COMP8700  Agent-Directed Simulation
This presentation is the property of its rightful owner.
Sponsored Links
1 / 45

Introduction to Model Conceptualization and Design PowerPoint PPT Presentation


  • 66 Views
  • Uploaded on
  • Presentation posted in: General

COMP8700 Agent-Directed Simulation. Introduction to Model Conceptualization and Design. Dr. Levent Yilmaz M&SNet: Auburn M&S Laboratory Computer Science & Software Engineering Auburn University, Auburn, AL 36849 http://www.eng.auburn.edu/~yilmaz.

Download Presentation

Introduction to Model Conceptualization and Design

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -

Presentation Transcript


Introduction to model conceptualization and design

COMP8700 Agent-Directed Simulation

Introduction to Model Conceptualization and Design

Dr. Levent Yilmaz

M&SNet: Auburn M&S Laboratory

Computer Science & Software Engineering

Auburn University, Auburn, AL 36849

http://www.eng.auburn.edu/~yilmaz

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


Introduction to model conceptualization and design

Aim

  • 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.


Modeling system dynamics

Modeling system dynamics

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 techniques classification

Modeling 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 modeling

Domain 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 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.


How to make a domain model

How 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.


Introduction to model conceptualization and design

Partitioning the Domain Model


Introduction to model conceptualization and design

Finding Domain Concepts

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

  • 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.


Introduction to model conceptualization and design

Approaches

  • 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


Introduction to model conceptualization and design

Associations


Introduction to model conceptualization and design

Multiplicity


Introduction to model conceptualization and design

Focus on Important Associations

  • Use Common associations list (page156 of your textbook)

  • Name an association based on TypeName – VerbName –TypeName format


Domain model adding attributes

Domain 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


Introduction to model conceptualization and design

Attributes

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

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


Introduction to model conceptualization and design

Do Not Use Attributes To Relate Concepts

  • Why not?


Formal modeling

Formal Modeling

  • 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


Declarative models

Declarative 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 models

Functional 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 models

Spatial models

  • Space notions included

  • Relationship between time and space positions

    • Example: customers moving through the server.


Introduction to model conceptualization and design

THE DEVS FORMALISM

DEVS = Discrete Event System Specification


Introduction to model conceptualization and design

Basic Entities and Relations in Modeling and Simulation

Experimental Frame

Source

Simulator

System

behavior database

Modeling

Relation

Simulation

Relation

Model


Devs modeling simulation framework

DEVS Modeling & Simulation Framework

  • 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)


The devs framework for m s

The DEVS Framework for M&S

  • 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


Formalism transformation

Formalism transformation


Devs formalism

DEVS Formalism

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

  • Basic models that can be coupled to build complex simulations.

  • Abstract simulation mechanism


Atomic model definition

Atomic model definition

Behavioral models


Devs atomic models

DEVS 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


Devs atomic models cont

DEVS Atomic models (cont.)

  • 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

Y

X

R

ext


Atomic model discrete event dynamics

Atomic model Discrete Event Dynamics

  • 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.)

  • Internal Event Transition Function (int): transforms state into another state after time has elapsed

    • (e.g., there are 10 parts available and broken part requires7 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.)

  • Output Function (): maps a state into an output

    • (e.g., number of parts available falls below a minimum number, issue an order to restock.)


Devs atomic models semantics

DEVS atomic models semantics

y (3)

x (5)

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

(6)

l (s) (2)

s

s’ = d int (s)

(4)

ta(s) (1)

DEVS = < X, S, Y, dint , dext , ta, l >


Atomic model example ping pong

Atomic model example: ping-pong

  • 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

Ball_A

A

D

Ball_B

Ball_B


Dynamic behavior of devs models

Dynamic behavior of DEVS models

in

M

out

event

x1

y1

x2

t

S

s2=ext((s0,e),x1)

s2

s1=int(x2)

s1

s0

t

e

ta(s2)

ta(s1)

ta(s0)

t


Atomic model example processing server

Atomic model example: Processing Server


Coupled models

Coupled models

Structural models (multicomponent)


Hierarchical vs incremental modelling

Hierarchical vs. Incremental modelling

G+B+P

B+P

G

P

B

GEN-BUF-PROC

BUF-PROC

out

in

out

in

out

out

GEN

BUF

PROC

done

A

B

C

Incremental : A andB: connect

ABC

BC

  • Petri Net : incremental

  • DEVS : hierarchical

A

B

C

Hierarchical : A and BC: connect


Coupled models formal specification

Coupled models formal specification

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

  • Xis 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, dinti, dexti, 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, Zijis the i to j translation function.

  • Finally, select is the tie-breaking selector.


Coupled devs example

Coupled DEVS example

< GEN-BUF-PROC model >

out

in

out

in

out

out

GEN

BUF

PROC

done

  • 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


Closure under coupling

Closure Under Coupling

DEVS

<X, S, Y, dint,dext, dcon,ta,l >

DN

<X, Y, D, {Mi }, {Ii },{Zi,j }>

Every DEVS

coupled model

has a DEVS

Basic equivalent

DEVS

<X, S, Y, dint,dext, dcon,ta,l >


Input output ports concepts

Input/output ports concepts

start

start

generator

(genr)

out

repair

shop

stop

repaired

faulty

sent

transducer

(transd)

report

out

finished

  • Components (D)

  • couplings

    • Internal Couplings (IC)

    • External Input Couplings (EIC)

    • External Output Couplings (EOC)


Coupled devs example1

Coupled DEVS example

< GEN-BUF-PROC model >

out

in

out

in

out

out

GEN

BUF

PROC

done

  • 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 :


Introduction to model conceptualization and design

1. nextTN?

3 Output?

5 applyDelt

4 myOut

2. myTN

DEVS Simulation Protocol

Coupled

Model

coordinator

simulator

tN

simulator

tN

simulator

tN

Component

tN tL

Component

tN tL

Component

tN tL

After each transition

tN = t + ta(), tL = t


Introduction to model conceptualization and design

DEVS Simulator Protocol

tL = 0

tN = ta()

simulation cycle

initialize

tL = tN

tN = tN + ta()

tL = time of last event

tN = time of next event


  • Login