Software Engineering Design Resolution

• Goal of developing a Design Resolution is to develop a design of the solution to the problem stated in the requirements.

• The Design Resolution consist of 2 main parts

1. Architectural Design2. Detailed Design

• The result of design resolution is recorded in the design document from which code implementation can be performed.

Design AnalysisSRS

DesignDoc

Design Resolution:- Architectural

- Detailed

software engineering design

Design Resolution (the Design)

• 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, interfaces3. 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

Main Parts of Software Architecture

• Define (Decomposition/Composition) the “main” components

– 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) }

– Specification of relationships among components• Specification of collaboration among components (note that

collaboration is a kind of a relationship)• Specification of interfaces among components

may loop back& modify

The Role of “Decomposition” in Design

Water Heating System (Caldera)

Water HeaterController

UserInterface

HeatingControl

ThermostatInterface

TimerInterface

Deco

mp

ositio

n

“Requirements,” “Use Cases, ““Conceptual Model”

level 0

level 2

level 1

A Decomposition - Pictorial Discussion(closer to “Application” Domain Driven Arch.)

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?

Acct-Pay

Acct-Rec.

Gen_Ledger

Post data

Post data

Identifying relationships

We still need to specify interfaces among the components and key properties

(A)

(B)

Another Decomposition - Pictorial Discussion(closer to “Software System” Domain Driven Arch.)

Financial System

UIFinancial

LogicDB

Process/Control(messages, interrupts, etc.)

Architectural Design Considerations - DeSCRIPTR

• DeSCRIPTR– ** Decomposed system into major components **

• DeSCRIPTR– States that the major components may exist in

• DeSCRIPTR– Collaboration among components to achieve a goal

• DeSCRIPTR– ** Relationships among the major components in terms of dependencies and

communications ** • DeSCRIPTR

– ** Interfaces among the components that have relationships ** • DeSCRIPTR

– ** Properties that the major components must possess or satisfy **• DeSCRIPTR

– Transitions of components’ states• DeSCRIPTR

– ** 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 Considerations• 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 element2. Algorithms that need to used to implement the

services/functionalities3. Implementation specifications for the packaged components,

including language specific concerns4. Data structures and data types needed for the

implementation

A bit early?

Are There Design Principles ( Guidelines)?

Design Principles

Feasible

Adequate

Economical

Changeable

1) Basic2) ConstructionDesign “Criteria”

3) UserOriented

small

Modularity

Info hiding

leastprivilege

simple

cohesion

coupling

reuse

reusable

Aesthetic

“Beauty” indesign(simple& powerful)

delight

Improve &extendexperience

Implementability

(1) Some “Basic” Design Principles• 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.)

Some Observations about Basic Design Principles

• 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

Back to “Solar System”• 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 ?

(2) Construction-Design “Criteria”

• 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?”

Modularity in Design• Construct (via decomposition and reconstruction) the design in the

form of well-defined “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

Modularity Principles

• 3 sub-principles (for Modularity) are design guides:

– Principle of “Small” Modules: Design with Smaller Modules are Better

• 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 areasked to ensure software security? ---- why?

Cyclomatic # ?

Information Hiding Example Similar to Text (p238)

EmployeeEmployee

nameaddressage. .

getAge( )

nameaddressbirthDate. .

getAge( )

If we want to get the age of the person, it would be niceto just evoke getAge( ) and have the age returned regardlessof how the attributes of the person is set. So, we may “hide” theexistence of “age” or “birthdate” attribute of Employee. We can also

makethe attribute “private” to bring in the principle of “least privilege”

i) getAge is easy in case (a), but ---- age needs to be “updated” annuallyii) getAge may require a computation of [currentdate – birthdate] in (b) however ---- we may need birthdate for other reason where age won’t suffice

(a) (b)

Low Coupling and High Cohesion

• Coupling is the degree of connectedness among modules:– Control passing– Data passing

• Coupling should be kept to minimum – low coupling in design

• Cohesion is the degree of relatedness of the parts within a module

• Cohesion should be maximized --- high cohesion in design

Levels of Coupling• 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 birth-date 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

class_a class_b

xyzw

Method_xx( )Method_yy( )Method_zz( )

xyzw

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

class_a class_b

xyzw

Method_xx( )Method_yy( )Method_zz( )

xyzw

Method_xx( )Method_yy( )Method_zz( )

Method_xx uses x, y, zMethod_yy uses y, zMethod_zz uses z, w

Method_xx uses x, yMethod_yy uses y, wMethod_zz uses z

Since class_a’s methods more commonly access the attributes, class_amay 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 – {(∑Uai) / (m * A)} ]

- where ∑Uai is the number of methods that access

each attribute ai, summed over all the ai’s,

- m is the total number of methods in the class

- A is the total number of ai’sNote that the larger the LCOM is, the less is the Class cohesion.

An Excursion Into OO Class Cohesion

Class_a

Method_xx( )Method_yy( )Method_zz( )

xyzw

Method_xx uses x, y, zMethod_yy uses y, zMethod_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

An Excursion Into OO Class Cohesion

Class_b

xyzw

Method_xx( )Method_yy( )Method_zz( )

Method_xx uses x, yMethod_yy uses y, wMethod_zz uses z

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

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

Balancing the Design

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

• So we need to constantly balance between low coupling and high cohesion. These two criteria may sometimes collide against each other.

Balance low coupling and highcohesion in design by thinkingof : 1. Easier to understand & explain2. Easier to document3. Easier to change 4. Easier to test and debug5. Easier to re-use6. Easier to improve upon

Implementability Principles

• Once we have an implementable design, it is still important to address how easy is it to implement:

– “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 conflictwith design for only the specific and simple solution. --- thus many are NOT Designed as such

Aesthetic (Design) Principles

• A design is better because it is more “pleasing to the mind” (or beautiful).

• Gelernter of Yale states that beauty is:

– Simplicity – Yet powerful (more functionalities and speed)

Simple and powerful is hard to measure and is still new. However, manyMathematical proofs have been labeled “elegant” because they are simpleand powerful ---- “innovative?”

Other Principles

(3) User Oriented Design:

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

Summarizing Design Principles

Design Principles

Feasible

Adequate

Economical

Changeable

BasicUserOriented

small

Modularity

Info hiding

leastprivilege

simple

cohesion

coupling

reuse

reusable

Aesthetic

beauty(simple& power)

delight

Improve &extendexperience

Implementability

ConstructionDesign “Criteria”