Software Design Specifications with UML
Michael W. Bigrigg, Copyright
2004-2007
UML: Introduction
Use Cases: Actors |
Goals | Scenarios
Activity Diagrams: Overview |
Part 1 | Part 2
State Charts: Overview |
Part 1 | Part 2
Deployment Diagrams: Components |
Nodes | Communication
CHAPTER 1 Introduction
I had an electronics professor tell me to just look at the circuit and I would understand what voltage to apply. I stared and stared and nothing came to me. The problem was that I was not so familiar with the process that I could intuitively understand what to do. I knew formulas and the basic principles. But much of it was just how it feels. I eventually learned electronics by constantly doing it. System design is similar as you have to see it enough that you eventually develop an understanding of how it works. But before you can do that you really want a step-by-step methodology to follow to get you to the answer. The answer might not be the perfect one but it is a reasonable and good answer. This book is designed to give you a method of approach for the process of software engineering rather than making you have an intuitive understanding of what to do.
The standard approach to system design is top-down, namely problem decomposition. We take an initial problem and decompose it into smaller problems that we in turn decompose into smaller and smaller problems. The decomposition of a problem is hard to explain. What is the right size of a problem? When do we stop decomposing it? How do we find the smaller problems? We will take a bottom-up approach because we need a method to follow that will allow us to create our design without having to rely on an intuitive understanding of how to solve problems.
This book is suitable for sophomore students all the way to graduate students as well as professionals. This can be used as a supplemental to a traditional software engineering book.
The Effort is Important
The process of design is as important or more important than the end product of design. You need to slice up the problem. You need to look at it from many different points of view. We may start out thinking that we understand everything about the problem, but we don't. The software design process will help us to uncover the issues we aren't aware of yet. We could run into the issues at implementation or upon review by the client. It is better if we can find and desl with the issues early on namely during the design process. The method presented here emphasizes the different facets of the Unified Modeling Language (UML). UML is not one single tool, but an entire toolbox. I claim that we must use all the tools to be able to come up with a solid design.
FIGURE 1. Multiple Facets of Problem Analysis
Software design process using UML is like study methods for an exam. I used to just sit and stare at the book. I really wasn't absorbing any more material the longer I sat and read my book. What I needed to do was to outline the reading, to recopy my notes, to come up with sample questions. I needed to do something. By mixing up the task you can start to see things that you didn't notice before.
These UML tools are not the same though some overlap in the problems that they identify. There is a subset that is a static view of the system with others being a dynamic system view.
FIGURE 2. Design Views
The user may think he/she is very clear in describing the system the designer and developer is to create. There is a picture in his/her mind of what is to be produced. The problem comes in when we do not attempt to capture and implement what is in our client's mind but instead we head on off building a system based on what we have in our mind. If the designer does not capture what the user wants the developer will in turn not implement the correct system.
Software design has gotten a bad reputation as it is hard to quantify its schedule. How long will it take to come up with a design? It is also very difficult to quantify how far along in the process you are and when are you likely to finish. The reason for a bottom-up approach combined with an explicit number of UML tools is that we can quantify our process of design. I am using eight UML tools in a specific order. I will outline explicit activities to follow using each tool so that the design process will not take an unbounded amount of time.
Contrast to civil engineering, should we start to build a bridge before we know what we're building. Too often in software development, we want to jump right into the programming before we have a clear vision of what to build.
Outline
We will be focused as much on the process of designing good software as we are the design itself. Many people jump into the inside view of the software as the means of design. We will start off by looking at the outside of the product to obtain a good understanding of what the software should do before we focus on the problem of how to accomplish it.
Problem Statement
A gradebook is an electronic program that allows a course instructor to keep track of the student scores such as tests, quizzes, and home work assignments. An instructor teaches many courses and students take many courses. The teaching assistant (TA) assigned to a course section may enter or modify scores, but only the instructor can assign a grade. A course may have many sections and is cancelled if there are less than 5 students in a section. If more than 35 are registered for a section a second section is offered. The students should be able to see her/his own scores and also the averages, but not the scores of other students. Once a final grade has been assigned the TA may no longer update any scores.
This is an example of the kind of problem statement you will get from a client. They have a general idea of what they want on paper. We will use this one problem statement throughout this book as our running example.