Introduction
This paper describes the benefits and techniques for using an enterprise information architecture to develop and manage reusable software components.
Software component development is not a new technique or method. The first programs were often composed of reusable subroutines. When every line of code had to be keypunched onto an 80-column card,
it made sense to reuse the cards as much as possible. Many organizations would have cabinets full of card decks (“components”) that could be reused and shared by every programmer. Unfortunately,
when the ability to create and store programs and subroutines digitally on mass storage devices was introduced, programmers quit sharing their components. Today, new tools, programming languages,
and methods make it even easier to create software components.
Object-oriented programming (OOP) is the latest method for developing software components. OOP has its roots in the simulation languages of the late 1960s, and has recently developed in response to
a requirement for better tools to support the implementation of complex systems. The resulting programming languages (e.g. C++ and Smalltalk) permit or require the use of “objects”, with the goal
of producing complex applications which are more reliable, maintainable, and expandable than is possible or practicable with conventional programming techniques.
Object-oriented analysis and design methodologies have emerged to bridge the gap between business requirements and the physical implementation of a system. The techniques are focused upon the
design of logical models and physical designs that will be implemented using object-oriented programming tools. They use a range of mapping, diagramming, modeling and documentation conventions and
techniques.
The benefits of software component development are supposed to be reusability, modularity, reliability, flexibility, and scalability. Yet very few organizations have been successful in realizing
these benefits. While components could and should be reusable, they usually are not reused. And even if they are reused, they are not usually shared. This is because component development is easy,
but component management is hard.
Component and component development management require a rigorous and repeatable, unified method that allows organizations to realize full potential of component development while allowing
technological independence and tightly defined links between logical models, business requirements, and physical component designs.
It also requires automated tools that support the entire software component development life and provide the means to document and link the various elements of an Enterprise Information
Architecture with the enabling technology that allows data sharing, software component reuse, and rapid change management to be realized.
Business-driven Information Engineering
Information Engineering, as originally defined by Clive Finkelstein and James Martin in 1981, has evolved into two main variants:
- ‘DP-driven Information Engineering’, supported by James Martin, uses existing functions of an organization as a starting point; processes and data needed by the functions are then
defined, and the business knowledge is captured, often through interviews with users. - ‘Business-driven Information Engineering’, developed by Clive Finkelstein (and referred to as IE in this paper) captures strategic business requirements in terms of business statements
which define the organization’s mission, goals, strategies, objectives and policies, and links these to a logical, technology-independent model of the data and processes required to achieve those
statements. The resultant logical models then serve as a foundation from which physical systems can be designed and implemented.
Both business-driven IE and object-oriented analysis and design define business requirements using real-world terms. This narrows the gap between business experts and those who will implement and
maintain the systems by generating logical models that are both unambiguous to developers and understandable to business experts. The focus of the two sets of methodologies is different (but
complementary), as illustrated in the following table:
| Object-oriented analysis and design | Business-driven Information Engineering |
| Object-oriented analysis and design techniques develop and link logical models to a physical system implementation. |
The IE methodology provides a rigorous link between the logical data and process models and both the requirements of the business (as documented in a set of agreed business planning statements) and the physical system implementation. |
| An object-oriented implementation environment is assumed. |
No assumptions about the proposed implementation environment are made during data and process modeling. Implementation can take place in either an object-oriented or other environment. |
| An object-oriented design carries the benefits of modularity and encapsulation from the analysis stage through to the completed application. |
Data and process dependencies, which imply the boundaries of modules, are identified automatically and/or defined manually. Data access processes (DAPs) encapsulate the data upon which they act. |
|
The use of objects implies a data-first design. A recurring theme in the object-oriented texts is that the data and their inter-relationships are much less vulnerable to changing requirements than the operations performed on the data. |
Forward engineering (top-down) using business-driven IE is a data-first modeling methodology. Business changes bring about changes in procedures and processes more often than changes in the data upon which the business is based. A mature data model is a sound foundation from which to model changing business requirements.
IE also allows bottom-up modeling (for reverse engineering and systems migration and integration). The resulting data and process models can be implemented in |
Object-oriented analysis and design – Concepts and terminology
The fundamental concept of object-orientation is the “object,” which combines data structure and behavior in a single component. The inner workings of an object may be hidden. Only its visible
interfaces with the rest of the world need to be understood by any other processes (or objects) that interact with it. Objects with the same data structure and behavior are grouped into an object
“class;” libraries of class definitions are an important asset, and are the basis for the reusability resulting from the object-oriented approach. This is in contrast to “conventional”
programming, in which data structures and their behaviors are defined separately and are only loosely connected [Rumbaugh, 1991, p1].
There is an obvious mapping between the object classes of an object-oriented design and the entities in an IE data model. Business-driven IE uses the concept of “data access processes” (DAPs) to
define the basic processes which can act upon a specific entity (documented as Create, Read, Update and Delete DAPs for each entity). Higher-level business processes (which are initiated
in response to “business events”) are documented in terms of the various DAPs which are required to interact with the data model (e.g. Create EMPLOYEE). Using the IE methodology
the definition of an entity, accompanied by its available DAPs, forms an encapsulated unit which provides the functionality of the OO object class definition. The IE definition of an entity also
includes the linkages with the business planning statements.
[Booch, 1994] offers precise definitions of object-oriented analysis and design:
models of the systems under design.
To support object-oriented analysis, design and programming methodologies, a nomenclature has developed to describe the key concepts. The following table lists and describes these concepts, and
clarifies their relationship with the business-driven IE methodology:
| OO concept | Features of the object-oriented concept | IE’s relationship to OO concept |
|
Class or Object class: |
Objects with the same data structure and behavior (in the context of the particular application environment) are grouped into an object “class”. Classes can be grouped in a hierarchical structure. Classes may have attributes (see below). Example: An object class of PERSON. |
An entity in the data model with its associated Data Access Processes (DAPs). DAPs govern the behavior or operations on an entity.
The IE definition of an entity additionally includes the linkages to the business planning statements. |
| Object instance: |
A particular real-world occurrence of an object. Each instance of an object is assumed to be unique. OO assumes that all objects in an object class have a unique identity that separates and identifies them from all other object instances. Example: Robin Peel is an instance of the object class PERSON. |
An occurrence of an entity or group of related entities.
IE expressly identifies characteristics that identify one occurrence from another, in the form of a primary key. A system-generated primary key identifies entities |
| Attribute: |
A data value which can be held by the objects in a class. Attributes may be assigned to different data types (e.g. integer).
Example: An attribute of the class PERSON is last name (of type string). |
An attribute within an entity. Attributes are assigned a domain, which define the valid data types. Domains offer additional flexibility by defining length, range and a specific valid set of values for one or more attributes. |
| Association or Relationship: |
A conceptual relationship between instances of an object. Associations have cardinality including one-to-one, one-to-many, and many-to-many. Most object-oriented texts do not address the nature of an association (i.e. mandatory or optional), except in the definition of an object’s behavior. Example: The object CUSTOMER is associated with the object ORDER. This will probably have a cardinality of one-to-many. |
IE captures cardinality as degree.
IE additionally captures:
|
| Abstraction or Generalization: |
The essential characteristics of an object or class, ignoring irrelevant features, providing crisply defined conceptual boundaries. This maintains a focus upon identifying common characteristics among what may initially appear to be different objects. Abstraction enhances reusability and inheritance.
Example: Objects CUSTOMER and EMPLOYEE may initially appear to be quite different objects, but applying the concept of abstraction will |
The strategic, top-down analysis provides a high-level of abstraction as a starting point for modeling. Lower levels of abstraction are identified through tactical and operational modeling.
Abstraction is really a modeling technique used to identify commonality between things in the real world. The level of abstraction appropriate to a particular |
| Inheritance: |
The relationship between object classes, where one class shares the attributes and behavior of one or more other classes, based upon a hierarchical relationship. A discriminator attribute discriminates an instance of an object between the possible sub-classes.
Example: If two sub-classes of PERSON were defined as CUSTOMER and EMPLOYEE, both would inherit all the structure and behavior |
Secondary entities capture information that is unique to a particular type or category of the parent entity. Information that is common between a parent and all its secondary entities is retained within the parent and inherited by occurrences of the secondary entities. If a parent entity may simultaneously have more than one child entity, then this will be captured in a role entity. |
| Multiple inheritance: |
An object class may have more than one parent.
Example: The class CUSTOMER has been defined in our examples as a sub-class of PERSON, but it might also be a sub-class of SALES |
A parent can have more than one group of secondary entities, and can be of more than one type within each group (captured in a role entity).
Valid combinations of sub-types are documented in a rule entity. This allows the rules (and the behavior derived from them) to be changed by updating values |
| Typing: |
Quality control on the interchange of objects of different classes. Typing may be enforced to different degrees. Application environments may allow conversions between types.
Example: Although the classes CUSTOMER and EMPLOYEE share a common super-class (PERSON), they are different. It might be invalid to |
The object-oriented concept of type is essentially the same as the IE concept of a type entity or category discriminator.
If an entity may simultaneously be of more than one type, or may have a history of type changes, then this will be captured in a role entity. |
| Encapsulation or Information hiding: |
This hides the details of the implementation of an object. The result is that the interfaces of a class do not need to change if just the internal implementation of a class is changed. Encapsulation makes implementations more portable, reliable, stable and reusable.
Example: The derivation of an employee’s salary can be defined in many potential ways. A request to an object for an employee’s salary can ignore |
Data Access Processes (DAPs) represent processes that are encapsulated with the entity upon which they act. The inner workings of the DAPs are not visible at the business process level. The business process just provides a list of required information to a DAP. DAPs are the only processes which act directly upon entities within the data model. |
| Modularity: |
Physical packaging of the classes and objects in the logical design into cohesive and loosely coupled modules.
Example: The PERSON class, along with the sub-class EMPLOYEE, and other classes such as JOB and its sub-class MANAGER, might |
Data clusters are identified based upon data dependency, which can then be used to define the boundaries of implementation modules.
Data clusters can also be used to model the DAPs which invoke (re-use) each other to form process modules, which in turn may be re-used by other processes or |
| Polymorphism: |
Different object classes may behave differently in response to a common request or message. This enables instances of different object classes to respond appropriately to common operations upon them.
Example: An operation of Print for an object of class PICTURE will behave differently than the same Print operation for an object of |
A process may branch to one of several possible paths depending on the value of an individual attribute.
Additionally, processes have a defined set of completion states, which can be used to trigger a range of responses in their calling processes. |
| State transition: |
The state of an object instance is the status that the object instance is in. A state transition is the action of an object instance changing from one state to another. An event is some occurrence that may cause the state of a system to change [Booch, 1994].
Example: When an order is shipped to a customer, the state of the attribute order status within the object ORDER will change from “In |
The state of an entity is captured by a static entity related to that entity, or by a specific domain of values for a state attribute. Intersecting entities show the history of the state transitions for the entity.
Rule entities restrict the state value combinations to only those combinations that are pre-defined as valid. Any state transition would be triggered by |
| Concurrency: |
It may be necessary to execute a set of processes either consecutively or simultaneously. If simultaneous processes are taking place, then multiple objects will be active concurrently.
Synchronizing the activities of multiple active objects is difficult. Implementation environments to support truly concurrent applications are not widely
Example: The flight control system of an aircraft might include object classes such as ENGINE and RUDDER. To keep the aircraft flying |
Business-driven IE process maps show which activities must be executed in a specific sequence and which can be executed in parallel (if this is supported in the chosen environment).
If parallel processing is not supported, the parallel process steps imply that processing sequence is not important and can be optimized in the physical |
| Persistence: |
A measure of the lifetime and location of the occurrence of an object, including both an object’s state and its class. Encompasses both the role of variables in traditional application environments (such variables usually live just during the execution of a program or program module) and the domain of database technology (which enables information, such as the state and class of an object, to be retained between different executions of a program).
Object-oriented DBMSs are in their infancy. Most practical implementation environments coerce existing relational DBMSs toward the needs of object-oriented
Example: When an object of class CUSTOMER places an order (defined as an object of class ORDER), it will be necessary to keep a record of |
All data manipulated by processes must be a part of the data model. It is assumed that all elements of the data model will be stored and thus “persist”. |
| Operations or Methods: |
The direct manipulation of an object, categorized as:
Constructor: Create an object and/or initialize. Destructor: Free the state of an object and/or destroy the object. Modifier: Alter the state of the object. Selector: Access and read the state of an object. Iterator: Access all parts of an object in a well-defined order. |
The specific DAPs created for an entity:
Equivalent to Create DAP.
Equivalent to Update DAP. Equivalent to Read DAP. Equivalent to a Read DAP that returns more than one occurrence for group or iterative processing. |
| Reusability & Components: |
A result of abstraction, encapsulation and modularity is that:
Example: Once the class CUSTOMER has been defined for an order-entry and stock control system, it can be reused in the design of a marketing |
DAPs represent re-useable processes that pertain to a specific object.
Business processes can capture reusable subsets of logic that are invoked by multiple other processes.
Example: In the CUSTOMER example, the Add Customer process and CUSTOMER data structure(s) would be re-used in current and future |
Benefits of object-orientation
Object-orientation is perceived as providing many benefits which, at least at a conceptual level, are understood and seen as highly desirable by non-technical business experts. Some of these
benefits are:
- Reusability.
- Modularity.
- Avoidance of duplication.
- Reliability.
- Flexibility for expansion.
- Portability.
Information Engineering provides all of the above benefits when used to generate logical data and process models, but also provides two important additional benefits:
- Documented links between logical data and process models and both the business requirements and the physical design.
- Technology independence at the logical design stage, linked to an optimized technology-dependent physical design.
Implementing object-oriented methodologies
The use of either an OO or IE methodology requires a major commitment of time and resources to the analysis and design stages of a project. To organizations focused upon traditional systems
development techniques, this may appear as a high-risk approach. The benefits of a `pure’ OO approach will mainly accrue to the IS department within an organization (reusability, easier
maintenance and extensibility) and may be difficult to sell to non-technical managers (such as the end-users of a proposed system). The benefits of an IE approach to the analysis stage of an OO
project, which include formalizing the linkages between the business requirements and the final implemented systems, are more clearly visible and desirable to non-technical managers.
Reusability is one of the strongest selling points of object-orientation. It is perceived as one of the rewards resulting from the extra time devoted to analysis and design. Object libraries can be
built from objects designed during internal projects or purchased as `off-the shelf’ commercial products. But there are practical problems facing enterprises that establish and use such libraries:
- Reuse presents a cultural change in the way developers operate.
- Reuse enforces standards when new objects are created, which is likely to result in additional time and cost compared with generating a `once-off’ solution. The performance pressures placed
upon those responsible for systems implementation usually focuses upon the timely and cost-efficient delivery of new or additional functionality to users, rather than offering a practical incentive
to generate reusable objects. - At the same time, reuse can be perceived by project managers as a loss of control, if most development is done by pulling pieces out of a reuse library.
- Locating the right object classes or code components in the available libraries is not easy. Organizations may need to establish a new group just to manage reusable objects and enforce OO
standards. The operating cost of such a library is likely to be a vulnerable overhead to the IS department. - There is a danger that reusable code components can become too large and generic to be effective. A balance needs to be maintained to avoid code components becoming generalized to the point at
which their use becomes inefficient or ineffective.
Re-engineering legacy systems
To reverse engineer legacy systems, with a goal of systems integration in an object-oriented environment, is difficult using just OO techniques, since the OO analysis and design methodologies
require a means of defining object classes based upon `real world’ objects, rather than upon the old, possibly inappropriate data structures inherited from the legacy systems.
A combination of forward and reverse engineering using the business-driven IE methodology and appropriate tools can resolve most of these problems, by combining the reverse-engineered logical data
and process models of the legacy systems with an analysis of current business requirements. This enhanced analysis can form a solid basis for an object-oriented physical design.
Summary
Object-orientation and business-driven IE should be regarded as symbiotic:
- IE can provide the leverage to gain the benefits of an object-oriented approach to systems design and implementation. The logical data and process models resulting from an IE approach to a
business requirement are technology independent and reflect the business goals of an enterprise. They can be subsequently revised, amended and refined independent of the implementation environment
of any physical systems. If an object-oriented application environment is chosen, the IE data and process models provide a firm base from which an object-oriented design can be developed. - The concepts and terminology used to describe the features of object-oriented analysis and design are closely related to Business-driven IE.
The perceived benefits of an object-oriented approach are often quoted as being reusability, modularity, avoidance of duplication, reliability, and flexibility for expansion. IE also provides these
benefits, but extends them to include technological independence and tightly defined links between logical models, business requirements and physical implementation designs.
The functions and phases of Business-Driven Information Engineering and Object-Oriented Design are fully supported by the products available from Visible Systems Corporation (www.visible.com).
Bibliography – Sources and Further Reading
- Object-Oriented Analysis and Design with Applications, Grady Booch, 1994
- Object-Oriented Modeling and Design, Rumbaugh, Blaha, Premerlani, Eddy & Lorensen, 1991
- Object-Oriented Software Engineering, Jacobson, Christerson, Jonsson & Overgaard, 1992
- Object-Oriented Information Engineering, Stephen L. Montgomery, 1994
- Object-Oriented Analysis, Coad & Yourdon, 1991
- Object-Oriented Design, Coad & Yourdon, 1991
- Object-Oriented Analysis and Design, James Martin & James Odell, 1992
- Distributed Object-Oriented Data-Systems Design, Andleigh & Gretzinger, 1992
- Information Engineering: Strategic Systems Development, Clive Finkelstein, 1992
- The C++ Programming Language, Bjarne Stroustrup, 1991
Copyright © 1997, Visible Systems Corporation