Essentials of OVID
53
Essentials of OVID • Using UML based notation to capture system requirements and design.
description
Essentials of OVID. Using UML based notation to capture system requirements and design. Overview of Socio-cognitive Engineering. Design Concept. Contextual Studies. Design space. Task model. Evaluation. System specification. Theory of Use. General requirements. Deployment. - PowerPoint PPT Presentation
Transcript of Essentials of OVID
Essentials of OVID
•Using UML based notation to capture system requirements
and design.
Overview of Socio-cognitive Engineering
Generalrequirements
Theory of Use
Design Concept
ContextualStudies
Task model
Design space
System specification
ImplementationDeployment
Evaluation
Use of OVID UML
Generalrequirements
Theory of Use
Design Concept
ContextualStudies
Task model
Design space
System specification
ImplementationDeployment
Evaluation
* also used for business process models and software engineering
* *
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
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
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
Class diagrams (users and goals)
Generalrequirements
Theory of Use
Design Concept
ContextualStudies
Task model
Design space
System specification
ImplementationDeployment
Evaluation
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
Class diagrams (users)
•Actors represent groups of users
•Subclass hierarchy shows levels of grouping
•Can also show other relationships
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
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
Class diagrams (goals)
•Break down goals until all users have different goals
•Goals can be quantitative or qualitative
Defines how it is validated
Activity diagrams
Generalrequirements
Theory of Use
Design Concept
ContextualStudies
Task model
Design space
System specification
ImplementationDeployment
Evaluation
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
Activity diagrams
•One lane for each participant
users and system
•Place activities, states and decisions in the right lane
Use cases
Generalrequirements
Theory of Use
Design Concept
ContextualStudies
Task model
Design space
System specification
ImplementationDeployment
Evaluation
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
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
Class diagrams (objects and views)
Generalrequirements
Theory of Use
Design Concept
ContextualStudies
Task model
Design space
System specification
ImplementationDeployment
Evaluation
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
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
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
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
Core hotel model
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
Class diagram for views
•View classes have stereotype of <<view>>
•Attributes show which parts of objects are used for an interaction
•Can connect users to show where they start
State models
Generalrequirements
Theory of Use
Design Concept
ContextualStudies
Task model
Design space
System specification
ImplementationDeployment
Evaluation
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
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
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?’
State table
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]
Rows: States, Columns: Operations
State Table
Open Inputs Process [valid data]
Process [invalid data]
Reenter input
Check-in Close out
[Initial] To receiving input
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
Confirmed
Not allowed - no changes are allowed once a reservation is confirmed
To [final] Not allowed
Invalid Not allowed To receiving input
Not allowed
To [final]
Rows: States, Columns: Operations
Sequence diagrams
Generalrequirements
Theory of Use
Design Concept
ContextualStudies
Task model
Design space
System specification
ImplementationDeployment
Evaluation
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
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
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)
Models As Input To Presentation View Design
Objects in many views
Objects retain identity
Same objects, two tasksMaking a reservation
Checking in
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
Paper prototype
Paper prototype
Paper prototype
Medium fidelity prototype
Medium fidelity prototype
Medium fidelity prototype
Medium fidelity prototype
Medium fidelity prototype
Flow between views
Another realisation
Presentation model
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/589
