High-Level Architecture v1

Size: px

Start display at page:

Download "High-Level Architecture v1"

Candace Webb
5 years ago
Views:

1 High-Level Architecture v1 Access Control Configuration Admin Admin Interface Access Control Customer DB Configuration Web Interface Staff Mail System Interface Query and Data Analysis Requests DBMS Customers Overall Comments about Requirements Uniformly nicely done Provided Clients with a number of good ideas 1

2 Some criticisms Project Integration Overlap between tickets and threads Database Management Too much information about the internal DB schema and not enough information about the Client s interaction with the DB configuration Access Control Document had HLD information Data Analysis Too much information about the internal DB schema and not enough information about the statistical analysis results and merging capabilities Document needs some reorganization, need an overview of each section Requirements Concerns Terminology problems Customers versus Clients Our project clients are Thea and Sachin CMS is dealing with UMOCH customers Collections versus Threads Thread - set of related interaction records for a customer Need to define what related means Will have collections of threads in the DBMS 2

3 Tickets Clients like the idea of knowing which interactions still need to be processed But didn t like the ticket systems they have used in the past Could be handled by having a topic to indicate that an interaction is awaiting processing Pending interactions - interactions pending action by a staff member Project Integration team could provide special GUI to support functions for dealing with pending interactions But, may not be very different than functions for dealing with any topic Need to investigate this further CMS DB Terminology CMS DB contains one or more Customer Records Customer Record consists of: 1 Customer ID Information 0 or more s An consists of: 1 or more related Interaction Entries 3

4 Conceptual View of the CMS DB (may or may not be implemented this way) Customer Record Customer ID Information Conceptual View of the CMS DB (may or may not be implemented this way) Customer Record Customer ID Information { Collection of Interaction Threads 4

5 Conceptual View of the CMS DB (may or may not be implemented this way) Customer Record { Collection of Interaction Threads Customer ID Information } Interaction Thread CMS DB Glossary CMS DB = collection of zero or more Customer Records Customer Record = Customer ID Information and collection of zero or more Customer Interaction Threads Customer = one or more Customer Interaction Entries Note, collection is a conceptual term Abbreviations: Customer N can be shortened to N, when the meaning is clear E.g., DB, Interaction thread, 5

6 Single or Multiple Databases? Currently one database, but maintaining this is not a priority We can assume that there are two separate data bases Customer Management System (CMS) Database Property Database Customers may register in the Property DB Interactions between the two Databases: Usecase A customer submits an entry for the Property Database Must be a registered customer Can a customer register on the spot? Fills out the appropriate on-line form Request goes to Staff who then accepts or rejects the request Mail message is sent to the customer indicating whether the request was accepted or not Currently, Staff manually creates a customer interaction entry that corresponds to this request Is a record created when the request is rejected? The entry into the CMS DB could be automated Perhaps with staff confirmation 6

7 Deletion Deletion is often a dangerous concept Clients prefer Active and Archived E.g. Binary value so one name is better than two Active: Y or N Must be able to set the value of Active Could be a predefined category or just based on the date of last interaction, or both E.g., only show (active) records that are less than # months old Should be able to select default value for # Should be able to use a date instead of relative time Same look and feel Need to have the various frames have a similar style E.g., Instant search for customer and for staff Project Integration team will create some proposals for discussion as part of their HLD 7

8 DBMS Glossary DBMS= {Customer Records*} Customer Record = {Customer ID Information, Customer s*} Customer = {Customer Interaction Entries+} Categories Class proposed using: Customer ID Fields Interaction Entity Topics For now, we ll use categories Clients liked the idea of being able to define a hierarchy Whenever you have a constant, think about generalizing (e.g., 2=>N) Typical directory structure Try to generalize concepts, not just constants E.g., Also need Categories Try to generalize terms Categories, subcategories, subsubcategories, 8

9 Category Directory Customer ID Information Name Home Address Street Town Zip code Position(s) Student Employee Categories Predefined and Staff-defined categories Predefined Categories -- can not be changed, except to add new subcategories Staff-defined Categories Can only be defined by staff with appropriate permission Some possible attributes of a category Multiple values or single values Required or optional Possible values E.g., Yes/No text Default value and, if so, actual value to be used 9

10 Category Directory with additional subcategories Customer ID Information Name Home Address Street Town Zip code Position(s) Student Employee Parent Low Income Category Directory with Attributes Shown Customer ID Information Name Home Address Street Town Zip code Position(s) [required, multiple values from subcategories, no default] Student Employee Parent [optional, single value:text, no default] Low Income [optional, single value:y/n,default=y] 10

11 Category Directory Customer ID Information Customer Customer Category Directory Customer ID Information Customer Issue Problem Website problem» password» Navigation» Disability accessibility Renter problem» Landlord» Evictions» Heat Roommate Customer 11

12 Thinking Ahead Categories should be presented to the staff and implemented in a consistent way Adding categories easier to implement than removing or reorganizing them Could delay remove and reorganize for a future version of the system, but design the system to facilitate making this change in the future Generalization Often good but easy to overdo How do you know if something should be generalized or not? Provides needed functionality or expected future functionality Expected to reduce future maintenance Sometimes the cost is minimal or even less But sometimes it is considerably more 12

13 Generalization May not be able to decide until doing design Make this clear in the requirements Multiple costs to consider Cost to build Cost to maintain Cost of added complexity in the UI Impact on time to completion (Time to market) Some of these costs could go up and others down Clients may not want to pay for functionality if the cost is too high Need to keep the clients in the loop Generalization Alternatives to consider when doing design Don t generalize Fully generalization Intermediate level of generalization E.g., 3 level directory instead of N levels May decide not to generalize (or minimal generalization) but design the system so it is easy to change Agile methods advocate not generalizing, Spiral model advocates evaluating the risks 13

14 Which team is responsible for what? Project Integration team Provide overall CMS project web interface that activates/deactivates all subfunctionality Interact with mail system Process mail automatically as appropriate Interface to create and update single customer records Provide ticket system Provide instant search for a customers (general capability so can be instantiated for staff) Access Control Provide support for defining permission groups Provide support for maintaining staff info Provide instant search for a staff member Define permission items(?) (probably needs to be predefined, but should be done in a way that makes it relatively easy to modify) Support the requested permissions Which team is responsible for what? Database team Data Analysis Team Provide support for Category Directory Provide support for search based on Provide Category Directory to other Category Directory teams Provide support for merge Provide support to update and retrieve Initiated by staff CMS DB info based on Category Prioritize candidate customers Directory Customize prioritization Do updates as requested by other After staff confirmation, make calls on teams DB to complete merge operation E.g., Set Pending to Y, Provide support for statistical analysis Merge (cust_1, cust_2) Requests for data reports based on retrieve information as requested category directory by other teams Customization of visualization E.g., single and collections of records/entries Reports Charts 14

15 Slightly Revised Schedule March 3: Revised Requirement Documents Due March 23: HL Design Documents Due March 23, 24: HL Design Presentations 15

High-Level Architecture v1. Overall Comments about Requirements. Some criticisms. Requirements Concerns. CMS DB Terminology

High-Level Architecture v1. Overall Comments about Requirements. Some criticisms. Requirements Concerns. CMS DB Terminology Admin High-Level Architecture v1 Admin Web Access Control Configuration Access Control Customer DB Configuration Overall Comments about Requirements Uniformly nicely done Provided Clients with a number