EETimes

Embedded Systems December 2000 Vol13_13

Issue link: http://dc.ee.ubm-us.com/i/71850

Contents of this Issue

Navigation

Page 147 of 197

Object analysis also reifies these objects into classes, identifies the structural relations among them (associations of various kinds and generalizations), and defines the collaborative and individual behavior. application of a simple rul e, which applies recursively at evel-y descending level of abstraction: The structural model at level n is adequate if and only if all of the scenarios defined at level n- l can be realized using the new, more detailed set of abstractions. This means, simply, that a subsystem structural model is adequate if all of the system level scenarios (defin ed using the actors' and tJ1e system) can be real ized using the newly identified subsystems. These refin ed scenarios tJ1en show the same set of scenarios as described a t the previous leve l of abstraction, but also how the subsys- tems interact in addition to the system and the actors. The next step in systems engineer- ing is to break tJ1e subsystems down in to single-disciplin e components (softwal-e, mechanical, elecu-onic, and chemical) and understand how mese single-discipline components interact. This is commonly called me "hard- ware-software decom posi tion." In terms of me software, the next subphase, object analys is, identifies the objects tJu t are essen tial to the problem being solved. For example, if you' re building a guidance and navi- gation system or subsystem, concepts uch as waypoint, vectors, positions, and so on are e sential and would be expected to appear in any acceptable solution. This analysis is done one use case at a time. That is, each use case is realized by a set of collaborating objects. The ide ntifi cation of th e obj ects is most often done a use case at a time. Object analysis also reifies these objects into classes, identifies the structural relations among tJ1em (asso- ciations of various kinds and general- izations), and defin es the collabora- tive and individual behavior. An alternative approach is to speci- fy me objects a domain at a time. In ROPE , a domain is an area of subject matter with a common vocabulary. Typical domains in real-tim e and embedded systems are user interface, device I/O, alarm manageme nt, and bus communications. Every semantic c1as in the system falls into a single domain ; in fact, all generalization hierarchies fall within a single domain as well. Domains are modeled using UML packages and may be internally decomposed in to subpackages to allow them to be morĀ·e easily man- aged. Domains organize what ROPES refers to as tJle logical model-the types and classes of a system, that is, things that exist at design time. This is dis- tinct from the physical model, which, as we shall see late r, organizes the objects, subsystems, and compo- nents-things that exist at run-time. If ana lys is defin es th e essential properties of a system, design picks a single particular solution. Design is all about optimization against system and proj ect qua li ty of service require- ments . Requirements come in two fla- vors: fun ctional "capabili ty" require- ments and quali ty of service (QoS) requiremcn ts. QoS requiremen ts defin e how well a capability is to be achieved. Designs have to optimize all the important QoS requirements of a system simul taneously in accordance with their respective importance in the particular system or proj ect. In some cases, worst case pe.-formance and high safet y may be crucial-such as in the development of a controller for a nuclear power plant or an avion- ics flight conu-ol compute r system. In other proj ects, time to market and reusability may be more important. A good design optimizes each important 146 DECEMBER 2000 El11bedded Systel11s Progral11l11ing

Articles in this issue

Archives of this issue

view archives of EETimes - Embedded Systems December 2000 Vol13_13