1. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Service Oriented Development using Base Structure Grammar

2. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

3. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

4. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

5. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

6. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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

7. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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

8. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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

9. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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( ) from Object A Object D requests service M( ) from Object E Objects in red are external objects

10. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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 B Object A requests service R( ) from Object C Object B requests service P( ) from Object D terminated Object C requests service M( ) from Object E terminated Object C requests service N( ) from Object A Object A requests service …………………….

11. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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 B Object A requests service R( ) from Object C Object B requests service P( ) from Object D terminated Object C requests service M( ) from Object E terminated Object C requests service N( ) from Object A Object A requests service ……………………. Object X requests service W( ) from Object F terminated

12. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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 Line Line req. ser. Sound_ring_tone from Modem 1 Line req. ser. Ring_phone from Modem 2 Modem 1 req. ser. Rec._ringing_tone from caller Modem 2 req. ser. Rec.phone_ringing from callee Modem 2 req. ser. Picked_up from Line Line req. ser. Stop_ring_tone from Modem 1 Line req. ser. Stop_ringing from Modem 2 Cont’d next column Line req. ser. Connect from Modem 1 Line req. ser. Connect from Modem 2 Modem 1 req. ser. Connected from Caller Modem 2 req. ser. Connected from Callee Caller req. ser. Disconnect from Modem 1 Modem 1 req. ser. Disconnect_signal from Line Line req. ser. Break_connect from Modem 1 Line req. ser. Break_connect from Modem 2 Line req. ser. Sound_dial_tone from Modem 1 Line req. ser. Sound_dial_tone from Modem 2 Modem 1 req. ser. Dial_tone from Caller Modem 2 req. ser. Dial_tone from Callee Example, incomplete

13. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

14. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

15. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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)

16. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

17. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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

18. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

19. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

20. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

21. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

22. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Using abstraction to deal with combinatorial complexity: The method to employ is very similar to the method of equivalence partitioning 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.

23. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

24. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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?

25. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

26. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

27. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

28. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

29. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

30. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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 Line Line req. ser. Sound_ring_tone from Modem 1 Line req. ser. Ring_phone from Modem 2 Modem 1 req. ser. Rec._ringing_tone from caller Modem 2 req. ser. Rec.phone_ringing from callee Modem 2 req. ser. Picked_up from Line Line req. ser. Stop_ring_tone from Modem 1 Line req. ser. Stop_ringing from Modem 2 Cont’d next column Line req. ser. Connect from Modem 1 Line req. ser. Connect from Modem 2 Modem 1 req. ser. Connected from Caller Modem 2 req. ser. Connected from Callee Caller req. ser. Disconnect from Modem 1 Modem 1 req. ser. Disconnect_signal from Line Line req. ser. Break_connect from Modem 1 Line req. ser. Break_connect from Modem 2 Line req. ser. Sound_dial_tone from Modem 1 Line req. ser. Sound_dial_tone from Modem 2 Modem 1 req. ser. Dial_tone from Caller Modem 2 req. ser. Dial_tone from Callee Remember this?

31. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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 Line Line req. ser. Sound_ring_tone from Modem 1 Line req. ser. Ring_phone from Modem 2 Modem 1 req. ser. Rec._ringing_tone from caller Modem 2 req. ser. Rec.phone_ringing from callee Modem 2 req. ser. Picked_up from Line Line req. ser. Stop_ring_tone from Modem 1 Line req. ser. Stop_ringing from Modem 2 Cont’d next column Line req. ser. Connect from Modem 1 Line req. ser. Connect from Modem 2 Modem 1 req. ser. Connected from Caller Modem 2 req. ser. Connected from Callee Caller req. ser. Disconnect from Modem 1 Modem 1 req. ser. Disconnect_signal from Line Line req. ser. Break_connect from Modem 1 Line req. ser. Break_connect from Modem 2 Line req. ser. Sound_dial_tone from Modem 1 Line req. ser. Sound_dial_tone from Modem 2 Modem 1 req. ser. Dial_tone from Caller Modem 2 req. ser. Dial_tone from Callee We can first abstract by elimination of intermediate elements.

32. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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 from Line Line req. ser. Receive_ call_ signal from Modem2 Modem 2 req. ser. Routed from Line Line req. ser. Sound_ring_tone from Modem 1 Line req. ser. Ring_phone from Modem 2 Modem 2 req. ser. Picked_up from Line Line req. ser. Stop_ring_tone from Modem 1 Line req. ser. Stop_ringing from Modem 2 Line req. ser. Connect from Modem 1 Line req. ser. Connect from Modem 2 Modem 1 req. ser. Disconnect_signal from Line Line req. ser. Break_connect from Modem 1 Line req. ser. Break_connect from Modem 2 Line req. ser. Sound_dial_tone from Modem 1 Line req. ser. Sound_dial_tone from Modem 2 We now add thread information

33. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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 from Line 0 Line req. ser. Receive_ call_ signal from Modem 2 0 Modem 2 req. ser. Routed from Line 00 Line req. ser. Sound_ring_tone from Modem 1T 01 Line req. ser. Ring_phone from Modem 2 01 Modem 2 req. ser. Picked_up from Line 011 Line req. ser. Stop_ring_tone from Modem 1 012 Line req. ser. Stop_ringing from Modem 2T 013 Line req. ser. Connect from Modem 1 014 Line req. ser. Connect from Modem 2 013 Modem 1 req. ser. Disconnect_signal from Line 013 Line req. ser. Break_connect from Modem 1 014 Line req. ser. Break_connect from Modem 2 013 Line req. ser. Sound_dial_tone from Modem 1T 014 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.

34. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi We are still dealing with 17 lines of transformations, significantly larger than the 7±2 suggested by the Miller’s rule. 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 from Line 0 Line req. ser. Receive_ call_ signal from TTD2 0 TTD2 req. ser. Routed from Line 00 Line req. ser. Sound_ring_tone from TTD1T 01 Line req. ser. Ring_phone from TTD2 01 TTD2 req. ser. Picked_up from Line 011 Line req. ser. Stop_ring_tone from TTD1T 012 Line req. ser. Stop_ringing from TTD2T 013 Line req. ser. Connect from TTD1 014 Line req. ser. Connect from TTD2 013 TTD1 req. ser. Disconnect_signal from Line 013 Line req. ser. Break_connect from TTD1 014 Line req. ser. Break_connect from TTD2 013 Line req. ser. Sound_dial_tone from TTD1T 014 Line req. ser. Sound_dial_tone from TTD2T

35. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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 1T 1Exchange req. ser. Reset( ) from TTD2T 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 1T 1NSLX req. ser. Dial( ) from Dial_register 1Dial_register req. ser. Receive_call( ) from FSLX 1FSLX req. ser. Routed( ) from Call_registerT 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 NSLX 0FSLX req. ser. Ring( ) from TTD2 1NSLX req. ser. Sound_ring_tone( ) from TTD 1T 0TTD 2 req. ser. Picked_up( ) from CR 00CR req. ser. Req_stop_ring_tone( ) from NSLX 01CR req. ser. Req_stop_ring( ) from FSLX 00NSLX req. ser. Stop_ring_tone( ) from TTD 1T 01FSLX req. ser. Stop_ring( ) from TTD 2T NSLX: Near-side Local Exchange FSLX: Far-side Local Exchange

36. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi A usecase is a non-normal case of another: This situation has been adequately discussed.

37. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

38. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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: 1.There is a usecase at a higher level with a set of transformations that reads something like: ::::::::: 3. UI requests service log_in( ) from Guardian 4. Guardian……… :::::::::::: 7. UI requests service place_order(ord_details) from Shipment ::::::::::::

39. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 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.

40. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Using usecases to extract an object-oriented models: Extracting the dynamic model A well-formed usecase can tell us which object requested what service from which other object and in what sequence. It also captures (although deficiently) whether there was simultaneity and parallel threads. This is almost all the information we need to extract an object-oriented dynamic model of the situation. This could be in the form of sequence diagrams, collaboration diagrams or later, state diagrams.

41. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Extracting sequence diagrams: If we have a well-formed usecase, construction of a sequence diagram becomes rather trivial. A sequence diagram depicts the order of the exchange of messages between the various objects involved in order to achieve a certain goal. Usecases do exactly the same and well-formed ones contain all the necessary information to extract a sequence diagram.

42. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi The left-hand side object of any one line of usecase is a client object, the right- hand side one the server for a particular message request, which is the transformation of that given line. Therefore all objects needed for the sequence diagram all simply the left-hand side and the right-hand side words of the transformation set. A message (an arrow in a sequence diagram) is from a client to a server, thus it is from the life-line of a left-hand side object to the one of the right-hand side. The label on it is the name of the transformation. The order of the arrows are the order of the lines. Use rules of progression to figure out multi-threading.

43. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi TTD1:TTD Exchange:Connectio n Attempt_conn( ) TTD2:TTD Attemp_disconn( ) Reset( ) Disconnect( ) Establish_call( ) Use Case: Telephony Communication Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: TTD 1 req. ser. Attempt_connection( ) from Exchange Exchange req. ser. Establish_call( ) from TTD 2 TTD 1 req. ser. Attempt_disconnect( ) from Exchange Exchange req. ser. Disconnect( ) from TTD 1 Exchange req. ser. Reset( ) from TTD2

44. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Use Case: Attempt_connection Actors: TTD 1 Initiating Actor: TTD 1 Events: TTD 1 req. ser. Connect( ) from NSLX NSLX req. ser. Sound_dial_tone( ) from TTD 1 NSLX req. ser. Dial( ) from Dial_register Dial_register req. ser. Receive_call( ) from FSLX FSLX req. ser. Routed( ) from Dial_register TTD1:TTD NSLX:LX Connect( ) Receive_call( ) Routed( ) Dial( ) Dial- Register:Reg FSLX:LX Sound_dial_tone( )

45. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Extracting collaboration diagrams: Collaboration diagrams contain the same essential information as sequence diagrams. A collaboration diagram also depicts the order of the exchange of messages between the various objects involved in order to achieve a certain goal. As we know usecases also do exactly the same and well-formed ones contain all the necessary information to extract a sequence diagram.

46. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi TTD2:TTD Exchange:Connection 1- Attemp_connect( ) 3- Attempt_disconnect( ) 4a- Disconnect( ) 2- Establish_call ( ) 4b- Reset( ) TTD1:TTD Use Case: Telephony Communication Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: TTD 1 req. ser. Attempt_connection( ) from Exchange Exchange req. ser. Establish_call( ) from TTD 2 TTD 1 req. ser. Attempt_disconnect( ) from Exchange Exchange req. ser. Disconnect( ) from TTD 1 Exchange req. ser. Reset( ) from TTD2

47. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi TTD1:TTD NSLX:LX 1. Connect( ) 3. Receive_call( ) 4. Routed( ) 2b. Dial( ) Dial- Register:Reg FSLX:LX 2a. Sound_dial_tone( ) Use Case: Attempt_connection Actors: TTD 1 Initiating Actor: TTD 1 Events: TTD 1 req. ser. Connect( ) from NSLX NSLX req. ser. Sound_dial_tone( ) from TTD 1 NSLX req. ser. Dial( ) from Dial_register Dial_register req. ser. Receive_call( ) from FSLX FSLX req. ser. Routed( ) from Call_register

48. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi A well-formed usecase can tell us which object requested what service from which other object. Therefore a full set of well-formed and related usecases would contain in it all the objects that exchange messages in the system and the messages that they exchange. As each object must belong to a class, all classes required in the system are therefore identifiable. As each message is a request for an object to perform an operation, all the operations are also known. The hierarchy of usecases and their subordinate ones also indicate a structural hierarchy. This almost all the information we need to extract an object-oriented static model. This could be in the form of a class diagram.

49. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Extracting a class diagram: Each object (right-hand side or left-hand side) must belong to a class. So each object named in a usecase implies a class. Each class has a number of operations that it has to perform. So the operations indicated by the usecase define the object as its class.

50. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Each line of usecase at level n implies a pair of objects (therefore also classes) and an operation on the server class. This latter class may be (usually is) a complex class (an entire system or sub-system) and the operation implied with respect to it a complex operation. This latter operation may however be now taken as the subject for a new usecase, implying that the server object at level n is now our “system”, with (for the moment) one goal; the operation it has to perform. Now we can start the system analysis effort over again, this time at the lower n+1 level of granularity. This implies new lower level (component) objects (and therefore

51. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi classes which would logically compose the higher level object at level n. So there is a compositional relationship between the levels of a usecase and objects with which we aught to deal.

52. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Use Case: Telephony Communication Actors: TTD 1, TTD 2 Initiating Actor: TTD 1 Events: TTD 1 req. ser. Attempt_connection( ) from Exchange Exchange req. ser. Establish_call( ) from TTD 2 TTD 1 req. ser. Attempt_disconnect( ) from Exchange Exchange req. ser. Disconnect( ) from TTD 1 Exchange req. ser. Reset( ) from TTD2 Attempt_connect( ) Attempt_disconnect( ) Connection

53. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Dial( ) Dial_register Use Case: Attempt_connection Actors: TTD 1 Initiating Actor: TTD 1 Events: TTD 1 req. ser. Connect( ) from NSLX NSLX req. ser. Sound_dial_tone( ) from TTD 1 NSLX req. ser. Dial( ) from Dial_register Dial_register req. ser. Receive_call( ) from FSLX FSLX req. ser. Routed( ) from Call_register Routed( ) Call_Register Connect( ) Receive_call( ) Local_exchange

54. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Dial( ) Dial_register Routed( ) Call_Register Connect( ) Receive_call( ) Local_exchange Attempt_connect( ) Attempt_disconnect( ) Connection

55. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Dial( ) Dial_register Routed( ) Call_register Connect( ) Receive_call( ) Local_exchange Attempt_connect( ) Attempt_disconnect( ) Connection Register

56. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Reviewing usecases: Like any other artifact in software engineering, usecases may also be reviewed. We review usecases from the perspective of: 1.Well-formedness 2.Completeness 3.Fit We shall discuss these one at a time.

57. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Well-formedness: A usecase is well-formed if it follows the one initiation, five progression and two termination rules. There may be other rules added to these to cater for architectural concerns, but that is of no concern to us here. Should extra rules exist, then following these is also a requirement of well-formedness. Additionally, to be well-formed, a usecase must be documented in one of the accepted usecase documentation formats. The one provided herein is recommended.

58. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Completeness: There are two aspects to completeness; Essential completeness, and Structural completeness We must ensure both.

59. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Essential completeness is ensured when there is covered traceability to at least the functional requirements set. This means that all stated and implied functional requirements must be covered by usecases. Structural completeness is ensured when all named transformations have been either expanded into lower level usecases or into procedural flow (if at leaf level). We also need to ensure that all necessary non-normal course usecases have been considered and documented. It is also necessary to ensure that there is a relevant entry in each cell of the usecase template and that those containing no entries are explicitly mentioned to be blank.

60. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Fit: Here we must ensure that everyone is happy with our usecase set. We must check for understandability, logical consistency, and necessity (that there is nothing we don’t need). You need to review with all stakeholders: Review with Clients Review with Actors, and Review with Owners. Remember that there are several systems with which you are concerned here, not just a software specification.

61. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi A system to achieve goal X (the software specification) A system to develop system to do X A system to system administer the system that achieves X A system to deliver value for money A system to shine and stay employed or be promoted

62. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Who should be present at the review? Project chief architect Project manager Chief analyst – usecase developer(s) Project Owner or representative Chief developer/programmer End user representatives

63. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Usecases and project schedule/Work Breakdown Structure (WBS): We had mentioned earlier that a usecase may be prioritized. Once we have a priority value for each of our usecases, we can utilize this information to create a project schedule. The process is very simple, we rank the usecases according to their priority and their level, we then start with the highest priority/level usecase and work our way down until we run out of time or money. This is how it works:

64. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 1.All usecases receive a priority number. A priority number is a weighted index based on : 1. Impact on software Architecture 2. Importance to business or system 3. Importance to the development (provides lots of insight) 4. Complexity 5. Risk if excluded We can then score each usecase on an ordinal scale (1-5) and then sum up the scores. Thus a usecase may have a maximum priority number of 25.

65. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi 2. Each usecase also has a level number. A level number corresponds with the level of the hierarchy of usecases and its subordinates. The top level usecase is at level 1, all its subordinates are at level 2, etc. 3.No non-normal course usecase may have a priority number higher than or equal to the normal course. Of course different non-normal course may have different priorities. 4a.Rank usecases in order of priority but with higher level usecases of the same priority first. OR 4b.Rank usecases in order of level numbers but with higher priority usecases of the same level first.

66. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Using usecases as a basis for V+V: Usecases may be utilized in validation and verification of systems. It is however imperative to recognize that usecases are essentially specification tools and NOT a means of requirements elicitation; that role is filled by scenarios. Usecases therefore are tools to validate design and not programs. Despite their popular utility as test script, they are inappropriate for that purpose. This does not mean however that we cannot extract test scripts from usecases with a little effort.

67. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Using usecases to validate design: A usecase may be the guiding document for conducting a Class-Responsibility- Collaboration (CRC) game. CRC can highlight design faults and deviations of the design from the intended specification. Using usecases to extract test-scripts: The essence here is to extract an end-to-end non-abstracted sequence of events that describes a purposeful interaction with the system. Thus a usecase could yield many test-scripts. Equivalence partitioning is the technique to be used here.

68. SoD via BSG S oftware E ngineering M anagement Software Engineering Management - © 2010 Houman Younessi Equivalence Partitioning: This is where each input condition is partitioned into sets of valid and invalid classes called equivalence classes. These are in turn used to generate test cases by selecting representative values of valid and invalid elements from each class. In this approach one can reasonably assume but not be certain that a test of a representative value of each class is equivalent to a test of any other value. That is, if one test case in a class detects an error, all other test cases in the class would be expected to do the same. Conversely, if a test case did not detect an error, we would expect that no other test case in the class would find an error.