METHODS & TOOLSorganization lean and mean. This is especially critical in an Extreme Programming environment or anywhere the ratio of developers to testers is high. • Evaluate tools

METHODS & TOOLSGlobal knowledge source for software development professionals ISSN 1023-4918Spring 2001 (Volume 9 - number 1)

Oops! It Did It Again...

There is a recurring phenomenon in the software development industry that you have surelyexperienced. I will call it the "New Thing". Like the famous silver bullet mentioned by FredBrooks in 1975, we are continually seeing new items being presented as a "must have" solutionto improve the software development practice. Living in a technological sector, it is normal thatwe have a continuous evolution of our methods and tools and I will not discuss here of thepertinent values of the last elements presented as "the solution du jour": Java, e-commerce, B2Bor XML to name a few of the recent ones. Some of these concepts or products have advantages,even if few could be considered real revolutions. I would rather discuss how these items arrivein the limelight before to fade away when a new New Thing takes the power.

This phenomenon could be amusing if it is not causing repeatedly some casualties in the ITdepartments. However, these manipulations of hype also produce some concrete benefits forsome members of the software development community. Who are the people that benefit themost from this phenomenon? First, you have the research firms. Surprisingly, the same GarfieldGroup that announces that the value of the m-commerce will achieve 100 billion of dollars in2007 has also the consultants to help you manage the transition to this new technology. Strangecoincidence? There are also the consultants and the software vendors that want to sell their newor upgraded services and products. You will also find some company's technologists that arevery competent to on how to produce successful projects with new tools, but the only softwarethey really master is PowerPoint and the only people they talk to are research analyst or highlevel managers. Finally, there are also the journalists. It is more easy to make headlines with them-commerce phenomenon (and to find consultants and vendors to interview on the subject) thanto dig on the lack of test training in the users' ranks.

We must evolve and most of us like to change and learn new things, but stop saying that a NewThing will save the IT world. Miracles should not be linked to annual 15% maintenance fees.

InsideQuality: Introducing QA in a Web Startup.............................................................................. page 2

UML: Database Modelling...................................................................................................... page 10

Quality

Methods & Tools * Spring 2001 * Page 2

Much has been written, in this newsletterand other publications, about the risks of e-Business applications. "Web-time" is awidely acknowledged phenomenon. We allagree that quality is imperative for an e-Business, as all the competition is just a clickaway. Unfortunately, most of us can agreethat a Web startup is not an environment inwhich quality testing is typically found.

Development is fast and loose. Manydevelopers are inexperienced. Marketing ispushing to be beat the competition to market.The rules change every day. An e-Businessneeds to respond immediately to marketpressures. And an e-Business cannot affordpoor performance or that big revenue drain,downtime.

I have now survived bringing qualityassurance (QA) and testing to two startups -one an e-Business, TRIP.com, the other asoftware development shop, Tensegrent. Bysharing my experiences, I will provideguidelines for successful implementation ofQA and testing in the startup environment.

When I accepted the opportunity of being thefirst test engineer at TRIP.com, the startupconsisted of 25 employees. The developershad produced some exciting applications andfelt they were ready to "grow up and playwith the big boys." The development teamthought they were intellectually prepared tointroduce standards and procedures.

In reality, development was frenetic, and thedevelopers didn't have a clue as to how tostop and analyze their processes, much lesshow to impose discipline on them.

What's worse, the wide wild world of theWeb was completely new to me. I truly feltlost in the wilderness without a map. Mybackground was in testing traditional

software in mid- to large-sized softwarecompanies. I had worked on every possibleplatform and operating system, testeddatabases and client/server software, butknew nothing about Internet applications. Iknew my customers' needs. I was used todevelopment cycles of several months -during which your typical Web applicationhas gone through numerous incarnations.

Using the strategy I will outline below, Iovercame these limitations. I collaboratedwith the software and product developersand marketing managers to implementdevelopment standards and project processesthat build quality into the applications.TRIP.com now employs over two hundredpeople and has over four million registeredcustomers. It was acquired in March, 2000for $326 million by Galileo International Inc.

Recently I moved on to Tensegrent, gettingin much earlier in the lifecycle of a startup - Iwas hired in the second month of thecompany's existence, the 10th employee andthe first Test Engineer. Tensegrent isdevoted to developing high-quality softwarethrough the use of the eXtreme Programming(XP) technique. The good news was that XPinvolves intense unit and integration testingon the part of the developers. The bad newswas that the role of the Test Engineer wasnot well-defined.

Any startup or DotCom is a work inprogress. Even once we had a successfulproject process at TRIP.com, we facedcontinual challenges such as an inadequatetest environment. Even when the wholecompany understands and is committed tothe importance of quality assurance testing,unexpected events lead to surprises. The keyis to keep plugging away at the followingtasks:

Uncharted Territory: Introducing QA in a Web Startup

Lisa Crispin, Senior QA Engineer, Tensegrent, http://www.tensegrent.com

Quality


• Get Buy-In

• Work Smart

• Define Processes

I. Get Buy-In

I won over my managers, developers, andmarketing counterparts by following thesetenets:

• Identify a top manager in yourorganization who believes in your causeand will champion it. At TRIP.com, itwas the Vice President of WebDevelopment and Chief Cat Herder (yes,that really was her title). When I washired, this person did not believe that fivedevelopers could keep one tester busyfull time. But, in time, she became mybiggest ally. She not only pushed thedevelopers to work for quality, but shealso lobbied the management team fortesting resources. At Tensegrent, the staffwas actively committed to quality, but I

needed help from the General Managerto get them on track.

• Partner with someone outside of yourorganization, such as a project oroperations manager. Educate your ally togarner his or her help. At TRIP.com, wehad a topnotch project manager who,once she understood what QA and testingwould do for the company, did much ofmy job for me. She enforced processessuch as document review and signoff,helped implement and police the defecttracking system, and tied up a milliondetails involved with every bigproduction launch. She became the primechannel of communication betweenmarketing and development. AtTensegrent, our team was the wholecompany, at the beginning; the teamcaptains were key to enforcing process.

• Educate everyone you come into contactwith at the company about softwarequality assurance: what it is and what it

