UML - Outline

s s s s s s s

Introduction Requirements Specification Analysis Design Pitfalls and Workarounds Roadmap to UML 2.0 References
1

UML Syntax and Semantics

2000 Abteilung fr Informationssysteme

Motivation for Analysis and Design

Why do we model?
When it comes down to it, the real point of software development is cutting code Diagrams are, after all, just pretty pictures No user is going to thank you for pretty pictures; what a user wants is software that executes
[M. Fowler, UML Distilled, Addison Wesley, 1997]

2000 Abteilung fr Informationssysteme

Motivation for Analysis and Design

The Model as an Abstraction of the Reality
s

We are not able to comprehend a complex system in its entirety - a single model is not enough
x

different perspectives are required, which in turn require different models being independent from each other each model must exist on different levels of granularity

Good models are necessary ...

x x x x

for making complex systems more understandable for visualizing the essential aspects of a system for communication among project members and with the customer for ensuring architectural soundness

2000 Abteilung fr Informationssysteme

What is the UML?

Goals
s

Provide users with an expressive modeling language

x

x x

for the specification, construction, visualization and documentation of the artifacts of a software system for the construction of different kinds of models for the exchange of models however, extensibility and specialization mechanisms are available metamodel in terms of a UML class diagram Semantics is part of the official UML documentation such as collaborations, patterns, and components

Provide users with ready-to-use core concepts

x

Provide a formal basis for understanding the modeling language

x x

Support higher-level development concepts

x

Integrate best practices

2000 Abteilung fr Informationssysteme

What is the UML not?

s

It is the explicit intention of the UML developers not to prescribe

x x x x

a certain process a certain modeling tool any modeling guidelines a certain programming language

Dedicated Goal: Openness!

2000 Abteilung fr Informationssysteme

History of UML
June `99 UML 1.3 OMG accepts the UML as the official industrial standard for software modeling UML 1.1 notations on 17th Nov. 97 Public Feedback Submission to OMG, Sept 97 Submission to OMG, Jan 97 Beta Version OOPSLA 96 WWW-June 96 OOPSLA 95 Method Wars Various Methods
2000 Abteilung fr Informationssysteme

Industrialization

Standardization

UML 1.0 UML 0.9 Unification

Unified Method 0.8 Booch93 Booch91 OMT-2 OMT-1

Fragmentation OOSE
6

The Roots of UML

s

OMT - Object Modeling Technique (James Rumbaugh et al.)

x x

especially suited for analysis of data intensive information systems among others, employment of extended Entity-Relationship diagrams particularly suited for modeling real-time systems and concurrent systems strong relationship to programming languages (Ada) use case-oriented approach excellent support for business engineering and requirements analysis modeling and simulation of telecommunication systems by means of Message Sequence Charts and SDL (Specification and Description Language)

Booch-Method (Grady Booch)

x x

OOSE - Object-Oriented Software Engineering (Ivar Jacobson)

x x x

UML unifies many of their concepts and introduces new ones

2000 Abteilung fr Informationssysteme

Acceptance of UML
The UML Partner Consortium
s s s s s s s s s

Oracle IBM DEC HP TI Unisys i-Logix IntelliCorp Microsoft

s s s s s s s s s

Softeam Sterling Software ICON Computing MCI Systemhouse ObjecTime Platinum Technology Ptech Reich Technologies .....

2000 Abteilung fr Informationssysteme

Competitors of UML
s

Other proposals submitted to OMG for standardization:

x x x x

Catalysis (D. DSouza, A. Wills) Syntropy (S. Cook et al., IBM) OML/Open (B. Henderson-Sellers) Fusion (D. Coleman, HP)

Drawbacks of these approaches:

x x x

they are based on their own processes and their own methods no integration of the major players (except Fusion) little support for different interaction patterns (concurrency and synchronization)

2000 Abteilung fr Informationssysteme

Diagrams of UML
(1) Use Case Diagram (2) Class Diagram (3) Sequence Diagram

Interaction Diagrams

Behavior Diagrams

(4) Collaboration Diagram (5) Statechart Diagram (6) Activity Diagram

Implementation Diagrams

(7) Component Diagram (8) Deployment Diagram

2000 Abteilung fr Informationssysteme

10

Views supported by UML

Use Case View
s

g ass hart Dia m Lo Cl tec tion gra a s St erac Dia s Int tivity s Ac
s

n ig es ram ram s D g al/ Diag Dia gram ic

iew V

s s s

Use Case Diagram Statechart Diagram Interaction Diagrams Activity Diagram

Pr oc s e Cla ss/ s C St ss D on s
s

a c Int tech iagra urr e a en Ac ract rt D m cy ion iag tiv Vie ity Dia ram Dia w gra gram m s

System

Deployment View
s s s s

Component / Impl. View

s s s s

Deployment Diagram Statechart Diagram Interaction Diagrams Activity Diagram

Component Diagram Statechart Diagram Interaction Diagrams Activity Diagram

[after Booch et al., 1999]
11

2000 Abteilung fr Informationssysteme

Ongoing Example
Calendar Manager CALENDARIUM (1/2)
s s

Multi-user calendar manager on Internet basis Visualization

x x x

views on a yearly, monthly, weekly and daily basis insert/update of appointments in each view highlighting of days with appointments (in year view only) single appointments; appointment series possibility to define different kinds of appointments (private, business, etc.) management of a to-do list appointments are relocatable or fixed

Appointments
x x

x x

2000 Abteilung fr Informationssysteme

12

Ongoing Example
Calendar Manager CALENDARIUM (2/2)
s

Communication
x x x x x

timely notification of all persons involved in a appointment advance notice of appointments management of access rights coordination of joint appointments search capability for possible appointments with n participants

s s

Definition of named groups of persons Export of appointments within a certain time frame
x

printer, spread sheet, HTML

Various visualization parameters may be configured by the user

2000 Abteilung fr Informationssysteme

13

Process for Introducing UML

Phases (1/2)
Requirements Specification Contract Analysis
[else] [Requirements Model complete]

Requirements Model Analysis Model

Design
[else] [Analysis Model complete]

Design Model

Implementation
[else] [Design Model complete]

Code

Test
2000 Abteilung fr Informationssysteme 14

Process for Introducing UML

Phases (2/2)
Test

[else] [Test successful] [incremental development necessary] [else]

Start of Operation

[else] [Start of operation successful]

Employment
[Maintenance necessary]
2000 Abteilung fr Informationssysteme

[additional functionality required]

15

Outline
s s s s s s s

Introduction Requirements Specification Analysis Design Pitfalls and Workarounds Roadmap to UML 2.0 References

UML-Syntax and -Semantics

2000 Abteilung fr Informationssysteme

16

Phase 1: Requirements Specification

s

Goal is the description of the required system functionality from the users point of view
x x

Description of the use cases (use case driven) conceptual model of the Universe of Discourse to which the application belongs defines how the system should communicate with its environment, represented by actors

Communication medium between user and developer

2000 Abteilung fr Informationssysteme

17

Models of the Requirements Specification Phase

Constructing the Use Case Model

Constructing the Problem Domain Model

Constructing the Interface Model Interface Model

Use Case Model

Problem Domain Model

[else] [no further use cases]

2000 Abteilung fr Informationssysteme

18

Results of the Requirements Specification Phase

1 1 Use Case Model * UML Use Case Diagram

Description of Use Cases

Requirements Model

1 Problem Domain Model

UML Class Diagram

* 1 Interface Model *
2000 Abteilung fr Informationssysteme

UI Specification

Spec. of System Interfaces

19

Use Case Model

System, Actor and Use Case
s

Functional decomposition of the system into use cases and actors interacting with them
x

use cases represent the requirements of the customers

Results of constructing the use case model:

x x

global use case diagram a detailed textual description for each use case

2000 Abteilung fr Informationssysteme

20

Use Case Diagram

CALENDARIUM
CALENDARIUM query appointment

export appointments delete appointment

User insert appointment

change appointment

2000 Abteilung fr Informationssysteme

21

Actor (1/2)
s

Actors interact with the system

x x

x x

by using the system, i.e., by initiating the execution of use cases by being used by the system, i.e., by providing functionality for realizing use cases each actor is required to communicate with at least one use case the communication relationship is undirected concrete users are allowed to adopt/play/discard more than one role at a time actors are located outside the system boundaries

Actors represent roles

x

actor User User

2000 Abteilung fr Informationssysteme

22

Actor (2/2)
s

Classification
x x x

x x

human: e.g. novice/trained user; system administrator non-human: e.g., fax, e-mail primary: ultimate user of the system secondary: ensures the correct functionality of the system active: initiates use cases passive: corresponding use case is initiated by the system Who uses the essential use cases? Who needs system support in order to fulfil the daily tasks? Who is responsible for system administration? What are the external devices/software systems the system has to communicate with? Who is interested in the results of the system?

Questions for identifying actors:

x x x x x

2000 Abteilung fr Informationssysteme

23

Use Case
s s

Use cases represent the functionality expected by the system under development Identification of use cases can be done by collecting user requirements and by analyzing the problem description

Short Description:
An appointment can be inserted for one or more participants by an authorized user, who does not need to be one of the participants. All participants must be notified of this new appointment. New appointments must be visualized immediately in all open calendars of the respective participants.

insert appointment

Note
2000 Abteilung fr Informationssysteme 24

Relationships Between Use Cases (1/4)

s

include -Relationship
x

the behavior of B is included into A the included use case B is necessary to ensure the functionality of the base use case A formerly called uses -relationship A include B

base use case; needs B

2000 Abteilung fr Informationssysteme

included use case; is self-contained

25

Relationships Between Use Cases (2/4)

s

extend -Relationship
x

the behavior of B may be incorporated into A the extending use case B may be (but need not be) activated by the base use case A extension points specify the location where the extending use case extends the base use case A extend B

base use case; is self-contained; controls, if B is executed or not

2000 Abteilung fr Informationssysteme

extending use case; is self-contained

26

Relationships Between Use Cases (3/4)

configure program extension points Modify access rights Modify parameters
x x x x

extend rights) odify access cted] (M ts sele [Access righ

configure access rights configure parameters

extend (Modify paramet [Parame e ters sele rs) cted]

the condition under which the extending use case is incorporated has to be specified more than one extension point can be specified for each use case the names of extension points have to be unique the names of extension points need not be equal with the names of the extending use cases

2000 Abteilung fr Informationssysteme

27

Relationships Between Use Cases (4/4)

s

Generalization Relationship
x x x x

similar to the generalization relationship between classes B inherits the behavior of A and is allowed to override and extend it B inherits all relationships of A modeling of abstract use cases is also possible ({abstract})

base use case; is self-contained

sub use case; needs A (gets base functionality from A); controls, what is executed from A and what gets changed
28

2000 Abteilung fr Informationssysteme

Use Case Diagram

CALENDARIUM (refined, 1/2)
CALENDARIUM query entry export entries change entry

delete entry

User

insert entry configure Program extend configure access rights

include include include update calendar notify participants configure parameters administer users

actor Fax-System actor E-Mail-System

Administrator

administer entry types

29

2000 Abteilung fr Informationssysteme

Use Case Diagram

CALENDARIUM (refined, 2/2)
insert entry {abstract} User insert appointment insert to-do entry

Analogous for query/export/delete/change entry

2000 Abteilung fr Informationssysteme

30

Excursion (1/4)
Semantics of the include-Relationship
A include
s

B
s

Problem: Where and how should include be located within the base use case ? Possible solution: Probes from OOSE

2000 Abteilung fr Informationssysteme

31

Excursion (2/4)
Semantics of the extend-Relationship

extend

B A

inner of the language BETA

2222 Abteilung fr Informationssysteme 33

Excursion (3/4)
Semantics of the Generalization Relationship
A

B B A

super of the language Smalltalk

2000 Abteilung fr Informationssysteme 33

Excursion (4/4)
Generalization Relationship between Actors
s

s s

An actor A which inherits another actor B is able to communicate with the same use cases as B Multiple inheritance also allowed It can be distinguished whether multiple actors have to communicate with a use case in common or not

A A B
2000 Abteilung fr Informationssysteme

B B

34

Partitioning Use Case Diagrams

Package (1/3)
s

s s

Large use case diagrams are becoming too complex and confusing (as is the case for all diagrams :-() UML abstraction mechanism: Package Criteria for partitioning:
x x x x

Functional cohesion Actors Experience systemModel systemModel CALENDARIUM .... Appointment Manager
35

System Administration

2000 Abteilung fr Informationssysteme

Partitioning Use Case Diagrams

Package (2/3)
Appointment Manager query entry User update calender

include delete entry include

insert entry

include include change entry include include notify participants

export entries

actor E-Mail-System
2000 Abteilung fr Informationssysteme

actor Fax-System
36

Partitioning Use Case Diagrams

Package (3/3)
System Administration

configure program User administer users

extend extend

configure parameters

configure access rights administer entry types

Administrator
2000 Abteilung fr Informationssysteme

37

Excursion (1/4)
Description of Use Case
s s s s s s s s s

Name/Short Description Preconditions: prerequisites for successful execution Postcondition: system state upon successful completion Failure Situations: only domain-related failures Postcondition in case of failure Actors: communicating with the use case Trigger: initiating event for the use case Main Success Scenario: single (atomic) steps/other use cases Extensions/Variations: deviations from main success scenario
[cf.: A. Cockburn, Goals and Use Cases. JOOP, Sept. 1997]

2000 Abteilung fr Informationssysteme

38

Excursion (2/4)
Description of Use Case - Insert Appointment
s

Name and Short Description: Insert appointment

An appointment can be inserted for one or more participants by an authorized user, who does not need to be one of the participants. All participants must be notified of this new appointment. New appointments must be visualized immediately in all open calendars of the respective participants.
s s

Precondition: User is known by the system. Postcondition:

x x

New appointment is inserted. All participants are notified either about the new appointment or that due to authorization problems it was not possible to change their calendar. All calendar views are updated.

x s

Failure Situations: The user lacks proper authorization for every participant in order to insert the new appointment into their calendars.

2000 Abteilung fr Informationssysteme

39

Excursion (3/4)
Description of Use Case - Insert appointment
s

Postcondition in case of failure:

x x

appointment couldn not be inserted. The calendars of all participants as well as their views havent been changed by the use case.

Actors: User (primary actor), E-Mail-System (secondary actor), Fax-System (secundary actor). Trigger: Main Success Scenario: (1) User identifies him/herself. (2) The details of the new appointment (time, location, duration, participants, etc.) are being recorded. (3) User is authorized to insert the appointment for all participants. (4) appointment does not cause any collisions and is inserted.

s s

2000 Abteilung fr Informationssysteme

40

Excursion (4/4)
Description of Use Case - Insert appointment
(5) All participants (except the user in case (s)he is a participant too) are notified according to their preferred type of communication (include notify participants) (6) All currently open calendars of participants are updated. (include update
calendar)
s

Extensions/Variations: (3) For at least one participant, the user is not authorized to insert a appointment. (4) Analogous to (4) (5) Analogous to 5, whereas each participant whose calendar could not be changed is notified about this authorization problem. (6) All calendars of participants without authorization problems are updated, where proper authorization exists.

2000 Abteilung fr Informationssysteme

41

Problem Domain Model

s

Represents the conceptual model of the problem domain (also called universe of discourse)
x x

does not contain any implementation details supports the communication between developer and user

Result of problem domain modeling:

x

class diagram, visualizing the static structure of the system under development (static structure diagram)

2000 Abteilung fr Informationssysteme

42

Class and Object

s

Class:
User name: String authorization: Right pwd: String number: Integer validatePW (PW: String): bool computeNumber(): Integer

Attributes Operations

Class Attribute Class Operation

Object: Name of object (and class) is underlined

aUser : User aUser : User
43

2000 Abteilung fr Informationssysteme

Characteristics of a Class
s s

Class attributes/operations: underlined Properties of attributes:

x x

/ attribute name: derived attribute {optional}: null values permitted {query}: operation without side effects {sequential}, {guarded}, {concurrent}: kind of concurrency + ... public - ... private # ... protected

Properties of operations:
x x

Visibilities:
x x x

2000 Abteilung fr Informationssysteme

44

Abstract Class
s s s

Cannot be instantiated Useful for generalization hierarchies only Factors out common properties of subclasses

Entry {abstract}
s

or

Entry

The same notation is used in order to distinguish between abstract operations and implemented operations

2000 Abteilung fr Informationssysteme

45

Excursion (1/3)
Identification of Classes
s

Linguistic analysis of the problem description - extraction of nouns Rules of thumb:

x x x x x x

elimination of irrelevant terms elimination of names of values elimination of vague terms identification of attributes identification of operations elimination of terms which are in fact relationships

[cf.: R.J. Abbott, Program Design by Informal English Descriptions, CACM, Vol. 26, No. 11, 1983]
2000 Abteilung fr Informationssysteme 46

Excursion (2/3)
Identification of Attributes
s

Linguistic analysis of the problem description - extraction of adjectives and participles Rules of thumb:
x

x x

attributes describe objects and should be neither class-valued nor multi-valued derived attributes should be marked as such context-dependent attributes should be assigned to associations rather than to classes

The list of attributes is usually incomplete in the problem description

[cf.: R.J. Abbott, Program Design by Informal English Descriptions, CACM, Vol. 26, No. 11, 1983]

2000 Abteilung fr Informationssysteme

47

Excursion (3/3)
Identification of Operations
s

Linguistic analysis of the problem description - extraction of verbs Rules of thumb:

x x

x x x

which operations can be executed by a certain object not only the current requirements should be considered, but also reusability should be taken into account which events are expected which objects can react to these events which other events are raised in turn

[cf.: R.J. Abbott, Program Design by Informal English Descriptions, CACM, Vol. 26, No. 11, 1983]
2000 Abteilung fr Informationssysteme 48

Classes in Different Phases

Requirements Specification: Appointment / visualization: Color start: DateTime description: String duration: Time hyperlink[0..1]: URL type: AppointmentType numberOfAppointments: Int {visualization = colorCode(type)}
(t.startDate=startDate (t.startTime startTime+duration t.startTime+t.duration startTime))

Design: entity Appointment {persistence=persistent} - startDate: Date - startTime: Time = 09:00 - duration: Time = 01:00 - description: String = "" +visualization(): Color +collidesWith (t: Appointment): bool ...

Note

2000 Abteilung fr Informationssysteme

49

Association (1/3)
s

Association between classes

x x x x x

association name (optional) arrow above each edge expresses reading direction (optional) arrow at the end of an edge expresses navigation direction (optional) each end of an association is defined by means of multiplicity for a binary association, the multiplicity on the target end contrains how many objects of the target class may be associated with a given single object from the other (source) end

Calendar
s
x

1..*

attachedTo *

Appointment
attachedTo

Link between objects

represents an instance of an association

aCalendar : Calendar

a1:Appointment

attachedTo a2:Appointment
50

2000 Abteilung fr Informationssysteme

Association (2/3)
Multiplicity
s s s

arbitrary number * a range is specified by means of .. possible numbers are separated by means of commas

exactly 1: 1 0: * (or 0..*) 0 1: 0..1 fixed number (e.g. 3): 3 range (e.g. 3 or more): 3..* range (e.g. 3-6): 3..6 enumeration (e.g. 3,6,7,8,9): 3, 6..9
2000 Abteilung fr Informationssysteme 51

Association (3/3)
Role
s

Classes play roles within associations

x

a single class can play more than one role

Insurance Company

1 insurer

issued by

0..*

Insurance Contract
refers to
0..*

married to 0..* subordinate 0..1 superior

Employee
0..* peer

0..*

0..1 husband

wife 0..1 1..*

policyholder

Person

married to is still incompletely specified...

Properties of Associations (1/2)

s

{sorted}
Calendar isOpen 1..* {sorted} * Appointment /visualization start description duration type

{ordered}

1 * contains Queue independent of QueueItem attributes. Ordering is {ordered}

QueueItem

2000 Abteilung fr Informationssysteme

53

Properties of Associations (2/2)

s

Exclusive Or {xor}
x

SerialEntry 1

1 {xor} 1..* {sorted}

only one of a set of possible associations can be instantiated for a certain object at a certain time

1..* {sorted} ToDoEntry

Appointment

{subset}
User coordinator 1 1..* participant participates {subset} coordinates * Appointment *

2000 Abteilung fr Informationssysteme

54

Qualified Association
s

A Qualifier is an attribute or a list of attributes

x

Bank *

Bank
account#

whose values partition the objects * of the associated class in a disjoint Person manner in most cases, multiplicity is reduced to one

* 0..1 Person

Represents a property of the association

1 manages 1 groupName Owner User name Participant 1..*

GroupOfParticipants *

consistsOf
2000 Abteilung fr Informationssysteme 55

Association Class (1/2)

s

Necessary in case of m:n-associations with attributes:

User 1..* Participation * Appointment association class

isRelocatable

It enhances flexibility in case of 1:1 and 1:n-associations:

Company name address 1 Employment loan position * Person name socSec# address loan position
56

2000 Abteilung fr Informationssysteme

Association Class (2/2)

Person 1 * * Employment qualificationProfile hours dailyRate 1

Object Class Association Class

Project P1 E1 E2 E3 P2 Person * Employment qualificationProfile hours dailyRate P2
2000 Abteilung fr Informationssysteme

Pr1

E4

Pr2

Project P1 E1 E3 E4 Pr2
57

Pr1

N-ary Association
s

Relationship between more than two classes

x

navigation direction cannot be specified Calendar * User * * AppointmentType

Example of a ternary association:

Authorization
set of [r, w, d] validateAuth(...)
2000 Abteilung fr Informationssysteme

association class

58

Aggregation
s

Aggregation is a special kind of association having the following properties:

x

Transitivity: C is part of B and B is part of A C is part of A Anti-Symmetry: B is part of A A is NOT part of B

UML supports two kinds of aggregation:

x x

weak aggregation Composition

2000 Abteilung fr Informationssysteme

59

Weak Aggregation
s

The multiplicity at the aggregate end may be > 1

A * * B

Properties:
x x x

weak relationship, i.e., parts are independent of the whole there is almost no propagation semantics the aggregated objects form a directed, acyclic graph *

GroupOfPersons

User

2000 Abteilung fr Informationssysteme

60

Composition
s

The multiplicity at the aggregate end must be <= 1

A
0..1

Properties:
x

x x x

a certain part can be incorporated at a certain time in at most one composite object only the parts are dependent on the composite object propagation semantics the composite objects form a tree Graphic Paragraph * * * *
61

Document

Annotation

2000 Abteilung fr Informationssysteme

Composition vs. Association

Rules of Thumb
s

Physically embedded vs. references:

x x

the parts are physically embedded within the composite object objects are associated by means of references the part is visible for the composite object only the visibility of the associated object is public the composite object creates and deletes its parts there is no existential dependency between associated objects composite objects and parts are copied together only the references to associated objects are copied

Visibility:
x x

Life Time:
x x

Copy Semantics:
x x

2000 Abteilung fr Informationssysteme

62

Generalization (1/2)
s

is a taxonomic relationship between a specialized class and a more general class

x x x

the specialized one inherits all properties of the generalized one additional properties can be added an instance of the subclass can be used wherever an instance of the superclass is allowed (at least syntactically) multiple inheritance is also allowed: University Member
{overlapping}

...
The model contains more subclasses than actually shown in this diagram
2000 Abteilung fr Informationssysteme

Student

Lecturer

Instructor
63

Generalization (2/2)
s

Properties of Generalization:
x

non-complete / complete (default) 3 complete: all possible subclasses are already part of the model (but not necessarily visualized!) overlapping / disjoint (default) 3 2 interpretations of overlapping: Concerning multiple inheritance: two or more subclasses can have again common subclasses (e.g. Instructor) Concerning multiple classification: an object can be instance of more than one subclass
Entry 2 alternative notations ToDoEntry Employee {incomplete, overlapping}

{complete, disjoint}

Appointment SerialEntry

Technical Employee

Administrative Employee
64

2000 Abteilung fr Informationssysteme

Generalization of Associations
s

Used for restricting the possible links between objects whose superclasses are associated with each other

Entry

visualizes

0..1

B_Entry

ToDoEntry Appointment
2000 Abteilung fr Informationssysteme

B_ToDoEntry B_Appointment
65

Template Class
s

A template class describes a family of classes on the basis of formal parameters

x

each class is specified by binding the parameters with actual values Array
length: 0..k ...

T,k: Int

Alternative 1: Array<Point,3>

putAt (e: T, i: Int) at (i: Int): T

Alternative 2: bind (Point,3) ListOfPoints

6 6 Abteilung fr Informationssysteme 66

6 6

Interface
s

Required behavior is defined by specifying the necessary operations

x x x

of a class of a component of a package abstract class contains operations AND attributes abstract class can be realized by subclasses only, whereas an interface can be realized by means of arbitrary classes

Difference to abstract classes

x x

Classes realizing a certain interface (supplier) can contain additional operations Classes using an interface (clients) are not forced to use all available operations

6 6 Abteilung fr Informationssysteme 66

6 6

Example CALENDARIUM
Interface SMTPServer
Client Email SMTPServer Qsmtp Supplier

Email Email (String to, String message) notify() use mailer.open (mailbox.univie.ac.at, 25); mailer.sendmsg (CALENDARIUM, [email protected], Reminder, Meeting at 12.1.99, 14:00); mailer.close();
6 6 Abteilung fr Informationssysteme 66

Qsmtp +open (String hostId, int port=25) +sendmsg (String from, String to, String subject, String message) +close() +Qsmtp () #finalize()
6 6

interface SMTPServer open (String hostId, int port) sendmsg (String from, String to, String subject, String message) close()

realize

Benefits of Interfaces
s

By means of interfaces, the inheritance of implementations can be separated from the inheritance of interfaces
x

frameworks especially are built on the basis of interfaces

A class can be seen as a set of roles which are specified by means of use cases
x x x

each interface represents a role played by the class different clients use only those roles which are interesting for them by means of interfaces, different views on a class can be realized for different clients coupling is reduced, flexibility with respect to maintenance and extensibility is increased

6 6 Abteilung fr Informationssysteme 66

6 6

Interface Model
s

Goals
x

Specification of the user interface for each use case / actor

not explicitly supported by UML

Specification of the internal interfaces

supported by UML in terms of interfaces

6 6 Abteilung fr Informationssysteme 66

6 6

User Interface Specification

Example (1/2 - Poor Mans Prototype)
GK (1) MH (2)
Monday 28 Tuesday 29 Wednesday Thursday 30 10-12 31 Consult Hour (2) 6 7 13 10-12 Consult Hour (2) 11-12 Consult Hour (1) 20 10-12 Consult Hour (2) 11-12 Consult Hour (1) 27 10-12 Consult Hour (2) 14 8-9:30 InfoSys II (1) Friday 1 Saturday 2 Sunday 3 *Konstantin (2) 10 17

4 11 Meeting (1,2)

5 12 14-17 UML Meeting (2)

8 16-18 C++ (2) 15 16-18 C++ (2)

9 16

January 1999
18 19

21 8-9:30 InfoSys II (1)

22 16-18 C++ (2)

23

24

T M

W J

25

26

28 8-9:30 InfoSys II (1)

29 16-18 30 C++ (2) 17-18 Infosys II Exam.

31

6 6 Abteilung fr Informationssysteme 66

6 6

User Interface Specification

Example (2/2 - GUI Builder Prototype)

6 6 Abteilung fr Informationssysteme 66

6 6

UML Extensibility Mechanisms (1/3)

s

Stereotype:
x x x

each model element can be further classified by means of a stereotype ... near the name of the element used instead of an extension of the metaclass hierarchy arbitrary information can be attached to a model element is not interpreted by UML there exist pre-defined ones, e.g., persistence={transitory,persistent} there may be user-defined ones, e.g., author={...} can be defined in an arbitrary language, e.g., OCL (Object Constraint Language) Example for a predefined one: generalization may be overlapping or disjoint

Tagged Value:
x x x x

Constraint:
x x

2000 Abteilung fr Informationssysteme

73

UML Extensibility Mechanisms (2/3)

Visualization of Stereotypes

entity

entity

Appointment

Appointment

Appointment

Appointment

2000 Abteilung fr Informationssysteme

74

UML Extensibility Mechanisms (3/3)

Example of a Constraint
1 remindsOf

Entry
*

{ n Notification: n.User n.Entry.participant} 1..* participant 0..3 isDirectedTo *

User

1..*

Notification

In OCL: Notification entry.participant->includesAll(user)

2000 Abteilung fr Informationssysteme 75

UML - Metamodel (1/3)

s s

Represents a predefined class diagram Contains all UML model concepts in terms of so-called meta model classes Purpose:
x x x

formal specification common exchange format for tool vendors proper extension possible

Similar to data dictionary in relational database systems

2000 Abteilung fr Informationssysteme

76

UML - Metamodel (2/3)

Small Extract of the Metamodel
ModelElement
name: Name 1 Generalizable- suptype * Element 1

BeispielBeispielInstantiierung (etwa Instantiierung (etwa f. "ModelElement") f. "ModelElement") ??

Generalization
*

Feature
ownerScore: ScopeKind visibility: VisibilityKind

* discriminator: Name isRoot: Boolean supertype isLeaf: Boolean isAbstract: Boolean

StructuralFeature Classifier 1
multiplicity: Multiplicity * changeable: ChangeableKind Interface targetScope: ScopeKind type

BehavioralFeature
IsQuery: Boolean

Operation
specification: Uninterpreted isPolymorphic: Boolean concurrency: CallConcurKind
77

Datatype
metaclass

Attribute
initialValue: Expression

isActive: Boolean
2000 Abteilung fr Informationssysteme

Class

UML-Metamodel (3/3)
Extensibility Mechanisms in the Metamodel

0..1

ModelElement
{ordered} 1..*

TaggedValue
tag: Name value: Uninterpreted

GeneralizableElement

Constraint *

requiredTag *

Stereotype
0..1 icon: Geometry

baseClass: Name

0..1

2000 Abteilung fr Informationssysteme

78

Outline
s s s s s s s

Introduction Requirements Specification Analysis Design Pitfalls and Workarounds Roadmap to UML 2.0 References

UMLSyntax and Semantics

2000 Abteilung fr Informationssysteme

79

Phase 2: Analysis
s

Goal is a detailed analysis of problem domain and use cases

x x x x

complementation of the model by means of additional objects definition / refinement of the objects structure definition of the objects behavior definition of the interaction between the objects

Preservation of a certain level of abstraction enhances the potential of reusability Categorization of objects increases locality of changes and therefore leads to a more stable system architecture
x x x

entity objects boundary objects control objects

2000 Abteilung fr Informationssysteme

80

Models of the Analysis Phase

Refining the Problem Domain Model Structure Model [constructed]

Constructing the Behavior Model Behavior Model [constructed]

[else] [no additional refinements necessary]
81

2000 Abteilung fr Informationssysteme

Results of the Analysis Phase

1 Structure Model 1 UML Class Diagram

UML Sequence Diagram UML Collaboration Diagram UML Statechart Diagram UML Activity Diagram
82

* Analysis Model 1 Behavior Model

*
2000 Abteilung fr Informationssysteme

Structure Model

The structure model is a refinement of the problem domain model

x

a copy of the problem domain model is used as the basis of a contract between client and developer

Partitioning of the Structure Model

x

UML Packages

2000 Abteilung fr Informationssysteme

83

Example CALENDARIUM
Extract of the Class Diagram (1/2)
manages 1

CALENDARIUM 1

manages

GroupOfPersons
{sorted} Calendar 1..* * Entry User * 1..* * isisOpen: bool name partici- /visualization: Color AttachedTo isDirectedTo * * authorization pates description: String visualizes * 1 type: ApptmentType * Notification 0..3 remindsOf View * * *

Appointment
start: DateTime duration: Time * hyperlink [0..1]: URL nOfAppts: Int
* 1..* {sorted}

Series Entry
duration frequency
1 {xor} 1

ToDoEntry
deadline: Date
1..* {sorted}

/collidesWith

2000 Abteilung fr Informationssysteme

84

Example CALENDARIUM
Extract of the Class Diagram (2/2)
control C_User
C_User(b:User) C_User() start() finish() 1 1

boundary B_User
B_User(b:User) validate():bool start() 0..1 instantiate

instantiate

entity User
User() save() delete()
85

control CALENDARIUM
2000 Abteilung fr Informationssysteme

Partitioning of the Class Diagram

Package
s s s

Large class diagrams are quickly getting complex and confusing UML abstraction mechanism: Package Criteria for partitioning:
x x x x x

Functional cohesion Informational cohesion Access control Distribution structure ....

s s

Elements of a package may be all kinds of UML model elements Visibility of elements may be restricted (+,#,-)

2000 Abteilung fr Informationssysteme

86

Dependencies between Packages

s

Evt. auch importEvt. auch importFolie ? Folie ?

Elements of one package require elements of another one

x

Sichtbarkeit Sichtbarkeit zwischen Paketen? zwischen Paketen?

x x

access-dependency on the Package level of packages X forms a graph access-dependencies are NOT transitive!

access

Package Y

Certain elements of a package require certain elements of another one

x x

specific relationship on the element level or incorporation by means of qualification access

Class B Package Y Class C Class D

Package X Class A Class B

Package X Class A

Package Y ::Class C
87

2000 Abteilung fr Informationssysteme

Kinds of Packages
s

Package
x

represents a grouping mechanism only

Subsystem
x

x x

allows also the specification of the behavior of a package interfaces and operations may be specified icon: describes a certain view of the system to be modeled icon:

subsystem subsystem

Model
x

model model

2000 Abteilung fr Informationssysteme

88

SichtbarkeitSichtbarkeitBsp. fehlt Bsp. fehlt

Packages and Subsystems

s

Interfaces offer part of the behavior of packages (subsystems!)

x

realized by means of an arbitrary number of classes within the package

Package X Class A
s

I Class B

subsystem Package Y Class C Class D

Packages can be nested

x

x x

semantics is determined by the implementation language arbitrary depth package hierarchy forms a tree

Package X Class A Class B

Package Y

2000 Abteilung fr Informationssysteme

89

Generalization
s

Generalization relationships between packages subsystem There exists at least one Editor generalization relationship Controller between the elements of the access respective packages
access

Diagram Elements
access

access

Domain Elements

Graphics Core
access

Windowing System Motif

access

MotifCore

WindowsCore
2000 Abteilung fr Informationssysteme

MSWindows
90

Example CALENDARIUM
Packages
CALENDARIUM
User Interface B_Calendar B_Calendarium B_Appointment Appointment Manager
access

systemModel

...

User Appointment Calendar

Calendarium

access

...

System Administration

access

2000 Abteilung fr Informationssysteme

91

Dr. Martin Hitz: Dr. Martin Hitz: Nur mit Bsp. gut! Nur mit Bsp. gut!

Excursion
Employment of Packages
s

Bottom-up approach
x x x

a-posteriori-decomposition of class diagrams goal is small units and intuitive groupings packages are automatically disjoint a-priori-allocation of use cases to packages goal is distribution of work similar concepts may occur several times in multiple packages recognize common properties (Generalization?) factor out classes explicitly import classes and operations

Top-down approach
x x x

Normalization of packages eliminates redundancies

x x x

2000 Abteilung fr Informationssysteme

92

Behavioral Model
s

Goal
x

Specification of the inter-object behavior (interaction structure, responsibilities)

interaction diagrams: sequence diagram collaboration diagram statechart diagram activity diagram

Specification of the intra-object behavior statechart diagram

93

2000 Abteilung fr Informationssysteme

Interaction Diagrams
s

Illustrate the communication between objects Purpose:

x x

Specifying the realization of an operation Specifying the realization of a use case

2 Kinds:
x

generic kind, i.e., all possible scenarios are described by means of branching and iteration exemplary kind, i.e., one certain scenario is described

2000 Abteilung fr Informationssysteme

94

Interaction Diagrams
Sequence and Collaboration Diagram
s s

Both specify the same information However, each emphasizes different aspects
x

sequence diagram is temporally-oriented 3 shows graphically the order of messages 3 does not show how to get the receiver object collaboration diagram is spatially-oriented 3 shows the static and dynamic relationships between objects - the context aspect 1 3 the order of messages is expressed by means of decimal classification only 3 time is no dimension on its own

1.1

1.2

2000 Abteilung fr Informationssysteme

95

Interaction Diagrams
Sequence Diagram
s

Objects are represented by means of vertical lines (lifelines)

x x

depict also the time line the horizontal ordering of the objects has no meaning

s s

An activation (focus of control) shows the period during which an object is directly or indirectly executing an operation Messages between objects are denoted by means of arrows [Guard] specifies conditional sending of messages
: User : Calendar totalDuration() a1:Appointment duration() duration() return(meetingTime)
96

a2:Appointment

return(meetingTime) return(total)
2000 Abteilung fr Informationssysteme

Interaction Diagrams
Sequence Diagram - Example
: User
example insertAppt(a1)

: Calendar
new()

a: Appointment a1:Appointment
Treibendes Treibendes Objekt fehlt Objekt fehlt

deleteAppt(a2)

a2:Appointment
delete()

totalDuration() a = 1 .. nOfAppts type() return(aType) [aType private] duration() return(total)

2000 Abteilung fr Informationssysteme

return(meetingTime)
97

Interaction Diagrams
Collaboration Diagram
s

Examples of messages (events):

x x

simple message:

2: display(x,y)

nested call including return value: 1.3.1: p:= find (specs) conditional message: [x<0] 4: invert(x,color) synchronization with other threads and iterations: A3, B4 / C3.1*|| [i:= 1..n]: update

x x

1.1 : meetingTime:= duration() 1 : total:= totalDuration() : User : Calendar a1:Appointment 1.2 : meetingTime:= duration() a2:Appointment
98

2000 Abteilung fr Informationssysteme

Interaction Diagrams
Collaboration Diagram - Example
1: insertAppt(a1) 3: total := totalDuration() 1.1: new()

a1:Appointment {new}

: User

: Calendar

3.1*[i=1..nOfAppts]:complete

2: deleteAppt(a2) 3.1.2: aType := type () 3.1.3 [aType private]: meetingTime := duration()

2.1: delete()

a2:Appointment {destroyed}

3.1.1: a := select(i)

a:Appointment

: Appointment

2000 Abteilung fr Informationssysteme

99

Interaction Diagrams
Relationships & Roles in Collaboration Diagrams
s

The kind of relationship between sender object and receiver object may be specified (:: Sequence Diagram!)
x x x x x

attribute global variable local variable (temporary object) parameter self referencing

association global local parameter self

(default)

:Calendarium

readAuthorization( ) loggedInUser local

: User

2000 Abteilung fr Informationssysteme

100

Interaction Diagrams
Collaboration Diagram - Example
redisplay() :Controller 1: displayPositions (window) self 1.1*[i:=1..n]: draw Segment(i) wire wire: Wire i-1 i local line 1.1.2: create(r0,r1) 1.1.3: display(window) window :Window 1.1.3.1: add(self) contents {new} :Line {new}

parameter window

1.1.1a: r0:=position() left: Bead

1.1.1b: r1:=position() right: Bead

[from Rumbaugh et al. 1999, p.202]

101

2000 Abteilung fr Informationssysteme

Interaction Diagrams
Numbering of Messages
s

Ordering of messages is defined by means of a nested numbering scheme Decimal classification:

x x

n.m mth message with the realization of message n If the only differences between two or more message numbers are the names at their end, then they may be potentially executed in parallel: 1.1.1a can be executed at the same time as 1.1.1b (both represent message 1.1.1)

In case of asynchronous control flow decimal classification is not used

2000 Abteilung fr Informationssysteme

102

Interaction Diagrams
Kinds of Control Flow
s

Synchronous
x

a nested control flow, typically realized as a procedure call optional is used if kind of control flow is not of interest at this point in time (however, typically asynchronous)

Return
x

Unspecified
x

Asynchronous holds for sequence and collaboration diagrams

2000 Abteilung fr Informationssysteme

103

Example CALENDARIUM
Sequence Diagram Insert Appointment (1/2)
: B_Calendarium login(...) c : Calendarium User: Class pa : User Authorization : Class ca : Calendar

login(user,pwd) ok storeAppt (partic,appt)

login(user,pwd) ok

new appt

forall pa in partic checkAuthorization (user, pa, write) authorized forall pa in partic checkCollision (bD, eD) ok
2000 Abteilung fr Informationssysteme

checkCollision (bD, eD) ok

104

Example CALENDARIUM
Sequence Diagram Insert Appointment (2/2)
: B_Calendarium c : Calendarium User: Class pa : User Authorization : Class ca : Calendar cv : Calendar View

d_new := new (...)

d_new : Appointment

forall pa in partic insertAppt(d_new) done

Observer !

insertAppt(d_new) update( ) notify(d_new) forall cv

2000 Abteilung fr Informationssysteme

105

Statechart Diagram
s

describes
x x

the life cycle of the instances of a class the execution of an operation on an instance of a class

models
x x x x

the possible states of the instances of a class the possible transitions from one state to another one the events firing transitions the operations (actions and activities) which are executed within states or during a transition

2000 Abteilung fr Informationssysteme

106

Statechart Diagram
Kinds of Events
s s s s

CallEvent: receipt of a message: SignalEvent: receipt of a signal: ChangeEvent: a condition evaluates to true: TimeEvent: relative or absolute point in time:
automatic transition
cancel

cancel left_button_down when(x<y) after(5 sec.)

Canceled delete

Appointment start duration cancel () delete ()

new

Enter Details

Active delete

when(start+duration<=now)
2000 Abteilung fr Informationssysteme

Finished

107

Statechart Diagrams
State
s

State:
x x

state (in the strict sense) final state

Pseudostates:
x x

initial state history state, synch state, fork, join etc. action: atomic and non-interruptible activity: complex (possibly nested statechart diagram) and interruptible entry / action exit / action do / activity event / action action is executed when entering the state action is executed when leaving the state activity is executed, parameters are allowed event is handled within the state
108

Action and Activity:

x x

Action / Activity within a state:

x x x x

2000 Abteilung fr Informationssysteme

Statechart Diagram
State Transition
s

A state transition takes place, if

x x

the event occurs and the guard is true the lack of an event corresponds to the event activity is finished (completion transition) the lack of a condition corresponds to [true] Special action: Sending a message to another object send receiver.message() Example:
right-mouse-down (loc) [ loc in window ] / obj:= pick-obj (loc); send obj.highlight()

Default Assumptions
x

Actions on state transitions are possible

x

2000 Abteilung fr Informationssysteme

109

Statechart Diagram
Example
DigitalWatch modeButton() inc()

self transition
Display time do/ display current time mode Button new

inc / hours:= hours+1 Set hours entry/ beep do/ display hours modeButton mode Button

inc / min:= min+1 Set minutes entry/ beep do/ display minutes

2000 Abteilung fr Informationssysteme

110

Statechart Diagram
Refining Statechart Diagrams
s

Refinement of a state by means of a nested statechart diagram

x

disjoint substates (OR-refinement) exactly one substate is active in case that the superordinate state (complex state, super state) is active parallel substates (AND-refinement) all substates are active in case that the super state is active; the substates are again or-refined

Z A B Z A B
111

2000 Abteilung fr Informationssysteme

Statechart Diagram
Example Appointment (1/2)

cancel

Cancelled delete

new

Enter Details

Active

when(start+duration<=now)

Finished

2000 Abteilung fr Informationssysteme

112

Statechart Diagram
Example Appointment (2/2)
Active

Oberes Subdiagramm Oberes Subdiagramm ist inhaltlich kaum ist inhaltlich kaum argumentierbar und argumentierbar und die Zustandsnamen die Zustandsnamen (abonniert) sind nicht (abonniert) sind nicht intuitiv intuitiv

Occurred Not Current when(start<=now) Current when(start+duration<=now)

Fixed

reschedule (newStart) [not in Current] / start:=newStart

Reschedule do/ notify participants and update views

cancel

Cancelled

2000 Abteilung fr Informationssysteme

113

Statechart Diagram
History State (1/2)
s

Complex states are able to remember the internal state which had been left due to an interruption At a later point in time, one can go back to this internal state by means of a transition from superordinate states via a dummy state H
x

all entry actions are executed again

By means of H* all states along the given nesting depth are memorized

2000 Abteilung fr Informationssysteme

114

Statechart Diagram
History State (2/2)

Folie ber Folie ber Zusammenfassung Zusammenfassung Eingang / /Ausgang Eingang Ausgang in / /aus komplexen in aus komplexen Zustand Zustand

Folie ber Folie ber Pseudozustnde: Pseudozustnde: junction, synch, junction, synch, stub, decision stub, decision join / /fork join fork

+ H Deposit(b) / Balance := Balance + b

when(Balance < 0) when(Balance > 0)

Balancing [not in Frozen] / Balance := 0

Withdrawal(b) [not in Frozen] /Balance := Balance - b Freeze Unfreeze

Open / Balance := 0

Normal

Frozen

2000 Abteilung fr Informationssysteme

115

Statechart Diagram
Semantics of AND-Refinements
+/N when(Balance < 0) when(Balance > 0) H -/N

Balancing / Balance := 0

Unfreeze Unfreeze
H* +/F

Unfreeze Unfreeze

Deposit(b) / Balance := Balance + b

2000 Abteilung fr Informationssysteme 116

Freeze Freeze

Freeze Freeze

Withdrawal(b) /Balance := Balance - b when(Balance < 0) when(Balance > 0)

Open / Balance := 0

-/F

Statechart Diagram
Stubbed State
Question yes no

Question F1 / display help do / pose question da yes njet no

2000 Abteilung fr Informationssysteme

117

Statechart Diagram
Synch State
P1 P2

k
s

s s

Synchronization of control C1 C2 between two concurrent regions Producer-Consumer Upon activation, a token is inserted into the synch state (at most k tokens, k = 1, 2, *) Outgoing transition can fire if at least one token is available
118

2000 Abteilung fr Informationssysteme

Activity Diagram
Concepts (1/5)
s

Describes a process consisting of:

x x x x

actions and activities control flow input and output objects, object flow responsible objects atomic represented by an action state can be further decomposed hierarchically represented by a subactivity state

Action
x x

Define start of contract

Activity
x x

Check plausibility

2000 Abteilung fr Informationssysteme

119

Activity Diagram
Concepts (2/5)
s

Control flow
x x x

order of actions / activities B represented by transition arrows no events - as soon as execution of the predecessor is finished, execution of the successor is started guards and (send-) actions are allowed

[not finished]

Responsibilities (swimlane)
x x

responsible objects can be assigned e.g., objects of the system to be realized, actors or organizational units

2000 Abteilung fr Informationssysteme

120

Activity Diagram
Concepts (3/5)
s s

Start state: start of an activity diagram End state: end of an activity diagram Object flow
x x x x

from actions to objects from objects to actions the current state of the object may be specified in case that control flow and object flow are identical, only the object flow is drawn

Compute contract Contract [computed] Authorize contract

2000 Abteilung fr Informationssysteme

121

Activity Diagram
Concepts (4/5)
s

Guard
x x

a transition may be annotated with a guard or further actions in this case, both the execution of the predecessor must be finished and the condition must be true in order to be able to execute the successor Check plausibility [OK] Compute contract

Alternative Sequences
x

either by means of mutually exclusive guards placed on the outgoing transitions of an action or by means of dedicated decision states

2000 Abteilung fr Informationssysteme

122

Activity Diagram
Concepts (5/5)
s

Decision state
x x

makes alternative sequences explicit complex decisions can be visualized by means of decision trees outgoing transitions are required to have mutually exclusive guards

Compute contract
[else] [bonus > 500]

Concurrency
x

x x

a fork denotes the starting point of the concurrent execution of activities/actions a join depicts the corresponding end conditional branches are possible

2000 Abteilung fr Informationssysteme

123

Activity Diagram
Example (1/2)
Claim Processing Automatic Processing Claim Check

Define start of contract

Create contract#

Attach insurance prod. Establish cover

Attach policy holder

Check plausibility

2000 Abteilung fr Informationssysteme

124

Activity Diagram
Example (2/2)
Claim Processing Automatic Processing Contract [computed]
[else] [else]

Specialized Claim Check Compute contract

[bonus>500]

Draw sample

[is a sample]

Release contract Contract [released]

2000 Abteilung fr Informationssysteme

Authorize contract { t<24h}

Contract [authorized]
125

Outline
s s s s s s s

Introduction Requirements Specification Analysis Design Pitfalls and Workarounds Roadmap to UML 2.0 References
126

UML Syntax and Semantics

2000 Abteilung fr Informationssysteme

Phase 3: Design
s

Previous focus: WHAT is required from the system New focus: HOW should the system fulfil these requirements
x

implementation dependent decisions are made, constituting the basis for refining the analysis model decomposition of the system into parts and distribution thereof concurrency and real-time aspects persistency mechanisms ... completing the class diagram by means of impl.dep. concepts completing the class properties (e.g. visibilities) decomposing structures which cannot be implemented as such ...

System design
x x x x

Detailed design
x x x x

2000 Abteilung fr Informationssysteme

127

Models of the Design Phase

System Design Design Model Detailed Design Design Model [refined] [no further refinements necessary]

[else]

2000 Abteilung fr Informationssysteme

128

Results of the Design Phase

1 UML Component Diagram UML Deployment Diagram

1 Design Model 1 Structural Model Behavioral Model

Architectural Description

2000 Abteilung fr Informationssysteme

129

Distribution
Distribution Alternatives (1/2)
2 6 6 6 6
Data Management Application

Presentation

Distributed User Interface Remote User Interface Distributed Application Remote Database Distributed Database
130

2000 Abteilung fr Informationssysteme

Distribution
Distribution Alternatives (2/2)
Complexity
s

MH: Argumente MH: Argumente sind mir nicht sind mir nicht ganz klar... ganz klar...
Distribution Costs

Security

Consistency

Reusability

Bottlenecks

Distributed User Interface Remote User Interface Remote DB Distributed DB Distributed Application

s s s

2000 Abteilung fr Informationssysteme

131

Distribution
Component Diagram
s

Describes SW-components and their dependencies

x x x

source code components (can offer interfaces - Java) binary code components (can offer interfaces - OLE) executable code components: instances are represented by means of deployment diagrams

Packages can contain components and vice versa

file1.java file2. java

Compilation Dependencies

I file3. java file4. java

2000 Abteilung fr Informationssysteme

132

Distribution
Deployment Diagram (1/3)
s

Shows the actual HW configuration consisting of

x x x x

internet Calendarium Client

Calendarium Server

nodes (processors (default), I/O, ...) SW-components processes objects

* DB Server

and of the communication channels between nodes Properties of nodes can be denoted by means of tagged values and/or stereotypes (e.g., capacity, reliability)

device Tape

2000 Abteilung fr Informationssysteme

133

Distribution
Deployment Diagram (2/3)

Possible system configuration:

Calendarium Client 1

Calendarium Server DB Server

Calendarium Client 2

2000 Abteilung fr Informationssysteme

134

Distribution
Deployment Diagram (3/3)

Calendarium Client User Interface Applet

b_calendarium

internet access access access

System Administration access Appointment Manager

Calendarium Server

Calendar Server Program

t1:calThread calendarium ... appobj

DB-Server

DBAccess

2000 Abteilung fr Informationssysteme

135

Distribution
Migration between Nodes

notebook :Customer mainServer :Customer

newCustomer newCustomer

become

2000 Abteilung fr Informationssysteme

136

System Design
Concurrency
s

UML does not provide a dedicated diagram type in order to express different aspects of concurrency
x

instead, concurrency aspects are incorporated into existing diagram types, in particular into behavior diagrams

Active objects are represented using rectangles with bold border lines
x

Symbolen entfernt Symbolen entfernt s Implementation alternatives for active objects: und Zeichnungen und Zeichnungen adaptiert... x heavyweight processes: own address space adaptiert...
x

in sequence diagrams, in addition, the whole lifeline is depicted as activation Bis hierher: Bis x hierher: in collaboration diagrams, different objects sharing a certain process Hintergrundfarbe von together using a bolded rectangle Hintergrundfarbe von can be grouped

lightweight processes (threads): common address space

137

2000 Abteilung fr Informationssysteme

Concurrency in Sequence Diagrams (1/2)

anUnfunded Order : Credit Authorization
new(...) authorizePurchase (312779, 8144-22-7999, $22,64) execute( )

: Credit Registry : Funds Request

lookup( )

: Credit Agency

: Local Credit Agency

authorize(...) authorized( ) authorize(...) authorized( )

return(true)
2000 Abteilung fr Informationssysteme

authorized( )

138

Concurrency in Sequence Diagrams (2/2)

s s

Objects may be used by multiple other objects in parallel An object is able to initiate parallel executions

Client

Request Handler

Server One

Server Two

System Clock

handleRequest

currentTime [x<100] doPart currentTime

[y>5] doPart

2000 Abteilung fr Informationssysteme

139

Concurrency in Collaboration Diagrams

s

Concurrency is expressed by different names instead of numbers at the same level of the decimal classification Synchronization is expressed by message numbers preceding a slash
currentJob :TransferJob

job
:Robot :Factory Scheduler

:FactoryManager
:Oven

B1/B2:completed 1 / B1:start(job)

1:start(job) A2,B2 / 2:completed(job)

:Factory JobMqr

A1/A2:completed 1 / A1:start(job)
[cf.: Rumbaugh et al., 1999]
140

2000 Abteilung fr Informationssysteme

System Design
Real-Time (1/2)
s

Application areas for real-time systems:

x

telecommunication, embedded systems, mobile computing, ... reactive: reaction to events whose occurrence and order of occurrence cannot be predicted timeliness: correct reaction within certain time intervals dynamic: system components must be reconfigurable dynamically due to frequent changes of environmental characteristics concurrency distribution ...

Properties of real-time systems:

x

x x

x x x

Proposal for an integration of the concepts of ROOM (Real Time Object Modeling Language, ObjecTime Inc.) in UML
http://www.objecTime.com/uml/index.html

2000 Abteilung fr Informationssysteme

141

System Design
Real-Time (2/2)
s

The time axis may contain metrics information (time restrictions)

x x

duration for executing an operation duration for sending a message : Funds Request : Local Credit Agency a: authorize() b: authorize() c: : Credit Agency

d:

{ b.receiveTime - b.sendTime < 0,5 sec } { d.receiveTime - a.sendTime < 1 sec } { c.sendTime - b.receiveTime < 0,1 sec }
2000 Abteilung fr Informationssysteme 142

System Design
Persistence
s

Decision about the type of persistence mechanism

x x x

File system object-relational database system object-oriented database system mapping of these classes to the selected persistence mechanism

Selecting the classes which should be made persistent

x

Defining the transaction boundaries Specifying the coupling between application and database (DB)

2000 Abteilung fr Informationssysteme

143

Persistence
Connecting to Relational DB - Alternative 1
s s

Database access is not decoupled from application specific behavior Each persistent class performs the mapping and access to the underlying relations by itself Disadvantages:
x

high coupling between problem domain classes : Appointment : Calendarium and DB structure save() DB-specific code is intermingled with different classes makePersistent poor portability of the application, /* SQL-Code */ since changes of the DB structure influence the application and vice versa

2000 Abteilung fr Informationssysteme

144

Persistence
Connecting to Relational DB - Alternative 2
s

Separation of DB access and application specific behavior

x

for each persistent problem domain class, n DB classes are implemented, corresponding 1:1 to the DB relations these DB classes realize both, mapping and access to the DB relations inflexible, high maintenance overhead, poor scalability

Disadvantages:
x

: Calendarium saveAppt(appt)

: DBManager

: DBAppointment

: Appointment

save (appt)

get Description makePersistent

2000 Abteilung fr Informationssysteme

145

Persistence
Connecting to Relational DB - Alternative 3
s

Separation of DB access and application specific behavior

x

there exists a generic interface to a relational DB, automatically realizing mapping and access to the relations

Can be realized by means of the Broker-pattern or by deriving from a persistent class

: Calendarium save() : Termin : DBManager

makePersistent(this)

2000 Abteilung fr Informationssysteme

146

Persistence
Coupling Alternatives (1/2)
A fat client
x

all data from the database is located at the client (Calendarium is located at the client too) all checks are performed by the client on every check, the client accesses the Calendarium within the DB B1 methods are implemented on the basis of SQL-statements, operating on relational counterparts of the objects, namely the tuples within the DB (Alternative 1)

B thin client
x x

B2 methods and all objects which are accessed are located within memory (Alternative 3)
2000 Abteilung fr Informationssysteme 147

Persistence
Coupling Alternatives (2/2)
A B1 Client
SQL SQL

Client Server

Server

boundary boundary

use use

:X1 :X3 :X2

X1

:X

SQL SQL
X2

X3

B2

Client

Server
148

2000 Abteilung fr Informationssysteme

Example CALENDARIUM
DB Access for Insert Appointment
: B_Calendarium c : Calendarium persistent User : Class persistent Authorization : Class dbmgr : DBManager new() persistent ca : Calendar con : Connection

login(...) login(user,pwd) login(user,pwd) new appt con storeAppt (partic, appt) con

login(user,pwd) con persistent u : User

checkAuthoriz (user, pa, auth)

executeQuery(sqlString) authorizationData

Alternative 1

a pll ar o f ctr ap n i i

authorized select(pa) u

select(User,pa,2) u checkCollision (UD, eD) ok

Alternative 3

checkCollision (bD, eD)

2000 Abteilung fr Informationssysteme

ll ar o f ctr ap n ap i i

149

Detailed Design
Completing Classes
s

State variables from statechart diagrams, which were not considered within the class diagram yet Operations,
x x

x x x

implementing activities of states implementing reactions to events in statechart and interaction diagrams reacting on external events with or without state transitions for CRUD (create, read, update, delete) managing associations

Visibility of attributes / operations

150

2000 Abteilung fr Informationssysteme

Detailed Design
Realizing Relationships
s

Mapping of associations / aggregations to oo programming language and DB

x

x x

specifying the realization of relationships (global, local, etc.) within collaboration diagrams and modifying the class diagram accordingly navigation - optimizing access paths by means of redundant associations materializing derived attributes realizing collections of objects

Mapping of generalizations to oo programming language and DB

x

multiple, extensional, overlapping

2000 Abteilung fr Informationssysteme

151

Detailed Design
Pattern - Framework - Component
s

Pattern:
schematic solution for an often recurring problem, emphasizing on the collaboration between objects

Framework:
collection of reusable design decisions (patterns) of a domain, represented by abstract and concrete classes as well as collaborations (inversion of control)

Component:
reusable unit having a clearly defined offering interface and a clearly defined required interface

2000 Abteilung fr Informationssysteme

152

Patterns in UML
Example Observer Pattern
s

Observer:
x

x x

goal is the automatic notification of dependent objects in case of state changes of an object ensures consistency for loosely coupled objects most often used in the area of graphical user interfaces subject observer Observer observer

: Calendar

cv1 : CalendarView cv2 : CalendarView

2000 Abteilung fr Informationssysteme

153

Schema of the Observer Pattern

Subject
addObserver (Observer) removeObserver (Observer) notifyObservers() observers *

Observer
update (Subject)

for all o in observers o->update(this);

ConcreteObserver ConcreteSubject
subjectState getState () setState () return subjectState; // change state notifyObservers();
2000 Abteilung fr Informationssysteme

subject

observerState update (Subject)

observerState=subject->getState()

154

Observer Pattern in CALENDARIUM

Updating the Calendar Views
pa : User ca : Calendar cv1 : Calendar View cv2 : Calendar View addObserver(this) insertAppt (d_new) notifyObservers() update(this) ok appointments( )
further access methods

addObserver(this)

update(this)

appointments( )
further acces methods 2000 Abteilung fr Informationssysteme 155

Outline
s s s s s s s

Introduction Requirements Specification Analysis Design Pitfalls and Workarounds Roadmap to UML 2.0 References
156

UML Syntax and Semantics

2000 Abteilung fr Informationssysteme

Pitfalls & Workarounds

A (constructive) critical view
s s

Aggregation semantics Generalization semantics

x x

Static view Dynamic view Interaction diagrams for algorithmic views Use case extension (include / extend / generalize) in I.D. Dynamic object references in sequence diagrams

Use Case formalization

x x x

s s

Some OCL obscenities Traceability of model refinement

2000 Abteilung fr Informationssysteme

157

Aggregation Semantics

Problems in UML:
x x

Weak aggregation does not bear useful semantics Canonical variations of aggregation not completely covered

2000 Abteilung fr Informationssysteme

158

Additional Additional Variant #1 unklar Variant #1 unklar

Aggregation Semantics
Standard Classification
dependent exclusive shared ?
1..* 1

independent
0..1

+ user specified del./propagation semantics necessary!

Additional variants: x exclusive, dependent, but no delete propagation! 1

x

0 0..1 very specific semantics: only transition 01 allowed

Weak aggregation is indeed weak :-)

(Rumbaugh: modeling placebo)

2000 Abteilung fr Informationssysteme

159

Generalization Semantics
Problems in UML:
x

Canonical variations of generalization not completely covered 3 w.r.t. static view (class diagram) 3 w.r.t. dynamic view (state diagram) Properties of generalization relationships are ambiguous, depending on basic assumptions: 3 multiple inheritance allowed? 3 multiple classification allowed? 3 Both allowed???

2000 Abteilung fr Informationssysteme

160

Generalization Semantics
Flavors of Inheritance
not distinguished in UML!
s

Specification inheritance
x x x x

yields type hierarchies preconditions must not become stricter, postconditions not weaker DQueue subtype-of Stack contravariance 3 Stack::push: Stack x Element Stack 3 DQueue::push: Stack x Element Stack (possibly: DQueue) yields is-a hierarchies Integer is-a Rational covariance 3 Rational::*: Rational x Rational Rational 3 Integer::*: Integer x Integer Integer no conceptual relationship at all
implementation
161

Specialization inheritance
x x x

Implementation inheritance
x

2000 Abteilung fr Informationssysteme

Generalization Semantics
Properties
s

incomplete / complete (default)

x x

complete: All possible subclasses are already part of the model additional interpretation (outside UML) (with multiple classification): Each super class instance must also belong to at least one subclass 2 interpretations of overlapping: 3 w.r.t. multiple inheritance: two or more subclasses can have again common subclasses (e.g. Instructor) 3 w.r.t. multiple classification: an object can be instance of more than one subclass
Entry ToDoEntry Employee Technical Employee {incomplete, overlapping}

overlapping / disjoint (default)

x

{complete, disjoint}

Appointment SerialEntry
2000 Abteilung fr Informationssysteme

Administrative Employee
162

Generalization Semantics
Inheritance of State Chart Diagrams (1/2)
class Reservation
establish s2 consume s3 pay s4 create s1 sendSorryLetter
Reservation

inheritance hierarchy
Reservation_ with_Cancel
2000 Abteilung fr Informationssysteme

Reservation_ with_Insurance
163

Generalization Semantics
Inheritance of State Chart Diagrams (2/2)
Reservation_with_Cancel (contravariance) cancel Reservation
establish s2 consume s3 pay s4 create s1 s6 makeInsurance s7

Reservation_with_Insurance sendSorryLetter (covariance) UML remains silent about these alternatives!

2000 Abteilung fr Informationssysteme 164

Use Case Formalization

s

Use Cases need formal specifications

x x x

Sequence Diagrams (SD) Collaboration Diagrams (CD) Activity Diagrams are well suited to scenario description are not adequate for algorithmic views

Interaction Diagrams (SD, CD)

x x

(same applies for other behavioral aspects)

2000 Abteilung fr Informationssysteme

165

Alternatives (1/2)
Guarded Messages
x

x x

A message guard is a Boolean expression (a predicate) that indicates under what circumstances the message can occur The guard appears in square brackets as part of the message label Multiple guarded messages within a single SD reduce the SDs readability considerably!
c:Customer b:Bank

transfer(rcvb, rcva, amnt) [amnt<limit] true [amnt >= limit] false alternative
2000 Abteilung fr Informationssysteme 166

Alternatives (2/2)
Conditional Lifelines
x x

A conditional lifeline expresses alternative behavior of a single component Conditional lifelines typically occur in conjunction with guarded messages and reduce an SDs readability even further!
b1:Bank bal:=getBal() conditional lifeline a1:Account b2:Bank

c:Customer

[bal a]

transfer(rb,ra,a) deposit(a-bal) BTransfer(rcvb, rcva, amnt) add(a-bal) ack

[bal<a]

Repetition
The UML lets us specify loops by enclosing the section to repeat, and by indicating (informally) the repetition
b1:Bank initMultiTransfer() loop condition for all t in transactionSet BTransfer(t) ack loop area b2:Bank

finishMultiTransfer()
2000 Abteilung fr Informationssysteme 168

Real Life Example

CALENDARIUM SD Insert Appointment (excerpt)
: B_Calendarium login(...) c : Calendarium User: Class pa : User Authorization : Class ca : Calendar

login(user,pwd) ok

login(user,pwd) ok

new appt

storeAppt (partic,appt) [authorized = false]

scope of pa?

forall pa in partic checkAuthorization (user, pa, write) authorized forall pa in partic checkCollision (bD, eD) checkCollision (bD, eD) ok
169

?
[ok = false]

ok

2000 Abteilung fr Informationssysteme

Use-Case Formalization
Problems with Algorithms in Interaction Diagrams

Decisions
x x

Where should you branch to? Message arrows pointing downwards (time dimension!) No multi-object in sequence diagrams Loops need pseudo-messages in collaboration diagrams: how to represent class methods classes seen as objects however: new is treated differently

Iterations
x x

Class methods
x x x

Appointment

Dynamic object references (e.g., pa)

2000 Abteilung fr Informationssysteme

170

Use-Case Formalization
Referencing of Use Cases (1/2)
Probes from OOSE are missing in UML

include

A o1 o2 o3

B o3 o4 o5

2000 Abteilung fr Informationssysteme

171

Use-Case Formalization
Referencing of Use Cases (2/2)

Variant borrowed from the MSC-96 standard

SD SuccessfulWithdrawal b1:Bank reference b1:Bank a:Account

a:Account

initTransfer()

withdraw(a) ack

ref SuccessfulWithdrawal endTransfer()

2000 Abteilung fr Informationssysteme

172

Alternatives
Separate alternation boxes
x x x

Each alternative has its own guard The disjunction of all guards must equal true Any one of the alternatives whose guard equals true will occur in an execution that complies with the SD
b1:Bank bal:=getBal() a1:Account b2:Bank

c:Customer

alt: [bal a]

transfer(rb,ra,a) BTransfer(rcvb, rcva, amnt)

alt: [bal<a]

deposit(a-bal) add(a-bal) ack

Repetition
Use repetition box with guards for specifying loops The loop guard is of any one of the following forms:
x x x x

loop<lb,ub> : at least lb and at most ub repetitions loop<*>: any finite number of repetitions loop< >: an infinite number of repetitions loop<g>: if g is a Boolean expression then the repetition occurs as long as g evaluates to true
b1:Bank loop<1,10> BTransfer(t) ack b2:Bank

Actions
s

Use action boxes for specifying that a component performs a local activity, such as an assignment to its attributes The activitys position on the components lifeline indicates when the activity occurs

b1:Bank withdraw(amnt)

a:Account

action symbol bal := bal-amnt

2000 Abteilung fr Informationssysteme

175

OCL
s

Purpose
x

x x x

Capture properties of modelling elements not conveniently covered by other UML constructs Documentation specification Reason about specification Execution (of a sub-language) First-order specification language 3 Boolean operators, quantifiers Basic datatypes included very similar to 3 Algebraic specification language 3 Logic language

Characteristics
x

x x

2000 Abteilung fr Informationssysteme

176

Missing Definitions in OCL

s

let-construct:
x

let in

p = a*b min(x,y) = if(x<y) then x else y fi min(a,p)+min(b,p)

dataype-construct:
x

dataype Error = Ok | ReadOnly | ReadErr | DiskErr(String)

both from functional languages

2000 Abteilung fr Informationssysteme

177

The Russel Paradoxon

s

Each type is subtype of OclAny.

x

Therefore, Set(OclAny) is subtype of OclAny. R = OclAny.allInstances -> select( x:Set(OclAny) | not x->includes(x) ) P = R->includes(R) as both would lead to contradiction

Define set R and Boolean value P:

x

P is neither True nor False,

x

Logic contains contradictions: Everything can be deduced

2000 Abteilung fr Informationssysteme

178

Prevention of the Russel Paradoxon

s s s

No OclAny type, or OclAny type, but no operations on it (?) Disallowing type constructors on OclAny Instead:
x x

Define operations for each type separately! Introduce OclObject as top for all Classes!

2000 Abteilung fr Informationssysteme

179

Traceability of Model Refinement

Example 1
X op() trace refine X op() op() 1

refine and trace dependency

x x x

between 2 model elements (need some kind of n:m-relationship) trace semantics not quite clear impossible for model elements on different diagrams
180

2000 Abteilung fr Informationssysteme

Traceability of Model Refinement

Example 2
X 1

refine X

Y-Set

Only reasonable workaround: Tool support

2000 Abteilung fr Informationssysteme

181

Conclusion

UML 1.3
x x

is well under way to become the lingua franca has several deficiencies yet to be eliminated 3 major problem: algorithmic views (may be repaired?!) 3 major problem: traceability (needs tool support) 3 minor problem: unclear semantics of some model elements

2000 Abteilung fr Informationssysteme

182

Outline
s s s s s s s

Introduction Requirements Specification Analysis Design Pitfalls and Workarounds Roadmap to UML 2.0 References
183

UML Syntax and Semantics

2000 Abteilung fr Informationssysteme

UML 2.0 Roadmap Draft

[Kobryn99]
s s

s s s s s s

Heavyweight extension mechanisms and profiles Activity graph semantics independent of state machines semantics State machine generalization Refinement of refine Generalization of association Variations of aggregation OCL extensions Cleanup constructs not used based on feedback from vendors and users

2000 Abteilung fr Informationssysteme

184

Literature (1/5)
s

Official documentation of the UML, v. 1.3 June 1999 (http://uml.shl.com):

x x x x

UML Summary UML Semantics UML Notation Guide UML Extensions

3 3

UML Extension for Software Development Processes UML Extension for Business Modeling

x x x

OA&D CORBAfacility Interface Definition Object Constraint Language Specification (OCL) UML Metamodel

2000 Abteilung fr Informationssysteme

185

Literature (2/5)
s s

Scott W. Ambler, Building Object Applications - Patterns, Architecture, Design, Construction, and Testing, SIGS Books, 1997, ISBN 0-13-789215-2 Grady Booch, James Rumbaugh, Ivar Jacobson, The Unified Modeling Language User Guide, Addison Wesley Longman, 1999, ISBN 0-201-57168-4 R. Breu, I. Krger, B. Rumpe: Applied Software Engineering Principles for UML, Tutorial Notes, TOOLS Europe 1999. Rainer Burkhard, UML - Unified Modeling Language, Addison Wesley, 1997, ISBN 38273-1226-4 Murray Cantor, Object-Oriented Project Management with UML, John Wiley, 1998, ISBN: 0-471-25303-0 Paul Dorsey, Joseph Hudicka, Oracle8 Design Using UML Object Modeling, Osborne McGraw-Hill, 1999, ISBN: 0-078-82474-5 Bruce Powel Douglass, Real Time UML - Developing Efficient Objects for Embedded Systems, Addison Wesley Longman, 1998, ISBN: 0-201-32579-9 Hans-Erik Eriksson and Magnus Penker, UML Toolkit, John Wiley & Sons, 1998, ISBN: 0-471-19161-2

2000 Abteilung fr Informationssysteme

186

Literature (3/5)
s

Martin Fowler, UML Distilled: Applying the Standard Object Modeling Notation, Addison Wesley, 1997, ISBN: 0-201-32563-2 Martin Fowler, Kendall Scott, UML konzentriert, deutsche bersetzung von UML Distilled, Addison-Wesley, 1998, ISBN 3-8273-1329-5 Paul Harmon, Mark Watson, Understanding UML - The developer guide, Morgan Kaufmann Publishing, 1997, ISBN: 1-558-60465-0 M. Hitz, G. Kappel, UML @ Work: Von der Analyse zur Realisierung, dpunkt.Verlag, 1999 Ari Jaaksi, Juha-Markus Aalto, Ari Aalto, Tried and True Object Development, Industry-Proven Approaches with UML, 1998, ISBN: 0-521-64530-1 Bernd Kahlbrandt, Software-Engineering - Objektorientierte Softwarentwicklung mit der UML, Springer Verlag, 1998, ISBN 3-540-63309-X C. Kobryn: UML RTF Status, http://uml.shl.com, 1999.

2000 Abteilung fr Informationssysteme

187

Literature (4/5)
s s

s s

Craig Larman, Applying UML and Patterns - An Introduction to Object-Oriented Analysis and Design, Prentice Hall, 1998, ISBN: 0-137-48880-7 Richard C. Lee, William M. Tepfenhart, UML and C++: A Practical Guide to Object-Oriented Development, Prentice Hall, 1997, ISBN 0-13-619719-1 James Martin, James J. Odell, Object-Oriented Methods: A Foundation, UML Edition, Prentice Hall, 1997, ISBN 0-13-905597-5 James J. Odell, Advanced Object-Oriented Analysis & Design Using the UML, Cambridge University Press, 1998 Bernd Oestereich, Objektorientierte Softwareentwicklung mit der UML, Oldenburg Verlag, 4.Auflage, 1999, ISBN 3-486-24319-5 Pierre-Alain Muller, Instant UML, Wrox Press, 1997, ISBN: 1-861-00087-1 Horst Neumann, Objektorientierte Softwareentwicklung mit der Unified Methode, 1998, Hanser-Verlag, ISBN 3-446-18879-7 Terry Quatrani, Visual Modeling with Rational Rose and UML, Addison Wesley Longman, 1998, ISBN 0-201-31016-3

2000 Abteilung fr Informationssysteme

188

Literature (5/5)
s s

s s

James Rumbaugh, Ivar Jacobson, Grady Booch, The Unified Modeling Language Reference Manual, Addison Wesley Longman, 1999, ISBN 0-201-30998-X Martin Schader, Axel Korthaus (eds.): The Unified Modeling Language Technical Aspects & Applications, Physica-Verlag, 1998, ISBN: 3-7908-1105-X J. Seemann, J. Wolff von Gudenberg, Software-Entwicklung mit der UML, Springer Verlag, 1999, ISBN 3-540-64103-3 Sinan Si Alhir, UML in a Nutshell, O'Reilly, 1998, ISBN: 1-56592-448-7 M. Thron, UML - Objektorientierte Entwicklung in der Praxis, Springer Verlag, 1999, ISBN 3-540-64420-2

2000 Abteilung fr Informationssysteme

189

UML Web addresses

s

Rational Software Corporation: www.rational.com

s
s

UML Revision Task Force: http://uml.shl.com

Interesting Links in this Area: http://www.infosys.tuwien.ac.at/cetus/oo_uml.html Presenters UML Site: http://www.ifs.univie.ac.at/UML

2000 Abteilung fr Informationssysteme

190