INF 5120 Modellbasert Systemutvikling Modelbased System development Lecture
INF 5120 ”Modellbasert Systemutvikling” ”Modelbased System development” Lecture 11: 26. 03. 2012 Arne-Jørgen Berre arneb@ifi. uio. no or Arne. J. Berre@sintef. no Telecom and Informatics 1
INF 5120 - Lecture plan - 2012 n n n Part I: SSI – Service Innovation and Agile Service/Software Engineering Part II: SSMDE – Model Driven Engineering Part III – Model Driven Interoperability and ADM n n n n n 1: 16/1: Introduction to Model Based System Development (INF 5120) 2: 23/1: SIE I: Enterprise Architecture, Role modeling-Collaboration and Value Networks – Verna Allee (VNA) 3: 30/1: SIE II: : Business Process Modeling with BPMN 2. 0 and Business Model Innovation - Peter Lindgren (BMI) 4: 6/2: SIE III: AT ONE –User-oriented design – with Use cases and user stories 5: 13/2: SIE IV: Service modeling with Soa. ML – Service modeling - Design, patterns 6: 20/2: SIE V: Precise Modeing in UML with OCL and Design with DCI - Design, patterns 7: 27/2: MDE I: Software Process Model Frameworks – Essence/SEMAT, SPEM, EPF and ISO 24744 –Shihong Huang/Brian Elvesæter/Arne J. Berre 8: 5/3: MDE II: Metamodels, Domain specific languages and UML profiles (Franck Fleurey, Brian Elves æter) 9: 12/3: MDE III: Metamodeling, MDLE and DSL Tools (EMF, GMF, ATL, Kermeta) (Franck Fleurey) 10: 19/3: MDE IV: Model transformations - MOFScript, QVT DSLs with examples (Franck Fleurey) 11: 26/3: MDE V: Method Engineering and CORAS UML profile-: DSL example (Arne J. Berre) 2/4, 9/4: EASTER 12: 16/4: MDE VI: User Interface Modeling – IFML etc. - ESITO 13: 23/4: MDI I: Semantic technologies, Ontologies and Semantic annotations , Rules/SBVR 14: 30/4: MDI II: Model Driven Service Interoperability 15: 7/5: MDI III: ADM and Migration to Cloud computing 16: 13/5: Conclusion and Summary for INF 5120 - Preparation of Exam n Exam: Monday June 4 th, 2011, 1430 -1830 (4 hours) Telecom and Informatics 2
INF 5120 – Oblig/Exercise plan - 2012 n n n n 1: 16/1: None 2: 23/1: Guest lecture: Value Networks – Verna Allee (VNA) 3: 30/1: Guest lecture: Business Model Innovation - Peter Lindgren (BMI) – Establish groups 4: 6/2: AT ONE initial exercise – overall approach for Oblig 1 – “my. Service. Fellow” 5: 13/2: Group presentation 6: 20/2: Group presentation 7: 27/2: Group presentation n n 8: 5/3: MDE Tools – introduction – Oblig 2 intro 9: 12/3: MDE Tools II - EMF 10: 21/3: MDE Transformation tools - Delivery of Oblig 1 11: 26/3: Walk through of Oblig 1 2/4, 9/4: EASTER 12: 16/4: MDE User Interface tools – ESITO o. a. 13: 23/4: Oblig 2 questions 14: 30/4: Oblig 2 delivery 15: 7/5: Oblig 2 summary 16: 13/5: Conclusion and Summary for INF 5120 - Preparation of Exam n Exam: Monday June 4 th, 2011, 1430 -1830 (4 hours) Telecom and Informatics 3
Outline n Method Engineering, FACESEM – OMG standardisation process - metamodeling aspects ! (now after MDE lectures) n SPEM-ISO 24744, KUALI BEH, Essence, SPEM-EPF n CMMN n Essence Book (draft) (Ivar Jacobson !) n Ref. Inf 5120. modelbased. net (EPF example) n CORAS DSL example – UML Profile, Metamodel, DSL, Method and Tool (ref. INF 5150) n Soa. ML standard – UML profile and metamodel n Agile Service Engineering book (Draft) (Marc Lankhorst) n Oblig 1 – presentation and discussion Telecom and Informatics
OMG - SPEM and FACESEM EPF, RMC SPEM 1 SPEM 2 SPEM RFP Ess. Work SEMAT FACESEM RFP 2011 SEMDM ISO 24744 FACESEM ? SEMAT Esssence 2012/2013 KUALI BEH Telecom and Informatics 5
Static view basic concepts Software project practitioners work context. Method followed by practitioners work team i during the software project. Method is composed by set of practices. ….
Software project definition Temporary endeavor undertaken by a work team. Uses a method in order to develop, maintain or integrate a software product. Responds to specific stakeholder needs and particular project conditions.
Software project related concepts
Operational View Related to the software project execution. Provides the work team with mechanisms to enact a method and adapt its practices to the specific context and stakeholder needs.
Operational View Method enactment Work team selects a method from the MPI according to the software project characteristics. Selected method is adapted in accordance with stakeholder needs and project conditions. To adapt the method work Consistent, team analyzes its practices and coherent and Results applies the practice complete set substitution, merging or splitting of practices operations, if necessary.
Method enactment WT adapts the method Adapted WT assigns inputs Ready to Begin Selected WT assigns results as inputs WT adapts the method WT chooses practice instances, estimates and agrees work distribution Progress Snapshot In Progress WT produces software product WT=Work Team Finished WT produces verified results or WT cancels practice instances and WT collects data measures WT verifies results or WT in stand by
Method enactment board example Method states Practice states
SEMDM/ISO 24744 vs SPEM ISO 24744 as an International standard Metamodeling – Powertypes/Clabjects SEMDM Metamodel areas SEMDM Diagrams SEMDM Graphical notation SEMDM Examples Satisfaction of RFP requirements Issues to be discussed Overview
Task Kind Task powertype Name Purpose Min. Cap. Lev “Code Writing” “To write code…” 1 clabject Start End Duration partitioned type Code Writing Language 12 -Sep-07 15 -Sep-07 3 “C#” Moving on to metamodelling
Task Kind Name Purpose Min. Cap. Lev “Code Writing” “To write code…” 1 Task Start End Duration Code Writing metamodel method Language 12 -Sep-07 15 -Sep-07 3 “C#” Putting things in context endeavour
Metamodel overview
Case Management Notation Telecom and Informatics 18
OMG CASE MANAGEMENT MODEL AND NOTATION AGILE ENTERPRISE DESIGN, BIZAGI, CORDYS, IBM, ORACLE, SAP, SINGULARITY, SINTEF, TIBCO, TRISOTECH, VISUMPOINT
WHAT IS AUTOMATED CASE MANAGEMENT? • • Adaptive processes Predefined process building blocks Shared case knowledge Activities triggered by events Automated guidance Timely and detailed records Humans in control CMMN is about modeling a case file and process building blocks to support a type of case management 9/15/2020 20
PROJECT TIMELINE • 9/09 Case Management RFP issued • 6/11 OMG evaluates three initial submissions • Biz. Agi, IBM, Oracle, SAP, Trisotech • Agile Enterprise Design, Cordys, SINTEF, TIBCO, Unisys, Visumpoint • Singularity • Teams asked to explore a merger • 11/11 First draft of merged specification • 2/12 Revised (merged) submission published • 3/12 OMG Reston - review of revised submission
RELATIONSHIP TO BPMN 2. 0 • Working name: Case Management Model and Notation (CMMN), analogous to BPMN • Case is defined as independent concept, but BPMN Processes can be invoked through CMMN tasks • Similar notation for similar concepts • Task, Event • Intentionally different notation for new concepts • Stage, Sentry, Planning Scope List, . .
KEY SPECIFICATION ELEMENTS • Notation • Meta-model (information, behavior) • Execution semantics • Planning in run-time • Event-Condition-Action (ECA) principles • Exchange formats (derived from metamodel) • Relationship to BPMN 2. 0 • In the revised submission the least mature element is the expression language definition and integration
CASE MODEL • Case model main areas: • Information (“case file”) • Behavior • Roles
CASE FILE MODEL
CASE BEHAVIOR • The items that together can form a case plan: • • stages (“behavior containers”, can be nested) tasks (human tasks, tasks to call processes and cases) events (internal, external) milestones. • Defined once (related to stages), but can get multiple occurrences.
“FIXED” PART OF THE PLAN • Occurrences that are defined in design-time, represent the “fixed” part of the plan (as contained in stages). • Their entry or forced termination criteria, possibly as dependencies on each other, defined as “sentries”. • Sentry defines EC (…On … IF …) part of ECA.
SENTRY MODEL
SENTRY “ON” SHOWN AS CONNECTOR IN SOME COMMON SITUATIONS
“DISCRETIONARY” PART OF THE PLAN • Occurrences might evolve in run-time • based on design-time defined “discretionary items”. • No sentries defined on discretionary items, as these are sources of potentially multiple occurrences. • Lists of discretionary items (planning scope lists ) defined per • stage (for pulled, or ad-hoc planning) • task (for pushed planning).
PLANNING STAGE • Planning scope list on a stage • Collapsed view • Expanded view
PLANNING TASK • Planning scope list on a stage • Collapsed view • Expanded view
PLANNING SCOPE LIST MODEL
STAGE MODEL • Stage can contain: • definitions of plan items • design-time fixed occurrences of them (and sentries) • discretionary items. • Fixed / discretionary occurrences can be defined in any mix, from 100 % fixed to 100 % discretionary.
NEXT STEPS • Complete the specification • • Start expression language work Start exchange formats (XSD and XMI) work Complete notation and meta-model (including constraints) Complete documentation • Next CM team F 2 F is April 24 -26 • Meeting goal - complete the remaining design work • CM team requests that the BMI TF extend the revised submission deadline to November 12 th, 2012 • Four weeks before OMG SFO meeting on December 10 th • We do not plan to request any further extensions • Not possible to finish by the September OMG meeting
QUESTIONS? COMMENTS? • Technical editing team • Henk de Man (Cordys), hdman@cordys. com • Chuck Fay (IBM), cfay@us. ibm. com • Ralf Mueller (Oracle), ralf. mueller@oracle. com • Project Management • Dave Ings (IBM), ings@ca. ibm. com • Martin Chapman (Oracle), martin. chapman@oracle. com
OTHER SUBMISSION TEAM MEMBERS • • • • • Alan Babich (IBM), alanbabich@us. ibm. com Fred Cummins (Agile Enterprise Design), fred. a. cummins@gmail. com Jesus Sanches (Bizagi), jesus. sanchez@bizagi. com Bill Carpenter (IBM), wjcarpenter@us. ibm. com Rick Hull (IBM), hull@us. ibm. com Matthias Kloppmann (IBM), matthias. kloppmann@de. ibm. com Gregory Melahn (IBM), melahn@us. ibm. com Mike Marin (IBM), mikemarin@us. ibm. com Heidi Buelow (Oracle), heidi. buelow@oracle. com Ravi Rangaswamy (Oracle), ravi. rangaswamy@oracle. com Ivana Trickovic (SAP), ivana. trickovic@sap. com Oliver Kieselback (SAP), oliver. kieselbach@sap. com Paul O’Neill (Singularity), paul. oneill@singularitylive. com Arne Berre (SINTEF), arne. j. berre@sintef. no Brian Elvesater (SINTEF), brian. elvesater@sintef. no Paul Vincent (TIBCO), pvincent@tibco. com Justin Brunt (TIBCO), jbrunt@tibco. com Denis Gagne (Trisotech), dgagne@trisotech. com Robert Lario (Visumpoint), Robert. Lario@visumpoint. com
CORAS - initial UML profile and then DSL n http: //coras. sourceforge. net/ n CORAS is part of the curricula in INF 5150 (Fall 2012) n For INF 5120 we just use it as an example of a DSL language, derived from an initial UML profile, and an example of tooling support with EMF. Telecom and Informatics
Overview n What is CORAS? n Main concepts n Process of eight steps n Risk modeling n Semantics n Calculus n Tool support n Further reading CORA Telecom and Informatics 39
What is CORAS? n CORAS consists of n Method for risk analysis n Language for risk modeling n Tool for editing diagrams n Stepwise, structured and systematic process n Directed by assets n Concrete tasks with practical guidelines n Model-driven n Models as basis for analysis n Models as documentation of results n Based on international standards CORA Telecom and Informatics 40
Main Concepts Party Vulnerability Asset Threat Treatment Unwanted incident Likelihood Consequence Risk CORA Telecom and Informatics 41
Definitions n Asset: Something to which a party assigns value and hence for which the party requires protection n Consequence: The impact of an unwanted incident on an asset in terms of harm or reduced asset value n Likelihood: The frequency or probability of something to occur n Party: An organization, company, person, group or other body on whose behalf a risk analysis is conducted n Risk: The likelihood of an unwanted incident and its consequence for a specific asset n Risk level: The level or value of a risk as derived from its likelihood and consequence n Threat: A potential cause of an unwanted incident n Treatment: An appropriate measure to reduce risk level n Unwanted incident: An event that harms or reduces the value of an asset n Vulnerability: A weakness, flaw or deficiency that opens for, or may be exploited by, a threat to cause harm to or reduce the value of an asset CORA Telecom and Informatics 42
Process of Eight Steps 1. Preparations for the analysis 2. Customer presentation of the target 3. Refining the target description using asset diagrams 4. Approval of the target description 5. Risk identification using threat diagrams 6. Risk estimation using threat diagrams 7. Risk evaluation using risk diagrams 8. Risk treatment using treatment diagrams Establish context Assess risk Treat risk CORA Telecom and Informatics 43
Risk Modeling n The CORAS language consists of five kinds of diagrams n Asset diagrams n Threat diagrams n Risk diagrams n Treatment overview diagrams n Each kind supports concrete steps in the risk analysis process n In addition there are three kinds of diagrams for specific needs n High-level CORAS diagrams n Dependent CORAS diagrams n Legal CORAS diagrams CORA Telecom and Informatics 44
Initial UML profile Telecom and Informatics 45
CORAS DSL Example: Threat Diagram Consequence Asset Likelihood Threat Vulnerability Threat scenario Unwanted incident CORA Telecom and Informatics 46
Semantics n How to interpret and understand a CORAS diagram? n Users need a precise and unambiguous explanation of the meaning of a given diagram n Natural language semantics n CORAS comes with rules for systematic translation of any diagram into sentences in English n Formal semantics n Semantics in terms of a probability space on traces CORA Telecom and Informatics 47
Example n Elements n Computer virus is a non-human threat. n Virus protection not up to date is a vulnerability. n Threat scenario Server is infected by computer virus occurs with likelihood possible. n Unwanted incident Server goes down occurs with likelihood unlikely. n Availability of server is an asset. n Relations n Computer virus exploits vulnerability Virus protection not up to date to initiate Server is infected by computer virus with undefined likelihood. n Server is infected by computer virus leads to Server goes down with conditional likelihood 0. 2. n Server goes down impacts Availability of server with consequence high. CORA Telecom and Informatics 48
SINTEF – EPF based methods sisas. modelbased. net neffics. modelbased. net Inf 5120. modelbased. net Telecom and Informatics 49
Telecom and Informatics 50
CORAS Method Telecom and Informatics 51
Agile Service Development (1/3) New book – in the publishing process until April 2012, Springer. We will use a publication preprint initially Telecom and Informatics 52
Agile Service Development (2/3) Telecom and Informatics 53
Agile Service Development (1/3) Telecom and Informatics 54
Book: Telecom and Informatics 55
Telecom and Informatics 56
Telecom and Informatics 57
Soa. ML specification 1. 0 http: //www. omg. org/spec/Soa. ML/1. 0/ Telecom and Informatics 58
Next Lecture (12) – April 16 th, 2012 n User Interface Modeling n IFML n Genova, ESITO n Oblig 2 – Discussions Telecom and Informatics 59
- Slides: 59