Chapter 5System Modeling
Sommerville, "software engineering " , 9th Ed., 2011
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.
Structural models may be static models, which show the structure of the system design, or 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.
2Chapter 5 System modeling
Class diagrams
Class diagrams are used when developing an object-oriented system model to show the classes in a system and the associations between these classes.
An object class can be thought of as a general definition of one kind of system object.
An association is a link between classes that indicates that there is some relationship between these classes.
When you are developing models during the early stages of the software engineering process, objects represent something in the real world, such as a patient, a prescription, doctor, etc.
3Chapter 5 System modeling
Class diagram
In software engineering, a class diagram in UML is a type of static structure diagram that describes the structure of a system by showing the system's classes, their attributes, operations (or methods), and the relationships among the classes.
Chapter 5 System modeling 4
The Consultation class
5Chapter 5 System modeling
Object class aggregation models
An aggregation model shows how classes that are collections are composed of other classes.
Aggregation models are similar to the part-of relationship in semantic data models.
6Chapter 5 System modeling
The aggregation association
7Chapter 5 System modeling
Essential Elements of Class Diagram
ClassAttributesOperationsRelationshipsConstraint Rules and Notes
8
Class diagram
Classes are composed of three things: a name, attributes, and operations. Below is an example of a class.
9
Class attributes
10
• attributes (fields, instance variables)– visibility name : type [count] = default_value
– visibility:+ public# protected- private~ package (default)/ derived
– underline static attributes
– derived attribute: not stored, but can be computed from other attribute values
– attribute example:- balance : double = 0.00
11
Class operations / methods• operations / methods
– visibility name (parameters) : return_type
– visibility: + public# protected- private~ package (default)
– underline static methods– parameter types listed as (name: type)– omit return_type on constructors and
when return type is void
– method example:+ distance(p1: Point, p2: Point): double
Comments
12
• represented as a folded note, attached to the appropriate class/method/etc by a dashed line
Classes and objects : summary
Objects are instances of classes.
Classes define the behaviour and the data types for an object
Data held in instances of the same class will typically vary.
Instances of the same class provide exactly the same services (subject to the data not controlling the flow).
13
Relationships
In UML, object interconnections are modeled as relationships.
The kinds of relationships in UML: Generalizations Associations Aggregation Composition
Class Diagram Relationships
Class
Generalization
Object
Association
Aggregation
Composition
Class Diagram Relationships
o Generalization (Class-to-Class) (Superclass/Subclass)
• Inheritance
• Example: Person - FacultyPerson, StudentPerson, Staff...
• Example: ModesOfTravel - Airplane, Train, Auto, Cycle, Boat...
o [Object] Associations• FacultyInformation - CourseInformation
• StudentInformation - CourseInformation
o [Object] Aggregations & Composition (Whole-Part)
• Assembly - Parts
• Group - Members
• Container - Contents
17
Multiplicities
Class
Class
Class
Class
1
0*..
0..1
m..n
exactly one
many(zero or more)
optional(zero or one)
numericallyspecified
Course CourseOffering1
0*..
Example:
Generalization Relationships
A generalization is used when two classes are similar, but have some differences. Look at the generalization below:
18
Generalization Relationships
Generalization is an everyday technique that we use to manage complexity.
Rather than learn the detailed characteristics of every entity that we experience, we place these entities in more general classes (animals, cars, houses, etc.) and learn the characteristics of these classes.
This allows us to infer that different members of these classes have some common characteristics e.g. squirrels and rats are rodents.
Chapter 5 System modeling 19
Generalization Relationships
In modeling systems, it is often useful to examine the classes in a system to see if there is scope for generalization. If changes are proposed, then you do not have to look at all classes in the system to see if they are affected by the change.
In object-oriented languages, such as Java, generalization is implemented using the class inheritance mechanisms built into the language.
In a generalization, the attributes and operations associated with higher-level classes are also associated with the lower-level classes.
The lower-level classes are subclasses inherit the attributes and operations from their superclasses. These lower-level classes then add more specific attributes and operations.
Chapter 5 System modeling 20
A generalization hierarchy
21Chapter 5 System modeling
A generalization hierarchy with added detail
22Chapter 5 System modeling
Generalization Relationships
A sub-class inherits from its super-class Attributes Operations Relationships
A sub-class may Add attributes and operations Add relationships Refine (override) inherited operations
23
Association Relationships
If two classes in a model need to communicate with each other, there must be link between them.
An association denotes that link.
InstructorStudent
Associations
o A semantic relationship between two or more classes that specifies connections among their instances.
o A structural relationship, specifying that objects of one class are connected to objects of a second (possibly the same) class.
o Example: “An Employee works for a Company”
CompanyDepartmentEmployee
25
Associations (cont.)
An association between two classes indicates that objects at one end of an association “recognize” objects at the other end and may send messages to them. This property will help us discover less trivial associations
using interaction diagrams.
26
Association Relationships (Cont’d)
We can indicate the multiplicity of an association by adding multiplicity adornments to the line denoting the association.
The example indicates that a Student has one or more Instructors:
InstructorStudent1..*
Association Relationships (Cont’d)
The example indicates that every Instructor has one or more Students:
InstructorStudent1..*
Association Relationships (Cont’d)
We can also indicate the behavior of an object in an association (i.e., the role of an object) using rolenames.
InstructorStudent1..*1..*
learns fromteaches
Association Relationships (Cont’d)
We can also name the association.
TeamStudentmembership
1..* 1..*
Association Relationships (Cont’d)
We can specify dual associations.
TeamStudent
member of
1..*
president of1 1..*
1..*
Association Relationships (Cont’d)
We can constrain the association relationship by defining the navigability of the association. Here, a Router object requests services from a DNS object by sending messages to (invoking the operations of) the server. The direction of
the association indicates that the server has no knowledge of the Router.
Router DomainNameServer
Association Relationships (Cont’d)
A class can have a self association.
LinkedListNode
next
previous
Course
0*..
0*..
has pre-requisite of
is pre-requisite for
Association Relationships (Cont’d)
•We can model objects that contain other objects by way of special associations called aggregations and compositions.
•An aggregation specifies a whole-part relationship between an aggregate (a whole) and a constituent part.
•The part can exist independently from the aggregate. Aggregations are denoted by a hollow-diamond adornment on the association.
Car
Engine
Transmission
Aggregation
A special form of association that models a whole-part relationship between an aggregate (the whole) and its parts. Models a “is a part-part of” relationship.
Whole Part
Car Door House1..*2..*
35
Aggregation (cont.)
Aggregation tests:Is the phrase “part of” used to describe the
relationship?A door is “part of” a car
Are some operations on the whole automatically applied to its parts?
Move the car, move the door.Are some attribute values propagated from the
whole to all or some of its parts?The car is blue, therefore the door is blue.
Is there an intrinsic asymmetry to the relationship where one class is subordinate to the other?
A door is part of a car. A car is not part of a door.
36
Composition
•A composition indicates a strong ownership and coincident lifetime of parts by the whole (i.e., they live and die as a whole).
•Compositions are denoted by a filled-diamond adornment on the association.
Window
Scrollbar
Titlebar
Menu
1
1
1
1
1
1 .. *
Composition
A strong form of aggregationThe whole is the sole owner of its part.
The part object may belong to only one whole
Multiplicity on the whole side must be zero or one.
The life time of the part is dependent upon the whole. The composite must manage the creation and destruction
of its parts.
38
Aggregation and Composition
• Aggregation (shared aggregation):• is a specialized form of ASSOCIATION in which a whole is related to its
part(s).• is known as a “part of” or containment relationship and follows the “has a”
heuristic• three ways to think about aggregations:
• whole-parts• container-contents• group-members
• Composition (composite aggregation):• is a stronger version of AGGREGATION• the “part(s)” may belong to only ONE whole• the part(s) are usually expected to “live” and “die” with the whole
(“cascading delete”)
• Aggregation vs. Composition vs. Association???
40
Aggregation Composition
0*..
1*..
Faculty
CourseTeaching
1*..
1
SalesOrder
SalesOrderLineItem
(another: hand --> finger)(another: assembly --> part)
(team-teaching is possible)
Static modeling: sum up
Steps during static modeling 1. Object/Class identification
• Start with the nouns in the use cases event flows 2. Find the attributes
• nouns 3. Find the methods 4. Find the associations between classes
• Association, generalization, aggregation, composition 5. Find the multiplicity relationship between classes
41
Example
42
1
0,m
UniversityCourse
StudentInCourse
StudentInformation
1
0,m
Example
43
44
Class diagram example 2
DVD Movie VHS Movie Video Game
Rental Item
Rental Invoice
1..*1
Customer
Checkout Screen
0..1
1
Simple
Association
Class
Abstract
Class
Simple
Aggregation
GeneralizationComposition
Multiplicity
Dynamic Modeling:State Diagrams
State A condition during the life of an object during which it
satisfies some conditions, performs some actions or waits for some events
Shown as a rectangle with rounded corners State Transition
The changes in the attribute of an object or in the links an object has with other objects
Shown as a solid arrow Diagrammed with a guard condition and action
Event Something that takes place at a certain point in time
20.4520.45
Slide 46
Behavioral State Machines
• The behavioral state machine is a dynamic model that shows the different states of the object and what events cause the object to change from one state to another, along with its responses and actions.
Slide 47
Elements of a Behavioral State Machine
• States• Events• Transitions• Actions• Activities
Slide 48
Example Behavioral State Machine Diagram
Slide 49
Behavioral State Machine Diagram Syntax
A STATE
AN INITIAL STATE
A FINAL STATE
AN EVENT
A TRANSITION
A Frame
Slide 50
Building Behavioral State Machine Diagrams
• Set the context• Identify the initial final, and stable states of the
object• Determine the order in which the object will pass
through stable states• Identify the events, actions, and guard conditions
associated with the transitions• Validate the statechart diagram
Analysis Versus Design
Start with existing set of analysis modelProgressively add technical detailsDesign model must be more detailed than
analysis modelComponent Diagram
A diagram that shows the software components or modules and their dependencies
Deployment Diagram A diagram that shows how the software
components, process and objects are deployed into the physical architecture of the system
20.5120.51
Summary
Object-Oriented modeling approach Benefits Unified Modeling Language
• Use cases
• Class diagrams
• State diagrams
• Sequence diagrams
• Activity Diagrams
Use-case modeling
20.5220.52
Summary
Object Modeling: Class Diagrams Associations Generalizations Inheritance and Overriding Aggregation
Dynamic Modeling: State Diagrams
Dynamic Modeling: Sequence Diagrams
Analysis Versus Design
20.5320.53
Questions???
Thanks for your Attention!
Slide 54