A dvanced S ystems A nalysis and D esign Fall 2006

MGMT 6170- ASAD

- 1 -HO 8

© HY 2006

Lecture 8

Advanced Systems

Analysis and DesignFall 2006Convener:

Houman Younessi

1-860-548-7880

[email protected]

MGMT 6170- ASAD

- 2 -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 6170- ASAD

- 3 -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 6170- ASAD

- 4 -HO 8

© HY 2006

Lecture 8

UI requests service fetch(id) from RecordRecord 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 6170- ASAD

- 5 -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 6170- ASAD

- 6 -HO 8

© HY 2006

Lecture 8


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 RecordRecord requests service Ack_valid( ) from UI

MGMT 6170- ASAD

- 7 -HO 8

© HY 2006

Lecture 8


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 RecordRecord requests service validate( ) from UIRecord requests service lock(id) from Database-manager

MGMT 6170- ASAD

- 8 -HO 8

© HY 2006

Lecture 8


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 BObject B requests service T1( ) from Object AObject B requests service T2( ) from Object CObject A requests service T11( ) from Object DObject C requests service T12( ) from Object E

MGMT 6170- ASAD

- 9 -HO 8

© HY 2006

Lecture 8


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 BObject B requests service T( ) from Object AObject D requests service M( ) from Object E

Objects in red are external objects

MGMT 6170- ASAD

- 10 -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 BObject A requests service R( ) from Object C Object B requests service P( ) from Object D terminatedObject C requests service M( ) from Object E terminatedObject C requests service N( ) from Object AObject A requests service …………………….

MGMT 6170- ASAD

- 11 -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 BObject A requests service R( ) from Object C Object B requests service P( ) from Object D terminatedObject C requests service M( ) from Object E terminatedObject C requests service N( ) from Object AObject A requests service …………………….Object X requests service W( ) from Object F terminated

MGMT 6170- ASAD

- 12 -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 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

Example, incomplete

MGMT 6170- ASAD

- 13 -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 6170- ASAD

- 14 -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 6170- ASAD

- 15 -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 6170- ASAD

- 16 -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 6170- ASAD

- 17 -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 6170- ASAD

- 18 -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 6170- ASAD

- 19 -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 6170- ASAD

- 20 -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 6170- ASAD

- 21 -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 6170- ASAD

- 22 -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 6170- ASAD

- 23 -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 6170- ASAD

- 24 -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 6170- ASAD

- 25 -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 6170- ASAD

- 26 -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 6170- ASAD

- 27 -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 6170- ASAD

- 28 -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 6170- ASAD

- 29 -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 6170- ASAD

- 30 -HO 8

© HY 2006

Lecture 8




Events:



Remember this?

MGMT 6170- ASAD

- 31 -HO 8

© HY 2006

Lecture 8




Events:



We can first abstract by elimination of intermediate elements.

MGMT 6170- ASAD

- 32 -HO 8

© HY 2006

Lecture 8


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 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

MGMT 6170- ASAD

- 33 -HO 8

© HY 2006

Lecture 8


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 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.

MGMT 6170- ASAD

- 34 -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.


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 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

MGMT 6170- ASAD

- 35 -HO 8

© HY 2006

Lecture 8

Use Case: Telephony Communication

Actors: TTD 1, TTD 2


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 TTD2TUse Case: Attempt_connection

Actors: 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 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

NSLX: Near-side Local Exchange

FSLX: Far-side Local Exchange

MGMT 6170- ASAD

- 36 -HO 8

© HY 2006

Lecture 8

A usecase is a non-normal case of another:

This situation has been adequately discussed.

MGMT 6170- ASAD

- 37 -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 6170- ASAD

- 38 -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 Guardian4. Guardian……… ::::::::::::7. UI requests service place_order(ord_details) from Shipment ::::::::::::

MGMT 6170- ASAD

- 39 -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.

Documents

A dvanced S ystems A nalysis and D esign Fall 2006