Following the adoption of UML by the Object Management Group (OMG), it is fairly certain that there will be one standardised and widely adopted software modelling and design notation. The UML currently at version 1.3, is a visual object modelling language developed by Grady Booch, James Rumbaugh, and Ivar Jacobson, with contributions from many users and other methodologists in the industry--the aim being to eliminate object method fragmentation. Recently, the Unified Software Development Process has been published by the UML authors, and Matrice has incorporated their suggestions into the process model that this course teaches.
This course is an extension of our theory-only course Object-Oriented Analysis and Design using UML. It offers participants the opportunity to gain some familiarity with the support for the method and notation from a CASE tool--such as Together, StP, OEW, Describe, Visual Modelleror Rose--within the context of an OO analysis and design course.
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. Participants will also be wanting an introduction to CASE via a popular tool.
The course lasts five days with one day devoted to the use of the CASE tool. The use of the CASE tool will be integrated with the theory part throughout the five days, or if facilities are limited the final day will be devoted to using the tool.
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 their characteristics. 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 and analysis differ; just what it is that analysis is analysing; how analysis differs from design; and the effect of object-orientation.
The structure and major elements of UML 1.3 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 look at the approach taken by CASE tools and we introduce the creation of diagrams. We will also be considering model detail & correctness, forward & reverse engineering, printing & document generation, and tools, utilities & integration.
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. Activity diagrams are discussed as a means of representing the procedural and concurrent parts of these dynamics.
What can we analyse? How does one analyse? How are the results documented? We look at what analysis attempts and how it is carried out and documented
We begin in a traditional manner, examining the context and subject matter for entities that make sense of the subject matter and that suggest good objects.
Another way to make sense of the subject matter and again suggest some of the design architecture, is to explore 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.
Our final analysis activity is to look at any constraints on, and states in, the lives of our entities and document them with statecharts.
We begin our quest for the classes we will ultimately deliver, with a consideration of the service providers and their interfaces. To emphasise that choosing the classes which will implement these services is a later and distinct step, we refer to object types at this stage. Query services are easy to define, but 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.
We start to think about the rôles that relationships will play for the object classes and their instances. Areas where care is necessary are highlighted. Use of CASE.
Having got a little way into the "static" model, we now begin some dynamic modelling. We have an initial idea of the types we will need. We have a simple set of services. Now we confirm and extend our classes' service interfaces through a consideration of object collaboration, employing CRC workshops and interaction diagrams. Use of CASE.
In a medium to large development it is likely that the number of types and classes will be too large to consider in its entirety. This chapter introduces packaging.
We move from analysis and high-level design into detailed design. From the types uncovered by the analysis and high-level design, we decide which classes and abstract types will result. Use of CASE.
Our objects will communicate only through messages. The only way our objects can send messages to each other is through relationships. We also need to establish the conformance relationships between classes and types. We have some ideas on relationships from the early models. Here we refine those ideas and get practical about their implementation, using either sequence and collaboration diagrams to record the messaging patterns. Use of CASE.
In order to establish the behavioural characteristics of some classes, a state model is sometimes helpful--an intra-object dynamic model. This chapter looks in more detail at the use of statecharts. We also look at when they are helpful or necessary.
Previous activities have focused on interfaces and linkages. In this chapter we start to look at details of the internal design of classes--the implementation with methods and variables. Use of CASE.
There is only so much that a formalised approach can suggest. There comes a point where you simply need to look at good design patterns that have already been used, and that worked well.
We recommend that there are no more than 10 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 10 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 Matrice by telephone on +44 7010 704705; by fax on +44 7010 704706; by emailing bookings@matrice.co.uk; or by visiting http://www.matrice.co.uk
Questions or problems regarding this web site should be
directed to webmaster@matrice.co.uk.
Copyright © 2005 Matrice. All rights reserved.
Last modified:
Tuesday, 07-Jun-2005