1 / 265

MCS-032 Object Oriented Analysis & Design

MCS-032 Object Oriented Analysis & Design. Block -1 Object Oriented Modeling and UML. Object Orientation. What Is Object Orientation Advantages of Object Orientation Elements of Object Model What is UML Goals Of UML Systems Phases In System Development. 3.

patrick-riley
Download Presentation

MCS-032 Object Oriented Analysis & Design

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. MCS-032Object Oriented Analysis & Design

  2. Block -1 • Object Oriented Modeling and UML

  3. Object Orientation • What Is Object Orientation • Advantages of Object Orientation • Elements of Object Model • What is UML • Goals Of UML • Systems • Phases In System Development 3 Presentation Title | July 27, 2010 | <document classification>

  4. Object Orientation • Object orientation is a method for organizing systems as collections of interacting objects that combine data as well as behavior.

  5. Object Orientation • When models are constructed using object orientation in a proper way, they become easy to communicate, change, expand and validate.

  6. Object Orientation • The object oriented paradigm focuses on real world concepts rather than realization constructs.

  7. Advantages of Object Orientation • Data Abstraction • Compatibility • Flexibility • Reuse • Extensibility • Maintenance 7 Presentation Title | July 27, 2010 | <document classification>

  8. Elements of Object Model • Abstraction • Giving necessarily details only. • Encapsulation • Hiding unnecessarily details • Modularity • Decomposition into a set of cohesive and loosely coupled modules. • Hierarchy • Ranking or an ordering of abstractions. 8 Presentation Title | July 27, 2010 | <document classification>

  9. Class Diagram • Captures static information structure • In O-O: also functions • Generalization, inheritance & reuse are important issues • Imported into CommonKADS domain- schema notation • no use made of operation box • Can also be used in Task Model to sketch task information structure 9 Presentation Title | July 27, 2010 | <document classification>

  10. Objects and classes 10 Presentation Title | July 27, 2010 | <document classification>

  11. Object class • Describes a group of objects with similar properties • Abbreviation: "class" • Rationale for introducing classes: • it provides a means for abstraction • Terminology: “object” is often used in an ambiguous way, pointing to both objects (in the strict sense) and object classes. 11 Presentation Title | July 27, 2010 | <document classification>

  12. Attributes • An attribute describes a value held by objects belonging to the class. • Attribute specification consists of: • Class it is defined on (student) • Attribute name (name) • Admissible values (string) • Optional: default value 12 Presentation Title | July 27, 2010 | <document classification>

  13. Operations • Operation is "a function or a transformation that can be applied to objects of a class". • Objects in a class share the same operations. • Method: implementation of an operation • functional view 13 Presentation Title | July 27, 2010 | <document classification>

  14. Class notation 14 Presentation Title | July 27, 2010 | <document classification>

  15. Associations • Associations are used to link objects to other objects • Majority of associations: • binary (between two objects) • directional (should be read in a particular direction • Ternary associations come up occasionally. • Associations between more than three objects are rare. 15 Presentation Title | July 27, 2010 | <document classification>

  16. Association notation 16 Presentation Title | July 27, 2010 | <document classification>

  17. Multiplicity examples 17 Presentation Title | July 27, 2010 | <document classification>

  18. Multiplicity • Also called: "cardinality". • Always connected to one of the classes involved. • Typical types of multiplicity: • 0-1 Zero or one (optional). • 1 Precisely one. • 0+ Zero or more, • 1+ One or more. 18 Presentation Title | July 27, 2010 | <document classification>

  19. Association class • Modeling an association as a class if the association has an internal information structure • Advantage: associations become first-class objects. • Attributes and methods can be defined for the association class. 19 Presentation Title | July 27, 2010 | <document classification>

  20. Notation association class 20 Presentation Title | July 27, 2010 | <document classification>

  21. Associations with specific semantics • Associations provide a general, "neutral", way of connecting object classes. • Semantics of the association are defined through argument typing, multiplicity and (implicitly) the name of the association. • Class diagrams provide specific types of associations, with predefined semantics: • generalization ("is a"). • aggregation ("part of"). 21 Presentation Title | July 27, 2010 | <document classification>

  22. Generalization • Purpose: sharing similarities while preserving differences • Is an association between a class that acts as super-class and one or more classes called the sub-classes. • Super-classes show the features that the sub-classes have in common. • Each sub-class inherits the attributes and operations defined on its super-class(es). 22 Presentation Title | July 27, 2010 | <document classification>

  23. Notation for generalization 23 Presentation Title | July 27, 2010 | <document classification>

  24. Aggregation • Aggregation denotes a binary association in which one side is an "assembly" and the other side a "part". • "Assembly" and "part" act as predefined roles involved in the aggregation association. • Cardinality of a part can be defined • precisely one; optional (0-1); many, ... 24 Presentation Title | July 27, 2010 | <document classification>

  25. Notation for aggregation 25 Presentation Title | July 27, 2010 | <document classification>

  26. Composition • Sub-type of aggregation • Existence of part depends on aggregate 26 Presentation Title | July 27, 2010 | <document classification>

  27. Aggregation and generalization • Similarities: • Tree-like structure • Transitive properties • Differences: • AND-tree (aggregation) vs. OR-tree (generalization) • instance tree (aggregation) vs. class tree (generalization) 27 Presentation Title | July 27, 2010 | <document classification>

  28. Combined Aggregation and Generalization 28 Presentation Title | July 27, 2010 | <document classification>

  29. Use-case Diagram • shows services that can be expected from a system • provides outsider view (customer) • terminology use case service provided by system actor agent using a system service • used in early phases of system analysis • use in CommonKADS: way to present possible solutions to customer 29 Presentation Title | July 27, 2010 | <document classification>

  30. Use cases for a library 30 Presentation Title | July 27, 2010 | <document classification>

  31. Inheritance Hierarchy MAMALS Dogs Cats Humans Leopards Lions Tigers 31 Presentation Title | July 27, 2010 | <document classification>

  32. Block – 2 • Object Oriented Design

  33. Analysis & Design • Define Analysis • Define Design • Why to study OOAD • Difference between- Procedural Analysis & Design Object Analysis & Design Component Analysis & Design • Models Used by OOAD 33 Presentation Title | July 27, 2010 | <document classification>

  34. Define Analysis • Analysis is a detailed study of the various operations performed by a system and their relationships within and outside of the system. 34 Presentation Title | July 27, 2010 | <document classification>

  35. Define Analysis • During analysis data are collected on the available files, decision points, and transactions handled by the present system 35 Presentation Title | July 27, 2010 | <document classification>

  36. Define Analysis • Data Flow Diagrams, interviews, on-site observations, and questionnaires are some examples of tools that are used in analysis. 36 Presentation Title | July 27, 2010 | <document classification>

  37. Once the Analysis is completed the analyst has a firm understanding of what is to done. The next step is to decide how the problem might be solved. Thus, in systems design, we move from the logical to the physical aspects of the life cycle. 37 Presentation Title | July 27, 2010 | <document classification>

  38. Design Design refers to the technical specifications that will be applied in implementing the candidate system. This involves input/output, file, and processing design Refers to the technical specifications that will be applied in implementing the candidate system. This involves input/output, file, and processing design

  39. Steps in System Design From Analysis 1 Cost Justification & candidate System design Output Design Detailed Documentation Design submitted to management for approval Input Design File Design Design Accepted No Abandon project Processing Design Yes Go to implementation Test Program 2 39 Presentation Title | July 27, 2010 | <document classification>

  40. Why OOAD Object Oriented approach to software development based on modeling objects from the real world & then using the model to build a language independent design organized around those objects.

  41. OOAD Provides/Promotes Better understanding of requirements Cleaner designs Easy to make changes in the system

  42. Report published in JAPAN The software industry still relies mainly on the informal paper and pencil approach in the upstream development phases. 42 Presentation Title | July 27, 2010 | <document classification>

  43. Why to use MODELS The process of problem-solving using a computer is an intricate process requiring much thought, careful planning, logical precision, persistence, and attention to detail.

  44. Evolution of Models Procedural Model Object Oriented Model Component Model

  45. Procedural Model Each problem is divided into smaller problem and solved using specified modules that act on data.

  46. Procedural Model • This approach to software development is process centric or procedural • Not ideal for developing complex software coz, concentrates on the processes 46 Presentation Title | July 27, 2010 | <document classification>

  47. Procedural Model • Modules are tightly interwoven and interdependent, that it is difficult to separate one module from another • Reusability of software becomes difficult as complexity increases with processes 47 Presentation Title | July 27, 2010 | <document classification>

  48. Object Oriented Model It perceives the entire software system as a collection of objects which contain attributes and behaviors

  49. Why Object Oriented Model • Realistic Modeling • Reusability • Resilience to change 49 Presentation Title | July 27, 2010 | <document classification>

  50. Component Based Model • Software development is done based on a standard that allows software components to communicate with one another. 50 Presentation Title | July 27, 2010 | <document classification>

More Related