CS446 [CS646]: SOFTWARE SYSTEM DESIGN

CS446 [CS646] Software Design and Architecture, Fall 1997

EXAMINATION

Prof Ric Holt, Department of Computer Science, Waterloo University

Tuesday, Dec 9, 1997

MARKING

1. ARCHITECTURAL EVALUATION.    [25 points]     _____

2. DESIGN PATTERNS.             [20 points]     _____

3. ARCHITECTURAL ALGEBRA.       [10 points]     _____

4. IMPLEMENTATION STYLE.        [10 points]     _____ 

5. BOOKSHELF.                   [15 points]     _____

6. OAM-CU MESSAGE PASSING.      [10 points]     _____

7. STRUCTURAL STYLE.            [10 points]     _____

   TOTAL                       [100 points]     _____

1. ARCHITECTURAL EVALUATION. Kazman's SAAM (Software Architecture Analysis Method), as described in his paper presented in class, provides a five step methodology. Kazman describes these steps as follows:

Step 1. Characterize a canonical functional partitioning for the domain.
Step 2. Map the functional partitioning onto the architecture's structural decomposition.
Step 3. Choose a set of quality attributes with which to assess the architecture.
Step 4. Choose a set of concrete tasks which test the desired quality attributes.
Step 5. Evaluate the degree to which each architecture provides support for each task.

Using the OAM system which you implemented as an example, you are to consider that you have already carried out these five steps. Describe the results of carrying out these steps:

Step 1. [4 points] Describe the functionality of your system (OAM) partitioned into subfunctions. (What does it do?)
Step 2. [5 points] Using a diagram, give your system's architecture, showing how the subfunctions from Step 1 are allocated to the parts of your architecture.
Step 3. [4 points] Give some attributes that your architecture should provide good support for. (For example, you may decide that your system should be easily expandable to support future changes in the means of operator access.) Give at least two such attributes.
Step 4. [4 points] Choose at least one concrete task for each attribute from Step 3 to be used to test your architecture to see how well it satisfies that attribute. (For example, you may pick the task of providing more than one operator console, as a test of the attribute to support changes in operator access.)
Step 5. [4 points] For each task from Step 4, discuss how well your architecture satisfies the task.

[4 points] In terms of Garlan & Shaw's list of architectural styles, which of them most closely describes the style of your architecture (described in Step 2).

2. DESIGN PATTERNS. Gamma et al have popularized the idea of software design patterns. [5 points] Using a key example, explain what is meant by a design pattern. What advantages are provided by these patterns?

[15 points] Compare and contrast these three design patterns, as they are defined by Gamma et al: Facade, Adapter and Wrapper. Use diagrammatic notation (explain what the notation you are using) in describing these.

3. ARCHITECTURAL ALGEBRA. Here are some tuples (in RSF notation) from a representation of a simple software architecture:

    contain S A
    contain S B
    contain S C
    contain A x
    contain A y
    contain C z
    store x y
    store y z
    fetch x z

Part A. [4 points] Draw a clear diagram illustrating this simple architecture.

Part B. [3 points] Consider relation M defined by

    M = (contain * (store + inv fetch))+

where

        *    means relational composition,
        +    (infix) means relational union,
        inv  means the inverse (or backwards) relation,
        +    (postfix) means transitive closure (non-reflexive).

(These are the same operators that Grok supports.) Enhance your previous diagram to show relation M.

Part C. [3 points] List all the tuples (in RSF notation) in relation M.

4. IMPLEMENTATION STYLE.

[5 points] It is a common practice in C programming that each dot-C file (except for the main program) has a corresponding dot-H file. Explain what should appear in each of these files. Explain the architectural advantages of this practice, in terms of principles such as information hiding.

[5 points] This practice is not enforced by standard software tools such as C compilers and Unix linkers. Describe a set of hypothetical tools, perhaps based on those provided by PBS, that could be used to enforce this practice. Give enough detail so that it is clear how these tools would be constructed and how they would be used in practice.

5. [15 points] BOOKSHELF. In extracting the concrete architecture of your implementation of OAM, you used the PBS software tools. Using a diagram, describe the process (step by step, including a description of the use of software tools), how your team proceeded to create landscapes (and/or a bookshelf) for your system. Describe any transformations of the facts that were extracted from your system.

6. [10 points] OAM-CU MESSAGE PASSING. Recently, the SX4 system has been implemented within a small metropolitan business having all 9 exchanges and each with 60 telephones. Consider a case where phone number 451 made a call to 633 lasting 5 minutes on today's date. The CU has now sent a message with this information to the OAM. Explain the sequence of events that occurs in order to bill a long distance call in your OAM implementation. Also, briefly describe how your OAM implementation interprets this message in the context of message specifics and flow of information within your modular decomposition.

7. STRUCTURAL STYLE. This question involves visibility constraint rules used for architecture; you will apply these rules to software written in Hehner's PP notation.

Hehner's PP (Predicative Programming) approach to FM (formal methods) uses a notation that can be interpreted as either a program (when sufficiently refined) or a specification. This means that a PP program can be interpreted to be a piece of software, which is potentially executable. A PP program is divided into parts, which are successively divided into parts, so the program's structure is a tree.

Within PP, there is a special notation called a "frame" that limits to access to parts of the program to other parts (frames are analogous to import lists). The frame for each part p gives a list of items outside of p that can be accessed inside p. The frame for each part p is allowed to list parts which are p's siblings or parent or which are listed in p's parent's frame. Within a subpart q of part p, q is allowed access to q's siblings (and to itself), to p, and to parts listed in p's frame.

AN EXAMPLE. The entire program, D0, is divided into parts called D1 and D2. Part D1 contains x1 and y1; D2 contains y2.

In the program, x1 accesses y1 and D2; y2 accesses itself. There are no other accesses.

D1's frame lists D2, so D1's contained parts (x1 and y1) can access D2 as well as D1 and each other (as well as themselves). D2's frame is empty, so y2 can access only itself and D2. The frames for all other parts (D0, x1, y1, and y2) are all empty. Note that upper level parts can also have accesses, for example, D1 can access D0.

Part A. [2 points] Draw a clear diagram that represents this example, illustrating the following relations in program D0:

p C q -- part p directly contains (C) part q
p A q -- part p accesses (A) part q
p L q -- part p's frame lists (L) part q

Part B. [2 points] For this example, give the values of each of the relations, A, L and C, by explicitly listing the tuples in each.

Part C. [3 points] On another copy of the diagram (from Part A), draw all the allowed accesses and label them A' (based on the rules described above and the frames in the example).

Part D. [3 points] Give architectural style rules that precisely describe the allowed accessing of parts by other parts within a PP program. These rules place constraints on the A relation. You can give these rules in ASF diagrammatic notation or as an inequality which has the form:

    A <=  Some expression involving A, L and C etc, where
            <= means "subset"

You may also want to use P as the inverse of C, and S0 as the reflexive sibling relation for C.