| |||||||
|
We envision a more assured environment where the system is able to automatically determine the suitability of components based on richer semantics (functional in addition to input/output data equivalence) and performance issues. We illustrate the capabilities of TBASSCO in the following bio-surveillance scenario, centered around extensions to our GeoWorlds geospatial situation understanding system which is already an extensive practical application of component-based software development: Imagine that to counter potential terrorist threats, a city deploys bio- and chemical advance warning sensors mounted on mobile vehicles, which can be manned vehicles, such as police cars and bus, or unmanned radio controlled vehicles that regularly traverse the city. Fixed ground-based relay stations, scattered through out the city, gather the sensor readings and forward them to central command. Central command then use these readings to perform a variety of analysis tasks, such as data fusion, plume analysis, and path routing. In that context, consider various likely software development, maintenance and extension actions. Semantic gauges for component selection and linking. Suppose the bio-surveillance designer wants to explore the possibility of replacing the current ArcViewä GIS (Geographical Information System) path routing component with an Internet-based service, such as MapQuestä . TBASSCO performs a semantic compatibility analysis of the components. It determines that the components are functionally equivalent, since both are instances of the route planner class and both contain city-level geographical data. The input data of both components belong to the same abstract class: zero-dimensional (point) geo-locations. The ArcView route planner takes two latitude-longitude coordinates as input, while MapQuest takes two street-addresses as input. TBASSCO determines that a data input wrapper is needed to map latitude-longitude coordinates to street addresses. The system finds that ArcView does indeed provide such a map. However, the output data presents more problems.The output data of both components belong to the same abstract class: one-dimensional (line) geo-location. ArcView represents the line geometrically, while MapQuest uses a combination of text and GIF images to describe the line. TBASSCO searches databases of registered components, determines that it does not have a map to perform the appropriate conversion, and flags the problem. In terms of communicating these analyses to the system designer, the system provides scalar gauges with color-coded regions. A functional gauge signals green to indicate that the two components are functionally equivalent. An input gauge points to the yellow region near the green to indicate that there is a mismatch, but the system has found a potential one-step adapter to resolve the mismatch. The output gauge signals red to indicate a mismatch with no fix available. The red signal triggers the next round of iterative component modifications. The Arcview geographical data displayer, the next component in the link, has to be changed resolve the mismatch. TBASSCO determines that this mismatch can be resolved by replacing the current displayer with the MapQuest geographical data displayer, i.e., a Web page browser. The analyses from these individually gauged findings feed into summary gauges for the entire system to indicate that one adapter component has to be inserted and one existing component has to be replaced. Resource and performance gauges for alternative evaluation. Suppose the designers want to explore performance response of the bio-surveillance network given a simulated chemical release situation. A mobile sensor has detected a possible phosgene gas release near the convention center. Central command deploys additional mobile sensors to the area to determine the spread and concentration of the gas. The collected data, when properly fused, would allow toxic plume analyzers to better predict how the gas will diffuse. The designer wants to determine if the additional sensors are going to overwhelm the fixed ground-based relay station near the convention center. Using deployment and sequence diagrams TBASSCO carries out a performance analysis of the bio-surveillance network. The deployment diagram shows that there are 14 mobile sensors deployed under the relay station near the convention center. An analysis of the sequence diagram of the gas data gathering use case indicates that each sensor generates 5 kilobits of data per second (kbs) for a total of 70 kbs. The resource capacity diagram indicates that the relay stations wireless local area network is capable of supporting 70 kbs, but the connection from the relay station to central command is 56kbs. The communication capacity gauge for this system would swing into red proportionately to indicate the capacity constraint from the relay station to central command. Retrieving candidate components based on their suppliers functional, i/o, and performance descriptors, TBASSCO helps the designer explore options available at this point. He can correct the situation by replacing the sensor components with 4kbs data rate models, by upgrading the link capacity to 70kbs, or by compressing the data relayed by moving data fusion component from central command to the relay station to fuse the data locally. Alternatively, TBASSCO will help generate run-time warning gauges to alert the bio-surveillance operator not to deploy more than 11 sensors per relay station. Run-time gauges can also be used to gather resource usage information to feed back into, and improve, the application performance predictions. For example, based on resource usage information, the designer may discover that the 5kbs provided by the sensor manufacturer is too conservative. In practice, the sensors generate less 5kbs, so the relay station can support more then 11 sensors. Back to Top |
|
|