Object Oriented Analysis and Design

Lecture 1

The inherent complexity of software consists from four elements. Those are the complexity of the problem domain, the difficulty of managing the developmental process, the flexibility possible through software, and the problems of characterizing the behavior of discrete systems.

This complexity comes because of the complexity of the problem domain. Some times developers may have to develop a system which they are not familiar with. For example the requirement may be to develop some kind of very accurate medical equipment or an air craft monitoring system. At that situation the developers are from a programming background and not from a medical or aeronautic background. Then they find it difficult to understand the concepts and the requirements the users are expecting. Perhaps there may be contradictory requirements. Nonfunctional requirements such as usability, erformance, cost, survivability, and reliability provide an extra complexity to a system.

This external complexity usually springs from the impedance mismatch that exists between the users of a system and its developers. Users generally find it very hard to give precise expression to their needs in a form that developers can understand. This occurs because each group generally lacks expertise in the domain of the other. Users and developers have different perspectives on the nature of the problem and make different assumptions regarding the nature of the solution.

A further complication is that the requirements of a software system often change during its development process. May be because the users are not aware of the requirements properly. So they change the requirements from time to time when they get the correct vicinity of the system. Seeing early products, such as design documents and prototypes, and then using a system once it is installed and operational, are forcing functions that lead users to better understand and articulate their real needs.

The main objective of the software development process is to make a bib and complex problem domain into a very simple solution where the user can understand and manipulate easily. Developing software writing less code by inventing clever and powerful mechanisms that give us this simplicity, as well as by reusing frame-works of existing designs and code is the most difficult thing in the software development process.

• Many complex systems are decomposable. Hierarchic structure is a major facilitating factor enabling us to understand by dividing them to subparts and study part by part and then to have a hierarchic structure.
• What is primitive for one observer may be at a much higher level of abstraction for another.
• This difference between intra- and inter component interactions provides a clear separation of concerns among the various parts of a system, making it possible to study each part in relative isolation.
• Most of the big complex systems are developed identifying the common patterns. These patterns may involve the reuse of small components.
• All the complex systems are evolved from a simple system and we must use them and then improve them over time as we learn more about the real behavior of the system.

Object-oriented analysis

This is a method of analysis of the identified requirements from the perspective of the classes and objects within the problem domain.

Object-oriented design

This is a method of design encompassing the process of object-oriented decomposition and a notation for represents logical and physical as well as static and dynamic models of the system under design.

Abstraction

Abstraction is mainly the process of generalizing which is used as a remedy to the complex requirements. When we are unable to understand a complex system we don’t worry about the unknown parts we just make them abstract. A good abstraction is one that emphasizes details that are significant to the reader or user and suppresses details which are unimportant for the moment.

Abstraction Types

Entity abstraction

An object that represents a useful model of a problem domain or solution-domain Entity

Action abstraction

An object that provides a generalized set of operations for similar kind of functions.

Virtual machine abstraction

An object that groups together operations that are all used by some superior level of control, or operations that all use some junior-level set of operations

Coincidental abstraction

An object that packages a set of operations that have no relation to each other

Encapsulation

Encapsulation hides the details of the implementation.

Modularity

Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules. The act of partitioning a program into individual components can reduce its complexity to some degree.

Overall goal of the decomposition into modules

• The simplicity preserves when modularized. It is easy to understand the problem since its divided into small parts.
• When a problem is modularized its possible to change one module without having a knowledge about the other modules and in the same way a change done to a module may not arises problems in other modules.

— Reduction of software cost by allowing modules to be designed and revised independently

Hierarchy

Hierarchy is a ranking or ordering of abstractions. Hierarchies in our design greatly simplify our understanding of the problem. There are two types of hierarchies. They are ‘is a hierarchy’ and ‘part of hierarchy’.

‘is a hierarchy’

In here Cat is an animal. Dog is an animal. Goat is an animal. Lion is an animal. All belong to the animal class.

‘part of hierarchy’

In here monitor is a part of the computer. Keyboard is a part of the computer. Mouse is a part of the computer. All the three components are in the computer itself and provide different parts of it.