Object Oriented Software& Engineering

W1- L1

SE-4302, 5311

BS(SE)-06
About Myself:

Syed Hassan Askari

Dept. of Software Engineering
The University of Lahore
Office: 111
Email: [email protected]
About Myself:
MS Research
 Domain (SE)
• Software Reuse (CBSE)
• MDA
 Problem Area
• Complex system modeling
and analysis
• Theory of Composability
• Formal Verification
 Application Domains
• Defense M&S
• Healthcare
• Robotics
 Lessons Learned?

Simplify!
Correctness, Completeness, Consistency
Correct: No requirement in the model is wrong and thus every solution
accepted by the customer (in C) is in accord with the model (in M).

Complete: No requirement in the model is missing and thus every

solution according to the model (in M) is also accepted by the customer
(in C).

Consistent: There is at least one possible solution and thus the modelled

and the possible solutions (M and P) have an intersection, as in diagram
(consistent).
 Experience is an expensive school
[Benjamin Franklin]
It is something you get just after you
needed it 
About the Course:
SE- 5311 Object Oriented Software & Engineering
 KG = Software Engineering
 Core course / Mandatory
 4 credit hours (labs)
 Timings:
 2 lectures in a week
 Consulting Hours: Monday 3:00 PM- 4:00 PM
 Wednesday 9:00 AM - 10:00 AM
Learning Resources
Training Resources
 On screen training
 UML Tools
 Java programming IDE
 C# programming IDE

 Hands on training & Discussion

 Participation is a must!

 Occasionally a learning feedback quiz!

 Participation is a must!
Assessment
 Assignments 10%
 Choose a real world system
 Perform OOSE
 Deliver as Project report
 Make groups (4-5)
 Web application development using OOSE
 Java platform (preferred)
 Presentation/demonstration at the end of the course
 Quizzes 10%
 MCQs (type?)
 Unannounced (min attendance rule)
 Mid , lab 40%
 See outline
 Final Exam 40%
What do we expect from each other?
What to expect
• Mature BS students
• Know all the ethics, rules and regulations
• who remember to mute their mobiles 
• Come on time and settle down before we begin
• If you are late, just sneak in!
• Class protocol
• You cannot speak in the class until:
• You may however ask questions, ask me to slow down or repeat!
• You are encouraged to take active part in class discussions (but
raise your hands, and let me choose)
• You are encouraged to give feedback regularly
Discussion
Discussion
• How many of you have studied SE before? Any idea of UML?
• How many of you know about Java?

• Why is object orientated software engineering important?

• Why do you think it is in your degree?
• How will you use it in the future?
WEEK I : Introduction

Concepts
 Complexity,
and the complex systems
Complex Systems
 Systems are complex by nature
 Natural systems
 Manmade systems
 The more complex the system, the more open it is to total breakdown.
 A civil engineer will never think of adding a new sub-basement to
an existing 100-story building.
 Doing that would be very costly and would undoubtedly invite
failures.

 Software systems may also involve elements of great complexity

 However, the complexity we find here is of a fundamentally different
kind
Industrial Strength Software
 Such as an industrial-strength software.
 That exhibit a very rich set of behaviors
 E.g., in reactive systems that drive or are driven by events in the
physical world
 For which time and space are scarce resources
 Applications that maintain the integrity of hundreds of
thousands of records of information while allowing concurrent
updates and queries
 Systems for the command and control of real-world entities, such as
the routing of air or railway traffic
 Elevator control system of a huge skyscraper.
Industrial Strength Software
 Software systems such as these tend to have a long life span

 Many users come to depend on their proper functioning.

 Sometimes, the safety of a huge population depends upon them

 In the world of industrial-strength software, we also find frameworks

that deals with the creation of domain-specific applications, and
programs that mimic some aspect of human intelligence.
Industrial Strength Software
 The distinguishing characteristic of industrial-strength software is that
it is intensely difficult (if not impossible) for the individual developer
to comprehend all the complexity and subtleties of its design

 Unfortunately, this complexity is an essential property of all large

