This section describes the basic principles of UML, including the nature of UML modeling and the target and all of the functional areas covered by UML.
Chapter 1 UML Summary
This chapter is a quick browsing of UML and its application. 1.1 UML Introduction Unified Modeling Language (UML) is a universal visual modeling language for description, visualization, construction, and documentation of software system products. It records the decisions and understandings of systems that must be constructed, which can be used to understand, design, browse, configuration, maintenance, and information control of the system. UML is suitable for a variety of software development methods, various stages of the software lifecycle, various application areas, and various development tools, UML is a standard modeling method that summarizes past modeling techniques and absorbs the standard modeling methods of today's excellent results. UML includes the semantics, representation, and description of the concept, providing a model of static, dynamic, system environment, and organizational structure. It can be supported by visual modeling tools that provide code generators and report generators. The UML standard does not define a standard development process, but it applies to iterative development processes. It is designed to support most existing object-oriented development processes. UML describes a systematic static structure and dynamic behavior. UML describes the system as some discrete interactions and ultimately provides a certain function of the external user. The static structure defines the properties and operations of important objects in the system and the interrelationships between these objects. Dynamic behavior defines the timing of objects and objects that communicate with each other with each other. The model established from the system from different but interconnected perspectives can be used for different purposes. UML also includes structural components that can decompose models into packages to facilitate the software team to decompose large systems into block structures that are easy to process, and understand and control the dependencies between each package, manage model cells in complex development environments . It also includes components for displaying system implementation and organization running. UML is not a programming language. However, you can use the Code Builder Tool to convert the UML model to a variety of programming language code, or use the reverse generator tool to convert the program source code to UML. UML is not a highly formal language that can be used for theorem prove, which has many languages, but they are very versatile, not easy to understand and use. UML is a universal modeling language. For some specializes, such as user graphical interface (GUI) design, large scale integrated circuit (VLSI) design, rule-based artificial intelligence, use specialized language and tools may be more suitable. UML is a discrete modeling language that is not suitable for continuous system modeling such as engineering and physics. It is a comprehensive generic modeling language that is suitable for modeling such as discrete systems composed of computer software, firmware or digital logic. 1.2 UML History UML is developed to simplify and enhance the purpose of existing large number of object-oriented development methods. 1.2.1 Object-Oriented Development Methods The software development method of traditional programming language (such as Cobol and Fortran languages) has emerged in the 1970s, in the 1980s, most important is structured analysis and structured design. Method [YourDon-79] and its variation, such as real-time structured design methods [WARD-85], etc. These methods were initially invented and promoted by Constantine, Demarco, Mellor, Ward, Yourdon, and some of the large systems, especially in systems, including the government signed by the government, and hosted in these systems. Project government officials emphasize the intensity and sufficient development of organizational and development design documents. The result is not always like expected. It is very effective. Commercial applications are more reluctant to use large CASE systems and development methods. Most commercial enterprises have independently develop software within the company, and there is no opposition between customers and contractors, and this relationship is the characteristics of large government projects. It is generally considered that the commercial system is relatively simple, regardless of whether this view is correct, it does not need to pass the inspection of the outside world. It is widely believed that the birth of the Simula-67 of 1967 is the first object-oriented language.
Although this language has a great impact on many object-oriented language designs, it has no subsequent versions. In the early 1980s, SmallTalk, the extensive use of "object-oriented movement", which is born, and the object-oriented C, C , Eiffel and Clos are born. At first, although there is a certain limitations in actual use, it still attracts extensive attention. After about 5 years in the SmallTalk language, the first batch of books that introduce object-oriented software development methods appeared. Including SHLAER / MELLOR [SHLAER-88] and COAD / YOURDON [COAD-91], followed by Booch [Booch-91], Rumbaugh / Blaha / Premerlani / Eddy / Lorensen [Rumbaugh-91] and Wirfs-BROCK / Wilkerson / wiener [wirffs-brock-90] (Note: The book copyright year often includes books published after the previous year). These works plus Goldberg / Robson [Goldberg-83] Cox [COX-86] and Meyer [Meyer-88] and other related program language design, which created the first river for object-oriented methods. The first phase was completed at the end of 1990. Getting later [Jacobson-92], it is based on the previous results, introduces a slightly different way, namely the use case and the development process. In the next five years, a large number of books on object-oriented methods have been admitted, each has its own concept, definition, representation, terminology, and applicable development process. Some books put forward some new concepts, but in general, the concepts used by each author are similar. Many subsequent books are moved in front of them, and they do some small expansion or modifications. The earliest copyman is not idle. Most of them have updated their previous works and adopted some other people's good ideas. In short, there have been some widely used core concepts, and there is a large number of people who are adopted by individual people. Even in the widely accepted core concept, there are some small differences in each object-oriented method. Subtle between these object-oriented methods often make people feel that these concepts are not known to be good, especially non-professional readers. 1.2.2 Unified Working Before UML, there have been some initial attempts to unify the concepts used in various methods. It is Coleman and his colleagues [Coleman-94] to OMT [Rumbaugh-91] , Booch [Booch-91], CRC [Wirfs-BROCK-90] method is combined. Since this work does not have these methods for these methods, it is actually only a new method, and various methods are not replaced. Attempts to successfully merge and replace existing methods begin in 1994 in Rumbaugh and Booch in Rational Software in 1994. They began to merge the concepts used in OMT and BOOCH methods, which made the first suggestion in 1995. At this point, Jacobson also joined Rational's start with Rumbaugh and Booch. They are working together to design unified modeling languages. The founders of the three best-oriented objective methods work together to inject power into this work, breaking the original balance in the field of object-oriented software development. Prior to this, the advocator of various methods felt that there is no need to give up the idea of accepting this unified S. In 1996, OMG released a message to the outside world about object-oriented modeling standard methods. The three founders of UML began to develop a software engineering approach from other companies and developers to develop a way to interested OMG, and designed a software development tool provider, software development methodologist and developer. Modeling languages accepted by these end users. At the same time, some other people are also doing this competitive job. In September 1997, all recommendations were finally submitted into an OMG in a set of UML methods. The final result is the result of many people working together.
We launched the work of creating UMLs and put forward some beneficial recommendations, but these suggested final formation is the crystallization of collective wisdom. 1.2.3 Standardization November 1997, UML was adopted by all members of the OMG and was adopted as a standard. OMG assumes that further improved UML standards. Before the UML standard passes, there have been many books published in UML essence. Many software development tool suppliers claim that their product support or plan support UML, several software engineering methodologists announce that they will use UML's representations for future research work. The emergence of UML seems to be welcomed by the computer world, as it is formed by the official experience of many experts in the official, reducing unnecessary differences between various software development tools. We want to model the standardization of the language that can promote software developers widely use object-oriented modeling techniques, and can also bring the UML support tools and training markets, because whether users or suppliers don't have to consider which one should be used Development method. 1.2.4 Core group members present the core group members of the UML recommendation or UML standard revision work: Data Acquisition Company: Tom Digredhr Technology Company: Ed Seidewitzhp: Martin Grissibm: Steve Brodsky, Steve Cook, Jos Warmer I -Lgix company: Eran Gery, David Harel ICON Computing company: Desmond D'Souza IntelliCorp and James Martin company: Conrad Bock, James Odell MCI enterprise: Cris Kobryn, Joaquin Miller ObjecTime company: John Hogg, Bran Selic Oracle company: Guus Ramackers platinum technology: Dilhar Desilva Rational software company: Grady Booch, Ed Eykholt, Ivar Jacobson, Gunnar Overgaard, Karin Palmkvist, James Rumbaugh SAP company: Oliver Wiegert SOFTEAM: Philippe Desfray Sterling software: John Cheesman, Keith Short Taskon company: Trygve Reenskaug 1.2.5 Unified meaning "Unified" The word has the following interrelated meanings in UML: * In the past, the methods and representations of the conventional occurrence. UML merges many object-oriented methods that are generally accepted in the method, gives clear definitions, representations, and related terms for each concept, UML. Using UML can describe the existing models established with various methods and more better than the original method. * In terms of life during software development. UML is seamless for development requirements. Different stages of the development process can use the same set of concepts and representations, they can be mixed in the same model. At different stages of development, no need to conversion concepts and representations. This seamlessness is critical to iterative, incremental software development. * In terms of application areas. UML is suitable for modeling of various applications, including large, complex, real-time, distributed, centralized data, or computational, embedded systems. Perhaps use some special language to describe more useful in some special fields, but in most applications, UML is not not only compared to other universal languages and better. • In implementing programming languages and development platforms. UML can be applied to systems running a variety of different programming implementations and development platforms. These include programming languages, databases, 4GL, organizational documents and firmware. In various cases, the former part of the work should be the same or similar, and the work is different from a variety of development media to some extent.
* In the development of the whole process. UML is a model language that is not described for the details of the development process. Just like the general programming language can be used in many styles, UML is suitable for most existing or new development processes. Especially suitable for the iterative incremental development process we recommend. * In terms of internal concepts. During constructing the UML meta model, we specialize in revealing and expressing the inherent links between the various concepts and trying to grasp the concepts of modeling in modeling for known and unknown situations. This process will enhance the understanding of concepts and their applicability. This is not the original intention of the unified standards, but it is one of the most important results of the unified standards. 1.3 UML's target UML language has multiple targets. First, the most important goal is to make UML a universal modeling language for all modeling. It is not someone else, and it is based on the general agreement of the computer industry, that is, it includes various main methods and can be used as their modeling language. At least, we want it to replace the model established by the OMT, Booch, Objectory method, and the methods used by other people who participate in UML recommendations. Second, we hope that UML adopts the representation of Omt Booch, Objectory, and other main methods, which can be well supported as much as possible, such as packaging, block, and recording model constructive ideas. In addition, we hope that UML accurately expresses hotspot issues in current software development, such as large scale, distribution, concurrency, mode, and group development. UML does not try to be a complete development method. It does not include a step-by-step development process. We think that a good software development process is critical to successful development software, we recommend a book to readers [Jacobson-99]. UML and software development processes using UML are two things, this is very important. We hope that UML can support all, at least most software development processes. UML contains all the concepts, we believe that these concepts are necessary to support a robust architecture to solve the needs of the needed to drive. The ultimate goal of UML is to model all aspects of the system that actually need to be established simultaneously as simple as possible. UML requires sufficient expressive ability to handle all concepts that appear in modern software systems, such as concurrent and distribution, and techniques used in software engineering, such as packages and components. It must be a universal language, like any common programming language. However, this means that UML will be very large, and it is not possible to simply be simple in software systems that describe a near toy. Modern language and operating systems are more complicated than 40 years ago, because we have more and more requirements for them. UML provides a variety of models that are not capable of being able to master within one day. It is more complicated than previous modeling languages because it is more comprehensive. But you don't have to learn it completely, just like learning any programming language, operating system or complex application. 1.4 UML concept domain UML concepts and models can be divided into the following conceptual domains. 1. Static structure. Any precise model must first define the range involved, that is, the key concept of applying the application, internal characteristics, and its interrelationship. UML static components are called static views. Static views use the class constructor to express the application, each class consists of a set of discrete objects that contain information and implementation behavior. The information contained in the object is used as an attribute, and the behavior they perform is operated as an operation. Multiple classes can have some common structure by generalization. Subclasses add new structures and behaviors on the basis of inheriting the structure and behavior of their common parental class. There is also a runtime connection between the object and other objects, which is called the association between the relationship between the object and the object. Some elements are organized together by relying on relationships, including model conversion on abstraction, bundle of template parameters, granting licenses and uses another element by one element. Another type of relationship includes the combination of use cases and data streams. Static view mainly uses class diagrams. Static views can be used to generate most data structures used in the program.
Other types of elements in the UML view, such as interfaces, data types, use cases, and signals, etc., are collectively referred to as class, and their behavior is very similar to a certain limit on each type of element. 2. Dynamic behavior. There are two ways to model behavior. One is the life history of an object and the external relationship; the other is a series of related objects when they interact to implement behavior. The view of the isolated object is a state machine - the object is performed as part of the reaction based on the current state, and the action as a reaction is performed, and the view is converted from one state to another. The state machine model is described in a state diagram. The system view of the interaction object is a collaboration, a chain associated with the context and a chain between each other, and there is a message stream between the data chain objects. The viewpoint is united in one view of the data structure, the control flow, and data stream. Collaborative and mutual operation sequence diagrams and collaborative drawings are described. The guidance of all behavioral views is a set of use cases, and each use case describes a function of use case participants or external users. 3. Implementing the construction of the UML model can be used for logic analysis and physical implementation. Some components represent the implementation. The component is a physical alternative portion in the system, which is designed and implemented in a set of interfaces. It can be conveniently replaced by a component having the same specification. The node is the runtime calculation resource, and the resource defines a location. It includes components and objects. The deployment diagram describes the arrangement of resource configurations and components on a node in a actual running system and the object included in the component, and includes possible migration of content between nodes. 4. Model organizational computers can handle large monotonous models, but people don't work. For a large system, modeling information must be divided into a coherent portion so that the working group can work simultaneously on different portions. Even a small system, people's understanding also requires organizing the content of the entire model into an appropriate size package. Package is a hierarchical organization that is a UML model, which can be used for storage, access control, and managing the configuration of a reusable model cell library. The dependency between the bags is the summary of dependencies between the components of the package. The entire architecture can apply a dependency between the package. Therefore, the content of the package must meet the dependencies of the package and the relevant architectural requirements. 5. The expansion mechanism will always want to expand its function regardless of a perfect mechanism in a language. We have made UML have certain expansion capabilities, which believes that most of the basic part of the UML expansion is met without changing the language. The structure is a new model element that has the same structure as the existing model element, but adds some additional limits, with new interpretations and icons. Code generators and other tools have also changed. The marking value is a pair of arbitrary tag value strings that can be connected to any model element and represent any information, such as project management information, code generation indication information, and a value required for the constructor. Tags and values are represented by string. Constraint is the conditional language or natural language that is expressed in a specific language (such as programming language). UML provides a language that expresses constraints, named OCL. As with all other extension mechanisms, these expansion mechanisms must be carefully used because there may be some dialects that some others cannot understand. However, these mechanisms can avoid fundamental changes in the language base. 1.5 Expression and Chart Syntax This book lists many expressions and charts of the actual model, as well as the syntax and chart of the expression. In order to avoid the explanation and examples, this book adopts some agreed formats. The actual representation of the chart and text expression is typed with Helvetica font. For example, the class name of the Helvetica font that appears in the model is a legal name. The parential arc in the grammar expression is a parental arc that may appear in the actual expression, which is not part of the actual syntax. For example: ORDER.CREATE (Customer, Amount) In consecutive text, keywords and model elements are printed with Helvetica font, such as: Order or Customer.
