1 / 29

Service Oriented Analysis II: Service Modeling

Service Oriented Analysis II: Service Modeling. 605.702 Service Oriented Architecture Johns-Hopkins University Montgomery County Center, Spring 2009 Lecture 9: April 6, 2009 Instructor: T. Pole . Agenda. Class Project Deliverables (introduction)

Antony
Télécharger la présentation

Service Oriented Analysis II: Service Modeling

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Service Oriented Analysis II:Service Modeling 605.702 Service Oriented ArchitectureJohns-Hopkins University Montgomery County Center, Spring 2009 Lecture 9: April 6, 2009 Instructor: T. Pole

  2. Agenda • Class Project Deliverables (introduction) • Review Chapter 11: Service Oriented Analysis (Part I Introduction) • Chapter 12 Service Oriented Analysis (Part II Service Modeling) • Class Project • Summary • Please Note: • Exercise 4B Review will be Wednesday

  3. Class Project Deliverables (Introduction) • Report • Results • Benefits analysis of SOA • Service Oriented Analysis • Service Oriented Design • Future planning • Testing, Deployment and Administration • Implementation • Services from your SOA design • Including legacy wrapping utility services • End user client • Automates business process in requirements of system

  4. Ch 11: Service Oriented Analysis ISummary from last week • Benefits of a Business Centric SOA • Benefits Analysis – why make the investment in SOA • Determine scope of the SOA • Based on requirements • Derive additional requirements • Identification of business processes that will be automated in the SOA • Identify Automation Systems • What legacy automation systems will support the SOA • Model (Candidate) Services • Names of and purpose of services • Service Layers

  5. Ch 12: Service Oriented Analysis IIService Modeling • Consider, take into account and manage: • Reusability • Cross process • Intra-process • Dependencies • Balancing the architecture model • Control services • Using orchestration or choreography • Using application logic

  6. Overview of Class Project • What you will deliver for each of: • Business Benefits Analysis • Service Oriented Analysis • Service Oriented Design • Service Development • Service Testing • Service Deployment • Service Administration

  7. Instructions • The class project consists of multiple deliverables. • Each deliverables DOES NOT have to be a separate artifact • Most deliverables will be part of one main document • Each deliverable in the project submission MUST BE LABELLED (e.g. Deliverable 0-01 Business Benefits)

  8. Benefits Analysis • Report: 1 page • Deliverable 0-01 Business Benefits. Identify what the business benefits are that are specific to this business • Deliverable 0-02 Technical Benefits. Identify what the technical benefits are, and what the business benefits are that can be derived from those technical benefits

  9. Project: Service Oriented Analysis • Report: 2-3 pages • Determine the scope of the SOA • Deliverable 1-01 Requirements Statement. • Supplied user requirements and your derived requirements • Deliverable 1-02 Business Processes. ERM Diagrams (see 11.3) for each usage scenario • Optionally: entity dependence diagram (see 11.4) • Map out the (candidate) service layers • Deliverable 1-03 Candidate Architecture. Draft service layered architecture diagram (see figures 9.7 though 9.14) • Include legacy system automation that will be integrated • Identify individual service operations modeled as candidate services • Deliverable 1-04 Candidate Operations. Draft list of candidate operations • Analysis process is identified in chap 11 and 12

  10. Project: Service Oriented Design • Report: At least 5 pages, probably 10 or more • Service Layers are finalized • Deliverable 2-01 Final Architecture. Final layered architecture diagram. • Candidate operations list is finalized • Deliverable 2-02 Final Services and Operations List. Complete list of and description of the purpose of each service, and within each service the list of and description of the purpose of each operation (see figure 12.4.2) • Business process are mapped to operation sequences that will automate them (see figure 12.9 trough 12.11) • Deliverable 2-03 Map of each business process ERM diagram to its’ automation in the layered architecture SOA diagram For each inter-service connection recommend (in a foot note) any ws-* extensions appropriate for the service connection. (reuses 2-01) • SOA Design process is defined in chapters 13 - 15

  11. Service Development • Actual construction of the services • All software is in ONE VS2008 Solution • Each service is implemented, as a separate project in that solution • A end user client will be included which demonstrates how the solution supports each of the required business processes • Deliverable 3-01 Solution: The entire solution will be zipped into a single file, and then delivered on a CD-ROM or memory stick in class (I will NOT be able to return the CD’s or memory sticks, and CD’s cost less) • Deliverable 3-02 A short user’s manual on how to install the clients and use them to invoke the services will be submitted as a text, PDF or Word file on the same CD.

  12. Future Planning Appendix • Your class project report will include appendices for deliverables 4-01, 4-02 and 4-03. • Each will be a short discussion (1 page or less) of what must be done to plan: • 4-01 Service and Solution Testing • 4-02 Service and Solution Deployment • 4-03 Service and Solution Administration

  13. 4-01 Service Testing • Involves both “unit” testing, and system or integration testing • “unit” testing: testing individual services, or even individual operations out of context • Deliverable 4-09 A short “unit” test plan (what to do and what to expect when you do it) for each service, which exercises each operation. • system testing: testing entire operation sequences against the business process they automate • Deliverable 4-10 A short system test plan which explains how to use your client(s) to accomplish the automated portion of each use case scenario, for each business process your SOA supports.

  14. 4-02 Service Deployment • The deployment (installation, configuration, etc.) of all individual services, and their consumers/requestors • Integrating the services with • their underlying functional components • COTS products • Legacy systems

  15. 4-03 Service Administration • Operate the system • Train users in the use of the system • Maintain the system • Evolve the system • Track usage, maintenance, etc. of the system

  16. Class Project: XYZ SEAM An example of a System Engineering Asset Management (SEAM) System

  17. Overview: • Remember, the goal here is to learn the analysis and design of an SOA solution, not SEAM • We will only discuss some of the goals and processes of a SEAM • We will discuss a system which satisfies only some of the requirements of a SEAMSys • The automation side of a SEAM • The design and implementation will not be complete fro the class project • Some security, maintainability, dependability issues will be simplified or ignored

  18. SEAM Business Goals • Manage (capture, make accessible and preserve) the work products of engineering activities • Control • Capture the engineering work products (assets) • Capture the metadata about those assets • Make Accessible • Organize assets and assets’ metadata so that assets can be found and accessed • Preserve • Protect assets from unapproved changes, and capture approved change history

  19. SEAM Business Processes • Initializing SEAM • Establishing SEAM ingest, access and reuse policies and procedures • Implementing SEAM System (automation) • Operating SEAM • Linking new project(s) to SEAM • Ingesting assets into SEAMSys • Finding and accessing assets in SEAMSys • Updating SEAM controlled assets • Repurposing/Reusing SEAM assets

  20. XYZ Software Company P&P • Policies and Procedures • All programs will maximize reuse of past development efforts • Program managers are responsible that this happens • PMs and staff are rewarded for reusing assets, or creating reusable assets (but not till they’re reused) • All engineering assets are stored in the DocManager system • Weekly system build are only built from software in the DocManager system • Company policy says that all requirements statements, design documents , source code and testing material must be checked into the DocManager system • Project is not complete until QA has verified that all assets are checked into the DocManager system • A life cycle phase can not be marked as complete on project schedule until all engineering assets created in that phase are checked in to the DocManager system • XYZ software purchased ABC software in 2005 and QED software in 2007. They did not follow XYZ P&P, but the ABC and WED CM archives are available on line in other document management systems • PM’s are given bonuses based partly on the percentage of reuse their programs consume. This also helps determine the size of the bonus pool available for PM’s to share with their staff • Directors are given bonuses based partly on the number of reuses of components created by programs under their direction. This also determines the size of the bonus pool available for Directors to share with their staff.

  21. XYZ Software SEAM Related Business Processes • Engineers search SEAM for assets to reuse • Engineers access assets via SEAM • Engineer submits new assets to SEAM • Project registers with SEAM • This enables them to access SEAM for reuse existing assets, and submit new assets • This is required to gather reuse metrics per project • SEAM admins update asset • Which notifies registered asset users

  22. In Class Demonstration Project • Overview: ITInc Program Tracking (IPT) SOA Project • IPT Business Goals • IPT Business Processes • IPT Policies and Procedures • IPT Related Business Processes

  23. Overview: ITInc Program Tracking (IPT) SOA Project • IT Inc is a system integrator, building COTS based IT systems for its customers • Both for billing customers and tracking cost and profits on projects, ITInc must improve the way it tracks projects • In order to develop and maintain organization agility, the IPT project will be developed using an SOA approach

  24. IPT Business Goals • Keep track of all resources available for projects, including staff, equipment, consumables and funds • For each project • Allocate resources • Note: Estimate of required resources is NOT in scope • Track consumption of consumable resources • Consumable product (e.g. software licenses) • Staff hours

  25. IPT Business Processes • Deployment and administration of IPT • Modeling of available resources and past projects • Integration of IPT with financial systems • Operation of IPT • Setting up new projects in IPT • Assigning resources to projects • Tracking consumption of resources

  26. IPT Policies and Procedures • Policies and Procedures • All programs will track work performed by staff, both ITInc employees and contractors. • Program managers are responsible that this happens • PM’s and other managers are incentivized according to their tracking of resource consumption and keeping to budgeted allocations • All staff must record their actual hours worked per project, on a daily basis • All staff must record their use of consumables, on a weekly basis • All staff must use only equipment (non-consumables) assigned to the tasks they are working on, and use it only for the project they are currently charging their labor time to • Each project is allocated resources by senior management • Business Operations assigns labor and equipment funds • Engineering Management assigns equipment and engineering consumables

  27. IPT Related Business Processes • BizOps Management sets up projects in IPT • Engineering Management assigns equipment and engineering consumable resources to projects in IPT • BizOps assigns funding for labor and other resources to projects in IPT • Staff records hours worked per project in IPT • Project managers and project leads record non-labor resource consumption • Managers in the project validate labor hours recorded • Program manager validates all resource consumption

  28. White Board Exercise • IPT requirements Statement • Business Processes and Business Process Diagrams • Candidate Architecture • Service Layers • Candidate Services • Candidate Operations

  29. Process Derivation Exercise • I’m the customer • You’re the analyst • Here are my requirements (next slides) • Start asking me questions and identifying and or deriving the business processes that you will be automating in your SOA • Working toward: • 1-01requirements Statement (including derived) • 1-02 Business Process, ERM Diagrams • 1-03 Candidate Architecture • Service Layers • Candidate Services and Operations

More Related