system and software architecture reconciliation

System and SoftwareArchitecture ReconciliationMark W. Maier*

The Aerospace Corporation, 15049 Conference Center Drive, Chantilly, VA 20151

SYSTEM AND SOFTWARE ARCHITECTURE RECONCILIATION

Received 2 June 2003; Revised 7 January 2006; Accepted 12 January 2006, after one or more revisionsPublished online in Wiley InterScience (www.interscience.wiley.com). DOI 10.1002/sys.20050

ABSTRACT

Large, complex systems today are increasingly software-intensive. As a result, it is commonlyessential that system development methods strongly facilitate good software development,even where to do so departs from traditional systems engineering practice. Unfortunately, thetraditional state of the practice in systems engineering and system architecture descriptionsare often not well suited to support complex software developments. For example, traditionalsystems engineering practice is to take a function-first approach to definition, while softwarearchitectures are typically driven from the external interfaces inward, and are more oftendata-based than function-based. Moreover, the most successful very large system architec-tures typically take a strongly layered approach, with deliberate selection of convergencelayers, a concept not typically found in traditional systems engineering practice. Each of theseissues can be addressed through understanding of the elements of a good software architec-ture, appropriate ordering of systems engineering activities, and modeling methods extendedto encompass layered system descriptions. While the example here is specific to software-in-tensive systems, the methods applied can be extended to other types of domain integration.© 2006 Syst Eng 9: 146–159, 2006

Key words: architecture; architecting; software; layered systems

1. INTRODUCTION

The world of large, complex systems is software-domi-nated. Most very large or complex systems now have avery large software component, and the most complex

systems are frequently information and software-cen-tric. There would be little surprise at seeing 80% ormore of a development budget spent on software andsoftware-related activities for a consumer electronicsproduct, a military remote sensing system, or an un-manned vehicle. This is due to a combination of twotrends. First, hardware is increasingly commoditized

Regular Paper

*E-mail: [email protected]

Systems Engineering, Vol. 9, No. 2, 2006© 2006 Wiley Periodicals, Inc.

146

because of the economies of scale in 100 million andbillion transistor chips. The economic path of leastresistance for system developers is to buy commodityhardware and provide the system-unique functionalitythrough software. Second, the functional richness andadaptability expected in modern products is practicallyachievable (with current technology) only through largesoftware developments.

The structure of these systems is increasingly multi-layer rather than hierarchical. The layered abstractionfor system composition that has become dominant incommercial communications has rapidly spread toother areas. In a layered system the elements in a lowerlayer are not parts or components of a higher layer (asin the classical system–subsystem–segment hierarchi-cal decomposition), rather they are service providers tothe higher layers. Complex services or functions areassembled through the layered composition of lowerlayer services, without those lower layer providers be-ing solely owned and operated parts of the higher layers.This basic abstraction in system structuring has leddirectly to a fundamental approach to interoperability,that of the “convergence layer” or “convergence proto-col.”

The trends toward software-intensive systems andlayered structures are related and synergistic. We cannotfully consider the impact of either on systems engineer-ing without considering both. Given the growing im-portance of software, it is important to eliminatemismatches in the representations and methods of sys-tems and software engineering. Serious mismatchesexist in the current state of the practice. These mis-matches are in the kinds of information systems engi-neering models provide at the beginning of softwarearchitecting. In many cases the systems models over-define attributes not needed to develop the softwarearchitecture, and entirely ignore other attributes criticalto software architecture. The use of layered abstractionsas a fundamental structuring mechanism is part of thismismatch.

This paper specifically examines the issues involvedin systems and software architecture integration. Thisis a subset of the larger problem of design integrationacross many disciplines and levels of abstraction. Thesections to follow first define key terms and concepts,and then define the integration problem within thecontext of the systems engineering process. The paperthen examines reconcilation methods specific to sys-tems and software architecture, beginning with systemsarchitecture description needs induced by establishedsoftware architecture methods. This examination ofneeds suggests viewpoints that should be altered toeliminate mismatches, and additional viewpointsneeded facilitate design integration. This leads directly

to the specific case of a layered structure viewpoint. TheSysML [SysML, 2005] current as of this writing par-tially addresses the relevant issues, but is also missingimportant elements. Specific layered forms, those withconvergence layers, are a primary means of achievingcertain overall objectives (mainly long-term interoper-ability objectives) that are common in systems in thesoftware-intensive domain. The paper concludes byplacing this specific case in the larger context of gener-alized integration through views and viewpoints, a sub-ject of active research.

2. TERMS AND CONCEPTS

2.1. Architecture and Design

The overall subject of this paper is integration amongdesign representations, specifically architecture repre-sentations. For the purposes of this paper, we use thedefinition of design from IEEE 610.12-1990 [IEEE,1990]:

The process of defining the architecture, components,interfaces, and other characteristics of a system orcomponent; and the result of the process (IEEE610.12-1990).

This paper also follows the practice of ANSI/IEEE1471-2000 [ANSI, 2000; Maier and Rechtin, 2000] intaking a conceptual approach to the definition of archi-tecture, and in distinguishing between architecture as aconcept and architecture description as a collection ofspecific products used by designers in the design proc-ess. The relevant definitions from the ANSI/IEEEstandard [ANSI, 2000] are:

Architecture: The fundamental organization of a sys-tem, embodied in its components, their relationships toeach other and the environment, and the principlesgoverning its design and evolution (ANSI/IEEE 1471)

A collection of products to document an architecture.(ANSI/IEEE 1471)

Across the systems and software communities thereis quite a bit of diversity in exactly what architecturemeans. In a general sense, is broadly agreed that archi-tecture is the embodiment of the set of design decisionsthat define essential characteristics of the system. InClements and Northrup [1996], software architecture

