Object Oriented

Programming
&
Unified Modeling Language
Benefits of Object Oriented Programming

• OOA/OOD/OOP is good for:

– Analyzing user requirements
– Designing software
– Constructing software
• Reusability (reusable components)
• Reliability
• Robustness
• Extensibility
• Maintainability
– Reducing large problems to smaller, more
manageable problems 2
 Symptoms of software
development problems
• Inaccurate understanding of end-user needs.
• Inability to deal with changing requirements.
• Modules that don't fit together.
• Software that's hard to maintain or extend.
• Late discovery of serious projects flaws.
• Poor software quality.
• Unacceptable software performance.
• Team members in each other's way.
• An untrustworthy build and release process.
3
Root causes of project failure
• Ad hoc requirements management.
• Ambiguous and imprecise communication.
• Brittle architectures.
• Overwhelming complexity.
• Undetected inconsistencies in requirements,
designs, and implementations.
• Insufficient testing.
• Subjective project status assessment.
• Failure to attack risk.
• Uncontrolled change propagation.
• Insufficient automation.

4
 Software development best
practices
• Develop software iteratively.
• Manage requirements.
• Use component-based architectures.
• Visually model software.
• Verify software quality.
• Control changes to software.

5
 Introduction to OO concepts
• Encapsulation - the grouping of related ideas into
unit. Encapsulating attributes and behaviors.
• Inheritance - a class can inherit its behavior from a
super class (parent class) that it extends.
• Polymorphism - literally means ``many forms''.
• Information/implementation hiding - the use of
encapsulation to keep implementation details from
being externally visible.
• State retention - the set of values an object holds.
• Object identity - an object can be identified and
treated as a distinct entity.
• Message passing - the ability to send messages from
one object to another.
• Classes - the templates/blueprints from which
objects are created. 6
 Encapsulation
• One of the basic concepts of OO.
• The grouping of related items into one unit.
• Attributes and behaviors are encapsulated to create
objects.
• OO modeling is close to how we perceive the world.
• Implementation details are hidden from the outside
world. We all know how to use a phone, few of us
care how it works.
• The packaging of operations and attributes
representing state into an object type so that state is
accessible or modifiable only through the objects'
interface
• Encapsulation lets builders of objects reuse already-
existing objects, and if those objects have already
been well-tested, much larger and more complex 7
systems can be created.
 Inheritance
• A subclass is derived from a superclass. An
Employee is a Person.
• The subclass inherits the attributes and behavior of
the superclass.
• The subclass can override the behavior of the
superclass.
• Notice the use of the ``Is-A'' phrase to describe
inheritance.
• Inheritance promotes re-use.

8
 Polymorphism
• Literally means ``many forms''.
• A method can have many different forms of
behavior.
• Commonly used between a set of classes that have a
common superclass.
• The sender of a message does not have to know the
type/class of the receiver.
• A single operation or attribute may be defined upon
more than one class and may take on different
implementations in each of those classes.
• An attribute may point to different objects at
different times.

9
 Abstraction with objects
• Abstraction: the act of identifying software artifacts to
model the problem domain.
• Classes are abstracted from concepts.
• This is the first step in identifying the classes that will
be used in your applications.
• Better to have too many classes than too few. (?)
• When in doubt, make it a class. (?)

10
 UML summary
• Unified Modeling Language - UML.
• A modeling language, not a method.
• Provides a graphical representation that allows
developers and architects to model a software system
before the system is ever built.
• Analogy - an architect creating a blueprint before a
house or office building is ever built.
• The UML does not specify a methodology/process.
Therefore, saying ``We use the UML methodology is
incorrect.''

11
 UML Standard diagrams
• The UML defines nine standard diagrams:
– Use Case
– Class
– Interaction
• Sequence
• Collaboration
– Package
– State
– Activity
– Component
– Deployment
12
Use Case diagram

13
 Class Diagram
• Describes the types of objects in the
system, and the static relationships
between them.
• Two main kinds of static relationships:
– Associations - Has-A
– Subtypes - Is-A

14
 Class Diagram
Is-a Relationship – Generalization

15
 Class Diagram
Has-a Relationship – Generalization

16
Class Diagram

17
 Package Diagram
• Classes are arranged into logically-
ordered packages.
• Package diagrams show relationships
and dependencies between packages.
• Package diagrams are vital for large
projects.

18
Package Diagram

19
 Sequence Diagram
• Sequence diagrams follow the flow of
entire use cases (emphasis on time
ordering).
• One sequence diagram for the basic
course and alternative courses for each
of your use cases.

20
Sequence Diagram

21
 Collaboration Diagram
• Shows how critical objects collaborate
within a use case.
• Similar to sequence diagrams.
– Focus on key transactions.
– Sequence diagrams follow the flow of entire
use cases (emphasis on time ordering).
– Collaboration diagrams add extra detail
related to timing of messages.

22
Collaboration Diagram

23
 State Diagram
• Captures the lifecycle of one or more objects.

24
 Activity Diagram
• Advanced flowcharts.
• Swimlanes let you organize a set of
activities according to who is
performing them.

