OOAD [Object Oriented Analysis and Design]

UNIT-III
[Class and Object Diagrams]

G.Vijay kumar

Page 1

OOAD [Object Oriented Analysis and Design]

CLASS DIAGRAMS

Class diagrams are the most common diagram found in modeling object- oriented systems. A class diagram shows a set of classes, interfaces, and collaborations and their relationships. Class diagrams are use to model the static design view of a system. For the most part, Class diagrams involve
1. Modeling the vocabulary of the system, 2. Modeling collaborations, or 3. Modeling schemas.

Class diagrams are important not only for visualizing, specifying, and documenting structural models, but also for constructing executable systems through forward and reverse engineering.

For example
o

When we build a house, we start with a vocabulary that includes basic building blocks, such as These things are largely

walls, floors, windows, doors, ceilings, etc.

o

structural (walls have height, width, and thickness), but they're also somewhat behavioral (different kinds of walls can support different loads, doors open and close, there are constraints o on the span of unsupported floor). In fact, we can't consider these structural and behavioral features independently. o Rather, when we build our and UML, behavioral we use things class house, we must consider how these structural interact.

In

diagrams to visualize the static aspects of these building blocks and their relationships and to specify their details for construction, as shown in below figure
G.Vijay kumar Page 2

OOAD [Object Oriented Analysis and Design]

Terms and Concepts

A class diagram is a diagram that shows a set of classes, interfaces, and collaborations and their relationships. Graphically, a class diagram is a collection of vertices and arcs. A class diagram is just a special kind of diagram and shares the same common properties as do all other diagrams a name and graphical content that are a projection into a model.

Common Properties

Contents Class diagrams commonly contain the following things: Common Uses

Classes Interfaces Collaborations Dependency, generalization, and association relationships Notes and constraints. Packages or subsystems

Class diagrams are used to model the static design view of a system. This view primarily supports the functional requirements of a system i.e the services the system should provide to its end users. When we model the static design view of a system, we will typically use class diagrams in one of three ways.

1. To model the vocabulary of a system Modeling the vocabulary of a system involves making a decision about which abstractions is a part of the system under consideration and which fall outside its boundaries. class diagrams are used to specify these abstractions and their responsibilities. 2. To model simple collaborations

Collaboration is a society of classes, interfaces, and other elements that work together to provide some cooperative behavior that's bigger than the sum of all the elements. For example, when we're modeling the semantics of a transaction in a distributed system, we can't just stare at a single class to understand what's going on. Rather, these semantics are carried out by a set of classes that work together.

Class diagrams are used to visualize and specify this set of classes and their relationships.

3. To model a logical database schema Think of a schema as the blueprint for the conceptual design of a database.
Page 3 G.Vijay kumar

OOAD [Object Oriented Analysis and Design]

In many domains, we'll want to store persistent information in a relational database or in an objectoriented database. we can model schemas for these databases using class diagrams

Common Modeling Techniques

Modeling Simple Collaborations

No class stands alone. Rather, each class works in collaboration with other classes to carry out some semantics greater than each individual. Therefore, in addition to capturing the vocabulary of our system, we'll also need to visualizing, specifying, constructing, and documenting the various ways these things in our vocabulary work together.

We use class diagrams to represent such collaborations. When we create a class diagram, we just model a part of the things and relationships that make up our system's design view.

1. To model a collaboration,
1. Identify the mechanism we'd like to model. A

mechanism represents some function or behavior of the part of the system we are modeling that results from the interaction of a society of classes, interfaces, and other things.
2. For each mechanism, identify the classes, interfaces,

and other collaborations that participate in this collaboration. Identify the relationships among these things, as well.
3. Use scenarios to walk through these things. Along the

way, we'll discover parts of our model that were missing and parts that were just plain semantically wrong. 4. Be sure to populate these elements with their contents. For classes, start with getting a good balance of responsibilities. Then, over time, turn these into concrete attributes and operations. For example

G.Vijay kumar

Page 4

