UNIT-2 OOM.pptxUNIT-2 OOM.pptxUNIT-2 OOM.pptx

UNIT-2 OOM.pptxUNIT-2 OOM.pptxUNIT-2 OOM.pptxUNIT-2 OOM.pptxUNIT-2 OOM.pptxUNIT-2 OOM.pptx

1. UNIT-II Advanced Structural Modeling: Advanced classes, advanced relationships, Interfaces, Types and Roles, Packages, Common modelling techniques. Class & Object Diagrams: Terms, concepts, modeling techniques for Class & Object Diagrams, Common modelling techniques.

2. Why Use Advanced Structural Modeling? Handle Complex Systems : Models intricate relationships, behaviors, and real-world complexities. Enhance Accuracy : Provides precise designs with advanced classes and relationships. Represent Real Scenarios : Captures dynamic roles and states of objects. Support Reusability : Promotes modular and scalable system design using packages and interfaces. Provide Static & Runtime Views : Combines class diagrams (static) and object diagrams (runtime). Improve Communication : Offers clarity for all stakeholders to understand the system’s structure.

3. STRUCTARAL/ADVANCED STRUCTURAL Structural model represents a view of a system that focuses on the structure of the objects, including their classifiers, relationships, attributes and operations. The advanced Structural Modeling describes some advanced features of classes and their relationships. Advanced Classes feature contains classifier, visibility and scope. The classifier is a modeling element that defines attributes and operations. It can be accessed by other classifiers through the visibility feature.

4. Advanced classes Classifier A classifier is a kind of UML element that is used to define some common features in terms of structural (attributes) as well as behavioral (operations). Class, interface, data Types, use case, collaboration, node, signal and subsystems all are examples ofclassifier. A class is an important type of classifier in UML, which describes a group of objects that share the same features. Some more classifiers are given as follows: Interface : It is collection of named operations that describe the behavior of an element. Datatype : its values have no identity, including primitive built-in type (eg. number, string) and enumeration types (eg. Boolean). Node : It is a run-time physical object that denotes a computational resource such as a server, router etc. Signal : An asynchronous event communicated between objects. Use case : It is a list of stages that explain how a process will be carried out in a system. Component : A component is used to split the actual system into various modular parts.

5. Advanced Classes contd … Visibility - UML, you can specify any of three levels of visibility. public Any outside classifier with visibility to the given classifier can use the feature specified by prepending the symbol +. protected Any descendant of the classifier can use the feature; specified by prepending the symbol #. private Only the classifier itself can use the feature; specified by prepending the symbol.

6. Scope 1. instance Each instance of the classifier holds its own value for the feature. 2. classifier There is just one value of the feature for all instances of the classifier.

7. Multiplicity - The number of instances a class may have is called its multiplicity. Multiplicity is a specification of the range of allowable cardinalities an entity may assume.

8. Attributes In its full form, the syntax of an attribute in the UML is [visibility] name [multiplicity] [: type] [= initial-value] [{property-string}] name : The name of the attribute. [multiplicity] : Specifies how many instances of the attribute are allowed, e.g., 1, 0..1, 1..*. [: type] : Specifies the data type of the attribute, e.g., int, String, etc. [= initial-value] : An optional part that assigns a default value to the attribute. [{property-string}] : Includes additional constraints or properties like {readOnly}, {unique}. - age : int = 18 + name : String # scores [0..*] : float

9. There are three defined properties that you can use with attributes. changeable addOnly Frozen 1. changeable: Meaning : This is the default property for attributes in UML. It means the value of the attribute can be modified after it is initially set . EXAMPLE + age : int {changeable} addOnly: Meaning : The attribute allows only the addition of new values, but existing values cannot be removed or modified. Usage : This is typically applied to attributes with a collection or multiplicity greater than 1 + scores [0..*] : float {addOnly} Operations In its full form, the syntax of an operation in the UML is [visibility] name [(parameter-list)] [: return-type] [{property- string}]

10. 3. frozen: Meaning : Indicates that the value of the attribute is immutable once it is set. It cannot be changed during the object's lifecycle. + identifier : String {frozen} EXAMPLE : Person + name : String {changeable} + age : int {changeable} + id : String {frozen} + hobbies [0..*] : String {addOnly} Operations In its full form, the syntax of an operation in the UML is [visibility] name [(parameter-list)] [: return-type] [{property- string}]

11. In an operation's signature, you may provide zero or more parameters, each of which follows the syntax [direction] name : type [= default-value] Direction may be any of the following values in out Inout 1. in Parameter Purpose : The parameter is used to pass data into the operation. The operation can read this value but cannot modify it in a way that affects the caller. EX:+ calculateArea(length: in int, width: in int) : float 2.out Parameter Purpose : The parameter is used to pass data out of the operation. The operation assigns a value to this parameter, which is then returned to the caller. EX:+ findMax(numbers: in int[], max: out int) -there are four defined properties that you can use with operations. 1)IsQuery 2)Sequential 3)Guarded 4)Concurrent

