Published on

1 Like
  • Be the first to comment

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

No notes for slide


  1. 1. 3.Object Oriented Systems Development Life Cycle  s/w development process -> three transformations, building high quality s/w -> correspondence, correctness, validation, verification.  Object Oriented system development (OOSD) -> OOA, OOD, prototyping, Implementation –> Component Based Development & Rapid Application Development(CBD & RAD), Incremental Testing, Reusability. • Main goal of this is giving idea of building the s/w by placing emphasis on the Analysis and Design aspects of the s/w life cycle. • Emphasis means intend to promote the building of high quality s/w. • s/w industry has suffered a lot on the early stages of the life cycle.
  2. 2. 3.Object Oriented Systems Development Life Cycle Software Development Process: • System development can be viewed as a process. • With in the process, it is possible to replace one subprocess with a new one. • But the new subprocess has the same interface as the old one. • Each Process can be divided into small, interacting phases into subprocesses which consists of • Description of the work to be done. • Specification of input required for the process. • Specification of output to be produced. • Software development process also can be divided into smaller, interacting subprocesses. • s/w development process can be viewed as a series of transformations. • Here o/p of one transformation becomes the i/p of the subsequent transformation.
  3. 3. 3.Object Oriented Systems Development Life Cycle • Transformation 1:(analysis) • It translates the users needs into system requirements and responsibilities. • In this the system can provide insight into the users requirements. • Transformation 2:(design) • It begins with a problem statement and ends with detailed design. • It can be transformed into an operational system. • In this transformation it includes the bulk of the s/w development activity. • That means it includes the definition of how to build the s/w, it’s development, testing, and design descriptions. • Also includes the program & the testing materials.
  4. 4. 3.Object Oriented Systems Development Life Cycle • Transformation 3:(implementation) • It refines the detailed design into the system deployment. • It will satisfy the users needs. • It includes the equipment, procedures, people. • It represents embedding the s/w product within it’s operational environment. User needs Problem, statements, analysis Design, Implementation, Details System, software, product Transformation 1 Transformation 2 Transformation 3 SEQUENCE OF TRANSFORMATIONS
  5. 5. 3.Object Oriented Systems Development Life Cycle • s/w development process mainly based on Water fall approach. a. Decide what is the problem? b. Decide how to accomplish the requirement’s determined. c. Do it. d. Test the result.(if user’s requirement are satisfied) e. Finally Use what we’ve done. What How Do It Test Use
  6. 6. 3.Object Oriented Systems Development Life Cycle
  7. 7. 3.Object Oriented Systems Development Life Cycle 1. Correspondence measures how well the delivered system matches the needs of the problem. 2. Validation is the task of predicting correspondence. 3. Correctness measures the consistency of the product Needs Requirements Design Software Validation Verification Correctness Correspondence
  8. 8. 3.Object Oriented Systems Development Life Cycle • Correctness is always objective & Validation is always subjective. • Boehm observes the difference b/w the Verification & Validation as: • Verification : Am I building the product right? • Validation : Am I building the right product? • Validation begins as soon as the project starts. • But Verification can begin only after a specification has been accepted. • These’re independent of each other.
  9. 9. 3.Object Oriented Systems Development Life Cycle  OO Analysis – Use Case Driven: • Mainly concerned with determining the system requirements & identifying classes and their relationship to other classes in the problem domain. • To determine sys. Requirements, we need to identify the user’s or the actor’s. • For that , Ivar Jacobson had brought the concept of Use Case. • A Use Case is a typical interaction between a user and a system. • It captures user’s goals & needs. • The intersection among objects, roles to achieve a given goal is known as Collaboration. • Focusing on high level processes and interactions with customers in a scenario & analyzing is referred to as Use Case modeling.
  10. 10. 3.Object Oriented Systems Development Life Cycle • Once our Use Case model is well understood and developed, we should start to identify classes and create their relationship’s. • Interaction between objects in a particular context is given in collaboration diagram. • Msg. exchanged among objects with in the collaboration to achieve the desired outcome. • Sequence is indicated by numbering the msg. • Documentation is another important activity. • It does not end with Object Oriented Analysis, but it should be carried out throughout the system development.
  11. 11. 3.Object Oriented Systems Development Life Cycle • Make the Documentation as short as possible. • For that we’re applying 80 – 20 rule for documentation. • That is 80 percent of the work can be done with 20 percent of the documentation. • Documentation & Modeling are not separate activities. • So good modeling can make up good documentation.
  12. 12. 3.Object Oriented Systems Development Life Cycle  Object Oriented Design: • Main goal of OOD is to design the classes identified during the analysis phase and the user interface. • During this phase, we identify and define additional objects and classes that support implementation of the requirements. • Some activities are: • Design & refine classes. • Design & refine attributes • Design & refine methods. • Design & refine structures. • Design & refine associations.
  13. 13. 3.Object Oriented Systems Development Life Cycle • Few guidelines to use in our object oriented design: • Reuse, rather than build a new class. Know the existing classes. • Design a large number of simple classes , rather than a small number of complex classes. • Design methods.
  14. 14. 3.Object Oriented Systems Development Life Cycle  Prototyping: • A prototype is a version of a s/w product developed in the early stages of the product’s life cycle for specific, experimental purposes. • A prototype enables us to fully understand how easy or difficult it will be to implement some of the features of the system. • Also given a chance to the user to comment on the usability & usefulness of User Interface Design (UID). • Prototyping provides the developer a means to test and refine the user interface and increase the usability of the system.
  15. 15. 3.Object Oriented Systems Development Life Cycle • Prototyps can be categorized into many ways: 1. Horizontal prototype 2. Vertical prototype 3. Analysis prototype 4. Domain prototype • Horizontal prototype: • It is a simulation of the user interface. (i.e) it has the entire user interface that’ll be in the full featured system. • But it contains no functionality. • Adv: very easy to implement good overall feel of the sys. • Allowing the user to evaluate UI based on the expectation or needs.
  16. 16. 3.Object Oriented Systems Development Life Cycle • Vertical prototype: • It is a subset of the system features with complete functionality. • Adv: few implemented functions can be tested in great depth. • Analysis prototype: • It is an aid for exploring the problem domain. • Adv: This is used to inform the user and demonstrate the proof of a concept.
  17. 17. 3.Object Oriented Systems Development Life Cycle • Domain prototype: • It is an aid for the incremental development of the ultimate sw solution. • Adv: used as a tool for the staged delivery of subsystems to the user’s or other members of the development team. • Overall prototyping is a useful one at almost any stage of the development.
  18. 18. 3.Object Oriented Systems Development Life Cycle • Object Oriented Implementation: • Computer Aided Software Engineering (CASE) tools is only the skeleton of an application. • New generation of CASE tools support component based development (CBD). • Implementation: a.CBD-Component based development b.RAD-Rapid application development
  19. 19. 3.Object Oriented Systems Development Life Cycle • CBD: • This’s an industrial approach to the s/w. • In this, application development moves from custom development to assembly development.(i.e.) prebuilt, pretested & reusable s/w components. • Two basic ideas: 1.Application development can be improved significantly if applications can be assembled quickly from pre s/w components. 2.Large collection of interpretable s/w components can be easily available to the developer’s in both general & specialist catalogs.
  20. 20. 3.Object Oriented Systems Development Life Cycle • CBD developer can assemble components to construct a complete s/w system. • s/w are assembled from components from the variety of constructed components written in several diff. languages & run on several diff. platform advantages. • Simplicity: • Replacing components to produced stepwise improvement. • Integration: • Inserting additional components to create new tasks & next transformation. • Disassembling: The components based on the sys.needs
  21. 21. 3.Object Oriented Systems Development Life Cycle • RAD: • It’s a quick & dirty prototype used to build an application faster than other traditional methods. • To achieve RAD, developer sacrifices the quality of the product for a quicker delivery. • RAD does not replace the system development life cycle but complement’s it. • Main objective of RAD is to build a version of an application rapidly to see whether they actually have understood the problem.(i.e.) Analysis. • Further it determines whether the system does what it’s supposed to do.(i.e.) Design.
  22. 22. 3.Object Oriented Systems Development Life Cycle • RAD involves a number of iterations. • Through each iteration we can understand the problem a little better and make an improvement. • RAD encourages the incremental development approach. • Prototyping & RAD do not replace the object oriented software development model. • Instead , in a RAD application, we go through stages in a rapid (incomplete) fashion, completing more in the next iteration of the prototype.
  23. 23. 3.Object Oriented Systems Development Life Cycle • Incremental testing: • Testing is a process with a intent of finding error’s. • If we wait until after development to test an application, we'd be wasting a lot of time & money. • The problem was that developers would turn over applications to a quality assurance (QA) group for testing only after development was completed. • Since the QA group wasn’t included in the initial plan, it had no clear picture of the system characteristics until it came time to test. • Do the test case, it provides reliability, reduced time & cost and improve consistency.
  24. 24. 3.Object Oriented Systems Development Life Cycle  Reusability – A major benefit of object-oriented systems development is reusability, and this is the most difficult promise to deliver on.  Reuse strategy – Information hiding (encapsulation). – Conformance to naming standards. – Creation and administration of an object repository. – Encouragement by strategic management of reuse as opposed to constant redevelopment.
  25. 25. 3.Object Oriented Systems Development Life Cycle – Establishing targets for a percentage of the objects in the project to be reused (i.e.,50 percent reuse of objects).  The essence of the software process is the transformation of users‘ needs into a software solution.  The O-O SDLC is an iterative process and is divided into analysis, design , prototyping / implementation, and testing.
  26. 26. 4.Object Oriented Methodologies  Rumbaugh Object Modeling Technique: • Object model • OMT Dynamic model • OMT Functional model  Booch Methodology: • Macro development process • Micro development process  Jacobson methodologies: • Use Cases • Object Oriented S/w engineering • Object Oriented Business Engineering
  27. 27. 4.Object Oriented Methodologies  Patterns: • Generative & Non generative patterns • Patterns template • Antipatterns • Capturing patterns  Frameworks  Unified approach • OOA • OOD • Iterative development & continuous testing • Modeling based on UML • UA protocol repository • Layered approach: Business layer User interface layer Access layer
  28. 28. 4.Object Oriented Methodologies • For system development many methodologies are available. • Each object oriented methodology is based on modeling the business problem & implementing the application only in an object oriented fashion. • Small variant or differences only in documentation , modeling & notations. • Rumbaugh, Booch & Jacobson have developed some methodologies & their modeling notations. • These are the origin of Unified Modeling Language (UML).
  29. 29. 4.Object Oriented Methodologies • Rumbaugh method describes object model or static structure of system. • Booch method describes detailed object oriented design models. • Jacobson method describes user driven analysis models.
  30. 30. 4.Object Oriented Methodologies  Rumbaugh Object Modeling Technique: • This Object Modeling Technique describes a method for Analysis, Design & Implementation of a sys. Using an object oriented technique. • OMT is fast & intuitive approach for identifying & modeling objects that making up a system. • Class attributes, methods, inheritance & association can be expressed easily using object model. • Dynamic behavior of objects with in a system can be described using OMT Dynamic model. • Process description & consumer – producer relationships can be expressed using OMT Functional model.
  31. 31. 4.Object Oriented Methodologies  Rambaugh methodologies: • Phases of OMT: • Analysis • System Design • Object Design • Implementation • OMT consists of four phases, which can be performed iteratively, – Analysis: The results are objects and dynamic and functional models. – System design: The result is a structure of the basic architecture of the system. – Object design: This phase produces a design document, consisting of detailed objects and dynamic and functional models. – Implementation: This activity produces reusable, extendible and robust code.
  32. 32. 4.Object Oriented Methodologies • OMT consists of three parts:  object model– consists of Object model and Data dictionary. Dynamic model– consists of State diagrams and Event flow diagrams. Functional model– consists of Data flow and Constraints.
  33. 33. 4.Object Oriented Methodologies  Object model: • This describes the structure of objects in the system. • That is Identity, Relationships to other objects, Attributes & Operations. • OMT object model diagram contains classes interconnected by association lines. • Each class represents a set of individual objects. • Association lines establish relationships among the classes & represent set of links from objects of one class to objects of another class.
  34. 34. 4.Object Oriented Methodologies  OMT object model bank system Client First name Last name Pin code Client Account Account Transaction Account Number balance Deposit Withdraw Create transaction Transaction Trans. Date Trans. Time Trans. Type Amount Post balance Checking Account Withdraw Checking Savings Account Savings Account Boxes represent classes, *filled triangle represents specialization, *association b/w account & transaction is one to many • filled circle represents many • *client & account classes is one to one relationships.
  35. 35. 4.Object Oriented Methodologies  OMT Dynamic model: 1. States 2. Transitions 3. Events 4. Actions
  36. 36. 4.Object Oriented Methodologies • State transition diagram of bank application: Many Nothing is selected Account has been selected Selected checking Or savings account Select checking account Select transaction type (withdraw, deposit, transfer) Enter the amount confirmation Transitions States Round boxes states, Arrows transitions Each state receives one or more events, at which time it makes the transition to next state. Next state depends on the current state as well as the events.
  37. 37. 4.Object Oriented Methodologies  OMT functional model:  OMT data flow diagram (DFD) shows the flow of data b/w different processes in a business.  DFD how data is processed by a sys. In terms of i/p’s & o/p’s.  OMT DFD provides simple & intuitive method.  It describes business processes without focusing on details of computer systems.
  38. 38. 4.Object Oriented Methodologies  DFD consists of four symbols: 1. Process : any function being performed. For example verify Password or PIN in ATM system. 2. Data flow: direction of data element movement. E.g.: PIN code. 3. Data store: location where data are stored. E.g.: account is a data store in ATM. 4. External entity: source or destination of a data element. E.g.: ATM card reader.
  39. 39. 4.Object Oriented Methodologies  Rambaugh OMT methodology provides strongest tool sets for analysis and design of object oriented systems.
  40. 40. 4.Object Oriented Methodologies  Booch Methodology – The Booch methodology covers the analysis and design phases of systems development. – Booch sometimes is criticized for his large set of symbols. – The Booch method consists of the following diagrams: • Class diagrams • Object diagrams • State transition diagrams • Module diagrams • Process diagrams • Interaction diagrams
  41. 41. 4.Object Oriented Methodologies Car Color Manufacturer cost Escort Ford Mustang Taurus inherits inherits superclass Object modeling diagram using Booch notation. Arrows represent specialization. e.g. the class Escort is subclass of the class Ford.
  42. 42. 4.Object Oriented Methodologies  Booch’s object oriented design is also known as Object Oriented Analysis and Design (OOAD).  This’s one of the precursor of Unified Modeling Language (UML).  Booch dynamic diagrams corresponds to in UML.  State transition diagram corresponds to State chart diagram in UML.  Interaction diagram corresponds to Sequence diagram in UML.  Module diagram corresponds to Component diagram in UML.  Process diagram corresponds to deployment diagram in UML.  Module diagram & Process diagram illustrate the physical design of our application.
  43. 43. 4.Object Oriented Methodologies  State chart diagram in UML (State transition diagram)  State Event or Action Initial State Final State
  44. 44. 4.Object Oriented Methodologies synchronization (2 transitions entering into it) Splitting of control (2 transitions leaving it & Creates multiple States)
  45. 45. 4.Object Oriented Methodologies  Sequence diagram in UML (Interaction diagram):  It describes interactions among classes in terms of an exchange of messages over time.  Class roles:  Messages :  Messages are arrows, represent communication b/w objects.  Use half arrowed lines, represent Asynchronous messages.  i.e. Asynchronous messages are sent from an object & that’ll not wait for a response from receiver before continuing it’s tasks. object: class
  46. 46. 4.Object Oriented Methodologies  Symbols for Message type:  Simple Synchronous Asynchronous
  47. 47. 4.Object Oriented Methodologies  Component diagram (Module diagram):  It describes the organization of physical components in a system.  Symbols:  Component  physical building block of the system.  Interface describes group of operations used. component Rectangular with tabs
  48. 48. 4.Object Oriented Methodologies  Dependencies : component component component ---- ---- dependency
  49. 49. 4.Object Oriented Methodologies  Deployment diagram (Process diagram):  Depict the physical resources in a system including nodes, components & connections.  Symbols:  Node: physical resources that executes code components. Node name
  50. 50. 4.Object Oriented Methodologies  Association:  Physical connection b/w nodes. E.g. Ethernet. Node Node
  51. 51. 4.Object Oriented Methodologies  Components & Nodes:  Place components inside the node that deploys them. component component Server
  52. 52. 4.Object Oriented Methodologies  The Booch methodology prescribes – A macro development process – A micro development process.  Macro development process:  It serves as a controlling framework for micro process.  For the period of more than a week & months.  Primary concern of macro process is technical management of the system.  But this technical management is less interested in object oriented design.
  53. 53. 4.Object Oriented Methodologies  Rather it’ll concentrate more on how the project corresponds to requirements & whether it’ll be produced on time.  In macro process traditional phases of analysis & design are preserved to a large extent.  Macro development process consists of five steps: 1.Conceptualization 2.Analysis and development of the model 3.Design or create the system architecture 4.Evolution and implementation 5.Maintenance
  54. 54. 4.Object Oriented Methodologies  Conceptualization:  During Conceptualization we’ve to establish the core requirements of the system.  We’ve to establish a set of goals & develop some prototype to prove the concept.  Analysis and development of the model:  In this stage, we use the class diagram.  Class diagram used to describe the roles and responsibilities of the objects that are carry out to perform the behavior of the system.(or)  Object diagram used to describe the behavior of system in terms of scenarios.(or)  Interaction diagram used to describe the same as object diagram.
  55. 55. 4.Object Oriented Methodologies  Design or create the system architecture:  At design stage, we use the class diagram.  Here Class diagram used to describe what classes exists & how they relate to each other.  Next we use object diagram, used to describe what mechanisms are used to regulate the collaboration of objects.  Next we use Module diagram, used to map out where each class & object should be declared.  Finally we use process diagram, used to determine which processor to allocate a process.  Process diagram is also used to determine the schedules for multiple processes on each relevant processor.
  56. 56. 4.Object Oriented Methodologies  Evolution and implementation:  In this phase, we’re successively refine the system through many iterations.  Each refinement of prior one by producing a stream of s/w implementation.  Maintenance:  Some localized changes are made to the system to add new requirements & eliminate bugs.
  57. 57. 4.Object Oriented Methodologies  The Micro Development Process:  Each macro development process has it’s own micro development processes.  Micro process having the description of day to day activities by a single or small group of s/w developers.  Since analysis and design phases are not clearly defined.
  58. 58. 4.Object Oriented Methodologies  The micro development process consists of the following steps:  Identify classes and objects.  Identify class and object semantics.  Identify class and object relationships.  Identify class and object interfaces and implementation.
  59. 59. 4.Object Oriented Methodologies  Jacobson Methodologies:  The Jacobson et al. methodologies (e.g., OOBE, OOSE, and Objectory ) cover the entire lifecycle and stress traceability between the different phases.  Here traceability means reuse of analysis & design work.  It’ll reduce the development time than reuse of code.  Heart of this methodology is use case concept.
  60. 60. 4.Object Oriented Methodologies  Use Case concept:  Use cases are scenarios for understanding sys. requirements.  Use case describes the interaction b’w users & system.  Use case model captures the goal of the user & the responsibility of system to it’s users.
  61. 61. 4.Object Oriented Methodologies  In requirement analysis, use cases are described as any one of the following: • Non formal text, with no clear flow of events. • Text, easy to read with clear flow of events. • Formal style, using pseudo code.  Use case description must contain: a.How & when the use case begins & ends. b.When the interaction occurs and what is going to be exchanged b/w the use case and it’s actors should be included. c.How and when the use case will need data store in the sys. d.Exceptions to the flow of events. e.How and when the concepts of the problem domain
  62. 62. 4.Object Oriented Methodologies  Every single use case should describe one main flow of events.  Exceptional or additional flow of events could be added.  Extends relationship is used when we have one use case that is similar to another use case.  It extends the functionality of original use case that is it does a bit more (like subclass).
  63. 63. 4.Object Oriented Methodologies  Abstract use case  use cases could be viewed as abstract use case.  It’s not complete & has no actors that initiate it.  It’s used by another use case.  This inheritance used in different levels.  Abstract use case have uses or extends relationship.
  64. 64. 4.Object Oriented Methodologies  Object-Oriented Software Engineering: Objectory – Object-oriented software engineering (OOSE), also called Objectory, is a method of object-oriented development with the specific aim to fit the development of large, real-time systems. – OOSE also known as object factory for system development. – It follows the concept of modern UML. – i.e. Modeling language & methodology. – Development process called use case driven development includes Analysis, Design, Validation & Testing.
  65. 65. 4.Object Oriented Methodologies  Objectory is built around several different models: – Use case model. – Domain object model. – Analysis object model. – Implementation model. – Test model
  66. 66. 4.Object Oriented Methodologies Use case diagram Analysis diagram State transition diagram Interaction diagram Program diagram
  67. 67. 4.Object Oriented Methodologies  In this we can use RUP – Relational Unified Process.  OOSE tools have been replaced by UML & RUP tools.  Objectory is built around several different models:  Use case model:  Use case model defines the outside & inside of system’s behavior.  Domain object model:  Provides the logical view of a system used to specify the use cases for use case diagram.
  68. 68. 4.Object Oriented Methodologies  Problem domain object model diagram:  Interaction b/w users. obj obj obj obj
  69. 69. 4.Object Oriented Methodologies  E.g.. For use case  quiz system. Quiz system Requestration Viewing the question Answering the question Validation Final score Quiz system viewer
  70. 70. 4.Object Oriented Methodologies  Analysis model:  Defines the three object in a system.  Entity object information about the object.  Control object illustrate the functionality of object.  Interface object interact directly with an environment.  Design model:  State transition diagram  Interaction diagram
  71. 71. 4.Object Oriented Methodologies  State transition diagram:  Similar to UML state chart diagram.  It shows the flow of events with in the system.  Jacobson’s method also user Unix symbols.  Interaction diagram:  Similar to UML sequence diagram.  Shows the step by step happenings to accomplish a particular functionality.
  72. 72. 4.Object Oriented Methodologies  Jacobson’s symbols: Send msg Receive a msg Return a msg Send a signal Receive a signal Process Decision Label
  73. 73. 4.Object Oriented Methodologies  Implementation model:  Represents the implementation of a system, finally test model represent test cases, specification & report.
  74. 74. 4.Object Oriented Methodologies  Object-Oriented Business Engineering (OOBE): • Object-oriented business engineering (OOBE) is object modeling at the enterprise level. • Use cases again are the central vehicle for modeling. • It provides traceability throughout the software engineering processes.
  75. 75. 4.Object Oriented Methodologies  OOBE consists of – Analysis phase – Design Implementation phases – Testing phase.  Analysis phase:  Analysis phase defines the system in terms of problem domain object model, requirement model & analysis model.  This reduces the complexity & promotes maintainability over the life of the system.  Analysis process is iterative.  But requirements & analysis model should be stable before moving on to subsequent models.
  76. 76. 4.Object Oriented Methodologies  Design Implementation phases:  Implementation environment must be identified for design model.  It includes Database Management System, distribution of process, available component libraries & graphical user interface tools.  Testing phase:  Several testing levels & techniques are described by Jacobson.  This phase includes unit testing, integration testing & system testing.
  77. 77. 4.Object Oriented Methodologies  Patterns:  A pattern is an instructive information that captures the essential structure and insight of a successful family of proven solutions to a recurring problem that arises within a certain context and system of forces.  The main idea behind using patterns is to provide documentation to help categorize and communicate about solutions to recurring problems.  The pattern has a name to facilitate discussion and the information it represents.
  78. 78. 4.Object Oriented Methodologies  A good pattern will do the following:  It solves a problem  Patterns capture solutions, not just abstract principles or strategies.  It is a proven concept  Patterns capture solutions with a track record, not theories or speculation.  The solution is not obvious  The best patterns generate a solution to a problem indirectly- a necessary approach for the most difficult problems of design
  79. 79. 4.Object Oriented Methodologies  It describes a relationship  Patterns do not just describe modules, but describe deeper system structures and mechanisms.  The pattern has a significant human component .  All software serves human comfort or quality of life; the best patterns explicitly appeal to aesthetics and utility.
  80. 80. 4.Object Oriented Methodologies  More recent patterns encompass all aspects of software engineering, s/w development process, project planning, requirements engineering & s/w configuration management. a. Generative & Non generative patterns b. Pattern template c. Antipatterns
  81. 81. 4.Object Oriented Methodologies  Generative patterns:  It not only a recurring problem, it can tell us how to generate something & can be observed in the resulting system architecture.  Non generative patterns:  Static & passive.  It’ll describe recurring phenomena without necessarily saying how to reproduce them.  Patterns template:  Every pattern must be expressed in the form of a rule which establishes a relationship b/w a context.  It allows to resolve themselves in that context.  Here template  nothing but a rule.
  82. 82. 4.Object Oriented Methodologies  Different patterns template are: 1. Name 2. Context 3. Forces 4. Solution 5. Problem 6. Examples 7. Related patterns
  83. 83. 4.Object Oriented Methodologies  Antipatterns:  Patterns represents a best practice.  Antipatterns represents a worst practice.  Antipatterns come in two ways: 1.Those describing a bad solution to a problem that resulted in bad situation. 2.Those describing how to get out of a bad situation & how to proceed from there to a good solution.  Antipatterns are valuable one, because often it’s used to see & understand the bad solution & also see & understand the good ones.
  84. 84. 4.Object Oriented Methodologies  Capturing patterns:  Patterns should provide not only facts, but it also tell a story that captures the experience they are trying to convey.  A pattern should help it’s users,  comprehend existing systems  Customize systems to fit user needs  Construct new systems  The process of looking for patterns to document is known as pattern mining.
  85. 85. 4.Object Oriented Methodologies  Some guidelines:  Focus on practicability:  Patterns should describe proven solutions to recurring problems rather than the latest scientific results.  Aggressive disregard of originality:  Pattern writers do not need to be the original inventor or discoverer of the solutions that they document.  Non anonymous review:  Pattern submissions are shepherded rather than reviewed. (a person who guides, or watches).  The shepherd contacts the patterns author and discusses with him or how the patterns might be clarified or improved on.
  86. 86. 4.Object Oriented Methodologies  Writer’s workshops instead of presentations:  Rather than being presented by the individual authors, the pattern authors and discusses in writers workshops,  open forums where all attending seek to improve the patterns presented by discussing what they like about them and the areas in which they are lacking.  Careful editing:  The pattern authors should have the opportunity to incorporate all the comments and insights during the shepherding and writers workshops before presenting the patterns in their finished form.
  87. 87. 4.Object Oriented Methodologies  Frameworks:  A framework is a way of presenting a generic solution to a problem that can be applied to all levels in a development.  A single framework typically encompasses several design patterns and can be viewed as the implementation of a system of design patterns.  It is important to recognize that framework & design patterns are two distinctly separate beasts.
  88. 88. 4.Object Oriented Methodologies  Framework is executable software & design patterns represent the knowledge and experience about software.  Frameworks are the physical realization of one or more software pattern solutions.  Patterns are the instructions for how to implement those solutions.
  89. 89. 4.Object Oriented Methodologies  Differences Between Design Patterns and Frameworks:  Design patterns are more abstract than frameworks.  Design patterns are smaller architectural elements than frameworks.  Design patterns are less specialized than frameworks.
  90. 90. 4.Object Oriented Methodologies  The Unified Approach  The idea behind the UA is not to introduce yet another methodology.  The main motivation here is to combine the best practices, processes, methodologies, and Guidelines along with UML notations and diagrams.  UA establishes a unifying & unitary framework around their works by utilizing the Unified Modeling Language (UML).  It’ll be better understanding object oriented concepts & system development.
  91. 91. 4.Object Oriented Methodologies  Motivation of UA:  Here Booch, Rambaugh & Jacobson methods has it’s strength & weakness. Rambaugh Objectmodel Cannot fully express the requirements Jacobson User driven requirement & OO analysis model Not for design Booch Detailed OO Design Not for analysis
  92. 92. 4.Object Oriented Methodologies So motivation of UA is to combine all the three methodologies strength along with UML notation for better understanding OO concepts & system development.
  93. 93. 4.Object Oriented Methodologies  The Unified Approach (UA)  The unified approach to software development revolves around (but is not limited to)the following processes and components.  The UA processes are: – Use-case driven development. – Object-oriented analysis. – Object-oriented design. – Incremental development and prototyping. – Continuous testing
  94. 94. 4.Object Oriented Methodologies  UA Methods and Technology  Unified modeling language (UML) used for modeling.  Layered approach.  Repository for object-oriented system development patterns and frameworks.  Promoting Component-based development.
  95. 95. Processes & Components of Unified Approach
  96. 96. 4.Object Oriented Methodologies  UA Object-Oriented Analysis: Use-Case Driven:  The use-case model captures the user requirements.  The objects found during analysis lead us to model the classes.  The interaction between objects provide a map for the design phase to model the relationships and designing classes.
  97. 97. 4.Object Oriented Methodologies • UA Object-Oriented Design:  Booch provides the most comprehensive object- oriented design method.  However, Booch methods can be somewhat imposing to learn and especially tricky to figure out where to start.  UA realizes this by combining Jacobson et al.'s analysis with Booch's design concept to create a comprehensive design process.
  98. 98. 4.Object Oriented Methodologies  Iterative Development and Continuous Testing:  The UA encourages the integration of testing plans from day 1 of the project.  Usage scenarios or Use Cases can become test scenarios; therefore, use cases will drive the usability testing
  99. 99. 4.Object Oriented Methodologies  Modeling Based on the Unified Modeling Language:  The UA uses the unified modeling language (UML) to describe and model the analysis and design phases of system development.
  100. 100. 4.Object Oriented Methodologies  The UA Proposed Repository:  The requirement, analysis, design, and implementation documents should be stored in the repository, so reports can be run on them for traceability.  This allows us to produce designs that are traceable across requirements, analysis, design, implementation, and testing.
  101. 101. 4.Object Oriented Methodologies  The Layered Approach to Software Development:  Most systems developed with today's CASE tools or client-server application development environments tend to lean toward what is known as two-layered architecture: interface and data workstation Data
  102. 102. 4.Object Oriented Methodologies  Two-Layer Architecture:  In a two-layer system, user interface screens are tied directly to the data through routines that sit directly behind the screens.  Problem with the Two-Layer Architecture:  This approach results in objects that are very specialized and cannot be reused easily in other projects.
  103. 103. 4.Object Oriented Methodologies  Three-Layer Architecture:  Using three layered architecture , we’re able to create objects that represents tangible elements of our business,  Yet are completely independent of how:  they are represented to the user (through an interface) or  how they are physically stored(in a database).
  104. 104. 4.Object Oriented Methodologies  Three layered approach consists of  View or User interface layer  Business layer  Access layer  User Interface layer:  This layer consists of objects with which the user interacts as well as the objects needed to manage or control the interface.  Also known as view layer.
  105. 105. Access Layer Business Layer View Layer Three-Layered Architecture
  106. 106. 4.Object Oriented Methodologies  This layer is typically responsible for two major aspects of the applications:  Responding to user interaction  Displaying business objects.  Responding to user interaction:  The user interface layer objects must be designed to translate actions by the user, such as clicking on a button or selecting from a menu, into an appropriate response.  Displaying business objects:  This layer must paint the best possible picture of the business objects for the user. e.g. list boxes & graph.
  107. 107. 4.Object Oriented Methodologies  Use cases can provide a very useful tool for understanding user interface requirements.  User interface layer’s objects are identified during the object oriented design phase.  Business layer:  Layer contains all the objects that represent the business (both data & behavior).  Responsibilities of the business layer are very straight forward:  Model the objects of the business and how they interact to accomplish the business processes.  When creating the business layer, there’re two important things to note: • Displaying details • Data access details
  108. 108. 4.Object Oriented Methodologies  Displaying details:  Business objects should have no special knowledge of how they are being displayed and by whom.  They are designed to be independent of any particular interface, so the details of how to display an object is exists in the interface layer of the object displaying it.  Data access details:  Business objects also should have no special knowledge of where they come from.  It does not matter whether data are stored and retrieved via SQL or file I/O.  Business objects need to know only to whom to talk about being stored or retrieved.
  109. 109. 4.Object Oriented Methodologies  Business model captures of static and dynamic relationships among a collection of business objects.  Static relationships includes object associations and aggregations.  Dynamic relationships show how the objects interact to perform tasks.  Use cases can provide a tool to capture business objects.  Business objects are identified during object oriented analysis phase.
  110. 110. 4.Object Oriented Methodologies  Access layer:  Layer contains objects that know how to communicate with the place where the data actually reside.  Whether it be a relational database, mainframe, internet or file.  Access layer has two major responsibilities: • Translate request • Translate results  Translate request:  The access layer must be able to translate any data related requests from the business layer into the appropriate protocol for data access.  For example, if customer number 102356 needs to be retrieved, access layer must be able to create the
  111. 111. 4.Object Oriented Methodologies  Translate results:  The access layer also must be able to translate the data retrieved back into the appropriate business objects and pass those objects back up into the business layer.  Access objects are identified during object oriented design phase.
  112. 112. 5.Unified Modeling Language  A model is an abstract representation of a system, constructed to understand the system prior to building or modifying it.  Most of the modeling techniques involve graphical languages.  Static or Dynamic Models: Static Dynamic Model A static model can be viewed as “snapshot" of a system's parameters at rest or at a specific point in time. Is a collection of procedures or behaviors that, taken together, reflect the behavior of a system over time. The classes‘ structure and their relationships to each other frozen in time are examples of static models. For example, an order interacts with inventory to determine product availability.
  113. 113. 5.Unified Modeling Language  Why Modeling?  Models make it easier to express complex ideas.  For example, an architect builds a model to communicate ideas more easily to clients.  Advantages of Modeling:  Models reduce complexity by separating those aspects that are unimportant from those that are important.  Models enhance learning.  The cost of the modeling analysis is much lower than the cost of similar experimentation conducted with a real system
  114. 114. 5.Unified Modeling Language  Manipulation of the model (changing variables) is much easier than manipulating areal system.  Modeling Key Ideas:  A model is rarely correct on the first try.  Always seek the advice and criticism of others.  Avoid excess model revisions, as they can distort the essence of your model. Let simplicity and elegance guide us through the process.
  115. 115. 5.Unified Modeling Language  What Is the UML?  The Unified Modeling Language (UML) is a language for  Specifying  Visualizing  Constructing  Documenting the software system and its components
  116. 116. 5.Unified Modeling Language  What UML is/isn’t?  Is NOT  A process  A formalism  Is  A way to describe your software more precise than English less detailed than code
  117. 117. 5.Unified Modeling Language  What is UML Used For? Trace external interactions with the software. Plan the internal behavior of the application. Study the software structure. View the system architecture. Trace behavior down to physical components.
  118. 118. 5.Unified Modeling Language  UML Diagrams  The UML defines nine graphical diagrams: 1. Class diagram (static) 2. Use-case diagram 3. Behavior diagrams (dynamic)  3.1. Interaction diagram • 3.1.1. Sequence diagram • 3.1.2. Collaboration diagram  3.2. State chart diagram  3.3. Activity diagram 4. Implementation diagram  4.1. Component diagram  4.2. Deployment diagram
  119. 119. 5.Unified Modeling Language  Use Case Diagram:  Use case diagrams are created to visualize the relationships between actors and use cases.  An actor is someoneor some thing that must interact with the system under development.  A use case is a pattern of behavior the system exhibits.  Use cases are written from an actor point of view.  Details what the system must provide to the actor when the use cases is executed.
  120. 120. Use Case Diagram
  121. 121. 5.Unified Modeling Language  Class Diagram  A class diagram describes the types of objects in the system and the various kinds of static relationships that exist among them.  A graphical representation of a static view on declarative static elements.  A central modeling technique that runs through nearly all object-oriented methods.  The richest notation in UML.  A class diagram shows the existence of classes and their relationships in the logical view of a system.
  122. 122. 5.Unified Modeling Language  Essential Elements of a UML Class Diagram  Class  Attributes  Operations  Relationships • Associations • Generalization  Dependency  Realization