Software Construction

Lecture 4
Iterative Development & the
Rational Unified Process (RUP)
Introduction to UML
History of UML
Intro to UML through an Example

1
 Software—A Risky Business
Successful:
The project is completed
on-time and on-budget,
with all features and
functions as initially
specified

Challenged
Source: The project is completed
CHAOS and operational but over-
Report by budget, over the time
The Standish estimate, and offers fewer
Group Report
features and functions
than originally specified

Failed
The project is cancelled
at some point during the
development cycle.!
 Faulty Assumption 1:
Requirements can be Fairly Accurate
• Applied Software Measurement, Capers Jones.
• Based on 6,700 systems.
60
Creeping Req's as % of original

50

40

30

20

10

0
10 100 1000 10000 100000
Project Size in Function Points
 Faulty Assumption 2:
Requirements are Stable

• The market changes—constantly

• The technology changes
• The goals of the stakeholders change
Faulty Assumption 3: The Design can be
Done, before implementation

• Requirements are incomplete and changing

• Too many variables, unknowns etc.
• A complete specification must be as detailed as
code itself
 Iterative Development

• Iterative (& incremental) development can help to minimize

these problems
• Iterative development
• developing a system through repeated cycles
• Incremental
• developing a system in smaller portions at a time
• It allows software developers to take advantage of what was
learned during development of earlier parts or versions of the
system
• Learning comes from both the development and use of the
system
 Iterative Development
• Small steps, feedback and refinement.
• System grows incrementally over time, iteration by iteration.
• Iterative, incremental, time-boxed.

Iteration Iteration
...
1 2

Code, Test, Code, Test,

Analyze Design Analyze Design
Integrate Integrate

2 weeks 2 weeks
 Benefits of Iterative Development

• Early mitigation of high risks

• Early visible progress
• Early user feedback and adaptation leading to a refined
system that meets real needs of users
• Complexity is managed
• Learning within an iteration can be used to improve the
process
The Rational Unified
Process

9
 A Popular Iterative Process—The Unified Process
• Warning: The phases are not iterations
Introduction to UML

15
 Unified Modeling Language (UML)

• “Owning a hammer doesn’t make one an architect”

• Knowing an object-oriented language (such as Java) is a

necessary but insufficient first step to create object oriented
systems

• Knowing how to "think in objects" is critical

 What is UML?
• UML (Unified Modeling Language)
• “A graphical language for visualizing, specifying, constructing and documenting the
artifacts of a software intensive system” [Booch]
• Nonproprietary standard for modeling software systems – OMG
• Convergence of notations used in object-oriented methods
• OMT (James Rumbaugh and collegues)
• Booch (Grady Booch)
• OOSE (Ivar Jacobson)
• Current Version: UML 2.5
• For detailed information visit http://www.omg.org/spec/UML/2.5/
• Commercial tools: Rational (IBM),Together (Borland), Visual Architect (business processes, BCD)
• Open Source tools: ArgoUML, StarUML, Umbrello, UMLet
• Commercial and Opensource: PoseidonUML (Gentleware)
 UML History
Version Release Date
• OO languages appeared in mid 70’s to late 80’s
2.5 June 2015
• Between ’89 and ’94, OO methods increased from 10
to 50 2.4.1 August 2011

• Unification of ideas began in mid 90’s. 2.4 March 2011

• Rumbaugh joins Booch at Rational ’94 2.3 May 2010

• v0.8 draft Unified Method ’95
2.2 February 2009
• Jacobson joins Rational ’95
2.1.2 November 2007
• UML v0.9 in June ’96
• UML 1.0 offered to OMG in January ’97 2.1.1 August 2007

• UML 1.1 offered to OMG in July ’97 1.5 March 2003

• UML 1.2 in June ’98 1.4 September 2001

1.3 March 2000

 UML: Basic Diagrams
