se 430 object oriented modeling dennis mumaugh, instructor [email protected] office: cdm, room...

SE 430 SE 430 Object Oriented ModelingObject Oriented Modeling

Dennis Mumaugh, Instructor

[email protected]

Office: CDM, Room 432

Office Hours: Thursday, 4:00 – 5:30

September 24, 2015 SE 430: Lecture 3 1 of 94

AdministriviaAdministrivia Comments and/or Feedback Email – make sure your email address on campus

connection is correct! At least one student has an email that bounces!

For documents to be submitted: be sure any embedded figures are JPEG.

Assignments: You may use the solutions from the previous assignment(s) as a

basis for work on your next assignment Solutions for assignments will be posted the next day (evening) after

they are due.


September 24, 2015 SE 430: Lecture 3

Assignment 2Assignment 2Assignment 2 (Due October 1) Visitor Information Subsystem: Subsystem Use Cases and Use-case

supplemental diagram. Produce the use-case model for the Visitor Information subsystem Deliverables:

Cover page List of all actors, their goals and objectives Identification of use cases Brief descriptions of all use cases – see template Ranking of use cases and basis of ranking Use case diagram (all use cases – together). Detailed use case: (Fully dressed or expanded) description of major

use case Use-Case Supplemental Diagram (system sequence diagram) Glossary

Forms that you may elect to use are on the reading list page.

3 of 94

Term ProjectTerm Project Team Project Preliminary Description discusses the first deliverable.

Due (Due October 22) Preliminary project description – Team Project – Preliminary Descript

ion.doc http://condor.depaul.edu/dmumaugh/se430/assignments/Team Project – Preliminary Description.doc

List of primary use cases Team Project

Due (Due November 19) http://condor.depaul.edu/dmumaugh/se430/assignments/TeamProjec

t.doc See the course documents page

Team assignments are on the course documents page on D2L.


http://condor.depaul.edu/dmumaugh/se430/assignments/Team%20Project%20%E2%80%93%20Preliminary%20Description.doc




http://condor.depaul.edu/dmumaugh/se430/assignments/TeamProject.doc

http://condor.depaul.edu/dmumaugh/se430/assignments/TeamProject.doc

ProjectsProjects Some sort of personal productivity enhancer

Smart phone or iPad application

StarTrek™ Tri-corder Field work support: GPS, pictures, documents, portable science lab

Smart shopper device UPS delivery tracking or OTR Truck dispatch Guide for the blind



ProjectProjectFormat of document Make sure each page is numbered and has name of project

and submission info Use standard “business” report formats Proofread your documents! Check that the submission contains all that is asked for and

in the correct (logical) order. Maximum size of submission is 25 pages or less, preferably

less!

6 of 94

Project HintsProject Hints Get organized ASAP and have some meetings. You have three weeks to

decide on a project, develop requirements, use-cases and write-it up. If possible, have some face to face meetings There are collaboration groups for each team.

Email list for each team Project collaboration site

Group drop outs: Reduce scope of project. Cover less use cases: max (<groupSize>-1, 2) Notify me ASAP if a team member is not working or seems to have

dropped out. How (not) to lose in SE 430

Read the paper and follow it. (Not!) Make a schedule and follow it. Try to pace yourselves and keep

making progress.



Project: Working in groupsProject: Working in groups Rotate responsibilities Have a moderator and a recorder at each meeting

Moderator keeps meeting on track, keeps track of action items Recorder keeps good notes

Allow contributions from all members Project is a learning process as well as just a job Need to make sure all are on board Use the Amerindian tradition of the "Talking Stick"

Be careful not to overwhelm people. Tell people if you feel you are

Being ignored Not given enough work or too simple work.

Make a schedule of work and action items (deliverables, both internal and external) Keep communicating. Answer your mail promptly.

8 of 94


SE 430 – Class 3SE 430 – Class 3Topic: Use-Case Model

Concepts and Background The Use-Case Model in the Unified Process

» High level use cases Use-Case Workflow Use-Case Tasks and Artifacts

» Use Case Diagrams » Ranking Use Cases » Detailed Use Cases

