Software Engineering Design Analysis

• Goal of engineering design analysis is to understand the software product design and the constraints (from requirements)

• The Engineering Design Analysis consist of 2 main tasks

1. Understanding (studying, clarifying, prioritizing, etc.) the SRS and product design

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

Analyze (SRS &Product Design)

SRS/ProductDesign

DesignDoc

PerformRest of Design

Steps

software engineering design

Recall Product Design is really requirements ---- your text author)

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. Defines the major system functionalities2. Defines the entities or actors (mostly users and other systems) that

interact with the system3. 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. Defines the “Classes” in the problem 2. 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

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 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” physical world item described in

the requirements document (e.g.)

• “A patient form must be filled by each patient” ---- (in describing the requirements for a hospital admittance process.)

– The entity may be a conceptual (“man-made”) item described in the requirements

(e.g.)• “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 forCLASSES.

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 Class2. Define the responsibilities of the Class3. 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

Earth

displaysrotate picture

users

Solar System

DisplayIndividual item

details

<<extends>>

<<include>>

<<include>>

Extension pts : planets, sun

Display StaticSolar System

System startup/shutdown

sys admin

IndividualPlanet

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

PatientP_Name: string [1.. 40]P_Address: string [1..50]P_Phone: string [1..10]P_Age: int .Get_P_Name( ): stringGet_P_Addres( ): stringInput_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 patientInformation inputted --- via constructor or a separate operation? )

Class Attribute Specification Format

• name : type [multiplicity ] = initial value

1. name : a “simple” name (no double colon to indicate composite) to identify the attribute; can not be suppressed

2. type : name of the data type or class type; may be suppressed

3. multiplicity : the number of values stored in the attribute; may be suppressed

4. 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 operation2. 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:

1. Classes

2. Associations among Classes

doctor

lab_test

patient

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)

visit

ord

er

1

0..N

What happens whena doctor visits anotherdoctor as a patient? (use role names?)

This constraintIs called multiplicity

Association among several Classes

library books

CDs

stores

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

customer Shopping-cart

item

buys

1 1- - - ncreates

1

1- - - n

moved

1- - - n

1

Can a cart be createdby more than 1 customer or an (same) item be bought bymore than 1 customer?

Discuss the Meaning of Following Class Diagram

Customer Cart

Item

buys

1 1..ncreates

0..1

1... *

moved

1.. *

1name: stringaddress: stringcardNumber: int

itemId: intitemPrice: float iteminStock: bool

getPrice( ): floatinStock(ItemId): bool

cartId: inttotalPrice: float totalItmes; Int

calcPrice( ): float

Do you agree with1..* and 1..n ?

note: - the associations are verbs

- the designers would have to decide where to put them (e.g. in which class?)

Recommended Heuristics & Conventionsfor 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 waterheater and provides more efficient control of the water temperature to save money andprotect the environment. Caldera sets the water heater thermostat high when hot wateris 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 andall 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 vacationor 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 setthe water heater thermostat

Example from Text (page 214)

Caldera is a smart water-heater-controller that attaches to the thermostat of a waterheater and provides more efficient control of the water temperature to save money andprotect the environment. Caldera sets the water heater thermostat high when hot wateris 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 andall 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 vacationor 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 setthe water heater thermostat

Initial “Sample” set of Classes(Conceptual Modeling of the Domain)

Water-heater-controller

Thermostat

Clock

Homeowner

sets

checks

specify parameters

lowTemp highTempwkendDayspkTimesmode

temp

time

What about responsibilities or functionalities?It is optional at this stage - - - Conceptual Modeling (Design)

Attribute types are left as suppressed first - - - because ?

Is this an “actor”outside of theUse Case &thus not a Domain Class ?

Initial Sample set of Classes, “refined”

Water-heater-controller

Thermostat

Clock

Homeowner-Interface

sets

checks

specify parameters

lowTemp : inthighTemp: intwkendDays: stringpkTimes: perd [1..3]mode: int

temp: float

time: int ?

setMode ( ):boolean

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

becoming aSoftware Class

Conceptual Modeling Activity Heuristics

• Identify important requirements (problem) concepts through the SRS document - potential classes:

– Physical entities, individuals, roles, 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

• Optionally add operations– Behavior of the class

• Add associations based on relationships such as:

– 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

SRS

ClassDiagram

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.

-You mayiteratewithin-May notfollow thesequence

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