DIFFERENCES BETWEEN STRUCTURED ANALYSIS AND OBJECT ORIENTED ANALYSIS

Advantages and Disadvantages of Object Oriented Analysis and Design

Advantages: The OO approach inherently makes each object a stand alone component that can be reused not only within a specific stat problem domain, but also is completely
different problem domains, having the requirement of similar objects. The other main advantage of object oriented (OO) is the focus on data relationships. You cannot develop
a successful system where data relationships are not well understood. An OO model provides all of the insight of an ER diagram and contains additional information related to
the methods to be performed on the data. We will have more detailed discussion on this aspects in Block 3 of this Course.
Disadvantages: You know that OO methods only build functional models within the objects. There is no place in the methodology to build a complete functional model. While
this is not a problem for some applications (e.g., building a software toolset), but for large systems, it can lead to missed requirements. You will see in Unit 3 of this course. “Use
cases” addresses this problem, but since all use cases cannot be developed, it is still possible to miss requirements until late in the development cycle. Another disadvantage of
the object oriented analysis design (OOAD) is in system modeling for performance and sizing. The object oriented (OO) models do not easily describe the communications
between objects. Indeed, a basic concept of object oriented (OO) is that the object need not know who is invoking it. While this leads to a flexible design, performance modeling
cannot be handled easily. The object oriented (OO) analysis design itself does not provide support for identifying which objects will generate an optimal system design.
Specifically, there is no single diagram that shows all of the interfaces between objects. You will study object oriented analysis design (OOAD) diagrams in Unit 3 of this course.
As you know, coupling is a major factor in system complexity, not having this information makes architecture component selection a hit or miss proposition.
Advantages and Disadvantages of Structured Analysis With experience, you will come to know that most customers understand structured methods better than object
oriented (OO) methods. Since one of the main reasons of modeling a system is for communication with customers and users, there is an advantage in providing structured
models for information exchange with user groups or customers. 27 Object Oriented Analysis In fact, specifications are typically in the form of a simple English language
statement of Work and Requirement Specification. Therefore, the system to be built, must be understood in terms of requirements (functions the system must perform), that is
why this naturally leads to a structured analysis, at least at the top level. Specifically structured methods (functional decomposition) provide a natural vehicle for discussing,
modeling, and deriving the requirements of the system. The disadvantage with structured methods is that they do not readily support the use of reusable modules. The top
down process works well for new development, but does not provide the mechanisms for “designing in” the use of existing components. The top down process of functional
decomposition does not lead to a set of requirements which map well to existing components. When the requirements do not map cleanly, you have two choices: either you do
not use the existing components, or force fit the requirements to the existing components and “somehow” deal with the requirements which are only partially covered by the
existing components, which does not lead to a good successful system. Now, we will discuss how actually object oriented analysis (OOA) system is performed.

Difference between Generalization and Specialization in DBMS

Generalization :
It works on the principle of bottom up approach. In Generalization lower level functions are combined to form
higher level function which is called as entities. This process is repeated further to make advanced level
entities.
In the Generalization process properties are drawn from particular entities and thus we can create generalized
entity. We can summarize Generalization process as it combines subclasses to form superclass. Example of
Generalization –
Consider two entities Student and Patient. These two entities will have some characteristics of their own. For
example Student entity will have Roll_No, Name and Mob_No while patient will have PId, Name and Mob_No
characteristics. Now in this example Name and Mob_No of both Student and Patient can be combined as a Person to form one higher level entity and this process is called
as Generalization Process.

2. Specialization :
We can say that Specialization is opposite of Generalization. In Specialization things are broken down into
smaller things to simplify it further. We can also say that in Specialization a particular entity gets divided into
sub entities and it’s done on the basis of it’s characteristics. Also in Specialization Inheritance takes
place.Example of Specialization –
Consider an entity Account. This will have some attributes consider them Acc_No and Balance. Account entity
may have some other attributes like Current_Acc and Savings_Acc. Now Current_Acc may have Acc_No,
Balance and Transactions while Savings_Acc may have Acc_No, Balance and Interest_Rate henceforth we can
say that specialized entities inherits characteristics of higher level entity.After applying generalization and
specialization, the structure of resultant figures are same.