... represents the embodiment of the earliest set ofdesign decisions about a system, and these early bind-ings carry weight far out of proportion to their individ-ual gravity with respect to the system’s remaining

SYSTEM AND SOFTWARE ARCHITECTURE RECONCILIATION 147

Systems Engineering DOI 10.1002/sys

development, its service in deployment, and its main-tenance life.

Put another way, the architecture is that set of systemattributes that largely determine system value, cost, andrisk . An architecture is the definition of the essentialqualities of the system. Other sources [Maier, 2000;Shaw and Garlan, 1996] likewise encompass the ideathat architecture describes the critical properties orstructures of a system, and does so at a relatively highlevel of abstraction. However, the work of Shaw andGarlan [1996] and many others in the software archi-tecture community often takes a more structuralist ap-proach, emphasizing the high-level physical structureas the architecture.

Boehm has emphasized the importance of the soft-ware architecture, and the need to control it [Boehm,1995]:

If a project has not achieved a system architecture,including its rationale, the project should not proceedto full-scale system development. Specifying the archi-tecture as a deliverable enables its use throughout thedevelopment and maintenance process.

The phrase “Architectural Design” has appeared insystems development standards. For example, the sys-tem/segment design document called for by the U.S.MIL-STD-498 development standard calls for an archi-tectural design, and defines it as “...identifying thecomponents, their interfaces, and the concept of execu-tion among them.” By components it is meant hardwareelements, software elements, and manual operations.

For the purposes of this paper we adopt and use thesedefinitions as follows. “Architecture,” either of a systemor of a piece of software, is taken to mean its fundamen-tal organization or structure. Architecture reflects basicdecisions about what a thing (system or piece of soft-ware) will consist of. As engineers we write descrip-tions of the architecture of a system or piece or softwareof interest as part of the design process. “Descriptions”here refers to collection of descriptive elements. “Mod-els” is used in both common senses of the world. First,descriptions are built from models. In this sense indi-vidual models (e.g., drawings, diagrams, texts) are theconstituent elements of an overall description. Second,we use “model” in its more abstract sense of a modelbeing any abstraction of things in the world.

2.2. View and Viewpoint

View and viewpoint are discussed late in the paper, butwith the definitions introduced here for completeness,and to ease the occasional use of the terms earlier in the

paper. We take the approach of ANSI/IEEE 1471 indefining both concepts:

View: a representation of a whole system from theperspective of a related set of concerns.

Viewpoint: a specification of the conventions forconstructing and using a view. A viewpoint actsas a pattern or template from which to developindividual views by establishing the purposesand audience for a view and the techniques for itscreation and analysis.

So, a view is typically a collection of models of asystem, where the collection is sufficient to address arelated set of concerns. For example, we can speak of abehavioral view as the collection of models that definehow a system behaves. In the broad sense of how theterm “model” is used this is itself a model, but, practi-cally, we understand the behavioral description of acomplex system is itself complex, and normally iscomposed of many individual parts, each of which wenormally think of as a model itself. A viewpoint defineshow to construct a view. In the example of a behavioralview, the corresponding viewpoint would define thenotations used to define behavior, the audience for theresulting models, and perhaps methods to be employedin using the notations for their designated audience.

2.3. Layered Systems

The concept of a layered system can be defined incontrast to the classic model of a system–subsystemhierarchy. The system–subsystem hierarchy is built onthe is-a-part-of relationship. That is, an element at onelevel is composed of elements from the level immedi-ately below it. We normally think of this as an exclusivecomposition hierarchy. That means that something canonly be a part of one parent object on the next higherlevel. There aren’t any shared parts.

We always recognize that composition hierarchies,even when considering hardware alone, have other di-mensions than the exclusive composition hierarchy. Forexample, your car probably has four shock absorbers,one for each wheel. Possibly they are the same makeand model (at least when the car first ships). Thus theyshare a common attribute (their make and model), eventhough each is only an actual part of a single wheelassembly. Likewise, there are many more shock absorb-ers of the same family on many other cars, but each isonly actually a part of one wheel assembly on one carat a time.

A layered system is also built from parts, and theparts exist in hierarchy, in the sense of higher and lowerlevels, but the relationship is is-used-by not is-a-part-of.Figure 1 illustrates the difference. In a layered system

148 MAIER


an entity at a lower level provides services to entities ata higher level. Multiple entities at a given level may usean entity at a lower level, but the lower level is notactually a part of any of them. Two common layeredhierarchies are communication protocols and most soft-ware systems. Consider the collection of software onmodern computer. The application programs occupythe top layer. The application programs all use a varietyof shared, lower layer services, such as file reading andwriting, graphics, keyboard input, and the like. Theseshared services are typically provided by the operatingsystem, whose code is not contained within any of theapplication programs. The operating system itselfmakes use of even lower layer services (e.g. devicedrivers) in providing its services.

3. SYSTEMS/SOFTWARE INTEGRATIONISSUES

The phrasing in MIL-STD-498 is representative of whatcan be thought of as the canonical systems engineeringapproach to complex systems design. The fundamentalnotion is top-down, stepwise decomposition. The de-velopers are instructed to first consider functional andother performance objectives, then decompose the sys-tem into subsystems, those subsystems into compo-nents, and so forth. At some point, some of thosecomponents are designated as software componentsand others as hardware or manual operations. In anidealized waterfall model of development, each step inthe chain is completed before proceeding to the next.

This idealized process breaks down in reality onseveral points. In many systems today the cost of soft-ware development dominates the total development

