REAL-TIME SYSTEMS DESIGN AND ANALYSIS phần 6 docx

5.4 PROCEDURAL-ORIENTED DESIGN 241 Context Diagram DFD Level 1 DFD Level 0 B C A System Part 1 Part 2 Part 3 X Y Z e X d f Y Z Part 3.1 Part 3.2 Result e Z f P_Spec 3.2 Result: data_in; Z: data_out; Body …. Figure 5.7 Context diagram evolution from context diagram to level 0 DFD to level 1 DFD, and finally, to a P-SPEC, which is suitable for coding [Laplante03b]. DFD 0 Display Information ∆ x , ∆ y , ∆ z Torquing Pulses ( gx , gy , gz ) 40a-ms Interrupt Attitude Data Attitude Data Temperature, Other Physical Data Torque Gyros 1 Process Accelerometer Data 2 10-ms Interrupt Store and Transmit Data 3 40b-ms Interrupt Diagnostics 4 True Acceleration, Velocity, and Position Information 1000-ms Interrupt Temperature, Other Physical Data True Acceleration, Velocity, and Position Information Diagnostics Information Diagnostics Information Diagnostics Information Figure 5.8 Level 0 DFD for the inertial measurement system. The dashed arcs represent control flow in the system. 242 5 SOFTWARE SYSTEM DESIGN DFD 1: Torque Gyros 40a-ms Interrupt Validate Data Compute Pulses Pulses_Counts Attitude Data 1.1 1.2 Attitude Data, Valid_Data Output Pulses 1.3 Torquing Pulses True Acceleration, Velocity, and Position Information Diagnostics Information Figure 5.9 DFD 1: Gyro torquing. 1.1 Validate Data Check that data are within acceptable range 1.2 Compute Pulses If valid_data= TRUE, compute pulses as follows… 1.3 Output Pulses Output torquing pulses as follows… Figure 5.10 P-SPECs for DFD 1: Torque gyros. interface flow in the DFD. Data structure diagrams are also used to describe information about logical relationships in complex data structures. 5.4.2.2 Data Dictionaries A data dictionary is a repository of data about data that describes every data entity in the system. This dictionary is an essential component of the structured design, and includes entries for data flows, control flows, data stores, data elements, control elements. Each entry is identified by name, range, rate, units, and so forth. The dictionary is organized alphabetically for ease of use. Other than that there is no standard format, but every design element should have an entry in it. Most CASE tools provide the data dictio- nary feature. For example, each entry might be organized to contain the following information: Entry type (data flow, data store, terminator, process) Name 5.4 PROCEDURAL-ORIENTED DESIGN 243 10-ms Interrupt DFD 2: Process Accelerometer Data 2.1 Attitude Data Errors Diagnostic Information True Acceleration, Velocity, and Position Information ∆ x , ∆ y , ∆ z Temperature, Other Physical Data 2.2 2.3 2.4 Errors Validated Interrupt Invalidated Interrupt Validate Interrupt Compute True Accelerations Compensate Accelerometer Data Error Processing 2.4 Compute Final Parameters True Acceleration, Velocity, and Position Information Compensated Accelerometer Data True Accelerations Errors Figure 5.11 Level 1 DFD 2: Compensate accelerometer data. Temperature, Other Physical Data True Accelerations 2.3.1 2.3.2 Compensated Accelerometer Data Calculate Compensation Factors Compensate Accelerations Compensation Factors Figure 5.12 DFD 2.3 compensate accelerometer data. 244 5 SOFTWARE SYSTEM DESIGN 2.3.2 Compensate Accelerations begin cax = f(ax,…) cay = f(ay,…) caz = f(az,…) end Figure 5.13 P-SPEC corresponding to functionality 2.3.2. Alias Description Found in For the inertial measurement system in particular one entry might appear as follows: Type: Data flow Name: Compensation factors Alias: Comp. factors Description: Accelerometer compensation factors used for temperature and mass unbalance corrections. Found in: 2.3.1 The missing information for modules “Found in” will be added as the code is developed. In this way, data dictionaries help to provide substantial traceability between code elements. 5.4.2.3 Problems with Structured Analysis and Structured Design in Real-Time Applications There are several apparent problems in using struc- tured analysis and structured design (SASD) to model the real-time systems, including difficulty in modeling time and events. For example, concurrency is not easily depicted in this form of SASD. Another problem arises in the context diagram. Control flows are not easily translated directly into code because they are hardware dependent. In addition, the control flow does not really make sense since there is no connectivity between portions of it, a c ondition known as “floating.” Details of the underlying hardware also need to be known for further modeling of Process 1. What happens if the hardware changes? What if the algorithm or even the sensitivity levels change because of the installation of new hardware? In this case the changes would need to propagate into the level 1 DFD for each process, any subsequent levels and, ultimately, into the code. 5.4 PROCEDURAL-ORIENTED DESIGN 245 Clearly making and tracking changes in structured design is fraught with dan- ger. Moreover, any change means that significant amounts of code would need to be rewritten, recompiled, and prope rly linked with the unchanged code to make the system work. None of these problems arise using the object-oriented paradigm. 5.4.2.4 Real-Time Extensions of Structured Analysis and Structured Design It is well known that the standard SASD methodology is not well equipped for dealing with time, as it is a data-oriented and not a control-oriented approach. In order to address this shortcoming, Hatley and Pirbhai extended the SASD method by allowing for the addition of control flow analysis. To do this the following artifacts were added to the standard approach: arcs made of dashed lines to indicate the flow of control information, and solid bars indicating “stored” control commands (control stores), which are left unlabeled [Hatley87]. Additional tools, such as Mealy finite state machines, are used to represent the encapsulated behavior and process activations. The addition of the new control flows and control stores allow for the creation of a diagram containing only those elements called a control flow diagram (CFD). These CFDs can be decomposed into C-SPECs (control specifications), which can then be described by a finite state machine. The relationship between the control and process models is shown in Figure 5.14. Although the Hatley-Pirbhai extensions suggest that the CFD and C-SPECs stand alone, the CFD by itself makes little sense. Hence, the CFD and DFD are generally combined as shown in Figure 5.11. Process Model DFDs P-SPECs Control Model C-SPECs CFDs Data OutputsData Inputs Control Inputs Control Outputs Process Activations Data Conditions Figure 5.14 The relationship between the control and process model [Laplante03c]. 246 5 SOFTWARE SYSTEM DESIGN 5.4.3 Design in Procedural Form Using Finite State Machines One of the advantages of using finite state machines in the software requirements specification and later in the software design is that they are easily converted to code and test cases. For example, consider the inertial measurement system. The tabular representation of the state transition function (Table 4.2), which describes the system’s high-level behavior, can be easily transformed into a design using the pseudocode shown in Figure 5.15. Each procedure associated with the operational modes (TAK, NAV, NAE, NAA, LAN) will be structured code that can be viewed as executing in one of any number of process states at an instant in time. This functionality can be described by the pseudocode shown in Figure 5.15. The pseudocode shown in Figures 5.15 and 5.16 can be coded easily in any procedural language, or even an object-oriented one. Alternatively, the system behavior can be described with a case statement or nested if then statements such that, given the current state and receipt of a signal, a new state is assigned. This is illustrated below: TAK: If MA then NAV Else TAK NAV: If TD then NAA If MC then LAN If LO then NAE Else NAV typedef states: (state 1, ,state n); {n is# of states} alphabet: (input 1, ,input n); table_row: array [1 n] of states; procedure move_forward; {advances FSM one state} var state: states; input: alphabet; table: array [1 m] of table_row; {m is the size of the alphabet} begin repeat get(input); {read one token from input stream} state:=table[ord(input)] [state]; {next state} execute_process (state); until input = EOF; end; Figure 5.15 Pseudocode that can implement the behavior of the finite state machine shown in Figure 4.1 [Laplante03c]. 5.5 OBJECT-ORIENTED DESIGN 247 Procedure execute_process (state: states); begin case state of state 1: process 1; {execute process 1} state 2: process 2; {execute process 2} state n: process n; {execute process n} end Figure 5.16 Finite state machine code for executing a single operational process in the avionics system. Each process can exist in multiple states, allowing for partitioning of the code into appropriate modules [Laplante03c]. NAE: If EE then NAA Else NAE NAA: If LO then NAE If ED then NAV Else NAA LAN: Else LAN The advantage of finite state machine design over the case statement, of course, is that the former is more flexible and compact. 5.5 OBJECT-ORIENTED DESIGN Object-oriented programming languages are those characterized by data abstraction, inheritance, polymorphism and messaging. Data abstraction was defined earlier. Inheritance allows the software engineer to define new objects in terms of previously defined objects so that the new objects “inherit” properties. Function polymorphism allows the programmer to define operations that behave differently, depending on the type of object involved. Messaging allows objects to communicate and invoke the methods that they support. Object-oriented languages provide a natural environment for information hid- ing through encapsulation. The state, data, and behavior of objects are encapsu- lated and accessed only via a published interface or private methods. For example, in the inertial measurement system it would be appropriate to design a class called accelerometer with attributes describing its physical implementation and methods describing its output, compensation, and so forth. Object-oriented design is an approach to systems design that views the system components as objects and data processes, control processes, and data stores that are encapsulated within objects. Early forays into object-oriented design were led 248 5 SOFTWARE SYSTEM DESIGN by attempts to reuse some of the better features of conventional methodologies, such as the DFDs and entity relationship models by reinterpreting them in the context of object-oriented languages. This can be seen in the Unified Modeling Language (UML). Over the last several years the object-oriented framework has gained significant acceptance into the software engineering community. 5.5.1 Benefits of Object Orientation The benefits of object orientation in combining data and behavior into an encap- sulated entity have been discussed already. The real advantages of applying object-oriented paradigms are the future extensibility and reuse that can be attained, and the relative ease of future changes. Software systems are subject to near-continuous change: requirements change, merge, emerge, and mutate; target languages, platforms, and architectures change; and most significantly the way the software is employed in practice changes. This flexibility places a considerable burden on the software design: How can systems that must support such widespread change be built without compromising quality? There are four basic principles of object-oriented engineering that can answer this question and they have been recognized as supporting reuse. 5.5.1.1 Open–Closed Principle First recorded by Meyer [Meyer00], the open–closed principle (OCP) states that classes should be open to extension, but closed to modification. That is, it should be possible to extend the behavior of a class in response to new or changing requirements, but modification to the source code is not allowed. While these expectations may seem at odds, the key is abstraction. In object-oriented systems a superclass can be created that is fixed, but can represent unbounded variation by subclassing. This aspect is clearly superior to structured approaches and top-down design in, for example, changes in accelerometer compensation algorithms, which would require new function parameter lists and wholesale recompilation of any modules calling that code in the structured design. 5.5.1.2 Once and Only Once While certainly not a new idea, Beck [Beck99] put a name to the principle that any aspect of a software system – be it an algo- rithm, a set of constants, documentation, or logic – should exist in only one place. This isolates future changes, makes the system easier to comprehend and main- tain, and through the low coupling and high cohesion that the principle instills, the reuse potential of these aspects increases. The encapsulation of state and behavior in objects, and the ability to inherit properties between classes allows for the rigorous application of these ideas in an object-oriented system, but is difficult to implement in structured techniques. More importantly, in structured techniques, once and only once (OAOO) needs to be breeched frequently for reasons of performance, reliability, availability, and often, for security. 5.5.1.3 Dependency Inversion Principle The dependency inversion prin- ciple (DIP) states that high-level modules should not depend upon low-level 5.5 OBJECT-ORIENTED DESIGN 249 modules. Both should depend upon abstractions. This can be restated as: Abstrac- tions should not depend upon details, details should depend upon abstractions. Martin introduced this idea as an extension to OCP with reference to the prolifer- ation of dependencies that exist between high- and low-level modules [Martin96]. For example, in a structured decomposition approach, the high-level procedures reference the lower-level procedures, but changes often occur at the lowest levels. This infers that high-level modules or procedures that should be unaffected by such detailed modifications may be affected due to these dependencies. Again, consider the case where the accelerometer characteristics change and even though perhaps only one routine needs to be rewritten, the calling module(s) need to be modified and recompiled as well. A preferable situation is to reverse these depen- dencies, as is evident in the Liskov substitution principle (LSP). The intent here is to allow dynamic changes in the preprocessing scheme, which is achieved by ensuring that all the accelerometer objects conform to the same interface, and are therefore interchangeable. 5.5.1.4 Liskov Substitution Principle Liskov expressed the principle of the substitutivity of subclasses for their base classes as: What is wanted here is something like the following substitution property: If for each object o 1 of type S there is an object o 2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o 1 is substituted for o 2 then S is a subtype of T. [Liskov88] This principle has led to the concept of type inheritance and is the basis of polymorphism in object-oriented systems, where instances of derived classes can be substituted for each other, provided they fulfill the obligations of a com- mon superclass. 5.5.2 Design Patterns Developing software is hard and developing reusable software is even harder. Designs should be specific to the current problem, but general enough to address future problems and requirements. Experienced designers know not to solve every problem from first principles, but to reuse solutions encountered previously, that is, they find recurring patterns and use them as a basis for new designs. This is simply an embodiment of the principle of generality. While object-oriented systems can be designed to be as rigid and resistant to extension and modification as in any other paradigm, object-orientation has the ability to include distinct design elements that can cater to future changes and extensions. These “design patterns” were first introduced to the mainstream of software engineering practice by Gamma, Helm, Johnson, and Vlissides, and are commonly referred to as the “Gang of Four (GoF)” patterns [Gamma94]. The formal definition of a pattern is not consistent in the literature. Sim- ply, a pattern is a named problem–solution pair that can be applied in new 250 5 SOFTWARE SYSTEM DESIGN contexts, with advice on how to apply it in novel situations. This text is con- cerned with three pattern types: architectural patterns, design patterns, and idioms. An architectural pattern occurs across subsystems; a design pattern occurs within a subsystem, but is independent of the language; an idiom is a low-level pattern that is language specific. In general, a pattern consists of four essential elements: a name, such as “strategy,” “bridge,” “fa¸cade”; the problem to be solved; the solution to the problem; and the consequences of the solution. More specifically, the problem describes when to apply the pattern in terms of specific design problems, such as how to represent algorithms as objects. The problem may describe class structures that are symptomatic of an inflexible design. Finally, the problem section might include conditions that must be met before it makes sense to apply the pattern. The solution describes the elements that make up the design, though it does not describe a particular concrete design or implementation. Rather, the solution provides how a general arrangement of objects and classes solves the problem. Consider, for example, the previously mentioned GoF patterns. They describe 23 patterns, each organized by either creational, behavioral, or structural in its intent (Table 5.3). Table 5.3 is provided for illustration only, and it is not the intention to describe any of these patterns in detail. Other patterns have evolved, particularly for real-time systems, that provide various approaches to addressing the real-time communication and synchronization problem (e.g., [Douglass03; Schmidt00]). 5.5.3 Object-Oriented Design Using the Unified Modeling Language The UML is widely accepted as the de facto standard language for the specifica- tion and design of software-intensive systems using an object-oriented approach. By bringing together the “best-of-breed” in specification techniques, the UML Table 5.3 The set of design patterns popularized by the Gang of Four [Gamma94] Creational Behavioral Structural Abstract factory Chain of responsibility Adapter Builder Command Bridge Factory method Interpreter Composite Prototype Iterator Decorator Singleton Mediator Facade Memento Flyweight Observer Proxy State Strategy Template method Visitor [...]... structured analysis according to system focus 5 .6 APPENDIX: CASE STUDY IN SOFTWARE REQUIREMENTS SPECIFICATION 255 one, or at most two, of these vertices For example, early, non -real-time imageprocessing systems were data and action intensive, but did not encounter much in the way of stimuli and response Real-time systems are usually data intensive and would seem well suited to structured analysis But real-time. .. UML include the use of Q models [Motus94] and various temporal logics 5.5.3.10 Object-Oriented or Structured Design The preceding observations beg the question of whether object-oriented design is more suitable then SD for the embedded real-time systems and the inertial measure unit in particular SD and object-oriented design are often compared and contrasted, and, indeed, they are similar in some ways... int = 65 5 36 m_Record: Record* [0 * ordered] m_CurrentRecord: int m_First: int m_Last: int m_Full: boolean Database − − − − − − Name: Author: Version: Created: Updated: ErrorHandler() ∼ErrorHandler() onNonCriticalError(int) : void onCriticalError(int) : void −m_ErrorHandler IntersectionController- Class Model Team 2 1.0 18-Nov-2002 16: 34: 46 09-Dec-2002 07:13: 36 + −* + + ErrorHandler 5 .6 271... in the work of Parnas and his predecessors [Parnas79], [Parnas72] Table 5.4 provides a side-by-side comparison of the methodologies Both structured and object-oriented analysis (OOA) are full life-cycle methodologies and use some similar tools and techniques However, there are major 254 5 SOFTWARE SYSTEM DESIGN Table 5.4 A comparison of structured analysis and object-oriented analysis SA OOA System... Language (UML), supplemented by text descriptions, to define the details of the design This representation provides the design views described in IEEE 10 16 ([3]) within the framework of object-oriented design, as shown in Table 1 5 .6 APPENDIX: CASE STUDY IN SOFTWARE REQUIREMENTS SPECIFICATION 259 Table 1 IEEE 10 16 design views Design View Represented By SDD Reference Decomposition view Classes in class... Traffic signal control Same messages as between m_PedestrianDetector[0] and m_Approach[0] 2.2 resetState() 2.1 watchState() 2 ignoreState() m_Approach[1] :Approach m_VehicleTrafficStandard[0] :IntersectionStandard m_Approach[2] :Approach Same messages as between m_VehicleTrafficStandard[0] and m_Approach[0] m_VehicleTrafficStandard[1] :IntersectionStandard 5.1 onVehicleEntry(approach) 7 setIndication(indication)... Sequence Diagrams System Operation Contracts Software classes in domain layer of design from concepts in domain model Design Model Design Figure 5.17 The UML and its role in specification and design (Adapted from [Larman02]) 252 5 SOFTWARE SYSTEM DESIGN 5.5.3.1 Activity Activity diagrams are closely related to the flow chart and are used for the same purpose, that is, to show flow of control Typically,... fixed scheme Overall handling of pedestrian crossing requests Handling of emergency vehicle preemption Intersection control in response to manual override commands Intersection control in response to remote override commands Management of traffic history and incident log databases 274 5 SOFTWARE SYSTEM DESIGN 14 Handling of maintenance access requests from the maintenance port 15 Handling of maintenance... readDatabase(int) m Network m Maintenance 6 sendPacket(void∗ ) m Maintenance m Network 3.1.2 Collaboration Diagrams The collaborations described above are depicted in Figure 4 through Figure 9 m_PedestrianDetector[1] :OnOffSensor m_PedestrianDetector[0] :OnOffSensor m_PedestrianTrafficStandard[1] :IntersectionStandard Same messages as between m_PedestrianTrafficStandard[0] and m_Approach[0] m_VehicleDetector... Approach[1]::m VehicleTrafficStandard[0] 1.2.2 m IntersectionController::m Approach[1]::m VehicleTrafficStandard[1] 1.2.3 m IntersectionController::m Approach[1]::m VehicleTrafficStandard[0] 1.2.4 m IntersectionController::m Approach[1]::m PedestrianTrafficStandard[1] 1.2.5 m IntersectionController::m Approach[1]::m PedestrianDetector[0] 1.2 .6 m IntersectionController::m Approach[1]::m PedestrianDetector[1] 1.2.7 . Structured Analysis and Structured Design in Real-Time Applications There are several apparent problems in using struc- tured analysis and structured design (SASD) to model the real-time systems, including. suitable then SD for the embedded real-time systems and the inertial measure unit in particular. SD and object-oriented design are often compared and contrasted, and, indeed, they are similar in. early, non -real-time image- processing systems were data and action intensive, but did not encounter much in the way of stimuli and response. Real-time systems are usually data intensive and would