The Software Design Book

8/14/2019 The Software Design Book

1/24

The Software Design and Development BookWith UML Examples

by Mark Watson

Version 0.08 July 21, 2003

This work is licensed under the Creative Commons Attribution-NoDerivs-NonCommercial License. To view a copy of this license, visithttp://creativecommons.org/licenses/by-nd-nc/1.0 or send a letter to Creative Commons,559 Nathan Abbott Way, Stanford, California 94305, USA.

Additional license terms:

No commercial use without author's permission The work is published "AS IS" with no implied or expressed warranty - you

accept all risks for the use of both the Free Web Book and any software program

examples that are bundled with the work.


2/24

Table of Contents

>Table of Contents............................................................................................................ 2

Preface............................................................................................................................ 4Book audience............................................................................................................. 5Programming Languages............................................................................................. 5Acknowledgements ..................................................................................................... 5

Part I Rethinking Design and Software Development ................................................... 7Chapter 1. Whats wrong with current design and software development methods .......... 8Chapter 2. Economics of software development ............................................................ 11

Advantages of Open Source and Commercial Software............................................. 11Chapter 3. Job satisfaction: aligning corporate and personal goals ................................. 13Chapter 4. History of software design and development ................................................ 14

Structured programming............................................................................................ 14

Object oriented.......................................................................................................... 14Design patterns.......................................................................................................... 14Extreme programming............................................................................................... 15Aspect oriented programming ................................................................................... 15

Chapter 5. Introduction to UML.................................................................................... 16Use Case Diagrams ................................................................................................... 16Class Diagrams ......................................................................................................... 17Sequence Diagrams................................................................................................... 18

Chapter 6. Example UML Process: Developing an Automated Help Desk System ........ 19Iterative Design and Development............................................................................. 22

Chapter 7. Model View Controller Design Pattern......................................................... 24

>

Preface

Part I Rethinking Design and Software Development

1. Whats wrong with current design and software development methods2. Economics of software development3. Job satisfaction: aligning corporate and personal goals

Part II Fundamentals of Design

4. History of software design and development5. Common design pattern used in this book6. Introduction to UML7. Importance of iterative development8. Use case analysis


3/24

9. Designing classes10.Object interaction diagrams11.Design patterns an overview.12.Design patterns for GUI applications.13.Design patterns for web services.

Part II Example Design Projects

14.An Automated Help Desk System15.Socket based client server models16.SOAP based web services17.Separation of content and control when creating dynamic web content18.Abstraction layers between application code and relational database access19.Model View Controller design pattern for GUI applications20.Model View Controller design pattern for web based applications


4/24

Preface

The complexity of information increases faster than our ability to organize and use it toincrease efficiency and profit. We have lived through the dot-com hype and crash and

most developers now have a more realistic view of the benefits versus costs of softwaresystems. As the complexity of information increases so does the software required toautomate information processing.

In the last few decades there have been many software design methods that have allpromised the reduction of software costs. Most software developers have been involvedwith projects that used (in historical order) the waterfall method, structuredprogramming, object oriented programming, various object modeling languages, andperhaps the most recent Unified Modeling Language (UML). Most developers will tellyou that their mileage varied when discussing the utility and cost effectiveness ofvarious software development methodologies.

A common complaint with methodologies that promote formal up front design is that thedesign process and documents are not kept up to date during software development.Modern design tools do promote round trip engineering to keep model designdocuments and code in sync but many projects still ignore the maintenance of designdocuments in the rush to get projects complete.

One of the great success stories in software engineering has been the series of designpatterns books. These books codify and describe the designs for common programmingproblems. Developers reuse a proven design without having had to go through thenormal process of making mistakes and then learning from these mistakes.

In this book we will look at design practices that make sense in the reality of todayseconomy.

This book is a hybrid, combining new ideas for a lightweight approach to using UML fordesign and discussing in cookbook fashion design recipes for a few problems that moderndevelopers face. These six design problems will be discussed in the proposed book:

Socket based client server models SOAP based web services Separation of content and control when creating applications with both dynamic

