2014 Oct.31 International Symposium on Practical Formal Approaches to Software Development. Copyright Prof. Dr. Shuichiro Yamamoto 2014

Size: px

Start display at page:

Download "2014 Oct.31 International Symposium on Practical Formal Approaches to Software Development. Copyright Prof. Dr. Shuichiro Yamamoto 2014"

Juliana Kelley
6 years ago
Views:

1 2014 Oct.31 International Symposium on Practical Formal Approaches to Software Development Nagoya University Dr. Prof. Shuichiro Yamamoto 1 Agenda Assurance case Pitfalls of assurance case Generic derivation of assurance case from models Case study for ArchiMate Summary and future work 2

2 Essential concept of Assurance case (GSN) Principles to be satisfied by the target artifact Principles Context of shall be satisfied Assuredness of Artifacts for the Principles Assurance case (GSN) Architecture as the target of explanations (ArchiMate) Artifacts By the explanation based on evidences, satisfaction of the principles by the target artifact is described by GSN 3 Accountability achievement by GSN Principles Context of argument Target artifact satisfy principles Claim Target artifact for accountability Argument over the artifact configuration Rationale of decomposition Elements of the target artifact satisfy principles Validation report of elements Evidence Relationships among the target artifact satisfy principles Validation report of relationships 4

3 Pitfalls to introduce assurance case Fundamental Challenges Claim descriptions Decomposition exhaustiveness Context descriptions Confusion of Argument Structure & Control Structure Controlling the scopes Diversity of Decomposition Approaches 5 Assurance case and context boundary Completeness of assurance case depends on the context Assurance case boundary Assurance case Context boundary Context of Assurance case 6

Decomposition patterns types explanation Architecture splitting a component into several sub components functional splitting a component into several sub functions Attributes splitting a property

4 Decomposition patterns types explanation Architecture splitting a component into several sub components functional splitting a component into several sub functions Attributes splitting a property into several attributes Infinite set inductive partitioning from a base case (e.g., over time) complete capturing the full set of values for risks, requirements, etc. monotonic concretion the new system only improves on the old system making informal statements less vague Robin Bloomfield and Peter Bishop, Safety and Assurance Cases: Past, Present and Possible Future an Adelard Perspective 7 Architecture decomposition System architecture design System is dependable Argument over System architecture Sub system A is dependable Sub system B is dependable Interactions between A and B are dependable 8

5 Argument Patterns Document Evidence pattern Target systems Assurance case Explanation Description patterns Reference patterns Conditional patterns Deduction patterns Reuse patterns Existing Assurance case Copyright Prof. Dr. Shuichiro Yamamoto Assurance case Pattern classes Patterns Description 15 Reference 10 Conditional 7 Inference 5 Evidence 11 Reuse 2 Description Architecture, Function, Attribute, Completion, Process, Process dependency, Hierarchy, DFD, View, Use case, Requirements, State transitions, Operation requirements, Sequence diagram, Business process Risk, Embedded system, Common criteria, Requirements template, System boundary, Failure mode, NFR grade, DEOS process, Test case, Problem frame ECA, Conditional decision, Alternative choice, Contradiction resolution, Balance, Improvement, Clarification Induction, eliminative, negative induction, refutation Regulation, Formal proof, Model checking, Testing, Agreement, Review, Simulation, Evaluation, Explanation, Monitoring, Documentation Horizontal, Vertical Copyright Prof. Dr. Shuichiro Yamamoto

6 Scope of Assurance case Family Process Assurance case category Requirements Assurance case for R SLCP Design Construction Testing Assurance case for D Assurance case for C Assurance case for T Assurance case for Development process Service strategy Assurance case for SS ITIL Service design Service transition Service operation Service improvement Assurance case for SD Assurance case for ST Assurance case for SO Assurance case for SI Assurance case for Operation process Refs. ISO/IEC 12207, IEEE Std , Systems and software engineering Software life cycle processes itsmf, ITIL V3 Foundation Handbook, 2009 Copyright Prof. Dr. Shuichiro Yamamoto Assurance case derivation from Software model Principles Principles Context of argument The software model satisfies dependability principles Software model Software model Argument over architecture Rationale of decomposition Model elements Relationships between Model elements Elements of the Software model satisfy principles Relationships among the Software model satisfy principles from/to Argument over each element Argument over each relationship Generic configuration of Software model Assurance case pattern derived from Software model 12

