OBJECT-ORIENTED

SOFTWARE ENGINEERING
UNIT 03 : Object Orientation Fundamentals

© 2019, PRAMOD PARAJULI

 Disclaimer
These slides are part of teaching materials for Object Oriented
Software Engineering (OOSE). These slides do not cover all aspect of
learning OOSE, nor are these be taken as primary source of
information. As the core textbooks and reference books for learning
the subject has already been specified and provided to the students,
students are encouraged to learn from the original sources.

Contents in these slides are copyrighted to the instructor and

authors of original texts where applicable.
Introduction of OOAD, OO Life Cycle

Unified Modeling Language

Models, use cases

(Rational) Unified process

UNIT 03: Object Orientation Fundamentals

SOFTWARE ENGINEERING
ORGANIZATIONS AND WORKFLOWS
 System’s view
 Data-driven view
 Functional view
 Event-based view
 State machine view
 SOFTWARE AS A PRODUCT
 Programs  Configuration data
 Associated documents  Additional services –
– System documentation trainings
– Manuals and websites
– User documentation/guide
– Advertisements
 SOFTWARE TYPES
 System software
Generally, two types  Application software
 Generic  Mobile software/app
 Web applications
– Developers get full control  Production line software
 Bespoke (customised)  Embedded software
 AI software
– Users get full control  Ubiquitous computing
 Wearable computing
 OpenSource software
(Classroom discussion)  Legacy software
 ...
 SOFTWARE CHARACTERISTICS
 Software is developed,  Flexibility vs. complexity
but not manufactured.  Software qualities
– Portability
 Software doesn’t wear – Maintainability
out. – Modular
– Intuitive (ease of use)
 Most software are – Reusability
custom built. – Stable
– Dependable
 SOFTWARE EVOLUTION

THE EARLY YEARS THE SECOND ERA THE THIRD ERA THE FOURTH ERA
1950s 1960s – 1970S 1980s – 1990S 2000s –

Batch oriented Multi-user Distributed systems Powerful desktops

Limited distribution Real-time Embedded intelligence OO Technologies
Low cost h/w Expert Systems
Custom Software Database
Consumer impact Parallel computing
Product Software Data-centred
 CURRENT TREND
 Lean development  Data analytics
 Cloud computing  Millions of lines of code
 Cognitive computing  Natural interactions
 Software as a Service  Collaborative development
 AI as a Service!  Web apps
 Wearable computing  UX first!
 Quantum computation  Disruptive technologies!
 Complex Systems

❃ Why would a system be complex?

 SOFTWARE COMPLEXITY
 Need to deliver – flexibility, solid
performance
 End-users have different views
 Problem domain is complex
 Difficulty of managing the
development process
 Difficulty in modeling behavior of
discrete systems
 5 ATTRIBUTES OF COMPLEX SYSTEM
 Hierarchic structure – follow hierarchic structure of some kind
 Relative primitives – relative measures on primitive operations
 Separation of concerns – decomposable and non-decomposable
components
 Common patterns – repetitive patterns in the structure
 Stable intermediate forms – complex system when evolves from stable
simple system
 ORGANISED AND DISORGANISED
COMPLEXITY
 Finding abstractions help
organise complexity
 Canonical form of complexity –
hierarchical: part of, is a
 Humans are limited in
understanding complexity in
detail
 MANAGING CHAOS
 Decomposition – decompose system into manageable
chunks (algorithmic decomposition, object-oriented
decomposition)
 Abstraction – generalized common components
 Hierarchy – follow hierarchical structure
 DESIGNING COMPLEX SYSTEMS
 Engineering is a science as well as an art
 Design - Stroustrup suggests, “the purpose of design is to create a clean and
relatively simple internal structure, sometimes also called an architecture. . . . A
design is the end product of the design process”
 Model building – multiple models
 Software design – using notation, process, and tools
 MODELS OF ‘OOSE’
 Object oriented analysis and design

 Unified Modeling Language

 Rational Unified Process

 Open Unified Process

 USEFUL LINKS
 Software Engineering Institute: sei.cmu.edu
 Object Management Group: omg.org
 Rational Unified Process: ibm.com
 Open Unified Process: epf.eclipse.org/wikis/openup/
 Roger S. Presman: rspa.com/spi/
