Architecture Description Languages and UML

At Canaxia and at every other company that is developing software, the question of how software architecture should be represented is a difficult one. Stakeholders of the system need targeted material that speaks to them because, above all else, stakeholders must understand the architecture in order to implement it correctly. For technical stakeholders or those who understand software development, UML is the most popular notation to describe the design of software systems. On the surface, UML appears to be well suited as a notation for describing software architectures. UML has a large set of elements that can be used to describe software designs. The Rational Unified Process (RUP) best represents the viewpoint that UML is adequate for representing software architectures.

RUP is an "architecture-centric" process that promotes the use of UML for depicting software architecture. However, academics have questioned UML as a means of depicting software architecture (Medvidovic 2002). This is mostly because early versions of UML did not contain notations for components and connectors as first-class elements. Other constructs are important when describing software architecture, such as ports or points of interaction with a component and roles or points of interaction with a connector. In UML 1.5, components are expected to be concrete, executable software that consumes a machine's resources and memory. Although some parts of software architecture are concrete components, not all architectural components are concrete software entities. They may be an entire system or a federation of systems that need to be depicted as a single component that provides a single function.

UML 2.0 moves components and connectors through the lifecycle and addresses many of these concerns.

In addition, a connector is an architectural notion that describes something that provides a conduit from one or many components to one or many components. The connector may also adapt the protocol and format of the message from one component to another. UML 1.5 does not provide a similar concept, although one could get around this by depicting a connector as a set of cooperating classes or as a component.

UML 2.0 was released in June 2003 and addresses many of these issues in the language. In UML 2.0, a component can be depicted to use an interface and provide a port. A port can be a complex port that provides and consumes multiple interfaces. Each interface can be designated with attribution that indicates the visibility of the interface, whether or not it is a service and has asynchronous capability or not. UML 2.0 is making strides toward becoming the standard notation for depicting architectures.

Using UML has the distinct advantage of being a standard notation for software design. It is desirable to use UML for describing software architecture because it is standard. To use earlier versions of UML for this purpose, readers of the UML architecture description must be willing to suspend their disbelief. For example, an architectural component could be described by a UML component in a UML diagram. Another popular approach is to use a stereotyped class. This will work as long as the reader does not take this to mean that the component is an actual software entity and that it describes a conceptual component, not a physical one.

In addition, researchers have created several architecture description languages that have a small set of core elements that allow for the first-class representation of architectural concerns. These languages focus on a precise description of software architecture. They argue that the only way to assess the completeness and correctness of the software architecture is to precisely describe the software architecture. These methods and languages suffer from the fact that there are dozens of them, and they all have the goal of precision over understandability.

The bottom line is that there is no standard notation for documenting software architecture. The key criteria when choosing a modeling language whether it is UML, an ADL, or your own notation is that it should further the understanding of the architecture by those who read it. The model should accomplish this primary goal regardless of the notation used to document it.