1 / 122

UNIT-III

UNIT-III. Class Diagram and Composite Structure Diagram P. P. Mahale. Object Diagrams. 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

bradyj
Download Presentation

UNIT-III

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. UNIT-III Class Diagram and Composite Structure Diagram P. P. Mahale

  2. Object Diagrams • 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 • Objects • Links • Common Uses To model object structures

  3. Object Diagrams Common Modeling Techniques Modeling Object Structures 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.

  4. 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.

  5. Object Diagrams

  6. Object Diagrams

  7. Link: • A link is a physical or conceptual (semantic) connection between object instances. • Messages : • It is a specification of communication among objects that convey information with expectation that activity will ensure • Model actions like:- • Call – invoke operation on an object 3. send • return:- return value to caller 4. create 5. destroy

  8. sequencing :- - Sequence is formed by stream of messages

  9. Class Diagrams • When writing software you are constantly making design decisions: • what classes hold references to other classes, • which class "owns" some other class, and so on. • Class diagrams provide a way to capture this "physical" structure of a system.

  10. Classes • A class represents a group of things that have common state and behavior. UML suggests that the class name: • Start with a capital letter • Be centered in the top compartment • Be written in a boldface font • Be written in italics if the class is abstract

  11. Objects An object is an instance of a class.

  12. Attributes • Details of a class are represented as attributes. • Attributes can be simple primitive types (integers, floating-point numbers, etc.) or relationships to other complex objects. • An attribute can be shown using two different notations: inlined or relationships between classes. • In addition, notation is available to show such things as multiplicity, uniqueness, and ordering.

  13. Inline attributes • UML refers to inlined attributes as attribute notation . Inlined attributes use the following notation: visibility / name : type multiplicity = default {property strings and constraints } visibility ::= {+|-|#|~} multiplicity ::= [lower..upper]

  14. The syntax elements are: • Visibility: Indicates the visibility of the attribute. Use the following symbols: +, -, #, or ~ for public, private, protected, or package, respectively • / : Indicates the attribute is derived . • Name: Is a noun or short phrase naming the attribute. Typically the first letter is lowercase, and the first letter of each subsequent word is capitalized. • Type: Is the type of the attribute as another classifier, typically a class, interface, or built-in type like int.

  15. Multiplicity: Specifies how many instances of the attribute's type are referenced by this attribute. • Default: Is the default value of the attribute. • property strings: Is a collection of properties, or tags, that can be attached to attributes. These are typically context-specific and denote such things as ordering or uniqueness. They are surrounded by {} and separated by commas. See "Properties.“ • Constraints: Are one or more restrictions placed on an attribute. They may be natural language or use a formal grammar such as the OCL.

  16. Attributes by Relationship • The relationship notation results in a larger class diagram, but it can provide greater detail for complex attribute types. • The relationship notation also conveys exactly how the attribute is contained within a class

  17. Figure 2-5. Relationship notation using constraints

  18. Derived Attribute • The derived notation, which is the leading forward slash (/), can be used as an indicator to the implementer that the attribute may not be strictly necessary.

  19. Derived property is property which value (or values) is produced or computed from other information, for example, by using values of other properties.

  20. Attribute Multiplicity • The multiplicity of an attribute specifies how many instances of the attribute's type are created when the owning class is instantiated.

  21. Ordering • An attribute with a multiplicity greater than 1 can be specified to be ordered . • If the attribute is ordered, the elements must be stored sequentially.

  22. Uniqueness • In addition to being ordered, an attribute with multiplicity greater than 1 may be required to be unique Figure:- Unique multiplicity

  23. Attribute Properties The common properties defined by UML are: • readOnly: Specifies that the attribute may not be modified once the initial value is set. • Union: Specifies that the attribute type is a union of the possible values for this attribute. • Subsets <attribute-name>: Specifies that this attribute type is a subset of all the valid values for the given attribute. • redefine <attribute-name>: Specifies that this attribute acts as an alias for the given attribute. • Composite: Specifies that this attribute is part of a whole part relationship with the classifier

  24. Constraints • Constraints represent restrictions placed on an element. Fig- Example of inlined and note constraints

  25. Static attributes • Static attributes are attributes of the class rather than of an instance of the class.

  26. Operations • Operations are features of classes that specify how to invoke a particular behavior. • syntax: visibility name ( parameters ) : return-type {properties} where parameters are written as: direction parameter_name : type [ multiplicity ] = default_value { properties }

  27. Visibility • Name • return-type • Properties • Parameter syntax elements are: • Direction: An optional part of the syntax that indicates how a parameter is used by an operation. It is one of in, inout, out, or return. in states that the parameter is passed to the operation by the caller. • parameter_name: Is a noun or noun phrase naming the parameter. • Type: Is the type of the parameter. • Multiplicity: default_value • Properties: Specifies any parameter-related properties and is specified between curly braces.

  28. Operation Constraints • An operation may have several constraints associated with it that help define how the operation interacts with the rest of the system. Precondition: • Preconditions capture what the state of the system must be before an operation can be invoked.

  29. Postconditions • Postconditions capture guarantees about the state of the system after an operation has executed.

  30. Body condition: • An operation may have a body Condition that constrains the return value.

  31. Query operations: • An operation may be declared as a query operation if the implementation of the operation doesn't modify the owning class in any way.

  32. Exceptions: • Exceptions are often used to reflect abnormal conditions that are part of common operations such as creating a new file, opening a socket, or dividing by zero.

  33. Abstract Classes • An abstract class is typically a class that provides an operation signature, but no implementation; however, you can have an abstract class that has no operations at all. • An abstract class is useful for identifying common functionality across several types of objects.

  34. Relationships • Classes in isolation would not provide much insight into how a system is designed. UML provides several ways of representing relationships between classes. 1. Dependency • The weakest relationship between classes is a dependency relationship. Dependency between classes means that one class uses, or has knowledge of, another class. • Dependencies are typically read as "...uses a...". • A dependency relationship indicates that changes to independent model element can cause changes in another model element. The supplier model element is independent because a change in the client does not affect it.

More Related