System Sequence Diagrams

Reading:

Arlow & Neustadt: Ch’s 4 & 5

Class reading list

9 of 94


Thought for the DayThought for the Day

"Never ask users what they want, or they'll tell you."

10 of 94


Last TimeLast TimeTopics: Requirements Analysis

Defining Requirements Problem Statement or Project Charter or Vision Requirements Document

» Formal list of what the product will do

Business and Domain Rules Activity Diagrams

11 of 94


Big PictureBig Picture

Today

12 of 94

Object-Oriented ModelingObject-Oriented Modeling


What is a model?What is a model? A model is an abstraction which strips away unnecessary details, and

views an entity from a particular perspective This is another application of the just right principle: include just what you

need for the problem at hand, no more, no less

Models allow us to: Focus on the important parts of the entity Ignore parts of the entity that are irrelevant Hypothesize and reason about the entity

Paraphrased from Software Measurement and Estimation: A Practical Approach, L.M. Laird & M.C. Brennan, 2006


A fundamental modeling principleA fundamental modeling principle

“Models are not right or wrong, they are more or less useful.”

- Martin Fowler


Types of object-oriented analysis modelsTypes of object-oriented analysis models Requirements capture the needs and wants of various stakeholders and

formalize them as user stories Requirements represent a collective mental model of the system

viewed from the stakeholders' perspective‣ Everyday mental model example: Thermostats of different sorts

The use-case model—use cases and system sequence diagrams— models the dynamic/behavioral/process-oriented aspects of the system However, the use case diagram is a static diagram that models the

static relationships among actors and use cases The domain model—diagram and glossary—models the

static/structural/logical aspects of the system Domain processes are modeled in both the use case model and in the

domain model


Domain processes: static and dynamic representationsDomain processes: static and dynamic representations

Domain processes are modeled statically in the domain modeland dynamically in use cases


Visualizing O-O model relationshipsVisualizing O-O model relationships



Modeling system behaviorModeling system behavior

19 of 94


Modeling system behaviorModeling system behaviorTypical ways of modeling system behavior Scenarios or story boards Use cases or user stories (System) Sequence diagram: way of drawing a picture of a

scenario (Object) Interaction diagrams

Message sequence charts Communication (Collaboration) Diagrams

20 of 94

ScenariosScenarios


A scenario is a little story it is an outline of some

expected sequence of events

A scenario is used to convey the fundamentals of “how things work”

It usually includes at least one actor

Each actor can make requests of the system or respond to system activity

I would like a book of stamps, please.

That will be $9.90.

Here is $10.

Thanks. Here are your stamps and your change.

Yes.

OK. Will that be all?

21 of 94


High-level system viewHigh-level system view If we look at the system as a

“black box”, we can identify some of the external users of the system (either humans or other computer systems) The simplest “black box”

diagram is a system diagram, which shows the outside actors

The use case diagram is more elaborate: it also shows the connections between “use cases” and actors

register

deleteoffering

create newcourse

My systemStudent

Administrator

Instructor

Use case diagram

System diagram

My system

Student

Administrator

Instructor

22 of 94


Sequence diagramSequence diagram A sequence diagram is a way of drawing a picture of a scenario Sequence diagrams are also sometimes called event trace diagrams,

ladder diagrams, interaction diagrams, or fence post diagrams Each vertical line describes an “actor” or a “system” in the scenario The vertical axis represents time: time flows down the page

Postal clerk

Ask for book of stamps

Customer

No

Do you want anything else?

Respond with price

Give stamps and change

Give money

23 of 94


Iterative DevelopmentIterative DevelopmentUse Cases Decide and describe the functional requirements of the

system Bring agreement between the customer and software

developer Give a clear and consistent description of what the system

should do. Provide a basis for performing tests that verify the system

delivers the functionality stated. Trace the functional requirements into actual classes and

operations in the system.

24 of 94

Use-Case Model IUse-Case Model I

Concepts and Background The Use-Case Model in the Unified Process Use-Case Workflow Use-Case Tasks and Artifacts


Concepts and BackgroundConcepts and Background



Use CasesUse Cases A use case tells a story of actors using a system.

“Rent Videos” A use-case is a sequence of actions a system performs that yields

an observable result of value to a particular actor.

One artifact to express (especially) functional requirements. Emphasizes thinking about the valuable objectives-

oriented viewpoint of the users.

27 of 94


What is a use case?What is a use case? Documents a set of interactions between a user (or actor) and a

computer system. Can be viewed as a necessary (but not sufficient) collection of

requirements for those interactions. Use cases:

Help to focus on achieving well-defined user goals. Vary widely in their level of detail.

Capture use cases by: Interviewing users. Discussing their use of the system. Naming (a form of abstraction) and describing each use of system.

Hint: Domain processes and events from the system context description are good sources for use cases. Also functional requirements.

28 of 94


Use casesUse cases A use case is a concept that is related to scenarios:

A use case is a description of all the possible sequences of interactions among the system and one or more actors in response to some initial stimulus by one of the actors. (Rumbaugh)

A use case is a collection of possible sequences of interactions between the system under discussion and its external actors, related to a particular goal. (Cockburn)

In a use case, the system is considered as a black box

29 of 94


Use casesUse cases Each actor is an external thing that interacts with the

system An actor can represent either a human user or another system Actors have goals; they want to accomplish something

Use cases are often documented by drawing some scenarios Use case analysis often considers both “sunny-day scenarios” and

exceptional cases

30 of 94


User goals and system interactionsUser goals and system interactions Recall: User goals are specific,

but not detailed, descriptions of what user wants the system to do

A system interaction occurs when a user attempts to do something to achieve a goal

A single user goal may lead to several system interactions

31 of 94


Use cases and scenariosUse cases and scenarios The use case describes a set of interactions between the user and the

system, possibly with several different outcomes. A scenario describes a specific path through, and outcome of, a use

case. A use case represents a collection of scenarios: primary, plus zero or

more alternates. The primary scenario corresponds to the main system interactions,

usually the ‘success’ scenario. Alternate scenarios correspond to less frequent interactions and

exceptions. Different scenarios are analogous to alternatives in switch..case

constructs. The term interaction can refer to a single interaction or a set. Typically

an actor has a set of interactions with the system.

32 of 94


From user goals to scenariosFrom user goals to scenarios

Goal/requirement space System behavior space

33 of 94


Another viewAnother view

User Goal

Interaction 1 Interaction 2 Interaction n

…

Use case 2

Scenario 1 Scenario 2

…

Scenario n

yields

maps to

composed of

… …

34 of 94


Use case formatUse case format Start with a simple use-case format and add additional features, if

needed. For each use case, provide:

Identification. short identification tag, e.g. UC001 Name. Provide a (short) title Description. brief description in a few sentences. Short narrative (2-

3 sentences) describing use case and objectives Actors. List the actors that interact with this use case. Goals. What the actor wants to achieve. Preconditions. Specify what conditions must be true before the use

case starts. Postconditions. Specify what conditions must be true when the use

case ends. Event Flow. Use a sequentially-numbered list of brief statements

describing the steps of the use case. Start with “This use case begins when…” and end with “This use case ends when…”.

35 of 94


High-level use case: primary scenarioHigh-level use case: primary scenarioIdentification: UC003Name: Artifact physical care requirements entryDescription: Enter physical care requirements for a new artifact into the Artifact

Tracking System (ATS)Actors: Artifact Tracking (AT) staff member (user); climate, fire, and security

control subsystemsTrigger: AT staff member wishes to enter all the climate, fire, and security control

physical care requirements for a new artifact into the ATSGoals: see Trigger abovePreconditions:

Ø AT staff member must be logged into the ATS.Ø AT staff member must have entered the unique identification code

assigned to the artifact.Incoming information: Climate, fire control, and security requirements for artifactResults: Artifact physical care requirements are entered into ATSPostconditions:

Ø ATS (in collaboration with appropriate subsystems) confirms Museum can provide appropriate physical care for artifact.

36 of 94


High-level use case – basic formHigh-level use case – basic formEvent Flow:1. This use case begins when the user selects ‘ArtifactPhysical Care’

from the ATS menus.2. System displays a blank entry form for the artifact's climate control

requirements.3. User enters the artifact's climate control requirements into the form.4. User selects ‘Continue’ to end climate control requirements entry.5. System displays a blank entry form for the artifact's fire control

requirements.6. User enters the artifact's fire control requirements into the form.7. User selects ‘Continue’ to end fire control requirements entry.8. System displays a blank entry form for the artifact's security

requirements.9. User enters the artifact's security requirements into the form.10. User selects ‘Continue’ to end security requirements entry.

37 of 94


High-level use case—basic formHigh-level use case—basic formEvent Flow:11. User selects ‘Continue’ to end physical care requirements entry.12. System presents the artifact's physical care requirements to the user

for review.13. This use case ends when the user selects ‘Accept’ for the displayed

information.

38 of 94


Alternate event flow form with Alternate event flow form with ‘‘repeatrepeat’’ Event Flow:1. This use case begins when the user selects ‘ArtifactPhysical Care’

from the ATS menus.2. For each specific physical care requirement (climate, fire, security)

repeat steps 3-5:3. System displays a blank entry form for the artifact's specific physical

care requirements.4. User enters the artifact's specific physical care requirements into the

form.5. User selects ‘Continue’ to end specific physical care requirements entry.6. User selects ‘Continue’ again to end all physical care requirements

entry.7. System presents the artifact's physical care requirements to the user for

review.8. This use case ends when the user selects ‘Accept’ for the displayed

information.

39 of 94


Use case evolutionUse case evolution Storyboards represent an early form of use case. Use cases were formalized in Ivar Jacobson's Objectory process

and later popularized in Object-Oriented Software Engineering: A Use Case Driven Approach (1992).

Use cases were incorporated in UML at the very earliest stages: sometime around v. 0.9 or 1.0.

Use cases have been part of the Unified Process – “a use-case-driven process” – from its inception.

Schneider & Winters (Applying Use Cases: A Practical Guide), Cockburn (Writing Effective Use Cases), and others have helped make use cases more accessible.

40 of 94


Use cases in the software life cycleUse cases in the software life cycle First iteration of Elaboration:

About 80% of use cases captured.

About 10% detailed.

Why just 10%? About 10% of project use cases will be identified as highest-risk.

Subsequent iterations: Most use cases captured.

About 80% detailed by end.

Why only 80%? About 20% of use cases will be minor variations on others or will be trivial.

Construction: Use cases added or extended by recycling to Inception phase.

41 of 94

Use Case WorkflowUse Case Workflow



Idealized use case workflowIdealized use case workflow

43 of 94


UC workflow techniques and artifactsUC workflow techniques and artifacts

Start

44 of 94

Use Case Tasks & ArtifactsUse Case Tasks & Artifacts



Find actorsFind actors Identifying actors is the most critical element in constructing

the use-case model. A use-case actor interacts with the system in a specific role Candidate actors can come from several sources. System context description can be a rich source of

candidate actors. Actors may take on more than one role, depending upon

specific interaction.

46 of 94


Find actorsFind actors Minimize overlap of roles that different use-case actors play:

Combine overlapping roles into a single role for one actor» Example: Assign ‘Security Profile Administrator’ role and ‘Access

Privileges Manager’ roles to a single Security Profile Manager actor, unless there is a good reason to keep them separate

Assign one or more overlapping roles to separate actors.» Example: A Museum Administrator may act in both system

management and end user roles. Assign these very different roles to two different actors: System Manager and End User

47 of 94


Types of actors Types of actors Primary actors

The source of user goals. Have goals satisfied through interactions with the system. Example: ATS staff member has goals satisfied by ATS.

Supporting actors Provide a service to the system. Have interfacing requirements with the system. Example: Climate, security, and fire control systems are supporting

actors to the ATS, providing ATS with information. Offstage actors

Have secondary (or more-removed) interaction with the system. May have needs that the system satisfies. Example: Visitor Information system is an off-stage actor to the

ATS. ATS provides information to Visitor Information system.

48 of 94


Find use casesFind use cases There is no cookbook formula for finding use cases. Good starting points for finding use cases:

Interviews with users. Domain processes and events from system context description. Interactions associated with various type of actors. Functional Requirements. Any other requirements.

49 of 94


Exercise: Identifying use casesExercise: Identifying use cases Suppose we want to develop an Automated Teller Machine.

List some of the use cases for such a system:

50 of 94


Exercise: Identifying use casesExercise: Identifying use cases Suppose we want to develop an Automated Teller Machine.

List some of the use cases for such a system: Get instant cash Transfer money Get money from checking Balance check Deposit cash or checks

51 of 94


Use case formatsUse case formats Brief

Same as high-level with no steps, but a two to three sentence description.

See sample form (see notes).

High-level Very terse summary—perhaps 5-6 steps in event flow. Usually two

or three sentences describing the objective. Covers only the primary scenario with minimal detail. Roughly equivalent to the Agile‘stories.’ See sample form (see notes).

Casual More detailed format—perhaps 10-20 steps in event flow. Include actors and possibly pre- and post-conditions. May cover important scenarios other than primary.

52 of 94


Use case formatsUse case formats Fully-dressed (detailed) or expanded or extended

Lengthy and detailed—perhaps > 15-20 steps in event flow. Covers most scenarios. Can be trimmed to suit phase and priority of use case.

Or, see my sample forms:http://condor.depaul.edu/dmumaugh/readings/SE430readings.html[Project Forms and Documents]

53 of 94


Variations on a ThemeVariations on a Theme Many different use case formats. Cockburn had over 37

variations. Use whatever provides the most information at the level of

detail appropriate The reading list has a couple of forms that might be useful.

54 of 94


Describing the Use-case Model As a WholeDescribing the Use-case Model As a Whole

We need some way to summarize and track the various actors and use cases and their relationships

Full use-case model consists of:1. Use-case (prose) descriptions, at various appropriate levels of

detail

2. Glossary which contains definitions and descriptions of items in the use-case model

3. Visual model in the form of a use-case diagram

4. Select system sequence diagrams

55 of 94

GlossaryGlossaryA glossary is part of the use-case model Consists of all the terms and phrases listed in the

requirements document List of actors and their goals List of use-cases (name and description) Any new terms and phrases introduced



Use-case diagramUse-case diagram Static, summary illustration of

use-case structure. Stick-people icons are actors

that use the system, linked to particular use case(s).

Rectangles represent external system actors that interact with the use case.

Ellipses indicate use cases themselves.

«extends» link » specialization «uses» link » aggregation «include» is same as «uses»

57 of 94


ATS sample use-case diagramATS sample use-case diagram

Save and publishnew artifactdescription

Create newartifact

description

Enter artifactphysical carerequirements

Enter artifactphysical

description

ATS StaffMember

<< actor>>

Climate Control

Subsystem

<< actor>>

Fire ControlSubsystem

<< actor >>

Security ControlSubsystem

58 of 94


Sidebar: Identifying the system boundarySidebar: Identifying the system boundary

Like most analysis and design concepts, system and system boundary may vary with the level of abstraction.

The system represents the software and hardware elements which are the current focus of attention. Example: In the Museum Automation Problem, each individual

subsystem—climate, security, Visitor Information—can be considered ‘the system’ during its analysis and design.

The system boundary represents the division between the system itself, including software and hardware, and the actors: primary, supporting, and off-stage.

Defining the scope of the system during the requirements effort can help delineate the system boundary.

59 of 94


Detailed use casesDetailed use cases Highest-priority use cases require early attention to detail. Identify the use cases scheduled for the first iteration of

development, generally about 10% of total. For each first-iteration use case, write a detailed (fully-

dressed) use case. Because these use cases are being detailed at an early

stage, they may require refinement in later iterations. Avoid getting involved in detailed UI design issues at this

stage: write use cases in an essential (mostly UI-free) style.

60 of 94


Sidebar: essential styleSidebar: essential style Keep UI specifics out of the use cases and focus on the

actor’s intent during the interaction The UI is a part of the system that is expected to change

substantially over the course of development Early specification of UI details can solidify issues that are

best left flexible at this point So:

Postpone specific UI descriptions and interactions until later in design and even then, confine them to a ‘look & feel’ artifact

It’s OK to use general UI terminology and user actions: displays, menus, buttons; selects, enters, confirms

Avoid specific UI widgets (e.g. radio buttons, pop-up menu, drop-down menu) or user interaction descriptions (scrolls, highlights, drags)

61 of 94


Detailed use-case formatDetailed use-case format Start with a simple use-case format and add additional features, if

needed. Suggested detailed use-case elements:

Identification – use-case ID (Number) Name Narrative description (two to three sentences) Actors (primary, supporting, off-stage), goals and roles. Preconditions and postconditions. Main (primary) scenario event flow. Extensions (alternate scenarios) event flows. Special requirements (attributes and constraints identified in

requirements document). Technology and data variations list (from supplementary, non-

functional requirements). Frequency of occurrence of use case Open issues related to the use case

62 of 94


Structuring the use-caseStructuring the use-case Follow a consistent structure for all detailed use cases. Always use “This use case begins when…” and “This use case ends

when…” stylistic ‘bookends’. The primary scenario should be the one most readily traced through

the use case. Defer exceptional conditions and branches to alternative scenarios. Alternative scenarios (a.k.a. extensions) should follow the primary

scenario in the text. Alternative scenarios are identified by the step number in the primary

scenario plus a letter. Example: Three alternative scenarios that begin at step 6 in a

primary scenario would be labeled 6a, 6b, and 6c.

63 of 94


Detailed use case example: headerDetailed use case example: headerIdentification: UC003Name: Artifact physical care requirements entryDescription: Enter physical care requirements for a new artifact into the Artifact

Tracking System (ATS)Actors: Artifact Tracking (AT) staff member (user); climate, fire, and security

control subsystemsTrigger: AT staff member wishes to enter all the climate, fire, and security control

physical care requirements for a new artifact into the ATSGoals: see Trigger abovePreconditions:

Ø AT staff member must be logged into the ATS.Ø AT staff member must have entered the unique identification code

assigned to the artifact.Incoming information: Climate, fire control, and security requirements for artifactResults: Artifact physical care requirements are entered into ATSPostconditions:


64 of 94


Use case example with alternate scenarioUse case example with alternate scenarioEvent Flow:

1. This use case begins when the user selects ‘ArtifactPhysical Care’ from the ATS menus.

2. System displays a blank entry form for the artifact's climate requirements.3. User enters the artifact’s climate requirements.4. User selects ‘Continue’ to end climate requirements entry.5. System displays a blank entry form for the artifact's fire requirements.6. …

5a. Museum facilities cannot support climate requirements of artifact:1. System informs user that Museum cannot support climate

requirements of artifact.2. System specifies requirement(s) that cannot be met.3. System displays climate control system modification request form.4. User enters the climate requirements for the artifact.5. User selects ‘Submit’ to submit modification request to facilities staff.6. Continue event flow with step 5.

65 of 94


Example: additional elementsExample: additional elementsSpecial requirements: All entered physical care requirements

must be verified against minimal generic requirements for the type of artifact

Technology and data variations list: System must support both artifacts that are part of the Museum's permanent collection and those that are on temporary loan from other sources

Frequency of occurrence: Variable. Very high during initial set-up; high during arrival of visiting exhibitions; low otherwise

Open issues: Must identify minimal lists of requirements for each of the areas (climate, fire, and security)

66 of 94


Prioritize use casesPrioritize use cases Planning in an iterative and incremental process is risk-

driven. Schedule analysis, design, and implementation of use

cases representing core system (required vs. desirable or optional) functionality and high-risk use cases for early iterations

Conversely, schedule development of non-core-functionality and low-risk use cases for later iterations.

Need to balance risk and functionality factors. At this stage, consider priority based on:

Proportion of contribution to overall system functionality. Technological, skills, and dependency risks.

67 of 94


Risk factorsRisk factors Requirements risks

Have you properly identified requirements for system? Have you reviewed project scope? Can you effectively set functional requirements priorities?

Technological risks Are you using a new, untested technology?

