Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of...

UNIVERSITY OF AARHUS

Department of Computer Science Kari R. Schougaard, PhD Stud.Værktøjer og Teknikker, 2006

Unified Modeling Language

Visual language for designMotivation

Syntax and Semantics



Software is invisible

Invisibility is an inherent, not accidental, property of software Brooks: ‘No Silver Bullet-Essence and Accidents of Software Engineering’

We have a strong visual and spatial perception.

Software is multi-dimensional and does not lend itself easily to a single 2D or 3D diagrammatic form.



Need for communication

Communication about software Generating ideas: Sketch Work division: Blueprint Time passes: Documentation



UML history Booch: Booch notation 1994

language design, focus on structural aspects esp. inheritance

Rumbaugh et al.: OMT 1991 background in database and Entity Relation

modeling

Jacobson: OOSE 1992 use cases / requirements

Unified Modeling Language 1997 unified means ”joint effort instead of wars”



UML is a language

”A language provides a vocabulary and the rules for combining words […] for the purpose of communication. A modeling language is a language whose vocabulary and rules focus on the conceptual and physical representation of a system. A modeling language such as the UML is thus a standard language for software blueprints.”Booch, Jacobson, and Rumbaugh: ‘UML user guide’



UML uses

UML is used to document designs

design patterns / frameworks

represent different views/aspects of design static / dynamic / deployment / modular aspects

provide a next-to-precise, common, language for the benefit of analysis, discussion,

comprehension…



UML and Abstraction

Abstraction takes precedence over precision! 20/80 rule aim is overview and comprehension;

not execution



Diagram types

UML has a Zoo of different diagrams, each with their own syntax and semantics: class diagram object diagram use case diagram sequence diagram communication diagram interaction diagram

We will not cover all!

package diagram state diagram activity diagram component diagram deployment diagram



Class diagram Focus: Classes and

their relations. classes

attributes methods

relations generalization association

multiplicity roles navigability



Exercise

What does it actually mean to have a 1-* relation between classes?



Perspective

Programs often require phenomena and concepts that cannot be found in the modeled world.

Fowler expresses this as a perspective in the models: Conceptual perspective Software perspective (specification &

implementation)



1 diagram – 2 perspectives Conceptual perspective

Focus on the domain: building a vocabulary Phenomena, concepts and their relations Forget the software to be written!

Software perspective The elements maps pretty directly to elements in a

software system. Add concepts directed at program execution. Focus on specification/interface (what) or

implementation (how).



Object diagram

Focus: Objects and their relations



Contracts and roles Subclass when you want to inherit code

else subtype using interfaces. Think in terms of contracts and

responsibility!



A note on class diagrams

Class diagrams can easily be overloaded with implementation information.

I prefer to Mostly ignore the attribute and method boxes

in software perspective (and definitely in conceptual perspective) and…

to express behavior in terms of responsibilities



Lollipop notation

Interfaces have an alternative notation.



Additional notation

Notes allow us to add useful but non-standard information anywhere.

for each shape {

shape.draw();

}

Drawing

draw()



Discussion

What are the differences between class diagrams and object diagrams?

What aspects of a system are best described by either?



Exercise

Consider the following diagram:

I cannot create such an association in some UML CASE Tools because the association cannot be expressed by the underlying code.

Is it thus not legal UML?

<<interface>>

Iterator

<<interface>>

Matrix

*



Sequence diagrams

Focus: Collaboration and behavior objects invocations activations

Overview! Relation to

use cases:a singlescenario



Exercises

Compare sequence- and class diagrams. How comprehensive are the diagrams?

(what percentage of the full system do they describe)

How would you mechanical compute a diagram? class diagram? sequence diagram?

Which is easier to compute from source code? Which is most important?



Summary

UML is a modeling language for describing software systems.

Class diagrams describe static relations between abstractions: interfaces and classes.

Object diagrams describe dynamic relations between concrete objects

Sequence diagrams describe dynamics of scenarios during execution

Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of...

Documents

Transcript of Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of...