Building Systems from Commercial Components: Classroom Experiences



Robert C. Seacord

This library item is related to the following area(s) of work:

System of Systems

This article was originally published in News at SEI on: March 1, 2002

It often happens that a teacher learns as much in the classroom as his or her students. Columnist Robert Seacord shares insights he gained from teaching systems engineering students to integrate commercial off-the-shelf (COTS) and custom components in their system designs. Seacord anticipates using these insights to improve COTS-based development processes.


There are two points of view regarding software engineering. The first holds that human intelligence is a constant, and to improve the quality and reduce the cost of developing software-intensive systems, we must improve the techniques, technologies, process, methods, and tools we use to build software. The second holds that, if you take an axe away from a simpleton and replace it with a chainsaw, he will still cut off his leg—only now he will do it more efficiently. The solution, in this case, does not require that you improve the tools, only that you improve the users’ ability to apply the tools they already have. Hence, we have software engineering education.

Armed with the latter philosophy, I set off this spring to teach software engineering at the undergraduate level. When I took software engineering as an undergraduate in 1983, software engineering still meant “Ada.” Unfortunately, there was no Ada compiler available for our use at that time, so we got to scribble our designs on sheets of paper and hand them in for credit. As this was not my fondest memory of my undergraduate years, I decided not to share this experience with my students. Instead, I fashioned a software engineering course from Ian Sommerville’s text on software engineering [1] and my own text, Building Systems from Commercial Components [2].

While one hopes to fashion young students into future software engineers (and not scare them away to the fast food industry), I think it is often the case that the teacher learns as much as the student. In this column, I will discuss one of the lessons I’ve learned from this experience and how I see this lesson potentially improving COTS-based system processes down the road.

Software Engineering with Commercial Components

The software engineering course I am teaching consists of two main elements, a semester-long project developed by teams of students, and the classroom “experience,” which culminates in a final examination. The project teams are assigned based on the result of a student assessment, in the hope that balanced teams can be formed.

The actual assignment is to develop an enterprise information system that could be used by car dealerships for tracking maintenance activity on cars under warranty. Mechanics would use the system at individual service stations to record all maintenance activity. Senior management would use the system at an enterprise level to collect and analyze maintenance trends. In addition to functional requirements, several technology requirements were also imposed, including requirements that the system be Web-accessible, use Enterprise JavaBeans (EJB) in the middle tier, and store data in a relational database management system (RDBMS).

Execution of the project was separated into three phases, with milestones established at the end of each phase identifying required products that must be handed in for grading. Each set of milestone deliverables was given equal weighting:

First milestone:

  • a Unified Modeling Language (UML) specification/design for the system
  • blackboards for three component ensembles

Second milestone:

  • completed blackboards for all three ensembles
  • risk/misfit evaluation

Third milestone:

  • PowerPoint presentation and demonstration to be delivered in class
  • source code and URL for the working system

The goal of the project was to model, as closely as possible in a classroom situation, a real-world development project. In the initial milestone, the students were asked to create a design for the system, as well as three component ensembles. Component ensembles are groups of compatible components that can be used to achieve the system objectives. In this case, these components are all infrastructure components. The students were asked to vary each ensemble at least in the choice of an EJB server (since the choice of an EJB server, more so than the other components, drives other component choices). Blackboards are UML-based notation for describing component ensembles. Component ensembles and blackboards are both subjects of Building Systems from Commercial Components, and are taught in the classroom.

In the initial set of blackboards, the students are told to identify both “knowns” and “known unknowns.” These are expressed in terms of credentials (facts associated with a degree of confidence), postulates (required information associated with a plan to acquire), and constraints on component interactions. Students are penalized for failing to identify unknowns (“unknown unknowns”).

The second milestone consists of two deliverables. Postulates in the blackboard are replaced with credentials, with the overall effect being that the feasibility (or infeasibility) of the ensembles is demonstrated. Student teams are required to produce at least two feasible ensembles from the original set of three, so that these ensembles can be evaluated using the Risk/Misfit techniques also described in Building Systems from Commercial Components. A single ensemble is then chosen as a result of the evaluation, and this ensemble is driven through to implementation.

A Lesson Learned

One lesson I’ve learned (so far) from administering and evaluating project deliverables is that, once someone is enmeshed in the field of COTS-based software engineering, it is too easy to de-emphasize or ignore non-COTS aspects of the development effort. For example, in the first milestone, the students were required to create both a UML design for the system and a set of blackboards. Performing these tasks concurrently is a practical necessity for any real-world development effort as well as a class project, as component compatibility must be accessed while the system specification is created and custom components are designed. This introduces two interesting and opposed sets of challenges—incorporating constraints imposed by the component ensembles on the design while developing a design specification independent of any particular ensemble.

The solution is a tightrope-walking exercise in integrating common, technology-driven aspects of the component ensembles with the design, while designing abstract classes not tied to a particular product for implementation. Some student teams also jumped right off the tightrope and specified generic sequence diagrams for interactions among technology components. These diagrams were a reasonably useful extension of the blackboard.

Once a component ensemble has been selected, it is now feasible (and necessary) to allow component-specific concerns to influence the design. Still, these designs should be maintained in a configuration-management system that directly connects the artifacts to the selected design contingency.

In retrospect, this lesson was evident from the beginning in my choice of two texts for the course. Eventually, to be done right, this course will need to be taught with a single text that applies all the traditional areas of software engineering, including software process, project management, requirements engineering, architectural design, verification and validation, and software testing with COTS-based development practices.


Teaching software engineering using commercial components at the undergraduate level provides a great opportunity to evaluate these processes in a controlled setting, since students in general are not shy about complaining about all the hardships being forced on them. I hope that by repetition of this course, combined with refinement of the processes and industry involvement, a more prescriptive COTS-based development process can be formulated.


[1] Sommerville, Ian. Software Engineering. New York: Addison-Wesley, 2000, ISBN: 020139815X.

[2] Wallnau, Kurt C.; Hissam, Scott A.; and Seacord, Robert C. Building Systems from Commercial Components. Boston: Addison-Wesley, 2002, ISBN: 0201700646.

About the Author

Robert C. Seacord is a senior member of the technical staff at the SEI and an eclectic technologist. He is coauthor of the book Building Systems from Commercial Components as well as more than 30 papers on component-based software engineering, Web-based system design, legacy system modernization, component repositories and search engines, security, and user interface design and development.

Visit our library for more information on the book Building Systems from Commercial Components.

The views expressed in this article are the author's only and do not represent directly or imply any official position or view of the Software Engineering Institute or Carnegie Mellon University. This article is intended to stimulate further discussion about this topic.

Find Us Here

Find us on Youtube  Find us on LinkedIn  Find us on twitter  Find us on Facebook

Share This Page

Share on Facebook  Send to your Twitter page  Save to  Save to LinkedIn  Digg this  Stumble this page.  Add to Technorati favorites  Save this page on your Google Home Page 

For more information

Contact Us


Help us improve

Visitor feedback helps us continually improve our site.

Please tell us what you
think with this short
(< 5 minute) survey.