Docstoc

Addressing architectural issues using “The Architecture Based Design Method”

Document Sample
Addressing architectural issues using “The Architecture Based Design Method” Powered By Docstoc
					Final Exam – Spring 2008
Addressing architectural issues using “The Architecture Based Design Method” & document the architecture following Architecture Layers, Interfaces and Behavior aspects of a completed Project
Software Architecture and Component Based Design SEN-565

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

May 25, 2008

1. INTRODUCTION............................................................................................................................. 3 1.1 QUESIONS ...................................................................................................................................... 3 1.2 PROJECT INFO ................................................................................................................................ 3 1.3 COMPANY INFO ............................................................................................................................. 3 2. ADDRESSING ARCHITECTURAL DESIGN ISSUES IN COMPLIANCE TO ABD............. 4 2.1 DIVIDE FUNCTIONALITY ............................................................................................................... 4 2.2 CHOOSE ARCHITECTURAL STYLE ................................................................................................. 5 2.3 ALLOCATE FUNCTIONALITY TO STYLE ......................................................................................... 6 2.4 REFINE TEMPLATES ....................................................................................................................... 7 2.5 VERIFY FUNCTIONALITY ............................................................................................................... 7 2.6 GENERATE CONCURRENCY VIEW ................................................................................................. 7 2.7 GENERATE DEPLOYMENT VIEW.................................................................................................... 7 2.8 VERIFY QUALITY SCENARIOS ....................................................................................................... 8 2.8.1 Use Case Scenarios................................................................................................................ 8 2.8.2 Growth Scenarios................................................................................................................... 9 2.8.3 Exploratory Scenarios.......................................................................................................... 10 2.9 VERIFY CONSTRAINTS................................................................................................................. 10 3. DOCUMENTING THE ARCHITECTURE ................................................................................ 10 3.1 ARCHITECTURAL LAYERS ........................................................................................................... 10 3.1.1 KAA Architecture Overview................................................................................................. 10 3.1.2 Client Tier Layers ................................................................................................................ 10 3.1.3 Server Tier ........................................................................................................................... 13 3.1.4 Database Tier....................................................................................................................... 13 3.1.5 File Server, Print Server, Email Server and Fax Server...................................................... 13 3.2 INTERFACES ................................................................................................................................. 14 3.2.1 Interfaces Identity ................................................................................................................ 14 3.2.2 Resources Provided ............................................................................................................. 16 3.2.3 Locally Defined Data Types................................................................................................. 17 3.2.4 Error Handling Capabilities................................................................................................ 18 3.3 BEHAVIOR ................................................................................................................................... 21 3.3.1 Static Behavioral Modeling ................................................................................................. 21 3.3.2 Trace-oriented Representations........................................................................................... 29

1. Introduction
1.1 Quesions
Take a completed project, very much known to you with access to different intermediate products including code. Answer following questions with respect to this project: 1. Address architectural design issues in compliance to following steps of ”The Architecture Based Design Method”: a. Divide Functionality b. Choose Architectural Style c. Allocate Functionality to Style d. Refine Templates e. Verify Functionality f. Generate Concurrency View g. Generate Dployment View h. Verify Quality Scenarios i. Verify Constraints 2. Document following aspects of the architecture: a. Architectural Layers b. Interfaces c. Behavior

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 is the offline sales application for the key account customers. This project at present is running in production environment and passing through the maintenance phase. 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 client of the project KAA is Enren Denmark A/S (www.Enren.dk).

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.

2. Addressing Architectural Design issues in Compliance to ABD
The ABD method is intended to organize the earliest design decisions. It does not involve commitments to actual software components and classes, nor to organization of the components into processes and operating system threads. The input to the ABD method consists of • abstract functional requirements, including the identification of variabilities and commonalities • use cases (concrete functional requirements) • abstract quality and business requirements • quality scenarios (concrete quality and business requirements) • architecture options • constraints The ABD method is based on decomposing the overall system. Every system consists of an application portion and an infrastructure portion. Although the boundaries between these portions are not always clear, a design must consider both the application and the infrastructure on which it executes. The ABD method captures these two fundamental portions by viewing the system as the combination of an application portion and the infrastructure. The different architectural design issues of KAA have been described relating the different steps of ABD bellow in more detail:

2.1 Divide Functionality
A design element has a set of responsibilities. These responsibilities are divided into groups. The goal of the division is to have each group represent distinct elements within the architecture. The divisions may need to be refined further, even to the extent of breaking up design elements. The criteria for this division depend on the qualities that are important to a particular design element. The following qualities have been considered influential for dividing the functionalities for KAA: • Performance • • • • • • • • Modifiability Scalability Availability Reliability Security Modularity Testability Reusability

For the performance quality, the division was based on minimizing the amount of data movement among the pieces and frequency of data calculations. For the modifiability quality, the groups of responsibilities were chosen based on several criteria - functional coherence - how requirements grouped together, similar patterns of data or computation behavior, similar levels of abstraction, locality of responsibility. The goal of the decomposition was to produce groups of functionality of sufficient granularity so as to represent the decomposition of the design element responsibilities while keeping the number of groups intellectually manageable. The information flow and the design elements with which the current design element interacted were determined by generating the diagram using tools.

The total functionality of the project have been dividend into the following modules or area in the tabular format. Table 1: KAA Functional Areas/Modules SL No. 1 2 Module/Area Functionality

3

4 5

7 8 9 10 11

12 13

Key Account List Shows the list of key accounts. Provides the option to create, delete and Module access key account. Provides facility to filter the list of key account. Key Account Info Provides the manipulation opportunity of key account. Add or remove departments to the key account. Shows and give access to the Key account offer, offline order lines, payment plans, letters etc. Key Account Offer Provides the facility to provide new key account offer, delete and remove offer. Adding the offer to the payment plan. Shows the list of offer lines, and access to the offer line. Provide option to copy offer lines from the daisy and payment plans. Create and access the customer letters. Offline Offer line Provides the facility to create and manipulate actual order. Copy the order to different books. Handle article (ad). Payment Plan Provides the facility to create payment plan, distribute payments over the different months, registering orders. Create and access customer letters. Replace Module Provides the facility to change or modify a number of order at the same time. Test Module Provide option to the customers whether they are eligible for becoming Key Account. Production Plan Provides the facility to import the production plan into the system and Import update the status of the books and the customers. Company Info Provides the option access the individual customers and to view their detail information including the orders. XLetter Module Provides the facility to create offer letter, order confirmation letter, payment plan letter and print proof. This also provides facility to print, email, fax letters to the customer. Search Module Provide the facility to efficient search on Key account, company over the millions of records. System Reports Provides the facility to generate different system reports for the customers.

2.2 Choose Architectural Style
Each design element has a dominant architectural style or pattern. It is the basis for how the design element achieves its responsibilities. The dominant style is not the only style within the design element; it may be modified to achieve particular goals. The choice of architectural style is based on the architectural drivers for this design element. Thus, the process is to determine the architectural drivers for this design element and from the architectural drivers and consideration of the functional decomposition, to determine the dominant architectural style. For KAA, there several documented styles were chosen as dominant styles. But, it was not always the case. Sometimes, the responsibilities of a design element consisted of relatively independent collections and no dominant style could be suitable. In that case, a style of independent filters with

connections from outside the design element was adopted. Following are the list of architectural styles that were adopted for KAA: • Multi -tier Architecture • Database-centric Architecture • Client-Server Architecture • Service Oriented Architecture • Search Oriented Architecture • Parallel Process Architecture • Event Driven Architecture The choice of an architectural style for a design element is a fundamental choice that relies heavily on the architects’ experience in design. For the KAA, the architect is highly experienced and that’s why this choice was highly influential.

