Rational Unified Process

Transcription

1 6- Readings OOAD Using the UML Copyright Rational Software, all rights reserved [Partly] posted Rational Unified Process The Unified Modeling Language (UML) is a language for specifying, visualizing, constructing, and documenting the artifacts of a software-intensive system A software development process defines Who is doing What, When and How in building a software product The Rational Unified Process has four phases: Inception, Elaboration, Construction and Transition Each phase ends at a major milestone and contains one or more iterations An iteration is a distinct sequence of activities with an established plan and evaluation criteria, resulting in an executable release The RUP presentation is adapted from OOAD Using the UML Copyright Rational Software, all rights reserved Rick Adrion 2005 (except where noted)

2 In RUP: Major Workflows Produce Models Business Modeling Business Model supported by Requirements realized by Analysis & Use-Case Model Model implemented by Implementation verified by Test Implementation Model Test Model The RUP Iterative Model Process Workflows Business Modeling Analysis & Implementation Test Supporting Workflows Workflows group activities logically Requirements Deployment Configuration Mgmt Management Environment Inception Elaboration Preliminary Iteration(s) Iter. # Iter. #2 Phases Construction Iter. #n Iter. #n+ Iterations Iter. #n+2 In Transition iteration, you walk through all workflows Iter. #m Iter. #m+ Rick Adrion 2005 (except where noted) 2

3 Requirements Workflow Develop Vision Elicit Stakeholder Needs Find Actors and Use Cases Manage Capture a Dependencies Common Vocabulary Structure the Use-Case Model Requirements Reviewer Use-Case Specifier Detail a Use Case Review Requirements User-Interface er User-Interface Modeling User-Interface Prototyping Architect Prioritize Use Cases Analysis & Workflow Architectural Analysis Architect Architectural Describe Concurrency Describe Distribution Review the Architecture Architecture Reviewer er Use-Case Analysis Subsystem Use-Case Review the Reviewer Class Database er Database Rick Adrion 2005 (except where noted) 3

4 Implementation Workflow Architect Structure the Implementation Model System Integrator Plan System Integration Integrate System Implementer Plan Subsystem Integration Implement Classes Perform Unit Test Integrate Subsystem Fix a Defect Code Reviewer Review Code Test Workflow Test er PlanTest Test ImplementTest Evaluate Test Integration Tester Execute Integration Test System Tester Execute System Test Performance Tester Execute Performance Test er Test Classes and Packages Implementer Implement Test Components and Subsystems Rick Adrion 2005 (except where noted) 4

5 O-O System Development problem statement Project0 Requirements elicitation interviews nonf unctional requirements f unctional model use case diagram Project class diagram Requirements analy sis analy sis object model dy namic model statechart diagram sequence diagram System design design goals system design object model subsy stem decomposition Object design class diagram object design model Project2 Implementation Project3 source code Test deliv erable sy stem adapted from Bruegge/Dutoit O-O SW Engr A Minimal Iterative Process Getting Started: (do this once). Capture the major functional and non-functional requirements for the system. Express the functional requirements as use cases, scenarios, or stories. Capture non-functional requirements in a standard paragraph-style document. 2. Identify the classes which are part of the domain being modeled. 3. Define the responsibilities and relationships for each class in the domain. 4. Construct the domain class diagram. This diagram and the responsibility definitions lay a foundation for a common vocabulary in the project. 5. Capture use case and class definitions in an OO CASE tool (e.g., Rose) only when they have stablilized. Copyright Gary K. Evans. All Rights Reserved. Rick Adrion 2005 (except where noted) 5

