Applying a Model-based Approach for Embedded

System Development
Christian Bunse Hans-Gerhard Gross Christian Peper
International University Software Engineering Research Group Fraunhofer Institute
in Germany Delft University of Technology Experimental Software Engineering
Campus 2 / School of IT Mekelweg 4, 2628 CD Delft, Fraunhofer-Platz 1,
76646 Bruchsal, Germany The Netherlands 67663 Kaiserslautern, Germany
Email: [email protected] Email: [email protected] Email: [email protected]

Abstract—Model-based and component-oriented software de- pitfalls of modern, complex embedded systems, and often they
velopment approaches are slowly superseding traditional ways only approach the problems from their individual perspectives.
of developing embedded systems. For investigating to which What is really lacking is a vehicle to transport the recent
extent model-based development is feasible for embedded system
development, we conducted a case study in which a small advances in software engineering and component technologies
embedded system is developed using the MARMOT approach. In into the embedded world in a way that engineers of the three
order to evaluate the degree of reuse that might be achieved, the disciplines can actually communicate and understand each
components of the case study are used in the context of different other.
small projects. Several aspects of reuse, application size, ease of This paper introduces the MARMOT development method
adaptation, and development effort are quantified. This analysis
reveals that model-based and component-oriented development [4] for mastering multi-disciplinary (involving mechanical,
performs well for small embedded systems, and it leads to the electronic and software engineering) embedded systems de-
conclusion that model-driven/component-based development of velopment. It provides templates, models and guidelines for
embedded systems enables adaptable applications with higher- the products describing a (software) system, and how these
than-normal reuse rate. artifacts are built up throughout the development process.
We introduce a case study in which we apply MARMOT
I. I NTRODUCTION
to the development, adaptation and reuse of components in
The main motivation for applying model-driven and the context of a control system for a car’s exterior mirror.
component-based engineering techniques is that new applica- We validated the expected benefits concerning reuse, time-to-
tions can be created with less effort than in traditional ap- market, and adaptability, according to aspects such as number
proaches, simply by assembling existing parts. The principles and size of models, amount of reuse, defect numbers, etc.
of model-driven and component-based development are suc- Section II gives an overview on related work. Sections III
cessfully applied in hardware manufacturing (e.g., production and IV describe MARMOT in detail including product and
lines in the automotive industry). However, embedded software process model. Section V presents the case study in detail
systems are still afar from rapid application assembly with including example UML models, and Section VI presents the
components. Many embedded system projects are targeted at evaluation of the case study and describes results obtained.
small 8 or 16 bit processors with limited resources, whereby Finally, Section VII presents a brief summary, conclusions
the complexity of these systems is continuously increasing. drawn, and the hypotheses for future research.
This leads engineers to applying informal but structured de-
velopment techniques including the application of object and II. R ELATED W ORK
component technologies, and the UML [28] as a unifying Growing complexity and short release cycles of embedded
specification notation. The underlying hypothesis is that ap- systems stimulated the transfer of model-driven development
plying such techniques will help control the complexity of techniques to the domain of embedded software systems.
embedded systems, and improve maintainability, adaptability There are two research routes: Formal modeling languages for
and portability, as well as time-to-market [12]. Component- embedded system design, and non-formal approaches using
based development methods [31], technologies, and tools have standard notations such as UML. Initially, formal languages
evolved well in the information systems domain. However, such as Z [19], functional decomposition [26], or state-based
engineers working in the embedded systems domain do not notations [11] were used, but these approaches lack reuse
readily exploit the effects of component technology and mechanisms on higher levels of abstraction. Newer develop-
modeling for an apparent reason: We believe, the disciplines ments such as MATLAB [24] or MODELICA [9] provide
involved, mechanical-, electronic-, and software engineering, tool and (additional) methodological support, but lack effective
are not in sync, a fact which cannot be attributed to any one of reuse strategies and adaptation mechanisms. Recently, the
these fields alone. Engineers are struggling hard to master the Unified Modeling Language (UML) [28] was adapted for

