Contract First Modeling Services Using Uml


Published on

Presentation given in the minor EAD at ICA, HAN University

Published in: Technology
  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • Contract First Modeling Services Using Uml

    1. 1. Contract first modeling Services using UML Minor Enterprise Application Development
    2. 3. Validating the approach <ul><li>“… in my opinion services are a technical implementation of a functional defined use case. So when you say that services are reducible from business processes you are absolutely right, because creating a service can only happen as a result of a business process needing it. In my experience services have never been the cause for starting to model. The service is there because of the reference architecture that has been chosen. When you take a closer look at Tobago MDA, you will see that after modeling a business process in user goal uc's and subfunction uc's it is possible to generate a service interface and other technical elements that implement the uc. Having your students specify and design the technical flow you can use activity diagrams and sequence diagrams. I have used these diagram techniques when modeling workflows and other framework entities to see how objects interact and what the lifetime of objects is. It is wise to associate the functional domain (uc's distilled from a business process) to the technical domain (activity diagrams and sequence diagrams) but the association is for clarity reasons and to keep track of things when your design grows bigger over time.” </li></ul>Wouter Goedvriend, CapGemini
    3. 4. Use Cases Merge Companies Merge Mortgage Systems Place Order Select Product Insert Orderline
    4. 5. Why Smart Use Cases <ul><li>Modeled early in projects </li></ul><ul><li>Low effort </li></ul><ul><li>Visual representation </li></ul><ul><li>Single level of complexity </li></ul><ul><li>Similar granularity </li></ul><ul><li>Good unit of work in iterative projects </li></ul><ul><li>Can be based on most functional requirements specifications, business processes or existing applications </li></ul><ul><li>Technology independent </li></ul><ul><li>Reproducible </li></ul><ul><li>Repeatable </li></ul>
    5. 6. Example Smart Use Cases
    6. 7. Cookbook <ul><li>Define the main processes in the company starting with the name of the company as the root </li></ul><ul><li>Refine the processes to EBPs, which resemble sea level use cases </li></ul><ul><ul><li>Use smart use cases to define services and find out relations and possibilities for re-use </li></ul></ul><ul><ul><li>Use activitydiagrams for complex relationships like choices and flows </li></ul></ul><ul><li>Use sequence diagrams to define operations and interfaces of the services. Redefine operations using XSD. </li></ul><ul><li>Separate classes and interface through classdiagrams, define public and private operations. </li></ul>
    7. 8. Why Contract First <ul><li>Two approaches </li></ul><ul><ul><li>Contract first </li></ul></ul><ul><ul><li>Contract last “Things are not as simple as they appear: there is a fundamental difference between hierarchical languages such as XML (and especially XSD) and the graph model of Java” </li></ul></ul>
    8. 9. Object XML Mismatch <ul><li>XSD Extensions </li></ul><ul><li>Unportable Types </li></ul><ul><li>Cyclic Graphs </li></ul><ul><li><simpleType name=&quot;AirportCode&quot;> </li></ul><ul><li><restriction base=&quot;string&quot;> </li></ul><ul><li><pattern value=&quot;[A-Z][A-Z][A-Z]&quot;/> </li></ul><ul><li></restriction> </li></ul><ul><li></simpleType> </li></ul>
    9. 10. Object XML Mismatch <ul><li>XSD Extensions </li></ul><ul><li>Unportable Types </li></ul><ul><li>Cyclic Graphs </li></ul><ul><li>public Map getFlights() </li></ul><ul><li>{ </li></ul><ul><li>TreeMap map = </li></ul><ul><li>new TreeMap(); map.put(&quot;KL1117&quot;, </li></ul><ul><li>&quot;Stockholm&quot;); </li></ul><ul><li>return map; </li></ul><ul><li>} </li></ul>
    10. 11. Object XML Mismatch <ul><li>XSD Extensions </li></ul><ul><li>Unportable Types </li></ul><ul><li>Cyclic Graphs </li></ul><ul><li>public class Flight { </li></ul><ul><li>private String number; </li></ul><ul><li>private List<Passenger> passengers; </li></ul><ul><li>} </li></ul><ul><li>public class Passenger { </li></ul><ul><li>private String name; </li></ul><ul><li>private Flight flight; </li></ul><ul><li>} </li></ul>
    11. 12. Contract Last <ul><li>Fragility </li></ul><ul><ul><li>no guarantee that the contract stays constant over time </li></ul></ul><ul><ul><li>not all SOAP stacks generate the same web service contract from a Java contract </li></ul></ul><ul><li>Performance </li></ul><ul><ul><li>there is no way to be sure as to what is sent across the wire </li></ul></ul><ul><li>Reusability </li></ul><ul><ul><li>defining your schema in a separate file allows you to reuse that file in different scenarios </li></ul></ul><ul><li>Versioning </li></ul><ul><ul><li>if using contract-first, we can have a looser coupling between contract and implementation </li></ul></ul>
    12. 13. Messages and Services, not Method Calls and Objects <ul><li>No, no, no – not (just) XML-based RPC </li></ul><ul><ul><li>Tools imply this, though… </li></ul></ul><ul><li>Abstractions & decoupling </li></ul><ul><ul><li>Factors for successful and evolvable applications & architectures </li></ul></ul><ul><li>Service-oriented principles </li></ul><ul><ul><li>Boundaries are explicit </li></ul></ul><ul><ul><li>Services are autonomous </li></ul></ul><ul><ul><li>Services share schema and contract, not types </li></ul></ul><ul><ul><li>Compatibility/Behavior is based upon policy </li></ul></ul>
    13. 14. When Are Contracts important? <ul><li>When crossing boundaries </li></ul><ul><ul><li>You have to define ‚boundary‘ </li></ul></ul>System SubSystem1 SubSystem2 External Services
    14. 15. What do Service Contracts define? <ul><li>What an application does, not how it is implemented </li></ul><ul><li>Contract needs to define all aspects of message exchange </li></ul><ul><ul><li>Data content (‘Schema’) </li></ul></ul><ul><ul><li>Sequencing rules, exchange patterns (‘Protocol’) </li></ul></ul><ul><ul><li>Other rules/behaviors (‘Policies’) </li></ul></ul>
    15. 16. It is all about Agreements <ul><li>Web Services exchange (XML) messages. Period. </li></ul><ul><li>Contract-First design & development </li></ul><ul><ul><li>The data/message and interface contract is what makes a stable and good communication between parties </li></ul></ul><ul><ul><ul><li>Explicit boundary </li></ul></ul></ul><ul><ul><ul><li>No exposure of objects and platform </li></ul></ul></ul><ul><ul><ul><li>Ensures interoperability (together with policies) </li></ul></ul></ul><ul><li>Two flavors of Contract-First Web Services design </li></ul><ul><ul><li>Code-based </li></ul></ul><ul><ul><li>Schema-based </li></ul></ul>
    16. 17. Schema-based Contract First - Phases 1 & 2 Modelling Data Modelling Messages XSD XSD XSD XSD XSD XSD XSD XSD
    17. 18. Schema-based Contract First - Phases 3, 4 & 5 Modelling Interface & Operations Generate Code C# Java VB AppleScript WSDL Iterate
    18. 19. Schema-based Approach <ul><li>Five simple yet effective steps </li></ul><ul><ul><li>Model your data </li></ul></ul><ul><ul><li>Model your messages </li></ul></ul><ul><ul><li>Model your interface </li></ul></ul><ul><ul><li>Generate code (platform and runtime specific) </li></ul></ul><ul><ul><li>Iterate contract design and code generation (inside your team/project!) </li></ul></ul>
    19. 20. Case: Dare2Date <ul><li>Datingservice </li></ul><ul><li>Used with </li></ul><ul><ul><li>SMS </li></ul></ul><ul><ul><li>Google or Yahoo Maps </li></ul></ul><ul><ul><li>Currency </li></ul></ul><ul><ul><li>Translation </li></ul></ul><ul><ul><li>Restaurants </li></ul></ul><ul><ul><li>News </li></ul></ul><ul><ul><li>Social Networks: Hyves, blogs </li></ul></ul><ul><ul><li>Flickr </li></ul></ul>
    20. 21. Dare2Date Processes
    21. 22. Dare2Date Partial Use Case Model
    22. 23. Dare2Date Activity Diagram for Use Case Apply Registration <ul><li>Different types of activities: </li></ul><ul><ul><li>Use cases </li></ul></ul><ul><ul><li>Forms </li></ul></ul><ul><li>Activities depend on each other </li></ul><ul><li>Activitydiagram implies state, not all use cases should be services! </li></ul>
    23. 24. Dare2Date High Level Sequence Diagram
    24. 25. Which Services? <ul><li>Services types: </li></ul><ul><ul><li>Process services </li></ul></ul><ul><ul><ul><li>Orchestration </li></ul></ul></ul><ul><ul><li>Business services </li></ul></ul><ul><ul><ul><li>Task centric </li></ul></ul></ul><ul><ul><ul><li>Entity centric </li></ul></ul></ul><ul><ul><li>Application services </li></ul></ul><ul><ul><ul><li>Utilities </li></ul></ul></ul><ul><ul><ul><li>Infrastructure </li></ul></ul></ul>Process services Business services Application services
    25. 26. Service Classification <ul><li>Apply Registration: RegistrationProcessing </li></ul><ul><ul><li>Process Service or Task Centric Business Service </li></ul></ul><ul><li>Insert Registration </li></ul><ul><ul><li>No service needed, manual step </li></ul></ul><ul><li>Validate Registration: RegistrationValidation </li></ul><ul><ul><li>Task or Entity Centric Business Service </li></ul></ul><ul><li>Insert Creditcard </li></ul><ul><ul><li>No service needed, manual step </li></ul></ul><ul><li>Validate Creditcard: CreditcardValidation </li></ul><ul><ul><li>External interface, therefore Application Service </li></ul></ul><ul><li>Confirm Registration: Email </li></ul><ul><ul><li>Application Service </li></ul></ul>
    26. 27. Service Level Sequence Diagram
    27. 28. Dare2Date: Communication with External Services
    28. 29. Resources <ul><li>Pragmatisch Modelleren met UML 2.0 Sander Hoogendoorn </li></ul><ul><li>Spring Web Services Documentation </li></ul>