An Introduction to Using AWS and ASK to Build Voice Driven Experiences
Experiences from Representing Software Architecture in a Large Industrial Project Using Model Driven...
description
Transcript of Experiences from Representing Software Architecture in a Large Industrial Project Using Model Driven...
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