Download 3 Logical View

RDA e-Store Architecture Document
1 Introduction
The architecture of a software system requires six distinct views, each view focusing on different aspects of the
system. Its purpose is to communicate the major components of the system, how it is structured, the system process
flows, and major interfaces. From a high level, the goal is to examine the system from several different perspectives,
each providing a different “view” in order to capture all critical system features. A brief description of the six
architecture views is provided as follows:
Deployment View – This view documents the physical topology of the system modeled in the Deployment Model.
It includes each computer in the implementation and describes how they are interconnected. The configuration for
each node is also specified – Operating system, databases, Commercial off-the shelf (COTS), and custom
applications.
Logical View – The logical view documents the Design Model, which defines the layers of the application and the
primary classes within each layer. The system architect identifies patterns of functionality and creates common
mechanisms to provide this functionality to several areas across the application.
Data View – Classes in the logical view are classified as transient or persistent. The persistent classes are mapped
to structures on disk, usually into a combination of rows in a relational database. An entity-relationship data model
describes the database schema. This view also communicates how the Object-Oriented classes are mapped to the
relational tables.
Process (Concurrency) View – This view focuses on the concurrency aspects of the system and how they contend
for shared resources (i.e., transaction semantics, etc.). The process view documents the independent threads of
execution within the system and describes how they communicate. It also lists the resources in contention by these
threads and the transaction model for maintaining integrity with these resources.
Implementation View – This view maps the classes in the Logical View to physical source files and combines the
files into deployable components. The implementation view also tracks the dependencies among the components.
Security View – This view focuses on how the system identifies end users, grants authorization to them based on
their identity, ensuring integrity of the system and of the data and properly tracking and auditing of system activity.
Note: This is a brief overview of the architecture. The complete eStore SAD is included in the download.
www.itflightplan.com
Copyright © 2002 RDA Corporation
Page - 1
www.rdacorp.com
Feedback: [email protected]
RDA e-Store Architecture Document
2 Deployment View
The configuration view presents the topology and its physical and logical connections.
eStore Users
RDA Pet Store DB ...
Router
Internet
RDA Pet Store Web Server
www.itflightplan.com
Copyright © 2002 RDA Corporation
Page - 2
www.rdacorp.com
Feedback: [email protected]
RDA e-Store Architecture Document
3 Logical View
The logical view presents the core design of the system. It presents the primary classes that collaborate to
implement the system functionality. It contains the following subsections:
 Three Software Layers
 Business Layer Interface
 Business Layer Implementation
3.1 Three Software Layers
The application is structured along three distinct layers – UI Layer, Business Layer and Data Layer.

UI Layer 


Business Layer 

Data Layer 

Web Pages
Images
UI Reusable Components
Business Objects
Business Layer Reusable Components
Data Layer Interface
SQL Server tables
Stored procedures
UI Layer: Responsible for authentication, presentation and managing session state.
Business Layer: Exports the business objects defined in the Solution Model class analysis. Maintains no
knowledge of presentation. Insulates the UI Layer from database design. Responsible for complex business rule
logic.
Data Layer: Responsible for managing persistent data and transactions. Maps business objects to physical
relational tables. Responsible for data integrity, transactions and data intensive business rules such as unique name
on a column.
www.itflightplan.com
Copyright © 2002 RDA Corporation
Page - 3
www.rdacorp.com
Feedback: [email protected]
RDA e-Store Architecture Document
3.2 Business Layer Interface
The following diagram illustrates the classes and their relationships exported from the business layer to the
presentation layer.
MaintainBillingOrder
MaintainShippingAddr
ConfirmAddresses
OrderConfirmed
Payment
«head»
Order
- BillTo, ShipTo
- AcctAddr
Location
- parent
MaintainAccount
«directory, head»
Account
SignInWelcome
ConfirmAccountSaved
- BillTo, ShipTo
- Owner
Person
PetStoreUserAccount
- parent
«directory»
AccountDirectory
The context of these
instances is for a
single web session.
- parent
BusLayerUserAcct
Home
DisplayCatetory
DisplayProduct
DisplayItem
SearchProducts
MaintainCart
ConfirmCart
- parent
Cart
LineItem
Static, cached
objects shared
across all web
sessions
Category
Product
Item
SKU
Figure 1: UI Session Stack Class Diagram
3.3 Business Layer Implementation
Pet Store’s business layer is implemented by leveraging the services provided by IT FlightPlan’s Software Library.
The business classes exported by the business layer are either BusinessClasses or ReferenceClasses. IT FlightPlan’s
Software Library exports a BusinessClass base, abstract class and an IReferenceClass interface. The following
diagram shows how the classes in the business layer are implemented – the session BusinessClasses inherit from
BusinessClass while the cached classes implement the IReferenceClass interface.
www.itflightplan.com
Copyright © 2002 RDA Corporation
Page - 4
www.rdacorp.com
Feedback: [email protected]
RDA e-Store Architecture Document
BusinessClass
IReferenceClass
Category
Product
SKU
Item
Cart
+ «get» PK ( )
+ setChangedFlag ( )
+ «get» isHead ( )
~ «get» version ( )
+ «get» parent ( )
+ findAuthenticatedUser ( )
+ getRoot ( )
+ isAnInsert ( )
+ checkBusinessRules ( )
+ appendToStream ( )
+ loadFromHashTable ( )
~ toBusObjsStream ( )
+ save ( )
PetStoreUserAccount
Location
«head»
Order
LineItem
«directory»
AccountDirectory
Payment
«directory, head»
Account
Person
www.itflightplan.com
Copyright © 2002 RDA Corporation
Page - 5
www.rdacorp.com
Feedback: [email protected]
RDA e-Store Architecture Document
4 Data View
The Database Model is presented as a logical view, physical view and data dictionary. The logical data model is
included in this overview.
www.itflightplan.com
Copyright © 2002 RDA Corporation
Page - 6
www.rdacorp.com
Feedback: [email protected]
RDA e-Store Architecture Document
4.1 E/R Model
4.1.1
Logical View
www.itflightplan.com
Copyright © 2002 RDA Corporation
Page - 7
www.rdacorp.com
Feedback: [email protected]
RDA e-Store Architecture Document
5 Process View (Concurrency)
The Process View focuses on the parallel processing aspects within the system. eStore deals with concurrency in
two distinct areas 1.
The CPU/process/thread design
2.
Transaction design for shared resources,
A. Records in the PetStore database – single data source
B. Updates to PetStore database and the Credit Authorizer
C. Shared objects in memory
5.1 CPU/Process/Thread Design
HTTPResponse
HTTPRequest
Web Server
Web Worker
Thread Pool
IIS
HTTP
Listener
eStore .Net app
DBConn
DBConn
DBConn
get
Pooled DB Connections
in shared memory
DB Server
DB Worker Thread Pool
DB
Listener
SP
Thread
This diagram shows the major threads and context switches involved with processing a web request. IIS allocates a
pool of worker threads to process HTTP requests and posts.
5.2 Transaction Design
5.2.1 PetStore Database transactions
All transactions are encapsulated within a call from the BusinessLayer to a stored procedure. Any SQL errors
within a stored procedure force a rollback and the error is raised to the BusinessLayer.
Account data integrity is maintained through optimistic concurrency. A unique version timestamp is returned with
each head Account object.
www.itflightplan.com
Copyright © 2002 RDA Corporation
Page - 8
www.rdacorp.com
Feedback: [email protected]
RDA e-Store Architecture Document
5.2.2 Updates to PetStore database and the Credit Authorizer
There is one point in the application where there are two distinct data sources, so this leads to a critical region in the
code. ConfirmAddresses invokes CreditAuthorizer to charge the customer’s credit card. If successful, it returns a
credit authorization code, which is stored in the Payment when the Order is saved. We have an exposure in the case
where the charge is successful, but Order.save() fails. CreditAuthorizer does not support two-phased commit
transactions, so RDA Pet Store will continue to reconcile its daily charges with the Credit Authorizer at the close of
each business day.
5.2.3 Shared Objects in Memory
The static reference objects that are shared across all sessions have only one instance per web server. All sessions
refer to this single instance. Since these classes are loaded when the application starts and are not modified,
semaphores are not required for synchronization.
www.itflightplan.com
Copyright © 2002 RDA Corporation
Page - 9
www.rdacorp.com
Feedback: [email protected]
RDA e-Store Architecture Document
6 ImplementationView
The implementation view describes how the software is physically contained in files and how files combine to form
components. At the highest level, the application is comprised of packages.
RDAEStoreCS contains the
presentation layer. It uses the
business layer to interact with the
business objects and IT FlightPlan
SWLib to access the reusable UI
utilities - such as binding business
attributes to UI controls.
The business layer exports the
business objects modeled in the To
BeAnalysis model to RDAEStoreCS
ITFlightPlanSWLib encapsulates many
common CRUD patterns into a single,
reusable component and is independent of
business application domain.
The DataLayer comprises the DB
tables, initial reference data and
the stored procedures required to
implement CRUD the business
objects.
RDAEStoreCS
BusinessLayer
ITFlightPlanSWLib
DataLayer
The 3 layers outlined in the Logical View (UI, Business and Data) are implemented with the above packages as
follows –
UI Layer:
 RDAEStore[CS, VB] - all aspx, code behinds, images and Pet Store UI utilities
 ITFlightPlanSWLib - generic UI utilities to bind/unbind attributes to UI controls
Business Layer:
 BusinessLayer[CS, VB] - all of the Pet Store business classes
 ITFlightPlanSWLib packages – reusable mechanisms the provide persistence and error handling\
Data Layer:
 DataLayer – the Pet Store tables, stored procedures and reference data
 ITFlightPlanSWLib – Generic wrapper interface to access ADO
www.itflightplan.com
Copyright © 2002 RDA Corporation
Page - 10
www.rdacorp.com
Feedback: [email protected]
RDA e-Store Architecture Document
7 Security View
The security view describes how the system implements the security requirements specified in the Detailed Spec.
Security design is presented in the following sub-areas.




User Identification & Authentication – How does the system identify users and verify it is them?
Authorization – Once authenticated, who is allowed to do what?
Data Integrity and Privacy – Ensure the integrity of the data is not compromised.
Non-repudiation and Auditing – Ensure the end user cannot cover up their tracks. Record access to the data
so we know who’s done what.
7.1 User Identification & Authentication

eStore uses ASP.Net Forms authentication to authenticate users.

UserIDs and passwords are stored in the RDAPetStore database. Passwords are first “sha1”, 40-byte
encrypted before being stored in the database.

The eStore application itself authenticates with its own SQL Server userID. The ID and password is stored
in the web.config file. The only the database objects granted to the eStore userID are execute grants to the
eStore stored procedures.
7.2 Authorization - Data Entitlement
eStore uses a single stored procedure – getAccountForUserID – to fetch the account information for a particular user
and stores it in the session stack.
Since the authenticated user contained in the session stack, eStore relies on the integrity of .Net sessions to ensure
that users can only access their own accounts.
7.3 Data Integrity and Privacy
V1.0 of RDA Pet Store provides minimal protection of data. Passwords are encrypted before they are stored in the
database.
Extending Pet Store to be more secure, we would use SSL to transmit password and credit card information.
7.4 Non-repudiation &Auditing
Each table in the database provides last modified by and last modified timestamp columns. The authenticated
userID parameter on the save stored procedure is set in these columns on all inserts and updates.
www.itflightplan.com
Copyright © 2002 RDA Corporation
Page - 11
www.rdacorp.com
Feedback: [email protected]