Universal Architecture Description Framework

1.         A Brief Trip Through History

Modern structured analysis (MSA) evolved under the leadership of Edward Yourdon, Tom Demarco, and a host of other software developers. It is a functional analysis approach recognizing computer processing in the form of bubbles that are interconnected by directed line segments that route data between processing bubbles and temporary stores to form a data flow diagram (DFD).  A data dictionary defines all of the data flows and stores and a p-spec defines the computer processing that must take place in each lowest tier bubble. Requirements are derived from the p-specs and data dictionary. Derek Hatley and Imtiaz Pirbhai teamed to describe a variation on MSA that added a second analytical plane for analysis of control needs expressed in a control flow diagram (CFD) separated from the computer processing plane expressed on the DFD. After Imtiaz's death Peter Hruschka joined Derek to continue the development of what they now call a Process for System Architecture and Requirements Engineering (PSARE).

The inclusion of PSARE with MSA  is deceiving in that it actually can be used for systems, hardware, and software modeling. In this paper PSARE will be recognized as a main element of one of the universal architecture description frameworks identified.

Many software analysts believed that an object oriented analysis (OOA) approach would be an improvement where the analyst first attempted to identify the objects of which the software would be composed followed by a dynamic analysis of each object from a functional perspective using a data flow diagram and behaviorally using a state diagram. An architect Louis Sullivan in the early 20th Century coined a phrase describing how he thought an architect should design a new building with the phrase "form follows function" that many system engineers over the years have accepted as a great truth. This was expressed in "newsletters" Sullivan wrote to his kindergarten (young architects in Chicago) later quoted in " Kindergarten Chats and Other Writings". To system engineers the early OOA encouragement of function follows form was simply backwards and wrong headed.

A system architecture description can be said to consist of a comprehensive modeling set that includes coverage of the problem and solution spaces plus a means to capture the requirements derived from the models. The order in which we attack the modeling work is very important but not necessarily always the same as we will see. But for the situation where we are developing a solution for an unprecedented problem most system engineers would agree that Sullivan was right. Many software engineers continue to believe that the early OOA sequence was correct.

The many variations on OOA led some software developers to evolve under the banner of the Object Management Group (OMG) what came to be called unified modeling language (UML) that begins an analysis with use cases that examine the inside-outside relationship of the system with its environment much like MSA does with a context diagram. A set of dynamic modeling artifacts are applied to describe the use case and in the process lower tier static entities are identified down to the object level paralleling the process employed in TSA. A universal architecture description framework could be formed using TSA and UML but it will perpetuate parent-child traceability problems at the boundary.

Congress passed a law that requires any government agency requesting funding for the development of an information system to describe it in an architecture framework. Never slow to encourage continued access to funding, the Department of Defense developed a modeling framework to serve their needs in developing systems to deal with the fantastically complex problems arising in development of systems that must master the union of command, control, communication, computers, intelligence, surveillance, reconnaissance (C4ISR) problems. This framework is called the DoD Architecture Framework (DoDAF) involving 26 different modeling artifacts. This framework is not comprehensive as it is not useful in developing hardware entities but the initiative gives us a pattern to apply in a search of a universal framework.

The difficulty in the development of computer software and its interfaces with hardware entities encouraged some software and system engineers to cooperate in an effort sponsored by OMG and the International Council On Systems Engineering (INCOSE) to develop a profile on UML to model the problem space related to systems and hardware entities called system modeling language (SysML).

Throughout this 50-year evolution, groups of very smart people have developed modeling approaches some of which became very popular. It is likely that the stream of new model development will not end at this point in the story. We have been very creative in developing modeling methods and languages but not so effective in integrating and optimizing across these models toward a universal modeling capability. One would find people today using every one of the models but there is some hope that the combination of UML and SysML will continue to mature and merge more tightly together offering a universal modeling approach. Unfortunately, the union of these two as presently defined is not comprehensive. But one can add four artifacts from TSA forming a universal architecture description framework that can be employed on any program no matter the problem space or the intended methods of implementation.