6 A Minimal Iterative Process Getting Started: (do this once) 6. Identify the major risk factors and prioritize the most architecturally significant use cases and scenarios. It is absolutely imperative that the highest risk items and the most architecturally significant functionality be addressed in the early iterations. You must not pick the low hanging fruit and leave the risks for later. 7. Partition the use cases/scenarios across the planned iterations. 8. Develop an Iteration plan describing each mini-project to be completed in each iteration. Describe the goals of each iteration, plus the staffing, the schedule, the risks, inputs and deliverables. Keep the iterations focused and limited (2-3 weeks per iteration). In each iteration, conduct all of the software activities in the process: requirements, analysis, design, implementation and test. Copyright Gary K. Evans. All Rights Reserved. A Minimal Iterative Process For each iteration: (repeat until done). Merge the functional flow in the use cases/scenarios with the classes in the domain class diagram Produce sequence (and collaboration) diagrams at the analysis level. 2. Test and challenge the sequence diagrams on paper, or whiteboard Discover additional operations and data to be assigned to classes Validate the business process captured in the flow of the sequence diagram 3. Develop statechart diagrams for classes with significant state Statechart events, actions, and most activities will become operations on the corresponding class 4. Enhance sequence diagrams and statechart diagrams with design level content Identify and add to the class diagram and sequence diagrams any required support or design classes (e.g. collection classes, GUI and other technology classes, etc.) 5. Challenge the sequence diagrams on paper/whiteboard, discovering additional operations and data assigned to classes. Copyright Gary K. Evans. All Rights Reserved. Rick Adrion 2005 (except where noted) 6

7 Views & Workflows Architect Architectural Analysis Architectural Describe Describe Concurrency Distribution Review the Architecture Architecture Reviewer er Use-Case Analysis Subsystem Use-Case Review the Reviewer Database er Class Database Classes, interfaces, collaborations design v iew implementation v iew Components Organization Package, subsystem Use cases Use -Case View Dynamics Interaction State machine process v iew deployment v iew Active classes Nodes Worker Responsibilities Architect Use Case Realization er Model Package/ Subsystem Class Software Architecture Document Database er Data Model Architecture Reviewer Reviewer Rick Adrion 2005 (except where noted) 7

8 So where do we start? Architect Architectural Analysis Architectural Describe Describe Concurrency Distribution Review the Architecture Architecture Reviewer er Use-Case Analysis Subsystem Use-Case Review the Reviewer Class Database er Database Use Case Analysis Overview Use-Case Model Supporting Documents Architecture Document Glossary Supplemental Specs Analysis Classes OR Use-Case Realization Analysis Model Model Rick Adrion 2005 (except where noted) 8

9 Use Case Analysis Steps Supplement the Descriptions of the Use Case For each use case realization Find Classes from Use-Case Behavior Distribute Use-Case Behavior to Classes For each resulting analysis class Describe Responsibilities Describe Attributes and Associations Qualify Analysis Mechanisms Unify Analysis Classes What is an Analysis Class? Early conceptual model Functional requirements Model problem domain Likely to change Boundary Information used Control logic <<control>> System boundary Use-case behavior coordination <<control>> System information <<entity>> <<entity>> Rick Adrion 2005 (except where noted) 9

10 The Roles Collaboration Diagram Boundary Class -- Model interaction between the system and its environment Control Class -- Coordinate the use case behavior Customer Entity Class -- Store and manage information in the system Example: Entity & Control Classes Course (from University Artifacts) CourseOffering (from University Artifacts) Grade (from University Artifacts) Student (from University Artifacts) Professor (from University Artifacts) Schedule (from University Artifacts) RegistrationController (from Registration) CloseRegistrationController (from Registration) MaintainStudentController (from Registration) MaintainProfessorController SelectCoursesToTeachController ReportCardController (from Registration) (from Registration) (from Student Evaluation) SubmitGradesController (from Student Evaluation) Rick Adrion 2005 (except where noted) 0

11 Describe Responsibilities What are responsibilities? How do we find them? First cut at class operations Actions that object can perform Knowledge object maintains Non-functional requirements Class should have multiple responsibilities Responsibility Class Name Responsibility 2 Responsibility N Class Responsibilities from a Collaboration Diagram : Main Form 2: // open schedule f orm( ) : // select maintain schedule( ) 5: // select 4 primary and 2 alternate of f erings( ) : Maintain ScheduleForm Register for Courses use case : Student 3: // get course of f erings( ) 6: // add courses to schedule( ) MaintainScheduleForm : CourseCatalog4: // get course Sy stem of f erings( ) : Registration Controller 7: // create with of f erings( ) // select 4 primary and 2 alternate offerings() // open () :Schedule MainForm // select maintain schedule() <<entity>> Schedule // create with offerings() <<control>> RegistrationController CourseCatalogSystem // add courses to schedule() // get course offerings() Rick Adrion 2005 (except where noted)

