�ݺ�ߣ

Editor's Notes

• #3: Web applications characterised by: large, evolving, and heterogenous populations of users heavy dependence on the interactions with the users User requirements: evolving needs, attitudes, navigation profiles, preferences
• #4: User’s behaviours cannot be fully anticipated at design time. Only released applications allow us to collect statistics Users may have multiple and heterogeneous navigational behaviours that depend on several factors Behaviours may unpredictably change over time thus invalidating the analysis efforts Several classes of users with distinct user behaviours coexist at the same time
• #5: Monitoring the usage of the system and subsequently mining possible interaction patterns Little support from a general software engineering perspective Limited flexibility (e.g., Google Analytics) Ad-hoc techniques: link-prediction (Sarukkai et al., 2000) data caching (Yang et al., 2003)
• #6: General abstraction to support software engineers in maintaining and adapting user-intensive Web applications Automated and non-ambigous analysis tool Support for different user classes Other key features: extensibility (domain specific analysis) incrementality applicable to legacy systems
• #8: Partition user population into significant classes. Give semantics to the interaction events (URLs) occurring in the log file Use the events to infer semantically rich user-behaviour models (DTMC) Support queries on behaviour models
• #9: Declaratively give semantics to the URLs occurring in the log file Declaratively characterise the population of users by identifying a set of relevant features to cluster them into distinct classes. Incrementally infer a set of discrete time Markov chains (DTMCs) Annotating the states of the models to represent domain specific quantities Specifying the properties of the interaction patterns (PCTL). Analysing the models
• #10: RESTful web application: findyourhouse.com Real estate announcements (sales, rentals) we had full access to both the application and the log file we conducted our experiments on the data collected during the normal operation of the application.
• #11: BEAR associates semantics et of atomic propositions (AP) that indicate what can be assumed as valid when a certain entry in the log file is found. Declarative approach: annotation @BearFilter
• #12: The first filter associates the proposition homepage to the homepage URL. The second filter associates the proposition sales anncs to the URLs that matches the regular expression in its an- notation, and indicates that the URLs are related to sales announcements. The third filter associates the propositions login success and login fail to URLs that correspond to lo- gin attempts, depending on the HTTP status code of the request. The fourth filter associates the propositions con- trol panel to the pages of the control panel.
• #14: BEAR infers a set of DTMCs that represent the users’ behaviours. The inference process works sequentially and incrementally on the log file as a data stream. The inference engine generates an independent DTMC for each user class defined by the classifiers.
• #17: Rewards: domain specific metrics of interests. An example: To give special recognition to the states that display a large number of announcements. This can be easily achieved by annotating the propositions with rewards that depend on the number of announcements they are related with. They assign rewards to propositions in the setup phase, and do not need to know the structure and the number of the inferred models, which are inferred only later while monitoring the application behaviour.
• #18: PCTL is probabilistic branching-time temporal logic based on the classic CTL logic that predicates on a state of a Markov process. The PCTL properties depend only on the propositions, and designers can specify them without knowing the structure of the inferred models in terms of states or transitions.
• #20: where Pi(uk) corresponds to the probability for a user (associated to the selected user classes) that exited state si to belong to the specific user class uk.
• #21: The BEAR analysis engine indicated that 48% of users are interested in sales announcements only, and 20% users are interested in renting announcements only. ge of users look both for sales and renting announce- ments. With these data, the designers decided to change the homepage that initially displayed a random set of an- nouncements, and now displays renting and sales announce- ment proportionally to the measured users’ behaviors.
• #22: We generated synthetic log files composed of 10, 000 lines generated ad-hoc to produce DTMCs with an increasing number of states. Figure 4(a) shows that the BEAR inference engine can produce a DTMC of 150 states analyzing a log files of 10, 000 lines in few sec- onds. Figure 4(b) illustrates instead the execution time of processing log files of increasing length. The figure reports the execution time for log files that produce a DTMC of 50 states. BEAR processes a log file of 100, 000 lines in around 60 seconds. inference engine.