Benefits of the Object-Oriented Development 1. Exploits the expressive power of the object-oriented programming languages. 2.

Encourages the re-use of software components. 3. Leads to systems that are more resilient to changes. 4. Reduces development risk. 5. Reduction in development time and the size of the resulting source code. 6. Appeals to the working of human cognition. Risks of Object-Oriented Development There could be Performance Risks and Start-up Cost Risks. Performance Risks: There is a performance cost for sending a message from one object to another. A call to another function has an overhead on the run-time to handle stack management activities. Inheritance hierarchies can also add to the performance cost of an object-oriented system. Every time an object of a derived class is created, the constructor of that class and all its base classes are called. Thus, if the inheritance structure is very deep or very wide, there can be a significant drop in the performance. Polymorphism adds further to the performance cost of a system. Dynamic lookup that is required to determine the method defined for the class of the receiving object can take significantly longer time than a simple, statically bound function call. Often object-oriented system is defined in a manner whose components are built in layers of abstraction. On the positive side, such layering helps in the comprehending a complex system. It may be impossible ever to get a complex system working without starting with a layered design. On the negative side, sometimes methods must be written to gain protected access to the otherwise encapsulated fields of an object. This plethora of methods means that we can end up with a glut of method invocations. Invoking a method at a high level of abstraction usually results in a cascade of methods invocations involving lower levels.

Another source of performance bottlenecks is due to the paging behaviour of running applications. Most compilers allocate object code in segments, with the code for each compilation unit (usually a single file) placed in one or more segments. If an operating system funds physical memory bottlenecks and uses the virtual memory concept, then it may result in a higher number of page swapping activities, as most of the function calls in object-oriented applications are across source file boundaries. Dynamic allocation and destruction of objects also contributes to performance costs. Allocating an object on a heap is a dynamic action as opposed to statically allocating an object either globally or on a stack frame. For time-critical applications, the cycles needed for completing a heap allocation may be too costly. A commonly used solution to this problem is to pre-allocate such objects during elaboration of the program. Start-up Cost Risks: Using the object-oriented technology for the first time requires capitalization of the software development tools. If an organization is using a particular object-oriented language for the first time, they usually have no established base of domain-specific software to re-use. A first attempt to use the object technology is usually a failure without the appropriate knowledge and training. An object-oriented language is not just another programming language that can be mastered in a short time period. The mindset shift for object-oriented design may take a long time in most cases.

Basic activities of OOAD:

Object oriented analysis: Analysis is the first stage of the development process. It is also the first step in producing high-performance software. Analysis is central to the performance tuning process. The analysis part having these below steps

OOA process consists of the following steps:

Identify the actors Develop a simple business process model using UML Activity diagram Develop the usecase Develop interaction diagrams Identify classes

Steps involved in OOA process: 1. Actors identification 2. Using UML activity diagram develop a simple business process 3. Develop the use case 4. Prepare interaction diagram 5. Classification-develop static UML class diagram 6. Iterate and refine

The BOOCH Methodology

1. The Booch methodology is a widely used object-oriented method that helps you design your system using the object paradigm. 2. It covers the analysis and design phases of an object-oriented system. 3. Booch sometimes is criticized for his large set of symbols. 4. The Booch method consists of the following diagrams:

1. 2. 3. 4. 5. 6.

Class diagrams Object diagrams State transition diagrams Module diagrams Process diagrams Interaction diagrams

The Booch methodology prescribes a macro development process and a micro development process. 1.The Macro Development Process The macro process serves as a controlling framework for the micro process and can take weeks or even months. The primary concern of the macro process is technical management of the system. Such management is interested less in the actual object-oriented design than in how well the project corresponds to the requirements set for it and whether it is produced on time. The macro development process consists of the following steps: 1. Conceptualization 2. Analysis and developenent of the model 3. Design or create the system architecture 4. Evolution or implementation 5. Maintenance 2.The Micro Developenent Process The micro process is a description of the day-to-day activities by a single or small group of software developers. The micro developenent process consists of the following steps: 1.Identify class and objects 2.Identify class and objects semantics 3.Identify class and object relationships 4.Identify class and object interfaces and implementation.

Algorithmic Decomposition Versus ObjectOriented Decomposition

