Page Last Updated: Wednesday, 04 November 2015 13:35 EDT, (c) 2005, 2008

Successful Design, Development, and Integration of UA SoS:
Initial Findings from the Commonality Pathfinder Project

Dr. Dean S. Hartley III
Hartley Consulting

Dr. Richard C. Goldfinger, Ms. Kara L. Kruse, Mr. Lawrence P. MacIntyre,
Dr. Andrew Loebl, Dr. Lee M. Hively
Oak Ridge National Laboratory

Mr. Michael J. McDonald
Sandia National Laboratory

1. Introduction:

This document describes recent work by the Future Force Integrated Support Team (FIST) under the Unit of Action (UA) Program, SMART Director. The UA is an implementation of the Army's Future Combat System (FCS). The FIST was formed and organized to address critical technical and analytical challenges that had been identified throughout the earlier Concept Exploration phases of the UA program. The purpose of the FIST Commonality Pathfinder Project has been to determine the impact of problems caused by insufficient exploitation of commonality and to advise on corrective measures.¹

Commonality determination is a process that reveals a deeper understanding of how to successfully design, develop and integrate the Future Combat System (FCS) Unit of Action (UA) System of Systems (SoS). Design and development share the responsibility of accomplishing integration so that functionality will not be compromised and missions jeopardized. Where interdependencies exist in the SoS they must be precisely understood. There is an array of features, functions, processes, steps, and tasks that define the FCS SoS and that are required to exercise the FCS capabilities. These complex characteristics prescribe a unique and perhaps one-of-a-kind cybernetic concept.

We assert that the FCS can be characterized as a complex adaptive system² and, once fielded, will exhibit emergent properties that cannot be understood or predicted by studying the system elements in isolation. This assertion is based on three observations.

1. Warfighting itself is increasingly being recognized as a complex adaptive system.³ War is a multi-layered human enterprise. As such, it has many of the features studied in complexity theory work that is focused on social systems and economics.

2. Modern war's focus on the role of information is generally increasing interconnectedness that will, in turn, tend to sharpen the effects of its complexity. Specifically, emergence, a key attribute of complex adaptive systems, is characterized in the complexity literature as an effect of system-level attributes related to information flows and distributed knowledge. Cooper specifically explores this issue in terms of the role C3I plays in war-making as a complex adaptive system.⁴

3. The technological systems that FCS relies upon have very similar architectural elements to recognized complex systems. For example, communications and agent technologies are both current topics in complex systems research.⁵

The shaping of the SoS emergent properties and behaviors must be treated as an operational requirement.

The basis upon which SoS integration is possible may lie entirely in how well commonalities are exploited once determined.

Commonality exploitation is more than code, or artifact re-use. The complex characteristics of the SoS share commonalities that involve much more than just code. Thus code reuse is merely one by-product of the SoS analysis needed. Exploiting commonality has benefits for the UA SoS that go far beyond the cost savings that are often argued as the major benefit of code re-use. It appears likely that the UA SoS will fail without explicit treatment of commonality in its broader sense, because without exploitation of the SoS commonalities, the SoS capabilities cannot be achieved and undesirable properties of the SoS will emerge.

Understanding FCS SoS commonality is a difficult challenge. New methods need to be developed for commonality determination. However, determining what commonalities exist is not enough. The commonalities must be exploited and that means assuring its contribution through design and development.

One U.S. military definition of commonality is "the utilization of the same doctrine, procedures or equipment."⁶ A white paper on UA by the Military Analysis Network states, "Significant capability enhancements will be achieved by developing multi-functional, multi-mission and modular features for system and component commonality that will allow for multiple state-of-the-art technology options for mission tailoring and performance enhancements. The Army will investigate possibilities for a FCS that is an innovative, multi-mission system, optimizing commonality of component and subsystems, affordability, deployability, survivability, and lethality to meet ground force requirements for the Objective Force."⁷ Moreover, the Army mandates commonality as a requirement for the UA: functionality of the simulations and the operational systems are equivalent or identical, regardless of use (i.e. "... garrison operations, training, field exercises and actual operations..."⁸).

