Sie sind auf Seite 1von 11

.

UNIT-I

What is the Basic Unified Process

Basic Unified Process (BUP) is a streamlined version of IBM Rational Unified Process
(RUP)optimized for small projects.
Small projects constitute teams of 3 to 6 people and involve 3 to 6
months of development effort. BUP preserves the essential characteristics of RUP,
which
includes iterative development, use-cases and scenarios driving development, risk
management and architecture-centric approach.
Most optional parts of RUP have been excluded, and many elements have been merged.
The result is a much simpler process that is still true to RUP principles
The Unified Software Development Process or Unified Process is a popular
iterative and incremental software development process framework. The bestknown and extensively documented refinement of the Unified Process is the
Rational Unified Process (RUP)

The NextGen POS

INCEPTION

INCEPTION

A use case in software engineering and


systems engineering is a description of a
systems behaviour as it responds to a
request that originates from outside of that
system. In other words, a use case describes
"who" can do "what" with the system in
question. The use case technique is used to
capture a system's behavioral requirements
by detailing scenario-driven threads through
the functional requirements.

A use case should:


Describe what the system shall do for the
actor to achieve a particular goal.
Include no implementation-specific language.
Be at the appropriate level of detail.
Not include detail regarding user interfaces
and screens. This is done in user-interface
design, which references the use case and its
business rules.

Actors

A use case defines the interactions between


external actors and the system under
consideration to accomplish a goal. An actor
specifies a role played by a person or thing
when interacting with the system
The same person using the system may be
represented as different actors because they
are playing different roles. For example, user
"Joe" could be playing the role of a Customer
when using an Automated Teller Machine to
withdraw cash, or playing the role of a Bank
Teller when using the system to restock the
cash drawer.

USECASE-Restaurant

Use Case Relationships


- 4 Types
Include

In one form of interaction, a given use case may include another. "Include is a
Directed Relationship between two use cases, implying that the behavior of the
included use case is inserted into the behavior of the including use case".

The first use case often depends on the outcome of the included use case. This is
useful for extracting truly common behaviors from multiple use cases into a single
description. The notation is a dashed arrow from the including to the included use
case, with the label "include". This usage resembles a macro expansion where the
included use case behavior is placed inline in the base use case behavior. There are no
parameters or return values. To specify the location in a flow of events in which the
base use case includes the behavior of another, you simply write include followed by
the name of use case you want to include, as in the following flow for track order.
Extend

In another form of interaction, a given use case (the extension) may extend another.
This relationship indicates that the behavior of the extension use case may be inserted
in the extended use case under some conditions[2]. The notation is a dashed arrow
from the extension to the extended use case, with the label "extend". The notes or
constraints may be associated with this relationship to illustrate the conditions under
which this behavior will be executed.

Modelers use the extend relationship to indicate use cases that are "optional" to the
base use case. Depending on the modeler's approach "optional" may mean "potentially
not executed with the base use case" or it may mean "not required to achieve the base
use case goal".

Continued.

Generalization

In the third form of relationship among use cases, a


generalization/specialization relationship 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. The notation is a solid
line ending in a hollow triangle drawn from the specialized to the more
general use case (following the standard generalization notation).
Associations

Associations between actors and use cases are indicated in use case
diagrams by solid lines. An association exists whenever an actor is involved
with an interaction described by a use case. Associations are modeled as
lines connecting use cases and actors to one another, with an optional
arrowhead on one end of the line.

The arrowhead is often used to indicating the direction of the initial


invocation of the relationship or to indicate the primary actor within the use
case. The arrowheads imply control flow and should not be confused with
data flow.