English (pdf)
Article in xml format
Article references
Automatic translation
Send this article by e-mail
Cited by SciELO 
Cited by Google 
Similars in
SciELO 
Similars in Google 
Permalink
1. Introduction
In systems designing, early fault detection is one of the biggest challenges due to software crises. In Software, fault detection is less than 10% in the conceptual design phase and around 40% of the failures are introduced in this phase. Thus compared with the cost to fix a fault during the design phase, a fault in an operational or testing phase is more expensive to fix[1,2].This is especially true during most of the systems development procedures; fault detection during the design phase usually consists of models’ logical verification (UML, SysML, BPMN, etc.) and the requirement compliance in the design models only[2-5]. However, logical verification of models only ensures the fault detection associated with the stakeholders needs, but that approach cannot ensure that the system could achieve its behavioral goals. There exist other approaches to reduce the fault insertion by goal-oriented requirement engineering (GORE)[5] Those approaches try to ensure that elicitation, analysis, elaboration and refinement, specification and modeling of requirements are related to the specified goals for a particular solution. As a result, this article is focused on fault-detection confirmation approaches by using logical verification of models that seek to ensure the achievement of their behavioral goals.
ISO/IEC/IEEE 24765[6] (System and software engineering - Vocabulary) defines a requirement as "a condition or capability needed by a user to solve a problem or achieve an objective". In an architectural environment, business requirements support the business capabilities designing, architectural models- especially in the business or operational views- represent those capabilities, and the capabilities designs seek to satisfy the requirements and achieve the organizational goals[7,8]. An organizational capability represents skills that organizations have that can create value[9]. This paper shows an approach based on a model-checking methodology[1] to verify models in terms of capabilities. This approach seeks to detect faults related to the organizational goals.
In order to implement the capability model-checking approach, a Custom Implants Design System (CIDS)[10] is employed with an architecture implementation that uses DoDAF and TOGAF architectural frameworks[11,12]. To describe the approach, this document is organized as follows: the first part describes the model-checking technique, the second part shows the approach for capability model-checking. Finally, the analysis and conclusions are presented. All the parts contain an application example by including the CIDS system.
2. Model-checking as a fault detection technique
The model-checking (MC) technique proposed by Clarke & Emerson[13] and Queille & Sifakis[14] is an automatic technique for finite state systems verification regarding some temporary logical specifications. The standard approach focuses on the semi-formal models: SysML (System modeling language), UML (Unified Modeling Language), BPMN (Business Process Model and Notation), etc. Especially those that describe the system behavior with behavioral models to develop formal ones (executable) aim at verifying dynamic aspects of the systems and detecting failures through a model-checking tool. See Figure 1.
Failure detection using MC follows the next steps:
Convert the system behavioral models into formal models (LTS-Labeled Transition Systems).
Specify the system requirements in terms of logic temporal specifications (LTL).
Use an MC tool to execute the LTL and determine compliance.
2.1 Behavioral models and Kripke structures
Systems architectures are developed to work as a bridge between requirements and design in complex systems[15] by using an ADM (Architecture Development Method) cycle[16] that describes the system organization in term of its components and interactions. SAs divide the analyses into structural component and functional component analyses, which are both related, but conduct different activities. See Figure 2.
Architectural models are developed by using modeling languages such as UML, SysML, BPMN, among others, that display different classifications according to their viewpoints. However, the architectural viewpoints, in general, are classified in terms of behavior, requirements, and structure. For example, SysML[17] architectural model classification is particularly considered in this paper (see Figure 3). Regarding other architectural frameworks as TOGAF or DoDAF, the possible models have a different classification. TOGAF, for instance, categorizes them as business, information and systems, and technology views. In contrast, DoDAF categorizes the architecture as capability, operational, services, and systems views.
For the purpose of this paper, two AF (Architectural Frameworks), TOGAF and DoDAF are mixed in order to standardize a set of capability models that DoDAF includes combined with the implementation method that TOGAF provides, namely, ADM[16]. Another reason for this blend is that DoDAF, in comparison with other AF such as Zachman, 4+1 Views, FEAF, among others, do not support a capability model design approach directly. Hence DoDAF and TOGAF terminology are both used to carry out this paper’s procedure: a capability analysis in the architecture through the requirement model, capability models (CV), and the business views represented by the operational models (OV) in the architecture.
The proper system behavior is connected to the requirement fulfillment stipulated by the stakeholders. The MC techniques seek to verify the requirement fulfillment using the behavior models (see Figure 4). For this purpose, it uses state machine (SM) diagrams. SM is a useful graphical tool to describe the dynamic system behavior from an architectural point of view. The OV models represent the system behavior; OV-6b (State Transition Description) is an example.
2.1 Case study
A Custom Implants Design System (CIDS)[9] is presented here. It uses some software packages: BioCAD, CAD, and CAE to model digital volumes and verify by simulation, as well as a 3D printer through rapid prototyping (RP) of Osteosynthesis implants. See Figure 5.
From the system architectural point of view, the OV-6b model is taken as a sample to analyze the system behavior, see Figure 6.
OV-6b is a Statechart (SC) diagram used to describe the detailed sequencing of activities or work flow in the business process. It is useful for describing critical sequencing of behaviors and timing of operational activities that cannot be adequately described in the OV-5b Operational Activity Model. It could be defined as a tuple: SC={S,Var,G,E,Edges}, where S is the states set, E is the set of events, Var is the state variables set, G is the guards set, and Edges is the transitions set.
Although UML Statechart diagrams count on their own semantics and syntax, a system behavior graphic is represented here. The SC diagrams need to be transformed into an executable model with a mathematical formality.
Transition Systems (TS) are used here. They consist of a set of states and transitions such as labels denoted by actions and one initial state, to represent the behavior and communication between components in a concurrent system (see Figure 7). TS is a tuple (S, Act, 
, I, AP, L):
S is a set of states,
Act is a set of actions
is a transition relation,
is a set of initial states,AP is a set of atomic propositions, and
L: S
2APis a labeling function.
Statechart diagrams and transition systems models have common elements: set of states S, events E, guards G, transition Edges represented in TS as the actions Act, and the transition relations ( In contrast, The SC diagram does not contain the atomic propositions AP nor the labeling function L. The AP are defined as hidden actions in the system related to the requirements. See Table 1.
Table 1 Requirements list for the CAD tool obtained from the requirements model and atomic propositions obtained from OV-6a model
The labeling function L creates a relation between a state si ϵ S and a proposition pj 𝜖 AP (see Table 2). The AP and L are used to create a relation between system requirements and behavior models. Then, before transforming the SC diagram into a TS, the system requirements need to be represented in labels. In turn, they represent specific actions obtained from the OV - 6a model (Operational rules model), which is an activity diagram that contains the detailed set of operations, activities, and guards that specify each state and satisfy each requirement. In summary, labeled function L allows to execute the TS in system requirements terms.
2.3. Linear Temporal Logic Specifications (LTLs)
A TS execution is a sequence of actions (2AP) that can be executed starting with an initial state I. A TS = (S, Act,, I, AP, L) transits TS’ = (S, Act,, I’, AP, L) by an action a denoted as 
The L function in the LTS ts = (S, Act,,I) takes a set of AP that come from activities related to system requirements and transform the Labeled Transition System LTS in TS = (S, Act,, I, AP, L). Here the system behavior is labeled with a set of actions that are directly related to requirements. Such system behavior can be evaluated with the TS execution, specifically, L function.
An LTL formula is a mathematical language for describing linear-time properties; it is a widely used logic for expressing properties of programs viewed as sets of executions, and it is inductively defined by using Boolean and temporal operators X (next) and U (until), given an AP:
1) p i ϵ AP is a formula
2) If 
and 
are formulas, then 
are also.
An LTL formula interpretation is an infinite word w = x 0 x 1 x 2… over the set 2 AP . Then for each time instant in the system execution, there is a subset of AP that is active. Being w i the word w starting with x i that comes from the TS execution, the LTL semantics is defined as follow. See Figure 8.
There are additional operators proposed by Giannakopoulou in[15]: 
, 
, the Boolean operator 
that is defined as 
, and the temporal operators <> (Eventually), 
(Always), W (Weak until) defined in terms of the main temporal operators: 
.
2.4 Use of transition systems to verify LTLs formulas
The LTL verification basic scheme is based on the use of Büchi automatons (BA)[18,19]. A BA is a 5-tuple B =<Q,Σ,δ,q0,
F >, where Q is a finite set of states, Σ is a finite set of labels, 
is a labeled transition relation, q0 ϵ Q is the initial state, and 
is the set of accepted states.
A B execution in a finite word < a
0
a
1
a
2 ··· > over Σ is an infinite word <s
0
s
1
s
2 ··· > over Q, so that s
=
q
0 and 
. If any elements in F occur infinitely, an execution is accepted and an infinite word w over Σ is accepted by the automaton B if there are any executions from B in w.
For an LTL formula over a set of AP, we formulated a BA to accept words over 2AP that satisfy 
. A finite state system is verified by an LTL specification by calculating the intersection between the system and the BA (¬). The TS satisfy if the intersection does not accept words.
LTL functions in AP terms is designed here to try to verify the requirements in the systems behavior models. The set of operators used are shown in Table 3.
An LTL formula F is designed for each requirement. A model-checking tool is used to verify (see Table 4). An LTSA analyzer is employed here. When a requirement is validated by using an LTL formula, one of these three different results is obtained:
1) The property (requirement) is fulfilled.
2) The property (requirement) is not fulfilled and a counter example is shown.
3) The test generates an inconclusive result.
2.5 The problem of requirement verification
Requirement elicitation is the most effective phase of systems development processes. Such elicitation aims to correctly meet the stakeholders’ requirements[20] so that the systems models design is allowed. However, as we can see in the Figure 9, a simple requirement verification in the systems models can only ensure that the stakeholders’ needs are fulfilled, but it cannot ensure that the stakeholders’ intentions are achieved with designed models.
3. Capability analysis by using a model-checking scheme
A system capability represents the ability to perform certain actions or outcomes through a set of controllable and measurable faculties, features, functions, processes, or services. From an architectural point of view, we model capabilities to meet the stakeholder requirements and organizational goals. In order to meet a set of requirements: R = {r1,r2,…,rm}, a set of capabilities C = {c1,c2,…,cn} is designed. In the architecture, capabilities C are represented as a set of behavioral models that deploy them in terms of operational activities.
In this article, a capability verification approach is proposed by using a model-checking scheme. Such approach is based on the next assumptions:
A designed capability tries to meet one or many requirements.
A requirement is a condition or capability needed by a user to solve a problem or achieve an objective.
Capabilities provide an environment to meet the organizational goals.
In short, these are the general steps to carry out the capability analysis (see Figure 10)):
Relate capabilities and requirements.
Validate the requirements by using a model-checking approach.
Analyze and categorize results in capabilities terms.
3.1. Capabilities and requirements
The first assumption previously mentioned states that a capability is designed to meet one or many requirements. Nevertheless, a capability is a formal system component and a requirement is an informal stakeholder need (see Table 1 and Table 5).
An efficient and organized technique to translate the "Stakeholder voice" into the "Engineering voice" or designers is the process of quality function deploy (QFD)[22]. It is a useful tool to associate qualitative and ambiguous requirements with systems attributes. For the purpose of this article, an adaptation of QFD and the house of quality HOQ have been employed to relate the requirements to specific properties in the system.
The properties of interest are the system capabilities. The HOQ methodology denotes the relations between requirements and capabilities as strong ⓪[9], average ○[3], and weak Δ[1]. The relation between capabilities is defined as positive + and negative - correlations. As the name implies, a positive correlation means that a positive capability achievement has a positive impact over the capability related. A negative correlation, on the other hand, means that a capability positive achievement has a negative impact over the capability related (see Figure 11).
A weight factor vector C w for capabilities and R w for the requirements can be obtained from the relations. The vector C R,i to i = 1,2,···n, where n is the number of capabilities in the system, is obtained from Table 5 CR,i contains all the requirements (strong, average, and weak) related to the capability C i . See an example in Table 6. Additionally, the correlation matrix C c that contains the correlation between capabilities can also be obtained. (See the HOQ roof in Figure 11).
3.2. Capability analysis
To carry out the capability analysis, it is necessary to observe the models in Figure 6, since it represents the designed capabilities to meet the requirements that need the LTL formulas, as shown in Table 4.
From the CR,i vector that contains the requirements for the capability Ci, three additional vectors are denoted: Rs,i, Ra,i, Rl,i ϵ R, where 
That represents the strong, average, and low requirements related to the capability Ci.
In addition to the LTL formulas related to the requirements Rs,i, Ra,i, Rl,i, the 
vectors are formulated and they contain the respective set of requirements (strong, average, and low). Being 
the behavioral model used, the LTSA tool proceed to verify if the LTL formulas 
satisfy the behavior model.
When the set of properties 
are tested, the vectors O
s,i
, O
a,i
, and O
l,i
contain the respective testing results, see Table 7.
In order to determine if a capability is achieved, the next variables are defined: N
i
: the number of properties to verify the capability C
i
in , Ki,Li,Ti ϵ ℕ: the number of properties evaluated in Os,i, Oa,i and Ol,i. αs,i, βs,i and γs,i: the positive, negative, and inconclusive results obtained for the strongly related properties 
.
In the same way, αa,i, βa,i and γa,i are defined as the average related properties, and αl,i, βl,i and γl,i as the weakly related properties. The capability analysis also needs the Eqs (1, 2 and 3) since they indicate the number of properties verified for the strong, average, and low requirements related to the capability Ci, and the Eq. (4) represents the total number of requirements related to a particular capability.
(1)
(2)
(3)
(4)
For a particular set O s,i , O a,i or O l,i , there are six possible results when the model-checking process is carried out:
All the properties are achieved to the capability C i .
Some properties are not achieved and the counter examples are shown.
None of the properties are fulfilled nor are the counter examples shown.
Some results are not conclusive.
The entire set of properties does not have conclusive results.
Some properties are achieved.
In a capability model checking verification, it is possible to obtain a combination of results when the three sets of properties O s,i , O a,i , and O l,i are being taken into account. To summarize, the combined results are presented in Table 8.
According to Table 8, only one from the six options is selected as an output for the O s,i , O a,i , and O l,I sets. It is proposed to assign a possible value for each possible result, see Table 9.
When the requirements associated with a particular capability are verified, a general value that summarizes the capability fulfillment is needed, see Eq. (5). 
. It represents a certainty value associated with the requirements fulfillment in the capability Ci (see Table 10).
(5)
3.3. Result analysis
For this particular case study -analysis of the capability associated with the CAD tool-, it is possible to obtain a compliance analysis and indicator. See Table 11.
denotes the compliance indicator for a particular capability, 
the weight for the entire capabilities, 
the compliance indicator for the entire capabilities, and 
the domain in which 
exists. 
defines the compliance value for each capability; negative values mean low expectations, positive values mean high expectations, and null values mean that nothing can be said about the capability achievement. The capability integration 
shows a measurement of the entire capabilities achievement. The values that are closer to K
f
indicate that the capabilities are well incorporated, but the values closer to - K
f
indicate that the capabilities incorporation by the system is poor. Finally, the values that are closer to zero (0) indicate that no capability analysis could correctly be performed.
Figure 12 represents the compliance indicator to analyze the implications of the capability analysis.
Besides, the capabilities affected by an analysis can be obtained from the correlation matrix Cc. Particularly, if the capabilities C 1,C 9,C 11, and C 12 could be affected.
4. Analysis and conclusions
With each capability compliance indicator, a notion on how the system general goal are met can be obtained at an early phase, as well as whether those goals could be achieved with the corresponding designed capabilities.
Particularly, the 
indicator measures three important aspects. Firstly, the capability weight C
w,i
indicates how important the capability is in relation to the stakeholder requirements. Secondly, the capability compliance certainty indicates how well designed a capability is. Thirdly, the compliance indicator domain 
indicates the interval in which exists.
A value less than zero is an indicator of a wrong capability design. In contrast, a value greater than zero is an indicator of a good capability design. A value close to zero indicates that the capability design must be thoroughly checked. Finally, a value close to K
f
or - K
f
indicates that capability designed is well conceived or an entire design change is needed, with a high certainty.
When the analysis includes more than one capability, the same analysis is carried out by using the T
c
values that indicate how well integrated and designed the capabilities are. It is also important to take into account that T
c
is more related to system goals than values.
Using the capability as an evaluation item of a fault detection model instead of directly using requirements allowing to detect problems at systems design early stages. This type of analysis is associated with the systems’ goals rather than stakeholder needs. So it is useful for fault insertions reduction at early stages and correct systems goals design.
