CONCEPTUAL DESIGN: PURPOSE, ACTORS, FEATURES, AND UML USE CASES

CONCEPTUAL DESIGN: PURPOSE, ACTORS, FEATURES, AND UML USE CASES

Information Systems Purpose • The overriding purpose of any information system is to support the mission of the enterprise • Every information system has a [specific] purpose or mission • No matter how trivial the purpose may seem, do not skip documenting it

Information System Purpose Examples • A Convenience Store: The purpose of the information system is "To help each cashier work more effectively during checkout, to keep good records of each sale, and to support more efficient store operations." • A Warehouse: The purpose of the information system is "To improve warehouse profitability by helping team members put away and pick items more efficiently…by keeping more accurate inventory counts, and by increasing fill rate."

Information Systems Purpose Guidelines Purpose Statements should be: • Kept short – 25 words or less if possible • Proactive in form • Supportive the mission of the enterprise • Broad in scope, yet specific to the problem • Void of technology jargon

Actors Actor definitions: • An abstraction for entities outside a system, subsystem, or class that interact directly with the system. An actor participates in a use case or coherent set of use cases to accomplish an overall purpose. [UML] • A coherent set of roles that users of use cases play when interacting with the use cases. [Booch, Rumbaugh and Jacobson] • Roles people or other information systems play when interacting through a use case with this information system. [Norman]

Actors • Actors are not part of the system—they represent anyone or anything [another system] that must interact with the system • Actors input to and/or receive output from the information system • Actors are often identified via conversations with subject domain [matter] experts

Actor Examples • Customer • Student • Employee • Faculty • Member • Credit Card Validation System Mary Tom Jack Dino

Features • A prominent or significant functional, behavioral or descriptive part of an information system • Broad in scope; apply to whole system • Narrow in scope; apply to one part of the system • An end-to-end (start-to-finish) significant process of the information system • Synonymous with the UML’s Use Case • Granularity is arbitrary

Feature Examples(note the “start-to-finish” characteristic) • Course Registration or • Add a course • Drop a course • Check seat availability • Membership Maintenance or • Add a member’s information • Change a member’s information • Delete a membership • Print/Display membership information

page 1 of 3 Types of Information System Features A feature is a tangible, measurable, desired outcome that an information system could produce. Log InformationConduct Business Analyze results Interact with other systems • (“needed information”) • Business Problem • Reference Data (Master, • Foundational data) • Business Problem • Transaction Data • Business Problem Results • Business Problem Integration

page 2 of 3 Features Examples • Log Information: • Maintain membership information • Maintain product information • Maintain vendor (supplier) information • Maintain employee security information • etc… • Conduct Business: • Rental transaction • Sales transaction • Order products transaction • etc... (Maintain = adding, changing, deleting, & viewing)

page 3 of 3 Features Examples • Analyze results: • Produce Periodic Sales Report s by: • Product • Employee • Fastest-moving rentals • Fastest-moving sales • Produce “On-Order” Report sorted by Vendor • Produce “On-Order” Report sorted by Product • etc… • Interact with other systems: • Validation of Credit Cards • etc...

Actor #1 Feature #1 Feature #2 Feature #3 Actor #2 Feature #1 Feature #2 Feature #3 Actor #3 Feature #1 Feature #2 Feature #3 Actor #4 Feature #1 Feature #2 Feature #3 Documenting Actors and Features

Use Case Diagram Example #1

Use Case Diagram Example #2

Use cases and Use-Case Diagrams • A use case is a description of a specific usage of the system • Use cases define the functionality requirements (features) of the system • A use case usually represents a user-recognizable “end-to-end” process rather than an individual step or activity within a process (e.g., “rent a video” instead of “pay for video rental”) • A use-case diagram shows any number of external actors and their connection to the use cases that the system provides • A use-case diagram generally includes a number of use cases • Use cases are often identified by: • identifying actors who input to or receive something from the system • external events that the system must respond to (e.g., “purchase an airline ticket”, “check-out a video”)

Components of the Use Case • Actor(stick figure) • a role that a user (e.g., people, other systems, and objects) plays with respect to the system • Use case(oval) • significant “end-to-end” process • Stereotypes(<< >>) [guillemets] - provides the capability to extend the basic modeling elements of the UML to create new elements • <<Include>>- a similar chunk of behavior across more than one use case (artifact reuse) • <<Extend>>- indicates that one use case is similar to another but it does more • Scenario (documented via an interaction diagram) • documented step-by-step instantiation of an actual use case Valuation

Type Brief Description Notation Figure 4.4 UML Use Case Diagram Notation (adapted from The Unified Modeling Language Reference Manual, p. 65)

base use case extension use case Place Order <<extend>> Request Catalog <<include>> <<include>> <<include>> parent use case Supply Customer Data Order Product Arrange Payment child use case inclusion use cases Pay Cash Arrange Credit Figure 4.5 UML Use Case Relationships (adapted from The Unified Modeling Language Reference Manual, p. 66)

TIME QUITTING

CONCEPTUAL DESIGN: PURPOSE, ACTORS, FEATURES, AND UML USE CASES