Training Courses in the UK and Europe

Link to home page
Link to training page
Link to consulting page
Link to PPARC page
Link to personal details
Link to contact information

Object-Oriented Analysis and Design with UML

A John Deacon training course

This four-day course will give participants a sound understanding of modern object-oriented analysis and design techniques. On completion of the course, participants will know what must be done before coding can begin on non-trivial projects. The course ensures that the approach taken to analysis and design makes insightful and pragmatic use of both object technology (our examples are Java, C++, Smalltalk and C#) and UML (the Unified Modelling Language, version 1.x or version 2.0). The course also shows how more recent trends like agile processes and eXtreme Programming have influenced analysis and design.

Aims

  • 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 identify and clearly explain which areas of the UML can be expected to benefit typical object technology users, and how best to use them;
  • 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 ensure that the expected benefits of each aspect of typical object technologies, especially inheritance, are put into context against their potential drawbacks;

Background

For several reasons, today's object-oriented analysis and design approaches are based on database design techniques. However, it is essential that the passive-data basis of these older techniques is not allowed to spoil the potential of a modern, object-oriented analysis phase to give the object planning a sound beginning. There are several important shifts of emphasis that must be understood - for example, the older techniques found relationship symmetry to be an fairly unimportant topic, whereas for object-oriented analysis it's very important that we begin to identify directed relationships.

Furthermore, much of what is taught today for analysis in systems development is still based on an age that is long-past as far as many typical developers of today are concerned - the age of "computerization". Today, it is not usually the case that an analyst-programmer analyzes how an existing clerical system works and then proceeds to program up its software analogue. Today, we have a much more subtle path to follow.

A more realistic and workable approach is to analyze the subject matter of the system-to-be with a view to beginning a model that, wherever it is reasonable, there is a good resemblance between the structure of the system-to-be and its subject matter. One must not be naive, however; we cannot expect that every aspect of a computer system being developed will have a simple match with something in the subject matter. It is essential to distinguish those subject matter elements that are relevant and good predictors, from those that are not; some things directly influence the structure of the model and some things do not.

Following on from this, we then expect a design activity to elaborate this model, inventing those areas where the subject matter furnishes no useful input, while ensuring that the benefit of object technology are fully realized. Misunderstanding the importance of types, misunderstanding the power and the perils of inheritance, being class-oriented rather than object-oriented can all lead to object technology lending plenty of extra complexity but no benefit.

In order for analysis and design to provide the solid foundation for the development of a software-intensive system, yet not consume any more of the development budget than they should, it is vital that each phase is clearly understood in terms of what it can, should, and should not be trying to do. It is all too easy, for example, to muddle requirements capture and elicitation with analysis, and all too easy to muddle analysis with high-level design.

While system developers would be in even more trouble without the UML as a standard for software engineering specification, an uninsightful use of the UML will produce ambiguous and ungainly specifications and encourage a ponderous rather than agile process. It is necessary for developers to be able to select the correct balance of UML diagram types and contents for a project.

For more background to this course, you might like to take a look at the object-oriented analysis and design book that this course eventually inspired. A good starting place would be the book's sample content page.

(For other mixtures of topics, you might look at the modular OO description.)

Audience

This course will 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. The course will also benefit those who wish to learn a sensible and pragmatic use of the UML (2.0 or 1.x). It also benefits those wanting to better understand the nature and successful deployment of object technology.

The course is suitable both for groups who have not yet learned their object technology, where it establishes what we expect of object technology, and for groups who have covered the technology, where it shows how we must plan for a sensible use of the technology. Ideally, it is best if the group is not a mixture of the two.

Duration and Construction

The course last four days, typically from 0900 to 1630 and is delivered via lecture, case-study and discussion. The case-study is a significant and realistic one. Start, end and break times can be tailored to suit individual sites.

Delivery

Courses are normally delivered at the customer site. To discuss arrangements, please contact course administration, by email, or by fax (+44 20 7498 3747).

The course deliverables comprise:

  • lectures and a per-student copy of the lecture notes;
  • case study exercises and sample solutions;
  • help with, and feedback on, the exercises;
  • leading and moderating of discussion, questions and answers;
  • reference and resource lists;
  • appendices to the lecture notes comprising: OO aphorisms, glossary, index and UML ready-reference;
  • (most pricing structures) a per-student copy of Object-Oriented Analysis and Design, written by John Deacon, published by Addison-Wesley;

Content

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.

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 will be an introduction; and for other groups this will be revision and agreement as to terminology.

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.

 

 

JDL Logo
Copyright © 2009 John Deacon. All rights reserved.