Dependency risks Are you depending on a third-party product?

Skills risks Are you planning to do something with which you are completely

unfamiliar? Do you have the right staff with the necessary skills?

68 of 94


Ranking (or Prioritizing) Use CasesRanking (or Prioritizing) Use CasesProject managers use use case versions for development

cycles Time-box development cycles have a fixed time frame. Complex use cases may require multiple development

cycles to be fully implemented. Create simplified versions of the complex use case that

can be developed within each subsequent time-box.

69 of 94


Ranking Use CasesRanking Use CasesSetting Priorities – Rank Order use cases Many factors may be need to be considered when ranking

or prioritizing use cases:A. Impact on the architectural design

B. Information and insight regarding the design

C. Risky, time-critical, or complex functions

D. New or risky technology.

E. Represent line-of-business processes

F. Directly support increased revenue or decreased costs.

70 of 94


Ranking Use CasesRanking Use Cases

Use Case A B C D E F Sum

Buy Items 5 3 2 0 5 3 18

Add New Users 3 3 2 0 2 2 12

Start Up 3 2 2 0 2 2 11

71 of 94


Rank Use Case Justification

High Buy Items Scores on most increased ranking criteria

Medium Add New UsersLog InRefund Items

Affects Security DomainAffects Security DomainImportant process affects Accounting

Low Cash OutStart UpShut Down

Minimal effect on architectureDefinition is dependent on other use casesMinimal effect on architecture

Ranking Use CasesRanking Use CasesIt is also possible to do simpler classifications – high, medium,

low

72 of 94


Practical tipsPractical tips Pick a set of use cases that maximizes system coverage

write two or three of the most common simple transactions first; most common or “sunny day”

it is easy to get carried away generating too many use cases, so try to create more “abstract” scenarios when three or more scenarios look very similar

Keep a list of Actors/Roles/Goals/Use Cases After all use cases are developed, refactor for common

elements

73 of 94


Practical tipsPractical tips Beware of analysis paralysis

inability to write any scenarios, or creating too many detailed scenarios

Techniques to get out of analysis paralysis: write two or three of the most common simple transactions first it is easy to get carried away generating too many use cases, so

try to create more “abstract” scenarios when three or more scenarios look very similar

be cautious of generating more than 30 use cases to cover the fundamental system actions

additional use cases for unusual events should be chosen with care and kept to a manageable number

74 of 94


ConceptsConcepts In writing use cases, start to identify potential classes,

objects, and sub-systems Use cases are used to generate the conceptual (domain)

model Nouns become “concepts” or classes/objects Verbs become “actions” or methods

Start each use case name with a verb. Start sentence 1 with “<Actor> does <event>” All systems have a Start Up and Shut Down use case

(perhaps trivial).

75 of 94


System testingSystem testing One big reason for writing use cases: they really help

when it is time to test the entire system both sunny day cases and exception behavior can be extracted

from the use case descriptions the use cases define what behavior is inside the system and what

behavior depends on the external actors

Since use cases treat the system as a black box, there is a great deal of design freedom, but the external behavior must be correct

76 of 94


Use Case DiagramUse Case Diagram A way to conceive and

illustrate the use cases. Usually created during the

initial use case analysis.

77 of 94


Diagram of Sample Use CaseDiagram of Sample Use Case

78 of 94

Use-Case Model IIUse-Case Model II

Use case workflow tasks and artifacts

System Sequence Diagrams



Use case workflow tasks and artifactsUse case workflow tasks and artifacts

Next

80 of 94


Statecharts discussed in

context of object

behavior.

Additional techniques and artifactsAdditional techniques and artifacts

Next

81 of 94

System Sequence DiagramsSystem Sequence Diagrams



Use Cases and System Sequence DiagramsUse Cases and System Sequence Diagrams

A use case is a prose description of an actor/system interaction.

Use case diagram is a visual summary of: All significant use cases. All significant actors. Relations among actors and use cases.

A System sequence diagram (SSD) is a visual summary of the individual use cases.

For ease of understanding, each use-case scenario corresponds to a separate system sequence diagram.

83 of 94


