Lectures

(3+4+5)
22/09/2019 4:51 PM

(Lecture 3) Lecture 5
Modeling.
Abstract Class vs Concrete Class.
Definition : Modeling is the simplification of reality.
Example : We make a model bridge before constructing a real bridge. Ø Abstract Class:
○ An incomplete Superclass that defines common parts.
"A model is the simplification of our perception of reality" ○ Not instantiated. (Cannot make objects or instances)
Ø Concrete Class:
Benefits of Modeling : ○ A complete Class.
Ø Understanding why what and how's of software. ○ Describes a concept completely.
Ø Communicating ^ our understanding. ○ Is intended to be instantiated.
Ø Detection of commonalities and differences.
Ø Detection of misunderstandings and miscommunications.
State of an Object
Object Oriented Modeling.
Ø Attach behavior and information that is Important to Objects. Ø State
Ø Associate relations between objects to describe the Structure and Organization ○ Definition : "State is a collection of associations (an object has with other objects) and its own
(static+dynamic) of a real situation. attributes.
○ "The state of an object encompasses all of the (usually static) properties of the object plus the
current (usually dynamic) values of each of these properties" - "Object-Oriented Analysis and
(Lecture 4)
Design" by G. Booch
Object.
Ø State Change
○ Definition : "A state change is the transition of an object from one state to another."
Definition: "Anything to which a concept applies, in our awareness."
Ø Event
○ An event is a note-worthy change in state [Rumbaugh]
Ø Object -> A structure that has identity and properties and behavior.
Ø Object -> It is an instance of a collective concept i.e. a class.
Object Oriented Application
Ø An object has operations and attributes. For example a particular human as an example can have
○ Operations:
Definition : "A collection of discrete objects, interacting with each other"
§ Work
Properties:-
§ Dance
Ø Objects have property and behavior (causing state transition)
§ Drive
Ø Interactions through message passing
§ Jump
Ø A sender object sends a request (message) to another object (reciever) to invoke a method of the
○ Attributes:
receiver object's)
§ Height
§ Eye color
§ Hair Color
§ Weight

Ø Object Relationships are of two types. Static and Dynamic.

○ Static :
§ Existing over a long time
§ Objects know about each others existence.
○ Dynamic:
§ Two objects communicate with each other.
§ Objects sending stimuli to each other
§ Stimuli are events, messages etc. •

What is OOAD?

Ø Analysis:
○ Understanding, finding and describing -> (Concepts in the problem domain)
Ø Basic Principles of OO Ø Design:
○ Abstraction ○ Understanding and defining -> (Software solution/objects) that represent the analysis concepts
§ Focus on the essentials and will eventually be implemented in code.
§ Omits Tremendous amounts of details Ø OOAD
§ Focus : What an object is and does, rather than the nitty details of how it does it. ○ Analysis is object-oriented and design is object oriented. A software development approach that
○ Encapsulation emphasizes a logical solution based on objects.
§ A.k.a. Information hiding. ○ Methodology -> (Notation + Process)
§ Objects Encapsulate:- Ø During OOA there is an emphasis on finding and describing the objects or concepts in the problem
□ Property (variables) domain.
□ Behavior (As a collection of Methods invoked by messages) ○ For example in a library management system, the objects can be Book, Library, Members,
□ State (as a collection of instance variables) librarian etc.
§ Behavior and information is represented or implemented internally. Ø During OOD there is an emphasis on defining software objects and how they collaborate to fulfill the
requirements.
○ For example, in the library system, a Book software object may have a title attribute and a
getChapter method.

Ø Example:

○
○ Inheritance
○ Polymorphism

Class.

Definition: "A collection of objects that share common properties, attributes, behaviors and semantics in
general." or "A collection of objects with the same data structure (attributes, state variables) and
behavior (function/operations) in the solution space.

Ø Classification : Grouping common objects into a class. (generalization)

Ø Instantiation : The act of creating an instance.
Ø A class represents a template for several objects and describes how these objects are structured
internally.
Ø Objects of the same class have the same definition both for their operations and their information
structure.
Ø Class is an implementation of objects.
○

UML and OOAD

Ø UML is a standard diagramming notation

Instance. Ø As useful as it is to learn notation, there are more critical object-oriented things to learn; specifically,
how to think in objects- how to design object-oriented systems.
Definition: An instance is an object created from a class. Ø UML is not OOA/OOD or a method. It is simply a notation.
Ø Yet, one needs a language for OOA/D and "software blueprints" both as a tool of thought and as a form
Ø Instance -> (Behavior and Information structure) -> Defined by class. or communication with others.
Ø Instance -> (Current State) -> Defined by Operations performed on the instance. Ø Explore how to apply the UML in the service of doing OOA/D
Ø System Behavior -> Interaction between instances.

Is it Any Good?
Inheritance:
Ø A system which is designed and modelled using an object oriented technology is:
Ø Specialization -> The act of defining one class as a refinement of another (Generalized) ○ Easy to understand
Ø Subclass -> A class defined in terms of a specialization of a superclass using inheritance. ○ Directly related to reality
Ø Superclass -> A class serving as a base for inheritance in a class hierarchy. ○ More Flexible and resilient to change
Ø Inheritance -> Automatic duplication of superclass attribute and behavior definitions in subclass. ○ Systems can be developed more rapidly and at a lower cost.

Software Process Models

Ø Software Process Model Descriptions

○ (Software process model) -> Abstract Representation of a process. -> Presents description of a
process.
○ When we describe and discuss processes, we usually talk about the activities in these processes
such as specifying a data model, designing a user interface etc. And the ordering of these
Ø activities.
○ Processes -> (Specifying data model) -> (designing user interface) -> etc.
§ Products which are the outcome of a process activity.
§ Roles which reflect the responsibilities of the people involved in the process.
§ Notation; Activities, products.

Iterative Development

Ø Why inheritance? Ø Building the entire project at once is complex and Error Prone.
○ Show similarities Ø Traditional Approach : Linear Water fall.
○ Reuse Common Descriptions Ø Limitations of water fall model??
○ Software Reuse
○ Easy modification
○ Avoiding Redundancy

Polymorphism.

Definition: The ability to hide many different implementations behind a single interface.

Ø Solution? Build in Iterations!

○ Evolve the system, rather than implementing all. Parts at once.
○ How??
§ Pick part of functionality
§ Design
§ Implement & test
§ Pick next set of functionality … and so on.
"Objects of different classes respond to the same message differently"
○ The software is built in iterations rather than as a single do-at-once project.
Ø Why Polymorphism?
○ Allows development of flexible systems.
○ Designer only needs to specify what shall occur and not how.
○ To add an object, modification will only affect the new object, not those using it.