Uml Intro H1

Hoang Huu Hanh, PhD [email protected] 



UML UNIFIED MODELING LANGUAGE

Hue University

ue University b a se d o n o n lin e co u rse s a n d p re se n ta tio n s

ue University

DEFINITION Unified Modeling Language is the successor to the wave of Object-Oriented Analysis and Design methods that appear in the late `80s and early `90s. Most directly unifies the methods of Booch, Rumbaugh (OMT), and Jacobson, but its reach is wider than that. UML went through a standardization process with the OMG (Object Management Group) and is now an OMG Introduction to UML

2

UML History

ue University Introduction to UML

3

ue University

WHAT IT IS UML is a modeling language, not a method Most methods consist, at least in principle, of both a modeling language and a process. Modelling Language is the (mainly graphical) notation that methods use to express designs. Process is their advice on what steps to take in doing a design. Modeling Language is the most important part of the method, which is the key part of communication. Introduction to UML

4

ue University

WHY USE UML  Helps Analysis and Design  Used for communication  Use the advantages of OO  Documentation 

As stated in The Unified Modeling Language User Guide; UML is a language for: • Visualizing • Specifying • Constructing • Documenting 



Introduction to UML

5

Visualizing It

makes it easier to understand and work through problem Since it is a formal language, it enables other developers familiar with the language to more easily interpret our drawings.

ue University Introduction to UML

6

Specifying We

must communicate our software system using some common, precise, and unambiguous communication mechanism. Again the formal nature of the UML facilitates this specification quite nicely.

ue University Introduction to UML

7

ue University

Constructing  We

know that the UML is a formal language with its own set of syntactical rules.  Because of this formality, we can create tools that interpret our models.  They can map the elements to a programming language, such as Java, C++.  Many tools such as Rational Rose, supports this forward engineering. In fact this is one of the advantages of using a formal modeling tool. Introduction to UML

8

Documenting The

models we create are just one of the articats produced throughout the development lifecycle. Using the UML in a consistent fashion produces a set of documentation that can serve as a blueprint of our system.

ue University Introduction to UML

9

ue University

USAGES Define the boundaries of a system & its major functions ◦ use cases and actors

Illustrate use cases

◦ interaction diagrams

Define the static structure of a system ◦ class diagrams

Model the behavior of objects ◦ state transition diagrams

Document the physical implementation architecture ◦ component & deployment diagrams

Provide for growth ◦ stereotypes

Introduction to UML

10

FUNDAMENTAL UML Models

and Views Core Diagrams Fundamental Elements

ue University Introduction to UML

11

Model Views Class Diagrams Sequence Diagrams

Class Diagrams (Packages)

Individual Diagrams «utility» utility1

«interface» Interface3

UseCase1

Class3 UseCase2 Actor1

Fundamental Elements Interface2

*

«uses»

-End1 *

Actor2

UseCase3

-End2

{}

ue University Introduction to UML

12

ue University

Models and Views UML

is more than disjointed diagrams Turn attention to an illustration of the UML from three different perspectives Further insight into these divisions enables us to realize one of the greatest benefits of modeling, which is creating different views of our software system. Introduction to UML

13

Core Elements Construct Description

Syntax

class

a description of a set of objects that share the same attributes, operations, methods, relationships and semantics. interface a named set of operations that characterize the behavior of an element. component a modular, replaceable and significant part of a system that packages implementation and exposes a set of interfaces. node a run-time physical object that represents a computational resource. ue University

« in

Introduction to UML

14

Core Elements (cont’d) Construct

Description

Syntax

constraint ¹

a semantic condition or restriction. { c o

n

s t r a

i n

t }

¹ An extension mechanism useful for specifying structural elements.

ue University Introduction to UML

15

Fundamental Elements These

are the elements of which diagrams are composed Understanding the intent of each element enables us to create precise diagrams, because each of them has unambiguous meaning.

ue University Introduction to UML

16

ue University

DIAGRAMS  Individual

diagrams contribute more to the specification of a software system.  They are composition of many of the fundamental elements.  Are mechanism that developers use to communicate and solve problems in the complex aspects of the system.  The most common diagram is the Class Diagram, which describe the structural relationships that exist among the classes, can guide developers in understanding our software system’s class structure. Introduction to UML

17

ue University

VIEWS  As

