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