Fact-checked by Grok 2 weeks ago

Subject-oriented programming

Subject-oriented programming (SOP) is a modular approach to object-oriented programming that composes programs from units called subjects, each encapsulating a subjective, application-specific view of objects and their interactions, enabling flexible integration of multiple perspectives on shared domain elements without requiring a single, global object model. Developed by William Harrison and Harold Ossher at IBM, SOP was introduced in a 1993 paper presented at the Object-Oriented Programming, Systems, Languages & Applications (OOPSLA) conference, critiquing the limitations of "pure" object-oriented paradigms that emphasize intrinsic object properties over extrinsic, contextual views. Unlike traditional object-oriented programming, which localizes behavior within individual classes or hierarchies, SOP delocalizes objects across subjects to support multi-dimensional separation of concerns, allowing developers to evolve software by adding unanticipated extensions without modifying existing codebases. In SOP, a subject is a cohesive collection of classes, methods, and state variables that model a particular aspect or viewpoint of a problem , such as a tax assessor's on versus a maintenance engineer's view, spanning multiple object types rather than being confined to a single . in SOP involves rules for merging or nesting subjects—such as aligning methods with the same or resolving state conflicts—to form composite programs that integrate behaviors seamlessly, preserving encapsulation, polymorphism, and within each subject. This mechanism facilitates decentralized , where independent teams can create subjects that are later composed, addressing challenges in large-scale software evolution like those in integrated development environments. SOP has influenced subsequent paradigms, including , by providing foundational ideas for composing crosscutting concerns, and it relates to adaptive programming through shared goals in flexible composition, though SOP explicitly uses class fragments while adaptive methods employ traversal strategies for glue code. Early implementations explored tools like OOTIS for subject integration in environments, demonstrating SOP's potential for real-world applications such as combining editors, project managers, and schedulers.

Overview

Definition and Motivation

Subject-oriented programming (SOP) is a compositional that extends by emphasizing subjective viewpoints, where the state and behavior of objects are not intrinsic to the objects themselves but are instead provided by modular units called "subjects." These subjects encapsulate class fragments reflecting particular perspectives or concerns, allowing systems to be constructed through the composition of multiple such viewpoints into cohesive wholes. This subjectivity is illustrated by considering a as a shared object viewed from diverse angles: a might perceive it primarily as a for nesting, employing methods like make-nest that affect its branches; a assessor regards it as a factor in property valuation, using operations to compute its assessed worth based on and size; and a sees it as a to , invoking cut-down which alters its height and influences related schedules. In each case, the subject's methods and state fragments interact with the shared object identity without requiring a unified, predefined across all views. The motivation for SOP arises from the limitations of traditional (OOP) in handling concerns, where multiple interrelated perspectives—such as those in integrated application suites—lead to scattered and tangled code that hampers modularity, reusability, and evolution. In OOP, behaviors are fixed within class hierarchies, often forcing invasive modifications or duplication when accommodating new viewpoints; SOP counters this by enabling independent development of subjects that can be composed non-invasively, fostering better separation of subjective domains without compromising encapsulation. Unlike , where objects possess self-contained, intrinsic behaviors, SOP treats object functionality as emergent from the dynamic composition of subjects, providing a flexible model for multi-perspective systems. This approach briefly enables a multi-dimensional , with each subject representing an orthogonal dimension of functionality.

Historical Development

Subject-oriented programming originated at the in the early 1990s, where researchers William Harrison and Harold Ossher developed it as an extension to to address limitations in composing software from independent, subjective viewpoints. The paradigm was formally introduced in the seminal 1993 paper "Subject-Oriented Programming: A Critique of Pure Objects," presented at the conference, which critiqued the purity of object-oriented encapsulation and proposed subjects as modular units of related classes for flexible across multiple concerns. In the mid-1990s, early prototypes extended subject-oriented programming to existing languages, including a C++ implementation that supported decentralized development through subject composition rules and a Smalltalk system called Subjectalk, which enabled subjective views within object-oriented environments. By the late 1990s, the approach evolved to incorporate multi-dimensional , allowing concerns to intersect across multiple dimensions rather than in linear layers, as explored in on hyperslices and mechanisms. A key milestone came in with a from at the ECOOP workshop on , which highlighted subject-oriented techniques for operation-level and influenced the emerging field by demonstrating how subjects could handle concerns more flexibly than traditional . This work laid foundational ideas for , which emerged shortly after as a refinement focusing on aspects at join points, while subject-oriented programming emphasized broader subjective modularity. By the early , subject-oriented programming was widely recognized as a pioneering method for advanced , enabling decentralized reuse and integration in large-scale , as evidenced in workshops and tools like Hyper/J, which integrated multi-dimensional models for in 2001.

Core Concepts

Subjects and Class Fragments

In subject-oriented programming (SOP), a subject is defined as a collection of class fragments that encapsulate a complete, self-contained description of system entities from a specific subjective viewpoint or concern. This viewpoint represents a particular perception or "gestalt" of the domain, allowing developers to model aspects such as security, persistence, or domain-specific behaviors independently without requiring knowledge of other subjects' details beyond shared object identities. For instance, a subject might describe a "tree" entity solely in terms of its assessed value for taxation purposes, including relevant state like valuation metrics, while ignoring unrelated properties such as biological height or growth rate. Class fragments form the core components of subjects, providing partial definitions of es that include only the methods, variables, and behaviors pertinent to the subject's perspective. Unlike full definitions in traditional , these fragments are incomplete and modular, focusing on a subset of an 's interfaces and implementations to maintain within the subject. An example is a "billing" subject containing a fragment for a "" that defines processing methods and billing , such as history, without encompassing unrelated aspects like interactions. A single subject can include fragments for multiple interrelated es—such as , , and processors—to ensure the viewpoint remains internally consistent and reusable. Subjects and their class fragments play a central role in SOP by enabling reusability and composability, where multiple viewpoints can be layered onto base entities to form integrated systems without modifying existing code. This modularity supports decentralized development, as fragments from diverse subjects (e.g., one for adding access controls and another for persistence handling ) can be combined via composition rules to produce cohesive, multi-perspective programs. By treating subjects as schematic hierarchies of fragments, SOP facilitates the separation of cross-cutting concerns while preserving object-oriented principles like encapsulation and polymorphism within each subjective domain.

Composition Rules and Mechanisms

In subject-oriented programming (SOP), the composition process involves merging multiple subjects—each containing fragments—into complete, classes and programs through declarative composition rules that specify how fragments integrate across shared names. These rules ensure that the resulting composition forms a cohesive system by resolving how methods, state, and behaviors from different subjects combine, often at the level of individual operations or classes. For instance, the composition rule defines the precise manner in which subjects cooperate, such as by sequentially dispatching operations to activations in each subject or by nesting subjects to and propagation of calls. Key rule types in SOP include merge rules, which invoke methods from multiple subjects in sequence and require identical return values or raise exceptions on discrepancies, and override rules, which allow a later subject to supersede definitions from earlier ones for method overriding or state replacement. Inheritance rules extend this by propagating class hierarchies across subjects, while state merging rules combine instance variables, potentially using precedence to handle overlaps. These rules form a library of generic mechanisms, where higher-level rules can incorporate subrules for flexibility, such as plugging in specific behaviors for inheritance or merging. Activation mechanisms in SOP operate at operation-level join points, where method invocations from different subjects are coordinated during runtime or compile-time composition, enabling dynamic interaction without tight coupling. For example, nesting rules treat compositions as lexical scopes, allowing method calls to propagate only if explicitly permitted, thus controlling when fragments from one subject activate those in another. This supports modular activation, where rules dictate the order and conditions for invoking cross-subject behaviors, such as extending a base subject's methods with logging from an auxiliary subject. Conflict relies on explicit rules to manage overlaps, such as interface matching to align differing method signatures across subjects or precedence declarations to determine which fragment prevails in cases of method redefinition. If conflicts cannot be resolved—e.g., incompatible merges—the rules may signal an error, promoting by requiring developers to address ambiguities upfront. Techniques like operational further aid by inferring how unknown classes fit into the based on usage patterns.

