Automata-based programming. Automata-based programming is a programming paradigm in which the program or its part is thought of as a model of a finite state machine (FSM) or any other (often more complicated) formal automaton (see automata theory).
Sometimes a potentially-infinite set of possible states is introduced, and such a set can have a complicated structure, not just an enumeration. FSM-based programming is generally the same, but, formally speaking, doesn't cover all possible variants as FSM stands for finite state machine and automata-based programming doesn't necessarily employ FSMs in the strict sense. The following properties are key indicators for automata-based programming: The time period of the program's execution is clearly separated down to the steps of the automaton. Each of the steps is effectively an execution of a code section (same for all the steps), which has a single entry point. The whole execution of the automata-based code is a (possibly explicit) cycle of the automaton's steps.
Model-driven architecture. Model-driven architecture (MDA) is a software design approach for the development of software systems.
It provides a set of guidelines for the structuring of specifications, which are expressed as models. Model-driven architecture is a kind of domain engineering, and supports model-driven engineering of software systems. It was launched by the Object Management Group (OMG) in 2001.[1] Overview[edit] The model-driven architecture approach defines system functionality using a platform-independent model (PIM) using an appropriate domain-specific language (DSL)[citation needed]. Then, given a platform model corresponding to CORBA, .NET, the Web, etc., the PIM is translated to one or more platform-specific models (PSMs) that computers can run.
The PSM may use different DSLs or a general purpose language. The OMG organization provides rough specifications rather than implementations, often as answers to Requests for Proposals (RFPs). Related standards[edit] Trademark[edit] MDA approach[edit] ATL Use Case - Model Driven Performance Engineering: From UML/SPT to AnyLogic. In this case study we present a transformation from annotated UML activity diagrams to AnyLogic simulation models.
The actions and control flows in activity diagrams are annotated with performance information utilizing the UML profile for schedulability, performance, and timing (SPT). This information is used to generate a simulation model that can be executed by the AnyLogic simulation tool from XJ Technologies. Such simulations can help to identify performance issues early in a software design process.
When designing software, system behavior can be modeled using UML by utilizing, for instance, activity diagrams. To lower costs and risks, it is desirable to run analysis on the modeled system before it is actually implemented. The pizza ordering process as activity diagram In the diagram, several elements are stereotyped with the PStep stereotype. Performance attributes of the CreateOrder action Running simulation in AnyLogic Overall Transformation Process.
ATL/Concepts. Models are now part of an increasing number of engineering processes (such as software engineering).
However, in most cases, they are still confined to a simple documentation role instead of being actively integrated into the engineering process. As opposed to this passive approach, the field of Model-Driven Engineering (MDE) aims to consider models as first class entities. It also considers that the different kinds of handled items (such as the tools, the repositories, etc.) can be viewed and represented as models.
The model-driven approach supposes to provide model designers and developers with a set of operations dedicated to the manipulation of models. In this context, model transformation appears to be a central operation for model handling: it aims to make it possible to specify the way to produce a number of target models based on a set of source models. This section aims to provide an overview of the main MDE concepts, with a particular focus on model transformation. Figure 1. Applying UML and Patterns: An Introduction to Object-Oriented Analysis and Design and Iterative Development, Third Edition > Introduction > Object-Oriented Analysis and Design.