UML 2 & Use Case Models - omegaegitim.com · UML 2 & Use Case Models 1 Modeling with UML 2 17...

30.10.2011

1

UML 2 &Use Case Models

Binnur Kurt, Ph.D.Omega Training and Consultancywww.omegaegitim.com

[email protected]

UML 2 & Use Case Models 2

Agenda

1. Modeling with UML 2 and Software Development Process2. Creating Use Case Diagrams3. Creating Use Case Scenarios and Forms

30.10.2011

2


Background

1995, B.Sc.

1997, M.Sc.

2007, Ph.D.

(All in Computer Engineering)

2004‐2008, Lecturer, ITU Computer Eng. Dept.

2008‐to date, Trainer & Consultant


References – UML2

30.10.2011

3


References – UML2, Use Cases


References –Use Cases

30.10.2011

4


BiographyDr. Binnur Kurt received BS, MS, and PhD degrees from Istanbul TechnicalUniversity in 1995, 1997, 2007 all in computer engineering. He was alecturer at the Computer Engineering Department of Istanbul TechnicalUniversity from 2004 to 2007 and offered courses mostly on webprogramming and object oriented software engineering. He is currentlyworking as an information technology consultant and trainer in JavaEnterprise Technologies, Object Oriented Analysis and Design, ServiceOriented Architecture, MySQL, Oracle Middleware Technologies, UnixProgramming and Administration, High performance computing, and Real‐Time Computer Vision systems. He has published many internationalconference and journal papers, and book chapters on these topics. He hasalso designed many IT trainings and written training materials onadvanced topics, including Spring Framework, JSF, XML Web Services,Service Oriented Architecture, and OSGi. He holds several certifications,including Sun Certified Java Programmer, Oracle Certified ProfessionalMySQL 5.0 Developer, Oracle Certified Professional MySQL 5.0 DatabaseAdministrator and Red Hat Certified Engineer. He is also referee for theassessment of industrial projects submitted to TUBITAK Technology andInnovation Funding Programs Directorate (TEYDEB) and inspector forindustrial projects supported by TUBITAK Technology and InnovationFunding Programs Directorate (TEYDEB).


> Java Desktop and Enterprise Technologies

> SOA

> OOAD

> MySQL

> Oracle Directory Server

> Application Servers: WebLogic, Glassfish, Tomcat

Areas of Interest

30.10.2011

5

1Modeling with UML 2and Software Development Process

UML 2 & Use Case Models Modeling with UML 2 101

Software Complexity

> The profile and importance of software has increased

30.10.2011

6


Software Complexity is increasing


And things are only going to get worse

> Increasingly complex, vulnerable and every changing platforms, applications and customer desires.

30.10.2011

7


Important Skills> These skills are essential for the creation of well‐designed, robust, and

maintainable software

> Apply principles and patterns to create better object designs.

> Follow a set of common activities in analysis and design, based on theUnified Process as an example.

> Create diagrams in the UML notation.

Skills

UML notation

Requirements analysis

Principles and guidelines

Patterns

Software Development Process Model

OOA/D


OO Concepts

> Objects

> Classes

> Abstraction

> Encapsulation

> Inheritance

> Interfaces

> Polymorphism

> Cohesion

> Coupling

> Class associations and object links

> Delegation

30.10.2011

8


OOP Principals

> The Single‐Responsibility Principle (SRP)

> The Open/Closed Principle (OCP)

> The Liskov Substitution Principle (LSP)

> Common Closure Principle (CCP)

> Acyclic Dependency Principle (ADP)

> Stable Dependencies Principle (SDP)

> Stable Abstractions Principle (SAP)


Patterns

> Design Patterns – GoF Patterns

> Security Patterns

> Networking Patterns

> Concurrent, Parallel System Patterns

> Java EE Patterns

30.10.2011

9


Describing Software Methodology

A methodology is “a body of methods, rules, and postulatesemployed by a discipline” [Webster New Collegiate Dictionary]

> In OOSD, methodology refers to the highest‐levelorganization of a software project.

> This organization can be decomposed into medium‐level phases. Phases are decomposed into workflows (disciplines). Workflows are decomposed into activities.

> Activities transform the artifacts from one workflow toanother. The output of one workflow becomes theinput into the next.

> The final artifact is a working software system thatsatisfies the initial artifacts: the system requirements.


The OOSD Hierarchy

30.10.2011

10


Listing the Workflows of the OOSD Process

Software development has traditionally encompassed thefollowing workflows:

> Requirements Gathering

> Requirements Analysis

> Architecture

> Design

> Implementation

> Testing

> Deployment


Describing the Software Team Job Roles

30.10.2011

11


Describing the Software Team Job Roles


Exploring the Requirements GatheringWorkflow

30.10.2011

12


Activities and Artifacts of the RequirementsGathering Workflow


Exploring the Requirements AnalysisWorkflow

30.10.2011

13


Activities and Artifacts of the RequirementsAnalysis Workflow


Exploring the ArchitectureWorkflow

30.10.2011

14


Activities and Artifacts of the ArchitectureWorkflow


Exploring the DesignWorkflow

30.10.2011

15


Exploring the DesignWorkflow


Activities and Artifacts of the DesignWorkflow

30.10.2011

16


Exploring the Implementation, Testing, andDeployment Workflows


Exploring the Implementation, Testing, andDeployment Workflows

30.10.2011

17


Exploring the Benefits of Modeling Software

> The inception of every software project starts as an idea insomeone’s mind.

> To construct a realization of that idea, the development team must create a series of conceptual models that transform the idea into a production system.


Activities and Artifacts of theImplementation, Testing, and DeploymentWorkflows

30.10.2011

18


What is a Model?

“A model is a simplification of reality.” (Booch UML User Guidepage 6)

> A model is an abstract conceptualization of some entity(such as a building) or a system (e.g. software).

> Different views show the model from different perspectives.


Why Model Software?

“We build models so that we can better understand the system we are developing.” (Booch UML User Guide page 6)

> Specifically, modeling enables us to:

—Visualize new or existing systems

—Communicate decisions to the project stakeholders

