Embedded Systems December 2000 Vol13_13

Issue link:

Contents of this Issue


Page 150 of 197

QoS property of the system in accor- dance to its re lative importance to the system or project, Subphases of design The ROPES process divides design in to three subphases. Architectural design decisions have broad system- wide cope. Architectural design is bro- ken into five important sub-models: • Subsystem or com ponen t model • oncLirrency model • Distdbution model • Safety and reliabili ty model • Deployment model Although these are each called "mod- els," they are really views or pe rspec- tives of the si ngle system model, con- centrating on some particular aspect. All of these aspects must work togeth- er harmoniously for the system to achieve its overall purpose. Analysis Design Translation Test The subsystem or compo ne nt model has all-eady been touched upon. This defines the large-scale pieces of the system. Each of th ese p ieces wi ll contain (th at is, have a composition relationship with ) small- e r obj ec ts and wi ll organi ze and orchestrate their behavior. At the bot- tom we have primitive or "semantic" objects that do the real work of the system. The classes that define the semantic objects are all defin ed in the domains. The classes that defin e the subsytem mode l are not consid- ered "semantic" because they exist sole ly to organ ize th e run-time TABLE 1 r;tl" _m:Im~m ROP.ES spiral ' Phase Party Oeseri tion 1. Initial project planning, scheduling, resource allocation, concepts, and development strategies, including development plans, configuration management plans, the set of prototypes to be produced, and so on. 2. On-going process Improvement and realignment activities to ensure the process Is working well, risks are being reduced, the architecture is scaling, and so on. Identification of all aspects of the product that are required for correctness. Select ion of a specific solution that optimizes all required quality of service of the system, such as worst case performance, average case performance, reusability, safety, reliability, and so on. Generation of machine-executable code, either via automation or manual generation, and the unit-test of those components. Ensuring that the prototype is constructed properly of its various components and subsystems (integration) and achieves its specific set of requirements (validation) . In-Circuit Emulators Dinkumwace, Ltd. Genuine S ojtJvare Dinkum C++ for GCC/Linux iC2000 Power Emulator Preserve your investment with universal emulators from iSYSTEM. From low-cost BDMIJTAG to high-end full-function ICEs. Support for 68HC05 08 091 1 121 6, 68K, 683xx, MCORE, MPC, 8051, 80x86, C500, Z80/180, CR16, PIC, ST7, and many more. ~ Call Toll Free 888 543-5300 1 SYSTEM Includes the Dinkum C99 Library Comes ready to run with GCC 2.95.2 on either SPARC Solaris or PC Linux Dinkum® C99 Library A complete implementation of the ISO /IEC 9899: 1999 Standard C Library. The Dinkum C99 Library has rich the extensive additions required to conform to the C++ Standard. math and locale support, and has ~. ' .. 9 *Dinkumware & Dinkum are Registered Trademarks of Dinkumware. Ltd. Solaris & SPARe are Registered Trademarks o f Sun Micorsystems , lne. Embedded Systems Programming DECEMBER 2000 149 Dinkum C++ for GCC / Solaris

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13