budget. Even though the system of interest is a mixtureof hardware and software, the software may consume80% or more of the development and integration cost.The software is also often a relatively invariant part ofthe overall system. It is common for critical and valu-able software to be moved from processor generation togeneration as each new throughput doubling generationarrives. Unsurprisingly, in these cases the developmentteam needs to begin software architecture work veryearly in the development process, and needs to treat thearchitecture of the software portion of the system as amajor entity in its own right. Moreover, most of thesesystems are built on a spiral process or incrementalprocess with many deliveries over the system lifetime.Most of the change in each increment is generated bydelivering new software, and effective and efficientincremental software development depends on the ex-istence of invariant structures in the software taken as awhole.

In a modern development environment system, soft-ware, and other disciplinary engineering will be at leastpartially concurrent. The conceptual overlap is shownin Figure 2, where the thin lines show the overallactivities and the thick bars the actual tasks. Softwarearchitecting logically follows systems architecting, butoccurs while detailed systems engineering is takingplace. Supporting systems engineering activities willtake place throughout the lifecycle, as shown, but soft-ware architecting parallels the large-scale efforts ofdetailed requirements development and system design.Hence, the developers of the most complex technologi-cal piece of the final system depend on systems engi-neers to provide a continuous flow of data and designdecisions to allow them to work. In particular, systemsengineering must supply very early those data items anddesign decisions necessary to enable the beginning ofsoftware architecting.

Figure 1. Composition versus layered hierarchies.

Figure 2. Process overlap in systems and software engineer-ing.



Many of the complaints between software and sys-tems engineers can be traced to mismatches in this earlysoftware architecting phase. Consider the following:Suppose that systems engineering is focused early ondata or decisions that will not be needed until relativelylate in the software development process. Will softwarearchitecting, the architecting of the largest single ele-ment, be able to wait until they are provided the infor-mation they need? Will software architects proceed ontheir own, making their own decisions, without waitingfor the systems engineering process to complete? Theanswer is obvious: The software architects will proceed.

The overlapping relationships are even more dra-matic in projects organized on spiral development mod-els. In the spiral development model the system goesthrough several iterations of requirements, design, de-velopment, and test. In these cases software design willtake centerplace in iteration because of its relative easeof change. In a spiral development complete systemsengineering cannot, even in principle, take place untillong after the software architecture has been estab-lished. After all, if it were possible to complete allaspects of systems engineering early there would not bea need for the spiral. Effective spiral development re-quires that the overall architecture be relatively stable.The overall stability allows functionality to be incre-mentally added with manageable cost in re-integrationand test in each spiral cycle.

The issue of reconciliation is addressed in threelevels, in increasing order of abstraction. First, is theconcrete issue of design information order. We considerwhat information is demanded by software architecturemodels, and how that information is, or is not, providedby systems engineering methods. This can be resolvedby appropriate ordering of systems engineering activi-ties and some adjustment to methods. Second, we takeup the more general issue of hierarchical versus layereddecomposition. These can be reconciled through theconcepts of viewpoints and views, and the constructionof a particular layered viewpoint. Lastly, we can see thisto be a specific instance of the more general role for theconcept of viewpoint and view in design integration.

4. SOFTWARE ARCHITECTURE CONCEPTS

The goal of this paper has been to examine the issues inintegrating or reconciling system and software architec-ture representations, and to use that as a means forillustrating more general concerns. We can best beginby working backwards from the specific architecturalneeds of software. While there is no single definition ofsoftware architecture, there is a growing body of litera-ture that reveals the concerns of architecture. Principal

among them are the 4+1 model of Kruchten [1995], theGarlan and Shaw model [Shaw and Garlan, 1996], andvarious emerging standards. We deal primarily with the4+1 model because its detail facilitates the under-standing of the interaction of systems and software. Ithas also been influential in the formulation of the Uni-fied Modeling Language (UML), and UML multipleviews support the 4+1 model.

4.1. 4+1 Model

The 4+1 model describes a software architecturethrough its representation in four views and an addi-tional integrating view:

1. The Logical view. This view shows the soft-ware’s object model in the sense of class andobject models. An object model is principally adata representation, but also contains a func-tional decomposition hung on a data relationshipframework.

2. The Process view, which defines concurrencyand synchronization aspects. That is, it defineswhat things happen in logical parallelism, andhow events or interfaces are treated (synchro-nously, asynchronously, etc.).

3. The Physical view, which defines the mappingof the software to the hardware.

4. The Development view, which is the structure ofthe software in its development environment.

+1. The Scenario view, which consists of selecteduse-cases [UML, 1998], scenarios, or threads (touse various terminologies).

4.2. Induced System Architecture Needs

Given a model like 4+1 for software architectures, whatare the induced demands on systems architectures? Putanother way, what are the bottom-up requirements onsystem architectures as determined from software ar-chitectures? Several important points can be gleaned.

1. Detailed functional or behavioral models (in thesense of full input–output models) are not re-quired to define software architecture (to carryout the whole software design and implementa-tion is a different matter). The behavioral modelsneeded are primarily trace or use-case based.

2. Early data modeling should be conducted, andfunctional models organized, in a way to facili-tate class based object oriented modeling. Soft-ware architectures built on 4+1 guidelines will beprimarily data-centric rather than function-cen-tric.

150 MAIER


3. Physical modeling, and allocation maps, shouldinclude the information needed to define concur-rency and synchronization in the software. Mostimportantly, this means the critical informationon interfaces is less about what data flows in andout, than in how it flows in the sense of control.For example, it is much more important to thesoftware architect whether a data flow is drivenin under outside control versus being pulled inunder internal control than is exactly what theflow is.

4. The system hierarchy and allocation mappingsshould support software that spans or movesamong hardware units, as allocation to hardwaremodules is often not unique.

5. ADAPTING SYSTEMS ENGINEERINGMETHODS

Traditional systems methods do not fully support theissues induced from software architecture, althoughthey do so in part, and can often be readily extended,even if they often are not in practice. This sectionreviews the needs identified above and their relation-ship to existing and potential methods.

