PowerDesigner UML Modeling

Introduction
PowerDesigner supports all UML1.3 diagrams including use case diagrams, Sequence diagrams, class diagrams, activity diagrams, and component diagrams, and fully supports UML2.0. The object-oriented analysis and Design (OOAD) analysis method is improved and the integration with the development process is enhanced.

PowerDesigner can help you build traditional business and e-business systems adapted to modern IT development, using new technologies such as Java, Object-oriented languages, and XML to merge with our database technologies in physical or virtual ways. Our goal is to provide you with the ability to access information, control business processes, and to give companies a competitive advantage in any market today, based on your needs.

Our analytical methods and design techniques will be diverse, from business process modeling to UML object-oriented analysis and design, and traditional relational modeling. This article will help you learn more about UML, a powerful technology that can help your organization create efficient traditional business and e-business systems.

Object-Oriented analysis

Before you are ready to invest in systems and software for your enterprise, you must first understand the actual needs of the enterprise and how the technology deployed will help your business achieve greater success. You can use UML to analyze using use case diagrams, sequence diagrams, and activity diagrams. These charts will help you plan your system's scope, dynamic performance, and how it behaves. Regardless of the implementation details, you want to get only the performance of the system that you need to perform.

use case diagram (Diagram)

UML use case diagrams provide a way to model a system environment. It helps you determine the external and internal elements of the system/application as well as the system scope. As a graphical modeling model, it will also be helpful when you need to talk to the system requirements that you collect, and it is important for the development team to work on the finished product. The owner of the enterprise, or the first contact with the SOFTWARE product users also have a great help. A use case diagram can visually express how the system satisfies the collected business rules and specific user needs.

in theA UML use case diagram can also be used later in the project. You can assist in testing the related functionality of a project through the requirements defined in the use case diagram. Not only can you verify that system performance is error-free (no crashes or obvious illogical responses), but you can also verify that the system runtime executes the specified command as required. This allows you to test whether the system fully meets the requirements to make sure that the finished product is ready for production-that is, it fully meets the needs of the user.

Only by ensuring that reasonable and practical requirements are met can the greater success of IT projects be ensured.



sequence Diagram (the Sequence Diagram)

