© Yilmaz- - 2004-12-06 “Introduction to DEVS” 1 Introduction to Model Conceptualization and Design Dr. Levent Yilmaz M&SNet: Auburn M&S Laboratory Computer

© Yilmaz- - 2004-12-06 “Introduction to DEVS” 1

Introduction to Model Conceptualization and Design

Dr. Levent YilmazM&SNet: Auburn M&S Laboratory

Computer Science & Software EngineeringAuburn University, Auburn, AL 36849http://www.eng.auburn.edu/~yilmaz

COMP8700 Agent-Directed Simulation

Acknowledgements: Thanks to Dr. Bernard Zeigler and Dr. Gabriel Wainer for sharing their DEVS lecture materials


AimAim

• The aim of this lecture is to overview the conventional conceptual and design models as well as fundamentals, principles, and the conceptual framework underlying the DEVS formalism.


Interested in modeling systems’ dynamic behavior how it organizes itself over time in response to imposed conditions and stimuli.

Predict how a system will react to external inputs and proposed structural changes.

Modeling system dynamicsModeling system dynamics


Modeling techniques classificationModeling techniques classification

• Conceptual Modeling: informal model.

– Communicates the basic nature of the process

– Provides a vocabulary for the system (ambiguous)

– General description of the system to be modeled


Domain ModelingDomain Modeling

• Partitions and illustrates the important domain concepts.

• A classic object-oriented analysis activity.

• What are the objects of interest in the this domain?

– their attributes?

– their relationships?

– IMPORTANT: Not software objects, but a “visual dictionary” of domain

concepts.


A Domain Model Does Not Represent Software Objects

• A model of domain concepts, not of software objects.

– A “visual dictionary” of important words in the domain.

• Uses UML static structure diagram notation.

V ideo

ID

S tocks

R ents

R ents-from

11..*

1 *1*

V ideoS tore

addressnam ephoneN um ber

C ustom er

addressnam ephoneN um ber


How to Make a Domain ModelHow to Make a Domain Model

• List the candidate conceptual classes using the Conceptual Class category list

• Draw them in a domain model

• Add the associations necessary to record relations

• Add the necessary attributes to fulfill the information requirements.


Dom ain Concepts

Core/M isc Paym ents Products Sales

Core/M isc

Person

VideoStore

addressnam e

M anaged-by

11...etc...

Products

Rents

1..*1

Product

description...

V ideo

...

SoftwareGam e

...

AudioTape

...

Note how onecan referencetypes fromotherpackages.

Core::VideoStore

Partitioning the Domain Model


• Candidate lists (Conceptual category list – textbook page 134)

Finding Domain Concepts

• Linguistic Analysis: Identify the nouns and noun phrases in textual descriptions.

– Care must be applied with this method: a mechanical noun-to-class mapping isn’t possible, and words in natural languages are ambiguous.

• Specification: Design a library catalog system. The system must support the registration of patrons, checking books in and out patrons, adding and removing of books, and determining which patron has a book.


• Abbott and Booch suggest:

– Use nouns, pronouns, noun phrases to identify objects and classes

– Singular object, plural class

– Not all nouns are really going to relate to objects

• Coad and Yourdon suggest:

– Identify individual or group “things” in the system or problem

• Ross suggest:

– People, places, things, organizations, concepts, events

• Danger signs: class name is a verb, is described as performing something

Approaches


S aleP O S T R ecords-current 11

assoc ia tion nam e m ultip lic ity

-"d irec tion reading arrow "-it has no m eaning except to ind icate d irection of read ing the assoc ia tion labe l-o ften exc luded

Associations


zero or m ore ;"m any"

one or m ore

one to fo rty

exactly five

T

T

T

T

*

1..*

1..40

5

T3, 5 , 8 exactly three,

five or e ight

C ustom er

V ideo

R ents

*

O ne ins tance o f aC ustom er m ay be ren tingzero or m ore V ideos.

O ne ins tance o f a V ideom ay be be ing rented byzero or one C ustom ers .

0 ..1

Multiplicity


V ideo

...R ents

In fluenced-by

1

1..*

1 Loan P olicy

...

C ustom er

...

Im portant assoc ia tion.N eed to rem em ber.

Low va lue assoc ia tion.P oss ib le , bu t so w hat?

Focus on Important Associations

• Use Common associations

list (page156 of your

textbook)

• Name an association

based on TypeName –

VerbName –TypeName

format


Domain Model: Adding AttributesDomain Model: Adding Attributes

• An attribute is a logical data value of an object.

• The values of attributes of an object at any time during run-time execution constitutes the state of that object.

• UML Attribute Notation

• Relate with associations, NOT attributes


Attributes

• Show only “simple” relatively primitive types as attributes.

• Connections to other concepts are to be represented as associations, not attributes.

P aym ent

date : D atetim e : T im eam ount : M oney

attribu tes


Do Not Use Attributes To Relate Concepts

• Why not?

