Unit-2

Lecture-1
Notes on oosdp wrt process domain and time domain:
Object Oriented Software Development Process wrt process domain:
Analysis understanding, finding and describing concepts in the problem domain.
Design understanding and defining software solution/objects that represent the
analysis concepts and will eventually be implemented in code.
OOAD Analysis is object-oriented and design is object-oriented. A software
development approach that emphasizes a logical solution based on objects.
Software Development Life Cycle:

Object Model: describes the static

structure of the objects in the system and
their relationships -> Object Diagrams.

Dynamic Model: describes the

interactions among objects in the
system -> State Diagrams.

Functional Model: describes the data

transformation of the system
-> DataFlow Diagrams.

Analysis:

i) Model the real world showing its important

properties;
ii) Concise model of what the system will do

System Design:
Organize into subsystems based on analysis
structure and propose architecture

Object Design: Based on analysis

model but with implementation details;
Focus on data structures and
algorithms to implement each class;
Computer and domain objects

Implementation: Translate the object

classes and relationships into a
programming language

Software Development Life Cycle

The UML is largely process-independent, meaning that it is not tied to any particular software
development life cycle. However, to get the most benefit from the UML, you should consider a
process that is

Use case driven

Architecture-centric

Iterative and incremental

Use case driven means that use cases are used as a primary artifact for establishing the
desired behavior of the system, for verifying and validating the system's architecture, for
testing, and for communicating among the stakeholders of the project.

Architecture-centric means that a system's architecture is used as a primary artifact for

conceptualizing, constructing, managing, and evolving the system under development.

An iterative process is one that involves managing a stream of executable releases. An

incremental process is one that involves the continuous integration of the system's
architecture to produce these releases, with each new release embodying incremental
improvements over the other. Together, an iterative and incremental process is riskdriven, meaning that each new release is focused on attacking and reducing the most
significant risks to the success of the project.

This use case driven, architecture-centric, and iterative/incremental process can be broken
into phases. A phase is the span of time between two major milestones of the process,
when a well-defined set of objectives are met, artifacts are completed, and decisions are
made whether to move into the next phase.

As Figure 1 shows, there are four phases in the software development life cycle:
inception, elaboration, construction, and transition. In the diagram, workflows are plotted
against these phases, showing their varying degrees of focus over time.

Figure 2-24. Software Development Life Cycle

OOsdp wrt time domain

Inception is the first phase of the process, when the seed idea for the development is
brought up to the point of beingat least internallysufficiently well-founded to warrant
entering into the elaboration phase.

Elaboration is the second phase of the process, when the product requirements and
architecture are defined. In this phase, the requirements are articulated, prioritized, and
baselined. A system's requirements may range from general vision statements to precise
evaluation criteria, each specifying particular functional or nonfunctional behavior and
each providing a basis for testing.

Construction is the third phase of the process, when the software is brought from an
executable architectural baseline to being ready to be transitioned to the user community.
Here also, the system's requirements and especially its evaluation criteria are constantly
reexamined against the business needs of the project, and resources are allocated as
appropriate to actively attack risks to the project.

Transition is the fourth phase of the process, when the software is delivered to the user
community. Rarely does the software development process end here, for even during this
phase, the system is continuously improved, bugs are eradicated, and features that didn't
make an earlier release are added.

One element that distinguishes this process and that cuts across all four phases is an
iteration. An iteration is a distinct set of work tasks, with a baselined plan and evaluation
criteria that results in an executable system that can be run, tested, and evaluated. The
executable system need not be released externally. Because the iteration yields an
executable product, progress can be judged and risks can be reevaluated after each
iteration. This means that the software development life cycle can be characterized as
involving a continuous stream of executable releases of the system's architecture with a
midcourse correction after each iteration to mitigate potential risk. It is this emphasis on
architecture as an important artifact that drives the UML to focus on modeling the
different views of a system's architecture.

