Analysis Model

2

A Bridge

system description

analysis model

design model

Writing the Software Specification

Everyone knew exactly what had to be done until someone wrote it down!

Elements of the Analysis Model

Elements of the Analysis Model Contd.

4

Use case textUse case diagramsActivity diagramsSwim lane diagrams

Scenario-basedmodeling

Class diagramsAnalysis packagesCRC modelsCollaboration diagrams

Class-basedmodeling

Data structure diagramsData flow diagramsControl-flow diagramsProcessing narratives

Flow-orientedmodeling

State diagramsSequence diagrams

Behavioralmodeling

Structured AnalysisObject-oriented Analysis

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

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

Scenario-based Modeling

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.

Use cases elementsUse 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.

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

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?

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)

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.

Descriptive Use-CaseUC-ID: 001Use-case Name: LoginGoal: Librarian has to login the system to perform different transactionsPrimary Actor: LibrarianSecondary Actor: University, StudentPre-condition: System is working properlyMain 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

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.

Main success scenario (or basic flow):

Actor Action System Response1.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 the sale total.

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.

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 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

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

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

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

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

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

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

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

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

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

Use Case Example: Alarm Clock

This is a contrivedexample, to showmany relations.Your diagrams

should be simpler.

31

Overview• A use case

diagram identifies transactions between actors and a system as individual use cases