12. inout Parameter Purpose : The parameter is used to pass data both into and out of the operation. The operation can read the initial value of the parameter, modify it, and then pass it back to the caller. Example : + updateBalance(balance: inout float, transaction: in float) PROPERTIES: -there are four defined properties that you can use with operations. 1)IsQuery 2)Sequential 3)Guarded 4)Concurrent

13. 1. Query A query operation is an operation that retrieves information from an object without changing its state. It is a read-only operation. Key Characteristics : Does not modify the object’s attributes or relationships. Often annotated with {query} in UML diagrams. Example : plaintext Copy code + getBalance() : float {query} Meaning : This operation retrieves the balance without modifying the object. Use Case : Query operations are used for calculations, reporting, or retrieving information. 2. Sequential Sequential refers to operations or processes that are executed one after the other , in a linear sequence. Key Characteristics : Each operation completes before the next one begins. No parallelism or concurrency is involved. Example in UML Activity Diagram : plaintext Copy code [Activity 1] --> [Activity 2] --> [Activity 3] Meaning : Activity 2 starts only after Activity 1 completes, and Activity 3 starts after Activity 2. Use Case : Sequential behavior is useful when steps must be executed in a strict order, such as in transaction processing.

14. 3. Guard A guard is a condition that must be true for a transition or an action to occur in UML state diagrams or activity diagrams. Key Characteristics : Guards are boolean expressions enclosed in square brackets [condition]. The transition happens only if the guard evaluates to true. Example in State Diagram : e [state1] -- [x > 5] --> [state2] Meaning : Transition from state1 to state2 occurs only if x > 5. Use Case : Guards are commonly used to control decision points or to restrict transitions in state machines or workflows. 4. Concurrent Concurrent refers to processes or operations that occur at the same time, either independently or with some level of synchronization. Key Characteristics : Represented in UML activity diagrams with a fork or join node. Can involve multiple threads, processes, or parallel activities.

15. Template Classes - A template is a parameterized element. In such languages as C++ and Ada, you can write template classes, each of which defines a family of classes (you can also write template functions, each of which defines a family of functions). template<class Item, class Value, int Buckets> class Map { public: virtual Boolean bind(const Item&, constValue&); virtual Boolean isBound(const Item&) const; ... };

16. Template Classes In UML (Unified Modeling Language) , a template class is depicted as a generic class that can work with multiple data types. It is a blueprint that uses template parameters . Example : template <type name T> +----------------------+ Stack<T> <------ Template Class <<template>> +----------------------+ - items: T* - top: int - maxSize: int +----------------------+ + Stack(size: int) + push(item: T): void + pop(): T + isEmpty(): bool +----------------------+

17. Standard Elements The UML defines four standard stereotypes that apply to classes. 1)Metaclass 2)Powertype 3)Streotype 4)Utility

18. Example <<metaclass>> Class (meta class) <<stereotype>> <<Persistent>> ( A stereotype extends the metaclass) isCached: Boolean (Attribute) Customer name: String email: String save(): void delete(): void <<Persistent>>

19. Power type Definition: Specifies a class whose objects are the children of a given parent class. A power type is a classifier used to define a taxonomy or hierarchy.

20. Utility Specifies a class whose attributes and operations are all class-scoped (i.e., static). Utility classes typically group common functions or constants

21. Advanced relationships Dependency The UML defines a number of stereotypes that may be applied to dependency relationships. There are 17 such stereotypes, all of which can be organized into six groups. First, there are eight stereotypes that apply to dependency relationships among classes and objects in class diagrams. there are two stereotypes that apply to dependency relationships among packages. Two stereotypes apply to dependency relationships among use cases three stereotypes when modeling interactions among objects. One stereotype you'll encounter in the context of state machines one stereotype that you'll encounter in the context of organizing the elements of your system into subsystems

22. Dependency relationships among classes and objects in class diagrams

23. UML-Dependency Dependency depicts how various things within a system are dependent on each other. In UML, a dependency relationship is the kind of relationship in which a client (one element) is dependent on the supplier (another element). It is used in class diagrams, component diagrams, deployment diagrams, and use-case diagrams, which indicates that a change to the supplier necessitates a change to the client. An example is given below:            Types of Dependency Relationship Following are the type of dependency relationships, keywords, or stereotypes given below:

24. <<Bind>> - It is a constraint that specifies the template can be initialized by the source at the target location utilizing given parameters. <<derive>> - It represents that the source object's location can be evaluated from the target object. <<friend>> - It states the uniqueness of the source in the target object.

