SIMVA-SoS Software Design Description (SDD)

SIMVA-SoS

Software Design Description (SDD)

[SW Starlab]

Software R&D for Model-based Analysis and Verification of

Higher-order Large Complex System

Version: 1.0

Last Update: 2018.11

Software Engineering Lab,

KAIST (Korea Advanced Institute of Science and Technology)

SIMVA-SoS Software Design Description (SDD) KAIST

2

Contents

1. Introduction .......................................................................................................... 4

1.1 Motivation ................................................................................................................................... 4

1.2 Goals ............................................................................................................................................ 4

1.3 Feature List ................................................................................................................................. 4

2. Architecture Design ............................................................................................. 6

2.1 Procedural Architecture & Descriptions ................................................................................. 6

2.2 Program Architecture & Descriptions ..................................................................................... 7

2.3 Architectural Design Pattern: MVC (Model-View-Controller) ............................................ 8

2.4 Workflows of SIMVA-SoS ........................................................................................................ 8

3. Class Design ........................................................................................................ 11

3.1 SIMVA-SoS Models ................................................................................................................. 11

3.1.1 Class Diagram ...................................................................................................................................................... 11

3.1.2 Class Description ................................................................................................................................................. 13

3.2 SoS Simulation & Verification Modules ................................................................................ 18

3.2.1 Class Diagram ...................................................................................................................................................... 18


3.3 Model Slicing Modules ............................................................................................................. 20

3.3.1 Class Diagram ...................................................................................................................................................... 20


4. Human Interface Design ................................................................................... 22

4.1 Overview of User Interface ..................................................................................................... 22

4.1.1 Requirements (specified in SRS) ......................................................................................................................... 22

4.1.2 Initial Design of Graphical User Interface ........................................................................................................... 23

4.2 Screen Images of GUI Prototyping......................................................................................... 25


3


4

1. Introduction

1.1 Motivation

The increasing scale and complexity of systems have reached a point that imposes qualitatively new

demands on the existing system technology. The emerging system is characterized by distributed,

decentralized, and networked combinations of autonomous sub-systems under large-scale and complex

environments. This new “system" is a general concept of “System of systems" (SoS). The term has arisen

in various domains such as social infrastructures, smart grids, military services, and air traffic.

With respect to SoS, there are various types of definition from the literature that have been

independently published by industry, government, and academia. One definition suggests that SoS is

composed of independent sub-systems, which is called Constituent Systems (CSs), and CS has two

unique properties: (1) operational independence, i.e., each system operates independently and it

achieves its own goals by itself and (2) managerial independence, i.e., each system is managed in most

parts for its own goals rather than the goals of SoS. These indicate that CS is operated, managed, and

developed independently, and it may not focus on the whole SoS-level goals. The behavior of an SoS

emerges from the interaction among its CSs.

A key aspect of SoS is that how we can achieve whole SoS-level goals by orchestrating the

interconnection between otherwise independent CSs. Thus, naturally, it is necessary to study approaches

to verifying whether the SoS-level goals are achieved or not. However, there is a lack of supporting tools

for modeling and verifying SoS and SoS-level goal achievements.

1.2 Goals

SIMVA-SoS is a software for simulating and verifying the SoS. SoS models, given by users, are

converted to executable SoS models and those become the inputs of simulation engine. Another input

for simulation engine is SoS scenario data which is based on a target SoS. For verification, SoS goal and

its verification property are input of the verification engine. A user can verify the satisfaction of goal and

verification property of an SoS supported by SIMVA-SoS.

1.3 Feature List

A. SoS Modeling & Specifications

SIMVA-SoS imports input models and specifications from user’s local device.

o Input models: SoS system models, SoS environment model

o Input specifications: Verification properties, Policy specifications, Simulation scenario

specification

SIMVA-SoS contains predefined skeleton classes to represent input models as Java classes.

Based on predefined classes, SIMVA-SoS checks correctness and completeness of input

models for Java code generation.

SIMVA-SoS reads, interprets, and transforms input models.

o XML parser reads and interprets input XML files.

o Java code generator transforms input models into simulatable Java code using predefined

classes in SIMVA-SoS.


5

SIMVA-SoS displays information of imported input files.

SIMVA-SoS supports re-importation of input files.

SIMVA-SoS shows runtime status of model objects during simulation.

B. Simulation

SIMVA-SoS simulates the input SoS model by discrete time simulation.

o Discrete time simulation executes simulation model based on a discrete time unit.

o Status of models are changed by time flow.

o Simulation result is log of each time unit.

SIMVA-SoS performs multi-agent simulation.

o CSs of the SoS model is regarded as an autonomous and independent agents.

o The behavior of each CS is determined by their decision making algorithm.

o It supports to simulate collaborative behavior or interactions between the multiple

agents.

C. Verification

SIMVA-SoS verifies the input models by adopting SPRT algorithm.

o A SPRT algorithm is the fastest statistical model checking algorithm.

o In SPRT algorithm, SIMVA-SoS simulates the input models several times to each

probability (from 0.01 to 1.00) for checking whether each probability is true or false.

SIMVA-SoS can apply a specific verification property as a verifiable goal of SoS.

o There are 22 verification properties that we found from other existing research (listed in

Appendix A).

SIMVA-SoS shows the raw and analyzed result to the user.

o The raw result of the verification is the number of samples, number of true samples, the

true/false tag selected by the SPRT algorithm.

o SIMVA-SoS provides the analyzed result to the user by the form of the graph for each

probability and its specific value.

SIMVA-SoS can save the results of verification as a file.

D. Slicing

Slicing module increases the efficiency of simulation and verification by slicing user interested

parts of SoS simulation and goal models.


6

2. Architecture Design

2.1 Procedural Architecture & Descriptions

Figure 1. Procedural Architecture of SIMVA-SoS

As a preliminary step for SIMVA-SoS design, an overall architecture of SIMVA-SoS is developed. This

