• Goal of developing a
Design Resolution is to develop a design of the solution to the problem stated in the requirements. software engineering design
SRS Design Analysis
• The Design Resolution consist of 2 main parts
1.
Architectural Design
2.
Detailed Design
• The result of design resolution is recorded in the design document from which code implementation can be performed.
Design Resolution:
- Architectural
- Detailed
Design
Doc

• At the end of Design Analysis , we have looked at the requirements and the “System” mainly as a black box in terms of the external behavior and external characteristics – although we have started to get into “potential” internals with Class
Diagrams .
• Designing is composed of 2 main levels :
A) Architectural : where the following are defined
1.
major components ,
2.
their responsibilities, properties, interfaces
3.
their high level structure (relationships and interactions) among components
B) Detailed : where the following are defined
1.
internal elements of the major components,
2.
their processing algorithms of the responsibilities and attribute structure of the properties (data structure)
3.
internal elements’ structures , relationships , and interactions

•
– Assignment of responsibilities (functionalities) to the main components
– Specification of properties of the main components
{ Specification of the states and transitions of states of the main components (note that state is a property)
} back
& modify
– Specification of relationships among components may loop
• Specification of collaboration among components (note that collaboration is a kind of a relationship )
• Specification of interfaces among components

“Requirements,”
“Use Cases, “
“Conceptual Model”
Water Heating
System (Caldera) level 0
User
Interface
Heating
Control level 1 level 2
Water Heater
Controller
Thermostat
Interface
Timer
Interface

.
(A)
Financial
System
Acct.
Pay.
Acct.
Rec .
Gen.
Ledger
Decomposed into main parts by “
Responsibilities
” or functionalities
- What other criteria may be used for decomposing into parts?
(B)
Acct-Pay
Gen_Ledger
Acct-Rec.
Identifying relationships
We still need to specify interfaces among the components and key properties

.
Financial
System
UI
Financial
Logic
DB
Process/Control
(messages, interrupts, etc.)

• De SCRIPTR
– ** Decomposed system into major components **
• De S CRIPTR
–
States that the major components may exist in
• DeS C RIPTR
– Collaboration among components to achieve a goal
• DeSC R IPTR
– ** Relationships among the major components in terms of dependencies and communications **
• DeSCR I PTR
– ** Interfaces among the components that have relationships **
• DeSCRI P TR
– ** Properties that the major components must possess or satisfy **
• DeSCRIP T R
– Transitions of components’ states
• DeSCRIPT R
– ** Responsibilities of the major components **
An Architectural Design document may contain all or parts of this list.
Should have the
** items of the above list.

• Detailed Design is a further refinement of the
Architecture Design, starting with detailed decomposition of major components and all the subsequent refinements associated with smaller elements. Thus a refined DeSCRIPTR is part of the detailed design.
• There are 4 more considerations in Detailed Design:
( PAID )
1.
Packaging of the components and related element
2.
Algorithms that need to used to implement the services/functionalities
A bit early?
3.
Implementation specifications for the packaged components, including language specific concerns
4.
Data structures and data types needed for the implementation

Design Principles
1) Basic
2) Construction
Design “Criteria”
3) User
Oriented
Aesthetic
Feasible Economical
Implementability
Adequate Changeable
Modularity delight small least privilege
Info hiding coupling cohesion simple reuse reusable
“Beauty” in design
(simple
& powerful)
Improve & extend experience

• Design Principles help make the design better. Some are the same as other disciplines and some are specific to software engineering. The “Basic” Design Principles are meant to “improve on satisfying product specification”
(more general): ---closer to Design Analysis
– Feasibility
• The proposed design can be technically implemented , thus realizable
– Adequacy
• The proposed design meets the stakeholders needs and expectations (note: expectations are sometimes desires)
– Economy
• The proposed design can be implemented within reasonable cost
(people resource and tool resources) and reasonable schedule.
– Changeability (harder to evaluate)
• The proposed design results in implemented system that is “easily” modifiable (for both functional maintenance and quality maintenance.)

• Most of the “Basic” Principles are not easy to assess:
– Feasibility : even though this can end up in a binary yes/no answer, it may take a while to assess. (Often, we choose the easy way out and design what we know works.)
– Adequacy : This may not be a binary answer, but a sliding scale answer in the form of “degree” of adequacy.
•
(Number of requirements implemented) / (total requirements)
• Any other potential metric?
– Economy : Some parts of this may be easy to assess and others more difficult.
•
Effort needed
– person months
• Elapsed time – calendar days or months
• Cost – dollars expended
• Risk - ??
– Changeability : how would you gauge this?
• Modular size ?
• Amount of documentation and type of documentation?
•
Existence of external interfaces and parameterized interfaces ?
• Usage “abstract” Classes and inheritance
Does this lead us to design: a) only “doable” things
??? b) “cheapest” things that’s “barely adequate” c) lots of small functionalities that can be modified

