DSS DESIGN II

1
DSS DESIGN II

• IS3301 Session 7
• Prof. Mark Nissen

2
Agenda

• CSF/ROMC T Review
• Unified Modeling Language
• Use Cases
• Portfolio Management Example
• DSS Exercise
• Summary
• Lots of hidden slides

3
DSS Design Approach Decision-Maker Centric

• Analyze existing process (not BPR)
• DSS design method
• Formalize decision problem
• Decision steps, variables models
• Preliminary KA/CSF analysis
• DM behavioral description
• ROMC T method
• Knowledge/data acquisition
• Rapid, iterative prototyping
• Integrate UML?

4
CSF Analysis

• ID what must go well, how to tell
• 4 elements
• Mission - why project exists (1/DSS)
• Goals - what to accomplish (2-3/mission)
• CSFs - what must go well (2-3/goal)
• Measures - how to tell CSF met (2-3/CSF)
• Use to ID DSS data requirements
• Starting point for behavior ROMC
• Behavior UML?

5
ROMC T Method

• Follow CSF behavioral
• Process independent
• Elements on DSS design palette
• Representations
• Operations
• Memory Aids
• Controls
• Technologies

6
ROMC T Table
Letters (a-z) denote Rs, Os, Ms, Cs Ts
available on DSS designer palette
7
Unified Modeling Language

• UML evolved out of OOAD
• Modeling involves abstraction
• Notation to articulate complex ideas
• Three types of UML models
• Functional - use case diagrams
• Object - class diagrams
• Dynamic - sequence, statechart activity
  diagrams
• UML now has standard semantics
• OMG maintains

8
Use Cases - Overview

• Behavior of system - external view
• From perspective of actors
• Yields visible result from system
• Developed during requirements phase
• Key technique for eliciting requirements
• Discussions with users and sponsors
• Natural language description
• Use terms understandable by users
• Follow template and guidelines

9
Use Cases - Kinds

• Basic
• Handle ordinary scenarios
• Extend
• Handle exceptions
• Used by other use cases
• Uses and Includes
• Handle common functions
• Used by other use cases
• Specialization
• Special cases of basic use case

10
Use Case Example - Basic
Name BoldText Actors Invoked by Author Entry
conditions 1. The Author enters text into the
system. Flow of events 2. The text to be
emboldened is highlighted. 3. The Author selects
the bold function. 4. The system displays
highlighted text in boldface type. Exit conditi
on 5. The Author deselects the bold
function. Special requirements The text
displayed to the Author must change to boldface
type within 10 milliseconds of having the bold
function selected. The boldface type must also
be reflected in printed documents.
WORD PROCESSOR
BoldText
Author
PrintText
11
Use Case Example - Scenarios
Name BoldTextWithHighlight Actors Mark
Author Flow of events 1. The text to be
emboldened is highlighted. 2. The Author selects
the bold function. 3. The system displays text
in boldface type. 4. The Author deselects the
bold function.
Name BoldTextNoHighlight Actors Mark
Author Flow of events 1. The text to be
emboldened is not highlighted. 2. The Author
selects the bold function. 3. The system does
not display text in boldface type. 4. The
system sends a help message to remind the user
to highlight text before before selecting the
bold function.
12
Use Case Example - Extension
Name BoldTextHelpMessage Actors Invoked by
Author Extends BoldText Entry conditions 1.
The text to be emboldened is not highlighted. 2.
The Author selects the bold function. Flow of
events 3. The system does not display text in
boldface type. 4. The system sends a help
message to remind the user to highlight text
before before selecting the bold
function. Exit condition 5. Author acknowledges
message. Special requirements The help
message to the Author must appear near the
control selected to activate the bold function.
The system must also emit an audible sound to
attract attention of Author.
WORD PROCESSOR
BoldText
ltltextendgtgt
Author
PrintText
BoldTextHelpMessage
13
Use Case Examples - Include Specialize
Include Specialize
WORD PROCESSOR
WORD PROCESSOR
BoldText
BoldText
ltltincludegtgt
ltltincludegtgt
Author
PrintText
Author
PrintText
ltltincludegtgt
HelpMessage
HelpMessage
HelpMessageDesktop
HelpMessageWebBrowser
14
Portfolio Management Example

• Ms. Roller manages 1 stock portfolio
• Only SP500 securities
• Monthly inflow of capital to invest
• Monitors portfolio throughout day
• Ms. Roller is DM

15
Portfolio Management Example (Cont)

• CSF analysis
• Mission manage stock portfolio
• Goals accumulate returns with acceptable risk
• CSFs
• Gains must exceed losses
• Returns must compensate for risk
• Measures gains, losses (buy/sell prices),
  volatility, risk-free rate

16
Portfolio Management Example (Cont)

• Intelligence, design, choice behavior
• ID need to trade stocks
• Assess rank alternatives
• Select preferred buy/sells
• Takes action from thresholds
• Portfolio exceeds high --gt sell stocks
• Portfolio falls below low--gt buy stocks
• New capital --gt buy stocks
• Otherwise hold

