How to define the relationships between layers in a layered architecture is coming to be discussed.

Introduction: Today, Cui asked me a question. I asked me what kind of relationship exists between the package and the package. Why do I use dependency instead of dependency? I feel that dependency is used, however, I found out why I didn't need to associate myself, so I went online and found my senior blog. I just turned it over for your reference.

Body:

In the afternoon, the meeting discussed the system architecture design issues and gave rise to the thinking on the relationship between the architectures.

In fact, the main difference is the relationship and dependency in the UML relationship. There is a point of view that there is a kind of relationship between packages in the structural diagram (package relationship) called Association.

We all know that there are five relations in UML. From the UML standards supported in rationalrose2007, only dependency and generalization are supported between packages.
The Inter-package relationship is supported more frequently in impact 7.5, including package merge and package.
Import two relationships (there may be more relationships. I hope you can correct them ). In addition, the relationship between the two modeling tools are represented Based on the dotted arrow. The only difference is some text marks.

For example, in the four packet diagrams, how should we treat such a very instructive Design During architecture?

The relationship between package charts plays a role in guiding developers to make time sequence charts and interaction diagrams. So, how can we identify their relationships?

There is not much access to architecture-level things. I have always followed my own ideas and have not taken them seriously. Today, I have taken them seriously and found that the relationship between these things is somewhat unknown.

Let's take a look at the concept.

Dependency

It can be simply understood that a class A uses another class B, and this relationship is contingent, temporary, and very weak, but changes in Class B will affect a. For example, if someone wants to cross the river and borrow a ship, the relationship between people and the ship is dependent. It is manifested in the Code layer, class B is used as a parameter by Class A in a method;

Association

It represents a strong dependency between two classes or between classes and interfaces, such as my friends and I; 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 the relationship can be one-way and two-way; it is manifested in the Code layer. For associated Class B, it appears in the form of class attributes in associated Class, it may also be that associated Class A references a global variable of the associated Class B;

(Association, dependency interpretation, from: http://www.iteye.com/topic/632059
)

To better differentiate these two relationships, we can start with code implementation to make it easier to understand.

I understand that the biggest difference between dependency and association is that a scope problem, that is, Class B is used in a method in Class; class B is associated with class A in the form of class attributes (member variables. The former Acts less than the latter, so I use it as the basis for analysis. (I hope to confirm this .)

In Rose, the relationship between packages is only dependent and generalized, which is correct. There is a dependency between the UI and BLL. Basically, the corresponding BLL class will be introduced in each event Method in the instance object of each interface class in the UI, the instance becomes an object to complete the corresponding functions. If we consider system optimization and Resource Saving, we may describe the relationship between the UI Interface Class and the corresponding class in BLL, in this case, is there an association between the UI and BLL?

This is not the case. In my understanding, the relationships between the UI and BLL packages may be dependent and generalized, but based on the package layer relationship, we still need to start from the basic norms and starting points, that is, the corresponding classes in BLL should be separately introduced into the methods of UI Class Object objects. This is dependency rather than Association.

In EA, there is a package relationship between packages.
Import, that is, the reference between the package and the package (the reference between the layer and the layer is more inclined to implement some is to introduce the namespace, and then can instance this layer class, call class methods.

Looking at the relationship between packages, I prefer the expression of the relationship between packages in EA.

In addition, in rose, the design architecture diagram, the inter-package relationship is not associated with this relationship, but should be dependent or generalized (inherited ).

As follows, I agree with the expression of this relationship in EA: