dv_guide_1.1.doc

Analyst’s Guide
Single-Thread Software Architecture

INTRODUCTION .........................................................................................................................2

1.1

OW TO

SE THIS

OCUMENT

...................................................................................................2

1.2

YNAMIC

ERIFICATION

...........................................................................................................2

BEFORE YOU START.................................................................................................................3

2.1

NALYSIS

REPARATION

...........................................................................................................3

2.2

YPE

APPINGS

........................................................................................................................3

2.3

ROJECT

IRECTORY

................................................................................................................3

2.3.1

System Directory ..............................................................................................................3

2.3.2

Stub Bridges.....................................................................................................................4

2.4

ENERATING

ODE

...................................................................................................................5

CREATING THE PROGRAM .....................................................................................................5

3.1

STABLISH

ROJECT

..........................................................................................................5

3.2

ILES

ROJECT

.............................................................................................................5

3.3

OMPILE

LAGS AND

WITCHES

..........................................................................................5

3.4

UILD

.......................................................................................................................................5

TESTING.......................................................................................................................................5

Analyst’s Guide
Single-Thread Software Architecture

1. INTRODUCTION

1.1 How to Use this Document

This document provides the Analyst/Developer with the information needed to prepare for
Dynamic Verification on MBSE models using the Pathfinder Solutions Instrumented Execution
(IE) model-level debug environment. It is assumed the developer is familiar with the following
papers available from the Pathfinder Solutions web site downloads page:

www.pathfindersol.com/downloads

n “Model Based Software Engineering - An Overview of Rigorous and Effective

Software Development using UML”

n “Model Based Software Engineering Process”
n “MBSE Modeling Conventions”
n “Pathfinder Solutions Design Templates and Components Analyst’s Guide”

This document provides a step-by-step description of how to create a program for use in the
Dynamic Verification of a set Analyzed domains. These steps will provide you with an
executable that you can use to run models against a set of scenarios, determine their actual
behavior, and investigate the cause of any deviations from expected behavior.

This document does not offer insight on how to verify that your particular application executes
properly, nor does it lay down general software verification processes or techniques.

1.2 Dynamic Verification

The topic of Dynamic verification is outlined in the “Model Based Software Engineering Process”
paper. To summarize here, Dynamic Verification is the portion of the overall MBSE process
where the models are verified through execution. It roughly corresponds to what may be known
as the Unit Test phase. The starting unit of test is a domain. Tests are performed on a domain
basis, focusing on the scenarios described during Scenario Modeling. Once each Analyzed
domain is proven valid at this level, it may be helpful to assemble sets of domains that bridge
tightly together, so they may be verified as a set.

Once the Analyzed domains are ready to put together, Dynamic Verification has been
successfully completed and Software Integration can begin. Software Integration is a
development-environment-based effort where all Analyzed domains are brought together with
any available realized domains (those that can run on the development platform) and
appropriate simulators (for approximating hardware specific realized domains and interfaces).

Analyst’s Guide
Single-Thread Software Architecture

2. BEFORE YOU START

2.1 Analysis Preparation

Before you can build an executable for DV, you must have completed the Analysis for the target
domain(s). This means the following Analysis components must be complete (including all
descriptions), syntactically correct, and reviewed: Domain Model, Information Model, Scenario
Models, State Models, and Action Models for all domain services, object services, and state
actions.

In addition to team reviews of the above Analysis, be sure to run the Model Auditor static
checker and correct all errors it finds.

For every target domain, be sure Instrumented Execution is enabled by checking the properties
page of the domain description dialog. “IE Enabled” should be checked.

2.2 Type Mappings

Also, any enumerates referenced as a range of values in the target domain’s Analysis (including
the bridge) must be defined in the types subdirectory of the encyclopedia directory. System-
level types go in <system name>.typ, and domain-specific types are defined in <domain
prefix>.typ.

2.3 Project Directory

Establish a working directory for your project using the following layout:
project/

anal/

: Analysis encycloped ia

gc/

: generated code for all analyzed

domains in system

<domain 1 prefix>/

: gen. code for 1

analyzed domain

<target domain prefix n>/ : gen. code for nth analyzed domain

sys/

: gen. code for system -wide items

reports/

: contains formatted reports and

shortcuts to generate them

stubs/

: directory for stubbed bridges

system/

: system-specific definition files