http://www.componentsource.com/default.asp?MTC=METO

Quality


will do for them and the products. Earlyon at TRIP.com, I held a "Lunch 'n'learn" professional development seminar.The company bought lunch, soattendance was good. I explained whytesting is essential and what it involves.At Tensegrent, I held a similar BrownBag session where I demonstrated theautomated test tool to the developers.Lots of meetings and one-on-oneencounters are needed to get everyone onboard and to establish priorities.

• Support Information Systems, the groupthat administers the production site.These people (or person, if yourcompany is really small) will benefitfrom not having their pager go off somuch when applications are tested beforebeing launched to production. The VicePresident of Technology and the ISdirector at TRIP.com fully supported meand refused to launch any update that hadnot been fully tested. This kept the rest ofthe organization from steamrolling overme, giving me a chance to prove thevalue of testing. I don't bug IS for thethings I can do myself, but I let them dotheir job. For example, at TRIP.com, Iinstalled Y2K patches on the testmachines, but IS controlled all the UNIXand NT account management.

• Understand the developers' point ofview. You may have young, brilliantdevelopers who don't communicate inways you are accustomed to. TRIP.com'soriginal developers were mostly veryyoung and inexperienced. Some had notfinished high school!. Others weren't oldenough to drink! The culture was anti-corporate, and they said what was ontheir minds. I found that if I listened, Ilearned, and they in turn were willing tolisten to my ideas. I learned everything Inow know about Web applications fromthe developers themselves.

• Celebrate success. At TRIP.com, Ipresented a "Quality Hero" award eachmonth to a developer who tookexceptional measures to prevent defects

and improve quality. The prize was just aNerf gun and the developer's nameengraved on a plaque, but it raised thevisibility of high quality process andtechniques. At Tensegrent, I try to makesure the celebratory end-of-iterationFoosball games occur AFTERacceptance testing is successfullycompleted!

• Brainstorm with developers and othersabout problems that may not come out intesting. For example, I didn't know that ifyou change a URL, search engines maynot be able to find your site. When weimplemented a content management toolat TRIP.com that required changingevery URL, this was importantinformation!

II. Work Smart

Here's my advice for making the testingorganization lean and mean. This isespecially critical in an ExtremeProgramming environment or anywhere theratio of developers to testers is high.

• Evaluate tools. Put as much time as youcan into tool evaluation, such as those forautomated testing, defect tracking, andconfiguration management. Identify thevendors who can help you the most, andget as much information from them asyou can. Ask fellow testers for theirrecommendations and experiences.Install new tools and try them out. Selecttools that are appropriate for you andyour company. It doesn't do any good tobuy a tool you don't have time to learnhow to use, especially if your testingteam is small. I ended up choosing toolsthat are lesser known but still meet ourneeds. For example:

• For automated testing, bothTRIP.com and Tensegrent useWebART (www.oclc.org/webart), aninexpensive, easy-to-learn, butpowerful tool sold by OCLC Inc. (anon-profit company). The vendorgave me valuable advice andprovided insights about Web testing.

Quality


Pick everyone's brain, includingvendors!

• For defect tracking at TRIP.com, wechose a Web-based tool, TeamTrack(now called TTrack), from a startupcompany called TeamShare . It, alsowas far less expensive than itscompetitors, but it was easy toimplement and customize. AtTensegrent, which is a brand-newstartup on a small budget, we use thefree Bugzilla successfully.

• For configuration management, atTRIP.com we again turned to asmaller, innovative company whichproduces an inexpensive, easy toimplement and learn yet robust tool,Perforce. At Tensegrent, we usefreeware, CVS - it lacks somefeatures, but the development team issmall and can work around itsdrawbacks more easily.

• These tools won't necessarily meetyour needs - just be open and creativewhen evaluating tools. Investigatealternatives - for example, if youcreate unit tests to reproduce eachbug you find in testing, you may noteven need a defect tracking system!

• Design automated tests that work foryou.

Automated acceptance tests atTensegrent and TRIP.com use thefollowing criteria to provide useful testswith minimum resources:

• Modular and self-verifying to keepup with the pace of development in"Web-time".

• Verify the minimum criteria forsuccess. Make sure the developerswrite comprehensive unit tests.Acceptance tests can't cover everypath through the code.

• Perform each function in one andonly one place to minimizemaintenance time.

• Contain modules that can be

reused, even for unrelated projects

• Do the simplest thing that works.This XP value applies as much totesting as to coding.

• Report results in easy-to-readformat. Create easy-to-read reportsfrom your test results and post themso that everyone can monitor statusand keep the project on track. Theproject team will gain confidence asthey see the percentage of successfultests increases.

In addition, the developers try to designthe software with testability in mind.This might mean building hooks into theapplication to help automate acceptancetests. Push as much functionality aspossible to the backend, because it ismuch easier to automate tests against abackend than through a user interface.

• Search the Web for resources. I wouldhave quit TRIP.com after a week if I hadnot found an excellent Web site thatpoints to information about testing Webapplications and lists of tools. Thesesites, in turn, led me to more tools andinformation Here are some examples:

www.softwareqatest.com/index.html

Everything from basic definition andarticles on how to test Web applicationsto comprehensive lists of Web tools tolinks to other informative sites.

www.kaner.com/writing.htm

Articles by Cem Kaner

www.crl.com/~zallar/testing.html#Kerry

long lists of associations, vendors, tools,training, reference information,conferences, interesting papers.

www.testingcraft.com/cgi-bin/wiki.cgi?FrontPage

a Wiki forum for exchanging testtechniques and the related

www.egroups.com/group/testingcraft-discuss

User conferences are invaluable for bothinformation-gathering and networking.

Quality


• Hire good help. It proved impossible atfirst to find experienced test engineers inour area, so at TRIP.com we hired brightbut inexperienced people with the rightqualities that make good test engineers:enthusiasm, dedication to the end user,and determination. A caveat:inexperienced testers who have noprogramming experience have a hardertime learning a scripting language for anautomated test tool. However, by using acombination of outside classes, hiringconsultants and patient, one-on-onetraining, our testers learned UNIX, SQL,test scripting, HTML, configurationmanagement, and other technical skills.You're going to spend money either way- paying high salaries for experiencedtest engineers, or training novice testers.Once you've turned them into pros,remember to keep them challenged,happy and well-compensated so othercompanies don't poach them!

