0707.321 Principles of Software Engineering

Homework 3

System Design

Due Date

Both Sections: Tuesday, April 2

Form of Submission

Homework can submitted via email or printout by deadline.

Preparation

This assignment will exercise your knowledge of generic software architecture models. Before you begin, do the following:

Assignment

    System Architectures (Ch. 10-11)

  1. Giving reasons for your answers (answers without reasons will be severely penalized), suggest an appropriate structural model for each of the following systems: [5 points each]
    1. A computer-controlled home-management system, with control over security, temperature, humidity, lighting, cleaning, etc.
    2. A multiuser, networked flight simulator game, with multiple users controlling virtual planes in the same "space".

    1. The most appropriate model is an active repository model, with each of the subsystems (security system, temperature measurement, heating/cooling, etc.) placing information in the repository for other sub-systems to use. Under this model, the temperature sensors, for instance, would publish temperature measurements to the repository, and the heating and cooling systems, could "react" to these reports appropriately. Using a centralized active repository (or "blackboard") allows for the easy addition/subtraction of components. In some sense, the "smart house" is like a robot, sensing and reacting to its environment.

      Partial credit to any distributed model, with significant credit going to a peer-to-peer approach.

    2. Some sort of distributed model is required here, with each plane (player) being a client in the distributed network. The architectual challenge here is to propose a distributed framework that best supports the game mechanics. Since all clients (that is, planes) are flying in the same space, they all have to the same internal representation of the (virtual) airspace. This leads one to propose a client/server model, where the centalized server maintains the definitive model of the airspace state and communicates the details back to the planes as required. (For efficiency reasons each client would maintain a local copy of the airspace local to their location.) A more ambitious design (meriting extra credit) would propose some sort of hybrid peer-to-peer scheme, where the players' clients can interact directly with each other when necessary. This feature would be particular useful for implementing "dogfighting", where direct communication would be faster (and more responsive).

  2. Design (and draw) an architecture based on your answers (make reasonable assumptions about the system requirements when necessary). [5 points each]

    [Your answers to this question will be graded for consistency with your answers in (1), and so may differ from those provided here.]

  3. Giving reasons for your answers (answers without reasons will be severely penalized), suggest appropriate control models for each of these systems. [5 points each]

    1. Each of the units must be have autonomous control; able to sense (eg., temperature, humidity, etc.) or react (eg. heat, cool, sound alarm, call fire department) independently. Thus an event-based control model (broadcast) over the system is appropriate.
    2. Since all the player (airplanes) must be informed of changes to the shared state, a broadcast model is appropriate. (If a peer-to-peer component is part of the design, then some mention that communication will be looked for as well.)

    [Your answers to this question will be graded for consistency with your answers in (1), and so may differ from those provided here.]

    Design with Reuse (Ch. 14)

  4. Explain why the savings in cost from reusing existing software is not simply proportional to the size of the components that are reused. [10 points]

    The cost savings from reusing components are the cost savings from not having to write (and test) that component. These savings are more-or-less proportional to the component size: the larger the component, the greater the cost saving.

    But one must also consider the new costs associated with reuse: the costs of searching for and understanding the components chosen for reuse, and the costs of adapting other parts of the system to accommodate the reused components. These costs do not scale with the size of the component. For small components, these new costs may be considerable compared to any savings. This reduces the total cost saving, perhaps even making reuse more expensive than creating the component from scratch.

  5. Explain why it can be more practical to tailor a system's requirements and design with the use of existing components in mind, rather than searching for reusable components after the system has been specified and designed. [10 points]

    In specifying and designing a system, you are restricting the range of components that can be used to implement it. If the search for existing components to serve in a system is deferred until after the system has been specified and designed, the likelihood that any preexisting components in this range (that is, components fitting into the design) can be found is relatively small.

    What are more likely to be found are components that are "close" to what is required, necessitating changes to the design (or to the components), if component reuse is to be applied as a strategy. These accomodations add extra costs, and offset the benefits of using preexisting components as part of the system implementation.

    Better would be to sketch a design, look for candidate components, and then, with these components in mind, to "firm up" the design. This strategy is much more likely to result in being able to reuse existing components.