2.3 Allocate Functionality to Style
The choice of architectural style produced a collection of component types. The number and function of each of these types were determined. The groups of functionality resulting from the decomposition of function were allocated to the types of components resulting from the determination of style. This involved determining how many instances of each type of component existed and what the functionality of each instance would be. The components resulting from this allocation would be the candidate child design elements for the design element being decomposed. The conceptual interface for each design element was also identified. The interface consists of both the information that the design element needed and produced (identified during the functional decomposition) and the data and control flow information needed by each component type within the defined architectural style. It is in the iteration of these three steps (divide functionality, choose style, and allocate functionality to style) that tradeoffs were made among the various quality attributes. The validation steps that followed the definition of the logical view provided concrete evidence of these compromises. Table 2: KAA Architectural Styles
SL. No 1 Architectural Style Allocated Functionality

Multi -tier Architecture

The over all functionality have been allocated to the three tiers. For the user logic and presentation layer has been placed in the client tier. The business logic and related services have been placed in the middle tier as server part. The physical data are stored in the data base 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, etc. SOAP is being used for accessing many of these services.

2

Database-centric Architecture

3 4.

Client Server Architecture Service Oriented Architecture

SL. No 5. 6.

Architectural Style

Allocated Functionality

Search Oriented Architecture Parallel Process Architecture

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.

7.

Event Driven Architecture

2.4 Refine Templates
The design element were decomposed had a collection of templates that pertain to it. These were inherited from its parents up the hierarchy. At the initiation of the method, the system had no template. Responsibilities were added to the templates as they were refined. These responsibilities were implemented by a concrete component at some point in the design process. Finally, the responsibilities of the templates were examined to determine whether any additional responsibilities needed to be added to any of the design elements anywhere in the system. The templates contained both what it meant for a design element to be a good citizen as well as those responsibilities that should have been shared rather than handled locally. Each type of responsibility ought to require additional support functionality. This support functionality, once were identified, were allocated.

2.5 Verify Functionality
The use cases were exercised to verify that they could be achieved through the proposed structure. Additional responsibilities for the child design elements were determined through the exercise of use cases. Change scenarios were also exercised at this point since the difficulty of performing a change were based on the division of functionality. From this type of verification, the design covered the requirements and supported the modifications through the change scenarios.

2.6 Generate Concurrency View
The concurrency view also was considered. The purpose of examining the concurrency view was to determine what activities might have been carried on in parallel. These activities were identified and pointed of spawning new threads, synchronization and resource contention discovered. The examination of the concurrency view was in terms of virtual threads. Virtual threads were used to describe a sequence of activities and so synchronization or resource contention would be between multiple virtual threads. Use cases which examined the effects of having two users, the effects of parallelism on the activities of one user, or the effects of start-up and shutdown, are useful in thinking about the concurrency view.

2.7 Generate Deployment View
In the deployment view, the effect of the network on the virtual threads was examined. A virtual thread may travel via the network from one processor to another. We used the term physical thread to describe the threads that existed on a particular processor. That was, a virtual thread was composed of the concatenation of physical threads. This view was to discover requirements for synchronizing physical threads on a single processor and for handing off a virtual thread from one processor to

another. Questions were asked during the generation of the deployment view about the impact of the network on data transmission, latencies, and on the synchronization of activities. We used the concept of unit of deployment within the deployment view. A unit of deployment was the smallest design element that can be allocated to a processor. Exactly what this meant depended on the granularity of the design elements. Decisions were made as to which level of design element constituted a unit of deployment. That was, what was the coarsest design element that would not be allocated or split among different processors? If the design elements were coarser than the smallest unit of deployment, then the design element might have split across two processors.

Figure 1: Deployment View of KAA

2.8 Verify Quality Scenarios
Once the three views were available, the quality scenarios were applied to the children design elements being generated. Each quality scenario included a quality attribute stimulus and a desired response. Considered the decisions made so far in the design and determined whether it was still possible to achieve the quality scenario. In the event of a negative answer, then either the decisions that were made were reconsidered, or the architect accepted the failure to realize one of the quality scenarios. The rationale for accepting a failure to realize one of the quality scenarios was recorded. The quality scenarios verified have been provided bellow: 2.8.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.

