Software Engineering Design Analysis
•
•
Goal of engineering design
analysis is to understand the
software engineering design
software product design and
the constraints (from
requirements)
SRS/Product
Analyze (SRS &
The Engineering Design
Design
Product Design)
Analysis consist of 2 main
tasks
1.
2.
•
Understanding (studying,
clarifying, prioritizing, etc.)
the SRS and product design
Develop a “new” model of the
design problem if necessary
The result of design analysis
“often” requires further
clarification and rework of the
SRS and product model
Perform
Rest of Design
Steps
Recall Product Design is really requirements ---- your text author)
Design
Doc
Engineering Design Analysis
•
Engineering Design Analysis Model is a representation of a
design “problem” (the modeling of the issues related to
requirements)
–
Dynamic aspects may be represented with Use Case Diagram and
Use Case Description which
1.
2.
3.
–
Defines the major system functionalities
Defines the entities or actors (mostly users and other systems) that
interact with the system
Describes the actual interactions via scenarios’ descriptions
Static aspects may be represented with Conceptual Model (or
Analysis Class Model if using OO).
(Using OO techniques)
1.
2.
Defines the “Classes” in the problem
Associations among Classes
Note: Both Use Case Diagram/Descriptions and Conceptual Model
(OO Class Diagram) may be used for both requirements and design
activities
Use Case and Conceptual Model
• Use Case:
– Represents the
requirements and the
behavior of the needed
system
– Does not describe the
solution
– ‘Usually” does not
describe in detail the
entities or the structure
in the problem/solution
(does describe
interactions between
actors and the system)
• Conceptual Model:
– Also represents the
problem/solution, the
static aspects
– Does not “quite” describe
the solution, but start to
– Does describe (more
detail of)
• the real world and
possible artificial entities
• relations among these
entities
What type of model did you all do for the Solar System assignment?
3 Levels of Model in Analysis and Design
OO Model
1.
Conceptual Model (or Domain Model) : represent the
entities in the problem-(some solution) domain a) their characteristics, and b) relationships among
the entities (the entities may be represented in the
form of OO classes)
2.
Design Class Model: represents the entities in the
solution – a) their attributes, b) operations, and c)
relationships among the entities independent of the
implementation language or platform
1.
Implementation Class Model: represents the classes
in the implementation of the solution and all the
details which were left out in the Design Class
Model
OO Code
Conceptual Model
• Conceptual model is the “bridge” between requirements
(problem) and design (solution).
• Conceptual Modeling is used for Analysis of “mostly”
requirements:
– Understanding the problem domain:
• the major entities,
• the responsibilities (or functionalities) of these entities,
• and the relationships among these entities
– Understanding the data requirements that are associated with
entities, their characteristics, and their relationships
--------- ----------– Reviewing/Inspection of the SRS against the Conceptual Model
With a Conceptual Model, many of the entities, characteristics, responsibilities,
and relationships that are portrayed in the problem domain may be transformed
into classes, attributes, operations, and associations in the Design Model
So --- How do we come up with an entity (CLASS)?
• A CLASS is an abstraction of an entity in requirements at this
stage.
– The entity may be a “real”
the requirements document
(e.g.)
physical world item described in
• “A patient form must be filled by each patient” ---- (in describing the
requirements for a hospital admittance process.)
– The entity may be a conceptual
described in the requirements
(e.g.)
(“man-made”) item
• “When the patient’s accrued backlog payment amount is more than
$10,000, a statement of possible financing alternatives is included in
the financial invoice statement to the patient” ---- (in describing the
billing statement of a hospital system)
(note that financial invoice statement may be verbal, electronic, or
paper in form; but it is not a “real/natural” world item.)
At the Conceptual Design level, we are dealing with requirements and design. Thus the
“major entities” mentioned in the requirements document are candidates for
CLASSES.
Note: CLASSES may have to be defined and altered several times in Conceptual Design and
even in the later Design Class Model !
Identifying Key Component
1.
Identifying key components or Classes is the first
step.
–
Just “listing” the Classes’ names (no other information about
the Classes, yet ---- then think about properties)
2.
After thinking about what functionalities (or
responsibilities) these Classes should possess ----(we may actually change our minds and combine
some Classes ---- we now are starting to drop into
“Designing” Class Model)
3.
We may start to associate Classes in terms of
relationships
CRC “Card” Approach
• CRC is an old, but popular approach at this stage to
view the “problem/solution world” and identify the
“key” components of the problem arena.
– C : Class (“key” component)
– R : Responsibility (functionality/feature)
– C : Collaboration (interfaces with other Classes)
• The identified Entities (“Classes”) in requirements
(from Use Case) are often “directly” converted to
Classes to be used in the Design
CRC Technique for Modeling (cont.)
• Class-Responsibility-Collaboration (CRC) is an object
oriented modeling technique:
1. Identify or “Design” a Class
2. Define the responsibilities of the Class
3. Define the structural relationship among the Classes
• For Conceptual Model,
–
–
–
the Class may be a physical or non-physical entity in the
problem domain.
Responsibilities are the services (or functionalities) that the
Class will provide
Collaboration shows the relationships among the classes
• A CRC card is just a small card that lists the Class
name, its set of responsibilities, and which other
Classes it interacts with.
In “theory,” Conceptual Model for Design Analysis contain only Classes which are
real-world entities that are in the requirements --- but in practice we also start to
include non-real world entities and invent (getting into design) new classes.
“Class Discussion” on What Solar System Conceptual
Design may include ( ---- start with)
Solar System
users
Display Static
Solar System
Extension pts : planets,
Earth
sun
<<include>>
rotate picture
<<extends>>
<<include>>
Display
Individual item
details
System startup/
shutdown
sys admin
Solar
displays
System
Individual
Planet
Class Discussion of Conceptual Design
(--- from past ---)
• You started to relate “major entities”
• “Sam” --- wanted to talk about functionalities
--- - that a major entity provides !
– So how should we do that? --- Use Class Diagram
CLASS Representation in UML
• A Class is composed of
3 parts:
– Class name
• character string that
identifies the Class
– Class attributes
• list of characteristics of the
Class that are eventually
stored in “variables” and
“constants”
– Class operations
• list of services or
functionalities provided by
the Class’s methods
Patient
P_Name: string [1.. 40]
P_Address: string [1..50]
P_Phone: string [1..10]
P_Age: int
.
Get_P_Name( ): string
Get_P_Addres( ): string
Input_P_Name ( )
.
.
1) Coming up with CLASS is an important and difficult design task!!!
2) At this point, don’t get too tangled up in the details, yet. (e.g. how is the patient
Information inputted --- via constructor or a separate operation? )
Class Attribute Specification Format
•
name : type [multiplicity ] = initial value
1.
2.
3.
4.
name : a “simple” name (no double colon to indicate
composite) to identify the attribute; can not be
suppressed
type : name of the data type or class type; may be
suppressed
multiplicity : the number of values stored in the attribute;
may be suppressed
initial value : initial value assigned to the attribute; may be
suppressed
Some notes: - multiplicity may be comma separated list of ranges of non-negative
numbers, where each range is in the form of j---k (e.g. 1---6)
- * stands for unlimited upper bound 0---* mean 0 or more.
- if multiplicity is suppressed, it is assumed to be 1 and the [ ] sign may be
dropped
Class Operations Specification
•
name ( parameter-list ) : return-type-list
1. name : a “simple” name of the operation
2. parameter list : a comma separated list of names and types of the
parameters of this operation in the form of :
direction param-name : param-type = default value
–
–
–
–
direction is either in, out, inout, return ; if suppressed it is assumed to be in
param-name is the simple name of the parameter
param-type is the data type or class of the parameter
default value is the initial value of the parameter if it is not specified
3. return type list : a comma separated list of types of values
returned by the operation
Note: - both parameter-list and return-type-list may be suppressed
- if parameter-list is suppressed, the parenthesis, ( ), must still show
Using CLASS diagram for Conceptual
Modeling
• In describing or developing a “SOLAR System”, the
sun and planets may be thought of as CLASSes
Discuss:
1. Should sun and planets be a CLASS individually?
2. If so what may be its attributes and operations?
- as we ask these questions --- we may also be
clarifying our requirements
- class diagram may also be viewed as a conceptual
modeling tool for static structure of the requirements
A “simple” CLASS Diagram
•
A Class diagram is
composed of 2 main
set of items:
Classes
0..N
2.
Associations among
Classes
visit
patient
1
order
1.
doctor
What happens when
a doctor visits another
doctor as a patient?
(use role names?)
lab_test
1. doctors, patient, and lab_tests are the Classes.
2. The “lines” represent associations among these classes.
-The associations may also be labeled with “visit” and “order”
-Constraints may be placed on the associations (e.g. lab-test must be
ordered by at least one doctor but a doctor may order 0 to N lab tests
-Navigability may also be placed on the association, with arrows,
(e.g. would show the association from the end towards the arrow)
This constraint
Is called multiplicity
Association among several Classes
stores
books
library
CDs
The library stores books and stores CDs; the diamond is used as the connection.
This multiple association can be confusing sometimes.
Discuss the “Meaning” of the Following (Key
Components) Class Diagram
1
creates
1- - - n
customer
1
Can a cart be created
by more than 1 customer
or
an (same) item be bought by
more than 1 customer?
Shopping-cart
1
1- - - n
1- - - n
item
Discuss the Meaning of Following Class
Diagram
1
creates
1..n
Customer
name: string
address: string
cardNumber: int
Cart
0..1
1
cartId: int
totalPrice: float
totalItmes; Int
calcPrice( ): float
1... *
1.. *
Item
note: - the associations are verbs
- the designers would have
to decide where to put them
(e.g. in which class?)
itemId: int
itemPrice: float
iteminStock: bool
getPrice( ): float
inStock(ItemId): bool
Do you agree with
1..* and 1..n ?
Recommended Heuristics & Conventions
for Class Diagram
• Classes, attributes, and roles most likely come from “noun
phrases” in requirements/use case
• Operations and associations most likely come from “verb
phrases” in requirements/use case
• In Class Diagram, capitalize the Class name, but not the others
• Stick to binary associations as much as possible because
associations among three or more classes are harder to
understand.
• Evade role names and use association names as much as
possible because of possible confusion
• Place multiplicity, role name and association on the opposite
side of the association of a single instance of class.
Example from Text (page 214)
Caldera is a smart water-heater-controller that attaches to the thermostat of a water
heater and provides more efficient control of the water temperature to save money and
protect the environment. Caldera sets the water heater thermostat high when hot water
is much in demand and sets it low when there is not much demand. For example,
Caldera can be told to set the thermostat high on weekday mornings and evenings and
all day on weekends, and low during the middle of weekdays and at night.
Furthermore, Caldera can be told to set the thermostat high all the time in case of
illness or other need, or be told to set the thermostat low all the time in case of vacation
or some other prolonged absence from home.
The homeowner can specify values for the following Caldera parameters:
- Low Temp – temperature when little or no hot water is needed
- High Temp – temperature when much hot water is needed
- Weekend Days – days when the thermostat will be set to High Temp all day long;
on all other days it will be set between Low Temp and High Temp.
- Peak times – From 1 to 3 time periods on a 24 hour-clock during which thermostat will
be set to High Temp on non-Weekend Days. On Weekend Days, the
thermostat will be set to High Temp during the entire period between
the earliest time and the latest time set in Peak times.
Caldera has the following states called modes:
i) Stay Low mode – Thermostat is set to stay at Low Temp
ii) Stay High mode – Thermostat is set to stay at High Temp
iii) Normal mode – Thermostat is changed between Low Temp and High Temp on a
regular schedule, as explained above.
Caldera has its own internal clock that it checks every second to determine how to set
the water heater thermostat
Example from Text (page 214)
Caldera is a smart water-heater-controller that attaches to the thermostat of a water
heater and provides more efficient control of the water temperature to save money and
protect the environment. Caldera sets the water heater thermostat high when hot water
is much in demand and sets it low when there is not much demand. For example,
Caldera can be told to set the thermostat high on weekday mornings and evenings and
all day on weekends, and low during the middle of weekdays and at night.
Furthermore, Caldera can be told to set the thermostat high all the time in case of
illness or other need, or be told to set the thermostat low all the time in case of vacation
or some other prolonged absence from home.
The homeowner can specify values for the following Caldera parameters:
- Low Temp – temperature when little or no hot water is needed
- High Temp – temperature when much hot water is needed
- Weekend Days – days when the thermostat will be set to High Temp all day long;
on all other days it will be set between Low Temp and High Temp.
- Peak times – From 1 to 3 time periods on a 24 hour-clock during which thermostat will
be set to High Temp on non-Weekend Days. On Weekend Days, the
thermostat will be set to High Temp during the entire period between
the earliest time and the latest time set in Peak times.
Caldera has the following states called modes:
i) Stay Low mode – Thermostat is set to stay at Low Temp
ii) Stay High mode – Thermostat is set to stay at High Temp
iii) Normal mode – Thermostat is changed between Low Temp and High Temp on a
regular schedule, as explained above.
Caldera has its own internal clock that it checks every second to determine how to set
the water heater thermostat
Initial “Sample” set of Classes
(Conceptual Modeling of the Domain)
Water-heatercontroller
Homeowner
Is this an “actor”
outside of the
Use Case &
thus not a Domain Class ?
lowTemp
highTemp
wkendDays
pkTimes
mode
sets
Thermostat
temp
Clock
time
Attribute types are left as suppressed first - - - because ?
What about responsibilities or functionalities?
It is optional at this stage - - - Conceptual Modeling (Design)
Initial Sample set of Classes, “refined”
Water-heatercontroller
HomeownerInterface
lowTemp : int
highTemp: int
wkendDays: string
pkTimes: perd [1..3]
mode: int
becoming a
Software Class
setMode ( ):boolean
sets
Thermostat
temp: float
Clock
time: int
1) Defining pkTimes as perd type with multiplicty of 1..3 leaves a lot open.
2) By defining mode attribute as integer type and putting setMode( ) in as the
responsibility of water-heater-controller, we have started on our design - - - - from
Conceptual Model to Design Class Model
3) Changing Homeowner to Homeowner Interface is moving out of Conceptual
Modeling
?
Conceptual Modeling Activity Heuristics
•
Identify important requirements
(problem) concepts through the SRS
document - potential classes:
– Physical entities, individuals, roles,
SRS
groups
– Items tracked, recorded, or presented
– People, devices, systems that
interact with the system
•
•
•
Add attributes to the class
– Characteristics such as size, color,
model number, or any identifier
-You may
Optionally add operations
iterate
– Behavior of the class
Add associations based on
relationships such as:
within
-May not
follow the
sequence
– Control, coordinate, attend,
supervise, send, order, part of, is-a,
above, inside, etc.
Conceptual Modeling
Identify classes
Add attributes/operations
Identify associations
Add association
constraints
1. Note that most of the classes are represented as “noun or noun phrases”
2. Note that most of the attributes and behavior are in “noun” and “verb” forms, respectively.
Class
Diagram
Some Thoughts to Keep in Mind
as You do Conceptual Modeling & Design
• Use “meaningful” names to represent your thought,
especially for those non-physical entities. e.g. Class
name, attribute name, etc.
• Strive for coherent components --- grouping attributes
and actions that are “related” as you design the Class.
• Ensure that what you are portraying is accurate --e.g. it does represent what you want
• Do not insert extraneous material, which are not called
for in the requirements, into the Design. e.g. additional
generalization for the future.
• *** Check that the Conceptual Model “design” is
complete – e.g. all characteristics and functionalities from
requirements are included. ***