Systems Engineering and Project Management
(Unified Modeling Language) Prof. Dr. Franz Wotawa
Institute for Software Technology [email protected]
Aufbau der UML
KlassendiagrammKomponentendiagrammObjektdiagrammKomposi4onsstrukturdiagrammVerteilungsdiagrammPaketdiagrammProfildiagramm
Ak4vitätsdiagrammAnwendungsfalldiagrammZustandsdiagrammSequenzdiagrammKommunika4onsdiagrammZeitdiagrammInterak4onsübersichtsdiagramm
Struktur-undVerhaltensmodell
Stereo
type
n,M
odell,Inform
a4on
sfluss,
prim
i4veDaten
type
n,Tem
plates,O
bject
ConstraintLanguage(OCL),
Datenaustauschform
ate(XMI)
Struktur Verhalten Sons/ges
Diagramm
Mod
ell
UMLImplementa4on
Sinn und Zweck von UML • Darstellung von Systemen und ihrer
Bestandteile • Verschiedene Sichtweisen auf das System durch
verschiedene Diagramme • Reduktion der Komplexität durch Zerlegung in
Teilsysteme und schrittweise Verfeinerungen • Bereitstellung einer Diskussionsbasis mit
Kunden (Use Cases) und Entwicklern • Definierte Semantik der Diagramme
UMLImplementa4on
Hinweise
• Es ist nicht erforderlich ein System mit Hilfe aller möglichen Diagrammtypen zu beschreiben.
• Diagramme sind auf ihre Sinnhaftigkeit zu überprüfen!
• Fast immer sinnvoll: – Use Cases – Klassendiagramme
UMLClassDiagrams 6
Grundlegende Begriffe • Objekt
„A discrete entity with a well-defined boundary that encapsulates state and behavior; an instance of a class“ [UML Reference Manual (Rumbaugh)]
• Eigenschaften – Kombination von Daten und Funktionen (Operationen
(Analyse), Methoden (Design)) – Data Hiding (durch Funktionen) – Jedes Objekt ist eindeutig (unique) – Attribute speichern die Objektdaten
UMLClassDiagrams 7
Kapselung (Encapsulation) • Der Objektzustand wird durch die Objektattribute
definiert und kann nur durch Objektfunktionen verändert werden.
• Das Objektverhalten ist durch die Objektfunktionen definiert
„ThomasMann“MNR03846789
KNZ173
setKennzahl()
addKennzahl()
changeName()
UMLClassDiagrams 8
Systemverhalten • Das Systemverhalten wird durch die Objekte
mittels Senden von Nachrichten (Messages) generiert. Das Senden geschieht über Links zwischen Objekten. [Kollaboration]
Prüfungsabteilung Studentendaten
addPrüfung(20030120,“Informa4k“,1)
UMLClassDiagrams 9
UML Objektdarstellung
name:String=„ThomasMann“matrNr:Integer=03846789kennzahl:Integer=173
mannDaten:Studentendaten
objectname classname
namecompartment
abributecompartment
abributename
abributetype
abributevalue
UMLClassDiagrams 10
Klassen • Eine Klasse beschreibt das Verhalten
einer Menge von Objekten „The descriptor for a set of objects that share the same attributes, operations, methods, relationships, and behavior“
• Jedes Objekt ist Instanz einer Klasse • Das richtige Klassifikationsschema ist ein
Schlüssel zu einer erfolgreichen OO-Analyse
UMLClassDiagrams 11
Beziehung Klassen - Objekte
name:String=„ThomasMann“matrNr:Integer=03846789kennzahl:Integer=173
mannDaten:Studentendaten
name:String=„HermannHesse“matrNr:Integer=0301234kennzahl:Integer=140
hesseDaten:Studentendaten
name:StringmatrNr:Integerkennzahl:Integer
Studentendaten
addPrüfung()changeName()
<<instan4ate>><<instan4ate>>
Class
Objects
UMLClassDiagrams 12
Beziehungen (Relationships) • Verbindung zwischen Dingen (Things)
„A connection between modeling elements.“ • Dependency Relation
„Änderung des Suppliers hat eine Auswirkung auf den Client.“
• Objektinstanzierung erzeugt ein neues Objekt unter Verwendung seiner Klasse als Template
<<instan4ate>>DependencyRela4onStereotype
UMLClassDiagrams 13
UML Klassendarstellung
+name:String+matrNr:Integer=0+kennzahl:Integer=0-currentMatrNr=0
Studentendaten
visibilityadornment
classname
namecompartment
abributecompartment
classscope(underlined)
ini4alvalue
taggedvalues
+create()+addPrüfung()+changeName()-addStudent()
opera4oncompartment
{author=wotawa,status=untested}
UMLClassDiagrams 14
Name Compartment • In der UML gibt es keine Namenskonventionen! • Gute Namen folgen 2 Prinzipien:
– Klassennamen beginnen mit einem Großbuchstaben und haben danach Groß- und Kleinbuchstaben. Großbuchstaben werden dabei nur am Beginn von Wörtern verwendet.
– Verwenden Sie keine Abkürzungen!
• Beispiele: StudentRecord, Account,.. aber nicht StdRec oder Acnt!
UMLClassDiagrams 15
Attribute Compartment • Folgende Form
visibility name multiplicity : type = initialValue
• Visibility
• Multiplicity zur Modellierung von Null (Nil) oder Arrays address[3]: String emailAddress[0..1]: String
+ Public Alle
- Private Nur die Klasse
# Protected Die Klasse und ihre Unterklassen ~ Package Alle im selben Package
UMLClassDiagrams 16
Operation Compartment • Funktion ist durch
– Name – Parameterliste – Return-Typ
(Signatur) definiert. visibility name (parameterName: parameterType,...) : returnType
• Beispiel: +add(argument: Integer): Integer
UMLClassDiagrams 17
Scope • Wir unterscheiden 2 Arten:
– Instance Scope Attribute und Operationen, die für spezifische Objekte verfügbar sind.
– Class Scope Attribute und Operationen, die für eine Klasse gültig sind.
• Beispiel: add ist für jedes Objekt (von Integer definiert). Eine Methode, die ein neues Objekt instantiert (create()), ist für die Klasse definiert.
UMLClassDiagrams 18
Object Construction and Destruction
• Konstruktoren sind spezielle Methoden (auf Klassenseite), die ein neues Objekt einer Klasse erzeugen. BankAccount() create()
• Destruktoren sind spezielle Methoden, die aufgerufen werden, wenn ein Objekt nicht mehr gebraucht wird. ~BankAccount() finalize()
UMLClassDiagrams 19
Relationen (Relationship)
• Beziehungen zwischen Dingen in UML • Verbinden Dinge miteinander • Beispiele:
– Zwischen Actor und Use Case (Association) – Zwischen Use Case und Use Case
(Generalization, <<include>>,<<extend>>) – Zwischen Actor und Actor (Generalization)
UMLClassDiagrams 20
Links und Object Diagrams
• Objekte kommunizieren (durch das Senden von Messages) über Links. Links sind Verbindungen zwischen Objekten.
• Object Diagrams beschreiben den Zustand von Objekten und deren Beziehungen zu einem bestimmten Zeitpunkt.
UMLClassDiagrams 21
Beispiel - Links
2:Integer
IneinerMethodemdesObjektsOsteht2+3
add(3:Integer)
5:IntegerO
1. Die Methode add mit Parameter 3:Integer wird an das Objekt 2:Integer geschickt
2. Der Return-Wert wird zurück an O geschickt.
UMLClassDiagrams 22
Beispiel - Object Diagram
downHillSkiClub:Club
jim:Person
marie:Person
ann:Person
chairman
secretary
member
rolename
bidirec4onallink
Snapshotofanexecu4ngOOsystem
UMLClassDiagrams 23
Associations
• Associations sind Verbindungen zwischen Klassen.
• Links hängen von Associations ab.
Club Person
downhillSkiClub:Club jim:Personchairman
<<instantiate>> <<instantiate>> <<instantiate>>
associa4on
link
UMLClassDiagrams 24
UML Syntax von Associations
• Eine Association wird durch eine Linie zwischen Klassen dargestellt und kann zusätzlich folgende Angaben beinhalten: – Name – Rollennamen – Multiplicity – Navigability
UMLClassDiagrams 25
Beispiel
Company Person1 *
employs!employer employee
mul4plicity
associa4onname
navigability
rolename
Acompanyemploysmanypersons
APersonworksforonecompany
Anmerkung:NormalerweisewerdenentwederRollenspezifiziertodereswirdeinAssocia4onNamevergeben.Nichtbeides!
UMLClassDiagrams 26
Multiplicity • Wenn nicht festgelegt, so ist sie noch nicht
entschieden
• UML Diagramme müssen exakt so gelesen werden, wie sie gezeichnet wurden!
0..1 0 oder 1 1..* 1 oder mehr 1 Genau 1 1..6 1 bis 6
0..* 0 oder mehr 1..3,7..10,15,17,*
1-3,7-10, 15,17 oder mehr * 0 oder mehr
UMLClassDiagrams 27
Darstellung von Hierarchien
a:A
c2:Ac1:A
b2:Ab1:A b3:AA
0..1
0..*
ReflexiveAssocia4on
UMLClassDiagrams 28
Darstellung von Netzwerken
a:A
c2:Ac1:A
b2:Ab1:A b3:AA
0..*
0..*
ReflexiveAssocia4on
UMLClassDiagrams 29
Anmerkung zur Navigability
• Navigability zeigt wie man von einer Klasse zur anderen kommen kann.
• „Messages can only be sent in the direction of the arrow“ (Source -> Target)
• Beispiel: Order Objekte können Daten zu Product Objekten schicken (aber nicht umgekehrt)
UMLClassDiagrams 30
Sinn von Navigability
• Minimierung der Klassenkopplung
Order Product* *
Naviga4onsrichtungAnmerkung:ProduktespeichernkeineListevonObjektenderKlasseOrder
IngutenOO-DesignssolldieAnzahlderKlassenkopplungenminimiertsein.
UMLClassDiagrams 31
Associations und Attribute
• Wenn es eine Association zwischen einer Source- und einer Target-Klasse gibt, so heißt das, daß die Source-Klasse ein Objekt der Target-Klasse speichern kann.
• Wird bei Code-Generierung automatisch durchgeführt!
House Address1 1address
House
address:Address
UMLClassDiagrams 32
Association Klasse
• Bei Many-to-Many Beziehungen treten Probleme auf, die durch eine eigene Klasse gelöst werden können.
Company Person* *
Problem:WowirddasGehaltgespeichert?
GehaltistEigenscharderAssozia4on!
UMLClassDiagrams 33
Association Klassen 2
Company Person* *
Job
salary:Double
EineAssocia/onClassisteineAssocia4on,dieaucheineKlasseist!
Seman4k:EsgibtnureinLinkzwischenzweiObjektenzujederbeliebigenZeit!
UMLClassDiagrams 34
Reified Association
ImUnterschiedzurAssocia4onKlasseerlaubtdiewirklicheEinführungeinerKlassebeliebigvieleLinkszwischen2Objekten.
Company Person* *Job
salary:Double
1 1
EinePersonkannnunauchineinerFirmamehrmalsangestelltsein!
UMLClassDiagrams 35
Inheritance (Vererbung)
• Klassenhierarchien aufbauend auf Generalization.
• Generalization ist eine Beziehung zwischen einem spezielleren und einem generelleren Ding.
Shape
Square
UMLClassDiagrams 36
Klassenhierarchien
• Generalisierung von spezialisierten Dingen
• Spezialisieren von generelleren Dingen
Square
Rectangle Square
Rectangle
ODER?
UMLClassDiagrams 37
Vererbung • Subklassen erben alle Features von der
Superklasse – Attributes – Operations – Relationships – Constraints
• Die Features können in der Subklasse überschrieben werden. – Operation mit selber Signatur einführen
UMLClassDiagrams 38
Abstrakte Klassen
• Stellen ein „Interface“ zur Verfügung • Haben keine konkrete Implementierung für
zumindest eine Operation. • Die implementierte Funktionalität ist bei
den Subklassen. • Können nicht instantiiert werden.
UMLClassDiagrams 39
Hinweise
• Dinge auf der selben (graphischen) Abstraktionsebene sollen auch die selbe Abstraktion darstellen.
• Beispiel: (schlecht)
Vehicle
VWPolo Truck
UMLClassDiagrams 40
Polymorphismus
• Eine polymorphe Operation hat viele Implementierungen.
Shape
draw(g:Graphics)
Square
draw(g:Graphics)
Circle
draw(g:Graphics)
KonkreteSubklassenmüssenalleabstraktenOpera4onenderSuperklasseimplemen4eren!
UMLCourse—FindingClasses
Analysis and Design
• Analysis Goal: Understanding the problem domain
• Design Goal: Describing the software architecture
UMLCourse—FindingClasses
Finding classes • Analysis Goal: To find an appropriate description
of problem domain – The classes – Their relationships – Thinking about implementation not allowed!
• Think about the user, about the interfaces to external world. Everything else is implementation.
• Close connection to use cases
UMLCourse—FindingClasses
Finding Classes
1. Brainstorming 2. Noun method 3. CRC cards
• A creative process…
UMLCourse—FindingClasses
Classes • Common types of classes:
– Physical Objects (Calendar, Display, Page) – Conceptual Entities (Appointment,
Reminder)
UMLCourse—FindingClasses
Finding classes: Brainstorming
• Think of terms relevant to problem – e.g., Terms often used by experts
• Good classes – Encapsulate data – Are something, not just do something – Different in behavior from other classes
• Bad classes – Outside the system boundary – “Manager” classes
UMLCourse—FindingClasses
Finding Classes: Noun Method
• Underline all nouns in requirement document • Finds important terms • Criticism: grammar decides your design!
– For every entry of an appointment, a database record is made
– For every appointment that is entered, a database entry is made.
• The noun method is good, but be critical!
UMLCourse—FindingClasses
Refining Classes
• After classes have been found, refine by – Constructing class diagrams – Discussion of use cases
• Can use cases be explained using the class diagram?
UMLCourse—FindingClasses
Class Diagrams • A useful tool for visualizing an analysis or
design. • Goal: capture important objects and their
relations • Don’t be too formal about UML in early stages!
Make notes, shift things around, create different possibilities, different views.
• For initial deliberations, a black board is much easier than Rose – For later refinement and for presentation, tools are
helpful
UMLCourse—FindingClasses
Example UseCase: Insert Appointment ID: UC1.1 Actors: owner Preconditions: Flow of events:
1. The user specifies date, beginning time, end time, and description of appointment
2. The calendar warns about conflicting appointments 3. The appointment is entered in the calendar
Postconditions: The appointment is in the calendar
UMLCourse—FindingClasses
Class-Responsibility-Collaboration Cards
• Class-Responsibility-Collaboration on a 10 by 15cm index card.
• Find if classes play together well. • Responsibilities more important than
interfaces, classes collaborate with other classes to fulfill them
• Works well for analysis and design
UMLCourse—FindingClasses
CRC Cards Class Name
Responsibility
Collaboration
AppointmentAlertuser
Display
Alert
Calendar,Display
Keeptrackof4meanddate
UMLCourse—FindingClasses
TodoDisplayifnotyetdone Calendar,Display
Todo
CRC cards, example
AppointmentAlertuser
Display
Alert
Calendar,Display
Keeptrackof4me&date
CalendarDisplayAppointments
DisplayTodo’s
Appointment
Todo
Warnforcollisions Appointment
KeeptrackofDate
UMLCourse—FindingClasses
CRC Cards
• Visual: – Close together means collaborate closely – Below means part of (or is supervised by)
• Tactile – You can point to a card and take it in your
hand when discussing its responsibility.
UMLCourse—FindingClasses
CRC and Scenarios
• Scenarios and use cases
• Go through a scenario – explain how the system reacts to the scenario – keep track of responsibilities on CRC cards
UMLCourse—FindingClasses
Note on Inheritance
• Inheritance may come natural from problem domain – We have two sorts of appointments,…
• Similarities may become apparent during analysis – Appointments and todo items have similar
responsibilities • Especially important in design
UMLCourse—FindingClasses
Design With CRC Cards
• Conflict: – Need to clearly separate design and analysis – Need to have a smooth transition
UMLCourse—FindingClasses
CRC and Scenarios • Scenarios and use cases
• Go through a scenario – explain how the system reacts to the scenario – progressively make your explanations more detailed. – keep track of responsibilities on CRC cards – When interaction understood, document with
interaction diagrams
UMLCourse—FindingClasses
CRC: Merging and Splitting
• If a class has to many responsibilities (more than 3), either – restate the responsibilities at a higher level, or – split the class in two
• If a class has too few responsibilities, merge it into another class
UMLCourse—FindingClasses
CRC Cards for Analysis & Design
• Analysis: – Go through some scenarios (responsibilities
are high level, lots of magic) • Design
– Go through scenarios in more detail – Explain how magic happens, until you can
explain everything in sufficient detail (trivial to implement)
UMLImplementa4on
Component Diagrams • „A component is a physical, replaceable part of a
system that packages implementation, and confirms to and provides the realization of a set of interfaces.“
• Unit of Reuse! • Source File, ActiveX control, JavaBeans, Java
servlets,... • Beinhalten viele Klassen und Interfaces
UMLImplementa4on
Ein weiteres Beispiel
A B
C
EsgibteinedirekteAbhängigkeit(Dependency)zwischenAundB.DasInterfaceFwirdverwendetumdieComponentsAundCzuentkoppeln.
F
Shortcutfür:EineKlasseinCrealisiertdasInterfaceF
UMLImplementa4on
Deployment Diagrams • Zeigen die Hardware auf der die Software
laufen soll, sowie die Verteilung der Software auf diese Hardware.
• 2 Formen von Deployment Diagrams – Descriptor Form: Node, deren Beziehungen
und Components – Instance Form: Node Instances, deren
Beziehungen und Component Instances
UMLImplementa4on
Verwendung von Deployment Diagrams
• 2 Schrittprozeß – Design Workflow
• Fokus auf Nodes, Nodes Instances und deren Beziehungen
• Ziel: Hardware Architektur zu bestimmen – Implementation Workflow:
• Assign Component Instances zu Node Instances • Assign Components zu Nodes
UMLImplementa4on
Beispiel - Descriptor Form
<<webserver>>Apache
<<browser>>NETSCAPE
PC SparcSta4on
HTTP
Node Component
UMLImplementa4on
Beispiel - Instance Form
<<webserver>>:Apache
<<browser>>A:NETSCAPE
4msPC:PC sun:SparcSta4on
HTTP
Nodeinstance
Componentinstance
<<browser>>A:NETSCAPE
lisasPC:PC
UMLDependenciesundPackages
Relationships
Rela4onships
Associa4on
Dependency Generaliza4on
Realiza4on
UMLDependenciesundPackages
Architecture (4+1)
ClassdiagramsStatecharts
Objectdiagrams
Logicalview
ClassdiagramsObjectdiagrams
Processview
Componentdiagrams
Imlementa4onview
Deploymentdiagrams
DeploymentviewUsecasediagramsInterac4ondiagrams
Usecaseview
UMLDependenciesundPackages
Andere Relationships • Qualified Associations
– Reduktion von n-to-n Associations zu n-to-1 Associations
• Dependencies – Der Client hängt auf eine bestimmte Art vom Supplier
ab. – Beispiel: Ein Objekt einer Klasse wird als Parameter
einer Methode einer anderen Klasse geschickt. • Weitere Relationships werden später
eingeführt...
UMLDependenciesundPackages
Qualified Associations
• Eine Qualified Association wählt ein Element aus einer Zielmenge aus.
Club
Member
memberId:String
*
*Wiewirdein„Member“des„Clubs“gefunden?
DurchdiememberId!
UMLDependenciesundPackages
Andere Darstellung... • Kann immer eingesetzt werden, wenn ein spezielles
Objekt durch einen EINDEUTIGEN Schlüssel aus einer Menge selektiert werden kann.
Club
Member
memberId:String
*
1
memberId
UMLDependenciesundPackages
Dependencies
• „A dependency is a relationship between two elements where a change to one element (the supplier) may affect or supply information needed by the other element (the client)“
• Der Client hängt vom Supplier ab!
UMLDependenciesundPackages
Arten von Dependencies • Usage
– Der Client benutzt ein Service des Suppliers.
• Abstraction – Der Supplier ist abstrakter als der Client
• Permission – Der Supplier erlaubt (eingeschränkt) Zugriff durch den
Client • Binding
– Nur für Sprachen die Templates implementieren.
UMLDependenciesundPackages
Usage Dependencies • <<use>>
1. Eine Operation von A braucht einen Parameter der Klasse B 2. Eine Operation von A gibt einen Wert von B zurück 3. Eine Operation von A benutzt ein Objekt von B in einer Methode
(aber nicht als Attribut) • <<call>>
Die Client-Operation ruft eine Supplier-Operation auf.
• <<parameter>> Der Supplier ist ein Parameter oder Return-Wert einer Operation des Clients
• <<send>> Der Client schickt den Supplier (= Signal) zu einem unspezifizierten Ziel
• <<instantiate>>
UMLDependenciesundPackages
Beispiel Usage Dependency
A
foo(b:B)bar():B
doSomething()
B<<use>>
Client Supplier
UMLDependenciesundPackages
Abstraction Dependencies • <<trace>>
– Um darzustellen, daß der Supplier in einem früheren Stadium des Entwicklungsprozesses als der Client entwickelt wurde. (Analyse vs. Design)
– Oder um Requirements auf einen Use Case (der dieses Requirement unterstützt) abzubilden.
• <<refine>> – Um zu zeigen, daß der Client eine „verfeinerte“ Version des Suppliers
ist.
• <<derive>> – Um zu zeigen, daß ein Ding von einem anderen abgeleitet werden
kann.
UMLDependenciesundPackages
Beispiel <<derive>>
BankAccount Transac4on
Quan4ty
1 0..*
1
11
1
balance
<<derive>>
UMLDependenciesundPackages
Permission Dependencies • <<access>>
Das Supplier-Package erlaubt einen Client-Package den Zugriff auf den PUBLIC Inhalt (die Name-Spaces bleiben getrennt).
• <<import>> Wie <<access>> aber der Name-Space des Suppliers wird mit dem Name-Space des Client verbunden (im Client).
• <<friend>> Das Client-Element hat Zugriff auf das Supplier-Element (unabhängig von der Visibility).
UMLDependenciesundPackages
Warum Packages? • Um UML-Elemente und Diagramme in
Gruppen zu organisieren • Verwendungen:
– Zusammenfassen von Elemente mit ähnlicher Semantik
– Abgrenzung „Semantische Bereiche“ – Einheiten für Configuration Management – Einheiten für das parallele Arbeiten – Trennung von Name-Spaces
UMLDependenciesundPackages
Packages - Aufbau und Inhalt • Jedes Element bzw. Diagramm gehört zu
einem Package • Packages formen eine Hierarchie. • Top-Level-Package <<topLevel>> • Beispiel: Analyse-Package mit
– Use Cases – Analysis Classes – Use Case Realizations
• Visibility für Packages legt fest ob Elemente von Außen gesehen werden können oder nicht.
UMLDependenciesundPackages
Packages - Beispiel
+ClubMembership+Benefits+MembershipRules+MemberDetails:Member-JoiningRules
Membership:MemberDetails
Membership
Membership
Membership
MemberDetails
Member
JoiningRules ClubMembership
MembershipRules Benefits
<<access>>
qualifiedpackagename
UMLDependenciesundPackages
Package Dependencies
Supplier
Supplier
Supplier
AnalysisModel
Client
Client
Client
DesignModel
<<use>>
<<import>>
<<access>>
<<trace>>
UMLDependenciesundPackages
Transitivität
• <<access>> und <<import>> sind NICHT transitiv!
A B C<<access>> <<import>>
ElementevonAhabenkeinenZugriffaufElementvonC
UMLDependenciesundPackages
Package1
Nested Packages
Package2
MyClass
Package1
Package2
MyClass
ContainmentRela4onship AnchorIcon
Pathname,z.B.:Package1::Package2::myClass
EinPackagekanndiePublic-ElementeseinesumschließendenPackagessehen(abernichtumgekehrt).
UMLDependenciesundPackages
Generalization und Stereotypes
• Packages können in einer Vererbungshierarchie angeordnet werden (so wie Klassen)
• Stereotypes um die Semantik von Packages genauer zu bestimmen.
<<system>> Das zu modellierende System <<subsystem>> Ein unabhängiges Teilsystem <<façade>> Ein View auf ein anderes Package <<framework>> Pattern Package <<stub>> Proxy für den Public-Inhalt eines anderen Packages
UMLDependenciesundPackages
Architekturanalyse • Zweck:
– Minimierung der Kopplung zwischen Teilen des Systems. – Architekturanalyse partitioniert zusammenhängende Klassen in
Analysis Packages. – Die Analysis Packages werden danach auf Ebenen aufgeteilt.
• Ziele: – Minimierung der Abhängigkeiten zwischen Analysis Packages – Minimierung der Public und Protected Elemente in jedem
Analysis Package – Maximierung der Private Elemente
UMLDependenciesundPackages
Architecture - Beispiel
Sales Products
AccountManagement InventoryManagement
applica4on-specificlayer
applica4on-generallayer
par44on par44on
UMLDependenciesundPackages
Wie findet man Packages? • Identifizierung von Modellelementen mit einer
starken semantischen Verbindung • Benutzen des Statischen Models
– Cluster von Klassen im Klassendiagramm – Vererbungshierarchie – Use Cases können/sollen auch verwendet werden
• Nach der Identifizierung von Packages: – Minimierung Public/Protected Elemente und der
Package Abhängigkeiten durch: • Verschieben von Klassen zwischen Packages • Einführung neuer bzw. Entfernung alter Packages
UMLDependenciesundPackages
Zyklische Package Abhängigkeiten
A
A
B
A B
C
MERGE
ZyklischeAbhängigkeitensolltenvermiedenwerden.
UMLDependenciesundPackages
Zusammenfassung Vorgehensweise
Requirements Analyses
UseCasesClassDiagramsPackages
(Verbale)BeschreibungUseCases
WassolldasSystemmachen? Sorware
Architecture
<<use>> <<use>>
UseCases 99
Use Cases
• An (itemized) story of possible use • Created from a user interview
– Tied to a user • Use diagrams and text
• Use case prioritization
UseCases 100
Use Cases Capture Functional Requirements
• Not captured:
– Performance, – Reliability, – Hardware compatibility, – …
• Need to capture non-functional requirements separately
UseCases 101
What to do
• Three tasks: 1. Find system boundary 2. Find actors
• Actors are Roles 3. Find use Cases
UseCases 102
Use Case Diagrams • Actors
– Are outside the system – Interact with it – Are roles, not people – E.g.: calendar-owner,
secretary, MS-Outlook, Time • Use Cases
– Describe one use of the system
• Relationships • System Boundary
– Actors are outside, use cases inside
InsertAppointment
owner
UseCases 103
Use Case Diagrams • Actors
– Are outside the system – Interact with it – Are roles, not people – E.g.: calendar-owner,
secretary, MS-Outlook, Time • Use Cases
– Describe one use of the system
• Relationships • System Boundary
– Actors are outside, use cases inside
InsertAppointment
owner
PrintToday’sAppointments
printer
UseCases 104
Identifying Actors
• Who or what uses the system? • What roles do they play in interaction? • Who maintains the system? • What other systems interact with it? • Who gets and provides information? • Do things happen at fixed times?
UseCases 105
Use Case
• For every role, describe typical interactions with the system
• We want to understand the requirements, not model the system in detail.
UseCases 106
Example UseCase: Insert Appointment ID: UC1.1 Actors: owner Preconditions: Flow of events:
1. The user specifies date, beginning time, end time, and description of appointment
2. The calendar warns about conflicting appointments 3. The appointment is entered in the calendar
Postconditions: The appointment is in the calendar
UseCases 107
Requirements • The uses are
– Clear – Detailed
• Is anything missing? (Who, what, when, where?)
• Bad use case: The user enters the appointment data.
• Use cases describe one example!
• Detail depends on phase
UseCases 108
Example: a Later Iteration UseCase: Insert Appointment ID: UC1.2 Actors: owner Preconditions: Flow of events:
1. The owner selects the day of the appointment 2. The system shows the day, including all appointments already scheduled 3. The user clicks on the begin time, drags to end time, and releases the mouse
button 4. The system shows a box for the appointment, and a cursor inside the box. If
there are conflicting appointments, the box is in s different color. 5. The user types a description. 6. The appointment is entered in the data base
Postconditions: The appointment is in the calendar
UseCases 109
More Complicated Use Cases
• Use case describes one example of use!
• But: what to do with very similar cases?
UseCases 110
Extra Keywords
• If, for, while – If there is a conflict, the system warns – For all appointments in the day, the calendar
shows a box • Alternative flows
UseCases 111
Example: Alternative Flows UseCase: Insert Appointment ID: UC1.1.1 Actors: owner Preconditions: Flow of events:
1. The user specifies date, beginning time, end time, and description of appointment
2. If there is a conflicting appointment 1. The calendar issues a warning
3. The appointment is entered in the calendar Postconditions: The appointment is in the calendar Alternative Flows: The user may cancel the creation of an
appointment at any time before entering the description Postconditions: The calendar is not changed Alternative Flows: The user may leave the description empty Postconditions: The calendar enters the description
“appointment.”
UseCases 112
Scenarios • A path through a use case (without
branches, ifs, fors, and whiles), is called a scenario.
• Try to stick with scenarios as much as possible, especially initially.
• When are use cases good?
UseCases 113
Benefits and Drawbacks • Use cases are good when
– There are many actors – There are many functional requirements – The functional requirements are not
immediately clear
• Not as good for e.g. – A very fast sorting algorithm (too much) – A highly secure system (too little)
UseCases 114
Advanced Concepts • Actor generalization • Use case generalization • Inclusion • Extension points
• Use extreme case with advanced concepts – They can easily be misunderstood – They can easily make use cases more complex,
instead of simple. – Remember, use cases are also for clients
UMLAc4vityDiagrams
Was sind Activity Diagrams? • „OO Flow Charts“ • Prozeßmodellierung durch
– Aktivitäten und Transitions • Spezialfall von State Charts
– Jeder Zustand hat eine Aktion, die einen Prozeß oder Funktion spezifiziert und ausgeführt wird, wenn man den Zustand betritt.
• Activity Diagrams können an jedes Modellierungselement angehängt werden. – Use Cases, Classe, ..., Business Processes
UMLAc4vityDiagrams
Action States
• Atomare Einheiten von Activity Diagrams • Repräsentieren einen Zustand • Haben eine Action Expression • Die Ausführung einer Action Expression kann nicht
unterbrochen werden • Die Zeit für die Ausführung ist nicht von Bedeutung.
i:=i+1 Ac4vatealarm Opendoor
ac4onstate ac4onexpression
UMLAc4vityDiagrams
Spezielle Activity States
• Start und Stop State • Jedes Activity Diagramm beginnt mit
dem Start und endet mit dem Stop State
startstate stopstate
UMLAc4vityDiagrams
Subactivity States
• Beinhalten einen Nested Activity Graph • Subactivity States können wiederum aus
Subactivity States oder Activity States bestehen.
Logon
UMLAc4vityDiagrams
Transitions
• Verbindung zwischen States eines Activity Diagramms
• Wenn ein State fertig ist wird der nächste verbundene State ausgeführt.
Writeleber
Addressleber
Postleber
transi4on
ac4vitystates
UMLAc4vityDiagrams
Forks und Joins
• Zur Modellierung paralleler Workflows (inklusive Synchronisation)
Designnewproduct
Sellproduct
Manufactureproduct
Deliverproduct
Marketproduct
UMLAc4vityDiagrams
Swimlanes
Designnewproduct
Sellproduct
Manufactureproduct
Deliverproduct
Marketproduct
Zur Partitionierung von Activity Diagrams
MARKETINGMANUFACTURING
DELIVERY
UMLAc4vityDiagrams
Interpretation von Swimlanes
• In UML ist die Semantik von Swimlanes nicht bestimmt.
• Swimlanes repräsentieren: – Organisatorische Einheiten – Use Cases – Classes – Processes – ...
UMLAc4vityDiagrams
Object Flow
• Activities können Objekte als In- bzw. Output haben. Der Zustand von Objekten kann ebenfalls durch Activities verändert werden.
UMLAc4vityDiagrams
Object Flow - Beispiel
Designnewproduct
SellproductManufactureproduct
Deliverproduct
Marketproduct
MARKETING MANUFACTURING DELIVERY
:ProductSpec
:Order[delivered]
:Order[paid]
objectinstate
objectflow
object
UMLAc4vityDiagrams
Signale • Ein Signal dient zur asynchronen
Kommunikation zwischen Objekten • Signale können ebenfalls in Activity Diagrammen
verwendet werden • Signale in UML können als Klassen mit dem
Stereotyp <<signal>> modelliert werden. • Signale haben eine implizite Funktion send(targetSet) und sonst nur Attribute.
UMLAc4vityDiagrams
Signale - Beispiel Selectproductsfromcatalog
Fillinorderform
Mailorder
Order
Trackorder
Goodsdelivered
:MailOrderCompany
externalflowofcontrol
targetobject
receiveasignal
sendasignalcalledOrder
UMLAc4vityDiagrams
Signal Hierarchie - Beispiel
<<signal>>Arithme4csErrorEvent
codemessage
<<signal>>DivisionByZero
<<signal>>Arithme4csOverflow
AdvancedStatecharts 133
States • „..a condition or situation during the life of an
object during which it satisfies some condition, performs some activity, or waits for some event.“
• Zustand (State) eines Objekts ist gegeben durch: – Attributwerte – Relationships zu anderen Objekten – Aktivitäten, die vom Objekt durchgeführt werden.
AdvancedStatecharts 134
Zustände von Objekten?
• State = Semantisch signifikante Beschaffenheit eines Objekts
• Identifiziere Zustände von Objekten die sich wirklich unterscheiden!
• Beispiel: class Color {
int red; int green; int blue;
}
WassindhierdieZustände?
AdvancedStatecharts 135
State Syntax
entry/displaypasswordexit/validatealphaKeypress/echo“*“help/displaydo/get
EnteringPasswordstatename
entryandexitac4ons
internaltransi4ons
internalac4vi4y
Ac/onskönnennichtunterbrochenwerdenundbenö4genkeineZeit.
Ac/vi/eskönnenunterbrochenwerdenundbenö4geneineendlicheZeit.
AdvancedStatecharts 136
Transitions
• Event: Extern oder Intern, Trigger für Transition
• Guard Condition: Boolscher Ausdruck, der zu TRUE evaluieren muß
• Action: Wird ausgeführt, wenn die Transition gefeuert wird.
A BanEvent[guardConditon]/Ac4on
AdvancedStatecharts 137
Events
• 4 Arten: – Call events: Verursacht die Ausführung einer
Methode einer Klasse. – Signal events: One-Way, asynchrone
Kommunikation zwischen Objekten. – Change events: Aktion, die mit dem Event
assoziiert ist, wird ausgeführt, wenn eine Bedingung zu TRUE evaluiert.
– Time events
AdvancedStatecharts 138
Beispiel - Call Event
InCredit
deposit(m)/balance:=balance+mwithdraw(n)/balance:=balance-n;returnbalance
Overdrawn
deposit(m)/balance:=balance+mwithdraw(n)/balance:=balance-n;returnbalance
[balance>=0] [balance<0]
Kontext:BankAccountclass
AdvancedStatecharts 139
Beispiel - Signal Event
MonitoringAccounts
accountOverdrawn(od:OverdrawnAccount)/callborrower
ac4on signal
eventtrigger
date:DateaccountNumber:long
amountOverdrawn:double
<<signal>>OverdrawnAccount
EventwirdgetriggertdurchdenAufrufvonOverdrawnAccount.send(..)
AdvancedStatecharts 140
Beispiel - Change Event
InCredit
Overdrawn
when(balance<overdrarLimit)/no4fyManager
[balance>=0] [balance<0]
keyword Booleanexpressionac4on
ChangeEventssindflankengetriggert.ErstbeimÜbergangvonFalseaufTruewerdensieexeku4ert
AdvancedStatecharts 141
Beispiel - Time Events
Frozen
Overdrawn
when(balance<overdrarLimit)/no4fyManager
arer(3months) Keywords:arer,when
Beispiele:arer(3months)when(date=1.1.2004)
SymboleinAusdrückenmüssenAbributenimreak4venObjektentsprechen!(date!)
AdvancedStatecharts 142
Composite States
Enthält1odermehrere(nested)StateMachines(Submachines)
Decomposi4onIndicatornichtnotwendig,wennSubstatesexplizitdargestelltwerden!
DialingISP
entry/offHook
compositestate
decomposi4onindicator
AdvancedStatecharts 143
Sequential Composite States CompositeStatemitgenaueinernestedStateMachine
DialingISPentry/offHook
Wai4ngForDailtoneDailing
do/dialISP Wai4ngForCarrier
NotConnected
entry/onHook
Connected
exit/onHookdo/useConnec4on
arer(20seconds)/noDialtone arer(20seconds)/noCarrier
cancel
[dialtone]
[carrier]
AdvancedStatecharts 144
Concurrent Composite States
• 2 oder mehrer Submaschinen, die parallel exekutiert werden (FORK).
• 2 Arten der Beendigung: – Alle Submaschinen werden beendet (JOIN) – Eine Submaschine wird beendet und geht zu
einem Zustand außerhalb! Keine Synchronisation!
AdvancedStatecharts 145
Beispiel - Join
Ini4alizingSystem
Ini4alizeFireSensors
do/ini4alizeFireSensors
Ini4alizeSecurtySensors
do/ini4alizeSecuritySensors
AdvancedStatecharts 146
Beispiel - Ohne Synchronisation
Monitoring
Ini4alizeFireSensors
do/ini4alizeFireSensors
Ini4alizeSecuritySensors
do/ini4alizeSecuritySensors
SoundingFireAlarm
SoundingIntruderAlarm
arer(15mins)
fire
fire
intruder
ErrorsensorError
AdvancedStatecharts 147
Asynchrone Kommunikation
• Bisher synchrone Kommunikation zwischen Submaschinen
• Asynchrone Kommunikation durch: – Attribute – Sync States
AdvancedStatecharts 148
Kommunikation - Attribute
OrderProcessing
Accep4ngPayment
do/acceptPayment
AssemblingOrder
do/assembleOrder
DeliveringOrder
PaidFor
entry/paidFor:=true
[pairFor]
AdvancedStatecharts 149
Kommunikation Sync States • Sync State = Zustand, der wie eine Queue,
Nachrichten speichert. • Immer wenn ein Übergang zum Sync State
erfolgt, wird ein Eintrag gespeichert. • Wenn ein Übergang vom Sync State erfolgt, wird
ein Eintrag entfernt. • Anzahl der Einträge kann limitiert werden • Keine Angabe über Implementierungsdetails
durch Sync States!
AdvancedStatecharts 150
Beispiel - Sync States
OrderProcessing
Accep4ngPayment
do/acceptPayment
AssemblingOrder
do/assembleOrder
DeliveringOrder
PaidFor
* syncstate
fork
join
AdvancedStatecharts 151
History • Wichtig in der folgenden Situation:
1. Man befindet sich in Substate A eines Composite States
2. Man verläßt den Composite State 3. Man besucht andere States außerhalb 4. Man möchte wieder zurück in den Composite State
(und zwar genau zum Substate A) • Shallow History (H): Nur eine Ebene wird
gespeichert. • Deep History (H*): Alle Ebenen werden
gespeichert.
AdvancedStatecharts 152
Beispiel - History
BrowseCatalog
DisplayingItem
H
DisplayingIndex
DisplayingBasket
CheckingOut
goToBasket
goToCheckout
goToCatalog
goToCatalog
goToIndexselectProduct
exit
Interaction Diagrams
• Show how objects interact to realize a use case
• A diagram corresponds to one use case
• Like CRC Cards: describe use-case realization in increasing detail – Can extend and document CRC cards
Collaboration & Sequence Diagrams
• Collaboration Diagrams – Emphasize structural
relationships
• Sequence Diagrams – Emphasize temporal
relationships
• We can convert from one to the other
Registrar :RegistrationManager
UML:Course {new}
OOP:Course {new}
1. addCourse("UML")1.1. <<create>>
2. addCourse("OOP")
2.1. <<create>>
Registrar :RegistrationManager
UML:Course {new}
OOP:Course {new}
addCourse("UML")<<create>>
addCourse("OOP")<<create>>
Role and Instance Diagrams
• Role Diagrams: – Emphasize different roles of same class
• Instance Diagrams: – Describe exact interaction between objects
Collaboration Diagrams: Roles
Party
10..*
+employer 1 +employee0..*
Address
:Address
/Employer:Party /Employee:Party
1
*
1
1
1
1
ClassRoleAssocia4onRole
/RoleName:ClassName
Collaboration Diagrams
Use case: Add course
Preconditions: Registrar is logged in to system Flow of Events: 1. Registrar selects “add course” 2. Registrar enters name of new course 3. System creates new course
Postcondition: A new course is present in the system
RegistrationManager Course
*11 *
Collaboration Diagrams
Registrar :RegistrationManager
UML:Course {new}
OOP:Course {new}
1. addCourse("UML")1.1. <<create>>
2. addCourse("OOP")
2.1. <<create>>
Sequencenumber
Messagename
link
object
constraint
Messageflow
Objectcrea4on
Sequence Diagrams
Adifferentviewofthesameinterac3on!
Registrar:RegistrationMa
nager
UML:Course {new}
OOP:Course {new}
addCourse("UML")<<create>>
addCourse("OOP")<<create>>
Second run through use case
comment
objects
Sequence Diagrams
Registrar:RegistrationMa
nager
UML:Course {new}
OOP:Course {new}
addCourse("UML")<<create>>
addCourse("OOP")<<create>>
Second run through use case
Objectdele4on
Message Flow
Procedure call: caller waits for return Asynchronous message: caller
continuous without waiting for reply Return from call: only indicated when
important Unspecified
More Complicated Diagrams Flow of events: 1. The registrar enters name of student (Jim) and
name of course to register for (UML) 2. If the student exists and the course exists
1. The system registers the student for the course 3. If the student does not exist
1. The system gives an error message 4. If the course does not exist
1. The system gives an error message
Self-Calls and Conditions
• Calls of own object shown as – Nested control flow (sequence diagrams) – Loop (collaboration)
• Conditions for an action shown in square brackets: [student exists]
: Registrar : RegistrationManager Students Courses : Course
registerStudent("Jim","UML")s := findStudent("Jim")
find("Jim")
findCourse("UML")
find("UML")
[s&c]: register("Jim")[s&c]: ok
[!s]: studentNotFound
[!c]: courseNotFound
: Registrar
: RegistrationManager Students
1. registerStudent("Jim","UML")
1.1. s := findStudent("Jim")
1.1.1. aStudent := find("Jim")
1.2. findCourse("UML")
Courses
1.2.1. find("UML")
: Course
1.2.2. [s&c]: register(aStudent)
1.3. [s&c]: ok1.4. [!s]: studentNotFound1.5. [!c]: courseNotFound
<<local>>
Corresponding Collaboration Diagram
Iteration • Use iteration expressions to repeat steps • [i := 1…n] repeat n times • [I := 1..7] repeat 7 times • [while(bool)] repeat until expression is
false • [until (bool)] • [for each (collection)]
An Alarm System
: SecurityGuard : ControlBox : Siren : SecuritySensorMonitor : FireSensorMonitor
Hall : SecuritySensor Hall : FireSensor
activate
sound beep
ret:= isTriggered()
ret:=isTriggered
*[un4lret=true]
*[un4lret=true]
Alarm System : SecurityGuard : Siren : ControlBox : SecuritySensorMonitor :
FireSensorMonitorHall : SecuritySensor Hall :
FireSensor : Burglar
activate
sound beep
ret:= isTriggered()
ret:=isTriggered
Sound Alarm
*[un4lret=true]
*[un4lret=true]
Top Related