25. <<instanceOf>> - It states that an instance of a target classifier is the source object. <<instantiate>> - It defines the capability of the source object, creating instances of a target object. <<refine>> - It states that the source object comprises of exceptional abstraction than that of the target object. <<use>> - When the packages are created in UML, the use of stereotype is used as it describes that the elements of the source package can also exist in the target package. It specifies that the source package uses some of the elements of the target package.

26. <<substitute>> - The substitute stereotype state that the client can be substituted at the runtime for the supplier. <<access>> - It is also called as private merging in which the source package accesses the element of the target package. <<import>> - It specifies that target imports the source package's element as they are defined within the target. It is also known as public merging. <<permit>> - It describes that the source element can access the supplier element or whatever visibility is provided by the supplier. <<extend>> - It states that the behavior of the source element can be extended by the target. <<include>> - It describes the source element, which can include the behavior of another element at a specific location, just like a function call in C/C++. <<become>> - It states that target is similar to the source with distinct roles and values. <<call>> - It specifies that the target object can be invoked by the source. <<copy>> - It states that the target is an independent replica of a source object. <<parameter>> - It describes that the supplier is a parameter of the client's actions. <<send>> - The client act as an operation, which sends some unspecified targets to the supplier.

27. Example for Bind

28. Example for derive

29. Example for Friend

30. Example for instance of

31. Instantiate

32. Examples for powertype and refine and use

33. among packages. there are two stereotypes that apply to dependency relationships among packages. access : Specifies that the source package is granted the right to reference the elements of the target package .A kind of access that specifies that the public contents of the target package enter the Import : flat namespace of the source, as if they had been declared in the source

34. Examples

35. among use cases Two stereotypes apply to dependency relationships among use cases: 1. extend : Specifies that the target use case extends the behavior of the source 2.i nclude: Specifies that the source use case explicitly incorporates the behavior of another

36. Examples

37. among objects& Interactions. You'll encounter three stereotypes when modeling interactions among objects. 1. become :Specifies that the target is the same object as the source but at a later point in time and with possibly different values, state, or roles 2. call: Specifies that the source operation invokes the target operation 3. copy : Specifies that the target object is an exact, but independent, copy of the source

38. Examples

39. state machines One stereotype you'll encounter in the context of state machines is Send: Specifies that the source operation sends the target event You'll use send when you want to model an operation (such as found in the action associated with a state transition) dispatching a given event to a target object (which in turn might have an associated state machine). The send dependency in effect lets you tie independent state machines together.

40. subsystems one stereotype that you'll encounter in the context of organizing the elements of your system into subsystems and models is trace Specifies that the target is an historical ancestor of the source

41. Generalization the UML defines one stereotype and four constraints that may be applied to generalization relationships there is the one stereotype. implementation Specifies that the child inherits the implementation of the parent but does not make public nor support its interfaces, thereby violating substitutability

42. Generalization Next, there are four standard constraints that apply to generalization relationships. complete: Specifies that all children in the generalization have been specified in the model (although some may be elided in the diagram) and that no additional children are permitted incomplete: Specifies that not all children in the generalization have been specified (even if some are elided) and that additional children are permitted disjoint : Specifies that objects of the parent may have no more than one of the children as a type overlapping: Specifies that objects of the parent may have more than one of the children as a type

43. Association Association

44. Association Visibility

45. Association Qualification

46. Interface Specifier

47. Association class

48. Composition Aggregation turns out to be a simple concept with some fairly deep semantics. Simple aggregation is entirely conceptual and does nothing more than distinguish a "whole" from a "part." Simple aggregation does not change the meaning of navigation across the association between the whole and its parts, nor does it link the lifetimes of the whole and its parts

49. Composition

50. Constraints 1.Implicit 2.Ordered 3.Changable 4.Addonly 5.Frozen

51. Realization Realization A realization is a semantic relationship between classifiers in which one classifier specifies a contract that another classifier guarantees to carry out.

52. Realization of an Interface

53. Interfaces, Types, and Roles Interfaces define a line between the specification of what an abstraction does and the implementation of how that abstraction does it. An interface is a collection of operations that are used to specify a service of a class or a component. A type is a stereotype of a class used to specify a domain of objects, together with the operations (but not the methods) applicable to the object. A role is the behavior of an entity participating in a particular context. Graphically, an interface is rendered as a circle;

54. An interface is a collection of operations that are used to specify a service of a class or a component. Names An interface name must be unique within its enclosing package. Operations An interface is a named collection of operations used to specify a service of a class or of a component. Relationships Like a class, an interface may participate in generalization, association, and dependency relationships.