Subject-oriented programming

Last updated

In computing, subject-oriented programming is an object-oriented software paradigm in which the state (fields) and behavior (methods) of objects are not seen as intrinsic to the objects themselves, but are provided by various subjective perceptions ("subjects") of the objects. The term and concepts were first published in September 1993 in a conference paper [1] which was later recognized as being one of the three most influential papers to be presented at the conference between 1986 and 1996. [2] As illustrated in that paper, an analogy is made with the contrast between the philosophical views of Plato and Kant with respect to the characteristics of "real" objects, but applied to software ones. For example, while we may all perceive a tree as having a measurable height, weight, leaf-mass, etc., from the point of view of a bird, a tree may also have measures of relative value for food or nesting purposes, or from the point of view of a tax-assessor, it may have a certain taxable value in a given year. Neither the bird's nor the tax-assessor's additional state information need be seen as intrinsic to the tree, but are added by the perceptions of the bird and tax-assessor, and from Kant's analysis, the same may be true even of characteristics we think of as intrinsic.

Contents

Subject-oriented programming advocates the organization of the classes that describe objects into "subjects", which may be composed to form larger subjects. At points of access to fields or methods, several subjects' contributions may be composed. These points were characterized as the join-points [3] of the subjects. For example, if a tree is cut down, the methods involved may need to join behavior in the bird and tax-assessor's subjects with that of the tree's own. It is therefore fundamentally a view of the compositional nature of software development, as opposed to the algorithmic (procedural) or representation-hiding (object) nature.

Relationships

Relationship to aspect-oriented programming

The introduction of aspect-oriented programming in 1997 [4] raised questions about its relationship to subject-oriented programming, and about the difference between subjects and aspects. These questions were unanswered for some time, but were addressed in the patent on Aspect-oriented programming filed in 1999 [5] in which two points emerge as characteristic differences from earlier art:

In the subject-oriented view, the cross-cut may be placed separately from the aspect (subject) and the behavior is not forced by the aspect, but governed by rules of composition. Hindsight [6] makes it also possible to distinguish aspect-oriented programming by its introduction and exploitation of the concept of a query-like pointcut to externally impose the join-points used by aspects in general ways.

In the presentation of subject-oriented programming, the join-points were deliberately restricted to field access and method call on the grounds that those were the points at which well-designed frameworks were designed to admit functional extension. The use of externally imposed pointcuts is an important linguistic capability, but remains one of the most controversial features of aspect-oriented programming. [7]

Relationship to aspect-oriented software development

By the turn of the millennium, it was clear that a number of research groups were pursuing different technologies that employed the composition or attachment of separately packaged state and function to form objects. [8] To distinguish the common field of interest from Aspect-Oriented Programming with its particular patent definitions and to emphasize that the compositional technology deals with more than just the coding phase of software development, these technologies were organized together under the term Aspect-Oriented Software Development, [9] and an organization and series on international conferences begun on the subject. Like aspect-oriented programming, subject-oriented programming, composition filters, feature-oriented programming and adaptive methods are considered to be aspect-oriented software development approaches.

Dimensions

Multi-dimensional separation of concerns, Hyper/J, and the Concern Manipulation Environment

The original formulation of subject-oriented programming deliberately envisioned it as a packaging technology – allowing the space of functions and data types to be extended in either dimension. The first implementations had been for C++, [10] and Smalltalk. [11] These implementations exploited the concepts of software labels and composition rules to describe the joining of subjects.

To address the concern that a better foundation should be provided for the analysis and composition of software not just in terms of its packaging but in terms of the various concerns these packages addressed, an explicit organization of the material was developed in terms of a multi-dimensional "matrix" in which concerns are related to the software units that implement them. This organization is called multi-dimensional separation of concerns, and the paper describing it [12] has been recognized as the most influential paper of the ICSE 1999 Conference. [13]

This new concept was implemented for composing Java software, using the name Hyper/J for the tool. [14]

