1 / 32

OOA/D, RUP and SSDs

OOA/D, RUP and SSDs. Presented By Dr. Shazzad Hosain. Object-Oriented Analysis and Design (OOA/D). Applying UML and Patterns in OOA/D. “Owning a hammer doesn’t make one an architect” “Knowing an object-oriented language e.g. Java doesn’t make you software architect”

abla
Download Presentation

OOA/D, RUP and SSDs

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. OOA/D, RUP and SSDs Presented By Dr. Shazzad Hosain

  2. Object-Oriented Analysis and Design (OOA/D)

  3. Applying UML and Patterns in OOA/D • “Owning a hammer doesn’t make one an architect” • “Knowing an object-oriented language e.g. Java doesn’t make you software architect” • Knowing OO language is necessary but insufficient first step to create object systems • Knowing how to “think in objects” is also critical

  4. Applying UML • UML stands for Unified Modeling Language • UML is a standard diagramming notation • UML is not OOA/D or a method, it is simply notation • It is not so helpful to learn syntactically correct UML diagram, UML CASE tool, but then not be able to create an excellent design, or evaluate and improve an existing one. • This is harder and more valuable skill • But UML is used as a language to represent, communicate OOA/D with others • We will emphasis on helping you learn the art and science of building object systems, rather than notation

  5. Applying Patterns • How should responsibilities be allocated to classes of objects? • How should objects interact? • What classes should do what? • These are critical questions in the design of a system. • A pattern describes a problemand solution, and given a name. • Examples are Singleton, Adapter, Factory etc. • Singleton Pattern • Context/Problem: Exactly on instance of a class is allowed. Objects need a global and single point of access. • Solution: Define a static method of the class that returns the singleton.

  6. Naming Patterns Improves Communication • Engineers can discuss among themselves a complex principle or design idea with a simple name. Fred: “Where do you think we should place the responsibility for creating a SalesLineItem? I think a Factory.” Wilma: “By Creator, I think Sale will be suitable.” Fred: “Oh, right – I agree”.

  7. Assigning Responsibilities – a “desert island” skill • A critical fundamental ability in OOA/D is to skillfully assign responsibilities to software components. • Why? • It is one activity that must be performed – either while drawing a UML diagram or programming • And it strongly influences the robustness, maintainability and reusability of software components.

  8. What is Analysis and Design? • Analysis emphasizes an investigation of the problem and requirements, rather than a solution e.g. requirement analysis, or object analysis. • Design emphasizes a conceptual solution that fulfills the requirements, rather than its implementation e.g. database design, object design etc. Ultimately designs can be implemented. • Analysis is to do the right thing and design is to do the thing right.

  9. What is OO Analysis and Design? • OO analysis emphasizes on finding and describing the objects – or concepts – in the problem domain, e.g. Book, Library, Patronetc. in LibSys system. • OO design emphasizes on defining software objects and how they collaborate to fulfill the requirements, e.g. a Book software object may have a title attribute and a getChapter method.

  10. An Example • Player rolls two die, if the total is seven, they win; otherwise, they lose.

  11. Procedural Implementation DiceGame Class Main function fv1 = random () fv2 = random () sum = fv1 + fv2 if (sum == 7) print (“you win”) else print (“you lose”) End main End Class

  12. Define Use Cases • Play a Dice Game: A player picks up and rolls the dice. If the dice face value total seven, they win; otherwise, they lose.

  13. Define a Domain Model Fig 1.3 Partial domain model of the dice game

  14. Define Interaction Diagrams Fig 1.3 Interaction diagram illustrating messages between software objects

  15. Define Design Class Diagrams Fig 1.5 Partial design class diagram

  16. Die Class int faceValue = 0 ; public int getFaceValue () { return faceValue ; } public void roll () { faceValue = random () ; } End Class DiceGame Class Die die1 = new Die () ; Die die2 = new Die () ; public void play () { die1.roll () ; die2.roll () ; int fv1 = die1.getFaceValue () ; int fv2 = die2.getFaceValue () ; if (fv1 + fv2 == 7) print (“you win”) else print (“you lose”) } End Class

  17. Die Class int faceValue = 0 ; public int getFaceValue () { return faceValue ; } public void roll () { faceValue = random () ; } End Class DiceGame Class Die die1 = new Die () ; Die die2 = new Die () ; public void play () { die1.roll () ; die2.roll () ; int fv1 = die1.getFaceValue () ; int fv2 = die2.getFaceValue () ; if (fv1 + fv2 == 7) print (“you win”) else print (“you lose”) } End Class

  18. Player Class string name ; DiceGame dg = new DiceGame() ; public void plays () { dg.play () ; } End Class

  19. Rational Unified Process (RUP)

  20. Rational Unified Process (RUP) • A kind of iterative and incremental development.

  21. Rational Unified Process (RUP) Figure 2.2 Iterative feedback and adaptation leads towards the desired system. The requirements and design instability lowers over time.

  22. The UP Phases and Schedule-Oriented Terms • Inception – Approximate vision, business case, scope, vague estimates. • Elaboration – Refined vision, iterative implementation, resolution of high risks, …. • Construction – Iterative implementation of the remaining lower risk and easier elements and preparation for deployment. • Transition – beta tests, deployment

  23. UP Disciplines

  24. Use-Case Model: Drawing System Sequence Diagrams In theory, there is no difference between theory and practice. But, in practice, there is.

  25. System Sequence Diagrams (SSDs) • A system sequence diagram is a picture that shows, for a particular scenario of a use case, the events that external actors generate, their order, and inter-system events.

  26. Example of SSD

  27. SSDs and Use Cases

  28. Naming System Events

  29. Showing Use Case Text

  30. SSD Suggestions • An SSD should be done for the main success scenario of the use case, and frequent or complex alternative scenarios. • The terms (operations, parameters, return data) shown in SSD are terse. These may need proper explanation. In that case you can use glossary. There should be truly meaningful use, otherwise it is simply low-value unnecessary work. • Not necessary to create SSDs for all scenarios of all use cases. • It should only take a few minutes or an half hour to create the SSDs.

  31. References • Chapter 1, 2, 9 of “Applying UML and Patterns – An Introduction to Object-Oriented Analysis and Design and the Unified Process” – by Craig Larman

More Related