Training Courses in the UK and Europe

Modular Training for Object-Oriented Analysis, Design and Programming

This set of modules allows an organization to decide exactly how specific it wishes its training to be, and to tailor a course, or set of courses, that suit its needs exactly. It is from these modules that the two most popular courses - Object-Oriented Analysis and Design with UML and the Hands-On Design and Programming ... - are constructed.

• Aims
• Background
• Audience
• Duration and Construction
• Delivery
• Content

Aims

The aims have been ordered such that the most specific aims come last. An organization that didn't take a language module, for example, wouldn't be immediately interested in the final aim.

• To understand the nature of object technology, what it offers and what must be done to make the most of it;
• To describe how to structure and carry out the early phases of a development in a cost-effective and insightful way;
• To clearly show what we should, and should not, expect requirements capture, analysis and design to achieve for us, and to clearly differentiate these activities;
• To identify exactly which aspects of object-oriented analysis can benefit from its database beginnings, and which aspects require us to think afresh;
• To ensure that each activity has a realistic expectation of success, and an identifiable and understood payoff;
• To clearly describe the nature and needs of good objects, and how they are satisfied via "outside-in design" where messages lead us, via object types, to appropriate interfaces, abstract classes and concrete classes; and to avoid "inside-out", class-oriented and naive design;
• To understand the available object-oriented languages and the nature of object-oriented programming;
• To understand the UML, particularly how to tame it, how to get the best that it offers without getting mired in its enormous detail;
• To ensure that the expected benefits of each aspect of typical object technologies, especially inheritance, are put into context against their potential drawbacks;
• To understand a chosen language (typically Smalltalk, Java, C++ or C#) both from the point of view of how to program in the chosen language and from the point of view of ensuring good object-oriented design practices are not forgotten (particularly in C++);

Background

Even though object-orientation began in 1967, many projects today find themselves in the process of adopting object technology. There are certain fundamental shifts of perception and practice that are essential to take on board, if the benefits of object technology are to be realized.

The core of our object-oriented course set is formed from five main modules:

• The nature and origins of object technology (1 unit)
• Object-oriented analysis and design (5 units)
• UML details (1.5 or 2.0) (2 units)
• Object-oriented programming themes and illustrations (1 unit)
• Object-oriented programming language (Java, C#, C++ or Smalltalk) (6 units)

  where a unit represents approximately half a day.

The object-oriented analysis and design module uses the UML - it is necessary to have some diagrams and it makes sense to use this, now universal, standard - but its emphasis is on good analysis and design practices that have been optimized to make the best of object technology.

The UML module adds the details of the notation for those who wish to learn them at the same time.

The object-oriented programming themes module introduces and compares the typical object-oriented programming languages, and introduces the programming concepts that object-orientation adds to the programming skill set. (A first time programmer's introduction to object-oriented programming would require a separate course.)

An organization, for example, that had not established its exact process yet, and had not finalized its choice of language could take the object technology, the UML-light object-oriented analysis and design and the object-oriented programming illustration modules. An organization that had made its choices and that wanted a complete set of training courses would take all the modules, probably in the form of the two courses mentioned at the beginning of this document, and probably separated by four or five weeks of reflection and practice.

Following on from this core it is possible, of course, to proceed to increasingly specific training such as Enterprise Java, the .NET architecture or C++'s STL, for example.

Audience

Courses formed from these modules will typically be of interest to anyone involved in the development of software-intensive systems - from the analysts and designers producing models and specifications, to the developers who work from them. They will also benefit those who wish to learn a sensible and pragmatic use of the UML (2.0 or 1.x), and those wanting to better understand the nature and successful deployment of object technology.

Courses can also be constructed that are suitable for groups who have not yet learned their object technology, where they establish what we expect of object technology, as well as for groups who have already covered the technology, where they show how we must plan for a sensible use of the technology.

Duration and Construction

Course days are typically from 0900 to 1630 and delivery is via lecture, case-study or practical, and discussion. The case-study and practicals are significant and realistic ones. Start, end and break times can be tailored to suit individual sites.

Delivery

Courses are normally delivered at the customer site.

The course deliverables comprise:

• lectures and a copy of the lecture notes;
• case study exercises and sample solutions;
• practical exercises and sample solutions;
• help with, and feedback on, the exercises;
• leading and moderating of discussion, questions and answers;
• reference and resource lists;
• an appendix to the notes of C++ aphorisms;
• an appendix to the notes of C++ traps and pitfalls;

Content

Objects and Object Technology

In order to understand the reason for several important debates and their outcome, it is necessary to understand the intended implementation technology. For some groups this unit will be an introduction; and for other groups it will be revision and agreement as to terminology.

Object-Oriented Analysis and Design

The process

It is here that several important themes are first introduced. Distinctions are made between the activities of requirements capture and elicitation, of analysis, and of design. The thinking behind agile processes and eXtreme Programming are explained and put into context. Model-driven development is explained and the phases of this approach are introduced.

Packaging and presentation

In anything but the smallest software development effort, it's necessary to organize the large number of artifacts that will be produced. In this session we introduce the package as it is known in the UML, and in Java. We also introduce the various offerings of the UML and the likely appropriateness of each offering for typical object technology projects.

Analysis inputs

Although requirements capture and elicitation are big subjects, and deserving of dedicated courses in their own right, it is important that analysts understand what to expect of this important input; and, of course, in this imperfect world, developers must often wade in and participate in requirements activities. We must, therefore, at least introduce the capturing and documenting of good and correct requirements. We must also continue with a theme introduced earlier - that terminology is very varied and muddled. It is essential to explain why this course holds requirements capture to be an activity that is carried out differently, and with different aims, to the analysis activity, and yet why other books and courses may use the terms differently.

Analysis I

The model begins with the search for subject matter objects, which is a reasonable way to model subject matters anyway; and, of course, an eminently sensible beginning of a model that will ultimately evolve into an object technological model. We then go on to characterize these early object ideas with their attributes and their characterizing relationships (the association and aggregation relationships of the UML). We also explain why action or operation modelling is not completed at this stage, but during the next.

Activity diagrams

For some developments, a significant start must be made on action or operation modelling - for example when a group is involved with business systems analysis, as well as with the analysis of the subject matter of a computer system under development. UML activity diagrams could therefore be important. However, the nature of activity diagrams brings great dangers for object-oriented developments, and a careful and insightful understanding use is essential.

Analysis II

The first analysis session described a model beginning that is usually beneficial to all developers, and is a reasonably straightforward one. Traditional approaches to OOA, and the UML, have presented us with further modelling possibilities, however. One of the most difficult to understand, and to use correctly - getting benefit without getting into enormous trouble or wasting inordinate amounts of time - is the state machine. Another one that is much less problematic but still capable of leading one astray or into time-wasting backwaters, is generalization. This second analysis session looks at both generalization and state machines. One of the main difficulties, common to both, is that they are often presented as though they can each be used with a single interpretation that will serve both in analysis and in design. An important distinguishing feature of this approach, however, is that there are important and subtle differences of usefulness and interpretation from phase to phase.

Systems Analysis

We continue with another theme that was begun earlier. Systems analysis isn't always the obvious beginning that it used to be in the days of computerization. Frequently today, there is no system to analyze; or if there is, it is already a computer system the analysis of which will almost certainly be somewhere between highly challenging and impossible. We began, therefore, with subject matter analysis. However, there certainly will be times when an existing system can be analyzed, and this session looks at how.

Object types and the transition to design

There are several more traps for the unwary that we will be learning how to avoid in this session. The first one is imagining that the analysis model denizens give direct input as to object classes; they don't; they tell us about object types - types of object instances. It's a subtle distinction but it's very, very important. Only when we've understood the kinds of object instances that are needed will we have the evidence to decide how to make those instances with concrete classes; and how to type the variables, etc. that those instances will be accessed through, with abstract classes and/or interfaces. Another trap is to think that static, structural models are all that are needed; when really it is essential to validate the emerging structural model via message and instance exploration. In other words, in this session we introduce techniques like Class Responsibility Collaboration, and diagrams like the UML sequence diagram. This session completes the explanation of why outside-in design is much better than inside-out design.

Technical design

As just explained, we should now be in a position to specify concrete classes, abstract classes and interfaces. In this session we cover the ways in which, and the reasons why, object technology provides these mechanisms, and how we should use them to best effect. To support this, we also look at what concerns designers as far as details of messages, methods (member functions), instance variables (data members), constructors, etc. are concerned. We also complete the story on the power and the perils of implementation inheritance.

UML Detail

This unit comprises a session that describes the organization and content of the UML, and extra detail that is presented, in context, during the analysis and design modules.

Object-Oriented Programming Themes and Illustrations

This unit introduces and contrasts the main object technology choices - the object-oriented languages and frameworks. It also introduces the changes and additions required to the programmer's skill set if the benefits of object technology are to outweigh the extra complexities. This is done in a language-neutral way, focusing on the core of object-orientation that is present, and is similarly presented, by the main languages. (If a group is considering Smalltalk, however, they must make that known to us, as Smalltalk is somewhat different to the other three likely languages: C++, C# and Java.)

Hands-On Object-Oriented Design and Programming

Objects and messages

We want to be object-oriented rather than class-oriented, and we want to follow outside-in design rather than inside-out design, as advocated in earlier units, so we start with objects and their means of interaction.

Defining and making objects

Objects are defined by classes and we cover their details next.

Object instance relationships

When object instances are composed of, or aware of and collaborate with, other object instances, we have a simple, powerful and very object-oriented structure. We look at how these relationships are created and we revise the theory behind them.

Objects, the type system and conformance

An important part of outside-in design is realizing that the type system is more important than the class system. This is very important stuff to understand and use correctly; and the way it's done varies significantly from language to language.

Inheritance - the power and the peril

When object-orientation was first being promoted, a lot was made of inheritance. It has turned out to be significantly more difficult to do correctly and safely than anyone would have imagined twenty-five years ago. And we tend to use it with a different philosophy than was first anticipated.

Miscellany

Each language will have its peculiarities and idiosyncrasies. We cover the trivial ones here, at the end.

There are also some unique mechanisms in particular languages - delegates in C# for example. They get chapters to themselves that are slotted in at an appropriate point.

Contacting

Please contact John Deacon by telephone on +44 20 7498 3773; by fax on +44 20 7498 3747; by emailing  jdeacon@jdl.co.uk; or by visiting http://www.jdl.co.uk

[ Home page | Courses List ]

Last modified: Thursday, 08-Feb-2007.
Copyright © 2007 John Deacon. All rights reserved.