See discussions, stats, and author profiles for this publication at: https://www.researchgate.

net/publication/229677275

Systems Architecture

Chapter · December 1999

DOI: 10.1002/047134608X.W7114

CITATIONS READS

4 1,624

1 author:

Alexander H Levis
George Mason University
272 PUBLICATIONS 2,787 CITATIONS

SEE PROFILE

All content following this page was uploaded by Alexander H Levis on 01 July 2019.

The user has requested enhancement of the downloaded file.

314 SYSTEMS ARCHITECTURE

SYSTEMS ARCHITECTURE

Rapid changes in information technology, uncertainty regard-

ing future requirements, and increasing complexity of sys-
tems have led to the use of systems architectures as a key
step in the systems engineering process. While hardware and
software components of a system can change over time, the

J. Webster (ed.), Wiley Encyclopedia of Electrical and Electronics Engineering. Copyright # 1999 John Wiley & Sons, Inc.
 SYSTEMS ARCHITECTURE 315

underlying architecture remains invariant. This allows grace- structured analysis and design, has served the needs of sys-
ful upgrading of systems through the use of components from tems engineers and has produced many of the complex sys-
many manufacturers whose products conform to the architec- tems in use today. It is effective when the requirements are
ture. The use of systems architectures has been very effective well-defined and remain essentially constant during the sys-
in telecommunication systems, in software development, and tem development period. However, this well-focused approach
in computers. It is now being extended to large-scale informa- cannot handle change well; its strength lies in its efficiency
tion systems. in designing a system that meets a set of fixed requirements.
Two basic paradigms are available for designing and eval- An alternative approach with roots in software systems en-
uating systems and architectures: the structured analysis and gineering is emerging better able to deal with uncertainty in
the object oriented approaches. Both require multiple models requirements and in technology, especially for systems with
to represent them and both lead, through different routes, to long development time and expected long life cycle during
executable models. The latter are appropriate for analyzing which both requirements and technology will change. This ap-
the behavior of the architecture and for evaluating perfor- proach is based on object oriented constructs. The problem is
mance prior to system implementation. formulated in general terms and the requirements are more
Systems architecting has been defined as the process of abstract and, therefore, subject to interpretation. The key ad-
creating complex, unprecedented systems (1,2). This de- vantage of the object oriented approach is that it allows flexi-
scription fits the computer-based systems that are being bility in the design as it evolves over time.
created or planned today, whether in industry, government,
or academia. The requirements of the marketplace are ill-
defined and rapidly changing with evolving technology mak- DEFINITION OF ARCHITECTURES
ing possible the offering of new services at a global level.
At the same time, there is increasing uncertainty as to the In defining an architecture, especially of an information sys-
way in which they will be used, what components will be tem, the following items need to be described. First, there are
incorporated, and the interconnections that will be made. processes that need to take place in order that the system
Generating a system architecture as part of the systems accomplish its intended functions; the individual processes
engineering process can be seen as a deliberate approach to transform either data or materials that flow between them.
manage the uncertainty that characterizes these complex, These processes or activities or operations follow some rules
unprecedented systems. that establish the conditions under which they occur; further-
more, they occur in some order that need not be deterministic
The word architecture derives from the Greek word archi-
and depends on the initial conditions. There is also need to
tecton which means master mason or master builder. The ar-
describe the components that will implement the design: the
chitect, now as then, is a member of the team that is responsi-
hardware, software, personnel, and facilities that will be the
ble for designing and building a system; then the systems
system.
were edifices, now they are computer-based and software in-
This fundamental notion leads to the definition of two ar-
tensive. Indeed, the system architect’s contribution comes in
chitectural constructs: the functional architecture and the
the very early stages of the systems engineering process, at
physical architecture. A functional architecture is a set of ac-
the time when the operational concept is defined and the con-
tivities or functions, arranged in a specified partial order that,
ceptual model of the system is developed. Consequently, the
when activated, achieves a set of requirements. Similarly, a
design of a system’s architecture is a top-down process, going
physical architecture is a representation of the physical re-
from the abstract and general to the concrete and specific. sources, expressed as nodes, that constitute the system and
Furthermore, it is an iterative process. The process of devel- their connectivity, expressed in the form of links. Both defini-
oping an architecture in response to requirements (that are tions should be interpreted broadly to cover a wide range of
ill-structured because of multiple uncertainties) forces their applications; furthermore, each may require multiple repre-
re-examination. Ambiguities are identified and resolved and, sentations or views to describe all aspects.
when inconsistencies are discovered, the requirements them- Before even attempting to develop these representations,
selves are reformulated. the operational concept must be defined. This is the first step
One thinks of system architectures when the system in in the architecture development process. An operational con-
question consists of many diverse components. A system ar- cept is a concise statement that describes how the goal will
chitect, while knowledgeable about the individual compo- be met. There are no analytical procedures for deriving an
nents, needs to have a good understanding of the inter-rela- operational concept for complex, unprecedented systems. On
tionships among the components. While there are many tools the contrary, given a set of goals, experience, and expertise,
and techniques to aid the architect and there is a well-defined humans invent operational concepts. It has often been stated
architecture development process, architecting requires cre- (1) that the development of an architecture is both an art and
ativity and vision because of the unprecedented nature of the a science. The development of the conceptual model that rep-
systems being developed and the ill-defined requirements. For resents an operational concept falls clearly on the art side. A
detailed discussions on the need for systems architecting, see good operational concept is based on a simple idea of how the
Refs. 1–7. over-riding goal is to be met. For example, ‘‘centralized deci-
Many of the methodologies for systems engineering have sion making and distributed execution’’ represents a very ab-
been designed to support a traditional system development stract operational concept that lends itself to many possible
model. A set of requirements is defined; several options are implementations, while an operational concept such as the
considered and, through a process of elimination, a final de- ‘‘client-server’’ one is much more limiting. As the architecture
sign emerges that is well defined. This approach, based on development process unfolds, it becomes necessary to elabo-
316 SYSTEMS ARCHITECTURE

