Classes and objects are separate yet intimate related concepts.Specifically , every object is the instance of some class ,and every class has zero or more instance .For particularly all applications classes are static : therefore their existence ,semantics ,and relationship are fixed prior to the execution of a program.Similarly ,the class of most objects is static ,meaning that once an objects is created ,its class is fixed. In sharp contrast, however, objects are typically created and destroyed at a furious rate during the life time of an application.

For example, consider the classes and objects in the implementation of air traffics control, systems .Some of the more important abstractions include planes ,flight plans ,runways, and air space. By their very definition ,the meaning of these class of objects are relatively static, or otherwise one could not build an application that embodied knowledge of such commonsense facts as that planes can take off, and then land ,and that 2 planes should not occupy the same space at the same time .Conversely ,the instance of these classes are dynamic. At a fairly slow rate, new runways are built, and old ones are filled away. With great frequency, new planes enter a particular air space, and old ones leave.

THE ROLE OF CLASSES AND OBJECTS IN ANALYSIS AND DESIGN

During analysis and the early stages of design, the developer has two primary tasks:

• Identify the classes and objects that from the vocabulary of the problem domain
• Invent the structures where by sets of objects work together to provide the behaviors that satisfy the requirements of the problem.

Collectively, we call such classes and objects the key abstraction of the problem, we call these cooperative structures the mechanisms of the abstractions.

During these phases of development, the focus of the developer must be upon the outside view of these key abstractions and mechanisms. This view represents the logical frame work of the system, and therefore encompasses the class structure and objects structure of the systems .In the later stages of design and then moving into implementation, the tasks of the developer changes .The focus is on the inside view of these key abstractions and mechanisms, involving their physical representation .We may express these design decisions as part of the systems module architecture and process architecture.

• A daisy is a kind of flower.
• A rose is a different kind of flower.
• Red roses and yellow roses are both kinds of roses.
• A petal is a part of both kinds of flowers.
• Ladybugs eat certain pests such as alphids,which may be infesting certain kinds of flowers

From this example we conclude that classes, like objects, do not exist in isolation .Rather a particular problem domain, the key abstractions are usually related in a variety of interesting ways, forming the class structure of our design.

We establish relationship between two classes for one or two reasons.First ,a class relationship might indicate some sort of sharing .For example ,daises and roses are both kind of flowers ,meaning that both have brightly colored petals , both emits fragrance, and so on.second a class relationship between might indicate some kinds of semantic connections.Thus,we say that red roses and yellow roses are more alike than are daises and roses ,and daises and roses are more closely related than are petals and flowers .Similarly ,there is a combining connection between ladybugs and flowers :ladybugs protect flowers from certain pests, which in turns serves as the food source for the lady bug. In all there are three basic kind of relationships. The first of these is generalization /specialization, denoting an “is a “relationship. For instance a rose is a kind of flower, meaning that a rose is a specialized subclass of the more general class, flower. The second is the whole /part, which denotes a part of relationship. Thus a petal is not a kind of flower; it is a part of flower. The third is a association ,which denotes some semantic dependency among otherwise unrelated classes ,such as between ladybugs and flowers .As another example roses and candles are largely independent classes , but they both represent things that we might use to decorate a dinner table.

Several common approaches have evolved in programming languages to capture generalization /specialization, whole /part, and association relationships. Specifically, most object-oriented languages provide direct support for some combination of the following relationship.

• Association
• Inheritance
• Aggregation

The concept of a class and an objects are tightly interowens,for we cannot talk about an object without regard for its class .However there are important difference between these two terms. Where as an objects is a concrete entity that exists in time and space a class represents only an abstraction,”the essence of an objects”, as it were. Thus we may speak of the class mammals. To identify a particular mammal in this class, we must speak of “this mammal”or “that mammal”.

Definition: A class is a set of objects that share a common structure and a common behavior.

A single object is simply an instance of a class .An object is not a class, although a class may be an object. Object that share no common structure and behavior cannot be grouped in a class because, by definition, they are unrelated except by general nature as object.

