Chapter 6
Designing the Modules
CSCI 3428: Software Engineering
Tami Meredith
Design
 Not really any boundary between architecture and




module-level design
Generally done by senior developers
Refactoring is often done when a design becomes overly
complex
Opportunistic – both top-down (analysis) and bottomup (synthesis) is used
Tends to increase in importance with the size of the
project
Faking the Process (Parnas & Clements, 1986)
 Applies to more than just design
 We know that changes, unknowns, and other factors require
an iterative approach
 But, if we TRY to follow a defined process:
1) It can provide guidance when we are unsure
2) It can help us get closer to a better result
3) It is easier to measure progress
 Thus, even though we know we can't apply any process
perfectly, we should try our best to do so
 Can use placeholders (ToDo's), Refactoring as necessary
Principles
1.
2.
3.
4.
5.
6.
Modularity
Interfaces
Information hiding
Incremental development
Abstraction
Generality
Modularity
 We want to achieve Separation of Concerns
 A module is any programming unit, e.g., library, package,
class, ADT, module, file
 Modules should have a single, clearly defined, purpose
 Measure modularity using
 coupling: amount of interconnection and dependence between
modules
 cohesion: amount of interconnection and dependence between
elements of a single module
Coupling
 Strive for LOOSE coupling
 Minimise the dependencies and interconnections between
modules
1. Uncoupled: Modules are unrelated [LEAST]
2. Data Coupling: Pass simple (primitive) data
3. Stamp Coupling: Pass complex data structures
4. Control Coupling: One module influences the behaviour
(i.e., control flow) of another
5. Common Coupling: Shared (common) data
6. Content Coupling: Module modifies another [MOST]
Cohesion




Strive for TIGHT cohesion
Want a module's components to be related and relevant to the module
Informational: Functional cohesion + data abstraction [MOST]
Functional:
1.
2.
All elements of a single behaviour are in the same module
All of the elements are essential for that behaviour
 Communicational: Functions get/send/manage the same data (e.g., both




read same sensor)
Procedural: Functions show an execution sequence
Temporal: Functions execute at the same time (e.g., all the set-up code
for a program)
Logical: Use the same code differently
Coincidental: Functions not related [LEAST]
Interfaces
 Defines the services offered by the module
 Usually provides the definitions in terms of (type) signatures
for access functions
 Try to keep as small as possible
 Is the basis of the Design by Contract approach
 Specification describes the externally visible properties
1.
2.
3.
4.
5.
Purpose (general description)
Preconditions (assumptions)
Protocols (usage restrictions etc.)
Postconditions (all external effects)
Quality attributes (performance etc.)
Information Hiding
 Design decisions are hidden – i.e., module can be rewritten




without changing interface
Structuring using ADTs
Minimises coupling
Increases cohesion
Strive for self-containment
Incremental Development
 Recursive cycles can require large amounts of code to be




produced before testing
Techniques such as sandwiching or dependency inversion can be
used to break cycles but lead to more complex design
Incremental development leads to higher programmer
morale
Aim to get a working product ASAP and keep it working as
its improved and/or extended
Gives us something we can show customer
Abstraction
 We tend to break the system into a hierarchy of increasingly
detailed abstractions
 Designs generally should support abstraction
 Somewhat like layered architecture, but smaller scale
Generality
 Try to make each module as general as possible to improve




reuse
E.g., a sort that works on any data type
Can lead to gold-plating
Helped by polymorphism
How:
Parameterise context-specific information
2. Remove preconditions
3. Simplify postconditions (simpler parts)
1.
6.3 Objects
 Inheritance = implementation inheritance which need NOT





be linked to sub-type hierarchy
Polymorphism = inclusion (subtype) polymorphism which is
NOT parametric polymorphism (or ad-hoc polymorphism)
ADTs do not need objects to implement
OO Implementations are slower at runtime because of the
need for runtime type information to resolve over-riding
Can add unneeded complexity to designs
Works best for simulations
Using UML
Requirements:
1)

Use-Case diagrams, Activity diagrams
Architecture:
2)

Component diagrams, Deployment diagrams
Design:
3)




Sequence diagrams, Communication diagrams
Class, Object, & Package diagrams
Activity diagrams
State diagrams
UML in Action
 Useful for formal settings
 Not usually done by entry-level programmers
 Generally linked to OO Implementations
 Good support for some Transformational development
model
 Considered a specialised type of software engineering (OO
SE)
 Not as general-purpose as some advocates suggest
 Did not solve the "Software Crisis"
5 Surveys
Famous Moments in Software Engineering
Robbins-Gioia (2001)
1.





Implementation of ERP (Enterprise Resource Planning) Package
232 Respondents: 36% had or were impl. ERP
51%: ERP Unsuccessful
46%: Did not think org. knew how to use it
56%: Had a program mgmt office in place (and of these 36%
considered the ERP unsuccessful)
KPMG Canada (1997)
2.




1450 Leading Public/Private Organisations (176 responses)
25 billion (CAD) spent
61% considered projects to have failed
75%+ blew schedule by 30% or more
3.
Conference Board Survey (2001)
 117 Companies that attempted ERP
 34% Very satisfied, 58% Somewhat satisfied, 8% Unhappy
 40% Failed to achieve business goals in 1 year
 For those who achieved goals, took 6 months longer than expected
 25% over budget, Support costs 20% too low
4.
Chaos Report (1995)
 31% of projects cancelled before they are finished
 52% of projects will cost over 189% of estimate
 81 billion USD spent on 80K cancelled projects (1995)
 16.2% completed on time and on budget (but only 9% for large
companies)
 Only 42% of the proposed features implemented (large companies)
and 74% (small companies)
 48% of IT executives believe the failure rate is rising
5.
OASIG (1995)
 45 Expert consultants/professors
 20 years avg. experience (900 total)
 14k projects considered
 7 out of 10 IT projects fail in some way
 Success rate < 30%