Differing Units of Interest

As with any large, complex problem, breaking the problem into smaller parts makes it easier to understand. Software engineering is no different in this respect, with the word modularization often used to capture this notion. We get modularized units when we wrap parts of the problem space together. To this end, we are interested in how a particular problem is divided into smaller parts. In this section, we show how requirements specifications and object-oriented specifications use different modularization units, making it difficult to match up one with the other.

Describing Requirements

A requirements specification is a description of an expected software system. It is generally the output of a requirements-gathering process that is likely to have considered a number of dimensions: The needs and requirements of the potential end users of the software system are elicited and documented; the business processes the software system must support are examined and the supporting requirements are documented; the technical environment and technical constraints within which the software system must run are assessed and documented; all existing software systems with which the new software system must interact are identified, and the requirements for their interaction are documented. Requirements specifications tend to be documented in a language that can be understood by eventual users of the system, which is generally a natural language.

Individuals and groups of individuals (for example, clubs or businesses) have different needs for software systems from both a business and personal perspective. The vocabularies and processes used to describe these needs are wide and varied, with numerous approaches to requirements gathering and documentation. Here, we look at two things: first, the differences in vocabularies used by various approaches to describe individual requirement units (e.g., features, functions, services), and second, some different approaches to dividing a requirements specification into smaller parts. Influences on this division relate to the different views or perspectives of the people who need the software.

Requirements Units

There are many words used to describe what a computer system is supposed to do: requirement, feature, functionality, facility and service are a subset that we look at here. In order to give a context for the vocabulary, dictionary^[1] definitions for each of these terms are shown in Table 2-1, followed by a description of how the concepts are used in some requirements-engineering approaches.

^[1] The Concise Oxford Dictionary. Clarendon Press, Oxford.

Table 2-1. Requirements Units

Term	Dictionary Definition
Requirement	Need; depend on for success, fulfillment, etc.
Feature	Distinctive or characteristic part of a thing; part that arrests attention; important participant in.
Function	Mode of action or activity by which a thing fulfills its purpose.
Service	Provision of what is necessary for the maintenance of a thing or property.
Facility	Equipment or physical means for doing something.

Different requirements-engineering processes use different vocabularies to describe units of interest to the requirements gatherer. For example, the Unified Software Development Process^[2] refers to requirements, features, and functionality, but in essence describes the process of capturing requirements as use cases. A use case delimits the system from its environment; outlines who and what will interact with the system and what functionality is expected from the system; and captures and defines in a glossary common terms that are essential for creating detailed descriptions of the system's functionality.

^[2] Ivar Jacobson, Grady Booch, & James Rumbaugh. The Unified Software Development Process. Addison-Wesley, 1999.

Feature-oriented domain analysis (FODA) models domains in a feature-oriented way integrated with a use-case approach.^[3] Its purpose is ". . . to capture in a model the end user's (and customer's) understanding of the general capabilities of applications in a domain," which, the point is made, "sounds like use-case modeling." The two approaches are integrated because they serve different purposes. The use-case model is user oriented, providing the "what" of a domain: a complete description of what systems in the domain do. The feature model is re-user oriented, providing the "which" of the domain: which functionality can be selected when engineering new systems in the domain.

^[3] Martin Griss, John Favaro, & Massimo d'Alessandro. "Integrating Feature Modeling with the RESB." In Proceedings of International Conference on Software Reuse (ICSR), 1998.

Features, described as "an optional unit or increment of functionality," are also at the core of the Distributed Feature Composition (DFC) architecture.^[4] The fundamental idea of the DFC architecture for the telecommunications domain is to treat features as independent components through which calls are routed from caller to callee. Examples of features in the telecommunications environment are call-waiting and third-party conference.

^[4] Michael Jackson & Pamela Zave. "Distributed Feature Composition: A Virtual Architecture for Telecommunications Services." IEEE TSE Special Issue on Feature Interaction, 1998.

Services and facilities are part of the specification of the OMG work on CORBA.^{[5], [6]} Systems that support distributed objects can conform to the CORBA standard by providing certain services. Two examples of such services are an object-naming service and an object-event service. Examples of common facilities provided for by CORBA are user interface facilities and data interchange facilities.

^[5] Thomas Mowbray & Ron Zahavi. The Essential CORBA: Systems Integration Using Distributed Objects. Object Management Group, John Wiley & Sons, 1995.

^[6] Jon Siegel. CORBA Fundamentals and Programming. Object Management Group, John Wiley & Sons, 1996.

Goal-oriented requirements engineering (exemplified by the KAOS^[7] approach) involves the capturing of goals and agents. Goals are statements of intent about a program. Agents are "active components" or entities that play a role (humans, devices, and so on). Goals are refined into ever-finer grained subgoals until they can be realized and operationalized. Objects can be identified from goals by examining the passive entities involved in goal operation and by identifying the agents responsible for realizing the goals.

^[7] A. Dardenne, A. van Lamsweerde, & S. Fickas. "Goal-Directed Requirements Acquisition." Science of Computer Programming, 20:350, 1993.

Motivation for Choosing Units

From the units' definitions and the approach of different requirements-specification techniques, requirements for computer systems can be seen to be statements of what the computer system should do. Opinions of what computer systems should do, even opinions of the same computer system, are dependent on the people who will use the system and for what the system will be used. Different kinds of people have different needsand again, many different terms are used to describe the different motivations (for example, view, perspective, role). As before, in order to give a context for the vocabulary, dictionary definitions for these terms are described in Table 2-2.

Table 2-2. Motivations

Term	Dictionary definition
View	Manner of considering a subject, opinion, mental attitude; intention, design.
Perspective	Aspect of a subject and its parts as viewed by the mind; view.
Role	One's function, what a person or thing is appointed or expected to do.

Processes for requirements gathering take approaches based on the motivations of the end users of the computer system. Those motivations depend on the views, the perspectives, the roles, and the responsibilities of the end users. In requirements engineering, views have been described as allowing "development participants to address only those concerns or criteria that are of interest, ignoring others that are unrelated."^[8] One framework for requirements elicitation is based on the capture of multiple perspectives,^[9] while the roles end users play under different domain-dependent circumstances are the motivation behind role-modeling.^[10]

^[8] Bashar Nuseibeh, Jeff Kramer, & Anthony Finkelstein. "A Framework for Expressing the Relationships Between Multiple Views in Requirements Specification." IEEE TSE, 20(10):760773, October 1994.

^[9] Steve Easterbrook. "Elicitation of Requirements from Multiple Perspectives." PhD thesis, Department of Computing, Imperial College, London. 1991.

^[10] Trygve Reenskaug, Per Wold, & Odd Arild Lehne. Working with Objects: The OOram Software Engineering Method. Manning, 1995.

In summary, a requirements specification is modularized in terms of descriptions of required features, services, functions, and facilities. Potentially, each individual unit may be described to support multiple roles from different views and perspectives.

Describing Objects

The object-oriented paradigm supports modularization of software primarily based on the notion of an object as a representation of an entity, whether it's a "thing" in the real world, a software "thing," a system in and of itself, or an actor within a system. An object encapsulates the structural and behavioral properties that are core to that entity.

Object-Oriented Units

There have been many definitions of the units that are fundamental to the object-oriented paradigm. Table 2-3 illustrates some definitions for the main object-oriented concepts from a number of different sources.

Table 2-3. Object-Oriented Units

Term	Definition
Object	A concrete manifestation of an abstraction; an entity with a well-defined boundary and identity that encapsulates state and behavior; an instance of a class. [a]
	A concept, abstraction or thing with crisp boundaries and meaning for the problem at hand. [b]
	The "is-a" abstraction, representing a part of a system. An object has identity and attributes and is encapsulated so that the messages it sends and receives constitute all its externally observable properties. [c]
Class	A description of a set of objects that share the same attributes, operations, relationships, and semantics. [d]
	Objects that share the same behavior are said to belong to the same class. A class is a generic specification for an arbitrary number of similar objects.[e]
	A description of a group of objects with similar properties, common behavior, common relationships, and common semantics.[f]
Attribute	A named value or relationship that exists for some or all instances of some entity and is directly associated with that instance.[g]
	A named property of a class that describes a range of values that instances of the property may hold.[h]
	A data value held by the objects in a class.[i]
	The information an object may store.[j]
