©Ian Sommerville 1995 Software DesignSlide 1 Software Design u Deriving a solution which satisfies software requirements

©Ian Sommerville 1995 Software DesignSlide 2 Topics covered u The design process and design methods u Design strategies including object-oriented design and functional decomposition - briefly u Design quality attributes

©Ian Sommerville 1995 Software DesignSlide 3 Design u Good design is the key to effective engineering u It is not possible to fomalize the design process in any engineering discipline. u A creative process requiring insight and flair u Any design problem must be tackled in three stages: Study and understand the problem Identify gross features of at least one possible solution Describe earch abstraction used in the solution

©Ian Sommerville 1995 Software DesignSlide 4 The design process u Any design may be modelled as a directed graph made up of entities with attributes which participate in relationships u The system should be described at several different levels of abstraction u Design takes place in overlapping stages. It is artificial to separate it into distinct phases but some separation is usually necessary

©Ian Sommerville 1995 Software DesignSlide 5 From informal to formal design

©Ian Sommerville 1995 Software DesignSlide 6 Output of Activity u A specification of some kind is the output of each design activity u It maybe an abstract, formal specification that is produced to clarify the requirement u Or it maybe a specification of how part of the system is to be realized u Detail will be added to the specification as the design process continue u The final results are precise specification of the algorithm and data structure to be implemented

©Ian Sommerville 1995 Software DesignSlide 7 Phases in the design process

©Ian Sommerville 1995 Software DesignSlide 8 Design phases u Architectural design Identify sub-systems u Abstract specification Specify sub-systems u Interface design Describe sub-system interfaces u Component design Decompose sub-systems into components u Data structure design Design data structures to hold problem data u Algorithm design Design algorithms for problem functions

©Ian Sommerville 1995 Software DesignSlide 9 Hierarchical design structure

©Ian Sommerville 1995 Software DesignSlide 10 Top-down design u In principle, top-down design involves starting at the uppermost components in the hierarchy and working down the hierarchy level by level u 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

©Ian Sommerville 1995 Software DesignSlide 11 Design methods u Software design is still an ad hoc process, starting from a set of requirements (usually in natural language), an informal design is prepared. u Structured methods are sets of notations for expressing a software design and guidelines for creating a design u Well-known methods include Structured Design (Yourdon), and JSD (Jackson Method) Can be applied successfully because they support standard notations and ensure designs follow a standard form u Structured methods may be supported with CASE tools

©Ian Sommerville 1995 Software DesignSlide 12 Method components u Many methods support comparable views of a system u A data flow view (data flow diagrams) showing data transformations u An entity-relation view describing the logical data structures u A structural view showing system components and their interactions u An Object-oriented modelling how objects are composed and used by other objects

©Ian Sommerville 1995 Software DesignSlide 13 Method deficiencies u They are guidelines rather than methods in the mathematical sense. Different designers create quite different system designs u They do not help much with the early, creative phase of design. Rather, they help the designer to structure and document his or her design ideas

©Ian Sommerville 1995 Software DesignSlide 14 Design description u There are three main types of notation used in design document u Graphical notations. Used to display component relationships u Program description languages. Based on programming languages but with more flexibility to represent abstract concepts u Informal text. Natural language description. u All of these notations may be used in large systems design

©Ian Sommerville 1995 Software DesignSlide 15 Design strategies u Functional design The system is designed from a functional viewpoint. The system state is centralised and shared between the functions operating on that state u Object-oriented design The system is viewed as a collection of interacting objects. The system state is de-centralised and each object manages its own state. Objects may be instances of an object class and communicate by exchanging messages

©Ian Sommerville 1995 Software DesignSlide 16 Functional view of a compiler

©Ian Sommerville 1995 Software DesignSlide 17 Object-oriented view of a compiler

©Ian Sommerville 1995 Software DesignSlide 18 Mixed-strategy design u Although it is sometimes suggested that one approach to design is superior, in practice, an object-oriented and a functional-oriented approach to design are complementary u Good software engineers should select the most appropriate approach for whatever sub-system is being designed

©Ian Sommerville 1995 Software DesignSlide 19 Design quality u Design quality is an elusive concept. Quality depends on specific organisational priorities u A 'good' design may be the most efficient, the cheapest, the most maintainable, the most reliable, etc. u The attributes discussed here are concerned with the maintainability of the design u Quality characteristics are equally applicable to function-oriented and object-oriented designs