It is important to note that the class—as defined by most programming languages —is a necessary but insufficient vehicle for decomposition .Sometimes abstractions are so complex that they cannot be conveniently expressed in terms of a single declaration. For example, at a sufficiently high level of abstraction, a UGI frame work, a database ,and an entire inventory system are all conceptually individual objects , none of which can be expressed as a single class. Instead ,it is far better for us to capture these abstractions as a cluster of classes whose instances collaborate to provide the desired structure and behavior.

Examples of class and objects:

As all human beings have common features ,we can have a class of human beings .Let’s say it is X.An instance of X class can be an existing person whose has the features of class X.Let’s call it Y.Therefore X is the class and Y is the object.

INTERFACE AND IMPLEMENTATION

Programming is largely a matter of “contracting”: the various functions of a larger problem are decomposed into smaller problems by subcontracting them to different elements of the design. No where is this idea more evident then in the design of the classes.

Where as an individual object is an concrete entity that performs some role in the overall systems, the class captures the structure and behavior common to all related objects. Thus , a class serves as a sort of binding contract between an abstraction and all of its clients. By capturing these decisions in the interface of a class , a strongly typed programming language can detect violations of these contract during compilation.

This view of programming as contracting leads us to distinguish between the outside view and the inside view of a class.The interface of a class provides its outside view and therefore emphasis the abstraction while hiding its structure and the secrete of its behavior. This interface primarily consists of the declarations of all the operations applicable to instance of this class, but it may also include the declaration of other classes ,constants, variables, and exceptions as needed to complete the abstractions. By contrast ,the implementation of a class is its inside view, which encompasses the secrets of its behavior .The implementation of a class primarily consists of the implementation of all the operations defined in the interface of the class.

We can further divided the interface of a class into three parts:

Public A declaration that is accessible to all clients

Protected A declaration that is accessible only to the class itself,

Private A declaration that is accessible only to the class itself and its friends.

Different programming languages provide different mixture of public, protected and private parts, which developers can choose among to establish specific access rights for each part of a classes interface and thereby exercise over what clients can see and what they can’t see.

In particular ,C++ allows a developer to make explicit distinctions among all three of these parts. The C++ friendship mechanism permits a class to distinguish certain privileged classes that are given the rights to see the classes protected and private parts.Friendship breaks a classes encapsulation, and so in life, must be chosen carefully.

The relationship between any two objects encompasses the assumption that each makes about the other including what operation can be performed and what behavior result. There are two kinds of object hierarchies

• Links
• Aggregation

LINKS

It is a physical and conceptual connection between objects. An object collaborates with other objects .Stated another way a link to these objects.Stated another way a link denotes the specific association through which one object (client)applies the services of another objects (the supplier), or through which one object may navigate to another .

Example: In C++, the passing of a object of one class to a member function of another class. Therefore a link is established between 2 objects. Through this link they can communicate with ach other.

AGGREGATION

Aggregation denotes a whole/part of hierarchy, with the ability to navigate from the whole to its part .In this sense aggregation is a specialized kind of association.Agreegation may or may not denote physical containment. For example, an airplane is composed of wings and engines, landing gear, and so on. This is a case of physical containment .On the other hand, the relationship between a share holders and her shares is an aggregation relationship that does not require physical containment. The share holders uniquely owns share, but the shares are by no means a physical part of the share holder. Rather this whole/part relationship is more conceptual and therefore less direct than the physical aggregation of the parts that form an airplane.

There are clear trade-offs between links and aggregation. Aggregation is sometimes better because it encapsulates parts as secret of the whole. Links are sometimes better because they permit looser coupling among objects. Intelligent engineering decisions require careful weighing of these two factors.

By implementation, an object that is an attribute of another has a link to its aggregate. Across this link, the aggregate may send message to its parts.

