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

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 Group’s • MDA – Model-Driven Architecture • Domain-Oriented Programming • Model-Driven Engineering • Microsoft’s • 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 didn’t 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_<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.”

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