Global 14 KWIC Software Architecture v1.

CS/SE 6362 Advanced Software Architectural Design (Spring 2011)

K.W.I.C.
(Key Words In Context)
Software Architecture
Submitted to:
Dr. Lawrence Chung
Associate Professor,
Department of Computer Science,
The University of Texas at Dallas,
Richardson, TX -75080

Team Name: Global 14

Date Version Description Author

2/2/2011 1.0 Initial draft Global 14
2/17/2011 1.1 Added development view Global 14
2/27/2011 1.2 Introduced SAAM process Global 14
3/7/2011 1.3 Added ADT2 architecture Global 14
3/23/2011 1.4 Added traceability Global 14

Developer’s Website: http://utdallas.edu/~sas071100/SAD/

1
Global 14 KWIC Software Architecture v1.4

Contents
Introduction................................................................................................................................................3
Brief Introduction to KWIC System.....................................................................................................3
Purpose..................................................................................................................................................3
Scope.....................................................................................................................................................3
Definitions..............................................................................................................................................3
Architectural Representation...............................................................................................................3
Architectural Goals and Constraints...................................................................................................3
Process Architecture................................................................................................................................4
Methodology..........................................................................................................................................4
Process Architectural Design..............................................................................................................5
Architectural Candidates..........................................................................................................................6
Pipe-and-Filter.......................................................................................................................................6
Abstract Data Type 1............................................................................................................................7
Abstract Data Type 2............................................................................................................................9
Implicit Invocation...............................................................................................................................10
Scenarios.................................................................................................................................................13
Scenario Interactions..........................................................................................................................14
Selected Architectural Design...............................................................................................................15
Traceability matrix between requirement specification and architectural specification.................15
References..............................................................................................................................................17

2
Global 14 KWIC Software Architecture v1.4

Introduction

Brief Introduction to KWIC System

KWIC is an acronym for Key Word In Context. The KWIC index system accepts as input an
ordered set of lines, each line is an ordered set of words and each word is an ordered set of
characters. Any line may be “circularly shifted” by repeatedly removing the first word and
appending it at the end of the line. The KWIC index system outputs a listing of all circular shifts
of all lines in alphabetical order. A full description of the system is specified in Shaw and
Garlan’s book [1].

Purpose
This document provides an architectural overview of the KWIC system produced by Global 14.
Multiple architectural views are present to highlight particular aspects of the system as seen
from various perspectives.

Scope
This document serves as a complete high-level architectural specification of the KWIC system.
It is not intended to illustrate the domain of the system or the details of its implementation.
Rather, its scope is bounded by the system’s constraints and its various views.

Definitions
Circular shift – operation in which a line’s first word is removed and appended to its end

Line – an ordered set of words

Word – an ordered set of characters

Architectural Representation
This document presents the system’s architecture in the form of “4+1” views, including the use-
case view, logical view, process view, development view, and physical view. These views are
based largely on the system’s underlying model as expressed in Unified Modeling Language
(UML).

Architectural Goals and Constraints

 Performance must not suffer from architectural limitations.
 The system architecture must be mostly reusable.
 It must be possible to enhance the system architecture with additional functionality while
encountering few if any complications regarding existing components.
 The customer has requested an object-oriented system. The need to evaluate of other
systems is demonstrative in nature rather than selective.

3
Global 14 KWIC Software Architecture v1.4

Process Architecture
Methodology
Global 14 used Software Architecture Analysis Method (SAAM) as a basis upon which to
systematically decide upon the ideal architecture for this project. The purpose of this practice is
to formally weigh the benefits and drawbacks of four architectural candidates, thus providing a
weigh to objectively determine the best design.

There are six main steps in the SAAM process [2]. These are:

1. Develop scenarios

2. Describe candidate architecture

3. Classify and prioritize scenarios

4. Perform scenario evaluation

5. Assess scenario interaction

6. Generate overall evaluation

The candidate architectures in step two are described in detail immediately following the
Process Architecture section of this document.

Scenarios were developed in step one and elaborated upon in steps 3-5 regarding likely
potential uses of the KWIC system and its components. These are listed following the
description of candidate architectures. In this section, these scenarios are evaluated with regard
to individual architectural candidates.

The overall evaluation of step six immediately follows the assessment of scenario interaction.
The ideal architectural candidate is identified in this section, as well as rationale explaining the
reasons for our selection.

4
Global 14 KWIC Software Architecture v1.4

Process Architectural Design

Team members assumed the following roles for analysis and design:

Team members Role

Jay Laughlin
Blake Jensen Requirements Engineer
Hendra Sutedja
Paul Asere
Sam Shaw Architect
Zhenzhon Sun
Doug Beach
Luis Furtado Development Engineer
Abhishek Kumar
Caitlin Fowler
Tao Ran Quality Assurance Engineer
Sean Wilson
Frederico Araujo
Project Manager
Owolabi Legunsen

The above diagram depicts the relationships between roles with respect to the process
architecture. Black arrows indicate traceability between products of effort, while blue arrows
indicate coordination.

5
Global 14 KWIC Software Architecture v1.4

Architectural Candidates
Three candidates were considered with regard to selection of an architectural style.
These are the pipe-and-filter, abstract data type, and implicit invocation solutions.

Pipe-and-Filter

Figure 1: Pipe-and-filter solution

The first and simplest candidate for architectural style is the pipe-and-filter solution. With
respect to the above diagram, each rectangle represents a “filter,” or component of data
processing, while each arrow represents a “pipe” that carries data between filters.
Dashed lines represent system input and output access, while system devices are
represented by ellipses. No filter is aware of any other filter.

Of the four filters in the KWIC system, the first, “Input,” is responsible for reading data
from the input source. It then produces as output the contents of the input source as a
series of lines.

“Circular shift” takes these lines as input and generates all the circular shifts that can be
constructed from them. These circular shifts become output for the next filter.

The third filter, “Alphabetizer,” takes as input a series of circular shifts then sorts them
into alphabetical order. These alphabetized circular shifts are produced as output.

“Output,” the fourth and final filter, reads a series of alphabetized circular shifts and
writes them to the output destination.

Constraint

All filters must be independent entities: in particular, they should not share state with
other filters. And also, filters do not know the identity of their upstream and downstream
filters.

6
Global 14 KWIC Software Architecture v1.4

Pattern

Abstract Data Type 1

In this style, which is based on data abstraction and object-oriented organization, data
representations and their associated primitive operations are encapsulated in an
abstract data type or object. In ADT architecture design, the system can be viewed as a
collection of ADT objects. Each ADT includes data objects, operations on data objects
and essential properties of operations algebraic equations. Each ADT object also
provides interfaces for other objects in the system, the communications can be
achieved by sending message or passing parameters. An object is responsible for
preserving the integrity of its representation that is hidden from other object. So data is
no longer directly shared by the process components. Instead, each module provides
interface, other components access data only by invoking that interface (information
hiding).

The second solution decomposes the system into a similar set of five modules.
However, in this case data is no longer directly shared by the computational
components.Instead, each module provides an interface that permits other
components to access data only by invoking procedures in that interface. (See

7
Global 14 KWIC Software Architecture v1.4

Figure, which illustrates how each of the components now has a set of procedures
that determine the form of access by other components in the system.)

Component: Object & Data

Module Input

In the Figure above, Master Control passes control to input, input then reads data lines
from the input medium and stores data lines by calling the “Setchar” of “Line Storage”.

Module Line Storage

After module Input passes control to module Line Storage, this module will work to
create, access and possibly delete characters, words and lines. It provides interface “
setchar” which is used by module Input, and interface “Char” and “Word” which are
needed by next module Circular Shift to reconstruct all the lines. Actual representations
and processing algorithms are hidden.

Module Circular Shift

This module creates a circular shift for multiple string lines. Circular Shift means
repeatedly removing the first word and appending it at the end of the line until a circular
is reached. After master control passes control to module Circular Shift, this module will
start procedure Setup, which gets titles using Char and Word of Circular Shift. And
Setup and CS-Setchar are routines to construct circular shifts. This module also
provides interface CS-Char and CS-Word, which are needed by next module –“
Alphabetic Shifts” to reconstructed the circular shifts of the lines.

Module Alphabetic Shift

This module creates alphabetized lines of the circular shifts using CS-Char and CS-
Word provided by last module, and provides routines to access shifted lines in
alphabetical order.

Module Output

This module calls “i-th” routine provided by last module to produce output lines in
alphabetic order and output the results to output medium.

Connections / Glues

• Subprogram Call: One module can access procedures in other modules through this
routine.

8
Global 14 KWIC Software Architecture v1.4

• System I/O: This refers to Input from the input medium or Output to the output
medium.

Constraint

Components access data only by invoking other component’s interface (information hiding).

Pattern

Subprogram Call

System I/O

Direct Memory Acess

ddsdsdada
Abstract Data Type 2

Access Attributes

System I/O

In this ADT(OO) architecture, Master Control accepts the inputs lines from inputs directly and
creates KwicIndices which contain the number of lines. Master Control then invokes the Data
Store through Set.

In Data Store each input is analyzed and stored in two buffers based on Wordlength and
WordCharacter. The contents of these two buffers are available to the Word module.

Word is invoked by Master Control through Set. Word uses inputs from WordLength and
WordCharacter to generate offsets.
9
Global 14 KWIC Software Architecture v1.4

Circular Shift is invoked by Master control through the Set interface. Shifts constructs a circular
shift of the words based on the KwicIndices supplied to it by master control and offsets supplied
to it by word through an interface. However the words are not reconstructed like in the previous
architecture rather the shifts generated are just indices.

Alphabetizer is invoked next after circular shift. Alphabetizer takes the shifts generated in
Circular shift and sorts them alphabetically. Again this is just a set of indices and no
reconstruction of actual input.

Finally Master Control invokes output. Output reconstructs the alphabetized circular shifted
words by accessing the shift and sort interfaces and also using the KwicIndices supplied to it by
master control.

The major advantage of this architecture is that data replication is eliminated. This design has
the same constraints and patterns as the first abstract data type design.

Implicit Invocation

Figure 3.0 Implicit Invocation

This architectural style combines both Shared Data and Abstract Data Type; however the
interface to the data is abstract. A key feature of this style is that computations are invoked
implicitly as data is modified as a result of this interaction is based on an active data model.
The idea behind implicit invocation is that instead of invoking a procedure directly, a component

10
Global 14 KWIC Software Architecture v1.4

can announce (or broadcast) one or more events. Other components in the system can register
an interest in an event by associating a procedure with the event [1].

Input

In the Figure above, Master Control passes control to input, input then reads data from
the input medium and implicitly invokes (triggers) the insert operation. The insert
operation stores each new line read to a line buffer called I-lines.

Circular Shift

Insert invokes circular shift implicitly by announcing an event upon its completion. Circular Shift
registers an interest in this event. Once this event is announced, Control invokes all of the
procedures that have been registered, thus an event announcement cause the invocation of
procedures in other modules.

Circular Shift through the first i-th operation reads I-lines and produces circularly shifted lines
which are stored in a separate line buffer called CS-Lines.

Alphabetizer

The i-th module performs two operations. The first operation stores the circularly shifted lines
into the buffer, while the second operation implicitly invokes the alphabetizer module in a
manner similar to the description above. The alphabetizer through this second i-th operation
reads CS-lines and produces alphabetized lines which are stored in a separate abstract line
buffer called A-lines.

Output

The output module continuously checks to see when an output is available. It accesses A-lines
and prints out the alphabetically sorted circularly shifted lines to the output medium.

Master control explicitly invokes input and output.

Connections / Glues

• Subprogram Call: One module can access procedures in other modules through this routine.

11
 Global 14 KWIC Software Architecture v1.4

• Implicit Invocation: One module announces an event, which in turn “implicitly” invokes other
module procedures registered to be associated with the event.

• System I/O: This refers to Input from the input medium or Output to the output medium.

Constraint

Computations are invoked implicitly as data is modified, based on active data model.

Pattern

Subprogram Call

System I/O
Implicit Invocation

12
Global 14 KWIC Software Architecture v1.4

Scenarios
The following scenarios pertaining to the KWIC system are organized in order of descending
priority:

1. Elimination of noise words or unwanted lines

a. Indirect
b. ADT1 and ADT2 allow for this with no problem, as the elimination component can be
safely added to the end of the Output process. II incurs slightly more significant
penalty to performance and difficulty because the invocation control must be taken
into account. Pipe-and-filter does not well support user interaction. Thus, the ease of
inserting the function is displaced by the difficulty of accounting for user interaction.

2. Modification of internal representation of input/data structures

a. Indirect
b. If data representation is changed, for ADT1 circular shift and alphabetizer must be
updated accordingly. However, these changes are straightforward and minor, since
data storage is somewhat arbitrary in ADT1. II incurs a significant penalty for this
modification because all contents of the control must change accordingly. Pipe-and-
filter and ADT2 are ideal in this predicament because no component depends on the
internal representation of data in any other component.

3. System ported to different platform

a. Indirect
b. For all four architectural candidates, the input and output medium must be accounted
for when porting to a different platform. In addition, Master control must be updated
for ADT1, ADT2, and II, but pipe-and-filter is indifferent to this.

