لطفا منتظر باشید ...
4.5 Conclusions and Future Directions
This work was motivated by the increasing variety and complexity of interdependencies among components of large software systems. It has observed that most current programming languages and tools do not provide adequate support for identifying and representing such dependencies, while the knowledge of managing them has not yet been systematically codified.
The initial results of this research provide positive evidence for supporting the claim that software interconnection can usefully be treated as a design problem in its own right, orthogonal to the specification and implementation of the core functional pieces of an application. More specifically, software interconnection relationships and coordination protocols for managing them can be usefully represented as independent entities, separate from the interdependent components. Furthermore they can be systematically organized in a design handbook. Such a handbook can assist, or even automate, the process of integrating a set of independently developed components into a new application.
Our experience with SYNTHESIS, a prototype application development environment based on these principles has demonstrated both the feasibility and the practical usefulness of this approach. Nevertheless, we view the work reported in this chapter as only the beginning of an ongoing effort to develop better methodologies and tools for supporting component-based software development. Some tasks remain that we plan to address in the immediate future:
Classify composite dependency patterns. Our current taxonomy includes relatively low-level dependency types, such as flows and prerequisites. In a sense, our taxonomy defines a vocabulary of software interconnection relationships. A particularly promising path of research seems to be the classification of more complex dependency types as patterns of more elementary dependencies.
Develop coordination process design rules. It will be interesting to develop design rules that help automate the selection step by ranking candidate processes according to various evaluation criteria such as their response time, their reliability, and their overall fit with the rest of the application. For example, when managing a data flow dependency, one possible design heuristic would be to use direct transfer of control (e.g., remote procedure calls) when the size of the data that flows is small, and to use a separate carrier resource, such as a file, when the size of the data is large.
Develop guidelines for better reusable components. The idea of separating the design of component functionality from the design of interconnection protocols has interesting implications about the way reusable components should be designed in the future. At best, components should contain minimal assumptions about their interconnection patterns with other components embedded in them. More research is needed to translate this abstract requirement to concrete design guidelines.
