1. A3 INC.:
LEAD ALLOCATION SYSTEM ATTRIBUTE DRIVEN DESIGN
Draft: 1
Date: June 10, 2009
Authors: Ali Raza (aliraza@csu.fullerton.edu)
Amin Bandeali (amin.bandeali@csu.fullerton.edu)
Arash Sharif (asharif@csu.fullerton.edu)

2. CONTENTS
1. Introduction 1
1.1. What is ADD 1
1.2. Applying ADD in Real World 1
1.2.1. Step 1: Inputs 1
1.2.2. Step 2: Requirement Conformation: 1
1.2.3. Step 3: Identify all elements 1
1.2.4. Step 4: Choose the element 1
1.2.5. Step 5: Identify architecture Drivers 1
1.2.6. Step 6: Initiate the architectural patterns and allocate the responsibilities1
1.2.7. Step 7: Define interface for instantiated elements 1
1.2.8. Step 8: Verify and refine requirements and make them constraints for
instantiated element. 2
1.2.9. Step 9: Repetition 2
2. Software Architecture Design - LAS 2
2.1. Introduction 2
2.2. Function Requirements 2
2.2.1. Acquire Lead 2
2.2.2. Allocate Lead 2
2.3. Design constraints 2
2.3.1. SLA (Service Level Agreement) 2
2.3.2. Performance 2
2.3.3. Operating Environment 3
2.4. Quality Attribute Requirement 3
2.4.1. Availability 3
2.4.2. Security 3
2.4.3. Modifiability 3
3. Attribute Driven Design 3
3.1. Inputs 3
3.1.1. Functional Requirements 3
3.1.2. Constraints 3
3.1.3. Quality Scenarios 4
3.2. First Iteration 4
3.2.1. Choose an Element to Decompose 4
3.2.2. Identify Candidate Architecture Drivers 4
3.2.3. Choose Design Concept that Satisfies Architectural Drivers 5
3.2.4. Instantiate Architectural Elements and Allocate Responsibilities 9
3.2.5. Verify and refine requirements and make them constraints for instantiated
elements 11
3.3. Second Iteration 11
3.3.1. Confirm there is Sufficient Requirement Information 11
3.3.2. Identify Candidate Architecture Drivers 12
3.3.3. Choose Design Concept that Satisfies Architectural Drivers 12
3.3.4. Instantiate Architectural Elements and Allocate Responsibilities 14
3.3.5. Define interfaces for Instantiated Elements 14
3.3.6. Verify and refine requirements and make them constraints for instantiated
elements 15

3. LAS - ADD 1
1.Introduction
1.1.What is ADD
The ADD Attribute Driven Design approach is developed by SEI. It is a method
where we can achieve the software architecture by decomposing process on the
quality attributes base on the Software Requirement Specification. ADD follows a
recursive process that decomposes of the system element by applying architectural
tactics and patterns that satisfy its driving quality attribute requirement.
In ADD architectural drivers are such as function requirement, design constraints and
quality attribute requirement.
This document focuses on choosing the selected patterns and models, which used to
determine whether the architecture satisfies the architecture drivers.
1.2.Applying ADD in Real World
Following are the steps for Software Architecture Design by using ADD.
1.2.1.Step 1: Inputs
The inputs for ADD are functional requirements, quality attribute requirements and
constraints.
1.2.2.Step 2: Requirement Conformation:
Confirm there is sufficient requirements information in order to apply ADD method
1.2.3.Step 3: Identify all elements
List all the elements based on the requirements
1.2.4.Step 4: Choose the element
Choose the element of the system to decompose
1.2.5.Step 5: Identify architecture Drivers
Identify the architectural drivers for the elements which have chosen for the
decomposition
1.2.6.Step 6: Initiate the architectural patterns and
allocate the responsibilities
Initiate the architectural patterns and allocate the responsibilities by using the
tactics, quality attribute and assign the responsibilities based on the requirements for
the particular decomposed element
1.2.7.Step 7: Define interface for instantiated
elements
This step will documents what others (elements) can use and on what they can
depend however this is different from the signature. This step also analyzes the

