INF5120 ”Modellering med objekter” · INF5120 Modellering med Objekter 22.01.2004 3 Telecom and Informatics 5 Krav og forutsetninger Ingen formelle krav (student ved UiO) Kunnskaper

INF5120 Modellering med Objekter 22.01.2004

1

1Telecom and Informatics

INF5120”Modellering med objekter”

Forelesning 22.01.2004

Arne-Jørgen Berre


Velkommen til INF5120 “Modellering med objekter”� Modellering med objekter

� http://www.uio.no/studier/emner/matnat/ifi/INF5120/v04/

� Forelesere:� Arne-Jørgen Berre� Jan Øyvind Aagedal� Brian Elvesæter� Christoffer Daae-Qvale/Geir Borge Ottersen� Birger Møller Pedersen� Email: [email protected]

� Øvingsansvarlig:� Sinan Sigurd Tanilkan� Email: [email protected]


2


Forelesning 1

� Praktiske ting og litt om faget� Modeller og modellering� Objektorientering og Basisbegreper� UML – notasjon – Strukturell modellering� UML – notasjon – Oppførselsmodellering

� Diskusjoner...� Kaffemaskinoppgave...


Praktisk

� Forelesninger m/øvinger torsdager 14.15 - 17.00 (Lille)

� 10 studiepoeng, skriftlig, åpen bok eksamen� To obligatorisk oppgaver

� 1) Kort presentasjonsoppgave rundt et gitt case� m/tilhørende elektronisk innlevering som postes på web

� 2) Større caseoppgave som skal innleveres elektronisk

� Papirkopier av foiler på forelesning� Oppdatert web før neste forelesning (29/1)


3


Krav og forutsetninger

� Ingen formelle krav (student ved UiO)� Kunnskaper tilsvarende IN-219, IN-265 og IN-ODS/IN-DIS

vil være en fordel� Egeninnsats til lesing om UML notasjon

(Dette vil etterhvert undervises i fag på lavere grad) – se egen støttebok


INF5120 - Forelesninger - 2004

M: MDA, O: M: MDA, O: OptimalJOptimalJ, R: RUP, U: UML, C: COMET (Literature references), R: RUP, U: UML, C: COMET (Literature references)

� 1: 22/1: Introduction –OO, UML 1.5 and 2.0 (U, R)� 2: 29/1: MDA technologies and RUP Process, ( M, R)� 3: 5/2: Requirements Modeling, ( R, U) � 4: 12/2: PIM Modeling Domain/Service (M, O) � 5: 19/2: PSM Mapping EJB and DBMS (M, O)� 6: 26/2: PSM Mapping Web and User Interface/Presentation rules (M, O)� 7: 4/3: Business Rules and introduction to OCL (M, O)� 8: 11/3: Testing, packaging and deployment (M, O)� 9: 18/3: Business and CIM Modeling with Architecture mappings: ( C)� 10: 25/3: Architecture and System Modeling UML 2.0 – (C, U)� 11: 1/4: Behavioural Modeling – Sequence and State diagrams, exeUML 2.0 (U) � 12: 15/4: Non-functional requirements – Quality of service (C) � 13: 22/4: Component Modeling /design – OCL (C, U) � 14: 29/4: MDA, MOF, CWM and QVT Transformations (M, C)� 15: 6/5: Genericity: Patterns/reuse/Frameworks, Repository, Product line (C)� 16: 13/5: Summary – preparation for exam


4


INF5120 – Øvinger -2004

� 1: 22/1: Kaffemaskin� 2: 29/1: UML modellering – Gruppe Oblig 1� 3: 5/2: MDA og Prosess - Gruppe Oblig 1� 4: 12/2: Krav Modell – Gruppe Oblig 1� 5: 19/2: PIM modell - Gruppe Oblig 1� 6: 26/2: PSM: EJB og DBMS – Gruppe Oblig 1� 7: 4/3: PSM: Web og UI – Gruppe Oblig 1� 8: 11/3: Business Rules – Gruppe Oblig 1� 9: 18/3: Testing, Deployment – Gruppe Oblig 1� 10: 25/3: Business Modell – Gruppe Oblig 1� 11: 1/4: Arkitektur Modell – Gruppe Oblig 1� 12: 15/4: Oppførsels Modeller – Gruppe Oblig 1� 13: 22/4: Ikke funksjonelle krav – Gruppe Oblig 1� 14: 29/4: OBLIG 2� 15: 6/5: OBLIG 2� 16: 13/5: Preparation for exam

