Presentation is loading. Please wait.

Presentation is loading. Please wait.

This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department.

Similar presentations


Presentation on theme: "This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department."— Presentation transcript:

1 This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department of Defense © 2005 by Carnegie Mellon University February 2005 Pittsburgh, PA 15213-3890 PSP II - Software Design - 1 Personal Software Process for Engineers: Part II Software Design SM

2 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 2 Lecture Topics The design framework Design completeness The PSP design templates operational specification functional specification state specification logic specification The design hierarchy UML and the PSP

3 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 3 Design is a Learning Process Design involves discovery, invention, and intuitive leaps from one abstraction level to another. While the design must reflect the requirements, requirements usually are not stable until the product has been used, if then. Design work is iterative, and it must be driven by feedback from all involved parties. The critical problem is knowing when to freeze the design to produce the next iteration.

4 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 4 The Design Framework Initial requirements Completed design Gather data on user requirements Analyze the requirements data Conceive of a high-level design Refine and document the design Validate the design against the requirements Obtain answers to requirements questions

5 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 5 Development Framework Design Unit test Integration test System test Acceptance Use User Requirements Implementation

6 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 6 Design Quality Design is a defect prevention activity. Poor quality designs are a major source of rework, maintenance, and user dissatisfaction. A quality design is complete and precise meets the user’s needs precisely guides implementation

7 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 7 Design Levels Design work is an inverted pyramid in which each level provides a foundation for the following levels debugs the preceding levels To save time and prevent defects, document all design decisions at all levels when they are made. Implementation Detailed design High-level design Conceptual design Requirements specification

8 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 8 Structuring the Design Process Good software designers follow a dynamic process. They jump from concept to detail simultaneously consider issues at several design levels explore multiple alternatives A structured design process can help you to manage the dynamics of design. capture what has been learned record and manage issues track design status A properly-implemented design process will reduce rework, manage routine tasks, and give the designer the freedom to be creative.

9 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 9 Requirements definition System specification System high-level design Product N specification Product N high-level design Product 1 specification Product 1 high-level design Component 1-1 specification Component 1-1 high-level design Component 1-n specification Component 1-n high-level design - - - - - - - - - - - Module 1nk specification - - - - - - - - - - Module 1n1 specification Module 1n1 detailed design Module 1nk detailed design - - - - - - - - - - - The Design Hierarchy

10 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 10 The PSP Design Process Since there is no single best design method, the PSP supports multiple methods. The PSP focuses on what a complete design should contain. The goal is to eliminate requirements and design defects. The PSP uses design templates to provide criteria for design completeness reviewable designs

11 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 11 Design Completeness Under-specified and incomplete designs are expensive and error-prone. Designs can be over-specified, especially when they are produced without completeness criteria. In the PSP course, most students find that their designs are incomplete and do not adequately guide implementation. To avoid over- or under-specification examine your defect data establish design completeness criteria focus on design quality

12 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 12 Users of Design Information The principal users of the design are implementers design reviewers and verifiers testers and test developers documenters, maintainers, and enhancers These users potentially need a large amount of material. Not all information is needed immediately. Some information can be obtained from other sources. It is wise to limit the design workload as much as possible.

13 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 13 Essential Design Information The information that designers should provide includes a picture of where the program fits into the system a description of how the program will be used a specification for all related classes and parts a structural view of the product a specification of all external calls and references a list of all external variables, parameters, and constants a clear statement of the program’s logic The essential design information can be categorized into static or dynamic views, and internal or external views.

14 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 14 Design Views StaticDynamic Internal External Structure (attributes, constraints) Functions (inheritance, class structure) Interactions (services, messages) Behavior (state machine)

15 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 15 Design Templates Four design templates are used in the PSP to cover the four design views. operational specification template functional specification template state specification template logic specification template These four templates provide the framework for completely and precisely recording a software design.

16 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 16 Mapping Templates to Views StaticDynamic Internal External Operational and functional specification templates Functional specification template State specification template Logic specification template

