Java/A Taking Components into Java

Transcription

1 Java/A Taking Components into Java Florian Hacklinger Institut für Informatik Ludwig-Maximilians-Universität München Oettingenstraße 67, München, Germany Abstract Component-based software-engineering and software architecture gain importance in software engineering. It is a well known fact that high level architectures and modular composition help constructing large-scale software systems. Today, programming languages support software architecture insufficiently. This leads to a number of problems, e.g. reduced reusability and architectural erosion. In this paper, the Java/A programming language is introduced. Java/A integrates notions like components and connectors into Java. Furthermore, Java/A provides mechanisms to verify component configurations. 1 Introduction In the last decade, the notions of component-based systems and software architecture have been established in the software engineering community. A high-level model of a software system allows software engineers or software architects to reason on the systems feasibility [6]. This helps to anticipate complications in an early phase of the development process. A vast number of languages to express architectures of software systems have been proposed and tools to analyse these architectures have been developed. Yet, there is a lack of support for software architectures in programming languages. This insufficiency leads to an architecture almost invisible once implemented using a programming language [11]. As a consequence, software maintenance can cause architectural erosion [10]. Programmers adding new functionality to a software system are in danger of altering or even damaging the underlying architecture by mistake. The entire architectural design proves to be useless if the software no longer corresponds to the architecture. The reuse of software components, another ambitious goal of software architecture, is inhibited as programming languages do not support the specification of run-time behaviour to an adequate extent. Unfortunately, it is not obvious whether two or more components are compatible with each other. Software development through the connecting of components without any knowledge of their dynamic behaviour is almost unachievable [5]. To ensure compatibility, tool support like compile-time verification of configurations is indispensable. The basic idea of Java/A is to integrate architectural concepts, such as components, ports and connectors, as fundamental parts into Java. The underlying component model is compatible to the UML 2.0 component model [14]. This compatibility and the one-to-one mapping of the aforementioned concepts allow software designers to easily implement UML 2.0 component diagrams. They can express the notions present in these diagrams using builtin language constructs of Java. Furthermore, the visibility of architectural elements in the Java/A source code prevents architectural erosion. Programmers actually see the architecture. Therefore, the chances of accidental damage to the architecture are reduced. By capturing the dynamic behaviour of components in port protocols, the reusability of components is improved. The soundness of component compositions can be checked at compile time. As a consequence, composition is type-safe. Another advantage of capturing dynamic behaviour is that replacing one single component of a configuration is facilitated. 2 The Java/A programming language 2.1 The Java/A component model The basic concepts of the Java/A component model are components, ports, connectors and configurations. The model in its essence is taken from ROOM [12]. The component model of Java/A is shown in Fig. 1. The correspondence of the Java/A component model to the UML 2.0 component model is outlined in Tab. 1. Any communication between Java/A components is performed by sending messages to ports. If a component needs to interact with its environment, it simply sends a message to a port. Of course, this message must be an element of the required interface of the respective port. The

2 1 Configuration * Connector * Component * 2 Port 0..1 Protocol required 1 1 provided CompositeComponent AtomicComponent Interface Figure 1: The Java/A component model Java/A UML 2.0 Component no analogy AtomicComponent Component (from Basic- Components) CompositeComponent Component (from PackagingComponents) Port Port (from Ports) Interface Interface (from Communications, specialised) Protocol ProtocolStateMachine (from ProtocolStatemachines) Connector Connector (from Internal- Structures) Configuration component diagram Table 1: Correspondence of the Java/A component model to UML 2.0 components port will then pass on the message to the attached connector, which itself will delegate the message to the port at its other end. Each port may contain a protocol. These protocols describe the order of messages that are allowed to be sent from and to the respective port. Any incoming and outgoing communication must conform to the protocol. Otherwise, the port will throw an error. If no protocol is specified, a standard protocol that allows all messages at any time is assumed. Protocols are realised by UML state machines. More information on protocols can be found in Sect Java/A components can be atoms or composites. A composite contains connected components, more precisely a configuration. Atomic components provide functionality by implementing it. Any functionality that composites offer is being accomplished by inner components. Composites themselves do not contain real code. Figure 2 shows a composite component. The component A contains a configuration of two components, namely B and C. The port P4 of A is linked to the port P3 of C. Any message sent to P4 will be delegated to P3. The port P4 acts as a relay. In the current version of Java/A, the ports P3 and P4 must have identical provided and required interfaces as well as a compatible protocol. A B C P1 P2 P3 P4 Figure 2: A composite component 2.2 Java/A language features Encapsulation The encapsulation of Java/A components ensures modular development, self-containedness and reusability. The encapsulation is being achieved by restricting any component communication to ports. Required interfaces of ports specify the demands that components make on their environment. Thus, reusability is being improved with the documentation of dependencies between components and their environment. Hierarchical composition The hierarchical composition mechanism of Java/A allows component designers to generate a composite by connecting existing components to a configuration. Ports of composites are linked (by the same connection mechanism used to connect external ports) to free ports of inner components. Configurations are only valid inside a composite component. As a consequence, any Java/A program is a composite with no ports. Compositional connectors Connectors in Java/A are used to link components. They provide means to overcoming syntactic differences of messages in required and provided interfaces. Connectors can map operation names and

