Unified Modeling Language (UML)

Flight Booking System

MagicDraw UML 16.0

Completed by Firas M. Kadhum Iraq- Baghdad

TABLE OF CONTENTS
Title Page No.

Introduction: The UML 1 2 3 4 5 What Is UML? Conceptual changes between UML 1.x and UML 2.0 : Comparison of the types of diagram: Aspects of the model: The structure of UML 2.0 diagrams:

3 3 3 4 5 10 11 13 13 14 15 15 16 17 18 19 21 22 22 23 24

An In-Depth Look at UML: 1 2 3 4 5 6 Use Case Diagram: Class Diagram: Sequence Diagram: Communication (collaboration) Diagram: State Machine Diagram: Activity Diagram:

Notation of Use Case Diagram: Notation of Class Diagram: Notation of Sequence Diagram: Notation of Communication (collaboration) Diagram: Notation of State Machine Diagram: Notation of Activity Diagram: References:

Introduction:
The purpose with this document is to provide a brief introduction to the Unified Modeling Language (UML) for programmers and software architects, to review the diagrams that comprise UML and offer some examples on how these diagrams are used to model systems.

The UML:
1- What Is UML? The Unified Modeling Language (UML) is a family of graphical notations, backed by single metamodel, that help in describing and designing software systems, particularly software systems built using the object-oriented (OO) style. That's a somewhat simplified definition. In fact, the UML is a few different things to different people. This comes both from its own history and from the different views that people have about what makes an effective software engineering process [1]. The UML was born out of the unification of the many object-oriented graphical modeling languages that thrived in the late 1980s and early 1990s. Since its appearance in 1997, it has relegated that particular tower of Babel to history. It is a unification and standardization of earlier modeling notations of Rumbaugh, Jacobson, Booch, Mellor, Shlaer, Coad, and Wirf-Brock, among others. The UML most closely reflects the combined work of James Rumbaugh, Ivar Jacobson, and Grady Booch sometimes called the three amigos, and the Rational Software Corporation. These renowned computer scientists fused their respective technologies into a single, standardized model. Today, The UML is accepted by the Object Management Group (OMG) as the standard for modeling object oriented programs. It can be used to model different kinds of systems: software systems, hardware systems and real-world organizations. From UML it is possible to automatically generate different types of descriptions (for example specifications in XML), or even automatic creation of software code. UML is becoming a standard tool for software and system engineers.

2- Conceptual changes between UML 1.x and UML 2.0 : There are no conceptual changes to the UML whatsoever. The concepts of structural and behavioural modelling are exactly the same. It is still essential to have both aspects of the model but now there are 13, rather than 9, diagrams available to realize these 2 aspects as indicated on Figure 1 and listed in Table 1. The concepts of choosing the right model, levels of abstraction, connection to reality and independent views of the same system remain the same as they are basic modelling concepts, rather than UML-specific concepts. Therefore, anyone with a full and proper understanding of the concepts of the UML, should find the changes logical and easy to understand the changes are all syntactical [2].

Figure (1): The 13 types of UML 2.0 diagram

Diagram
Activity Class Communication

Purpose
Procedural and parallel behavior Class, features, and relationships Interaction between objects; emphasis on links

Lineage
In UML 1 In UML 1 UML 1 Collaboration

Component Composite structure Deployment Interaction overview Object

Structure and connections of components Runtime decomposition of a class Deployment of artifacts to nodes Mix of sequence and activity diagram Example configurations of instances Compile-time hierarchic structure Interaction between objects; emphasis on sequence How events change an object over its life Interaction between objects; emphasis on timing How users interact with a system
Table (1): Official diagram types of UML 2.0
[1]

In UML 1 New to UML 2 In UML 1 New to UML 2 Unofficially in UML 1 Unofficially in UML 1 In UML 1 In UML 1 New to UML 2 In UML 1

Package Sequence State machine Timing Use case

