MGMT ASAD HO 8 © HY 2006 Lecture 8 A dvanced S ystems A nalysis and D esign Fall 2006 Convener: Houman Younessi

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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

MGMT ASAD HO 8 © HY 2006 Lecture 8 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

MGMT ASAD HO 8 © HY 2006 Lecture 8 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

MGMT ASAD HO 8 © HY 2006 Lecture 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( ) from Object A Object D requests service M( ) from Object E Objects in red are external objects

MGMT ASAD HO 8 © HY 2006 Lecture 8 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 …………………….

MGMT ASAD HO 8 © HY 2006 Lecture 8 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

MGMT ASAD HO 8 © HY 2006 Lecture 8 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

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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)

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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?

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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?

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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

MGMT ASAD HO 8 © HY 2006 Lecture 8 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 Line req. ser. Stop_ringing from Modem 2T 013 Line req. ser. Connect from Modem Line req. ser. Connect from Modem Modem 1 req. ser. Disconnect_signal from Line 013 Line req. ser. Break_connect from Modem Line req. ser. Break_connect from Modem 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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

MGMT ASAD HO 8 © HY 2006 Lecture 8 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

MGMT ASAD HO 8 © HY 2006 Lecture 8 A usecase is a non-normal case of another: This situation has been adequately discussed.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.

MGMT ASAD HO 8 © HY 2006 Lecture 8 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 ::::::::::::

MGMT ASAD HO 8 © HY 2006 Lecture 8 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.