Category: object Oriented Analysis Design

OOAD – Object Oriented Principles ”; Previous Next Principles of Object-Oriented Systems The conceptual framework of object–oriented systems is based upon the object model. There are two categories of elements in an object-oriented system − Major Elements − By major, it is meant that if a model does not have any one of these elements, it ceases to be object oriented. The four major elements are − Abstraction Encapsulation Modularity Hierarchy Minor Elements − By minor, it is meant that these elements are useful, but not indispensable part of the object model. The three minor elements are − Typing Concurrency Persistence Abstraction Abstraction means to focus on the essential features of an element or object in OOP, ignoring its extraneous or accidental properties. The essential features are relative to the context in which the object is being used. Grady Booch has defined abstraction as follows − “An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects and thus provide crisply defined conceptual boundaries, relative to the perspective of the viewer.” Example − When a class Student is designed, the attributes enrolment_number, name, course, and address are included while characteristics like pulse_rate and size_of_shoe are eliminated, since they are irrelevant in the perspective of the educational institution. Encapsulation Encapsulation is the process of binding both attributes and methods together within a class. Through encapsulation, the internal details of a class can be hidden from outside. The class has methods that provide user interfaces by which the services provided by the class may be used. Modularity Modularity is the process of decomposing a problem (program) into a set of modules so as to reduce the overall complexity of the problem. Booch has defined modularity as − “Modularity is the property of a system that has been decomposed into a set of cohesive and loosely coupled modules.” Modularity is intrinsically linked with encapsulation. Modularity can be visualized as a way of mapping encapsulated abstractions into real, physical modules having high cohesion within the modules and their inter–module interaction or coupling is low. Hierarchy In Grady Booch’s words, “Hierarchy is the ranking or ordering of abstraction”. Through hierarchy, a system can be made up of interrelated subsystems, which can have their own subsystems and so on until the smallest level components are reached. It uses the principle of “divide and conquer”. Hierarchy allows code reusability. The two types of hierarchies in OOA are − “IS–A” hierarchy − It defines the hierarchical relationship in inheritance, whereby from a super-class, a number of subclasses may be derived which may again have subclasses and so on. For example, if we derive a class Rose from a class Flower, we can say that a rose “is–a” flower. “PART–OF” hierarchy − It defines the hierarchical relationship in aggregation by which a class may be composed of other classes. For example, a flower is composed of sepals, petals, stamens, and carpel. It can be said that a petal is a “part–of” flower. Typing According to the theories of abstract data type, a type is a characterization of a set of elements. In OOP, a class is visualized as a type having properties distinct from any other types. Typing is the enforcement of the notion that an object is an instance of a single class or type. It also enforces that objects of different types may not be generally interchanged; and can be interchanged only in a very restricted manner if absolutely required to do so. The two types of typing are − Strong Typing − Here, the operation on an object is checked at the time of compilation, as in the programming language Eiffel. Weak Typing − Here, messages may be sent to any class. The operation is checked only at the time of execution, as in the programming language Smalltalk. Concurrency Concurrency in operating systems allows performing multiple tasks or processes simultaneously. When a single process exists in a system, it is said that there is a single thread of control. However, most systems have multiple threads, some active, some waiting for CPU, some suspended, and some terminated. Systems with multiple CPUs inherently permit concurrent threads of control; but systems running on a single CPU use appropriate algorithms to give equitable CPU time to the threads so as to enable concurrency. In an object-oriented environment, there are active and inactive objects. The active objects have independent threads of control that can execute concurrently with threads of other objects. The active objects synchronize with one another as well as with purely sequential objects. Persistence An object occupies a memory space and exists for a particular period of time. In traditional programming, the lifespan of an object was typically the lifespan of the execution of the program that created it. In files or databases, the object lifespan is longer than the duration of the process creating the object. This property by which an object continues to exist even after its creator ceases to exist is known as persistence. Print Page Previous Next Advertisements ”;

