Object-oriented system analysis and design

Introduction to UML
Hieu Dinh Vo

Contents
Origins of UML Using UML Use case diagrams Class diagrams State diagrams and sequence diagrams

Origins of UML
In the 1980s, object-oriented programming moved from research labs into the real world Smalltalk and C++ became popular languages and various people started thinking about object-oriented graphical design languages Between 1988 and 1992, the key authors were Booch, Coad, Jacobson, Odell, Rumbaugh, Shlaer, Mellor, and Wirfs-Brock
Each author was informally leading a group of practitioners who liked those ideas The same basic OO concepts would reappear in very different notations, causing confusion with clients

When Jim Rumbaugh left GE to join Grady Booch at Rational, an alliance was formed and a critical mass of market share occurred In 1997, Rational released UML 1.0

Origins of UML
Consists of a family of graphical notations that help in describing and designing software systems Focuses particularly on software systems built using the object-oriented style Controlled by the Object Management Group, which is an open consortium of companies Comes from the unification of many OO graphical modeling languages that thrived in the 1980s and early 1990s
4

Ways of Using the UML

UML as sketch UML as blueprint UML as programming language

As a Sketch
Most common use of UML Used to help communicate some aspect of a system and to better understand it Used for both forward engineering (i.e., build diagrams before coding) and reverse engineering (i.e., build diagrams from existing code) Only emphasizes those classes, attributes, operations, and relationships that are of interest More concerned with selective communication than complete specification
6

As a Blueprint
Goal is completeness Is more definitive, while the sketch approach is more explorative Used to describe a detailed design for a programmer to follow in writing source code Notation should be sufficiently complete so that a programmer can follow it in a straightforward manner Can be used by a designer to develop blueprint-level models that show interfaces of subsystems or classes
Developers then work out the implementation details

As a reversed engineered product, diagrams convey detailed information about the source code that is easier for developers to understand
7

As a Programming Language
Specifies the complete system in UML so that code can be automatically generated Looks at UML from a software perspective rather than a conceptual perspective which concentrates on the domain of study Diagrams are compiled directly into executable code so that the UML becomes the source code Challenge is making it more productive to use UML rather than some another programming language Another concern is how to model behavioral logic
Done with interaction diagrams, state diagrams, and activity diagrams
8

Aspects of UML
Views Diagrams Model elements General mechanisms Model Driven Architecture (MDA) features

Views
Use-case view: A view showing the functionality of the system as perceived by external actors. Logical view: A view showing how the functionality is designed inside the system, in terms of the systems static structure and dynamic behavior. Implementation view: A view showing the organization of the code and the actual execution code. Process view: A view showing main elements in the system related to process performance. This view includes scalability, throughput, and basic time performance and can touch on some very complex calculations for advanced systems. Deployment view: A view showing the deployment of the system into the physical architecture with computers and devices called nodes.

10

Views

11

Classification of Diagram Types

Class Diagram Structure Diagram Composite Structure Diagram Object Diagram Diagram Deployment Diagram Package Diagram Sequence Diagram Communication Diagram Interaction Overview Diagram Timing Diagram Component Diagram

Use Case Diagram Behavior Diagram Activity Diagram Interaction Diagram State Machine Diagram

12

Use Case Diagram

Use cases serve as a technique for capturing the functional requirements of a system Describes the typical interactions between the users of a system and the system itself, providing a narrative of how a system is used A use case consists of a set of one or more scenarios tied together by a common user goal Users are referred to as actors; an actor is a role that carries out a use case An actor need not always be a person; it can also be an external system that is either automated or manual
13

Use Case Diagram

A use case diagram is like a graphical table of contents of the use cases for a system
It shows the use cases, the actors, and the relationships between them

Use cases represent an external view of the system; consequently, they have no correlation to the classes in the system
They can serve as a starting point for writing software validation test cases
14

15

Use Cases
A use case is always initiated by an actor. The actor must directly or indirectly order the system to perform the use case. A use case provides value to an actor. A use case must deliver some kind of tangible value to an actor or actors. A use case is complete. A use case must be a complete description. A common mistake is to divide a use case into smaller use cases that implement each other much as functions call each other in a programming language. A use case is not complete until the end value is produced, even if several communications (such as user dialogs) occur along the way.
16

Finding Actors
Who will use the main functionality of the system? Who will need support from the system to do their daily tasks? Who will need to maintain and administer the system, and keep it working? Which hardware devices does the system need to handle? With which other systems does the system need to interact? Who or what has an interest in the results (the value) that the system produces?
17

Relationships between Actors

18

Finding Use Cases

Which functions does the actor require from the system? What does the actor need to do? Does the actor need to read, create, destroy, modify, or store some kind of information in the system? Does the actor have to be notified about events in the system, or does the actor need to notify the system about something? What do those events represent in terms of functionality? Could the actors daily work be simplified or made more efficient by adding new functions to the system (typically functions currently not automated in the system)?
19

Relationships between Use Cases

Generalization Include Extend

20

Organizing Use Cases

21

Class Diagram
Describes the types of objects in the system and the various kinds of static relationships that exist among them Also shows the properties and operations of a class and the constraints that apply to the way objects are connected Name A class box has three parts: Attributes
Name of the class Attributes of the class Operations of the class
Operations

Properties represent structural features of a class and consist of attributes and associations
22

Finding Classes
Do I have information that should be stored or analyzed? Do I have external systems? Do I have any reusable patterns, class libraries, or components? Are there devices that the system must handle? Do I have organizational parts? Which roles do the actors in the business play?

23

Visibility
If an attribute has the visibility of public, it can be used and viewed outside that class. If an attribute has the visibility of private, you cannot access it from other classes. If an attribute is protected it is private to the class, but visible to any subclasses through generalization and specialization.

24

Relationships
An association is a connection between classes, which means that it is also a connection between objects of those classes. In UML, an association is defined as a relationship that describes a set of links, where link is defined as a semantic connection among a tuple of objects. A generalization is a relationship between a more general and a more specific element. The more specific element can contain only additional information. An instance (an object is an instance of a class) of the more specific element may be used wherever the more general element is allowed. A dependency is a relationship between elements, one independent and one dependent. A change in the independent element will affect the dependent element.
25

Associations

Normal Association

Recursive Association

26

Qualified Associations

27

Xor Constraint

28

Aggregation
Aggregation is a special case of association that indicates that the relationship between the classes is some sort of whole-part Types
Shared Aggregation Composition Aggregation

29

Generalization

30

Interfaces

31

Packages
A package provides a grouping mechanism for organizing UML elements In UML, a package is used to group elements and to provide a namespace for the grouped elements

32

Dynamic Modeling
State machines. These describe which states an object can have during its life cycle, and the behavior in those states along with what events cause the state to change; for example, an invoice can be paid (state paid) or unpaid (state unpaid). Activity diagrams. These show communication in a system, but they focus on workflow. When objects are interacting with each other, the objects also perform work in terms of activities. These activities and their order are described in activity diagrams. Activity diagrams do not have to reference a specific object but can just reference a high-level flow. Interaction diagrams. These describe how objects communicate with each other. The sequence diagram shows how a sequence of messages is sent and received between a set of objects in order to perform some function. The interaction overview diagram shows interaction diagrams as part of a larger flow. The communication diagram focuses on the relationship between interacting objects.

33

State Machines

34

State Machines

35

Activity Diagram
Serves as a technique to describe procedural logic, business process logic, and work flow Is similar to a flowchart except that it can also show parallel behavior States the essential sequencing rules to follow, thereby allowing concurrent algorithms to be used
Consequently, an activity diagram allows whoever is doing the process to choose the order in which to do certain things

Can be used to describe the actions in a use case

36

Activity Diagram
Set counter = positive n Set accumulator = initial value F

n>1 T

Set accumulator = accumulator * n Set n = n - 1 F T (n mod 5) == 0

Display accumulator value

Return accumulator value

37

Activity Diagram

38

Sequence Diagram
Two types
Instance form Generic form

39

Sequence Diagram

40

Concepts used in a sequence diagram

41

Combined Fragments

42

Combined Fragments

43

44

45

Address Book
The software to be designed is a program that can be used to maintain an address book. An address book holds a collection of entries, each recording a person's name, address, phone number, and email. It must be possible to add a new person to an address book, to edit existing information about a person (except the person's name), and to delete a person. It must be possible to sort the entries in the address book alphabetically by name. It must be possible to create a new address book, to open a disk file containing an existing address book to close an address book, and to save an address book to a disk file, using standard New, Open, Close, Save and Save As ... File menu options. The program's File menu will also have a Quit option to allow closing all open address books and terminating the program. The initial requirements call for the program to only be able to work with a single address book at a time; therefore, if the user chooses the New or Open menu option, any current address book will be closed before creating/opening a new one. The program will keep track of whether any changes have been made to an address book since it was last saved, and will offer the user the opportunity to save changes when an address book is closed either explicitly or as a result of choosing to create/open another or to quit the program.
46

Draw use case diagram Define use cases Draw conceptual class diagrams Refine class diagrams Draw sequence diagrams

47