iArch-U/MC: An Uncertainty-Aware Model Checker

for Embracing Known Unknowns

Naoyasu Ubayas hi, Yasutaka Kamei and Ryo suke Sato

Kyushu University, Fukuoka, Japan

Keywords:

Model Checking, Uncertainty, Known Unknowns, Modular Uncertainty R epresentation, Partial Model, State

Explosion Problem.

Abstract:

Embracing uncertainty in software development is one of the crucial research topics in software engineering.

In most projects, we have to deal with uncertain concerns by using informal ways such as documents, mailing

lists, or issue tracking systems. This task is tedious and error-prone. Especially, uncertainty in programming

is one of the challenging issues to be tackled, because it is difﬁcult to verify the correctness of a program when

there are uncertain user requirements, unﬁxed design choices, and alternative algorithms. This paper proposes

iArch-U/MC, an uncertainty-aware model checker for verifying whether or not some important properties are

guaranteed even if Known Unknowns remain in a program. Our tool is based on LTSA (Labelled Transition

System Analyzer) and is implemented as an Eclipse plug-in.

1 INTRODUCTION

Embracing uncertainty in software development is

one of the crucial research topics in software engi-

neering. Garlan, D. discusses the future of software

engineer ing from the view point of uncertainty (Gar-

lan, 2010). He argues that we must embrace un-

certainty within the engineering discipline of soft-

ware engineering. There are two kinds of uncertainty:

Known Unknowns and Unknown Unknowns (Elbaum

and Rosenblum, 2014). In Known Unknowns, there

are u ncertain issues in the process of software de-

velopment. However, these issues are known and

shared among the stakeholders including developers

and customers. For example, there are alternative re-

quirements althoug h it is uncertain which alternative

should be selected. On the other hand, in Unknown

Unknowns, it is uncertain wh a t is uncer ta in. It is dif-

ﬁcult to deal with Unknown Unknowns, because we

cannot pre dict the appearance of this kind of uncer-

tainty. In this paper, we focus on Known Unknowns

as the ﬁrst research step .

It is important to systematically describe and ve-

rify a program if we have to embrace uncertainties in

the software development. Unfortu nately, program-

ming under uncertainty is not yet appropriately sup -

ported. It would be preferab le to be able to modu-

larize uncertain concerns and check whether the im-

portant properties concerning to the require ments and

designs are satisﬁed even if there are uncertain con -

cerns. We can c ontinue the development if the pro-

perties hold, because the de cision can be deferred.

To deal with this problem, we propose the design

and implementation of iArch-U/MC

, a model chec-

ker for verifying whether or not some impor ta nt pr o-

perties such as functionality and deadlock freedom

are guaranteed even if Known U nknowns remain in

a program. Using this uncertainty-aware model chec-

ker, we can postpone the decision for dealing with un-

certainty to th e later software development phase if

the selection of uncertain a lternatives doe s not affect

the corr e ctness of the properties.

In th is paper, we introduce a new programming

style to realize a n uncertain ty-aware mo del checking:

1) an interface mec hanism for modular uncertainty re-

presentation based o n par tial model (Famelis et al.,

2012), a single model containing all possible alterna-

tive d esigns of a system; 2) type checker for guaran-

teeing the reﬁnement simulation between an interface

and its sour c e code; and 3) model checker for veri-

fying whether or not a partial model generated from

an un c ertainty-aware interface satisﬁes an important

The iArch-U (Watanabe et al., 2017) is an IDE (Integra-

ted Development Environment) for supporting uncertainty-

aware software development. The iArch-U/MC, one of the

iArch-U tool components, supports model checking. This

paper focuses on only the design and implementation of our

uncertainty-aware model checker.

176

Ubayashi, N., Kamei, Y. and Sato, R.

iArch-U/MC: An Uncertainty-Aware Model Checker for Embracing Known Unknowns.

DOI: 10.5220/0006889501760184

In Proceedings of the 13th International Conference on Software Technologies (ICSOFT 2018), pages 176-184

ISBN: 978-989-758-320-9

property. Although model checking is performed at

the interface-level (an abstraction of the code), the

behavior of a program is also guaranteed in terms of

interface descriptions. The reason is that there is a si-

mulation relation between the interface and the co de

if type checking is passed. Our a pproach can relax

the state explosion problem because of the combinati-

onal usage of interface-level model checking and type

checking. Our tool is implemented as an Eclipse plug-

in and su pports uncertainty in Java programming.

This paper is structured as follows. We survey the

related work on uncerta inty in Section 2. Section 3 in-

troduces an unce rtainty-aware interface mechanism.

Section 4 shows our approach to type checking and