Operational Analysis
concept phase

Functional Synthesis
architecture phase

Physical Evaluation
architecture phase

Technical Dynamics Executable MOP

Figure 1. The three phase process of architec- architecture model model MOE
ture development.

rate on the operational concept and make it more specific. The in the 1950s (8) and encompasses structured design (9), struc-
clear definition and understanding of the operational concept tured development (10), the structured analysis approach of
is central to the development of compatible functional and DeMarco (11), structured systems analysis (12), and the many
physical architectures. variants that have appeared since then, often embodied in
Analogous to the close relationship between the opera- software packages for computer-aided requirements genera-
tional concept and the functional architecture is the relation- tion and analysis. This approach can be characterized as a
ship between the technical architecture and the physical one. process-oriented one (12) in that it considers as the starting
A technical architecture is a minimal set of rules governing point the functions or activities that the system must per-
the arrangement, interaction, and interdependence of the form. A second characterizing feature is the use of functional
parts or elements whose purpose is to ensure that a con- decompositions and the resulting hierarchically structured di-
formant system satisfies a specified set of requirements. It agrams. However, to obtain the complete specification of the
provides the framework upon which engineering specifica- architecture, as reflected in the executable model, in addition
tions can be derived, guiding the implementation of the sys-
to the process or activity model, a data model, a rule model,
tem. It has often been compared to the building code that pro-
and a dynamics model are required. Each one of these models
vides guidance for new buildings to be able to connect to the
contains inter-related aspects of the architecture description.
existing infrastructure by characterizing the attributes of
For example, in the case of an information system, the activi-
that infrastructure.
All these representations are static ones; they consist of ties or processes receive data as input, transform them in ac-
diagrams. In order to analyze the behavior of the architecture cordance with some conditions, and produce data as output.
and evaluate the performance characteristics, an executable The associated data model describes the relationships be-
model is needed. An executable model is a dynamic model; it tween these same data elements. The conditions that must be
can be used to analyze the properties of the architecture and satisfied are expressed as rules associated with the activities.
it can also be used to carry out simulations. Both methodolo- But for the rules to be evaluated, they require data that must
gies, whether structured analysis based or object oriented be available at that particular activity with which the rule is
based, become rigorous when an executable model is derived associated; the output of the rule also consists of data that
and the condition is imposed that all information contained control the execution of the process. Furthermore, given that
in that model must be traced back to one or more of the static the architecture is for a dynamic system, the states of the
diagrams. This dynamic model of the architecture is called system need to be defined and the transitions between states
the operational-X architecture where the X stands for the exe- identified to describe the dynamic behavior. State transition
cutable property. diagrams are but one way of representing this information.
The architecture development process can be characterized Underlying these four models is a data dictionary or, more
as consisting of three phases: the analysis phase in which the properly, a system dictionary, in which all data elements, ac-
static representations of the functional and physical architec- tivities, and flows are defined. The construct that emerges
tures are obtained using the operational concept to drive the from this description is that a set of inter-related views, or
process and the technical architecture to guide it; the synthe- models, are needed to describe an architecture using the
sis phase in which these static constructs are used, together structured analysis approach. The activity model, the data
with descriptions of the dynamic behavior of the architecture
model, the rule model and the supporting system dictionary,
(often referred to as the dynamics model), to obtain the exe-
taken together, constitute the functional architecture of the
cutable model of the architecture, and the evaluation phase
system. The term functional architecture has been used to
in which measures of performance (MOP) and measures of
effectiveness (MOE) are obtained. This three phase process is describe a range of representations—from a simple activity
shown schematically in Fig. 1. model to the set of models defined here. The structure of the
functional architecture is shown in Fig. 2.
STRUCTURED ANALYSIS APPROACH At this time, the architect must use a suite of tools and,
cognizant of the inter-relationships among the four models
The structured analysis approach has its roots in the struc- and the features of the tools chosen to depict them, work
tured analysis and design technique (SADT) that originated across models to make the various views consistent and co-
 SYSTEMS ARCHITECTURE 317