SOFTWARE ENGINEERING

❃ What is software engineering?

 SOFTWARE DEV. LIFE CYCLE

Conceptualisation ... Decommissioning

 SOFTWARE DEV. LIFE CYCLE

Integration and
Specification Development Deployment
testing

OOSE UNIT 01 - Introduction

 UNIT 03: Object Orientation Fundamentals and UML

INTRODUCTION TO OBJECT ORIENTATION

Reference: Philippe Kruchten, The Rational Unified Process – An Introduction, Third Edition, Addison Wesley, 2003
 How object-orientation helps model complex systems?
 How object-orientation helps reduce
software/development risks?
 What are software development problems?
 What are the best practices of software development ?
 BASIC CONSIDERATION
The world consists of;
 Objects, and
 Events
 FUNCTIONAL VS OBJECT-ORIENTED
Functional approach Object oriented approach
 Functions  Objects – properties (attributes)
 Modules
 Data structures  Events – methods (capabilities)
 Shared space (monolithic)
WHY OBJECT ORIENTED APPROACH?
SOFTWARE PROJECTS
 SOFTWARE DEVELOPMENT PROBLEMS -
SYMPTOMS
 Inaccurate understanding of end-  Poor software quality
user needs  Unacceptable software
 Inability to deal with changing performance
requirements  Team members in each other's way,
 Modules that don't fit together making it impossible to reconstruct
 Software that's hard to maintain or who changed what, when, where,
extend and why
 Late discovery of serious project  An untrustworthy build-and-
flaws release process
SOFTWARE DEVELOPMENT PROBLEMS - ROOTS
 Ad hoc requirements management  Insufficient testing
 Ambiguous and imprecise  Subjective assessment of project
communication status
 Brittle architectures  Failure to attack risk
 Overwhelming complexity  Uncontrolled change propagation
 Undetected inconsistencies in  Insufficient automation
requirements, designs, and
implementations
 SOFTWARE DEVELOPMENT – BEST
PRACTICES
1. Develop software 4. Visually model
iteratively. software.
2. Manage requirements. 5. Continuously verify
3. Use component-based software quality.
architectures 6. Control changes to
software.
 1. DEVELOP SOFTWARE ITERATIVELY
1. Serious misunderstandings are made evident early in the
lifecycle when it's possible to react to them.
2. This approach enables and encourages user feedback so as to
elicit the system's real requirements.
3. The development team is forced to focus on those issues that
are most critical to the project and are shielded from those
issues that distract them from the project's real risks.
4. Continuous, iterative testing enables an objective
assessment of the project's status.
 1. DEVELOP SOFTWARE ITERATIVELY
5. Inconsistencies among requirements, designs, and
implementations are detected early.
6. The workload of the team, especially the testing team, is
spread more evenly throughout the project's lifecycle.
7. The team can leverage lessons learned and therefore can
continuously improve the process.
8. Stakeholders in the project can be given concrete evidence of
the project's status throughout its lifecycle.
WATERFALL MODEL
ITERATIVE DEVELOPMENT
 2. MANAGE REQUIREMENTS
A condition or capability a system must have.
1. A disciplined approach is built into requirements management.
2. Communications are based on defined requirements.
3. Requirements can be prioritized, filtered, and traced.
4. An objective assessment of functionality and performance is possible.
5. Inconsistencies are detected more easily.
6. With suitable tool support, it is possible to provide a repository for a
system's requirements, attributes, and traces, with automatic links to
external documents.
 3. USE COMPONENT-BASED
ARCHITECTURE
Organisation of building blocks and their interactions.

Helps decision-making for

 The organization of a software system
 The selection of the structural elements and their interfaces by which the system is
composed
 Their behavior, as specified by the collaborations among those elements
 The composition of these structural and behavioral elements into progressively
larger subsystems
 The architectural style that guides this organization: these elements and their
interfaces, their collaborations, and their composition
 3. USE COMPONENT-BASED
