1 / 30

Simona Bernardi, Università di Torino José Merseguer, Universidad de Zaragoza

Reliability and availability requirements engineering within the Unified Process using a Dependability Analysis and Modeling profile. Simona Bernardi, Università di Torino José Merseguer, Universidad de Zaragoza Robyn R. Lutz, Iowa State University. Outline.

werner
Download Presentation

Simona Bernardi, Università di Torino José Merseguer, Universidad de Zaragoza

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Reliability and availability requirements engineering within the Unified Process using a Dependability Analysis and Modeling profile Simona Bernardi, Università di Torino José Merseguer, Universidad de Zaragoza Robyn R. Lutz, Iowa State University

  2. Outline • Improve elicitation, documentation and analysis of R&A sw requirements within the Unified Process (UP) • Extension of the requirement workflow to handle R&AR • Step-by-step incremental process • Use of a UML profile (DAM) to 1) specify R&AR and 2) characterize system faults/failures • Application to an intrusion-tolerant, distributed firewall for critical information infrastructures (CRUTIAL IST project)

  3. Motivation • Toward the definition of a methodology for the synergetic use of dependability techniques within the UP • Why the Unified Process (UP) ? • Incremental & iterative: manages risks and handles changes in sw projects better than waterfall models • Uses UML as its specification language • Can be customized for different kind of sw systems/application domains • UP pays little attention to non-functional reqs • Several UML profiles exist that help to gather NFPs • MARTE OMG standard profile • DAM profile for dependability NFPs

  4. Phases Inception Elaboration Construction Transition Workflows Requirements Analysis Design Implementation Test Preliminary Iterations It. #1 It. #2 It. #i It. #i+1 It. #n It. #n+1 It. #n+2 It. #m It. #m+1 System Analyst Structure UC model Find actors & UCs Architect Prioritize UCs UC Specifier Detail UCs UI Designer Prototype UI Unified Process & req. workflow

  5. The set of dependability reqs specification techniques • (Mis)Use cases • IEEE Std. 830-1998 • IEEE Recommended practise for sw requirements specification • DAM profile • Fault Trees

  6. Generation of illegal traffic <<mitigates>> CIS PS Destination Attacker Payload corruption <<threatens>> <<include>> PRRW Service <<mitigates>> Ouside Threat Inside Threat Sender (Mis)Use Cases • Use Cases are textual specifications • Use of templates, like the Cockburn's one

  7. IEEE 830-1998 • Recommends approaches for sw req specification and describes contents and qualities of a good SRS • UP Supplementary Spec document inspired by IEEE 830-1998

  8. DAM profile • DAM Profile has been devised to annotate the design, in this work we use it to specify R&AR • It is a specialization of the MARTE profile • MARTE NFP types enable to describe relevant dependability aspect using “properties”: • Value: value/parameter name • Expr: VSL expression • Source: origin of the NFP (req,est,msr,assm) • StatQ: statistical qualifier (mean,min,max,..)

  9. Fault Trees • FTs are used to • Gather information about the potential contributing causes to threats • Trace the combination of faults/failures to misuse and use cases

  10. CIS LAN WAN CIS Hub Hub CIS WAN Traffic Replicator Message WAN untrusted * * send receive Host 1..* incoming 1..* 2..* join LAN LAN Traffic Replicator CIS Firewall outgoing 1..* trusted A running example from CRUTIAL project

  11. Step-by-step process: ith iteration in the requirement workflow (I) • Input: DMi-1,UCDi-1,SSi-1 • Output: DMi,UCDi,SSi • Discover new UCs,MUCs and actors: UCDi ← UCDi-1 U UCnew U MUCnew U ACnew • Select UCs to be specified: selUCi  UDCi • Forall uc selUCi do • Specify(uc)

  12. UC specify activity • Textual description of the UC using Cockburn template • R&AR from the Special Requirement section • Application of DAM profile for rewriting them in a standard and disciplined form

  13. Generation of illegal traffic <<mitigates>> CIS PS Destination Attacker Payload corruption <<threatens>> <<include>> PRRW Service <<mitigates>> Ouside Threat Inside Threat Sender UCDi-1

  14. CIS PS use case description

  15. ssAvail=(value=99.99%,statQ=min,source=req); failure = (MTBF = (value=(6,month),statQ=min,source=req) <<DaService>> CIS PS Destination <<stereotype>> DaService <<tupleType>> DaFailure Sender ssAvail:NFP_Percent[*] failure:DaFailure[*] .... MTBF:NFP_Duration[*] ... DAM annotation to CIS PS use case DAM annotation DAM extensions

  16. Step-by-step process: ith iteration in the requirement workflow (II) • Select MUCs related to selUCi: selMUCi  UDCi • Forall muc selMUCi do • Specify(muc)

  17. MUC specify activity • Textual description of the MUC using Cockburn template • Threats information from Success guarantee, Main/Alternate scenario and Other Reqs sections • Application of the DAM profile to characterize from both a qualitative/quantitative viewpoints faults/failures • Faults Trees are used to formally specify UCD relationships • Among Negative Actor actions and Misuse Case success • Among Misuse Cases and related Use Case

  18. Generation of illegal traffic <<mitigates>> CIS PS Destination Attacker Payload corruption <<threatens>> <<include>> PRRW Service <<mitigates>> Ouside Threat Inside Threat Sender UCD0

  19. Payload Corruption MUC description

  20. numberOfFaults=(value=$f,statQ=max,source=est/msr); fault = (type = (value=malicious-logic); occurrenceRate = (value=$fr1,statQ=mean,source=est/msr); effect = (domain = (value=invalid,omission))); <<DaFaultGenerator>> Payload corruption <<threatens>> <<DaService>> CIS PS Attacker <<tupleType>> DaFault type:FaultType[*] occurrenceRate:NFP_Frequency[*] effect: DaFailure[*] <<stereotype>> DaFaultGenerator numerOfFaults:NFP_Integer[*] fault:DaFault <<tupleType>> DaFailure domain:Domain[*] ... DAM annotation to Payload Corruption MUC DAM annotation DAM extensions

  21. CIS PS failure <<DaService>> CIS PS Quorum not reached or wrong judgement The leader is corrupted (fails to fwd the approved message to Destination) <<threatens>> [n/2]+1:n Pn corrupted P1 corrupted ... <<DaFaultGenerator>> Payload corruption P omission (FM2) P is the leader P1 invalid (FM1) P1 omission (FM2) Use of FT to formalize MUC-UC relationships

  22. Step-by-step process: ith iteration in the requirement workflow (III) • Discover new NFRs: SSi ← SSi-1 U NFRnew • Select a subset of requirements: selNFRi  SSi • Forall nfr selNFRi do • Elaborate(nfr) • Restructure UCDi and DMi if necessary

  23. NFR elaboration activity • Rewriting of further NFR from the SS, related to dependability/fault-tolerance with the DAM profile • Annotation in the Domain Model/Use Case Diagrams

  24. IEEE 830-1998 • Recommends approaches for sw req specification and describes contents and qualities of a good SRS • UP Supplementary Spec document inspired by IEEE 830-1998 3.6 Other requirements: (Fault Tolerance) There shall be at least 2f+1 CIS Firewalls to tolerate f concurrent faults

  25. Message WAN WAN Traffic Replicator untrusted * * send receive Host 1..* incoming join 1..* 2..* <<DaVariant>> CIS Firewall LAN outgoing LAN Traffic Replicator 1..* trusted multiplicity=(value=$n,expr=($n>=2*$f+1),source=req); 3.6 Other requirements: (Fault Tolerance) There shall be at least 2f+1 CIS Firewalls to tolerate f concurrent faults DAM annotation to Domain Model

  26. Conclusions • The DAM annotated UML artifacts (UCD,DM) provide input for the other UP workflows (design,test,..) as well as for V&V activities • Next steps: • Study of the DAM applicability in the other UP workflows • V&V activities driven by DAM annotated M(UC)s

  27. Thank you!

  28. MARTE::GRM:: ResourceCore::Resource MARTE::GQAM:: AnalysisContext MARTE::GQAM:: GQAM_Workload:: BehaviorScenario <<user>> ServiceRequest Dependability Analysis Context 1..* accessProb serviceProb[1..*]{ordered} 1..* Component 1..* 1..* stateful origin isActive failureCoverage /percPermFault /ssAvail unreliability /reliability missionTime availLevel reliabLevel safetyLevel complexity * Service requests {ordered} execProb /ssAvail instAvail unreliability /reliability missionTime availLevel reliabLevel safetyLevel complexity 1..* * 1..* 0..1 provides 0..1 1..* * * * requests basicServices sub {Component.provides->lowerBound()+ Component.requests->lowerBound()>=1} {ordered} * Connector MARTE::GQAM:: GQAM_Workload::Step Step 2 1..* coupling interacts-via DAM Core model

  29. DAM Threats model System::Redundancy:: RedundantStructure ErrorPropagation Relation System::Core:: Connector from effect System::Core:: Component ErrorPropagation Impairment System::Core:: Service to effect cause effect Fault Error Failure Hazard cause effect cause cause domain MTTF …. severity risk …. SystemCore:: Core::Step Fault Generator ErrorStep FailureStep HazardStep

  30. <<modelLibrary>> MARTE::MARTE_Library::BasicNFP_Types <<profile>> MARTE::GQAM <<import>> <<import>> <<profile>> DAM <<modelLibrary>> DAM::DAM_Library <<profile>> MARTE::NFPs <<modelLibrary>> DAM_Library Basic_DA_Types <<apply>> <<import>> <<import>> <<profile>> MARTE::VSL:: DataType DAM_UML_Extensions Complex_DA_Types <<apply>> DAM profile overview

More Related