1. Introduction to RUP and Visual Modeling Month Day, Year

2. Agenda Training Plan Overview Introduction Software Development Object Orientation Rational Unified Process Visual Modeling The Model The Models Model Evolution Next Steps

3. Training Plan Overview Introduction Using Rational Administrator Using ClearCase Using ClearQuest Using Rational Rose XDE Identifying & Creating Use-Cases – Part 1 Identifying & Creating Use-Cases – Part 2 Detailing Requirements with RequisitePro Actors and Use-Case Diagrams Sequence and Statechart Diagrams Collaboration and Class Diagrams Integration and Development with the.NET Framework

4. Software Development Simplicity to Complexity Transient Procedures & Data Structures Persistent Procedures & Data Multidimensional Code –Modules –Sub-routines Multidimensional Structures –Databases –Normalization: The process of organizing data to minimize redundancy and isolate data so that additions, deletions, and modifications of a field can be made in just one table and then propagated through the rest of the database via the defined relationships

5. Software Development Architecture Procedural Client / Server Objects Multi-tiered Distributed Network

6. Object-Orientation - Why Perception Complexity to Simplicity Real World Orientation Classification –Commonality –Patterns Organization –Responsibilities Uniformity –Individuality

7. Object-Orientation – Who Users Analysts Designers Programmers Testers Project Managers

8. Object-Orientation – What Activities Business Processes System Uses

9. Object-Orientation – What Object A self-contained entity that consists of both data and procedures to manipulate the data Actors Entities Processes

10. Object-Orientation – When During Analysis Design Implementation Documentation Management

11. Object-Orientation – Where In Workflow Requirements Designs Implementations Documentation Plans

12. Object-Orientation - Why Complexity to Simplicity Real World Orientation Activities –People –Entities Advance Software Development Privilege Responsibility

13. Object-Orientation - Why Complexity to Simplicity Classification Commonality –Patterns –Attributes –Functionality –Abstraction - The process of picking out common features of objects and procedures –Inheritance –Encapsulation - The process of combining elements to create a new entity

14. Object-Orientation - Why Complexity to Simplicity Organization Responsibilities –Management –Passive vs. Active –Job Description –API –Workspace –Attributes –Collaboration –Performance Evaluation

15. Object-Orientation - Why Complexity to Simplicity Uniformity Individuality –Specialization –Composition –States –State Change –Polymorphism –The ability to redefine methods for derived classes –The ability to derive composition from different objects

16. Object-Oriented Programming A type of programming in which programmers define not only the data type of a data structure, but also the types of operations (functions) that can be applied to the data structure. In this way, the data structure becomes an object that includes both data and functions. In addition, programmers can create relationships between one object and another. For example, objects can inherit characteristics from other objects.

17. Rational Unified Process (RUP) The Process A collected body of software engineering practices designed for Object-Oriented software development Executable architectural prototypes that gradually evolve to become the final system in later iterations Promotes tackling risks early in projects RUP is itself implemented iteratively

18. Rational Unified Process (RUP) The Development Case A specialization of the RUP process to the organization or project Development Artifacts In RUP are generally not documents RUP discourages the systematic production of paper documents Supported by IBM Rational Tools Rose/XDE Requisite Pro ClearCase (Configuration Management) ClearQuest (Defect/Change Tracking)

19. Rational Unified Process (RUP) The Development Case The Product Disciplines –Workflows The Document Development Artifacts Workflow Processes Roles The Development Artifacts The Model Models –Model Elements Databases Source Code Miscellaneous –Multimedia Files –URLS Documents –Specifications –Plans

20. RUP – Best Practices Develop Iteratively Manage Requirements Use Component Architectures Model Visually Continuously Verify Quality Manage Change

21. RUP is Use Case-Driven DisciplineUse Case Usage Project ManagementBasis for iteration planning Business ModelingBusiness use cases used to define and structure the business processes RequirementsWhere system use cases are formally defined and structured Analysis & DesignUse cases are “realized” – define how use cases are performed by interacting objects in design model ImplementationUse cases implemented by design classes TestBasis for Test Cases and Test Procedures – system verified by performing each use case DeploymentFoundation for Users Guide

22. Use Cases Assigned to Iterations Iteration 1Iteration 2Iteration 3 Product A Use Case 1 All scenarios Use Case 2 All scenarios Use Case 3 “Happy Day” scenario Alternative Flow 1Alternative Flow 2 Product B Use Case 4 All scenarios Use Case 5 “Happy Day” scenario All Alternative Flows Use Case 6 All scenarios

23. Use Case 3 Implementation

24. RUP – Model Overview Business ModelingSystem Use Case Modeling Design Modeling Who?Business Process Analyst System AnalystDesigner/Developer What?Business ModelSystem Use Case ModelDesign Model Where?Rose and ReqPro Rose/XDE When?First 3 iterationsFirst 4 iterationsAll iterations Why?  Define business processes  Identify points of automation  Define functional requirements  Start transition to design  Define Components  Integrate With Code