Most programming languages use variable names to distinguish temporary objects, mixing addressability and identity. Most database system use identifier keys to distinguish persistent objects mixing data value and identity. the failure to recognize the difference between the name of an object and the object itself is the source of many kinds of errors in object oriented programming.

Message Passaging: An object communication with other objects through messages. A message connection is established between two objects when they are communicating. A message connection is a mapping of one object to another object, in which a sender sends message to a receiver to get some processing done. The needed processing is named in the sender’s services specification, and is defined in the receiver’s Services Specification. A message consists of an address (which object or objects to send it to) and an instruction, consisting of a method name and zero or more parameters. If the addresses contains a method which the instruction makes sense and then an answer is returned to the sending objects.For example ,we can send an integer object 3 the message ‘add 5’ and expect the answer ‘8’ to come back.

Definition: Behavior is how an object acts and reacts, in terms of its state changes and message passing.

In another words, the behavior of an objects represents its outwardly visible and testable activity. Our definition for behavior notes that the state of an object affects its behavior. Consider again the vending machine example. We may invoke some operation to make a selection, but the vending machine will behave very differently depending upon its state. If we do not deposit change sufficient for our selection, then the machine will probably do nothing. if we provide sufficient change, the machine will take our change and then give us our selection(thereby altering its state).Thus we may say that the behavior of an object is a function of its state as well as the operation performed upon it, with certain operations having t6he side effect of altering the object’s state.

Operations: An operation denotes a service that a class offers to its clients (users).An operation is also referred to by several people as “method”. In practice, a client typically performs five kinds of operations are the following:

Modifier An operation that alters the state of an object. This is also known as the set operation.

Selector An operation that access the state of an objects, but does not alter the state. This is also referred to as get operation.

Iterator An operation that permits all parts of an object to be accessed in some well defined order.

Two other kinds of operations are also common: they represent the infrastructure necessary to create and destroy instances of a class:

Constructor:- An operation that creates an object and/or initializes its state

Destructor:-An operation that frees they state of an object and/or destroys the objects itself

In each of those circumstances ,we see how to behavior of an object is influenced by its history: the order in which one operates upon the object is important. The reason for this event – and time-dependent behavior is the existence of the state with in the object. For example ,one essential state associated with the vending machine is the amount of money currently entered by a user but not yet applied to a selection. Other important property includes the amount of change available and the quality of soft drinks on hand.

Another property of vending machine is that it can accept coins .this is a static property, meaning that it is an essential characteristic of a vending machine. In contrast, the actual quantity of coins accepted at any moment represents the dynamic value of the property, and is affected by the order of operations upon the machine. We say that values are “usually dynamic” because in some cases values are static. For example, the serial number of a vending machine is a static property and value. All the property of an object constitutes the Object’s Attributes. The values held by these Attributes at a particular instance describe that object at that particular Instance.

Definition: The state of an object encompasses all of the(usually static) properties of the object plus the current(usually dynamic) values of each of these properties.

The ability to recognize physical objects is a skill that humans learn at a very early age. A brightly colored ball will attract an infant’s attention. But typically if you hide the ball, the child will not try to look for it ; when the object leaves her field of vision ,as far as she can determine ,it ceases to exist. It is not until near the age of one that a child normally developers what is called the object concept, a skill that is of critical importance to future mental development. Show a ball to a one –year-old and then hide it, and she will usually search for it even though it is not visible.Through the object concepts ,a child comes to realize that objects have a permanence and identify upon any operations upon them.

From the perspective of human cognition, an object is any of the following.

• A touchable and/or visible thing.
• Something that may be apprehended intellectually.
• Something towards which thought and action is directed.

We add to our informal definition the idea that an object models some part of reality and is therefore something that exists in time and space.Realworld objects are not the only kind of objects that are of interest to us during software development.Other important kinds of objects are invention of design process whose collaboration with other such objects serve as the mechanisms that provide some higher-level behavior .In general terms we define an object as anything with a crispy defined boundary.

