Lite mer UML. UMLs historia. Metamodelling OMG s 4-lagers arkitektur. UML 2 - Diagram. Diagram: Ramar. Paketdiagram

(1)

Lite mer UML

304

UMLs historia

●UML v1.0, 1/97

●OMG standard (UML v1.1, 11/97)

●ISO standard (UML v1.3, 10/00) (ISO/IEC 19501: 1.4.2, 19505: 2.1.2)

●UML 2.0 antagen av OMG (6/03)

●Senaste versionen: 2.4.1 (08/11)

305

UML 2 - Diagram

Component Diagram

Diagram

Behaviour Diagram Structure

Diagram

Package Diagram Object Diagram Deployment

Diagram Composite Struct-

ure Diagram

Class Diagram

Interaction

Diagram Activity

Diagram Use Case Diagram State Machine

Diagram Timing

Diagram

Communication Diagram Interaction Over-

view Diagram Sequence

Diagram

nya i UML 2 behandlas idag

306

Metamodelling

OMG’s 4-lagers arkitektur

MOF

UML (core)

UML model

Source code

<<instance of>>

M3: Meta-metamodel

M2: Metamodel

M1: Application specific model

M0: Concrete application

används för att beskriva

används för att beskriva profileUML

<<instance of>>

<<apply>>

<<extends>>

307

Diagram: Ramar

●UML-diagram kan ha en ram med en rubrik.

●Rubriken innehåller namnet på det omgivande namespacet, typen av diagram och parametrar

heading :: [<kind>] name [parameters]

kommentarer kan göras för alla delar i ett diagram

308

Paketdiagram

●Gruppering av klasser och paket

●Definierar namespace

GUI

javax.swing

User Forms Admin Forms

DB Interface User Forms Admin Forms

GUI

javax.swing

DB Interface

alternativ representation

309

(2)

Paketdiagram

●Alla diagramtyper kan grupperas

●Ganska vanligt för use cases

Admin Enrolling Course Registration System

Finances Student

Billing System Director of Studies

Alternativ representation för

<<actor>>

Director of Studies

310

Use Case-diagram

●Högnivårepresentation av systemet från en användares perspektiv

●Actors = Roll som spelas av en fysisk person eller ett externt system som interagerar med systemet.

●Use Case = Högnivå observerbart beteende hos systemet

●Fokus på vad systemet kan göra inte hur den gör det.

●Används ofta tillsammans med textbeskrivningar av use casen.

311

Johan Eliasson

Ett Use Case-diagram

Billing System Student

Select courses to teach Teacher

<<include>>

Check schedule

<<extend>>

Go to waiting list

Register for program Teaching Assistant

Register for courses extension points

Course full

312

Aktivitetsdiagram

●Grafisk notation för att modelera arbetsflöden

●Beskriver (parallella) aktiviteter på en hög nivå.

●Användbara för att beskriva affärslogik, komplexa operationer eller relationer mellan use cases

●Många likheter med flödesdiagram

●Tekniskt en form av state machine-diagram

313

Johan Eliasson

Ett Aktivitetsdiagram

Customer Sales Warehouse

Request product

Process order

Pull materials Ship order

Bill customer Receive order

Pay bill

Close order [in stock]

[not available]

b: Bill [unpaid]

b: Bill [paid]

Object flow

314

Klassdiagram

●Statisk analys och designmodeller

●Typer av objekt och deras relationer (statiskt)

●Huvuddelar:

−Klasser

−Attribut

−Metoder

−Relationer mellan klasser

<class name>

Fler delar kan definieras

315

(3)

Johan Eliasson

Klasser

+size: Area = (100, 100)

#maxSize: Rectangle -xWindowPtr -components [*] {ordered}

+create()

+resize( in f: real = 1.25): Area

#repaint( in gc: Graphics) Window

{abstract}

{author = “Joe”, status = tested}

Window size: Area maxSize create() resize() repaint()

Window

Attribute :: [visibility] [/] name [: type] [multiplicity] [= default-value] [{ property-string }]

Operation :: [visibility] name ( [parameter-list] ) [: return-type [{ property-string }]]

Parameter :: [direction] name : type-expression [multiplicity] [= default-value] [{ property-string }]

public

size: Area = (100, 100) protected maxSize: Rectangle private xWindowPtr components [*] {ordered}

public create()

resize( in f: real = 1.25): Area protected

repaint( in gc: Graphics) Window

Exampel på tagged values

316

Klassrelationer

●Dependency

●Association

●Aggregation

●Composition

●Generalisation

●Realisation

generell

specifik

styrka

317

<<interface>>

Nonstandard compartments should be named unambiguously

gender: {female, male}

Person

Kommentarer, Begränsningar, Kvalificerare, och Interface

Corporation BankAccount

wife 0..1 husband 0..1

Responsibilities - keep current balance - handle deposits and withdrawals

balance {> 0} {or}

