Presentation is loading. Please wait.

Presentation is loading. Please wait.

AutoFocus - Case Tool Mela Enrica. Summary History AutoFocus as notation AutoFocus as tool Features.

Similar presentations


Presentation on theme: "AutoFocus - Case Tool Mela Enrica. Summary History AutoFocus as notation AutoFocus as tool Features."— Presentation transcript:

1 AutoFocus - Case Tool Mela Enrica

2 Summary History AutoFocus as notation AutoFocus as tool Features

3 History 1996  The modeling tool has been built at the faculty of computer science at the Technische Universität München during the practical course `Software Engineering' by students and members of the chairs Prof. Broy and Prof. Endres 1997  A rapid prototyping and simulation environment implemented during the Softwaretechnik-Praktikum 2000 …  Validas Ag has integrated many add-ons and free features into AutoFocus (code generation)  Based on the Validas tool infrastructure TUM build the prototype AutoFlex(next generation of AutoFocus)

4 Design tool AutoFocus Embedded systems, which are logically (and later in the implementation possibly also physically) distributed Uses a component-based paradigm to represent models of hierarchical structuring techniques, such as decomposition of system components during the development process uses several graphical views All system views have Based on the formal development method Focusformal

5 Summary History AutoFocus as notation AutoFocus as tool Features

6 Modeling with AutoFocus Components : elements of the system which are physically or logically separated from each other Ports: interfaces of components Channels: connect two ports, are directed Ports and channels are typed

7 Modeling with AutoFocus(2) When modeling begins, the system as a whole is usually represented by just one single component (interface view of the system) First, we have to determine which pieces of information enter and leave the system and in which form(input and output channels to the environment) In the next step, we refine the structure. This means that subcomponents are identified, the tasks are allocated, and the channels between the subcomponents are specified. (architecture view) The result is called decomposition If necessary, individual components are decomposed further

8 Notation: System View Structure view:System Structure diagrams(SSDs) for components, interfaces, and communication channels to model the structure of the system Behaviour view:State transition diagrams(STDs) for the state-based description of the behaviour of components. Interaction view: Extended event traces(EETs) for the interaction between components Data view: Data type definitions(DTDs) allow to define the types of messages and data elements in a user-friendly, functional style

9 System Structure Diagrams Describe the structure of a system with the aid of components, channels, and ports Components communicate with each other via directed channels Ports and channels are typed in order to determine which kind of data is sent through them. A hierarchical description of the system is obtained by means of decomposing the components (sub-SSDs)

10 SSD: Decomposition A component itself can be regarded as an independent system as well By gradually decomposing a component into subcomponents, the structure of a system can be increasingly refined Each decomposition is represented in a new SSD and is also called a refined view of the system

11 SSD Example: simple component channel Name type port type name Exist decomposition

12 SSD Example: decomposition

13 Extended Event Trace used to provide exemplary descriptions of the interaction of several components, either among each other or with their environment Must be associated with :  a single component To represent a typical input/output sequence of the associated component  a system structure diagram (SSD). represents a typical interaction between the components of the system structure diagram and its environment (only channels, ports, and components should be used in the sequence diagram which exist in the associated system structure diagram)

14 EET(2) vertical axis represent time axis which correspond to components in system structure diagrams (component lifelines) Messages are represented by horizontal arrows between different axis (components) or between the environment The order in which the messages in the sequence diagram are represented from top to bottom indicates the time sequence of the events  Events may also occur simultaneously Explicit time steps are represented by horizontal broken lines. Event separated by time step definitely occur one after the other Loop (indicator) may be annotated to determine the number of the runs

15 EET: Structuring Elements offer possibilities of structuring interaction scenarios hierarchically so-called boxes can be used, in which a set of sub-EETs can be named Since any of the sub-EETs can be chosen as interaction for the period in question, boxes offer the possibility of structuring as well as of introducing behavior variations in EETs

16 EET: Example

17

18 EET: Structuring structuring interaction scenarios Structuring view exist

19 EET: refinement Another option for hierarchical description Analogously to the decomposition in the associated SSD In order to ensure consistency, all inputs/outputs of the super-EET must appear in the redefined view

20 EET: refinement Refinement view exist indicator

21 State Transition Diagrams describe the behaviour of a system or a component in terms of its reactions to inputs from the environment and the resulting outputs to the environment The reactions depend on the current state of the component Association describe as a state control move into another state control Data State is represented by internal parameters and external parameters (ports) of the component

22 Local Variables Each system component may have (any number of) local variables  declared with the respective component in the system structure (SSD)  Only the state transition system associated with the component can access the local variables  have a name and an assigned type

23 Association connect two control states: the source state and the target state.  the source state need not necessarily differ from the target state. can be described more precisely with the following attributes:  Label  Comment Precondition:input:output:postcondition

24 STD: Example inputoutput

25 State Transition Diagrams(STD ) Example Wait in yellow(t>0):::t=(t-1) Label

26 Data Type Definitions AutoFocus used typed languages This applies, fir instance, to every channel name and every port name There are also formulas and patterns and they also have types

27 DTD(2) AutoFocus supports two approaches:  Java: a partial set of the basic types of the java programming language can be used for typing It is not possible to use self-defined types  QuestF: is a functional programming language The basic type of QuestF and the type introduced with the data construct can be used for typing In a project, it is not possible to mix the two approaches

28 DTD: Example Data TrafColor = red | RedYellow | green | yellow;  Set a type TrafColor with four different constants (red, RedYellow, green and yellow) Data PedColor = walk | stop;  A type PedColor with the two constants walk and stop. data Datum = TMJ(tag:Int, monat:Int, jahr:Int);  Constructors may also have parameters.

29 Summary History AutoFocus as notation AutoFocus as tool Features

30 AutoFocus: Tool Project browser Editors Consistency Assurance Simulation Code generation

31 User Interface Consists of  a project browser for the organization of the specification documents of the single project,  one editor for each kind of specification document

32 Project Browser

33 Editor for SSDs

34 New Channel

35 New port

36 Decomposition

37 Decomposition(2)

38 Editor for DTD

39 Editor for EET

40 Editor for STD

41 Consistency Assurance The information describing the system as a whole is spread over several views and layers of abstraction. This is a major source of errors and inconsistencies uses different as well as hierarchically organized views, it is important to ensure that the information spread over the various views is well-defined or "consistent" in a methodological sense

42 The Consistency Notion Grammatical correctness  the syntactic rules for the textual representation and the graph- grammatical rules for the graphical representation are observed in the various views Interface correctness  if one view is hierarchically embedded into another view, the views must have compatible interfaces Definedness  if elements from one view are used in another view, they must be defined in the respective view Type correctness  the type required for using an element must correspond to the element type Completeness: all "essential" views of a project are available Only static consistency

43 The Consistency Notion Several consistency conditions are already integrated The consistency check is started in the project browser The tool then carries out the selected checks and afterwards shows the list of all inconsistencies found, together with the affected views The type correctness of terms can only be verified in DTDs. If transitions are not type correct, however, this may cause errors during simulation as well

44 Result of check

45 Result of check (2)

46 Simulation It is possible to simulate the behavior of any component whose behavior was previously laid down in a STD or which was split up into subcomponents. consists of animations of the SSDs, the STDs, and the EET displays which correspond to the respective run of the system It is absolutely essential to perform a consistency check before the first simulation.

47 Simulation: SimCenter

48 Simulation

49 Simulation: recording

50 Features : Code Generation Validas AG has integrated many add-ons and free features:  C code generation  Java code generator

51 Validas Validation Framework

52 Implementation Was implemented as a Client/Server system with a central document repository and a arbitrary number of editor clients Developers can shared the specification documents The complete tool can be used in common computer platforms because it is implemented in Java

53 Version control and locking concepts Specifications are repeatedly revised to use version control for single document and whole project it is necessary tool support should rule out inconsistencies The tool offer a central repository with version control both documents and projects as well as locking mechanism for documents

54 References http://autofocus.informatik.tu- muenchen.de/index-e.html http://autofocus.informatik.tu- muenchen.de/index-e.html http://www.validas.de/

55 Formal methods Is a science of mathematically describing and reasoning about computer-based systems Help in the reduction of errors introduced into a system Are widely used in software verification


Download ppt "AutoFocus - Case Tool Mela Enrica. Summary History AutoFocus as notation AutoFocus as tool Features."

Similar presentations


Ads by Google