Decomposition in computer science, also known as factoring, refers to the process by which a complex problem or system is broken down into parts that are easier to conceive, understand, program, and maintain.

In structured programming, algorithmic decomposition breaks a process down into welldefined steps. Object-oriented decomposition, on the other hand, breaks a large system down into progressively smaller classes or objects that are responsible for some part of the problem domain. According to Booch, algorithmic decomposition is a necessary part of object-oriented analysis and design,

1. Traditional programming techniques have used algorithmic decomposition. 2. Algorithmic or functional decomposition views software as a process.

3. It decomposes the software into modules that represents steps of a process. 4. These modules are implemented by language constructs such as functions in C. The data structures required to implement the program are a secondary concern, which is addressed after the project has been decomposed into functional modules. 1. 2. Object-oriented decomposition views software as a set of well-defined objects that model entities in the application domain. 3. These objects interact with each other to form a software system. 4. Functional decomposition is addressed after the system has been decomposed into objects. 5. An object is an entity that performs computations and has a local state. It may therefore be viewed as a combination of data and procedural elements. Object-oriented approach is a method of implementation in which 1) 2) Objects Each object are is an the instance fundamental of some building type or blocks. class.

3) Classes are related to each other by inheritance relationships. The principal advantage of object-oriented decomposition is that it encourages the reuse of software. This results in flexible software systems that can evolve as system requirements change. It allows a programmer to use object-oriented programming languages effectively. Object-oriented decomposition is also more intuitive than algorithm-oriented decomposition because objects naturally model entities in the application domain. Object-oriented design is a design strategy where system designers think in terms of things instead of operations or functions. The executing system is made up of interacting objects that maintain their own local state and provide operations on that state information. They hide information about the representation of the state and hence limit access to it. An object-oriented design process involves designing the object classes and the relationships between these classes. When the design is realised as an executing program, the required objects are created dynamically using the class definitions. Object-oriented systems should be maintainable as the objects are independent. They may be understood and modified as stand-alone entities. Changing the implementation of an object or adding services should not affect other system objects. Because objects are associated with things, there is often a clear mapping between real-world entities (such as hardware components) and their controlling objects in the system. This improves the understandability and hence the maintainability of the design. The two approaches are similar in that both believe that the way to develop a complex system is by using the philosophy of divide-and-conquer; that is break up a complex software design project into a number of simpler subprojects, and then tackle these subprojects individually. The two approaches disagree on how a project should be decomposed.

Create User Satisfaction for Bank system application

Steps: 1. Develop test objectives. 2. Develop test cases. 3. Analyze the tests. 1. Develop test objectives 1. Test objectives are based on the requirements, use cases, or convert or desired system usage. 2. Ease of use is the most important requirement. Objectives to test usability of Via. Net bank ATM kiosk and its Via: 95% of users should be able to find out how to withdraw money from the ATM machine without error (or) any format training. 90% of consumers should be able to operate the ATM within 90 seconds. 1. Develop Test Cases: Test cases for usability testing are slightly different from test cases for quality assurance. We are not testing the input and expected output. But how users interact in value system. The usability test scenarios are based on the following use cases. 1. 2. 3. 4. 5. 6. Deposit chewing Withdraw chewing Deposit chewing Withdraw savings Saving transaction himself Checking transaction himself

Start by explaining the testing process and equipment to the participants to ease the pressure. As the participants work, second the time they take to perform a task as well as any problems they encounter. Once the test subjects complete their tasks, conduct a user satisfaction test to measure their level of satisfaction with the kiosk. The users use cases and test object should provide the attributes to be included in the test. The following attributes can play a certain role because ease of use is the main issue of user interface. 1. 2. 3. 4. 5. 6. Easy to operate Burrows are easily located. It is efficient It is visually pleasing Provides easy recovery from error. Analyze the Tests:

The final step is to analyze the tasks and document the test results. We also need to analyze the results of user satisfaction tasks. The user satisfaction test can be used as tool for finding out attributes are important or unimportant. An Example: In withdrawal checking, in adding to entering the amount for withdrawal, we are able to select from the list of predefined values say $20, $40, etc. This would speed up the process at the ATM Kiosk.

OBJECT ORIENTED DATA BASES The object oriented database management system is a combination of object oriented programming and database technology to provide what we now call object oriented databases. Additionally, object oriented databases allow all the benefits of an object orientation as well as the ability to have a strong equivalence with object-oriented programs, an equivalence that would be lost if an alternative were chosen, as with a purely relational database. By combining object-oriented programming with database

technology, we have an integrated application development system, a significant characteristics of object-oriented database technology. Many advantages accrue from including the definition of operations with the definition of data. First, the defined operations apply universally and are not dependent on the particular database application running at the moment. Second , the data types can be extended to support complex data such as multimedia by defining new object classes that have operations to support the new kinds of information. The object-oriented database system described the necessary characteristics that a system must satisfy to be considered an object-oriented database. These categories can be broadly divided into object-oriented language properties and database requirements. First, the rules that make it an object-oriented system are as follows 1. The system must support complex objects. A system must provide simple atomic types of objects(integers, characters, etc) from which complex objects can be built by applying constructors to atomic objects or other complex objects or both. 2. Object identity must be supported. A data object must have an identity and existence independent of its values. 3. Objects must be encapsulated. An object must encapsulate both a program and its data. Encapsulation embodies the separation of interface and implementation and the need for modularity. 4. The system must support types or classes. The system must support (embodied by smalltalk). 5. The system must support inheritance. Classes and types can participate in a class hierarchy. The primary advantage of inheritance is that it factors out shared code and interfaces. 6. The system must avoid premature binding. either the type concept(embodied by c++) or the class concept

This feature also known as late binding or dynamic binding. Since classes and types support encapsulation and inheritance, the system must resolve conflicts in operation names at run time. 7. The system must be computationally complete. Any computable function should be expressible in the data manipulation language(DML) of the system, thereby allowing expression of any type of operation. 8. The system must be extensible. The user of the system should be able to create new types that have equal status to the systems predefined types. Second, these rules make it a DBMS: 9. It must be persistent, able to remember an object state. The system must allow the programmer to have data survive beyond the execution of the creating process for it to be reused in another process. 10 It must be able to manage very large databases.

The system must efficiently manage access to the secondary storage and provide performance features, such as indexing, clustering, buffering, and query optimization.
11. It must accept concurrent users. The system must allow multiple concurrent users and support the notions of atomic, serializable transactions. 12. It must be able to recover from hardware and software failures. The system must be able to recover from software and hardware failures and return to a coherent state. 13. Data query must be simple The system must provide some high-level mechanism for ad-hoc browsing of the contents of the database.

The major benefits of using ODBMS include:

1. The objects as such can be stored in the database(often the operations are not stored, but are only present in the class library in the primary memory). 2. No conversion is needed for the DBMS type system, the user defined classes are used as types in the DBMS. 3. The language of the DBMS can be integrated with an object-oriented programming language.

Association:

Abstraction: Abstraction provides a well-defined conceptual boundary relative to the perspective of the viewer. When we define abstract data, we identify their essential characteristics. All other characteristics are unimportant. There are different types of abstraction: Entity abstraction: The object presents a useful model of an entity in the problem-domain Action abstraction: The object provides a generalised set of operations, all of which perform the same kind of function. Virtual machine abstraction: The object groups together operations that are all used by some superior level of control Coincidental abstraction: The object packages operations that have no relation to each other. Entity abstraction is considered to be the best form of abstraction as it groups together the data and operations concerning an entity. For example, an object called salaried_employee could contain operations like compute_income_tax, compute_pf, etc. Thus information about an entity is localized. One often faces the question as to how to identify useful objects from a problem specification. The answer is look for nouns in the specification. They

represent 'things' or entities. This leads to entity abstraction.

Encapsulation:
While abstraction helps one to focus on the essential characteristics of an object, encapsulation enables one to expose only those details that are necessary to effectively use the object. This is achieved through information hiding and "need to know" principle. One could declare some of the variables and methods of the object as private and the rest public. Only public variables and methods will be accessible by other objects. By carefully selecting what is available to the outside world, the developer can prevent illegal use of objects. For example, consider a class called Person with an operation like 'compute_income_tax'. Details of a person's income are not essential to a viewer of this class. Only the ability to compute the income-tax for each object is essential. Hence the data members of the class can be declared private, while 'compute_income_tax' can be public.

