On the semantics of explicit dependency relations

Meta-modeling leads to components built along the own-relations (compositions) and to component-interdependencies along structural use-relations.

Component interdependencies might appear deeply nested in the component. Remember that component comes from the Latin word "componere" which means being composed. The following example shows a use-relation between A.B and X.Y.

Just looking at the components without knowing the internals we can say that there is an implicit dependency between the two components A and X.


If we could make this dependency relation explicit there would be a way to constrain the A.B-X.Y relations on higher level.


This possibility would allow you to control the component-interdependencies - even if they are nested deeply in the component structure.

Technical Architecture

You may argue that component are not complex enough to control their use-relation by an explicit dependency. But imagine a software architecture which is based on layers and packages:

All packages and subpackages are somehow related to each other. Since the above diagram shows the technical architecture of our system the artifacts placed in the packages are templates (when generating) or simply code.

Just imagine you could explicitly define the dependencies between the packages. And now imagine that every template inter-dependency (one generic class using other generic classes) is checked immediately by the actifsource real-time validator.

Providing such a system your technical architecture would be documented soundly. And moreover actifsource would ensure that your code follows perfectly along the architecture.

Business Architecture

Another very interesting application of dependency relations is found when designing the business architecture. Coping with a complex business domain the relating business objects have to be structured to keep the overview.


Grouping domain-objects in packages and defining dependencies between the packages allows you to control use-relations between components from a higher level.

Providing such a system would allow you to group domain objects together for a perfect overview. Moreover actifsource would ensure that any relationship between components follows the well defined business architecture.

Conclusion

Modeling explicit dependencies allows you to control use-relations from a higher view. This view is what we usually call the architecture overview. actifsource could not only provide sound documentation of the architecture (technical and business) but also ensure at real-time that no artifact breaks the dependency rules.

The secret to this functionality lies in typed folders as Micha described in his blog Grouping Is Domain Specific Too. In one of my next blogs I try to workout the tricky details.