Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide


  1. 1. Object Oriented Analysis & Design 3/27/2014 1
  2. 2. Syllabus • Two views of software Developments: • SSAD and OOAD. • Why Object –Orientation? 3/27/2014 2
  3. 3. Systems development life cycle (SDLC) • SDLC: process of building, deploying, using, and updating an information system Plan Develop Use & Maintain 3/27/2014 3
  4. 4. System development methodology • SD Methodlogy – Guidelines for developing system. – Kind of knowledge. • Two kinds of methodologies – Structured (since 1970s) – Newer, rapid development 3/27/2014 4
  5. 5. Structured methodology Also called “Waterfall” methodology INSTALLATION, TESTING 3/27/2014 5
  6. 6. Waterfall Model – from ‘what’ to ‘use’ 3/27/2014 6
  7. 7. Software Development Process 7 Requirement Specification System Analysis System Design Testing Implementation Maintenance Deployment 3/27/2014
  8. 8. Requirement Specification 8 Requirement Specification System Analysis System Design Testing Implementation Maintenance Deployment A formal process that seeks to understand the problem and document in detail what the software system needs to do. This phase involves close interaction between users and designers. Most of the examples in this book are simple, and their requirements are clearly stated. In the real world, however, problems are not well defined. You need to study a problem carefully to identify its requirements.3/27/2014
  9. 9. System Analysis 9 Requirement Specification System Analysis System Design Testing Implementation Maintenance Deployment Seeks to analyze the business process in terms of data flow, and to identify the system’s input and output. Part of the analysis entails modeling the system’s behavior. The model is intended to capture the essential elements of the system and to define services to the system. 3/27/2014
  10. 10. System Design 10 Requirement Specification System Analysis System Design Testing Implementation Maintenance Deployment The process of designing the system’s components. This phase involves the use of many levels of abstraction to decompose the problem into manageable components, identify classes and interfaces, and establish relationships among the classes and interfaces.3/27/2014
  11. 11. Implementation 11 Requirement Specification System Analysis System Design Testing Implementation Maintenance Deployment The process of translating the system design into programs. Separate programs are written for each component and put to work together. This phase requires the use of a programming language like Java. The implementation involves coding, testing, and debugging. 3/27/2014
  12. 12. Testing 12 Requirement Specification System Analysis System Design Testing Implementation Maintenance Deployment Ensures that the code meets the requirements specification and weeds out bugs. An independent team of software engineers not involved in the design and implementation of the project usually conducts such testing. 3/27/2014
  13. 13. Deployment 13 Requirement Specification System Analysis System Design Testing Implementation Maintenance Deployment Deployment makes the project available for use. For a Java applet, this means installing it on a Web server; for a Java application, installing it on the client's computer. 3/27/2014
  14. 14. Relationships among Classes • Association • Aggregation • Composition • Inheritance 143/27/2014
  15. 15. Association Association represents a general binary relationship that describes an activity between two classes. 15 Student *5..60 Take Teach 0..3 1 Teacher FacultyCourse An association is usually represented as a data field in the class. 3/27/2014
  16. 16. Association Between Same Class Association may exist between objects of the same class. For example, a person may have a supervisor. 16 Person Supervisor 1 1 3/27/2014
  17. 17. Aggregation and Composition Aggregation is a special form of association, which represents an ownership relationship between two classes. Aggregation models the has-a relationship. If an object is exclusively owned by an aggregated object, the relationship between the object and its aggregated object is referred to as composition. 17 Name AddressPerson Composition Aggregation 3/27/2014
  18. 18. 3/27/2014 18 Aggregation and Composition
  19. 19. 3/27/2014 19 Aggregation and Composition
  20. 20. 3/27/2014 20 Aggregation and Composition
  21. 21. 3/27/2014 21 Aggregation and Composition
  22. 22. 3/27/2014 22 What is a navigable association in UML? Associations are relationships between classes in a UML Class Diagram. They are represented by a solid line between classes. Associations are typically named using a verb or verb phrase which reflects the real world problem domain. The normal kind of association is bidirectional by default. This means that if an association exists between two classes, then both objects know about each other. However, when creating a class diagram it is possible to use a navigable association between two classes. This is shown by adding an arrowhead at one end of the association.
  23. 23. 3/27/2014 23 What is a navigable association in UML? If “A” is the source class and “B” is the target class, the arrowhead would be placed on the “B” side of the association. A navigable association of this type means that at runtime object “A” knows about object “B”, but object “B” has no knowledge of or visibility into object “A”.
  24. 24. 3/27/2014 24 What is a navigable association in UML?
  25. 25. 3/27/2014 25 What is a navigable association in UML?
  26. 26. 3/27/2014 26 What is a navigable association in UML? StaffMember Student 1..* *instructs instructor Association name Role name Multiplicity Navigable (uni-directional) association Courses pre - requisites 0..3 Reflexive association Role *
  27. 27. Inheritance Inheritance models the is-an-extension-of relationship between two classes. 27 Person Faculty public class Faculty extends Person { /** Data fields */ /** Constructors */ /** Methods */ } (A) (B) 3/27/2014
  28. 28. Objects • An object is an individual unit which is used as the basic building block of programs. The term object is also used to refer to any "thing". • Each object is capable of receiving messages, processing data, and sending messages to other objects. • Each object can be viewed as an independent little machine or actor with a distinct role or responsibility. 283/27/2014
  29. 29. Object – key concept • Object: Thing (data structure) with data (attributes) and methods (behaviors, processes, operations) • Object “encapsulates” data and processes • Examples of objects – Problem domain objects (student, customer) – User interface (buttons, text boxes) 3/27/2014 29
  30. 30. Object examples  Objects are associated and interact via messages. 3/27/2014 30
  31. 31. Classes • Classes are used to group related variables and functions. • A class specifies the structure of data which contains methods (functions) which manipulate the data of the object and perform tasks. A method is a function with a special property that it has access to data stored in an object. • A class is the most specific type of an object in relation to a specific layer. A class may also have a representation (meta-object) at run-time, which provides run-time support for manipulating the class- related metadata. 313/27/2014
  32. 32. Class • Class: Defines what all objects of a class represent • Objects are instances of a class (Customer object is an instance of a customer class) Name Attributes Operations Object – An instance of class with specified Values of Attributes (specific data) 12005 09/10/2003 16/10/2003 Class 3/27/2014 32
  33. 33. Inheritance & Specialization/Generalization  Inheritance: Property of OO systems allowing for attributes and methods to be shared among objects.  Inheritance enables a special association between classes called Specialization/Generalization 3/27/2014 33
  34. 34. Inheritance & Specialization/ Generalization (Cont.) 34 of 13 • Specialization: Subclasses inherit attributes and operations of the super- class, plus have some of their own. • Subclasses “specialize” the super-class. • Generalization represented by arrows from subclasses to super- class. • Class “generalizes” attributes & methods of sub-classes. 3/27/2014
  35. 35. Each type of vehicle has its own version of calcPrice() Message: ”Calculate price” Inheritance and Polymorphism • Polymorphism: Ability for dissimilar objects to respond to the same message in different ways. 3/27/2014 35
  36. 36. Ex. Inheritance for graphic figures: Each subclass inherits the attributes, operations, and associations of its superclasses Figure Color center Position penThickness penType Move Select Rotate display Diagram name ZeroDimensional OneDimensional orientation scale TwoDimension al Orientation fillType Scale fill Point display Line endPoints display Arc Radius startAngle arcAngle display Spline controlPts display Polygon numOfSides vertices display Circle diameter Display rotate Radius startAngle arcAngle display Arc Radius startAngle arcAngle display Arc Radius startAngle arcAngle display Arc Radius startAngle arcAngle display Arc Radius startAngle arcAngle display 1 * dimensionality 3/27/2014 36
  37. 37. Specialization (EER – ENHANCED OR EXTENDED ENTITY RELATIONSHIP) 3/27/2014 37
  38. 38. • Generalization is the reverse of the specialization process • Several classes with common features are generalized into a super-class; – original classes become its subclasses • Example: CAR, TRUCK generalized into VEHICLE; – both CAR, TRUCK become subclasses of the super-class VEHICLE. – We can view {CAR, TRUCK} as a specialization of VEHICLE – Alternatively, we can view VEHICLE as a generalization of CAR and TRUCK Generalization 3/27/2014 38
  39. 39. Generalization 3/27/2014 39
  40. 40. Generalization 3/27/2014 40
  41. 41. Specialization 3/27/2014 41
  42. 42. Object Oriented Development • The process of converting a problem specification into an object oriented program is called as object oriented development. • This program consists of a group of objects which communicates with one another. • These objects can be created or destroyed while the programs execution as per the need. 423/27/2014
  43. 43. Problems in Shifting from the Traditional Approach to Object Oriented Development are : • Initially, the whole process becomes very tedious because – OO S/W must coexist with the legacy s/w. Stored data is in relational databases & now it must be converted into objects.  Initially, we do not get experienced people to work with. The staff needs proper training to understand & employ the OO development & infrastructure. 433/27/2014
  44. 44. Contd.  Project Management is pervaded (spread) As the project leaders are not well Knowledgeable with the new technology, architectural flaws cannot be detected in the early stages  Estimation & planning also fails up to some extent. As most of the estimation models rely upon the previous data, so a level of mismanagement occurs. 443/27/2014