Sequence of transformations and usecase BSG (Base Structural Grammar)

1. Sequence of transformations and usecase BSG (Base Structural Grammar) Rule of initiation: A usecase at any one level must start with an external object (external to the system scope), or an object representing an external object. That is, the first (left-hand side) object on the first line of a usecase must be an external object to that usecase. UI requests service fetch(id) from Record UI is an external object.

2. Very important note: An object that is external to one context may be deemed internal to another even within a single usecase. This makes sense as each transformation line of a usecase is to be deemed as a system of an object (on the left-hand side) requesting a service from another object (on the right-hand side) which at the time is deemed to be THE system. On the following line the order of request is usually reversed, that is the object that was on the right-hand side is now the left-hand side (requester) object on the succeeding line. See next rule; rule of progression 1.

3. UI requests service fetch(id) from Record Record requests service Ack_valid( ) from UI On the first line UI is the external object and the Record or the system that contains Record is the system of concern (Record is the internal object), On the second line Record is the external object requesting a service from a UI system. In other words, if we were to design a Records system, fetch(id) would be a part of it but Ack_valid( ) is not. When designing a UI system, the ability to acknowledge if a record displayed is valid (Ack-valid ( ) ) is part of the system.

4. Rule of progression 1: The right-hand side object on the first line of a usecase must be an internal object (the “system” object or an object that is a component of the system) in our present context. UI requests service fetch(id) from Record Record is a component of the system being designed.

5. Rule of progression 2: Given a non-simultaneous (single-thread) situation, if the right-hand side object on line n is an internal object, the left-hand side object on line n+1 must be the same object UI requests service fetch(id) from Record Record requests service Ack_valid( ) from UI

6. Rule of progression 3: Given a simultaneous (multi-thread) situation, if the right-hand side object on line n is an internal object, the left-hand side objects on the relevant multiple succeeding lines (each signifying a thread) must be the same object. UI requests service fetch(id) from Record Record requests service validate( ) from UI Record requests service lock(id) from Database-manager

7. Rule of progression 4: Given a simultaneous (multi-thread) situation, each thread must follow rule of progression 2. If an order is implied in the threads, the order must be followed in an interleaved fashion. Object A requests service S( ) from Object B Object B requests service T1( ) from Object A Object B requests service T2( ) from Object C Object A requests service T11( ) from Object D Object C requests service T12( ) from Object E

8. Rule of progression 5: If the right-hand side object of a usecase line is an external object (actor), then the left-hand side object of the next line on that thread must also be an external object (not necessarily the same object). Object A requests service S( ) from Object B Object B requests service T( ) fromObject A Object Drequests service M( ) from Object E Objects in red are external objects

9. Rule of termination 1: Any thread may cease upon task completion. The last thread(s) may only terminate when the goal is met. Object A requests service S( ) from Object BObject A requests service R( ) from Object C Object B requests service P( ) from Object D terminatedObject C requests service M( ) from Object E terminated Object C requests service N( ) from Object A Object A requests service …………………….

10. Rule of termination 2: All threads must terminate, preferably on an external. That is the right-hand side object of any terminating thread (last line of a thread) should be (but does not have to be) an external object. Object A requests service S( ) from Object BObject A requests service R( ) from Object C Object B requests service P( ) from Object DterminatedObject C requests service M( ) from Object Eterminated Object C requests service N( ) from Object A Object A requests service ……………………. Object X requests service W( ) from Object F terminated

