Introduction to PowerDesigner UML Modeling (PART II)

PowerDesigner UML Introduction (Part II)
Author: Sybase, Inc. powerdesigner product manager David Dichmann

In the BluePrint #4 (an electronic version of access to Http://www.sybase.com/blueprint for previous issues), we explored 5 UML diagrams: Use case diagrams, Sequence diagrams, activity diagrams, class diagrams, and component diagrams to help you master the requirements of your system, Design its physical structure and expected functionality, and convert it to code. We can also use another 4 UML diagrams to further refine the definitions contained in the first 5 diagrams, or to define the system from a completely different desirable angle.

These charts (object, collaboration, Statechart, and deployment diagrams), together with the previous diagram, make up all the charts in the PowerDesigner and can be used in PowerDesigner9.5.
Object Graph (Diagram):
Like the class diagram, the object graph is also a UML static structure diagram, which defines the physical elements that the system has at a given moment without considering the dynamic activity of the system. It corresponds to code one by one, but unlike class diagrams, we are now talking about specific classifiers, not classifier definitions. It may be most appropriate to describe an object graph as a class instance diagram.

The main purpose of the object graph is to analyze. There is an indeterminate constraint between classes that cannot be represented in the class diagram. We will use object graphs to record these constraints. Also, the object graph allows us to define specific "What if" scenarios when we look at the examples of examples of instances of management that illustrate the interactions between these elements.

The following applies to the beginners of OO modeling: The classifier is an abstract object structure definition. The classifier can tell us what type of data is being managed (attribute/member represents data Element) and what the classifier is capable of (the action/method represents the behavior of the object). The instance is a concrete classifier example. Suppose you define a class named Customer that has the Name property. Class Customer instance "Jane Doe" is a customer whose name is "Jane Doe". An instance usually has a richer meaning than a classifier because the classifier represents an overview of some level. Collecting several instances or examples of a classifier may help you understand its purpose and use it better.

Therefore, the object graph is the concrete form of the class diagram, representing the class instance sample, and displaying the key values and relationships. For example, the Customerbean class has the following customer instances: The customer has an ID of 52271 and the name is "John Doe". The customer instance is associated with three order instances (three orders), and the order number is 122047, 122103, and 122399, respectively.






Collaboration Diagram (collaboration Diagram):
collaboration diagrams and sequence diagrams are very similar. In fact, sequence diagrams and collaboration diagrams can be used interchangeably effectively, and can be easily converted to each other. The difference is in the way users read and understand each other. Sequence diagrams have good hierarchies and are structured around time. The collaboration diagram is mainly constructed around the object structure. You can indicate the order of messages by numbering the messages in the diagram. In this way, a timed relationship is maintained even if the structure of the graph is not based on time.

Collaboration diagrams, by means of the interaction between elements or objects in a system, represent the dynamic aspects of a system, that is, the way it behaves over time. It complements the class diagram and object graph by representing the static structure of the system, but instead of using a structure-based relationship, it passes the interaction "message" between system objects.

You can also test the static model at the conceptual level when you construct a collaboration diagram. class instances are defined in the class diagram, and the interaction between these class instances defines a specific usage scenario and the internal communication that will occur between those elements. We can also use other roles to represent external actors and internal users of the system, such as use case diagrams.

For example, we can create an order entry system for use by customers and sales reps. The customer interacts with the system by creating a new order. A conversation is made between the order object and the sales object, which is represented by a link message, in which case there are only two messages: one is the order request from the orders class and one is the order confirmation from the sales class. There is no limit on the number of messages on a link. The conversation we are discussing here starts with an order request, and then the confirmation of the order.




Applicability
Collaboration diagrams are particularly important for designers because they illustrate the role of objects. You can construct a collaboration diagram before a sequence diagram (if you plan to construct these two diagrams), but you typically construct a collaboration diagram after you complete the class diagram to illustrate the interaction between objects that are exported from the class. You can use one or more collaboration diagrams to implement a use case, or to split complex behavior into multiple logical child behaviors.
State diagram (Statechart Diagram):
A statechart diagram (also known as a state machine) describes the behavior of a particular class or component as it changes throughout its lifecycle. The figure shows what triggers a transition from one state to another, and what actions are invoked on that class to provide the behavior of that State or trigger the conversion. For example, an order is in the initial state when it is created. After the customer confirms that the order is correct, the order will enter the confirmation status. After shipment, the order needs to go from the confirmation status to the shipping status.







Therefore, whenever a class has different options available (different valid behaviors) at different stages of its lifecycle, you can use the Statechart diagram to model these rules and conditions. Each stage in the lifecycle is a state of the object, and each trigger that changes the state represents a transition from one state to another. You can convert from one state to any number of other states as needed, or you can enter a state from several other states.
Child State diagram
To keep the state diagram simple and readable, you may find that one or more of the states you define actually involve more complex behavior, so that it itself can be defined as a statechart diagram. At this point, it is better to decompose this individual state into multiple child states than to add a large number of complex details to the main diagram, and then form a secondary diagram to define the more complex internal behavior of the parent state.



Deployment diagram (Deployment Diagram):
Deployment diagrams can help us determine where all code elements are stored in servers, workstations, and databases. Some nodes need to rely on hardware or software boxes to run part of the business logic. These nodes interact to demonstrate how multiple computers and systems we have developed interact and integrate. The node contains instance of the component that will be deployed to a database, application, or WEB server.

Deployment diagrams are used to physically deploy components to the server. By defining where you want the components to run, we can quickly map, deploy, and manage the business logic or database-side server logic that is distributed between client application and application server-side components. The following is a 1:1 model of the physical architecture to manage.

For example, suppose we have decided to implement two Enterprise Java Beans and run them on the application server. The following illustration shows a single node and two components within that node (one component per EJB). We can see that Employeebean relies on Customerbean within the same application server.


Conclusion
When we complete basic UML modeling with use case diagrams, Sequence diagrams, activity diagrams, class diagrams, and component diagrams, we will need some other tools to define details about certain elements in the system. We may want to use an exact example in an object graph to represent the structure of an object, or to learn more about the behavior of classes with multiple complex states within them, with the help of State diagrams. We need to use collaboration diagrams to examine the interaction between system components from a structural perspective rather than from a time perspective. Finally, you need to use a deployment diagram to show the location of all system components in the physical hardware or servers in the running environment, so that you can learn more about how the distributed architecture is used.

UML provides us with a more practical diagram to complete the technical analysis, design, development, or deployment of business logic. Combining these 9 charts with traditional data modeling methods and new business process modeling methodologies, we can fully understand all the factors driving software development from high-level requirements to technology and data requirements, and to various aspects of physical implementation.