we become more proficient in modeling, we begin to realize that using a combination of diagrams to communicate is most effective.  We may need to combine class diagram with a diagram whose intent is to give systems dynamics.  By combining these called views.  View is a depiction of our system from a particular perspective.  By making different views, we can represent our system from different perspectives. Introduction to UML

18

ue University

VIEWS (cont’d) There are five main views, ◦ ◦ ◦ ◦ ◦

Use case Design Development Process Physical

They must be consistent with each other, because all of them are representing the same system. Can be used to validate each other. Introduction to UML

19

ue University

USE CASE VIEW  This

view documents the system from the customer’s perspective.  Terminology used in this view should be domain specific.  Depending on the technical nature of our audience, we should avoid obscure technical terms.  Diagrams most common in this view are the use case diagrams and, less common, activity diagrams.  Organizations transitioning to the UML may wish to work only with use case diagrams early and experiment with activity diagrams over time. Introduction to UML 20

ue University

Design VIEW This

view documents the system from designer’s and architect’s perspective. Diagrams most common in this view are class and interaction diagrams (either sequence or collaboration), as well as package diagrams illustrating the package structure of our Java application. 

Introduction to UML

21

ue University

Development VIEW This

view documents the components that the system is composed of. This view typically contains component diagrams. Except for the most complex Java applications, this view is optional.  Introduction to UML

22

ue University

Process VIEW This

view documents the processes and threads that compose our application. These processes and threads typically are captured on class diagrams using an active class. Because of the advanced nature of active classes, coupled with the volume of use, active classes are beyond the scope of this discussion. Introduction to UML

23

Physical VIEW This

view documents the system topology. Deployment diagrams that compose this view illustrate the physical nodes and devices that make up the application, as well as the connections that exist between them. 

ue University Introduction to UML

24

VIEWS (cont.) We

are not limited with the listed views. If there is something that architecturally important, for example security, then we may create a new view (ex: security view) into the system from that perspective.

ue University Introduction to UML

25

ue University

Modeling Elements Structural

elements

◦ class, interface, collaboration, use case, active class, component, node Behavioral

elements

◦ interaction, state machine Grouping

elements

◦ package, subsystem Other

elements

◦ note Introduction to UML

26

ue University

Diagrams - The foundation of UML  Use Case Diagrams ◦ Requirements

 Activity Diagrams ◦ Generally what, not who - good to detect parallelism

 Interaction Diagrams ◦ Collaboration/Communication Diagrams (object centered) ◦ Sequence Diagrams (timeline)

 Static Structure Diagrams ◦ Objects/Classes/Packages

 Statechart Diagrams ◦ States of objects with interesting lifecycles

 Implementation Diagrams ◦ Component Diagrams ◦ Deployment Diagrams Introduction to UML

27

ue University

DIAGRAMS  As we’ve seen, we can combine diagrams that form models and that can serve as views into our system.  If an advantage in modeling is to combine diagrams to form views into our system, then it only makes sense that each diagram has a different focus on what it communicates.  Each falls into one of two categories: behavioral, and structural.  Most commonly used

Introduction to UML

28

ue University

Behavioral diagrams  Behavioral diagrams depict the dynamic aspects of our system.They are most useful for specifying the collaborations among elements that satisfy the behavior of our system’s requirements.  Five diagrams that fall into this category are; ◦ Use case ◦ Activity ◦ State ◦ Sequence ◦ Collaboration (Communication)  Mostly used are use case, sequence, and collaboration.  Activity and state diagrams are used on an asneeded basis.  Activity diagrams visually represent behaviors captured by use cases.  State diagrams, on the other hand, are used to illustrate complex transitions in behavior for a single class. Introduction to UML

29

Core Relationships Construct

Description

association

a relationship between two or more classifiers that involves connections among their instances. A special form of association that specifies a whole -part relationship between the aggregate (whole) and the component part. a taxonomic relationship between a more general and a more specific element. a relationship between two modeling elements, in which a change to one modeling element (the independent element) will affect th e other modeling element (the dependent element).

aggregation

generalization

dependency

ue University

Syntax

Introduction to UML

30

Core Relationships (cont’d) Construct

Description

Syntax

realization

a relationship between a specification and its implementation.

ue University Introduction to UML

31

ue University

Relationships  An

association is a bi-directional connection between classes ◦ An association is shown as a line connecting the related classes

 An