architecture contains whole processes from modeling to simulation-based verification. Major components

of SIMVA-SoS are (1) simulatable input files (models, specifications that are transformed into Java code),

(2) Simulation engine, and (3) Verifiers.

First, simulatable input files are made based on a meta-model, called M2SoS (Meta-Model for SoS).

M2SoS conceptually defines fundamental and essential classes to represent SoS ontologies for high-

level analysis and design. Based on M2SoS, several models, scenario, policy specifications can be

developed. Input models consist of several SoS models that are modeled using ADOxx modeling tool.

Other models or specifications can be made independently following defined modeling rule (e.g., policy

specification rules, scenario specification rules). Among various models, a goal model is also used to

specify verification properties for statistical model checking of SIMVA-SoS. Based on goals in the goal

model, verification properties (safety/liveness) can be derived with specific model information (object or

variable names).

A user can import the input models and specifications using GUI, and then GUI of SIMVA-SoS requests

model interpretation to Model Interpreter. Model Interpreter reads and interprets input XML files and

interpretation results (i.e., preprocessing of inputs) are sent to Simulation Model Generator. The

Simulation Model Generator generates several Java files (classes) according to the interpretation results

of input files. For the prototype of SIMVA-SoS, this code generation will be performed manually so it

requires human efforts to program Java code.

If simulation models are successfully generated, they can be simulated by SIMVA-SoS. For the

simulation, SIMVA-SoS has a discrete event-based simulation engine that can execute the simulation

models. When a user starts a simulation, simulation progress and logs are shown on SIMVA-SoS GUI

and they can be saved as output files. Statistical Model Checking (SMC) basically performs a number of


7

simulations repeatedly, and a SMC module analyzes the whole simulation logs to verify whether input

properties are satisfied or violated statistically. SIMVA-SoS basically supports sequential probability ratio

test (SPRT) for the statistical model checking, and the SMC module finally generates model checking

results.

2.2 Program Architecture & Descriptions

SIMVA-SoS program can be divided into two subprograms (two windows), which are (1) Main

Program/Process and (2) S&V Program/Process, and they play different roles for simulation and

verification in SIMVA-SoS. First, Main Program can be considered as an administrator program of

SIMVA-SoS that covers all SIMVA-SoS modules and accesses to all SIMVA-SoS functionalities.

There are four major roles of Main Program. First, Main Program converts input files (XML models,

specifications) into Java code. This includes roles of <Model Interpreter> and <Simulation Model

Generator>. The generated Java files are compiled and executed by S&V program when a simulation is

started. To support the functions, SIMVA-SoS should have proper user interfaces for file exploration and

importing. Secondly, Main Program supports user’s manual configurations before executing simulation

or verification. A user can input user-defined verification properties and configure statistical parameters

and simulation models. Thirdly, Main Program supports property-based model slicing for cost-efficient

verification of SoS. Fourthy, based on the inputs explained above, Main Program executes the S&V

Program via pre-defined script file. Inputs required by Main Program are model XML files, configuration

DAT files, and generated Java or Class files.

When the Main Program executes the S&V Program, a new window for S&V is popped-up as a

secondary window. S&V Program basically reads input files and performs simulation & verification, and

S&V Program supports monitoring of progresses of simulation and verification. Lastly, a user can save

simulation and verification results as output files (e.g., simvasos_simulation_results_181116-1515.txt). If

a user wants to quit the secondary S&V window, then the S&V window is terminated and the user can

go back to Main Program and restart S&V (with different inputs).

Figure 2. Program Architecture of SIMVA-SoS

Figure 3. User's viewpoint to use SIMVA-SoS


8

2.3 Architectural Design Pattern: MVC (Model-View-Controller)

SIMVA-SoS development follows MVC (Model-View-Controller) architectural design pattern. Models

of SIMVA-SoS are skeleton classes including both abstract classes and concrete classes. These models

should be able to represent input models adequately, thus their definitions should be consistent with input

models’ definitions. Controllers of SIMVA-SoS consist of simulator (i.e., simulation engine) and verifiers

(i.e., SPRT modules and statistical model checker). Views of SIMVA-SoS are mainly composed of GUI

views and their components to control overall file management, simulation, and verification.

2.4 Workflows of SIMVA-SoS

A. Workflow of Simulation Model Generation

Figure 4. Workflow of Simulation Model Generation

An SoS model file which represents information of an SoS is inserted into the executable model

generation module. The input SoS model is a static file like XML file. Through the model generation

process, given SoS model is interpreted and an executable model is generated as a java file. The

generated java files include SoS behavioral model and a scenario.

The generated executable models (java files) are compiled and they are simulated by the simulation

engine. The simulator executes multiple agents which represent constituent systems of the SoS, with

increasing discrete time. The simulator returns the results of the simulation in a form of log for each

simulation time unit. The extracted results are used for verification. The statistical verification module

repeatedly requires simulation execution and results, so that verifies the SoS models. The simulation

results, logs, and verification results are returned as the final outputs.

B. Workflow of Model Slicing, Simulation and Verification

The slicing module is a technique for extracting necessary parts to increase the efficiency of simulation

and verification. In the property-based slicing module, the SoS Java program is received as input. The

reason why Java program is selected as input is that Java can be executed by compiling, and it is possible

to model various SoS with high expressiveness. The first step is to compile the input Java file. You will

perform slicing on the compiled .class file. In the second step, to select instruction to be executed, the

slicing module receives verification properties which will be the starting point of slicing. The third step, to


9

insert probes, inserts probes into the class file. When the probes are inserted, it becomes the basis for

extracting the instruction of the actually executed part. Finally, in generating executable Java program

step, the probe runs the inserted program and gets execution traces. If slicing is performed on the

execution trace based on the selected instruction, an executable Java program is generated as a result

of the execution.

Figure 5. Workflow of Model Slicing, Simulation and Verification

C. User’s Workflow for Simulation & Verification

From a user’s viewpoint, a workflow of SIMVA-SoS simulation can be described as Figure 99 illustrates.

The figure focuses on simulation aspects and it summarizes basic use cases to input files, to start/monitor

simulation and verification, and to analyze and store simulation results. First, a SIMVA-SoS user can run

SIMVA-SoS by running an executable file of SIMVA-SoS or by compiling and executing SIMVA-SoS java

project. When a user runs SIMVA-SoS, the simulation engine is automatically initialized without specific

inputs and configurations for simulation. Before starting a simulation, the user should import several files

in addition to simulation models (SoS and environment model). Those files are (1) simulation scenario,

(2) policies to be simulated, and (3) simulation configuration. All of them are not necessarily required to

simulate target simulation models, but they can be meaningfully used to control behaviors of systems

and environment during simulation or to configure simulation itself. Based on the input files, simulation

engine creates objects dynamically to be simulated. After importing all required inputs, a user can run

the simulation engine by clicking a start button for the single simulation.

If a simulation is normally started, the simulation engine repeats a loop for performing discrete event-

based simulation, which utilizes a concept of a logical tick. First, the engine increases its logical tick and

the engine calls several methods to run whole executable models. For a single tick, run() methods of

SoS model and environment model are simultaneously called. Then the run() method of the SoS model

hierarchically calls lower-level objects’ run() methods (run() methods of Infra, Organizations, CSs, etc.).

During these repetitions of running single ticks, SIMVA-SoS user can monitor mid-process of this

simulation using simulation logs and graphs. This loop is terminated if the end condition of the simulation

engine is satisfied, which can be maximum number of ticks.

After the simulation is successfully finished, the user can analyze simulation results by observing

graphs, logs, and values of certain objects. In addition, the simulation results can be saved as text files

for future analysis.


10

Figure 6. User's Workflow for Simulation in SIMVA-SoS


11

3. Class Design

3.1 SIMVA-SoS Models

3.1.1 Class Diagram

A. Abstract Classes

Figure 7. Class Deisgn of SIMVA-SoS Models: Abstract Classes


12

B. Concrete Classes

Figure 8. Class Deisgn of SIMVA-SoS Models: Concrete Classes


13

C. Interfaces

Figure 9. Class Deisgn of SIMVA-SoS Models: Interfaces

3.1.2 Class Description

No Abstract/Concrete Class Name Class Description

1 abstract SIMVASoS_Object SIMVASoS_Object is an abstract class for every

object class in SIMVA-SoS. SIMVASoS_Object

basically includes its name, type, activation-status,

and location.

If a SIMVASoS_Object is excluded for the

simulation, isActivated should be ‘false’ and it

is automatically excluded by the simulation engine.

2 concrete ObjectLocation ObjectLocation is a concrete class to represent

location of SIMVASoS_Object. Every

SIMVASoS_Object contains its location information

as an instance of ObjectLocation. The location

can be represented with either 3-dimensional value

(x, y, z position) or its location information.

3 abstract ActionableObject ActionableObject is an abstract class for every

actionable object in SIMVA-SoS.

ActionableObjects can perform its own specific

actions autonomously during the simulation.

Capabilities of an ActionableObject are

represented as a set of possible (executable)

actions, and the actions are stored in

actionList[]. ActionableObject is mainly

inherited by systems (CSs, servicized systems).

4 abstract NonActionableObject NonActionableObject is an abstract class for

every non-actionable object in SIMVA-SoS.

NonActionableObjects cannot perform any

actions during the simulation, but the state or value

can be accessed and modified by others.

NonActionableObject only has its value

(objectValue) as a specialized attribute based on

SIMVASoS_Object.


14

5 abstract SIMVASoS_Action SIMVASoS_Action is an abstract class to describe

action objects in SIMVA-SoS. ActionableObjects

(i.e., systems (CSs)) can execute concrete actions,

which are instantiated actions of

SIMVASoS_Action. Basically, each action has its

ID, name, and type. An action can be executed

only when the precondition is met

(actionPrecondition == true). A single action

can consist of one or more concrete behaviors. An

action has its individual duration according to the

time unit of the simulation engine.

6 abstract SIMVASoS_Operation SIMVASoS_Operation is an abstract class to

describe the lowest-level of behavioral objects in

SIMVA-SoS. One or more operations can be

included in a single action (SIMVASoS_Action). A

unit operation manipulates the value or state of

certain variables. To make an operation executable,

operate() method should be specifically

implemented at code-level.

7 abstract CS -

8 abstract CS_Action -


1 concrete SoS SoS is the highest-level of system class. SoS has

one or more Organizations, and each

Organization consists of multiple CSs. In SIMVA-

SoS, an SoS is conceptually defined to integrate

component systems (CSs), infrastructure, and

policy instruments.

2 concrete Organization Organization is the highest-level of structured

component of an SoS. An organization consists of

multiple CSs and required organizational features.

Organizational structure, tasks, roles, contacts,

policies are instances of the organizational features.

An organization can have its suborganizations.

3 concrete Infrastructure Infrastructure is one of major components of an

SoS. The Infrastructure mainly provides two

things: (1) SoS-level Services, (2) SoS-level

Resources. Thus, an Infrastructure maintains two

lists for managing services (infraServices) and

resource (infraResources).

4 abstract InfraService InfraService is an abstract class that

autonomously provides a service to components of

an SoS. Each InfraService has its own id, name,

type, and it can be occupied by multiple CSs.


15

InfraService can run its own service

autonomously, so it has an abstract method

runServices(…). runServices() method is called

by the simulation engine.

5 concrete InfraResource InfraResource is a specialized type of

NonActionableObject. InfraResource is a

component class of an Infrastructure. Since

InfraResource is not an autonomous object, it is

non-actionable. For more specialized purposes,

InfraResource can be specialized further into

another child class.

6 concrete CommunicationChannel CommunicationChannel is a specialized type of

