Rational Rose Study Notes (i) Introduction to UML

This chapter first introduces the history and present of UML, as well as the concept of object-oriented programming, and then describes how to construct an application using UML. It mainly consists of the following four parts: first, understanding the object-oriented mechanism and visual model. Second, understand the graphical labeling model. Third, understand the UML block diagram type. Four, develop software with visual model.

Introduction to an object-oriented mechanism

An object-oriented mechanism is another way of observing an application outside of structured programming. Using an object-oriented approach, the application is divided into small chunks (or objects) that are independent of each other. These objects can then be combined to build the application. You can think of it as a brick wall. The first part is to establish or Purchase basic objects (various bricks). With these bricks, you can build a brick wall. Once you have established or purchased a basic object in the computer domain, you can integrate the object to create a new application.

One of the main benefits of object-oriented mechanisms is the ability to build components at once and reuse them over and over again. Just as bricks can be repeatedly used to build walls and houses, object-oriented basic design and code can be reused for accounting systems, inventory systems, and order processing systems.

The basic principle of object-oriented mechanism: packaging, inheritance and polymorphism.

Second, what is visual modeling

A model in the software domain, similar to the blueprint that was drawn when building a house. Blueprints can complement our planning, and models can help us plan the systems we want to see. This can ensure that the system is well designed, the requirements are met, the system can be in demand change when the feet of the station.

So what is the process of modeling? When collecting system requirements, map the user's business requirements to the requirements that the development team can understand. Ultimately, you have to use these requirements to generate code. By mapping requirements into code, you can ensure that your code meets these requirements, and your code can be easily traced back to requirements. And this process becomes modeling. The modeling process is the process of tracking from business requirements, to requirements, to models, to code, and to the opposite process, without getting lost in the process.

Learn about modeling and what visual modeling is about. Visual modeling visually represents information in a model with standard graphical elements. This allows for a good purpose, namely, communication between advocates, developers, analysts, testers, managers, and other people involved in the project. With visual modeling, we can show how the system works on several levels. such as the interaction between the user and the system, the interaction between system objects, and even the interaction between systems.

With this model in place, there is also an important benefit of showing the system plan to the relevant departments.

Three graphical labeling system

The concept of visual modeling we have a basic understanding, but what kind of graphical notation do we use to represent various aspects of the system? This labeling method should be able to convey intention to all parties concerned, otherwise the powerful use of the model can not be revealed. The most commonly used methods of drawing today are booth, Object Modeling (OMT) and Unified Modeling Language UML. Rational Rose supports these three approaches, but UML is the standard used by most companies. This book uses the UML1.3 version.

Quad UML Block Diagram

UML can be used to develop several different visual block diagrams, representing different aspects of the system. Rational Rose supports the development of most of these models, including:
1 Business use case block diagram
2 Use case block diagram
3 Activity block Diagram
4 Sequence block diagram
5 Collaboration Block diagram
6 Class block Diagram
7 Statechart block Diagram
8 Component Block Diagram
9 Deployment Block Diagram
These model diagrams represent different aspects of the system. For example, the collaboration block diagram shows that the object is built to perform the interaction required for a system function. Each block diagram has a certain purpose and use of objects. The following sections describe the functions of each of these block diagrams.