5.1. Behavioral Definition

Traditionally, there has been a very strong emphasiswithin systems engineering on complete and detailedrequirements flow down. This has included both func-tional requirements (usually captured through func-tional decomposition) and so-called nonfunctional orperformance requirements (usually emergent property-type attributes, such as reliability or maintainability).Traditionally, functional decomposition has been de-fined by functional flow block diagrams or data flowdiagrams. Activity model in the DOD ArchitectureFramework [2003] is essentially the same thing. Othertechniques are usually syntactical or graphical vari-ations on the same themes.

The system-theoretic methods are highly capable ofrepresenting detailed input/output behavior, but thatvery property makes them less than ideal for drivingsoftware architecture. As noted above, detailed func-tional breakdowns are not need for software architect-ing, only general functional breakdowns that helpidentify the highest level software objects are needed.Detailed data definitions, detailed functional flows, andalgorithm specifications can wait until later stages ofsoftware design. Why is there this distinction betweentraditional systems engineering practice with its em-phasis on detailed and complete requirements specifi-cation and software architecture that does not need it?

The difference is a matter of base assumption. Theclassical assumption in systems engineering (and oftentrue) is that rectifying requirements mistakes late in theprocess (for example after a system is fielded) are ordersof magnitude more expensive than avoiding the mistakevery early in the process. In contrast, incremental soft-ware development is predicated on the assumption thatit is impossible to know all the user requirements early,that many of the most important ones can be discoveredonly after a software system is shipped, and that makingfield changes to software is low cost.

Fully understanding the relative merits of these po-sitions, and the intermediate stages in-between, is be-yond the scope of this paper, though a very worthytopic. Simple examples show that both ends of thespectrum are valid in certain cases. For example, in deepspace exploration the cost of defect correction is oftenthe entire cost of the mission (consider the Mars Landerlosses). For these kinds of one-shot systems, very de-tailed upfront understanding is clearly critical. In con-trast, in many consumer electronic products there areenormous economic advantages to being first to marketthat outweigh defect correction costs, and on-goingsoftware updates are expected by the users and are oftena source of revenue for the developer. In this case tryingto understand all the functionality that will eventuallybe demanded by the market without going to the marketis recognized as counterproductive, and the cost ofcorrection is much less than the cost of being late.

A full understanding of this issue is not necessaryfor the purposes of this paper. For our present purposesit is enough to recognize that common software archi-tecture practices very deliberately defer functional de-tails, either into the detailed design phase or into laterincremental cycles of development. Instead the soft-ware architecture practices emphasize identifying fun-damental functional examples (the use-cases) andidentifying relatively stable data structures, captured inthe “Logical” view, usually with class-object diagrams.The elements of the 4+1 software architecture modelcan be seen as response to what is relatively hard tochange, and what is relatively easy to change, and theassociated costs, in software specifically. Adding andrefining functionality to a software system is easy andinexpensive, as long as the addition or change does notinvalidate the data within the software (the logical view)or result in infeasible timing or control relationship withthe outside world (the process view). Changes involv-ing either of those areas are likely to be difficult andexpensive. In contrast, adding and refining functional-ity within a relatively invariant data and control frame-work is exactly what spiraling software developmentseeks to achieve.



The solution in this case is relatively simple: Torealize that a complete and precise functional decom-position has its place, but enabling software architect-ing is not it. Detailed functional specification does needto take place, but it can be carried out in parallel withsoftware development, rather than precede it, so long asthe fundamental issues have been identified very early.Thus, in a software-intensive environment where soft-ware architecture is a critical activity the rigorous ac-tivity of functional decomposition is relatively lessvaluable, but the insightful activity of identifying sys-tem wide, controlling, end-to-end behaviors is veryimportant.

A secondary part of the solution may be to useobject-oriented representation methods rather thanclassical functional decomposition methods. We takethis up in the next section.

5.2. Logical View and Data Definition

Data models (the “Logical View” in the 4+1 model)show the content and interrelationships among complexdata objects. Data modeling has its roots in entity–re-lationship diagrams, but is now moving very stronglyin an object-oriented direction. Class-object models,like classical data flow diagramming methods, actuallycombine both functional and data modeling (as doestraditional data flow modeling, though in a differentway). In traditional data flow models the data-modelingportion is the data dictionary, and the functional decom-position is depicted graphically. In class-object modelsthe graphical centerpiece of the models depict datastructures and relationships with the functional decom-position embedded within as class methods. One canthink of this as organizing the behavioral model on abackbone of data decomposition, rather than the reverseas in the traditional functional decomposition models.There methods were originally exemplified by OMT[Rumbaugh et al., 1991], but the usual choice now isthe Unified Modeling Language [UML, 1998].

This area is often neglected in systems engineeringmodels, sometimes to the serious detriment of the soft-ware developers. Software development generally fa-vors class-object models (though not always), largelybecause so much of the complexity of large softwaresystem is typically in the retained data, its organization,and the managing of data relationships. If a system ischaracterized by a very complex data view it is virtuallycertain that all of that view (and the associated function-ality) will be allocated to software for implementation.Hence there is little or nothing to be gained by devel-oping models for that view that match poorly to theneeds of software development. In this case the bestsolution to integrating the systems and software archi-

tecture perspective is likely to be to simply defer to thesoftware perspective. Develop an integrated logicalview built from class-object models that capture bothdata relationships and functional decomposition. Thestandard methods of developing such views will orderthe products in ways that better match the needs ofsoftware architecture than the function-first methods oftraditional systems engineering. The constituent mod-els form a functional requirements specification for thesoftware (and the overall system) through the specifi-cation of the object methods. This can be carried out asrigorously as the developers find appropriate, and caneven incorporate formal traceability links and conditiontesting if so desired. Essentially nothing is necessarilylost in the possibility of rigor in the system specificationprocesses, except that the modeling vocabulary of theperformers will have to be rebuilt.

