MADALINA CROITORU croitoru@lirmm.fr Software Engineering week 4 Madalina Croitoru IUT Montpellier.
Post on 26-Dec-2015
216 Views
Preview:
Transcript
The requirements document
• Specify external behavior
• Specify constraints on implementation
MADALINA CROITORUcroitoru@lirmm.fr
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 CROITORUcroitoru@lirmm.fr
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 CROITORUcroitoru@lirmm.fr
Procedural abstraction
• Procedures represent distinct logical functions in a program:– Display menu– Get user option
MADALINA CROITORUcroitoru@lirmm.fr
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 CROITORUcroitoru@lirmm.fr
Five criteria for design methods
• Modular decomposability• Modular composability• Modular understandability• Modular continuity• Modular protection
MADALINA CROITORUcroitoru@lirmm.fr
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 CROITORUcroitoru@lirmm.fr
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 CROITORUcroitoru@lirmm.fr
Modular Understandability
• Encourage the development of modules which are easily understandable
• Counter example: GOTO
MADALINA CROITORUcroitoru@lirmm.fr
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 CROITORUcroitoru@lirmm.fr
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 CROITORUcroitoru@lirmm.fr
Five principles for good design
• Linguistic modular units• Few interfaces• Small interfaces• Explicit interfaces• Information hiding
MADALINA CROITORUcroitoru@lirmm.fr
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 CROITORUcroitoru@lirmm.fr
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 CROITORUcroitoru@lirmm.fr
Small interfaces (loose coupling)
• If two modules communicate they should exchange as little information possible
• Counter example: declaring all instance variables public (why?)
MADALINA CROITORUcroitoru@lirmm.fr
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 CROITORUcroitoru@lirmm.fr
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 CROITORUcroitoru@lirmm.fr
Reusability
• A major obstacle to the production of cheap quality software is reusability
• Obstacles:– Economic– Organisational– Psychological
MADALINA CROITORUcroitoru@lirmm.fr
top related