Software Design: An Overview Guy Tremblay and Anne Pons

1. Software Design: An OverviewGuy Tremblay and Anne Pons EEL 6883 Software Engineering Vol. 1 Chapter 4 pp.191-208 Presenter: Sorosh Olamaei

2. 1 Introduction • Design as a life cycle activity bonds the requirements to construction • Process of breaking down the system into components, defining interfaces and defining components to a level of detail that enables their construction • Blueprint of the solution to be implemented • Usually not unique

3. Scope of the paper DeMarco’s terminology: • Decomposition design ( D-design ): mapping of a system into its component pieces • Family Pattern design (FP-Design): goal is to establish exploitable commonalities over a family of systems • Not covered: User Interface design, Invention design (I-design): a conceptualization of a system to satisfy discovered needs and constraints

4. 2 Software Design Concepts • Design key concepts: (car example) • Goals • Constraints • Alternatives • Representations • Solutions ( to wicked problems: lack of test to determine when the problem is indeed solved)

5. 2.2 Software Design Context Software design is bounded to: • Requirement analysis • Construction (coding and unit testing) • Integration and qualification testing • Linear or Incremental life cycle models

6. 2.3 Software Design Process • Software architectural design • Software detailed design

7. 3 Software Structure and Architecture Definition of software architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and principles guiding its design and evolution. Reuse of generic design knowledge: • Architectural Styles • Design Patterns • Product Lines

8. 3.1 Architectural Structures and Views • Key purpose of software architecture is communication among stakeholders • Design View: • A collection of models that represent an aspect of an entire system. • Represent a partial aspect of software architecture that shows specific properties of a software system • Overall organization of an SDD is composed of a number of design views each of which contains a subset of the various attributes describing design entities • View model by IEEE: • Decomposition, Dependency, Interface , detailed description • 4+1 view model by RUP: • Logical, Implementation, Process ,Deployment ,Use-case

9. Architectural Structures and Views • Views can be classified into 3 categories called Viewtypes: • Module viewtype • Component-and-connector viewtype • Allocation viewtype • Software architecture is a multifaceted artifact produced by the design process and composed of a set of relatively independent and orthogonal views

10. 3.2 Macro/Micro architectural Patterns: Architectural Styles Versus Design Patterns • A pattern is a common solution to a common problem in a given context • Goal is to codify and document recurring solutions to typical problems • Attributes to ensure transferability: • Pattern name • The context in which the pattern may apply • Example illustrating need • Essence of the general problem • Underlying solution • Implementation guidelines • Related patterns • Advantages and disadvantages

11. Macro/Micro architectural Patterns: Architectural Styles Versus Design Patterns • Pattern Classification based on scope and level of abstraction: • Architectural Styles • Design Patterns • Coding Idioms ( part of software construction not explained in this paper)

12. Macro/Micro architectural Patterns: Architectural Styles Versus Design Patterns • An architectural style expresses a fundamental structural organization schema for software systems. It provides a rich set of predefined subsystems, specifies their responsibilities, and includes rules and guideline for organizing the relationship between them • Major Architectural Styles: • General structure • Distributed systems • Interactive systems • Adaptable systems • Other Styles • Choice depends on quality attributes that must be satisfied. Heterogeneous styles are possible.

13. Macro/Micro architectural Patterns: Architectural Styles Versus Design Patterns Gamma et al. : • Creational patterns • Structural patterns • Behavioral patterns Buschmann et al. : • Structural decomposition patterns • Organization of work patterns • Access control patterns • Management patterns • Communication patterns

14. 3.3 Design of Families of Systems and Frameworks • Based on software product lines and software components • Software production line : A collection of systems sharing a managed set of features constructed from a common set of core software asset • Building a common set of software assets involves identifying the key commonalities encountered among the various members of the possible family of product- done through domain analysis as well as accounting for their possible variability - done by identifying and defining reusable and customizable components • In an object-oriented context, a related notion is that of framework, a partially complete software subsystem that can be extended by instantiating specific plug-ins or hot spots

