Just Another Teaching of Software Engineering (2006-07)

This website archives the teaching and learning of a Software Engineering course. It supports teaching and learning during the course of study (September 2006 to May 2007). After the course, it is an archive for reference and sharing.

Seasonal Greetings

To MT356F Students   To MT356F Students

To MT356F Students   To MT356F Students

Course Test

The course test is scheduled on the first meeting after the semester break. Well plan your time for your revision. The test will be close-book, 2-hour session, and cover the following topics.

  • Chapter 1: Introduction to Software Engineering
  • Chapter 2: Modeling with UML
  • Chapter 4: Requirements Elicitation
  • Chapter 5: Requirements Analysis
  • Chapter 6: System Design: Decomposing the System
  • Chapter 7: System Design: Addressing Design Goals

Lecture#11: Review

In this lecture, you will have a review on

  • Chapter 1: Introduction to Software Engineering
  • Chapter 2: Modeling with UML
  • Chapter 4: Requirements Elicitation
  • Chapter 5: Requirements Analysis

Read more…

Where have we been, where are we now, where are we going?

Hi MT356F students:

Times pass very quickly. Do you konw where you have been, where you are now, and where you are going. Let me give you a brief answer.

What you have done in the first semester:

  • Finished studying of Chapters 1, 2, 4, 5, 6, 7, and 8
  • Did and submitted Assignment One (Earned 0-10 points)
  • Did and submitted Software Project Proposal (Earned 0-10 points)

What you shall do in the second semester:

  • Attended a mid-term test (10 points)
  • Continue studying other topics of Software Engineering
  • Do and submit Assignment Two (10 points)
  • Do and release your Software Project deliverable (10 points)
  • Review the course and sit the final examination (50 points)

Tutorial#12 The Strategy Pattern

In this tutorial, you will do a practical exercise about the Strategy pattern.

The Strategy pattern is one of the most fundamental design pattern. It embodies two object-oriented design principles—encapsulate the concept that varies and program to an interface, not an implementation.

The Design Patterns authors define the Strategy pattern as:

Define a family of algorithms, encapsulate each one, and make them interchangeable. [The] Strategy [pattern] lets the algorithm vary independently from clients that use it.

The following suggests a good article for you to learn the Strategy pattern. It first illustrates how Swing uses the Strategy pattern to draw borders around its components. Then it discusses how Swing benefits by using the Strategy pattern, and finally it explains how you can implement the Strategy pattern in your own software.

Strategy for success: The powerful Strategy design pattern aids object-oriented design (By David Geary, JavaWorld.com, 04/26/02)

Discussion: Suppose JComponent.paintBorder() method use switch-case to handle drawing borders around its components, instead of using the Strategy pattern. What you need to do if you tried to implement a new border type? What are the difficulties that you will be faced with?