systems engineering and project management (unified ... · uml implementaon sinn und zweck von uml...

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

KLASSENDIAGRAMM (CLASS DIAGRAM)

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!

Finding Classes

UMLCourse—FindingClasses

Analysis and Design

•  Analysis Goal: Understanding the problem domain

•  Design Goal: Describing the software architecture


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


Finding Classes

1.  Brainstorming 2.  Noun method 3.  CRC cards

•  A creative process…


Classes •  Common types of classes:

– Physical Objects (Calendar, Display, Page) – Conceptual Entities (Appointment,

Reminder)


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


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!


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?


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


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


Class Diagram

Date

Appointment

Descrip4on

Appointmentstart

end

Calendar


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


CRC Cards Class Name

Responsibility

Collaboration

AppointmentAlertuser

Display

Alert

Calendar,Display

Keeptrackof4meanddate


TodoDisplayifnotyetdone Calendar,Display

Todo

CRC cards, example

AppointmentAlertuser

Display

Alert

Calendar,Display

Keeptrackof4me&date

CalendarDisplayAppointments

DisplayTodo’s

Appointment

Todo

Warnforcollisions Appointment

KeeptrackofDate


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.


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


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


Design With CRC Cards

•  Conflict: – Need to clearly separate design and analysis – Need to have a smooth transition


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


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


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)

WEITERE STRUKTURDIAGRAMME

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

Syntax -Component Diagrams

A

B

A

B<<reside>>

„KlasseBistTeilderKomponenteA“

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

UMLImplementa4on

Hinweis

Thinkpad

PC

LaserPrinter

SparcSta4on

Iconskönnen(sollen)verwendetwerden

OTHER RELATIONSHIPS & DIAGRAMS

UMLDependenciesundPackages

Relationships

Rela4onships

Associa4on

Dependency Generaliza4on

Realiza4on


Architecture (4+1)

ClassdiagramsStatecharts

Objectdiagrams

Logicalview

ClassdiagramsObjectdiagrams

Processview

Componentdiagrams

Imlementa4onview

Deploymentdiagrams

DeploymentviewUsecasediagramsInterac4ondiagrams

Usecaseview


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...


Qualified Associations

•  Eine Qualified Association wählt ein Element aus einer Zielmenge aus.

Club

Member

memberId:String

*

*Wiewirdein„Member“des„Clubs“gefunden?

DurchdiememberId!


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


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!


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.


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>>


Beispiel Usage Dependency

A

foo(b:B)bar():B

doSomething()

B<<use>>

Client Supplier


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.


Beispiel <<derive>>

BankAccount Transac4on

Quan4ty

1 0..*

1

11

1

balance

<<derive>>


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).

PACKETDIAGRAMM (PACKAGE DIAGRAM)


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


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.


Packages - Beispiel

+ClubMembership+Benefits+MembershipRules+MemberDetails:Member-JoiningRules

Membership:MemberDetails

Membership

Membership

Membership

MemberDetails

Member

JoiningRules ClubMembership

MembershipRules Benefits

<<access>>

qualifiedpackagename


Package Dependencies

Supplier

Supplier

Supplier

AnalysisModel

Client

Client

Client

DesignModel

<<use>>

<<import>>

<<access>>

<<trace>>


Transitivität

•  <<access>> und <<import>> sind NICHT transitiv!

A B C<<access>> <<import>>

ElementevonAhabenkeinenZugriffaufElementvonC


Package1

Nested Packages

Package2

MyClass

Package1

Package2

MyClass

ContainmentRela4onship AnchorIcon

Pathname,z.B.:Package1::Package2::myClass

EinPackagekanndiePublic-ElementeseinesumschließendenPackagessehen(abernichtumgekehrt).


Beispiel - Elementzugriff

Package1 Package2

A Package2::B B<<access>>


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


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


Architecture - Beispiel

Sales Products

AccountManagement InventoryManagement

applica4on-specificlayer

applica4on-generallayer

par44on par44on


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


Zyklische Package Abhängigkeiten

A

A

B

A B

C

MERGE

ZyklischeAbhängigkeitensolltenvermiedenwerden.


Zusammenfassung Vorgehensweise

Requirements Analyses

UseCasesClassDiagramsPackages