Composition and the concept of subject can be applied to software artifacts that have no executable semantics, like requirement specifications or documentation. A research vehicle for Eclipse, called the Concern Manipulation Environment (CME), has been described [15] in which tools for query, analysis, modelling, [16] and composition are applied to artifacts in any language or representation, through the use of appropriate plug-in adapters to manipulate the representation.

A successor to the Hyper/J composition engine [17] was developed as part of CME which uses a general approach for the several elements of a composition engine:

Both Hyper/J and CME are available, from alphaWorks [18] or sourceforge, [19] respectively, but neither is actively supported.

Subject-oriented programming as a "third dimension"

Method dispatch in object oriented programming can be thought of as "two dimensional" in the sense that the code executed depends on both the method name and the object in question. This can be contrasted [20] with procedural programming, where a procedure name resolves directly, or one dimensionally, onto a subroutine, and also to subject oriented programming, where the sender or subject is also relevant to dispatch, constituting a third dimension.

See also

Related Research Articles

In computer programming and software design, code refactoring is the process of restructuring existing computer code—changing the factoring—without changing its external behavior. Refactoring is intended to improve the design, structure, and/or implementation of the software, while preserving its functionality. Potential advantages of refactoring may include improved code readability and reduced complexity; these can improve the source code's maintainability and create a simpler, cleaner, or more expressive internal architecture or object model to improve extensibility. Another potential goal for refactoring is improved performance; software engineers face an ongoing challenge to write programs that perform faster or use less memory.

<span class="mw-page-title-main">Design by contract</span> Approach for designing software

Design by contract (DbC), also known as contract programming, programming by contract and design-by-contract programming, is an approach for designing software.

<i>Design Patterns</i> 1994 software engineering book

Design Patterns: Elements of Reusable Object-Oriented Software (1994) is a software engineering book describing software design patterns. The book was written by Erich Gamma, Richard Helm, Ralph Johnson, and John Vlissides, with a foreword by Grady Booch. The book is divided into two parts, with the first two chapters exploring the capabilities and pitfalls of object-oriented programming, and the remaining chapters describing 23 classic software design patterns. The book includes examples in C++ and Smalltalk.

In computing, aspect-oriented programming (AOP) is a programming paradigm that aims to increase modularity by allowing the separation of cross-cutting concerns. It does so by adding behavior to existing code without modifying the code itself, instead separately specifying which code is modified via a "pointcut" specification, such as "log all function calls when the function's name begins with 'set'". This allows behaviors that are not central to the business logic to be added to a program without cluttering the code core to the functionality.

In software engineering, a software design pattern is a general, reusable solution to a commonly occurring problem within a given context in software design. It is not a finished design that can be transformed directly into source or machine code. Rather, it is a description or template for how to solve a problem that can be used in many different situations. Design patterns are formalized best practices that the programmer can use to solve common problems when designing an application or system.

The Law of Demeter (LoD) or principle of least knowledge is a design guideline for developing software, particularly object-oriented programs. In its general form, the LoD is a specific case of loose coupling. The guideline was proposed by Ian Holland at Northeastern University towards the end of 1987, and the following three recommendations serve as a succinct summary:

In computer science, separation of concerns is a design principle for separating a computer program into distinct sections. Each section addresses a separate concern, a set of information that affects the code of a computer program. A concern can be as general as "the details of the hardware for an application", or as specific as "the name of which class to instantiate". A program that embodies SoC well is called a modular program. Modularity, and hence separation of concerns, is achieved by encapsulating information inside a section of code that has a well-defined interface. Encapsulation is a means of information hiding. Layered designs in information systems are another embodiment of separation of concerns.

In aspect-oriented programming, a pointcut is a set of join points. Pointcut specifies where exactly to apply advice, which allows separation of concerns and helps in modularizing business logic. Pointcuts are often specified using class names or method names, in some cases using regular expressions that match class or method name. Different frameworks support different Pointcut expressions; AspectJ syntax is considered as de facto standard. Frameworks are available for various programming languages like Java, Perl, Ruby, and many more which support pointcut.

<span class="mw-page-title-main">Liskov substitution principle</span> Object-oriented programming principle