• Design a Software which will demonstrate our Solar System for children in elementary, middle, and high schools to learn. This software should be accessible on the web. It should be able to demonstrate the following attributes:
– The complete solar system visually in one window, showing the relative distance form the Sun in the middle. For more advanced users, the relative distance from the sun will be in proper proportion.
– Sub windows may be opened to provide “detailed” information (such as size, number of moons, relative distance from sun, rotational speed, etc.) about each solar body.
– The planets may be put into static or into rotational modes.
Furthermore, for the more advance users, the planetary planes may be shown to be different.
1. Think about the high level design in terms of DeSCRIPTR : first - - - what are the main component of the software system (not physical system) ------- etc. ?
2. With just the main components --- before you go further think about the 4 Basic principles of Feasibility , Adequacy , Economy , Changeability
Now --- Does this approach affect your thinking and Designing ?

• Constructive (Construction) Design Principles are design criteria that experience has shown to lead to
“good quality” product that also satisfy the Basic
Design Principles:
1.
Modularity Principles:
• Self contained modules (via info hiding, least privilege, high cohesion and low coupling) with well defined interfaces lead to high quality product
2.
Implementability Principles :
• Designs that are “ easier” to implement (simple/reuse) leads to high quality product
3.
Aesthetic Principles (of internal design):
• “beauty” and “ease of use” are concerns that lead to designs that please other designers/implementers ---- and users
Note that these principles are nice but still not clear – “measurable?”

• Construct (via decomposition and reconstruction) the design in the form of welldefined “modules ,” which are independent (self contained) units that 1) perform specific services and 2) have clear interfaces.
• The definition of a module is not clear: (module may be a Class)
– Is it size oriented (number of parts or lines of code)?
– Is it complexity oriented (relations and dependencies)?
• Advantages of “clearly well-defined” ( less size and complexity?
) modular design :
( “easier” ≡ takes less effort ? )
– Easier to understand and explain to others
– Easier to document
– Easier to change
– Easier to test and debug
–
Easier to re-use
– Easier to improve upon for performance and other properties

• 3 sub-principles (for Modularity) are design guides:
– Principle of “Small” Modules : Design with Smaller Modules are Better
Cyclomatic # • Physical size based (small number of loc or parts)
• Mental states based (small number of binary decisions)
?
– Principle of Information Hiding : Design that Shields Internal
Details of a Module’s Structure and Processing is Better
• Shield the internal structure and processing
– Must have clearly defined interfaces that do not expose the module’s internals
– Principle of Least Privilege : Design that Does not Allow
Access to Unneeded Resources is better
• Restrict the modules from accessing unneeded resources
• A bit related to coupling (next slide)
Which of the above would you emphasize as a software engineer if you are asked to ensure software security ? ---- why?

Information Hiding Example Similar to Text (p238)
Employee name address age
. . getAge( )
Employee name address birthDate
. . getAge( )
(a)
(b)
If we want to get the age of the person, it would be nice to just evoke getAge( ) and have the age returned regardless of how the attributes of the person is set. So, we may “hide” the existence of “age” or “birthdate” attribute of Employee . We can also make the attribute “private” to bring in the principle of “least privilege” i) getAge is easy in case (a), but ---age needs to be “updated” annually ii) getAge may require a computation of [currentdate – birthdate] in (b) however ---we may need birthdate for other reason where age won’t suffice

– Control passing
– Data passing
•
•

• Content coupling (worst – high coupling)
– One module directly references the content of another module. (such as using a pointer to get to another module’s data and modifying that data.)
• Common coupling
– Two or more modules all use a common, “global” data.
– Usage of a database as a common “blackboard” for some control purpose. (This one is used very heavily in commercial applications.)
• Control coupling
– One module passes information or a parameter to control the logic of another module. (This one is often done in our design.)
• Stamp coupling
– One module passing a complete structure to another, through parameter, even though only a small part of the data structure is needed. (Passing a complete employee record when only the birthdate field is required. This also happens often in lazy design.)
• Data coupling (best – low coupling)
– Only the necessary items are passed from one module to another.

“Levels” of Cohesion
• Coincidental cohesion (worst – weakest)
–
A module that performs multiple, unrelated tasks .
• Logical cohesion
– A module that performs a “ series of related” functionalities
. (This is often done in commercial world where a module performs the insertion, deletion, and modification of records of a “master-file”)
• Temporal cohesion
– A module that performs a set of tasks that are related in time (temporal).
(This is also often done in commercial world where all the databases are “opened” at once during the beginning of a module.)
• Procedural cohesion
– A module that performs two related procedures that probably should be done separately (such as read a record from one file and based on the information go update another file.)
• Communicational cohesion
–
A module performing a sequence of related tasks on a same piece of data where the sequence of tasks is based on some specific procedure.
• Sequential cohesion
–
A module performing related sequence of tasks where an output of one is the input to the next task in sequence.
• Functional cohesion (best – strongest)
– A module that performs exactly one task to achieve a single goal .

An Excursion Into OO Class Cohesion x y z w class_a
Method_xx( )
Method_yy( )
Method_zz( ) x y z w class_b
Method_xx( )
Method_yy( )
Method_zz( )
There is not enough information to allow us to tell which class is more cohesive.
So --- we need to look at more details:
how are the attributes used by the methods?
- how do the methods interact, if any?

