30.10.2011
UML 2 & Use Case Models
Binnur Kurt, Ph.D. Omega Training and Consultancy www.omegaegitim.com
UML 2 & Use Case Models 2 Agenda 1. Modeling with UML 2 and Software Development Process 2. Creating Use Case Diagrams 3. Creating Use Case Scenarios and Forms
1 30.10.2011
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
2 30.10.2011
UML 2 & Use Case Models 5 References – UML2, Use Cases
UML 2 & Use Case Models 6 References –Use Cases
3 30.10.2011
UML 2 & Use Case Models 7 Biography Dr. Binnur Kurt received BS, MS, and PhD degrees from Istanbul Technical University in 1995, 1997, 2007 all in computer engineering. He was a lecturer at the Computer Engineering Department of Istanbul Technical University from 2004 to 2007 and offered courses mostly on web programming and object oriented software engineering. He is currently working as an information technology consultant and trainer in Java Enterprise Technologies, Object Oriented Analysis and Design, Service Oriented Architecture, MySQL, Oracle Middleware Technologies, Unix Programming and Administration, High performance computing, and Real‐ Time Computer Vision systems. He has published many international conference and journal papers, and book chapters on these topics. He has also designed many IT trainings and written training materials on advanced topics, including Spring Framework, JSF, XML Web Services, Service Oriented Architecture, and OSGi. He holds several certifications, including Sun Certified Java Programmer, Oracle Certified Professional MySQL 5.0 Developer, Oracle Certified Professional MySQL 5.0 Database Administrator and Red Hat Certified Engineer. He is also referee for the assessment of industrial projects submitted to TUBITAK Technology and Innovation Funding Programs Directorate (TEYDEB) and inspector for industrial projects supported by TUBITAK Technology and Innovation Funding Programs Directorate (TEYDEB).
UML 2 & Use Case Models 8 Areas of Interest > Java Desktop and Enterprise Technologies > SOA > OOAD > MySQL > Oracle Directory Server > Application Servers: WebLogic, Glassfish, Tomcat
4 30.10.2011
1 Modeling with UML 2 and Software Development Process
UML 2 & Use Case Models 1 Modeling with UML 2 10 Software Complexity > The profile and importance of software has increased
5 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 11 Software Complexity is increasing
UML 2 & Use Case Models 1 Modeling with UML 2 12 And things are only going to get worse > Increasingly complex, vulnerable and every changing platforms, applications and customer desires.
6 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 13 Important Skills > These skills are essential for the creation of well‐designed, robust, and maintainable software
OOA/D
Patterns UML notation
Skills
Principles and Requirements guidelines analysis
Software Development Process Model > Apply principles and patterns to create better object designs. > Follow a set of common activities in analysis and design, based on the Unified Process as an example. > Create diagrams in the UML notation.
UML 2 & Use Case Models 1 Modeling with UML 2 14 OO Concepts > Objects > Classes > Abstraction > Encapsulation > Inheritance > Interfaces > Polymorphism > Cohesion > Coupling > Class associations and object links > Delegation
7 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 15 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 1 Modeling with UML 2 16 Patterns > Design Patterns –GoF Patterns > Security Patterns > Networking Patterns > Concurrent, Parallel System Patterns > Java EE Patterns
8 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 17 Describing Software Methodology
A methodology is “a body of methods, rules, and postulates employed by a discipline” [Webster New Collegiate Dictionary] > In OOSD, methodology refers to the highest‐level organization 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 to another. The output of one workflow becomes the input into the next. > The final artifact is a working software system that satisfies the initial artifacts: the system requirements.
UML 2 & Use Case Models 1 Modeling with UML 2 18 The OOSD Hierarchy
9 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 19 Listing the Workflows of the OOSD Process Software development has traditionally encompassed the following workflows: > Requirements Gathering > Requirements Analysis > Architecture > Design > Implementation > Testing > Deployment
UML 2 & Use Case Models 1 Modeling with UML 2 20 Describing the Software Team Job Roles
10 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 21 Describing the Software Team Job Roles
UML 2 & Use Case Models 1 Modeling with UML 2 22 Exploring the Requirements Gathering Workflow
11 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 23 Activities and Artifacts of the Requirements Gathering Workflow
UML 2 & Use Case Models 1 Modeling with UML 2 24 Exploring the Requirements Analysis Workflow
12 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 25 Activities and Artifacts of the Requirements Analysis Workflow
UML 2 & Use Case Models 1 Modeling with UML 2 26 Exploring the ArchitectureWorkflow
13 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 27 Activities and Artifacts of the Architecture Workflow
UML 2 & Use Case Models 1 Modeling with UML 2 28 Exploring the DesignWorkflow
14 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 29 Exploring the DesignWorkflow
UML 2 & Use Case Models 1 Modeling with UML 2 30 Activities and Artifacts of the Design Workflow
15 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 31 Exploring the Implementation, Testing, and Deployment Workflows
UML 2 & Use Case Models 1 Modeling with UML 2 32 Exploring the Implementation, Testing, and Deployment Workflows
16 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 33 Exploring the Benefits of Modeling Software > The inception of every software project starts as an idea in someone’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 1 Modeling with UML 2 34 Activities and Artifacts of the Implementation, Testing, and Deployment Workflows
17 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 35 What is a Model?
“A model is a simplification of reality.” (Booch UML User Guide page 6)
> Amodel 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 1 Modeling with UML 2 36 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
18 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 37 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 1 Modeling with UML 2 38 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.
Modeling Execution
Measurement
19 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 39 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 1 Modeling with UML 2 40 Real‐World Business Processes
Organizational Units Operations Sales and Manu‐ Finance and Marketing facturing HR
Order Management
Processes Product Configuration Warranty and Returns Management
Enterprise infrastructure services (portal, SOA, IDRS, LDAP, EAI, Email, IT operations)
20 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 41 Real‐World Business Process Management
Order Management Process
Operations Sales and Manu‐ Finance and Marketing facturing HR
Enterprise infrastructure services (portal, SOA, IDRS, LDAP, EAI, Email, IT operations)
UML 2 & Use Case Models 1 Modeling with UML 2 42 Summary: Business Process Management
Strategy Goals Policies
Process
X
Systems People Information
21 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 43 Elements of a BPMN Business Process Model
Gateway Task
UserTask
Start Activity1 End
Activity2
Event Sequence Flow
UML 2 & Use Case Models 1 Modeling with UML 2 44 OOSD as Model Transformations > Software development can be viewed as a series of transformations from the Stakeholder’s mental model to the actual code:
22 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 45 OOSD as Model Transformations
Book Book ‐title: String title +turnPage(int) Application domain Application domain model Software domain model public class Book { private String title; public void turnPage(int pn){...} }
UML 2 & Use Case Models 1 Modeling with UML 2 46 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 a model)
23 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 47 UML Elements
UML 2 & Use Case Models 1 Modeling with UML 2 48 UML Diagrams
24 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 49 UML Diagram Categories
UML 2 & Use Case Models 1 Modeling with UML 2 50 Common UML Elements and Connectors > UML has a few elements and connectors that are common across UML diagrams. These include: —Package —Note —Dependency —Stereotypes
25 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 51 Packages and Notes > Package
> Notes
UML 2 & Use Case Models 1 Modeling with UML 2 52 Dependency and Stereotype
26 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 53 What UML Is and Is Not
UML 2 & Use Case Models 1 Modeling with UML 2 54 History of UML
27 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 55 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 1 Modeling with UML 2 56 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.
28 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 57 The four‐layer architecture of UML
UML 2 & Use Case Models 1 Modeling with UML 2 58 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, . . .)
29 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 59 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 1 Modeling with UML 2 60 The metamodel of data types
30 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 61 Overview of the UML diagrams
UML 2 & Use Case Models 1 Modeling with UML 2 62 Stereotypes > Stereotypes are formal extensions of existing model elements within the UML metamodel, that is, metamodel extensions. > 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.
31 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 63 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 1 Modeling with UML 2 64 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.
32 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 65 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 1 Modeling with UML 2 66 UML Standard Stereotypes
33 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 67 UML Standard Stereotypes
UML 2 & Use Case Models 1 Modeling with UML 2 68 Non‐Standard UML Stereotypes
34 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 69 Non‐Standard UML Stereotypes
UML 2 & Use Case Models 1 Modeling with UML 2 70 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 design patterns, Java™ Platform, Enterprise Edition (Java™ EE platform) components, and so on
35 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 71
An Example: Dice Game
UML 2 & Use Case Models 1 Modeling with UML 2 72 An Example > Before diving into the details of requirements analysis and OOA/D, this section presents a birds‐eye view of a few key steps 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.
36 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 73 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 1 Modeling with UML 2 74 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.
37 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 75 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 are considered noteworthy.
UML 2 & Use Case Models 1 Modeling with UML 2 76 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.
38 30.10.2011
UML 2 & Use Case Models 1 Modeling with UML 2 77 Define Interaction Diagrams
:DiceGame die1 : Die die2 : Die
play() roll()
fv1 := getFaceValue()
roll()
fv2 := getFaceValue()
UML 2 & Use Case Models 1 Modeling with UML 2 78 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.
DiceGame Die
die1 : Die 1 2 faceValue : int die2 : Die getFaceValue() : int play() roll()
39 30.10.2011
2 Creating Use Case Diagrams
? ? ? ?
UML 2 & Use Case Models 2 Creating Use Case Diagrams 80
40 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 81 Process Map
UML 2 & Use Case Models 2 Creating Use Case Diagrams 82 Process Map
41 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 83 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—by modeling—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 of priority. > Use cases often have minimal dependencies, which enables a degree of independent development.
UML 2 & Use Case Models 2 Creating Use Case Diagrams 84 Use cases and other requirements FURPS Design constraints > Functionality > Operating systems > Usability > Environments > Reliability > Compatibility > Performance Use Cases > Application standards > Supportability Legal and regulatory requirements > Federal Communication Commission > Food and Drug Administration > Department of Defense > Canadian Standards Association > European Union Directive
42 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 85 Use cases drive software development
Use‐Case Model Implemented by
Design Model Test Model
Implementation Model
UML 2 & Use Case Models 2 Creating Use Case Diagrams 86 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).
43 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 87 Identifying the Elements of a Use Case Diagram > This diagram illustrates an alternate style that explicitly shows an association between the Receptionist actor (role) and the Manage Reservation use case.
UML 2 & Use Case Models 2 Creating Use Case Diagrams 88 Actors An actor: > Models a type of role that is external to the system and interacts 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 system may play the role of several different actors.
44 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 89 Actors
This icon represents a This icon can This icon represents human actor (user) of represent any actor, a time‐trigger the system. but is usually used to mechanism that represent external activates a use case. systems, devices, or time.
UML 2 & Use Case Models 2 Creating Use Case Diagrams 90 Actors
Dükkan
Müşteriye Satış Sistemi Vergi Dairesi Terminal (kasa) Amaç: Vergileri doğru toplamak Satış İnceleme Sistemi Kasa Görevlisi Müşteri
Amaç: Mal satın almak Amaç:Firmanın satış Amaç: Satışı yapmak Performansını belirlemek
45 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 91 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 but unambiguous verb‐noun pair. > A use case can often be UI independent.
UML 2 & Use Case Models 2 Creating Use Case Diagrams 92 System Boundary > The use cases may optionally be enclosed by a rectangle that represents the system boundary.
The system boundary This equivalent Use Case box is optional. diagram shows the system boundary for clarity.
46 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 93 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 no arrowheads. However, some UML tools use arrows by default.
UML 2 & Use Case Models 2 Creating Use Case Diagrams 94 Creating the Initial Use Case Diagram > One of the primary aims of the initial meeting with the project’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 the meeting from textual notes. > The next two slides present some text showing an abstract of the use‐case‐specific topics discussed during the meeting.
47 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 95 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 to amend 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 2 Creating Use Case Diagrams 96 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, afurther 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 areview 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.
48 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 97 Creating the Initial Use Case Diagram
UML 2 & Use Case Models 2 Creating Use Case Diagrams 98 Identifying additional Use Cases > During the meeting with the business owner, you will typically discover 10 to 20 percent of the use cases needed for the system. > During the meeting with the other stakeholders, you will discover 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
49 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 99 Identifying additional Use Cases > The time of discovery depends upon the development process. > In a non‐iterative process: —You ideally need to discover all of the remaining use case titles, bringing the total to 100 percent. —However, this is a resource‐intensive task and is rarely completely accurate.
UML 2 & Use Case Models 2 Creating Use Case Diagrams 100 Identifying additional Use Cases > In an iterative/incremental development process, an option is to: —Discover a total of 80 percent of the use case titles in the 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 to accommodate change.
50 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 101 Workflow of use case modeling
Iterate
Describe the Use Cases Seek Actors
Seek Use Cases
> 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
UML 2 & Use Case Models 2 Creating Use Case Diagrams 102 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.
51 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 103 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 2 Creating Use Case Diagrams 104 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
52 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 105 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 2 Creating Use Case Diagrams 106 Expanding High‐Level Use Cases > Typically, managing an entity implies being able to Create, (Retrieve), Update, and Delete an entity (so called, CRUD operations). Other keywords include: —Maintain —Process > Other high‐level use cases can occur. Identify these by analyzing the use case scenarios and look for significantly divergent flows. > If several scenarios have a different starting point, these scenarios might represent different use cases.
53 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 107 Expanding High‐Level Use Cases > The expanded diagram:
UML 2 & Use Case Models 2 Creating Use Case Diagrams 108 Analyzing Inheritance Patterns Inheritance can occur in Use Case diagrams for both actors and use cases: > An actor can inherit all of the use case associations from the parent actor. > A use case can be subclassed into multiple, specialized use cases.
54 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 109 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 2 Creating Use Case Diagrams 110 Use Case Specialization A use case can be subclassed into multiple, specialized use cases:
> Use case specializations are usually identified by significant variations in the use case scenarios. > If the base use case cannot be instantiated, you must mark it as abstract.
55 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 111 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 the behavior 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 2 Creating Use Case Diagrams 112 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:
56 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 113 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 2 Creating Use Case Diagrams 114 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 Case diagram with an «include» dependency.
57 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 115 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 2 Creating Use Case Diagrams 116 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.
58 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 117 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 2 Creating Use Case Diagrams 118 The «extend» Dependency Identifying and recording behaviors associated with an alternate 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 Case diagram with a «extend» dependency.
59 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 119 A Combined Example
UML 2 & Use Case Models 2 Creating Use Case Diagrams 120 «extend» or «include»
60 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 121 Packaging the Use Case Views > It should be apparent that any non‐trivial software development would need more use cases than could be viewed at one time. Therefore, you need to be able to manage this complexity. > One way of managing this complexity is to break down the use cases into packages.
UML 2 & Use Case Models 2 Creating Use Case Diagrams 122 Packaging the Use Case Views
61 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 123 Packaging the Use Case Views > You can look inside each package to reveal the detailed content. > A use case element may exist in multiple packages, where it participates in multiple views.
UML 2 & Use Case Models 2 Creating Use Case Diagrams 124 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).
62 30.10.2011
UML 2 & Use Case Models 2 Creating Use Case Diagrams 125 Packaging the Use Case Views
UML 2 & Use Case Models 2 Creating Use Case Diagrams 126 The Metamodel for Use cases and Actors
63 30.10.2011
3 Creating Use Case Scenarios and Forms
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 128 Process Map
64 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 129 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 INSERT statement for the sale...
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 130 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 success guarantees.
65 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 131 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 3 Creating UC Scenarios & FormsAnaly132sis P 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
66 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 133 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 3 Creating UC Scenarios & Forms 134 The Two‐Column Variation
67 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 135 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 3 Creating UC Scenarios & Forms 136 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 (in different scenarios) > Use Case scenarios drive several other OOAD workflows.
68 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 137 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 the actor. —The use case has several potential failure points, such as 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 3 Creating UC Scenarios & Forms 138 Writing a Use Case Scenario A Use Case scenario is a story that: > Describes how an actor uses the system and how the system responds to the actions of the actor. > Has a beginning, a middle, and an end.
69 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 139 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 3 Creating UC Scenarios & Forms 140 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.
70 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 141 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 3 Creating UC Scenarios & Forms 142 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.
71 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 143 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 3 Creating UC Scenarios & Forms 144 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 a Supplementary Specification Document, which often contains: —NFRs —Project Risks —Project Constraints —Glossary of Terms
72 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 145 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 3 Creating UC Scenarios & Forms 146 NFRs: Examples > NFR1: The system must support 200 simultaneous users in the Web application. > NFR2: The process for completing any reservation activity must take the average user no more than 10 minutes to finish. > NFR3: The capacity of reservation records could grow to 2,600 per month. > NFR4: The Web access should use the HTTPS transport layer when critical customer information is being communicated. > NFR5: The numerical accuracy of all financial calculations (for example, reports and customer receipts) should follow a 2‐significant‐digit precision with standard rounding of intermediate results.
73 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 147 NFRs: Examples > NFR6: The System must be available “7 by 24 by 365”. However, the applications can be shut down for maintenance once a week for one hour. This maintenance activity should be scheduled between 3 a.m. and 6 a.m. > NFR7: Based on historical evidence, there are approximately 600 reservations per month pe property. > NFR8: The search for available rooms must take no longer than 30 seconds.
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 148 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 with new terms, or amended if a term is found to be incorrect or needs redefinition.
74 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 149 Glossary of Terms: Examples
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 150 Description of a Use Case Form
> A Use Case form provides a tool to record the detailed analysis of a single use case and its scenarios.
75 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 151 Description of a Use Case Form
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 152 Description of a Use Case Form
76 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 153 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 3 Creating UC Scenarios & Forms 154 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.
77 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 155 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 from discussions with stakeholders. 11. Determine the post‐conditions. 12. Determine the new NFRs from discussions with stakeholders. 13. Add notes for information—gathered from discussions with stakeholders—that does not fit into the standard sections of the form.
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 156 Fill in Values for the Use Case Form > Fill in elements derived from stakeholders and previous artifacts
78 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 157 Fill in Values for the Use Case Form
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 158 Fill in Values for the Use Case Form
79 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 159 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 used for the main flow and each of the other scenarios (in turn). > The alternate flows are the steps that are different between the scenario used for the main flow and each of the other scenarios.
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 160 Fill in Values for the Alternate Flow of Events
80 30.10.2011
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 161 Fill in Values for the Alternate Flow of Events
UML 2 & Use Case Models 3 Creating UC Scenarios & Forms 162 Fill in Values for the Business Rules
81 30.10.2011
Appendix A Improving Requirement Quality
UML 2 & Use Case Models A Improving Requirement Quality 164 Objectives
When you complete this module, you should be able to: —Know the best practice when writing requirements —Avoid common pitfalls —Critique individual requirements
82 30.10.2011
UML 2 & Use Case Models A Improving Requirement Quality 165 Characteristics of a good requirement
Design-freeConsistentTraceableCompleteIndividualVerifiableIdentifiedFeasibleModularPositiveCorrectUniqueClear
Positive Modular Design-free
Traceable Feasible
Consistent Clear Verifiable
Correct Complete
Unique Individual Identified
UML 2 & Use Case Models A Improving Requirement Quality 166 Anatomy of a good stakeholder requirement User type Performance criteria Positive end result
“The Internet user shall be able to access their current account balance in less than 5 seconds.”
Measurable
The challenge is to seek out the user type, end result, and success measure in every requirement that you define.
r572
83 30.10.2011
UML 2 & Use Case Models A Improving Requirement Quality 167 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 A Improving Requirement Quality 168 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
84 30.10.2011
UML 2 & Use Case Models A Improving Requirement Quality 169 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 A Improving Requirement Quality 170 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 Improvements: required framework of section 3.1.5 to indicate the desired input state.”
Ambiguity
85 30.10.2011
UML 2 & Use Case Models A Improving Requirement Quality 171 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 A Improving Requirement Quality 172 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
86 30.10.2011
UML 2 & Use Case Models A Improving Requirement Quality 173 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 A Improving Requirement Quality 174 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
87 30.10.2011
UML 2 & Use Case Models A Improving Requirement Quality 175 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 A Improving Requirement Quality 176 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
88 30.10.2011
Appendix B Practical Exercise
UML 2 & Use Case Models B Practical Exercise 178
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.
89 30.10.2011
UML 2 & Use Case Models B Practical Exercise 179
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 B Practical Exercise 180 For each potential use case, determine whether it is a use case
Comply with SOX Support IE7.0 Have system 100% available during regular business hours
Support English and Japanese Display error messages within 30 Login seconds
Withdraw cash from an ATM Transfer funds Make reservation
Support LDAP authentication Place order Create customer user interface
90 30.10.2011
UML 2 & Use Case Models B Practical Exercise 181 The primary Use Cases for the Sample Bank ATM
UML 2 & Use Case Models B Practical Exercise 182 Supporting Use Cases for the Sample Bank ATM
Refill and Service the Machine ATM Engineer
Configure the Machine
Check the Machine is in Working Order
Analyze System Performance
ATM Operator Reconcile Transaction Logs
Update System Configuration
Run Advertising Compaign Service Administrator
91 30.10.2011
UML 2 & Use Case Models B Practical Exercise 183
Öğrenci Otomasyon <
Danışman <
Kullanıcı
Öğretmen Öğrenci
Appendix C Lecture Notes in Turkish
92 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 185 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 C Lecture Notes in Turkish 186 Ortak bir dil 1 dx x2 0 > Tüm mühendisler simgesinin anlamını bilir > Simge basit olsada arkasındaki anlam karmaşık ve derindir! > : Ters sekiz? > Kapasite?
C
93 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 187 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 C Lecture Notes in Turkish 188 UML’in Kazanımları─2
> 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
94 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 189 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 C Lecture Notes in Turkish 190 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!
95 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 191 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 C Lecture Notes in Turkish 192 Şelale Modeli
•“Küçük” projeler için uygun •Birkaç aylık projeler
Big‐Bang Etkisi
96 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 193 Şelale Modelinin Yitimleri
Risk
Hatayı Düzeltmenin Maliyeti
Zaman
UML 2 & Use Case Models C Lecture Notes in Turkish 194 Spril Model
97 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 195 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 C Lecture Notes in Turkish 196 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.
98 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 197 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.
Barrow Book Customer (from
UML 2 & Use Case Models C Lecture Notes in Turkish 198 Kullanım Senaryosu Şemasının Bileşenleri
99 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 199 Kullanım Senaryosu Şeması
> Bir aktör birden fazla kullanım
senaryosunda yer alabilir Start Up (from
Produce Report
(from
Order System
(f rom Ac t ors ) View Order Status
(from
UML 2 & Use Case Models C Lecture Notes in Turkish 200 Actor > 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:
Start Up
(from
Operator
(f rom Actors)
Shutdown > Her aktör en az bir senaryo ile Operator (fro m
Produce Report
(fro m
100 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 201 Kullanım SenaryolarınınSağ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 C Lecture Notes in Turkish 202 Çözünürlük Ne Olmalı? > Kullanım senaryosunun kullanımına ilişkin bir örnek: ATM cihazından para çekmek
Enter Card
(from
Enter PIN
(from
Remove Card Select Amount Customer (fro m
Confirm Amount
(fro m
(from
101 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 203 Çözüm > Kullanım senaryosu, aktör için bir amacı yerine getirmelidir.
Amaç: para çekmek
Withdraw Money Customer (from
UML 2 & Use Case Models C Lecture Notes in Turkish 204
Check Balance Withdraw Money Customer (from
Transfer Money
(from < Use Case Name>)
102 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 205 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 C Lecture Notes in Turkish 206 Örnek Kullanım Senaryosu
<
Withdraw Money Update Account
(from
Custom er <
(f rom Actors)
Withdraw Money with Overdraft Protect Overdraft Protection (from < Use Case Name>) (from
103 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 207 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 C Lecture Notes in Turkish 208 Kullanım Senaryosu Anlatımı ►Standart bir format yok. ►Her firma kendine uygun bir format belirleyebilir.
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
104 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 209 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 C Lecture Notes in Turkish 210 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ı?
105 30.10.2011
UML 2 & Use Case Models C Lecture Notes in Turkish 211 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
106