Diese Präsentation wurde erfolgreich gemeldet.
Wir verwenden Ihre LinkedIn Profilangaben und Informationen zu Ihren Aktivitäten, um Anzeigen zu personalisieren und Ihnen relevantere Inhalte anzuzeigen. Sie können Ihre Anzeigeneinstellungen jederzeit ändern.
Analysis Model
A Bridge
2
system
description
analysis
model
design
model
Writing the Software Specification
Everyone knew exactly what
ha...
Elements of the Analysis Model
Elements of the Analysis Model
Contd.
4
Use case text
Use case diagrams
Activity diagrams
Swim lane diagrams
Scenario-base...
Elements of the Analysis Model
Contd.
• Flow-oriented modeling – provides an indication of how data objects are
transforme...
Overall Objectives of Analysis
Model
• Three primary objectives
– To describe what the customer requires
– To establish a ...
Scenario-based Modeling
Textual Use Cases
• Use cases are a type of textual requirements
specification that capture how a user will interact with ...
Use cases elements
Use cases contain the following elements:
Name – A clear verb-noun descriptor that communicates the sco...
Use cases elements contd.
Basic Flow – The set of steps the actors take to
accomplish the goal of the use case. A clear de...
Golden Rule of Use-Case Names
• Each use case should have a name that indicates what value
(or goal) is achieved by the ac...
Use Case Name Examples
• Excellent - Purchase Concert Ticket
• Very Good - Purchase Concert Tickets
• Good - Purchase Tick...
Types of Actors
• Primary Actor
– Has goals to be fulfilled by system
• Supporting/Secondary Actor
– Provides service to t...
Descriptive Use-Case
UC-ID: 001
Use-case Name: Login
Goal: Librarian has to login the system to perform different transact...
15
USE CASE : Process Sale
(FULLY DRESSED VERSION)
• Primary Actor: Cashier
• Stakeholders and Interests:
 Cashier: Wants...
Main success scenario (or basic flow):
Actor Action System Response
1.The Customer arrives at a POS checkout
with items to...
17
Use case (contd…)
• Extensions (or alternative flows):
• Success Guarantee (Post conditions):
Sale is saved. Tax correc...
Use Case Diagram
19
Actor
• An actor is an idealized user
of a system.
• Actors can be users,
processes, and other
systems
• Many users can...
20
Non-human Actor
• Actors can be users,
processes, and other
systems.
• Show non human actors in
a different manner, usu...
21
Use Case
• A use case is a coherent unit of
externally visible functionality
provided by a system and
expressed by a se...
22
System
• A system is shown as a
rectangle, labeled with the
system name
• Actors are outside the
system
• Use cases are...
23
Association Relationship
• An association is the
communication path between an
actor and the use case that it
participa...
24
Relationships in Use Cases
• There are several Use
Case relationships:
• Association
• Extend
• Generalization
• Uses
•...
25
Extend Relationship
• Extend puts additional
behavior in a use case that
does not know about it.
• It is shown as a dot...
26
Use Case Generalization
• Generalization is a
relationship between a
general use case and a
more specific use case that...
27
Uses Relationship
• When a use case uses
another process, the
relationship can be shown
with the uses relationship
• Th...
28
Include Relationship
• Include relationships insert
additional behavior into a
base use case
• They are shown as a
dott...
29
Use Case Example: Alarm Clock
This is a contrived
example, to show
many relations.
Your diagrams
should be simpler.
31
Overview
• A use case
diagram
identifies
transactions
between actors
and a system as
individual use
cases
Final use case (1)
Nächste SlideShare
Wird geladen in …5
×

Final use case (1)

use case

  • Loggen Sie sich ein, um Kommentare anzuzeigen.

  • Gehören Sie zu den Ersten, denen das gefällt!

