Object-Process Methodology

Imagine that an intelligent, friendly extra-terrestrial creature has just landed on planet Earth, without any prior knowledge of earthly physical and societal systems. Trying to figure out what his senses are telling him and how to construct a model of the surrounding reality, this creature is in a situation not unlike that of a human system developer, who is beginning to evolve a new system in an unfamiliar domain. Lacking sufficient knowledge about the domain that hosts the system and its environment, the analyst must start with an arbitrary collection of facts. The collected observations are not overly refined nor are they extremely abstract. The knowledge and understanding of the system is gradually improved through activities such as observing the current state of affairs and practices, inquiring, interviewing professionals in the field, and reading relevant documents.

In Chapter 1, we were exposed to basic OPM principles and features. In this chapter, OPM’s visual capabilities are presented. Diagrams are intuitive and therefore widely used. As Cook (1999) noted, “with diagrams the meaning is obvious, because once you understand how the basic elements of the diagrams fit together, the meaning literally stares you in the face.” This is one of the premises OPM is built upon. Diagrams contain symbols for objects, processes and states that are interconnected with several types of links with precise semantics. These diagrams are naturally called Object-Process Diagrams (OPDs). Using an ATM system as a case in point, this chapter presents an overview of OPDs, their properties and the main symbols they use. An ATM is appropriate as an introductory case study, since it is a familiar system. Familiarity with the domain and the system being investigated assists the acquaintance with OPM, as the reader can draw on prior knowledge.

In Chapter 2, we started developing the ATM system, and were exposed to OPDs, the graphic facet of OPM. Spoken or written language is the modality of OPM that is complementary to the graphics. Winograd and Flores (1987) noted: “Nothing exists except through language. In saying that some “thing” exists (or that it has some property) we have brought it into a domain of articulated objects and qualities that exist in language.” Indeed, language greatly enhances our ability to understand systems and communicate our understanding to others. In this chapter, we introduce the Object-Process Language (OPL) and show the equivalence between graphic specification through OPDs and natural language specification through OPL sentences and paragraphs. We will add the language element to the set of OPDs we started developing in Chapter 2. We will then proceed with the ATM case study, adding more detailed OPDs and their corresponding OPL paragraphs.

Immanuel Kant said, “objects are our way of knowing.” While this is the truth, it is not the whole truth. Objects are our way of knowing the structure of systems. To understand systems’ behavior, processes are required. We know of the existence of an object if we can name it and refer to its unconditional, relatively stable existence, but without processes we cannot tell how this object changes over time.

System dynamics deals with system changes over time. The dynamic aspect of a system is the complement to the static. It specifies how the system operates to attain its function. Time is an essential concept in analyzing the dynamic aspect of systems. An important motivation in the development of OPM has been to strike a needed balance in systems modeling between the structural and procedural aspects of a system. OPM is designed to incorporate structure and behavior in one coherent frame of reference. This chapter addresses the issue of system dynamics; in other words, the system’s behavior and the changes it undergoes over time.

Structure pertains to the relatively fixed, non-transient, long-term relationships that exist among components or parts of the system. Alternatively, structure can be viewed as a snapshot — an account of the system, or part of it, at some point in time. The snapshot captures the system at some state, at which specific relationships between objects hold. Structure is contrasted with the complementary dynamic aspect of the system, or its behavior, discussed in Chapter 5, which has to do with the changes the system undergoes over time, along with the causes for and effects of these changes. In other words, structure is about the static aspect of the system, while behavior is about its dynamic aspect. This chapter is devoted to discussing the structure of systems and expressing it through OPM.

Any interesting system can be decomposed into parts. The system and its parts can be described using natural language modifiers: adjectives and adverbs. Without the ability to mentally take things apart and examine their features, our ability to study systems would be greatly hindered. Consider, for example, a table. Without describing it, we cannot determine its function: is it for dining, studying, or displaying artifacts? We cannot tell what material it is made of: is it plastic, metal, or wood? What are its dimensions? Is the tabletop round, square or perhaps some other shape? How many legs does the table have, and how long is each?

