Essentials of OVID

1
Essentials of OVID

• Using UML based notation to capture system
  requirements and design.

2
Overview of Socio-cognitive Engineering
Design Concept
Contextual Studies
Design space
Task model
Evaluation
System specification
Theory of Use
General requirements
Implementation
Deployment
3
Use of OVID UML
Design Concept
Contextual Studies
Design space
Task model
Evaluation
System specification
Theory of Use

General requirements

Implementation
Deployment
also used for business process models and
software engineering
4
Why UML?

• CASE tools support UML and can be used to
  facilitate communication within a project team
• design can be partitioned for teams
• control levels and versions
• software design and business process are already
  documented in UML
• can teach other disciplines to use OVID subset
• May use gatekeeper to help others understand

5
Summary of UML used

• Class diagrams
• for users, goals
• for objects and views
• Activity diagrams
• for old tasks and new tasks
• Use cases
• for function specification

6
Summary of UML used

• State models
• for object and view states
• Harel diagram from UML
• state tables added from Schlear and Mellor
• Sequence Diagrams
• for detailed tasks

see http//www.projtech.com/info/smmethod.html
7
Class diagrams (users and goals)
Design Concept
Contextual Studies
Design space
Task model
Evaluation
System specification
Theory of Use
General requirements
Implementation
Deployment
8
Class diagrams (users and goals)

• Describe the stakeholders in the system
• users (roles)
• indirect users
• customers, buyers, managers
• Describe the goals they have
• quantitative goals
• qualitative goals

9
Class diagrams (users)

• Actors represent groups of users
• Subclass hierarchy shows levels of grouping
• Can also show other relationships

10
Class diagrams (users)

• Record attributes of users in the role
• Focus on things that make them different
• Use when recruiting subjects for studies or
  validation

11
Class diagrams (goals)

• Goals are states that users want to reach
• Use class showing goal
• Connect users who have that goal
• Attributes show how to measure the goal

12
Class diagrams (goals)

• Break down goals until all users have different
  goals
• Goals can be quantitative or qualitative
• Defines how it is validated

13
Activity diagrams
Design Concept
Contextual Studies
Design space
Task model
Evaluation
System specification
Theory of Use
General requirements
Implementation
Deployment
14
Activity diagrams

• Capture tasks in detail
• both existing practice and new design
• capture activity, goals reached, decisions made
• Use swimlanes to show how several users and/or
  systems participate in activity
• know who does what and when
• crossing between lanes communication

15
Activity diagrams

• One lane for each participant
• users and system
• Place activities, states and decisions in the
  right lane

16
Use cases
Design Concept
Contextual Studies
Design space
Task model
Evaluation
System specification
Theory of Use
General requirements
Implementation
Deployment
17
Use cases

• Describe the functions the system will enable
• at the end of design space analysis
• Relate each case to the goals it satisfies
• Capture details to aid design priority
• How many users know of this case
• via connections to goals and hence users
• How often this case is used

18
Use cases

• Define functions that you will include in the
  design
• in CASE tools the use cases can contain other
  diagrams such as activity diagrams
• Show which users will need which functions

19
Class diagrams (objects and views)
Design Concept
Contextual Studies
Design space
Task model
Evaluation
System specification
Theory of Use
General requirements
Implementation
Deployment
20
Class diagrams (objects and views)

• Define the objects the users will know
• name and description lead to metaphor
• attributes
• Describe how the user will see the objects as
  multiple views
• which attributes are seen when
• transition between views

21
Finding objects to model

• Identify the objects - review nouns that are
  found in the task models
• Sort the objects utilizing a simple table
  (optional can do directly into modelling if
  desired)
• Define each object with 1 clause (no jargon) in
  ways users would understand them
• Put objects in model (including definitions,
  attributes and operations) and define
  relationships between objects

Concrete People Forms Users Abstract

Real things you can touch or walk away with
Those who are managed by the system or have
things saved for them
Existing paperwork or other system
Those who operate the system or directly interact
with the system
Anything else

• Hotel
• Room
• Credit card
• Key

• Guest

• Reservation
• Folio

• Guest
• Reservation clerk
• Front Desk clerk
• Night auditor

• Authorization
• Stay
• Dates

22
Class diagram for user objects

• Create classes for each object the users need
• Names and descriptions should be as simple as
  possible