ARCHITECTURE
Benefits
1. Components facilitate resilient architectures.
2. Modularity enables a clear separation of concerns among elements of a system
that are subject to change.
3. Reuse is facilitated by leveraging standardized frameworks (such as
COM+, CORBA, and EJB) and commercially available components.
4. Components provide a natural basis for configuration management.
5. Visual modeling tools provide automation for component-based development.
 4. VISUALLY MODEL SOFTWARE
Model is a simplified representation. Modeling is a process of
building a model with an objective.
 4. VISUALLY MODEL SOFTWARE
Benefits

1. Use cases and scenarios unambiguously specify behavior.

2. Models unambiguously capture software design.
3. Non-modular and inflexible architectures are exposed.
4. Details can be hidden when necessary.
5. Unambiguous designs reveal their inconsistencies more readily.
6. Application quality starts with good design.
7. Visual modeling tools provide support for UML modeling.
5. CONTINUOUSLY VERIFY SOFTWARE
QUALITY

Cost of fixing problem

 5. CONTINUOUSLY VERIFY SOFTWARE
QUALITY
Benefits
1. Project status assessment is made objective, not subjective, because test results,
not paper documents, are evaluated.
2. This objective assessment exposes inconsistencies in requirements, designs, and
implementations.
3. Testing and verification are focused on areas of highest risk, thereby increasing
the quality and effectiveness of those areas.
4. Defects are identified early, radically reducing the cost of fixing them.
5. Automated testing tools provide testing for functionality, reliability, and
performance.
 6. CONTROL CHANGES TO SOFTWARE

 Multiple stakeholders might result into chaos.

 Dividing the software team into different teams, delegating

tasks, and proper coordination is required.
 6. CONTROL CHANGES TO SOFTWARE
Benefits
1. The workflow of requirements changes is defined and repeatable.
2. Change requests facilitate clear communications.
3. Isolated workspaces reduce interference among team members working
in parallel.
4. Change rate statistics provide good measurements for objectively
assessing project status.
5. Workspaces contain all artifacts, which facilitates consistency.
6. Change propagation is assessable and controlled.
7. Changes can be maintained in a robust, customizable system.
 UNIT 03: Object Orientation Fundamentals and UML
OBJECT ORIENTED DEVELOPMENT CYCLE

Reference: Brown et al., Object-oriented Analysis 2nd. Ed., Wiley, 2001

OBJECT ORIENTED DEVELOPMENT CYCLE
Phase Activity Models produced Components
• Project scope,
• feasibility study,
• context diagram,
Requirements
Analysis OOA • class diagram (entity classes, interface classes, control classes),
model • behavior diagrams (statechart diagrams, collaborations and
CRC cards),
• sequence diagrams, activity diagrams

Design versions
Design OOD
of the OO models
Construction OOP Actual system
Testing OO Testing Working system
Maintenance All of the above All of the above
EXAMPLE – UNIFIED PROCESS
EXAMPLE
EXAMPLE
ACCORDING TO PRESSMAN
 UNIT 03: Object Orientation Fundamentals and UML
THE OBJECT MODEL

References:
• Booch et al., The Unified Modeling Language User Guide, Pearson. and
• Booch et al., Object-Oriented Analysis and Design with Applications, 3 rd ed., Addison-Wesley., Chapter 2 and 3.
Models: simplification of reality
 MODELS
 Are developed so that we can better understand the
system we are developing.

– Help us visualise a system as it is or as we want it to be

– Permit us to specify the structure or behavior of the system
– Give us a template that guides us structuring a system
– Document decisions we made
 MODELS
Different levels

 Conceptual level
 Logical level
 Physical level
 MODELING
Principles of modeling
1. The choice of what models to create has a profound influence on the
how a problem is attacked and how a solution is shaped.
2. Every model may be expressed at different level of precision.
3. The best models are connected to reality.
4. No single model is sufficient. Every nontrivial system is best
approached through a small set of nearly independent models.
 OBJECT-ORIENTED MODELING
Object-oriented perspective
 Basic building block of a software system is the object or
class.
 Object is a thing.
 Class is a set of common objects.
 Every object has;
– Identity (name)
– State (properties/data associated)
– Behavior (methods)
 THE OBJECT MODEL
 Generations of programming languages allowed the
