Object-oriented concepts:Purpose,Strengths, weaknesses, limitations and Inputs and related ideas

By -

Object-oriented concepts

6.1 Purpose

The objective of the object-oriented approach to software development is to support creating software that is easier to change, debug, and maintain than is traditional software. Today, object-oriented principles are also applied to system development.

6.2 Strengths, weaknesses, and limitations

The object-oriented approach offers many advantages over traditional software (and system) development. Object-oriented software and systems are intuitive. Objects are things that really exist, events are things that really happen, and real-world objects really do respond to something like signals.

Object-oriented software and systems are easier to change, debug, and maintain than are traditional structured software and systems because they are highly modular. Because the modules reflect natural classifications, they tend to be more independent and more stable than the somewhat arbitrary modules suggested by traditional structured techniques. Because data and methods are grouped in the same object, ripple effects are isolated and thus easier to trace.

The object-oriented approach to software development supports reusable code. The principle of reusability is imbedded in the theory that underlies object-oriented software.

Object-oriented software is often less efficient than structured software on traditional single-processor computers. Note, however, that object-oriented software may actually be more efficient on the parallel systems that are evolving.

More significantly, relatively few programmers are trained in the object-oriented approach, leading to personnel shortages, and adding to software development expense. Current academic curricula are beginning to stress object-oriented software, however, so this problem may grow less severe given time.

6.3 Inputs and related ideas

Object-oriented analysis is discussed in Chapter 29. Object-oriented software design is discussed in Chapter 66.

6.4 Concepts

An object is a thing about which data are stored and manipulated. It might be a physical thing such as a person, a customer, a book, or an item in inventory. It might be an abstract thing such as a model, a concept, or a process. Unlike many technical terms, the word object means what people intuitively think it means.

6.4.1 Objects and object types

To avoid being swamped by the sheer number of objects, similar objects are grouped to form classes or object types. Classifying or grouping objects makes it easier to track them.

An individual object is a single instance (or occurrence) of an object class (or object type). For example, a given computer (the object itself) has a unique serial number. That particular computer is but one instance of a given model. Moving up the classification hierarchy, a store might distinguish between tower, desktop, laptop, and hand-held computers. Finally, computers, printers, boards, software, supplies, books, and services clearly represent different categories.

6.4.2 Encapsulation

Both data (attributes) and methods (processes) are associated with an object. For example, an item in inventory might be described by listing such attributes as its product code, a brief description, its selling price, and so on. A method is a process that accesses an object. For example, associated with a given product in inventory are methods for placing it in inventory, changing one of more of its attributes, removing it from inventory, and so on. Methods define how the object’s data are manipulated.

In an object-oriented program, an object’s data and methods are bundled so that the only way to access the data is through the object’s own methods. Hiding implementation details in this way is called encapsulation. The only way other objects can obtain a given object’s data is through one of that object’s own methods.

6.4.3 Signals

Because the objects in a well-designed object-oriented system are encapsulated, they are isolated from each other and changes to one object cannot inadvertently affect others. Objects do not exist in a vacuum, however. They interact with other objects by transmitting and responding to signals.

Signals are generated by events. An event occurs when an object’s state changes. A change in state usually implies a change in the value of one of the object’s attributes. The only way to change an attribute is through one of the object’s own methods, so events imply methods.

An operation is an external view of an object that can be accessed by other objects. An operation is implemented by one of more methods. In effect, an operation is a method (or methods) that responds to or generates external signals.

Note that a given event does not direct its signal to a specific target object. Instead, the initiating event simply broadcasts the signal. Other objects might respond to the signal or ignore it, but the source object neither knows nor cares. In this case, indifference implies independence.

6.4.4 Inheritance

A Mazda Miata can be described as a small, sporty, two-seat automobile. Because it is a type (subclass) of automobile, all the attributes the Miata shares with other automobiles (four wheels, an engine, a cooling system, methods for propulsion, steering, and stopping) can be assumed.

Moving down another level, a specific Mazda Miata (an object) can be described in terms of the attributes that make it unique (red, convertible top, serial number), and the attributes it shares with other Miatas (small, two seats, sporty) can be assumed. In effect, each subclass borrows (or inherits) attributes and methods from its superclass. This concept is called inheritance.

