1. Chapter 5 – System Modeling
Lecture 2
We don't have time to stop for gas, we're already late.
M. Cleron (Commenting on how Software Projects are often Run)
One purpose of CRC cards [a design tool] is to fail early, to fail often, and to fail inexpensively. It is a lot cheaper to tear up a bunch of cards that it would be to reorganize a large amount of source code.
C. Horstmann (in Object-Oriented Design with Java)
Chapter 5 System modeling

2. Chapter 5 System modeling
Topics covered
Context models
Interaction models
Structural models
Behavioral models
Model-driven engineering
Chapter 5 System modeling

3. Chapter 5 System modeling
Structural models
Structural models of software display the organization of a system in terms of the components that make up that system and their relationships.
Types of Structural models
static models, which show the structure of the system design
dynamic models, which show the organization of the system when it is executing.
You create structural models of a system when you are discussing and designing the system architecture.
Chapter 5 System modeling

4. Chapter 5 System modeling
Class diagrams
Class diagrams
used when developing an object-oriented system model
show the classes in a system
Show the associations between these classes.
An association is a link between classes
indicates the relationship between these classes.
Initially objects represent something in the real world
a patient, a prescription, doctor, etc.
Later will represent programming constructs
Chapter 5 System modeling

5. Chapter 5 System modeling
Class Diagrams
To create and evolve a conceptual class diagram, you need to iteratively model:
Classes
Responsibilities
Associations
Inheritance relationships
Composition associations
Vocabularies
Chapter 5 System modeling

6. UML classes and association
Chapter 5 System modeling

7. Classes and associations in the MHC-PMS
Chapter 5 System modeling

8. The Consultation class
The upper part holds the name of the class
The middle part contains the attributes of the class
The bottom part gives the methods or operations the class can take or undertake
Chapter 5 System modeling

9. Chapter 5 System modeling
Associations
An association represents a family of links.
Binary associations (with two ends) are normally represented as a line.
An association can be named,
the ends of an association can be adorned with role names, ownership indicators, multiplicity, visibility, and other properties.
Associations represent static relationships between 2 classes
There are four different types of association:
bi-directional,
uni-directional,
Aggregation (includes Composition aggregation) and
Reflexive.
Bi-directional and uni-directional associations are the most common.
Chapter 5 System modeling

10. Chapter 5 System modeling
Navigability
End property of association is navigable from the opposite end(s) of association if instances of the classifier at this end of the link can be accessed efficiently at runtime from instances at the other ends of the link.
Notation:
navigable end is indicated by an open arrowhead on the end of an association
not navigable end is indicated with a small x on the end of an association
no adornment on the end of an association means unspecified navigability
Chapter 5 System modeling

11. Chapter 5 System modeling
Navigability
Both ends of association have unspecified navigability.
A2 has unspecified navigability while B2 is navigable from A2.
A3 is not navigable from B3 while B3 has unspecified navigability.
Chapter 5 System modeling

12. Chapter 5 System modeling
Navigability
A4 is not navigable from B4 while B4 is navigable from A4.
A5 is navigable from B5 and B5 is navigable from A5.
A6 is not navigable from B6 and B6 is not navigable from A6.
Chapter 5 System modeling

13. Associations: uni-directional
Class 1 contains an instance of class 2
Chapter 5 System modeling

14. Association: bi-directional
Multiplicity the number of magazines that participate
role
Field in Person that holds a Magazine instance
0..1 No instances, or one instance (optional, may)
1 Exactly one instance
0..* or * Zero or more instances
1..* One or more instances (at least one)
This example is bi-directional.
A Person may subscribe to many Magazines
A Magazine may have many subscribers
Chapter 5 System modeling

15. Association: bi-directional
Roles: A role name explains how an object participates in the relationship.
Two associated classes: Professor and Book:
The role Wrote gives a description of the association
In this case Professor is the writer of the associated book.
The fields or properties are also given: author holds an instance of a Professor in the Book class
in the Professor class textbook holds an instance of the Book class
A small solid triangle could be placed next to or in place of the name of binary association (drawn as a solid line) to show the order of the ends of the association. The arrow indicates that the association is to be read from the left to the right (in this example). In other words, the Professor wrote the Book.
Chapter 5 System modeling

16. Association: bi-directional
Each object needs to hold a reference to the associated object or objects.
The reference is held in an attribute value within the object.
The diagram shows that Query builder has a Query (and vice versa). How is this association depicted in the code?
You have a class QueryBuilder that has an attribute of type Query named query.
Ownership of association may be indicated graphically by a small filled circle (aka dot).
Chapter 5 System modeling

