Unified Modeling Language

1. Unified Modeling Language UML and the design of Object-Oriented Information Systems Professor Randy Guthrie Randy Guthrie – Microsoft Corporation

2. About Your Instructor Randy Guthrie - Cal Poly Pomona

3. Your Instructor • 15 Years Industry Experience • Contract Administrator • Project Manager • Financial Analyst • 9 Years University Teaching Experience • 1 Year with Microsoft Corporation Randy Guthrie - Cal Poly Pomona

4. Your Instructor • My Family • Married 29 years • Six Children • three married • Three in college • one still in school Randy Guthrie - Cal Poly Pomona

5. Randy Guthrie - Cal Poly Pomona

6. Where I Live Denver, Colorado Randy Guthrie - Cal Poly Pomona

7. Colorado Randy Guthrie - Cal Poly Pomona

8. My Home in Denver(Winter) Randy Guthrie - Cal Poly Pomona

9. Overview Randy Guthrie - Cal Poly Pomona

10. Rational Unified Process (RUP) • Four Stages: • Inception • Elaboration • Construction • Transition Randy Guthrie - Cal Poly Pomona

11. RUP - Inception • Making the business case to management • High level goals of the project • Rough estimates of costs & benefits • Rough estimates of resource commitments Randy Guthrie - Cal Poly Pomona

12. RUP - Elaboration • Better definition of overall goals of project • Iterative implementation of core architecture • Resolution of high risks • Identification of most of the requirements • Realistic estimates Randy Guthrie - Cal Poly Pomona

13. RUP - Construction • Iterative implementation of lower-risk elements • Preparation for deployment • Training • Hardware installation & test Randy Guthrie - Cal Poly Pomona

14. RUP - Transition • Beta or limited-release testing • Deployment Randy Guthrie - Cal Poly Pomona

15. RUP & Iterations Randy Guthrie - Cal Poly Pomona

16. RUP & Iterations Randy Guthrie - Cal Poly Pomona

17. Unified Process • Iterative Development • software/system developed in iterations (cycles) • each iteration • critical use cases developed first • two-four weeks duration • based on use cases • fully-dressed use cases • domain model • robustness diagram • sequence diagram • class diagram • working code • tested code Randy Guthrie - Cal Poly Pomona

18. Unified Process • Each iteration completes a portion of the system • client evaluates software at each iteration • changes are incorporated into next iteration • cycle continues until system is complete Randy Guthrie - Cal Poly Pomona

19. Unified Process Prototype Screens Domain Model Casual / Full Dress Use Case Unified Process / Iterative Development Brief Use Cases Event Analysis Rank Use Cases Robustness Diagram Code and Test Sequence Diagram Class Diagram Randy Guthrie - Cal Poly Pomona

20. Unified Process • Some Best Practices • Iterative Development • Project developed in 2-4 week phases • Called “time-boxes” • Use of software design “patterns” • GRASP • Gang of Four • Many others Randy Guthrie - Cal Poly Pomona

21. Analysis Phase • Exploring the “problem domain” • Defining system and problem boundaries • What is “in-scope” vs. “out-of-scope” • Discovering system requirements Randy Guthrie - Cal Poly Pomona

22. Design Phase • Creating a conceptual solution • Identifying software classes • Assigning responsibilities to the software classes Randy Guthrie - Cal Poly Pomona

23. Design Phase • Software Classes have two types of responsibility: • “knowing” (attributes / data) • “doing” (behavior / methods) • Assigning responsibilities to classes is a critical activity of software design • In other words, deciding where the variables and operations go is really important Randy Guthrie - Cal Poly Pomona

24. Analysis and Design • Are done at the same time • Most analysis is completed during elaboration phase during early iterations Randy Guthrie - Cal Poly Pomona

25. What Is the Unified Modeling Language (UML) • A standardized set of documentation and diagramming techniques that are useful for analyzing and designing information systems that will be implemented using object-oriented software Randy Guthrie - Cal Poly Pomona

26. Rational Unified Architecture Randy Guthrie - Cal Poly Pomona

27. Rational Unified Architecture End-user Functionality Programmers Logical View Development View Scenarios Process View Physical View Integrators Performance Scalability System Engineers Topology/Communications Randy Guthrie - Cal Poly Pomona

28. Logical Architecture • Supports Functional Requirements • what services the system should provide to the users • Focus on objects and object classes • class diagrams Randy Guthrie - Cal Poly Pomona

