The Unified Modeling Language

UML class diagrams UML is a graphical language for recording aspects of the requirements and design of software systems.

Nigel Goddard It provides many diagram types; all the diagrams of a system together form a UML model. Three important types of diagram:

School of Informatics 1. Use-case diagram. Already seen in requirements lecture. University of Edinburgh 2. Class diagram. Today. 3. Interaction diagram. In the future.

Reminder: a simple use case diagram A class

Reserve book Browse

Browser BookBorrower Book

Borrow copy of book

A class as design entity is an example of a model element: the Return copy of book rectangle and text form an example of a corresponding presentation element.

Extend loan UML explicitly separates concerns of actual symbols used vs

Update catalogue meaning. Many other things can be model elements: use cases, actors, Borrow journal Librarian associations, generalisation, packages, methods,...

Return journal JournalBorrower An object Classifiers and instances

An aspect of the UML metamodel that it’s helpful to understand up front. jo : Customer An instance is to a classifier as an object is to a class: instance and classifier are more general terms. This pattern generalises: always show an instance of a classifier In the metamodel, Class inherits from Classifier, Object inherits using the same symbol as for the classifier, labelled from Instance. instanceName : classifierName. UML defines many different classifiers. E.g., UseCase and Actor are classifiers.

Showing attributes and operations Compartments

We saw the standard: Book a compartment for attributes title : String I I a compartment for operations, below it copiesOnShelf() : Integer borrow(c:Copy) They can be suppressed in diagrams. They are omitted if empty. Syntax for signature of operations (argument and return types) adaptable for different programming languages. May be omitted You can have extra compartments labelled for other purposes, e.g., responsibilities of the class... Visibility Association between classes

Book

+ title : String is a copy of Book - copiesOnShelf() : Integer Copy # borrow(c:Copy)

Can show whether an attribute or operation is This generalises: association between classifiers is always shown using a plain line. (Recall the associations between actors and use I public (visible from everywhere) with + cases!)

I private (visible only from inside objects of this class) with − An instance of an association connects objects (e.g. Copy 3 of War (Or protected (#), package (∼) or other language dependent and Peace with War and Peace). visibility.) An object diagram contains objects and links: occasionally useful.

Rolenames on associations Class invariants

A class invariant is a statement which is supposed to be true of Director of DoS directee Student every object of the class, all the time - a “sanity check”. Studies Very useful to make these explicit. Can be included as comments Can show the role that one object plays to the other. on class diagrams, and in code. Useful when documenting the class: e.g. a class invariant for May be formal, e.g. x + y = z, or informal, e.g. “the attribute DirectorOfStudies could refer to the associated Student objects as docstring describes the action of the button in concise English”. self.directee (a set, if there can be more than one). If formal, it can be useful to have class invariants automatically Can use visibility notation + − etc on role names too. checked. Clicker question Multiplicity of association Book

1 is a copy of

In a class diagram, a class may have compartments for: 1..*

1. attributes LibraryMember borrows/returns Copy 2. operations 1 0..* 0..* 3. responsibilities 4. all of the above, but nothing else borrows/returns 1 5. all of the above, and other items MemberOfStaff borrows/returns Journal 1 0..*

Commas for alternatives, two dots for ranges, * for unknown number. E.g. each Copy is a copy of exactly one Book; there must be at least one Copy of every Book.

Navigability Generalisation

LibraryMember Adding an arrow at the end of an association shows that some object of the class at one end can access some object of the class at the other end, e.g. to send a message.

is taking Student Module

Crucial to understanding the coupling of the system. NB direction of navigability has nothing to do with direction in which you read MemberOfStaff the association name. This generalises: generalisation between classifiers is always shown using this arrow. Usually, but not necessarily, corresponds to implementation with inheritance. Usually, but not always, can read as is a e.g., Member of Staff is a Library Member. Abstract operations and classes Interfaces

In UML an interface is just a collection of operations, that can be realised by a class.

An operation of a class is abstract if the class provides no <> Module implementation for it: thus, it is only useful if a subclass provides Stringifiable stringify() : String the implementation. stringify() : String ... A class which cannot be instantiated directly – for example, ... because it has at least one abstract operation – is also called Stringifiable abstract. Java... <> Can show abstract operation or class using italics for the name, and/or using the property {abstract}.

Printer

Simpler diagram: WRITE ONCE Identifying objects and classes

<> Module Stringifiable stringify() : String Simplest and best: look for noun phrases in the system description! stringify() : String ...... Then abandon things which are: I redundant I attributes Stringifiable I outside scope I operations and events

prints I vague I implementation classes. (May need to add some back later, especially implementation classes: point is to avoid incorporating premature design decisions Printer into your conceptual level model.) Similarly, can use verb phrases to identify operations and/or associations Many things other than classes can realise interfaces: can use the lollipop symbol on e.g. components, actors. Reading

Suggested: (class diagrams) Stevens ch 5.