component based development (CBD) with UML

The main focus of the course is to use CBD techniques to create kits of components, that can then be used to create families of applications. Software development is a team effort, and it is equally important that developers have a language for talking about analyses and designs: 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 CBD. We show how to use the UML notation most effectively both to discuss designs with colleagues, and in documents.

Duration: 5 days

objectives

use UML and OCL, as a common language for talking about requirements, designs, and component interfaces;
practice the main principles of CBD with UML;
know the major tasks required to develop component models, frameworks, and software; and
understand how to leverage reuse and adaptability from component-based development.

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 component development lifecycle.

fundamentals of Component Based Development (CBD)

An overview of the model-based approach to specifying enterprise components

business modelling: concepts and tasks
system requirements models
responsibilities and collaborations
persistence, GUI, distribution
coding in an OO language
component-based design (brief overview)
components and interfaces
components kits and architecture
component and reuse culture
patterns (brief overview)

business modelling and UML basics

This section covers techniques of identifying business concepts and tasks, and introduces relevant parts of UML along the way.

static models
objects, types, attributes, snapshots
subtypes
dynamics
use-cases and tasks
event charts
state charts
building a business model
finding use-cases
connecting use-case and class views
the Dictionary
UML Notation review
uses of business model
architecture of business process
context for software requirements
basis for component interface definition
documentation style

requirements modelling

This section deals with the specification of requirements of a software component, application, or complete system. More modelling patterns and techniques are investigated.

System context models
High-level operation specs
State charts for system models
Meaning of 'model'
How to start abstract and get more detailed
event charts: horizontal and vertical expansion
elaborating models
relating the levels of detail
building a system spec
system context
defining system use-case goals
modelling patterns

design patterns

In this section, the usefulness of design patterns as a way of thinking about and describing designs is investigated. Several patterns are discussed, and then a problem is presented which participants model and then sketch a solution for, using the patterns.

Two-way link
Observer
Recursive composite
State delegation
Interface decoupling

domain coupling

The linkage of the 'core(s)' to presentation, persistence, and other layers.

GUI: MVC and reification of use-cases in UI objects
Persistence: proxy
and building atop object and relational DBs
Networks: layering

component development process

This section reviews the tasks and deliverables involved in a typical CBD development project.

the main tasks and artefacts
business/conceptual modelling
specification/requirements modelling
architecture, design, and implementation
integration and testing
short-cycle development
spiral model
phased development
role of prototyping

frameworks: generic models

Partial models (views) as reusable artefacts.

generalization of two example static models
collaborations: generic designs for interactions
roles
synthesis of collaborations

reuse and adaptability

Reuse does not come automatically, and requires not only appropriate technology, but also management and motivation at the corporate level.

management and economics of reuse
component repositories
what's in the repository
components, frameworks, patterns, and plans

component technology

pluggable code and connector protocols
component kits and building tools
component architecture
common models
common couplings
wrapping existing assets
product vs component building

distributed systems

architectures
CORBA, DCOM
3 and N-tier
CORBA and IDL
defining interfaces in UML
distributed system building tools
patterns for distributed systems

re-engineering existing systems

business process and existing asset analysis
wrapping vs re-engineering
low-risk re-engineering path

process patterns

The UML notation gives us a way to describe business models, requirements, component interfaces, and designs at any level of detail. But what tasks and documents are there in a project? That depends on where you're starting from, and what you want to achieve. There is no one process that fits all. Instead, we will look at a basic set of process patterns — that is, patterns that help you plan a CBD project.

process patterns — introduction
project-level patterns:
- green field
- re-engineering
- short-cycle development
- small project
- large project
- critical systems
- systems integration, and
- component development
strategic patterns
- technology migration
- reuse
- re-architecture

timetable

Day 1	fundamentals of Component Based Development (CBD) business modelling and UML basics
Day 2	requirements modelling design patterns domain coupling
Day 3	component development process frameworks: generic models reuse and adaptability
Day 4	component technology distributed systems re-engineering existing systems process patterns
Day 5	workshop to put CBD with UML theory into practice on a realistic case study

course exercises

It is a pencil-and-paper course, with group exercises. We can demonstrate a variety of support tools (such as Rose, Select, or Rhapsody). 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.

course instructor

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