Unit IV

Classes and Object Diagrams

Class Diagrams
A class diagram shows a set of classes, interfaces, and collaborations and their relationships. Graphically, a class diagram is a collection of vertices and arcs.

Common Properties Contents Class diagrams commonly contain the following things: o Classes o Interfaces o Collaborations o Dependency, generalization, and association relationships Like all other diagrams, class diagrams may contain notes and constraints Class diagrams may also contain packages or subsystems

Note: Component diagrams and deployment diagrams are similar to class diagrams, except that instead of containing classes, they contain components and nodes Common Uses o You use class diagrams to model the static design view of a system. This view primarily supports the functional requirements of a system o We'll typically use class diagrams in one of three ways: 1. To model the vocabulary of a system 2. To model simple collaborations 3. To model a logical database schema Modeling the vocabulary of a system o Modeling the vocabulary of a system involves making a decision about which abstractions are a part of the system under consideration and which fall outside its boundaries Modeling simple collaborations o A 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. Modeling logical database schema o We can model schemas for these databases using class diagrams.

Common Modeling Techniques

Modeling Simple Collaborations o When you create a class diagram, you just model a part of the things and relationships that make up your system's design view. For this reason, each class diagram should focus on one collaboration at a time. o To model a collaboration o Identify the mechanism you'd like to model. A mechanism represents some function or behavior of the part of the system you are modeling that results from the interaction of a society of classes, interfaces, and other things. o For each mechanism, identify the classes, interfaces, and other collaborations that participate in this collaboration. Identify the relationships among these things, as well. o Use scenarios to walk through these things. Along the way, you'll discover parts of your model that were missing and parts that were just plain semantically wrong. o 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.

Unit IV

Classes and Object Diagrams

Modeling a Logical Database Schema o The UML is well-suited to modeling logical database schemas, as well as physical databases themselves. o The UML's class diagrams are a superset of entity-relationship (E-R) diagrams, Whereas classical E-R diagrams focus only on data, class diagrams go a step further by permitting the modeling of behavior, as well. In the physical database these logical operations are generally turned into triggers or stored procedures. o To model a schema, o Identify those classes in your model whose state must transcend the lifetime of their applications. o Create a class diagram that contains these classes and mark them as persistent (a standard tagged value). You can define your own set of tagged values to address database-specific details. o 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. o Watch for common patterns that complicate physical database design, such as cyclic associations, one-to-one associations, and n-ary associations. Where necessary, create intermediate abstractions to simplify your logical structure. o 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. o Where possible, use tools to help you transform your logical design into a physical design.

Modeling a Schema Forward and Reverse Engineering o Forward engineering is the process of transforming a model into code through a mapping to an implementation language o Forward engineering results in a loss of information, because models written in the UML are semantically richer than any current object-oriented programming language. o To forward engineer a class diagram,

Identify the rules for mapping to your implementation language or languages of choice. This is something you'll want to do for your project or your organization as a whole. o Depending on the semantics of the languages you choose, you may have to constrain your use of certain UML features. For example, the UML permits you to model multiple inheritance, but Smalltalk permits only single inheritance. You 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). o Use tagged values to specify your target language. You can do this at the level of individual classes if you need precise control. You can also do so at a higher level, such as with collaborations or packages.

Unit IV

Classes and Object Diagrams

o Use tools to forward engineer your models.

Forward Engineering

Reverse engineering is the process of transforming code into a model through a mapping from a specific implementation language. Reverse engineering results in a flood of information, some of which is at a lower level of detail than you'll need to build useful models. Reverse engineering is incomplete. There is a loss of information when forward engineering models into code, and so you can't completely recreate a model from code unless your tools encode information in the source comments that goes beyond the semantics of the implementation language. To reverse engineer a class diagram, o Identify the rules for mapping from your implementation language or languages of choice. This is something you'll want to do for your project or your organization as a whole. Using a tool, point to the code you'd like to reverse engineer. Use your tool to generate a new model or modify an existing one that was previously forward engineered. Using your tool, create a class diagram by querying the model. For example, you 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 your intent.

Object Diagram
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 An object diagram is a special kind of diagram and shares the same common properties as all other diagramsthat is, a name and graphical contents that are a projection into a model

Contents 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 Common Uses You use object diagrams to model the static design view or static process view of a system just as you do with class diagrams When you model the static design view or static process view of a system, you typically use object diagrams in one way:

Unit IV

Classes and Object Diagrams

To model object structures

Modeling Object Structures Modeling object structures involves taking a snapshot of the objects in a system at a given moment in time. An object diagram represents one static frame in the dynamic storyboard represented by an interaction diagram

Common Modeling Techniques Modeling Object Structures

An object diagram shows one set of objects in relation to one another at one moment in time. To model an object structure, Identify the mechanism you'd like to model. A mechanism represents some function or behavior of the part of the system you 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.

Modeling Object Structures Forward and Reverse Engineering Forward engineering an object diagram is theoretically possible but pragmatically of limited value

In an object-oriented system, instances are things that are created and destroyed by the application during run time. Therefore, you can't exactly instantiate these objects from the outside. Component instances and node instances are things that live outside the running system and are amenable to some degree of forward engineering. Reverse engineering an object diagram is a very different thing To reverse engineer an object diagram, Chose the target you want to reverse engineer. Typically, you'll set your context inside an operation or relative to an instance of one particular class. Using a tool or simply walking through a scenario, stop execution at a certain moment in time.

Unit IV

Classes and Object Diagrams

Identify the set of interesting objects that collaborate in that context and render them in an object diagram. As necessary to understand their semantics, expose these object's states.

As necessary to understand their semantics, identify the links that exist among these objects. If your diagram ends up overly complicated, prune it by eliminating objects that are not germane to the questions about the scenario you need answered. If your diagram is too simplistic, expand the neighbors of certain interesting objects and expose each object's state more deeply.

www.jntuworld.com