Introduction to UML

Booch’s definition of UML is a graphical language for visualizing, constructing, and documenting the artifacts of a software intensive system . 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 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 formal 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  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 rendezvous or unsynchronized 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}. 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 synchronous 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 . However, it is not our intent to construct some underlying MoC 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.

Source: Internet


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s