33rd EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 2007)
0-7695-2977-1/07 $25.00 © 2007
 Composition
on
Composition ati
lid are
Va
rdw
Ha

ry
na
/Bi
u rce de
So Co

l
de Concretization
Mo

Decomposition
t
en
im
bod
Genericity Em

Abstraction

Specialization
Decomposition

(a) Component meta model. (b) Development dimensions.

Fig. 1: MARMOT’s product and process models.

modeling embedded and real-time systems, but it still lacks gained by initial component development plus reuse for a real
precise semantics, and guidelines about its usage. system, and the impact of the acquired technologies on quality
OMEGA [13], HIDOORS [32], or FLEXICON [22], or the and time-to-market. This is the motivation for performing this
work presented in [7], [8], [20], [23], [30] define development case study and assessing the benefits of these techniques.
methods for real-time and embedded systems using the UML.
Although a step in the right direction, they often do not use the A. Research Questions
enhanced features of UML 2.0, nor do they address complexity
and reuse issues. Another problem is the inadequate support Our research questions focus on two sets of properties of
for mapping UML (2.0) models to code [15]. Developers MDD in the context of component-oriented development. The
follow traditional approaches, and a complete transition to first set of questions (Q1-Q4) will lead to an understanding of
object- or component technology is prevented by the required basic and/or general properties of a methodological approach
time and space efficiency of the product, or due to standards to to embedded system development:
be followed (e.g., DO-178B in the civil aviation domain). Em- • Q1: Which process was used to develop the system?
bedded system development would benefit from the advantages The answer to this question will give a brief qualitative
of model-driven development (MDD) [15] if the technologies description of the method we used for developing the
could be integrated into existing development processes (i.e., initial exterior mirror system (MARMOT, RUP, Agile).
keep C as target language). Most approaches and tools map • Q2: Which types of diagrams have been used? Are all 13
models to sophisticated languages (e.g., Java, resulting in run- UML diagram types required, or is there a specific subset
time performance, memory, or timing problems [15]), or use sufficient for a domain?
straightforward mapping strategies (UML to C) that neglect • Q3: How were models transferred to source code? Devel-
concepts such as inheritance or dynamic binding. opers typically follow the traditional procedural paradigm
(i.e., C) that impedes the transformation of UML concepts
III. R ESEARCH A PPROACH into C [15].
By applying MDD and component-based development • Q4: How was reuse applied and organized? Reuse is
(CBD) methods, engineers expect an increase of model or central to MDD with respect to quality, time-to-market,
component reuse, and, thus, shorter time-to-market, improved and effort, but reuse must be built into the process, it
adaptability, and higher quality. However, introducing MDD does not come as a by-product (i.e., components have to
and CBD principles in an organization is generally a slow and be developed for reuse).
incremental procedure [21]. An organization will start with The second set of questions (Q5-Q9) deals with the resulting
some reusable components, and eventually build a component product of the applied MDD/CBD approach. The developed
repository. But they are unsure about the return on investment systems are examined from a customer’s point of view, with

33rd EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 2007)
0-7695-2977-1/07 $25.00 © 2007
 respect to code size, defect density of the released code, and
