Embed Size (px)
Citation preview
MGMT 6170- ASAD
- 1 -HO 7
© HY 2006
Lecture 7
Advanced Systems
Analysis and DesignFall 2006
Convener:
Houman Younessi
1-860-548-7880
MGMT 6170- ASAD
- 2 -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 6170- ASAD
- 3 -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 6170- ASAD
- 4 -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 6170- ASAD
- 5 -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 6170- ASAD
- 6 -HO 7
© HY 2006
Lecture 7
Goal OrientationA 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 6170- ASAD
- 7 -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 6170- ASAD
- 8 -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 6170- ASAD
- 9 -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 6170- ASAD
- 10 -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 6170- ASAD
- 11 -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 6170- ASAD
- 12 -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 6170- ASAD
- 13 -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 6170- ASAD
- 14 -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 6170- ASAD
- 15 -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 6170- ASAD
- 16 -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 6170- ASAD
- 17 -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 555-1212 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 6170- ASAD
- 18 -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%5-1212 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 6170- ASAD
- 19 -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 6170- ASAD
- 20 -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 6170- ASAD
- 21 -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 6170- ASAD
- 22 -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 6170- ASAD
- 23 -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 modemor
child exchange childor any other set of two stakeholders
Consider the case of “getting off-line”.
MGMT 6170- ASAD
- 24 -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 6170- ASAD
- 25 -HO 7
© HY 2006
Lecture 7
Abstraction by categorizationIn 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 6170- ASAD
- 26 -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 6170- ASAD
- 27 -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 6170- ASAD
- 28 -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 6170- ASAD
- 29 -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 6170- ASAD
- 30 -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 6170- ASAD
- 31 -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 6170- ASAD
- 32 -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.