17
Portfolio Management Example (Cont)

• Identifies evaluates alternatives
• From SP500 index
• Projects returns for current year
• Rank from PE ratios volatility indices
• Other heuristics
• Trade with insiders (3 or more people)
• Trade on news (3 or more stories)
• Trade on gossip (3 or more rumors)
• Selects best stocks to buy sell

18
DSS Exercise

• Develop use cases - portfolio manager
• Focus on intelligence phase of DM
• Diagram key functions on board
• Brief key elements (use template)
• ID other functions needing use cases
• Intelligence, design choice phases
• Integrate with CSF/ROMC T
• Use cases to capture DMer behaviors?
• Before or after CSF ROMC T?

19
Summary

• DMer-centric approach to DSS design
• CSF - things that must go well
• ROMC - process-independent approach
• T - must consider technology in design
• UML
• Modeling notation to manage complexity
• Standard semantics used by many
• Use cases particularly applicable to DSS
• Integrate with CSF/ROMC T

20
Use Case

• Use Case
• a set of sequences of actions that a system
  performs that yield an observable result of value
  to a particular actor
• Actor
• a role that someone or something in the
  environment can play in relation to the business,
  everything that interacts with the system, the
  same someone or something can play different
  roles.

Notation
(Jacobson et al 1995)
21
Use Case Notation
Use case name
Use case name
extends
uses
Actor
Use case name
Actor
Use case name
System Name
22
Use Cases

• Provides a functional description of the system
  and its processes
• places a boundary
• Processes that occur within the application
• Not a class or object, but a process that
  satisfies some user need
• Characteristics
• always initiated (directly or indirectly) by an
  actor
• provides value to an actor
• must be complete

23
Actors

• Person, another software application or hardware
  device
• e.g., bank customer, central bank system and
  printer in an ATM
• Describes the types of users
• Same user can be several actors
• Same actor can be involved in several use cases
• role relationship or communication between
  actors and use cases
• Actors need not be described in detail

24
Actors

• Who / which
• use the main functionality of the system (primary
  actors)?
• need system support for daily tasks?
• Maintain, administrate, operate system
  (secondary)?
• Have interest in the results of the system?
• Hardware devices does the system need to handle?
• Other systems interact

Source Eriksson and Penker, 1997)
25
Users, Actors and Use Cases
26
Use Case Description

• a generic, step-by-step written description of
  the interaction between an actor and a use case
• describes functionality as a whole, including
  possible alternatives, errors and exceptions that
  can occur during the execution of the usecaes
• Provides granularity designers choice
• generic use case descriptions vs. descriptions
  for each interaction
• contains generic steps, not a specific scenario

27
Use Case Description

• Should include
• objective for the use case (use cases are goal
  oriented)
• How the use case is initiated?
• The flow of messages between the actor and the
  use case
• Alternative flow in the use case
• how the use case finishes with a value to the
  actor
• identify what is done in relevance to the user
  and not how things are done inside the system
• scenarios complement (not substitute)
  descriptions

Source Eriksson and Penker, 1997)
28
Finding Use Cases

• For each actor, ask
• Which function does the actor require from the
  system? What does the actor need to do?
• Does the actor need to read, create, destroy,
  modify, or store some kind of information in the
  system?
• Does the actor have to be notified about events
  in the system, or does the actor need to notify
  the system about something? What are the required
  functionalities to achieve this?
• Could the actors work be simplified or made more
  efficient by system functionality?

Source Eriksson and Penker, 1997)
29
Use Cases

• Connected to actors through associations
  (normally one-to-one)
• named for the instance it performs
• e.g., purchase insurance policy, update account
• scenario An instantiation of a use case
• e.g., John Doe contacts the system by fax and
  purchases an insurance for his car

30
Relationships between Use Cases

• Extends
• Uses
• Grouping

31
Extension

• specifies how one use case can be inserted into
  (and thus, extend) another use case
• the original use case captures the complete
  course, avoiding unnecessary complexity
• Some examples of extensions
• modeling optional parts of use cases
• modeling complex, alternative courses that seldom
  occur
• modeling separate sub-courses executed only in
  certain cases

Notation
extends
32
Uses

• similar behavior across use cases is identified
  after the use cases are specified
• The entire use case must be used though
  activities in the used use case can be
  intermixed with the activities in the using use
  case
• requires use case decomposition, and identifying
  commonalities
• abstract and concrete use cases

Notation
uses
33
Extends vs Uses

• how strongly functionally coupled are the use
  cases?
• is the base use case meaningful in its own right?
• how are these use cases found?

34
A Use Case Template

• Use Case name
• Actors roles and systems initiating the use case
• Contact the user contact who provided the
  information / requirements for the use case
• Summary brief description
• Pre-conditions conditions that must be met
  before the use case can be performed
• Post-conditions state of the system after the
  use case is performed
• Exceptions different alternative courses that
  may be taken
• Related Use Cases list of related use cases
• Test Plan based on the use case

( Adapted Rumbaugh, J. JOOP. September 1994)
35
Use Cases