time-to-market.
• Q5: What is the model-size of the systems? MDD is often
believed to create a large overhead of models, even for
small projects. Model-Size is calculated by using standard
metrics as defined in [18].
• Q6: What is the defect density of the code? Defect density
is computed per one hundred lines of code.
• Q7: How long did it take to develop the systems and how
is this effort distributed over the requirements, design,
implementation, and test phases? Effort saving is one
promise of MDD and CBD [33], though, it does not occur
immediately (i.e., in the first project), but in follow-up
projects. Effort is measured for all development phases
to identify where savings are realized. Fig. 2: Exterior mirror control system.
• Q8: What is the size of the resulting systems? MDD for
number of software components. These metrics are com-
embedded systems will only be successful if the resulting
parable to the traditional LOC or McCabe’s cyclomatic
code size, obtained from the models, is small.
complexity (MVG) for estimating the size and nesting of
• Q9: How much reuse did take place? Reuse is central
a system’s program code [16].
for MDD and CBD and it must be seen as an upfront
• Code-size measured in normalized LOC (i.e., without
investment paying off in many projects. Reuse must be
comment and blank lines).
examined between projects and not within a project.
• System-size is measured in KBytes of the hex-file to be
flashed to the controller. All systems were compiled using
B. Research Procedure
the GCC’s space optimization facilities.
The assumption is that by using a systematic method (i.e., • The amount of reuse is described as the proportion of the
MARMOT), we can obtain efficient reuse, and shorter time- system that can be reused without changes or with small
to-market. However, such claims need to be evaluated. The adaptations (i.e., configuration but no model change).
benefits of MDD and CBD are only realized in follow-up Measures are taken at the model and the code level and
projects, so that we developed an initial mirror control system are normalized using the system size (model, LOC).
as basis for further application engineering. Students of the • Defect density is measured in defects per 100 LOC
Department of Computer Science at the Technical University (defects collected via inspection and testing activities)
of Kaiserslautern used the initial system documentation and • Development effort and its distribution over development
MARMOT as method in the context of different (small) phases are measured as development time. Since all
system development projects. The students were taught basic projects were quite small, development hours were used,
software engineering principles, object-oriented development coming from daily effort sheets.
techniques, and UML. All students had sufficient knowledge of
developing micro-controller-based applications through part- IV. OVERVIEW OF MARMOT
time employment at local companies. Students knew that Reuse can be seen as a major driving force in hardware and
data would be collected and analyzed. They were unaware software development. The growing complexity of systems
of the concrete nature of questions/hypotheses being tested. requires well-structured approaches, which in turn increase the
The student projects were organized according to typical reuse possibilities for reuse. This section introduces the MARMOT
situations in component-based development, and a number of method that facilitates component-based structuring and reuse
measurements to answer the research questions of the previous in embedded systems development. MARMOT is an extension
sub-section were performed. The measures are: to the KobrA method [2], a component-based development
• Model-size measured using the absolute and relative framework for information systems that is geared towards the
size measures proposed in [18]. Relative size measures, specific requirements of product line architectures. MARMOT
defined as ratios of absolute measures, are used to address adds concepts addressing the specific requirements of devel-
UMLs multi-diagram structure as well as to deal with oping embedded systems.
completeness issues [18]. The absolute size measures Composition is a key activity in component-based develop-
(i.e., metrics that measure numbers of elements or LOC) ment with MARMOT. A system is viewed as a hierarchy of
used within this paper are: the number of classes in components, in which the parent/child relationship represents
a model (NCM), number of components in a model composition, i.e., a super-ordinate component is composed out
(NCOM), number of diagrams (ND), and LOC. NCOM of its contained sub-ordinate components. Another established
describes the number of hardware and software com- principle is the separation of interface and implementation
ponents within the system. NCM is used to denote the which supports independent component development, and al-

33rd EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 2007)
0-7695-2977-1/07 $25.00 © 2007
 lows different realizations of a component to be exchanged. a hardware component, and as an assembly of common
