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

MGMT ASAD HO 7 © HY 2006 Lecture 7 A most important stage of the software process is that of Specification. The specification process entails all those activities that relate to the identification and documentation of what the to be constructed system must be and do. In itself, the Specification process has several elements or sub-components. These are: Requirements elicitation Requirements capture Requirements analysis Production of a specification Usecases are central to this process

MGMT ASAD HO 7 © HY 2006 Lecture 7 Requirements Elicitation There are many techniques of Requirements Elicitation. The following are some example techniques: Interviewing Questionnaires Joint sessions Document and process study Prototyping We have already studied this phase

MGMT ASAD HO 7 © HY 2006 Lecture 7 Requirements Capture Once software requirements are elicited, they must be captured and documented in a clear, unambiguous and accessible way. This is called Requirements Capture or Requirements Documentation. There are several popular techniques available: Simple Narrative Enhanced narrative, including: Scenarios and Usecases Pictures, diagrams and cartoons Formal Language

MGMT ASAD HO 7 © HY 2006 Lecture 7 Requirements are captured for several reasons. Amongst these are to: Ensure that our understanding of what is to be done coincides with that of the customer, Have a basis for writing of contracts, Be able to convey to our design and implementation colleagues precisely what needs to be developed, Have a basis for evaluating whether we have completed the project successfully.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Goal Orientation A system is identified in terms of the single goal it is to achieve. A system name is a cognitive handle that allows the identification and communication of a particular coherent and purposeful set of activities. A system name is usually presented in the form of: “A system to do/be/achieve X” Example: A system to generate birth certificates A system to generate reusable components A system to provide a uniform computing platform across government agencies All these may actually refer to the same application software!

MGMT ASAD HO 7 © HY 2006 Lecture 7 Each system name implies a single goal that defines a certain boundary and a specific set of interactions which in turn define the context of the system. If you cannot clearly name a system (identify a label that clearly indicates the goal to be attained), you are not yet ready to proceed with its analysis. The system goal (name) implies a set of interactions between “the system” and the outside world (outside entities or stakeholders) and a sequence of transformations within the system that achieves the purpose or goal implied. The border transcended by these interactions is called the boundary.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Stakeholders: Stakeholders in any system may belong to one of these three categories: Clients: Beneficiaries or victims of the goal, it having been achieved Actors: Those who operate the system Owners: Those with the power to abolish the system. To correctly comprehend or describe a system, as many of its stakeholders as possible must be identified and their interactions with the system noted.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Whilst it is important to identify and consider the impact and interaction of each and every stakeholder/role player with the system and with each other to better understand the system, it is unnecessary to model each in detail. It is the system within the boundary that is to be defined and analyzed not what lies outside. It is therefore permissible to abstract outside entities (stakeholders) into one or a small number of abstract entities or concepts. IMPORTANT NOTE:

MGMT ASAD HO 7 © HY 2006 Lecture 7 parent  child  keyboard  PC Hardware  modem  exchange  modem  PC Hardware  screen  child  parent User  exchange  User UI  exchange  UI Modem  exchange  Modem Consider the case of “getting off-line”. These abstractions (of stakeholders) that play the role of outside entities interacting with the system are called Actors.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Transformations: A Transformations is an element of a sequence of end-to-end activities that may be initiated by an interaction (a call) from the outside world but take place within the system in order to achieve the goal for which the system exists or is to be constructed. Therefore, a set of transformations in a particular order ( a sequence) describe how the system goal is achieved. A transformation can be (often is) in itself considered the goal for a subsystem of the system at a lower level.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Scenarios: We stated earlier that transformations are end-to-end activities that show how a system goal is achieved or is to be achieved. It stands to reason therefore to accept that capturing these end to end activities in the order that they take place determines how a system works. We can do this simply by creating artifacts called Scenarios A scenario is the ordered end-to-end listing of activities that takes place between a system and its actors in order to achieve a goal.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Constructing a scenario: In order to construct a scenario, we first need to identify and express the goal for the system of which the scenario would describe the transformations. This can be in the form of a system name. Having identified the goal, the main action implied by the system name would become the name or the focus of the scenario. We then identify and name all the stakeholders of the system that are significant in achieving the goal at hand. Each stakeholder would lead us to specific activities that may not have been foreseen. For example by identifying a system administrator, we may become aware of the need for system administration activities.