• System Level
• Actors and Use Cases
• Structure Level
• Steps, Sequencing, Iteration, Decisions
• Detailed Level
• Interactions among Classes, Messaging

36
Testing Use Cases

• Validation build the right system
• Use cases presented to and discussed with
  customers
• Verification the system is built right
• to test that the system behaves as specified by
  the users and the use cases behave as described
• Walking the use case
• for both validation and verification
• role play the actors and the system

Source Eriksson and Penker, 1997
37
Use Cases Checklist

• Do all actors communicate with use cases
• are there similarities between actors
• consolidate common roles
• can similarities among activities of use cases be
  handled with uses relationship
• do special cases of a use case exist -gt uses
  relationship
• Are any functional requirements known, but not
  handled by any use case?

Source Eriksson and Penker, 1997)
38
Use Cases Benefits Claimed

• Capturing requirements from users perspective
• User involvement and Understanding
• Good estimation of percentage of requirements
  captured
• Prioritizing for phased delivery according to
  users immediate needs
• Easier user validation
• Test plan generation based on use cases
• Traceability throughout the development cycle

( Source A Use Case FAQ at http//www.unantes.un
iv-nantes.fr/usecase/Contributions/chandra.html )
39
Use Cases to Objects Ideal Object Model

• Jacobsons OOSE proposes three types of classes
• Interface Objects
• classes that interact with things outside the
  application
• handle communication between system and external
  world such as users, MIS, operators, other
  systems etc.
• Entity objects
• keep track of information about major elements of
  the problem
• drawn from ERD concepts
• fundamental object/classes we discover in
  business analysis
• Control objects
• manage processes that transcend specific entity
  objects in the process
• place holders for behavior (methods) that do not
  easily fit into other objects

40
Ideal Object Model

• One Ideal model per use case
• Views objects as entities with behavior
• Advantages
• focus and specificity
• a piece of the problem considered in detail
• Disadvantages
• object classes need to be merged and synchronized
  from ideal diagrams
• control and interface objects are
  implementation oriented - not business objects
  gt wrong focus in the early phases of development

41
Ideal Object Model ..

• Views objects as entities with behavior
• Advantages
• focus and specificity
• a piece of the problem considered in detail
• Disadvantages
• object classes need to be merged and synchronized
  from ideal diagrams
• control and interface objects are
  implementation oriented - not business objects
  gt wrong focus in the early phases of development

42
Entity Objects

• Concrete tangible objects
• examples
• beings person, employee, customer, student,
  citizen
• land buildings store, rental unit, lot,
  street, farm
• equipment car, computer, hammer, grader,
  telephone
• goods book, chair
• Conceptual objects
• intangible, typically defined in terms of other
  classes
• examples
• organizations corporation, church, sports club
• abstractions strategy, plan, blueprint, layout,
  proposal, resume, map
• agreements lease, mortgage, contract, covenant,
  loan guarantee, waranty

43
Entity Objects

• Event state objects
• highly abstract in nature
• interrelated as when one occurs, one or more
  states (condition or situation) switch.
• Examples
• events purchase, sale, negotiation, arrival,
  departure, transaction, deposit, loan, return,
  hire, rental, delivery
• states ownership,employment, birth, status,
  registration, enrollment, assignment,
  termination, immigrant

44
Interface and Control Objects

• Interface Objects
• the least stable of system objects
• have little control over them if created by
  others
• must be isolated - encapsulated
• examples
• other computerized systems, manual systems,
• windows, buttons, scrollbars
• I/O devices
• Control Objects
• typically carry out tasks involving many other
  objects
• examples
• authorization, approval, acceptance

45
CRC Cards (classes, responsibilities,
collaboration)

• Method used to explore and refine analysts
  knowledge of requirements
• Physical or computer supported
• e.g., 3x5 card or SA tool
• Used to represent and describe knowledge about
  classes
• Used to do scenario walk throughs

46
CRC Card
47
CRC Terminology

• Responsibilities
• operations and knowledge that the system
  maintains
• usually a short phrase must include a verb
• e.g., check for amount, verify PIN number
• Collaborators
• other classes needed to perform responsibilities
• each responsibilities may be associated with from
  zero to several collaborators
• the same collaborators can associate with more
  than one responsibility
• Attributes
• describe class
• e.g., authorization PIN_number

48
CRC Session

• Assemble the group
• review requirement statements and use cases
• brainstrom list of classes needed
• review list
• prepare one CRC card for each class. Assign one
  card to each team member
• develop a brief description of each class
• brainstrom responsibilities and collaborators
  for each class
• use the Use Cases to generate specific scenarios
• Walk through several scenarios
• Repeat until the group is satisfied that all
  responsibilities, collaborators and classes are
  identified
• Add any obvious superclasses, subclasses

49
Analysis Process

• Use cases describe processes and actors that
  interact with the system
• Use cases form the basis for scenarios
• Ideal object models identify some major classes
  needed to implement a use case
• CRC cards and scenario walk through develop
  classes, responsibilities and collaborators