aggregation is a stronger form of relationship where the relationship is between a whole and its parts ◦ An aggregation is shown as a line connecting the related classes with a diamond next to the class representing the whole

A

dependency relationship is a weaker form of relationship showing a relationship between a client and a supplier where the client does not have semantic knowledge of the supplier  A dependency is shown as a dashed line Introduction to UML 32

Relationship Notation 1

- one and only one 4 - four and only 4 0..1 - zero or 1 5..10 - five to and including 10 0..* - zero or more 4..* - four or more

ue University Introduction to UML

33

Finding Relationships Relationships

are discovered by examining interaction diagrams ◦ If two objects must “talk” there must be a pathway for communication

Registration Manager

RegistrationManager Math 101: Course

3: add student(joe) Course

ue University Introduction to UML

34

Relationships ScheduleAlgorithm

RegistrationForm

ue University

RegistrationManager addStudent(Course, StudentInfo)

Course name numberCredits

Student

open() addStudent(StudentInfo)

name major

Professor name tenureStatus

CourseOffering location open() addStudent(StudentInfo)

Introduction to UML

35

Associations Job 1..∗ ∗ Company employer employee

Job salary

Person

boss

worker ∗

0..1

Manages

Person Account

{X or} Corporation

ue University Introduction to UML

36

Association Ends 1 Polygon

+vertex 3..∗ Contains {ordered}

Point

1 1 -bundle

GraphicsBundle color texture density

ue University Introduction to UML

37

Relationship Notation 1

- one and only one 4 - four and only 4 0..1 - zero or 1 5..10 - five to and including 10 0..* - zero or more 4..* - four or more

ue University Introduction to UML

38

ue University

Ternary Associations Year season ∗

Team

∗

∗ goalkeeper

team

Player

Record goals for goals against wins losses ties

Introduction to UML

39

Composition Window scrollbar [2]: Slider title: Header body: Panel

Window 1 scrollbar Slider

2

1 1 title

1 Header

body

1 Panel

ue University Introduction to UML

40

Composition (cont’d) Window

scrollbar:Slider

2

1 title:Header

body:Panel

1

ue University Introduction to UML

41

ue University

Generalization Shape Separate Target Style

Polygon

Ellipse

Spline

. ..

Shape

Polygon

Ellipse

Shared Target Style

Spline

...

Introduction to UML

42

Generalization Vehicle venue

power power

{overlapping} WindPowered Vehicle

Truck

venue

MotorPowered Vehicle

{overlapping} Land Vehicle

Water Vehicle

Sailboat

ue University Introduction to UML

43

Dependencies ClassA

ClassD

ClassB

«friend»

«friend» «instantiate»

«call»

ClassC «refine»

ClassD

operationZ()

ClassC combines two logical classes

ClassE

ue University Introduction to UML

44

Dependencies Controller «access»

«access» «access»

Diagram Elements

«access»

«access» Domain Elements

Graphics Core

ue University Introduction to UML

45

Derived Attributes and Associations Person birthdate /age

{age = currentDate - birthdate}

Company

1

employer 1 employer

∗ Department 1

department WorksForDepartment

∗

∗ Person

/WorksForCompany { Person.employer=Person.department.employer }

ue University Introduction to UML

46

Links officer

treasurer downhillSkiClub:Club president

Jill:Person

member member

Joe:Person

member Chris:Person officer

ue University Introduction to UML

47

Constraints and Comments ∗

M em b e r - of

P e rs o n

∗ C o m m itt e e

{ s ub s e t} 1

C h ai r -o f

∗

e m p lo y e e

∗

0 .. 1

P e r so n

∗

R ep r e s en ts a n in c o r po r a te d e n ti ty .

em p l o y e r 0 .. 1

C om pa ny

b os s

{ P e r s o n. em p l oy e r = P e rs o n. bo s s .e m p lo y e r }

ue University Introduction to UML

48

ue University

Actors An

actor is someone or some thing that interacts with the system External Forces ◦ Human interaction ◦ Automated System Driver User

Keyboard Operator

Traffic Control System

<> <> Introduction to UML

49

ue University

Use Cases A use case is a pattern of behavior the system exhibits ◦ Each use case is a sequence of related transactions performed by an actor and the system in a dialogue ◦ Details what the system must provide to the actor when the use cases is executed