3- Comparison of the types of diagram: As mentioned above, the most immediately-apparent differences between UML 2.0 and UML 1.x are the number of diagrams UML 1.x has 9 diagrams, whilst UML 2.0 has 13 diagrams and the significant changes in terminology for diagram elements. In order to understand the new diagrams and some of the term changes, UML 2.0 and UML 1.x will be compared at a diagrammatical level, first
5

considering the structural diagram and then the behavioural diagrams. Figure 2 shows a comparison of the structural diagrams [2].

Figure (2): Comparison of structural diagrams UML 2.0 versus UML 1.x

[2]

The diagram in Figure 2 shows how the structural diagrams relate between UML 2.0 and UML 1.x. The main differences are as follows: Object diagram to Object diagram no significant changes. Package diagram to Class diagram although the package diagram is a new type of diagram, it is simply the concept of a package from UML 1.x, but this time it is given its own diagram. These are useful for defining profiles, showing ownership of model elements and relating models together using their merges and uses relationships. Class diagram to Class diagram no significant changes, although more emphasis is now put on identifying interfaces in class diagrams.
6

 Composite structure diagram to Class diagram again, a new type of diagram, but this time there are two distinct uses: defining logical structure within a composite or aggregation and identifying collaborations. In UML 1.x it was possible for class diagrams to be created where the emphasis was on identifying the elements in a composite structure (aggregations and compositions) rather than on the logical relationships between these lowerlevel elements. The composite structure diagram allows an aggregation or composition to be replaced by a Part that contains a number of structural elements, such as classes. This was only achievable in UML 1.x by cheating by using a package to show the contents of a class. This usage is particularly good for modelling architectures of systems. The second usage is to identify static collaborations within a model that represent two diagram elements that will interact with each other in some way. There is then a clear, and obvious, connection to all interaction diagrams that then go on to explore the behaviour of such collaborations. In summary, therefore, it is a completely new diagram which, unlike the new package diagram, has many new symbols and notations. Deployment diagram to Deployment diagram these diagrams are very similar, but now it is objects and artifacts that are deployed in UML 2.0, rather than objects and components in UML 1.x. Components are now abstract specifications whereas an artifact represent the actual implementation of a component. Component diagram to Component diagram significant improvements to interfaces that can now be output (required) or input (provided) and can have parts. The internal structure of a component can now be specified using parts and the symbol has been made far simpler to draw by abandoning the cumbersome single plus double rectangle notation with a stereotyped class called component. Figure 3 shows a high-level comparison of the behavioural diagrams in UML 2.0, compared with UML 1.x.

Figure (3): Comparison of behavioural diagrams UML 2.0 versus UML 1.x [2]

The diagram in Figure 3 shows how the behavioural diagrams relate between UML 2.0 and UML 1.x. The main differences are as follows:

Use

case diagram to Use case diagram no significant differences unfortunately the dreaded stick person is still there, although there are recommendations to stereotype the symbol.

State machine diagram to Statechart diagram apart from the name change, optional graphical notation has been introduced for conditions, events and actions (the same as the optional notation in activity diagrams). Otherwise it is the same in UML 2.0 as in UML 1.x. Activity diagram to Activity diagram enhanced regions (swimlanes and interruptible regions) and the concept of token flow has now been introduced that has been taken from Petri nets. The main behavioural unit is
8

