Case Study

Our case study will span many of the chapters of this course. We’ll be examining a single problem closely from a variety of perspectives. It’s very important to look at alternative designs and design patterns; more than once, we’ll point out that there’s no single right answer: there are a number of good answers. Our intent here is to provide a realistic example that involves realistic depth and complications and leads to difficult trade-off decisions. Our goal is to help the reader apply object-oriented programming and design concepts. This means choosing among the technical alternatives to create something useful.

This first part of the case study is an overview of the problem and why we’re tackling it. This background will cover a number of aspects of the problem to set up the design and construction of solutions in later chapters. Part of this overview will include some UML diagrams to capture elements of the problem to be solved. These will evolve in later chapters as we dive into the consequences of design choices and make changes to those design choices.

Classification

Our users want to automate a job often called classification. This is the underpinning idea behind product recommendations: last time, a customer bought product X, so perhaps they’d be interested in a similar product, Y. We’ve classified their desires and can locate other items in that class of products. This problem can involve complex data organization issues.

It helps to start with something smaller and more manageable. The users eventually want to tackle complex consumer products but recognize that solving a difficult problem is not a good way to learn how to build this kind of application. It’s better to start with something of a manageable level of complexity and then refine and expand it until it does everything they need. In this case study, therefore, we’ll be building a classifier for the iris species. This is a classic problem, and there’s a great deal written about approaches to classifying iris flowers.

A training set of data is required, which the classifier uses as examples of correctly classified irises. We will discuss what the training data looks like in the next lesson.

4+1 architectural view model

We’ll create a collection of diagrams using the Unified Modeling Language (UML) to help depict and summarize the software we’re going to build. We’ll examine the problem using a technique called 4+1 Views. The views are:

• Logical view: A view of the data entities, their static attributes, and their relationships. This is the heart of object-oriented design.

• Process view: A view that describes how the data is processed. This can take a variety of forms, including state models, activity diagrams, and sequence diagrams.

• Development view: A view of the core components to be built. This diagram shows relationships among software components. This is used to show how class definitions are gathered into modules and packages.

• Physical view: A view of the application to be integrated and deployed. In cases where an application follows a common design pattern, a sophisticated diagram isn’t necessary. In other cases, a diagram is essential to show how a collection of components are integrated and deployed.

• Context view: A view that provides a unifying context for the other four views. The context view will often describe the actors that use (or interact) with the system to be built. This can involve human actors as well as automated interfaces: both are outside the system, and the system must respond to these external actors.