1 / 143

CSDP Preparation Course Module III: Software Design

CSDP Preparation Course Module III: Software Design. 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

glain
Download Presentation

CSDP Preparation Course Module III: Software Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. CSDP Preparation CourseModule III: Software Design

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

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

  8. 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

  9. A. Software Design Concepts - 4 The Problem (cont.) • Ill-Defined Problems: • The problem it is not clear from the beginning on what the problem is and thus, what a solution is • Finding a solution requires in addition to find the real problem • Solving and specifying develop in parallel and drive each other • Solutions to Ill-Defined Problems: • Often such that they still could be improved • Up to the problem solver to decide when enough is enough Module III. Software Design

  10. A. Software Design Concepts - 5 Key Definitions • Software Engineering: A discipline that encompasses the process associated with software development, the methods used to analyze, design and test computer software, the management techniques associated with the control and monitoring of software projects and the tools used to support process, methods, and techniques • Analysis: A set of activities that attempt to understand and model customer needs and constraints • Design: An activity that translates the requirements model into a more detailed model that is the guide to implementation of the software • Methodology: A codified set of procedures for some phase of software engineering, such as analysis and design. • Abstraction: The level of technical detail of some representation of a software system Module III. Software Design

  11. A. Software Design Concepts - 6 Key Definitions (cont.)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

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

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

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

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

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

  17. A. Software Design Concepts - 12 Software Engineering Approaches Several General Approaches to Software Engineering • 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

  18. 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

  19. 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

  20. Which is a true statement regarding software design? a) It produces a description of the software’s internal construction b) It describes the software’s architecture c) It bridges the gap between software requirements and software code 1) a & c 2) b 3) a, b, & c 4) c A. Quiz - 1 Module III. Software Design

  21. The purpose of a Software Design Description is used to document a) requirements traceability b) high-level design c) low-level design 1) a & b 2) b & c 3) a, b, & c 4) b A. Quiz - 2 Module III. Software Design

  22. Detailed design a) is also known as low-level design b) specifies internal component structure c) specifies component behavior 1) a & b 2) b & c 3) a & c 4) a, b, & c A. Quiz - 3 Module III. Software Design

  23. Which of the following is not a valid design approach? a) inside out b) top-down c) bottom-up d) opportunistic 1) a 2) a & d 3) b & d 4) d A. Quiz - 4 Module III. Software Design

  24. A. Quiz - 5 Pseudocode is more appropriate for low-level design than architectural design. a.) True b.) False Module III. Software Design

  25. A. Quiz - 6 Software design is most concerned with which of the following: a.) synthesizing a domain analysis into an implementation b.) defining components c.) describing a solution to some problem d.) the object-oriented architecture of the solution space 1.) a 2.) b 3.) c 4.) e Module III. Software Design

  26. 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

  27. 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

  28. 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

  29. B. Software Architecture - 4 Introducing Model Driven Architecture • Relatively new approach to building software • Sponsored by the Object Management Group (OMG) • Based on a platform-independent model (PIM) • Described with Unified Modeling Language (UML) Module III. Software Design

  30. B. Software Architecture - 5 Model Driven Architecture (MDA) Primary goals of MDA • Portability • Interoperability • Reusability Using these technologies: Unified Modeling Language (UML) Meta-Object Facility (MOF) XML Meta-Data Interchange (XMI) Common Warehouse Meta-model (CWM) Module III. Software Design

  31. B. Software Architecture - 6 MDA Overview Model-Driven Architecture separates the specification of the operation of a system from the details of the way that system uses the capabilities of its platform. MDA provides an approach for • Specifying a system independently of the platform that supports it • Specifying platforms • Choosing a particular platform for the system • Transforming the system specification into one for a particular platform Module III. Software Design

  32. System Model Model-Driven Architecture Viewpoint View Platform Application Platform Independence Viewpoints Computation Independent Model (CIM) Platform Independent Model (PIM) Platform Specific Model (PSM) Platform Model Model Transformation Pervasive Services Implementation B. Software Architecture - 7 Key Model Driven Architecture Concepts Module III. Software Design

  33. B. Software Architecture - 8 Definition of System: A collection of elements that are organized to work together to accomplish some goal Module III. Software Design

  34. B. Software Architecture - 9 Model • A model is a representation of a system • Often a combination of drawings and text • The text may be in terms of • A modeling language • Natural language • Another Definition of model: A collection of views where each view describes a system from a particular perspective Module III. Software Design

  35. B. Software Architecture - 10 Model Driven An approach to system and software specification that focuses on the evolution of one or more models, where each model describes some relevant aspect of the system Benefits: • Facilitates communication • Reduces complexity Module III. Software Design

  36. B. Software Architecture - 11 Viewpoints & Views Viewpoint Technique for abstraction using a selected set of architectural concepts and structuring rules View A perspective of a system from a point of view of a viewpoint MDA prescribes 3 types of viewpoints • Computation independent • Platform independent • Platform specific Module III. Software Design

  37. B. Software Architecture - 12 Platform A platform is a set of subsystems and technologies Provides a coherent set of functionality through • Interfaces • Usage patterns Any application supported by that platform can use without concern for the details of how the functionality provided by the platform is implemented Examples: • J2EE • Microsoft Windows • Linux Module III. Software Design

  38. B. Software Architecture - 13 Platform Independence • Quality of a model • Not specific for a particular platform • Able to be implemented on any number of platforms, as appropriate CORBA J2EE A platform independent distributed messaging model could be implemented, for example, on either CORBA or J2EE Module III. Software Design

  39. B. Software Architecture - 14 Computation Independent Model (CIM) • View of the system independent of the system structure • Also known as a domain model • Terminology familiar to those in the application’s domain • Bridges the gap between domain experts and design experts • Facilitates clear specification of the problem domain VS. Module III. Software Design

  40. B. Software Architecture - 15 Platform Independent Model (PIM) • More specific than a Computational Independent Model • Less specific that a Platform Dependent Model • Details of the implementation on a particular platform are omitted • Could be implemented on multiple platforms VS. Module III. Software Design

  41. B. Software Architecture - 16 • Platform Specific Model (PSM) • More specific than a Platform Independent Model • Details of the implementation on a particular platform are provided • An implementation on a specific platform VS. Module III. Software Design

  42. B. Software Architecture - 17 Model Transformation Process by which one model is converted to another model in the same system Software examples: Computation Independent Model to a Platform Independent Model Platform Independent Model to a Platform Specific Model Analysis model to a design model An implementation model to a deployment model Module III. Software Design

  43. B. Software Architecture - 18 MDA prescribes a series of model transformations CIM to PIM to PSM CIM PIM PSM Use Cases Analysis Classes Enterprise Java Beans Module III. Software Design

  44. B. Software Architecture - 19 Manual vs. Automatic Transformations • Manual transformations are the traditional approach • Design decisions are made • Design is implemented • Low automation in most cases • Component-based development is an improvement • Canned, off-the-shelf middleware is common today • IBM Websphere • Microsoft .NET • Application frameworks are also available • Struts • Java Server Faces • Some tools available today can automate transformations • Generate executable applications via the PIM • E.g. Rational Rose Technical Developer, Telelogic TAU Module III. Software Design

  45. 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

  46. B. Quiz - 1 Architecture design deals with components and a) their interfaces b) class structures c) their relationships 1) a 2) a & b 3) a & c 4) b & c Module III. Software Design

  47. B. Quiz - 2 Model Driven Architecture is an approach to specifying architecture that uses: a) Platform independent models b) Platform specific models c) Computation independent viewpoints d) Model transformations • a & b • a, b, & d • d • all of the above Module III. Software Design

  48. B. Quiz – 3 A use case model is an example of a: • Computational independent model • Platform independent model • Platform specific model • a • b • c Module III. Software Design

  49. B. Quiz – 4 An architect is concerned about the system’s: a.) quality b.) usability c.) performance d.) maintainability 1.) all of the above 2.) a & d 3.) b, c & d 4.) c & d Module III. Software Design

  50. B. Quiz - 5 It is the responsibility of the architect to ensure the component interfaces are used in the manner intended. 1.) True 2.) False Module III. Software Design

More Related