Objects with Attitudes

Identities and Aspects

Despite its object and unified vocations, the OMG’s UML (Unified Modeling Language) has been sitting uneasily between scopes (e.g requirements, analysis, and design), as well as between concepts (e.g objects, aspects, and domains).

Where to look  for AAA issues (Maurizio Cattelan)

Those misgivings probably go a long way to explain the limited, fragmented, and shallow footprint of UML despite its clear merits. Hence the benefits to be expected from a comprehensive and consistent approach of object-oriented modeling based upon two classic distinctions:

  • Business vs System: assuming that systems are designed to manage symbolic representations of business objects and processes, models should keep the distinction between business and system objects descriptions.
  • Identity vs behavior: while business objects and their system counterpart must be identified uniformly, that’s not the case for aspects of symbolic representations which can be specified independently.

That two-pronged approach bridges the gap between analysis and design models, bringing about a unified perspective for concepts (objects and aspects) as well as scope (business objects and system counterparts).

Object Oriented Modeling

Object Oriented and Relational approaches are arguably the two main advances of software engineering for the last 50 years. Yet, while the latter is supported by a fully defined theoretical model, the former still mostly stands on the programming languages supporting it. That is somewhat disappointing considering the aims of the Object Management Group (OMG),

UML was born out of the merge of three modeling methods: the Booch method, the Object-modeling technique (OMT) and Object-oriented software engineering (OOSE), all strongly marked by object orientation. Yet, from inception, the semantics of objects were not clearly defined, when not explicitly confused under the label “Object Oriented Analysis and Design” (OOA/D). In other words, the mapping of business contexts to system objects, a critical modeling step if there is any, has been swept under the carpet.

Literal Bird

That’s a lose/lose situation. Downstream, OO approaches, while widely accepted at design level, remain fragmented due to the absence of a consensus regarding object semantics outside programming languages. Upstream, requirements are left estranged from engineering processes, either forcing analysts to a leap of faith over an uncharted no man’s land, or to let business objects being chewed up by programming constructs.

Domains and Images

In mathematics, an image is the outcome of a function mapping its source domain to its target co-domain. Applied to object-oriented modeling, the problem is to translate business objects to their counterpart as system components. For that purpose one needs to:

  1. Define domains as sets of business objects and activities whose semantics and life-cycle are under the authority of a single organizational unit.
  2. Identify the objects and phenomena whose representation has to be managed, as well as the lifespan of those representations.
  3. Define the features (attributes or operations) to be associated to system objects.
  4. Define the software artifacts to be used to manage the representations and implement the features.
From Business Domain to System Image

While some of those objectives can be set on familiar grounds, the four must be reset into a new perspective.

Business Objects are rooted in Concerns

Physical or symbolic, objects and activities are set by concerns. Some may be local to enterprises, some defined by common business activities, and some set along a broader social perspective. The first step is therefore to identify the organizational units responsible for domains, objects identities and semantics:

  • Domains in charge of identities will govern objects life-cycle (create and delete operations) and identification mechanisms (fetch operations). That would target objects, agents, events and processes identified independently of systems.
  • Domains in charge of semantics will define objects features (read and update operations). That would target aspects and activities rooted (aka identified) through primary objects or processes.
Context anchors and associated roles and activities

It must be noted that whereas the former are defined as concrete sets of identified instances governed by unique domains, the latter may be defined independently of the objects supporting them, and therefore may be governed by overlapping concerns set by different domains.

Objects and Architectures

Not by chance, the distinction between identities and features has an architectural equivalent. Just like buildings, systems are made of supporting structures and subordinate constructs, the former intrinsic and permanent, the latter contingent and temporary. Common sense should therefore dictate a clear distinction between modeling levels, and put the focus on architectures:

  • Enterprise architecture deals with objectives, assets and organization associated with the continuity of corporate identity and business capabilities within a given regulatory and market environment. That is where domains, objects and activities are identified and defined.
  • Functional architecture deals with the continuity of systems functionalities as they support the continuity of business memory and operations. At this level the focus is not on business objects or activities but on functions supported by the system: communication, control, persistency, and processing.
  • Technical architecture deals with the feasibility, efficiency and economics of systems operations. That is where the software artifacts supporting the functions are designed .
Objects and Architectures

Objects provide the hinges binding architectural layers, and models should therefore ensure direct and transparent mapping between business objects, functional entities, and system components. That’s not the case for features whose specification and implementation can and should be managed separately.

Fleshing out Objects with Semantic Aspects

Confusing business contexts with their system counterparts leads to mistaken equivalence between features respectively supported by business objects and system artifacts:

  • The state of physical objects may be captured or modified through specific interfaces and persistently recorded by symbolic representations, possibly with associated operations.
  • Non physical (notional) business objects are identified and persistently recorded as such. Their state may also appear as transient objects associated with execution states and processing rules.
  • Events have no life-cycle and therefore don’t have to be identified on their own. Their value is obtained through interfaces; associated messages can be used by control or processing functions; values can be recorded persistently. Since the value of past events is not meant to be modified operations are irrelevant except for interfaces.
  • Actual processes are identified by execution context and timing. There state may be queried through interfaces and recorded, but persistent records cannot be directly modified.
  • Symbolic processes are identified by footprint independently of actual execution. Their execution may be called through interfaces and the results may be recorded, but persistent records cannot be directly modified.
  • External roles are identified by the interfaces supporting the interactions. Their activity may be recorded, but persistent records cannot be directly modified.
Fleshing out Aspects

By introducing complementary levels of indirection between business and system objects on one hand, identities and features on the other hand, the proposed approach significantly further object-oriented modeling from requirements analysis to system design. Moreover, this approach provides a robust and effective basis for the federation of business domains, by modeling separately identities and semantic features while bridging across conceptual, logical and physical information models.

Untangling Business Rules

However tangled and poorly formulated, rules provide the substance of requirements as they express the primary constraints, needs and purposes. That jumble can usually be reshaped differently depending on perspective (business or functional requirements),  timing constraints (synchronous or asynchronous) or architectural contexts; as a corollary, the way rules are expressed will have a significant impact on the functional architecture of the system under consideration. Hence, if transparency and traceability of functional and technical arbitrages are to be supported, the configuration of rules has to be rationalized from requirements inception. And that can be achieved if rules can be organized depending on their footprint: domains,  instances, or attitudes.

From Objects to Artifacts

Requirements analysis is about functional architecture and business semantics, design is about software artifacts used to build system components. The former starts with concrete descriptions and winds up with abstract ones, the latter takes over the abstractions and devise their concrete implementation.

Uphill to functionalities, downhill to implementations

Somewhat counter-intuitively, information processing is very concrete as it is governed by actual concerns set from biased standpoints. Hence, trying to abstract requirements of supporting systems up to some conceptual level is a one way ticket to misunderstandings because information flows are rooted in the “Here and Now” of business concerns. Abstract (aka conceptual) descriptions are the outcome of requirements analysis, introduced when system symbolic representations are consolidated across business domains and processes.

Starting with a concrete description of identified objects and processes, partitions are used to analyze the variants and select those bound to identities. Inheritance hierarchies can organized accordingly, for objects or aspects.

Inheritance of identities vs inheritance of aspects.

While based on well understood concepts, the distinction between identity and aspect inheritance provides a principled object-oriented bridge between requirements and models free of any assumption regarding programming language semantics for abstract classes or inheritance.

Objects, attitudes, and Programming Languages

Because object-oriented approaches often stem from programming languages, their use for analysis and design is hampered by some lack of consensus and a few irrelevant concepts. That is best illustrated by two constructs, abstract classes and interfaces.

  • Most programming languages define abstract classes as partial descriptions and, as a result, the impossibility to be instantiated. When applied to business objects the argument is turned around, with the consequence, no instance, taken as the definition.
  • Interfaces are also a common features of object-oriented languages, but not only, as they may be used to describe the behavior of any software component.

Those distinctions can be settled when set within a broader understanding of objects and aspects, the former associated with identified instances with bound structures, eventually implemented as concrete classes, the latter with functionalities, eventually implemented as abstract classes or interfaces.

From Analysis to Design

A pivotal benefit of distinguishing between objects identity and aspects is to open a bridge between analysis and design by unifying respective patterns along object-oriented perspective. Taking a cue from the Gang of Four, system functionalities could be organized along three basic pattern categories:

  • Creational functionalities deal with the life-cycle (create and delete operations) and identification mechanisms (fetch operations)  of business objects whose integrity and consistency has to be persistently maintained independently of activities using them.
  • Structural functionalities deal with the structure and semantics of transient objects whose integrity and consistency has to be maintained while in use by activities. They will govern features (read and update operations) and target aspects and activities rooted (aka identified) through primary objects or processes.
  • Behavioral functionalities deal with the ways objects are processed.

Mapping analysis patterns to design ones will greatly enhance models traceability; moreover, taking advantage of the relative maturity of design patterns, it may also boost quality across model layers as well as the whole effectiveness of model driven engineering solutions.

Objects Oriented Modeling and Model Driven Engineering

The double distinction between contexts and systems on one hand, objects and aspects on the other hand, should help to clarify the contents of modeling layers as defined by OMG’s model driven architecture (MDA):

  • Computation independent models (CIMs) are structured around business objects and processes identified on their own, associated with organizational details for roles and activities.
  • Platform independent models (PIMs) are organized on two levels, one for functional architectures (boundaries, processes, persistency, services, communication), the other one for associated aspects.
  • Platform specific models (PSMs) are similarly designed on two levels, one mapping functional architectures, the other one implementing aspects.
MDA with UML#

Using  UML#, object-oriented concepts can therefore be applied uniformly from requirements to design without forcing programming semantics into models.

Further Readings