100 stk = 25 grupper a 3-4, 2 grupper hver gang, 12 ganger


INF5120 - Forelesnings/Øvings ansvarlige -2004

� 1: 22/1: AJB� 2: 29/1: AJB� 3: 5/2: JØA� 4: 12/2: JØA, CDQ/GBO � 5: 19/2: BRE, CDQ/GBO� 6: 26/2: BRE, CDQ/GBO� 7: 4/3: AJB, CDQ/GBO� 8: 11/3: BRE. CDQ/GBO� 9: 18/3: AJB� 10: 25/3: AJB� 11: 1/4: BMP� 12: 15/4: JØA� 13: 22/4: JØA� 14: 29/4: AJB� 15: 6/5: BRE� 16: 13/5: AJB

Personer og Temaer:Arne-Jørgen BerreAJB: BM, MDA,Brian ElvesæterBRE: Req.Mod, Verktøy,

PSM/ImplemChristoffer Daae-QvaleGeir Borge OttersenCDQ/GBO: OptimalJ

Jan Øyvind AagedalJOEA: Presis mod, QoSBirger Møller PedersenBMP: UML 2.0 Oppførsel

HL: Sinan Sigurd Tanilkan, SST


5


MDA Explained

The Model Driven Architecture Practice and Promise by Anneke Kleppe, Jos Warmer, Wim Bast

•Paperback: 166 pages ;

•Publisher: Addison+Wesley;

•2003

•ISBN: 0-321-19442-x


MDA Explained� 1: The MDA Development Process� 2: The MDA Framework� 3: MDA Today

� 4: Rosa’s Application of MDA� 5: Rosa;s PIM to three PSMs� 6: Rosa’s PSMs to Code� 7: More on Transformations� 8: Metamodeling� 9: Defining your own transformations� 10: Rosa’s transformation definitions� 11: OMG Standards and additional technologies� 12: The MDA promise

� A: Glossary � B: The Code for Rosa’s system


6


See also

� http://www.klasse.nl/mdaexplained/

� and

� http://javacentral.compuware.com/optimalj/demo_edition/

� (OptimalJ Demo edition) + MDA chapter 1 og 4 tilgjengelig


The Rational Unified Process

Third Edition

by Philippe Kruchten

•Paperback: 289 pages ;

•Publisher: Addison Wesley Professional; ;

•3rd edition, January 2004

•ISBN: 0-321-19770-4


7


The Rational Unified Process� 1: SW Development Best Practices� 2: The Rational Unified Process� 3:Static structure: Process description � 4: Dynamic structure: Iterative Development� 5: An Architecture-centric Process� 6: A Use-cased Driven Process� 7: The PM Discipline� 8: The Business Modeling Discipline� 9: The Requirements Discipline� 10: The Analysis and Design Discipline� 11: The Implementation Discipline� 12: The Test Discipline� 13: The Configuration and change Discipline� 14: The Environment Discipline� 15: The Deployment Discipline� 16: Typical Interation plans� 17: Implementing RUP� A: Roles, B: Artifacts, C: Acronyms

RUP


COMET - MDA for Interoperable Systems (Berre/Aagedal/Elvesæter/…) – new version March 2004� 1: Introduction to COMET – overview/motivation/nutshell� 2: An introduction to Interoperable Systems and Enterprise

Architecture� 3: An introduction to the sample application� 4: Business Modeling and Enterprise Architecture� 5: Requirements (Actors and use cases, User Experience )� 6: Architecture� 7. Components and Design� 8: Extra-functional requirements, Quality of Service� 9: Implementation� 10: Phases: Inception, Elaboration, Construction, Transition� 11: Additional. Topics: Testing, Repository, Tool environment� A: Profiles and stereotypes, B. MDA environment & tools/UMT ++� X: Web Structure support COMET


8


UML 1.4/1. 5 and UML 2.0

� UML Background and Reference material� http://www.omg.org/uml/ (UML)� http://www.omg.org/mda/ (MDA)� http://www.omg.org/cwm/ (MOF, XMI, CWM)

� Supporting litterature:� UML book 1: UML Distilled - Third edition w/UML 2.0� UML book 2: Applying UML and patterns� UML book 3: UML and Unified Process


UML reference books

UML Distilled: A Brief Guide to the Standard Object Modeling Language (3rd Edition)by Martin Fowler, Kendall Scott

Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and the Unified Process (2nd Edition)by Craig Larman