25
Activity Diagram

26
 Component Diagram
• The implementation view of a system.
• Displays the organization and
dependencies between software
components.

27
Component Diagram

28
 Deployment Diagram
• The environment view of a system.
• Shows the physical relationships among software
and hardware components.
• Each node represents some computational unit -
usually a piece of hardware.
• Connections show communication paths.
• In practice probably not used very much, though
most projects have a drawing that looks something
like these.

29
Deployment Diagram

30
Object Oriented Software Development
• Larger processes/methodologies:
– Rational Unified Process (RUP)
– Object-Oriented Software Process (OOSP)
– OPEN Process
• Lightweight/agile processes:
– XP (Extreme Programming)
– Cockburn's Crystal Family
– Open Source
– Highsmith's Adaptive Software Development
– Scrum
– Coad's Feature Driven Development
– DSDM (Dynamic System Development Method)
• Larger/heavier processes are typically built around the Unified
Modeling Language, or UML. 31
 Why have a process?
• Create a product that users want.
• Make the process manageable and predictable.
• Capability Maturity Model (CMM) defines five levels of "maturity".
• Traditional development process: Waterfall (Analysis, Design, Code,
Test).
• Spiral process (Risk Analysis/Systems Analysis/User Feedback, Design,
Code, Test/User Feedback).
• Objectory - defines the four project phases of Inception, Elaboration,
Construction, Transition.
– Completion of each Objectory phase marks a major milestone.
– Objectory uses iteration to make complex projects possible.
• The process defines ways to make iterative projects manageable.
• Model the system before developing it (in the same way an architect
models a new facility before building it).

32
 Rational Unified Process
The Rational Unified Process formally consists
of the following steps:
– Inception - a discover phase, where an initial
problem statement and functional requirements
are created.
– Elaboration - the product vision and architecture
are defined, construction cycles are planned.
– Construction - the software is taken from an
architectural baseline to the point where it is
ready to make the transition to the user
community.
– Transition - The software is turned into the hands
33
of the user's community.
 Inception Phase
• Objectives
– Establish project's scope and boundary conditions.
– Determine the critical uses of the system.
– Exhibiting at least one candidate architecture against some of the
primary scenarios.
– Estimating the overall cost and schedule for the entire project.
– Estimating potential risks.
• Activities
– Formulate the scope of the project.
– Plan and prepare the business case, including alternatives for risk
management, staffing, project plan, and trade-offs between cost,
schedule, and profitability.
– Develop a candidate architecture.

34
 Inception Phase
• Artifacts
– A vision document.
– A use-case model survey.
– An initial project glossary.
– An initial business case.
– An initial risk assessment.
– A project plan.
– Other possible items:
• An initial use-case model.
• An initial domain model.
• One or more prototypes.

35
 Elaboration Phase
• Purpose
– Analyze the problem domain.
– Establish a sound architectural foundation.
– Develop the project plan.
– Eliminate the highest-risk elements.
• Objectives
– Define, validate, and baseline the architecture.
– Baseline the vision.
– Baseline a plan for the construction phase.
– Demonstrate that the baseline architecture will support the
vision for a reasonable cost in a reasonable time, or not.

36
 Elaboration Phase
• Activities
– The vision is elaborated.
– The process, infrastructure, and development environment are
elaborated.
– Processes, tools, and automation support are put into place.
– The architecture is elaborated and the components are selected.
• Outcome/Deliverables
– An 80% complete use-case model has been developed.
– Supplementary requirements are documented.
– A software architecture description is created.
– An executable architectural prototype is created.
– A revised risk list and business case are created.
– A development plan for the overall project is created.
– An updated development case is created, specifying the process to
be used.
37
 Elaboration Phase
• Other artifacts
– Construction plan.
– Software prototypes.
– Risk identification and management plan.
– A test plan.
– A data dictionary.
– A preliminary user manual.

38
 Construction Phase
• Objectives
– Minimize development costs by optimizing resources and
avoiding unnecessary scrap and rework.
– Achieving adequate quality as rapidly as practical.
– Achieving useful versions as rapidly as practical.
• Activities
– Resource management, resource control, process optimization.
– Complete component development and testing.
– Assessment of product releases against acceptance criteria.
• Deliverables
– The software product integrated on the adequate platforms.
– User manuals.
– A description of the current release.

39
 Transition Phase
• Purpose
– Transition the software to the user community.
• Beta testing.
• Parallel operation with any existing legacy system.
• Conversions of operational databases.
• Training of users.
• Product rollout.
• Objectives
– Achieving user self-supportability.
– Achieving stakeholder buy-in that the deployed product is
complete and consistent with the evaluation criteria of the vision.
– Achieving final product baseline as rapidly and cost-effectively as
possible.

40
 Transition Phase
• Activities
– Deployment-specific engineering:
• Cutover
• Commercial packaging and production
• Sales rollout
• Field personnel training
– Tuning activities, bug-fixing, and enhancement for
performance and usability.
– Assessing the deployment baseline against the vision and
acceptance criteria.

41
 Happy
Software
Programming!