Multi-dimensional Separation of Concerns

Multi-dimensional separation of concerns (MDSoC) in subject-oriented programming (SOP) extends traditional modularization techniques by enabling the independent encapsulation and composition of multiple, orthogonal concerns within a . In conventional approaches, such as single-dimensional separation via modules or classes, concerns are often tangled, scattering related code across the system and hindering independent evolution. SOP addresses this by modeling the system as a multi-dimensional , where dimensions represent distinct concern categories—such as functional requirements (e.g., ) versus non-functional aspects (e.g., or persistence)—allowing developers to modularize and manipulate concerns along multiple axes simultaneously. This framework, introduced as a of SOP principles, supports decentralized development by treating each concern dimension as a separable entity, reducing the complexity of integrating overlapping functionalities. The benefits of MDSoC in SOP include enhanced modularity, reusability, and maintainability, as it permits the independent evolution of concerns without pervasive code modifications. For instance, changes to a security concern can be isolated and propagated without affecting core functionality, minimizing tangling and improving system adaptability to evolving requirements. A concern graph, a visualization tool in this paradigm, depicts intersections between dimensions as nodes and edges, facilitating analysis of dependencies and potential conflicts during composition. This approach contrasts with one-dimensional methods by accommodating the inherent multi-faceted nature of software, where concerns like performance and usability intersect orthogonally, thereby lowering the risk of inadvertent side effects in large-scale systems. In SOP, MDSoC is implemented through subjects, which serve as "slices" or partial views of the multi-dimensional , encapsulating fragments relevant to specific concern intersections without scattering across unrelated modules. These subjects are composed using predefined rules to realize the full system, effectively weaving together orthogonal dimensions at runtime or compile-time to form complete, cohesive programs. This mechanism ensures that intersections—such as a functional slice combined with a overlay—are handled modularly, preserving the of individual concerns. For example, Hyper/J realizes this in by supporting subject for multi-dimensional concerns. The theoretical foundation of MDSoC in SOP builds on hyperspace models, where the entire software artifact is viewed as a encompassing all concern dimensions and their interrelations. Hyperslices represent projections or subsets of this , enabling partial, concern-specific views that can be independently developed and integrated. This model, evolving from early SOP concepts of subjective object views, provides a formal basis for scalable , emphasizing decentralized control over monolithic structures. By formalizing concerns as dimensions in a , SOP facilitates precise reasoning about system structure and evolution, underpinning tools and methodologies for advanced modularization.

Implementations and Tools

Hyper/J

Hyper/J is an experimental extension to the Java programming language, developed by researchers at IBM in the late 1990s to implement subject-oriented programming (SOP). It enables developers to modularize software along multiple dimensions of concern by defining subjects as collections of class fragments and specifying how these fragments are composed into complete programs. This approach addresses limitations in traditional object-oriented programming by allowing subjective views of objects to be expressed and integrated without invasive modifications to existing code. Key features of Hyper/J include support for subject declarations, which group related class fragments—partial definitions of classes containing fields, methods, or interfaces specific to a concern. These fragments can include partial method implementations that are merged during composition. Composition is managed through external files containing rules that dictate how elements from different subjects are combined, such as merging methods, resolving name conflicts, or propagating calls between fragments. The tool compiles these specifications into standard, executable , ensuring compatibility with conventional environments and virtual machines. Hyper/J also introduces hyperslices as the fundamental units for composition, enabling multi-dimensional where multiple overlapping views can be independently developed and integrated. A representative usage example involves creating a base subject that encapsulates the core of an application, such as classes for managing without any mechanisms. A separate "distribution" subject can then be defined with class fragments that extend these base classes to include remote method invocations, such as RMI stubs and proxies. Composition rules specify that methods in the distribution fragments override or wrap corresponding methods in the base subject, adding remote access transparently while preserving the original logic intact. This composition yields a complete application that supports distributed execution, demonstrating how Hyper/J facilitates incremental without refactoring the core . Hyper/J was released as a batch compiler via IBM's alphaWorks around , allowing downloads for experimental use. Although not actively maintained since its initial release, following the discontinuation of alphaWorks in , the source code is no longer publicly available. Descriptions and examples from the original release continue to support studies in advanced techniques.

