COMP 8700 AgentDirected Simulation Introduction to Model Conceptualization

  • Slides: 45
Download presentation
COMP 8700 Agent-Directed Simulation Introduction to Model Conceptualization and Design Dr. Levent Yilmaz M&SNet:

COMP 8700 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 © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 1

Aim • The aim of this lecture is to overview the conventional conceptual and

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. © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 2

Modeling system dynamics Interested in modeling systems’ dynamic behavior ¾ how it organizes itself

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. © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 3

Modeling techniques classification • Conceptual Modeling: informal model. – Communicates the basic nature of

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 © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 4

Domain Modeling • Partitions and illustrates the important domain concepts. • A classic object-oriented

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. © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 5

A Domain Model Does Not Represent Software Objects • A model 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. © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 6

How to Make a Domain Model • List the candidate conceptual classes using the

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. © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 7

Partitioning the Domain Model © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 8

Partitioning the Domain Model © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 8

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

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. © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 9

Approaches • Abbott and Booch suggest: – Use nouns, pronouns, noun phrases to identify

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 © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 10

Associations © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 11

Associations © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 11

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

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

Focus on Important Associations • Use Common associations list (page 156 of your textbook)

Focus on Important Associations • Use Common associations list (page 156 of your textbook) • Name an association based on Type. Name – Verb. Name –Type. Name format © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 13

Domain Model: Adding Attributes • An attribute is a logical data value of an

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 runtime execution constitutes the state of that object. • UML Attribute Notation • Relate with associations, NOT attributes © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 14

Attributes • Show only “simple” relatively primitive types as attributes. • Connections to other

Attributes • Show only “simple” relatively primitive types as attributes. • Connections to other concepts are to be represented as associations, not attributes. © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 15

Do Not Use Attributes To Relate Concepts • Why not? © Yilmaz- - 2004

Do Not Use Attributes To Relate Concepts • Why not? © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 16

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

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

Formal Modeling • Advantage of Formal Methods – Correctness and completeness Testing – Communication

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 © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 18

Declarative models • System states (representing system entities) • Transitions between states • State-based

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 © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 19

Declarative models (cont. ) • Event-based declarative models • Arcs: represent scheduling. • Event

Declarative models (cont. ) • Event-based declarative models • Arcs: represent scheduling. • Event relation: from arrival of token i to departure of token i. © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 20

Functional models • “Black box”. • Input: signal defined over time • Output: depending

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 © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 21

Spatial models • Space notions included • Relationship between time and space positions –

Spatial models • Space notions included • Relationship between time and space positions – Example: customers moving through the server. © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 22

THE DEVS FORMALISM DEVS = Discrete Event System Specification © Yilmaz- - 2004 -12

THE DEVS FORMALISM DEVS = Discrete Event System Specification © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 23

Basic Entities and Relations in Modeling and Simulation Experimental Frame Source System Simulator behavior

Basic Entities and Relations in Modeling and Simulation Experimental Frame Source System Simulator behavior database Modeling Relation Simulation Relation Model © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 24

DEVS Modeling & Simulation Framework • DEVS = Discrete Event System Specification • Provides

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) © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 25

The DEVS Framework for M&S • Separates Modeling from Simulation • Derived from Generic

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 © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 26

Formalism transformation © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 27

Formalism transformation © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 27

DEVS Formalism · Discrete-Event formalism: time advances using a continuous time base. · Basic

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 © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 28

Atomic model definition Behavioral models © Yilmaz- - 2004 -12 -06 “Introduction to DEVS”

Atomic model definition Behavioral models © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 29

DEVS Atomic models • Atomic DEVS = < S, X, Y, int , ext

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 © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 30

