Successfully reported this slideshow.

03 How to Keep Domain Requirements Models Reasonably Sized

627 views

Published on

  • Be the first to comment

  • Be the first to like this

03 How to Keep Domain Requirements Models Reasonably Sized

  1. 1. How to Keep Domain Requirements Models Reasonably Sized Hans W. Nissen , Dominik Schmitz, Matthias Jarke, Thomas Rose (Fraunhofer FIT) ZAMOMO project context “Integration of model-based software and model-based control systems engineering“
  2. 2. Agenda <ul><li>Motivation and problem characterization </li></ul><ul><li>Environment: Domain model-based RE for Controllers </li></ul><ul><li>Extending the domain model </li></ul><ul><li>Reducing the domain model </li></ul><ul><li>Conclusions & future work </li></ul>MaRK‘09, Atlanta slide
  3. 3. Motivation: Requirements Engineering in Control System Development <ul><li>Problem for SMEs: customer-oriented development </li></ul><ul><ul><li>RE is part of offer development </li></ul></ul><ul><ul><li>Short time frame </li></ul></ul><ul><li>Solution: Domain-model based requirements engineering </li></ul><ul><ul><li>Domain model captures SME-specific knowledge and experiences </li></ul></ul><ul><ul><li>Fast requirements capture [RE’08, MaRK’08] </li></ul></ul><ul><li>Domain model evolves over time </li></ul><ul><ul><li>Keep it reasonably sized </li></ul></ul><ul><ul><ul><li>Adequate for daily work </li></ul></ul></ul><ul><ul><li>Derive proposals from previous experiences/projects </li></ul></ul>MaRK‘09, Atlanta slide
  4. 4. Domain Model-Based RE for Controllers with i* MaRK‘09, Atlanta slide <ul><li>Common starting point accelerates modeling </li></ul><ul><ul><li>Eliminate non-applicable elements </li></ul></ul><ul><ul><li>Add project-specific elements </li></ul></ul><ul><li>Too big or too small domain models hamper </li></ul><ul><li>requirement capture </li></ul>
  5. 5. Extending the Domain Model <ul><li>Source: project-specific extensions in requirements models </li></ul><ul><li>Candidates: </li></ul><ul><ul><li>Similar project-specific extensions introduced several times </li></ul></ul><ul><li>Computation in 5 steps </li></ul><ul><ul><li>Identify project-specific extensions </li></ul></ul><ul><ul><li>Compute similarity between them </li></ul></ul><ul><ul><li>Group similar extensions </li></ul></ul><ul><ul><li>Inspection and implementation by engineer </li></ul></ul><ul><ul><li>Store results </li></ul></ul>MaRK‘09, Atlanta slide
  6. 6. Step 1: Identification of Project-Specific Extensions <ul><li>For a requirements model of a finalized project </li></ul><ul><ul><li>Identify all elements not originating from domain model </li></ul></ul><ul><ul><li>Group directly connected elements together </li></ul></ul><ul><ul><ul><li>=> Candidates for project-specific extensions </li></ul></ul></ul><ul><li>Inspection by engineer </li></ul><ul><ul><li>Combine unconnected extensions that belong together </li></ul></ul><ul><li>Identification of anchor objects for each extension </li></ul><ul><ul><li>Objects of domain model connected to added objects </li></ul></ul>MaRK‘09, Atlanta slide Extension 1+2 Extension 1+2
  7. 7. Step 2: Computing a Similarity Measure <ul><li>“ Similar project-specific extensions share anchor objects” </li></ul><ul><ul><li>Identical or </li></ul></ul><ul><ul><li>Part of common refinement hierarchy </li></ul></ul><ul><li>Compute refinement paths </li></ul>MaRK‘09, Atlanta slide Extension of Engineer B Extension of Engineer A Engineer Anchor Objects Refinement Path A A1: controller {controller, control cycle} A2: controlled system {controlled system , control cycle} B B1: controller {controller , control cycle} B2: injection {injection, controlled system , control cycle}
  8. 8. Step 2: Computing a Similarity Measure <ul><li>Similarity between anchor objects of two extensions </li></ul><ul><li>1 / distance to nearest anchor object on common refinement hierarchy </li></ul><ul><li>0 if no common refinement hierarchy </li></ul>MaRK‘09, Atlanta slide Anchor Objects Refinement Path A1: controller {controller, control cycle} A2: controlled system {controlled system, control cycle} B1: controller {controller, control cycle} B2: injection {injection, controlled system, control cycle}
  9. 9. Step 2: Computing a Similarity Measure <ul><li>Similarity between two extensions </li></ul><ul><li>Relate the similarity of anchor objects to total number of anchor objects </li></ul><ul><ul><li>1 – if all anchor objects are identical </li></ul></ul><ul><ul><li>0 – if no anchor objects on common refinement hierarchy </li></ul></ul>MaRK‘09, Atlanta slide Anchor Objects Refinement Path A1: controller {controller, control cycle} A2: controlled system {controlled system, control cycle} B1: controller {controller, control cycle} B2: injection {injection, controlled system, control cycle}
  10. 10. Steps 3, 4 and 5 <ul><li>Step 3: Grouping of Similar Extensions </li></ul><ul><li>Group extensions with similarity measure above threshold </li></ul><ul><li>Step 4: Decision Making by an Engineer </li></ul><ul><li>Engineer re-organizes groups if necessary </li></ul><ul><li>Engineer selects group(s) to extend domain model </li></ul><ul><li>Step 5: Storing of Results </li></ul><ul><li>Results of all steps recorded in KB </li></ul><ul><ul><li>Basis for incremental computation </li></ul></ul>MaRK‘09, Atlanta slide
  11. 11. Reducing the Domain Model <ul><li>“ If an element has not been used in the last X projects, suggest its banishment” </li></ul><ul><ul><li>X is SME specific </li></ul></ul><ul><li>Short outline </li></ul><ul><ul><li>Compute elements not used within last X requirements models </li></ul></ul><ul><ul><li>Engineer decides on proposals </li></ul></ul><ul><ul><li>Automatic deletion of elements from domain model possible </li></ul></ul>MaRK‘09, Atlanta slide
  12. 12. Conclusions and Future Work <ul><li>Contributions: Keep domain models focused </li></ul><ul><li>Experience-based proposals for domain model modification </li></ul><ul><li>Similarity measures for project-specific extensions </li></ul><ul><li>Implemented in Telos/ConceptBase </li></ul><ul><li>Future work </li></ul><ul><li>Improvement of similarity measure </li></ul><ul><li>Evaluate quality of proposals by case study </li></ul>MaRK‘09, Atlanta slide
  13. 13. Appendix
  14. 14. Telos and ConceptBase <ul><li>Telos [Mylopoulos et al., 1990] </li></ul><ul><li>Formal knowledge representation language </li></ul><ul><li>Capture knowledge on information system development </li></ul><ul><li>Extensible by meta-modeling, tailor to specific domains </li></ul><ul><li>ConceptBase [Jarke et al., 1995] </li></ul><ul><li>Implementation of Telos </li></ul><ul><li>Object-oriented deductive database </li></ul><ul><li>Additional features: </li></ul><ul><ul><li>Query concept – query as class, answers as instances </li></ul></ul><ul><ul><li>Generic queries – parameters </li></ul></ul><ul><ul><li>Functions – predefined queries for counting, summing up etc. </li></ul></ul><ul><ul><li>Modules – introduce several non-conflicting namespaces </li></ul></ul><ul><ul><li>Active rules – events trigger actions in KB </li></ul></ul>MaRK‘09, Atlanta slide
  15. 15. Automatic Numbering of Projects <ul><li>FinalisedProjects with </li></ul><ul><li>attribute </li></ul><ul><li>seq_number : Integer </li></ul><ul><li>end </li></ul><ul><li>ECArule ProjectNumberRule with </li></ul><ul><li>ecarule </li></ul><ul><li>er : $ x/FinalisedProjects </li></ul><ul><li>i,i1/Integer </li></ul><ul><li>ON Tell(In(x,FinalisedProjects)) </li></ul><ul><li>IF (i = COUNT(FinalisedProjects)) </li></ul><ul><li>DO i1 = IPLUS(i,1) </li></ul><ul><li>Tell(A(x,seq_number,i1)) </li></ul><ul><li>ELSE Tell(A(x,seq_number,1))$ </li></ul><ul><li>end </li></ul>MaRK‘09, Atlanta slide
  16. 16. Identification of last X Projects <ul><li>GenericQueryClass ConsideredProjects isA </li></ul><ul><li>FinalisedProjects with </li></ul><ul><li>parameter </li></ul><ul><li>size : Integer </li></ul><ul><li>constraint </li></ul><ul><li>c : $ exists n/Integer (this seq_number n) </li></ul><ul><li>and </li></ul><ul><li>(n > IMINUS(COUNT(FinalisedProjects),~size))$ </li></ul><ul><li>end </li></ul>MaRK‘09, Atlanta slide
  17. 17. Identify unused Concepts in Previous Projects <ul><li>QueryClass AllConcepts isA Token with </li></ul><ul><li>constraint </li></ul><ul><li>c1 : $In@DomainModel(this, Token)$ </li></ul><ul><li>end </li></ul><ul><li>GenericQueryClass UnusedConcepts isA AllConcepts with </li></ul><ul><li>parameter </li></ul><ul><li>x : Integer </li></ul><ul><li>constraint </li></ul><ul><li>c2 : $forall m/ConsideredModules[~x/size] </li></ul><ul><li>NotUsedIn[this/concept, m/module]$ </li></ul><ul><li>end </li></ul>MaRK‘09, Atlanta slide
  18. 18. Identify unused Concept in one Model <ul><li>GenericQueryClass NotUsedIn isA Boolean with </li></ul><ul><li>parameter </li></ul><ul><li>concept : Token; </li></ul><ul><li>module : Module </li></ul><ul><li>constraint </li></ul><ul><li>c3 : $not(In@~module(~concept,Token)) </li></ul><ul><li>and (this = TRUE)$ </li></ul><ul><li>end </li></ul>MaRK‘09, Atlanta slide
  19. 19. Computing refinement between anchor objects: Definition of computed attribute super <ul><li>IStarElement with </li></ul><ul><li>attribute </li></ul><ul><li>super : IStarElement </li></ul><ul><li>rule </li></ul><ul><li>superRule : </li></ul><ul><li>$forall c/IStarElement p/IStarElement </li></ul><ul><li>(((c in IStarIntentionalElement) and </li></ul><ul><li>((exists dl/IStarDecompositionLink </li></ul><ul><li>(dl to c) and (dl from p)) </li></ul><ul><li>or (exists ml/IStarMeansEndsLink </li></ul><ul><li>(ml from c) and (ml to p)) </li></ul><ul><li>or ((not exists ml/IStarMeansEndsLink </li></ul><ul><li>(ml from c)) and </li></ul><ul><li>(not exists dl/IStarDecompositionLink </li></ul><ul><li>(dl to c)) and </li></ul><ul><li>(c parent p)))) </li></ul><ul><li>or ((c in IStarActorElement) and </li></ul><ul><li>(exists pl/IStarPartsLink </li></ul><ul><li>(pl from c) and (pl to p)))) </li></ul><ul><li>==> (c super p)$ </li></ul><ul><li>end </li></ul>MaRK‘09, Atlanta slide
  20. 20. Computing refinement between anchor objects: computation of transitive closure of super <ul><li>GenericQueryClass SuperElements </li></ul><ul><li>isA IStarElement with </li></ul><ul><li>parameter </li></ul><ul><li>src : IStarElement </li></ul><ul><li>constraint </li></ul><ul><li>c : $(~src = this) or (~src super this) </li></ul><ul><li>or (exists e/IStarElement </li></ul><ul><li>(e in SuperElements[~src/src]) </li></ul><ul><li>and (e super this))$ </li></ul><ul><li>end </li></ul>MaRK‘09, Atlanta slide
  21. 21. Similarity Measure <ul><li>Formalization of similarity between anchor objects : </li></ul><ul><li>E 1 and E 2 project-specific extensions </li></ul><ul><li>We define two functions </li></ul>MaRK‘09, Atlanta slide
  22. 22. Similarity Measure <ul><li>Formalization of similarity between extensions : </li></ul><ul><li>E 1 and E 2 project-specific extensions </li></ul><ul><li>sim() is symmetric </li></ul>MaRK‘09, Atlanta slide

×