Modeling Software Architecture

In my last blog On the semantics of explicit dependency relations I explained the concept of explicit dependency relations between domain-specific components. The big advantage shows up when modeling on an architectural level.

A complex system is divided in layers/tiers and packages to manage code artifacts. This technical architecture provides an overview on the implementation.

On the other hand we find the business architecture where packages, areas, functionality, epics, etc. are used to structure domain objects.

On the semantics of projects and packages
Both the technical and the business architecture have one thing in common: they are structured not only with packages but also with projects. Modern IDE's as Eclipse, MS Visual Studio or InteliJ's Idea animate developers to separate different concerns in different projects.

All artifacts of a software system are structured using projects and packages.

But architecture lays above projects. Architecture describes how a system is divided into projects. This fact leads to the problem, that architecture can never be described by its projects alone.

It seems that describing architecture needs kind of an Über-Project which contains the overview how projects are interrelated. This overview shows packages and their dependencies as shown in my blog before.

There has to be an overview how projects are interrelated. This overview is the most important artifact to understand the technical architecture or business architecture.

The tricky thing: The overview provides an entry point whereat the details are managed in the projects. But nevertheless this architectural project should contain all the information to get a complete overview. This includes also detail information contained in the particular projects.

Let's assume that all green packages are modeled in the architecture overview while the red packages are realized as projects.

• The architectural overview seems to define packages which contain other packages
• At a certain level the architectural overview seems to reference packages from other projects to illustrate the dependencies
  

Packages as resources
In the current version of actifsource packages are reflected as file system folders. But it seems obvious that packages are much more then folders.

• Package-structures have a project-specific meta model
  
• Packages declare dependencies to other packages (according the meta model)
  
• Package structures may be distributed over several projects (package references)
• Packages can be mapped to file system folders
  

Packages are resources that contain other resources. Modeling packages as folders is just one way. Packages might also be modeled in the architectural overview without a folder representation. And package hierarchy structures are not limited to one project but distributed over many projects.

In one of my next articles I try to examine the technicalities.