DEVS Atomic models (cont. ) • ta : S R+0, • Q = {(s,

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 X ext © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” Y R 31

Atomic model Discrete Event Dynamics External Event Transition Function ( ext): transforms state and

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 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. ) Output Function ( ): maps a state into an output (e. g. , number of parts available falls below a minimum number, issue an order to restock. ) © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 32

DEVS atomic models semantics y (3) x (5) s’ = ext (s, e, x)

DEVS atomic models semantics y (3) x (5) s’ = ext (s, e, x) (s) (2) (6) s s’ = int (s) ta(s) (1) (4) DEVS = < X, S, Y, int , ext , ta, > © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 33

Atomic model example: ping-pong – AMplayer_A =< S, X, Y, int , ext ,

Atomic model example: ping-pong – AMplayer_A =< S, X, Y, int , ext , , ta > • X = {Ball_B} Ball_B • Y = {Ball_A} A D Ball_A Ball_B • S = {A, D} • int (A) = D • ext (Ball_B, D) = A • ta(A) = thinking_time • ta(D) = INFINITY • (A) = Ball_A © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 34

Dynamic behavior of DEVS models in event M x 1 y 1 out x

Dynamic behavior of DEVS models in event M x 1 y 1 out x 2 t S s 2 s s 01 s 2= ext((s 0, e), x 1) s 1= int(x 2) t e ta(s 1) © Yilmaz- - 2004 -12 -06 ta(s 0) “Introduction to DEVS” ta(s 2) t 35

Atomic model example: Processing Server © Yilmaz- - 2004 -12 -06 “Introduction to DEVS”

Atomic model example: Processing Server © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 36

Coupled models Structural models (multicomponent) © Yilmaz- - 2004 -12 -06 “Introduction to DEVS”

Coupled models Structural models (multicomponent) © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 37

Hierarchical vs. Incremental modelling GEN-BUF-PROC out GEN in done BUF out in PROC out

Hierarchical vs. Incremental modelling GEN-BUF-PROC out GEN in done BUF out in PROC out G+B+P A G B C B+P Incremental : A and B: connect B P ABC BC – Petri Net : incremental A – DEVS : hierarchical Hierarchical : A and BC: connect © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” B C 38

Coupled models formal specification CM = < X, Y, D, {Mi}, {Ii}, {Zij}, select

Coupled models formal specification 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. © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 39

Coupled DEVS example < GEN-BUF-PROC model > GEN out in done BUF out in

Coupled DEVS example < GEN-BUF-PROC model > GEN out in done BUF out in PROC out – 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 © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 40

Closure Under Coupling DN < X , Y, D, {Mi }, {Ii }, {Zi,

Closure Under Coupling DN < X , Y, D, {Mi }, {Ii }, {Zi, j }> DEVS < X, S, Y, int, ext, con, ta, > © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” Every DEVS coupled model has a DEVS Basic equivalent 41

Input/output ports concepts • Components (D) • couplings – Internal Couplings (IC) – External

Input/output ports concepts • Components (D) • couplings – Internal Couplings (IC) – External Input Couplings (EIC) – External Output Couplings (EOC) start generator (genr) out repair faulty shop stop repaired sent transducer (transd) finished © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” report out 42

Coupled DEVS example < GEN-BUF-PROC model > GEN out in done BUF out in

Coupled DEVS example < GEN-BUF-PROC model > GEN out in done BUF out in PROC out – 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 : © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 43

DEVS Simulation Protocol 1. next. TN? 3 Output? coordinator Coupled Model 5 apply. Delt

DEVS Simulation Protocol 1. next. TN? 3 Output? coordinator Coupled Model 5 apply. Delt simulator t. N 4 my. Out 2. my. TN Component t. N t. L simulator t. N Component t. N t. L After each transition t. N = t + ta(), t. L = t © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 44

DEVS Simulator Protocol t. L = 0 simulation cycle t. N = ta() initialize

DEVS Simulator Protocol t. L = 0 simulation cycle t. N = ta() initialize t. L = t. N t. L = time of last event t. N = t. N + ta() t. N = time of next event © Yilmaz- - 2004 -12 -06 “Introduction to DEVS” 45