Figure 7. Possible Horizontal Commonality
A variety of newer methodologies exist to find and exploit commonality. Some examples are pattern, antipattern, and SCV analyses. (These approaches could also be used in a larger context, such as manufacturing and automation.) In the UA SoS, many important, repeated patterns occur, such as probability of kill algorithms, RF propagation models, visibility considerations (LOS, NLOS, BLOS, etc.), to name just a few. One methodology incorporates UML tools to provide export of the diagram data (e.g., use case, class diagrams) into XML tagged files. This methodology uses tools that can search these tagged files for patterns. Another methodology applies a search engine to find routines in source code with similar names or descriptions. This methodology would probably require some research into matching criteria for high efficiency, but the possibility for finding commonalities would seem to be much greater when searching a very large software system. This section describes several of these newer methodologies.
6.1. Patterns as a Commonality Declaration
Christopher Alexander (an architect) was the first person to mention the use of patterns in the 1970s. He noted that architecture and urban planning were a repetition of simple and similar principles. The point is that each of these patterns shared a common uniformity that was independent of the specific application, to which it was applied. According to Alexander, design patterns have emerged as an expressive means of documentation and communication of successful solutions to commonly occurring problems in a particular field. Each pattern systematically describes the distilled experience for solving of specific, recurring problems. These patterns are identified through the discovery of successful solutions.
Design patterns have evolved as standard solutions to common problems in object-oriented software design in particular, but also in other disciplines including systems engineering. Although most of the literature in the field and application of design patterns has been in software design, design patterns have been successfully used in other disciplines. The phrase was introduced to computer science in 1995 by the text, Design Patterns: Elements of Reusable Object-Oriented Software.15 The scope of the term remained a matter of dispute into the next decade. Algorithms are not thought of as design patterns, since they solve computational problems rather than design problems.16
Design patterns have several advantages. The most important one is speeding the development process by providing ready-made, efficient solutions that have been used earlier. A second advantage is that commonly-used design patterns also are revised and improved over time, and thus are more likely to perform better than home-made designs. A third is that design patterns allow for a generalized solution that does not depend on the analyst's detailed understanding of the specific design problem in all its aspects, thus easing reuse of this solution. This ease of re-use is even easier if the previous analyst documented the solution (and its use) adequately. Moreover, documentation of a design pattern eases recognition of one's own design problem and its direct solution.
6.2. Antipattern Analysis to Understand Incongruities to Integration
Another topic gaining momentum is the study of antipatterns, in which designs are studied for patterns that make the design break in methodical ways.17 These antipatterns are captured so that they can be avoided in future designs. The study of previous Army M&S codes could be valuable to the UA design project by looking for reasons previous codes cannot be readily reused for the UA project. For example, can the current OneSAF design be easily modified to do Networked Fires without a person in the loop (e.g., no user input to each individual tasking order)? If not, what in the OneSAF design inhibits or prevents the code reuse for Networked Fires?
6.3. Analysis to Understand Variability of Related but Different Functionality
A related extension of commonality is 'scope, commonality and variability' (SCV) analysis. SCV goes beyond simply identifying the common system elements to elucidating the variability of related (but different) elements. This formal recognition of differences versus similarities in elements extends the value of commonality analysis. James Coplien (formerly a Bell Labs researcher, now at Lucent Technologies), who is one of the "founding fathers" of the C++ language, states that:
A commonality is an assumption held uniformly across a given set of objects (S). Frequently, such assumptions are attributes with the same values for all elements of S. Conversely, a variability is an assumption true of only some elements of S, or an attribute with different values for at least two elements of S. When commonalities are invariant and variabilities precisely defined, developers create opportunities for high-payoff automation. The benefit of automation is well known in manufacturing industries, where production lines for items such as automobiles, television sets, and personal computers rely on a family architecture to improve production efficiency.18
Coplien goes on to state:
We use five main steps in SCV analysis.
1. Establish the scope: the collection of objects under consideration;
2. Identify the commonalities and variabilities;
3. Bound the variabilities by placing specific limits--such as maximum values--on each variability;
4. Exploit the commonalities;
5. Accommodate the variabilities.
Coplien states that for a fixed startup cost of performing the SCV analysis, the problem-solving effort with SCV would increase less rapidly than the effort without SCV. Thus, SCV provides a significant payoff in efficiency for even a small number of applications.
6.4. Horizontal Commonality - Beyond UML and Design Patterns
The concept of object-oriented software development (OOSD) has become well established in the modeling and simulation (M&S) community. OOSD is a catch-all that includes object-oriented analysis (OOA), object-oriented design (OOD), modeling (with UML type tools), design patterns, frameworks, etc. The final model might be designed with an object-oriented approach, but may be coded with object-oriented programming (OOP) languages (e.g., C++ and Java) or with procedural languages, such as C (e.g. OneSAF) or FORTRAN (e.g. CASTFOREM). The use of UML type tools in OOSD is a fairly new addition to the OOSD process over the last decade.
A good example of UML use is the design process of "Software Embedded Controls for Intelligent Uninhabited Aerial Vehicles (UAVs)" in a presentation by Georgia Tech University and Boeing at the October 1998 DARPA and AFRL Software Embedded Control (SEC) PI meeting.19 Their UAV design requirements were obviously a precursor to the present requirements. The design process included the top level requirements with a flow-down tree outline of detailed requirements. The requirements were then mapped to Rational Rose as Use Cases and analyzed using UML to design the UAV architecture.
Traditional OOSD methodologies (e.g., UML and design patterns) have proven very useful in designing a single system (e.g., a UAV with many subsystems). The UA involves many such systems (a system of systems) with complex interactions. Many of the UA systems have common functionality that needs to be captured so that code can be reused. A fundamental question is: Can present OOSD methodologies capture the horizontal commonality in the complex UA SoS? Traditionally, OOSD has employed a concept called "separation of concerns" (similar to modularization discussed earlier) in which large complex systems are broken down into manageable software units. Later, these separate units are merged and/or concatenated into a system. Some UML tools can search for commonality among these separate units, but commonality can be missed if the separate units implement a common method in totally different ways with different descriptive language. An application of this methodology to a large (but still much smaller than the UA SoS) M&S code is a recent project by SimVentions to search for interaction patterns (including commonality) for software reuse in the Navy Open Architecture (NOA) systems design.20 The SimVentions effort was severely hampered by incompatibilities among different UML tools and even among versions of a single UML tool.
According to Laufer,
OOP is very good at capturing common attributes and behavior in a vertical fashion. However, when it comes to behavior that affects entities that do not have common base classes, it is impossible to address commonality in a horizontal fashion.21
In other words, Object Oriented Programming (OOP) and OOSD are very good at capturing interactions within a hierarchical tree structure, but not interactions between class trees. If commonality is found among several horizontal subclasses in one tree, the common method can be implemented in the closest common parent class in the tree as described in Section 5.4. However, no easy way exists to implement complex common methods among separate class trees other than to add a new base class that is a parent to each of the separate class trees, merging them into one class tree. This approach is a bad programming practice, which forces many low-level sub-class methods into the base class while these methods are only used by a small portion of the class tree, going against the design intention of sub-classing.
Figure 7 illustrates this concept. The left portion shows the Sensor Class tree from Figure 4. The right portion is a comparable tree for the class of vehicles. Unmanned vehicles require cameras to provide vision for the operators and the cameras are required to collect data. In the system software design these cameras are class objects that belong to or are otherwise associated with a UAV or UGV class object. Logically, the camera class should be a part of the Sensor class structure and have a CollectData() method. However, if the cameras are defined and procured strictly through the unmanned vehicle program, the camera class is likely to be implemented separately from the Sensor class hierarchy. In addition, the camera class's method for data collection is likely to be programmed in a functionally similar but programmatically different way and may even have a different name such as ProvideVision(). Consequently, commonality between the camera functions and the sensor functions will go undetected and uncaptured resulting in code duplication and possibly interoperability incompatibilities.
Figure 7. Possible Horizontal Commonality
Another option is extraction of common methods from separate trees, and creation of a new class tree structure that contains only a set of common methods that can be used by the original class trees. For example, the Java programming language has a construct for implementing a class with a collection of related methods that can be called without the instantiation of a particular run-time class object. The class is declared as a "public final class" and methods are declared as "public static" methods. A common Java example is the "Math" class that contains methods for common mathematical procedures. Any instantiated class can call the methods in the Math class without instantiating an instance of the Math class. This is one methodology for implementing horizontal commonality. Other languages, such as C++, permit multiple inheritance, which is another methodology for implementing horizontal commonality, once that inheritance has been discovered. However, multiple inheritance is a rather controversial topic in OOP and some languages, e.g. Java, do not implement multiple inheritance. Instead, Java uses the public final class methodology and "interface" classes which define the class form (method names, argument lists, return types) but no implementation, i.e., no method algorithms.
Currently, new research is being conducted on methodologies to analyze, design, and program interactions that occur among hierarchical trees. One new and potentially useful methodology for analysis of horizontal commonality is aspect-oriented software design (AOSD) and programming (AOP). According to Laufer, "the idea in a nutshell is to capture behavior that cuts across many (or possibly all) units of abstraction in a given software application.13" AOP is an extension of OOP that allows for horizontal integration/interactions among class hierarchies, and thus may aid the determination of horizontal commonality. AOP extensions to OOP languages such as C++ and Java are currently available, but are still in the rapid development stage. Likewise, AOSD extensions to UML tools are currently in development, some of which is funded by DARPA. AOSD would be one methodology for discovering (and perhaps beginning to accomplish) the horizontal commonality determination and application for the UA SoS to achieve the integration demanded of its operational requirements.
OOSD and AOSD tools are useful for software design and potentially useful for finding commonality. However, these approaches may not lead to reusable code. The ability to implement commonality is greatly dependent on the available techniques in the chosen programming language(s) and on the way in which the programmer implements the system design in code. OneSAF is a good example of an M&S code that was designed with OOSD principals, but programmed largely in the procedural language C with some user interface functions in Java. OneSAF implements code replication rather than code reuse for common sensor methods despite its object-oriented design, which was likely done with UML tools. OneSAF is an example of design commonality that did not lead to code commonality or reuse.
The UA SoS is an immensely complex system of systems with critical requirements based on the need for real-time operation and the life-or-death implications of improper operation. Speed of operation requires smaller, more tightly coupled code. Correctness requires transparency and simplicity of code.
7.1. Use of Existing UML Descriptions
The total work of discovering commonalities will be much less if present OOD diagrams are obtainable rather than starting from scratch. However, existing OOD diagrams may need reworking if they were created as by-products rather than as design products.
If there is a single OOD diagram for the entire FCS system, then there is a good chance that some commonalities will be identified among the various modules. While additional commonality may be identified immediately, the diagrams will more probably have to be decomposed into smaller components in order to identify common functions. Relational commonality will be visible with less decomposition, because higher-level functions are generally more complex, and therefore less likely to be identical to similar functions in other subsystems. As complex functions are decomposed into lower-level functions, the likelihood of finding function level commonality will increase. More specifically for the UA SoS, diagrams for each IP will have many common elements that have not been identified as such. One may find much commonality by simply comparing the classes and methods among the diagrams.
7.2. Stove-piping as a Major Barrier to Success
Stove-piping has been recognized as a major problem in expanding the use of legacy Army software. It is not surprising that software that was not designed to interoperate with other software does not, in fact, interoperate with other software. It will, however, be a major disappointment if the software systems that will make up the UA System of Systems, which are supposed to operate together, do not do so.
Classical systems engineering, design and development protect against certain categories of errors in creating software systems. However, they were not intended to address commonality issues.
Object oriented design and development methodologies (including the older and the newer OO methodologies) add tools and techniques to handle the power and problems of object oriented software. At its best, this leads to better system stability (resilience to change), maintainability (for future enhancements), reusability (of software components), and data accessibility (to multiple programs/users). However, from the perspective of the UA SoS, OO suffers from a determined preference for modularity, which, without mitigation, is likely to lead to a SoS that runs, but doesn't yield accurate, stable and reliable results.
None of the existing methodologies protects against structural stove-piping. The example of the camera in Figure 7 was invented to show how a common function could be created in two places with no common parent from which to inherit any elements, leading to a failure of commonality exploitation. If all of the software shown in the example were being developed by a single corporation, under a single contract, it is conceivable (although highly improbable) that the commonality could be found by one of the newer methodologies (given enough time, resources, and serendipity). However, if the two parts of the example are being developed under separate contracts or by different corporations, the discovery of the commonality, much less its exploitation, would be improbable without contractually imposed, cross-effort commonality searches.
Each and every contract will be creating a separate stove-pipe. Imagine the class structure diagram of Figure 4 with no parent classes, where each implemented class is developed by a separate contractor22, with no access to other classes and no one responsible for creating parent classes. There would be no inheritance and no exploitation of commonality at all. As documented in other reports from our initial pathfinder project, the failure to exploit commonalities has large monetary costs related to code creation, debugging and maintenance; but more importantly, the failure to exploit commonalities puts the entire SoS at risk of failure.
7.3. A New Design/Development Paradigm
In 1991, Grady Booch published a book on object-oriented design in which he describes the consequences of unconstrained systems complexity, and the software crisis.23 This book is a lucid account of the implications of complexity and the difficulties of assuring performance. The book explains that without conscious and disciplined effort, complex systems will fail and we won't know why. The estimate for the entire UA SoS is on the order of 35 million lines of code.24 The National Academy of Sciences published a book that discussed software project failures.25 One table in the book lists 12 troubled software projects, nine of which have costs ranging from $44 million to $42 billion. For example:
1. As of January 2000, the National Weather Service technology modernization project, which began in 1982 was over budget and behind schedule. The cost of the system was estimated to be $4.5 billion.
2. The Internal Revenue Service tax systems modernization project was cancelled in 1997, after spending $4 billion and 8 years of work.
3. The Federal Aviation Administration air traffic control modernization project, which began in 1981, is still ongoing; major pieces of the project were canceled, others are over budget and/or delayed. The total cost estimate now stands at $42 billion through the year 2004 (or $51 billion through 200726).
The bottom line is that large software projects can and do fail unless the systems complexity is carefully planned, managed and understood, with appropriate attention to the technical details, throughout the project life. The technical details include critical show-stopper processes in the system design that must be identified and resolved with sound technical judgment.
With large projects, decomposition and separation of concerns are required, as no one person can understand the entire system. With the UA SoS, the whole must be decomposed into systems, and then those systems must be further decomposed into common low-level components. The present end result is stove-piping because contracts do not require SoS commonality, so that each (sub)contractor is largely ignorant of what is happening in the other organizations. The result is individual failure points or a massive system failure.
A new paradigm for design, development and integration might include the following steps:
7.4. Benefits
Object-oriented design (e.g., performed manually or via a tool such as Rational Rose) does not guarantee completeness, consistency, succinctness, or validity any more than does any other methodology of designing a system. OO proponents claim that the software design becomes easier to develop correctly, as substantiated by the results of some OOSD projects. A clear need remains to supplement the design process with any appropriate tools that will increase the completeness, consistency, succinctness, and validity of the operational system.
Greater efficiency and reliability of the SoS requirements and UA software may be possible at a higher level than replication, or a more sophisticated form of re-use of common components, the discovery of common patterns, variabilities, etc. In addition to the more general application, commonality determination could be especially useful to enable the builders of the SoSCOE system to increase the correctness of their design. By increasing code and application program interface (API) reuse, they can reduce the possibility of errors, and increase the maintainability.
At the highest level, the emergent properties of the SoS must be treated as operational requirements. The design and development management process can be modified to implement these requirements.
7.5. Conclusion
The UA SoS is likely to have an assurance of failure, as it now stands, due to systems complexity and lack of commonality exploitation. Costs will be high, due to duplication of effort. Maintenance and failure correction costs will be high, due to multiple occurrences of similar, but not identical code. Performance will be too slow, due to loose coupling among the interacting systems. The overall functionality of the SoS will be unpredictable at best, because all complex systems have emergent properties. However, no effort will have been made to design and develop for the desired emergent properties in the present methodology, so far as can be determined to date.
The analysis provided by this SMART-principled commonality pathfinder project supports the need for identification and exploitation of commonality. Additional object-oriented tools can facilitate the design choices, leading to inheritance structures and global definitions that increase the consistency and succinctness of the system. A complete decomposition, itself, as a by-product of this commonality pathfinder project, can at least serve as a check on the completeness of the system design.
1 Unit of Action (UA) Future Force Integrated Support Team (FIST), "Common C4ISR Representation: SMART-Based Progress for UA Modeling and Simulation (FY04 Report)," November 2004
2 Standish, R. K. "On complexity and emergence," http://journal-ci.csse.monash.edu.au/ci/vol09/standi09/
3 Weeks, Major Michael R., USAF, "Chaos, Complexity and Conflict," Air & Space Power Chronicles, July 2001 (also at http://www.airpower.maxwell.af.mil/airchronicles/cc/Weeks.html
4 Cooper, Clive, "Complexity in C3I Systems," 1994
5 Mirsad Hadzikadic, "Security Of Computer Networks," http://www.honetcon-nsf.uncc..edu/Invited-PapersSummaries/MirsadHadzikadic-HONET04-Sum-CAS&Sec.pdf
6 http://www.abca.hqda.pentagon.mil/Introduction/glossary.html
7 http://www.fas.org/man/dod-101/sys/land/fcs.htm
8 FCS ORD 3266
9 http://www.hyperthot.com/pm_sdm.htm
10 Unit of Action (UA) Future Force Integrated Support Team (FIST), "Common C4ISR Representation: SMART-Based Progress for UA Modeling and Simulation (FY04 Report)," Section 3.5, November 2004
11 "Enterprise Resource Planning: A Business Approach to Systems Development," Nicola Gibson, Christopher Holland, and Ben Light, Proceedings of the 32nd Hawaii International Conference on System Sciences - 1999
12 Grady Booch, Object Oriented Design with Applications, Benjamin Cummings, Redwood City, CA, 1991, pp 14-16
13 "STL Tutorial and Reference Guide, C++ Programming with the Standard Template Library", David R. Musser and Atul Saini, Addison-Wesley, 1996.
14 http://www.hartford-hwp.com/archives/25/026.html
15 ISBN 0201633612
16 http://en.wikipedia.org/wiki/Design_pattern_(computer_science)
17 "Bitter Java", Bruce A. Tate, Manning Publ., April 2002
18 http://www.bell-labs.com/user/cope/Mpd/IeeeNov1998/
19 "Software Embedded Controls for Intelligent Uninhabited Aerial Vehicles (UAVs)", Daniel Schrage, George Vachtsevanos, et. al., SEC PI Meeting, Berkeley, CA, October 26-27, 1998; http://www.sainc.com/sec/meetinglist.htm
20 "Coupling of Navy Open Architecture (NOA) Modeling Efforts to a Modeling and Simulation (M&S) Framework", SimVentions final report to NAVSEA, Sept. 30, 2004; http://www.simventions.com/whitepapers/Coupling%20of%20Navy%20Open%20Architecture.pdf
21 K. Läufer, G. K. Thiruvathukal, T. Elrad, and A. Bader. Enhancing the CS curriculum with aspect-oriented software development (AOSD) and early experience. Working paper, September 2003
22 Or each development is held as proprietary by the contractor corporation.
23 Grady Booch, Object Oriented Design with Applications, Benjamin Cummings, Redwood City, CA, 1991, Chapter 1
24 "Challenges and Opportunities for Increments II and III Future Combat Systems (FCS)," Army Science Board, 2003 Summer Study
25 Making IT Better: Expanding Information Technology Research to Meet Society's Needs (2000), Computer Science and Telecommunications Board (CSTB), National Academy Press, Washington, D.C., 2000
26 Thursday,October 30,2003, AIR TRAFFIC CONTROL: FAA 's Modernization Efforts - Past, Present, and Future, GAO-04-227T
27 "STL Tutorial and Reference Guide, C++ Programming with the Standard Template Library", David R. Musser and Atul Saini, Addison-Wesley, 1996.
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