Analysis and Design Overview

Last updated: Mar. 22, 2006

Objectives:

• Review the key Analysis and Design terms and concepts

• Introduce the Analysis and Design process, including roles, artifacts and workflow

• Explain the difference between Analysis and Design

Analysis and Design in Context:

• The Requirements Discipline provides the primary input for Analysis and Design.

• The purposes of Analysis and Design are to:

  • Transform the requirements into a system design.

  • Evolve a robust architecture for the system.

  • Adapt the design to match the implementation environment, designing it for performance.

Analysis and Design Overview:

• The result of Analysis and Design is a Design Model that serves as an abstraction of the source code; that is, the Design Model acts as a blueprint of how the source code is structured and written. The Design Model consists of design classes structured into design packages; it also contains descriptions of how objects of these design classes collaborate to perform use cases (use-case realizations.)

• The design activities are centered around the notion of architecture. The production and validation of this architecture is the main focus of early design iterations.

• Architecture is represented by a number of architectural views that capture the major structural design decisions. In essence, architectural views are abstractions or simplifications of the entire design, in which important characteristics are made more visible by leaving details aside. The architecture is an important vehicle not only for developing a good Design Model, but also for increasing the quality of any model built during system development. The architecture is documented in the Architecture Document.

Analysis versus Design:

• The goal in Analysis is to understand the problem and to begin to develop a visual model of what you are trying to build, independent of implementation and technology concerns. Analysis focuses on translation the functional requirements into software concepts. The idea is to get a rough cut at the objects that comprise our system, but focusing on behavior  (and therefore encapsulation). We then move very quickly, nearly seamlessly, into "Design" and the other concerns.

• A goal of Design is to refine the model with the intention of developing a Design Model that will allow a seamless transition to the coding phase. In design, we adapt to the implementation and the deployment environment. The implementation environments is the "developer" environment, which is a software superset and a hardware subset of the deployment environment.

Analysis and Design Are Not Top-Down or Bottom-Up:

• Analysis is both top-to-middle, middle-up, middle-down and bottom-to-middle. There is no way of saying that one path is more important than another－you have to ravel on all paths to get the system right. All of these four paths are equally important. That is why the bottom-up and top-down question cannot be solved.

What Is Architecture?

• Software architecture encompasses a set of significant decisions about the organization of a software system.

  • Selection of the structural elements and their interfaces by which a system is composed

  • Behavior as specified in collaborations among those elements

  • Composition of these structural and behavioral elements into larger subsystems

  • Architectural style that guides this organization

• An equation we have used is :

  Architecture = Elements + Form + Rationale

  • Rationale is essential for justifying a good architecture.

  • Patterns are the guidelines for assembling elements in some form.

Architecture Constrains Design and Implementation:

• Architecture involves a set of strategic design decisions, rules or patterns that constrain design and construction.

• Architecture decisions are the most fundamental decisions, and changing them will have significant effects.

Software Architecture: The "4+1 View" Model

• Not all system require all views (for example, single processor: drop Deployment View; single process: drop Process View; small program: drop Implementation View, and so fourth). A project may document all of these views or additional views. The number of views is dependent on the system you are building.

Analysis and Design workflow:

• The early Elaboration phase focuses on creating an initial architecture for the system (Define a Candidate Architecture) to provide a starting point for the main analysis work. If the architecture already exists (because it was produced in previous iterations, or projects, or is obtained from an application framework), the focus of the work changes to reining the architecture (Refine the Architecture), analyzing behavior, and creating an initial set of elements that provide the appropriate  behavior (Analyze Behavior).

• After the initial elements are identified, they are further refined. Design Components produce a set of components that provide the appropriate behavior so satisfy the requirements on the system. In parallel with these activities, persistence issues are handled in Design the Database. The result is an initial set of components that are further refined in the Implementation Discipline.

Analysis and Design Activity Overview:

• The design activities are centered around the notion of architecture. The production and validation of this architecture are the main focal points of early design iterations.

• The focus of this course is on the activities of the designer.

Software Architect's Responsibilities:

• The software architect role leads and coordinates technical activities and artifacts throughout the project.

• The software architect establishes the overall structure for each architectural view: the decomposition of the view, the grouping of elements, and the interfaces between these major groupings. Therefore, in contrast to the other roles, the software architect's view is one of breadth as opposed to one of depth.

• The software architect, or members of the architecture team, must combine these skills:.

  • Experience in both the problem domain, through a thorough understanding of the requirements, and the software engineering domain

  • Leadership in order to drive the technical effort across the various teams, and to make critical decision under pressure and make those decision stick. To be effective, the software architect and the project manager must work closely together, with the software architect leading the technical issues and the project manager leading the administrative issues. The software architect must have the authority to make technical decisions.

  • Communication to earn trust, to persuade, to motivate, and to mentor. The software architect cannot lead by decree－ only by the consent of the rest of the project. In order to be effective, the software architect must earn the respect of the project team, the project manager, the customer, and the user community, as well as the management team.

  • Goal orientation and being proactive with a relentless focus on results. The software architect is the technical driving force behind the project, not a visionary or dreamer. The career of a successful software architect is a long series of sub-optimal decisions made in uncertainty and under pressure. Only those who can focus on doing what needs to be done are successful in this environment of the project.

  　

Designer's Responsibilities:

• The designer role defines the responsibilities, operations, attributes, and relationships of one or several classes, and determines how they are adjusted to the implementation environment. In addition, the designer role may have responsibility for one or more classes, including analysis, design, subsystem, or testability.

• The designer must have a solid working knowledge of:

  • Use-case modeling techniques

  • System requirements

  • Software design techniques, including object-oriented Analysis and Design techniques, and the Unified Modeling Language

  • Technologies with which the system will be implemented

  • Understand the architecture of the system. as represented in the software Architecture Document.

Analysis and Design is Use-Case Driven:

• Use cases defined for a system are the basis for the entire development process.

• Benefits of use cases:

  • Concise, simple, and understandable by a wide range of stakeholders.

  • Help synchronize the content of different models.

What Is a Use-Case realization?

• A use-case realization describes how a particular use case is realized within the design Model, in terms of collaboration objects. A use-case realization ties together the use cases from the Use-Case Model with the classes and relationships of the Design Model. A use-case realization specifies what classes must be built to implement each use case.

• In the UML, use-case realizations are stereotyped collaborations. The symbol for a collaboration is an ellipsis containing the name of the collaboration. The symbol for a use-case realization is a dotted line version of the collaboration symbol.

• The number and types of the diagrams that are used depend on what is needed to provide a complete picture of the collaboration and the guidelines developed for the project under development.

Analysis and Design in an Iterative process: