Package diagram in UML (Object Oriented System Development)

Package Diagram in Object Oriented System Development (UML)

1. PACKAGE DIAGRAM

2. Generalization There are two kinds of relationships you can have between packages: import and access dependencies - used to import into one package elements exported from another generalizations - used to specify families of packages. Generalization among packages is very much like generalization among classes.

3. For example, the package GUI is shown to export two classes (Window and Form) and one protected class (EventHandler). Two packages specialize the more general package GUI:WindowsGUI and MacGUI. These specialized packages inherit the public and protected elements of the more general package. But, just as in class inheritance, packages can replace more general elements and add new ones. For example, the package WindowsGUI inherits from GUI, so it includes the classes GUI::Window and GUI::EventHandler. In addition, WindowsGUI overrides one class (Form) and adds a new one (VBForm).

4. Standard Elements facade and stub - These two stereotypes help you to manage very large models. You use facades to provide elided views

5. Common Modeling Techniques Modeling Groups of Elements The most common purpose for which you'll use packages is to organize modeling elements into groups that you can name and manipulate as a set. For example, Figure shows a set of packages that organize the classes in an information system's design view into a classic three-tier architecture. The elements in the package User Services provide the visual interface for presenting information and gathering data. The elements in the package Data Services maintain, access, and update data. The elements in the package Business Services bridge the elements in the other two packages and encompass all the classes and other elements that manage requests from the user to execute a business task, including business rules that dictate the policies for manipulating data.

6. Modeling Architectural Views

7. To model architectural views, Identify the set of architectural views that are significant in the context of your problem. This typically includes a design view, a process view, an implementation view, a deployment view, and a use case view. Place the elements (and diagrams) that are necessary and sufficient to visualize, specify construct, and document the semantics of each view into the appropriate package. As necessary, further group these elements into their own packages. There will typically be dependencies across the elements in different views. So, in general, let each view at the top of a system be open to all others at that level

8. Instances The terms "instance" and "object" are largely synonymous An abstraction denotes the ideal essence of a thing; an instance denotes a concrete manifestation.

9. An instance is a concrete manifestation of an abstraction to which a set of operations can be applied and which has a state that stores the effects of the operations. Instance and object are largely synonymous. Graphically, an instance is rendered by underlining its name. Most instances you'll model with the UML will be instances of classes (and these things are called objects), although you can have instances of other things, such as components, nodes, use cases, and associations. In the UML, an instance is easily distinguishable from an abstraction. To indicate an instance, you underline its name.

10. In a general sense, an object is something that takes up space in the real or conceptual world, and you can do things to it. For example, an instance of a node is typically a computer that physically sits in a room; an instance of a customer record consumes some amount of physical memory. The classifier of an instance is usually static. For example, once you create an instance of a class, its class won't change during the lifetime of that object. In some modeling situations and in some programming languages, however, it is possible to change the abstraction of an instance. For example, a Caterpillar object might become a Butterfly object. It's the same object, but of a different abstraction.

11. Every instance must have a name that distinguishes it from other instances within its context. A name is a textual string, such as t and myCustomer in Figure

12. That name alone is known as a simple name. The abstraction of the instance may be a simple name (such as Transaction) or it may be a path name (such as Multimedia::AudioStream) which is the abstraction's name prefixed by the name of the package in which that abstraction lives. An object also has state, which in this sense encompasses all the (usually static) properties of the object plus the current (usually dynamic) values of each of these properties. These properties include the attributes of the object, as well as all its aggregate parts. An object's state is therefore dynamic.

13. OBJECT DIAGRAM

14. Object Diagrams An Object Diagram can be referred to as a screenshot of the instances in a system and the relationship that exists between them. An object diagram in UML is useful because it provides a clear and visual representation of specific instances of classes and their relationships at a particular point in time, aiding in understanding and communicating the structure and interactions within a system. In other words, "An object diagram in the Unified Modeling Language (UML), is a diagram that shows a complete or partial view of the structure of a modeled system at a specific time. Object diagrams in UML are depicted using a simple and intuitive notations to show a snapshot of a system at a specific point in time, displaying instances of classes and their relationships.