gencode.bat

: (see below)

gencode.err

: shortcut to gc\sprngbrd.err

You create the script gencode.bat to generate code for your system. Use it to identify where
your local and Pathfinder code archetypes are, and where your Analysis encyclopedia is:

springboard -d <local code arche type directory> -d <Pathfinder code

archetype directory> -e ..\anal sys_top <system name>

2.3.1 System Directory

Populate your system directory with templates from the system directory in the Pathfinder
installation. Edit the following files:

startup.cpp
Edit startup.cpp to add any project-specific startup processing, such as invocation of startup
domain services, or the creation of preexisting instances, Add this code just below the line:

Analyst’s Guide
Single-Thread Software Architecture

// Add application -specific initializations here:

Be sure to provide any required includes just below the line:
// Put application -specific includes here

driver.cpp
Review all the scenarios you are going to run, and list all the bridge services or indirect events
from “external” sources. Invent an input scheme to map character input to services called or
events sent. Modify the function check_input_thread()  to prompt for your inputs, and add a
case to the switch construct for each service you have to drive, or event to send. Be sure to
add the appropriate includes just below the line:
// Put application -specific includes here

Example: assume you have the target domain FoodPrep(FP). The scenarios for this set of tests
indicate we will call FP.SystemInit and FP.StartRecipe. At the top of driver.cpp we add the
include:
// Put application -specific includes here
#include “fp_brg.hpp”

Then, in check_input_thread() , our prompt and switch become:
cerr << "\ndriver input ('i' to init, 'r' for CC cookie recipe):";
cin >> reply;
switch (reply)
{

case 'i':

FP::SystemInit();

break;

case 'r':

FP::StartRecipe(“Chocolate Cookies”, 0);

break;

default:

cerr << “INPUT ERROR \n.”;

break;

}

version.hpp
Change the version string to reflect the details of your system. You may want to indicate this is a
DV build.

2.3.2 Stub Bridges

For each domain that your target domain(s) directly invokes services of, create a stub bridge:
n copy <domain prefix>.hpp from project/gc/sys to project/stubs
n rename it to <domain prefix>_services.cpp
n turn each service profile definition into an actual function: remove the “;” and add a “{ }”

body

n eliminate all the existing includes
n add an include for “<domain prefix>.hpp”
n add any required code to the stub bodies. This may include:

n printing input parameters to cerr
n sending back hardcoded output values
n sending back a reply indirect event
n invoking a service of the client domain

Analyst’s Guide
Single-Thread Software Architecture

2.4 Generating Code

Once you’ve set up your project directory, run gencode.bat. This will populate the gc directory
with code from all analyzed domains. Be sure to check the translation error log - conveniently
accessed through gencode.err - and correct all Analysis errors identified there. Repeat until
you get a clean generate.

3. Creating The Program

Once the Analysis and project directory are set, it is time to build the DV executable.

3.1 Establish The Project

For a C++ environment that supports makefiles, you can build (or generate) a makefile. For
those C++ IDE that support various “application types”, set up to build a console application.

3.2 Add Files To Project

Add all .cpp files from the following directories:
n project/system
n project/stubs
n project/gc/sys
n project/gc/<domain prefix> for all target domains

Be sure to add the Software Mechanisms library sw.lib to your link list. Additionally,
depending on what else you’ve linked in, you may need to add winmm.lib.

3.3 Set Compile Flags and Switches

The compiler include path should be:

n system
n sw (from Pathfinder installation)
n gc/sys
n gc/<domain prefix> for all target domains
(all the above paths except sw are relative to the project directory)

To properly support the driver input thread, the compiler symbol PATH_MULTI_TASK must be
set.

3.4 Build

Go ahead and build the program. Sometimes modeling errors and inconsistencies aren’t
possible to detect before compilation time, so you may find these now as compiler errors –
usually as mismatches between function invocations and function profile definitions. Also, and
inconsistencies or incompleteness in your mappings from one Analysis data type another, or to
implementation types may be shown here.

4. Testing

You can simply run the program at this point. To use Instrumented Execution object-level
debugging, start the IE server before starting your DV executable. It is common to run the
application from within a C++ language-level debugger in conjunction with IE. Don’t forget to
verify your startup instance population – both attribute values and association connectivity. The
focus on your scenarios.

Good luck, and good hunting!