5.3. Interface Specification

The most glaring disconnect between traditional archi-tecture modeling perspectives of systems and softwareis in the system’s models lack of support for the speci-fication of software concurrency and synchronization.A central concern of the software architect is to under-stand the needs for synchronous and asynchronousinterface to the outside world, as seen by the software.The interfaces in question are not the logical interfacesof system context diagrams, but the physical interfacesfrom software to hardware. Moreover, the charac-terizations needed are not of the data elements, but ofthe logic or the control of their transfer. This informa-tion is tied to a model of the system as implemented,that is, to physical a view of the system.

Consider the following thought experiment. A sys-tem receives 1000 messages of size 1000 bytes everysecond. In one version one message arrives every mil-lisecond and is held in a hardware queue until retrievedby the software in the system for functional processing.In the second version the messages arrive at an averagerate of 1000 Hz, but arrive randomly and separated byas little as a microsecond. Moreover, each message isavailable for retrieval only from its arrival to the arrivalof the next message (which could be in as little as onemicrosecond). While both versions have the same mes-sages and the same data rate, they present radicallydifferent challenges to the software architect. Whilethey both imply the same processing rate, they imply a1000:1 difference in degree of control necessary overinternal timing. This will have an enormous impact onhow the software can be structured. It is obviouslyessential to effective software architecting that whichof the two situations pertains be determined, and clari-fying among them is clearly if much greater importance

152 MAIER


to the earliest software architecture activities than aredetails of the functional requirements. The existence ofmultiple interfaces with constraint relationships amongthem is typical in real systems, and only amplifies thepoint.

This issue can be dealt with directly by appropriateextensions to common block diagramming methods. Aswe shall see later, we also wish to extend block-dia-gramming methods to encompass layering. The exten-sion discussed here are complementary to theextensions discussed later related to layering. Systemsengineering commonly uses block diagrams of severaltypes to specify the physical realization of the system.The information needed for synchronization and con-currency analysis should be contained in these dia-grams, but it often is not. The popular diagram basedmethodologies frequently provide for some form ofphysical model. The most extensive set of physicalmodeling diagrams is defined in the Hatley-Pirbhai[Hatley and Pirbhai, 1988] method. This method usestwo types of physical block diagram, one that shows theinformation flow among the physical elements andanother that shows the physical channels connecting theelements. A newer version of this method [Hatley et al.,1998] extends the notation to show push/pull logic onthe flow diagram.

We propose here a generalization of the approach,built on the example of the ADARTS [SPC, 1990]method for software design. We outline here how to dothis, although this is not a formal specification for amethod. Each element of this model consists of compo-nents and connectors. The identification of componentsand connectors depends on the layer to which they areassigned, defined in a subsequent section. For the mo-ment we consider a component to by any physicallyidentifiable part of the system and a connector to be achannel by which an identified data element flowsbetween at least two components. Connectors come ingeneric and specific types. The generic types representthe main logical categories of interconnection (e.g.,loose or tight coupling, push or pull, queued). A UMLmodel of this concept is given in Figure 3. It is importantto understand that Figure 3 is not the only possiblegeneric model of interface control typing. It representsa typically useful classification of interface charac-teristics. Specific types have to be defined for a particu-lar system, as they correspond to the actual physicalinterface types chosen for that system.

So far we have avoided saying that a componentcorresponds to a “box” and a connector to an “arrow,”although that is what will normally be done. Part of thisconcept is to separate the logical content of the physicalmodel from the graphical depiction. A given modelingmethod with well-structured content can be mapped to

a variety of textual and/or graphical representations. Inthis case we use the usual round-sided boxes for com-ponents and lines for the connectors. An arrowed lineindicates the direction of flow (for those connectors thathave flow) and an enhancement on the line indicates thedirection of control and the type to which it belongs. Anexample of a set of graphical conventions for the UMLmodel in Figure 3 is in Figure 4. An example diagramusing these conventions, restricted to three layers, isshown in Figure 6.

This method, which is deliberately defined as asystem method in not being attached to any particularimplementation technology, whether hardware or soft-ware, directly addresses the point raised about lack ofinterface definition required for software architecting.Where traditional block diagrams that do not specifythe direction or type of control fail to provide concur-rency and synchronization information, these do. Thusthey fill the identified gap in system architecture mod-eling support to software architecting.

The version 1.0 alpha specification of the SystemMarkup Language [SysML, 2005], the most current as

Figure 3. Partial UML diagram for layered physical modelwith logical enhancements.

Figure 4. Example graphical conventions for logically en-hanced physical connectors.



of this writing, partially supports the concepts discussedhere. The structure diagram in SysML explicitly pro-vides for noting ports and port specifications. To theextent that all of the issues of interface typing discussedhere can be captured in SysML structure diagram portspecifications, the SysML specification will support themethod advocated here. However, there is more to themethod described there than simply having port speci-fications. The method defined here predefines at least alimited set of generic flow types, and insist on specify-ing them early in the design cycle. In SysML one wouldneed to extend the base definitions (with no fixed porttypes) to capture this. This is permitted in usage ofSysML, but not defined. A more important issue is theneed for multiple structure descriptions (whether dia-grams or otherwise) that have specific layer correspon-dence. This is described in the next major section.

5.4. Allocation and Traceability Issues

The only issue here that is software-unique is that insome software-intensive systems there is no fixed rela-tionship between software modules and hardware mod-ules. A given piece of software, which fulfills someelement of the system’s requirements, may have nofixed physical home; it may be implemented in such away that it migrates among processing resources inresponse to demands on the system. This is a conceptualproblem for requirements traceability only if one insistson a strict vertical hierarchy of components and uniquetraceability to those vertical components. As discussedin the next section, the attachment to a single hierarchyneeds to be replaced in the multiple view paradigm, andit leads naturally to accommodating layered systemissues. Traceability need not be abandoned, but it can-not any longer be tied strictly to a single vertical hier-archy to allocate to.

