ISYS1041 Systems Implementation 1
Topic 5: OO BIS Development, Business Scenarios, Use Cases and Use Case Diagrams
Preview
Looking at the modelling of business scenarios in an IS development
After completing this topic you should be able to:
Write use cases (should be able to do that already!!!)
Draw use case diagrams to model the functionality of a BIS
UniMENTOR
The IS development process used in the course is UniMENTOR
It is a subset of the Process Mentor software engineering architecture developed by Object Consulting Pty. Ltd.
Object Consulting is based in
Sydney
Melbourne
Singapore
Has approximately 300 staff
金融案例银行分析论文Started in 1989 and has been a leader in OO in Australia and internationally
Principles of UniMENTOR
OO Concepts
Classes and Objects
Inheritance
Message Sending
Polymorphism
Classes
have data
have behaviour
A class is a template for building objects
Classes are source code
Objects are computer memory
Example classes are:
Integer
String
Vehicle
Student
OO Concepts - Inheritance
Lets one class inherit (use) all the data and behaviour of another class
Examples
CAR inherits from VEHICLE
BANANA inherits from FRUIT
MANAGER inherits from EMPLOYEE
UNDERGRADUATE inherits from STUDENT
CHAIR inherits from FURNITURE
Inheritance is a powerful technique which can vastly reduce the amount of code we need to write!
OO Concepts - Message Sending
Objects communicate by sending messages to each other
Each message represents either a piece of data or a behaviour which that class does
If the object doesn’t know about the message you get an error.
If the object does know about the message, do whatever the message indicates
OO Concepts - Polymorphism
Latin means many forms
means different objects can be sent the same message and handle it in their own particular way
Eliminates in many cases the need for case statements
leads to more flexible systems
Eg. Deposit for Standard, Investment Account, Holiday Account and Overdraft Account which are all Accounts
An advantage of polymorphism
Structured Code
Dim sAccountType As String
‘some other code
If (sAccountType) = “Savings” Then
DepositToSavings()
ElseIf (sAccountType) = “Investment” Then
DepositToInvestment()
ElseIf (sAccountType) = “Term” Then
DepositToTerm();
ElseIf (sAccountType = “Holiday” Then
DepositToHoliday()
Else
sErrorMessage = “Unknown Vehicle”
End If
Object-Oriented Code
Account ActiveAccount;
Our techniques based upon the Unified Modeling Language (UML)
Techniques form the UML we will use include:
Package Diagrams
Class Diagrams
Sequence Diagrams
Collaboration Diagrams
Use Cases
Use Case Diagrams
State Diagrams
System Dictionary
All these are based upon the OO concepts
some other code
ActiveAccount.Deposit()
UML Background
1994 - Grady Booch and Rational hire Jim Rumbaugh away from General Electric
1995 Version 0.8 of the Unified Method released
Late 1995 - Ivar Jacobson joins Rational from Ericssons, become the “Three Amigos”
Jan 1997 - Version 1.0 of the Unified Modeling Language is released
August 1997 - The Object Management Group (CORBA people) select UML to be the standard OO modeling notation
Backed by Microsoft, HP, DEC etc etc.
1998-2003 – UML versions 1.1 to 1.5
2004-5 – UML 2.0 adopted
The UniMENTOR Project Lifecycle
Project Lifecycle Phases
Project Investigation
this phase specifies initial scheduling and costing of the project, feasibility analysis and SSM
System Definition
during this phase requirements are gathered and a high-level design activity is undertaken
Development
this phase is where detailed design, system testing and implementation of the software system occurs
Release
product is released to the users
Process Units
Techniques in UniMENTOR are packaged into what are called process units
Necessary to provide a framework for using the techniques in a practical environment
There are 19 different process units in UniMENTOR
A process unit is represented as follows:
Process Units in UniMENTOR
Concept Exploration
Alternative Evaluation
Programme Development
Business Engineering
Requirements Modelling
User Interface Modelling
System Modelling
Subsystem Modelling
Component Modelling
Prototyping
Installation
Project Management
Software Cost Estimation
Quality Assurance
Software. Engineering Process Construction
Software Configuration Management
Test Management.
System Testing
Acceptance Testing
Definitions of Process Units
Requirements Modelling (RM)
developing the business requirements in terms of business use cases
developing a class model that meets the requirements of the use cases
System Modelling (SM)
developing the high level architecture and design of the system
system use cases are defined here
major input are the business scenarios from requirements modelling
Process Units, Activities and Tasks
Phases, Process Units, Activities and Tasks
Each phase has a number of process units
Each process unit has a number of activities
Each activity has a number of tasks
Structure is descriptive, not prescriptive
Example
System Definition Phase
Requirements Modelling Process Unit
Scenario Analysis Activity
Identify Actors Task
System Definition Phase
This phase will be what we will be looking at in ISYS1041
Objectives
Obtain a clear, validated and verified statement of user requirements (both functional and non-functional) for the software system to be developed such that change-control can be effectively measured against it during the Development phase
Obtain an understanding of the technical and system-wide requirements, as well as the issues relating to, and the structure of a solution
Obtain a clear understanding of the resources required to implement the solution such that the Project Plan can be refined
Stages and Process Units in System Definition
Development Phase
Objectives
Prepare a detailed schedule to implement the required functionality defined for the phase through one or more iterations of the Component Development stage
Produce and/or update detailed design documents for components of the system
Produce the source code
Produce the builds for the target platforms
Produce the quality assurance outputs required to verify the source and build against the requirements of this Development phase
Test the solution to ensure it is correct with respect to the specification
Stages and Process Units in the Development Phase
Requirements Modelling in UniMentor
In UniMentor, requirements are documented using scenarios
A scenario is a textual description of an interaction within a system
We have two types of scenarios
Business Scenarios - focused on the problem that the business is trying to solve
System Scenarios - focused on the solution provided by a particular system for a business scenario
In general, we aim to have all scenarios understandable by all members of the project team, including user representatives
Requirement Modelling Activities in Uni-SEP
Scenario Analysis (Use Cases)
produce requirements overview
identify actors
identify initial business scenarios
develop graphical scenario diagrams
identify subject areas
document business scenarios
develop domain scenarios
develop domain dictionary
re-factor business scenarios
re-factor the actors
Business Domain Modelling
modelling of the business objects in the domain
we will look at this next week in Topic 6
Operational Analysis
determining enabling technologies
determining standards employed (UniMENTOR documentation and relevant coding standards)
determining the operational parameters
Much of this would come out of our soft systems analysis
Use Cases
A Use Case is a narrative document that describes the sequence of events of an actor using a system to complete a process
Properties of a Use Case
it captures some user-visible function
a use case is a relatively large end-to-end process
it achieves some discrete goal for the user
You need some understanding of the requirements before starting to develop your use cases
Use cases are used to describe business scenarios
High-Level Use Case Example
A Customer arrives at a checkout with items to
purchase. The Cashier records the purchase items
and collects payment. On completion, the
Customer leaves with the items
Components of a Use Case
NAME - start with a verb to emphasise that it is a process
ACTOR - is a role that a user plays in respect to the system. Actors are generally shown when they are the ones who need the use case.
Also need to indicate which actor initiates (starts) the use case
DESCRIPTION - short and abstract
CROSS-REFERENCES – indicate other use cases connected to this use case by <<includes>>, <<extends>> or inheritance
Importance
Primary
System needs it, no point building the system without it
These have to be done to achieve the business goals
Represent major common processes
Secondary
System should have it, but can work without it
These have a measurable impact on the system's business goals
Represent minor or rare processes
Optional
System doesn’t require it, but it would be nice
These would make the user happy, but without explicit justification
processes that may not be implemented in the system depending upon resources
This is determined by the CLIENT!
Technical Difficulty
Measure of how difficult the developers think the use case will be to implement
Usually measured on a 3 point scale
High
Medium
Low
High-level - terse description of the activities without going into details of how activities are performed
Expanded - shows more detail than a high-level one, details the sequence of events in the process
generally done in a conversational style
show alternative courses
shows the initiator of the use case
Real - details concretely the process in terms of its real current design, input and output technologies
Pre-conditions
Things that must be true for the use case to commence
A very common pre-condition is that a user is logged in to the system
Often used to indicate business process relationships between use cases, where the output of one use case is a necessary requirements for another use case to proceed
Use Case: Buy Items with Cash
Actors: Customer (initiator), Cashier
Purpose: Capture a sale and its cash payment
Overview: A Customer arrives at a checkout with items
to purchase. The Cashier records the
purchase items and collects a cash
payment. On completion, the Customer
leaves with the items.
Type: Expanded
Importance: Primary
Cross references: R1.1, R1.2, R1.7
Pre-conditions Cashier logged in
Store open
Expanded Use Case (2)
1. This use case begins when a Customer arrives at the register with items to purchase.
2. The cashier records the identifier from each item. If more than one of the same item, the Cashier can enter the quantity as well.
4.
Cashier indicates completion of item entry.
6. Cashier tells the Customer the total.
Alternative Courses
Line 2: Invalid identifier entered. Indicate error
Line 7: Customer didn’t have enough cash. Cancel sales transaction
Alternative Courses
If a Typical Course of Events has multiple equally likely courses of action
indicate branches in Use case
write a subsection for each branch indicating the typical course of events
have alternatives for each subsection if necessary
Using the actors
Identify the actors related to a system or organisation
For each actor, identify the processes they initiate or participate in
Using events
Identify the external events that a system must respond to
Relate the events to actors and use cases
Examples
Withdraw cash from ATM
Order a product
Enrol for a subject
Check the spelling of a document
Handle a telephone call
Names a single, identifiable, and reasonably atomic behaviour of the system
Describes the flow of events clearly enough for an outsider to easily understand it
Illustrates a set of use cases for a system, the actors and the relationships between actors and use cases.
Each use case diagram is for a particular subject area
In most systems, we will see several actors
Often these actors will have similarities
We use an actor diagram to show these similarities
Actors can have one type of relationship between them called generalisation
As an example, we could decide that our supermarket offers home delivery to pensioners
In many situations we find that use cases are very similar
We need mechanisms to handle these similarities
Three mechanisms in the UML
Generalisation
Includes
Extends
This means that a child use case inherits the behaviour and meaning of the parent use case
The child may add or override the behaviour of the parent
The child may be substituted in any place the parent may appear in the system
Generalisation appears as
Looked at basic OO concepts
Looked at the OO IS development process we are using
Revised use cases
Looked at how we can model the use cases in a system as a use case diagram or diagrams
OO Techniques