Using ATAM for Architecture Evaluation

Project Paper Using ATAM for Architecture Evaluation Software Architecture and Component Based Design SEN-565 S.M. Saiful Islam ID # 0712004 Program – M.Sc. in SE May 17, 2008 1. INTRODUCTION............................................................................................................................. 3 1.1 BACKGROUND ............................................................................................................................... 3 1.2 OBJECTIVES ................................................................................................................................... 3 1.3 STUDIED PROJECT INFO ................................................................................................................. 3 1.4 COMPANY INFO ............................................................................................................................. 3 1.5 CLIENT INFO .................................................................................................................................. 3 2. MATERIALS AND METHODS ..................................................................................................... 3 3. PROJECT DESCRIPTION ............................................................................................................. 4 3.1 BUSINESS OVERVIEW .................................................................................................................... 4 3.2 SYSTEM OVERVIEW – WORK PROCESS ......................................................................................... 4 4. ARCHITECTURAL APPROACHES............................................................................................. 5 4.1 ARCHITECTURE OVERVIEW........................................................................................................... 5 4.1.1 Client Tier .............................................................................................................................. 6 4.1.2 Server Tier ............................................................................................................................. 7 4.1.3 Database Tier......................................................................................................................... 7 4.1.4 File Server, Print Server, Email Server and Fax Server........................................................ 7 4.2 ARCHITECTURAL FEATURES ......................................................................................................... 7 5. SCENARIOS ..................................................................................................................................... 8 5.1 USE CASE SCENARIOS ................................................................................................................... 8 5.2 GROWTH SCENARIOS .................................................................................................................... 9 5.3 EXPLORATORY SCENARIOS ........................................................................................................... 9 6. QUALITY ATTRIBUTES ............................................................................................................... 9 6.1 PERFORMANCE ............................................................................................................................ 10 6.2 MODIFIABLITY ............................................................................................................................ 10 6.3 SCALABILITY ............................................................................................................................... 10 6.4 AVAILABILITY ............................................................................................................................. 10 6.5 RELIABILITY ................................................................................................................................ 10 6.6 SECURITY .................................................................................................................................... 10 6.7 MODULARITY .............................................................................................................................. 10 6.8 TESTABILITY ............................................................................................................................... 10 6.9 REUSABILITY ............................................................................................................................... 11 7. UTILITY TREES (WITH PRIORITY)........................................................................................ 11 8. RISK AND NON-RISK ANALYSIS ............................................................................................. 12 9. SENSITIVITY POINTS................................................................................................................. 17 10. TRADE-OFF POINTS ................................................................................................................. 17 11. CONLUSION ................................................................................................................................ 17 1. Introduction 1.1 Background Software architectural analysis should be a key practice for Software development or procurement organization, as because architectures are complex and involve many design tradeoffs. Without undertaking a formal analysis process, the organization cannot ensure that the architectural decisions made—particularly those which affect the achievement of quality attribute such as performance, availability, security, and modifiability— are advisable ones that appropriately mitigate risks. 1.2 Objectives The main objective of doing this Project is to applying ATAM (Architecure Trade-off Analysis Method) to evaluate the Software Architecture of a completed project. The specific objective of this work is as follwos: Using ATAM to understand the consequences of architectural decisions with respect to the quality attribute rquirements for a completed project I worked on. 1.3 Studied Project Info A completed project named KAA (Key Account Application) developed by the ITNet Ltd for a Danish company named Enren Denmark A/S (www.Enren.dk) for performing this study. This project at present is running in production environment and passing through the maintenance phase. The overview of this project has been given in the later section. 1.4 Company Info The ITNet Limited (www.ITNet.com ) is a leading software outsourcing company in Bangladesh which is providing primarily software services to the Nordic countries. This company is a sister concern of the Danish IT company ITcare A/S (www.ITcare.dk). Though this is a new company, yet it has already completed a number of projects successfully which are now in maintenance phase. 1.5 Client Info The Enren (www.Enren.com) is the leading search company in the Nordic media market. Enren makes it easy to find people, businesses and products using directories, directory assistance, Internet and mobile services. Enren has operations in Sweden, Norway, Finland, Denmark and Poland. Enren offers the best channels for buyers and sellers who want to find each other. These channels currently include directories (offline), directory assistance (voice), Internet and mobile services (online). Strong brands and high usage of Enren’s products and services make it attractive for advertisers to participate. Enren’s services are largely financed by advertising and free of charge for users. Directory assistance by telephone, on the other hand, is financed by users. The direct client of the project KAA is Enren Denmark A/S (www.Enren.dk). 2. Materials and Methods For preparing this document, I have taken the most recent project in which I played the key role and I have full access to all resources. The major architectural decisions of this project were made by the Enren IT Department which is comprised of Architect, DBA and other IT personnel. The architectural decisions were mostly influenced by their legacy systems compatibility. Client architecture has been decided by ITNet. As this is post project evaluation, that’s why all the available documents and other work products have been consulted and this document has been prepared. No stake holders could have been contacted for interview. 3. Project Description 3.1 Business Overview One of the major business area of Enren is to publish different directory like Yellow Pages. Enren publishes more than 700 directories in the Nordic countries. Enren Denmark alone publishes more than 300 directories in Denmark. These directories (relevant ones) are available wholeover the country - all offices, public places, shops, houses for free. But, these books contain huge number of advertisements. Advertising in these books are highly costly. These advertisements generates huge revenue for Enren per year. There is millions of customers who give advertisement in these books. So, selling these advertisement is a huge task. There is two type of customer - Core Customer and Key Account Customer. This project - KAA only focuses on supporting the sales and registration procedures for Key Accounts. 3.2 System Overview – Work Process An overall view of the major entities in KAA is shown below. Key Account $ $ Sales report Offer Offer: Køge 2006 Vejle 2007 Køge 2006, Vejle 2007 Total: 12500,- Order lines Payment plan ----------------------------------------------------------------------01/01: 5000,01/04: 5000,01/07: 2500,Order confirm Payment plan overview Figure 1 – Major System Entities All items in the figure 1 shaped as a document illustrates a report/letter printed from the application. The customer is the main entity in the application and all actions is based on these. A normal work process would be: 1. A Key Account is selected 2. Offer is created (and printed) by the salesperson/supporter when the Key Account is prepared. Preparing simply means that all information such as phonebook ads, Key Account overview and Key Account Offer is printed and collected to prepare the sales person for a customer visit. 3. When the order is received from the customer (by fax or letter) an order confirmation is sent to the customer. 4. The order lines are added to a payment plan and registered in Daisy. 5. Payments are then added to the payment plan and an order confirmation and payment plan overview is printed by the sales supporter and sent to the Key Account. 6. Sales reports can be printed to follow-up on the sales effort. 4. Architectural Approaches 4.1 Architecture Overview KAA is basically a 3-Tier Database Centric Application. KAA has to handle millions of records of customer and order information. It works collaborating with many other legacy system. The database is huge big in terms of data volume and number of tables. Following is the high level view of overall system architecture: Client User Interface Layer PNUIFramework UI Framework Client Service Interface Util Application Server Eniro Internal Application Server (EIAS) Eniro Service API (ESA) Service Layer Web Interface Business Layer Service Layer Web Interface Business Layer Entity Layer Data Provider Hibernate Entity Layer EJB Persistence Eniro Server Framework (ESF) J2EE Server (JBoss Application Server) Email Server Fax Server Print Server Database Servers Daisy Samas Timba File Server Fics Figure 2 – SKAA System Architecture 4.1.1 Client Tier The KAA client tier is comprised of several layers and services. KAA User Interface layer is Java Swing client. This is the top most layer of this architecture. The User Interface layer is built on top of PNUIFramework and UIFramework. All of the three layers use Utility Services. There is one interface layer to communicate with the Application Server. The client will run using Java Webstart Technology over Intranet or Internet. The client runs on many different platforms like MS Windows, Apple Mac OS, Linux, etc. 4.1.2 Server Tier The Server Tier is the Middle Tier. It is the application server. It is comprised of three major layers/services viz. EIAS (Enren Internal Application Server), ESA (Enren Service API) and ESF (Enren Server Framework). Both EIAS and ESA have Service Layer and Entity Layer. The Service Layers of both EIAS and ESA are comprised of Service Interface, Web Service Interface and Business Logic Layer. The communication occurs with the client tier with the help of service interface. The Business Logic Layer implements most of the business logics of the application. The Entity Layer is responsible for data access and data manipulation. In EIAS the entity layer uses Hibernate technology. In the ESA, the entity layer uses EJB persistence directly. Both of EIAS and ESA are built on top of ESF. The Entity Layer is independent on underlying database server, i.e. the database server could be Oracle, DB2, etc. The ESF provides some common services to EIAS and ESA. All together comprise Enren Server Area. This Server Part runs on J2EE Application Server named JBoss Application Server. The application server runs Linux Cent OS platform. 4.1.3 Database Tier The database tier is the end tier of this architecture. As I have stated earlier, Enren uses three different legacy database named “Daisy”, “Samas” and “Timba”. There huge complex business logic has been implemented. Many other legacy applications use these databases. KAA cannot work alone; it is interrelated and interdependent with other system. The database is maintained in Oracle. The Oracle runs on Linux Cent OS platform. 4.1.4 File Server, Print Server, Email Server and Fax Server In addition to JBoss Application Server, it uses File server that handles huge volumes of Scanned Files and Ads. The Letters are maintained in JBoss Server. The different type of distribution of the documents is handled in the relevant servers. And all sorts of distribution of documents are tracked in the Samas database. 4.2 Architectural Features The architectural approaches used in KAA have been described in the following table. SL. No Architectural Feature Related Architectural Concept Multi -tier Architecture Database-centric Architecture Client Server Architecture Service Oriented Architecture 1 2 The overall structures comprised of 3 distinct Tiers. More tiers can be extended like web tier. The database plays very crucial roles in this application. Huge business logic has been implemented in database by means of stored procedures, triggers, views etc. Controlling access to the same key account is controlled by the application server tracking the client request. Many services are being used by KAA viz. XLetter Services, XPP Services for creating and distributing different Offer letter, Order confirmation letter, Print Proof, 3 4. SL. No Architectural Feature Related Architectural Concept etc. SOAP is being used for accessing many of these services. 5. 6. There is many search operation is done in KAA. The search is conducted on sometimes billions of records. The KAA client is completely made multi threaded. It is possible to work in many different UIs and run many operations in the in the same client application. All user interaction is initiated from the User Interface in response to the user actions. Search Oriented Architecture Parallel Process Architecture Event Driven Architecture 7. 5. Scenarios Three types of scenarios have been discussed here. 5.1 Use Case Scenarios • • • • • • • • The user wants to see key account list in 10 seconds. S/he wantsto see key account list using paging. Changing the page should not more than 5 seconds. The user needs to create a new key account and remove an existing key account based on the permission. The user wants to search departments and associate with an existing key account. Showing the department list shouldn’t take 10 seconds. The user wants to create key account offer in 2 seconds. The user wants to copy previous order lines from the payment plan or daisy system to the current key accunt offer. This copy should not take more than 10 seconds. The user wants to create new order line in 5 seconds. During order line creation s/he wants to handle main product, extra product, ad and alternative address. The user wants to copy an order line to many similar books. This copy should not take more than 10 seconds. The user wants to recalculate the order line prices for a key account offer. The recaculation should adjust excess prices as discount and need to distribute proportionately to the all order lines. The user wants to create new Payment Plan from an Key account offer. This opertion shouldn’t take more than 5 seconds. The user wants to add a new key account offer to an existing payment plan. The user wants to complete this in 5 seconds. The user wants to update many order lines at the same time using replace funtion. This function shouldn’t take more than 20 seconds. The user wants to register payment plan in 10 seconds. The user wants to print customer letters in 5 seconds. The user wants to lock a key account when s/he will be working on it so that other can’t get • • • • • • write access to this key account. • • • • The user needs to import production plan for the current period. This function shouldn’t take more than 10 minutes. The user should be able to search Key account, Copmpay, Sales Person, Book, Product, Ad, Heading, Placement, Additional Product. Any search shouldn’t take more than 10 seconds. The user should be able to test the companies for making key account. This test process shouldn’t take more than 20 seconds. The user might need to change the ordering process. Some steps might not be required and new steps need to be added. 5.2 Growth Scenarios • • • • • Using Multiple window for the single client application might be required. Using web client and mobile client application in addition to the distributed desktop application might be required. Synchronization of client correspondens, events, tasks with third party tools like Microsoft Outlook might be required. In addition to the handling of offline (print) orders, the online orders handling might also be required. A customer web interface might be required so that they can review their orders, review the ads and generate change requests or make approvals. 5.3 Exploratory Scenarios • • • • • • • • • The order frequency increases 10 times - 100 books per week (at present) can be increased to 1000 books per week. The offer volume increases 10 times - 100 order lines per key account offer can be increased to 1000 order lines per key account offer. The number of the customer increases by 100 per cent - 1000000 can be increased to 100000000. Change the underlying Linux Platform to the windows platform. Add a new web client in Dot Net platform in less than 10 person months. Incorporate online customer sales functionality in less than 5 person months. Migrate the database platform from Oracle to DB2 in less than 6 person months. The remote client access should be 99.999 % secure. The transaction processing should be 99.999 % secure. 6. Quality Attributes For designing the KAA architecture following quality attributes have been taken into consideration: • • Performance Modifiability • • • • • • • Scalability Availability Reliability Security Modularity Testability Reusability 6.1 Performance Performance is the one of the Key quality attribute for the KAA. For, doing search operation; creating key account, offer, order line; generating customer letters; registering payment plan and importing production plan should meet performance requirement. 6.2 Modifiablity Modifiability is also important quality attribute for KAA. KAA needs to handle different business process modification. There new steps would be required to be introduced and some steps/features might required to be with held or discarded. KAA should be flexible enough to support this modification. 6.3 Scalability Scalability is an important quality attribute for KAA. The number of customrs and volume of orders are increasing rapidly. That’s why KAA will be required to scaled. Therefore, this is an essential quality attribute. 6.4 Availability Availability of KAA should be 99.99%. The sales persons will be using this application all the time. So, availability of KAA has to be ensured to high degree. 6.5 Reliability KAA should be reliable for handling any platform change, database change. This should be fault tollerant. 6.6 Security KAA should be fully secure application. Sales Persons usually access application using VPN remotely. This access should be cotroll. Any unauthorised should be controlled. 6.7 Modularity KAA should be modular enough. Any changes in a partcular module should affect the other module in a minimum level. 6.8 Testability KAA should have test driven architecture. All features should be designed in that way so, that test cases can be generated and tested accordingly. 6.9 Reusability KAA should have a resuable architecture and reusable components. Many components and services need to be used which are common/suitable for other Enren applications as well. 7. Utility Trees (With Priority) Utility trees provide a top-down mechanism for directly and efficiently translating the business drivers of a system into concrete quality attribute scenarios. Following tree describes the quality attribute scenarios for KAA. Show key account list in 10 seconds Change list page in 5 seconds Show department list in 10 seconds Create key account offer in 2 seconds Performance Data Latency Copy function in 10 seconds Create new order line in 5 seconds Create/Add to Payment Plan in 5 seconds Replace order lines in 20 seconds Print customer letters in 5 seconds Import Production Plan in 10 minutes New Product categoris Modifiability Exisnting Feature Change Add online product functionality in 5 person months Add new Java web client Add new Dot Net web client Change orderering process in 2 person months Introduce Multiple window in 3 person months The order frequency increases 10 times Scalability Work volume increase The offer volume increases 10 times The number of the customer increases by 100 per cent Utility H/W Failure Power outage to Application Server 1 requires traffice redirect to Application Server 2 in 3 seconds Applicatin Server restarts in 5 minutes Power outage to Database Server 1 requires traffice redirect to Database Server 2 in 3 seconds Availability Database Server restarts in 7 minutes Network failure is detected and recovered in 3 minutes S/W Failure Applicaton Server service failure is detected in 5 seconds Application Server service restarted in 1 minute SOAP service failure is detected in 5 seconds and restarted in 10 seconds Database service failure is dected in 3 seconds and restarted in 10 seconds Reliability New Platform Change the underlying Linux Platform to the windows platform Migrate the database platform from Oracle to DB2 in less than 6 person months Data Confidentiality Security Data Integretiy The remote client access should be 99.999 % secure. The transaction processing should be 99.999 % secure. Same key account access is controlled by multiple user The system is divided into many 13 modules Modularity System decomposition User Interface Usability User Interfces are highly interactive. User can process data in multiple window simultaneously Work flow is clearly identified System boundaries are well defined. Testabliliy Test case generation Component oriented Reusability Services, domain functions, and application functions are distributed in components 8. Risk and Non-Risk Analysis Risks are potentially problematic architectural decisions. Non-risks are good decisions that rely on assumptions that are frequently implicit in the architecture. The risk and non-risk architectural decisions for KAA have been documented in the following table. SL. No. 1 Quality Attribute Scenario Architectural Concept Risk / Non-Risk (R/NR) Rationale Performance Show key account list in 10 seconds Change list page in 5 seconds 3-Tier NR This will meet the quality requirements This may not meet the quality requiremetns. Search Oriented Architecture would be better option This may not meet the quality requiremetns. Search Oriented Architecture would be better option This will meet the quality requirements This will meet the quality requirements This will meet the quality requirements This will meet the quality requirements This will meet the quality requirements This will meet the quality requirements This will not meet the quality requirement. Multi processed pipeline would be beter. This will meet the quality requirements 2 Performance 3-Tier R 3 Performance Show department list in 10 seconds 3-Tier R 4 Performance Create key account offer in 2 seconds 3-Tier Database Centric 3-Tier Database Centric 3-Tier Database Centric 3-Tier Database Centric 3-Tier Database Centric Service Oriented 3-Tier Database Centric NR 5 Performance Copy function in 10 seconds NR 6 Performance Create new order line in 5 seconds NR 7 Performance Create/Add to Payment Plan in 5 seconds NR 8 Performance Replace order lines in 20 seconds NR 9 Performance Print customer letters in 5 seconds Import Production Plan in 10 minutes NR 10 Performance R 11 Modifiability Add online product functionality in 5 person months 3-Tier Database NR SL. No. Quality Attribute Scenario Architectural Concept Risk / Non-Risk (R/NR) Rationale Centric 12 Modifiability Add new Java web client Add new Dot Net web client Multi-Tier NR This will be possible to add new web tier This will be possible to add new web tier using web service This might be difficult. Plug In would be better option. This will be possible to change Java client tier to multiple window This will be possible to scale the server component for increased order frequency. This will be possible to scale the server component for increased volume. This will be possible to scale the server component for increased customer. Meets the quality attribute 13 Modifiability Multi-Tier NR 14 Modifiability Change orderering process in 2 person months Introduce Multiple window in 3 person months The order frequency increases 10 times Multi-Tier R 15 Modifiablity Event Driven NR 16 Scalability Three Tier NR 17 Scalability The offer volume increases 10 times Three Tier NR 18 Scalability The number of the customer increases by 100 per cent Three Tier NR 19 Availablity Power outage to Application Server 1 requires traffice redirect to Application Server 2 in 3 seconds Applicatin Server restarts in 5 minutes Power outage to Database Server 1 requires traffice Multi Tier with Redundant Server NR 20 Availability Multi Tier with Redundant Server Multi Tier with Redundant Server NR Meets the quality attribute Meets the quality attribute 21 Availability NR SL. No. Quality Attribute Scenario Architectural Concept Risk / Non-Risk (R/NR) Rationale redirect to Database Server 2 in 3 seconds 22 Availability Database Server restarts in 7 minutes Network failure is detected and recovered in 3 minutes Applicaton Server service failure is detected in 5 seconds Application Server service restarted in 1 minute SOAP service failure is detected in 5 seconds and restarted in 10 seconds Database service failure is dected in 3 seconds and restarted in 10 seconds Change the underlying Linux Platform to the windows platform Multi Tier with Redundant Server Multi Tier with Redundant Server Multi Tier with Redundant Server Multi Tier with Redundant Server Multi Tier with Redundant Server Multi Tier with Redundant Server Multi Tier NR Meets the quality attribute Meets the quality attribute Meets the quality attribute Meets the quality attribute Meets the quality attribute 23 Availability NR 24 Availability NR 25 Availability NR 26 Availability NR 27 Availability NR Meets the quality attribute 28 Reliability NR Meets the quality attribute. As Java is platform independent that’s why it would be easy. It would be very difficult to migrate to DB2. For being the database centric application, many objects – procudures, functions in database which might required to be changed. Meets the quality requirement. Multi level security has been given. Network, 29 Reliability- Migrate the database platform from Oracle to DB2 in less than 6 person months Multi Tier Database Centeric R 30 Security The remote client access should be 99.999 % secure. Multi Tier NR SL. No. Quality Attribute Scenario Architectural Concept Risk / Non-Risk (R/NR) Rationale Application server and Database. 31 Security The transaction processing should be 99.999 % secure. Same key account access is controlled by multiple user Three Tier Database Centric Client Server R NR Meets the sequirity requirement 32 Security Doesn’t meet the security requirement. Event Driven Architecture would be better solution The sytem is modularized and meets the quality requirement Meets quality attribute 33 Modularity The system is divided into many 13 modules Client Server Event Driven NR 34 Usability User Interfces are highly interactive. User can process data in multiple window simultaneously Work flow is clearly identified Event Driven NR 35 Testabliliy Three Tier NR Meets the quality attribute. It is possible to generate test cases for each feature and test accordingly. Meets the quality attribute. It is possible to generate test cases for each feature and test accordingly. Meets the quality attribute. 36 Testabliliy System boundaries are well defined. Three Tier NR 37 Reusability Services, domain functions, and application functions are distributed in components Service Oriented Architecture NR 9. Sensitivity Points A sensitivity point is a property of one or more components (and/or component relationships) that is critical for achieving a particular quality attribute response. The sensitivity Points for KAA have been discussed bellow: • • • • • • • • Generate, print and manage customer letters are sensitive points if Xletter service fails. Providing Serch results in the required time are sensitive points if Search Oriented Architecture doesn’t work. Product Plant Import is a sensitive points if Multi Processed Pipeline doesn’t work Key Account access (Locking) is a sentive points if it is can’t be achived by Event Driven architecture. The offer volume increase in 10 times would be a sensitive point if it fails to proved desired result in the given time. The payment plan registration would be sensitive point if it fails to register in daisy system. Registering Ads could be sensitive point if SST service fails handle those. Customer correspondence integration with other tool can be a sensitve points if fails to integrate with the third party tool. 10. Trade-off Points A tradeoff point is a property that affects more than one attribute and is a sensitivity point for more than one attribute. • Key account locking (key account access control) is implemented by Client Server Architecture. Changing this architecute to Event Driven Architecutre will give the user significant visual effect. So, this is a Trade-off point. • The chance of converting present database to DB2 or something else from Oracle is very low. The visble impact to the customer will not be high though they will be technically more improved. As the Oracle expert is available, and this a database centric application, that’s changing the database has been skipped. This is a Trade Off point. Providing the web client to the user will not help much though this more desired. The applcation can be accessed from the web like web clint using Java Web Start, this can skipped. So, this is trade off point. Providing the Dot Net web client to the user will not very usefull for the user. This will increase complexity to maintain web services for inter oprability. But, this objective can be met using Java client/ Java Web client. So, this can be skipped and this a Trade Off point. • • 11. Conlusion The architecture of KAA is large and complex. These involved many stakeholders, each of whom has their own agenda. But they were not in the scene. Some of the parts of this architecture have incompletely thought out or only partially documented. The evaluation of this architecture using ATAM is aimed to obtain a precise statement of the quality attribute requirements; to understand the architectural decisions that have been made; and to determine if the architectural decisions made adequately address the quality attribute requirements.