Architecture Analysis in Software Factories
Sandeep Neema

Jason Scott

Gabor Karsai

Vanderbilt University/ISIS
P.O. Box 351829
Nashville, TN 37235, USA+1 615 343 7472

Vanderbilt University/ISIS
P.O. Box 351829
Nashville, TN 37235, USA+1 615 343 7472

Vanderbilt University/ISIS
P.O. Box 351829
Nashville, TN 37235, USA+1 615 343 7472

sandeep.k.neema@vanderbilt.edu

jscott@isis.vanderbilt.edu

gabor.karsai@vanderbilt.edu

ABSTRACTIn this paper, we argue for the incorporation of architecture
analysis techniques in Software Factories. While software
factories often rely on a domain-specific (or product-line specific)
architecture, frequently there are some architectural alternatives
left open. In these situations, architectural analysis, static ordynamic is essential. The paper elaborates these concepts andshows an example from the domain of avionics systems how thiscan be accomplished.

Categories and Subject Descriptors
D.2.2 [Design Tools and Techniques]: Computer-aided software
engineering, Object-oriented design methods

General Terms
Design, Performance.

Keywords
Model-integrated Computing, Software Factories.

1. INTRODUCTION
Software Factories configure tools, processes, and content forbuilding software product lines [1]. Often, the product lines arebuilt using a reference architecture that is instantiated in different
ways in specific products. The reference architecture may rely on
a number of common architectural patterns (e.g.
publish/subscribe, etc.), or it could be based on a very strict
framework for component composition. In any case, there could
be architectural decisions that are made by the designers (i.e. the“operators” of the factory) and that ultimately effect thefunctional and non-functional properties of the product. For
instance, allocating components in a different way or relying on
proxy techniques for local data distribution in real-time embedded
systems can greatly influence the end-to-end latency in avionics
systems.

large (has, let us say, >1K components), it is very difficult topredict whether the resulting system satisfies expectations or not.
We argue that it is essential to incorporate analytical techniques insoftware factories to assist with the architectural decisions. We
assume that the components one uses in the factory are notnecessarily available, but at least some approximations of theirrelevant properties are known (e.g. worst-case execution time).
Given these assumptions, architectural analysis tools could be
used to validate architectural decisions.
In this paper we introduce an illustrative example from thedomain of distributed (soft) real-time systems. The problem wasto determine some non-functional properties of a particularinstance of a domain-architecture. We have developed: (1) adomain-specific design modeling language for capturing thevariability in the domain architecture, (2) a modeling language for
capturing the analytical model of a given execution platform, (3)a translator from the design language into the analysis language,(4) the simulation components that approximated the behavior ofcomponents and the execution platform, (5) a dynamic analysis
framework that allowed quantity studies via using a discrete-event
system simulator. We were able to show the impact ofarchitectural decisions using this tool, in a quantitative manner.
We were using our metaprogrammable tools from our work on
Model-Integrated Computing [2].
The approach as presented here makes key contributions to thefollowing focal points of Software Factories research:
1)

Verification and Validation: The paper demonstrates ananalytical technique to help assess architectural compliancewith system requirements. The architecture of the system is
described with a domain specific modeling language thatincorporates the architectural invariants in the form of wellformedness constraints as well as in the form oftransformations that capture the dynamic operations
semantics of the architecture.

2)

Automatic Configuration, Code Generation, and Model
Transformation: The paper also demonstrates the use ofmodel transformations for derivation of analysis models
from the architecture models. A technique based on graphrewriting has been employed for specifying modeltransformations, which is formal in addition to being
efficient and scalable.

3)

Product line element verification: The techniquesdemonstrated in the paper can be used to address questions
highly relevant to the users of software factories. For
instance: “If we include certain features in a particular

The difficulty is that the impact of architectural decisions could
be hard to determine at design time. Especially, if the system is
Permission to make digital or hard copies of all or part of this work forpersonal or classroom use is granted without fee provided that copies are
not made or distributed for profit or commercial advantage and that
copies bear this notice and the full citation on the first page. To copy
otherwise, or republish, to post on servers or to redistribute to lists,requires prior specific permission and/or a fee.
OOPSLA Workshop Software factories, 2005, October 16, 2005, San
Diego, CA, USA.

instance application (i.e. product line element), will thesystem exhibit the right performance or not?”We also note that the general approach of deriving analysis
models from design models using a transformation is applicablebeyond the realm of distributed real-time embedded systems,
including information systems. Moreover, the analyticalformalism of Discrete Event Systems is very general and has been
employed in modeling and simulation of a large variety ofcomplex systems [9].

2. CHALLENGE PROBLEM
Real-time Operating Systems based on the ARINC 653
specification, are rapidly becoming the operating platform of
choice for safety critical real-time avionics applications [7]. The
focal point of the specification is robust partitioning – amechanism for strong isolation of applications, both in time
(temporal partitioning) and in space (memory partitioning), forassuring a high degree of fault containment, ease of verification,
validation, and certification. A robustly partitioned system allows
partitions (or application software) with different criticality levels
to execute on the same processor core without affecting eachother spatially or temporally.
Partitions are scheduled on a fixed-cycle basis, with a major timeframe that is repeated throughout the runtime. Within the major
time frame each partition may be allocated one or more windows– defined by offset from start of major time frame, and duration.
Thus each partition is assured dedicated and uninterrupted1 accessto execution resources during its execution window. The static
schedule must be designed by taking into account periodic
computational requirements of each partition. Please note thatwithin each partition multiple processes may execute concurrently
and are governed by a priority-based preemptive schedulingscheme that is local to the partition, and sharing resources that areallocated to the partition. Similar to temporal windowing,predetermined areas of memory are allocated to partitions, with at
most one partition having write access to any particular area ofmemory.
One of the challenges in systems implemented atop an ARINC
653 compliant RTOS is in inter-partition communication. For thereasons of isolation, and fault containment, the specification does
not allow any direct/memory-mapped communication acrosspartitions. The inter-partition communication must be done using
the ARINC 653 communication services, and the actual
communication is performed by an I/O service which executes asa system partition governed by the overall partition scheduling.
The direct implication of this requirement is that the static
partition schedule, an architectural decision, has a significant
impact on the communication latencies. We present a small subset
of an avionics application as a challenge problem2 that illustrates
this concern, and demonstrates the value of an analytical approachin understanding and addressing this concern.

1

Bus-acknowledgements and time-outs may interrupt one
partition’s execution even though the events relate to a different
partition. We note this here since it affects the analysis.

2

The authors thank Northrop Grumman and USC for the avionics
problem cited here.

Consider an avionics system that consists of a number ofsubsystems. Each subsystem is implemented as a separate ARINC
653 partition. The avionics system has a number of sporadic
events that need to be processed. A key design objective is toestablish an upper bound on the arrival rate of such events. The
particular event processing scenario is to process New Page
request events from the Multi-Function Display (MFD). By menu
selection the pilot can request a different page from a particularfunctional unit to be shown on the display. The processing of therequest involves several subsystems: the MFD display hardware,
the DisplayManager (DM) subsystem, the PageContentManager(PCM) subsystem, the FlightManager (FM) subsystem, and the
FlightDirector (FD) subsystem.

Figure 1: System Latency Flow
The maximum arrival rate of the New Page request is bounded by
the minimum latency between the time the pilot selects the menu
item to request the page and the time the new page has been
displayed. The minimum latency is determined by the amount oftime it takes to process the flow of the page request including thedisplay of the new page. The lower bound of this processing
latency is determined by the fact that subsystems execute as
separate partitions and that inter-partition communication incurs apartition offset delay as well as frame delays at the partition
execution rate.

3. TOOL CHAIN
Analogous to manufacturing assembly lines, a software factoryneeds to be configured to support a particular software productline. Configuration involves customizing meta-programmabletools and integrating them in “tool chains” to support the design
process for a particular software product line. A tool chain is an
integrated suite of tools, where the integration is accomplished byproviding automated transformations from the output of a tool to
input of another tool. In prior research at ISIS we have developed
a meta-programmable integration framework, labeled Open Tool
Integration Framework or OTIF that facilitates creation anddeployment of tool chains (see [10] for details). Utilizing thisinfrastructure, we have set up a tool chain to support design,
analysis, and synthesis of the class of systems described above.
Figure 2 shows a logical architecture and design flow in the
toolchain. The details of the tools and transformations areprovided below.

3.1 Design ModelingIn this section we briefly describe Avionics Systems Modeling
Language (AvSML), a multi-aspect Domain-Specific Modeling
Language that supports modeling of component based Avionics
applications architected to be deployed on an ARINC 653
compliant RTOS. This language has been instantiated in the metaprogrammable GME tool, resulting in a domain-specific modelingenvironment that can be used by System Integrators andDesigners to model avionic systems.

feedback

tra
ns
f

or
m
at
io

transformation

Analysis/
Simulation
Engine(ADEVS)

Analysis
ModelsAvSMLModeling(GME)nConfiguration
ModelsBuild/
DeploySystemThe Component Interaction Modeling sub-language of AvSML
allows composing systems by instantiating components, anddefining their interactions (we refrain from detailing themetamodel in the interest of brevity). The interaction semantics
are defined by the type of Component Connectors participating in
an interaction. Two types of interaction mechanisms aresupported: a) Sampled interaction, and b) Queued interaction. The
sampled interaction implies a form of asynchrony in which thesource component produces output on its connector which stays
persistent till a new value is written. The destination component
samples the connector and reads the most recent value. The
queued interaction on the other hand implies a loose form ofsynchrony in which output of the source component is queued till
it is consumed by the destination component. Please note that his
particular choice of interaction semantics is driven by theplatform. The ARINC 653 specification supports these two typesof inter-partition interaction mechanisms, and the challenge
problem requires implementing components (subsystem) in
individual partitions, thereby constraining the interaction
semantics. One may argue here for the need for platform
independence in the DSML; however we note that the ARINC
653 specification influences the domain architecture, which inturn dictates the DSML.

Figure 2: Tool Chain
The key modeling concepts of AvSML can be summarized into
following categories:
1.
2.
3.
4.

Component (Subsystem) Modeling
Component Interaction Modeling
ARINC 653 Platform Modeling
Deployment Modeling

Figure 3 shows a (partial) metamodel of Component Modeling
sub-language of AvSML. Components are defined by modelingtheir interfaces (Connector)3, and their internal behavior. Theinternal behavior of a component is modeled by defining aworkflow (data and control flow) that includes Connectors,
PrimitiveFunction and [Compound]Functions, and Statevariables. This in effect captures the internal processing flow of
the component, from when data/event arrives to a Connector, tillwhen results are sent to a Connector. The workflow language (notshown in the figure below) is intentionally not Turing complete
for reasons of analyzability. Please note that the internal
behaviors of the PrimitiveFunctions can be implemented in a
Turing complete programming language, however the models
abstract out those details with a data interface (DataInput,
DataOutput), and a characterization with respect to execution
properties. The execution property characterization allows
modeling the execution time in the form of a statistical
distribution, and parameters specific to the distribution, forexample the mean (μ) and variance (σ) in case of a Gaussian
distribution.

3

The little curved arrow at the bottom of the class icon, indicatesa proxy to a class that has been defined in a different paradigm
sheet (class diagram).

Figure 3: Component (Subsystem) Modeling
Figure 4 shows a metamodel of the Platform and Deployment
Modeling sub-language of AvSML. This sub-language includes
concepts to model the Partitions, time slots or Windows assigned
to a partition, InterPartition, and IntraPartition communication
ports, and inter-partition communication Channels. The
deployment of application components or subsystems is modeledwith SubsystemRef , which refers to a Subsystem. For reasons offault-tolerance the deployment modeling also allows specifying
backup deployments i.e. in addition to the primary deployment, acomponent is also deployed in a different partition/processor as a
backup (SubsystemBackup) where it stays inactive till a fault
causes the primary deployment to fail. The sub-language allows

associating partitions with ComputationalUnits which represent
processing resources.
In summary, AvSML allows representation and characterizationof a component-based Avionics application architected inaccordance with ARINC 653 specification.

3.2 Analysis Models
As illustrated in the challenge problem, our analysis objectives
are to establish non-functional properties such as end-to-end
latency, resource utilization etc. Experience indicates that static
analysis techniques such as RMA fails to adequately address theanalysis needs of class of systems represented by the challenge
problem, due to both an overly conservative approximation withworst-case execution time, as well as inability to incorporate data
dependencies. This motivates the need for dynamic analysis
techniques based on Simulation. Discrete Event Simulators withthe ability to program the event processing behaviors ofsimulation components have been utilized in a variety of
performance analyses [9].

section we describe the input language of this tool, which defines
the analysis model. Figure 5 shows a (partial) metamodel of theanalysis model. As can be expected the analysis metamodel
abstracts away some of the details of the software engineering
artifacts, but explicates the details of all computation activities
that consume processing resource, all communication activities
that consume bandwidth, and the workflow across these.
The key concepts here can be summarized as follows. A Partition
represents allocation of processing resources, and can beassociated with a ProcessorElement with more than one Window,
characterized with a Duration, and Offset. A Function represents
processing activities, and the processing time requirements arecharacterized as a statistical distribution (DistFunc), and a set ofparameters specific to the distribution (Mean, Min, Max, Mode,
StdDev). Please note here that the Function construct captures,processing activities in general, whether it is processing activity
in application (see Component Functions in AvSML), or
processing activity in the platform services which are notexplicitly represented in the design models but are incorporated
via the design model to analysis model transformation. The
DataElement construct facilitates specification of communication,and is associated with a NetworkElement (not visible in the
figure). Please note that the ARINC 653 inter-partition
communication of necessity involve a memory copy, and may
often take place across a bus. The Functions produce or consume
DataElements in the workflow.

Figure 5: Analysis Metamodel
Next, we briefly describe the derivation of analysis models fromdesign models as expressed in a transformation that we havedeveloped. Some elements of the mapping are one-to-one andfairly straightforward:-

Figure 4: Platform and Deployment Modeling
We utilize one such DES based performance simulation tool thathas been developed at ISIS in another research. In the rest of thisComputationUnit in AvSML maps to ProcessorElement
Partition, Windows and their association with
ComputationUnit in AvSML maps to Partition and its
association with a ProcessorElement through a Window.
Note here that the syntactic representation of theseconcepts differs in AvSML and the Analysis
metamodel, for obvious reasons of user convenience(relevant to AvSML) vs. conciseness (relevant toAnalysis metamodel).

The component workflow in AvSML maps analogously, however,some elaboration is performed during mapping. The elaboration
happens at the communication endpoints. A Function is inserted
to incorporate the processing overhead of the platform API, as
well as a DataElement is introduced to capture thecommunication resource requirements.