12 Class Responsibilities from a Sequence Diagram : Student : MainForm : Maintain : Registration : CourseCatalog ScheduleForm Controller Sy stem : Schedule Register for Courses use case : // select maintain schedule( ) 2: // open schedule f orm( ) 3: // get course of f erings( ) 5: // select 4 primary and 2 alternate of f erings( ) 4: // get course of f erings( ) MaintainScheduleForm 6: // add courses to schedule( ) 7: // create with of f erings( ) // select 4 primary and 2 alternate offerings() // open () MainForm <<entity>> Schedule // select maintain schedule() // create with offerings() <<control>> RegistrationController CourseCatalogSystem // add courses to schedule() // get course offerings() What are Roles? The face that a class plays in the association Instructor Department head CourseOffering Professor Department Pre-requisites Course Rick Adrion 2005 (except where noted) 2

13 Example: Finding Relationships MaintainScheduleForm does not make any sense outside of the context of a particular use session. Only one MaintainScheduleForm can be active at any one time, or none may be active : Main Form : // select maintain schedule( ) 5: // select 4 primary and 2 alternate of f erings( ) : Maintain ScheduleForm MainForm MaintainScheduleForm 0.. // select maintain schedule() + // open() + // select 4 primary and 2 alternate offerings() 2: // open schedule f orm( ) legacy system. CourseCatalogSystem // get course offerings() 0..* <<control>> RegistrationController // add courses to schedule() // get course offerings () 0.. : Student : CourseCatalog4: // get course Sy stem of f erings( ) one controller for each 3: // get course of f erings( ) Schedule being created (e.g., 6: // add courses to schedule( ) each Student registration session). : Registration Controller only one CourseCatalogSystem instance for possibly many MaintainScheduleForms 7: // create with of f erings( ) serializes access :Schedule Many MaintainScheduleForms can be active at one time (for different sessions/students). <<entity>> Schedule // create with offerings() View of Participating Classes (VOPC) diagram. What is a Use-Case Realization? Use Case Model Use Case <<realizes>> Model Use Case Realization Sequence Diagrams Collaboration Diagrams Use Case Realization Documentation Class Diagrams Rick Adrion 2005 (except where noted) 3

14 Alternatives RUP begins with Analysis classes we found by analyzing Collaboration & Sequence Diagrams (these derived from the Use Cases during Use Case Analysis), then is refined by defining Operations, States, Attributes, Associations and Generalizations (in Class ) Some other approaches: Noun Phrase Approach Common Class Patterns CRC (Class-Responsibility-Collaboration) Noun Phrase Approach Examine the requirements and underline each noun Each noun is a candidate class Divide list of candidate classes into Relevant Classes Part of the application domain; occur frequently in reqs Irrelevant Classes Outside of application domain Fuzzy Classes Unable to be declared relevant with confidence; require additional analysis Experience will eventually enable designers to avoid generating irrelevant classes Rick Adrion 2005 (except where noted) 4

15 Find Classes from requirements Consider the following University Enrollment system specification each university major has a number of required courses and a number of elective courses. Course RequiredCourse Major ElectiveCourse Fuzzy Classes, Relationships & Attributes A course can be part of any number of majors Each major specifies minimum total credits required Students may combine course offerings into programs of study suited to their individual needs and leading to the degree/major in which enrolled Relevant classes Course Major Student CourseOffering Fuzzy classes CompulsoryCourse ElectiveCourse Sudyprogram Rick Adrion 2005 (except where noted) 5

16 Noun Phrase Approach may help in identifying domain objects not good at identifying objects that live in the application domain Thus, it can help at the beginning of analysis, but you will not return to it as you move into design Finding good objects during design means identifying abstractions that are part of your application domain and its execution machinery Objects that are part of your application domain will have a tenuous connection, at best, to real-world things e.g. what s the correspondence of a scrollbar to the real world Common Class Patterns Derive classes from the generic classification theory of objects Concept class a notion shared by a large community Events class captures an event that demarks intervals within a system Organization class a collection or group within the domain People class roles people can play Places class a physical location relevant to the system Rick Adrion 2005 (except where noted) 6

