Introduction to RUP and Visual Modeling Month Day, Year

IntroductiontoRUP and Visual Modeling

Month Day, Year

AgendaTraining Plan OverviewIntroduction

Software DevelopmentObject OrientationRational Unified ProcessVisual Modeling

• The Model• The Models• Model Evolution

Next Steps

Training Plan OverviewIntroductionUsing Rational AdministratorUsing ClearCaseUsing ClearQuestUsing Rational Rose XDEIdentifying & Creating Use-Cases – Part 1Identifying & Creating Use-Cases – Part 2Detailing Requirements withRequisiteProActors and Use-Case DiagramsSequence and Statechart DiagramsCollaboration and Class DiagramsIntegration and Development with the .NET Framework

Software DevelopmentSimplicity 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 DevelopmentArchitecture

ProceduralClient / ServerObjectsMulti-tiered• Distributed Network

Object-Orientation - WhyPerception

Complexity to Simplicity• Real World Orientation• Classification

– Commonality– Patterns

• Organization– Responsibilities

• Uniformity– Individuality

Object-Orientation – WhoUsersAnalystsDesignersProgrammersTestersProject Managers

Object-Orientation – WhatActivities

Business ProcessesSystem Uses

Object-Orientation – WhatObject

A self-contained entity that consists of both data and procedures to manipulate the data• Actors• Entities• Processes

Object-Orientation – WhenDuring

AnalysisDesignImplementationDocumentationManagement

Object-Orientation – WhereIn Workflow

RequirementsDesignsImplementationsDocumentationPlans

Object-Orientation - WhyComplexity to Simplicity

Real World Orientation• Activities

– People– Entities

Advance Software Development• Privilege• Responsibility


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

DAIDS Protocol Registration Checklist

- Date of Submission : Date- Number of Pages (including cover) : Integer- Main Site Name : String- Main Site Number(s)- Affliated Site Number(s) : Integer- Protocol Number- Version Number : Integer- Sub-Study Protocol Number (if applicable)- E-mail Address- Investigator of Record (IoR)- Study Coordinator- Telephone Number- New Protocol Registration- Amendment Protocol Registration- Corrected Materials- Deregistration- Pre-Review of Site Informed Consent- Other- English Translation of Non-English Local Language IC- Form FDA 1572- IoR Curriculum Vitae (CV)- Documentation of Continuing IRB/EC Review

+ new ( )+ save ( )


Organization• Responsibilities

– Management– Passive vs. Active

– Job Description– API

– Workspace– Attributes

– Collaboration– Performance Evaluation


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 ProgrammingA 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 developmentExecutable architectural prototypes that gradually evolve to become the final system in later iterationsPromotes tackling risks early in projectsRUP is itself implemented iteratively

Rational Unified Process (RUP)The Development Case

A specialization of the RUP process to the organization or project

Development ArtifactsIn RUP are generally not documents

• RUP discourages the systematic production of paper documents

