1. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Unified Modeling Language Visual language for design Motivation Syntax and Semantics

2. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science 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.

3. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Need for communication  Communication about software  Generating ideas: Sketch  Work division: Blueprint  Time passes: Documentation

4. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science 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”

5. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science 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’

6. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science 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…

7. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science UML and Abstraction  Abstraction takes precedence over precision!  20/80 rule  aim is overview and comprehension; not execution

8. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science 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

9. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Class diagram  Focus: Classes and their relations.  classes  attributes  methods  relations  generalization  association  multiplicity  roles  navigability

10. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Exercise  What does it actually mean to have a 1-* relation between classes?

11. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science 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)

12. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science 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).

13. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Object diagram  Focus: Objects and their relations

14. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Contracts and roles  Subclass when you want to inherit code else subtype using interfaces.  Think in terms of contracts and responsibility!

15. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science 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

16. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Lollipop notation  Interfaces have an alternative notation.

17. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Additional notation  Notes allow us to add useful but non-standard information anywhere. for each shape { shape.draw(); } Drawing draw()

18. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Discussion  What are the differences between class diagrams and object diagrams?  What aspects of a system are best described by either?

19. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science 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? > Iterator > Matrix *

20. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science Sequence diagrams  Focus: Collaboration and behavior  objects  invocations  activations  Overview!  Relation to use cases: a single scenario

21. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science 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?

22. Kari R. Schougaard, PhD Stud. Værktøjer og Teknikker, 2006 UNIVERSITY OF AARHUS Department of Computer Science 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