MADALINA CROITORU [email protected] Software Engineering week 4 Madalina Croitoru IUT Montpellier.

MADALINA [email protected]

Software Engineeringweek 4

Madalina CroitoruIUT Montpellier


Waterfall model

The requirements document

• Specify external behavior

• Specify constraints on implementation


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)


Kinds of requirements



Waterfall model

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


Modules

• Autonomous

• Coherent

• Robust


Procedural abstraction

• Procedures represent distinct logical functions in a program:– Display menu– Get user option


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


Five criteria for design methods

• Modular decomposability• Modular composability• Modular understandability• Modular continuity• Modular protection


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


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)


Modular Understandability

• Encourage the development of modules which are easily understandable

• Counter example: GOTO


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


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


Criteria for design


Five principles for good design

• Linguistic modular units• Few interfaces• Small interfaces• Explicit interfaces• Information hiding


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


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.


Small interfaces (loose coupling)

• If two modules communicate they should exchange as little information possible

• Counter example: declaring all instance variables public (why?)


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


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


Reusability

• A major obstacle to the production of cheap quality software is reusability

• Obstacles:– Economic– Organisational– Psychological


Object oriented design

• Suitable for complex systems (why?)• We will focus on one particular OO

design approach (UML)


Date post:	26-Dec-2015
Category:	Documents
Upload:	christal-russell
View:	216 times
Download:	0 times

MADALINA CROITORU [email protected] Software Engineering week 4 Madalina Croitoru IUT Montpellier.

Documents