Message Passing Model of Process Communication:Process communication is the mechanism provided by the operating system that
allows processes to communicate with each other. This communication could involve a process letting another process know that
some event has occurred or transferring of data from one process to another. One of the models of process communication is the
message passing model.Message passing model allows multiple processes to read and write data to the message queue without
being connected to each other. Messages are stored on the queue until their recipient retrieves them. Message queues are quite
useful for interprocess communication and are used by most operating systems.A diagram that demonstrates message passing model
of process communication is given as follows −In the above diagram, both the processes P1 and P2 can access the message queue
and store and retrieve data.
Advantages of Message Passing Model:The message passing model is much easier to implement than the shared memory model.It is
easier to build parallel hardware using message passing model as it is quite tolerant of higher communication latencies.
Disadvantage of Message Passing Mode:The message passing model has slower communication than the shared memory model because the connection setup takes time.
Inheritance:- Inheritance is one of the cornerstones of object-oriented programming language because it allows a creation of hierarchical classifications. Using inheritance you
can create a general class that defines trails common, to a set of related items. More specific classes can inherit this class, and each could add a certain unique thing to the
resulting new class. The class that inherits from another, class, or classes is called a derived class or subclass, and the class/classes from which the derived class is made is called,
a base class or a super class. For example, racing cars. Pick up cars and saloons, etc. are all different kinds of cars in object-oriented terminology racing cars. Pick up cars, and
saloons, etc. are all subclasses of the car class. Similarly, as illustrated in Figure15, below, the car class is the super class of sub classes like racing cars, saloons, sedans,
convertibles, etc. 46 Object Oriented Design Figure 15: Hierarchy of Classes Inheritance can be of various types, such as:
1. Single inheritance : In this type, the child class inherits the properties from the superclass.
2. Multiple inheritance: The child class inherits the properties and features from two or more parent classes with this type.
3. Hierarchical inheritance : In the Hierarchical Inheritance type, two or more child classes inherit the properties and behaviors from one superclass.
4. Multilevel inheritance: With this type, one child class inherits the properties and behavior from two or more superclasses.

PERSISTENCY: Persistent data is data which has a longer lifetime than the program created it. In the context of an object oriented program, this means that it must be possible
to save the objects created in one run of a program and to reload them at a later date. The user should not have to create all the data used by a program from scratch every
time the program is run. The usefulness of the program will be rather limited if it is not possible to save diagrams to disk and to continue working on them at a later date.
Enabling data to be stored on a permanent storage medium provides persistency. The most common techniques used are to store data in files, or to make use of a backend
database system. Identifying Persistent Data The basic problem is that it may not be always clear from a model exactly what data needs to be persistent. Models in UML are not
restricted to describing permanent data, or database schemas, and as a result a single model can combine persistent and transient data. The only notation that UML provides
for persistency is a tagged value ‘persistence’. This has two values ‘persistent’ and ‘transient’ and can be applied to classes, associations and attributes. For example, the
diagram and element classes in the diagram editor need to be persistent. This is the data that the user would expect to be able to save and reload at a later date. The tool class,
on the other hand, does not need to be persistent. Tools represent transient features of the user’s interaction with the editor, and it would not be felt to be a major
shortcoming if the tool that was being last used was not available when the program was restarted. The primary unit of persistency is the class. Associations between two
persistent classes are normally persistent, so that information about the links between persistent objects is stored. An association between a persistent and a transient class will
be transient, as the instances at one end of the association are not being stored. Attributes normally have the same persistence value as their enclosing class, though it is
sometimes natural to have a transient attribute within a persistent class. Dealing with Object Identities References are transient, and the persistency of an object model cannot
be obtained simply by copying the values of these references to disk. The problem is that references are normally implemented using the address of the object referred to in
memory, and therefore an object’s identity depends on where free memory happened to be available when it was created. A more common approach, however, is to adopt
some form of encoding whereby references and object identities are stored in such a way that they can be consistently recreated.
Object Modeling
Object modelling is very important for any object oriented development, object modeling shows the static data structure of the real world system. Basically, object modeling
means identifying objects and classes of a system, or you can say that it describes real world object classes and their relationships to each other. You can develop an object
model by getting information for the object model from the problem statement, expert knowledge of the application domain, and general knowledge of the real world. Object
model diagrams are used to make easy and useful communications between computer professionals and application domain experts. To develop an object model first identify
the classes and their associations as they affect the overall problem structure and approach. Then prepare a data dictionary. i) Identify associations between objects. ii) Identify
attributes of objects and links. iii) Organise and simplify object classes using inheritances. Then you verify that access paths exist for likely queries iv) Iterate and refine the
model, and v) Group classes into modules. Identifying Object Classes You should always be careful while identifying relevant object classes from the application domain. Objects
include physical entities in a system like buildings, employees, department, etc. Classes must make sense in the application domain. At this stage you should avoid computer
implementation constructs, such as linked lists and subroutines. Some classes are implicit in the application domain, so you need to find out by understanding the problem well.
Action-object matrix: A matrix showing how update actions affect objects. It may be considered to be part of the user object model, as it summarizes user object action
definitions in a tabular view.Process of this whole activity is like: Check for multiple models • Identify objects • Create user object model diagram • Define user object attributes
• Define user object actions • Create action-object matrix • Check for dynamic behavior • Review glossary.