Following those principles, each component can be described data, which is true for the hardware and the software. The
through a suite of models (e.g., UML diagrams) as if it was software represents an abstraction of the hardware.
a system in its own right (see Figure 1a). • An additional important property is communication ac-
cording to interface contracts which becomes feasible
A. The MARMOT process model
in the embedded world through typical software abstrac-
The core principle of MARMOT is separation of con- tions. Here, the additional hardware wrapper of MAR-
cerns, with two basic development dimensions (Composi- MOT realizes that the hardware communication protocol
tion/Decomposition and Abstraction Concretization) that map is translated into a component communication contract.
to four basic activities (Decomposition, Embodiment, Com- Composition turns a MARMOT project into a tree-shaped
position, and Validation) [2]. These are depicted in Figure 1b structure, a containment tree, with nested component repre-
and described in the following list: sentations. Every box in the tree is treated as a system in its
• Decomposition. A development project starts above the own right. It comprises a component specification, defining
top left-hand side box in Figure 1b. It represents the entire everything externally knowable about a component, and a
system to be built. Before the specification of the box, the component realization, a model about the internal design of the
concepts of the domain in which the system is supposed component. Any component in a tree, represents a containment
to operate must be determined comprising descriptions tree in its own right and, thus, another MARMOT project.
of all entities relevant in the domain such as standard
hardware components that will appear on the right- V. C ASE S TUDY
hand side towards concretization. These implementation- The exterior mirror control system that we used as case
specific entities determine the way in which a system study is composed of electrical and mechanical components
is divided into smaller parts [10]. Decomposition deter- and control logic. It allows the mirror to be adjusted horizon-
mines the shapes of identified individual components in tally and vertically into the desired position. Cars supporting
an abstract and logical way. different driver profiles can store the mirror position and recall
• Embodiment. The system, or its parts, can then be moved as soon as the profile is activated. Here, we use a simplified
towards more concrete representations, mostly through version for brevity of illustration. The system (Figure 2)
reusing existing components (or custom development). comprises a microcontroller, a button, two potentiometers, and
There is no distinction between hard- and software com- two servos. It controls the two servo-drives via two poten-
ponents at this early phase because all components are tiometers, and indicates their movement on a small LCD panel.
treated in terms abstract models. The micro-controller reads values from the potentiometers,
• Composition. The reused and implemented components converts them to degrees, and generates the needed servo
are assembled according to the abstract model, and the control signals, while at the same time indicating movement
subordinate boxes have to be coordinated with their re- and degree on the LCD display. The system stores a position
spective super-ordinate boxes according to the MARMOT through pressing the button for more than 5 seconds.
component model. 1) Requirements Modeling: Use cases describe the require-
• Validation assesses to which extent the concrete compo- ments in a textual and a graphical representation. Activity
sition of the embedded system corresponds to its abstract diagrams describe the general flow of control, including a
description. UML representation of the target platform (see Figure ??).
The actor ’User’ initiates the task of controlling the mirror
B. The Basic MARMOT Product Model
aptitude rotation, and stores and recalls positions through the
MARMOT follows the principles of encapsulation, modu- button. The system uses an ATMega8 controller and several
larity and unique identity [31], which lead to a number of hardware components.
obligatory properties: 2) System Architecture: The artifacts shown in Figure ??
• Composability is the primary property and it can be represent the ’context realization’ of the mirror system. The
applied recursively: components make up components, context is like a pseudo component realization at the root of
which make up components, and so on. the development tree that embeds the system as a regular
• Reusability is the second key property, separated into component. Since components are identified in a top-down
development for reuse, i.e., components are specified to manner, a component or containment hierarchy is established.
be reusable, and development with reuse, dealing with Figure IV-B shows the containment hierarchy of the mirror
the integration and adaptation of existing components in system in its final form.
a new application. 3) Component Modeling: Component modeling creates the
• Having unique identities requires that a component must specification and realization of all software components using
be uniquely identifiable within its development and run- class, state, interaction, and activity diagrams, as well as oper-
time environment. ation schemata. Since timing is critical in embedded systems,
• Modularity/encapsulation refer to a component’s scoping the component realization is extended by timing diagrams.
property as an assembly of services, which is also true for Modeling starts at the root of the containment hierarchy, and

33rd EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 2007)
0-7695-2977-1/07 $25.00 © 2007
 Fig. 3: Containment hierarchy

