A Consistency Check of Dependability Case (D-case) Produced from Data Flow Diagram (DFD)

Transcription

1 A Consistency Check of Dependability Case (D-case) Produced from Data Flow Diagram (DFD) Nada Olayan 1 and Shuichiro Yamamoto 2 1 Graduate School of Information Sciences, Nagoya University, Nagoya, Aichi, Japan dew2019dew@hotmail.com 2 Strategy Office of Information and Communications Headquarters, Nagoya University furocho, Chikusa-ku, Nagoya, Aichi, Japan yamamotosui@icts.nagoya-u.ac.jp Abstract. After producing the D-case based on DFD, a question about the consistency of the produced D-case was raised. In this paper we will be discussing consistency checks for the produced D-case according to DFD and D-case rules and propose some approaches based on it. There are some rules used to define and formalize the DFD, in the same manner we will define the syntax and semantics of the produced D-case. Keywords: DFD, D-case, GSN, Assurance case, Dependability case, consistency. 1 Introduction Dependability is one of the most important properties in most systems specially the critical ones, the need for dependability has triggered a large growth in demand and has encouraged the seek for more dependability assurance methods. In this paper and in our previous paper we have used the Dependability Case (Dcase) tool to prove dependability, D-case is a technique and a tool used to help build an agreement with the stakeholders; it is based on the concept of discussing evidence until a claim of system dependability is proven valid to guarantee the dependability. Based on our previous paper A dependability assurance method based on Data flow diagram (DFD) [7], where we have discussed the method and explained our first approach, we are going to continue our research by providing consistency proof for this method. In the early stages of the system development life cycle, precisely in the system analysis phase, context diagram and Data Flow Diagram (DFD) are produced. DFD is a graphical representation of the "flow" of data through an information system, modeling its process aspects. Often they are a preliminary step used to create an overview of the system, which can later be elaborated. [6][3] Starting from the Context diagram, the DFD processes are created according to some rules. Tools to ensure DFD Diagram consistency were produced by defining the following: the produced DFD processes from the context diagram, the set of syntax and semantics, the general meaning and fundamentals of DFD. A. Kravets et al. (Eds.): JCKBSE 2014, CCIS 466, pp , Springer International Publishing Switzerland 2014

2 604 N. Olayan and S. Yamamoto The check process can be a manual consistency checks from Context diagram to lower level data flow diagrams using checklist, however this method is time consuming and could be subject to human mistake. So new techniques were introduced by formalizing the rules. Providing a formal model for DFD is helpful while developing the DFD diagrams in the analysis phase of the software development lifecycle. DFD diagrams are considered important for their essential role in tracing the flow of data in the system, and therefore must be produced in details, which will result in a lot of multi-level processes. Using the DFD to prove dependability seems simple but with large amount of processes and their sub levels, it is difficult to track the produced D-case and prove its consistency. Between the Data flow and D-case diagram we will look at the meanings for each, and then come up with the formal rules to define the produced D-case from DFD. In this paper our goal is to define the general meaning of consistency for the produced D-case from DFD in a clear as possible way, and to elaborate and simplify knowledge concerning D-case. We will be defining the syntax and semantics for the produced D-case from DFD in general. The complete formalized rules will not be introduced mathematically, it should be directly produced since the rules were set already, but it shall be formalized in later work for some automated solutions. This paper begins with words on our research background and related work then proceeds with the fundamental rules of both D-case and DFD independently. Then we present an example, which will be used to explain a new approach (improvement on our first method) to reduce the produced D-case levels in order to simplify the checking process. Finally and based on the previous information we present the map to define and check consistency for the produced D-case from DFD, which includes: the rules and, semantics and check tables. 2 Background and Related Work In our previous paper, we explained the method of producing D-case from DFD. The method was explained and proven valid and functional by examining the DFD thoroughly, however a question was raised about the consistency of the produced Dcase from DFD. In classical concept, consistency means the lack of contradiction.it can be defined in either semantic or syntactic terms. In the case of DFD several approaches and techniques were proposed to prove the diagrams consistency. The important rules of DFD were formalized to address the consistency issues in DFD, the research developed a formal method for consistency check between data flow diagrams based on formal notations [1]. It has been realized that the semantics of D-case need to be defined rigorously so that we can systematically reason about its consistency. [2]