4. LAS - ADD 2
decomposition element in terms of structure (view), concurrency view and runtime
(deployment view) which uncovers the interaction assumptions for the child
modules. We must document three views such as restart, deployment and
Data integrity. We also need to evaluate the alternative patterns by using the
mentioned views.
1.2.8.Step 8: Verify and refine requirements and
make them constraints for instantiated element.
The decomposition thus far must be verified and if the child module needs more
decomposition then we much be prepare for their own decomposition by using
functional requirements, constraints and quality scenarios.
1.2.9.Step 9: Repetition
Need to Repeat from Step 4 to Step 8 until all the elements get decomposed.
2.Software Architecture Design - LAS
2.1.Introduction
The Lead Allocation System (LAS) project will allocate any lead to the partner who
placed the highest bid. The process will now become more efficient for marketing
department, customers and partners.
2.2.Function Requirements
2.2.1.Acquire Lead
Lead providers shall be able to allocate leads through the LAS. Lead providers could
be other web or middleware systems.
2.2.2.Allocate Lead
Allocate Lead is the feature of the LAS which will allow partners to view lead based
on their zip code and ssn; then bid on the full lead to purchase.
2.3.Design constraints
2.3.1.SLA (Service Level Agreement)
During the lead allocation process the partners shall be able to place a bid on the
lead(s) for a period of 5 second, a time period that the lead shall be locked. After 5
secs the bids of the partners that responded shall be analyzed. System shall allocate
leads to the highest bidder.
2.3.2.Performance
The system shall allocate the lead no later than 8 sec and would concurrently process
no more than 10 leads at one time. If the system would receive more than 10 leads,
it would queue the rest and process them as a FIFO.

5. LAS - ADD 3
2.3.3.Operating Environment
Web Server: Windows IIS 6.0
Database: SQL server 2005
Runtime Environments: .NET CLR (Server)
Browsers: MS IE 6.0+, Firefox 1.2+
OS: Windows 2003 Server
2.4.Quality Attribute Requirement
2.4.1.Availability
LAS shall be available 24 hours a day, 7 days a week, 365 days a year bearing
significant hardware malfunction. It might be wise to consider a separate system in
the future to detect faults in LAS and restart it if need be. There shall be a backup
system that could be
2.4.2.Security
Every request need to authenticate and every response need to authorize by using
Active Directory (AD)
2.4.3.Modifiability
LAS needs to control the time and cost to implement during the development,
testing, and fixing phase. Also LAS must use object oriented paradigm in order to
achieve the modifiability quality attribute.
3.Attribute Driven Design
3.1.Inputs
3.1.1.Functional Requirements
Reviewing the Software Requirement Specification we see that there are two system
features that encapsulate three use cases. The system features are the following:
Acquire Lead - Lead providers shall be able to allocate leads through the LAS. Lead
providers could be other web or middleware systems.
Allocate Lead - Allocate Lead is the feature of the LAS which will allow partners to
view lead based on their zip code and SSN, then bid on the full lead to purchase.
3.1.2.Constraints
Reviewing the Software Requirement Specification there are several constraints that
we need to consider. They are the following:
• End product will be DLL(s) that can be referenced by different types of
applications, including Web Services.
• The runtime environment will be the .NET CLR.
• OOD shall be used with a clear separation of objects that consume data and
objects that produce data.

6. LAS - ADD 4
• Interfaces between components shall be designed to only take primitive types
and return primitive types.
3.1.3.Quality Scenarios
• The system needs to allocate the lead no later than 8 sec and would
concurrently process no more than 10 leads at one time. If the system
receives more than 10 leads, it should handle them using a queue.
• LAS needs to be available 24 hours a day, 7 days a week, 365 days a year
bearing significant hardware malfunction. The LAS architecture should
accommodate this using some sort of backup system.
• LAS should only allow trusted sources access to API calls. If the API calls are
from un-trusted sources, then LAS should deny access.
• The API calls should be secure so that malicious third party persons/software
cannot view information going to and from the LAS.
3.2.First Iteration
Confirm there is Sufficient Requirement Information
After reviewing the inputs, the architecture team has determined that there sufficient
requirements information.
3.2.1.Choose an Element to Decompose
Since this is the first iteration, the architecture team has decided to start at the root,
which is LAS.
3.2.2.Identify Candidate Architecture Drivers
Reviewing the Input section of this document the architecture team found the
following Architectural drivers and their priorities:
# Architectural Section Importance Difficulty
Drivers Discussed
In
1 Scenario 1 1.3 Medium High
Allocate Lead
Performance
2 Scenario 2 1.3 Medium Medium
System availability
3 Scenario 3 1.3 High Medium
Trusted access only
4 Scenario 4 1.3 High Medium
Secure access
5 Requirement 1 1.1 High Medium
Acquire Lead
6 Requirement 2 1.1 High High
Allocate Lead
7 Constraint 1 1.2 Medium Low
Compiled DLLs
8 Constraint 2 1.2 Medium Low
Run in .NET CLR
9 Constraint 3 1.2 Medium Low
OOD used
10 Constraint 4 1.2 High Low

