component based development (CBD) with UML
course overview
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.
course syllabus
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
further information
timetable
|
Day 1 |
|
|
Day 2 |
|
|
Day 3 |
|
|
Day 4 |
|
|
Day 5 |
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.