Bangalore Call Girl Just Call♥️ 8084732287 ♥️Top Class Call Girl Service Avai...
03 How to Keep Domain Requirements Models Reasonably Sized
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“
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'' 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:
![Agenda ,[object Object],[object Object],[object Object],[object Object],[object Object],MaRK‘09, Atlanta slide](data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7)