The importance of commonality is widely recognized in various venues, which include the military, the software development community, the systems engineering community, as well as others. However, commonality has come to be recognized as only one component of a holistic approach that is required to achieve new operational expectations that are only possible since technological capabilities have reached current levels of performance. For example, the software community has moved beyond studying commonality and code re-use, alone, to a more holistic view of trying to improve what has come to be known as software development methodology (SDM). SDM is the documented collection of policies, processes and procedures used by a development team or organization to practice software engineering.⁹ The goal is to produce software that is more rapidly created, accurate, and reliable (i.e., not subject to unexpected properties or failure). The new techniques to encompass this goal include design patterns, scope, commonality and variability analysis (SCV) and others. We will use the concept of commonality to guide the exploration of these ideas and their impact on UA SoS development.

We begin by discussing and defining simple commonality concepts in Section 2. In Section 3, we switch gears to look at some of the elements that bear on defining the UA SoS. In Sections 4, 5, and 6, we return to software concepts; however, this time we look more deeply into the problem of taking advantage of commonality in a system whose capabilities are beyond the current state of practice and is as large and complex as the UA SoS. Section 4 briefly describes the software systems engineering, design and development methodologies that preceded Object Oriented (OO) methodologies and Section 5 describes OO methodologies. Section 6 describes some potentially useful newer methodologies. Section 7 concludes the text with a description of the implications of commonality and the state of systems design and development as they apply to the UA SoS. We conclude with an Appendix of definitions of terms, which gathers in one place the definitions that have been introduced throughout the body of the text and the FY04 portion of the pathfinder study.

2. A First Look at Commonality:

A helpful approach to system design is segmentation into smaller components, each of which is simpler and easier to understand, holistically. If done properly, this approach allows the designer to identify identical functions in various parts of the system. Re-use of these common functions in multiple locations reduces the design complexity. Such commonality also increases the design reliability by eliminating slightly different functional implementations. Error identification and correction consequently is done once, rather than identifying each instance of a function for individual correction.

There are various levels of commonality in a system design, as follows.

1. The most basic level has the same conceptual function existing in at least two places, but the specific implementations are different. For example, a damage function for an artillery range might be computed in one place using a cookie-cutter algorithm, in which everything within a certain radius is totally destroyed, and in another place the computation might yield fractional damage as a continuous function of distance from the impact point. This situation is undesirable.

2. A second level has the same functionality with the same interface, allowing alternative implementations to be used interchangeably. For example, a best-path function might be based on the shortest distance, a fastest-traversal path, or a least-fuel criterion, depending on the situation. Each algorithm is a best path function with same inputs and the same outputs (its interface).

3. The third level involves functions that are equivalent, so that the same results are obtainable using any version of the implementation. For example, polynomial functions of five or seven terms may be used to predict artillery round trajectories, depending on the precision required. The five-term polynomial is practically equivalent to the seven-term polynomial, when the difference is small enough for the intended use. (See practical commonality in the definition below.)

4. The highest level of commonality uses identical instantiations of the function. When this level is reached, the full benefits of commonality can be realized.

We thus have the following definitions:

• Commonality is the same or equivalent instantiation wherever that specific functionality is needed.

• Ideal commonality is the use of the identical instantiation for each occurrence of a function.

• Practical commonality is the use of instantiations of the function that yield essentially the same output for nearly the same input. That is, given two different functions (f1 , f2), with inputs (x1 , x2) and outputs (y1 , y2), respectively, if the inputs are essentially identical, |x1 - x2| LE delta, then the outputs are also close, |y1 -y2| LE epsilon, for delta and epsilon > 0. The variables (x1 , x2 , y1 , y2) may be numbers, arrays, or objects, so long as there is an appropriate distance metric to define "close."

For example, given the following definitions:

Function f(x) = 2*(3+4)

Function g(x) = 2*(3+4)

Function h(x) = 2*3 + 2*4

Functions f and g have ideal commonality and function h has practical commonality with functions f and g. These examples illustrate stylistic differences in computer coding. A more complex example is given above for functions used to predict artillery round trajectories.

