A random variable: some usefull links on wikipedia
- from the sample space
- onto real numbers
This article introduces a methodology and formalism for developing multiple, cooperative models of physical systems of the type studied in qualitative physics. The formalism combines discrete event and continuous models and offers an approach to building intelligent machines capable of physical modeling and reasoning.
... simulation methodology developed concepts to model complex systems over multiple levels of abstraction ... a concept of multimodel to formalize models containing several submodels, only one of which is put into effect at any given time.The idea of a multimodel has its roots within the work in combined simulation modeling.Combined modeling has traditionally referred to a integration of discrete event and continuous modeling within the same system description.
formalism for developing multiple, cooperative models of physical systems of the type studied in qualitative physics. The formalism should help to build intelligent machines capable of physical modeling and reasoning.
... to aid in question-answering at di erent levels.
... Using the canonical model definition ...
The emphasis on behavior preservation through homomorphic mapping insures maximal consistency when dynamically mapping between abstraction levels.
We see the need for multiple models and effective methods for linking models using behavior preserving morphisms.
If you boil the water, what will happen next?"
... a top-down approach
models can be derived in a top-down approach. We start with an abstract model expressed as an FSA ( nite state automaton) and perform homogeneous (i.e., staying within the same formalism) refinement to derive two more levels of refinement...
A deterministic system < T, U, Y, Q,omega,delta,lambda > within classical systems theory 29, 40] is defined as follows:
delta(s,t,w): the input w for a duration of t time units
Discrete State Space:
Continuous State Space:
Discrete event models cannot be localized within table 2 since the concept of "discrete event" refers to a discrete updating process rather than to the discrete or continuous character of time or state.
What about continuous events -> no references in literature. They are discrete since they map to cognitive and linguistic concets connected with the processes that we model.
A combined model combines two or more of the above model typesl.
An event is a state < s, ..., sn > (where si are components of the state vector) at a specific time t. Therefore, an event is of the form < t, s, ..., sn >. This definition of event was first used in physics, and is defined in systems theory
Events are defined as points in time relative to the level of abstraction associated with the model; many events such as NextToWaterFountain can be modeled as activities (rather than ...
Note that a transition condition may sometimes refer to a more detailed state specication than is available at the current level of abstraction.
Alternatively, the modeller may decide to terminate the refinement process leaving the transition non-deterministically specified.
Note that the continuous models share a common set of state variables. However, in general state variables may be diff
erent for each Mi model.
the lowest level. To form a multimodel, we need to specify how the set of models that we have defined can be coordinated so that exactly one submodel is active at any time.
"Q-Type" means category of question. There are 4 types of questions specified PRED (prediction), DIAG (diagnostic), EXP (explanation), and REF (reference). A predictive question is one where simulation is required to generate the answer. A diagnostic question yields a short answer specifying the immediate cause, whereas an explanation is more lengthy and may involve a summary of information to be presented. A reference question is one that does not involve analysis or simulation such as "What is the material in the pot?"
IEEE Software, Vol. 19, No. 1. (2002), pp. 8-10.
by Daniels J
But all too often, the understanding is muddled and confused because the designer hasn’t clearly established the picture’s (remark: that represent some aspect of the software or its requirements) purpose or explained how others should interpret it.
The important difference is the level of abstraction.
Two issues with models to better understand the real-world problem to be solved:
I’ll refer to all models of situations in the world—of which information models are one example—as conceptual models; other terms that are used include essential models, domain models, business models, and even, most confusingly in my view, analysis models.
Three kind of models:
Opportunities for confusion between these three modeling perspectives are particularly large.
We find different representations of the same concept in many different parts of the application.
life gets much more complicated when we attempt to model behavior
... they claimed that the process of moving from conceptual model to code was one that simply involved elaboration rather than mapping or translation.
But the generality of class diagram is part of the problem. Even within the limited scope of a single development project, you’ll typically find class diagrams used for a range of purposes, including the structural aspects of all three kinds of models discussed earlier.
A breakthrough in software systems will be a consequece of building software systems by assembling them from pre-fabricated parts, rather than repeatedly starting system development from scratch.
simulation: software model are for the purpose of understanding the system itself. The model does not correspond in real time to any portion of the world: instead it is used to ask 'what if' questions
controlling a process: software responds to stimuli generated within the process and produces appropriate responses to control the future development of the process
The world is partially predictable. We can predict the sun will rise, and having risen will not rise again after it has set.
Does the sun send messages to all birds individually? If so, in what order? Is there a problem of deadlock? This is a problem of software execution.
To model the world we use two basic concepts: objects and events.
Somewhere in the software is a concept model, partially mimicking the behaviour of certain things in the world.
Notion of a domain: separately considered sub-systems: e.g. concept domain, interaction domain
Three kind of essential models:
To offer significant advantages, there must be consistency and systematic correspondance between these three models of a system.
Important activity: decide what to include: infinity of phenomena which can be perceived and might be included
all events are instantaneous, regardless of how long they take in the real world
The essential model does not describe cause and effect relationships. This is infinitely complex and non-deterministic. However, we do notice that some sequences of events do occur in the world, whereas others don't.
The essential model tracks the changes of state of the observed situation. The essential model states which sequences of events can happen, and which cannot. There are no 'run-time errors' in a correct essential model: if an event occurs which is not allowed by the model, then the model does not describe the situation properly.
An essential model, once built, could in principle be executed and would act as a kind of simulation of the modelled situation.
It is necessary to define the boundary between the software and its environment.
It is important not to under-estimate the changes which introducing software can make to a situation.
To state what the software will do.
A specification model can:
It ignores control flow, concurrency, user-interface details, persistence and so on. The specification should describe the implementation accurately, in the sense that it would be possible to produce a formul proof that the implementation implements the specification correctly ... in the current state of the art, such proofs a rarely a practical proposition for software systems of any significant size or complexity.
To create a specification model we must draw a boundary between the software and the rest of the situation, which we call the environment. To design a specification model requires considerable thought about how the software and its environment will interact.
semantically close to the execution model
the effects of languages are most likely to be seen in this model
egg model: data, operations and shell
event: detected by hardware device, then detected by interaction domain objects which will send appropriate messages to concept domain objects
In essential and specification models speed of execution is not an issue
each view shows a different aspect of the model. Textual view, graphical view.
Two most important views:
.. we define how formal, mathematical, specification can be used to enchance these views
We would like to be able to reuse elements from our essential and specification models too.