are used to identify the data or objects represented by the

d
i Activity model arcs. There are detailed rules for handling the branching and
S c the joining of the arcs. A key feature of IDEF0 is that it sup-
y t ports hierarchical decomposition. At the highest level, the A-
s i
t
0 level, there is a single activity that contains the root verb
o Data model Functional of the functional decomposition. This is called the context dia-
e n architecture
m a gram and also includes a statement of the purpose of the
r model and the point of view taken. The next level down, the
y A0 level, contains the first level decomposition of the system
Rule model function and the interrelationships between these functions.
Each one of the activity boxes on the A0 page can be further
Figure 2. Structure of the functional architecture. The functional decomposed into the A1, A2, A3, . . . page, respectively.
architecture contains an activity model, a data model, and a rule Associated with IDEF0 is a data dictionary which includes
model. The three models must be in concordance with each other and the definitions and descriptions of the activities, listing and
have a common data dictionary. description of the inputs, controls, and outputs, and, if en-
tered, a set of activation rules of the form ‘‘preconditions 씮
postconditions.’’ These are the rules that indicate the condi-
herent, that is, to achieve model concordance. The architect tions under which the associated function can be carried out.
must obtain a single, integrated system dictionary from the
individual dictionaries produced by the various tools that gen- Data Model
erate the different views.
What a functional architecture does not contain is the The purpose of a data model is to analyze the data structures
specification of the physical resources that will be used to im- and their relationships independently of the processing that
plement the functions or the structure of the human organiza- takes place, already depicted in the activity model. There are
tion that is supported by the information system. These de- two main approaches with associated tools for data modeling:
scriptions are contained in the physical architecture. IDEF1x and entity-relationship (E-R) diagrams. Both ap-
proaches are used widely. The National Institute of Stan-
Activity Model dards and Technology has published Draft Federal Informa-
tion Processing Standard #184 in which IDEF1x is specified.
A method in wide use for the representation of an activity There are many books that describe E-R diagrams: Sanders
model is IDEF0 which has systems engineering roots; for its (14), Yourdon (15), McLeod (16).
history, see (8). The National Institute of Standards and IDEF1x (IDEF1 extended) is a modeling language for rep-
Technology (NIST) published Draft Federal Information Pro- resenting the structure and semantics of the information in a
cessing Standard #183 for IDEF0. IDEF0 is a modeling lan- system. The elements of IDEF1x are the entities, their rela-
guage for developing structured graphical representations of tionships or associations, and the attributes or keys. An
the activities or functions of a system. It is a static represen- IDEF1x model is comprised of one or more views, definitions
tation, designed to address a specific question from a single of the entities, and the domains of the attributes used in the
point of view. It has two graphical elements: a box, which views.
represents an activity, and a directed arc that represents the An entity is the representation of a set of real or abstract
conveyance of data or objects related to the activity. A distin- objects that share the same characteristics and can partici-
guishing characteristic of IDEF0 is that the sides of the activ- pate in the same relationships. An individual member of the
ity box have a standard meaning, as shown in Fig. 3. Arcs set is called an entity instance. An entity is depicted by a box;
entering the left side of the activity box are inputs, the top it has a unique name and a unique identifier. If an instance
side are controls, and the bottom side are mechanisms or re- of an entity is identifiable with reference to its relationship to
sources used to perform the activity. Arcs leaving the right other entities, it is called identifier dependent. The box de-
side are outputs—the data or objects generated by the activ- picting the entity instance is divided into two parts: the top
ity. When IDEF0 is used to represent the process model in a part contains the primary key attributes; the lower one the
functional architecture, mechanisms are not needed; they are nonprimary key attributes. Every attribute must have a
part of the physical architecture. name (expressed as a noun or noun phrase) that is unique
Verbs or verb phrases are inscribed in the activity boxes to among all attributes across the entities in the model. The at-
define the function represented. Similarly, arc inscriptions tributes take values from their specified domains.
Relationships between entities are depicted in the form of
lines that connect entities; a verb or verb phrase is placed
Controls beside the relationship line. The connection relationship is di-
rected—it establishes a parent–child association—and has
cardinality. Special symbols are used at the ends of the lines
Inputs Outputs to indicate the cardinality. The relationships can be classified
into types such as identifying or non-identifying, specific and
A0
nonspecific, and categorization relationships. The latter, for
example, is a generalization/specialization relationship in
Mechanisms
which an attribute of the generic entity is used as the discrim-
Figure 3. Box and arrow semantics in IDEF0. inator for the categories.
318 SYSTEMS ARCHITECTURE

