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%
0