InfraResource. InfraResource is a

NonActionableObject, thus

CommunicationChannel is basically non-

actionable. CommunicationChannel is built on (and

managed by) the SoS-level infrastructure, and the

channel can be utilized by multiple CSs for

communication purposes.

7 abstract CS CS is a major component system of an organization

of an SoS. Basically, a CS is an ActionableObject,

which means that a CS can perform its autonomous

behaviors (actions and their operations). By

extending ActionableObject, a CS has its own

ActionList[] with selectedActions() and

doActions() methods.

8 abstract <<inner class>>

CS > CS_Action

CS_Action is an execution unit of a CS, which has

its own operations, durations, progress, and status

information.

CS_Action basically inherits SIMVASoS_Action and

it is an inner class of CS, thus it has all attributes

and methods of SIMVASoS_Action. CS_Action is

also an abstract class, and it has attributes of CS-

level actions, such as cost and benefit information.

From SIMVASoS_Action, two abstract methods

should be implemented for instantiation of

CS_Action: (1) runOperations() to specify

detailed code-level behaviors of an action, which

can consist of a series of CS_Operations, (2)

checkPrecondition() to update value of

actionPrecondition (true/false).

In CS_Action, the concept ‘utility’ is used to

describe the value of an action with respect to SoS-

level (or Organization-level) goal. Thus,

calculateUtility() should be implemented

when CS_Action is instantiated while defining a CS.


16

However, it is allowed that calculateUtility()

performs static calculation using a constant value.


CS >

CS_Communication

CS_Communication is a specialized type of

SIMVASoS_Action for communication purpose.

When selecting actions from actionList[] of a CS,

CS_Communication can be selected (or created).

Because this action is for the communication, it

necessarily requires a message

(CommunicationMessage).

Since CS_Communication is also an abstract class

inheriting SIMVASoS_Action, runOperations()

and checkPrecondition() should be implemented

for the instantiation.


CS > CS_Operation

CS_Operation is a specialized type of

SIMVASoS_Operation and an inner class of CS.

Thus, multiple CS_Operation can be included in a

single SIMVASoS_Action (i.e., CS_Action).

Definition of CS_Operations is not mandatory, but it

enables more systematic action definition. To make

a concrete CS_Operation object, an abstract

method operate() from SIMVASoS_Operation

should be implemented.

11 concrete CommunicationMessage CommunicationMessage is a specialized type of

NonActionableObject used for communication

purposes. The message can be created by CSs, and

it can be sent to other CSs/Organizations through

the simulation engine.

There are two message types supported: (1)

SEND_MESSAGE, (2) REQUEST_OCCUPANCY.

SEND_MESSAGE supports the direct communication

between (among) CSs. REQUEST_OCCUPANCY is used

to request the occupancy of SoS-level objects such

as InfraResources/Services.

For SEND_MESSAGE, two ways of direct

communication are supported: (1) unicast (CS-to-

CS), (2) broadcast (CS-to-Org). One of those two

casting methods is determined according to the

msgReceiverId. If msgReceiverId is CS’s id, then

it is unicated. Otherwise (Org’s id), it will be

broadcasted to member CSs of the Organization.


CS >

CS_DecisionMaking

CS_DecisionMaking is a class used for

selectActions() method of ActionableObject

(i.e., CS). CS_DecisionMaking includes specific

decision making mechanism such as cost-benefit

analysis. Since this class requires a goal-based

assessment model to evaluate actions to be


17

performed, makeDecision() method should be

implemented.

13 <<inner class>>

CS > CS_Knowledge

CS_Knowledge is a specialized type of

NonActionableObject, and is an inner class of CS.

Based on attributes and operations defined in

NonActionableObject, CS_Knowledge has its own

knowledge type and information.

14 <<inner class>>

CS > CS_Resource

CS_Resource is a specialized type of

NonActionableObject, and is an inner class of CS.

To represent a specific resource that belongs to a

certain CS, it has its specific resource type

(csResType).

No Interface Name Interface Description

1 Environment Element

EnvironmentElement is an interface to describe SoS-level environment(-al)

objects or factors. Since EnvironmentElement is defined as an interface, it can

be simultaneously used (inherited) with other (super-)classes. For example,

environment element can be either ActionableObject or

NonActionableObject.

If the element is an Actionable EnvironmentElement, we can define a new class

like [class EnvFactor_A extends ActionableObject implements

EnvironmentElement].

Otherwise (in case of NonActionableObject), we can define as follows. [class

EnvFactor_B extends NonActionableObject implements

EnvironmentElement]

More detailed class descriptions are included in Appendix B-1).


18

3.2 SoS Simulation & Verification Modules

3.2.1 Class Diagram

Figure 10. Class Deisgn of SIMVA-SoS Simulation & Verification



1 Abstract Simulation Simulation represents a unit of a single simulation

execution. It has a simulation input SoS model and

a simulator to execute the models. The simulator

executes the input model following the given

scenario.

2 Concrete Simulator Simulator is a module to execute the given SoS

models following the scenario. It has internal

simulation time. During a simulation execution, log

is collected for each time unit. After the simulation

execution the collected log is returned. When the

simulation is started, the simulation can be paused,

stopped, or monitored.

3 Abstract SoS SoS is a model of the SoS that is an output of the

modeling feature of the SIMVA-SoS.

4 Concrete Scenario Scenario is a time-series representation of the

events. It has list of the events that will be occurred

in the SoS models during the simulation.

5 Concrete Event Event is a unit of the scenario. Event is a

composition of an action and a time. The action is

an operation which is occurred at a certain point of


19

the scenario, and the time represents when the

action is occurred.

6 Abstract Action Action is an operation which is occurred at a certain

point of the scenario.

7 Concrete Log Log is a list of snapshot which represents states of

the model in a certain time. States of the model is

written in a string value and is composed with a

time.