• • • • • • • • • •

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

2.9 Verify Constraints
The final step was to verify that none of the constraints were violated by the decisions made in this step. That was, for each constraint, asked the question “was the achievement of this constraint still possible?” A negative answer was treated in the same fashion as a negative achievement of a quality scenario. The rationale was documented and the decisions that led to the constraint being imposed were re-examined.

3. Documenting the Architecture
3.1 Architectural Layers
The layered view of architecture is one of the most commonly used views in software architecture. Layering, like all architectural structures, reflects a division of the software into units. In this case, the units are layers; each layer represents a virtual machine. A virtual machine is a collection of software that together provides a cohesive set of services that other software can utilize without knowing how those services are implemented. The goal of layering is to define virtual machines that are small enough to be well understood, but comprehensive enough so that likely changes will affect only a single layer. 3.1.1 KAA 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: The different layers within the tiers have been shown using with different rectangle. 3.1.2 Client Tier Layers The KAA client tier is comprised of several layers and services. The layers have been described

bellow. The client runs using Java Webstart Technology over Intranet or Internet. The client can run on many different platforms like MS Windows, Apple Mac OS, Linux, etc.

3.1.2.1 User Interface Layer
KAA User Interface layer is Java Swing client. This is the top most layer of this architecture. This layer directly interfaces with user.

3.1.2.2 PNUIFramework Layer
The User Interface layer is built on top of PNUIFramework. This layer provides basic building blocks for generating the user interface.

3.1.2.3 UIFramework Layer
The User Interface layer is built on top of UIFramework along with PNUIFramework. This layer provides core building blocks for generating the user interface. Both the PNUIFramework and UIFramework work in concert to provide best suited usability to the User Interface Layer.

3.1.2.4 Utility Service Layer
The utility layer provides the different utility services to the User Interface Layer. This service helps User Interface to perform different user level manipulation and processing.

3.1.2.5 Client Service Interface Layer
This layer is responsible establishing communication with application server. This layer works as request dispatcher for the client.

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 Layered Architecture

3.1.3 Server Tier The Server Tier is the Middle Tier. It is the application server for KAA. It is comprised of several major layers. These have been described bellow.

3.1.3.1 EIAS Service Layer
This layer EIAS (Enren Internal Application Server) is responsible to provide the interfaces for the business services for KAA. The client communicates with this layer to obtain the desired services. It has business service layer as well as web interface layer.

3.1.3.2 EIAS Entity Layer
This layer is responsible for providing and manipulating data for the business layer. This layer communicates with underneath Enren Server Framework layer and parallel ESA service layer. The EIAS Entity layer is comprised of Data Provider layer and Hibernate layer.

3.1.3.3 ESA Service Layer
This layer ESA (Enren Service API) is responsible to provide the interfaces for the business services for KAA and other applications. This implements service oriented architecture. The client communicates with this layer to obtain the desired services. It has business service layer as well as web interface layer.

3.1.3.4 ESA Entity Layer
This layer is responsible for providing and manipulating data for the business layer. This layer communicates with underneath Enren Server Framework layer and parallel EIAS service layer. The ESA Entity layer is comprised of EJB Persistence layer.

3.1.3.5 ESF Layer
The Enren Server Frameowork provides basic system services and services to the EIAS and ESA entity layers. This built on top of the Application server framework.

3.1.3.6 Application Server (JBoss) Layer
This layer is the J2EE application server itself. It is the container all the Enren server components. It provides all the communication, transaction, scalability etc issues. It makes application platform independent. This can run on different platform like MS Windows, Linux etc. This maintains the communication with other database server, file server, email, fax and print servers. At present the application server runs Linux Cent OS platform. 3.1.4 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.1.5 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.