6.4.5 Polymorphism

A given operation or method is considered polymorphic if it produces similar results in different objects or at different levels. For example, a customer sale, a customer return, the arrival of a shipment, and the completion of a physical inventory are all events that can change the value of the inventory stock-on-hand for a given object type. The general structure of the inventory update method might be inherited from the highest-level class, and then customized for each of these special cases.

6.5 Key terms
Class (object type) —
A group of similar objects.
Encapsulation —
Hiding implementation details by bundling an object’s data and its methods so that the only way to access the data is through the object’s own methods.
Event —
An occurrence that generates a signal.
Inheritance —
The principle that allows an object to get attributes and methods from its superclass.
Method —
A process that accesses an object.
Object —
A thing about which data are stored and manipulated.
Object type (class) —
A group of similar objects.
Operation —
An external view of an object that can be accessed by other objects.
Polymorphism —
The property of an operation or method that allows it to produce similar results in different objects or at different levels.
Signal —
A message that allows objects to interact with other objects.
State —
A set of attribute values for an object.
6.6 Software

Not applicable.

6.7 References
1.  Budd, T., An Introduction to Object-Oriented Programming, Addison-Wesley, Reading, MA, 1991.
2.  Davis, W. S., Business Systems Analysis and Design, Wadsworth, Belmont, CA, 1994.
3.  Martin, J. and Odell, J. J., Object-Oriented Analysis and Design, Prentice-Hall, Englewood Cliffs, NJ, 1992.
4.  Winblad, A. L., et al., Object Oriented Software, Addison-Wesley, Reading, MA, 1990.

Comments

Post a Comment

Popular posts from this blog

The Conversion Cycle:The Traditional Manufacturing Environment

By -
Image
The Traditional Manufacturing Environment The conversion cycle consists of both physical and information activities related to manufacturing products for sale. The context-level data flow diagram (DFD) in Figure 7-1 illustrates the central role of the conversion cycle and its interactions with other business cycles. Production is triggered by customer orders from the revenue cycle and/or by sales forecasts from marketing. These inputs are used to set a production target and prepare a production plan, which drives production activities. Purchase requisitions for the raw materials needed to meet production objectives are sent to the purchases procedures (expenditure cycle), which prepares purchase orders for vendors. Labor used in production is transmitted to the payroll system (expenditure cycle) for payroll processing. Manufacturing costs associated with intermediate work-in-process and finished goods (FG) are sent to the general ledger (GL) and financial reporting system. Dependin...
Read more

The Revenue Cycle:Manual Systems

By -
Image
Manual Systems The purpose of this section is to support the system concepts presented in the previous section with models depicting people, organizational units, and physical documents and files. This section should help you envision the segregation of duties and independent verifications, which are essential to effective internal control regardless of the technology in place. In addition, we highlight inefficiencies intrinsic to manual systems, which gave rise to modern systems using improved technologies. SALES ORDER PROCESSING The system flowchart in Figure 4-12 shows the procedures and the documents typical to a manual sales order system. In manual systems, maintaining physical files of source documents is critical to the audit trail. As we walk through the flowchart, notice that in each department, after completion of the assigned task, one or more documents are filed as evidence that the task was completed. Sales Department The sales process begins with a customer cont...
Read more

HIPO (hierarchy plus input-process-output)

By -
Image
HIPO (hierarchy plus input-process-output) 64.1 Purpose The HIPO (Hierarchy plus Input-Process-Output) technique is a tool for planning and/or documenting a computer program. A HIPO model consists of a hierarchy chart that graphically represents the program’s control structure and a set of IPO (Input-Process-Output) charts that describe the inputs to, the outputs from, and the functions (or processes) performed by each module on the hierarchy chart. 64.2 Strengths, weaknesses, and limitations Using the HIPO technique, designers can evaluate and refine a program’s design, and correct flaws prior to implementation. Given the graphic nature of HIPO, users and managers can easily follow a program’s structure. The hierarchy chart serves as a useful planning and visualization document for managing the program development process. The IPO charts define for the programmer each module’s inputs, outputs, and algorithms. In theory, HIPO provides valuable long-term documentation. However...
Read more