CS560: Formal Modelling and Implementation of Systems (Term II)

Transcription

1 CS560: Formal Modelling and Implementation of Systems (Term II) Software Design A.P.O Riordan, Course Webpage: CS560 1

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 CS560 2

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

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, CS560 4

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

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

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

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, Data Abstraction/Encapsulation Modularity and Procedural Abstraction Assessing Design: Cohesion and Coupling We will examine each in turn CS560 8

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

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

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

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

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): (1974) CS560 13

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

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

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

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 welldefined 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 CS560 17