Alternatively, a similar variation on PSARE can serve the same purpose. In the process of investigating these many models and ways to evolve a universal framework, the author became convinced that there is a need for the application of integration and optimization to the current model collection to the end that a system engineer or development organization may select and successfully apply a particular comprehensive collection of modeling artifacts that they find effective and that cover the complete problem space they have to deal with. Thus we find ourselves in the period of adjustment working towards utopia with the modeling capabilities history has provided us.

A subset of all of the modeling methods available that can be shown to be comprehensive is referred to in this paper as a framework within which the architecture of a system can be described and from which all requirements can be derived. This universal architecture description framework should also be characterized by a coordinated means to define corresponding design concepts that validate the requirements derived from the models and a means to collect those requirements into what we call a set of specifications. The frameworks offered in this paper identify a specific set of modeling artifacts that are collectively comprehensive and apply a set of modeling IDs (MID) to those artifacts from which requirements will be derived. The analyst must transform the modeling features identified by MID into requirements of one of four kinds and allocate them to a product entity or product entity relationship (interface) thereby identifying the product entities and relationships as well as characterizing them. A requirements analysis sheet (RAS) is offered as the means to coordinate modeling artifacts identified by MID to requirements and thence the product entities that will be responsible for satisfying them.

The process of applying the method covered in this paper can be distilled into a simple string of tasks ideally applied top-down with functional analysis preceding concept analysis:

a.   Progressively apply a comprehensive modeling set to problem space interactively synthesizing product entities and relationships and appropriate requirements for them into design concepts trading between alternative appealing solutions where necessary.

b.   Identify the artifacts on the modeling sketches with modeling ID (MID).

c.   List the MID in the RAS, characterize each, and allocate to entities and relationships.

d.   Publish specifications and subject to a formal approval and release process.

This paper uses models to describe architecture description frameworks so those two words must be clearly understood as a prerequisite. Bran Selic, a respected name in modeling work, described a model by listing its characteristics as follows:

a.   The use of abstraction to emphasize important aspects while removing irrelevant ones.

b.   Expressed in a form that is really understandable by observers.

c.   Fully and accurately represents the modeled system.

d.   Predictive such that it can be used to derive correct conclusions about the modeled system.

e.   Inexpensive meaning it is much cheaper to construct and study than simply building and observing the modeled system.

The word architecture has many meanings. There was a time when the author applied the word only to the things of which the system consisted but he has been influenced by the content of Eberhardt Rechtin's book "System Architecting" to go beyond the things in a system. The author has selected the definition included in DoDAF that recognizes a particular collection of things forming a whole combined with a clear understanding of what the things do, how they relate to each other, and the rules and constraints under which they function at a particular point in time.

A system is said to be a collection of things that interact to achieve a specific purpose. A system has an architecture that consists of the things that comprise it, their relationships, and what they are intended to accomplish within the context of a particular environment.  offers a view of the way we commonly create systems to satisfy complex needs.

A system can be defined as a process (commonly arranged in a circular sequence in the interest of reuse of assets) that organizes collections of things (A) interconnected in particular ways (I) to accomplish particular functions (F) within a particular environment (E). A is the set of all things in the system while A* is the power set of A containing all subsets of A. The process we select for the system translates the cross product of the power sets noted onto the function set and when we can cover the function set in N revolutions of the process set having used all of A we can say we have a consistent system. We have to develop unprecedented systems based on a little knowledge of the desired ultimate functionality often referred to as the customer need statement. We can instantly associate this functionality with the solution that is the complete system without knowing a great deal about what the system is. We decompose the ultimate functionality, describe it in terms of essential characteristics called requirements, and allocate these requirements to a product entity structure (A) the elements of which are related by interfaces pre-determined by the way we relate functionality to the product entity structure. We model all of these facets of the evolving system because there is no current reality at the time we begin creating it. So, one can say that an architecture description is a way to describe a system using models. In this paper a collection of models forms an architecture description framework. If that collection is comprehensive it may be called a universal framework.

The reader should recognize that problem space modeling is only one facet of the architecture that also should include an expression of the solution space intent as well. As the problem space becomes more clearly understood a synthesis must be accomplished possibly involving trades to determine the best achievable and affordable solution. Simulation work may also be effective in helping to focus on both the problem and solution space descriptions of merit. Finally, a means is required to capture the requirements derived from the models including the traceability between requirements and the driving models. This paper deals only with the problem space description from modeling through requirements capture.