6. LAYERED (AND MULTIPLE)HIERARCHIES

The issue of layering and mismatched hierarchies hasbeen brought up several times, but not comprehensivelyaddressed. Understanding this issue is the bridge fromthe specific issues of reconciling system and softwarearchitecture elements and more general reconciliationconcerns that requires the more general (and powerful)perspective of viewpoints and views. That all systemsexist in a hierarchy of systems and subsystems is almostan article of faith among systems engineers. A funda-mental insight is that all systems are components oflarger systems, and all systems are themselves com-posed of subsystems. The problem is that the naturalhierarchy of system and subsystem is quite different

from different perspectives, and specifically quite dif-ferent when viewed from software-centric and hard-ware-centric perspectives.

Consider a large, multiprocessor, software-intensivesystem (say a command and control system with manyuser workstations, sensor, and communications feeds).From the hardware-centric perspective the systemwould be represented as a hierarchy of interconnectedprocessors, each containing software units, as in thelower section of Figure 5. In this perspective the soft-ware elements are components of the hardware modulesthat happen to have processors. But, in a command andcontrol system, there is quite likely no absolutely fixedrelationship between software and hardware elements.It may be highly desirable for functions implementedin software to be replicable, perhaps dynamically, onadditional workstations as the load increases and opera-tors are added. Conversely, there may be austere ver-sions where software is aggregated on hardwaremodules. Now consider the upper part of Figure 5 andthe perspective of software developers. The softwaredevelopers may have gone to considerable lengths toavoid any fixed set of configurations at all, but rathermay have developed their application software to de-pend on sea of network and “middleware” services thatthemselves float on a variable sea of computationalresources. From the software perspective the hierarchyis reversed. At the top is a distributed application,composed of large-scale software units that run acrossthe network without regard to location, and often with-out explicit awareness of the computational topologyon which they run. Below the application are the oper-ating system (OS) and library layers that support the

Figure 5. Mismatched systems and software hierarchies.

154 MAIER


distributed application. At the bottom of the hierarchyis the hardware, the actual processors, and interconnec-tion network.

Both hierarchies are simultaneously valid, althoughnot equivalent. At any given moment software modulesare contained within (execute on) given pieces of hard-ware. But, just as surely, the layered perspective of thedeveloper is how the software is actually constructedand represents the computational world as actually seenby a participant in it.

The mismatch has consequences. If the hardware-centric hierarchy is imposed on the overall system, thesoftware development will suffer consequences. Thismost commonly occurs when a hardware-based hierar-chy model is used to structure a work breakdown struc-ture, and thus places significant constraints on theorganization of the development work. Among the con-sequences are likely to be:

1. The operating system may not be recognized asa component at the same level as the hardware,since it is inherently distributed. This may causeit to be ignored, or may demand over specifica-tion of a bought item.

2. Interface software may be forced to be replicatedin each hardware unit as an application evenwhen it could be provided as an OS service. Thereplication can increase develop costs linearlywith the replication, and the impact on test andmaintenance may be even worse.

3. Management overhead is increased if distributedsoftware units have to be treated as independenteven when they operate as a single system andare not written separately.

4. Scalability across variable numbers of processorsmay be compromised by treating the multiproc-essor aspects as application issues when theyshould belong to the operating system or othermiddle-ware services.

It can be argued that this mismatch is not inherent incurrent methods and standards. But the mismatch is atleast implicit. Common software architecture conceptscall for descriptions in terms of components, connec-tors, and constraints. Connections can be of many types.Connection in the sense of passing data between is one.But modern software-intensive systems are developedprimarily by building on top of operating system andmiddleware layers rather than writing code from theground up. Thus the hardware to software relationshipis mediated by other purchased software, and theirinterrelationships are complex. Given pieces of appli-cation software may migrate from machine to machinein execution in a way that is controlled by the operating

system, not by the application programmer. To theextent that this relieves the application programmer ofa very complicated job, and facilitates the reuse ofsoftware by “shrink-wrapped sale,” this obscuration ofwhat is happening is laudable.

Close reading of some development standards, suchas MIL-STD-498, shows that multiple hierarchies anda variety of connections and relationships are permitted.But the structure of the required documents, top-downdecomposition in hardware and computer software con-figuration items (CSCIs), would seem to make it a hardpath to employ. Few structured methods provide anyway of explicitly showing the relationships of softwarelayers in functional decomposition, much less a waythat is friendly to multiple hierarchies. The Hatley-Pirbhai88 methodology [Hatley and Pirbhai, 1988]does allow for explicit functional interface models—one of the very few that does [Wood and Wood, 1989;Maier, 1996]—but places everything in a single physi-cal hierarchy.

Like the older 498, the new SysML specificationdoes not recognize layered structures, but does notexclude them. The formalism of the structure charts isclearly tied to a hardware-centric hierarchy. There is noexplicit provision within the SysML 1.0 alpha specifi-cation to carry multiple structure charts, each corre-sponding to different layers, with consistencyrelationship among other than classic hardware-centriccomposition. On the other hand, the specification doesnot exclude one using the structure chart formalism inthat way, or exclude one from developing an extensionto the SysML that explicitly provides for layered mod-els.

