1. Class Diagram & Object Diagram

3. UML Class Diagrams
The class diagram provides a static structure of all the classes that exist within the system. Classes are arranged in hierarchies sharing common structure and behaviour and are associated with other classes.
Class diagrams are used in:
Analysis To build a conceptual domain model with semantic associations between concepts
Design Structural model of a design in terms of class interfaces
Implementation Source code documentation, exposing the implementation

4. Class diagram
A class diagram describes the type of objects in a system and the static relationships between them.
Static relations:
Associations
Subtypes
Static structure:
Attributes
Operations

6. Class
A class is a set of objects that share the same properties.
Name

7. Class A class is a set of objects that share the same properties.
A class has a name.
Order

8. Class - attributes
The class captures the abstraction of properties in the set of objects.
Name
Attributes

9. Class - attributes
An attribute of a class is identified by name, and it identifies a property of the objects of the class, for which each object takes a value.
A class has 0 to n attributes.
Order
number: String
price: Money

11. Class - operations
Operations are the processes that a class knows to carry out.
Order
Attributes
Operations

12. Class - operations
The operations are the ‘responsibilities’ – the things we can ask an object to do.
A class has 0 to n operations.
Name
number: String
price: Money
Send ()
Close ()

13. Class - operations
An operation is the implementation of a service that can be requested from any object of the class in order to affect behaviour.
Operations are used to manipualte the attributes or to perform other actions. Operations are normally called functions, but they are inside a class and can be applied only to objects of that class.
An operation is described with a return-type, a name and zero or more parameters. Together, the return-type, name, and parameters are called the signature of the operation.
The signature describes everything needed to use the operation.

15. Associations
Associations are strcutural relationships where instances (objects) of one class are connected to instances (objects) of another class.
an employee works for a company
a company has a number of offices
An association is normally bidirectional, which means that if an object is associated with another object, both objects are aware of each other (navigation is bidirectional by default).
Binary association connects exactly two classes. N-ary connects may classes.
The most common association is just a connection between classes.

16. Association Adornments: Name, Role
The association has a name - the descriptive term, often a verb, for the association.
Each association has two association ends; each end is attached to one of the classes in the association. An end can be explicitly named with a label. This label is called a role name (association ends are often called roles).
Person
Company
employee employer
works for
 has employment for

17. Association: Multiplicity
Multiplicity defines the number of objects associated with an instance of the association.
Default of 1 (1: 1)
0 or 1: 0..1
Zero or more (0..infinite): *
1 or more (1..infinite): 1..*
n..m; range from n to m inclusive
Car
Person
transports
passenger 5 *
1..*
2..5

18. Navigation
It is possible to use navigable associations by adding an arrow at the end of the association.
Within the specification perspective, navigability represent responsabilities.
An Order has a responsability to tell you which Customer it is for.

20. Generalization
A specialization / generalization relationship, in which objects of the specialized element (child) are substitutable for objects of the generalized element (parent).
Superclass – the generalization of another class, the child.
Subclass – the specialization of another class, the parent.
Customer
Corporate
Customer
Personal
Customer

21. Generalization - characteristics
Identify common features concerning behaviour and knowledge. Define these common features on a higher level in the inheritance hierarchy.
The aim is at behaviour more than knowledge when combining classes.
Generalization is a bottum-up process.
A superclass includes all common properties of its subclasses.

22. Specialization - characteristics
Define a new class which is a special appearance of an existing class.
Specialization is a top-down process.
A subclass can have attributes and operations that are specific for that sub-class.
A subclass may redefine operations of its super-class.

24. Constraints
The basic constructs of association, attribute, and generalization do much to specify important constraints.
They cannot indicate every constraint. These constraints still need to be captured; the class diagram is a good place to do that.
The UML allows you to use anything to describe constraints. The only rule is that you put them inside braces { }.

26. Remarks Class diagrams are the backbone of nearly all OO methods.
The trouble with class diagrams is that they are so rich, they can be overwhelming to use. Start with: classes, associations, attributes, generalization, and constraints.
If you are in the analysis stage of the project, draw conceptual models.
File  New  Software  UML Model Diagram  UML Static Structure

27. Association class
Association classes allow you to add attributes, operations, and other features to associations.

28. Association Class  Full Class
Promoting an Association Class to a Full Class

29. Attribute Analysis
It is not always clear which attributes belongs to which classes by finding out the class attributes. An attribute is assigned to that class where it is certainly a feature.
For example: a project leader has the attributes name, department and age.
But what to do with the attributes project number, project duration, starting time, and budget? These attributes clarifies something about the relation between project leader and type of project.
This often happens if a n:m relation refers to an association between two classes. In that case, we can define a new class, for instance project management.

31. UML Classes
UML has become an effective standard for object-oriented modelling.
Object classes are rectangles with the name at the top, attributes in the middle section and operations in the bottom section.
Relationships between object classes (known as associations) are shown as lines linking objects.
Inheritance is referred to as generalisation and is shown ‘upwards’ rather than ‘downwards’ in a hierarchy.

32. Aggregation and Composition
Aggregation is a special form of association that specifies a whole-part relationship between the aggregate (the whole) and a component (the part).
Composition is a form of aggregation with strong ownership and coincident lifetime of the parts by the whole; parts with nonfixed multiplicity may be created after the composite itself, but once created they live and die with it; such parts can also be explicitly removed before the death of the composite.
Fiets: Bike
Wiel: Wheel
Frame: Frame

33. Object diagram
An object diagram is a diagram that shows a set of objects and their relationships at a point in time; object diagrams address the static design view or static process view of a system.
An object diagram is shown as a class, and the name is underscored, although an object’s name can be shown optionally preceding the class name as: objectname: classname. The object does not have to be named, in which case only the classname is shown underscored.

35. NS Ticket service Define a use case diagram of ‘NS Ticket service’
Destination
Define a use case diagram of ‘NS Ticket service’
Describe an use case.
Take ticket

36. Use Case diagram ‘NS Ticket service’

37. Use Case Actors Preconditions Description Extension Exceptions Result
Use Case
Buy OV Ticket
Actors
Traveller
Preconditions
Traveller has a valid pass
Description
Ticket device expects destination code
Traveller enters destination code
Extension point: NS ticket
Ticket device checks code and calculates the charge. Shows destination code & fare. Activates ticket machine for paying
Traveller pays (use case: Pay ticket)
Ticket device print and supplies ticket
Traveller takes ticket
Extension
Destination code = NS station.
3a. Ticket device expects ticket type
3b. Traveller enters Single/Return, Discount Y/N, Class
Exceptions
Traveller interrupt the interaction or walk away
Traveller enters an incorrect destination code
Payment is not finished off successful
Result
Traveller has ticket.
(NS can look forward to the payment)

38. Make a class diagram of ‘NS ticket service’ including the classes ‘Ticket’ and ‘Destination’

39. Structural modeling essentials

40. CRC (Class-Responsibility-Collaboration) - Card
<<Class>> Subscription
<<Responsibility>>
<<Collaboration>>