VISHWAKARMA INSTITUTE OF TECHNOLOGY, PUNE
Home assignment of Software Engineering Guided by
Prof. Swati Jadhav
Roll Number
Name
GR Number
14 Devendra Natekar 12010669
15 Poonam Nayakodi 12011279
16 Neha Raut 12010255
19 Omkar Jahagirdar 12011016
Case Study on COMET- Software Modelling and Design Method
The software modeling and design method described in this case study are called COMET (Collaborative Object Modeling and Architectural Design Method), which uses the UML notation.
INTRODUCTION
The COMET use case-based software life cycle model is a highly iterative software development process centred on the concept of use cases. The functional needs of the system are expressed in terms of actors and use cases in the requirements model. A sequence of interactions between one or more actors and the system is defined by each use case. The use case is implemented in the analysis model to explain the objects involved in the use case and their interactions. The software architecture is defined in the design model, which describes components and their interactions. The COMET use case-based software life cycle model is shown here in its entirety. COMET's life cycle is very iterative. The COMET method ties in the three phases of requirements, analysis, and design modeling by means of a use case-based approach.
REQUIREMENTS MODELLING
A requirements model is created during the requirements modelling phase, in which the system's functional requirements are expressed in terms of actors and use cases. Each use case is given a narrative description. This effort requires user feedback and active participation. If the needs are unclear, a throwaway prototype can be created to aid in the clarification of the requirements.
ANALYSIS MODELLING
The static and dynamic models of the system are built during the analysis modelling phase. The structural links among problem domain classes are defined by the static model. Class diagrams represent the classes and their relationships. The items to be considered for the analysis model are determined using object structuring criteria. The use cases from the requirements model are then implemented in a dynamic model to demonstrate the objects that participate in each use case and how they interact with one another. Communication diagrams and sequence diagrams are used to depict objects and their interactions. State-dependent objects are defined using state charts in the dynamic model.
DESIGN MODELLING
The software architecture of the system is built during the design modelling phase, and the analytical model is transferred to an operational environment. The problem domain is emphasised in the analysis model, which is transferred to the solution domain in the design model. Subsystem structuring criteria are used to divide the system into subsystems, which are then grouped together as aggregate or composite objects. Designing distributed subsystems as adjustable components that communicate with one another via messages receives special attention. After that, each subsystem is designed. The object-oriented ideas of information hiding, classes, and inheritance are emphasised for sequential systems. Concurrent tasking must be considered while designing concurrent systems such as real-time, client/server, and distributed applications.
INCREMENTAL SOFTWARE CONSTRUCTION
Following the completion of the software architecture design, the programme is built incrementally. This method works by selecting a portion of the system to build for each increment. The subset is determined by selecting the use cases and objects that participate in these use cases to be included in this increment. The precise design, coding, and unit testing of the classes in the subset are all part of incremental software building. This is a phased technique in which the software is built and integrated one step at a time until the entire system is complete.
INCREMENTAL SOFTWARE INTEGRATION
Each software increment is tested for integration during incremental software integration. The increment's integration test is based on the use cases chosen for the increment. Each use case has its own set of integration test cases. Integration testing is a type of white-box testing that involves verifying the interfaces between the items involved in each use case. An incremental prototype is formed by each software increment. Iterating through the incremental software creation and incremental software integration phases when the software increment is considered to be satisfactory results in the construction and integration of the following increment. Iteration through the requirements modelling, analysis modelling, and design modelling phases may be necessary if major problems are discovered in the software increment.
SOFTWARE TESTING
The functional testing of the system — that is, testing the system against its functional requirements – is included in system testing. This testing is done in a black-box environment and is based on black-box use scenarios. As a result, functional test cases for each black box use case are created. The system testing step must be completed before any software increment is provided to the customer.
COMPARISON OF THE COMET LIFE CYCLE WITH OTHER SOFTWARE PROCESSES
The COMET life cycle is compared to the Unified Software Development Process (USDP) and the spiral model in this section. The COMET approach can be combined with the USDP or spiral models.
Comparison of COMET life cycle with Unified Software Development Process
The USDP goes into great detail about the life cycle aspects as well as the approach that will be used. The COMET technique is USDP-compatible. The USDP workflows include requirements, analysis, design, implementation, and testing. The USDP workflow corresponds to each phase of the COMET life cycle. The first three phases of COMET have the same names as the first three workflows of the USDP, which is not surprising given that Jacobson's prior work heavily affected the COMET life cycle (Jacobson 1992). The USDP implementation workflow relates to the COMET incremental software creation activity. COMET's incremental software integration and system testing phases correspond to USDP's test procedure.
Comparison of the COMET Life Cycle with the Spiral Model
The spiral model can also be employed with the COMET approach (Boehm 1988). The project manager selects what precise technical activity should be conducted in the third quadrant, which is the product development quadrant, during project planning for a given cycle of the spiral model. In the third quadrant, the chosen technical activity, such as requirements modelling, analysis modelling, or design modelling, is carried out. The risk analysis activity in the second quadrant, as well as cycle planning in the fourth quadrant, define the number of iterations required for each of the technical tasks.
Requirements, Analysis, and Design Modeling
Requirements, analysis, and design concepts are all supported by the UML notation. The COMET approach described here divides activities into three categories: requirements, analysis, and design. It should be mentioned that in order to completely describe the software architecture, the UML models must be complemented with extra information.
Requirements modelling is the process of defining the system's functional and nonfunctional requirements. COMET distinguishes analysis from design by stating that analysis is the process of breaking down or decomposing an issue in order to better understand it, whereas design is the process of synthesising or composing a solution.
Activities in Requirements Modeling
In the requirements model, the system is considered as a black box. The use case model is developed.
■ Use case modeling. Define actors and use cases in the black box. The system's functional requirements are broken down into use cases and actors. The use case descriptions provide a behavioural perspective, while the relationships between the use cases provide a structural perspective.
■ Nonfunctional requirements must also be addressed during the requirements phase. This is not addressed in the UML notation. Nonfunctional needs can, however, be addressed using the use case modelling approach.
Activities in Analysis Modeling
The focus of the analysis model is on comprehending the problem; as a result, the focus is on identifying the problem domain objects and the data exchanged between them. Design time is used to decide whether the object is active or passive, whether the message transmitted is asynchronous or synchronous, and what operation is invoked at the receiving object. The problem domain analysis is taken into account in the analysis model. The following are the activities:
■ Static modeling. Define a static model that is specific to the problem. This is a graphical representation of the data in the system. The attributes of classes, as well as their relationships with other classes, are used to define them. The design model specifies the operations. This perspective is critical for information-intensive systems. The emphasis in the issue domain is on information modelling of real-world classes.
■ Object structuring. Figure out which items are involved in each use case. Entity objects, boundary objects, control objects, and application logic objects are all examples of software objects that can be determined using object structuring criteria.
■ Dynamic interaction modeling.The use cases are created to demonstrate the interaction between the objects involved in each use case. Communication diagrams, also known as sequence diagrams, are used to demonstrate how objects interact with one another to carry out the use case. The stateless dynamic modelling technique, which includes the dynamic interaction modelling approach, is used to determine how objects interact with one another to enable use cases. The interaction between state-dependent control objects and the statecharts they execute is explicitly modelled in state-dependent dynamic interaction modelling.
■ Dynamic state machine modeling. Hierarchical statecharts are used to define the system's state-dependent perspective. Each state-dependent object is specified in terms of the statecharts that make it up.
Activities in Design Modeling
In the design model, the solution domain is considered. During this phase, the analysis model is mapped to a concurrent design model. For designing software architectures, the following activities are performed:
■ Integrate the object communication model. Develop integrated object communication diagrams.
■ Make decisions about subsystem structure and interfaces. Develop the overall software architecture. Structure the application into subsystems.
■ Make decisions about what software architectural and design patterns to use in the software architecture.
■ Make class interface decisions, especially for sequential software architectures. Create information concealing classes for each subsystem. Create each class's operations as well as the parameters for each operation.
■ Make decisions about how to divide the distributed application into distributed subsystems, each of which is intended as a configurable component, and the message communication interfaces that connect the subsystems.
■ Make choices concerning object properties, such as whether they are active or passive. Divide the system into concurrent jobs for each subsystem (active objects). Tasks are structured using task-structuring criteria, and task interfaces are specified during task structuring.
■ Make choices concerning message characteristics, such as whether they are asynchronous or synchronous (with or without reply). At several stages of the analysis and design process, COMET stresses the usage of structural criteria. Concurrent object structuring criteria are used to help determine the concurrent (active) objects in the system. subsystem structuring criteria are used to help determine the subsystems To clearly demonstrate the use of the structuring requirements, UML stereotypes are utilised throughout.
Designing Software Architectures
During software design modelling, design decisions are made based on the software architecture's characteristics. The design of many types of software architectures is described in the chapters of this textbook's design modelling section:
Object-Oriented Software Architectures are a subset of Object-Oriented Software Architectures. The ideas of information hiding, classes, and inheritance are all part of object-oriented design.
Client/Server Software Architectures are a type of software architecture that consists of a client and a server. A typical setup consists of a single server and a number of clients.
Service-Oriented Architectures are a type of architecture that is based on the concept of a service. the creation of service-oriented architectures, which are made up of a number of distributed autonomous services that can be combined to form distributed software applications.
Distributed Components Software Architectures Based on Distributed Components. the creation of component-based software architectures that may run on distributed platforms in a distributed configuration
Real-Time Software Architectures are a type of software that runs in real time. the creation of real-time software architectures, which are frequently concurrent systems.
SUMMARY
The COMET use case-based software life cycle for the creation of UML-based object-oriented software applications was presented in this case study. The COMET life cycle was compared to the USDP and the spiral model, and it was explained how the COMET approach may be employed with either the USDP or the spiral model. It also explained the COMET method's primary actions and concluded with a description of how to use COMET. Systems modeling can be done before software modeling in software-intensive systems where the software is one component of a broader hardware/software system.