10-07-2012, 02:38 PM
Structure diagrams emphasize
Structure diagrams emphasize the things that must be present in the system being modeled. Since structure diagrams represent the structure, they are used extensively in documenting the software architecture of software systems.
Object diagram: shows a complete or partial view of the structure of an example modeled system at a specific time.
• Well, if you looked at a class diagram, you would not get the picture of how these classes interact with each other at runtime, and in the actual system, how the objects created at runtime are related to the classes.
• An object diagram shows this relation between the instantiated classes and the defined class, and the relation between these objects, in the logical view of the system.
• These are very useful to explain smaller portions of your system, when your system class diagram is very complex
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.
In UML modeling, interfaces are model elements that define sets of operations that other model elements, such as classes, or components must implement. An implementing model element realizes an interface by overriding each of the operations that the interface declares.
You can use interfaces in class diagrams and component diagrams to specify a contract between the interface and the classifier that realizes the interface. Each interface specifies a well-defined set of operations that have public visibility. The operation signatures tell the implementing classifiers what kind of behavior to invoke, but not how they should invoke that behavior. Many classifiers can implement a single interface, each one providing a unique implementation.
Interfaces support the hiding of information and protect client code by publicly declaring certain behavior or services. Classes or components that realize the interfaces by implementing this behavior simplify the development of applications because developers who write client code need to know only about the interfaces, not about the details of the implementation. If you replace classes, or components that implement interfaces, in your model, you do not need to redesign your application if the new model elements implement the same interfaces.
Instance specifications in UML
In UML models, instance specifications are elements that represent an instance in the modeled system. When you instantiate a classifier in a model, the instance specification that you create represents an entity in the modeled system at a point in time, similar to a snapshot of the entity. You can model changes to the entity over time by creating several instance specifications, one for each snapshot.
Instance specifications can include the following information about the entity:
• The classification of the entity by one or more classifiers of which the entity is an instance
• The kind of instance, based on its classifiers; for example, an instance specification whose classifier is a class describes an object of that class, while an instance specification whose classifier is an association describes a link of that association
• Specific values of the structural features of the entity, which are represented by slots