A flow of events document is created for each use case ◦ Written from an actor point of view ◦ Actors are examined to determine their how they interact with the system

§ Break down into the most atomic actions possible

Typical contents ◦ ◦ ◦ ◦

How the use case starts and ends Normal flow of events Alternate flow of events Exceptional flow of events Introduction to UML

50

ue University

Use case diagrams Use case diagrams are centered around the business processes that our application must support. Most simply, use case diagrams enable us to structure our entire application around the core processes that it must support. Doing so enables us to use these use cases to drive the remainder of the modeling and development effort. Shows a set of actors and use cases, and the relationships between them. Use case diagrams contribute to effective model organization, as well as modeling the core behaviors of a system. Introduction to UML

51

ue University

Use Case Diagram Captures system functionality as seen by users Built in early stages of development Purpose ◦ Specify the context of a system ◦ Capture the requirements of a system ◦ Validate a system’s architecture ◦ Drive implementation and generate test cases

Developed by analysts and

Introduction to UML

52

Use Case Diagram Use

case diagrams are created to visualize the relationships between actors and use cases Pay toll Driver

Passager Lost Luggage

Customer Service Agent

ue University

Ramp Maintenance Mechanic

Introduction to UML

53

Use Case Diagram Captures

system functionality as seen by users

ue University Introduction to UML

54

ue University

Collaboration Diagrams A

type of interaction diagram that describes the organizational layout of the objects that send and receive messages. Semantically equivalent to a sequence diagram. It uses class diagrams layout, and can be used to make more cohesive and less coupled classes. Introduction to UML

55

ue University

Collaboration Diagram A

collaboration diagram displays object interactions organized around objects and their links to one another course form : 1: set course info 2: process

CourseForm

3: add course

: Registrar

theManager : CurriculumManager

aCourse : Course 4: new course

Introduction to UML

56

ue University

Sequence Diagrams Semantically

equivalent to a collaboration diagram. sequence diagram is a type of interaction diagram that describes time ordering of messages sent between objects. Almost in all software development activity, this diagram is used. Introduction to UML

57

Sequence Diagram A

sequence diagram displays object interactions arranged in a time sequence

Passenger

Counter Agent

Ticket

Gate Agent

Plane

1: Give Info 2: Questions 3: Answer 5: Safeguard

4: Print 6:Present

7: Board 8: Overbook

9: Return

ue University Introduction to UML

58

The State of an Object A

state transition diagram shows ◦ The life history of a given class ◦ The events that cause a transition from one state to another ◦ The actions that result from a state change

State

transition diagrams are created for objects with significant dynamic behavior

ue University Introduction to UML

59

State Transition Diagrams Illustrates

internal state-related behavior of an object. Transitions between states help identify, and validate, complex behavior. A class can have at most a single state diagram. 

ue University Introduction to UML

60

State Transition Diagram Add student[ count < 10 ] Initialization

Add Student / Set count = 0

do: Initialize course

Open entry: Register student exit: Increment count

Cancel Cancel

[ count = 10 ]

Canceled do: Notify registered students

Cancel

Closed do: Finalize course

ue University Introduction to UML

61

Activity Diagrams Models

the flow of activity between processes. These diagrams are most useful in detailing use case behavior. An activity diagram doesn’t show collaboration among objects. 

ue University Introduction to UML

62

ue University

STRUCTURAL DIAGRAMS  Diagrams in this category are focused on specifying the static aspects of our system.  Of these four diagrams, the class diagram is most often used.  when transitioning to the UML, most organizations tend to use class diagrams first because they are excellent mechanisms for communication among developers, as well as tools that can be used for problem solving.  There are two forms of class diagrams.  The first is the most commonly understood and consists of the classes that compose our system and of the structure among these classes.  Unfortunately, the second is not often used but is of equal importance and can be most effective in helping developers understand our system from a high level.  A type of class diagram, called a package diagram, often represents the Java packages and the dependencies between them that our application consists of. Introduction to UML

63

Class Diagrams Illustrates

a set of classes, packages, and relationships detailing a particular aspect of a system. This diagram is likely the most common one used in modeling. 

ue University Introduction to UML

64

ue University