model checking. Section 5 shows the overview of

iArch-U/MC. We discuss on the originality and the ap-

plicability of our approach in Section 6. Concluding

remarks are p rovided in Section 7.

2 RELATED WORK

Recently, uncertainty has attracted a growing interest

among researchers. Most of the state-of-the-art stu-

dies focus on Known Unknowns. As a representa-

tive work, a method for expressing Known Unk no-

wns using partial model is proposed in (Famelis et al.,

2012; Famelis et al., 2015). A partial model is a single

model containing all possible alternative designs of a

system and is encoded in propositional logic. We c an

check whether or not a mod el includin g unc ertainty

satisﬁes some interesting properties. The idea of par-

tial model ﬁts the ne eds in real software d evelopment

projects, because alternatives appearing in a software

design model or a source program ca n be represented

as a single model by using partial model. This partial

model is effective for a developer to manag e uncer-

tainty in design and coding phases. For this reason,

our approach is based on partial mod e l.

Perez-Palacin, D. and Mirandola, R. provide a

systematic review on unce rtainty (Pere z-Palacin and

Mirandola , 2014) and summarize as follows: The

most used deﬁ nitions of uncertainty simply distin-

guish b etween natural variability of physical proces-

ses (i.e., aleatory or stochastic uncertainty) and the

uncertainties in knowledge of these proce sses (i.e.,

epistemic or state-of-kno wledge uncertainty) .

The state-of-the-art research themes sp read over

uncertainty of requirements mod eling, software ar-

chitecture, model transformations, program ming,

testing, veriﬁcation, and performance engineering.

In ( Salay et al., 2013a), partial model is applied to

uncertainty in requirements to addr ess the problem

of specifying uncertainty within a requirements mo-

del, reﬁning a model as uncertainty reduces, provi-

ding meaning to tracea bility relations betwee n models

containing unc e rtainty, and propagatin g uncertainty-

reducing changes between related models. In (Au-

tili et al. , 201 2; Esfahani et al., 20 12; Esfahani et al. ,

2013; Lag o and Vliet, 2005), uncertainty is explored

in terms of software architecture. Letier, E et al. pre-

sent a support method for eva luating uncertainty, its

impact on risk, and the value of reducing uncertainty

in requirements and arch itec ture (Letier et al., 2014).

In (Salay et a l., 2013b), a method for change prop a-

gation in the context of model uncertainty is propo-

sed. Most of these studies focus on epistemic uncer-

tainty. Un c ertain< T >, a simple probabilistic pro-

gramming language for letting programme rs without

statistics exper tise easily a nd cor rectly compute with

estimates (Bornholt et al., 2014). Uncertain< T >

deals with aleatory uncertainty. Elbaum, S. and Ro-

senblum, D. S. explo re how uncertainty affects soft-

ware testing (Elbaum a nd Rosenblum, 2014). Uncer-

tainty in self-ad a ptive systems is explor ed in (Cheng

and Garlan, 2007; Esfahani et al., 2011; Esfahani

and Malek, 201 3; Perez-Palacin and Mirandola, 2014;

Whittle et al., 2010; Yang et al., 201 4). Performance

and reliability analysis under u ncertainty is exp lored

in (Devaraj et al., 2010; K. and S., 2003; Meedeniya

et al., 2011; Trubiani et al., 2013).

Uncertainty has been well studied in the ﬁeld of

formal method s: PRISM (Hinton et al., 200 6), a pro-

babilistic symbol model checker, can deal with ale-

atory uncertainty; and th ree-valued logic consisting

True

False

, and

Undefined

can represent epis-

temic uncertainty as in VDM (Vienna Development

Method) (Fitzgerald and Larsen, 1998). Unfortuna-

tely, it is not easy to check w hether or not a program

behaves cor rectly at the source code level when there

are Known Unknowns, because there are m a ny beha-

vioral possibilities in the program.

Although uncertainty is an imp ortant research is-

sue, uncertainty in programm ing and modular reaso-

ning has not been well explored. One of the reasons

why uncertainty cannot be dealt with in c urrent pro -

gramming languages is that the state-of-the-art mo-

dule me chanisms do not regard an uncertain concern

as a ﬁrst-class pluggab le software module. If uncer-

tainty can be dealt with modularly, we can add or de-

lete uncer tain conc e rns to/from code whenever these

concerns appear or disappear. Moreover, we can ve-

rify the correctness of a program modularly and efﬁ-

ciently if uncertain ty is repr esented modularly. In this

paper, we show an uncertainty-aware model checking

approa c h for modular reasoning.