Consider for a moment a manufacturing plant that processes composite materials for making such divers items as bicycle frames and airplane wings. Manufacturing plants are often divided into separate shopes: mechanical, chemical, electrical,and so forth.Shopes are further divided into cells and in each cells we have some collections of machines,such as die stamps,presses,and lathes. Along a manufacturing line, we might finds vats containing raw materials, and which are used in a chemical process to produce blokes of composite materials, and which in turns are formed and shaped to produce end items such as bicycle frames and airplanes wings. Each of the tangible things that have been mentioned thus far is an object. A lathe has a crispy defined boundary that separates it from the block of composite material it operates upon; a bicycle frame has a crispy defined boundary that distinguish it from the cell of machines that produce the frame itself.

Some objects may have crisp conceptual boundaries, yet represent untouchable events or processes.For example a chemical process in a manufacturing plant may be treated as an objects, because it is having a crisp conceptual boundary, interacts with certain other objects through a well ordered collection of operations that unfolds overtime, and exhibits a well defined behavior.

Some objects may be touchable, yet have fuzzy physical Boundaries.Objects such as rivers, fog, and crowds of people fit this definition.Just as a person holding a hammer tends to see everything in the world as a nail, so the developer with an object oriented mindset begins to think that everything in the world is a object. This perspective is a little naive, because there are certain things that are distinctly not objects. For examples attributes such as time, beauty, color are not objects nor are emotions as love and anger. On the other hand, these things are all potentially properties of other objects For example we might say that a man (an object) loves is wife(another object),or that a particular cat(yet another object)is gray.Thus,it is useful to say that an object is something that has crispy defined boundaries, but this not enough to guide us in distinguishing one object from another, nor does it allow us to judge the quality of our abstractions.The above discussion therefore suggests the following definition:

Definition:An object has state ,behavior ,and identity; the structure and behavior of similar objects are defined in their common class;the terms instance and objects are interchangeable.

The practice of every engineering discipline involves elements of both science and art. As Petroski states, the conception of a design of a new structure can involve as much a leap of imagination and as much as a synthesis of experienced and knowledge as any artist is required to bring to his canvas or paper. And once that design is articulated by the engineer as artist, it must be analyzed by the engineer as scientist in as rigorous an application of the scientific method as any scientist must make.

The role of the engineer is particularly challenging when the task is to design an entirely new system. Frankly this is the most common circumstance in software engineering .Especially in the case of reactive systems and systems of command and control, we are frequently asked to write software for an entirely unique set of requirements often to be executed on a configuration of target processors constructed specifically for the system. In other cases such as the creation of frameworks , tools for research in artificial intelligence, or even information management systems, we may have a well defined ,stable target environment ,but our requirements may stress the software technology in one or more dimensions. For example we may be asked to craft systems that are faster ,have greater capacity ,or have radically improved functionality. In all these situations ,we try to use proven abstractions and mechanisms as a foundation upon which to build new software systems .In the presence of a large library of reusable software components ,the software engineer must assemble these parts in innovative ways to satisfy the stated and implicit requirements ,just as the painters or the musicians must push the limits of his or her medium.Unfortunately ,since rich libraries rarely exists for the software engineer, He or she must usually proceed with a relatively primitive set of facilities.

]]> http://www.offshore-website-development.com/claveland/2008/02/29/on-designing-complex-systems/feed/ http://www.offshore-website-development.com/claveland/2008/02/29/bringing-order-to-chaos/ http://www.offshore-website-development.com/claveland/2008/02/29/bringing-order-to-chaos/#comments Fri, 29 Feb 2008 10:51:12 +0000 admin http://www.offshore-website-development.com/claveland/2008/02/29/bringing-order-to-chaos/ The Role of Decomposition

The technique of mastering complexity has been known since ancient times: divide and rule. When designing a complex software systems, it is essential to decompose it into smaller parts each of which we may then refine independently. In this manner, we satisfy the very real constraint that exists upon the channel capacity of human cognition. To understand any given level of systems ,we need only comprehend a few parts at once.