3.2 Interfaces
An interface is a boundary across which two independent entities meet and interact or communicate with each other. The characteristics of an interface depend on the view type of its element. If the element is a component, the interface represents a specific point of its potential interaction with its environment. If the element is a module, the interface is a definition of services. There is a relation between these two kinds of interfaces, just as there is a relation between components and modules. An interface is documented with an interface specification: An interface specification is a statement of what an architect chooses to make known about an element in order for other entities to interact or communicate with it. Although an interface comprises every interaction an element has with its environment, what we choose to disclose about an interface— that is, what we document in an interface specification— is more limited. Writing down every aspect of every possible interaction is not practical and almost never desirable. Rather, the architect should expose only what users of an element need to know in order to interact with it. Put another way, the architect chooses what information is permissible and appropriate for people to assume about the element and unlikely to change.
The Major Entities and their Interfaces have been documented bellow in the tabular form.

3.2.1 Interfaces Identity The most common means of identifying the interfaces is to name the interfaces. All the interface can be identified with their name in association of their containing classes. The overloaded interfaces can be identified based on their syntax – the arguments. Table 3: KAA Interface List
SL No. 1 2 3 4 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 Component Name KAArticleBean KAArticleBean KAArticleBean KACommonBean KACommonBean KACommonBean KACommonBean KACommonBean KACommonBean KACommonBean KACommonBean KACommonBean KACommonBean KACommonBean KACommonBean KACompanyBean KACompanyBean KACompanyBean KACompanyBean KACompanyBean KACompanyBean Interface Name getKeyAccountArticleList() getKeyAccountArticleList() getCopyArticleList() getBookTypeList() getKeyAccountTypeList() getKeyAccountStatusList() getText() saveOrUpdateOr DeleteText() getDepartment() getDepartment() setDefaultTradeArea() getSalesPerson() hasKADelete Permission() getKeyAccountProject() getBookPublication Date() getCompanyDetails() getHeadOffice() getCompetiorURL() checkKACustomer() saveOrUpdaeKA Basic Data() updateHeadOffice()

SL No. 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69

Component Name KACompanyBean KACompanyBean KACompanyBean KACompanyBean KAOfferBean KAOfferBean KAOfferBean KAOfferBean KAOfferBean KAOfferBean KAOfflineBean KAOfflineBean KAOfflineBean KAOfflineBean KAOfflineBean KAOfflineBean KAOfflineBean KAOfflineBean KAOfflineBean KAOfflineBean KAOfflineBean KAOfflineBean KAOfflineBean KAOfflineBean KAOfflineBean KAPaymentPlan Bean KAPaymentPlan Bean KAPaymentPlan Bean KAPaymentPlan Bean ProductionPlan ImportBean ProductionPlan ImportBean ProductionPlan ImportBean ReplaceModule ReplaceModule KASearhBean KASearhBean KASearhBean KATestBean KATestBean KATestBean KATestBean KALetterFacade KALetterFacade KALetterFacade KALetterFacade KAReportBean KALockState HandlerFacade KALockState HandlerFacade KALockState HandlerFacade

Interface Name validateAddDepartment() addDepartment() removeDepartment() getOfflineDeadLine() saveOrUpdateKAOffer() addToPaymentPlan() deleteOffer() removeOffer() recalculateOffer() getOffer() getOrderline() saveOrUpdateOfferline() validateOfferline() getBook() getHeading() getProduct() getPlacement() getExtraproductList() saveOrUpdateExtra ProductLine() deleteExtraProductLine() saveOrUpdateMain Discount() saveOrUpdateExtra Discount() deleteDiscount() copyOfferLine() getSubDirectory() saveOrUpdatePaymentPlan() distributePaymentPlan() makeUpPaymentPlan() deletePaymentPlan() importBookDeadlines() updateCompanyBook Deadlines() updateKeyAccount BookDeadLine() replaceOrderLines() getFailedOrderLines() getKeyAccountList() getCompanyList() getUserList() getTestList() getCandiateList() saveOrUpdateTest() deleteTest() createLetter() getLetters() sendMail() printDocument() getReport() lockKeyAccount() lockKeyAccountBy Forec() removeLockState()

