During this first day, the fundamental concepts are presented with many concrete examples. We cover the main features of OO Analysis and Design and how they unfold throughout the entire OOAD cycle.

A simple case study, The Personal Accounting System is used for students to practice basic modeling skills. By the end of the day, people feel they've received a rich description of the fundamental strategies and techniques.

They understand the benefits of OO technologies, have received a road map and are ready to use it to perform their first case study (next day).

Here is the first day's outline:

On this second day, focus is on integrating the first day's knowledge. The Brokerage Model is the students' first opportunity to perform an entire OOAD cycle using the UML, and on a business case that approaches real-life complexity.

Students have an opportunity to model on their own as well as in a small group. They get opportunities to present their own solutions and learn from others as well as from the instructor(s).

All students are closely mentored: we ask them questions that direct or rectify their thinking towards successful modeling. Solutions are never given away, except by the end of the exercise where everyone has either discovered them or has come very close.

Different types of solutions along with their conceptual business meanings are presented. At that point, people already feel that they know how to perform OO Analysis. They've solved a problem that is just slightly below average complexity. It's a very fulfilling step.

This Brokerage Model is then used as a stepping stone towards OO Design. The 5 key OO Design fundamentals are presented while walking the audience step-by-step through the OO Design process.

It is then time to generalize these OO Design principles to the subject of application design. We look at the successive layers (tiers) a typical software application is made of and how the UML syntax supports their modeling.

By the end of this very busy but fulfilling day, students feel they've acquired the fundamental skills to perform OOAD. They've also got a clear picture of the whole OOAD process. They're enthusiastic and well prepared to deal with the next day's challenge.

Here is the second day's outline:

Thanks to the second day, students now possess the whole OOAD & UML picture and the Brokerage Model has given them great confidence. It is time to deal with case studies that reflect real-life complexity.

The third day's "HR Model" brings about this opportunity. It is tackled in exactly the same way OO Analysis was performed on the previous day but it brings greater challenges.

Students quickly discover that there exists a powerful dimension to modeling: the modeling of relationships. 75% of all the models' challenges reside in relationship modeling: inheritance, compositions, associations, association classes and roles. This is advanced modeling.

At least half of the day is devoted to letting (and helping) the students discover how to analyze this challenging problem domain and overcome all difficulties. Solutions come about through the persistent modeling of business concepts and their relationships.

During this lab, people also learn to ask the right questions that are beneficial to OO Analysis. They learn how to map all business concepts to classes, objects and their relationships.

After this exercise we consider that they can already go out and solve average real-life cases by themselves. They're already above average OO modelers.

Optionally, the rest of the day is devoted to learning about the next phase: OO Design. We see how classes and objects can be implemented with OO languages. We also cover how relational models can systematically be derived from class diagrams.

Here is the third day's outline, most of the day is spent on the HR Model:

During the third day, students have learned how to "survive" real-life challenges through the advanced practice of relationship modeling.

At the start of the fourth day, the following question naturally comes up: Is there a way to tackle such models quickly? Yes there is; it's based on two key aspects: Patterns and Group Analysis Dynamics.

Patterns are typical solutions to typical problems. Unless you use them, you'll be constantly re-inventing the wheel. Students learn the most fundamental analysis and design patterns and how to apply them on-the-fly.

Patterns are a higher-level modeling practice. With this technique one can do real-time modeling. Real-time Modeling here means the ability to quickly come up with solutions to complex problems while interviewing the domain experts.

Several real-life (and non-confidential) case studies that we have dealt with during our own career at Object Discovery are used as patterns exercises. Three of them are so powerful and universal that they beautifully describe frameworks: a Scheduling Framework, a Product Configuration Framework and a Patient Tracking and Management Framework.

Frameworks are like super-patterns. They use one or many instances of one or many patterns. They represent most of the model one would need to solve a specific problem. Small extensions of these frameworks make up your final specific model.

Group Analysts Dynamics are studied too. These advanced techniques help the analyst channel and take advantage of the high energy and advanced knowledge of an entire group of subject-matter experts. All professional analysts have to deal with such groups soon or later.

There are a few simple steps and behavioral rules that allow to succeed in such environments. We cover them all while going through the many case studies explored in this day.

Students at this point feel that we've greatly shifted gears. They're getting ready to deal with any real-life challenges, including those they will encounter at their current work environment.

Optionally, this day can also be used to cover various advanced topics, like the Rational Unified Process, CASE tools, Object-oriented Business Process Modeling, and OO Databases.

Also, at some of our clients' request this fourth day may be simplified and kept more basic.

Here is the fourth day's outline:

We consider that after the fourth day our students have become experts. A very exciting and rewarding experience now is to apply this whole expertise to a subject matter or project pertaining to the student's own work environment.

On the fifth day, our client brings a problem that is considered to be important (even mission-critical) and non-trivial. We start from a written short problem statement and corresponding glossary of terms that have usually been prepared earlier in the week.

Then we perform the whole OO analysis and some OO design as a group, involving the whole class. All steps are completed according to the principles and techniques that we've learned during the past four days.

It is an interesting experience for our clients that see some of their most dreaded corporate problem domains melt away under the "powerful chisel of professional OO strategies".

It gives the students great confidence, and we (instructors) get to see some of the greatest problems ever found in the field... and get an opportunity to solve them.

Alternately and upon our clients request we can use this last day to review other topics or cover more of the optional ones.

Here is the fifth day's standard outline: