Chapter 5 – System Modeling Lecture 2 We don't have time to stop for gas, we're already late. M....

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)

1Chapter 5 System modeling

Topics covered

Context models

Interaction models

Structural models

Behavioral models

Model-driven engineering


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.


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


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 5

UML classes and association


Classes and associations in the MHC-PMS


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

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.


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


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.


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.


Associations: uni-directional


Class 1 contains an instance of class 2

Association: bi-directional


0..1 No instances, or one instance (optional, may)1 Exactly one instance0..* or * Zero or more instances1..* One or more instances (at least one)

This example is bi-directional.A Person may subscribe to many MagazinesA Magazine may have many subscribers

role

Field in Person that holds a Magazine instance

Multiplicity the number of magazines that participate


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.


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.

Chapter 5 System modeling 16Ownership of association may be indicated graphically by a small filled circle (aka dot).


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

In code:

class Query {

QueryBuilder qbuilder;

}


The attribute (query for class QueryBuilder and qbuilder for class Query) is the reference to the associated object


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 18


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).


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.



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.


Note here that a Patient record contains 1 Patient but many Consultations


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

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


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.

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

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.


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.


A generalization hierarchy


A generalization hierarchy with added detail


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


Example


This is a comment box

Example: objective-C classes (inheritance)


Examples

See http://www.uml-diagrams.org/class-diagrams-examples.html

We’ll look at several of these.


http://www.uml-diagrams.org/class-diagrams-examples.html

http://www.uml-diagrams.org/class-diagrams-examples.html

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).



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).


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 Lecture 2 We don't have time to stop for gas, we're already late. M....

Documents

Transcript of Chapter 5 – System Modeling Lecture 2 We don't have time to stop for gas, we're already late. M....