3.3 Analysis Engine and Component Models
Prior to describing the analysis engine and simulation
components, it is worthwhile to note here that the analysis (orsimulation) engine is responsible for operationalization of theanalysis metamodel described above. Thus, from a language
viewpoint, one can consider the description of the simulation
components as defining the operational semantics of the analysis
metamodel.
Our simulation engine is built atop ADEVS, a public domain
discrete event simulator developed at University of Arizona [8].
ADEVS is implemented as a C++ library that supports theconstruction of discrete event models based on the Parallel DEVS
formalism [9]. While the details of the DEVS formalism areclearly outside the scope of this paper, it can be summarized as acollection of concurrently interacting components, the dynamic
behavior of which is defined in terms of events. Thus, each DEVS
component implements an event-driven reactive behavior.
ADEVS designates such components as ‘atomic’ components.
The behavior of an atomic component is defined by its statetransition function, its output function, and its time advancefunction. The interface for these behaviors is defined in an
abstract base class labeled ‘atomic’. All simulation components
derive from atomic and provide implementation for the behaviors
listed above. In addition to reactive components, ADEVS also
allows modeling passive components that represent data or
tokens.
The behavior of some key simulation components can besummarized as follows:
Function – The function simulation components has three internal
states: Idle, InvokedWaiting, InvokedProcessing. The Function
can receive three types of events: recv_control, proc_req_grant,
proc_grant_cancel, and can generate three types of events:
relinquish_control, proc_req, proc_req_done. Additionally, it also
handles timer events (time advance behavior) from the simulator.
Initially, a Function is in an Idle state, and is waiting to receive
control, which can be passed from a prior element in theworkflow (routed by the workflow engine), or from an external
generator (mimicking environmental or user stimuli). Once it
receives the ‘recv_control’ event it emits a ‘proc_req’ event andenters the ‘InvokedWaiting’ state. In the ‘InvokedWaiting’ state it
waits for a ‘proc_req_grant’ event. The processor request can be
granted depending on whether the partition to which the function
is mapped is currently sliced in. In case the ‘proc_req_grant’
event is received it transitions to the ‘InvokedProcessing’ andnotifies the ADEVS engine through the time advance interface ofthe required processing time. The ADEVS engine then notifies
back the Function when the required processing time is complete.
The Function then emits a ‘relinquish_control’ and a‘proc_req_done’ event and transitions to the ‘Idle’ state. It is also
possible that before the processing time of the Function has
expired, the Partition to which the Function is mapped can get
sliced out in which case the Function receives a‘proc_grant_cancel’ event. In response to this event the function
computes the remaining processing time, emits a ‘proc_req’ eventand transitions to ‘InvokedWaiting’ state.
Please note that the required processing time is computed basedon the statistical distribution that characterizes the execution timeof the function code. In our current implementation datadependent execution times can not be handled, however, an
extension is in progress which would allow characterizing thedata tokens with additional meta-data, and incorporating userdefined computation of processing time based on data token
characteristics.
Partition – The partition simulation components has three internal
states: SlicedIn, SlicedInProcessing, and SlicedOut. Partition
handles four types of input events: slice_in, slice_out, proc_req,
proc_req_done, and it generates two types of events:
proc_req_grant, proc_grant_cancel. Partition starts in a
‘SlicedOut’ state. On receiving a ‘slice_in’ event it transitions tothe ‘SlicedIn’ state. From the ‘SlicedIn’ state, in response to a‘proc_req’ event, it emits a ‘proc_req_grant’ event and transitions
to a ‘SlicedInProcessing’ state, and marks the Function that iscurrently active. From ‘SlicedInProcessing’, in response to a‘proc_req_done’ event it transitions to ‘SlicedIn’ state, while inresponse to a ‘slice_out’ event it emits a ‘proc_grant_cancel’
event and transitions to ‘SlicedOut’ state. From ‘SlicedIn’ state ittransitions to ‘SlicedOut’ state in response to ‘slice_out’ event.
Processor – The processor simulation component simply
implements a time slicing scheduler. It cycles through the list of
windows sorted by their start offset, sends a ‘slice_in’ event to therespective partition at the start of the window, notifies thesimulation engine to wake it up after the window duration, at
which point it sends a ‘slice_out’ event to the corresponding
partition. This cycling behavior is repeated for the entire durationof the simulation.
The result of the simulation is an event trace which captures thetiming of occurrence of each event. A secondary, Matlab-based
data-mining and post-processing tool bundled with the simulation
tool performs processing of the event traces to compute end-toend latency, communication buffers, and processor utilization.

4. RESULTS
The challenge problem briefly described in section 2 was
subjected to modeling and analysis using the tool chain that we
described above.
Figure 6 shows models of the challenge problem in AvSML. We
modeled each of the subsystems (MFD, DM, PCM, FM, and FD)
including their interfaces, and their internal workflows. Eachcomponent (except for MFD, and FD), have two input queued
ports and two output queued ports. A request that comes in to the
input port is processed by the workflow, and the results of theprocessing are dispatched via the output ports. For example theDM component has one input port through which it receives apage request, which it processes and dispatches via its output port
to the PCM component. The DM component has another input
port on which it receives NewPage, which it then processes anddispatches via another output port to the MFD component. The
MFD component has one output port through which it generates
page requests, and an input port through which it receives new
page. We characterized the execution time requirements of theprocessing functions based on our best understanding of thecomputational requirements of the system, as well as modulated
these requirements to derive interesting analytical observations.
We also modeled the interactions between these components as
described in the challenge problem. The components were
deployed on a single processor but were distributed acrossmultiple partitions i.e. one component was mapped to one
partition. The analysis question stated in the challenge problem
can be reformulated with respect to the models as: estimate thelatency between generation of an output on the PageRequest portof the MFD component, and arrival of an input on the NewPage
port of the MFD component. As we noted earlier that the partitionschedule can have significant impact on the latency, we
experimented with different partition schedules in the deployment
models to substantiate this hypothesis.
Component
Models
Deployment
Modelsearlier this type of routing is a consequence of the ARINC 653
specification that mandates that all inter-partition communications
are performed by an IO Process running in a system partition.
Please note that the design models do not capture these details,
and this routing is an example of automatic synthesis of theplatform details through the transformation. The partition
mapping view shows all the partitions mapped to a single
processor, and the connections between Partition/Processor
capture the windowing details such as offset, and duration.
These analysis models were generated from the AvSML modeland were subjected to another transformation, which is purely
syntactical in nature and as such we refrain from describing its
details. This transformation takes the analysis model andgenerates a textual configuration file that is sent to the ADEVS
engine which executes the simulation model, and generates anevent trace. A Matlab-based post-processing utility tool computes
end-to-end latency estimates by examining the timestamps of theevents corresponding to the generation of an event by the MFD
function into the data-element at its output port, andcorresponding to the receipt of an event into the data-element at
its input port.
In all of the partition scheduling configurations the major timeframe was 200 ms, and the simulation was run for 100 seconds(500 schedule cycles). The chart shown plot the latency on the yaxis, and the simulation time on x-axis.

Platform
ModelsFigure 6: AvSML Models of the Challenge Problem
Figure 7 shows the analysis models for the challenge problem,
derived automatically from AvSML models through a modeltransformation. Two views are shown: a) an aggregated workflow
including functions, and data elements, and b) a partitionwindow/processor mapping view. In the aggregated workflow theiconic objects with symbol φ are functions, whereas the othericonic objects represent data elements.

Figure 8 shows latency plots from our first partition schedulingconfiguration. This could be considered a most optimal (withrespect to latency) partition schedule. The partitions were timeordered according to their data dependencies, and an IO partition
was scheduled between every communicating partitions. Thus theentire roundtrip from the MFD to FD and back completes in twoschedule cycles, and the worst case latency is ~380 ms which isunder two scheduling cycle time (400 ms). The variances inlatencies are due to the statistical distribution of the execution
times.

MFD
FD
DM
PCM
FM
IO

0

Time (in ms)

200

Figure 8: End-to-End Latency Results (Configuration 1)

Figure 7: Analysis Model derived from AvSML Models
Data elements are characterized with the size requirement forcommunication. Please note the connection topology in this view.
All the outputs from a component go to a data element, whichgoes into an IOProcess, which then routes it to another data
element that goes into the input of a component. As we mentioned

Figure 9 shows the result from the second partition schedulingconfiguration. Here we chose a more realistic partition schedule
which allocates two windows to the IO process two windows to
the FD process (owing to its periodicity requirements), and one
window to each of the rest. The windows are not specificallyarranged to follow the data dependency order. The latency resultsin this configuration demonstrate a 4.5 cycle (~900 ms) round trip
delay. The histogram chart of latency also conveys a Gaussian
type of distribution which is what we chose for the execution
times of processing. The worst case latency in this configuration
is observed to be 5 cycle (~1000 ms).

of the scenarios/configurations posed. This is where arguments
are typically made for static analytical techniques since they are
not necessary subject to limitations of the tested scenarios.
Unfortunately, such techniques can not be applied to the type ofcomplex applications represented by the challenge problem
without gross approximations, and oversimplifications.

5. RELATED WORK
Typical Latency
WC Latency

20

30

20

30

20

30

20

30
200

Time (in ms)

0

MFD
FD
DM
PCM
FM
IO

Figure 9: End-to-End Latency Results (Configuration 2)
Figure 10 shows the latency results from our third partitionscheduling configuration. The scheduling configuration in thiscase is the same as the second configuration; however, we
experimented with the distribution of execution time. We
increased the variance in the execution time of the FD component.
Note that while this variance is artificial, this simulates a realscheduling jitter that is acknowledged in the specification as
mentioned in the footnote on page 1. Please note here that due tothe spread in the execution time of the FD component, it may notalways finish its execution in a single window, and the rest of theprocessing is finished in the next window allocated to the FDpartition. The consequence as can be understood from the latency
plots is a one cycle (200 ms) jitter. Since, the FM partition
follows the second window of IO partition, which in turn follows
the second window of the FD partition. If the execution of the FDpartition is completed in the second partition then the IO partitiontransfers the output to the FM partition in the same schedulingcycle. However, in case the execution of the FD partition does notcomplete in the second window, then it is postponed till the firstwindow of the next cycle. Thus the FM partition gets the result in
the next cycle instead of the same cycle which results in a 1 cycle
jitter.
High Variance in Flight Director ET (partition slice two windows spread) causes cycle delay

