Global 14
KWIC Software Architecture v1.4
CS/SE 6362 Advanced Software Architectural Design (Spring 2011)
Cyberminer
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
4/6/2011
4/12/2011
4/23/2011
Version
1.0
1.1
1.2
Description
Initial draft
Added architectural descriptions
Finished SAAM process
Author
Global 14
Global 14
Global 14
1
Global 14
KWIC Software Architecture v1.4
Developer’s Website: http://utdallas.edu/~sas071100/SAD/
2
Global 14
KWIC Software Architecture v1.4
Contents
Introduction.................................................................................................................................................. 4
Brief Introduction .................................................................................................................................... 4
Purpose.................................................................................................................................................... 4
Scope ....................................................................................................................................................... 4
Definitions ................................................................................................................................................ 4
Architectural Representation ................................................................................................................ 4
Architectural Goals and Constraints .................................................................................................... 4
Process Architecture.................................................................................................................................. 5
Methodology............................................................................................................................................ 5
Process Architectural Design ............................................................................................................... 6
Architectural Candidates ........................................................................................................................... 7
Abstract Data Type 1 ............................................................................................................................. 7
Abstract Data Type 2 ............................................................................................................................. 9
Abstract Data Type 3 ........................................................................................................................... 10
Scenarios ................................................................................................................................................... 12
Scenario Interactions .............................................................................................................................. 14
Selected Architectural Design ................................................................................................................ 15
Traceability matrix between requirement specification and architectural specification ................. 16
UML ............................................................................................................................................................. 18
Use case view .......................................................................................................................................... 18
Component view ..................................................................................................................................... 19
Class view ................................................................................................................................................ 20
Interaction view ...................................................................................................................................... 21
3
Global 14
KWIC Software Architecture v1.4
Introduction
Brief Introduction
Search engines have become commonly used in today’s online world. There may be no tool
more frequently leveraged by users of the Internet than search engines. Search engines are
usually composed of many parts, including at least one that crawls web pages for metadata,
one that stores the metadata, and another that allows users to access it in a readable format.
The purpose of Cyberminer is to meet the second and third of these functions. Cyberminer does
not require a component to crawl for metadata.
Purpose
This document provides an architectural overview of the Cyberminer 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 Cyberminer
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
Descriptor – full text of any single entry, paired with a URL
Architectural Representation
This document presents the system’s architecture in the form of “4+1” views, including the usecase 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.
4
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.
5
Global 14
KWIC Software Architecture v1.4
Process Architectural Design
Team members assumed the following roles for analysis and design:
Team members
Jay Laughlin
Blake Jensen
Hendra Sutedja
Paul Asere
Sam Shaw
Zhenzhon Sun
Doug Beach
Luis Furtado
Abhishek Kumar
Caitlin Fowler
Tao Ran
Sean Wilson
Frederico Araujo
Owolabi Legunsen
Role
Requirements Engineer
Architect
Development Engineer
Quality Assurance Engineer
Project Manager
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.
6
Global 14
KWIC Software Architecture v1.4
Architectural Candidates
Three candidates were considered with regard to selection of an architectural design.
All candidates are of the abstract data type architectural style.
Abstract Data Type 1
Figure 1: First abstract data type design
Components
View: This component is responsible for user interactions. It provides information about
the system state in a clear format to the user. In addition, it accepts commands from the
user, and uses the Add, Remove, and Query interfaces of Controller to process these
commands.
Controller: The duties of the controller include handling requests from the view by
utilizing all other system components. It is the center of the architecture, and it provides
three interfaces: Add, Remove, and Query.