Rule Model The process of developing a consistent and comprehensive

dictionary provides the best opportunity for ensuring concor-
In a rule oriented model, knowledge about the behavior of the
dance among the four models. Since each model has a differ-
architecture is represented by a set of assertions that describe
ent root and was developed to serve a different purpose, to-
what is to be done when a set of conditions evaluates as true.
gether they do not constitute a well integrated set. Rather,
These assertions, or rules, apply to specific functions defined
they can be seen as a suite of tools that collectively depict
in the activity model and are formulated as relationships
sufficient information to specify the architecture. The inter-
among data elements. There are several specification methods
relationships among models are complex. For example, rules
that are used depending on the application. They include de-
should be associated with the functions at the leaves of the
cision trees, decision tables, structured english, and mathe-
functional decomposition tree. This implies that, if changes
matical logic. Each one has advantages and disadvantages; are made in the IDEF0 diagram, then the rule model should
the choice often depends on the way that knowledge about be examined to determine whether rules should be reallo-
rules has been elicited and on the complexity of the rules cated and whether they need to be restructured to reflect the
themselves. availability of data in the revised activity model. A further
implication is that the four models cannot be developed in
Dynamics Model sequence. Rather, the development of all four should be
planned at the beginning with ample opportunity provided for
The fourth type of model that is needed is one that character-
iteration, because if changes are made in one, they need to be
izes the dynamic behavior of the architecture. This is not an
reflected in the other models.
executable model, but one that shows the transition of the
Once concordance of these models has been achieved, it is
system state as a result of events that take place. The state
possible to construct an executable model. Since the physical
of a system can be defined as all the information that is
architecture has not been constructed yet, the executable
needed at some time to so that knowledge of the system and
model can only be used to address logical and behavioral is-
its inputs from that time on determines the outputs. The sues, but not performance issues.
state space is the set of all possible values that the state can
take.
There is a wide variety of tools for depicting the dynamics, The Executable Model
with some tools being more formal than others: state transi- Colored petri nets (17) are an example of a mathematically
tion diagrams, state charts, event traces, key threads, and rigorous approach but with a graphical interface designed to
so on. Each one serves a particular purpose and has unique represent and analyze discrete event dynamical systems.
advantages. For example, a state transition diagram is a rep- They can be used directly to model an architecture. The prob-
resentation of a sequence of transitions from one state to an- lem, however, is to derive a dynamic representation of the
other—as a result of the occurrence of a set of events—when system from the four static representations.
starting from a particular initial state or condition. The states The solution to this problem using the structured analysis
are represented by nodes (e.g., a box) while the transitions models can be described as follows. One starts with the activ-
are shown as directed arcs. The event that causes the transi- ity model. Each IDEF0 activity is converted into a petri net
tion is shown as an arc annotation, while the name of the transition; each IDEF0 arrow connecting two boxes is re-
state is inscribed in the node symbol. If an action is associated placed by an arc-place-arc construct, and the label of the
with the change of state, then this is shown on the connecting IDEF0 arc becomes the color set associated with the place. All
arc, next to the event. Often, the conditions that must be sat- these derived names of color sets are gathered in the global
isfied in order for a transition to occur are shown on the arcs. declaration node of the petri net. From this point on, a sub-
This is an alternative approach for documenting the rule stantial modeling effort is required to make the colored petri
model. net model a dynamic representation of the system. The infor-
mation contained in the data model is used to specify the color
System Dictionary and Concordance of Models sets and their respective domains, while the rules in the rule
model result in arc inscriptions, guard functions, and code
Underlying all these four models is the system dictionary. segments.
Since the individual models contain overlapping information, The executable model becomes the integrator of all the in-
it becomes necessary to integrate the dictionaries developed formation; its ability to execute tests some of the logic of the
for each one of them. Such a dictionary must contain descrip- model. Given the colored petri net model, a number of analyti-
tions of all the functions or activities including what inputs cal tools from petri net theory can be used to evaluate the
they require and what outputs they produce. These functions structure of the model, for example, to determine the presence
appear in the activity model (IDEF0), the rule model (as ac- of deadlocks, or obtain its occurrence graph. The occurrence
tions), and the state transition diagrams. The rules, in turn, graph represents a generalization of the state transition dia-
are associated with activities; they specify the conditions that gram model. By obtaining the occurrence graph of the petri
must hold for the activity to take place. For the conditions to net model, which depicts the sequence of states that can be
be evaluated, the corresponding data must be available at the reached from an initial marking (state) with feasible firing
specific activity—there must be an input or control in the sequences, one has obtained a representation of a set of state
IDEF0 diagram that makes that data available to the corre- transition diagrams. This can be thought as a first step in the
sponding activity. Of course, the system dictionary contains validation of the model at the behavioral level. Of course, the
definitions of all the data elements as well as the data flows model can be executed to check its logical consistency, that is,
that appear in the activity model. to check whether the functions are executed in the appro-
 SYSTEMS ARCHITECTURE 319

