-
Functional View
-
The challenge to the analyst is to identify the real functional requirements that will satisfy the real user's real business needs. The use case approach is an especially effective technique for deriving software requirements, analysis models, and test cases. Use Case (Functional Model)
-
Use cases were introduced as part of an object-oriented development methodology by Ivar Jacobson in Object-Oriented Software Engineering
Each use case describes a scenario in which a user interacts with the system being defined to achieve a specific goal or accomplish a particular task.
Use Case (Functional Model)
-
Use Case (Functional Model)A use case diagram establish the capability of the system as a whole.
Components of use case diagram:ActorUse caseSystem boundaryRelationshipSpecification
-
ACTOR:What is an actor?
An actor is some one or something that must interact with the system under developmentUML notation for actor is stickman, shown below.
-
ACTOR:More about an actor:
It is role a user plays with respect to system.
Actors are not part of the system they represent anyone or anything that must interact with the system.
Actors carry out use cases and a single actor may perform more than one use cases.
Actors are determined by observing the direct uses of the system,
-
ACTOR: Contd
Those are responsible for its use and maintain as well as other systems that interact with the developed system.
An actor may - input information to the system.- receive information from the system.- input to and out from the system.
-
ACTOR:How do we find the actor?
Ask following questions to find the actors:Who uses the system?Who installs the system?Who Starts up the system?What other systems use this system?Who gets the information from the system?Who provides information to the system?
Actor is always external to the system. They are never part of the system to be developed.
-
*ACTOR:
4-Categories of an actor:
Principle: Who uses the main system functions.Secondary: Who takes care of administration & maintenance.External h/w : The h/w devices which are part of application domain and must be used.Other system: The other system with which the system must interact.
-
USE CASE:What is USE case?A use case is a pattern of behavior, the system exhibitsEach use case is a sequence of related transactions performed by an actor and the system in dialogue.USE CASE is dialogue between an actor and the system. Examples:
Open new accountWithdrawal of cash from ATM
-
USE CASE:More about USE CASE:
They model a dialog between actor and system.A use case typically represents a major piece of functionality that is complete from beginning to end.Most of the use cases are generated in initial phase, but you find some more as you proceed.A use case may be small or large. It captures a broad view of a primary functionality of the system in a manner that can be easily grasped by non technical user.
-
USE CASE:Contd
A use case must deliver something of value to an actor.The use cases may be decomposed into other use cases.Use cases also present a good vehicle for project planning.
-
USE CASE:How do we find the use cases?
What functions will the actor want from the system?
Does the system store information? What actors will create, read, update. Or delete that information?
Does the system need to notify an actor about changes in its internal state?
-
SYSTEM BOUNDARY:What is System Boundary?
It is shown as a rectangle.It helps to identify what is external verses internal, and what the responsibilities of the system are.The external environment is represented only by actors.
-
A Use case diagram of the business
Catalog Order SystemCatalog CustomerPlace OrderReturn Order ItemCancel OrderItemCancel Order
-
RELATIONSHIP:What is Relationship?
Relationship between use case and actor. CommunicatesRelationship between two use cases Extends Uses (include) Generalize Notation used to show the relationships:>
-
RELATIONSHIP: or :
A uses relation from use case A to use case B indicates that the an instance of the use case A will also include the behavior as specified by B
-
RELATIONSHIP:: An extends relationship from use case A to use case B indicates that an instance of use case B may include the behavior specified by A
-
RelationshipCancel OrderItemCancel Order
-
RelationshipPlace OrderAdd Customer
-
Uses V/s ExtendsA uses B means that A always invokes B.
B extends A means that A sometimes invokes BBA
BA
-
ralationshipThe third form of relationship among use cases, ageneralization/specializationrelationship exists.A given use case may have common behaviors, requirements, constraints, and assumptions with a more general use case. In this case, describe them once, and deal with it in the same way, describing any differences in the specialized cases.
-
Notation is CustomerAdministratorUser
-
*SpecificationGeneric format for documenting the use case: - Pre condition:If anyUse case: Name of the case.Actors:List of actors(external agents), indicating who initiates the use case.Purpose:Intention of the use case.Overview:Description.Post condition:If any
Typical Course of Events:ACTOR ACTION: Numbered actions of the actor.SYSTEM RESPONSE: Numbered description of system responses.
-
*USE CASE documentation example:The following use case describes the process of opening a new account in the bank. Use case:Open new accountActors:Customer, Cashier, ManagerPurpose:Like to have new saving account.Description:A customer arrives in the bank to open the new account. Customer requests for the new account form, fill the same and submits, along with the minimal deposit. At the end of complete successful process customer receives the passbook.
-
Activity DiagramUse case diagram defines the actors, use cases and relationship between them but it contain no information about the dynamics of these function:Suppose one use case uses several use cases. You do not see in what order those are used.Suppose one use case extends another. You do not see under what conditions the extension occurs
Activity diagram provides solution for these deficiencies.
-
Activity DiagramShows control/data flows from one activity to anotherEmphasizes the flow of control among objectsPurposeModel business workflows, flow control within a system, and operationsCaptures dynamic behavior (activity-oriented)
-
NotationsActivity Name
NotationMeaningActivityWork Flow / TransitionStartStopConditionForkJoin
-
Activity DiagramsAn Activity diagram shows the workflow of activitiesAn Activity is modeled as Capsule with the activity name enclosed.
XYActivity Y follows Activity XTransition
-
Conditional Activities(Branching)XY[ i==0 ][ i !=0 ]
-
Nested ActivitiesXY1[ i==0 ][ i !=0 ]Y2[ i>0 ]
-
Repeated ActivitiesXYActivity X is followed by multiple Activity Ys*For each widget produced by x
-
Parallel ActivityY1Y2XZY2Y2Y2Z[Y1 and either Y2 or Y3]Synchronization bars
-
EventIn activity diagram communication between object is model as Event.Notation for event isEvent NameEvent NameEvent SentEvent Received
-
Activities in Placing OrderEntering the order, which involves taking information about the order and the payment method from customer
Authorizing the purchase, which requires verification of funds
Allocating the order items from inventory
Shipping the order
-
Activity diagram for Placing OrderEnter OrderAuthorize FundsAllocateInventoryShip Order[aborted][denied][committed][approved]
-
& Relationship:- Indicates a design refinement.
:-indicates any other kind of refinement
-
Refined Activity diagram for Placing OrderPlace Order
-
Refined Activity diagram for Placing Order with Events
-
Activity diagram for Cancel Order ItemCheck Order StatusCreditAccountReleaseInventory[not pending]Cancel OrderItem
-
You can extend the activity diagram to show exactly who carries out what activity, by dividing it into Swimlanes Activity diagram with SwimlanesRegion 1Region 2Region 3Region 4
-
Activity diagram with SwimlanesPlace Order
Enter OrderAuthorize FundsAllocateInventoryShip Order[aborted][denied][committed][approved]Order EntryFinanceInventory ManagementShipping
***************************************