Class Diagrams  A class diagram shows the existence of classes and their relationships in the logical view of a system  UML modeling elements in class diagrams ◦ Classes and their structure and behavior ◦ Association, aggregation, dependency, and inheritance relationships ◦ Multiplicity and navigation indicators ◦ Role names

 Attributes ◦ The structure of a class is represented by its attributes ◦ Attributes may be found by examining class definitions, the problem requirements, and by applying domain knowledge

 Operations ◦ The behavior of a class is represented by its operations interaction ◦ Operations may be found by examining Introduction to UML

65

Class Diagram  Captures

the vocabulary of a system

ue University Introduction to UML

66

ue University

Object Diagrams  Provides

a snapshot of the system illustrating the static relationships that exist between objects.  Object diagrams depict the structural relationship that exists among the objects within our running application at a given point in time.  When we think of the runtime version of our system, we typically think of behavior.  Many people have found that object diagrams are most useful in fleshing out the instance relationships among objects, which in turn can help verify our class diagrams.  Beyond this, object diagrams are not often used. Introduction to UML

67

ue University

Relationships Relationships provide a pathway for communication between objects Sequence and/or collaboration diagrams are examined to determine what links between objects need to exist to accomplish the behavior -- if two objects need to “talk” there must be a link between them Three types of relationships are: ◦ Association ◦ Aggregation ◦ Dependency

Introduction to UML

68

ue University

Multiplicity and Navigation Multiplicity

defines how many objects participate in a relationships ◦ Multiplicity is the number of instances of one class related to ONE instance of the other class ◦ For each association and aggregation, there are two multiplicity decisions to make: one for each end of the relationship

Although

associations and aggregations are bi-directional by default, it is often desirable to restrict navigation to one direction If navigation is restricted, an Introduction to UML

69

Multiplicity and Navigation ScheduleAlgorithm

RegistrationForm 0..*

1 RegistrationManager addStudent(Course, StudentInfo)

Course

1 0..* Student

name numberCredits open() addStudent(StudentInfo)

major

1 3..10 Professor tenureStatus

4 1

1..* CourseOffering location

0..4

open() addStudent(StudentInfo)

ue University Introduction to UML

70

ue University

Inheritance Inheritance

is a relationships between a superclass and its subclasses There are two ways to find inheritance: ◦ Generalization ◦ Specialization Common

attributes, operations, and/or relationships are shown at the highest applicable level in the hierarchy Introduction to UML

71

Inheritance ScheduleAlgorithm

RegistrationForm RegistrationManager addStudent(Course, StudentInfo)

Course name numberCredits

RegistrationUser name

Student

open() addStudent(StudentInfo)

major

Professor tenureStatus

CourseOffering location open() addStudent(StudentInfo)

ue University Introduction to UML

72

The Physical World Component

diagrams illustrate the organizations and dependencies among software components A component may be ◦ A source code component ◦ A run time components or ◦ An executable component

ue University Introduction to UML

73

ue University

Component Diagrams Addresses

the static relationships existing between the deployable software components. Examples of components may be .exe, .dll, .ocx, jar files, and/or Enterprise JavaBeans. Component diagrams might be used to show the software components within our application. Components aren’t equivalent to Introduction to UML

74

Component Diagram Captures

the physical structure of the implementation

ue University Introduction to UML

75

Deploying the System The

deployment diagram shows the configuration of run-time processing elements and the software processes living on them The deployment diagram visualizes the distribution of components across the enterprise.

ue University Introduction to UML

76

Deployment Diagram Captures

the topology of a system’s hardware

ue University Introduction to UML

77

Extensibility Mechanisms Stereotype Tagged

value Constraint

ue University Introduction to UML

78

ue University

Extending the UML Stereotypes can be used to extend the UML notational elements Stereotypes may be used to classify and extend associations, inheritance relationships, classes, and components Examples: ◦ Class stereotypes: boundary, control, entity, utility, exception uses ◦ Inheritance stereotypes: Introduction to UML and 79

ue University

Deployment Diagrams  Describes

the physical topology of a

system.  Typically includes various processing nodes, realized in the form of a device (for example, a printer or modem) or a processor (for example, a server).  Deployment diagrams are most useful when we have a complex configuration environment.  If our application is to be deployed to multiple servers, across locations, a deployment diagram might be useful. 

Introduction to UML

80

Q&A

… time to ask questions

ue University Introduction to UML

81

Thank you! … take a break

ue University Introduction to UML

82