Software Design

1. Software Design

2. Main issues: decompose system into parts many attempts to measure the results design as product  design as process

3. Programmer’s Approach to Software Engineering • Skip requirements engineering and design phases; • start writing code

4. Why this programmer’s approach? • Design is a waste of time • We need to show something to the customer real quick • We are judged by the amount of LOC/month • We expect or know that the schedule is too tight

5. However, ... The longer you postpone coding, the sooner you’ll be finished

6. Up front remarks • Design is a trial-and-error process • The process is not the same as the outcome of that process • There is an interaction between requirements engineering, architecting, and design

7. Software design as a “wicked” problem • There is no definite formulation • There is no stopping rule • Solutions are not simply true or false • Every wicked problem is a symptom of another problem

8. Design Purpose

9. Purpose of Design • Design is where customer requirements, business needs, and technical considerations all come together in the formulation of a product or system • The design model provides detail about the software data structures, architecture, interfaces, and components • The design model can be assessed for quality and be improved before code is generated and tests are conducted • Does the design contain errors, inconsistencies, or omissions? • Are there better design alternatives? • Can the design be implemented within the constraints, schedule, and cost that have been established?

10. Purpose of Design • A designer must practice diversification and convergence • The designer selects from design components, component solutions, and knowledge available through catalogs, textbooks, and experience • The designer then chooses the elements from this collection that meet the requirements defined by requirements engineering and analysis modeling • Convergence occurs as alternatives are considered and rejected until one particular configuration of components is chosen • Software design is an iterative process through which requirements are translated into a blueprint for constructing the software • Design begins at a high level of abstraction that can be directly traced back to the data, functional, and behavioral requirements • As design iteration occurs, subsequent refinement leads to design representations at much lower levels of abstraction

11. Design Quality

12. Design Quality – Quality’s Role • The importance of design is quality • Design is the place where quality is fostered • Provides representations of software that can be assessed for quality • Accurately translates a customer's requirements into a finished software product or system • Serves as the foundation for all software engineering activities that follow • Without design, we risk building an unstable system that • Will fail when small changes are made • May be difficult to test • Cannot be assessed for quality later in the software process when time is short and most of the budget has been spent • The quality of the design is assessed through a series of formal technical reviews or design walkthroughs

13. "Writing a clever piece of code that works is one thing; designing something that can support a long-lasting business is quite another." Design Quality - Goals of Good Design • The design must implement all of the explicit requirements contained in the analysis model • It must also accommodate all of the implicit requirements desired by the customer • The design must be a readable and understandable guide for those who generate code, and for those who test and support the software • The design should provide a complete picture of the software, addressing the data, functional, and behavioral domains from an implementation perspective

14. Design Tasks

15. From Analysis Model to Design Model • Each element of the analysis model provides information that is necessary to create the four design models • The data/class design transforms analysis classes into design classes along with the data structures required to implement the software • The architectural design defines the relationship between major structural elements of the software; architectural styles and design patterns help achieve the requirements defined for the system • The interface design describes how the software communicates with systems that interoperate with it and with humans that use it • The component-level design transforms structural elements of the software architecture into a procedural description of software components

16. Component-level Design (Class-based model, Flow-oriented model Behavioral model) Interface Design (Scenario-based model, Flow-oriented model Behavioral model) Architectural Design (Class-based model, Flow-oriented model) Data/Class Design (Class-based model, Behavioral model) From Analysis Model to Design Model

17. Design Elements • Data/class design • Creates a model of data and objects that is represented at a high level of abstraction • Architectural design • Depicts the overall layout of the software • Interface design • Tells how information flows into and out of the system and how it is communicated among the components defined as part of the architecture • Includes the user interface, external interfaces, and internal interfaces • Component-level design elements • Describes the internal detail of each software component by way of data structure definitions, algorithms, and interface specifications • Deployment-level design elements • Indicates how software functionality and subsystems will be allocated within the physical computing environment that will support the software

18. Dimensions of the Design Model High Analysis model Abstraction Dimension Design model Data/Class Elements Architectural Elements Interface Elements Component-level Elements Deployment-level Elements Low Process Dimension (Progression)

19. Design Tasks • Examine the information domain model and design appropriate data structures for data objects and their attributes • Using the analysis model, select an architectural style (and design patterns) that are appropriate for the software • Partition the analysis model into design subsystems and allocate these subsystems within the architecture • Design the subsystem interfaces • Allocate analysis classes or functions to each subsystem • Create a set of design classes or components • Translate each analysis class description into a design class • Check each design class against design criteria; consider inheritance issues • Define methods associated with each design class • Evaluate and select design patterns for a design class or subsystem

20. Design Tasks • Design any interface required with external systems or devices • Design the user interface • Conduct component-level design • Specify all algorithms at a relatively low level of abstraction • Refine the interface of each component • Define component-level data structures • Review each component and correct all errors uncovered • Develop a deployment model • Show a physical layout of the system, revealing which components will be located where in the physical computing environment

21. Design Principles

22. Design principles • Abstraction • Modularity, coupling and cohesion • Information hiding • Limit complexity • Hierarchical structure

23. Abstraction procedural abstraction: • natural consequence of stepwise refinement • a sequence of instructions that have a specific and limited function abstraction subproblems time

24. Abstraction data abstraction: • aimed at finding a hierarchy in the data • a named collection of data that describes a data object application-oriented data structures simpler data structure general data structures