(a) Business use case block diagram
The business use case block diagram represents the functionality provided by the entire organization. It is only necessary to understand that the business use Case block diagram describes what functionality is provided by the entire organization. In other words, what the company is going to do. The business usage Case block diagram is used extensively for setting up system scenarios and forming the basis for use cases during the operational modeling activity. It has nothing to do with whether the system is automated (this is different from the use Case block diagram). It represents the interaction between a user outside the company or another company (called a business role) and the company's execution process, called a business use case.
(ii) use case block diagram
The use cases block diagram shows the interaction between the usage case, which represents the system's requirements from the user's point of view, the system function, and the role that represents the person or system that provided or received the system information. In other words, these block diagrams represent the role of the mobile use case and show that the role and the city receive information from the use case. In fact, the use Case block diagram demonstrates the requirements of the system.
So what is the relationship between business use cases and use cases? We know that the business use case represents the company's execution process, but rather the case of the company's system function, which is understandable from a realistic point of view. The company's execution process may have to correspond to a number of combinations of system functions. This is also true in UML, where a business use case may take more than 30 use cases to implement its process.
Most of the information can be seen from the use case block diagram. This block diagram shows the overall function of the system. Users, project Administrators, analysts, developers, quality assurance engineers, and anyone interested in the system can browse this block diagram to understand the system's capabilities.
(iii) Activity block diagram
The activity Block diagram illustrates the functional flow in the system, which shows the business workflow in the business model, and a transaction flow in a usage case that can be displayed when the requirement is collected. It focuses on the order in which activities occur. Instead of creating an activity block diagram for each workflow, they are powerful communication tools, especially in large, complex workflows.
(d) Sequence block diagram
The sequence block diagram shows the function flow in the use case. The user can see the details of the business process from this block diagram. The analyst sees the process flow from this block diagram. Developers see the objects that need to be developed and the actions of those objects. Quality assurance engineers can develop test cases based on this process. The sequence block diagram is useful for everyone on the project.
(v) Collaboration block diagram
The collaboration block diagram shows the same information as the sequence block diagram, but the collaboration block diagram shows this information in different ways, with different effects. The sequence block diagram shows the interaction of objects and roles over time, while the collaboration block diagram shows the interaction of objects and roles without reference to time.
Quality assurance engineers and system architects use the collaboration Block diagram to show the distribution of process between objects. Assuming that the collaboration block diagram is star-shaped, and that several objects communicate with a central object, the system architect may think that the system is too dependent on the central object, and this interaction is difficult to see in the sequence block diagram.
(vi) class block diagram
The class diagram shows the interaction between classes in the system. Developers develop classes with class diagrams. Tools like Rose generate the skeleton code for the class, and then the developer fills in the details with the selected language. The analyst displays the system details in a class block diagram. The architect also displays the system design in a class block diagram.
(vii) Statechart block diagram
The Statechart block diagram provides a way to model the various states of an object. If the class block diagram focuses on static descriptive classes and their interrelationships, then the Statechart block diagram models The dynamic functions of the system. The Statechart block diagram is not created for each class, but rather for complex classes.
(eight) component block diagram
The component block diagram shows the physical view of the model, as well as the software formation and its interrelationships in the system. There are two types of components in the Block diagram: The actor and the code base.
The person compiling the system should use the component block diagram. The component block diagram shows in what order the components should be compiled and also shows which running components are created at compile time. The component block diagram shows the mapping between the class and the implementation component. These block diagrams also initiate code generation.
(ix) Deployment block diagram
The deployment block diagram shows the physical layout of the network and the location of the various components.
Five visualization modeling and software development process
The traditional flow-type development process has a long development cycle, which can not meet the needs of users and many other problems. The Rational Unified Process (rup,rational Unified processes) is an implementation method for repetitive development. Repetitive development is a sub-phase of analysis, design, development, testing, and deployment over and over again in an object-oriented process.
It is not possible to understand all the requirements early in the project. New events continue to emerge, so repeat planning is needed. In the project, we have to go through four stages: start, refinement, construction and handover. The beginning is the beginning of the project, gathering information and conducting proof-of-concept. The start stage draws the lines of the project or the decision not to do so. The refinement phase is to refine use cases and make structural decisions. Refinement includes analysis, design, coding, and test files. The construction phase is a large number of encodings. Handover is the final stage of preparation and deployment of the system to the user. The meanings of these four phases in object-oriented projects are described below.
(i) Use of rose at the start stage
The start phase is first the business model. Rose can establish a business usage case model, which includes operational use cases, business roles, and business workers. The next step is to identify roles and use cases. Rose can document these use cases and roles to create a block diagram that shows their relationships. Using the case block diagram allows the user to verify that this block diagram synthesizes the system features.
(ii) Use of rose in the refinement phase
Rational Rose can be used in several sections of the refinement phase. Because of the refinement phase to refine the system requirements, you might want to update the use case model. Rational Rose can create an activity block diagram to demonstrate the event flow. When refining the process, you can take advantage of the sequence and collaboration block diagrams, and they also help design the objects that the system asks for. Refine the design preparation to design the system so that developers can begin to develop. This can be achieved by creating a class diagram with Rose and the Statechart block diagram. Finally, the refinement phase identifies many system components. Rose can create a block diagram showing these components and their relationships.
(iii) Use of rose during the tectonic phase
As with the refinement phase, Rose creates the above block diagram during the construction phase. Rose can create components based on object design. The build Block diagram shows the compilation dependencies between components. After you select the language for each component, you can generate the framework code. Once the developer has created the code, you can synchronize the software with the model by reversing the engineering code. Rose is creating a deployment block diagram in the construction phase that describes how components are used in the deployment.
(iv) Use of rose during the handover phase
Rose is primarily used during the handover phase to update the model when the software product is finished. In particular, the component block diagram and the deployment block diagram are usually updated during the handover phase. The aim is to ensure the synchronization of the software and the model.