Abstractions in programming
Introduction
Programmers make a lot of use of abstractions to help them understand particular aspects of a system they are programming.
Flow diagrams
Flow diagrams model a sequence of events. There is no detail about the nature of the information that is required to be input, whether it is via a keyboard or voice, for example. There is no detail about the messages that need to be displayed, or the log of log-ins that usually is updated each time a person logs in, and so forth. What is does do, however, is to allow a programmer to see what key events happen and in what order, so they can design some code that does this.
Use-case diagram
The use case diagram is an abstraction of a real system that gives a pictorial representation of all the external systems or people (usually called 'actors') who interact with a particular system, the range of functions that they will need when they interact with it and how the functions themselves interact with each other. Generally, this type of diagram describes what a system must actually be able to do (the 'use cases') and the people (or systems) involved who must use it (the 'actors').
Use case diagrams are a really good starting point for any project, and as such, are usually produced in the early, planning stages. It gives a clear summary of the actors in a system and the main processes that need to be designed. If a use case diagram is done properly and completely, what you actually end up with is essentially a Requirements Specification for the system you are going to build.
Use case diagrams provide an overview, which can be used by a team of designers as the basis for checking that all the major areas in a system have been covered and that all the relevant actors have been included. They can then also use this diagram to help them to go on to design and plan further, more detailed work.
UML diagrams, designing classes and the nature of inheritance
Object oriented programs make use of something called a 'class'. This is simply a template that spells out what information you need to keep about an object and what you need to do with the data. For example, if you need to keep information about student 'objects', then first, you need to design a template that will be used to create as many student objects as you need.
The specification for a class using Unified Modelling Language notation would look like the three-part box above, which shows the name of the class, the data and data type of each object created using this class and the things you will do with each piece of data (called 'methods'). There are no other details, such as any validation rules for the data, but this is enough information to allow a programmer to get started.
A characteristic of object oriented programming is that once you have designed one class, you can use it to quickly design other classes using something called 'inheritance'.
In the above diagram, we need to create a new class called 'Student'. This has all of the details (data and methods) of the class called Person, plus a few extra ones. Rather than design a completely new class, we can design one that inherits everything that Person has got, and simply add the extra ones. In the UML diagram above, the arrow from Student to Person shows that Student inherits all the data and methods from Person, and has the extra ones shown in its own box. The same idea is used for a new class called Teacher. This also inherits everything from Person, and has its own extra data and methods that are unique to teachers.
Again, what we have here are abstractions, where unnecessary details are omitted and a model is built up that shows a programmer what classes they need, how they are related and the required data and methods needed by each class. This is just enough information to allow the programmer to make a start and to identify what other diagrams must be created.
Sequence diagrams
A sequence diagram shows how the different objects in a system programmed using an object oriented programming language interact with each other. It shows the objects in the system, the order that the interactions happen in and the processes that occur as a result. This is another example of an abstraction, that allows a programmer to focus on a particular job that needs doing, without worrying about unneccesary details.
There are various symbols used In sequence diagrams.
* instances of objects are shown at the top with a dashed line descending from the center of the name.
* Processes are shown as vertical boxes.
* Interactions or messages (methods) being passed between the processes are shown as arrows in the order that the messages are passed, starting from the top.
In the example on the left, you can see a typical sequence diagram for the withdrawal of money from an ATM machine. You can see the objects that communicate with each other at the very top of the diagram. Dotted lines fall from the center of each object's name. These are known as the object's life lines and simply allow the reader to have a point of reference for each object.
Each message is identified with a reference number and is represented by an arrow.
Each message has a short description, identifying the purpose of the message.
Arrows flow from the one vertical dotted line (an object) to another vertical dotted line (another object).
Messages flow downwards from the top of the diagram in the order that they occur.
A message typically flows into a black box. This is the symbol used when some code associated with the object is actually running and doing some processing, usually because it has been triggered by a message being received.