Lecture-2
Use Case Diagram:
A use case diagram does not show the detail of the use cases: it only summarizes some of the
relationships between use cases, actors, and systems. In particular, the diagram does not show the
order in which steps are performed to achieve the goals of each use case.
Example

 An actor (1) is a class of person, organization, device, or external software component that
interacts with your system. Example actors are Customer, Restaurant, Temperature Sensor,
Credit Card Authorizer.
A use case (2) represents the actions that are performed by one or more actors in the pursuit
of a particular goal. Example use cases are Order Meal, Update Menu, Process Payment.
On a use case diagram, use cases are associated (3) with the actors that perform them.
Your system (4) is whatever you are developing. It might be a small software component,
whose actors are just other software components; or it might be a complete application; or it
might be a large distributed suite of applications deployed over many computers and devices.
Example subsystems are Meal Ordering Website, Meal Delivery Business, Website Version 2.

modeling project are views of the same model.

Drawing Actors and Use Cases

The main purpose of a use case diagram is to show who interacts with your system, and the main
goals they achieve with it.

Create Actors to represent classes of people, organizations, other systems, software or

devices that interact with your system or subsystem.

To learn how to draw actors and other elements, see How to: Edit UML Models
and Diagrams.

For each distinct set of goals, identify actors by their type or role, even though the
physical persons or entities might be the same. For example, Restaurant and
Customer are separate actors, even though a restaurant employee might
sometimes be a customer.

Create Use Cases for each of the goals that each actor seeks to achieve with the system.
o

Name and describe the use cases in words that the actor would understand, instead
of implementation terms.

Use Associations to link actors to use cases.

Inheritance between Actors

Alternative Actor Icons
You can use custom icons to represent an actor, instead of the standard stick figure. For example,
you could change it to resemble a device, restaurant, bank, and so on.
To change the appearance of an actor
1. Right-click the actor and then click Properties.
The Properties window appears.
2. Set the Image Path property to the location of an image file.
o

You can use any of several image formats, including .gif, .jpg, and .bmp.

Use a file that is included in the solution or project source control so that it is still
available when the solution is moved or copied.

3. To replicate this appearance in other use case diagrams, copy the actor and paste it into
another diagram.
o

The change of image applies only to the view in a particular diagram. It does not
apply to the underlying model element. If you drag the actor from UML Model
Explorer onto another diagram, it will appear as the standard stick figure.

Multiplicities between Actors and Use Cases

The association between an actor and a use case can show a multiplicity at each end.

Note
The multiplicities of an association on a use case diagram are hidden if they are both 1.
By default, each multiplicity is 1. In a strict interpretation of the model, a multiplicity of 1 means
that, for example, only one customer is involved in ordering each meal and that each customer
orders only one meal at a time.
You can change these multiplicities.
For example:

To state that several actors of the same class can take part in a single occurrence of a use
case, set the multiplicity at the actor end of the association to 1..*.
In the illustration, one or more restaurants can take part in fulfilling the same meal order.

To show that each actor can participate at the same time in several occurrences of a use
case, set the multiplicity at the use case end of the association to *.
In the illustration, each restaurant can work on fulfilling more than one order at a time.

To set multiplicities on an association

1. Right-click the association and then click Properties.

2. Expand either First Role or Second Role.

Role means the element at one end of the association.
3. Set the Multiplicity property, choosing from the list:
o

1 to state that exactly one instance of this role participates in each link.

1..* to state that one or more instance of this role participate in each link.

0..1 to state that participation is optional.

* to state that zero or more instances of this role participate in the link.

In the example, the Order a Meal and Subscribe to Reviews use cases both include Pay.

The goal and scenarios of an included use case should make sense independently so that it can be
included in use cases that are designed later.
Separating use cases into including and included parts is useful to achieve the following goals:

Structure your use case descriptions into different layers of detail.

Avoid repeating shared scenarios in different use cases.