Software Architecture Document Template

OMSE 555/556 Software Engineering Practicum I & II
Software Architecture Document
Distributed Development Monitoring and Mining

Tom Mooney, Shailesh Shimpi, Ahmed Osman, Isaac Pendergrass
Version 1.7
04/11/2013
Revision History
Version Description of Versions / Changes Responsible Party Date
1.0 Initial version Shail Shimpi 2/16/13
1.1 Start of functional view Tom Mooney 3/10/13
1.2 Add the Prediction functional view Ahmed Osman 3/19/13
1.3 -Added Entity Data Model diagram

-Added interface specifications to get all
Tom Mooney 4/6/13
Spaces a user has access to and to get
Space data for a specific Space and user.
1.4 - Added Web Portal interface definitions. Shail Shimpi 4/9/13
- Added GetLastUserReport methods.
- Changed operation signatures.
1.5 - Enhanced the Prediction module Ahmed Osman 4/9/13
- Added PredictionClient and
PredictionClientService modules
1.6 - Web Portal Interface definition Shail Shimpi 4/10/13
modified
1.7 Added Use Case View and Deployment Isaac Pendergrass 4/11/13
View
Approval Block
Version Comments Responsible Party Date
Software Architecture Document (SAD) ii Distributed Development Monitoring and Mining

Table of Contents
1. Introduction ...................................................................................................................... 1
1.1. Purpose ..................................................................................................................................... 1
1.2. Scope ........................................................................................................................................ 1
1.3. Definitions, Acronyms, and Abbreviations ................................................................................ 2
1.4. References ................................................................................................................................ 2
1.5. Overview ................................................................................................................................... 2
2. Architectural Representation .......................................................................................... 3
3. Architectural Goals and Constraints .............................................................................. 4
4. Use-Case View ................................................................................................................. 4
4.1. Actors ........................................................................................................................................ 4
4.2. Use-Case Realizations.............................................................................................................. 5
4.2.1. Login ................................................................................................................................... 5
4.2.2. Request Analysis (Get Report) ........................................................................................... 6
4.2.3. Retrieve Last Report ........................................................................................................... 9
4.2.4. Print Report....................................................................................................................... 10
4.2.5. Email Report ..................................................................................................................... 11
5. Logical View ................................................................................................................... 12
5.1. Overview ................................................................................................................................. 12
5.2. Interface Definitions ................................................................................................................ 14
6. Data View ........................................................................................................................ 22
7. Deployment View ........................................................................................................... 25
Software Architecture Document (SAD) iii Distributed Development Monitoring and Mining
Software Architecture Document
1. Introduction
This document provides a high level overview and explains the architecture of the Distributed
Development Monitoring and Mining system.
The document defines goals of the architecture, the use cases supported by the system, architectural
styles and components that have been selected. The document provides a rationale for the
architecture and design decisions made from the conceptual idea to its implementation.
1.1. Purpose
The Software Architecture Document (SAD) provides a comprehensive architectural overview of

the Distributed Development Monitoring and Mining system (DMM). It presents a number of
different architectural views to depict the different aspects of the system.
In order to depict the software as accurately as possible, the structure of this document is based
on Philippe Kruchten’s “4+1” model view of architecture [Kruchten].
The “4+1” View Model allows various stakeholders to find what they need in the software
architecture.
1.2. Scope
The scope of this SAD is to explain the architecture of the Distributed Development Monitoring
and Mining system.
This document describes the various aspects of the DMM system design that are considered to
be architecturally significant. These elements and behaviors are fundamental for guiding the
construction of the DMM system and for understanding this project as a whole. Stakeholders who
require a technical understanding of the DMM system are encouraged to start by reading the
Project Proposal, Concept of Operations and Software Requirements Specification documents
developed for this system [PP, ConOps, SRS].
Software Architecture Document (SAD) 1 Distributed Development Monitoring and Mining

1.3. Definitions, Acronyms, and Abbreviations
 Apache – Web Server
 ASP.NET - Microsoft web platform
 HTTP – Hypertext Transfer Protocol
 Mono – open source implementation of Microsoft’s Common Language
