Following the adoption of UML by the Object Management Group (OMG), the UML has become a widely adopted, standard software modelling and design notation. The UML is a visual object modelling language developed by Grady Booch, Jim Rumbaugh, and Ivar Jacobson, with contributions from many users and other methodologists in the industry. This course not only teaches the UML but also shows how to use it within a sensible and pragmatic process, in order that all the benefits of object technology can be realized.
UML 2—a major revision of the standard—has recently been finalized. The most significant changes are to the activity diagrams and, to a lesser extent, the state machines (or statecharts as they were known). Please specify if you would like UML 2 or UML 1.x when ordering the course. If you are not sure, we would be delighted to discuss it with you.
Participants should have some knowledge of object technology although this need not necessarily be at a detailed level. Participants should also have had some experience of the problems associated with building large, complex, software-intensive systems; perhaps through already having tried to create specifications and designs, or through having worked from specifications or designs. Participants will normally know, and will have used, at least one high-level programming language. They will be wanting to know what object technology means for analysis and design. It will perhaps be helpful if they have read a little about the reasons for, and expected benefits from, object technology.
The course lasts four days.
It is based on a cycle of theory-language-practice-review, with approximately two cycles per day. One non-trivial, practical case-study is developed during the course. Each day will start at 09.30 and finish at 17.00, with an hour for lunch. Time is available at the end of the day for extended discussions or related issues.
In order to understand why object technology might benefit analysis and design, it is necessary to look at where objects came from and what their primary and secondary characteristics are. We recall the evolution of the object and establish the characteristics that make objects powerful yet predictable and malleable.
We look at the nature of, and relationships between, the various activities that might be undertaken prior to coding, and the reasons we don't just start coding. We ask how requirements capture differs from analysis; just what it is that analysis is analyzing; how analysis differs from design; and what effect object-orientation has on all this. We contrast agile and low-ceremony approaches with ponderous and high-ceremony processes.
The structure and contents of UML 1.4 (or the customer can choose to cover UML 2 instead) are introduced.
We establish just what requirements are, who has them and how they are documented. We describe use cases as a powerful technique for understanding and documenting the dynamics of requirements. We also ask if use cases are enough; and whether we need also to look outside the UML for ways to augment the accuracy and dependability of requirements.
When establishing the requirements for a system we often need to understand the constraints of the business process or workflow within which the system will be used. UML activity diagrams are discussed as a means of representing the procedural and concurrent parts of these dynamics. (Activity diagrams received the greatest number of changes in the move to UML 2. If they are of especial interest to you, please ensure that you talk to us about what you would like covered at this, transitional, point in time.)
What can we analyze? How does one analyze? How does analysis differ from requirements capture? How is analysis distinguished from high-level design? How are the results documented? We introduce analysis in terms of what it needs to achieve and the practices and documentation involved.
We begin in a fairly traditional manner, examining the context and subject matter for entities that make sense of the subject matter and that suggest good objects. It is essential for many reasons, including understandability, communicability and limiting the impact of change, that every object-to-be has a strong raison d'etre and a strong correspondence with something meaningful and relevant in the subject matter, in the context, in the platform or in a powerful metaphor. The UML structure diagram ("class" diagram) is introduced.
We further explore the subject matter while garnering more suggestions for the design architecture, by exploring the dependencies and relationships between the subject matter entities. This chapter is careful, however, to point out where object-oriented analysis is similar to information modelling and where it is not. The UML terminology (associations and aggregations) is introduced and one or two ambiguities and difficulties are explained and resolved.
The UML generalization relationships is introduced. Again there are danger areas to be wary of. We explain how to benefit from generalization relationships without them become introspective time wasting activities (analysis paralysis).
Our final analysis activity is to look at any constraints on, and states within, the life patterns of our entities; and to document them with state machines (statecharts as they were known in UML 1.x). When creating and using state machines we tread very carefully. Interpreting state machines, knowing when they are required, verifying and minimizing them, and keeping them productive are all significant challenges. This is the first look at state machines. They are used in enough places, and continue to present enough challenges, that we will return to them later, when we use them at design time.
We ask how analysis would proceed when there is no existing system that amenable to analysis. We distinguish business systems analysis from system subject matter analysis, and from systems analysis. The era of "computerization" is long-gone for the majority of developments. A job title of "analyst-programmer" no longer makes sense. We look at what we typically need to do for today's developments. And, occasionally, systems analysis is feasible and desirable, so we look at whether, and how, it differs from subject matter analysis, and how it is carried out.
We begin our quest for the classes and types that we must ultimately deliver, with a consideration of the service interfaces of the objects-to-be. We observe that many approaches of the past were class-oriented rather than object-oriented. We, however, will be thoroughly object-oriented. To emphasize that the choosing of the classes which will define the implementations of the objects is a later and distinct step, we introduce and explain the UML's object type.
The first services we can establish are the query services, which emerge directly from the analysis model. We look at why that is so and we discover that even the implementation of a simple query offers pitfalls which can undermine the potential benefits of object technology.
To begin discovering the remainder of the objects' service interfaces, and to continue to encourage the design of good objects (rather than thinly-disguised data structures), we start to make use of the CRC workshop (Class Responsibility Collaboration) and of UML sequence diagrams.
In a medium to large developments it is certain that the number of types and classes will be too large to consider in a single helping. This chapter introduces packaging and its UML representation. We also look at how packaging helps with name clashes, reuse and limiting the impact of change.
Having done the subject matter model, and having evolved that into an object type model, we move from analysis and high-level design into detailed, or technical design, and our third and final model; we move from the knowledge of the objects we need to the classes that bring them into being and the type system that controls other objects' perception of them. We cover the UML's representation of concrete classes, of abstract classes and of interfaces.
Objects communicate exclusively through messages. The only way our objects are able to message each other is via relationships. These can be refinements of the characterizing relationships already suggested by the analysis; or these can be use relationships, which were not particularly relevant to the analysis model, but which we now introduce. We also need to detail and specify the conformance relationships—the UML's realization and implements relationships—between the classes and the types. We continue to expose the cautions that are required because of UML/OOA's beginnings in semantic data models. Such things as bidirectional, many-to-many and n-ary characterizing relationships must be scrutinized very carefully and only kept in the model if absolutely essential and correct.
In order to establish the characteristics of some classes, a state machine is sometimes necessary. This chapter looks at the final tranche of detail in the use of state machines. The differences between the UML's protocol state machines and behavioural state machines is finalized. We look again at when state machines—the behavioural state machines in particular—are really necessary and we look again at the care necessary in their use.
In this third, most technical and final model, the emphasis so far has been on interfaces and relationships. In this chapter we look at details of the internal design of concrete and abstract classes—their implementation in methods, instance variables and constructors.
It may seem surprising, given the emphasis of the early OO evangelists, but implementation inheritance comes in at quite a late stage. While we may have made limited use of the inheritance mechanism already—in C++ we will have used it for the conformance (interface inheritance) already mentioned—this approach considers that the only time that decisions on sharing of implementation is reasonable, is when you know something about the implementation that you are considering sharing.
There is only so much that a formalized approach can suggest. There comes a point where you simply need to look at good design ideas that have already been used, and that have worked well. We examine a few of the interesting design patterns, introduce design pattern literature and catalogues, and introduce suggestions for capturing and documenting patterns.
We recommend that there are no more than 12 participants, with the best results usually obtained when there are at least 8 participants. It is possible, by negotiation and mutual agreement, for more than 12 participants to be present.
The case studies have been chosen to be realistic yet achievable. They introduce interesting problems often found in real applications. They are complex enough that they are not trivial, yet they allow a degree of completion to be attained. They are also in problem domains that most students have had some experience of. With advance planning, exercises that are relevant to the customer's business can be introduced.
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 ]