the top-level component is specified using three different UML 16MhZ), and to an entirely different processor (i.e., PICF,
models (see Figure 1a): (1) structural model, showing with 7Kb Flash, 192Byte RAM, 128Byte EEPROM, 20MHz).
which other classes the component interacts; (2) functional Implementing a port on the same type of processor can be
model, describing the externally visible operations supplied by automated at the code-level, whereas, a port to a different
the component; (3) behavioral model, showing the externally kind of hardware may affect the models [25].
visible state model. Figure 4a shows the model of the Ap- • We implemented evolving system requirements as to (1)
plication component. The component specification is further remove the recall position functionality, referred to as
decomposed to the component realization comprising the Adapt-), and (2) add a defreeze/defog function with a
component’s private design. It describes how the component humidity sensor and a heater, referred to as Adapt+.
fulfills its requirements, via (1) a structural model, showing • Parts of the mirror system were reused in a door control
its internal class architecture, (2) an activity model specifying unit, referred to as Door, that incorporates the control of
the algorithms, and (3) an interaction model showing how a the mirror, power windows, and door illumination. It was
group of instances collaborate to realize an operation. realized using three controller boards, and a serial-line
These primary artifacts can be enhanced, if needed, by communication between the controllers.
timing diagrams, or other non-functional specifications. Figure As development tools, the students used Rational Rose [29]
4b depicts some of the realization models of the Application or ARGO UML [1] for modeling, and the AVRStudio/GCC
component (interaction model, activity model, and structural environment [3] for programming and debugging.
model). The models are devised for every component in the
containment hierarchy. VI. R ESULTS OF THE C ASE S TUDY
4) Implementation: Iteratively devising specifications and The presented case study applied the MARMOT approach
realizations is continued until an existing component is found, (Q1) according to the research questions stated (Section III),
thereby targeting existing abstractions, or, until it can be imple- whereby mapping models to code (Q3) was done manually.
mented (no reuse). Coming to a concrete implementation from We performed a number of measurements in order to get
the models requires us to reduce the level of abstraction of a first impression whether maintainability, portability, and
our descriptions. First, the containment hierarchy is simplified adaptability of embedded systems, developed with MARMOT,
according to the technical restrictions of the used implemen- may be improved. Table I provides all data concerning model
tation technology. That is through refining the containment and code size as well as data on quality- (e.g., defect numbers),
hierarchy and mapping it to a UML model with the source and process measures (e.g., effort). The figures follow the
code structure of the resulting system. Second, the models are metric definitions presented in Section III.
mapped to source code, either through a code generator, or On first thought, the number of diagrams (ND) seems
through manual mapping according to [15]. to be quite high for such a simple example. Modeling at
5) Follow-Up Projects: Reuse can only be assessed in the specification and realization level results in several dia-
follow-up projects. This is why we devised a number of grams plus textual descriptions for each component. Due to
student assignments, in order to change and extend the original MARMOT’s modeling principles, every component has two
mirror system, with the aim to look at the reuse situations associated sets of diagrams, one at the specification- and one
described in [5]. on the realization level. This increases the number of diagrams
• Porting to different hardware platforms retaining its func- and creates the impression of redundant information. However,
tionality. We ported the system to a similar processor the separation and explicit distinction of specification and
(i.e., ATMega32, 32Kb Flash, 2Kb RAM, 1Kb EEPROM, realization provides several advantages (see Sect. IV). In

33rd EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 2007)
0-7695-2977-1/07 $25.00 © 2007
 (a) Specification Diagrams

(b) Realization Diagrams

Fig. 4: Mirror control system- Specification and Realization Diagrams

addition, realization diagrams need only to be revisited or platforms is also supported by the high amount of reuse
modified if the component specification was changed. with minimal changes, the low effort, and the low number
of defects. Concerning the adaptation of existing systems by
It is interesting to see that porting the system to another adding or removing functionality, the data presented in Table
hardware platform, required only minimal changes to the mod- I reveals that MARMOT provides sufficient support. (1) A
els (e.g., UML hardware representation, ports, and the like). large proportion of the systems could be reused from the
Thus, MARMOT supports the MDA idea [25] of platform original system. (2) In comparison to the initial development
independent modeling. Only in the embodiment step, models project (i.e., ’Original’), the effort for adaptation is low, i.e.,
become platform-specific. Portability of a system to different

33rd EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 2007)
0-7695-2977-1/07 $25.00 © 2007
 Project Original ATMega32 PICF Adapt- Adapt+ Door