An Excursion Into OO Class Cohesion x y z w class_a
Method_xx( )
Method_yy( )
Method_zz( ) x y z w class_b
Method_xx( )
Method_yy( )
Method_zz( )
Method_xx uses x, y, z
Method_yy uses y, z
Method_zz uses z, w
Method_xx uses x, y
Method_yy uses y, w
Method_zz uses z
Since class_a’s methods more commonly access the attributes, class_a may be more cohesive. Let’s look at some metrics of class cohesion -----

An Excursion Into OO Class Cohesion (cont.)
• There are several ways to “measure” Class cohesion
• These 2 deal with how the attributes are “commonly” used by the methods ( similar to “communicational” level of cohesion ):
– LCOM ( Lack of Cohesion ) by Chidamber and Kemerer
LCOM = ( #P - # Q )
- where #P is the cardinality of the set of pairs of methods that have no common instance variables, and
#Q is the cardinality of the set of pairs of methods that have common instance variables
- if #P ≤ #Q, then LCOM = 0
– LCOM5 by Henderson-sellers ( a variant)
LCOM5 = [ 1
– {(∑Ua i
) / (m * A)} ]
where ∑Ua i is the number of methods that access each attribute a i
, summed over all the a i
’s,
m is the total number of methods in the class
- A is the total number of a i’ s
Note that the larger the LCOM is, the less is the Class cohesion .

An Excursion Into OO Class Cohesion x y z w
Class_a
Method_xx( )
Method_yy( )
Method_zz( )
Method_xx uses x, y, z
Method_yy uses y, z
Method_zz uses z, w
LCOM = (#P - #Q)
- There are 3!/[2!(3-2)!] = 3 pairs of methods or { (xx, yy), (yy,zz), (xx,zz) }
- #Q = cardinality of pairs that have common attribute = 3
- #P = 0
- if #P ≤ #Q, then LCOM = 0
Thus LCOM = 0; this is good because the bigger
LCOM is the less cohesive is the class.
LCOM5 = [1 ((∑Uai) / (m * A)) ]
∑Uai = 1 + 2 + 3 + 1 = 7
- m = sum of methods = 3
- A = sum of attributes = 4
LCOM5 = [ 1 – (7/12) ] = 5/12; this is also good because the closer LCOM5 is to 1, the less cohesive is the class

x y z w
Class_b
Method_xx( )
Method_yy( )
Method_zz( )
An Excursion Into OO Class Cohesion
LCOM = (#P - #Q)
- There are 3!/[2!(3-2)!] = 3 pairs of methods or { (xx, yy), (yy,zz), (xx,zz) }
- #Q = cardinality of pairs that have common attributes = 1
- #P = 2
LCOM = 2 – 1 = 1 ; this is bigger and thus worse than Class_a
Method_xx uses x, y
Method_yy uses y, w
Method_zz uses z
LCOM5 = [1 ((∑Uai) / (m * A)) ]
∑Uai = 1+ 2 + 1 + 1= 5
- m = sum of methods = 3
- A = sum of attributes = 4
LCOM5 = [ 1 – (5/12) ] = 7/12; this is larger and thus worse than Class_a

• Design small, single purpose , cohesive modules --- sounds good
• But if the whole design is composed of these, then there may be a lot of passing of control and/or data among these in order to accomplish anything significant ---causing high coupling.
Balance low coupling and high cohesion in design by thinking of :
1. Easier to understand & explain
2. Easier to document
3. Easier to change
4. Easier to test and debug
5. Easier to re-use
6. Easier to improve upon
• So we need to constantly balance between low coupling and high cohesion.
These two criteria may sometimes collide against each other.

•
– “Simpler” design are easier to understand and implement (e.g. simple in # number of steps or low cyclomatic number ?)
– Reuse the existing artifacts to save effort and time
– Design with reuse for the future.
Design with reuse often introduces more work and possibly even more complexity. --- why?
Again, design is a balancing act here, too . Design for reuse may conflict with design for only the specific and simple solution. --- thus many are NOT
Designed as such

•
•
– Simplicity
– Yet powerful (more functionalities and speed)
Simple and powerful is hard to measure and is still new. However, many
Mathematical proofs have been labeled “elegant” because they are simple and powerful ---“innovative?”

– Design to “improve the user experience ”
• matches users’ past experience and extends the experience by extrapolating and improving some part of the interaction
– Design to “delight” the users
• Matches or exceeds user expectations
• Stays within users’ knowledge and experience context
These are just as hard to measure and define as the aesthetic principles.
Yet, Steve Jobs of Apple seem to introduce new products that capture this concept.

Basic
Design Principles
Construction
Design “Criteria”
User
Oriented
Aesthetic
Feasible
Economical
Adequate Changeable
Modularity
Implementability delight small least privilege
Info hiding coupling cohesion simple reuse reusable beauty
(simple
& power)
Improve & extend experience