3. Cấu trỳc và nội dung của luận văn
4.3.1 Phỏt triển cỏc scenario
4.3.1.1 Scenario về hiệu năng (P)
Số lƣợng ngƣời truy cập đồng thời vào hệ thống để đặt hàng lớn.
Lượng dữ liệu cú thể lờn tới hàng chục GB.
Thời gian populate cỏc mục dữ liệu trờn màn hỡnh bị giới hạn < 15s. Cỏc thao tỏc của khỏch hàng đƣợc cập nhật ngay vào Database.
Người dựng thao tỏc rất nhanh (bấm liờn tục vào nỳt hiển thị ds đơn hàng) Người dựng chọn số lượng đơn hàng rất lớn để hiển thị đồng thời.
Dữ liệu khỏch hàng được backup hàng ngày.
4.3.1.2 scenario về bảo mật (S)
Hệ thống cú nhiều đối tƣợng sử dụng với những quyền khỏc nhau.
Mỗi trang web khi hiển thị cho ngƣời dựng đều phải đƣợc chứng thực. Việc chứng thực chỉ thực hiện một lần theo mụ hỡnh SSO (Single Sign On) Một user Account đăng nhập đồng thời từ nhiều mỏy.
4.1.3 Scenario về tớnh khả chuyển (P1)
Hệ thống chạy trờn cỏc trỡnh duyệt phổ biến mà khụng bị phỏ vỡ layout cũng nhƣ cỏc hỗ trợ xử lý Script.
Chuyển sang hệ quản trị CSDL SQL Server 2005
Chuyển sang sử dụng cụng nghệ Ajax và Atlas ở tầng trỡnh diễn.
4.1.4 Scenario về tớnh bảo trỡ (M)
Hiển thị cỏc đơn hàng và quản lý đơn hàng thay đổi ở pha sau. Thờm module thanh toỏn trực tuyến
Thờm tầng nghiệp vụ mới.
Thay đổi giao diện của tất cả cỏc trang.
4.1.5 Scenario về tớnh sẵn sàng
DB Server gặp trục trặc. Webservice lỗi.
4.1.6 Scenario về tớnh tin cậy
Đang xử lý đơn hàng thỡ mất điện/ ngắt kết nối.
Dữ liệu đang được cập nhật thỡ DB Server gặp trục trặc. Khỏch hàng ra khỏi hệ thống nhưng quờn khụng Logout.
Đơn hàng đặt trong file Excel khụng đỳng theo định dạng chuẩn khi Upload. Mỗi khi đơn hàng được thực hiện thỡ một email sẽ gửi thụng bỏo cho khỏch hàng.
4.2 Gỏn mức ƣu tiờn cho cỏc scenario
Cỏc scenario ở trờn được đem ra thảo luận và được gỏn độ ưu tiờn theo tầm quan trọng của chỳng đối với sự thành cụng của hệ thống.
Sau thảo luận thỡ thuộc tớnh chất lượng Hiệu năng, Bảo mật, Bảo trỡ, Khả chuyển là quan trọng nhất. Trong đú, cỏc scenario cú mức ưu tiờu cao được gạch chõn tương ứng.
4.3 Xỏc định cỏc tiếp cận kiến trỳc
Mục tiờu ở đõy là phải tỡm ra cỏc phương ỏn kiến trỳc để làm sao giải quyết được cỏc yờu cầu đặt ra (cỏc yờu cầu này cũng thể hiện thụng qua cỏc scenario đó trỡnh bày ở trờn). Dưới đõy là danh sỏch cỏc quyết định kiến trỳc đề xuất và được chọn lựa để giải quyết cỏc scenario:
Dựng cơ chế Cache ở mức trang để cải thiện hiệu năng (P)
Chuyển một phần tớnh toỏn ở ngay bờn phớa mỏy khỏch thay vỡ phải quay
về tớnh toỏn tại mỏy chủ. Làm giảm tải cho mỏy chủ khi số lượng request lớn. (P)
Dựng cơ chế bảo mật của Windows kết hợp với cơ chế bảo mật của DBMS
và cơ chế Account mềm (S).
Sử dụng cơ chế trang chủ Master Page của ASP.NET (S)
Chia hệ thống thành cỏc tầng : Presentation Webservice Business
Rule Data Access Data Base. (M)
Sử dụng kiến trỳc hướng dịch vụ (SOA) (M)(S)
Sử dụng Ajax và Master Page sẽ đảm bảo dễ dàng thay đổi giao diện (M)
Tăng số lượng Server dự phũng (R) (S-) (A).
Thực tế với cỏc ứng dụng chạy trờn nền web thỡ đó cú những phong cỏch phỏt triển sẵn cú, đú là phong cỏch kiến trỳc Phõn tầng (Layered). Vỡ vậy, ta cú thể ỏp dụng phong cỏch (mẫu) này với đầy đủ những ưu điểm sẵn cú.
4.5 Đỏnh giỏ kết quả
Nhỡn chung, thật khú cú thể ỏp dụng được toàn bộ qui trỡnh đó đề xuất vào cỏc dự ỏn thực tế bởi rất nhiều nguyờn nhõn. Vỡ vậy, việc ỏp dụng được một phần quan trọng của phương phỏp trong dự ỏn thực tế cũng là điều rất tốt. Với dự ỏn Vanco- NetDirect tại FSoft thỡ việc ỏp dụng chủ yếu là tỡm ra cỏc scenario và lựa chọn được cỏc tiếp cận kiến trỳc phự hợp (Vỡ điều này cú thể thực hiện lồng ghộp trong những buổi tỡm hiểu yờu cầu và phõn tớch tỡm kiếm giải phỏp trong nhúm dự ỏn). Kết quả cụ thể mà nhúm tỏc giả tham gia đề xuất chớnh là những tiếp cận kiến trỳc được trỡnh bày trong phần IV.4.3 ở trờn. Chớnh cỏc kết quả này cũng đó ghúp phần quan trọng vào cải tiến đỏng kể chất lượng của hệ thống cũng như rỳt ngắn được thời gian hoàn thành cho khỏch hàng do cú kiến trỳc phự hợp.
KẾT LUẬN
Đỏnh giỏ kiến trỳc phần mềm luụn là một khõu vụ cựng quan trọng vỡ nú ảnh hưởng đến toàn bộ cỏc cụng đoạn phỏt triển cũn lại. Chất lượng của phần mềm thường do chớnh kiến trỳc của hệ thống phần mềm đú qui định chứ khụng phải do thuật toỏn mà nhiều người vẫn tưởng.
Đối với cỏc dự ỏn lớn thỡ việc phõn tớch và tỡm ra cỏc giải phỏp kiến trỳc phự hợp là điều bắt buộc. Tuy nhiờn, đặc thự của phõn tớch kiến trỳc đú là được thực hiện sớm, trước cả giai đoạn thiết kế vỡ, vậy rất khú để cú thể định lượng được. Hơn nữa, vỡ ở giai đoạn đầu nờn thụng tin thường là khụng cú cấu trỳc do vậy nếu khụng cú một phương phỏp phõn tớch cú cấu trỳc nào đú thỡ cụng sức bỏ ra sẽ rất lớn.
Nhỡn nhận thấy tầm quan trọng đặc biệt của kiến trỳc đối với chất lượng của hệ thống phần mềm cũng như mong muốn tỡm ra một phương phỏp cú cấu trỳc trong phõn tớch, rất nhiều cỏc phương phỏp phõn tớch kiến trỳc đó ra đời, trong đú kiến trỳc dựa trờn scenario trờn thực tế đó chứng tỏ rất hiệu quả. Và chớnh những phương phỏp này cũng đó ỏp dụng thành cụng cho nhiều dự ỏn trờn thực tế, vớ dụ dự ỏn ―NASA ECS‖ của Mỹ, dự ỏn BCS, Avionics Systems, ….
Trong số cỏc phương phỏp phõn tớch kiến trỳc phần mềm dựa trờn scenario, cú thể kể ra một số phương phỏp như: SAAM, FAAM, ALMA, ATAM, CBAM. Đặc biệt ATAM và CBAM đang được quan tõm đặc biệt bởi nú cú khả năng phõn tớch nhiều thuộc tớnh phần mềm hơn so với cỏc phương phỏp khỏc, riờng CBAM thỡ cú điểm mạnh vượt trội là cú thể phõn tớch được cả về khớa cạnh kinh tế và lợi ớch. Nhận thức được tầm quan trọng của kiến trỳc phần mềm trong phỏt triển hệ thống, hơn nữa lĩnh vực nghiờn cứu này cũng đang cũn khỏ mới mẻ tại Việt Nam, do vậy mà em đó chọn đề tài tỡm hiểu phương phỏp phõn tớch kiến trỳc phần mềm ATAM và CBAM làm luận văn tốt nghiệp của mỡnh, dưới sự dẫn dắt và định hướng của thầy giỏo PGS.TS Huỳnh Quyết Thắng. Mục tiờu sau khi nghiờn cứu về cỏc phương phỏp này, em đó cố gắng ỏp dụng nú vào dự ỏn thực tế mà em tham gia tại cụng ty cổ phần phần mềm FPT Software.
Bước đầu ỏp dụng cũng đó thu lượm được một số kết quả đỏng kể, ghúp phần nõng cao chất lượng của dự ỏn phần mềm Vanco-NetDirect. Tuy nhiờn, vỡ nhiều lý do và điều kiện khỏch quan khỏc nhau và trỡnh độ cú hạn của bản thõn mà toàn bộ qui trỡnh của phõn tớch của phương phỏp khụng được thử nghiệm và ỏp dụng triệt để, do vậy cũn nhiều hạn chế cần phải khắc phục.
Mặc dự kết quả nghiờn cứu chưa thực sự được như ý muốn, nhưng cú thể kết luận rằng việc đi sõu nghiờn cứu và tỡm hiểu về đỏnh giỏ kiến trỳc phần mềm sẽ đem lại những kết quả to lớn, đem lại lợi ớch tối đa đồng thời làm giảm thiểu đỏng kể những rủi ro cú thể dự đoỏn được cho doanh nghiệp.
Lời cuối cựng, em xin được gửi lời cảm ơn chõn thành tới cỏc Thầy cụ và bố bạn đó đọc bản luận văn này và mong Thầy cụ cho những ý kiến đúng gúp để em hoàn thiện luận văn được tốt hơn !.
PHỤ LỤC 1
Vanco-NetDirect Software Requirement Specification
1. Functional requirements Overview
Expert should be regarded as an entirely separate view of the same NetDirect data. In terms of flow, the decision to show the end user Classic, Expert or the Current system is made at the point of log-in at the portal. So when the user selects Pricing System from the portal, they will only see one of the above system interfaces.
The flow of the Current and Classic systems is not applicable to Expert. Within Expert, we will change the process flow to better reflect how Expert will be used. With Classic/Current systems, there are a number of regimented steps, each of which must be completed before moving on to the next. With Expert, the network design is worked on using may pieces of information simultaneously, giving more flexibility to the user. The technical user will also want to progress some areas of the design almost to completion before other sites are entered or considered. With this in mind, we need 3 basic steps: Quote List, Network Designer, Ordering. The main part of the functional complexity will be contained within the Network Designer step. This approach offers most power and flexibility to the Expert user.
Expert will permit the technical user to work on 5 designs simultaneously per quote, compare prices between all designs, select the preferred design and then proceed to order. The use of ―flow‖ and ―number of sites‖ in the Current system will no longer be applicable in Expert. The ―flow‖ and ―number of sites‖ was used to estimate a contention for use in the VSIP. In Expert, the user will now be given the location of each VSIP and the actual list of carriers in each VSIP. Users will then be able to select their own speed, taking the sizing risk away from Vanco.
The ability to add, change or remove circuits from a quote during network design will be introduced in Expert. The circuit details will only be fixed in a quote at the point of order.
2. Core modules
Quote List screen
Network Designer overview
MPLS Matrix tab (Network Designer) DIA tab (Network Designer)
VSIPs tab (Network Designer) Attributes screen
Compare Designs screen Prices
Quote export Maintain users Maintain clients
3. Non-Functional core requirements
3.1 Performance
Page refresh times within the application are to meet the following timing: Maximum 10 seconds for screen elements to be updated / populated.
Moving between pages/screens should have maximum timing of 15 seconds. For some long-running calculation, e.g. look up possible carriers and / or design it
is allowed to do the calculation in background and send email alerting users when it is done.
As the hosting environment is provided by Vanco and the software has been written by Harvey Nash performance targets can only relate to the relative efficiency of the code. Issues that reside in the underlying database and other servers will be raised by Harvey Nash to Vanco to make joint decision about hardware vertical and horizontal upgrading.
3.2 Scalability
Simon: The following figures were taken from the Classic spec, so we need to obtain the equivalent Expert expectations and requirements.
It is expected that there will be an average of 2000 users by the end of 2007. The system should be able to scale to support additional users.
Up to 50 Users per Client
The number of concurrent customers accessing the application is assumed to be 20 in one hour
Average session duration expected to be 2-3 hours
The number of hits per day is assumed to be up to 1000.
To avoid issues caused by large datasets being retrieved to the client browser, all paged data (including quotes and circuits) should be retrieved from the server one page at a time, i.e. 25, 50 or 100 records only (depending on user paging options) should be downloaded to the client browser at any given time.
3.3 Reliability
All the components of the application must be monitored permanently. It is done manually at the moment and automatically (alert by email/SMS when fatal errors happen in one of the components) in future.
3.4 Availability
The application should be available 23 hours a day, 7 days a week. It must be stated that the responsibility of this belongs to both Harvey Nash (software side) and Vanco (hardware and hosting sides)
3.5 Bug and defect rates
Regarding bug and defect rates no specific requirements have been stated. The defect rate objectives can be derived from standards and norms of Harvey Nash quality management system.
3.6 Supportability
Vanco is responsible for 1st line support which involves answering the phone, initial call diagnosis and issue routing. All support calls will be logged and routed by the Vanco help desk in Cerberus.
PHỤ LỤC 2
DANH MỤC CÁC TỪ VIẾT TẮT
STT Từ viết tắt í nghĩa
1 ALMA Architecture Level Modifiability Analysis
2 SAAM Software Architecture Analysis Method
3 ATAM Architecture Tradeoff Analysis Method
4 CBAM Cost-Benefit Analysis Method
5 ASs Architectural Strategies
6 FAAM Family Architectural Analysis Method
7 QA Quality Attribute
TÀI LIỆU THAM KHẢO
[1] Atwood, J. The Systems Analyst, Hayden, 1977.
[2] Clements, P., Bass, L., Kazman, R., Abowd, G., ―Predicting Software
Quality by Architecture- Level Evaluation‖, 5th International
Conference on Software Quality, (Austin, TX), October 1995, to appear.
[3] Dardenne, A., ―On the Use of Scenarios in Requirements Acquisition‖,
CIS-TR-93-17, Depart- ment of Computer and Information Science, University of Oregon, 1993.
[4] Dean, T., Cordy, ―A Syntactic Theory of Software Architecture‖,
Transactions on Software Engi- neering, 21(4), April 1995, 302-313.
[5] Dijkstra, E. W. ―The structure of the ‗T.H.E.‘ multiprogramming system,‖
Communications of the ACM, 18(8), 1968, 453-457.
[6] Garlan, D., Shaw, M. ―An Introduction to Software Architecture‖.
Advances in Software Engineer- ing and Knowledge Engineering,
Volume I, World Scientific Publishing, 1993.
[7] Gough, P., Fodemski, F., Higgins, S., Ray, S., ―Scenarios - an Industrial
Case Study and Hyper- media Enhancements‖, Proceedings of
the Second IEEE International Symposium on Requirements
Engineering, York, England, March, 1995, 10-17.
[8] Henry, S., Kafura, D. ―Software Structure Metrics Based on Information
Flow‖, IEEE Transac- tions on Software Engineering, SE-7(5), Sept.
1981.
[9] Heyliger, G., ―Coupling‖, Encyclopedia of Software Engineering, J.
Marciniak (ed.), 220-228.
[10] Jacobson, I., Christerson, M., Jonsson, P. and Overgaard, G. Object-
Oriented Software Engineer- ing: A Use Case Driven Approach.
Addison-Wesley, 1992.
[11] Kazman, R., Bass, L., Abowd, G., Webb, M., ―SAAM: A Method for
Analyzing the Properties of Software Architectures‖, Proceedings of ICSE
16, Sorrento, Italy, May 1994, 81-90.
[12] Kazman, R., Bass, L., ―Toward Deriving Software Architectures from Quality Attributes‖, CMU/ SEI-94-TR-10, Software Engineering Institute, Carnegie Mellon University, 1994.
[13] Kazman, R., Bass, L., Abowd, G., and Clements, P., ―An Architectural
Analysis Case Study: Inter- net Information Systems,‖ Proceedings,
First International Workshop on Software-Intensive Systems, Seattle, April 1995. (Also available as CMU-CS-TR-95-151, School of Computer Sci- ence, Carnegie Mellon University, Pittsburgh).
[14] Mettala, E., Graham, M. (eds.), ―The Domain-Specific Software Architecture Program‖, CMU/ SEI-92-SR-9, Software Engineering Institute, Carnegie Mellon University, 1992.
[15] Parnas, D, ―On the design and development of program families,‖ IEEE
Transactions on Software Engineering, SE-2(1), 1976, 1-9.
[16] Parnas, D., ―On the criteria for decomposing systems into modules,‖
Communications of the ACM, 15(12), December 1972, 1053-1058.
[17] Shaw, M., ―Larger Scale Systems Require Higher-Level
Abstractions‖,Proceedings of Fifth Inter- national Workshop on
SoftwareSpecificationand Design, IEEE Computer Society, 1989, 143
[18] Tichy, W. ―RCS—A System for Version Control‖, Software—Practice &
Experience, 15(7), July 1985, 637-654.
[19] Trowbridge, D., Roxburgh, U., Hohpe, G., Manolescu, D., and Nadhan, E. ―Integration Patterns: Patterns & Practices‖, Microsoft Press, 2004, ISBN: 073561850X.
[20] Young, R.M.; Riedl, M.O., Branly, M., Jhala, A., Martin, R.J., and Saretto, C.J. ―An architecture for integrating plan-based behavior
generation with interactive game environments‖. J ourna l of Ga me
Development , 1(1), 2004, pp. 51-70.
[21] Weiss, D., Parnas, D., ―Active Design Reviews: Principles and
Practices,‖ Proceedings, Eighth International Conference on Software