UML and the Unified Process: Practical Object-Oriented Analysis and Designby Jim Arlow, Ila Neustadt


9


Eksamen

� Case-basert oppgave (ref. tidligere eksamen)� Alle skriftlige hjelpemidler er tillatt

� 09-13 – tentativt, torsdag 3 . juni


Modeller og modellering


10


Diskusjon

� MODELLERING� med� OBJEKTER

� Sett dere sammen i grupper a 2-3 og diskuter begrepene:� MODELLERING

� OBJEKTER(5 min)


...tilbake til OO...


11


PhaseClass

TraditionalSA/SD/ERA

SA-based OO

ERA-based OO

Hybrid SA/ER-based OO

SA - Yordon SD - Page Jones

ERA - Chen ER-Rel.db - 3NF

OO RT SA - Wards

OOA/OOD - Coad/Yordon

OMT - Rumbaugh et. al

Fusion - HP

OOAD - Booch (93 w/C++)

HOOD - ESAOOSD - Wasserman

SD-basert OO

OO-based

RDOOD - Wirfs-Brock et. al

CRC-cards - Cunningham

OOram - Reenskaug et. al

ANALYSIS DESIGN DETAILED DESIGN

OOAD - Martin/Odell

OSDL-92 - CCITT/Bræk et. alOOSE/ObjectOry - Jacobson

Ada(C++)-based

SDL-based OO

UML (96)Booch/OMT/ObjectOry

OOAD metoderOOAD metoder

Catalysis, Syntropy, SOMA, OBA, BHS, ...


Evolution of the UMLEvolution of the UML

Booch ´91

Booch ´93

Unified Method 0.8

UML 1.0

OMT - 2

OMT - 1 OOSE

UML 0.9 & 0.91

OOPSLA ´95

June ´96 & Oct ´96

Submission of UML 1.1 to OMGfor adoption, Sept ´97

Other methods

publicfeedback UML Partners’

Expertise

UML 1.1 (Sept. 1997)

Taskon,SINTEF

UML 1.4UML 2.0


12


Hvorfor UML: Systemkompleksitet

SubsystemSubsystem

Enhet

System

Enhet

Omgivelse


aRealWorldPhenomena

Mental modelSystem

Manifest Model

Objects� A model is created for a purpose� A model is never complete� We think in multiple models� The world is rarely hierarchical

Hvorfor UML: Felles beskrivelse


13


Hvorfor UML: Naturlig del av prosess

UnifiedModelingLanguage

Process

� Convergence Today� Unification

leads to “standards”

� Convergencein the future

� Process frameworks through consensus

Two parts of a Harmonized Whole


Evolution of methodologies

UML1.0

UML1.1

UML1.2

UML1.3

UML1.4

OMT

Objectory

Booch

UML Components

Catalysis

OOram

KobrA

COMET

UML4EDOC

UML2

Pulse

UP

RUP

Notation

Process 2002

2001

1995-1999

2000


14


Målsetning med faget

� Modellering med objekter� Ikke programmering med objekter

� Forståelse for modelldrevet systemutvikling� Komponentbasert utvikling

� Gjenbruk

� Lære teknikker� Unified Modeling Language (UML)


Undervisning

� Forelesninger� Dekker utvalgte deler av teorien i bøkene� Litt annen fokus enn bøkene

� Øvinger� Bruke forelest stoff i praksis� Case-oppgave på eksamen

� Eksempler i forelesninger og øvingstimer


15


Objektorientering og basisbegreper


Objektorientering, Begreper og konsepter� Basis tanker� Objekt Modellering� Basis konsepter� Klassifisering / Typer / skaping av “individer”� Innkapsling� Deling og Arv� Polymorfi og dynamisk binding� CRC kort


16


Historisk fokusHistorisk fokus

Kvalitet og Produktivitet

Modellering(mdlg)

Abstraksjon ogModularisering

Gjenbruk ogVedlikehold

Funksjonell mdlg ( -55 -> )Data mdlg (-60 ->)Simula 1967 +

mdlg av “individer”mdlg av individers

oppgave ( -70 ->)“Oppgave-behandlere”/

“saksbehandlere”

[Oppgavefokus]

SW Engineering +komplekse systemer

fra velprøvete delerAbstrakte Data Typer1965-KlassifiseringFerdiglagete deler /

komponenter av gitt“type”

[Eksterne egenskaper]

Biblioteker ( -55 -> )Komponenter og

rammeverk ( -80 -> )Patterns (-90 -> )