priate sequence and that the data needed by each function Performance Evaluation
are appropriately provided. Performance measures cannot be
The executable model can be used both at the logical and be-
obtained until the physical architecture is introduced; it pro-
havioral level as well as the performance level. The latter re-
vides the information needed to compute performance mea-
quires the inclusion of the physical architecture. In one con-
sures.
sistent architectural framework supported by a set of models,
both requirement analysis, design, and evaluation can be per-
Physical Architecture formed. Furthermore, the process provides a documented set
To complete the analysis phase of the procedure, the physical of models that collectively contain all the necessary informa-
architecture needs to be developed. There is no standardized tion. Note that any changes made during the construction of
way to represent the physical systems, existing ones as well the executable model must be fed back and shown in the
as planned ones that will be used to implement the architec- static models.
ture. They range from wiring diagrams of systems to block Measures of performance (MOP) are obtained either ana-
diagram representations to node models to organization lytically or by executing the model in simulation mode. For
charts. While there is not much difficulty in describing in a example, if deterministic or stochastic time delays are associ-
precise manner physical subsystems using the terminology ated with the various activities, it is possible to compute the
and notation of the particular domain (communication sys- overall delay or to obtain it through simulation. Depending
tems, computers, displays, data bases), a problem arises on on the questions to be answered, realistic scenarios of inputs
how to depict the human organization that is an integral part need to be defined that are consistent with the operational
of the information system. The humans in the organization concept. This phase allows for functional and performance re-
can not be thought simply as users; they are active partici- quirements to be validated, if the results obtained from the
pants in the workings of the information system and their simulations show that the measures of performance are
organizational structure that includes task allocations, au- within the required range. If not, the systems may need to be
thority, responsibility, reporting requirements, and so on, modified to address the issues that account for the encoun-
must be taken into account and be a part of the physical tered problems.
model description. This is an issue of current research, since However, the structured analysis approach is not very
traditional organizational models do not address explicitly the flexible; it cannot handle major changes that may occur dur-
need to include the human organization as part of the physi- ing the development and implementation process. An alterna-
cal system description. tive approach, that uses many of the same tools, has began to
be used in an exploratory manner.
Synthesis
Once the physical architecture is available, then the execut- OBJECT ORIENTED APPROACH
able model of the architecture shown in Fig. 1 can be ob-
tained. The process is described in Fig. 4 as the synthesis This approach allows for the graceful migration from one op-
phase. The required inter-relationship between the functional tion to another, in a rapid and low cost manner; it places em-
and the physical architectures is shown by the bold two-way phasis on system integration rather than on doing one-of-a-
arrow. It is critical that the granularity of the two architec- kind designs.
tures be comparable and that the partitions in the hierarchi- The fundamental notion in object oriented design is that of
cal decompositions allows functions or activities to be as- an object, an abstraction that captures a set of variables
signed unambiguously to resources and vice versa. Once the which correspond to actual real world behavior (18). The
parameter values and properties of the physical systems have boundary of the object that hides the inner workings of the
become part of the data base of the executable model, perfor- object from other objects is clearly defined. Interactions be-
mance evaluation can take place. tween objects occur only at the boundary through the clearly
stated relationships with the other objects. The selection of
objects is domain specific.
A class is a template, description, or pattern for a group of
Operation
very similar objects, namely, objects that have similar attri-
concept butes, common behavior, common semantics, and common re-
lationship to other objects. In that sense, an object is an in-
stance of a class. For example, ‘‘air traffic controller’’ is an
Functional Physical object class; the specific individual that controls air traffic
architecture architecture during a particular shift at an Air Traffic Control center is an
object—an instantiation of the abstraction ‘‘air traffic control-
ler.’’ The concept of object class is particularly relevant in the
design of information systems, where it is possible to have
Dynamics
hardware, software, or humans perform some tasks. At the
model higher levels of abstraction, it is not necessary to specify
Executable
model whether some tasks will be performed by humans or by soft-
ware running on a particular platform.
Figure 4. The synthesis phase. The executable model is obtained by Encapsulation is the process of separating the external as-
assigning resources to functions and using the dynamics model to pects of an object from the internal ones; in engineering
specify behavior. terms, this is defining the boundary and the interactions that
320 SYSTEMS ARCHITECTURE

