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

Björn Lundell2Brian Lings2

Brian Fitzgerald3

1 Combitech AB, P.O. Box 1017, SE-551 11 JÖNKÖPING, Sweden2 University of Skövde, P.O. Box 408, SE-541 28 SKÖVDE, Sweden3 Lero – the Irish Software Engineering Research Centre University of Limerick, Ireland

Presented by: Karo Mazidzhyan

Role of ArchitectureRole of ArchitecturePrimary role of architecture is to

capture:◦design decisions◦rules which are to be followed in detailed

designAllow 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 PaperPurpose of this PaperModel-Driven Development is an

emerging disciplineThe 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 Model-Driven DevelopmentDevelopmentMDD

◦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 MDD Tools and ApproachesApproachesObject Management Group’s

◦MDA – Model-Driven ArchitectureDomain-Oriented ProgrammingModel-Driven EngineeringMicrosoft’s

◦Software Factories

Paper BackgroundPaper BackgroundDescribe Experiences from a large projectTask

◦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 ChallengesDevelopment ChallengesShort time-to-market

◦Competition with other developersIntegration 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…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 efficientlyCompetition

◦Products would compete on performance and quality to win the final contract

Rationale for Choosing Rationale for Choosing MDDMDDCS, 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…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…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…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 Capturing of the ArchitectureArchitectureProduct 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 Capturing Architecture Cont…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 Capturing Architecture Cont…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_<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.”

Architectural Framework

Lessons LearnedLessons LearnedManual 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

SummarySummaryMDD 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…Summary Continued…Late changes are hard to make

◦architectural rules are manually introduced

◦Involves massive reworkingTo 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