Publications
[ sd&m Home | ARCUS Home | What's New | Contact ]
Publications
|
|
OBJEKTspektrum 1996(4), pages 20-28 - German.
Many enterprises see the adaptation of Object technology as an opportunity for more reuse and easier application development. Especially large IS shops like e.g. banks or insurance companies will often replace existing applications instead of writing new ones. These existing applications will typically be monolithis transaction systems. A big bang replacement strategy is doomed to fail here in most cases. This article discusses Object Oriented Data Integration as one feasible migration strategy amongst others. Legacy applications and new built systems will work on the same database in parallel while more and more legacy systems are being replaced. The article discusses typical problem and solutions in the context of such a strategy.
Proceedings of the 1997 European Pattern Languages of Programming Conference, Irsee, Germany, Siemens Technical Report 120/SW1/FB, 1997
Despite all the benefits of object-oriented user interfaces, there are still domains that call for a form-based user interface. Business information systems that support fast processing of few, well-defined use cases are typical examples. This pattern language helps to develop the software architecture for such systems.
For newer versions and updates see Jens Coldewey's publication pages on UI construction
Full paper as Postcript: (Zipped PS [251k])
Proceedings: Pattern Languages of Program Design III, 1996.
Multilayer Class deals with the connection of adjacent layers in a layered architecture when using statically typed languages. Standard coupling techniques, such as simple calls, Envelope-Letter, or Observer, do well in most situations. However, when the two layers have closely coupled life cycles, the standard solutions may fail. Here, Multilayer Class offers a last resort.
Full paper as Postcript: (Zipped PS [111k])
[Remark, WK 2000]: Even though the paper has a certain age now, the pattern is still in wide use in various situations. A patterns that will not let you do new things but will make you understand why you do them :-)
Proceedings: Pattern Languages of Program Design III, 1996.
The Relational Database Access Layer Pattern Language provides a uniform mechanism for efficient database accesses and encapsulation of database system aspects. The pattern applies as a persistence mechanism for data abstraction modules.
For versions in other formats follow this link
Full paper as Postcript: (Zipped PS [374k])
('Ways Towards an Object Oriented Software Architecture') Proceedings: Annual conference, Gesellschaft für Informatik, Klagenfurt 1996 - German.
Many clients want to start implementing object technology in their practice to facilitate distributed architectures and reuse of components. The present environment found at these companies are often large, monolithic, and transaction oriented applications running on a mainframe computer.
The paper dicusses several strategies for a migration from monolithic IT structures to object oriented components. The different strategies can be combined to form a migration strategy that leads towards a pure object oriented software architecture. All options take into account that several generations of software technology will have to coexist for many years.
Full paper as Postcript: (Zipped PS [168k])
Also available as (pdf)
('Object Oriented Data Integration Covering Several Generations of Technology') Proceedings, ONLINE Conference, Hamburg 1996 - German.
Large IS organizations seldom ever use only one generation of database technology at a time. It is pretty common to find three or more generations of database technology in a single programming shop. While some pilot projects work with object technology, the mass of programmers still works with relational database technology and conventional third generation languages such as COBOL or PL/I. Often the main load of data processing is still managed by hierarchical IMS-DB databases. Object oriented projects need access to the vast data resources that are stored in database systems of other technology generations. Conventional projects need access to the newer data, produced by object oriented projects. This talk introduces a software architecture that integrates various generations of database technology and allows a soft migration from conventional to object oriented database technologies. The talk features an overview of the categories of possible standard software components that can be used to fill this architectural frame and tailor an individual solution for the data integration problem of a specific IS organization.
The application of the architecture is demonstrated by an example of an object oriented access layer for heterogeneous databases in a large financial institution. As host oriented environments (MVS, DB2, IMS) are seldom supported by standard integration products for object oriented data management, a custom solution for the data integration problem had to be developed.
The focus here lies on the integration of new and existing data resources and on the coexistence of Client/Server and host programming environments.
Full paper as Postcript: (Zipped PS [179k])
For other formats and an english version follow this link
('ENTSTAND Developping a Standard Architecture for Business Information Systems') Proceedings: Statusseminar des BMBF Softwaretechnologie, Berlin, 25.-26. März 1996 - German.
The paper is a summary of a presentation given at the above seminar. (It's here for historical reasons :-)
The project ENTSTAND (alias ARCUS) is mining patterns for the implementation of business information systems. The project is further researching improved description techniques for software architectures. This means especially looking for suitable abstractions for components and connectors. If patterns and description techniques are present, they can be combined to a pattern driven design process. Such a process will be examined as well.
in Frank Buschmann, Dirk Riehle (Eds.): Proceedings of the 1997 European Pattern Languages of Programming Conference, Irsee, Germany, Siemens Technical Report 120/SW1/FB, 1997
Mapping Objects to Tables is a problem that has occurred as long as people want to program in an object oriented language but have to use relational instead of object oriented databases for some reasons. Mapping Objects to Tables is only one family of problems that occurs in object/relational access layers.
Please see our later work on the topic
Full paper as Postcript: (Zipped PS [93k])
For other formats follow this link
Pattern Languages of Programming Conference (PLoP), Monticello, Illinois, USA, 1997
This paper presents several patterns for distributing business information systems that are structured according to a layered architecture. Each distribution pattern cuts the architecture into different client and server components. All the patterns presented give an answer to the same question: How do I distribute a business information system? However, the consequences of applying the patterns are very different with regards to the forces influencing distributed systems design.
Full paper as Postcript: (Zipped PS [282k])
For other formats follow this link
in Frank Buschmann, Dirk Riehle (Eds.): Proceedings of the 1997 European Pattern Languages of Programming Conference, Irsee, Germany, Siemens Technical Report 120/SW1/FB, 1997
Before we can handle an error or failure we have to detect it. Error Detection shows how to install error detectors within your software: it enriches the code with a number of run-time checks. Those checks are a prerequisite for handling software faults successfully and to avoid system crashes.
Full paper as Postcript: ( Zipped PS [145k])
('Object Oriented Database Access Using the VAA Database Manager') Written for the Association of German Insurances (GDV) - German.
VAA is a standard architecture for insurance applications developed by the Association of German Insurances (GDV). The architecture contains a database access layer that emulates a NF2 relational view on different database systems like IMS/DB or DB/2.
This paper discusses the architecture of an access layer that maps this relational view to an object oriented application. It lists the major problems one has to cope with and emphasizes the aspect of performance. Another topic is the connection to legacy databases without changing the database layout or other applications.
The paper contains a well proven architecture and discusses limitations of the approach. A list of vendors that offer related products is appended as well as a comprehensive bibliography.
Full paper as Postcript: (Zipped PS [352k])
Written for discussion in the CompuServe CASE forum
This paper describes problems that you will be confronted with, when trying to build an Object Oriented Data Access Layer for relational legacy data without any alterations of old tables the relational data reengineering problem. Mapping associations is one central topic that has to be handled for such an access layer.
We present our current solution, the solutions we have abandoned in our discussion and we invite others to join our discussion with the purpose to find an elegant solution for the handling of relational legacy data in OODBMS without breaking ODMG'93 user code patterns.
This paper does not discuss the overal architecture of an access layer it only discusses the special problems around relations.
Full paper as Postcript: (Zipped PS [68k])
Written for discussion in the CompuServe CASE forum
This paper describes problems that you will be confronted with, when trying to build an Object Oriented Data Access Layer for relational legacy data without any alterations of old tables the relational data reengineering problem. This results in very expensive solutions for OID (Object Identifier) handling.
We present our current solution, the solutions we have abandoned in a first discussion and we invite others to join our discussion with the purpose to find an elegant solution for the handling of relational legacy data in OODBMS without breaking ODMG'93 user code patterns.
This paper does not discuss the overal architecture of an access layer it only discusses the special problems around object identity.
Full paper as Postcript: (Zipped PS[38k])
 |
Copyright © 1996
sd&m GmbH & Co
KG, arcus@sdm.de J. Coldewey 9.04.96 |
Last
modified Fri Aug 7 14:27:13 1998 by Klaus Renzel |