Relative completeness of Assurance case Assurance case is relatively complete for Principles, Architecture, and Risks Principles dependability parameters safety, security, sustainability,

context of assurance cases Agree on the criticality of candidate Assurance cases Review critical Assurance cases Ex.

7 Relative completeness of Assurance case Assurance case is relatively complete for Principles, Architecture, and Risks Principles dependability parameters safety, security, sustainability, etc. Context of assurance case Architecture traceability management through models Risk residual risk management 13 Assuredness review Agree on principles, architectures, and risks as the context of assurance cases Agree on the criticality of candidate Assurance cases Review critical Assurance cases Ex. Safety, Security, Sustainability -- Dependability parameters as principles Business architecture AC(BA, Sa) AC (BA, Se) AC (BA, Su) Information system architecture AC (IA, Sa) AC (IA, Se) AC (IA, Su) Technology architecture AC (TA, Sa) AC (TA, Se) AC (TA, Su) 14

8 15 ArchiMate category ArchiMate core Motivation extension Implementation extension B C D -- A H -- E F G TOGAF ADM phase Business architecture Information system Technology architecture preliminary Architecture vision Architecture change management Requirements management Opportunity and solution Transition planning Implementation governance 16

9 ArchiMate metamodel assigned from associated with value associated with meaning product associated aggregates with associated aggregated by with contract Business accessed by objectives realized by assigned realizes from assigned from expression accesses realized by Business service realizes Business process/funct accesses ion/collabora tion triggered triggers by triggers triggered by Business event assigned to uses used by used by Business interface assigned from triggered by / flow from uses/ composed of Business collaboration location used by/ composes assigned to Business actor aggregated by assigned to assigned from Business role aggregated by aggregates assigned to 17 Assurance case derivation from ArchiMate model Dependability Principles Dependability Principles Context of argument ArchiMate model satisfies dependability principles ArchiMate model ArchiMate model Argument over architecture Rationale of decomposition Model elements Relationships between Model elements Elements of the ArchiMate model satisfy principles Relationships among the ArchiMate model satisfy principles from/to Argument over each element Argument over each relationship Generic configuration of ArchiMate model Assurance case derived from ArchiMate model 18

10 Assurance case decomposition hierarchy for ArchiMate Root goal Concepts and relationships Category of concepts and relationships Category instances of concepts and relationships Risk mitigation for Instance risks The root goal states that ArchiMate model shall satisfy dependability principles Root goal is decomposed by Concepts and relationships of ArchiMate notations Second level goals are decomposed by categories of concepts and relationships of ArchiMate notations Third level goals are decomposed by instances of concepts and relationships of ArchiMate notations Fourth level goals are decomposed by risks for the corresponding instances and are supported by evidences to mitigate risks. 19 Automatic derivation GSN from ArchiMate ArchiMate Model A For each ArchiMate model A=<Concept Set, Relationship Set>, where ConceptSet={<Name, Cc > Cc is a Concept category of ArchiMate} RelationshipSet={<Name, Cr > Cr is a Relationship category of ArchiMate} the following sets are calculated. ConceptCategory(A)={ C <x, C> is in ConceptSet of A } RelationshipCategory(A)={ C <r, C> is in RelationshipSet of A} ConceptInstance(C, A)={ x <x, C> is in ConceptSet of A} RelationshipInstance(C, A)={ r <r, C> is in RelationshipSet of A} Assurance Case D Based on the above sets, GSN model D is derived by the following steps. The root goal can simply be developed such that ArchiMate model A satisfies dependability principles. Second level goals are derived by Concept and Relationship Third level goals are derived by using ConceptCategory(A) and RelationshipCategory(A) Fourth level goals are derived by using ConceptInstance(C, A) and RelationshipInstance(C, A) Fifth level goals are derived by analyzing instance risks. The derivation shall be conducted by eliciting risks for each instance element of A. 20

