Introduction to C ++ Programming

UML should not be a stranger to many people. In the past one or two years, UML has been increasingly discussed. Originally, UML does not seem to have much to do with my topic (it is language-independent, or even a language-used for communication ). I am talking about it for two purposes: 1. UML is designed for Object-Oriented software development, and C ++ is such a language. 2. UML is being used more and more in design. The next lecture is about preparing to discuss the design mode. If you do not understand UML, you cannot proceed. UML (Unified Modeling Language) is a graphic Language designed to visualize, detail, construct, and document software-intensive products. UML is based on the ideas of many predecessors. It was passed by OMG in 1997 and became a standard (so in the design pattern book, if you see something different from the standard, don't be surprised, that book is 95 years old ). For more information about the history and description of UML, see the UML reference manual. UML is mainly composed of a series of views, including Static views and Use case Views Activity views. Different diagrams are naturally used differently, for developers (or my next article), more importantly, class digraphs and Interaction views in static views) in the Sequence diagram (Sequence digoal), please note the difference between view and digoal. Class Diagram Static views describe the structure of objects. The most commonly used class diagrams help us better understand the architecture of a system. Sometimes, it is also useful to describe the Object diagram of system snapshots. Here, we mainly introduce class diagrams. The following figure shows a simple class diagram: In the class diagram, classes are represented by rectangular boxes. For example, four classes are defined, namely Base, A, B, and C, the relationship between classes is represented by various lines and other symbols. In the middle, the hollow triangle table shows the inheritance relationship. In the UML terminology, this relationship is called Generalization ), therefore, the above class is represented: Class Base {...}; Class A: public Base {...}; Class B: public Base {...}; Class C: public Base {...}; Let's look at the next figure: This figure is almost no different from the previous one. The only difference is that a Member is added to the Base class, a private integer _ x (UML is called property) and a public fun () whether or not the internal details of these classes are required by the UML itself is not limited, it is entirely dependent on how you use them, the purpose of UML is to help you understand the system, so as long as you think it is clear enough, you should not be complicated. Next, let's look at the third figure: The arrow in the figure above represents a relationship, and the other side of the arrow has a diamond (hollow) representing aggregation. The meaning of aggregation indicates the has-a relationship. Its equivalent code is as follows: Class {...}; Class B {A * theA ;...}; Aggregation is A relatively loose relationship. Aggregation Class B does not need to be responsible for the aggregated Class. The figure below: The only difference between this image and the above is that the diamond is solid, which represents a more robust relationship-composition ). The link expressed by the combination is also has-a, but here, the life cycle of A is controlled by B. Generally, the equivalent code is as follows: Class {...}; Class B {A theA ;...}; That is, A will be created with the creation of B and die with the demise of B. : Here, the relationship between B and A is only A dependency, which indicates that if Class A is modified, Class B will be affected. A simple example is as follows: Class {...}; Class B {fun (A params );...}; Common relationships are the ones we use above. Through these relationships and class diagrams, we can use graphical methods to describe the design part of a system. When you are used to UML, you will find that this is much easier than telling your companion that a class is derived from a class. Sequence diagram: Another common graph in UML is the sequence diagram in the interactive view. In previous procedural languages, we usually use flowcharts to describe how a function (system) works, in an object-oriented system, this is obviously not feasible, and the sequence diagram is used to solve this problem. Assume that the following pseudo code is available: Class circle { Public: Void fillcolor () { //... }; Void draw () { Fillcolor (); }; }; Class window { Public: Void drawcircle () { _ Circle. draw (); }; Private: Circle _ circle; }; For the following calls: Window wnd; Wnd. drawcircle (); The sequence diagram is as follows: The square above the figure indicates the participating object, the vertical dotted line indicates the lifeline of the object, and the box indicates activation. The arrow indicates a call message (or a return message can be returned ), for Asynchronous Message consumption, the semi-arrow is used. draw indicates a self call) So far, the most common UML (from the developer's point of view), of course, the content of UML is far more than that. The introduction here is just a few simple summaries, in addition, the UML itself is constantly evolving. No matter how, I think the UML will go deeper into our development process, especially for the design pattern we will introduce in the next article, class diagrams are the main descriptive tools (at that time you will experience the advantages of UML descriptions ). If you read the design patterns book, you will find that there are some slight differences with what I described above. Don't be nervous. design patterns are a gof95's work, at that time, UML was not yet formed, and it was also clear that it was the OMT method (Object Modeling Technique, a Modeling technology published by Jim Rumbaugh at GE) and Booch method. If you think that UML makes you feel at a loss, you don't have to worry about it. UML itself is just an auxiliary tool. Its purpose is to help you describe the system, not to repeat your work, if your system is very simple and can be clearly stated in one sentence, do not use UML. If you only want to describe the relationship between classes rather than the class interface, it is good to describe as simple as the first figure. In short, you should not pursue details. As long as the problem can be explained, your goal will be achieved (or even you do not have to fully abide by the specifications ). Bibliography: Design Pattern-Basis for reusable Object-Oriented Software Author: Erich Gamma Translator: Ma Xiaoxing, Ma weixing, Ma weixing, Liu Jianzhong, Mechanical Industry Press 2000 Author of UML Reference Manual: James Rumbaugh Ivar jakbson Grady Booch Translator: Yao shuzhen Tang fa Gen Machinery Industry Press 2001 UML essence-Concise Guide to Standard Object Modeling Language (version 2nd) Author: Martin Fowler & Kendall Scott: Xu Jiafu Tsinghua University Press 2002 Design Patterns Explained Alan Shalloway, James R. Trott Addison-Wesley Pub 2001

Reproduced http://bbs.chinabyte.com/thread-358355-1-1.html