top of page

Object  Oriented System Analysis and Design

Object Oriented is a way of structuring hardware and software resources in packaged modular units, which will allow the object to be freely connected to and used with any object in environment, providing that the object interface rules be adhered to.

  • What is Object Orientation?

  • Why is Object Orientation so Important?

    1. Why do we need Object Orientation?​​

    2. Objectives and Benefits of Object Orientation

  • What does Object Orientation mean to the Businessman?

  • Layers of Business Object​

    1. Business Strategic Objects

    2. Commercial Objects

    3. Technical Objects

    4. The Impact of Object Orientation on a Process Oriented Business Design

Object Oriented System Analysis and Design Manual

What is Object Orientation?

Simply stated, object-oriented system establishment is an approach to business system establishment, in which the decomposition of a system is based upon the concept of an object.


An object is a natural building block in Business Systems, Application Systems, as well as the Operating Environment.
Objects are simply the noun part of any ordinary sentence. Changing from function-oriented to objectoriented thinking is like changing from active to passive tense.


Object Oriented is a way of structuring hardware and software resources in packaged modular units, which will allow the object to be freely connected to and used with any object in environment, providing that the  object interface rules be adhered to.


Systems designed in an object oriented manner tend to exhibit characteristics quite different to those designed with more traditional functional approaches. Large object-oriented systems tend to be built in layers of abstraction, where each layer denotes a collection of objects and classes of objects, with restricted visibility to other layers; we call such a collection or cluster of objects a sub-system. Furthermore, the components that form a sub-system tend to be structurally flat, rather than being strictly hierarchical and deeply nested.


The global flow of control in an object-oriented system is quite different from that of a functionally decomposed system. In the latter case, there tends to be a single thread of control that follows the hierarchical lines of decomposition. In the case of an object-oriented system we typically cannot identify a central thread of control, because objects may be independent and autonomous. Rather, there may be many threads active simultaneously throughout a system. This model is actually not a bad one, for it more often reflects our abstraction of reality. We should add that the subprogram call profile of an object-oriented system, typically exhibits deeply nested calls; the implementation of an object operation most often involves invoking operations upon other objects. 


The notion of an object plays the central role in object-oriented systems, but actually, the concept is not a new one. Indeed, as MacLenna reports, “programming is object oriented mathematics.


To many, object orientation means the structuring of actions/processes around data. This elementary approach is adequate for the software application layer of the I.S. architecture, but not for the business and operating environment architecture layers.

​

Why is Object Orientation so Important?

​Why do we need Object Orientation?

  1. Use of multiple hardware and software components to do the work of the same constituent. (For instance, a machine may run both OS/2 and DOS as operating systems).

  2. Use of incompatible and sometimes mutually exclusive components. (For instance: Ventura (Desktop Publishing) running under DOS and GEM, configured for a WYSE 7190 high resolution graphics adapter, cannot run simultaneously with GUIDE (Multimedia) running under DIS and Windows, configured for a Super VGA adapter).​

  3. Use of hybrid software and hardware components. (Example: OS/2 PM used on an IBM PS/2 as one workstation, and Unix, Motif and OpenLook used on a SUN as another workstation, both linked to be DEC/VAX mainframe running Sybase as data base manager.) Hybrid technologies make for extremely complex operating environments which have the potential to become a system administrators and users nightmare, because of the effort to ensure a seamless IS operation.

  4. Poorly integrated facilities in the operating environment resulting in:

    • conflicts between components​

    • inconsistency in data and results from operations

    • redundancy (or duplication) of data, functions and facilities

    • fragmentation of operational systems.

​

Objectives and Benefits of Object Orientation

  1. To be able (by having a suitable mechanism) to formalise our model of reality. They make
    possible a direct and natural correspondence between the world and its model.

  2. To provide a more natural paradigm to emulate the real world in the application environment.

  3. To enhance understandability and maintainability due to the fact that objects and their related

  4. To ensure reusability of all system components: hardware, software code, designs, concepts, systems.

  5. To ensure “open endedness” of software (and hardware) components for maximum configurability..

  6. To facilitate a co-operative and concurrent processing environment to attain maximum throughput.

  7. Applicability to problems containing natural concurrency, the object-oriented method seemed to produce better solutions for a problem which involved real-time processing.

  8. masters and by dynamically allocating appropriate system resources to do this task.

  9. To reduce the total life-cycle software cost by increasing programmer productivity and reducing maintenance costs.

  10. To ensure system robustness.

  11. To implement software systems that resist both accidental and malicious corruption attempts.

  12. Modular, object-oriented programming yields software products on which modifications and extensions [Maintenance] are much easier to perform than with programs structured in a more conventional, procedure-oriented fashion”.

  13. To rationalise and optimise the organisation of the I.S. Application Environment.

  14. To facilitate the “packaging” of hardware and software components to support distributed architectures.

  15. To ensure interchangeability of hardware and software components (This will facilitate diversification and technology enhancements in a natural manner, because migration to improved environments is made transparent).

  16. Comprehensibility and architectural elegance

  17. To ensure system quality.

  18. To establish a Business consisting of Business objects.

  19. To establish a Methodology consisting of Method objects. operations are localised.

What does Object Orientation mean to the Businessman?

The rate of change required of businesses, to ensure survival, is necessitating an ability to adapt to changing business requirements in a matter of weeks. Businesses simply lose their competitive advantage if they don't have the means of anticipating and effecting change quicker than their competitors. The only way a business can keep abreast of the current rate of change in the business environment is to have the ability to adapt its business and information systems at the same rate and to pre-empt the change.


A business that is built out of a number of business objects that can be replaced in an object oriented way stand a chance of obtaining the required rate of change. If a business object like a Procurement process can be plugged out and replaced with a new one without effecting the surrounding business objects the process of change would be exponentially simpler and more streamlined. This is achievable through object orientation at a business level.


Object orientation initially started at the technology level of systems. The initial occurrences of true objects were in the format of hardware. A graphic card being accommodated with a set of methods that enable it to control the images that are displayed on a screen. The next generation of objects were programmable processes that were designed and coded as objects. Businesses are freed from the burden of investing in and developing both of these different levels of objects, as they are commercially available. The objects that most programmers were coding themselves a year or two ago can all be purchased today.

Object Orientation System.png

Currently the emphasis has shifted to business objects. Organisations are investing in developing objects at this architectural level. These objects will provide businesses with the same kinds of benefits that the objects at the other two architectural levels did. In the very near future objects at this architectural level will also be shrink wrapped and sold off the shelf.


This rationale currently implies a strategic investment from the business to either acquire or construct a set of business objects. The business objects alone would however not be sufficient to solve the problem. One set of business objects must exist that is focused on ensuring that we can anticipate the requirement for change. We need a set of business objects for dedicated business engineering. This approach allows one to truly have business strategic systems consisting of business strategic objects.

​

The industry should focus on developing generic objects and more specific classes of them. These objects must be made available for purchase by anyone. Businesses should not hesitate to make their business objects available to their competitors. The mere fact that they are in a position to provide their competitor with business objects already gives them the competitive edge. It is not the objects but it is rather the ability to apply the objects that will one day be the distinguishing factor of businesses.


Any new development of any business object that is conducted within the Object Oriented paradigm is focused on building small objects, classifying them into class structures, composing bigger objects from a number of smaller objects and building objects with smaller, fewer and more explicit interfaces. This is the only way of facilitating the termination of a business object and enabling a new one.


An organisation that follows this approach is more exposed to change crises due to the ability of changing faster. This places a major emphasis on Change Management. People will experience threats associated with change more frequently due to the change ability. This necessitates a Change and Learning culture in an organisation.

Layers of Business Object

A business that is constructed from objects is different to an ordinary structured business in that the entire system is built around an object bias rather than a transaction bias.


An example of an ordinary business would be to have a set of business functions that would Sell products to customers. This sale would then trigger the customer to give the salesman an Order. The salesman woul  verify the Order and initiate Inventory Management to Purchase the product from a supplier. For this transaction a new set of functions would generate yet another set of documents called the Purchase Order that their manager would have to compare with the Request for Purchase documents to ensure that the quantity is correct. This Purchase Order is then submitted to the supplier. The supplier would deliver products that are accompanied by a Delivery Note. An additional set of business functions, with people manning them, would now have to disseminate the Delivery Note and compare with all the Orders that have not been fully satisfied in terms of delivery, to Receive the products. This is required as one needs to
understand which deliveries are associated with which orders.

Layers of OO.png

It is clear that a business that has its systems structured around such a transaction requirement needs a bigger staff component and much more control mechanisms, which ultimately complicates and slows the process down.


The alternative is to construct the business from system components that are grouped around objects. What this means is that we have to identify the potential objects. In the previous example the Product qualifies as an object. Then we have to identify all the transaction states that the object can have.