now an activity activation that replaces the action state and activity state. Graphically, they look very similar. Communication diagram to Collaboration diagram the name has changed to make the distinction between a collaboration (structural) and interaction (behavioural) more apparent. Rather than objects, the main element in all interaction diagrams is now the Life line (not the same as the UML 1.x life line, rather confusingly) that represents instances of classifiers (objects are instances of classes). This enables greater flexibility as it is now possible to model interactions between instances of any classifiers, such as components, classes, actors, and so on. Interactions are now bundled up into frames so that they can be reused. Timing diagram to Collaboration diagram and Sequence diagram a new diagram that looks at the timing involved with life lines and their states. Two graphical styles one is a traditional time line, as seen on graphs (known as a state condition time line) whereas the other concentrates on the duration of each state (known as general value time line) and looks more like timing shown on communication protocols. The timing diagram has very strong relations with all other interaction diagrams and state machine diagrams. Interaction overview diagram to Collaboration diagram and Sequence diagram a new diagram that represents interactions at a high level. Effectively, individual scenarios can be connected together using activity diagram notation (with interactions replacing the nodes) to form complex behaviour, such as complete system behaviours. Sequence diagram to Sequence diagram like the communication diagram, the new sequence diagrams now use life lines and enable scenarios to be bundled up using frames. This allows scenarios to be referenced from within scenarios. Also, the introduction of conditions allows several options to be explored on a single scenario.

4- Aspects of the model: As discussed previously the 13 diagrams in the UML 2.0 that are grouped into two broad categories, each of which represents a particular aspect of the model. These 2 aspects of the model are the structural (often referred to as static) and behavioural (often referred to as dynamic, or timing) aspects of the model. It is vital that both of these aspects exist for any system, otherwise the system is not fully defined [2]. The structural aspect of the model shows the what of the system, while the behavioural aspect of the model shows the how. This means the structural aspect of the model shows the things or entities in a system and the relationships between them. It is crucial to remember that the structural aspect of the model shows what the system looks like and what it does, but not how. While the behavioural aspect of the model demonstrates how a system behaves over time by showing the order in which things happen, the conditions under which they happen and the interactions between things. Figure 4 shows the UML diagrams that relate to structural modelling. The structural aspect of the model may be realised by Six UML diagrams:

Class diagram Package diagram Composite Structure diagram Object diagram Component diagram Deployment diagram

Figure (4): Diagrams that realise a structural aspect of the model in the UML [2]

10

Figure 5 shows the UML diagrams that relate to behavioural modelling. The behavioural aspect of the model may be realised by Seven UML diagrams:

State Machine diagram Activity diagram Use Case diagram Sequence diagram Communication diagram State Machine diagram Timing diagram Interaction Overview diagram

Figure (5): Diagrams that realise the behavioural aspect of the model in the UML

[2]

Note that details on all of these diagrams, and much more in UML, can be found at www.omg.org, or go directly to www.uml.org.

5- The structure of UML 2.0 diagrams: Each diagram in the UML 2.0 has the same structure, which is intended to provide a similar appearance for each, as well as making cross referencing between diagrams simpler. The structure of each diagram is shown in Figure 6 [2].

11

Figure (6): Structure of each UML 2.0 diagram

[2]

The diagram in Figure 6 shows that each diagram is made up of one or more graphic node and one or more graphic path. Each graphic path relates together one or more graphic node. Examples of graphic nodes include: classes on class diagrams, objects on object diagrams, etc. Examples of graphic paths include: relationships on class diagrams and links on object diagrams. Any UML diagram may have an optional graphic node known as a Frame that encapsulates the diagram and that has a unique identifier, in order to make identification of, and navigation between, diagrams simpler. An example of a frame is shown in Figure 7.

Figure (7): Example of a frame in UML 2.0

[2]

The diagram in Figure 7 shows the symbol for a frame, which is, quite simply, a large rectangle that will contain all the view elements in a particular diagram. The pentagon in the upper left-hand corner contains two references one to the type of diagram (for example: cd for class diagram, od for object diagram, etc.) and then one to the name, or identifier for the diagram.

12

An In-Depth Look at UML:

The remainder of this paper describes the most valuable UML diagrams: those that yield the biggest bang for the buck on most projects. This core set consists of the:

Use case diagram Class diagram Sequence diagram Communication (collaboration) diagram State Machine diagram Activity diagram

Now, this section presents a more detailed look at modeling with UML. A very simple Flight Booking System is used to illustrate UML diagrams. Note that all the next UML diagrams have been applied in MagicDraw v16.0.