SL No. 70

Component Name KALockState HandlerFacade

Interface Name removeLockStates()

3.2.2 Resources Provided The heart of an interface document is the set of resources that the element provides to its actors. The resources have been defined by giving their syntax and their semantics.
Table 4: KAA Interface List with Resources Provided SL No. 1 2 3 4 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 Interface Name getKeyAccountArticleList getKeyAccountArticleList getCopyArticle List getBookTypeList getKeyAccount TypeList getKeyAccountStatusList getText saveOrUpdateOr DeleteText getDepartment getDepartment setDefaultTradeArea getSalesPerson hasKADelete Permission getKeyAccountProject getBookPublication Date getCompanyDetails getHeadOffice getCompetiorURL checkKACustomer saveOrUpdaeKABasicData updateHeadOffice validateAddDepartment addDepartment removeDepartment getOfflineDeadLine saveOrUpdateKAOffer addToPaymentPlan deleteOffer removeOffer recalculateOffer getOffer getOrderline saveOrUpdateOfferline validateOfferline getBook getHeading Resources Provided Resource Syntax Resource Semantics keyAccountID keyAccountID,productNo keyAccountID id, com salesPersonName, id, text, com, className companyDTO id departmentDTO, dwhIndividAkt salesPersonDTO userId offerDTO companyId keyAccuntId companyId companyId keyAccountDTO departmentDTO companyDTO companyDTOList companyDTOList keyAccountId keyAccountOfferDTO keyAccountOffer, paymentPlanNo offerId offerId offerlineList offerId offerlineId offerLineDTO offerLineDTO bookId headingId List List List List List List Text void of of of of of of ArticleDTO ArticleDTO ArticleDTO BookTypeDTO TypeDTO StatusDTO

KA Department DTO KA Department DTO void SalesPersonDTO Boolean SalesProjectDTO Calendar CompanyDTO CompanyDTO URL Boolean void void Boolean void void Calendar void void void void void KAOfferDTO OfferLineDTO void Boolean BookDTO HeadingDTO

SL No. 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64

Interface Name getProduct getPlacement getExtraproductList saveOrUpdateExtra ProductLine deleteExtraProductLine saveOrUpdateMain Discount saveOrUpdateExtra Discount deleteDiscount copyOfferLine getSubDirectory saveOrUpdatePaymentPlan distributePaymentPlan makeUpPaymentPlan deletePaymentPlan importBookDeadlines updateCompanyBook Deadlines updateKeyAccount BookDeadLine replaceOrderLines getFailedOrderLines getKeyAccountList getCompanyList getUserList getTestList getCandiateList saveOrUpdateTest deleteTest createLetter getLetters sendMail

Resources Provided Resource Syntax Resource Semantics productId placementId productId offerlineId, extralineList offerLineId offerLineId, offerLineList offerLineId, extraLineId, extraDiscountList offerlineId copyOfferLineList paymentPlanDTO, userName paymentPlanDTO paymentPlanDTO paymentPlanNo bookTypeList bookTypeList bookTypeList orderline list keyAccountId searhCriteria searhCriteria searhCriteria testDTO testId letterParam keyAccountId, letterType documentRegistration DTO, subject, mailContent, mailType, fromMail, toMail documentRegistrtion DTO, printerName reportParam salesPersonDTO, keyAccountDTO salesPersonDTO, keyAccountDTO salesPersonDTO, keyAccountDTO salesPersonDTO, keyAccountDTOList ProductDTO PlacementDTO List of ExtraProduct DTOs void void void void void void List of SubDirectoryDTO void void List PaymentDTO void void void void void List of OrderLineDTO List of KeyAccountDTO List of CompanyDTO List of SalesPersonDTO List of KATestDTO List of KACandidateDTO void void void List Document RegistrationDTO void