web content and standard GUI user interfaces Abstraction layers between application code and relational database access Model View Controller design pattern for GUI applications Model View Controller design pattern for web based applications

The goal of this book is to encourage the reader to step back and reevaluate how theydesign and write software systems. The great computer scientist Edsger Dijkstra, whodied recently, once said Computer science is as much about computers as astronomy is


5/24

about telescopes. That is not simply a glib remark! Talk to successful software designersand developers and they will probably tell you that they do their best work in design andproblem solving away from their computer, often taking a walk with colleagues or sittingoutside with a pad of paper.

So, the reader is expected to think about the entire software design and implementationprocess in the first part of the proposed book and reevaluate how they do their work. Thesecond part of the book contains case studies for six design problems.

Book audience

The computer industry in the U.S. and in other countries has seen a reduction of jobs andin the start of new projects in the last few years. No one can predict the future economy(well, economists do try) but there is one certain thing: computer scientists mustcontinually educate themselves as new technologies capture the interest of the industry

and the business world. I want to help you, the reader, not by concentrating on the detailsof the newest technologies but by reevaluating how you work and the meaning and meansto productivity gains.

This book is for software developers who worry about the economy and their careers andwant to proactively do something about their fears by improving the way they design andwrite software.

Programming Languages

The only assumption that I make regarding the readers preferred programming language

is that it is object oriented. That said the examples in this book are written in Java.

Using UML is a key part of this book. For Java, I recommend the Poseidon UML editor.A free community edition is available, with professional editions also available withadded features. You can download Poseidon at www.gentleware.com. In addition tousing a specific UML tool, I also like to use OmniGraffle running under Mac OS X tocreate UML diagrams.

I believe that selecting a programming language for a project is important, but lessimportant than proper design. I use a wide range of programming languages (in order ofdecreasing use): Java, Common Lisp, Python, Smalltalk, C++, C#, PHP, and Perl. For

me, the selection of a programming language is driven by cost considerations: whichlanguage allows me to design and implement a system that will be maintainable, for thelowest cost. We will see later in the book that choosing the right infrastructure tools is asimilar and related process to programming language selection.

Acknowledgements


6/24

I would like to thank the following readers who have provided ideas for design in thisbook: . I would also like to thank the following people who pointed outtypographical errors in the manuscript: .


7/24

Part I Rethinking Design and Software Development


8/24

Chapter 1. Whats wrong with current design and

software development methods

This chapter expresses my personal opinions based on my experiences writing softwarein a variety of organizations with a wide variety of team sizes and organizations. I amwriting this book in the fall of 2002, a year or two after the dot-com bust. In mypersonal experience the dot com era helps to demarcate three eras of softwaredevelopment:

1. The pre-dot-com era was characterized by moderate spending for softwaredevelopment and a real interest in doing software development right using thesoftware development methodology that was in current vogue.

2. The dot-com period era was characterized by large and enthusiastic spending forsoftware development and less emphasis on proper software development. Iwitnessed more of a frenzy to get products to market while that market was hot.

3. The post-dot-com era is characterized by conservative spending for softwaredevelopment and uncertainty in the future of IT spending.

Sadly, I would argue that we have made negative progress! We need to get back to thevalues we used before the dot-com era while realizing that IT expenditures in todayseconomy must be made efficiently.

I have been programming since high school (for me, that is the mid 1960s) andprofessionally programming since 1973. Roughly, my experience working on mediumand large software projects falls in three categories:

1. Under designed either because of a rush to get something working or generalshort sightedness, little time was spent on design, a quick hack got somethingworking, and everyone was happy except for the people who had to maintain thesystem.

2. Good balance between design time and implementation time the just rightcombination!

3. Over design attempt to write the perfect design, not realizing that a gooddesign methodology depends on staged prototypes that affect the design process.

As you might guess, I prefer category 2.

It is difficult to know how to plan software development. If, for example, you need toconvert a structured text data source into a form that can be imported into a relationaldatabase, then it is not likely that the code to do this conversion will be reused. If weknow that the results of a small project will not be reused (i.e., a one-shot project),there are obvious economies that we can make use of. For example:

1. Do not bother documenting the software.


9/24

2. Do not bother commenting the software for the benefit of future programmerswho must maintain it.

3. Worry about code correctness, not efficiency (i.e., memory footprint, runtimeefficiency).

This book is really not about one-shot coding projects, but we need to define themargins of our discussion of planning software development and using the correct designprocess. At the other end of the spectrum of software development, we might considersystems for which software failure would endanger lives (e.g., embedded medicalequipment, aircraft control software, etc.) This book is also not about designing andimplementing this class of software.

This book tries to take a Buddhist middle of the road approach: we want to developsoftware development planning and design habits for small, medium and large sizeprojects that will be reused and must be efficiently maintained.

So what is wrong with current design and software development methodologies?

I think that to some extent, fault lies with industry leaders like Sun and Microsoft.

Suns Java platform certainly has a lot going for it, especially developer loyalty.However, instead of placing resources to solve problems like too large of a memoryfootprint, runtime efficiency, and poor looking GUI applications, Sun seems too caughtup in developing and releasing too many new APIs. One of the best additions to the Javaplatform has been the Hotspot just-in-time compiler, but that technology was purchasedfrom a Smalltalk vendor (yes, it had been originally developed for a different platform!).

Java is an incredible platform for developing server side or web based applications. Still,many in the developer community are disappointed by the overall design and complexityof Enterprise Java Beans (EJBs).

Microsoft, of course, is not without their problems. Most of these problems are tied tolegacy support for COM, so-called DLL hell (i.e., earlier versions of Windows thatallowed developers to add DLLs to the system instead of green installs where all DLLscoexisted with specific applications. As a programmer, I have always dislikedautomatically generated code that is unreadable to most human beings. I do not like socalled wizards that generate unreadable code.

I spent a fair amount of time with VisualStudio.net before I started writing my lastpublished book (which covered Java J2EE technologies). I wanted to scope out thecompetition. Microsofts .Net does have a lot going for it. It makes generating webapplications easy and provides a uniform way to make both GUI and web based userinterfaces for applications. Time will tell how .Net does in the market place and how it isviewed on technical merits.


10/24

Both Sun and Microsoft are corporations that have a legal obligation to their shareholdersto make every attempt to be profitable. It is regrettable, but understandable that publiccompanies need to worry more about the bottom line than uniformly creating softwaretools to support lean/mean/economical software development.

Still, for many of the types of problems that we need to design and code for can beeffectively solved with inexpensive or free software tools that certainly meet mylean/mean/economical criteria. For example:

Java on the server, using JSP, JavaBeans, and JDBC database connections. Microsoft .Net for both Windows forms and web forms applications. Python for writing utility scripts and server side web programming. Smalltalk for server side Smalltalk servlet programming and general application

development.

These four platforms are inexpensive or free but do have a cost for training: the Java,

.Net, and Smalltalk class libraries all have a long learning curve. Knowing the syntax andgeneral use patterns for an object oriented language is of limited use if you have not alsomastered the standard class libraries for that language.

So, in this book, we will look at my own approach to solving current softwaredevelopment problems. My approach involves using simple tools that are well understoodby you the developer, and use just the right mix of up front design followed by stagedimplementations that positively affect the design process. When we build our softwareprojects, we should strive to write code that works, is easily maintained, and iseconomical to develop and maintain.


11/24

Chapter 2. Economics of software development

Writing software costs money. Even Open Source projects have a cost to participantswho either give up some of their free time to work on a project that interests them or for

companies who pay their staff to work on Open Source projects in order to gain somecompetitive advantage by also utilizing the work of other people outside theirorganization.

It is usually interesting to examine different ideas that are in vogue for reducing softwarecosts. In the 1980s, managers at my company (SAIC) seemed preoccupied withCommercial Off The Shelf (COTS) software. This was a response to customersquestioning why, for example, they spent a great deal of money paying for custommapping software instead of buying a commercial package that could be licensed for$20K. In the 1990s, the new mantra was software reuse. Software reuse is a good ideaof course, but I would argue that best practice procedures do not call for up front design

for software reuse, especially when designing and implementing class libraries for a newproject. Really, the problem with up front design for reuse is similar to the problem ofover design without iterative staged prototypes: we really need some implementationexperience to drive the requirements and design process. It is almost always better tosimply pay the price of re-implementing a class library that has proven its usefulness afterexperience using it.

Advantages of Open Source and Commercial Software

There is absolutely no question, in my opinion, that organizations can save money byeffectively using Open Source software. Strategically, the question for us to ask is howwe mix Open Source, COTS software, and custom development. Best practice calls for(usually) using Open Source for infrastructure code. Here are a few common examples:

1. Static and dynamic web content using the Apache web service software, addinga few custom CGI programs for database access, etc.

2. Static and dynamic web content for Java developers using Apache JakartaTomcat with standard JDBC database connectivity tools, adding custom JSPs,JavaBeans.

3. Small scale enterprise web applications for Java developers using Tomcat andJBoss, adding custom JSPs, EJBs.

4. A new Apple Mac operating system uses BSD Unix for core functionality,adding Apples GUI magic (I am a Mac OS X user, and definitely a little biased).

It is easy to see the common thread here: use free Open Source software forinfrastructure, adding value added code where required.

It often makes good sense to buy commercial software and tools. For example, if you livein the Microsoft Windows world, it is hard to beat the .Net framework for easily


12/24

writing web services. Some commercial applications, like Microsoft Office, are oftenused effectively as components in custom, vertical application development (i.e.,applications targeted to narrow vertical markets).

In all cases, it makes sense to devote some small fraction of a development budget on

research of available tools (both Open Source and commercial). Best practices for toolselection use the following criteria:

Cost both purchase price and training Licensing issues when redistribution is required Maturity of tools (e.g., are they industrial strength or research prototypes) Prior team experience with tools


13/24

Chapter 3. Job satisfaction: aligning corporate and

personal goals

At least in the U.S., most workers expectations of long-term employment at a singlecompany have changed. To be sure, many companies still see the high value of long-termemployees but with the increased cost of benefits the use of temporary employees andconsultants is more common than it used to be. As with many white collar jobs (e.g.,architectural design, evaluation of patient x-rays, staffing help desks, tax preparation,etc.), there has been major movement in outsourcing software development work tocountries with lower costs of living (and therefore lower salaries).

This chapter is a brief discussion based on both my experiences and those who I havetalked to on the subject of what computer professionals want and expect in todayseconomic situation.

To summarize, professional programmers and engineers want the following from theiremployers (different people have different priorities, to be sure):

Good salary Job stability Interesting work Work in technologies with a future Work environment Work location (e.g., large city vs. rural living)

Different people have additional desires for their career. It is important to understand ourown priorities and to try to live our personal and professional lives in a way that meetsour own priorities.

While it is important for workers to share their priorities with their bosses at work, thissharing of information does little good if it is not acknowledged and acted on. A goodfirst step in planning for success in meeting professional goals is to write down yourpriorities and discuss them with family members and friends. We are all responsible forour own decisions in life but that does not mean that we should not seek advice andalternative ideas.

There has definitely been a change in the information technology (IT) industry since the

dot-com bust. I argue that one very positive aspect of this bust has been that many peoplewho looked at software development as just a job have left the field. Like any career, itis important for IT workers to have a real passion for their work. (Exercise: do a websearch on Joseph Campbell follow bliss and read his philosophy on choosing a career.)


14/24

Chapter 4. History of software design and development

The history of software development methodologies is really a search for a silverbullet, that is, a search for some way to manage the complexity of software systems. My

personal take: developing complex software systems is, well, complex and therefore timeconsuming and expensive. We will look at five popular methodologies in the rough orderthat they were developed and used.

Structured programming

I was programming professionally (started in 1973) for a few years before the ideas ofstructured programming started to gel and catch on. Structured programming deals withthe correct use of block structure, procedure call statements, and various loop constructs.We had a new mantra: go-to considered harmful.

The idea that programs should be well structured with transparent, easily understood flowof control seems like an obvious idea today. I would argue that the ideas from structuredprogramming are integrated into all later methodologies.

Object oriented

Object Oriented Programming (OOP) methodology certainly grew out of structuredprogramming ideas. OOP manages software complexity by packaging code and the datathat code uses together. We are used to dealing with physical objects in the real world. InOOP, we sometimes model real world objects (e.g., writing simulation programs, where

OOP concepts were first developed) as software objects and also model non-materialthings like processes, ways to organize information, etc. as software objects.

A software object maintains its own internal state. This is very different from structuredprograms where the code may have been laid out in a structured and easily understoodway, but global shared data was available to all parts of a software system includingthose parts with no real need to access or to modify the data.

Design patterns

Intelligent people notice patterns in their worlds. As children, we might have noticed thatclassmates who exhibited patterns of good study habits earned better grades. When welearned to cook, we might have noticed that experienced cooks had work patterns likepreparing ingredients before starting to cook, frequently tasted food as they added spices,etc.

In software development, the use of design patterns is based on observations that somesoftware projects fail while similar projects are successful (these could be management


15/24


16/24

Both the free Eclipse Java IDE (www.eclipse.org) and the commercial IntelliJ Java IDE(www.intellij.com) support AspectJ. Aspectj is an extension of the Java language andrequires preprocessing. Note: even though I have been following AOP for a while, I havenot yet used it for a real project.

Chapter 5. Introduction to UML

In this chapter we will briefly cover the basic ideas of UML and object modeling. In thenext chapter, we will look at the UML models for a simple commercial product that Iwrote (a help desk system). It would be best to read this and the next chapter in onesitting because we will not see actual diagrams in this chapter you have to wait forChapter 6.

I got my introduction to Object Oriented Modeling (OOM) by using Grady Boochsmethodology. I was writing a series of C++ books for McGraw-Hill at the time, andGrady sent me a (hand marked up) copy of his manuscript for a book on OOM. At the

time, there were over ten different methodologies a literal Tower of Babel situation indesign notations.

UML borrowed ideas from the Booch notation, Rumbaugh notation, and Jacobsonsnotation. UML is now widely accepted as the standard notation for performing OOMactivities.

Most books on UML (e.g., the book Paul Harmon and I wrote, Understanding UML)go into some great detail on all UML diagram types. My approach here is a littledifferent: in my own work, I find myself usually only using three types of diagrams andwe will only discuss these three types of diagrams here:

Use Case describes how users of a system interact with it Class documents the public and (optionally) private APIs for a class Sequence shows how objects of different classes interact as a function of time

A word of warning: be aware that we are just looking at the most commonly used aspectsof UML in the web book; if you will be using UML with other team members, they arelikely to want to use additional types of diagrams. That said, this chapter exposes you tothe basics and provide a good starting point.

Use Case Diagrams

Even programmers who do not like to perform a lot of up front design work will find usecase diagrams a very effective method to both understand customer requirements and as atype of contract between you and your customers. Like all aspects of good design, usecase diagrams not only will help you to reduce the costs of writing all but the most trivial


17/24

programs, they will also serve as insurance that you are developing what your customersreally want. In the next chapter, we will see an example use case diagram (Figure 6.1).

As a developer, you will base the use cases that you write on conversations with yourcustomer. A set of use cases can be refined until both you and your customer agree on the

way that a system will be used and, in keeping with the philosophy of ExtremeProgramming, can be used to define test cases early in the development cycle.

A good alternative to using UML modeling tool to create use case diagrams is to use 3x5cards. Write a (very) brief description of each use case on a separate 3x5 card.

In either case, the idea is to develop a set of independent example uses of the systemunder development.

Class Diagrams

Class diagrams are used to show both the APIs for a class and internal data and also toshow the relationships between classes. I find class diagrams to be most useful when usedto get a top-level overview of the major classes in a system and how they inter relate. Fora complex system implemented with hundreds of classes, I do not think that it makessense to produce class diagrams for all classes.

Most UML modeling tools (e.g., Poseidon) offer round trip capabilities: if you alreadyhave source code, then they can import the source code and automatically producediagrams. If you modify a diagram in the modeling tool, for example: adding a fewmethods and extra class data, then the modeling tool can automatically update your

source code.

If I need to quickly produce high-level UML class diagrams for a new project, I find itfastest to use a text editor to write skeleton code (i.e., just method signatures and datadefinitions) for the top level classes and import this source code into my UML modelingtool. I use the tool to clean up the layout of the diagrams, and tweak the initial classdesign before allowing the modeling tool to update the original source code.

While I find modeling the high level classes for a new project useful, I also have a wordof warning: design is far from a perfect science. You will be modifying your design asyou get experience implementing the system. For this reason, I prefer for my own work

to cycle between design and implementation work. Too much up front design time can bewasted if during early implementation you discover errors in requirements analysis(which I consider part of design, not a separate step) or design that requires largemodifications. I consider best practices to be a cyclical development style.

Figure 6.2 in the next chapter I an example of a top-level class diagram for an automatedhelp desk system.


18/24

Sequence Diagrams

Sequence diagrams are a great way to understand and to explain to other people how theobjects in a system inter relate as a function of time. The utility of sequence diagrams isincredible for at least three reasons:

1. Allows developers to really understand the time-sequenced interaction betweensystem objects.

2. Allows technically oriented customers to get a better understanding of how thesystem will function.

3. Allows developers to identify failure points and facilitates setting up test cases.I personally consider UML sequence diagrams as the big win for UML that does themost to justify the time required for UML modeling. We will see an example sequencediagram in Figure 6-3.


19/24

Chapter 6. Example UML Process: Developing an

Automated Help Desk System

For the first example design, we will look at a recent project that I designed andimplemented: an automated help desk system. This is a good example both because it isrealistic (it is a real product that my company sells and uses at www.markwatson.com)and because it is a good example of a web based application. This system is implementedas a Java servlet.

Regardless of whether you are designing and implementing a commercial product or anOpen Source project, or an in house project, or a project for a customer I recommendstarting with this process:

1. Describe briefly how people will use the new system (one or two paragraphs)2. Create one or more UML use case diagrams showing how the end user interacts

with the system (note: if the new system is, for example, a back end serverapplication, then the use case diagram could show how other system componentsinteract with the new system)

3. Talk with users of the new system, customers, etc. to make sure that they agreewith the preliminary use description and use case diagram(s).

Here is a two-paragraph concept summary for the new product:

The automated help desk servlet initializes by reading an XML document thatcontains product information. This XML document format is easily edited to addnew products and product FAQ information.

The users of the help desk access it by using a URL. There are three primaryways to use the help desk: view the complete table of contents for all productinformation, use key word search to find FAQs for a specific product, and to usenatural language queries to search for information for a specific product.

Figure 6.1 shows three end-user use cases for the help desk system.


20/24

HelpDesk Systemuser 1

user 2

user 3

XMLinitialization

datafile

key word search

natural language query

use table of contents menu system

Figure 6.1 UML Use Case Diagram for the Automated Help Desk System

Whenever I design and implement any system that contains a user interface, the firstthing that I like to do is to cut the system in two: an engine and a presentation manager.Here, I will start by designing, then implementing, an engine that has a public interfacefor:

Initialization from the XML product configuration file Generate an HTML menu element with links for each product Generate an HTML data table for any specified product including links for each

FAQ for the product Generate an HTML data table for any specified FAQ for a specific product For a sequence of key words, return a list (in decreasing order of relevance) of

FAQs for a specified product For a natural language query, return a list (in decreasing order of relevance) of

FAQs for a specified product

The public API for this interface is a contract with the presentation manager. We willbe free to change the internal implementation of the engine class at will withoutbreaking the system.

Figure 6-2 shows a detailed UML class diagram for the engine part of the help desksystem. We show classes as a box with three vertical panes: name of class, listing of class


21/24

attributes, and listing of class methods. For high-level class diagrams, I often only specifythe class name and leave the attributes list and methods list blank. It is often useful to listjust the attributes (for data oriented classes like Faq and Product). A negative signpreceding an attribute or method implies that it is private while a plus sign indicates thatit is public. Since the Help Desk product was a small effort, my design efforts were hand

written on a few sheets of paper. Figure 6-2 was generated after the fact by importingthe existing Java source files into the Poseidon UML tool.

ConfigFileSAXHandler

-lastProduct : String = ""

-faqs : Vector = null

-lastTag : String = ""

~depth : int = 0

-engine : HelpDeskEngine = null

-product : Product = null

-faq : Faq = null

-shared_faq : Faq = null

+ConfigFileSAXHandler(engine:HelpDeskEngine) : ConfigFileSAXHandler

+startElement(uri:String, localName:String, qName:String, attributes:Attributes)

+endElement(uri:String, localName:String, qName:String)

+characters(in ch:char[], in start:int, in length:int)

Faq

+title : String = ""

+description : String = ""

+ID : String = ""

HelpDeskEngine

+DEBUG : boolean = false

-singletonInstance : HelpDeskEngine = null

-htmlMenu : String = null

-htmlProduct : String = null

~v_products : Vector = new Vector()

~shared_FAQs : Hashtable = new Hashtable()

~invertedWordIndex : Hashtable[] = null

~products : Product[] = null

~title : String = ""

-noiseWords : Hashtable = new Hashtable()

+main(args:String[])

+getInstance() : HelpDeskEngine

+HelpDeskEngine() : HelpDeskEngine

-loadConfigFile()

+getHTMLMenu() : String

+getProductHTMLTable(in productIndex:int) : String

+getFaq(in productIndex:int, in faqIndex:int) : Faq

+getNumProducts() : int

+getProductNames() : String[]

+getFAQIndices(in productIndex:int, keyWords:String[]) : int[]

+getFAQIndicesFromQuery(in productIndex:int, nlQuery:String) : int[]

+getTitle() : String

-createWordIndices()

-readWords(counts:Hashtable, faq:Faq, in faqNumber:int)

+wordsToArray(s2:String) : String[]

-makeNoiseWords()

Product

+name : String = ""

+cost : float = 0

+faqs : Vector = null

+shared_faqs : Vector = new Vector()

containscontains

containscontains

usesuses

Figure 6-2. UML Class Diagram for the Help Desk Engine

There is an important point here: developing software is a complex task; here, we haveeffectively partitioned the job into two loosely connected tasks (i.e., developing the anengine and a presentation manager) that can be written and debugged separately. With thepublic interface defined between these two parts of the system, we can proceed with the


22/24

design, implementation, and unit testing of the engine without too much concern for thefuture task of designing, implementing, and testing the presentation manager.

There is another fairly obvious advantage to splitting the problem into two pieces: wemight in the future want to create a standalone application for the automated help desk. In

this case, we could set aside the presentation manager that is implemented as a Javaservlet and write a new presentation manager with, for example, the Java Swing library.

Figure 6-3 shows a UML Sequence Diagram showing the interactions between a user(using a web browser), the HelpDesk servlet, and the HelpDesk Engine. Arrows representrequests or returned values from objects. This is general purpose: an arrow can be amethod call between objects in the same Java Virtual Machine (JVM), a remoteprocedure call, etc. Time increases going down the page when looking at a sequencediagram.

Figure 6-3. UML Sequence Diagram for Help Desk System

Iterative Design and Development

It is difficult to know in advance all the features that a software system needs in order tobe most convenient for users. As an example, after I did the preliminary requirementsanalysis in the last section for the help desk system, I started designing and coding the


23/24

engine module. As part of this effort, I set my emacs editor in XML mode and startedto create an XML initialization file for the products on my www.markwatson.com webpage. I quickly realized that there would be many common FAQs for several of mynatural language processing products.

My first thought was to implement an inheritance scheme for products. However, thisseemed to violate a basic object oriented concept: subclasses should obey an is a typerelationship with a super class. For example, a car is a type of vehicle. However, it didnot seem right to create dummy products that would be super classes of real products.

I decided that a simpler approach was better: independent of product definitions in a helpdesk XML initialization file, use a separate tag type, a FAQ set. Common FAQs can bedefined in a FAQ set and any given product can simple list the FAQ sets that it uses.


24/24

The Software Design Book

Documents

Transcript of The Software Design Book