Introduction - personal.utdallas.educhung/SA... · Web viewThis document presents the system’s architecture in the form of “4+1” views, including the use-case view, logical

Global 14 KWIC Software Architecture v1.4

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

Cyberminer

Software ArchitectureSubmitted to:

Dr. Lawrence ChungAssociate Professor,

Department of Computer Science,The University of Texas at Dallas,

Richardson, TX -75080

Team Name: Global 14

Date Version Description Author4/6/2011 1.0 Initial draft Global 144/12/2011 1.1 Added architectural descriptions Global 144/23/2011 1.2 Finished SAAM process Global 14

1


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

2

http://utdallas.edu/~sas071100/SAD/


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


Introduction

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

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

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

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

4


Process Architecture

MethodologyGlobal 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


Process Architectural DesignTeam members assumed the following roles for analysis and design:

Team members Role

Jay LaughlinBlake Jensen

Hendra SutedjaRequirements Engineer

Paul AsereSam Shaw

Zhenzhon SunArchitect

Doug BeachLuis Furtado

Abhishek KumarDevelopment Engineer

Caitlin FowlerTao Ran

Sean WilsonQuality Assurance Engineer

Frederico AraujoOwolabi Legunsen

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


Architectural CandidatesThree 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


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

http://utdallas.edu/~sas071100/SAD/phase1/KWIC%20Software%20Architecture.doc



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



Constraint


Pattern

9



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


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



Constraint


Pattern

2 http://utdallas.edu/~sas071100/SAD/phase1/KWIC%20Software%20Architecture.doc11

http://utdallas.edu/~sas071100/SAD/phase1/KWIC%20Software%20Architecture.doc


ScenariosThe following scenarios pertaining to the Cyberminer system are organized in order of descending priority:

1. Case sensitive searcha. Directb. 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 descriptionsa. Directb. 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 structuresa. Indirectb. 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 platforma. Indirectb. 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 systema. Indirectb. 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 cs-word 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


6. Removal of noise elimination componenta. Indirectb. 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


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

ADT1 ADT2 ADT3

A ++ ++ +-

B ++ ++ -

C ++ +- -

D +- +- +-

E ++ ++ +-

F ++ ++ --

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

1. ADT1 92%2. ADT2 83%3. ADT3 33%

14


Selected Architectural DesignBased 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


Traceability matrix between requirement specification and architectural specification

OFRIssues Functional

RequirementsArchitectural Specification

OFR1-ISSUE1 Input sourceInput medium accepts keyboard entry and copy/pasted inputs

OFR1-ISSUE2 Language supportedAll modules designed to support only English

OFR2-ISSUE1Interaction 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-ISSUE2The 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-ISSUE3The 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 wordThe KWIC Engine defines the set of words considered ‘noise’

OFR7-ISSUE1The 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

OFR7-ISSUE2 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

16


indices and grows the indices with later additions.

OFR7-ISSUE3The source of the additions to

the indices

Module KWIC Engine generates new indices from the new additions to the database of Module Repository

OFR7-ISSUE4The way to input the additions to the indices into the KWIC system

The execute interface of Module Repository allows for execution of insert, delete, and select operations

OFR8-ISSUE1 Case sensitive searchingThe operations of Module Repository supports case sensitiveness

OFR11-ISSUE1The way for multiple search engines to run concurrently

Multiple systems can access the database of Module Repository simultaneously

OFR12-ISSUE2The way to delete out-of-date

URLs

The execute interface of Module Repository allows for execution of insert, delete, and select operations

OFR16 Auto-fill Module View, Controller, KWIC Engine, and Repository work together for auto-fill

ONRIssues Non-Functional

Requirements

ONR3 EnhanceabilityThe module Repository can be able to add more URLs to its database as the system grows

ONR4 ReusabilityThe selected architecture uses an OO architecture, which makes it easier to re-use code

ONR5 User-friendlyThe GUI design is simple to use and a help function helps user

17


UML

Use case view

Figure 3: Cyberminer UML use case diagram

18


Component view

Figure 4: Cyberminer UML component diagram

19


Class view

Figure 5: Controller and Repository UML class diagram

20


Interaction view

Figure 6: Cyberminer UML sequence diagram

21

Documents

Introduction - personal.utdallas.educhung/SA... · Web viewThis document presents the system’s architecture in the form of “4+1” views, including the use-case view, logical