UML Slides K50

LP TRNH HNG I TNG
(OBJECT-ORIENTED PROGRAMMING TECHNIQUES)
Nm hc 2008-2009
Ging vin: PGS. Hunh Quyt Thng BM Cng ngh phn mm Khoa CNTT, HBK HN
1
Chng 5. Ngn ng m hnh ha UML

1. 2. 3. 4. 5.
Tng quan Cc thnh phn ca ngn ng m hnh ha UML Cc biu ca UML S dng UML trong LTHT Cu hi bi tp chng 5
(c) PGS. Hunh Quyt Thng, BM CNPM, KhoaCNTT, HBK HN, 2007. Email: thanghq@ithut edu vn
5.1. Tng quan What Is the UML:
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 objectoriented (OO) style. The UML is a relatively open standard, controlled by the Object Management Group (OMG), an open consortium of companies The UML was born out of the unification of the many objectoriented graphical modeling languages that thrived in the late 1980s and early 1990s
5.1. Tng quan Three modes for using the UML: sketch, blueprint, and programming 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 forwardengineering or reverse-engineering direction. Forward engineering draws a UML diagram before you write code, while reverse engineering builds a UML diagram from existing code in order to help understand it. In many software tools, developers can use the UML as programming languauge. Developers draw UML diagrams that are compiled directly to executable code, and the UML becomes the source code. Obviously, this usage of UML demands particularly sophisticated tooling.
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.1. Tng quan UML Diagrams
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 are connected. The UML uses the term feature as a general term that covers properties and operations of a class Properties represent structural features of a class. As a first approximation, you can think of properties as corresponding to fields in a class. The reality is rather involved, as we shall see, but that's a reasonable place to start.
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 same thing. The attribute notation describes a property as a line of text within 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
Associations
The other way to notate a property is as an association An association is a solid line between two classes, directed from
the source class to the target class.
10
Operations: Operations are the actions that a class knows to ca out. Operations most obviously correspond to the methods on a class
visibility name (parameter-list) : return-type {property-string} This visibility marker is public (+) or private (-); The name is a string. The parameter-list is the list of parameters for the operation. The return-type is the type of the returned value, if there is one. The property-string indicates property values that apply to the
given operation.
11
Notes and Comments:
Notes are comments in the diagrams. Notes can stand on their

own, or they can be linked with a dashed line to the elements they are commenting
12
Bidirectional Associations:
together as inverses
A bidirectional association is a pair of properties that are linked
13
Dependency
dependency exists between two elements if changes to the definition of one element (the supplier) may cause changes to the other (the client). With classes, dependencies exist for various reasons: One class sends a message to another; one class has another as part of its data; one class mentions another as a parameter to an operation. If a class changes its interface, any message sent to that class may no longer be valid.
14
Dependency
15
Dependency
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
private features. realize:The source is an implementation of a specification or interface defined by the target refine: Refinement indicates a relationship between different semantic 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
the target's
16
Aggregation and Composition
Aggregation is the part-of relationship. It's like saying that a car

has an engine and wheels as its parts As well as aggregation, the UML has the more defined property of composition. The general rule is that, although a class may be a component of many other classes, any instance must be a component of only one owner
17
Interfaces and Abstract Classes
An abstract class is a class that cannot be directly instantiated.
Instead, you instantiate an instance of a subclass. Typically, an abstract class has one or more operations that are abstract. An abstract operation has no implementation; it is pure declaration so that clients can bind to the abstract class. Classes have two kinds of relationships with interfaces: providing and requiring. A class provides an interface if it is substitutable for the interface Class requires an interface if it needs an instance of that interface in order to work. Essentially, this is having a dependency on the interface
18
Interfaces and Abstract Classes
19
Interfaces and Abstract Classes:
ArrayList
interface
implements List and Collection. Order requires a List
20
Qualified Associations
A qualified association is the UML equivalent of a programming
concept 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
Association Class
Association classes allow you to add attributes, operations, and

