The analysis model

The analysis model describes the structure of the system or application that you are modeling. It consists of class diagrams and sequence diagrams that describe the logical implementation of the functional requirements that you identified in the use case model.

The analysis model identifies the main classes in the system and contains a set of use case realizations that describe how the system will be built. Class diagrams describes the static structure of the system by using stereotypes to model the functional parts of the system. Sequence diagrams realize the use cases by describing the flow of events in the use cases when they are executed. These use case realizations model how the parts of the system interact within the context of a specific use case.

You can think of the analysis model as the foundation of the design model since it describes the logical structure of the system, but not how it will be implemented.

After you identify the use cases for the system or application and capture them in a use case model, the next step in the development process is to build on the use case model by describing the structure of the system. In this phase, you analyze the application domain to discover the domain requirements of the system and create a high-level object model that describes how the system will be logically constructed. You can use class diagrams and sequence diagrams to capture the logical implementation of the functional requirements that you described in the use case model.

A practice is set of techniques for accomplishing a goal. Usually a part of a larger process, a practice addresses one aspect of the software development lifecycle, such as requirements management, use case-driven development, or change management. The process of creating an analysis model is included in the following IBM Practices:

Evolutionary Architecture Practice

The Evolutionary Architecture Practice describes how to analyze the major technical concerns that affect a solution, and capture those architectural decisions to ensure that those decisions are assessed and communicated.

Component-based Software Architecture Practice

The Component-based Software Architecture Practice defines a system's functional architecture by breaking the system up into a number of collaborating components. It focuses on identifying the major abstractions of the system and making decisions on how the system will be built to ensure resilience and maintainability.

Feedback