The product can Be Sold, Be Requested from Inventory Management, Be Quoted For by the supplier, Be Ordered from the supplier, Be Delivered by the supplier and Be Received by us. What we have to do now is to group methods around this object that have the ability of interfacing with methods of other objects.
 

The methods of a particular object also have to have the ability of changing the status of the object to one of
its relevant transaction states. An example of another object could be the Supplier that could have states of
Be Ordered From and Has Supplied.

Protocol.png

In the example above the Supplier is the Respondent and the Product the Initiator.


It is very clear that a totally different rationale for design was used in the latter case. The grouping of functions were structured around processes and not around a transaction as in the normal case. The ordinary business cycles or processes can still be achieved by utilising the functions of the objects in a particular sequence and by allowing them to interface with functions from other objects.


In the object oriented paradigm businesses are constructed from layers of objects. Business objects are super-imposed on commercial objects that are super-imposed on technical objects.

Business Decisions.png

  1. Business Strategic Objects

    • Characteristics of these objects​​

      • They are difficult to develop.

      • They are impossible for competitors to replicate.

      • Over time they will require shorter development times due to the object oriented development paradigm. Currently they might still require long development times.

      • It delivers benefits that are hard for competitors to respond to. Typical of real first mover advantage. (Building the Wall)

      • Opens opportunities to a new class of customer. An example would be if South African deep gold mining operations actually capitalise on their expertise and consult on it.

      • Changes the rules of the competition. For example this is when a product market is forced into a service or solutions market with very low mark up on the actual products.

      • Provide a platform for evolution. From an object based platform the strategic objects can be continuously modified. (Widen the Gap between you and your competitors).

      • Are sometimes difficult to conceptualise.

    • Examples of the Objects

      • Forecasting of product trends.​

      • Forecasting of market trends.

      • Sales channel front end tools.

      • Sales advisor / configurators.

  2. Commercial Objects

    • Characteristics of the Objects​

      • They are similar for businesses of the same industry type.​

      • They are commercially available in packages.

      • It is easy to get access to these objects.

      • They do not take a huge investment to enable.

      • They are relatively easily understandable as they are based on basic business practise principles.

      • They are always perceived as necessary.

    • Examples of the Objects

      • Bill of Material.​

      • Inventory Management.

      • General Ledger.

      • Procurement.

  3. Technical Objects

    • Characteristics of the Objects​

      • Sometimes initially difficult to conceptualise.​

      • Relatively basic of nature, e.g. a cursor.

      • Totally programmable.

      • All are purchasable.

      • They do not take a huge investment to establish.

      • Due to their numbers configuration management could be a problem.

    • Examples Of the Objects

      • Device Drivers.​

      • Graphics Objects.

      • Data Engines.

      • A cursor.

      • A column of a table.

      • The objects that are accumulated are based on business decisions dictated by business requirements. The process of building object based business systems involves the establishment of the business requirements and reflecting them in Strategic Business Objects. These objects are based on a layer of Commercial Business Objects below them, that are in turn based on Technical objects one level below them. All three the layers of objects together represent all the business objects.

      • It is possible to have designs and implemented objects at any of the three levels with only partial representation of true object designs and implementations at the other two levels.

  4. The Impact of Object Orientation on a Process Oriented Business Design​​

A process orientation typically represents a very rigid business design due to its sequential nature. Any changes that are made to components of these kinds of processes will result in the entire procedure being effected. This implies that a phased change plan will need to be implemented to effect the change over a longer period of time, to accommodate the mind set change. Implementing a change over a longer period of time simply means that the window of business opportunity is not exploited
and missed in a lot of instances.


When a process is constructed from a number of autonomous objects it enables one to plug an object out and plug a new object in to replace it. So, from a technical design point of view an object oriented system enables us to implement change in a very controlled manner, with the minimum effect to the process, as the effect of the change is contained to the single object or objects that were replaced.


It is actually possible to implement a change in the process exponentially faster. It is simply the only approach that can enable us to change our processes as fast as is required. There will be no spilling of the business opportunities. It is simply easier to continuously align a process with the required strategies. The manning of process structured business implies that people must have more diverse skills to deal with more functional areas, as a process spans several functional areas. Changes to these systems are faced with different resistance, as a wider front of people are effected. The process nature of the system also implies that people become a lot more comfortable with the procedural nature of their work. Because we are able to change processes faster and more regularly it actually creates a problem for us in how to ensure the buy-in from the people who man the systems. Thus, new objects that are plugged in effect more people that might have to be re-skilled and more people to resist the change.

bottom of page