CS2200 Software Development

1. CS2200 Software Development • Software Design • A. O’Riordan, 2008

2. Design • Design is the process of originating and developing a plan for an artistic or functional object, which may require countless hours of thought, modeling, iterative adjustment, and re-design. • Engineering is often viewed as a more rigorous form of design than is practiced the arts and crafts. • Some designs are viewed as classic • [1916] Coca-Cola glass bottle by Root Glass Company • [1935] Volkswagen Car by Erwin Komenda • [1984] Apple Macintosh by Apple Computer by Raskin, Atkinson and Smith and others Software examples: • [1979] Model-View-Controller Design Pattern by Reenskaug, Xerox • [1998] Google Search Page by Larry Page and Sergey Brin

3. Software Design • Software designers need knowledge of computer science and basic engineering design principles. • Software design encompasses high level specification through to programming. • Definition of Software Design: The process of defining the architecture, components, interfaces, and other characteristics of a system or component. [IEEE spec. 610.12, 1990] • In analysis it is possible to produce the correct model of an existing system. However there is no such thing as a correct design. • A design should be acceptable to users and easy to implement.

4. Design Objectives • The design process involves the search for a good design given a set of objectives that are reasonably static (no sudden changes). • Evolutionary Design: Objectives "evolve" over time. • Design Objectives [Hawryszkiewycz†] • Functional objectives – new services, security, etc. • Process improvements – access to data, input/output • Operational objectives – performance • Personal & job satisfaction needs – user interface, ergonomics • †Hawryszkiewycz, I. Introduction to Systems Analysis and Design, 5th ed. Prentice-Hall, 2000.

5. What designers do? •   Designers …† • use abstract "mental models" to simulate the dynamic behaviour of the eventual system; • make constraints affecting design explicit when handling an unfamiliar problem; • reuse previous design plans - design patterns; • make notes about future intention of system - aide to expansion of design. †Adelson, B. and E. Soloway. The Role of Domain Experience in Software Design. IEEE Trans. on Software Engineering, V SE-11, N 11, 1985, pp. 1351-1360.

6. Constraints on Design I • In practice, there are few opportunities to design a system with a free hand. Design takes place in a context. Examples of constraints: • operation environment - Linux, Windows, multiplatform, Web • file structures - storage requirements • programming language(s) – general purpose, scripting, specialized • "look and feel" of user interface – Swing, Windows, OS X • choice of using a single process or several with interprocess communication; multithreaded • single machine or distributed application

7. Constraints on Design II • choice of software architecture - e.g. client/server or centralised • standards conformance - ISO, W3C, IETF • performance and timing criteria – important for real-time systems • extensibility – future upgrades • release date • security and privacy – if data is sensitive or financial tracnsactions

8. Elements of Software Design Dijkstra wrote about disentangling intrinsic intricacy from accidental intricacy. He proposed that the central challenge of computing was “how not to make a mess”†. †Dijkstra, E. The next fifty years. EWD1243, http://www.cs.utexas.edu/users/EWD/ • Data Abstraction/Encapsulation • Modularity and Procedural Abstraction • Assessing Design: Cohesion and Coupling • We will examine each in turn

9. Data Abstraction • Data Abstraction – separate the details of how an object is used from the primitive data that represent it • Programs should be designed around an abstract interface • Don’t assume anything about the details of the data that is not required to perform the task • Concrete implementations of the data can then be provided separately, and can be changed without affecting the rest of the program, i.e. the interface

10. Encapsulation • Encapsulation: hiding implementation details behind a public interface • In Java there is public, private and protected visibility • A class is the interface plus the implementation • interface: the signatures of public methods (and public data) • implementation: the method bodies, private data (and private methods) • May require setters and getters - although we now have the overhead of extra method invocations, the overhead is small • Java Bean is a class where field xyz of type T has getter and setter T getXyz() and setXyz(T t) respectively

11. Modularity • Modularity - organisation of a program into small independent units called modules • A module is implemented as a sequence of programming instructions bounded by an entry point and an exit point, or multiple exit points. • Goals • decompose program into independent pieces • divide complex problem into smaller problems • test part of program independently of it's use as a unit larger system “We propose … that one begins with a list of difficult design decisions or design decisions which are likely to change. Each module is then designed to hide such a decision from the others” [Parnas†] †On the Criteria to Be Used in Decomposing Systems into Modules. Communications of the ACM, 15(12), 1972

12. Procedure Abstraction • Procedural Abstraction: the organisation of a program into methods • Factoring: identify recurring segments of code and capture them once in a single method • Top-down decomposition or "stepwise refinement" †). : design a complex method by breaking it up into smaller chunks • This approach to software design probably originated at IBM. • Bottom-up composition: write some simple methods and then use them to design more complex ones • end product is built by integration • † Wirth N. "Program Development by Stepwise Refinement," • Communications of the ACM, Vol. 14, No. 4, April 1971.

13. Assessing Design: Cohesion • The software quality metrics of coupling and cohesion were invented by Larry Constantine and others at IBM†. • Cohesion: the degree to which the computation in a method is directed towards a single purpose • High cohesion is desirable • write separate methods for separate purposes • convoluted method names are a sign of low cohesion • Yourdon suggests that an effective way of doing an assessment of module cohesion is to try to describe the module's function in a single sentence. If the module is cohesive it should be possible. †Wayne P. Stevens, Glenford J. Myers, Larry L. Constantine. Structured Design. IBM Systems Journal 13(2): 115-139 (1974)

14. Assessing Design: Coupling • Coupling: the degree to which methods rely on each other • When there is little interaction between methods, methods are described as loosely coupled; when there is a great deal of interaction, they are said to be tightly coupled. • Low (or loose or weak) coupling is desirable • Three factors affect the coupling between methods • Data items passed between methods • Control data passed between methods • Global data passed between methods • Operates are multiple levels of granularity – method, class and package

15. Prototyping • Prototyping a design in engineering • a first of it’s kind • model produced to scale • simulation • Prototyping is popular at the moment: • Iterative lifecycle models • agile processes • RAD (Rapid Application Development) method • interpreted languages, e.g. Java bytecode • scripting languages (e.g. Javascript, PHP).

16. Role of Prototyping • Categorised according to the roles they play in the software lifecycle: • Exploratory • helps evaluate the feasibility of different design alternatives • may also be used to clarify user requirements • thrown away • Evolutionary • form of prototyping closest to actual development • software is adapted gradually, changing requirements as you go • prototype may actually become the final released product. • Experimental • used to evaluate possible solutions to a problem • developed in advance of large-scale implementation • may be used for assessment of performance

17. Benefits of good design • Greater readability - individual methods may be shorter; the contribution of a method should be obvious from its signature • Greater maintainabiltiy - reduced repetition means fewer inconsistent changes • Greater testability - smaller independently testable and debuggable pieces • Greater reusability - each smaller class/method does some single well-defined task that may be needed in other parts of the project • Possibly greater performance - it may be easier to find bottlenecks in the code and remedy them