8.Unified Process Modelling.ppt of software engg

UNIFIED MODELING LANGUAGE
• UML is a general purpose modeling language.
• The main aim of UML is to define a standard method to visualize the way a system
has been designed.
• It is quite similar to blueprints used in other fields of engineering.
• UML is not a programming language, it is rather a visual language.

WHY DO WE NEED UML?
• Complex applications need collaboration and planning from multiple teams and hence
require a clear and concise way to communicate amongst them.
• Businessmen do not understand code. So UML becomes essential to communicate
with non programmers about essential requirements, functionalities, and processes
of the system.
• A lot of time is saved down the line when teams can visualize processes, user
interactions, and the static structure of the system.

DIFFERENT TYPES OF UML DIAGRAMS

CLASS DIAGRAM
• The most widely used UML diagram is the class diagram.
• It is the building block of all object oriented software systems.
• We use class diagrams to depict the static structure of a system by showing system’s
classes, their methods and attributes.
Class diagrams also help us identify relationship between different classes or
objects.

OBJECT DIAGRAM
• An Object Diagram can be referred to as a screenshot of the instances in a system
and the relationship that exists between them. Since object diagrams depict behaviour
when objects have been instantiated, we are able to study the behaviour of the system
at a particular instant.
• An object diagram is similar to a class diagram except it shows the instances of
classes in the system.
• We depict actual classifiers and their relationships making the use of class diagrams.
• On the other hand, an Object Diagram represents specific instances of classes and
relationships between them at a point of time.

COMPOSITE STRUCTURE DIAGRAM
• They are similar to class diagrams except they represent individual parts in
detail as compared to the entire class
• We use composite structure diagrams to represent the internal structure of a class and
its interaction points with other parts of the system.
• A composite structure diagram represents relationship between parts and their
configuration which determine how the classifier (class, a component, or a deployment
node) behaves.
• They represent internal structure of a structured classifier making the use of parts,
ports, and connectors.
• We can also model collaborations using composite structure diagrams.
• .

COMPONENT DIAGRAM
• Component diagrams are used to represent how the physical components in a system
have been organized. We use them for modelling implementation details.
• Component Diagrams depict the structural relationship between software system
elements and help us in understanding if functional requirements have been covered
by planned development.
• Component Diagrams become essential to use when we design and build complex
systems.
• Interfaces are used by components of the system to communicate with each other.

DEPLOYMENT DIAGRAM
• Deployment Diagrams are used to represent system hardware and its software.It tells
us what hardware components exist and what software components run on them.
• They are primarily used when a software is being used, distributed or deployed over
multiple machines with different configurations.

PACKAGE DIAGRAM
• We use Package Diagrams to depict how packages and their elements have been
organized. A package diagram simply shows us the dependencies between different
packages and internal composition of packages.
• Packages help us to organise UML diagrams into meaningful groups and make the
diagram easy to understand.
• They are primarily used to organise class and use case diagrams.

STATE MACHINE DIAGRAMS
• A state diagram is used to represent the condition of the system or part of the system
at finite instances of time. It’s a behavioral diagram and it represents the behavior
using finite state transitions.
• State diagrams are also referred to as State machines and State-chart Diagrams .
• These terms are often used interchangeably. So simply, a state diagram is used to
model the dynamic behavior of a class in response to time and changing
external stimuli.

ACTIVITY DIAGRAMS
• We use Activity Diagrams to illustrate the flow of control in a system. We can also use
an activity diagram to refer to the steps involved in the execution of a use case.
• We model sequential and concurrent activities using activity diagrams. So, we
basically depict workflows visually using an activity diagram.
• An activity diagram focuses on condition of flow and the sequence in which it happens.
• We describe or depict what causes a particular event using an activity diagram.

USE CASE DIAGRAMS
• Use Case Diagrams are used to depict the functionality of a system or a part of a
system. They are widely used to illustrate the functional requirements of the system
and its interaction with external agents(actors).
• A use case is basically a diagram representing different scenarios where the system
can be used.
• A use case diagram gives us a high level view of what the system or a part of the
system does without going into implementation details.

