1. Some Analysis and Issues Concerning Design
Levels of Abstraction and modularity
Collaborative and Multi-site Design
UI Design and Internationalization
Concurrency and synchronization
Performance
Consistency
Completeness
Structural Complexity – McCabe’s cyclomatic #
Some “Good” Characteristics of Designs 1

2. Levels of Abstraction & Modularity
In Abstraction:
pick out the essentials
pick out the unique differentiators
hide the details
We must also Synthesize at each level of (possible multi-levels of) abstraction
One possible result is the design of a “CLASS” 2

3. Abstraction , Synthesis, Information Hiding
How do we do this ? (where creativity comes in !)
Look at the requirements and aggregate similar ones for solution
Look at the requirements and identify unique Objects and consider them as the first level of abstraction
Look at relationship among requirements and see if there is implications to design (solution):
sequence and concurrency
natural points of break-up
input, process, output
present choice, input, process 1, process 2, ---, process n, output
Look at the solutions and combine the similar ones
“common” data into a single table
“common” functionality into a single module
what information needs to be “separated and hidden”
Look at some of the key problems and identify those as needing special algorithms or those that should be separated out for detailed design at the next lower level 3

4. Collaboration and Multi-site Design
Problems are more complex today and requires multiple sets of expertise to come up with a Solution:
network
database
application domain specialist
development platform and programming language experts
general architecture
UI experts
testing and quality control
Solutions are often put together by a “team” of people, not necessarily always at one common physical site due to better technology and global economy. 4

5. Collaborative Design Some major problems encountered:
communications
different background and culture
different physical locations and time zones
asynchronous mode of internet .vs. synchronous telephone or face-to-face meetings
different tools and need specific group-ware or configuration management tool to aid in project control
different development process assumptions and experiences
Some positive actions and experiences:
requirements analysis and high level design performed by a small group at a common physical site (cost money but worth it)
regular “synchronous” meetings (with advanced tools such as the tools for on-line meeting)
use a common group-ware tool
well defined process with clear, specific milestone artifacts 5

6. UI Design
While there are lots of new tools for prototyping the UI, it still needs to be designed:
navigation paradigm : application domain specific, general internet (e.g. “left margin” choices), Cognitive Science’s Miller’s 7+ or – 2, etc.
metaphor : domain specific, country specific, etc. (e.g. calendar vs 2-D table vs labeled fields for a “personal time manager”)
looks : buttons; sliders; drop down choices; dials; fill in fields; etc.
international considerations:
field size (long names for international )
representation (e.g. mm/dd/yy ; xxx, xxx. yy in USA )
audio, video, and graphical preferences
modality : screen display, printed text, printed pictures, etc.
Give “Control” to the User  let the user choose
(not too many choices) 6

7. Concurrency and Synchronization
Human minds process in sequential mode but many of our system solutions include parallel and concurrent processes:
contention for resources
security of shared resource and authority of access
synchronization of processes : synch points
non-determinant versus parallel processes
These issues all have some solutions:
monitors for contention of and access of shared resources along with database locks
multi-threading for parallel and concurrent processes in programming languages 7

8. Performance
Performance in terms of speed or capacity is one of the more difficult to design:
Increase raw resources of hardware memory, storage, CPU speed, network capacity ---consider at design time
Specify queue size, file size, table size, etc. at design time
Describe basic processing algorithms’ speed of search, sort, etc. at design time
analyze requirements and set up primary search keys at design time
Sometimes we will need to compromise and create “branches” that adds complexity or bypasses normal processing (e.g. skip layers in layered design)

9. Consistency Consistency of Design: terminology across the system:
display screens
reports
database
processing (e.g. copy, paste, delete, etc.)
common handling of :
help
messages (error, warning, information, etc.)
failure detection and amount of diagnostics
recovery from failure or exceptions: “retry” - “correct’ - “report”
navigational style

10. Completeness Completeness of Design: * * * . * . * . . * . * . * .
Each requirement has an associated design component(s)
Each design components has an associated requirement(s) * * * . * . . * . .
Design
Requirements * . * * . * .
Design
Requirements

