ABSTRACT: This paper describes a mathematical approach based on a model-checking technique to analyze capabilities in enterprise architectures developed by using DoDAF and TOGAF architecture frameworks. Such approach base is the requirements’ validation related to the enterprise capabilities by employing operational or business artifacts associated with the dynamic behavior processes. We show how this approach can be used to quantitatively verify if the operational models in an enterprise architecture can achieve the enterprise capabilities by using a case study connected to a capability integration problem.
Keywords:Capability analysisCapability analysis,enterprise architecturesenterprise architectures,DoDAFDoDAF,model-checkingmodel-checking,requirementsrequirements,TOGAFTOGAF.
RESUMEN: Este trabajo describe un enfoque matemático basado en una técnica de validación de modelos para analizar capacidades en arquitecturas empresariales construidas utilizando los marcos arquitecturales DoDAF y TOGAF. La base de este enfoque es la validación de requerimientos relacionados con las capacidades empresariales empleando artefactos arquitecturales operacionales o de negocio asociados con el comportamiento dinámico de los procesos. Se muestra cómo este enfoque puede ser utilizado para verificar, de forma cuantitativa, si los modelos operacionales en una arquitectura empresarial pueden satisfacer las capacidades empresariales. Para ello, se utiliza un estudio de caso relacionado con un problema de integración de capacidades.
Palabras clave: Análisis de capacidades, arquitecturas empresariales, DoDAF, evaluación de modelos, requerimientos, TOGAF.
Artículo original
Architectural capability analysis using a model-checking technique
Análisis de Capacidades en arquitecturas utilizando técnicas de evaluación de modelos
Facultad de Ingeniería, Universidad de Antioquia
Received: 11 October 2016
Accepted: 04 April 2017
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 fix1) (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 only2) (3) (4) (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 247656 (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 goals7) (8. An organizational capability represents skills that organizations have that can create value9. This paper shows an approach based on a model-checking methodology1 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 frameworks11) (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.
The model-checking (MC) technique proposed by Clarke & Emerson13 and Queille & Sifakis14 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.
Figure 1
Requirements validation general scheme using model-checking
Failure detection using MC follows the next steps:
- 1. Convert the system behavioral models into formal models (LTS-Labeled Transition Systems).
- 2. Specify the system requirements in terms of logic temporal specifications (LTL).
- 3. Use an MC tool to execute the LTL and determine compliance.
Systems architectures are developed to work as a bridge between requirements and design in complex systems15 by using an ADM (Architecture Development Method) cycle16 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.
Figure 2
A generic scheme for systems architecture
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, SysML17 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.
Figure 3
Possible architectural models using SysML
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, ADM16. 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.
Figure 4
Structure, behavior, and design requirements
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.
Figure 5
General perspective to the custom implants design system (CIDS)
From the system architectural point of view, the OV-6b model is taken as a sample to analyze the system behavior, see Figure 6.
Figure 6
LTS fragment, CAD tool states in the CIDS system
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):
- 1. S is a set of states,
- 2. Act is a set of actions
- 3.
is a transition relation, - 4.
is a set of initial states, - 5. AP is a set of atomic propositions, and
- 6.
L: S 2APis a labeling function.
Figure 7
OV-6b model fragment, Statechart diagram fragment for CAD tool in the CIDS system
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.
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.
L function deployment
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:
pi ϵ AP is a formula
If 
and 
are formulas, then 
are also.
An LTL formula interpretation is an infinite word w = x0x1x2… over the set 2AP . Then for each time instant in the system execution, there is a subset of AP that is active. Being wi the word w starting with xi that comes from the TS execution, the LTL semantics is defined as follow. See Figure 8.
1) 
2) 
3) 
4) 
5) 
6) 
Figure 8
Intuitive view for a LTL
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: 
.
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 < a0a1a2 ··· > over Σ is an infinite word <s0s1s2 ··· > over Q, so that s=q0 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.
Operators to formulate LTL formulas
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.
LTL formulas for the CAD requirements
Requirement elicitation is the most effective phase of systems development processes. Such elicitation aims to correctly meet the stakeholders’ requirements20 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.
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:
- 1. A designed capability tries to meet one or many requirements.
- 2. A requirement is a condition or capability needed by a user to solve a problem or achieve an objective.
- 3. 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):
- 1. Relate capabilities and requirements.
- 2. Validate the requirements by using a model-checking approach.
- 3. Analyze and categorize results in capabilities terms.
Figure 10
Methodological scheme for capability analysis by using a model-checking technique
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).
Capabilities list obtained from the CV-2 model
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).
Figure 11
Capability and requirements relationship for the CAD tool
A weight factor vector Cw for capabilities and Rw for the requirements can be obtained from the relations. The vector CR,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 Ci . See an example in Table 6. Additionally, the correlation matrix Cc that contains the correlation between capabilities can also be obtained. (See the HOQ roof in Figure 11).
Requirements related with the capability C8 (Implant modeling)
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 Os,i , Oa,i , and Ol,i contain the respective testing results, see Table 7.
Capability testing report for C8 capability
In order to determine if a capability is achieved, the next variables are defined: Ni: the number of properties to verify the capability Ci 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 Os,i , Oa,i or Ol,i , there are six possible results when the model-checking process is carried out:
- 1. All the properties are achieved to the capability Ci .
- 2. Some properties are not achieved and the counter examples are shown.
- 3. None of the properties are fulfilled nor are the counter examples shown.
- 4. Some results are not conclusive.
- 5. The entire set of properties does not have conclusive results.
- 6. 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 Os,i , Oa,i , and Ol,i are being taken into account. To summarize, the combined results are presented in Table 8.
Result analysis for the capability Ci
According to Table 8, only one from the six options is selected as an output for the Os,i , Oa,i , and Ol,I sets. It is proposed to assign a possible value for each possible result, see Table 9.
Value assignment proposal for the results in Os,i , Oa,i , and Ol,i
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)
Capability compliance certainty levels
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 Kf indicate that the capabilities are well incorporated, but the values closer to -Kf 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.
Compliance analysis and indicator
Figure 12 represents the compliance indicator to analyze the implications of the capability analysis.
Figure 12
Graphical representation of the compliance indicator
Besides, the capabilities affected by an analysis can be obtained from the correlation matrix Cc. Particularly, if the capabilities C1,C9,C11, and C12 could be affected.
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 Cw,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 Kf or -Kf 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 Tc values that indicate how well integrated and designed the capabilities are. It is also important to take into account that Tc 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.
This research was supported by the Administrative Department of Science, Technology and Innovation (COLCIENCIAS); it has been funded by Francisco José de Caldas Doctoral Program Scholarship # 511. We thank Anna Shchiptsova who greatly assisted the research and the International Institute for Applied Systems Analysis (IIASA) that provided insight and expertise in the Advanced Systems Analysis area.
* Corresponding author: Darío José Delgado Quintero e-mail: dario.delgado@correo.uis.edu.co
Figure 1
Requirements validation general scheme using model-checking
Figure 2
A generic scheme for systems architecture
Figure 3
Possible architectural models using SysML
Figure 4
Structure, behavior, and design requirements
Figure 5
General perspective to the custom implants design system (CIDS)
Figure 6
LTS fragment, CAD tool states in the CIDS system
Figure 7
OV-6b model fragment, Statechart diagram fragment for CAD tool in the CIDS system
Requirements list for the CAD tool obtained from the requirements model and atomic propositions obtained from OV-6a model
L function deployment
Figure 8
Intuitive view for a LTL
Operators to formulate LTL formulas
LTL formulas for the CAD requirements
Figure 10
Methodological scheme for capability analysis by using a model-checking technique
Capabilities list obtained from the CV-2 model
Figure 11
Capability and requirements relationship for the CAD tool
Requirements related with the capability C8 (Implant modeling)
Capability testing report for C8 capability
Result analysis for the capability Ci
Value assignment proposal for the results in Os,i , Oa,i , and Ol,i
Capability compliance certainty levels
Compliance analysis and indicator
Figure 12
Graphical representation of the compliance indicator
