1 / 53

Essentials of OVID

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.

Download Presentation

Essentials of OVID

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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 Deployment Implementation

  3. Use of OVID UML Design Concept Contextual Studies Design space Task model Evaluation System specification Theory of Use * General requirements * Deployment Implementation * 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 Deployment Implementation

  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 Deployment Implementation

  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 Deployment Implementation

  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 Deployment Implementation

  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 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 <<view>> • 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 Deployment Implementation

  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

  32. State Table Rows: States, Columns: Operations

  33. Sequence diagrams Design Concept Contextual Studies Design space Task model Evaluation System specification Theory of Use General requirements Deployment Implementation

  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

More Related