Presentation is loading. Please wait.

Presentation is loading. Please wait.

Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement.

Similar presentations


Presentation on theme: "Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement."— Presentation transcript:

1 Chapter 10 Analysis and Design Discipline

2 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement the system We must understand requirements and transform them into a system design by selecting the best implementation strategy Early in the project, we must establish a robust architecture so that we can design a system that is easy to understand, build, and evolve. Then we must adjust the design to match implementation environment, designing it for performance, robustness, scalability, and testability, among other qualities.

3 3 Analysis versus Design The purpose of analysis is to transform the requirements of the system into a form that maps well to the software designer's area of concern –That is, to a set of classes and subsystems. Analysis focuses on ensuring that the system's functional requirements are handled. –It ignores many of nonfunctional requirements of the system and also the constraints of the implementation environment. Thus, analysis expresses a nearly ideal picture of system.

4 4 Analysis versus Design (cont.) The purpose of design is to adapt the results of analysis to the constraints imposed by nonfunctional requirements, implementation environment, performance requirements, and so forth. Design is a refinement of analysis. Design focuses on optimizing the system's design while ensuring complete requirements coverage.

5 5 How Far Must Design Go? In some cases, design may be elaborated to the point that system can be implemented through a direct and systematic transformation of the design into code. In other cases, design resembles a sketch, elaborated only to ensure that the implementer can produce a set of components that satisfy the requirements. When design is specified precisely, the code can be tied closely to the design and can be kept synchronized with the design in what we call round-trip engineering.

6 6 Roles and Artifacts Software Architect –leads and coordinates technical activities and artifacts throughout the project. –establishes the overall structure for each architectural view: the decomposition of the view, the grouping of elements, and the interfaces between the major groupings. Designer –defines the responsibilities, operations, attributes, and relationships of one or several classes –determines how they should be adjusted to the implementation environment.

7 7 Roles and Artifacts in Analysis and Design

8 8 Additional Roles Database Designer: –is needed when the system being designed includes a database. Capsule Designer (for real-time systems): –is a kind of designer who focuses on ensuring that the system is able to respond to events in a timely manner through appropriate use of concurrent design techniques. Architecture Reviewer and Design Reviewer: –review the key artifacts produced through this workflow.

9 9 Key Artifacts of Analysis and Design The Design Model: –The major blueprint for the system under construction The Software Architecture Document (SAD): –SAD captures various architectural views of the system

10 10 Designing a User-Centered Interface The expression user-interface design can mean one of at least the two following things: –The visual shaping of the user interface so that it handles various usability requirements –The design of the user interface in terms of design classes (and components such as ActiveX classes and JavaBeans) that is related to other design classes

11 11 The Design Model Generally, there is one design of the system. Design model consists of a set of collaborations of model elements that provide the behavior of the system. This behavior is derived primarily from the use-case model and nonfunctional requirements. Design model consists of collaborations of classes Classes may be grouped into packages and subsystems to help organize model (building blocks within the model).

12 12 The Design Model A class is a description of a set of objects that share responsibilities, relationships, operations, attributes, and semantics. A package is a logical grouping of classes, for organizational purposes, that reduces the complexity of the system. A subsystem is a kind of package consisting of a set of classes that act as a single unit to provide specific behaviors.

13 13 The Analysis Model Analysis produces a rough sketch of the system, which is refined further in design. Systems may live for decades or there are many variants of system - a separate analysis model has proved useful. Analysis model is an abstraction (generalization) of design. It omits most of the details of how the system works and provides an overview of the system's functionality. The extra work required to ensure that the analysis and design models remain consistent

14 14 The Role of Interfaces Interfaces are used to specify behavior offered by classes, subsystems, and components in a way that is independent of the implementation of behavior. They specify –A set of operations performed by the model elements, –The returned type –The number and types of parameters. Interfaces improve the flexibility of designs by reducing dependencies between parts of the system and therefore making them easier to change.

15 15 Component-Based Design Components are elements in implementation model and are used to express the way system is implemented in a set of smaller "chunks." Using components lets us design, implement, deliver, and replace parts of system independently of rest of system. Design model element that corresponds to component is the subsystem: Design may include a data model that expresses the way persistent objects in the system are stored and retrieved. –A data model is useful when underlying database technology imposes.

16 16 Workflow in Analysis and Design

17 17 Define a Candidate Architecture The activities include: –Architectural Analysis, performed by the architect –Use-Case Analysis, performed by the designer Its purposes are to: –Create an initial sketch of the architecture of the system –Identify analysis classes from the architecturally significant use cases. –Update the use-case realizations with analysis class interactions.

18 18 Refine the Architecture Activities include: –Identify Design Mechanisms, –Identify Design Elements, –Incorporate Existing Design Elements, –Describe Runtime Architecture –Describe Distribution The purpose is to: –Provide natural transition from analysis activities to design activities –Maintain the consistency and integrity of the architecture –Describe the organization of the system's runtime and deployment architecture. –Organize the implementation model to make the transition between design and implementation seamless.

19 19 Analyze Behavior Activities include –Use-Case Analysis, performed by the designer –Identify Design Elements,performed by the architect –Review the Design, performed by the design reviewer. The purpose is to: –transform the behavioral descriptions provided by the use cases into a set of elements on which the design can be based. In Analyze Behavior: –We are less concerned with the nonfunctional requirements –Main focus is how to deliver the needed application capabilities.

20 20 Design Components Activities include: –Use-Case Design –Class Design –Subsystem Design, performed by the designer –Review the Design, performed by the design reviewer. The purposes are to: –Refine definitions of design elements by working out the details of how the design elements implement the behavior required of them. –Refine and update use-case realizations based on new design elements introduced, thus keeping use-case realizations up to date. –Review the design as it evolves.

21 21 Design the Database (Optional) Activities include: –Database Design, performed by the database designer, –Class Design, performed by the designer, –Review the Design, performed by the design reviewer. Its purposes are: –Identify the persistent classes in the design. –Design appropriate database structures to store persistent classes. –Define mechanisms and strategies for storing and retrieving persistent data in that the performance criteria for system are met.

22 22 Summary Analysis and design bridge the gap between requirements and implementation. It uses use cases to identify a set of objects that is subsequently refined into classes, subsystems, and packages. Responsibilities in analysis and design are distributed among the roles –Software Architect (the big picture issues) –Designer (the details) –Database Designer (the details that require specialized knowledge about handling persistence). Analysis and design result in a design model, which can be abstracted using three architectural views. –Logical view presents the decomposition of the system into a set of logical elements (classes, subsystems, packages, and collaborations). –Process view maps those elements to the processes and threads in the systems. –Deployment view maps processes to a set of nodes on which they execute.

23 23 Summary (cont.) The design of the user interface proceeds in parallel, resulting in a user-interface prototype. In some cases, a separate analysis model can be useful for presenting an overview or abstraction of the system or to bootstrap the design activities.


Download ppt "Chapter 10 Analysis and Design Discipline. 2 Purpose The purpose is to translate the requirements into a specification that describes how to implement."

Similar presentations


Ads by Google