11. A “complexity” measure: Cyclomatic number
Cyclomatic complexity = E - N + 2p
where E = number of edges
N= number of nodes
p = number of connected
regions (usually 1)
So, for this control flow :
7 edges – 6 nodes + 2 = 3 n1 e1 e2 e3 n2 e4
Region 1 e5 n4 n3
Region 2 n5 e7
Cyclomatic complexity number can also
be computed as follows:
- number of binary decision +1
- number of closed regions + 1 e6 n6
T.J. McCabe’s Cyclomatic complexity metric is based on the belief that design/program quality is related to the complexity of the design or program “control flow”.

12. Some Characteristics of Good Design
Strong Cohesion (relatedness within)
Fan-in and Fan-out (# of coupling)
Loose Coupling (cross inter-dependence)

13. Cohesion The concept of cohesion deals with:
“degree of connectedness or relatedness” within the component
degree of bounding or unison within the component
A component design is considered better the more functionally cohesive that component is “internally”
clear focus on a problem
solution is targeted and thus simpler to construct, simpler to understand, and simpler to extend or modify
Object Oriented Technology with its combination of data and functions combined within an object is a “natural” for cohesion, assuming the choice of Class definition was good.

14. Degree or Levels of Functional Cohesion
There are 7 levels (or degrees) of functional cohesion as follows from lowest to the highest: (highest being the “best” but NO clear “numerical” metric)
1. Coincidental
2. Logical
3. Temporal
4. Procedural
5. Communicational
6. Informational or Sequential
7. Functional

15. Degrees of Cohesion
1. Coincidental is the lowest and the parts within the component are unrelated to one another. The only reasons that the parts are even found in the same component is due to convenience or accident.
2. Logical is the next higher where several logically related actions are placed in the same component. These actions may be logically related, but not process-function related.
(e.g. one input routine for all unrelated functions or data.)

16. Degrees of Cohesion
3. Temporal is the performing of all actions for temporary timing reason.
(e.g. perform all initialization of all, possibly unrelated, data at the beginning or perform all error detection at one place in the end.)
4. Procedural is the grouping of actions within a component because of some “procedural” sequence (like the sequential cohesion but output of one does not necessarily follows as input to the next)
(e.g. read a data record from database and update a related but different record because of the business process.)

17. examples of “Logical” and “Temporal” degrees of Cohesion
Temporal Cohesion
(timing)
Logical Cohesion
Read Web
inputs
Process
Inputs
Perform all
initializations “first”
Process all
imports
Read all
transactions
Perform
business
processing
Perform all
business
processing
Display
query responses
Perform all
updates to
DB “last”
Output all
acknowledg
Process
outputs
Output
error mess.

18. Degrees of Cohesion
5. Communicational is the case where possibly unrelated actions are taken on the same data or unrelated data are fetched together from a common file.
(e.g. using a primary search key and get employee data necessary for payroll processing but also get additional employee data such as employee educational information for some other processing which will come later.)
6. Informational or Sequential is the situation where a number of related actions are performed based on output of one as input to another.
(e.g. initialize a record and then process the record)

19. Examples of “Procedural” and “Communicational” degrees of Cohesion
Communicational Cohesion
Procedural Cohesion
Business-flow 1
Business-flow n
Request
business input
Request input
Request input
Validate all input
& process error
Validate input
Validate input
Process normal
business
Process normal
business
Process normal
business
Common Read error
table & process
errors
Very much like your
web screen to process
to db in one component

20. Example of “Sequential” degree of Cohesion and “Functional” degree
Sequential Cohesion
Create a Team
Assign Team Name
Assign Team
Members &
Update member
Functional Cohesion
Team Function
- create team ( )
-name team ( )
-delete team( )
-add member( )
-update member( )
How much of this is
really “single” purpose?

21. Degrees of Cohesion
7. Functional is the highest degree of cohesion where all the actions are directed towards one goal. The functional component achieves a single purpose.
This top level of functional cohesion was thought to also provide high reusability of that component for all similar requirements.
Because data can still change dramatically, it was not until object technology with inheritance came along even the functional cohesive module was still limited in reuse.

22. Fan-in and Fan-out
An assessment of characteristics of good high level design is the measure of Fan-in and Fan-out
Fan in of a component is the number of flows into a component (number of modules calling this module) and the number of global data structure accessed by the module.
Component with
multiple Fan-ins
Note : Fan-in is sometimes known as Afferent Coupling --- e.g. db interface called by many

23. Fan-in and Fan-out
Fan-out of a component is the number of flows out of a component (number of modules this module calls) and the number of global data structures updated by the module.
Component with
multiple
fan-outs
Note : Fan-out is sometimes known as Efferent Coupling

24. Henry-Kafura (Fan-in and Fan-out)
Henry and Kafura metric measures the inter-modular flow, which includes:
Parameter passing
Global variable access
inputs
outputs
Fan-in : number of inter-modular flow into a program
Fan-out: number of inter-modular flow out of a program
Module, P
non-linear
Module’s Complexity, Cp = ( fan-in x fan-out )2
for the “picture” above: Cp = (3 x 1)2 = 9

25. Measure of Fan-in & Fan-out
There are several formulae relating the number of fan-ins and fan-outs of the components of a design to the complexity of a design.
It is also believed that generally a component with high number of fan-outs may be a concern.
A component with high number of fan-outs needs to account for more parameter passing, more data structures, more control transfers. Therefore it may be more complex and also requires more testing.
But a component with high number of fan-ins can still be quite self containing. It is not any more complex just because of the number of fan-ins, and it also gets tested more as the multiple fan-in components are tested.

26. Coupling
The concept of Coupling deals with the degree of “inter-dependence” of components. The inter-dependence may be :
asynchronous passing of controls
synchronous passing of controls
passing of data between components
combination of passing controls and data with further embedded semantics
It is believed that a design is better the “looser” or lesser the coupling is among its components.

27. Degree or Levels of Coupling
There are 6 levels of coupling as follows (the lowest or the second lowest being the best) :
6. Content coupling
5. Common coupling
4. Control coupling
3. Stamp coupling
2. Data coupling
1. Uncoupled

28. Degrees of coupling
6. Content coupling is the least desirable in that one component directly references or has access to the contents of another component.
(e.g. a pointer is passed from one component to another where the pointer may be used to change the content of another component. Also unintended incrementing of the pointer may get to unanticipated areas and cause the MS’s famous “gpf”.)
5. Common coupling is the case where a common global data is used.
(e.g. the common repository design style is a case where all the communicating modules depend on the status and integrity of a common data.)

29. Degree of Coupling
Control coupling is the situation where one component passes a data to another but the data has embedded semantics that controls the processing of the receiving component.
(e.g. Component A passes a parameter, x, with value 1, from set of {1, 2, 3} values where 1 means “I can not complete my processing --- and you should issue error message x in French.”)
Stamp coupling is the passing of the complete data structure when only some the data element is needed.
(e.g. passing of a personnel record of a person as opposed to just the needed data fields such as name and birthdate of the person causing the receiving component to possibly access the “wrong” fields.)

30. Degree of Coupling
Data coupling is the case where only the necessary information is passed from one component to another. This is the most desirable coupling if there must be some coupling which almost all system must have.
Uncoupled is the case where there is no coupling at all. Very unlikely situation for any medium to large systems.

31. Coupling
Coupling addresses the attribute of “degree of interdependence” between software units, modules or components.
Content Coupling
Accessing the internal data or procedural information
Data coupling is
coupling where
Levels of
lowest
Common Coupling
Lower the better
Control Coupling
Stamp Coupling
Data Coupling
Passing only the necessary information
No Coupling
Ideal, but not practical

32. where Functional is the
Cohesion
Cohesion of a unit, of a module, of an object, or a component addresses the attribute of “degree of relatedness” within that unit, module, object, or component.
Functional
Performing 1 single function
where Functional is the
Levels of Cohesion
“highest”
Sequential
Communicational
Higher the better
Procedural
Temporal
Logical
Performing more than 1
unrelated functions
Coincidental

33. “Good” Design: a) Strong-Cohesion & b) Loose-Coupling
High Level
Tight
Strong
Cohesion
Coupling
Weak
Loose
Low Level
“Good” Design: a) Strong-Cohesion & b) Loose-Coupling