Docstoc

Post Project Software Architecture Evaluation

Document Sample
Post Project Software Architecture Evaluation Powered By Docstoc
					Mid Term Paper

Post Project Software Architecture Evaluation
Software Architecture and Component Based Design SEN-565

S.M. Saiful Islam ID # 0712004 Program – M.Sc. in SE

March 22, 2008

1. INTRODUCTION............................................................................................................................. 3 1.1 EXAM OVERVIEW .......................................................................................................................... 3 1.2 PROJECT INFO ................................................................................................................................ 3 1.3 COMPANY INFO ............................................................................................................................. 3 1.4 CLIENT INFO .................................................................................................................................. 3 2. MATERIALS AND METHODS ..................................................................................................... 4 3. PROJECT DESCRIPTION ............................................................................................................. 4 3.1 BUSINESS OVERVIEW .................................................................................................................... 4 3.2 SYSTEM OVERVIEW – WORK PROCESS ......................................................................................... 4 3.3 SOFTWARE REQUIREMENTS .......................................................................................................... 5 3.4 ARCHITECTURE OVERVIEW........................................................................................................... 7 3.4.1 Client Tier .............................................................................................................................. 8 3.4.2 Server Tier ............................................................................................................................. 9 3.4.3 Database Tier......................................................................................................................... 9 3.4.4 File Server, Print Server, Email Server and Fax Server........................................................ 9 4. MAPPING OF ARCHITECTURAL FEATURES, GAPS AND IMPLICATIONS................... 9 5. IMPACT OF DETECTED GAPS ON PRODUCTIVITY, EMPLOYEE TURN OVER AND COMMUNICATION WITH DESIGNERS, CODERS, AND TESTERS ..................................... 12 6. CONCLUSION ............................................................................................................................... 12

1. Introduction
1.1 Exam Overview
The main objective of this exam is to evaluate the Software Architecture of a completed project. Following are the questions/quidelines to complete this assignment. Questions have been copied bellow from the supplied question paper as it is: ”Take a complete project, very much known to you with access to different itermediate products including code. Answer following questions with respect to this project: 1. Write an overview on the requirements and other engineering aspects of this project. 2. Establish a mapping between architectural features used in the project to different architectural concepts studied in the class. 3. Perform a gap analysis of taken architectural decisionn with respect to your suggestions. 4. What are the implications on detected gaps on modularity, reusability, testability, customizability, and scalability of the application? 5. How does the detected gap affect productivity, employee turn over impact, and ease of communication with designers, coders, and testers?” To reach a common template to document the answer a discussion was held in the class room. The subsequent section will follow that template.

1.2 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). This project at present is running in production environment and passing through the maintenance phase. The detail overview of this project has been given in the later section.

1.3 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. There are several projects in the development phase and some are in the pipeline.

1.4 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. Most of the requirements were specified by the Enren Business Development Consultant and documented by IT Consultant from Groupcare. The major architectural decisions 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. For this project a number of documents have been produced – which includes Software Requirement Specification, High Level Architecture Document, Several Service Design document, Database related document, Legacy Systems Compatibility documents, Usability Documents, etc. For source control, development and testing, we use Enren source server (CVS), database server (Daisy, Samas & Timba), file server (Fics) and Issue Tracker (JIRA) directly using VPN. That’s why I have the full access to the related resources of the Project. For preparing this document, I consulted all the related documents.

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. If any customer meets one of the following criteria can be treated as Key Account: • Yearly sales above DKK 150,000 (US$ 30,000) and/or • A chain with more than 10 departments (also referred to as companies or branches) • One of the 100 largest business-to-consumer enterprises in Denmark • High order complexity (ordering more than 10 books per year) 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.

3.3 Software Requirements
Major Modules/Areas along with their hierachical breakdown (1 level) has been enlisted bellow: 1. Key Account List a. New Key Account b. Remove Key Account c. Access Key Account 2. Key Account a. Key Account Information b. Departments

i. Comompany Search And Associate with Key Account c. Key Account offers i. New Key Account Offer ii. Access Key Account Offer d. Payment Plans i. Access Payment Plan e. Print Orders i. Access Daisy Order Information f. Ads i. Access Ad 3. Key Account Offer a. Key Account Offer Informaton i. New Payment Plan ii. Add to Payment Plan b. Print Orders i. New Offerline ii. Copy Offerline iii. Replace Offerline iv. Recalcualtion 4. Department Offer 5. Offline Offline a. Offerline Information i. Additional Product ii. Copy iii. New Ad b. Alternative Adress c. ATX/RTX Text d. Ads 6. Payment Plan a. Payment Plan Informatin i. Make up b. Print Orders i. Replace ii. Recalculation 7. Company a. Company Information

b. Info Site c. Information d. Relations e. Order Information f. Competior g. Activities 8. Key Account Search 9. Company Search 10. Test Module 11. Replace Module 12. Production Plan Import 13. Xletter a. Key Account Offer b. Key Account Order Confirmation c. Department Offer d. Department Order Confirmation e. Print Proof f. Letters g. Archives h. Payment Plan Overview i. j. Print Letters Email Letters

k. Fax Letters 14. System Reports a. Key Account Overview b. Key Account Test Report c. Department Test Report d. Print System Reports 15. Key Account Locking 16. Multiple Window

3.4 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 Daisy

Database Server

File Server

Samas

Timba

Fics

Figure 2 – SKAA System Architecture 3.4.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. 3.4.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. 3.4.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. 3.4.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. Mapping of Architectural Features, Gaps and Implications
In the following table a mapping has been establish with the architectural features used in KAA, then a gap analysis has been done based on the suggested solution, then implications have been determined on detected gaps in terms of modularity, reusability, testability, customizability, and scalability. The gaps and implications will be denoted as one of following: • • • • Low (L) Medium (M) High (H) None (N)

The Source of Information would be referred as Ref. Work Product. The work product would be denoted as one of the following:

• • • • • • • • •

Software Specification (SRS) Software Architecture Document (SAD) High Level Design Document (HLD) Detail Design Document (DD) Code (CD) Database Objects Descriptions (DO) Test Case (TC) Deployment Design Document (DP) Other (OTH)

SL No

Architectural Feature

Ref. Work
Prod.

Customizability N

Related Arch. Concept

Suggested
Architectu re

Rationale for Suggestion

G a p s Modularity

Implications

Reusability

Testability

1

The overall structures comprised of 3 distinct Tiers. More tier can be extended like web tier.

SAD DP

Multi -tier Architectu re

Same as it is now.

The one instance of the business logic will be used by many users. So, it is required to isolate User Interface from main business logic and business logic should be implemented in one place. The business logic should be isolated as well as from the database layer. So, this is the right choice as the main architectural pattern. Huge implementation of business logic in database is not good if considered from different engineering aspects. So, it is suggested to implement true MultiTier Architecture shifting business logic from database layer to the application server. This might reduce the performance but will increase modularity, reusability and scalability. The increase the database performance other

N

N

N

N

N

2

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.

SRS DO TC OTH

Databasecentric Architectu re

True Multi -tier Architectu re

M M M M H

H

Scalability

SL No

Architectural Feature

Ref. Work
Prod.

Customizability L

Related Arch. Concept

Suggested
Architectu re

Rationale for Suggestion

G a p s Modularity

Implications

Reusability

Testability

architectural pattern can be introduced along with this. 3 Controlling access to the same key account is controlled by the application server tracking the client request. SRS DD CD ClientServer Architectu re Event Driven Architectu re One key account can’t be accessed by multiple users at the same time. So, the users should be notified when a user has been accessed or released and accordingly access can be controlled. To implement this Event Driven Architecture will best suit rather than simple client server architecture. SOA would be best suited here, that would be highly modular, reusable and scalable. M M M H M H

4.

Many services are being used by KAA viz. XLetter Services, XPP Services for creating and distributing different Offer letter, Order confirmation letter, Print Proof, etc. SOAP is being used for accessing many of these services. There is many search operation is done in KAA. The search is conducted on sometimes billions of records. The KAA

DD CD TC

SOA Service Oriented Architectu re

Same as it is now i.e. SOA with true implement ation

L

M M L

M

5.

SRS DO TC

Client Server Architectu re

Search Oriented Architectu re

To improve the search performance it is required to introduce Search Oriented Architecture. For that purpose a Search Engine layer can be placed on top of database layer. Implementation of Multi

M M M M H

M

6.

SRS

Multi

Multi

M M M H

M L

Scalability

SL No

Architectural Feature

Ref. Work
Prod.

Customizability

Related Arch. Concept

Suggested
Architectu re

Rationale for Suggestion

G a p s Modularity

Implications

Reusability

Testability

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.

DD CD

Process / Parallel Process

Processed Pipelines

processed pipelines architectural pattern will be more manageable and technically efficient.

5. Impact of detected gaps on productivity, employee turn over and communication with designers, coders, and testers
The KAA is built on strong and well thought architecture. The architecture is optimized for performance, modularity, scalability and reusability. The architectural features are well evident and well communicated. Therefore, overall detected gaps are not high, can rated as Medium Low. The detected gaps are not that much significant in terms of productivity, employee turn over and communication with designers, coders and testers. As KAA can’t work isolately and has much dependecy on legacy systems, there is still some scope of improvement. For making those improvement from the current state will have significant impact on Employee turnover as the major challange is to upgrade and comply with legacy system. As there is lot of design and requirment documentations that will help a lot to communicate with designers, coders and testers.

6. Conclusion
As a part of the post project sotware architecture evaluation, the project KAA has been evaluated thoroughly. Out of the study, it has been evident that, though the KAA has been built on strong architectural base, but still there is some lacks. If those lacks can be eliminited, then the architecture will be more robust, which in turn will incrase performance, modularity, .reusability and scalability. That will also reduce employee turn over impact and increase productivity.

Scalability


				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:80
posted:7/2/2009
language:English
pages:12
Description: The main objective of this document is to evaluate the Software Architecture of a completed project.