2.         Current Problems

Currently software architecting in some development organizations follows a pattern that is sufficiently different from the systems and hardware architecting pattern of work that it is unnecessarily difficult for management and system engineering people as well as hardware and software people to understand and correlate the two processes. This can lead to a frustrated acceptance on the part of management and systems people that the software people know what they are doing and can be left alone motivated by an inability to understand their methods. Obviously, the whole of the system must be brought under an effective integration, optimization, and management influence not just the hardware aspects especially since the hardware aspects are a shrinking subset of the whole and the least complex part of it. It is possible to re-order the software development pattern practiced by some slightly to encourage improved hardware-software integration and management visibility while simultaneously improving the software development process in the opinion of the author.

The author, a long time professional system engineer with a hardware-dominated background, makes no claim to being a gifted software architect but has attempted to fashion an integrated approach that will encourage system and software engineering participation in the final closure of the modeling split that has existed in industry for the past 50 years.

As computer software came to be a reality with the acceptance of a computer design concept calling for use of binary arithmetic and an instruction set to be stored in the computer that would be called from memory in sequence to execute a planned series of steps in a program, the software would be diagrammed in flow chart form by people who understood how the computer hardware worked. These engineers would then transform the flow chart depiction into code using some language that was initially machine language formed of 8 or 16 bit words or strings of ones and zeros based on the design of the binary digital computer hardware and the registers of flip flops and logic gates it used for control, storage, and arithmetic operations. Over a period of several decades including the 1960s through the 1990s, the computer software profession developed a string of new modeling approaches shown.

We have been very successful in inventing new modeling approaches but we have not applied good integrating skills toward unifying the modeling work about a common core. The work that the system engineer accomplishes in the early development period on a program is focused on understanding the problem to be solved and clearly describing it for others. The system engineer stares at problem space through a multi-faceted set of planes each dealing with a particular perspective. Models are commonly crafted using simple graphic images that move into the human mind through vision, the most powerful conduit for information to make the transit from outside to inside. The analyst creates these simple images through hand-eye coordination with pencil and paper or using a computer keyboard, mouse, and monitor screen.

In many modeling approaches we view problem space through a trio of facets. We model the problem space from an object or product entity perspective to discover what the system shall consist of in a physical sense. Ideally, our conclusions about the product entity plane would be based on a prior understanding of the functional perspective such that we could follow Louis Sullivan's form follows function notion. Finally, we are interested in how the system and its product entities will behave while satisfying needed functionality.

Some of the models we will apply are very simple and the vision mechanism works very effectively but the story transferred to the human mind is not very rich. TSA using functional flow diagramming follows this pattern. Other models involve a lot of black ink, they make the passage into the mind with difficulty but they do convey a very rich message for those who can master them. In any case, the analyst uses some combination of simple graphics to illustrate the intended functionality, behavior, and product entity structure. Over time the problem space dissipates and the system is represented by the simple graphic images that precipitate on the facets of the problem space.

It is necessary to attack the problem space from all three perspectives simultaneously. Traditional structured analysis, modern structure analysis including the Hatley-Pirbhai or PSARE expression, UML, SysML, and DoDAF all attempt to support these several views using different modeling artifacts and rules. Each of these models has useful unique features that are helpful in analyzing problem space but none of them are comprehensive such that a single model can be used as the basis for analyzing problem space to define all of the appropriate requirements for a given problem space. In that the author believes that all requirements should be derived from models and that none of the models are comprehensive, it follows that we must use a collection of models at present. None of these models were intended to be used in association with other models so it has not been easy to establish traceability across the gaps between them especially since they do not all apply the same measures of the problem space.

It is necessary to attack the problem space from all three perspectives simultaneously. Traditional structured analysis, modern structure analysis including the Hatley-Pirbhai or PSARE expression, UML, SysML, and DoDAF all attempt to support these several views using different modeling artifacts and rules. Each of these models has useful unique features that are helpful in analyzing problem space but none of them are comprehensive such that a single model can be used as the basis for analyzing problem space to define all of the appropriate requirements for a given problem space. In that the author believes that all requirements should be derived from models and that none of the models are comprehensive, it follows that we must use a collection of models at present. None of these models were intended to be used in association with other models so it has not been easy to establish traceability across the gaps between them especially since they do not all apply the same measures of the problem space.

