Welcome to the OOSE Website 3/E This site provides support material for Object-Oriented Software Engineering: Using UML, Patterns, and Java, 3rd Edition Prentice Hall, Upper Saddle River, NJ, September 25, 2009. To purchase the English edition, visit amazon com, de, or uk To request an instructor copy or instructor resources, visit Pearson. To report errors, provide feedback, or otherwise tell us about your opinion on this book, please contact us: Bernd Bruegge & Allen H. Dutoit.

Examples of project courses

In this section we show a couple of movies created during our courses.

Example of a three month course - TRAMP

The TRAMP system (Traveling Repair and Maintenance Platform) was developed in a Praktikum with 50 student participants.

TRAMP's objectives can be divided in two parts. First, there are some overall goals that have to be kept in mind especially during  the system design phase. Overall Goal: Develop a Car Maintenance System that supports the TRAMP scenario and provides as much capability as possible as constrained by the functional and nonúfunctional requirements and the time assigned to the class. Secondary Goal: Identify and evaluate new UMTS applications to support vehicle maintenanceSecond, another objective that focuses on the actual development process exists: Merge new system components with existing components from Inmedius and TUM.The success criteria of the project is the acceptance by the client.

Example of a four month course - DOLLI Winter 2007

This movie shows the flavor of our course. 47 third year students participated in the single-project course to develop a software system to address quite complex requirements from a real client, the Munich Airport GmbH IT. The problem statement (in german) asked the students to build a system that can track dollies, baggage, support a remote repair scenario and provide a 3-D visualization of the complete Munich airport based on GIS data obtained from the customer. The project lasted for 4 1/2 months, 15 Oct 2006 to 15 March 2007. The course material was offered in the 3 month course with focus on Chapter 1 to 11, and Chapter 13 as well as the templates from our book. In addition we offered an advanced project management seminar with a syllabus based on the content from Chapter 12 to Chapter 16. The "exercises" for these students consisted managing student teams from the project course as coaches. A PhD student was the project leader, the instructor performed the role of the methodologist. The film as produced in another academic course, a seminar called "Software Cinema" in which we taught the students about using film for scenario-based design.

During the 3 month course, the development of the software took place in our labs following a software lifecycle based on the Unified Process. At the beginning of the vacation -after the finals were taken and the semester was over - we asked which of the students wanted to continue the development as volunteers. 43 students offered to participate to continue on, and worked 2 weeks in at the airport facilities. For this time, we used a the Scrum approach with two Sprints of one week each. We had taught Scrum the advanced project management students, who then taught it to the project course students supervised by the project leader and the methodologist. On March 7 the system was successfully demonstrated to the client.

Example of a four month course - VSO Winter 2005

Virtual Symphony Orchestra (VSO) is another example for a project course with Bayrischen Rundfunk and 52 students. To be continued by Prof. Bernd Brügge.

Example of a two semester course - JAMES

JAMES is an example of a continued development of a successful 3 or 4 month course where the customer added new requirements or the underlying technology changed. It was a three semester project course with a 110 students working globally distributed: The first semester course was initiated at CMU. the second semester course involved both the CMU and the TUM; the third semester course was on the CMU site only. The overall project, including pre- and post-development, lasted 11 months.

The goals of the JAMES project were twofold: First, to investigate JavaCard technology and assess if it can be used to host multiple applications on the same card, the purpose being to reduce the number of cards each individual needs to carry around. Second, to define a system architecture that would enable users to select a combination of applications and dynamically store them on their cards. This allows the car manufacturer to offer new services and applications that could be added even after the purchase of the vehicle.

To accomplish these two goals, JAMES was to demonstrate a technology prototype that included three smart card applications: Travel, a system for planning and following routes on an onboard digital street map; Bonus, a reward system similar to a frequent flier mileage program; and VIP, a system for storing and customizing individual preferences, such as seat position, radio station, and audio volume settings. 

The movies are taken from the distributed client acceptance test, which was performed simultanously at CMU in Pittsburgh, TUM in Munich and Daimler Headquarter in Stuttgart.

The movie shows the Bonus System scenario: The Bonus System is a discount System for a special relationship between customer and the client.	The movie shows the home interface with a smart card reader.	The movie shows the home interface with a smart card reader.
How is your wife doing?	This video shows the presentation of actors for a scenario.	This movie shows a car wash scenario.
This movie shows the system acceptance test.	The movie shows a customized seat	The movie shows the Bonus System user interface and its usage
This movie shows the participants of the client acceptance test.	This movie shows the distributed participants of the client acceptance test.	This movie shows the travelling repair system
This movie shows directions on the card	Two months later.

Examples of Problem Statements

This page contains a representative set of problem statement which we have used in our project courses.

• DOLLI (german): Aim of this course is the evaluation and prototypical realization of the application of telemetric data (e.g. shipment completition of a plane, tank level of a plane, or the alert status of a security door) and the benefit of an interaction with localized object. Customer: Flughafen München
• WALOS (german): Exploration of applicability of RFID in a production facility to optimizie the logistic process by capturing recently produced products quickly. Furthermore GPS tracking was tested with aditional sensor information, e.g. temperature, to adress liability issues. Customer: Wacker Chemie Reichel?
• Campus TV: DVB-T based transmission of interactive lecture.
  Customer: Rohde & Schwarz: Manfred Reitmeier
• TRAMP: The realized scenario was to guide a mechanic who is equipped with a wearable computer to a customer who has a car breakdown. The mechanic is also instructed by the system on the actual repair process to fix the car.
• STARS - Sticky Technology for Augmented Reality Systems: STARS attempts to reduce the cost of logistics support and maintenance while improving or at least maintaining current aircraft readiness. To address the problem, we propose the implementation of two major processes:

  developing & managing interactive electronic technical manuals and performing maintenance with advanced capability IETMs.

• PAID: The goal of this project was to develop a software solution for deploying frequently updated technical specifications and information about vehicle maintenance to car dealers. Traditional methods, such as delivering paper-based or CD-based documents, are slow and costly. The project is based on a selective, adaptive multicast protocol and builds on advanced technologies such as data mining, statistical modeling, and mobile computing.
• JAMES: The goal of this project is to develop services and applications related to smart cards and cars. Examples are the automatic reservation of parking lots via mobile phones, the remote diagnosis of car failures, and the realization of frequent driver incentive schemes. Some of these applications also benefit from satellite navigation systems, for example, to guide the driver to its reserved parking lot.
• OWL: The goal of this project was to develop the infrastructure for intelligent buildings. All objects in a house, from the elevators and locks down to single light bulbs, are equipped with sensors and actuators that allow to detect failures and malfunctions.
  Customer: Volker Hartkopf
• DIAMOND: The goal of the DIAMOND (Distributed Intelligent Assistant for Maintenance ON Demand) system is to improve and optimize the flow of information between engineers performing maintenance on people mover systems. DIAMOND is part of a larger system development effort called AMEFS (ATS Maintenance Engineering Feedback System) The overall AMEFS is expected to provide easy access to an integrated information space so that technicians, engineers, managers and trainers can author or obtain needed information anytime and anyplace their work demands it.
• AMEFS/ DAIMLER: The goal of the DAIMLER (Distributed Assistant for Intelligent Maintenance in a gLobal EnviRonment) system is to improve and optimize the flow of information between engineers performing maintenance on people mover systems. To deal with these goals, this course focuses on three areas of Management and Diagnostics.
• JEWEL: The goal of this project was to measure and simulate the spread of air pollutants with respect to a model of the environment.
  Customer: Gregory Mc Rae, Department of Chemistry, CMU and Ted Russel, Mechanical Engineering, CMU
• FRIEND: Planning, fire, police, emergency medical services (EMS), administrative, public works, and building inspection departments compile seemingly unlimited amounts of paper based information. This information becomes extremely hard to use during an emergency, and for all intent and purpose it is rarely used. Each employee in these departments has historical information that is not a part of the paper data base. This information is so massive that it would not be economically feasible to catalog to catalog it in a paper system.
  Customer: Chief of Police, Michael Boolser (??)

Examples of Client Acceptance Presentations

This section contains some examples of presentations of the projects to our clients

• VSO - Virtual Symphony Orchestra
• TRAMP Folien und TRAMP Client Acceptance Presenatation movie

Examples of Communication Infrastructure

Web Portal, Mailman, Lotus Notes, Bboard

Here you find examples for our Software Engineering course projects:

• Virtual Symphony Orchestra: An example of project course for the Bayrischen Rundfunk.

Case Study

ARENA: Work products for the case study discussed in the book

With the arrival of the global broadband network infrastructure, new game concepts are possible and resulted in the creation of a wealth of Multiplayer Online Games (MOGs), for example, Quake, CounterStrike, Ultima Online, EverQuest, or WarCraft. These games share common concepts:

• A client-/server architecture, with one dedicated server with control over player movement and world objects.
• Extensible, but pre-designed sets of maps, objects, and weapons. Typically, these game elements are created by graphic designers and artists in substantial manual effort.
• Freedom of player movement and the ability to manipulate world objects.