Vedlikehold kostbartØkende kompleksitet /

størelse.

[modulbygging]

“Splitt og hersk”: store, komplekse problemer deles opp i et settav små, selvstendige og enkle problemer. (i ett eller flere trinn!)


“Skandinavisk” Modellerings-perspektiv“Skandinavisk” Modellerings-perspektiv

A program execution is regarded as a physical model, simulating the behaviour of either a real or imaginary part of the world.A physical model consists of objects, each object is characterized by attributes and a sequence of actions. Objects organize the substance aspect of phenomena, and transformations on substance are reflected by objects executing actions.Objects may have part-objects. An attribute may be a reference to a part object or to a separate object. Some attributes represent measurable properties of the object.The state of an object at a given moment is expressed by its substance, its measurable properties and the actions going on then. The state of the model is the states of the objects in the model.

(Fra Simula)


17


Basis for OO TeknologiBasis for OO Teknologi

Kvalitet og Produktivitet

Modellering Abstraksjon ogModularisering

Gjenbruk ogVedlikehold

Objekt Modell

Klassifisering/Instansiering Innkapsling Deling

Arv Polymorfisme


Objektorientert ModellObjektorientert Modell

En objektorientert modell er en (simulerings) modell som består avsamspillende objekter i interaksjon med hverandre.

En parallell i “virkeligheten”: en bil. Den består av et settdeler / komponenter som samvirker i et gitt mønster.( ikke alle påvirker alle andre direkte; interaksjonene/samspilleter diktert av oppgaver og hensikt)


18


OO - SYN PÅ VERDENOO - SYN PÅ VERDEN� SAMSPILLENDE OBJEKTER. Hvert Objekt:

� har klart ansvar� vet om samarbeis partnerene� er robust

� Ingen vet om det hele!

Data storage

Internalstorage

Disc

”Monolitisk”


System and objectsSystem and objectsA system is a part of the real world which we choose to regard as a whole, separated from the rest of the world during some period of consideration.

A whole that we choose to consider as a collection of objects, each object being characterized by attributes and by actionswhich may involve itself and other objects.

Mental modell

Manifest ModelReal-Worldphenomenon


19


Object oriented modelingObject oriented modelingaRealWorld-Phenomena roleModels anImplemented

SystemanObjectModel

Manifest ModelReal-Worldphenomenon

Mental modelEnvironmentModel environment

System model


Noen ord om Objekt-Orientering

� En “filosofi”; en måte å betrakte verden på� En måte å spesifisere systemer på� En måte å designe systemer på� En måte å programmere systemer på

� “Alt” er objekter� Det som skjer,

hender ved at objekter agerer i samspill� Peker mot oppdeling, distribusjon og delegering


20


OO Programming TerminologyOO Programming Terminology

� Encapsulation� Object� Message� Method� Class� Instance� Inheritance� Polymorphism� Dynamic (Late) Binding


CRC Method, class, responsibilities, and collaborators� Method to learn

the most basic OO concepts plus OO “thinking”� “The most effective way of teaching the idiomatic way of thinking

with objects is to immerse the learner in the "object-ness" of the material. To do this we must remove as much familiar material aspossible, expecting that details such as syntax and programming environment operation will be picked up quickly enough once the fundamentals have been thoroughly understood.”

� Technique also very useful during informal and creative analysis and design

� Created by Kent Beck and Ward Cunningham,Textronix, 1989


21


The CRC-Cardan object of paper personalizing the object

Class (Name):

Responsibility: Collaborators:


Class, responsibilities, and collaborators� Class

The class name of an object creates a vocabulary for discussing a design. Indeed, many people have remarked that object design has more in common with language design than with procedural program design. We urge learners (and spend considerable time ourselves while designing) to find just the right set of words to describe our objects, a set that is internally consistent and evocative in the context of the larger design environment.

� Responsibilities Responsibilities identify problems to be solved. The solutions will exist in many versions and refinements. A responsibility serves as a handle for discussing potential solutions. The responsibilities of an object are expressed by a handful of short verb phrases, each containing an active verb. The more that can be expressed by these phrases, the more powerful and concise the design. Again, searching for just the right words is a valuable use of time while designing.

� CollaboratorsObjects which will send or be sent messages in the course of satisfying responsibilities. Collaboration is not necessarily a symmetric relation. For example in Smalltalk, View and Controller operate as near equals while OrderedCollection offers a service with little regard or even awareness of its client.


22


