AutoFocus - Case Tool

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 Focus

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 name Exist decomposition type port Name type channel

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. EET: Example

18. EET: Structuring Structuring view exist structuring interaction scenarios

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. input output STD: Example

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

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