Oyster Safari Training Institute

treescattleSoftware and s/w Development

Nov 2, 2013 (4 years and 6 days ago)

125 views



Oyster Safari Training Institute



SOTI
-
EDMS

Software Architecture Document


Version 1.0






SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page
2

of



Revision History

Date

Version

Description

Author

20
/
07
/
07

1.0

Software Architecture Description

Lanre Ogunkunle














SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page
3

of



Table of Contents

1.

In
troduction

4

1.1

Purpose

4

1.2

Scope

4

1.3

Definitions, Acronyms and Abbreviations

4

1.4

References

5

1.5

Overview

5

2.

Architectural Representation

6

3.

Architectural Goals and Constraints

6

4.

Use
-
Case View

8

4.1

Use
-
Case Realizations

9

5.

Logical View

1
0

5.1

Overview

12

5.2

Architecturally Significant Design Packages

13

6.

Process View

14

7.

Deployment View

15

8.

Implementation View

15

8.1

Overview

15

8.2

Layers

15

10.

Size and Performance

16

11.

Quality

16

SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page
4

of



Software Architectur
e 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
managem
ent, 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 supp
ort by the system architectural styles and components that have been chosen to best achieve the
use cases. The emer
ging framework guides the development of the design criteria and documents that
describe the technical and domain standards in detail. The de
tail 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 t
he ability to view the architecture from different perspective
s.


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


SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page
5

of



1.4

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/arc
hitect/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 th
e 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:

D
escribes the architectural representation

Section 3:

C
ontain
s the
descri
ption of

the architectural constraints of the system

Section 4:

D
escribes the
use case view

Section
4.1
:

Contains the
descri
ption of

important use
-
case realization.

Section
5
:

D
escribes
logical view

Section 5.
1: Overview of the logical view

Se
ction 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:

C
ontains 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 enumera
tes 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

SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page
6

of



Target
Audience
: Designers.

Area
: Functional Requirements: d
escribes 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
dis
tributed 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 m
odel.



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, distr
ibution,
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 s
taff and a
variety of others from the customers ranging from FireFox to Netscape and others



SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page
7

of



3.2

Transaction


The
EDMS

application
has many

transaction
s 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

customer
s

must be granted
permission to

perform some specific actions
on the system in accord
ance with the specified rules

For
all types of
access, the following requirements are
required:



Confidentiality: sensitive data must be encrypted (credit card payments)



Data integrity : Data sent across the network cannot be modified by a tier



Auditing: Ev
ery sensitive action can be logged



Non
-
repudiation :
gives evidence a specific action occurred


3.4

Persistence


This issue

will be addressed using a relational database.


3.5

Reliability/Availability


System

availability

is
of
high importance
. The candidate ar
chitecture
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 activit
ies



3.6

Performance


Th
is system is expected to have high performance abilities
.

The system should have high response time,
should be able to scale very well.



SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page
8

of



4.

Use
-
Case View

[This section lists use cases or scenarios from the use
-
case model if they repres
ent 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.



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
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page
9

of







SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page


of




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 lay
ering 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

improve
s

both system development and maintenance


SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page


of





Each layer has s
pecific 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
d
omain 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



Capture Feature: For capturing document
s



Store Feature: For storing electronic documents and data



Work Flow Feature: For handling office processes



Distribute Feature: For disseminating information

SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page


of





5.2

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.

SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page


of










SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page


of



Basic Flow:








6.

Process View

The .NET framework will handle threading and processing issues.

SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page


of



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 L
ayer

Th
is

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
contain
er 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.

.

SOTI
-
EDMS


Version: 1.0

Software Architecture Document


Date: 20
/
07
/
07

<document identi
fier>


Confidential


SOTI
, 200
7

Page


of



8.2.5

Common Elements Layer

The layer contains the components re
-
used within sever
al 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:



Time to respond to request : less that 10 seconds required



10.

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 tec
hniques

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
:



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.