



Study with the several resources on Docsity
Earn points by helping other students or get them with a premium plan
Prepare for your exams
Study with the several resources on Docsity
Earn points to download
Earn points by helping other students or get them with a premium plan
Streaming war application requirement
Typology: Assignments
1 / 6
This page cannot be seen from the preview
Don't miss anything!




CS 6310 – Software Architecture & Design Assignment # 5 [ 150 points]: Streaming Wars Project – Architecture & Design (v 1 ) Spring Term 2021 – Instructor: Mark Moss Submission
Submit your proposed project modifications in a file labeled group_proposals.pdf. The file should contain one Architectural Decision Record (ADRs) for each modification. ADRs are discussed in more depth in Chapter 19 of Fundamentals of Software Architecture (Ford & Richards, O'Reilly 2020). Also, here are some links that contain more examples of, and details about, ADRs and the process: https://adr.github.io/ https://www.ozimmer.ch/practices/2020/05/22/ADDefinitionOfDone.html https://medium.com/olzzio/y-statements-10eb07b5a Planned Technical Deployment [ 20 points] (^) Provide a brief description (~4-12 sentences) of the languages, systems and related technologies that you're planning to use – or at least seriously considering using – to implement and deploy your final system (A6). We don't expect a comprehensive list of every single library or package that might be included, but we do want you to be proactive on letting us know your most likely plan for implementation. We give you a relatively wide latitude with the technologies that you can select for the final project, but you must coordinate your choices with your designated grading TA to ensure that they will be able to interact with and evaluate your final submission thoroughly. The TAs have "final approving authority" for technology selections. Please include your "Planned Technical Deployment" content as the last portion of the group_proposals.pdf document.
Robustness: Ability to handle error and boundary conditions while running if the internet connection goes down or if there’s a power outage or hardware failure. There have not been many error handling requirements so far. This is an opportunity to improve the error handling of the system and much more. Consider the possibility of the program crashing – for example, power being lost – while executing a program run. How would you modify the system to allow your system to resume execution after such an event without major delays, data corruption, etc.? Configurability: Ability for the end users to easily change aspects of the software’s configuration (through usable interfaces). We implemented a relatively simple Command Line Interface in earlier assignments, so this is an opportunity not only to generate a better, richer interface, but also to address things like the ability to set the starting month and date of the program run instead of hardcoding it into the program. Similarly, the implementation of some of your other architectural and design changes might create other configuration parameters that need to be changed. How would you modify the system to allow users to manage these configuration parameters as easily as possible? Archivability: Will the data need to be archived or deleted after a period of time? (For example, customer accounts are to be deleted after three months or marked as obsolete and archived to a secondary database for future access.) Suppose that the data that is being collected and analyzed must be stored for a certain period of time. This might be driven by a legal requirement, a policy requirement, or a technical limitation, but either way the system must be implemented to manage the storage of this information. And, in some cases, there must also be ways to ensure that the information is purged after a certain amount of time. This next group of architectural concepts is "intertwined" in that it's difficult to consider one of them in isolation, because implementing one of them effectively all but requires that you consider the impacts (and dependencies) on the others. I'm listing all of these terms here as a "bundle", but you may select and implement two or three of them as permitted by the assignment instructions. Authentication: Security requirements to ensure users are who they say they are. Authorization: Security requirements to ensure users can access only certain functions within the application (by use case, subsystem, webpage, business rule, field level, etc.). Authentication and authorization are often essential if you're going to enforce any kind of security and/or privacy protocols. Privacy: Ability to hide transactions from internal company employees (encrypted transactions so even DBAs and network architects cannot see them).
Security: Does the data need to be encrypted in the database? Encrypted for network communication between internal systems? What type of authentication needs to be in place for remote user access? Also, the public has become much more aware of the need for data privacy, and there are various things that can be done to ensure that user's data – especially medically and/or financially sensitive data – is accessed only by authorized users for its intended purposes. *Auditability: Ability to track the "activity records" (e.g., which commands were executed by a user) in such a way that a user's activity records can only be reviewed by personnel in appropriate roles, such as a Security Administrator; and, that a user cannot remove or otherwise corrupt their own activity records. *I included this one from other sources including my own personal experience. The unifying theme of all of these architectural considerations is making the system more "trustworthy" against the case of deliberate, adversarial threats as well as accidental, non-adversarial issues that might corrupt the data and/or operations of the system. How would you modify the system to improve its overall level of trustworthiness? Additional Functional Requirements As mentioned in the previous assignment, we are additional functionality primarily to allow the updating and deletion of certain elements of the system. [ 13 ] update_demo,