Business Systems Analysis with UML

Modelling the Zeitgeist Club

Owen Johnson

Information Systems Programme Manager

Leeds University, School of Computing

owenj@comp.leeds.ac.uk

Objectives

By the end of session you will be able to: Understand some of the guiding principles behind

business systems analysis Appreciate the value of modelling Identify a range of modelling tools and techniques Describe how these modelling tools and

techniques can be combined to conduct business systems analysis.

Develop information systems requirements for the Zeitgeist Club

OO Analysis and Design

5. Create Prototype Evaluate against real-world

CandidateDesign

Solution 1

CandidateDesign

Solution 3

CandidateDesign

Solution 2

3. Technical DesignGenerate “candidate”

design solutions

4. ChooseA business benefits

vs. cost/ risk trade-off

CandidateDesign

Solution 2

Modelling and Systems Design

Real-world problem domain

LogicalModel

1. AnalysisStudy and

understand the current solution to develop a “logical”

model

New LogicalModel

2. Process Re-DesignRadical rethink or best practice

Outline

Some Theory and Principles Modelling Zeitgeist Conclusions

Some Theory and Principles

General Systems Theory Systems have Inputs, perform Processes and produce Outputs. They include

some element of Control which uses Feedback. Anything with these elements can be regarded as a system. Systems can be very simple (e.g. a thermostat controlling heating) or highly

complex (e.g. human systems of government).Some key features of General Systems Theory:

1. The components of a system work together towards a collective goal2. Systems do not operate in complete isolation

They are contained within an environmentThe scope of the system is defined by its boundaryThe boundary marks the interface between a system and its

environment 3. Systems can be complex and made up of sub-systems4. Systems have emergent properties – more than the sum of their parts5. Subsystems can be treated as systems

Their environment includes the other sub-systems that they interface with

Sub-systems have emergent properties

Sub-Systems and Emergence

Sub-systemA1

Sub-systemA2

Emergent Properties of A

Keyis a part of

System A is more than the sum of Subsystems A1 and A2

System A

Body Mind

Life, decision making,

interactionHuman

Example – a complex system

Sub-Systems and Emergence

Keyis a part of

Sub-systemA1

Sub-systemA2

Emergent Properties of ASystem A

Sub-systemA2a

Sub-systemA2b

Emergent Properties of A2

Emergent Properties of A2b

Sub-Systems and Emergence

Keyis a part of

Competitor:Venue

Zeitgeist: Venue

GrowthSophisticated customer base

Information sensitiveEntertainment:Industry

Catering: Department

Zeitgeist IS: Information System

Loyal customersFalling attendance

Warring department managers

SecurityPerformance

Usability

Modelling Perspectives

The System

to be

Studied

OUTSIDE view INSIDE view

HIGH-LEVEL view LOW-LEVEL view

REQUIREMENTS view DYNAMIC view LOGICAL view PHYSICAL view

Modelling Z-Club

Z-ClubBusiness Context OUTSIDE…

REQUIREMENTS view

HIGH-LEVEL…

KeyActor – independent, autonomous, a person, organisation or other system that isoutside the system boundary but that interacts with it.

Z-ClubBusiness Use Case OUTSIDE…

REQUIREMENTS view

HIGH-LEVEL…

Key

Actor

Use Case – a “case of using” the system. A class of (set of) interactions between actor and the system that results in a positive outcome (measurable value) when complete. Typically represents a business process or system requirement.

Z-ClubBusiness Process

HIGH-LEVEL…

DYNAMIC view

KeyAn activity. An action, or set of actions that are performed as part of a process. It may represent a process in it’s own right.

Transition. A line to indicate the next activity in the sequence.

Z-ClubBusiness Process (Swimlanes)

HIGH-LEVEL…

DYNAMIC view

Key

An activity.

Transition.

Swimlane. A boundary between two areas responsible for different activities.

OUTSIDE viewINSIDE view

Z-ClubBusiness Object Model

HIGH-LEVEL…

KeyA business worker. A role performed by people within the business

A business entity. An important object that plays a key role in understanding and modelling the business.

INSIDE…

LOGICAL view

Z-ClubBusiness Service Use Cases OUTSIDE,

REQUIREMENTS view

Key

Actor

Use Case – a “case of using” the system. Each use case must independently have value to the actor.

Z-ClubService Delivery Process INSIDE …

DYNAMIC view

Key

An activity.

Transition.

Swimlane.

Z-ClubRadical Process Redesign DYNAMIC view

