İstemci sunucu mimarisi, nesneye dayalı programlama ve tahsilat takip otomasyonu

Abstract

Bu tez çalışmasının amacı, uygulama programcılarının kendileri için en uygun yazılım geliştirme ortamlarını kurmak ve etkin ve kolay program geliştirmeleri için gerekli olan alt yapının ne olması gerektiği konusunda bilgilendirmektir. Çalışmada temel olarak son yıllarda programlama teknolojisinin geçirdiği evreler sonucunda ortaya çıkan istemci/sunucu ortamlar ve nesneye dayalı teknolojiler ele alınmıştır. Tezin savunduğu fikirleri doğrulamak için örnek bir projenin iki farklı ortamda iki ayrı versiyonu hazırlanmış ve karşılaştırılmıştır. Çalışmanın genel yapısı dört ana bölümü içermektedir: istemci/sunucu ortamlar, nesneye dayalı programlama, OWL sınıf kütüphanesi ve Tahsilat Takip Sistemi projesi. Birinci ve beşinci bölümler arasında programlama kavramlarına girmeden istemci/sunucu ortamlarla ilgili temel bilgiler, veritabanı sunucuları, iyi bir istemci/sunucu ortam oluşturmak için dikkat edilmesi gereken noktalar ve bu ortamlarda uygulama tasarımı anlatılmıştır. Altıncı ve onikinci bölümler arasında nesneye dayalı programlama kavramları ve C++ programlama dili örneklerle aktarılmıştır. Nesneye dayalı programlamaya (NDP) giriş, NDP parçaları, nesneye dayalı analiz gibi konular C++ dili çerçevesinde sunulmuştur. Onüçüncü kısımda projenin geliştirilmesinde kullanılan grafik kullanıcı arabirimi (GKA) hakkında bilgiler verilmiştir. Bu GKA, Borland firması tarafından geliştirilen ve Borland C++ derleyicileri ile birlikte dağıtılan OWL (Object Windows Library) sınıf kütüphanesidir. Ondördüncü ve son bölümde ise istemci/sunucu ortamların özellikleri, C++ programlama dili ve OWL sınıf kütüphanesi kullanılarak hazırlanmış olan 'Tahsilat Takip Sistemi (Tl S)' projesi anlatılmıştır. TTS projesinin yapısal programlama teknikleri kullanarak hazırlanmış diğer bir versiyonu ile karşılaştırmalar yaparak NDP ile yapısal programlama teknikleri arasındaki farklılıkların aktarılması sağlanmıştır.

