• Save
Contract First Modeling Services Using Uml
Upcoming SlideShare
Loading in...5
×
 

Contract First Modeling Services Using Uml

on

  • 2,266 views

Presentation given in the minor EAD at ICA, HAN University

Presentation given in the minor EAD at ICA, HAN University

Statistics

Views

Total Views
2,266
Views on SlideShare
2,260
Embed Views
6

Actions

Likes
0
Downloads
0
Comments
0

2 Embeds 6

http://www.linkedin.com 4
https://www.linkedin.com 2

Accessibility

Categories

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Contract First Modeling Services Using Uml Contract First Modeling Services Using Uml Presentation Transcript

  • Contract first modeling Services using UML Minor Enterprise Application Development
  •  
  • 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 View slide
  • Use Cases http://wiki.trinidadplatform.org Merge Companies Merge Mortgage Systems Place Order Select Product Insert Orderline View slide
  • Why Smart Use Cases
    • 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
  • Example Smart Use Cases
  • Cookbook
    • Define the main 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.
  • Why Contract First
    • Two 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”
  • Object XML Mismatch
    • XSD Extensions
    • Unportable Types
    • Cyclic Graphs
    • <simpleType name=&quot;AirportCode&quot;>
    • <restriction base=&quot;string&quot;>
    • <pattern value=&quot;[A-Z][A-Z][A-Z]&quot;/>
    • </restriction>
    • </simpleType>
  • Object XML Mismatch
    • XSD Extensions
    • Unportable Types
    • Cyclic Graphs
    • public Map getFlights()
    • {
    • TreeMap map =
    • new TreeMap(); map.put(&quot;KL1117&quot;,
    • &quot;Stockholm&quot;);
    • return map;
    • }
  • Object XML Mismatch
    • XSD Extensions
    • Unportable Types
    • Cyclic Graphs
    • public class Flight {
    • private String number;
    • private List<Passenger> passengers;
    • }
    • public class Passenger {
    • private String name;
    • private Flight flight;
    • }
  • Contract Last
    • Fragility
      • no 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
  • 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
  • When Are Contracts important?
    • When crossing boundaries
      • You have to define ‚boundary‘
    System SubSystem1 SubSystem2 External Services
  • What do Service Contracts 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’)
  • It is all about 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
  • Schema-based Contract First - Phases 1 & 2 Modelling Data Modelling Messages XSD XSD XSD XSD XSD XSD XSD XSD
  • Schema-based Contract First - Phases 3, 4 & 5 Modelling Interface & Operations Generate Code C# Java VB AppleScript WSDL Iterate
  • Schema-based Approach
    • Five simple 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!)
  • Case: Dare2Date
    • Datingservice
    • Used with
      • SMS
      • Google or Yahoo Maps
      • Currency
      • Translation
      • Restaurants
      • News
      • Social Networks: Hyves, blogs
      • Flickr
  • Dare2Date Processes
  • Dare2Date Partial Use Case Model
  • Dare2Date Activity Diagram for 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!
  • Dare2Date High Level Sequence Diagram
  • Which Services?
    • Services types:
      • Process services
        • Orchestration
      • Business services
        • Task centric
        • Entity centric
      • Application services
        • Utilities
        • Infrastructure
    Process services Business services Application services
  • Service Classification
    • Apply Registration: 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
  • Service Level Sequence Diagram
  • Dare2Date: Communication with External Services
  • Resources
    • Pragmatisch Modelleren met UML 2.0 Sander Hoogendoorn
    • Spring Web Services Documentation