How to hear this lecture

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