Architecture analysis is a well-known concept in the field, but
often it is restricted to static analysis to check architecturalcompliance [4]. As it is presented in the literature, it assumes theuse of an Architecture Description Language (ADL), withadditional tool support. We argue that for the Software Factory
world, the problem is better solved by using a two-level approach:namely using a (1) domain-specific modeling language for
capturing the design, and a (2) dedicated analysis modelinglanguage (with automatic transformation from the first to thesecond). The reason for this is that the design language could hideplatform-specific details that are irrelevant for the designer (andall these can be incorporated in the transformation), and thus
analysis language could be optimized for the analysis
environment/tool that is used.
Previous work has been done on modeling architectural dynamics
using Statecharts (see, e.g. [2]), and the importance of using
simulations has been pointed out in [5]. Here we propose
something different: the dynamic analysis of the entirearchitecture, with automatically generated analysis models. In thisrespect, our work is related to [6], but differs in using domainspecific design models (instead of UML).

6. CONCLUSIONS
We have illustrated how architectural analysis can be done in a
Software Factory setting, through an example worked out using
our MIC tools. We claim that analysis, especially quantitative
analysis should be part of a software factory in order to validate
architectural decisions in the design. Obviously, a number ofproperties could be checked using other techniques (e.g.
architectural compliance, interface compliance between
components, etc.) that we did not elaborate here, but must be
considered as well.
Note that early in the design component models could be very
approximate and the worth of architectural analysis could bequestioned. In this case, the approximate models may serve as thesource of requirements for component implementers, because if
the components are indeed built according to these expectations,
we have a high degree of confidence in the final product.

Latency 1
Latency 1 + cycle
MFD
FD
DM
PCM
FM
IO

20
0

30

20

30

20

Time (in ms)

30

20

20

30

30

200

Figure 10: End-to-End Latency Results (Configuration 3)
This type of jitter in latency may have significant consequences
depending on the nature of the application. The results shown
above highlight the ability of the simulation based performance
analysis in drawing such interesting observations. One caveat has
to be made: the quality of the results is dependent on the richness

Architectural analysis provides a number of research challenges.
The issues of scalability, performance modeling of software
components, the modeling of their dynamics, modeling of
platforms, are just a few examples. However, we believe answers
to these questions will lead to better software engineering
processes that allow us to build complex, large-scale systems thatwill work in real-life as they were expected to work in the designphase.

7. ACKNOWLEDGMENTS
The authors would like thank all government agencies (DARPA,
NSF, and NASA) and industrial partners (Boeing, Lockheed-Martin, and others) who provided support for the infrastructure
tools used in the effort described in this paper.

8. REFERENCES[1] J. Greenfield, and K. Short: Software Factories: Assembling
Applications with Patterns, Models, Frameworks, and Tools,
John Wiley, 2004.
[2] Karsai G., Agrawal A., Ledeczi A.: A Metamodel-Driven
MDA Process and its Tools, WISME, UML 2003
Conference, San Francisco, CA, October, 2003.
[3] A. Egyed, D. Wile: Statechart Simulator for ModelingArchitectural Dynamics, Proceedings of 2nd International
Working Conference on Software Architecture (WICSA),
Amsterdam, The Netherlands, August 2001.
[4] Abowd, Gregory, Robert Allen and David Garlan, "Using
Style to Understand Descriptions of Software Architecture,"
Proceedings of the First ACM SIGSOFT Symposium on theFoundations of Software Engineering (SIGSOFT'93), Los
Angeles, CA, 7-10 December 1993, in SIGSOFT Software

Engineering Notes, Vol. 18, No. 5, December 1993, pp. 920.
[5] Alexander Egyed: Dynamic Deployment of Executing and
Simulating Software Components, in Proceedings of the 2nd
IFIP/ACM Working Conference on Component Deployment(CD), Edinburgh, Scotland, UK, May 2004, pp. 113-128.
[6] T. Verdickt, B. Dhoedt, F. Gielen, P. Demeester: Automatic
Inclusion of Middleware Performance Attributes into
Architectural UML Software Models, IEEE Transactions on
Software Engineering, Aug. 2005, pp 695-711.
[7] ARINC 653 standard, www.arinc.com.
[8] ADEVS: http://www.ece.arizona.edu/~nutaro/index.php[9] Bernard P. Zeigler, Tag Gon Kim, Herbert Praehofer: Theoryof Modeling and Simulation, AP, 2000.
[10] Karsai, G., Lang, A., Neema, S.: Design Patterns for Open
Tool Integration, Vol 4. No1, DOI: 10.1007/s10270-0040073-y, Journal of Software and System Modeling, 2004.