The data processing industry has changed dramatically in the last 1 5 years. Before that time services were supplied exclusively by mainframe-based technologies. With the introduction of the PC in the early 1980s, the potential offload of mainframe services were started to experience, but the alternative environment was used commonly: the personal computer. In the last five years the PC has evolved into a workplace platform. These new powerful workstations, joined together by a network with even more powerful servers capable of mainframe processing, make up the base platform for client/server solutions. Client/server architecture differs extensively from mainframe architecture because the application is divided between the client and the server. The client typically is responsible for the application presentation, editing, and some processing, whereas the server provides data management, shared resource facilities (for example printing, file organizing), and the remainings. The server is connected to the client via a network. Any single user request can be processed on the client alone or split between the client and the server (s). The right client/server platform for one organization can be significantly different for another organization. Additionally, client/server solutions may not be most cost-effective solution in all cases. Most industry analysts agree that client/server-based application solutions are the best among alternativies because there are many significant benefits once the client/server development platform is in place and developers have experience with the platform: Object Oriented Design, Analysis, and Programming techniques are one of the important tools at the computer industry in recent years. In addition to downsizing of hardware prices and progressing of hardware technologies, end user requirements and programs that are written for these requirements have dramatically increased. In 90s, programs process more data, are used easily and when hardware is changed programs do not need to rewrite. Therefore code size in programs are increased. This situation has brought new problems: Maintaince. In order to solve these problems traditional methods should have been changed and new methodologies should have created. At this point a new technology has been used: Object Oriented Programming (OOP). XIV OOP is a technique that provides building blocks which can be combined to implement complex applications and that insulate system modules from implementation changes made to other modules. Each OOP building block is a simulation of a real-word object. For example, in a insurance application, a policy or a customer may be an object. In another case, an object-oriented electronic Computer Aided Design (CAD) system might model a circuit as a set of Component objects, each containing a collection of Pin objects that connect through Net objects to the Pins of other Components. When a Component applies a signal on an output Pin, the Pin sends a message to its Net, which applies the signal to all other connecting Pins. Although the decomposition of an application into entities and relationships meaningful to the end user is a common analysis technique, OOP preserves this decomposition through the design and implementation phases. In other words, at the program design stage, there is no need to represent the Policy object in some process model like a data flow diagram or a mathematical logic formula. This preservation makes the software tangible even to non-implementers who have application knowledge. And, because objects come into existence because of their natural presence in the real world, they can be often reused in similar application. For many programmers, "reuse" means taking code from an existing application and editing it until it becomes a different application. Such editing results not in reuse, but in proliferation. Every copy is different. The ability to reuse software without modification, as in OOP, is critical to building and maintaining large applications. OOP is built on a few fundamental concepts: the ideas of objects, encapsulation, and inheritance. An object is something that can be acted upon. In addition to this, an object has state, behavior, and identity. Because it is always an instance of some class, the terms object and instance are interchangeable. Objects are a natural way for humans to think about real-word applications. An OOP application is designed and thought of as a collection of objects and procedures (methods) that operate on those objects. In OOP, an object contains private data, procedures, or both. An object-oriented language, like C++ or Smalltalk, directly supports this view of programming by formaliang the notion of an object and making it the natural unit of modularity. Each object belongs to a class. An object's characteristics are represented by a set of values stored in what are called instance variables in programming language. These variables make up the object's private memory. An object's memory is called private because it cannot accidentally be destroyed by errant pointers or procedures. An object can be changed and observed only by sending it a message, which objects of the same class are able to receive. The way an objects reacts to messages is called the object's behavior. True OOP languages have a rich class hierarchy for the programmer to choose from and from which to create new classes of objects as the application requires. In Smalltalk or C++, for instance, Integer is a subclass of class Number. Objects typically reside in memory, but they can be made to persist by writing them to disk. The term persistent objects is sometimes used to describe objects written to disk and managed by object-oriented databases. xv It is much easier to maintain and extend an OOP application than a conventional application because of the way objects are organized and because of their unique properties. A high-quality system design is still mandatory. In a pure OOP language, however, major design changes are possible late in the implementation with minimal impact. In traditional programming systems, data and the programs that manipulate the data are separate entities. The programmer is responsible for applying active procedures to passive data structures - and frequently for ensuring that the procedure works correctly on the data types to which it is applied. In an OOP system, on the other hand, an objects consists of both the data and the procedures that apply to that data. Only an object's procedures have access to its private data. The process of bundling the object and the procedures that apply to it is called encapsulation. Encapsulation provides security and reliability unayailable outside of OOP and is a major benefit of OOP. OOP extends the concept of encapsulation by bundling data and procedures into logical units that are dealt with as a whole. In traditional systems, the functions that apply to a policy record, for example, are implemented separately and are often spread through several different programs. Furthermore each updating procedure needs to know the exact field sizes and positions (representation) of the policy record. In a true object-oriented system, every policy record is itself an Policy object. Figure 1 illustrates the encapsulation of a policy object. Method GetPolicy Message Answer Method InsertPolicy Method CheckPolicy Data Policy Number: 12345678 Policy Owner CAM, Yilmaz Total Sum Insured: $1 10,000.0 Basic Rate: 0.000770 Total Premium: $84.70 Encapsulation Boundary Figure 1. Encapsulation of an object Because encapsulation lets every object hide its data and procedures, the implementation of an object or its procedures can change without requiring a change in any associated object. To access this hidden data or to invoke some behavior, users of the object need only send a message to the object. A message, in OOP parlance, is analogous to a program call in a standard High Level Language like RPG, COBOL or C. The difference is that the message specifies the action and the object on which it is to be performed. The object definition specifies which procedure is to be invoked for a particular message xvi type. For example, both a Line object and a Circle object can have a procedure named Draw. Sending the message Draw to a Line invokes its Draw procedure; sending the same message to a Circle invokes its Draw procedure. Thus, appropriate behavior for the Draw operation can be always taken. It is quite common in object-oriented systems to code multiple classes of objects that respond to the same messages, as in the Line and Circle example. The ability of different objects to respond differently to the same message is known as polymorphism. As the previous example shows, polymorphism is superior to using CASE statements or nested Ifs to test for all different known object types in a single global procedure. Polymorphism is partly responsible for a well-known characteristic of object-oriented systems: a style of programming that is sometimes referred to as "differential programming" or "programming by modification". It is easy to plug new objects into a system if the new objects respond to the same messages as existing objects. For instance, a rectangle object that has a Draw procedure can be easily added to a system that previously had only Lines and Circles. This ability to add features and functions to existing systems is yet another OOP benefit. Another principle of object-oriented languages that supports differential programming is inheritance, or the ability to define a new object that is just like an old one except for a few minor differences. For instance, in a insurance application, a FirePolicy object can be defined that is just like an existing Policy object except for a few additional or different responses to messages. FirePolicy inherits all of Policy's private data and procedures. Inheritance can be extended into multiple generators of objects (e.g., a new DoctorPolicy object can inherit the private data and procedures of AccidentPolicy object). Figure 2 shows inheritance mechanism of OOP. Policy rz FirePolicy AccidentPoiicy j I MarinePolicy AutomobilePolicy | DoctorPolicy I Figure 2. Inheritance mechanism Inheritance implements a kind of or subclass relationship. The attributes and procedures of each superclass are inherited by its subclasses. Thus, FirePolicy inherits both private data and procedures of its superclass, Policy. An object's data and methods are not stored together, though, so we don't have the redundancy that inheritance may at first seem to imply. Conceptually, an object-oriented program consists of a two-dimensional table indexed by class and procedure. Given the class and procedure, the table locates xvn the actual program to be executed. The object-oriented language takes care of maintaining the table for the applications programmer. Together, inheritance and encapsulation lead to a different style of programming. OOP encourages reuse rather than reinvention. It encourages prototyping and code polishing. And it rewards the development of generic classes that can be reused in different applications. There are many key benefits possible with a properly implemented OOP environment. These benefits fall mainly into two categories: management benefits and programming benefits. On the management side:. OOP's object encapsulation and reusability make rapid prototyping possible, resulting, in quickly developed applications that provide what the end users want.. Programming productivity improves 30 to 60 percent over conventional system development-more when application-specific class libraries are in place.. Programmers are motivated by the modern programming environment, the GUI common to OOP languages, and the highly integrated development aids.. Life cycle maintenance costs are significantly reduced.. Product function can be extended easily without debugging marathons and costly regression testing typical of large procedural applications.. Maintenance programmers can browse and maintain applications very easily using the powerful browsers, revision control tools, and application management tools available in pure OOP languages.. Encapsulation and automatic memory management result in exceptionally reliable applications.. Programmers are rewarded by the amount of code they reuse, not by how many lines of new code they write. On the programming side:. The highly integrated, flexible environment means that programmers can try out code immediately, without long compiles and link cycles, and can quickly get tangible results and the associated emotional rewards.. The graphical, multiwindowing environment common to OOP has a "fun factor" that allows longer periods of productive work before the mental brick wall is encountered.. Powerful symbolic debuggers with "hop", "skip", and "jump" capabilities, coupled with break points, source code edit, and trace buffers, reduce strain on programmers.. Automatic memory management means programmers never have to worry about memory allocation/deallocation or deal with memory allocation bugs.. OOP's "real-world" design model and implementation mean that program maintenance is not the traumatic experience that it is with other traditional languages.. There is a natural tendency to fine-tune and polish reusable class libraries. xviii The beginning chapters of the thesis give an instruction to OOP with a number of examples in order to make the concepts and definitions clearer. In addition, a specific application program was developed in two different environment to compare traditional programming concepts and the OOP. They are coded in both C and C++ languages. The name of the application is Insurance Premium Tracking System and it is aimed for the use of the agencies of an insurance company to track premiums collected from customers. This application is aimed to give an example of object-oriented programming in a client/server environment.