Personal.utdallas.edu



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:

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

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.

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.

Process Architectural Design

Team members assumed the following roles for analysis and design:

|Team members |Role |

|Jay Laughlin |Requirements Engineer |

|Blake Jensen | |

|Hendra Sutedja | |

|Paul Asere |Architect |

|Sam Shaw | |

|Zhenzhon Sun | |

|Doug Beach |Development Engineer |

|Luis Furtado | |

|Abhishek Kumar | |

|Caitlin Fowler |Quality Assurance Engineer |

|Tao Ran | |

|Sean Wilson | |

|Frederico Araujo |Project Manager |

|Owolabi Legunsen | |

[pic]

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.

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

[pic]

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.

Pattern

[pic]

Abstract Data Type 1

[pic]

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 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.

• 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

Abstract Data Type 2

[pic]

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.

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

[pic]

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 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.

• 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

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 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%

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

|I-FR |Issues Functional Requirements |Architectural Specification |

|FR1 |Input verification |Module input verifies all the inputs |

|FR2 |Sets of characters |Module input accepts all valid ASCII characters|

|FR3 |Shifting each line |Module Circular Shift constructs circular shift|

| | |of each line |

|FR4 |Punctuation |Module Circular Shift excludes circular shift |

| | |of punctuation |

|FR5 |Exclude original statement in the output |Module Output doesn't output original statement|

|FR6 |Input methods |Input medium accepts keyboard entry and |

| | |copy/pasted inputs |

|FR7 |Only print the alphabetized form |Module Output only outputs the alphabetized |

| | |form |

|I-NFR |Issues Non-Functional Requirements | |

|NFR1 |Understandability |A sound User Manual and good GUI makes the |

| | |product easily understandable |

|NFR2 |Portability |Anybody can use the system via internet and the|

| | |system is non-platform specific |

|NFR3 |Enhanceability |The system can accept updates without problems |

|NFR4 |Reusability |The modules of the system can be easily reused |

| | |because of fewer assumptions |

|NFR5 |Good performance |The system responses quickly and correctly |

|NFR6 |User-friendly |The GUI design is simple to use and a help |

| | |function helps user |

|NFR7 |Responsiveness |The system responses in two minutes |

|NFR8 |adaptability |The system is modular to be easily maintained |

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.

-----------------------

Subprogram Call

System I/O

Direct Memory Acess

ddsdsdada

Access Attributes

System I/O

Implicit Invocation

Subprogram Call

System I/O

System I/O

................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download