Operation	The implementation of a service that can be requested from any object of the class in order to affect behavior.[k]
	A function or transformation that may be applied to or by objects in a class.[l]
	A piece of code triggered by a message.[m]
Interface	A collection of operations that are used to specify a service of a class or a component.[n]
Method	The implementation of an operation.[o], [p]

^[a] Grady Booch, James Rumbaugh, & Ivar Jacobson. The Unified Modeling Language. The Object Technology Series, Addison-Wesley, 1998.

^[b] Derek Coleman, Patrick Arnold, Stephanie Bodoff, Chris Dollin, Helena Gilchrist, Fiona Hayes, & Paul Jeremes. Object-Oriented Development: The Fusion Method. Prentice Hall, 1994.

^[c] Reenskaug, Wold, & Lehne, Working with Objects.

^[d] Booch, Rumbaugh, & Jacobson, The Unified Modeling Language.

^[e] Rebecca Wirfs-Brock, Brian Wilkerson, & Lauren Wiener. Designing Object-Oriented Software. Prentice Hall, 1990.

^[f] Coleman et al., Object-Oriented Development.

^[g] FOLDOC: Free On-Line Dictionary of Computing.

^[h] Booch, Rumbaugh, & Jacobson, The Unified Modeling Language.

^[i] Coleman et al., Object-Oriented Development.

^[j] Reenskaug, Wold, & Lehne, Working with Objects.

^[k] Booch, Rumbaugh, & Jacobson, The Unified Modeling Language.

^[l] Coleman et al., Object-Oriented Development.

^[m] Steve Cook & John Daniels. Designing Object Systems. Object-Oriented Modeling with Syntropy. Prentice Hall, 1994.

^[n] Booch, Rumbaugh, & Jacobson, The Unified Modeling Language.

^[o] Ibid.

^[p] Coleman et al., Object-Oriented Development.

The definitions for the individual units are much the same. Multiple definitions are listed here partially from a historical perspective to illustrate that even from the early days, there was some level of consistency as to what were considered to be the units of interest in the object-oriented paradigm. Essentially, there are "things" of interest to the design that encapsulate structure and behavior. Classes, objects, and attributes describe the structure of things. Operations, interfaces, and methods describe the behavior of things.

Motivation for Choosing Units

The original motivations associated with the choice of "object" as the basic decomposition unit in the object-oriented software paradigm was to model real-world objects, thereby making software systems easier to develop and understand. Since then, objects have made sense as a unit of encapsulation because they allow decomposition and description in terms of a system's entities. Those entities can then be extended and reused. Additionally, the concept of working with objects at the software-specification level is familiar and intuitive, since we can relate it to the way in which we work with and describe real-world objects in daily life.

Comparing Requirements to Objects

The requirements-specification paradigm contains the notions of features, capabilities, services, functions, and so on, with generally no mention of objects and interfaces or any of the units of interest in the object-oriented design domain. The object-oriented paradigm contains the notions of objects, interfaces, and so on, with no mention of features, requirements, or any of the units of interest in the requirements domain. Object-oriented designs structurally match object-oriented code, because object-oriented programming languages such as C++ and Java explicitly provide programming constructs that map to object-oriented notions. This provides a measure of traceability between the design and coding phases.

Structurally, the units of interest in the requirements domain are fundamentally different from the units of interest in object-oriented software. Requirements units of interest generally are not, and cannot readily be, encapsulated in the software.

Achieving a mapping from requirements specifications to the object-oriented paradigm necessitates a transition from feature (or function, service, etc.) concerns in the requirements phase to the object/class concerns of the object-oriented paradigm. For instance, Figure 2-1 abstractly illustrates how requirements might not align with an object structure. Requirements are handled by multiple objects, and objects contain functionality pertaining to various requirements. Even the goal-oriented approaches listed above involve additional stages to make the transition from their basic unit (the goal) to objects.

Figure 2-1. Requirements to objects.

This point is particularly important. In general, most design paradigms are not sufficiently powerful to permit designs to match both requirements and codethey allow designs to align with either the requirements or the code, but not with both. Let's look at the impact of this with an example.