featuremodeling Architecting Systems with UML 2.0 Morgan Björkander and Cris Kobryn, Telelogic ignaling the end of the method wars, the Object Management Group (OMG) first standardized the Unified Modeling Lan- guage1 in 1997. The software industry rapidly accepted it as the S standard modeling language for specifying software and system architectures. Although UML is primarily intended for general-purpose modeling, it’s receiving extensive use in diverse specialized areas, such as business process modeling and real-time-systems modeling. Despite these successes, development tools crosoft’s .NET. The second is the common use have been slow to realize UML’s full potential. of more mature modeling languages, such as In addition, the software industry has evolved SDL (Specification and Description Language)2 considerably during the last six years, and the and ROOM (Real-Time Object-Oriented first version of UML (UML 1.x) is now dated. Modeling),3 to specify components and system Two examples illustrate the difficulty of pro- architectures for real-time applications. If you gramming in UML 1.x. The first is the main- try to model either of these demanding do- streaming of component-based development mains with UML 1.x, you will soon find that it for enterprise applications, as with the propa- does not cope well with their paradigms or gation of J2EE (Java 2 Platform, Enterprise complexity. Consequently, UML tools serving Edition), COM+ (the extension to Microsoft’s these domains have had to provide proprietary Component Object Model), and, recently, Mi- language extensions to address UML’s preci- sion and scalability limitations. During the last few years, application cre- Despite the successes of UML 1.x, modeling tools have been slow ation’s focus has shifted from code to models, and model-driven development has taken off. to realize its full potential for specifying software and system Various model transformation and code gener- architectures. UML 2.0 will make the language more current and ation techniques let you automatically generate improve its expressive power and precision. applications from models. Some tools take this 0740-7459/03/$17.00 © 2003 IEEE Published by the IEEE Computer Society IEEE SOFTWARE 57 ■ Required interfaces describe the services pE iFuelMonitor that others must provide for the class to op- erate properly in a particular environment. iFuelControl iAngle ElectricSystem This distinction supports the development of iElectricity iPower each class as a standalone entity that does not need to know anything about the entities that implement the required interfaces. UML also pS iFeedback allows you to specify provided and required Steering Class interfaces for components, but because of space iAngle Port limitations, here we focus on the use of inter- Provided interface faces with classes. iSteering Required interface A UML class might be used in many differ- ent ways, because different stakeholders re- quire different sets of services. Although im- plementing multiple interfaces on a class Figure 1. Classes might partially express these different uses, with ports and one step further, and also let you execute the developers also need to be able to group inter- interfaces. models. In this context, a modeling language faces belonging to particular stakeholders. can serve as a visual programming language, Each such group provides a different view of but with variable levels of abstraction. This ap- the class. UML 2.0 realizes this through the proach allows much earlier verification than is port construct (see Figure 1). As we will see, normally possible, because you don’t need to these ports play another important role when produce code in order to check the system’s you assemble classes. functionality. Unfortunately, UML lacks the A port connects a class’s internals to its en- precision to properly handle such models. vironment. It functions as an intentional open- Aside from UML 1.x’s inability to ade- ing in the class’s encapsulation through which quately support such technology advances, it messages are sent either into or out of the presents other significant problems for tool class, depending on the port’s provided or re- vendors and users. To address these issues, the quired interfaces. A port that has both pro- OMG process requires a major revision of the vided and required interfaces is bidirectional. language. Fortunately, the standardization process for creating UML 2.0 started more Decomposing a system than three years ago and is nearing completion. A particular influence on UML 2.0’s use of In this article, we look at some major improve- interfaces has been component-based develop- ments proposed for UML 2.0.4 The new con- ment, which aims to hierarchically decompose a cepts are not forced on users. Backward com- system into smaller and smaller parts and then patibility is a strong requirement for UML 2.0, connect (“wire”) these parts together. Of course, and you should be able to continue using the once you’ve defined a part, you can reuse it in basic language as you did before, if you desire. many other contexts. The provided interfaces let you view a class as a black-box component, Modeling structure whose implementation is known only if you For most system architectures, a fundamen- look inside it. You can also describe the order in tal necessity is specifying their structures. A which its services can be invoked by using alter- sound structure makes distributing the sys- native views (for example, using interactions or tem’s development and maintaining its integ- state machines) that don’t directly expose the in- rity easier over time. Many modern program- ternal implementation. Naturally, these choices ming languages have adopted interfaces as a affect how you describe your structures. means to describe the services available from Figure 2 defines a typical compositional specific classes. Here we distinguish between structure of an Automobile class. The dia- two kinds of interfaces for classes: gram provides a hierarchical view of the parts that make up an automobile. ■ Provided interfaces describe the services In contrast, Figure 3a shows how the auto- that a class implements. mobile’s parts are connected to each other. 58 IEEE SOFTWARE http://computer.org/software Figure 2. An Automobile Automobile class’s 0..1 compositional structure. 1 11 1 1 PowerTrain Steering ElectricSystem VehicleStructure FuelSystem 0..1 0..1 111 11 PowerSteeringPump Rack SteeringColumn Body Chassis Class Whole-part compositions Figure 3. An Automobile class’s class Automobile :PowerTrain internal structure pP (some details omitted): (a) white- iFuel box view; (b) black- iSteering :Steering iPower :FuelSystem pF2 pA box view. iPower iSteering iExhaust pS pF1 iElectricity :ElectricSystem iAngle pE (a) pA iFuel iSteering Automobile iExhaust (b) Provided Required Port Part Connector interface interface This white-box view of the class shows the mentary views let you decompose systems of Automobile class’s different parts—that is, arbitrary complexity. The class owning the Automobile’s implementation. This view of parts is usually called the container class; each the composition tree focuses on the relation- part represents the use of a class in the context ships between parts at the same level and on of the container. Another way to think of a how connectors join them. These connectors part is as a set of instances of a particular type. describe the communications paths that are This example also shows the second use of valid in this particular context. You can zoom ports: as a connection point of a class, through out of this view, which would give you the which you can connect parts. The context in black-box view of the Automobile class (see which a class is used determines how it inter- Figure 3b), or zoom into any of the parts to acts with its environment; in each such con- access its white-box view. The two comple- text it can function as a part that connects to July/August 2003 IEEE SOFTWARE 59 of the semantics of hierarchical decomposition. class CDPlayer Whenever an instance of the container class is created, the container instance also creates in- stances representing its parts. Similarly, when- iControl iInitiation ever an instance of a container class is deleted, that instance deletes its part instances. :Record [*] Acting on actions iRead One of the UML 2.0 work’s great under- takings has been to integrate activities with their related actions. (An action is a funda- mental unit of behavioral specification that :Player iSpeaker iSpeaker represents some transformation or processing. Actions tend to be general, and apply to all kinds of behavior—for instance, state ma- chines, interactions, or activities. An activity is Behavioral Provided Required Port Connector Part the basic behavioral construct used for model- port interface interface ing activity diagrams, which specify behavior using a hybrid control and dataflow model.) A Figure 4. A class’s few years ago, an initiative began to make internal structure other parts. In the previous example, the Pow- UML able to specify executable models. This with behavioral erTrain class functioned as a part in the con- initiative essentially replaced the previous ac- ports. text of an Automobile class; it would have tion model with a new one in which you could been connected differently in the context of a express actions with precise procedural se- Boat class. mantics. The overlap with activities was glar- ing, however. UML 2.0 has significantly im- Adding behavior to the mix proved this part of the language; UML actions A system does not consist of structure are now defined in as much as detail as an or- alone. In some cases, as we saw previously, a dinary programming language’s actions (or class’s behavior is delegated to its parts, but in statements).