cross the boundary—the black-box paradigm. This is a very tions or transformations of the class that can be applied to
natural concept in information system design; it allows the the class or by it.
separation of the internal processes from the interactions The lines connecting the object classes represent relation-
with other objects, either directly or through communication ships. These relationships have cardinality (one to one, one to
systems. many, etc.). In addition to the generalization and inheritance
Modularity is another key concept that has a direct, intu- relationships, the lines also represent associations: they show
itive meaning. Modularity, according to Booch (19) is the how one class accesses the attributes or invokes the opera-
property of a system that has been decomposed into a set of tions of another.
cohesive and loosely coupled modules. Consider, for example,
the corporate staff, the line organization, and the marketing The Functional View
organization of a company. Each module consists of objects
and their interactions; the assumption here is that the objects The functional view consists of a set of data flow diagrams
within a module have a higher level of interaction than there that are analogous to the activity models in structured analy-
is across the modules. sis. A data flow diagram, as used in the object modeling tech-
In the context of object oriented design, hierarchy refers to nique, depicts the functional relationships of the values com-
the ranking or ordering of abstractions, with the more general puted by the system; it specifies the meaning of the
one at the top and the most specific one at the bottom. An operations defined in the object model without indicating
ordering is induced by a relation and the ordering can be where these operations reside or how they are implemented.
strict or partial. In the object oriented paradigm, two types of The functions or operations or transformations, as they are
ordering relations are recognized: aggregation and inheri- often called, are depicted by ovals with the name of the trans-
tance. Aggregation refers to the ability to create objects com- formation inscribed in them, preferably as a verb phrase. The
posed of other objects, each part of the aggregate object. The directed arcs connecting transformations represent data
concept of aggregation provides the means of incorporating flows; the arc inscriptions define what flows between the
functional decompositions from structured analysis in the ob- transformations. Flows can converge (join) and diverge
ject oriented approach. (branch). A unique feature of data flow diagrams is the inclu-
Inheritance is the means by which an object acquires char- sion of data stores which represent data at rest—a data base
acteristics (attributes, behaviors, semantics, and relation- or a buffer. Stores are connected by data flows to transforma-
ships) from one or more other objects (20). In single inheri- tions with an arc from a store to a transformation denoting
tance, an object inherits characteristics from only one other that the data in the store is accessible to the transformation,
object; in multiple inheritance, from more than one object. In- while an arc from a transformation to a store indicates an
heritance is a way of representing generalization and special- operation (write, update, delete) on the data contained by the
ization. The navigator in an air crew inherits all the attri- store. Entities that are external to the system, but with which
butes of the air crew member object class, but has additional the system interacts, are called terminators or actors. The
attributes that specialize the object class. The pilot and the arcs connecting the actors to the transformations in the data
copilot are different siblings of the air crew object class. flow diagram represent the interfaces of the system with the
The object modeling technique (OMT) of Rumbaugh et al. external world. Clearly, data flow diagrams can be decom-
(21) requires three views of the system: the object view, the posed hierarchically, in the same manner that the IDEF0 dia-
functional view, and the dynamic view. The object view is rep- gram was multileveled.
resented by the object model that describes the structure of While data flow diagrams have many strengths such as
the system—it is a static description of the objects and it simplicity of representation, ease of use, hierarchical decom-
shows the various object classes and their hierarchical rela- position, and the use of stores and actors, they also have
tionships. The functional view is represented in terms of data weaknesses. The most important one is the inability to show
flow diagrams, an alternative to IDEF0, that depict the de- the flow of control. For this reason, enhancements exist that
pendencies between input data and computed values in the include the flow of control, but at the cost of reducing the
system. The dynamic view is represented in terms of state clarity and simplicity of the approach.
transition diagrams. While these three views are adequate for
object oriented software system design, they are not sufficient The Dynamics View
to represent an architecture and answer user’s questions. As
in the structured analysis approach, an executable model is The dynamics view in OMT is similar to the one in structured
needed to bring them all together and to provide a means for analysis—state transition diagrams are used to show how
performance evaluation. events change the state of the system. The rules that govern
the operations of the system are not shown as an independent
model, but are integrated in the dynamics model.
The Object View
A final construct that describes the trajectories of the sys-
The object view presents the static structure of the object tem using events and objects is the event trace. In this dia-
classes and their relationships. The object view is a diagram gram, each object in the object view is depicted as a vertical
that is similar to the data model, but in place of the data line and each event as a directed line from one object to an-
entities there are object classes. An object class is depicted by other. The sequencing of the events is depicted from top to
a box divided into three parts: the top part contains the name bottom, with the initiating event as the topmost one. The
of the class; the second part contains the attributes (they are event traces characterize behaviors of the architecture; if
the data values held by all the objects in the class); and the given, they provide behavioral requirements; if obtained from
third part contains the class operations. These are the func- the executable model, they indicate behavior.
 SYSTEMS ARCHITECTURE 321