Add interface causes new data to be processed with the KWIC Engine then
introduced into the Repository.
Remove interface causes a single record of data to be deleted from the
Repository.
Query interface returns the result of a query executed upon the contents of the
Repository.
7
Global 14
KWIC Software Architecture v1.4
KWIC Engine: The KWIC Engine accepts a set of plaintext input and produces from it a
set of alphabetized circular shifts. This is described in detail in KWIC Software
Architecture.1
Repository: This component is responsible for storing alphabetized circular shift index
information along with URLs and full descriptors. The execute interface allows for
execution of insert, delete, and select operations.
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 components’ interfaces, using
information hiding.
Pattern
1
http://utdallas.edu/~sas071100/SAD/phase1/KWIC%20Software%20Architecture.doc
8
Global 14
KWIC Software Architecture v1.4
Abstract Data Type 2
Figure 2: Second abstract data type design
Components
The second abstract data type design has the same components as the first design,
with the addition of a new component called CyberminerEngine.
CyberminerEngine…
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 components’ interfaces, using
information hiding.
Pattern
9
Global 14
KWIC Software Architecture v1.4
Abstract Data Type 3
Add
View
Execute
Remove
Query
Repository
Cyberminer Engine
Generate
Shifts
Components
View: This component is responsible for user interactions. It provides information about
the system state in a clear format to the user. In addition, it accepts commands from the
user, and uses the Add, Remove, and Query interfaces of Controller to process these
commands.
Cyberminer Engine: The duties of the Cyberminer Engine include handling requests
from the view by utilizing all other system components. It is the center of the
architecture, and it provides three interfaces: Add, Remove, and Query and in internal
method Generate Shifts.



Add interface causes new data to be processed with the KWIC Engine then
introduced into the Repository.
Remove interface causes a single record of data to be deleted from the
Repository.
Query interface returns the result of a query executed upon the contents of the
Repository.
10
Global 14