(Verbale)BeschreibungUseCases

WassolldasSystemmachen? Sorware

Architecture

<<use>> <<use>>

ANWENDUNGSFALLDIAGRAMM (USE CASE DIAGRAM)

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:


2.  The calendar warns about conflicting appointments 3.  The appointment is entered 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


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:


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

UseCases 115

Inclusion

InsertAppointment

owner

Viewappointments <<includes>>

AKTIVITÄTSDIAGRAMM (ACTIVITY DIAGRAM)

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

Decisions

Getmail

Openmail Binmail

guardedexpressionkeyword

else [isjunk]

merge

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

ZUSTANDSDIAGRAMM (STATE CHART DIAGRAM)

AdvancedStatecharts 132

Beispiel

ONOFF

OFF

ON

turnOn turnOff

burnOut


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.


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?


State Syntax

entry/displaypasswordexit/validatealphaKeypress/echo“*“help/displaydo/get

EnteringPasswordstatename

entryandexitac4ons

internaltransi4ons

internalac4vi4y

Ac/onskönnennichtunterbrochenwerdenundbenö4genkeineZeit.

Ac/vi/eskönnenunterbrochenwerdenundbenö4geneineendlicheZeit.


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


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


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


Beispiel - Signal Event

MonitoringAccounts

accountOverdrawn(od:OverdrawnAccount)/callborrower

ac4on signal

eventtrigger

date:DateaccountNumber:long

amountOverdrawn:double

<<signal>>OverdrawnAccount

EventwirdgetriggertdurchdenAufrufvonOverdrawnAccount.send(..)


Beispiel - Change Event

InCredit

Overdrawn

when(balance<overdrarLimit)/no4fyManager

[balance>=0] [balance<0]

keyword Booleanexpressionac4on

ChangeEventssindflankengetriggert.ErstbeimÜbergangvonFalseaufTruewerdensieexeku4ert


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!)


Composite States

Enthält1odermehrere(nested)StateMachines(Submachines)

Decomposi4onIndicatornichtnotwendig,wennSubstatesexplizitdargestelltwerden!

DialingISP

entry/offHook

compositestate

decomposi4onindicator


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]


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!


Beispiel - Join

Ini4alizingSystem

Ini4alizeFireSensors

do/ini4alizeFireSensors

Ini4alizeSecurtySensors

do/ini4alizeSecuritySensors


Beispiel - Ohne Synchronisation

Monitoring

Ini4alizeFireSensors

do/ini4alizeFireSensors

Ini4alizeSecuritySensors

do/ini4alizeSecuritySensors

SoundingFireAlarm

SoundingIntruderAlarm

arer(15mins)

fire

fire

intruder

ErrorsensorError


Asynchrone Kommunikation

•  Bisher synchrone Kommunikation zwischen Submaschinen

•  Asynchrone Kommunikation durch: – Attribute – Sync States


Kommunikation - Attribute

OrderProcessing

Accep4ngPayment

do/acceptPayment

AssemblingOrder

do/assembleOrder

DeliveringOrder

PaidFor

entry/paidFor:=true

[pairFor]


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!


Beispiel - Sync States

OrderProcessing

Accep4ngPayment

do/acceptPayment

AssemblingOrder

do/assembleOrder

DeliveringOrder

PaidFor

* syncstate

fork

join


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.


Beispiel - History

BrowseCatalog

DisplayingItem

H

DisplayingIndex

DisplayingBasket

CheckingOut

goToBasket

goToCheckout

goToCatalog

goToCatalog

goToIndexselectProduct

exit

ANDERE VERHALTENSDIAGRAMME

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>>


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


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}



Second run through use case

comment

objects

Sequence Diagrams

Registrar:RegistrationMa

nager

UML:Course {new}

OOP:Course {new}



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)]

Concurrency

ControlBox

SirenSecuritySensorMonitor

SecuritySensor

**

FireSensorMonitor

FireSensor

**

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]

Further Constructs

•  Object State

Conclusions

•  Collaboration and sequence diagrams are tools to explain how use case is realized

•  Collaboration diagrams emphasize relations, sequence diagrams emphasize sequencing

•  Can be used in combination with CRC cards

systems engineering and project management (unified ... · uml implementaon sinn und zweck von uml...

Documents