3 A Consistency Check of Dependability Case (D-case) Produced from DFD 605 It is difficult to ensure consistency of the D-cases in every detailed document. So the parts that can be checked mechanically were checked by the D-case in Agda system developed by the authors of [2]. Agda system is a general-purpose proof-assistant that can be used to support Dcase description. Using Agda allows the user to build a D-case interactively while incrementally checking the syntax and types. However, Agda does not support consistency checking between D-Case and other types of analysis diagrams such that Data flow Diagrams. 3 Fundamental Rules of D-Case [5] A graphical notation called D-case diagram based on GSN (goal structuring notation) is used to elaborate dependability [9] [5], using a D-case editor we can prove dependability of the system by setting a top goal for the system system is dependable. Various types of documents are associated with D-case such as UML, DFD, risk analysis. etc. In order to prove D-case consistency we have to mention the set of syntax and semantics that defines the D-case based on DFD. Unlike GSN, which mainly focuses on the field of safety, D-case handles all the attributes of dependability: availability, safety, integrity, reliability and maintainability. We will start with the rules and definition of the D-case in general as a graphical structure then we will define the main elements briefly. Fig. 1. D-case Diagram example showing node types

4 606 N. Olayan and S. Yamamoto D-case diagram nodes normally consist of: Goal Context Strategy Evidence Where: Goal or claim is an assertion to be proven, it embodies what we want to show. Context is the means by which the case references detailed artifacts that have been developed elsewhere. Strategy or argument is how evidence supports claim There are two types of arguments that support a claim: Arguments that disassemble the claim into several different claims. Argument that confirms the claim by evidence. Evidence requires document and it supports the argument that may take many forms including test results, formal analyses, simulation results, fault-tree analyses, hazard analyses, modeling, and inspections. 3.1 General Rules of D-Case Output data flows usually have different names than input data flows for a process The diagram is traced only in one direction (downwards) Every context connects to either goal or strategy. D-Case Diagram Basic Rules on Structure [6] A Goal is decomposed to Strategy. Every leaf is either evidence, monitor, external, or undeveloped. Contexts are attached to Goal or Strategy Arrows in the D-Case Diagram has Two Types Solved By: Goal to Strategy, Strategy to Goal, Goal to Evidence, Monitor, External, and Undeveloped In Context of: To context from other kinds of nodes D-Case Diagram Rules on Description Goal should not be an instruction or an opinion, it should be a proposition in the form of system is Dependable and system is safe. Every sub goal must support the goal. Evidence is not just a sentence but must be a solid detailed proof, such as a document that supports the goal. Context associates documents of information, assumptions and definition:

5 A Consistency Check of Dependability Case (D-case) Produced from DFD 607 Such as system environment, identified risk list, system structure, dependability requirements or term definition. The scope of the context is only the attached goal or strategy and the child tree. Monitor is a data available from runtime system (runtime log result) External is a link to other system s D-case. 4 Fundamental Rules of DFD [1][8] A Data Flow Diagram consists of Processes, Data Flows, Data Stores and External Entities Where: Process is an activity to manipulate the incoming input to produce a specific output. Data flow is the way which data travels within the diagram, it could be from or to a process and another processes, a processes and external entity or process and data stores. Data store is where the data is stored, created or manipulated in those stores. External entity is an external entity to the system but interacts with it. 4.1 General Rules of DFD For external entity there is at least one input or output data flow. For a process there is at least one input data flow and/or at least one output data flow. Output data flows usually have different names than Input data flows for a process Data flows only in one direction Every data flow connects to at least one process General rules for drawing the data flow diagrams. For each external entity, there should be at least one input or output for data flow coming in or going out from the external entity. For every data store, data cannot move directly from one data store to another data store. Data must be moved by a process. Naming, decomposition, balancing and consistency rules are discussed in details by Ibrahim and Yen Yen in [1]. I will not be defining syntax and semantics of the DFD assuming consistency checks have already taken place for the Data Flow Diagram. 4.2 DFD Example In our previous paper [7] we used an online bookstore system as an example. The online bookstore is a system that offers search, buy and compare capabilities for bookstores.