Modularity: Modularity creates a number of well-defined, documented boundaries within a system. A module typically clusters logically related abstractions. This is invaluable in understanding a system. Each module can be compiled separately, but has connections with other modules. Connections between modules are the assumptions which modules make about each other. Ideally, a module should be a single syntactic construct in the programming language.

Hierarchy:

Hierarchy is a ranking or ordering of abstractions. The important hierarchies in an OO system are: The class structure hierarchy The object structure hierarchy A class structure hierarchy is used for sharing of behaviour and sharing of code between different classes of entities which have some features in common. This is achieved through inheritance. It is called the 'is a' hierarchy. Features that are common to many classes are migrated to a common class, called base-class, (or super-class, or parentclass). Other classes may add, modify, or even hide some of these features. These are called derived-classes, (or sub-classes, or child-classes). For example, vehicle can be a base-class and two-wheeler, three-wheeler, and fourwheeler can be derived classes. There is also a possibility of inheriting from more than one class. This is called multiple inheritance. For example, a two-in-one inherits the features of a radio and a tape-recorder. However, it can raise the following complications: Possibility of name clashes Repeated inheritance from two peer super-classes The object structure hierarchy is also called 'part of' hierarchy. It is implemented through aggregation, that is one object becomes a part of another object. Aggregation permits grouping of logically related structures. It is not unique to object oriented systems. For example, in C a structure can be used to group logically related data elements and

structures. In OO context, a vehicle consists of many parts like engine, wheels, chasis, etc. Hence it can be represented as an aggregation of many parts.

The Rumbaugh method 1. it a very friendly and easy methodology. 2. For traditional system analyst's, the Rumbaugh's methodology is the closest to the traditional approach to system analysis and design, and beginners will recognize familiar symbols and techniques. 3. The Rumbaugh methodology has its primary strength in object analysis but it also does an excellent job with object design. 4. Rumbaugh has three deliverables to the object analysis phase; the Object model, the Dynamic model, and the functional model. These three models are similar to traditional system analysis, with the additions for the object model, including definitions of classes along with the classes variables and behaviors. 5. The Rumbaugh object model is very much like an entity relationship diagram except that there are now behaviors in the diagram and class hierarchies. 6. The dynamic model is a "state transition" diagram that shows how an entity changes from one state to another state. 7. The functional model is the equivalent of the familiar data flow diagrams from a traditional systems analysis. The Booch method 1. Booch's methodology has its primary strength in the object system design. 2. Grady Booch has included in his methodology a requirements analysis that is similar to a traditional requirements analysis, as well as a domain analysis phase. 3. Booch's object system design method has four parts, the logical structure design where the class hierarchies are defined, the physical structure diagram where the object methods are described. In addition, Booch defines the dynamics of classes in a fashion very similar to the Rumbaugh method, as well as an analysis of the dynamics of object instances, where he describes how an object may change state. The Coad-Yourdon method Coad-Yourdon methodology has its primary strength in system analysis. Their methodology is based on a technique called "SOSAS", which stands for the five steps that help make up the analysis part of their methodology. The first step in system analysis is called "Subjects", which are basically data flow diagrams for objects. The second step is called "Objects", where they identify the object classes and the class hierarchies. The third step is called "Structures", where they decompose structures into two types, classification structures and composition structures. Classification structures handle the inheritance connection between related classes, while composition structures handle all of the other connections among classes. The next step in analysis is called "Attributes", and the final step is called "Services", where all of the behaviors or methods for each class are identified.

Following analysis, Coad and Yourdon define four parts that make up the design part of their methodology. The steps of system design are:

The problem domain component - This will define the classes that should be in the problem domain. The human interaction component - These steps defines the interface classes between objects. The task management component - This is where system-wide management classes are identified. The data management component - This design step identifies the classes needed for database access methods.

The Shlaer-Mellor method Shlaer-Mellor methodology has its primary strength in system design and is considered somewhat weak on analysis. The Shlaer-Mellor methodology includes three models; the information model, the state model, and the process model. The information model contains objects, variables, and all the relationships between the objects, and is basically a data model for the system. The state model records the different states of objects and changes that can occur between the objects. The process model is really not much more than a traditional data flow diagram. Now that we have covered the basics of the object approach, let's take a look at how a real-world object is created by using these techniques.