introduction to rup and visual modeling month day, year
TRANSCRIPT
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
Object-Orientation - WhyComplexity 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
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 ( )
Object-Orientation - WhyComplexity to Simplicity
Organization• Responsibilities
– Management– Passive vs. Active
– Job Description– API
– Workspace– Attributes
– Collaboration– Performance Evaluation
Object-Orientation - WhyComplexity 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 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 – BUCM
Activity Diagrams – BUCM
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