Identify and define dependencies between partitions.
Dependencies and Associations
Dependencies describe a relationship between partitions. You can figure out where the dependencies are by evaluating the associations. One
class is associated with another class because there is some form of communication between them. Objects of one class might query the other
class for information. For example, the ShowSeat might ask the Seat for its location details to print out the Ticket.
Dependencies and Interactions:
One way to find the direction of the dependency is to look for the direction of the communication between the objects. In the sequence and
collaboration diagrams, you documented the way that objects talked to one another. View the series of image below to examine dependencies and interactions. Find the interaction diagrams where the two types of objects communicate. Find out whether the event arrows all go one direction or whether they go both directions. The direction(s) of the event arrows will tell you the direction of the dependency.
UML Dependency Associations1) See the Event Management subsystem and the Facilities Management subsystem. There are three associations between them to examine.
2) Find sequence or collaboration diagrams that show the associated objects communicating with one another. Here we have 2 sequence diagrams that contain the associated objects. For simplicity's sake I have combined them into one diagram with notes on the side.
3) Determine the direction of the communication between the two objects in question.
4) Update the package diagram to indicate the direction of the dependency.
This association is simply an object reference held within the EventFloorPlan.
The presence or absence of a link indicates the current status of the Seat
Functional Dependencies
A dependency may also exist between a function and a class or object.
For example, the object model tells you that "Shows" must be part of an Event (composition). In order to create a Show object you should invoke the "Event" object, ask it to create a new Show, and add the new Show object to its composition. The Show Management function (use case) initiates the addition, cancellation, and rescheduling of Shows. But Show Management depends on the Event object from Event Management to do the actual work.
Time dependency:
Yet another way to identify dependencies is to determine which object has to exist first. For example, in the Pricing subsystem there is no
object interaction that would tell you explicitly in which direction to draw the dependency. Both the "Show" and the "pricing plan objects" have to exist before the
Show pricing subsystem can do its job.
Time dependency
The image shows a UML package diagram with three packages, each representing a subsystem in a software design:
Show Pricing - This package is labeled with <<subsystem>> and connects to two other subsystems, Show Management and Price Planning.
Show Management - This package, also marked as <<subsystem>>, has a dependency relationship from Show Pricing shown with a dashed arrow pointing towards it.
Price Planning - This package is also marked with <<subsystem>>. It has a dependency relationship from Show Pricing, represented by another dashed arrow pointing towards it.
In this diagram:
The Show Pricing subsystem depends on both Show Management and Price Planning subsystems.
The dashed arrows indicate dependency relationships, meaning that Show Pricing relies on or interacts with Show Management and Price Planning but not necessarily the other way around.
This type of diagram helps illustrate dependencies and relationships between various subsystems in a modular design.
Partition Dependencies - Exercise
Click the Exercise link below to work on the course project.
In this exercise you will practice determining the dependencies between domain partitions.
Partition Dependencies - Exercise
