EXTREME: EXecuTable Requirements Engineering, Management and Evolution Dr. Ella Roubtsova Open University of the Netherlands
Two phases of the Cognitive process Cognitive laws state that men: discover new knowledge in a declarative way and then refine it to the procedural level
RE is a cognitive process It goes beyond IT Declarative and Procedural stages are currently supported with methods with different semantics. How can the RE process be made seamless?
How can the RE process be made seamless? Psychology studies show that people s thinking is context related (Tversky,A.,Simonson,I.(1999). The stakeholders can identify missing or tacit requirements at the moment they see the behaviour of the system model. Hence, the executable models offer to stakeholders the contextual basis for identification of incompleteness.
Declarative stage: Goals and Rules The declarative paradigm does not have explicit notion of state progress. Declarative specifications present snapshots of a system A snapshot is a visible abstract state captured after or before an event. A state is abstract if the relation of this state to the system life cycle is unknown. An abstract state may present the state of a set of system concepts, a subset of states of system etc.
Examples of Declarations A product is composed; A policy is bought by a registered customer; A claim of a client with a bought policy is handled. 90% of claims should be handled within 4 days.
Goal graph An application supporting insurance business AND A product is composed A policy is bought by a registered customer 90% of claims should be handled within 4 days. A claim of a client with a bought policy is handled
Declarative Approaches Goal-Oriented Requirements Engineering (GORE) is a wellestablished group of approaches (Kavakli,E. 2002, Lamsweerde van A.2004, Darimont,R., Lemoine,M.2006, Regev,G., Wegmann, A.2012). The aim of a goal-oriented approach is to justify requirements by linking them to higher-level goals. Goals are refined by business rules, requirements and concerns. The goal models are used to keep the business motivation in mind of requirement engineers and to elaborate the strategic goals with requirements and concerns.
Goal refinement An application supporting insurance business A product is composed There is a list of medical procedures AND Medical procedures are combined into groups Each group corresponds to a NoLimit Coverage or a Max Coverage. AND A claim of a client with a bought policy is handled A policy is bought by a registered customer A Customer is registered. A registered customer bought a policy AND The containers for the current state of coverages of the policy are. A registered customer with the bought policy can submit claims A submitted claim is sorted as : Not Covered, To Max Claim (covered to max) No Limit Claim (covered No Limit ) AND A Not Covered claims is refused. No Limit claim is paid. To Max Claim is handled and paid To Max and the Information about the rest is provided
GORE: From Goals to Procedural Models Entities - represent passive objects Agents - human beings or automated components Operations - provoke object state transitions or trigger other operations through the send and receive events. GORE operation diagrams are either data flow or control flow diagrams. Data flow and control flow diagrams have asynchronous semantics. This is the place where the operation model introduces states that cannot be related to goals.
Wishes for transformation From Goals to Executable Models 1. One requirement - one executable model 2. Requirements present concepts, extra behaviours, constraints, dependences and aspects. 3. The compositions technique should be able to compose concepts, constraints, dependences and aspects into visible system behaviour and should not introduce any states that s that cannot be justified by requirements. 4. The modelling semantics should model execution for the feedback to the user of the designed system.
EXTREME: Goal Modelling with Protocol Modelling 1. One requirement - one executable protocol machine V 2. Requirements present both concepts, constraints, dependences and aspects. V 3. The compositions technique should be able to compose concepts, constraints, dependences and aspects and should not introduce any states that s that cannot be justified by requirements. V CSP parallel composition extended for machines with data. 4. The modelling semantics should model execution for the feedback to the user of the designed system. V ModelScope
Concepts, Dependencies OBJECT Medical Procedure NAME Name ATTRIBUTES Name: String,MPGroup:MPGroup STATES, added TRANSITIONS new* Medical Procedure=, *AddMPintoGroup=added, added*submit Claim=added EVENT Medical Procedure ATTRIBUTES Name: String EVENT AddMPintoGroup Medical Procedure: Medical Procedure, ATTRIBUTES Medical Procedure: Medical Procedure, EVENT Submit Claim MPGroup:MPGroup ATTRIBUTES Claim:Claim, Polis:Polis, Medical Procedure: Medical Procedure, Claim Number:String, Amount: Currency Medical Procedure Claim Submit Claim PayToMax paidtomax AddMP togroup MP Group AddMPtoGroep MPGroup ChangeMPGroup coveredmax PayNoLimit Submit Claim added AddGroupTo NoLimitCoverage paidnolimt Covered NoLimit ChangeMPGroup AddGroupTo NoLimitCoverage
Extra behaviour Claim Submit Claim PayNoLimit paidnolimt PayToMax paidtomax Claim Sorting Max PayToMax PayNoLimit No Limit Not Covered
Aspects Submit Claim Medical Procedure AddMP togroup added Duplicate Check unique duplicate Product MaxCoverage, NoLimitCoverage AddGroupToMaxCoverage, AddGroupToNoLimitCoverage Offer Product offered Person Buy policy Delete Product deleted Withdraw Product
An application supporting insurance business EXTRIME: Declarative and procedural AND A product manager, unique medical procedure. Each medical procedure c is added to only one group of medical procedures. A product manager a unique Medical Procedure Duplicate Check MP Group Duplicate Check A product manager a Max Coverage with the size of Max. The coverage is added to a Product Max Coverage group of medical procedures,. Each group is added to only one Coverage ( MaxCoverage or No Limit coverage) A product manager a No Limit Coverage. The coverage is added to a Product No Limit Coverage A product is composed A product manager a product and offers it to the market A submitted claim is sorted as : Not Covered, Max Claim No Limit Claim Claim Sorting Product Duplicate check AND A claim of a client with a bought policy is handled AND A Not Covered claims is refused. A policy is bought by a registered customer AND A Customer is registered. Duplicate Check Person A registered customer with the bought policy submitted a claim A No Limit claim is always paid.: A registered customer bought a policy Policy The handler for each Coverage of the policy are.: The initial Balance for each Coverage Max is equal to the Max in Max Balance assigned to attributes of Max Coverage. Coverage No Limit Coverage Max Claim A Max Claim is paid as follows: If the Coverage Max. Balance=0 I, then the Max Claim is refused. If the Coverage Max. Balance>0 then : If Max Claim. Amount <= Coverage Max. Balance, the claim is paid; If Max Claim. Amount >Coverage Max. Balance, then ( Coverage Max. Balance- Max Claim. Amount ) is paid and Coverage Max. Balance=0.
EXTRIME: Procedural Medical Procedure AddMP togroup Submit Claim added Claim Submit Claim PayToMax PayNoLimit paidnolimt CSP parallel composition MP Group MPGroup ChangeMPGroup Product Product AddMPtoGroep AddGroupTo NoLimitCoverage coveredmax Covered NoLimit ChangeMPGroup AddGroupTo NoLimitCoverage MaxCoverage, NoLimitCoverage AddGroupToMaxCoverage, AddGroupToNoLimitCoverage Delete Product deleted Offer Product Withdraw Product offered Buy Policy Duplicate Check Person Person unique duplicate Buy policy paidtomax Claim Sorting PayToMax Max No Limit Not Covered Policy PayNoLimit Buy Policy, Submit CoverageMax, Claim CoverageNoLimit NoLimit Coverage AddGroupTo NoLimitCoverage CoverageNoLimit NoLimitCoverag Max Coverage AddGroupTo MaxCoverage CoverageMax MaxCoverage CoverageMax Coverage Max PayToMax CoverageNoLimit Pay NoLimit CoverageNoLimit
EXTREME: Execution and Feedback to the user
EXTREME : Local Reasoning Seamless relation of the declarative and procedural levels of requirements engineering. The basis is the synchronous semantics and composition. Traceability of declarative rules in the executable models. Local reasoning on protocol models using declarative rules. The conclusion are true for the complete model because of the properties of the CSP parallel composition. Local reasoning in Protocol Modelling is based on a property of CSP composition. Let us take a sequence, S, of events that is accepted by the CSP parallel composition of protocol machines (M1 M2) of the two machines M1 and M2. Then let us take the subsequence, S0, of S obtained by removing all events in S that are not in the alphabet of M1, S0 will be accepted by the machine M1 by itself. In other words, composing another machine with M1cannot " break its trace behaviour".
EXTREME : Management and Evolution Simplification of model management. Simplification of model evolution. Unfolding hidden requirements BEHAVIOUR!Duplicate Check STATES unique, duplicate TRANSITIONS @any* =unique --------------------------------------- package Insurance; import com.metamaxim.modelscope.callbacks.*; public class DuplicateCheck extends Behaviour { public String getstate() { String myname=getstring("name"); Instance[] existingins = this.selectinstate(this.getobjecttype(), "@any"); for (int i = 0; i < existingins.length; i++) if (existingins[i].getstring("name").equals(myname) &&!existingins[i].equals(this)) return "duplicate"; return "unique"; } } Duplicate Check unique duplicate
EXTREME: Unfolding hidden requirements: Pay To Max package Insurance; import com.metamaxim.modelscope.callbacks.*; public class CoverageMax extends Behaviour { public void processpaytomax(event event, String subscript) { int newbalance=this.getcurrency("balance"); int newamount= event.getinstance("claim").getcurrency("amount"); int newpayment=0; if (newbalance >= newamount) { newbalance=newbalance-newamount; newpayment=newamount; } else { newpayment=newbalance; newbalance=0; } this.setcurrency("balance", newbalance); this.setcurrency("paymenttomax", newpayment); } }
Future Research Directions Tool support for traceability of requirements in models Modelling of abstract business concepts: capacities and Key Performance Indicators.
Queries to models Function selectbyref( Behaviour_Name, Attribute_Name ) returns an array of instances, all of which include the specified behaviour (or object) and have the specified attribute referencing this. Function selectincontext ( Behaviour_Name, Event_Name ) returns an array of instances, all of which include the specified behaviour and have the specified event with the specified subscript in context. Function selectinstate ( Behaviour_Name, State ) returns an array if instances, all of which include the specified behaviour.
Example of KPIs KPI: Submitted and Paid Claims per Year are monitored Protocol machine CounterNumberOfClaims Number of claims submitted from one year ago till now Number of claims submitted and paid from one year ago till now Claim Now State:Claim is paid to max SubmissionDate State: Claim paid no limit
Number of claims submitted and paid from one year ago till now package Insurance; import com.metamaxim.modelscope.callbacks.*; import java.util.*; public int getnumberofpaidclaims() { int NumberOfPaidClaims=0; Date d = new Date(); Calendar cal = Calendar.getInstance(); cal.add(calendar.year, -1); Date oneyearago = cal.gettime(); Instance[] PaidToMaxIns = selectinstate("claim", "paidtomax"); for (int i = 0; i < PaidToMaxIns.length; i++) { Date SD=PaidToMaxIns[i].getDate("SubmissionDate"); if (SD.compareTo(oneYearAgo)>0) NumberOfPaidClaims=NumberOfPaidClaims+1; } Instance[] PaidNoLimitIns = selectinstate("claim", "paidnolimit"); for (int i = 0; i < PaidNoLimitIns.length; i++) {Date SD=PaidNoLimitIns[i].getDate("SubmissionDate"); if (SD.compareTo(oneYearAgo)>0) NumberOfPaidClaims=NumberOfPaidClaims+1; } return NumberOfPaidClaims; }}
Publication Ella Roubtsova. EXTREME: EXecuTable Requirements Engineering, Management and Evolution. Accepted chapter for the book "Progressions and Innovations in Model-Driven Software Engineering" IGI global. April 2013.
IT IS QUESTION TIME!