25. Modularity • structural criteria which tell us something about individual modules and their interconnections • Separately named and addressable components (i.e., modules) that are integrated to satisfy requirements (divide and conquer principle) • Makes software intellectually manageable so as to grasp the control paths, span of reference, number of variables, and overall complexity • Functional independence • Modules that have a "single-minded" function and an aversion to excessive interaction with other modules • cohesion and coupling • cohesion: the glue that keeps a module together • coupling: the strength of the connection between modules • High cohesion – a module performs only a single task • Low coupling – a module has the lowest amount of connection needed with other modules

26. How to determine the cohesion type? • describe the purpose of the module in one sentence • if the sentence is compound, contains a comma or more than one verb  it probably has more than one function: logical or communicational cohesion • if the sentence contains time-related words like “first”, “then”, “after”  temporal cohesion • if the verb is not followed by a specific object  probably logical cohesion (example: edit all data) • words like “startup”, “initialize” imply temporal cohesion

27. strong cohesion & weak coupling simple interfaces  • simpler communication • simpler correctness proofs • changes influence other modules less often • reusability increases • comprehensibility improves

28. Information hiding • each module has a secret • design involves a series of decision: for each such decision, wonder who needs to know and who can be kept in the dark • The designing of modules so that the algorithms and local data contained within them are inaccessible to other modules • This enforces access constraints to both procedural (i.e., implementation) detail and local data structures • information hiding is strongly related to • abstraction: if you hide something, the user may abstract from that fact • coupling: the secret decreases coupling between a module and its environment • cohesion: the secret is what binds the parts of the module together

29. Complexity • measure certain aspects of the software (lines of code, # of if-statements, depth of nesting, …) • use these numbers as a criterion to assess a design, or to guide the design • interpretation: higher value  higher complexity  more effort required (= worse design) • two kinds: • intra-modular: inside one module • inter-modular: between modules

30. intra-modular • attributes of a single module • Two types: • measures based on size • measures based on structure

31. Sized-based complexity measures • counting lines of code • differences in verbosity • differences between programming languages • a:= b versus while p^ <> nil do p:= p^

32. Structure-based measures • based on • control structures • data structures • or both • example complexity measure based on data structures: average number of instructions between successive references to a variable • best known measure is based on the control structure: McCabe’s cyclomatic complexity

33. Hierarchy - System structure: inter-module complexity • looks at the complexity of the dependencies between modules • draw modules and their dependencies in a graph • then the arrows connecting modules may denote several relations, such as: • A contains B • A precedes B • A uses B • we are mostly interested in the latter type of relation

34. In a picture: hierarchy chaos strict hierarchy tree

35. Design Methods

36. Design methods • Functional decomposition • Data Flow Design • Design based on Data Structures • Object Oriented design

37. Functional decomposition bottom-up top-down

38. Functional decomposition (cnt’d) • Extremes: bottom-up and top-down • Not used as such; design is not purely rational: • clients do not know what they want • changes influence earlier decisions • people make errors • projects do not start from scratch • Rather, design has a yo-yo character • We can only fake a rational design process

39. Data flow design • Yourdon and Constantine (early 70s) • nowadays version: two-step process: • Structured Analysis (SA), resulting in a logical design, drawn as a set of data flow diagrams • Structured Design (SD) transforming the logical design into a program structure drawn as a set of structure charts

40. Entities in a data flow diagram • external entities • processes • data flows • data stores

41. library system Top-level DFD: context diagram direction request management client report ack’ment

42. borrow title prelim. doc prelim. doc prelim. doc First-level decomposition client management request report direction log data return request borrow request acknowledgement log data log file title title catalog adm.

43. check client data process request data base log file Second-level decomposition for “preliminary processing” request client info log data OK borrow return not OK request request

44. Example minispec Identification: Process request Description: • Enter type of request 1.1 If invalid, issue warning and repeat step 1 1.2 If step 1 repeated 5 times, terminate transaction • Enter book identification 2.1 If invalid, issue warning and repeat step 2 2.2 If step 2 repeated 5 times, terminate transaction • Log client identification, request type and book identification • ...

45. OOAD methods • three major steps: • identify the objects • determine their attributes and services • determine the relationships between objects

46. (Part of) problem statement Design the software to support the operation of a public library. The system has a number of stations for customer transactions. These stations are operated by library employees. When a book is borrowed, the identification card of the client is read. Next, the station’s bar code reader reads the book’s code. When a book is returned, the identification card isnot needed and only the book’s code needs to be read.

47. (Part of) problem statement Design the software to support the operation of a public library. The system has a number of stations for customertransactions. These stations are operated by library employees. When a book is borrowed, the identification card of the client is read. Next, the station’s bar codereader reads the book’s code. When a book is returned, the identification card isnot needed and only the book’s code needs to be read.

48. Candidate objects • software • library • system • station • customer • transaction • book • library employee • identification card • client • bar code reader • book’s code

49. Carefully consider candidate list • eliminate implementation constructs, such as “software” • replace or eliminate vague terms: “system”  “computer” • equate synonymous terms: “customer” and “client”  “client” • eliminate operation names, if possible (such as “transaction”) • be careful in what you really mean: can a client be a library employee? Is it “book copy” rather than “book”? • eliminate individual objects (as opposed to classes). “book’s code”  attribute of “book copy”

50. Relationships • From the problem statement: • employee operates station • station has bar code reader • bar code reader reads book copy • bar code reader reads identification card • Tacit knowledge: • library owns computer • library owns stations • computer communicates with station • library employs employee • client is member of library • client has identification card