LOC 310 310 320 280 350 490
Hex-Size (Kbytes) 4 4 4 3.5 4.5 6
Model NCM 8 8 8 6 10 10
NCOM 15 15 15 11 19 29
ND 46 46 46 33 52 64
StateCharts
Relative Classes
1 1 1 1 0.8 1
Operations
Model Classes
3.25 3.25 3.25 2.5 3 3.4
Associations
Size Classes
1.375 1.375 1.275 1.33 1.3 1.6
Reuse Reuse Fraction 0 100 97 100 89 60
in New 100 0 3 0 11 40
percent Unchanged 0 95 86 75 90 95
Changed 0 5 14 5 10 5
Removed 0 0 0 20 0 40
Effort Global 26 6 10.5 3 10 24
in Hardware 10 2 4 0.5 2 8
hours Requirements 1 0 0 0.5 1 2
Design 9.5 0.5 1 0.5 5 6
Implementation 3 1 3 0.5 2 4
Test 2.5 2.5 2.5 1 2 4
Quality Defect Density 9 0 2 0 3 4

TABLE I: Results of the case study.

26 hours initial development vs. 3 or 10 hours for the adapted sumption that embedded systems can be developed quickly,
systems. (3) The quality of the final systems benefits from the resulting in high quality.
quality assurance activities carried out in the initial component Up to this point, we have only examined the effects of
development. following the MARMOT method in developing our case study.
The promises of component-oriented development concern- However, it is also interesting to compare our experience,
ing time-to-market and quality are confirmed by our case- gathered so far, with the ways other development methods
study. The effort for the initial system corresponds to stan- may be applied in such a setting. This is why we are
dardized effort distributions over development phases such as currently performing two more experiments, developing the
the ones used by common cost estimation methods [35]. The same system, using other methods and development teams.
effort for the variants is significantly lower, and it supports In one experiment, we follow the Unified Process [17], with
the assumption that component-oriented development has an a specific adaptation to embedded system development [5],
effort-saving effect in subsequent projects. This is in-line with and in the second experiment, our developers follow an agile
the experiences reported by [6], [34], [35]. In general, porting development process according to the principles outlined in
and adaptation activities within a component-based system [14]. In addition, we are interested to see whether or to which
development takes place during devising the system variants. extent exchanging personnel is going to affect the factors that
On the one hand, our systems are very similar, which explains we have looked at here. Having many different people work on
why reuse works so well. On the other hand, the consistent the same system or components is normal in industry where
use of C as programming language and the encapsulation maintenance or adaptations are not necessarily performed by
of the hardware (i.e., using a ’Driver’ component) supports the people originally involved in a project. We will have
the porting, since this requires only changing the hardware the follow-up projects being developed by other development
capsule. Even if code is not generated automatically (as in teams in parallel.
this case-study) the MARMOT component structure permits
easy localization of necessary changes and reduction of the VII. S UMMARY AND C ONCLUSIONS
number of changes. The case-study shows that the promises of model-driven
In order to investigate the development of larger systems and component-oriented development can also be achieved in
that reuse the original system as a whole or to a large extent, embedded system development. However, component-based
we carried out the ’Door’ case study. Table I indicates that 60% development projects require an upfront investment before
of the overall original mirror control system was reused in the they pay-off. We are aware of the fact, that there may be
new door control system. The integrated mirror control system problems with the validity of our results impeding their
did not require extended adaptations. The effort and defect generalization. First, the developers were students, and they
density was found to be higher in this case, than those of the may not be representative for software professionals, although
other mirror system variants. We could attribute this to the fact the results may be useful in an industrial context, because,
that on top of the additional component development, major sometimes, engineers have a negative attitude towards model-
hardware extensions and intensive quality-assurance activities ing, in contrast to students.
took place. When compared to the initial development effort Introducing a method requires a steep training curve, even
and quality of the product, i.e., the original mirror control for professionals. Second, volunteers may affect the validity
system, we can observe a positive trend supporting our as- of the study (i.e., selection bias), because they are motivated.