shift from programming-in-the-small to programming-
in-the-large
– Object-oriented languages (Smalltalk, C++, Ada83, Eiffel)
– Emergence of framework (Visual Basic, Java, Python, J2EE, .NET,
Visual C#, Visual Basic .NET)
 THE OBJECT MODEL
 Topology of languages
 THE OBJECT MODEL
 Topology of languages
 THE OBJECT MODEL
 Topology of languages
 THE OBJECT MODEL
 Object-oriented languages
 THE OBJECT MODEL
Foundations
 Object model is influenced by many factors, not just object-
oriented programming. e.g. design of user interfaces,
databases, and computer architectures.
 An object – maintains integrity and there exist invariant
properties that characterize an object and its behavior.
 Objects cooperate with other!
 THE OBJECT MODEL
Object-oriented programming (OOP)
 A method of implementation in which programs are
organised as cooperative collections of objects.
 Three features;
i. OOP uses objects, not algorithms, as its fundamental building
blocks (‘has a’);
ii. Each object is an instance of some class; and
iii. Classes may be related to one another via inheritance (‘is a’). (no
inheritance  abstract data types, e.g. stack)
 THE OBJECT MODEL
Object-oriented programming (OOP)
A language is object-oriented if and only if it satisfies the
following requirements :
 It supports objects that are data abstractions with an
interface of named operations and a hidden local state.
 Objects have an associated type [class ].
 Types [classes ] may inherit attributes from supertypes
[superclasses ].
 THE OBJECT MODEL
Object-oriented design (OOD)
A design method encompassing the process of object-oriented
decomposition and a notation for depicting both logical and
physical as well as static and dynamic models of the system
under design.
 Design
 Notation
 THE OBJECT MODEL
Object-oriented analysis (OOA)
A method of analysis that examines requirements from the
perspective of the classes and objects found in the vocabulary of
the problem domain.

OOA  OOD  OOP

 THE OBJECT MODEL
Elements of object model
 Abstraction – essential characteristics
 Encapsulation – compartmentalizing the elements of an abstraction
that constitute its structure and behavior
 Modularity – system decomposed into cohesive and loosely coupled
modules
 Hierarchy – inheritance, multiple inheritance, avoid redundancy
 THE OBJECT MODEL
Elements of object model
 Typing – precise characterisation of structural or behavioral properties
(enforcement of the class of an object), static typing, dynamic typing
(polymorphism)
 Concurrency – active object can be distinguished from one
that is not active
 Persistence – state and class of an object is consistent across
time or space
 THE OBJECT MODEL
Benefits
 Expressive – real world objects and their interactions are
better expressed using OM
 Helps in complex system modeling
 OM encourages reuse
 Modular design allows resilient change
 CLASSES AND OBJECTS
 Real-world consists of objects

 An object
– A tangible and/or visible thing
– Something that may be comprehended intellectually
– Something toward which thought or action is directed
 OBJECTS
 An object
– Has state – static properties and current properties
(dynamic)
– Has well-define behavior – how object acts and reacts in
terms of its state changes and message passing (operations:
modifier, selector, iterator, constructor, destructor; roles and
responsibilities)
– Has a unique identity – every object should be
distinguishable from other objects
 OBJECTS
Relationship among objects
 Two types
– Links – physical/conceptual connection between two
objects (peer-to-peer or client/supplier)

– Aggregation – whole/part hierarchy

 OBJECTS
Relationship among objects
 Links – show message passing
 While passing message, an object may play one of three roles;
– Controller
– Server
– Proxy (both controller and server, represents a real-world object in the
domain of the application)
 OBJECTS
Relationship among objects
 Links – show message passing
 OBJECTS
Relationship among objects
 Links
– Visibility - for an object to receive messages, it must be visible to
others.
– Synchronisation – objects may be active in sequence, guarded (mutual
exclusion), or concurrent
 OBJECTS
Relationship among objects
 Aggregation – whole/part hierarchy
 CLASSES
 Classes provide framework for objects

 An object is an instance of a class.

 A class represents a set of objects that share common

structure and a common behavior.
 CLASSES
 Interface of a class
– Public – components of a class accessible to all clients)
– Protected – accessible to itself and its subclasses
– Private – accessible to itself
– Package – accessible by classes in the same package
 CLASSES
 Relationship among classes