• Get input about quality from alldepartments in the company. AtTRIP.com, I formed a quality board withmembers from sales, marketing,customer support and travel to gatherfresh ideas about error prevention andprioritization of regression testing.Whenever a crisis occurred, we held aquality review panel whererepresentatives from development andinformation systems heard shortpresentations from the people whoexperienced and fixed the problem. Thepanel studied the issues andrecommended steps to prevent suchproblems from recurring. This was a bigeffort and to be truthful, it was difficultto get follow-through. But give it a try.We also held post-mortems after allmajor launches to see what lessons couldbe learned. By employing these methods,we learned some valuable lessons!

• Insist on a test environment that isexact replica of, but is entirelyindependent from, production. You can'temulate a production load without theequivalent of production hardware and

software. Since the productionarchitecture is likely to change inresponse to increased traffic and otherconsiderations, this is a moving target.The test environment will need to beupdated in synch with the productionenvironment. The architecture is key too.If the production servers are clustered,your testing had better be done in aclustered environment. If part of anapplication runs on a stand-alonemachine, it must do so in your testenvironment. Establishing and keepingup development, test and productionenvironments was a huge challenge.Even when the entire company is sold onthe idea of a proper test environment,there are business and technical reasons(read: excuses) that get in the way ofreproducing the production environmentin for testing . Don't be complacent, andnever give up. Make sure you have thebest test environment you can get foreach application going into production,and work actively with your informationsystems team to get the environment youreally need. Even small applications candeceive you. For example, at TRIP.comwe launched a simple application,SantaTracker, on Christmas Eve sokiddies could watch Santa's sleigh flyaround the country. The test environmentwas broken, so we were not able to teston the same architecture that it was torun in production, but we weren'tconcerned. After all, it should haveworked exactly like our regularFlightTracker application! Right?Wrong! It was a disaster!

• In short: Dig your heels in and refuse tolaunch until some semblance of a testenvironment is established. Remember, itis harder to get the test environment oncethe new application is in production.Make it a requirement of release.

• Learn about the development toolsand processes. They present their ownquality issues and offer some solutions,too. For example, the first version of ourcontent management tool did not have

Quality


any version control. It took more than ayear to upgrade to the release that offeredthis capability, and even then it didn'tenforce version control. We had toconstantly police the process to ensurethat developers version their code. Thesoftware on which our Java applicationswere based had complex configurationparameters we didn't fully understandwhen we first put it into production. Wehad tested our intelliTRIP product with aproduction load in terms of transactionsper second, but never with a realisticnumber of concurrent users. As a result,the servers kept crashing on the first daywe put it in production. If we hadunderstood the configuration and the usersession management parameters better inour Java-application management toolbetter, we could have prevented thisproblem. At Tensegrent, a deepunderstanding of the XP process hasproved to be essential. A project can gooff track in a matter of days. My job is tohelp keep it on track by participating indevelopment as much as possible.

III. Define Processes

Collaborate with your counterparts toformalize your processes:

• Get control of the productionenvironments. Work with yourinformation systems team to create aproduction update procedure. When Istarted at TRIP.com, developerslaunched their own changes toproduction. It was hard to wean themaway from this bad habit. Even after wethought we had implemented goodproduction update procedures, we lackedthe discipline to enforce it underpressure. For example, since we did nothave good configuration management, itbecame impossible to build baselines ofintelliTRIP, so developers would simplymove new classes into production to fixproblems. Only after two years were weable to require developers to buildscripts and installation documentationbefore we accepted any software from

development for testing. At Tensegrent,we started this good habit at thebeginning. If you can get in on the verystart of a start-up, implementing bestpractices is much easier.

• Get involved from the beginning of eachproject. This is hard work. It forces youto juggle many tasks, but it is essential.See Figure 1 for a sample overview of aproject process. Participate in alldocumentation reviews: Those forrequirements, functional specifications,and design specifications. Make sure thedocuments are complete and clear. Lookfor ambiguities, gaps, lack of detail. Allparties, including marketing,development, test, customer support,sales must agree on a vision for theproduct. This vision is a short phrase thatdescribes the main thrust of the product.With intelliTRIP, development and testwere told to produce a server-sideversion of the original client-side productas quickly as possible. Sales andmarketing believed that the purpose ofthe product was to quickly locate faresfrom airline Websites. Sincedevelopment and test wasn't told that partabout quickly, and was focused only ontime to market, we released the producteven though we knew that is wassometimes slow to return results. Thistype of disconnect can be prevented byincluding a vision statement in therequirements.

• Define quality. Work with marketingand product development to definequality for each product: Should thepriority be good, fast, or cheap? (Youcan only have two of the three!) Even ifyou choose fast, don't sacrifice theprocess. At TRIP.com, we onceimplemented a promotion that marketingbelieved to be simple and wanted to rushto production. Since the product managerdid not hold documentation reviews andget signoff, the HTML pages producedby the developers had to be changedthree times. This took much longer than adocumentation review meeting. There isno need to get bogged down in process

Quality


either. If you find that is happening,change the process, or train people howto use it properly.

• Document the internal processes of bothtest and development. You can't expectmarketing and product development tofollow best practices if you don't do ityourself. At TRIP.com, one of thedevelopment directors, with the help ofthe technical writer, led an effort todefine and document the developmentprocess. An aside: No matter the size ofthe company, unless you are using alightweight technology such as ExtremeProgramming, you need at least oneexperienced, skilled technical writer inyour development organization. See

Figure 2 for a sample SoftwareDevelopment process.

• Enforce the process. If your QA team islarge enough, dedicate one person toadministering and enforcingconfiguration management and deliveryof installation scripts and documentation.At TRIP.com, we expanded thisConfiguration Manager role to that of adeployment engineer who works closelywith developers to produce the buildsand installation procedures. Don't acceptsoftware to test if it is not accompaniedby all the documentation and softwareyou need to promote, test, and launch itto production.

ProjectPlaced inProduction

ProjectEvaluation

Define

Design

Develop