7. LAS - ADD 5
Primitive API calls
only
3.2.3.Choose Design Concept that Satisfies
Architectural Drivers
3.2.3.1.IDENTIFY DESIGN CONCERNS
The architecture team reviewed the candidate architectural drivers and identified
some design concerns with them. They are listed in the table below.
AD# Design Concern
1 Performance, Resource Arbitration
2 Availability, Fault Recovery
3 Security, Resisting Attacks
4 Security, Resisting Attacks
5 Modifiability, Prevent Ripple Effect
6 Modifiability, Prevent Ripple Effect
7 Modifiability, Localize Modification
8 Modifiability, (N/A)
9 Modifiability, Prevent Ripple Effect
10 Modifiability, Localize Modification
3.2.3.2.LIST ALTERNATIVE PATTERNS THAT ADDRESS THE CONCERNS
After reviewing the candidate architectural drivers the architecture team determined
that several patterns and tactics can be used to achieve them. They are listed in the
following matrix:
AD # Design Pattern (pros/cons) Pattern (pros/cons)
Concern
1 Performance - FIFO Fixed-Priority
Resource Pros- Easy to Pros- Flexibility for
Arbitration implement priority
Cons – No flexibility Cons – Difficult to
for priority implement
2 Availability – Spare Active Redundancy
Fault Recovery Pros – Easy to Pros – Data will be
configure up to date. Also,
Cons – Data will not recovery time will
be up to date and be milliseconds.
recovery time will be Cons – Need
minutes. additional
monitoring and
switching software
3 Security - Limit Access Authorize users
Resisting Pros – High Security Pros – Dynamic.
Attacks Cons – Need to know Easy to modify
IP address of Cons – Need
incoming request additional software
such as Active
Directory
4 Security – Authenticate Users Maintain Data

8. LAS - ADD 6
Resisting Pros – Easy to use in Confidentiality
Attacks conjunction with Pros – Software
Authorize users such as SSL exist
Cons – Need and is easy to
additional software implement
or man power to Cons – Need to
manage user purchase SSL
registration certificate.
5 Modifiability, Hide information Use an
Prevent Ripple Pros – Traditional. Intermediary
Effect People are most Pros – Easy to
familiar with it understand.
Cons – Depends Cons – Tedious to
strongly on skills and implement.
talents of the person
implementing it.
6 Modifiability, Hide information Use an
Prevent Ripple Pros – Traditional. Intermediary
Effect People are most Pros – Easy to
familiar with it understand.
Cons – Depends Cons – Tedious to
strongly on skills and implement.
talents of the person
implementing it.
7 Modifiability – Maintain Semantic Limit Possible
Localize Coherence Options
Modifications Pros – Creates Pros – Requires
reusability as well as zero development
preventing ripple time
effects Cons – Requires
Cons – Time senior
consuming. Requires management buy
talented in
professionals.
8 N/A N/A N/A
9 Modifiability, Hide information Use an
Prevent Ripple Pros – Traditional. Intermediary
Effect People are most Pros – Easy to
familiar with it understand.
Cons – Depends Cons – Tedious to
strongly on skills and implement.
talents of the person
implementing it.
10 Modifiability – Generalize the Anticipate Expected
Localize Module Changes
Modifications Pros – Makes Pros – Fits in nicely
communication with with Maintain
modules much Semantic
simpler. Coherence pattern.
Cons – Makes the Cons – Difficult to
inner workings of the determine what to
module somewhat anticipate for.
more complex, hence

