Software Engineering COMP 201

1. Software EngineeringCOMP 201 Lecturer: Sebastian Coope Ashton Building, Room G.18 E-mail: coopes@liverpool.ac.uk COMP 201 web-page: http://www.csc.liv.ac.uk/~coopes/comp201 http://www.csc.liv.ac.uk/~pbell/comp201.html Lecture 13 – Design Methodology COMP201 - Software Engineering

2. Software Design Deriving a solution which satisfies software requirements COMP201 - Software Engineering

3. Software Design • Why • Software is produced by many people • Software needs to be • Simple • Understandable • Flexible • Portable • Re-usable • How • Complex to simple • Abstraction COMP201 - Software Engineering

4. Software Design in Reality • Design mixed with implementation • Designstep 1 • Implement and add more design • Design step 2 • Implement and add more design • In effect much of software is designed while coded and the design document doesn’t reflect the final product COMP201 - Software Engineering

5. 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. COMP201 - Software Engineering

6. The Design Process • Any design may be modeled 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. COMP201 - Software Engineering

7. Phases in the Design Process COMP201 - Software Engineering

8. 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. COMP201 - Software Engineering

9. 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 do; • How the modules interact with one-another COMP201 - Software Engineering

10. 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 COMP201 - Software Engineering

11. 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 COMP201 - Software Engineering

12. 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 Less well-suited to distributed, non-terminating systems- e.g., process control systems, operating systems like WinNT, ATM machines Well-suited to certain application domains - e.g., compilers COMP201 - Software Engineering

13. 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. • Note , use of internal state against functional programming • Objects may be instances of an object class and communicate by exchanging messages. COMP201 - Software Engineering

14. Five Criteria for Design Methods • We can identify five criteriato help evaluate modular design methods: • Modular decomposability; • Modular composability; • Modular understandability; • Modular continuity; • Modular protection. COMP201 - Software Engineering

15. Modular Decomposability • 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, this 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 a method COMP201 - Software Engineering

16. Hierarchical Design Structure COMP201 - Software Engineering

17. 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. COMP201 - Software Engineering

18. An Example of Top-Down Design Imagine designing a word processor program from scratch. What subsystems could be initially found at the top level? File I/O, printing, graphical user interface, text processing etc. For each of these components we can then decompose further, i.e., File I/O comprises of saving documents and opening documents.. COMP201 - Software Engineering

19. Modular Composability • 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, it 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 COMP201 - Software Engineering

20. 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. COMP201 - Software Engineering

21. Modular Understandability • Abstraction • int A=21 • intage_in_years = 21; print_out_document(Document d) • Modular Understandability - a design method satisfies this criterion if it encourages the development of modules which are easily understandable. • COUNTER EXAMPLE 1. 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. • COUNTER EXAMPLE 2. “Go to” statements. COMP201 - Software Engineering

22. Modular 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. COMP201 - Software Engineering

23. Modular Continuity • 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 • COUNTER EXAMPLE. Static arrays (as opposed to dynamic arrays) make this criterion harder to satisfy. COMP201 - Software Engineering

24. Modular Protection • 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 (design by contract) • COUNTER EXAMPLE. Using int types where subrange or short types are appropriate. COMP201 - Software Engineering

25. A Real Life Example – Ariane 5 Flight 501 • The failure of an Ariane 5 space launcher is possibly the most expensive software bug in history at around $370 million. • Other bugs have been even worse by causing loss of life, for example Therac-25 radiation machines. COMP201 - Software Engineering

26. The Ariane 5 Space Launcher • While developing the Ariane 5 space launcher, the designers reused a component (the inertial reference software) which was successfully used in the Ariane 4 launcher • This component failed 37 seconds into the flight and the ground crew had to instruct the launcher to self-destruct. • The error was caused by an unhandled numerical conversion exception causing a numeric overflow. • Component reuse is usually a good thing but care must be taken that assumptions made when the component was developed are still valid! COMP201 - Software Engineering

27. Repository Models • Sub systems making up a system must exchange and share data so they can work together effectively. • There are two main approaches to this: • The repository model – All shared data is held in a central database which may be accessed by all sub-systems • Each sub-system or component maintains its own database. Data is then exchanged between sub-systems via message passing. • There are advantages and disadvantages to each approach as we shall now see. COMP201 - Software Engineering

28. Repository Model • The advantages include: • Databases are an efficient way to share large amounts of data and data does not have to be transformed between different sub-systems (they agree on a single data representation). • Sub-systems producing data need not be concerned with how that data is used by other sub-systems. • Many standard operations such as backup, security, access control, recovery and data integrity are centralised and can be controlled by a single repository manager. • The data model is visible through the repository schema. COMP201 - Software Engineering

29. Repository Model • The disadvantages include: • Sub-systems must agree on the data model which means compromises must be made, for example with performance. • Evolution may be difficult since a large amount of data is generated and translation may be difficult and expensive. • Different systems have different requirements for security, recovery and backup policies which may be difficult to enforce in a single database. • It may be difficult to distribute the repository over a number of different machines. COMP201 - Software Engineering

30. Lecture Key Points • We have studied five criteria to help evaluate modular design methods and their advantages: • Modular decomposability; modular composability; modular understandability; modular continuity; modular protection. • We have seen the advantages and the disadvantages of repository models COMP201 - Software Engineering