When we laugh at the UML, what should we laugh?

        To laugh UML, UML we must retrospective of the mind, so we must understand the natural barriers between the real world and the world of software. Although people have become accustomed to the software, but the software is not constructed as the manufacture of other physical tools as transparent. People who know nothing about the software, "programming" more or less contained the word "magic" ingredients.

        If you understand the internal mechanism of the software, you can more easily express the gap between software and reality - that is, describe the mismatch (mismatch) between natural language and describe the software world, the real world of machine language. Demand for the real world can not easily be expressed in machine language, which is where the gulf, or more professional to say, is the source of the complexity of the structure of the software.

        All along, the computer industry to reduce this complexity in two ways. The first method is to encapsulate machine language - by introducing a high-level language, object-oriented concepts, so that a programming language can be more directly describe the real world.

(By the way, this is why the number of (US) to learn more and watch the programming language Lisp dirty because although beautiful - a beauty of a book page to Lisp code at the bottom of the palm contains the essence of computing, but this beauty can not help Lisp better describe the real world of dirty.)

        But because of the nature of any programming language and Turing machines are equivalent, so the programming language and the closeness of the real world there is a limit. Existing programming language is still difficult to directly describe the complex reality.

        So the computer industry with a second way to bridge the gap between reality and the software, which is modeled (modelling) - by modeling the real world abstract model, the real world is more clarity and precision; programming language is no longer directly describe the real world , but it describes reality model of the world.

        "Modeling" consists of two parts: First, the behavior ( "build"), i.e., a method how to construct the model; followed by result ( "mode"), i.e., a method as a model product.

        UML model is a model for constructing software, it is the real world and the world of software effective mediator. UML models are used to describe the structure of the real world, and to ensure that the results described in software architecture and natural approximation.

        But not a UML modeling, UML does not define the real world into modeling UML model. In fact, using the UML model modeling method is called "Unified Software Development Process (Unified Software Development Process, abbreviated as UP)".

        UP's official definition of the phrase "use-case driven, architecture-centric, iterative incremental development process." UP model-agency, reduce the complexity of software development, to help people more easily convert real-world demand for software. UP UML model is just the product, but only an important part of the article. Not a proper analogy: UP is pushed internal organs Heart of UML moves.

        Unfortunately, the reality of UP are discarded, forgotten, is unknown. Thus producing a wide variety of erroneous use of UML:

        - for example, that the UML use case diagrams that use case; that it describes a circle painted villain needs. In fact, UP in the document attached to the first use of the domain model and business model describes requirements. Each use case is withdrawn from the demand, and the participants comprising, pre-conditions, post-guaranteed main event stream, the event stream extend the full text of the description. Use Case diagram is merely illustrated embodiment for retroactively indexed used.

        - for example, that contains only UML class diagram; that class diagram is a silver bullet; that is to use UML class diagrams to draw a micromanager. In fact, UP contains the complete flow diagram of the method of constructing a system class, which includes: first abstract concept of real-world relationships constructed domain model class diagram. In cases followed by mediation refinement field class diagram, with the embodiment drawn from the class comprising Analysis Identification of a new concept relationships in FIG. Analysis of the class diagram will be refined into a design class diagram in the later process, until it is used to guide the implementation.

        - For example, because all kinds of misuse, that the complexity of software development is the result of UML, UML will get rid of the thought to get rid of the complexity of software development. In fact, the natural complexity of software development. UML does not mean that people can get rid of a programming language described directly (with a certain complexity) of the final system. Instead people still will be "Hyperactivity" way to construct your own mediator.

         Here I do not intend to UP sermon. But I want to say that when we use UML as above and cause confusion, we should not laugh UML, UML should laugh at us because we are the root cause of confusion.

        When we laugh at the UML, in the end what should we laugh?

        The biggest problem is that UML or say UP: they think the model is a silver bullet to solve all problems.

        In fact, the reality modeling Mi divide software level, need to go through two steps: first, an abstract of reality, the reality transformed into a more understandable model more accurate; Step sucked Model "avatar" to the software world, that obtained model implemented in programming language. The first of these steps, the model is very important as the final product; but the second step must be implemented in software on a programming language.

        UP does not recognize this, so UP does not define the boundaries of the model used, it is not given the opportunity at the end of the process abandoned abstract model, and therefore did not focus on the realization of the programming language of the software. Instead UP requirements for continued refinement model, the model requires ever closer to the final software.

        This leads to a broader UML or modeling studies to become the ultimate ideal: generate software to run directly through the refinement of the model, or, more bluntly attempt to replace the programming language used model.

        But both intuitive feeling, or the result of years of research have shown that: when attempting to accurately describe the software world, the model is not superior than the programming language - that is, after a certain deep into the details, express the same amount of content, the same model and programming languages complex (if the former is not more complicated words).

        Therefore, all efforts to model alternative programming language appears to be doomed to fail. UML is all these futile spokesperson.

        Therefore, I think that only when we see all manner of those of the class diagram, extremely precise timing diagram, see the intricate rules of those two-way conversion model, see the "modeling language" programming language quite similar to those that we you can go to laugh at UML.

        Because it represents how many UML / UP conceit that can be achieved, but in fact, impossible to achieve position.

        Source Chain blog: http://sakinijino.com/archives/3936

Original articles published 0 · won praise 0 · Views 1157

Guess you like

Origin blog.csdn.net/wyf0903/article/details/88079527