6 608 N. Olayan and S. Yamamoto Figures 2,3and 4 are sub levels of one of the process in the system, which is the search process; The Search process and its sub-processes are one of the simplest processes in the Bookstore system. To define the nature of the produced D-case; lets take a look at the following process and sub processes (Figures 2, 3and 4) to recognize the common rules. Visitor/ User Search Result Keyword Category 1 Search Search info bookstoreinfo usediteminfo Not found message websiteinfo Fig. 2. Level-0 diagram for the process "Search" Useditem keyword News Keyword 1.2 Search for used item Search info3 usediteminfo Category Result 3 Visitor/user Category Result 2 Not found Not found message message Keyword Not found message Category Result Search for News Search info2 bookstoreinfo Search info1 1.1 Search for item websiteinfo Fig. 3. Level-1 diagram for the process "Search" Keyword Category Verify Search info1 bookstoreinfo Visitor/user Result 1 Not found message Search notify Fig. 4. Level-2 diagram shows the decomposition of the process "Search for Bookstore items" To apply the concept of dependability to the whole bookstore system, we need to examine all the processes in the system. It is clearly easier to keep track of the system

7 A Consistency Check of Dependability Case (D-case) Produced from DFD 609 using our method, because as DFD Diagrams are created, each process would be investigated accordingly. The investigation includes every input, output, data store and the process itself. The Search process allows the user to search for Items, used items or News of the website. We can easily identify the attributes to be checked directly just by looking at the DFD and then argue over their dependability for each process. To elaborate the above-mentioned point, we will list the attributes to be checked for the Search process, it shows how easy it is to identify the concerned attributes: The inputs for the search process are: Search info 1,2 and 3 Item keyword (keyword), Used item keyword and News keyword Category Outputs are: Result 1, 2 and 3 Not found message Processes are: Search for item, search for used item and search for news Verify and search notify Data Stores are: BookstoreInfo,UsedItemInfo and WebsiteInfo 5 Constructing the D-Case from DFD (The Bottom Up Oriented Method) To identify the nature of the produced D-case lets take a look at the following Process decomposition structure for the previously mentioned Bookstore System (Figure.5). Fig. 5. Online Bookstore System processes (decomposition structure)

8 610 N. Olayan and S. Yamamoto Now lets take a look at the produced D-case diagram (Figure.6), as you can see there are three levels that corresponds to the DFD levels. Fig. 6. D-case diagram for Search process Our method was to basically investigate each process and sub process; the checks included the data flows in and out of the process and checks for data stores. On our previous paper we introduced a method to create a D-case from DFD, the paper explained the usefulness and validity of the method, we have also provided the steps and general rules for construction [7], as we were looking to improve the method gradually, we will introduce and explain this method as a simple addition to flatten the produced D-case and to make the process less time consuming. In this part, a bottom-up approach to produce D-case from DFD is elaborated. From (Figure.6) we can easily notice that the D-case diagram can grow large to multiple levels. To avoid such situation, the bottom-up proposes method, flattens the D-case diagram in the following steps: (a) Check the bottom processes: from (figure.5) the bottom processes have been underlined. (b) Start off by listing each bottom process and change it to an appropriate Goal name such as: process 1.1.1Verify (Figure.4) changed to > Verify of Search for item is dependable as in (Figure.7) Applying the previous method would save time and reduce levels in the produced Dcase The D-case diagram shown in Fig.6 corresponds the 3 levels of DFD structure in Fig.5 Replacing G_4 with G_7 and G_8 reduces the D-case diagram, as shown in following figure (Fig.7):

