Object Oriented

Software Development
and UML
19CSE204: Object Oriented Paradigm

Dr. Prabu M
 Why OO?
• Benefits of object-oriented programming
• Symptoms of software development problems
• Root causes of project failure
• Software development best practices
 Benefits of OO
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
 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.
 Root cause 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.
Software development
best practices
• Develop software iteratively.
• Manage requirements.
• Use component-based architectures.
• Visually model software.
• Verify software quality.
• Control changes to software.
1. Encapsulation - the grouping of related ideas
into unit. Encapsulating attributes and
behaviors.
2. Inheritance - a class can inherit its behavior
from a superclass (parent class) that it extends.
3. Polymorphism - literally means ``many
forms''.
4. Information/implementation hiding - the use Introduction to
of encapsulation to keep implementation details
from being externally visible. OO concepts
5. Object identity - an object can be identified
and treated as a distinct entity.
6. Message passing - the ability to send messages
from one object to another.
7. Classes - the templates/blueprints from which
objects are created.
 Encapsulation
The grouping of related items into one unit.
• One of the basic concepts of OO.
• 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 systems can be created.
 Inheritance

• A subclass is derived from a superclass.

• The subclass inherits the attributes and behavior
of the superclass.
• The subclass can override the behavior of the
superclass.
• Inheritance promotes re-use.
 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
 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.
 Message passing
• Objects communicate by sending messages.
• Messages convey some form of information.
• An object requests another object to carry out an activity by sending it
a message.
• Most messages pass arguments back and forth.
• Meilir Page-Jones defines three types of messages:
1. Informative - send information for the object to update itself.
2. Interrogative - ask an object to reveal some information about itself
3. Imperative - take some action on itself, or another object
• Grady Booch defines four types of messages:
1. Synchronous - receiving object starts only when it receives a message from a
sender, and it is ready.
2. Balking - sending object gives up on the message if the receiving object is not
ready to accept it.
3. Timeout - sending object waits only for a certain time period for the receiving
object to be ready to accept the message.
4. Asynchronous - sender can send a message to a receiver regardless of whether
the receiver is ready to receive it.
 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 or process. Therefore,
saying ``We use the UML methodology is incorrect.''
 Typical UML diagrams

• Each UML diagram is designed to let developers and

customers view a software system from a different perspective
and in varying degrees of abstraction. UML diagrams
commonly created in visual modeling tools include
• Use case diagram
• Class diagram
• Interaction diagrams
– Sequence diagram
– Collaboration diagram
• State diagram
 Use case diagram
• displays the relationship among actors
and use cases
 Class diagram
• Models class structure and contents using design
elements such as classes, packages and objects. It
also displays relationships such as containment,
inheritance, associations and others
• Widely used to describe the types of objects in a
system and their relationships.
• Model class structure and contents using design
elements such as classes, packages and objects.2
• Describe three different perspectives when designing
a system: conceptual, specification, implementation.
• These perspectives become evident as the diagram is
created and help solidify the design.
 Class diagram
• Classes are composed of three things: a name,
attributes, and operations.
 Class diagram
• Class diagrams also display relationships such as
containment, inheritance, associations and
others. Below is an example of an associative
relationship
 Class diagram
• Another common relationship in class diagrams is a
generalization. A generalization is used when two
classes are similar, but have some differences.
 Class diagram
• When to Use: Class Diagrams
– Class diagrams are used in nearly all Object Oriented software
designs. Use them to describe the Classes of the system and their
relationships to each other
• How to Draw: Class Diagrams
– Class diagrams are some of the most difficult UML diagrams to
draw. To draw detailed and useful diagrams a person would have to
study UML and Object Oriented principles for a long time.
 Class diagram
• Before drawing a class diagram consider the three
different perspectives of the system the diagram will
present; conceptual, specification, and
implementation. Try not to focus on one perspective
and try see how they all work together.
• When designing classes consider what attributes and
operations it will have. Then try to determine how
instances of the classes will interact with each other.
These are the very first steps of many in developing a
class diagram. However, using just these basic
techniques one can develop a complete view of the
software system.
 Interaction diagram
• Sequence Diagram displays the time sequence of the objects
participating in the interaction. This consists of the vertical
dimension (time) and horizontal dimension (different objects)
• Collaboration Diagram displays an interaction organized
around the objects and their links to one another. Numbers
are used to show the sequence of messages
 When to use interaction diagrams
• Interaction diagrams are used when you want to
model the behavior of several objects in a use
case.
• They demonstrate how the objects collaborate
for the behavior.
• Interaction diagrams do not give a in depth
representation of the behavior.
• If you want to see what a specific object is doing
for several use cases, use a state diagrams.
• To see a particular behavior over many use
cases or threads, use an activity diagrams
 How to draw interaction diagram
• Sequence diagrams, collaboration
diagrams, or both diagrams can be used
to demonstrate the interaction of objects
in a use case.
• Sequence diagrams generally show the
sequence of events that occur.
• Collaboration diagrams demonstrate how
objects are statically connected.
• Both diagrams are relatively simple to
draw and contain similar elements
 Sequence diagram
• Sequence diagrams demonstrate the behavior
of objects in a use case by describing the
objects and the messages they pass. the
diagrams are read left to right and descending.
Sequence diagram
Sequence diagram
Sequence diagram
 Collaboration diagram
• They show the relationship between objects and the order of
messages passed between them
• The objects are listed as icons and arrows indicate the
messages being passed between them.
• The numbers next to the messages are called sequence
numbers. As the name suggests, they show the sequence of
the messages as they are passed between the objects.
Collaboration diagram
Collaboration diagram
 State diagram
• displays the sequences of states that an object of an
interaction goes through during its life in response to
received stimuli, together with its responses and
actions
 State diagram
• State diagrams are used to describe the behavior of a
system.
• State diagrams describe all of the possible states of an object
as events occur.
• Each diagram usually represents objects of a single class and
track the different states of its objects through the system
 When to use state diagram
• Use state diagrams to demonstrate the behavior
of an object through many use cases of the
system.
• Only use state diagrams for classes where it is
necessary to understand the behavior of the
object through the entire system.
• Not all classes will require a state diagram and
state diagrams are not useful for describing the
collaboration of all objects in a use case.
• State diagrams are often combined with other
diagrams such as interaction diagrams and
activity diagrams
 How to draw state diagram
• State diagrams have very few elements.
• The basic elements are rounded boxes representing
the state of the object and arrows indicting the
transition to the next state.
• The activity section of the state symbol depicts what
activities the object will be doing while it is in that state
 How to draw state diagram
• All state diagrams begin with an initial state of the
object that is the state of the object when it is created.
• After the initial state the object begins changing states,
conditions based on the activities can determine what
the next state the object transitions to
 How to draw state diagram
• Below is an example of a state diagram might look like
for an Order object.
 How to draw state diagram
A super-state is used when many transitions lead to the a certain
state. Instead of showing all of the transitions from each state to
the redundant state a super-state can be used to show that all
of the states inside of the super-state can transition to the
redundant state.
ATM – State Diagram