1. By: David Harel & Eran Grey Presenter: Elizabeth Antony CISC 836

3.  Models for the development of Object Oriented System should be:  Behaviorally expressive  Well structured  And intuitive  Semantics should be rigorously defined

4.  Semantics not well defined => produce fully executability and automatic code synthesis impossible  Statecharts must capture not only the state of the object as a precondition to service requests, but also the dynamics of the object’s internal behavior in responding to those requests and in maintaining relationships with other objects.

5. Focuses on developing an integrated set of diagrammatic languages for object modelling, built around Statecharts. Language set includes : Object Model Diagrams StateCharts

6.  Statecharts extend statemachines or state diagrams with three elements namely, hierarchy, concurrency and communications  Complex systems such as multicomputer real time systems, communication protocols and digital control units Source: [1]

7.  Each car  Cruise control  Engine  Max speed till it is within 80 yards from another car  Each Platform  Single car  Car within 100 yards from the terminal  platform and  entrance segments allocated  Car departing terminal  after being parked for 90 secs  Exit segment allocated  Turns off the destination indicator

8. One diagram/system Classes Structural relationships unidirectional bidirectional partof Relationship Name or role its Car can refer to a set of its terminals it stopsAt

9. Passenger->itsCar->stopsAt Set of all terminals that the car Carrying the passenger stopsAt System->itsTerminal[1:6] Is the object model diagram concerned with the static aspects only? System refers to an explicit composite object that encloses the entire model

10.  Initialisation:  What object instances are created at the start and how the attributes and relationships with other objects are set up.  Dynamics over time:  Dynamics concerns the way models behave while running.  Triggers like events, operations change the model status

11. Composite structures Associationsinitialisation scripts

12.  Setting up relation ships and defining how instances collaborate  Unambiguous  Ambiguous but bounded  unworkable Unambiguous Unworkable

13. for (int car = 0; car < 6; car++) { System -> itsCar[2*car] = new Car(System -> itsTerminal[car]); System -> itsCar[2*car+1] = new Car(System -> itsTerminal[car]) }

14.  An extension to statemachines and statediagrams  Used to model complex systems  Describe how objects communicate and collaborate and how they carry out their internal behavior  It must also reflect issues such as inheritance.

15.  Object Communication and Collaboration:  Objects generate events (asynchronous)  Invoke operation on an other object (synchronous) Obj B Obj A ObjC Queue Server - > gen(( ( )) gen( ( )) // events that are generated within and limited to the present state chart

16.  Event delegation  If server A is a composite object Who responds to the event e addressed to A ? Composite object endowed with forwarding spec  delegate(e,B)  delegate(e,B,C,…)  broadcast(e) Delegation continues down the tree of composites

17.  -> ( )  Method call within the called object  ( )

18.  Statecharts can be  Full State hierarchy Multilevel orthogonal Components History connectors and Broadcast communication used to describe “modal”  `Partial statecharts Only to specify pre and post conditions of operations Discard concurrent states and broadcast mechanism

19.  Reactions of the form  Trigger[condition]/action-list  Reactions can be adorned on the transition arrow or within a state’s reaction spec  A trigger – either an event expression or an operation request  Action – sequences of event generation expressions, operation invocations, and C++ statements

20.  in(s)  test if the current statechart configuration includes the state s  tm(ev,n)  occurs t time units after event ev; the clock is reset to 0 upon each occurrence of event ev

21.  Creating and deleting instances  = new ( )  delete(object)  Adding and removing components from a composite instance  = add ()  Remove ( )  Ex., stopsAt - > add(term)  Car is now scheduled to stop at the term also

22.  Actions for maintaining association relationships  Adding an object to the other end of a relationship  - > add( )  - > remove( )

23.  Entrance to the statechart’s top level state is the initialisation entrance for any newly created instance of the object.  A reaction attached to the top level default arrow serves as an intialisation script for instances of that class.

28. Establishing relationship between statecharts of a parent class A and its inherited subclass B: Base the two statecharts on the same underlying state/transition topology. Modify states by : decomposing a basic state by Or (substates) or by And (into orthogonal components) Modify the conditions and change the action-list by deleting some actions and adding new ones.

29.  At the time the paper was written (1996),  Event delegation was not implemented.  This paper does not talk about concurrency  Inheritance  Rhapsody tool was not fully developed.  I-Logix released Rhapsody in 1996  Now it is one of the products of IBM Rational Software Unit.

30.  http://homepage.cs.uiowa.edu/~fleck/181content/sta techarts.pdf http://homepage.cs.uiowa.edu/~fleck/181content/sta techarts.pdf  Harel, D.; Gery, E., "Executable object modeling with statecharts," Computer, vol.30, no.7, pp.31,42, Jul 1997  Statecharts: a visual formalism for complex systems by David Harel, Department of Applied Mathematics, The Weizmann Institute of Science, Rehovot, Israel,1987 David Harel

31. Thank you.