Berkeley ELENG C249A - Object-Oriented Design of an Embedded Communication Protocol in UML

Unformatted text preview:

1Object-Oriented Design of an Embedded Communication Protocolin UMLDanny Patel EE249 ProjectAbstract: This paper presents an object-orientedapproach to describe an embedded communicationprotocol in UML. We build on top of existing work basedon object-oriented patterns. We follow the belief that thereshould exist a generalized structure or pattern on whichprotocols should be formed. We feel that the systemstructure is of importance for promoting reuse. Theseprotocol patterns would provide flexibility for the cost ofadditional complexity. This complexity could be latersimplified for a flexibility tradeoff. We will describe ourprotocol pattern, and use it structure our protocol in ourembedded communication system. Our ultimate goal is toolook for a describe-and-synthesize technique forcommunication protocols.1 IntroductionEmbedded Communication protocols describe the legalsequence of process that process can exhibit. Essentially,they provide the "rules" of communication. At the highestlevel of abstraction the protocol may actually describe thepurpose of the system. The refinements of the highestlayer bring about objects that are required to implement thehigher layer. These objects then need coordination orprotocols. This process could repeat many times to evolveinto the communication protocol for the embedded system.Protocol design is becoming an increasing complex andcost-sensitive process. For this reason we wish to find agood describe-and-synthesize path. Therefore our firstattempt is to describe our protocol cleanly, and to identifythe boundaries of our system. Thus our primary goal is tofind a novel protocol structure that fits all and use UML todescribe it. Our secondary goal is clearly describe thesemantics of UML and find its place in our describe-and-synthesize path. We chose to describe our model in UMLbecause it has roots in programming languages, it isobject-oriented, and it was a new tool.1.1 What is UML?Booch's definition of UML is a graphical language forvisualizing, constructing, and documenting the artifacts ofa software intensive system [Boo98]. It is a language thatcaptures the object-oriented model. Some of the items thismodel stresses are data encapsulation, information hiding,and inheritance. UML has mainly been targeted forsoftware 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. Wealso hope to reap some of the OO benefits, and believe weare not limited by the software nature of UML. Webelieve in philosophy that software and hardware can beabstracted away so we do not see UML's software natureas a big hindrance. We also hope to use object-orientedproperties to ultimately promote reuse.Actually there already exists an object-orientedlanguage for protocols called SDL. SDL is more formal1with its communication, assumptions, and it is a FormalDescription Technique (FDT). SDL is based on anextended finite state machines (EFSM) framework thathave asynchronous processes with zero-delay intra-processsignals [Tru98] and unbounded delay between processblocks. We see UML not as a replacement for SDL but asa front-end for it. SDL was not at the right level ofabstraction to begin designing protocols so we had hopedUML could remedy this. UML is really very general (andstill incomplete) but this gives us freedom to explorestructures without worrying too much about the details.Thus the main focus of this paper is the exploration of nextgeneration protocol structure, but first let us finishdescribing the semantics of UMLUML is still under development and is mainly anotation rather than a formal language right now. UMLdoes not clearly define the communication between objectsvery rigidly. It uses the notion of message passing, butthey can be rendezvous2 or unsynchronized3 or differentshades of both. Also the existence of queue is implied butthe exact type is not specified. Each object in a UMLdiagram has a class which generalizes that object, andwithin the class there is a state diagram that describes thebehavior. These state diagrams are very much like Harel'sSTATEMATE for statecharts [HN96]. UML allows statesto be hierarchical, concurrent, and nondeterministicdefined by {name, entry/exit actions, internal transition,substates, deferred events} 4. State transitions are definedby {source state, event trigger, guard condition (on eventtrigger), action (atomic, local object only), target state}. Statesare reactive, but not synchronous5 and process that occuron transitions or in states have some unknown boundeddelay. Actually UML carries no notion of any time, real orabstract.All this expressive power tends to causes trouble incompletely specifying a system for the real-time systems.Its practitioners have recognized these problems and haveadded some constraints to synthesize usable code. Theseconstraints include fully deterministic state machines andsome partial ordering of signals [SL98]. However, it is not 1 I use formal loosely. It is however more formal than UML2 [LSS98] definition of rendezvous3 [LSS98] definition of unsynchronized4 A more detailed description found in [BJR98] pp.291-35 [LSS98] definition of synchronous2our intent to construct some underlying MoC6 for UML.We use UML as tool to visualize object-oriented protocolstructures, and in this aspect we found it useful. Themessage sequence charts helped to describe dynamicbehavior, state charts helped describe some internalbehavior, class diagrams helped describe the structure.The remaining outline of the paper is as follows: asection on object-oriented protocol design, a UMLdescription of a communication protocol using ourprotocol structure, a few wrap-up sections towards the endof the paper.2 Object-Oriented ProtocolDesignResearch in object-oriented structures for protocols hashad some success. Most of the papers describe a protocolthat existed and then model the structure for it. Yet whatmost of these papers lacked was an insight on what thegeneralized object-oriented pattern that the protocols took.We believe that there should be a generalized structurethat holds for all protocol layers, and that they should notbe constrained to be rigidly layered as in the OSI model. Infact, the designer should design the protocol stack so that itcould change dramatically with only local changes. Westress that layering may not be the most effectiveimplementation contrary to popular belief7. The layering ofthe


View Full Document

Berkeley ELENG C249A - Object-Oriented Design of an Embedded Communication Protocol in UML

Documents in this Course
Load more
Download Object-Oriented Design of an Embedded Communication Protocol in UML
Our administrator received your request to download this document. We will send you the file to your email shortly.
Loading Unlocking...
Login

Join to view Object-Oriented Design of an Embedded Communication Protocol in UML and access 3M+ class-specific study document.

or
We will never post anything without your permission.
Don't have an account?
Sign Up

Join to view Object-Oriented Design of an Embedded Communication Protocol in UML 2 2 and access 3M+ class-specific study document.

or

By creating an account you agree to our Privacy Policy and Terms Of Use

Already a member?