iArch-U/MC: An Uncertainty-Aware Model Checker for Embracing Known Unknowns

177

[List 1]

01: interface component cPrinter {

02: public void get();

03: public void put();

04: public void print();

05: [public void utility();]

06: }

07:

08: interface component cScanner {

09: public void get();

10: public void put();

11: public void scan();

12: [public void utility();]

13: }

14:

15: interface component cCopyMachine {

16: public void copy();

17: }

18: interface connector cSystem (

19: cCopyMachine P, cCopyMachine Q,

20: cPrinter printer, cScanner scanner) {

21:

22: GET = (printer.get -> scanner.get);

23: PUT = (printer.put -> scanner.put);

24: COPY = (scanner.scan -> printer.print);

25:

26: P.copy = (GET -> COPY -> PUT -> P.copy);

27: Q.copy = (GET -> COPY -> PUT -> Q.copy);

28: }

[List 2]

01: interface connector uSystem

02: extends cSystem (

03: cPrinter printer, cScanner scanner) {

04:

05: GET = ({printer.get -> scanner.get,

06: scanner.get -> printer.get});

07: }

Figure 1: Archface-U Description (Printer-Scanner System).

3 MODULAR PROGRAMMING

FOR UNCERTAINTY

We adopt an interface mechanism to realize modular

programming for uncertainty. In this section, we in-

troduce the inte rface mechanism called Archface-U to

represent uncertainty based on partial mo del by refer-

ring o ur prelim inary work (Fukamachi et al., 2015 a ;

Fukamach i et al., 2015b).

Archface-U, an abbreviation of architectural in-

terface for uncertainty, represents an abstract pro-

gram structure in terms of c omponent-and- c onnector

architecture consisting of two kinds o f interface: com-

ponen t an d connector. Figure 1 (Printer-Scanner Sy-

stem), a well-known parallel system that falls into

a d eadlock (Mag ee and Krame r, 20 06), is an exam-

ple of Archface-U descriptions. Two processes P a nd

Q a c quire the lock from each of the shared resour-

ces, the printer and the scanner, and then releases

the locks. The sy mbols



and



represent alter-

native and optional, respectively. A component is

the same with ord inary Java interface. A c onnector,

which is speciﬁed using the notation similar to FSP

(Finite State Processes) (Magee and Kramer, 2006),

deﬁnes the message interactions among compone nts.

In Archface-U, unc ertain concerns are deﬁned as a

sub interface as shown in List 2. By extending the

existing interface, we can introduce uncertainty mo -

dularly. The

uSystem

interface, an extension of the

cSystem

interface, introduces uncertainty by over-

writing the existing

GET

message sequence. In List

2, it is uncertain how to acquire printer and scanner

Table 1: Checking Property on Partial Model (Famelis et al.,

2012).

∧ Φ

∧ ¬Φ

Property p

SAT SAT Maybe

SAT UNSAT True

UNSAT SAT False

UNSAT UNSAT (error)

resources in two processes, P and Q. In the overwrit-

ten

GET

message sequence, there can be two alterna-

tives: printer.get → scanner.get and scann e r.get →

printer.get. As shown here, uncerta inty can be intro-

duced modu la rly without invading existing interfaces.

As shown in Figure 1, we can explicitly represent

Known Unknowns-type un c ertainty using alternative

and optional language constructs. If a developer is

writing a program (currently, the target programming

languag e is Java) and he or she b e comes aware o f

the existence of uncertainty, the developer only has

to modify Archface-U as shown in List 2. The deve-

loper does not have to modify the original code, be-

cause the essential information containing uncertain

concerns is expressed in the Archface-U and the be-

havioral properties can be checked using only this in-

formation as explained in Section 4. If an uncertain

concern is ﬁxed to certain, a developer only has to

delete the corresponding inh eritance (List 2) and mo-

dify the o riginal Archface-U (List 1) if needed. As

explained here, uncertainty can be managed at only

interface level and the original program co de is not

basically affected. This is why we adopt an interface

mechanism to represent uncertainty modularly.

ICSOFT 2018 - 13th International Conference on Software Technologies

178

 









!"#"$%&"

'(#)"$&

+",



 

 

 

 





-./"0'1"230

