Modeling Components and Frameworks withUML or more than a decade ven- Sun Microsystem’s JavaBeans defini- dors have hyped and under tion has developed into the Enter- delivered the promises of prise JavaBeans (EJB) specification, object modeling and com- which supports both transaction and F Fponent technologies. As a persistence services for enterprise result, object modeling applications [4]. Similarly, Microsoft’s tools are in disrepute in many devel- COM definition has evolved into the As localized opment organizations, and the DCOM and COM+ specifications, semantics of the term “component- and supports the Microsoft Transac- objects evolve based” have been diluted to an extent tion Server (MTS) for enterprise reminiscent of what occurred to the applications [3]. into distributed expression “object-oriented” in the While analyzing the evolution of components, previous software generation. these technologies it is important to However, if we put aside our note that strong synergies exist developers are skepticism and evaluate recent between them. The coarse granularity asking that UML advances in these technologies, we of components in relation to classes find encouraging signs that they are promotes the modularity and reuse provide better catching up with some of their goals of object modeling. Conversely, support for hyperbole. Many object modeling the rigorous specification discipline of tools can now generate production- object modeling supports the inter- component-based quality skeleton code from structural face-based design and replaceability development models, and some of them can also aims of components. Consequently, it derive useful methods from behav- is not surprising that component using EJB and ioral models. While they still fall far Integrated Development Environ- COM+. short of the ambitious goals of full ments (IDEs) are converging with “round-trip engineering,” their visual object modeling tools, a trend improvements mark significant that is likely to continue. progress toward automating the soft- This article explores some of the Cris ware development process. synergies between object modeling kobryn Likewise, the leading component and components by examining how standards have evolved from nascent the de facto object modeling lan- definitions of simple architectures to guage standard, the Unified Model- mature specifications of complete ing Language (UML), supports the runtime environments. For example, leading enterprise component archi- COMMUNICATIONS OF THE ACM October 2000/Vol. 43, No. 10 31 tecture standards—EJB and Figure 1. Component and interface notation. COM+/MTS (or COM+ for short). It is presumed the reader is generally familiar with how Realize relationship Longhand Component UML is used to specify software notation for «interface» showing Calculate systems; the central focus here interface showing ShoppingCart attributes and operations operations +calcWeight() is UML component-modeling +calcShipping() +Weight +calcTotal() +Shipping capabilities. ... ... +orderItems ... Components in UML 1.3 +calcWeight() The current UML specification, «interface» +calcShipping() ChangeOrder ... UML 1.3, defines a component +addItem(item:OrderItem) +addItem(item:Item) +deleteItem() as follows: +deleteItem() ... +saveItem() ... component: A physical, replaceable part of a system that Component and interface notations showing details packages implementation and Calculate provides the realization of a set Shorthand ("lollipop") ChangeOrder ShoppingCart of interfaces. A component rep- notation for resents a physical piece of interface implementation of a system, Component and interface notations hiding details including software code (source, binary or executable) or equivalents such as scripts or Figure 2. Deployment diagram example. command files [9]. A computational primaryServer:appServer node, in this case «database» an application PrimaryDB: It is important to note that server primaryQuoter: «call» AccountsDB QuoteService this definition tends to be «call» restrictive and emphasizes the primaryBroker use of components for imple- :StockBroker mentation modeling (compare In a failover this with analysis and design scenario, the backupBroker modeling). This point will be «copy» «copy» «copy» becomes the primaryBroker addressed later in this article. «become» and vice versa Indicates The UML notation for com- replication «become» ponents is summarized in Fig- ure 1. In this diagram a backupServer:appServer ShoppingCart component for backupBroker :StockBroker an e-business application is «call» shown as a rectangle with two «call» «database» smaller rectangles protruding backupQuoter: backupDB: QuoteService from its side. At the top of the AccountsDB diagram the component is shown with attributes, opera- tions, and the interfaces Calcu- late and ChangeOrder, which are drawn using found in implementation model diagrams, such as longhand interface notation (rectangles that contain component diagrams and deployment diagrams. A an operations compartment). At the bottom of the component diagram shows the organization and diagram the component is shown in a more compact dependencies of components, and a deployment representation where the attributes and operations diagram shows how component and class instances are elided and the interfaces are drawn using short- are deployed on computational nodes. An example hand (“lollipop”) interface notation. of a deployment diagram that uses components is Although UML components may be shown in shown in Figure 2. any structural modeling diagram, they are typically The example shows a simple failover scenario for 32 October 2000/Vol. 43, No. 10 COMMUNICATIONS OF THE ACM Table 1. Semantic comparison of components, advanced UML modeling topic, subsystem, and classes. problematic. One of the most common problems modelers COMPONENT SUBSYSTEM CLASS encounter is the semantic overlap Is a classifier? + + + between components and related Can have operations? + + + classifiers, such as classes and sub- Can have methods? – – + systems, which are defined as fol- Can have attributes? + – + lows: Can have interfaces? + + + Can be associated? + + + class: A description of a set of Can have thread of – – + objects that share the same control? attributes, operations, methods, Can be nested? + + + relationships, and semantics. A Is a grouping construct? – + + class may use a set of interfaces Can import/access? – + – to specify collections of opera- Represents a unit in a + + – tions it provides to its environ- physical system? ment [9]. Contains implementation + – – subsystem: A grouping of model of model elements? elements that represents a behav- Can create instances? + + (optional) + ioral unit in a physical system. A Instances typically reside + – – subsystem offers interfaces and on nodes? has operations. In addition, the model elements of a subsystem an online stockbroker system, where several compo- can be partitioned into specification and realization nents deployed on an instance of the primary appli- elements [9]. cation server node (primaryServer) are replicated on the backup application server node (backupServer). The semantics of components, subsystems, and On the primaryServer the primaryBroker, an instance classes are compared in Table 1. The table shows that of the component StockBroker, calls the interfaces of all three classifiers can have operations and inter- the primaryQuoter (an instance of the QuoteService faces, may be associated with other classifiers, can be component) and the primaryDB (an instance of the nested, and may create instances. Components are AccountsDB component). Component replication similar to subsystems and differ from classes in that and migration are shown by «copy» and «become» they cannot have threads of control and they repre- dependency flows, which are part of standard UML. sent units in physical systems. Components differ from subsystems and classes because they are not a Semantic Overlap: Components, Classes, grouping construct; they alone can contain the and Subsystems implementation of model elements, and their The fact that UML is a general-purpose modeling instances typically reside on computational nodes. language is both a strength and a weakness. Although Only subsystems can import or access other model software developers find they can use UML to model elements. most software problems in a variety of ways, they are It is important to note that, while all three classi- frequently overwhelmed by their options. The prob- fiers may conform to a set of interfaces, interfaces are lem is exacerbated by the dearth of pragmatic exam- usually most closely associated with components. ples and the lack of tools that support advanced Although it is relatively common to see a class with- constructs. Many of the examples in UML modeling out an interface during analysis, and subsystems may books tend to be trivial or academic, and frequently use model elements other than interfaces for specifi- do not address the practical problems faced by devel- cation (for example, use cases and statecharts), a opers. As for modeling tools, the author knows of none component without an interface may be technically that fully implements the UML 1.1 semantics and well-formed but suspect. This reflects the longstand- notation (adopted three years ago), let alone one that ing and intimate relationship between component- completely or correctly implements the current UML based development and interface-based design. 1.3 specification (which was adopted a year