UML Slides K50

8/4/2019 UML Slides K50

1/74

1

LLP TRNH HP TRNH HNGNGI TI TNGNG

(OBJECT(OBJECT--ORIENTED PROGRAMMING TECHNIQUES)ORIENTED PROGRAMMING TECHNIQUES)

NmNm hhcc 20082008--20092009

Ging vin: PGS. Hunh Quyt Thng

BM Cng ngh phn mmKhoa CNTT, HBK HN


2/74

(c) PGS. Hunh Quyt Thng, BM CNPM, KhoaCNTT,HBK HN, 2007. Email: thanghq@it- 2

Chng 5. Ngn ng m hnh ha UML

1. Tng quan2. Cc thnh phn ca ngn ng m hnh ha UML

3. Cc biu ca UML4. S dng UML trong LTHT5. Cu hi bi tp chng 5


3/74

(c) PGS. Hunh Quyt Thng, BM CNPM, KhoaCNTT,HBK HN, 2007. Email: thanghq@it-

5.1. Tng quan

What Is the UML: UML is a family of graphical notations, backed by single meta-

model, that help in describing and designing software

systems, particularly software systems built using the object-oriented (OO) style.

The UML is a relatively open standard, controlled by theObject Management Group (OMG), an open consortium of

companies The UML was born out of the unification of the many object-oriented graphical modeling languages that thrived in the late1980s and early 1990s

3


4/74


5.1. Tng quan

Three modes for using the UML: sketch, blueprint, andprogramming language In using UML as sketch, developers use the UML to help

communicate some aspects of a system. As with blueprints, you can use sketches in a forward-

engineering or reverse-engineering direction. Forwardengineering draws a UML diagram before you write code,

while reverse engineering builds a UML diagram from existingcode in order to help understand it. In many software tools, developers can use the UML as

programming languauge. Developers draw UML diagrams thatare compiled directly to executable code, and the UMLbecomes the source code. Obviously, this usage of UMLdemands particularly sophisticated tooling.

4


5/74


5.1. Tng quan

UML Diagrams UML 2 describes 13 official diagram types: Activity, Class,

Communication, Component, Composite structure,

Deployment, Interaction overview, Object, Package,Sequence, State machine, Timing, Use case

5


6/74


5.1. Tng quan

UML Diagrams

6


7/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams A class diagram describes the types of objects in the system

and the various kinds of static relationships that exist among

them. Class diagrams also show the properties and operations of a

class and the constraints that apply to the way objects areconnected.

The UML uses the term feature as a general term that coversproperties and operations of a class Properties represent structural features of a class. As a first

approximation, you can think of properties as corresponding tofields in a class. The reality is rather involved, as we shall see,but that's a reasonable place to start.

7


8/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams Properties are a single concept, but they appear in two quite

distinct notations: attributes and associations. Although they

look quite different on a diagram, they are really the samething.

The attribute notation describes a property as a line of textwithin the class box itself. The full form of an attribute is:

visibility name: type multiplicity = default {property-string} This visibility marker indicates whether the attribute is public (+)or private (-);

The name of the attributehow the class refers to the attribute The type of the attribute indicates a restriction on what kind of

object may be placed in the attribute The default value is the value for a newly created object The {property-string} allows you to indicate additional properties

for the attribute

8


9/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams

9


10/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams Associations

The other way to notate a property is as an association

An association is a solid line between two classes, directed fromthe source class to the target class.

10


11/74


12/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams Notes and Comments:

Notes are comments in the diagrams. Notes can stand on theirown, or they can be linked with a dashed line to the elementsthey are commenting

12


13/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams Bidirectional Associations:

A bidirectional association is a pair of properties that are linkedtogether as inverses

13


14/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams Dependency

A dependency exists between two elements if changes to thedefinition of one element (the supplier) may cause changes to theother (the client).

With classes, dependencies exist for various reasons: One classsends a message to another; one class has another as part of itsdata; one class mentions another as a parameter to an operation.

If a class changes its interface, any message sent to that classmay no longer be valid.

14


15/74


5.3. Cc biu ca UML


15


16/74


5.3. Cc biu ca UML


call: The source calls an operation in the target

create:The source creates instances of the target derive:The source is derived from the target instantiate:The source is an instance of the target. permit:The target allows the source to access the target's

private features.

realize:The source is an implementation of a specification orinterface defined by the target

refine: Refinement indicates a relationship between differentsemantic levels; for example, the source might be a design class

and the target the corresponding analysis class substitute:The source is substitutable for the target trace: Used to track such things as requirements to classes or

how changes in one model link to changes elsewhere use:The source requires the target for its implementation

16


17/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams Aggregation and Composition

Aggregation is the part-of relationship. It's like saying that a carhas an engine and wheels as its parts As well as aggregation, the UML has the more defined propertyof composition. The general rule is that, although a class may bea component of many other classes, any instance must be acomponent of only one owner

17


18/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams Interfaces and Abstract Classes

An abstract class is a class that cannot be directly instantiated.Instead, you instantiate an instance of a subclass. Typically, anabstract class has one or more operations that are abstract. Anabstract operation has no implementation; it is pure declarationso that clients can bind to the abstract class.

Classes have two kinds of relationships with interfaces: providingand requiring. A class provides an interface if it is substitutablefor the interface

Class requires an interface if it needs an instance of that interfacein order to work. Essentially, this is having a dependency on theinterface

18


19/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams Interfaces and Abstract Classes

19


20/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams Interfaces and Abstract Classes:

ArrayList implements List and Collection. Order requires a Listinterface

20


21/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams Qualified Associations

A qualified association is the UML equivalent of a programmingconcept variously known as associative arrays, maps, hashes,and dictionaries

Example: The qualifier says that in connection with an Order,there may be one Order Line for each instance of Product

21


22/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams Association Class

Association classes allow you to add attributes, operations, andother features to associations

22


23/74


5.3. Cc biu ca UML

5.3.1. Class Diagrams Template (Parameterized) Class

Several languages, most noticeably C++, have the notion of aparameterized class, or template.

23


24/74


5.3. Cc biu ca UML

5.3.2. Sequence Diagrams Interaction diagrams describe how groups of objects

collaborate in some behavior. The UML defines several forms

of interaction diagram, of which the most common is thesequence diagram A sequence diagram captures the behavior of a single

scenario. The diagram shows a number of example objectsand the messages that are passed between these objectswithin the use case.

24


25/74


5.3. Cc biu ca UML

5.3.2. Sequence Diagrams

25


26/74


5.3. Cc biu ca UML

5.3.2. Sequence Diagrams Creating and Deleting Participants

Sequence diagrams show some extra notation for creating anddeleting participants To create a participant, you draw the message arrow directly intothe participant box

A message name is optional here if you are using a constructor,but I usually mark it with "new" in any case. If the participant

immediately does something once it's created, such as the querycommand, you start an activation right after the participant box.

Deletion of a participant is indicated by big X. A message arrowgoing into the X indicates one participant explicitly deletinganother; an X at the end of a lifeline shows a participant deleting

itself.

26


27/74


5.3. Cc biu ca UML

5.3.2. Sequence Diagrams Creating and Deleting Participants

27


28/74


5.3. Cc biu ca UML

5.3.2. Sequence Diagrams Loops, Conditionals, and the Like:

A common issue with sequence diagrams is how to show loopingand conditional behavior.

28


29/74


5.3. Cc biu ca UML


foreach (lineitem)

if (product.value > $10K)careful.dispatchelseregular.dispatchend ifend forif (needsConfirmation)messenger.confirm

29


30/74


5.3. Cc biu ca UML


alt: Alternative multiple fragments; only the one whose conditionis true will execute opt: Optional; the fragment executes only if the supplied conditionis true. Equivalent to an alt with only one trace.

par: Parallel: each fragment is run in parallel. loop: Loop; the fragment may execute multiple times, and the

guard indicates the basis of iteration. region: Critical region; the fragment can have only one thread

executing it at once. neg: Negative; the fragment shows an invalid interaction.

ref: Reference; refers to an interaction defined on anotherdiagram. The frame is drawn to cover the lifelines involved in theinteraction. You can define parameters and a return value.

sd: Sequence diagram; used to surround an entire sequencediagram, if you wish.

30


31/74


5.3. Cc biu ca UML

5.3.2. Sequence Diagrams Synchronous and Asynchronous Calls

If a caller sends a synchronous message, it must wait until themessage is done, such as invoking a subroutine. If a caller sendsan asynchronous message, it can continue processing anddoesn't have to wait for a response.

You see asynchronous calls in multithreaded applications and inmessage-oriented middleware. Asynchrony gives better

responsiveness and reduces the temporal coupling but is harderto debug

31


32/74


5.3. Cc biu ca UML

5.3.2. Sequence Diagrams Synchronous and Asynchronous Calls

32


33/74


5.3. Cc biu ca UML

5.3.3. Object Diagrams An object diagram is a snapshot of the objects in a system at a

point in time. Because it shows instances rather than classes,

an object diagram is often called an instance diagram Object diagrams are useful for showing examples of objectsconnected together. In many situations, you can define astructure precisely with a class diagram, but the structure isstill difficult to understand. In these situations, a couple ofobject diagram examples can make all the difference.

33


34/74


5.3. Cc biu ca UML

5.3.3. Object Diagrams

34


35/74


5.3. Cc biu ca UML

5.3.4. Package Diagram A package is a grouping construct that allows you to take any

construct in the UML and group its elements together into

higher-level units Each package represents a namespace, which means thatevery class must have a unique name within its owningpackage

35


36/74


5.3. Cc biu ca UML

5.3.4. Package Diagram Package diagram for an enterprise application

36


37/74


5.3. Cc biu ca UML

5.3.5. Deployment Diagrams Deployment diagrams show a system's physical layout,

revealing which pieces of software run on what pieces of

hardware. node is something that can host some software. Nodes comein two forms. A device is hardware, it may be a computer or asimpler piece of hardware connected to a system. Anexecution environment is software that itself hosts or containsother software, examples are an operating system or acontainer process.

The nodes contain artifacts, which are the physicalmanifestations of software: usually, files. These files might be

executables (such as .exe files, binaries, DLLs, JAR files,assemblies, or scripts), or data files, configuration files, HTMLdocuments, and so on. Listing an artifact within a node showsthat the artifact is deployed to that node in the running system.

37


38/74


5.3. Cc biu ca UML

5.3.5. Deployment Diagrams

38


39/74


5.3. Cc biu ca UML

5.3.5. Use-case Diagrams Use cases are a technique for capturing the functional

requirements of a system. Use cases work by describing the

typical interactions between the users of a system and thesystem itself, providing a narrative of how a system is used A scenario is a sequence of steps describing an interaction

between a user and a system A use case is a set of scenarios tied together by a common

user goal An actor is a role that a user plays with respect to the system

39


40/74


5.3. Cc biu ca UML

5.3.5. Use-case Diagrams Content of a Use Case

There is no standard way to write the content of a use case,and different formats work well in different cases Picking one of the scenarios as the main success scenario

As well as the steps in the scenarios, you can add some othercommon information to a use case

A pre-condition describes what the system should ensure is truebefore the system allows the use case to begin. This is useful fortelling the programmers what conditions they don't have to checkfor in their code.

A guarantee describes what the system will ensure at the end ofthe use case. Success guarantees hold after a successfulscenario; minimal guarantees hold after any scenario.

A trigger specifies the event that gets the use case started

40


41/74


5.3. Cc biu ca UML

5.3.5. Use-case Diagrams Use Case Diagrams

41


42/74


5.3. Cc biu ca UML

5.3.6. State Machine Diagrams State machine diagrams are a familiar technique to describe

the behavior of a system.

State diagrams are good at describing the behavior of anobject across several use cases

If you do use state diagrams, don't try to draw them forevery class in the system

State diagrams are not very good at describing behaviorthat involves a number of objects collaborating. As such, it isuseful to combine state diagrams with other techniques

42


43/74


5.3. Cc biu ca UML

5.3.6. State Machine Diagrams State machine diagrams are a familiar technique to describe

the behavior of a system.

43


44/74


5.3. Cc biu ca UML

5.3.6. State Machine Diagrams Internal Activities: States can react to events without

transition, using internal activities: putting the event, guard,

and activity inside the state box itself.

44


45/74


5.3. Cc biu ca UML

5.3.6. State Machine Diagrams Activity States: activity state: The ongoing activity is marked

with the do/; hence the term do-activity

45


46/74


5.3. Cc biu ca UML

5.3.6. State Machine Diagrams Superstates: several states share common transitions and

internal activities

46


47/74


5.3. Cc biu ca UML

5.3.6. State Machine Diagrams Concurrent States: States can be broken into several

orthogonal state diagrams that run concurrently

47


48/74


5.3. Cc biu ca UML

5.3.6. State Machine Diagrams Implementing State Diagrams: A state diagram can be

implemented in three main ways: nested switch, the State

pattern, and state tables.

48


49/74


5.3. Cc biu ca UML

5.3.6. State Machine Diagrams Implementing State Diagrams: A state diagram can be

implemented in three main ways: nested switch, the State

pattern, and state tables.

49


50/74


5.3. Cc biu ca UML

5.3.7. Activity Diagrams Activity diagrams are a technique to describe procedural

logic, business process, and work flow.

In many ways, they play a role similar to flowcharts, but theprincipal difference between them and flowchart notation isthat they support parallel behavior.

The main strength of doing this may come with people using

UML as a programming language. In this case, activitydiagrams represent an important technique to representbehavioral logic

50


51/74


5.3. Cc biu ca UML

5.3.7. Activity Diagrams

51


52/74


53/74


5.3. Cc biu ca UML

5.3.7. Activity Diagrams Partitions: Activity diagrams tell you what happens, but they

do not tell you who does what. In programming, this means

