Uml 2 toolkit phần 5 pot

191 This chapter explores advanced mechanisms for showing dynamic behavior illustrated by real-time systems. We seek to provide you enough information to diagnose issues and to decide on the advanced “tool” from the UML toolkit you need. Even modelers who think they will never need real-time features will benefit from this chapter because all complex systems rely on the elements discussed in this review. UML has more advanced options than we can cover in this chapter, including dynamic modeling with components, working with Web services, and advanced development with the UML action semantics. Given the general nature of real-time issues, we concluded that this theme pro- vides the best focus for advanced features in the complete UML diagram set. This chapter investigates common issues in real-time systems and explores related concepts used in UML diagrams. The diagram section relies on practi- cal examples, including an alarm system and an investment simulation game. Finally, the chapter considers advanced design and implementation issues, including suggestions on when to use the different UML diagrams. What Is a Real-Time System? No set definition of a real-time system exists. The term has come to stand for a system concerned with performance, scheduling, and timing. Even a simple Advanced Dynamic Modeling Illustrated by Real-Time Systems CHAPTER 6 Internet application has real-time elements with performance over a distrib- uted network. Any time a system must handle external events within con- strained time limits, execution is concurrent, or the performance of the system needs to be “fast,” you can benefit from real-time modeling features. Attributes of a Real-Time System A real-time system has the following attributes. ■■ Timeliness is important. The system performs its functions within specified time limits (“response time”). All specified time deadlines must be handled by the system. ■■ It is reactive. The system is continuously responding to events from the external environment that trigger the execution of the system. ■■ It contains concurrently executing control processes, where different parts of the software run in parallel. Concurrency enables an efficient utilization of the hardware and is used in creating good models of sys- tems where external events occur in an unpredictable manner. ■■ It has very high requirements in most of the non-function-related areas such as reliability, fault tolerance, and performance. This makes almost all Internet applications in need of some form of real-time modeling. ■■ It is not deterministic. It is difficult to formally prove that the system will work in all situations under all conditions, due to the complexity of concurrency, the unpredictable events, and the hardware involved. Types of Real-Time Systems A real-time system is often highly integrated with its physical environment, receiving events and information through sensors and controlling devices through actuators. The system often works closely with specialized hardware and has to handle low-level interrupts and hardware interfaces, or ports. A system that involves tightly integrated specialized hardware and software is called an embedded system. Embedded systems can be found in cars, consumer electronics, manufacturing machines, and many other places. An embedded system often uses a small real-time operating system that uses limited mem- ory. An embedded system must be fast enough to control its hardware and to handle all the events, even in a worst-case situation when everything happens at once. Real-time systems are often divided into hard and soft categories. In a hard real-time system, a late (or incorrect) response is considered an unacceptable 192 Chapter 6 error that can result in loss of life. Examples of hard real-time systems are air- plane control software, life surveillance systems, battlefield target control, and automatic train control systems. Soft real-time systems can accept a late response occasionally, for instance, in a digital telephone system: it may take a long time to connect a call, or the connection may fail; neither scenario is con- sidered a serious or dangerous error, but they are situations the company wants to avoid. Real-time systems, then, require excellent design. How does UML address these demands? Concepts in UML for Real-Time Systems This section presents the basic concepts needed for modeling a real-time sys- tem in UML. Later in the chapter we show you how these are handled in UML diagrams. The mechanisms presented include the definition of active classes and objects (concurrency), communication between active objects, the syn- chronization of active objects, and fault tolerance. Some real-time systems get very complex. The issues explained here are the more common. The Object Management Group (OMG) has a set of standard extensions for real-time systems called the profile for schedulability, perfor- mance, and time. This can help with advanced real-time modeling concepts, such as those involving complex latency and relative time. For more on pro- files and how they extend UML, see Chapter 8. Here our focus relates to the basic issues in the core of UML that illustrate advanced dynamic modeling, not a review of advanced profiles. CROSS-REFERENCE For more advanced real-time features, review the profile for schedulability, performance, and time from the OMG. Active Classes and Active Objects The key structure in a real-time system is the active class or object. An active class owns an execution thread so that all instances of that class, or the active objects, can initiate control activity. An active object can execute in parallel with other active objects and initiates actions by itself, in its own code or by sending messages. The active object executes its specified behavior until it is completed or terminated by an external force. The active object determines the reaction to external communication; the external object does not invoke the behavior or the active class. The active class represents the unit that executes concurrently. In contrast, a passive class has instances that can execute only when some other object performs some operation on it (sends a message to it). Advanced Dynamic Modeling Illustrated by Real-Time Systems 193 Active Class Implementation An active class usually is implemented as a process or a thread. A thread is a more “lightweight” unit of control. The important difference between process and thread is that a process normally encapsulates and protects all its internal structure by executing in its own memory space, while a thread executes in a memory space shared with other threads; this memory space can contain shared information (such as other objects). A thread may require less resources, but this means the shared resources must be managed. Active classes are typically implemented through a class library with a superclass for the active class or an interface that an active class can imple- ment. This superclass contains the mapping of process or thread operations such as start, stop, suspend, resume, priority handling, and so on to the corre- sponding operating system calls that implement these functions. See the Java implementation later in the chapter for an example. Active Object Interactions Once you have an object that can control a thread or process, it increases the options for interaction. With such options arise issues of communication between these active objects and the synchronization of resource usage. These concerns form the heart of real-time systems and dominate the rest of the chapter. Active objects generally require more resources than passive objects because they own or reference a number of other objects. Sometimes a package or com- ponent is controlled through an active object that makes the package run con- currently with other packages. However, it is important to realize that even in a hard real-time system, there are a lot more passive objects than active objects. A cost is connected with creating a thread, and the system becomes overly complex and slow if too many active objects are defined. An active class is shown in UML as a class rectangle drawn with an extra vertical line on the inside. If the name inside the rectangle contains a class name, the symbol represents an active class; if the name is underlined with a colon showing the class and the instance, the symbol represents an active object (see Figure 6.1). Without the underlining, the symbol represents an active part. When instantiated, a part functions in this context like any other active object (see Chapter 7 for composite structure diagrams and parts). Figure 6.1 An active class and an object of that active class. «ActiveClass» Communication Supervisor anInstance: Communication Supervisor 194 Chapter 6 An active class, part, or object is often depicted with its internal structure embedded, as shown in Figure 6.2, and typically uses several other classes to define its internal structure. These internal classes can be both active and pas- sive. Because active classes might manage a wide array of low-level behavior, they can have complex internal structure. Knowing the internal structure gets you to the first step in assessing a real-time system. Understanding how these active and passive objects communicate presents the next major hurdle. Communication Understanding the difference between asynchronous or synchronous commu- nication is essential for real-time design. ■■ Asynchronous communication is unpredictable—that is, an event can occur at any time in the execution of the system, and it is not possible to know when a specific behavior will be triggered by an event. ■■ Synchronous communication is predictable in that it can occur only at specified times in the execution of the system (which can be identified by reading the control flow in the code). Figure 6.2 An active object with its internal structure in terms of other active or passive objects. Input: MessageBuffer Log1: CommunicationLog Output: MessageBuffer DetailLog: CommLog Manager :Communication Tracking Supervisor Advanced Dynamic Modeling Illustrated by Real-Time Systems 195 Passive objects normally use the synchronous approach to communicate with each other through operations (synchronous message sending). One object calls an operation (sends a message to) another object, and the calling object waits for the operation to execute (possibly along with a return value from the operation). As part of the operation call, data can pass between the objects. Such communication is not advanced. An object sends a message and waits for a return, like someone ordering a book from a mail-order company. Once a reader has ordered the book, the reader must wait for the book to arrive before he or she can start reading that book. Of course, only a fool would stop reading entirely until the book arrived; people have libraries and other books they can read until they get the book they ordered. In contrast to the single option in synchronous communication, active classes and objects have far more communication options, so the mod- eling will show greater complexity. Messages will not necessarily occur in a particular order, and you need to model the system response to a message based on the current state. Depending on the priority for the book ordered from the mail-order company, when the book finally arrives, the reader either starts reading as soon as possible or puts it on the shelf for later. Of course, the decision gets more complicated if the reader gets three books on the same day. In a similar manner, systems using asynchronous communication must handle messages and triggers. A real-time system uses both asynchronous and synchronous communica- tion. Typically, external events in the environment happen asynchronously, while parts of the internal communication in the system are synchronous. When discussing message sending between objects, asynchronous and syn- chronous communications have also come to indicate whether the sending object waits for the message to be handled (synchronous message sending) or not (asynchronous message sending). A number of strategies can be used to enable active objects to communicate with each other. Active objects must be able to execute concurrently and to send messages to other active objects without having to wait for a return value. Some common mechanisms for active object communication include the following. ■■ Operation calls. An ordinary call on an operation in an object. This is the equivalent of sending a synchronous message to an object, whereby the caller waits for the operation to finish and return. ■■ Mailboxes/message queues. A technique that defines mailboxes or message queues. A message is placed in the mailbox and at some point read and handled by the receiver. This technique allows for asynchro- nous messages; a sender can place a message in the mailbox and then continue to execute. This is often called the publish/subscribe model, whereby an object will send a message to a common destination and other objects will subscribe in order to get the message. 196 Chapter 6 ■■ Shared memory. A block of memory is reserved for communication, so that two or more active objects can write and read information. The block has to be guarded so that concurrently executing objects don’t access the information at the same time. ■■ Rendezvous. A technique by which specific rendezvous points in the execution of two threads are defined. The first thread to reach the ren- dezvous point stops and waits for the other thread. When both threads are at the rendezvous point, they exchange information and then start to execute concurrently again. ■■ Remote procedure calls (RPCs). RPCs handle distribution of concur- rent threads. The calling thread identifies an operation in an object and then furthers this request to the RPC library. The RPC finds the object in the network, packages the request, and sends the request over the net- work. On the receiving side, the request is translated to the format that the receiving object wants, and the call is made. When the call is fin- ished, the result is returned in a similar manner. To describe these strategies, modelers rely on showing communication with triggers, signals, and messages. Events and Triggers In UML, an event can provide a trigger to cause the execution of a behavior. An event is something that occurs in the system or in the environment. A well- designed system handles effectively the set of possible events. The behavior triggered by the event is often connected to the state of an object; the same event can cause different behaviors, depending on the state. An event can also trigger a transition from one state to another. As discussed in Chapter 5, UML defines four triggers related to four types of observable events. ■■ Change trigger. When a Boolean value expression is set to “true” because of some change, this represents a change that could trigger something for an object. So, for example, a guard condition that becomes true is considered a trigger that will have consequences. Once a change event prompts a change trigger, that change trigger remains active for the behavior until completion, even if the expression associ- ated with the change event returns to false. ■■ Signal trigger. The receipt of an asynchronous signal can trigger behav- ior. Receiving a signal is called an AcceptEventAction, showing that the action will act on the event. See the section below for more detail on signals. ■■ Call trigger. One object calls an operation in another object or an object calls an operation of its own. This operation call, which is considered a Advanced Dynamic Modeling Illustrated by Real-Time Systems 197 synchronous message, passes information through parameters and the return value. The call trigger represents the reception of a request to invoke an operation. The trigger indicates the behavior invoked in response to this call event, which can include state transitions or other behavior after the invocation of the called operation. ■■ Time trigger. A specified amount of time passing or reaching a speci- fied deadline also represents an event. The time trigger can be relative to the execution of some system element. A time trigger can also respond to absolute time, such as a tax program requiring you to file by midnight on April 15. Events can also be divided into logical and physical categories. A physical event is low level, at the hardware level, while a logical event is a higher-level representation of that occurrence. For example, the physical event “interrupt on port 4H” can be translated into the logical event “alarm from the infrared sensor device.” Because logical events are at a higher level of abstraction, defining your model with logical events is preferable to defining it with low- level physical events. Physical events should be translated into logical events as close to their detection as possible. Properties such as a categorization of the event, priority, time-handling requirements, and administrative information can be defined for the classifiers that respond to the event. Signals Signals in UML specify the classifier passed between objects for communica- tion. The signal can have attributes and operations to carry both information and behavior. Signals are passed between objects in the system asynchro- nously. On an interaction diagram, a message can represent a signal as well as an operation call. Signals can also be shown on transitions in state machines, and they can be shown on activity diagrams. Because a signal is a classifier and a generalizable element, it uses class nota- tion and inheritance (see Chapter 4 for an overview of generalization). These features make it possible to group a number of signals under a common super- class. A receiver of a signal can then specify that it accepts objects of a specified superclass or any of its specialized subclasses. Asuperclass in such a hierarchy can also contain general information about the signal. A signal can be shown with special notation if desired. The receipt of a sig- nal can be a rectangle with a notch in the side in the form of a triangle. The sending of a signal can be a rectangle that has a triangular point protruding from one side. A signal can also be shown as a classifier with the stereotype <<signal>>. Figure 6.3 shows a sample hierarchy of signal classes. 198 Chapter 6 Figure 6.3 A hierarchy of signal classes. Signals can be either logical or physical signals carrying low-level hardware information or a higher-level interpretation of what the event means in terms of the execution of the system. Messages Objects interact through messages. Amessage can be implemented by a simple operation call, or as a signal object that can be put in a mailbox or queue. A message can also be used to send a communication to create or to destroy an instance. The receipt of a message represents an event that can trigger a behav- ior. These messages used to communicate come in a few different types, as explained in the following: ■■ Synchronous. A synchronous message between active objects indicates wait semantics; the sender waits for the message to be handled before it continues to execute. This typically shows a method call. ■■ Reply. This shows the return message from another message. ■■ Create. This message results in the creation of a new object. The mes- sage could call a constructor for a class if you are working with Java, for example. The create message used in UML 2 has the same format as the old return message in UML 1.x, making this message not backward compatible with older sequence diagrams. ■■ Asynchronous. With an asynchronous flow of control, there is no explicit return to the caller. An asynchronous message between objects indicates no-wait semantics; the sender does not wait for the message before it continues. This allows objects to execute concurrently. «Signal» Signal «Signal» Synchronization «Signal» Perform Command «Signal» Object Drop «Signal» Logical «Signal» Physical «Signal» Key Pressed «Signal» Mouse move Advanced Dynamic Modeling Illustrated by Real-Time Systems 199 [...]... systems that don’t model concurrency, and are described in Chapter 5 :Photo Cell Sensor 1 Alarm :Cell Handler :Supervisor 2c.1 Store(Date, Time, Cell, Sensor) :Log :Sound Alarm :System Handler 2c .2 Trigger 2c Alarm 2b Trigger :Phone Alarm 2a Trigger :Phone Alarm Advanced Dynamic Modeling Illustrated by Real-Time Systems Figure 6. 15 A sensor has detected a movement and initiates an alarm in the system... into superactivities to prevent the diagram from becoming too complex The activity diagram shows how these signals interact For more detailed review of messages between instances, use the UML interaction diagrams 22 1 22 2 Chapter 6 Waiting for signal Alarm Deactivate Time-out Trigger Alarm Trigger Alarm A Activate Activate Message Handling Deactivate Message Handling Time-out Message Handling Trigger Alarm... parallel can be described using letters in the sequence number expression For example, the sequence numbers 2. 1a and 2. 1b of two messages in the communication diagram indicate that those messages are sent in parallel The message label can also implicitly contain synchronization information through the 22 3 22 4 Chapter 6 predecessor specification A predecessor specifies other messages that must be performed... The higher-priority object still runs, but not according to the defined priority scheme 20 1 20 2 Chapter 6 A variety of design patterns expressed in UML address these typical issues For a review of these design patterns, see Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems (Douglass 20 02) We discuss some of these in terms of managing synchronization Synchronization Mechanisms... submitVerifiedBid() {t . excellent design. How does UML address these demands? Concepts in UML for Real-Time Systems This section presents the basic concepts needed for modeling a real-time sys- tem in UML. Later in the chapter. if you are working with Java, for example. The create message used in UML 2 has the same format as the old return message in UML 1.x, making this message not backward compatible with older sequence. of a behavior to one instance, and these can occur simultaneously. 20 2 Chapter 6 The built-in support for synchronization in UML can be extended using stereotypes or properties. For example, if