You can use UML sequence diagrams to refine requirements and link design elements. Sequence diagrams allow for interactive documentation between high-level and low-level objects. The interaction is displayed between the role (the same as the role in the use case diagram) and the class instance (the technical object and detail object that runs in the computer's memory).

With sequence diagrams, you can describe system behavior over time in a precise order of events (messages) in a system-specific scenario. Use sequence diagrams for use case analysis and guided design: You can decide which type of system object will be responsible for the administrative tasks defined by the use case diagram, and decide which object will manage "session" or communication within and outside the system. Because messages have been extracted from a sequence diagram, you can describe some of the key actions (methods) required for classes and interfaces (the code elements that we are finally compiling and deploying).


activity diagram (The activities Diagram)

UML activity diagrams are designed to help you understand the dynamic changes of objects in your system. Used to describe how a particular class or group of classes works together. Unlike a sequence diagram, an activity diagram is not a series of time-related traffic, but a control transfer from one task to another, specifying who (which object) is responsible for the task that occurs.

UML activity diagrams are also technical views of business processes. You can analyze business workflows or work with business process modeling to get an activity diagram.

An activity diagram can also help construct a detailed dynamic view of elements within a system (how EJBS interoperate, and so on).



Drive Design through analysis

The analysis model captures system intentions and expected behavior that are independent of implementation details, and is not related to the language used, the deployed application server, or the architecture used. However, after the design phase began, everything changed. You must go into the details of the production environment and build the software into a specific architecture. Design is the implementation of the system.

If the design is based on analysis, you can be more confident of the correctness of the system behavior that you are writing, and confirm that the results you develop will be a demand-built system. You will be highly successful-allowing users to get the systems they need. You can also reduce development time by directly leveraging the information that is analyzed without having to regenerate in the design process, thereby reducing human error because you do not have to "replicate" any work.

Through analysis, what can we get? Using a use case diagram, you can discover objects and facilitate the creation of classes and interfaces. One or more classes and interfaces can implement a role, and you can create classes and interfaces directly in the role definition. You can also link roles to existing classes and interfaces, showing how to use a single code to satisfy multiple elements that are parsed.

You can discover methods and facilitate the creation of class operations through sequence diagrams. If you need to send a message to a class, you can call the method of that class. Messages in a sequence diagram can be used to automatically create an action or link to an existing operation. You can use links to track the functionality of the method, including what is entered and what must be returned, and so on.

What the design contains

You already know what to build, and now you need to express how to build it. You need to determine where the business logic resides: It can be placed in components such as an EJB for an application server, or in a class or component that uses languages such as VB or PowerBuilder, as part of a client application, or as triggers and procedures that are placed in a relational database. You need to make choices based on requirements, including extensibility, security, performance, and accessibility.

UML class Diagrams and component diagrams are used to define detailed technical system static structures.

class Diagram (the Class Diagram)

UML class diagrams, business logic, and all supporting structures are used to define the entire code structure. Since class diagrams are used to simulate the actual code that is maintained in development, it is obvious that it is a general expression of an object language such as Java or PowerBuilder. You can also use UML class diagrams to generalize complex structures in XML to make them easier to develop and understand.

You can generate code from a UML class diagram. You can also edit the code during the development process to refine, test, and deploy the final running application. Because PowerDesigner has a 1:1 mapping function between the object language and UML class diagrams, you can also implement reverse engineering code, read the source file, and create a new class diagram. You can get a deeper understanding of your existing systems and simplify integration and maintenance work.


Component Diagram (the Component Diagram)

UML component diagrams will be used to describe the definition and relevance of advanced objects in the larger black box view. It is still a design model and is a direct generalization of the code. For example, the component identity of an EJB is directly linked to a series of classes and interfaces necessary for implementation and will generate the required code to drive the development of the final bean.



Component diagrams are easier to understand and manage than the code-tier view of a component architecture. You can also share and reuse code by writing the documentation for the component interface, and users need (or rarely) to understand the implementation details of the component to use the code in other projects and systems.

Right-click the customer entitybean_cmp and select Create/update class Diagram to generate the following class Diagram:


Cyclic iterative Engineering

The world is not static, and so is your IT project. When you understand the requirements, by analyzing the design and building some elements of the system, it is inevitable that new changes will be encountered, such as updating definitions, or some errors that need to be corrected in the existing use case diagram, the code is edited in the IDE and text editor, and the database is optimized by DBA. You must manage and master all the details that need to be changed to ensure that the system you build is aligned with your business needs.

One solution to the round-trip project is that the current code needs to be reflected in the class diagram when it is changed during development. Specific details are as follows:
1. Create class diagrams and add business logic elements to the model
2. Generate File System application code
3. Edit code in the IDE or text editor
4. Edit the design, ignoring the changes that occurred in the generated code
5. Reverse-engineer the editorial content until it is consistent with the existing class diagram
6. Synchronize the work completed in the design process with the content edited during development (merge)
7. Generate new code, which is the sum of design code and developer Change code

When you modify a class diagram to reflect new design content, you should use synchronous/merge techniques to prevent the loss of developer work, while allowing designers to accept or reject changes made during the development process. In this way, PowerDesigner enables it to fully control the architecture, which is the key to winning.

The PowerDesigner function is not limited to this. Now that the design model has been updated, you can link these changes to the analysis. It is possible that you have found new requirements in the analysis that can be reflected in the design and written in code. Using the leading Compare/merge technology in PowerDesigner (discussed in September Blueprint), you can get real round-trip synchronization in all models and phases of the development cycle.
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.


Conclusions

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 advanced requirements to technology and data requirements, and to all aspects of physical implementation