Introduction to RUP and Visual Modeling Month Day, Year

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

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

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

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

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

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

Object-Orientation – What Activities Business Processes System Uses

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

Object-Orientation – When During Analysis Design Implementation Documentation Management

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

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

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

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

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

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.

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

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)

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

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

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

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

Use Case 3 Implementation

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Activity Diagram – BUCM

Activity Diagrams – BUCM

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

Activity Diagrams – BUCM

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

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

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

Sequence Diagrams - BUCM

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.

Collaboration Diagrams - BUCM

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

Statechart Diagrams - BUCM

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

Class Diagrams – BUCM Use–Case Diagram

Class Diagrams – BUCM Object Diagram

Class Diagrams – BUCM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

The Other Model Elements Multimedia Files URLS

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