17 Common Class Patterns Rumbaugh proposed a different scheme Physical Class (Airplane) Business Class (Reservation) Logical Class (FlightTimeTable) Application Class (ReservationTransaction) Computer Class (Index) Behavioral Class (ReservationCancellation) These taxonomies are meant to help a designer think of classes, however it is difficult to be systematic Probably only useful during early analysis CRC Cards CRC = Candidates, Responsibilities, Collaborators Meant primarily as a brainstorming tool for analysis and design In place of use case diagrams use index cards In place of attributes and methods record responsibilities See Object by Wirfs-Brock and McKean, 2003 Rick Adrion 2005 (except where noted) 7

18 Index Cards On the unlined side of the index card write an informal description of each candidate class purpose and role On the lined side of the index card identify responsibilities and collaborators Document Purpose: A Document acts as a container for graphics and text Role: Container Pattern: Composite Document Knows contents Knows storage location Inserts and removes text,graphics, other elements responsibilities candidate TextFlow collaborators MVC using CRC cards View class collaborators Render the Model Transform coordinates Model Controller Model responsibilities Controller Interpret user input Distribute control View Model Maintain problem related information Broadcast change notification Rick Adrion 2005 (except where noted) 8

19 Not Just Index Cards Post-It Notes can be used for even less structure ; might be easier when brainstorming Document Purpose: A document Represents a container that holds text and/or graphics that the user can enter and visually arrange on pages Why index cards? Forces you to be concise and clear and focus on major responsibilities since you must fit everything onto one index card Inherent Advantages cheap, portable, readily available, and familiar gives people a "feel" for the design can propose and test changes to the design rapidly (all you have to do is make new cards) focus on responsibilities as opposed to n:m attribute" design as promoted by OMT, Booch, etc affords Spatial Semantics close collaborators can be overlapped vertical dimension can be assigned meanings abstract classes and specializations can form piles which provides benefits Beck and Cunningham report that they have seen designers talk about a new card by pointing at where it will be placed Rick Adrion 2005 (except where noted) 9

20 So Where Are We? Architect Architectural Analysis Architectural Describe Describe Concurrency Distribution Review the Architecture Architecture Reviewer er Use-Case Analysis Subsystem Use-Case Review the Reviewer Class Database er Database Architectural Overview Glossary Architecture Document Supplementary Guidelines Specifications Guidelines and Implementation Mechanisms Classes and Subsystems Reuse Opportunities Refined Architectural Layers and Partitions Architectural Analysis Classes Model Model Architect Architectural Describe Describe Concurrency Distribution Rick Adrion 2005 (except where noted) 20

21 Classes In analysis, we had one application with many different forms MainForm 0.. LogonForm MaintainScheduleForm (from Student Interface) CloseRegistrationForm (from Registrar Interface) During design, some analysis classes may be split, joined, removed, etc. 0.. SelectCoursesForm (from Professor Interface) 0.. ReportCardForm (from Student Interface) 0.. SubmitGradesForm (from Professor Interface) 0.. MaintainStudentForm (from Registrar Interface) 0.. MaintainProfessorForm (from Registrar Interface) Classes (cont.) In design, the one application becomes three applications, each with it s own forms... MaintainScheduleForm (from Student Interface) MainStudentForm (from Student Interface) <<boundary >> MaintainSc heduleform (from Student Interfac e) 0.. ReportCardForm (from Student Interface) <<boundary >> MainForm 0.. <<boundary >> <<boundary >> SubmitGrades Form Selec tcours es Form (from Professor Interface) (from Professor Interface) 0.. <<boundary >> ReportCardForm (from Student Interfac e) MainProfessorForm (from Professor Interface) <<boundary >> LogonForm <<boundary >> MaintainStudentForm (from Registrar Interface) <<boundary >> Clos eregis trationform (from Registrar Interface) 0.. <<boundary >> MaintainProfes s orform (from Registrar Interface) MainRegistrarForm (from Registrar Interface) SelectCoursesForm (from Professor Interface) SubmitGradesForm (from Professor Interface) 0..* 0..* MaintainStudentForm (from Registrar Interface) MaintainProfessorForm (from Registrar Interface) 0.. CloseRegistrationForm (from Registrar Interface) Rick Adrion 2005 (except where noted) 2