15. What is an Object? An object refers to a specific instance of a class within a system. A class is a blueprint or template that defines the common attributes and behaviors shared by a group of objects. An object, on the other hand, is a concrete and individual occurrence of that class, possessing unique values for its attributes.

16. What is a Classifier? In UML a classifier refers to a group of elements that have some common features like methods, attributes and operations. A classifier can be thought of as an abstract metaclass which draws a boundary for a group of instances having common static and dynamic features. For example: we refer a class, an object, a component, or a deployment node as classifiers in UML since they define a common set of properties.

17. Object Diagram Notations

18. Objects or Instance specifications When we instantiate a classifier in a system, the object we create represents an entity which exists in the system. We can represent the changes in object over time by creating multiple instance specifications. We use a rectangle to represent an object in an object diagram.

19. Attributes and Values Inside the object box, attributes of the object are listed along with their specific values. Link We use a link to represent a relationship between two objects. We represent the number of participants on the link for each, at the end of the link. The term link is used to specify a relationship between two instance specifications or objects. We use a solid line to represent a link between two objects.

20. For Example - In the figure below, an object of class Student is linked to an object of class College.

21. Dependency Relationships We use a dependency relationship to show when one element depends on another element. A dependency is used to depict the relationship between dependent and independent entities in the system. Any change in the definition or structure of one element may cause changes to the other. This is a unidirectional kind of relationship between two objects. Dependency relationships are of various types specified with keywords like Abstraction, Binding, Realization, Substitution and Usage are the types of dependency relationships used in UML.

22. For example - In the figure below, an object of Player class is dependent (or uses) an object of Bat class.

23. Association Association is a reference relationship between two objects (or classes). An association line connects two object boxes, representing a relationship between instances of two classes. We use association when one object references members of the other object. Association can be uni-directional or bi-directional. We use an arrow to represent association.

24. For example - The object of Order class is associated with an object of Customer class.

25. Aggregation Aggregation represents a "has a" relationship. We use a hollow diamond on the containing object with a line which joins it to the contained object. Aggregation is a specific form of association. It is a kind of parent-child relationship however it isn't inheritance. Aggregation occurs when the lifecycle of the contained objects does not strongly depend on the lifecycle of container objects.

26. For example - A library has an aggregation relationship with books. Library has books or books are a part of library. The existence of books is independent of the existence of the library.

27. Composition Composition is a type of association where the child cannot exist independent of the other. We use a filled diamond on the containing object with a line which joins it to the contained object. Composition is also a special type of association. It is also a kind of parent child relationship but it is not inheritance. So whenever independent existence of the child is not possible we use a composition relationship.

28. How to draw an Object Diagram? Identify Classes:   Determine the classes relevant to the scenario you want to depict. Classes are the blueprints that define the attributes and behaviors shared by their instances. Identify Objects:   Identify specific instances or objects of each class that you want to include in the diagram. These represent the actual things in your system. Create Object Boxes:   Draw rectangles to represent the specific instances or objects of each class. Write the name of each object inside the box. Add Attributes and Values:   Inside each object box, list the attributes of that object along with their specific values.

29. Draw Relationships: Connect the object boxes with lines to represent relationships or associations between instances. Use arrows to indicate the direction of the association if necessary. Label Relationships: Label the relationships with multiplicity and role names if needed. Label the association lines with a verb or phrase to describe the nature of the relationship. Review and Refine: Review your Object diagram to ensure it accurately represents the system's structure and relationships. Refine the diagram as needed based on feedback and requirements. Use Tools for Digital Drawing: While you can draw class diagrams on paper, using digital tools can provide more flexibility and ease of modification. UML modeling tools, drawing software, or even specialized diagramming tools can be helpful.

30. COMPONENT DIAGRAM

