![Object XML Mismatch XSD Extensions Unportable Types Cyclic Graphs <simpleType name="AirportCode"> <restriction base="string"> <pattern value="[A-Z][A-Z][A-Z]"/> </restriction> </simpleType>](https://image.slidesharecdn.com/ContractfirstmodelingServicesusingUML-122763990521-phpapp01/75/Contract-First-Modeling-Services-Using-Uml-9-2048.jpg)
Uploaded byRody Middelkoop
Contract First Modeling Services Using Uml
The document discusses modeling services for a minor enterprise application called Contract first modeling Services using UML. It provides an overview of the contract-first modeling approach, including modeling business processes as use cases and technical services, and then generating interfaces and code from these models. The key benefits of the contract-first approach are that the contract remains stable over time and allows for loose coupling between interfaces and implementations.
Contract First Modeling Services Using Uml
- 1. Contract first modelingServices using UML Minor Enterprise Application Development
- 2.
- 3. Validating the approach“… 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.” Wouter Goedvriend, CapGemini http://wiki.trinidadplatform.org/forum/Default.aspx?g=posts&t=8
- 4. Use Cases http://wiki.trinidadplatform.org Merge Companies Merge Mortgage Systems Place Order Select Product Insert Orderline
- 5. Why Smart UseCases Modeled early in projects Low effort Visual representation Single level of complexity Similar granularity Good unit of work in iterative projects Can be based on most functional requirements specifications, business processes or existing applications Technology independent Reproducible Repeatable
- 6. Example Smart UseCases
- 7. Cookbook Define themain processes in the company starting with the name of the company as the root Refine the processes to EBPs, which resemble sea level use cases Use smart use cases to define services and find out relations and possibilities for re-use Use activitydiagrams for complex relationships like choices and flows Use sequence diagrams to define operations and interfaces of the services. Redefine operations using XSD. Separate classes and interface through classdiagrams, define public and private operations.
- 8. Why Contract FirstTwo approaches Contract first 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”
- 9. Object XML MismatchXSD Extensions Unportable Types Cyclic Graphs <simpleType name="AirportCode"> <restriction base="string"> <pattern value="[A-Z][A-Z][A-Z]"/> </restriction> </simpleType>
- 10. Object XML MismatchXSD Extensions Unportable Types Cyclic Graphs public Map getFlights() { TreeMap map = new TreeMap(); map.put("KL1117", "Stockholm"); return map; }
- 11. Object XML MismatchXSD Extensions Unportable Types Cyclic Graphs public class Flight { private String number; private List<Passenger> passengers; } public class Passenger { private String name; private Flight flight; }
- 12. Contract Last Fragilityno guarantee that the contract stays constant over time not all SOAP stacks generate the same web service contract from a Java contract Performance there is no way to be sure as to what is sent across the wire Reusability defining your schema in a separate file allows you to reuse that file in different scenarios Versioning if using contract-first, we can have a looser coupling between contract and implementation
- 13. Messages and Services,not Method Calls and Objects No, no, no – not (just) XML-based RPC Tools imply this, though… Abstractions & decoupling Factors for successful and evolvable applications & architectures Service-oriented principles Boundaries are explicit Services are autonomous Services share schema and contract, not types Compatibility/Behavior is based upon policy
- 14. When Are Contractsimportant? When crossing boundaries You have to define ‚boundary‘ System SubSystem1 SubSystem2 External Services
- 15. What do ServiceContracts define? What an application does, not how it is implemented Contract needs to define all aspects of message exchange Data content (‘Schema’) Sequencing rules, exchange patterns (‘Protocol’) Other rules/behaviors (‘Policies’)
- 16. It is allabout Agreements Web Services exchange (XML) messages. Period. Contract-First design & development The data/message and interface contract is what makes a stable and good communication between parties Explicit boundary No exposure of objects and platform Ensures interoperability (together with policies) Two flavors of Contract-First Web Services design Code-based Schema-based
- 17. Schema-based Contract First- Phases 1 & 2 Modelling Data Modelling Messages XSD XSD XSD XSD XSD XSD XSD XSD
- 18. Schema-based Contract First- Phases 3, 4 & 5 Modelling Interface & Operations Generate Code C# Java VB AppleScript WSDL Iterate
- 19. Schema-based Approach Fivesimple yet effective steps Model your data Model your messages Model your interface Generate code (platform and runtime specific) Iterate contract design and code generation (inside your team/project!)
- 20. Case: Dare2Date Datingservice Used with SMS Google or Yahoo Maps Currency Translation Restaurants News Social Networks: Hyves, blogs Flickr
- 21.
- 22. Dare2Date Partial UseCase Model
- 23. Dare2Date Activity Diagramfor Use Case Apply Registration Different types of activities: Use cases Forms Activities depend on each other Activitydiagram implies state, not all use cases should be services!
- 24. Dare2Date High LevelSequence Diagram
- 25. Which Services? Servicestypes: Process services Orchestration Business services Task centric Entity centric Application services Utilities Infrastructure Process services Business services Application services
- 26. Service Classification ApplyRegistration: RegistrationProcessing Process Service or Task Centric Business Service Insert Registration No service needed, manual step Validate Registration: RegistrationValidation Task or Entity Centric Business Service Insert Creditcard No service needed, manual step Validate Creditcard: CreditcardValidation External interface, therefore Application Service Confirm Registration: Email Application Service
- 27. Service Level SequenceDiagram
- 28. Dare2Date: Communication withExternal Services
- 29. Resources Pragmatisch Modellerenmet UML 2.0 Sander Hoogendoorn Spring Web Services Documentation