SEQUENCE DIAGRAM
• A sequence diagram simply depicts interaction between objects in a sequential order
i.e. the order in which these interactions take place.
• We can also use the terms event diagrams or event scenarios to refer to a sequence
diagram.
• Sequence diagrams describe how and in what order the objects in a system function.
• These diagrams are widely used by businessmen and software developers to
document and understand requirements for new and existing systems.

COMMUNICATION DIAGRAM
• A Communication Diagram (known as Collaboration Diagram in UML 1.x) is used to
show sequenced messages exchanged between objects.
• A communication diagram focuses primarily on objects and their relationships.
• We can represent similar information using Sequence diagrams, however
communication diagrams represent objects and links in a free form.

TIMING DIAGRAM
• Timing Diagram are a special form of Sequence diagrams which are used to depict the
behavior of objects over a time frame.
• We use them to show time and duration constraints which govern changes in states
and behavior of objects.

WHAT IS THE UNIFIED PROCESS
The Unified Process (UP) is a software development
framework used for object-oriented modeling.
Derived from the work on the UML.
It is the leading object oriented methodology for the
development of large scale software
Maps out when and how to use the various UML techniques

THE MOST IMPORTANT UP IDEA:
ITERATIVE DEVELOPMENT
• The UP(unified process) promotes several best practices, but one stands above the others:
iterative development.
• In this approach, development is organized into a series of short, fixed-length (for
example, four week) mini-projects called iterations.
• The outcome of each is tested, integrated, into executable system.
• Each iteration includes its own requirements analysis, design, implementation, and testing
activities.

ITERATION RESULT..
• The result of each iteration is an executable but incomplete system.
• The output of an iteration is not an experimental or throw-away prototype, and
iterative development is not prototyping. Rather, the output is a production-
grade subset of the final system.

BENEFITS OF ITERATIVE DEVELOPMENT
It includes:
• early rather than late mitigation of high risks (technical, requirements, objectives,
usability, and so forth)
• early visible progress
• early feedback, user engagement, and adaptation, leading to a refined system that
more closely meets the real needs of the stakeholders
• managed complexity: the team is not overwhelmed by very long and complex steps
• the learning within an iteration can be methodically used to improve the development
process itself, iteration by iteration

ITERATION LENGTH
• The UP recommends an iteration length between two and six weeks.
• Much less than two weeks, and it is difficult to complete sufficient work to get
meaningful throughput and feedback.
• Much more than six or eight weeks, and the complexity becomes rather overwhelming,
and feedback is delayed.
• A very long iteration misses the point of iterative development.
• Short is good.

TIME-BOXED
• A key idea is that iterations are time boxed, or fixed in length.
• For example, if the next iteration is chosen to be four weeks long, then the partial
system should be integrated, tested, and stabilized by the scheduled date.
• Date slippage is discouraged.
• If it seems that it will be difficult to meet the deadline, the recommended response is to
remove tasks or requirements from the iteration, and include them in a future iteration,
rather than slip the completion date.

THE UP PHASES
A UP project organizes the work and iterations across four major phases:
1.Inception— approximate vision, business case, scope, vague estimates.
2.Elaboration—refined vision, iterative implementation of the core architecture, resolution
of high risks, identification of most requirements and scope, more realistic estimates.
3.Construction—iterative implementation of the remaining lower risk and
easier elements, and preparation for deployment.
4.Transition—beta tests, deployment.

IMP POINT ABOUT PHASES.
• This is not the old "waterfall" or sequential lifecycle of first defining all the
requirements, and then doing all or most of the design.
• Inception is not a requirements phase; rather, it is a kind of feasibility phase, where just
enough investigation is done to support a decision to continue or stop.
• Similarly, elaboration is not the requirements or design phase; rather, it is a phase
where the core architecture is iteratively implemented, and high risk issues are
mitigated.

SCHEDULE-ORIENTED TERMS IN THE
UP.

8.Unified Process Modelling.ppt of software engg

Recommended

Recommended

More Related Content

Similar to 8.Unified Process Modelling.ppt of software engg

Similar to 8.Unified Process Modelling.ppt of software engg (20)

Recently uploaded

Recently uploaded (20)

8.Unified Process Modelling.ppt of software engg