This paper presents a method to develop frameworks for protocol implementation. Frameworks are software structures developed for a specific application domain, which can be reused in the implementation of various different concrete systems in this domain. The use of frameworks support a protocol implementation process connected with formal design methods and produce an implementation code easy to extend and to reuse

Barros Barbosa, C. de

Ferreira Pires, L.

English

de Barros Barbosa, Ciro

Ferreira Pires, Luis

University of Twente Research Information

Page 1 of 5Developing Frameworks for Protocol ImplementationCiro de Barros Barbosa1, Luís Ferreira PiresCentre for Telematics and Information Technology University of Twente P.O. Box 217, 7500 AE, Enschede, the Netherlands e-mail:{barbosa,pires}@cs.utwente.nlAbstract. This paper presents a method to develop frameworks for protocol implementation. Frame-works are software structures developed for a specific application domain, which can be reused in the implementation of various different concrete systems in this domain. The use of frameworks support a protocol implementation process connected with formal design methods and produce an implementation code easy to extend and to reuse.1  IntroductionThe scope of our work is the investigation of the use of frameworks for protocol implemen-taion. Frameworks are software structures developed for a specific application domain, whichcan be re-used in the implementation of various different concrete systems in this domain. Weare particularly interested in an implementation method that is connected to formal designtechniques. In this case, the application domain of our frameworks is the design model under-lying the design process; the concrete systems are the protocol implementations. A designmodel consists of the design concepts applied to model the protocol and the rules to combinesuch concepts [6]. The protocol implementation process consists of mapping the concepts of the chosen designmodel onto the concepts of an implementation model. An implementation model consists ofthe implementation building blocks available in a specific environment. In this work we usethe term meta-model to generally refer to design models and implementation models. Ideally,for a precise mapping, both meta-models should have their semantics formally defined and acouple of tools should support the mapping process. However, implementation models do nothave a formal semantics and the mapping process relies on the knowledge designers have ofthe implementation environments and their skills to combine the available building blocks.Implementations from scratch in these circumstances are not an efficient process. Implemen-tation conformance usually relies on timing consuming tests without many guarantees.The use a framework to implement a specific protocol, the final implementation will consist ofthe framework complemented with classes that define the specific functions of the protocol. Inthis respect a framework resembles a program with a ‘hole’, which has to be ‘filled in’ withspecific functions in order to be executed [7]. By using frameworks we intend to give a contribution to the implementation process, provid-ing an implementation method with a good balance between implementation process effec-tiveness, maintenability and performance. Such method also allows, to a large extend, thereuse of the implementation effort. The framework development process must be committed with the following goals, in order tothe resulting frameworks efficiently contribute to the protocol implementation process:• frameworks must have a good balance between code maintenance and performance. 1.Sponsored by CNPq - BrazilPage 2 of 5• frameworks must have a clear and intuitive documentation. • there must be a conformance between frameworks and the concepts they implement. We have defined a systematic approach to develop frameworks through which we intend toreach these goals. The analysis and design techniques used here were inspired in [2]. Themodelling techniques follow the UML standard [8]. Our approach consists of four steps:Domain analysis, Definition of the Software Architecture, Coding and Documentation. Theremaining of this paper describes in detail our method to develop frameworks. 2  Domain AnalysisIn the domain analysis step we strive for a clear definition of the design model we intend tosupport. The concepts of the design model and their relationships are analysed and presented.Such analysis is based on a basic meta-model we have identified. The analysis consists of spe-cializing the components of the basic meta-models into the specific characteristics of the par-ticular design model we intend to use.The modelling techniques we use in order to describe design concepts and their relations aredata dictionaries and class diagrams. The data dictionary consists of one paragraph for eachdesign concept, describing the semantics of this concept and its associations to other concepts.Such description is done in natural language. We use class diagrams to help describing thestatic relations between concepts. The next subsection presents our basic meta-model and dis-cuss the specialization of its elements. 2.1  A Basic Meta-ModelIn order to facilitate the analysis of design models, we provide in this sub-section a basicstructure for meta-models. The basic meta-model, as we call it, consists of the fundamentalconcepts that can be found in any meta-model. The analysis of a specific meta-model can bedone identifying how this specific meta-model defines each fundamental concept of the basicmeta-model. We have obtained the basic meta-model by analysing the communities betweenthe concepts present in some architectures for distributed systems, e.g., ISO/OSI [4] and Inter-net [5]. The same basic meta-model can be found by analysing description techniques whichwere conceived to model distributed systems [3]. The concepts identified in the basic meta-model are:• Behaviour: is an abstraction which models the functionality of the system, i.e., how the system reacts, in each stage of its execution, to stimulus from its environment or the absence of them.• Component: communication system architectures are often structured in layers. These layers may be decomposed into different functional parts. In this way we can reason about the system through smaller parts that are easier to understand than the whole. We use the concept of component to model such a system part. A component encapsulates the characteristics of the system part it models, e.g., its behaviour. • Interaction: this concept models an instance of common activity between system parts. • Interaction means: is an abstraction that represents the mechanisms through which com-ponents cooperate. The relation between interaction means and interaction is analogous to the relation between component and behaviour, i.e., it supplies a place and an identity for the interaction being performed. Page 3 of 5For each specific meta-model we specialize the concepts presented above or aggregate newconcepts to support them. Some of the basic meta-model concepts may have a few most com-mon specializations, while others may rely on definitions that can vary considerably frommeta-model to meta-model. 3  Software Architecture DefinitionA modelling notation has to be used to document the resulting model, i.e., the framework soft-ware architecture. For the purpose of defining the software architecture, the modelling nota-tion can still abstract from implementation details like language syntax and communicationsub-systems interface. However, the mapping of the constructs of the modelling notation ontoimplementation constructs of an implementation environment should be straightforward. The deliverable of this phase consists mainly of data dictionaries and class diagrams. Interac-tion diagrams [8] are eventually used to represent scenarios that are relevant for the under-standing of dynamic aspects of the software architecture. In order to deal with more complexdynamic behaviour, i.e., an object class with a non-trivial number of states, we make use ofstate diagrams that offer a complete and precise behaviour description. For each class we must also define its boundary conditions, i.e.; initialization, termination andfailure. In the initialization, the system must be brought from a quiencent initial state to a sus-tainable steady state condition. Termination usually consists of releasing allocated resources.Failure can arise from user errors or from resources exhaustion. The benefits and drawbacksof the design decisions taken in the development of the software architecture are documentedin natural language, in order to facilitate the selection among alternative frameworks, whenimplementing a specific protocol. The modelling process that defines the software architectureis mainly a creative process. Nevertheless, some heuristics can be applied to support this task.We present such heuristics in next sub-section.3.1  Heuristics for defining the software architectureBy heuristics we mean any actions or procedures whose effectiveness has not been proven butare accepted based on experience or common sense. In software engineering, such approachstill plays an important role and therefore saving such knowledge is a pragmatic attitude.The main heuristic for defining software architecture comes from the object-oriented systemdevelopment method presented in [2]. In order to reach the framework software architecture,the class diagram obtained from the domain analysis must be adapted to an implementationenvironment. Object classes are excluded or included in the software architecture for imple-mentation optimization. New responsibilities of object classes must be defined. However,optimization of the design should not be excessive. Another way to apply heuristics is the use of design patterns. A design pattern is a descriptionof communicating objects that are customized to solve a general design problem in a particu-lar context [1]. Design patterns are usually the result of a largely applied implementation solu-tion which became well known and flexible for reuse purposes. The use of design patternsmakes the software architecture definition more systematic. Design patterns represent a com-promise between an one-class implementation solution, e.g., a linked list, which is reused theway it is, and a more complex solution which falls in the category of a framework.Page 4 of 5For some important issues of protocol implementation, e.g., execution flow control and map-ping of protocol behaviour, some design patterns can be found in the literature. For example, apattern called scheduler can be used to share the opportunity of execution among differentparts of a system; a pattern called event-demultiplexer to supply an event-driven executionmodel; the state pattern can be used for mapping a finite state machine. 4  CodingIn this step we map the framework software architecture onto the constructs of a specificimplementation environment. Some instructions on mapping the object-oriented implementa-tion model onto implementation code is given is the Object Design phase of the Object Mod-elling Technique (OMT) development method presented in [2]. We apply a prototyping strategy for coding. In this approach, the concepts which havestronger impact in the implementation are coded first. We start by producing a simplified pro-totype which allows preliminary tests. An interactive and incremental approach is also advisedin the software development process presented in [9]. The prototyping strategy helps us rea-soning about different problems separately. When dealing with some improvements in aframework, we can abstract from other features that are consolidated in previous versions ofthe same framework. In the coding step we also have to decide about the trade-off between portability and perform-ance. Building blocks that are intended to improve performance are usually less portable, forexample, multi-thread packages. Some implementation building blocks offer portability, e.g.,wrappers [10]. 5  DocumentationProtocols are specified by creating instances of the concepts of a design model and combiningthese instances. Modelling techniques have constructs representing the concepts and con-structs to combine them, as operators of concepts. Frameworks are intended to support moredirectly the semantics of design concepts, but it is not our goal to support any particular speci-fication language. Therefore, in order to use a framework, we have to provide some guidelinesthat describe how to create instances of concepts and how to combine them.Since we are applying object-orientation, instantiation of the constructs supplied by the frame-work to support design concepts can be done by instantiation of object classes. Some of thesesobject classes may need specialization in order to capture protocol specific information. Inorder to combine the instantiated concepts, different techniques may be applied, such as:• template code to be filled in with code for each specific protocol function;• suggested mappings of behaviour structures of the protocol specification onto implemen-tation patterns.The instructions for applying a framework must also contain the information for handlingboundary conditions. Guidelines for using frameworks are formulated in natural language andillustrated with some examples.Page 5 of 56  Conformance AssessmentProtocol development methods that use formal methods emphasize precision as the basis forthe design activity. An important requirement in our research is the conformance betweendesign concepts and the way such concepts are supported by the protocol implementation. Thesemantics of the design concepts must be preserved in the implementation, otherwise, theeffort done in the design may be compromised.We have decided for a pragmatical approach to deal with the conformance requirement. Wesuggest testing techniques upon each concept implementation whenever the complexity of theconcepts justifies so. We claim that the application of test techniques to basic design conceptsis simple and produce reliable results.7  ConclusionsWe have briefly presented a systematic way to develop frameworks. This approach is an effortto combine formal design techniques with current practices in software engineering in a inte-grated protocol development process. We have presented the phases of our method and theirdeliverables. We have pointed out the conceptual basis of our work and the techniquesapplied. This is an approach that is better applied in environments where the changes in therequired protocol functionalities are frequent. We claim that with this method we haveaddressed the cornerstones of an efficient and reliable process for implementing protocols. 8  References[1]     E. Gama, R. Helm, R. Jonson, J. Vlissides, Design Patterns: Elements os Reusable-Ori-ented Software, Addison-Wesley Publishing Company, 1994.[2]      J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, Object-Oriented Modeling and Design, Prentice Hall, New York, 1991, 491p.[3]     Using Formal Description Techniques: An Introduction to Estelle, LOTOS and SDL, Ed-ited by Kenneth J. Turner, John Willey & Sons, 1993, 431p.[4]     ISO, Information Processing Systems - Open Systems Interconection - Basic Reference Model, 1984, IS 7498.[5]     D.D. Clark, The design philosophy of the DARPA Internet protocols. In proceedings of the SIGCOMM’88 Symposium (Aug. 1988), pp. 106-114.[6]     C.A.Vissers et al., The Architectural Design of Distributed Systems, Lecture Notes, Uni-versity of Twente, Enschede, The Nethedlands, 1995.[7]     C.B.Barbosa; L.F.Pires; M.Sinderen, Frameworks for Protocol Implementation, Simpo-sio Brasileiro de Redes de  Computadores 16, 1998,[8]     M.Fowler, K.Scott, UML Distilled - Applying the Standard Object Modeling Language, Addison-Wesley, 1997, 179p.[9]     G. Booch. Object-oriented analysis and design with applications. The Benjamin/Cum-mings Publishing Company, Inc., California, USA, 1994.[10]     D.C. Schmidt, ACE: an Object-Oriented Framework for Developing Distributed Appli-cations, in Proceedings of the 6 USENIX C++ Technical Conference, (Cambridge, Ma-sachusetts), USENIX Association, April 1994.

Developing frameworks for protocol implementation

Abstract

Similar works

Full text

Available Versions

University of Twente Research Information