- Software Reuse
- Software Product Lines
- Modeling Requirements Variability in Software Product Lines: Feature Modeling
- Modeling Design Variability in Software Product Lines
- Reusable Design Patterns
- Modeling Single Systems with UML
- COMET: A UML-Based Software Design Method for Single Systems
- Modeling Software Product Lines with UML
- UML as a Standard
- Related Texts
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
1.7 COMET: A UML-Based Software Design Method for Single Systems
An example of a UML-based software design method for single systems is COMET (Concurrent Object Modeling and Architectural Design Method), which is described in Gomaa 2000. COMET is a highly iterative object-oriented software development method that addresses the requirements, analysis, and design modeling phases of the object-oriented development life cycle. The functional requirements of the system are defined in terms of actors and use cases. Each use case defines a sequence of interactions between one or more actors and the system. A use case can be viewed at various levels of detail. In a requirements model, the functional requirements of the system are defined in terms of actors and use cases. In an analysis model, the use case is realized to describe the objects that participate in the use case, and their interactions. In the design model, the software architecture is developed, addressing issues of distribution, concurrency, and information hiding. Sections 1.7.1 through 1.7.3 discuss each of these phases of object-oriented development.
1.7.1 Requirements Modeling
During the requirements modeling phase, a requirements model is developed in which the functional requirements of the system are defined in terms of actors and use cases. A narrative description of each use case is developed. User inputs and active participation are essential to this effort. If the requirements are not well understood, a throwaway prototype can be developed to help clarify the requirements.
1.7.2 Analysis Modeling
In the analysis modeling phase, static and dynamic models of the system are developed. The static model defines the structural relationships among problem domain classes. The classes and their relationships are depicted on class diagrams. Object-structuring criteria are used to determine which objects should be considered for the analysis model. A dynamic model is then developed in which the use cases from the requirements model are realized to show the objects that participate in each use case and how they interact with each other. Objects and their interactions are depicted on either communication diagrams or sequence diagrams. In the dynamic model, state-dependent objects are defined with statecharts. A statechart is a graphical representation of a finite state machine in the form of a hierarchical state transition diagram.
1.7.3 Design Modeling
In the design modeling phase, the software architecture of the system is designed; that is, the analysis model is mapped to an operational environment. The analysis model (which emphasizes the problem domain) is mapped to the design model (which emphasizes the solution domain). Subsystem structuring criteria are provided to structure the system into subsystems, which are considered as aggregate or composite objects. Special consideration is given to designing distributed subsystems as configurable components that communicate with each other using messages.
Each subsystem is then designed. For sequential systems, the emphasis is on the object-oriented concepts of information hiding, classes, and inheritance. For the design of concurrent systems, such as real-time, client/server, and distributed applications, it is necessary to consider concurrent tasking concepts in addition to object-oriented concepts.