The concept of a pattern is a generalization of the concept of a commonality. A pattern is a complex construct that has a top layer abstraction common to each implementation; however, the details below this top layer will vary from implementation to implementation.

• A Pattern is a description of a problem that occurs over and over again and a description of the core of the solution to that problem in such a way that one can use the solution over and over again, with variations as appropriate. A pattern identifies a set of elements used to accomplish or support a common need, capability or purpose.

A pattern may be as simple as the description of a generic loop in computer code. There are many different implementations of loops in each code language and the implementations differ from one language to another, yet the pattern is the same: the program flow enters a loop control block which determines the number of iterations of a code block, exiting the loop control block when the proper number of iterations is complete. The diagram in Figure 1 illustrates the loop pattern example.

Figure 1. Loop Pattern

A pattern may also represent a much higher level solution to a general problem. For example, in object oriented programming the Adapter Pattern is one of 23 frequently used object patterns. Figure 2 illustrates the generalized class diagram of the pattern. An object of the Adapter class converts data from an Adaptee object to the format needed by the Target object.

Figure 2. Adapter Pattern

An airport simulation provides an application of the Adapter Pattern:

1. The airport traffic control system (Target) requires positional coordinates as latitude (degrees/minutes/seconds [dms]), longitude (dms), ground clearance (meters), and air speed (meters/second).

2. The airplane GPS system (Adaptee) maintains positional coordinates as latitude (decimal degrees), longitude (decimal degrees), elevation (feet above sea level), and ground speed (knots).

3. The Adapter performs the conversion whenever the airplane coordinates are requested from the airplane GPS by the air traffic control system.

We include "patterns" as a generalization and extension to the notion of "commonality" for improved software system design.

3. UA Capabilities, Integrated Processes, and Functions:

Before we can understand how commonality can help with the UA SoS, we have to identify the possible sources for defining the SoS. Several documents have been suggested as useful beginning points, including the Army Universal Task List (AUTL), the FCS UA Operational Requirements Document (ORD), and the Integrated Processes (IPs).

3.1. A Beginning with the Army Universal Task List

The AUTL is a list of all the tasks that a soldier might need to perform and is updated periodically, as needed. The AUTL began as a training aid, showing what the soldiers need to learn, both in general (all soldiers) and in particular (these soldiers). The AUTL includes a description of each task and a set of measures to evaluate performance of the task. The tasks in the AUTL are organized by Battlefield Operating Systems (BOS), which are the physical means (soldiers, organizations, and equipment) that commanders use to accomplish missions. The seven BOS are: Intelligence, Maneuver, Fire Support, Air Defense, Mobility/CounterMobility/Survivability (M/CM/S), Combat Service Support (CSS), and Command and Control (C2). The first seven chapters of the AUTL are devoted to these seven BOS. The eighth chapter describes the tasks the Army performs in support of joint operations. This organization provides the basis for the numbering system of the tasks, each number preceded by the label ART which stands for Army Tactical task. Table 1 below shows part of the table of contents of the AUTL and displays the typical task organization.

Table 1. Example from the AUTL

We note that no task is repeated in the AUTL. That is, tasks that are common to more than one BOS will appear only in one place. Thus, the AUTL is based first on the principle of commonality; only after that principle is satisfied are the tasks organized by BOS. We also note that the AUTL does not link any tasks and so does not provide any information on patterns. However, because the AUTL is a minimal list of human tasks without duplication, it is very useful for many other purposes, as we discuss next.

3.2. Significance of UA ORD in Elemental SoS Design and Development

The main purpose of an Operational Requirements Document (ORD) is to describe the materiel and non-materiel requirements of a system in operational terms. That is, the ORD describes what the system should be able to do in an operational setting, as opposed to describing the system in physical terms (horsepower, etc.) in a static setting. The scope of the ORD depends on the scope of the system. For example, a replacement for a piece of equipment, such as a fighter airplane, might have minimal non-materiel requirements (i.e. doctrine, operational concepts, tactics, organization, training, and Soldiers); whereas, the Army's Unit of Action (UA) embodies considerable changes from the current non-materiel requirements and thus needs extensive documentation in the ORD to reflect these changes.

