The training/consulting session combines theory of the ICONIX process, an instructor-led work session where object models , use case models, and test models will be started for the project, and hands-on laboratory sessions where company personnel continue to refine the models which were started in the work session. The tool of your choice is used, and the UML notation is used for modeling. Laboratory sessions are split into teams along major functional boundaries.
2 Weeks Prior to Class:
Since classroom time is limited, preparation beforehand on both sides is key to success!
1. ICONIX (usually under nondisclosure) receives detailed information about your project. This gives our instructors time to study up on your project prior to the workshop so that when we walk through the door, we are already briefed and ready to work.
2. Each student receives a free CD-ROM tutorial, Mastering UML with the ICONIX Process, to prepare for the topics covered in the training course. This allows our instructors to spend less time on the basics, and frees up more time to actually apply the concepts being taught to your project.
Project description -- Your company's team introduces the system and explains functionality, problem areas, goals and requirements. ICONIX expects to receive some written information on the system and reviews the written material before the start of the consulting session. This reinforces the material the instuctor has already reviewed prior to the class.
Introduction to the ICONIX Process and UML -- An overview of the object modeling, use case modeling, and test modeling activities to be performed and how they relate to the overall development lifecycle is presented. Special emphasis is placed on the differences in thought process between use case modeling and object-oriented decomposition on the one hand, versus more traditional approaches to system/software specification such as functional and data-driven decomposition. A brief overview of UML is provided.
Object Oriented Analysis -- The remainder of the first day and the second and third days are focused on Object Oriented Analysis, the capturing of a system/application requirements model specifying the "problem" that the system/application needs to solve.
Identification of domain objects -- The focus of this section is on development of an initial domain object model and use of object modeling techniques without use cases, such as noun-verb analysis. This activity is a typical approach to requirements modeling for object oriented systems, and is conducted as a brainstorming session using whiteboards and the chosen CASE tool, and then expanded in the first laboratory session.
The students are divided up into lab teams so that each group has a mix of skillsets and project roles. All students participate in the lab whether they are subject matter experts, developers, testers, or managers. UML class diagrams are used to describe problem domain objects and the associations between them. Finally, the group results are presented to the whole class in an instructor-led debrief. The difficulties of proceeding in object modeling without use cases are made apparent, to set the stage for Day 2.
Identification of use cases, user interface prototyping, and the expansion of the domain object model -- This activity starts with identification of the actors (users and other systems that interact with the system being specified), and proceeds into identifying broad categories of use cases (usage scenarios) for each of these actors. Use Case diagram notation is introduced, and diagrams are used to capture actors and associated use cases. This is done in a group brainstorming fashion for the first few actors, and then additional actors and use cases are detailed as a laboratory exercise. Again all students participate regardless of project role.
At this point the relationship between use cases and user interface prototyping is introduced. Following the identification of the use cases, selected use cases are detailed. This is done for a couple use cases by the instructor in a group lecture first, and then additional use cases are detailed as a second laboratory exercise. Exploration of the use cases is used as a mechanism to uncover more objects and more details about the domain objects as well, particularly the attributes of each object.
Development of the User Interface prototype, Use Case Model and Domain Object Model is an iterative process carried out over the rest of the day. As before, after each lab session, the group results are presented to the whole class in an instructor-led debrief.
Verifying and Validating the Requirements Models -- At this point the class has familiarity with the notations used to specify the system/application requirements: User Interface prototypes, the Use Case Model, and the Domain Object Model. It is now time to introduce the primary mechanism for verifying and validating these models: Robustness Analysis. This activity shows how to explicitly map the three models together in order to verify their consistency and completeness. The Robustness Diagram notation is introduced and diagrams are used to create explicitly traceable maps between the use cases and the UI-related and Domain-related objects.
At the same time, a new type of object is introduced that "glues" the UI to the Domain objects, and provides overall system control. These "control" objects eventually form the basis for most of the operations on the objects and are the first step toward designing a solution to the requirements.
This activity is introduced first as a lecture, with the instructor covering the notation and the process, and working through one of the use case's robustness. Then the students go back into their groups and do the rest of the robustness analysis as a laboratory exercise. Once again, the group results of each lab session are presented to the whole class in an instructor-led debrief.
Test Development -- Now that the Requirements Models have been verified and validated, it is time to start the planning and development of tests based on the models. The direct relationship between functional test cases and usage scenarios is described, as well as the process of creating test plans and test cases from the use case model. The discussion also describes how to factor use cases and categorize in ways that facilitate test development. Next, the process of test data derivation from the Domain Object Model is presented. Finally, while the primary focus of the class is the test model and test process, the instructor will also discuss test tool usage in the context of this process.
Once again, after the instructor introduces these elements via lecture and an example, the students resume their lab groups, with each team taking the appropriate use cases from the work session, and applies the techniques learned in the morning to identify and create test cases.
Object Oriented Design -- At this point, the class moves into the more development/technical oriented parts of the process. Days 4 and 5 focus on defining the "solution" to the Requirements Model. The primary notations for design level object modeling of the solution (as opposed to the previous analysis level modeling of the problem) are sequence diagrams, a design level object model called the Static Object Model, and component diagrams.
Sequence Diagramming -- The sequence diagram notation is introduced and used to define how the domain objects are factored into design level objects (using the robustness diagrams as a starting point) and how each of these objects communicates with the others over time. While this activity is performed, all responsibilities are allocated to specific objects, which is the core design activity in an object oriented system/application. The sequence diagrams, like the robustness diagrams, are directly mapped and traceable to the use cases.
Static Object Models at the design level -- The fundamentals of class modeling with UML, including generalization, aggregation, attributes, and operations at the analysis level were covered in Domain Modeling. Now, as responsibilities are allocated during sequence diagramming, these basic class modeling elements are augmented with notations for visibility, abstract vs concrete classes, parameters and arguments, and a variety of other detailed design constructs. At this point, the application of design patterns and programming language considerations are discussed.
Component Diagrams -- Specific technology choices, such as distributed object/component technologies, application frameworks, and overall system architecture are drivers for this activity. The objects identified in the static object model are grouped into components, and additional infrastructure objects and component interfaces are modeled as necessary. Particular emphasis is placed on the abstraction of interfaces for extensibility and the implications of object/component packaging and distribution on performance, reliability, and safety.
After the instructor introduces each topic and works through an example, each lab group works to adds objects discovered during the previous day's lab session to the object model and begins to refine a portion of the overall object model to a design level, allocating responsibilities via sequence diagrams and detail design constructs via the Static Object Model. In a second lab, these objects are packaged into components and component diagrams are created. Finally, the operational implications of the design are discussed in an instructor-led debrief.
Verifying and Validating the Design Models -- At this point the class has familiarity with the notations used to specify the system/application design: Sequence Diagrams, Static Object Model, and Component Diagrams. Once again, as with robustness, the traceability of the design to the requirements is explicit. Verification of the consistency and completeness of the design with respect to the requirements via sequence diagrams is discussed.
Test Development -- Now that the Design Models have been verified and validated versus the requirements, it is time to start the planning and development of tests based on the design models. The direct relationships between unit test cases and objects is discussed. Further, the relationship between lower level integration test cases and object/component allocation is explored. Finally, the relationship between higher level integration test cases and component interfaces is described. For each of these relationships, the process of creating test plans and test cases from these models is presented. The discussion also describes how to augment components with objects/operations in ways that facilitate testing. Next, the process of test data derivation from the Static Object Model is presented. Finally, while the primary focus of the class is the test model and test process, the instructor will also discuss test tool usage in the context of this process.
Once again, after the instructor introduces these elements via lecture and an example, the students resume their lab groups, with each team taking the appropriate use cases from the work session, and applies the techniques learned in the morning to identify and create unit and integration test cases.
This course is available in a 3-day format. Click here for more details.
*UML is a trademark of Object Management Group, Inc. in the U.S. and other countries.
ICONIX Software Engineering, Inc./2800 28th Street, Suite 320/Santa Monica, CA 90405/Tel (310)458-0092/Fax (310)396-3454/email: email@example.com