{self.wife.gender = #female and self.husband.gender = #male}

compare ()

Sortable A constraint written

in OCL (Object Constraint Language) {ordered}

Account- number Association qualifier

318

Några riktlinjer för klassdiagram

●Håll modellen enkel i analysfasen

●Många enkla klasser är bättre än ett fåtal komplexa

●Använd meningsfulla och kända namn.

●Undvik “gud klasser,” beteendet ska spridas mellan klasserna

●Försök undvika den för generella dependency

●Namnge alla associationer

●Dokumentera din modell noggrant

319

Objektdiagram

●Ögonblicksbild av systemets tillstånd

●Visar relevanta instanser

●Bra för att analysera komplexa objektstrukturer

●Oförändrat sedan UML 1.x

teacher1: Lecturer name = ”Johan Eliasson"

room = "E441"

teacher2: PhDStudent name = "Anne Brown"

room = "E234"

ID = 12345 java: CourseOffering

teaches teaches

se12: CourseOffering semester = "fall 2012"

se13: CourseOffering semester = "fall 2013"

se: Course name = ”Applikations prog i Java"

code = "5DV135"

320

Sekvensdiagram

●Notation for scenarion

●Fokus på interaktion och tid

●Beskriver hur objekt samarbetar för att tillhandahålla en tjänst

−Ordnat meddelandeflöde

−Skapande/borttagning av objekt

−…

●Ett bra verktyg för att upptäcka avsaknad av beteende och eller objekt/klasser som saknas

●Mer avancerade i UML2

321

(4)

Ett enkelt sekvensdiagram

tid

322 Livslinje

Objekt

Activation bar

Sekvensdiagram: detaljer

●Beteckningar för parallellitet

−Parallella fragments (par)

−Assynkrona meddelanden

●Många speciella annoteringar

−State invariants

−Tids och varaktighets begränsningar

−Parametrar och lokala variabler

●Interaktionsfragment

−Referenser till andra (interaktions) diagram (ref)

−Val (alt, else, opt) och loopar (loop)

−...

call

asynchronous message return

323

establishAccess

Ett annat sekvensdiagram

sd userAccess

:ACSystem :User

openDoor

ref opt

cardOut message(“Please Enter”)

324 ref

ref - Refererar till ett annat mer detaljerat diagram

opt - Refererar till att en del är valfri. Villkor kan specificeras

Johan Eliasson

Loopexempel

325

loop

[isEmpty=false]

Några Guidelines för Sekvensdiagram

●Håll scenarion vid analys enkla

●Analysscenarios bör vanligtvis initieras av en actor

●Skilj på olika instanser av samma klass

●Gör alla antaganden klara (pre- and postconditions)

●Koncentrera er på huvudscenarion.

●Se till så att klass-, sekvens, use case-, etc.-diagram är konsistenta.

●Fokusera på generellt beteende. ”Implementera” inte metoder för tidigt (det finns nog med möjligheter i sekvensdiagrammen för att göra detta)

326

Kommunikationsdiagram

●Fokus på interaktion och förbindelser mellan objekt.

●Inte helt olika sekvensdiagram i funktionalitet

●Rollspelsdiagram kan användas istället (de innehåller mer info) (se UMINF04.04)

se: Course

aStudent 1: registerStudent (aStudent)

: User

1.1: getPrerequisites (): pre-requisites

1.2: isEligible (pre-requisites)

: CourseOffering 1.4 [isEligible and not isFull]:

addStudent (aStudent) 1.3: isFull] ()

327

(5)

State Machine-diagram 1

●Baserade på Harel statecharts

●Grafisk notation för att modellera klassbeteende

●Beskriver alla möjliga tillstånd och

tillståndsförändringar som triggas av externa händelser.

●Beskriva komplexa livscykler hos objekt

●Hjälp att hitta saknad tillståndsinformation och beteende <state name>

entry / <action>

exit / <action>

do / <action>

<event> / defer

event trigger [guard condition]/ action

if event then if condition then trigger transition;

execute action else nothing happens;

start

stop

An internal transition A deferred event

328

State Machine-diagram 2

●Tillstånd kan nästlas

●Undertillstånd kan vara parallella

●Övergångar kan ha flera källor och eller destinationer

●Formaliserar många informella delar från UML 1.x

●Activitetsdiagram är också state machines

329

Exampel: State Machine

330

Utveckla State Machines från tillstånd

●Leta efter tillstånd då maskinen väntar på att en händelse ska inträffa

●Leta efter tillstånd som är beteendemönster som fortgår tills dess att de avslutas av sig själv eller en händelse med högre prioritet.

A state models a situation during which some (usually implicit) invariant condition holds. The invariant may represent a static situation such as an object waiting for some external event to occur. However, it can also model dynamic conditions such as the process of performing some behaviour (i.e., the model element under consideration enters the state when the behaviour commences and leaves it as soon as the behaviour is completed).

331

Utveckla State Machines från relevanta händelser

●Leta efter tre typer av händelser: namngivna händelser, händelser som ändrar villkor, och tids händelser

●En händelse är relevant om någon sorts svar krävs, som en tillståndsförändring eller aktivitet (eller båda)

●När du har alla tillstånd och händelser kan man slå samman dem till ett SMD och fylla i detaljerna

−Åtgärder att utföra som svar på händelser

−Relevanta guards (villkor som måste vara sanna för en tillståndsövergång)

An event is (the specification of) some occurrence that may potentially trigger effects by an object. A transition from a source to a target state represents the response of the state machine to an occurrence of an event of a particular type.

332

En annan State Machine

333

(6)

Några guidelines för State Machine-diagram

●Använd SMDs när beteendet är (komplext) beroende på tillstånd.

●Använd SMDs när du inte är säker på när saker kan (är tillåtna att) hända.

●Se till så att alla händelser täcks.

●Se till att alla tillstånd går att nå.

●Se till att alla tillstånd kan lämnas.

●Se till att alla tillståndsövergångar kan startas.

●Kolla varje par av tillstånd för att hitta saknade tillstånd och övergångar

●Kolla så att allt är konsistent med övriga diagram(- typer)

334