3 permute parameter orders. This feature is helpful to compose independently developed components without having to write wrappers. An example of connectors and their compositional features is being presented in Sect Loose coupling The coupling mechanism of Java/A is based on reflection. Components do not have knowledge, neither at design time nor at runtime, about their environment. They rely on the soundness of their configuration. Methods specified in a port s required interfaces must be provided by the connected port. This loose coupling mechanism enhances reusability as it allows for a component to be designed and implemented on its own. Protocols Port protocols ensure the soundness of a configuration at compile-time. The Java/A compiler uses a model checker to verify the validity of a connection. The compiler ensures type-safety of configurations. Protocols are specified by UTE [7], a textual notation of UML state machines. Instantiable components and connectors Components and connectors in Java/A are instantiable, like classes are in Java. Several components or connectors of one type can be used in the same Java/A program. Java language features Java/A preserves all Java language features. Programmers do not need to learn a new language to use Java/A. The new features of Java/A concern only the high-level structure of a program. 2.3 Tools Currently, the Java/A language is supported by a compiler and a graphical design workbench. The compiler jaac translates Java/A components to Java source code. This Java source code can be compiled into Java byte code as it is. Furthermore, the compiler can check the soundness of configurations using a model checker on the port protocols. The Component Composition Platform (CCP) is built to be a platform that enables the software engineer to design a component-based system from scratch as well as to compose a system by simply connecting existing components. Components can be created, edited, loaded and saved to a repository. As the compiler, the CCP makes use of a model checker to validate the soundness of component connections. 2.4 Example: Bank and ATM We illustrate Java/A by means of a simple example. Figure 3 shows a (naive) structural diagram of a system consisting of a bank connected to an ATM. The ATM is used to withdraw money from an account. Therefore, it sends an account number and the PIN of the account to the bank. If the identification is successful, money can be withdrawn from the account. BankATM Bank BankToATM ATM ATMToBank Figure 3: Java/A program BankATM The components Bank and ATM are atomic components, whereas the component BankATM is a composite. The composite component BankATM has no ports. It is a complete Java/A program independent from its environment, except any used class libraries. As can be seen in Fig. 4, the Java/A implementation of the component Bank is relatively simple. simple component Bank { port BankToATM { provided { void verify(int pin, int accountnr); void withdraw(int amount, int accountnr); required { void pinok(); void pinnok(); void withdrawok(); void withdrawnok(); protocol <!!> public void withdraw(int amount, int accnr) implements BankToATM.withdraw(int, int) { Account a = getaccount(accnr); if (amount <= a.getbalance()) { a.withdraw(amount); BankToATM.withdrawOk(); else { BankToATM.withdrawNok(); Figure 4: The source code for the component Bank It is assumed that the component Bank has a collection of Account objects and an operation to retrieve one Account object through its account number. The bank has a single port BankToATM with a provided and a required

4 interface. In case of an unidirectional communication, one of these interfaces may be omitted. The protocol is disregarded here; see Sect. 2.5 for more details on protocols. If a message withdraw is sent to the port BankToATM, the port delegates the message to the respective implementation inside the component. In the example, the bank will reply with a signal withdrawok if the balance of the respective account allows for withdrawing the given amount. The ATM can now dispense the money. The response is done by invoking the operation withdrawok at the port BankToATM. As already mentioned earlier, the programmer of the component Bank can implement the component without having to know anything about the bank s environment. He can rely on the fact that any component attached to BankToATM understands the messages pinok, pinnok, withdrawok and withdrawnok. simple component ATM { port ATMToBank { provided { void pinnok(); void pinok(); void withdrawok(); void withdrawnok(); required { void verifypin(int accnr, int pin); void withdraw(int amount, int accnr); protocol <!!> Figure 5: The source code for the component ATM The implementation of the component ATM is presented in Fig. 5. The comparison of the ports BankToATM and ATMToBank shows some problems. First, there is no method verifypin in the provided interface of the port BankToATM. Nevertheless, there is a method that will do the same job with the name verify. Second, the parameter orders of these methods differ. Both have parameters for the account number and the pin but they are not at the same position in the parameter list. The implementation of the composite BankATM in Fig. 6 shows how Java/A connectors deal with these syntactical problems. 2.5 Protocols A connection of two ports is sound if every operation in the required interface of one port has a mapping to an operation of the provided interface of the other port. Additionally, the protocols of the ports have to match each other composite component BankATM { configuration { component Bank bank = new Bank(); component ATM atm = new ATM(); connector Connector cn = new Connector(); cn.connect(bank.banktoatm, atm.atmtobank) { verify(int,int) -> verifypin(int,int)[2,1]; ; Figure 6: Source code for the component BankATM such that there exists no trace of operation calls that leads to a deadlock. An operation of a required interface has a mapping to an operation in a provided interface if they have the same name and parameter list, or if the respective connector contains a mapping statement for the operation. Recall the running example from Sect. 2.4: The protocol of the port BankToATM can be formalised as a UML state machine as shown in Fig. 7(a). The state diagram describes the behaviour of the bank. Any outbound message is marked by a prefixed ˆ. In the example, the parameters are omitted. After initialising, the bank waits for the ATM to send a verify operation. This operation call can be responded to by either pinok or pinnok. If the answer is pinok, the ATM can enter the amount to be withdrawn. If the answer to withdraw is withdrawok, the transaction is complete. The bank then waits for the ATM to initiate the next transaction. We now assume, that the port ATMToBank has the protocol shown in Fig. 7(b). This protocol allows only for one withdraw operation per transaction. If the ports BankToATM and ATMToBank are connected, the resulting configuration will eventually deadlock. The first withdraw that is responded to with a withdrawnok will have the effect that the bank will stay in the state Q3 and wait for other withdraw messages, while the ATM will abort the transaction and proceed to state Q1. The model checker HUGO will detect this deadlock at compile time. The advantages of protocols being checked by a model checker at compile time are obvious. Type-safety of configurations can be ensured. The software designer benefits from increased certainty when composing components. At the very least, he can be sure that the connection is sound. Of course, the problem of semantic differences is not addressed by this approach.

5 Q1 Q4 ^withdrawok verify ^pinnok withdraw ^withdrawnok Q2 Q3 (a) The protocol of the port BankToATM Q1 withdrawok Q4 ^verify pinnok withdrawnok ^withdraw Q2 Q3 (b) The protocol of the port ATMToBank ^pinok pinok Figure 7: Protocols of the ATM-Bank example. 3 Related Work ArchJava, SOFA and Fractal ArchJava [1] is an approach similar to Java/A. ArchJava also integrates components and connectors into Java. ArchJava components have ports with required and provided interfaces. However, ports in ArchJava do not have protocols. As a result, the dynamic behaviour of ports is not captured in ArchJava. ArchJava, as well as Java/A, allows for hierarchical component composition. In Java/A, there is no possibility of communicating with components other than sending messages to its ports, whereas in ArchJava outer components can invoke methods of inner components directly, which breaks the encapsulation. SOFA [13] and Fractal [4] are both frameworks that support component-oriented programming. Fractal is an abstract framework providing a reference implementation in Java, SOFA is a concrete framework. Neither approach introduces new concepts into a programming language. Their approach is based on a set of programming techniques combined with enhancements like a component description language (in case of SOFA). SOFA supports protocols and their verification, whereas Fractal does not. SOFA protocols are described as traces. There is no tool support available to generate these traces. See Tab. 2 for a comparison of the key features of ArchJava, SOFA, Fractal and Java/A. Other component models There are various frameworks to implement components like JavaBeans, J2EE, CORBA, COM+, and others. Nevertheless, these are not sufficient to overcome the aforementioned problems. Neither in JavaBeans nor in J2EE are there required interfaces or protocols. CORBA components have provided interfaces but they lack protocols to describe dynamic behaviour. All in all, CORBA is a composition language not a programming language. COM+ components are more comparable to libraries than to components in an architectural sense [3]. Their design does not allow for the composition of software systems. Architecture description languages Within the last decade, many architecture description languages (ADL) have been designed [9]. A common feature of these languages is the focus on high level structure and behaviour of software systems. Java/A does not aim at replacing ADLs. Java/A uses ideas presented in ADLs, for example, capturing the dynamic behaviour as in Wright [2] and brings them down to the implementation level of software systems. Furthermore, by implementing the UML 2.0 component model and using UML statecharts to specify protocols, Java/A is easy to use by programmers as the UML is wide-spread among them. In some sense, Java/A and ADLs complement each other. The implementation of an ADL model using Java/A is straight-forward as most notions of ADLs are language constructs of Java/A. Additionally, ADLs and Java/A have different goals. Whereas ADLs have a strong focus on the analysis of architectures, Java/A focuses on implementing component-based systems with additional support for the architectural level of these systems. The best fitting ADL for Java/A is the UML. 4 Conclusion The Java/A language supports software engineers in implementing component-based systems. The extension of Java with concepts like components and connectors simplifies the realisation of architectural models and, at the same time, prevents architectural erosion. Java/A provides for software component reuse. Strict encapsulation, ports with required interfaces and port protocols ensure safe composition of previously developed components. The compiler jaac and the CCP are tools that prove the concept to be applicable. As the presented concepts are compatible to the UML, Java/A is easily usable for software designers and programmers with the UML being well known among them. Currently, we work on further improvements for jaac and CCP. As for the language itself, we investigate dynamic ports and dynamic reconfigurations. The ATM-Bank

6 ArchJava SOFA Fractal 2.1 Java/A 0.3 provided interfaces required interfaces ports protocols & verification strict encapsulation dynamic architectures Table 2: Comparison of ArchJava, SOFA, Fractal and Java/A example demonstrates the necessity of dynamic ports. In the real world, there are usually more than one ATM connected to a bank. Furthermore, these connections are only used from time to time. In the current version of Java/A, connections that are established when necessary and terminated after usage are not expressible. As all ATMs will be connected to ports with identical interfaces and protocols, a construct that supports port instantiation is necessary. To a certain degree, reconfiguration at run-time is established by dynamic ports. A more ambitious goal is to introduce a hot swap mechanism into Java/A. Such a mechanism would allow for updating components at run-time. Acknowledgments I would like to thank Angelika März for proof-reading and Alexander Knapp for helpful suggestions. References [1] J. Aldrich. (2004, April 27). ArchJava: Home. Retrieved from (5/2/04) [2] R. Allen, R. Douence and D. Garlan. Specifying and Analyzing Dynamic Software Architectures. Proc. Fundamental Approaches to Software Engineering 1998, [3] G. Eddon and H. Eddon. Inside COM+. Microsoft Press, [7] A. Knapp. (2004, April 24). HUGO/RT. Retrieved from (4/28/04) [8] A. Knapp, S. Merz and T. Schäfer. Model checking UML State Machines and Collaborations. Proc. Wsh. Software Model Checking. Electronic Notes in Theoretical Computer Science, 55(3), [9] N. Medvidovic and R. Taylor. A Framework for Classifying and Comparing Architecture Description Languages. Proc 6th European Software Engineering Conference, Lecture Notes in Computer Science 1301, 1997, pages [10] D. Perry and A. Wolf. Foundations for the Study of Software Architecture. ACM SIGSOFT, Software Engineering Notes, 17(4), pp , [11] B. Selic. Reflections on Software Architectures. Lecture notes, Software Architecture Summer School, Turku, Finland [12] B. Selic, G. Gullekson and P. Ward. Real Time Object Oriented Modeling. John Wiley & Sons, [13] SOFA: Software Appliances. Retrieved from (5/2/04) [14] Object Management Group.: UML 2.0 Superstructure Specification. Technical report ptc/ OMG, [4] ObjectWeb Consortium. (2004, March 29). The Fractal Project. Retrieved from (5/2/04) [5] D. Garlan, R. Allen and J. Ockerbloom. Architectural Mismatch or Why It s Hard to Build Systems Out Of Existing Parts. International Conference on Software Engineering, pp , [6] D. Garlan and M. Shaw. Software Architecture, Perspectives of an Emerging Discipline. Prentice Hall, 1996.