Mechanisms for Requirements Driven Component Selection and Design Automation 최경석

Content 2 Nomenclature Introduction Related Work RDDA Framework Architecture Component selection and architecture synthesis Result Conclusions

Nomenclature 3 CLPConstraint Logic Programming KBKnowledge Base OWLOntology Web Language RDDARequirements-Driven Design Automation SysMLSystems Modeling Language XMIXML Metadata Interchange XMLExtensible Markup Language XSLTExtensible Stylesheet Language(XSL) Transformations

Introduction 4 Architecture selection during system design is a time consuming activity  Manual checking of existing components  Mapping system requirements to available subsystems or components  Choosing the optimal subset that satisfy the specification Methodology for automated design synthesis  partially automating the process of architecture synthesis Requirements-Driven Design Automation(RDDA) framework  Reduce the development cost and time  adapts a SysML modeling tool for requirements specification and design modeling Concepts of Model-Driven Engineering  Requirements-driven Domain-specific language called the OPP Design Language (ODL)  Covers the requirements domain for mobile systems

Related Work 5 A Framework for Declarative Queries and Automatic Data Interpretation Microsoft Research  a framework called Semantic Streams in which a user can take advantage of declarative statements to query a sensor network.  These services are converted to rules with pre- and post-conditions and the inference engine uses backward chaining to match every element of the query with the post- condition of a service. Requirements Engineering and the Semantic Web: Part II. Representation, Management, and Validation of Requirements and System-Level Architectures  validation of the system architecture based on ontologies and reasoning. Model level coupling of heterogeneous embedded systems  The main idea behind this approach is the model-based coupling of heterogeneous subsystems provided by the GeneralStore tool.

RDDA Framework 6 Requirements workflow Design workflow

RDDA Framework 7 Modeling requirements using SysML Requirements workflow

RDDA Framework 8 Export to XMI Requirements workflow

RDDA Framework 9 Convert to OWL using XSLT Requirements workflow

RDDA Framework 10 OWL statements transform into Prolog facts Requirements workflow

RDDA Framework 11 Requirements workflow Validate the requirements

RDDA Framework 12 If errors exist Requirements workflow

RDDA Framework 13 Describing system components using SysML Block Definition Diagrams Design workflow

RDDA Framework 14 Design workflow Export to XMI

RDDA Framework 15 Design workflow Convert to OWL using XSLT

RDDA Framework 16 Design workflow Select the right components

Component selection and architecture synthesis 17 Initial component diagram  Location-based system

Component selection and architecture synthesis 18 Initial component diagram  Location-based system Provided interface

Component selection and architecture synthesis 19 Initial component diagram  Location-based system Required interface

Component selection and architecture synthesis 20 Initial component diagram  Location-based system

Component selection and architecture synthesis 21 Initial component diagram  Location-based system

Component selection and architecture synthesis 22 Convert to OWL  SysML Diagram is exported to a standard XMI format  XMI model is translated into OWL  OWL model is expressed with the concepts and properties from the ODL ontology

Component selection and architecture synthesis 23 Prolog  Declarative logic programming language formal logic  Consists of a series of facts and rules Stored in a database called a Knowledge Base(KB)  The main goal is to answer queries  Example Facts : father(john, megan); father(john, david); male(david). Rules : son(X, Y) : – father(Y, X), male(X) Query : ? – son(david, john) Result : true

Component selection and architecture synthesis 24 Prolog  An advantage of Prolog Provides backward chaining  Example Facts : father(john, megan); father(john, david); male(david). Rules : son(X, Y) : – father(Y, X), male(X) Query : ? – son(X, john) Check1 : father(john, megan), male(megan) => fail Check2 : father(john, david), male(david) => true Result : X(david)  Backtracking is also useful for finding more than one solution to a query  SWI-Prolog Provides a library that facilitates constraint programming called CLP  CLP Expr1# =< Expr2 (Expr1 is smaller than or equal to Expr2)

Component selection and architecture synthesis The Architecture Synthesis Algorithm  All loaded in the KB Requirements models, design models, semantic component annotations  comp(component) defines one component  compReq(c,i) component c requires (uses) interface i  compProv(c,i) component c provides interface i  compReqsFeature(c,f) component c requires feature f  compProvFeature(c,f) component c provides feature f  compReqsQoS(c,q,v1,v2) component c requires QoS numeric constraint between v1 and v2  compProvQoS(c,q,v1,v2) component c provides QoS numeric constraint between v1 and v2 25

Component selection and architecture synthesis The Architecture Synthesis Algorithm  Algorithm 1. Find initial components that match the required interfaces 26

Component selection and architecture synthesis The Architecture Synthesis Algorithm  Algorithm 2. Check if the required features and constraints have been met by the components from the previous step 27

Component selection and architecture synthesis The Architecture Synthesis Algorithm  Algorithm 3. If there are featrues or constraints not provided by the components in the solution, check if there are other components that provide those missing features 4. Return a list S of edges ci(CR, I, CP) Return a list of features cpf(CR, F, CP) Return a list of features that are not provided by any existing component 28

Component selection and architecture synthesis The Architecture Synthesis Algorithm  Algorithm QoS constraint 29

Component selection and architecture synthesis The Architecture Synthesis Algorithm  Algorithm sorted by the solution for which all features and constraints have been satisfied The reason we chose to present solutions to users in this way is because of the assumption that when a new product (or new version of a product) is constructed, there will likely be features/constraints not satisfied by the components used in previous products (or versions). 30 Solution 1Solution 2Solution 3

Result Example 31

Result Example  Best Solution [ci(camera, iImageEncoder, canon), ci(gps, iLocationService, ti), ci(phone, iCamera, camera), ci(phone, iGPS, gps), ci(dummy, iPhone, phone)], [], [], [], [].  Another Solution [ci(camera, iImageEncoder, olympus), ci(gps, iLocationService, sirf), ci(phone, iCamera, camera), ci(phone, iGPS, gps), ci(dummy, iPhone, phone)], [cpf(gps, fProximityService, ti), cpf(camera, fGIFImageFormat, canon)], [], [cc(qosLocationError, ti)], []. 32

Result RDDA Framework  This model is then converted to an XMI file and merged as a SysML structural diagram with the user’s SysML design project  The resulting XMI project file is reloaded by the SysML modeling tool and the designer now can further refine it, or turn it to code generation 33

Conclusions The large design search space could be too large to handle for people  To satisfy Functional and QoS requirements  Our systems implements an automated search method looking for feasible configurations The generated diagram is added to the project and is loaded back into the modeling tool  provides users with information identifying the requirements and constraints that cannot be satisfied  The user can then go back and adjust the requirements model or add components to the model Future work  consider modeling the behavioral part of a system, by using specific SysML diagrams  A long-term goal is to integrate all tools for requirements modeling and validation, component selection, and design composition, into a common visual modeling tool based on the Eclipse platform. 34

35 Q & A