A software engineering methodology typically comprises a process and a modelling language. The process describes how to create or engineer the design, the modelling language shall be used to define and describe it.
The Object-Orientated Software Engineering (OOSE) process shall define the overall standard process or method for the development of the system and the comprising CSCIs and Software Units for projects. The Unified Modelling Language (UML) shall be used as the notation for the models being developed for the projects.
This document aims to provide an overall description of the OOSE process that shall be used as the generic process for engineering the software for the projects. The OOSE process does not define the detail process; the specific software project manager shall define a detailed procedure that is in consonance with the OOSE process. UML shall be used for the notation of the various models or diagrams. However, as UML allows such a wide range of constructs; a level of streamlining will have to be applied to define the preferred usage for the various types of software.
The object-oriented modelling process is based on the development of many interrelated models, diagrams, artefacts, documents, and prototypes that describe all or part of an application from a specific point of view or perspective. It is recognized that different personnel create or engineer using different design styles. This document defines the requirement for process 'blueprints' or 'schematics' for an architecture-driven modelling process for developing object-oriented applications.
The process blueprints shall be the reusable building blocks from which an organization or project may tailor an object-oriented software engineering (OOSE) process that meets its unique needs.
It is important to understand that no one single model captures the entirety of an application. A class diagram shows the static relationships between classes whereas sequence diagrams show the dynamic interactions between objects. User interface prototypes model the design of screens and reports whereas use cases model the user requirements for an application. Different models produce different points of view or perceptions and careful consideration is needed when deciding on which models to use. Successful object-oriented (OO) modelling depends on understanding each model, when each model should and shouldn't be used, how each model relates to the other models, and how to approach the modelling process for large-scale, and/or mission/safety/security-critical projects.
The Object-Orientated Software Engineering (OOSE) process shall define the overall standard process or method for the development of the system and the comprising CSCIs and Software Units for projects. The Unified Modelling Language (UML) shall be used as the notation for the models being developed for the projects.
This document aims to provide an overall description of the OOSE process that shall be used as the generic process for engineering the software for the projects. The OOSE process does not define the detail process; the specific software project manager shall define a detailed procedure that is in consonance with the OOSE process. UML shall be used for the notation of the various models or diagrams. However, as UML allows such a wide range of constructs; a level of streamlining will have to be applied to define the preferred usage for the various types of software.
The object-oriented modelling process is based on the development of many interrelated models, diagrams, artefacts, documents, and prototypes that describe all or part of an application from a specific point of view or perspective. It is recognized that different personnel create or engineer using different design styles. This document defines the requirement for process 'blueprints' or 'schematics' for an architecture-driven modelling process for developing object-oriented applications.
The process blueprints shall be the reusable building blocks from which an organization or project may tailor an object-oriented software engineering (OOSE) process that meets its unique needs.
It is important to understand that no one single model captures the entirety of an application. A class diagram shows the static relationships between classes whereas sequence diagrams show the dynamic interactions between objects. User interface prototypes model the design of screens and reports whereas use cases model the user requirements for an application. Different models produce different points of view or perceptions and careful consideration is needed when deciding on which models to use. Successful object-oriented (OO) modelling depends on understanding each model, when each model should and shouldn't be used, how each model relates to the other models, and how to approach the modelling process for large-scale, and/or mission/safety/security-critical projects.
Guidance on the completion of the MIL-STD-498 Data Item Descriptions (DIDs) with regard to the Object-Oriented methodology is provided in the Appendix A. Guidance on the design requirements for compliance with MIL-STD-498 are provided in the Appendices.