Infrastructure
 WWW – World Wide Web
 SAD - Software Architecture Document
 UML – Unified Modeling Language
 User - This is any user who is registered on the DMM website
1.4. References
[PP]: Project Proposal
[SPMP]: Software Project Management Plan
[ConOps]: Concept of Operations
[SRS]: Software Requirements Specification
[MedBiquitous]: Sample SAD,

http://medbiq.org/std_specs/techguidelines/softwarearchitecture.pdf
[Kruchten]: The “4+1” view model of software architecture, Philippe Kruchten, November 1995,
http://www3.software.ibm.com/ibmdl/pub/software/rational/web/whitepapers/2003/Pbk4p1.pdf
1.5. Overview
In order to fully document all the aspects of the architecture, the Software Architecture
Document contains the following subsections.
Section 2: describes the use of each view
Section 3: describes the architectural goals and constraints of the system
Section 4: describes the most important use-case realizations
Section 5: describes logical view of the system including interface and operation definitions.
Section 6: describes significant persistence elements.
Section 7: describes how the system will be deployed.

2. Architectural Representation
This document details the architecture using the views defined in the “4+1” model [Kruchten]. The
views used to document the DMM system are:
Use Case view

Audience: all the stakeholders of the system, including the end-users.
Area: describes the set of scenarios and/or use cases that represent some significant,
central functionality of the system. Describes the actors and use cases for the system, this
view presents the needs of the user and is elaborated further at the design level to describe
discrete flows and constraints in more detail. This domain vocabulary is independent of any
processing model or representational syntax (i.e. XML).
Related Artifacts : Use-Case Model, Use-Case documents
Logical view
Audience: Designers.
Area: Functional Requirements: describes the design's object model. Also describes the
most important use-case realizations and business requirements of the system.
Related Artifacts: Design model
Data view
Audience: Data specialists, Database administrators
Area: Persistence: describes the architecturally significant persistent elements in the data
model as well as how data flows through the system.
Related Artifacts: Data model.
Deployment view
Audience: Deployment managers.
Area: Topology: describes the mapping of the software onto the hardware and shows the
system's distributed aspects. Describes potential deployment structures, by including known
and anticipated deployment scenarios in the architecture we allow the implementers to
make certain assumptions on network performance, system interaction and so forth.
Related Artifacts: Deployment model.

3. Architectural Goals and Constraints
There are some key requirements and system constraints that have a significant bearing on the
architecture. They are:
1. The system is meant as a proof of concept for a more complete project prediction system to
be built in the future. Therefore one of the primary stakeholders in this document and the
system as a whole are future architects and designers, not necessarily users as is normally
the case. As a result, one goal of this document is to be useful to future architects and
designers.
2. The system will be written using Microsoft .NET technologies but will use an open source
RDBMS system (MySQL) for data persistence and will be deployed to a Linux webserver
running Mono. These special deployment requirements require additional consideration in
the development of the architecture.
3. The system must communicate with multiple third-party APIs, Assembla and Google
Predictive. Defining how the system interfaces with these third-party systems is a primary
concern of the architecture.
4. Section 3.3 of the Software Requirements Specification outlines a number of anticipated

changes that the application could face over time. One of the primary goals of the system
architecture is to minimize the impact of these changes by minimizing the amount of code
that would need to be modified to implement them. The architecture seeks to do this
through the use of modularization and information hiding to isolate components that are
likely to change from the rest of the system.
4. Use-Case View
The purpose of the use-case view is to give additional context surrounding the usage of the
system and the interactions between its components. For the purposes of this document, each
component is considered a use-case actor. Section 4.1 lists the current actors and gives a brief
description of each in the overall use context of the system. In section 4.2, the most common
use-cases are outlined and illustrated using UML use-case diagrams and sequence diagrams to
clarify the interactions between components.
4.1. Actors
User
The user will drive all operation of the software. No distinction is made in regards to type
of user. The user interacts with all available interfaces to initiate and monitor all
application operations.
Assembla Client
The Assembla client serves to aid in user authentication and general assembla
accessibility.
Assembla Data Retrieval Service

The Assembla Data Retrieval Services main purpose is to act as the communication link
between the Assembla API and our application.
Assembla Data Store

The Assembla Data Store handles all storage and retrieval of saved Assembla information.
Web Portal
The web portal is the main user interface for the system.
Google Predictive Client

The Google Predictive client is the gateway into all functionality of the predictive service.
Prediction Service
The Prediction Service is the link between our application and the Google Predictive API.
4.2. Use-Case Realizations
4.2.1. Login
User credentials are authenticated and user is redirected to application home page.
Figure 4.1 Login Use Case Diagram

Figure 4.2 Login Sequence Diagram
4.2.2. Request Analysis (Get Report)

User requests a report for a user-specified project and report is displayed.
Figure 4.3 Request Analysis Use Case Diagram

Figure 4.4 Request Analysis Sequence Diagram

4.2.3. Retrieve Last Report
User requests to view the last generated report.
Figure 4.5 Retrieve Last Report Use Case Diagram
Figure 4.6 Retrieve Last Report Sequence Diagram

4.2.4. Print Report
User requests to print report.
Figure 4.7 Print Report Use Case Diagram
Figure 4.8 Print Report Sequence Diagram

4.2.5. Email Report
User requests a report be sent to a user-specified list of recipients.
Figure 4.9 Email Report Use Case Diagram
Figure 4.10 Email Report Sequence Diagram

5. Logical View
5.1. Overview
The main goal of the logical view is to define the components that will make up the system and
to define the interfaces through which they will communicate and interact with one another. The
primary decision-making factor behind defining the system components is the need to isolate
the components that are likely to change from the rest of the system. By clearly defining the
interfaces of these components and hiding their internal implementations from the rest of the
system, the impact of expected changes can be minimized. Section 3.3 of the Software
Requirements Specification outlines the changes that are likely to be made to the system. A
summary of these changes and how the logical decomposition of the architecture addresses
them is as follows:
1. Changes to the Assembla API

a. The architecture addresses this by implementing the calls to the Assembla API in
an Assembla Client component (see figure 5.1). The rest of the application will
communicate with Assembla only through the interface exposed by this
component. Therefore any changes to the system to deal with changes in the
Assembla API need only be made in the internal implementation of this
component.
2. Changes to the Google Predictive API

a. Similar to the above, this is addressed by implementing calls to the Google
Predictive API in a Google Predictive Client component (see figure 5.1).
Changes required to deal with changes to the Google Predictive API need only
be made in the internal implementation of this component and not to the rest of
the system.
3. Changes to the metrics used to construct the predictive model

a. All business logic dealing with Google Predictive, including what metrics are sent
to it to construct it’s model are isolated in a Prediction Service component (see
figure 5.1). Changes to the metrics used to construct the model need only be
made in this component without affecting the rest of the system.
4. Changes to the content of the prediction report generated for the user
a. This report is generated in the Web Portal module (see figure 5.1). As such
changes to its content need only be made in this module.

Figure 5.1 Logical Component Diagram.
Table 5.1 Element Responsibilities

Element Responsibilities
Assembla Client  Provide an interface for Assembla OAuth authentication.
 Handle all communication with the Assembla REST API
 Provide a native .NET interface for other components to use to access the
Assembla API.
Assembla Data  Provide an interface for retrieving data from Assembla
Retrieval Service  Manage the saving of data retrieved from Assembla
Assembla Data  Persist data to MySQL data store.
Store  Provide query interface to the MySQL data store.
Web Portal  Present users with an HTML-based user interface accessible through a
web browser.
 Interact with other components in the system to allow users to authenticate
with Assembla, choose an Assembla project for analysis, and analyze the
chosen project.
Google  Handle all communication with the Google Predictive API.
Predictive Client  Provide a native .NET interface for other components to use to access the
Google Predicitive API.
Prediction  Provide an interface to get a prediction for a given Assembla project.
Service  Provide an interface for providing training data to Google Predictive.