Characteristics of System Sequence DiagramsCharacteristics of System Sequence Diagrams

System sequence diagrams are a special case of the more-general UML sequence diagram.

Captures the sequencing of messages and data exchanged between an actor and the system.

Provides about the same level of detail as use-case prose description.

Usually deals with primary actors and system, but can include other actors as well.

Provides a more formal notation for expressing the interaction.

Concerned only with external behavior: the system is treated as a black box.

84 of 94


System Sequence DiagramSystem Sequence Diagram

85 of 94


System Sequence Diagram NotationSystem Sequence Diagram Notation

.

Note that software participants cannot

perform operations on human actors!

86 of 94


Sequence DiagramsSequence Diagrams

Messages are indicated by a solid line with an arrow.

Arrow Meaning Arrow head style UML 2.0

Synchronous Transfer control and wait for answer. (sequential operations)

Return Returns a value to the caller (optional)

87 of 94


Artifact Tracking use caseArtifact Tracking use caseName: Artifact physical care requirements entryDescription: Enter physical care requirements for a new artifact into the

Artifact Tracking System (ATS)Actors: Artifact Tracking (AT) staff member (user); climate, fire, and

security control subsystemsTrigger: AT staff member wishes to enter all the climate, fire, and security

control physical care requirements for a new artifact into the ATSPreconditions:

1. AT staff member must be logged into the ATS.2. AT staff member must have entered the unique identification code

assigned to the artifact.Incoming information: Climate, fire control, and security requirements for

artifactResults: Artifact physical care requirements are entered into ATSPostconditions:


88 of 94


Artifact Tracking use caseArtifact Tracking use caseEvent Flow:

1. The use case begins when the user selects to begin the ‘Physical care entry’ process for an artifact in ATS.

2. For each specific physical care requirement (climate, fire, security) repeat steps 3-5:

3. System displays a blank entry form for the artifact's specific physical care requirements.

4. User enters the artifact's specific physical care requirements into the form.

5. User selects ‘Continue’ to end specific physical care requirements entry.

6. User selects ‘Continue’ again to end all physical care requirements entry.

7. System presents the artifact's physical care requirements to the user for review.

8. The use case ends when the user selects ‘Accept’ for the displayed information.

89 of 94


Use-case system sequence diagramUse-case system sequence diagram

ATS

select('Physical Care Entry')

User

select('Continue')

physicalCareRequirementsEntryForm

enter(physicalCareRequirements)

<<actor>>Control

Subsystem

confirm(specific requirement)

requirementsConfirmationForm

select('Accept')

confirmation

[for each physical care category]loop

90 of 94


SSD – With Use CaseSSD – With Use Case

91 of 94


SummarySummary OO analysis starts with the following “requirements-oriented

” data: problem statement list of text inputs set of use cases

A Use-case is a major distinct, complete, end-to-end process of using a system. Not usually one step, but a complete story.

Use cases tell a story of actors using a system. Examples

» Rent Videos» Return Videos» Pay Fines

A use-case is a sequence of actions a system performs that yields an observable result of value to a particular actor.

92 of 94


SummarySummary A use-case is one artifact to express (especially) functional

requirements. Use-cases emphasize thinking about the valuable, objectives-oriented

viewpoint of the users. They illustrate functional requirements, by the stories they tell. Use-cases are valuable for:

providing a good overview of the system to be developed defining the system boundary helping to generate the test suites

Complementary with a feature requirement list. Choose use-cases carefully since they are the requirements for the

entire system and the foundation for the OO analysis process Forms a contract (see Design by Contract)

93 of 94

Next ClassNext ClassTopic:

Static Structure: Requirements Traceability; Building a Beginning Conceptual Model: Class Diagram; CRC Cards; Domain model basic principles; Domain model associations; Domain model attributes; System Glossary.

Reading:

Arlow & Neustadt: Ch’s 6-9 Driving Design: The Problem Domain Tracing Your Design

Using CRC CardsAssignment – October 1, 2015


http://www.ddj.com/dept/architect/184414689

http://www.ddj.com/dept/architect/184415675

http://alistair.cockburn.us/index.php/Using_CRC_cards