OOP and UML
Wen / Alex Marbus
One. Introduction
● Introduction
The purpose of this article is to provide you with information about UML and how to use it.
● What is UML?
UML, Unified Modeling Language, is a standard symbol for object models that is suitable for real-world, is considered to be the first step in the development of object-oriented programming. It describes a unified language for artificial items for designation, naked eye observation, constructing, and recording software systems.
● Why do you make a model?
Develop a model for a software system before you really start designing software, can be seen as your engineering design a blueprint. This is basic job, although this does not mean that you have to draw a model every time, or introduce a simple class in your software.
two. Some symbol rules
● Graphics and their content
Most UML charts are graphics that contain through path contacts. It is mostly the type of information, not the position of the size or symbol. Here are the types of three visible important methods:
1. Connection (usually line)
2. Cylinder (2D shape along the boundary)
3. Visible attachment (an object is another object)
UML symbols are often drawn on a 2D plane. There are four basic graphics structures in the UML symbol:
1. Icon - Icon is a graphical profile of a fixed size and shape. It does not expand to control content. The icon may appear as a path boundary in the symbol area, or as a separate symbol that may or cannot connect to the path.
2. 2D Symbol - Two spatial symbols have variable length and width, which can be expanded to control other things, such as lists, strings, or other symbols. Most of them are divided into the same or different kinds of characters. Drag or delete a 2D symbol will affect its content and any path connected to it.
3. Path - Sequence of a line segment with an endpoint. Conceptually, the path is a separate topology entity, although it can be cleverly process graphics. Segments cannot stay away from its path. The path is always placed on both endpoints of other graphical symbols (cannot be a tang line). The path may have a boundary, which is an image that appears in some sequences of the path, which limits the connotation of the path symbol.
4. String - Everything now is in a "unresolved" table. UML assumes that each usage of the strings in the symbol has a syntax, and can be resolved into the model information below through this syntax string. For example, syntax is exchanged with attributes, operations, and transitions. Strings may be as separate symbol elements or symbol components, and elements in the list are attached to symbols or paths as labels, or as separate elements in the chart.
three. Relationship
● Properties and behavior
Each object has different properties. The attribute is a pair of names / values. For example, my age is 22. In the properties, the name is "age", the value is 22. Objects can also have behavior. I can stand, go, sleep, and so on.
Here are different types of relationships:
"Dependency" means that an object must know where another object is.
In a simple dependency, all we know is an object with another object. For example: If a class requires a header file that contains another class, it has established a dependency. We describe a class with a dashed arrow. If A is dependent B, then the arrow points to B.
In "United", the status of the object depends on another object.
In a joint, we can say that as part of understanding an object state, you must understand the relationship with the second object. There are many types of simulated real world relationships, like "Has (ARJEN has this bicycle)", "(Raymond is working)" and so on. In a joint, two objects must have a strong connection, but there is no one to another. Relationship is strong in terms of dependencies; a joint affects bilateral relations.
The combination of A and B is expressed by connecting two classes:
If there is no arrow on the line, the combination will help to bilateral direction. A unidirectional combination is like this:
In order to make the expression of the class chart more clear, the combination between the two objects can be specified:
"Collection" simulates the overall / part of the relationship.
Objects are often composed of another object. The car is made of a steering wheel, an engine, a conveyor belt, and the like. Each component is an object from its own point of view. A special combination of a car to its component is the "collection" we know. Put a white diamond in the joint end of the collection class, it shows the relationship of the collection. If B set A, then A is part of B, but their life is independent.
"Synthesis" simulates an object is the main part of another object.
Typically, the component portion of an object is only integrated into the entity using the entire object. For example, a person consists of many parts, including heart, lungs, etc. If you model, heart and lung life of a person, will be directly determined by the life of the synthetic. We call this particular relationship to "synthesis".
In the collection, the collection of components can be independently survive. Although my car consists of its wheel, tires and radios, they can continue to exist before my car is produced. In the synthesis, the life of the object being included is closely related to the life of the object containing these objects.
Synthesis can be represented by a black diamonds in the end of the combined end of the synthesis class. If b is composed of A, then B control A life.
four. Inherit
● inheritance
"Inherit" is a special / general relationship in the object. We (human) inherit the ability to distinguish the behavior and characteristics of things in our environment. This is the most expressive example: if something breathes and moves, we say it is an animal. If a thing exercise, breathing, there is also a living, and care about them, we say it is a mammal. We know that mammals are one of animals, so we can predict that if we see a animal, it will breathe and move around.
If a mammal roaring shakes, we say it is a dog. Some mammals are dogs, some are horses. Every type of animal has a determined feature, which helps us identify them, predict their behavior and characteristics.
This only has a suitable way to describe:
Once we have this classification, we can see that the familiar reading animal level exposes "generalization" of a common feature.
In the same way, we can create a car model. To do these things, we must ask yourself some questions:
What is the car? What makes the car different from the truck, different from one person, different from a rock? One of the fun of object-oriented programming is that these things are related to us. Understand how do we know and consider the object in the real world and how to establish these objects directly in the model.
In one view, the car is the sum of components part: steering wheel, brake, seat, headlight. Here, we think about the collection. In still another point of view, it is really equivalent, the car is one of the vehicles.
Because the car is a vehicle, it moves and transports the goods. That is the basic thing of the vehicle. The car inherits the feature "moving" and "transport goods" from their parent class "vehicles".
We also know that the car is used for vehicles. They are a special category of the vehicle, and also meet the joint specifications of the car. We can use inheritance to simulate this relationship. We said that the automotive type is open from the vehicle; a car is a vehicle.
Public inheritance established a "one" relationship. It has established a parent class (vehicle) and a subclass (car), which suggests that the car is a typical vehicle specialization. All real things about the vehicle should also be true to cars, but the opposite things will not be true. The car may be used for its "how" exercise, but it should exercise.
What is the motor vehicle? This is a different specialization from an abstract level. Motor vehicles are engine-driven vehicles. A car is a type, and a truck is another type. We'd better use inheritance to simulate this complex relationship.
Which model is better depends on what model you build. How do you decide which model you should use? Ask yourself! Do you have something that I want to model the "motor vehicle"? Do I have another model that is non-exciting vehicle? If you want, you should use another model. You can use an example: What will you want to build two classes for the vehicle of Marah?
● Public inheritance
A critical aspect of "public inheritance" is that it is to simulate specialization / generalization, and there is no other. If you want to inherit, but don't identify a relationship, you should use "private inheritance".
Private inheritance establishes a relationship of "executive implementation" than "Is a" relationship.
● Multiple inheritance
One of the useful performance in C is "multiple inheritance". Multiple inheritance allows a class from more than one base class to introduce two or more members and methods of classes.
In a simple multiple inheritance, both base classes are independent. Here is an example of multiple inheritance. Note how functions in this model are displayed.
In this fairly simple model, the GriffIn class inherits from Lion and Eagle. This means griffin can be eatmeat (), ROAR (), Squawk (), and fly (). When Lion and Eagle share a common base class, the problem is generated, such as Animal.
This common base class Animal can have Griffin now inherited a method of twice a member variable. When you call Griffin's Sleep () method, the compiler will not know which SLEEP () you want to call. As a Griffin class, you must understand their relationship and ready to solve the unclear when they created. C makes this problem easier to solve by providing "virtual inheritance".
With virtual inheritance, Griffin only inherits a copy of Animal members, which is not clearly solved. The problem is that two classes of Lion and Eagle must know that they may be involved in multiple inheritance relationships. Keyword "virtual" must be in their inheritance declaration, not in Griffin.
Fives. Collect
● Use multiple inheritance when you need a collection.
How do you know when to use multiple inheritance and when? Should a car inherit from the steering wheel, tires and doors? Should a police car be inherited from municipal property and vehicle?
The first policy is that public inheritance should always simulate specialization. This common expression is that inherits should simulate "it is a" relationship, the collection should simulate "there is a" relationship.
Is the car a steering wheel? Obviously not. You must figure out the car is the combination of steering wheel, wheel and door, but this does not simulate inheritance. A car is not the specialization of these things; it is a collection of these things. A car has a steering wheel, it has a door, it has a tire. Another good reason why not inheriting the car from the door is the fact that a car usually has a door. This is not the relationship that can be used inheritance.
Is a police car a vehicle and municipal property? Obviously it is. In fact, it belongs to these two. Similarly, multiple inherits have produced a lot of significance:
● Base class and subclass
Subcords should know who is their base class. They depend on the base class. On the other hand, the base class should not know anything for their subclasses. Don't put the headers of the word into your base class file.
You should be very doubtful to any "overthrow" inheritance. When you ask a pointer for its "Real" (Run Time) class, you will be frustrated and then calculate the pointer to the child type. In theory, the base pointer should be multi-form, calculating the "real" type of the pointer and the call "correct" method should be left to the compiler.
Eversing Most common uses is to call a method that does not exist in the base class. You should ask your own question is why you need this to do this. If the knowledge of running time is hidden, why are you frustrating?
● Single Example Class
You should also know which subclass is always only one instance. Don't use a single instance-program only require a single instance of a class - mix, such as only one document or a database.
six. Describe a class
● Display members
Assuming that you want to create a class cfloatPoint, it has two members: x and y, the type is 'float', there is a reset two members, assigning a function of 0.00000 EMPTY ().
First, you describe the class:
Now, we make members x and y in the model:
As we see, X and Y are private (represented by lock), and type "float".
Now, we want to make function EMPTY () can be seen in the model:
● Notes
If you want to add some additional information to your class. You can easily add a note, like this:
Seven. in conclusion
● Software used
Visual Modeler
Keep in keeping these models created with Visual Modio Enterprise Edition. So you can try themselves to describe them. Here I will explain how Visual Modeler works. See Manual or MSDN Library for more information.
● This file future version
I think this article is OOP and UML a good entry. Document "Different Styles of Programming provides a good OBJect Oriented Programming guide.
There are many disclosed UMLs in this article. One of them is the so-called "use case" in the novel. This will explain it in the new document written later.