Deploy

Key Deliverables- Concept Proposal- Business Requirements- Technical Approach

Key Deliverables- Functional Requirements- UI Design- System Design- Test Plan- Project Plan

Key Deliverables- Product- Acceptance Test Results

Key Deliverables- Launch Announcements- Product Support- Project Evaluation

Figure 1: Sample Project Process Overview

Quality


• Innovate! Look for new ways to presentdocumentation such as functionalspecifications. Web applications requirea new approach. You have creativepeople at your company who can help!Get input from as many different groupsas you can. If your company really wantsto get innovative, consider lightweightmethodologies such as ExtremeProgramming (seewww.extremeprogramming.org.). Thesemethodologies can meet the need to getto market quickly, accommodate rapidlychanging requirements but still release ahigh quality product.

Summary - As You Grow

All companies change as they grow beyondthe 'startup' size and environment. My teamand I endured countless frustrations whenfast growth at TRIP.com repeatedly led totemporary chaos. As your organizationgrows, educate new employees about projectprocess and quality practices. Listen to them;take advantage of their fresh outlook andnew ideas. Take the initiative. If a gap

results from a re-organization, fill it yourself.For example, when we were temporarilywithout a project management function inthe company, the TRIP.com developmentdirector and I set up a weekly tacticalmeeting with representatives from alldepartments so that everyone could stayinformed and juggle resources. Qualityassurance can be a frustrating job, especiallyin a Web startup. Pick your battles. Keepstriving for better quality. Above all, enjoythe experience!

SystemDesign

DevelopmentImplementation

CodeReview

Unit Test

FinalizeBaselineDocuments

IntegrationTest

CodeModuleFreeze

ProjectCodeFreeze

ProjectCertification

FinalTest

ProjectPlaced inProduction

ProjectEvaluation

Figure 4: Sample Development Process

UML


Introduction

When it comes to providing reliable, flexibleand efficient object persistence for softwaresystems, today's designers and architects arefaced with many choices. From thetechnological perspective, the choice isusually between pure Object-Oriented,Object-Relational hybrids, pure Relationaland custom solutions based on open orproprietary file formats (eg. XML, OLEstructured storage). From the vendor aspectOracle, IBM, Microsoft, POET and othersoffer similar but often-incompatiblesolutions.

This article is about only one of thosechoices, that is the layering of an object-oriented class model on top of a purelyrelational database. This is not to imply thisis the only, best or simplest solution, butpragmatically it is one of the most common,and one that has the potential for the mostmisuse.

We will begin with a quick tour of the twodesign domains we are trying to bridge:firstly the object-oriented class model asrepresented in the UML, and secondly therelational database model.

For each domain, we will look only at themain features that will affect our task. Wewill then look at the techniques and issuesinvolved in mapping from the class model tothe database model, including objectpersistence, object behaviour, relationshipsbetween objects and object identity. We willconclude with a review of the UML DataProfile (as proposed by Rational Software).Some familiarity with object-orienteddesign, UML and relational databasemodelling is assumed.

The Class Model

The Class Model in the UML is the mainartefact produced to represent the logicalstructure of a software system. It captures theboth the data requirements and the behaviourof objects within the model domain. Thetechniques for discovering and elaboratingthat model are outside the scope of thisarticle, so we will assume the existence of awell designed class model that requiresmapping onto a relational database.

The class is the basic logical entity in theUML. It defines both the data and thebehaviour of a structural unit. A class is atemplate or model from which instances orobjects are created at run time. When wedevelop a logical model such as a structuralhierarchy in UML we explicitly deal withclasses.

When we work with dynamic diagrams, suchas sequence diagrams and collaborations, wework with objects or instances of classes andtheir inter-actions at run-time.

The principal of data hiding or encapsulationis based on localisation of effect. A class hasinternal data elements that it is responsiblefor. Access to these data elements should bethrough the class's exposed behaviour orinterface. Adherence to this principal resultsin more maintainable code.

Behaviour

Behaviour is captured in the class modelusing the operations that are defined for theclass. Operations may be externally visible(public), visible to children (protected) orhidden (private).

Database Modelling in UML

By Geoffrey Sparks, [email protected] Systems, http://www.sparxsystems.com.au

UML


By combining hidden data with a publiclyaccessible interface and hidden or protecteddata manipulation, a class designer cancreate highly maintainable structural unitsthat support rather than hinder change.

Relationships and Identity

Association is a relationship between 2classes indicating that at least one side of therelationship knows about and somehow usesor manipulates the other side. Thisrelationship may by functional (dosomething for me) or structural (besomething for me). For this article it is thestructural relationship that is mostinteresting: for example an Address classmay be associated with a Person class. Themapping of this relationship into therelational data space requires some care.

Aggregation is a form of association thatimplies the collection of one class of objectswithin another. Composition is a strongerform of aggregation that implies one objectis actually composed of others. Like theassociation relationship, this implies acomplex class attribute that requires careful

consideration in the process of mapping tothe relational domain.

While a class represents the template ormodel from which many object instancesmay be created, an object at run timerequires some means of identifying itselfsuch that associated objects may act upon thecorrect object instance. In a programminglanguage like C++, object pointers may bepassed around and held to allow objectsaccess to a unique object instance.

Often though, an object will be destroyedand require that it be re-created as it wasduring its last active instance. These objectsrequire a storage mechanism to save theirinternal state and associations into and toretrieve that state as required.

Inheritance provides the class model with ameans of factoring out common behaviourinto generalised classes that then act as theancestors of many variations on a commontheme. Inheritance is a means of managingboth re-use and complexity. As we will see,the relational model has no directcounterpart of inheritance, which creates a

PersonPersonPersonPerson

- Address: CAddress# Name: String# Age: double

+ getAge() : int+ setAge(n)+ getName() : String+ setName(s)

Class attributes : the encapsulated data

Class operations: the behaviour

Attributes and operations define the state of an object at run-time and the capabilities or behaviour of the object


A simple person class w ith no state or behaviour show n

Figure 1. Classes, attributes and operations

UML


dilemma for the data modeller mapping anobject model onto a relational framework.

