Software Engineering G Session 7 Sub-Topic 7 Presentation EAMF Application/Information Perspectives. Dr. Jean-Claude Franchitti

Transcription

1 Software Engineering G Session 7 Sub-Topic 7 Presentation EAMF Application/Information Perspectives Dr. Jean-Claude Franchitti New York University Computer Science Department Courant Institute of Mathematical Sciences Objectives Describe EAMF Application and Information Perspectives and Related Activities 2

2 more specific Levels of Abstraction more abstract Roadmap EAMF Perspectives Information Perspective Application Perspective Conceptual Technology Architecture (CTA) Architectural Style Reference Architecture/Element ABASs Architectural Mechanisms Patterns Framework Architectural Pattern Design Pattern Idiom 3 Information Perspective Table used to summarize the artifacts captured and stored in the information perspective Viewpoints for information perspective 4

3 Application Perspective Table used to summarize the artifacts captured and stored in the application perspective 5 Application Perspective: Conceptual Technology Architecture (CTA) The CTA is the counterpart of problem specific part of CBA diagram in the application perspective CTA diagram visualizes the high level computer processes, data stores, network assets without specific classifications The actors interaction with the technology would be depicted and explained CTA will not show specific software or hardware equipment or logical layering of any software components if this information is not known upfront 6

4 Application Perspective: Viewpoints Technology viewpoints are described differently by different resources EAMF combines the viewpoints of the industry think-tanks and defines a combined set as the following Microsoft s Enterprise Solution Patterns Viewpoints Database Application Deployment Infrastructure Gartner s Expanded Architecture Framework s Viewpoints Data Application Integration Point of Access n/a n/a PDA EAF Viewpoints Data Application Integration Point of Access Moved to Deployment Mapping Moved to Infrastructure Mapping 7 Application Perspective: Viewpoints (cont.) Data Data viewpoint shows patterns, pattern clusters and artifacts that relate to access and storage of persistent data Application Application viewpoint shows patterns, pattern clusters and artifacts that relate how application logic processes data internally Integration Integration viewpoint shows patterns, pattern clusters and artifacts that relate how a solution accesses external systems Point Of Access Point of Access viewpoint shows patterns, pattern clusters and artifacts that relate how external systems and users access the solution 8

5 Use of UML Artifacts to Construct EAMF Views Diagram Name Use Case Class Activity State Machine Object Package Composite Structure Deployment Interaction Overview Sequence Communication Type Dynamic Static Dynamic Dynamic Static Static Static Static Dynamic Dynamic Dynamic EAMF Disciplines Analysis Analysis Analysis Analysis Analysis Analysis Analysis Analysis Design Design Design Timing Component Dynamic Static Design Design 9 Roadmap Using the EAMF Application Perspective Sample CTA Diagram Identifying/Confirming RA Application Model Catalog Relationships Working with Application Model Catalogs Sample Logical Architecture Analysis Diagram Identification of Applicable Patterns Sample Guidelines Sample Design Considerations Sample Design Model Identification of Reference Implementation Product Mapping 0

6 Sample CTA Diagram Identifying/Confirming RA ad Identification and Confirmation of Reference Architecture Business Perspective Iteration Completed Compare CR-Matrix functional capabilities with the capability matrix of the implied ref. arch. Yes Does Busi ness Analysis imply a Ref. Arch.? No Does implied ref. arch. capabilities match with the CR- Matrix functional capabilities? No Compare CR-Matrix functional capabilities to each available ref. arch. capability matrix Yes Select the most appropriate ref. arch. based on comparison results Set implied ref. arch. as appropriate ref. arch. Ref. Arch. identified and confirmed 2

7 Application Model Catalog Relationships cd Catalog Relationships Application Model Catalog Reference Architecture Capability Matrix..* Reference Architecture Model Matrix Reference Architecture Reference Architecture Document 3 Working with Application Model Catalogs The application model catalog contains a list of the reference architectures For each reference architecture in the application model catalog there is a: Document which explains the reference architecture in detail. The document may contain many links to more detailed explanations, graphics and tables Model matrix which identifies the related patterns for that reference architecture Capability matrix which lists the functional capabilities of the given reference architecture A capability matrix for a reference architecture (Application Server) looks like the following: 4

8 Sample Logical Architecture Analysis Diagram AIM <<Employee>> Provide New Group Number Calculate New Number Eliminate nonunique numbers Eliminate offensive words Services Naming and Directory Transactions Concurrency Security Group Master DB2 Application Logic Layer Application Infrastructure Layer 5 Identification of Applicable Patterns NF policies identified in the CR-Matrices are used to determine appropriate styles and patterns for the solution Not all non-functional capabilities lead to software design patterns Some non-functional capabilities such as reliability, availability, recoverability and dependability (and possibly others) require hardware deployment patterns along with organizational behavior changes towards quality There is no (bullet-proof) defined process that would help an architect to identify appropriate patterns A pattern can be applicable to a certain problem but it may not be appropriate The identification of the applicable and appropriate pattern requires immense working pattern knowledge which is not only knowing and understanding what patterns are but also recognizing when and when not to use certain patterns NFR Framework Based Approach is suggested 6

9 Sample Guidelines EBP.Producer.LowVolumeLowFrequency - C2B.RequestResponse Motivation Policy Type Measurable (only verifiable after implementation) Concrete (based on proven design) Business Driven - Required - (resulting from analysis) Efficieny.Time : 8 sec/per request/per user Scalability : 20 concurrent users to 40 concurrent users without software modifications Availability : 6:00 am - 6:00 pm Business days Security : Only authenticated and authorized AFLAC employees Concurrency Persistent State Security Transaction Technology Driven - Desired - (resulting from design considerations) Extensibility : Same generation process with different algorithms will be supported. Efficieny.Time : 0.5 sec/per request/per user Testability : Provide test harness, debugging and adjustable levels of logging capabilities. Naming and Directory Readability : Follow company standards For improvements in Scalability Keep data modification blocks short and synchronized. Improve Effiecieny.Time Table Data Gateway Pattern. 7 Sample Design Considerations Start Sample Steps: Generation of a new group number Steps are: Read the last used group number from the persistence store Calculate the next group number based on an algorithm Validate the calculated group number Check that it does not include offensive words Check that it has never been used before If the newly calculated group number is not valid go to step 2. Otherwise, update the last used group number persistence store with the newly calculated group number Return the newly calculated group number to the client Last Group Number = read Last Group Number from Data Store New Group Number = Calculate following the algorithm based on Last Group Number Last Group Number = New Group Number New Group Yes Number Offensive? No No New Group Number Unique? Yes Update Data Store with New Group Number Return New Group Number End 8

10 Sample Design Considerations: Improvement on Efficiency.Time Yes New Group Number Offensive? No I/O operation Offensive Words List = read Offensive Words List from data store Offensive Word = next word in the list CPU operation Contains = new Group number contains offensive word Repeated as many times as the number of words in the list. The longer the list the more time consuming is the process Yes Contains? Yes No More words in the list? No 9 Sample Design Considerations: Suggested Synchronous Layer 20

11 Sample Design Considerations: Suggested Asynchronous Layer Asynchronous Layer Application Server Group Number Replenisher Valid New Group Numbers List generate validate Group Number Generator Group Number Validator send Offensive Words List (Singleton) isoffensive Insert List (grouped I/O) select isunique (Lazy Load) MoM Last Used Group Number Table Offensive Words Table Group Master Table Group Numbers Cache Table GroupNumbersCache LastUsedGroupNumber OffensiveWords GroupMaster DB2 Application Logic Layer Application Integration Layer 2 Sample Design Considerations: Standard Application Model Matrix 22

12 Sample Design Model ud AIM System Partial Use Cases AIM System Boundary Setup New Account AIM Team Member New Account Setup Team Member «include» Get New Group Number 23 Sample Design Model (cont.) ad Get Group Number Activity Get Group Number Request Received ad get completeto count Get Group Number from the Cache load cache update properties (Lazy Load in Singleton) read unreserv ed group number from cache table unreserved threshold get count of unreserv ed group numbers unreserved full count groupnumber unreserved count groupnumber update read group number record as reserved with a timestamp unreserved threshold threshold - count difference unreserved count put read flag message into MoM difference > 0 Yes completeto = 0 groupnumber No completeto = full count - threshold + difference Update Group Numbers Cache Group Number returned get completeto count ad insert completeto new numbers into cache completeto read Last Used Group Number load OffensiveWordsList (Lazy Load in Singleton) No completeto <= 0 Yes stop update cache flow last Group Number completeto last Group Number get completeto New Group Numbers insert completeto new numbers into cache eliminate used reserved numbers from cache New Group Numbers List Last Group Number in the List update Last Used Group Number w ith Last Group Number in the List cache updated insert New Group Number into Cache New Group Numbers List 24

13 Identification of Ref. Implementation cd Catalog Relationships Application Implementation Catalog..* Reference Implementation Implementation Matrix cd Catalog Relationships Reference Architecture Capability Matrix Application Model Catalog..*..* Application Implementation Catalog..* Reference Implementation Implementation Matrix Reference Implementation Reference Implementation Capability Matrix Reference Architecture Model Matrix Reference Architecture Document Reference Architecture Reference Reference Implementation Implementation Capability Matrix Reference Implementation Document Reference Implementation Document 25 Product Mapping ad Application Perspective Matrix Population Process Business Perspective Iteration Completed Identify New Reference Architecture Populate Model Matrix Create Architectural Restrictions and Connstraints Doc Yes Any Architectural constraints or restrictions No Identify Reference Implementation Populate Implementation Matrix Create Implementation Restrictions and Constraints Document Yes Any Implementation Restriction or Constraints Create Product Restriction and Constraints Document Identify Appropriate Product Yes Any Product Restrictions or Constraints Yes Does Product Exist? No Ready to move to deployment view No Acquire Product - Insert to Product Catalog 26

14 Roadmap EAMF-Compliant A&D Notations Architecture Analysis and Design Block Diagrams (Iconic Notations) BPMN Notations UML 2.0 Reference Architectures Specific Notations CWML Service Oriented A&D Notations 27 Refined Application Architecture Blueprint (e.g., virtual classroom environment) Users Connectivity e-business Portal e-business Services Back-Office Systems Client Client Administrator Web Sales TradiDesk Marketing VPN User Interfaces XML/Web Enabling Facilities Component Manager Legacy Systems Facilitator Phone Visitor Support Facilitator Administrator PDA User Data XML-Based Application Data Legacy Databases Data Repositories 28

15 IVR NT & Unix Win 2000 Faxback NT & Unix Win 2000 IVR Win 2000 (Custom Java Applications) (2D Avatars, Classroom Navigation, Chat, Events) (ACD, Flex-Routing, Call Center Mgmt.) (Product Support, Issue Resolution, Proactive Account Mgmt.) Questions capture and Q&A viewring) (XML interfaces, , Browser) (Browsers, PDAs, WAPs) (tutorials, online help) Teleweb / Web Integration Services (Consolidated Messaging, Telephone-Based Web Services, Video Conf., etc.) Mapping Application to App. Infrastructure Application Model Business model Data Model Content Model Organization Location Process Logical Data Principles Assumptions Constraints Web Interface Presentation Navigation Look and Feel Business Constraints Logical Application Model Global Front End System Client Handler Core Components Services Events Persistence Messaging Externalization Domain Specific Client API EFI Execution Interface Execution & Market Systems EFI Execution Systems Client Interface Components Client to Core components Handler Licensing Reporting Naming Security Common Facilities XML POP Monitoring Transaction Channels FX Execution Interface Market Instrument Reference data FX Execution Systems Market Systems Error Handling Backup / Recovery Performance Tuning System Admin Markets Help XML MOM Query / Search Portal interfaces Preferences and Operating Constraints Technology Infrastructure Model Global Front End System Client Workstation Client Services Administrator XML, SWIFT, FIX, , Fax System Admin & Support Client Handler Web Server Servlets & JSP Streaming Server (https & http) Sun E220/Solaris 2.6 ncipher SSL accelerator Websphere: - HTTP svr - servlet engine - jsp engine Sun E220/Solaris 2.6 TIBCO Streaming Svr ncipher SSL accelerator Sun E420/Solaris 2.6 Websphere MQseries Application Server Database Server Sun E4500/Solaris GB Disk Array Sybase.9.2 Core Components Security & Entitlements Srv Admin/Reporting Server Sun E420/Solaris 2.6 encommerce GetAccess 50GB Disk Array Sun E420/Solaris GB raid5 Disk Array iplanet Enterprise Svr Webtrends Execution & Market Systems Instrument Repository Foreign Exchange Euro Fixed Income Market Systems 29 Business Functions Sample Logical Architecture Diagram (e.g., virtual classroom environment) Users Connectivity e-business Portal e-business Services Legacy Systems Facilitators Facilitator Interfaces University Intranet LAN PBX-Based Service Presentation Enabling: Authoring Posting Q&A Enabling: Authoring Posting Professor Presentation Enabling: Authoring Q&A Enabling: Integration System Support: Monitoring System Admin. Help Desk Teaching Assistant XML, , Fax Clients PBX-Based Services Front Office Apps University Internet or Intranet LANs Ft Off. & Web Apps (via VPN) Telephony Svcs Front Office Apps University Interne or Intranet LANs Ft Off. & Web Apps (via VPN) "Lights Out" Services Call Forwarding, Teleconferencing, etc. Portal Mgmt. Interface Front Office Apps Educational Applications Maintenance Apps Data Mining Software / Global Content Monitoring / Backup Web-Enabled Applications Facilitator Application, Channel, and Client/ System Admin Interfaces Business Intelligence (Customer Analysis, Course Planning) Customer Care Services (Call Center Support: Educational & Systems) Collaborative Applications "Lights Out" Svcs XML Fax Interfaces Client Interfaces Telephony-Based Services Customer Calls Handling University Internet LAN XML/Web Enabling Facilities Client Request Handler Firewall Client Request Handler Subnet (within DMZ) Web Server Proxy Server Servlet Engine JSP Engine Servlets/JSPs: session hdlr SMIL presentation hdlr Q&A hdlr XML MOM/POP hdlr etc. System Administration Servlets Facilitator/Client Admin. Servlets Client Request Handler API XML-based Component presentation Manager oriented publishing templates Firewall Component Manager Application Server Chat Platform Application Logic Chatroom Component ChatUser Component Client & System Administration Component Entitlement & Security Component Support Services XML Core Services (Doc Hdlr, Version Manager) Session/State Mgmt. Process Automation & Dynamic Content Mgmt. Site Development Svc. DataWarehouse-Driven Processing Connectors Course Production Systems) Back-Office Systems University Systems Firewall Client Administration Login, Authentification, Non-Repudiation Registration Systems Accounting Systems Sales/Marketing Systems Client Support Systtems (carreer management, alumni relations, library support, etc.) Internal Administration Course Development Systems Course Production Systems Human Resources Systems Payroll Systtems Support Systtems Router Presentation Enabling: Querying Locating Viewing Telephony Svcs Web Applications CSR Assisted Services Web-Enabled Applications Client Interface (Presentation querying, locating, and viewing - Integrated Data Architecture Layer Database Management Systems (DBMS) Q&A Enabling: Capture Viewing Students Legend: In scope Out of scope University Internet LAN PDA/WAP Applications WAP Server Internet-Based Services Personalization Interface Channels Interface Real Time Services (Web Channels, Chat, TV Events, etc.) Self Care Services Remote Training Interface Collaborative Applications (2D Avatars, Classroom Navigation, Chat, Events) Voice/Data Integration Customer Profiles Time Critical Information In Memory Database Desktop Filesystems XML SMIL Data MOM & POP XLF Data Templates Operational Data Content-Mgmt Repository Global Application Data Replicas Operational Data Store Client Knowledge Engine Metadata Repository Business Information Warehouse Local Account Data Entitlement/Security Data etc. Legacy Operational Data Educational Research Educational News etc. Third Party Data University Intranet WAN 30

16 Sample Logical Architecture Diagram (e.g., virtual classroom environment) University Systems & Network Management Environment Internet Client Workstation XML, , Fax Professor/TA Workstation Router HSRP Router Connects to all devices below Intrusion Detection Firewall Firewall Students, Professor, and TA Interfaces Intrusion Web-Enabled Detection Applications Clients/Facilitators Application/Admin Interfaces (e.g.,soja Applet) Collaborative Applications (e.g., Chat Applet) Channels Interface NFR Flight Recorder Remote- Sun E220/Solaris 2.6 Checkpoint Firewall- Stonebeat NFR Flight Recorder Remote- University Internet LAN (dual) Load Balancers Alteon AC3 University Mgmt. Firewall Firewall / IIOP Proxy Server Sun E220/Solaris 2.6 Checkpoint Firewall- Stonebeat IONA Wonderwall Proxy Server XML/Web Enabling Facilities Web Server Servlets & JSP Engines Sun E220/Solaris 2.6 ncipher SSL accelerator Apache HTTP sever TomCat servlet engine TomCat jsp engine Client Request Handler Servlets/JSPs: - session handler - SMIL presentation handler - Q&A handler - Cocoon 2 XML POP handler University Intranet LAN (dual) Component Manager Application Server Sun E420/Solaris 2.6 WebLogic Security & Entitlements Srv Database Server Firewall Sun E220/Solaris 2.6 Checkpoint Firewall- Stonebeat Intrusion Detection NFR Flight Recorder Remote- Tape Silo Veritas Network Backup (shared service) Chat Platform Application Logic ChatUser Component Sun E420/Solaris 2.6 encommerce GetAccess 50GB Disk Array Sun E4500/Solaris GB Disk Array Sybase.9.2 ChatRoom Component Support Services XML Core Services Session/State/EOD Mgmt Dynamic Content Mgmt SMIL Data XLF Data Operational Data Global Application Data XML POP Templates Content Mgmt. Repository Sun E420/Solaris GB raid5 Disk Array iplanet Enterprise Svr Webtrends Admin/Reporting Server Intrusion Detection University Intranet LAN Back-Office Systems Client Administration Internal Administration Facilitators, and Production Interfaces Professor/TA Program Administrator Web-Enabled Applications Facilitator Application and Client/System Administration Interfaces 3 Procedural Knowledge Road Map Type of knowledge/ Levels Process Instance level Conceptual model Process instance concept Deployment methodology BPMN+ Interoperability Wf-XML Process definition level Process definition concept WfMC meta-model+ BPMN XPDL+ BPMN - Business Process Modeling Notation, BPMI XPDL - XML Process Definition Language, WfMC Wf-XML - Workflow Interoperability Binding, WfMC 32

17 Process Definition - An Example 33 Possible Process Execution 34

18 UML The UML emphasizes a graphical notation, called diagrams, for representing models UML Models help specifying the artifacts and interactions of a software system UML provides little to no guidance on when and how to use UML diagrams This is an area where EAMF helps as it describes the kinds of project artifacts, such as diagrams, needed during architectural disciplines and helps put them in the context of an overall project plan UML helps formalize architectural models by providing a precise syntax and semantics 35 Review of UML.x UML.x defines twelve types of diagrams, divided into three categories Four diagram types represent static application structure: Class Diagram Object Diagram Component Diagram Deployment Diagram Five represent different aspects of dynamic behavior Use Case Diagram Sequence Diagram Activity Diagram Collaboration Diagram Statechart Diagram Three represent ways you can organize and manage your application modules Packages Subsystems Models See the UML.0 Introduction given under Additional Online Resources for a detailed overview of the various UML modeling notations 36

19 Introducing UML 2.0 UML 2 defines 3 basic diagram types divided into two sets: Structural Modeling Diagrams Behavioral Diagrams Package Diagram Class of Structural Diagram Object Diagram Composite Structure Diagram Component Diagram Deployment Diagram Use Case Diagram Activity Diagram State Machine Diagram Communication Diagram Sequence Diagram Timing Diagram Interaction Overview Diagram See the UML 2.0 tutorial given under Additional Online Resources for a detailed overview of the various UML modeling notations 37 Structural Modeling Diagrams Package diagrams Used to divide the model into logical containers or 'packages' and describe the interactions between them at a high level Class or Structural diagrams Define the basic building blocks of a model: the types, classes and general materials that are used to construct a full model Object diagrams Show how instances of structural elements are related and used at run-time 38

20 Structural Modeling Diagrams (cont.) Composite Structure diagrams Provide a means of layering an element's structure and focusing on inner detail, construction and relationships Component diagrams Used to model higher level or more complex structures, usually built up from one or more classes, and providing a well defined interface Deployment diagrams Show the physical disposition of significant artifacts within a real-world setting 39 Behavioral Modeling Diagrams Use Case diagrams Used to model user/system interactions. They define behavior, requirements and constraints in the form of scripts or scenarios Activity diagrams Have a wide number of uses, from defining basic program flow, to capturing the decision points and actions within any generalized process State Machine diagrams Essential to understanding the instant to intant condition or "run state" of a model when it executes Communication diagrams Show the network and sequence of messages or communications between objects at run-time during a collaboration instance 40

21 Behavioral Modeling Diagrams (cont.) Sequence diagrams Closely related to Communication diagrams and show the sequence of messages passed between objects using a vertical timeline Timing diagrams Fuse Sequence and State diagrams to provide a view of an object's state over time and messages which modify that state Interaction Overview diagrams Fuse Activity and Sequence diagrams to provide allow interaction fragments to be easily combined with decision points and flows 4 Visual Modeling with UML 2.0 * Activity Diagrams Use Case Diagrams Package Diagrams Class Diagrams Object Diagrams State Machine Diagrams Component Diagrams Sequence Diagrams Models Composite Structure Diagrams Communication Diagrams Timing Diagrams Interaction Overview Diagrams Deployment Diagrams Dynamic Diagrams Static Diagrams 42

22 Use of UML Artifacts to Construct EAMF Views Diagram Name Use Case Class Activity State Machine Object Package Composite Structure Deployment Interaction Overview Sequence Communication Type Dynamic Static Dynamic Dynamic Static Static Static Static Dynamic Dynamic Dynamic EAMF Disciplines Analysis Analysis Analysis Analysis Analysis Analysis Analysis Analysis Design Design Design Timing Component Dynamic Static Design Design 43 UML 2.0 Domains UML defines the notation and semantics for the following domains: User Interaction or Use Case Model Interaction or Communication Model State or Dynamic Model Logical or Class Model Physical Component Model Physical Deployment Model UML.x used use case, logical, process, implementation, and deployment views instead of domain models Views used specific (sets of) UML.x diagrams to look at overall models from various angles 44

23 Put Coffee in Filter Put Filter in Machine Turn on Machine BrewCoffee Find Beverage Add Water to Reservoir ^coffeepot.turnon [ found coffee ] light goes out [ no coffee ] Get Cups Pour Coffee Get Can of Cola Drink Beverage [ no cola ] [ found cola ] Player (fromuse Case View) Rolls name : String score : int = 0; 2 play() Plays DiceGame HighScore Scoring Die facevalue : int = roll() Includes / S tart game Ready to play Quit [ turn>=0 ] cancel start Cancel Player ready entry: get player name play roll dices[ turn<0 ] In progress entry: turn++ : DiceGame : play( ) : Player 2: roll( ) d : Die 3: roll( ) d2 : Die DicePersist HighScore PersistKit DiceSystem Randomizer Random system Play the game Displayable Observable JBDC Connection Game Computer File System Observer Save/load the highscore Dice Vizualization SGBD computer Maybe a Remote a file system Maintaining Models Consistency/Coverage Functional view Architectural View Player Play View High Score Static View Consistency Coverage game : Dice Game : play( ) 2: r=roll( ) 3: r2=roll( ) Behavioral View d : Die Momo : Player d2 : Die 45 Component/Composite/Workflow Business Services 46

24 Sample SOAD Interaction Model 47 Roadmap Sample Enterprise Reference Architectures Information Management Aspects Service Management Aspects Service vs. Component Management 48

25 Information Management Aspects Front-End Aspects Consumption Search/Query, Portal, Analytics Management Modeling, Profiling, Indexing, Quality Availability Federation, ETL, Replication, Event Collaboration Workflow, Version Control Security Single Sign-On, Audit, Access Control Infrastructure Aspects Heterogeneous Data Sources Access Text/XML files, spreadsheets, messages, relational data, content data Metadata Management & Storage 49 Service Management Aspects 50

26 Service vs. Component Management 5 Roadmap Traditional Object Oriented Architecture Analysis & Design Approach (Review) From Requirements to Analysis Analysis Class Use Case Realization Example: Pay Invoice Use Case Pay Invoice Use Case: Flow of Events Analysis Class Diagram Realizing a Pay Invoice Use Case Collaboration Diagram Realizing a Pay Invoice Use Case Analysis and Design Workflow Summary: Architecture Engineering Steps Summary: Architecture Engineering Artifacts 52

27 From Requirements to Analysis Requirements specify the behavior of the largestgrained component: the system Specifies the behaviors the system provides for and with the actors The system shall Object-oriented analysis is reduction of a system to a coarse set of discovered objects with responsibilities, so that the set of objects is able to fulfill the behavioral requirements of the user Analysis limits the effort to objects found in the domain otherwise you are doing design 53 Analysis Class Analysis Class Entity Boundary Control Analysis classes represent an early conceptual model for things in the system which have responsibilities and behavior Class, stereotyped as «boundary», «entity» or «control» Entity classes Long-lived, real-life object or event in the application domain Data and behavior Usually persistent (saved in a file or database) Boundary classes Interaction between the system and its actors At the system boundary Control classes Coordination and sequencing of system behavior Transactions 54

28 rep Repository name : char * = 0 readdoc( ) readfile( ) FileMgr fetchdoc( ) sortbyname( ) (from Persistence) FileList add( ) delete( ) read( ) File DocumentList add( ) delete( ) flist GrpFile read( ) open( ) create( ) fillfile( ) Document name : int docid : int numfield : int get( ) open( ) close( ) read( ) sortfilelist( ) create( ) filldocument( ) read() fill the code.. Use-Case Realization Use Case Use Cases <<trace>> Class diagram Use-Case Realization Sequence diagram A use-case realization is a description of how a particular use case is realized within the design model, in terms of collaborating objects Collaboration diagram 55 Example: Pay Invoice Use Case The use case Pay Invoice is used by a Buyer to schedule invoice payments. The Pay Invoice use case then completes the payment on the due date Pre-condition: The Buyer has received the goods or services ordered and at least one invoice from the system. The Buyer now plans to schedule the invoice(s) Post-condition: The use-case ends when the invoice has been paid or the invoice payment was canceled and no money was transferred 56

29 Pay Invoice Use Case: Flow of Events Primary Scenario (i.e., basic path) The buyer invokes the use case by beginning to browse the invoices received by the system. The system checks that the content of each invoice is consistent with the order confirmations received earlier (as part of the Confirm Order use case) and somehow indicates this to the buyer. The order confirmation describes which items will be delivered, when, where, and at what price. The buyer decides to schedule an invoice for payment by the bank, and the system generates a payment request to transfer money to the seller s account. Note that a buyer may not schedule the same invoice for payment twice. Later, if there is enough money in the buyer s account, a payment transaction is made on the scheduled date. During the transaction, money is transferred from the buyer s account to the seller s account, as described by the abstract use case Perform Transactions (which is used by Pay Invoice). The buyer and the seller are notified of the result of the transaction. The bank collects a fee for the transaction, which is withdrawn from the buyer s account by the system. The use-case instance terminates 57 Analysis Class Diagram Realizing a Pay Invoice Use Case Order Confirmation Order Handler Invoice Buyer Payment Request UI Payment Scheduler Payment Request 58

30 Collaboration Diagram Realizing a Pay Invoice Use Case 5: Get : Order Confirmation 3: Check Invoice : Order Handler 4: Get : Browse Invoice 6: Schedule Invoice for Payment 2: Browse 9: setstatus(scheduled) : Invoice Scott : Buyer : Payment Request UI 7: Schedule payment 8: New : Payment Scheduler : Payment Request 59 Analysis and Design Workflow 60

31 Summary: Architecture Engineering Steps Create an initial sketch of the architecture of the system Define an initial set of architecturally significant elements to be used as the basis for analysis Issues that are typically architecturally significant include performance, scaling, process and thread synchronization, and distribution Define an initial set of analysis mechanisms Define the initial layering and organization of the system Define the use-case realizations to be addressed in the current iteration Identify analysis classes from the architecturally significant use cases Update the use-case realizations with analysis class interactions 6 Summary: Architecture Engineering Steps (cont.) How to Staff Small team with cross-functional team members The team should include members with domain experience who can identify key abstractions The team should also have experience with model organization and layering Work Guidelines The work is best done in several sessions, perhaps performed over a few days (or weeks and months for very large systems) Iterate between Architectural Analysis and Use-Case Analysis 62

32 Summary: Architecture Engineering Steps (cont.) 63 Summary: Architecture Engineering Artifacts 64

33 Roadmap Clean Separation Between Analysis and Design Analysis versus Design Not Top-Down or Bottom-Up Review: Use Case Analysis Steps Analysis Results Grow the Design Designer Role 65 Analysis versus Design Analysis Focus on understanding the problem Idealized design Behavior Functional structure Functional requirements A small model Design Focus on understanding the solution Operations and attributes Performance Close to real code Object lifecycles Non-functional requirements A large model 66

34 Analysis versus Design Analysis Understand the problem and begin to develop a visual model of what you are trying to build Independent of implementation and technology concerns Translate the functional requirements into software concepts Get a rough cut at the objects that comprise the system Focus on behavior Focus on structure: coupling/separating concerns Design Refine the model into a form that will allow a seamless transition into implementation 67 Analysis versus Design If you tried to manage all of the analysis and design issues in one go, your brain would explode on all but the most trivial developments. Mental switch of focus Analysis: problem domain I docare about what the system has to do I don t care (as much) about memory, persistence, databases, languages, etc. Design: solution domain I docare about memory, persistence, databases,etc. I don t care (as much) about understanding the problem In practice, Analysis and Design are closely related and often iterative To understand a problem, produce a solution The as much above is a balance of focus 68

35 Not Top-Down or Bottom-Up It is Middle-In/Out The use cases define a middle level At the middle level, identify analysis classes that collaborate to realize the use cases From the middle level, move up and down Up: Defining subsystems Down: Defining design classes Understanding and solving the problem is iterative Middle-to-Top, Top-to-Middle, Middle-to-Bottom, and Bottom-to- Middle Use Cases Subsystems Analysis Classes Design Classes 69 Review: Use-Case Analysis - Steps Supplement the Use-Case Description 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 architectural analysis mechanisms Unify analysis classes Review 70

36 Analysis Results Architecture Packages organized into Layers focused on upper layers Analysis mechanisms Key abstractions (classes) Classes Classes named to reflect their roles and responsibilities Classes defined Responsibilities, Attributes Associations Classes are internally cohesive Classes assigned to packages Closely related classes are in the same packages Packages are loosely coupled Use-case realizations All required functionality is realized all flows are realized Each class has the attributes and responsibilities it needs to carry out its assigned responsibility 7 Grow the Design 72

37 Designer Role The designer role defines the responsibilities, operations, attributes, and relationships of one or several classes, and determines how they will be adjusted to the implementation environment Skills and Knowledge Use-case modeling techniques System requirements Software design techniques, including object-oriented analysis and design techniques, and the Unified Modeling Language Technologies with which the system will be implemented 73 Roadmap Planning Design Alternatives Step into Design Purpose of Grow the Design Workflow Context of Use Case Design Background of Use Case Design Verifying for Consistency Purpose of Use Case Design Use Case Design Steps 74

38 Step into Design Next steps are to refine the analysis model into a design model Two perspectives for further decomposition Architecture: further detailing of parts and their relationships Packages Subsystems Analysis mechanisms Design mechanisms Class: further detailing of the parts Analysis classes Design classes, components, and interfaces A third perspective assures integration ( Re-composition ) Use-case realization -- Design 75 Purpose of Grow the Design Workflow Provide the natural transition from analysis activities to design activities, identifying: appropriate design elements from analysis elements appropriate design mechanisms from related analysis mechanisms Maintain the consistency and integrity of the architecture, ensuring that: new design elements identified for the current iteration are integrated with pre-existing design elements. maximal re-use of available components and design elements is achieved as early as possible in the design effort. 76

39 Context of Use-Case Design Based on prior analysis and design, we have An initial architecture design Defined major elements of our system (subsystems, their interfaces, the design classes, the processes, and threads) and their relationships An understanding of how processes map to system hardware Now, in use-case design, we concentrate on how a use case is implemented and make sure there is consistency from beginning to end Use-case design is where the design elements meet the architectural mechanisms The use-case realization from analysis is refined to included the design elements, using the patterns of interaction 77 defined for the architectural mechanisms Background of Use-Case Design Use-Case Design is a cross-checking, consistency-imposing activity Focus on a use-case thread to make sure everything still fits together Continually review the interaction diagrams, looking for inconsistencies missing information opportunities for reuse etc. Make sure we have operations for the whole path of the flow of events 78

40 Verifying for Consistency For each use case, across all use cases, verify that All the necessary behavior to support a use-case implementation has been distributed among the appropriate participating classes The use-case flows naturally over the participating design elements All associations between design elements (classes or subsystems) needed for the use case realizations have been defined All the attributes needed for the use-cases have been defined Refine the analysis-level use cases to included the defined design model elements (which are the design classes and subsystems that the analysis classes have morphed into ) Incorporate applicable architectural design 79 mechanisms Purpose of Use-Case Design To refine use-case realizations in terms of interactions. To refine requirements on the operations of design classes. To refine requirements on the operations of subsystems and/or their interfaces. To refine requirements on the operations of capsules 80

41 Use-Case Design Design Classes Supplementary Specification Multiple design teams, each with a different focus Design Subsystems and Interfaces Use-Case Design Use-Case Realization Design (Refined) Use-Case Realization -Analysis Use-Case Specifications Class diagrams Sequence diagrams Refined flow-ofevents descriptions 8 Use-Case Design Steps Describe interaction between design objects Simplify sequence diagrams using subsystems Describe persistence related behavior Read, write, delete persistent objects Model transactions Handle error conditions Handle concurrency control Refine the flow of events description Unify classes and subsystems Evaluate your results 82

42 rep Repository name : char * = 0 readdoc( ) readfile( ) FileMgr fetchdoc( ) sortbyname( ) (from Persistence) FileList add( ) delete( ) read( ) File DocumentList add( ) delete( ) flist GrpFile read( ) open( ) create( ) fillfile( ) Document name : int docid : int numfield : int get( ) open( ) close( ) read( ) sortfilelist( ) create( ) filldocument( ) : Doc view request ( ) user :»ç ëàú read() fill the code.. 9: sortbyname ( ) mainwnd : MainWnd L 2: fetchdoc( ) 4: create ( ) 8: fillfile ( ) filemgr : FileMgr 7: readfile ( ) 5: readdoc ( ) repository : Repository Æ Á ¹ ¼- ëçñ º ±â»ç ëàú äã»çñ Ù. È-ÀÏ ü ÀÚ Â Àоî  ¹ ¼-ÀÇ Á º ÇØ ç ¹ ¼- ü ¼³Á À» äã»çñ Ù. È- é ü  ÀоîµéÀΠüµé ëçø ÀÌ º Î Á ÄÀ» ½ÃÄÑ È- é º ÁØ Ù. 3: create ( ) 6: filldocument ( ) : Doc view request ( ) gfile : GrpFile document : Document 9: sortbyname ( ) 2: fetchdoc( ) 3: create ( ) 6: filldocument ( ) 4: create ( ) 5: readdoc ( ) 8: fillfile ( ) 7: readfile ( ) Use-Case Design Steps Next Describe interaction between design objects Simplify sequence diagrams using subsystems Describe persistence related behavior Read, write, delete persistent objects Model transactions Handle error conditions Handle concurrency control Refine the flow of events description Unify classes and subsystems Evaluate your results 83 Review: Use-Case Realization Use Case Use Cases <<trace>> Class diagram Use-Case Realization user Sequence diagram mainwnd filemgr : FileMgr document : Document gfile repository A use-case realization is a description of how a particular use case is realized within the design model, in terms of collaborating objects Collaboration diagram 84

43 Review: From Analysis Classes to Design Elements Analysis classes will seldom retain their same structure through design They may be expanded, collapsed, combined, or even deleted in design Analysis Classes Many-to-Many Mapping Design Elements 85 Use-Case Realization Refinement Identify participating objects Allocate responsibilities amongst objects Model messages between objects Describe processing resulting from messages Model associated class relationships In essence, re-draw the analysis realizations, now using the design elements the analysis models were refined into, making sure that the allocation of responsibility is still accurate Sequence diagrams Class diagrams 86

44 Use-Case Realization Refinement Steps Identify each object that participates in the flow of the use-case Represent each participating object in a sequence diagram Incrementally incorporate applicable architectural mechanisms 87 Use-Case Design Steps Next Describe interaction between design objects Simplify sequence diagrams using subsystems Describe persistence related behavior Read, write, delete persistent objects Model transactions Handle error conditions Handle concurrency control Refine the flow of events description Unify classes and subsystems Evaluate your results 88

45 With Subsystems &Architectural Mechanisms Look at the interaction diagrams For each class that has been refined into a subsystem, replace the class with the associated subsystem interface Any interactions that describe HOW the subsystem should implement the service should be deferred until subsystem design Incrementally incorporate any applicable architectural mechanisms Use the patterns of behavior defined for the mechanisms May include the introduction of new design elements and messages Update the dynamic and static parts (sequence diagrams and view of participating classes diagram) 89 Representing Subsystems on a Sequence Diagram Interfaces Represents any model element that realizes the interface No message should be drawn from the interface Proxy class Represents a specific subsystem Messages can be drawn from the proxy Proxy OK 90

46 Example : Incorporating Subsystem Interfaces Analysis Classes Design Elements <<Interface>> ICourseCatalogSystem (from External System Interfaces) CourseCatalogSystem + getcourseofferings(forsemester : Semester) : CourseOfferingList + init ialize() //get course offerings() <<subsystem proxy>> CourseCatalogSystem (from CourseCatalogSystem) + getcourseofferings(forsemester : Semester) : CourseOfferingList + initialize() <<Interface>> IBillingSys tem (from External System Interfaces) BillingSystem + submitbill(fortuition : Double, forstudent : Student) //submit bill() <<subsystem proxy>> BillingSystem + submitbill(forstudent : Student, fortuition : double) 9 Example: Incorporating Subsystem Interfaces (Before) Replace with subsystem interface : Student : Regist erforcoursesform : RegistrationController : CourseCatalogSystem : Course Catalog : Schedule : Student. // create schedule( ) Student wishes to create a new schedule.. // get course offerings( )... // get course offerings(forsemester)... // get course offerings( ).2. // display course offerings( ) A list of the available course offerings for this semester are displayed A blank schedule is displayed for the students to select offerings.3. // display blank schedule( ) 2. // select 4 primary and 2 alternate offerings( ) 2.. // create schedule with offerings( ) 2... // create with offerings( ) // add schedule(schedule) At this, point the Submit Schedule subflow is executed. Sequence Diagram: Register for Courses / Register for Courses - Basic Flow (Submit Schedule) 92

47 Example: Incorporating Subsystem Interfaces (After) Replaced with subsystem interface This flow is inserted after the Register for Courses - Basic Flow Sequence Diagram: Register for Courses / Register for Courses - Basic Flow : Student : RegisterForCoursesForm : RegistrationController : Schedule : Student. : ICourseCata.... createschedule( ).. // get course offerings( ) Student wishes to create a new schedule.2. displaycourseofferings( )... getcours eofferings(semester) A list of the available course offerings for this semester are displayed A blank schedule is displayed for the students to select offerings.3. displayblankschedule( ) 2. select 4 primary and 2 alternate()( ) 2.. create schedule with offerings(courseofferinglist, CourseOfferingList) Sequence Diagram: University Artifacts / Use of Schedule Offering Info 2... new(forsemester : Semester, withprimaryofferings : CourseOfferingList, withalternateofferings : CourseOfferingLi addschedule(theschedule : Schedule) At this, point the Submit Schedule subflow is executed. 93 Encapsulating Subsystem Interactions Coarse-grained interaction between subsystems Fine-grained interaction within subsystems Interactions can be described at several levels of abstraction Subsystem internal interactions can be described in their own interaction diagrams 94

48 When to Encapsulate Sub-Flows in a Subsystem Encapsulate a sub-flow when it: occurs in multiple use-case realizations has reuse potential is complex and easily encapsulated is the responsibility of one person/team produces a well-defined result is encapsulated within a single Implementation Model component Make sure that what you are abstracting is worth abstracting 95 Guidelines: Encapsulating Subsystem Interactions Subsystems should be represented by their interfaces on interaction diagrams Messages to subsystems are modeled as messages to the subsystem interface Messages to subsystems correspond to operations on the subsystem interface Interactions within subsystems are modeled in subsystem design InterfaceA op() :InterfaceA op() 96

49 Advantages of Encapsulating Subsystem Interactions Use-case realizations Are less cluttered Can be created before the internal designs of subsystems are created parallel development Are more generic and easier to change subsystems can be substituted 97 Parallel Subsystem Development Concentrate on requirements that affect subsystem interfaces Outline required interfaces Model messages that cross subsystem boundaries Draw interaction diagrams in terms of subsystem interfaces fore each use-case Refine the interfaces needed to provide messages Develop each subsystem in parallel Use subsystem interfaces as project synchronization points 98

50 Use-Case Design Steps Next Describe interaction between design objects Simplify sequence diagrams using subsystems Describe persistence related behavior Model transactions Read, write, delete persistent objects Handle error conditions Handle concurrency control Refine the flow of events description Unify classes and subsystems Evaluate your results 99 Modeling Transactions What is a Transaction? Atomic operation invocations All or nothing Assure consistency in changes Modeling options Textually (scripts) Explicit messages Error conditions Rollback Failure modes May require separate interaction diagrams 00

51 Use-Case Design Steps Next Describe interaction between design objects Simplify sequence diagrams using subsystems Describe persistence related behavior Model transactions Read, write, delete persistent objects Handle error conditions Handle concurrency control Refine the flow of events description Unify classes and subsystems Evaluate your results 0 Detailed Flow of Event Description Options Annotate the interaction diagrams to clarify behavior Timing Conditional behavior Clarification or constraint on operation behavior Control flow (decision steps, looping, branching) Use UML notes or use free-form text 02

52 Use-Case Design Steps Next Describe interaction between design objects Simplify sequence diagrams using subsystems Describe persistence related behavior Model transactions Read, write, delete persistent objects Handle error conditions Handle concurrency control Refine the flow of events description Unify classes and subsystems Evaluate your results 03 Design Model Unification Considerations Model element names should describe their function Avoid similar names Avoid synonyms Merge similar model elements Use inheritance to abstract model elements Keep model elements and flows of events consistent When updating a model element, also update the affected use-case realizations 04

53 Use-Case Design Steps Next Describe interaction between design objects Simplify sequence diagrams using subsystems Describe persistence related behavior Model transactions Read, write, delete persistent objects Handle error conditions Handle concurrency control Refine the flow of events description Unify classes and subsystems Evaluate your results 05 Checkpoints: Use- Case Design Is package/subsystem partitioning logical and consistent? Are the names of the packages/subsystems descriptive? Do the public package classes and subsystem interfaces provide a single, logically consistent set of services? Do the package/subsystem dependencies correspond to the relationships between the contained classes? Do the classes contained in a package belong there according to the criteria for the package division? Are there classes or collaborations of classes which can be separated into an independent package/subsystem? 06

54 Checkpoints: Use- Case Design Have all the main and/or sub-flows for this development iteration been handled? Has all behavior been distributed among the participating design elements? Has behavior been distributed to the right design elements? If there are several interaction diagrams for the use-case realization, is it easy to understand which diagrams relate to which flow of events? 07 Any Questions? 08