The UA ORD may be divided into two parts, textual descriptions and numbered requirements (as denoted by "ORD" followed by a number). We find that the numbered ORD requirements are not exhaustive. Specifically, a careful crosswalk of the Integrated Process (IP) for networked fires (IP03) has shown that the process descriptions are contained in the text.¹⁰ Both parts of the ORD are necessary to understand the UA requirements and its expectations for performance.

3.3. Integrated Processes

The ORD specifies UA capabilities, which are implemented in the UA as Integrated Processes (IPs) that are then broken down into steps and decomposable (in turn) into functions. It is presumed that each capability is intended to encompass the complete set of functions embodied in the text of the ORD, without contradiction or accretion. The IPs, however, may amplify the ORD processes by providing more detail. It is not clear whether the IPs contain all of the use cases that should be derived from the ORD.

3.4. Recapitulation

The problem for designing and developing the UA SoS is that the documents above are not computer systems specification documents. The IPs provide the proper starting point for searching for commonality and patterns of automated systems and their interfaces with humans. Creation of use cases and class descriptions (via UML or some similar tool for capturing such information) using information from the ORD would be more difficult than using information from the IPs. Both may be required. The AUTL describes human tasks as a basis for understanding the UA interactions of humans with automated systems, and the automated systems that replace human tasks. The AUTL already accounts for commonality of human tasks, since duplication of tasks across BOS's is not allowed. However, the AUTL does not have any new or modified human tasks for the UA, and consequently does not provide a useful starting point for discovering patterns, because the tasks are not explicitly linked in any way. These caveats are important to understand relative to UA performance expectations, commonality, and the nature of tasking within this new paradigm (new tasks added, tasks deleted, task changes with respect to human and automated systems, etc.).

4. Systems Engineering and Systems Design/Development Methodologies

Hardware systems engineering, design and development has numerous complexities; however, the hardware domain enjoys one significant advantage over software systems engineering, design and development: hardware components have fewer connections among themselves. A gear must mesh properly with only a limited number of other gears, must be attached to only one shaft, and is contained in a single housing. Thus, the gear's dimensional constraints are limited. The torque the gear must exert and its speed of revolution are defined by the external attachments; however, these attachments are also limited. Thus, the compositional constraints on the gear's materials are limited. Software, on the other hand, often requires more complex connectivity, which adds complexity to its domain.

Software systems engineering, design and development were borrowed from the hardware domain and co-evolved with procedural languages, such as COBOL and FORTRAN. Early software projects were constrained by the capabilities of early computers and were much less ambitious than current software projects. Despite these constraints, numerous problems were encountered and were solved by creating life cycle processes (such as the waterfall model), structured programming, data flow diagrams, entity relationship diagrams, state transition diagrams, etc.¹¹ Later enhancements included the use of software design environments and configuration management. Software systems methodologies are still required for current software; however, they are no longer sufficient to guarantee the desired results. Object Oriented methodologies have been offered to fill the gaps.

5. Object Oriented Software Design and Development Methodologies

According to Grady Booch,¹² there are significant differences between algorithmic decomposition (the approach of this commonality pathfinder project) and object-oriented decomposition for software design and development.

• Algorithmic decomposition consists of the successive division of a process into sub-processes or algorithms. A process is fully decomposed when subdivision of any lowest-level algorithm no longer results in a process or when the purpose of the decomposition has been met.

• Object-oriented decomposition consists of the successive division of a system into objects and sub-objects. See Booch for a lengthier definition.

In Object Oriented decomposition, according to Booch:

...we view the world as a set of autonomous agents that collaborate to perform some higher level behavior... each object in our solution embodies its own unique behavior, and each one models some object in the real world. From this perspective, an object is simply a tangible entity which exhibits some well-defined behavior.

