Your SlideShare is downloading. ×
Lead Allocation System's Attribute Driven Design (ADD)
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Lead Allocation System's Attribute Driven Design (ADD)

488
views

Published on

Published in: Technology, Business

0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
488
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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.