Software Architecture: Example
Software Architecture: Example of the Order Entry System
Version: 10-11-2009
This document gives an example of the products of the Software Architecture conform the terminology of
OpenUP.
This example is not a complete Software Architecture Document!
Argumentations and detailed specifications are missing.
Table of contents
1.
Architectural goals ________________________________________________________________ 2
2.
Architectural Significant requirements _________________________________________________ 2
2.1
Non functional _________________________________________________________________ 2
2.2
Functional ____________________________________________________________________ 2
3.
Key abstractions/ Class model ______________________________________________________ 3
4.
Decisions and justification __________________________________________________________ 3
5.
Architectural Mechanisms __________________________________________________________ 4
6.
5.1
Tier model ____________________________________________________________________ 4
5.2
Component model ______________________________________________________________ 4
5.3
Layers model __________________________________________________________________ 5
5.4
Deployment model______________________________________________________________ 6
System partitioning: Increments plan__________________________________________________ 7
© HU/Leo Pruijt
1
Software Architecture: Example
1. Architectural goals


The Order Entry System is expected to have a long lifespan, so the architecture should
anticipate on:

Technological changes over time, such as new versions of middleware, operating system
or database should be anticipated.

Functional changes in the business: communication channals, products and product
structure, taxes.

Technical changes in the environment: hardware, connected software applications, …
The Order Entry System should be able to provide other systems with supporting, data
delivering services.
2. Architectural Significant requirements
2.1 Non functional
Id
NF3
NF6
NF8
Description
The system has to be able to supply services, including data
delivery and domain logic to other systems, communicating
conform open standards.
The system has to be easily extendible with new use cases or
new communication channels.
The system should migrate easily to new versions of the
middleware, operating system or database.
ISO 9126 Quality Attribute
Interoperabilty
Changeability
Portability
2.2 Functional
From the fourteen use cases specified in the use case model, the following three are architecually
the most significant:
© HU/Leo Pruijt
2
Software Architecture: Example
3. Key abstractions/ Class model
4. Decisions and justification
Decision
Justification
The architectural approach/style/pattern of the
system will be Service Oriënted Architecture.
NF3, NF6
The system will be Enterprise Java-based.
NF8
Oracle’s Application Development Framework is
chosen as the primary development framework.
NF3, NF6, NF8, scalability, productivity of
development team
…
…
© HU/Leo Pruijt
3
Software Architecture: Example
5. Architectural Mechanisms
5.1 Tier model
The tier model shows the tiers and the chosen technology per tier.
Client Tier
Web Tier
JSF
Pages
1
Browser
Business Tier
2
4
ADF
Business
Components
EIS Tier
3
Database
5
Pure
HTML
5.2 Component model
The component model shows how the business domain is partitioned into logical components.
© HU/Leo Pruijt
4
Software Architecture: Example
5.3 Layers model
The layers model shows the logical and physical layers.
5.3.1 Logical Layers and their mapping tot the Physical
Logical Layers
Mapping to ADF components
Presentation Logic
JSF
Task Specific Logic
Application modules
View objects/links
Backing bean
Domain Logic
Entity objects
Associations
Domains
Data Access Logic
JBO-library
classes
5.3.2 Physical Layers
View
Controller
Model
Business Service
Application Module
View object 1
View object 2
Business Domain
Entity object 1
Table 1
© HU/Leo Pruijt
Entity object 2
Database
Table 2
5
Software Architecture: Example
5.4 Deployment model
The deployment model shows the hardware nodes and their (network) connections, with te
assignment of components to the hardware nodes.
Deployment model
connection
Node X
Component 1
Component 4
Node Y
Component 2
Component 3
© HU/Leo Pruijt
6
Software Architecture: Example
6. System partitioning: Increments
Increment
Use Case/Functionality
M
1
Register Customer
X
Register New Product
X
Maintain Products
S
C
W
X
Maintain Employees
2

New

Update
X
X
Register Promotion
X
Register New Order
X
Maintain Orders
X
Process Customer Order
3
M
S
C
W
=
=
=
=

Shipment letter

Update Inventory

Create invoice
X
Maintain Warehouses
X
X
X
Report Sales Per Salesman
X
Order Stock For Warehouse
X
Update Inventory After Delivery
X
Maintain Locations
X
Maintain Departments
X
Must have
Should have
Could have
Want to have
© HU/Leo Pruijt
7