SOFTWARE ARCHITECTURE FOR A KWIC SYSTEM

1. SOFTWARE ARCHITECTURE FOR A KWIC SYSTEM TEAM: GLOBAL 14

2. Agenda • Problem, Process and Solution • Progress Report  • Requirements Analysis • Architecture • Implementation • TO DO list • Demonstration • Conclusion

3. Problem Description (QUICK KWIC;-)) • Architect a simple KWIC system using OO  Style • Build a web-accessible interface for architected system • Functional Requirements • Accept ordered set of lines • "Circularly Shift" each input line • Output a listing of all "circular shifts" of all lines in ascending alphabetical order • NFRs • understandable, portable, enhanceable... • responsive, user-friendly...

4. Development Process (Software)

5. Development Process (Team)

6. Devt. Process (Team Organization) • Subdivisions  • Our Group Size was large • Coordination was more effective within smaller groups • Weekly Online Meetings to keep every one abreast of issues • Use of Google Docs and SVN • HOW TO Wiki for every team member to know what is being done elsewhere

7. Our Solution • A very easily enhanceable architecture based on the OO style • A .NET application with a Microsoft Silverlight front end • Why .NET  • Exploring new frontiers in available technology

8. Work Done - Requirements Analysis Issue: What set of characters are allowable as input into the system, ( ie. %, $, &) ? Options: O1: All valid ASCII characters.O2: All valid Unicode characters.O3: Various other language characters. Winner: O1

9. Work Done - Requirements Analysis (2) Issue: What is “user-friendly”? Does this only refer to GUI? Options:O1: Provide Progress bar or timer for large inputs O2: GUI design should be simple to allow a user to immediately know what each element is for.O3: Provide a help function to assist usersO4: Provide a pop-up menu to assist users Solution: O1, O2, O3

10. Test Plan How we had to a test plan before development? We start our test plan before implementation. We come up test plan and test cases with the requirement documents and architecture documents. • NFRS test cases • FRS test cases

11. Work Done - Architecture • Software Architecture Analysis Method (SAAM) as a basis upon which to systematically decide upon the ideal architecture for this project.  • OO architecture was requested. The need to evaluate other systems is demonstrative rather than selective. • 6 steps of the SAAM process:  • Develop scenarios • Describe candidate architecture • Classify and prioritize scenarios • Perform scenario evaluation • Assess scenario interaction • Generate overall evaluation

12. Work Done - Architecture (contd.) Consideration of alternative  OO architectures - Option A Diagram for First alternative considered

13. Work Done - Architecture (contd.) Consideration of alternative  OO architectures - Option B Diagram for second alternative considered The major advantage of this architecture is that data replication is eliminated

14. Work Done - Architecture (contd.)    Rationale for selecting final OO architectures (Option X)    ++ = 100%  + = 75%    +- = 50%    - = 25%   -- = 0%      1.        ADT1                                  75%            2.        ADT2                                 80%            3.       Implicit Invocation           50%            4.       Pipe-and-Filter                  60%

15. Work Done - Implementation • Client • Engine • Server

16. User Manual • How to set up the system • How to use/run the system • Required system configuration

17. Demonstration http://hypv3355.appliedi.net/G14Kwic/Computer Might Need Silverlight Installation Input Text: This is a sample test for the presentation$We hope it convinces you we did our work

18. TO DO • NFRs not yet tested • Enhancements of the UI • "Clear Screen" Button • Convert the Text Input into a Text Area • Requirements traceability matrix

19. Conclusion Our strenghts: • SAAM • Alternative OO architectures • Test plan built from the  beginning • Team organization to take cognizance of each member's strengths and for effectiveness • Large number = more work done

20. ??Any Questions??