MorseStewardOSDocs/ProductDocumentation/Design-Architecture.md

##### Project

::PROJECT-NAME(Home)

##### Internal Release Number

::X.Y.Z

##### Related Documents

- [Design](Design) > Design Architecture
- [Software Requirements Specification](SRS)
- [Glossary](Glossary)
- ::LINKS TO RELEVANT STANDARDS
- ::LINKS TO OTHER DOCUMENTS

---

*TODO: Answer the questions below to help you define your system
architecture. Some example text is provided.*

### Overview

#### What are the most important facts that a developer should know about this system architecture?

::PARAGRAPH OR BULLETS

#### What software architecture style is being used?

- ::Single-process desktop application (with plug-in extension modules).
- ::Client-server with a custom thick-clients and server.
- ::2-tier web application: webserver/app-server, database.
- ::3-tier web application: webserver, app-server, database.
- ::Single web service: app-server, database.
- ::Network of web services.
- ::Peer-to-peer with/without central server.
- ::Pipe-and-filter.
- ::Computing grid / distributed servers.

#### What are the ranked goals of this architecture?

1. ::[Ease of integration](Glossary-Standard-Terms#ease_of_integration)
2. ::[Extensibility](Glossary-Standard-Terms#extensibility)
3. ::[Capacity matching](Glossary-Standard-Terms#capacity_matching)

### Components

#### What are the components of this system?

::The components of this system are clearly defined in this [UML Model
  with Component Diagram](LINK-TO-MODEL).

::The components of this system are listed below by type:

- ::Presentation/UI Components
  - ::[C-00: COMPONENT-NAME](Design-Components#c-00)
- ::Application Logic Components
  - ::[C-10: COMPONENT-NAME](Design-Components#c-10)
- ::Data Storage Components
  - ::[C-20: COMPONENT-NAME](Design-Components#c-20)

### Deployment

#### How will the components be deployed to processes and machines?

::The deployment of components to processes and machines is clearly
defined in this [UML Model with Deployment Diagram](LINK-TO-MODEL).

::The deployment of components to processes and machines is clearly
defined below:

- ::All-in-one server
  - ::Tomcat process
    - ::[C-00: Tomcat web server](Design-Components#c-00)
    - ::[C-10: PROJECT-NAME
      application](Design-Components#c-10)
  - ::Database process
    - ::[C-20: COMPONENT-NAME](Design-Components#c-30)

::The deployment of components to processes and machines is clearly
defined below:

- ::Load-balanced front-end servers
  - ::[C-01: COMPONENT-NAME](Design-Components#c-00)
- ::Back-end server
  - ::JVM process
    - ::[C-00: COMPONENT-NAME](Design-Components#c-00)
    - ::[C-10: COMPONENT-NAME](Design-Components#c-10)
    - ::[C-11: PLUG-IN COMPONENT-NAME](Design-Components#c-11)
    - ::[C-12: PLUG-IN COMPONENT-NAME](Design-Components#c-12)
  - Database process
    - ::[C-20: COMPONENT-NAME](Design-Components#c-30)

#### What aspects/resources of their environment are shared?

::Everything is on one server so all machine resources are shared by
all components.

::All machines share the same bandwidth to the Internet. All machines
access the same file server. So, if one component uses the resources
heavily, other components may have to wait.

#### How are requests allocated to redundant or load-balanced servers?

::We are not doing any load-balancing or redundancy for fail-over.

::Load-balancing among front-end servers is handled by a load
balancing device that we can make very few assumptions about.
However, once a user session is established, the same front-end
server will be used for all requests during that session.

#### What alternative deployment configurations are possible?

::This is the only possible deployment.

::The database could be moved to a different machine with a fairly
simple change to a configuration file. Otherwise, nothing can be
changed about the deployment.

::We have the ability to move the database process to a
separate machine. We have the ability to add more front-end servers.
The application logic running on the application server cannot be
split or load-balanced.

### Integration

#### How will components be integrated? Specifically, how will they communicate?

::All of our code uses direct procedure calls. The database is
accessed through a driver.

::Components within the same process use direct procedure call or
standard Java events. Plug-ins are also accessed through a API of
direct procedure calls and standard events. Communication with the
database uses a JDBC driver. Communication between the front end-and
back-end servers uses XML-RPC.

#### What architectural mechanisms are being used to ease future extensions or modifications?

::We could change the database by switching drivers. Otherwise,
extensions and modifications can only be done at the design level.

::New front-end components could be added so long as they access the
back-end the same way. New plug-in components can be dynamically
loaded, so long as they satisfy the plug-in API. Otherwise, there is
no ability to add or exchange components, because this architecture
uses direct dependencies between its components rather than
implicit invocation. Extensions and modifications can be made at the
design-level, but deploying those changes requires recompilation
and down-time.

### Architectural Scenarios

*TODO: Provide architecture scenarios that show how objects will
communicate across components, processes, and machines. Focus on
scenarios where the architecture itself is changing, e.g., system
startup, shutdown, adding or upgrading components, load balancing or
fail-over.*

The following sequence diagrams give step-by-step descriptions of how
components communicate during some important usage scenarios:

- ::[System startup](LINK-TO-DIAGRAM)
- ::[System shutdown](LINK-TO-DIAGRAM)
- ::[SCENARIO NAME](LINK-TO-DIAGRAM)

### Architecture Checklist

*TODO: Evaluate your architecture with respect to each of your goals.*

#### Ease of integration: Have mechanisms been provided for all needed types of integration?

::Yes. In this system, all of the new components are designed to
work together. And, the reused components are integrated via fairly
simple interfaces.

#### Extensibility: What types of components can be added later and how?

::See above.

#### Capacity matching: How has this architecture matched component resource needs to machines?

::The database can be on a machine with RAID disks and a hot-swappable
power supply, while the web front-end components can be on cheaper
machines that could fail individually without causing
system downtime. The front-end web servers and application server
are both CPU-intensive, so they are deployed to different CPUs. The
database is disk-intensive, so it can be deployed to the same
machine as the CPU-intensive application server, with only moderate
competition for resources.

#### Has the architecture been communicated to the development team and other stakeholders?

::Yes, everyone understands. Feedback is welcome.

::No, this is a risk that is noted in the [Risk Management](Project-Plan#Risk-Management) section.