1. N. Kokash, Software Engineering
Natallia Kokash
Note that the book is misleadingly simple.
Just reading the book is like learning to swim without getting wet.
N. Kokash, Software Engineering

2. Agenda Software Architecture Software Design Definition
Architecture Design
Viewpoints and view models
Architectural styles
Architecture assessment
Software Design
Principles
Methods
N. Kokash, Software Engineering

3. Programmer’s approach to SD
Skip RE and design
Start writing code
Design is a waste of time
We need to show something to the customer
We are judged by the amount of LOC/month
We know that the schedule is too tight…
How is this different from eXtreme Programming?
Another view:
The longer you postpone coding, the sooner you will finish!
N. Kokash, Software Engineering

4. Design principles Abstraction Modularity, coupling and cohesion
Information hiding
Limited complexity
Hierarchical structure
N. Kokash, Software Engineering

5. Abstraction Procedural abstraction: Data abstraction:
Natural consequence of stepwise refinement: name of procedure denotes sequence of actions
Data abstraction:
Aimed at finding a hierarchy in the data
N. Kokash, Software Engineering

6. Coupling and cohesion Cohesion: the glue that keeps a module together
Structural criteria which tell us something about individual modules and their interconnections
Cohesion: the glue that keeps a module together
Coupling: the strength of the connection between modules
N. Kokash, Software Engineering

7. Cohesion types
Coincidental (worst): arbitrarily parts (e.g., utiility classes)
Logical: parts of a module logically are categorized to do the same thing.
Temporal: parts of a module are processed together (e.g., after catching an exception).
Procedural: parts of a module always follow a certain sequence of execution (e.g. check file permission).
Communicational: parts of a module operate on the same data.
Sequential: the output from one part is the input to another part.
Functional (best): parts of a module contribute to a single well-defined task (e.g. tokenizing a string of XML).
N. Kokash, Software Engineering

8. How to determine the cohesion type?
Describe the purpose of the module in one sentence
If the sentence is compound, contains a comma or more than one verb  it probably has more than one function: logical or communicational cohesion
If the verb is not followed by a specific object  probably logical cohesion (example: edit all data)
If the sentence contains time-related words like “first”, “then”, “after”  temporal cohesion
Words like “startup”, “initialize” imply temporal cohesion
N. Kokash, Software Engineering

9. Coupling types
Content: a module depends on the internal working of another module
Common: two modules share the same global data
External: modules share an externally imposed data format, or communication protocol
Control: one module controls the flow of another, by passing it information on what to do
Stamp: modules share a composite data structure and use only part of it
Data: modules share data through, e.g., through parameters.
Message: Component communicate via message passing
N. Kokash, Software Engineering

10. Strong cohesion + weak coupling
Simple interface
Simpler communication
Simpler correctness proofs
Changes influence other modules less often
Reusability increases
Comprehensibility improves
N. Kokash, Software Engineering

11. Information hiding Each module has a secret
Design involves a series of decision
For each such decision, wonder who needs to know and who can be kept in the dark
Information hiding is related to:
Abstraction: if you hide something, the user may abstract from that fact
Coupling: the secret decreases coupling between a module and its environment
Cohesion: the secret is what binds the parts of the module together
N. Kokash, Software Engineering

