Several object-oriented software development methodologies are available to project software managers and software developers prior to starting a project. Project software managers and software developers are encouraged to review one or more of them for possible use on their projects. This attachment examines Edward Colbert’s Object-Oriented Software Development (OOSD) (Version 4.0, March 15, 1995) as a sample methodology.
Colbert’s OOSD methodology is presented as a process model with activities that the software developer can use, starting with performing requirements analysis, proceeding to developing an architectural design, and continuing on to developing a unit detailed design, from which code can be written.
The top level activities in the following sample are fully covered in the Software Development Volume of the Guidebook. The activity numbers cited in this attachment matches the activity number in the Software Development Volume.
(See activity 3.2.1.1.2)
Overview
This activity develops the computer software configuration item’s (CSCI) Object-Interaction Specification. This static structure describes the CSCI’’s overall context by identifying external objects and their interactions with the CSCI.
Roles and Responsibilities
The software developer develops the Object-Interaction Specification.
Controls
See parent activity 3.2.1.1.2 Perform Object-Oriented Requirements Analysis.
Inputs
Allocated CSCI requirements, as listed in the MIL-STD-498 System/Subsystem Design Description ( SSDD ) (see Appendix E) (see activity 3.1.2 Define System Design).
Procedures
The Object-Oriented Requirements Analysis (OORA) method described in Colbert’s Object-Oriented Software Development (OOSD) methodology [Colbert, 1995] uses the following four-step, iterative approach to developing the Object-Interaction Specification.
1) The software developer identifies and defines the complex, active CSCI object drawn in the Context Object-Interaction Diagram (OID). The purpose of an OID is to represent the nature and structure of objects. Objects are either active or passive in nature, and interfaces or components structurally. OIDs also represent the interactions (operation requests and flows such as data flow) between objects. A complex object can decompose into other component objects, and an active object can act under its own power. The software developer names the CSCI object with a noun phrase, and completes a Data Dictionary entry (see activity II.1.4 Develop Data Dictionary) for it.
2) The software developer identifies external objects (e.g., hardware devices, other software CSCIs, human users) with which the CSCI communicates. These interfaces should be described in the Interface Design section of the SSDD . External objects receive information from or send information to the CSCI. For interactive CSCIs, a human user is seen as an external object during requirements analysis even though communication may be through a keyboard, mouse, etc. The external objects are then named, added to the Context OID, and recorded in the Data Dictionary (see activity II.1.4 Develop Data Dictionary).
External objects may be either active or passive. Active objects have some degree of self-motivation, and may act on their own power (e.g., an operating system). Passive objects have no self-motivation and never act on their own power (e.g., a database).
3) The software developer defines the nature of each interaction between the CSCI and an external object. An interaction is a request by one object that another object (the called object) perform one of its operations (i.e., operation request); it includes any objects or data exchanged as part of the interaction (e.g., data flow, object flow, and error flow) [Colbert, 1995] .
The Context OID shows only interactions between the CSCI and the external objects. Interactions between external objects are outside the perspective of the CSCI being built, and thus, are not illustrated in the Context OID. The software developer only identifies the operations and flows for individual external objects or sets of external objects from which the CSCI object requests an operation, or receives a request (from).
In most cases, the software developer finds that the direction of each interaction between the CSCI object and an external object is obvious from the Interface Design section of the SSDD or other system documentation.
Example:
If a requirement states that "the CSCI will turn on the sensor," it is shown in the Context OID as an operation request from the CSCI object to the external object (the sensor) to turn on.
When the direction is not obvious, the software developer must select the most natural direction, and study the impact of the choice.
The following substeps guide the software developer as interactions for the Context OID are identified:
A) The software developer identifies all of the CSCI object’s operation requests on the external objects. It is suggested that the software developer focus on one external object at a time and determine whether the CSCI is requesting (i.e., calling) an operation from that external object.
The software developer defines each operation request identified. There are four kinds of operation requests: synchronous, asynchronous, timed, and balking. In a synchronous request, the two objects remain synchronized throughout the interaction (like a telephone conversation). In an asynchronous request, the requesting object issues its request but does not wait to see if the request is received or the requested operation is performed (like mailing a letter). Timed and balking requests are essentially synchronous, but the requesting object can "give up" (i.e., stop waiting). In a timed request, the requesting object stops waiting if the performing object does not begin the operation within a specified time. In a balking request, the requesting object gives up if the performing object does not immediately begin the operation.
The software developer also determines whether the operation request is functional (i.e., returns a value) or procedural (i.e., does not return a value). This helps determine the operation request’s direction, as well as the needed type (e.g., synchronous, asynchronous, timed, or balking).
The operation requests are drawn on the Context OID. The software developer represents interactions (operations requests) in the OID by arrow-headed arcs connecting the interacting objects. The operation-request notations are described in Colbert’s OOSD Method [Colbert, 1995] , and they distinguish the four kinds of operation requests. The software developer then assigns each operation a name in the form of a verb.
B) The software developer identifies each operation request made by an external object upon the CSCI object. Again, the software developer focuses on one external object at a time, and determines whether that object is requesting an operation from the CSCI object. The software developer defines the operation requests as described in substep A, using the same categories. In this case, because the external object is requesting an operation from the CSCI, the arrow representing the operation request points toward the CSCI object. As before, the software developer assigns each operation a verb name and illustrates them in the OID.
C) The software developer identifies all flows (i.e., information exchanges) associated with each operation request. It is recommended that the software developer focus on one operation request at a time, and define all flows that may occur. There are three types of flows.
A data flow is an information transfer between two communicating objects about one or more objects.
An object flow occurs when a communicating object hands over a measure of control of an object, either granting access while retaining ultimate control (i.e., grant object flow) or giving over entire control (i.e., give object flow).
An error flow reports that an object failed to perform a requested operation and supplies the reason.
Each of these has its own arrow notation, illustrated and explained in Colbert’s OOSD Method [Colbert, 1995] . The software developer uses these notations to record each flow on the OID.
Functional operation requests require a data, object, or error flow that is returned to the requesting object. The software developer determines what flows, if any, must be passed to the performer of the operation request so the appropriate flow value is returned. The software developer determines if the procedural operation requests require flows to be passed to the performing object.
The software developer represents each error flow as an output and gives each a name describing the failure. Other data and object flows are given the name of the data or objects to be transferred, from the perspective of the performing object. These are added to the Context OID.
D) The software developer then makes Data Dictionary entries (see activity II.1.4 Develop Data Dictionary) for each flow and operation.
4) The software developer places (or references) the Context OID in the CSCI External Interface Requirements section of the MIL-STD-498 Software Requirements Specification (SRS) (see Appendix E).
Outputs
The Context OID developed and placed in the CSCI External Interface Requirements section of the SRS.
Overview
In this activity, the software developer specifies the dynamic behavior of the computer software configuration item (CSCI) with diagrams. The Behavior Diagram describes the required CSCI behavior as states, state transitions, conditions causing a state transition, and any actions performed as a result of a state transition or when in a state.
Roles and Responsibilities
The software developer develops the behavior specification.
Controls
See parent activity 3.2.1.1.2 Perform Object-Oriented Requirement Analysis .
Inputs
Allocated CSCI requirements in the MIL-STD-498 System/Subsystem Design Description ( SSDD ) (see Appendix E) or other equivalent system documentation (see activity 3.1 Participate In System Requirements And Design ).
The Context Object-Interaction Diagram (OID) (see activity II.1.1 Develop Object-Interaction Specification ) that shows the system interfaces.
Procedures
The software developer uses the Object-Oriented Requirements Analysis (OORA) method to develop the Context Behavior Diagram of the CSCI using information from the Context OID and the allocated CSCI requirements. A Context Behavior Diagram shows the relationship between states, state transitions, conditions causing a state transition, and actions performed as a result of these state transitions, using a graphical presentation in which nodes represent states, and arcs linking the nodes represent transitions. This notation is shown and more fully explained in Colbert’s Object-Oriented Software Development (OOSD) methodology [Colbert, 1995] .
The required behavior of the CSCI object is shown in a Context Behavior Diagram describing how the CSCI behaves from a "black box" or external view (i.e., modeled as it appears from outside the object).
Each entity (e.g., state, transition, condition, action) shown in a Behavior Diagram is defined in the Data Dictionary (see subactivity II.1.4 Develop Data Dictionary). Any questions or to be determined (TBD) information requiring resolution are labeled in a Behavior Diagram with three question marks (i.e., ???). Questions and TBDs also are recorded in the Data Dictionary.
A state represents the instantaneous condition of an object that is significant in relation to the flow of the object’s behavior. The four kinds of states -- basic, operation request, operation, termination -- are each represented by a different Behavior Diagram notation.
The basic state represents all other states.
The operation request state invokes a service request from another object.
The operation state is a waiting state from which other objects initiate service-to-operation requests.
The termination state is the object’s last state before being deinstantiated. The object ceases to exist in this state.
Instances of states are: continuous polling, waiting, lengthy computation, or an operation request blocking while waiting for response from another object. States are diagrammed using a multi-level, parent-child arrangement in which the lowest-level children contain the most detailed information (see [Colbert, 1995] for notation). A state may be composed of substates or simultaneous behavior components, but not both. Substates refine granularization of the parent state. Simultaneous behavior components, representing independent, simultaneous behavior within the parent state, describe complex behaviors that an object performs while in a state. The top-level state (i.e., highest parent) is typically titled the "On" ("alive") state; this simply signifies that the CSCI software is operational. Both substates and simultaneous behavior components may be further decomposed into substates or simultaneous behavior components.
Within a state, action descriptions may be specified. An action is work performed, such as computing a formula or requesting an operation. Actions specified within a state usually require significant completion time (relative to the overall behavioral flow). See [Colbert, 1995] for details on diagramming actions.
A transition (and any action associated with it) is a change of state that effectively takes zero time to occur in relation to the overall CSCI behavior. Although, in a software implementation, a transition generally requires a non-zero time to transpire; this time must be insignificant relative to the overall behavior. A transition is symbolically shown as a one-way arc linking two states. Many transitions are unconditional, in which case, the transitions to subsequent states occur immediately after the initial state actions are completed. Transitions also may be conditional, meaning the transitions occur only when a specified condition exists. Multiple transitions exiting a single state do not have to be conditional. One transition can be unconditional, in which case, that transition is the default. That is, the transition is taken when the state’s work is completed if the condition of no other transition is met. A condition may be an event, the result of an internal test, or both. An event is one of the following:
The receipt of an operation request from another object or simultaneous behavior component. An object receiving a request must be in a state waiting for the specific request to service it. When the operation state request is received, the object enters the operation state for the operation request. Every operation request received by an object must appear as a condition of at least one transition in the Behavior Diagram for the object.
The receipt of a message from a simultaneous behavior component. A message broadcast is an informal communication between orthogonal components of a Behavior Diagram. Messages cannot be functional (i.e., they cannot return information). An object must be in a wait state specific to the message to be received. The message name appears enclosed in braces (i.e., {}) as a condition on a transition exiting the wait state. If the message takes parameters, the parameter names appear in parentheses.
Example:
The string {Enable (Sensor_Name)} in the condition of a transition, says that the transition is taken when the Enable message with a Sensor_Name is received.
A time-out. An object waiting for a time-out will be in a state with an exiting transition condition that is {time-out value}.
Internal tests are enclosed in brackets (i.e., [ ]) and can be one of the following:
A test of the state of another simultaneous behavior component, in which case, the change of state depends on the state of another simultaneous behavior component.
A test of the value returned from an operation requested by this object. Because an operation request can be functional, the returned value may be a condition for a transition.
A test of an attribute of the object whose behavior is being represented. An attribute is an object’s known quality or characteristic. Any internal attribute’s value can be a transition condition. Attributes of other external objects cannot be directly referenced.
Actions also may be associated with a transition. Any such action is considered to take zero time to complete, and is separated from the transition by a horizontal line. An action can be a request that another object perform one of its operations, a broadcast of messages, or an informal description that is enclosed in brackets (i.e., {}).
Example:
As a simple example of a multiple-event, conditional transitions from a wait state, consider an internal state to a CSCI object, named Wait, which waits for receipt of an operation request event (e.g., an interrupt) to occur. As a result of this interrupt, an enable or disable of a sensor, one of the transitions leaving the Wait state, should be labeled with a conditional command=enable and the other with command=disable. Associated with these conditions might be the actions {broadcast_sensor_enabled} and {broadcast_sensor_disabled}, respectively.
The following sequential steps explain how to create and verify a Behavior Diagram. However, it is likely that several iterations of these steps will be necessary to complete the Behavior Diagrams.
1) The software developer first must identify the system’s condition-response behavior. Scenarios (see activity 3.1.2.3 Generate Subsystem Operational Scenarios) may be developed to understand the CSCI’s functionality.
2) To begin creating a Behavior Diagram, the software developer reviews each external object’s interactions with the CSCI object as captured in the Context OID and its corresponding Data Dictionary and Property Specification entries.
The software developer begins constructing the state diagrams by specifying an "Off" ("dead") state and an "On" ("alive") state. The transition from the Off state to the On state generally includes any initialization actions. In turn, the transition from the On state to the Off state includes any clean-up actions associated with a CSCI shutdown. Because the On state is decomposed into substates or orthogonal components, the software developer draws this state with a bold border. Starting the behavior description with the On/Off-state diagram, the software developer is certain to consider the requirements for CSCI startup and shutdown actions.
After this two-state Behavior Diagram is complete, the software developer uses the scenarios to elaborate on the On-state behavior by creating a child diagram for the On-state that is composed of substates or simultaneous behavior components. The software developer starts describing the detailed behavior of a state by identifying each behavior’s "initial" substate. Thus, for an On-state child diagram that contains substates, the software developer specifies an initial substate to identify where the On-state Behavior Diagram functions begin. The initial substate of each simultaneous behavior component (if simultaneous behaviors exist in the current situation) is specified when the diagram describing the details of the behavior is created. The software developer should note that simultaneous behavior components are not always necessary.
Beginning at the initial state (previously in this activity referred to as a "substate of the parent"), the software developer identifies each transition to a new state, and determines what conditions trigger that transition by examining the CSCI’s operation requests (shown as arrows pointing toward the CSCI object on the Context OID), and identifying the operation requests handled by this behavior component. All exiting transitions are then diagrammed and labeled with their conditions. Condition labels should use the same reference used by the associated operation request in the Context OID. The software developer takes the path of each exiting transition from the initial state, and identifies its subsequent states.
The software developer adds actions to each state and transition, as appropriate. Actions that are considered to take insignificant time to perform are associated with transitions. Actions that take significant time are associated with states.
The software developer starts this process by examining the operations requested by the CSCI object of the external objects. These operation requests are shown on the Context OID as an arrow pointing from the CSCI object toward an external object. Every procedural operation requested by an external object must appear as an action of at least one transition or state in the object’s Behavior Diagram. (Functional operations requested by an object must appear in at least one condition or action). If an operation requested by the CSCI object does not fit on any of the existing states or transitions, the condition causing the CSCI to issue the request needs to be identified by examining the allocated CSCI requirements which may be documented in a SSDD and any scenarios that were created.
The software developer also examines the allocated CSCI requirements which may be documented in a SSDD , and any scenarios to identify internal processing performed by the CSCI object, and adds informal descriptions of the actions to appropriate states and transitions. The software developer may need to add new transitions and states. Also, when describing the behavior of a simultaneous behavior component (or a substate of a simultaneous behavior component), the software developer must add "broadcast message" actions as appropriate to communicate with other simultaneous behavior components.
Transitions and subsequent states outlined for the initial state are iteratively defined to identify each subsequent state’s subsequent states and exiting transitions. This is repeated until the final transition returns to a termination state or to a previously defined state (i.e., loop situation).
Behavior Diagram substates or simultaneous behavior components should be defined with a similar abstraction level so that no state’s detail level is out of proportion with the others. To define lower levels of abstract behavior, substates or simultaneous behavior components should be shown with child Behavior Diagrams. Thus, the software developer decomposes the defined "On" state with substates or simultaneous behavior components one at a time, as needed, into child Behavior Diagrams.
For each state, simultaneous behavior component, and transition, the software developer completes a Data Dictionary entry (see subactivity II.1.4 Develop Data Dictionary) and, as appropriate, Property Specification entries (see subactivity II.1.5 Develop Property Specification). While specifying the CSCI’s behavior, the software developer will probably identify additional interactions that need to occur between the CSCI and the external objects. The interactions need to be added to the Context OID and described in the Data Dictionary (see subactivity II.1.1 Develop Object-Interaction Specification).
3) The software developer verifies the Behavior Diagram is complete by ensuring:
Every operation request sent to the CSCI object from an external object, as shown in the Context OID, appears in a Behavior Diagram as a condition for at least one transition exiting an operation state accepting the request.
Every operation the CSCI object requests of an external object, as shown in the Context OID, appears as an operation request in a Behavior Diagram.
The software developer also simulates a manual or automated execution of the Behavior Diagram, and compares the results to the previously developed scenarios to confirm that:
The CSCI object performs correct actions for all operation request sequences to the CSCI.
Correct transition occurs from every state, for every possible requested operation and all conditions.
Results are what the customer (or end user) expects.
4) The software developer places the completed scenarios and Behavior Diagrams in the CSCI Capability section of the MIL-STD-498 Software Requirements Specification (SRS) (see Appendix E ). A text overview is added with each Behavior Diagram.
Outputs
The Behavior Diagrams, with their descriptions and completed scenarios, placed in the CSCI Capability section of the SRS.
Overview
This activity covers developing one or more Object-Class Specifications, graphically presented as Object-Class Diagrams (OCD). The OCD shows the classes to define the objects, flows, and attributes of the Object-Interaction Diagrams (OID); the relations between the classes; and the operations defined for the classes of the computer software configuration item’s (CSCI) object. For requirements analysis, a Context-Level OCD is produced, reflecting classes in the Context OID and the Context Behavior Diagram.
Roles and Responsibilities
The software developer develops the Object-Class Specification.
Controls
See parent activity 3.2.1.1.2 Perform Object-Oriented Requirements Analysis .
Inputs
Context OID (see activity II.1.1 Develop Object-Interaction Specification ).
The Context Behavior Diagram (see activity II.1.2 Develop Behavior Specification ).
Procedures
A class is blueprint describing an object’s characteristics. The Context OID, Behavior Diagrams, Property Specification Forms, and Property Summary Table describe which objects interact, under what conditions, and how. They do not show what classes define the objects or flows, the relations between classes, nor the class structures. The OCD identifies: each object, parameter (flow), and attribute; which objects share the same class; and relationships among classes and objects. The OCD graphically represents classes, metaclasses, and objects, and with relations for links. The software developer records entries in the Data Dictionary for objects, classes, operations, parameters, and attributes (see subactivity II.1.4 Develop Data Dictionary). Together, these OCDs and related Data Dictionary entries constitute the Object-Class Specification.
A class is describes the behavior, responsibilities, and qualities of objects with the same or similar structures. By identifying a class, the software developer avoids redundancy in defining the objects in that class [Colbert, 1989] . Two objects of the same class are differentiated by the way they are used, although they may have the same or different attribute values, or interactions with other objects. A class can represent a data type from which an object or attribute value is made (e.g., range of values, record, or array). It also can define operations (e.g., procedures, functions, address interrupts, or time-outs). Thus, an instance of a class converts the class abstract structure into concrete existence as an object.
The diagramming notation for developing the OCD is described in Colbert’s Object-Oriented Software Development (OOSD) [Colbert, 1995] . The following steps describe how to create a Context-Level OCD:
1) Create an active object in the Context-Level OCD to represent the CSCI object in the Context-Level OID. The software developer places the CSCI object toward the bottom center of the Context OCD. The space above the CSCI object is for the object’s class, which the software developer defines in step 3.
2) Add an external object to the Context-Level OCD for each external object in the Context-Level OID of which the CSCI requests an operation. The software developer places these external objects to the left or right of the CSCI object, leaving room above them for their classes, which are defined in step 4.
3) Define a class for each object in the Context-Level OCD. The software developer uses the same class as its related object (e.g., active class for active object). Therefore, the software developer uses an active class notation to represent the CSCI object class, and depicts one or more external classes to represent each external object. The software developer then names the classes using nouns with the suffix "_Class." In OOSD, the CSCI is an object. Therefore, only one class needs to be created for the CSCI. The software developer starts by adding the CSCI class above the CSCI object in the OCD and then proceeds with creating external classes for each external object in the Context-Level OID. The software developer creates external classes for only those external objects from which the CSCI object requests an operation. This specifically identifies what external classes are implemented by the CSCI class.
A class can be defined as an instance of a metaclass. This allows multiple individual classes to be represented by a single entity. The software developer draws an "instance of" relation arc from each object to its class and, if used, from each class to its metaclass. The arc should point from the object toward the class or from the class toward the metaclass.
Before creating a class, the software developer should review classes already created for this CSCI or classes from another CSCI (perhaps using other OCDs from reusable-component libraries) to determine if one or more classes can be reused to define the object. Reuse an existing class (changing the name if needed) if it exactly defines the object’s required operations, behavior, and attributes. Otherwise, define a new class.
The software developer enters new class entries into the Data Dictionary, and refines any reused class entries as needed (see subactivity II.1.4 Develop Data Dictionary ).
4) Add a "uses in implementation" relation from the CSCI class to every external class. All external classes in the OCD have a "uses in implementation" relationship with the CSCI because the CSCI object requests operations from these external objects. A request to an external object can occur anywhere inside the CSCI object.
5) Review the interface interactions in the Context-Level OID to determine the operations performed by each class. An interface operation is defined to be an operation provided by external classes in the CSCI and requested by external classes. Add an interface operation with the name of the operation requested by the external object to the CSCI object by attaching an "Operation-Interface" icon to the class of the performing object. Repeat this action when the CSCI object makes an operation request of an external object. All operation requests between the CSCI object and the external objects are interface requests, and, thus, are shown as interface operations.
Each operation must be unique and not merely a different name for another operation in the same class. Operations within one class can be overloaded (i.e., have the same names but different parameter classes). Therefore, if the names of two operations are the same, either the number of parameters or the names of their parameter classes must be different, or the return type of functional operations must be different. An operation’s parameters are found by examining the OID and identifying the flows associated with the operation. Each flow represents one parameter (except error flows).
The software developer adds Data Dictionary entries for each interface operation and updates the class defining the operation (see subactivity II.1.4 Develop Data Dictionary).
6) Define classes for every parameter of every operation. For each data flow associated with an operation request in the Context-Level OID, the software developer adds a parameter to the operation in the Context-Level OCD, and updates the operation’s Data Dictionary entry to include the parameter. Also, for each error flow identified in the Context-Level OID, the software developer adds the error name and conditions to the operation description.
Because the parameters are objects, the software developer identifies the parameter classes. The software developer creates an appropriate (active or passive) class notation or reuses a notation, and places them on the OCD.
The software developer enters the new parameter class and its definition, or refines the reused parameter class in the Data Dictionary (see subactivity II.1.4 Develop Data Dictionary).
7) Link each parameter class identified on the Context-Level OCD to the CSCI class with the uses-in-interface or uses-in-implementation relation notation. This "uses" relation type is from the CSCI class viewpoint. The following are guidelines for each type of the "uses" relation.
A) The software developer associates every parameter class with the CSCI class operations with the "uses-in-interface" relation notation. This implies these parameter classes must be visible to the external objects requesting the operation.
B) The software developer links every parameter class associated with the operations performed by an external object class for the CSCI class with the "uses-in-implementation" relation notation. The "uses-in-implementation" notation implies that the CSCI uses the parameter class for issuing operation requests to an external object—considered to be internal behavior of the CSCI object.
8) Review the Behavior Diagrams of the CSCI object to identify attributes, or a quality characteristic of the class. The software developer reviews values maintained or calculated (e.g., counters); values used within transition conditions; and states that wait, have time periods, or represent values. The software developer records an attribute’s name, initial value (if known) and attribute description in the Data Dictionary (see subactivity II.1.4 Develop Data Dictionary). For atomic classes (i.e., cannot or do not need to be further decomposed), OOSD defines specific attributes which need to be described. The software developer determines the attributes of non-atomic classes by inspecting the Behavior Diagrams and documenting what is known about the attribute (e.g., component objects that make up the attribute).
9) Determine if attributes of the system class share the same class or need their own unique class(es). The software developer should first decide if an attribute class can be reused by determining if its values, accuracy, and physical representation (e.g., 16-bit integer) are similar to that of the needed class. Reusable classes may have been created by previous iterations of this activity or other development efforts (check classes in other OCDs from available reusable-component libraries). If no reusable class is suitable, the software developer creates a passive class icon on the OCD for the attribute. The software developer adds a new class to the Data Dictionary by incorporating its name, value, and description, or refines the description of a reused class (see subactivity II.1.4 Develop Data Dictionary). If the software developer is reusing a class from a reusable-component library, its definition may be a new Data Dictionary entry that must be incorporated.
10) Add a "uses" relation from the CSCI class to every attribute class. The "uses-in-interface" relation is specified for all attribute classes directly associated with the CSCI class’ operation parameters (parameters related to operation requests serviced by the CSCI object). All other attribute classes are defined with the "uses in implementation" relation.
11) Identify assembly-part, collection-member, or container-contents relationships between other objects, classes, or metaclasses. These relationships are all of a set-subset type. In requirements analysis, the software developer uses these relations to group the attributes and data flows derived from the CSCI object’s behavior. The following substeps are performed:
A) The software developer identifies assembly-part relations in which all parts are required to define the assembly. This is not the case with collection-member or container-content relationships.
Object–Object. An object is built from other objects (i.e., an object is an assembly of parts). Behavior and assembly states are defined by the parts’ combined behavior and states (i.e., an assembly object can request services provided by parts; each assembly state is composed of the states of its parts).
Class–Object, Metaclass–Object. The assembly class (metaclass) and all class objects are built from component objects.
Class–Class, Metaclass–Class, Metaclass–Metaclass. The assembly class (metaclass) has one or more components of the "component" class (metaclass).
The assembly class or metaclass is built from objects, classes, or metaclasses. The parts together represent the assembly.
Example:
Objects named tire, brakes, and motor could possibly be assembled into a car object.
For all newly defined object assemblies, the software developer must define classes for these objects so that an instance-of relation can be applied (this is done in step 12).
B) The software developer identifies collection-member relations. Collections are homogeneous (i.e., member objects must be instances of the same class or subclasses of the member class). In this relation, members have similar (i.e., homogeneous) characteristics, but no one member is essential to define the collection. The collection class or metaclass defines a collection (e.g., group, set) of member objects, classes, or metaclasses The state of the members (e.g., awake, asleep) does not affect the state of the collection.
Example:
A monkey, horse, and whale are a collection of mammals. If the monkey is removed, its still a functional collection.
Object-Object. An object is a collection (group, set) of other member objects. Behavior and states of the collection is independent of the behavior and states of the members (e.g., a committee of people, a queue of messages).
Class-Object, Metaclass-Object. A collection class (metaclass) defines collections of member objects (e.g., a committee class, a queue class). All objects of the collection class are collections of the member objects.
Class-Class, Metaclass-Class, Metaclass-Metaclass. A collection class (metaclass) is a collection of objects of the "member" class (metaclass) (i.e., member objects must be instances of the same class or a subclass of "member" class).
C) The software developer identifies container-contents relations that are similar to the collection-member relationship except the software developer is modeling a real world entity (e.g., bag of spark plugs). If part of the contents of a container is missing, the container is just empty. The contents’ state does not affect the state of the container.
Object-Object. An object is a container holding other, perhaps dissimilar, objects.
Class-Object, Metaclass-Object. A container class (metaclass) defines a container of objects (e.g., a trunk class, a bottle class). All objects of the collection class are collections of the member objects.
Class-Class, Metaclass-Class, Metaclass-Metaclass. The container class or metaclass contains other classes or metaclasses.
12) Identify classes or metaclasses of any parts, members, or contents. The assembly-part, collection-member, and container-contents relations depicted in the Context-Level OCD need to have their enclosed objects, classes, or metaclasses related to a class or metaclass. For each part, member, or content enclosed by an assembly, collection, or container class, the software developer should:
A) Determine if a part, member, or content can reuse a class already created by performing this activity or in another development effort (the software developer checks other OCDs and classes from any available reusable-component library).
B) Add the class icon if the class is not represented in the Context-Level OCD. For each part, member, or content that does not have a class, and for which no reusable class can be identified, the software developer creates a passive class icon on the OCD.
C) Create an entry in the Data Dictionary or refine an entry (if needed) for a reused class (see subactivity II.1.4 Develop Data Dictionary ). If the software developer reuses a class from a reusable-component library, its definition as a new Data Dictionary entry must be incorporated. The software developer then updates the Data Dictionary (see activity II.1.4 Develop Data Dictionary) to reflect which parts, members, or contents are associated with the reusable classes.
13) For each collection class, identify the selector class, if required. If the software developer adds a collection class or metaclass to the Context-Level OCD, it may be necessary to identify a selector. The selector object identifies an individual collection member (e.g., an index identifying one particular record in a database acts as a selector). Use the "selected-by" relation to associate the selector object with the collection class. Create a class for the selector if an existing class cannot be used.
14) Use the following two substeps to refine the Context-Level OCD classes (and metaclasses) using the derived-from and subclass-of relations:
A) The software developer identifies the derived-from relations (also referred to an "non-polymorphic inheritance") which creates a class (or metaclass) whose structure, responsibility, and qualities are derived from a class (or metaclass). Unlike the subclass-of relationship, instances of the derived class are not also instances of the parent class.
Example:
If a coordinate class exists in the Context-Level OCD, the software developer can assume that a start_coordinate object and an end_coordinate object are instances of the coordinate class. Having identified start and end coordinates, the software developer can use the Great-Circle navigation formula to determine the distance between the two points. Thus, the software developer can derive a distance class and make instances of it from the coordinate class, even if the original requirements never mentioned distance.
Once the derived class(es) is created, the software developer uses the derived-from relation to associate the derived class with the deriving class.
B) The software developer identifies the subclass-of relations (also known as the "polymorphic inheritance") between two classes -- a subclass and a superclass -- where the subclass inherits the structure (i.e., attributes), behavior (i.e., operations), and qualities from the superclass. The goal in refining with polymorphic inheritance is to improve reliability and maintainability, and take advantage of real-world inheritance relationships to reduce re-design and implementation by reusing common structure and operations. Attributes and operations common to a group of subclasses should be attached to the superclass and shared by each subclass. The subclass inherits the features of its superclass, providing a powerful abstraction for class similarities, while preserving the subclasses’ differences. Each subclass can possess unique attributes and operations in addition to what was inherited.
The software developer creates subclass-of relations in one of two ways: abstracting common attributes and operations of existing classes into a superclass (a bottom-up approach), or refining an existing class into specialized subclasses, making the existing class a superclass (top-down).
Bottom up. Inheritance is found by searching the classes in the Context-Level OCD for common attributes, operations, and relations. For each group of common classes, the software developer creates a proposed superclass and attaches common class features.
Example:
Consider a case with an airplane, balloon, and helicopter as classes in a Context-Level OCD. All three classes have attributes of altitude and airspeed and also operations of takeoff, land, altitude_of, and airspeed_of. By studying these classes, a software developer can create a superclass named "aircraft" containing all of the mentioned common attributes and operations. In addition to the attributes and operations given to the aircraft superclass, the airplane class could have unique attributes and operations for propeller_speed; the balloon class could have unique attributes and operations for gas_rate; and the helicopter class could have unique attributes and operations for rotor_speed.
Top-down. Inheritance is found by searching the existing classes in the Context-Level OCD and identifying class(es) that can be broken down by proposed specialized subclasses.
Example:
If the aircraft class is defined first, it can be a superclass with the subclasses airplane, balloon, and helicopter created from it.
Once the superclass and subclass have been created or refined into an inheritance hierarchy, the software developer should use the subclass-of relation between the subclass and the superclass.
15) Identify any parameterized class relations that enable deferring details of an internal class structure until its objects are created (i.e., instantiated). A parameter notation is attached to the instance-of relation notation and labeled with formal parameters.
16) Identify any associated classes relations, possibly at a higher level. The associated class relations define names describing the relation, class roles in the relation, and any multiplicity. The associated classes relation can link any classes regardless of other class relationships (e.g., superclass-subclass). The relation name should indicate the intent of the relation.
Example:
The association between a class named Person and a class named Company could be that a person owns a company, a person works for a company, or a person is a client of a company. Any relation has an inverse that could be described as a person works for a company or a company employs a person.
If the association direction between two associated classes is not obvious, use the relation parameter direction notation (hollow circle attached to an arrow). Associated class relations also show how many instances of each class are related (multiplicity). The default is 1-to-1. Typical descriptions of multiplicity include:
1+ One or more
0+ Zero or more
1..n One to n (where n is the maximum number)
0..n Zero to n (where n is the maximum number)
Example:
Multiplicity may show a person as working for zero or more (0+) companies, and a company as employing one or more (1+) persons.
17) Identify any required operations for classes identified in steps 7 through 17. All classes created should be analyzed to determine if any operations must be identified for them. For each superclass, the software developer determines which subclass operations can be defined in the superclass. If a subclass is to inherit an operation from its superclass, that operation must be present in the superclass.
18) Repeat steps 12 through 17 until all required relations are identified. Once the software developer identifies all required relations and records all appropriate descriptions in the Data Dictionary, the Context-Level OCD should completely represent all the necessary classes and their relations.
19) In this step, the software developer verifies that the following have been accomplished:
The CSCI object and all external objects from which the CSCI object requests a service, as shown in the Context-Level OID, are represented in the Context-Level OCD.
The CSCI object has a corresponding class linked to it by the instance-of relation, as well as a class description recorded in the Data Dictionary.
Each external object has a corresponding class (more than one external object may correspond to the same class) associated to it by the instance-of relation, as well as a class description recorded in the Data Dictionary.
Each operation requested of the CSCI object, as shown in the Context-Level OID, is shown in the Context-Level OCD as an operation-interface attached to the CSCI class and labeled with the same verb name as the operation request in the OID. There is also a Data Dictionary entry for each operation.
Each operation request from the CSCI to an external object, as shown in the Context-Level OID, is shown in the Context-Level OCD as an operation-interface attached to the external object and labeled with the same verb name as the operation request in the OID. There is also a Data Dictionary entry for each operation.
All the flows shown in the Context-Level OID, which are the operations’ parameters, have appropriate classes shown in the Context-Level OCD, and each class of parameters is linked to the CSCI class by the "uses in implementation" or the "uses in interface" relation. Parameter classes defined from the operations attached to the CSCI class are linked to the CSCI class by the "uses-in-interface" relation. Parameter classes defined from the operations attached to the external classes are linked to the CSCI class by the "uses-in-implementation" relation. There is also a Data Dictionary entry for each operation parameter.
Classes are correctly defined for the attributes identified for the CSCI and linked to the CSCI class by the "uses in implementation" or the "uses in interface" relation. When attributes use classes defined by parameters, the "uses" relation is already drawn between each attribute class and the CSCI class. Each attribute class has a descriptive entry in the Data Dictionary.
Classes representing assembly-part, collection-member, or container-content relations and associated with the appropriate relation are identified. If a collection class is defined, a selector class and a selected-by relation may exist in the Context-Level OCD.
Related classes are identified using the "derived from," "subclass of" (inheritance), or "associated with" relations.
Each class shown in the Context-Level OCD is thoroughly reviewed to determine whether an operation-interface icon should be attached to identify each required operation.
20) After completing and testing the OCD, the software developer places the OCD in the CSCI Capability Requirements section of the MIL-STD-498 Software Requirements Specification (SRS) (see Appendix E).
Outputs
The Context OCD has been developed, verified, and placed in the CSCI Capability Requirements section of the SRS.
Overview
In this activity, the Data Dictionary is established. The Data Dictionary summarizes all known information about every entity identified in the requirements analysis, capturing in text form the information that cannot easily be represented in diagrams (e.g., descriptions of purpose, notes, questions).
Responsibilities
The software developer is responsible for maintaining the Data Dictionary.
Controls
See parent activity 3.2.1.1.2 Perform Object-Oriented Requirements Analysis .
Inputs
The Context Object-Interaction Diagram (OID) (see activity II.1.1 Develop Object-Interaction Specification ).
The Context State-Transition Diagram (Behavior Diagram) (see activity II.1.2 Develop Behavior Specification).
The Context Object-Class Diagram (OCD) (see activity II.1.3 Develop Object-Class Specification).
The Data Dictionary from the MIL-STD-498 System/Subsystem Design Description ( SSDD ) (see Appendix E) (if available) or other equivalent system documentation (see activity 3.1.2 Define System Design).
Procedures
The Data Dictionary is developed concurrently with subactivities II.1.1 Develop Object-Interaction Specification, II.1.2 Develop Behavior Specification, II.1.3 Develop Object-Class Specification, and II.1.5 Develop Property Specification . A Data Dictionary may have already been established during system requirements and design. If so, that information should be maintained throughout the software development effort.
Table II.1.4-1 lists the OOSD entity forms and the diagrams from which the software developer derives the information required to complete them. These forms, along with the instructions for completing them, are in Appendix C .
Table II.1.4-1 Diagrams And Corresponding Entity Forms
| Diagram | Entity Form |
| OID, OCD | Object |
| OID | Interaction |
| OID | Flow |
| OCD | Relation |
| OCD | Relation Parameter |
| OID, OCD | Attribute |
| OCD | Class |
| OCD | Operation |
| OCD | Operation Parameter |
| Behavior Diagram | State |
| Behavior Diagram | Transition |
Note : a computer-aided software engineering (CASE) tool may be used for maintaining the Data Dictionary as changes are made to the diagrams.
The Property Summary Table (see Appendix C ) lists the contents of the Data Dictionary and gives a brief description of each entity. The purpose of the Property Summary Table is to serve as a quick look-up of any Data Dictionary form. The Property Summary Table identifies the name and the full path name of the entity through decomposition levels. The following paragraphs describe the forms used by the software developer to define Data Dictionary entities.
Object Form. The software developer uses the Object Form to define each object (component) identified and shown in the OID.
Interaction Form. The software developer uses the Interaction Form to capture the object interactions identified and shown in the OID(s), including interactions between the CSCI and the external objects (interfaces) and interactions between internal CSCI objects (internal interactions). Each interaction includes two objects (e.g., the CSCI object and an external object), one of which acts as a requester and the other as a server.
Flow Form. The software developer uses the Flow Form to capture information on each data flow associated with an operation request, as identified and shown in the OID.
Class Form. The software developer uses the Class Form to capture information about each class shown in the OCD.
Operation Form. The software developer uses the Operation Form to capture information about an operation applied to a class, as shown in the OCD.
Operation Parameter Form. The software developer uses the Operation Parameter Form to describe a parameter of an operation appearing in an OCD.
Relation Form. The software developer uses the Relation Form to describe each relation between classes (e.g., selected by, subclass of), as shown in an OCD.
Relation Parameter Form. The software developer uses the Relation Parameter Form to describe each parameter of a relation between classes, as shown in an OCD.
State Form. The software developer uses the State Form to describe states shown in a Behavior Diagram.
Transition Form. The software developer uses the Transition Form to describe transitions shown in a Behavior Diagram.
Attribute Form. The software developer uses the Attribute Form to describe a characteristic attributed to an object or a class.
Question Form. The software developer uses the Question Form to record questions about entities of the diagrams (indicated therein with three question marks (???)), attributes, requirements, or properties. Every Data Dictionary form (other than the Question Form itself) has a "Questions" field which is used for listing the identifiers of any questions that apply to the entity.
Property Summary Table. The Property Summary Table is a list of the contents of the Data Dictionary arranged alphabetically.
The following steps guide the software developer in creating and maintaining the Data Dictionary (see Appendix C for each of the forms and the instructions for completing them):
1) When the software developer adds an entity to a diagram, a new form appropriate to the kind of entity is begun. If the entity already exists, the software developer updates the form with any new information reflected in the diagram. Minimally, the software developer fills in the Name, Full Name, and Purpose fields and completes the other fields as more information becomes available. If the entity is a relation, the software developer also updates the forms of the related entities.
2) For each operational characteristic (property) required of the entity described in step 1, the software developer creates a new Property Specification Form and fills in the fields, as described in subactivity II.1.5 Develop Property Specification . The relationship between the entity and the property is recorded by adding the unique identifier of the property to the property field of the appropriate entity form and by adding the unique identifier of the entity in Item [3] on the Property Specification Form (see Appendix C ).
During requirements analysis, most properties that must be captured are related to specific operational requirements. The Property Specification Form captures the details of these requirements.
3) For each attribute of the entity described in step 2, the software developer completes the fields of the Attribute Form . The relationship between the entity and the attribute is described by adding the unique identifier of the attribute to the attributes field of the appropriate entity form and by adding the unique identifier of the entity in Item [3] on the Attribute Form (see Appendix C ). Atomic objects and classes have the pre-defined attributes as described in the instructions to the Attribute Form .
4) For any open questions about the entity described in step 2, the software developer completes the Question Form and fills in the fields describing the question, the question originator, and the date. The software developer records the relationship between the entity and the question by entering the unique identifier of the question in the questions field of the appropriate entity form and by entering the unique identifier of the entity in Item [8] on the Question Form in Appendix C .
As a reminder that there are questions about the entity, the software developer adds three question marks (???) to the label of the icon representing the entity either on all diagrams where it appears, if the question is whether the entity should exist, or on any diagram that relates to the question. When the answer is received, the software developer completes Items [5], [6], and [7] on the Question Form (see Appendix C ).
5) Create a Property Summary Table. The software developer creates an instance of the table summarizing everything known about the system. The software developer creates a row in the table for each entity, question, property, and attribute described in steps 2 through 4 and copies the appropriate information from the Data Dictionary entity forms to the Property Summary Table. The software developer then alphabetically sorts the table entities to support quick reference. (Note: this step may be automated by the software developer’s CASE tool).
6) Upon completion of the Data Dictionary, the software developer places it in an appendix to the MIL-STD-498 Software Requirements Specification (SRS ) (see Appendix E).
Outputs
The Data Dictionary, describing all information known about the system, its requirements, and any questions have been developed, verified, and placed in an appendix to the SRS .
Overview
The software developer uses the Property Specification Form and the Property Summary Table (see Appendix C ) to record text descriptions of the operational characteristics (properties) of the computer software configuration item (CSCI) object. A property is a quality (operational characteristic) of some object (or class) or operation.
Roles and Responsibilities
The software developer is responsible for completing the Property Specification Form and Property Summary Table.
Controls
See parent activity 3.2.1.1.2 Perform Object-Oriented Requirements Analysis .
Inputs
Working versions of the Context Object-Interaction Diagram (OID) (see activity II.1.1 Develop Object-Interaction Specification ).
Working versions of the Context Behavior Diagram (see activity II.1.2 Develop Behavior Specification ).
Working versions of the Context Object-Class Diagram (OCD) (see activity II.1.3 Develop Object-Class Specification ).
The Data Dictionary forms (see activity II.1.4 Develop Data Dictionary ).
Allocated CSCI software requirements, as listed in the MIL-STD-498 System/Subsystem Design Description ( SSDD ) (see Appendix E) or other equivalent system documentation (see activity 3.1.2 Define System Design).
Procedures
The Context-Level OID, Context-Level Behavior Diagram, and Context-Level OCD show which objects interact; under what conditions; and what classes are used to define the objects and data flows, the relations between classes and structure of the classes, but not qualitative issues regarding how the relations interact. The Property Specification addresses these by using two textual representations: the Property Specification Form and the Property Summary Table. The Property Specification Form defines the quality of an object or a class in terms of operational characteristics (properties). The software developer specifies the required quality goals and resource constraints for the CSCI Object.
One approach to creating a Property Specification Form is to consider performance, operational, and design-constraint requirements. Table II.1.5-1 lists the categories of the requirements listed in the Software Requirements Specification (SRS ) Data Item Description (DID) (see Appendix E) and associates them with potential property types. Requirements that fall into these categories could be candidate properties in OOSD.
Table II.1.5-1 Requirement Categories Candidate For OOSD Properties
| Performance | Static numerical Number of files and records Size of files and tables Number of terminals Data precision Frequency of transactions Dynamic numerical Time constraints Throughput and response time Periodicity Normal workloads vs. peak workload conditions Data quality, integrity, accuracy, and retention CSCI and communications capacity Reliability, availability, uniformity, workability, and maintainability Human workload Error detection and recovery Quality factors (e.g., reliability, flexibility, reusability, in terms of performance) |
Operational | System monitoring and
configuration control Training Support capabilities (other hardware, software, COTS) Maintenance Logistics Facilities Safety/security Usability, adaptability, reusability, suitability, portability, and extendibility |
Design Constraint | Organizational regulations
and format standards (e.g., DIDs, coding standards) Resources: hardware limitations (e.g., size of memory) Resources: Software limitations (e.g., operating system, COTS) Development facility Management approval/decisions Special test requirements Installation, phase-in, or turnover Schedule and budget constraints Growth, flexibility, and expandability Development resources of time, personnel, money and tools Quality factors. |
The properties listed in Table II.1.5-1 may often be qualified with various "software quality factors." Some of these quality factors are listed in Table II.1.5-2 .
Table II.1.5-2 Quality Factors
| Quality Factors | Description |
| Correctness | Conformance to operational needs and system requirements; accuracy of output |
| Efficiency | Speed of function execution and corresponding consumption of renewable and nonrenewable resources |
| Flexibility | Ease of modifying or interchanging operational components, protocols, or interfaces |
| Expandability | Ease of increasing functional capability, performance, or number of component interfaces |
| Integrity | Control of access to and modification of components and data |
| Interoperability | Ease of interfacing with other CSCIs; difficulty of adapting to different CSCI environments |
| Maintainability | Ease of locating errors, analyzing their impact, and correcting them |
| Portability | Degree of computer and site independence; ease of setup, teardown, transport, and installation |
| Reliability | Expectation of performing intended function with required precision over a defined period |
| Reusability | Degree of component usefulness in other contexts or CSCIs |
| Testability | Ease of calibration and testing to ensure performance and functional requirements are met |
| Usability | Ease of learning the user interface, preparing inputs, interpreting outputs, interacting with the CSCI, and adjusting the user interface to compensate for user experience and knowledge |
| Survivability | Degree of robustness, functionality, and performance retained when components or data items are unavailable |
| Availability | How much of the time the CSCI is useable |
The Property Specification Form captures the unit of measurement (scale) used to assess each property of an object, how the property will be tested (tests), the minimum and desired standards to be met (worst-acceptable level and planned level), the best known and past-performance measures (record level and past level), the current measure (current level), notes, references, and questions.
The software developer has the option of creating a Property Summary Table. This table summarizes all the properties of an object and helps the software developer analyze property tradeoffs, risks of failing to achieve desirable or necessary combinations, and alternate designs. If the software developer uses an automated tool to develop and maintain the Property Specification, that tool should produce a table summarizing all the properties. The Property Summary Table will serve as a means of navigation between the table and the individual Property Specification Forms.
The following steps explain the process for creating the Property Specification Form and the Property Summary Table for the CSCI object:
1) In defining the properties of the CSCI object, the software developer looks for quality goals, such as those related to reliability, performance, usability, availability, safety, adaptability, and security, and for constraints on resources, such as memory and time (see Table II.1.5-2 ). In many cases, properties are described in the SSDD or other equivalent system documentation. If only a value is specified in the SSDD , the software developer must verify whether the customer meant it as a minimum (worst-acceptable) or a desired value.
The software developer should first apply properties to objects which communicate with other objects. The entities of the OID (object, operations, flow, and interaction) involved in communication should be considered in order to assign quality properties. Likewise, the entities in the Behavior Diagram (states and transitions) and the OCD should be considered for quality properties.
2) The software developer fills in the Property Specification Form. The properties of the CSCI object apply to every entity in the OID, Behavior Diagram, and OCD that have Data Dictionary entries; this includes attributes. The software developer looks for quality goals for such areas as reliability, performance, usability, availability, safety, and security to define constraints on resources, such as memory and time. Measurable property requirements and tests to assess the status of each property are then established. The software developer identifies properties that are critical and those that must work reliably, as well as those that may be difficult to achieve and are therefore a high-risk and costly. A Property Specification Form for each property identified is completed and appropriately assigned to each diagram entity.
3) The software developer creates a Property Summary Table for the CSCI object. This table is a summary of all the Property Specification Forms completed for all identified properties of the CSCI object. In addition to the properties of operations performed by the CSCI object, the software developer includes properties from the user’s point of view, such as ease-of-use measures, time-to-learn measures, productivity measures, and error rates found per hour. The Property Summary Table can be grouped or it can be a subset of properties, such as critical and desired.
4) The software developer places the Property Specification Forms and Property Summary Table in the Requirements section of the SRS.
Outputs
Property Specification Forms and a Property Summary Table have been developed, verified, and placed in the Requirements section of the SRS.
(See activity 3.2.2.1)
Overview
In this activity, the software developer refines the Context Object-Interaction Diagram (OID) created in activity II.1.1 Develop Object-Interaction Specification and documented in the MIL-STD-498 Software Requirements Specification (SRS) (see Appendix E ).
The OIDs developed are the internal views of the CSCI object and its component objects. The internal OIDs show not only the component objects, but how a parent interacts with its child components, and how the child components interact among each other. The Context OID is recursively decomposed until the develop reaches objects that are atomic. The highest abstraction level begins with the first internal OID of the CSCI object that shows its immediate component objects. In turn, each component object is decomposed, describing a more refined abstraction level until all component objects are completely decomposed, and the appropriate Data Dictionary entries are made.
Roles and Responsibilities
The software developer constructs the internal OIDs with their corresponding Data Dictionary entries.
Controls
See parent activity 3.2.2.1 Develop Architectural Design.
Inputs
The CSCI External Interface Requirements section of the SRS with the Context OID and the Behavior Diagrams from the Required States and Modes section of the SRS.
Procedures
OOSD begins with the Context OID and works down (except where reusing OIDs) in a "breadth-first" approach concentrating horizontally on creating one abstraction level for the CSCI object, and proceeds to represent the Behavior Specification and Object-Class Specifications, then repeats the process for the next lower abstraction level. By identifying the behavior and classes of each component object at the parent level, the proper component objects for the lower abstraction level are easier to identify. Figure II.2.1-1 depicts the object decomposition concept diagram.
The OID notations are explained for objects and interactions in Colbert’s OOSD methodology [Colbert, 1995] . The OOSD architectural design uses a four-step iterative approach as follows:
Figure II.2.1-1 Example of Object Decomposition Concept Diagram (System = CSCI)
1) Start to construct an OID for the internal view of parent object. The parent object begins with the CSCI object, and afterward the parent objects are component objects that are complex (i.e., have their own component objects). The major references are the parent’s external OID (the diagram shows where the parent is used to build a higher-level object) and the parent’s External Behavior Diagram. An internal OID is created by adding the proper OID notations. To create the internal OID, the software developer performs the following substeps:
A) Titles the internal OID(s).
B) Draws the enlarged parent object. In the middle of the page, enlarge the parent object to include all of its component objects.
C) Draws objects with which the parent object interacts around the enlarged parent object. The objects placed around the enlarged parent object are the same objects with which it interacted before being enlarged. The objects surrounding the enlarged parent object are shown as off-page connectors indicating the object, interaction type, and data flow.
The first internal OID shows the enlarged CSCI object with the external objects. The second and subsequent OIDs describe the internals of complex component objects making up the parent object.
D) Draw all interactions between parent object and its external objects. Copy the interactions shown on the external diagram of the parent object.
2) Design the implementation of the parent object, describing the appropriate component objects and their interactions. The components may be new objects that need to be designed and implemented, or objects in a library (or whose class is in the library) that are reused.
The OOSD method develops component objects by applying a set of Object Decomposition Guidelines (also known as "heuristics"), such as a component may be created to manage each external object, and using the CSCI object’s properties to determine which design best satisfies the CSCI’s required operation characteristics. The Object Decomposition Guidelines are as follows:
A) Design component objects by modularizing the parent’s structure and behavior. Use the parent’s OID and behavior description.
B) Generally, more than one set of objects can implement a parent object. A set of objects implements the parent object if the component objects when combined with the parent’s internal view, implements all of the parent’s interactions as described in the external view of the parent. The combined external behavior of the components, when combined with the internal behavior of the parent, implements the external view of the parent’s behavior, and the combined components meets at least the worst-acceptable levels of all critical properties. If more than one set of components meets these requirements, then analyze the trade-offs among the alternative designs and select the design that best meets the planned levels of all properties.
C) Represent "real world" parts of the parent object needed for abstraction. A part is needed only:
If part information is set or requested by operations on the parent, and cannot be adequately represented as an attribute of the parent or other parts, and
Any behavior performed by the part is not required for the abstraction of the current system, or
Can be adequately represented as behavior of the parent or other parts.
However, a "real world" part of the parent object still may be desirable for supporting later enhancements (at a cost of adding complexity).
Parts of a passive parent’s object must be passive (reassess the passive parent object if it seems parts should be active).
D) Create an object to manage or monitor each external object with which the parent interacts, unless this behavior is the only responsibility of the parent object, or another identified component is assigned this responsibility. In general, the responsibility for managing or monitoring each external object should be assigned to a separate component. However, one component may be created to manage multiple externals when the behavior associated with managing or monitoring them is highly coupled. Using one component to manage or monitor multiple components may raise maintenance and enhancements costs. A "manager" or "monitoring" component is most likely active.
E) Create one or more objects to decouple the monitor and manager objects, as necessary to achieve response time and throughput properties required of each monitor/manager. Typically, monitor and manager objects need to be responsive to their external objects. Direct interactive communication with other monitors/managers often can result in race conditions, deadlocks, or failures to respond to external objects as required. In general, defer the decision to decouple until the implementation of each object and interaction is selected (i.e., during detailed design), and until the operational characteristics are analyzed. The decoupling typically adds complexity and obscures the necessary fundamental communication.
F) Create an active object for each independent periodic or aperiodic behavior not directly related to manager/monitor objects, unless this behavior is the only responsibility of the parent object, or a part with this responsibility is identified.
G) For each attribute that was identified for the parent object, create a passive object to maintain the attribute value if the information is not maintained by another component, and if information cannot be calculated based on information from other objects (e.g., components of the parent or external to the parent).
The diagram representing an object’s internal view must show all of the same interactions between the object and the external objects, as the diagram representing external views of the object. In some cases, an interaction between the parent object and an external object, may upon refinement, be implemented by an interaction between a parent’s component and the external object. The following guidelines for identifying interactions are provided:
3) Any interaction where an operation perceived as being requested by a parent object in the external view may actually be requested by one or more component objects. (Because the components cannot be seen from the outside of the parent object, their requests appear to originate from the parent.)
4) An "internal" interaction, in which another CSCI object requesting an operation of the parent, is retained as an interaction with the parent object in the internal view. (Objects are not allowed to violate the interface of another object.)
5) An interface interaction, in which an object external to the CSCI object is requesting a service of the "current" parent object in the external view of the parent, may be implemented by an interaction between the external object and a component object (i.e., "delegated to a component") in the parent’s internal view. (The interaction between the CSCI external and parent object, which is visible in the parent’s "black box" view, is an abstraction of the interaction between the external object and the component object.) Allowing the CSCI external to directly communicate with components violates hiding of components, but interactions with external objects typically cross hardware-software boundaries. Hardware does not know about software boundaries. That is, some objects are logically components of both software and hardware. The delegation of the interaction eases maintenance by localizing behavior and structures related to the external object.
The following substeps should be performed using the object decomposition guidelines described above to identify appropriate component objects and their interactions:
6) Add component objects to the OID. Determine if an object must be new, or if an existing object can be reused. Assign a project-unique identifier (PUI), and make a corresponding Data Dictionary entry (see activity II.2.4 Refine Data Dictionary) by filling out an Object Form (see Appendix C ) for each added object.
7) Add interactions between component objects, parent and component objects, and external and component objects (interface interactions only) to the OID.
8) Repeat steps 1 and 2 for each active and complex passive object in an OID. Both an active and complex passive object decompose into component objects that make up the parent object.
9) Create the Object-Hierarchy Diagrams (OHD) that summarize the assembly-part relation between objects in a CSCI. The OHD illustrates which objects are components of other objects, and gives a different view of information represented in the OIDs. Use the following to create OHDs:
A) Place the parent object at the top of the OHD page (begin with the CSCI object).
B) Title the OHD.
C) Place component objects below the parent in the OHD. Identify components from the parent’s OID and insert component’s notation, name, and PUI. The external objects are ignored.
D) Draw all component objects that are decomposed in the OID.
E) Create a connection from the parent object to the component objects.
F) Repeat Substeps A through E for each object in substep E.
Outputs
The updated Context OID and internal OIDs in the Interface Design section of the (architectural) SDD .
The OHDs placed in the CSCI Component section of the (architectural) SDD .
Overview
In this activity, the software developer determines the behavior of the component objects of the computer software configuration items (CSCI) to construct the Behavior Diagrams. This is done is a manner similar to that in subactivity II.1.2 Develop Behavior Specification .
Roles and Responsibilities
The software developer defines and constructs the Behavior Diagrams and their corresponding Data Dictionary entries. Extended Behavior Diagrams are created for all objects, and, internal Behavior Diagrams are created for complex objects.
Controls
See parent activity 3.2.2.1 Develop Architectural Design.
Inputs
The external behavior descriptions as documented in the Required States and Modes section of the MIL-STD-498 Software Requirements Specification (SRS) (see Appendix E).
The component Object-Interaction Diagrams (OID) and Object-Hierarchy Diagrams (OHD) created in activity II.2.1 Refine Object-Interaction Specification.
Procedures
1) Starting with the CSCI parent object, the software developer performs the following substeps for each parent object:
A) Reviews the internal OID (see activity II.2.1 Refine Object-Interaction Specification) and the object’s external behavior descriptions (documented in the Required States and Modes section of the SRS). Identify the object’s actions based on requests from external objects. Scenarios, as described in activity 3.1.1.3 Develop Operational Scenarios , can be used to determine this.
B) Identifies the conditions causing the object to request operations of its component objects. Based on this information, identifies the object’s internal states and conditions.
C) Identifies all possible sequences of conditions and actions.
2) Create Behavior Diagrams to illustrate the object’s internal behavior, using the diagramming method described in Colbert’s Object-Oriented Software Development (OOSD) methodology (Colbert, 1995). Identify the start state (by drawing a "default" transition) and the other required states (a state for each operation and other "decision" states as appropriate). These diagrams are placed in the Concept of Execution section of the MIL-STD-498 (architectural) Software Design Description (SDD ) (see Appendix E).
3) Verify that the parent’s external behavior is correctly implemented. Verify that the combined external behavior of the component objects, and the internal behavior of the parent object implements the external (i.e., black-box) behavior of the parent object.
4) Re-analyze schedulability of system activities.
5) The scenarios and Behavior Diagrams are placed in the Concept of Execution section of the (architectural) SDD .
Outputs
The completed external behavior specification consisting of scenarios and Behavior Diagrams for all objects and documented in the Concept of Execution section of the SDD .
The internal behavior descriptions for all complex objects (e.g., scenarios and Behavior Diagrams) documented in the Concept of Execution section of the (architectural) SDD .
Overview
In this activity, the software developer refines the Object-Class Diagram (OCD) created during activity II.1.3 Develop Object-Class Specification . In addition, OCDs are created for the component objects identified and shown in the internal Object-Interaction Diagrams (OID) for the computer software configuration item (CSCI) object created during subactivity II.1.1 Develop Object-Interaction Specification .
Roles and Responsibilities
The software developer constructs the OCDs with their corresponding Data Dictionary entries.
Controls
See parent activity 3.2.2.1 Develop Architectural Design.
Inputs
The MIL-STD-498 Software Requirements Specification (SRS) (see Appendix E) that includes the OCD (see activity II.1.3 Develop Object-Class Specification).
The component OIDs and Object-Hierarchy Diagrams (OHD) (see activity II.2.1 Refine Object-Interaction Specification ).
The component Behavior Diagrams (see activity II.2.2 Refine Behavior Specification ).
Procedures
This activity identifies and defines the classes, operations, attributes, instances, and relations between the classes required to describe the component objects identified and shown in an internal OID of a parent. Note: A parent begins with the CSCI object and afterwards a parent is any complex component object. There are two kinds of OCDs: (1) an external view for all classes and objects, and (2) an internal view for complex classes.
The approach to constructing the External and Internal OCDs is similar to creating the Context OCD for the CSCI object. The main difference is the external and internal OCDs focus on component objects of the parent classes, starting with the CSCI class. Each component object within the parent class, its operations, and its attributes and relation with other classes, are identified and shown in an External OCD. An internal class diagram is created for each parent class, using a corresponding internal OID of the parent object, showing the class’ component objects and relations.
The following steps describe the approach to constructing the External and Internal OCDs, but the actual procedures are the same as those in the requirements analysis activities:
1) Create an OCD for each class (other than external classes) in the Context OCD. The External OCD for a class is a reusable class description. The software developer starts with a detailed OCD for the CSCI class and labels the diagram with the class name and assigned unique identifier.
2) Identify any parts, members, or contents of the "focus" class (i.e., the class being defined by this OCD). The software developer adds object icons for parts, members, or contents to the class icon.
3) Determine the class for each part, member, or content of the OCD "focus" class. The software developer determines if an existing class, developed for another system object or an existing class in a reusable-component library can be reused. If the class is not represented in this OCD, the software developer creates a class icon. If every instance of the new class must be a component of the "focus" class, then the new class icon is a hidden component of the "focus" class (placed inside the "focus" class). It is a visible component of the "focus" class (attached to the edge of the "focus" class) if instances of the new class can be created only when it is possible to create instances of the "focus" class. Otherwise, the new class is external to the "focus" class, and the software developer places the class icon outside the "focus" class. An OCD for a new class may be started, and the Data Dictionary entry may be made (see activity II.2.4 Refine Data Dictionary ).
4) Draw the "instance of" relation from parts, members, or contents of the "focus" class to the appropriate class icon.
5) Determine the attributes of the "focus" class by reviewing the Behavior Description of the CSCI object to identify attributes, such as values maintained and time periods. Enter a description of the system class attributes in the Data Dictionary.
6) Define the class of every attribute. The software developer repeats the process of step 3.
7) Add "uses" relation from the "focus" class to every attribute class.
8) Determine operations for the OCD "focus" class. The software developer reviews each OID containing objects that are instances of the "focus" class to identify interactions where these objects are the "performing" object, and to determine the operation name, operation parameters (from flows), and each parameter class. The software developer then reviews the behavior description of objects that are instances of the "focus" class, looking for logical and mathematical operations. If the "focus" class has subclasses, the software developer determines which subclass operations should be defined for the superclass. For each unique operation, the software developer attaches an operation icon to the "focus" class icon. An operation is unique if it has a unique name and unique combination of classes for parameters. The software developer verifies that the operation is not merely a different name for another class operation.
Optionally, add an operation icon (including parameter descriptions) to the class icon of the "focus" class on the OCD where the "focus" class appears as a "using" class, and the operation is requested by the "using" class. The operation icon clarifies which operations are used, but adds complexity to the OCD of the "using" class. A Data Dictionary entry is added for each parameter (see activity II.2.4 Refine Data Dictionary ).
9) Define all parameter classes for every operation. The software developer determines if an existing class can be reused (i.e., a class developed for another system object, or check other OCDs or a class in a reusable-component library). Add a class icon if the class is not represented on an OCD, and make an entry in the Data Dictionary (see activity II.2.4 Refine Data Dictionary).
10) Add the "uses" relation from the "focus" class to every parameter class.
11) (Optional) Add "uses" relation from operations of the "using" class to parameter classes of the operation. (This specifically shows which operations have parameters that are instances of the specific class, at the cost of additional complexity on the "focus" class diagram.)
12) If the "focus" class is a collection class, identify the selector class (if needed for the abstraction). If the "focus" class is a new class, create a class icon, and draw a "selected by" relation from the "focus" class icon to the selector class.
13) Identify related classes. The software developer determines the relation type (e.g., "subclass of" or "derived from") and draws a relation from class icon to class icon.
14) For each class identified in steps 3 through 13, repeat steps 2 through 13.
15) The OCDs are placed in the CSCI Components section of the MIL-STD-498 (architectural) Software Design Description (SDD ) .
Outputs
The external, and, as appropriate, internal OCDs for the component classes of the CSCI documented in the CSCI Components section of the (architectural) SDD .
Overview
The software developer refines the Data Dictionary that summarizes all known information for the entities identified and shown in the internal Object-Interaction Diagrams (OID) and their corresponding Behavior Diagrams and Object-Class Diagrams (OCD).
Roles and Responsibilities
The software developer maintains all entities in the Data Dictionary for the OIDs, Behavior Diagrams, and OCDs that describe decomposing the computer software configuration item (CSCI) object into components.
Control
See parent activity 3.2.2.1 Develop Architectural Design.
Inputs
Component OIDs and OHDs (see activity II.2.1 Refine Object-Interaction Specification ).
Internal Behavior Diagrams (see activity II.2.2 Refine Behavior Specification ).
Component OCDs (see activity II.2.3 Refine Object-Class Specification ).
SRS which contains the Data Dictionary created during activity II.1.4 Develop Data Dictionary .
Procedures
1) The Data Dictionary is iteratively refined with subactivities II.2.1 Refine Object-Interaction Specification, II.2.2 Refine Behavior Specification, II.2.3 Refine Object-Class Specification, and II.2.5 Refine Property Specification . An entry is made in the Data Dictionary for each diagram entity produced in architectural design activities. The Object-Oriented Software Development (OOSD) Data Dictionary forms are the same as those described in activity II.1.4 Develop Data Dictionary in requirements analysis.
2) The Data Dictionary forms may be placed in the MIL-STD-498 (architectural) Software Design Description (SDD ) (see Appendix E) as an appendix.
Outputs
The updated Data Dictionary that is an appendix to the (architectural) SDD .
Overview
In this activity, the software developer uses the Property Specification Forms and Property Summary Table (see Appendix C) to document the properties of each object and its operations as identified in the architectural design.
Roles and Responsibilities
The software developer completes the Property Specification Forms and the Property Summary Table.
Controls
See parent activity 3.2.2.1 Develop Architectural Design.
Inputs
The Requirements section of the MIL-STD-498 Software Requirements Specification (SRS) (see Appendix E ) which includes the Property Specification Forms and Property Summary Table developed in activity II.1.5 Develop Property Specification .
The component Object-Interaction Diagrams (OID) and Object-Hierarchy Diagrams (OHD) created in activity II.2.1 Refine Object-Interaction Specification.
The Behavior Diagrams created in activity II.2.2 Refine Behavior Specification .
The component Object-Class Diagram (OCD) and component External/Internal OCDs created in activity II.2.3 Refine Object-Class Specification .
The Data Dictionary created in activity II.1.4 Develop Data Dictionary .
Procedures
1) The properties of each object identified in the OIDs are identified by defining the qualities and constraints of each object in a measurable manner. The properties of the parent object as documented in the Requirements section of the SRS are allocated to some (possibly all) subset of the component objects. Any new properties are determined based on the object’s interactions and behavior. The object’s Behavior Diagrams and OCDs, and the Data Dictionary may be referenced to help identify these properties. Guidance on determining the object’s properties is in the OOSD documentation [Colbert, 1995].
2) A Property Specification Form (see Appendix C ) is completed for each property of each object or operations.
3) A Property Summary Table (see Appendix C ) is created for each object. The software developer identifies the critical properties (i.e., those properties which, if not met, result in a system failure) in this table.
4) The software developer places the completed Property Specification Forms and Property Summary Table in the CSCI Components section of the MIL-STD-498 (architectural) Software Design Description (SDD ) (see Appendix E).
Outputs
The Property Specification Forms and Property Summary Table placed in the CSCI Components section of the (architectural) SDD .
(see activity 3.2.3.1)
Overview
The software developer uses the Object-Interaction Diagrams (OID), Behavior Diagrams, and Object-Class Diagrams (OCD) created during the architectural design to develop a Ada-specific representation of the computer software configuration item (CSCI). The software developer uses Ada graphic notations to represent selected implementations for objects, classes, and their operations and interactions. The hierarchical relationship among CSCI software units and the dependencies between the units also are defined. The Ada implementation products are one or more Ada Structure Diagrams (ASD), Ada Visibility Diagrams (AVD), and Program Design Language (PDL) (known as "pseudo-code") descriptions of each software unit’s interface.
Roles and Responsibilities
The software developer develops the language-specific software architectural specification.
Controls
See parent activity, 3.2.3.1 Develop Unit Detailed Design.
Inputs
The MIL-STD-498 (architectural) Software Design Document ( SDD ) (see Appendix E).
Procedures
In this activity, the software developer creates a language-specific implementation (combining graphic and text representations) of each object and class defined in the architectural design OIDs and OCDs in the SDD . Generally, the software developer produces the graphic representations and then the text representations.
Because Ada is the assumed language, this activity describes the Ada implementation of the architectural design. To accomplish the Ada implementation, the software developer uses a modified form of Ray Buhr’s notations [Buhr, 1984] for the graphic representations as described in [Colbert, 1995] , and Ada PDL for the text representations.
While partial automation is available for generating the language-specific representation of objects and classes defined in architectural design, knowledge of the language is needed for good choices between alternate representations. Some computer-aided software engineering (CASE) tools automate generating Ada PDL from the respective language-specific graphic notations and vice versa.
In this Guidebook, PDL consists of language-specific, compilable code providing a text explanation of the software unit’s purpose and variables. PDL uses header information and a series of formal, step-by-step, high-level code statements to capture the interfaces, major logic, and dependencies of each software unit. With PDL, the software developer communicates the design’s exact intent to reviewers and coders. This activity focuses on creating interface PDL (i.e., CSCI’s skeleton structure depicting all interfaces and data structures).
Development of the detailed design with the Object-Oriented Software Development (OOSD) method uses an iterative approach. The software developer performs the following steps to generate the Ada language-specific implementation.
1) Creates the ASD by performing the substeps described in the following paragraphs (see [Colbert, 1995] for notation).
A) Selects an implementation for each object in the OIDs (as documented in the Interface Design section of the (architectural) SDD ), based on the expectation that the implementation best satisfies the object’s properties, and adds an icon for each implementation to the ASD. To represent each active object, the software developer adds one of the following Ada components to the ASD:
A task if the active object has no active components or has an active internal behavior.
A package if its active components all map to tasks.
A subsystem (i.e., collection of packages) if some of its active components map to packages.
To represent each passive object, the software developer adds one of the following Ada components:
An object (variable) if the passive object is not unique.
A package if the passive object is unique and contains only components that map to Ada objects.
A collection of packages if the passive object is unique and contains only components mapping to packages.
B) Selects one or more implementations to represent each interaction between objects shown in the OIDs (documented in the Interface Design section of the (architectural) SDD ) and add the appropriate interactions between the corresponding Ada software objects. For each OID operation, the software developer adds one of the following Ada components to the ASD:
A subprogram in a class package if the owning object maps to an Ada object (except tasks).
A subprogram in an object package if the owning object maps to a package or subsystem.
A task entry if the owning object maps to an Ada task.
To implement each operation request, the software developer adds one of the following call types from the appropriate Ada component to the appropriate subprogram or task entry:
A basic call if the OID notation indicates a simple, synchronous request.
A timed call if the notation indicates a timed request.
A conditional call if the notation indicates a balking request.
If the notation indicates an asynchronous request, the software developer defines a buffer.
For each object and data flow, the software developer adds formal parameters to the appropriate subprogram or task-entry declaration, and adds actual parameters (as described in the calls shown in the Behavior Diagrams of the callers) to the appropriate subprogram or task-entry calls. For each error flow, the software developer adds an exception declaration to the appropriate class or object package, and adds an exception propagation to the appropriate subprogram or task-entry calls.
C) Selects an implementation for each class in the OCDs (from the CSCI Components section of the (architectural) SDD ) and adds the appropriate icons to the ASD. To implement each class represented in the OCD, the software developer selects one of the following Ada components:
A subtype if the class is a constrained subclass.
A type if the class corresponds to an Ada primitive type, and the implementation details do not have to be hidden.
A derived type if the class is derived from another class.
An abstract-type package if the class does not correspond to an Ada primitive type, and the class is not a parameterized class. The software developer must create type and package icons to represent an abstract-type package.
A generic abstract-object package if the parameterized class generates an object when instantiated.
A generic abstract-type package, if the class is a metaclass. The software developer must create package and type icons to represent an abstract-type package.
The software developer localizes each component in an Ada program unit or subsystem, as appropriate.
2) Creates the AVD. Some tools may automatically generate the AVD and formal interface descriptions from the ASD. The AVD shows the dependency, that is, the required "withing" so one software component can see (i.e., visible) needed operations, data, or types belonging to other components. The software developer performs the following substeps to create the AVD.
A) Copies the hierarchy of Ada program units from the ASD.
B) Adds dependency arrows (see [Colbert, 1995] for notation), as follows:
Between the program unit calling an operation and the program unit owning the operation (the software developer reviews the OIDs to identify these program units).
Between the program unit declaring objects, types, parameters, etc., and the program unit owning the objects, types, parameters, etc., on which they are based. The software developer reviews the OCDs to identify these program units.
The software developer specifies whether the dependency belongs to the declaration, body, or subunit.
3) Creates a formal description of each unit’s interfaces. The software developer performs the following substeps:
A) Creates a PDL description of all interfaces for each software unit in the ASD. In Ada, PDL descriptions are compilable packages that include their functions and procedures, externally visible data, and all interfaces and dependencies (i.e., withing) among packages (objects) and subprograms (i.e., operations, task-entries). In other words, PDL is the result of mapping the language-specific software architecture into high-level Ada code. This high-level code communicates the design concept to the level of items such as dependencies, major logic branches, and error-handling strategies. The software developer delays the design of package bodies (i.e., the hidden package part) until activity II.3.2 Refine Behavior Specification is completed. For now, the software developer nulls each body and any procedures or functions.
In this step, the software developer creates the prolog of compilable Ada packages that identifies all "withing" of packages, as well as all interfacing functions and procedures, visible data variables and structures, task declarations, major logic decisions and branching, error handling, and call dependencies. Some CASE tools (e.g., ObjectMaker) automatically generate Ada PDL from the language-specific diagrams.
B) Completes the CSCI subsystem or packaging structure , and add types and objects needed to implement the interface description.
C) Processes all descriptions with a PDL analyzer, which may be a compiler. The exact nature of the PDL description depends on the design language used. In this case, because the software developer is using Ada, the description should have Ada-like features, such as modularity, information hiding, strong typing, and detailed instructions as comments or compilable Ada instructions.
4) Places the ASDs, AVD, and PDL in the CSCI Detailed Design section of the (detailed) SDD .
Outputs
ASDs, AVD, and interface Ada PDL of each unit’s interfaces (using Ada PDL) in the CSCI Detailed Design section of the (detailed) SDD .
Overview
In this activity, the software developer uses Program Design Language (PDL) to show the dynamic behavior of the language-specific architecture created in activity II.3.1 Develop Language-Specific Software Architecture Specification . The software developer also shows that the language-specific behavior implements the required computer software configuration item (CSCI) behavior.
Roles and Responsibilities
The software developer creates the PDL for all software units describing their defined operations (e.g., functions, procedures, task entries, address interrupts).
Controls
See parent activity 3.2.3.1 Develop Unit Detailed Design.
Inputs
The external and internal Behavior Diagrams from the Concept of Execution section of the MIL-STD-498 (architectural) Software Design Document ( SDD ) .
Ada Structure Diagrams (ASDs), an Ada Visibility Diagram (AVD), and Ada PDL of each unit’s interfaces as developed in activity II.3.1 Develop Language-Specific Software Architecture Specification .
Procedures
1) Review the internal Behavior Diagram of each complex object and the external Behavior Diagram of each atomic object in the Object-Interaction Diagrams (OIDs) (see activity II.3.1 Develop Language-Specific Architecture Specification) and revise the ASD, if necessary. For each task (or task type), the software developer determines when each entry call originates and, thus, when it must be performed. If the object’s Behavior Diagram shows that it is a request of an operation of another object while the object is processing a request of its own operations, then the corresponding task calls the operation of the corresponding Ada component while performing the accept of its own corresponding entry. If the Behavior Diagram shows that the object issues a particular call after it completed processing a particular request, then the corresponding task issues its call after completing the corresponding accept statement, possibly while in a select statement. If the Behavior Diagram shows that a particular operation request occurs because of a condition such as a time-out, an error flow return, or testing some value, then describe the corresponding behavior in the task.
Example:
In the task, if the call occurs as a result of the return of a particular error flow, add an exception handler to the task (or an appropriate inner block), and add the call.
For each object or class package, unless the operation request relates to initializing the object or class, the corresponding call is performed when one or more subprograms in the package is executed. The software developer determines which subprogram(s) make each call. If the operation request relates to an initialization, the software developer must decide whether the corresponding call should be made in the initialization of a variable declaration, the sequence of statements associated with the package body, or an initialization subprogram.
If an object mapped to a task waits in a state for a request of any one of multiple operations, the software developer creates a select statement around the accept statements for the corresponding task entries. If a time-out can end the wait, the software developer adds an entry labeled "delay."
If an object mapped to a task will wait for requests in different states for different sets of operations, the complexity of the communication protocol affects the way the software developer represents the task creation. If the communication protocol is relatively simple, which is true in most cases, the software developer may implement it as follows:
A) Create a select statement around accept statements for the entries corresponding to each operation in the union of sets.
B) Create a state variable and names values for the different states in the Behavior Diagram.
C) Add guards to the alternatives in the select statement that determine whether an entry call should be accepted based on the value of the state variable.
If the communication protocol is complicated (e.g., a certain task must wait for a second request before completing the current communication), the software developer skips to step 2 and creates a PDL description of each software unit. Creating a graphic representation of a complex communication protocol is too inefficient.
2) The software developer creates a PDL description of each software unit in the ASD. In the PDL description, the software developer captures each unit’s details from the ASD and adds any details from the Behavior Diagrams that are not represented in the ASD.
3) The software developer verifies that the PDL description of the software units’ behavior is correct. The software developer compares the description of the software behavior to the Behavior Diagrams. If the software developer created executable PDL (or code), the software developer executes the PDL and compares the results against the operational scenarios, which may have been developed in the preliminary design phase.
Outputs
Ada PDL for all software units in the ASDs placed in the CSCI Detailed Design section of the (detailed) SDD .
Overview
The software developer refines the Object-Class Diagrams (OCD) produced in activity II.2.3 Refine Object-Class Specification, capturing any language-specific classes and relations. This is mainly maintaining the documentation, and is useful when reusing the detailed design. To accomplish this, the software developer reviews the language-specific software architecture produced during activity II.3.1 Develop Language-Specific Software Architecture Specification, and updates the OCDs and their corresponding Data Dictionary descriptions to include any language-specific classes and relations.
Roles and Responsibilities
The software developer revises the OCDs produced during the architectural design activities (see activity II.2.3 Refine Object-Class Specification ).
Controls
See parent activity 3.2.3.1 Develop Unit Detailed Design.
Inputs
The Object-Class Specification as documented in the CSCI Components section of the MIL-STD-498 (architectural) Software Design Document ( SDD ) .
The Ada Structure Diagrams (ASD) produced in activity II.3.1 Develop Language-Specific Software Architecture Specification .
The refined Data Dictionary from the (detailed) SDD (see activity II.3.4 Refine Data Dictionary ) which is maintained throughout the detailed design effort.
Procedures
In this activity, the software developer refines the object-class relationships of the computer software configuration item (CSCI), identifying changes to the class structure or relations resulting from the language-specific implementation. The software developer identifies the classes of any implementation-specific objects, and determines which objects share the same class and any new relations between classes (including implementation-specific classes). The software developer then refines the OCDs, and creates or refines Data Dictionary entries for objects, classes, operations, parameters, and attributes accordingly.
The following steps describe revising the Object-Class Specification (as documented in the CSCI Components section of the SDD ) using a language-specific implementation.
1) Incorporate any changes needed to implement the design with the selected language and technology into the OCDs for existing classes and objects. The software developer compares each OID with the corresponding Ada structure diagram, and identifies any objects that were restructured to accomplish the language-specific implementation, such as any component objects given new parents or any objects whose operations were changed (e.g., the addition of initialization subprograms). The software developer also identifies any classes given new, implementation-specific parts, members, or contents.
The software developer determines whether each identified change applies to all objects of the same class. If it does, the existing OCD class icon is revised to reflect the change. If not, a new class is defined, and a new class icon is added to the OCD. The software developer then determines whether the new or original class should be a subclass of another class, updates the relations shown in the OCD, and attaches object icons representing parts, members, or contents to the class icon.
2) Define a class for any new implementation-specific parts, members, or contents. The software developer determines if it is possible to reuse an existing class, either developed for another object in this CSCI (other OCDs are checked) or found in a reusable-component library. If the class is not represented in the OCD and the new class is unique to the focus class (i.e., the class defined by this OCD), the software developer creates a class icon and places it inside the focus class. Otherwise, the new icon is placed outside the focus class. The software developer has the option of creating a new OCD to represent a new class. The software developer adds an entry for a new class in the Data Dictionary, or refines an existing class entry (see activity II.3.4 Refine Data Dictionary).
3) Draw an "instance of" relation from each implementation-specific part, member, or content of the focus class to the appropriate class icon.
4) Create an OCD for each implementation-specific class (to be a reusable class description). The software developer creates an OCD for each new class added to support one or more implementation-specific objects, and labels the diagram with the class name and unique identifier.
5) Identify any parts, members, or contents of the focus class. The software developer attaches object icons for parts, members, or contents to the class icon.
6) Determine the class of each part, member, or content of the new classes. See step 2.
7) Draw an "instance of" relation from each part, member, or content of the focus class to the appropriate class icon.
8) Identify any focus class operations. The software developer reviews each ASD showing objects that are focus class instances. The software developer identifies all operations performed by these objects, and determines each operation’s name, parameters, and parameter classes. If the focus class has subclasses, the software developer determines which subclass operations are properly defined for the superclass.
For each unique focus class operation, the software developer attaches an operation icon to the focus class icon. An operation is unique if it has a unique name and combination of parameter classes. The software developer must verify that an operation is not merely a different name for another class operation.
The software developer also has the option of depicting the same OCD operation whose focus class requests the operation. In this OCD, the focus class is the using class. The software developer attaches the operation to the using class performing the operation. This clarifies which operations are used, at the cost of complicating the OCD of the using class.
The software developer adds a Data Dictionary entry (see activity II.3.4 Refine Data Dictionary ) for each operation (including a description of the operation’s parameters) and parameter.
9) Define all parameter classes of every operation. The software developer determines if it is possible to reuse an existing class, developed for another system object (other OCDs are checked) or found in a reusable-component library. A Data Dictionary entry is made if the class is not recorded (see activity II.3.4 Refine Data Dictionary ).
10) Add a uses relation from the focus class to every parameter class.
11) (Optional) Add a uses relation from the operations of the used class to the operation’s parameter classes.
12) If the focus class is a collection class, identify a selector class (if needed for abstraction). If the selector class is a new class, the software developer creates a class icon to represent it, and draws a "selected by" relation from the focus class icon to the selector class icon.
13) Identify related classes. The software developer determines the type of relation between the related classes (e.g., "subclass of" or "derived from"), and draws the relation from class icon to class icon.
14) For each class identified in steps 6 through 13, repeat steps 6 through 13. The software developer has the option of creating an OCD for each assembly, collection, or container relation class, and referring to the internal OIDs of the class objects to determine the relation class(es).
Outputs
The refined OCDs placed in the CSCI Components section of the (detailed) SDD .
Overview
In this activity, the software developer refines the Data Dictionary created in activity II.2.4 Refine Data Dictionary to capture new information concerning the Object-Class Diagrams (OCD).
Roles and Responsibilities
The software developer updates and maintains the Data Dictionary.
Controls
See parent activity 3.2.3.1 Develop Unit Detailed Design.
Inputs
The MIL-STD-498 (architectural) Software Design Document ( SDD ) (see Appendix E) containing, in an appendix, the Data Dictionary created in activity II.3.4 Refine Data Dictionary.
The revised OCDs from activity II.2.3 Refine Object-Class Specification .
Procedures
1) The software developer adds entries to the Data Dictionary defined in activity II.2.4 Refine Data Dictionary for all new classes, operations, and parameters defined in the revised OCDs from activity II.3.3 Refine Object-Class Specification . The appropriate forms for each type of Data Dictionary entry are described in Table II.1.4-1 in activity II.1.4 Develop Data Dictionary .
2) The software developer includes the updated Data Dictionary as an appendix to the (detailed) SDD.
Outputs
The updated Data Dictionary which is an appendix to the (detailed) SDD .
Overview
In this activity, qualities and constraints for the Ada-specific objects and their interactions are defined and documented.
Roles and Responsibilities
The software developer defines the qualities and constraints for the Ada-specific objects and their interactions, and documenting them on the Property Specification Forms and the Property Summary Table (see Appendix C ).
Controls
See parent activity 3.2.3.1 Develop Unit Detailed Design.
Inputs
The Ada Structure Diagrams (ASD) and Ada Visibility Diagrams (AVD) as developed in activity II.3.1 Develop Language-Specific Software Architectural Specification.
The Program Design Language (PDL) as developed in activity II.3.2 Develop Behavior Specification .
The (architectural) Software Design Document ( SDD ) with the Property Specification Forms and Tables created during activity II.2.5 Refine Property Specification.
Procedures
1) The software developer identifies the architectural design objects or operations corresponding to each Ada object and operation as described in the ASDs and AVDs. The software developer then reviews the Property Specification Form and Property Summary Table associated with the architectural design objects or operations, and allocates these properties to the Ada-specific objects or operations.
2) The software developer determines any "new" properties based on the Ada implementation of the objects and operations. The software developer completes a Property Specification Form ( Appendix C ) for each new property and updates the Property Summary Table from the (architectural) SDD as necessary.
3) The software developer determines each property’s current level or value by analyzing the ASDs and AVDs of each software unit, and by testing the PDL description of the units’ behavior by examining the PDL descriptions, structure, and logic. The current level is documented in Item [11] on the Property Specification Form in Appendix C .
4) The software developer may make any necessary refinements to the ASDs, AVDs (see activity II.3.1 Develop Language-Specific Software Architecture Specification), or PDL (see activity II.3.2 Develop Behavior Specification) to achieve the required limits for critical properties.
Outputs
The updated Property Specification Forms and Property Summary Table (see Appendix C).