other features to associations
22
Template (Parameterized) Class
Several
languages, most noticeably C++, have the notion of a parameterized class, or template.
23
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 the sequence diagram A sequence diagram captures the behavior of a single scenario. The diagram shows a number of example objects and the messages that are passed between these objects within the use case.
24
25
Creating and Deleting Participants
Sequence diagrams show some extra notation for creating and
deleting participants To create a participant, you draw the message arrow directly into the 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 query command, you start an activation right after the participant box. Deletion of a participant is indicated by big X. A message arrow going into the X indicates one participant explicitly deleting another; an X at the end of a lifeline shows a participant deleting itself.
26
Creating and Deleting Participants
27
Loops, Conditionals, and the Like:

and conditional behavior.
A common issue with sequence diagrams is how to show looping
28

foreach (lineitem) if (product.value > $10K) careful.dispatch else regular.dispatch end if end for if (needsConfirmation) messenger.confirm
29
alt: Alternative multiple fragments; only the one whose condition
is true will execute opt: Optional; the fragment executes only if the supplied condition is 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 another diagram. The frame is drawn to cover the lifelines involved in the interaction. You can define parameters and a return value. sd: Sequence diagram; used to surround an entire sequence diagram, if you wish.
30
Synchronous and Asynchronous Calls
If a caller sends a synchronous message, it must wait until the
message is done, such as invoking a subroutine. If a caller sends an asynchronous message, it can continue processing and doesn't have to wait for a response. You see asynchronous calls in multithreaded applications and in message-oriented middleware. Asynchrony gives better responsiveness and reduces the temporal coupling but is harder to debug
31
Synchronous and Asynchronous Calls
32
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 objects connected together. In many situations, you can define a structure precisely with a class diagram, but the structure is still difficult to understand. In these situations, a couple of object diagram examples can make all the difference.
33
5.3. Cc biu ca UML 5.3.3. Object Diagrams
34
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 that every class must have a unique name within its owning package
35
5.3. Cc biu ca UML 5.3.4. Package Diagram Package diagram for an enterprise application
36
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 come in two forms. A device is hardware, it may be a computer or a simpler piece of hardware connected to a system. An execution environment is software that itself hosts or contains other software, examples are an operating system or a container process. The nodes contain artifacts, which are the physical manifestations 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, HTML documents, and so on. Listing an artifact within a node shows that the artifact is deployed to that node in the running system.
37
5.3. Cc biu ca UML 5.3.5. Deployment Diagrams
38
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 the system 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
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 other common information to a use case
A pre-condition describes what the system should ensure is true
before the system allows the use case to begin. This is useful for telling the programmers what conditions they don't have to check for in their code. A guarantee describes what the system will ensure at the end of the use case. Success guarantees hold after a successful scenario; minimal guarantees hold after any scenario. A trigger specifies the event that gets the use case started
40
5.3. Cc biu ca UML 5.3.5. Use-case Diagrams Use Case Diagrams
41
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 an object across several use cases If you do use state diagrams, don't try to draw them for every class in the system State diagrams are not very good at describing behavior that involves a number of objects collaborating. As such, it is useful to combine state diagrams with other techniques
42
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
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
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
5.3. Cc biu ca UML 5.3.6. State Machine Diagrams Superstates: several states share common transitions and internal activities
46
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
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
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
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 the principal difference between them and flowchart notation is that they support parallel behavior. The main strength of doing this may come with people using UML as a programming language. In this case, activity diagrams represent an important technique to represent behavioral logic
50
5.3. Cc biu ca UML 5.3.7. Activity Diagrams
51
5.3. Cc biu ca UML 5.3.7. Activity Diagrams Decomposing an Action: Actions can be decomposed into subactivities
52
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 responsible for each action. In business process modeling, this does not convey which part of an organization carries out which action. This isn't necessarily a problem; often, it makes sense to concentrate on what gets done rather than on who does what parts of the behavior.
53
54
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. Cc biu ca UML 5.3.7. Activity Diagrams Time signal
56
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 to describe the connections between two actions. The simplest kind of edge is the simple arrow between two actions. You can 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 information about parameters on the activity diagram, but if you wish, you can show them with pins. If you're decomposing an action, pins correspond to the parameter boxes on the decomposed diagram
57
58
59
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 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 the end of one particular flow, without terminating the whole activity.
61
62
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, an output token is emitted
63
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 of participants, allows you to draw links to show how the participants connect, and use numbering to show the sequence of messages
64
5.3. Cc biu ca UML 5.3.8. Communication diagrams
65
5.3. Cc biu ca UML 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 and break it down into parts
66
5.3. Cc biu ca UML 5.3.8. Composite Structures
67
5.3. Cc biu ca UML 5.3.9. Component Diagrams
68
5.3. Cc biu ca UML 5.3.9. Collaborations
69
5.3. Cc biu ca UML 5.3.9. Interaction Overview Diagrams
70
5.3. Cc biu ca UML 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 as activity diagrams in which the activities are replaced by little sequence diagrams, or as a sequence diagram broken up with activity diagram notation used to show control flow.
71
5.3. Cc biu ca UML 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 S dng thnh tho cc biu :
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 c lp trnh
Use-Case Class-Diagrams Object-Diagrams Sequence, Collaboration, Communication, Timming Diagrams Activity, State Machine Diagrams
73
5.5. Cu hi bi tp, ti liu s dng 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 Wesley Publisher, 2003, 208 Pages Lm bi tp trong file pdf km theo
Bi tp
74