25. RUP – Basic Steps Create Software Development Plan Create Project Model Create visual sub-models –Business Use-Case Model –System Use-Case Model –Design Model –Implementation Model Create requirements sub-model Knowledge Acquisition Model Develop Code Test

26. Software Development Plan Create Vision and Features Identify Business/System Use-Cases Prioritize Business/System Use-Cases Create Iteration Plan and Schedule Create Supporting Process Plans and Guidelines

27. Create Business Use-Case Model Identify Business Use-Cases Brainstorming major business processes Decompose using activity diagrams For each Business Use-Case create: Business Activity Diagrams Business Use-Case Diagrams Business Sequence/Collaboration Diagrams Business Statechart Diagrams Business Class Diagrams Create Business Use-Case Requirements

28. Create System Use-Case Model Identify points of automation For each System Use-Case create: System Use-Case Diagrams System Activity Diagrams System Sequence/Collaboration Diagrams System State Transition Diagram System Statechart Diagrams Analysis Class Diagrams UI Design Diagrams/Mockups/Prototype Create Use-Case Requirements

29. Create Design Model Import Rose Requirements Model into XDE Create Sequence/Collaboration Diagrams Transform Objects into Classes Create Action-level Activity Diagrams Create Design Class Diagrams Create Data Model/Database

30. Create Implementation Model Integrate Code with XDE Model Forward engineer Implementation Classes Reverse engineer existing code and frameworks Write Code Unit Test

31. Test Define Evaluation Mission Test Ideas Verify Test Approach Test & Evaluate Achieve Acceptable Mission Improve Test Assets

32. Artifact Review Development Case Software Development Plan Iteration 1 Plan –Plan –Schedule Business Modeling Guidelines Knowledge Acquisition Worksheet

33. The Models Business Use-Case Model Identify the tasks, activities, roles and entities that accomplish business goals Identify Automation Points Use-Cases (Automatable/ed Business Use-Cases) –Actors (Business Workers) –Entities (Business Entity) Use-Case Model Models User – System Interaction Clear, concise overview of the purpose and functionality of the system All functional and non-functional requirements are mapped to at least one use-case and visa-versa

34. The Model Design Model Use-Case Analysis Objects Design Classes Object Evolution Identify Mechanisms and Elements Architectural Analysis Assess Viability of Architectural Proof-of-Concepts Implementation Model Construct Architectural Proof of Concepts Prototype User-Interface Implement Classes

35. The Models Deployment Model What where Test Model Test Cases Test Classes Test Scripts Test Data Test Results

36. Model Evolution A process of working out or developing A process of change in a certain direction A process of continuous change from a lower, simpler, or worse to a higher, more complex, or better state

37. Model Evolution Modeling Diagrams Activity Sequence Collaboration Statechart Class –Use-Case –Object –Class Requirements Multimedia

38. Model Evolution Model Lineage Business Use-Case (BUCM) Use-Case (UCm) –Design (DM) –Implementation (IM) –Deployment (DM) –Test ™

39. Activity Diagram – BUCM Primary Diagram for Requirements Specification Elements Activities Actions Transitions Decisions Synchronizations States

40. Activity Diagram – BUCM

41. Activity Diagrams – BUCM

42. Swimlanes Integration of the division of activity between business actors / actors into the Business Use- Case / Use-case activity Recognition of collaborating objects

43. Activity Diagrams – BUCM

45. Object Flows Integration of Business Entities / Entities into the Business Use-Case / Use-case activity Recognition of collaborating objects

46. Sequence Diagrams - BUCM Show object interaction in a time- based sequence Establish the roles of objects Provide essential information to determine class responsibilities and interfaces

47. Sequence Diagrams - BUCM Simplicity Plain English Shows interaction between Business Actors –Workers Business Entities

48. Sequence Diagrams - BUCM

49. Collaboration Diagrams - BUCM Used to show how objects interact to perform a particular behavior Used to define and clarify the roles of the objects that perform a particular flow of events Better suited to depicting simpler interactions of smaller numbers of objects.

50. Collaboration Diagrams - BUCM

52. Statechart Diagrams - BUCM Used To Model Dynamic Behavior Event-driven behavior Are required for objects who call events and signal events to implement their operations State-dependent behavior Are required for active objects whose behavior varies base on their state Are not required for passive objects whose behavior does not vary with their state

53. Statechart Diagrams - BUCM

55. Class Diagrams – BUCM Models the static structure of the model Objects / Classes Internal structure –Attributes –Operations Relationships to other classes

56. Class Diagrams – BUCM Use–Case Diagram

57. Class Diagrams – BUCM Object Diagram

58. Class Diagrams – BUCM

59. Activity Diagrams - UCM Simple Plain English Details interaction activity between Actors (Business Workers) System (Computer)