12. Complexity
Measure certain aspects of the software (lines of code, # of if-statements, depth of nesting, …)
Use these numbers as a criterion to assess a design, or to guide the design
Higher value  higher complexity  more effort required (= worse design)
Two kinds:
intra-modular: inside one module
inter-modular: between modules
N. Kokash, Software Engineering

13. Size-based complexity measures
Counting lines of code
Differences in verbosity
Differences between programming languages
a:= b versus while p^ <> nil do p:= p^
Halstead’s “software science”, essentially counting operators and operands:
n1: number of unique operators
n2: number of unique operands
N1: total number of operators
N2: total number of operands
N. Kokash, Software Engineering

14. Example public static void sort(int x []) {
for (int i=0; i < x.length-1; i++) {
for (int j=i+1; j < x.length; j++) {
if (x[i] > x[j]) {
int save=x[i];
x[i]=x[j]; x[j]=save }
operator, 1 occurrence
operand, 2 occurrences
operand, 2 occurrences
operator, 2 occurrences
N. Kokash, Software Engineering

15. Other computer science formulas
Size of vocabulary: n = n1 + n2
Program length: N = N1 + N2
Volume: V = N log2n
Level of abstraction: L = V*/ V
Approximation: L’ = (2/n1)(n2/N2)
Programming effort: E = V/L
Estimated programming time: T ’ = E/18
Estimate of N: N ’ = n1log2n2 : n2log2n2
For this example: N = 68, N ’ = 89, L = .015, L’ = .028
N. Kokash, Software Engineering

16. More complex metrics Intra-modular: Inter-modular:
Structure-based (e.g., McCabe’s cyclomatic complexity:
number of edges - number of nodes + number of connected components + 1)
Inter-modular:
Based on “uses” relation (call graph)
Tree impurity (for a graph with n nodes and e edges: m(G) = 2(e-n+1)/(n-1)(n-2)
Information flow metric (e.g., Shepperd’s variant )
N. Kokash, Software Engineering

17. Object-oriented metrics
WMC: Weighted Methods per Class
DIT: Depth of Inheritance Tree
NOC: Number Of Children
CBO: Coupling Between Object Classes
RFC: Response For a Class
LCOM: Lack of COhesion of a Method
More in the lectures on software quality (lecture 5) and cost estimation (lecture 11)
N. Kokash, Software Engineering

18. Design methods Functional decomposition Data flow design (SA/SD)
Design based on data structures (JSD/JSP)
Object-oriented design
N. Kokash, Software Engineering

19. Functional decomposition
Extremes: bottom-up and top-down
Not used as such; design is not purely rational:
clients do not know what they want
changes influence earlier decisions
people make errors
projects do not start from scratch
Rather, design has a yo-yo character
We can only fake a rational design process
N. Kokash, Software Engineering

20. Data flow design Yourdon and Constantine (early 70s)
Nowadays version: two-step process:
Structured Analysis (SA), resulting in a logical design, drawn as a set of data flow diagrams
Structured Design (SD) transforming the logical design into a program structure drawn as a set of structure charts
Do you remember Data Flow Diagrams (DFDs)?
N. Kokash, Software Engineering

21. Data flow design Top-level DFD: context view First-level decomposition
Second-level decomposition …
direction
library
system
request
management
client
report
ack’ment
N. Kokash, Software Engineering

22. First-level decomposition
Borrow
title
Prelim
doc
client
catalog adm.
management
log file
request
log data
return
borrow
acknowledgement
report
direction
N. Kokash, Software Engineering

23. Second-level decomposition
Check
client
data
log file
log data
Process
request
data base
return
borrow
not OK OK
client info
N. Kokash, Software Engineering

24. Example minispec Identification: Process request Description:
Enter type of request
1.1 If invalid, issue warning and repeat step 1
1.2 If step 1 repeated 5 times, terminate transaction
Enter book identification
2.1 If invalid, issue warning and repeat step 2
2.2 If step 2 repeated 5 times, terminate transaction
Log client identification, request type and book identification
...
N. Kokash, Software Engineering

25. Data dictionary entries
borrow-request = client-id + book-id return-request = client-id + book-id log-data = client-id + [borrow | return] + book-id book-id = author-name + title + (isbn) + [proc | series | other] Conventions: [ ] - include one of the enclosed options | - separates options + - AND () - enclosed items are optional
N. Kokash, Software Engineering

26. From data flow diagrams to structure charts
Result of SA: logical model, consisting f a set of DFD’s, augmented by minispecs and data dictionary
Structured Design = transition from DFD’s to structure charts
Heuristics for this transition are based on notions of coupling and cohesion
Major heuristic concerns choice for top-level structure chart, most often: transform-centered
N. Kokash, Software Engineering

27. Transform-centered designB D E F G C H K
Do job A C B G F E D K H
N. Kokash, Software Engineering

28. Design based on data structures
Jackson Structured Programming (JSP)
for programming-in-the-small
Jackson Structured Design (JSD)
for programming-in-the-large
Michael Anthony Jackson (born 1936) is a British computer scientist
N. Kokash, Software Engineering

29. JSP
Basic idea: good program reflects structure of its input and output
Program can be derived almost mechanically from a description of the input and output
Input and output are depicted in a structure diagram and/or in structured text/schematic logic (pseudocode) A B C D
sequence
B *
iteration
B o
C o
D o A
selection A
N. Kokash, Software Engineering

30. JSP Example
N. Kokash, Software Engineering

31. JSP Example
N. Kokash, Software Engineering

32. The same without JSP
N. Kokash, Software Engineering

33. Fundamental issues in JSP
Model input and output using structure diagrams
Merge diagrams to create program structure
Meanwhile, resolve structure clashes
Clash = there is no obvious correspondence between the input and output structures
Optimize results through program inversion
Design simple programs using JSP and then invert one (or more) programs to optimize the design.
N. Kokash, Software Engineering

34. Program inversion
N. Kokash, Software Engineering

35. Differences between JSP and other methods
Functional decomposition, data flow design:
Problem structure  functional structure  program structure
JSP:
Problem structure  data structure  program structure
N. Kokash, Software Engineering

36. Jackson Structured Design (JSD)
Problem with JSP: how to obtain a mapping from the problem structure to the data structure?
JSD tries to fill this gap
JSD has three stages:
modeling stage: description of real world problem in terms of entities and actions
network stage: model system as a network of communicating processes
implementation stage: transform network into a sequential design
N. Kokash, Software Engineering

37. JSD modeling stage JSD models the UoD as a set of entities
For each entity, a process is created which models the life cycle of that entity
This life cycle is depicted as a process structure diagram (PSD)
PSD’s are finite state diagrams:
the roles of nodes and edges has been reversed
the nodes denote transitions while the edges denote states
N. Kokash, Software Engineering

38. Object-oriented design principles
Three major steps:
Identify the objects
Determine their attributes and services
Determine the relationships between objects
OO as middle-out design
First set of objects becomes middle level
To implement these, lower-level objects are required
A control/workflow set of objects constitutes the top level
N. Kokash, Software Engineering

39. Carefully consider candidate list
Eliminate implementation constructs, such as “software”
Replace or eliminate vague terms:
“system”  “computer”
Equate synonymous terms:
“customer” and “client”  “client”
Eliminate operation names, if possible (such as “transaction”)
Be careful in what you really mean
Can a client be a library employee? Is it “book copy” rather than “book”?
Eliminate individual objects (as opposed to classes)
“book’s code”  attribute of “book copy”
N. Kokash, Software Engineering

40. Identify relationships
From the problem statement:
employee operates station
station has bar code reader
bar code reader reads book copy
bar code reader reads identification card
Tacit knowledge:
library owns computer
library owns stations
computer communicates with station
library employs employee
client is member of library
client has identification card
N. Kokash, Software Engineering

41. Result: Initial class diagram
N. Kokash, Software Engineering

42. Object-oriented design methods
Booch: early, new and rich set of notations
Fusion: more emphasis on process
RUP: full life cycle model associated with UML
N. Kokash, Software Engineering

43. Booch’ method Identify classes and objects
Identify semantics of classes and objects
Identify relationships between classes and objects
Identify interface and implementation
of classes and objects
N. Kokash, Software Engineering

44. Fusion Analysis object model interface model Design object interaction
graphs
visibility graphs
class descriptions
inheritance graphs
N. Kokash, Software Engineering

45. RUP Four phases: inception, elaboration, construction, transition
Analysis and design workflow:
First iteration: architecture
Next, analyze behavior:
from use cases to set of design elements
produces black-box model of the solution
Finally, design components:
refine elements into classes, interfaces, etc.
N. Kokash, Software Engineering

46. Classification of design methods
Orientation dimension:
Problem-oriented: understand problem and its solution
Product-oriented: correct transformation from specification to implementation
Product/model dimension:
Conceptual: descriptive models
Formal: prescriptive models
Problem-oriented techniques focus on getting a better understanding of problems and solutions. They are human-centered They describe, communicate, document solutions.
Product-centered approaches focus n correct transformation.
Conceptual models describe an external reality, the UoD. They are checked through validation.
Formal models describe the behavior of the system to be developed. They are verified.
N. Kokash, Software Engineering
© SE, Design, Hans van Vliet

47. Classification of design methods
problem-oriented
product-oriented
Understand the problem
Transform to implementation I
ER modeling
Structured analysis II
Structured design
conceptual
III
JSD
VDM IV
Functional decomposition
JSP
formal
Represent properties
Create implementation units
N. Kokash, Software Engineering

48. Caveats when choosing a particular design method
Familiarity with the problem domain
Designer’s experience
Available tools
Development philosophy
N. Kokash, Software Engineering

49. Design pattern Provides solution to a recurring problem
Balances set of opposing forces
Documents well-prove design experience
Abstraction above the level of a single component
Provides common vocabulary and understanding
Are a means of documentation
Supports construction of software with defined properties
N. Kokash, Software Engineering

50. Example design pattern: Proxy
Context:
Client needs services from other component, direct access may not be the best approach
Problem:
We do not want hard-code access
Solution:
Communication via a representative, the Proxy
N. Kokash, Software Engineering

51. Example design pattern: Command Processor
Context:
User interface that must be flexible or provides functionality beyond handling of user functions
Problem:
Well-structured solution for mapping interface to internal functionality. All ‘extras’ are separate from the interface
Solution:
A separate component, the Command Processor, takes care of all commands
Actual execution of the command is delegated
N. Kokash, Software Engineering

52. Anti-patterns Patterns describe desirable behavior
Anti-patterns describe situations one had better avoid
In agile approaches (XP), refactoring is applied whenever an anti-pattern has been introduced
N. Kokash, Software Engineering

53. Example antipatterns God class: class that holds most responsibilities
Lava flow: dead code
Poltergeist: class with few responsibilities and a short life
Golden Hammer: solution that does not fit the problem
Stovepipe: (almost) identical solutions at different places
Swiss Army Knife: excessively complex class interface
N. Kokash, Software Engineering

54. SUMMARY Essence of the design process: decompose system into parts
Desirable properties of a decomposition:
coupling/cohesion, information hiding, (layers of) abstraction
There have been many attempts to express these properties in numbers
Design methods:
functional decomposition, data flow design, data structure design, object-oriented design
N. Kokash, Software Engineering

55. Homework Read chapter 12 Design the Image2UML system
Use a UML design tool and deliver your design sufficiently documented in a PDF file. The document to be delivered should at least consist of a class diagram, a sequence diagram, an activity diagram and a state chart diagram.
N. Kokash, Software Engineering

56. Software Engineering (3rd Ed.)
1. Introduction
2. Introduction to Software Engineering Management
3. The Software Life Cycle Revisited
4. Configuration Management
5. People Management and Team Organization
6. On Managing Software Quality
7. Cost Estimation
8. Project Planning and Control
9. Requirements Engineering
10. Modeling
11. Software Architecture
12. Software Design
13. Software Testing
14. Software Maintenance
17. Software Reusability
18. Component-Based Software Engineering
19. Service Orientation
20. Global Software Development
N. Kokash, Software Engineering