OOAD [Object Oriented Analysis and Design]

The following figure focuses on the classes involved in the mechanism for moving the robot along a path. we'll find one abstract class (Motor) with two concrete children, SteeringMotor and MainMotor. Both of these classes inherit the five operations of their parent, Motor. The two classes are, in turn, shown as parts of another class, Driver. The class PathAgent has a one-to-one association to Driver and a one-to-many association to CollisionSensor. No attributes or operations are shown for PathAgent, although its responsibilities are given.

Modeling a Logical Database Schema

Many of the systems we'll model will have persistent objects, which mean that they can be stored in a database for later retrieval. Most often, we'll use a relational database, an object oriented database, or a hybrid object/relational database for persistent storage. The UML is well suited to modeling logical database schemas, as well as physical databases themselves. The UML's class diagrams are a superset of entity-relationship (E-R) diagrams, a common modeling tool for logical database design.

3. To model a schema,

Identify those classes in our model whose state must transcend the lifetime of their applications. Create a class diagram that contains these classes and mark them as persistent (a standard tagged value). we can define our own set of tagged values to address database-specific details. Expand the structural details of these classes. In general, this means specifying the details of their attributes and focusing on the associations and their cardinalities that structure these classes. Watch for common patterns that complicate physical database design, such as cyclic associations, oneto-one associations, and n-ary associations. Where necessary, create intermediate abstractions to simplify logical structure.

Consider also the behavior of these classes by expanding operations that are important for data access and data integrity. In general, to provide a better separation of concerns, business rules concerned with the manipulation of sets of these objects should be encapsulated in a layer above these persistent classes.

Where possible, use tools to help you transform your logical design into a physical design
Page 5

G.Vijay kumar

OOAD [Object Oriented Analysis and Design]

The figure shows a set of classes drawn from an information system for a school. This figure expands upon an earlier class diagram, the details of these classes revealed sufficient to construct a physical database.

Starting at the bottom-left of this diagram, we will find the classes named Student, Course, and Instructor.

There's an association between Student and Course, specifying that students attend courses.

Every student may attend any number of courses and every course may have any number of students

This diagram also exposes the attributes of all these classes. Notice that all the attributes are primitive types. Two of these classes (School and Department) expose several operations for manipulatingtheir parts. These operations are included because they are important to maintain data integrity

Forward and Reverse Engineering .Modeling is important, but we have to remember that the primary product of a development team is software, not diagrams.

Of course, the reason we create models is to predictably deliver at the right time the right software that satisfies the evolving goals of its users and the business. For some uses of the UML, the models you create will never map to code. Forward engineering is the process of transforming a model into code through a mapping to an implementation language. Forward engineering results in a loss of information, because models written in the UML are semantically richer than any current object-oriented programming language. In fact, this is a major reason why we need models in addition to code.
Page 6

Forward Engineering

G.Vijay kumar

OOAD [Object Oriented Analysis and Design]

To forward engineer a class diagram

Identify the rules for mapping to our implementation language or languages of choice. This is something we'll want to do for our project or our organization as a whole. Depending on the semantics of the languages we choose, we may have to constrain our use of certain UML features. For example, the UML permits us to model multiple inheritance, but Smalltalk permits only single inheritance. We can either choose to prohibit developers from modeling with multiple inheritance (which makes your models language-dependent) or develop idioms that transform these richer features into the implementation language (which makes the mapping more complex).

Use tagged values to specify our target language. we can do this at the level of individual classes if we need precise control. we can also do so at a higher level, such as with collaborations or packages. Use tools to forward engineer our models.

Example:The following example illustrates a simple class diagram specifying an instantiation of the chain of responsibility pattern. This particular instantiation involves three classes: Client, EventHandler, and GUIEventHandler. Client and EventHandler are shown as abstract classes, whereas GUIEventHandler is concrete. EventHandler has the usual operation expected of this pattern (handleRequest), although two private attributes have been added for this instantiation. All of these classes specify a mapping to Java, as noted in their tagged value. Forward engineering the classes in this diagram to Java is straightforward, using a tool. Forward engineering the class EventHandler yields the following code. public abstract class EventHandler { EventHandler successor; private Integer currentEventID; private String source;
G.Vijay kumar Page 7

OOAD [Object Oriented Analysis and Design]

EventHandler() {} public void handleRequest() {} } Reverse Engineering