Thus, each object has its own unique behavior, as represented by algorithmic procedures, and acts on and/or communicates with other objects. Both types of decomposition provide necessary views into the system. However, according to Booch, one should start with one type of decomposition, following it to completion, and then recasting the results in terms of the other. This systematic approach is particularly important for complex systems and those whose performance is critical for life, health, and welfare. Booch advises that starting with an object-oriented decomposition is superior for the purpose of designing a system. However, designing a system is not within the scope of this pathfinder project. Rather, our current effort, in part, seeks to offer advice about the system design. In the UA SoS, a level of commonality exists in the functions, and in the algorithms/data, and in how these are organized into various systems or tasks. The tightly-coupled UA SoS requires special efforts to embrace this commonality as a conscious part of the design process. Some of this design effort will be naturally encompassed in the use of inheritance. However, some use of global methods may be called for -- that is, methods that are not associated with any particular instantiated object, but are more like conventional subroutines.

5.1. What the intended system is to be able to do--Use Cases

A "use case" for a system is a description of one of the uses of the system. The complete set of all possible uses of a system should capture all of the requirements for system performance. As a practical matter, the complete set of use cases is non-trivial to define, and can result in an unmanageable number of cases. Thus, discipline is necessary to capture all of the supporting information for any one case.

Several definitions are required.

• Use Case Scope: the part of the system under consideration in the given use case.

• Use Case Level: one of "summary," "primary task," or "sub-task," indicating the detail of the given use case.

• Use Case Actor: anything that acts (has specific behavior) on the current scope of the system, at the level of interest. An actor may be a person or an external system. Actors may be primary or secondary. Primary actors use the system to achieve a goal. At least one primary actor is required for a use case.

• Use Case Goal: a description of the use case, representing the reason for using the system in this case, the goal or objective of the user, or the requirement being elucidated in this particular use case. The use case title is a shortened form of the goal.

• Use Case Conditions: The preconditions of the use case consist of the state of the world/system immediately prior to the start of the use case. The end conditions consist of the expected state following a successful/failed completion of the use case.

• Use Case Trigger: the action on the system that starts the use case.

• Use Case Scenario: a complete set of steps that begin with the trigger and continue to the delivery of the goal (or its failure), including any clean-up steps afterward. The scenario may include branches. At the higher use case levels, many of the steps will be the names of subordinate use cases.

Figure 3 illustrates a use case with one primary (P) and one secondary (S) actor. The trigger is the first step. Step 2 is expanded by a subordinate use case and a variation that follows Step 2 is also expanded as a subordinate use case.

Figure 3. Use Case Diagram

Traditionally, an exhaustive set of use cases is required to completely specify the system. However, the use cases are not necessarily mutually exclusive. For example, Step 3 and Variation 1 might also be required in some other use case. The purpose of the use cases is to define all of the functionality of the system in terms of what the system does. More work is required to define how the system does it.

5.2. Some more definitions

At this point, some definitions are required. In this paper we refer to "functions" and "methods," which can be used interchangeably in describing some programming "methodologies." As an aid to the reader, we will use these terms in distinctive ways.

• By function, we will mean a service, role, or duty that some entity is supposed to perform. In particular, we will mean the elemental functions into which broader functions may be decomposed.

• We will use method to refer to a single algorithmic procedure of a program. Methods are the means of implementing functions into coded languages. For those familiar with older programming languages, methods are similar to functions and subroutines. Method is the term used in Object Oriented languages such as C++ and Java for this concept. Methods are usually named with a paired parenthesis appended, e.g., CollectData(), to distinguish them from data elements and emphasize their functional nature. Elemental functions may be implemented as one or more methods.

• A class may be thought of as an extension of the "structure" concept, which allows a collection of data elements or attributes to be treated as a single item. The extension adds the inclusion of methods to the collection. Technically, a class could represent a random collection of attributes and methods; however, in practice, classes are used to represent the idealization of some concrete or abstract object, such as a sensor or a military order.

• An object is the instantiation of a class. In designing a computer program, the designer might define a class to represent a sensor. While the program is running, several sensor objects might be created (instantiated), each having all of the attributes and methods of the sensor class; however, each has its own unique values for its attributes (e.g., different serial number values).