Navigation from one object at run time toanother is based on absolute references. Oneobject has some form of link (a pointer orunique object ID) with which to locate or re-create the required object.

The Relational Model

The relational data model has been aroundfor many years and has a proven track recordof providing performance and flexibility. Itis essentially set based and has as itsfundamental unit the 'table', which iscomposed of a set of one or more 'columns',each of which contains a data element.

Tables and Columns

A relational table is collection of one ormore columns each of which has a uniquename within the table construct. Eachcolumn is defined to be of a certain basicdata type, such as a number, text or binarydata. A table definition is a template fromwhich table rows are created, each row beingan instance of a possible table instance.

Public Data Access

The relational model only offers a publicdata access model. All data is equallyexposed and open to any process to update,query or manipulate it. Information hiding isunknown.

Behaviour

The behaviour associated with a table isusually based on the business or logical rulesapplied to that entity.

Constraints may be applied to columns in theform of uniqueness requirements, relationalintegrity constraints to other tables/rows,allowable values and data types.

Triggers provide some additional behaviourthat can be associated with an entity.Typically this is used to enforce dataintegrity before or after updates, inserts anddeletes.

Database stored procedures provide a meansof extending database functionality throughproprietary language extensions used toconstruct functional units (scripts). Thesefunctional procedures do not map directly to

ParentParentParentParent


ChildChildChildChild

Association captures a having or using relationship between classes

A class hierarchy showing a generalised person class from which other classes are derived

FamilyFamilyFamilyFamilyAggregation captures the concept of collection or composition between classes

The main relationships we are interested in are Association, Aggregation and Inheritance. These describe the ways classes interact or relate to each other

2 1..n

Figure 2. UML Class model notation

UML


entities, nor have a logical relationship tothem.

Navigation through relational data sets isbased on row traversal and table joins. SQLis the primary language used to select rowsand locate instances from a table set.

Relationships and Identity

The primary key of a table provides theunique identifying value for a particular row.There are two kinds of primary key that weare interested in: firstly the meaningful key,made up of data columns which have ameaning within the business domain, andsecond the abstract unique identifier, such asa counter value, which have no businessmeaning but uniquely identify a row. Wewill discuss this and the implications ofmeaningful keys later.

A table may contain columns that map to theprimary key of another table. Thisrelationship between tables defines a foreignkey and implies a structural relationship orassociation between the two tables.

Summary

From the above overview we can see that theobject model is based on discrete entitieshaving both state (attributes/data) andbehaviour, with access to the encapsulateddata generally through the class publicinterface only. The relational model exposesall data equally, with limited support forassociating behaviour with data elementsthrough triggers, indexes and constraints.

You navigate to distinct information in theobject model by moving from object toobject using unique object identifiers andestablished object relationships (similar to anetwork data model). In the relational modelyou find rows by joining and filtering result

PersonPersonPersonPerson ID DocumentID DocumentID DocumentID Document

ShareShareShareShare

AddressAddressAddressAddress

A Person may reside at zero or more addresses

An Address may have zero or more Persons in residence

A Person is composed of a strict set of ID documents (having n elements)

A Person may own a set of Shares

Three forms of the Aggregation relationship. The weak form is depicted with an unfil led diamond head, the strong form (composition) with a fi l led head.

n1

0..n

0..1

0..n 0..n

Figure 3. Aggregation Relationships

UML


sets using SQL using generalised searchcriteria.

Identity in the object model is either a run-time reference or persistent unique ID(termed an OID). In the relational world,primary keys define the uniqueness of a dataset in the overall data space.

In the object model we have a rich set ofrelationships: inheritance, aggregation,association, composition, dependency andothers. In the relational model we can reallyonly specify a relationship using foreignkeys.

Having looked at the two domains of interestand compared some of the important featuresof each, we will digress briefly to look at thenotation proposed to represent relational datamodels in the UML.

The UML Data Model Profile

The Data Model Profile is a proposed UMLextension (and currently under review - Jan2001) to support the modelling of relationaldatabases in UML. It includes customextensions for such things as tables, database schema, table keys, triggers andconstraints. While this is not a ratifiedextension, it still illustrates one possibletechnique for modelling a relational databasein the UML.

Tables

Cus tom erCus tom erCus tom erCus tom er

A table in the UML Data Profile is a classwith the «Table» stereotype, displayed asabove with a table icon in the top rightcorner.

Columns


PK OID: intName: VARCHAR2Address: VARCHAR2

Database columns are modelled as attributesof the «Table» class. For example, the figureabove shows some attributes associated withthe Customer table. In the example, an objectid has been defined as the primary key, aswell as two other columns, Name andAddress. Note that the example abovedefines the column type in terms of thenative DBMS data types.

Behaviour

So far we have only defines the logical(static) structure of the table; in addition weshould describe the behaviour associatedwith columns, including indexes, keys,triggers, procedures & etc. Behaviour isrepresented as stereotyped operations.

The figure below shows our table above witha primary key constraint and index, bothdefined as stereotyped operations:



+ «PK» idx_customer00()+ «index» idx_customer01()

Note that the PK flag on the column 'OID'defines the logical primary key, while thestereotyped operation "«PK»idx_customer00" defines the constraints andbehaviour associated with the primary keyimplementation (that is, the behaviour of theprimary key).

UML


Adding to our example, we may now defineadditional behaviour such as triggers,constraints and stored procedures as in theexample below:



+ «PK» idx_customer00()+ «FK» idx_customer02()+ «Index» idx_customer01()+ «Trigger» trg_customer00()+ «Unique» unq_customer00()+ «Proc» spUpdateCustomer()+ «Check» chk_customer00()

The example illustrates the followingpossible behaviour:

1. A primary key constraint (PK);

2. A Foreign key constraint (FK);

3. An index constraint (Index);

4. A trigger (Trigger);

5. A uniqueness constraint (Unique);

6. A stored procedure (Proc) - not formallypart of the data profile, but an example ofa possible modelling technique; and a

7. Validity check (Check).

Using the notation provided above, it ispossible to model complex data structuresand behaviour at the DBMS level. Inaddition to this, the UML provides thenotation to express relationships betweenlogical entities.

Relationships

