This assignment is pretty open, and there are may possible answers. Grading is based on clarity (of explanations and writing), coverage (of the required questions and issues) and reasonabless (of the proposed solutions).

Marking scheme: (1) 3 for each box, total 36, (2) 20, (3) (a) explanation 14, (b) architecture 30, total 44: grand total 100.

1. The Mary Shaw paper "Some Patterns for Software Architecture" describes a number of software architectural styles identified from industry applications: http://www.cs.cmu.edu/afs/cs/project/vit/www/paper_abstracts/PLoP95.html

   This paper provides an alternative source to the readings assigned from Bass/Clements/Kazman.

   In the table below, give an example of a type of application that would be best designed using the given architectural style. (You may draw from the applications presented in class.) For each case, consider the quality attributes of running time, verifiability, and reusability (i.e., replacing existing components, portability, adding new components) and provide brief comments on how those qualities are affected by the architectural style.

   There are lots of possibilities for this. The type of application should not be too broad (e.g. "operating system", "communications software") because in a broad type there are too many possibilities of best design. But "layered operating system" (e.g. Win 2000, Tunis) is fine.

   It is tempting, but wrong, to confuse "verifiability" (the quality of being seen to be correct) from "reliability" or "robustness" or various other qualities of being correct in fact. Comments about verifiability should be directed at the question how easily can it be verified that the application is reliable / robust / safe / live / correct?

   The quality of reusability includes replacement, extension, and actual reuse (see above).

   Architectural Style	Your Example	Comments on Reusability	Comments on Running Time	Comments on Verifiability
   Layered	graphics rendering, layered protocol communications, browser/download software	In theory, layered architecture should delimit scope of change and allow a layer to be reused within a configuration with other layers In practice, this doesn't happen unless the layer is implemented to a standard (external) protocol, because nothing else prevents the interface between adjacent layers from becoming unreusably specialized. Porting is in theory eased by the fact that upper layers are abstractions of lower layers, and so it is expected that only the lowest layer is dependent on the platform.	It's important to keep an eye on the hidden overhead (runtime and space) of propagating requests and data up and down the layers. This can lead to unusable or delicately tuned designs.	Similar comments apply as for reusability.
   Data Centred	object-oriented operating system (e.g. OS/2, AS/400). Any passive database application (e.g. management information system, accounting, SAP, etc.)	Can produce the least resuable whole programs (when they tend to be specialized to a clerical task). COTS components with standard interfaces (e.g. SQL) can be replaced with a little less effort (e.g. FoxPro -> Oracle -> DB2). New components are easily added because the protocol doesn't require them to be aware of the existance of other components, only the database.	A data-centered architecture, e.g. a blackboard-style system, can keep as low as possible the overhead of sharing data. The blackboarsd or file system can cache frequently-used data internally. If the repository is distributed or centralized in a distributed architecture then there data transfer can be a bottleneck, of course.	In theory data centered architectures can be highly verifiable if most of the application is just pushing data around: the algorithms are simple. The above can apply to the basic structure of the data repository or data architecture in practice: but transformations, processes, and reports are usually unspecified and unverifiable as usual
   Event Driven	embedded control software (auto, aero, consumer electronic, etc.), video games, GUI managers, applets	There is a general tendency in event-driven and embedded software to be unreusable because the overriding concern is usually response time. Adding new responders-to-events is usually easy as the central dispatcher of an event-driven design contains dynamic tables of components which require control when events occur. Porting to another platform is possible in inverse proportion to the degree to which the lowest-level (drivers) has been allowed to affect the overall design.	Predictable real-time response is generally the paramount concern. It is made possible by generally requiring responders to perform tight little effects, possibly creating some new events, and then completing, so that the total time required for the response is limited and predictable.	This class of software is the only one which is industrially subject to real verification. The reason is, that the state space of embedded event-driven systems, while huge, is begininng to be within range of exhaustive or heuristic-exhasutive automatic verifiers. You need to formalize the required behaviour somehow so that the model checking software has something to do.