22 Classes & packages What is a class? A description of a set of objects that share the same responsibilities, relationships, operations, attributes, and semantics. Class Name What is a package? A general purpose mechanism for organizing elements into groups A model element which can contain other model elements Package Name Packages Vs. Subsystems Packages provide no behavior Packages are simply containers of things which provide behavior Packages help organize and control sets of classes that are needed in common, but which aren t really subsystems Dependencies are on specific elements within the Package Subsystems provide behavior, packages do not Subsystems completely encapsulate A their contents Dependencies are on the interface of the subsystem Subsystems are easily replaceable <<subsystem>> Client Class PackageB Class B Encapsulation is the key! But note for packages dependencies should be on public classes Class B2 Rick Adrion 2005 (except where noted) 22

23 Classes and Subsystems Identifying Classes analysis class is simple and already represents a single logical abstraction-> design class entity classes survive relatively intact into design. Identifying Subsystems analysis class is complex, such that it appears to embody behaviors that cannot be the responsibility of a single class acting alone, or the responsibilities may need to be reused, the analysis class should be mapped to a subsystem may take a few iterations to stabilize. Analysis classes which evolve into subsystems might include: complex services and/or utilities user interfaces and external system interfaces. Class Class <<subsystem>> Subsystem <<subsystem>> Subsystem Class Class <<subsystem>> Subsystem Layering Concentrate on encapsulating change Package dependencies are not transitive, thus one layer can shield another from change Upward dependencies should be resolved in design e.g., call backs can be replaced with the subscribes to association whose source is a class (called the subscriber) and whose target is a class (called the publisher) subscriber specifies a set of events and is notified when one of those events occurs in the target Rick Adrion 2005 (except where noted) 23

24 Layering Guidelines Visibility Dependencies only within current layer and below Volatility Upper layers affected by requirements changes Lower layers affected by environment changes Generality More abstract model elements in lower layers <<layer>> Business Services <<layer>> User Interface <<layer>> Middleware <<layer>> Business Objects Number of layers <<layer>> Base Reuse Small system: 3 layers System global global Complex system: 5-7 layers Goal is to reduce coupling and to ease maintenance effort java Layers & Visibility <<layer>> Business Services <<layer>> User Interface Only public classes can be referenced outside of the owning package PackageA Class A <<layer>> Business Objects A Class A3 Class A2 <<layer>> Middlew are B PackageB Class B Class B2 Public visibility <<layer>> System Base Reuse global global java Private visibility Rick Adrion 2005 (except where noted) 24

25 Describe Concurrency Architect Architectural Describe Describe Concurrency Distribution Supplementary Specifications Describe Concurrency Process Model Concurrency Requirements driven by: degree to which the system must be distributed degree to which the system is event-driven computational intensity of key algorithms degree of parallel execution supported by the environment Modeling Processes map on independent threads of control supported by environment Processes - stand-alone, heavyweight flow of control that may be divided into individual threads Threads- lightweight flow of control which run in the context of an enclosing process Mapping Processes onto the Implementation Environment Distributing Model Elements Among Processes Example <<process>> StudentApplication MainStudentForm (from Student Interface) <<process>> CourseRegistrationProcess <<control>> RegistrationController (from Registration) <<process>> CourseCatalogSystemAccess <<subsystem>> CourseCatalog (from CourseCatalog) <<entity>> 0..* CourseOffering (from University Artifacts) <<thread>> OfferingCache <<thread>> CourseCache 0..* <<entity>> Course (from University Artifacts) Mapping Elements to Processes Rick Adrion 2005 (except where noted) 25

