Experiences from Representing
Software Architecture in a Large
Industrial Project Using Model Driven
Development
Andres Mattsson1
Björn Lundell2
Brian Lings2
Brian Fitzgerald3
Presented by: Karo Mazidzhyan
Combitech AB, P.O. Box 1017, SE-551 11 JÖNKÖPING, Sweden
2 University of Skövde, P.O. Box 408, SE-541 28 SKÖVDE, Sweden
3 Lero – the Irish Software Engineering Research Centre University of Limerick, Ireland
1
Role of Architecture

Primary role of architecture is to capture:
◦ design decisions
◦ rules which are to be followed in detailed
design
Allow for the quality requirements to be
met
 “architecture is the conceptual glue that
holds every phase of the project together
for all of its many stakeholders.”

Purpose of this Paper
Model-Driven Development is an
emerging discipline
 The success of MDD in a large industrial
project is still in question
 Reports on industrial experience from
use of MDD and brings to light possible
improvements

Model-Driven Development

MDD
◦ Capture all important design information in a
set of formal or semi-formal models which
are automatically kept consistent by tools.
Raises level of abstraction at which
developers work
 Eliminate time consuming and error
prone manual work in keeping different
design artifacts consistent.

MDD Tools and Approaches

Object Management Group’s
◦ MDA – Model-Driven Architecture
Domain-Oriented Programming
 Model-Driven Engineering
 Microsoft’s

◦ Software Factories
Paper Background


Describe Experiences from a large project
Task
◦ Combitech Systems (CS), in the year 2000 was
assigned a task to build a platform for a new
generation of digital television set top boxes.

Timeline
◦ Development completed in 18 months

Challenges
◦ Completely new, customized hardware platform
Development Challenges

Short time-to-market
◦ Competition with other developers

Integration of HW and Software
◦ Software and Hardware had to be developed
in parallel
◦ Testing of software had to occur on range of
platforms

Moving Target
◦ Requirements overridden by acceptance tests
delivered late in project
Challenges Continued…

Long Term Maintenance Period
◦ Due to the long maintenance period of the
hardware, it must be cost effective

Product Variants
◦ Need to generate product variants based on
different markets
◦ Variants need to be developed and maintained
efficiently

Competition
◦ Products would compete on performance and
quality to win the final contract
Rationale for Choosing MDD
CS, had extensive experience in working
with models in UML and earlier modeling
languages, both for analysis and design.
 CS had experience of using rule-based
transformations, however real project
transformations had been done manually.
 Given these experiences CS felt that
MDD would help in taking on this
challenge.

Rationale Continued…

Agility
◦ This approach made it possible to work in an
agile manner in which one can go from
requirements to tested implementation
without skipping documentation

Testing on Several HW Platforms
◦ Made it possible to test most of the code
without access to the actual hardware by
generating code for different platforms as the
HW became available
Rationale Continued…

Performance
◦ Generated code must be efficient
◦ High level abstraction would allow for
refactoring with less effort, which makes fine
tuning the system easier

Product Variability
◦ MDD would make it easier to both
communicate and enforce the architecture
Rationale Continued…

Tool Selection – Rhapsody (Ilogix)
◦ Due to the time restrictions an out-of-the-box
tool was required which would give:
 Modeling in standard UML – to minimize training
 Generate code with good performance on target
platform
 Ability to use C++ code where needed – remove risks
of novelty
 Debug at model level
 Support for distributed team working
 Vendor support for improving embedded real-time
system development
Capturing of the Architecture

Product line architecture approach
◦ Addresses requirements for efficient
development and maintenance of product
variants.

Approach for capturing design
◦ High level structure captured in system model
◦ Design rules captured in combination of natural
language and a framework in the system model
◦ Example components designed in the system
model – illustrating the architectural rules
Capturing Architecture Cont…

High Level Structure
◦ System was partitioned to a level at which
components were to be developed by individuals
◦ Captured in a package hierarchy populated with
classes acting as façades for the actual components

Architectural Design Rules
◦ The framework contained abstract base classes,
relations between them and operations which are to
be overridden
◦ Framework also contained full implementations of
basic mechanisms – inter-process resource locking,
component registry
◦ Project didn’t capture architecture rules in a formal
model – natural language was needed to express the
rules
Capturing Architecture Cont…
◦ Example of natural language expression:
“All specializations of arcPort may have several methods for the method Ctrl().These
methods shall be named as ctrl_<specific_name> and may not change the parameter list
of the base class, except for specialization of the parameter classes given for the base
class. However, a method may omit the second (parameters) parameter.”

Providing Example Components
◦ A number of example components were
developed by the architects as a guide on how to
use the architectural framework
◦ Examples also showed how to use different
diagrams to capture the design
Architectural Framework
Lessons Learned

Manual enforcement and guidance is time consuming
◦ Using natural language to describe the architecture forced
heavy reliance on manual reviews to enforce conformance
◦ Rules proved hard to enforce and ambiguous, which led to
different interpretations
◦ Developers had hard time following all of the detailed
rules

Late changes to design rules are time consuming and
error prone
◦ Due to the manual transformation of part of the
architecture which made late changes almost impossible
◦ The idea that MDD would allow late changes to the
architecture did not hold
Summary

MDD allows some of the architecture to
be captured in formal models but not all
◦ Current methods and tools do not support
formal representation of rules which go
beyond structure
◦ The remaining rules need to be captured in
natural language which causes a reliance on
manual interpretation and reviews
◦ This requires a lot of effort from developers
and architects and creates a bottleneck
◦ Affects both time and quality
Summary Continued…

Late changes are hard to make
◦ architectural rules are manually introduced
◦ Involves massive reworking

To obtain the full benefits from MDD
◦ Need for support of formal modeling of
architectural rules
◦ Automatic enforcement of these rules on
generated models of the system