The UML data modelling profile defines arelationship as a dependency of any kindbetween two tables. It is represented as astereotyped association and includes a set ofprimary and foreign keys.

The data profile goes on to require that arelationship always involves a parent andchild, the parent defining a primary key and

the child implementing a foreign key basedon all or part of the parent primary key.

The relationship is termed 'identifying' if thechild foreign key includes all the elements ofthe parent primary key and 'non-identifying'if only some elements of the primary key areincluded. The relationship may includecardinality constraints and be modelled withthe relevant PK - FK pair named asassociation roles. Figure 4 illustrates thiskind of relationship modelling using UML.

The Physical Model

UML also provides some mechanisms forrepresenting the overall physical structure ofthe database, its contents and deployedlocation. To represent a physical database inUML, use a stereotyped component as in thefigure below:

« D a ta b a s e »

MainOr aDBMainOr aDBMainOr aDBMainOr aDB

A component represents a discrete anddeployable entity within the model. In thephysical model, a component may bemapped on to a physical piece of hardware (a'node' in UML).

To represent schema within the database, usethe «schema» stereotype on a package. Atable may be placed in a «schema» toestablish its scope and location within adatabase.

«schema»UserUserUserUser

ChildGrandchildGrandparentParentPerson

UML


Mapping from the Class Model to theRelational Model

Having described the two domains of interestand the notation to be used, we can now turnour attention as to how to map or translatefrom one domain to the other. The strategyand sequence presented below is meant to besuggestive rather than proscriptive - adaptthe steps and procedures to your personalrequirements and environment.

1. Model Classes

Firstly we will assume we are engineering anew relational database schema from a classmodel we have created. This is obviously theeasiest direction as the models remain underour control and we can optimise therelational data model to the class model.

In the real world it may be that you need tolayer a class model on top of a legacy datamodel - a more difficult situation and onethat presents its own challenges. For thecurrent discussion will focus on the firstsituation. At a minimum, your class modelshould capture associations, inheritance andaggregation between elements.

2. Identify persistent objects

Having built our class model we need toseparate it into those elements that requirepersistence and those that do not. For

example, if we have designed our applicationusing the Model-View-Controller designpattern, then only classes in the modelsection would require persistent state.

3. Assume each persistent class maps toone relational table

A fairly big assumption, but one that worksin most cases (leaving the inheritance issueaside for the moment). In the simplest modela class from the logical model maps to arelational table, either in whole or in part.The logical extension of this is that a singleobject (or instance of a class) maps to asingle table row.

4. Select an inheritance strategy

Inheritance is perhaps the most problematicrelationship and logical construct from theobject-oriented model that requirestranslating into the relational model. Therelational space is essentially flat, everyentity being complete in its self, while theobject model is often quite deep with a well-developed class hierarchy.

The deep class model may have many layersof inherited attributes and behaviour,resulting in a final, fully featured object atrun-time. There are three basic ways tohandle the translation of inheritance to arelational model:

ParentParentParentParent ChildChildChildChild

An identifying relationship between child and parent, with role names based on primary to foreign key relationship.

PK_PersonID

2 «identifying»

FK_PersonID

0..n

Figure 4. UML relationship

UML


1. Each class hierarchy has a singlecorresponding table that contains all theinherited attributes for all elements - thistable is therefore the union of every classin the hierarchy. For example, Person,Parent, Child and Grandchild may allform a single class hierarchy, andelements from each will appear in thesame relational table;

2. Each class in the hierarchy has acorresponding table of only the attributesaccessible by that class (includinginherited attributes). For example, ifChild is inherited from Person only, thenthe table will contain elements of Personand Child only;

3. Each generation in the class hierarchyhas a table containing only thatgeneration's actual attributes. Forexample, Child will map to a single tablewith Child attributes only

There are cases to be made for eachapproach, but I would suggest the simplest,easiest to maintain and less error prone is thethird option. The first option provides thebest performance at run-time and the secondis a compromise between the first and last.

The first option flattens the hierarchy andlocates all attributes in one table - convenientfor updates and retrievals of any class in thehierarchy, but difficult to authenticate andmaintain. Business rules associated with arow are hard to implement, as each row maybe instantiated as any object in the hierarchy.

The dependencies between columns canbecome quite complicated. In addition, anupdate to any class in the hierarchy willpotentially impact every other class in thehierarchy, as columns are added, deleted ormodified from the table.

tbl_Parenttbl_Parenttbl_Parenttbl_Parent

AddressOID: VARCHARName: VARCHAR

PK OID: VARCHARSex: VARCHAR

ParentParentParentParent

- OID: GUID# Name: String# Sex: Gender

+ setName(String)+ getName() : String+ setSex(String)+ getSex() : String

AddressAddressAddressAddress

- OID: GUID# City: String# Phone: String# State: String# Street: String

+ getCity() : String+ getStreet() : String+ setCity(String)+ setStreet(String)

tbl_Addresstbl_Addresstbl_Addresstbl_Address

City: VARCHARPK OID: VARCHAR

Phone: VARCHARState: VARCHARStreet: VARCHAR

The Address association from the logical model becomes a foreign key relationship in the data model

A Parent class with unique ID (OID) and Name and Sex attributes maps to a relational table.

The Address class in the logical model becomes a table in the data model

<<realises>>

m_Address 0..n

1

<<realises>>

Figure 5. Class to Table mapping

UML


The second option is a compromise thatprovides better encapsulation and eliminatesempty columns. However, a change to aparent class may need to be replicated inmany child tables. Even worse, the parentaldata in two or more child classes may beredundantly stored in many tables; if aparent's attributes are modified, there isconsiderable effort in locating dependentchildren and updating the affected rows.

The third option more accurately reflects theobject model, with each class in thehierarchy mapped to its own independenttable. Updates to parents or children arelocalised in the correct space. Maintenance isalso relatively easier, as any modification ofan entity is restricted to a single relationaltable also. The down side is the need to re-construct the hierarchy at run-time toaccurately re-create a child class's state. AChild object may require a Person membervariable to represent their model parentage.As both require loading, two database callsare required to initialise one object. As thehierarchy deepens, with more generations,the number of database calls required toinitialise or update a single object increases.