KWIC Software Architecture v1.4
Generate Shifts accepts a set of plaintext input and produces from it a set of
alphabetized circular shifts. This is described in detail in KWIC Software
Architecture.2
Repository: This component is responsible for storing alphabetized circular shift index
information along with URLs and full descriptors. The execute interface allows for
execution of insert, delete, and select operations.
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 components’ interfaces, using
information hiding.
Pattern
2
http://utdallas.edu/~sas071100/SAD/phase1/KWIC%20Software%20Architecture.doc
11
Global 14
KWIC Software Architecture v1.4
Scenarios
The following scenarios pertaining to the Cyberminer system are organized in order of
descending priority:
1. Case sensitive search
a. Direct
b. Evaluation……
For each of the three architecture styles proposed, they all perform well on this
scenario as case sensitive search only has to do with the query component, however
ADT1 and ADT2 will be faster than ADT3 because they are more modular.
2. Addition/removal of indices based on URLs and descriptions
a. Direct
b. Evaluation
Addition/Removal of indices is better achieved by ADT1 and ADT2 because of
separation of concerns; however ADT3 uses less space because data is not
duplicated.
3. Modification of internal representation of input/data structures
a. Indirect
b. Evaluation…
Although data representation in ADT is arbitrary it can be observed that if data
representation is changed for ADT1 and ADT2 then the only the KWIC modules will
be affected (in ADT2 more interfaces may be affected), however in the case of ADT3
the entire Cybeminer module will be affected.
4. System ported to different platform
a. Indirect
b. Evaluation…
For all three architectural candidates, add, remove and query medium must be
accounted for when porting to a different platform
5. Components reused in new system
a. Indirect
b. Evaluation
All the three architectural candidates will require adaptation of the new operating
environment to account for the circular shift’s “ith” operation, and the cs-char and csword interfaces and noise word eliminator, however ADT1 and ADT2 will be easily
reusable as the KWIC component is separated from the Cybeminer. Separation of
concerns is clearly achieved in these two.
12
Global 14
KWIC Software Architecture v1.4
6. Removal of noise elimination component
a. Indirect
b. Evaluation…
This scenario works well in ADT1 and ADT2, because only the KWIC component will
be affected, however in ADT3 the entire cyberminer component has to be affected
because it is tightly coupled.
13
Global 14
KWIC Software Architecture v1.4
Scenario Interactions
Following are quantitative evaluations of the scenario interactions based on the above
evaluations:
ADT1
ADT2
ADT3
A
++
++
+-
B
++
++
-
C
++
+-
-
D
+-
+-
+-
E
++
++
+-
F
++
++
--
++ = 100%
1. ADT1
2. ADT2
3. ADT3
+ = 75%
+- = 50%
- = 25%
-- = 0%
92%
83%
33%
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 first design best suited to serve as our
basis for construction of the Cyberminer software system.
The third ADT solution underperforms in scenarios 2, 3, and 6. As such it is not a viable
candidate for architecture of the Cyberminer system. Enhanceability, a valued non-functional
requirement necessary for the system, suffers in these three scenarios with this architecture.
Portability and reusability also are insufficient in ADT3, as seen in scenarios 4 and 5
respectively.
In comparing the remaining two choices, ADT1 and ADT2, it is clear that they perform similarly
in five of the six scenarios. In scenario 3, however, ADT1 outperforms ADT2, as there are fewer
affected components that must be updated when internal data structures are modified in this
architecture. This reflects a benefit with respect to enhanceability.
Therefore, we have selected the first abstract data type design to use as the foundation for the
Cyberminer software system.
15
Global 14
KWIC Software Architecture v1.4
Traceability matrix between requirement specification and
architectural specification
OFR
Issues Functional
Requirements
Architectural
Specification
OFR1-ISSUE1
Input source
Input medium accepts keyboard
entry and copy/pasted inputs
OFR1-ISSUE2
Language supported
All modules designed to support
only English
Interaction between Cyberminer
system and KWIC system
Add interface of Module
Controller causes new data to be
processed with the KWIC Engine
then introduced into the
Repository
OFR2-ISSUE2
The way KWIC system maintains
the database of URL’s
Module Repository is responsible
for storing alphabetized circular
shift index information along
with URLs and full descriptors
OFR2-ISSUE3
The way KWIC system efficiently
maintains the database of URL’s
Module Repository maintains an
index of all the URLs in the
database
OFR6-ISSUE1
The constitution of a noise word
The KWIC Engine defines the set
of words considered ‘noise’
OFR7-ISSUE1
The location the shifted URL’s
sent to or stored
Module Repository stores shifted
URL’s and Module View works to
print the result on screen
The way indices are built
Module view gets input from
user and uses the Add, Remove,
and Query interfaces of
Controller to process these
commands. And module KWIC
Engine builds an initial KWIC
OFR2-ISSUE1
OFR7-ISSUE2
16
Global 14
KWIC Software Architecture v1.4
indices and grows the indices
with later additions.
OFR7-ISSUE3
OFR7-ISSUE4
The source of the additions to
the indices
Module KWIC Engine generates
new indices from the new
additions to the database of
Module Repository
The execute interface of Module
The way to input the additions to Repository allows for execution
the indices into the KWIC system of insert, delete, and select
operations
The operations of Module
Repository supports case
sensitiveness
OFR8-ISSUE1
Case sensitive searching
OFR11-ISSUE1
The way for multiple search
engines to run concurrently
Multiple systems can access the
database of Module Repository
simultaneously
The way to delete out-of-date
URLs
The execute interface of Module
Repository allows for execution
of insert, delete, and select
operations
OFR12-ISSUE2
OFR16
Auto-fill
ONR
Issues Non-Functional
Requirements
ONR3
Enhanceability
ONR4
Reusability
ONR5
User-friendly
Module View, Controller, KWIC
Engine, and Repository work
together for auto-fill
The module Repository can be
able to add more URLs to its
database as the system grows
The selected architecture uses
an OO architecture, which makes
it easier to re-use code
The GUI design is simple to use
and a help function helps user
17
Global 14
KWIC Software Architecture v1.4
UML
Use case view
Figure 3: Cyberminer UML use case diagram
18
Global 14
KWIC Software Architecture v1.4
Component view
Figure 4: Cyberminer UML component diagram
19
Global 14
KWIC Software Architecture v1.4
Class view
Figure 5: Controller and Repository UML class diagram
20
Global 14
KWIC Software Architecture v1.4
Interaction view
Figure 6: Cyberminer UML sequence diagram
21