Application Data  Provide an interface to save and retrieve application specific data, for
Service example past prediction reports.
Application Data  Persist application specific data such as past prediction reports to the
Store MySQL data store.
 Provide a query interface to the application specific MySQL data store
5.2. Interface Definitions
Assembla_Client::Assembla_Client_Interface
Interface Signature
public interface IAssemblaClient
{
HttpWebResponse Milestones(string spaceId);
HttpWebResponse PublicSpaceNamesForPage(int pageNumber);
HttpWebResponse PublicSpaces();
HttpWebResponse SpaceTools(string spaceId);
HttpWebResponse TicketsByMilestone(string spaceId, string milestoneId);
HttpWebResponse UserSpaces(string accessToken);
HttpWebResponse Space(string accessToken, string spaceId);
HttpWebResponse AuthorizeUser();
HttpWebResponse GetAccessToken(string authorizationCode);
}
Operation Definitions
Milestones(string spaceId)
Description: This operation connects to the Assembla API and downloads all Milestones
associated with a particular Space as identified by the spaceId parameter.
Precondition: A valid Assembla application ID and application secret must be sent in the
request headers in order to authenticate with the Assembla API.
Postcondition: An HttpWebResponse object is returned to the caller. This object contains the
JSON formatted response containing the Milestone data. The caller is responsible for
deserializing the response.
PublicSpaceNamesForPage(int pageNumber)
Description: This operation connects to the Assembla website and downloads a specific HTML
page containing publicly available space IDs. The page to download is specified by the
pageNumber parameter.
Precondition: None
HTML content of the page requested.

PublicSpaces()
Description: This operation connects to the Assembla website and downloads the HTML page
that lists all publicly available space IDs.
Precondition: None
HTML content of the page requested.
SpaceTools(string spaceId)
Description: This operation connects to the Assembla API and downloads all Tools associated
with a particular Space as identified by the spaceId parameter.
JSON formatted response containing the Tool data. The caller is responsible for deserializing
the response.
TicketsByMilestone(string spaceId, string milestoneId)
Description: This operation connects to the Assembla API and downloads all Tickets associated
with a particular Space and Milestone as identified by the spaceId and milestoneId parameters.
JSON formatted response containing the Ticket data. The caller is responsible for deserializing
the response.
UserSpaces(string accessToken)
Description: Returns a list of spaces that the currently logged on user has access to.
Precondition: User has successfully logged on through Assembla and a valid access token has
been obtained.
JSON formatted response containing the Spaces data. The caller is responsible for deserializing
the response.

Space(string accessToken, string spaceId)
Description: This operation connects to the Assembla API and downloads all data associated
with a particular Space and user as identified by the spaceId and accessToken parameters.
Precondition: User has successfully logged on through Assembla and a valid access token has
been obtained. The user must also have access to at least one Assembla space.
JSON formatted response containing the Space data. The caller is responsible for deserializing
the response.
AuthorizeUser()
Description: Calls the Assembla API web service authorization method.
Precondition: A valid Assembla client ID must be sent in the request query string in a
parameter named “client_id”.
Postcondition: An HttpWebResponse object is returned to the caller. This object contains a

redirect to the callback URL configured for the application with Assembla. The redirect URL
will contain a query string parameter called “code” that contains the user’s authorization code.
The caller is responsible for executing this redirect and capturing the authorization code.
GetAccessToken(string authorizationCode)
Description: Calls the Assembla API method to generate an access token for an authorized
user.
Precondition: User has been authorized and an authorization code obtained through the
AuthorizeUser() method. A valid authorization code must be passed in to the
authorizationCode parameter.
Postcondition: An HttpWebResponse object is returned to the caller. This object contains a

JSON formatted response containing the access token and refresh token for the authorized user
to be used in subsequent Assembla API requests made on the user’s behalf. The caller is
responsible for deserializing this response and handling the tokens.
Assembla_Data_Retrieval_Service::Assembla_Data_Retrieval_Service_Interface
public interface IAssemblaDataService