9. LAS - ADD 7
requiring more
qualified people.
3.2.3.3.SELECT PATTERNS FROM THE LIST AND GIVE RATIONALE
• For AD # 1 the architecture team selected the FIFO pattern. The reason for
this was mainly because of the simplicity of implementing such a pattern and
although it does not exceed the requirements, it certainly meets them. Also,
there are resources on the team that are very familiar with this pattern
• For AD # 2 the architecture team selected Active Redundancy pattern. This
choice was because the team decided that since the spare is not up to date
and it takes minutes to recover it is vastly inferior to the Active Redundancy
pattern.
• For AD # 3 the architecture team selected Authorize Users patterns. This
choice was because the team decided that limiting access to certain IP
addresses was really not practical for a web based application since managing
client IP addresses would be too restrictive and sometimes, not possible.
• For AD # 4 the architecture team decided that both Authenticate Users and
Maintain Data Confidentiality patterns will be required because of their
relationship to each other. They have good synergy and really cannot exist
without coexisting in this instance.
• For AD # 5 the architecture team selected Hide Information pattern. This
choice was because of the natural nature of this pattern and also because of
the tedious nature of the Use an Intermediary pattern.
• For AD # 6 the architecture team selected Hide Information pattern. This
choice was because of the natural nature of this pattern and also because of
the tedious nature of the Use an Intermediary pattern.
• For AD # 7 the architecture team selected Maintaining Symantec Coherence
pattern. This choice was made because the architecture team decided that
depending on management to limit possible options, even though they might
agree initially, is not realistic.
• N/A
• For AD # 9 the architecture team selected Hide Information pattern. This
choice was because of the natural nature of this pattern and also because of
the tedious nature of the Use an Intermediary pattern.
• For AD #10 the architecture team decided that a combination of both the
Generalize the Module and Anticipate Expected Changes pattern would be a
good way to go. The reason for this choice was because since the API for the
LAS needs to work for other platforms having the inner workings of the
middleware adjust based on the primitive input types would be ultra helpful.
To have this architecture team decided that it would have to think 2 steps
ahead and anticipate what changes would occur.
3.2.3.4.CONSIDER THE PATTERNS IDENTIFIED SO FAR AND DECIDE HOW
THEY RELATE TO EACH OTHER
After examining the patterns identified so far, the architecture team decided to use
event-driven architecture (EDA) to allow loosely coupled objects and packages a way
of communication. This type of architecture meets and exceeds the patterns
identified so far. The description of EDA is outside the scope of this document.
3.2.3.5.CAPTURE PRELIMINARY ARCHITECTURAL VIEWS
Since this is the first iteration, the architecture team determined the following
component UML as an appropriate high level view for the EDA pattern.

10. LAS - ADD 8
LAS API Adapter Dispatch Allocate Lead Event
Listen Allocate Lead Event
Allocate Lead Service

11. LAS - ADD 9
3.2.4.Instantiate Architectural Elements and Allocate
Responsibilities
3.2.4.1.INSTANTIATE ELEMENTS
Lead Allocation System (LAS)
LAS API Adapter
Allocate Lead Service
Acquire Lead Service
Lead Providers
Allocate Lead FIFO computation Lead Acquirers
Security Service
Redundant LAS Redundant LAS Redundant LAS
Server 1 Server 2 Server 3
3.2.4.2.ASSIGN RESPONSIBILITIES TO ELEMENTS ACCORDING TO PATTERN
TYPE
Element # Element Name Architectural Driver Pattern (s)
1 LAS API Adapter 7, 8, 9, 10 Generalize the
Module,
Hide information,
Maintain Semantic
Coherence,
Anticipate Expected
Change
2 Acquire Lead Service 5 Hide information
3 Allocate Lead 6 Hide information
Service
4 Allocate Lead FIFO 1 FIFO
computation
5 Security Service 3, 4 Authenticate Users,