2. Suppose you have three components, A, B, C, that you are trying to compose into a system as shown in figure 2 (below). One of the commonest problems when composing components is the fact that often they do not agree on how the data should be represented. Suppose you have the following characteristics for your system:
   1. component A is written in-house and you have the source for component A
   2. you don't have the source for components B and C
   3. the format of the output from A follows a company wide standard
   4. the output from B and C are not in the company standard format
   5. the input to C is in the company standard format
   6. component A may be replaced in the future by a third-party component
   7. all three components work independently
   8. the final output from the system has to be in the company standard format
   9. the company standard format may change in the future

   The Mary Shaw paper, "Architectural Issues in Software Reuse: It's not just the Functionality, It's the Packaging" http://www.cs.cmu.edu/afs/cs/project/vit/www/paper_abstracts/Packaging.html describes several techniques for resolving data mismatches between components. Fill in the following table showing what choices you would make to get the components of this system working together (There is no one correct answer.)

   Shaw's paper contains 9 techniques for handling form mismatch between two components say A and B. It's not always quite clear how they differ. But note that a key issue is that neither components is isolated, and either could be involved in other interactions as well. So changes are delicate.

   1. Rewrite one component to use the other's form.
   2. Publish an abstraction of one component's form, for the other to use.
   3. Write a run-time translator from A's form to B's.
   4. Add functionality to to negotiate on a common form at run time
   5. Add functionality to B to accept A's form externally
   6. Write standalone or on-demand translators for B to use, reading A's form.
   7. Introduce an intermediate (exchange) form and make them both use it.
   8. Wrap or adapt A using adapter design pattern, showing B's form externally.
   9. Maintain parallel versions of either or both. (This is similar to (1) except allowing for the situation in which one or both is also required to interact in its native form.)

   Certain additional assumptions are needed: basically the input and output of all three components are needed.

   As long as the proposed techniques are justified in a reasonable way, and produce the right input/output form match, then almost any combination of them is a viable solution, at least until we know more about the situation.

   For example, C can get a standalone translator on input, B can get one on output, and we can create two run-time filters to translate C's output to company-standard and A's output company standard to B's input.

   It would be inappropriate to choose a solution which risked excessive cost, such as

   1. Total rewrite of A (which might soon get trashed anyway)
   2. Forcing everything to use the company standard
   3. etc. etc.

    

3. Courtesy of Maj.Greg Phillips, RMC) In response to complaints about a lack of intelligence analysis capability, the Department of National Defence initiates a multi-billion dollar project called RABID CALF: the Really Astoundingly Big Intelligence Data Collection and AnaLysis Facility. By means of a highly structured requirements elicitation and validation process (performed by a bored clerk on a cocktail napkin over lunch) the following set of critical information system requirements are identified:
   • Intelligence information data elements will be received in three formats: high resolution reconnaissance photographs, voice recordings, and text-based field reports.
   • Each received data element must be automatically preprocessed (e.g., the voice recordings will be filtered to remove background noise). Each data format will require a different form of preprocessing.
   • Each data element must be manually validated and have "meta-data" attached to it. This might include, for example, keywords, locations, times and dates added to reconnaissance photographs.
   • All data elements and associated meta-data are to be retained in an online intelligence library.
   • Due to the volume of data, much of the analysis will be performed by "intelligent" software. There will be a large number of software agents constantly analysing the data and adding their results to the online library. The number of agent types is expected to increase over time as new software is developed. Initial software agent types are:
     • image feature recognizers, which will detect and identify items of interest in reconnaissance photographs;
     • transcribers, which will produce textual versions of voice recordings;
     • collators, which will identify and group related images, voice recordings, and field reports based on meta-data, contents, and the results of other analyses; and
     • trend analysers, which will identify significant trends over time or space.
   • A separate interface will allow human intelligence analysts to browse and search the library. It will direct their attention towards elements or groups of elements identified as interesting by the software agents. Based on their analyses, the human analysts may add further information to the library.
   • Periodically, a high-level summary report must be generated for the Department's senior intelligence officer, the Director Of Stuff You DOn't talk about (DOSYDO).

     After you make the mistake of beating her at golf one afternoon, your boss tasks you with designing a high-level architecture for RABID CALF's information system.

   1. Identify an appropriate architectural style to use as the core architecture for the system. Justify your choice. If there are identifiable subsystems with other architectural styles, explain what these are. (This explanation should be around a half page in length.)
   2. Produce a high level architectural diagram for the RABID CALF information system. It must include all components necessary to carry out the functions indicated in the requirements. Clearly label each component and connector in such a way that it is clear what role the component or connector is playing. See figure 1 for an explanation of the symbols to be used in your diagram.

   The basic outline of the architecture should include:

   • filter designs for accepting the various kinds of input up to (not including) user verification
   • data repository for handling user verification, because verification can't really be done in real time, holding up the input pipe
   • a black-board style central repository or some other way to handle registration of agents and dsitribution of notification to them when certain kinds of data arrive
   • indication of where user intervention is used

   Here is a possible diagram.