• Another extension that is included in the concept of a class is inheritance. A class may be created as a sub-class of another class and thus inherit the attributes and methods of the parent class. A generic sensor class might have the attribute of serial number and the method of CollectData(). A sub-class would inherit the attribute and method automatically and could add attributes and methods that distinguish the sub-class from a generic sensor and from other sub-types of the generic sensor. An object instantiated from the sub-class would have the attributes and methods of the sub-class and, thus, of the parent class. Some languages, such as C++, implement multiple inheritance, which permits sub-classes to have multiple parent classes and inherit attributes and methods from all the parent classes. The system of classes and subclasses forms a tree-like structure, which engenders the concept of class levels.

• Polymorphism is another aspect that may be included in the class concept. Polymorphism allows sub-classes to modify the methods that they inherit. Thus a RadiationSensor and a ChemicalSensor might implement their separate CollectData() methods differently to represent the differences in data collection for the two different real-world sensors that these two classes are supposed to represent.

• The concepts of classes, objects, attributes, methods, inheritance, polymorphism are included in Object Oriented design and programming.

• C and C++ are very strongly typed programming languages in which the type (integer, double, class name, etc) of each variable must be specified. This requirement can result in much code duplication of classes or methods that differ only in the variable types. For example, in C, if we want to use a sort algorithm to sort a list of integer values and a list of double values we would have to write two separate methods, one specifying variable type integer and one specifying variable type double. However, with C++ function templates we can write one function defined as a template with a generic data type and essentially pass the actual data type to the function when it is called. The passed variable type can be a simple primitive type (e.g. boolean, integer, double) or a class type defined by the programmer. Classes can also be defined as a class template with generic data types that are determined when the class is instantiated. Template functions and template classes were designed to provide for a high degree of adaptability and efficiency so that software components could be written in a generic way for reusability.⁷

• Rather than referring to a design or development process, technique or style as a method, we will refer to it as a methodology.

• Similarly, when discussing the services, roles or duties of a system, we will refer to its functionality.

• We will use functional level to mean that level of system functionality that is represented by the elemental functions. This is not the same as class level. This is not a precise description, but an approximate one. In general, the implemented methods are found at the functional level. System functionality that encompasses several functions would be at a higher level. Modeling constructs that contain or operate on data and methods (e.g., classes and templates) would be at a higher level. Constructs that contain or operate on classes and templates (e.g., patterns) would be at a still higher level. This approximate description is sufficient for the discussion of this paper.

5.3. Depicting how the system is to perform functions--Class Diagrams

The creation of class diagrams (for software development in the design phase) is the beginning of the definition of how a system performs its functions. Figure 4 depicts a simplified example, in which each box represents a class. The gray boxes are abstract classes that will never be instantiated as objects, and provide the framework for the blue boxes that represent classes that will be instantiated as objects. The classes here only have a class name and one method, CollectData(), to collect data. That method (or algorithmic procedure) is specified in the parent class and will be required in all of its children. However, that method may be only minimally specified, because the details will vary with each particular sensor. Two additional abstract classes are defined in this example, PointSensor and ImageSensor. Any child of the PointSensor class collects data at one spatial point (e.g., RadiationSensor, ChemicalSensor, and ElevationSensor). Any child of ImageSensor collects an array of data for construction of an image from a single viewpoint. The PointSensor and ImageSensor abstract classes contain the relevant structures necessary to make this distinction, in addition to what they inherit from the Sensor class, and pass these structures on to their respective children. The children (in turn) add any necessary structures for their peculiarities and implement the method, CollectData(), in the manner necessary to model the relevant real-world sensors.

Figure 4. Inheritance in Sensor Classes

5.4. Commonality in Classes

The commonality illustrated in Figure 4 is based on inheritance. We will introduce a definition for this.

• Vertical commonality is commonality in the class structure between elements in a class and its parent class.

In general, different sensor classes will not exhibit complete commonality at the functional level for CollectData(). In this example, the collect data function is implemented in the methods at several class levels. For example, suppose that the CollectData() method for all of the lowest level subclasses can be decomposed into several parts as illustrated in Figure 5. Each of the PointSensor and ImageSensor subclasses implements PartA and PartG of the CollectData() method. Each of the PointSensor subclasses implements PartB while each of the ImageSensor subclasses implements PartC. PartD is common only to RadiationSensor and ChemicalSensor, PartE is common only to RadiationSensor and IRSensor, and PartF is only implemented in ElevationSensor. Clearly, while none of subclass CollectData() methods are exactly equivalent, they do exhibit a certain degree of commonality.