Example: Problem 5. Customers must book and pay in person at reception. This entails a visit to the venue which is in a seedy part of town renown for car crime and poor parking.

Q. How can technology change the entire process?

Key

An activity.

Transition.

Swimlane.

Z-ClubBest Practice Process Redesign1. There is little information on what events are taking place or

when.Process: (Customer) Learn about EventsBest Practice: Self-service information via WebBest Practice: Send targeted information based on customer profile2. The receptionists are surly and unhelpful.Process: (Customer) <<Get Information>>Best Practice: Self-service information via Web…8. Tickets do not specify a seat number; therefore customers

scramble to gain the best seats.Process: (Customer) Make a bookingBest Practice: Booking by seat number 12. Popular drinks often sell out early on. Process: (Customer) Buy drinksBest Practice: Stock management based on demand forecasting

REQUIREMENTS view

Z-ClubSystem Concept Class Model

Key

A class of objects. The class diagram represents the “model” that the system maintains to store what it needs to know about the real-world problem domain.A relationship between objects of different classes, e.g. one (1) to many (*)A part ofA type of (a class can inherit some properties from another class, e.g. a disco is a type of event. All events have date, time, duration, room etc.)

INSIDE…

LOGICAL view

Z-ClubSystem Use Case Diagram REQUIREMENTS view

Key

Actor

Use Case – a “case of using” the system a system requirement.

Z-ClubUse Case Realisations DYNAMIC view

INSIDE …

LOW-LEVEL …

KeyBoundary Object – controls the user interface

Control Object – controls the logic of the use case

A message sent between objects in the system

Z-ClubSoftware Components INSIDE …

HIGH-LEVEL …

PHYSICAL view

Software Component

Package

Dependency

Key

Conclusions

The Nine UML Diagrams

Use Case

Class

Activity

State Sequence

Communication

ObjectComposite

Deployment

UML was developed as a set of complementary diagrams to support multiple views Now a de facto standard in software engineering. The current standard is UML 2.0.

Once you have the big picture you can then zoom in to examine the detail.

Modelling LevelsChoosing Levels of Abstraction

Visual Modelling Levels OUTSIDE View Business

Business Context Business Use Case diagram

System System Context Use Case diagram System Use Case diagram

Sub-Systems More use cases

INSIDE View Business Business Objects – workers/ objects Business Activity Diagrams

System Concept Class Diagram Activity diagram for a use case

Sub Systems Design Level Class diagrams Sequence diagrams for a use case realisation State diagrams for a Class

+ physical design – software components and packages

Current Research Modelling Variety and Best Practice

MIT Process Compass

VBP ModellingGeneralisation Specialisation

Subactivities

Uses

CitizenAccess Information and Services

Access Other Information and

Services

Get Help with Pupil Admission

Get Information on School Make an ApplicationOther Processes

Make Application toLocal Authority

Make Application direct to School

Best Practice: Citizen Portal

Best Practice: Local Authority managed application

Get Information from Local Authority

Get Information from School

Best Practice:School Web site

Objectives

By the end of session you will be able to: Understand some of the guiding principles behind

business systems analysis Appreciate the value of modelling Identify a range of modelling tools and techniques Describe how these modelling tools and

techniques can be combined to conduct business systems analysis.

Develop information systems requirements for the Zeitgeist Club

OO Analysis and Design

What next?

Online School of Computing, Software Engineering www.comp.leeds.ac.uk/se20 The Object Management Group (OMG's) www.uml.org UML Style guidelines from Scott Ambler www.agilemodeling.com/style

Reading Ambler S, Agile Modeling, Wiley, 2002 Ambler S, The Elements of UML 2.0 Style, Cambridge University Press, 2005 Bennett S, Skelton J & Lunn K, Schaum's Outline of UML (2nd edition), McGraw-Hill,

2005

References King S.F. and Johnson O.A. VBP: An Approach to Modelling Process Variety and

Best Practice, Information and Software Technology, forthcoming. Malone, T.W, Crowston, K, Lee, J, Pentland, B, Dellarocas, C, Wyner, G, Quimby, J,

Osborn, C.S, Bernstein, A, Herman, G & Klein, M (1999). ‘Tools for inventing organizations: toward a handbook of organizational processes’. Management Science, 45(3), 425-443.

OO Analysis and Design

Business Systems Analysis with UML

Modelling the Zeitgeist Club

Owen Johnson

Information Systems Programme Manager

Leeds University, School of Computing

owenj@comp.leeds.ac.uk