Software Engineering
week 4
Madalina Croitoru
IUT Montpellier
MADALINA CROITORU
[email protected]
Waterfall model
MADALINA CROITORU
[email protected]
The requirements document
• Specify external
behavior
• Specify
constraints on
implementation
MADALINA CROITORU
[email protected]
Requirements definition
• A high - level, customer – oriented
statement of what system is to do
• Two types of requirements:
– Functional: services the systems should
provide, how it responds to inputs, how it
behaves, what is should NOT do
– Non-functional: constraints the system should
operate under (Pentium, X RAM, Y hard disk)
MADALINA CROITORU
[email protected]
Kinds of requirements
MADALINA CROITORU
[email protected]
Waterfall model
MADALINA CROITORU
[email protected]
Software design
• Computer programs are composed of
multiple, interacting modules
• The goal of system design is to:
– Decide what the modules are
– Decide what the modules should contain
– Decide how the modules should interact
MADALINA CROITORU
[email protected]
Modules
• Autonomous
• Coherent
• Robust
MADALINA CROITORU
[email protected]
Procedural abstraction
• Procedures represent distinct logical
functions in a program:
– Display menu
– Get user option
MADALINA CROITORU
[email protected]
Programs as Functions
• X -> f -> f(x)
• The program is views as a function from a
set of legal inputs to a set of outputs
• Example: LISP
• Well suited for certain applications:
compilers etc.
• Less suited for distributed, non terminating
systems: ATMs, certain OSs
MADALINA CROITORU
[email protected]
Five criteria for
design methods
• Modular decomposability
• Modular composability
• Modular understandability
• Modular continuity
• Modular protection
MADALINA CROITORU
[email protected]
Modular decomposability
• The method supports the decomposition of
a problem into smaller sub problems which
can be solved independently
• The method is usually repetitive
• Example: top-down design methods
• Initialization modules do NOT meet this
criterion
MADALINA CROITORU
[email protected]
Modular composability
• Production of modules that may be freely
combined to produce new systems
• Directly related to the issue of reusability
• Composability usually at odds with
decomposability (top down leads to
modules with a specific function and not a
general one)
MADALINA CROITORU
[email protected]
Modular
Understandability
• Encourage the development of modules
which are easily understandable
• Counter example: GOTO
MADALINA CROITORU
[email protected]
Modular Continuity
• Leads to production of software such that
a small change in a problem specification
leads to a change in just one module
• Example: symbolic constants used
• Counter example: static arrays
MADALINA CROITORU
[email protected]
Modular Protection
• Yields architectures in which the effect of
an abnormal condition at run time, only
affects one module
• Example: validating input at source
• Counter example: int instead of short
types
MADALINA CROITORU
[email protected]
Criteria for design
MADALINA CROITORU
[email protected]
Five principles for good design
• Linguistic modular units
• Few interfaces
• Small interfaces
• Explicit interfaces
• Information hiding
MADALINA CROITORU
[email protected]
Linguistic Modular Units
• Modules must correspond to linguistic units
in the language used
• Example: Java modules and classes
• Counter Example: Subroutines in BASIC
are given a line number
MADALINA CROITORU
[email protected]
Few interfaces
• Overall number of communication
channels between modules should be as
small as possible
• For a system with n modules the minimum
is n-1 and the max is n(n-1)/2.
MADALINA CROITORU
[email protected]
Small interfaces (loose
coupling)
• If two modules communicate they should
exchange as little information possible
• Counter example: declaring all instance
variables public (why?)
MADALINA CROITORU
[email protected]
Explicit interfaces
• If modules A and B communicate this must
be obvious from the text of A or B or both
• If we change a module we need to be
able to see what other modules are
affected by these changes
MADALINA CROITORU
[email protected]
Information hiding
• All information about a module (how the
module does what it does) should be
private to the module unless it is
specifically declared otherwise
• Default Java rule: make everything private
MADALINA CROITORU
[email protected]
Reusability
• A major obstacle to the production of
cheap quality software is reusability
• Obstacles:
– Economic
– Organisational
– Psychological
MADALINA CROITORU
[email protected]
Object oriented design
• Suitable for complex systems (why?)
• We will focus on one particular OO design
approach (UML)
MADALINA CROITORU
[email protected]