CRC is Not distinguishing between Object Instance and Class� It is not needed

� because the CRC-methods physical aspects where each class description becomes an individual physical object, a filing card.This enables the double role of class and object in discussion and analysis with no confusions.

� It gives an benefit� the number of concepts

to be handled and mastered are kept to a minimum!!


Card Playing Rules - Notation

� Every card represents possibly several objects at the same time (if needed)

� Overlapping cards implies close collaboration� Positioned above a card

implies that the object is controlled by this card� A stack of cards

implies hierarchical detailing of abstractions - the most abstract card is placed on top and represents the rest of the hierarchy


23


Card Playing Rules - Process

� Regard the cards as objects� Start with the known, evolve towards the unknown� Evolve design by 'playing' through scenarios

(simulate execution)� pick up the object which is executing

and identify yourself with it� create new objects or responsibilities

founded on requirements / needs emerging during simulation. (not for some hypothetical future needs)

� Work in a team. A single person will have difficulties finding all requirements or scenarios.


UML – notasjon –Basis strukturell modellering


24


UML Structural Modeling

� Building blocks of UML� Classes� Attributes/Operations� Associations� Packages� Extension mechanisms


Building blocks of the UML

� Things� Structural, Behavioural, Grouping, Annotational

� Relationships� Dependency, Association, Generalisation, Realisation

� Diagrams� Use Case, Sequence, Class, Object, Collaboration, Statechart,

Activity, Component, Deployment


25


Metamodel Architecture

«metaclass»Attribute

«metaclass»Class

«metaclass»Operation

«instanceOf»

<<metamodel>>UML Metamodel

Analysis ModelThe attribute fare ofthe PassengerTicketclass is an instance ofthe metaclassAttribute.

The operationissue of thePassengerTicketclass is aninstance of themetaclassOperation.

«instanceOf»«instanceOf»

«instanceOf»

<<use>>

<<use>>

Represents theUser Object layerof the 4-layermetamodelarchitecturepattern.

«metaclass»Class

<<metamodel>>MOF Meta-Metamodel

«metaclass»Operation

«metaclass»Attribute

PassengerTicket

+total()+issue()+surrender()+refund()

+issuedBy : Airline+issuingAgent : TravelAgent+fare : Currency+tax : Currency

45723990550: PassengerTicket

+issuedBy : Airline = AcmeAirlines+issuingAgent : TravelAgent = TerrificTravel+fare : Currency = 1050.00+tax : Currency = 57.56

«instanceOf»

From Modeling CORBA Applications with UML chapter in [Siegel 00].


Foundation

Model Management

Behavioral Elements

UML Overview

CoreExtension Mechanisms

Data Types


26


Different kind of models

� Conceptual models

� Specification models

� Implementation models


Class diagram

GM_Primitive

+ boundary() : Set(GM_Primitive)

(from GeomPrimitive) GM_Complex(from GeomComplex)

GM_Object+ mbRegion : GM_Object+ representativePoint : DirectPosition

+ SRS() : SpatialReferenceSystem+ transform(SRS : SpatialReferenceSystem) : GM_Object+ equals(object : GM_Object) : Boolean+ distance(object : GM_Object) : Distance+ dimension() : Integer+ dimension(point : DirectPosition) : Integer+ coordinateDimension() : Integer+ envelope() : Envelop+ boundary() : Set(GM_Object)+ buffer(radius : Distance) : GM_Object+ convexHull() : GM_Object+ centroid() : DirectPosit ion+ representativePoint() : GM_Point+ isInComplexes() : Set(GM_Complex)+ isPartOf(geomCplx : GM_Complex) : Boolean+ universe() : GM_Complex

SpatialReferenceSystem(from DirectPositioningSchema)

1

+srs

1


27


The object symbol

Can represent

� an instance

� a type/interface

� a class

John :Person

Person

<<Interface>>Person


Class diagram - notation

Class name

attributtename-1 : datatype-1 = defaulval-1attributtename-2 : datatype-2 = defaultval-2

operationname-1 (argumentlist-1) : resulttype-1operationname-2 (argumentlist-2) : resulttype-2

. . . .

. . . .

An Abstract class is shown with class name in italics(means no implementationof this class, i.e. subclasses are needed)


28


Encapsulation and visibility

ClassName