Reverse engineering is the process of transforming code into a model through a mapping from a specific implementation language. At the same time, reverse engineering is incomplete. There is a loss of information when forward engineering models into code, and so we can't completely recreate a model from code unless our tools encode information in the source comments that goes beyond the semantics of the implementation language.

To reverse engineer a class diagram,

Identify the rules for mapping from our implementation language or languages of choice. Using a tool, point to the code we'd like to reverse engineer.

Use our tool to generate a new model or modify an existing one that was previously forward engineered.
Using that tool, create a class diagram by querying the model. For example, we might start with one or

more classes, then expand the diagram by following specific relationships or other neighboring classes. Expose or hide details of the contents of this class diagram as necessary to communicate our intent

G.Vijay kumar

Page 8

OOAD [Object Oriented Analysis and Design]

OBJECT DIAGRAMS
Object diagrams model the instances of things contained in class diagrams. An object diagram shows a set of objects and their relationships at a point in time. Object diagrams are used to model the static design view or static process view of a system. This involves modeling a snapshot of the system at a moment in time and rendering a set of objects, their state, and their relationships. Object diagrams are not only important for visualizing, specifying, and documenting structural models, but also for constructing the static aspects of systems through forward and reverse engineering. Terms and Concepts An object diagram is a diagram that shows a set of objects and their relationships at a point in time. Graphically, an object diagram is a collection of vertices and arcs Common Properties An object diagram is a special kind of diagram and shares the same common properties as all other diagrams that is, a name and graphical contents that are a projection into a model. . Object diagrams commonly contain Objects Links

Like all other diagrams, object diagrams may contain notes and constraints. Object diagrams may also contain packages or subsystems, both of which are used to group Sometimes, we'll want to place classes in our object diagrams, as well, especially when we want

elements of your model into larger chunks. to visualize the classes behind each instance.

Common Modeling Techniques

G.Vijay kumar Page 9

OOAD [Object Oriented Analysis and Design]

Modeling Object Structures Constructing a class diagram, a component diagram, or a deployment diagram, what we are really doing is capturing a set of abstractions that are interesting to us as a group and, in that context, exposing their semantics and their relationships to other abstractions in the group. These diagrams show only potentiality. If class A has a one-to-many association to class B, then for one instance of A there might be five instances of B; for another instance of A there might be only one instance of B. Furthermore, at a given moment in time, that instance of A, along with the related instances of B, will each have certain values for their attributes and state machines. To model an object structure,

Identify the mechanism we like to model. A mechanism represents some function or behavior of the part of the system we are modeling that results from the interaction of a society of classes, interfaces, and other things.

For each mechanism, identify the classes, interfaces, and other elements that participate in this

collaboration; identify the relationships among these things, as well.

Consider one scenario that walks through this mechanism. Freeze that scenario at a moment in time, and

render each object that participates in the mechanism.

Expose the state and attribute values of each such object, as necessary, to understand the scenario. Similarly, expose the links among these objects, representing instances of associations among them.

For example, Figure 14-2 shows a set of objects drawn from the implementation of an autonomous robot. This figure focuses on some of the objects involved in the mechanism used by the robot to calculate a model of the world in which it moves. There are many more objects involved in a running system, but this diagram focuses on only those abstractions that are directly involved in creating this world view.

G.Vijay kumar

Page 10

OOAD [Object Oriented Analysis and Design]

Enumerate the steps to model object structures. Illustrate with an object diagram. Enumerate the steps to model simple collaborations. (b) Enumerate the steps to model logical database schema. (c) What is class diagram?

G.Vijay kumar

Page 11