8 Concrete Snapshot Snapshot is a status of a model in a certain time.

9 Abstract Verifier Verifier verifies a property of an SoS model based

on the simulation results. It performs multiple

simulation to statistically verify the property. The

verification result is a probability of the satisfaction

ratio of the verification property.

10 Concrete SPRT SPRT is an implementation of the Sequential

probability ratio test algorithm for a specialization of

a verifier. It has internal configuration variables

alpha, beta, gamma, and the number of minimum

samples. Based on the SPRT algorithm it performs

statistical verification with the results of multiple

simulation results.

11 Abstract PropertyChecker PropertyChecker checks whether a log, which is a

set of snapshots, satisfies a property or not. The

evaluateState method is to check a property

satisfaction of a snapshot. The evaluateState

method is an abstract method.

There are 6 property checker types:

Existence Checker

Absence Checker

Universality Checker

Steady State Probability Checker

Transient State Probability Checker

Minimum Duration Checker

12 Abstract Property Property is a specification of verification property.

The property has its name and specification. It has

it type and values that should be interpreted during

the verification.



20

3.3 Model Slicing Modules

3.3.1 Class Diagram

Figure 11. Class Deisgn of SIMVA-SoS Model Slicing



1 Concrete SoSSimulationModelSlicer SoSSimulationModelSlicer class receives SoS

model (SoS Java program), slicing criterion (SoS

goal, verification properties). The SoS model is

given to tracing method. The output of tracing

method is given to slicing method. The output of

slicing method is given to

generatingCompilableProg method. Finally in

SoSSimulationModelSlicer, the sliced model is

given as an output.

2 Concrete SoSGoalModelSlicer SoSGoalModelSlicer class slices SoS goal

model. The SoS goal set is given to the input of

slicingGoalModel function. The sliced set of SoS

goals are given as outputs. SoSGoalModelSlicer

and SoSSimulationModelSlicer classes have

aggregation relationship.

3 Concrete SoSGoalModel SoSGoalModel class generates goal model by

using generateGoalModel method. The method

receives set of SoS goals. SoSGoalModelSlicer

and SoSGoalModel classes have composition

relationship.

4 Concrete SoSGoal SoSGoal class defines the SoS verification

properties and relationships between SoSGoals.

The attributes of SoSGoal are goalName,


21

higherGoalName, subGoalName,

formalDescription, and goalExplanation.

By using setHigherGoal and setSubGoal

methods, it generates an SoSGoal.



22

4. Human Interface Design

4.1 Overview of User Interface

4.1.1 Requirements (specified in SRS)

A. Abstract Classes

Req ID

User Interface Requirement Input Output Priority

When a user runs SIMVA-SoS, a graphical user interface should be shown (displayed) to the user.

User event: <Run SIMVA-SoS>

Main GUI of SIMVA-SoS

high

SIMVA-SoS should provide two tabs to support <Statistical Analysis/Verification> and <Single Simulation> independently



high

When a user clicks a specific tab, the clicked tab should be opened and ready.

User event: <Click [Tab]>

Selected tab high

SIMVA-SoS should provide a menu to support importation, simulation, verification, and configuration



high

When a user wants to import inputs, SIMVA-SoS should support the importation function both using buttons on tabs and using menu items. The importation should open a proper file explorer to select files from user’s local device.

User event: <Import [input]>

File explorer high

When a user selects and imports a file, SIMVA-SoS should interpret the input file and show the file information immediately.

User event: <Select a file using file explorer>

Information of the imported file on GUI

high

SIMVA-SoS should display <Start simulation> button and menu to start single simulation.

User event: < Start simulation>

Simulation started high

SIMVA-SoS should display <Stop simulation> button and menu to stop single simulation.

User event: <Stop simulation>

Simulation terminated

high

SIMVA-SoS should display <Start verification> button and menu to start statistical verification.

User event: <Run verification>

Verification started high

SIMVA-SoS should display <Stop verification> button and menu to stop statistical verification.

User event: <Stop verification>

Verification terminated

high

During simulation, SIMVA-SoS should display simulation progress and logs to user.

Simulation started Simulation progress on GUI

high

During verification, SIMVA-SoS should display verification progress and logs to user.

Verification started Verification progress on GUI

high

To display simulation progress and logs effectively, a line graph shall be used on the simulation tab.

Simulation started Simulation line graph on simulation tab

middle

To display verification progress and logs effectively, a bar graph shall be used on the verification tab.

Verification started Verification bar graph on verification tab

middle

After simulation, SIMVA-SoS should support file output when <Save simulation results> button is clicked.

User event: <Save results>

File output saved middle


23

After verification, SIMVA-SoS should support file output when <Save verification results> button is clicked.

User event: <Save results>

File output saved middle

SIMVA-SoS should support user configuration before simulation and verification.

Simulation or verification is ready

Configured simulation or verification is ready

middle

For case that a user wants to quit SIMVA-SoS, SIMVA-SoS windows should provide a quit button.

User event: <Quit SIMVA-SoS>

SIMVA-SoS terminated

high

B. Information to be Shown on User Interface

Menu to control import, simulation, verification, configuration of simulation & verification, help

Imported model information: file information (name, directory), file structure, file contents

• Information of imported input model (system model, environment model)

• Information of imported simulation scenario: sequence of events

• Information of imported verification property: property type, property specification

• Information of imported policy specifications: set of policies

Simulation configuration

Statistical analysis configuration

Single simulation results

• Single simulation logs

• Single simulation graph

• Performance measurement & stats

Statistical analysis (verification / model checking) results

• Statistical analysis logs

• Statistical analysis results

• Performance measurement & stats

Help

• Link to website: official website & GitHub

• Help and support windows

4.1.2 Initial Design of Graphical User Interface

A. Main Window

As explained in architecture section, SIMVA-SoS contains two programs (i.e., windows): (1) Main

Window, (2) S&V Window. In Main Window, a user should be able to import models, specifications,