Final use case (1)

  1. 1. Analysis Model
  2. 2. A Bridge 2 system description analysis model design model Writing the Software Specification Everyone knew exactly what had to be done until someone wrote it down!
  3. 3. Elements of the Analysis Model
  4. 4. Elements of the Analysis Model Contd. 4 Use case text Use case diagrams Activity diagrams Swim lane diagrams Scenario-based modeling Class diagrams Analysis packages CRC models Collaboration diagrams Class-based modeling Data structure diagrams Data flow diagrams Control-flow diagrams Processing narratives Flow-oriented modeling State diagrams Sequence diagrams Behavioral modeling Structured AnalysisObject-oriented Analysis
  5. 5. Elements of the Analysis Model Contd. • Flow-oriented modeling – provides an indication of how data objects are transformed by a set of processing functions • Scenario-based modeling – represents the system from the user's point of view • Class-based modeling – defines objects, attributes, and relationships • Behavioral modeling – depicts the states of the classes and the impact of events on these states 5
  6. 6. Overall Objectives of Analysis Model • Three primary objectives – To describe what the customer requires – To establish a basis for the creation of a software design – To define a set of requirements that can be validated once the software is built • All elements of an analysis model are directly traceable to parts of the design model, and some parts overlap. 6
  7. 7. Scenario-based Modeling
  8. 8. Textual Use Cases • Use cases are a type of textual requirements specification that capture how a user will interact with a solution to achieve a specific goal. • They describe the step by step process a user goes through to complete that goal using a software system. • Use cases capture all the possible ways the user and system can interact that result in the user achieving the goal. • They also capture all the things that can go wrong along the way that prevent the user from achieving the goal.
  9. 9. Use cases elements Use cases contain the following elements: Name – A clear verb-noun descriptor that communicates the scope of the use case. Goal – A brief paragraph of text describing the scope of the use case. Actors – A list of the types of users who can engage in the activities described in the use case. Actor names should not correspond to job titles. – Primary Actor – Supporting Actor/ Secondary Actor – Off-Stage Actor / Secondary Actor Precondition/s – Anything the solution can assume to be true when the use case begins.
  10. 10. Use cases elements contd. Basic Flow – The set of steps the actors take to accomplish the goal of the use case. A clear description of what the system does in response to each user action. Alternate Flows – Capture the less common user/system interactions, such as being on a new computer and answering a security question. Exception Flows – The things that can happen that prevent the user from achieving their goal, such as providing an incorrect username and password. Post Condition/s – Anything that must be true when the use case is complete.
  11. 11. Golden Rule of Use-Case Names • Each use case should have a name that indicates what value (or goal) is achieved by the actor's interaction with the system • Here are some good questions to help you adhere to this rule: – Why would the actor initiate this interaction with the system? What goal does the actor have in mind when undertaking these actions? What value is achieved and for which actor? 11
  12. 12. Use Case Name Examples • Excellent - Purchase Concert Ticket • Very Good - Purchase Concert Tickets • Good - Purchase Ticket (insufficient detail) • Fair - Ticket Purchase (passive) • Poor - Ticket Order (system view, not user) • Unacceptable - Pay for Ticket (procedure, not process) 12
  13. 13. Types of Actors • Primary Actor – Has goals to be fulfilled by system • Supporting/Secondary Actor – Provides service to the system • Offstage Actor/Secondary – Interested in the behavior, but no contribution • In diagrams, Primary actors go on the left and others on the right. 13
  14. 14. Descriptive Use-Case UC-ID: 001 Use-case Name: Login Goal: Librarian has to login the system to perform different transactions Primary Actor: Librarian Secondary Actor: University, Student Pre-condition: System is working properly Main Success Scenario: Post condition: Librarian is able to perform different other transactions. Actor Action System Response 1. User enters user name. 2. User enters password. 3. System validates the username and password.
  15. 15. 15 USE CASE : Process Sale (FULLY DRESSED VERSION) • Primary Actor: Cashier • Stakeholders and Interests:  Cashier: Wants accurate and fast entry, no payment errors, …  Salesperson: Wants sales commissions updated. … • Preconditions: Cashier is identified and authenticated.
  16. 16. Main success scenario (or basic flow): Actor Action System Response 1.The Customer arrives at a POS checkout with items to purchase. 2.The cashier records the identifier for each item. If there is more than one of the same item, the Cashier can enter the quantity as well. 3.The system determines the item price and adds the item information to the running sales transaction. The description and the price of the current item are presented. 4.On completion of item entry, the Cashier indicates to the POS system that item entry is complete. 5.The System calculates and presents the sale total. 6.The Cashier tells the customer the total. The Customer gives a cash payment (“cash tendered”) possibly greater than
  17. 17. 17 Use case (contd…) • Extensions (or alternative flows): • Success Guarantee (Post conditions): Sale is saved. Tax correctly calculated.… Actor Action System Response If invalid identifier entered. Indicate error. If customer didn’t have enough cash cancel sales transaction.
  18. 18. Use Case Diagram
  19. 19. 19 Actor • An actor is an idealized user of a system. • Actors can be users, processes, and other systems • Many users can be one actor, in a common role. • One user can be different actors, based on different roles. • An actor is labeled with the name of the role
  20. 20. 20 Non-human Actor • Actors can be users, processes, and other systems. • Show non human actors in a different manner, usually as a rectangle • Non human actors are usually not primary users, and thus are usually shown on the right, not the left. Inventory System
  21. 21. 21 Use Case • A use case is a coherent unit of externally visible functionality provided by a system and expressed by a sequence of messages • Additional behavior can be shown with parent-child, extend and include use cases • It is labeled with a name that the user can understand
  22. 22. 22 System • A system is shown as a rectangle, labeled with the system name • Actors are outside the system • Use cases are inside the system • The rectangle shows the scope or boundary of the system Don’t forget the boundary and the system name, unless you are using Rational Rose!
  23. 23. 23 Association Relationship • An association is the communication path between an actor and the use case that it participates in • It is shown as a solid line • It does not have an arrow, and is normally read from left to right • Here, the association is between a Modeler and the Create Model use case
  24. 24. 24 Relationships in Use Cases • There are several Use Case relationships: • Association • Extend • Generalization • Uses • Include Most Use Cases have only associations. Use other relationships sparingly.
  25. 25. 25 Extend Relationship • Extend puts additional behavior in a use case that does not know about it. • It is shown as a dotted line with an arrow point and labeled <<extend>> • In this case, a customer can request a catalog when placing an order
  26. 26. 26 Use Case Generalization • Generalization is a relationship between a general use case and a more specific use case that inherits and extends features to it • It is shown as a solid line with a closed arrow point • Here, the payment process is modified for cash and charge cards
  27. 27. 27 Uses Relationship • When a use case uses another process, the relationship can be shown with the uses relationship • This is shown as a solid line with a closed arrow point and the <<uses>> keyword • Here different system processes can use the logon use case voucher
  28. 28. 28 Include Relationship • Include relationships insert additional behavior into a base use case • They are shown as a dotted line with an open arrow and the key word <<include>>
  29. 29. 29 Use Case Example: Alarm Clock This is a contrived example, to show many relations. Your diagrams should be simpler.
  30. 30. 31 Overview • A use case diagram identifies transactions between actors and a system as individual use cases

×