Figure 5. Inheritance in Sensor Classes , No Code Reuse Implementation

One way to handle this situation is to implement the entire CollectData() functionality in the lowest level subclasses as illustrated in Figure 5. However, if PartA, PartB, PartC, and/or PartG contain significant amounts of code, this implementation involves much code duplication. A more efficient implementation that takes advantage of code reuse is illustrated in Figure 6. In this implementation, the PartA code is moved to the Sensor class's CollectData() method and called from within the PointSensor and ImageSensor subclasses using Sensor.CollectData(). Likewise, the PartB and PartC code is moved to the CollectData() method of the PointSensor and ImageSensor subclasses respectively. Each of the PointSensor subclasses calls the PointSensor.CollectData() method which executes both PartA and then PartB before executing the unique PartD, PartE, and/or PartF code. Each of the ImageSensor subclasses calls the ImageSensor.CollectData() method before executing unique portions of the CollectData() code. PartG is moved to a new method in the Sensor class so that it can be called by each of the subclasses at the end of their CollectData() methods. In this implementation of the CollectData() method, various parts of the functional code exist at different levels of the class tree and allow for maximum code reuse of the PartA, PartB, PartC, PartD, PartF, and PartG code segments.

Not resolved in this example is how to implement maximum code reuse of PartE. For both the RadiationSensor and IRSensor subclasses to have access, the PartE code would have to be moved to the Sensor class. However, PartE would then be accessible to all of the subclasses of the Sensor class. At best, this implementation violates the theoretical design methodology of OOP. At worst, it opens up the possibility that a programmer could mistakenly call the PartE code from a subclass for which such action could lead to a critical failure of the system. The FCS SoS is expected to contain many real examples of this design scenario.

Figure 6. Inheritance in Sensor Classes, Code Reuse Implementation

• Horizontal commonality is commonality across the lines of inheritance viewed within the class structure or across implementation stove-pipes.

Note that while the commonality exists horizontally across the lowest level of subclasses, the commonality is implemented through a vertical implementation of code reuse. The horizontal commonality of most interest is that which is found in classes that have no common parent or are only connected by a distant parent, that is, difficult to implement vertically. Horizontal commonality that is easily addressed through vertical implementation is of less interest, as it can be implemented through standard inheritance. Simple single-inheritance class structures cannot efficiently and securely implement horizontal commonality in a very complex system with multiple levels of complex interaction among the classes. Some combination of the OOP methodology of multiple-inheritance and new methodologies currently in the research and development stage is needed to efficiently and securely implement horizontal commonality in the FCS SoS.

The class diagram for sensors in Figure 6 is but one possible structure for the implementation of sensor functionality. Many alternate class diagrams can be implemented based on different sensor attributes, such as energy source, electromagnetic spectrum, active/passive, etc. Each of these alternate class diagrams will have a different vertical partitioning of the CollectData() common code and elements. Thus each will emphasize and/or elucidate different subsets of the complete functional commonality. And each will put a different one of the CollectData() Parts into the category of un-implemented commonality.

Ideal commonality might only exist among all the instantiations of a specific sensor type (e.g., RadiationSensor). Despite the differences in CollectData() at the functional level, there is something that is common, otherwise, labeling the process with the same name would never have occurred to the analyst. Therefore an additional definition is needed for this combination of commonality and variability.

• Relational commonality occurs above the functional level and involves the comparison of processes (p1 and p2) that can be further decomposed into functions (di) and data structures (sj). If the processes are identical when written as functions of (di,sj), then they have relational commonality. In this example, the CollectData() functions are relationally common, but not functionally common.

Templates, as defined earlier, provide one method of incorporating relational commonality. Templates provide common processes, but allow variability in the data types. In this simplified example, the objects instantiating the classes RadiationSensor, ChemicalSensor, and ElevationSensor have relational commonality by inheriting common elements from the PointSensor class. In addition, they have variability through the differences that distinguish them. Patterns provide commonality in the interactions among classes, while providing for variability in the identities and natures of the classes involved.