software systems.

 We may master this complexity, but we can never make it go away.

Elements of software complexity
Complexity of the Problem Domain
 The problems we try to solve in software often involve
elements of inescapable complexity
 In which we usually find numerous competing and
contradictory, requirements.
 Consider the requirements for the electronic system of a
multiengine aircraft, a cellular phone switching system, or an
autonomous robot.
 The raw functionality of such systems is already quite
difficult enough to comprehend
 But now add all of the (often implicit) nonfunctional
requirements such as usability, performance, cost,
survivability, and reliability.
 This complexity usually emerges from the “communication
gap” that exists between the users and the developers
Elements of software complexity
Complexity of the Problem Domain
 Users generally find it very hard to give precise
expression to their needs in a form that developers can
understand.
 In some cases, users may have only vague ideas of what
they want in a software system.
 This is not so much the fault of either the users or the
developers of a system; rather, it occurs because each
group generally lacks expertise in the domain of the other.
 A further complication is that the requirements of a
software system often change during its development
Elements of software complexity
Difficulty of Managing the Development
Process
 The fundamental task of the software development team
is to engineer the illusion of simplicity
 They strive to write less code by inventing clever and
powerful mechanisms
 As well as by reusing frameworks of existing designs
and code.
 However, the sheer volume of a system’s requirements is
sometimes inescapable and forces us either to write a
large amount of new software or to reuse existing
software in novel ways.
 Today, it is not unusual to find delivered systems whose
size is measured in hundreds of thousands or even
millions of lines of code (and all of that in a high order
programming language).
Elements of software complexity
Difficulty of Managing the Development
Process
 This amount of work demands that we use a team of
developers, and ideally we use as small a team as
possible.
 However, no matter what its size, there are always
significant challenges associated with team development.
 Having more developers means more complex
communication and hence more difficult coordination,
particularly if the team is geographically dispersed, as is
often the case.
 With a team of developers, the key management
challenge is always to maintain a unity and integrity of
design.
Elements of software complexity
Complex Behavior due to discrete states
 Within a large application, there may be hundreds or even
thousands of variables
 as well as more than one thread of control (concurrent
systems)
 The entire collection of these variables, their current
values, and the current address and calling stack of
each process within the system constitute the present
state of the application.
 Software on digital computers, have a system with
discrete states, with a finite number of possible states
 In large systems, there is a combinatorial explosion
that makes this number very large.
Elements of software complexity
Complex Behavior due to discrete states
 Events external to a software system have the potential of
placing that system in a new state
 Furthermore, the mapping from state to state is not
always deterministic.
 In the worst circumstances, an external event may corrupt
the state of a system because its designers failed to take
into account certain interactions among events.
 There has been a dramatic rise in software-related system
failures in subway systems, automobiles, satellites, air
traffic control systems, inventory systems, and so forth.
Five attributes of a complex system
Hieratical Structure
 Complexity usually takes the form of a hierarchy
 where a complex system is composed of interrelated subsystems
 that have in turn their own subsystems, and so on
 until some lowest elementary level is reached.
 The fact that many complex systems have a decomposable, hierarchic
structure enables us to understand, describe, and even ‘see’ such
systems and their parts
 The architecture of a complex system is a function of its components
and their hierarchic relationships
Five attributes of a complex system
Relative Primitiveness
 Regarding the nature of the primitive components of a complex
system,
 The choice of what components in a system are primitive is
relatively arbitrary and is largely up to the discretion of the
observer of the system.

 What is primitive for one observer may be at a much higher level

of abstraction for another.
Abstraction focuses on the essential characteristics of some object,
relative to the perspective of the viewer
Five attributes of a complex system
Separation of Concerns
 Hierarchic systems are called decomposable because they can be
divided into identifiable parts (but these parts are not completely
independent)
 Intra-component linkages are generally stronger than inter-
component linkages
 This difference between intra- and inter- component interactions
provides a clear separation of concerns among the various parts of a
system, making it possible to study each part in relative isolation.
Five attributes of a complex system
Common Patterns
 Many complex systems are implemented with an economy of