While discussing Aggregation and Exhibition, we talked about entire groups of objects or processes — any scientific paper, any employee, any running. However, what if we wanted to consider the example of a specific paper, written by a certain John Doe? Or if we wanted to consider a group of employees, namely managers, who receive a certain salary out of the range of salaries available for the company? Perhaps we would like to discuss running in a marathon, as opposed to just any kind of running? We need to be able to pay particular attention to a specialized group, which belongs to a more general group, or even a specific instance out of a class of objects. As its name clearly points out, Generalization-Specialization is the relation between a general and a specialized case of a thing. Classification-Instantiation links between a class of things and a unique instance from the class. Since these two of the four fundamental relations are important to systems modeling, we consider them in more detail now; and since they are intimately related, they are explained together in this chapter.

Complexity is inherent in real-life systems. An integral part of a system development methodology must therefore be a set of tools for controlling and managing this complexity. Like most classical engineering problems, complexity management entails a tradeoff that must be balanced between two conflicting require- ments: completeness and clarity. On one hand, completeness requires that the system details be stipulated to the fullest extent possible. On the other hand, the need for clarity imposes an upper limit on the level of complexity of each individual diagram and does not allow for a diagram that is too cluttered or loaded. OO development methods, notably the UML standard (Object Management Group, 2000), address the problem of managing systems complexity by dividing the development of a different model for each one of the important aspects of the system — structure, dynamics, state transitions, etc.

Each one of us is a system. We live within systems and are surrounded by them. Systems exist in nature as well as in virtually any conceivable area of human activity. Systems are the focus of research and development in any field of human endeavor. In Chapter 4 we have elaborated on objects and processes as the fundamental building blocks of the universe. In the chapters that followed, we have learned how these building blocks can be combined in a variety of ways to model ever more complex things, which are still objects and processes. Having studied structure and dynamics, we are now ready to discuss systems.

A complete methodology is not just an ontology and a set of notations. It prescribes a system whose function is supporting the lifecycle and evolution of an artificial system. There is confusion regarding the various terms that pertain to this issue. Most methods refer to the development of software systems, called the “Software Process”, where there is a consensus that development entails analysis, design and implementation. OPM considers development as just one (albeit a central one) of three processes, the other two being initiating and deploying. This chapter introduces the architecture — the combination of structure and behavior through interacting objects — that comprises the objects and the processes that affect them, to attain the entire system function. We do this by way of presenting a set of OPDs and discussing their content using OPL. Since the architecture is aimed to be as general as possible, this chapter may seem abstract in first reading. The description of the System Lifecycle and Evolution system is probably initially quite vague. However, as we move forward and drill down to increase the level of detail of the system specification, the specification of the system’s architecture gets less fuzzy and more concrete. This chapter discusses system lifecycle and applies OPM to describe the lifecycle and evolution of artificial systems.

Along with objects and processes, states are an important entity in OPM. If objects and processes are the building blocks of OPM, and links are the mortar, states can be considered as the finish of the house: the paint job, the furniture, the architectural elements. States make the use of OPM a lot smoother and more expressive. They allow an object to change while retaining its identity; they provide for a wide range of interactions between objects and processes; their context sensitivity significantly enriches OPM’s articulation power. We have been using states since the first chapter of this book. We have seen that values are generalizations of states. This chapter focuses on value and states’ relations to other entities in OPM, as well as introducing a few more uses for states.

In this chapter we present new advanced OPM concepts and elaborate on material presented in earlier chapters. These issues include real-time, metamodeling, scope, and structural relations.

Systems theory encompasses the observations made over the past two and a half millennia about common features that characterize systems, regardless of their domain. As defined by Heylighen (2001), systems theory is the trans-disciplinary study of the abstract organization of phenomena, independent of their substance, type, or spatial or temporal scale of existence. It investigates both the principles common to all complex entities, and the (usually mathematical) models, which can be used to describe them. More specifically, it is related to the recently developing “sciences of complexity,” including artificial intelligence, neural networks, dynamical systems, chaos, and complex adaptive systems. Building on the foundation of systems laid out in Chapters 10 and 11, this chapter discusses various system theories and their relationships with OPM. We begin with an introduction of the informatics hierarchy and General Systems Theory. We discuss the term beneficiary in the context of system, environment, and interface. Control and feedback are modeled in OPM terms. Classical physics and the quantum theory are discussed with an eye toward their effects on OPM. We define and demonstrate objectifying: converting a process occurrence to an object record. The informatics hierarchy is then defined and ontology are finally related to OPM.