Object Oriented Analysis and Design - OOAD

This ppt gives detailed description of Object Oriented Analysis and design.

1. Unit - 1

2. Abstraction-OOAD An abstraction denotes the essential characteristics of an object that distinguish it from all other kinds of objects, 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

3. 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 .

4. Class Hierarchy In Grady Booch’s words, “Hierarchy is the ranking or ordering of abstraction”. It uses the principle of “divide and conquer”. Hierarchy allows code reusability. The two types of hierarchies in OOA are −

5. “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.

6. “ 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.

7. Persistence 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.

8. Dynamic binding Static binding is a binding in which name can be associated with the class during compilation time , and it is also called as early Binding. Dynamic binding is a binding in which name can be associated with the class during execution time , and it is also called as Late Binding

9. Inheritance Inheritance is the property of object-oriented systems that allows objects to be built from other objects. Inheritance is a relationship between classes where one class is the parent class of another derived class called base class or super class.

10. Types of inheritance Dynamic inheritance. It allows objects to change and evolve over time. Since base classes provide properties and attributes for objects, changing base classes changes the properties and attributes of a class. .

11. Multiple inheritance. Some object-oriented systems permit a class to inherit its state (attributes) and behaviors form more than one super class

12. Polymorphism Polymorphism means that the same operation may behave differently on different classes. Polymorphism allows us to write generic, reusable code more easily, specify general instructions and delegate the implementation details to the objects involved.

13. Meta Classes If a class is an object, it must belong to a class which is called as meta-class or a class of classes. All the objects are instances of a class and all classes are instances of a meta-class. Meta-classes are used by the compiler.

14. Aggregations All objects except the most basic ones, are composed of and may contain other objects Ex : a spreadsheet is an object composed of cells, and cells are objects that may   contain text, mathematical formulas, etc.,

15. Aggregation – Attribute can be an object itself Ex : A car object is an agrregation of engine, seat, wheels and other objects

16. Object-oriented Systems Development Life Cycle The object-oriented life cycle model considers 'objects' as the basis of the software engineering process. The development team starts by observing and analyzing the system they intend to develop before defining the requirements. Once the process is over, they focus on identifying the objects of the system.

17. Advantages of Object-Oriented Life Cycle Model Since it is data-focused and easy to work with problem domains. It uses encapsulation and data hiding process that allows a developer to build tamper-proof systems. It enables software modularity, making it easier to manage and maintain complex software. It allows developers to create new modules using existing models, saving time and development cost of organizations.

18. The primary objectives of the Object-Oriented Model Object-oriented Analysis Object-oriented Design Object-oriented Implementation

19. SOFTWARE DEVELOPMENT PROCESS Process to change, refine, transform & add to existing product Transformation 1(analysis) - translates user’s need into system’s requirements & responsibilitiesthey use system can give insight into requirements, eg : analyzing incentive payroll - capacity must be included in requirements Transformation 2 (design) - begins with problem statement, ends with detailed design that can be transformed into operational system – bulk of development activity, include definition on how to build software, its development, its testing, design description + program + testing material Transformation 3 (implementation) - refines detailed design into system deployment that will satisfy users’needs takes account of equipment, procedures, resources, people, etc - how to embed software product within its operational environment, eg : new compensation method prg needs new form, gives new report.

20. Software Process – Transforming needs to Software Product

21. Waterfall Model The waterfall model is also called as  'Linear sequential model'  or  'Classic life cycle model'. In this model, each phase is fully completed before the beginning of the next phase. This model is used for the small projects. In this model, feedback is taken after each phase to ensure that the project is on the right path. Testing part starts only after the development is complete.

22. Advantages of waterfall model The waterfall model is simple and easy to understand, implement, and use. All the requirements are known at the beginning of the project, hence it is easy to manage. It avoids overlapping of phases because each phase is completed at once. This model works for small projects because the requirements are understood very well. This model is preferred for those projects where the quality is more important as compared to the cost of the project. Disadvantages of the waterfall model This model is not good for complex and object oriented projects. It is a poor model for long projects. The problems with this model are uncovered, until the software testing. The amount of risk is high.

23. Building high quality software Goal is user satisfaction   how do we determine system is ready for delivery   is it now an operational system that satisfies users’needs   is it correct and operating as we thought it should ?   Does it pass an evaluation process ?   Approaches to systems testing   Test according to   how it has been built   what it should do

24. 4 quality measures correspondence measures how well delivered system matches needs of operational environment, as described in original requirements statement validation task of predicting correspondence (true correspondence only determined after system is in place) correctness measures consistency of product requirements with respect to design specification v erification exercise of determining correctness (correctness objective => always possible to determine if product precisely satisfies requirements of specification)

25. Object-oriented approach: A use-case driven approach Object-oriented software development life cycle consists of Object-oriented analysis Object-oriented design Object-oriented implementation Use-case model can be employed throughout most activities of software development designs traceable across requirements, analysis, design, implementation & testing can be produced all design decisions can be traced back directly to user requirements usage scenarios can be test scenarios

26. Using Jacobson life cycle model – traceable design across develop

27. Activities   Object-oriented analysis - use case driven   Object-oriented design   Prototyping   Component-based development   Incremental testing

28. Object-oriented analysis - use-case driven Use Case , is a name for a scenario to describe the user–computer system interaction. Determine system requirements, identify classes & their relationship to other classes in domain To understand system requirements  need to identify the users or actors - who are the actors ? How do they use system ? Scenarios - Jacobson introduces concept of use case - scenario to describe user- computer system interaction

29. Usecase - Typical interaction between user & system that captures users’ goal & needs use cased modeling - expressing high level processes & interactions with customers in a scenario & analyzing it  developing use case is iterative - when use case model better understood & developed, start identifying classes & create their relationship Identifying objects - What are physical objects in system ? Documentation - 80-20 rule , 80% work can be done with 20% documentation modeling & documentation inseparatable - good modeling implies good documentation

30. Object-oriented Design  Goal : to design classes identified during analysis phase & user interface  Identify additional objects & classes that support implementation of requirements First, build object model based on objects & relationship Then iterate & refine model Design & refine classes Design & refine attributes Design & refine methods

31. Guidelines in Object-oriented Design Reuse rather than build new classes Know existing classes Design large number of simple classes rather than small number of complex classes Design methods  Critique what has been proposed Go back & refine classes

32. Prototyping   Prototype – version of software product developed in early stages of product’s life cycle for specific, experimental purposes Prototyping: old & new Before: prototype thrown away when industrial strength version developed New trend: ( eg. rapid application development) prototype refined into final product

33. Categories of Prototypes Horizontal prototype A Horizontal prototype displays the user interface for the product and gives a broader view of the entire system, without concentrating on internal functions. Simulation of interface (entire interface in full-featured system) Contain no functionality Vertical prototype  A Vertical prototype on the other side is a detailed elaboration of a specific function or a sub system in the product. Subset of system features with complete functionality Few implemented functions can be tested in great depth Hybrid prototypes Major portions of interface established, features having high degree of risk are prototyped with more functionality

34. Analysis prototype Aid in exploring problem domain, used to inform user & demonstrate proof of concept Not used as basis of development, discarded when it has serve purpose Final product use prototype concepts, not code Domain prototype Aid for incremental development of the ultimate software solution Often used as tool for staged delivery of subsystems to users/other members of development team Demonstrate the feasibility of implementation Eventually evolve into deliverable product

35. Implementation - Component-based development   Industrialized approach to system development, move form custom development to assembly of pre-built, pre-tested, reusable software components that operate with each other Components themselves can be constructed from other components, down to prebuilt components/old-fashioned code written in prg languages like C Less development effort, faster, increase flexibility

36. Rapid Application Development (RAD)  Set of tools & techniques to build application faster than typically possible with traditional methods Often used with software prototyping Iterational development  Begins when design completed Do we actually understood problem (analysis) ? Does the system do what it is supposed to do (design) ? Make improvement in each iteration

37. Reusability   Major benefit of Object-oriented approach For objects to be reusable, much effort must be spent of designing it – Design reusability Effectively evaluate existing software components Has my problem been solved ? Has my problem been partially solved ? What has been done before to solve problem similar to this one ? Need - detailed summary info about existing software components

38. Reuse Strategy   Information hiding Conformance to naming standards Creation & administration of an object repository Encouragement by strategic management of reuse as opposed to constant redevelopment Establish target for % of object in project to be reuse

39. Identity The identity provides a mechanism for referring to such parts of the object that are not exposed in the interface. Thus, identity is the basis for polymorphism in object-oriented programming. Object identity is a property of data that is created in the context of an object data model, where an object is assigned a unique internal object identifier, or oid . For example, the fridge can not become the T.V.

40. Identity The identity of an object makes it unique. You can use the unique identity of an object to differentiate between multiple instances of a class if each instance has the same state. Identity allows comparison of references. Two references can be compared whether they are equal or not.

41. UML Diagrams A UML diagram is a diagram based on the UML (Unified Modeling Language) with the purpose of visually representing a system along with its main actors, roles, actions, artifacts or classes, in order to better understand, alter, maintain, or document information about the system.

42. Use Case Diagram Actor – Person Organization Another System External Device Types Primary Actors – Initiates the use of the system Secondary Actors – Reactionary Use Case – Represents an action accomplishes some sort of task within the system. -> Login -> Transfer funds -> Check Balance -> Make Payment

43. Relationship Association – Basic Communication Include – Base use case , Included use case Extend – Base use case, Extend use case Generalization