Unified Modeling Language (UML) Overview

Source: Internet
Author: User

The development of Object-Oriented Analysis and Design (OOA & D) methods has seen a climax from the end of 1980s to the end of 1990s. UML is the product of this climax. It not only unifies the Expression Methods of booch, Rumbaugh, and Jacob, but also makes further development on it, and finally unified it into the standard modeling language accepted by the masses.

1. emergence of standard modeling language UML
The accepted object-oriented modeling language appeared in the middle of 1970s. From 1989 to 1994, the number has increased from 10 to more than 50. Among the many modeling languages, language creators strive to promote their own products and improve them in practice. However, users of the OO method do not understand the advantages and disadvantages of different modeling languages and their differences. Therefore, it is difficult to select an appropriate modeling language based on the characteristics of the application, as a result, a "method war" broke out ". In 1990s, a number of new methods emerged, with the most striking being booch 1993, OOSE and OMT-2.
Booch was one of the earliest advocates of object-oriented methods. He proposed the concept of object-oriented software engineering. In 1991, he expanded his previous Ada-oriented work to the entire object-oriented design field. Booch 1993 is suitable for system design and construction. Rumbaugh and others proposed the object-oriented modeling technology (OMT) method, adopted the object-oriented concept, and introduced various language-independent tokens. This method uses the object model, dynamic model, function model, and case model to model the entire system, the defined concepts and symbols can be used in the entire process of analysis, design, and implementation of software development. Software developers do not have to convert concepts and symbols at different stages of the development process. OMT-2 is particularly useful for analyzing and describing data-centric information systems.
In 1994, Jacob proposed the oose method. The biggest feature of the oose method is the use-case method, and introduced the concept of external roles in the case description. The concept of use cases is an important weapon to accurately describe the requirements, but use cases run through the entire development process, including testing and verifying the system. Oose is suitable for supporting business engineering and demand analysis. In addition, the Coad/Yourdon method, also known as OOA/OOD, is one of the earliest object-oriented analysis and design methods. This method is simple, easy to learn, and suitable for beginners of object-oriented technology. However, this method is rarely used because of its limitations in processing capabilities.
To sum up, first of all, in the face of many modeling languages, users are unable to distinguish the differences between different languages, so it is difficult to find a language suitable for their application characteristics. Second, many modeling languages have their own advantages. Third, although many different modeling languages are similar, there are still some minor differences, which greatly hinders communication between users. Therefore, objectively, it is very necessary to organize a joint design team on the basis of carefully comparing the advantages and disadvantages of different modeling languages and summarizing the application practices of object-oriented technology, so as to extract the essence and discard the dregs according to the application requirements, unified Modeling Language.
In October 1994, Grady booch and Jim Rumbaugh started their work. They first unified booch9 3 and OMT-2, and released the first public version in October 1995, called the unified method um 0.8 (UN itied method ). In the autumn of 1995, Ivar Jacob son, founder of oose, joined the team. With the joint efforts of booch, Rumbaugh, and Jacob bson, two new versions, UML June 1996 and UML October, were released in 0.9 and 0.91, respectively, and rename um as UML (Unified Modeling Language ). In 1996, some organizations saw UML as their business strategy. UML developers received a positive response from the public and proposed the establishment of a UML Member Association to improve, strengthen and promote the definition of UML. The former members were Dec, HP, I-Logix, itellicorp, IBM, icon computing, MCI Systemhouse, MICR osoft, Oracle, Rational Software, Ti, and Unisys. This mechanism has played an important role in promoting the definition and release of UML 1.0 (January 1997) and UML 1.1 (November 17, 1997.
UML is a well-defined, easy-to-Express, powerful, and universally applicable modeling language. It incorporates new ideas, new methods, and new technologies in the software engineering field. Its scope is not limited to support object-oriented analysis and design, but also the entire process of software development starting from requirement analysis.
In the United States, by October 1996, UML had been widely supported by the industrial, scientific, and application sectors. More than 700 companies have expressed support for using UML as a modeling language. By the end of 1996, UML had steadily accounted for 85% of the object-oriented technology market, becoming the de facto industrial standard for visual modeling language. In November 17, 1997, OMG adopted UML 1.1 as a standard modeling language based on object-oriented technology. UML represents the development direction of object-oriented software development technology, with a huge market prospect, great economic value and National Defense value.


2. Content of the standard modeling language UML
First, UML integrates the basic concepts in booch, OMT, and OOSE methods, and these basic concepts are mostly the same as those in other object-oriented technologies, UML must be a simple and consistent modeling language that users of these and other methods are willing to use. Secondly, UML is not only a simple convergence of the above methods, however, on the basis of these methods, we have extensively solicited opinions. After several modifications, UML expands the application scope of existing methods. Third, UML is a standard modeling language, rather than the standard development process. Although the application of UML must be based on the development process of the system, different development processes must be adopted because of different organizations and application fields.
As a modeling language, the definition of UML consists of UML Semantics and UML notation.
(1) UML semantic description precise metadata model definition based on UML. The meta-model provides simple, consistent, and general definitions for all UML elements in terms of syntax and semantics, enabling developers to achieve semantic consistency, eliminate the impact of the best expressions that vary from person to person. In addition, UML also supports the extension definition of the metadata model.
(2) UML notation defines the notation of UML symbols, which provides a standard for System Modeling by developers or development tools using these graphical symbols and text syntax. These graphical symbols and texts express application-level models. In terms of semantics, they are examples of UML meta-models.
The important content of the standard modeling language UML can be defined by the following five types of diagrams (9 in total:
· The first type is the use case diagram, which describes the system functions from the user's perspective and points out the operators of each function.
· The second category is static digraphs, including class graphs, object graphs, and packet graphs. The class diagram describes the static structure of the class in the system. It defines not only the classes in the system, but also the relationships between classes, such as association, dependency, and aggregation. It also includes the internal structure of the class (attributes and operations of the class ). A class chart describes a static relationship that is valid throughout the lifecycle of the system. An object graph is an instance of a class graph. It uses almost the same ID as a class graph. Their difference is that the object graph shows multiple object instances of the class, rather than the actual class. An object graph is an instance of a class graph. Because the object has a lifecycle, the object graph can only exist in a certain period of time in the system. A package consists of packages or classes, indicating the relationship between the package and the package. A package chart is used to describe the layered structure of the system.
· The third type is the behavior diagram, which describes the dynamic model of the system and the interaction between the components. The status chart describes all possible states of the class object and the transfer conditions of the State when an event occurs. Generally, a status chart is a supplement to a class chart. In practice, you do not need to draw a state chart for all classes. You only need to draw a state chart for classes that have multiple states and their behaviors are affected by the external environment and change. The activity diagram describes the activities that meet the requirements of the use case and the constraints between the activities, which is conducive to identifying parallel activities.
· Interactive digraphs describes the interaction between objects. A sequence diagram shows the dynamic cooperative relationship between objects. It emphasizes the order in which messages are sent between objects and displays interactions between objects. A Sequence diagram describes the cooperative relationship between objects, the cooperation diagram is similar to the sequence diagram, indicating the dynamic cooperation relationship between objects. In addition to information exchange, the cooperation diagram also displays objects and their relationships. If time and order are emphasized, the sequence chart is used. If the relationship between upper and lower levels is emphasized, the cooperation chart is selected. These two types of graphs are called interaction graphs.
· The fifth type is the implementation graph (Implementation divisor ). The component diagram describes the physical structure of the Code component and its dependencies. A component may be a resource code component, a binary component, or an executable component. It contains information about logical or implementation classes. A widget graph helps you analyze and understand the degree of interaction between widgets.
The configuration diagram defines the physical architecture of the software and hardware in the system. It can display the actual computers and devices (expressed by nodes) as well as the connection relationships between them, as well as the connection type and dependency between components. Place executable parts and objects inside the node to display the correspondence between the node and the executable software unit.
From the perspective of applications, when using object-oriented technology to design a system, the first is to describe the requirements; the second is to establish a static model of the system based on the requirements to construct the system structure; the third step is to describe the behavior of the system. The models created in step 1 and Step 2 are static, including the use case diagram, class diagram (including package), object diagram, component diagram, and configuration diagram, it is a static modeling mechanism of the standard modeling language UML. The model created in step 3 can be executed, or indicates the time sequence status or Interaction relationship during execution. It consists of four diagrams, including status chart, activity chart, sequence chart, and ing. It is a dynamic modeling mechanism of the standard Modeling Language (UML. Therefore, the main content of the standard modeling language UML can also be summarized into two categories: Static Modeling Mechanism and dynamic modeling mechanism.
3. Main features of the standard modeling language UML
The main features of the standard Modeling Language (UML) are as follows:
(1) UML unifies the basic concepts in methods such as booch, OMT, and OOSE.
(2) UML also draws on the strengths of other schools in the field of object-oriented technology, including the influence of non-oo methods. UML notation considers graphical representations of various methods, removes a large number of confusing, redundant, and rarely used symbols, and adds some new symbols. Therefore, many people's ideas in the Object-Oriented field are integrated into UML. These ideas were not invented by developers of UML, but developed by developers based on the best oo methods and rich experience in computer science.
(3) some new concepts are proposed in the evolution of UML. Added a new template (stereotyp es), responsibilities, extensibility Mechanic (MS), thread (s), process (processes), distributed (distribution) to the UML standard) concurrency, patterns, collaborations, activity digraphs, and other new concepts, as well as clear areas, types, and classes) and instance, refinement, interfaces, and COM ponents.
4. application fields of the standard modeling language UML
The purpose of UML is to describe any type of system in the form of object-oriented graphs, with a wide range of application fields. The most common model is to build a software system, but it can also be used to describe systems in non-software fields, such as mechanical systems, enterprise organizations, or business processes, and information systems that process complex data, industrial systems that have real-time requirements, or industrial processes. In short, UML is a general standard modeling language that can model any system with static structures and dynamic behaviors. In addition, UML is applicable to different stages from Requirement Specification descriptions to testing after the system is completed during system development. In the demand analysis stage, use cases can be used to capture user requirements. Use Case modeling to describe the external roles interested in the system and their functional requirements for the system (Use Case. In the analysis phase, the main concepts (such as abstraction, classes, and objects) and mechanisms in the problem domain need to be identified and their relationships need to be described using UML class diagrams.
To implement use cases, classes need to collaborate, which can be described using the UML dynamic model. In the analysis phase, only the objects in the problem domain (concepts in the real world) are modeled, classes that define technical details in software systems (such as those that handle user interfaces, databases, communication, and concurrency) are not considered ). These technical details will be introduced in the design phase, so the design phase provides more detailed specifications for the construction phase. Programming (constructor) is an independent stage. Its task is to convert classes from the design stage into actual code using object-oriented programming language. When using UML to build analysis and design models, we should avoid converting models into a specific programming language. In the early stage, the model was just a tool for understanding and analyzing the system structure. It was difficult to establish a simple and correct model to consider the coding problem too early.
The UML model can also be used as a basis for testing. Systems usually need to undergo unit testing, integration testing, system testing, and acceptance testing. Different test teams use different UML diagrams as the basis for testing: class diagrams and class specification descriptions for unit testing; component diagrams and contract diagrams for integration testing; the system test uses an example diagram to verify system behavior. the acceptance test is performed by the user to verify that the results of the system test meet the requirements identified during the analysis phase.
In short, the standard Modeling Language (UML) is applicable to describing any type of system with object-oriented technology. It is also suitable for testing and maintenance at different stages of system development, from Requirement Specification Description to system completion.


Contact Us

The content source of this page is from Internet, which doesn't represent Alibaba Cloud's opinion; products and services mentioned on that page don't have any relationship with Alibaba Cloud. If the content of the page makes you feel confusing, please write us an email, we will handle the problem within 5 days after receiving your email.

If you find any instances of plagiarism from the community, please send an email to: info-contact@alibabacloud.com and provide relevant evidence. A staff member will contact you within 5 working days.

A Free Trial That Lets You Build Big!

Start building with 50+ products and up to 12 months usage for Elastic Compute Service

  • Sales Support

    1 on 1 presale consultation

  • After-Sales Support

    24/7 Technical Support 6 Free Tickets per Quarter Faster Response

  • Alibaba Cloud offers highly flexible support services tailored to meet your exact needs.