60. Sequence Diagrams - UCM Simple Plain English Shows interaction between Actors (Business Workers) System (Computer)

61. Other Diagrams - UCM Collaboration Statechart Class Use-Case Object Simple Plain English

62. Activity Diagram – DM - Analysis Defining division of actions between objects for obtaining a particular result from the system Detailed Actions Requirements –Preconditions –Postconditions

63. Sequence Diagram - DM - Analysis Defining interaction of objects for obtaining a particular result from the system Simple messages Synchronization Period

64. Collaboration Diagrams - DM - Analysis Shows collaboration of objects for obtaining a particular result from the system Simple Messages Easy to Create F6 Layout

65. Statechart Diagrams - DM - Analysis Shows achievable states of the objects within the system Simple

66. Class Diagrams - DM - Analysis Show the static state of objects Structure Simple attributes Simple operations Relationships

67. Activity Diagram – DM - Design Defining internal actions of an object to produce a particular result

68. Sequence Diagram - DM - Design Defining interaction of objects for obtaining a particular result from the system Assignment Simple messages become detailed messages / procedure calls to specific object operations Programming Notation

69. Collaboration Diagrams – DM - Design Shows collaboration of objects for obtaining a particular result from the system Detailed Messages / Procedure Calls to specific object operations

70. Statechart Diagrams – DM - Design Shows achievable states of the objects within the system Detailed Internal Sub-States

71. Class Diagrams - DM - Design Show the static state of classes Structure Detailed attributes Detailed operations Relationships Detailed

72. Traceability The ability to trace a project element to other related project elements, especially those related to requirements

73. The Other Model Elements RequisitePro Requirements Business Use-Case Use-Case Class –Object –Class Shareholder Requests Benefits Features Supplementary Business Goal Business Rule Interface Other –Glossary

74. The Other Model Elements Views Attribute Matrix –Requirement vs. Attribute –Illustrates the relationships between requirements and their attributes Traceability Matrix –Requirement vs. Requirement –Illustrates the relationships between requirements of the same or different types Traceability Tree –Requirement vs. Requirement –Displays all internal and external requirements traced to or from a requirement

75. RequisitePro – Requirements Stakeholder Request Any type of requests a stakeholder might have on the system to be developed or any type of external parameter to which the system must comply Feature Based on the benefits listed in your problem statements Supplementary Specifications System requirements that are not readily captured in behavioral requirements artifacts such as use-case specifications Glossary Item Provide a consistent set of definitions

76. RequisitePro – Requirements Stakeholder Requests Any type of requests a stakeholder might have on the system to be developed or any type of external parameter to which the system must comply Results of stakeholder interviews Results from requirements elicitation sessions and workshops Change Request Statement of work Request for proposal Mission statement Problem statement Business rules Laws and regulations Legacy systems Business models

77. RequisitePro – Requirements Features Abilities based on the benefits listed in your problem statements Examples FEATURE1: Ability to save and restore sort and filter criteria FEATURE2: Ability to save a RequisitePro document as a Microsoft® Word® document. FEATURE3: Ability to see deleted requirements in a view window.

78. RequisitePro – Requirements Supplementary Specifications System requirements that are not readily captured in behavioral requirements artifacts such as use-case specifications Legal and regulatory requirements, and application standards Quality attributes of the system to be built, including usability, reliability, performance, and supportability requirements Other requirements such as those for operating systems and environments, compatibility with other software, and design constraints

79. RequisitePro – Requirements Glossary Provide a consistent set of definitions Analysts –Project-specific terms –Clearly define business rules –Ensure that requirement specifications make correct and consistent use of those terms Developers –Terms defining defining the design and implementation classes, database tables, user-interfaces… Course developers and technical writers –Training material and documentation using recognized terminology

80. RequisitePro – Requirements Business Goal Describe the desired value of a particular measure at some future point in time and can therefore be used to plan and manage the activities of the business Attributes Property Name Brief Description UML Representation Business Rule Define a specific constraint or invariant that must be satisfied by the business May apply always (invariants) or only under a specific condition –If the condition occurs, the rule becomes valid, and must therefore be complied with. Do not conflict Present an accurate picture of the principles that govern the way business is done Attributes Structural Constraints Behavioral Constraints

81. RequisitePro – Requirements Interface Requirements Graphical –Accessibility –Branding Non-Graphical –Programmable

82. The Other Model Elements Multimedia Files URLS

83. Next Steps Homework Explore RUP Classes Ahead Using Rational Administrator Using ClearCase Using ClearQuest Using Rational Rose XDE Identifying & Creating Use-Cases – Part 1 Identifying & Creating Use-Cases – Part 2 Detailing Requirements with RequisitePro Actors and Use-Case Diagrams Sequence and Statechart Diagrams Collaboration and Class Diagrams Integration and Development with the.NET Framework