14 thoughts on “Objects with Attitudes”

  1. I appreciate your statement that “OO approaches, while widely accepted at design level, remain fragmented due to the absence of a consensus regarding object semantics”.
    My conclusion has been that the first problem is that it is tried to put the semantics in the objects, whereas the semantics should be in the relationships between the objects.
    On basis of that conclusion we developed a formalized natural language that is based on a relations-oriented-approach. Without attributes.
    See my Semantic Modeling on

  2. Igor’s description “Project Manager created project team ….” is essentially a UseCase Description or UserStory.

    The generalized structure of UseCase Description / Description or UserStory enables known and also not yet discovered essence (abstraction) of the “activities, dialogs, goals etc”.

    These structures and patterns become clear as one works on a number of projects. They can be formalized through systematic REUSE of artifacts. Then the analyst needs to validate the REUSABILITY of artifacts by careful close study instead of force-fitting artifacts. If the artifacts of each kind fall into superclass–subclass structure the REUSE would become quick and efficient.

    I suppose that’s what Remy is saying.


  3. The only purpose of systems is to manage symbolic representations (aka surrogates), and that cannot be achieved without abstract constructs.

    1. manage symbolic representations (aka surrogates)
      I am not sure what sort of systems you develop, I have been fortunate to work with clients that have expertise in their domain. I learn that and that is the language I use. For example I have a Project Management system for a jewelry company in the works. It uses THEIR existing terminology to decompose products, and development phases of these components, and tasks related to that. I need no additional abstractions.
      Instead of use case I say: “Project Manager created project team by dragging and dropping user avatars onto tasks. The system will auto-prioritize the tasks to be last in person’s queue”
      They have queues, they have tasks, this is normal language to them. If new process is being developed, development of proper terms is key and is done at the same time with system development with much consultation from client’s experts and respect to culture.

  4. AA: I am with! Igor.

    A language should facilitate and enable, NOT challenge and inhibit. UML does more of the latter with 800+ pages of tyranny.

    I fully endorse Igor’s excellent example of patient and cardiologist—I too had been using a similar example of doctors, though not cardiologist exactly. It is amazing how software professionals blame the customer and GET AWAY WITH IT!


    I wish to bring up FACT MODELING by Ronald Ross it removes the intricate multiplicity assignment to classes (entities) in associations. I see that Igor prefers ER Diagrams to Class Diagrams but there is NOT much difference for any specific advantage.

    CC: UseCase Modeling

    UseCases are indeed excellent, through Igor does NOT seem to like them much. I have been experimenting with http://www.slideshare.net/putchavn/combined-use-case-description-mock-up-screens-and-system-sequence-diagram

    I provides the mock-up screens for the customer and other related stuff for the developers.


    1. Thats how I have seen UML used in the field most of the time. And the same BAs that are eager to write use cases with signature placeholders on the buttom are the 1st one to claim (Inexcusably) that “this (business) customer did not give us good requirements”. That claim is what I consider to be a sign of incompetence. You don’t have cardiologist claiming that “customer did not give me good requirements – the dude said it looks like I need a bypass… who am I to argue with the client, he is paying – so bypass he gets.” Software development is a domain of specialists, customers deserve not having to read nausea inducing use cases and not having to sign off on such gibberish.

      I did not find UML to be a useful abstraction, as I have not seen teams that are universally well versed in all of the UML goodness. I feel more comfortable showing database ERD to end user than use cases to demonstrate the current understanding.

  5. This kwetch is only related to design of interactive systems:
    Quote from the article:
    “Those misgivings probably go a long way to explain the limited, fragmented, and shallow footprint of UML despite its clear merits.” –

    The clearest merit of UML is confusing end customer, thereby allowing BAs to walk away with signed off UML, that business customer could barely comprehend.

    I have found that nothing describes essense of a system as a collection of user interface mockups together with “owner’s manual” style description of functionality written in familiar language.

  6. Architekk:

    I have already acknowledged good points Caminao’s blogs. I have made some observations based on my understanding of publications and my own use and analysis.

    If you have any references to elaborate on the points being discussed you are welcome provide them.

    I have some idea of UML and I do what I am capable of. In my own way I have gone beyond UML BPMN etc separately. I do not need any general advise from you. Please confine yourself to the points being discussed.

  7. Putcha,

    I understand your perception of “serious problems of modeling, OOAD, [and] UML”, especially as they relate to GST and Systems Thinking. It is not really the case. Behind Caminao’s blog is a rich (even mathematical) formalism that relates myriad domains and co-domains including software, hardware, business processes, requirements, systems engineering, even strategic, economic blueprints for the enterprise.

    I’ve used the UML for functional, object-oriented, aspect-oriented, subject oriented – even category-theoretic mathematical modeling of myriad kinds of systems, and myriad coupled scales. The UML is extensible. Try modeling things that challenge your mental constraints (by using modelling languages in ways they weren’t originally intended).

  8. Remy:

    You have identified some serious problems of modeling, OOAD, UML and so far disconnected phases of BA, RE, Architecture and Design. I appreciate your point that the conceptual framework of OOAD is too critically dependent on the programming languages and their shortcuts and compromises.

    I do not see any specific references to General System Theory and Systems Thinking. Don’t you think they would provide some sound theory and guiding principles?

    I hope you and like minded professionals will build a robust framework for OOAD and BAs REs and Software Developers will all converge to common reusable methods and tools.

    Your statements and arguments must be sound but are difficult to understand / agree or disagree with. Perhaps some example will help… that is a lot of work but it is worth it.

Leave a Reply

%d bloggers like this: