Software Design 3 Dr. Pedro Meja Alvarez Departamento de Computacion CINVESTAV-IPN

1. Software Design 3Dr. Pedro Meja AlvarezDepartamento de ComputacionCINVESTAV-IPN

2. Specifications The exam specific topics covered in this module are listed below, and are the basis for the outline of its content • Software Design Concepts • Software Architecture • Software Design Quality Analysis and Evaluation • Software Design Notations and Documentation • Software Design Strategies and Methods • Human Factors in Software Design • Software and System Safety Module III. Software Design

3. After completing this module, you should be able to… To describe the efforts and thoughts behind software design To develop an understanding of the software design process To describe software design approaches To describe several software design techniques To contrast architectural design with detailed design Objectives Module III. Software Design

4. Organization The organization of information for each specification topic is as follows: • Topic Content Slides - detail the important issues concerning each topic and support the module objectives • Topic Reference Slides - detail the sources for the topical content and provides additional references for review • Topic Quiz Slides - allow students to prepare for the exam Module III. Software Design

5. Introduction • The main goal of the software engineering process is the production of software that: • Functions properly • On time • Within budget • Meets end-users’ needs • Software Design is a key piece of of this process Module III. Software Design

6. Characteristics of design (1) • Design situations start with a need and require intention • A need so identified acts as the initial motivational force that provides the basis for starting design work. • Design situations involve transformation • Design is the restructuring of a current situation to achieve some preferred situation • Generation of new ideas is fundamental to design situations • Design occurs whenever there is an “imaginative jump from present facts to future possibilities.” • The precise manner in which new ideas are generated cannot be codified.

7. Characteristics of design (2) • Constraint satisfaction • An initial need determines the most basic constraints and requirements on a design situation. • In general, more constraints are eventually discovered during the design work itself. • The constraints that apply both to the designed artifact and to the processes and participants involved during the design activity. • Problem solving or decision making • The solution space for design problems is very large and its sheer size eliminates exhaustive search as a possible problem solving technique • “design” is characterized by a series of decisions between various design alternatives • Each divergent perspective may influence the progress of the design in different and unpredictable ways.

8. Characteristics of design (3) • Design results in a scheme for implementing an artifact • “Design” is essentially “the formulation of a prescription or model for a finished work in advance of its embodiment” • Design representation serves as the basis to conceptualize and compare various design decisions. • Sometimes, a design does not result in a distinct “plan-then-implement” situation. • Often the design output occurs incrementally while the design and the artifact evolve together.

9. Characteristics of design (4) • Diversity and evolution • Any particular design situation could be drawn in many different directions. • The designer’s act of making decisions among the various identified design alternatives ties together this evolution of the design. • The evolution of a design is often closely linked to the consolidation of the constraints and requirements applied in a particular design situation.

10. Characteristics of design (5) • Design situations start with a need and require intention • RE is needed before software design • Finding the problems, defining the requirements • Design situations involve transformation • Software changes the world • Designing base on limited objects (shared phenomenon) and fixed rules (domain characteristics) So, Requirements, Shared Phenomenon and Domain Characteristics comprising the basis of software design, that is Analysis Model

11. Analysis Model -> Design Model Characteristics of design (6)

12. A. Software Design Concepts Definition of Software Design: A problem solving process in which the designer applies knowledge and experience to produce a conceptualization that defines and describes a solution to a problem Software Design: • Produces a description of the software’s internal construction • Describes the software’s architecture • Bridges the gap between software requirements and software code Module III. Software Design

13. A. Software Design Concepts - 2 Software Design Description (SDD) A Software Design Description (SDD) is a representation of software created to facilitate analysis, planning, implementation, and decision-making An SDD is: • Used as a medium for communicating software design information • Like a blueprint or model of the system Module III. Software Design

14. A. Software Design Concepts - 3 The Problem with Software Design • Software requirements are frequently incomplete, incorrect, and inconsistent • Requirements change over time during development • Is a "Wicked Problem”: • Cannot be easily defined so that all stakeholders agree on the problem to solve • Require complex judgements about the level of abstraction at which to define the problem • Have no clear stopping rules • Have better or worse solutions, not right and wrong ones • Have no objective measure of success • Require iteration-every trial counts • Have no given alternative solutions-these must be discovered • Often have strong moral, political or professional dimensions Module III. Software Design

15. A. Software Design Concepts - 4 • Software Design • Functional and nonfunctional • Visible and invisible • Software Design Guidelines • A design should exhibit an architecture • A design should be modular • A design should contain distinct representations • A design should lead to data structures that are appropriate. • A design should lead to components that exhibit independent functional characteristics. • A design should lead to interfaces that reduce the complexity. • A design should be derived using a repeatable method. • A design should be represented using a notation that effectively communicates its meaning.

16. A. Software Design Concepts - 5 Preliminary Design: Creates representation of the data and architecture • Detailed Design: A design activity that focuses on the creation of an algorithm • Object-Oriented: An approach to software development that makes use of a classification approach and packages data and processing together • Prototyping: The creation of a model and the simulation of all aspects of a product. • Formal Methods: A software engineering approach in which specification and design are described using mathematically-based formal notation Module III. Software Design

17. A. Software Design Concepts - 7 The Design Process Review - Definition of Design: A problem solving process in which the designer applies knowledge and experience to produce a conceptualization that defines and describes a solution to a problem Rational Unified Process (RUP) Analysis & Design Workflow Module III. Software Design

18. A. Software Design Concepts - 8 Activities Associated with the RUP Analysis & Design Discipline Module III. Software Design

19. A. Software Design Concepts - 9 Artifacts Associated with the RUP Analysis & Design Discipline Module III. Software Design

20. A. Software Design Concepts - 10 Software Design can be represented in many ways Examples: • Flow Charts • Use-Case Realizations • Data Flow Diagrams • Pseudocode • State Diagrams • Activity Diagrams • Subsystem Diagrams • Text Documents • Any combination of these Module III. Software Design

21. A. Software Design Concepts - 11 Design Phases Two Types of Design • Architecture • Detailed Architecture Design Specifycomponents, their interfaces, and their interactions with other components Detailed Design Specify the internal structure and behavior of each component Module III. Software Design

22. A. Software Design Concepts - 12 Several Approaches to Architectural Design • Top-Down • Starts with the highest level of abstraction and recursively fills in details of the subparts • Bottom-Up • Start with the lowest-level components and describe how these work together to accomplish the system’s goals • Opportunistic • Some combination of the above two approaches Module III. Software Design

23. A. References [CD04] The Computer Dictionary http://www.computerdictionary.info, 2004 [CE96] CERN, “STING Software Engineering Glossary”, http://www.apl.jhu.edu/Classes/Notes/Hausler/web/glossary.html, 1996 [DD88] Department of Defense, MIL-STD-2167A, 1998 [HR84] Rittel, H. J., and M. M. Webber (1984). "Planning problems are wicked problems", In N. Cross (Ed.), Developments in Design Methodology, Wiley, pp. 135-144. [HR84] Rittel, H. J., and M. M. Webber (1984). Planning problems are wicked problems, Wiley, 1984 [LB98] Bass, Len et al, p. 298, Software Architecture in Practice, Addison-Wesley, Boston, 1998. [RH97] Hubscher, Roland, “LBD Conceptual Design Problems”, http://www.cc.gatech.edu/edutech/LBD/ill-defined-problems.html, June 11, 1997 [RP03] Pressman, R.S. 2003, “Software Engineering Resources”, http://www.rspa.com/spi/glossary.html Module III. Software Design

24. A. References (cont.) [RS04] IBM Rational Software, The Rational Unified Process v2003.06.13, 2004 [SB97] Buckingham Shum, S., "Representing Hard-to-Formalise, Contextualised, Multidisciplinary, Organisational Knowledge“, 1997 [SD04] SmartDraw.com, http://www.smartdraw.com/tutorials, 2004 [SF03] SourceForge.net, http://cweb.sourceforge.net/cgi-bin/moin.cgi/ObjectFlow, 2003 Module III. Software Design

25. B. Software Architecture • Software architecture encompasses: • Overall organization of the software system • Selection of the structural elements and specification of their • Interfaces • Behavior • Composition of these elements into progressively larger subsystems • The architectural style Module III. Software Design

26. B. Software Architecture - 2 Software architecture is also concerned with: • Usage • Functionality • Performance • Resilience • Reuse • Comprehensibility • Economic and technology constraints and tradeoffs • Aesthetics Module III. Software Design

27. B. Software Architecture - 3 Architecture-Based Process An example of an architecture-first approach: • Create the business case for the system • Analyze the requirements • Decide on a software architecture • Specify the architecture • Communicate the architecture • Evaluate the architecture • Implement the system based on the architecture • Ensure the implementation conforms to the architecture Module III. Software Design

28. B. References [LB98] Bass, Len et al, p. 298, Software Architecture in Practice, Addison-Wesley, Boston, 1998. [OG03] Object Management Group, Model Driven Architecture Guide, v1.0.1,http://www.omg.org/mda, July 12, 2003 [RS04] IBM Corporation, 2004, The Rational Unified Process v2003.06.13 Module III. Software Design

29. C. Software Design Quality Analysis & Evaluation • Many methods to analyze design quality • No single method, by itself, is sufficient This module looks at quality programs in general and quality design attributes in particular Module III. Software Design

30. C. Software Design Quality Analysis & Evaluation - 2 What is Quality? • A measure of how good something is • Very natural concept in traditional manufacturing • Tolerance • Capacity • Strength • Size • Color • Weight • Not quite as natural for software Module III. Software Design

31. C. Software Design Quality Analysis & Evaluation - 3 Quality Concept • Meaning of “quality” has evolved over time: • Conforming to the specification • Fitness for use • 2 dimensional model • “must have” vs. • “nice to have” VS. Module III. Software Design

32. C. Software Design Quality Analysis & Evaluation - 4 Total Quality Management • Management strategy to embed quality awareness in all processes • Employs statistical methods • Goal to do things right the first time instead of fixing later • Metrics regarding failures are collected and analyzed • Then the process that caused the failure is fixed • Has roots in manufacturing • But applicable to software development also Module III. Software Design

33. C. Software Design Quality Analysis & Evaluation - 5 Quality Management System • Quality Management System (QMS) fathered by William Deming • Can be implemented with one of any number of quality management programs • Six Sigma • ISO 9000 Series • Total Quality Management (TQM) • Malcolm Baldrige National Quality Award • Recognizes high-quality U.S. companies Module III. Software Design

34. C. Software Design Quality Analysis & Evaluation – 6 Six Sigma • Quality management program • “Six Sigma” quality level goal • Pioneered by Motorola • Roughly fewer than 3.4 defects in one million • Very difficult to achieve in practice • Some market leaders have obtained six sigma Module III. Software Design

35. C. Software Design Quality Analysis & Evaluation - 7 ISO 9000 Series • Another instance of a Quality Management System • Guides the production of a product or service • A series of standards: • ISO 9000: Basic language for the entire ISO 9000 family • ISO 9001: For organizations who design, develop, test, install, and service their product • ISO 9002: For organizations who test, install and service a product • ISO 9003: For organizations who test final products • ISO 9004: Guidance for compliance and customer satisfaction Module III. Software Design

36. C. Software Design Quality Analysis & Evaluation - 8 ISO 9000-3 • Software related, specifically for companies that • Develop • Supply • Install • Maintain • End-to-end procedures to track products • Guidelines for the application of ISO 9001 to the development, supply, and maintenance of software Module III. Software Design

37. C. Software Design Quality Analysis & Evaluation - 9 Three Classifications of Quality System quality attributes categories: • Discernable by observing system execution • E.g. performance, functionality, reliability • Not discernable at runtime • E.g. modifiability, portability, reusability • Business qualities • E.g. Time to market, marketability $$$ Module III. Software Design

38. C. Software Design Quality Analysis & Evaluation - 10 Quality attributes that are discernable at system runtime Performance Two Aspects of Performance: • Response time • Number of transactions per some time interval SecurityMeasure of the system’s ability to resist unauthorized usage Availability Measure of the proportion of time a system is up and running Functionality Ability of the system to do the work for which it was intended Usability Extent to which a system is easy learn and use on an ongoing basis Module III. Software Design

