Solution Architects need to create models of the systems they are building for a number of reasons:
- Models help to visualise the component parts, their relationships and how they will interact.
- Models help stakeholders understand how the system will work.
- Models, defined at the right level of detail, enable the implementers of the system to build the component parts in relative isolation provided the interfaces between the parts are well defined.
These models need to show different amounts of detail depending on who is looking at them and what sort of information you expect to get from them. Grady Booch says that “a good model excludes those elements that are not relevant to the given level of abstraction”. Every system can be described using different views and different models. Each model should be “a semantically closed abstraction of the system” (that is complete at what ever level it is drawn). Ideally models will be both structural, emphasizing the organization of the system, as well as behavioral, emphasizing the dynamics aspects of the system.
To support different views and allow models to be created at different levels of abstraction I use a number of different diagrams, created using the Unified Modeling Language (UML) in an appropriate modeling tool (e.g. Rational Software Architect or Sparx Enterprise Architect). Using a process of “architecture drill-down” I can get both high level views as well as detailed views that are relevant to the level of abstraction I want to see. Here are the views and UML diagrams I create.
- Enterprise View (created with a UML Package diagram). This sets the context of the whole enterprise and shows actors (users and other external systems) who interact with the enterprise.
- System View (Package diagram). This shows the context of an individual system within the enterprise and shows internal workers and other internal systems.
- Subsystem View (Package diagram). This shows the breakdown of one of the internal systems into subsystems and the dependencies between them.
- Component View (Component diagrams and Sequence diagrams). This shows the relationships between components within the subsystems, both static dependency type relationships (through the UML Component diagram) as well as interactions between components (through the UML Sequence diagram).
- Component Composition View (Composite Structure diagram). This shows the internal structure of a component and the interfaces it provides.
Note hat a good tool will link all these together and ideally allow them to be published as HTML allowing people without the tool to use them and also navigate through the different levels. Illustrative examples of the first three of the diagrams mentioned above are shown below. These give increasing levels of detail for a hypothetical hotel system. Click on the picture to get a bigger view.
In the actual tool, Sparx Enterprise Architect in this case, each of these diagrams is linked so when I click on the package of the first it opens up the second and son on. When published as HTML this “drill-down” gets maintained as hyperlinks allowing for easy navigation and review of the architecture.
2 thoughts on “Architecture Drill Down in the UML”
Agree with the flow of static models, BUT..can you really do without high-level process models ?
Without modeling the basic processes of the Enterprise (let's say the first 2 levels), you may miss a key piece of info to assess the existing system's adequacy.
A second point: NFRs have to be part of the model somehow. The how is a good question
Hi Fabio, Good to hear from you via this channel. Agree process models are needed as well but I see those as another view that can run alongside these (and be linked to them if necessary). As for NFRs (our favorite topic) I have a plan 🙂 watch this space.