12. LAS - ADD 10
Maintain Data
Confidentiality,
Authorize Users
6 Redundant LAS 2 Active Redundancy
servers 1, 2, 3
3.2.4.3.ALLOCATE RESPONSIBILITIES ASSOCIATED PARENT ELEMENT
AMONG ITS CHILDREN.
• LAS API Adapter – This element is responsible for receiving API calls,
interpreting them and passing them along to other elements.
• Acquire Lead Service – This element is responsible for receiving leads from
lead providers and preparing them to be allocated to lead acquirers.
• Allocate Lead Service – This element is responsible for providing lead heading
to lead acquirers that ask for it. It is also responsible for accepting bids and
sending complete leads to lead providers.
• Allocate Lead FIFO – This element is responsible for the FIFO algorithm
computation to handle multiple lead acquirers requesting leads
simultaneously.
• Security Service – This element is responsible for making sure only trusted
lead providers and lead acquirers have access to LAS and they are who they
say they are.
• Redundant LAS server 1, 2, 3 – These elements would act as mirrored
duplicates in case the primary LAS server experiences problems.
3.2.4.4.DEFINE INTERFACES FOR INSTANTIATED ELEMENTS
Element Requires Provides
LAS API Adapter Primitive type input from TO LEAD PROVIDER: A
lead providers or lead lead recorded successful
acquirers. This would be message and transaction
lead information from the reference number.
lead providers and lead TO LEAD ACQUIRER: A
request information from lead heading. An interface
lead acquirers. It would to allow the lead provider
also require trusted user to place a bid, and the full
information such as a lead if the lead acquirer
username and password. decided to buy the lead.
The interface should also
provide a transaction
reference number.
TO ACQUIRE LEAD
SERVICE: The lead
information
TO ALLOCATE LEAD
SERVICE: The request for
a lead information
Acquire Lead Service FROM LAS API ADAPTER: TO SECURITY SERVICE:
Lead information. Trusted Trusted user information
user information
Allocate Lead Service FROM LAS API ADAPTER: TO ALLOCATE LEAD FIFO
Lead request information. COMPUTATION: Lead
Lead bid information. request information. Lead
Trusted user information bid information.
TO SECURITY SERVICE:

13. LAS - ADD 11
Trusted user information
Allocate Lead FIFO FROM ALLOCATE LEAD TO ALLOCATE LEAD
Computation SERVICE: Lead request SERVICE: Lead request
information. Lead bid from queue. Lead bid
information. from queue.
Security Service FROM ACQUIRE LEAD TO ALLOCATE LEAD
SERVICE: Trusted user SERVICE: Trusted user
information security information
FROM ALLOCATE LEAD TO ACQUIRE LEAD
SERVICE: Trusted user SERVICE: Trusted user
information security information
Redundant LAS servers 1, N/A N/A
2, 3
3.2.5.Verify and refine requirements and make them
constraints for instantiated elements
After careful review of the elements, their responsibilities and their interfaces, the
architecture team decides that all the architectural drivers (functional requirements,
constraints, and quality scenarios) have been accounted for.
3.3.Second Iteration
3.3.1.Confirm there is Sufficient Requirement
Information
This step is not necessary for the second iteration since it was done once at the
beginning of the ADD process.
3.2 Step 2. Choose an Element to Decompose
Current knowledge of the architecture
The security service element has chosen as the system to decompose. Specifically
when acquire lead and allocate lead services are targeted as per section 2.6.
3.3.1.1.RISK AND DIFFICULTY
Since this element is depending upon the third party active directory therefore it is
very difficult to achieve the element associated requirements.
In order to decompose this element, active directory component should be setup and
the users profiles need to be inserted.
3.3.1.2.BUSINESS CRITERIA
Security element plays a vital role in the system as per SRS.
Partners need to be in active directory before LAS system broadcast the lead.
Secure Certificate Layer needs to be set before LAS will go live
3.3.1.3.ORGANIZATIONAL CRITERIA