MGMT ASAD HO 7 © HY 2006 Lecture 7 We then capture the end to end activities that would achieve the goal and the order in which they need to be performed, if an order is extant or implied. Otherwise scenarios must be found that imply the sequence we seek. We then identify the initiating stakeholder that starts the scenario, and write down the first line of the scenario in the form of: Stakeholder action verb Example: customer places order or preferably Stakeholder action verb system or system component Example: customer selects place order

MGMT ASAD HO 7 © HY 2006 Lecture 7 The following lines take largely the same format but do not need to necessarily start with a stakeholder. Important A scenario describes an end-to-end set of actions that achieves a goal. No conditional should be present in a given scenario. Scenarios that assume this end-to-end action is completed successfully, are called primary scenarios. Scenarios that assume otherwise are called alternate scenarios.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Example: A scenario for establishing a modem connection 1.Identify and express the goal, state system name: A system to establish a modem connection between two modems. It assumes that there are two modems, each on one side, connected to computing equipment (in this case two personal computers) and that the personal computers are ready and modems are installed and enabled properly and that the communication line is available (subscription exists).

MGMT ASAD HO 7 © HY 2006 Lecture 7 2.In this exchange John and Mary are the two individuals involved who wish to establish a connection using their modems. John initiates the call. 3. John sends “wake” signal to modem 1 Modem 1 connects to line Dial tone begins Modem sends Acknowledge to John John sends number sequence Modem 1 “Acknowledge”s John Modem 1 dials 5 Dial tone ends Modem 1 dials 5 Modem 1dials 5 Modem 1 dials 1 ::::::: Mary’s modem receives call signal Call is routed Ringing tone is heard by John Modem 2 connects to line Modem 2 stops ringing Modems are connected Modem 1 sends data stream Modem 2 sends reply data stream John sends disconnect signal Modem 1 sends disconnect signal Line disconnects John is notified of disconnection Mary is notified of disconnection

MGMT ASAD HO 7 © HY 2006 Lecture 7 Example: Alternate scenario John sends “wake” signal to modem 1 Modem 1 connects to line Dial tone begins Modem sends Acknowledge to John John sends number sequence 5% Modem 1 “Acknowledge”s John Modem 1 dials 5 Dial tone ends Modem 1 dials % Modem 1dials 5 Modem 1 dials 1 ::::::: Recording indicates invalid number John disconnects

MGMT ASAD HO 7 © HY 2006 Lecture 7 Our example scenario indicated what actually happened between the stakeholders through a system. It says nothing about what specifically was asked of the system and what did the system specifically do or asked to be done. Our example scenario was between John and Mary, does it matter if it is between these two or between Gunter and Gretchen? Our example scenario had 28 lines. How many lines should there be in a scenario? Is there a minimum? A maximum? Does it matter? This is where usecases come in

MGMT ASAD HO 7 © HY 2006 Lecture 7 Scenarios Vs Usecases Scenarios are tools of requirements elicitation They are a tool by which we determine as many of the end-to-end activities that are to be part of our system and their alternates. Scenarios are concrete They are depictions of the actual activity between actual stakeholders and stakeholders and the system Scenarios are informal They have a casual format and arbitrary length

MGMT ASAD HO 7 © HY 2006 Lecture 7 Usecases are tools of requirements analysis and specification They are a tool by which we analyze system interactions and what interactions are required and in what order and hierarchy for the goal to be achieved. Usecases are abstract They are depictions of the abstract (except for leaf level usecases) activities between an abstraction of the stakeholders and the system or its components, in terms of lower level transformations. Usecases are formal They have a precise format and specific length.