9 A Consistency Check of Dependability Case (D-case) Produced from DFD 611 Fig. 7. D-case diagram for Search is reduced 6 Rules for Consistency between DFD and D-Case and Semantics of the Produced D-Case from DFD 6.1 General Rules Every element that belongs to DFD must exist in the produced D-case. Produced D-case will not contain anything that isn t corresponded to the DFD Produced D-case should contain the correct element from DFD Every process in the DFD must be examined deep down to each sub process on each level. Every Process, Input/output and Data store must be examined. For every single D-case diagram there is one set data flow diagrams constructed from one context diagram. 6.2 The General Rule of Consistency by Definition of the Used DFD and the Produced D-Case Let D mean DFD then D=<DP, DE, DS> where: DP={dp1, dp2 dpm} a finite set of processes; DE={de1, de2,dem} a finite set of External entity ; DS = {ds1,ds2, dsm } a finite set of data stores; Let D-c mean D-case then D-c =<D-cg,D-cc,D-cs,D-ce> where: D-Cg={d-cg1,d-cg2,d-cgm} a finite set of Goals or claims; D-Cmg =main goal D-Cc={d-cc1,d-cc2,d-ccm} a finite set of Context; D-Cs={d-cs1,d-cs2,d-csm} a finite set of Strategy; D-Ce={d-ce1,d-ce2,d-cem} a finite set of Evidence;

10 612 N. Olayan and S. Yamamoto Now we can come up with the General rule to prove consistency of the produced Dcase from DFD: idpi,dei,dsi jd, jdpj,dej,dsjj d-cg,dpi,dei,dsi =dpj,dej,dsj, 1 i, j m Which means that every element that belongs to DFD must exist in the produced D-case. This rule should be true for every process, input/output and data store. 6.3 Checking D-Case Consistency According to Semantics As Figure 8 indicates we are applying the consistency checks in a one-way manner. The checks are applied while constructing the D-case from DFD. DFD [C-R] Consistency Rule D-case Fig. 8. One-way consistency check There must be one main Goal in the D-case, which states System is dependable, the system name is the same as in the context diagram. Context diagram is level 0 DFD, which is a one process diagram that shows the scope of the system and summarize the inputs and outputs (Figure.9) Every top process in level 1 of the DFD is mentioned in a Goal in the produced D- case. Fig. 9. Part of Context Diagram or Context Model of the Bookstore System (bulk process flow)

11 A Consistency Check of Dependability Case (D-case) Produced from DFD 613 Every leaf process in the DFD with no further sub process in the DFD diagram must be in a sub goal in the D-case (sub goal of the main top goal) and must be proven dependable. Main strategy must argue over each Process in the DFD in order to prove the top goal dependable. Every Input/output and Data store in the DFD must be checked under a strategy. 6.4 Consistency Check Tables From the above-mentioned rules in section 6 we can come up with check tables that could facilitate the consistency checks for the main elements to be tested for consistence: DFD: main process, top process, leaf process, input, output and data stores. D-Case: Goals and strategies. As processes are added to the DFD in the early stages of the analysis phase or after the design changes in the design phase, the check tables should be updated and a check should be commenced to determine how many sub process are there for each process. DFD levels and other information such as names are added as context to the D-case. Note: Context of D-case is the means by which the case references detailed artifacts that have been developed elsewhere. It is attached to a Goal or a strategy in the D- case. While Context of DFD is a model that represents the whole system from a broad view as level 0. The check tables are initially empty; it is filled as the D-case diagram is created. Creating the tables should be a prior step to updating the D-case from DFD. It is easier to use the tables than to roughly create the D-case because it organizes while help to keep track of changes. The check processes is unidirectional, it is used to check the produced D-case from DFD and not the other way around. The tables could also be used as a guide to create the D-case from DFD from scratch for a system after the analysis phase is done or even after the D-case is created. The Tables: Top Process Table (Table 1): Top Processes are level 1 DFD processes. o Check Column 1 and 2: All the processes must be top processes. There should be one main process. Processes must be correctly named and numbered in ascending order. o Assignment of Columns 3 and 4: every top Processes is assigned a Goal and a Strategy (including the main goal)

