Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.


This PPT contains Maximum topics of first unit IN OOAD CS6502

  • Be the first to comment


  1. 1. 1 Object-Oriented Analysis and Design (OOAD) By Mikel Raj.K.T
  2. 2. 2 Learning Objectives Key terms Association Class diagram Event Object Object class Operation Sequence diagram State State transition Unified Modeling Language (UML) Use case A.2
  3. 3. 3 The Object-Oriented Modeling Approach • Benefits 1.The ability to tackle more challenging problem domains 2.Improved communication among users, analysts, designers, and programmers 3.Reusability of analysis, design, and programming results 4.Increased consistency among the models developed during object-oriented analysis, design, and programming A.3
  4. 4. 4
  5. 5. 5 The Object-Oriented Modeling Approach (continued) • Object-Oriented Systems Development Life Cycle – Process of progressively developing representation of a system component (or object) through the phases of analysis, design, and implementation – The model is abstract in the early stages – As the model evolves, it becomes more and more detailed A.5
  6. 6. 6 The Object-Oriented Systems Development Life Cycle • Analysis Phase – Model of the real-world application is developed showing its important properties – Model specifies the functional behavior of the system independent of implementation details • Design Phase – Analysis model is refined and adapted to the environment • Implementation Phase – Design is implemented using a programming language or database management system A.6
  7. 7. 7 The Object-Oriented Systems Development Life Cycle (continued) • Unified Modeling Language (UML) – A notation that allows the modeler to specify, visualize and construct the artifacts of software systems, as well as business models – Techniques and notations • Use cases • Class diagrams • State diagrams • Sequence diagrams A.7
  8. 8. 8 Use-Case Modeling • Applied to analyze functional requirements of the system • Performed during the analysis phase to help developers understand functional requirements of the system without regard for implementation details • Use Case – A complete sequence of related actions initiated by an actor • Actor – An external entity that interacts with the system A.8
  9. 9. 9 Use-Case Modeling • Use cases represent complete functionality of the system • Use cases may participate in relationships with other use cases • Use cases may also use other use cases A.9
  10. 10. 10A.10
  11. 11. 11 Object Modeling: Class Diagrams • Object – An entity that has a well-defined role in the application domain, and has state, behavior, and identity • State – A condition that encompasses an object’s properties and the values those properties have • Behavior – A manner that represents how an object acts and reacts • Object Class – A set of objects that share a common structure and a common behaviorA.11
  12. 12. 12 Object Modeling: Class Diagrams (continued) • Class Diagram – Class is represented as a rectangle with three compartments – Objects can participate in relationships with objects of the same class A.12
  13. 13. 13 Object Modeling: Object Diagrams • Object Diagram – A graph of instances that are compatible with a given class diagram; also called an instance diagram – Object is represented as a rectangle with two compartments • Operation – A function or service that is provided by all the instances of a class • Encapsulation – The technique of hiding the internal implementation details of an object from its external view A.13
  14. 14. 14A.14
  15. 15. 15 Representing Associations • Association – A relationship between object classes – Degree may be unary, binary, ternary or higher – Depicted as a solid line between participating classes • Association Role – The end of an association where it connects to a class – Each role has multiplicity, which indicates how many objects participate in a given association relationship A.15
  16. 16. 16A.16
  17. 17. 17 Representing Generalization • Generalization – Abstraction of common features among multiple classes, as well as their relationships, into a more general class • Subclass – A class that has been generalized • Superclass – A class that is composed of several generalized subclasses A.17
  18. 18. 18 Representing Generalization (continued) • Discriminator – Shows which property of an object class is being abstracted by a generalization relationship • Inheritance – A property that a subclass inherits the features from its superclass • Abstract Class – A class that has no direct instances but whose descendents may have direct instances • Concrete Class – A class that can have direct instances A.18
  19. 19. 19A.19
  20. 20. 20 Representing Aggregation • Aggregation – A part-of relationship between a component object and an aggregate object – Example: Personal computer • Composed of CPU, Monitor, Keyboard, etc A.20
  21. 21. 21 Dynamic Modeling: State Diagrams • State – A condition during the life of an object during which it satisfies some conditions, performs some actions or waits for some events – Shown as a rectangle with rounded corners • State Transition – The changes in the attributes of an object or in the links an object has with other objects – Shown as a solid arrow – Diagrammed with a guard condition and action • Event – Something that takes place at a certain point in time A.21
  22. 22. 22A.22
  23. 23. 23 Dynamic Modeling: Sequence Diagrams • Sequence Diagram – A depiction of the interaction among objects during certain periods of time • Activation – The time period during which an object performs an operation • Messages – Means by which objects communicate with each other A.23
  24. 24. 24 Dynamic Modeling: Sequence Diagrams (continued) • Synchronous Message – A type of message in which the caller has to wait for the receiving object to finish executing the called operation before it can resume execution itself • Simple Message – A message that transfers control from the sender to the recipient without describing the details of the communication A.24
  25. 25. 25A.25
  26. 26. 26 Moving to Design • Start with existing set of analysis model • Progressively add technical details • Design model must be more detailed than analysis model • Component Diagram – A diagram that shows the software components or modules and their dependencies • Deployment Diagram – A diagram that shows how the software components, processes and objects are deployed into the physical architecture of the system A.26
  27. 27. 27A.27
  28. 28. 28 Summary • Object-Oriented Modeling Approach – Benefits – Unified Modeling Language • Use cases • Class diagrams • State diagrams • Sequence diagrams • Use Case Modeling A.28
  29. 29. 29 Summary (continued) • Object Modeling: Class Diagrams – Associations – Generalizations – Aggregation • Dynamic Modeling: State Diagrams • Dynamic Modeling: Sequence Diagrams • Moving to Design A.29
  30. 30. 30 Unified Process
  31. 31. 31 What is Process ??? • Defines who is doing, what and when to do it, and how to reach a certain goal. Software Engineering Process New or Changed requirements New or Changed system
  32. 32. 32 What is Unified Process ?? • Unified process (UP) is an architecture-centric, use- case driven, iterative and incremental development process that leverages unified modeling language and is compliant with the system process engineering metamodel. • A popular iterative modern process model (framework) derived from the work on the UML and associated process.
  33. 33. 33 Unified Process • The leading object-oriented methodology for the development of large-scale software • Maps out when and how to use the various UML techniques • Develop high-risk elements in early iterations • Deliver value to customer
  34. 34. 34 Creating the Unified Process Rational Unified Process 5.0 1998 Rational Objectory Process 4.1 1996-1997 Objectory Process 1.0-3.8 1987-1995 Ericsson Approach Rational Approach IBM Approach Unified Process 1998 OO Approach
  35. 35. 35 The Unified Process • The Unified Process is an adaptable methodology. • The Unified Process is a modeling technique. UML stands for unified modeling language. • The object-oriented paradigm is iterative and incremental in nature
  36. 36. 36 Unified Process Phases • Inception – Establish the business case for the system, define risks, obtain 10% of the requirements, estimate next phase effort. • Elaboration – Develop an understanding of the problem domain and the system architecture, risk significant portions may be coded/tested, 80% major requirements identified. • Construction – System design, programming and testing. Building the remaining system in short iterations. • Transition – Starts when beta testing is completed, Deploy the system in its operating environment. Deliver releases for feedback and deployment
  37. 37. 37 The Phases/Workflows Of Unified Process qPhase is Business context of a step Workflow is Technical context of a step
  38. 38. 38 The Phases/Workflows Of Unified Process q NOTE: Most of the requirements work or workflow is done in the inception phase. q However some is done later.
  39. 39. 39 The Phases/Workflows Of Unified Process q NOTE: Most of the implementati on work or workflow is done in construction q However some is done earlier and some later.
  40. 40. 40 Example roles in UP • Stake Holder: customer, product manager, etc. • Software Architect: established and maintains architectural vision • Process Engineer: leads definition and refinement of Development Case • Graphic Artist: assists in user interface design, etc.
  41. 41. 41 Agile Process
  42. 42. 42 Agenda • Manifesto for Agile Software Development • What is Agility? • Agile Teams • Agility and the Cost of Change • An Agile Process • The principles of agile methods • Human Factors • Agile Process Models • Agile Modeling • Conclusion
  43. 43. 43 Manifesto for Agile Software Development • “We are uncovering better ways of developing software by doing it and helping others do it. • Agile values: 1. Individuals and interactions- in agile development, self organization & motivation are important 2. Working software- working software will be more useful and welcome than just presenting documents to clients in meetings 3. Customer collaboration-requirements cant be fully collected at the beginning of the software development cycle, therefore continuous customer involvement is important 4. Responding to change- agile development is focused on quick responses to change and continuous development
  44. 44. 44 Agility • Effective response to change • Effective communication among all stakeholders • Drawing the customer into the team. • Organizing a team so that it is in control of the work performed In order to yield rapid, incremental delivery of software
  45. 45. 45 Agile Teams • Responsive to changes during project development • Recognize that project plans must be flexible • Eliminates the separation between customers and developers
  46. 46. 46 Agility and the Cost of Change • Conventional wisdom is that the cost of change increases nonlinearly as a project progresses. It is relatively easy to accommodate a change when a team is gathering requirements early in a project.
  47. 47. 47 Agility and the Cost of Change
  48. 48. 48 An Agile Process • Is driven by customer descriptions of what is required (scenarios). Some assumptions: – Recognizes that plans are short-lived (some requirements will persist, some will change. Customer priorities will change) – Develops software iteratively with a heavy emphasis on construction activities (design and construction are interleaved, hard to say how much design is necessary before construction. Design models are proven as they are created. ) – Analysis, design, construction and testing are not predictable. • Thus has to Adapt as changes occur due to unpredictability • Delivers multiple ‘software increments’, deliver an operational prototype or portion of an OS to collect customer feedback for adaption.
  49. 49. 49 Human Factors • The process molds to the needs of the people and team, not the other way around • key traits must exist among the people on an agile team : – Competence. ( talent, skills, knowledge) – Common focus. ( deliver a working software increment ) – Collaboration. ( peers and stakeholders) – Decision-making ability. ( freedom to control its own destiny) – Fuzzy problem-solving ability.(ambiguity and constant changes, today problem may not be tomorrow’s problem) – Mutual trust and respect. – Self-organization. ( themselves for the work done, process for
  50. 50. 50 Agile Process Models • Extreme Programming (XP) • Adaptive Software Development (ASD) • Agile Modeling (AM)
  51. 51. 51 Extreme programming • The most widely used agile process. • Defines 4 framework activities – Planning – Design – Coding – Testing
  52. 52. 52 Extreme programming 52 planning planning designdesign coding coding testtest refactoring user stories values acceptance test criteria iteration plan simple design CRC cards spike solutions prototypes pair programming unit test continuous integration acceptance testing software increment project velocity computed software increment project velocity computed Release
  53. 53. 53 Extreme programming • XP Planning – Begins with the creation of “user requirements” – Agile team assesses it and assigns a cost – They are grouped to form a deliverable increment – A commitment is made on delivery date – After the first increment “project velocity” is used to help define subsequent delivery dates for other increments
  54. 54. 54 Extreme programming • XP Design –Follows the KIS principle –For difficult design problems, suggests the creation of “spike solutions”—a design prototype –Encourages “refactoring”—an iterative refinement of the internal program design
  55. 55. 55 Extreme programming • XP Coding –Recommends the construction of a unit test for a store before coding commences. –Encourages “pair programming”. • XP Testing –All unit tests are executed daily –“Acceptance tests” are defined by the customer and executed to assess customer visible functionality
  56. 56. 56 Adaptive Software Development (ASD) • Self-organization arises when independent agents cooperate to create a solution to a problem that is beyond the capability of any individual agent • Adaptive cycle characteristics – Mission-driven planning – Component-based focus – Uses “time-boxing” – Explicit consideration of risks – Emphasizes collaboration for requirements gathering
  57. 57. 57 Three Phases of ASD adapt ive cycle planning uses mission st at ement project const raint s basic requirement s t ime-boxed release plan Requirement s gat hering JAD mini-specs component s implement ed/ t est ed focus groups for feedback formal t echnical reviews post mort ems software increment adjustments for subsequent cycles Release
  58. 58. 58 Three Phases of ASD 1. Speculation: • Project is initiated and adaptive cycle planning is conducted. • Adaptive cycle planning uses project initiation information. • Based on the information obtained at the completion of the first cycle, the plan is reviewed and adjusted.
  59. 59. 59 Three Phases of ASD 2. Collaborations • Are used to multiply their talent and creative output beyond absolute number (1+1>2). • It encompasses communication and teamwork, but it also emphasizes individualism.
  60. 60. 60 Three Phases of ASD 3. Learning: • As members of ASD team begin to develop the components, the emphasis is on “learning”. • Learning will help them to improve developers level of real understanding. • Three ways: focus groups, technical reviews and project postmortems
  61. 61. 61 Process Assessment
  62. 62. 62 What is Process Assessment • An objective model-independent method to assess the capability of an organization to meet the process goals • About collecting information • A way to demonstrate program effectiveness
  63. 63. 63 Assessment Method • Assessment Stages • Key Players • Initiation • Preparation • Assessment • Analysis and Reporting • Closure
  64. 64. 64 Assessment Stages Initiation Preparation Assessment Analysis and Reporting Closure
  65. 65. 65 Initiation (stage 1) Define the inputs • identify the assessment purpose • select the assessment model • define goals for the assessment • identify the business drivers • identify constraints • document assumptions • identify additional information gathering requirements • identify feedback and output requirements • complete the assessment brief Sanction the business case • costs and benefits • decision to proceed Select the Resources OutputsOutputs • assessment purpose • constraints • assessment goals • confidentiality agreements • quality measures to be collected
  66. 66. 66 Assessment (stage 3) Gather Information • conduct interviews • study documentation • document findings • consolidate the findings • rate the goals • rate the process • feedback initial conclusions • determine the Organizational Unit’s Capability Level Reach Consensus • on ALL ratings! ConductConduct • according assessment plan • adapt plan for changes and feedback • data collection by interview or document • data review for process ratings • assessors agree on ratings before submitting them to the Lead Assessor TypesTypes • measurement only (no analysis) • Findings & Recommendations • Findings & Action Planning
  67. 67. 67 Analysis & Reporting (stage 4) Analyse Findings Disseminate Findings Identify Action Plan issue Final Report • Strengths & Weaknesses • Gap Analysis • Identify Improvement Opportunities • semi-formal interactive feedback session • prioritise improvements according impact & effort against business drivers • Cost/benefit Analysis • Schedule of improvement roll-out • management findings & recommendations • summary assessment process & key players • results compared with targets • detailed process findings
  68. 68. 68 Closure (stage 5) Post-Assessment Review • results of the analysis of the participants feedback forms • the assessments’ achievements against its goals • the overall level of confidence in the assessments results • any problems the assessors experienced during the assessment including problems with the use of the method • the successes achieved • the techniques used during the assessment • the organizational unit and the Sponsor's response to the results • Lead Assessor ensures that the Assessment Conformance Checklist is complete and signed-off.
  69. 69. 69 UML Diagrams
  70. 70. 70 What is UML? • Standard language for specifying, visualizing, constructing, and documenting the artifacts of software systems, business modeling and other non- software systems. • The UML represents a collection of best engineering practices that have proven successful in the modeling of large and complex systems.
  71. 71. 71 • The UML is a very important part of developing object oriented software and the software development process. • The UML uses mostly graphical notations to express the design of software projects. • Using the UML helps project teams communicate, explore potential designs, and validate the architectural design of the software.
  72. 72. 72 Overview of UML Diagrams Structural : element of spec. irrespective of time • Class • Component • Deployment • Object • Composite structure • Package Behavioral : behavioral features of a system / business process • Activity • State machine • Use case • Interaction Interaction : emphasize object interaction • Communication(collaberati on) • Sequence • Interaction overview • Timing
  73. 73. 73 Class diagram UML class diagrams show the classes of the system, their inter-relationships, and the operations and attributes of the classes  Explore domain concepts in the form of a domain model  Analyze requirements in the form of a conceptual/analysis model  Depict the detailed design of object-oriented or object-based software
  74. 74. 74 Class diagram
  75. 75. 75 Class diagram
  76. 76. 76 Component diagram UML component diagrams shows the dependencies among software components, including the classifiers that specify them (for example implementation classes) and the artifacts that implement them; such as source code files, binary code files, executable files, scripts and tables.
  77. 77. 77 Component diagram
  78. 78. 78 Deployment diagram  UML deployment diagram depicts a static view of the run- time configuration of hardware nodes and the software components that run on those nodes. Deployment diagrams show the hardware for your system, the software that is installed on that hardware, and the middleware used to connect the disparate machines to one another.
  79. 79. 79 Deployment diagram
  80. 80. 80 Deployment diagram
  81. 81. 81 Object diagram UML Object diagrams (instance diagrams), are useful for exploring real world examples of objects and the relationships between them. It shows instances instead of classes. They are useful for explaining small pieces with complicated relationships, especially recursive relationships.
  82. 82. 82 Object diagram
  83. 83. 83 Package diagram UML Package diagrams simplify complex class diagrams, it can group classes into packages. A package is a collection of logically related UML elements. Packages are depicted as file folders and can be used on any of the UML diagrams.
  84. 84. 84 Package diagram
  85. 85. 85 Composite structure diagram UML Composite structure diagrams used to explore run-time instances of interconnected instances collaborating over communications links.  It shows the internal structure (including parts and connectors) of a structured classifier or collaboration.
  86. 86. 86 Activity diagram UML Activity diagrams helps to describe the flow of control of the target system.  such as the exploring complex business rules and operations, describing the use case also the business process. It is object-oriented equivalent of flow charts and data-flow diagrams (DFDs).
  87. 87. 87 Activity diagram
  88. 88. 88 State diagram UML State diagrams can show the different states of an entity also how an entity responds to various events by changing from one state to another. The history of an entity can best be modeled by a finite state diagram.
  89. 89. 89 State diagram
  90. 90. 90 State diagram
  91. 91. 91 Use cases diagram Use cases diagrams describes the behavior of the target system from an external point of view. Use cases describe "the meat" of the actual requirements. Use cases: A use case describes a sequence of actions that provide something of measurable value to an actor and is drawn as a horizontal ellipse.
  92. 92. 92 Use cases diagram (cont…)  Actors: An actor is a person, organization, or external system that plays a role in one or more interactions with your system. Actors are drawn as stick figures.  Associations: Associations between actors and use cases are indicated by solid lines. An association exists whenever an actor is involved with an interaction described by a use case.
  93. 93. 93 Use cases diagram
  94. 94. 94 Use cases diagram
  95. 95. 95 Communication diagram Communication diagrams used to model the dynamic behavior of the use case.  When compare to Sequence Diagram, the Communication Diagram is more focused on showing the collaboration of objects rather than the time sequence.
  96. 96. 96 Communication diagram
  97. 97. 97 Sequence diagram UML Sequence diagrams models the collaboration of objects based on a time sequence.  It shows how the objects interact with others in a particular scenario of a use case.
  98. 98. 98 Sequence diagram
  99. 99. 99 Timing diagram  Timing diagrams shows the behavior of the objects in a given period of time.  Timing diagram is a special form of a sequence diagram.  The differences between timing diagram and sequence diagram are the axes are reversed so that the time are increase from left to right and the lifelines are shown in separate compartments arranged vertically.
  100. 100. 100 Timing diagram
  101. 101. 101 Timing diagram
  102. 102. 102 Interaction overview diagram Interaction overview diagrams focuses on the overview of the flow of control of the interactions. It is a variant of the Activity Diagram where the nodes are the interactions or interaction occurrences. It describes the interactions where messages and lifelines are hidden.
  103. 103. 103 Interaction overview diagram
  104. 104. 104 UML Diagram Hierarchy
  105. 105. 105 References • • http://www.visual- •,1410,31863, ml • uage • D/UML_tutorial/index.htm
  106. 106. 106 Thank u