introduction - personal.utdallas.educhung/sa... · web viewthis document presents the system’s...
TRANSCRIPT
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
Global 14 KWIC Software Architecture v1.4
Developer’s Website: http://utdallas.edu/~sas071100/SAD/
2
Global 14 KWIC Software Architecture v1.4
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
Global 14 KWIC Software Architecture v1.4
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
Global 14 KWIC Software Architecture v1.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
Global 14 KWIC Software Architecture v1.4
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
Global 14 KWIC Software Architecture v1.4
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
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.doc8
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
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.doc11
Global 14 KWIC Software Architecture v1.4
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
Global 14 KWIC Software Architecture v1.4
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
Global 14 KWIC Software Architecture v1.4
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
Global 14 KWIC Software Architecture v1.4
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
Global 14 KWIC Software Architecture v1.4
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
Global 14 KWIC Software Architecture v1.4
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
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