– Association
• Semantic dependencies – e.g. a weather station has multiple
sensors.
• Multiplicity – one-to-one, one-to-many, many-to-many
– Inheritance – a class may inherit a super-class
• Single inheritance
• Polymorphism
• Multiple inheritance
 CLASSES
 Relationship among classes
– Aggregation - whole and part relationship (has a), enforces physical
containment
– Dependencies – when one element is dependent on other,
e.g. one module dependent on other.
 INTERPLAY OF CLASSES AND OBJECTS
 Identify the classes that form the vocabulary of the
problem domain.
 Invent the structures whereby sets of objects work
together to provide the behaviors that satisfy the
requirements of the problem.
BUILDING QUALITY CLASSES AND OBJECTS
 Measuring quality of abstraction –
– Coupling,
– Cohesion,
– Sufficiency,
– Completeness,
– Primitiveness

 Choosing operations
– Functional semantics – focusing on reusability, complexity, applicability and
implementation performance
– Time and space semantics
BUILDING QUALITY CLASSES AND OBJECTS
 Choosing relationships
– Law of demeter – the methods of a class should not depend on structure of other classes,
except its immediate super class.
– Visibility

 Implementation
– Proper representation
– Proper packaging
 UNIT 03: Object Orientation Fundamentals and UML

CLASSIFICATION
References:
• Booch et al., Object-Oriented Analysis and Design with Applications, 3 rd ed., Addison-Wesley., Chapter 4.
 PROPER CLASSIFICATION
 Classification helps generalisation, specialisation,
aggregation hierarchies among classes.
 Objects, classes, hierarchies, associations etc. need to
properly identified.
 Help maintain proper level of cohesion and coupling.
 Challenges – there is no perfect classification, intelligent classification
requires tremendous amount of creative insight
 IDENTIFYING CLASSES AND OBJECTS
Three approaches to classification;
 Classical cetegorisation - All the entities that have a given property
or collection of properties in common form a category. Such properties
are necessary and sufficient to define the category. e.g. employee
 Conceptual clustering – classes are generated by formulating
conceptual descriptions then classifying the entities according to the
descriptions. e.g. love songs
 Prototype theory – class represented by prototypical object e.g. game
 IDENTIFYING CLASSES AND OBJECTS

We will revisit identification of classes and objects in Unit

4. Refer to

 Object-oriented analysis (Chapter 4.2, p. 131)

 Key Abstractions and mechanisms (Chapter 4.3, p. 138)
 UNIT 03: Object Orientation Fundamentals and UML

UNIFIED PROCESS
References:
Schach, S. R., 2008, Object-oriented software engineering, McGrawHill (Chapter – 3)
Bruegge B., and Dutoit A. H. 2010, Object-oriented Software Engineering using UML, Patterns and Java, 3rd ed., Prentice Hall (Chapter 15)
 UNIFIED SOFTWARE DEVELOPMENT PROCESS
 Development time – divided into cycles
 Cycles – birth, childhood, adulthood, retirement etc.
 Each cycle end with release of the system
 Each cycle can be in one of four phases
 UNIFIED SOFTWARE DEVELOPMENT PROCESS
 Each phase might contain a number of iterations
 Each iteration
– Use use-cases
– Mitigate risks in the iteration
– Acts as a project
 Activities, also known as workflows, in each cycle
are performed in parallel
UNIFIED PROCESS - WORKFLOWS
 UNIFIED PROCESS - WORKFLOWS
 Engineering workflows
– Requirements – analysis of application domain and creation of
specifications
– Design – design of the software – creation of solution
– Implementation - code
– Test – test cases, benchmarking
 UNIFIED PROCESS - WORKFLOWS
 Supporting workflows
– Management – project planning
– Environment – development environment, automation of the
software process
– Assessment – verification and validation (reviews, walkthroughs and
inspections)
– Deployment – configuration, transition of the software system to the
end user
UNIFIED PROCESS - WORKFLOWS
IBM RATIONAL UNIFIED PROCESS
❃ Read Chapter 3 from book Object-oriented
software engineering by Stephen R. Schach.
End of Unit 03 : Object Orientation
Fundamentals