Software Design

1. Software Design Deriving a solution which satisfies software Speficitaion

2. 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 abstractionuntil the design is expressed in primitive terms.

3. 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.

4. Phases in the Design Process

5. 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.

6. 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

7. 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

8. 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

9. 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

10. 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.

11. 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.

12. 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

13. Hierarchical Design Structure

14. 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.

15. 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

16. 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.

17. 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.

18. 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.

19. 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 open arrays) make this criterion harder to satisfy.

20. 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. • COUNTER EXAMPLE. Using int types where subrange or short types are appropriate.

21. 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.

22. 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 • COUNTER EXAMPLE. Subroutines in BASIC are called by giving a line number where execution is to proceed from; there is no way of telling, just by looking at a section of code, that it is a subroutine.

23. 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

24. Few Interfaces

25. 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!

26. Coupling • 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.

27. Tight Coupling

28. Loose Coupling

29. Coupling and Inheritance • 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.

30. 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; • Psychological.

31. 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.

32. 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.

33. 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

34. 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.

35. Cohesion Levels • Coincidental cohesion (weak) • Parts of a component are simply bundled together. • Logical association (weak) • Components which perform similar functions are grouped. • Temporal cohesion (weak) • Components which are activated at the same time are grouped.

36. Cohesion Levels • Communicational cohesion (medium) • All the elements of a component operate on the same input or produce the same output. • Sequential cohesion (medium) • The output for one part of a component is the input to another part. • Functional cohesion (strong) • Each part of a component is necessary for the execution of a single function. • Object cohesion (strong) • Each operation provides functionality which allows object attributes to be modified or inspected.

37. Cohesion as a Design Attribute • Not well-defined. Often difficult to classify cohesion. • Inheriting attributes from super-classes weakens cohesion. • To understand a component, the super-classes as well as the component class must be examined. • Object class browsers assist with this process.

38. Natural Language • Nouns suggest candidate Classes. • Not every noun is an Object Class. • Some are attributes of another Class. • Some are irrelevant, outside the scope of the application. • Verb phrases suggest class associations • some relationships are irrelevant (caution). • Proper nouns suggest Objects of a Class type. Beware of singular nouns.

39. Class Description • Develop a Class description, either in textual prose or some other structured form. E.G. using a customer in a Bank • Customer: a holder of one or more accounts in a Bank. A customer can consist of one or more persons or companies. A customer can: make withdrawals; deposit money; transfer money between their accounts or to another account; query their accounts.

40. Structured Class Description Class Name: Customer Description: Personal or company details Superclass: User Name: Name Description: Customer’s name Type: String (max. 12 chars) Cardinality: 1 Name: Owns Description: Details of bank accounts Type: Account Cardinality: Many

41. Structured Class Description (cont..) Public Methods: Name: Pay_bill Parameters: amount, date, destination, account. Description: Customer may pay bills through the Bank.

42. Structured Class Description (cont..) Private Methods: Name: Transfer Parameters: amount, from_account, to_account. Description: Allow transfers from owned accounts to any others.