object-oriented analysis and design (OOAD) with UML
course overview
Object oriented programming languages provide a powerful tool for building flexible and extensible software components. However, maximum benefits are gained only if the software is appropriately designed. The choice of classes, and the distribution of tasks between the objects, is of crucial importance. 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 is part of a package including mentoring, aimed at making a low-risk migration towards UML-based analysis and design. We tailor the content to suit your needs.
This course separates and makes explicit the decisions that make up an OO analysis and design. We show how to use the UML notation most effectively both to discuss designs with colleagues, and in documents. UML is now an industry standard, supported by all the major tools. The course provides especially strong coherence between the different notations used in UML, 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.
Duration: 5 days
objectives
- gain enough competence in object-oriented analysis and design (OOAD) to tackle a complete OO project;
- acquire UML, a common language for talking about requirements, designs, and component interfaces;
- understand the main principles of good OO design;
- understand what major tasks are appropriate to developing OO models and software; and
- understand the issues and options in reuse and 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 object-oriented development lifecycle.
prerequisites
Some knowledge of an OO language (such as C++, Java, Smalltalk, Eiffel) is an advantage.
course syllabus
[B] — Basic material for participants whose familiarity with analysis and design is limited.
[D] — Design issues, rather than modelling, specification, or analysis: can be de-emphasized.
[A] — Additional topic (can be omitted).
[S] — Strategic issues particularly of interest to senior designers and management.
Object Oriented programming [B]
Introducing the principles of OO design.
- aims of OO design
- OO designs are based on the 'real' world
- what's an object?
- distribution of responsibilities
- objects, classes, messages and methods
- decoupling for flexible software
- interfaces and the 'implements' relation
- types and object specifications
- class extension
OO analysis and design
Aims and overview of process.
- layering design decisions: abstraction
- exposing gaps and inconsistencies: precision
- traceable designs: continuity
- clear, ready communication: a language for design
- a vanilla process: development from scratch (brief overview)
- business modelling: concepts and tasks
- system requirements models
- responsibilities and collaborations
- persistence, GUI, distribution
- coding in an OO language
- component-based design (brief overview)
- robust, flexible software
- 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
basic design
The key principle of OO design is assigning responsibilities and designing collaborations.
- separating core from GUI, persistence, and other layers
- selection of control objects
- designing system operations with messages
- decoupling, extensibility, reusability
- CRC 'cards'
- dependencies and visibilities
- the class dictionary
- translation to code [Java, C++, or Smalltalk examples]
basic design patterns [D]
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 [D]
The linkage of the 'core(s)' to presentation, persistence, and other layers.
- GUIs
- reification of use-cases in UI objects
- persistence and proxies
- building atop object and relational DBs
- networks and layering
development: fundamental tasks
This section reviews the tasks and deliverables involved in a typical object-oriented development project.
- the main tasks and artefacts
- business/conceptual modelling
- specification/requirements modelling
- architecture
- design and implementation
- integration and test
- short-cycle development
- spiral model
- phased development
- role of prototyping
Standard design patterns [D] [A]
More patterns, based on texts by Gamma et al, Coplien, Pree, and the PLoP workshops.
frameworks: generic models [A]
Partial models (views) as reusable artefacts.
- generalization of two example static models
- collaborations: generic designs for interactions [OORAM]
- roles
- synthesis of collaborations
re-use and Component-based development [S]
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, plans, ...
components — the technology [A]
- pluggable code and connector protocols
- component kits, Beans; building tools
- component architecture
- common models
- common couplings
- wrapping existing assets
- product vs component building
distributed systems [A] [see also "Components"]
- architectures
- CORBA, DCOM, J2EE
- 3- and n-tier
- distributed system building tools
- patterns for distributed systems
re-engineering existing systems [A]
- defining interfaces in UML
- re-engineering existing systems [A]
- business process and existing asset analysis
- wrapping vs re-engineering
- low-risk re-engineering path
Please note, when taught at your site, this course is customizable. Modules can be adapted, removed, added from other courses, or even created.
further information
timetable
|
Day 1 |
|
|
Day 2 |
|
|
Day 3 |
|
|
Day 4 |
|
|
Day 5 |
course exercises
Each section 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. This 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. At the detailed design level, we will use examples in Java, C++, or another language of your choice. The course is presented by one of our senior consultants, each of whom has 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.
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 analysis, design and software development, and at least three years' experience as a trainer and consultant in a diverse range of application areas.