simulation files, and configure simulation and verification by importing files or adjusting values. In order

to support the functionalities, Main Window of SIMVA-SoS is designed as Figure 99 illustrates.

Main Window is composed of simple user interfaces such as menus, text fields, and several buttons.

Most of them are related to file import, which are implemented like a file-based software. If a user wants

to open a certain required file, then he or she can use proper types of file explorer to find input files. If a

file is selected and successfully read by Main Program, information of the imported file is displayed on

the text field. To read input files, SIMVA-SoS has an internal file interpreter that can parse the files and

do corresponding tasks.

After all required inputs are successfully imported and a user is ready to start statistical analysis, he or

she can use the ‘Run Simulation-based Analysis’ button at the bottom. If there is no error or exception,

S&V window is popped up without any error message.


24

Figure 12. GUI of Main Window to Control S&V

B. S&V Window

In S&V Program, there are three views to analyze input models & specifications, to monitor simulations,

and to analyze results of simulation and verification. Model View supports the analysis of models and

specifications by providing hierarchical viewer for models and model components. Simulation View

supports monitoring of simulation by displaying runtime logs of a simulation. Analysis View supports

analysis of model checking results and property-(or variable-)based value tracing by drawing a runtime

graph. In Simulation View and Analysis View, saving files should be supported.

Figure 13. GUI of S&V Window: Model View

Figure 14. GUI of S&V Window: Simulation View

Figure 15. GUI of S&V Window: Analysis View

Detailed images are included in Appendix C.


25

In S&V Window, a user can start or stop simulation-based analysis using buttons at the top. After a

simulation is normally started, progress bar shows current progress of simulation with percentage value.

If the simulation-based analysis is finished, results are displayed on Simulation View and Analysis View.

Figure 16. GUI of S&V Window for Simulation

4.2 Screen Images of GUI Prototyping

Figure 17. SIMVA-SoS GUI Prototyping: Simulation-based Analysis View


26

Figure 18. SIMVA-SoS GUI Prototyping: Single Simulation View

Figure 19. SIMVA-SoS GUI Prototyping: Menus


27

Appendix

Appendix A. Types of Verification Properties

Appendix B. Class Definitions in SIMVA-SoS Java Project

1) Model Classes

(1) Model Classes – Abstract Classes

(2) Model Classes – Concrete Classes

(3) Model Classes - Interfaces

2) Controller Classes

(1) Simulation & Verification Classes

(2) Model Slicing Classes

Appendix C Graphical User Interface Design – S&V Window


28

Appendix A. Types of Verification Properties


29

Appendix B. Class Definitions in SIMVA-SoS Java Project

1) Model Classes

(1) Model Classes – Abstract Classes

Type

(Abstract/Concrete)

Class/Attributes/Operations Name Parameter

Class Superclass Attributes/Operations

abstract SIMVASoS_Object - SIMVASoS_Object()

SIMVASoS_Object(objId,

objName)

SIMVASoS_Object(objId,

objName, isActivated,

objLocation)

String objId

String objName

boolean isActivated

ObjectLocation

objLocation

String objId

String objName

boolean isActivated

ObjectLocation objLocation

void activate()

void deactivate()

String getObjId()

String getObjName()

boolean isActivated()

ObjectLocation

getObjLocation()

void setObjId(objId) String objId

void setObjName(objname) String objName

void

setObjLocation(objLocation)

ObjectLocation

objLocation

concrete ObjectLocation - ObjectLocation()

ObjectLocation(xPos, yPos,

zPos)

ObjectLocation(locationInfo)

ObjectLocation(xPos, yPos,

zPos, locationInfo)

float xPos

float yPos

float zPos

String locationInfo

float xPos

float yPos

float zPos

String locationInfo

float getXPos()

float getYPos()

float getZPos()

String getLocationInfo()

void setxPos(xPos) float xPos

void setyPos(yPos) float yPos

void setzPos(zPos) float zPos

void setXYZLocation(xPos,

yPos, zPos)

float xPos

float yPos

float zPos

abstract ActionableObject SIMVASoS_Object ActionableObject()

ArrayList<SIMVASoS_Action>

actionList


selectedActionList


30


getActionList()


getSelectedActionList()

void addAction(…) SIMVASoS_Action

action

void resetActionList()

void setActionList(actionList) ArrayList

<SIMVASoS_Action>

actionList

abstract

String selectActions()

abstract

String doActions()

abstract NonActionableObject SIMVASoS_Object NonActionableObject()

float objNumValue

String objStringValue

boolean isAvailable

ArrayList<String>

objOccupyingIds

boolean isAvailable()

float getNumValue()

String getStringValue()

void setNumValue(numValue) float numValue

void setStringValue(strValue) String strValue

void setAvailable(available) boolean available

void addOccpuyingId(csId) String csId

abstract SIMVASoS_Action - SIMVASoS_Action()

int actionId

String actionName

EnumActionPriority

actionPriority

EnumActionType actionType

boolean actionPrecondition

ArrayList<SIMVASoS_Operation>

actionOperations

int actionDuration

int actionProgress

EnumActionState actionStatus

int getActionId()

String getActionName()

EnumActionPriority

getActionPriority()

boolean isPreconditionMet()

ArrayList<SIMVASoS_Operation>

getActionOperations()

int getActionDuration()

int getActionProgress()

EnumActionState

getActionStatus()

void setActionId(actionId) int actionId

void setActionName(actionName) String actionName

void setActionPriority

(actionPriority)

EnumActionPriority

actionPriority


31

void setActionOperations

(actionOperations)

ArrayList

<SIMVASoS_Operation>

actionOperations

void setActionDuration

(actionDuration)

int actionDuration

void setActionStatus

(actionStatus)

EnumActionState

actionStatus

void addActionOperation

(actionOperation)

SIMVASoS_Operation

actionOperation

void resetOperations()

void resetProgress()

abstract

String runOperations()

