How to Keep Domain Requirements Models Reasonably Sized Hans W. Nissen , Dominik Schmitz,  Matthias Jarke, Thomas Rose (Fr...
Agenda <ul><li>Motivation and problem characterization </li></ul><ul><li>Environment: Domain model-based RE for Controller...
Motivation: Requirements Engineering in  Control System Development <ul><li>Problem for SMEs: customer-oriented developmen...
Domain Model-Based RE for Controllers with  i* MaRK‘09, Atlanta  slide  <ul><li>Common starting point accelerates modeling...
Extending the Domain Model <ul><li>Source: project-specific extensions in requirements models </li></ul><ul><li>Candidates...
Step 1: Identification of Project-Specific Extensions <ul><li>For a requirements model of a finalized project </li></ul><u...
Step 2: Computing a Similarity Measure <ul><li>“ Similar project-specific extensions share anchor objects” </li></ul><ul><...
Step 2: Computing a Similarity Measure <ul><li>Similarity between   anchor objects  of two extensions </li></ul><ul><li>1 ...
Step 2: Computing a Similarity Measure <ul><li>Similarity between   two extensions </li></ul><ul><li>Relate the similarity...
Steps 3, 4 and 5 <ul><li>Step 3: Grouping of Similar Extensions </li></ul><ul><li>Group extensions with similarity measure...
Reducing the Domain Model <ul><li>“ If an element has not been used in the last X projects, suggest its banishment” </li><...
Conclusions and Future Work <ul><li>Contributions:   Keep domain models focused </li></ul><ul><li>Experience-based proposa...
Appendix
Telos and ConceptBase <ul><li>Telos  [Mylopoulos et al., 1990] </li></ul><ul><li>Formal knowledge representation language ...
Automatic Numbering of Projects <ul><li>FinalisedProjects   with </li></ul><ul><li>attribute </li></ul><ul><li>seq_number ...
Identification of last X Projects <ul><li>GenericQueryClass  ConsideredProjects  isA  </li></ul><ul><li>FinalisedProjects ...
Identify unused Concepts in Previous Projects <ul><li>QueryClass  AllConcepts  isA Token with </li></ul><ul><li>constraint...
Identify unused Concept in one Model <ul><li>GenericQueryClass  NotUsedIn  isA Boolean with </li></ul><ul><li>parameter </...
Computing refinement between anchor objects: Definition of computed attribute  super <ul><li>IStarElement with </li></ul><...
Computing refinement between anchor objects: computation of transitive closure of  super <ul><li>GenericQueryClass  SuperE...
Similarity Measure <ul><li>Formalization of  similarity between anchor objects : </li></ul><ul><li>E 1  and E 2  project-s...
Similarity Measure <ul><li>Formalization of  similarity between extensions : </li></ul><ul><li>E 1  and E 2  project-speci...
Upcoming SlideShare
Loading in...5
×

03 How to Keep Domain Requirements Models Reasonably Sized

431

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
431
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide
  • Functions: COUNT(C) – current number of instances of class C IPLUS(I,j) – computes i+j IMINUS(I,j) – computes i-j Modules – requirement models of projects separated into modules
  • We need an ordering on the projects to identify the last $X$ projects (where a project is always stored separately in its own module). This can easily be achieved by extending the basic model slightly via a sequence number for each finalised project: The following Event-Condition-Action (ECA) rule automatically tells the correct sequence number as soon as a project is finalised:
  • Having the sequence number of each project available, the following generic query class identifies the last size projects to be considered within the search for unused domain model objects: As mentioned before size is a free parameter that reflects the retrospective window size and that can be set to the current needs of a particular SME.
  • Since the domain model is simply a normal, pre-filled module, we can easily identify all current concepts in the domain model by asking for the Tokens in the domain model module. By using the class Token here we will get only instances of classes and not the classes themselves as answers. To find unused concepts, we can simply refine the above query by checking the x most recent projects and return only those concepts that are not occurring in all these ConsideredProjects . It checks, whether one of the concepts of the domain model (available due to inheriting from AllConcepts query) is NOT available in all the projects (modules) to be considered. It uses another generic query class NotUsedIn that verifies whether a given concept is not available within a given module:
  • It uses another generic query class exttt{NotUsedIn} that verifies whether a given concept is not available within a given module:
  • Thus, for the first decision whether two anchor objects are related we must find out whether there is a ``path&apos;&apos; between them considering the above mentioned modelling means. A set of computed attributes and deductive rules has been defined to compute this information. The following Telos code introduces a new super attribute to any i* element and an accompanying deductive rule that determines the value of this new attribute according to the above mentioned relationships. If the element is an actor, we check for an outgoing is-part-of link. If existing, the target is the value of the super attribute. For a so called intentional element, a common meta class to group task, goal, resource, and softgoal elements, first it is checked whether there is an outgoing means ends link or an incoming decomposition link. If existing, the target (or source, respectively) is the searched value. If no such link exists, it is checked whether the element is inside an actor, i.,e. whether the parent attribute is set. If this is the case, the value is copied to super. These cases completely capture all possibly occurring situations.
  • Having this derived attribute available, we can easily formulate a query that returns the transitive closure of this super relationship starting at (and including) the object src, i.e. all direct or indirect super elements of an object. Picking up on the advanced means of the Telos implementation ConceptBase, by which our approach is backed up, the following recursive generic query class is suitable:
  • Transcript of "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

    ×