Supported by IBM Rational ToolsRose/XDERequisite ProClearCase (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 PracticesDevelop IterativelyManage RequirementsUse Component ArchitecturesModel VisuallyContinuously Verify QualityManage Change

RUP is Use Case-DrivenDiscipline Use Case Usage

Project Management

Basis for iteration planning

Business Modeling

Business use cases used to define and structure the business processes

Requirements Where system use cases are formally defined and structured

Analysis & Design Use cases are “realized” – define how use cases are performed by interacting objects in design model

Implementation Use cases implemented by design classes

Test Basis for Test Cases and Test Procedures – system verified by performing each use case

Deployment Foundation for Users Guide

Use Cases Assigned to IterationsIteration 1 Iteration 2 Iteration 3

Product A Use Case 1 All scenarios

Use Case 2 All scenarios

Use Case 3 “Happy Day” scenario

Alternative Flow 1

Alternative 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 ImplementationIteration 1 Iteration 2 Iteration 3 Iteration 4 Iteration 5

B usiness M ode ling

R equ irem ents

Im plem enta tion

Test

A na lysis & D esign

D eploym ent

C onfigura tion & C hange M anagem ent

RUP – Model OverviewBusiness Modeling System Use Case

ModelingDesign Modeling

Who? Business Process Analyst

System Analyst Designer/Developer

What? Business Model System Use Case Model

Design Model

Where?

Rose and ReqPro Rose and ReqPro Rose/XDE

When? First 3 iterations First 4 iterations All iterations

Why? Define business processesIdentify points of automation

Define functional requirements

Start transition to design

Define Components

Integrate With Code

RUP – Basic StepsCreate 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 AcquisitionModelDevelop CodeTest

Software Development PlanCreate Vision and FeaturesIdentify Business/System Use-Cases Prioritize Business/System Use-CasesCreate Iteration Plan and Schedule Create Supporting Process Plans and Guidelines

Create Business Use-Case ModelIdentify Business Use-Cases

Brainstorming major business processesDecompose using activity diagrams

For each Business Use-Case create:Business Activity DiagramsBusiness Use-Case DiagramsBusiness Sequence/Collaboration DiagramsBusiness Statechart DiagramsBusiness Class Diagrams

Create Business Use-Case Requirements

Create System Use-Case Model Identify points of automationFor each System Use-Case create:

System Use-Case DiagramsSystem Activity DiagramsSystem Sequence/Collaboration DiagramsSystem State Transition DiagramSystem Statechart DiagramsAnalysis Class DiagramsUI Design Diagrams/Mockups/Prototype

Create Use-Case Requirements

Create Design Model Import Rose Requirements Model into XDECreate Sequence/Collaboration DiagramsTransform Objects into ClassesCreate Action-level Activity DiagramsCreate Design Class DiagramsCreate Data Model/Database

Create Implementation ModelIntegrate Code with XDE Model

Forward engineer Implementation ClassesReverse engineer existing code and frameworks

Write CodeUnit Test

TestDefine Evaluation Mission

Test Ideas

Verify Test ApproachTest & EvaluateAchieve Acceptable MissionImprove Test Assets

Artifact ReviewDevelopment Case

Software Development Plan • Iteration 1 Plan

– Plan– Schedule

Business Modeling GuidelinesKnowledge Acquisition Worksheet

The ModelsBusiness Use-Case Model

Identify the tasks, activities, roles and entities that accomplish business goalsIdentify Automation Points

• Use-Cases (Automatable/ed Business Use-Cases)– Actors (Business Workers)– Entities (Business Entity)

Use-Case ModelModels User – System InteractionClear, 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 ModelDesign Model

Use-Case Analysis• Objects

Design Classes• Object Evolution• Identify Mechanisms and Elements

Architectural Analysis• Assess Viability of Architectural Proof-of-Concepts

Implementation ModelConstruct Architectural Proof of ConceptsPrototype User-InterfaceImplement Classes

The ModelsDeployment Model

What where

Test ModelTest Cases

• Test Classes• Test Scripts• Test Data• Test Results

Model EvolutionA process of working out or developingA 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 EvolutionModeling

Diagrams• Activity• Sequence• Collaboration• Statechart• Class

– Use-Case– Object– Class

Requirements• Multimedia

Model EvolutionModel Lineage

Business Use-Case (BUCM)

• Use-Case (UCm)– Design (DM)

– Implementation (IM)

– Deployment (DM)

– Test ™

Activity Diagram – BUCMPrimary Diagram for Requirements SpecificationElements

Activities• Actions

TransitionsDecisionsSynchronizationsStates

Activity Diagram – BUCM

Activity Diagrams – BUCM

Activity Diagrams – BUCMSwimlanes

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



Activity Diagrams – BUCMObject Flows

Integration of Business Entities / Entities into the Business Use-Case / Use-case activityRecognition of collaborating objects

Sequence Diagrams - BUCMShow object interaction in a time-based sequenceEstablish the roles of objects Provide essential information to determine class responsibilities and interfaces

Sequence Diagrams - BUCMSimplicity

• Plain English

Shows interaction between

• Business Actors– Workers

• Business Entities

Sequence Diagrams - BUCM

Collaboration Diagrams - BUCMUsed to show how objects interact to perform a particular behaviorUsed to define and clarify the roles of the objects that perform a particular flow of eventsBetter suited to depicting simpler interactions of smaller numbers of objects.

Collaboration Diagrams - BUCM

Collaboration Diagrams - BUCM

Statechart Diagrams - BUCMUsed 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

Statechart Diagrams - BUCM

Class Diagrams – BUCMModels the static structure of the model

Objects / Classes• Internal structure

– Attributes– Operations

Relationships to other classes

Class Diagrams – BUCM

Use–Case Diagram

Class Diagrams – BUCMObject Diagram

Class Diagrams – BUCM

Activity Diagrams - UCMSimple

Plain English

Details interaction activity between

Actors (Business Workers)System (Computer)

Sequence Diagrams - UCMSimple

Plain English

Shows interaction between

Actors (Business Workers)System (Computer)

Other Diagrams - UCMCollaborationStatechartClass

Use-CaseObject

SimplePlain English

Activity Diagram – DM - AnalysisDefining division of actions between objects for obtaining a particular result from the system

Detailed• Actions• Requirements

– Preconditions– Postconditions

Sequence Diagram - DM - AnalysisDefining interaction of objects for obtaining a particular result from the system

Simple messages• Synchronization• Period

Collaboration Diagrams - DM - AnalysisShows collaboration of objects for obtaining a particular result from the system

Simple Messages

Easy to CreateF6Layout

Statechart Diagrams - DM - AnalysisShows achievable states of the objects within the system

Simple

Class Diagrams - DM - AnalysisShow 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 - DesignDefining 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 - DesignShows collaboration of objects for obtaining a particular result from the system

Detailed Messages / Procedure Calls to specific object operations

Statechart Diagrams – DM - DesignShows achievable states of the objects within the system

DetailedInternal Sub-States

Class Diagrams - DM - DesignShow the static state of classes

Structure• Detailed attributes• Detailed

operations

Relationships• Detailed

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

The Other Model ElementsRequisitePro

Requirements• Business Use-Case• Use-Case• Class

– Object– Class

• Shareholder Requests

• Benefits• Features• Supplementary• Business Goal• Business Rule• Interface• Other

– Glossary

The Other Model ElementsViews

• 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 – RequirementsStakeholder 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 – RequirementsStakeholder 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 – RequirementsFeatures

Abilities based on the benefits listed in your problem statementsExamples

• 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 – RequirementsSupplementary 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 – RequirementsGlossary

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 – RequirementsBusiness 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 RuleDefine 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 – RequirementsInterface

Requirements• Graphical

– Accessibility– Branding

• Non-Graphical– Programmable

The Other Model ElementsMultimedia

FilesURLS

Next StepsHomework

Explore RUPClasses Ahead

Using Rational AdministratorUsing ClearCaseUsing ClearQuestUsing Rational Rose XDEIdentifying & Creating Use-Cases – Part 1Identifying & Creating Use-Cases – Part 2Detailing Requirements withRequisiteProActors and Use-Case DiagramsSequence and Statechart DiagramsCollaboration and Class DiagramsIntegration and Development with the .NET Framework