Experiences from Representing Software Architecture in a Large Industrial Project Using Model Driven

1
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
1 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
2
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.

3
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

4
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.

5
MDD Tools and Approaches

• Object Management Groups
• MDA Model-Driven Architecture
• Domain-Oriented Programming
• Model-Driven Engineering
• Microsofts
• Software Factories

6
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

7
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

8
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

9
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.

10
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

11
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

12
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

13
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

14
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 didnt capture architecture rules in a
  formal model natural language was needed to
  express the rules

15
Capturing Architecture Cont

• Example of natural language expression
• 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

All specializations of arcPort may have several
methods for the method Ctrl(). These methods
shall be named as ctrl_ltspecific_namegt 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.
16
Architectural Framework
17
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

18
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

19
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