Upload
mahmoud-saaideh
View
69
Download
1
Tags:
Embed Size (px)
DESCRIPTION
for software engineering
Citation preview
Software Engineering Software Design Slide 1
Software Engineering
Software Design
Software Engineering Software Design Slide 2
Software Design
Deriving a solution which satisfies software requirements
Software Engineering Software Design Slide 3
Stages of Design
• Problem understanding– Look at the problem from different angles to discover the
design requirements.
• Identify one or more solutions– Evaluate possible solutions and choose the most appropriate depending
on the designer's experience and available resources.
• Describe solution abstractions– Use graphical, formal or other descriptive notations to
describe the components of the design.
• Repeat process for each identified abstraction until the design is expressed in primitive terms.
Software Engineering Software Design Slide 4
The Design Process
• Any design may be modelled as a directed graph made up of entities with attributes which participate in relationships.
• The system should be described at several different levels of abstraction.
• Design takes place in overlapping stages. It is artificial to separate it into distinct phases but some separation is usually necessary.
Software Engineering Software Design Slide 5
Phases in the Design Process
Architecturaldesign
Abstractspecificatio
n
Interfacedesign
Componentdesign
Datastructuredesign
Algorithmdesign
Systemarchitecture
Softwarespecification
Interfacespecification
Componentspecification
Datastructure
specification
Algorithmspecification
Requirementsspecification
Design activities
Design products
Software Engineering Software Design Slide 6
Design Phases
• Architectural design: Identify sub-systems.
• Abstract specification: Specify sub-systems.
• Interface design: Describe sub-system interfaces.
• Component design: Decompose sub-systems into components.
• Data structure design: Design data structures to hold problem data.
• Algorithm design: Design algorithms for problem functions.
Software Engineering Software Design Slide 7
Design
• Computer systems are not monolithic: they are usually composed of multiple, interacting modules.
• Modularity has long been seen as a key to cheap, high quality software.
• The goal of system design is to decode:– What the modules are;
– What the modules should be;
– How the modules interact with one-another
Software Engineering Software Design Slide 8
Modular programming
• In the early days, modular programming was taken to mean constructing programs out of small pieces: “subroutines”
• But modularity cannot bring benefits unless the modules are – autonomous, – coherent and – robust
Software Engineering Software Design Slide 9
Procedural Abstraction
• The most obvious design methods involve functional decomposition.
• This leads to programs in which procedures represent distinct logical functions in a program.
• Examples of such functions:– “Display menu”– “Get user option”
• This is called procedural abstraction
Software Engineering Software Design Slide 1 0
Programs as Functions
• Another view is programs as functions:
input output
x f f (x) the program is viewed as a function from a set I of legal inputs to a set O of outputs.
• There are programming languages (ML, Miranda, LISP) that directly support this view of programming
Software Engineering Software Design Slide 11
Object-oriented design
– The system is viewed as a collection of interacting objects.
– The system state is decentralized and each object manages its own state.
– Objects may be instances of an object class and communicate by exchanging
methods.
Software Engineering Software Design Slide 1 2
Five Criteria for Design Methods
• We can identify five criteria to help evaluate modular design methods:– Modular decomposability;– Modular composability;– Modular understandability;– Modular continuity;– Modular protection.
Software Engineering Software Design Slide 1 3
Modular Decomposability
• This criterion is met by a design method if the method supports the decomposition of a problem into smaller sub-problems, which can be solved independently.
• In general method will be repetitive: sub-problems will be divided still further
• Top-down design methods fulfil this criterion; stepwise refinement is an example of such method
Software Engineering Software Design Slide 1 4
Hierarchical Design Structure
System level
Sub-systemlevel
Software Engineering Software Design Slide 1 5
Top-down Design
• In principle, top-down design involves starting
at the uppermost components in the hierarchy and working down the hierarchy level by level.
• In practice, large systems design is never truly top-down. Some branches are designed before others. Designers reuse experience (and sometimes components) during the design process.
Software Engineering Software Design Slide 1 6
Modular Composability
• A method satisfies this criterion if it leads to the production of modules that may be freely combined to produce new systems.
• Composability is directly related to the issue of reusability • Note that composability is often at odds with
decomposability; top-down design, – for example, tends to produce modules that may not be composed
in the way desired
• This is because top-down design leads to modules which fulfil a specific function, rather than a general one
Software Engineering Software Design Slide 1 7
Examples
• The Numerical Algorithm Group (NAG) libraries contain a wide range of routines for solving problems in linear algebra, differential equations, etc.
• The Unix shell provides a facility called a pipe, written “”, whereby – the standard output of one program may be
redirected to the standard input of another; this convention favours composability.
Software Engineering Software Design Slide 1 8
Modular Understandability
• A design method satisfies this criterion if it encourages the development of modules which are easily understandable.
• EXAMPLE. Take a thousand lines program, containing no procedures; it’s just a long list of sequential statements. Divide it into twenty blocks, each fifty statements long; make each block a method.
Software Engineering Software Design Slide 1 9
Understandability
• Related to several component characteristics– Can the component be understood on its own?– Are meaningful names used?– Is the design well-documented?– Are complex algorithms used?
• Informally, high complexity means many relationships between different parts of the design.
Software Engineering Software Design Slide 2 0
Modular Continuity
• A method satisfies this criterion if it leads to the production of software such that a small change in the problem specification leads to a change in just one (or a small number of ) modules.
• EXAMPLE. Some projects enforce the rule that no numerical or textual literal should be used in programs: only symbolic constants should be used
Software Engineering Software Design Slide 2 1
Modular Protection
• A method satisfied this criterion if it yields architectures in which the effect of an abnormal condition at run-time only effects one (or very few) modules
• EXAMPLE. Validating input at source prevents errors from propagating throughout the program.
Software Engineering Software Design Slide 2 2
Five principles for Good Design
• From the discussion above, we can distil five principles that should be adhered to:– Linguistic modular units;– Few interfaces;– Small interfaces– Explicit interfaces;– Information hiding.
Software Engineering Software Design Slide 2 3
Linguistic Modular Units
• A programming language (or design language) should support the principle of linguistic modular units:– Modules must correspond to linguistic units in the
language used
• EXAMPLE. Java methods and classes
Software Engineering Software Design Slide 2 4
Few Interfaces
• This principle states that the overall number of communication channels between modules should be as small as possible:– Every module should communicate with as few others
as possible.
• So, in the system with n modules, there may be a minimum of n-1 and a maximum of links; your system should stay closer to the minimum
2
)1( nn
Software Engineering Software Design Slide 2 5
Few Interfaces
Software Engineering Software Design Slide 2 6
Small Interfaces (Loose Coupling)
• This principle states:– If any two modules communicate, they should
exchange as little information as possible.
• COUNTER EXAMPLE. Declaring all instance variables as public!
Software Engineering Software Design Slide 2 7
• A measure of the strength of the inter-connections between system components.
• Loose coupling means component changes are unlikely to affect other components.– Shared variables or control information exchange lead
to tight coupling.– Loose coupling can be achieved by state
decentralization (as in objects) and component communication via parameters or message passing.
Coupling
Software Engineering Software Design Slide 2 8
Tight Coupling
Module A Module B
Module C Module D
Shared dataarea
Software Engineering Software Design Slide 2 9
Loose Coupling
Module A
A’s data
Module B
B’s data
Module D
D’s data
Module C
C’s data
Software Engineering Software Design Slide 3 0
• Object-oriented systems are loosely coupled because there is no shared state and objects communicate using message passing.
• However, an object class is coupled to its super-classes. Changes made to the attributes or operations in a super-class propagate to all sub-classes.
Coupling and Inheritance
Software Engineering Software Design Slide 3 1
Reusability
• A major obstacle to the production of cheap quality software is the intractability of the reusability issue.
• Why isn’t writing software more like producing hardware? Why do we start from scratch every time, coding similar problems time after time after time?
• Obstacles:– Economic;
– Organizational;
Software Engineering Software Design Slide 3 2
Stepwise Refinement
• The simplest realistic design method, widely used in practice.
• Not appropriate for large-scale, distributed systems: mainly applicable to the design of methods.
• Basic idea is:– Start with a high-level spec of what a method is to achieve;– Break this down into a small number of problems (usually no
more than 10)– For each of these problems do the same;– Repeat until the sub-problems may be solved immediately.
Software Engineering Software Design Slide 3 3
Explicit Interfaces
• If two modules must communicate, they must do it so that we can see it:– If modules A and B communicate, this must be
obvious from the text of A or B or both.
• Why? If we change a module, we need to see what other modules may be affected by these changes.
Software Engineering Software Design Slide 3 4
Information Hiding
• This principle states:– All information about a module, (and particularly how the
module does what it does) should be private to the module unless it is specifically declared otherwise.
• Thus each module should have some interface, which is how the world sees it anything beyond that interface should be hidden.
• The default Java rule:– Make everything private
Software Engineering Software Design Slide 3 5
Cohesion
A measure of how well a component “fits together”.
• A component should implement a single logical entity or function.
• Cohesion is a desirable design component attribute as when a change has to be made, it is localized in a single cohesive component.
• Various levels of cohesion have been identified.