OOAD – Testing & Quality Assurance ”; Previous Next Once a program code is written, it must be tested to detect and subsequently handle all errors in it. A number of schemes are used for testing purposes. Another important aspect is the fitness of purpose of a program that ascertains whether the program serves the purpose which it aims for. The fitness defines the software quality. Testing Object-Oriented Systems Testing is a continuous activity during software development. In object-oriented systems, testing encompasses three levels, namely, unit testing, subsystem testing, and system testing. Unit Testing In unit testing, the individual classes are tested. It is seen whether the class attributes are implemented as per design and whether the methods and the interfaces are error-free. Unit testing is the responsibility of the application engineer who implements the structure. Subsystem Testing This involves testing a particular module or a subsystem and is the responsibility of the subsystem lead. It involves testing the associations within the subsystem as well as the interaction of the subsystem with the outside. Subsystem tests can be used as regression tests for each newly released version of the subsystem. System Testing System testing involves testing the system as a whole and is the responsibility of the quality-assurance team. The team often uses system tests as regression tests when assembling new releases. Object-Oriented Testing Techniques Grey Box Testing The different types of test cases that can be designed for testing object-oriented programs are called grey box test cases. Some of the important types of grey box testing are − State model based testing − This encompasses state coverage, state transition coverage, and state transition path coverage. Use case based testing − Each scenario in each use case is tested. Class diagram based testing − Each class, derived class, associations, and aggregations are tested. Sequence diagram based testing − The methods in the messages in the sequence diagrams are tested. Techniques for Subsystem Testing The two main approaches of subsystem testing are − Thread based testing − All classes that are needed to realize a single use case in a subsystem are integrated and tested. Use based testing − The interfaces and services of the modules at each level of hierarchy are tested. Testing starts from the individual classes to the small modules comprising of classes, gradually to larger modules, and finally all the major subsystems. Categories of System Testing Alpha testing − This is carried out by the testing team within the organization that develops software. Beta testing − This is carried out by select group of co-operating customers. Acceptance testing − This is carried out by the customer before accepting the deliverables. Software Quality Assurance Software Quality Schulmeyer and McManus have defined software quality as “the fitness for use of the total software product”. A good quality software does exactly what it is supposed to do and is interpreted in terms of satisfaction of the requirement specification laid down by the user. Quality Assurance Software quality assurance is a methodology that determines the extent to which a software product is fit for use. The activities that are included for determining software quality are − Auditing Development of standards and guidelines Production of reports Review of quality system Quality Factors Correctness − Correctness determines whether the software requirements are appropriately met. Usability − Usability determines whether the software can be used by different categories of users (beginners, non-technical, and experts). Portability − Portability determines whether the software can operate in different platforms with different hardware devices. Maintainability − Maintainability determines the ease at which errors can be corrected and modules can be updated. Reusability − Reusability determines whether the modules and classes can be reused for developing other software products. Object-Oriented Metrics Metrics can be broadly classified into three categories: project metrics, product metrics, and process metrics. Project Metrics Project Metrics enable a software project manager to assess the status and performance of an ongoing project. The following metrics are appropriate for object-oriented software projects − Number of scenario scripts Number of key classes Number of support classes Number of subsystems Product Metrics Product metrics measure the characteristics of the software product that has been developed. The product metrics suitable for object-oriented systems are − Methods per Class − It determines the complexity of a class. If all the methods of a class are assumed to be equally complex, then a class with more methods is more complex and thus more susceptible to errors. Inheritance Structure − Systems with several small inheritance lattices are more well–structured than systems with a single large inheritance lattice. As a thumb rule, an inheritance tree should not have more than 7 (± 2) number of levels and the tree should be balanced. Coupling and Cohesion − Modules having low coupling and high cohesion are considered to be better designed, as they permit greater reusability and maintainability. Response for a Class − It measures the efficiency of the methods that are called by the instances of the class. Process Metrics Process metrics help in measuring how a process is performing. They are collected over all projects over long periods of time. They are used as indicators for long-term software process improvements. Some process metrics are − Number of KLOC (Kilo Lines of Code) Defect removal efficiency Average number of failures detected during testing Number of latent defects per KLOC Print Page Previous Next Advertisements ”;

Object Oriented Analysis & Design Tutorial PDF Version Quick Guide Resources Job Search Discussion This tutorial will help you understand the basics of object-oriented analysis and design along with its associated terminologies. Audience This tutorial has been designed to help beginners. After completing this tutorial, you will find yourself at a moderate level of expertise from where you can take yourself to next levels. Prerequisites Before you start proceeding with this tutorial, it is assumed that you have basic understanding of computer programming and related programming paradigms. Print Page Previous Next Advertisements ”;