33rd EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 2007)
0-7695-2977-1/07 $25.00 © 2007
 In contrast, people in companies are often afraid that new [6] S. Cohen, Predicting when Product Line Investment Pays, Proc. of the
technology takes too much of their time. These differences Second International Workshop on Software Product Lines: Economics,
Architectures, and Implications, pages 15-18, 2001.
between study participants and people in real organizations [7] I. Crnkovic, M. Larsson (Eds.), Building Reliable Component-Based
may limit the generalizability of our conclusions. Third, the Software Systems, Artech House, 2002.
case-study is limited in a sense that it does not allow to [8] B.P. Douglass, Real-Time Design Patterns, Addison-Wesley, 2003.
[9] P. Fritzson, Principles of Object-Oriented Modeling and Simulation with
explicitly identify the concrete factors and technologies (e.g., Modelica 2.1, Wiley, 2004.
UML, MDD, CBSD, PLA) which are responsible for the [10] H.-G. Gross, Component-Based Software Testing with UML, Springer,
obtained reuse rates. One reason might be that students used a Heidelberg, 2005.
[11] D. Harel, H. Lachover, A. Naamad, and others, Statemate: A working
mix of explicit and implicit techniques during the study. Thus, environment for the development of complex reactive systems, IEEE TSE,
further, more detailed studies are required that examine this 16(4), April 1990.
issues in-depth. [12] B. Heck, L. Wills, G. Vachtenavos, Software technology for Imple-
menting Reusable, Distributed Control Systems, IEEE Control Systems
Finally, the systems developed may not be representative in magazine, February, 2003.
terms of their size and complexity, although we regard them [13] J. Hooman, Towards Formal Support for UML-based Development of
Embedded Systems, Proc. of the 3d PROGRESS Workshop on Embed-
as indicating a trend of possible benefits. ded Systems, Technology Foundation STW, 2002.
The growing interest in the UML provides a unique op- [14] P. Hruschka, C. Rupp, Agile Softwareentwicklung fr Embedded Real-
portunity to increase the amount of software modeling, and Time Systems mit der UML, Hanser, 2002.
[15] M.U. Khan, K. Geihs, and others, Model-Driven Development of Real-
to elevate quality standards. UML 2.0 promises new ways Time Systems with UML 2.0 and C, 3rd International Workshop on
to apply object/component-oriented and model-based devel- Model-based Methodologies for Pervasive and Embedded Software at
opment techniques throughout embedded system engineering. the 13th IEEE Int. Conf. on Engineering, 2006.
[16] H. Kim, C. Boldyreff, Developing software metrics applicable to UML
However, this chance will be lost, if developers are not given models, Proc. of the 6th ECOOP Workshop on Quantitative Approaches
effective and practical means for handling the complexity of in Object-oriented engineering, Malaga, Spain, June 2002.
such systems, and guidelines for systematically applying them. [17] P. Kruchten, The Rational Unified Process - An Introduction, 2nd edition,
Addison-Wesley, 2000.
This paper has outlined the UML modeling practices, which [18] C.F.J. Lange, Model Size Matters, Workshop on Model Size Metrics,
are needed in order to fully leverage the component paradigm 2006 (co-located with the ACM/IEEE MoDELS/UML Conference);
in the development of software for embedded systems. Fol- October, 2006.
[19] K. Lano, Formal Object-Oriented Development. Springer, 1995.
lowing the principles of encapsulation and uniformity, and de- [20] L. Lavagno, G. Martin, B. Selic (Eds.), UML for Real Design of
scribing both levels with a standard set of models, it becomes Embedded Real-Time Systems, Kluwer, 2003.
feasible to model hardware and software components of an [21] J. Li, R. Conradi, P. Mohagheghi and others, A Study of Developer
Attitude to Component Reuse in Three IT Companies, 5th Int. Conference
embedded system with UML. This facilitates also a ”divide Product Focused Software Process Improvement, PROFES 2004, 2004.
and conquer” approach to modeling, in which a system unit [22] M. Marcos, E. Estvez, U. Gangoiti and others, UML Modeling of
can be developed independently, and it permits new versions Industrial Distr. Control Systems, Proc. of the 6th Portuguese Conf. on
Automatic Control, Portugal, 2004.
of a unit to be interchanged with old versions, provided that [23] P. Marwedel, Embedded System Design, Springer, 2006.
both fulfill the original specification/interface. [24] The MathWorks, Inc., Simulink Reference, 2005,
We carried out a case-study, and we are still in the process of http://www.mathworks.com.
[25] J. Miller, J. Mukerji, MDA Guide 1.0, omg/03-05-01, 2003.
gathering more experimental results to assess the MARMOT [26] H.D. Mills, V.R. Basili, J.D. Gannon and others, Principles of Computer
method. Quantitative and qualitative results of our study Programming: A Mathematical Approach. Allyn and Bacon Inc., 1987.
indicate that MARMOT supports systematic reuse and thereby [27] A. Mockus, R.T. Fielding, J. Herbsleb, A Case Study of Open Source
Software Development: The Apache Server, Proc. of the 22nd Interna-
reduces development effort, and improves the quality of a tional Conference on Software Engineering, Limerick Ireland, 2000.
software system. However, these results are only a starting [28] Object Management Group, UML 2.0 Super-structure Specifica-
point for more elaborate validation and generalization. Besides tion, OMG document formal/05-07-04, 2005, http://www.omg.org/cgi-
bin/doc?formal/05-07-04.
the extended experiments that we are currently performing, [29] Rational Rose, http://www.rational.com.
we plan a larger controlled experiment in order receive more [30] B. Selic, G. Gullekson, P.T. Ward, Real-Time Object-Oriented Modeling,
experimental data to identify to which technology the obtained John Wiley & Sons, 1994.
[31] C. Szyperski, Component Software. Beyond Object-Oriented Program-
reuse rates can be attributed (i.e., MDD, CBSD, or PLA). ming, Addison-Wesley, 2002.
[32] J. Ventura, F. Siebert, and others, HIDOORS - A High Integrity Dis-
tributed Deterministic Java Environment, Proc. of the 7th Int. Workshop
R EFERENCES on Object-Oriented Real-Time Dependable Systems, USA, 2002
[33] A. Dagnino, H. Srikanth, M. Naedele, D.A. Brantly, A model to
[1] ArgoUML Homepage: http://argouml.tigris.org/ evaluate the economic benefits of software components development,
[2] C. Atkinson, J. Bayer, C. Bunse, and others, Component-Based Product- IEEE International Conference on Systems, Man and Cybernetics, 2003.
Line Engineering with UML, Addison-Wesley, UK, 2001. [34] G. Böckle, P. Clements, J.D. McGregor, K. Schmid, A Cost Model for
[3] AVR Studio, Atmel Corp. http://www.atmel.com. Software Product Lines, Fifth International Workshop on Product Family
[4] C. Bunse, H.-G. Gross, Unifying Hardware and Software Components Engineering (PFE-5), Siena, Italy, November 4-6, 2003.
for Embedded System Development, In: Architecting Systems with [35] G. Böckle, P. Clements, J.D. McGregor, K. Schmid, Calculating ROI
Trustworthy Components, R. Reussner, J.A. Staffort, C.A. Szyperski for Software Product Lines, IEEE Software, Volume 21, Issue 3, 2004
(Eds), Lecture Notes in Computer Science, Vol. 3938, Springer, 2006. [36] B. Boehm, E. Horowitz, R. Madachy, D. Reifer, B. Clark, B. Steece,
[5] M. Cantor, Rational Unified Process for Systems Engineering, the A. Brown, S. Chulan, Software Cost Estimation with Cocomo II,
Rational Edge e-Zine, 2003, http://www.therationaledge.com/content Prentice Hall, 2000)
/aug 03/f rupse mc.jsp.

33rd EUROMICRO Conference on Software Engineering and Advanced Applications (SEAA 2007)
0-7695-2977-1/07 $25.00 © 2007