11 Overview of Assured ADM O-DA ADM phase AADM Preliminary 1Architecture repository to store evidence and assurance case 2Dependability board to agree on priority among claims A. Architecture vision 1Dependability scope definitions 2Quantitative evaluation index 3 Capability evaluation of dependability 4Dependability parameter B. Business architecture 1Dependability principle definition 2BA assurance case development 3BA assurance case review C. Information system architecture 1IA assurance case development 2IA assurance case review D. Technology architecture 1TA assurance case development 2TA assurance case review E. Solution 1Integration of BA, IA, TA assurance case 2Integrity confirmation F. Transition 1Operation management assurance case development 2Value analysis of operation assurance case 1Evidence development for assurance case 2Process evidence G. Implementation development method 3Exhaustive relationship validation between claims and evidences 4Operational assurance case review H. Architecture change management Requirements management 1Evidence management of operational assurance case 2 Confirmation of measure for claim failures3risk management by assurance case 4Failure analysis by assurance case Traceability management of assurance case Ref. Open Group Standard, Real Time and Embedded Systems:, Dependability through Assuredness (O DA) Framework, Interrelationship among concepts ADM uses developed by Architecture described by ArchiMate assured by assured by O DA uses Assurance case 22

Dependability argument based on TOGAF Dependability of Architecture layers and layer interactions Intra dependability of business, application, and technology layer Inter dependability of interaction

12 Dependability argument based on TOGAF Dependability of Architecture layers and layer interactions Intra dependability of business, application, and technology layer Inter dependability of interaction between business and application layers and Interaction between application and technology layers Architectures are described in ArchiMate Dependability of Architectures is assured by GSN derived from ArchiMate descriptions 23 24

13 GSN for OP3.0 smart store implementation Top Goal Sub goals for layers Sub goals for node category Sub goals for node instances 25 26

Case study: driving diagnosis service Gasoline sales company provides the driving diagnosis service that supports safety drive by analyzing driving information of cars using gasoline stations with

When a car enter the gas station and stops the engine, the onboard device sends the driving information recorded after the time of the last refueling to the connection device on the gas station by

When the driving information is sent to the cloud server through network from the connection device on the gas station, the driving diagnosis service analyzes the driving information and provides the

14 Case study: driving diagnosis service Gasoline sales company provides the driving diagnosis service that supports safety drive by analyzing driving information of cars using gasoline stations with cloud service. Onboard car devices gather all the information such as gather number of immediate slowdown, idling time, injection quantity. When a car enter the gas station and stops the engine, the onboard device sends the driving information recorded after the time of the last refueling to the connection device on the gas station by using wireless network. When the driving information is sent to the cloud server through network from the connection device on the gas station, the driving diagnosis service analyzes the driving information and provides the driving report to the driver through smart phones. The service can make a precise decision on the levels of the driving technique of drivers. The gasoline sales company provides the motor vehicle insurance that varies the payment according to the driving technique levels by collaborating with an insurance company. 27 Business Architecture example of DDS( driving diagnosis service) driving diagnosis insurance application process Application of driving diagnosis insurance Acceptance of application Application procedure Collection of premium Insurance participation application Collected premium Insurance application Insurance premium 28

15 GSN for DDS Business Architecture 29 GSN sub tree of G_2 for DDS BA 30

16 GSN sub tree of G_3 for DDS BA 31 Integrated approach of O-DA through ArchiMate ArchiMate O-DA/ GSN Motivation extension Goal model Requirements model Goal GSN Requirements GSN BA Business process BP GSN ArchiMate GSN IA Data model, AP model Data AP GSN TA Deployment model Technology GSN Impl.extension Task model, Artifact model Process/Product GSN 32

17 Summary and future issues Generic Assurance case derivation method through Software models Case studies Future issues include case studies for other modeling languages Ex. SysML, UML, BPMN, SPEM 2 Interdependency analysis of context More case studies 33 34

Certkiller.OG questions

Certkiller.OG questions Certkiller.OG0-021.80 questions Number: OG0-021 Passing Score: 800 Time Limit: 120 min File Version: 4.8 http://www.gratisexam.com/ OG0-021 ArchiMate 2 Part 1 Examination It guided me step by step through