Sommerville Chapter 7 Fowler Chapters 1, 3, 5, and 6 ... · Conceptual Modeling and Class Diagrams...
Transcript of Sommerville Chapter 7 Fowler Chapters 1, 3, 5, and 6 ... · Conceptual Modeling and Class Diagrams...
Conceptual Modeling and
Class Diagrams
Sommerville Chapter 7
Fowler Chapters 1, 3, 5, and 6
Announcements
HW2 handout now available on the
webpage.
Interpration of throttle position and its
relation to acceleration is different in HW2
Next tutorial in Week 4 on class diagrams
and sequence diagrams
<date/time><footer>
Objective for Today
To introduce conceptual modeling The goal of conceptual modeling
To review the OO solutionTo introduce and discuss the object model
(conceptual) Syntax and semantics
<date/time><footer>
Common Problems
The requirements are
wrong Incomplete, inconsistent,
or ambiguous The developer and the
customer did not
interpret the
requirements the same
way
Requirements drift The requirements tend to
change throughout the
project Late design changes
Continual change The functionality of the
system continually
changes Many changes come late
in the project Many changes during
maintenance
Breakdown of system
structure The system finally
becomes unusable
<date/time><footer>4
Solutions
Rigorous requirements and planning stage Make sure all stakeholders understand and
agree on the requirementsStructure the system design to
accommodate change Isolate parts that are likely to change Modularize so changes are contained Attempt to not compromise system structure
during change
<date/time><footer>5
The OO Solution
The problem domain is relatively constant Auto pilot Get a plane from point A to point B using the available
control surfaces
<date/time><footer>6
The OO Solution
The problem domain is relatively constant Auto pilot Get a plane from point A to point B using the available control
surfacesThe functionality and data representation is what is likely to
change Auto pilot The hardware interfaces are different between different
models The operational modes vary between models and evolve over
time
<date/time><footer>7
The OO Solution
The problem domain is relatively constant Auto pilot Get a plane from point A to point B using the available control
surfacesThe functionality and data representation is what is likely to
change Auto pilot The hardware interfaces are different between different
models The operational modes vary between models and evolve over
time
<date/time><footer>8
Structure the system based on the structure of the problem
domain, NOT based on the structure of the solution
What is OO
A way of thinking about a problem (software)
based on abstractions of concepts that exist in
the real worldOO is not constrained by implementation
language (C, Pascal, FORTRAN , etc. will
work)
<date/time><footer>9
What is not OO
Using an “object oriented” language (C++, Eiffel,
Smalltalk) You can easily misuse the OO support in these
languages
Using an “OO notation” for design Misuse the notation for a non-OO design
Calling what you do OO Management and customers like OO, therefore, that is
what we are doing
<date/time><footer>10
OO is not the answer to all your problems
Several Complementary
Models
Structural Models Describes the structure of the objects in a system Structure of individual objects (attributes and
operations) Relationships between the objects (inheritance,
sharing, and associations) Clustering of objects in logical packages and on the
actual hardware
Dynamic models (behavioral models) The aspects related to sequencing of operations Changes to attributes and sequences of changes The control aspects of the system
<date/time><footer>11
Conceptual ModelingA Short Discussion
F
al
l
2
0
1
3
C
S
ci
5
8
0
1
-
D
r.
M
a
ts
H
ei
m
d
a
hl
12
Conceptual Modeling
Early modeling to understand the problem
Conducted in cooperation with the
customer Domain experts Domain engineers
No real problem analysis if the customer is
not involvedPower of OO It is simple and people can quickly participate
effectively Or so they say…
<date/time><footer>13
The OO Solution
<date/time><footer>14
The OO model closely resembles the
problem domain Base your model on the objects in the problem
domainIteratively refine the high-level model until
you have an implementation Attempt to avoid big conceptual jumps during
the development process
The OO Solution (Cont.)
Organize the model as a collection of objects Concrete concepts in the physical world A drivers license, a credit card, an aircraft, etc.
Logical concepts A scheduling policy in an OS, ATC conflict resolution rules,
etc.
Encapsulate all information within the objects Data representation Characteristics of the object - the object attributes
Functionality (behavior) What the object can do - what operations can the object
perform
<date/time><footer>15
Fall 2013CSci 5801 - Dr. Mats Heimdahl16
Ajitha Rajan
123 4567 887766 998
Ajitha Rajan
Drivers License
A-123456
Objects
Characteristics of Objects
Identity Discrete and distinguishable entities
Classification Abstract entities with the same structure
(attributes) and behaviour (operations) into
classesPolymorphism The same operation may behave different on
different classesInheritance Sharing of attributes and operations based on a
hierarchical relationship
<date/time><footer>17
The Class Diagrams
F
al
l
2
0
1
3
C
S
ci
5
8
0
1
-
D
r.
M
a
ts
H
ei
m
d
a
hl
18
<date/time><footer>19
Objects
Something that makes sense in the
application context (application domain) Ajitha Rajan Joe’s Homework Assignment 1 Ajitha’s drivers license
All objects have identity and are
distinguishableNOT objects Person Drivers license
Classes
Describes a group of objects with similar
properties (attributes), common behavior
(operations), common relationships to other
classes, and common semantics Person Ajitha Rajan Joe Smith Allan Clark
Card Credit card Drivers license Teller card
<date/time><footer>20
Attributes and Operations
Fall 2013CSci 5801 - Dr. Mats Heimdahl21
Attributes
name
age
height
weight
Operations
move
change-job
Attributes
height
width
id-number
Operations
issue
change
Person objects
Card objects
Person class
Card class
abstracts to
Ajitha Rajan
Drivers License
A-123456Ajitha Rajan
123 4567 887766 998
Lisa Heimdahl
32
Person
Mats Heimdahl
33
Person
Class Diagrams
Fall 2013 CSci 5801 - Dr. Mats Heimdahl 22
Class with attributesObjects with values
Objects have an identity
Do not explicitly list
object identifiers
SSN OK!
Class diagram Instance diagram
person ID: integer
name: String
age: integer
Person
name: String
age: integer
Person
Class Diagrams
<date/time><footer>23
Class with attributesObjects with values
Objects have an identity
Class diagram
person ID: integer
name: String
age: integer
Person
name: String
age: integer
Person
Instance diagram
-name = Lisa Heimdahl
-age = 32
Person-1 : Person
-name = Mats Heimdahl
-age = 33
Person-2 : Person
<date/time><footer>24
Operations and Methods
Transformation that can be
applied to or performed by an
object
May have arguments
issue()
revoke()
height: integer
width: integer
thickness: integer
id-number: integer
Card
rotate(angle: integer)
move(x: integer, y: integer)
height: integer
width: integer
Shape
<date/time><footer>25
Object Notation - Summary
operation-1(argument-list-1) : result-type-1
operation-2(argument-list-2) : result-type-2
operation-3(argument-list-3) : result-type-3
attribute-1 : data-type-1 = default-value-1
attribute-2 : data-type-2 = default-value-2
attribute-3 : data-type-3 = default-value-3
Class name
<date/time><footer>26
Associations
Conceptual connection between classes A credit card is issued-by a bank A person works-for a company
Class diagrams
Instance diagram
Credit Card BankIssued-by
Person CompanyWorks-for
-name = Mats Heimdahl
-age = 33
Person-2 : Person U of M : Company
1 1
Works-for
<date/time><footer>27
Associations are Bi-
directional
There is no direction implied in an
association
Country
name
Drivers-license
lic.-number: integer
Person
name
City
nameHas-capital
Is-issued
<date/time><footer>28
Associations Have Direction
Unified adds a direction indicator
Country
name
Drivers-license
lic.-number: integer
Person
name
City
nameHas-capital
Is-issued
<date/time><footer>29
Multiplicity
One object can be related to many objects
through the same association
One person holds
one credit card
One person can hold
zero or more credit
cards
(* stands for many)
name: String
Person
card-number: integer
Credit-cardHolds
name: String
Person
card-number: integer
Credit-cardHolds 0..*
<date/time><footer>30
Multiplicity
One object can be related to many objects
through the same association
One person holds
one credit card
One person can hold
zero or more credit
cards
(* stands for many)
name: String
Person
card-number: integer
Credit-cardHolds
name: String
Person
card-number: integer
Credit-cardHolds 0..*
<date/time><footer>31
One person can hold zero or more credit cards (0..*)
Each card has zero or one holder (0..1)
Multiplicity (Cont.)
Mats Heimdahl
33
Person 123 456 789
Credit-Card
111 222 333
Credit-Card
Holds
Holds
name: String
Person
card-number: integer
Credit-cardHolds 0..*0..1
111 222 333
Credit-Card
Lisa Heimdahl
32
Person
<date/time><footer>32
One person can hold zero or more credit cards (0..*)
Each card has zero or one holder (0..1)
Multiplicity (Cont.)
Mats Heimdahl
33
Person 123 456 789
Credit-Card
111 222 333
Credit-Card
Holds
Holds
name: String
Person
card-number: integer
Credit-cardHolds 0..*0..1
111 222 333
Credit-Card
Lisa Heimdahl
32
Person
<date/time><footer>33
Multiplicity (Cont.)
One person can hold zero or more credit cards (0..*)
Each card has one holder (no indication or 1)
Each card has one or more authorized users (1..*)
One person can be authorized to use zero or more cards
Explicit enumeration is also
possible (2, 3, 2..5, etc.)
Lisa Heimdahl
32
Person
Mats Heimdahl
33
Person 123 456 789
Credit-Card
111 222 333
Credit-Card
111 222 333
Credit-Card
Holds
Holds
Autorized
Holds
Autorized
Autorized
Autorized
name: String
Person
card-number: integer
Credit-cardHolds 0..*
Autorized
1
1..* 0..*
<date/time><footer>34
How represent salary and
job title?
Use a link attribute!
Link Attributes
Associations can have properties the same way objects have
properties
name: String
age: integer
SSN: integer
address: String
Person
name: String
address: String
CompanyWorks-for 0..*
name: String
age: integer
SSN: integer
address: String
Person
name: String
address: String
CompanyWorks-for 0..*
salary: integer
job-title: String
Folding Link Attributes into
Class
<date/time><footer>35
Why not this?
Salary and job title are
properties of the job
not the person
name: String
age: integer
SSN: integer
address: String
salary: integer
job-title: String
Person
name: String
address: String
CompanyWorks-for 0..*
name: String
age: integer
SSN: integer
address: String
Person
name: String
address: String
CompanyWorks-for 0..*
salary: integer
job-title: String
0..*In this case, a link attribute is the only solution
Ordering
The objects on the “many” side of an association does not
have order.Imply ordering with the ordered attribute
WindowScreenVisible 0..*
{ordered}WindowScreen
Visible 0..*
<date/time><footer>37
General Constraints
Express constraints in plain EnglishDraw a dotted line if feasibleDo not clutter the diagram with constraint arrows!
<date/time><footer>38
Attribute Constraints
Constraints on the attributes Card number must be a 12 digit number Worker’s salary is always less than the salary of
the boss
Credit-card
card-number: integer
{card-number is 12 digits}
Employee
name
salary
address
boss
workerManages
{worker.salary < boss.salary}
0..*
0..1
39
Navigability
Indicates you can get information about
objects in only one direction Pointer from one object to the next Object defined as a member in the
implementation
F
al
l
2
0
1
3
<footer>40
Role Names
Attach names to the ends of an association
to clarify its meaning
name: String
age: integer
SSN: integer
address: String
Person
name: String
address: String
CompanyWorks-for 0..* 0..*
salary: integer
job-title: String
employeremployeeboss
workerManages
0..*
0..1
F
al
l
2
0
1
3
<footer>41
Higher order associations
Ternary association Project, language, person
Language
Person
Project1..*
1..*
1..*
Mats Heimdahl
33
Person
Compiler
Project
C++
Language
TicTacToe
Project
LISP
Language
42
Aggregation symbol
Aggregation
A special association, the is-part-of
association A sentence is part of a paragraph (a paragraph
consists of sentences) A paragraph is part of a document (a document
consists of paragraphs)
Document Paragraph Sentence0..* 0..*
43
Aggregation (Cont.)
Often used in parts explosion
Car
Wheel Body Gearbox Engine
Door Hood Trunk Piston Valve Crankshaft
0..*1..* 1..*
4
F
al
l
2
0
1
3
<footer>44
Generalization and Inheritance
The is-a association Cards have many
properties in common Generalize the common
properties to a separate
class, the base-card Let all cards inherit from
this class, all cards is-a
base-card (plus possibly
something more)
issue()
revoke()
height: integer
width: integer
thickness: integer
id-number: integer
Card
expire()
class: vehicle
issued: date
expires: date
Drivers License
expire()
issued: date
expires: date
ID Card
validate()
credit-limit: integer
issued: date
Credit Card
45
Example
name
City
name
Airline
name
license
Pilot
name
Passenger
heat()
clean()
name
Airport
cancel()
delay()
date
fl ight #
Flight
heat()
refuel()
clean()
model
serial #
hours flown
Plane
reserve()
location
Seat
Based-In 0..*
Departs
Works-for
Arrives Used-For
Certified-On
Owns
Located-In
0..*
Offers
Pilots
Confirmed-for
0..*
0..*
0..*
1..*
0..*
0..*0..*
0..*
30..*
<date/time><footer>46
Aggregation Versus
AssociationCan you use the phrase is-part-of or is-made-ofAre operations automatically applied to the parts (for
example, move) - aggregationNot clear what it should be……
Company DepartmentDivision
Person
0..*
Works-for
0..* 0..*
<date/time><footer>47
Aggregation Versus
InheritanceDo not confuse the is-a
relation (inheritance) with
the is-part-of relation
(aggregation)Use inheritance for
special cases of a
general conceptUse aggregation for parts
explosion
Car
Wheel
Body
Gearbox
Engine
4
Station
WagonCompact 4 by 4
Transfer
Case
Object Modeling Summary
Classes● Name● Attributes● Operations
Associations
Roles Link attributes
Aggregation
Inheritance
F
al
l
2
0
1
3
48
In Class Examples
Draw a class diagram for a
book chapter with the
following structure. A chapter
comprises several sections,
each of which comprises
several paragraphs and/or
figures. A paragraph
comprises several
sentences, each of which
comprises several words. Note 1: You may ignore
punctuation and you need
not pursue the structure of
a figure any further. Note 2: “Several” in the text
above refers to “one or
more”.
Draw a class diagram (using
inheritance) that captures
two categories of a
company’s customers:
external customers, which
are other companies buying
goods from this company,
and internal customer, which
are all the divisions of this
company.
F
al
l
2
0
1
3
49
F
al
l
2
0
1
3
50
Suggested Solution
Chapter Section Section Component
ParagraphSentenceWord Picture
1 1..* 1 1..*
11..*11..*
F
al
l
2
0
1
3
Another Suggested Solution
Corporate Division Customer
Internal Customer External Customers
Object Modeling Approach
Sommerville Chapter 7
Fowler Chapters 1, 3, 5, and 6
F
al
l
2
0
1
3
C
S
ci
5
8
0
1
-
D
r.
M
a
ts
H
ei
m
d
a
hl
52
Objective
To introduce one way of getting a model
startedIntroduce a way of starting to find
responsibilities, collaborators, and
relationships
<date/time><footer>53
Object Modeling Approach
Start with a problem statement High-level requirements
Define object model Identify objects and classes Prepare data dictionary Identify associations and aggregations Identify attributes of objects and links Organize and simplify using inheritance Iterate and refine the model Group classes into modules
F
al
l
2
0
1
3
54
The Home Heating System
Fall 2013CSci 5801 - Dr. Mats Heimdahl55
90
80
70
60
50
On
Off
Controller
Fuel Valve
Burner
Water Pump
Hot Water
Fuel
Temp Sensor
Water Valve
Control Panel
Home
Home Heating Requirements
<date/time><footer>56
The software shall control the heat in each
room The room shall be heated when the
temperature is 2F below desired temp The room shall no longer be heated when
the temperature is 2F above desired temp The flow of heat to each room shall be
individually controlled by opening and
closing its water valve The valve shall be open when the room
needs heat and closed otherwise The user shall set the desired temperature
on the thermostat The operator shall be able to turn the
heating system on and off The furnace must not run when the system
is off
When the furnace is not running and a room needs
heat, the software shall turn the furnace on To turn the furnace on the software shall follow
these steps open the fuel valve turn the burner on
The software shall turn the furnace off when heat
is no longer needed in any room To turn the furnace off the software shall follow
these steps close fuel valve turn burner off
The purpose of the software for the Home Heating System is to control the heating
system that heats the rooms of a house. The software shall maintain the temperature of
each room within a specified range by controlling the heat flow to individual rooms.
57
Requirements
Statements
Extract
Nouns
Tentative
Object Classes
Eliminate
Spurious Classes
Object
Classes
Candidate Classes
Controller
Fuel Valve
Burner
Water Pump
Hot Water
Fuel Temp Sensor
Water Valve
software
Home Heating System
heating systemroom
house
temperature
heatdesired temp
operator
thermostatfurnace
on-off switch Control Panel
Home
range
Identify Object Classes
Eliminate Bad Classes
Redundant classes Classes that represent
the same thing with
different words
Irrelevant classes Classes we simply do
not care about
Vague classes Classes with ill defined
boundaries
Attributes Things that describe
individual objects
Operations Sequences of actions are
often mistaken for classes
Roles The name of a class should
reflect what it is, not the role it
plays
Implementation details Save that for implementation
58
Controller
Fuel Valve Burner
Water Pump
Hot Water
Fuel
Temp Sensor Water Valve
software
Home Heating System
heating system
room
house
temperature
heat desired temp
operatorthermostat
furnace
Redundant Irrelevant Vague Attributes
Operations ImplementationRoles
None NoneNone
heat flow
on-off switch Control Panel
homeuser
range
Eliminate Classes
60
Controller
Fuel Valve
Burner
Water Pump
Temp Sensor
Water Valve
Home Heating System
Room
Operator
Thermostat Furnace
on-off switch
Control Panel
Classes After Elimination
Prepare Data Dictionary
Water Tank The storage tank containing the water that
circulates in the system.Pump-1 The pump pumping water from the Water Tank
to the radiators in the roomsEtc.Etc.
61
<date/time><footer>62
Possible Associations
A room consists of a thermometer and a radiator A radiator consists of a valve and a radiator element The home heating system consists of a furnace, rooms, a water
pump, a control panel, and a controller The furnace consists of a fuel pump and a burner The control panel consists of an on-off switch and a thermostat The controller controls the fuel pump The controller controls the burner The controller controls the water pump The controller monitors the temperature in each room The controller opens and closes the valves in the rooms The operator sets the desired temperature The operator turns the system on and off The controller gets notified of the new desired temperature
Class Diagram
F
al
l
2
0
1
3
<footer>63
Home Heating
System
Control Panel
On-Off Switch Thermostat
Room
Operator
Water Valve Temp Sensor
Furnace
Burner
Water Pump
Fuel Valve
Controller
Pushes Adjusts
Notifies
Monitor
Actuates
Ignites
Opens/Closes
Runs
1..*
Class Diagram (Better?)
F
al
l
2
0
1
3
<footer>64
Control Panel
On-Off Switch Thermostat
Room
Operator
Water Valve Temp Sensor
Furnace
Burner
Water Pump
Fuel Valve
Controller
Pushes Adjusts
No
tifies
M
on
itor
A
ctu
ate
s
Ignites
Opens/Closes
Runs
65
Class Diagram - Modified
Home Heating
System
Control Panel
On-Off Switch Thermostat
Room
Operator
Water Valve Temp Sensor
Furnace
Burner
Water Pump
Fuel Valve
Controller
Pushes Adjusts
Notifies
Monitor
Heats
Ignites
Opens/Closes
Runs
1..*
1..*
1..*
<date/time><footer>66
Class Diagram—Alternate
Fuel Valve Burner
Water Pump
Thermostat
Operator
Room
Water Valve Temp Sensor
Furnace
Power Switch
Control Panel
11
11
1 111
11
11
1
*
Notify
*
1
Request Heat
1
1
Start
1
1
Adjust1
1 Push
67
Temp Sensor
temperature
Thermostat
desired-temp
On-Off switch
setting
Attributes
68
Final Class Diagram
Home Heating
System
Control Panel
setting
On-Off Switch
desired-temp
Thermostat
Room
Operator
Water Valve
temperature
Temp Sensor
Furnace
Burner
Water Pump
Fuel Valve
Controller
Pushes Adjusts
Notifies
Monitor
Heats
Ignites
Opens/Closes
Runs
1..*
1..*
1..*
<date/time><footer>69
Final Alternative
Fuel Valve Burner
Water Pump
-Desired Temp
Thermostat
Operator
Room
Water Valve
-Temperature
Temp Sensor
Furnace
-setting
Power Switch
Control Panel
11
11
1 111
11
11
1
*
Notify
*
1
Request Heat
1
1
Start
1
1
Adjust1
1 Push
Iterate
Iterate the Model
Keep on doing this
until you, your
customer, and your
engineers are happy
with the model
Different Types of Interaction
Diagrams
An Interaction Diagram typically captures a
use-case A sequence of user interactions
Sequence diagrams Highlight the sequencing of of the interactions
between objectsCollaboration diagrams Highlight the structure of the components
(objects) involved in the interaction
<date/time><footer>71
<date/time><footer>72
Home Heating Use-Case
Use case: Power Up
Actors: Home Owner (initiator)
Type: Primary and essential
Description: The Home Owner turns the power on. Each room
is temperature checked. If a room is below the
the desired temperature the valve for the room is
opened, the water pump started, the fuel valve
opened, and the burner ignited.
If the temperature in all rooms is above the desired
temperature, no actions are taken.
Cross Ref.: Requirements XX, YY, and ZZ
Use-Cases: None
F
al
l
2
0
1
3
<footer>73
Class Diagram—v1
Control Panel
setting
On-Off Switch
desired-temp
Thermostat
Room
Operator
Water Valve
temperature
Temp Sensor
Furnace
Burner
Water Pump
Fuel Valve
Controller
Pushes Adjusts
No
tifies
M
on
itor
H
ea
ts
Ignites
Opens/Closes
Runs
1..*
1..*
<date/time><footer>74
Sequence Diagrams (for cd—
v1)
Sequence Diagrams (old)
(for cd—v1)
<date/time><footer>75
We Have Learned
An object is an entity in the problem domainA class is an abstraction of a collection of objectsObjects (classes) have attributes and operations Objects (classes) are related to each other trough associations
Regular association Aggregation Inheritance
Associations have multiplicity May have link attributes
Role names may be used to clarify the model
<date/time><footer>76
We Have Learned
How to approach an OO modeling effort Identify objects (nouns) Identify associations (typically verbs) Identify attributes and operations
The model will need a lot of iteration In conjunction with other models we have not
yet talked about We will the next few lectures
Fall 2013CSci 5801 - Dr. Mats Heimdahl77