11. Use Case: Communicate via Modem Actors: Caller, Callee Initiating Actor: Caller Events: Caller req. ser. Wake from Modem 1 Modem 1 req. ser. Connect from Line Line req. ser. Sound_ dial_ tone from Modem 1 Modem 1 re. Ser. Acknowledge from Caller Caller req. ser. Accept_ dial_ seq. from Modem 1 Modem 1 req. ser. Dial from Line Line req. ser. Receive_ call_ signal from Modem2 Modem 2 req. ser. Routed from LineLine req. ser. Sound_ring_tone from Modem 1Line req. ser. Ring_phone from Modem 2 Modem 1 req. ser. Rec._ringing_tone from caller Modem 2 req. ser. Rec.phone_ringing from calleeModem 2 req. ser. Picked_up from LineLine req. ser. Stop_ring_tone from Modem 1Line req. ser. Stop_ringing from Modem 2Cont’d next column Example, incomplete Line req. ser. Connect from Modem 1Line req. ser. Connect from Modem 2Modem 1 req. ser. Connected from CallerModem 2 req. ser. Connected from CalleeCaller req. ser. Disconnect from Modem 1Modem 1 req. ser. Disconnect_signal from LineLine req. ser. Break_connect from Modem 1Line req. ser. Break_connect from Modem 2Line req. ser. Sound_dial_tone from Modem 1Line req. ser. Sound_dial_tone from Modem 2Modem 1 req. ser. Dial_tone from CallerModem 2 req. ser. Dial_tone from Callee

12. Structural format of a usecase There are rules for writing usecase transformations, there is also a structure for keeping the important elements of a usecase together. There are many of these structural formats. Here we show two: A minimal one that represents the necessary minimum requirements A formal one that is comprehensive, detailed and in accordance to systems theory requirements.