17. Association: bi-directional
You have a class QueryBuilder that has an attribute of type Query named query.
In code:
class QueryBuilder {
Query query; }
And you have a class Query that has an attribute of type QueryBuilder named qbuilder
class Query {
QueryBuilder qbuilder;
The attribute (query for class QueryBuilder and qbuilder for class Query) is the reference to the associated object
Chapter 5 System modeling

18. Association: bi-directional
When there is only one association then there is only one attribute holding a reference
In the previous example, there was one association (i.e., one line), so we have one attribute (field) in each class to keep the reference of the associated object.
In the diagram on the next slide, Acount has two associations with BookItem, borrowed, and received
So, in class Account we will have two fields, one field for each association.
class Account {
BookItem[] borrowed;
BookItem[] reserved; }
These associations are one to many, so the fields that we have for the associations are arrays that can keep more than one BookItems.
Chapter 5 System modeling

19. Association: bi-directional
Chapter 5 System modeling

20. Association: bi-directional
line that connects Author and Book
Author has one or more Book objects (the books written by the author)
also Book has one or more Author objects (because book can have more than one author).
An association with multiplicity many (one or more) is usually implemented with a collection or an array.
Class Author has a field that can be a collection or array of Books. The diagram does not provide the name of this fields.
Example:
Book[] textbook;
Also the visibility of the fields is not provided (could be default, private or public).
Chapter 5 System modeling

21. Associations: Aggregation
Aggregation is a variant of the "has a" or association relationship;
aggregation is more specific than association.
It is an association that represents a part-whole or part-of relationship.
an aggregation may not involve more than two classes.
occurs when a class is a collection or container of other classes, but the contained classes do not have a strong lifecycle dependency on the container.
The contents of the container are not automatically destroyed when the container is.
Chapter 5 System modeling

22. Associations: Aggregation
In UML, it is graphically represented as a hollow diamond shape on the containing class end of the tree with a single line that connects to the contained class.
The aggregate is semantically an extended object that is treated as a unit in many operations, although physically it is made of several lesser objects.
Chapter 5 System modeling

23. Associations: Aggregation
Note here that a Patient record contains 1 Patient but many Consultations
Chapter 5 System modeling

24. Chapter 5 System modeling
Aggregation example
override func viewDidAppear(animated: Bool) { //Get the Songslist singleton let model = (self.tabBarController as MainTabBarViewController).SongList songs = model.songList }
songList is created elsewhere
Chapter 5 System modeling

25. Association: Composition
Composition is a stronger variant of the "owns a" or association relationship;
composition is more specific than aggregation.
Composition usually has a strong life cycle dependency between instances of the container class and instances of the contained class(es):
If the container is destroyed, normally every instance that it contains is destroyed as well
Chapter 5 System modeling

26. Associations: Composition
The UML graphical representation of a composition relationship is a filled diamond shape on the containing class end of the tree of lines that connect contained class(es) to the containing class.
Chapter 5 System modeling

27. Associations: Composition
Compositions model a class that creates another class
class Car{
var myCarb : Carburetor = Carburetor() }
The instance is created within this class and dies when the class dies
Chapter 5 System modeling

28. Aggregation vs Composition
the aggregation relationship is "catalog" containment composition is "physical" containment.
Aggregation relationship : When representing a software or database relationship, e.g., car model engine ENG01 is part of a car model CM01, as the engine, ENG01 may be also part of a different car model.
Composition relationship : When attempting to represent real-world whole-part relationships, e.g., an engine is a part of a car.
Chapter 5 System modeling

29. Chapter 5 System modeling
Generalization
Generalization is an everyday technique that we use to manage complexity.
In OOP it is implemented through inheritance
Extrapolate common characteristics into more general classes (animals, cars, houses, etc.)
the attributes and operations associated with higher-level classes are also associated with the lower-level classes.
Subclasses inherit the attributes and operations from their superclasses.
These lower-level classes then add more specific attributes and operations.
Chapter 5 System modeling

30. A generalization hierarchy
Chapter 5 System modeling

31. A generalization hierarchy with added detail
Chapter 5 System modeling

32. Chapter 5 System modeling
Realization
a relationship between two model elements, in which one model element (the client) realizes (implements or executes) the behavior that the other model element (the supplier) specifies.
The UML graphical representation is a hollow triangle shape on the interface end of the dashed line (or tree of lines) that connects it to one or more implementers.
A plain arrow head is used on the interface end of the dashed line that connects it to its users.
Realizations can only be shown on class or component diagrams.
Represents an interface in Java or a delegate in Swift
Chapter 5 System modeling

33. Chapter 5 System modeling
Example
This is a comment box
Chapter 5 System modeling

34. Example: objective-C classes (inheritance)
Chapter 5 System modeling

35. Chapter 5 System modeling
Examples
See examples.html
We’ll look at several of these.
Chapter 5 System modeling

36. Example: Digital imaging in medicine
Purpose: Represent domain model ("model of the real world") for Digital Imaging and Communications in Medicine (DICOM) - Patient, Visit, Facility, Imaging Service Request, Scheduled Procedure Step, Modality Performed Procedure Step.
Summary: UML diagram example represents DICOM extended domain, abstract description of the real world objects used in the Modality-IS Interface.
Modality is a piece of medical imaging equipment, e.g. computed tomography (CT) or ultrasound (US).
Chapter 5 System modeling

37. Example: Digital imaging in medicine
A Patient is a human or an animal receiving, or registered to receive, healthcare services, or is the subject of research studies.
A Clinical Document is a part of the medical record of a patient. It is a documentation of clinical observations and services provided to the patient.
A Service Episode is a collection of events, context in which the treatment or management of an arbitrary subset of a Patient’s medical conditions occurs. Service episode is entirely arbitrary; it may include a single outpatient visit or a hospitalization, or extend over significant period of time, e.g., the duration of a pregnancy, or an oncology treatment regimen.
A service episode may involve one or more Healthcare Organizations (administrative entities that authorize Healthcare Providers to provide services within their legal administrative domain, e.g. hospitals, private physician’s offices, multispecialty clinics, nursing homes).
Chapter 5 System modeling

38. Example: Digital imaging in medicine
Chapter 5 System modeling

39. Chapter 5 System modeling
Key points
A model is an abstract view of a system that ignores system details. Complementary system models can be developed to show the system’s context, interactions, structure and behavior.
Context models show how a system that is being modeled is positioned in an environment with other systems and processes.
Use case diagrams and sequence diagrams are used to describe the interactions between users and systems in the system being designed. Use cases describe interactions between a system and external actors; sequence diagrams add more information to these by showing interactions between system objects.
Structural models show the organization and architecture of a system. Class diagrams are used to define the static structure of classes in a system and their associations.
Chapter 5 System modeling