Dynamic Modeling You know that computer systems are built from objects which respond to events. External events arrive at the boundary of the system; you understand the
concept of events. For example, whenever you click with your mouse on the desktop or the canvas area some action is triggered (you get some response back).
In Dynamic modeling you examine “a way of describing how an individual object responds to events, either internal events triggered by other objects or external events
triggered by the outside world”. Dynamic modeling is elaborated further by adding the concept of time: new attributes are computed as a function of attribute changes over
time. Before you define the dynamic behaviour of user objects. You should know the following: The Inputs are: User object model which comprises objects, attributes, actions
and relationships. Task model: from which significant object states may be identified. Products Dynamic model: A model of the dynamic behaviour of a user object. It defines
significant states of the user object, the way that actions depend on the state, and affect the state. The dynamic model consists of a dynamic model diagram, showing states and
transitions and supplementary notes, specifying states and actions in more detail. Process of Dynamic modeling: • Analyse applicability of actions • Identify object states • Draw
dynamic model diagram • Express each state in terms of object attributes • Validate dynamic model • Concepts. Dynamic modeling: state diagrams We will study this in detail in
Block 3 of this course. Generally, a state diagrams allows you to further explore the operations and attributes that need to be defined for an object. They consist of sets of states
which an object is in, and events which take the object from one state to another. State: An object may have one or more states−stable points in its life, expressed by the
object’s attributes and relationships. Event/action: Something that happens to an object. Atomic, in that it either has happened or it hasn’t. An event causes an action.
Transition: A jump between states, labeled with the corresponding action.

2.5.3 Functional Modeling You know that Data flow modeling is a common technique used for the analysis of a problem in software engineering. It is exceptionally useful for
analyzing and describing systems where there is a large amount of calculation involved. Data flow models consist of a number of processes which exchange information. A
process transforms information it receives, and passes the transformed information on to other processes or to objects in the system. Data flow models can be used to uncover
new operations and new attributes for the object model. Sometimes, new objects can be discovered too. Basically you can state that the functional model shows how values are
computed. It describes the decisions or object structure without the regard for sequencing. It gives you dependency between the various data and the functions that relate
them, giving the flow of data. Each process needs to be implemented as an operation in one or more of the objects. Each data item arising from an object must have a
corresponding attribute, or set of attributes in the source object. The data flow diagram (DFD) corresponds to activities or actions in the state diagrams of the classes. That is
why it is suggested to construct the functional model after the object and dynamic models. Now, let us discuss about the creation of the DFD and the functional model. The
approach to data flow diagramming should be as follows: • Create a data flow diagram for each of the major outputs of the system • Work back from the outputs to the inputs
to construct the diagram • Add new objects where necessary to the object model as you discover the need for them in the data flow modeling add new operations and
attributes to the object model as you discover the need for them in the data flow modeling. One thing you have to remember is that the data flow diagram is not used as a basis
for devising the structure of the system. Steps in constructing a Functional Model
Identifying Input and Output Values First, identify what data is going to be used as input to the system, and what will be the output from the system. Input and output values are
parameters of events between the system and the outside world. You must note that Input events that only affect the flow of control, such as cancel, terminate, or continue.
They do not supply input values. For example, supplier code, name, product description, rate per unit, etc. are the inputs to a sales system. Build data Flow diagrams showing
functional dependencies Data flow diagrams are useful for showing the functional dependencies. In data flow diagrams processes are drawn as bubbles, each bubble containing
with the name of the process inside. Arrowhead lines are used to connect processes to each other, and to objects in the system. The lines are label with the information that is
being passed. Objects are drawn as rectangular boxes, just as in the object model,Describe functions After you have roughly designed the data flow diagram, you can write a
description of each function, and you can describe the function in any form such as, mathematical equations, pseudo code, decision tables, or some other appropriate form. You
need not know the implementation of the function, but what it does. The description can be declarative or procedural. A declarative description specifies the relationship
between the input and output values, and relationship among the output values. A procedural description specifies a function by giving an algorithm to compute it. The purpose
of the algorithm is only to specify what the function does. Identifying Constraints Between Objects In a system, there are some boundaries to work on. Boundaries or
Constraints are the functional dependencies between objects which are not related by an input-output dependency. You have to find out the constraints between the objects.
Constraint has different behavior at different times. It can be on two objects at the same time, between instances of the same object at different times (an invariant), or
between instances of different objects at different times. You can define constraints as Preconditions (input values) and PostConditions (output values). Preconditions on
functions are constraints that the input values must satisfy. Post conditions are constraints that the output values must satisfy to hold. State the conditions under which
constraints hold. Specifying Optimisation Criteria Specify values to be maximized, minimized, or optimized. You can understand it as the way you normalize the data in the
database. For example, you should minimize the time an account is locked for concurrency reasons. If locks are needed, then it is extremely important to minimize the time that
an entire bank is locked for concurrency reasons

