UML for OOAD
-
Upload
dang-tuan -
Category
Technology
-
view
2.992 -
download
3
description
Transcript of UML for OOAD
![Page 1: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/1.jpg)
UML for OOAD Stefan Kluth 1
2 UML for OOAD
2.1 What is UML?2.2 Classes in UML2.3 Relations in UML2.4 Static and Dynamic Design with UML
![Page 2: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/2.jpg)
UML for OOAD Stefan Kluth 2
2.1 UML Background
"The Unified Modelling Language (UML) is a graphical language for visualizing, specifying, constructing, anddocumenting the artifacts of a software-intensive system. The UML offers a standard way to write a systems blueprints, including conceptual things like business processes and system functions as well as concrete things such asprogramming language statements, database schemas, andreusable software components."
Grady Booch, Ivar Jacobsen, Jim Rumbaugh Rational Software
[OMG Unified Modelling Language Specification, Version 1.3, March 2000]
![Page 3: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/3.jpg)
UML for OOAD Stefan Kluth 3
2.1 Brief UML History
● Around 1980– first OO modelling languages– other techniques, e.g. SA/SD
● Around 1990– "OO method wars"– many modelling languages
● End of 90's– UML appears as combination of best practices
![Page 4: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/4.jpg)
UML for OOAD Stefan Kluth 4
2.1 Why UML?
● Physicists know formal graphical modelling– Mathematics to describe nature– Feynman graphs to calculate particle reaction rates
● We need a common language– discuss software systems at a black- (white-) board– document software systems– UML is an important part of that language– UML provides the "words and grammar"
![Page 5: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/5.jpg)
UML for OOAD Stefan Kluth 5
2.2 Classes in UML
● Classes describe objects– Interface (member function signature)– Behaviour (member function implementation)– State bookkeeping (values of data members)– Creation and destruction
● Objects described by classes collaborate– Class relations → object relations– Dependencies between classes
![Page 6: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/6.jpg)
UML for OOAD Stefan Kluth 6
2.2 UML ClassClass name
Data members
Instance methods
ArgumentsReturn types
Data members, arguments and methods are specified byvisibility name : type
Class method
![Page 7: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/7.jpg)
UML for OOAD Stefan Kluth 7
2.2 Class Name
The top compartmentcontains the class name
Abstract classes have italicisednamesAbstract methods also haveitalicised names
Stereotypes are used to identifygroups of classes, e.g interfacesor persistent (storeable) classes
![Page 8: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/8.jpg)
UML for OOAD Stefan Kluth 8
2.2 Class AttributesAttributes are the instanceand class data members
Class data members (underlined) are shared between all instances(objects) of a given class
Data types shown after ":"
Visibility shown as+ public- private# protected
Attributecompartment
visibility name : type
![Page 9: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/9.jpg)
UML for OOAD Stefan Kluth 9
2.2 Class Operations (Interface)
Operations are the classmethods with their argumentand return types
Public (+) operations define theclass interface
Class methods (underlined) have only access to class datamembers, no need for a classinstance (object)
Operationscompartment
visibility name : type
![Page 10: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/10.jpg)
UML for OOAD Stefan Kluth 10
2.2 Visibility
+public
Anyone can access
Interface operations
Not data members
-private
No-one can access
Data members
Helper functions
"Friends" are allowdin though
#protected
Subclasses can access
Operations where sub-classes collaborate
Not data members(creates dependencyoff subclass on im-
plementation of parent)
![Page 11: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/11.jpg)
UML for OOAD Stefan Kluth 11
2.2 Template Classes
Generic classes depending on parametrised types
Type parameter(s)
Operations compartmentas usual, but may havetype parameter instead ofconcrete type
![Page 12: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/12.jpg)
UML for OOAD Stefan Kluth 12
2.3 Relations
● Association● Aggregation● Composition● Parametric and Friendship● Inheritance
![Page 13: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/13.jpg)
UML for OOAD Stefan Kluth 13
2.3 Binary AssociationBinary association: both classes know each other
Usually "knows about" means a pointer or referenceOther methods possible: method argument, tables, database, ...Implies dependency cycle
![Page 14: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/14.jpg)
UML for OOAD Stefan Kluth 14
2.3 Unary Association
A knows about B, but B knows nothing about A
Arrow shows direction of association in direction ofdependency
![Page 15: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/15.jpg)
UML for OOAD Stefan Kluth 15
2.3 AggregationAggregation = Association with "whole-part" relationship
Shown by hollow diamondat the "whole" side
No lifetime control implied
![Page 16: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/16.jpg)
UML for OOAD Stefan Kluth 16
2.3 CompositionComposition = Aggregation with lifetime control
Shown by filled diamondat the "owner" side
Lifetime control implied
Lifetime control can betranferred
Lifetime control: construction anddestruction controlled by "owner"→ call constructors and destructors
(or have somebody else do it)
![Page 17: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/17.jpg)
UML for OOAD Stefan Kluth 17
2.3 Association Details
Name gives details of associationName can be viewed as verb of a sentence
Notes at association endsexplain "roles" of classes (objects)
Multiplicities show number ofobjects which participate in theassociation
![Page 18: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/18.jpg)
UML for OOAD Stefan Kluth 18
2.3 FriendshipFriends are granted access to private data members andmember functionsFriendship is given to other classes, never taken
Bob Martin: More like lovers than friends.You can have many friends,you should not have many lovers
Friendship breaks data hiding, use carefully
![Page 19: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/19.jpg)
UML for OOAD Stefan Kluth 19
2.3 Parametric Association
Association mediated by a parameter (function call argument)
A depends upon B, because it uses BNo data member of type B in A
![Page 20: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/20.jpg)
UML for OOAD Stefan Kluth 20
2.3 Inheritance
Base class or super class
Derived class or subclass
Arrow shows directionof dependency
→ B inherits A's interface, behaviour and data members
→ B can extend A, i.e. add newdata members or member functions
→ B depends on A,A knows nothing about B
![Page 21: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/21.jpg)
UML for OOAD Stefan Kluth 21
2.3 Associations Summary
● Can express different kinds of associations between classes/objects with UML– Association, aggregation, composition, inheritance– Friendship, parametric association
● Can go from simple sketches to more detailed design by adding adornments– Name, roles, multiplicities– lifetime control
![Page 22: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/22.jpg)
UML for OOAD Stefan Kluth 22
2.3 Multiple Inheritance
The derived class inheritsinterface, behaviour anddata members of all itsbase classes
Extension and overridingworks as before
B implements the interface A andis also a "countable" class
Countable also called a "Mixin class"
![Page 23: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/23.jpg)
UML for OOAD Stefan Kluth 23
2.3 Deadly Diamond of Death
Now the @*#! hits the %&$?
Data members of TObject areinherited twice in B, which onesare valid?
Fortunately, there is a solutionto this problem:→ virtual inheritance in C++:
only one copy of a multiplyinherited structure willbe created
(A C++ feature)
![Page 24: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/24.jpg)
UML for OOAD Stefan Kluth 24
2.4 Static and Dynamic Design
● Static design describes code structure and object relations– Class relations– Objects at a given time
● Dynamic design shows communication between objects– Similarity to class relations– can follow sequences of events
![Page 25: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/25.jpg)
UML for OOAD Stefan Kluth 25
2.4 Class Diagram
● Show static relations between classes– we have seen them already– interfaces, data members– associations
● Subdivide into diagrams for specific purpose– showing all classes usually too much– ok to show only relevant class members– set of all diagrams should describe system
![Page 26: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/26.jpg)
UML for OOAD Stefan Kluth 26
2.4 Object Diagram
Object diagram showsrelations at instant in time(snapshot)
Object relations are drawnusing the class associationlines
Class diagramnever changes
![Page 27: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/27.jpg)
UML for OOAD Stefan Kluth 27
2.4 Sequence Diagram
Show sequence of events for a particular use case
Object
Lifeline
Activation
Messageshalf-arrow=asynchronous, full arrow=synchronous, dashed=return
Active object
![Page 28: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/28.jpg)
UML for OOAD Stefan Kluth 28
2.4 Sequence Diagram
Can show creation anddestruction of objects
Destruction mark
![Page 29: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/29.jpg)
UML for OOAD Stefan Kluth 29
2.4 Sequence Diagram
Slanted messages takesome time
Can model real-timesystems
![Page 30: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/30.jpg)
UML for OOAD Stefan Kluth 30
2.4 Sequence Diagram
Crossing message linesare a bad sign
→ race conditions
![Page 31: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/31.jpg)
UML for OOAD Stefan Kluth 31
2.4 Collaboration Diagram
Object diagram withnumbered messages
Sequence numbers of messages are nested by procedure call
![Page 32: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/32.jpg)
UML for OOAD Stefan Kluth 32
2.4 Static and Dynamic Design Summary
● Class diagrams → object diagrams– classes → objects; associations → links
● Dynamic models show how system works– Sequence and collaboration diagram
● There are tools for this process– UML syntax and consistency checks
● Rough sketches by hand or with simple tools– aid in design discussions
![Page 33: UML for OOAD](https://reader036.fdocuments.us/reader036/viewer/2022081413/5482680db4af9f4f6b8b464a/html5/thumbnails/33.jpg)
UML for OOAD Stefan Kluth 33
Some Comments
● Design-heavy development processes– several 10% of person-power/time spent on design
with formal UML from requirements– start coding when the design is consistent– large software houses may work this way
● Lighter processes– a few % of person-power/time spent with UML– UML as a discussion and documentation aid– probably more adequate in HEP