• 80-20 rule: Pareto principle (http://en.wikipedia.org/wiki/Pareto_principle)
• 80% of your profits come from 20% of your customers

• 80% of your complaints come from 20% of your customers

• 80% of software problems are caused by 20% of bugs

• 80% of users only use 20% of software features

• We can model 80% of the problems by using about 20% UML

• We will mainly cover those 20%

 UML: Basic Diagrams
• Use case diagrams
• Describe the functional behavior of the system as seen by the user

• Class diagrams
• Describe the static structure of the system: Objects, attributes,
associations

• Sequence diagrams
• Describe the dynamic behavior between objects of the system

• State diagrams
• Describe the dynamic behavior of an individual object
An Example

• A "dice game" in which software simulates a player

rolling two dice

• If the total is seven, he wins; otherwise, he loses

 Define Use Cases

• Play a Dice Game use case: Player requests to roll the die. System
presents results: If the die face value totals seven, player wins; otherwise,
player loses

Dice Game

Play a Dice
Game
Player
 Define a Domain Model
• Object-oriented analysis is concerned with creating a description of the domain from
the perspective of objects.

• There is an identification of the concepts, attributes, and associations that are

considered important.

• The result can be expressed in a domain model that shows the noteworthy domain
concepts or objects.
 Assign Object Responsibilities and Draw
Interaction Diagrams
• Object-oriented design is concerned with defining software objects their
responsibilities and collaborations
• A common notation to illustrate these collaborations is the sequence diagram
(a kind of UML interaction diagram)

• It shows the flow of messages between software objects, and thus the
invocation of methods
 Define Design Class Diagrams

• In addition to a dynamic view of collaborating objects shown in

interaction diagrams, a static view of the class definitions is
usefully shown with a design class diagram

• This illustrates the attributes and methods of the classes

Classification of UML Diagrams
 Classification of UML Diagrams
• Three classifications of UML diagrams:

• Structure diagrams.  A type of diagrams that depict the elements of a specification that
are irrespective of time.  This includes Class Diagram, Object Diagram, Component
Diagram, Composite Structure Diagram, Package Diagram, and Deployment Diagram  

• Behavior diagrams.  A type of diagrams that depict behavioral features of a system or

business process.  This includes Use Case Diagram, Activity Diagram, and State Machine
Diagram

• Interaction diagrams.  A subset of behavior diagrams which emphasize object

interactions.  This includes Sequence Diagram, Communication Diagram, Timing
Diagram, and Interaction Overview Diagram
 Structure Diagrams

• Class Diagram: Shows the static structure of a system

• Object Diagram: Shows the static structure of a system at a point in time

• Component Diagram: Shows how a software system is split up into components and
shows the dependencies among these components.  

• Composite Diagram: Shows the internal structure of a class and the collaborations that
this structure makes possible

• Package Diagram: Shows how a system is split up into logical groupings by showing the
dependencies among these groupings (packages that make up a model)

• Deployment Diagram: Shows the execution architecture of systems.  This includes

nodes, either hardware or software execution environments, as well as the middleware
connecting them
 Behavior Diagrams

• Use Case Diagram: Shows use cases, actors, and their interrelationships

• Activity Diagram: Represents the step-by-step workflows of components in a

system. An activity diagram shows the overall flow of control

• State Machine Diagram: Describes the states an object or interaction may be in, as

well as the transitions between states. Formerly referred to as a state diagram,

state chart diagram, or a state-transition diagram

 Interaction Diagrams

• Sequence Diagram: Sequence diagrams depict an interaction among

elements of a system organized in time sequence

• Communication Diagram: Shows instances of classes, their

interrelationships, and the message flow between them

• Timing Diagram: Depicts the changes in the state of an object over time in
response to external events 

• Interaction Overview Diagram: A variant of an activity diagram, an

individual activity is pictured as a frame which can contain nested interaction
diagrams
 The UML is NOT

• A visual programming language, but a visual modeling language

• A tool or repository specification, but a modeling language

specification

• A process, but enables processes

Extensibility of UML

• Stereotypes
• Allows to define a new kind of model element based on an
existing one
• Basically adds extra semantics

• Examples
 Case Study

• The NextGen POS System

A POS system is a computerized application used to record sales and
handle payments; it is typically used in a retail store, it includes H/W
components (bar code scanner ) as well.

It interfaces to various service applications, such as third party tax

calculator and inventory control
Case Study Focus

• Many systems can be divided into 3 layers

• User interface
• Business logic (application)
• Integration (DB & other systems)

• Focus is on business layer because

• It’s design is less technology dependent
• OOAD skills can be applied to other layers
Sample layers and objects in an object-oriented system,
and the case study focus

minor focus
User Interface
explore how to connect to
other layers

primary focus
of case studies
application Sale Payment
logic layer explore how to
design objects

other layers or secondary

Logging ... Database Access ...
components focus
Questions???