12 614 N. Olayan and S. Yamamoto Sub Processes Table (Table2) o Check Columns 1 and 2: The processes types are either Sub processes or Leaf process. Processes must be correctly named and numbered in ascending order o Assignment Column 3: Assign a Goal only for the Leaf processes. Leaf Processes Table (Table 3): Leaf processes are the DFD nodes with no further decomposition. o Check Column 1: All the processes in this table must be Leaf processes Processes must be correctly named and numbered in ascending order o Assignment Columns 2, 3,4 and 5: in every Leaf process assign 4 strategies to argue over inputs, outputs, Data stores and the process. Example: The following figure (Fig.10) shows a system with three main processes and their sub process, we will use this simple example to demonstrate the consistency Check tables. Where: C=Context model of DFD, X=Process, G=Goal of D-case, S=Strategy of D-case Fig. 10. Process X1, X2 and X3 and their sub processes The following tables (Tables 1,2and 3) show an example based on Figure 10. The process could also be implemented as an automated solution to save time and effort while keeping in mind that further checks are needed. Top Process from DFD Table 1. Top Process consistency check table Type Goal from D-case Strategy C1 Level 0 main Goal G1 S1 X1 Level 1 top goal G2 S2 X2 Level 1 top goal G3 S3 X3 Level 1 top goal G4 S4

13 A Consistency Check of Dependability Case (D-case) Produced from DFD 615 Table 2. Sub Process consistency check table Process from DFD Type Goal from D- case X1.1 Sub Process - X1.2 Leaf process G5 X1.3 Sub process - X1.1.1 Leaf process G6 X1.3.1 Leaf process G7 X2 Sub process - X2.1 Leaf process G8 X2.2 Leaf process G9 X.3 Leaf process G10 Leaf Process from DFD Argument by risk for Input Table 3. Leaf Process check table Argument by risk for Output Argument by risk for Data Store Argument by risk for Process X1.2 S5 S6 S7 S8 X1.1.1 S9 S10 S11 S12 X1.3.1 S13 S14 S15 S16 X2.1 S17 S18 S19 S20 X2.2 S21 S22 S23 S24 X3 S25 S26 S27 S28 7 Summary and Future Work A Consistency check method was proposed in this paper based on DFD and D-case and their definitions.it is easy to check a flatter D-case diagram (less levels) so a bottom-up approach was also proposed. Furthermore, The methods can contribute to risk mitigation by using the DFD functions as mentioned in our previous paper [7]. Defining the syntax and semantics of the D-case produced from DFD will help us set the rules and prove the consistency by checking the produced D-case manually. This can be very useful but time consuming, for future research those rules can be

14 616 N. Olayan and S. Yamamoto used to facilitate the process of producing the formalized rules by mathematical notation and therefore making it easy to produce an automated solution that could check the consistency automatically for this particular method. References 1. Ibrahim, R., YenYen, S.: A Formal Model for Data Flow Diagram Rules. International Journal of Software Engineering & Applications 1(2), (2010) 2. The Agda Wiki, 3. Dependability Case Editor with Pattern LibraryYutaka Matsuno, Hiroki Takamura,Yutaka Ishikawa Information Technology Center/ The University of Tokyo 4. Tong, L., Tang, C.S.: Semantic Specification and Verification of Data Flow Diagrams. Journal of Computer Science and Technology 6(1), (1991) 5. Yutaka, M., Takai, T., Yamamoto, S.: D- Case Pocket Book Let s write Dependability Cases! Asset Management Co. Ltd., (2012) ISBN: Bruza, P.D., Van der Weide, T.P.: The Semantics of Data Flow Diagrams. University of Nijmegen (1993) 7. Olayan, N., Patu, V., Matsuno, Y., Yamamoto, S.: A Dependability Assurance Method Based on Data Flow Diagram (DFD). In: 2013 European Modeling Symposium (EMS), pp (2013) 8. Dennis, A., Wixom, B.H., Roth, R.M.: System Analysis and Design, 4th edn. John Wiley and sons, USA (2008) 9. Kelly, T., Weaver, R.: The Goal Structuring Notation - A Safety Argument Notation. In: Proceedings of the Dependable Systems and Networks 2004 Workshop on Assurance Cases (July 2004)