that the diagram does not convey which class is responsiblefor each action. In business process modeling, this does notconvey which part of an organization carries out whichaction. This isn't necessarily a problem; often, it makes

sense to concentrate on what gets done rather than on whodoes what parts of the behavior.

53


54/74


5.3. Cc biu ca UML


54

5 3 C bi UML


55/74


5.3. Cc biu ca UML

5.3.7. Activity Diagrams A time signal occurs because of the passage of time. Such

signals might indicate the end of a month in a financial

period or each microsecond in a real-time controller

55

5 3 C bi UML


56/74


5.3. Cc biu ca UML

5.3.7. Activity Diagrams Time signal

56

5 3 C bi UML


57/74


5.3. Cc biu ca UML

5.3.7. Activity Diagrams Tokens: Tokens can visualized with coins or counters

moving across the diagram

UML 2 uses the terms flow and edge synonymously todescribe the connections between two actions. The simplestkind of edge is the simple arrow between two actions. Youcan give an edge a name if you like, but most of the time, a

simple arrow will suffice Pins and Transformations: Actions can have parameters,

just as methods do. You don't need to show informationabout parameters on the activity diagram, but if you wish,

you can show them with pins. If you're decomposing anaction, pins correspond to the parameter boxes on thedecomposed diagram

57

5 3 Cc biu ca UML


58/74


5.3. Cc biu ca UML


58

5 3 Cc biu ca UML


59/74


5.3. Cc biu ca UML


59

5 3 Cc biu ca UML


60/74


5.3. Cc biu ca UML

5.3.7. Activity Diagrams Expansion Regions: An expansion region marks an activity

diagram area where actions occur once for each item in a

collection.

60

5 3 Cc biu ca UML


61/74


5.3. Cc biu ca UML

5.3.7. Activity Diagrams Flow Final: Once you get multiple tokens, as in an

expansion region, you often get flows that stop even when

the activity as a whole doesn't end. A flow final indicates theend of one particular flow, without terminating the wholeactivity.

61

5 3 Cc biu ca UML


62/74


5.3. Cc biu ca UML


62

5 3 Cc biu ca UML


63/74


5.3. Cc biu ca UML

5.3.7. Activity Diagrams Join Specifications: A join specification is a Boolean

expression attached to a join. Each time a token arrives at

the join, the join specification is evaluated and if true, anoutput token is emitted

63

5.3. Cc biu ca UML


64/74


5.3. Cc biu ca UML

5.3.8. Communication diagrams Kind of interaction diagram, emphasize the data links

between the various participants in the interaction

The communication diagram allows free placement ofparticipants, allows you to draw links to show how theparticipants connect, and use numbering to show thesequence of messages

64

5.3. Cc biu ca UML


65/74


5.3. Cc biu ca UML

5.3.8. Communication diagrams

65

5.3. Cc biu ca UML


66/74


5 3 Cc b u c a U

5.3.8. Composite Structures One of the most significant new features in UML 2 is the

ability to hierarchically decompose a class into an internal

structure. This allows you to take a complex object andbreak it down into parts

66

5.3. Cc biu ca UML


67/74


5.3.8. Composite Structures

67

5.3. Cc biu ca UML


68/74


5.3.9. Component Diagrams

68

5.3. Cc biu ca UML


69/74


5.3.9. Collaborations

69

5.3. Cc biu ca UML


70/74


5.3.9. Interaction Overview Diagrams

70

5.3. Cc biu ca UML


71/74


5.3.9. Interaction Overview Diagrams Interaction overview diagrams are a grafting together of

activity diagrams and sequence diagrams.

You can think of interaction overview diagrams either asactivity diagrams in which the activities are replaced by littlesequence diagrams, or as a sequence diagram broken upwith activity diagram notation used to show control flow.

71

5.3. Cc biu ca UML


72/74


5.3.10. Timing Diagrams Timing diagrams are another form of interaction diagram,

where the focus is on timing constraints: either for a single

object or, more usefully, for a bunch of objects.

72

5.4. S dng UML trong LTHT


73/74


S dng thnh tho cc biu : Use-Case Class-Diagrams

Object-Diagrams Sequence, Collaboration, Communication, Timming Diagrams Activity, State Machine Diagrams

ng dng hiu qu vo bi tp ln v th hin cc chc k

thut trong LTHT So snh cc biu vi cc Tools chun trong cc cng clp trnh

73

5.5. Cu hi bi tp, ti liu s dng


74/74


Mt s ti liu s dng hay v UML: http://martinfowler.com/articles/newMethodology.html Martin Fowler. UML Distilled: A Brief Guide to the Standard

Object Modeling Language, Third Edition, Addison WesleyPublisher, 2003, 208 Pages

Bi tp Lm bi tp trong file pdf km theo

74

Documents

UML Slides K50