26 Example dependency Class Diagram <<process>> CourseCatalogSystemAccess <<process>> CourseRegistrationProcess <<process>> StudentApplication <<thread>> CourseCache composition <<thread>> OfferingCache <<process>> CourseCatalogSystemAccess <<process>> CourseRegistrationProcess dependency Component Diagram <<thread>> OfferingCache <<thread>> CourseCache Mapping to Implementation <<process>> StudentApplication CourseCatalogSystemAccess CourseCache Remote (from java.rmi) CourseRegistrationProcess Runnable (from java.lang) OfferingCache Thread (from java.lang) Describe Distribution Overview Process Model Describe Distribution Deployment Model Implementation Model Architect Architectural Describe Describe Concurrency Distribution Rick Adrion 2005 (except where noted) 26

27 Why Distribute? Reduce processor load Special processing requirements Scaling concerns Economic concerns Distribution Patterns Client/Server 3-tier Fat-Client Web Application Distributed Client/Server Peer-to-peer Distribution patterns Common services Presentation Services UI including, the visual appearance of output and how user input is handled Business Services Business rules and logic Data Services Data relationships, efficiency of storage, and data integrity Patterns One-Tier Two-Tier Fat Client -- client has its presentation and business services; server has the data services Thin Client -- client has the presentation services; server has the business and data services Three-tier client has presentation services; server has business services; separate (logical) server has data services. Web-tier client accesses a web server that at least handles presentation services; web server may have its own business and data services or it may utilize one or more servers that handle business and data services Rick Adrion 2005 (except where noted) 27

28 Deployment Model Modeling Elements Node Physical run-time computational resource Processor Execute system software Device Support devices Typically controlled by a Processor Connection Communication mechanisms Physical medium Software protocol <<Node>> Node # <<Processor>> Processor # Connection <<Device>> Device # Deployment Diagrams <<Node>> Node # Component Object <<connection type>> Connection Process- Process-2... <<Node>> Node #2 Component Object Interface Process- Process-2... Rick Adrion 2005 (except where noted) 28

29 Process-to-Node Allocation Dial up access and behind campus firewall External Desktop PC StudentApplication <<Internet>> Desktop PC <<Campus LAN>> StudentApplication ProfessorApplication RegistrarApplication Registration Server <<Campus LAN>> <<legacy>> Course Catalog <<Campus LAN>> CourseCatalogSystemAccess CourseRegistrationProcess GradeSubmissionProcess TeachingCoursesSelectionProcess ProfessorMaintenanceProcess StudentMaintenanceProcess CloseRegistrationProcess ReportCardProcess FinanceSystemAccess <<legacy>> Billing System Distribution Pattern: Proxy <<utility>> Naming (from java.rmi) ProxyDistributedController RemoteDistributedController 0..* <<controller>> RegistrationController (from Student Activities) +currentuser +currentuser <<Interface>> SecureUser (from Secure Interfaces) 0..* 0.. RemoteRegistrationController (from Student Activities) client server secure user instance is created on the client and passed to the server when the remote controller is created Rick Adrion 2005 (except where noted) 29

30 Distribution Pattern: Proxy SomeForm : ProxyDistributed Controller : Naming : RemoteTimecard Controller Lookup("RemoteTimecardController") : new(secureuser) The connection between the proxy and remote controller is established when the proxy controller is created 5: DoSomething 2: lookup(string) 3: new( ) 4: setsession(secureuser) The current user context is passed to the server for later access checks 6: DoSomething All calls to the proxy controller are forwarded to the remote controller Affect on Process Model Associations <<process>> StudentApplication MainStudentForm (from Student Interface) <<process>> StudentApplication <<process>> RegistrationControllerProcess <<process>> CourseRegistrationProcess <<control>> RegistrationController (from Registration) <<process>> CourseCatalogSystemAccess <<subsystem>> CourseCatalog (from CourseCatalog) MainStudentForm (from Student Interface) <<entity>> 0..* CourseOffering (from University Artifacts) <<thread>> OfferingCache <<thread>> CourseCache 0..* <<entity>> Course (from University Artifacts) 0.. MaintainScheduleForm (from Student Interface) <<control>> RegistrationController (from Student Activities) <<control>> RemoteRegistrationController (from Student Activities) 0.. Rick Adrion 2005 (except where noted) 30