• Add attributes and operations as you design

23
Relationships for objects

• For many-to-many relationships add an object to
  represent the relationship
• An existing form is often the right object for
  this

24
Core hotel model
25
Finding views

• Review most frequent or most commonly used tasks
  (in use cases) first
• Note the objects involved in activities as
  swimlanes are crossed
• Define a view of that object that has the
  necessary information

26
Class diagram for views

• View classes have stereotype of ltltviewgtgt
• Attributes show which parts of objects are used
  for an interaction
• Can connect users to show where they start

27
State models
Design Concept
Contextual Studies
Design space
Task model
Evaluation
System specification
Theory of Use
General requirements
Implementation
Deployment
28
State models

• Show how objects and views change with events in
  the system
• what is the lifecycle of each object
• does the view state match the object
• Harel diagrams for normal events
• State tables for exceptions

29
State model as Harel diagram

• Use state diagrams (Harel Diagrams) to show
  normal processes for an object or a view
• Transition names should correspond to operations
• Convert to state tables to examine all
  combinations of states and transitions

30
State models (state tables)

• Harel diagrams can be transcribed to state tables
• normally gives a sparse table
• empty cells represent events you have not
  designed for
• fill in all empty cells by making design
  decisions
• consider if the user was trying to do that, what
  would they expect to happen?

31
State table
Rows States, Columns Operations
Open Inputs Process valid data Process invalid data Reenter input Check-in Close out
Initial To receiving input
Receiving input To receiving input To confirmed To invalid
Confirmed To final
Invalid To receiving input To final
32
State Table
Rows States, Columns Operations
Open Inputs Process valid data Process invalid data Reenter input Check-in Close out Close out
Initial To receiving input Not available to the user Not available to the user Not available to the user Not available to the user Not available to the user Not available to the user Not available to the user
Receiving input Open is an internal action so not available to the user To receiving input To confirmed To invalid Must be invalid Not allowed Not allowed Not allowed
Confirmed Open is an internal action so not available to the user Not allowed - no changes are allowed once a reservation is confirmed Not allowed - no changes are allowed once a reservation is confirmed Not allowed - no changes are allowed once a reservation is confirmed Not allowed - no changes are allowed once a reservation is confirmed To final To final Not allowed
Invalid Open is an internal action so not available to the user Not allowed Not allowed Not allowed To receiving input Not allowed Not allowed To final
33
Sequence diagrams
Design Concept
Contextual Studies
Design space
Task model
Evaluation
System specification
Theory of Use
General requirements
Implementation
Deployment
34
Sequence diagrams

• Alternative to activity diagrams
• expressed as messages or methods
• normally only needed for fine grain design such
  as when relating to complex state models
• no decisions/branching available

35
Realising design

• Models considered by
• graphic design
• software design
• Class diagrams (objects) lead to data design
• Class, activity and sequence diagrams with state
  models lead to program design
• Class (views) and activity diagrams with state
  models lead to window/web page/dialog designs

36
Sequence diagram

• To read these diagrams Read down a column to
  determine the order of activities performed by
  the entity (an actor, object or view)

37
Models As Input To Presentation View Design
38
Objects in many views
39
Objects retain identity
40
Same objects, two tasks
Making a reservation
Checking in
41
Views math sequences

• The state diagrams clarify the interaction
  information that was left to interpretation in
  the Abstract View
• Knowing which steps are supported by an object
  completes the information needed to plan its view
  in the composition

42
Paper prototype
43
Paper prototype
44
Paper prototype
45
Medium fidelity prototype
46
Medium fidelity prototype
47
Medium fidelity prototype
48
Medium fidelity prototype
49
Medium fidelity prototype
50
Flow between views
51
Another realisation
52
Presentation model
53
Resources

• OMG UML resources page
• http//www.omg.org/uml/
• Rational UML resources page
• http//www.rational.com/uml/index.jsp
• OVID book
• Designing for the User with OVID Bridging User
  Interface Design and Software Engineering by Dave
  Roberts, Dick Berry, Scott Isensee, John Mullaly
• Published by Macmillan Technical Publishing 1998,
  187 pages ISBN 1578701015
• Ease of Use web site and OVID section
• http//www.ibm.com/easy
• http//www.ibm.com/ibm/easy/eou_ext.nsf/Publish/58
  9