Object Oriented Design of an Embedded Communication Protocol in UML Danny Patel EE249 Project Abstract This paper presents an object oriented approach to describe an embedded communication protocol in UML We build on top of existing work based on object oriented patterns We follow the belief that there should exist a generalized structure or pattern on which protocols should be formed We feel that the system structure is of importance for promoting reuse These protocol patterns would provide flexibility for the cost of additional complexity This complexity could be later simplified for a flexibility tradeoff We will describe our protocol pattern and use it structure our protocol in our embedded communication system Our ultimate goal is too look for a describe and synthesize technique for communication protocols 1 Introduction Embedded Communication protocols describe the legal sequence of process that process can exhibit Essentially they provide the rules of communication At the highest level of abstraction the protocol may actually describe the purpose of the system The refinements of the highest layer bring about objects that are required to implement the higher layer These objects then need coordination or protocols This process could repeat many times to evolve into the communication protocol for the embedded system Protocol design is becoming an increasing complex and cost sensitive process For this reason we wish to find a good describe and synthesize path Therefore our first attempt is to describe our protocol cleanly and to identify the boundaries of our system Thus our primary goal is to find a novel protocol structure that fits all and use UML to describe it Our secondary goal is clearly describe the semantics of UML and find its place in our describe andsynthesize path We chose to describe our model in UML because it has roots in programming languages it is object oriented and it was a new tool 1 1 What is UML Booch s definition of UML is a graphical language for visualizing constructing and documenting the artifacts of a software intensive system Boo98 It is a language that captures the object oriented model Some of the items this model stresses are data encapsulation information hiding and inheritance UML has mainly been targeted for software projects where it has met the most success UML s intent is to capture the object oriented OO model and many OO practitioners have praised this model We also hope to reap some of the OO benefits and believe we are not limited by the software nature of UML We believe in philosophy that software and hardware can be 1 abstracted away so we do not see UML s software nature as a big hindrance We also hope to use object oriented properties to ultimately promote reuse Actually there already exists an object oriented language for protocols called SDL SDL is more formal1 with its communication assumptions and it is a Formal Description Technique FDT SDL is based on an extended finite state machines EFSM framework that have asynchronous processes with zero delay intra process signals Tru98 and unbounded delay between process blocks We see UML not as a replacement for SDL but as a front end for it SDL was not at the right level of abstraction to begin designing protocols so we had hoped UML could remedy this UML is really very general and still incomplete but this gives us freedom to explore structures without worrying too much about the details Thus the main focus of this paper is the exploration of next generation protocol structure but first let us finish describing the semantics of UML UML is still under development and is mainly a notation rather than a formal language right now UML does not clearly define the communication between objects very rigidly It uses the notion of message passing but they can be rendezvous2 or unsynchronized3 or different shades of both Also the existence of queue is implied but the exact type is not specified Each object in a UML diagram has a class which generalizes that object and within the class there is a state diagram that describes the behavior These state diagrams are very much like Harel s STATEMATE for statecharts HN96 UML allows states to be hierarchical concurrent and nondeterministic defined by name entry exit actions internal transition substates deferred events 4 State transitions are defined by source state event trigger guard condition on event trigger action atomic local object only target state States are reactive but not synchronous5 and process that occur on transitions or in states have some unknown bounded delay Actually UML carries no notion of any time real or abstract All this expressive power tends to causes trouble in completely specifying a system for the real time systems Its practitioners have recognized these problems and have added some constraints to synthesize usable code These constraints include fully deterministic state machines and some partial ordering of signals SL98 However it is not 1 I use formal loosely It is however more formal than UML LSS98 definition of rendezvous LSS98 definition of unsynchronized 4 A more detailed description found in BJR98 pp 291 3 5 LSS98 definition of synchronous 2 3 Figure 1 Protocol Interface pattern in UML notation Basically similar to the SAP points found in the OSI model except that client n 1 which exists in the layer n 1 can access layer n and z our intent to construct some underlying MoC6 for UML We use UML as tool to visualize object oriented protocol structures and in this aspect we found it useful The message sequence charts helped to describe dynamic behavior state charts helped describe some internal behavior class diagrams helped describe the structure The remaining outline of the paper is as follows a section on object oriented protocol design a UML description of a communication protocol using our protocol structure a few wrap up sections towards the end of the paper 2 Object Oriented Protocol Design Research in object oriented structures for protocols has had some success Most of the papers describe a protocol that existed and then model the structure for it Yet what most of these papers lacked was an insight on what the generalized object oriented pattern that the protocols took We believe that there should be a generalized structure that holds for all protocol layers and that they should not be constrained to be rigidly layered as in the OSI model In fact the designer should design the protocol stack so that it could
View Full Document
Unlocking...