It is important to understand the issues thatarise when you map inheritance onto arelational model, so you can decide whichsolution is right for you.

5. For each class add a unique objectidentifier

In both the relational and the object world,there is the need to uniquely identify anobject or entity.

In the object model, non-persistent objects atrun-time are typically identified by directreference or by a pointer to the object. Oncean object is created, we can refer to it by itsrun-time identity. However, if we write outan object to storage, the problem is how toretrieve the exact same instance on demand.

The most convenient method is to define anOID (object identifier) that is guaranteed tobe unique in the namespace of interest. This

may be at the class, package or system level,depending on actual requirements. Anexample of a system level OID might be aGUID (globally unique identifier) createdwith Microsoft's 'guidgen' tool; eg.{A1A68E8E-CD92-420b-BDA7-118F847B71EB}. A class level OID mightbe implemented using a simple numeric (eg.32 bit counter).

If an object holds references to other objects,it may do so using their OID. A completerun-time scenario can then be loaded fromstorage reasonably efficiently.

An important point about the OID valuesabove is that they have no inherent meaningbeyond simple identity. They are onlylogical pointers and nothing more. In therelational model, the situation is often quitedifferent.

Identity in the relational model is normallyimplemented with a primary key. A primarykey is a set of columns in a table thattogether uniquely identify a row. Forexample, name and address may uniquelyidentify a 'Customer'. Where other entities,such as a 'Salesperson', reference the'Customer', they implement a foreign keybased on the 'Customer' primary key.

The problem with this approach for ourpurposes is the impact of having businessinformation (such as customer name andaddress) embedded in the identifier. Imaginethree or four tables all have foreign keysbased on the customer primary key, and asystem change requires the customer primarykey to change (for example to include'customer type'). The work required tomodify both the 'customer' table and theentities related by foreign key is quite large.

On the other hand, if an OID wasimplemented as the primary key and formedthe foreign key for other tables, the scope ofthe change is limited to the primary table andthe impact of the change is therefore muchless.

UML


Also, in practice, a primary key based onbusiness data may be subject to change. Forexample a customer may change address orname. In this case the changes must bepropagated correctly to all other relatedentities, not to mention the difficulty ofchanging information that is part of theprimary key.

An OID always refers to the same entity - nomatter what other information changes. Inthe above example, a customer may changename or address and the related tablesrequire no change.

When mapping object models into relationaltables, it is often more convenient toimplement absolute identity using OID'srather than business related primary keys.The OID as primary and foreign keyapproach will usually give better load andupdate times for objects and minimisemaintenance effort. In practice, a businessrelated primary key might be replaced with:

1. A uniqueness constraint or index on thecolumns concerned;

2. Business rules embedded in the classbehaviour;

3. A combination of 1 and 2.

Again, the decision to use meaningful keysor OID's will depend on the exactrequirements of the system being developed.

6. Map attributes to columns

In general we will map the simple dataattributes of a class to columns in therelational table. For example a text andnumber field may represent a person's nameand age respectively. This sort of directmapping should pose no problem - simplyselect the appropriate data type in thevendor's relational model to host your classattribute. For complex attributes (ie.attributes that are other objects) use theapproach detailed below for handlingassociations and aggregation.

7. Map associations to foreign keys

More complex class attributes (i.e. thosewhich represent other classes), are usuallymodelled as associations. An association is astructural relationship between objects. Forexample, a Person may live at an Address.While this could be modelled as a Person hasCity, Street and Zip attributes, in both theobject and the relational world we areinclined to structure this information as aseparate entity, an Address.

In the object domain an address represents aunique physical object, possibly with aunique OID. In the relational, an addressmay be a row in an Address table, with otherentities having a foreign key to the Addressprimary key.

In both models then, there is the tendency tomove the address information into a separateentity. This helps to avoid redundant dataand improves maintainability.

So for each association in the class model,consider creating a foreign key from thechild to the parent table.

8. Map Aggregation and Composition

Aggregation and composition relationshipsare similar to the association relationship andmap to tables related by primary-foreign keypairs. There are however, some points tobear in mind.

Ordinary aggregation (the weak form)models relationships such as a Person residesat one or more Addresses. In this instance,more than one person could live at the sameaddress, and if the Person ceased to exist, theAddresses associated with them would stillexist. This example parallels the many-to-many relationship in relational terminology,and is usually implemented as a separatetable containing a mapping of primary keysfrom one table to the primary keys ofanother.

UML


A second example of the weak form ofaggregation is where an entity has use orexclusive ownership of another. Forexample, a Person entity aggregates a set ofshares. This implies a Person may beassociated with zero or more shares from aShare table, but each Share may beassociated with zero or one Person. If thePerson ceases to exist, the Shares becomeun-owned or are passed to another Person. Inthe relational world, this could beimplemented as each Share having an 'owner'column which stored a Person ID (or OID) .

The strong form of aggregation, however,has important integrity constraints associatedwith it. Composition, implies that an entity iscomposed of parts, and those parts have adependent relationship to the whole. Forexample, a Person may have identifyingdocuments such as a Passport, BirthCertificate, Driver's License & etc. A Personentity may be composed of the set of suchidentifying documents. If the Person isdeleted from the system, then the identifyingdocuments must be deleted also, as they aremapped to a unique individual.

If we ignore the OID issue for the moment, aweak aggregation could be implementedusing either an intermediate table (for themany-to-many case) or with a foreign key inthe aggregated class/table (one-to-many

case). In the case of the many-to-manyrelationship, if the parent is deleted, theentries in the intermediate table for thatentity must also be deleted also. In the caseof the one-to-many relationship, if the parentis deleted, the foreign key entry (i.e. 'owner')must be cleared.

In the case of composition, the use of aforeign key is mandatory, with the addedconstraint that on deletion of the parent thepart must be deleted also. Logically there isalso the implication with composition thatthe primary key of the part forms part of theprimary key of the whole - for example, aPerson's primary key may composed of theiridentifying documents ID's. In practice, thiswould be cumbersome, but the logicalrelationship holds true.

9. Define relationship roles

For each association type relationship, eachend of the relationship may be furtherspecified with role information. Typically,you will include the Primary Key constraintname and the Foreign Key Constraint name.Figure 6 illustrates this concept. Thislogically defines the relationship between thetwo classes. In addition, you may specifyadditional constraints (e.g. {Not NULL}) onthe role and cardinality constraints (eg. 0..n).

CustomerCustomerCustomerCustomer

PK OID: intName: VARCHAR2Address: VARCHAR2Salesperson: int

+ «PK» PK_Customer()+ «FK» FK_SalesPerson()

SalespersonSalespersonSalespersonSalesperson

PK OID: intName: VARCHAR2Department: VARCHAR2

+ «PK» PK_Salesperson()

Relationships are based on the PK- FK pair. This example relates a Salesperson to aCustomer by the appropriate primary and foreign keys. The assumption is that acustomer may only be associated with one salesperson.

PK_Salesperson

1

FK_Salesperson

0..*

Figure 6. Table relationships in UML

UML


10. Model behaviour

We now come to another difficult issue:whether to map some or all class behaviourto the functional capabilities provided bydatabase vendors in the form of triggers,stored procedures, uniqueness and dataconstraints, and relational integrity.

A non-persistent object model wouldtypically implement all the behaviourrequired in one or more programminglanguages (e.g. Java or C++). Each class willbe given its required behaviour andresponsibilities in the form of public,protected and private methods.

Relational databases from different vendorstypically include some form ofprogrammable SQL based scripting languageto implement data manipulation. The twocommon examples are triggers and storedprocedures. When we mix the object andrelational models, the decision is usuallywhether to implement all the business logicin the class model, or to move some to theoften more efficient triggers and storedprocedures implemented in the relationalDBMS.

From a purely object-oriented point of view,the answer is obviously to avoid triggers andstored procedures and place all behaviour inthe classes. This localises behaviour,provides for a cleaner design, simplifiesmaintenance and provides good portabilitybetween DBMS vendors. In the real world,

the bottom line may be scaling to 100's or1000's of transactions per second, somethingstored procedures and triggers are purposedesigned for. If purity of design, portability,maintenance and flexibility are the maindrivers, localise all behaviour in the objectmethods.

If performance is an over-riding concern,consider delegating some behaviour to themore efficient DBMS scripting languages.Be aware though that the extra time taken tointegrate the object model with the storedprocedures in a safe way, including issueswith remote effects and debugging, may costmore in development time than simplydeploying to more capable hardware.

As mentioned earlier, the UML Data Profileprovides the following extensions(stereotyped operations) with which you canmodel DBMS behaviour:

• Primary key constraint (PK);

• Foreign key constraint (FK);

• Index constraint (Index);

• Trigger (Trigger);

• Uniqueness constraint (Unique);

• Validity check (Check).

11. Produce a physical model

In UML, the physical model describes howsomething will be deployed into the realworld - the hardware platform, network

http://www.datewise.com/mt

UML


connectivity, software, operating system,DLL's and other components. You produce aphysical model to complete the cycle - froman initial use case or domain model, throughthe class model and data models and finallythe deployment model.

Typically for this model you will create oneor more nodes that will host the database(s)and place DBMS software components onthem. If the database is split over more thanone DBMS instance, you can assignpackages («schema») of tables to a singleDBMS component to indicate where the datawill reside.

Conclusion

This concludes this short article on databasemodelling using the UML. As you can see,there are quite a few issues to consider whenmapping from the object world to therelational. The UML provides support forbridging the gap between both domains, andtogether with extensions such as the UML

Data Profile is a good language forsuccessfully integrating both worlds.

References

• Muller, Robert J., Database Design forSmarties, Morgan Kaufman, 1999.

• Rational Software, The UML and DataModelling, Rational Software

• Ambler, Scott W., Mapping Objects toRelational Databases, AmbySoft inc,1999

About the Author

Geoffrey Sparks is the director of SparxSystems, an Australian company thatspecialises in UML tools. The SparxSystems Web site is at:www.sparxsystems.com.au. Geoffrey may becontacted at [email protected]

MainServerMainServerMainServerMainServer

«schema»SystemSystemSystemSystem

sys_aliases

sys_procs

sys_queries

sys_tables

sys_users

«schema»UserUserUserUser

Child

Grandchild

Grandparent

Parent

Person

«Database»

MainOraDBMainOraDBMainOraDBMainOraDB

A Node is a physical piece of hardware (such as a Unix server) on which components are deployed. Thedatabase component in this example is also mapped to two logical «schema», each of which contains anumber of tables.

Figure 6. The Physical Model

UML


A quick summary guide to data modelling in UML

1. Create a class model for your development domain

2. Identify persistent classes from the model

3. Assume each persistent class in the model will map to one relational table

4. Select a suitable inheritance strategy for each class hierarchy

5. For each class add a unique ID (OID) or select a suitable primary key

6. For each class map simple data types to table columns

7. For each class, map complex attributes (association, aggregation) to PK/ FK pairs. Takespecial note of the strong and weak forms of aggregation.

8. For related classes, map PK, FK pairs naming the role ends according to selected key.

9. Label relationship roles with their appropriate cardinality and stereotype: <<identifying>>or <<non-identifying>>

10. Add stereotyped operations for table behaviour (keys, indexes, uniqueness, checks, andtriggers)

11. Divide persistent classes into logical schema

12. Create a deployment model and link database components to physical nodes

Classified Advertisement

Advertising for a new Web development tool? Looking to recruitsoftware developers? Promoting a conference or a book?Organising software development related training? This space iswaiting for you at the price of US $ 20 each line. Reach morethan 13'000 Web-savvy software developers and project managersworldwide with a classified advertisement in Methods & Tools.Without counting those that download the issue without beingregistered! To advertise in this section or to place a page adsimply send an e-mail to [email protected]

METHODS & TOOLS is published by Martinig & Associates, Rue des Marronniers 25,CH-1800 Vevey, Switzerland Tel. +41 21 922 13 00 Fax +41 21 921 23 53 www.martinig.chEditor: Franco Martinig; e-mail [email protected] ISSN 1023-4918Free subscription: www.martinig.ch/mt/index.htmlThe content of this publication cannot be reproduced without prior written consent of the publisherCopyright 2001, Martinig & Associates