The Executable Model one requires that a library of object classes be defined and
implemented prior to the actual design. If this is a new do-
The three views, when enhanced by the rule model embedded
main, there may not exist prior libraries populated with suit-
in the state transition diagrams, provide sufficient informa-
able object classes; they may have to be defined. Of course,
tion for the generation of an executable model. Colored petri
with time, more object class implementations will become
nets can be used to implement the executable model, although
available, but at this time, the start-up cost is not insignifi-
the procedure this time is not based on the functional model.
cant. On the other hand, if the requirements are expected to
Instead, the object classes are represented by subnets that
change and new technology insertions are anticipated, it may
are contained in ‘‘pages’’ of the hierarchical colored petri net.
be more effective to create the class library in order to avail
These pages have port nodes for connecting the object classes
the systems engineering team with the requisite flexibility in
with other classes. Data read through those ports can in-
modifying the system architecture.
stantiate a particular class to a specific object. The operations
of the pages/object subnets are activated in accordance with
the rules and, again, the marking of the net denotes the state BIBLIOGRAPHY
of the system.
Once the colored petri net is obtained, the evaluation 1. E. Rechtin, Architecting Information Systems, Englewood Cliffs,
phase is identical to that of structured analysis. The same NJ: Prentice-Hall, 1991.
analytical tools (invariants, deadlocks, occurrence graphs) 2. E. Rechtin and M. Maier, The Art of Systems Architecting, Boca
and the same simulations can be run to assess the perfor- Raton, FL: CRC Press, 1996.
mance of the architecture. 3. E. Rechtin, The art of systems architecting, IEEE Spectrum., 29
(10): 66–69, 1992.
UML 4. E. Rechtin, Foundations of systems architecting, J. NCOSE, 1:
35–42, 1992.
More recently, the Unified Modeling Language (UML) has 5. D. N. Chorafas, Systems Architecture and Systems Design, New
been put forward as a standard modeling language for object- York: McGraw-Hill, 1989.
oriented software systems engineering (22). The language in- 6. A. P. Sage, Systems Engineering, New York: Wiley, 1992.
corporates many of the best practices of industry. What is 7. A. H. Levis, Lecture notes on architecting information systems,
particularly relevant to its future extension beyond software Rep. GMU/C3I-165-R, Fairfax, VA: C3I Center, George Mason
systems-to-systems engineering is the inclusion of a large Univ.
number of diagrams or views of the architecture. It includes 8. D. A. Marca and C. L. McGowan, Structured Analysis and Design
use cases which describe the interaction of the user with the Technique, New York: McGraw-Hill, 1987.
system, class diagrams that correspond to the object view in 9. E. Yourdon and L. Constantine, Structured Design, New York:
OMT, interaction diagrams which describe the behavior of a Yourdon Press, 1975.
use case, package diagrams which are class diagrams that 10. P. Ward and S. Mellor, Structured Development of Real-time Sys-
depict the dependencies between groups of classes, and state tems, New York: Yourdon Press, 1986.
transition diagrams. The proposed standardization may pro- 11. T. DeMarco, Structured Analysis and Systems Specification, En-
vide the necessary impetus for developing system architec- glewood Cliffs, NJ: Prentice-Hall, 1979.
tures using object-oriented methods. 12. C. Gane and T. Sarson, Structured Systems Analysis: Tools and
Techniques, Englewood Cliffs, NJ: Prentice-Hall, 1978.
13. A. Solvberg and D. C. Kung, Information Systems Engineering,
SUMMARY New York: Springer-Verlag, 1993.
14. G. L. Sanders, Data Modeling, Danvers, MA: Boyd & Fraser,
The problem of developing system architectures, particularly 1995.
for information systems, has been discussed. Two main ap- 15. E. Yourdon, Modern Structured Analysis, Englewood Cliffs, NJ:
proaches, the structured analysis one with roots in systems Yourdon Press, 1989.
engineering, and the object oriented one with roots in soft- 16. R. McLeod, Jr., Systems Analysis and Design, Fort Worth, TX:
ware system engineering, have been described. Both of them Dryden, 1994.
are shown to lead to an executable model, if a coherent set of 17. K. Jensen, Coloured Petri Nets, New York: Springer-Verlag, 1992.
models or views is used. The executable model, whether ob- 18. A. P. Sage, Object oriented methodologies in decision and infor-
tained from the structured analysis approach or the object mation technologies, IEEE Trans. Syst., Man, Cybern., SMC-19:
oriented one should exhibit the same behavior and lead to 31–54, 1993.
the same performance measures. This does not imply that the 19. G. Booch, Object-oriented Analysis and Design, Redwood City, CA:
structure of the colored petri net will be the same. Indeed, the Benjamin/Cummings, 1994.
one obtained from structured analysis has a strong structural 20. E. V. Berard, Essays on Object-oriented Software Engineering, En-
resemblance to the IDEF0 (functional) diagram, while the one glewood Cliffs, NJ: Prentice-Hall, 1993.
obtained from the object oriented approach has a structure 21. J. Rumbaugh et al., Object-oriented Modeling and Design, Engle-
similar to the object view. The difference in the structure of wood Cliffs, NJ: Prentice-Hall, 1991.
the two models is the basis for the observations that the two 22. M. Fowler and K. Scott, UML Distilled, Reading, MA: Addison-
approaches are significantly different in effectiveness de- Wesley, 1997.
pending on the nature of the problem being addressed. When
the requirements are well defined and stable, the structured ALEXANDER H. LEVIS
analysis approach is direct and efficient. The object oriented George Mason University

View publication stats