Model-Driven Engineering in a Large Industrial Context - Motorola Case Study
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
Model-Driven Engineering in a Large Industrial
Context — Motorola Case Study
Paul Baker1 , Shiou Loh2 , and Frank Weil3
1
Motorola Labs, Jays Close, Viables Industrial Estate, Basingstoke, Hampshire,
RG22 4PD, UK
Paul.Baker@motorola.com
2
Motorola Inc, 1301 E. Algonquin Rd., Schaumburg, IL 60196, USA
Shiou.Loh@motorola.com
3
Motorola Global Software, 1303 E. Algonquin Rd., Schaumburg, IL 60196, USA
Frank.Weil@motorola.com
Abstract. In an ongoing effort to reduce development costs in spite of
increasing system complexity, Motorola has been a long-time adopter
of Model-Driven Engineering (MDE) practices. The foundation of this
approach is the creation of rigorous models throughout the development
process, thereby enabling the introduction of automation. In this paper
we present our experiences within Motorola in deploying a top-down
approach to MDE for more than 15 years. We describe some of the key
competencies that have been developed and the impact of MDE within
the organization. Next we present some of the main issues encountered
during MDE deployment, together with some possible resolutions.
1 Introduction
Motorola employs over 13,000 software engineers and has been applying ini-
tiatives such as the Software Engineering Institute Capability Maturity Model
to improve the quality and productivity of software and system development.
However, given increasing system complexity, these initiatives are not enough
by themselves. As a result, Motorola began to deploy Model-Driven Engineer-
ing (MDE) as a means of introducing automation into the development process.
After more than 15 years, Motorola has matured and deployed its MDE process
with impressive results. This paper introduces some of Motorola’s experiences
and issues during MDE usage. We conclude by presenting some high-level strate-
gies Motorola is pursuing to further enhance MDE deployment and success.
2 Experience
Motorola’s experience in MDE crosses a wide spectrum of activities, tools, and
modeling languages in the telecommunications domain. Typical applications
range from protocol implementations on hand-held devices (pagers, cell phones,
etc.) to network controllers in infrastructure components (base stations, radio
L. Briand and C. Williams (Eds.): MoDELS 2005, LNCS 3713, pp. 476–491, 2005.
c Springer-Verlag Berlin Heidelberg 2005Model-Driven Engineering in a Large Industrial Context 477
network controllers, etc.) This section describes this experience, covering lan-
guages and standards, development processes, and the automatic generation of
tests and application code. In addition, we discuss MDE successes and failures
and the impact that MDE has had.
2.1 Languages and Standards
Motorola began using standard modeling languages over 15 years ago with Struc-
tured Analysis and Structured Design (SA/SD) [9]. This was followed by the
introduction of the Specification and Description Language (SDL) [12] to Mo-
torola Europe for the modeling and validation of the design of communication
protocols. These positive experiences led to the large-scale deployment of an
MDE approach using languages such as Message Sequence Charts (MSC) [11],
SDL, and TTCN-2 [13] for the development of large telecommunication sys-
tems. MSCs were typically used for requirements specification, SDL for design,
and TTCN-2 for test specification.
Following this wider deployment with MSC and SDL, Motorola increased
its involvement and leadership within the standards communities, especially the
International Telecommunications Union (ITU-T), the European Telecommuni-
cation Standards Institute (ETSI), and the Object Management Group (OMG).
For example, the MSC language was extended to allow the parameterization
of any data language, thereby making it possible to develop test models as a
basis for automatic test generation. In general, these languages were very well
suited to the domain of telecommunication systems, and their precise semantic
foundations gave a clear and unambiguous interpretation for users.
To broaden the application domains for MDE, gain wider user acceptance,
and harmonize languages, Motorola pursued the development of UML 2.0 [16]
and testing notations. In doing so, MSC and SDL were incorporated into UML 2.0
to provide a language with a wider application scope which preserves those ca-
pabilities needed for communication system development.
Together with European telecommunication companies, ETSI pursued the
evolution of TTCN-2 to define a test specification language that could be used
in a wider context (e.g., CORBA, web-based systems, etc.). The result was
TTCN-3 [7], a powerful and well defined abstract test specification and exe-
cution framework. Motorola promoted the use of TTCN-3 to harmonize testing
across different engineering teams, thereby leading to transferable skills and tool
reuse. To bridge the gap between TTCN-3 and UML 2.0, Motorola pursued the
development of the UML 2.0 Testing Profile [3] for graphical test modeling.
Motorola is an active participant in the OMG Platform Technology Commit-
tee and in the ITU-T SDL Committee (Study Group 17), including the ITU-T
efforts to unify SDL and UML (Question 13/17 - System Design Languages
Framework and Unified Modeling Language).478 Paul Baker, Shiou Loh, and Frank Weil
2.2 Process Overview
Since its adoption of MDE, Motorola has followed a rigorous, top-down pro-
cess. Typically, the process starts with the development of requirements using
scenario-based models (defined using MSCs or UML 2.0 Interaction Diagrams),
thereby capturing normative and exception behaviors. Next, architectural re-
quirements are developed to define the main system components and the inter-
actions between them. In addition to refining scenario-based models, interface
specifications detailing the data passed between system components are devel-
oped in either proprietary or standard languages such as ASN.1. Finally, detailed
design models are developed, using either SDL or UML 2.0, for each system com-
ponent. Data from the system or architectural requirements are transformed
either into SDL or UML 2.0 data types. These models are then tested and sub-
sequently transformed into code for the target application.
To support this process, a number of technologies and tools have been de-
veloped and deployed. Firstly, Motorola developed a proprietary specification
technique for data because standard languages such as ASN.1 [10] could not
readily capture the bit-level data layout schemas used in the existing protocols.
In doing so, Motorola also developed automatic code generation tools that would
not only provide efficient data marshaling (see Sect 2.3), but would also facilitate
data reuse between design and testing activities. Motorola also institutionalized
the notion of model testing using co-simulation techniques. For example, an
executable SDL or UML 2.0 design model4 is run as a simulation against an
executable test suite. This has proven to be a very effective means of ensur-
ing the correctness and quality of models, as other verification techniques (e.g.,
model checking) are not tractable for such large-scale models. After the model
correctness has been determined, automatic code generation is used to gener-
ate the necessary code for the target implementation. Finally, for component,
integration, and system testing, Motorola introduced automated test generation
tools [4] that produce test suites from scenario-based requirements.
2.3 Automatic Code Generation
Motorola has been involved in automatic code generation from models for over
15 years [5,6]. The original work was done with Structured Design models, re-
lying on an internally developed action language for the process specifications.
These design models were transformed to code through a transformation sys-
tem written in Smalltalk. While this system worked well for small projects, the
original implementation of the code generator proved not to scale well to large
infrastructure components encompassing many applications each consisting of
several hundred thousand lines of source code and was re-architected.
After the viability of modeling and automatic code generation was estab-
lished, several factors came into play:
4
Most models are currently in SDL or UML 1.x, but a general transition to UML 2.0
is being made, and products have been developed and shipped using UML 2.0.Model-Driven Engineering in a Large Industrial Context 479
– the desire to use standardized and non-proprietary modeling languages,
– the desire to scale to large projects,
– the desire to target small embedded systems such as pagers and cell phones,
– the desire to fully leverage the models for testing.
Modeling notations such as LOTOS and Z never gained popularity in the
United States, and commercial tool support for them was minimal. In addition,
the telecommunications systems being modeled were largely state-based. The
decision was therefore made to adopt SDL as the primary modeling language.
At this point, the automatic code generation efforts in Motorola split into
three separate but related paths: code for infrastructure components such as
Base Site Controllers, code for subscriber components such as pagers and cell
phones, and code for encoding and decoding communications protocols (also
called packing and unpacking, or marshaling).
Infrastructure and Subscriber Components While the basic modeling
needs for infrastructure and subscriber development are the same (i.e., state
machines, concurrent communicating processes, messages, etc.), the needs of the
generated code are vastly different. Infrastructure components typically have
powerful processors, large amounts of memory, and no power constraints. In
contrast, subscriber components typically have minimal processing power, small
amounts of memory, and severe power and battery life constraints. In addi-
tion, the infrastructure components have strict throughput, latency, capacity,
and reliability requirements, often requiring the simultaneous handling of sev-
eral thousand calls in a fault-tolerant environment. Subscriber components just
have to be fast enough to handle one call, and reliability requirements are not as
strict (that is, an entire cell site cannot go down without major consequences,
but it is not catastrophic if a cell phone drops a call).
For infrastructure components, entire subsystems are modeled in the design
language, including the detailed functionality. The models are tested and de-
bugged (see Sect. 2.4), and complete code is generated. While it is sometimes
the case that the generated code must be debugged, it is expected that the gen-
erated code is never modified—if a defect is found, the model is updated and
the code is generated again from scratch. This follows the full MDE vision.
Subscriber components generally follow more of a “round-trip” approach.
The component is modeled, but the detailed functionality is added to the model
in the target language itself (C, C++, Java, etc.). The code is generated with
the target code left in place, and the testing is done on the resulting code in a
separate application test environment. Changes are never made to the parts of
the code that are actually generated, but may be made to the embedded target
code. Once debugged, these changes are loaded back into the model.
While it could be argued that round-trip development does not truly follow
MDE concepts, there is a fine line between writing target code in a model and
writing the same functionality in a modeling language such as SDL. Often, what
is written is identical except for minor notational changes. Currently, the use of
round-trip versus “full” MDE is more for historical reasons than technical ones.480 Paul Baker, Shiou Loh, and Frank Weil
Using these techniques, Motorola has shipped many millions of lines of code
generated from SDL and UML models.
Marshaling The common ground in automatic code generation has been pro-
tocol encoding and decoding. This marshaling code entails much low-level bit
manipulation of data to decode a buffer into the realization of the abstract data
types used in the model, and vice versa for the encoding.
These types of algorithms are tedious to represent in most modeling lan-
guages, and implementation-specific details are best left out of the models. We
have found that code generators are much better than humans at finding opti-
mal and correct sequences of bit-manipulation instructions for performing the
marshaling and dealing with data from different endian machines.
Motorola makes extensive use of marshaling code generators based on exter-
nal specifications written in standard languages such as ASN.1 and on internal
specifications using a proprietary language. One major advantage, especially for
internal protocols, is that once a protocol is specified, all components using that
protocol get the generated marshaling code with no additional effort.
Motorola uses generated marshaling code integrated with hand-written C
and C++ code, with application code generated from SDL and UML models
(both from internal tools and from various vendor tools), with TTCN-2, and
with TTCN-3.
Mousetrap Motorola has developed its own automatic code generation tool
suite called Mousetrap. The Mousetrap tool suite takes as input SDL, UML,
ASN.1, and ISL (a proprietary protocol language) and produces highly optimiz-
ing code customized for a product platform and a set of performance constraints.
Mousetrap is a rule-based code transformation system driven by a vast program-
ming knowledge base. Application code has been generated for and shipped in
both infrastructure and subscriber components.
Field data has shown that code generated by Mousetrap has fewer defects
than hand code or code generated by vendor tools. This is largely due to Mouse-
trap’s ability to detect model problems that most vendor tools cannot catch,
and its ability to generate more complete code than vendor tools (e.g., all of
the platform interface code is generated). Code generated by Mousetrap is also
higher performance than code generated by vendor tools. The main reasons for
this are better optimization techniques in Mousetrap and the luxury of knowing
the target platform and being able to customize the code generation for it.
2.4 Automation Test Generation
When Motorola first deployed MDE it was observed that users were taking
scenario-based requirements and manually translating them into conformance
test suites. Hence, an automatic test script generation tool called ptk [4] was de-
veloped that would process system and architectural scenario-based models, de-
scribed using MSCs or UML 2.0 Interactions Diagrams, to generate conformanceModel-Driven Engineering in a Large Industrial Context 481 and load tests. During the development and deployment of requirements-based test generation a number of factors came into play: Lack of rigorous models for test generation. Even though it is common for system architects and designers to use scenario-based notations, they typically do not contain the rigor needed for machine processing. We also found that architects and designers were reluctant to invest the extra ef- fort needed to develop rigorous models since the benefit of automated test generation did not immediately justify the extra effort within their project scope. Hence, Motorola has been pursuing a strategy of providing static anal- ysis and automated construction tools [2,15] for scenario-based models that help reduce appraisal costs and improve productivity. Specifically, these tools enable system architects to detect errors, such as pathologies and feature in- teractions in the designs, and at the same time to infer new and consistent scenarios. Correctness of scenario-based models. It was often the case that require- ments specifications contained semantic inconsistencies leading to tests that yield invalid results. Subsequently, research effort was directed to tools to detected these inconsistencies so that they could be corrected before the ap- plication of ptk. Pathological behaviors caused by inconsistencies in commu- nication semantics were prevalent among the issues identified during various Motorola case studies. Hence, it was decided to concentrate research effort on tools that detected these kinds of pathologies. Initially research was di- rected at characterizing inconsistencies in terms of standard UML behav- ioral semantics. However, practitioners often develop systems with implicit domain-specific communication semantics that are not formally incorporated within their model. As a result, the initial version of the tool reported many errors that practitioners regarded as false positives. It became clear that the understanding of these communication semantics was important. Hence, research has been directed at automatically inferring semantic constraints needed to resolve inconsistencies in scenario-based models in a manner that can be incorporated with little effort from the practitioner. In addition, it is possible to automatically resolve certain pathological behaviors in the same way. This allows the practitioner to concentrate more on the conceptual as- pects of the design and to enable a more agile and lightweight development process overall. Test generation versus test specification. During our experience in deploy- ing test generation, it became very clear that users often did not understand the differences between test generation and test specification. For example, even though Motorola practitioners use test generation tools, they typically use them as test specification tools and hence do not gain the full bene- fits (improved test coverage, abstraction, etc.). To this end, Motorola pur- sued the development of the UML 2.0 Testing Profile and the deployment of TTCN-3. The intention is to provide a well-defined test specification and execution framework with an optional graphical modeling front-end which
482 Paul Baker, Shiou Loh, and Frank Weil
enhances the distinction between test specification and the generation of
tests from requirements. [1]
In general, test generation has proven to be very successful in: (1) the reduc-
tion of effort in developing tests, either through the use of abstraction and test
generation techniques or through the reuse of test models for different test con-
texts, (2) the improvement of test coverage, and (3) the reduction of In-Process
Faults (IPF) that classifies the number of defects introduced during the test
development process.
2.5 Successes and Failures
The initial roll-out of MDE using SDL and MSC within Motorola Europe proved
to be successful in obtaining an approximate 2.3X reduction in effort through
the use of co-simulation, automatic code generation, and model testing. As a
result, MDE gained traction within other teams within Motorola.
In general, the use of scenario-based test generation tools yields an approx-
imately 33% reduction in the effort required to develop test cases. However, in
some cases where complex modeling has been required, the use of scenario-based
models has not been appropriate. For example, using a scenario to describe the
behavior of a set of concurrent components that form part of a complex and dy-
namic system can be problematic. In such cases, specifying end-to-end scenarios
can tend toward complex scenario specifications, whereas scenarios that specify
single component behavior can lead to better reuse and understanding.
The integrated Dispatch Enhanced Network (iDEN) infrastructure division
has seen a steady trend of MDE adoption over the past nine years. Starting
with the use of SDL for one network element, iDEN has expanded its MDE us-
age to 9 out of 12 major network elements. Most of those network elements have
achieved 65%–85% code-generation, which has contributed to significant produc-
tivity and quality improvement. The degree of modeling maturity has evolved
from informal “whiteboard” modeling to formal modeling with simulation to
code generation to test-case reuse and automated marshaling code generation.
iDEN is now looking into more seamless and integrated MDE approaches with
the emphasis on providing a smoother transition between system engineering
and downstream development. At the same time, iDEN is moving from SDL to
UML 2.0. This move is consistent with tool vendor and industry trends.
In addition to the overall productivity and quality gains, Motorola has seen
tremendous gains in some phases of the development process. For example, it is
not unusual to see a 30X–70X reduction in the time needed to correctly fix a
defect detected during system integration testing. This reduction is attributed
to the ability to add a model test that illustrates the problem, fix the problem
at the model level, test the fix by running a full regression test suite on the
model itself, regenerate the code from scratch, and run the same regression test
suite on the generated code. The time it takes to do this is typically 24 hours
or less, while achieving the same quality with several hundred thousand lines of
hand code can easily take one to two months. The time needed to find the rootModel-Driven Engineering in a Large Industrial Context 483
cause of a defect has been improved in some case and worsened in others. For
example, platform interface issues can be difficult to diagnose since the observed
behavior may have no obvious correlation to the model, but subtle logic problems
in system behavior are easier to uncover in the model simulation.
One pilot project that did not succeed involved an integrated transition from
hand code to automatic code generation. The project looked into the possibility
of “cleaning up” informal SDL models, generating the code for the process and
state machine infrastructure, and directly incorporating the legacy C code for
the state machine transitions. The main reasons that the project did not suc-
ceed is that (1) the hand code made no clear distinction between these behavioral
aspects, so the effort to refactor the hand code far outweighed any potential ben-
efits, and (2) the informal models no longer corresponded to the actual behavior
of the hand code since there was no compelling reason to have kept the model
up to date.
2.6 Impact
Overall, Motorola has seen a positive impact from the adoption of MDE. The
detailed results are mixed, however, and are very difficult to use for planning
purposes. The main issue in determining impact is the lack of a common baseline.
For large-scale development projects, it is unrealistic to try to set up parallel
development environments using code generation and hand coding. Even if the
required resources for this were available, it would be difficult to account for
several factors, including experience levels in the product itself, experience in
the modeling language versus the target language, legacy code that must be
included, learning curves associated with understanding how to model, reuse
of model test cases during product testing, reuse of model components in later
development projects, and maintainability of the model versus the hand code.
In spite of the inability to determine and apply an appropriate normalizing
factor due to the above issues, Motorola has seen consistent benefits from MDE
and code generation. Typical results collected over the past few years have shown
the following benefits when compared to hand code:
Quality: a 1.2X–4X overall reduction in defects and a 3X improvement in phase
containment of defects. Also, more defects are found earlier in the develop-
ment process where they are less costly to fix. The overall Cost of Quality
has also decreased due to a decrease in inspection and testing times.
Productivity: a 2X–8X productivity improvement when measured in terms of
equivalent source lines of code.
3 Issues Encountered
The adoption of MDE within Motorola has not been without challenges. This
section lists some of the main issues encountered and the impacts they have had.484 Paul Baker, Shiou Loh, and Frank Weil
3.1 Lack of Common Tools
The ready availability of third-party and internal tools for modeling and code
generation has led to a wide diversity of processes, languages, etc. Even within a
“single” language such as UML, there are several issues such as the inability to
completely transfer models between tools, use of vendor-specific extensions, lack
of complete UML support, and code generation support for different subsets of
UML. In practice, models and skills are only marginally transferable between
different development groups.
Our experience is also that testing teams tend toward the development of
their own test tools. This leads to a variety of testing solutions which are often
duplicated, not well defined, and poorly supported. The skills developed are not
always transferable between development groups.
3.2 Lack of Abstraction
During requirements modeling we have encountered three main issues:
Platform Specifics: Often we find that system architects and designers de-
velop requirements that contain either implicit or explicit assumptions about
the implementation. We are addressing this through the promotion of Model
Driven Architecture (MDA) [14] approaches.
Incompleteness: Typically requirements are defined either through use cases
or through scenario-based models. Since only partial models are developed,
there are implications on whether technologies such as model checking can
be used to determine the correctness of requirements.
Quality: Determining the adequacy of requirements is a common concern. We
are addressing this through the promotion of a top-down process and the use
of metrics and reliability models to determine the quality of requirements [8].
3.3 Lack of Well Defined Semantics
Motorola projects have encountered issues with language semantics with virtu-
ally every modeling language used. For example, SA/SD had no defined process
language and advocated natural language, tool vendors have added their own
language extensions, and even UML 2.0 contains semantic variation points. The
situation has improved drastically over the past decade, but local conventions
are still used and the exact meaning of a model often is dependent on the tool
in which it was created.
During the construction of models, implicit assumptions are also made about
domain semantics. For example, the type of semantics given to the communi-
cation between system components may be token passing, First-In First-Out,
synchronous/asynchronous, etc. To this end, a mechanism is needed to allow
the user to define domain-specific communication constraints that are consid-
ered during the construction and transformation of models. An initial UML 2.0
profile, called the Communication constraint UML Profile (CUP) [2], has beenModel-Driven Engineering in a Large Industrial Context 485
developed by Motorola Labs and can be used for specifying domain-specific com-
munication constraints with UML 2.0 Composite Structure Diagrams. CUP is
still being developed, but the intention is to standardize this within the OMG.
3.4 Coupling of Data and Behavior
With modeling languages such as SDL and MSC, the specification of data values
is tightly coupled with the behavior specification. For example, when an SDL
signal is sent between processes, the value of the signal is defined within the
behavior of each process. This means that when the signal type is modified, each
behavior definition must also be modified, resulting in a very large maintenance
burden for engineering teams. This also means that value definitions cannot be
reused between specification, design, and testing. By providing mechanisms for
decoupling data from behavior specification, we have seen very positive results.
With UML 2.0 we promote the use of instance modeling as a key strategy for
data reuse and reduced model maintenance. An instance is a run-time entity
with an identity that is distinguishable from other run-time entities. Hence,
instance modeling refers to the creation of “signal” instances as objects that can
be referenced and defined in an independent manner.
3.5 Poor Performance of Tools and Generated Code
Third-party MDE tools often do not scale well to the sizes needed for modeling
real telecommunications systems. We have encountered issues with the ability
of tools to load, save, compare, and generate code from large models. This has
become less of an issue as computing power increases, but it is far from solved.
We have also encountered performance issues with the generated code. When
using third-party tools with limited ability to customize the code generation, it
can be extremely frustrating to address performance bottlenecks.
3.6 Lack of Integrated Tools
No single tool supports a comprehensive MDE environment, allowing full use of
current tools and processes. To this end, integration of modeling concepts and
tools becomes problematic. For example, during the transformation of models
to code, how is traceability handled if a separate traceability tool is used?
3.7 Team Inexperience
We have observed that many teams encounter major obstacles in adopting MDE
due to the lack of a well defined MDE process, missing skill sets, and inflexibility
in changing the existing culture. Without a well defined MDE process, teams
that adopt MDE tend to use a “trial and error” approach and encounter the
same set of pitfalls others have already experienced. Skill sets related to MDE486 Paul Baker, Shiou Loh, and Frank Weil
includes mastery of formal languages, modeling, simulation, tools, code gener-
ation, model performance improvement, testing automation, and proper parti-
tioning of architectural and design views (specific MDE training requirements
are being identified as part of the effort described in Sect 4.3). Often the per-
ceived required skill set is daunting for many teams; some do not even attempt
MDE due to lack of the required skill sets. Adopting MDE without an appro-
priate cultural change has also caused many “painful” experiences. While some
development process changes could be documented and enforced, other manage-
ment and development cultural changes are hard to identify and much harder to
enforce. One example of inflexibility in cultural changes is the tendency to tune
performance through embedding pointer-manipulation code in the models, thus
opening the door to the same problems encountered in hand code.
3.8 Lack of Migration Tools
Motorola is migrating from SDL-based modeling to UML-based modeling. How-
ever, a large number of legacy SDL-based models exist from more than a decade
of SDL-based development. To facilitate the move to UML, migration tools are
needed that support not only the main behavioral models, but also the asso-
ciated modeling artifacts such as test cases and MSCs. The current migration
tools are inadequate, and this impacts software development.
There is a significant cost of migration which is difficult to justify in terms of
return on investment (ROI). Migrating existing software already in the field is
in general a risky endeavor with low ROI. The lack of comprehensive migration
tools exacerbates the problem.
There is also a limit to the benefit of MDE under a heterogeneous develop-
ment environment. With large software system consisting of both legacy SDL
and new UML models, there is no tractable way to co-develop the entire system.
Because of this, it is difficult to achieve consistent benefits from simulation and
consistency checking.
3.9 Lack of Scalability
We have observed that the current state of corporate MDE usage is characterized
by isolated models. For example, even in a highly coupled system such as iDEN,
each model exists separately. That is, they interact with each other only in the
target network and are neither currently being modeled as a whole nor being
leveraged for simulation and consistency checking as a whole.
The challenges of MDE with respect to model scalability are:
Distributed development: Almost all large systems are developed by sepa-
rately managed teams that are also geographically separated. MDE adds
another dimension to the distributed development because in order to take
advantage of MDE at the whole system level, one needs to build the sub-
systems interfaces at the model level (not just at the target level). TheModel-Driven Engineering in a Large Industrial Context 487
model-level subsystem interfaces are new and often ill-defined mainly be-
cause of the difficulty in abstracting only model-level messaging without
complications from lower-levels transport and network layers.
Information Overload: Modeling a large system such as the entirety of a
cellular network is usually very complicated mainly because there are no
straightforward ways of hiding detailed information at the right place in
design, simulation, and presentation.
Legacy Software: Modeling a large system often requires the new models to
interact with legacy software. It is normally not feasible to model a whole
system such as cellular network because it is too costly to create stubs that
replace the existing legacy software during modeling.
Tool Performance: Most MDE tools suffer from modeling performance when
the system under development is large. The problem most often appears in
simulating a large system such as an entire cellular network.
4 Addressing the Issues
This section presents some strategies Motorola is pursuing to optimized its use
of MDE while addressing some of the shortcomings presented earlier.
4.1 UML 2.0 Profiles
Profiles provide a powerful tool for the specialization of UML 2.0. In particular,
to address issues raised earlier in the paper, Motorola is currently using and/or
creating several profiles:
SDL Profile This profile fills the semantic variation points in UML 2.0 and
provides continuity with development that has been based on SDL.
Testing Profile (U2TP) This profile provides a means for defining test spec-
ifications that can be mapped onto TTCN-3 and JUnit test cases. In doing
so, our aim is not only to provide testing tools that are tightly integrated
with UML 2.0 model construction tools, but also to enable reuse of UML 2.0
models within the construction of tests.
System Engineering Profile (SysML) This profile provides common nota-
tions for systems engineering applications.5
Domain Specification Communication Constraints (CUP) This profile
allows system architects and designers to specify domain-specific constraints
explicitly as part of their models.
4.2 MDE Technical Advisory Board
The Motorola MDE Technical Advisory Board (MDE TAB) is the leadership
organization for an effort focused on the tool/software development discipline
5
SysML is not (yet) a UML 2.0 Profile in the strict definition.488 Paul Baker, Shiou Loh, and Frank Weil
deployed within Motorola. The focus of the MDE TAB is to provide a coor-
dinated point of interaction with MDE tool vendors regarding their modeling
and software development tools for Motorola global operations and to provide
a central organization responsible for collecting and distributing MDE-related
standards, metrics, etc.
The purpose of the MDE TAB is to:
– Develop enterprise technical requirements and Motorola-wide solutions.
– Identify and prioritize long-term deployment problems and enhancements.
– Determine the best approaches for addressing problems and requirements.
– Identify training, best practices, policies, and procedures related to MDE
tools and processes.
– Determine business impact metrics to measure the prioritized efforts.
– Identify and prioritize tool integration requirements.
– Coordinate with other Motorola teams related to MDE tool usage.
– Manage the supplier relationships.
4.3 Modeling Challenge Levels
As discussed in Sect. 3, we have encountered many MDE-associated challenges
such as ill-defined process, lack of required skill sets, etc. To overcome the chal-
lenges, an organization needs wide-ranging capabilities. However, it is not realis-
tic for any organization to acquire those capabilities in one single effort. Most, if
not all, development organizations need time to build their maturity with respect
to the deployment of MDE.
Over the years, MDE practitioners have found that they went through dif-
ferent stages of modeling experiences, each stage with its distinctive benefits,
challenges, and opportunities. Most MDE teams go through these stages be-
fore truly mastering MDE and its process. However, the documentation of those
stages is incomplete or nonexistent, causing difficulty in sharing modeling ex-
perience among development organizations across the corporation. The planned
continued growth of MDE in Motorola drives the need to define a framework of
these stages (or levels). This framework must facilitate the sharing of experience,
which includes tools, methodologies, best practices, processes, etc.
The framework Motorola is developing, called Modeling Challenge Levels
(MCL), is created under a task force sponsored by the MDE TAB (see Sect. 4.2).
The main purposes of the MCL are:
– To provide a framework for sharing MDE experience across the corporation.
This is accomplished through defining the levels of modeling maturity based
on the collective recommendation of MDE expert practitioners. The MCL
provides an environment to promote the best practices in MDE, relying on
local innovation for best practices while providing access to a corporate-wide
experience base.
– To provide guidelines for creating a local MDE roadmap.Model-Driven Engineering in a Large Industrial Context 489
– To serve as a self-assessment tool with respect to an organization’s modeling
maturity. A solid understanding of the current MDE capabilities of an orga-
nization enables it to acquire the right MDE resources, plan improvements
through gap analysis, understand anticipated challenges and benefits, and
share experience effectively with other groups.
MCL describes modeling maturity in six levels (from least to most mature):
1. No Modeling
2. Informal Modeling
3. Formal Modeling
4. Model-Centered Design
5. Model-Driven Engineering
6. Optimized Model-Driven Engineering.
4.4 MDE Qualification
Existing qualification approaches such as UML 2.0 certification only assess a
level of knowledge about a particular modeling language. The purpose behind
MDE qualification is to provide a formal structure, as well as incentives, for
the education and sharing of MDE skills and experience in a more systematic
manner. It attempts to do this in a staged and generic fashion, thereby allowing
managers and developers to learn and practice key skills that are appropriate to
their application and development domain. For example, verifying model correct-
ness is a generic and fundamental MDE activity, but how this is performed can
depend upon the context of a particular development project. Hence, the empha-
sis is to build an appreciation of and experience with the core concepts needed
for successful MDE while at the same time allowing flexibility on the specific
techniques and technologies used. By introducing formality into the education
of MDE, Motorola can build up a network of MDE experts that collectively
provide feedback for future MDE strategies.
The plan is to build formalized MDE expertise through the introduction of
staged MDE qualifications. This provides a formal means for sharing knowledge
and experiences between development teams, thereby reducing the risk in adopt-
ing MDE technologies. For example, it could be that for the first trial of MDE
within a particular development team, the project should be supported by at
least one experienced MDE expert. We do not present a comprehensive list of
ideas in this paper, but we do provide some idea of what we consider important
criteria for the staged qualification of MDE expertise:
Stage 1 Core MDE concept training and experience, including modeling, veri-
fication and validation, and process and measurement.
Stage 2 Further specialized training and experience, including several MDE
languages, hardware and enterprise modeling, formal verification techniques,
transformation techniques, and mentoring of Stage 1 projects.
Stage 3 Advanced training and experience, including demonstrations of model-
ing within different contexts, leadership in evaluating new MDE technologies,
mentoring, and knowledge sharing.490 Paul Baker, Shiou Loh, and Frank Weil 4.5 Corporate-Level Tool Selection Committee Motorola formed a one-time tool selection committee to evaluate the UML tools from third-party vendors and provide a recommendation on which one(s) should be used within Motorola. Each Motorola group engaging in MDE had represen- tation on the committee, and it was the responsibility of the representatives to collect and prioritize the requirements from their respective groups. Based on the collated requirements, tools from the major vendors were evaluated on how well they met the few-hundred weighted requirements. The committee was able to narrow the officially sanctioned modeling tools to two choices. The evaluation of new and updated MDE tools is initiated through the MDE TAB (see Sect 4.2). 4.6 MDE Technology Improvement Motorola continues to invest in MDE technology improvement ranging from automation technologies (including secure code generation, test generation, and model testing), metrics, profile development, meta-modeling, and analysis tools. 5 Conclusion We have presented an overview of the MDE-related activities in Motorola. In one form or another, Motorola has been active in MDE for nearly two decades and has seen incredible successes and glaring failures. We have found that through the coordinated and controlled introduction of MDE techniques, significant quality and productivity gains can be consistently achieved, and the issues encountered can be handled in a systematic way. References 1. Baker, P.: Test Generation towards TTCN-3. ETSI TTCN-3 User Conference (2004) 2. Baker, P., Burton, S., Bristow, P., King, D., Jervis, C., Mitchell, B., Thomson, R.: Detecting and Resolving Semantic Pathologies in UML Sequence Diagrams. ACM ESEC-Foundations of Software Engineering (2005) 3. Baker, P., Dai, Z., Grabowski, J., Haugen, O., Samuelsson, E., Schieferdecker, I., Williams, C.: The UML 2.0 Testing Profile. In: Proc. of the Conf. on Quality Engi- neering in Software Technology 2004. Nuremberg, Germany (2004) 4. Baker, P., Jervis, C., King, D.: An Industrial use of FP: A Tool for Generating Test Scripts from System Specifications. In: Trinder, P., Michaelson, G., Loidl, H-W. (eds.): Trends in Functional Programming, Vol. 1. Intellect (2000) 126-135 5. Boyle, J., Harmer, T., Weigert, T., Weil, F.: Knowledge-Based Derivation of Pro- grams from Specifications. In: Bourbakis, N. (ed.): Artificial Intelligence And Au- tomation. World Scientific Press (1996) 6. Dietz, P., Weigert, T., Weil, F.: Formal Techniques for Automatically Generating Marshalling Code from High-Level Specifications. In: Proc. of the 1998 Workshop on Industrial-strength Formal Specification Techniques. Boca Raton, FL (1998)
Model-Driven Engineering in a Large Industrial Context 491 7. European Telecommunications Standards Institute: Methods for Testing and Spec- ification; The Testing and Control Notation version 3 (TTCN-3); Part 1: TTCN-3 Core Language. ETSI ES 201 873-1 (2001) 8. Gras, J., McGaw, D.: End-to-End Defect Prediction. In: IEEE International Sym- posium on Software Reliability Engineering (ISSRE). Saint Malo, France (2004) 9. Hatley, D., Pirbhai, I.: Strategies for Real-Time System Specification. Dorset House, New York (1988) 10. International Telecommunications Union: Abstract Syntax Notation One (ASN.1): Specification of Basic Notation. ITU-T Rec. X.680 (2002) 11. International Telecommunications Union: Message Sequence Chart (MSC). ITU-T Rec. Z.120 (2000) 12. International Telecommunications Union: Specification and Description Language. ITU-T Rec. Z.100 (2000) 13. International Telecommunications Union: TTCN-2 standard, Conformance Testing Methodology and Framework: Part 3: The Tree and Tabular Combined Notation (TTCN). ITU-T Rec. X.292 (1997) 14. Kleppe, A., Warmer, J., Bast, W.: MDA Explained: The Model Driven Architec- ture: Practice and Promise. Addison-Wesley (2003) 15. Mitchell, B., Thomson, R., Jervis, C.: Phase Automaton for Requirements Scenar- ios. In: Feature Interactions in Telecommunications and Software Systems VII. IOS Press (2003) 77–84 16. Object Management Group: Unified Modeling Language (UML): Superstructure, Version 2.0 (2003)
You can also read
