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
The purpose of this document is to provide a detailed architecture design of the new Coop Evaluation System by focusing on four key quality attributes: ...
Typology: Exams
1 / 28
This page cannot be seen from the preview
Don't miss anything!
Team Members: Tyler Geery Maddison Hickson Casey Klimkowsky Emma Nelson
Faculty Coach: Samuel Malachowsky
Project Sponsors: Jim Bondi (OCSCE) Kim Sowers (ITS)
Table of Contents
Table of Contents Revision History 1 Introduction 2 Background 3 Functional Requirements 4 Quality Attributes 4.1 Usability 4.2 Availability 4.3 Maintainability 4.4 Testability 5 Architecture Overview 5.1 Big Picture 5.1.1 System Context 5.1.2 User Interactions 5.1.3 Data Flow 5.2 View Introduction 5.3 Patterns and Tactics 5.3.1 Architectural Drivers and Tactics Usability Availability Maintainability Testability 5.3.2 Patterns Service Oriented Pattern Domain Model and Data Mapper Patterns Client Server Pattern Model View Controller Pattern 6 Views 6.1 Logical (Layered) View 6.1.1 View Diagram Notation Explanation 6.1.2 Element Catalog Elements Presentation Layer Application Logic Layer Service Layer Domain Model Layer Data Access Layer (DAL) Data Source Layer Relations
Revision History
Version Primary Author(s) Description ofVersion Date Completed
v1.
Emma Nelson, Maddison Hickson, Casey Klimkowsky, Tyler Geery
Initial revision October 27, 2014
v1.1 Casey Klimkowsky
Update after receiving feedback from Lisa on 10/31/
November 3, 2014
v1.2 Emma Nelson Validate changes November 6, 2014
1 Introduction
The purpose of this document is to provide a detailed architecture design of the new Co op Evaluation System by focusing on four key quality attributes: usability, availability, maintainability, and testability. These attributes were chosen based on their importance in the design and construction of the application.
This document will address the background for this project, and the architecturally significant functional requirements. Each of the aforementioned quality attributes will be described through a comprehensive set of scenarios followed by an architectural overview, which includes a bird’s eye view and a full description of patterns and tactics that will be used to address the core quality attributes. This will be followed up by a look at a couple views into the system. Finally, acknowledgements, references, and appendices will round out the document.
The intention of this document is to help the development team to determine how the system will be structured at the highest level. It is also intended for the project sponsors to sign off on the high level structure before the team shifts into detailed design. Finally, the project coach can use this document to validate that the development team is meeting the agreed upon requirements during his evaluation of the team’s efforts.
2 Background
RIT’s current Co op Evaluation System, an application used by OCSCE, has a number of performance, reliability, usability, and maintainability issues. Among others, session timeouts and submission timeouts are inherent problems of the current Co op Evaluation System. A new version started from scratch with up to date technologies needs to be developed.
The purpose of this project is to re engineer the Co op Evaluation System in order to leverage newer web technologies while also improving performance and user interaction. Since we are essentially recreating the CES, the new system has to interface with any external components that the current CES uses or the replacement systems, as determined by ITS. These components include Shibboleth for RIT user authentication, the ITS mail server for sending emails to users, and an Oracle SQL database for storing system information. Refer to the Software Requirements Specification for a context diagram and a detailed description of how these components interact. The context diagrams are also available in section 5.1 of this document.
The system must comply with the development guidelines provided to us by ITS, as defined by the EWA Student Development Guidelines wiki page. At a high level, these guidelines include approved application frameworks, build tools, application server technologies, database standards, and several other technology standards. Although these constraints will primarily affect the detailed software design, we still need to take them into consideration when creating the system architecture.
Artifact Co op Evaluation System
Environment At runtime
Response
The system displays pertinent information by default on the user’s home screen without forcing them to dig into nested menus to find the information for which they are looking.
Response Measure Task time
Scenario The user wants to receive usermessages when an error occurs.^ and situation appropriate error
Source End user
Stimulus Minimize impact of errors
Artifact Co op Evaluation System
Environment At runtime
Response
The system will provide visual feedback stating whether or not a given action was successful. If it was not successful, the system will provide details on what went wrong and how to rectify the situation, when possible. Furthermore, the system will send the user a follow up email with the status of any submissions in the case of Work Reports and Co op Evaluations.
Response Measure User satisfaction, amount of time lost, amount of data lost
Scenario User wants to know which actions are available and that the actionthey choose is being executed correctly.
Source End user
Stimulus Increasing confidence and satisfaction
Artifact Co op Evaluation System
Environment At runtime
Response
The system will only display actions that are currently available as “active”. Any other options with either be hidden or greyed out and unclickable. Furthermore, the system will provide visual feedback stating whether or not a given action was successful.
Response Measure User satisfaction, gain of user knowledge
Scenario The system times out before a Work Report or Employer Evaluationcan be submitted.
Source Internal to system
Stimulus The maximum time allowed on form submission page has elapsed
Artifact Work Report or Employer Evaluation
Environment Normal operation
Response Notify the user that their session has timed out, and that the currentform was not submitted.
Response Measure Number of session timeouts
Scenario The application server fails or becomes unresponsive, causing theentire system to fail.
Source Internal to system
Stimulus A fault within the application server
Artifact Application server
Environment Degraded
Response The entire system shuts down until the application server is broughtup again.
Response Measure Percentage of uptime (Minimum of 95%)
Scenario The system is compromised by a Denial of Service (DoS) attack.
Source External to system
Stimulus The system receives more requests per second than it can handle
Artifact Web service
Environment Normal operation
Response Standard response according to RIT Systems and Operationsprotocol.
Environment Design time, runtime
Response Refactor code to be simpler and contain the new functionality
Response Measure Time spent refactoring
Scenario Lack of documentation hinders usage, management, and futureupgrades.
Source Developer, Maintainer
Stimulus
Documentation was not made a priority throughout the development of the application and thus does not provide the most up to date information on the system features and functionality
Artifact System documentation
Environment At runtime
Response Developers spend time improving documentation
Response Measure Time spent understanding the system that would have been aidedby more robust documentation
Scenario
Excessive dependencies between components and layers and inappropriate coupling to concrete classes prevents easy replacement, updates, and changes.
Source Developer, Maintainer
Stimulus Developer wish to replace, update, or modify part of the system.
Artifact The Co op Evaluation System
Environment At runtime
Response
Re design the system with well defined layers, or areas of concern, that clearly delineate the system’s UI, business processes, and data access functionality. Application configuration for commonly changed parameters, such as URLs, will maintained outside the code base following RIT EWA standards.
Response Measure Time spent redesigning and refactoring
Scenario There is a lack of test planning.
Source System verifier
Stimulus Subsystem integration completed. Testing did not start early duringthe development life cycle.
Artifact The Co op Evaluation System
Environment At design time
Response Prepare a test environment
Response Measure Test coverage, percent executable statements executed, length oftime to prepare test environment
Scenario Test coverage of the system is inadequate.
Source All testers
Stimulus
Subsystem integration completed os system delivered. Because both manual and automated tests don’t cover a large portion of the project, the testing team wish to expand the test suite.
Artifact The Co op Evaluation System
Environment At development time
Response Provide a fuller testing environment, which includes automated testsand coverage reporting.
Response Measure Percentage of paths or executable statements covered
Scenario Testing is not consistent throughout the system.
Source System verifier, Client acceptance tester
Stimulus
Subsystem integration completed os system delivered. Automated or granular testing cannot be performed if the application has a monolithic design
Artifact The Co op Evaluation System
Environment At deployment time
Figure 2. User interaction with the Co op Evaluation System
The diagram above show a high level view of the user interaction with the system as well as the interaction between technologies involved.
Figure 3. The flow of data into and out of the Co op Evaluation System
The above diagram shows the basic flow of data into and out of the system at a high level. Our system and direct interfaces are represented inside of the blue container, with the outside entities depicting how data is created and imported into our system. Our system does not deal with data creation, however it is responsible for importing and storing it.
The two views that we have detailed are a Logical (Module) View and a Process (Component and Connector) View. The Logical View describes the layered structure of the system, while the Process View describes the client server structure of the system. The Logical View shows how the the system is structured as a set of functional code units, or modules, whereas the Process View shows how the system is structured as a set of computational elements that have runtime behavior (components) and interactions (connectors).
The Logical View is a higher level view of the system than the Process View. The Logical View shows the layers that compose the system, and the hierarchy of these layers. The Presentation Layer is encapsulated by the client, whereas the the lower layers are encapsulated by the server. The Process View also details the interactions between the client and the server and the specific components that comprise each.
Although it is standard to use a 4+1 View Model when describing a system architecture, we omitted the Physical View, Development View, and Use Case View from this document. At this time, we do not have the details of the system deployment, which would be outlined by the Physical View. We also do not yet have implementation details of the system, which would be outlined by the Development View. Both of these aspects of the system will be covered at a later date in separate documents. Finally, the Use Case View, which describes the various use cases of the system, has already been outlined in our Software Requirements Specification. Reference Section 4 of the Software Requirements Specification for more information on the Use Case View.
In order to maintain our focus on usability and iterate quickly on our user interface, we will be using the tactic Separate User Interface. This allows us to keep the user interface separated from the backend business logic and data source, thus enabling changes to be made easier or even for the user interface to be swapped out in the future, if another modernization is needed. The team will utilize a model view controller architectural pattern to accomplish this task. More details will be provided in Section 5.3.2 Patterns.
documentation will be the only source of knowledge of the system, and will be used to understand the system when the system needs to be updated.
Testability must be determined in early stages of development. Due to the iterative nature of our methodology, regression testing will be one of the primary forms of testing conducted. Therefore, the tactic Able to Stub/Mock is highly valued to us. This tactic will allow us to create tests and quickly use them to test the system when changes are made or new features are added to the system.
Another tactic for testing our team plans to conduct is Separating the Interface from Implementation , which is a form of providing input and capturing output. Separating the interface from the implementation allows substitution of implementations for various testing purposes. This will also allow us to write tests without having to touch the interface itself.
The service oriented pattern compartmentalizes different features within the application. This pattern describes a collection of distributed components that provide and/or consume services. Service consumers are able to use these services without any detailed knowledge of their implementation.
This allows for easy maintainability, as each service can be altered without affecting the other services of the system. Additionally, each service can be tested independently of each other, which can be useful in pinpointing potential defects.
The domain model pattern incorporates both behavior and data into an object oriented model of the application domain. When using this pattern, the model of the domain is organized primarily around the nouns in the domain. The domain model is then separated from the database with the use of the data mapper pattern.
The data mapper is a layer that sits between the database and the domain model, which handles the loading and storing between the database and the domain model; therefore allowing both to vary independently. This separation of the database and domain model means that the domain objects do not have any knowledge that that database exists, and the domain model does not know that the data mapper exists.
The separation introduced by the data mapper pattern supports modifiability, as either entity can be modified independently of each other. The use of the domain model pattern supports increasing complexity and thus enhances extensibility as well.
Clients initiate interactions with servers, which provide a set of services. The clients invoke services as needed from those servers, and then wait for the results of those requests. The
client is responsible for displaying and performing small updates on the data, while the server handles data management.
The client server pattern supports modifiability and reuse, as it factors out common services, allowing them to be modified in a single location. This pattern also supports scalability and availability by centralizing the control of these resources and servers.
The model view controller (MVC) pattern separates user interface functionality from application functionality. With MVC, application functionality is divided into three types of components: models, which contain the application data; views, which display the underlying data and interact with the user; and controllers, which mediate between the model and the view and manage state changes.
The MVC pattern supports usability, as it allows the user interface to be designed and implemented separately from the rest of the application.
Each layer is denoted as long rectangle with a black border. The smaller rectangles inside represent a range of elements contained in each layer. Those included are not intended to be a complete list of entities. The large rectangles with blue borders demonstrates the physical separation of the layers between the client and the server. More information on that division will be provided in Section 6.2.
Presentation Layer The presentation layer will provide the user with a graphical interface for interacting with the system. It will be composed of HTML, CSS, JavaScript, and other related files that will run in the user’s web browser of choice. The main goal of this layer is to provide everything the user needs to complete their tasks in the system. The quality attributes that pertain to usability and front end design will have the biggest pull on the presentation.
Application Logic Layer The role of the application logic layer is to encapsulate the system controllers, which implement much of the core business logic. It will also serve as the connection between the user interface and the domain model, thus maintaining the separation of concerns.
Service Layer The service layer is in charge of modularizing different features (services) of the application. Certain features, such as reporting, require access to external APIs; the service layer will be in charge of interacting with those external APIs. An individual service can also use the application logic layer to perform core business logic.
Each service will act as a facade, serving as a general interface for a feature that can be accessed by the presentation layer. These facades (interfaces) will provide the ability to manipulate or fix the code underneath each service without affecting the way in which that service is called by other layers.
Modularizing the services within the system will also make it easier to pinpoint potential defects, allowing for easy maintainability. Each service can be tested individually, which allows for good system wide testability.
Domain Model Layer The domain model contains all of the system’s object representations of data in the system. This also includes associated methods for any objects that contain their own functionality.
Data Access Layer (DAL) The data access layer contains all of the mappers to the data in the system. The mappers are in charge of the coordination of all communication between the objects in the domain layer
and their corresponding tables in the database. This ensures that domain layer objects have no knowledge of the database, its schema, or any SQL interface.
Data Source Layer All persistent information and any external API integration (e.g. SIS, Simplicity) make up the data source layer. This includes the Oracle database that will contain all of the data for the system. At this time there is no expectation for integration with external systems, but the system should be architected to accommodate such integrations in the future, as there are a few options on the table.
Presentation Layer to Application Logic Layer The presentation layer represents the view of the system, and the application logic layer contains the controllers, which house the logic for the different roles. In following with the MVC architectural pattern, the controllers take information from the view and use it to modify or request related data in the model. This prevents the view from directly modifying the model, and instead has the view display changes to the data.
Application Logic Layer to Domain Layer The application layer modifies the data encapsulated in the domain layer according to the business logic rules before it reports changes back to the presentation layer to be displayed to the user.
Domain Layer to DAL to Data Source Layer The domain layer is the active representation of the information stored in the data layer. When it is time to store data according to the procedures defined in the upcoming detailed design stage, the changes to the domain layer will be pushed to the data source layer to create a persistent copy of the data to be stored across sessions through the DAL. All interactions between the DAL and Data Source Layer will indirectly be SQL queries in accordance with the ACID properties (i.e. an ORM framework will generate the SQL statements in most cases).
Interface Identity The DataMapper pattern acts as the interface between the persistence layer, and the domain layer, the object model. It is displayed in Figure 4 as the DAL. It serves as a way to convert domain model objects to data formated for the database.