A related issue is in how one understands the inter-faces of an object’s interfaces. In SysML a module mayhave physical functional ports, the latter providing serv-ices to other modules. This is clearly true (the notionwas discussed here), but in a layered system the notionis somewhat more complex. As an example consider anetwork switch. One of the services it expresses to theoutside world is the ability to be configured. That is,other modules can set its switching configuration. Butthere might be many physical ways to do so (e.g., a pushbutton front panel, a serial port to plug in a terminal, aninternal web server, and the ability to do remote proce-dure calls to internal software modules over the net-work). All of the physical means may work to the same(or subsets of the) service. That is, the services arevisible through multiple interfaces (simultaneously).There many be shared intermediate layers as well inaccessing those services.

The overall point is that the layered method of sys-tem construction leads us to understand the moduleinterfaces are much more complicated and inter-related



than just a physical-logical split. While recognizing thelogical-physical split is a good first step, eventually, wewill need means for organizing many levels. To do socoherently, we need a solidly grounded means of iden-tifying the concept of a layer, and of expressing inter-layer relationships. The layered model described herecould be very usefully added to SysML as an extension.

Returning to the overall concept, the way out of thisproblem is to recognize that there is nothing fundamen-tally privileged about a hardware-centric decomposi-tion. The decomposition along hardware lines isarbitrary; it is a choice of a representation not somethingfundamental. Other representations are equally funda-mental. This leads to the notion of a “view” or of an“architecture view” when specifically applied to archi-tecture. As introduced in the definitions, a view can bethought of as a projection of the system with respect tosome set of related concerns. It is a depiction of thewhole system, but only with respect to the chosenconcerns.

Multiview methods are now accepted, although theyare not well formalized. A variety of standards in archi-tecture and design embrace multiple views. Amongthem are the US Department of Defense ArchitectureFramework [DOD Architecture Framework, 2003], theInternational Standards Organization Reference Modelfor Open Distributed Processing [ISO/IEC, 1996], andthe Zachman Framework [Zachman, 1987]. The stand-ard ANSI/IEEE 1471 Recommended Practice for theArchitectural Description of Software-Intensive Sys-tems [ANSI, 2000] has a generic model for configuringdescriptions in multiple views and formalizing frame-

works through “viewpoints.” Other standards in devel-opment, such as the update to IEEE 1016 on SoftwareDesign Descriptions are extending this model to otherdomains. A complete, formal treatment of the conceptof views and viewpoints has not yet been given, but thesubject has been explored in Maier [2000].

6.1. Layers and Views

While the general notion of views and viewpoints ispowerful, our concerns here in this paper are narrower.Specifically, we want to use the notion of layered sys-tem definition to further enrich the physical model withflow and control discussed earlier. By understandinghow layers are identified in the standard communica-tions protocol stack we can better understand how toorganize the system portion of the physical view of asoftware-intensive system. It allows us to answer di-rectly this issue of how to identify components andconnectors in the physical modeling method brieflydescribed previously.

The original, and best-known, reference set of layersfor a system is the Open Systems Interconnection (OSI)[ISO/IEC, 1996] 7-layer model. While the OSI 7 layerstaken as a whole are obsolete, they have been highlyinfluential in the construction of actual systems. Thelower layers of the 7-layer stack can be taken these daysas effectively standardized. Table I presents, in reverseorder, from lower layer to upper, a map of layer, com-ponent, connector, and concerns typically addressed.

The importance of the use of the layered concepthere is twofold. First, the layered concept can greatly

Table I. Layered Model for Organizing Physical System/Hardware/Software Models

156 MAIER


organize the construction of physical block diagramsusing the methods described previously. Ambiguityabout what constitutes a component or connector isremoved when there is a model per layer. At each layerthe components and connectors are defined by the serv-ice abstraction relevant to that layer. So, for example, arouter can appear in layer 1, 2, or 3’s block diagram, butnot higher because (at least in the case of Internetprotocol choices) it is invisible to the higher layers.Also, what constitutes a connector is greatly clarified ateach level. At the application level is makes sense tomodel the logical data, that is, the data that are directlymeaningful to the stakeholders for the system. Thatlogical data does not appear directly at lower layersbecause in the lower layers it is encapsulated by thenature of the channels defined at each layer. Again,using an Internet-based example, at layer 3 we know thechannels are all packet channels, either point-to-pointor broadcast. Their contents are blocks of bytes, be-cause that is how the Internet protocol stack definescommunication layer 3.

A second important use is that particular desired andcomplex system attributes can be clarified in the contextof layers. As an example, many complex systems havean “interoperability” objective, although that objectiveis notoriously hard to clearly define, much less to quan-tify. In the context of a standardized layered decompo-sition, however, interoperability is considerablyclarified. Consider assembling a group of systems intocooperating whole. We can characterize their interop-erability by asking what they have in common by layer.So, in the case of systems connecting to the Internet,they share a single layer 3–4 protocol, TCP/IP. Thisprovides ubiquitous machine-to-machine exchange ofblocks and steams of bytes. It does not guarantee eitherphysical connectivity or application level communica-tion. So, for example, if you have two machines, onewith an Ethernet port and the other with a wireless card,the presence of TCP/IP on both does not allow commu-nication. But, if you then get a wireless hub with anEthernet port, you can guarantee the two machines willbe able to exchange bytes. But, again, exchanging bytes

Figure 6. Example layered use of enhanced block diagram model.



is a long way from actually having communicatingapplications. Because the Internet protocol family lacksany widely deployed standard upper layer protocolseach pair of interoperating applications must resolve theupper layers concerns individual.

These points are illustrated, using the notations de-fined earlier, in Figure 6. The example for Figure 6 is asimple Web cam. A camera and computer combinationrecords an image at a fixed rate. A Web server draws themost recent image from the camera-computer combi-nation when on its own schedule. A remotely locatedWeb browser downloads and displays the image. Thevarious elements interplay at many layers. Figure 6illustrates the components and connectors (and the in-terface flow of control) for three of those layers, thephysical, the network, and the application.

7. VIEWS, VIEWPOINTS, ANDINTEGRATION IN GENERAL

