Abstract: With the proliferation of middleware technologies and component infrastructures, there is a growing need to support high-level, platform-independent ways of modeling components and component-based systems. This need is reflected in the model-driven architecture vision of the Object-Management Group (OMG). However, component modeling involves much more than merely depicting physical deployment units using the Unified Modeling Language’s (UML) component notation. On the contrary, since components are often large, highly complex subsystems of an application, they can be fully described only by using the full range of the UML’s modeling portfolio. This chapter explains how this can be done. It suggests four basic principles by which the UML should be used to document components and component-based system in a rigorous, engineering-based manner. These principles essentially clarify how the core principles of software engineering (information hiding, separation of concerns, etc.) can be applied at the model level in terms of suites of interrelated UML diagrams. Keywords: Component Modeling, UML, Uniformity, Locality, Parsimony, Encapsulation, KobrA Method
As the software industry moves toward more model-driven and reuse-oriented ways of developing software, there is a growing interest in using the UML for modeling components and component-based systems. The UML already contains a rudimentary component modeling capability, but this is rather limited and focuses exclusively on modeling components at the level of physical implementation technologies such as COM+/.NET and Java 2 Enterprise Edition/Enterprise Java Beans (J2EE/EJB). In other words, the current UML view of components (as supported in component and deployment diagrams) corresponds to the “binary module” notion of components as “physical, replaceable part[s] of a system that packages implementation” (OMG 2001).