/ /* derived attribute+ /* public visibility# /* protected visibility- /* private visibilityunderline /* class level (static)


Attributes

[visibility] name [multiplicity] [:type] [= initial value] [{property-string}]

+ origin [0..1] : Point = (0,0) {frozen}

defined properties: changeable, addOnly, frozen (const)


29


Attributes and data types

� A data type specifies a legal value domain and the operations on values of that domain

� Four categories� a) Basic data types� b) Collection data types (from OCL)� c) Enumerated data types� d) Model types


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

[(parameter-list element)] ::= [direction] name : type [= default-value][direction] ::= in | out | inout

+ set ( in name : Name, in place : String = ‘Oslo’) : Boolean {sequential}

defined properties: isQuery, sequential, guarded, concurrentNo syntax for exceptions (?)Notes w/ stereotypes: <<precondition>>, <<postcondition>>, <<invariant>>


30


Relationships

� Association� A semantic connection between two instances

� Generalization� A relationship between an element and the

subelements that may be substituted for it

� Dependency� The use of one element by another

� Refinement� A shift in levels of abstraction


� Purpose: To show relationships between model entities, To definemulti-way constraints

AssociationNameRoleNameRoleName

1..*2

Multiplicity of an Association

Dependency (Client-Server) Composition (Strong Aggregation)

Generalization Aggregation

Link AttributeAssociation Notationused to “anchor” at noteto a model entity

Different relationships in UML Diagrams


31


Generalisation and Association

WomanMarried with

0..1 0..1

Person Bookloans

Loancustomer

Loan-entity

0..1 0..*

Man

{not siblings}

Generalisation

Superclass

Subclasses (inherits attributes and operations)

wifehusband

Arrow can be used toshow direction ofknowledge

Association


Multiplicity constraints

Multiplicity shows how many instances of a class that can be related to one instance of the class at the other end of the association

Class

Class

Class

Class

Class

Exactly one

Many, optional zero or more

One, optional one or more

At lease one

Given number

0..*

1

0..1Class*

1..*

3,5,10


32


Aggregation (can be shared)

Loose (weak) part-of relationship

Phonebook

Subscription0..* *

Open diamond

Multiplicity > 1 possibleExists even if a phone bookgoes away

listedIn subscriptions

associationrole names


Composition (sometimes called strong aggregatgion)

Strong part-of relationship

File Recordcontains1 *

Filled diamond

Multiplicity max 1 Existence dependent


33


Associations

Fig. 3-31, UML Notation Guide

Person

Manages

JobCompany

boss

worker

employeeemployer1..∗

∗

∗

0..1

Job

Account

Person

Corporation

{X or}

salary


Association Ends

Fig. 3-32, UML Notation Guide

Polygon PointContains

{ordered}

3.. ∗1

GraphicsBundle

colortexturedensity

1

1

-bundle

+points


34


UML – notasjon –Basis oppførselsmodellering


UML Behavioral Modelling

� Use Cases� Interactions

� Sequence diagrams� Collaboration diagrams

� Statecharts� Activity Diagrams


35


Use cases

� A special instance of collaboration:� between external actors and the system

� Has its own special simple notation: � Use case diagrams


Clerk

Register Car

Print Car Report

Understanding requirements -using Use-Case models

� The use-case model consists of � Actors� Use cases

� It is a model of what the system is supposed to do (use cases) and the system's surroundings (actors).

A Car-Register System

Actors can be subclassed


36


Structuring of a Use case (1)

� Extension of a Use Case (Bottle-machine)

� <<extend>> can be used to describe for instance exceptional situations.

� Can be added later� Main use case will not be impacted by an extension

Buy a bottle Remove bottle that is notproperly dispensed

<<extend>>

Use Case


Structuring of Use Case (2)

� Common parts of multiple use cases

� Advantages� Common description in one place� Changes is done in one place

Remove bottle

<<include>>

Fill new bottles

Open machine<<include>>

Use Case


37


Extenstion point & realisation

Place order

extension pointsset priority

Place rushorder

<<extend>>(set priority)

Ordermanagement

realisation


The context of a system

Credit Cardvalidation system

Performcard transaction

Reconciletransactions

Processcustomer bill

Customer

Retail institution

Sponsoring financial institution


38


Developing the Use Case Model

� Find the Actors� Find the Use Cases� Briefly describe each Use Case� Describe the Use Case Model (UML)

� Prioritize Use Cases� Detail each Use Case� Sketch interfaces

Documents

INF5120 ”Modellering med objekter” · INF5120 Modellering med Objekter 22.01.2004 3 Telecom and Informatics 5 Krav og forutsetninger Ingen formelle krav (student ved UiO) Kunnskaper