Upload
others
View
19
Download
0
Embed Size (px)
Citation preview
30.10.2011
1
UML 2 &Use Case Models
Binnur Kurt, Ph.D.Omega Training and Consultancywww.omegaegitim.com
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
UML 2 & Use Case Models 3
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
UML 2 & Use Case Models 4
References – UML2
30.10.2011
3
UML 2 & Use Case Models 5
References – UML2, Use Cases
UML 2 & Use Case Models 6
References –Use Cases
30.10.2011
4
UML 2 & Use Case Models 7
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).
UML 2 & Use Case Models 8
> 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
UML 2 & Use Case Models Modeling with UML 2 111
Software Complexity is increasing
UML 2 & Use Case Models Modeling with UML 2 121
And things are only going to get worse
> Increasingly complex, vulnerable and every changing platforms, applications and customer desires.
30.10.2011
7
UML 2 & Use Case Models Modeling with UML 2 131
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
UML 2 & Use Case Models Modeling with UML 2 141
OO Concepts
> Objects
> Classes
> Abstraction
> Encapsulation
> Inheritance
> Interfaces
> Polymorphism
> Cohesion
> Coupling
> Class associations and object links
> Delegation
30.10.2011
8
UML 2 & Use Case Models Modeling with UML 2 151
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)
UML 2 & Use Case Models Modeling with UML 2 161
Patterns
> Design Patterns – GoF Patterns
> Security Patterns
> Networking Patterns
> Concurrent, Parallel System Patterns
> Java EE Patterns
30.10.2011
9
UML 2 & Use Case Models Modeling with UML 2 171
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.
UML 2 & Use Case Models Modeling with UML 2 181
The OOSD Hierarchy
30.10.2011
10
UML 2 & Use Case Models Modeling with UML 2 191
Listing the Workflows of the OOSD Process
Software development has traditionally encompassed thefollowing workflows:
> Requirements Gathering
> Requirements Analysis
> Architecture
> Design
> Implementation
> Testing
> Deployment
UML 2 & Use Case Models Modeling with UML 2 201
Describing the Software Team Job Roles
30.10.2011
11
UML 2 & Use Case Models Modeling with UML 2 211
Describing the Software Team Job Roles
UML 2 & Use Case Models Modeling with UML 2 221
Exploring the Requirements GatheringWorkflow
30.10.2011
12
UML 2 & Use Case Models Modeling with UML 2 231
Activities and Artifacts of the RequirementsGathering Workflow
UML 2 & Use Case Models Modeling with UML 2 241
Exploring the Requirements AnalysisWorkflow
30.10.2011
13
UML 2 & Use Case Models Modeling with UML 2 251
Activities and Artifacts of the RequirementsAnalysis Workflow
UML 2 & Use Case Models Modeling with UML 2 261
Exploring the ArchitectureWorkflow
30.10.2011
14
UML 2 & Use Case Models Modeling with UML 2 271
Activities and Artifacts of the ArchitectureWorkflow
UML 2 & Use Case Models Modeling with UML 2 281
Exploring the DesignWorkflow
30.10.2011
15
UML 2 & Use Case Models Modeling with UML 2 291
Exploring the DesignWorkflow
UML 2 & Use Case Models Modeling with UML 2 301
Activities and Artifacts of the DesignWorkflow
30.10.2011
16
UML 2 & Use Case Models Modeling with UML 2 311
Exploring the Implementation, Testing, andDeployment Workflows
UML 2 & Use Case Models Modeling with UML 2 321
Exploring the Implementation, Testing, andDeployment Workflows
30.10.2011
17
UML 2 & Use Case Models Modeling with UML 2 331
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.
UML 2 & Use Case Models Modeling with UML 2 341
Activities and Artifacts of theImplementation, Testing, and DeploymentWorkflows
30.10.2011
18
UML 2 & Use Case Models Modeling with UML 2 351
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.
UML 2 & Use Case Models Modeling with UML 2 361
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
UML 2 & Use Case Models Modeling with UML 2 371
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.
UML 2 & Use Case Models Modeling with UML 2 381
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
UML 2 & Use Case Models Modeling with UML 2 391
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.
UML 2 & Use Case Models Modeling with UML 2 401
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
UML 2 & Use Case Models Modeling with UML 2 411
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
UML 2 & Use Case Models Modeling with UML 2 421
Summary: Business Process Management
X
Systems People Information
Process
Strategy Goals Policies
30.10.2011
22
UML 2 & Use Case Models Modeling with UML 2 431
Elements of a BPMN Business Process Model
Sequence FlowEvent
Task
Gateway
Start Activity1
Activity2
UserTask
End
UML 2 & Use Case Models Modeling with UML 2 441
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
UML 2 & Use Case Models Modeling with UML 2 451
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
UML 2 & Use Case Models Modeling with UML 2 461
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 2 & Use Case Models Modeling with UML 2 471
UML Elements
UML 2 & Use Case Models Modeling with UML 2 481
UML Diagrams
30.10.2011
25
UML 2 & Use Case Models Modeling with UML 2 491
UML Diagram Categories
UML 2 & Use Case Models Modeling with UML 2 501
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
UML 2 & Use Case Models Modeling with UML 2 511
Packages and Notes
> Package
> Notes
UML 2 & Use Case Models Modeling with UML 2 521
Dependency and Stereotype
30.10.2011
27
UML 2 & Use Case Models Modeling with UML 2 531
What UML Is and Is Not
UML 2 & Use Case Models Modeling with UML 2 541
History of UML
30.10.2011
28
UML 2 & Use Case Models Modeling with UML 2 551
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.
UML 2 & Use Case Models Modeling with UML 2 561
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
UML 2 & Use Case Models Modeling with UML 2 571
The four‐layer architecture of UML
UML 2 & Use Case Models Modeling with UML 2 581
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
UML 2 & Use Case Models Modeling with UML 2 591
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
UML 2 & Use Case Models Modeling with UML 2 601
The metamodel of data types
30.10.2011
31
UML 2 & Use Case Models Modeling with UML 2 611
Overview of the UML diagrams
UML 2 & Use Case Models Modeling with UML 2 621
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
UML 2 & Use Case Models Modeling with UML 2 631
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.
UML 2 & Use Case Models Modeling with UML 2 641
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
UML 2 & Use Case Models Modeling with UML 2 651
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 2 & Use Case Models Modeling with UML 2 661
UML Standard Stereotypes
30.10.2011
34
UML 2 & Use Case Models Modeling with UML 2 671
UML Standard Stereotypes
UML 2 & Use Case Models Modeling with UML 2 681
Non‐Standard UML Stereotypes
30.10.2011
35
UML 2 & Use Case Models Modeling with UML 2 691
Non‐Standard UML Stereotypes
UML 2 & Use Case Models Modeling with UML 2 701
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
UML 2 & Use Case Models Modeling with UML 2 711
An Example:Dice Game
UML 2 & Use Case Models Modeling with UML 2 721
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
UML 2 & Use Case Models Modeling with UML 2 731
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.
UML 2 & Use Case Models Modeling with UML 2 741
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
UML 2 & Use Case Models Modeling with UML 2 751
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.
UML 2 & Use Case Models Modeling with UML 2 761
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
UML 2 & Use Case Models Modeling with UML 2 771
Define Interaction Diagrams
:DiceGame
play()
die1 : Die
fv1 := getFaceValue()
die2 : Die
roll()
roll()
fv2 := getFaceValue()
UML 2 & Use Case Models Modeling with UML 2 781
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
UML 2 & Use Case Models Creating Use Case Diagrams 812
Process Map
UML 2 & Use Case Models Creating Use Case Diagrams 822
Process Map
30.10.2011
42
UML 2 & Use Case Models Creating Use Case Diagrams 832
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.
UML 2 & Use Case Models Creating Use Case Diagrams 842
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
UML 2 & Use Case Models Creating Use Case Diagrams 852
Use cases drive software development
Implementedby
Implementation Model
Test ModelDesign Model
Use‐Case Model
UML 2 & Use Case Models Creating Use Case Diagrams 862
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
UML 2 & Use Case Models Creating Use Case Diagrams 872
> 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
UML 2 & Use Case Models Creating Use Case Diagrams 882
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
UML 2 & Use Case Models Creating Use Case Diagrams 892
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.
UML 2 & Use Case Models Creating Use Case Diagrams 902
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
UML 2 & Use Case Models Creating Use Case Diagrams 912
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.
UML 2 & Use Case Models Creating Use Case Diagrams 922
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
UML 2 & Use Case Models Creating Use Case Diagrams 932
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.
UML 2 & Use Case Models Creating Use Case Diagrams 942
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
UML 2 & Use Case Models Creating Use Case Diagrams 952
Creating the Initial Use Case Diagram
> 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.
UML 2 & Use Case Models Creating Use Case Diagrams 962
Creating the Initial Use Case Diagram
> 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
UML 2 & Use Case Models Creating Use Case Diagrams 972
Creating the Initial Use Case Diagram
UML 2 & Use Case Models Creating Use Case Diagrams 982
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
UML 2 & Use Case Models Creating Use Case Diagrams 992
Identifying additional Use Cases
> 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.
UML 2 & Use Case Models Creating Use Case Diagrams 1002
Identifying additional Use Cases
> 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
UML 2 & Use Case Models Creating Use Case Diagrams 1012
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
UML 2 & Use Case Models Creating Use Case Diagrams 1022
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
UML 2 & Use Case Models Creating Use Case Diagrams 1032
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
UML 2 & Use Case Models Creating Use Case Diagrams 1042
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
UML 2 & Use Case Models Creating Use Case Diagrams 1052
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:
UML 2 & Use Case Models Creating Use Case Diagrams 1062
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
UML 2 & Use Case Models Creating Use Case Diagrams 1072
Expanding High‐Level Use Cases
> The expanded diagram:
UML 2 & Use Case Models Creating Use Case Diagrams 1082
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
UML 2 & Use Case Models Creating Use Case Diagrams 1092
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.
UML 2 & Use Case Models Creating Use Case Diagrams 1102
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
UML 2 & Use Case Models Creating Use Case Diagrams 1112
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).
UML 2 & Use Case Models Creating Use Case Diagrams 1122
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
UML 2 & Use Case Models Creating Use Case Diagrams 1132
The «include» Dependency
> An include relationship is used to integrate a use case into another use case, thus becoming a logical part of that use case.
UML 2 & Use Case Models Creating Use Case Diagrams 1142
The «include» Dependency
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
UML 2 & Use Case Models Creating Use Case Diagrams 1152
The «include» Dependency
Identifying behavior associated with a secondary actor:
> Review the use case scenarios for significant behavior that involves a secondary actor.
UML 2 & Use Case Models Creating Use Case Diagrams 1162
The «include» Dependency
> 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
UML 2 & Use Case Models Creating Use Case Diagrams 1172
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:
UML 2 & Use Case Models Creating Use Case Diagrams 1182
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
UML 2 & Use Case Models Creating Use Case Diagrams 1192
A Combined Example
UML 2 & Use Case Models Creating Use Case Diagrams 1202
«extend» or «include»
30.10.2011
61
UML 2 & Use Case Models Creating Use Case Diagrams 1212
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.
UML 2 & Use Case Models Creating Use Case Diagrams 1222
Packaging the Use Case Views
30.10.2011
62
UML 2 & Use Case Models Creating Use Case Diagrams 1232
Packaging the Use Case Views
> 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.
UML 2 & Use Case Models Creating Use Case Diagrams 1242
Packaging the Use Case 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
UML 2 & Use Case Models Creating Use Case Diagrams 1252
Packaging the Use Case Views
UML 2 & Use Case Models Creating Use Case Diagrams 1262
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
UML 2 & Use Case Models Creating UC Scenarios & Forms 1293
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...
UML 2 & Use Case Models Creating UC Scenarios & Forms 1303
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
UML 2 & Use Case Models Creating UC Scenarios & Forms 1313
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.
UML 2 & Use Case Models Creating UC Scenarios & Forms 1323
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
UML 2 & Use Case Models Creating UC Scenarios & Forms 1333
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.
UML 2 & Use Case Models Creating UC Scenarios & Forms 1343
The Two‐Column Variation
30.10.2011
68
UML 2 & Use Case Models Creating UC Scenarios & Forms 1353
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.
UML 2 & Use Case Models Creating UC Scenarios & Forms 1363
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
UML 2 & Use Case Models Creating UC Scenarios & Forms 1373
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.
UML 2 & Use Case Models Creating UC Scenarios & Forms 1383
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
UML 2 & Use Case Models Creating UC Scenarios & Forms 1393
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.
UML 2 & Use Case Models Creating UC Scenarios & Forms 1403
Primary Use Case Scenario: Example
> 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
UML 2 & Use Case Models Creating UC Scenarios & Forms 1413
Primary Use Case Scenario: Example
> 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.
UML 2 & Use Case Models Creating UC Scenarios & Forms 1423
Primary Use Case Scenario: Example
> 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
UML 2 & Use Case Models Creating UC Scenarios & Forms 1433
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.
UML 2 & Use Case Models Creating UC Scenarios & Forms 1443
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
UML 2 & Use Case Models Creating UC Scenarios & Forms 1453
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.
UML 2 & Use Case Models Creating UC Scenarios & Forms 1463
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
UML 2 & Use Case Models Creating UC Scenarios & Forms 1473
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.
UML 2 & Use Case Models Creating UC Scenarios & Forms 1483
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
UML 2 & Use Case Models Creating UC Scenarios & Forms 1493
Glossary of Terms: Examples
UML 2 & Use Case Models Creating UC Scenarios & Forms 1503
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
UML 2 & Use Case Models Creating UC Scenarios & Forms 1513
Description of a Use Case Form
UML 2 & Use Case Models Creating UC Scenarios & Forms 1523
Description of a Use Case Form
30.10.2011
77
UML 2 & Use Case Models Creating UC Scenarios & Forms 1533
Description of a Use Case Form
> 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.
UML 2 & Use Case Models Creating UC Scenarios & Forms 1543
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
UML 2 & Use Case Models Creating UC Scenarios & Forms 1553
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.
UML 2 & Use Case Models Creating UC Scenarios & Forms 1563
Fill in Values for the Use Case Form
> Fill in elements derived from stakeholders and previousartifacts
30.10.2011
79
UML 2 & Use Case Models Creating UC Scenarios & Forms 1573
Fill in Values for the Use Case Form
UML 2 & Use Case Models Creating UC Scenarios & Forms 1583
Fill in Values for the Use Case Form
30.10.2011
80
UML 2 & Use Case Models Creating UC Scenarios & Forms 1593
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.
UML 2 & Use Case Models Creating UC Scenarios & Forms 1603
Fill in Values for the Alternate Flow of Events
30.10.2011
81
UML 2 & Use Case Models Creating UC Scenarios & Forms 1613
Fill in Values for the Alternate Flow of Events
UML 2 & Use Case Models Creating UC Scenarios & Forms 1623
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
UML 2 & Use Case Models Improving Requirement Quality 165A
Characteristics of a good requirement
Unique Individual Identified
Correct Complete
Consistent Clear Verifiable
Traceable Feasible
Positive Modular Design-free
UniqueIndividualIdentifiedCorrectCompleteConsistentClearVerifiableTraceableFeasiblePositiveModularDesign-free
UML 2 & Use Case Models Improving Requirement Quality 166A
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
UML 2 & Use Case Models Improving Requirement Quality 167A
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
UML 2 & Use Case Models Improving Requirement Quality 168A
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
UML 2 & Use Case Models Improving Requirement Quality 169A
Writing pitfalls to avoid (cont.)
‘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
UML 2 & Use Case Models Improving Requirement Quality 170A
Writing pitfalls to avoid (cont.)
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
UML 2 & Use Case Models Improving Requirement Quality 171A
Writing pitfalls to avoid (cont.)
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
UML 2 & Use Case Models Improving Requirement Quality 172A
Writing pitfalls to avoid (cont.)
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
UML 2 & Use Case Models Improving Requirement Quality 173A
Writing pitfalls to avoid (cont.)
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
UML 2 & Use Case Models Improving Requirement Quality 174A
Writing pitfalls to avoid (cont.)
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
UML 2 & Use Case Models Improving Requirement Quality 175A
Writing pitfalls to avoid (cont.)
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
UML 2 & Use Case Models Improving Requirement Quality 176A
Writing pitfalls to avoid (cont.)
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
UML 2 & Use Case Models Practical Exercise 179B
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.
UML 2 & Use Case Models Practical Exercise 180B
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
UML 2 & Use Case Models Practical Exercise 181B
The primary Use Cases for the Sample Bank ATM
UML 2 & Use Case Models Practical Exercise 182B
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
UML 2 & Use Case Models Practical Exercise 183B
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.
UML 2 & Use Case Models Lecture Notes in Turkish 186C
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 2 & Use Case Models Lecture Notes in Turkish 187C
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
UML 2 & Use Case Models Lecture Notes in Turkish 188C
> 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 2 & Use Case Models Lecture Notes in Turkish 189C
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 2 & Use Case Models Lecture Notes in Turkish 190C
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
UML 2 & Use Case Models Lecture Notes in Turkish 191C
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
UML 2 & Use Case Models Lecture Notes in Turkish 192C
Big‐Bang Etkisi
• “Küçük” projeler için uygun• Birkaç aylık projeler
Şelale Modeli
30.10.2011
97
UML 2 & Use Case Models Lecture Notes in Turkish 193C
Risk
Hatayı DüzeltmeninMaliyeti
Zaman
Şelale Modelinin Yitimleri
UML 2 & Use Case Models Lecture Notes in Turkish 194C
Spril Model
30.10.2011
98
UML 2 & Use Case Models Lecture Notes in Turkish 195C
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.
UML 2 & Use Case Models Lecture Notes in Turkish 196C
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
UML 2 & Use Case Models Lecture Notes in Turkish 197C
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.
UML 2 & Use Case Models Lecture Notes in Turkish 198C
Kullanım Senaryosu Şemasının Bileşenleri
30.10.2011
100
UML 2 & Use Case Models Lecture Notes in Turkish 199C
Start Up
(from <Use Case Name>)
Shutdown
(from <Use Case Na me >)
Operator
(f rom Actors)
Produce Report
(from <Use Case Na me >)
Order System
(f rom Actors)View Order Status
(from <Use Case Na me >)
> Bir aktör birden fazla kullanım senaryosunda yer alabilir
> Aynı senaryoda birden fazla aktör olabilir.
Kullanım Senaryosu Şeması
UML 2 & Use Case Models Lecture Notes in Turkish 200C
> 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
(from <Use Case Name>)
Shutdown
(from <Use Case Name>)
Produce Report
(from <Use Case Name>)
Actor
30.10.2011
101
UML 2 & Use Case Models Lecture Notes in Turkish 201C
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.
UML 2 & Use Case Models Lecture Notes in Turkish 202C
Enter PIN
(from <Use Case Name>)
Confirm Amount
(from <Use Case Name>)
Select Amount
(from <Use Case Name>)
Enter Card
(from <Use Case Name>)
Take Receipt
(from <Use Case Name>)
Customer
(f rom Actors)
Remove Card
(from <Use Case Name>)
Çö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
UML 2 & Use Case Models Lecture Notes in Turkish 203C
Withdraw Money
(from <Use Case Name>)
Customer
(f rom Actors)
Amaç: para çekmek
Çözüm
> Kullanım senaryosu, aktör için bir amacı yerine getirmelidir.
UML 2 & Use Case Models Lecture Notes in Turkish 204C
Withdraw Money
(from <Use Case Name>)
Trans fer Money
(f rom <Use Case Name>)
Check Balance
(from <Use Case Name>)
Customer
(f rom Actors)
30.10.2011
103
UML 2 & Use Case Models Lecture Notes in Turkish 205C
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.
UML 2 & Use Case Models Lecture Notes in Turkish 206C
Withdraw Money
(from <Use Case Name>)
Update Account
(from <Use Case Name>)
<<include>>
Withdraw Money with Overdraft Protection
(from <Use Case Name>)
Protect Overdraft
(f rom <Use Case Name>)
Custom er
(f rom Actors)
<<extend>>
Örnek Kullanım Senaryosu
30.10.2011
104
UML 2 & Use Case Models Lecture Notes in Turkish 207C
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.
UML 2 & Use Case Models Lecture Notes in Turkish 208C
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
UML 2 & Use Case Models Lecture Notes in Turkish 209C
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?
UML 2 & Use Case Models Lecture Notes in Turkish 210C
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
UML 2 & Use Case Models Lecture Notes in Turkish 211C
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