17 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 17 Operational Template The operational specification template describes the users’ normal and abnormal interactions with the system. It contains the principal user actions and system responses anticipated error and recovery conditions The operational specification template can be used to define test scenarios and test cases resolve development questions about operational issues resolve requirements discussions with users DS E I

18 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 18 Example Operational Template DS E I

19 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 19 Operational Template Exercise For this exercise, produce an operational specification template for the stopwatch. The scenario objective is to test the stopwatch. Pair up and take 20 minutes to produce an operational specification template for the stopwatch. 20 minutes DS E I

20 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 20 Exercise Discussion Producing the operational template exposes some requirements questions. When the stopwatch is running, what happens if the hold button is pushed twice? The requirements statement could be read several ways. With the subsequent holds, the display could show either the timer value or more lap times. Precise designs often expose questions that must be resolved by talking to the user. DS E I

21 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 21 Exercise Operational Template DS E I

22 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 22 Functional Template The functional specification template allows you to unambiguously define the external functions provided by the product. classes and inheritance externally visible attributes external functions provided relationships with other classes or parts Where possible, specify the behavior of each function or method with a formal notation. DS E I

23 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 23 Example Functional Template DS E I

24 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 24 Producing the Functional Template To produce a functional template, you must decide how to build the product define the product’s functions define the key product attributes The functional specification is usually developed in steps. Produce an initial design. Refine the elements of that design. Revise the functional specification template as you better understand how to build the product. DS E I

25 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 25 Functional Template Exercise For this exercise, produce a functional specification template for the stopwatch. The objective is to specify the principal stopwatch elements and define their functions. Pair up and take 20 minutes to produce a functional specification template for the stopwatch. 20 minutes DS E I

26 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 26 Exercise Functional Template DS E I

27 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 27 State Specification Template The state specification template precisely defines the program’s states and the transitions among them. This template was described in the lecture on Designing and Verifying State Machines. DS E I

28 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 28 Logic Specification Template -1 The logic specification template precisely defines the program’s internal logic. Its objective is to describe the logic in a concise and convenient notation. A pseudocode compatible with the implementation language is often appropriate. Formal notation is also appropriate. Both the designers and the implementers must be familiar with the notation used. DS E I

29 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 29 Logic Specification Template -2 The logic specification template should specify the logic for each item or method, each part and class, and the overall program the precise call to each program, part, or method any external references special data types and data definitions DS E I

30 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 30 Example Logic Template DS E I

31 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 31 Using Pseudocode In producing pseudocode designs use spoken language where possible, avoid programming constructs where unavoidable, use constructs from the implementation language where the program’s action is clear, make a brief note be more specific about complex constructs, loops, and state-machine structures Consider writing the pseudocode in your development environment. Later, when implementing the program, include the pseudocode in the comments. DS E I

32 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 32 Logic Template Exercise For this exercise, produce a logic specification template for the stopwatch. The objective is to define the logic of the stopwatch program. Pair up and take 20 minutes to produce a logic specification template for the stopwatch. 20 minutes DS E I

33 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 33 Logic Template Discussion Although the stopwatch logic template is relatively simple, it involves more functions than you might expect. With such simple programs, it is important to be completely clear and consistent. Check the operational, functional, state, and logic templates to ensure that they are completely consistent. DS E I

34 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 34 Exercise Logic Template DS E I

35 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 35 Using Design Templates The PSP design templates provide one way to represent a design. They are precise, unambiguous, non-redundant, and complete. Use the PSP design templates in conjunction with your other design methods. Other representations may be substituted if they are equally precise, unambiguous, non-redundant, and complete.

36 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 36 Design Guidelines When designing large programs, use a dynamic design strategy that allows for uncertainty. Some design problems cannot be resolved without first building and testing a potential solution. For these cases, use prototyping. When modifying or enhancing an existing system without a documented design, use the design templates to record the design as you decipher it.

37 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 37 The Design Hierarchy You can use the design templates to refine the specification and design of large or small software products. system program component module Starting with requirements, produce a set of design templates to describe the highest-level product. Use these design templates as the requirements for producing the design templates for the next product level.

38 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 38 Program Design Logic specification State specification Functional specification Operational scenario Module requirements: what the program needs Program requirements: what the user needs Program specifications: what the program does High-level design: how the program works

39 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 39 Logic specification State specification Functional specification Operational scenario Module source code Module requirements: what the program needs Module specifications: what the module does Detailed design: how the module works Module Design

40 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 40 UML and the PSP -1 The Unified Modeling Language (UML) provides a graphical notation for describing software system behavior. UML is based on notations developed by Booch, Rumbaugh, and Jacobson. Standardization by the Object Management Group (OMG) has led to UML’s widespread acceptance. Since UML has many formats and methods, users typically work with (small) UML subsets.

41 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 41 UML and the PSP -2 UML and the PSP templates are complementary. UML covers the logical and physical construction of a software system. The PSP templates focus on precise descriptions of interfaces and system and component behavior. OCL (Object Constraint Language) is being developed to augment UML with a precise language for describing behavior. It is not yet widely used.

42 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 42 Mapping UML and PSP Views StaticDynamic Internal External Use cases and sequence diagrams Class diagrams Statechart diagrams Class and method specifications

43 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 43 Use Cases Use-case diagrams link actors (external agents) with use cases. Each use case describes a unit of functionality and is documented in text. (UML does not define a format.) A use case describes sequences of normal and abnormal interactions among actors and the system. A use-case description is an external perspective, with the system viewed as a “black box.” UML activity diagrams can also describe usage details. DS E I

44 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 44 Use-Case Diagram DS E I Student Mean&Std.Deviation

45 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 45 Use-Case Description Example DS E I

46 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 46 Sequence Diagrams Sequence diagrams map the use case actions to the sequence of messages between objects and actors. Sequence diagrams also specify the dynamic interactions among objects within a system. Sequence diagrams describe the time ordering of the interactions. UML also provides collaboration diagrams which describe the structural interconnections among objects. DS E I

47 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 47 Sequence Diagram Example DS E I

48 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 48 Class Diagrams UML class diagrams describe the static relationships between a system and its classes, including associations and inheritance. UML class diagrams also specify the methods and attributes of the class and the class external interfaces. DS E I

49 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 49 Class Diagram Example DS E I

50 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 50 Statechart Diagrams The UML statechart diagram describes all states that an object can have and the events that cause state transitions. A statechart diagram identifies the states associated with an object its transitions (how an object changes state) its activities (what an object does in a state) DS E I

51 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 51 Statechart Diagram Example DS E I

52 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 52 High-level Design Using UML Sequence diagrams Statechart diagrams (Abstract) Class diagrams Use Cases Module requirements: what the program needs Program requirements: what the user needs Program specifications: what the program does High-level design: how the program works

53 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 53 Logic specification Statechart diagrams Class diagrams Sequence diagrams Module source code Module requirements: what the program needs Module specifications: what the module does Detailed design: how the module works Detail-level Design Using UML

54 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 54 UML and the PSP Templates -1 The UML use case and sequence diagrams provide the same information as the PSP operational specification template. UML class and sequence diagrams provide relationship and interaction information that is not captured in the PSP templates. UML class diagrams record the method signature, but the behavioral specification should be documented with the PSP functional specification.

55 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 55 UML and the PSP Templates -2 The PSP logic specification template has no UML equivalent, so it should be used to record program logic. The statechart and state diagram are equivalent. UML does not have an equivalent to the state specification template. In designing state machines with UML, record the finished design on the state specification template.

56 © 2005 by Carnegie Mellon UniversityFebruary 2005PSP II - Software Design - 56 Messages to Remember While design is a creative process, its routine aspects can be defined. A good design notation will reduce design defects. Using precise design specifications and formats will improve design quality. Use the PSP design templates in the course exercises, and whenever you can do so in your work. UML provides design information that is not in the PSP templates, and the templates have design information that is not shown with the current UML methods.


Download ppt "This material is approved for public release. Distribution is limited by the Software Engineering Institute to attendees. Sponsored by the U.S. Department."

Similar presentations


Ads by Google