MGMT ASAD HO 7 © HY 2006 Lecture 7 A system is described in terms of its goal, which implies a boundary, which in turn implies (by exclusion) stakeholders who are outside the system scope but interact with it. As the artifact to be designed is “the system” and not its stakeholders, it is a good idea to concentrate on the system and its interactions with the outside world, which can be conveniently abstracted. There are two levels of interactional abstraction: Abstraction by elimination of intermediate elements Abstraction by categorization

MGMT ASAD HO 7 © HY 2006 Lecture 7 Abstraction by elimination of intermediate elements We have demonstrated this before: parent  child  keyboard  PC Hardware  modem  exchange  modem  PC Hardware  screen  child  parent modem  exchange  modem or child  exchange  child or any other set of two stakeholders Consider the case of “getting off-line”.

MGMT ASAD HO 7 © HY 2006 Lecture 7 It is best to consider the inner-most or the outer-most set and eliminate the rest. This is of course only permissible when the elements in the chain have no direct connection with the system except through their downstream element.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Abstraction by categorization In the case of John and Mary, John was the Caller, Mary was the Callee. Can we generalize the case by considering this more abstract case? When does the abstraction end? A category is usually a sub- category of another? When do we stop? Caller and Callee  User, User  Person, etc. It is customary to be as general as possible without loss of meaning.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Behavioral Abstraction: In addition to interactional abstraction (between stakeholders and systems) we can also have behavioral abstraction (within the system). Behavioral abstraction is the activity of describing the system through a set of abstract behaviors, themselves being described by other sets of behaviors. Behavioral abstraction allows us to concentrate on what is of import at any one time. It helps our brains to understand the situation more clearly and completely without being overwhelmed.

MGMT ASAD HO 7 © HY 2006 Lecture 7 The Miller Number: There is an assertion in psychology that the human brain can best deal with 7±2 chunks of information at any one time or level. Anything below 5 and you are wasting a level as it is not adding adequate detail, Anything above 9 and there is too much detail. We strive – in composing usecases – to work within the Miller limits. Each usecase should have 7±2 lines of transformation.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Transformations: A transformation is a concise abstraction of a behavior. A transformation is also a mapping. It can be depicted as an end-to- end un-conditional path through a set of activities that achieves a certain end. A transformation is formally described in terms of its: Pre-conditions Invariants Variant/Transformation Post-conditions A usecase transformation should be no different.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Pre-conditions: A transformation cannot commence unless all conditions necessary for it to commence have been already successfully conducted. For example a transformation (withdraw money form check account), cannot commence unless there is an account already opened (open_account( ) has succeeded), and there is a cash balance in the positive and equal or exceeding the amount to be withdrawn or there is an overdraft provision, etc. It is important to recognize that every transformation is a potential usecase and every usecase a transformation. So: Each usecase and each transformation within a usecase has a set of pre-conditions that must be satisfied.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Invariants: Each transformation implies a set of activities that have to take place in exactly the same way, every time. This implies that in a given usecase described by a set of transformations, all transformations must always be applied and in exactly the same fashion: no conditionals are allowed. Conditionals imply other cases (similar to alternate scenarios) that we deal with separately.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Post-conditions: Each transformation must when presented its pre-conditions, satisfy the goal for which it exists. Invariants imply that this goal should be unique and its accomplishment or otherwise clearly identifiable. However, this does not imply that each transformation only has a single post-condition as in addition to what must change, there are numerous conditions that must-not. Post-conditions must also ensure that what must not change, has not changed. For practical purposes, we only consider the positive post- conditions for usecases.

MGMT ASAD HO 7 © HY 2006 Lecture 7 Transformation format: A transformation must be formally defined. It must clearly indicate its source, its target and the action to be performed. Therefore a transformation must always be defined as below: Object A requests service S from Object B Example: UI requests service fetch(id) from Record Where UI happens to be the User Interface Object (an external Actor) and Record is an internal object to the system that has capability fetch( ) that requires parameter id.