This article provides an introduction to component modeling beyond the UML notation. It describes how I typically do component modeling, combining the non-functional and functional aspects of software to be built.
Component modeling has always been pretty clear to me – from a notation standpoint. But it took some time and practice for me to to create something that was of real value to my clients as well as the development team.
As modeling notation I typically use the UML2 component modeling notation, as – for example – outlined by Scott Ambler. I believe this is where most of us meet the first hurdle. We discover that the notation itself is not enough to create meaningful component models. I typically do – and I am sure others will approach it in a different way – do three things to create models that are meaningful:
- Model technical components,
- Model functional components, and
- Combine them into one component model.
Technical components are the technical building blocks of the system you are building. Often they are referred to application framework. The technical components serve as high-level blue-print for the system to be created. It can best be imagined as a model of the technical framework classes comprising your system.
I usually do a hierarchical breakdown of components. I usually start with the layers I had envisioned.
From there, I populate the layers with the technical essential design elements and libraries.
Usually I build tiers into the component model as well. Tiers, however, have a strong relation to the physical structure of the application. Due to this, I do not add tiers to the model until I have decided how the application will be structured physically.
This, as you can imagine, is not a one time task but an iterative process, slowly closing in on the target solution. It is also not something I do by myself but in a team-effort with the help of key-developers.
The functional components serve an equally important role, but for a different purpose. As it is important to structure software from a technical perspective, it is equally important to structure software from a functional perspective. This is important to:
- Be able to create a system with well separated functional sub-systems based on business processes, and
- helps you to structure the software you are building from a business priority perspective. This is vital as it helps you with the project planning effort, i.e. creates the structure, priorities and dependencies for your project plan. This is essential, as business priorities will typically drive a project, and not the technical effort.
Also here, I usually do a hierarchical break-down starting at the highest level of business processes. I usually stop at a level that:
- has sub-systems that are of manageable size from a project management standpoint, and
- has sub-systems that make sense (i.e. are not too small and not too large) from a business process perspective.
This as well is no activity I do on my own, but an activity that very much involves project managers, client stake-holders such as business architects and/or business subject matter experts.
The combination of both
Finally, I combine both views – the technical and functional. I do this to visualize how the technical framework supports the functional design of the software created.
Let’s imagine we are asked to create software for an educational organization. In particular, software that assists with the management of classroom education. In addition, the client defines some non-functional requirements such as web-user-interface, services and application-server-based. Please excuse that I am not using UML as notation, but you will be able to get my point.
I am not able to put all thoughts and decisions encountered throughout the process into this blog, but I hope to give you an idea as to how I go about this – in a typical scenario.
Let’s imagine the business process consists of three primary processes:
- Resource Management – for the management of all required resources, such as facilities, classrooms, equipment and teachers.
- Offering Management – such as managing the actual classes offered, their prices, etc.
- Scheduling – for scheduling classes at a given point in time with particular resources assigned.
- Enrollment Management – for dealing with the enrollment process, handling enrolments, cancellations, written confirmations, etc.
Additionally, the client has sub-processes for managing the individual types of resources, such as facilities, classrooms, equipment and teachers.
In this example the client does not have any notable non-functional requirements, except for:
- The application built is strictly for internal usage, i.e. no public access
- The application built must have a web-based user interface
- The application must provide a web-service for enrolments to be able to interface with other in-house systems, such as the Internet enrollment web-site, etc.
- The application interfaces to other systems, such as a billing system, different master-data management systems, and others.
Building the Component Model
Starting with the functional component model
For me, building the functional component model is the most important part of component modeling. Because it is the basis for many important future activities. The two most important ones are:
- Project planning, and
- Scope refinement.
The client explains that the processes “offering management”, “scheduling” and “enrollment management” are self-contained processes. Based on the high-level list of use cases we developed (i.e. not too large from a management perspective) with the client, it makes sense to keep those processes as components and not to sub-divide them any further.
The client explains further, that resource management for facilities, classrooms and equipment are pretty straight forward, but that the teacher management process is more involved. In particular, as it involves managing teacher contracts, prices, availabilities, etc. Therefore we combine the management of facilities, classrooms and equipment into one resource management component, but the management of teachers into its own.
Continuing with the technical component model
After a series of iterations we have come up with a technical component model such as this. Please bear in mind that this is really only a very, very simplified version of a technical component model, but it should give you an idea of what needs to be done. Generally I go to a conceptual level almost as deep as classes, but try to stay away from implementation details. I typically also model key classes, but really only those.
Basically what we have decided to do is the following:
- Create a one-tier application that has three layers for business logic:
- Service layer, more or less a service façade, providing service components as interface for calls from the outside.
- Logic layer, containing the actual business logic and one component per service operation. Those service operations are invoked by the service layer.
- Data Access layer, containing the data access logic. The data access objects in this layer are invoked by the logic layer.
The key idea behind this is to encapsulate all business logic within those three layers, and offer a single entry point for all calls from outside layers. This will foster reuse of business logic within the application.
- The fourth layer is actually used by external systems, invokes the service layer, and can be one of the following three:
- Web Presentation Layer – This layer contains all the web user-interface code and is used by users. Important is that all business logic, except for data validation, is executed in the logic layer and not in the web presentation layer.
- Web Service Layer – This layer provides the implementation of web service contracts to users of the web services exposed. Also here, it is important that the web services themselves do not implement logic but delegate all executions to the layers behind.
- Integration Layer – This layer provides an interface for all file- and/or message-based interactions. This layer may contain logic for receiving, sending and parsing messages, but executes all business logic in the logic layers.
The data – i.e. business objects – is not shown in this model but is typically included. Generally, I model data in a separate view and indicated by associations which layer uses which kind of data objects. This is important as not all layers will use the same type of business objects. This means: the logic layers and before will use business domain objects (which may more closely resemble the business domain), but the data access layer may use business objects that more closely resemble the data model of your database.
Combining the functional and technical model
In the last step I usually combine both views – at least for a single process – into one model view, in order to show how both views work together.
This as well, is a very much simplified view, but should illustrate how I combine both views. I typically try to illustrate how function calls flow from the outside for each one of the layers which can be accessed from the outside. In this example it would be the web presentation layer, the service layer and the integration layer.
This figure shows the flow for business logic invocation via the web service layer. In this example it is simplified, but what it should show is how the technical framework (i.e. the technical components) satisfy the functional and non-functional requirements of the software created.
[Amb2009] Ambler, S. 2009, “UML 2 Component Diagrams”, Agile Modeling (AM) Home Page [online] available at http://www.agilemodeling.com/artifacts/componentDiagram.htm
Copyright © 2010 Michael Pichler