18-Design. Analysis and Design Workflow. Worker Responsibilities. So what do we do next? CMPSCI520/620 Design. Rick Adrion 2003 (except where noted) 1

Transcription

1 CMPSCI520/ and Workflow Readings OOAD Using the UML Copyright Rational Software, all rights reserved Architect Architectural Architectural Describe Concurrency Describe Distribution Review the Architecture Architecture Reviewer er Review the Reviewer Class er Worker Responsibilities So what do we do next? Architect Use Case Realization er Architect Architectural Architectural Describe Concurrency Describe Distribution Review the Architecture Architecture Reviewer Model Package/ Class er Review the Reviewer Software Architecture Document Reviewer Class er Data Model Architecture Reviewer er Rick Adrion 2003 (except where noted)

2 CMPSCI520/620 Use Case Overview What is a Realization? Use Case Model <<realizes>> Model Model Supporting Documents Architecture Document Glossary Supplemental Specs Classes Use Case Use Case Realization OR Sequence Diagrams Collaboration Diagrams Realization Model Model Use Case Realization Documentation Class Diagrams Use Case Steps University Course Registration Supplement the Descriptions of the Use Case For each use case realization Find Classes from Behavior Distribute Behavior to Classes For each resulting analysis class Describe Responsibilities Describe Attributes and Associations Qualify Mechanisms Unify Classes Student Login Registrar Maintain Professor Information View Report Card Register for Courses Course Catalog Select Courses to Teach Maintain Student Information Close Registration Billing Professor Submit Grades Rick Adrion 2003 (except where noted) 2

3 CMPSCI520/620 What is an Class? The Roles Early conceptual model Functional requirements Model problem domain Likely to change Boundary Information used Control logic Collaboration Diagram Customer Boundary Class -- Model interaction between the system and its environment Control Class -- Coordinate the use case behavior boundary Use-case behavior coordination information Entity Class -- Store and manage information in the system Example: Entity & Control Classes Classes Course Student (from Registration) MaintainProfessorController (from Registration) CourseOffering Professor Close (from Registration) SubmitGradesController (from Student Evaluation) Grade Schedule MaintainStudentController (from Registration) SelectCoursesToTeachController ReportCardController (from Registration) (from Student Evaluation) Student Register for Courses Course Catalog MainForm Schedule CourseCatalog Use Case Model Model For each use case flow of events: Identify analysis classes Allocate use-case responsibilities to analysis classes Model analysis class interactions in interaction diagrams Client Object :Client Link : PerformResponsibility Message :Supplier Collaboration Diagrams Supplier Object Client Object : PerformResponsibility :Client Object Lifeline Message Focus of Control Sequence Diagrams Supplier Object :Supplier Reflexive Message Rick Adrion 2003 (except where noted) 3

4 CMPSCI520/620 : Student Example: Collaboration Diagram : Main Form : // select maintain schedule( ) 5: // select 4 primary and 2 alternate offerings( ) : Maintain ScheduleForm : CourseCatalog4: // get course offerings( ) 2: // open schedule form( ) 3: // get course offerings( ) 6: // add courses to schedule( ) : Registration Controller 7: // create with offerings( ) Example: Sequence Diagram : MainForm : Maintain : Registration : CourseCatalog : Schedule : Student ScheduleForm Controller : // select maintain schedule( ) 2: // open schedule form( ) 3: // get course offerings( ) 4: // get course offerings( ) 5: // select 4 primary and 2 alternate offerings( ) 6: // add courses to schedule( ) 7: // create with offerings( ) :Schedule Collaboration Vs Sequence Diagrams Collaboration Diagrams Use in Use Case Show relationships in addition to interactions Better for visualizing patterns of collaboration Better for visualizing all of the effects on a given object Easier to use for brainstorming sessions (reordering of messages easier) Sequence Diagrams Use in Use Case Show the explicit sequence of messages Better for visualizing overall flow Better for real-time specifications and for complex scenarios Describe Responsibilities What are responsibilities? How do we find them? Class Name Responsibility Responsibility 2 Responsibility N First cut at class operations Actions that object can perform Knowledge object maintains Non-functional requirements Class should have multiple responsibilities Rick Adrion 2003 (except where noted) 4

5 CMPSCI520/620 Class Responsibilities Attributes, Association, Aggregation // select 4 primary and 2 alternate offerings() // open () <<stereotype>> ClassName Attribute : Type = InitValue Attribute : Type = InitValue Attribute : Type = InitValue Student Simple association Schedule CourseOffering is a pre-requisite of MainForm // select maintain schedule() Schedule // create with offerings() CourseCatalog CourseOffering number :String= 00 starttime : Time endtime: Time days: enum Association Whole/aggregate part Student Schedule Reflexive association Course primarycourses alternatecourses CourseOffering // add courses to schedule() // get course offerings() Attribute Aggregation Finding Relationships Collaboration Diagram Client :Client Link : PerformResponsibility :Supplier Supplier : // select maintain schedule( ) : Student Class Responsibilities from a Collaboration Diagram : Main Form 2: // open schedule form( ) 5: // select 4 primary and 2 alternate offerings( ) : Maintain ScheduleForm 3: // get course offerings( ) 6: // add courses to schedule( ) Register for Courses use case Class Diagram Client Prime suppliers Supplier : Registration : CourseCatalog4: // get course offerings( ) Controller 7: // create with offerings( ) :Schedule // select 4 primary and 2 alternate offerings() // open () MainForm Schedule // select maintain schedule() // create with offerings() Association CourseCatalog // add courses to schedule() // get course offerings() Rick Adrion 2003 (except where noted) 5

6 CMPSCI520/620 Class Responsibilities from a Sequence Diagram What are Roles? : Student : MainForm : Maintain : Registration : CourseCatalog ScheduleForm Controller : Schedule The face that a class plays in the association : // select maintain schedule( ) 2: // open schedule form( ) 3: // get course offerings( ) 4: // get course offerings( ) 5: // select 4 primary and 2 alternate offerings( ) Register for Courses use case Instructor Department head CourseOffering Professor Department 6: // add courses to schedule( ) 7: // create with offerings( ) // select 4 primary and 2 alternate offerings() // open () MainForm Schedule Pre-requisites // select maintain schedule() // create with offerings() CourseCatalog Course // add courses to schedule() // get course offerings() Example: Finding Relationships So Where Are We? does not make any sense outside of the context of a particular use session. Only one can be active at any one time, or none may be active MainForm // select maintain schedule() // open() + // select 4 primary and 2 alternate offerings() Architect Architectural Architectural Describe Concurrency Describe Distribution Review the Architecture Architecture Reviewer : Main Form 2: // open schedule form( ) legacy system. CourseCatalog : // select maintain schedule( ) : Student 5: // select 4 primary and 2 alternate offerings( ) : Maintain ScheduleForm : CourseCatalog4: // get course offerings( ) : Registration Controller :Schedule // get course offerings() one controller for each Schedule 3: // get course offerings( ) being created (e.g., each Student 6: // add courses to schedule( ) registration session). only one CourseCatalog instance for possibly many s serializes access 7: // create with offerings( ) Many s can be active at one time (for different sessions/students). // add courses to schedule() // get course offerings () 0.. Schedule // create with offerings() View of Participating Classes (VOPC) diagram. er er Class Review the Reviewer Rick Adrion 2003 (except where noted) 6

7 CMPSCI520/620 Architectural Overview Classes Glossary Architecture Document Supplementary Guidelines Specifications Classes Model Architectural Guidelines Model Classes and s In analysis, we had one application with many different forms 0.. During design, some analysis classes may be split, joined, removed, etc. 0.. SelectCoursesForm ReportCardForm 0.. MainForm LogonForm SubmitGradesForm 0.. MaintainStudentForm 0.. CloseRegistrationForm 0.. MaintainProfessorForm Classes (cont.) In design, the one application becomes three applications, each with it s own forms... MainRegistrarForm MainStudentForm ReportCardForm 0.. SelectCoursesForm ReportCardForm SelectCoursesForm MainForm SubmitGradesForm 0.. MainProfessorForm MaintainStudentForm LogonForm 0.. CloseRegistrationForm 0.. MaintainProfessorForm SubmitGradesForm 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 MaintainStudentForm MaintainProfessorForm 0.. CloseRegistrationForm Package Name Rick Adrion 2003 (except where noted) 7

8 CMPSCI520/620 Packages Vs. s 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 s provide behavior, packages do not s completely encapsulate their contents Dependencies are on the interface of the subsystem s are easily replaceable A Client Class PackageB Class B Encapsulation is the key! But note for packages dependencies should be on public classes Class B2 IFinance (from Finance) Modeling s ICourseCatalog (from CourseCatalog) package = package with a stereotype of Finance (from Business Services) CourseCatalog (from Business Objects) Note: Rose does not fully support subsystems CourseCatalog ICourseCatalog CourseCatalog proxy class = class with a stereotype of Classes and s Identifying Classes analysis class is simple and already represents a single logical abstraction-> design class entity classes survive relatively intact into design. Identifying s 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. classes which evolve into subsystems might include: complex services and/or utilities user interfaces and external system interfaces. Class Class Class Class goals Properties of a system which make it flexible, maintainable Abstraction Modularity Cohesion how clearly-defined a particular module or procedure is a module with high cohesion does one or a few things exceedingly well. Coupling strength of connections between modules what information needs to be communicated between modules Goal: High cohesion, low coupling Information hiding Complexity Rick Adrion 2003 (except where noted) 8

9 CMPSCI520/620 Partitioning Considerations Coupling and cohesion design elements with tight coupling/cohesion (e.g., lots of relationships and communication) should be should be placed in the same partition design elements with loose coupling/cohesion should be placed in separate partitions. User organization not a good long-term strategy because the organizational structure may change you want the software and the business organization to be independent distribution partitioning to reflect distribution can help to visualize the network communication which will occur as the system executes., but can make the system more difficult to change if the Deployment Model changes significantly. Secrecy & access control functionality requiring special clearance must be partitioned into subsystems that will be developed independently, with the interfaces to the secrecy areas the only visible aspect of these subsystems. Variability partition optional functionality Specific functionality General functionality Typical Layering Approach Layering Guidelines Visibility User Interface Dependencies only within current layer and below Business Services Volatility Upper layers affected by Business Objects requirements changes Lower layers affected by environment changes Middleware Generality More abstract model elements in lower layers Number of layers Base Reuse Small system: 3 layers global global Complex system: 5-7 layers Goal is to reduce coupling and to ease maintenance effort java Business Services Layers & Visibility User Interface Middleware Business Objects Base Reuse global global java Only public classes can be referenced outside of the owning package A B Public visibility PackageA Class A PackageB Class B Class A3 Private visibility Class A2 Class B2 Rick Adrion 2003 (except where noted) 9

10 CMPSCI520/620 Layering Back to layers 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 Professor Interface Registrar Interface The applications need to retain the current user's context GUI Framework Secure Interfaces (from Security) Student Interface A bi-directional relationship exists between the GUI Framework and the other interface packages because the Logon Form needs to be able to notify the application forms MainApplicationForm ( from GUI Framework ) + start( ) 0.. Window (from java.awt) View + open() + refresh() + close() + update() inherits from inherits from inherits from 0.. LogonForm ( from GUI Framework ) + open( ) <<interface>> SecureUser ( from Secure Interfaces ) + getuserid( ) : UniqueId + getaccess( SecureData ) : SecurityAccess + setaccess( SecureData, SecurityAccess) User Interface Layer: Main Forms More Layers inherit from the MainApplicationForm that came from the GUI framework MainApplicationForm (from GUI Framework) LogonForm (from GUI Framework) 0.. MainRegistrarForm MainStudentForm ReportCardForm MainProfessorForm SelectCoursesForm SubmitGradesForm LogonForm was reverse engineered From GUI framework aggregation relationships to be addressed in Class Relational OODBMS DBMS Middleware <<Interface>> IPersistent (from OODBMS) RDBMSTransaction (from RelationalDBMS) OODBMSTransaction (from OODBMS) <<utility>> sql Objectstore (from RelationalDBMS) (from OODBMS) (from OODBMS) Contains Security Security 2 packages Manager SecureUser (from Secure Interfaces) SecureData (from Secure Interfaces) UniqueId SecurityAccess (from Secure Interfaces) (from Secure Interfaces) Secure Interfaces UserSecurityContext (from Security Manager) MaintainStudentForm MaintainProfessorForm CloseRegistrationForm Rick Adrion 2003 (except where noted) 0

11 CMPSCI520/620 So Where Are We? Describe Concurrency Overview Architect Architectural Architectural Describe Concurrency Describe Distribution Review the Architecture Architecture Reviewer er Review the Reviewer Supplementary Specifications Describe Concurrency Process Model er Class the independent threads of control are identified and the identified model elements (subsystems and classes) are mapped to these threads of control. Modeling Processes Processes may be modeled using Active classes (Class Diagrams) and Objects (Interaction Diagrams) owns it s own thread of execution and can initiate control activity may execute in parallel (i.e., concurrently) with other active classes. <<stereotype>> Name Components (Component Diagrams) <<stereotype>> Component Name Relationships <<stereotype>> Name Process.exe <<stereotype>> can be or <<thread>> <<stereotype>> Name dependency Modeling Processes: Class Diagram CourseCatalogAccess CourseRegistrationProcess StudentApplication <<thread>> CourseCache composition <<thread>> OfferingCache CourseCache and OfferingCache are used to asynchronously retrieve items from the legacy system. This will improve response time. Rick Adrion 2003 (except where noted)

12 CMPSCI520/620 Mapping Elements to Processes So Where Are We? The classes associated with the individual user interfaces were mapped to the application processes. The classes associated with the individual business services were mapped to the controller processes. The classes associated with access to the external systems were mapped to the access processes For the threads, composition is used to show what design elements have been mapped to them. CourseCatalogAccess StudentApplication CourseRegistrationProcess CourseOffering <<thread>> OfferingCache MainStudentForm CourseCatalog (from Registration) (from CourseCatalog) <<thread>> CourseCache Proxy due to Rose Course Architect er er Architectural Architectural Describe Describe Concurrency Distribution Class Review the Architecture Architecture Reviewer Review the Reviewer Describe Distribution Overview Why Distribute? Process Model Implementation Model Describe Distribution Deployment Model 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 Rick Adrion 2003 (except where noted) 2

13 CMPSCI520/620 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 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 # <<connection type>> Connection <<Node>> Node #2 Component Component Object Object Interface Process- Process-2... Process- Process-2... Process-to-Node Allocation External Desktop PC StudentApplication <<legacy>> Course Catalog <<Internet>> <<Campus LAN>> Dial up access and behind campus firewall Desktop PC <<Campus LAN>> StudentApplication ProfessorApplication RegistrarApplication Registration Server <<Campus LAN>> CourseCatalogAccess CourseRegistrationProcess GradeSubmissionProcess TeachingCoursesSelectionProcess ProfessorMaintenanceProcess StudentMaintenanceProcess CloseRegistrationProcess ReportCardProcess FinanceAccess <<legacy>> Billing Rick Adrion 2003 (except where noted) 3

14 CMPSCI520/620 Distribution Pattern: Proxy Distribution Pattern: Proxy <<utility>> Naming (from java.rmi) SomeForm : ProxyDistributed Controller : Naming : RemoteTimecard Controller ProxyDistributedController RemoteDistributedController Lookup("RemoteTimecardController") <<controller>> (from Student Activities) +currentuser +currentuser <<Interface>> SecureUser (from Secure Interfaces) 0.. Remote (from Student Activities) : 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 client server secure user instance is created on the client and passed to the server when the remote controller is created 6: DoSomething All calls to the proxy controller are forwarded to the remote controller The Rational 4+ Views Affect on Process Model Associations StudentApplication Process design view implementation view Classes, interfaces, collaborations Components MainStudentForm Organization Package, subsystem Use cases Use -Case View Dynamics Interaction State machine 0.. Active classes process view deployment view Nodes (from Student Activities) Remote 0.. (from Student Activities) Rick Adrion 2003 (except where noted) 4