Recognizing the presence of two simultaneously true,but clearly distinct, views of a software-intensive sys-tem was very useful in reconciling architecture com-patibility issues. By examining the information contentof a hardware-centric and a software-centric view, wewere able to identify extensions to modeling methodsto facilitate the development of software-intensive sys-tems. This can be considered part of a stakeholder-cen-tric approach to system architecture. In this approach,we examine the concerns, and the preferred views, ofmajor stakeholders (which includes disciplinary devel-opers as well as user/acquirers). Then, we work “in-ward” from their concerns to what needs to be part ofan architecture description, continuously looking forhow the resulting methods can be reconciled with eachother, to avoid the serious error us just assuming ortho-gonality and allowing views to be developed inde-pendently. This approach can be applied much morebroadly than just to software and hardware, but thedetails of other views and their reconciliation is beyondthe scope of the present paper. The purpose of the paperwas to demonstrate the flow for the reconciliation in thisparticularly important case.

8. CONCLUSIONS ANDRECOMMENDATIONS

The recognition of the value of an architectural ap-proach, and of an architect, in particular, is of longstanding. Brooks has written, in a retrospective on hisfamous book [Brooks, 1995]:

Today I am more convinced than ever. Conceptualintegrity is central to product quality. Having a systemarchitect is the most important step toward conceptualintegrity.

The central focus of this paper was on reconcilingsystem and software architectures, that is, ensuringintegrity between the most expensive and functionallyrich part of most modern systems, and the overallsystem itself, what we deliver to bring value to stake-holders. The principal recommendations are:

1. Systems modeling methodologies, and their as-sociated tools, should pay much closer attentionto the software/hardware interface. In particular,physical modeling methods are needed that ex-plicitly represent the control of data flow acrossthe hardware–software boundary. An example ofsuch a method was provided here.

2. Data modeling should be done carefully, andearly, and in most cases using class-object mod-eling methods rather than traditional functionaldecomposition.

3. Functional and behavioral analysis techniquesshould emphasize the identification and docu-mentation of the critical scenarios early in theprocess, and defer detailed functional specifica-tion to a parallel effort with software design.

4. Requirements and functional allocation methodsneed to take into account that multiprocessorsystems will dynamically allocate functions tohardware. This dynamic allocation should not beprecluded by static allocation rules.

REFERENCES

ANSI/IEEE Std. 1471-2000 Recommended Practice for Ar-chitectural Description of Software-Intensive Systems.

B. Boehm, Engineering context (for software architecture),Invited Talk, First International Workshop on Architecturefor Software Systems, Seattle, WA, 1995.

F. Brooks, The mythical man month, after twenty years,Addison-Wesley, Reading, MA, 1995.

P.D. Clements and L.M. Northrop, Software architecture: Anexecutive overview, Technical Report, CMU/SEI-96-TR-003, 1996, Pittsburgh, PA.

Department of Defense (DOD) Architecture Framework, ver-sion 1.0, U.S. Department of Defense Architecture Work-ing Group, Washington, DC, 2003.

D.J. Hatley and I. Pirbhai, Strategies for real-time systemspecification, Dorset House, New York, 1988.

D.J. Hatley, et al. A methodology for systems development,Dorset House, New York, 1998.

158 MAIER


ISO/IEC, ISO/IEC 10746-2:1996, Information technology—Open distributed processing—reference model: Founda-tions, 1996.

P.B. Kruchten, A 4+1 view model of software architecture,IEEE Software Magazine 12(6) (November 1995), 42–50.

M.W. Maier, Integrated modeling: A unified approach tosystem engineering, J Syst Software 32(2) (February1996), 101–119.

M.W. Maier, Model organization through viewpoints andviews, Proc Int Council Syst Eng Mid-Atlantic RegionalConf, 2000, pp. 6.2-1–6.2-9.

M. Maier and E. Rechtin, The art of systems architecting,CRC Press, Boca Raton, FL, 2000.

J. Rumbaugh, et al., Object-oriented modeling and design,Prentice Hall, Englewood Cliffs, NJ, 1991.

M. Shaw and D. Garlan, Software architecture: Perspectiveson an emerging discipline, Prentice Hall, EnglewoodCliffs, NJ, 1996.

Software Productivity Consortium (SPC), ADARTS user’sguidebook: The ADARTS method, Vols. 1–3,ADARTS_GUIDEBOOK-90031-MC, Software Produc-tivity Consortium, Herndon, VA, September 1990.

Systems Markup Language (SysML) Specification 1.0 alpha,14 November 2005, www.sysml.org, accessed January 6,2006.

Unified Modeling Language (UML), Version 1.1 notation andsemantics definition, http://www.rational.com, RationalCorporation, Vancouver, B.C., Canada, 1998.

U.S. Department of Defense, C4ISR Architecture Framework2.0, Washington, DC, 2000.

D.P. Wood and W.G. Wood, Comparative evaluation of fourspecification methods for real-time systems, SEI Techni-cal Report, CMU/SEI-89-TR-36, Software EngineeringInstitute, Pittsburgh, PA, 1989.

J.A. Zachman, A framework for information systems archi-tecture, IBM Syst J 26(3) (1987), 276–292.

Mark W. Maier is a Distinguished Engineer at The Aerospace Corporation, specializing in systemsarchitecting and analysis. Previously, he was Associate Professor of Electrical and Computer Engineeringat the University of Alabama in Huntsville. He was educated at Caltech and the University of SouthernCalifornia, where he received a Ph.D. in Electrical Engineering. While at USC he held a Hughes AircraftCompany Doctoral Fellowship, where he was also employed as a section head. He is the co-author of TheArt of Systems Architecting. He is a Fellow of the International Council on Systems Engineering.



system and software architecture reconciliation

Documents