abstract

void checkPrecondition()

abstract SIMVASoS_Operation - SIMVASoS_Operation()

abstract

String operate()

(2) Model Classes – Concrete Classes

Type

(Abstract/Concre

te)

Class/Attributes/Operations Name

Parameter Class Superclass Attributes/Operations

concrete SoS - SoS()

SoS(name, type)

SoS(name, type, orgs, infra,

environment)

String SoSName

EnumOrgType SoSType

ArrayList<Organization> SoSOrgs

Infrastructure SoSInfra

ArrayList<SIMVASoS_Object>

SoSEnvironment

String getSoSName()

EnumOrgType getSoSType()

ArrayList<Organization>

getSoSOrgs()

Infrastructure getSoSInfra()

ArrayList<SIMVASoS_Object>

getSoSEnvironment()

void setSoSName(SoSName) String SoSName

void setSoSType(SoSType) EnumOrgType SoSType

void setSoSOrgs(orgs[]) ArrayList

<Organization> orgs

void setSoSInfra(infra) Infrastructure infra

void setSoSEnvironment

(environment)

ArrayList

<SIMVASoS_Object>

environment

void addOrg(org) Organization org

void addEnvFactor(obj) SIMVASoS_Object obj

void addSoSInfraResource

(InfraResource)

InfraResource

InfraResource

void addSoSInfraService

(infraService)

InfraService

infraService


32

void resetSoS(isRestOrgs,

isResetInfraServices,

isResetInfraResources)

boolean isResetOrgs

boolean

isResetInfraServices

boolean

isResetInfraResources

String runSoS(tick, SoSEnv) int tick

ArrayList<SIMVASoS_Obj

ect> SoSEnv

concrete Organization - Organization()

Organization(orgId, orgName,

orgType, isOrgActivated)

int orgId

String orgName

EnumOrgType orgType

boolean isOrgActivated

String orgId

String orgName

EnumOrgType orgType

boolean isOrgActivated


orgSubOrgs

ArrayList<CS> orgCSs

ArrayList<Organization_Task>

orgTasks

int getOrgId()

String getOrgName()

EnumOrgType getOrgType()


getOrgSubOrgs()

ArrayList<CS> getOrgCSs()

ArrayList<Organization_Task>

getOrgTasks()

void setOrgId(orgId) int orgId

void setOrgName(orgName) String orgName

void setOrgType(orgType) EnumOrgType orgType

void addSubOrgs(subOrg) Organization subOrg

void addCS(cs) CS cs

void addTask(orgTask) Organization_Task

orgTask

void activate()

void deactivate()

void reset(isResetSubOrgs,

isResetCSs, isResetTasks)

boolean isResetSubOrgs

boolean isResetCSs

boolean isResetTasks

String runOrganization(…) int tick

ArrayList

<SIMVASoS_Object>

SoSEnvironment

concrete Infrastructure - Infrastructure()

Infrastructure(infraName)

Infrastructure(infraName,

infraServices, infraResource)

String infraName

ArrayList<InfraService

> infraServices

ArrayList<InfraResourc

e> infraResources

String infraName

ArrayList<InfraService>

infraServices

ArrayList<InfraResource>

infraResources

String getInfraName()


33

ArrayList<InfraService>

getInfraServices()

ArrayList<InfraResource>

getInfraResources()

void setInfraName(infraName) String infraName

void

setInfraServices(infraServices)

ArrayList<InfraService

> infraServices

void

setInfraResources(infraResource

s)

ArrayList<InfraResourc

e> infraResources

void

addInfraService(infraService)

InfraService

infraService

void

addInfraResource(infraResource)

InfraResource

infraResource

String runInfrastructure(…) int tick

ArrayList

<SIMVASoS_Object>

SoSEnvironment

abstract InfraService - InfraService()

EnumServiceType serviceType

String serviceId

String serviceName

ArrayList<String>

serviceOccupyingIds

EnumServiceType

getServiceType()

String getServiceId()

String getServiceName()

void

setServiceType(serviceType)

EnumServiceType

serviceType

void setServiceId(serviceId) String serviceId

void

setServiceName(serviceName)

String serviceName

void addOccupyingId(csId) String csId

abstract

String runService(tick,

SoSEnvironment)

int tick

ArrayList

<SIMVASoS_Object>

SoSEnvironment

concrete InfraResource NonActionableObj

ect

InfraResource()

InfraResource(resType)

EnumResType resType

EnumResType resType

EnumResType getResType()

void setResType(resType) EnumResType resType

concrete CommunicationChan

nel

InfraResource CommunicationChannel()

CommunicationChannel

(channelType)

EnumChannelType

channelType

EnumChannelType channelType

ArrayList<CommunicationMessage>

messageQueue

EnumChannelType

getChannelType()

void

setChannelType(channelType)

EnumChannelType

channelType

void addMessage(msg) Message msg

void resetMessageQueue()

abstract CS ActionableObject CS() String csName


34

CS(csType)

CS(csKnowledgeList,

csResourceList)

CS(csType, csKnowledgeList,

csResourceList)

EnumCSType csType

EnumCSType csType

EnumCSState csState

ArrayList<CommunicationMessage>

csReceivedMessages

ArrayList<CS_Knowledge>

csKnowledgeList

ArrayList<CS_Resource>

csResourceList

EnumCSType getCsType()

EnumCSState getCsState()

void setCsType(csType) EnumCSType csType

void setCsState(csState) EnumCSState csState

void initSystem()

void initActionList()

void initKnowledgeList()

void initResourceList()

void initReceivedMessasges()

void

addReceivedMessage(receivedMess

age)

CommunicationMessage

receivedMessage

void addKnowledge(csKnowledge) CS_Knowledge

csKnowledge

void addResource(csResource) CS_Resource csResource

abstract

void checkMessage()

abstract

String runCS(tick,

SoSEnvironment)

int tick

ArrayList