39. C. Software Design Quality Analysis & Evaluation - 11 Quality attributes that are not discernable at system runtime Modifiability Ability of the system to be enhanced and maintained over time Portability Ability of the system to run in different operating environments Reusability Ability of the system, or parts thereof, to be used to construct other systems Integrability Ability of the various components of a system to be made to work together Testability Ability to objectively measure the system against its requirements Module III. Software Design

40. C. Software Design Quality Analysis & Evaluation - 12 Business Qualities Qualities that are related to business aspects • Time to Market • Release before competition • Release while demand for product exists • Marketability • Cost • Competition • Target Market Module III. Software Design

41. C. Software Design Quality Analysis & Evaluation - 13 What is a Good Design? • Well Structured • Simple • Efficient • Adequate • Flexible • Practical • Implementable Module III. Software Design

42. C. Software Design Quality Analysis & Evaluation - 14 Design Quality Techniques to assess design quality include: • Design Verification • Design Analysis • Design Reviews • Design Audit • Informal Design Walkthrough • Formal Design Inspection Module III. Software Design

43. C. Software Design Quality Analysis & Evaluation - 15 Design Inspections • Step-by-step review • Roles involved: • Moderator • Reviewer • Author • Scribe • Each step checked against a list of criteria such as • Historical errors • Programming standards • Adherence to specifications • The developer is responsible for narrating the design • Design inspections should occur for • Preliminary Design • Detailed Design • Implementation Module III. Software Design

44. C. Software Design Quality Analysis & Evaluation - 16 Design Walkthroughs • Similar to inspections but: • Developer does not narrate the design • Team lead or architect leads the walkthrough • Manual simulation of the system • Intermediate results are recorded • Good for simulating discussion • Many errors are caught by the developer Module III. Software Design

45. C. Software Design Quality Analysis & Evaluation - 17 Quality Design Aspects • Fan-Out • The number of routines a given routine calls • Information Hiding • Abstraction technique that hides details behind and interface • Cohesion • Cohesion refers to the degree to which a module’s instructions are functionally related • Coupling • Level of dependency that exists between modules Module III. Software Design

46. C. References • [LB98] Bass, Len et al., Software Architecture in Practice, Addison-Wesley, 1998 • [DP87] Parnas, D.L, and D. M. Weiss, Activity Design Reviews: Principles and Practices, Journal of Systems and Software, Vol. 7, 1987, pp. 259-265 • [IS96] IEEE Software, Keep It Simple, Vol. 13, No. 6, December, 1996 • [PR04] Praxiom Research Group Limited, http://praxiom.com/iso-9000-3b.htm • [RP05] Pressman, Roger S., Software Engineering: A Practitioner’s Approach, 6th Edition, McGraw-Hill, 2005 • [WA82] Adrion, W. Richards., Validation, Verification, and Testing of Computer Software, ACM Computing Surveys, Vol 14, No. 2, June, 1982 Module III. Software Design

47. D. Software Design Notations and Documentation • Structural Description Examples • Class and object diagrams and their relationships • CRC cards • Entity-Relationship Diagrams (ERD) used to define conceptual models of data • Interface description language to deine the interfaces of software components • Structure charts to describe the calling structure of programs • Use case diagrams to model functional requirements form the perspective of the user Module III. Software Design

48. D. Software Design Notations and Documentation - 2 Why We Model • Top reasons for modeling software • Provide the “blueprint” for our system • Facilitate communication among project team members • Assures architectural soundness • Attributes of an appropriate modeling language • Model elements • Notation • Guidelines Guidelines Model Elements Notation Module III. Software Design

49. D. Software Design Notations and Documentation - 3 Functional vs. Object Oriented Two fundamental approaches to software design • Functional • Object-Oriented Functional (a.k.a “Structured”) takes the approach that high level functionality can be repeatedly broken down into smaller and smaller functions in order to reduce complexity. Object-Oriented takes the approach that functionality belongs with “objects”, which are software elements that have identity and whose state and behavior is self-contained. Module III. Software Design

50. D. Software Design Notations and Documentation - 4 Five Aspects of Structured Design • Form of the problem guides the form of the solution • Reduces complexity by organizing the system into a hierarchy of “black boxes” • Uses graphical tools to render systems readily understandable • Provides solution strategies based on a well-defined problem statement • Provides criteria for evaluating the quality of the design Module III. Software Design