AnyLog Stable Design Pattern Mohamed E. Fayad, Jayashree Rajagopalan, Anita Ranganath
Abstract— The AnyLog pattern models the core knowledge of any Log, as a written record. The Log finds extensive use in the computing industry. The pattern makes it easy to model different kinds of logs rather than thinking of the problem each time from scratch. This pattern can be utilized to model any kind of log in any application and it can be reused as part of a new model. Index Terms—Enduring business themes, Software stability, Software patterns, Stable analysis patterns, Stable design patterns. I. INTRODUCTION “Log” as a record, implies any significant information being stored in a media for future reference. Different applications for Log use different media and store entirely different kinds of information. The information in a log is stored as one or more entries. For example, a traveler’s log can be a diary, whereas a website traffic log can be a file on an electronic disk. The entries in a traveler’s log may be his daily expenses, places visited, etc., written in a free form (unformatted), whereas a website traffic log may contain formatted data like the client IP-address, time, date, etc. Since a Log finds use in diverse applications, it is important to understand the core knowledge behind the Log. The AnyLog design pattern aims at capturing such core knowledge that is common in all applications that use a Log. In the traditional way of modeling we created separate models of a Log for each application. That involves extensive time and effort to start the modeling process from scratch each time. On the other hand, the stable design pattern provides a good starting point. The Any Log pattern describes the characteristics, behavior, and lists all the key players and their relationships involved in any kind of Log application. This pattern can be easily extended or built upon to produce the model for any kind of Log application. A fundamental question is: Can we develop a pattern that captures the atomic log notion, and thus can serve as a base for modeling any kind of logs? The objective of this paper is to provide an answer to this question by discussing and Manuscript received June 29, 2003. Mohamed E. Fayad is with the Computer Engineering Department, College of Engineering, San José State University, One Washington Square, San José, CA 95192-0180 USA, (e-mail:
[email protected]). Jayashree Rajagopalan (e-mail:
[email protected]) & Anita Ranganath (e-mail:
[email protected] ) are students of the Computer Engineering Department, San Jose State University, San Jose
documenting the atomic pattern AnyLog. This pattern models the core knowledge of a Log, making it easy to reuse this pattern and build upon it to model different kinds of logs rather than re-working the same problem each time from scratch. AnyLog pattern is a stable design pattern [5,6 ,8] that is built based on the software stability concepts [9]. II. SOFTWARE STABILITY AND PATTERNS: A BRIEF BACK GROUND
STABLE
DESIGN
The pattern proposed in this paper is based on the concept of Stable design patterns introduced in [5,6,8]. The idea behind stable design patterns is to analyze the problem under consideration in terms of software stability concepts [9]. Software stability stratifies the classes of the system into three layers: the Enduring Business Themes (EBTs) layer (contains classes that present the enduring and basic knowledge of the underlying industry or business, and hence, they are extremely stable), the Business Objects (BOs) layer (contains classes that map the EBTs of the system into more concrete objects. BOs are tangible and externally stable, but they are internally adaptable), and the Industrial Objects (IOs) layer (contains classes that map the BOs of the system into physical objects.). Figure 1 depicts the three layers of the stability model. The detailed characteristics of EBTs, BOs, and IOs and useful heuristics and examples of identifying these concepts in real applications can be found in [7,8,10]. Unstable Leafs- IOs Layer
Concrete Objects- BOs Layer System Core Knowledge- EBTs Layer
Figure (1): Software Stability concepts layout Stable design patterns are created for semi-tangible objects that are always associated with some concept. The concept either forms their property or represents its relationship to another object. In generating a stable design pattern, we have to recognize the concept that always goes with the object irrespective of the application. The paper suggests a possible design pattern for any log. III. PATTERN DEVELOPMENT
PATTERN NAME: AnyLog The term ‘log’ implies maintaining a record of some kind. It could be record of performance or events. It could also be a record of the activity of a certain system stored for later reference. PROBLEM: Due to wide applicability of a log, we aim at designing the core concept of logging. The problem is to bring out a stable pattern for a log that is easily adaptable and easily extendable to any kind of log application. Main Problem: How to build a stable log pattern to which we can plug in any kind of logging application? CONTEXT: Log is a record that stores some information valuable to its creator. The log has applicability in various fields like information technology, travel, art, etc. For example, a file that contains the information on how many hits or impressions a web page is receiving is known as a traffic log Another example of a log is a record of a computer's or application's activity used for system information, backup, and recovery. Another use case of a log is that a ship’s captain stores events for a voyage in a trip log. FORCES: Challenges: • Log is a generic concept that caters to variety of applications that are totally unrelated, such as storing of a poem in a diary by a poet, or storing the number of website visits in a file by a website administrator. • One needs to recognize the core goal of having a log and it must be conveyed in the pattern. • As the applications of the log are so widely varied, the entries in the log can also be of many kinds. Also the entries can be ordered following a particular format or they could just be stored as is without a particular pattern of storage. The design pattern must have a representation for both formatted and unformatted entries. • The information to be stored in the log is entirely controlled by the creator. For example, a website administrator may want to log only the visits made to the website after 6 PM everyday. • The creator/maintainer of the log can be a person, group of persons, or an organization. Constraints: • The log pattern that is modeled is associated with EBT Recording and hence concentrates only on the aspect of storing or preserving the information valuable to the creator. However, one must understand that the use of the log can be different. • The model does not highlight this goal log as a tool for tracking or for other purposes. The model does not address the media on which log is created but it can be easily added, see figure 3. PATTERN STRUCTURE AND PARTICIPANTS:
The Figure 2 shows the solution without a media for the AnyLog design pattern. The model has one EBT named Recording and BO’s are AnyParty, AnyEntry, AnyLog, UnformattedEntry and FormattedEntry. Figure 3 shows Anylog design pattern with media. AnyParty name playRole( ) operate( ) request( ) party keeps recording Recording media record( ) specify( ) compare( ) examine( ) share( )
AnyLog
AnyEntry
entry enters 1..*
type name
name constraints
createEntry( ) 0..* enter( ) store( ) allocate( ) date_entry( )
create( ) refer( ) open( ) close( ) edit( )
FormattedEntry
UnformattedEntry
noOfFields layout( )
place( )
Figure (2): AnyLog Design Pattern Figure 3 below shows the AnyLog pattern with the AnyMedia pattern included. This pattern can be used when the media plays a very important role and hence needs to be illustrated.
AnyParty name playRole( ) operate( ) request( ) party
AnyMedia style rate type defineMediaProperties( ) identifyMedia( ) media mediaCapability( )
•
be maintained and stored in the log. whenever they appear. AnyMedia [8]: Identifies and defines the media on which the log is created. It also represents the media by which the log is to be displayed.
CONSEQUENCES: The AnyLog design pattern satisfies its objective and provides maintained in recording occurs in a core pattern that is adaptable to all kinds of log applications. AnyEntry AnyLog Benefits: Recording type record name Easily Understandable: The log pattern helps the reader to media name constraints easily understand the meaning of a log. The pattern is recording entry record( ) createEntry( ) create( ) associated with the EBT Recording and hence highlights the enters 1..* 0..* specify( ) enter( ) refer( ) compare( ) store( ) open( ) purpose of the Log. This makes the semantic of Log clearer. examine( ) allocate( ) close( ) Easily Adaptable: The stable design pattern for log is generic share( ) date_entry( ) edit( ) enough to fit to any kind of logging application. Stable over time: The pattern is not described using any industrial object; hence it is completely stable over time. Based on the context, the Industrial Objects can be plugged in the peripherals of the pattern to achieve a stable model for the FormattedEntry problem. UnformattedEntry noOfFields Scalable: Any application that uses this pattern can add its layout( ) place( ) context-based classes on top of this pattern. Hence the log pattern provides high level of extensibility to handle problems Figure (3): The AnyLog design pattern extended to show in various domains. Drawbacks: the media The AnyLog design pattern abstracts the core concept of a log. Also the AnyLog design pattern does not handle media on CLASSES: • Recording: This class indicates the purpose of using which the log is created. However, it can easily be extended to show the media as illustrated by Figure 3. a log. It is modeled as an EBT as it conveys the core goal of using any kind of log. IV. APPLICABILITY • UnformattedEntry: It is an abstraction, representative of all the entries in the log that do not Case Study 1: Error Log used by a system administrator have a format or basically any kind of unformatted You can monitor your server's activity using several data. An example of an unformatted entry would be different methods. One of the ways is to maintain log the numbers in a telephone diary not arranged files. Recording and viewing log files can provide a according to alphabetical order, whereas, if they we good reference to the server’s activity. This can be arranged in alphabetical order, they would be very useful to a system administrator who needs to formatted entries. monitor a server’s activity. Consider an example of • FormattedEntry: It is an abstraction for all entries an error log file. The error log file contains errors the that have a particular format. It is indicative of all the server has encountered since the log file was created; formatted data in the log. For example, if all the it also contains informational messages about the entries in a website administrator’s log may be server, such as when the server was started. arranged according to a particular date and time and Unsuccessful user authentication is also recorded in ordered according to their time of occurrence – these the error log. The error log can be used to find are formatted entries. broken URL paths or missing files. PATTERNS: • AnyLog: Represents the logging process itself. The class contains the behaviors and attributes that EBTs BOs IOs regulate the actual logging process. The AnyLog pattern is associated with an enduring business theme of Recording, where one’s purpose is to preserve the information. • AnyParty [8]: Represents the party that maintains the log. Party can be a customer, company, organization, etc. • AnyEntry [8]: Represents the information that has to keeps
part