13. A minimum format requirement: Usecase name: Usually the name of the system or sub-system the goal of which is the reason why the usecase exists. Actors: A list of external objects that exchanges messages with the system Initiating actor: The external entity that starts the usecase (the object on the left-hand side of the first line of transformation sequence Transformations: The sequence of events that need to take place for the goal to be achieved.

14. A Formal Template: Usecase name: Usually the name of the system or sub-system the goal of which is the reason why the usecase exists. Actors: A list of external objects that exchanges messages with the system Initiating actor: The external entity that starts the usecase (the object on the left-hand side of the first line of transformation sequence Type: Normal course or non-normal course (to be discussed later) Priority: How important is this usecase (discussed later)

15. A Formal Template: Pre-conditions: A set of conditions that must be true before the usecase can be initiated and the name of the usecase or usecases that operationalize them. Transformations: List of end-to-end events that need to take place for the goal to be achieved. Post-conditions: Given the pre-conditions, a set of conditions that must exist when the usecase ends. Extension points: A list of points in the usecase where non- normal courses extend out.

16. Subordinates: List of usecases that are subordinate to the present usecase, that is, usecases that expend an individual transformation of this usecase. Architectural Other – non-functional – requirements that Requirements: might impact the usecase Status: Where in the project are we with this usecase Features in: The list of usecase diagrams – if any – in which this usecase is depicted Sequence diagram: The name or address of the document that contains the sequence diagram relating to this usecase

17. Separation of concerns: One of the central principles of software engineering is the idea of separation of concerns. Simply put, it states that: If at all possible deal with different concerns, separately. This implies that different use courses should be captured and dealt with separately. There are two types of usecase courses: Normal Course: The course of action for which the system exists or persists; the “solution” we want of the system. Non-normal Course: A capability the system should possess but was not created for that purpose.

18. Example: A vending machine is there to dispense food, drink or cancer in exchange for an exact price. The “normal course” usecase for a vending machine is therefore the one dealing with receiving the exact change and dispensing the item selected. A non-normal course would be when the system asks for more money, not enough having been inserted in the first place, or making and giving change.

19. Identifying non-normal courses: The process of identifying non-normal courses is very simple. Begin with the normal course which has been identified and its pre-conditions and transformations have been enumerated. Start with the pre-conditions. For each pre-condition ask if an alternate valid course would be possible if this pre-condition was not met. If so, name and develop it into a usecase. Then proceed to the transformations section. Start with the first line. Ask if there could be any other way to proceed at that line, than the one suggested by the normal course. Each one is a potential non-normal usecase.

20. Combinatorial explosion: Beware of the menace of the combinatorial explosion. Theoretically, there can be an infinite number of possibilities (non-normal courses) for each line of transformation. In a solution bound to a Von Neumann machine the number of possibilities are however always finite. This is not necessarily good news. Ten trillion possibilities is still unmanageable. How do we battle this menace? We use the two concepts of abstraction and contextualization.

21. Using abstraction to deal with combinatorial complexity: The method to employ is very similar to the method of equivalencepartitioning in testing. In fact in a way it is the same method. The idea is to select not every possibility individually as a separate course but to select a sample case with the assumption that it can stand as the equivalent for an entire class of potential courses. For example we might consider one course of “more change needed” irrespective of whether the change needed is 3 cents or $1.05. No longer do we need to consider each individual needed change value. Of course this is a big assumption. Not all equivalences we assume are truly equivalent.

22. Using contextualization to deal with combinatorial complexity: Given infinite time and resources, we can consider and implement every non-normal course. This is clearly impossible as for even a very simple system the time and resource requirements to do so would be astronomical. Like any other area of engineering, we therefore must compromise. The software engineer – may be in collaboration with the other stakeholders – should (must) decide on which non-normal courses to consider and which to ignore. A judgment must be made based on the impact the exclusion of a particular course might have on the system.

23. Usecases and software quality characteristics: What would be the impact of excluding a normal course usecase or having an imperfect or incomplete one? What quality characteristic would suffer as a consequence? What would be the impact of excluding a non-normal course usecase or having an imperfect or incomplete one? What quality characteristic would suffer as a consequence?

24. One can therefore measure functionality and reliability of a system through the use of usecases. We shall not deal with this issue here in detail. Important note: Identifying a non-normal course and developing one are two different things. I may recognize that a vending machine may need to deal with foreign currency but not do anything about it.

25. A transformation set, a usecase and a usecase folder: These terms are often confused, sometimes even by experts. A transformation set is the “transformation/behavior” section of a usecase. Admittedly, it is the most important part of a usecase but it is not THE usecase. A usecase is the transformation set PLUS the other sections as described in the previous pages A usecase folder is the set of all usecases that relate to each other at one level. For example a normal course and all its developed non-normal courses. Subordinate usecases have their own folders.

26. Relating usecases: The foregoing implies that usecases have a variety of relationships. A usecase may be a component of another, A usecase may be a subordinate of another, or A usecase may be a non-normal course of another We shall deal with these cases one at a time.

27. A usecase is a component of another: Often we find ourselves repeating the same sequence of activities over and over. If these activities define a concrete objective to be achieved, then they represent a bona fide usecase. We may develop this usecase once and use it several times in different – larger – contexts. In this sense this usecase is a component of the other. Note: An arbitrary set of steps may not be simply bunched together and named a usecase to then be used as a component. For a component usecase to be a component usecase, it first has to be a usecase and that means supporting a concrete goal.

28. A usecase is a subordinate of another: Each usecase has a set of transformations; one per line. Each transformation in itself implies a goal – a subordinate goal – to be achieved. The usecase describing the achieving of this subordinate goal is a subordinate usecase to the one above it.

29. Use Case: Communicate via Modem Actors: Caller, Callee Initiating Actor: Caller Events: Caller req. ser. Wake from Modem 1 Modem 1 req. ser. Connect from Line Line req. ser. Sound_ dial_ tone from Modem 1 Modem 1 re. Ser. Acknowledge from Caller Caller req. ser. Accept_ dial_ seq. from Modem 1 Modem 1 req. ser. Dial from Line Line req. ser. Receive_ call_ signal from Modem2 Modem 2 req. ser. Routed from LineLine req. ser. Sound_ring_tone from Modem 1Line req. ser. Ring_phone from Modem 2 Modem 1 req. ser. Rec._ringing_tone from caller Modem 2 req. ser. Rec.phone_ringing from calleeModem 2 req. ser. Picked_up from LineLine req. ser. Stop_ring_tone from Modem 1Line req. ser. Stop_ringing from Modem 2Cont’d next column Remember this? Line req. ser. Connect from Modem 1Line req. ser. Connect from Modem 2Modem 1 req. ser. Connected from CallerModem 2 req. ser. Connected from CalleeCaller req. ser. Disconnect from Modem 1Modem 1 req. ser. Disconnect_signal from LineLine req. ser. Break_connect from Modem 1Line req. ser. Break_connect from Modem 2Line req. ser. Sound_dial_tone from Modem 1Line req. ser. Sound_dial_tone from Modem 2Modem 1 req. ser. Dial_tone from CallerModem 2 req. ser. Dial_tone from Callee

30. We can first abstract by elimination of intermediate elements. Use Case: Communicate via Modem Actors: Caller, Callee Initiating Actor: Caller Events: Caller req. ser. Wake from Modem 1 Modem 1 req. ser. Connect from Line Line req. ser. Sound_ dial_ tone from Modem 1 Modem 1 re. Ser. Acknowledge from Caller Caller req. ser. Accept_ dial_ seq. from Modem 1 Modem 1 req. ser. Dial fromLine Line req. ser. Receive_ call_ signal from Modem2 Modem 2 req. ser. Routed from LineLine req. ser. Sound_ring_tone from Modem 1Line req. ser. Ring_phone from Modem 2 Modem 1 req. ser. Rec._ringing_tone from caller Modem 2 req. ser. Rec.phone_ringing from calleeModem 2 req. ser. Picked_up from LineLine req. ser. Stop_ring_tone from Modem 1Line req. ser. Stop_ringing from Modem 2Cont’d next column Line req. ser. Connect from Modem 1Line req. ser. Connect from Modem 2Modem 1 req. ser. Connected from CallerModem 2 req. ser. Connected from CalleeCaller req. ser. Disconnect from Modem 1Modem 1 req. ser. Disconnect_signal from LineLine req. ser. Break_connect from Modem 1Line req. ser. Break_connect from Modem 2Line req. ser. Sound_dial_tone from Modem 1Line req. ser. Sound_dial_tone from Modem 2Modem 1 req. ser. Dial_tone from CallerModem 2 req. ser. Dial_tone from Callee

31. Use Case: Communicate via Modem Actors: Modem 1, Modem 2 Initiating Actor: Modem 1 Events: Modem 1 req. ser. Connect from Line Line req. ser. Sound_ dial_ tone from Modem 1 Modem 1 req. ser. Dial fromLine Line req. ser. Receive_ call_ signal from Modem2 Modem 2 req. ser. Routed from LineLine req. ser. Sound_ring_tone from Modem 1Line req. ser. Ring_phone from Modem 2 Modem 2 req. ser. Picked_up from LineLine req. ser. Stop_ring_tone from Modem 1Line req. ser. Stop_ringing from Modem 2Line req. ser. Connect from Modem 1Line req. ser. Connect from Modem 2Modem 1 req. ser. Disconnect_signal from LineLine req. ser. Break_connect from Modem 1Line req. ser. Break_connect from Modem 2Line req. ser. Sound_dial_tone from Modem 1Line req. ser. Sound_dial_tone from Modem 2 We now add thread information

32. Use Case: Communicate via Modem Actors: Modem 1, Modem 2 Initiating Actor: Modem 1 Events: 0 Modem 1 req. ser. Connect from Line 0 Line req. ser. Sound_ dial_ tone from Modem 1 0 Modem 1 req. ser. Dial fromLine 0 Line req. ser. Receive_ call_ signal from Modem 2 0 Modem 2 req. ser. Routed from Line00 Line req. ser. Sound_ring_tone from Modem 1T01 Line req. ser. Ring_phone from Modem 2 01 Modem 2 req. ser. Picked_up from Line011 Line req. ser. Stop_ring_tone from Modem 1012 Line req. ser. Stop_ringing from Modem 2T013 Line req. ser. Connect from Modem 1014 Line req. ser. Connect from Modem 2013 Modem 1 req. ser. Disconnect_signal from Line013 Line req. ser. Break_connect from Modem 1014 Line req. ser. Break_connect from Modem 2013 Line req. ser. Sound_dial_tone from Modem 1T014 Line req. ser. Sound_dial_tone from Modem 2T We can now apply abstraction of categorization. We recognize that a modem is a type of Telephony Terminus Device (TTD). Others such as a hand-set or a fax machine also exist. This would allow for devices other than a modem to be included.

33. Use Case: Communicate via Modem Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: 0 TTD1 req. ser. Connect from Line 0 Line req. ser. Sound_ dial_ tone from TTD 1 0 TTD1 req. ser. Dial fromLine 0 Line req. ser. Receive_ call_ signal from TTD2 0 TTD2 req. ser. Routed from Line00 Line req. ser. Sound_ring_tone from TTD1T01 Line req. ser. Ring_phone from TTD2 01 TTD2 req. ser. Picked_up from Line011 Line req. ser. Stop_ring_tone from TTD1T012 Line req. ser. Stop_ringing from TTD2T013 Line req. ser. Connect from TTD1014 Line req. ser. Connect from TTD2013 TTD1 req. ser. Disconnect_signal from Line013 Line req. ser. Break_connect from TTD1014 Line req. ser. Break_connect from TTD2013 Line req. ser. Sound_dial_tone from TTD1T014 Line req. ser. Sound_dial_tone from TTD2T We are still dealing with 17 lines of transformations, significantly larger than the 7±2 suggested by the Miller’s rule.

34. Use Case: Telephony Communication Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Attempt_connection( ) from Exchange 0Exchange req. ser. Establish_call( ) from TTD 2 0TTD 1 req. ser. Attempt_disconnect( ) from Exchange 0Exchange req. ser. Disconnect( ) from TTD 1T1Exchange req. ser. Reset( ) from TTD2T Use Case: Establish_call Actors: Call_register(CR), FSLX, NSLX Initiating Actor: Call_register Events: 0CR req. ser. Req_ring( ) from FSLX 1CR req. ser. Req_ring_tone( ) from NSLX0FSLX req. ser. Ring( ) from TTD21NSLX req. ser. Sound_ring_tone( ) from TTD 1T0TTD 2 req. ser. Picked_up( ) from CR00CR req. ser. Req_stop_ring_tone( ) from NSLX01CR req. ser. Req_stop_ring( ) from FSLX00NSLX req. ser. Stop_ring_tone( ) from TTD 1T01FSLX req. ser. Stop_ring( ) from TTD 2T Use Case: Attempt_connection Actors: TTD 1 Initiating Actor: TTD 1 Events: 0TTD 1 req. ser. Connect( ) from NSLX 0NSLX req. ser. Sound_dial_tone( ) from TTD 1T1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Call_registerT NSLX: Near-side Local Exchange FSLX: Far-side Local Exchange

35. A usecase is a non-normal case of another: This situation has been adequately discussed.

36. Pre-conditions and pre-condition operationalization Usecases also have pre-conditions defined for them. Each usecase is in final analysis nothing but a transformation; and transformations have pre-conditions. But what is a pre-condition? A pre-condition is simply a transformation that has to have occurred before the current transformation (this usecase) can occur. If so, then each pre-condition, being a transformation, implies a usecase. So each precondition must be related or recognized as an existing usecase, or if none exists, then it has to be defined. This is called pre-condition operationalization. All pre-conditions must be operationalized.

37. Example: • Usecase place_order has a pre-condition user_is_logged_in. This implies that there has to be a usecase log_in somewhere in the system. Two possibilities exist: • There is a usecase at a higher level with a set of transformations that reads something like: :::::::::3. UI requests service log_in( ) from Guardian4. Guardian……… ::::::::::::7. UI requests service place_order(ord_details) from Shipment ::::::::::::

38. Example: • or: • 2. This is the top level, in which case we either recognize a need for even a higher level or recognize the need for a usecase called log_in.