CIS 321 Exam 2
context diagrams are composed of three elements
-A system or subsystem. -Entities outside the system that interact with it. -Interactions between outside entities and the system.
use case diagram
-Diagram that shows relationship among actors, use cases, and the system. -i.e. A meta-model that portrays associations among actors, use cases, and the system.
vertical division
-Many Parallel Steps in a Use Case => Vertical Division necessary
a scenario consists of:
-normal flow: best case scenario -alternate flow: conditional steps -sub-flows: consists of discrete sub-steps -exceptions: event that prevent certain steps (or whole use case) from successful completion; ex: customer cannot pay
two types of systems
-real system: grocery store "bricks-and-mortar" -information system: point of sales system (POS)
steps in a use case scenario(3)
-steps can be repeated -a step can call on another use case -a step is a transaction
Use Case Diagram for Dependencies
In a use case diagram, dependency type is indicated by the direction of an arrow; the arrow points from the extending to the extended; the arrow points from the base UC to the included
subflows
Sub-flows identify the details of the steps in the normal flow. Usually has a name
major use caes are identified by analyzing _______ and _________; processes and functions are _____ _____ ______, but not one-to-one
business processes, functions; use case candidates
TF: postcondition
defines the state of the system after a use case is complete.
TF: ID
is unique numeric identifier for the use case
primary and supporting actors example
patient management: a registration clerk registers the patient, which includes verify insurance plan. Health insurance provider is a supporting actor that helps verify insurance plan.
TF: summary
◦ a long version of the use case name and a short version of the scenario
alternate flow and exceptions
-"if" is implicit -Alternate steps identify remedies; exceptions signify failure
extend relationship
-A relationship btw two use cases where a use case extends the functionality of a base use case --A base use case uses another use case -Enhance features of a base use case, but does not affect normal functionality (e.g. sunroom of a house) -Use case must be referenced in alternate flow (NOT in normal flow)
Activity Diagram
-Activity diagram can clarify, visualize flow of activities -Depicts the flow from activity to activity -Presents a visual, dynamic view of the system and its components.
TF: trigger
-Event that starts the use case. Can be temporal (time-related) -Trigger occurs, or can occur, only if preconditions to use case are met
Horizontal Division
-Flow is too long. -The scenario lacks unity of time. -The role hides more than one actual user -Some transactions are much more important or sensitive than others.
Dividing Use Cases
-New requirements or the challenge of complexity may demand that a use case be divided: --Vertical division is necessary if the use case has too many parallel steps. -Horizontal division is necessary if the flow is too complex or the building blocks of the use case lack unity.
Non-Behavioral Requirements
-Only when a non functional requirements applies to a specific use case, the requirement is specified in the template. -examples: The interface must be designed for a touch screen. No keyboard (these are not in steps/flow)
How to Generalize Use Cases
-Parent is abstract use case -Trigger is usually specific to concrete (child) use case -Actors may be different (since different mean) -Information (on items in form) can be --I: inherited with no change --S: inherited but specialized --N: new -Generalization can replace a set of alternate steps
primary actor and scope of extended use cases
-Primary Actor: same as base use case's --Supporting actor may be different, E.g.) sunroom's owner vs house's owner -Scope: same as base use case -Not instantiated independently(does not need independent trigger)
use case modeling
-Provides framework for building blocks of modeling and beyond -Used among all participants: from gathering requirements and communicating with stakeholders to exchanging information with designers and programmers -other models rely on use cases
discovering classes
-Start by mining the flow of use cases -The messages exchanged between the actors and the system
identify prominent actors
-The primary candidates for becoming actors are (domain concepts classified as) "role." -process of abstraction(deciding if there is a single actor, multiple roles, if more than one person fits in a role)
(Object's) Responsibilities
-The service that a class defines and provides to outside world -Consist of what it does and what it knows; in other words, its operations and its attributes
Structural Modeling
-View of the building blocks of a system or an entity -Their inter-relationships within a given scope. -Have to create one to develop an IS
Delineating Use Cases
-When do we know a use case is really one use case, and no more? -One use case must have: one primary actor, one useful goal, one system -if not, separate or join
four components of a use case
-a goal -stakeholders and actors -a system -a scenario
refactoring
-abstracts and reorganizes common behavior among use cases into new use cases. -Similar to taking out part of common codes among methods to make a new method. The new method is used in those methods. -A special case of horizontal division useful for a large system in which 1. Certain behaviors are repeated in many use cases, and 2. Analysis is assigned to a team rather than one person
TF: flow
-an ordered set of activities/steps that occur as the actors and the system attempt to reach a goal. -Steps are abstractions, i.e. just look from outside with less lower-level detail -System's response must be limited to "what", not "how" -Steps can be repeated
normal flow
-best case scenario -avoid too many steps: see if it is one use case, or steps have too much detail. -consider sub-flow, or develop use cases (include, extend) cases
TF: priority
-decides the order of design and implementation for use cases. E.g) High, Low, Medium. 1/5, 2/10, etc -Based on requirements of project and logic of system modeling and implementation
NOTs of use cases
-do not model the system from the inside -are not effective in capturing the non-functional requirements. (or designed for it either) -not inherently object oriented
TF: audit fields
-help us to keep track of the evolution of the use case. -records Author, Revision, Date, Source
develop initial use cases(3)
-identify prominent actors -identify major use cases -develop context diagram
use case template
-structures use cases by providing well-define and ordered fields -used to develop a use case description for each use case
include relationship
-◦ Relationship in which one use case uses the functionality of another independent use case. -Like a method calls another method in programming -more likely to be referenced in normal flow
Methods to Separate/Join Use Cases
1. We delineate them. 2. We divide them into more use cases. 3. We combine them.
Activity diagram
Concentrates on the logical flow of activities w/o notion of objects
Parse use cases for hidden grammatical objects
Customer orders the books in the shopping cart -Customer places order for the books Verb hides nouns (both vi and vt) -E.g.) drive (car), eat (meal), hum (tune), punch out (timecard)
Sequence diagram
Emphasizes the order of interactions in time
Events
Events are actions by one object that interrupt the existing condition of one or more other objects.
Collaboration diagram
Focuses on how the objects are organized and what set of messages they must exchange to satisfy a certain behavior.
Finding Class Candidates
Parse use cases (steps) for nouns as grammatical objects
context diagram
Represents the interaction of outside entities with a system as a whole; more abstract than use case, not a uml diagram
Dynamic Modeling
Represents the interaction of the building blocks of the information system -with each other and with the outside world to satisfy the behavioral requirements of the system Interaction through messages ◦ Features objects ◦ Interactions happen in time => Show order
Primary goal of use case modeling
To channel unruly requirements of a system into disciplined behavioral units with distinct boundaries
Statechart diagram
Traces the results of interactions on the state of objects belonging to a specific class
use case generalization
We generalize use cases when the they achieve the same goal by different means.
use case
a contract that formalizes the interaction between stakeholder and the system.
base use case
a fully formed, structured use case which serves as a base to develop other analysis and design artifacts; created from initial use cases defined in use case summary
goal
a goal is what the successful completion of a use case achieves -the goal must be meaningful -muse be a logically complete function -must be a measurable value a use case is successful only if its stated goal is completely achieved
use case diagram basic elements
actor-stick figure system boundary or scope-rectangle use case-ellipse(oval) association-line
actor vs class
actor: entity outside the system class: entity inside the system ex: doctor actor, doctor employee
Aggregation vs Composition
aggregation: Has a association, Represents the relationship of a whole to a part, Hollow diamond in class diagram composition: A form of aggregation in which the part is exclusively owned by the whole, its lifecycle is dependent on the lifecycle of the whole.
actor
an entity outside the system that interacts with the system to achieve a specific goal; a role that any user who has been given a part can play
scenario
an ordered sequence of interactions between the actor(s) and the system to accomplish a goal
TF: stakeholder
any entity, human or otherwise, who has an interest in the outcome of the use case
TF: supporting actor
assist the primary actor in achieving the goal of the use case.
use case model the _____ of a system
behavior
the system define the ________ of a use case
boundaries
TF: Scope
boundaries of the use case - defined by the system or the subsystem to which it belongs
Any ______ in one component of a use case might result in a different use case
change
TF: precondition
defines the state of the system before a use case can start;
TF: name
embodies the goal that the use case wants to accomplish.
stakeholder
entities whose interests are affected by the success or the failure of the use case
a use case's name is its _____. The name must be _____, _______, and _______.
goal; active, concise, decisive
TF: primary actor
is the actor whose goal identifies and drives the use case.
Dynamic modeling is about _____. DM models:
objects; ◦ interactions among objects ◦ how the objects change through interaction.
The goal of the ______ _________ is specified by the _________ of the use case
primary actor; name
TF: open issues
questions that must be resolved before the use case can be judged as complete
TF: custom fields
specifies an attribute or requirement that is specific to one use case or a set of use cases within the system.
____________ (or ________) actors support the primary actor in reaching the goal of the use case.
supporting, secondary
a use case cannot leave a _________, but can reach across its __________.
system; boundaries
identify major use cases, use the following strategy
take apart: Sell groceries => Purchase groceries + checkout groceries join: Checkout groceries += Bag groceries
a use case details...
the interaction of an actor with a system to accomplish a goal of value to the actor; Description needs a story to illustrate what a use case is
use case's name must show action: one _________ _______ and one __________.
transitive verb, object; ex: order pizza, verify credit card, set up account
an actor is identified by a __________ _________ which describes a _________ _______
unique name; unique role
use case modeling describes ____ a system accomplishes, not _____
what, how