The Liskov substitution principle (LSP) is a particular definition of a subtyping relation, called strong behavioral subtyping, that was initially introduced by Barbara Liskov in a 1987 conference keynote address titled Data abstraction and hierarchy. It is based on the concept of "substitutability" – a principle in object-oriented programming stating that an object may be replaced by a sub-object without breaking the program. It is a semantic rather than merely syntactic relation, because it intends to guarantee semantic interoperability of types in a hierarchy, object types in particular. Barbara Liskov and Jeannette Wing described the principle succinctly in a 1994 paper as follows:

Subtype Requirement: Let be a property provable about objects of type T. Then should be true for objects of type S where S is a subtype of T.

In computer science, a metaobject is an object that manipulates, creates, describes, or implements objects. The object that the metaobject pertains to is called the base object. Some information that a metaobject might define includes the base object's type, interface, class, methods, attributes, parse tree, etc. Metaobjects are examples of the computer science concept of reflection, where a system has access to its own internal structure. Reflection enables a system to essentially rewrite itself on the fly, to alter its own implementation as it executes.

In aspect-oriented software development, cross-cutting concerns are aspects of a program that affect several modules, without the possibility of being encapsulated in any of them. These concerns often cannot be cleanly decomposed from the rest of the system in both the design and implementation, and can result in either scattering, tangling, or both.

In object-oriented programming, inheritance is the mechanism of basing an object or class upon another object or class, retaining similar implementation. Also defined as deriving new classes from existing ones such as super class or base class and then forming them into a hierarchy of classes. In most class-based object-oriented languages like C++, an object created through inheritance, a "child object", acquires all the properties and behaviors of the "parent object", with the exception of: constructors, destructors, overloaded operators and friend functions of the base class. Inheritance allows programmers to create classes that are built upon existing classes, to specify a new implementation while maintaining the same behaviors, to reuse code and to independently extend original software via public classes and interfaces. The relationships of objects or classes through inheritance give rise to a directed acyclic graph.

Executable UML is both a software development method and a highly abstract software language. It was described for the first time in 2002 in the book "Executable UML: A Foundation for Model-Driven Architecture". The language "combines a subset of the UML graphical notation with executable semantics and timing rules." The Executable UML method is the successor to the Shlaer–Mellor method.

Peri Tarr received her BS in Zoology from the University of Massachusetts Amherst in 1986, and her MS and PhD in Computer Science from the University of Massachusetts Amherst. Between her BS and MS/PhD, she worked full-time at the University of Massachusetts Physical Plant, attempting to introduce an automated system to help with the Plant's operations. After receiving her PhD, she joined the IBM Thomas J. Watson Research Center as a Research Staff Member in 1996, where she worked on and led various projects relating to issues of software composition, morphogenic software, and aspect-oriented software development.

Data, context, and interaction (DCI) is a paradigm used in computer software to program systems of communicating objects. Its goals are:

<span class="mw-page-title-main">Aspect weaver</span> Software programming utility

An aspect weaver is a metaprogramming utility for aspect-oriented languages designed to take instructions specified by aspects and generate the final implementation code. The weaver integrates aspects into the locations specified by the software as a pre-compilation step. By merging aspects and classes, the weaver generates a woven class.

<span class="mw-page-title-main">Object-oriented programming</span> Programming paradigm based on the concept of objects

Object-oriented programming (OOP) is a programming paradigm based on the concept of objects, which can contain data and code: data in the form of fields, and code in the form of procedures. In OOP, computer programs are designed by making them out of objects that interact with one another.

Object schizophrenia or self schizophrenia is a complication arising from delegation and related techniques in object-oriented programming, where self/this can refer to more than one object. By way of metaphor with the public confusion of dissociative identity disorder with the psychiatric diagnosis of schizophrenia, the former being associated with "split personalities," this configuration is called object schizophrenia or self schizophrenia in object-oriented programming.

The composition filters model denotes a modular extension to the conventional object model. It provides a solution for a wide range of problems in the construction of large and complex applications. Most notably, one implementation of composition filters provides an abstraction layer for message-passing systems.