65 66 67 68 69 70

printDocument getReport lockKeyAccount lockKeyAccountBy Forec removeLockState removeLockStates

void ReprotObject KeyAccountLock State KeyAccountLock State void void

3.2.3 Locally Defined Data Types For the KAA, a list of types have been defined which have been used to communicate between different interfaces. The list of data types have been provide in the following table.
Table 5: Locally Defined Data Types SL No. Locally Define Data Type Name Description

SL No. 1 2 3 4 5 6 7 8 9 10

Locally Define Data Type Name DocumentType TextType CustomerType BookType SectionType ProductType DiscountType AdType AdStateType AdOnTextType

Description Defines the different types of document. Defines the types of available Text Defines the type of available Customers Defines the type of available Books Defines the type of Sections Defines the types of available products Defines the types of available discounts Defines the type of available types Defines the types of the states of ads Defines type of AdOnTexts

3.2.4 Error Handling Capabilities Following table describes errors that could be raised inside interfaces and throws from the interfaces.
Table 6: KAA Interface List with error handling capabilities SL No. 1 2 3 4 4 5 6 7 8 9 10 11 12 13 14 15 16 Interface Name getKeyAccount ArticleList getKeyAccountArticleList getCopyArticle List getBookTypeList getKeyAccount TypeList getKeyAccountStatusList getText saveOrUpdateOr DeleteText getDepartment getDepartment setDefaultTrade Area getSalesPerson hasKADelete Permission getKeyAccountProject getBookPublication Date getCompanyDetails getHeadOffice Exceptions handled HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException Exceptions Thrown ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException

SL No. 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37

Interface Name getCompetiorURL checkKACustomer saveOrUpdaeKA Basic Data updateHeadOffice validateAddDepartment addDepartment removeDepartment getOfflineDeadLine saveOrUpdateKAOffer addToPaymentPlan deleteOffer removeOffer recalculateOffer getOffer getOrderline saveOrUpdateOfferline validateOfferline getBook getHeading getProduct getPlacement

Exceptions handled HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException

Exceptions Thrown ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException

SL No. 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58

Interface Name getExtraproductList saveOrUpdateExtra ProductLine deleteExtraProductLine saveOrUpdateMain Discount saveOrUpdateExtra Discount deleteDiscount copyOfferLine getSubDirectory saveOrUpdatePaymentPlan distributePaymentPlan makeUpPaymentPlan deletePaymentPlan importBookDeadlines updateCompanyBook Deadlines updateKeyAccount BookDeadLine replaceOrderLines getFailedOrderLines getKeyAccountList getCompanyList getUserList getTestList

Exceptions handled HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException

Exceptions Thrown ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException

SL No. 59 60 61 62 63 64 65 66 67 68 69 70

Interface Name getCandiateList saveOrUpdateTest deleteTest createLetter getLetters sendMail printDocument getReport lockKeyAccount lockKeyAccountBy Forec removeLockState removeLockStates

Exceptions handled HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException HibernateException, SQLException KeyAccountLocked Exception KeyAccountLocked Exception KeyAccountLocked Exception KeyAccountLocked Exception

Exceptions Thrown ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException ServiceException -

3.3 Behavior
The behavior is documented to show how an element behave when stimulated in a particular way, or to show how an ensemble of elements (up to and including the whole system) react with each other. Documenting system behavior provides support for exploring the quality attributes of a system very early in the development process. Behavior of the system is considered as just in time response system. Any user can get service from the site at any time. There two types of behavior of the system. These are static view and traces. 3.3.1 Static Behavioral Modeling Static behavioral modeling shows the complete behavior of a structural element or set of elements. It is possible to infer all of the possible traces through a system given this type of documentation. The state-machine formalism is a good candidate for representing the behavior of architectural elements, because each state is an abstraction of all the possible histories that could lead to that state. Once in a state, it doesn’t matter how the system got there, only that it is there; it will react to the occurrence of a given event in the same way regardless of the system’s particular history at the time the event occurs. Notations are available that allow to describe the internal behavior of elements in terms of finite state machines and element-to element interactions in terms of inter-process communication of various types. These notations allow you to overlay a structural description of the system’s elements with constraints on the interactions and timed reactions to both internal and environmental stimuli. For conducting behavioral modeling Petrinet models (DES) have been used and described bellow:

3.3.1.1 Key Account List Module

Figure 3: Key Account List DSE Model

3.3.1.2 Key Account Info Module

Figure 4: Key Account Info DSE Model

3.3.1.3 Key Account Offer Module

Figure 5 : Key Account Offer DSE Model

3.3.1.4 Offline Offerline Module

Figure 6: Offline Offerline DSE Model

3.3.1.5 Payment Plan Module

Figure 7: Payment Plan DSE Model

3.3.1.6 XLetter Module

Figure 8: XLetter Module DSE Model

3.3.1.7 Company Module

Figure 9: Company Info DSE Model

3.3.1.8 Production Plan Import Module

Figure 10: Production Plan Import DSE Model

3.3.2 Trace-oriented Representations Trace-oriented representations consist of sequences of activities or interactions that describe the system’s response to a specific stimulus. They document the trace of activities through a system described in terms of its structural elements and their interactions. Although it is conceivable to describe all possible traces through a set of elements to generate the equivalent of a static behavior

description, it is not the intention of trace-oriented views to do so. This would reduce the benefit of being readily comprehensible due to the resultant loss of focus. Different techniques emphasize different aspects of behavior: • Message-oriented techniques focus on describing the message exchange between instances. • Component-oriented techniques focus on describing which behavioral features an element has to have in order to accommodate the system in performing its functions. • Activity-oriented techniques focus on describing which activities have to be performed in order to achieve the purpose of the system. • Flow-oriented techniques focus on describing the sequencing of responsibilities of elements for a specific scenario or trace.
There is some popular methods for trace-oriented representation like – Use Case Diagram, Use Case Map, Sequence Diagrams, Collaboration Diagrams etc. For showing trace-oriented representations of KAA Sequence Diagrams have been used. Some of the major sequence diagrams have been shown here:

3.3.2.1 Retrieve and Display Key Account

Figure 11: Retrieve and Display Key Account Info Sequence Diagram

3.3.2.2 Delete Key Account

KeyAccountSearchListUI

ClientFaceFacotory

FacadeFactory

KeyAccountFacade

KeyAccountBean

deleteKeyAccount

checkDeletePermission hasDeletePermission getKeyAccountFacade return KeyAccountFacade hasDeletePermission hasDeletePermission return value

return value return value

If the user has permission then

deleteKeyAccount getKeyAccountFacade return KeyAccountFacade deleteKeyAccount return value return value deleteKeyAccuount return value

showStatus

If the user has permission then

showMessage

Figure 12: Delete Key Account Info Sequence Diagram

3.3.2.3 Create Offline Offerline

Figure 13: Delete Key Account Info Sequence Diagram

3.3.2.4 Import Production Plan

SKAAMDI

ImportProductionPlanUI

ClientFacadeFactory

FacadeFactory

ImportProductionPlanFacade

ImportProductionPlanBean

importProductionPlan

selectFile

createProducttioplanDataList importProductionPlan importProductionPlan getProductionPlanFacade return ProductionPlanFacade importProductionPlan importProductionPlan

initSession

updateBookDeadLine

updateDepartmentDeadLine

updateKADeadLine return Status return Status return Status return Status

showMessage


				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:51
posted:7/2/2009
language:English
pages:34
Description: Address architectural design issues in compliance to the steps of the Architecture Based Design Method (ABD). Document the following aspects of the architecture a. Architectural Layers b.Interfaces c. Behavior.