{

void GetAllPublicSpaces();
void GetMilestones();
void GetTicketsForMilestones();
List<Space> GetSpacesForUser(string accessToken);
Space GetSpace(string accessToken, string spaceId);
}
GetAllPublicSpaces()
Description: This operation gets all public space IDs from Assembla and saves them to the
database.
Precondition: None
Postcondition: All publicly accessible space IDs are saved to the database.
GetMilestones ()
Description: This operation gets milestone data for each of the space IDs saved in the database
and saves the milestone data to the database.
Precondition: A list of space IDs is available in the database.
Postcondition: Milestone data for each space ID present in the database is saved to the database
and associated with the appropriate space ID.
GetSpacesForUser (string accessToken)
Description: This operation gets a list of all spaces that a user has access to.
Precondition: The user has successfully logged on to Assembla and a valid access token has
been obtained to pass to this method.
Postcondition: A list of Space objects is returned to the caller.
GetSpaceForUser (string accessToken, string spaceId)
Description: This operation gets data for a specific Space that a user has access to.
Precondition: The user has successfully logged on to Assembla and a valid access token has
been obtained to pass to this method. The user also has access to at least one Space.
Postcondition: A Space object is returned to the caller.
GetTicketsForMilestones ()

Description: This operation gets ticket data for each of the milestones saved in the database.
Precondition: A list of milestones and associated space IDs is available in the database.
Postcondition: Ticket data for each milestone present in the database is saved to the database
and associated with the appropriate milestone ID and space ID.
Application_Data_Service::Application_Data_Service_Interface
public interface IApplicationDataService

{
void SavePredictionReport(PredictionReport predictionReport);
PredictionReport GetLastPredictionReport(string spaceId);
}
void SavePredictionReport(PredictionReport predictionReport)
Description: This operation saves a prediction report to the application data store.
Precondition: A prediction report has been generated by Google Predictive.
Postcondition: A prediction report is saved to the database.
PredictionReport GetLastPredictionReport(string spaceId)
Description: This operation gets the last saved prediction report for a particular space.
Precondition: At least one prediction report has been previously saved to the application data
store.
Postcondition: A PredictionReport object is returned to the caller for further processing or

display.
Prediction_Client::Prediction_Client_Interface
Interface Signature
public interface IPredictionClient

{
public HttpWebResponse Analyze (string modelId)
public HttpWebResponse Delete (string modelId)
public HttpWebResponse Get (string modelId)
public HttpWebResponse Insert (string modelId)
public HttpWebResponse List ()
public HttpWebResponse Predict (string modelId)
public HttpWebResponse Update (string modelId)
public HttpWebResponse AuthorizeUser()
}
HttpWebResponse Analyze (string modelId)

Description: This operation connects to the Google Predictive API and get analysis of the
model and the data the model was trained on associated with a particular Model as identified by
the modelId parameter.
Precondition: A valid model ID and application secret must be sent in the request headers in
order to authenticate with the Google Predictive API.
JSON formatted response containing the analysis data. The caller is responsible for
HttpWebResponse Delete (string modelId)

Description: This operation connects to the Google Predictive API and Delete a trained model
associated with a particular Model as identified by the modelId parameter.
JSON formatted response containing the delete operation status. The caller is responsible for
HttpWebResponse Get (string modelId)

Description: This operation connects to the Google Predictive API and check training status of
model associated with a particular Model as identified by the modelId parameter.
JSON formatted response containing the status of the trained model if it is done or still in
progress. The caller is responsible for deserializing the response.
HttpWebResponse Insert (string modelId)

Description: This operation connects to the Google Predictive API and begin training the model
associated with a particular Model as identified by the modelId parameter.

order to authenticate with the Google Predictive API .
JSON formatted response containing the model data. The caller is responsible for deserializing
the response.
HttpWebResponse List ()
Description: This operation connects to the Google Predictive API and list available models.
JSON formatted response containing the list of models. The caller is responsible for deserializing
the response.
HttpWebResponse Predict (string modelId)

Description: This operation connects to the Google Predictive API and submit model id and
request a prediction associated with a particular Model as identified by the modelId parameter.
JSON formatted response containing the prediction. The caller is responsible for deserializing the
response.
HttpWebResponse Update (string modelId)

Description: This operation connects to the Google Predictive API and add new data to a
trained model associated with a particular Model as identified by the modelId parameter.
JSON formatted response containing the model update data. The caller is responsible for
HttpWebResponse AuthorizeUser()
Description: This operation connects to the Google Predictive API using the secrets for the
user.

Precondition: the user has already registered at Google Predictive to use its API.
JSON formatted response containing the authnitcation ID. The caller is responsible for
Prediction_Client_Service::Prediction_Client_Service_Interface
Interface Signature
public interface IPredectionClientService

{
public PredictionFeedback Predict()
public int UpdateModel(string modelId)
}
PredictionFeedback Predict()
Description: This operation is doing the actual prediction by sending the data to Google
Predictive Client and retrieving the results
Precondition: All parameters are set such as action, model name and prediction data
Postcondition: The model feedback is stored in PredictionFeedback object
int UpdateModel(string modelId)

Description: This operation updates the model at Google predictive with new data
Precondition: The model already exists at Google Predictive
Postcondition: The model has been updated from the data gathered from the collaboration
database and it will return status of failure or success
Web_Portal::Web_Portal_Interface
Interface Signature
public interface IWebPortal
{
HttpWebResponse AuthorizeUser(string url)
HttpWebResponse GetSpacesForUser(string accessToken)
HttpWebResponse RunPrediction(string spaceId)
HttpWebResponse GetLastUserReport(string userId)
}
AuthorizeUser(string url)

Description: User first visits DMM’s login page. Upon clicking ‘Login’; this operation redirects
user to the Assembla login page for authentication.
Precondition: Assembla authentication API requires client Id. The Client Id will be stored into
application’s configuration file.
Postcondition: Once user enters User Id and Password; Assembla API authenticates the user and
redirects the user to DMM’s home page.
GetSpacesForUser(string accessToken)
Description: This operation gets the project space Ids associated with the user.
Precondition: User needs to be authenticated. User Id is passed for getting the spaces.
Postcondition: User associated spaces are returned back to the user interface and those get
populated into the drop-down box. The return object is HttpWebResponse. The JSON formatted
response will be parsed at client.
RunPrediction(string spaceId)
Description: Once the user selects the project space to be analyzed and clicks the button
‘Analyze’, this operation is triggered.
Precondition: The Space Id that needs to be analyzed should be selected in the drop-down box.
Postcondition: Google Predictor API does the analysis depending upon the past training data
supplied and returns back with the analysis report that gets displayed on the user report interface.
GetLastUserReport(string userId)
Description: User is able to see the last analysis report that s/he has run previously. Clicking the
menu item, calls this operation.
Precondition: User Id needs to be passed. The model logic will look for the last report for the
specific user Id into the database.
Postcondition: The last analysis report gets displayed on user interface.
6. Data View

Figure 8.1 Static Data Structure Diagram
This diagram illustrates the static data structure and relationships of the main entities that will be stored
by the application in its database. Each element nominally represents a database table. Relationship
cardinality is denoted with UML multiplicity notation.
Figure 8.2 Data Flow Diagram

This diagram illustrates how data will flow between external entities and the DMM application. Ovals
represent external entities, tall boxes represent points where data is processed, arrows show the direction
of data flow, and short boxes represent persistent data stores.

7. Deployment View
The web application will be hosted on a single physical server. An Apache webserver running a mono
module will be used to serve the application pages. In addition, a MySql Server instance will also be hosted
on the physical server to aid the application in persisting data.
The application will interface with external APIs (Assembla, Google Predictive), of which the deployment
scenarios are not known.
The application’s deployment specifics can be seen below.
Figure 7.1 Deployment View Diagram

<<device>> Application Server
<<Web Server>> Apache
<<Execution Environment>> Mono 4.1
<<Application>> DMM Application

<<cloud>>
Assembla API
<<component>> Assembla Client
<<component>> Assembla Data Retrieval Service
Assembla Data Store
<<database system>>
MySql Server
Web Portal
Google Predictive Client
<<cloud>>
Google
Predictive API
Prediction Service
Application Data Service

Software Architecture Document Template

Uploaded by

Copyright:

Available Formats

Software Architecture Document Template

Uploaded by

Document Information

Original Description:

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Software Architecture Document Template

Uploaded by

Copyright:

Available Formats

OMSE 555/556 Software Engineering Practicum I & II

Software Architecture Document

Distributed Development Monitoring and Mining

Version Description of Versions / Changes Responsible Party Date

1.0 Initial version Shail Shimpi 2/16/13

1.1 Start of functional view Tom Mooney 3/10/13

1.2 Add the Prediction functional view Ahmed Osman 3/19/13

1.3 -Added Entity Data Model diagram

Software Architecture Document (SAD) ii Distributed Development Monitoring and Mining

The Software Architecture Document (SAD) provides a comprehensive architectural overview of

Software Architecture Document (SAD) 1 Distributed Development Monitoring and Mining

[PP]: Project Proposal

[SPMP]: Software Project Management Plan

[ConOps]: Concept of Operations

[SRS]: Software Requirements Specification

[MedBiquitous]: Sample SAD,

Software Architecture Document (SAD) 2 Distributed Development Monitoring and Mining

Use Case view

Software Architecture Document (SAD) 3 Distributed Development Monitoring and Mining

4. Section 3.3 of the Software Requirements Specification outlines a number of anticipated

Assembla Data Retrieval Service

Software Architecture Document (SAD) 4 Distributed Development Monitoring and Mining

Assembla Data Store

Google Predictive Client

4.2. Use-Case Realizations

Figure 4.1 Login Use Case Diagram

Software Architecture Document (SAD) 5 Distributed Development Monitoring and Mining

4.2.2. Request Analysis (Get Report)

Software Architecture Document (SAD) 6 Distributed Development Monitoring and Mining

Figure 4.3 Request Analysis Use Case Diagram

Software Architecture Document (SAD) 7 Distributed Development Monitoring and Mining

Software Architecture Document (SAD) 8 Distributed Development Monitoring and Mining

Figure 4.5 Retrieve Last Report Use Case Diagram

Figure 4.6 Retrieve Last Report Sequence Diagram

Software Architecture Document (SAD) 9 Distributed Development Monitoring and Mining

Figure 4.7 Print Report Use Case Diagram

Figure 4.8 Print Report Sequence Diagram

Software Architecture Document (SAD) 10 Distributed Development Monitoring and Mining

Figure 4.9 Email Report Use Case Diagram

Figure 4.10 Email Report Sequence Diagram

Software Architecture Document (SAD) 11 Distributed Development Monitoring and Mining

1. Changes to the Assembla API

2. Changes to the Google Predictive API

3. Changes to the metrics used to construct the predictive model

Software Architecture Document (SAD) 12 Distributed Development Monitoring and Mining

Table 5.1 Element Responsibilities

Software Architecture Document (SAD) 13 Distributed Development Monitoring and Mining

5.2. Interface Definitions

Software Architecture Document (SAD) 14 Distributed Development Monitoring and Mining

TicketsByMilestone(string spaceId, string milestoneId)

Software Architecture Document (SAD) 15 Distributed Development Monitoring and Mining

Description: Calls the Assembla API web service authorization method.

Postcondition: An HttpWebResponse object is returned to the caller. This object contains a

Postcondition: An HttpWebResponse object is returned to the caller. This object contains a

public interface IAssemblaDataService

Software Architecture Document (SAD) 16 Distributed Development Monitoring and Mining

Precondition: A list of space IDs is available in the database.

GetSpacesForUser (string accessToken)

Postcondition: A list of Space objects is returned to the caller.