31. Component Diagram One kind of structural diagram in the Unified Modeling Language (UML) that shows how the components of a system are arranged and relate to one another is termed a component-based diagram, or simply a component diagram. System components are modular units that offer a set of interfaces and encapsulate implementation. These diagrams illustrate how components are wired together to form larger systems, detailing their dependencies and interactions. Component-Based Diagrams are widely used in system design to promote modularity, enhance understanding of system architecture.

32. Component Represent modular parts of the system that encapsulate functionalities. Components can be software classes, collections of classes, or subsystems. Symbol:  Rectangles with the component stereotype («component»). Function:  Define and encapsulate functionality, ensuring modularity and reusability.

33. Interfaces Specify a set of operations that a component offers or requires, serving as a contract between the component and its environment. Symbol:  Circles (lollipops) for provided interfaces and half-circles (sockets) for required interfaces. Function:  Define how components communicate with each other, ensuring that components can be developed and maintained independently.

34. Relationships Depict the connections and dependencies between components and interfaces. Symbol:  Lines and arrows. Dependency (dashed arrow):  Indicates that one component relies on another. Association (solid line):  Shows a more permanent relationship between components. Assembly connector:  Connects a required interface of one component to a provided interface of another. Function:  Visualize how components interact and depend on each other, highlighting communication paths and potential points of failure.

35. Ports Role:  Represent specific interaction points on the boundary of a component where interfaces are provided or required. Symbol:  Small squares on the component boundary. Function:  Allow for more precise specification of interaction points, facilitating detailed design and implementation.

36. Artifacts Represent physical files or data that are deployed on nodes. Symbol:  Rectangles with the artifact stereotype («artifact»). Function:  Show how software artifacts, like executables or data files, relate to the components.

37. Nodes Represent physical or virtual execution environments where components are deployed. Symbol:  3D boxes. Function:  Provide context for deployment, showing where components reside and execute within the system’s infrastructure.

38. Steps to Create Component-Based Diagrams Step 1:   Identify the System Scope and Requirements: Understand the system:  Get as much information as you can on the requirements, limitations, and functionality of the system. Define the boundaries:  Determine what parts of the system will be included in the diagram. Step 2:   Identify and Define Components: List components:  Identify all the major components that make up the system. Detail functionality:  Define the responsibilities and functionalities of each component. Encapsulation:  Ensure each component encapsulates a specific set of functionalities. Step 3:   Identify Provided and Required Interfaces: Provided Interfaces:  Determine what services or functionalities each component provides to other components. Required Interfaces:  Identify what services or functionalities each component requires from other components. Define Interfaces:  Clearly define the operations included in each interface.

39. Step 4:   Identify Relationships and Dependencies: Determine connections:  Identify how components are connected and interact with each other. Specify dependencies:  Outline the dependencies between components, including which components rely on others to function. Step 5: Identify Artifacts: List artifacts:  Identify the physical pieces of information (files, documents, executables) associated with each component. Map artifacts:  Determine how these artifacts are deployed and used by the components. Step 6: Identify Nodes: Execution environments:  Identify the physical or virtual nodes where components will be deployed. Define nodes:  Detail the hardware or infrastructure specifications for each node.

40. Step 7: Draw the Diagram: Use a UML tool:  Make use of any UML software, such as Lucidchart, Microsoft Visio, or another UML diagramming tool. Draw components:  Represent each component as a rectangle with the «component» stereotype. Draw interfaces:  Use lollipop symbols for provided interfaces and socket symbols for required interfaces. Connect components:  Use assembly connectors to link provided interfaces to required interfaces. Add artifacts:  Represent artifacts as rectangles with the «artifact» stereotype and associate them with the appropriate components. Draw nodes:  Represent nodes as 3D boxes and place the components and artifacts within these nodes to show deployment. Step 8: Review and Refine the Diagram: Validate accuracy:  Ensure all components, interfaces, and relationships are accurately represented. Seek feedback:  Review the diagram with stakeholders or team members to ensure it meets the system requirements. Refine as needed:  Make necessary adjustments based on feedback to improve clarity and accuracy.