CS 590l                                                   Workshop I

               CS 590l – EQuotes Evaluation Repor...
CS 590l                                                                                                             Worksh...
CS 590l                                                                               Workshop I

CS 590l                                                                              Workshop I

The rest of the report is...
CS 590l                                                                              Workshop I

works will be to follow a...
CS 590l                                                                               Workshop I

        2. Quality at...
CS 590l                                                                              Workshop I

        4. Analysis

CS 590l                                                                           Workshop I

                     5. Mana...
CS 590l                                                                              Workshop I

CS 590l                                                                               Workshop I

As per [1], the 4+1 mo...
CS 590l                                                                             Workshop I

CS 590l                                                                              Workshop I

              EQuote S...
CS 590l                                                                               Workshop I

Refine requirements like...
CS 590l                                                                                Workshop I

The architectural style...
CS 590l                                                                                 Workshop I

Analysis & Suggested...
CS 590l                                                                                Workshop I

            The Develop...
CS 590l                                                                            Workshop I

CS 590l                                                                              Workshop I

CS 590l                                                                             Workshop I

   5.    The Client Handle...
CS 590l                                                                               Workshop I

CS 590l                                                                        Workshop I

[2]     K. Rick, A. Gregory, B....
CS 590l                                                                             Workshop I

            C.EQUOTES E...
CS 590l                                                                               Workshop I

dynamic integration of w...
CS 590l                                                                              Workshop I

    patterns. Alternative...
CS 590l                                                                            Workshop I


A registration da...
CS 590l                                                                               Workshop I

can be used. JSP is a se...
CS 590l                                                                              Workshop I

   The E-quotes software ...
CS 590l                                                                              Workshop I

    Other attributes such...
CS 590l                                                                               Workshop I