UML Slides K50

Загружено:

Сведения о документе

Исходное описание:

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

UML Slides K50

Загружено:

Авторское право:

Доступные форматы

LP TRNH HNG I TNG

(OBJECT-ORIENTED PROGRAMMING TECHNIQUES)

Chng 5. Ngn ng m hnh ha UML

5.1. Tng quan What Is the UML:

5.1. Tng quan UML Diagrams

5.1. Tng quan UML Diagrams

5.3. Cc biu ca UML 5.3.1. Class Diagrams

5.3. Cc biu ca UML 5.3.1. Class Diagrams

5.3. Cc biu ca UML 5.3.1. Class Diagrams

5.3. Cc biu ca UML 5.3.1. Class Diagrams

5.3. Cc biu ca UML 5.3.1. Class Diagrams

5.3. Cc biu ca UML 5.3.1. Class Diagrams

Notes and Comments:

Notes are comments in the diagrams. Notes can stand on their

5.3. Cc biu ca UML 5.3.1. Class Diagrams

A bidirectional association is a pair of properties that are linked

5.3. Cc biu ca UML 5.3.1. Class Diagrams

5.3. Cc biu ca UML 5.3.1. Class Diagrams

5.3. Cc biu ca UML 5.3.1. Class Diagrams

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 car

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.

5.3. Cc biu ca UML 5.3.1. Class Diagrams

Interfaces and Abstract Classes

5.3. Cc biu ca UML 5.3.1. Class Diagrams

Interfaces and Abstract Classes:

implements List and Collection. Order requires a List

5.3. Cc biu ca UML 5.3.1. Class Diagrams

A qualified association is the UML equivalent of a programming

5.3. Cc biu ca UML 5.3.1. Class Diagrams

Association classes allow you to add attributes, operations, and

5.3. Cc biu ca UML 5.3.1. Class Diagrams

Template (Parameterized) Class

5.3. Cc biu ca UML 5.3.2. Sequence Diagrams

5.3. Cc biu ca UML 5.3.2. Sequence Diagrams

5.3. Cc biu ca UML 5.3.2. Sequence Diagrams

Creating and Deleting Participants

Sequence diagrams show some extra notation for creating and

5.3. Cc biu ca UML 5.3.2. Sequence Diagrams

Creating and Deleting Participants

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 looping

5.3. Cc biu ca UML 5.3.2. Sequence Diagrams

Loops, Conditionals, and the Like:

5.3. Cc biu ca UML 5.3.2. Sequence Diagrams

Loops, Conditionals, and the Like:

alt: Alternative multiple fragments; only the one whose condition

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 the

5.3. Cc biu ca UML 5.3.2. Sequence Diagrams

Synchronous and Asynchronous Calls

5.3. Cc biu ca UML 5.3.3. Object Diagrams

5.3. Cc biu ca UML 5.3.3. Object Diagrams

5.3. Cc biu ca UML 5.3.4. Package Diagram

5.3. Cc biu ca UML 5.3.5. Deployment Diagrams

5.3. Cc biu ca UML 5.3.5. Deployment Diagrams

5.3. Cc biu ca UML 5.3.5. Use-case Diagrams

5.3. Cc biu ca UML 5.3.5. Use-case Diagrams Content of a Use Case