Algorithmic decomposition:-Most of us have been formally trained in the dogma of top-down structured design, and so we approach decomposition as a simple matter of algorithmic decomposition, where in each module in the system denotes a major step in some overall process.

Object Oriented Decomposition:- We have to decompose a system according to the key abstractions in the domain .rather than decomposing the problem into steps as in algorithmic decomposition here we have to identify the objects which occur directly in the vocabulary of the problem domain. We view the world as a set of autonomous agents that collaborate to perform some higher level behavior. Each object embodies its own unique behavior ,and object is simply tangible entity which exhibit some well –defined behavior Objects do this and we ask them to perform the what they do by sending them messages. Because our decomposition is based upon objects and not algorithms, call this an object-oriented decomposition.

Algorithmic verses object-oriented decomposition:- Which is the right way to decompose a complex system,–by algorithms or by objects? Actually the answer for this, both the ways are important. The algorithmic view highlights the ordering of events, and object oriented view emphasizes the agents that either cause action or are the subjects upon the operations act. However, the fact remains that we cannot construct a complex system in both ways simultaneously, for they are completely orthogonal views. We must start then use the resulting structure as the frame work for expressing the other perspective.

It is better the object oriented view first because this approach is better at helped us to describe the organized complexity of complex systems as diverse as computers ,plants,galaxies,and large social institutios.Object oriented decomposition has a number of highly significant advantages over algorithmic decomposition. Object oriented decomposition yield smaller systems through reuse of common mechanisms thus providing an important economy of expression. Object oriented systems are also more resilient to change and better able to evolve over time, because their design is based upon stable intermediate forms .Object Oriented decomposition greatly reduces the risk of building complex software systems ,because they are designed to evolve incrementally from smaller systems in which we already have confidence .Furthermore object oriented decomposition directly addresses the inherent complexity of software by helping us make intelligent decisions regarding the splitting of large software systems into smaller units.

The role of Abstraction

According with Miller’s Experiments, he concluded that an individual can comprehend only about seven, plus or minus two, chunks of information at one time. This number appears to be independent of information content. As Miller himself observes “the span of absolute judgment and the span of immediate memory impose several limitations on the amount of information that we are able to recive,process and remember .By organizing the stimulus input simultaneously into several dimensions and successively into a sequence of chunks ,we manage to break…this information al bottleneck. In contemporary terms ,we call this process chunking ,or abstraction.

The humans have developed an exceptionally powerful technique for dealing with complexity. We abstract from it. Unable to master the entirety with complexity. We chose to ignore its inessential details, dealing instead with the generalized, idealized, model of the object.

For example, when studying how photosynthesis works in a plant, we can focus upon the chemical reactions in certain cells in a leaf; ignore all other parts, such as the roots and the stems. We are still constrained but the number of things that we can comprehend at one time, but through abstraction, we use chunks of information with increasingly greater semantic content. This is especially true if we take an object oriented view of the world, because objects, as abstractions of entities in the real world, represent a particularly dense and cohesive clustering of information.

The Role Of Hierarchy

Another way to increase the semantic content of individual chunks of information is by explicitly recognizing the class and object hierarchies within complex software systems. The object structure is important because it illustrates how different objects collaborate with one another through patterns of interactions that we call mechanisms .The class structure is equally important ,because it highlights common structure and behavior within a system .Thus rather than study each individual photosynthesizing cell within a specific plant leaf, it is enough to study one such cell, because we expect all other will exhibit similar behavior .Although we treat each instance of a particular kind of object behavior .Although we treat each instance of a particular kind of object as distinct, we may assume that it shares the same kind of object. By classifying objects into groups of related abstractions, we come to explicitly distinguish the common and distinct properties of different objects, which further helps us to master their inherent complexity.

Identifying the hierarchies within a complex software system is often not easy, because it requires the discovery of patterns among many objects, each of which may embody some tremendously complicated behavior. Once we have exposed these hierarchies, however the structures of a complex system and in turn our understanding of it, becomes vastly simplified.