14. LAS - ADD 12
Security has been identified a highest priority for the LAS as per the business vision
and SRS because this element has an direct impact on the overall LAS
3.3.2.Identify Candidate Architecture Drivers
# Architectural Section Importance Difficulty
Drivers Discussed
In
1 Scenario 1 2.4.2 High High
Authorize User
2 Scenario 2 2.4.2 High Medium
Authenticate Users
3 Scenario 3 2.6 High Medium
Trusted access only
4 Constraint 1 2.6 High Low
Active Directory
3.3.3.Choose Design Concept that Satisfies
Architectural Drivers
3.3.3.1.IDENTIFY DESIGN CONCERNS
The architecture team reviewed the candidate architectural drivers and identified
some design concerns with them. They are listed in the table below.
AD# Design Concern
1 Security, Resisting Attacks, Authorize User
2 Security, Resisting Attacks, Authenticate User
3 Security, Resisting Attacks, Maintain integrity
4 Modifiability, Localize changes, Prevent Ripple Effect
3.3.3.2.LIST ALTERNATIVE PATTERNS THAT ADDRESS THE CONCERNS
After reviewing the candidate architectural drivers the architecture team determined
that several patterns and tactics can be used to achieve them. They are listed in the
following matrix:
AD # Design Pattern (pros/cons) Pattern (pros/cons)
Concern
1 Security - Access Matrix / N/A
Resisting Authorization [1]
Attacks, Pros – Flexible
Authorize User Cons – Need
additional resources
to maintain the user
profile and their roles
2 Security – Authenticate Users N/A
Resisting Pros – Reduce time,
Attacks, because for
Authenticate authenticate

15. LAS - ADD 13
User Enterprise uses
active directory
Cons – Needs extra
resource for the
configuration.
3 Security, Maintain Integrity N/A
Resisting Pros – Software such
Attacks, as SSL exist and is
Maintain easy to implement
integrity Cons – Need to
purchase SSL
certificate.
4 Modifiability, Prevent Ripple Effect N/A
Localize Pros – Enterprise
changes, standard, and easy
Prevent Ripple to configure
Effect Cons – Need to add
every partner.
Select patterns from the list and give rationale
There is no other alternative pattern has been identified for the each AD in section
3.4.2.
3.3.3.3.CONSIDER THE PATTERNS IDENTIFIED SO FAR AND DECIDE HOW
THEY RELATE TO EACH OTHER
After examining the patterns identified so far, the architecture team decided to check
point security architecture for authentication and authorization of LAS by using AD.
Figure below will illustrate this pattern

16. LAS - ADD 14
3.3.4.Instantiate Architectural Elements and Allocate
Responsibilities
3.3.4.1.INSTANTIATE ELEMENTS
(Need to change following diagram where Security component needs to take out
from the LAS). Draw a diagram that how active directory, database for the user
profile and gateway needs to be interact with security component
LAS LAS Active Directory
Gateway
Service
s
User Role
3.3.4.2.ASSIGNDatabase
RESPONSIBILITIES TO ELEMENTS ACCORDING TO PATTERN
TYPE
Element # Element Name Architectural Driver Pattern (s)
1 Active Directory 1, 4 Authenticate,
Prevent Ripple
Effect
2 User role database 2 Access Matrix /
Authorization
3 Gateway of LAS 3 Maintain Integrity
3.3.4.3.ALLOCATE RESPONSIBILITIES ASSOCIATED PARENT ELEMENT
AMONG ITS CHILDREN.
1. Active Directory: When users will try to invoke any LAS services, this element will
authenticate the users first and then allow users to entre in to the system
2. User role database: for the authorization level of the LAS services a database
needs to be created where user profiles will be stored.
3. Gateway: A new gateway needs to be purchased from the third party for secure
socket layer and configure it
3.3.5.Define interfaces for Instantiated Elements
Element Requires Provides
Active Directory A setup and configuration It provides authentication
need to require for entire and a system will be
LAS services. secure after implementing
this element.
User role database A setup as well as tables It provides authorization

17. LAS - ADD 15
needs to be created for for LAS services.
each and every LAS
service user. And also
identify the role.
Gateway Set up and configuration It provides the 128 bit
for LAS system. encryption for the entire
LAS system.
3.3.6.Verify and refine requirements and make them
constraints for instantiated elements
After careful review of the elements, their responsibilities and their interfaces, the
architecture team decides that all the architectural drivers (from the iteration 1)
have been accounted for.