STRUCTURAL DIAGRAMS
Class Diagram: A class diagram is used to support functional requirement of system. In a static design view, the class
diagram is used to model the vocabulary of the system, simple collaboration, and logical schema. It contains sets of
classes, interfaces, collaborations, dependency, generalization and association relationship. The notation for classes and
the relationship between classes is shown as:If in any college, there are limited classrooms that have to be allocated to
different classes and instructors are fixed for all classes, then the class diagram for the allocation of classrooms and
instructors is shown as:

Object Diagram An object diagram shows a set of objects and their relationships at a point of time.
In a static view, the object diagram is used to model interactions that consist of objects that
collaborate the without any message passed among them. It contains name, graphical contents,
notes, constraints, packages and subsystems. The notation for objects and the relationship
between objects is shown as:
Component Diagram A component diagram shows a set of component and their relationships. In a dynamic model, the component diagram is used to model physical
components such as executable releases, libraries, databases, files or adaptable systems. It contains components, interfaces, packages, subsystems, dependency, generalization,
association, and relationship. The notation for components and relationship between components is shown as:

Deployment Diagram: A deployment diagram shows all the nodes on the network, their interconnections, and processor execution. In a dynamic model, a deployment diagram
is used to represent computational resources. The notation for nodes and relationship between processors and devices is shown as:

BEHAVIORAL DIAGRAMS
Use Case Diagram: A use case diagram shows a set of use cases, actors, and their relationships. These diagrams should
be used to model the context or the requirement of a system. It contains use cases, actors, dependency, generalization, association, relationship, roles, constraints, packages,
and instances. The use case diagram makes systems, subsystems, and classes approachable by presenting an outside view of how the elements may be used in context. The
notation for use cases and relationship among use cases, base cases and extend cases is shown as:

Interaction Diagram: An interaction diagram shows an interaction, consisting of a set of objects and their relationships, including the messages that may be dispatched among
them. These diagrams should be used to model the dynamic aspect of the system. It includes sequence diagrams and collaboration diagrams. Here we will discuss two
interaction diagrams, sequence diagrams and collaboration diagrams.
Sequence Diagrams A sequence diagrams are interaction diagrams that emphasize the time ordering of messages. In UML it is shown as a table that shows objects arranged
along the X axis and messages, ordered in increasing time, along the Y axis. It has a global life line and the focus of control. An object life line is the vertical dashed line that
represents existence of an object over a period of time. The focus of control is tall and thin rectangle that shows the period during which an object is performing an action. The
notation for depiction of sequence among objects with certain conditions is shown as:

Collaboration Diagrams: Collaboration diagrams are interaction diagrams that emphasize the structural organisation of an object that send and receive messages. There is
always a path in collaboration diagrams to indicate how one object is linked to another, and sequence numbers to indicate the time ordering of a message. The notation for
depiction of a collaboration diagram is shown as:
Activity Diagram show the flow from one activity to another. An activity is an ongoing non atomic execution within a state machine. Activity ultimately results in some action,
which is made up of executable atomic computations that result in a change in state of the system, or the return of a value. It contains activity states, action states, transition
states, and objects. The activity diagram for encryption of a message send through e-mail is shown as:

Statechart Diagram: A state chart shows a state machine, emphasizing the flow of control from one state to another. A state
machine is a behaviour that specifies the sequence of states that an object goes through during the life time in response to
events together with its response to those events. A state is a condition/situation during the object’s life which performs some
activity, or waits for some event. It contains simple states, composite states, transitions, events, and actions. The notation for
multiple states depending on events/action based on set of activities is shown as:

Association: Association relationship is a structural relationship in which different objects are linked within the system. It exhibits
a binary relationship between the objects representing an activity. It depicts the relationship between objects, such as a teacher,
can be associated with multiple teachers. It is represented by a line between the classes followed by an arrow that navigates the direction, and when the arrow is on both sides,
it is then called a bidirectional association. We can specify the multiplicity of an association by adding the adornments on the line that will denote the association.
Aggregation: Aggregation is a subset of association, is a collection of different things. It represents has a relationship. It is more specific than an association. It describes a part-
whole or part-of relationship. It is a binary association, i.e., it only involves two classes. It is a kind of relationship in which the child is independent of its parent.
For example: Here we are considering a car and a wheel example. A car cannot move without a wheel. But the wheel can be independently used with the bike, scooter, cycle, or
any other vehicle. The wheel object can exist without the car object, which proves to be an aggregation relationship.
Composition The composition is a part of aggregation, and it portrays the whole-part relationship. It depicts dependency between a composite (parent) and its parts (children),
which means that if the composite is discarded, so will its parts get deleted. It exists between similar objects. As you can see from the example given below, the composition
association relationship connects the Person class with Brain class, Heart class, and Legs class. If the person is destroyed, the brain, heart, and legs will also get discarded.
Abstraction Abstraction is one of the very important concepts of object oriented systems Abstraction focus on the essential, inherent aspects of an object of the system. It does
not represent the accidental properties of the system. In system development, abstraction helps to focus on what an object is supposed to do, before deciding how it should be
implemented. The use of abstraction protects the freedom to make decisions for as long as possible, by avoiding intermediate commitments in problem solving. Most of the
modern languages provide data abstraction. With the abstraction, ability to use inheritance and ability to apply polymorphism provides additional freedom and capability for
system development. When you are using abstraction during analysis, you have to deal with application-domain concepts. You do not have to design and make implementation
decisions at that point.
Encapsulation Encapsulation, or information hiding, is the feature of separating the external aspects of an object, from the internal implementation details of that object. It
helps in hiding the actual implementation of characteristics of objects. You can say that encapsulation is hiding part of implementation that do internal things, and these hidden
parts are not concerned to outside world. Encapsulation enables you to combine data structure and behaviour in a single entity. Encapsulation helps in system enhancement. If
there is a need to change the implementation of object without affecting its external nature, encapsulation is of great help.