One of the advantages of object-oriented programming is that inheritance reduces code generation via relational commonality, almost as a direct consequence of the design process. For code generation to actually close the gap between design and operational software, the emphasis on the word "almost" is required. The designer(s) must recognize relational commonalities, which then must be explicitly included in the system design. This may be most difficult in regard to horizontal commonalities (see Section 6.4).

A second advantage of object-oriented programming is its insistence on modularity. Robert Verzola opines:

One of the most important rules that good designers will never violate is modularization: breaking up a complex system into relatively independent modules, which are isolated from each other except for a few well-defined interfaces. This design rule can be found in all engineering and computer science texts. It is true for hardware and software designs. Without exception, all complex systems, which have violated this rule have ended as miserable failures, while those which have tried to implement it have shown much better rates of success.¹⁴

In the FCS SoS this modularization is accomplished through stove-piping of the systems. However, horizontal commonality that exists among the systems will likely be missed and the common functions may be coded differently and perhaps incompatibly. Unfortunately, this prescription for the UA SoS may support the creation of a SoS that is completed and runs, yet yields the wrong results and where the results are correct, they are too late! Further, the costs of SoS failure in FCS operations are likely to be dearer than the costs of most software systems failures because the costs might be measured in human lives. A correct interface does not guarantee that the information that is passed will be interpreted as intended. Some methodology is required that gets around the hiding of commonality by modularity to ensure that results are correct and that human intervention is not required in the wrong places.

5.5. UML, Rational Rose & DOORS-Aides to Tracking the List of Requirements

DOORS is a Telelogic product designed to maintain and track the list of UA requirements, both explicit and implied, hardware and software. The LSI uses DOORS to provide an authoritative trace of ORD requirements and their fulfillment in the software development. ORD elements are operationally defined. For example: "FCS systems must accomplish position/navigation (horizontal and vertical) with a Low Probability of Detection (LPD)/ Interception (LPI) and in the presence of electronic jamming to a X meter Spherical Error Probable (SEP) (Threshold), Y meter SEP (Objective)." Numerous appendices amplify these elements. Later in each document/explanation, processes are discussed and then only at a very high and non-executable level.

Rational Rose is one of several tool sets for documenting Object Oriented (OO) analysis and design, using the Universal Modeling Language (UML) as the basis for its displays and language structure. The purpose of the OO analysis and design is to produce the specifications for a software system that can be coded into an operational system (e.g., simulation system, imbedded control system, hardware system). The logical view of OO analysis and design involves use cases, class diagrams, object diagrams, state transition diagrams, and timing diagrams to produce the class structure and the object structure. Some UML tools also explicitly support patterns. The physical view produces the software architecture via module diagrams and process diagrams. The analysis and design process of documentation in Rational Rose requires the creation of the detailed processes and connections of the UA system software. Decomposition, such as that which has been undertaken in the current pathfinder project, is one component that supports this creation process.

The LSI, with understanding and acceptance from the Army, uses the DOORS-Rose link to directly merge the list of requirements in the DOORS system to UML elements in the Rational Rose system. This approach enables the Army and the LSI to ensure that each ORD requirement has a referent UML component, as a class or an element. This methodology also identifies software elements that do not actually or explicitly map to a requirement, thus allowing verification that the UA is designed to satisfy the requirements without any unnecessary features. However, the UML model must be revised as requirements are added, modified, and deleted. This ever-changing complexity in UML documentation exacerbates problems in assuring that the UA system continues to meet old requirements, as well as the new/modified requirements. Review and verification of this assurance process is important.

This commonality pathfinder project has endeavored to identify the existence of commonality for further UA design improvements. Because relational commonality appears above the functional level in algorithmic decompositions and often disappears at decompositions at the functional level, the need for persistent commonality searching is evident. For such a comprehensive approach, it is important to elucidate the class and inheritance distinctions, both in organic UA systems and for complementary systems. However, it is also necessary to extend the search beyond class and inheritance design.

Continuation and Footnotes:

If you arrived here using a keyword shortcut, you may use your browser's "back" key to return to the keyword distribution page.

Return to Hartley's Projects Page