is a model?
A model is a small object usually built to scale,
that represents in details another larger object.
example, a car model or a build complex model is small object that represents a
much larger object.
a model represent all the detail?
model cannot represent all the details, but it helps visualize the object.
is a visual Model?
visual model is a way to represent an object or a process in term of tangible
representation for an audience to examine and relate to.
example, a flowchart represents the flow of logic for a code segment.
computer professionals such as programmers or analysts can understand and
relate to the flowchart.
or testers may not understand or relate to a flowchart.
visual model is a representation of an object or a process where all the
parties involved in building or working such an object or process can
understand and relate to it.
the involved parties would be able to recognize the parts of the object and
spot if there is a missing part of the model of representing the object or the
is a software Model?
software model is the a visual model that captures the structure and behavior
of architectures and components, where user, developers-programmer, managers,
testers and analysts would be able to recognize the parts of the model and spot
if there is a missing part or functionality of the model.
should not show details in order to simplify the model representation.
may consist of number of diagrams.
Modeling Language (UML):
is an industry-standard language that allows us to clearly communicate
requirements, architectures and design.
was originally created by Rational Software, and is now maintained by the
standards organization Object Management Group (OMG).
Booch, James Rumbaugh and Ivar Jacobson are the developed, unified for the UML
language and standardized it.
are known as the three Amigos.
can be used with any modeling and not necessary the software ones.
defines a number of items, which we will cover the following:
– by value
– by reference
Object Oriented provides a new way of declaring a
user-defined data type that has functionality.
This user-defined data type contains both the data objects
and the methods that perform certain tasks on them.
The new type is known as a class.
A class or an
ABSTRACT data type is a way of grouping logical data and the associated methods
within one object (class).
group of classes of related classes can be grouped under a package to share
values and functionality.
package can be used to help reduce complexity of the model.
can be nested or imported.
interface is basically the relationship between model components (objects ).
is also the interaction between objects.
inheritance is represented by arrow symbol, where the parent has the arrow
pointed to it.
is containment either by value or by reference.
– by value
an object – black diamond
– by reference
a reference or a pointer – white diamond
is the number of elements in a set.
is basically the association of one object to another.
association can be as follow:
same can be applied to the second object.
is one object depends on another object.
dash arrowed line shows dependency
there two ways dependency?
is the relationship between two objects, where it can be uni-directional or
means one object knows about another object of has a reference to it. The second object does not know anything
about the first object.
means both have the knowledge of the other existence.
the UML Guide handout.
is a plan, sketch, drawing, or an outline to demonstrate or explain how
something works, or to clarify the relationship between the parts of the whole.
Rose or Rose for short is a menu-driven application with a toolbars to help
with commonly used features.
supports the following UML diagrams:
is high-level piece of functionality that the system will provide.
Cases include anything that within the system and their relationships.
cases and actors describe the project scope without implementation details.
is implementation-independent view of the system.
is composed of actors and functionality.
parties involved in the development can look at the case diagram and spot each
individual role within the system.
can also see what is missing from the system.
should not be overloaded with actors and functionality to help make the diagram
simple and not confusing.
case diagram’s main benefits are:
case diagram illustrates the system functionality
between all parties involved in system development
of the system
system components interactions.
and system interaction
expectation of the system
to identify the use cases?
any documentation the customer provides
scope of the system
of the system
of the system
of the system
is the system will do
would the user get out of the system
to put a picture to every item listed above.
that you take user or client system description and turn it into a use case (a
in mind that the objective of the use case is visualization of the system, its
parts, parties and functionalities.
case should be named in business terms and not technical terms.
Flow of events:
is to document the flow of logic in the use case.
of events includes:
A short and to point description of the use case
List of conditions that must be met before the start
of the use case
flow of events
The start and end of a use case and what it will
encounter including errors and how to handle them.
flow of events
In case of errors or other things, what are the alternatives?
What must be always true after the end of use case?
include anything external to the system.
is anyone or anything that interacts with the system.
illustrate the interface with the system, which can be people, machines, or
example, would be as follows:
actors and Use cases show the scope of the project.
not model actor-to-actor communication.
What Is the Rational Unified Process?
Most software engineering is amid at developing new
software products, or enhancing an existing one. The Rational Unified Process
is a Software Engineering Process with the following goals:
the production of high-quality software.
the user’s needs.
does that within a predictable schedule and budget.
are seven known steps in any software development cycle starting with Problem
Definition and ending with Maintenance.
The Rational Unified Process takes each of the step and breaks it
farther down into the following four phases:
phase is concluded with a well-defined milestone, which is a point in time at
which certain critical decisions must be made, and therefore key goals must
have been achieved. The main objective
of the Rational Unified Process is break down each phase into four elements,
which are workers, activities, artifacts and workflows. The Rational Unified
Process works with models to help visualize the system picture as a whole. These models help all parties involved with
system development communicate and modify the models with their perspective
view of the problem and the system.
Static Structure of the Process:
A process describes who is doing what, how, and
when. The Rational Unified Process is represented using four primary modeling
Users, analysts, developers, testers and managers makeup the
workforce for developing any project. Either individuals or teams of
individuals do the project work and identifying he behavior and
responsibilities of an individual, or a group of individuals working together
as a team is critical step in each phase.
Individual or team role may change with the project progress. The Unified Process the worker is more the
role defining how the individuals should carry out the work. The
responsibilities are assigned to a worker includes the following:
of a certain set of activities
owner (responsibility) of a set of artifacts.
assignment of roles and ownership (responsibility) must be clearly set ahead of
An activity is the unit of work that an individual
must perform. Assignment of activity should be made with the following
categories in mind:
time needed to finish the work
job is a bottleneck
may be need.
sequence of jobs.
Artifacts are the tangible products of the project,
the things the project produces or uses while working towards the final
product. Artifacts are used as input by workers to perform an activity, and are
the result or output of such activities. Artifacts may take various shapes or
model, such as the Use-Case Model or the Design Model
model element, such as a class, a use case or a subsystem
document, such as Business Case or Software Architecture Document
It is sequences of activities that produce some
valuable result, and show the interactions between workers. In UML terms, a
workflow can be expressed as a sequence diagram, a collaboration diagram, or an
activity diagram. The use of a form of activity diagrams in this white paper.
Inception Phase (Setting up or Launch Phase)
This is the setup phase or launching phase, where
high-level interactions with actors are defined. It should identify all external entities with which the system
interacts. This phase should simplify
the scope of project. This involves the following:
all use cases
a few significant ones.
business case includes success criteria, risk assessment
of the resources needed
a phase plan showing dates of major milestones.
outcome of the inception phase is:
- A vision document: a
general vision of the core project's requirements, key features, and main
- An initial use-case
model (10%-20% complete).
- An initial project
glossary (may optionally be partially expressed as a domain model).
- An initial business
case, which includes business context, success criteria (revenue
projection, market recognition, and so on), and financial forecast.
- An initial risk
- A project plan, showing
phases and iterations.
- A business model, if
- One or several
The meaning of the word “Elaboration” is expansion
or explanation. In order for you to
explain it or expand it, you have to having the understanding of the whole
system, its scope, its major functionality and requirements. The purpose of the
elaboration phase is to do the following:
the problem domain
a sound architectural foundation
the project plan
the highest risk elements of the project.
outcome of the elaboration phase is:
- A use-case model (at
least 80% complete) - all use cases and actors have been identified, and
most use-case descriptions have been developed.
requirements capturing the non functional requirements and any
requirements that are not associated with a specific use case.
- A Software Architecture
- An executable
- A revised risk list and
a revised business case.
- A development plan for
the overall project, including the coarse-grained (rough) project plan,
showing iterations and evaluation criteria for each iteration.
- An updated development
case specifying the process to be used.
- A preliminary user
This is the production phase, where the product is
developed, tested and integrated.
Managing this phase is very crucial. All the work that is done in
previous phases will payoff in this phase. This phase needs the following:
operations to optimize costs, schedules, and quality
outcome of the construction phase is a product ready to put in hands of its
end-users. At minimum, it consists of:
- The software product
integrated on the adequate platforms.
- The user manuals.
- A description of the
The purpose of the transition phase is to transition
the software product to the user community. Once the product has been given to
the end user, issues usually arise that require you to develop new releases,
correct some problems, or finish the features that were postponed. This
testing" to validate the new system against user expectations
- Parallel operation with
a legacy system that it is replacing
- Conversion of
- Training of users and
- Roll-out the product to
the marketing, distribution, and sales teams
transition phase focuses on the activities required to place the software into
the hands of the users. Typically, this phase includes several iterations,
including beta releases, general availability releases, as well as bug-fix and
enhancement releases. Considerable effort is needed in developing user-oriented
documentation, training users, supporting users in their initial product use,
and reacting to user feedback. User
feedback should be confined primarily to product tuning, configuring,
installation, and usability issues. The primary objectives of the transition
- Achieving user
- Achieving stakeholder
concurrence that deployment baselines are complete and consistent with the
evaluation criteria of the vision
- Achieving final product
baseline as rapidly and cost effectively as practical
phase can range from being very simple to extremely complex, depending on the
type of product. For example, a new release of an existing desktop product may
be very simple, whereas replacing a nation's air-traffic control system would
be very complex
Each phase in the Rational Unified Process can be
further broken down into iterations. An iteration is a complete development
loop resulting in a release (internal or external) of an executable product or
a subset of the final product.
system can grow incrementally from iteration to iteration to become the final
Benefits of an Iterative Approach
Compared to the traditional waterfall process, the
iterative process has the following advantages:
- Risks are mitigated
- Change is more
- Higher level of reuse
- The project team can
learn along the way
- Better overall quality