Upcoming SlideShare
Loading in …5



Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. CS 590l Workshop I CS 590l – EQuotes Evaluation Report Submitted By: Senthilkumar Ayyasamy Tulika Rathi Seema Joshi Diksha Agarwal Manali Joshi(Leader) Workshop Webpage: http://m.students.umkc.edu/maj2m9 -1-
  2. 2. CS 590l Workshop I Table of Contents: A. EQUOTES EVALUATION REPORT (REQUIREMENTS EVALUATION)..........................................3 B. EQUOTES EVALUATION REPORT (DESIGN EVALUATION) ..........................................................9 A. web service................................................................................................................................................15 B. Security Component...................................................................................................................................15 C. Login..........................................................................................................................................................15 D. User Interface.............................................................................................................................................15 E. Stock Trading.............................................................................................................................................15 C. EQUOTES EVALUATION REPORT (IMPLEMENTATION EVALUATION)....................................22 -2-
  3. 3. CS 590l Workshop I A.EQUOTES EVALUATION REPORT (REQUIREMENTS EVALUATION) An important phase in the software metamorphosis is the architecture framework part. It serves as the blue print for the software development process. It is well known that the home-brew architecture structuring is done ad-hoc and off-hand. At times, it depends on the narrowed focus of the stockholder involved in the architecture framing process. So, it is necessary to validate the product- especially real time systems, before it enters the market. Most of the traditional evaluation schemes are based on formal notational theory, which are complex and hard to apply in practice. Other than that, many of the methods validate based on a single quality attribute or can be applied only at a very late stage of the life cycle. Architecture Tradeoff Analysis Method (ATAM) is a practical technique introduced to overcome those difficulties. This is the first of a set of reports, which will apply ATAM to a real time system, EQuote- a distributed stock exchange model developed at UMKC as a part of an advanced software engineering course. Introduction: Software architecture describes a high-level configuration of components that compose the system, and the connections that coordinate the activities of those components. Software development process commonly starts with requirement analysis, followed by architecture design and analysis. The architecture selected for a particular system should be appropriate in a given context and here is where the process of Architecture evaluation comes into picture. Software architecture evaluation methods are the ways of measuring software architecture quality. These qualities fall into the following three categories [1]: 1. Qualities described by observing the output of the executing system in the presence of some input, such as security, reliability, and availability. 2.Qualities described by measuring the activities of a development or maintenance team, such as maintainability, portability, adaptability, and scalability and 3. Qualities described by measuring the activities of a particular user (possibly another system) in context with the executing system, such as usability, predictability, and learn ability. There are several lists of evaluation methods depending on the technique employed. The methods, which are most commonly applied, include [2]: Software Architecture Analysis Method (SAAM), Architecture Tradeoff Analysis Method (ATAM), Active Reviews for Intermediate Designs (ARID), Architecture-Level Modifiability Analysis (ALMA) and Family Architecture Assessment Method (FAAM). Although, some of these methods are subsets of the other, we use the ATAM due to its ease of practical applicability and step-by-step process method. The Architecture Tradeoff Analysis Method [3] is a method for evaluating software architectures relative to quality attribute goals. It is a means of determining whether the goals are achievable by the architecture, as it has been conceived, before enormous organizational resources have been committed to it. The ATAM exposes architectural risks that potentially inhibit the achievement of an organization's business goals. The ATAM gets its name because it not only reveals how well an architecture satisfies particular quality goals, but it also provides insight into how those quality goals interact with each other-how they trade off against each other. This is a repeatable analysis method in which the right questions are asked early on in the requirements and design phases when discovered problems can be solved relatively cheaply. This method leads to increased stakeholder communication that leads to a better understanding of the requirements. Often new requirements surface as a result of an evaluation. Thus, a major goal of this evaluation method is to evaluate the architectural design decisions to determine if they satisfactorily address the quality requirements. -3-
  4. 4. CS 590l Workshop I The rest of the report is organized as follows. In the next section, we summarize various functions of the EQuote systems and then, justify the relative merits in applying ATAM when compared to other methods. The software system is evaluated in the following section based on the initial steps involved in the ATAM process. This is followed by the contribution of group members towards this report. The last section concludes with a discussion on the future road map for the evaluation work. EQuote System: EQuote [4] is a system that involves any number of Web Services agreeing with the common criterion, a client-side web server that can find and pull the data from such Web services and a user interface implemented at the client side. Thus, a single point access is provided to the user for information stored at different places. This project focuses specifically on stock exchange and provides the end user to view detailed information of a particular company’s shares at various stock exchanges and also providing other features such as comparison at different stock exchanges, top gainers/losers etc using Web Services. The project aims at providing User Friendliness, Distributed sources and Restricted Access. A conceptual description of the system under consideration divides it into four logical layers. The layer furthest from the client is the data layer, which stores information required by the Web Service. Above the data layer is the data access layer, which presents a logical view of the physical data to the business layer. The data access layer isolates the business logic from changes to the underlying data stores and ensures the integrity of the data. The business layer implements the business logic of the Web Service. Client applications interact with the Web Service listener, which is responsible for receiving service requests from the client, parsing the messages, and dispatching the request to the appropriate method on the business layer. The eQuotes system comprises of a Client Request/Response Handler that is responsible for communication with the eQuotes Web Services server in order to receive the updates from the Stock exchange. There is a Polling Manager that is responsible for generating periodic requests to the Web Services Server to send the updated information. The polling manager sends the periodic requests to the Client Request Response Handler, which then communicates with the respective servers through the Server Request/Response Handler to receive the updated information. The Web-based UI is the user interface. An Operation Manager authenticates the client as well as checks if the request is being polled after its scheduled time interval before sending the request to the Server Database Manager. Two managers Client Database Manager and Server Database Manager exist to maintain database integrity. EQuotes delivers to the first kind of customer, an individual company - the facility to view the company’s performance on daily, monthly and annual basis. It can view its closing price, opening price, highest and lowest prices attained during a day etc. The company also gets a comparison of its performance on various stock exchanges. Monthly and annual information is provided as graphical representation. The other kind of customer, the stock exchange, can view its top 5 gainers, its top 5 losers, its stock index on days opening etc. Is ATAM- a suitable method for EQuote? EQuote is a real-time system, which necessitate multiple attributes at different dimensions and time scales. A minimum quality attribute tool box for a distributed and restricted access system is (1) Reliability, (2) Availability and (3) performance. Other additional QA (not related to real time property) is, modularity, portability and functionality. So, obviously any final evaluation report cannot favor particular QA based architecture due to its mutual exclusive nature. Hence, EQuote requires an evaluation method that considers different scenarios and suggests various alternatives (rather than the best one.) The main objective behind ATAM was to trade-off different QA-based styles and suggests different options. This makes ATAM a possible candidate for validating EQuote system. Traditional methods [5], [6] and [7] is not applicable to real-time systems due to its parochialism of a particular QA or stockholder. Even theoretical techniques like formal methods [8], Petri nets [9] and automata based approaches [10] are not applicable due to lack of easy, simple tools to validate the system. But, one of the interesting -4-
  5. 5. CS 590l Workshop I works will be to follow a hybrid approach, where we can introduce these theoretical techniques within the ATAM step-by-step approach. This is discussed in detail in the final section. EQuote Analysis by ATAM: In this section, we detail various initial steps involved in the EQuote evaluation process. One can consider this as the first day of the validation process. The final result of these steps will provide more clear and insightful picture into the different architecture styles. This will serve as an important input for the further phases of the ATAM process. Step Activity Stakeholder Groups Phase 1 1 Present the ATAM Evaluation team/Customer representative/Architect 2 Present business drivers Evaluation team/Customer representative/Architect 3 Present architecture Evaluation team/Customer representative/Architect 4 Identify architectural approaches Evaluation team/Customer representative/Architect 5 Generate quality attribute utility tree Evaluation team/Customer representative/Architect 6 Analyze architectural approaches Evaluation team/Customer representative/Architect Phase 2 7 Brainstorm and prioritize scenarios All stakeholders 8 Analyze architectural approaches Evaluation team/Customer representative/Architect 9 Present results All stakeholders “All stakeholders” includes developers, maintainers, operators, end users, testers, system administrators, etc. The above table diagrammatically represents the various steps involved in the validation. The following paragraphs will add more details to the above-mentioned activities. 1. Stakeholders and high level requirements In “e-quotes” the key stakeholders are the customer/ end user, the system architect and the developer. The customer or the customer representative will specify other requirements that the system needs to meet. Such as only authorized users are able to access the E-quotes system. Also since E-quotes is a real-time system, the performance of the system should be as fast as possible, the availability, failure recovery and other requirements will be specified by the user. The system architect will consider all the requirements specified by the user and come up with some architectures for the system. The system architect is responsible for presenting an architect such that it is reusable, easily modifiable, cost efficient and at the same time fast and finally all the components of the system should coordinate well with each other thus making the system consistent. The system architect gives a framework to the developer to work with. The developer is responsible for following the framework and choosing an appropriate programming language for this framework. -5-
  6. 6. CS 590l Workshop I 2. Quality attributes The various QA associated with an ATAM were discussed in Section B. It is important to iterate the ATAM steps to precisely choose the use cases for Security, performance and availability based architecture styles. The security of the system is necessary due to the dynamic management of states in the EQuote system. Performance is required due to the distributed nature of the stock market model. Availability is a criterion as minimum access requirements is necessary. More details about various QA can be obtained from the type cases considered in the ensuing step. 3. Scenarios elicitation The below table comes within step 5 of the phase I. It gives insight into finding the trade-off and sensitive points in a software system. Stakeholder Type Scenario QA Customer Use Case Integrated view of all information on internet Reliability No unauthorized access to the system Security All operations are processed in fastest possible Performance speed Any failure should be followed by immediate Availability recovery User errors should be handled and appropriately Reliability reported System must be scalable Modifiability Data integrity maintained at all times Reliability Growth User Interface must be customizable Performance User profiles must be maintained Performance System Use Case Major parts of the components should be re- Modularity Architect usable for future architectures System modification is cost-effective, fast and Modifiability in minimal time Components interact in a coordinated manner Functionality System expansion is possible to allow for more Modularity sophisticated options Implementation allows for execution in different Portability environments Proper data encapsulation and secure data Security structures Compatibility with various platforms Portability Overall consistent behavior of architecture Conceptual Integrity Exploratory Addition of new kind of customers, like the Modifiability stockbroker who would like projections on prices of various stocks by processing historical data. Developer Use Case Framework should be complete, clear and Functionality perform exactly as required. -6-
  7. 7. CS 590l Workshop I 4. Analysis ATAM analysis phase came into picture when the initial scenario elicitation, architecture elicitation and scenario mapping were over thereby laying the foundation for a thorough analysis of the system. For the e-quotes system the analysis of the system was performed after getting familiar with the architecture and brainstorming the use cases and the scenarios made available to us by the e-quotes team. After a thorough review with the e-quotes architecture we observed a sound architecture for the system. The first question raised was about the lucid functionality of the architecture. Do the components interact in a coordinated manner or not? How the system stands against unauthorized access. Is it reliable enough to view confidential information? Is the system modifiable considering the changing needs of the users? How the architecture score performance wise? Is the data retrieval fast enough? How the system copes with the failure of one or more components? Is it compatible to be used on different platforms? Is the architecture modular? Is the future system modification cost effective and fast? Does it allow for more sophisticated options? The screening questions asked above were applied to the architecture at hand and the system was evaluated against quality attributes such as reliability, modifiability, portability, security, modularity, performance and functionality. The architecture of the system was found to be fully adaptable to future changes as no coupling was found between the user interface and the client DB manager. Thus there is no dependency on the working of the underlying architecture of the system. The user interface is therefore easily modifiable as per the changing needs of the user. The architecture was found to be effective in functionality as there was clear communication and interaction between the various components of the system. The requirements state that user authentication is required to enter the system. An Operation Manager should authenticate the client as well as check if the request is being polled after its scheduled time interval before sending the request to the Server Database Manager. However, possibly due to the complexity of incorporating encryption algorithms, none of the actual security features have been implemented in the final system. Two managers Client Database Manager and Server Database Manager maintain database integrity, the user does not directly interact with the databases on the data sources. The sources providing web services can specify the amount of data to be revealed depending on some agreements. This makes the system highly reliable. So overall the architecture meets it’s goal to provide the user a centralized retrieval of data from distributed sources in a secured fashion. After the analysis a few suggestions were put forward to make the system more user- friendly. It was suggested to maintain a user profile which would keep track of all the information viewed by a particular user over a given period of time. Such personalized services would make the system more user-friendly. Finally, security features could be implemented so as to guarantee secure transactions and prevent unauthorized access. Individual contribution of group members: Name of Member Contribution 1. Senthilkumar Ayyasamy Discussion of suitability of ATAM, Quality Attributes for EQuotes 2. Tulika Rathi Discussion of the Equotes System and scenario elicitation 3. Seema Joshi Discussion of Stakeholders, Requirements & scenarios 4. Diksha Agarwal Discussion of EQuote Analysis -7-
  8. 8. CS 590l Workshop I 5. Manali Joshi Discussion of Software Architecture Evaluation, methods used for evaluation and what is ATAM. Workshop web-page Conclusion and Future work: In this report, we have discussed ATAM and applied them to EQuote- a real time system developed as a part of the course project. A previous section in this report detailed on the reason for using ATAM for EQuote system. Most of the steps in the ATAM depend on the feedback obtained from the stockholders. So, the preciseness of the final analysis is directly proportional to the elicitation questions posed towards the stockholders at various phase. But, there is no standard procedure for such a process. An important property of the traditional formal analysis is the narrow depth-wise analysis (unlike ATAM which is breath-wise.) So, an important future work for the further reports is to incorporate some formal techniques to the ATAM. Also, this report serves as the torchbearer for the further detailed analysis steps, which will be dealt in ensuing reports. References: [1] K. Bhargavan, C.Gunter, and D.Obradovic, “ The village Telephone System: A Case Study in Formal Software Engineering,” TPHOL 1998. [2] P. Clements, R. Kazman, and M. Klein, “ Evaluating Software Architectures: Methods and Case Studies,” Addison-Wesley, 2002. [3] R. Kazman, M. Klein, M. Barbacci, H. Lipson, T., Longstaff, S.J. Carriere, “ The Architecture Tradeoff Analysis Method,” Proceedings of ICECCS. Monterey, CA, August 1998. [4] G. Sharma, A. Masasta, A. Biswas, and S. Yolekar, “ eQuote System,” CS 551 project report, UMKC, Dec 2002. [5] D. Hamlet, D. Mason and D. Woit, “ Theory of Software Reliability Based on Components,” ICSE 2001. [6] K. Rick, A. Gregory, B. Len and C. Paul. "Scenario-Based Analysis of Software Architecture," IEEE Software November 1996, 47-55. [7] K. Bhargavan, C. Gunter, and D. Obradovic,” Fault origin adjudication Formal Methods in Software Practice,” August 2000. [8] M. Barnett and W. Schulte, "Contracts, Components, and their Runtime Verification on the .NET Platform", Microsoft Research Technical Report MSR-TR-2002-38. [9] M. Barnett and W. Schulte, "The ABCs of Specification: AsmL, Behavior, and Components". Informatica 25(4), Nov 2001 [10] M. Barnett and W. Schulte, "Spying on Components: A Runtime Verification Technique", in OOPSLA 2001, Iowa State Technical Report 01-09a, 7-13. -8-
  9. 9. CS 590l Workshop I B.EQUOTES EVALUATION REPORT (DESIGN EVALUATION) Evaluation Method: The software architecture represents the earliest software design decisions. These decisions affect reliability, modifiability, security, real time performance, interoperability goals and requirements. They are the most critical to get right and the most difficult to change downstream in the development life cycle. The right software architecture often results in a system that fails to meet critical requirements and incurs high maintenance costs. There are many relevant views of software architecture and which one is relevant depends on the stakeholders and the system properties that are of interest. If we consider the analogy of the architecture of a building, various stakeholders all have an interest in how the building is to be constructed. Although they are interested in different components and different relationships, each of their views is valid. Each represents a structure that maps to one of the construction goals of the building, and all views are necessary to represent the architecture of the building fully. Similarly, software architecture has a variety of stakeholders, including possibly the development organization, the end user, the system maintainer, the operator, and the acquisition organization. Each of these stakeholders has a vested interest in different system properties and goals that are represented by different structural views of the system. These different properties and goals and their corresponding architectural views are import to understand and to analyze. They provide the basis for reasoning about the appropriateness and quality of the architecture. The following figure shows the common architectural views: -9-
  10. 10. CS 590l Workshop I As per [1], the 4+1 model view can be summarized as: 1. The conceptual (logical) view, which represents system functions, key system abstractions, their dependencies, and the data representation. 2. The module (development) view, which represents the decomposition of the system’s functionality. This can include objects, procedures, functions and their relationships. 3. The coordination (process) view, which represents the processing threads, their synchronization, and data flow 4. The physical view, which represents hardware including processors, storage, and external devices or sensors, along with the communications paths that connect them. 5. The scenario, which is the fifth view, illustrates the above four views by a few selected use cases. The architecture is in fact partially evolved from these scenarios. Purpose: Architectures allow or preclude almost all of the system’s quality attributes. If software architectures are important, then so are software architecture evaluations. A major goal of an evaluation is to elicit architectural risks. Evaluation gives the architecture team an agenda to work towards building an efficient architecture. Evaluation unfolds aspects of the architecture that were overlooked during the initial design. The purpose of the ATAM is to assess the consequences of the architectural decision alternatives in light of quality attribute requirements. The major goals of the ATAM are to: 1. Elicit and refine a precise statement of the architecture’s driving quality attribute requirements 2. Elicit and refine a precise statement of the architectural design decisions. 3. Evaluate the architectural design decisions to determine if they satisfactorily address the quality requirements. The method does not need to produce detailed analyses of any measurable quality attribute of a system (such as latency or mean time to failure) to succeed. Instead, success is achieved by identifying trends. The ATAM achieves these goals by involving a wide group of stakeholders. It is meant to be a risk mitigation method, a means of detecting areas of potential risk within the architecture of a complex software-intensive system. An evaluation team experienced in software architecture and the method leads this group of stakeholders to ensure that the right questions are asked to discover 1. Risks: alternatives that might create future problems in some quality attribute 2. Sensitivity points: alternatives for which a slight change makes a significant difference in a quality attribute 3. Tradeoffs: decisions affecting more than one quality attribute Why ATAM? The whole purpose of workshop-1 is to understand the evaluation of software architecture by means of ATAM (a practical evaluation system.) Hence, it is necessary to verify whether ATAM is a right kind of approach for all the three major phases: requirements, architecture and implementation analysis. In the last report, we have seen how an ATAM step can be used for requirement analysis. This report details on the architectural trade-offs and hence, it is necessary to analyze the applicability of ATAM system. In this section, we will compare other architectural evaluation schemes with ATAM. The ATAM system is based on the 4+1 model of architectural view analysis. Hence, the initial step in applying ATAM is common with 4+1 methodology. But, it is important to compare our method with other traditional methods before applying ATAM. Hence, we introduce a state machine for quality attributes for traditional automata theory based analysis. - 10 -
  11. 11. CS 590l Workshop I Performance Security Cost Scalability In the above Quality attribute system, the states (security, performance, Cost and Scalability) are pre-defined for any type of software system (depending on the specification.) But, the stationary and transient states are defined based on the system under study. In our case, the above state diagram can represent a QA based requirements. Once a state diagram is in place, a lot of techniques can be applied to study them. Some of the common methods include: 1. Applying first order predicate logic to derive equations for the above system. Then, we can formulate a global optimization problem for a particular metric. 2. Automata based predictions involve numerous microstates to represent each of the individual major states. But, a standard technique is still not found. All the techniques depend on some heuristic based or empirical based solving. 3. A very easy approach is to apply the state transition rules to model checkers and just validate for use case correctness. 4. Make all the transitions to follow proximity rules and then, apply known markov queuing network checking method. All the above techniques depend on the base state transition formulation. But, the state transition formulation can be done to optimize only particular metric. For example, if local optimization is done for security, it will not consider other quality attributes into account. So, they are generally not feasible for applying to practical systems. But, some of these techniques can be exploited in Meta phases associated with ATAM method. The original Equote system was designed from a developer perspective.i.e. simplicity of coding was given high priority when compared to other QA. So, the above evaluation methods will be applicable to such narrow validation process. But, when building a large software system, evaluation process should take all factors into account. - 11 -
  12. 12. CS 590l Workshop I EQuote System Architecture: In this section, we will analyze the Equote system from the ATAM architecture analysis point of view. Architectural requirements: Establish and document the requirements on the architecture Requirements analysis is about the modeling of software requirements in the information, functional, and behavioral domains of a problem. It includes a tradeoff analysis of performance requirements and the constraints on a system, along with all of the perceived primary and derived requirements of a system, which highlight the effect on development cost and schedule. It includes knowledge about various requirements modeling methods (e.g., structured analysis, object-oriented analysis), the use of prototyping to examine and assess requirements, and domain analysis techniques. It refines our understanding of the data analysis requirements of various stakeholders. Context Understand the key organizational, business, competitive, and technical drivers affecting your architecture. Collect architectural requirements from all key stakeholders. Clarify the organization's objectives for the architecture. Decide on system boundaries. State specifically what problems the architecture will address and what it will not. Customer Collect and document requirements from the three key customers of an architecture: the internal sponsors or business decision makers, the developers who will utilize the architecture to build products, and the end user. Vision Create and communicate a vision of how the architecture contributes to long-term business success. Functional Requirements: Identify representative functions of the system from a user's perspective. Document in Use Cases those product requirements that affect the overall architecture. For each requirement, identify the actors (people or other systems), the goal, the assumptions, and the steps required. Document those Use Cases that will impact the architecture. Non-functional Requirements: Express the non-functional requirements such as inter-operability, agility, and extensibility in terms of precise statements, test cases, and scenarios. Test Cases: - 12 -
  13. 13. CS 590l Workshop I Refine requirements like "extensibility" by developing test cases with specific measures (specific extensions, achievable in how much time, requiring what resources, and with what impact to the organization). Scenarios Develop scenarios, or stories, which express anticipated future challenges (organizational, strategic, and technical) that the architecture may have to address, such as integrating new technologies or outsourcing. The following questions can be put forward for requirement analysis:  What mission need is addressed by a requirement?  Where is a requirement implemented?  Is this requirement necessary?  How do I interpret this requirement?  What design decisions affect the implementation of a requirement?  Are all requirements allocated?  Why is the design implemented this way and what were the other alternatives?  Is this design element necessary?  Is the implementation compliant with the requirements?  What acceptance test will be used to verify a requirement?  Are we done?  What is the impact of changing a requirement? Based on this, the system-to-be is described within its operational environment, along with relevant functions and qualities. The following table shows the requirement analysis of existing e-Quotes: Requirement Importance Level Design decision for this requirement Web service must be located High Registration of service is required. Use UDDI Data from number of stock High Link to a number of stock exchanges and exchanges must be displayed get data from them into e-Quotes database Latest data has to be extracted High Real time implementation of the system User friendly interface High Use ASP to develop UI Performance High Use .NET and XML Security Medium Use of password to authorize client Intelligence Low Minimal Knowledge Mining module Expandable High Object oriented technology (C#) Reusable High Object oriented components (C#) Architectural Styles: An architectural style is a description of component types and their topology, which includes a description of the pattern of data and control interaction among the components. Architectural styles also provide an informal description of the benefits and drawbacks of using that style. Architectural styles are important engineering artifacts because they define classes of designs along with their associated known properties. They offer experience-based evidence of how each class has been used historically, along with qualitative reasoning to explain why each class has its specific properties. Using architectural styles allows an architect to reuse the collected wisdom of the architecture design community in much the same way that object-oriented design patterns give novice designers access to a vast array of experience collected in the object-oriented design community. - 13 -
  14. 14. CS 590l Workshop I The architectural style, which can be employed for the Equote project is attribute-based architectural styles. More details on attributed based architectural styles can be obtained from [x]. The various steps involved in the architectural styles include [7]: Problem description - informally describes the design and analysis problem that the ABAS are intended to solve, including the quality attribute of interest, the context of use, constraints, and relevant attribute-specific requirements. Stimulus/Response attribute measures - a characterization of the stimuli to which the ABAS are to respond and the quality attribute measures of the response. Architectural style - a description of the architectural style in terms of its components, connectors, properties of those components and connectors, and patterns of data and control interactions (their topology), and any constraints on the style. Analysis - a description of how the quality attribute models are formally related to the architectural style and the conclusions about "architectural behavior." With respect to Equote system, a number of QA listed in the below sections can be used to specify a certain Architectural style. We have to define the style for a particular QA (like security.) So the analysis and stimulus/response will be written with respect to security alone. This phase will greatly help in finding the sensitivity and trade-off point quickly. Evaluation Process: The evaluation team had discussions regarding the architectural needs for Equotes system. After these points were noted, the existing system was evaluated against these points using the 4+1 views. Group members were asked to suggest possible enhancements to the existing system so that it could be made more robust and functionally better. Work was then distributed among the group members to present this evaluation in a report form. Evaluation process (evaluation method  e-quote system architecture): (Architectural) Quality attributes: From the architectural point of view the following quality attribute need to be considered: Security No unauthorized access to the system Functionality Components interact in a coordinated manner Framework should be complete, clear and perform exactly as required Conceptual Integrity Overall consistent behavior of architecture Modifiability Addition of new kind of customers, like the stockbroker who would like projections on prices of various stocks by processing historical data System must be scalable Availability Any failure should be followed by immediate recovery Performance User profiles must be maintained Modularity Major parts of the components should be re- usable for future architectures System expansion is possible to allow for more sophisticated options - 14 -
  15. 15. CS 590l Workshop I Analysis & Suggested Enhancements: The Logical View The logic view gives the high level description of what the system should provide in terms of services to its users. Here as a further enhancement to the e-quote system we suggest an addition of a security component that would perform the user validation for reliable and secure viewing of information. Also providing further services to the user we suggest maintaining user profiles and as a very major enhancement to this system stock-trading services can also be offered. e-quote A.WEB SERVICE Suggested enhancement B.SECURITY COMPONENT C.LOGIN D.USER INTERFACE Stock Exchange Details Services Company Stock Comparative Suggested Details Services Analysis enhancement Services Suggested enhancement E.STOCK TRADING User Profile Services - 15 -
  16. 16. CS 590l Workshop I The Development View: The development view for the e-quote system consists of three layers of subsystems. The first layer is the server layer, which has three sub-layers in it as depicted above. The second layer is the client layer, which again has three sub-layers in it. The suggested enhancements of web mining component and the security component would be added in the client layer. And the highest level or the top most layer is the user interface, which sits on top of these layers. User Interface The user interface pulls out the 3 appropriate data from the client side database. Client Request/Response Handler Communicates with the Web Services server to receive updates from the Stock Exchanges. Received information is sent to the database for updation via the Client Error Handler. Client Polling Manager Interacts with Client Request/Response handler, determines the frequency of retrieval of information from a Web Service server. Checks the data received from the Client Database Manager Web Service server for correct format so that it can be sent to the database for updation. This listens for the request coming Server Request/Response Handler from the Client Request/Response Handler and issues the corresponding response. Validates the client request Operations Manager received by Server Request/ Server Response Handler and maintains a log file of all the incoming requests. Server Database Manager Performs database operations of search and retrieves and flags all the data, which have been updated so that only the recently updated information would be sent back to the client. The Process View: The process view, at the highest level, describes a set of independently executing processes distributed across a set of hardware resources. A process consists of tasks that can be executed as a group. Here we have described the ideal process structure for the Equotes system that includes some enhancements as suggested by the evaluation team. - 16 -
  17. 17. CS 590l Workshop I Web Mining Component Process The Physical View: The physical view primarily takes into account the non-functional requirements of the system such as availability, reliability, performance and scalability. Here we have shown the interaction of the system components at the physical level. The diagram also shows the enhancements as suggested by the evaluation team. - 17 -
  18. 18. CS 590l Workshop I Web Client Handler for Mining Requests & Component Response S E Polling Client DB Manager C Manager U 1. C R li I T Y Server-side Handler End users with C for Request & browsers O Response M P O N Db Operation Manager E Server DB N Manager T 2. S Cache e Component The evaluation has presented the 4+1 views for the EQuotes system in the Analysis section. After detailed discussions and by following the guidelines of the 4+1 views, the overall existing architecture was found to be quite satisfactory. The team came up with certain components, which could be added to further enhance and better the system. The general flow of events as analyzed by the evaluation team is as follows: 1. The first component that the browser hits is the Security Component (suggested). This component may be a firewall or an independent device. It will ensure that only authorized users will gain access to the system and hence query it. 2. The next component here is the Cache Component (suggested), which has the ability to handle hundreds of connections for content request on behalf of the web server. 3. The polling manager polls the client handler after every interval of time to retrieve the latest data. It also interacts with the Client DB manager to perform validation of user data, add and delete entries etc. Only after a particular client has been properly authenticated will the DB manager perform any updates on the Client DB. 4. Another suggestion here is to have a web mining component here as an enhancement to the Equotes system. This component will be like a personalized user-profile that can be used to perform analysis using the data- mining concept. Here the system could maintain a record of the companies whose stocks a user is usually interested in, it could present a research analysis on the current company trends. Also a trend analysis of the stocks of companies could be presented in report/graphical form for the benefit of the user. - 18 -
  19. 19. CS 590l Workshop I 5. The Client Handler queries the Server Handler that validates the client. Only after this process, the Server Db manager is queried to obtain the results for the client. The server-side Db manager fetches the latest data from the Server DB and the results are provided to the user. Scenario Analysis: 1. The client logs in using his login name and password. 2. The Polling Manager polls the Client Request/Response Handler after a specific interval to retrieve the latest data. 3. The Client Request/Response handler queries the Server Request/Response Handler who validates the client. 4. If the client is a valid one it queries the Server DB Manager for latest data and fetches the data from the server-side database returning it to Client Request/Response Handler. If the client is not valid, it returns “null” data. 5. The Client Request/Response Handler then invokes the Client DB Manager for validation of the data and then its addition to the client-side database. 6. The data is validated at the Client DB Manager and added to the database if valid. 7. The user can then retrieve information by interacting with the user interface. Considering just one scenario where the Client Request/Response Handler retrieves the interval from Server DB Manager. - 19 -
  20. 20. CS 590l Workshop I Individual contribution of group members: Name of Member Contribution 1. Senthilkumar Ayyasamy Discussion of suitability of evaluation method, Architectural Styles 2. Tulika Rathi Content, Architectural Requirement Analysis 3. Seema Joshi Architectural Quality Attributes, Scenario 4. Diksha Agarwal Logical & Developmental views 5. Manali Joshi Process & Physical Views, Evaluation Process Conclusion: In this report, we have discussed ATAM as an evaluation method and how the 4+1 views can be applied to EQuote- a real time system developed as a part of the course project. The 4+1 model allows the various stakeholders to find out what they want to know about the software architecture. The method helped in approaching the evaluation task from different perspectives through the different views. This helped to analyze the existing system architecture in a better way and identify the inconsistencies. The ensuing report will now present the final evaluation from the implementation perspective. References: [1] Hamlet, D. Mason and D. Woit, “ Theory of Software Reliability Based on Components,” ICSE 2001. - 20 -
  21. 21. CS 590l Workshop I [2] K. Rick, A. Gregory, B. Len and C. Paul. "Scenario-Based Analysis of Software Architecture," IEEE Software 2001. [3] K. Bhargavan, C. Gunter, and D. Obradovic,” Fault origin adjudication Formal Methods in Software Practice,” August 01. [4] M. Barnett and W. Schulte, "Contracts, Components, and their Runtime Verification on the .NET Platform", Microsoft Research Technical Report MSR-TR-2002-38. [5] M. Barnett and W. Schulte, "The ABCs of Specification: AsmL, Behavior, and Components". Informatica 25(4), Nov 01. [6] M. Barnett and W. Schulte, "Spying on Components: A Runtime Verification Technique", in OOPSLA 2001, Iowa State Technical Report 01-09a, 7-13. [7] Mark Klein and Rick Kazman, Attribute-Based Architectural Styles, Technical Report CMU/SEI-99-TR-022 - 21 -
  22. 22. CS 590l Workshop I C.EQUOTES EVALUATION REPORT (IMPLEMENTATION EVALUATION) Evaluation Method: Content: We will be using the idea of Abstract State Machines for the implementation evaluation of the e-quote system. The idea is to provide operational semantics for algorithms by the use of Turing’s thesis wherein every algorithm is simulated by an appropriate Turing machine. Turing machines give operational semantics to algorithms, however they are not very good. The solution lies in looking for machines that are able to simulate algorithms much more closely. Evolving Algebra’s, or EA’s are supposed to be such machines. The basic idea behind an EA is simple. In the sequential case, when time is sequential, only a bounded amount of work is done on each step. Each state can be represented by a first order structure ie a set with relations and functions. We can go from one state S(i) to the next state S(i+1) by performing a bounded number of changes in S(i). This way the whole algorithm can be rewritten as a finite number of transition rules of very simple form. Justification for the Evaluation Method: The implementation evaluation is done by means of Abstract State Machines (ASM). ASM is generally used for verifying and sometimes, even correcting the problems occurring during the run-time compilation of the code. Also, it is one of the few methods available for validation of implementations. ASM takes varies parts of the implementation as separate states and optimizes the coding phases. It also validates the steps for coding capability. Some of the other alternatives and their associated demerits include: 1. Algorithmic time complexities: A lot of insight can be inferred by observing the time and space complexity of the code. Most of the programming language libraries have a function to calculate the time complexities. But, some of the disadvantages associated with this method are: - It cannot check for semantic correctness. Some of the recent methods (which incorporates first order logic allow semantic correctness.) - Also, time complexity calculations are helpful for unit-process systems. It is not useful for real time systems, which has multi-dimension constraints. 2. ATAM model: In general, ATAM is used for evaluating the architectural blue print. It trade-off architectural constraints and suggests various better alternatives for the initial layout. Although, developers are also considered as a stock-holders, ATAM cannot be used for coding evaluation due to: - ATAM process is done before the coding phase. So, it cannot catch minor implementation details. - The goal of the ATAM is better architecture. For a better architecture, we should not consider data structures etc at the starting phase. 3. Some other methods like robustness testing are available. But, they are more specific for buffer over-run testing (which is not applicable.) EQuote Prototype: Requirement Analysis: Client Side Requirements: The e-quote system aims to provide the centralized information to the user from distributed sources. The objective is to provide a user-friendly GUI, restricted access to the databases to provide secure information, achieving the - 22 -
  23. 23. CS 590l Workshop I dynamic integration of web services, which comply with the requirements of the system and providing detailed analysis to the user by means of graphs. The following requirements were met in the actual implementation of the e-quote system: 1. The transfer of data at a regular interval basis from the server to the client. 2. The implementation of the polling manager that would pull the data from the server to itself at periodic intervals. 3. User-friendly registration utility. 4. Providing a detailed analysis of information received to the end user. 5. Making the system capable of dynamic integration of web services. 6. Mining component to provide personalized services as future work. Data Mining Component: Data mining is the process of non-trivial extraction of implicit, previously unknown and potentially useful information like knowledge rules, constraints and regularities from data in databases. This interesting knowledge, regularities or high level information from relevant sets of data can be investigated from different angles. Large databases thereby serve as rich and reliable sources for knowledge generation and verification. This information or knowledge gained can be used in applications ranging from business management, production control, and market analysis, to engineering design and science exploration. Data mining tools perform data analysis and may uncover important data patterns, contributing greatly to business strategies and knowledge bases. Process of knowledge discovery: 1. Data Cleaning: to remove noise and inconsistent data. 2. Data Integration: where multiple data sources may be combined. 3. Data Selection: where data relevant to the analysis task are retrieved from the database. 4. Data transformation: where data are transformed or consolidated into forms appropriate for mining by performing summary or aggregation operations. 5. Data mining: an essential process where intelligent methods are applied in order to extract data patterns. 6. Pattern evaluation: to identify the truly interesting patterns representing knowledge based on some interestingness measures. 7. Knowledge presentation: where visualization and knowledge representation techniques are used to present the mined knowledge to the user. The data mining system can have the following components: • Database, data warehouse, or other information repository This is a set of databases, data warehouses, spreadsheets or other kinds of information repositories. Data cleaning and data integration may be performed on the data • Database or data warehouse server This is responsible for fetching the relevant data, based on the user’s data mining request • Knowledge base This is the domain knowledge that is used to guide the search, or evaluate the interestingness of resulting patterns. Such knowledge can include concept hierarchies, used to organize attributes or attribute values into different levels of abstraction. Knowledge such as user belief’s, which can be used to access a pattern’s interestingness based on its unexpectedness, may be included. • Data mining engine This consists of a set of functional modules for tasks such as characterization, association, classification, cluster analysis and evolution and deviation analysis. Figure 2 shows the architecture of a typical data mining system • Pattern evaluation module This component typically employs interestingness measures and interacts with the data mining modules so as to focus the search towards interesting patterns. It may use interestingness thresholds to filter out discovered - 23 -
  24. 24. CS 590l Workshop I patterns. Alternatively, the pattern evaluation module may be integrated with the mining module, depending on the implementation of the data mining method used. For efficient data mining, it is highly recommended to push the evaluation of pattern interestingness as deep as possible into the mining process so as to confine the search to only the interesting patterns. Requirements of data mining component: • Handling of different types of data • Efficiency and scalability of data mining algorithms • Usefulness, certainty and expressiveness of data mining results • Expression of various kinds of data mining results • Interactive mining knowledge at multiple abstraction levels • Mining information from different sources of data • Protection of privacy and data security Server Requirements: • Windows NT Server 4.0, • Microsoft Internet Information Services (IIS) 5.0 for the Web Server. • 256 MB of Available RAM • 10 GB of Available Disk Space • Personal computer (PC) with a Pentium III-class processor 1.00 gigahertz (GHz) • Internet connectivity with firewall access permitting an outside connection. • Your website's server must allow the use of VB Scripts. • In order to ensure security the server should have provision for an SSH connection. Backend (Database) Requirements: • Improve resource utilization (reduce I/O contention, improve memory allocation, etc.). • Tune physical database layout to promote maintainability. • Backend requirements and implementation cost should be considered separately • Database efficiency and performance are of utmost importance. This is in terms of the query response time and record access time. • Secure back up / restore procedures. • Scalability over multiple platforms • There should be reliability and security for any kind of transaction that is performed on the database. Technologies and Tools: Web Services can be founded on the following major technologies: SOAP: SOAP is a lightweight protocol for exchanging information in a distributed, heterogeneous environment using XML. It enables cross-platform interoperability and is protocol and hardware independent. Thus it basically provides a means of communication between Web services and client applications. It is essentially an XML based protocol that consists of three parts: an envelope that defines a framework for describing what is in a message and how to process it, a set of encoding rules for expressing instances of application-defined data-types, and a convention for representing remote procedure calls and responses. SOAP messages are actually XML messages bound in a SOAP envelope. These messages are transported over HTTP since it is firewall friendly. Also, SOAP works over the existing Internet infrastructure. - 24 -
  25. 25. CS 590l Workshop I UDDI: A registration database is required for all Web Services so that they can be discovered by other applications. UDDI (Universal Description, Discovery and Integration) precisely provides such a mechanism for registration and discovery. It provides schema for service providers and description of the service. It provides an API for publishing and searching. It has been developed on industry standards – XMl, HTTP, TCP/IP, SOAP. It applies to both XML and non-XML services. WSDL: Web Services Description Language (WSDL) is an XML schema for describing Web Services. It provides the service interface definition and also the implementation definition. The description includes details like data type definition, the operations supported by the service, input/output message formats, network address, protocol bindings, etc. XML: XML is designed to represent and transfer structured data. It does not display or transform data. XML schemas describe the structure of an XML document. They also present the tag and attribute specifications and constraints on the contained text. SOAP, which is used commonly for implementation of web services, is an XML-based protocol. .NET Framework: The .NET Framework enables developers to build, deploy, and run XML Web services and Microsoft .NET– connected applications. This framework consists of several class libraries and the Common Language Runtime. The common language runtime is responsible for run time services such as language integration, security enforcement, memory, process, and thread management. Base classes provide standard functionality such as input/output, string manipulation, security management, network communications, thread management, text management, user interface design features, and other functions. The Microsoft ADO.NET data classes support persistent data management and include SQL classes for manipulating persistent data stores through a standard SQL interface. XML classes enable XML data manipulation and XML searching and translations. The Microsoft ASP.NET classes support the development of Web-based applications and XML Web services. The multiple language capability of the .NET Framework enables developers to use the programming language that is most appropriate for a given task and to combine languages within a single application. C#: Microsoft Visual C#™ .NET offers beginning and intermediate developers with C++ or Java experience a modern language and robust development environment for creating XML Web services. Immediately familiar to C++ and Java developers, C# is a modern and intuitive object-oriented programming language that offers significant improvements, including a unified type system, "unsafe" code for maximum developer control, and powerful new language constructs easily understood by most developers. Developers can enjoy a modern, component-oriented language with inherent support for properties, indexers, delegates, versioning, and custom attributes. With XML comments, C# developers can produce useful source code documentation. Web Interface: Web Interfaces can be developed using ASP or JSP. Active Server Pages is a server-side scripting technology developed by Microsoft. With ASP you can create dynamic web pages by putting script code inside your HTML pages. The web server executes the code before the page is returned to the browser. Both Visual Basic and JavaScript - 25 -
  26. 26. CS 590l Workshop I can be used. JSP is a server-side technology much like ASP developed by Sun. With JSP you can create dynamic web pages by putting Java code inside your HTML pages. Since JSP uses Java, the technology is not restricted to any server-specific platform. Databases: Different database systems like MS Access, SQL Server, Oracle etc can be used for the databases to be maintained for the Web Service application. MS Access may be used when a simple database solution is required. Evaluation Process: Scenarios: To test the robustness of the application and its ability to deliver the proposed deliverables test cases are formulated to test the application under extreme inputs. The application must either be able to provide with the required output or it must be able to avoid a crash and supply the user with an appropriate error message. This helps in analyzing the application’s implementation requirements. The test cases for equotes can be: 1. Extensive check of the user interface • Make sure all user interface components (list box, buttons etc) are working properly • All screens must work properly and no events generate exceptions. 2. Check for the correctness of values and graphs displayed • Correct stock values are being displayed • Validate the business knowledge used to generate the graph 3. Database • Integrity • Security • Recovery Quality Attributes: There are several issues that need to be considered during the quality assurance process of the implementation phase. 1) Security: Internet related software usually have security guidelines to safeguard the privacy of their customers. The testing process during the QA phase should see to it that there is no loophole in the code using which an intruder could get access to the customer information. Any security algorithm such as DES and RSA can be used for this purpose. The E-quotes system being a real-time and Internet related system should have the security feature. The code needs to have a provision for security. Also the database has to be secured using a password, so that an intruder is not able to access and change the database even though he is able to download the database somehow. 2) Correctness and Robustness Correctness of a software is the extend to which it is consistent with the requirement specifications of the system, the extent to which it is free of all design and coding defects and the extent to which the software meets user expectations. And degree of a robustness of software is defined as the extent to which it can continue to operate correctly despite the introduction of invalid inputs. Correctness and Robustness can be achieved by strong static typing, automatic initializations and automatic memory management, following coding standards and by testing the software thoroughly. By doing this we can be assured that our software is safeguarded from runtime type mismatch failures, un-initialized data reads, incorrect memory allocation, de-allocation or accesses. By doing code reviews and unit testing we trap the higher-level design defects (e.g., inconsistencies, omissions) as well as the lower-level code defects (e.g., flawed control-flow, data-flow, sequencing, and efficiency). - 26 -
  27. 27. CS 590l Workshop I The E-quotes software should be fast and should refresh the updated stocks soon. The software should follow the system design as closely as possibly. Also the user interface should be simple for the user to understand and at the same time should contain a lot of information. 3) Portability and Compatibility Portability is defined as the ease with which software can be transferred from one computer system to another. Development Language and Environment (supporting automatic dependency analysis, adapting and renaming external interfaces, etc.) helps to achieve consistency and ease of building applications on different platforms and in combining independently developed components (e.g., assists in adapting and components.) thus making the software portable. Also following proper coding standards are used so that coding is done using conventions, which ensure portability and compatibility. A good code review identifies the portability and compatibility problems in the code. Also testing will help identify the non-portable and incompatible code at compile-time (on each supported platform). E-quotes is based on newer technologies like Microsoft’s .Net and languages such as XML and C# which have great potential for portability. Even the Web Designer is subject to portability issues as they consider what browsers and browser plug-ins are being used when their site is being viewed. 4) Usability Usability is can be defined as a combination of Learnability, Memorability and Simplicity of use. A measure of how usable a system is for an application. For desktop applications, it could mean whether it requires special education for the user, or more verbose documentation. This also relates to how easy a system is to use – for example, we all know that most users can operate a GUI much better than a DOS command line. This is achieved through thorough requirements analysis with input from the end users. This can include good user documentation, a graphical user interface, standard interface patterns and shortcuts available for advanced users. Techniques like a User-Centered Design (UCD) will help to obtain early and continuous input from the actual users. By doing system testing, we can uncover usability problems with applications during development rather than during production use. Also if we use real-world concepts we can leverage the users knowledge and at the same time the users will perceive the system as natural and intuitive. The users will perceive the software as simple if we use less number of objects that the user needs to understand. The E-quotes software should have a user-friendly interface so that the users are able to understand and easily recollect how to use it. Also proper documentation has to be provided to users considering that the users are absolute layman and by considering cases and situations that a common use may stumble upon. 5) Extendibility and Reusability This relates directly to the code – whether or not objects or other parts of the system can be reused effectively for use in other applications. This is really of internal use to the company only, though it can (and should) translate into lower costs of software for the company, and possibly the consumer in the future. By using information hiding techniques, abstract data types and multiple inheritances we can limit the locality of impact of changes and also provides systematic structure for implementing Information Hiding. Genericity factors out common code, which can be reused. Also during code review the potential modifiability problems in code should be identified. The code should be as modular as possible so that the company can use those modules later. The programmer should also keep in mind that the code has to be understandable and consistent in form, so that there would be lesser learning curve for another programmer in the future. In order to achieve understandability the programmer needs to follow the coding conventions and also provide sufficient comments and documentation with his code to be able to understand the significance of sections of code. Flexibility within the code to handle situations; a certain level of adaptability is required of most software so that it can adapt to any changes that the customer may require. 6) Other attributes: - 27 -
  28. 28. CS 590l Workshop I Other attributes such as reliability and efficiency are also important and need to be considered. Reliability is to assure that the consumer gets a product that allows them to do what they expect to do, and to do it reliably for the stated period of time and for the stated conditions. Efficiency is the ability of a software system to fulfill its purpose with the best possible utilization of all necessary resources (time, storage, transmission channels, and peripherals). It also refers to the speed and compactness of the software. Analysis: The evaluation process used for the implementation review is as follows: 1. The code flow is hard-coded into a grammar. The grammar should have the normal predicate, subject and object like the ordinary programming language evaluations. This can be done using any of the standard schemes: - Predicate logic: This follows standard notations for programming flows. For example, “while” loop is given a pattern, which should be used for representations. - First-order logic: It is one form of representation. But, generally not used for coding. It is applied more to the field of knowledge representation. 2. Finding the representative states: This is the important phase for the whole evaluation process. We have to find the “critical elements or parts” of the program. Then, each should be represented by a state. If it involves some distributed type of programming, a number of multi-states have to be maintained within each state. After this phase, the remaining steps are more related to applying the ASM model to the process. 3. Getting the automata states: Most of the times, this step is automated and doesn’t require manual work. If the state table in fed to the ASM model, it returns the automata states. A lot of theory of computing based randomized algorithms (like ASK and RTM) has to be applied, if required to hand-code. 4. Running the steps in ASM: Applying the above input to the ASM gives the various respective results. It will check for modularity, robustness (recently) and then output normal quantitative normalization values. For this work, we have not practically applied to the ATM Model to the Equote. We have just listed the steps due to time constraints. But, this work will surely be undertaken in further reports. The E-quotes system lacks the security attribute. This system though it is real-time and Internet related does not consider the security feature. The code needs to have a provision for security. Also the database has to be secured using a password, so that an intruder is not able to access and change the database even though he is able to download the database somehow. The E-quotes software uses .Net as its middleware making it very portable and compatible with other Microsoft software. Also since .NET supports the use of any of the programming languages supported by Microsoft, adding an existing component to the system can be easily achieved. Also the system has a very easy to understand and easy to use interface and is also widely documented thus giving the software great usability. However, the existing system does not seem very reliable because it fails to provide security to the user. Also it isn’t very efficient because when the polling time is reduced the system faces network congestion and as a result the database also becomes inconsistent. - 28 -
  29. 29. CS 590l Workshop I Individual contribution of group members: Name of Member Contribution 1. Senthilkumar Ayyasamy Suitability of evaluation method, Analysis 2. Tulika Rathi Scenario, Data mining component requirements. 3. Seema Joshi Quality Attributes, Server-side requirements 4. Diksha Agarwal Introduction for evaluation method, Client Requirements 5. Manali Joshi Technology & Tools, Backend Requirements Conclusion: This report concludes the set of three reports presented as a part of Workshop I. Here, we have presented the final evaluation of the EQuotes system from the implementation perspective. Our implementation evaluation method was based on the concept of Abstract State Machines. Using this method the whole algorithm can be rewritten as a finite number of transition rules of very simple form. ASM takes various parts of the implementation as separate states and optimizes the coding phases. Based on our evaluation we are able to conclude that although the e-quote system was implemented along compatible lines still it lacks the most important issue of providing the security feature. Security is an important feature considering the Internet based real time behavior of the e-quote system. Although the system has a very user-friendly interface and is exhaustively documented, still it needs improvements in key areas such as security, providing personalized services such as user profiling and data mining, which have been listed in detail in our evaluation process. Implementation of our suggested enhancements would make the system highly reliable thereby increasing its overall functionality. References: [1] Runtime Verification of .NET (using Abstract State Machines) http://www.eecs.umich.edu/gasm/papers/verifnet.html [2] Runtime Verification of COM Components http://www.eecs.umich.edu/gasm/papers/verifcom.html [3] Synthesis from Requirements http://www.eecs.umich.edu/gasm/papers/synthasm.html [4] Behavioral Specification of Components http://www.eecs.umich.edu/gasm/papers/behavspec.html - 29 -