Polymorphism Class hierarchy is the deciding factor in the case of more than one implementation of characteristics. An object oriented program to calculate the area of
different Figures would simply call the Find_ Area operation on each figure whether it is a circle, triangle, or something else. The decision of which procedure to use is made
implicitly by each object, based on its class polymorphism makes maintenance easier because the calling code need not be modified when a new class is added.
Sharing of Structure and Behaviour One of the reasons for the popularity of object-oriented techniques is that they encourage sharing at different levels. Inheritance of both
data structure and behaviour allows common structure (base class) to be used in designing many subclasses based on basic characteristics of base class, and develop new
classes with less effort. Inheritance is one of the main advantages of any object oriented language, because it gives scope to share basic code. In a broader way we can say that
object oriented development not only allows information sharing and reuse within an application, but also, it gives a base for project enhancement in future. As and when there
is a need for adding new characteristics in the system, they can be added as an extension of existing basic features. This can be done by using inheritance, and that too, without
major modification in the existing code. But be aware that just by using object orientation you do not get a license to ensure reusability and enhancement. For ensuring
reusability and enhancement you have to have a more general design of the system. This type of design can be developed only if the system is properly studied and features of
proposed system are explored.
Emphasis on Object Structure, not on Operation Implementation In object orientation the major emphasis is on specifying the characteristics of the objects in a system, rather
than implementing these characteristics. The uses of an object depend highly on the facts of the application and regular changes during development. As requirements extend,
the features supplied by an object are much more stable than the ways in which they are used, hence software systems built on object structure are more secure. While
developing a system using the object oriented approach, main emphasis is on the essential properties of the objects involved in the system than on the procedure structure to
be used for implementation. During this process what an object is, and its role in system is deeply thought about.

CHARACTERISTICS OF OBJECT ORIENTED MODELING

In object oriented modeling objects and their characteristics are described. In any system, objects come into existence for playing some role. In the process of defining the roles
of objects, some features of object orientation are used. In this section we will discuss these features, which include: • Class and Objects • Links and Association • Generalization
and Inheritance Let us start our discussion with Class and Objects.
1.4.1 Class and Objects A class is a collection of things, or concepts that have the same characteristics. Each of these things, or concepts is called an object. We will discuss, in
the next unit of this block, that the class is the most fundamental construct within the UML. Classes define the basic words of the system being modeled. Using a set of classes
as the core vocabulary of a software project tends to greatly facilitate understanding and agreement about the meanings of terms, and other characteristics of the objects in the
system. Classes can serve as the foundation for data modeling. In OOM, the term classes is usually the base from which visual modeling tools−such as Rational Rose XDE, Visual
Paradigm function and design the model of systems. Now, let us see how the characteristics that classes share are captured as attributes and operations. These terms are
defined as follows: • Attributes are named slots for data values that belong to the class. As we have studied in MCS-024, different objects of a given class typically have at least
some differences in the values of their attributes. • Operations represent services that an object can request to affect the behaviour of the object or the system itself. In unit 3
of this block, we will cover the standard UML notation for OOM in detail. Here, we will mention about standard notation of class. The notation for a class is a box with three
sections. The naming convention for classes are as follow: • Class names are simple nouns or noun phrases. • Attribute names in a class are simple nouns or noun phrases. The
first word is not capitalized, but subsequent words may be capital. • Operation names are simple verbs. As with attributes, the first word is not capitalized and subsequent
words may be capital.
Objects The notation for an object is the same in basic form as that for a class. There are three differences between the notations, which are: • Within the top section of the
class box, the name of the class to which the object belongs appears after a colon. The object may have a name, which appears before the colon, or it may be anonymous, in
which case nothing appears before the colon. • The contents of the top compartment are underlined for an object. • Each attribute defined for the given class has a specific
value for each object that belongs to that class. Everything that the software object knows (state) and can do (behaviour) is expressed by the variables and the methods within
that object. In other words, all the objects share states and behaviour. Let us say that a software object that models your realworld bicycle would have variables that indicated
the bicycle’s current state: its speed is 20 mph, and its current gear is the 3rd gear, etc.