In this period of adjustment noted on earlier, the author hopes to encourage a return to the condition of modeling closure that we began this whole modeling story with in the 1950s. During this period of adjustment we should be able to apply a comprehensive subset of all available modeling methods while we work toward the simplest and most effective comprehensive universal architecture description framework. The requirements for this solution in the author's view should: (1) be comprehensive such that all requirements for all elements of a system (hardware, software, and human procedures) may be derived from the model artifacts, (2) be applied in to a top-down direction for unprecedented development programs and bottom-up, inside-out or outside-in for heavily precedented development programs, (3) enter the problem space from a functional perspective for unprecedented development programs and from the product entity structure perspective for heavily precedented development programs, and (4) encourage hierarchical (parent-child), lateral (requirements to the models from which derived), and longitudinal (requirements to design features and verification artifacts) traceability.

3.         Overview of the Recommended Corrective Action

In addition to offering a set of models that can be applied in an integrated fashion as if they were parts of a single great model and suggesting ways this model set will mature over time toward a universal architecture description framework, this paper will support the idea that the models from which such a framework can be assembled already exists and can actually be applied to problem spaces today. This interim universal architecture description framework (UADF) will consist of one or more subsets of all of the modeling methods currently active from which an enterprise or system engineer can select a subset that is comprehensive. The author prefers a subset consisting of UML combined with SysML extended to provide organized methods for identification of specialty engineering/quality requirements, environmental requirements, product entities, and the map between models and product entities the latter (as well as the other three) borrowed from TSA called a requirements analysis sheet. Finally, UADF must be coordinated with a sound requirements management and specification publishing process.

For those managers who feel that their population of system engineers is not yet ready to transition to SysML from TSA, it is possible for their organization to establish their universal or combined set of models using any particular collection of models discussed in this paper while recognizing a technology growth path leading to the terminal point discussed here. One alternative universal model can be assembled from PSARE augmented by the same four TSA artifacts noted above. Some readers will be disappointed that DoDAF is not included in the final mix suggested. With 26 different modeling artifacts it was a daunting challenge to work them all into the mix. The author believes that the picture he has painted of many DoDAF artifacts left outside of the final model is not necessary but didn't wish to take the time at present to force fit them into the mix. Also, presently OMG is fashioning a way to implement DoDAF with UML artifacts that will push its modeling capability into the final mix in the form of a UML Profile for DODAF MODAF (UPDM). One additional benefit from employing the recommended interim UADF, besides having improved their requirements capability for some period of time, is that the organization will be poised for movement to whatever the final solution is in that their staff will be familiar with just about all of the ways there are to model a problem space.

4.         Modeling Methods

In this paper we will take a brief tour of the several models that could be used today, none of which are comprehensive, followed by a description about how subsets of them can be assembled into a universal set coordinated with the content of a universal specification format and a way to establish traceability across the gaps when using one particularly troublesome pair of models.

4.1    A Brief Overview of Traditional Structured Analysis

Throughout the period of the software modeling evolution, the system and hardware engineers remained with TSA or simply continued a habit of employing ad hoc approach. The fundamental approach in TSA involves some form of functional flow diagramming that is used to expand the ultimate function, the customer need, into a life cycle model such as that shown in earlier, and continue the analysis of the use and sustain system functions of the life cycle model into a definition of the operational and logistics functions that will be accomplished by the entities comprising the system. Sullivan's encouragement of form follows function is respected calling for identification and allocation of exposed functionality to the physical entities that will comprise the system. The functions are transformed into performance requirements that flow into the specifications for the entities that will accomplish the allocated functionality.

The V model is observed by associating the definition function with the down stroke, synthesis with the bottom of the V, and verification with the up stroke. The spiral is observed by cycling through the definition, synthesis, and verification functions several times each time stripping off a lower and finer definition of the system being created.

Continue reading here