Embedded Systems October 2000 Vol13_11

Issue link:

Contents of this Issue


Page 145 of 181

5' the flow of requirements between domains. A domain can be analyzed, or it can be developed via other means, such as hand-written code, legacy code, generated from another source, imported from a library, and so on. Domain services are methods that make up the interface of the domain. Sin ce tlle domains define a complete specification of a single problem space, mey can be indepen- dently tested, tllen combined with omer domains for furmer testing • Information model:. for each domain that is to be analyzed, a UML class diagram is used to define the class- es tllat form the structure of the domain. Classes have associations with otller classes, and inhel-it from otller classes • Scenario model: key scenarios for this pecifi c domain are captured with UML sequence charts and/ or UML collaboJ"atio n diagrams to show interaction between domain ser- vices (ope rations), class services (memods), class events messages, and services of outside domains used in thi domain • State model: for each class th at receives event messages, a UML state diagram is used to capture the class lifecycl e, defining state-depen- dent behavior for tllat class • Action model: for each domain se r- vice, clas service, and tate action, a detailed, unambiguous behav- ioral description is created. This is expressed in an action language, an analys is-leve l "programming" language mat provides a complete set of analysis-level execution prim- itives wimout biasing me imple- men tation. By expl-essing behav- io ral detail in action language, con- siderable freedom is retained until me translation phase for how each analysis pl-imitive is implemented, which is critical for optimization Design Design is tlle creation of a strategy and mechan isms supporting me mapping of analysis constructs to a run-time environmen t. Design is conducted in a diffe rent concept space from analysis, and much of me preliminal}' design work can be completed independe nt of tlle analysis activities. Translation Translation is the process in which the UML mode ls fo r each analyzed domain are mapped to implementa- tion through design strategies. Design is conducted at two levels: • Structural design: identify me execu- tio n uni t (threads/ tasks/ processes) of the system, allocate them to processors, and allocate domains to the units • Mechanical design: develop detailed patterns (expressed in templates) to map analysis to implementation and build base mechanisms to sup- port this implementation Instrumentation Parallels to source code debugger Since the UML models represent a complete executable model of me sys- tem, me models can be translated into implementation automaticall y. A set of translation ru les is applied to the model, much like a compiler translates high-level programming languages. Following the language and model compiler analogy furtlle l~ a model com- piler can add inso-umentation in to tlle generated code,ju t as a language com- piler adds a symbol table and debug information in to the executable. Instrumentation from both compilers allows the resulting application to be tested and debugged by me developer at me same level of abso-action as it was developed. Only in vel}' rare cases would a high-level language developer want to look at tlle assembly or machine code when debugging an application. Similarly, for UML models, tlle develop- er will want to debug at tJle higher level of abstraction of me models, ramer tllan with me implementation code. The translational approach uses information from the ML models to create code to support testing in addi- 144 oaOBER 2000 Embedded Syst ems Programming tion to tlle application code. The instru- mentation does not add any additional fun ctionality to tlle software, omer man enhanced testabili ty. The test instru- mentation is only available for test sup- port and cannot be used during tlle normal operation of the software. Because tlle insu-umentation il-uect- ed during model translation is based only on the UML model execution seman tics, it provides a generic test harn ess mat can be applied to any application. The instrumentation can be compiled out, or me code regener- ated without the instrumentation, sim- ilar to the way debugging information is handled by the compiler. For manually implemented systems, me level of insul.Jmentation requi red is dependent on tJle complexity of tlle application, tlle test approach, tlle tar- get environment, available memol}" me support of omer tools, and the time available. Thus, trade-offs must be made in order to deliver a qual ity product on time. In tlle UML models, one must identify important data values, attribut- es, inputs, and control points. For each of tlle e items, add me appropl; ate inSlnlmentation access. The remainder of this article will describe adding instrumentation using tlle translational approach, but the same principles can be applied to manual implementation. Instrumented application architecture The UML test al-chi tecture is broken up in to two components, me dynamic veri- fication user interface (DVUI) and the instrumentation agent. The DVUI is responsible fo r displaying information to tlle user and accepting user com- mands. The DVUI could be replaced with a batch interface for automation. The insu-ume ntation agent acts as the interface between me application and tlle DVUI. The communication mechanism between me agent and DVUI can be any protocol-TCP / IP, RS-232, and so on. The agent supports information marshal ing and commu- nication via generated instrumenta- tion code. It in terfaces with tlle instru- mentation to set and re trieve instance

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems October 2000 Vol13_11