15. 4 Software design quality analysis and evaluation • Software Quality: The totality of features and characteristics of a software product or service that bear on its ability to satisfy stated or implied needs • Properties of Software Quality • Functionality • Usability • Efficiency • Maintainability • portability

16. Software design quality analysis and evaluation • 4.1 Design Quality Attributes • Run-time qualities • Development-time qualities • Impact of architectural choices • Conceptual integrity which concerns the architecture’s intrinsic quality : architecture reflects one single set of design ideas leading to simplicity, consistency and elegance • 4.2 Measures (quantitative estimates) • Depends on selected design approach • Function-oriented (structured) measures • Objected-oriented measures • 4.3 Quality Analysis and Evaluation Tools • Quality attributes are hard to quantify • Software design reviews • Simulation and prototyping

17. 5 Software design notations and documentation • Budgen categorization: • Black-box notation : external properties of the elements of a design model • White-box notation : describing some aspect of the detailed realization of a design element • Alternative categorization: • Structural/Static properties • Behavioral/dynamic properties • 5.1 A selection of Design Notations (UML) • Class and object diagrams • Component diagrams • Deployment diagrams • Structure charts • Structure (Jackson) diagrams

18. Software design notations and documentation • 5.2 Behavioral Descriptions (Dynamic view) • Activity diagrams • Interaction diagrams : sequence and collaboration diagrams • Data flow diagrams • State transition diagrams and statechart diagrams • Pseudo code and program design languages (PDLs)

19. 5.2 Design Documentation • Coherency of the design documentation depends on many aspects: stakeholders, software development methods … • Key practice is selection of an appropriate set of views which satisfies different stakeholders needs • Project manager: detailed allocation views • Developer: detailed module and component-and-connector views

20. Design Documentation • View documentation also involves describing interfaces of the element from that view • A key characteristic of any interface specification : must be two-way which means what the element provides and what it requires • Another key idea: design should be presented and documented in a rational way: the rationale behind the key decisions should also recorded ex. The design alternatives that were considered and rejected should be described

21. 6 Software Design strategies and methods • 6.1 General Strategies and Enabling Techniques • Software design strategies can be described in terms of enabling techniques : independent of specific software development method • Abstraction • Coupling and cohesion • Divide and conquer • Information hiding and encapsulation • Sufficiency

22. Software Design strategies and methods • 6.2 Function-oriented (Structured) Design Divide and conquer approach toward identifying major system function in a top-down approach. Structured analysis produces DFDs of the various system functions together with associated process descriptions, that is, descriptions of the processing performed by each subtask, usually using informal Pseudocode. Entity-relationship diagrams describing the data stores can also be used. • Key strategies to help derive a software architecture from a DFD • Transaction analysis: triggers • Transformation analysis : identifying the central transform, structure chart • Key concept of structured design are those of coupling and cohesion: restrict coupling to normal types: data, stamp, control coupling. Avoid common and contest coupling

23. Software Design strategies and methods • Additional Heuristics to improve the quality of resulting design • Fan-in/Fan-out: high / low or moderate ( 5-7 max) • Decision splitting (avoid separating them into files) • Balanced systems: top-level modules deal with logical and abstract data independent of the implementation format

24. Software Design strategies and methods • 6.3 Object-oriented Design • Object based (no inheritance or polymorphism) Vs object oriented design • OO design (solution domain) Vs requirement analysis ( problem domain) • Class diagrams Vs Integration diagrams (sequence or elaboration diagrams) 6.4 Data-structured-oriented Design (Jackson Structured Programming) • Emphasis is on the data that a program manipulates rather than the functions it performs • Motivated by stability in data rather then functions that need to be performed • Restricted to the design of data-processing programs using sequential ( batch-style) files and processes • Jackson System Development (JSD) : approach similar to OOD to address more complex interacting processes

25. My views about the paper • Comprehensive overview which does not get the reader lost • Gets the reader motivated to read the following design papers • Lack of references to sources that expand on topics

26. Questions !?