References

  1. ↑ William Harrison and Harold Ossher, Subject-Oriented Programming - A Critique of Pure Objects, Proceedings of 1993 Conference on Object-Oriented Programming Systems, Languages, and Applications, September 1993
  2. ↑ "Most Influential OOPSLA Paper Award".
  3. ↑ Harold Ossher, Peri Tarr. Operation-Level Composition: A Case in (Join) Point, in ECOOP '98 Workshop Reader, 406–409
  4. ↑ Kiczales, G.; Lamping, J.; Mendhekar, A.; Maeda, C.; Lopes, C.; Loingtier, J. M.; Irwin, J. (1997). Aspect-oriented programming (PDF). ECOOP'97. Proceedings of the 11th European Conference on Object-Oriented Programming. LNCS. Vol. 1241. pp. 220–242. CiteSeerX   10.1.1.115.8660 . doi:10.1007/BFb0053381. ISBN   3-540-63089-9.
  5. ↑ Kiczales; Gregor J.; Lamping; John O.; Lopes; Cristina V.; Hugunin; James J.; Hilsdale; Erik A.; Boyapati; Chandrasekhar, Aspect Oriented Programming, United States Patent 6,467,086, October 15, 2002
  6. ↑ William Harrison. De-constructing and Re-constructing Aspect-Orientation, Seventh Annual Workshop on Foundations of Aspect Languages, Brussels, Belgium, 1 April 2008, edited by Gary T. Leavens, ACM Digital Library, 2008, pp. 43-50
  7. ↑ Friedrich Steimann. The paradoxical success of aspect-oriented programming, Proceedings of the 21st annual ACM SIGPLAN conference on Object-oriented programming systems, languages, and applications, Portland, Oregon, USA, 2006, pp. 481 - 497
  8. ↑ Communications of the ACM, Vol. 44, No. 10, October 1994, pp. 28-95
  9. ↑ http://aosd.net/
  10. ↑ Harold Ossher, Matthew Kaplan, William Harrison, Alexander Katz and Vincent Kruskal, Subject-Oriented Composition Rules, Proceedings of 1995 Conference on Object-Oriented Programming Systems, Languages, and Applications, October 1995
  11. ↑ Hafedh Mili, William Harrison, Harold Ossher, Supporting Subject-Oriented Programming in Smalltalk, Proceedings of TOOLS USA 96, August 1996
  12. ↑ Harold Ossher, Peri Tarr, William Harrison, Stanley Sutton, N Degrees of Separation: Multi-Dimensional Separation of Concerns, Proceedings of 1999 International Conference on Software Engineering, May 1999
  13. ↑ "SIGSOFT - ACM Special Interest Group on Software Engineering".
  14. ↑ Harold Ossher, Peri Tarr. Hyper/J: Multi-dimensional separation of concerns for Java, Proceedings of the 23rd International Conference on Software Engineering, Toronto, Ontario, Canada, 2001, Pages: 821 - 822
  15. ↑ William Chung, William Harrison, Vincent Kruskal, Harold Ossher, Stanley M. Sutton, Jr., Peri Tarr, Matthew Chapman, Andrew Clement, Helen Hawkins, Sian January. The concern manipulation environment, Proceedings of the 27th international conference on Software engineering table of contents, St. Louis, MO, USA, 2005
  16. ↑ William Harrison, Harold Ossher, Stanley Sutton, Peri Tarr. Concern modeling in the concern manipulation environment, Proceedings of the 2005 workshop on Modeling and analysis of concerns in software, St. Louis, Missouri, 2005
  17. ↑ William Harrison, Harold Ossher, Peri Tarr. General Composition of Software Artifacts, Proceedings of Software Composition Workshop 2006, March 2006, Springer-Verlag, LNCS 4089, pages 194-210
  18. ↑ "Legacy Communities - IBM Community".
  19. ↑ "Concern Manipulation Environment (CME)". 24 April 2015.
  20. ↑ Journal of Object Technology: Context Oriented Programming
This page is based on this Wikipedia article
Text is available under the CC BY-SA 4.0 license; additional terms may apply.
Images, videos and audio are available under their respective licenses.