1 / 37

How to hear this lecture

How to hear this lecture. Click on the icon: to hear the narration for each slide. fisher.osu.edu. Fisher logo. Analysis Dr. Rajiv Ramnath Director Collaborative for Enterprise Transformation and Innovation (CETI)

twilken
Download Presentation

How to hear this lecture

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. How to hear this lecture Click on the icon: to hear the narration for each slide. Partnership for Performance

  2. fisher.osu.edu Fisher logo Analysis Dr. Rajiv Ramnath Director Collaborative for Enterprise Transformation and Innovation (CETI) Department of Computer Science and Engineering, College of Engineering The Ohio State University Ramnath.6@osu.edu http://www.ceti.cse.ohio-state.edu Partnership for Performance Partnership for Performance

  3. UML – A Notation for Capturing Software Engineering Work Products

  4. Uses of UML • As Sketch • As Blueprint • As Programming Language • Concepts (e.g. in a domain model) • Specification (of software components) • Implementation (tied to a language) Ref: Applying UML and Patterns, Craig Larman, Safari Partnership for Performance

  5. Use Case Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  6. Use Case Diagram Showing <<Extends>> Ref: http://www.agilemodeling.com/images/models/useCaseDiagram.jpg Partnership for Performance

  7. Use Case Diagram Showing Uses Intake Processor <<uses>> Client System Partnership for Performance

  8. Class Diagram Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  9. Association Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  10. Object Diagram Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  11. Sequence Diagram Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  12. Collaboration (Communication) Diagram Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  13. State Diagram Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  14. Activity Diagram Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  15. Advanced UML – 1 Static Operations Aggregation Composition (cannot exist outside of) Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  16. Advanced UML - 2 Interfaces Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  17. Advanced UML - 3 Interaction Overview Diagram Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  18. Advanced UML – 4 Swimlanes Ref: http://www.agilemodeling.com/style/activityDiagram.htm Partnership for Performance

  19. Package Diagram (Package == Namespace) Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  20. Deployment Diagram Ref: UML Distilled, Martin Fowler: Safari Partnership for Performance

  21. Analysis

  22. What is Analysis? • Analysis = Understanding: • In general: separating the target of the analysis into its component parts • Understanding static structure • Understanding dynamic behavior • Capturing this in documents or tacitly • Domain Analysis: Understanding the domain • Static structure aka Domain Model • Problem Analysis: Understanding the problem • Solution Analysis: Defining the solution • Interactions at the system boundary, no deeper Partnership for Performance

  23. Process and Techniques • Focus on target of analysis (not a solution to an immediately perceived problem) • Do not introduce design • Be iterative and incremental • Techniques: • Reuse existing models (CBM?, Porter? Value Chain?) • Create a categorized list of things in the domain • Create narratives and extract nouns (objects) and verbs (responsibilities) • Build class and object models for static structure • Use sequence, collaboration, state and activity diagrams for dynamic behavior • Use CRC Cards to socialize the process of analysis Partnership for Performance

  24. Analysis Using Structured Processes

  25. Analysis Work-Products • Analysis Guidelines • Domain Analysis • Part 1 of project • Create a Domain Model using an object diagram • Problem Analysis • Start with Problem Statement (note overlap with Requirements) • Use a problem object diagram to describe the static aspects of the problem • Explain problem scenarios using sequence, collaboration, activity or state diagrams • Solution Analysis • Start with Use Cases (note overlap with Requirements) • Explain scenarios using sequence, collaboration, state, or activity diagrams • Describe interface objects using object and class diagrams Partnership for Performance

  26. Notes on Analysis Guidelines • Done jointly by the developers - team leader and analysts • Keep minimal and not overly restrictive • Work product guidelines • Which work products • Templates • Naming conventions • Diagramming conventions • Process guidelines • How should the team do the analysis • Create scenarios from use cases, possible sketch UI screens, look at the as-is system • CRC Cards Partnership for Performance

  27. Notes on Solution Scenarios • Elaboration of a Use Case (one path through a use case) • Tradeoff: New use case vs. adding a scenario to existing • Use case + Assumptions + Outcomes • How to create: • Identify all the different outcomes in the use case • Techniques • Use domain experts, look at similar examples • Web reservation systems (itn.com), ATM systems • Reviewing the Problem statement • Walking through case studies or storyboards • Successful and unsuccessful outcomes • Look at each subclass of the actors involved Reference: Developing Object-Oriented Software – An Experience-Based Approach, Chapter on Analysis Partnership for Performance

  28. Notes on Sequence Diagrams • Graphical representation of each scenario (could combine scenarios, or explore only major ones)). UML notation. • Used to discover or validate class responsibilities • Object messages or internal activities • Components • Object • Time line • Messages - synchronous or asynchronous • loops, returns, internal • Advice • Keep messages in English • Feel free to annotate to properly describe the problem Reference: Developing Object-Oriented Software – An Experience-Based Approach, Chapter on Analysis Partnership for Performance

  29. Notes on Object and Class Models • Use the sequence diagrams to derive and validate this • UML Notation • Components • Objects and Classes • Relationships (aggregation (component), IS-A (inheritance), association (relationship)) • Attributes • Methods • Question: Why is an “object” model used in analysis, not a class model? Reference: Developing Object-Oriented Software – An Experience-Based Approach, Chapter on Analysis Partnership for Performance

  30. Notes on Domain Model • Illustrates important business concepts • Used in analysis • Often serves as software business objects – an interface layer in design • Along with problem object model Ref: Applying UML and Patterns, Craig Larman, Safari Partnership for Performance

  31. Domain Model - Example Ref: Applying UML and Patterns, Craig Larman, Safari Partnership for Performance

  32. Notes on CRC Cards - Template Ref: A Laboratory For Teaching Object-Oriented Thinking Kent Beck, Ward Cunningham – electronic reference Partnership for Performance

  33. Notes on CRC Cards - Example Ref: A Laboratory For Teaching Object-Oriented Thinking Kent Beck, Ward Cunningham – electronic reference Ref: Applying UML and Patterns, Craig Larman, Safari Partnership for Performance

  34. Agile Analysis

  35. Agile Analysis – Mostly About Values and Practices, Less About Techniques • An integral part of requirements definition – not a separate phase • Model with others • Model in small increments • Collective ownership • Purpose determines model • Create several models (in parallel) • Use simple tools • Prove it with code • Single source of information • Display publicly • Active stakeholder involvement Ref: Visual Studio Team System: Better Software Development for Agile Teams, Will Stott; James W. Newkirk, Safari. Agile 101.pdf – ThoughtWorks Inc. – CSE 757 Course Site Partnership for Performance

  36. Agile UML Modelling – Use Case Sketch Partnership for Performance

  37. Thank you! Partnership for Performance

More Related