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.
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.
Back to Home page MANAGING STANDARDS
Home page
Please send any
beneficial comments or identification of errors using the following form to: kenr@wysywig.airtime.co.uk
Copyright © Ken Rigby 2003,
2004