Describe the following with respect to Common Modeling Techniques: A) Modeling object Structures B) Forward and Reverse Engineering C) Object Diagrams

A) Modeling Object Structures
When you construct a class diagram, a component diagram, or a deployment diagram, what you are really doing is capturing a set of abstractions that are interesting to you 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-tomany association to class B, then for one instance of A there might be
live 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. If you freeze a running system or just imagine a moment of time in a

modeled system, you’ll find a set of objects, each in a specific state, and each in a particular relationship to other objects. You can use object diagrams to visualize, specify, construct, and document the structure of
these objects. Object diagrams are especially useful for modeling complex data structures. When you model your system’s design view, a set of class diagrams can be used to completely specify the semantics of your abstractions and their relationships. With object diagrams, however, you cannot completely specify the object structure of your system. For an individual class, there may be a multitude of possible instances, and for a set of classes in relationship to one another, there may be many times more possible configurations of these objects. Therefore, when you use object diagrams, you can only meaningfully expose interesting sets of concrete or prototypical objects. This is what it means to model an object structure 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.

B) Forward and Reverse Engineering
Forward engineering (the creation of code from a model) 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. Although this is true of most typical object diagrams (which contain instances of classes), it’s not true of object diagrams containing instances of components and of nodes. Both of these are special cases of
component diagrams and deployment diagrams, respectively, and are discussed elsewhere. In these cases, component instances and node instances are things that live outside the running system and are amenable to some degree of forward engineering. Reverse engineering (the creation of a model from code) an object
diagram is a very different thing. In fact, while you are debugging your system, this is something that you or your tools will do all the time. For example, if you are chasing down a dangling link, you’ll want to literally
or mentally draw an object diagram of the affected objects to see where, at a given moment in time, an object’s state or its relationship to other objects is broken. 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.
· 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.

C) 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. You use object diagrams 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.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.