—Document the decisions made in each OOSD workflow

—Specify the structure (static) and behavior (dynamic)elements of a system

—Use a template for constructing the software solution

30.10.2011

19


Information Systems and IT Systems

> An IT system is a computer‐based system—a system that provides information needed for the execution of certain business processes.

> A business model is a framework for creating economic, social, and/or other forms of value.

> A business process is a collection of related, structured activities or tasks that produce a specific service or product for a particular customer or customers.


Definition: Business Process Management

Business Process Management (BPM) is defined as a strategy for managing and improving the performance of a business through continuous optimization of business processes in a closed‐loop cycle of modeling, execution, and measurement.

ModelingExecution

Measurement

30.10.2011

20


Definition: Business Process

A business process is a set of linked activities performed by people and systems that deliver some kind of value through a product or process to internal or external customers.


Real‐World Business Processes

Enterprise infrastructure services(portal, SOA, IDRS, LDAP, EAI, Email, IT operations)

Organizational Units

Manu‐facturing

Operations Finance and HR

Sales and Marketing

Order Management

Product Configuration

Warranty and Returns Management

Processes

30.10.2011

21


Real‐World Business Process Management

Enterprise infrastructure services(portal, SOA, IDRS, LDAP, EAI, Email, IT operations)

Order Management Process

Manu‐facturing

Operations Finance and HR

Sales and Marketing


Summary: Business Process Management

X

Systems People Information

Process

Strategy Goals Policies

30.10.2011

22


Elements of a BPMN Business Process Model

Sequence FlowEvent

Task

Gateway

Start Activity1

Activity2

UserTask

End


OOSD as Model Transformations

> Software development can be viewed as a series oftransformations from the Stakeholder’s mental model to the actual code:

30.10.2011

23


OOSD as Model Transformations

Application domain

public class Book {private String title;public void turnPage(int pn){...}

}

Book

title

Book

‐title: String

+turnPage(int)Application domain model

Software domain model


Defining the UML

“The Unified Modeling Language (UML) is a graphical language for visualizing, specifying, constructing, and documenting the artifacts of a software‐intensive system.” (UML v1.4 page xix)

> Using the UML, a model is composed of:—Elements (things and relationships)—Diagrams (built from elements)—Views (diagrams showing different perspectives of amodel)

30.10.2011

24


UML Elements


UML Diagrams

30.10.2011

25


UML Diagram Categories


Common UML Elements and Connectors

> UML has a few elements and connectors that are commonacross UML diagrams. These include:

—Package

—Note

—Dependency

—Stereotypes

30.10.2011

26


Packages and Notes

> Package

> Notes


Dependency and Stereotype

30.10.2011

27


What UML Is and Is Not


History of UML

30.10.2011

28


UML Subspecifications

UML Version 2.0 has been formally divided into the following sub‐specifications:

> Infrastructure: Core of the architecture, profiles, and stereotypes.

> Superstructure: Static and dynamic model elements.

> Object Constraint Language (OCL): A formal language used to describe expressions on UML models.

> Diagram Interchange: The UML interchange format for diagrams.


The Metamodel of UML 2.0

The UML 2.0 language is largely defined in a so‐called metamodel.

> The reason for the prefix meta is that the language resides one abstraction level above the model that a UML user models.

> Now, the metamodel might seem confusing and illogical at first because the metamodel is a UML class model that describes UML.

> In other words, UML is defined in UML.

30.10.2011

29


The four‐layer architecture of UML


Datatypes

UML distinguishes between the following data types:

> Simple data types (DataType)—A simple data type is a type with values that have no identity (e.g., money, banking information

> Primitive data types (PrimitiveType)—A primitive data type is a simple data type without structures.

> UML itself defines the following primitive data types:

—Integer: (Infinite) set of integers: (...,−2,−1,0,1,2,...)

—Boolean: true, false

—UnlimitedNatural (Infinite) set of natural numbers (0, 1, 2, . . .)

30.10.2011

30


Datatypes

> UML itself defines the following primitive data types:

—Enumeration types—Enumeration types are simple data types with values that originate from a limited set of enumeration literals


The metamodel of data types

30.10.2011

31


Overview of the UML diagrams


Stereotypes

> Stereotypes are formal extensions of existing model elements within the UML metamodel, that is, metamodelextensions.

> The modeling element is directly influenced by the semantics defined by the extension.

> Rather than introducing a new model element to the metamodel, stereotypes add semantics to an existing model element.

30.10.2011

32


Multiple Stereotyping

> Several stereotypes can be used to classify one single modeling element.

> Even the visual representation of an element can be influenced by allocating stereotypes.

> Moreover, stereotypes can be added to attributes, operations, and relationships.

> Further, stereotypes can have attributes to store additional information.


Notation

> A stereotype is placed before or above the element name (e.g., class name) and enclosed in guillemets («, »).

> The characters « and », sometimes referred to as angled quotes, should not be mistaken for doubled greater‐than,>>, or smaller‐than, << , characters.

> Not every occurrence of this notation means that you are looking at a stereotype.

> Keywords predefined in UML are also enclosed in guillemets.

30.10.2011

33


Graphical Symbols

> As an alternative to this purely textual notation, special symbols can be used.

> Examples: «entity», «boundary», and «control»

> In addition, tools are free to use special color marking or other visual highlighting


UML Standard Stereotypes

30.10.2011

34


UML Standard Stereotypes


Non‐Standard UML Stereotypes

30.10.2011

35


Non‐Standard UML Stereotypes


UML Tools

> UML itself is a tool. You can create UML diagrams on paper or a white board. However, software tools are available to:

> Provide computer‐aided drawing of UML diagrams

> Support (or enforce) semantic verification of diagrams

> Provide support for a specific methodology

> Generate code skeletons from the UML diagrams

> Organize all of the diagrams for a project

> Automatic generation of modeling elements for designpatterns, Java™ Platform, Enterprise Edition (Java™ EE platform) components, and so on

30.10.2011

36


An Example:Dice Game


An Example

> Before diving into the details of requirements analysis andOOA/D, this section presents a birds‐eye view of a few keysteps and diagrams, using a simple example

—A "dice game" in which a player rolls two die.

If the total is seven, they win

Otherwise, they lose.

30.10.2011

37


Define Use cases

> Use cases are not an object‐oriented artifact—they are simply written stories.

> However, they are a popular tool in requirements analysis and are an important part of the Unified Process.


Dice Game use case

> Play a Dice Game: A player picks up and rolls the dice. If the dice face value total seven, they win; otherwise, they lose.

30.10.2011

38


Define a Domain Model

> Object‐oriented analysis is concerned with creating a description of the domain from the perspective of classification by objects.

> A decomposition of the domain involves an identification of the concepts, attributes, and associations that areconsidered noteworthy.


Define Interaction Diagrams

> Object‐oriented design is concerned with defining software objects and their collaborations.

> A common notation to illustrate these collaborations is the interaction diagram.

30.10.2011

39


Define Interaction Diagrams

:DiceGame

play()

die1 : Die

fv1 := getFaceValue()

die2 : Die

roll()

roll()

fv2 := getFaceValue()


Define Design Class Diagrams

> In addition to a dynamic view of collaborating objects shown in interaction diagrams, it is useful to create a static view of the class definitions with a design class diagram.

> This illustrates the attributes and methods of the classes.

2

Die

faceValue : int

getFaceValue() : introll()

DiceGame

die1 : Diedie2 : Die

play()

1

30.10.2011

40

? ???

2Creating Use Case Diagrams

UML 2 & Use Case Models Creating Use Case Diagrams 802

30.10.2011

41


Process Map


Process Map

30.10.2011

42


Justifying the Need for a Use Case Diagram

Following are reasons a Use Case diagram is necessary:

> A Use Case diagram enables you to identify—bymodeling—the high‐level functional requirements (FRs) that are required to satisfy each user’s goals.

> The client‐side stakeholders need a big picture view of the system.

> The use cases form the basis from which the detailed FRs are developed.

> Use cases can be prioritized and developed in order ofpriority.

> Use cases often have minimal dependencies, whichenables a degree of independent development.


Use cases and other requirementsDesign constraints

> Operating systems

> Environments

> Compatibility

> Application standards

FURPS

> Functionality

> Usability

> Reliability

> Performance

> Supportability

Legal and regulatory requirements

> Federal Communication Commission

> Food and Drug Administration

> Department of Defense

> Canadian Standards Association

> European Union Directive

Use Cases

30.10.2011

43


Use cases drive software development

Implementedby

Implementation Model

Test ModelDesign Model

Use‐Case Model


Identifying the Elements of a Use Case Diagram

> A Use Case diagram shows the relationships between actors (roles) and the goals they wish to achieve.

> A physical job title can assume multiple actors (roles).

30.10.2011

44


> This diagram illustrates an alternate style that explicitlyshows an association between the Receptionist actor (role) and the Manage Reservation use case.

Identifying the Elements of a Use Case Diagram


Actors

An actor:

> Models a type of role that is external to the system andinteracts with that system

> Can be a human, a device, another system, or time

> Can be primary or secondary

—Primary: Initiates and controls the whole use case

—Secondary: Participates only for part of the use case

A single physical instance of a human, a device, or a systemmay play the role of several different actors.

30.10.2011

45


Actors

This icon represents a human actor (user) of the system.

This icon canrepresent any actor, but is usually used to represent external systems, devices, or time.

This icon represents a time‐trigger mechanism that activates a use case.


Actors

Müşteri

Amaç: Mal satın almak

VergiDairesi

Amaç: Vergileridoğru toplamak

Dükkan

Müşteriye Satış Sistemi

Satış İncelemeSistemi

Amaç:Firmanın satışPerformansını belirlemek

Amaç: Satışı yapmak

KasaGörevlisi

Terminal(kasa)

30.10.2011

46


Use Cases

A use case describes an interaction between an actor and the system to achieve a goal.

> A use case encapsulates a major piece of system behavior with a definable outcome.

> A use case is represented as an oval with the use case title in the center.

> A good use case title should consist of a brief butunambiguous verb‐noun pair.

> A use case can often be UI independent.


System Boundary

> The use cases may optionally be enclosed by a rectangle that represents the system boundary.

The system boundary box is optional.

This equivalent Use Case diagram shows the system boundary for clarity.

30.10.2011

47


Use Case Associations

A use case association represents “the participation of an actor in a use case.” (UML v1.4 spec. page 357)

> An actor must be associated with one or more use cases.

> A use case must be associated with one or more actors.

> An association is represented by a solid line with noarrowheads. However, some UML tools use arrows bydefault.


Creating the Initial Use Case Diagram

> One of the primary aims of the initial meeting with theproject’s business owner is to identify the business‐significant use cases.

—A use case diagram may be created during the meeting.

—Alternatively, the diagrams can be created after themeeting from textual notes.

> The next two slides present some text showing an abstract of the use‐case‐specific topics discussed during the meeting.

30.10.2011

48



> The booking agent (internal staff) must be able to manage reservations on behalf of customers who telephone or e‐mail with reservation requests. The majority of these requests will make a new reservation, but occasionally they will need toamend or cancel a reservation. A reservation holds one or more rooms of a room type for a single time period, and must be guaranteed by either an electronic card payment or the receipt of a purchase order for corporate customers and travel agents. These payment guarantees must be saved for future reference.

> A reservation can also be made electronically from the Travel Agent system and also by customers directly via the internet.



> The receptionist must be able to check in customers arriving at the hotel. This action will allocate one or more rooms of the requested type. In most cases, a further electronic card payment guarantee is required.

> Most receptionists will be trained to perform the booking agent tasks for customers who arrive without a booking or need to change a booking.

> The marketing staff will need to manage promotions (special offers) based on a review of past and future reservation statistics. The marketing staff will elaborate on the detailed requirements in a subsequent meeting.

> The management needs a daily status report, which needs to be produced when the hotel is quiet. This activity is usually done at 3 a.m.

30.10.2011

49




Identifying additional Use Cases

> During the meeting with the business owner, you willtypically discover 10 to 20 percent of the use cases needed for the system.

> During the meeting with the other stakeholders, you willdiscover many more use case titles that you can add to the diagram.

> For example:

—Maintain Rooms

Create, Update, and Delete

—Maintain RoomTypes

Create, Update, and Delete

30.10.2011

50



> The time of discovery depends upon the developmentprocess.

> In a non‐iterative process:

—You ideally need to discover all of the remaining usecase titles, bringing the total to 100 percent.

—However, this is a resource‐intensive task and is rarely completely accurate.



> In an iterative/incremental development process, anoption is to:

—Discover a total of 80 percent of the use case titles inthe next few iterations for 20 percent of the effort. This is just one of the many uses of the 80/20 rule.

—Discover the remaining 20 percent of use case titles in the later iterations for minimal effort.

> This process works well with software that is built toaccommodate change.

30.10.2011

51


Workflow of use case modeling

> Seek Actors: Name and describe> Seek Use Cases:

—For each actor ask “What'd you like to use the system for?”> Name and briefly describe each Use Case> Iterate based on previous findings

Iterate

Seek Actors

Describe the Use Cases

Seek Use Cases


Finding actors

> Actors are “end points” for communication, or add some information. (“A button is not an actor if it has no other function than to inform the system that someone has pressed it.”)

> Concentrate on the active actors. They give you the Use Cases.

> Remember:

—Actors represent roles!

—Actors are always outside the system!

> Examples: users, other systems, external hardware etc.

30.10.2011

52


Finding use cases

> Black Box view of the system

> A use case should satisfy a major goal for the actor

> Put yourself in the situation of an (active) actor. Ask yourself: “What do I want to do with the system?”

> Name each use case using a verb/noun combination

> The Use Case shall represent a complete functionality for the initiating actor. Do not divide it into parts that must be used together to add some value to the actor


Use case drawing guide> Use different use case diagrams to separate use cases in a logical way

> Group use cases that are initiated by common actors

> Do not put unrelated use cases in the same diagram

> Limit the number of use cases per diagram to 10

30.10.2011

53


Use Case Elaboration

> During the meeting with the other stakeholders, you will discover many more use cases that you can add to the diagram.

> You might also find that some use cases are too high‐level. In this case, you can introduce new use cases that separate the workflows.

Example: Becomes:


Expanding High‐Level Use Cases

> Typically, managing an entity implies being able toCreate, (Retrieve), Update, and Delete an entity (so called, CRUD operations). Other keywords include:

—Maintain

—Process

> Other high‐level use cases can occur. Identify these byanalyzing the use case scenarios and look for significantly divergent flows.

> If several scenarios have a different starting point, thesescenarios might represent different use cases.

30.10.2011

54


Expanding High‐Level Use Cases

> The expanded diagram:


Analyzing Inheritance Patterns

Inheritance can occur in Use Case diagrams for both actorsand use cases:

> An actor can inherit all of the use case associations fromthe parent actor.

> A use case can be subclassed into multiple, specialized use cases.

30.10.2011

55


Actor Inheritance> An actor can inherit all of the use case associations from the parent actor.

> This inheritance should be used only if you can apply the “is a kind of” rule between the actors.


Use Case Specialization

A use case can be subclassed into multiple, specialized usecases:

> Use case specializations are usually identified bysignificant variations in the use case scenarios.

> If the base use case cannot be instantiated, you mustmark it as abstract.

30.10.2011

56


Analyzing Use Case Dependencies

Use cases can depend on other use cases in two ways:

> One use case (a) includes another use case (i).

This means that the one use case (a) requires thebehavior of the other use case (i) and always performs the included use case.

> One use case (e) can extend another use case (b).

This means that the one use case (e) can (optionally)extend the behavior of the other use case (b).


The «include» Dependency

> The include dependency enables you to identify behaviors of the system that are common to multiple use cases.

> This dependency is drawn like this:

30.10.2011

57



> An include relationship is used to integrate a use case into another use case, thus becoming a logical part of that use case.



Identifying and recording common behavior:

> Review the use case scenarios for common behaviors.

> Give this behavior a name and place it in the Use Casediagram with an «include» dependency.

30.10.2011

58



Identifying behavior associated with a secondary actor:

> Review the use case scenarios for significant behavior that involves a secondary actor.



> Split the behavior that interacts with this secondary actor. Give this behavior a Use Case title, and place it in the Use Case diagram with an «include» dependency.

30.10.2011

59


The «extend» Dependency

> The extend dependency enables you to identify behaviors of the system that are not part of the primary flow, but exist in alternate scenarios.

> This dependency is drawn like this:


The «extend» Dependency

Identifying and recording behaviors associated with analternate flow of a use case:

> Review the use case scenarios for significant and cohesive sequences of behavior.

> Give this behavior a name and place it in the Use Casediagram with a «extend» dependency.

30.10.2011

60


A Combined Example


«extend» or «include»

30.10.2011

61


Packaging the Use Case Views

> It should be apparent that any non‐trivial softwaredevelopment would need more use cases than could beviewed at one time. Therefore, you need to be able to manage this complexity.

> One way of managing this complexity is to break down theuse cases into packages.



30.10.2011

62



> You can look inside each package to reveal the detailedcontent.

> A use case element may exist in multiple packages, where it participates in multiple views.



> A diagram consists of an area within a rectangle and a header in the upper left corner. The diagram header shows the diagram type (optional), the diagram name (mandatory), and parameters (optional).

30.10.2011

63




The Metamodel for Use cases and Actors

30.10.2011

64

3Creating Use Case Scenarios and Forms

UML 2 & Use Case Models Creating UC Scenarios & Forms 1283

Process Map

30.10.2011

65


Black‐Box Use Cases

> Black‐box use cases are the most common and recommended kind;

> They do not describe the internal workings of the system, its components, or design.

> The system is described as having responsibilities, which is a common unifying metaphorical theme in object‐oriented thinking

Black‐box style Not

The system records the sale. The system writes the sale to a database....or (even worse):The system generates a SQL INSERTstatement for the sale...


Formality Types

> Use cases are written in different formats, depending on need. In addition to the black‐box versus white‐box visibility type, use cases are written in varying degrees of formality:

—brief—terse one‐paragraph summary, usually of the main success scenario.

—casual—informal paragraph format. Multiple paragraphs that cover various scenarios.

—fully dressed—the most elaborate. All steps and variations are written in detail, and there are supporting sections, such as preconditions and successguarantees.

30.10.2011

66


The usecases.org Format

> Various format templates are available for fully dressed use cases.

> However, perhaps the most widely used and shared format is the template available at www.usecases.org.


Use case description

The Use Case usually contains the following components:> Name

—A verb/noun that satisfies a major goal for the actor> Description

—One sentence describing what this use case is about> Pre‐Conditions

—Condition(s) which must be satisfied before the use case can take place> Post‐Conditions

—The state in which the system will be at the end of the use case> Course of Action

—Describes the most conventional flow of events through the use case> Alternative Flows

—Describe less common flows through the use case> Exception Flows

—Describe flows where errors have occurred and how to recover

Analysis P

30.10.2011

67


The Two‐Column Variation

> Some prefer the two‐column or conversational format, which emphasizes the fact that there is an interaction going on between the actors and the system.

> It was first proposed by Rebecca Wirfs‐Brock, and is also promoted by Constantine and Lockwood to aid usability analysis and engineering.


The Two‐Column Variation

30.10.2011

68


The Best Format?

> There isn’t one best format; some prefer the one‐column style, some the two‐column.

> Sections may be added and removed; heading names may change.

> None of this is particularly important; the key thing is to write the details of the main success scenario and its extensions, in some form.


Recording Use Case Scenarios

> A Use Case scenario is a concrete example of a use case.

> A Use Case scenario should:

—Be as specific as possible

—Never contain conditional statements

—Begin the same way but have different outcomes

—Not specify too many user interface details

—Show successful as well as unsuccessful outcomes (indifferent scenarios)

> Use Case scenarios drive several other OOAD workflows.

30.10.2011

69


Selecting Use Case Scenarios

> While it is ideal to have multiple scenarios for all use cases, doing so would take a lot of time. Therefore, you can select appropriate scenarios by the following criteria:

—The use case involves a complex interaction with theactor.

—The use case has several potential failure points, suchas interaction with external systems or a database.

> There are two types of scenarios:

—Primary (Happy) scenarios record successful results.

—Secondary (Sad) scenarios record failure events.


Writing a Use Case Scenario

A Use Case scenario is a story that:

> Describes how an actor uses the system and how thesystem responds to the actions of the actor.

> Has a beginning, a middle, and an end.

30.10.2011

70


Primary Use Case Scenario: Example

> The beginning:

The use case begins when the booking agent receives a request to make a reservation for rooms in the hotel.



> The middle:

The booking agent enters the arrival date, the departure date, and the quantity of each type of room that is required. The booking agent then submits the entered details. The system finds rooms that will be available during the period of the reservation and allocates the required number and type of rooms from the available rooms. The system responds that the specified rooms are available, returns the provisional reservation number, and marks the reservation as “held”. The booking agent accepts the rooms offered.

30.10.2011

71



> More of the middle:

The booking agent selects that the customer has visited one of the hotels in this group before, and enters the zip code and customer name. The system finds and returns a list of matching customers with full address details. The booking agent selects one of the customers as being the valid customer. The system assigns this customer to the reservation. The booking agent performs a payment guarantee check. This check is successful.



> The end:

The system assigns the payment guarantee to the reservation and changes the state of the reservation to “confirmed”. The system returns the reservation ID and booking details.

30.10.2011

72


Secondary Use Case Scenario: Example

> The beginning:

The use case begins when the booking agent receives a request to make a reservation for rooms in the hotel.

> The middle:

The booking agent enters the arrival date, the departure date, and the quantity of each type of room that is required. The booking agent then submits the entered details. The system responds that there are no rooms available of any type for the date range specified in the request.

> The end:

The use case ends.


Supplementary Specifications

> Some of the project information that you gather cannot be stored with the use cases because this information needs to be shared by several use cases.

> This additional information can be documented in aSupplementary Specification Document, which oftencontains:

—NFRs

—Project Risks

—Project Constraints

—Glossary of Terms

30.10.2011

73


Non‐Functional Requirements (NFRs)

> Non‐functional requirements (NFRs) define the qualitative characteristics of the system. As in an animal, the NFRs describe strength, speed, and agility of the internal features of the animal. How fast can the animal move? How much weight can the animal carry?

> Any adverbial phrase can be an NFR.


NFRs: Examples> NFR1: The system must support 200 simultaneous usersin the Web application.

> NFR2: The process for completing any reservationactivity must take the average user no more than 10minutes to finish.

> NFR3: The capacity of reservation records could grow to2,600 per month.

> NFR4: The Web access should use the HTTPS transportlayer when critical customer information is beingcommunicated.

> NFR5: The numerical accuracy of all financial calculations(for example, reports and customer receipts) shouldfollow a 2‐significant‐digit precision with standardrounding of intermediate results.

30.10.2011

74


NFRs: Examples

> NFR6: The System must be available “7 by 24 by 365”.However, the applications can be shut down formaintenance once a week for one hour. This maintenanceactivity should be scheduled between 3 a.m. and 6 a.m.

> NFR7: Based on historical evidence, there areapproximately 600 reservations per month pe property.

> NFR8: The search for available rooms must take no longerthan 30 seconds.


Glossary of Terms

> The Glossary of Terms defines business or IT terms that will be used in the project.

> This is a living document, which should be appended withnew terms, or amended if a term is found to be incorrect or needs redefinition.

30.10.2011

75


Glossary of Terms: Examples


Description of a Use Case Form

> A Use Case form provides a tool to record the detailedanalysis of a single use case and its scenarios.

30.10.2011

76





30.10.2011

77



> Some methodologies recommend more or less analysis of the use cases. The Analysis workflow presented in this module tends to be more detailed.

> Use Case forms are not standard. There are different styles that can be used to create a Use Case form.


Creating a Use Case Form

Steps to determine the information for Use Case form:1. Determine a brief description from the primary

scenarios.2. Determine the actors who initiate and participate in this

use case from the Use Case diagrams.3. Determine the priority of this use case from discussions

with the stakeholders.4. Determine the risk from scenarios and from discussions

with the stakeholders.5. Determine the extension points from the Use Case

diagrams.6. Determine the pre‐conditions from the scenarios.7. Determine the trigger from the scenarios.

30.10.2011

78


Creating a Use Case Form

8. Determine the flow of events from the primary (happy)scenarios.

9. Determine the alternate flows from the secondary (sad)scenarios.

10. Determine the business rules from scenarios and fromdiscussions with stakeholders.

11. Determine the post‐conditions.

12. Determine the new NFRs from discussions withstakeholders.

13. Add notes for information—gathered from discussionswith stakeholders—that does not fit into the standardsections of the form.


Fill in Values for the Use Case Form

> Fill in elements derived from stakeholders and previousartifacts

30.10.2011

79





30.10.2011

80


Fill in Values for the Alternate Flow of Events

> Determine the alternate flows from the secondary scenarios and remaining primary scenarios:

> Perform a difference analysis between the scenario usedfor the main flow and each of the other scenarios (inturn).

> The alternate flows are the steps that are differentbetween the scenario used for the main flow and each of the other scenarios.



30.10.2011

81




Fill in Values for the Business Rules

30.10.2011

82

Appendix AImproving Requirement Quality

UML 2 & Use Case Models Improving Requirement Quality 164A

Objectives

When you complete this module, you should be able to:—Know the best practice when writing requirements—Avoid common pitfalls—Critique individual requirements

30.10.2011

83


Characteristics of a good requirement

Unique Individual Identified

Correct Complete

Consistent Clear Verifiable

Traceable Feasible

Positive Modular Design-free

UniqueIndividualIdentifiedCorrectCompleteConsistentClearVerifiableTraceableFeasiblePositiveModularDesign-free


r572

“The Internet user shall be able to access their current account balance in less than 5 seconds.”

The challenge is to seek out the user type, end result, and success measure in every requirement that you define.

User type Positive end resultPerformance criteria

Measurable

Anatomy of a good stakeholder requirement

30.10.2011

84


Writing pitfalls to avoid

… or …

… and so on

… shall include but not be limited to …

Example: “The pilot or co‐pilot shall also be able to hear or see a visible or audible caution or warning signal in case of emergency, hazard, and so on”

Improvements:

Ambiguity


Writing pitfalls to avoid (cont.)

Each requirement is a single sentence

Conjunctions

…and… , …or…. , …with… , …also…

Example: “The user shall be notified with a low battery warning lamp light when the voltage drops below 3.6 Volts and the current workspace or input data shall be saved.”

Improvements:

Ambiguity

30.10.2011

85



‘let out’ clauses

…if… , …but… , …when… , …except…

…unless… , …although….

Example: “The homeowner shall always hear the smoke detector alarm when smoke is detected unless the alarm is being tested or suppressed.”

Improvements:

Ambiguity



Long sentences

Arcane language

References to unreachable documents

Example: “Provided that the designated input signals from the specified devices are received by the user in the correct order where the system is able to differentiate the designators, the output signal shall comply with the required framework of section 3.1.5 to indicate the desired input state.”

Improvements:

Ambiguity

30.10.2011

86



Mix user, system, design, test, and installation

High-level mixed with database design, software terms, technical terms

Example: “The user shall be able to view the currently selected channel number, which shall be displayed in 14pt Swiss type on an LCD panel tested to Federal Regulation Standard 567‐89 and mounted with shockproof rubber washers.”

Improvements:

Ambiguity



Specify design envelope for level required

Name components, materials, software objects, fields, and records in stakeholder or system requirements

Example: “The antenna shall be capable of receiving FM signals, using a copper core with nylon covering and a waterproof hardened rubber shield”

Improvements:

Ambiguity

30.10.2011

87



Wish lists

Vague about which stakeholder is speaking

…usually… , …generally… , …often… , …normally… , …typically…

Example: “The alarm system will probably have to operate over normal phone lines.”

Improvements:

Ambiguity



Qualitative terms

User friendly, highly versatile, and flexible

To the maximum extent, approximately, as much as possible, with minimal impact.

Example: “The user shall be provided with a user‐friendly front‐end.”

Improvements:

Ambiguity

30.10.2011

88



Suggestions will be ignored by developers

May, might, should, ought, could, perhaps, or probably

Example: “The network manager may be provided with possible network contention points, and should instantaneously re‐route the traffic.”

Improvements:

Ambiguity



Ask for the impossible

100% reliable, safe, handles all failures, fully upgradeable, and runs on all platforms

Example: “The network manager shall handle all unexpected errors without crashing the system, and be fully capable of managing future network configurations.”

Improvements:

Ambiguity

30.10.2011

89

Appendix BPractical Exercise

UML 2 & Use Case Models Practical Exercise 178B

1. The ATM user shall be allowed to withdraw money and be able to make a payment to any outstanding loan.

2. The ATM user shall be allowed to withdraw up to the current account balance amount in the selected account, the maximum amount available for withdrawal, or up to the maximum line of credit for the account.

3. The ATM shall be able to display all prompts in the English language and other languages including, but not limited to, Spanish, French, and German.

4. The price of the ATM shall not exceed $30,000 and allow the maintainer to request a notification be posted to indicate to all ATM users that the system is about to become unavailable.

5. Often an ATM user may usually perform multiple transactions during a single account session.

30.10.2011

90


6. The ATM shall probably have to access the bank provider system to determine what transactions are valid for this user.

7. The ATM user may probably wish to make a payment on any outstanding loan.

8. The ATM shall be able to provide foolproof identification of all ATM users to prevent any unauthorized access to a user’s account.

9. The ATM user shall be able to view the current account balance after an update within 5 seconds.

10. The ATM shall notify the user of the closest ATM to the current unit in the event that the current unit is out of cash.


For each potential use case, determine whether it is a use case

Support IE7.0 Have system 100% available during regular business hours

Comply with SOX

Support English and Japanese

Place order

Withdraw cash from an ATMTransfer funds

Display error messages within 30 seconds

Make reservation

Login

Create customer user interfaceSupport LDAP authentication

30.10.2011

91


The primary Use Cases for the Sample Bank ATM


Supporting Use Cases for the Sample Bank ATM

Refill and Service the Machine

Configure the Machine

Check the Machine is in Working Order

ATM Engineer

Analyze System Performance

Reconcile Transaction Logs

Update System Configuration

ATM Operator

Run Advertising CompaignService

Administrator

30.10.2011

92


Kullanıcı

Öğretmen Öğrenci

<<actor>>Veritabanı

Sınıf listesigöster Derse kayıt

Danışman

Geç kayıt

<<extend>>

Öğrenci Otomasyon Sistemi

Sisteme giriş

<<include>> <<include>>

Appendix CLecture Notes in Turkish

30.10.2011

93

UML 2 & Use Case Models Lecture Notes in Turkish 185C

UML Nedir

> UML yazılım sisteminin önemli bileşenlerini tanımlamayı, tasarlamayı ve dokümantasyonunu sağlayan grafiksel bir modelleme dilidir

> Yazılım geliştirme sürecindeki tüm katılımcıların (kullanıcı, iş çözümleyici, sistem çözümleyici, tasarımcı, programcı,...) gözüyle modellenmesine olanak sağlar,

> UML gösterimi nesneye dayalı yazılım mühendisliğine dayanır.


2

0

1 dxx

C

Ortak bir dil

> Tüm mühendisler simgesinin anlamını bilir

> Simge basit olsada arkasındaki anlam karmaşık ve derindir!

> : Ters sekiz?> Kapasite?

30.10.2011

94


UML’in Kazanımları

> Yazılım sistemi herhangi bir kod yazmadan önce profesyonelce tasarlanır ve dokümantasyonu yapılır

> Yeniden kullanılabilir kod parçaları kolaylıkla ayırt edilir ve en yüksek verimle kodlanır

> Daha düşük geliştirme maliyeti

> Tasarımdaki mantıksal boşluklar tasarım çizimlerinde kolaylıkla saptanabilir


> Daha az sürpriz – yazılımlar beklendiğimiz şekilde davranırlar

> Overall design will dictate the way software is developed – tüm tasarım kararları kod yazmadan verilir

> UML “resmin tamamını” görmemizi sağlar

> More memory and processor efficient code is developed

> Sistemde değişiklik yapmayı kolaylaştırır

UML’in Kazanımları─2

30.10.2011

95


UML’in Kazanımları─3

> Less ‘re/learning’ of the system takes place

> Diagrams will quickly get any other developer up to speed

> Programcılar arasında daha etkin bir iletişime olanak sağlar


UML’in Geliştirme Sürecindeki Yeri

> Three Amigos UML’i geliştirirken, dilin belirli bir süreç modeline bağlı olmamasına özen gösterdiler.

> Farklı süreç modelleri: RUP, Shlaer‐Mellor, CRC ve Extreme Programming kullanılabilir.

> RUP : Three Amigos tarafından geliştirildi.

> Derste RUP’u inceleyeceğiz

> Bu nedenle UML farklı yazılım projelerine cevap verebilecek genelliğe sahiptir:

E‐Ticaret Uygulaması × Askeri Uygulamalar

Dokümantasyon, Sınama, Performans

> UML nasıl yazılım geliştirileceğini söylemez!

30.10.2011

96


Hatırlatma

> “Süreç Yönetimi” konusuna kısa bir geri dönüş yapalım:

> Şelale Modeli

> V‐Modeli

> Spiral Model

> Artımsal ve Yinelemeli Modeller


Big‐Bang Etkisi

• “Küçük” projeler için uygun• Birkaç aylık projeler

Şelale Modeli

30.10.2011

97


Risk

Hatayı DüzeltmeninMaliyeti

Zaman

Şelale Modelinin Yitimleri


Spril Model

30.10.2011

98


Spiral Modelin Kazanımları

> Takım yazılım yaşam çevriminin tüm aşamalarına katılır,

> Kısa sürede ve düzgün aralıklarla geri besleme alınır,

> Riskli bileşenler önceden kestirilebilir ve gerçeklenebilir,

> İşin ölçeği ve karmaşıklığı önceden keşfedilebilir,

> Çalışan bir sürümün varlığı takımın moralini yüksek tutar,

> Projenin durumu daha kesin olarak değerlendirilebilir.


RUP

> RUP yinelemli, artımsal, mimari merkezli, risk güdümlü, kullanım senaryolarına dayalı bir yazılım geliştirme süreci modelidir.

> RUP iyi tanımlanmış ve yapılandırılmış bir yazılım sürecidir:Kimin Neden sorumlu olduğu, işlerin Nasıl ve Ne Zaman yapılacağı açıkça tanımlanır.

30.10.2011

99


Customer

(f rom Actors)

Barrow Book

(from <Use Case Name>)

aktör

Kullanım Senaryosu Şeması

> Kullanım senaryosu şeması, tasarlanacak sisteme kullanıcı gözüyle bakıldığındaki davranışını tanımlar.

> Şemanın anlaşılması oldukça kolaydır.

> [Bu nedenle] Hem geliştirme ekibinin hem de müşterinin ortak olarak çalışabileceği bir şemadır.

> Analizde yardımcı olur, tasarımda isteklerin anlaşılmasında yardımcı olur.


Kullanım Senaryosu Şemasının Bileşenleri

30.10.2011

100


Start Up


Shutdown

(from <Use Case Na me >)

Operator

(f rom Actors)

Produce Report


Order System

(f rom Actors)View Order Status


> Bir aktör birden fazla kullanım senaryosunda yer alabilir

> Aynı senaryoda birden fazla aktör olabilir.

Kullanım Senaryosu Şeması


> Aktör eylemi başlatan nesnedir.

> Aktör nesnesi mutlaka bir kişi olmak zorunda değil.

> Soyut bir nesne olabilir: zaman, tarih, ...

> Aktör sistemin dışından bir nesne olabilir

> Kullanılan Simge:

Operator

(f rom Actors)

> Her aktör en az bir senaryo ile ilişkilendirilmelidir:

Operator

(f rom Actors)

Start Up


Shutdown


Produce Report


Actor

30.10.2011

101


Kullanım Senaryolarının Sağladığı Kazanımlar

> Sistemin erimini, sınırlarını belirler.

> Böylelikle geliştirilecek sistemin boyutunu ve karmaşıklığını kafamızda daha rahat canlandırabiliriz.

> Kullanım senaryoları isteklerin çözümlenmesine çok benzemektedir: daha nettir ve tamdır.

> Basit oluşu müşteri ile geliştirme ekibi arasında iletişime olanak tanır.

> Geliştirme aşaması için temel oluşturur.

> Sistem testi için temel oluşturur.

> Kullanıcı klavuzu hazırlamaya yardımcı olur.


Enter PIN


Confirm Amount


Select Amount


Enter Card


Take Receipt


Customer

(f rom Actors)

Remove Card


Çözünürlük Ne Olmalı?

> Kullanım senaryosunun kullanımına ilişkin bir örnek: ATM cihazından para çekmek

30.10.2011

102


Withdraw Money


Customer

(f rom Actors)

Amaç: para çekmek

Çözüm

> Kullanım senaryosu, aktör için bir amacı yerine getirmelidir.


Withdraw Money


Trans fer Money

(f rom <Use Case Name>)

Check Balance


Customer

(f rom Actors)

30.10.2011

103


Kullanım Senaryoları Arası İlişkiler

> Kullanım senaryoları arasında üç tür ilişki bulunabilir

> İçerme «include»

Bir senaryo grubu içinde kullanılan başka bir senaryo grubudur

> Genişletme «extend»

Senaryo grupları doğal akışa göre verilirler. Bu akıştan olan sapmalar genişletme ilişkisi ile ana senaryodan olan sapma gösterilir.

> Genelleştirme

Sınıflar arasındaki türeme ilişkisine benzer. Genel bir senaryo grubundan özel bir senaryo grubu türetilir.


Withdraw Money


Update Account


<<include>>

Withdraw Money with Overdraft Protection


Protect Overdraft

(f rom <Use Case Name>)

Custom er

(f rom Actors)

<<extend>>

Örnek Kullanım Senaryosu

30.10.2011

104


Kullanım Senaryosu Anlatımı1. Müşteri kartını ATM cihazına tanıtır. Sistem karttaki bilgileri okur ve doğrular.

2. Sistem PIN kodunu sorar. Müşteri PIN kodunu girer. Sistemi PIN kodunu doğrular.

3. Sistem hangi tür işlem yapmak istediğini sorar. Müşteri “Para Çek“’i seçer

4. Sistem çekilecek miktarı sorar. Müşteri miktarı girer.

5. Sistem hesap türünü sorar. Müşteri hesap türünü girer.

6. Sistem ATM ağını kullanarak kimlik, PIN kodu ve çekilen miktarı doğrular.

7. Sistem makbuz istenip istenmediğini sorar. Bu işlem cihazda kağıt varsa yürütülür.

8. Sistem müşteriden kartı yuvasından almasını ister. Müşteri kartını alır. (Bu istek müşterinin kartı cihazda unutmadığından emin olmak için güvenlik amacıyla yapılır.)

9. Sistem istenilen miktar banknotu verir .

10.Eğer müşteri istemişse sistem kağıt makbuzu verir. Senaryo sona erer.


Senaryo: Senaryo adı Özet tanıtım: Senaryonun kısa bir tanımlaması Ön koşullar: Senaryonun başlaması için sağlanması gereken koşullar Sonuç koşulları: Senaryonun sonunda neler olduğu tanımlanır Ana Akış: Sistem için olağan senaryo durumunda gerçekleşen etkileşimlerin bir listesi verilir. Alternatif Akış: Olası alternatif etkileşimlerin tanımlanması Sıradışı Akış: Beklenmeyen yada öngörülmeyen olayların gerçekleştiği senaryolar tanımlanır

Kullanım Senaryosu Anlatımı

►Standart bir format yok.

►Her firma kendine uygun bir format belirleyebilir.

30.10.2011

105


Kullanım Senaryolarının Yazılması

Aktörlerin Belirlenmesi:

– Sistemin temel işlevlerini kim kullanacak?

– Sistemin bakımını ve işletimini kim yapacak?

– Sistem hangi cihazları kullanacak?

– Diğer hangi sistemlerle etkileşimde bulunacak?

– Sistemin çıkışlarını kimleri ilgilendirir?


Sistem Davranışının Belirlenmesi

►Aktörlerden yararlanarak sistem davranışının belirlenmesi

– Aktörlerin temel işlevi nedir?

– Aktör sistem bilgilerine erişmeli mi?

– Durum değişiklikleri aktöre bildirilecek mi?

– Aktör hangi işlevlere ihtiyaç duyar?

►Bazı davranışlar aktörlerden yola çıkarak belirlenemeyebilir. Bu durumda aşağıdaki soruları da sormak uygun olur:

– Sistemin gerek duyduğu giriş ve çıkış nedir?

– Sistem dış olaylardan etkilenir?

– Şu andaki sistemin eksiklikleri ve problemleri nelerdir?

– Periyodik olarak gerçekleştirilen işlemler var mı?

30.10.2011

106


Kullanım Senaryolarının Saptanması

►Olası sistem kullanıcıları ile görüşme yapmak

►Joint Requirements Planning Workshop (JRP)

– Beyinfırtınası: olası tüm aktörler saptanır

– Beyinfırtınası: olası tüm senaryolar saptanır

– Her senaryo için Kullanım Senaryo Anlatımı kağıda aktarılır ve doğrulanır

– Model CASE Tool kullanılarak bilgisayarda oluşturulur

UML 2 & Use Case Models - omegaegitim.com · UML 2 & Use Case Models 1 Modeling with UML 2 17...

Documents

Transcript of UML 2 & Use Case Models - omegaegitim.com · UML 2 & Use Case Models 1 Modeling with UML 2 17...