Video

...

Rents 1 1.. *Customer

...Better

Video

renter : Customer

Customer

rentedVideos: List of VideoWorse


Catalog

VideoDescription

titlesubjectCategory

VideoRental

dueDatereturnDatereturnTime

CashPayment

amount : Money

Video

ID

Stocks

Rents

Rents-from

Pays-for

Initiates

Owns-a

Described-by

Membership

IDstartDate

11

1.. *

1

1

1

1.. *

1

1

*

1

1

1

*1*

Pays-for-overdue-charges

RentalTransaction

date

LoanPolicy

perDayRentalChargeperDayLateCharge

Determines-rental-charge

1

Defines

1.. *

*

1.. *

1

1

* *

VideoStore

addressnamephoneNumber

Customer

addressnamephoneNumber

1

1

1.. *

Records-rental-of

0..1

1

Has Maintains

*

1

1


• Advantage of Formal Methods

– Correctness and completeness Testing

– Communication means Teamwork

• Formalism

– Communication convention

– Formal specification in unambiguous manner

– Abstraction (representation) + Manipulation of abstraction

– Formal model - Formal specification

Formal ModelingFormal Modeling


Declarative modelsDeclarative models

• System states (representing system entities)

• Transitions between states

• State-based declarative models

– Example: States = number of persons waiting in line

– Transitions: arrival of new customers/departure of serviced ones


Declarative models (cont.)Declarative models (cont.)

• Event-based declarative models

• Arcs: represent scheduling.

• Event relation: from arrival of token i to departure of token i.


Functional modelsFunctional models

• “Black box”.

• Input: signal defined over time

• Output: depending on the internal function.

• Timing delays: discrete or continuous

– Example: inputs = customers arriving

– Outputs = delayed output of the input customers


Spatial modelsSpatial models

• Space notions included

• Relationship between time and space positions

– Example: customers moving through the server.


THE DEVS FORMALISMDEVS = Discrete Event System Specification


Source

System

Simulator

Model

Experimental Frame

SimulationRelation

ModelingRelation

behavior database

Basic Entities and Relations in Modeling and Simulation


• DEVS = Discrete Event System Specification

• Provides sound formal M&S framework

• Supports full range of dynamic system representation capability

• Supports hierarchical, modular model development

(Zeigler, 1976/84/90/00)

DEVS Modeling & Simulation FrameworkDEVS Modeling & Simulation Framework


• Separates Modeling from Simulation

• Derived from Generic Dynamic Systems Formalism

– Includes Continuous and Discrete Time Systems

• Provides Well Defined Coupling of Components

• Supports

– Hierarchical Construction

– Stand Alone Testing

– Repository Reuse

• Enables Provably Correct, Efficient, Event-Based, Distributed Simulation

The DEVS Framework for M&SThe DEVS Framework for M&S


Formalism transformationFormalism transformation


DEVS FormalismDEVS Formalism

Discrete-Event formalism: time advances using a continuous time base.

Basic models that can be coupled to build complex simulations.

Abstract simulation mechanismAtomic Models:

M = < X, S, Y, int, ext, , D >.

Coupled Models:

CM = < X, Y, D, {Mi}, {Ii}, {Zij}, select >


Atomic model definitionAtomic model definition

Behavioral models


DEVS Atomic modelsDEVS Atomic models

• Atomic DEVS = < S, X, Y, int ,ext , , ta >

• X : external input event set

• Y : external output event set

• S : sequential state set

int: internal transition function

ext :external transition function

: output function

• ta : time advance function


• ta : S R+0,

• Q = {(s,e) | s S, 0 e ta(s)} : total state set, e: elapsed time

int : S S

ext : X * Q X

: S Y

S

int

ext

R

X Y

DEVS Atomic models (cont.)DEVS Atomic models (cont.)


External Event Transition Function (ext): transforms state

and an input event into another state(e.g., receiving a faulty device, put it into a queue to await its turn for repair.)

Output Function (): maps a state into an output (e.g., number of parts available falls below a minimum

number, issue an order to restock.)

Internal Event Transition Function (int): transforms state

into another state after time has elapsed(e.g., there are 10 parts available and broken part requires

7 of them, after fixing broken part, 3 parts will remain.)

Time Advance Function (ta): maps a state into a duration (e.g., how long to fix a device once processing has started.)

Atomic model Discrete Event DynamicsAtomic model Discrete Event Dynamics


ta(s) ta(s) (1)(1)ss

DEVS = DEVS = < X, S, Y, < X, S, Y, int int , , ext ext , ta, , ta,

ss

y y (3)(3)

ss’ ’ = = int int ss

x x (5)(5)

ss’ ’ = = ext ext ((s,e,x)s,e,x)

(6)(6)

DEVS atomic models semanticsDEVS atomic models semantics


– AMplayer_A =< S, X, Y, int ,ext , , ta >

• X = {Ball_B}

• Y = {Ball_A}

