UML and Service Oriented Architecture

The course shows how systems based on service oriented architecture can be specified, designed and built. The course uses BPMN and UML as the documentation tools to capture the specifications, architecture and design and demonstrates how services can be identified, and applications built based on those services. The course considers a variety of architecture styles including both orchestration and messaging.

Duration: 5 days

objectives

  • Acquire a knowledge of BPMN, a graphical language for capturing the steps in a business process;
  • acquire a knowledge of UML, a common language for talking about requirements, designs, services, and components;
  • show how both BPMN and UML can be integrated as a powerful tool for identifying services and their collaborations;
  • understand what major tasks are appropriate to producing models of services, and developing software from those models;
  • understand the issues and options in identifying, specifying and implementing services;
  • understand the issues involved in wrapping legacy systems to act as services;
  • understand the different styles and options of service oriented architectures; and
  • gain enough competence in service oriented architecture, analysis and design to tackle a complete project.

target audience

The course is suitable for analysts and designers wishing to develop clear precise methods of discussing requirements and designs at a high level, clear of implementation detail; and managers and architects wishing to understand the strategic issues in migrating to, and getting the best out of, an object-oriented development lifecycle.

course philosophy

UML and BPMN are notations that are used for capturing models that describe things in the real world and things in software. The notation is mainly pictorial and is straightforward to learn. However, not all of the notation is useful in every-day use — about 50% of the notation will cover 90% of its application area. We teach this useful core, and indicate how the remainder of the notation can be used. We also concentrate on how the language can be used as a modelling tool, rather on what the language is. As with learning a foreign language, just learning the vocabulary and a few simple sentences is not enough, you need to learn both how to speak and use the language. The courses look at how UML and BPMN can be used as an expressive tool to describe the business and its software specifications, architecture, and both the high and low-level design of the software.

The course concentrates on:

  • abstraction, a tool for problem understanding;
  • how to use BPMN and UML to model the system to identify services;
  • how to convert the system model into a working system;
  • services: develop, wrap legacy, or buy;
  • different styles of service oriented architecture;
  • how to use UML to investigate architectural and design issues; and
  • how to express service oriented architecture and designs in UML.

Description

The major thrust in modern software development today is building software applications based on services. The choice of services, and the distribution of tasks between the services, is of crucial importance. Services provide a powerful tool for building flexible and extensible software systems; service-based architecture provides the means of constructing such systems quickly and flexibly. The major problem in this approach is the identification of services and packaging the services for use.

Software development is a team effort, and it is equally important that developers have a language for talking about the system, its design and implementation: a language that is less ambiguous than English, but able to deal in requirements and high level design without being cluttered by the fine detail of program code.

This course separates and makes explicit the decisions that make up the analysis and design. We show how to use the UML and BPMN notation most effectively both to discuss designs with colleagues, and in documents.  both UML and BPMN are now industry standard, supported by all the major tools.  The course provides especially strong coherence between the different notations used, making it clear when there are inconsistencies or holes in the analysis. This saves a lot of money in the later stages of a project.

prerequisites

Some knowledge of an OO language (such as C#, C++, Java, and Smalltalk) is an advantage.

Introduction

An introduction to UML and SOA

This chapter outlines the philosophy of a development process geared to service oriented architecture, and provides a brief history of UML.

  • Why component technology?
    • the problems of a traditional approach
    • some solutions
  • Component Based Development
    • components for agility
    • components for reuse
  • Service Oriented Architecture
    • services for agility
    • changing the way business is done
  • What is a software development process?
    • business modelling: concepts and tasks
    • system requirements models
  • The background to UML
    • a model-based approach to developing enterprise components
    • history and background to UML and Catalysis
  • Resources and references

Analysis

The basics of modelling

The purpose of this chapter is to

  • introduce the concept of a model;
  • show how UML and BPMN can be used to capture a model;
  • show how the model of the real world and the real world are "syncronised"; and
  • illustrate and discuss some of the issues of abstraction.

This chapter will introduce the concept of a model, how abstraction is used, and how a model is captured using UML and BPMN. The emphasis is on understanding the modelling process with the goal of identifying the business services.

  • The basic ideas
    • UML as a modelling tool
    • the model and the real world
    • using abstraction
    • the model and the software
    • why Object Oriented models
    • keeping them accurate
    • individuals and relationships
  • Modelling
    • things of interest in the world and in our model
    • designations — specifying what we are modelling
    • abstraction — modelling the things of interest
    • different points of view
  • The fundamental modelling tools
    • modelling things that are: entities
    • modelling things that happen: business processes
    • the model and the real world
    • remembering the past (histories) and planning the future (futures)

At the end of the session, the attendee should be able to

  • understand the concept of a services model;
  • understand how UML and BPMN can be used as a modelling tool; and
  • construct a simple model using UML and BPMN diagrams;

BPMN: the basics

The purpose of this chapter is to

  • introduce the basic ideas of BPMN;
  • show how BPMN can be used to model business processes; and
  • discuss some of the issues of process modelling.
  • business activities
    • things of interest in the world and in our model
    • specifying what we are modelling — business activities
    • business sub-processes
    • abstraction — modelling at the right level of detail
  • the concept of the real user
    • the goals of the real user
    • getting down to atomic activities (and no further)
    • different points of view
  • events
    • activities and events
    • histories and futures
    • remembering the history and causing the future
  • process modelling and data
    • what is in a message
    • linking the activities and information

At the end of the session, the attendee should be able to

  • construct a simple model using BPMN;
  • illustrate a simple scenario of a business process with a series of snapshots; and
  • relate a snapshot to the corresponding type and business process models.

UML: the basics

In this chapter, the UML notations that are used for modelling are introduced. It is here that the basic vocabulary of UML is introduced.

  • Using UML Types
    • objects, types, attributes
    • static models
    • snapshots (instance diagrams)
  • Use cases and business services
    • the context
    • identifying services
    • specifying goals
    • snapshots & filmstrips
    • processes
  • More diagrams and meanings
    • subtypes
    • aggregates
    • stereotypes
  • Documenting what happens to things
    • statecharts: the notation
    • connecting the dynamic and static views
    • use cases and states
    • objects and roles
  • Documenting when things happen
    • activity diagrams: the notation
    • concurrent activities
    • different people do different things
  • The importance of readable documents
    • diagrams and dictionaries
    • documentation style
  • UML notation review

At the end of the session the attendee should know the basic UML notation for:

  • class (type) diagrams
  • object diagrams
  • activity diagrams
  • use case diagrams
  • state machine diagrams

Techniques — how to constructing a model

This chapter is looks at various ways to construct a model and how to check it for consistency and completeness. Here we are looking at requirements capture and modelling.

  • Roles, actions, and objects: who’s involved, what are their goals?
    • understanding the business
    • who does what
    • finding business processes
  • Identifying services — stories: how do they achieve their goals?
  • Snapshots and filmstrips: seeing the changes that are affected by a business process
    • understanding the business process
    • who and what are involved
    • have we understood the process
  • Specifying the use cases
    • searching for services
    • capturing the business processes
    • snapshots revisited
  • Refining the use cases: zooming in and out
    • getting the right level for services
    • too little vs too much
  • the life history of processes and objects
    • avoiding the £0.0 invoice problem
    • does it all fit together
    • have we modelled everything
  • Composing models: from different viewpoints

At the end of the session, the attendee should know how to start the construction of a simple model using UML by identifying and telling suitable "stories" about the business, illustrate those stories with snapshots and from them derive a basic type model and process model.

Packaging the model

This chapter considers the problem of how to break a model into UML packages, each of which covers part of the business. The packages will help to identify services, and components for implementation. Each package is a model of part of the business, a possible service, and is decoupled as much as possible from the other the other packages that make up the system.

  • Packaging
    • packaging the model
    • presentation vs implementation
  • Application architecture
    • the big picture
    • processes, concepts, and entities
  • Finding components
    • business entities
    • business processes and services
  • Identifying packages
  • Packaging the business entities
    • things that are
  • Packaging the business processes
    • things that happen
  • Decoupling packages
  • What’s in a package
  • Roles and reuse

At the end of the session, the attendee should know how to package a domain model in a way suitable for a clear understanding of the models. They should also understand how the packaging is a jumping off point for identifying components.

Business rules

This chapter looks at the need for, and the capture of, business rules. Ignoring business rules is a major source of errors in a system; these are the errors are usually found during system use and are the most expensive to fix.

  • The need for business rules
    • the world is not perfect
    • this is the way our business works
  • Identifying business rules
    • capturing the rules of the game
    • static rules
    • dynamic rules
    • business rules and services

At the end of the session, the attendee should know why there is a need for business rules, how they may be identified and captured. The attendee will also understand the possibility of using OCL to capture those business rules.

System specification

This chapter looks at how to interpret the services model as a system model and illustrates how the system can be specified as a set of interfaces that describe the services to be provided by the system. The main emphasis is on interfaces and specification of those interfaces by contract. The interfaces are about the business, not about the system implementation. The interfaces are aimed at a service based architectural style.

  • Application architecture
    • separating the business core from the GUI, persistence, and other layers
  • Scoping and elaborating
    • system context
    • system context models
    • building a system specification
    • iterative development?
  • Interfaces
    • defining interfaces
    • the syntax and semantics of an interface
  • Specifying the system — using the domain model
    • adding parameters
    • specifying system behaviour
    • high-level operation specs

At the end of the session, the attendee should know how to convert a domain model into a specification model. They should understand the concept of scoping, understanding the idea of a system model and how it should be synchronized with the real world.

Specifying the interface tier

This short chapter looks at the specification and design of the “client” side of a system — what the user sees.

  • Users of the system (actors) as concepts
    • user interfaces as objects
    • interfaces revisited
  • Specifying information
    • describing input and output using UML

At the end of the session, the attendee should know techniques for specifying the interface layer. They should also understand that a service based system is independent of the users.

The model building process

The chapter is concerned with discussing the management and organizational aspects of building models from a lightweight, iterative development point of view.

  • Modelling: concepts and tasks
  • The need for a services model
    • what is a services model
    • services are about the business, not about the system
    • a context for software requirements
    • deliverables — what’s in the services model
  • Process — what to do and when
  • Strategies — who constructs the model
    • building a services model
    • uses of the services model

At the end of the session, the attendee should know the advantages and disadvantages of using a light-weight, agile, development process. They will also know how to develop models using a co-operative approach.

Architecture and Design

Service Oriented Architecture

This section looks at the ideas behind service architecture and looks at the issues involved in producing service kits for constructing software.

  • Services
    • towards a definition
  • Service architectures?
    • the ideas behind services
    • what we need
  • Communication
    • exchanging information
    • towards a common language
  • The infrastructure
    • “platforms and pipes”
    • services and infrastructure
  • Architectural issues
    • pulling the ideas together
    • example technical architectures
  • Architectures
    • architectural styles

An interlude, some UML for design

  • Designing collaborations — a time-line approach
    • sequence diagrams — the notation
    • using sequence diagrams for discovering collaborations
    • almost a pseudo code?
    • advantages and disadvantages of this approach
  • Designing collaborations — collaborating objects
    • communication diagrams — the notation
    • objects and their links
    • objects and their collaborations
    • advantages and disadvantages of this approach

Service collaboration — a coordinated approach

The section looks at a technology-free coordinator approach to service collaboration. It covers the main aspects of serice specification and design. The architectural style is shows how a stateless coordinator can be built and is particularly suited to an ESB technology.

  • Coordinating services
  • Coordinators as an OO concept
    • where do the business rules go?
    • layers and dependencies
  • Using coordinators
    • service collaborations
    • services and interfaces
    • collaborations and business rules
    • completing interfaces
    • service specifications
  • Specifying the interfaces
    • using the system model
    • changing operations

At the end of the session, the attendee should know how to bundle interfaces (packages) together to form services that reflect the needs of the business; and know how to discover the collaborations that are necessary to support the services defined by the specification model.

Self-contained services

There are many architectural choices that can be made when building a system from services. This section looks at the various styles of collaborations between services and discusses the various styles of architecture and trade-offs that can be made. This section looks in detail at business service that manage their own business rules.

  • Alternative service architectures
  • Decoupling roles and services
    • sharing information between services
    • synchronising information
    • where do the actions and rules go?
  • Sharing across services
    • sharing information: a variety of styles
    • synchronising invariants
    • connecting services together
    • decoupling the services
  • Transformations for sharing
  • using roles
  • Designing the services
    • mixing approaches
    • tradeoffs

Agile services

This section looks in detail at business service that do not manage their own business rules allowing for more agility when changing business processes.

  • Alternative service architectures
  • Decoupling rules, roles and services
    • synchronising information
    • where do the actions and rules go?
  • Sharing across services
    • sharing information: a variety of styles
    • synchronising invariants
    • connecting services together
    • decoupling the services
  • Transformations for sharing
  • Using roles
  • Designing the services
    • mixing approaches
    • tradeoffs

Enterprise Integration Patterns — the basics

  • Integrating services
  • Messaging
    • messages
    • channels
    • endpoints
  • Patterns
    • the philosophy &mdash loose coupling
    • message construction
    • routing
    • message transformation

Designing the presentation tier

  • Specifying the information
    • storyboards
    • designing dialogues: what vs how
    • using UML as a design tool
    • the user and the system views
  • Forms
    • what vs how
    • leaving the design to last

Implementation

Component design — building the system with a coordinator

From specification to code — this section looks at how code can be derived from a specification and looks at the choices that are available. It provides an overview of the tasks that need to be done and provides a framework for implementing components using a coordinator approach — an approach suitable for J2EE, .Net and Orchestration in an SOA environment.

  • technical architecture
    • layering
    • distributed systems
    • stateless vs statefull
    • a typical application
  • some architectural issues
    • fine vs course granularity
    • types vs entities
  • From design to code (overview)
    • the specification
    • snapshots
    • deriving the code
  • Implementing the different architectures
    • finding the interfaces
    • sharing objects

At the end of the session, the attendee should understand the various options available to a programmer and have some understanding on how working code can be derived from a component specification.

Implementing the presentation tier

This chapter looks at the specification and high level design of the “client” side of a system — what the user sees.

  • Components in the presentation layers
    • GUI: MVC
    • the linkage of the 'core(s)' to the presentation layers
    • reification of use-cases in UI objects
  • Interface layer
    • from the user to the system
    • translating and checking

At the end of the session, the attendee know how UML can be used to express a high-level design for a user interface that could be implemented by one of the standard technologies.

Review

A review of the technical process

The following chapter is a review of the technical material covered in the course. It is tailored to the course it is used in. The chapter reviews component based development in the Catalysis style.

  • Business (conceptual) modelling
    • building a business model
  • System (requirements) modelling
    • defining the system
  • Application (architectural) modelling
    • finding the components and connectors
  • Design modelling
    • working out how things work
  • Implementation
    • writing the code
  • Architecture & patterns
    • encapsulating knowledge
  • The whole picture

The end

At the end of the session, the attendee should be able to construct a simple model using UML type diagrams and state machine diagrams.

  • A quick review of the ideas and concepts

course exercises

Each section of the course uses numerous small examples and exercises. Two major examples are followed through the course: one discussed in class as each point is introduced, and one developed by participants in groups. Depending on the background of the participants, the exercises can be chosen from commercial or process control areas, and can be based on one of your own projects. This is a pencil-and-paper course, with group exercises. We can demonstrate a variety of support tools (such as Enterprise Architect). However, we do not recommend using tools for the exercises, as the details of driving them distracts from the main issues of the language and techniques; and they do not promote team working in the class. At the detailed design level, we will use sketch examples in a pseudo code that can easily be translated into Java, C#, or VB-.net.

follow-up

This course is part of a package, including mentoring, aimed at providing a low-risk migration towards model-based analysis and design for service-based systems.

We will tailor the content of the course to suit your needs; for example, we can change the emphasis to an architectureal style that uses orchestration as the means to coordinate the services that make up an application. We can also tailor the content to an architectural style that uses asynchronous messages to coordinate services; this version looks at the various patterns that can be applied, and considers how an ESB can be used as a technology to support this architectural style.

course instructor

The course is presented by one of our senior consultants, each of whom has had at least ten years experience in object oriented software development, and at least three years' experience as a trainer and consultant in a diverse range of application areas.

print     printer-friendly version