<SIMVASoS_Object>

SoSEnvironment

abstract <<inner class>>

CS > CS_Action

SIMVASoS_Action CS_Action()

CS_Action(csActionCost,

csActionBenefit)

CS_Action(actionId, actionName)

CS_Action(actionId, actionName,

actionType, actionDuration,

csActionCost, csActionBenefit)

String actionId

String actionName

EnumActionType

actionType

int actionDuration

float csActionCost

float csActionBenefit

float csActionCost

float csActionBenefit

float csActionUtility

float getActionCost()

float getActionBenefit()

float getActionUtility()

void setActionCost(cost) float cost

void setActionBenefit(benefit) float benefit

void setActionUtility(utility) float utility

abstract

void calculateUtility()


CS >

CS_Communication

SIMVASoS_Action CS_Communication()

CS_Communication(commMsg)

Message commMsg

CommunicationMessage commMsg


35

CommunicationMessage

getCommMsg()

void setCommMsg(commMsg) CommunicationMessage

commMsg


CS > CS_Operation

SIMVASoS_Operati

on

CS_Operation()

String csBehaviorLog

String getCsBehaviorLog()

void

setCsBehaviorLog(csBehaviorLog)

String csBehaviorLog

concrete CommunicationMess

age

NonActionableObj

ect

CommunicationMessage()

CommunicationMessage(msgType)

CommunicationMessage(msgType,

msgSenderId, msgReceiverId,

msgContents)

EnumMessageType

msgType

String msgSenderId

String msgReceiverId

String msgContents

EnumMessageType msgType

String msgSenderId

String msgReceiverId

String msgContents

String getMsgSenderId() EnumMessageType

msgType

String getMsgReceiverId()

String getMsgContents()

EnumMessageType getMsgType()

void

setMsgSenderId(msgSenderId)

void

setMsgReceiverId(msgReceiverId)

void

setMsgContents(msgContents)

void setMsgType(msgType)


CS >

CS_DecisionMaking

- DecisionMaking()

DecisionMaking(mechanismId,

mechansimName)

String mechanismId

String mechanismName

String mechanismId


String getMechanismName()

String getMechanismId()

void

setMechanismName(mechanismName)


void

setMechanismId(mechanismId)

String mechanismId

abstract

ArrayList<CS_Action>

makeDecision(actionList)

ArrayList<CS_Action>

actionList

concrete <<inner class>>

CS > CS_Knowledge

NonActionableObj

ect

CS_Knowledge()

CS_Knowledge(csKnowledgeType,

csKnowledgeInfo)

EnumKnowledgeType

csKnowledgeType

String csKnowledgeInfo

EnumKnowledgeType

csKnowledgeType

String csKnowledgeInfo

EnumKnowledgeType

getKnowledgeType()

String getKnowledgInfo()

void setKnowledgeType

(knowledgeType)

EnumKnowledgeType

knowledgeType


36

void setKnowledgeInfo

(knowledgeInfo)

String knowledgeInfo

concrete <<inner class>>

CS > CS_Resource

NonActionableObj

ect

CS_Resource()

CS_Resource(csResType)

EnumResType csResType

EnumResType csResType

EnumResType getResType()

void setResType (resType) EnumResType resType

(3) Model Classes – Interfaces

Type Interface/Attributes/Operations Name

Parameter Interface Superclass Attributes/Operations

<<interface>> Environment

Element -

no constructer

abstract

void

runEnvElement(tick)

int tick

2) Controller Classes

(1) Controller Classes – Simulation & Verification

Type

(Abstract/Concrete)



Abstract Simulation - +scenario: Scenario

+sos: SoS

+simulator: Simulator

Concrete Simulator - -simulationTime: int

+sc: simulationConfiguration

+run(sos: SoS, scenario: Scenario): Log

+pause(): void

+stop(): void

+monitor(): void

Abstract SoS - -

Concrete Scenario - +event: Event[]

Concrete Event -

Abstract Action -

Concrete Log - +snapshotMap: Hashmap<Snapshot>

+addSnapshot(tick: int, snapshot: string):

void

+getSnapshot(): Hashmap<Snapshot>

Concrete Snapshot - +snapshotString: string

+getSnapshotString(): string

Abstract Verifier - +propertyChecker: PropertyChecker

+verify(simulation: Simulation, property:

Property): double

Concrete SPRT Verifier +alpha: double

+beta: double

+gamma: double

+minimumSample: int

+verifyWithSimulation(simulation:

Simulation, property: Property): pair


37

Abstract PropertyChecker - +check(log: Log, property: Property):

Boolean

+evaluateState(snapshot: Snapshot,

property: Property) Boolean

Abstract Property - +name: string

+specification: string

+type: string

+value: list<float>

(2) Controller Classes – Model Slicing

Type

(Abstract/Concrete)



Concrete SoSSimulationModelSlicer - +inputProgram: List<String>

+slicingCriterion: String

+tracing(prog: Class): StringList

+slicing(prog: List<String>, criterion: String):

List<String>

+generatingCompilableProg(prog: List<String>):

List<String>

Concrete SoSGoalModelSlicer - +resultGoalSet: Set<SoSGoal>

+slicingCriterionGoal: SoSGoal

+slicingGoalModel(goalSet: Set<SoSGoal>, criterion:

Set<SoSGoal>): Set<SoSGoal>

Concrete SoSGoalModel - +goalTree:Set<Goal>

+generateGoalModel(modelSet:Set<SoSGoal>):GoalSet

Concrete SoSGoal - +goalName: String

+higherGoalName: String

+subGoalName: String

+formalDescription: String

+goalExplanation: String

+setGoal(name: String, formal: String,

explanation:String): void

+setHigherGoal(goal: SoSGoal): void

+setSubGoal(goal: SoSGoal): void


38

Appendix C. Graphical User Interface Design – S&V Window


39

Documents

SIMVA-SoS Software Design Description (SDD)