4. One line at a time processing

a. Direct
b. For ADT1, each line being read requires that the Master control explicitly invoke
each component, though space requirements and time requirements for alphabetizer
are not significant. II is similar in that the control must perform invocation of each
component. However, the time requirement is more substantial because of the
control’s detection overhead. Pipe-and-filter also incurs overhead through its
invocation mechanism. ADT2 performs best in this regard, since data is stored from
lines into words for immediate, direct access by the Circular Shift component as
addressed by offset.

5. Components reused in new system

a. Indirect
b. The pipe-and-filter candidate presents little difficulty in reuse of its components.
Since each is well encapsulated, the alphabetizer for instance can be moved to

13
Global 14 KWIC Software Architecture v1.4

another pipe-and-filter system with ease. Implicit invocation and ADT1 require
adaptation of the new operating environment to account for the circular shift’s “ith”
operation, and the cs-char and cs-word interfaces, respectively. ADT2 scores lowest
on this scenario, as it will only seamlessly adapt to a new operating environment in
which the data storage component is similar.

Scenario Interactions
Following are quantitative evaluations of the scenario interactions based on the above
evaluations:

ADT1 ADT2 Implicit Invocation Pipe-and-filter

A ++ ++ + +-

B +- + - +

C + + + +

D + ++ -- --

E + +- + ++

++ = 100% + = 75% +- = 50% - = 25% -- = 0%

1. ADT1 75%
2. ADT2 80%
3. Implicit Invocation 50%
4. Pipe-and-Filter 60%

14
Global 14 KWIC Software Architecture v1.4

Selected Architectural Design

Based on our evaluation of the scenarios and their interactions with components of the
proposed architectural design candidates, we find the second abstract data type design best
suited as a basis upon which to construct the KWIC software.

Three major non-functional requirements dominate our analysis: enchanceability, reusability,

and performance. The scenarios we have used to evaluate architectural candidates represent
the need for these requirements in most likely situations.

The implicit invocation and pipe-and-filter architectures are both more than sufficient with
respect to enchanceability and reusability, although implicit invocation suffers from difficulty in
enchanceability of internal data representation, as observed in scenario B. Unfortunately, both
of these architectures incur a significant performance penalty, as demonstrated by scenario D.

Both abstract data type architectures have sufficiently positive scenario interaction for
enhanceability and reusability. They are also adequate in performance-evaluating scenario D,
where the other architectural candidates fall short. Comparison of the two ADT architectures
reveals that while the first carries a slight advantage in reusability, seen in scenario E, the
second is superior in enhanceability and performance, as demonstrated by scenarios B and D
respectively. As the advantages inherent in the second abstract data type candidate outweigh
those of the first, we have selected it as the architectural design for construction of the KWIC
system.

Traceability matrix between requirement specification and

architectural specification

Issues Functional Architectural

I-FR
Requirements Specification
Module input verifies all the
FR1 Input verification
inputs

Module input accepts all valid

FR2 Sets of characters
ASCII characters

Module Circular Shift constructs

FR3 Shifting each line
circular shift of each line

Module Circular Shift excludes

FR4 Punctuation
circular shift of punctuation

15
Global 14 KWIC Software Architecture v1.4

Exclude original statement in the Module Output doesn't output

FR5
output original statement

Input medium accepts keyboard

FR6 Input methods
entry and copy/pasted inputs

Module Output only outputs the

FR7 Only print the alphabetized form
alphabetized form

Issues Non-Functional
I-NFR
Requirements
A sound User Manual and good
NFR1 Understandability GUI makes the product easily
understandable

Anybody can use the system via

NFR2 Portability internet and the system is non-
platform specific

The system can accept updates

NFR3 Enhanceability
without problems

The modules of the system can

NFR4 Reusability be easily reused because of
fewer assumptions

The system responses quickly

NFR5 Good performance
and correctly

The GUI design is simple to use

NFR6 User-friendly
and a help function helps user

The system responses in two

NFR7 Responsiveness
minutes

The system is modular to be

NFR8 adaptability
easily maintained

16
Global 14 KWIC Software Architecture v1.4

References

[1]: Mary Shaw, David Garlan. “Software Architecture: Perspectives on an Emerging

Discipline.” Upper Saddle River, New Jersey: Simon & Schuster, 1996.

[2]: Mugurel T. Ionita, Dieter K. Hammer, Henk Obbink. "Scenario-Based Software Architecture
Evaluation Methods: An Overview." Technical University
Eindhoven. Web.

17