expression/effort
 Hierarchic systems are usually composed of only a few different
kinds of subsystems in various combinations and arrangements
 In other words, complex systems have common patterns.
 These patterns may involve the reuse of small components
Five attributes of a complex system
Stable Intermediate Forms
 Complex systems tend to evolve over time.
 Specifically, “complex systems will evolve from simple systems
much more rapidly if there are stable intermediate forms than if there
are not”.
 A complex system that works is invariably found to have evolved
from a simple system that worked. . . . A complex system designed
from scratch never works and cannot be patched up to make it work.
You have to start over, beginning with a working simple system
 As systems evolve, objects that were once considered complex
become the primitive objects on which more complex systems are
built
What are more disciplined
ways to master complexity?
Decomposition
 “The technique of mastering complexity has been known since
ancient times: (divide and rule)”
 When designing a complex software system, it is essential to
decompose it into smaller parts
 each of which we may then refine independently.

Decomposition

Algorithmic Object Oriented

Algorithmic Decomposition
 The traditional view of a computer program is that of a process that
has been encoded in an executable form.
 This view originated from the fact that the first computers were
developed mainly to automate a well-defined process (i.e., an
algorithm) for numerical computation, and dates back to the first
stored-program computers.
 Accordingly, the software creation process was seen as a translation
from a description in some ‘natural’ language to a sequence of
operations that could be executed on a computer.
 As many would argue, this paradigm is still the best way to introduce
the notion of programming to a beginner, but as systems became more
complex, its effectiveness in developing solutions became suspected.
Algorithmic Decomposition
 The ‘process-centered’ approach to software development used what
is called top-down functional decomposition.
 The first step in such a design was to recognize what the process had
to deliver (in terms of input and output of the program),
 which was followed by decomposition of the process into
functional modules.
 Structures to store data were defined and the computation was
carried out by invoking the modules, which performed some
computation on the stored data elements.
Algorithmic Decomposition

Algorithmic decomposition
Algorithmic Decomposition
 The life of a process-centered design was short because changes to
the process specification required a change in the entire program.
 This in turn resulted in an inability to reuse existing code without
considerable overhead.
 As a result, software designers began to scrutinize their own
approaches and also study design processes and principles that were
being employed by engineers in other disciplines.
 Cross-pollination of ideas from other engineering disciplines
started soon after, and the disciplines of ‘software design’ and
‘software engineering’ came into existence.
Object Oriented Decomposition
 Some of the pioneers in the field of software design began to ask
whether they could not also design software using such ‘off-the-shelf’
components.
 The object-oriented paradigm, has really evolved in response to this
outlook.
 There are, of course, several differences with the hardware design
process (inevitable, because the nature of software is fundamentally
different from hardware)
 but parallels can be drawn between many of the defining
characteristics of hardware design and a good software design.
Object Oriented Decomposition
 The overall philosophy here is to define a software system as a
collection of objects of various types that interact with each other
through well-defined interfaces.
 Unlike a hardware component, a software object can be designed to
handle multiple functions and can therefore participate in several
processes.
 A software component is also capable of storing data, which adds
another dimension of complexity to the process.
Object Oriented Decomposition
 It differs from the traditional process-oriented view in the sense that
instead of implementing an entire process end-to-end and defining
the needed data structures along the way,
 we first analyze the entire set of processes and from this identify
the necessary software components.
 Each component represents a data abstraction and is designed to
store information along with procedures to manipulate the same.
 The execution of the original processes is then broken down into
several steps, each of which can be logically assigned to one of
the software components.
 The components can also communicate with each other as needed
to complete the process
Object Oriented Decomposition

Object Oriented Decomposition

Object Oriented Software development
 Object-oriented (OO) software development is nothing new
 Has been around since the early 1960s
 Although there has been a steady and significant growth in OO
development in the past 20 years
 During the development of this paradigm, as one would expect,
several ideas and approaches were tried and discarded.
 Over the years the field has stabilized so that we can safely
