APPROACHES IN BUILDING AND SUPPORTING BUSINESS INFORMATION SYSTEMS1 Asst. Prof. Nikola Valchanov P , Asst. Prof. Todorka Terzieva *, Assoc. Prof. Vladimir Shkurtov*, Assoc. Prof. Anton Iliev P *Plovdiv University g Paisii Hilendarskih , Faculty of mathematics and informatics, +359 889557573, +359 32 261742, +359 32 261771, +359 32 261759
[email protected],
[email protected],
[email protected],
[email protected] ** Bulgarian academy of sciences Institute of mathematics and informatics The purpose of contemporary business information systems is to support technically and technologically the management processes, to increase the precision and the validity of management decisions. This purpose defines the scope of the application software related to the introduction of information management systems in the business. Software giants like SAP, Oracle, Microsoft etc. offer reusable information management systems like ERP systems. By buying a product from them the customer company gets a secure partner and reliable support. The system is configured according to the structure of the company and the business processes in it. On the other hand the core of the successful integration of a business information system is the preliminary work on defining the most competitive business strategy, analysis and optimization of existing business processes, detailed definition of the requirements for the information system and the definition of future company goals. This is possible by building software, oriented to the specific needs of the company.
1
This paper is partially supported by projects ISM-4, RS09fFMIf041 and MUf3 of Department for Scientific Research, Plovdiv University "Paisii Hilendarski".
1
1. Architecture of a business information system In order for a business system to be extendable, following the dynamics of the organization that uses it, it should be carefully planned [2]. Most commonly the software systems use the three layer model as a foundation [5, 4]. Data access layer fthe transactional management of data and metadata. Standard industrial relational databases and queries are most commonly used for data storage. Business logic layer fbusiness validation rules, functions, logic and programs, implementation of work processes. User interface fgraphical user interface or browser for user interaction and access to system functionality. Every one of the three main layers must be designed in such a way that it communicates with the rest using the provided abstractions. This way every layer can be extended when new functionality is needed without affecting the work of the other layers. 1.1. Data access layer This layer manages the communication between the database and the business logic layer. This layer encapsulates all CRUD operations N ] PP ] P O [O P x OPW PP and transactions management [5]. The DBManager class is responsible for the communication with the database. It follows the creation W[ P] gTRW P h[1]. 7 MTPObTS SPg []a T OP] h[ P] [3], gTRW P hoffers a simple mechanism for changing the type of the underlying database.
SR1. Schema of the data access layer 2
This way we create an abstract layer that encapsulates the work with the data source. This centralization of the communication bTS SPO ] NP T RT T N W d T [W TT P SP d P i N OP. On the other hand the system becomes independent of the data source type. This is the place of a connectivity management mechanism. Since this class encapsulates the communication with the database, Ti WRT N WS T[]aT OP PaP N N] ] TRbSP the connectivity with the data source is lost. In this case the event informs the business classes of the condition of the connectivity with the data source and offers the possibility of reopening the connection. DBEntity is a base class that holds the common logic for manipulating the data source. DBEntity provides virtual methods where its successors implement the calls to the data source. It is possible to extract their execution and their wrapping in transactional blocks in this base class. This way we achieve centralization of the mechanism that manages the transactions in the system. One of the toughest decisions in the data access layer design is choosing the way of communication with the business classes. Some technologies depend on open connections. This is not the most reliable way of communication because the connectivity could not be always guaranteed. As an alternative of this approach the frameworks provide classes that model sets of data. These classes are data source independent. They contain mechanisms for tracking the state of every record. This way we achieve optimal control on the mechanism of extracting, manipulating and persistence of the data in the source. Of course this approach has its drawbacks. To simplify the support of the system we could build a centralized access to its queries. Combined with SP g []aT OP] h pattern this mechanism would allow dynamic access to queries specific for the underlying data source. These conveniences could be accomplished by foreseeing of a centralized mechanism for query management. Some systems need dynamically generated queries, based on a given business object. This problem finds its solution in the query management mechanism. The description of every query has the type of the parameters it receives. They could be standard parameters, substitutions or 3
functional object. ESPW [T S bPi W WN T OP]T ORM (Object-Relational Mapping) [4]. Instruments like the built-in ORM designer of Visual Studio 2008 can generate a set of classes, fully encapsulating the responsibilities of a data access layer. This approach hides the communication with the data source from the developers. On one hand this speeds up the development process. On the other we rid ourselves of the necessity of complex abstractions that capsulate the communication with the data source. This approach has its drawbacks. Using ORM the developers trust completely its mechanisms for data management. This way they lose control of the lowest level of communication with the data source. 1.2. Business logic layer EST WdP] []aT OP T P] NP S i W Pc T MW PP RS be used equally effective irrespectively of the end user [5]. Business objects of every system can be divided in four basic types: information business objects that only provide information, editable business objects that give access to their data, collections of editable business objects that model lists of editable business objects and Master-Detail business objects. The base classes provide virtual methods in which their successors implement validation rules and events that occur on validation errors. This way the whole validation of the business objects is implemented in the business logic layer. Encapsulating the validation processes, the business logic layer becomes independent of the user interface layer. These classes must provide mechanisms for exception handling in the system. This way the exceptions could be categorized and stored, sent to users or managed in a different manner. 1.3. User interface layer The consistent look of the graphical user interface allows the user to adapt faster to the layout of the controls and makes the work with the system intuitive. This can be achieved by building a hierarchy of visual components. Mainly it can include classes for visualization of data, for displaying messages and for interaction 4
with the user. This eliminates the possibility of style differences in the looks of the system. Because the whole validation framework of SP d P TT SPM TP WRT NWdP]bPO i PPO T [W PP specific validation mechanisms here. The well structured hierarchy in this case speeds up the development and minimizes the possibility of style inconformity in the system. On the other hand it allows the implementation and the reuse of mechanisms to be represented in all visual components of the system. This not only simplifies the complexity of form development, but enforces a common convention in building the graphical user interface of the whole system. 2. Conclusion An important quality of a business information system is how well its functionality corresponds to the business processes in the client corporation. The separation of the layers and shaping of the communication between the modules more or less defines the extendibility of a system and the complexity of its support. The initial planning of a information system is decisive for its future growth. The good design can make the system robust. It can guarantee easier support, simpler integration in different organizations and code reuse. ESP] Pi T aP] W[ P] ] building business information systems. The choice of approach is still a subject of debates. The problems discussed in this paper are common in business application development. The proposed solutions are platform independent and are applicable in the development of extendable and easy to support business information systems. References 1. kv n n pPz 9 j Design Patterns: lzu u x q ruy - xu x q x u w q tyq xw zw sq u o x 1o m u , 2004. 2. Krishnamurthy, N., A. Saran. Building software A PractitioneriR T OP 5 P] M NSB MW T N T , 2008. 3. Microsoft Corporation, Provider Model Design Pattern and Specification, . 4. Redler R., J. Rossberg. Pro Scalable .NET 2.0 Application 5
Designs, Apress, 2006. 5. Varallo, V. ASP.NET 3.5 Enterprise Application Development with Visual Studio 2008: Problem fDesign fSolution. Wiley Publishing, 2009. APPROACHES IN BUILDING AND SUPPORTING BUSINESS INFORMATION SYSTEMS Asst. Prof. Nikola Valchanov, Asst. Prof. Todorka Terzieva, Assoc. Prof. Vladimir Shkurtov, Assoc. Prof. Anton Iliev Abstract. The goal of this paper is to present different approaches in building enterprise business information systems by pointing out assets and drawbacks of these approaches. The paper presents some solutions of common problems related to the development of such systems. Key words: business information systems, development approaches, architecture of information systems, development problems.
6
