Download - Object analysis and design
![Page 1: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/1.jpg)
Object OrientedAnalysis & Design
Amandeep S. PattiAP, Comp. Sc., PCTE
![Page 2: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/2.jpg)
Object Oriented Analysis,Modeling and Design• OO is a SW development approach• that is based on modeling objects from the
real world • and then using the model to build a Language-
independent design.
2
![Page 3: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/3.jpg)
Object-oriented approach is used by:
• OO Languages• OO Databases• OO Modeling• OO Methodology
3
![Page 4: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/4.jpg)
Object-oriented approach promotes:
• Better Understanding of requirements,• Visualize a problem using graphical notations,• Cleaner designs,• And more maintainable systems.
4
![Page 5: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/5.jpg)
Object oriented approachis divided into:• A set of object-oriented concepts• A language-independent graphical notation
which can be used to analyze problem requirements
• Design a solution to the problem,• And then implement the solution in a
programming language or in database
5
![Page 6: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/6.jpg)
Object-Orientation
• A way to organize software as a collection of discrete objects– that incorporate both data structure and
behavior.
• This contrasts with previous programming approaches in which– data structure and behavior are only loosely
connected.
6
![Page 7: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/7.jpg)
Major aspects underobject-orientation:• Identity• Classification• Inheritance• Polymorphism
7
![Page 8: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/8.jpg)
Identity
• Quantized data into – discrete, distinguishable entities called objects.
• Objects can be – concrete or conceptual
• Objects do have their own distinct identity– even if their attributes are same.
• Objects do have unique handle. – In comparison to real world where objects simply
exists, in programming languages each object has a unique handle by which it is referenced.
8
![Page 9: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/9.jpg)
Classification
• Objects with the same data structure (attributes) and behavior (operations) are grouped into a class.
• Class is an abstraction– that describes important properties to an
application– and ignores the rest.
• Each object is an instance of its class.
9
![Page 10: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/10.jpg)
Inheritance
• Sharing or attributes and operations– among classes based on hierarchical relationship.
• A superclass is general information– that subclasses refine and elaborate.
10
![Page 11: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/11.jpg)
Polymorphism
• Same operation may behave differently for different classes.
• An operation is a procedure or transformation – that an object performs or is subject to.
• An implementation of operation by a specific class– is called a method.
11
![Page 12: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/12.jpg)
OO Development
• A way of thinking about SW based on abstractions– that exist in the real world as well as in the
program.
• Development refers to the SW Life Cycle– analysis, design, and implementation.– Integration, maintenance, and enhancement• is automatically facilitated by a clean design in a
precise notation.
12
![Page 13: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/13.jpg)
OO Development
• Modeling concepts, not implementation• OO Methodology• Three Models
13
![Page 14: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/14.jpg)
Modeling concepts,not implementation• Front-end conceptual issues, rather than back-
end implementation details.• OO Modeling as a conceptual process– Independent of a programming language
• Serves as a medium– for specifications, analysis, documentation,
interfacing and programming
14
![Page 15: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/15.jpg)
OO Methodology
• OO methodology consists of– Building a model of an application– Then adding details to it during design.
• Stages– System conception– Analysis– System design– Class design– Implementation
15
![Page 16: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/16.jpg)
OO Themes
• Abstraction• Encapsulation• Combining Data and behavior• Sharing• Emphasis on the Essence of an Object• Synergy
16
![Page 17: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/17.jpg)
Modeling Concepts
• A Model is an abstraction of something for the purpose of understanding it before building it.
• Modeling serves several purposes:– Testing a physical entity before building it.– Communication with customers.– Visualization.– Reduction of complexity by omitting nonessential
details.
17
![Page 18: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/18.jpg)
Object Modeling Technique – OMT
• Different models are used to describe a system from different viewpoints:– Object Model / Class Model– Dynamic Model / State Model– Functional Model / Interaction Model
• Three models are separate parts to describe system but are cross-linked.
18
![Page 19: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/19.jpg)
Object Model / Class Model
• To describe static structure of the objects• To describe relationship among various
objects• Contains object/class diagrams– Object/Class diagram is a graph diagram where
nodes are objects/classes and arcs are relationships among objects/classes.
19
![Page 20: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/20.jpg)
Dynamic Model / State Model
• To describes the aspects of an object that change over time.
• Specifies and implements control.• Contains state diagrams– State diagram is a graph diagram where nodes are
states and arcs are transitions between states caused by events.
20
![Page 21: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/21.jpg)
Functional Model / Interaction Model
• Describes the data value transformations within a system.
• Contains Data Flow diagrams– Data flow diagram is a graph whose nodes are
processes/datastores and whose arcs are data flows.
21
![Page 22: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/22.jpg)
Object Modeling:
• Describes a model which capture the static structure of a system– by specifying the objects in the system and
relationship between them.
• Most important model– as it emphasize building a system around objects
rather than around functionality.
22
![Page 23: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/23.jpg)
Objects & Classes:
• Objects– Corresponds to real world entities
• Classes– Collection of the similar objects or entities.
• Each object is associated with the data of a class which they are created.
23
![Page 24: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/24.jpg)
Object Diagrams:
• Provide a format for graphical notation for modeling the objects, classes and relationships to on another.
• Types of object diagrams:– Class Diagram– Instance Diagram
24
![Page 25: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/25.jpg)
Class Diagrams:
• Is a schema, pattern, or template for describing many possible instances of data.
• describe the general case in modeling a system.
25
![Page 26: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/26.jpg)
Instance Diagrams:
• Describes object instances and show how a particular set of objects relate to each other.
• Used mainly to show examples to help to clarify a complex class diagram.
26
![Page 27: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/27.jpg)
Attributes:
• Data value held by the objects in class.• Each attribute has a value for each object
instance.• Different object instances may have the same or
different values for a given attribute.• Each attribute name is unique within a class.• Should describe values not objects.• Attributes are listed in the second part of the
class box.27
![Page 28: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/28.jpg)
Operations and Methods:
• An operation is a function or transformation – That may be applied to or by objects in class.
• All objects in a class share same operations.• Same operation may apply to many different
classes and is called polymorphic.• A method is the implementation of an operation
for a class.• Operations listed in the lower part of the class
box.28
![Page 29: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/29.jpg)
Links & Associations:
• A Link is a physical or conceptual connection between object instances.
• An association describes a group of links– with common structure and common semantics.
• Association and links often appear as verbs in the problem statements.
• An association describes a set of potential links in the same way that a class describes a set of potential objects.
29
![Page 30: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/30.jpg)
Degree of association:
• Describes the number of classes connected by association:– Unary association or reflexive association– Binary association– Ternary association– Quaternary association– Higher order association
30
![Page 31: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/31.jpg)
Multiplicity:
• Denotes the cardinality of the association.• It shows how many instances of one class may
relate to a single instance of an associated class.– One-to-one– One-to-many– Many-to-many
31
![Page 32: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/32.jpg)
Role Names:
• Uniquely identify one end of an association.• Roles often appear as nouns in the problem
statement.
32
![Page 33: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/33.jpg)
Ordering:
• Objects on the “many” side of an association have no explicit order, and is regarded as a set.
33
![Page 34: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/34.jpg)
Qualification:
• Special attribute that reduces the effective multiplicity of an association.
• A qualified association relates two object classes and a qualifier.
34
![Page 35: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/35.jpg)
Aggregation:
• Is an extension of association• Is the “part-whole” or “a-part-of” relationship– In which objects representing the components of
something are associated with an object representing the entire assembly.
35
![Page 36: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/36.jpg)
Generalization:
• Is the relationship between a class and one or more refined versions of it.
• Class being refined is called the superclass and each refined version is called a subclass.
• Is a bottom-up process.• Attributes and operations common to a group
of subclasses– are attached to the superclass– and shared by each subclass
36
![Page 37: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/37.jpg)
Notation for Generalization:
• The notation for generalization is a triangle– Connecting a superclass to its subclasses.– The superclass is connected by a line to the apex
or the triangle.– The subclasses are connected by lines to a
horizontal bar attached to the base of the triangle
• The dangling subclass ellipsis is used to indicate that there are additional subclasses that are not shown.
37
![Page 38: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/38.jpg)
Use of Generalization:
• Useful for conceptual modeling as well as for implementation
• Facilitates modeling– by structuring classes– capturing what is similar and what is different
about classes.
38
![Page 39: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/39.jpg)
Specialization:
• Is a mechanism for refining the definition or members of class.
• Is a top-down process.
39
![Page 40: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/40.jpg)
Inheritance:
• Is a mechanism of sharing attributes and operations among classes.
• May be of type:– Single Inheritance– Multiple Inheritance
40
![Page 41: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/41.jpg)
Overriding Features:
• A Subclass may override a superclass feature by defining a feature with the same name.
• The overriding feature refines and replaces the overridden feature.
41
![Page 42: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/42.jpg)
Association and Aggregation Comparison :• Both concepts provide the relationship among
the classes.• Aggregation is not an independent concept– but a special form of association.– exists after the existing of association.
• Associations are bidirectional but aggregations are antisymmetric.
42
![Page 43: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/43.jpg)
Aggregation and Generalization Comparison :• Aggregation provides the relationship
between classes, while generalization is a process to combine the common behavior and attributers in a single or more classes.
43
![Page 44: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/44.jpg)
Generalization and Specialization Comparison :• Two different viewpoints of the same
relationship– Viewed from subclasses to superclass is called
generalization– Viewed from superclass to subclasses is called
specialization
• Both are opposite to each other– Generalization uses bottom-up approach– Specialization uses top-down approach.
44
![Page 45: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/45.jpg)
Dynamic Modeling:
• Describes changes to the objects and their relationships over time.
• Represents the temporal, behavioral, control aspects of a system.
• Major concepts are– Events• represent external stimuli and point of time
– States• represent values of objects and interval of time
45
![Page 46: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/46.jpg)
Event:
• Happens at a point in time• One event may be casually related– logically precede or follow another
• or the two events may be casually unrelated– Concurrent
• Every event is a unique occurrence– but can be grouped into event classes– where event class indicate common structure and
behavior.46
![Page 47: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/47.jpg)
Event:
• An event is a one-way transmission of information from one object to another.– An object sending an event may expect reply– but that reply is a separate event under the
control of the second object.
• Some classes of events may be simply signals– that something has occurred
• Some classes of events may convey data values called attributes of that event.
47
![Page 48: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/48.jpg)
Scenario:
• Is a sequence of events– that occurs during one particular execution of a
system
• Scope of a scenario can vary– May include all events in the system– Or may include only those events impinging on or
generated by certain objects in the system
• Next step after writing a scenario is to identify the sender and receiver objects of each event.
48
![Page 49: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/49.jpg)
Event Trace Diagram:
• The sequence of events and the objects exchanging events can both be shown in an augmented scenario called an even trace diagram.
• Event diagrams shows– Each object as a vertical line– Each event as a horizontal arrow from the sender
object to the receiver object
49
![Page 50: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/50.jpg)
Event Trace Diagram:
• Time increases from top-to-bottom• Only the sequences of events are shown– Not their exact timing.
50
![Page 51: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/51.jpg)
State:
• Is an abstraction of the attribute values and links of an objects.
• corresponds to the interval between two events received by an object.
• specifies the response of the object to input events.
51
![Page 52: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/52.jpg)
State Diagram:
• Is used to relate events and states.• On the occurrence of an event, next state
depends– on the current state– as well as on the event
• A state diagram is a graph where– nodes are states and are drawn as rounded box– and directed arcs are transitions and are drawn as
arrow and labeled by event names52
![Page 53: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/53.jpg)
Functional Modeling:
• Specifies the results of a computation without specifying how or when they are computed.
• Shows which values depend on which other values and the functions that relate them.
53
![Page 54: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/54.jpg)
Relation with Objectand Dynamic Models:• The functional modal specifies– the meaning of the operations in the object model– and the actions in the dynamic model,– as well as any constraints in the object model.
• The Functional Model specifies what happens• The Dynamic Model shows when it happens• The Object Model specifies what it happens to
54
![Page 55: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/55.jpg)
Data Flow Diagrams:
• Shows the functional relationships of the values computed by a system– Including input values, output values, and internal
data stores
• DFD is a graph showing the flow of data values– from their sources– through processes that transforms them– to their destinations.
55
![Page 56: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/56.jpg)
Data Flow Diagram Contains:
• Processes– that transform data
• Data Flows– that move data
• Actor objects – that produce or consume data
• Data store objects– that store data passively
56
![Page 57: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/57.jpg)
Processes:
• A process transforms data values.• A process is drawn as an ellipse containing a
description of the transformation.• Each process has a fixed number of input and
output data arrows.• The lowest-level processes are pure functions.• The high-level processes may be whole DFD.• Processes are implemented as methods.
57
![Page 58: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/58.jpg)
Data Flows:
• A data flow connects the output of an object or process to the input of another object or process.
• A data flow is drawn as an arrow between the producer and the consumer of the data value.
58
![Page 59: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/59.jpg)
Data Flows:
• A fork with several arrows emerging from it may be used to represent– Flow of same value to several places– Splitting an aggregate data value into its
components, each of which goes to a different place.
59
![Page 60: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/60.jpg)
Actors:
• An actor is an active object that drives the data flow graph by producing or consuming values.
• Actors are attached to the inputs and outputs of a data flow graph.
• Also known as terminators.• An actor is drawn as a rectangle.
60
![Page 61: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/61.jpg)
Data stores:
• A data store is a passive object that stores data for later access.
• A data store allows values to be accessed in a different order than they are generated.
• It is drawn as a pair of parallel lines containing the name of the store.
61
![Page 62: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/62.jpg)
Actors vs. Data stores:
• Both actors and data stores are objects.• They are distinguished because of their
behavior and usages.• Data store might be implemented as a file and
an actor as an external device.
62
![Page 63: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/63.jpg)
Context Diagram:
• It is the first DFD for every system.• It shows the overall system processing as just
one process and shows the data flows to and from external entities called actors.
63
![Page 64: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/64.jpg)
Section A:
• Abstract Data Types: Model of Real World, Autonomy, Generation of correct Applications, Reusability Classes, Instance Values, Methods and Messages, Creating and destroying Objects, Constraints on object and Instance Variables, Pre and Post conditions of Methods.
64
![Page 65: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/65.jpg)
Model of Real World:
• Real world objects are not like variables and functions
• They have attributes and behaviour.• All the information is packaged under one
name and can be reused as one specification or programming component.
65
![Page 66: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/66.jpg)
Autonomy:
• Means independence, freedom from the hold of previous procedural programming approaches.– Redundant code is eliminated and the existing
classes can be extended through inheritance.– Bugs in the program by usage of same member’s
names can be avoided due to encapsulation.– Multiple instances may exist without interference.
66
![Page 67: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/67.jpg)
Generation of Correct Applications:
• OOAD simplifies the problem as it related the problem with real world.
• As abstraction in generated first that facilitates creating classes, thus chances of errors are avoided.
• Reusability of existing classes further helps in reducing errors
67
![Page 68: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/68.jpg)
Reusability:
68
![Page 69: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/69.jpg)
Classes:
69
![Page 70: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/70.jpg)
Instance Values:
• By instance we mean an object and by instantiating a class, we make the objects of a class.
• Every instance got features from the class it is instantiated from but represent a completely different object.
• Values that represent an object identity and features form the instance values.
70
![Page 71: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/71.jpg)
Methods and Messages:
• An object encapsulates data and algorithms called methods that process that data.
• Messages are the means by which the objects interact.
• A message stimulates some behaviour to occur in the receiving objet.
71
![Page 72: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/72.jpg)
Creating and Destroying Objects:
• Creation of objects is basically making copies of the class members.
• Memory allocation is done.• Creation of objects also includes its
initialization.• Release the memory.
72
![Page 73: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/73.jpg)
Constraints on Objects and instance variables
73
![Page 74: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/74.jpg)
Pre and Post Conditions or Methods
74
![Page 75: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/75.jpg)
Section A:
• Inheritance: Subsets as Subtypes, Sub typing of Structured Types Contrasting in inheritance with subtyping, Implicit Subtyping verses Explicit inheritance, Subtyping and dynamic binding class inheritance. Redefining Instance variables, Hiding Instance Variables inheriting methods, Method Overriding, Invoking Superclass method, Constrained Overriding, Inheriting the Interface, Excluding Super class Methods metaclasses, Explicit Support, Implicit of hidden Metaclasses, Object Oriented Languages without Metaclasses, Prototype Systems and Delegation, Multiple inheritance.
75
![Page 76: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/76.jpg)
Inheritance:
• Deriving something more specific from a generalized existing thing.
• Common characteristics are collected into one specific class and other classes inherit that class.
• Core idea for reuse• Avoid redundancy• Leading to smaller models
76
![Page 77: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/77.jpg)
Inheritance with subtyping:
• Class is regarded as an implementation of a type– which defines certain behaviour.
• A subclass represents a subtype to a class.• Ancestor represents a subset of the behaviour
common to all the descendants.• Subtyping normally occurs if the inheritance
performs only an extension rather than overriding.
77
![Page 78: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/78.jpg)
Instance variables:
• A variable associated with a specific instance is called an instance variable.
• Instance variable store instance’s state.• Encapsulation ensures that only one way to
affect an object’s state, and that is though its operations.
78
![Page 79: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/79.jpg)
Hiding instance variables:
• Local variable having the same name as instance variable can hide the instance variable.
79
![Page 80: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/80.jpg)
Overriding:
• Redefine some behaviour while inheriting from ancestor.
• With overriding, inheritance would not remain transitive.
80
![Page 81: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/81.jpg)
Invoking super class method:
• To use characteristics from more than one class.
• Controversial in the object-oriented community.
• Reduces understanding of a class hierarchy.• Having same name in more than one super
class creates problem
81
![Page 82: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/82.jpg)
System Design:
• It is the first design stage– in which the basic approach for solving the
problem is selected.
• System architecture is the overall organization of the system into components called subsystems.
82
![Page 83: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/83.jpg)
Key issues in System Design:
• Organize the system into subsystems.• Identify concurrency inherent in the problem.• Allocate subsystems to processors and tasks.• Choose an approach for management of data stores.• Handle access to global resources.• Choose the implementation of control in software.• Handle Boundary Conditions.• Set trade-off Priorities.
83
![Page 84: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/84.jpg)
Organize the system into subsystems:• A subsystem is usually identified by the service it
provides.• It is a package of – interrelated classes, associations, operations, events and
constraints.– Are reasonably well-defined.– Interfaced with other subsystems.
• The lowest level subsystems are called modules.
84
![Page 85: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/85.jpg)
Organize the system into subsystems:• Relationship between two subsystems can be– Client-supplier relationship– Peer-to-peer relationship
85
![Page 86: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/86.jpg)
Organize the system into subsystems:• Client-supplier relationship– Client calls on the supplier, which perform some service
and replies with a result.
– Client must know the interface of the supplier, but the supplier does not have to know the interface
86
![Page 87: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/87.jpg)
Organize the system into subsystems:• Peer-to-Peer relationship– Each of the subsystems may call on the others.– Subsystems must know each other's interface
• Which makes it more complicated.
– Peer-to-Peer Relationship• Each of the subsystems may call on the others.• Subsystems must know each other's interface.
87
![Page 88: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/88.jpg)
Organize the system into subsystems:• Decomposition of system into subsystems:– Layered Architecture
• Subsystem knows about the layers below it, but has no knowledge of the upper layers
• Client supplier relationship exists between lower and upper layers• Each layer is implemented in terms of classes and operations of
lower layers.• It may be Closed Architecture or Open Architecture
– Partitions• Vertically divide a system into several independent or weakly
coupled sybsystems.
88
![Page 89: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/89.jpg)
Identifying concurrency:
• The objects are said to be concurrent– if they can receive events at the same time– without interaction.
• Identify which objects must be active con-currently Identify which objects have activity that is mutually exclusive.
89
![Page 90: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/90.jpg)
Allocate subsystems toprocessors and tasks:• Each concurrent subsystem must be allocated to a
hardware unit– either a general purpose processor– or a specialized functional unit
• System designer must consider following aspects:– Estimate performance needs and the resources needed to
satisfy them.– Choose h/w or s/w implementation for subsystem.
90
![Page 91: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/91.jpg)
Choose an approach for management of data stores:• Data store may combine– Data structure– Databases– Data files
91
![Page 92: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/92.jpg)
Handle access to global resources.:• System designer must Identify global resources and
determine mechanism for controlling access to them
• Physical object– Can control itself by establishing a protocol for obtaining
access within a concurrent system.
• Logical object (such as object ID)– There is danger of conflicting access in a shared
environment.
• Global resource must be owned and locking mechanism should be implemented.
92
![Page 93: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/93.jpg)
Choose the implementation of control in software:• External Control• Internal Control
93
![Page 94: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/94.jpg)
Handle Boundary Conditions:
• Initialization– System must initial with all required things.
• Termination– System must contain the termination statements– Abnormal terminations must be avoided.
• Failure– Abnormal termination is called failure– May arise due to user errors, exhaustion of system
resources, external breakdown.
94
![Page 95: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/95.jpg)
Set trade-off Priorities:
• Based on relative importance of the various criteria
95
![Page 96: Object analysis and design](https://reader034.vdocument.in/reader034/viewer/2022052315/55502b35b4c9059f318b4ab6/html5/thumbnails/96.jpg)
Common Architectural Frameworks:• Functional Transformation System– Batch Computation system– Continuous Transformation system
• Time dependent system– Interactive Interface– Dynamic simulation
• Database system– Transaction manager
96