29. Process Architecture • Specifies non-functional requirements • performance • availability • fault tolerance • Specifies how functional requirements will be met Randy Guthrie - Cal Poly Pomona

30. Development Architecture • Focuses on how the actual software modules/class are organized • software structure • Object Oriented or structured • three-tier architecture Randy Guthrie - Cal Poly Pomona

31. Physical Architecture • Addresses physical infrastructure and topologies for system • hardware/software platforms • networks • terminals • protocols • storage media • backup / recovery Randy Guthrie - Cal Poly Pomona

32. Scenarios • All four views are integrated (related) through “scenarios” • Scenario is a story about how the system is used • sometimes referred to as “use cases” Randy Guthrie - Cal Poly Pomona

33. Use Cases Stories about how a feature is used to complete a task Randy Guthrie - Cal Poly Pomona

34. Use Case • Not part of UML and not OO • Text Document, not a “diagram” • Focuses on one task / feature • Can be high level and brief • Can be low-level and detailed • Typically avoids mention specific technology such as “scan bar code” Randy Guthrie - Cal Poly Pomona

35. Use Case • Three general types of use case • Brief: one paragraph summary • Casual: information paragraph format– multiple paragraphs cover various scenarios • Detailed (full dress): formal structure Randy Guthrie - Cal Poly Pomona

36. Detailed Use Case • Sections of Detailed Use Case: • Primary Actor • Stake Holders and Interests • Preconditions • Success Guarantees (Post Conditions) • Main Scenario (basic flow) • Extensions (alternative flows) Randy Guthrie - Cal Poly Pomona

37. Use Case • Optional Sections • Special Requirements • Technology and Data Variations List • Frequency of Occurrence • Open Issues Randy Guthrie - Cal Poly Pomona

38. Use Case • Primary Actor • the person that is interacting directly with the system (entering data and receiving output) • Sometimes called the “user” Randy Guthrie - Cal Poly Pomona

39. Use Case • Stakeholders and Interests • individuals and entities that have an interest in the successful completion of the use case • Includes the person triggering the event if not the user • Usually people/roles, but can also be organizations • helps to define what should be included in use case Randy Guthrie - Cal Poly Pomona

40. Use Case • Preconditions • a statement describing environmental conditions that must always be true before beginning the use case scenario • example: must have an account with the bank before you can deposit money Randy Guthrie - Cal Poly Pomona

41. Use Case • Success Guarantees (Post Conditions) • State what must be true on successful completion of the use case • Describes what useful function the system performed and/or what thing of value was delivered to the customer • Describes the system state, data storage, and activities completed Randy Guthrie - Cal Poly Pomona

42. Use Case • Main Success Scenario (basic flow) • numbered steps describing both user and system behavior and interaction • interactions • validation • state changes • write in third person (sports announcer) Randy Guthrie - Cal Poly Pomona

43. Use Case • Extensions (Alternative Flows) • Similar format as main success scenario • Identifies what to do when there is a problem or failure in main success scenario • Numbers correspond to step in main success scenario Randy Guthrie - Cal Poly Pomona

44. Use Case • Special Requirements • Identifies any non-functional requirements, quality / performance attributes, or other constraint • language • time constraints • business rules Randy Guthrie - Cal Poly Pomona

45. Use Case • Technology and Data Variations List • known technology requirements • operating system • input/output devices ie: scanner, bar code, etc. • interfaces / links Randy Guthrie - Cal Poly Pomona

46. Exercise 1 – Full Dress Use Case • Write a “full-dress” use case for withdrawing funds from a bank ATM Randy Guthrie - Cal Poly Pomona

47. Which use cases should you develop first? Randy Guthrie - Cal Poly Pomona

48. Ranking Use Cases • In iterative development, you develop ( the most critical use cases first • find out early about critical problems • can cancel with minimal investment • more schedule/budget flexibility when complicated parts of system are done early • later project cost /schedule estimates will be more accurate Randy Guthrie - Cal Poly Pomona

49. Ranking Use Cases • Three Criteria • Risk • Coverage • Criticality Randy Guthrie - Cal Poly Pomona

50. Use Case Risk • Technical Risk • cutting edge technology • not a lot of in-house expertise • Scope Risk • size of effort • Cost Risk • cost of hardware/software • cost of outside labor/consulting Randy Guthrie - Cal Poly Pomona