Concern Manipulation Environment (CME)

The Concern Manipulation Environment (CME) is a environment developed in the early to support the creation and manipulation of multi-dimensional concern models in aspect-oriented (AOSD), extending beyond code to various software artifacts. It was designed as an open-source plugin framework to facilitate multi-dimensional (MDSOC), a core aspect of subject-oriented programming (SOP), by allowing developers to model, visualize, and compose concerns across the software lifecycle. Initially introduced through research at and collaborators, CME emerged from efforts to address limitations in traditional object-oriented tools by providing extensible components for concern-based organization. Key features of CME include the visualization of concern matrices as interactive graphs, which represent relationships between concerns and software elements in a multi-dimensional hyperspace. It supports hyperslice extraction, enabling the isolation of specific concern intersections from complex models, and automated generation of compositions based on predefined rules. These capabilities are artifact-agnostic, making CME applicable to UML diagrams, requirements specifications, and other non-code representations, thus promoting concern manipulation at higher levels of abstraction than code-centric tools like Hyper/J. The environment's ConMan component serves as a central concern manager, handling identification, encapsulation, and querying of concerns through a unified interface. In usage, CME enables the independent development of concerns along multiple dimensions, such as security and performance, followed by automated merging to produce integrated models or artifacts. For instance, developers can define separate concern slices for functional requirements and non-functional properties, then compose them via hyperspace operations to resolve interactions early in the design phase. This supports SOP's emphasis on subjective views by allowing modular evolution of concerns without global restructuring. CME has been available as on since 2006, with its last update in 2015, positioning it as an experimental tool that is no longer actively maintained. While influential in early AOSD research, its adoption remained limited due to the evolving ecosystem and focus on more specialized tools.

Relationships to Other Paradigms

(AOP)

(AOP) is a that enables the modularization of crosscutting concerns—such as , , or synchronization—by defining them separately from core functionality and automatically integrating them into the system. Introduced by and colleagues at the European Conference on Object-Oriented Programming (ECOOP) in 1997, AOP achieves this through key mechanisms: aspects, which encapsulate the crosscutting logic; pointcuts, which specify locations (join points) in the base code where the aspect applies, such as method calls or executions; and , which defines the actions to perform at those points, such as before, after, or around the join point. This weaving process, often performed by a or , allows non-functional requirements to be expressed and reused without scattering them throughout the primary code modules. Both subject-oriented programming (SOP) and AOP address the challenges of code scattering and tangling caused by crosscutting concerns, promoting better through modular decomposition and composition. SOP, introduced by William Harrison and Harold Ossher in 1993, similarly enables the expression of subjective views of a system by organizing code into subjects—collections of class fragments that represent partial implementations from specific perspectives—and composing them explicitly via rules. Like AOP, SOP facilitates reuse and maintenance by isolating concerns, but it emphasizes functional aspects (e.g., business rules) alongside non-functional ones, treating all subjects as equal, standalone modules without a central base code. Key differences lie in their approaches to and . SOP relies on explicit composition rules at the operation level, where join points are method operations, allowing developers to build subjective views through labeled fragments and external rules that do not modify , fostering decentralized development. In contrast, AOP weaves aspects dynamically or statically at finer-grained join points, such as individual statements or field accesses, centralizing non-functional concerns in aspects that intercept and modify base code behavior more invasively. This makes SOP more aligned with subjective, multi-view systems, while AOP excels at oblivious, quantified modifications across the codebase. SOP is regarded as a precursor to AOP, with its operation-level join points and focus on functional aspects influencing the evolution of AOP's mechanisms for handling crosscutting concerns. Historical overlap emerged in the late 1990s, as evidenced by discussions of SOP integrations in early AOP workshops, such as the ECOOP 1998 workshop on aspect-oriented programming, where position papers explored combining SOP's composition techniques with AOP's weaving for enhanced modularity. AOP forms a core component of the broader field of aspect-oriented software development (AOSD).

Aspect-Oriented Software Development (AOSD) and Adaptive Programming

Aspect-Oriented Software Development (AOSD) represents a in , formalized in the early 2000s, that extends traditional to handle crosscutting functionalities more effectively across the software lifecycle. Unlike conventional object-oriented approaches, AOSD encompasses a suite of techniques, including (AOP), (SOP), and advanced composition mechanisms, to modularize concerns that span multiple modules or components. This methodology, pioneered through collaborative efforts at institutions like PARC and , enables developers to identify, encapsulate, and compose such concerns systematically, thereby improving , reusability, and adaptability in evolving systems. Within AOSD, SOP serves as a foundational composition model by organizing code into subjects—modular units comprising class fragments that represent subjective views of a domain. This subject-based approach facilitates the integration of disparate perspectives through explicit composition rules, allowing for the creation of cohesive systems from independently developed parts. SOP's emphasis on multi-dimensional , realized via hyperspace models, aligns directly with AOSD's goals by supporting incremental modularization along multiple axes, such as functionality, role, or evolution stage, without rigid hierarchies. For instance, tools like exemplify how SOP enables the weaving of subjects to address concerns that cut across traditional boundaries in applications. Adaptive Programming (AP), emerging from the Demeter project at , extends SOP by introducing implicit join points and traversal strategies to manage context-dependent behaviors in object structures. AP allows programmers to specify operations that propagate along specified paths in class graphs, automatically generating necessary without enumerating every structural detail. This is implemented in environments like Demeter/ (DJ), a library that supports AP through propagation patterns, enabling flexible traversal from source objects to targets while adapting to varying object configurations. In contrast to SOP's explicit handling of all class fragments and composition rules, AP simplifies the process by prioritizing behavior propagation along object graphs, thereby reducing the need for detailed explicit specifications and focusing on essential traversals. This makes AP particularly suited for open systems where structures evolve, as it abstracts away for implicit connections, enhancing SOP's composition model with greater adaptability to runtime contexts. Multi-dimensional remains a shared , allowing AP to integrate seamlessly within AOSD frameworks.

Applications and Limitations

Practical Examples and Use Cases

One practical example of involves enhancing an object-oriented application with capabilities by composing a dedicated "database" . This contains fragments that extend existing classes with save and load methods, such as adding constructors for database updates and getters for retrievals, without modifying the original codebase. In a environment, for instance, a syntactic editor's modules can be composed with a to introduce persistent state for items like testable code, enabling storage and retrieval across sessions via merge rules. This approach leverages operation join points to integrate aspects seamlessly, ensuring that objects maintain state independently of the application's . Another example demonstrates SOP's utility in implementing distribution for client-server systems through a "remote" subject. This subject overrides local method invocations with network calls, using class fragments to handle remote access and synchronization; for instance, a shared tree object can be distributed across activations where separate subjects, such as a tax assessor and woodsman, track attributes like nest existence via coordinated updates. Composition rules, such as merging or nesting, resolve concurrent state changes in distributed environments, allowing the system to function as if local while transparently managing remote invocations. Tools like Hyper/J facilitate such compositions by supporting multi-dimensional separation of concerns in Java. SOP is particularly suited for addressing non-functional concerns in large-scale systems, such as with multiple viewpoints. Examples include error handling through aspects that join pre- and post-condition checks to methods, and tracing via operation-level policies that record entry and exit points across the application, and metrics-gathering for monitoring without scattering code throughout the base system. These concerns are modularized into subjects that compose via join points, promoting integration in distributed or evolving architectures like tool suites or business applications. In practice, SOP enables the incremental addition of features to existing systems without refactoring the base code, thereby improving and supporting decentralized by multiple teams. This reduces the risks associated with software evolution, allowing concerns like persistence or distribution to be developed, tested, and integrated independently before composition.

Challenges and Current Status

One of the primary challenges in subject-oriented programming (SOP) lies in the of independent , particularly when they feature divergent class hierarchies and lack unified global definitions for classes or operations. This can lead to complexities in ensuring seamless without invasive modifications, requiring careful definition of composition rules to resolve conflicts and maintain encapsulation. Additionally, achieving effective cooperation between subjects demands agreement on operation interfaces and strategies for class matching, which can be rigid and limit flexibility, especially for pre-existing or separately developed applications. Implementation challenges further complicate SOP adoption, as the paradigm relies on tool support for automated and , yet early tools like the Watson Subject Compiler provided only partial functionality, such as limited support for dynamic or . Without robust tooling, manual becomes labor-intensive, potentially reintroducing code tangling and hindering in large systems. Moreover, assumptions in the core model, such as a shared (OID) space, restrict with systems using disparate object representations, posing barriers in distributed or heterogeneous environments. As of the early 2000s, SOP saw initial experimentation through prototypes like Hyper/J, but it has experienced limited research and widespread adoption compared to related paradigms. Its ideas influenced (AOP), which addressed some SOP limitations by centralizing crosscutting concerns more modularly, leading to broader tool ecosystems and industry uptake. By 2014, SOP was viewed as less mature, with sparse ongoing development and no dominant implementations, though its emphasis on subjective views continues to inform multi-dimensional in modern . As of 2025, efforts remain niche, primarily in academic explorations of related concepts like hyperslices, context-oriented programming, and subject-based process models, without significant commercial traction.

References

  1. [1]
    [PDF] Subject-Oriented Programming (A Critique of Pure Objects) - iViz Lab
    This paper explores this shift to a style of object- oriented technology that emphasizes the subjective views: Subject-Oriented Programming. 1. Introduction.
  2. [2]
    Subject-oriented programming: a critique of pure objects
    Subject-oriented programming: a critique of pure objects. Authors: William Harrison. William Harrison. View Profile. Harold Ossher. Harold Ossher. View Profile.
  3. [3]
    Subject-Oriented Programming (SOP) and Adaptive Programming ...
    Subject-oriented Programming (SOP) is a program composition technology from IBM initiated by Harold Ossher and Bill Harrison. A subject is a collection of ...
  4. [4]
    Subject-oriented programming: a critique of pure objects
    Subject-oriented programming: a critique of pure objects. Authors: William Harrison.
  5. [5]
    Ossher - Subject-Oriented Programming Supporting Decentralized ...
    This document discusses subject-oriented programming, which allows decentralized development of objects. It addresses issues that arise when multiple ...
  6. [6]
    Hafedh Mili's Publications
    Hafedh Mili, William Harrison, and Harold Ossher, ``Supporting Subject-Oriented Programming in Smalltalk,'' in Proceedings of TOOLS'96, July 30 - August 2 ...
  7. [7]
    Hyper/J: multi-dimensional separation of concerns for Java
    W. Harrison and H. Ossher. Subject-oriented programming (a critique of pure objects). In Proceedings of the Conference on Object-Oriented Programming: Systems ...
  8. [8]
    [PDF] Advanced Separation of Concerns - https ://ris.utwen te.nl
    position filters, hyperspaces, role-modelling, subject-oriented programming and many ... them within the context of advanced separation of concerns. One ...
  9. [9]
    Subject-oriented composition rules | ACM SIGPLAN Notices
    This paper presents an approach to the composition rules used to specify composition details. Rules can be generic, allowing different subrules to be "plugged ...
  10. [10]
    N degrees of separation: multi-dimensional separation of concerns
    Subject-oriented programming (a critique of pure objects). In Proceedings of ... Hyper/J: multi-dimensional separation of concerns for Java. ICSE '00 ...
  11. [11]
    Hyper/J: multi-dimensional separation of concerns for Java
    Dec 3, 2000 · Hyper/J supports flexible, multi-dimensional separation of concerns for Java software. This demonstration will-show how to use Hyper/J in ...
  12. [12]
    Hyper/J(tm): Multi-Dimensional Separation of Concerns for Java(tm)
    Harrison and H. Ossher, “Subject-oriented programming (a critique of pure objects).” In Proceedings of the Conference on Object-Oriented Programming ...
  13. [13]
    Using subject-oriented programming to overcome common ...
    May 16, 1999 · Subject-oriented programming (SOP) is a practical approach to object-oriented (OO) programming-in-the-large.Missing: history | Show results with:history
  14. [14]
    Hyper/J™: Multi-Dimensional Separation of Concerns for Java™
    Hyper/J supports multi-dimensional separation of concerns for Java using the hyperspace approach. It permits the identification, encapsulation and integration ( ...
  15. [15]
    [PDF] IBM Research Report
    Jul 30, 2001 · ... .com/hyperspace. Hyper/J is available for download, free of charge, from IBM's alphaWorks web site: http://www.alphaworks.ibm.com/tech/hyperj.
  16. [16]
    https://ieeexplore.ieee.org/document/1553644
  17. [17]
    (PDF) The concern manipulation environment - ResearchGate
    The Concern Manipulation Environment (CME) aims to provide a set of open, extensible components and a set of tools that promote aspect-oriented software ...
  18. [18]
    Concern modeling in the concern manipulation environment
    The Concern Manipulation Environment (CME) is an AOSD environment in which software is organized and manipulated in terms of concerns.
  19. [19]
    Concern Manipulation Environment (CME) - SourceForge
    Apr 24, 2015 · The Concern Manipulation Environment (CME) is an integrated Aspect-Oriented Development (AOSD) environment that promotes incremental ...Missing: subject- | Show results with:subject-
  20. [20]
    [PDF] Aspect Oriented Programming - UBC Computer Science
    We present the basis for a new programming technique, called aspect- oriented programming, that makes it possible to clearly express programs involving such ...
  21. [21]
    Aspect and Subject Oriented Programming Paradigms - ResearchGate
    Jun 20, 2016 · Aspect and Subject Oriented Programming Paradigms: A Comparative Study. December 2014. Conference: The International Conference on Complex ...
  22. [22]
    https://www.semanticscholar.org/paper/Aspect-Oriented-Software-Development-Filman-Elrad/65bd10b14eec9f5ac7a55189a47d3ce2bf6a6f89
  23. [23]
    Aspect-Oriented Software Development - Semantic Scholar
    Oct 16, 2004 · This foundation reference is all you need to start applying aspect-oriented software development in real-world systems, and four leaders in ...Missing: seminal | Show results with:seminal
  24. [24]
    (PDF) Aspect-Oriented Software Development - ResearchGate
    Aug 7, 2025 · How Can AOSD Apply to Process on Three Levels? AOSD consists of techniques applied to artifacts. Or as processes applied to products.
  25. [25]
    Multi-Dimensional Separation of Concerns and The Hyperspace ...
    For example, ModelSoC [3] is introduced as an extension of the hyperspace model for multi-dimensional separation of concern defined by Ossher and Tarr [9] that ...
  26. [26]
    [PDF] Adaptive Object-Oriented Software. The Demeter Method, 1996
    ... adaptive programming in. C++ and tools for supporting the methodology. And because the methodology is program- ming-language independent, any programmer ...
  27. [27]
    Using subject-oriented programming to overcome common ...
    Harrison and H. Ossher. Subject-oriented programming (a critique of pure objects). In Proc. OOPSLA '93, pages 41 l-428, September 1993. Digital Library.<|control11|><|separator|>