Basic concepts of UML [dependency, association, generalization, implementation] and basic concepts of uml
I. concept:
Introduction to the basic concepts of UML:
UML: UML (Unified Modeling Language) provides a Unified, standard, and visual Modeling Language for Object-Oriented software design. It is applicable to the whole process of describing case-driven, architecture-centered software design.
A uml Model diagram consists of transactions, relationships, and diagrams.
1. Things: things: component things [class, interface, use case, component, node, etc.] behavior things [interaction, state machine] group things [Package] Comment things [comment]
2. Relationship: dependency, Association [aggregation, combination], generalization, and implementation
3. diagram: class diagram, use case diagram, state diagram, object diagram, sequence diagram, collaboration diagram, activity diagram, component diagram, and deployment diagram.
Ii. UML syntax description: [this figure is taken in the startUML detailed tutorial]
3. Relationships in UML: 1. generalization: A class (called subclass and subinterface) inherits the functions of another class (called parent class and parent interface, it can also add its own new function capabilities. inheritance is the most common relationship between classes or interfaces and interfaces. in Java, such relationships are identified by the keyword extends.
It is represented by an implementation with a hollow arrow. [For other link representations, see the UML syntax description]
The class diagram is described as follows:
The class inheritance code is as follows:
package dim.uml.generalization;/* * ClassA extends classB , ClassA is_a ClassB */public class ClassA extends ClassB{public ClassA() {// TODO Auto-generated constructor stub}}class ClassB{public ClassB() {// TODO Auto-generated constructor stub}}
The inheritance code of the interface is as follows: interface:
<span style="font-size:14px;">package dim.uml.generalization;public interface InterfaceA {void doSometingInA();}</span>
Interface B: inherited interface
<span style="font-size:14px;">package dim.uml.generalization;public interface InterfaceB extends InterfaceA{void doSometingInB();}</span>
Test interface: we can see that it inherits interface B and rewrites doSomethingInA and doSomethingInB.
<span style="font-size:14px;">package dim.uml.generalization;public class TestInterface implements InterfaceB{@Overridepublic void doSometingInA() {// TODO Auto-generated method stub}@Overridepublic void doSometingInB() {// TODO Auto-generated method stub}}</span>
2. Implementation: it is a class that implements interface interfaces (multiple). Implementation is the most common relationship between classes and interfaces; in Java, such a link is identified by the keyword implements.
The implementation class diagram is as follows:
Interface Definition code:
<span style="font-size:14px;">package dim.uml.realization;public interface Interface_A {void doSomething();}</span>
Class_A implementation interface Interface_A
<span style="font-size:14px;">package dim.uml.realization;public class Class_A implements Interface_A {@Overridepublic void doSomething() {// TODO Auto-generated method stub}}</span>
3. Dependency is also a connection between classes. It indicates that one class depends on the definition of another class. Dependency is always unidirectional. You can simply use another class B for one class A, and this relationship is contingent, temporary, and very weak, but changes in Class B will affect; programmers need to code and use computers. The relationship between programmers and computers is dependent, that is, Class A uses another class B, but the computer performance is too poor, will affect the programmer's work efficiency, that is, Class B changes will affect Class. As shown in the code, Class B is used as A parameter by Class A in A method.
The class diagram is as follows:
Code corresponding to the class diagram: programmer class:
<span style="font-size:14px;">package dim.uml.dependency;public class Programmer {Computer computer=null; public Programmer() { computer=new Computer(); } public void coding() { computer.runCode(computer); }}</span>
COMPUTER:
<span style="font-size:14px;">package dim.uml.dependency;public class Computer {Computer(){}public void recordCode(){System.out.println("record code now");}public void compileCode(){System.out.println("compile code now");}public void runCode(Computer com){ com.recordCode(); com.compileCode();System.out.println("run code now");}public void setHeadWare(String HeadWare){System.out.println("set the headware of computer");}}</span>
Test class:
<span style="font-size:14px;">package dim.uml.dependency;public class TestClass {/** * @param args */public static void main(String[] args) {// TODO Auto-generated method stubProgrammer pr=new Programmer();pr.coding();}}</span>
Test result: Print: record code now
Compile code now
Run code now
4. Association: indicates the connection between the class and the class, which makes one class know the attributes and methods of the other class.
You can use a single arrow to indicate one-way Association. You can use a double arrow or an arrow to indicate two-way Association. We do not recommend two-way Association. there are two endpoints associated. Each endpoint can have a base number, indicating that the associated class can have several instances.
Common bases and meanings:
0 .. 1:0 or 1 instance.
0 .. *: there is no limit on the number of instances.
1: only one instance is allowed.
1 .. *: there must be at least one instance.
It represents a strong semantic dependency between two classes or between classes and interfaces, such as human and human friends, computers and keyboards; this relationship is more dependent than the dependency relationship, with no dependency relationship. The relationship is not temporary, and is generally long-term. In addition, the relationship between the two parties is generally equal and manifested in the Code layer, for associated Class B, it appears in the form of class attributes in associated Class A, or it may be that associated Class A references A global variable of the type of associated Class B; in java, associations are implemented using instance variables.
Pictures of human beings and friends:
(1) aggregation: a special case of association, which is a strong association. aggregation is the relationship between the whole and the individual, that is, the relationship between has-a. At this time, the whole and the part can be separated and they can have their own lifecycles, some can belong to multiple overall objects, or share multiple overall objects, such as the relationship between the computer and CPU, the company and the employee, and so on. The performance is at the code level and the relationship is consistent, it can only be distinguished from the semantic level;
The aggregation relationship is also implemented using instance variables. java syntax does not allow cross-linking and aggregation.
In an association, two classes are at the same level, while in an aggregation relationship, two classes are at an unequal level. One Class indicates the whole, and the other class indicates the part. for example, the relationship between a computer and a keyboard is as follows:
Computer
package dim.uml.association;public class Computer {KeyBoard keyBoard=null;Computer(String Name){System.out.println(Name+" computer");keyBoard=new KeyBoard();}public void surfing(){keyBoard.type();System.out.println("surfing ");}}
KeyBoard class
package dim.uml.association;public class KeyBoard {public KeyBoard() {// TODO Auto-generated constructor stub}public void type(){System.out.println("typing");}}
Test class:
package dim.uml.association;public class TestAssociation {public static void main(String[] args) {Computer com=null;com=new Computer("FAKE");com.surfing();}}
(2) combination: it is also a special case of association. It represents a contains-a relationship, which is stronger than aggregation, also known as strong aggregation; it also shows the relationship between the whole and the part, but the whole and the part are inseparable at this time, and the end of the overall life cycle means that part of the life cycle ends; for example, you and your brain; the compositing relationship cannot be shared .. It is represented at the code level and is consistent with the association. It can only be distinguished at the semantic level.
The combination is almost the same as aggregation. The only difference is that "part" cannot exist independently from "whole", that is, the life cycle of "part" cannot be longer than "whole.
Composite relationship class diagram:
Semantic understanding of combination and aggregation: 1. For a desktop keyboard, it is part of a computer but can be separated. [If the laptop is a combination of semantics, the whole and part cannot be divided. You can also split the laptop and keyboard. At that time, there was a semantic relationship between Parties .]
2. Relationship between the computer and the cpu. If it is a semantic understanding of the computer assembly, it is an aggregation relationship. Different types of CPU can be used to assemble the computer. If a common user uses a computer and is powered on, the computer and CPU are in a combination. The computer and CPU cannot be separated.
However, at the code level, the aggregate and composite tables are consistent with the association, and can only be distinguished from the semantic level;
Degree of association strength: dependency <Association <aggregation <combination
References:
Detailed StartUML tutorial
UML: six relationships in UML
UML relationships (generalization, implementation, dependency, Association (aggregation, combination ))
The level is very small, there are some deficiencies, more correction, and common progress!
