HTC

Object-Oriented Software Architecture Styles


In object-oriented styles, architectures are composed of objects that contain and manage their own internal data and provide well-defined interface services that allow other objects to use them. Object-oriented diagrams show collections of objects and the way each object makes use of the services provided by other objects. The left side of the figure below shows an example of a simple object-oriented diagram. There are a variety of object-oriented styles, and even some disagreement as to what can and cannot be called an object-oriented architecture.

The characteristic that is usually associated with an object-oriented style is that each data item is contained within and managed by an object. An object is an association of a particular set of data items with the operations that manipulate that data. An object's internal state can affect how it delivers services to other objects, but other objects cannot directly manipulate its internal data structures. The internal data of an object can only be altered indirectly by invoking one of the services associated with that object.

Another characteristic that is sometimes included in an object-oriented style is that objects are typed or classified. Each object in a diagram is viewed as an instance of some class of objects. The set of all classes in an architecture must be specified in addition to the objects and their relationships. Each object that is an instance of a particular class has its own internal data, but all the instances of a class provide the same set of services. Going back to the example of the figure, there might be multiple printer objects to manage multiple printers, where each of these maintains a different internal print queue but provides exactly the same set of services. Sometimes the classes themselves are organized into a hierarchy as shown on the right side of the figure, where a class "inherits" all the properties of all the classes above it in the hierarchy. The use of class hierarchies in an object-oriented style can sometimes enhance the amount of code reuse that occurs, since common services are easily reused among different objects.

One important variation between object-oriented styles is whether objects are considered to operate concurrently or whether an object is passive except when it is providing a service for another object. That is, can an object contain its own thread of control like a process, or does a thread of control pass from object to object during computation? If an object can have its own internal thread of control, then a number of alternatives exist for how objects interact with each other when a service is being performed (e.g. message passing, rendezvous). Picking an object-oriented style that allows some objects to have their own thread of control means selecting some set of these alternatives.

One analysis that can be performed in an object-oriented architecture is a determination of the type correctness of a diagram: is the set of services used by the objects in a diagram consistent with the set of services provided? Type checking can range from static and strong (type correctness is determinable at implementation-time) to dynamic and strong (type correctness is checked at run-time with the possibility of a run-time exception) to absent.

Many programming languages (e.g. SmallTalk, C++, Ada9X) include features intended to support an object-oriented style, including in some cases mechanisms to specify class or type hierarchies. However, coding guidelines can be developed that allow object-oriented architectures to be implemented in any language. Key object-oriented guidelines are the manner in which internal data structures are declared and maintained for individual objects, and the manner in which one object requests service from another. Other guidelines may cover such subjects as the mechanisms used to dynamically create objects, to name or point to an object, and to provide and control concurrency.

An object-oriented style was used to develop a reusable software architecture for graphical editors for the Domain Modeling Environment (DoME).

DSSA for GN&C Home Page