But after the broadcasting infrastructure of radio and television was supplemented by two-way network connections, another use of the technology was enabled: peer-to-peer (P2P) networks. Thus far they are mainly used for one-on-one messaging or simple file exchange. The newly available FRAG framework manages peer-to-peer communication, distributed object synchronization and message transport for object-based 2D or 3D game worlds. FRAG is part of the GlobalSE project ARENA providing an infrastructure for tournaments in mobile environments. This project will develop a peer-to-peer multiplayer online game called SWORD on top of the FRAG framework. A functional prototype will be demonstrated at the end of the project, which is based on the technologies and infrastructure available.

Document Templates

This section provides document templates from the book we use in our project course.

• Problem Statement
• Software Project Management Plan
• Requirements Analysis Document
• System Design Document
• Object Design Document
• Software Configuration Management Plan
• Test Plan
• Test Case Specification

Instructors Project Handbook

In this section you can download an instructors projects handbook which explains how to perform a Software Engineering project course.

Examples for Icebreakers

"You can learn more about a person in one hour of play than you can in a year of conversation" (Plato)

What is an icebreaker?

At the beginning of project in a project-based organiztion one should schedule an "icebreaker". This exercise

• allows the participants to get to know each other (we cannot assume that project members know each other)
• provides a cooperative challenge where everybody can participate without deep knowledge of the system to be developed
• allows the project leader to informally introduce basic concepts of the course in an easy to understand example.

Why is it called "icebreaker"?

The icebreaker addresses several problems ("breaks the ice") that are typical for projects in project-based organizations:

• It reduces social friction by providing a problem that has to be solved together. (social component)
• It reduces the uncertainty for the project by giving a sense of achievement when the first problem of the course is solved. (self-confidence component)
• It introduces first terms and concepts of the course that can be experienced by practical work. (reference component)

If it's done right, the icebreaker also lays the ground for participatory management, because it demonstrates that problems can be solved easier with personal initiative and that the help of other developers is crucial for solving the problem.

How to prepare the icebreaker?

There has to be done some work of preparation for that, the icebreaker doesn't work necessarily on its own. The first thing is to choose the right icebreaker exercise. Not every funny sounding "getting everybody to know"-game can be used as a succesful icebreaker in our meaning.

• Check the three criteria mentioned above (social, self-confidence and reference component)!
  If just one or two criterias are covered, think about splitting the social and self-confidence component and get the reference component from an example that's used throughout the entire course.
• Be prepared for what can be coming up during the exercise!
  May the exercise fails, because nobody finds a solution. Perhaps a different solution is found, because someone found a way to break the requirements. Perhaps one or two persons dominate the exercise and don't let the others take part in the solution because of their staus or dominance. The exerciese must be accompanied and guided.
• Prepare your comments on the exercise well!
  The references to topics of the course don't come from alone. The participants don't know exactly what the course will be about - so analogies, concepts and terms of the course have to be explicitly shown on the exercise.

Examples:

• The Bridge Builder Exercise asks teams to build a bridge over two tables with Lego parts:
  • Bridge Builder: Instructions for the Instructor
  • Bridge Builder: Exercise for the Students
• The goal is to construct an airplane that carries a kiss as far as possible without harming it. (ChocoPlane.ppt)

Lectures and Artwork

This section provides power point presentations for your lectures and artwork from the book.

• Foreword
• Preface

1. Introduction (lecture)
2. Modeling with UML (lectures 1, 2, 3, 4, 5)
3. Project Organization and Communication (lectures 1, 2, 3)
4. Requirements Elicitation (lectures1, 2)
5. Analysis (lectures 1, 2)
6. System Design: Decomposing the System (lecture)
7. System Design: Addressing Design Goals (lecture)
8. Object Design: Reusing Pattern Solutions (lectures 1, 2, 3)
9. Object Design: Specifying Interfaces (lectures 1, 2)
10. Mapping Models to Code (lectures 1, 2)
11. Testing (lectures 1, 2, 3)
12. Rationale Management (lectures 1, 2)
13. Configuration Management (lectures 1, 2)
14. Project Management (lectures 1, 2, 3, 4)
15. Software Life Cycle (lectures 1, 2, 3)
16. Methodologies: Putting It All Together (lectures 1, 2, 3)
    

To download all lectures as a single zip file, click here (64.6 MB).

Quiz questions

Quiz questions serve for exams. Here you find a set of exam questions to be used with a "closed book" exam.

Exercises

Here you find additional exercises to practice the concepts in the book.

Solutions

Here you find solutions for the exercises in the book.

Errata

Errata: This is the list of known typos in the book.
1. Throughout Chapter 15 we use the term "process group". The revised version of the IEEE Std 1074 standard now uses the term "activity group" instead of "process group".