Oyster Safari Training Institute
SOTI-EDMS
Software Architecture Document
Version 1.0
SOTI-EDMS
Software Architecture Document
<document identifier>
Version:
1.0
Date: 20/07/07
Revision History
Date
20/07/07
Confidential
Version
1.0
Description
Software Architecture Description
SOTI, 2007
Author
Lanre Ogunkunle
Page 2 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
Version:
1.0
Date: 20/07/07
Table of Contents
1.
Introduction
4
1.1
1.2
1.3
1.4
1.5
4
4
4
5
5
Purpose
Scope
Definitions, Acronyms and Abbreviations
References
Overview
2.
Architectural Representation
6
3.
Architectural Goals and Constraints
6
4.
Use-Case View
8
4.1
9
5.
Use-Case Realizations
Logical View
10
5.1
5.2
12
13
Overview
Architecturally Significant Design Packages
6.
Process View
14
7.
Deployment View
15
8.
Implementation View
15
8.1
8.2
15
15
Overview
Layers
10.
Size and Performance
16
11.
Quality
16
Confidential
SOTI, 2007
Page 3 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
Version:
1.0
Date: 20/07/07
Software Architecture Document
1.
Introduction
[The introduction of the Software Architecture Document should provide an overview of the entire
Software Architecture Document. It should include the purpose, scope, definitions, acronyms,
abbreviations, references, and overview of the Software Architecture Document.]
This document describes a high level overview of the evolving technical architecture for the SOTI-EDMS
project. It outlines the technologies that SOTI staff, clients and management group will use for document
management, and electronic workflow processes. In facilitating easy document creation, storage, retrieval
and processing; the system will enhance staff and customer satisfaction with the business practices while
the organization will be able to reap the benefits from cost reduction, better utilization of office space,
better rate of response to events and a formidable security from natural disaster.
The document provides a high level description of the goals of the architecture. Also, it defines the use
cases support by the system architectural styles and components that have been chosen to best achieve the
use cases. The emerging framework guides the development of the design criteria and documents that
describe the technical and domain standards in detail. The detail design documents will guide the
development of the actual SOTI-EDMS
1.1
Purpose
This document provides a comprehensive architectural overview of the system, using a number of different
architectural views to depict different aspects of the system. It is intended to capture and convey the
significant architectural decisions which have been made on the system.
To describe the software accurately, this document structure is based on “4+1” model view of architecture
[KRU41].
This view gives stakeholders the ability to view the architecture from different perspectives.
1.2
Scope
The scope of this document is to depict the architecture of the SOTI-EDMS.
1.3
Definitions, Acronyms and Abbreviations
RUP : Rational Unified Process
UML: Universal Modelling Language
SAD: Software Architecture Document
Confidential
SOTI, 2007
Page 4 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
1.4
Version:
1.0
Date: 20/07/07
References
[KRU41]:
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
[RSA]:
IBM Rational Software Architect
http://www-306.ibm.com/software/awdtools/architect/swarchitect/index.html
[RUP]:
The IBM Rational Unified Process: http://www-306.ibm.com/software/awdtools/rup/index.html
1.5
Overview
[This subsection should describe what the rest of the Software Architecture Document contains and
explain how the Software Architecture Document is organized.]
The remaining section of this document is structured as follows
Section 2: Describes the architectural representation
Section 3: Contains the description of the architectural constraints of the system
Section 4: Describes the use case view
Section 4.1: Contains the description of important use-case realization.
Section 5: Describes logical view
Section 5.1: Overview of the logical view
Section 5.2: Architecture significant design packages
Section 6: Describes the process view
Section 7: describes how the system will be deployed.
Section 8: describes the implementation view
Section 9: describes the size and performance issues
Section 10: Contains description about quality.
2.
Architectural Representation
[This section describes what software architecture is for the current system, and how it is represented. Of
the Use-Case, Logical, Process, Deployment, and Implementation Views, it enumerates the views that
are necessary, and for each view, explains what types of model elements it contains.]
The views defined in “4+1” model has been utilized for the purpose of describing the architecture; RUP
naming convention will also be used for naming.
The views necessary to document the SOTI-EDMS application are:
Logical view
Confidential
SOTI, 2007
Page 5 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
Version:
1.0
Date: 20/07/07
Target Audience: Designers.
Area: Functional Requirements: describes the design's object model. Also describes the most important
use-case realizations.
Artifacts: Design model
Process view
Target Audience: Integrators.
Area: Non-functional requirements: describes the design's concurrency and synchronization aspects.
Artifacts: (no specific artifact).
Implementation view
Target Audience: Programmers.
Area: Software components: describes the layers and subsystems of the application.
Artifacts: Implementation model, components
Deployment view
Target Audience: Deployment managers.
Area: Topology: describes the mapping of the software onto the hardware and shows the system's
distributed aspects.
Artifacts: Deployment model.
Use Case view
Target 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.
Artifacts : Use-Case Model, Use-Case documents
Data view (optional)
Target Audience: Data specialists, Database administrators
Area: Persistence: describes the architecturally significant persistent elements in the data model
Artifacts: Data model.
3.
Architectural Goals and Constraints
[This section describes the software requirements and objectives that have some significant impact on the
architecture, for example, safety, security, privacy, use of an off-the-shelf product, portability, distribution,
and reuse. It also captures the special constraints that may apply: design and implementation strategy,
development tools, team structure, schedule, legacy code, and so on.]
This section describes the software requirements and objectives that have some significant impact on the
architecture
3.1
Technical Platform
The SOTI-EDMS application will be deployed on a .NET Framework using IIS 7.0 as the web server
running Windows Vista Ultimate OS. The clients will be web browsers Internet Explorer 7.0 for staff and a
variety of others from the customers ranging from FireFox to Netscape and others
Confidential
SOTI, 2007
Page 6 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
3.2
Version:
1.0
Date: 20/07/07
Transaction
The EDMS application has many transactions of high importance. The transactional abilities of the system
come from the underlying framework that will be utilized. The .NET framework, IIS Server, Windows OS,
SQL Server 2005 are all powerful tools with high performance and scalability.
3.3
Security
The system must be secured, so that only authorized users will have access level priviledges
The application must implement basic security behaviors:

Authentication: Login using at least a user name and a password

Authorization: according to their profile, organization’s customers must be granted permission to
perform some specific actions on the system in accordance with the specified rules
For all types of access, the following requirements are required:
3.4

Confidentiality: sensitive data must be encrypted (credit card payments)

Data integrity : Data sent across the network cannot be modified by a tier

Auditing: Every sensitive action can be logged

Non-repudiation : gives evidence a specific action occurred
Persistence
This issue will be addressed using a relational database.
3.5
Reliability/Availability
System availability is of high importance. The candidate architecture is expected to have failover
capabilities. Reliability/Availability will be addressed through the .NET platform
Targeted availability is 23.5/7: 23.5 hours a day, 7 days a week
The time left (30 minutes) is reserved for any maintenance activities
3.6
Performance
This system is expected to have high performance abilities. The system should have high response time,
should be able to scale very well.
Confidential
SOTI, 2007
Page 7 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
4.
Version:
1.0
Date: 20/07/07
Use-Case View
[This section lists use cases or scenarios from the use-case model if they represent some significant, central
functionality of the final system, or if they have a large architectural coverage - they exercise many
architectural elements, or if they stress or illustrate a specific, delicate point of the architecture.]
This section lists use cases or scenarios from the use-case model that represent some significant, central
functionality of the final system. There are five use-cases with a significant impact on the SOTI-EDMS.
Confidential

The Capture Document Use Case

The Create Workflow Use Case

The Manage Workflow Use Case

The Manage Document Use Case

The Manage System Use Case
SOTI, 2007
Page 8 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
Confidential
Version:
1.0
Date: 20/07/07
SOTI, 2007
Page 9 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
Version:
1.0
Date: 20/07/07
5.
Logical View
5.1
Overview
SOTI-EDMS is divided into layers according to the N-Tier Architecture
The layering model of the EDMS solution is based on a responsibility layering strategy that associates each
layer with a particular responsibility.
This strategy is well adapted because it isolates various system responsibilities from one another, so that it
improves both system development and maintenance
Confidential
SOTI, 2007
Page 10 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
Version:
1.0
Date: 20/07/07
Each layer has specific responsibilities.

The presentation layer is concerned with the presentation logic and the rendering of pages

The control layer deals with management of access to the domain layer

The resource layer is responsible for access to the data store

The domain layer manages accesses to the resource layer.

The Common Elements layer collects the common objects reused through all the layers
The SOTI-EDMS 1.0 is a web based application that contains four basic features
Confidential

Capture Feature: For capturing documents

Store Feature: For storing electronic documents and data

Work Flow Feature: For handling office processes

Distribute Feature: For disseminating information
SOTI, 2007
Page 11 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
5.2
Version:
1.0
Date: 20/07/07
Architecturally Significant Design Packages
1. Distribute Package is responsible for disseminating electronic information captured in the datastore in
different format. It can print or plot or viewing.
Confidential
SOTI, 2007
Page 12 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
Confidential
Version:
1.0
Date: 20/07/07
SOTI, 2007
Page 13 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
Version:
1.0
Date: 20/07/07
Basic Flow:
2.
6.
Process View
The .NET framework will handle threading and processing issues.
Confidential
SOTI, 2007
Page 14 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
Version:
1.0
Date: 20/07/07
7.
Deployment View
8.
Implementation View
8.1
Overview
[This subsection names and defines the various layers and their contents, the rules that govern the inclusion
to a given layer, and the boundaries between layers. Include a component diagram that shows the relations
between layers. ]
8.2
Layers
8.2.1
Presentation Layer
This layer contains all the components needed to allow interactions with an end-user. It encompasses the
user interface
8.2.2
Control Layer
Control layer is the container for all the components used to access the domain layer or directly the
resource layer when this is appropriate.
8.2.3
Resource Layer
This layer contains the components needed to enable communication between the business tier and the
enterprise information systems (Database, external services, ERP, etc…)
8.2.4
Domain layer
The Domain layer contains all the components related to the business logic. It gathers all the subsystems
that meet the needs of a particular business domain. It also contains the business object model.
.
Confidential
SOTI, 2007
Page 15 of 16
SOTI-EDMS
Software Architecture Document
<document identifier>
Version:
1.0
Date: 20/07/07
8.2.5
Common Elements Layer
The layer contains the components re-used within several layers.
9.
Size and Performance
Volumes:

Estimated Request: 10,000 – 50,000 a day.

Registered Users is in the range of 8,000 - 10000

Registered Customers is about 50,000
Performance:

10.
Time to respond to request : less that 10 seconds required
Quality
As far as the online catering application is concerned, the following quality goals have been identified:
Scalability:

Description : System’s reaction when user demands increase

Solution : .NET application servers support several workload management techniques
Reliability, Availability:

Description : Transparent failover mechanism, mean-time-between-failure

Solution : : .NET framework and SQL server database application server supports load balancing
through clusters
Portability:

Description : Ability to be reused in another environment

Solution : The system me be fully compatible with Linux and Unix Operating Systems
Security:
Confidential

Description : Authentication and authorization mechanisms

Solution : Windows Vista, SQL Server and .NET framework all provide native security
mechanisms that will be adequate for this system.
SOTI, 2007
Page 16 of 16