• S = {A, D}

int (A) = D

ext (Ball_B, D) = A

• ta(A) = thinking_time

• ta(D) = INFINITY

(A) = Ball_A

A DBall_B

Ball_ABall_B

Atomic model example: ping-pongAtomic model example: ping-pong


Moutin

event

t

x1 y1 x2

t

S

s0

s1

s2

s2=ext((s0,e),x1)s1=int(x2)

t

e

ta(s0)ta(s1)ta(s2)

Dynamic behavior of DEVS modelsDynamic behavior of DEVS models


Atomic model example: Processing ServerAtomic model example: Processing Server

JobQueue

Sigma

S JobIn

Out

Atomic Model: P

State Variables: sigma = , phase = Passive; Job = none (< Job-id, Processing-time >); /* Represents the job being executed */ Job-Queue = Empty (Job*) /* Contains the Job-id's waiting for the CPU. */

Formal specification for P: X = { Job <N, R>}; Y = { Job-id N} S = { { Phase, sigma, Job-Queue, Job} }

ext (Job-Queue, Job, e, x (type: Job)) { case phase passive: sigma = x.Processing-time; phase = busy; Job = x.Job-id; busy: add( x, Job-Queue ); sigma = sigma - e; } int (Job-Queue, Job, e) { case phase busy: if empty(Job-Queue) phase = passive; sigma = ; else Job = Get(Job-Queue); sigma = Job.Processing-time; endif passive: /* Never happens*/ } s) { send Job.Job-Id to the port out }


Coupled modelsCoupled models

Structural models (multicomponent)


– Petri Net : incremental

– DEVS : hierarchical

GEN BUF PROCout outin in out out

done

GEN-BUF-PROC

BUF-PROC

G+B+P

B+PG

PB

A B C

Incremental : A andB: connect

A B C

Hierarchical : A and BC: connect

BCABC

Hierarchical vs. Incremental modellingHierarchical vs. Incremental modelling


CM = < X, Y, D, {Mi}, {Ii}, {Zij}, select >

• X is the set of input events;

• Y is the set of output events;

• D is an index for the components of the coupled model, and i D, Mi is a basic DEVS model (that is, an atomic or coupled

model), defined by

Mi = < Ii, Xi, Si, Yi, inti, exti, tai >

• Ii is the set of influencees of model i (that is, the models that can be influenced by outputs of model i), and j Ii, Zij is the i to j translation function.

• Finally, select is the tie-breaking selector.

Coupled models formal specificationCoupled models formal specification


– GEN-BUF-PROC = < X, Y, {GEN, BUF, PROC}, {Ii}, {Zij}, SELECT >

• X = ; Y = { out }

• I(GEN) = BUF;

• I(BUF) = PROC;

• I(PROC)= {BUF, self}

• Z(GEN)=BUF; Z(BUF)=PROC;

• Z(PROC) = BUF; Z(PROC)=self.

• SELECT : ({GEN, BUF, PROC}) = GEN ({BUF, PROC}) = BUF


done

< GEN-BUF-PROC model >

Coupled DEVS exampleCoupled DEVS example


DN X , Y, D, {Mi }, {Ii }, {Zi,j }

DEVS X, S, Y, int, ext, con, ta,

DEVS X, S, Y, int, ext, con, ta,

Every DEVS coupled model

has a DEVS Basic equivalent

Closure Under CouplingClosure Under Coupling


• Components (D)

• couplings

– Internal Couplings (IC)

– External Input Couplings (EIC)

– External Output Couplings (EOC)

repairshop

out

sent

finished

repairedfaulty

generator(genr)

transducer(transd)

out report

stop

start

start

Input/output ports conceptsInput/output ports concepts


– GEN-BUF-PROC = < X, Y, {GEN, BUF, PROC}, EIC, EOC, IC, SELECT >

• X = • Y = { out }

• EIC = • EOC = { (PROC.out, GEN_BUF_PROC.out) }

• IC = { (GEN.out, BUF.in), (BUF.out, PROC.in), (PROC.out, BUF.done)}

• SELECT : ({GEN, BUF, PROC}) = GEN ({BUF, PROC}) = BUF :


done

< GEN-BUF-PROC model >

Coupled DEVS exampleCoupled DEVS example


coordinator

simulatortN

After each transition tN = t + ta(), tL = t

ComponenttN tL

simulatortN

simulatortN

Coupled Model

1. nextTN?

2. myTN

3 Output?

4 myOut

5 applyDelt

DEVS Simulation Protocol

ComponenttN tL

ComponenttN tL


tL = tN

tN = tN + ta()

tL = 0

tN = ta()

initialize

DEVS Simulator Protocol

tL = time of last event

tN = time of next event

simulation cycle

Documents

© Yilmaz- - 2004-12-06 “Introduction to DEVS” 1 Introduction to Model Conceptualization and Design Dr. Levent Yilmaz M&SNet: Auburn M&S Laboratory Computer