present the key ideas whose soundness has stood the test of time.
Object Oriented Software development
 Object-oriented analysis and design is the method that leads us to an
effective decomposition of complex systems.
 By applying object-oriented design, we create software that is
resilient to change and written with economy of expression & effort.
 We achieve a greater level of confidence in the correctness of our
software through an intelligent separation of its state space.
 The experience has shown that the most successful complex software
systems are those whose designs explicitly encompass well-
engineered object structures and embody the five attributes of
complex systems.
Object Oriented Paradigm
OO Analysis
 Object-oriented analysis is a method of analysis that examines
requirements from the perspective of the classes and objects found in
the vocabulary of the problem domain.
OO Design
 Object-oriented design is a method of design 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.
OO Programming
 Object-oriented programming is a method of implementation
 in which programs are organized as cooperative collections of objects
 each of which represents an instance of some class
 and whose classes are all members of a hierarchy of classes united via
inheritance relationships
Procedural Programming vs. OO Programming
 Procedural programming normally separates the data of a system
from the operations that manipulate the data.
 For example, if you want to send information across a network,
only the relevant data is sent with the expectation that the
program at the other end of the network pipe knows what to do
with it.
 In OO Programming the fundamental advantage is that the data and
the operations that manipulate the data (the code) are both
encapsulated in the object.
 For example, when an object is transported across a network, the
entire object, including the data and behavior, goes with it
A good example of this concept is a Web object, such as a
Java object/applet. The browser has no idea of what the
Web object will do—the code is not there previously.
When the object is loaded, the browser executes the code
within the object and uses the data contained within the
object.
Object Oriented Software development
 What exactly is an object?
 This is both a complex and a simple question.
 It is complex because learning any method of software
development is not trivial.
 It is simple because people already think in terms of objects.
 E.g., when you look at a person, you see the person as an object.
 And an object is defined by two terms: attributes and
behaviors.
 A person has attributes, such as eye color, age, height etc.
 A person also has behaviors, such as walking, talking,
breathing, and so on.
Object Oriented Software development
 In its basic definition, an object is an entity that contains both data
and behavior.
 The notion of an object is centered around a piece of data and the
operations (or methods) that could be used to represent behavior.
 This allows abstraction that is very stable since it is not dependent
on the changing requirements of the application.
Abstraction
 In order to deal with complexity, we abstract from it.
Unable to master the entirety of a complex object, we
choose to ignore its inessential details, dealing instead
with the generalized, idealized model of the object
 This is especially true if we take an object-oriented view
of the world because objects, as abstractions of entities
in the real world, represent a particularly dense and
cohesive clustering of information
Object Oriented Software development
 In its basic definition, an object is an entity that contains both data
and behavior.
 The notion of an object is centered around a piece of data and the
operations (or methods) that could be used to represent behavior.
 This allows abstraction that is very stable since it is not dependent
on the changing requirements of the application.

 The execution of each process

relies heavily on the objects to store
the data and provide the necessary
operations; with some additional
work, the entire system is
‘assembled’ from the objects.
Object
 Objects are the building blocks of an OO program.
 A program that uses OO technology is basically a collection of
objects
 Object Data
 The data stored within an object represents the state of the object.
 In OO programming terminology, this data is called attributes.
 E.g. Employee attributes could be Social Security numbers, date
of birth, gender, phone number, and so on.
 The attributes contain the information that differentiates between
the various objects,
Object
 Object Behaviors
 The behavior of an object is what the object can do.
 In procedural languages the behavior is defined by procedures,
functions, and subroutines.
 In OO programming terminology these behaviors are contained in
methods, and you invoke a method by sending a message to it.
 In our employee example, consider that one of the behaviors required
of an employee object is to set and return the values of the various
attributes. Thus, each attribute would have corresponding methods,
such as setGender() and getGender().
 In this case, when another object needs this information, it can send a
message to an employee object and ask it what its gender is.
Getters and Setters
The concept of getters and setters supports the concept of
data hiding. Because other objects should not directly
manipulate data within another object, the getters and
setters provide controlled access to an object’s data.