©Ian Sommerville 1995 Software DesignSlide 20 Cohesion u A measure of how well a component 'fits together' u A component should implement a single logical entity or function u Cohesion is a desirable design component attribute as when a change has to be made, it is localised in a single cohesive component u Various levels of cohesion have been identified

©Ian Sommerville 1995 Software DesignSlide 21 Cohesion levels u Coincidental cohesion (weak) Parts of a component are simply bundled together u Logical association (weak) Components which perform similar functions are grouped For example: output text to screen output line to printer output record to file Seems ok Problem is it carries out a range of similar but different actions No single well defined action

©Ian Sommerville 1995 Software DesignSlide 22 Cohesion levels u Temporal cohesion (weak) Components which are activated at the same time are grouped For example: clear screen open file Initialise total again not related solution is to make initialisation module all other specialised modules: call init_terminal call init_files call init_calculations

©Ian Sommerville 1995 Software DesignSlide 23 Cohesion levels u Procedural cohesion (weak) The elements in a component make up a single control sequence u Communicational cohesion (medium) All the elements of a component operate on the same data e.g. display and log temperature u Sequential cohesion (medium) The output for one part of a component is the input to another part

©Ian Sommerville 1995 Software DesignSlide 24 Cohesion levels u Functional cohesion (strong) optimal type of cohesion performs a single well-defined action on a single data object e.g. calculate average Each part of a component is necessary for the execution of a single function u Object cohesion (strong) Each operation provides functionality which allows object attributes to be modified or inspected

©Ian Sommerville 1995 Software DesignSlide 25 Cohesion as a design attribute u Not well-defined. Often difficult to classify cohesion u Inheriting attributes from super-classes weakens cohesion u To understand a component, the super-classes as well as the component class must be examined u Object class browsers assist with this process

©Ian Sommerville 1995 Software DesignSlide 26 u A measure of the strength of the inter-connections between system components u Loose coupling means component changes are unlikely to affect other components u Shared variables or control information exchange lead to tight coupling u Loose coupling can be achieved by state decentralisation (as in objects) and component communication via parameters or message passing Coupling

©Ian Sommerville 1995 Software DesignSlide 27 Tight coupling

©Ian Sommerville 1995 Software DesignSlide 28 Loose coupling

©Ian Sommerville 1995 Software DesignSlide 29 Coupling levels u Altering another modules code (LISP, Assembler) u Modifying data within another module fault that appears in one module may be due to another complicated understanding and debugging can be done via global variables or pointers or call be reference in C++ / Java u Shared or global data

©Ian Sommerville 1995 Software DesignSlide 30 Coupling levels u Procedure call with a parameter that is a switch (or a function pointer in C) io (command, device buffer, length); where command is 0,1,2 for read, write open; better to use read( device, buffer, length); u Procedure call with parameters that are pure data ideal is call by value, where a small number of parameters are used and a copy of the data is passed to the procedure invoked clear what information is being communicated

©Ian Sommerville 1995 Software DesignSlide 31 Coupling levels u Passing a serial data stream most ideal situation one module passes stream of data to another once passed data is outside control of process/module like piping in UNIX data can be thought of as a temporary intermediate file only possible in languages that support concurrency such as Ada and Erlang and Parallel C

©Ian Sommerville 1995 Software DesignSlide 32 u Object-oriented systems are loosely coupled because there is no shared state and objects communicate using message passing u 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. Such changes must be carefully controlled Coupling and inheritance

©Ian Sommerville 1995 Software DesignSlide 33 u Related to several component characteristics Cohesion. Can the component be understood on its own? Naming. Are meaningful names used? Documentation. Is the design well-documented? Complexity. Are complex algorithms used? u Informally, high complexity means many relationships between different parts of the design. hence it is hard to understand u Most design quality metrics are oriented towards complexity measurement. They are of limited use Understandability

©Ian Sommerville 1995 Software DesignSlide 34 u A design is adaptable if: Its components are loosely coupled It is well-documented and the documentation is up to date There is an obvious correspondence between design levels (design visibility) Each component is a self-contained entity (tightly cohesive) u To adapt a design, it must be possible to trace the links between design components so that change consequences can be analysed Adaptability

©Ian Sommerville 1995 Software DesignSlide 35 Design traceability

©Ian Sommerville 1995 Software DesignSlide 36 u Inheritance dramatically improves adaptability. Components may be adapted without change by deriving a sub-class and modifying that derived class u However, as the depth of the inheritance hierarchy increases, it becomes increasingly complex. It must be periodically reviewed and restructured new trend in this area known as refactoring, associated with the lightweight process of Extreme Programming (XP) Adaptability and inheritance