1.4.2 Links and Association

Links and associations are the basic means used for establishing relationships among objects and classes of the system. In the next subsection we will discuss links and
associations which are used for representing relationship. General Concepts A link is a physical or conceptual connection between objects for example, a student, Ravi study in
IGNOU. Mathematically, you can define a link as a tuple that is an ordered list of objects. Further, a link is also defined as an instance of an association. In other words you can
say that an association is a group of links with a common structure and common meanings, for example, a student study in a university. All the links in an association connects
objects from the same classes. A link is used to show a relationship between two (or more) objects. Association and classes are similar in the sense that classes describe objects,
and association describe links. Figure 4a shows us how we can show the association between Student and University. Note that every association has roles. For example, in
Figure 4b you can see that two classes, Student and University, have their defined roles. Here you can also see that binary association has two roles, one from each class.
Associations may be binary, ternary, or have higher order. In exercise, the vast majority of association are binary or ternary associations. But a ternary association is formed
compulsion; they cannot be converted into binary association. If a ternary association is decomposed in some other association, some information will be lost. In Figure 5 you
can see a ternary association.
Multiplicity Multiplicity in an association specifies how many objects participate in a relationship. Multiplicity decides the number of related objects. Multiplicity is generally
explained as “one” or “many,” but in general it is a subset of the non-negative integers. n associations, generally movement is in both the directions of the relationships but if
you want to be specific in any particular direction, you have to mark it by an arrow.
Aggregation Aggregation is a special form of association, which models the “part-whole” or “apart-of” relationship as an aggregate (the whole) and parts. The most considerable
property of aggregation is transitivity, that is, if X is part of Y and Y is part of Z, then X is part of Z. Aggregation is seen as a relationship in which an assembly class is related to
component class. In this component objects are not having separate existence, they depend on composite objects as you can see in Figure 7 Exam Schedule is not having
separate existence.
1.4.3 Generalization and Inheritance In this section we will discuss the concepts of generalization, inheritance, and their uses in OOM. Generalization Generalization and
inheritance are powerful abstractions for sharing the structure and/or behaviour of one or more classes. Generalization is the relationship between a class, and it defines a
hierarchy of abstraction in which subclasses (one or more) inherit from one or more superclasses. Generalization and inheritance are transitive across a subjective number of
levels in the hierarchy. Generalization is an “is-a-kind of” relationship, for example, Saving Account is a kind of Account, PG student is kind of Student, etc. The notation for
generalization is a triangle connecting a super class to its subclasses. The superclass is connected by a line to the top of the triangle. The subclasses are connected by lines to a
horizontal bar attached to the base of the triangle. Generalization is a very useful construct for both abstract modeling and implementation. You can see in Figure 8, a
generalization of Account class.
Inheritance Inheritance is taken in the sense of code reuse within the object oriented development. During modeling, we look at the resulting classes, and try to group similar
classes together so that code reuse can be enforced. Generalization, specialization, and inheritance have very close association. Generalization is used to refer to the
relationship among classes, and inheritance is used for sharing attributes and operations using the generalization relationship. In respect of inheritance, generalization and
specialization are two phases of a coin in the sense that if a subclass is seen from a superclass the subclass is seen as a specialized version of superclass and in, reverse, a
superclass looks like general form of subclass. During inheritance, a subclass may override a superclass feature by defining that feature with the same name. The overriding
features (the subclass feature with the same names of superclass features) refines and replaces the overridden feature (the superclass feature).
Serialization Serialization is a generic term used for mechanisms that enable objects and object structures to be converted into a portable form, removing the volatility created
by object addresses. As we have already studied in MCS-024, serialization is provided in Java by means of an interface called ‘Serializable’. This interface defines no methods, so
in order to make a class serializable it is sufficient to declare that it implements this interface. Once this has been done, the methods ‘writeObject’ and ‘readObject’ can be used
to transfer objects to and from streams, and persistence can then easily be implemented. Serialization therefore provides a convenient and straightforward way of making data
persistent. It is most appropriate when the amount of data involved is relatively small. If larger amounts of data are to be stored, serialization may no longer be appropriate.
Concurrency Control Control as Concurrent Tasks:The term control as concurrent task means applying control for those events of the object that can occur simultaneously. An
object can be implemented as a task in the programming language or operating system. This is the most general approach of concurrency controls. With this you can preserve
the inherent concurrency of real objects. You can implement events as inter-task calls using the facilities of the language, or operating system. As far as OO programming
languages are concerned, there are some languages, such as Concurrent Pascal or Concurrent C++, which support concurrency, but the application of such languages in
production environments is still limited. Ada language supports concurrency, provided an object is equated with
an Ada task, although the run-time cost is very high. The major object oriented languages do not yet support
concurrency.
Object-Oriented Databases :An object-oriented database is a collection of object-oriented programming and
relational database. There are various items which are created using object-oriented programming languages like
C++, Java which can be stored in relational databases, but object-oriented databases are well-suited for those
items.An object-oriented database is organized around objects rather than actions, and data rather than logic. For
example, a multimedia record in a relational database can be a definable data object, as opposed to an
alphanumeric value.
Implementing Constraints: Class constraints are used to describe relationships that must be between the
attribute values of an instance of the class; and preconditions and post-conditions specify what must be true
before and after an operation are called. Once these are implemented by including code in the class which checks
these conditions at the appropriate times; then the applications become more reliable and robust. It is necessary
that all the preconditions that are specified for an operation should be explicitly checked in an implementation. Preconditions state properties of an operation’s parameters that
must be satisfied if the operation is to be able to run to completion successfully. It is the responsibility of the caller of the operation to ensure that the precondition is satisfied
when an operation is called. If an operation does not check its parameter values, then, there is a possibility that wrong or meaningless values will go undetected, and this results
in unpredictable runtime errors. A better strategy is for an operation to check its precondition and to raise an exception if a violation of the precondition is detected. The
following example provides a possible implementation of the withdraw operation of the savings account class. public class SavingsAccount { public void withdraw(double amt)
{ if (amt >= balance) { // throw PreconditionUnsatisfied } balance = balance - amt ; } private double balance ; } In general, any constraint can be checked at run-time by writing
code that will validate the current state of the model. But such checks increase overhead. That is why, except for the case of precondition checking, constraints are rarely
implemented explicitly. Statecharts are diagrams that specify an object’s responses to the events it might detect during its lifetime. We will discuss statechart in next section

METADATA AND KEYS

Let us first discuss metadata. You are already familiar with metadata concept in your database course. As you know, RDBMS uses metadata for storing information of database
tables. Basically, metadata is such set of data which describes other data. For example, if you have to describe an object, you must have a description of the class from which it
is instantiated. Here, the data used to describe class will be treated as metadata. You may observe that every real-world thing may have meta data, b and their directors. You
can store that school A is having X as its direct, School B is having Y as its director, and so on. Now, you have concrete information to keep in metadata that is every institute is
having a director. KEY Object instances may be identified by an attribute (or combination of attributes) called a key. A primary key is an attribute (or combination of attributes)
that uniquely identifies an object instance and corresponds to the identifier of an actual object. For example, customer number would usually be used as the primary key for
customer object instances. Two, or more, attributes in combination sometimes may be used to uniquely identify an object instance. For example, the combination of last name,
first name and middle initial might be used to identify a customer or employee object instance. Here, you can say that sometimes more than one attribute gives a better chance
to identify an object. For example, last name alone would not suffice because many people might have the same last name. First name would help but there is still a problem
with uniqueness. All three parts of the name are better still, although a system generated customer or employee number is bests used as an identifier if absolute uniqueness is
desired. Possible Primary Keys that are not actually selected and used as the primary keys are called candidate keys. A secondary key is an attribute (or combination of
attributes) that may not uniquely identify an object instance, but can describe a set of object instances that share some common characteristic. An attribute (customer type)
might be used as a secondary key to group customers as internal to the business organisation (subsidiaries or divisions) or external to it. Many customers could be typed as
internal or external at the same time, but the secondary key is useful to identify customers for pricing and customer service reasons. ecause every real world thing has a
description for them. Let us take the example of institutes

IMPLEMENTING STATE CHARTS: It is very important to apply proper strategy in final implementation of the systems. Here we will see some strategies for implementations. A
Basic Implementation Strategy This approach models the different states in the statechart explicitly by means of an enumeration in the class to which the statechart applies. The
current state that an object is in, is recorded by a special data member of the class that can take on values from this enumeration. Member functions that can have different
effects depending on the state of the object are implemented as switch statements, each case of which represents one possible state of the object. The implementation of each
case corresponds to a single transition on the statechart. It should check any applicable conditions, perform any actions, and if necessary change the state of the object by
assigning a new value to the data member which records the current state. This implementation of this approach is simple and can be generally applied but it has some
disadvantages also. It does not provide much flexibility in the case where a new state is added to the statechart. The implementation of every member function of the class
would have to be updated in such a case, even if they were unaffected by the change. Also, the strategy assumes that most functions have some effect in the majority of the
states of the object. If this is not the case, the switch statements will be full of ‘empty cases’ and the implementation will contain a lot of redundant code. An Alternative
Approach An alternative implementation of statecharts can avoid these problems at the cost of representation of individual states. Rather than representing the current state of
an object by the value of a data member in the object itself, this approach represents states as objects. Each instance of the class described by the statechart maintains a
pointer to its current state, which is an instance of one of the state classes. The state classes are arranged in a generalization hierarchy so that different states can be referred,
by the same pointer. Now, let us see a class diagram illustrating the structure of this implementation. You can see in Figure10 below, which shows the classes that would be
declared to implement the creation tool class from the diagram editor. A field in the creation tool class will hold a reference to an object of type ‘CtoolState’. This is an abstract
class, so at run-time the object referred to will be an instance of one of the subclasses ‘LocatingStart’ or ‘LocatingStop’. In this way, a creation tool always holds a reference to
an object representing its current state. The classes representing states provide implementations of the operations declared in the creation tool interface. When a creation tool
receives a message, it simply passes it on to the object representing its current state, which contains a suitable implementation. A partial definition of the creation tool class
could be given as follows. public class CreationTool { public void press() { state.press() ; } private CToolState state; } The interface of the ‘CtoolState’ class must include all the
messages that will be passed on from tools. Default implementations can be provided in ‘CtoolState’, however, so that individual states need only define those operations which
evoke some interesting behaviour in that state. The following code gives a partial declaration of the ‘CtoolState’ class. public abstract class CToolState { public abstract void
press(); } Subclasses that represent individual states must now redefine the operations that interest them. In the case of ‘press’, the press event can be detected in the
‘LocatingStart’ state, and in response the tool should change state. A possible definition of the function is given below. For reasons that are discussed below, only pseudocode
implementations of the functions are given. public class LocatingStart extends CToolState { public void press() { set start position to current; draw faint image of shape; set
current state to ‘LocatingStop’ ; } } As the press event cannot be received in the ‘LocatingStop’ state, as the mouse button is already depressed, no definition of this function is
required in the class ‘LocatingStop’. The default implementation of the function inherited from ‘CTooIState’ is quite adequate. It is important that any implementation must be
sensitive to the fact that an object can be in different states at different times, and that the effect of operations is dependent on the current state. The simple implementation
makes this all explicit, and the programmer must write switch statements to detect the current state of the object. In the more sophisticated implementation outlined above,
detection of the current state is performed implicitly by the dynamic binding performed when a virtual function from the general ‘CtoolState’ class is called. The sophisticated
implementation has several advantages over the simple one. For example, the classes that represent individual states only need to define the operations that are relevant to
them, and can inherit default implementations of the others from the general state class. This can considerably simplify the implementation of a statechart, especially in the
case where many operations are only applicable in a small subset of the object’s states. The sophisticated approach is also more maintainable than the simple one. For example,
if the statechart is extended to include extra states, these can simply be added as new subclasses of the general state class, and existing code which is not relevant to the change
will be unaffected. This contrasts with the simple implementation, where adding a state requires the implementation of every member function to be updated. There are costs
associated with the sophisticated approach, however, which mostly stop from the fact that the implementation of the member functions of the state classes often needs to
update the state of the object itself.
ASSOCIATION: DESIGN
Before we define association design let us define association “Association is the group of links between two objects in an object model”. It is helpful in an finding paths between
objects. It is a conceptual entity, which can be used for modeling and analysis. At the final phase of advance object design, you must use strategy for applying association in the
object model. Association is also defined as “a group of links between two objects with common structure and
common semantic”. Analyzing Association Traversal Association Traversal should be understood properly for an
association design explanation. Analyzing association traversal means analyzing traversal between the objects.
Associations are inherently bi-directional, which is certainly true in an abstract sense. But, if some associations in
your application are only traversed in one direction, in this case implementation can be simplified.
One-way Associations If an association is only traversed in one direction, then it is called one-way association. It
is implemented as a pointer, or an attribute that contains an object reference. If the multiplicity is “one”, as
shown in Figure 3, then it is a simple pointer; otherwise, if the multiplicity is “many”, then it is a set of
pointers. If the “many” end is ordered, then a list can be used, instead of a set. A qualified association with
multiplicity “one” can be implemented as a dictionary object.

Two-way Associations Many associations are traversed in both directions, and these are called two-way
associations. You may observe that it is not essential to have some frequency of traversal from both sides. It
can be implemented by using the following three methods: • Implement as an attribute in one direction only,
and perform a search when a backward traversal is required. This approach is useful only if there is a great
disparity in traversal frequency in the two directions, and when minimizing both the storage cost and the
update cost are important. It is observed that the rare backward traversal will be expensive. • You should try
to implement the attributes in both directions, as shown in Figure 4. This approach is good because
it permits fast access, but if either attribute is updated then the other attribute must also be
updated to keep the link consistent. This approach is useful in the case to access outnumber
updates.

Implement as a distinct association object, independent of either class, as shown in Figure 4. An

association object is a set of pairs of associated objects stored in a single variable-size object. For
efficiency, you can implement an association object using two dictionary objects, one for the
forward direction and other for the backward direction. This idea is useful for extending predefined,
the classes from a library which cannot be modified. Distinct association objects are also useful for
sparse associations. In sparse associations most objects of the classes do not participate because
space is used only for actual links