456789%&6(#:

;(<6=.

;(<"90'1"236#>

?%)% 2(<" @"1%)",

2($$"2&9. ")"# 6=

8#2"$&%6#&. "A6,&,B

?%)%02(<"01%,0&(0,6789%&"0(#"0

(=00&1"0@"1%)6($%907(<"9,

C#2"$&%6#&.07%.02%8,"0@"1%)6($%90"$$($,B

D%$&6%90;(<"9

;(<6=.

Figure 2: Modular Reasoning for Known Unknowns.

4 MODULAR REASONING

BASED ON PARTIAL M OD EL

Without modular reasoning abou t uncertainty, a deve-

loper has to rely on global reasoning to check whether

some pr operties are satisﬁed. In this section, we show

the Archface-U-based veriﬁcation in details.

4.1 Uncertainty-aware Veriﬁcation

We can use the veriﬁcation power pr ovided by partial

model. The behavioral correctness of a pr ogram is

guaran teed modularly using our compiler (type chec -

ker) and model checker. Figure 2 illustrates the ve-

riﬁcation process. The type checker based on the re-

ﬁnement calculus focusing on simulation checks th e

conformance between Archface-U and its code. The

model checker veriﬁes the behavioral properties such

as a dea dlock by only using the information descri-

bed in Archface-U. Integrating type che cker and mo-

del checker, we can verify behavioral properties at the

code level. Φ

and Φ

in Table 1 (Famelis et al.,

2012) correspon d to logical formula expressing a par-

tial model generated from Archface-U and the proper-

ties to be checked.

In this paper, we p rovide two types of true-

false decisions for a property p: 1) veriﬁed by type

checking; and 2) veriﬁed by model checking. Φ

correspo nds to the consistency among code or user-

deﬁned properties. When a property p is

True

, we can

continue to develop even if unce rtainty exists. When

a p roperty p is

Maybe

, we have to take care of the cor-

respond ing properties as a development risk. In o ther

cases, we have to reconsider the code .

4.2 Type Check

Uncertainty is a target of compilation. O ur type chec -

ker veriﬁes 1) whether a partial model Φ

generated

from A rchface-U satisﬁes a property Φ

such as con-

sistency; and 2 ) whether code is a subset o f the p artial

model Φ

(or whether code simulates one of the be-

havioral models contain e d in the partial model). It

is important that 1) is performed by only Archface-

U deﬁnitions. If code conforms to Archface-U in

terms of 2), Φ

is also satisﬁed in the code. That

is, the veriﬁcation of Φ

results in modular interface

checking. All of the c ode ﬁles are needed for property

checking without an interface mechanism provided

by Archface-U. Fixing the inter-model/code inco nsis-

tency is an important problem (Egyed et al., 2008).

Our approach can verify inconsistency among code

ﬁles by type checking even if uncertainty exists. For

example, our c ompiler generates an error message if

a method is deﬁned in a component interface and its

call is not appeared in the connector interface.

In our compiler, Archfac e-U is translated into a

partial model as shown in Figure 2. The followings is

the algorithm for Archface-U containing Alternative

uncertainty.

iArch-U/MC: An Uncertainty-Aware Model Checker for Embracing Known Unknowns

179

Par•al Model

C1 U1

C1 U2

Merge

Model1 Model2

Alterna•ve

C1 -> {U1,U2} -> C2

Figure 3: Partial Model Generation (A lternative)

C1 -> [U1] -> C2

1 32

1 2

Par•al Model

Model1 Model2

Op•onal

Merge

Figure 4: Partial Model Generation (O pti onal).

STEP 1. Divide a connector interface including Al-

ternative to a set of connector interfaces repre-

sented by original Archface-U that does not con-

tain uncertain ty. Each Archface-U description re-

presented by LTS (L a belled Transition System) is

translated into a state transition model. The upper

part of Figure 3 shows the result of transformation

in case of C1 → {U 1,U2} → C 2. The number in

Figure 3 indic a te s a state.

STEP 2. State transition models generated in STEP

1 are merged into a state transition mac hine as

shown in the lower part of Figure 3. This state

transition model is a partial mod el. Mandatory

edges and nodes appeared in all state transition

models are represented by solid lines. Othe r non-

common edges and nodes are represented by das-

hed lines. After generating a partial mod el, it is

translated into logical formula.

The algorithm in case of Op tional uncertainty is ba-

sically the same to the above algorithm as illustrated

in Figure 4. In case of C1 → [U1] → C2, this Opti-

onal uncertainty is translated into two state transition

models as shown in the upper part of Figu re 4. This

proced ure corresponds to STE P 1 in Alternative un-

certainty. After that, these two models are merged

into a state transition machine as shown in the lower

part of Figure 4. Th is procedure co rresponds to STEP

2 in Alternative uncertainty. C2 is represented by two

dashed line s, because the source of transition C (state

Figure 5: Expansion of uncertain FSP.

number 3) is different from that of transition D (state

number 2).

4.3 Model Checking Embracing

Uncertainty

Behavioral properties represented by LTL can be au-

tomatically veriﬁed using existing model checkers.

In our unce rtainty-aware model checker, LTSA (LTS

Analyzer)

is used as a model checking en gine

because Archface-U is based on FSP supported by

LTSA. Optional and Alternative are tran slated into or-

dinary FSP descriptions as shown in Figure 5.

If a property is veriﬁed by LTSA and the type

check is successfully passed, the program satisﬁes the

property too. Although we used LTSA, our appro-

ach takes a standard appr oach and can be implemen-

ted with other popular off-the-shelf checkers such as

FDR (Failures Divergences Reﬁneme nt)

, a reﬁne-

ment checker for the pr ocess algebra CSP (Commu-

nicating Sequential Processes).

4.4 Usage Scenario

We explain our veriﬁcation process using a printer-

scanner sy stem as an example. There are four pos-

sible resource ac quisition sequences as shown in Fi-

gure 6. These cases are genera te d from a partial mo-

del described as Archface-U (List 2). Type check is

passed if the code simulate s one of these sequences.

The Java code below (List 3) simulates the sequence

1 in Figure 6 and the type ch eck is passed.

http://www.doc.ic.ac.uk/ltsa/, Last accessed 19 April

2018.

https://www.cs.ox.ac.uk/projects/fdr/, Last accessed 19

April 2018.

ICSOFT 2018 - 13th International Conference on Software Technologies

180

Figure 6: Partial Model and Java Program.

[List 3]

01: public class Printer implements uPrinter {

02: public void get() { ... };

03: public void put() { ... };

04: public void print() { ... };

05: }

06:

07: public class Scanner implements uScanner {

08: public void get() { ... };

09: public void put() { ... };

10: public void scan() { ... };

11: }

12:

13: public class CopyMachine

14: implements uCopyMachine {

15: public void copy() {

16: printer.get(); scanner.get();

17: scanner.scan(); printer.print();

18: methodX();

19: printer.put(); scanner.put();

20: }

21: }

As shown in Figure 2, each behavioral model of

a partial mo del is converted into the corresponding

FSP description. Behavioral properties represented

by LTL can be automatically veriﬁed using our mo-

del checker. If counterexamples are no t ge nerated by

our model checker, we can select any sequence (either

of 1, 2, 3, or 4 is OK). We can proceed development

even if uncertain conc erns exist, because the code si-

mulating any sequence is correct. Of course, List 3

simulating the sequence 1 is correct. Unfortunately,

counterexamples are generated in case of the sequen-

ces 3 or 4 and these counter examples show that the

acquisition order must be the same. We are notiﬁed

that unc ertainty speciﬁed in Archface-U (List 2) may

cause a deadlo ck although the code (List 3) is correct.

We cannot embrace unce rtainty in this scenario. We

should not modify L ist 3 but c hange List 2 to remove

the alternatives of

get

operation orders. After that,

We have to run the model checker ag ain and conﬁrm

that no coun te rexamples a re generated. As explained

here, we can resolve uncertain co ncerns and make a

correct program b efore debugging and testing.

Our type checker con sists of a partial model gen e-

rator, a reﬁnement veriﬁer, and a consistency veriﬁer.

The par tial model generator creates a partial mode l, a

set of p ossible behavior models f rom FSPs containing

alternative and optio nal descriptions extended by

Archface-U. The reﬁnement veriﬁer checks whether

the code simulates one model included in the genera-

ted partial model. In List 3, a sequence printer.get →

scanner.get → scanner.scan → printer.print →

methodX → printer.put → scanner.put simulates the

sequence 1 (Figure 6) generated from the Archface-U

deﬁnitions (List 1 and 2). The call of

methodX

does

not violates an LTS deﬁned by FSP in Lists 1 and

2. As a result, properties satisﬁed by the LTS are

also held in the code that passes compile check. The

consistency veriﬁer checks the inconsistency not only

among Archface -U deﬁnitions but also among code

ﬁles. An error is generated if a method is deﬁned in

a component interface and its call does not appear in

the connector interface. Ou r approach can verify the

inconsistency even if uncer ta inty exists.

Our compiler adds only type checking embracing

uncertainty to the original Java compiler. Compiled

code is executable, because Archface-U is just a con-

straint to the code. Program b e havior is also guaran-

teed, because th e co de simulates just one of the pos-

sible models described in Archface-U.

4.5 State Explosion Problem

State explosion is a cru c ia l problem when applying

model checking to a real project. Especially, it is dif-

ﬁcult to apply model checking to source code even if

several tools suc h as CBMC (Bounded Model Chec-

ker for C and C++)

and Java Pathﬁnder

are already

provided. On the other hand, in our approach, mode l

http://www.cprover.org/cbmc/, Last accessed 19 April

2018.

https://github.com/javapathﬁnder/, Last accessed 19

April 2018.

iArch-U/MC: An Uncertainty-Aware Model Checker for Embracing Known Unknowns

181





!"#$%&#'()

*(+"%',-"./012

Figure 7: iArch-U/MC.

checking is p erformed in terms of only FSP descr ipti-

ons in Archface-U. Co de is not the direct target of mo-

del checking. As a result, the number of states is re-

duced. Nevertheless, as repea tedly claimed, code can

be indirectly veriﬁed by the mode l ch ecker if the code

conforms to its Archface-U via type checker. Our ap -

proach mitigates the problem of state explosion b y in-

tegrating type che c king with model chec king.

5 TOOL IMPLEMENTATION

The iArch-U, an IDE for supporting uncerta inty-

aware programming, consists of Java program editor,

uncertainty-aware compiler, uncertainty-aware model

checker, unit testing support, and Git-based uncer-

tainty management support. The iArch-U IDE is open

source software and its preliminary versio n can be do-

wnloaded fr om GitHub

The iArch-U/MC, a new tool com ponent for mo-

del check ing, is imple mented as an Ec lipse plug-in as

shown in Figure 7. Figure 2 illustrates the overview

of our approach. As roughly explained in Section 4,

a p artial model is generated from Archface-U deﬁniti-

ons. Each behavioral model consisting the partial mo-

del is converted into the corresponding FSP descrip-

tion. Behavioral proper ties repre sented by LTL can be

http://posl.github.io/i A r ch/, Last accessed 19 April

2018.

automatically veriﬁed using LTSA supporting FSP. If

a property is veriﬁed by a model checker and the type

check is successfully passed, the program satisﬁes im-

portant properties such as deadlock freedom. Whe n a

property is

True

, we can continue to develop even if

uncertainty exists. Otherwise, we have to reconsider

the code . Using iArch-U/MC, we can explore which

uncertainty can be permitted by interactively modi-

fying not prog ram co de itself but Archface-U descrip-

tions and checking the beh avioral corre ctness.

6 DISCUSSION

In this section, we discuss on the originality and the

applicability of our idea.

Someone might consider that Archface-U is simi-

lar to variability modeling in SPL (Ba¸k et al., 2014).

How different is our approach from SPL? If the re is

no difference, we can deal with uncertainty by only

using SPL technologies. Indeed, uncertainty in struc -

tural aspects (a component interface in Archface-U)

can be represented by deﬁning uncertain features in a

feature model. Althou gh it is difﬁcult to re present be-

havioral aspects of uncertainty (a con nector interface

in Archface -U) in a feature model, there are studies

on behavioral variability (Classen et al., 20 12; Ghezz i

and Shar iﬂoo, 2011).

Our most important contribution is to introduce

ICSOFT 2018 - 13th International Conference on Software Technologies

182

the interface-b ased v ariability to the world of SPL.

As claimed in this paper, this interface enables the

valuable integration of code-conform a nce check via

type chec ker and model checking taking into account

abstraction. Only using current SPL technologies, it

is not easy to integrate important facilities mentioned

above. Mor e over, our idea can be basically applied

to SPL by not limiting to variability in uncertain c on-

cerns. Similarity to SPL comes from the characte-

ristics of Known Unknowns in which uncertainty is a

subset of variability.

Although the interface mechanism of Archface-U

can be applied to SPL, the process of SPL is different

from that of uncer tainty-aware software development.

The former focuses on gener ating a product fr om a set

of features represented by optional and alternatives.

Product structure does not basically chan ge thro ugh a

software development, although product regene ration

may occur several times to deal with small changes.

On the other hand, our app roach focuses on the ma-

nagement of u ncertainty frequently appearing or di-

sappearing in a software development. Product gene-

ration is out of scope. The main concern is to ve-

rify whether some important properties are guaran -

teed even if uncertainty exists and to decide whether

resolution of uncertainty can be postponed. For this

reason, modular reasonin g realized by type checking

and model checking is important.

When modifying a large product, it is necessary

to impose constraints among alternatives because a

large number of checking for relatively com plex sy-

stems would result in errors. It makes sen se to ex-

tend the alternative and optional operators to in-

clude constraints. However, the number of constraints

might be overwhelming due to com binatorial explo-

sion. The lack of precision may indeed identify more

constraints than necessary in order to keep a sound

veriﬁcation. This issue is our future work.

7 CONCLUSIONS

In this paper, we proposed iArch-U/MC, an

uncertainty-aware model checker for verifying

whether or not some important properties a re guaran-

teed even if Known Unknowns remain in a program.

Our approach deals with epistemic uncertainty at the

program code level. As the next step, we plan to

integrate iArch-U/MC with LTSA- PCA (Probabilistic

Compone nt Automata) (Rodrigues et al., 2014) to

support aleatory uncertainty.

ACKNOWLEDGMENTS

We thank Syunya Nakamura, Keisuke Watanabe, and

Takuya Fukamachi for their gre a t contributions. They

were students of Naoyasu Ubayashi. This work

was supported by JSPS KAKEN HI Grant Numbers

JP26240007.

REFERENCES

Autili, M., Cortellessa, V., Ruscio, D. D., Inverardi, P., Pel-

liccione, P., and Tivoli, M. (2012). Integration archi-

tecture synthesis for taming uncertainty in the digital

space. In Proceedings of the 17th Monterey Confe-

rence on Large-Scale Complex IT Systems: Develop-

ment, Operation and Management, pp.118-131.

Ba¸k, K., Diskin, Z., Antkiewicz, M., Czarnecki, K., and

Wa¸sowski, A. (2014). Clafer: Unifying class and fea-

ture modeling. In Software & Systems Modeling, De-

cember 2014, pp.1-35.

Bornholt, J., Mytkowicz, T., and McKinley, K. S. (2014).

Uncertain< t > : A ﬁrst-order type for uncertain data.

In Proceedings of the 19th International Conference

on Architectural Support for Programming Languages

and Operating Systems (ASPLOS 2014), pp.51-66.

Cheng, S. W. and Garlan, D. (2007). Handling uncertainty

in autonomic systems. In Proceedings of the Interna-

tional Workshop on Living with Uncertainties (IWLU

2007).

Classen, A., Cordy, M., Heymans, P., Legay, A., and Schob-

bens, P. Y. (2012). Model checking software product

lines w ith snip. In International Journal on Software

Tools for Technology Transfer, 14(5), pp.589-612.

Devaraj, A., Mishra, K., and Trivedi, K. S. (2010). Uncer-

tainty propagation in analytic availability models. In

Proceedings of t he Symposium on Reliable Distribu-

ted Systems (SRDS 2010), pp.121-130.

Egyed, A., Letier, E., and Finkelstein, A. (2008). Genera-

ting and evaluating choices for ﬁxing inconsistencies

in uml design models. In Proceedings of the 23rd In-

ternational Conference on Automated Software Engi-

neering (ASE 2008), pp.99-108.

Elbaum, S. and Rosenblum, D. S. (2014). Known unkno-

wns: Testing in the presence of uncertainty. In Procee-

dings of the 22nd ACM SIGSOFT International Sym-

posium on Foundations of Software Engineering (FSE

2014), pp.833-836.

Esfahani, N., Kouroshfar, E., and Malek, S. (2011). Taming

uncertainty in self-adaptive software. In Proceedings

of the 8th Joint Meeting of the European Software En-

gineering Conference and the ACM SIGSOFT Sym-

posium on the Foundations of Software Engineering

(ESEC/FSE 2011), pp.234-244.

Esfahani, N. and Malek, S. (2013). Uncertainty in self-

adaptive software systems. In Software Engineering

for Self-Adaptive Systems I I, volume 7475 of LNCS,

pp.214-238. Springer.

iArch-U/MC: An Uncertainty-Aware Model Checker for Embracing Known Unknowns

183

Esfahani, N., Malek, S., and Razavi, K. (2013). Guidearch:

Guiding the exploration of architectural solution space

under uncertainty. In Proceedings of the 35th Inter-

national Conference on Software Engineering (ICSE

2013), pp.43-52.

Esfahani, N., Razavi, K., and Malek, S. (2012). Dealing

with uncertainty in early software architecture. In

Proceedings of the 20th International Symposium on

the Foundations of Software Engineering (FSE 2012),

pp.21:1-21:4.

Famelis, M., Ben-David, N., Sandro, A. D., Salay, R., and

Chechik, M. (2015). Mu-mmint: an ide for model

uncertainty. In Proceedings of the 37th Internatio-

nal Conference on Software Engineering (ICSE 2015),

Demonstrations Track, pp.697-700.

Famelis, M., S al ay, R., and Chechik, M. (2012). Partial

models: Towards modeling and reasoning with uncer-

tainty. In Proceedings of the 34th International Confe-

rence on Software Engineering (ICSE 2012), pp.573-

583.

Fitzgerald, J. and Larsen, G. P. (1998). Modeling Systems,

Practical Tools and Techniques in Software Develop-

ment. Cambridge University Press.

Fukamachi, T., Ubayashi, N., Hosoai, S., and Kamei, Y.

(2015a). Conquering uncertainty in java program-

ming. In Proceedings of the 37th International Con-

ference on Software Engineering (ICSE 2015), Poster

Track, pp.823-824.

Fukamachi, T., Ubayashi, N., Hosoai, S., and Kamei, Y.

(2015b). Modularity for uncertainty. In Proceedings

of the 7th International Workshop on Modelling in

Software E ngineering (MiSE 2015), pp.7-12.

Garlan, D. (2010). Software engineering in an uncertain

world. In Proceedings of FSE/SDP Workshop on Fu-

ture of Software Engineering Research (FoSER 2010),

pp.125-128.

Ghezzi, C. and Shariﬂoo, A. M. (2011). Quantitative ve-

riﬁcation of non-functional requirements with uncer-

tainty. In Dependable Computer Systems, pp.47-62.

Hinton, A., Kwiatkowska, M., Norman, G., and Parker, D.

(2006). Prism: A tool for automatic veriﬁcation of

probabilistic systems. In Proceedings of the 12th In-

ternational Conference on Tools and Algorithms for

the Construction and Analysis of Systems (TACAS

2006), pp.441-444.

K., G.-P. and S., K. (2003). Assessing uncertainty in relia-

bility of component-based software systems. In Pro-

ceedings of the 14th International Symposium on Soft-

ware Reliability Engineering (ISSRE 2003), pp.307-

320.

Lago, P. and Vliet, H. (2005). Explicit assumptions enrich

architectural models. In Proceedings of the 27th Inter-

national Conference on Software Engineering (ICSE

2005), pp.206-214.

Letier, E., St efan, D., and Barr, E. T. (2014). Uncertainty,

risk, and information value in software requirements

and architecture. In Proceedings of the 36th I nter-

national Conference on Software Engineering (ICSE

2014), pp.883-894.

Magee, J. and Kramer, J. (2006). C oncurrency: State Mo-

dels & Java Programs Second Editi on. Wiley.

Meedeniya, I., Moser, I., Aleti, A., and Grunske, L. (2011).

Architecture-based reliability evaluation under uncer-

tainty. In Proceedings of the 7th International ACM

Sigsoft Conference on the Quality of Software Archi-

tectures (QoSA 2011), pp.85-94.

Perez-Palacin, D. and Mirandola, R. (2014). Uncertainties

in the modeling of self-adaptive systems: a axonomy

and an example of availability evaluation. In Procee-

dings of the 5th ACM/SPEC International Conference

on Performance Engineering (ICPE 2014), pp.3-14.

Rodrigues, P., Lupu, E., and Kramer, J. (2014). Ltsa-pca:

Tool support for compositional reliability analysis,.

In ICSE Companion 2014 Companion Proceedings of

the 36th International Conference on Software Engi-

neering (ICSE 2014), pp.548-551.

Salay, R., Chechik, M., Horkoff, J., and Sandro, A. D.

(2013a). Managing requirements uncertainty with

partial models. In Requirements Engineering, Volume

18, Issue 2, pp.107-128.

Salay, R., Gorzny, J., and Chechik, M. (2013b). Change

propagation due to uncertainty change. In Procee-

dings of the 16th International Conference on Fun-

damental Approaches to Software Engineering ( FASE

2013), pp.21-36.

Trubiani, C., Meedeniya, I., Cortellessa, V., Aleti, A., and

Grunske, L. (2013). Model-based performance analy-

sis of software architectures under uncertainty. In Pro-

ceedings of the 9th International ACM Sigsoft Confe-

rence on the Quality of Software Architectures (QoSA

2013), pp.69-78.

Watanabe, K., Ubayashi, N., Fukamachi, T., Nakamura,

S., Muraoka, H., and Kamei, Y. (2017). iarch-u:

Interface-centric integrated uncertainty-aware deve-

lopment environment. In 9th International Workshop

on Modelling in Software Engineering (MiSE 2017),

pp.40-46.

Whittle, J., Sawyer, P., Bencomo, N., Cheng, B. H. C., and

Bruel, J. M. (2010). Relax: A language to address

uncertainty in self-adaptive systems requirement. In

Requirements Engineering, 15(2), pp.177-196.

Yang, W., Xu, C ., Liu, Y., Cao, C., Ma, X., and Lu, J.

(2014). Verifying self-adaptive applications suffering

uncertainty. In Proceedings of the 29th International

Conference on Automated Software Engineering (ASE

2014), pp.199-210.

ICSOFT 2018 - 13th International Conference on Software Technologies

184