1) Use Case Diagram:

Use case diagrams model the functionality of a system using actors and use cases. Use cases are services or functions provided by the system to its users. Here is a use case diagram for our Flight Booking System as in Figure 8.

Figure (8): Use Case Diagram

13

The description for use case Reservation Flight: 1- Passenger requests flight from Ticket Vendor. 2- Ticket Vendor checks availability from Airline. 3- Airline says Ticket is available, provides flight details. 4- Ticket Vendor provides Passenger with flight details. 5- Passenger request seat preference. 6- Ticket Vendor books seat. 7- Ticket Vendor confirms reservation with Passenger. 8- Ticket Vendor requests payment from Passenger. 9- Passenger sends payment to Ticket Vendor. 10- Ticket Vendor sends payment to Airline. 11- Airline provides final confirmation to Ticket Vendor. 12- Ticket Vendor issues ticket to Passenger.

2) Class Diagram:
Class diagrams are the backbone of almost every object-oriented method including UML. They describe the static structure of a system. Here is a class diagram example for our Flight Booking System as in Figure 9.

Figure (9): Class Diagram

14

3) Sequence Diagram:
Sequence diagrams describe interactions among classes in terms of an exchange of messages over time. Here is a simple sequence diagram for a use case called Reservation Flight as in Figure 10.

Figure (10): Sequence Diagram

4) Communication (collaboration) Diagram:

Communication Diagram a simplified version of the UML 1.x collaboration diagram. A Communication diagram models the interactions between objects or parts in terms of sequenced messages. Communication diagrams represent a combination of information taken from Class, Sequence, and Use Case Diagrams describing both the static structure and dynamic behavior of a system. The following Figure 11 shows communication diagram for our system.

15

Figure (11): Communication Diagram

5) State Machine Diagram:

State Machine Diagram is essentially a Harel statechart with standardized notation, which can describe many systems, from computer programs to business processes. In UML 2 the name has been changed to State Machine Diagram. Here is an example state machine diagram describing the state space for the Reservation class in our system domain as in Figure 12.

Figure (12): State Machine Diagram

16

6) Activity Diagram:
An activity diagram illustrates the dynamic nature of a system by modeling the flow of control from activity to activity. An activity represents an operation on some class in the system that results in a change in the state of the system. Typically, activity diagrams are used to model workflow or business processes and internal operation. Because an activity diagram is a special kind of statechart diagram, it uses some of the same modeling conventions. Here is an example activity diagram for our system as in Figure 13.

Figure (13): Activity Diagram

17

 Notation of Use Case Diagram:

The system boundary

Figure (14): Graphical representation of elements of a use case diagram

[2]

18

 Notation of Class Diagram:

+ Public - Private # Protected

Visibility

Multiplicity

Figure (15): Graphical representation of elements of a class diagram [2]

19

Figure (16): UML notation for attributes in class

Figure (17): UML notation for operations/methods in class

20

 Notation of Sequence Diagram:

Figure (18): Graphical representation of elements of a sequence diagram [2]

21

 Notation of Communication (collaboration) Diagram:

Figure (19): Graphical representation of elements of a communication diagram [2]

Notation of State Machine Diagram:

Figure (20): Graphical representation of elements of a state machine diagram [2]

22

 Notation of Activity Diagram:

Figure (21): Graphical representation of elements in an activity diagram [2]

23

References:
[1] FOWLER, M.: UML distilled (a brief guide to the standard object modeling language) (Addison-Wesley Professional, 2004, 3rd Ed.) [2] John, H.: UML for Systems Engineering: watching the wheels, (IEE Professional Applications of Computing, 2004, 2nd Ed.) [3]LARMAN, G.: Applying UML and patterns an introduction to object-oriented analysis and design (Prentice Hall Inc., New Jersey, 1998.) [4] Wikipedia http://www.wikipedia.org/. [5] MagicDraw Users Manual.

24