Developing enterprise Java applications with J2EE and UML 0201738295, 9780201738292

Citation preview

Developing Ent erprise Ja va Applica t ions w it h J2 EE a nd UM L by Khawar Zam an Ahm ed, Cary E. Um rysh •

Pa pe r ba ck : 288 pages ; Dim ensions ( in inches) : 0.66 x 9.28 x 7.32

•

Publisher: Addison- Wesley Pub Co; I SBN: 0201738295; 1st edit ion ( Decem ber 15, 2001)

•

Ave r a ge Cust om e r Re vie w :

Based on 6 reviews.

Table of Contents Copyright.................................................................................................................. 6 Dedication......................................................................................................... 7 Foreword.................................................................................................................. 8 Preface................................................................................................................... 10 Intended Audience .......................................................................................... 10 How to Use This Book......................................................................................11 Chapter Summaries ........................................................................................ 12 Conventions.................................................................................................... 13 Acknowledgments .................................................................................................. 15 Chapter 1. Introduction to Enterprise Software ....................................................... 17 What Is Enterprise Software?.......................................................................... 17 Evolution of Enterprise Software ..................................................................... 20 Enterprise Software and Component-Based Software ..................................... 22 Summary......................................................................................................... 23 Chapter 2. Introduction to the J2EE ........................................................................ 24 What Is the Java 2 Platform, Enterprise Edition?............................................. 24 A Brief History of J2EE .................................................................................... 25 Why J2EE? ..................................................................................................... 27 A Brief Overview of J2EE................................................................................. 30 Summary......................................................................................................... 39 Chapter 3. Introduction to the UML ......................................................................... 40 UML Overview................................................................................................. 41 Why Use the J2EE and the UML Together? .................................................... 43 Challenges in Modeling J2EE in the UML ........................................................ 45 Extension Mechanisms in the UML .................................................................. 46 The Approach to J2EE UML Modeling ............................................................. 49 Summary ........................................................................................................ 50 Chapter 4. UML and Java....................................................................................... 51 Representing Structure.................................................................................... 51 Representing Relationships............................................................................. 57 Summary......................................................................................................... 69 Chapter 5. Overview of Activities ............................................................................ 70 What Is a Software Development Process?..................................................... 70 Overview of Popular Approaches to Software Development ............................ 70 Approach Used in This Book ........................................................................... 79 Overview of Major Activities............................................................................. 80 Summary......................................................................................................... 82 Chapter 6. Architecture........................................................................................... 83 What Is Software Architecture?........................................................................ 83 Why Architecture?........................................................................................... 85 Key Concepts in Enterprise Application Architecture........................................ 86 Approaches to Software Architecture............................................................... 99

Putting It All Together.....................................................................................101 Summary .......................................................................................................102 Chapter 7. Analyzing Customer Needs ..................................................................103 Why Software Analysis and Design? ..............................................................103 Problem Analysis............................................................................................104 Use Case Modeling ........................................................................................105 Identifying the Actors......................................................................................106 Finding the Use Cases ...................................................................................107 Use Case Diagrams .......................................................................................109 Use Case Relationships ................................................................................. 110 Sequence Diagrams ....................................................................................... 113 Activity Diagrams............................................................................................ 115 Summary........................................................................................................ 118 Chapter 8. Creating the Design .............................................................................120 Use Case Analysis .........................................................................................120 Use Case Realizations ...................................................................................120 Refined Use Case Description........................................................................122 Sequence Diagrams .......................................................................................124 Collaboration Diagrams ..................................................................................129 Class Diagrams ..............................................................................................130 Coalescing the Analysis Classes....................................................................134 Packaging ......................................................................................................138 Summary........................................................................................................140 Chapter 9. Overview of J2EE Technologies...........................................................142 The Big Picture...............................................................................................142 Servlets..........................................................................................................143 JavaServer Pages (JSP) ................................................................................143 Enterprise JavaBeans (EJB)...........................................................................144 Session Beans ...............................................................................................144 Entity Beans...................................................................................................144 Message-Driven Beans..................................................................................145 Assembly and Deployment.............................................................................145 Case Study.....................................................................................................145 Summary........................................................................................................145 Chapter 10. Servlets..............................................................................................146 Introduction to Servlets...................................................................................147 Servlet Life Cycle ...........................................................................................149 Request Handling...........................................................................................152 Response Generation.....................................................................................153 HTTP Request Handlers.................................................................................155 The RequestDispatcher Interface ...................................................................156 Modeling Servlets in UML...............................................................................157 Modeling Other Servlet Aspects .....................................................................159 Servlet Deployment and Web Archives...........................................................164

Identifying Servlets in Enterprise Applications.................................................165 Summary........................................................................................................169 Chapter 11. JavaServer Pages..............................................................................170 Introduction to JSP .........................................................................................171 Anatomy of a JSP...........................................................................................174 Tag Libraries...................................................................................................178 JSP and the UML ...........................................................................................180 JSP in Enterprise Applications........................................................................185 Summary........................................................................................................189 Chapter 12. Session Beans...................................................................................190 Introduction to Enterprise JavaBeans .............................................................190 EJB Views and the UML .................................................................................192 Session Beans ...............................................................................................197 Types of Session Beans and Conversational State.........................................198 Instance Passivation ......................................................................................202 Transactions...................................................................................................203 Session Bean Technology ..............................................................................209 Modeling Interface Behavior...........................................................................213 Session Bean Life Cycle ................................................................................216 Session Bean Common Scenarios .................................................................218 Modeling Session Bean Relationships............................................................221 Managing Performance..................................................................................226 The Local Client .............................................................................................227 Identifying Session Beans in Enterprise Applications......................................227 Summary........................................................................................................230 Chapter 13. Entity Beans.......................................................................................232 Introduction to Entity Beans............................................................................232 Entity Bean Views and the UML .....................................................................235 Persistence ....................................................................................................238 Abstract Persistence.......................................................................................240 Container-Managed Relationships..................................................................243 Entity Bean Technology..................................................................................246 Entity Bean Life Cycle....................................................................................254 Entity Bean Common Scenarios.....................................................................256 Modeling Entity Bean Relationships................................................................256 Identifying Entity Beans in Enterprise Applications .........................................263 Summary........................................................................................................267 Chapter 14. Message-Driven Beans......................................................................268 Introduction to Message-Driven Beans...........................................................268 Message-Driven Bean Views and the UML .....................................................271 Message-Driven Bean Technology .................................................................275 Message-Driven Bean Life Cycle....................................................................277 Message-Driven Bean Common Scenario......................................................278 Modeling Message-Driven Bean Relationships...............................................279

Summary .......................................................................................................280 Chapter 15. Assembly and Deployment.................................................................281 Component Modeling .....................................................................................281 Component Modeling of J2EE Technologies...................................................282 Deployment Modeling.....................................................................................288 Traceability Revisited .....................................................................................290 Assembly and Deployment of Enterprise Java Applications............................291 Summary .......................................................................................................294 Chapter 16. Case Study ........................................................................................296 Case Study Background .................................................................................297 Problem Statement.........................................................................................297 Rationale and Assumptions............................................................................298 HomeDirect Requirements.............................................................................298 Inception Phase .............................................................................................302 Elaboration Phase ..........................................................................................312 Remaining Phases .........................................................................................326 Summary........................................................................................................327 Glossary................................................................................................................328 References............................................................................................................346 Books.............................................................................................................346 Articles and Online Sources ...........................................................................347

Copyright Many of t he designat ions used by m anufact ur er s and seller s t o dist inguish t heir pr oduct s ar e claim ed as t r ad em ar k s. Wh er e t h ose d esig n at ion s ap p ear in t his book, and Addison-Wesley I nc. w as aw ar e of a t r adem ar k claim , t he designat ions hav e been pr int ed w it h init ial capit al let t er s or in all capit als.

Th e au t h or s an d pu blish er h av e t ak en car e in t h e pr epar at ion of t h is book , bu t m ak e n o ex p r essed o r im plied w ar r an t y of an y k in d an d assu m e n o r espon sibilit y for er r or s or om issions. No liabilit y is assum ed for incident al or consequent ial dam ages in connect ion w it h or ar isin g ou t of t h e u se of t h e in f or m at ion or pr ogr am s con t ain ed h er ein .

Th e pu blish er of f er s discou n t s on t h is book w h en or der ed in qu an t it y f or special sales. For m or e infor m at ion, please cont act :

Pear son Edu cat ion Cor por at e Sales Div ision

2 0 1 W. 1 0 3 r d St r eet

I ndianapolis, I N 4 6 2 9 0

( 800) 428-5 3 3 1

co r p sa l e s@p e a r so n e d . co m

Visit AW on t h e Web:

w w w . aw l. com / csen g/

Library of Congress Cat aloging-in -Publicat ion Dat a

Ahm ed, Khaw ar Zam an.

Developing Ent erprise Java applicat ions wit h J2EE™ and UML / Khawar Zam an Ahm ed, Cary E. Um r y sh.

p. cm .

I n clu des bibliogr aph ical r efer en ces an d in dex .

I SBN 0 -2 0 1 -7 3 8 2 9 -5

1. Java ( Com put er program language) 2. Business—Dat a processing. I . Um rysh, Cary E. I I . Tit le.

QA76. 73. J38 A35 2001

005.13'3 —dc2 1 2 0 0 1 0 4 6 4 5 2

Copy r igh t © 2 0 0 2 by Addison -W esl ey

All right s reserved. No part of t his publicat ion m ay be reproduced, st ored in a ret rieval syst em , or t r ansm it t ed, in any for m , or by any m eans, elect r onic, m echanical, phot ocopy ing, r ecor din g, or ot h er w ise, w it h ou t t h e pr ior con sen t of t h e pu blish er . Pr in t ed in t h e Un it ed St at es of Am er ica. Pu blish ed sim u lt an eou sly in Can ada.

Tex t pr in t ed on r ecy cled paper

1 2 3 4 5 6 7 8 9 1 0 —CRS—0 5 0 4 0 3 0 2 0 1

Fir st pr int ing, Oct ober 2001

Dedication To m y lat e fat her and m y m ot her, and t o Heike and Yasm een.

—Khawar

To m y wife Socorro for her support during t his lengt hy proj ect , and t o m y sons Jordan and Joshua.

—Cary

Foreword Th e h ist or y of soft w ar e en gin eer in g is, in effect , t h e h ist or y of abst r act ion. As com plex it y r ises, w e r espond by r aising t he level of abst r act ion in our pr ogr am m ing languages and in our m et h ods. Th u s, w e h av e seen t h e m ov e f r om C t o Jav a, f r om st r u ct u r ed m et h ods t o obj ect -or ien t ed design , an d f r om classes t o design pat t er n s t o ar ch it ect u r al f r am ew or k s.

J2EE, t he Java 2 Plat form , Ent erprise Edit ion, is such a fram ework. J2EE is a com prehensive plat for m for deploy ing com plex sy st em s. I t r aises t he lev el of abst r act ion for t he developm ent t eam by offering a set of m echa nism s ( JSP, Ent erprise JavaBeans, servlet s) and ser v ices ( JDBC, JNDI , JMS, and RMI t o nam e a few ) , enabling t he t eam t o focus on it s cor e bu sin ess v alu e in st ead of bu ildin g in f r ast r u ct u r e.

As good as J2EE is, however, t here is a large sem ant ic gap bet ween w hat J2EE pr ov ides and w hat m ust be cr aft ed for t he business. Br idging t hat gap can only be achiev ed giv en a st r ong, f ou n dat ion al u n der st an din g of J2 EE t oget h er w it h a sou n d ar ch it ect u r e f or t h e dom ain -specific syst em . The Unified Modeling Language ( UML) com es int o play here, for t he UML is essen t ially t h e lan gu age of blu epr in t s for soft w ar e. Visu alizin g, specify in g, con st r u ct in g, an d docu m en t in g t h e k ey elem en t s of a sy st em ar e essen t ial as com plex it y r ises, an d t h is is t h e v er y r eason f or t h e UML' s ex ist e n ce.

Kh aw ar an d Car y br in g all of t h ese elem en t s t oget h er in t h is book t o h elp y ou br idge t h at sem ant ic gap. Not only do t hey cov er all of t he essent ial pieces of J2EE t hus helping y ou build a f ou n dat ion al u n der st an din g, t h ey also ex plain h ow best t o u se J2 EE' s m ech an ism s an d services. This book will also guide you in applying t he UML t o m odel your syst em s built upon J2 EE, t h u s en ablin g y ou t o bet t er r eason abou t an d com m u n icat e t h e an aly sis an d design decisions y our t eam m ust m ak e in building qualit y soft w ar e.

The aut hor s hav e a deep under st anding of J2EE and t he UML and a st r ong sense of t he best pr act ices t h at can lead y ou t o t h e effect iv e u se of bot h . Th eir ex per ien ce in bu ildin g pr oduct ion sy st em s com es t hr ough in t heir w r it ing, and especially in t heir com pr eh en siv e case st u dy .

There is an essent ial com plexit y in building ent erprise syst em s; t his book w ill help you m ast er m uch of t hat com plex it y .

—Gr ady Booch Ch ief Scient ist Rat ion al Soft w ar e Cor por at ion

Preface Dev elopin g com plex soft w ar e r equ ir es m or e t h an j u st ch u r n in g ou t lin es of code. As a soft w are archit ect or developer involved in an indust rial proj ect , you m ust underst and and be able t o lev er age cr it ical sof t w ar e su bdisciplin es su ch as ar ch it ect u r e, an aly sis an d design t ech n iqu es, dev elopm en t processes, v isual m odeling, and t he under ly ing t echnology t o be successful.

Th is book br in gs all t h ese div er se elem en t s t oget h er fr om t h e Jav a 2 Plat for m , En t er pr ise Edit ion ( J2 EE) dev elopm en t per spect iv e t o pr ov ide a h olist ic appr oach for t h e r eader . Specifically , t h is book t r ies t o an sw er t h e f ollow in g k ey qu est ion s:

•

Wh at is t h e Un if ied Modelin g Lan gu age ( UML) , an d h ow is it r elev an t t o J2 EE dev elopm en t ?

•

How do Jav a an d UML r elat e t o each ot h er ?

•

Wh at ar e t h e k ey con cept s in sof t w ar e ar ch it ect u r e?

•

How d oes a soft w ar e dev elopm en t pr ocess fit in t o t h e J2 EE soft w ar e dev elopm en t eq u at ion ?

•

How can analy sis and design help y ou t o ar r iv e at a bet t er J2 EE applicat ion design?

•

Wh at ar e t h e k ey J2 EE t ech n ologies, an d h ow do t h ey f it t oget h er ?

•

How can y ou lev er ag e t h e UML for J2 EE dev elopm en t ?

Rat her t han r einvent t he w heel, t he appr oach t aken in t his book is t hat of br inging t oget her k n ow n w or k s, su ch as Jim Con allen ' s Web Modelin g Pr ofile an d t h e Su n Jav a Specificat ion Req u est -26 for UML/ EJB Mapping Specificat ion.

To p rov ide a pr act ical illu st r at ion of t h e t opics discu ssed, t h is book gu ides y ou t h r ou gh a sam ple J2 EE applicat ion dev elopm ent pr oj ect using t he Rat ional Unified Pr ocess ( RUP) and t he UML. A w or k ing im plem ent at ion is pr ov ided. Suggest ions for fur t her enhancem e nts are also list ed t o assist y ou in con t in u in g y ou r ex plor at ion of t h e UML an d J2 EE t ech n ologies.

Intended Audience Th is book is su it able f or an y on e in t er est ed in lear n in g abou t t h e UML an d h ow it can be applied t o J2EE dev elopm ent . Cur r ent J2EE applicat ion dev eloper s w ill lear n how t o apply t he UML t o J2EE applicat ion developm ent . UML pract it ioners w ill benefit from learning about t he J2 EE in t h e con t ex t of t h e UML. An d sof t w ar e pr of ession als in t er est ed in lear n in g bot h t h e

UML an d J2 EE w ill be able t o get t o a pr odu ct iv e st at e f ast er f acilit at ed by t h e in t er t w in ed con t ex t u al discu ssion .

Aft er r eadin g t h e book , y ou w ill

•

Be able t o effect iv ely ut ilize t he UML for dev eloping J2 EE applicat ions

•

Lear n abou t t h e k ey J2 EE t ech n ologies ( EJB, JSP, an d ser v let s) at a t ech n ical lev el

•

Know w hen t o use Model 1 ver sus Model 2 ar chit ect ur e, and ident ify sit uat ions w her e pat t er n s su ch as v alu e obj ect an d session bean ch ain in g m ay be appr opr iat e

•

Un der st an d sof t w ar e ar ch it ect u r e con cept s su ch as decom posit ion , lay er in g, com p on en t s, f r am ew or k s, pat t er n s, an d t ier s

•

Be able t o apply t echniques such as use case analysis, analysis obj ect discover y, and an aly sis t o design t r an sfor m at ion t o y ou r J2 EE pr oj ect

•

Under st and t he not ion of soft w ar e developm ent pr ocesses and t he fun dam ent a ls of som e of t h e cu r r en t ly popu lar pr ocesses

•

Lear n h ow t o st ar t u sin g t h e RUP f or y ou r J2 EE pr oj ect

Th is book on ly cov er s t h e Jav a lan gu age t o t h e ex t en t of pr ov idin g a m appin g of k ey Jav a concept s t o t he UML. Consequent ly, som e fam iliarit y wit h Java is a ssum ed ( knowing C+ + or a sim ilar language should be sufficient t o get t he basics fr om t he exam ples) . Pr ior know ledge of, or ex per ien ce w it h , t h e UML, J2 EE, or en t er pr ise applicat ion dev elopm en t is n ot a pr er equisit e, but is cer t ainly helpful.

How to Use This Book I f y ou ar e n ew t o t h e UML an d J2 EE, y ou w ill get t h e m ost ou t of t h is book by r eadin g it com plet ely in a sequent ial m a nner .

Those w ho are com fort able w it h t he UML and are prim arily int erest ed in learning about J2EE ( or how t o apply t he UML t o J2 EE) can j um p dir ect ly t o

Ch a p t e r s 9 – 1 6 .

On t h e ot h er h an d, if y ou k n ow J2 EE an d m ost ly w an t t o lear n abou t UML, y ou sh ou ld con cen t r at e on

Ch a p t e r s 1 – 8 ,

an d t h en sk im t h r ou gh t h e r em ain in g por t ion s of t h e book .

You w ill get t h e best r esu lt s if y ou get y ou r h an ds on a good m odelin g t ool an d t r y t o apply v isual m odeling t o a p r oblem of y ou r ow n !

Chapter Summaries Chapt er 1 : I n t r o d u ct i o n t o En t er p r i se So f t w a r e

p r ov id es a h ig h -level overview of ent erprise soft w are

d ev elop m en t an d r elat ed t ech n olog ies.

Chapt er 2 : I n t r o d u cti o n t o t h e J2 EE

cov er s t he basics of t he Jav a 2 Plat for m , Ent er pr ise Edit ion. I t

pr ov ides an ov er v iew of t h e basic t ech n ologies an d t h e API s, w h ich f or m t h e J2 EE.

Chapt er 3 : I n t r o d u ct i o n t o t h e UML

provides an overview of t he UML and a quick int roduct ion t o t he

UML basics.

Cha pt er 4 : UML a n d Ja v a

pr ov ides an ov er v iew of t h e Jav a lan gu age' s m appin g t o t h e UML an d

cov er s som e of t h e basic UML con st r u ct s.

Chapt er 5 : Ov e r v i e w o f Act i v i t i e s

in t r odu ces t h e n ot ion of sof t w ar e dev elopm en t pr ocesses an d

ou t lin es t h e appr oach t ak en in t h e book .

Chapt er 6 : Ar ch i t e ct u r e ,

w hich is an im por t ant aspect of good soft w ar e, int r oduces t he not ion of

sof t w ar e ar ch it ect u r e an d pr ov ides an ov er v iew of som e of t h e con cept s in sof t w ar e ar chit ect ur e.

Chapt er 7 : An a l y zi n g Cu st o m e r Ne e d s

show s y ou how t o apply UML use cases t o bet t er under st and

cust om er requirem ent s. No m at t er how cool t he soft ware, if it does not m eet t he cust om er's r equir em ent s, it is a failur e!

Chapter 8 : Creat ing t he Design

focuses on analyzing t he requirem ent s furt her and creat ing t he init ial

design for t he case st udy. This chapt er discusses how t o t ranslat e t he requirem ent s you have g at h er ed in t o sof t w ar e.

Chapt er 9 : Overview of J2EE Technologies

lays t he groundwork for t he J2EE t echnologies we discuss in

t h e r em ain in g ch apt er s.

Chapt er 1 0 : Servlets

provides an overview of t he Java servlet t echnology, discusses how t hey are

m odeled in t he UML, and t hen show s a represent at ive applicat ion of UML and servlet s t o t he case st u dy . Jav a ser v let s ar e ideal f or t h e r equ est -r esp on se or ien t e d Web par adigm .

Chapt er 1 1 : JavaServer Pages

t eaches you about JSPs, w hen t o use t hem , and how t o use t hem in

t he sam ple pr oj ect . JavaSer ver Pages ( JSP) com bine t he pow er of ser vlet s w it h t he flexibilit y of HTML pages.

Chapt er 1 2 : Session Beans

discusses how session beans ar e used in t he m iddle t ier and how t o best

m od el an d u t ilize t h em . Session b ean s ar e on e of t h e t h r ee t y p es of en t er p r ise b ean s pr ovided in t he J2EE. The chapt er concludes w it h t he usage of session beans in t he cont ext of t h e case st u dy .

Chapt er 1 3 : Ent it y Beans

focuses on t he ent it y bean concept , it s advant ages and issues, and how

t o effect iv ely m odel it in t h e UML. En t it y bean s pr ov ide a con v en ien t w ay t o obj ect ify t h e st or ed d at a.

Chapt er 1 4 : M e s s a g e - D r i v e n Be a n s

cov er s t h e t ech n ology an d h ow t o m odel t h em in t h e UML.

Messag e-dr iv en bean s ar e a n ew addit ion t o t h e J2 EE En t er pr ise Jav aBean specif icat ion .

Chapt er 1 5 : Asse m b l y a n d D e p l o y m e n t

discusses how UML can help assem bly and deploy m ent of a

dist r ibut ed applicat io n .

Chapt er 1 6 : Ca s e S t u d y

discusses t he det ails of t he ex am ple used in t his book including gener al

r equ ir em en t s, r est r ict ion s, an d su ch .

References for fu r t h er r eadin g in clu de book s, ar t icles, an d on lin e sou r ces.

A

Glossary

cont aining specialized t erm s and t heir m eanings is provided for quick reference. An

I ndex is pr ov ided for qu ick look u p an d r efer en ce.

Conventions We use several not at ional convent ions t hroughout t his book. A short list is provided for your r ef er en ce:

•

I t alicized w or ds ar e u sed t o h igh ligh t k ey con cept s or t er m inology .

•

Refer ences t o t er m s such as j a va x .se r vle t .ht t p.H t t pSe r vle t Re sponse ar e used t o ident ify t he ex act J2 SE or J2 EE classes for fur t her det ails. For ex am ple, in t he preceding t erm t he user is being referred t o t he Ht t pServlet Response class, which is f ou n d in t h e h t t p pack age locat ed in t h e ser v let pack age of t h e j av ax pack age.

•

Boldf ace t ex t is u sed t o iden t if y k ey w or ds an d r eser v ed w or ds in t h e con t ex t of Jav a/ J2EE, for ex am ple, e j bCr e a t e .

•

Code sam ples ar e show n in a slight ly differ ent for m at t o dist inguish t hem from plain t ex t , for ex am ple, public void acceptOrder() {

Acknowledgments We w ou ld lik e t o ack n ow led g e t h e con t r ib u t ion s of all t h ose w h o h elp ed m ak e t h is b ook p ossib le.

Ou r sin cer e t h an k s t o Kir k Kn oer n sch id, Todd Du n n av an t , Dav e Tr opean o, At m a Sut j iant o, Kev in Kelly , Ter r y Quat r ani, Car oly n Hak ansson-Johnst on, I ngr id Subbot in, Jim Conallen, Loïc Julien, Dav e Hauck , Jam es Abbot t , Sim on Johnst on, Tom m y Fannon, Hassan I ssa, and all ot her s w ho pr ov ided dir ect or indir ect input , clar ificat ions, ideas, feedback, guidance, and r ev iew s at v ar iou s st ages, f r om bef or e in cept ion t h r ou gh t o com plet ion . Th eir h elp w as inst r um ent al in defining and r edefining t he w or k , in elim inat ing inaccur acies, in cr eat ing addit ion al m at er ial, an d in t h e en d, t h e r esu lt is a bet t er pr odu ct ov er all.

A special t hank y ou t o Todd Dunnav ant . He not only r ev iew ed m ult iple dr aft s cov er t o cov er , h e also gen er ou sly pr ov ided in -dept h w r it t en ex planat ions, suggest ions, and com m ent s on v ar iou s t op ics t h at w e w er e on ly t oo h ap p y t o in cor por at e in t h e book .

Kirk Knoernschid's succinct review w as m ost helpful in get t ing us t o focus and rem edy som e of t he k ey deficiencies in an ear lier , dr aft v er sion. Thank y ou for t hat .

Kh aw ar w ou ld lik e t o ack n ow ledge an d t h an k Kev in Kelly f or h is gu idan ce an d m en t or in g. Kev in ' s in sigh t s an d ideas w er e im m en sely u sef u l t h r ou gh ou t t h is pr oj ect .

Dav e Tr opean o' s r ev iew of a v er y ear ly dr aft dir ect ly led t o a r ev ect or in g of ou r ov er all approach and t he addit ion of at least t w o full chapt ers. The final version is bet t er because of it , an d w e h av e Dav e t o t h an k .

Ou r t h an k s t o Rat ion al Sof t w ar e an d it s m an agem en t f or f ost er in g a w or k en v ir on m en t in w hich such endeavors can be undert aken. We w ould especially like t o t hank St eve Rabuchin f or h is w illin gn ess t o go t h e ex t r a m ile t o h elp ot h er s pu r su e t h eir ideas an d ach iev e t h eir goals. We w ou ld also lik e t o t h an k Jim McGee, Roger Ober g, Magn u s Ch r ist er son , Joh n Scu m n iot ales, Mat t Halls, an d Er ic Naibu r g. Had it n ot been for t h e en cou r agem en t an d su p p or t of t h ese in div idu als, t h is book w ou ld n eit h er h av e been con ceiv ed n or w r it t en .

We ar e v er y gr at eful t o t he st aff at Addison -Wesley for t heir suppor t t hr oughout t his pr oj ect . We especially t hank Paul W. Beck er and his assist ant Jessica Cir one w ho assist ed, r em inded, guided, and pr odded us t hr ough t he publishing pr ocess. Many t hank s t o Anne Mar ie Walk er

who, t hrough her t hought ful edit ing, t ransform ed our sem i-coherent passages int o readable par agr aphs. Thanks also t o Kat hy Glidden of St r at for d Publishing Ser vices, I nc. for her skilled pr oj ect m an agem en t in t h e cr it ical pr odu ct ion st age.

We ben efit ed im m en sely fr om ot h er s w h o h av e w or k ed on or w r it t en abou t t h e UML, J2 EE, an d r elat ed t op ics. To t h at en d , w e w ou ld lik e t o t h an k t h e v ar iou s au t h or s w h ose b ook s, ar t icles, an d Web sit es ar e list ed in t h e Ref er en ces sect ion . Th eir w or k s h elped ex pan d ou r u n d er st an d in g of t h e su b j ect s.

Last but m ost im port ant ly, we would like t o t hank our fam ilies for t heir pat ience and support t h r ou g h ou t t h ese last sev er al m on t h s. Kh aw ar w ou ld lik e t o t h an k h is w ife Heik e an d h is daught er Yasm een for t heir cheerful and underst anding at t it ude and for t heir support during t his long com m it m ent . Heik e' s diligent pr oofr eading and cor r ect ions t o t he dr aft at v ar ious st ag es w er e in v alu ab le an d r esu lt ed in t he elim inat ion of num er ous lat e -n ig h t t y p os an d in coh er en t sen t en ces. Car y w ou ld lik e t o t h an k h is w if e Socor r o f or all h er su ppor t an d h elpf u ln ess du r in g t h is len gt h y pr oj ect .

—K.Z.A.

—C.E.U.

Chapter 1. Introduction to Enterprise Software •

W h a t I s En t e r p r i se So f t w a r e ?

•

Ev o l u t i o n o f En t er p r i se So f t w ar e

•

En t er p r i se So f t w a r e a n d Co m p o n en t - Ba sed So f t w a r e

•

Su m m ar y

I f you have heard of t er m s such as Business-t o-Business ( B2B) and Business-t o-Consum er ( B2C) , you ar e alr eady fam iliar w it h ent er pr ise soft w ar e at som e level. B2B and B2C ar e j ust som e of t he m ore popular m anifest at ions of ent erprise soft ware.

This int roduct ory chapt er offers a m ore in -dept h explorat ion of ent erprise soft ware and t he challenges and opport unit ies t hat accom pany it .

What Is Enterprise Software? The t erm ent er pr ise r efer s t o an or ganizat ion of indiv iduals or ent it ies, pr esum ably w or k ing t oget her t o achiev e som e com m on goals. Organizat ions com e in all shapes and sizes, large and sm all, for-pr ofit an d n on pr ofit , gov er n m en t al an d n on gov er n m en t al.

Chances ar e, how ever , t hat w hen som eone uses t he t er m ent er pr ise, t hey m ean a lar ge, f or-pr ofit or gan izat ion , su ch as I n t el, Gen er al Mot or s, Wal-Mar t , Bank of Am er ica, or eBay .

Ent er pr ises gener ally have som e com m on needs, such as infor m at ion shar ing and pr ocessing, asset m anagem ent and t racking, resource planning, cust om er or client m anagem ent , prot ect ion of business knowle dge, and so on. The t erm ent erprise soft w are is used t o collect iv ely r efer t o all soft w ar e inv olv ed in suppor t ing t hese com m on elem ent s of an en t er p r ise.

Fi g u r e 1 - 1

depict s en t er pr ise an d en t er pr is e soft w ar e gr aph ically .

Figure 1 - 1 . Ent erprise a nd ent erprise soft w a re

The figur e show s an ent er pr ise soft w ar e set up t hat is essent ially a collect ion of diver se syste m s. Soft ware is organized along t he various funct ions wit hin t he organizat ion, for exam ple, sales, hum an r esour ces, and so on. A fir ew all is pr ovided t o safeguar d ent er pr ise dat a from unaut horized access. Som e soft w are syst em s such as t hose for sales and i nvent ory m an agem en t in t er act ; h ow ev er , m ost ar e f air ly isolat ed islan ds of sof t w ar e.

Ent erprise soft ware m ay consist of a m ult it ude of dist inct pieces t oday, but ent erprises have gr adually com e t o r ealize t hat t her e is a st r ong need for t heir div er se sy st e m s t o int egrat e w ell and lev er age each ot her w her ev er appr opr iat e for m ax im um ent er pr ise benefit . B2B and B2 C ar e good ex am ples of su ch in t egr at ion an d lev er agin g.

Som e of t he pot ent ial w ay s an ent er pr ise hopes t o lev er age int egr at ed ent er pr ise soft w ar e fo llow s:

•

By int egrat ing it s cust om er support and in -house pr oduct know ledge, an ent er pr ise cou ld pr ov ide n ew an d bet t er ser v ices t o it s cu st om er s v ia t h e Web.

•

By link ing it s m ar k et ing m achine w it h t he online w or ld, an ent er pr ise could r each a m uch lar ger audien ce on lin e.

•

By linking it s sales m anagem ent and invent or y, an ent er pr ise m ay be able t o devise specif ic, low er cost Web sales ch an n els t o r each an u n t apped m ar k et segm en t .

•

By providing a front end t o one of t he services used by it s em ployees, such as t he int er nal office supply or der ing syst em , and t ying it int o t he account ing syst em , t he ent er pr ise could low er t he ov er all cost and im pr ov e em ploy ee efficiency .

•

Mak ing t he ent er pr ise HR sy st em av ailable online could be used as a w ay t o giv e em ployees m ore cont rol over t heir healt h and 401( k) choices and reduce t he overall adm in ist r at iv e cost s t o t h e en t er pr ise.

•

By aut om at ing one of it s hum an resource int ensive operat ions and m aking it available on an anyt im e, anywhere basis, an ent erprise could provide bet t e r service t o it s cu st om er s w h ile r edu cin g t h e ov er all oper at ion al cost s.

Challenges in Developing Enterprise Software

Successful ent er pr ises t end t o gr ow in size, hir e m or e people, hav e m or e cust om er s and m or e Web sit e hit s, hav e bigger sales and r ev enues, add m or e locat ions, and so on. I n or der t o support t his grow t h, ent erprise soft w are m ust be scalable in t erm s of accom m odat ing a lar g er en t er p r ise an d it s op er at ion s.

Ent er pr ises encount er const r aint s as t hey gr ow . One com m on const r aint is t he com put er h ardware's inabilit y t o scale as t he ent erprise's processing needs increase. Anot her const r aint is t he ent er pr ise's abilit y t o put m or e people in t he sam e phy sical or ev en geogr aphical locat ion. Thus, t he challenge of dist r ibut ion com es int o t he pict ur e. Mult iple physical m achines solve t he processing needs but int roduce t he challenge of dist ribut ed soft w ar e. New building or geogr aphical locat ions addr ess t he im m ediat e need, but t hey int r oduce t he challenge of br inging t he sam e lev el of ser v ices t o a div er sely locat ed en t er p r ise.

Connect ing pr eviously separ at e syst em s in or der t o gain ent er pr ise-scale efficiencies can be a m aj or challenge. Legacy syst em s w ere t ypically designed w it h specific purposes in m ind and w er e not specifically conceived w it h int egr at ion w it h ot her syst em s in m ind. For exam ple, hum an r esour ce m anagem ent per haps w as t r eat ed as a dist inct need w it hout m uch int er act ion w it h financial m anagem ent , and sales m anagem ent had lit t le, if anyt hing, t o do

w it h cust om er suppor t . This disj oint ed appr oa ch t o soft w ar e developm ent oft en r esult ed in excellent point pr oduct s being pur chased t o addr ess specific needs, but it com m only r esult ed in sof t w ar e ar ch it ect u r es t h at w er e dif f icu lt t o in t egr at e.

A relat ed challenge is t he need t o deal w it h a m ult ivendor environm ent . Part ly out of evolut ion, and part ly out of necessit y, ent erprise soft w are has oft en ended up w it h sim ilar product s from m ult iple vendors used for t he sam e purpose. For inst ance, alt hough t he HR applicat ion m ight be built on an Or acle 8i dat abase, t he cust om er support applicat ion m ight r ely on Micr osoft SQL Ser v er .

Ent er pr ise soft w ar e also t ypically r equir es som e com m on capabilit ies, such as secur it y ser vices t o safeguar d t he ent er pr ise know ledge, t r ansact ion ser vices t o guar ant ee int egr it y of dat a, and so on. Each of t hese requires specific skills and knowledge. For inst ance, proper t ransact ion handling requires st rat egies for recovering from failures, handling m ult iuser sit uat ions, ensuring consist ency across t ransact ions, and so on. Sim ilarly, im plem ent ing securit y m ight dem and a grasp of various securit y prot ocols and securit y m anagem ent ap p r oach es.

These ar e j ust som e of t he com m on challenges t hat m ust be addr essed w hen dealing w it h en t er p r ise sof t w ar e d ev elop m en t .

Evolution of Enterprise Software Not t oo long ago, m ainfr am es r uled t he w or ld, and all soft w ar e w as t ied t o t his cent r al ent it y . The adv ant ages of such a cent r alized appr oach included t he sim plicit y of dealing w it h a single sy st em for all processing needs, colocat ion of all resources, and t he like. On t he disadvant age fr ont , it m eant hav ing t o deal w it h phy sical lim it at ions of scalabilit y , single point s of failur e, lim it ed accessibilit y fr om r em ot e locat ions, and so on.

Such cent r alized applicat ion s ar e com m on ly r efer r ed t o as single t ier applicat ions. The Random House dict ionar y defines a t ier as " one of a ser ies of r ow s, r ising one behind or abov e an ot h er . " I n sof t w ar e, a t ier is pr im ar ily an abst r act ion an d it s m ain pu r pose is t o h elp u s u n der st an d t h e ar ch it ect u r e associat ed w it h a specif ic applicat ion by br eak in g dow n t h e soft w ar e int o dist inct , logical t ier s. See

Ch a p t e r 6

f or a m or e det ailed discu ssion of t iers.

Fr om an applicat ion per spect iv e, t h e sin gle m ost pr oblem at ic aspect of a sin gle t ier applicat ion w as t h e in t er m in glin g of pr esen t at ion , bu sin ess logic, an d t h e dat a it self . For

in st an ce, assu m e t h at a ch an g e w as r eq u ir ed t o som e asp ect of t h e sy st em . I n a single tier applicat ion, all aspect s w er e pr et t y m uch fused; t hat is, t he pr esent at ion side of t he soft w ar e w as t ied t o t he business logic, and t he business logic port ion had int im at e know ledge of t he dat a st r uct ur es. So any changes t o one pot ent ially h ad a r ipple effect and m eant r ev alidat ion of all aspect s. Anot her dr aw back of such int er m ingling w as t he lim it at ions it im posed on t he r eu se of bu sin ess logic or dat a access capabilit ies.

The client -ser ver appr oach alleviat ed som e of t hese m aj or issues by m oving t he present at ion aspect s an d som e of t h e bu sin ess logic t o a separ at e t ier . How ev er , f r om an applicat ion perspect ive, t he business logic and present at ion rem ained very m uch int erm ingled. As well, t h is t w o-t ier approach int roduced som e new issues of it s own, for inst ance, t he challenge of updat ing applicat ion soft w are on a large num ber of client s w it h m inim al cost and disrupt ion.

Th e n -t ier appr oach at t em pt s t o ach iev e a bet t er balan ce ov er all by separ at in g t h e pr esent at ion logic fr om business logic a nd t he business logic fr om t he under ly ing dat a. The t er m n -t ier ( as opposed t o t hree-t ier) is r epr esent at ive of t he fact t hat soft w ar e is not lim it ed t o t h r ee t ier s on ly , an d can be an d in deed is, or gan ized in t o deeper lay er s t o m eet specif ic n eed s.

I t sh ou ld be n ot ed t h at each t ier in an n -t ier does n ot im ply a separ at e piece of h ar dw ar e, alt h ou gh t h at is cer t ain ly possible. A t ier is, abov e all, a separ at ion of con cer n s w it h in t h e soft w ar e it self. The differ ent t ier s ar e logically dist inct w it hin t he softw are but m ay physically ex ist on t h e sam e m ach in e or be dist r ibu t ed acr oss m u lt iple m ach in es.

Som e ex am ples of t h e t y pes of adv an t ages an d ben ef it s of f er ed by n -t ier com put ing ar e

•

Fast er and pot ent ially lower cost developm ent : New ap p licat ion s can b e d ev elo p ed f ast er b y r eu sin g ex ist in g , p r et est ed b u sin ess an d d at a access com p on en t s.

•

I m pact of changes is isolat ed: As lon g as in t er f aces r em ain u n ch an ged, ch an ges on on e t ier do n ot af f ect com pon en t s on an ot h er t ier .

•

Changes are m ore m anageable: For ex am ple, it is easier t o r eplace one ver sion of a business com ponent w it h a new one if it is r esiding on a business t ier ( on one or a few dedicat ed ser v er s) r at h er t h an h av in g t o r eplace h u n dr eds or t h ou san ds of clien t ap p licat ion s ar ou n d t ow n , or ar ou n d t h e g lob e.

Fi g u r e 1 - 2

illu st r at es en t er p r ise sof t w ar e or g an ized alon g t h ese sin g le, t w o, an d n -t ier s.

Figure 1 - 2 . Archit ect ural evolut ion of ent erprise soft w are

Enterprise Software and Component-Based Software When t he obj ect -or iented soft w are approach burst ont o t he soft w are developm ent scene, it w as w id ely ex p ect ed t h at ad op t ion of ob j ect -or ien t ed sof t w ar e d ev elop m en t t ech n iq u es w ou ld lead t o r eu se, bu t t h is h ope w as on ly par t ially r ealized. On e of t h e r eason s f or t h is par t ial success w as t h e fin e gr an u lar it y of t h e obj ect s an d t h e u n der ly in g difficu lt y of achiev ing lar ge-scale r eu se at t h at lev el du e t o t h e m or e st r on gly cou pled n at u r e of fine-g r ain ed ob j ect s.

Soft ware com ponent s are designed t o address t his precise issue. Unlike a n obj ect , a soft w ar e com pon en t is design ed at a m u ch h igh er lev el of abst r act ion an d pr ov ides a com plet e funct ion or a ser v ice. Soft w ar e com ponent s ar e m or e loosely coupled. Using int er faces t he com ponent s hav e deliber at ely ex posed, t hey can be com bined t oget her rapidly t o build larger applicat ions quick ly and ar e m or e cost -effect iv e.

Com p on en t -based soft w ar e, of cour se, r equir es t hat com ponent s fr om differ ent sour ces be com pat ible. That is, an underlying com m on underst anding, a cont ract if you will, is req uired on w h ich t h e com p on en t s ar e t o b e d ev elop ed .

Var iou s com ponent m odels h av e b een d ev elop ed ov er t h e y ear s t o p r ov id e t h e com m on underst anding. Microsoft 's Act iveX, lat er COM, and Sun Microsyst em 's applet s and JavaBeans ar e ex am ples of su ch com pon en t m od els.

Dist r ib u t ed com p on en t m od els h av e also b een d ev elop ed t o ad d r ess com p on en t -b a sed sof t w ar e in t h e con t ex t of d ist r ib u t ed en t er p r ise sof t w ar e an d associat ed ch allen g es discu ssed ear lier . Su ch com pon en t m odels essen t ially pr ov ide an " oper at in g sy st em " for dist r ibu t ed an d com pon en t -based soft w ar e dev elopm ent . Ex am ples of t hese include DCOM, Micr osoft DNA ( now Microsoft.NET ) , and Sun Microsyst em 's Ent erprise JavaBeans ( EJB) , which is par t of t h e Jav a 2 Pla t for m , Ent er pr ise Edit ion ( J2EE) .

Summary Ent er pr ise soft w ar e has under gone a gr adual ev olut ion in pur suit of pr ov iding ev er-great er value t o t he ent erprise. Ent erprise soft ware faces som e dist inct challenges. These include, am ong ot her s, scalabilit y , dist r ibut ion, secur it y , and t he need t o w or k w it h a div er se set of vendor t echnology. Various evolut ionary archit ect ural approaches have been t ried over t he years t o m eet such challenges. An increasingly popular solut ion revolves around using a dist r ibut ed component m odel t o develop super ior ent er pr ise soft w ar e. Such dist r ibut ed com ponent m odels hold pr om ise, but t hey ar e st ill in t heir infancy .

Chapter 2. Introduction to the J2EE •

W h a t I s t h e Ja v a 2 Pl a t f o r m , En t e r p r i se Ed i t i o n ?

•

A B r i e f H i s t o r y o f J2 EE

•

W h y J2 EE?

•

A Br i e f Ov e r v i e w o f J2 EE

•

Su m m ar y

Sun Microsyst em s has organized t he Java 2 Plat form along t hree specific focused areas, or edit ions: Micro Edit ion ( J2ME) , St andard Edit ion ( J2SE) , and Ent erprise Edit ion ( J2EE) .

Of t hose product s, J2EE is t he m ost relevant t o developing ent erprise Java applicat ions.

What Is the Java 2 Platform, Enterprise Edition? Th e J2 EE defin es an ar ch it ect u r e for dev elopin g com plex , dist r ibu t ed en t er pr ise Jav a applicat ion s.

J2EE was originally announced by Sun Microsyst em s in m id -1999 and w as officially released in lat e 1 9 9 9 . The J2 EE, being r elat iv ely new , is st ill under going significant changes fr om r elease t o r elease, especially in t h e ar ea of En t er pr ise Jav aBean s ( EJB) .

Th e J2 EE con sist s of t h e f ollow in g:

•

Design gu idelin es f or dev elopin g en t er pr ise applicat ion s u sin g t h e J2 EE

•

A r ef er en ce im plem en t at ion t o pr ov ide an oper at ion al v iew of t h e J2 EE

•

A com pat ibilit y t est suit e for use by t hird part ies t o verify t heir product s' com pliance t o t h e J2 EE

•

Sev er al Applicat ion Pr ogr am m ing I nt er faces ( API s) t o enable gener ic access t o en t er pr ise r esou r ces an d in f r ast r u ct u r e

•

Tech n ologies t o sim plify en t er pr ise Jav a dev elopm en t

Fi g u r e 2 - 1

illu st r at es t h e r elat ion sh ip bet w een t h e J2 EE plat for m elem en t s gr aph ically .

Figure 2 - 1 . The J2 EE plat form elem ent s

The plat for m bu ilds on t h e Jav a m an t r a of " Wr it e On ce, Ru n An y w h er e" v ia a gr ou p of t ech n ologies an d a set of API s. Th ese ar e, in t u r n , su ppor t ed an d bou n d by t h r ee k ey elem ent s, nam ely t he reference im plem ent at ion, t he design guidelines, and t he com pat ibilit y su it e.

A Brief History of J2EE How J2 EE cam e abou t is qu it e in t er est in g. Jav a, or igin ally n am ed Oak , w as con ceiv ed as a sof t w ar e lan g u ag e f or d ev elop in g applicat ion s f or h ou seh old applian ces an d ot h er su ch dev ices. Wit h t h e I n t er n et r ev olu t ion , Jav a gr adu ally ev olv ed int o a language for client -side dev elopm en t w it h capabilit ies su ch as applet s an d Jav aBean s. Alon g t h e w ay , sev er al Jav a API s, such as Java Dat abase Connect ivit y ( JDBC) , w ere developed t o address m arket needs f or g en er ic access an d u sag e of r esou r ces t y pically r equ ir ed by en t er pr ise soft w ar e applicat ion s.

I t w as clear soon af t er Jav a' s in t r odu ct ion t h at t h e u se of Jav a on t h e clien t side in a b r o w ser-based sy st em s en v ir on m en t f aced som e ser iou s ch allen ges, su ch as t h e lat en cy

inv olv ed in t he loading of Java libr ar ies over t he I nt er net befor e a client -side Java applicat ion could st ar t up. How ev er , Jav a's r elat iv e sim plicit y , plat for m-in depen den t ar ch it ect u r e, an d r ich set of API s as w ell as it s Web en ab led n at u r e w er e st r on g p osit iv es f or it s u se in en t erp r ise sof t w ar e d ev elop m en t .

This ease of use and Web enabled nat ure of Java led t o a relat ively wide adopt ion of Java for W e b -cent r ic dev elopm ent . Dev eloper s used Jav a t echnologies, such as applet s, for v isuals an d dy n am ic ou t pu t t h at cou ld easily be added in t o st an d ar d HTML p ag es on Web sit es.

Alt hough Jav a applicat ions could be r un on ser v er s, Jav a init ially did not offer any specific capabilit ies for ser v er-side u se. Su n r ealized t h e pot en t ial f or u sin g Jav a as a lan gu age f or W e b -b ased ap p licat ion s an d s ou gh t t o adapt it f or t h e ser v er side v ia t h e Jav a Ser v let specificat ion . On ce t h e adapt at ion occu r r ed, t h e Web clien t cou ld call in t o a Jav a pr ogr am r unning on a r em ot e ser ver , and t he ser ver pr ogr am could pr ocess t he r equest and pass back m eaningful resu lt s. The concept of t he servlet w as bor n and has been ut ilized fair ly heavily for ent erprise applicat ion developm ent . Servlet s, how ever, w ere never really designed t o handle com plex issu es r elat ed t o cu st om er t r an sact ion s, session con cu r r en cy , sy n ch r on ization of d at a, an d so on .

EJB, originally released as an independent specificat ion by Sun Micro syst em s, was int ended t o sim plify ser v er-side dev elopm ent by pr ov iding a v er y lar ge set of out -o f-t he -box services t o h an dle t h e k ey en t er pr ise applicat ion dev elo p m en t issu es.

The concept of n -t ier ar ch it ect u r e h as been ar ou n d a lon g t im e an d h as been su ccessf u lly used for building ent erprise -scale applicat ions. Sun's em bracem ent of t he n -t ier developm ent m odel for Jav a, and int r oduct ion of specific funct ionalit y t o per m it easier ser v er-sid e d ev elop m en t of scalab le Web -based ent er pr ise applicat ions, gav e Jav a t he cr it ical m issing in gr edien t it n eeded in t h is ar en a.

Th e J2 EE is t h e r esu lt of Su n ' s ef f or t t o align t h e dispar at e Jav a t ech n ologies an d API s t og et h er in t o coh esiv e Jav a dev elopm en t plat for m s for dev elopin g specific t y pes of applicat ions. Thr ee Jav a plat for m s cur r ent ly ex ist . Each successiv e one list ed can concept ually ( but not necessar ily t echnologically ) be consider ed a super set of t he pr ev ious o n e:

•

Java 2 Plat form , Micro Edit ion ( J2ME) : Plat f or m f or t h e dev elopm en t of sof t w ar e f or em b ed d ed d ev ices su ch as p h on es, p alm t op s, an d so on .

•

Java 2 Plat form , St andard Edit ion ( J2SE) : Most fam iliar of t he Java 2 plat form s. I t is also k n ow n as t h e Jav a Dev elopm en t Kit ( JDK) and includes capabilit ies such as ap p let s, Jav aBean s, an d so on .

•

Java 2 Plat form , Ent erprise Edit ion ( J2EE) : Plat for m for dev elopin g en t er pr ise-scale applicat ion s. I t is design ed t o be u sed in con j u n ct ion w it h t h e J2 SE.

Fi g u r e 2 - 2

pr ov ides an ov er v iew of t h e t h r ee ex ist in g Jav a 2 plat f or m s.

Figure 2 - 2 . Ove r vie w of t he Ja va 2 pla t for m s

Why J2EE?

You are probably asking: So, why use t he J2EE? I sn't it t oo new and unproven? What does it r eally offer ? I s it j u st an ot h er fad?

Let 's st ar t w it h t he new ness aspect . Alt hough t he J2EE pack aging is new , specific pieces t hat m ake up t he J2EE have been around for a w hile. For inst ance, t he JDBC API is well est ablished. Ser v let t ech n ology h as also been u sed f or som e t im e as a ligh t w eigh t an d m ain t ain able alt er n at iv e t o t h e Com m on Gat ew ay I n t er face ( CGI ) [ 1 ] scr ipt s. [ 1]

An older appr oach used for pr ocessing user input pr ov ided v ia t he Web and for pr ov iding

dy n am ic con t en t based on t h e in pu t .

J2 EE also of f er s som e pr om isin g ben ef it s. As descr ibed in t h e f ollow in g par agr aph s, t h ese in clu d e f eat u r es t h at en ab le d ev elop er s t o f ocu s on d ev elop in g bu sin ess logic, on im plem en t in g t h e sy st em w it h ou t pr ior det ailed k n ow ledge of t h e ex ecu t ion en v ir on m en t , an d on cr eat in g sy st em s t h at can be por t ed m or e easily bet w een h ar dw ar e plat f or m s an d oper at in g sy st em s ( OSs) .

Ent er pr ise soft w ar e dev elopm ent is a com plex t ask and can r equir e ext ensive know ledge of m any differ ent ar eas. For inst ance, a t ypical ent er pr ise applicat ion developm ent effor t m ight r equir e t hat y ou be fam iliar w it h int er pr ocess com m unicat ion issues, secur it y issues, dat abase specific acce ss qu er ies, an d so on . J2 EE in clu des bu ilt -in and lar gely t r anspar ent su ppor t f or t h ese an d sim ilar ser v ices. As a r esu lt , dev eloper s ar e able t o f ocu s on im plem en t in g bu sin ess logic code r at h er t h an code t h at su ppor t s basic applicat ion infr ast r uct ur e.

Th e J2EE ent er pr ise developm ent m odel also encour ages a cleaner par t it ion bet w een syst em developm ent , deploym ent , and execut ion. Because of t his, developer s can defer deploym ent det ails, such as t he act ual dat abase nam e and locat ion, host specific configur at ion propert ies, an d so on , t o t h e d ep loy er .

J2 EE suppor t s har dw ar e and OS independence by enabling sy st em ser v ices t o be accessed v ia Jav a an d J2 EE r at h er t h an u n der ly in g sy st em API s. For t h is r eason , en t er pr ise sy st em s t hat confor m t o t he J2 EE ar chit ect ural specif icat ion can be por t ed f air ly easily bet w een dif f er en t h ar dw ar e sy st em s an d dif f er en t OSs.

Per h aps on e of t h e gr eat est J2 EE ben ef it s is it s su ppor t f or com pon en t izat ion . Com p on en t -b ased sof t w ar e h as n u m er ou s ad v an t ag es ov er t r ad it ion al, cu st om sof t w ar e dev elopm en t :

•

Higher product ivit y: Few er dev eloper s can ach iev e m or e by pu t t in g t oget h er an applicat ion from prebuilt , pret est ed com ponent s rat her t han im plem ent ing a cust om solut ion fr om scr at ch.

•

Rapid developm ent : Ex ist ing com ponent s can be put t ogether rapidly t o creat e new applicat ion s.

•

Higher qualit y: Rat her t han t est ing ent ir e applicat ions, com ponent -based applicat ion dev eloper s can con cen t r at e on t est in g t h e in t egr at ion an d t h e ov er all applicat ion funct ionalit y achiev ed v ia t he pr ebuilt com ponent s.

•

Easier m aint enance: Becau se com p on en t s ar e st an d -alon e t o begin w it h , m ain t en an ce su ch as u pgr ades t o in div idu al com pon en t s is m u ch easier an d m or e cost -effect iv e.

Alt hough som e level of soft ware com ponent izat ion does exist , it is a far cry from t he t yp e of com ponent izat ion prevalent in ot her indust ries, such as elect ronics or aut om obiles. I m agine t he dim inished elect r onics indust r y if each and ev er y chip r equir ed needed t o be handcr aft ed in or d er t o p u t t og et h er a n ew elect r on ic g ad g et .

J2EE facilit at es com pon en t izat ion in m an y w ay s. A f ew ex am ples f ollow :

•

Th e " Wr it e On ce, Ru n An y w h er e" n at u r e of Jav a m ak es it appealin g f or dev elopin g com p on en t s f or a d iv er se set of h ar d w ar e sy st em s an d op er at in g sy st em s.

•

J2EE offer s a w ell t hought -out appr oach for separat ing t he dev elopm ent aspect s of a com ponent fr om it s assem bly specifics and it s assem bly aspect s fr om it s deploym ent det ails. Th u s, com pon en t s dev eloped in depen den t ly can be r eadily in t egr at ed in t o n ew en v ir on m en t s an d applicat ion s.

•

J2 EE of f er s a w ide r an ge of API s t h at can be u sed f or accessin g an d in t egr at in g product s provided by t hird -part y vendors in a uniform w ay, for exam ple, dat abases, m ail sy st em s, m essagin g plat for m s, an d so on .

•

J2EE offers specialized com ponent s t hat are opt im ized for specific t ypes of r oles in an en t er pr ise applicat ion . For ex am ple, en t er pr ise com pon en t s can be dev eloped in dif f er en t " f lav or s, " depen din g on w h at t h ey ar e ex pect ed t o accom plish .

Com pon en t m ar k et places h av e alr eady st ar t ed t o em er ge. A r ecen t Gar t n er Gr ou p st u dy fo r ecast ed t hat by 2003, 70 per cent of all new applicat ions w ould be built fr om com ponent s. J2 EE, w it h it s su ppor t for com pon en t -based dev elopm ent ( CBD) , r apid adopt ion, and br oad in du st r y su ppor t , sh ou ld play a pr om in en t r ole in t h is sw it ch t o CBD.

A Brief Overview of J2EE The J2EE t echnologies and API s cover a broad spect rum of ent erprise Java developm ent . I t is unlikely you w ill use each and every aspect of t he J2EE in your ent erprise Java developm ent effor t . But it is alw ay s helpful t o hav e t he big pict ure in m ind, so t he int ent in t his sect ion is t o m ak e y ou aw ar e of w h at is in t h e J2 EE.

I n t he rest of t he book, w e cover t he t echnologies in t he cont ext of m odeling t hem w it h t he Un ified Modelin g Lan gu age ( UML) . We also cov er som e, bu t n ot all, of t h e API s. I f y ou ar e in t er est ed in a specif ic API , see t h e Ref er en ces sect ion at t h e en d of t h is book f or a list of r esou r ces f or f u r t h er r eadin g.

Technologies

To underst and t he J2EE t echnologies, you m ust first underst and t he role of t he cont ainer in t he J2EE ar ch it ect ur e. All cur r ent t echnologies in t he J2 EE r ely on t his sim ple y et pow er ful con cept .

Fi g u r e 2 - 3

illu st r at es t h e r ole of t h e con t ain er w it h in t h e J2 EE.

Figure 2 - 3 . The cont ainer concept

A con t ain er is a sof t w ar e en t it y t h at r u n s w it h in t he ser v er and is r esponsible for m anaging specific t y pes of com pon en t s. I t pr ov ides t h e ex ecu t ion en v ir on m en t for t h e J2 EE com ponent s y ou dev elop. I t is t hr ough such cont ainer s t hat t he J2 EE ar chit ect ur e is able t o p r ov id e in d ep en d en ce b et w een d ev elop m en t an d deploy m en t an d pr ov ide por t abilit y bet w een div er se m iddle t ier ser v er s.

A cont ainer also is r esponsible for m anaging t he life cy cle of com ponent s deploy ed w it hin it and for t hings such as r esour ce pooling and enfor cing secur it y . For inst ance, y ou can rest rict t he abilit y t o access a specific m et hod t o a sm all gr oup of caller s. The cont ainer w ould t hen enforce t his rest rict ion by int ercept ing request s for t hat m et hod and ensuring t hat t he ent it y r equ est in g access is in t h e pr iv ileged list .

Depending on t he cont ainer t ype, it m ay also provide access t o som e or all of t he J2EE API s.

All J2EE com ponent s ar e deployed and execut ed w it hin som e kind of a cont ainer . For inst ance, EJBs r un w it hin t he EJB cont ainer , and ser v let s r un in t he Web cont ainer . I n all, t he J2EE has fou r differ en t k in ds of con t ain er s:

•

Applicat ion cont ainer: Host s st an d -alon e Jav a applicat ion s

•

Applet cont ainer: Pr ov ides an ex ecu t ion en v ir on m en t f or applet s

•

Web cont ainer: Host s t h e Web com pon en t s, su ch as ser v let s an d Jav aSer v er Pages ( JSP)

•

Ent erprise cont ainer: Host s EJB com pon en t s

Servlets

Ser v let s ar e Web com pon en t s capable of gen er at in g dy n am ic con t en t . Th ey ar e on e of t h e m ost fr equent ly used J2EE com ponent s found on t he Wor ld Wide Web t oday . They pr ov ide an effect iv e m echanism for int e r act ion b et w een t h e ser v er-b ased b u sin ess log ic an d t h e W e b -based clien t , an d t h ey pr ov ide a ligh t w eigh t an d m or e m an ageable alt er n at iv e t o t h e popu lar CGI scr ipt in g appr oach .

Because servlet s are sim pler and require few er resources in general, som e develo pers prefer t o use t hese com ponent s along wit h JSPs alm ost exclusively in t heir im plem ent at ions rat her t han m aking use of t he m ore com plex EJB com ponent s. This pract ice m ight m ake sense for very sim ple ent erprise applicat ions, but quickly becom es a less t h an opt im al choice whenever t r an sact ion su ppor t is n eeded in t h e applicat ion .

Ser v let s ar e best used t o handle sim pler t ask s, lik e gat her ing and check ing for v alid input s fr om t he ent r y fields of a Web page. When t he pr elim inar y check s ar e done, t he dat a sh ould t h en b e p assed t o a m or e su it ab le com p on en t t o p er f or m t h e act u al t ask at h an d .

Ser vlet s r un inside t he ser vlet cont ainer ( also r efer r ed t o as t he ser vlet engine) host ed on a Web server. The servlet cont ainer m anages t he life cycle of a servlet and t ranslat es t he Web client ' s r equest s, m ade v ia pr ot ocols such as t he Hy per t ex t Tr ansfer Pr ot ocol ( HTTP) , int o obj ect -based r equ est s. Lik ew ise, t h e con t ain er t r an slat es t h e r espon se f r om a ser v let an d m ap s t h e r esp on se ob j ect t o t h e ap p r op r iat e Web p r ot ocol.

JSP

JSPs ar e anot her t y pe of J2EE Web com ponent and hav e ev olv ed fr om ser v let t echnology . I n f act , por t ion s of JSPs ar e com piled in t o ser v let s t h at ar e t h en ex ecu t ed w it h in t h e ser v let con t ain er en v ir on m en t .

JSPs cam e int o being t o m ake it easier for m em be r s of a Web t eam t o m aint ain t he por t ions of t h e sy st em t h at su ppor t Web page pr esen t at ion w it h ou t r equ ir in g t h em t o be t r adit ion al

pr ogr am m er s. Nonpr ogr am m er s t y pically m aint ain t he pr esent at ion code in t he Hy per Tex t Mar k up Language ( HTML) . This is har der t o d o w h en t h at HTML is g en er at ed b y Jav a st at em en t s con t ain ed w it h in ser v let s.

JSPs per m it Jav a code t o be em bedded w it h in a st r u ct u r ed docu m en t su ch as HTML or eXt en sible Mar k u p Lan gu age ( XML) . Th is allow s t h e pr esen t at ion code t o be easily m aint ained a s r egular HTML code and shields nont echnical cont r ibut or s fr om code edit or s, an d so o n .

Becau se JSPs allow f or v er y com plex Jav a code t o be em bedded w it h in t h ese HTML or XML docu m en t s, som e dev eloper s ch ose t o u se t h is m et h od du r in g t h e ear ly day s of JSP t ech n ology . How ev er , it is gen er ally good pr act ice t o k eep t h e Jav a code w it h in a JSP r elat iv ely sim ple.

Som e ot her Java t echnologies t hat have been ar ound for a w hile, like JavaBeans, also t ie int o t he use of JSPs. They help t o m ake it less com plicat ed t o display larger am ount s of dat a for t h in g s lik e t ab les in Web p ag es.

EJB

The EJB specificat ion is at t he v er y cor e of t he J2 EE plat for m . I t defines a com pr ehensiv e com ponent m odel for building scalable, dist r ibut ed ser v er-based ent er pr ise Java applicat ion com p on en t s.

Th er e ar e t h r ee t y pes of EJBs:

•

Session beans ar e best used for t r ansient act ivit ies. They ar e nonper sist ent and oft en en capsu lat e t h e m aj or it y of bu sin ess logic w it h in an en t er pr ise Jav a applicat ion . Session beans can be st at eful, m eaning t hey ret ain connect ions bet ween successive int er act ions w it h a client . The ot her t y pe of session bean is st at eless. I n t he case of a st at eless session bean, each successiv e inv ocat ion of t he session bean by t he sam e clien t is t r eat ed as a n ew , u n r elat ed act iv it y .

•

Ent it y beans encapsulat e per sist ent dat a in a dat a st ore, which is t ypically a com plet e or par t ial r ow of in f or m at ion f ou n d in a dat abase t able. Th ey pr ov ide au t om at ed ser v ices t o en su r e t h at t h e obj ect -or ien t ed v iew of t h is p er sist en t d at a st ay s sy nchr o n ized at all t im es w it h t h e act u al dat a r esidin g in t h e u n der ly in g dat abase.

En t it y bean s also ar e oft en u sed t o for m at t h is dat a, eit h er t o assist in t h e bu sin ess log ic of t h e t ask at h an d or t o p r ep ar e t h e d at a f or d isp lay in a Web p ag e. As an exam ple, in a dat abase t able of em ployees, each record could m ap t o an inst ance of an en t it y b ean .

•

Message-driven beans ar e design ed t o be con v en ien t , asy n ch r on ou s con su m er s of Jav a Messagin g Ser v ice ( JMS) m essages. Un lik e session an d en t it y bean s, m essag e-dr iv en bean s do n ot h av e pu blish ed in t er f aces. Rat h er , m essage-dr iv en beans oper at e anony m ously behind t he scenes. Message-dr iven beans ar e st at eless an d ar e a n ew t y pe of EJB com pon en t in t r odu ced in J2 EE 1 . 3 .

Th e Model-View -Cont roller ( MVC) archit ect ure, originally used in t he Sm allt alk pr ogr am m ing lan gu age, is u sef u l in u n der st an din g h ow t h ese dif f er en t J2 EE t ech n ologies f it an d w or k t oget her . For t hose unfam iliar w it h MVC ar chit ect ur e, t he basic idea is t o m inim ize t he coupling am ong obj ect s in a sy st em by aligning t hem wit h a specific set of responsibilit ies in t h e ar ea of t h e per sist en t dat a an d associat ed r u les ( Model) , pr esen t at ion ( View ) , an d t h e applicat ion logic ( Cont r oller ) . This is illust r at ed in

Fig u r e 2 - 4 .

Figure 2 - 4 . M odel- Vie w - Cont roller archit ect ure

Th e Model is r espon sible f or m ain t ain in g t h e applicat ion st at e an d dat a. I t can r eceiv e an d r espond t o quer ies fr om t he View and can pr ov ide not ificat ions t o t he View w hen t hings hav e ch an g ed .

The Cont roller updat es t he Model based on execut ion of applicat ion logic in response t o user gest ur es ( e. g. , dialog but t ons, for m subm it r equest s, et c. ) . I t is also r esponsible fo r t elling t h e View w h at t o d isp lay in r esp on se t o u ser g est u r es.

Th e View is r espon sible f or t h e act u al r en der in g of t h e dat a pr ov ided by t h e Con t r oller .

To illu st r at e, con sider a sim ple clock applicat ion dev eloped u sin g t h e MVC appr oach . Th e Model in t his case is essent ially r esponsible for k eeping t r ack of t im e. Tim e is aut om at ically u pdat ed at pr edefin ed in t er v als ( a m icr osecon d, m illisecon d, or som e ot h er u n it ) t h r ou gh som e built -in m ech an ism s in t h e Model. I t also pr ov ides oper at ion s so ot h er en t it ies can query t he Model and obt ain t he current t im e, but it does not care or know how t he t im e is t o b e d isp lay ed .

Th e r espon sibilit y for display in g t h e t im e falls on t h e View ; h ow ev er , t h e View can t ak e different form s. For exam ple, it m ay t ake t he form of an analog display whereby t wo ( or t hree) hands ar e used t o display t he t im e. I t can easily be a digit al display consist ing of sever al digit s as w ell. As t im e changes, t he Model not ifies t he View , and t he View updat es t o reflect t he new t im e.

Keep in m ind t ha t clocks require som e m echanism for updat ing t he t im e, for exam ple, when day light sav ings t im e goes int o effect . On a clock r ender ed in a Web br ow ser , t he user m ay have t he capabilit y t o indicat e a change in t im e by using som e Gr aphical User I nt er face ( GUI ) con t r ols or by t y pin g in a n ew t im e. Th e Con t r oller r eceiv es t h e u ser gest u r es f or su ch changes and updat es t he Model by calling t he appr opr iat e oper at ions defined on t he Model t o r ef lect t h e n ew t im e.

A Model m ay h av e sev er al sim u lt an eou s View s. For in st ance, a clock applicat ion r unning on t he Web m ay have several users ut ilizing it at t he sam e t im e, using different represent at ions, su ch as an alog, digit al, an d so on .

APIs

Ther e ar e sever al API s w it hin t he J2EE. Som e of t he m or e popular ones ar e discusse d in t he f ollow in g sect ion s.

JDBC

I nt er act ion w it h dat abases is an int egr al par t of an ent er pr ise Jav a applicat ion. The JDBC API is squ ar ely f ocu sed on m ak in g t h is aspect easier f or t h e en t er pr ise Jav a dev eloper .

The JDBC API , which is sim ilar in spirit t o Microsoft 's Open Dat abase Connect ivit y ( ODBC) API , sim plif ies access t o r elat ion al dat abases. I t con sist s of a gen er ic, v en dor in depen den t int erface t o dat abases. Using t he JDBC m akes your applicat ions port able and your dat abase sk ills applicable acr oss a w ider r an ge of v en dor plat f or m s.

The m aj or it y of t he JDBC API alr eady exist s as par t of t he J2SE. I t is not lim it ed t o use only w it h t h e J2 EE. Th er e ar e h ow ev er a f ew ex t en sion s t h at t h e J2 EE v er sion adds, m ost ly t o su ppor t som e adv an ced f u n ct ion s f or t h e J2EE cont ainer s t o use, lik e connect ion pooling as w ell as som e addit ion al su ppor t f or Jav aBean s.

The JDBC API pr ov ides a com m on int er face in or der t o shield t he user fr om v endor specific differ ences as m uch as possible. JDBC im plem ent at ions ar e supplied by t he dat abase vendor, so dif f er en t dat abases can act dif f er en t ly u n der t h e cov er s.

I n ent erprise applicat ions, you do not necessarily need t o use JDBC direct ly. For exam ple, you can use ent it y beans t o m ake t he necessary dat abase calls for you. The pract ice of using JDBC dir ect ly is ex pect ed t o becom e less com m on as applicat ion ser v er s pr ov ide m or e sop h ist icat ed an d w ell-t u n ed su p p or t f or en t it y b ean s.

Java Naming and Directory Interface (JNDI)

I n t he cont ext of JNDI , " nam ing" act ually r efer s t o a nam ing service. Nam ing services allow y ou t o look up, or r efer t o, an obj ect . A file sy st em is an ex am ple of a nam ing ser v ice.

A dir ect or y ser v ice is sim ilar t o a n am in g ser v ice an d pr ov ides en h an ced sear ch in g capabilit ies. I n fact , a dir ect or y ser v ice alw ay s has a nam ing ser v ice ( but not v ice v er sa) .

Ther e ar e v ar ious nam ing and dir ect or y ser v ices av ailable, so t he challenges on t his fr ont ar e quit e sim ilar t o t hose in t he area of dat abases. JNDI is designed t o address t hose challenges by pr ov idin g a gen er ic an d u n if or m w ay t o access t h e ser v ices.

Th e com plet e JNDI API alr eady ex ist s as par t of J2 SE, alt h ou gh it is list ed as an en t er pr ise feat ur e. Most dist r ibut ed ent er pr ise applicat ions m ake use of t his ser vice at som e point . For ex am ple, any use of EJBs in an ent erprise applicat ion necessit at es t hat JNDI be used t o find t h e associat ed EJB Hom e in t er f aces.

JMS

A m essagin g ser v ice allow s com m u n icat ion am on g dist r ibu t ed applicat ion s u sin g self-cont ained ent it ies called m essages. Such com m unicat ion is t y pically asy nch r on ou s.

Var iou s v en dor s pr ov ide m essagin g or ien t ed m iddlew ar e. Th e JMS pr ov ides a u n ifor m an d gen er ic in t er f ace t o su ch m iddlew ar e.

JMS can be u sed dir ect ly in an en t er pr ise applicat ion or v ia a t y pe of EJB k n ow n as a m essag e-d r iv en b ean . Messag e-dr iv en b ean s ar e n ew in J2 EE 1 . 3 .

Remote Method Invocation (RMI)

RMI enables access t o com ponent s in a dist r ibut ed envir onm ent by allow ing Java obj ect s t o inv ok e m et hods on r em ot e Jav a obj ect s. The m et hod is act ually inv ok ed on a pr ox y obj ect , w hich t hen ar r anges t o pass t he m et hod and param et ers ont o t he rem ot e obj ect and provides t h e r espon se f r om t h e r em ot e obj ect back t o t h e obj ect t h at in it iat ed t h e r em ot e m et h od inv ocat ion.

RMI is not exclusive t o J2EE. How ever , RMI is at t he hear t of som e J2EE t echnologies, such as EJB.

Other J2EE Technologies and APIs

I n t his sect ion, w e list som e ot her J2EE t echnologies and API s t hat ar e eit her in exist ence now or ar e ex pect ed t o becom e par t of J2 EE in t h e f u t u r e.

J2EE Connectors

J2 EE Con n ect or s pr ov ide a com m on ar ch it ect u re t o u se w h en d ealin g w it h En t er p r ise I n f or m at ion Sy st em s ( EI S) as t h e dat a st or e. Th ese lar ge sy st em s t en d t o be pr ev alen t in h u ge en t er pr ises, an d t h ey can be v er y com plex t o deal w it h .

Java Transaction API (JTA)

A t r an sact ion r ef er s t o a gr ou pin g of m u lt iple oper at ion s in t o a sin gle " at om ic" oper at ion . Thus, if part of a t ransact ion fails, t he ot her, previously execut ed operat ions are " rolled back," t h at is, u n don e, t o en su r e san it y of t h e sy st em .

The JTA pr ov ides a gener ic, high-level API for t ransact io n m anagem ent . I t is prim arily used for lar ge, dist r ibut ed, oft en com plex t r ansact ion pr ocessing, usually inv olv ing a num ber of lar ge, r em ot ely con n ect ed sy st em s.

Java IDL

The Jav a I nt er face Definit ion Language ( I DL) pr ov ides int er oper abilit y suppor t for t he Com m on Obj ect Request Br ok er Ar chit ect ur e ( CORBA) and t he indust r y st andar d I nt er net I n t er-Or b Pr ot ocol ( I I OP) . I t includes an I DL-t o-Jav a com piler an d a ligh t w eigh t Obj ect Request Br ok er ( ORB) .

RMI-IIOP

RMI -I I OP r efer s t o RMI using t he I I OP as t he com m u nicat ion pr ot ocol under t he cover s. I I OP is an Obj ect Man agem en t Gr ou p ( OMG) st an dar d. Becau se CORBA u ses I I OP as t h e under ly ing pr ot ocol, t he use of RMI -I I OP m ak es in t er oper abilit y bet w een RMI an d CORBA obj ect s sim pler . RMI -I I OP is t y pically also m or e efficient t han RMI ov er t he Jav a Rem ot e Met hod Pr ot ocol ( JRMP) .

Java Transaction Service (JTS)

JTS is a t r an sact ion m an ager ser v ice t h at su ppor t s JTA an d m ak es u se of I I OP t o com m unicat e bet w een rem ot e inst ances of t he service. Like JTA, it is used in large d ist ribut ed sy st em sit u at ion s.

JavaMail

JavaMail provides an API t o facilit at e int eract ion w it h e -m ail m essaging syst em s in a vendor in depen den t f ash ion . Th is API con sist s pr im ar ily of a set of abst r act classes t h at m odel a Java -based e -m ail syst em . I t is i nt ended for building sophist icat ed e -m ail-based applicat ions.

Not e, however, t hat it is possible t o provide e -m ail suppor t in an applicat ion w it hout using t he Jav aMail API .

Summary J2 EE of f er s a w ell t h ou gh t -out ar chit ect ur e for dev eloping com plex ent er pr ise Jav a applicat ion s.

J2 EE' s com bin at ion of t ech n ologies—nam ely EJB, ser v let s, and JSPs—an d it s gen er ic API ( JDBC, Jav aMail, JMS, et c. ) giv e it s user s v ar ious adv ant ages. Thus, dev eloping a J2EE applicat ion sim plifies t h e ov er all t ask of dev elopin g lar ge-scale dist r ibu t ed applicat ion s.

Som e of t he k ey challenges t hat ar e sim plified by J2 EE include dist r ibut ion of applicat ions acr oss m ult iple pr ocesses and pr ocessor s, secur it y , t r ansact ions, per sist ence m anagem ent , an d deploy m en t .

Chapter 3. Introduction to the UML •

UML Ov er v i ew

•

W h y Use t h e J2 EE a n d t h e UML To g e t h e r ?

•

Ch a l l e n g e s i n Mo d e l i n g J2 EE i n t h e UML

•

Ex t e n si o n Me ch a n i sm s i n t h e U M L

•

Th e A p p r o a c h t o J2 EE UML Mo d e l i n g

•

Su m m ar y

The Unified Modelin g Language ( UML) is a graphical language for t he m odeling and developm ent of soft ware syst em s. I t provides m odeling and visualizat ion support for all phases of soft ware developm ent , from requirem ent s analysis t o specificat ion, t o const ruct ion and deploym en t .

The UML has it s root s in several preceding obj ect - orient ed not at ions.[ 1 ] The m ost prom inent am ong t hem being t he not at ions popularized by Booch, Rum baugh, et al. and Jacobson, et al. So, even t hough t he UML has been form alized for j ust a few years, it s predecessors have been used t o design and specify soft ware-int ensiv e sy st em s since t he ear ly 1990s. [ 1]

The dist inct ion bet w een not at ion and m et hodology is a com m on source of confusion. The

UML is a not at ion t hat can be applied using m any differ ent appr oaches. These appr oaches ar e t h e m et h od olog ies.

The unificat ion of t he com pet ing not at ions cam e about in t he m id t o lat e 1990s. I n early 1997, several consort ia subm it t ed responses t o an Obj ect Managem ent Group ( OMG) Request for Proposal for a com m on m et am odel t o describe soft ware-int ensiv e sy st em s. A consor t ium headed by Rat ional Soft ware subm it t ed t he UML 1.0 specificat ion. This incorporat ed t he leading feat ures of several m odeling not at ions including t hose of Booch, Rum baugh, and Jacobson. At t he request of t he OMG, m ost of t he com pet ing consort ia cooperat ed wit h t he gr oup led by Rat ional t o r efine UML 1.0 int o UML 1.1, w hich w as accept ed by t he OMG in lat e 1997.

UML cont inues t o evolve under t he direct ion of t he OMG. For exam ple, recent ly proposed ext ensions provide com m on not at ions for dat a m odeling, Web applicat ion m odeling, and m apping J2EE const r uct s t o UML.

The UML has broad indust ry support . By virt ue of being t he specificat ion support ed by t he 850+ m em ber OMG, it is t he de j ure soft ware indust ry st andard for visual m odeling and developm ent . The fact t hat all leading t ools for m odeling soft ware-int ensiv e sy st em s now support UML m akes it t he de fact o st andard as well.

UML Overview Th e cen t r al idea beh in d u sin g t h e UML is t o capt u r e t h e sign if ican t det ails abou t a sy st em such t hat t he pr oblem is clear ly under st ood, solut ion ar chit ect ur e is developed, and a chosen im plem ent at ion is clear ly ident ified and const r uct ed.

A r ich not at ion for visually m odeling soft ware syst em s facilit at es t his exercise. The UML not on ly pr ov ides t h e n ot at ion f or t h e basic bu ildin g block s, bu t it also pr ov ides f or w ay s t o ex pr ess com plex r elat ion sh ips am on g t h e basic bu ildin g block s.

Relat ionships can be st at ic or dynam ic in nat ure. St at ic relat ionships prim arily revolve around t h e st r u ct u r al aspect s of a sy st em . I n h er it an ce r elat ion sh ip bet w een a pair of classes, in t er f aces im plem en t ed by a class, an d depen den cy on an ot h er class ar e all ex am ples of st at ic r elat ion sh ips.

Dy nam ic relat ionships, on t he ot her hand, are concerned w it h t he behavior of a syst em and h en ce ex ist at ex ecu t ion t im e. Th e m essages ex ch an ged w it h in a gr ou p of classes t o f u lf ill som e r esponsibilit y and flow of cont r ol w it hin a sy st em , for ex am ple, ar e each capt ured in t he con t ex t of t h e dy n am ic r elat ion sh ips t h at ex ist w it h in a sy st em .

Bot h st at ic and dynam ic aspect s of a syst em ar e capt ur ed in t he for m of UML diagr am s. Ther e ar e sev er al t y pes of UML diagr am s. Th ey ar e or gan ized alon g specif ic f ocal ar eas of v isual m odeling called v iew s.

Th e f ollow in g t y pes of diagr am s ar e pr ov ided by t h e UML:

•

Use case diagram : A u se case d iag r am sh ow s u se cases, act or s, an d t h eir r elat ion sh ips. Use case diagr am s capt u r e t h e pr ecise r equ ir em en t s f or t h e sy st em fr om a user 's p er spect iv e. See Ch a p t e r

7

for a det ailed discu ssion of u se cases in t h e

con t ex t of en t er pr ise Jav a applicat ion dev elopm en t .

•

Class diagram : A class diagr am sh ow s t h e st at ic r elation sh ips t h at ex ist am on g a group of classes and int erfaces in t he syst em . Som e com m on relat ionship t ypes are

in h er it an ce, aggr egat ion , an d depen den cy . See Ch a p t e r

8

for m or e details on classes,

in t er f aces, an d class diagr am s.

•

Obj ect diagram : An obj ect diagr am pr ovides a snapshot view of t he r elat ionships t hat ex ist bet w een class inst ances at a giv en point in t im e. An obj ect diagr am is useful for capt ur ing and illust r at ing, in a st at ic fashion, com plex and dy nam ic r elat ionships w it h in t h e sy st em . See

Ch a p t e r s 1 2

an d

13

f or addit ion al cov er age of h ow obj ect

diagr am s ar e used in t he cont ex t of ent er pr ise applicat ion design and dev elopm ent .

•

St at echart diagram : St at e m achines are excellent for capt uring t he dynam ic behavior of t he sy st em . They ar e par t icular ly applicable t o ev ent dr iv en, r eact iv e sy st em s or obj ect s w her e ev ent or der is im por t ant . St at e char t s ar e also useful for m odeling t he beh av ior of in t er faces. For m or e in for m at ion on u sin g st at ech ar t s in t h e con t ex t of J2 EE, see

•

Ch a p t e r 1 2 .

Act ivit y diagram : An act ivit y diagr am is an ext ension of a st at echar t diagr am and is sim ilar in concept t o a flow char t . An act iv it y diagr am allow s y ou t o m odel t he sy st em ' s behav ior in t er m s of int er act ion or flow of cont r ol am ong dist inct act iv it ies or obj ect s. Act iv it y diagr am s ar e best u sed for m odelin g w or k flow s an d flow w it h in op er at ion s. See

•

Ch a p t e r 7

for fu r t h er discu ssion of act iv it y diagr am s.

I nt eract ion diagram : I n t er act ion diagr am s ar e u sed for m odelin g t h e dy n am ic beh av ior of a sy st em . Th er e ar e t w o k in ds of in t er act ion diagr am s in t h e UML:

o

Sequence diagram : Used f or m od elin g t h e m essag e ex ch an g e b et w een obj ect s in a sy st em . Sequ en ce diagr am s also capt u r e t h e r elat iv e t im e or d er in g of m essag es ex ch an g ed .

o

Collabor at ion diagr am : The m essage exchange is capt ured in t he cont ext of t h e ov er all st r u ct u r al r elat ion sh ips am on g obj ect s.

The t w o diagr am s ar e equivalent , and it is possible t o conv er t fr om one t o t he ot her easily . I nt er act ion diagr am s ar e com m only used t o m odel t he flow of cont r ol in a use case and t o describe how obj ect s int eract during t he execut ion of an operat ion, such as t h e r ealizat ion of an in t er f ace oper at ion . I n t eract ion diagr am s ar e discu ssed in Ch a p t e r 8 .

•

Com ponent diagr am : A com ponent r epr esent s t he phy sical m anifest at ion of a par t of t he syst em , such as a file, an execut able, and so o n. A com ponent diagram illust rat es t h e depen den cies an d r elat ion sh ips am on g com pon en t s t h at m ak e u p a sy st em . A

com pon en t t y pically m aps t o on e or m or e classes, su bsy st em s, an d so on . Com pon en t s an d com pon en t diagr am s ar e discu ssed in

•

Ch a p t e r 1 5 .

Deploym ent diagram : A deploy m en t diagr am sh ow s t h e ar ch it ect u r e of a sy st em f r om t h e per spect iv e of n odes, pr ocessor s, an d r elat ion sh ips am on g t h em . On e or m or e com ponent s t y pically m ap t o a deploy m en t n ode. I n t h e con t ex t of J2 EE, deploy m ent diagr am s ar e useful for m odeling and dev eloping t he dist r ibut ed sy st em ar ch it ect u r e. Deploy m en t diagr am s ar e discu ssed in

Ch a p t e r 1 5 .

Th e UML is a com pr eh en siv e su bj ect w or t h y of a book it self ( an d in fact , sev er al good on es have alr eady been w r it t en! ) . Only t he m ost r elevant aspect s ar e cover ed in t his book. Refer t o t he Refer ences sect ion at t he end of t his book for a lis t of som e excellent books on t he UML t hat pr ov ide a m or e in -dept h discu ssion of specif ic ar eas of t h e UML.

Why Use the J2EE and the UML Together? An y r eason ably pr of icien t pr ogr am m er can dev elop a piece of sof t w ar e t h at w ill do t h e j ob—for a w h ile. Bu t bu ildin g an en t er pr ise sy st em t h at is m ain t ain able, scalable, an d evolvable is a differ ent m at t er alt oget her . And t hese days, w hen a syst em m ust evolve at a breakneck pace or face obsolescence, it is all t he m ore im port ant t o t ake t he long t erm view b ecau se y ou will n eed t o m ain t ain , scale, an d ev olv e t h e sy st em y ou ar e bu ildin g!

I t is possible t o sur v iv e and t hr iv e for a w hile by coding, com piling, fix ing, and deploy ing y our applicat ion. Sooner r at her t han lat er , y ou w ill m ost lik ely find t hat y our sy st em is not able t o scale t o t he new gr ow t h dem ands. This is because y our sy st em pr obably w as not ar chit ect ed an d design ed so t h at it cou ld ev olv e easily in t h e f ace of n ew r equ ir em en t s.

The UML pr ov ides t he t ools necessar y for ar chit ect ing and building com plex syst em s, such as t h ose r equ ir ed f or an en t er pr ise. I t su ppor t s, am on g ot h er disciplin es, r equ ir em en t s engineering, archit ect ure -level design, and det ailed design. I n addit ion, UML m odeling t ools ar e ev olv in g t o w h er e t h ey can b e u sed t o im p ose con sist en t d esig n p at t er n s u p on a J2EE-based sy st em m odel an d t o gen er at e a sign ifican t por t ion of t h e sy st em ' s ex ecu t able sou r ce cod e.

UML's support for requirem ent s engineering is m ainly m anifest ed in it s support for use cases, w h ich ar e u sed t o u n d er st an d an d com m u n icat e funct ional r equir em ent s. Using UML for r equ ir em en t s m odelin g, in con j u n ct ion w it h a u se case dr iv en dev elopm en t pr ocess,

facilit at es t r aceabilit y fr om r equir em ent s t o design. Tr aceabilit y , in t his cont ex t , im plies t he abilit y t o det erm ine t he elem ent s in a design t hat exist as a r esult of a specific r equir em ent . I n a u se case dr iv en dev elopm en t pr ocess, specif ic design elem en t s ar e cr eat ed f or t h e pur pose of sat isfy ing a use case. Thus, t r aceabilit y is oft en achiev ed im plicit ly .

Such t r aceabilit y has v ar ious benefit s. For ex am ple, t he abilit y t o ident ify t he im pact of changes in requirem ent s on t he design can not only sim plify t he t ask of m odifying a syst em t o m eet n ew r equ ir em en t s, bu t also h elp f ocu s t est in g of t h e sy st em af t er t h e ch an ges ar e com plete. Sim ilar ly , t he abilit y t o det er m ine t he r equir em ent s t hat led t o t he ex ist ence of specif ic design elem en t s can assist in elim in at in g u n n ecessar y design elem en t s.

Let ' s w alk t h r ou gh a sim ple scen ar io t o illu st r at e t h is. I m agin e t h at y ou r pr oj ect h as a re quirem ent R1. I n t he use case m odel, you cr eat e a use case nam ed deliver in response t o R1. I n t he analysis m odel, t wo classes com put e and rout e are creat ed t o fulfill t he use case. Th e u se case is r ealized b y a deliver use case realizat ion an d classes com put e.j ava an d rout e.j a va ar e cr eat ed t o fulfill t he deliver use case realizat ion. I f t h er e is a ch an ge t o R1, can y ou easily det er m in e w h ich classes w ill lik ely n eed t o be t est ed? Con v er sely , can y ou j u st ify t h e ex ist en ce of com put e.j ava in t h e im plem en t ation m odel?

As t h e f u n ct ion al r equ ir em en t s ch an ge or n ew on es ar e added, t h e sy st em m odel can be ex am ined t o det er m ine w hich por t ions of t he sy st em 's ar chit ect ur e and det ailed design ar e im pact ed by t h e ch an ges.

UML in clu des m odelin g con st r u ct s t h at can h elp d ev elop er s u n d er st an d h ow lar g e-scale por t ion s of t h e sy st em in t er act at r u n t im e an d depen d u pon each ot h er at com pile t im e. Addit ion ally , UML m odelin g t ools can in clu de ch eck s t o en su r e t h at design det ails do n ot violat e archit ect ure -level const raint s. Such t ools t her eby can help ensur e t hat t he qualit y of t h e sy st em ' s ar ch it ect u r e is m ain t ain ed t h r ou gh m u lt iple r eleases.

UML diagr am s, such as int er act ion diagr am s, act iv it y diagr am s, and class diagr am s, can be used t o under st and and docum ent com plex int e r act ions w it hin t he sy st em . These help in t he an aly sis of t h e pr oblem an d also pr ov ide a det ailed r ecor d of t h e as-designed behavior and st ruct ure of t he syst em . So w hen it is t im e t o incorporat e new funct ionalit y in t he syst em , you k n ow w h at t h e d esig n in t en t w as an d w h at t h e in h er en t sy st em lim it at ion s ar e.

I n addit ion t o su ppor t in g t h e abilit y t o cr eat e gen er ic UML m odels, UML m odelin g t ools ar e evolving r apidly t o a point w her e t hey w ill help im pose consist ent , accept ed pat t er ns of obj ect int eract ion in t o a syst em design. For exam ple, consider t he challenge of det er m ining w hen t o m ak e use of session beans v er sus ent it y beans, w hen t o use st at eful v er sus st at eless session beans, and w hen t o use Jav aSer v er Pages ( JSP) v er sus ser v let s. I n t he fut ur e, t hese t ypes of design decision s m ay be codif ied w it h in a t ool an d applied u pon dem an d.

Fin ally , u sin g UML en ables dev eloper s t o m ov e t o a t r u e v isu al dev elopm en t par adigm . I n addit ion t o en ablin g dev eloper s t o im pose con sist en t m odelin g pat t er n s in t o t h eir desig ns, m odern UML m odeling t ools generat e an increasing am ount of highly funct ional J2EE source code. As a r esu lt , dev eloper s can con cen t r at e on h igh er v alu e design act iv it ies an d leav e m u ch of t h e labor-in t en siv e codin g t o t h e m odelin g t ools. A v isu al r epr esen t at ion is also ex cellen t for com m u n icat in g t h e design am on g t h e t eam . I n addit ion , it can be u sed effect iv ely t o r am p -u p n ew t eam m em ber s r apidly .

Challenges in Modeling J2EE in the UML One of t he aut hor s r e calls t r ying t o r eplace a leaky r ear differ ent ial seal on his car . The r epair m anual called for a specialized t ool t o r em ov e t he seal, but he t ook one look at it and decided t he j ob could be done w it h his w r ench set and plier s. He ev ent ually m anaged t o r ep lace t he seal, bu t it t ook h im w eek s, an d som eh ow t h e oil n ev er st opped leak in g!

The challenge in using unadult er at ed UML for J2 EE m odeling is som ew hat sim ilar . You m ay get t h e j ob don e, bu t y ou r efficien cy an d lik elih ood of su ccess w ill be dim in ish ed.

More specifically , t he specificat ions t hat m ak e up t he J2 EE offer som e dist inct m odeling ch allen ges, f or in st an ce:

•

An Ent er pr ise Jav aBean ( EJB) class im plem ent s t he business m et hods in t he Rem ot e int er face, but not t he int er face it self. This is cont r ar y t o t he st andar d UML concept of in t er face r ealizat ion .

•

An EJB, by definit ion, is r elat ed t o a Hom e and Rem ot e int er face. I t is necessar y t hat a UML m odeler con sist en t ly h on or t h is ar ch it ect u r al pat t er n .

•

Ser v let s an d EJBs h av e deploy m en t descr ipt or s associat ed w it h t hem .

•

Un lik e m ost ot h er Jav a classes, EJBs, ser v let s, an d JSPs ar e pack aged in a specific t y pe of ar ch iv e file alon g w it h t h eir deploy m en t descr ipt or s.

•

En t it y b ean at t r ib u t es m ap t o elem en t s in a d at ab ase.

•

EJBs h av e t h e n ot ion of t r an sact ion s an d secu r it y.

•

Session EJBs can pot ent ially hav e significant dy nam ic behav ior .

•

Dif f er en t per sist en ce sch em es can be em ploy ed by en t it y bean s.

•

JSPs ar e logically a hybr id in t hat t hey have bot h client and ser ver aspect s t o t hem .

Given t he drive t o deliver bet t er soft w are in less t im e, anot her obj ect ive in m odeling J2EE is t o be pr ecise en ou gh t o per m it UML-based m odeling t ools t o be able t o pr ocess y our m odel an d pr ov ide v alu e-added capabilit ies r elat ed t o J2 EE.

Extension Mechanisms in the UML We ar e quit e sur e t he cr e at or s of UML did not hav e J2EE on t heir m inds w hen t hey cr eat ed t he UML. Fort unat ely for us, t hey had enough foresight t o recognize t hat in order for t he UML t o last an y len gt h of t im e, it w ou ld h av e t o be capable of ev olu t ion an d adapt ion t o n ew lan g u ag es an d con st r u ct s.

The UML pr ov ides t hr ee m echanism s for ex t ending t he UML: st er eot y pe, t agged v alue, and con st r ain t .

Stereotype

A st ereot ype allows you t o creat e a new, increm ent ally different m odel elem ent by changing t he sem ant ics of an ex ist ing UML m odel elem ent . I n essence, t his leads t o t he addit ion of new v ocabu lar y t o t h e UML.

I n t h e UML, a st er eot y ped m odel elem en t is r epr esen t ed by t h e base m odel elem en t ident ified w it h a st r ing enclosed w it hin a pair of guillem et s ( « » ) . A pair of angle brackets ( < < or > > ) can also r epr esent a guillem et .

The use of st er eot y pes is fair ly com m on in ev er y day UML usage, and it is quit e accept able t o cr eat e st er eot y pes t o m odel con cept s/ con st r u ct s if t h e st er eot y pe adds clar it y . As an exam ple, t he UML it self describes t he ex t end and include relat ionships via t he < < ext end> > and < < include> > st er eot y pes.

A st ereot ype can be defined for use w it h any m odel elem ent . For inst ance, st ereot ypes can be used w it h associat ions, classes, oper at ions, and so on. An exam ple of a st er eot ype is shown

in

Figure 3 - 1 .

Not e t h at

A st er eot ype m ay opt ionally be show n via an icon. An exam ple is show n in Figure 3 - 2 . Fi g u r e 3 - 1

an d

Fi g u r e 3 - 2

ar e equ iv alen t . We m ak e ex t en siv e u se of t h e icon ic

r epr esen t at ion in t h is book .

Figure 3 - 1 . A cla ss w it h st ereot ype

Figure 3 - 2 . Represent ing an int erface using an icon

Tagged Value

UML m odel elem ent s t y pically h av e pr oper t ies associat ed w it h t h em . For ex am ple, a class has a nam e. A t agged value can be used t o define and associat e a new pr oper t y for a m odel elem en t in or der t o associat e addit ion al in f or m at ion t o t h e m odel elem en t .

A t agged v alu e is d ef in ed as a t ag, value pair in t he follow ing for m at : { t ag= v alue} . For in st an ce, t h e UML con st r u ct class h as a n am e, bu t n or m ally t h er e is n o w ay t o iden t if y t h e au t h or of t h e class. A t ag g ed v alu e of { au t h or = Kh aw ar } cou ld b e u sed t o associat e t h e au t h or' s n am e t o t h e class m odel elem en t .

An ex am ple of a t agged v alu e is sh ow n in

Fi g u r e 3 - 3 .

Figure 3 - 3 . Ta gged va lue ex a m ple

Constraint

As it s n am e im plies, a con st r ain t in t h e UML allow s y ou t o specify r est r ict ion s an d relat ionships t hat cannot be expressed ot herw ise. Const raint s are great for specifying rules of h ow t h e m od el can or can n ot b e con st r u ct ed .

A con st r ain t is ex pr essed as a st r in g placed bet w een cu r ly br aces su ch as { con st r ain t } .

For ex am ple, if t h e or der of t h e associat ion s w it h in a g r ou p of in t er con n ect ed classes w as im por t ant , y ou could use a const r aint on each associat ion t o clear ly ident ify it s or der in t he r elat ion sh ip. An ex am ple of a con st r ain t is sh ow n in

Fig u r e 3 - 4 .

Figure 3 - 4 . An exam ple of a const raint

I t 's one t hing t o have t he facilit ies t o do som et hing, and quit e anot her t o act ually do it . The w hole point of having t he UML is t o pr ovide a com m on vocabular y, so ext ending t he language at an y on e' s w h im is cou n t er t o t h e p u r p ose as w ell as t h e spir it of t h e UML.

Gener ally, w hen a need ar ises t o adapt t he UML for a specific pur pose, t he suggest ed pr ocess is t o cr eat e a new UML pr ofile, and at an appr opr iat e point , subm it it t o t he OMG, w hich is t he body responsible for t he UML and for st anda rdizat ion. This allows ot her int erest ed part ies t o cont r ibut e t o t he pr ofile and ensur e it s adequacy for t he specialized needs fr om all point s of v i ew .

A UML pr of ile does n ot act u ally ex t en d t h e UML. I n st ead, it u ses t h e UML ex t en sion m echanism s t o est ablish a unifor m w ay of using t he ex ist ing UML const r uct s in t he cont ex t of a n ew dom ain . Th u s, a UML pr ofile is essen t ially a collect ion of st er eot y pes, con st r ain t s, t agged v alues, and icons along w it h t he conv ent ions for using t hem w it hin t he new dom ain.

Some ex am ples of UML pr of iles t h at alr eady ex ist or ar e in t h e w or k s in clu de

•

UML pr of ile f or Sof t w ar e Dev elopm en t Pr ocesses

•

UML pr ofile for Business Modeling

•

Dat a Modelin g

•

Real-Tim e Soft w ar e Modeling

•

XML DTD Modeling

•

XML Schem a Modeling

•

UML EJB Modeling

•

Web Modelin g

The fir st t w o pr ofiles in t he list ar e docum ent ed in t he OMG UML specificat ion docum ent . The r em aining pr ofiles ar e eit her published or subm it t ed, or ar e being used in t he indust r y, or ar e u n der con sider at ion f or dev elopm en t .

The Approach to J2EE UML Modeling Th e appr oach w e' v e t ak en in t h is book is t o r eu se ex ist in g an d pr ov en appr oach es f or m odelin g specific con cept s in t h e UML an d r edu ce t h e ex t en sion s t o t h e absolu t e m in im u m n ecessar y .

Sign if ican t w or k h as alr eady been don e in t h e f or m of a pr oposed UML pr ofile for EJBs, developed via t he Java Com m unit y Process ( JSR 26) . The UML not at ion for J2EE reuses t hat w or k t o a lar g e d eg r ee. Ef f or t h as also b een p u t f or t h on t h e Web Mod elin g p r of ile. [ 2 ]

[ 2]

As docu m en t ed in Building Web Applicat ions wit h UML by Jim Conallen, Addison-Wesley ,

1999.

So, rat her t han focus on t he m echanics and int ricacies of J2EE UML m apping, we at t em pt t o highlight how specific facilit ies w it hin t he UML can be effect iv ely u sed t o m odel J2 EE applicat ion s an d der iv e t h e m ost ben ef it s in t h e pr ocess.

Con sequ en t ly , ou r m odelin g f ocu s is on act iv it ies su ch as:

•

Under st anding and ident ify ing t he ov er all r ole a specific J2EE t echnology m ay play in an en t er pr ise applicat ion

•

I d en t if y in g st r at egies f or dealin g w it h in t er t ech n ology r elat ion sh ips

•

Un der st an din g dy n am ic beh av ior of com pon en t s

•

Dev elopin g a su it able ar ch it ect u r e f or t h e en t er pr ise applicat ion

•

I den t if y in g an d m ain t ain in g t h e depen den cies

Summary The UML pr ov ides a r ich set of const r uct s for m odeling com plex sy st em s and is ideally suit ed for m odelin g en t er pr ise Jav a applicat ion s.

UML m odelin g is m or e t h an t h e v isu al pr esen t at ion of a specific J2 EE t ech n ology . Th e t r u e v alu e of UML becom es appar en t as it is applied t o solv in g challenges t hat ar e har d t o solv e w it h ou t t h e aid of m odelin g. Su ch ch allen ges in clu de, am on g ot h er s, beh av ior al m odelin g, iden t ificat ion of depen den cies, sign ifican t r elat ion sh ips, an d dev elopm en t of a r esilien t ar ch it ect u r e for t h e en t er pr ise applicat ion .

Chapter 4. UML and Java •

Rep r esen t i n g St r u ct u r e

•

Re p r e se n t i n g Re l a t i o n sh i p s

•

Su m m ar y

UML and Java m ay be languages for soft w are developm ent , but t hey exist in different planes of realit y. UML occupies t he visual world, whereas Java is t ext ual in nat ure.

UML is also richer t han Java in t he sense t hat it offers m ore abst ract and powerful ways of expressing a part icular concept or relat ionship. However, t here is generally only one way t o represent t hat concept or relat ionship in t he Java language.

For exam ple, a Java variable declarat ion can be expressed in m ult iple ways in UML.

This chapt er provides an overview of som e key UML concept s relat ed t o classes and how t hey relat e t o t he im plem ent at ion world. The prim ary purpose is t o review t he basic m apping for t he benefit of t hose who m ay be new t o t he UML world. A secondary purpose is t o ident ify ways in which t he use of UML not at ion can effect ively enhance t he significance of a specific piece of Java code wit hout act ually alt ering t he equivalent Java code.

Representing Structure St ruct ural concept s, such as class and int erface, are fundam ent al t o bot h Java and t he UML. Th is sect ion iden t if ies h ow t h ese con cept s m ap t o Jav a an d t h e UML.

Class

I n t he UML, a Java class is represent ed via a com part m ent alized rect angle. Three horizont al com par t m en t s ar e u sed:

•

Nam e com part m ent : Sh ow s t h e Jav a class n am e

•

At t ribut e com part m en t : List s v ar iables def in ed on t h e class, if an y

•

Operat ions com part m ent : Sh ow s m et h od s d ef in ed on t h e class, if an y

Fi g u r e 4 - 1

sh ow s a sim p le Jav a class w it h ou t an y v ar iab les an d m et h od s.

Figure 4 - 1 . A class in Java and t he UM L

An abst r act class is iden t ified by it alicizing t he class nam e.

A st er eot y pe m ay be used alongside a class nam e t o unam biguously ident ify it as a specific t y pe of Jav a class, such as an applet ( w e discussed t he concept of st er eot y pes in Chapter 2 ) . You can also use st ereot ypes t o ident ify specific t ypes of classes ( such as < < Business Ent it y> > ) in y ou r par t icu lar dom ain v ocabu lar y t o m ak e t h e classes m or e m ean in gfu l w h er ev er t h ey ap p ear .

A w or d of caut ion: if y ou ar e using a UML t ool for Java code gener at ion, not e t hat t he t ool m ay u se t h e st er eot y pin g m ech an ism t o af f ect code gen er at ion .

Fi g u r e 4 - 2

sh ow s a st er eot y p ed class.

Figure 4 - 2 . A st ereot yped cla ss

Variable

Jav a v ar iables m ay m an ifest t h em selv es in v ar iou s w ay s in t h e UML. Th is is on e in st an ce w h er e m od elin g ad d s a d im en sion n ot ap p ar en t in t h e sou r ce cod e.

The sim plest form of variable declarat ion is t o list it w it hin a class's at t ri but e com part m ent . Un der lin in g t h e at t r ibu t e in dicat es t h e st at ic n at u r e of t h e v ar iable. The v isibilit y of an at t r ibu t e is in dicat ed by pr ecedin g t h e at t r ibu t e w it h + for pu blic, # for pr ot ect ed, an d - for pr iv at e.

Fi g u r e 4 - 3

sh ow s a class w it h at t r ib u t es.

Figure 4 - 3 . A cla ss w it h at t ribut es

This for m of declar at ion m ay com e about for basic dat a t h at is n eeded f or t h e class. Su ch variables do not generally have any specific significance from a broader m odeling perspect ive. Ex am ples include v ar iables y ou r equir e for st or ing basic pieces of infor m at ion t hat m ak e an obj ect w hat it is, v ar iables r equir ed for int er nal logic, and so on. Such v ar iables ar e based on obj ect s t h at u su ally can n ot be decom posed f u r t h er .

Var iables m ay also m anifest t hem selv es due t o an obj ect ' s r elat ionships w it h ot her obj ect s ( for ex am ple, a collect ion of som e sor t ) . We discuss such r elat ionships and t heir usage in t he " Re p r e se n t i n g

Re l a t i o n sh i p s "

sect ion lat er in t h is ch apt er .

Method

Met hods ar e t he equiv alent of oper at ions on a class in t he UML. They ar e show n in t he t hir d com par t m en t for a class. Visibilit y scope of UML oper at ion s is defin ed u sin g t h e sam e con v en t ion u sed f or class at t r ibu t es, as descr ibed in t h e " Var iables" sect ion .

Un der lin in g t h e oper at ion ' s n am e is u sed t o differ en t iat e a st at ic m et h od. List in g t h e operat ion in it alics in t he operat ion com part m ent show s t hat t he m et hod is abst ract . You can, of cou r se, h ide or sh ow det ails depen din g on t h e sign if ican ce of t h e det ail. For in st an ce, in Fi g u r e 4 - 4 ,

t h e f u ll oper at ion sign at u r es ar e n ot sh ow n by ch oice.

Figure 4 - 4 . A class w it h at t ribut es and operat ions

Object

Alt h ou gh bot h Jav a an d UML h av e t h e con cept of an obj ect , t h er e is n o dir ect m appin g betw een a UML obj ect and Java code. This is so because obj ect s are dynam ic ent it ies, w hich ar e based on class def in it ion s. Jav a applicat ion s ar e w r it t en in t er m s of Jav a classes t h at r esu lt in t h e cr eat ion of Jav a obj ect s w h en t h e applicat ion is act u ally ex ecu t ed .

I n t h e UML, obj ect s ar e u sed t o m odel dy n am ic aspect s of t h e sy st em v ia in t er act ion diagr am s. A r ect angle w it h an obj ect nam e, and/ or a class nam e, is used as t he not at ion for an obj ect . Som et im es it is desir able t o sh ow t h e at t r ibu t e v alu es f or t h e o bj ect in a giv en sit uat ion. This can be done using a r ect angle w it h t w o par t it ions show ing t he at t r ibut es of t he class. See

Fi g u r e 4 - 5 .

Figure 4 - 5 . An obj ect

Interface

I n t he UML, a Jav a int er face is depict ed as a class st er eot y ped w it h < < int er face> > . St er eot y ped classes m ay opt ion ally h av e icon s associat ed w it h t h em . I n t h e case of an int er face, t he UML iconic r epr esent at ion is a sm all cir cle. This iconic r epr esent at ion is com m on ly u sed for r epr esen t in g Jav a in t er faces w h en m odelin g in t h e UML.

Fi g u r e 4 - 6

sh ow s t h e st an d ar d in t er f ace r ep r esen t at ion .

Figure 4 - 6 . An int erface

Fi g u r e 4 - 7

sh ow s an alt er n at e an d m or e com pact f or m of r epr esen t at ion .

Figure 4 - 7 . Alt ernat e represent at ion of an int erface in t he UML

Eit h er appr oach is accept able f r om a m odelin g per spect iv e an d r eally com es dow n t o y ou r individual preference. This book m akes ext ensive use of t he icon represent at ion for diagram s p r esen t e d .

Package

A Java package m aps t o a UML package. Packages m ay be logical, m eaning you m ay only use t h em as a gr ou pin g m ech an ism . Pack ages can also be ph y sical, m ean in g t h ey r esu lt in a phy sical dir ect or y in t he file sy st em .

Th e UML pack age is r epr esen t ed a s a f old er , as sh ow n in

Fi g u r e 4 - 8 .

Pack ages m ay be

st er eot y ped t o dist in gu ish t h e t y pe of pack age, for ex am ple, u sin g < < su bsy st em > > t o iden t ify t h e pack age as a su bsy st em . ( A su bsy st em r efer s t o a gr oup of UML elem ent s and r epr esen t s a beh av ior al u n it in a m odel. I t can h av e in t er f aces as w ell as oper at ion s.

Su bsy st em s ar e t y pically sign ifican t fr om an an aly sis an d design per spect iv e. Th er e is n o d ir ect m ap p in g b et w een a su b sy st em an d a Jav a lan g u age const r uct . )

Figure 4 - 8 . A pa ck a ge

Representing Relationships Relat ionships play a k ey r ole in capt ur ing and m odeling t he im por t ant st r uct ur al aspect s of a Jav a applicat ion .

Som e of t hese r elat ionships, such as inher it ance, can be ex plicit ly ident ified in t he Jav a language via predefined keywords. Ot hers are not as easily ident ifiable in Java code but can n on et h eless b e r ep r esen t ed .

Inheritance

The UML concept of gener alizat ion is analogous t o inher it ance in Jav a. Gener alizat ion m aps dir ect ly t o t he ext ends k ey w or d an d is sh ow n v isu ally v ia a lin e w it h a t r ian gle at t h e en d n ear est t h e su p er class. See

Fi g u r e 4 - 9 .

Figure 4 - 9 . Represent ing t he inherit ance relat ionship

Realization

I n Java, a class m ay im plem ent one or m or e int er faces. The Java keyw or d im plem ent s m aps t o t h e con cept of r ealizat ion in UML.

I n t he UML, r ea lizat ion can be show n in t w o different w ays. I f t he st ereot yped class approach is used for represent ing an int erface, realizat ion is shown via a dashed line wit h a t riangle at t he end t ouching t he int er face. I f t he cir cle not at ion is used for an int er face, a plain, solid line con n ect in g t h e in t er f ace an d t h e im plem en t in g class is u sed.

These appr oaches ar e show n in Figure 4 - 10 and Figure 4 - 1 1 . Not e t hat t he appr oach show n in Figure 4-11

is sh or t h an d f or t h e ap p r oach sh ow n in Fi g u r e

4-10.

I t is inappropriat e t o m ix t he t wo. For

ex am ple, show ing an int er face v ia a cir cle and using t he dashed line w it h a t r iangle w ould be in appr opr iat e.

Figure 4 - 1 0 . UM L r e a liza t ion

Figure 4 - 1 1 . Alt ernat e represent at ion of int erface realizat ion

Dependency

An y t im e a class u ses an ot h er class in som e fash ion , a depen den cy ex ist s bet w een t h e t w o. Th e r elat ion sh ip is t h at of t h e u ser depen din g on t h e class t h at it is u sing. I n t he UML, a depen den cy is sh ow n v ia a dot t ed lin e w it h an ar r ow t ou ch in g t h e class t h at is cau sin g t h e depen den cy .

A depen den cy ex ist s if a class:

•

Has a local v ar iab le b ased on an ot h er class

•

Has a r ef er en ce t o an obj ect dir ect ly

•

Has a reference t o an obj ect indirect ly, for exam ple, via som e operat ion param et ers

•

Uses a class' s st at ic op er at ion

Dependency r elat ionships also ex ist bet w een pack ages cont aining classes t hat ar e r elat ed. Dep en d en cies b et w een p ack ag es ar e sh ow n v ia a d ot t ed lin e w it h an ar r owhead. See Figure 4-12

an d

Fi g u r e 4 - 1 3 .

Figure 4 - 1 2 . D e pe nde ncy be t w e e n cla sse s

Figure 4 - 1 3 . Dependency bet w een pa ck a ges

Association

Con cept u ally , an associat ion bet w een t w o classes sign if ies t h at som e sor t of st r u ct u r al r elat ion sh ip ex ist s bet w een t h e cla sse s.

I n t he UML, an associat ion is show n by dr aw ing a line bet w een t he classes t hat par t icipat e in t he relat ionship. Associat ions m ay be unidirect ional or bidirect ional. Bidirect ional associat ion is sh ow n w it h a sim ple lin e. Un idir ect ion al associat ion is sh ow n w it h an ar r ow on on e en d .

A u n idir ect ion al associat ion im plies t h at an obj ect of t h e class fr om w h ich t h e ar r ow is or igin at in g ( i. e. , t h e class t h at h as t h e n on ar r ow h ead side of t h e associat ion ) m ay in v ok e m et hods on t he class t ow ar ds w hich t he ar r ow is point ing. I n Jav a, t his m anifest s it self as an in st an ce v ar iable on t h e class t h at m ay in v ok e m et h ods.

Fi g u r e 4 - 1 4

sh ow s a u n idir ect ion al associat ion ex am ple.

Figure 4 - 1 4 . An exam ple of a unidirect ional associat ion

Most associat ions are of t he unidirect ional kind, but it is possible for som e associat ions t o be bidir ect ional. A bidir ect ional associat ion sim ply m eans t hat eit her obj ect in t he associat ion m ay invoke m et hods on t he ot her. I n Java, t his result s in an inst ance variable on each class b ased on t h e t y p e of t h e ot h er class.

A bidir ect ion al associat ion ex am ple is sh ow n in

Fi g u r e 4 - 1 5 .

Figure 4 - 1 5 . An exam ple of a bidirect ional associat ion

Wh at abou t sh ow in g associat ion s w it h pr im it iv e t y pes, su ch as int or boolean? Clear ly , it could be done t hat w ay if y ou ar e so inclined. I n fact , y ou m ay st ar t out show ing associat ions w it h a lar ge num ber of ent it ies in t he analy sis phase, but as y ou pr oceed t hr ough design and im plem ent at ion, and ident ify t he significance of each associat ion, t he num ber m ay be r educed significant ly . I n p r act ice, if it doesn ' t r eally add m u ch v alu e t o u n der st an din g t h e design, aside from adding som e visual clut t er t o t he m odel, t here really is no point in show ing t he r elat ionship v isually . I t is pr efer able t o use associat ions t o show only r elat ionships t hat ar e significant and nont r iv ial.

Each en d of t h e associat ion is a role in UML t er m inology and m ay be nam ed. For ex am ple, consider t hat a per son m ay have a bidir ect ional associat ion w it h a com pany t hat is em ploying t he person. I n t his case, t he roles m ay b e nam ed em ployer and em ployee, respect ively. From an im plem en t at ion per spect iv e in Jav a, t h e r oles m ay be appr opr iat e as t h e n am es of t h e

inst ance var iables in t he r espect ive classes. I t is usually helpful t o nam e a r ole if it adds value t o under st anding the m odel. I f not , it is perfect ly reasonable t o leave it unnam ed. I n such a case, t h e r ole n am e can sim ply be based on t h e n am e of t h e class.

An ex am ple of r oles on a bidir ect ion al associat ion is sh ow n in

Fi g u r e 4 - 1 6 .

Figure 4 - 1 6 . An exam ple of roles on bidirect ional associat ion

Of cour se, obj ect s in a class m ay hav e m ult iple associat ions w it h obj ect s in anot her class. For inst ance, a corporat ion t ypically has m any em ployees and a person m ay work for m ore t han one corporat ion. This is m odeled by assigning a m ult iplicit y t o t he role( s) . Mult iplicit y m ay be depict ed as a specific v alue ( e.g., 0, 1, 7) or as a range ( e.g., 0..1, 1..5, 1..* ) . An ast erisk is used t o indicat e an unlim it ed r ange. For ex am ple, " * " m eans zer o or m or e or sim ply m any , and " 5 0 0 . . * " indicat es 5 0 0 or m or e, up t o an unlim it ed num ber .

I n t er m s of Jav a im plem ent at ion, m ult iplicit y m anifest s it self as a m ult iv alued inst ance v ar iable. For ex am ple, assum e t hat a cor por at ion em ploy s sev er al per sons, and a per son can w or k for a m axim um of t hr ee cor por at ions. For t he var iable m ult iplicit y w it hout a fixed upper lim it , t his m ay t r anslate t o a collection r ep r esen t in g t h e p er son s w h o w or k f or a sin g le cor por at ion. For t he per son w ho w or ks for t hr ee differ ent cor por at ions, t his w ould r esult in an ar r ay of t h r ee elem en t s.

A m ult iplicit y ex am ple is show n in

Fi g u r e 4 - 1 7 .

Figure 4 - 1 7 . An exam ple of m ult iplicit y

I nform at ion relevant t o t he associat ion roles cannot alw ays reside w it h t he classes involved in t h e associat ion . For in st an ce, it w ou ld b e in ap p r op r iat e t o st or e t h e session b et w een a shopper and t he v ir t ual shopping car t in eit her class. I n such a case, an associat ion class m ay be u sed t o m odel t h is sit u at ion . See

Fi g u r e 4 - 1 8 .

Figure 4 - 1 8 . An a ssocia t ion cla ss

Aggregation

Aggr egat ion is a st r on ger f or m of an associat ion . I t is u sed t o sh ow a logical con t ain m en t r elat ionship, t hat is, a w hole form ed of part s. Alt hough t he part s m ay exist independent ly of t he w hole, t heir ex ist ence is pr im ar ily t o for m t he w hole. For ex am ple, a com put er m ay be m odeled as an aggr egat e of a m ot her boar d, a CPU, an I / O cont r oller , and so on. Not e t hat t he I / O co nt roller m ay exist independent ly ( e.g., in a com put er st ore) ; however, it s exist ence in t h e con t ex t of t h e w h ole is m or e appr opr iat e.

Aggr egat ion is m odeled as an associat ion w it h a h ollow diam on d at t h e class f or m in g t h e w h ole. Becau se it is an associat io n , an ag g r eg at ion su p p or t s t h e con cep t of r oles an d m ult iplicit y . I n t er m s of im plem ent at ion in Jav a, an aggr egat ion m aps t o inst ance v ar iables on a class.

An ex am ple of an aggr egat ion is sh ow n in

Fig u r e 4 - 1 9 .

Figure 4 - 1 9 . An aggregat ion exam ple

The sem ant ics and const r aint s of aggr egat ion ar e not subst ant ially differ ent fr om t hose for basic associat ion . I n spit e of t h is, ev er y on e con sider s aggr egat ion n ecessar y .

Unlike associat ion inst ances, inst ances of an aggr egat ion cannot have cyclic links. That is, an obj ect m ay not dir ect ly or indir ect ly be par t of it self. For ex am ple, if an inst ance of A ag g r eg at es an in st an ce o f B, t h en t h at in st an ce of B can n ot it self aggr egat e t h at sam e inst ance of A.

I n general, unless you believe t hat using aggregat ion adds value or clarifies som et hing, you sh ou ld u se associat ion . ( Com posit ion , discu ssed n ex t , is an ot h er alt er n at iv e. )

Composition

Com posit ion is an ot h er f or m of associat ion an d is sim ilar t o aggr egat ion t o som e degr ee. How ev er , it is less am bigu ou s.

Com posit ion is appr opr iat e for m odeling sit uat ions t hat call for phy sical cont ainm ent . I t im plies a m uch st ronger whole -par t coupling bet ween t he part icipant s such t hat part s cannot

ex ist w it hout t he w hole. That is, par t s shar e t he life cy cle of t he w hole. They ar e cr eat ed w hen t h e w h ole com es t o lif e an d d est r oy ed w h en t h e w h ole ceases t o ex ist .

Wh en w or k in g w it h an im plem en t at ion l an gu age, su ch as C+ + , u se of aggr egat ion v er su s com posit ion does m ap t o different code. For exam ple, aggregat ion im plies pass by reference, w hereas com posit ion im plies pass by value. How ever, t his dist inct ion is not applicable t o Java. Hen ce, t h e code m appin g of aggr egat ion v er su s com posit ion is t h e sam e ev en t h ou gh y ou m ay st ill w an t t o m odel t h em differ en t ly t o com m u n icat e t h e in t en t of t h e design an d h igh ligh t elem en t s in an im plem en t at ion in depen den t f ash ion .

Com p osit ion is sh ow n in t h e sam e w ay as ag g regat ion ex cept t hat t he diam ond is filled in.

Reflexive Relationships

A class m ay hav e an associat ion w it h it self. For ex am ple, if a per son em ploy s anot her per son, t h e Per son class m ay h av e an associat ion w it h it self w it h t h e r ole n am es of em ploy er an d em p loy ee. Such a r elat ionship is called a r eflex iv e r elat ionship.

This not at ion can be consider ed a m odeling shor t hand. Only one class icon r at her t han t w o is u sed t o illu st r at e t h e r elat ion . I n

Fi g u r e 4 - 2 0 ,

it w ou ld be per f ect ly accept able t o sh ow t w o

sep ar at e Per son class icon s w it h t h e r elat ion d r aw n b et w een t h em . How ev er , t o d o so con su m es space on a diagr am .

Figure 4 - 2 0 . An ex a m ple of a reflex ive a ssocia t ion

Summary The use of t he appr opr iat e UML const r uct s can add significant v alue t o t he ov er all design. I t can act as an aid in not only docum ent ing t he design but also m ak ing it m or e under st andable.

I n t h is ch apt er , w e f ocu sed on t h e k ey con cept s r elat ed t o t h e class diagr am . Th e k ey con cep t s d iscu ssed w er e

•

Classes, at t r ibu t es, an d oper at ion s, an d t h eir r e lat ionship t o Jav a im plem ent at ion

•

Pack age as a m ean s of gr ou pin g t h in gs an d it s r elat ion t o Jav a

•

Dif f er en t k in d s of r elat ion sh ip s b et w een classes an d w h en t o u se w h ich :

o

Associat ion

o

Aggr egat ion

o

Com posit ion

•

I n h er it an ce r epr esen t at ion in t h e UML

•

The r ole of r ealizat ion in t h e UML an d h ow it r elat es t o ext ends in t h e Jav a im plem en t at ion lan gu age

Good m odeling is not a t r iv ial t ask . Lik e any ot her sk ill-based t ask , it r equ ir es sign ifican t effor t and pr act ice t o becom e pr oficient in UML and m odeling. I n t he nex t f ew ch apt er s, w e ex plor e applicat ion of t h ese con cept s in t h e con t ex t of J2 EE dev elopm en t .

Chapter 5. Overview of Activities •

W h a t I s a So f t w a r e D e v e l o p m e n t Pr o ces s ?

•

Ov e r v i e w o f Po p u l a r Ap p r o a ch e s t o So f t w a r e D e v e l o p m e n t

•

Ap p r o a c h Us e d i n Th i s B o o k

•

Ov e r v i e w o f Ma j o r Act i v i t i e s

•

Su m m ar y

I s soft w are developm ent an art or a science? The answer really depends on whom you t alk t o. But t here is one t hing about which everyone will agree: soft ware cont inues t o becom e bigger, m ore com plex and harder t o develop, and m ore difficult t o m anage.

I n t his chapt er, we briefly explore som e of t he m ore popular approaches t o soft ware developm ent and highlight t heir perceived st rengt hs and weaknesses.

This is followed by a high -level overview of t he approach we have chosen t o follow for t his book. The idea is t o provide you wit h a roadm ap for t he rest of t he book.

What Is a Software Development Process? A soft w ar e dev elopm ent pr ocess pr ov ides guidance on how t o dev elop soft w ar e successfully . Su ch gu idan ce m ay cov er t h e en t ir e spect r u m of act iv it ies associat ed w it h soft w ar e dev elopm en t . Th e pr ocess m igh t m an ifest it self in t h e for m of pr ov en appr oach es, best pr act ices, gu idelin es, t ech n iqu es, sequ en cin g, an d so on .

Wh et h er for m al or in for m al, t h e soft w ar e dev elopm en t pr ocess u lt im at ely em ploy ed h as a pr ofound im pact on t he success of a soft w ar e pr oj ect . An ad hoc appr oach m ight w or k w ell for a sm all pr oj ect , bu t it m igh t lead t o ch aos for a lar ge pr oj ect an d h en ce gr eat ly im pact t h e ov er all sch edu le. Sim ilar ly , a bu r eau cr at ic soft w ar e dev elopm en t pr ocess m ay lead t o fr ust r at ion an d b og d ow n ev en t h e b est t eam .

Overview of Popular Approaches to Software Development Ther e ar e num er ous pr ocesses for developing soft w ar e. Som e of t he m or e pr evalent / popular on es ar e d iscu ssed in t h e f ollow in g sect ion s.

The Just-Develop-It Approach

Th e j u st -d ev elop -it appr oach is char act er ized by a gener al lack of for m alit y and alm ost nonexist ent pr ocess or cer em ony sur r ounding soft w ar e developm ent act ivit ies. The soft w ar e developer has t he key role, w hich is perhaps different iat ed by experience and expert ise in t he ar ea. The sole focus of t he dev elopm ent t eam is t o com plet e t he soft w ar e pr oj ect in t he best w ay it can , u sin g w h at ev er m ean s ar e af f or ded by t h e t ech n ologies at it s disposal. Som e u p -fr ont design w or k m ight be under t ak en, but t hat is largely dependent on t he init iat ive and p r ef er en ces of t h e sof t w ar e d ev elop er w h o is r esp on sib le f or t h e p r oj ect .

I n such an appr oach, t he ov er all design of t he soft w ar e ex ist s as par t of t he soft w ar e. I n ot her w or d s, t h er e is a on e-t o-one bidir ect ional m a ppin g bet w een t h e ar ch it ect u r e, design , an d im plem ent at ion. The ov er all qualit y of t he soft w ar e is lar gely dependent on t he dev eloper s inv olv ed in t he pr oj ect . Docum ent at ion, in gener al, is r elat iv ely unim por t ant . I nst ead, t he proj ect relies on t he cont inued availabilit y of t he sam e or equally skilled developers, so t hey can con t in u e t o ev olv e or m ain t ain t h e sof t w ar e.

Over all, t his m eans t hat t he soft w ar e m ay r ange fr om an excellent piece of w or k t hat is highly flex ible and ev olv able t o v er y poor qualit y s of t w ar e t h at is in f lex ible an d u n able t o accom m odat e even t he sim plest changes in requirem ent s. I n a nut shell, t he overall success r at e is unpr edict able at best and r epeat abilit y fr om one pr oj ect t o t he nex t ( or ev en fr om one pr oj ect ph ase t o t h e n ex t ) is m ost ly depen den t on lu ck .

As it t u r n s ou t , a lar ge n u m ber of soft w ar e dev elopm en t effor t s t oday st ill r ely on t h is dev elopm ent appr oach! Per haps t his is a m anifest at ion of t he com pr essed I nt er net deliv er y t im e pressures or sim ply t he result of t he soft ware indust ry being in it s infancy. Eit her way, t h e ph en om en on is v er y r eal.

The Waterfall Process

Th e w at er fall appr oach h as been u sed ex t en siv ely in t h e past an d con t in u es t o be popu lar . The idea is t o segm ent t he developm ent int o sequent ial phases ( e.g., requirem ent s, analysis, design, im plem ent at ion, t est ) . This w or k s w ell for sm all pr oj ect s and for pr oj ect s w her e t he r equir em ent s ar e st able and r elat ively fixed, t he pr oblem dom ain is w ell under st ood, and t he solu t ion h as been pr ov en on sim ilar pr oj ect s in t h e p ast .

Fi g u r e 5 - 1

d ep ict s t h e w at er f all p r ocess.

Figure 5 - 1 . The w a t e r fa ll pr oce ss

The Iterative Process

Un f or t u n at ely , m ost sof t w ar e pr oj ect s n ow aday s do n ot m eet t h e cr it er ia f or u t ilizin g t h e w at er fall appr oach. Requir em ent s ar e const ant ly changing; pr oj ect s oft en br eak new gr ound by t ackling novel pr oblem s and t r ying out cut t ing -edge t echnology, and so on. The it erat ive dev elopm ent appr oach, w hich is based on Boehm ' s spir al m odel, is pr im ar ily aim ed at addressing t hese issues. The idea is t o reduce risk early in t he proj ect by going t hrough t he iden t ified sequ en ce of act iv it ies ( r equ ir em en t s, an aly sis, design, et c. ) m ult iple t im es and

r ev isit in g each of t h e k ey act iv it ies in a plan n ed m an n er . Each it er at ion en ds w it h an ex ecu t able r elease. Am on g ot h er adv an t ages, t h is appr oach per m it s ear ly iden t ificat ion of issues w it h r espect t o inconsist ent r equirem ent s, enables end user involvem ent and feedback, pr ov ides a h igh er con f iden ce lev el in t h e st at e of t h e pr oj ect , an d so on .

Fi g u r e 5 - 2

depict s t h e it er at iv e pr ocess gr aph ically .

Figure 5 - 2 . The it erat ive process ( used w it h perm ission from Phillippe Krucht en, aut hor of The Ra t iona l Unifie d Pr oce ss: An I nt r oduct ion . p. 7 , Reading, MA: Addison- W e sle y , 1 9 9 9 .)

We discu ss t h e it er at iv e appr oach in f u r t h er det ail in t h e con t ex t of t h e ot h er appr oach es ex plain ed in t his chapt er .

The Rational Unified Process

Th e Rat ion al Un ified Pr ocess ( RUP) is an ev olu t ion of t h e Obj ect ory p r ocess, w h ich w as acquir ed by Rat ional Soft w ar e a few y ear s ago and w as m er ged w it h t he Rat ional Approach. I t h as been en h an ced ov er t im e v ia t h e in cor p or at ion of ot h er asp ect s of sof t w ar e dev elopm en t as w ell as best pr act ices iden t if ied by t h e sof t w ar e in du st r y ov er t h e y ear s.

At t h e h ear t of t h e RUP lie t h e sof t w ar e best pr act ices:

•

Develop soft ware it erat ively: A m aj or issue w it h t r adit ional ( i.e., wat erfall) soft ware dev elopm ent effor t is t he discov er y of design defect s lat e in t he dev elopm ent cy cle an d t h e pr oh ibit iv e cost t o f ix t h em at t h at st age. I t er at iv e dev elopm en t f ollow s a m ore cont inuous and cyclic process, allow ing easier course co rrect ions along t he w ay. Thus, high r isk issues can be focused on and t he r isk elim inat ed ear ly on. Pr oblem s ar e iden t ified con t in u ou sly an d can be ov er com e in a m or e cost -effect iv e m anner r at her t han being discov er ed at t he v er y end of t he effor t w hen t he y can t hreat en t he en t ir e pr oj ect .

•

Manage requirem ent s: Requ ir em en t s ar e oft en ev olu t ion ar y in n at u r e. Th at is, a pr oj ect nev er st ar t s w it h all it s r equir em ent s alr eady capt ur ed and out lined. I nst ead, t he pr ocess is one of gr adual ident ificat ion, under st an ding, and r efinem ent . As such, r equ ir em en t s n eed t o be m an aged car ef u lly t o en su r e pr oj ect su ccess.

•

Use com ponent -based archit ect ures: Com p on en t -b ased sof t w ar e of f er s t h e advant age of t rue m odular developm ent . Such m odular developm ent leads t o bet t er ov er a ll ar chit ect ur e. Com ponent s, w het her in house or com m er cially obt ained, also pr om ot e r eu se bot h in " as is" an d cu st om ized f or m s.

•

Visually m odel soft w ar e: I n t he w or ds of Gr ady Booch, " A m odel is a sim plificat ion of realit y t hat com plet ely describes a syst e m from a part icular perspect ive." [ 1 ] Building m odels leads t o bet t er under st anding of t he pr oblem and im pr ov es com m unicat ion about it , t her eby m ak ing com plex sy st em s m or e m anageable. Visual m odeling is t he pr ef er r ed w ay t o do m odelin g becau se it allow s y ou t o w or k at a h igh er lev el of abst r act ion . [ 1]

Kr ucht en, P. The Rat ional Unified Process: An I nt roduct ion . Ch ap t er 1 " Sof t w ar e

Developm ent Best Pract ices" by Grady Booch, p. 11, Reading, MA: Addison -Wesley, 1999.

•

Cont inuously verify soft ware qualit y: St u dies h av e pr ov en t h at t h e ear lier y ou ident ify a pr oblem , t he cheaper it is t o fix . I n fact , st udies hav e pr ov en t hat fix ing problem s report ed aft er t he product is deployed are always several t im es cost lier t o fix. Cont inuous t est ing m eans early t est ing, which can be m uch m ore cost -effect ive. Such ongoing t est ing can also offer a m or e obj ect iv e assessm ent of t he t r ue st at us of t h e pr oj ect .

•

Cont rol changes t o soft ware: Today's large soft w are proj ect s a re t ypically dist ribut ed acr oss m u lt iple geogr aph ical sit es, in v olv in g sev er al t eam s w it h a lar ge n u m ber of

dev eloper s. The pr obabilit y of conflict ing changes, r esult ing in chaos, is v er y high. Thus, t here is a st rong need t o cont rol changes for effect ive pr ogr ess on t he pr oj ect .

The RUP has t w o basic dim ensions. One RUP dim ension groups act ivit ies logically according t o t h e disciplin es t h at ar e r espon sible f or ex ecu t in g t h em .

The RUP ident ifies six cor e disciplines:

•

Business m odeling: As t he nam e suggest s, t he pur pose of t his discipline is t o develop a m odel of t he business. The idea is t o bet t er underst and t he overall business so t he soft w ar e applicat ion can fit in t o it m or e appr opr iat ely . Bu sin ess m odelin g is m ost suit able in sit uat ions w her e a lar ge am ount of inform at ion is expect ed t o be m anaged by t he syst em , and a relat ively large group of people is expect ed t o use t he syst em . A business use case m odel an d a business obj ect m odel ar e t ypically pr oduced as par t of t h e bu sin ess m odelin g disciplin e.

•

Requir em ent s: The requirem ent s discipline aim s t o develop a solid underst anding of t h e r equ ir em en t s. Th e in t en t is t o ach iev e agr eem en t w it h cu st om er s as w ell as t o pr ov ide gu idan ce t o dev eloper s. A u se case m odel is pr odu ced as par t of t h e r equ ir em en t s disciplin e. A u ser in t er f ace pr ot ot y pe m ay also be pr odu ced.

•

Analysis and Design: Requ ir em en t s capt u r ed in t h e r equ ir em en t s disciplin e ar e an aly zed an d t r an sf or m ed in t o t h e design in t h e an aly sis an d design disciplin e. An ar ch it ect u r e is dev eloped t o gu ide t h e r e m aining dev elopm ent effor t . Analy sis and design m odels ar e dev eloped as par t of t h is disciplin e.

•

I m plem ent at ion: I n t h is disciplin e, t h e design is t r an sfor m ed in t o t h e act u al im plem en t at ion code. A st r at egy is dev eloped for lay er in g an d par t it ion in g t h e syst em in t o su bsy st em s. Th e en d r esu lt is a set of im plem en t ed, u n it t est ed com pon en t s t h at f or m t h e pr odu ct .

•

Test : As is obvious fr om it s nam e, t he t est discipline is all about ver ifying t he syst em . Am ong ot her t hings, t his t y pically m eans v er ify ing t hat all r equ ir em en t s h av e been m et , con fir m in g t h at com pon en t s w or k t oget h er as ex pect ed, an d iden t ify in g an y defect s r em aining in t he pr oduct . The pr im ar y out put s of t his discipline ar e a t est m odel an d a set of d ef ect s g en er at ed as a r esu lt of t h e t est in g .

•

Deploym ent : The deploym ent discipline m akes t he pr oduct available t o t he end user s. As such, it covers det ails such as packaging of t he soft w are, inst allat ion, user t raining, an d dist r ibu t ion of t h e pr odu ct .

Th er e ar e also t h r ee su ppor t in g disciplin es: configurat ion and change m anagem ent , proj ect m anagem ent , an d env ir onm ent .

The ot her RUP dim ension deals w it h giv ing st r uct ur e t o t he it er at ions in a soft w ar e pr oj ect . Th e RUP gr ou ps t h e it er at ion s in t o f ou r ph ases. Each ph ase en ds w it h a m ilest on e t h at is a m an agem en t -lev el decision poin t .

As Fi g u r e

5-3

show s, each phase ( and each it er at ion w it hin a phase) usually t ouches m ult iple

disciplines. Depending on t he specific it er at ion, a specific discipline m ay pr ov ide t h e em ph asis f or a ph ase, w h er eas t h e ot h er disciplin es play a m in or r ole in t h e it er at ion . For inst ance, an ear lier it er at ion is lik ely t o spend m or e t im e in t he r equir em ent s discipline, w hereas a lat er it erat ion is likely t o spend m ore t im e in t he t est discipline and a m uch sm aller por t ion of t im e in t he r equir em ent s discipline.

Figure 5 - 3 . The Rat ional Unified Process ( used w it h perm ission from Phillippe Krucht en, a ut hor of The Ra t iona l Unifie d Pr oce ss: An I nt r oduct ion . p. 2 3 [ m odifie d t o reflect RUP t erm inology changes circa 2 0 0 1 ] , Reading, M A: Addison- W e sle y, 1 9 9 9 .)

Th e f ou r ph ases def in ed by t h e RUP ar e

•

I ncept ion phase: Th e in cept ion ph ase r ev olv es ar ou n d t h e scopin g of t h e pr oj ect in t er m s of t he pr oduct , under st anding of t he over all r equir em ent s, cost s involved, and k ey r isk s. The em phasis dur ing t he incept ion phase is on cr eat ing a v ision docum ent , iden t ify in g an in it ial set of u se cases an d act or s, dev elopin g a bu sin ess case for t h e p r oj ect , an d d ev elop in g a p r oj ect p lan sh ow in g t h e p h ases an d p lan n ed it erat ions.

•

Elaborat ion phase: Th e elabor at ion ph ase is per h aps t h e m ost sign if ican t ph ase. I n t h is ph ase, t h e r equ ir em en t s ar e an aly zed in det ail, an d an ov er all ar ch it ect u r e is developed t o carry t he proj ect t hrough t o com plet ion. St abilit y in requirem e nt s and a st able ov er all ar chit ect ur e ar e basic ex pect at ions for t he end of t his phase. Em phasis is on dev elopin g a u se case m odel, an an aly sis m odel, a design m odel, an ar ch it ect u r e pr ot ot y pe, an d a dev elopm en t plan .

•

Const ruct ion phase: Th e focu s of t h e con st r u ct ion p h ase is on d esig n an d im plem ent at ion. This is achiev ed by ev olv ing t he init ial pr ot ot y pe int o t he act ual pr odu ct . Th e k ey deliv er able f or t h e en d of t h e con st r u ct ion ph ase is t h e pr odu ct it self.

•

Transit ion phase: I n t h e t r an sit ion ph ase, t h e p r odu ct is r eadied f or t h e u ser s. Th is m ay inv olv e fix ing defect s ident ified dur ing bet a t est ing, adding any m issing capabilit ies, t r ain in g en d u ser s, an d so on . Th e fin al pr odu ct is deliv er ed t o t h e cu st om er at t h e en d of t h e t r an sit ion p h ase.

The RUP can also be cu st om ized t o m eet specif ic n eeds of an or gan izat ion or pr oj ect .

Fi g u r e 5 - 3

com bin es t h e v ar iou s elem en t s of t h e RUP an d v isu ally sh ow s t h e r elat ion sh ips

b et w een p h ases an d d iscip lin es.

The ICONIX Process

The I CONI X pr ocess offer s an appr oach t hat is sim ilar t o t he RUP. This pr ocess em phasizes " r obu st n ess an aly sis" an d for m alizes t h at an aly sis in t o a r obu st n ess diagr am . Robu st n ess an aly sis r ev olv es ar ou n d an aly zin g u se cases an d est ab lish in g a first cut at t he obj ect s t hat par t icipat e in each use case. These obj ect s ar e classified int o cont r ol, boundar y , and ent it y obj ect s. Pract ically speaking, t he difference is a m at t er of sem ant ics. The RUP not ion of use case an aly sis is essen t ially t h e sam e as I CONI X r obu st n ess an aly sis. I n addit ion , t h e RUP addr esses all aspect s of t h e sof t w ar e dev elopm en t lif e cy cle, w h er eas t h e I CONI X pr ocess f ocu ses on an aly sis an d d esig n .

The OPEN Process

The Obj ect -or ient ed Pr ocess, Env ir onm ent , and Not at ion ( OPEN) p rocess was developed by t he OPEN consort ium . Like t he RUP, it evolved from a m erger of earlier effort s in t he area. I t is pr im ar ily int ended for use in an obj ect -or ien t ed or com pon en t -b ased sof t w ar e dev elopm en t en v ir on m en t .

OPEN is defined as a pr ocess fr a m ework known as t he OPEN Process Fram ework ( OPF) . OPF provides a set of com ponent s, w hich are divided int o five groups: Work Unit s, Work Product s, Pr od u cer s, St ag es, an d Lan g u ag es.

Pr odu cer s ar e t y pically people. Pr odu cer s w or k on Wor k Un it s an d pr odu ce Work Products. Languages, from t he Unified Modeling Language ( UML) t o St ruct ured Query Language ( SQL) , ar e u sed f or cr eat in g t h e Wor k Pr odu ct s. All t h is h appen s in t h e con t ex t of St ages, su ch as ph ases, m ilest on es, an d so on , w h ich pr ov ide t h e or gan izat ion f or t h e Wor k Un it s.

Extreme Programming/Feature-Driven Development

Ex t r em e Pr ogr am m ing ( XP) , or iginally pr oposed by Kent Beck , has gained m uch at t ent ion lat ely . XP is oft en posit ioned as a " light w eight soft w ar e dev elopm ent pr ocess" and in fact can be alm ost con st r u ed as an an t ip r ocess in t h e t r ad it ion al sen se.

Th e m ain idea beh in d XP is t o k eep t h in gs as sim ple as possible t o get t h e j ob don e. XP act iv it ies ar e or gan ized ar ou n d fou r m aj or u n der t ak in gs: plan n in g, design in g, codin g, an d t est in g .

Plan n in g is organized ar ound a " Planning Gam e. " Requir em ent s ar e collect ed in t he for m of user st or ies, w hich can be used for discussion w it h cust om er s and pr ov ide sufficient det ail for est im at es an d sch edu lin g t r ade-offs. Requ ir em en t s ar e capt u r ed on in dex car ds. Th is is follow ed by ident ifying a " m et aphor " for t he over all syst em , w hich pr ovides t he over all shar ed vocabular y for t he t eam . Requir em ent s ar e par t it ioned int o sm all t asks, each of w hich can be im plem ent ed in a v er y shor t am ount of t im e ( w eek s) .

Because r equirem ent s can change rapidly, XP does not spend any t im e on up -front analysis. I nst ead, t he design and coding begins im m ediat ely . I n XP, t he code is t he design; hence, t he design phase consist s of discussing feat ur es w it h t he cust om er , ident ify ing t he t est c ases for

successful im plem ent at ion, and t hen im plem ent ing t he sim plest solut ion t hat w ill m eet t he r equir em ent s. Dev eloper s alw ay s w or k in pair s and focus on im plem ent ing t he t ask s, doing any r efact or ing of ex ist ing code as r equir ed along t he w ay . I nt egr at ion w it h ot her par t s of t he sy st em m ay t ak e place sev er al t im es a day .

Pr im ar y t est ing is cent er ed on unit t est ing, and funct ional t est ing is dict at ed by t he cust om er t o det er m in e accept abilit y of t h e sof t w ar e pr odu ct .

Feat ure -Driven Developm ent ( FDD) , developed by Jeff de Luca and Pet er Coad, is based on XP. I t pr im ar ily differ s fr om XP in t hat FDD includes a r equir em ent t o develop a dom ain obj ect m odel as par t of an ear ly design as a w ay t o com pensat e for t he r elat iv e absence of an ov er all ar chit ect ur e/ design . FDD fu r t h er con st r ain s t h e defin it ion of XP t ask s t o u ser-con su m able f eat u r es an d elev at es f eat u r es t o a cen t r al n ot ion w it h in t h e ov er all dev elopm en t pr ocess.

Approach Used in This Book As you m ay have already deduced from t he dept h of t he process d escript ions given t hus far, t h e appr oach in t h is book is lar gely based on t h e RUP.

Th e d ecision t o d o so w as b ased on t h e f ollow in g :

•

Th e RUP is a pr ov en pr ocess an d is cu r r en t ly bein g u sed su ccessf u lly in a lar ge n u m ber of pr oj ect s.

•

We st rongly believe t ha t ar chit ect ur e, analysis, and design ar e essent ial t o a pr oj ect 's lon g-t er m success. Unlik e ot her pr ocesses, for ex am ple, FDD and XP, t he RUP pr ov ides ex cellen t cov er age of t h ese k ey aspect s.

•

Ther e ar e enough sim ilar it ies bet w een t he RUP and ot her pr ocesse s ( e.g., I CONI X) t o m ak e t h e w or k pr esen t ed in t h is book u sef u l t o ev en t h ose n ot u sin g t h e RUP in it s pur e for m .

•

Th e RUP can be cu st om ized t o su it specif ic n eeds.

Of cou r se, t h is decision w as n ot based, by an y m ean s, on an ex h au st iv e com par ison of t h e diff er en t appr oach es an d w as n o dou bt in f lu en ced by ou r ow n f am iliar it y w it h t h e RUP.

We should point out t hat in t his book , w e hav e chosen t o use a cust om ized v er sion of t he RUP t ailored for t he needs of t his specific book and case st udy. I n addit ion, w e do not at t em pt t o

cov er each and ev er y ar t ifact , deliv er able, or elem ent out lined in t he RUP. This is pr im ar ily du e t o space an d t im e lim it at ion s im posed by t h e book .

For in st an ce, w e con den se w h at w ou ld r ealist ically be don e ov er sev er al it er at ion s w it h m ult iple in cr em en t s, each in t o a seem in gly sin gle it er at ion . We also do n ot cov er all disciplines ident ified in t he RUP, lim it ing our selv es t o t hose m ost dir ect ly r elev ant t o illu st r at in g specific aspect s of an aly sis, design , an d dev elopm en t .

Figure 5 - 4

graphically illust rat es t he relat ionship bet w een t he different RUP w orkflow s, art ifact s

pr odu ced du r in g t h e w or k f low s, an d h ow t h e ch apt er s in t h is book r elat e t o t h em .

Figure 5 - 4 . The RUP w or k flow s, a r tifact s, and relat ed book chapt ers

Refer t o t he Refer ences sect ion at t he end o f t his book for addit ional sources of inform at ion ab ou t t h e RUP.

Overview of Major Activities We lim it ou r discu ssion in t h e book t o som e k ey act iv it ies. Each t opic span s on e or m or e ch ap t er s.

Chapter 6:

Architecture

Ch a p t e r 6

in t r odu ces t h e n ot ion of ar ch it ect u r e an d discu sses som e of t h e k ey con cept s of

ar chit ect ur e, such as decom posit ion, lay er ing, an d so on . Th ese con cept s ar e t h en applied an d elabor at ed u pon in t h e r em ain in g ch apt er s.

Chapter 7:

Chapter 7

Analyzing Customer Needs

focuses on under st anding w hat is r equir ed t o be im plem ent ed. We st ar t by capt ur ing

t he r equir em ent s in t he for m of a use case m odel. This inv olv es ident ificat ion of act or s and u se cases an d ar t icu lat ion of t h e r eq u ir ement s concisely in t he for m of sequence diagr am s and act iv it y diagr am s.

Chapter 8:

Creating the Design

Ch a p t e r 8

r ev olv es ar ou n d dev elopin g a h igh -lev el design . We st ar t by dev elopin g a bet t er

u n der st an din g of t h e specif ic u se cases. Each u se case is r ef in ed u sin g t h e con cept of boundar y , cont r ol, and ent it y classes, and t he sy st em r esponsibilit ies ar e dist ribut ed t o t hese classes. Seq u en ce d iag r am s ar e u sed t o cap t u r e t h e r ef in ed u se case scen ar ios, an d collabor at ion diagr am s ar e used t o bet t er under st and t he int er act ions. We also dev elop t he init ial class diagram represent ing t he st ruct ural relat ionships in t he m odel. As well, we st art t o iden t if y t h e depen den cies an d pack agin g r equ ir em en t s.

Chapters 10–15 :

Chapt ers 10 – 1 5

Detailed Design

focus on bringing t he Java 2 Plat form , Ent erprise Edit ion ( J2EE) t echnologies and

UML t oget her . We use t he design m odel developed in Chapt er 9 as t he st ar t ing point and ev olv e it as w e cov er specific t echnologies. For ex am ple, in Chapt er 10 , we part it ion t he cont rol classes f u r t h er an d ev olv e a su bset of t h ose classes in t o ser v let s. I n

Ch a p t e r 1 1 ,

w e in t r odu ce

Jav aSer v er Pages ( JSP) an d cov er som e of t h e pr esen t at ion r elat ed aspect s of t h e applicat ion .

I n t hese chapt ers, we m ake use of class diagram s, int eract ion diagram s, st at e chart diagram s, an d act iv it y diagr am s as w ell as compon en t an d deploy m en t diagr am s.

Chapter 16:

Case Study

Ch a p t e r 1 6

r ecaps t h e v ar iou s act iv it ies u n der t ak en as par t of t he fir st it er at ion in Chapters 6 –1 5 .

The idea is t o pr ov ide a consolidat ed v iew of t he case st udy used t hr oughout t he book . We fill in t he holes using det ailed UML diagr am s for scenar ios not cov er ed in t he r est of t he book . We fur t her t alk about t he second and subsequent it er at ions of t he case st udy and highlight som e of t he k ey co n sider at ion s in m ov in g f or w ar d w it h t h e pr oj ect .

Summary Th er e ar e v ar iou s aspect s of sof t w ar e dev elopm en t . Som e of t h e k ey elem en t s ar e ar ch it ect u r e, u n der st an din g r equ ir em en t s, an aly sis an d design , an d im plem en t at ion .

Over t im e, num erous approaches have been developed for soft w are developm ent . Alt hough t here are differences am ong t he specific soft w are developm ent processes, t here are also a lot of sim ilar it ies. I n t h is ch apt er , w e h igh ligh t ed som e of t h e cu r r en t popu lar pr ocesses.

To pr ov ide a fr am ew or k for t he discussions t o com e in t he rem aining chapt ers, we provided a h igh -lev el ov er v iew of t h e act iv it ies u n der t ak en in

Ch a p t e r s 6 – 1 6 .

Chapter 6. Architecture •

W h a t I s So f t w a r e Ar ch i t e ct u r e ?

•

W h y Ar ch i t e ct u r e ?

•

K e y Co n ce p t s i n En t e r p r i se Ap p l i ca t i o n Ar ch i t e ct u r e

•

Ap p r o a ch e s t o So f t w a r e Ar ch i t e ct u r e

•

Pu t t i n g I t Al l To g e t h e r

•

Su m m ar y

Soft ware archit ect ure is one of t hose t erm s t hat everyone claim s t o underst and but no one can define precisely—or at least , not precisely enough t o sat isfy everyone else.

This is part ly because of t he relat ively short exist ence of t he soft ware profession it self and part ly due t o t he newness of t he concept of archit ect ure in t he cont ext of soft ware.

I n t his chapt er, we t ake a closer look at soft ware archit ect ure and som e of t he key concept s involved in it .

What Is Software Ar chitecture? Most sof t w ar e ar ch it ect u r e def in it ion s in v olv e r ef er en ces t o on e or m or e of t h e f ollow in g:

•

St at ic st r uct ur e of t he soft w ar e. St at ic st r uct ur e r efer s t o how elem ent s of soft w ar e r elat e t o each ot h er .

•

Dy nam ic st r uct ur e of t he soft w ar e, m eaning t he r elat ionships t hat change ov er t he lif et im e of t h e sof t w ar e an d det er m in e w h at t h e sof t w ar e look s lik e w h en it is r u n n in g.

•

Com posit ion ( or decom posit ion) of t he soft w ar e. This r efer s t o t he t y pe of significant bu t sm aller pieces, su ch as su bsy st em s an d m od u les, t h at can b e p ar t of t h e sof t w ar e.

•

Com ponent s and int eract ion am ong t hem . This refers t o t he various pieces t hat m ake u p t h e sof t w ar e an d h ow t h ey in t er act w it h each ot h er .

•

Lay er s and int er act ion am ong t hem . Lay er ing allow s im posit ion of a specific ordering or st r u ct u r e u pon t h e sof t w ar e, t h er eby per m it t in g an d/ or pr ev en t in g cer t ain r elat ion sh ip s as d eem ed ap p r op r iat e f or t h e sof t w ar e.

•

Or ganizat ion of t he physical soft w ar e pieces t o be deployed. The physical sour ce code m ust be or ganized int o appr opriat e t ypes of deployable unit s, for exam ple, .j ar, .w ar, an d . ex e files, for opt im al u sage

•

Const raint s on t he soft ware. Lim it at ions, eit her nat ural or self-im posed. For exam ple, t h e r equ ir em en t f or sof t w ar e t o be w r it t en in t h e Jav a lan gu age.

•

Rat ionale for t he soft ware. That is, why does t he soft ware look t he way it does? This is im por t an t becau se fr om an ar ch it ect u r al per spect iv e, if som et h in g can n ot be ex plained, t hen it isn' t r eally par t of t he ar chit ect ur e.

•

St y le t h at g u id es t h e sof t w ar e d ev elop m en t an d ev olu t ion .

•

Fu n ct ion alit y of t h e sof t w ar e. I n ot h er w or d s, w h at d oes t h e sof t w ar e d o?

•

Set of sign if ican t decision s abou t t h e or gan izat ion of t h e sof t w ar e sy st em .

•

Ot h er con sider at ion s su ch as r eu se, per f or m an ce, scalabilit y , an d so on .

The follow ing definit ion p er h ap s b est cap t u r es t h e essen ce of sof t w ar e ar ch it ect u r e:

The soft w ar e ar chit ect ur e of a pr ogr am or com put ing sy st em is t he st r uct ur e or st r uct ur es of t he syst em , w hich com prise soft w are com ponent s, t he ext ernally visible propert ies of t hose com pon en t s, an d t h e r elat ion sh ips am on g t h em [ B a s s

1997].

Soft w ar e ar ch it ect u r e is addit ion ally con cer n ed w it h :

…usage, funct ionalit y , per for m ance, r esilience, r euse, com pr ehensibilit y , econom ic and t ech n ological con st r ain t s an d t r ade-of f s, an d aest h et ics [ K r u c h t e n

1999].

Som e of t h ese lat t er aspect s of sof t w ar e ar ch it ect u r e, of cou r se, h av e a som ew h at m or e et h er eal n at u r e an d d o n ot len d t h em selv es easily t o p r ecise an aly sis as d o st r u ct u r e an d decom posit ion, for ex am ple.

I t should be clear from t he preceding definit ions t hat archit ect ure is m ult ifacet ed. As such, no single diagram or drawing can be viewed as represent ing t he archit ect ure of given soft ware. Nor is ar ch it ect u r e j u st a r epr esen t at ion of t h e u n der ly in g in f r ast r u ct u r e or t h e det ailed design of t h e sy st em .

Ar ch it ect u r e is on ly con cer n ed abou t t h e in t er n al det ails of t h e sof t w ar e t o t h e ex t ent t hat t h ese in t er n al det ails ar e m an if est ed ex t er n ally ( f or ex am ple, h ow a com pon en t beh av es w h en v iew ed f r om t h e ou t side) .

Why Architecture? Ev er y piece of soft w ar e ev er cr eat ed has ar chit ect ur e. The ar chit ect ur e ex ist s r egar dless of w h et h er t h e d esig n er of t h e sof t w ar e cr eat ed it k n ow in g ly or ev en k n ew w h at t h e t er m sof t w ar e ar ch it ect u r e m ean t .

So, t h e r eal qu est ion is n ot w h et h er y ou r sof t w ar e n eeds t o h av e ar ch it ect u r e bu t w h et h er y ou n eed t o cr eat e it in a deliber at e f ash ion .

The following list cont ains a few r easons w hy it is im por t ant t o focus on soft w ar e ar chit ect ur e:

•

An ad hoc appr oach t o soft w ar e st r uct ur e w ill ev ent ually lead t o a soft w ar e sy st em t hat is br it t le and har d t o add t o because no consider at ion w as given t o t he need t o ad ap t t o n ew or ch an g ed r eq u ir em en t s.

•

Decom posit ion of t h e sof t w ar e in t o sm aller pieces m ak es t h e sof t w ar e easier t o u n der st an d, m an age, dev elop, an d m ain t ain . I f don e pr oper ly , it can also significant ly im pr ov e r eusabilit y acr oss pr oj ect s.

•

Sof t w ar e ar ch it ect u r e aids in com pon en t -b ased sof t w ar e d ev elop m en t .

•

Per for m ance can be m anaged by ar chit ect ing t he soft w ar e pr oper ly fr om t he st ar t . Consider a proj ect t hat requires a service t hroughout t he soft w are syst em . Whereas in a haphazar d and unplanned ver sion of t he pr oject , t he sam e code m ay be redone ov er an d ov er again leadin g t o u n pr edict able per f or m an ce, a pr oper ly ar ch it ect ed sof t w ar e t h at pr o v ides t h e ser v ice v ia a sin gle com pon en t w ou ld h av e m or e pr edict able per for m an ce.

•

Bet t er r eu se can b e ach iev ed v ia p r op er arch it ect u r e. Con sider a pr odu ct lin e r equ ir in g t h e sam e basic ser v ices w it h sligh t v ar iat ion s. Wit h a lay er in g appr oach , on ly t h e t opm ost lay er s m ay n eed t o be r eplaced. Wit h ou t lay er in g, ex t en siv e ch an ges m ay be n ecessar y t o su ppor t m u lt iple pr odu ct s.

•

I ll-con ceiv ed con st r ain t s can h am per t h e sof t w ar e ev olu t ion , f or in st an ce, a const raint t o have a m onolit hic, nondist ribut ed syst em because dist ribut ed soft ware sy st em s ar e h ar der t o bu ild.

•

Failur e t o under st and and ident ify befor ehand how t he soft w ar e could b e m odified t o accom m odat e m or e user s and heavier dat a pr ocessing, pr ovide new er ser vices, t ake adv ant age of new t echnologies, and so on, can lead t o a sit uat ion w her e t he soft w ar e has t o be rewrit t en because t he original archit ect ure did not consider scala bilit y and

ev olu t ion n eeds. Av ailabilit y an d r eliabilit y of t h e soft w ar e sy st em ar e lar gely depen den t on t h e scalabilit y of t h e sy st em .

•

Hav ing a docum ent ed ar chit ect ur e m ak es it easier t o under st and and com m unicat e t h e in t en t an d su b st an ce of t h e sof t w ar e sy st em t o t h e dev elopm en t t eam .

•

Secur it y built int o t he soft w ar e, t est abilit y of t he soft w ar e, m aint ainabilit y , and over all m anageabilit y of t he soft w ar e ar e also st r ongly influenced by t he ar chit ect ur e of t h e sof t w ar e sy st em .

Key Concepts in Enterprise Ap plication Architecture I n t h is sect ion , w e discu ss som e con cept s t h at ar e cen t r al t o arriving at g ood sof t w ar e ar chit ect ur e. The not ion of ar chit ect ur e, of cour se, is br oader t han t he it em s discussed, but w e focus on t hese because of t heir gr ow ing r ole in t he developm ent of large -scale soft w ar e.

Decomposition

Decom posit ion r efer s t o t he par t it ioning of a sy st em int o sm aller , logical pieces t o m ak e it easier t o m anage t he com plexit y. Modules, subsyst em s, and com ponent s ar e all exam ples of decom posit ion .

Deco m posit ion helps define and clar ify int er faces bet w een differ ent pieces of a syst em . I t can also be h elpf u l in sit u at ion s w h er e y ou m u st in t egr at e legacy or ex t er n ally pu r ch ased applicat ion s.

Decom posit ion can also help w it h dist r ibut ion of t he soft w ar e acr oss m ult iple processors. The dr aw back , of cou r se, is t h at in appr opr iat e or ov er decom posit ion can easily lead t o ser iou s per f or m an ce degr adat ion du e t o t h e com m u n icat ion ov er h ead.

A side ben efit of decom posit ion is t h at it pr ov ides a n at u r al par t it ion in g o f t he developm ent t ask s an d m ak es t h em easier t o dist r ibu t e am on g a lar ger t eam .

I n t he Unified Modeling Language ( UML) , decom posit ion is m odeled via packages, m odules, and subsyst em s. Wit hin t he Java 2 Plat form , Ent erprise Edit ion ( J2EE) , decom posit ion ca n be accom plish ed v ia Web com pon en t s an d En t er pr ise Jav aBean s ( EJB) com pon en t s.

Fi g u r e 6 - 1

sh ow s a sim p le sy st em d ecom p osed in t o sev er al su b sy st em s.

Figure 6 - 1 . Syst em com posed of severa l subsyst ems

Components

A com pon en t is a coh esiv e u n it of sof t w ar e t h at pr ov ides a r elat ed set of f u n ct ion s an d ser v ices.

Com pon en t s can be dev eloped an d deliv er ed in depen den t ly of ot h er com pon en t s; t h at is, t h ey ar e in h er en t ly m odu lar in n at u r e, bu t ar e u sefu l on ly in t h e con t ex t of a com ponent m odel. A com ponent m odel pr ov ides t he under ly ing infr ast r uct ur e for com ponent com posit ion , in t er act ion , an d so on . EJB, Jav a Bean , an d COM ar e ex am ples of com pon en t m odels.

A com pon en t h as w ell-defin ed in t er faces t h at per m it it t o in t er act w it h ot h er com pon en t s. Com ponent s confor m ing t o t he sam e com ponent m odel t hat offer t he sam e int er faces can be su bst it u t ed. I n essen ce, t h e in t er f aces of a com pon en t pr ov ide t h e con t r act s bet w een t h e com pon en t an d t h e applicat ion .

I t is possible for a com pon en t t o con t ain ot h er com p on en t s.

Som e r eason s f or u sin g com pon en t s in clu de

•

Com pared t o t radit ional soft ware, com ponent s are easier t o m aint ain and m odify for f u t u r e n eed s.

•

Com ponent s hav e t he pot ent ial t o incr ease pr oduct iv it y in t he soft w ar e indust r y by allow in g r apid assem bly an d com plet ion of applicat ion s fr om pr ebu ilt com pon en t s.

•

Applicat ions built from com ponent s can pot ent ially be m ore flexible. For exam ple, it is easier t o dist r ibu t e applicat ion s t o m eet h igh er load an d so on .

•

Com pon en t s t h at per f or m specif ic t asks can b e b ou g h t an d sold . Th ese can b e assem bled t oget h er in t o lar ger applicat ion s. Th is r edu ces t im e t o m ar k et ,[ 1 ] overall r esou r ce r equ ir em en t s, ex per t ise r equ ir ed, an d so on . [ 1]

On t h e ot h er h an d, t h is is a pot en t ial r isk fact or as w ell if y ou ar e r ely in g on an

ex t er nal sour ce t o deliv er a cr it ical com ponent .

•

Com pon en t s f acilit at e a n at u r al par t it ion in g of t h e sof t w ar e sy st em in t o coh esiv e u n it s.

Co ar se-gr ain ed com pon en t s m ap w ell t o h igh -level s u bsy st em s ar r iv ed at v ia a fu n ct ion al decom posit ion of t h e sy st em . As t h ey ar e at a h igh er lev el of abst r act ion , coar se-gr ain ed com ponent s m ay hav e few er w ell-defined dependencies. Coarse -gr ained com ponent s aim t o deliv er discr et e an d com plet e bu sin ess capabilit y . I n t he cont ex t of J2EE, single or m ult iple EJBs an d associat ed Jav a classes m ay be u sed t o im plem en t a coar se-gr ained com ponent . Exam ples of coarse -grained com ponent s include a w arehouse m odule t hat keeps t rack of all aspect s of it em s received and dist ribut ed, a life insurance policy processing m odule, a cont act m an agem en t m odu le, an d so on .

Fine-gr ain ed com pon en t s, on t h e ot h er h an d, ar e com par able t o t r adit ion al obj ect s in funct ionalit y and scope. Unlik e coar se-gr ain ed com pon en t s, fin e-gr ained co m ponent s m ay have a large num ber of dependencies. I n t he Java arena, a fine -grained com ponent m aps t o elem en t s su ch as Jav aBean s.

EJBs can be m odeled as UML subsy st em s. See Figure 6 - 2 for one possible r epr esent at ion of an EJB com ponent in t he UML.

Figure 6 - 2 . An EJB com ponent as a UM L subsyst em

Given t he im port ance of int erfa ces in t erm s of com ponent s and t heir relat ionships, it is useful t o m odel t h ese ex plicit ly . A st at ech ar t diagr am can be u sed t o m odel t h e in t er f ace an d t h e v alid seq u en ce of op er at ion s su p p or t ed b y t h e com p on en t .

Com pon en t s also t y pically h av e com plex beh av ior . I t is usually helpful t o ex plicit ly m odel com ponent behavior via an act ivit y diagr am or a st at echar t diagr am t o under st and it in m or e det ail.

We discu ss bot h t h ese m odelin g aspect s in f u r t h er det ail in

Ch a p t e r 1 2 .

Frameworks

I n it s sim plest for m , a fr am ew or k can r efer t o any piece of developed and t est ed soft w ar e t hat is r eu sed in m u lt iple sof t w ar e dev elopm en t pr oj ect s.

More form ally, a fram ew ork provides a generalized arch it ect ural t em plat e t hat can be used t o bu ild applicat ion s w it h in a specific dom ain . I n ot h er w or ds, a fr am ew or k per m it s y ou t o specify , gr ou p t oget h er , an d r eu se elem en t s t o effect iv ely bu ild som e specific soft w ar e sy st em .

Consider t he ex am ple of a soft w are com pany t hat builds som e ser vice soft w ar e syst em s t hat alw ay s include cust om er billing and account m anagem ent funct ionalit y . I t could st ar t each sof t w ar e sy st em f r om scr at ch an d r ew r it e t h e billin g an d accou n t m an agem en t por t ion s. Mor e r ealist ically , t he sof t w ar e com pan y w ou ld be bet t er of f t ak in g t h e billin g/ accou n t in g pieces fr om one of it s ear lier im plem ent at ions and dev eloping a for m al fr am ew or k t o pr ov ide t h e f ou n d at ion f or each n ew sof t w ar e sy st em .

A fram ew ork can be used in t w o basic w ays. I n t he first approach, t he library approach, you use a fram ework for est ablishing a set of reusable com ponent s. I n t he alt ernat e approach, a fr am ew or k is used for cr eat ing a t em plat e for new pr oj ect s or for defining t he ar chit ect ur e of specific t ypes of syst em s. Each approach has it s advant ages, and requires different levels of adv an ce plan n in g an d ef f or t .

Th e library approach con sist s of u sin g a f r am ew or k t o cr eat e a set of r eu sable com pon en t s and is t he easier appr oach in t he sense t hat it is ver y m uch like using a library. Referring back t o t he syst em w it h t he billing and account m anagem ent capabilit ies, you w ould sim ply t ake all t h e r elev an t classes, pu t t h em t oget h er , an d cr eat e a f r am ew or k con t ain in g t h e classes of int er est . When it is t im e t o im plem ent y our n ex t sy st em , it is sim ply a m at t er of using t he f r am ew or k an d r eu sin g t h e desir ed pieces w it h in it t o dev elop t h e billin g an d accou n t m anagem ent funct ionalit y .

I n t h e fram ework as t em plat e approach, y ou cr eat e a f r am ew or k t h at con t ain s assem bled pieces of y ou r t y pical sy st em . Cr eat in g a n ew sy st em sim ply r equ ir es y ou t o u se t h e fr am ew or k as t he basis for t he new applicat ion, and t hen im plem ent abst r act m et hods or use som e ot her form of cust om izat ion ( e.g., subclassing) t o im plem ent t he new soft ware syst em . Clearly, t his is m ore w ork t han sim ply put t ing som e classes int o a loosely organized library, and it requires som e advanced planning. However, it also yields superior result s in t erm s of r eu se becau se y ou u se t h e f r am ew or k t o capt u r e an d r eu se k ey , ex cept io nally scar ce k n ow ledge of t h e sy st em ar ch it ect s. Th e t em plat e appr oach allow s y ou t o dev elop n ew syst em s fast er because not only do you get t he im plem ent at ion code for t he pieces, but you also get an aut hent ic blueprint for put t ing it t oget her in a consistent and usable m anner. For inst ance, if you ar e put t ing t oget her a fr am ew or k for developing I nt er net-based applicat ions, such a fr am ew or k m ight pr ov ide pieces for secur it y , sim ple quer y int er act ions, int er act ions inv olv ing t r ansact ions, user confir m at ion s er v ices, an d so on alon g w it h in st r u ct ion s on su ppor t ed con f igu r at ion s an d h ow t o qu ick ly assem ble t h e dif f er en t pieces t o cr eat e a n ew I nt ernet applicat ion. Brokat Financial Fram ework by Br ok at Technologies[ 2 ] is an exam ple of such a com m er cial fr am ew or k based on t he J2EE t echnology t hat can be r eused and r apidly ex t en ded t o dev elop n ew f in an cial applicat ion s. [ 2]

See ht t p: / / w w w . br ok at . com / for det a ils

Regardless of t he approach, t he end result of using fram eworks is an increase in t he relat ive am ount of t im e you can spend on developing t he feat ures and funct ionalit y and less relat ive

t im e spent on r ehashing w hat you have alr eady done. I n t he pr ocess, you also decrease t he ov er all sof t w ar e d ev elop m en t t im e b ecau se y ou cr eat e less n ew sou r ce cod e.

Som e con sider at ion s in dev elopin g a fr am ew or k :

•

The fram ework should be sim ple t o underst and. Deep in h er it an ce h ier ar ch ies an d inconsist ent API s and such m ake for poor fram eworks. Rem em ber, t he idea is t o get t he user t o st ar t using t he fr am ew or k quick ly and effect iv ely .

•

Provide adequat e docum ent at ion . Keep in m in d t h at ot h er s w ill u se t h e fr am ew or k you are developing over a long period of t im e. The m ore you can clarify t he int ent of t he fram ework, docum ent t he assum pt ions, and show how you m eant it t o be used, t h e lon ger t h e f r am ew or k w ill last .

•

I dent ify concret e fram ework ext ension m echanism s . Fram eworks grow over t im e t o m eet new needs. By pr ov iding built -in ex t en sion m ech an ism s or iden t ify in g t h e pr oper w ay of ex t en din g t h e f r am ew or k , t h e f r am ew or k w ill ev olv e in t o a m or e versat ile and cohesive fram ew ork rat her t han det eriorat e int o a hodge -podge of code. For t h e I n t er n et-based applicat ion fr am ew or k ex am ple m en t ion ed ear lier , a consider at ion m ight be t o iden t ify fr am ew or k ext ension point s t o easily suppor t new con n ect ion t y pes in t h e fu t u r e, for ex am ple, w ir eless in st ead of lin e-b a sed con n ect ion s.

Patterns

A soft w ar e pat t er n is a r eusable design t hat has been capt ured, dist illed, and abst ract ed out t h r ou gh ex per ien ce an d h as been pr ov en su ccessf u l in solv in g specif ic t y pes of pr oblem s.

Pat t er n s ar e u sef u l b ecau se:

•

Th ey con v ey pr ov en k n ow ledge capt u r ed t h r ou gh y ear s of ex per ien ce. Usin g p at t er n s can r ed u ce t h e ov er all r isk of failur e due t o specific t y pes of m ist ak es.

•

They can help in solv ing difficult pr oblem s t hat hav e been encount er ed in sim ilar sit u at ion s.

•

Use of w ell-est ablished soft w ar e pat t er ns enhances com m unicat ion w it hin t he t eam by pr ov idin g t h e basic con t ex t for discu ssion am on g t eam m em ber s.

Sof t w ar e pat t er n s ar e gen er ally classif ied in t o, am on g ot h er s, t h e f ollow in g cat egor ies: analysis pat t erns, archit ect ural pat t erns, design pat t erns, and coding pat t erns. The prim ary d if f er en ce b et w een t h e cat eg ories of pat t er n s is t h e lev el of abst r act ion .

For inst ance, archit ect ural pat t erns deal w it h t he st ruct ure of soft w are syst em s, subsyst em s, or com p on en t s an d h ow t h ey r elat e t o each ot h er . Desig n p at t er n s, on t h e ot h er h an d , op er at e at t h e class an d ob j ect lev el. They ar e based on pr ov en solut ions t o pr oblem s t hat ar ise w h en design in g sof t w ar e in a specif ic con t ex t .

Design pat t er n s ar e t y pically classif ied in t o t h r ee br oad cat egor ies:

•

Creat ional: Cr eat ion al design pat t er n s pr ov ide solu t ion s t o con f igu r at ion an d init ializat ion design pr oblem s. A singlet on pat t er n , w h ich pr ov ides f or a pat t er n f or r est r ict ing t he class t o a single inst ance, is an ex am ple of a cr eat ional design pat t er n.

•

St ruct ural: St r u ct u r al design pat t er n s solv e design pr oblem s by st r u ct u r in g t h e int erfaces and t heir class relat ionships in specific w ays. Proxy pat t ern, discussed lat er in t h is sect ion , is an ex am ple of a st r u ct u r al design pat t er n .

•

Behavioral: Beh av ior al pat t er n s iden t if y w ay s in w h ich a gr ou p of classes in t er act w it h each ot h er t o ach iev e a specific beh av ior . An ex am ple is t h e Obser v er pat t er n discu ssed lat er in t h is sect ion .

Design pat t er ns can be applied t o ex ist ing elem ent s w it hin a design t o im pr ov e a solut ion, or a new set of elem ent s can be const ruct ed using a design pat t e rn t o solve a problem t hat has b een r ecog n ized t h r ou g h an aly sis.

Fi g u r e 6 - 3

sh ow s a sim ple design pat t er n com m on ly r efer r ed t o as t h e Pr ox y pat t er n . I n t h is

pat t er n , an obj ect ( Pr ox y ) is essen t ially pr ov iding an indir ect access m echanism t o anot her obj ect ( RealSu bj ect ) . Th is is iden t if ied v ia t h e associat ion bet w een t h e Pr ox y an d t h e RealSubj ect . The Subj ect pr ov ides a com m on int er face t o Pr ox y and RealSubj ect , t her eby allow in g t h em t o w or k closely . This r elat ionship is capt ur ed v ia t he com m on int er face r ealizat ion .

Figure 6 - 3 . A design pat t ern

For inst ance, a Proxy m ay be useful in sit uat ions where access t o t he act ual resource cannot b e allow ed d u e t o secu r it y r eason s.

We ident ify and refer t o som e exist ing and em erging pat t ern s relevant t o J2EE developm ent in t h e J2 EE t ech n ology ch apt er s.

Pat t er ns ar e r epr esent ed in t he UML using a collaborat ion. A collaborat ion is a descript ion of a gen er al ar r an gem en t of obj ect s an d lin k s t h at in t er act w it h in a con t ex t t o im plem en t a behav ior. I t has a st at ic and a dynam ic par t . The st at ic par t descr ibes t he r oles t hat obj ect s an d lin k s m ay play in an in st an ce of t h e collabor at ion . Th e dy n am ic par t con sist s of on e or m or e in t er act ion s t h at sh ow m essage f low s ov er t im e in t h e collabor at ion .

A param et erized collaborat ion, t h at is, a collabor at ion m ade of gen er ic m odel elem en t s, is used for design pat t erns t hat can be applied repeat edly. This is accom plished by binding t he generic m odel elem ent s in t he param et erized collaborat ion t o specific m odel elem ent s w hen t h e collabor at ion is in st an t iat ed.

Collaborat ion support s specializat ion; hence, it is possible t o creat e collaborat ions t hat inherit fr om ot h er collabor at ion s.

I n t he UML, t he use of a collabor at ion is r epr esent ed by a dashed ellipse. Relat ionships wit h classes par t icipat ing in t he collabor at ion ar e show n via a dashed line fr om t he collabor at ion t o t h e class.

Fi g u r e 6 - 4

sh ow s a UML collabor at ion r epr esen t at ion f or t h e Su bj ect -Obser v e r pat t er n. The

pat t ern is properly represent ed t oget her w it h t he st ruct ural specificat ion in t he form of a class diagr am , and t he behavior al specificat ion is indicat ed using a sequence diagr am or st at echar t diagr am .

Figure 6 - 4 . A collaborat ion represent ing t he Subj ect - Obse r ve r pa t t e r n

The class and sequence diagr am s for t he Subj ect -Obser v er design pat t er n ar e show n in Figure 6-5

an d

Fi g u r e 6 - 6 ,

r espect iv ely .

Figure 6 - 5 . Cla ss dia gra m for Subj ect - Obse r ve r pa t t e r n

Figure 6 - 6 . Sequence diagram illust rat ing t he Subj ect - Obse r ve r pa t t e r n

Th e gen er al idea is t h at obser v er s r egist er w it h a su bj ect f or n ot if icat ion w h en t h er e is a ch an g e t o t h e su b j ect , an d t h e ob ser v er s ar e n ot if ied w h en t h er e is a ch an g e so t h ey can updat e t heir infor m at ion accor dingly. Consider t his sim ple r eal-life exam ple: You and several ot h er s ar e in t er est ed in u pdat es t o a specif ic p r odu ct an d h av e in dicat ed t h is t o t h e m an u f act u r er by r egist er in g f or u pdat es. Wh en t h e pr odu ct is u pdat ed, y ou an d t h e ot h er obser v er s ar e n ot if ied of t h e ch an ge t o t h e pr odu ct . At t h at t im e, all obser v er s can indiv idually quer y t he pr oduct t o find out t he d et ails of t h e u p d at e.

Layering

Lar g e-scale en t er pr ise sof t w ar e can be com plex an d dif f icu lt t o dev elop an d m an age. Layer ing is a pat t er n for decom posit ion. Decom posit ion leads t o a log ical par t it ioning of t he sy st em in t o su bsy st em s an d m odu les, an d layer s g r ou p an d sep ar at e t h ose su b sy st em s, t her eby const r aining w ho can use t he subsy st em s, com ponent s, and m odules. Lay er s cr eat e separ at ion of concer ns w it hin t he soft w ar e by abst r act ing specific t ypes of funct ionalit y int o funct ional lay er s and pr ov iding con cep t u al b ou n d ar ies b et w een set s of ser v ices.

Th e Rat ion al Un ified Pr ocess ( RUP) iden t ifies t w o com m on appr oach es t o lay er in g:

•

Responsibilit y -dr iv en lay er ing

•

Reu se-dr iv en lay er ing

I n r esponsibilit y -dr iv en lay er ing, lay er s hav e w ell-def in ed r espon sibilit ies, m ean in g t h ey fulfill a specific role in t he overall schem e of t hings. Such layers are also referred t o as t ier s. See t h e n ex t sect ion f or m or e det ails on t ier s.

I n reuse -dr iv en lay er ing, lay er s ar e cr aft ed so as t o pr ov ide t he m ost r euse of elem ent s of t he sy st em . I n such a set up, lay er s t y pically pr ov ide ser v ices t o ot her lay er s. This per m it s lay er s t o be u n der st ood in div idu ally w it h ou t n ecessit at in g u n der st an din g or sign if ican t pr ior k n ow led g e of t h e lay er s ab ov e or b elow t h em , w h ich lead s t o low er co u p lin g b et w een t h e lay er s.

For ex am ple, a soft w ar e sy st em m ay hav e, am ong ot her lay er s, a pr esent at ion ser v ices lay er t o pr ov ide capabilit ies t hat allow t he display of infor m at ion t o t he user and a gener al ser v ices lay er t o pr ov ide ser v ices su ch as loggin g, er r or h an dlin g, an d so on .

A u ser sh ou ld b e ab le t o u se t h e p r esen t at ion ser v ices cap ab ilit ies w it h ou t r eg ar d t o t h e lay er s below it .

The relat ionship am ong layers is st rict ly hierarchical in nat ure. That is, a layer m ay rely on t he lay er below it , but n ot v ice v er sa. Fr om t he st andpoint of r educing coupling, it is also desir able t o n ot h av e an y depen den cies bet w een lay er s t h at ar e n ot im m ediat e n eigh bor s. I ndeed, J2EE pr ovides an exam ple of layer ing it self, w her e t he cont ainer is a layer built on t op of t h e oper at in g sy st em .

Depending on t he com plexit y of t he soft w ar e syst em , layer s can also cont ain ot her sublayer s. Lay er s sh ou ld gen er ally n ot by pass lay er s im m ediat ely below t h em t o access ot h er lay er s, bu t t h is is accept able if t h e in t er m ediat e lay er s on ly act as by st ander s, t hat is, sim ply pass alon g t h e r equ est t o t h e n ex t lay er an d so on . For ex am ple, f or ser v ices su ch as er r or r epor t in g, it m ay m ak e sen se t o dir ect ly access t h em t h r ou gh ou t t h e applicat ion .

Lay er s ar e t y pically st r u ct u r ed su ch t h at t h e low est lay er is m ost t igh t ly cou pled t o t h e h ar dw ar e an d oper at in g sy st em . Middle lay er s pr ov ide t h e f ou n dat ion f or bu ildin g a w ide var iet y of soft w ar e syst em s r equir ing sim ilar capabilit ies. The t op layer cont ains t he soft w ar e elem ent s r equir ed for m eet ing slight ly varying end user requirem ent s, for exam ple, specific

bu sin ess ser v ices av ailable in t h e applicat ion t o specific cu st om er s or cu st om izat ion of t h e applicat ion f or Eu r opean v er su s Asian cu st om er s.

Lay er s should be an im por t ant st r uct ur al considerat ion in any ent er pr ise applicat ion design. Gen er ally speak in g, sm aller sof t w ar e sy st em s w ill r equ ir e f ew er lay er s, w h er eas lar ger sy st em s m ay r equ ir e m or e lay er s. How ev er , ev en lar ge applicat ion s do n ot gen er ally h av e lay er s in t h e dou ble digit s.

I n t he U ML, lay er s ar e r epr esen t ed as a pack age w it h t h e < < lay er > > st er eot y pe. Fi g u r e

6-7

show s an ex am ple of a UML lay er ed ar chit ect ur e. See Chapt er 13 for addit ional discussion in t he con t ex t of t h e sam ple applicat ion .

Figure 6 - 7 . A layered archit ect ure in UM L

Tiers

Tiers are prim arily concerned wit h dist ribut ion of a soft ware syst em over m ul t iple, separat e processes. Processes m ay be physically dist ribut e d ov er m ult iple pr ocessor s or r eside on t he sam e ph y sical dev ice.

Tiers can be m apped t o responsibilit y-dr iv en lay er s in w hich case a t ier becom es sy nony m ous w it h fu lfillin g a specific r ole w it h in t h e sy st em , su ch as pr esen t at ion , bu sin ess logic, dat a acce ss, an d so on .

Mainst r eam com put ing has evolved over t im e int o t he m ult it ier ed ar chit ect ur es in use t oday. I n t he early days of com put ing, m ainfram es and dum b t erm inals charact erized t he com put ing env ir onm ent . Tw o-t ier ed, LAN-based clien t -ser v er sy st em s w er e t he nor m for a long t im e. And alt hough n -t ier ar chit ect ur es have been ut ilized in specific indust r ies for a long t im e, it is only r ecent ly t hat n -t ier ar chit ect ur es ar e becom ing m ainst r eam in t he indust r y .

Tier ed ar chit ect ur es ar e desir able fr om t he point of view of increasing t hroughput , availabilit y, or funct ionalit y of t he sy st em by incr easing t he ov er all, phy sical pr ocessing pow er . Tier ed archit ect ures can also play a role in separat ing out different areas of applicat ion concerns t o im pr ov e ov er all m aint ainabilit y .

Such dist r ibut ion int r oduces

•

Com m unicat ion efficiency and r eliabilit y issues bet w een t ier s

•

The need for ident ificat ion and locat ion of com ponent s in a dist r ibut ed env ir onm ent

•

Secu r it y issu es du e t o a pot en t ially div er se an d geogr aph ically d ist r ib u t ed sy st em

•

Sy n ch r on izat ion issu es bet w een t ier s

•

Failu r e r ecov er y issu es

•

Th e n eed for addit ion al in t er faces t o accom m odat e t h e t ier ar ch it ect u r e

•

Addit ion al r esou r ce n eeds du e t o t h e dist r ibu t ed n at u r e of t h e sof t w ar e

As discu ssed ear lier , on e w ay t o achiev e dist r ibut ion in an n -t ier ar chit ect ur e is t o align specific lay er s w it h each t ier . J2 EE follow s t h is appr oach .

I n t h e J2 EE t ier ed ar ch it ect u r e:

•

Client t ier is pr im ar ily concer ned w it h user int er act ion.

•

Pr esen t at ion t ier d eals w it h p r esen t in g t h e r e su lt s of b u sin ess q u er ies.

•

Bu sin ess t ier con t ain s t h e k ey bu sin ess r u les.

•

Dat a t ier p r ov id es t h e in t er f ace t o t h e p er sist en t d at a st or e.

Th e J2 EE appr oach is sh ow n gr aph ically in

Fi g u r e 6 - 8 .

Figure 6 - 8 . J2 EE t ie r s

Approaches to Software Architecture Num erous approaches t o soft w are archit ect ure have been proposed and ut ilized over t im e. I n t his sect ion, w e highlight som e published appr oaches t o soft w ar e ar chit ect ur e t o pr ov ide y ou w it h a b r oad er p er sp ect iv e.

Each of t hese appr oaches has it s st r ong point s and w eak nesses as w ell as it s adv ocat es and crit ics.

The J2EE View of Architecture

Tiers + com ponent s + services ar e k ey t o u n der st an din g t h e J2 EE ar ch it ect u r al ph ilosoph y .

Giv en t h at t h e J2 EE is pr edom in an t ly focu sed on pr ov idin g a v iable pr oposit ion for building lar ge-scale en t er pr ise applicat ion s t h at ar e scalable, it sh ou ld com e as n o su r pr ise t h at it adv ocat es par t it ioning t he applicat ion int o m ult iple t ier s. The J2 EE plat for m pr ov ides m echanism s t o decom pose t he syst em int o relat ively coarse -g rained com ponent s. J2EE also ad v ocat es a ser v ices-based ar chit ect ur e t hat is char act er ized by a collect ion of cooper at ing and com m unicat ing ser v ices. The ser v ices r ely on w ell-defined API s for int er oper abilit y .

The J2 EE official guidelines shy aw ay fr om a st r ict r ecom m en dat ion of adh er en ce t o a lay er-like hierarchical view of t he t iers, opt ing inst ead for a m ore accom m odat ing st ance. The su ggest ion is t o u se t h e t ier s an d associat ed t ech n ologies if it m ak es sen se f or t h e specif ic sit uat ion. For ex am ple, it is per fect ly appr opr iat e t o access t h e dat a t ier dir ect ly fr om t h e pr esen t at ion t ier .

J2 EE r ecom m en ds u sin g t h e Model-View -Cont r oller ( MVC) [ 3 ] ar chit ect ur al par adigm for developing ent erprise applicat ions. As discussed br iefly in Chapt er 2 , t he basic idea behind t he MVC is t o m inim ize t he coupling am ong obj ect s in a sy st em by aligning t hem w it h a specific set of r esp on sib ilit ies in t h e ar ea of t h e per sist en t dat a an d associat ed r u les ( Model) , pr esent at ion ( View ) , and t he applicat ion logic ( Cont r oller ) . [ 3]

For m or e det ails an d t h e J2 EE per spect iv e on t h e MVC par adigm , see

j av a. sun. com / j 2ee/ bluepr int s/ design_pat t er ns/ m odel_v iew _cont r oller / index . ht m l. Addit ion al sou r ces ar e list ed in t h e Ref er en ces sect ion at t h e en d of t h is book .

The 4+1 View Model of Architecture

The prim ary m ot ivat ion behind using different views for archit ect ure is t o reduce t he overall com plexit y.

A v iew is essen t ially a look at t h e m odel fr om a specific v an t age poin t or per spect iv e, su ch t h at on ly t h e det ails t h at ar e r elev an t an d im por t an t ar e in clu ded an d all else is ign or ed.

Originally proposed as t he 4+ 1 View Model of Archit ect ure [ Krucht en 1995 ] , it is now part of t he RUP. I t h as b een w id ely u sed as t h e b asis for ar chit ect ur al analy sis and design of sy st em s.

The basic prem ise behind t he 4+ 1 View of Model Archit ect ure is t hat a soft w are syst em can be m odeled w ell w it h t h e f ollow in g in t er lock in g v iew s:

•

Th e Logical View m odels design pack ages, su bsy st em s, an d classes.

•

Th e I m plem ent at ion View descr ibes t h e ph y sical or gan izat ion of t h e sof t w ar e, f or ex am ple, ex ecu t ables, libr ar ies, sou r ce code, an d so on .

•

Th e Process View is con cer n ed w it h t h e con cu r r en cy aspect s of t h e sof t w ar e. For ex am ple, pr ocesses, t ask s, an d t h r ead s t h at ar e p ar t of t h e sof t w ar e sy st em .

•

Th e Deploym ent View focuses on t he m apping of t he execut ables ont o phy sical nodes an d com pu t in g h ar dw ar e.

•

Th e Use Case View is a special v iew in t h at it t ies all ot h er v iew s t oget h er .

This list does not im ply t hat t her e can be no ot her v iew s. For inst ance, it w ould be r easonable an d desir able t o h av e a secu r it y or a t r an sact ion v iew f or J2 EE-b ased so f t w ar e.

Hofmeister et al.: Four Views of Architecture

Hofm eist er , Nor d, and Soni pr esent a slight ly differ ent v iew f or ach iev in g sof t w ar e ar chit ect ur e [ H o f m e i s t e r

2000]

based on fou r v iew s, som e of w h ich par t ially ov er lap t h e 4 + 1

View s discu ssed ear lier :

•

Th e Concept ual View is prim ar ily concer ned w it h concept ually sound decom posit ion of t h e sy st em in t o v er y coar se-gr ain ed com pon en t s called capsules.[ 4 ] Th ese capsu les in t er act w it h each ot h er v ia con cept u al con n ect or s. Capsu le s an d con n ect or s f or m t h e basis f or t h e ev en t u al sof t w ar e sy st em . [ 4]

Th e con cept of capsu les is based on t h e con cept of act iv e obj ect s called act or s

( w hich ar e t o be dist inguished fr om use case act or s) , pr oposed for r eal-t im e soft ware sy st em s [ Selic 1994] .

•

Th e Module View deals w it h t h e r ealizat ion of capsu les an d con n ect or s. Th e coar se-gr ain ed com pon en t s ar e m apped t o act u al su bsy st em s an d m odu les in t h e con t ex t of t h e s pecific t ech n ology t o be em ploy ed for t h e pr oj ect .

•

Th e Execut ion View deals w it h t h e flow of con t r ol w it h in t h e r u n t im e sy st em . Th is in clu des issu es su ch as con cu r r en cy , dist r ibu t ion , an d per for m an ce.

•

Th e Code View em b od ies h ow t h e com p on en t s ar e m ap p ed t o sou r ce f iles an d ex ecu t ables as w ell as con cer n s su ch as bu ild t im es an d dev elopm en t t ools.

Putting It All Together Which com es first —soft ware archit ect ure or analysis? The answer, of course, part ly depends on t o w h om y ou t alk .

Ar chit ect ur e pr ov ides t he b lu epr in t f or t h e sof t w ar e, bu t w it h ou t pr oper an aly sis, t h e r eq u isit e u n d er st an d in g of t h e sy st em—r equ ir ed for t h e blu epr in t —can n ot b e d ev elop ed . Thus, it is v er y m uch an it er at iv e pr ocess in t hat r equir em ent s for m a k ey input int o t he sof t w ar e ar ch it ect u re, but t her e m ay be a need t o adj ust or clar ify t he r equir em ent s as t he ar ch it ect w or k s t h r ou gh t h em t o ar r iv e at t h e ar ch it ect u r e.

Defining a soft w ar e ar chit ect ur e is v er y m uch an ev olut ionar y pr ocess. Alt hough an ar chit ect m ay w an t t o st ar t w it h som e b asic not ions about w hat m ay be appr opr iat e or inappr opr iat e based on past ex per ience, he cannot sim ply t ak e t he r equir em ent s and ex pect t o ar r iv e at t he

final ar chit ect ur e ov er night . The ar chit ect ur e gr adually t ak es shape as deliber at e, infor m ed d ecision s are m ade w it h specif ic r equ ir em en t s an d t r ade-offs in m ind.

I t should be em phasized t hat t he concept s discussed in t his chapt er ar e pr im ar ily t ools at t he disposal of an ar chit ect . Lik e all t ools, t hey ar e useful only w hen used in t he pr oper cont ex t rat her t han for t he sake of using t he concept s. For exam ple, if no part icular pat t ern exist s t o addr ess t h e pr oblem f aced, it w ou ldn ' t m ak e sen se t o alt er t h e design so y ou cou ld apply som e p at t er n s.

We furt her discuss aspect s of archit ect ure in t heir proper cont e xt , t hat is, alongside analysis an d design as w e f ace specif ic pr oblem s an d addr ess par t icu lar con cer n s.

Summary Soft w ar e ar ch it ect u r e is an all-im por t an t bu t of t en n eglect ed, or at least m is u n der st ood, asp ect of en t er p r ise sof t w ar e d ev elop m en t .

Sof t w ar e ar ch it ect u r e is m u lt if acet ed an d cov er s m or e t h an sof t w ar e st r u ct u r e. No sin gle diagr am can be u sed t o descr ibe sof t w ar e ar ch it ect u r e.

Som e k ey con cept s in t h e ar ea of soft w ar e ar ch it ect u r e ar e decom posit ion , lay er in g, t ier s, pat t er n s, fr am ew or k s, an d com pon en t -b ased sof t w ar e. Th ese ar e essen t ially t ools at t h e disposal of an ar ch it ect r at h er t h an " m u st apply " con cept s f or all sof t w ar e pr oj ect s.

Discov er y of t h e sof t w ar e ar ch it ect u r e is an ev olu t ion ar y pr ocess an d m u st be don e in t h e cont ex t of t he r equir em ent s and in conj unct ion w it h t he analysis. This appr oach is follow ed in t h is book .

Chapter 7. Analyzing Customer Needs •

W h y So f t w a r e An a l y si s a n d D e si g n ?

•

Pr o b l e m An a l y si s

•

U s e Ca s e M o d e l i n g

•

I d e n t i f y i n g t h e Act o r s

•

Fi n d i n g t h e Use Ca se s

•

Us e Ca s e D i a g r a m s

•

Us e Ca s e Re l a t i o n s h i p s

•

Se q u e n ce D i a g r a m s

•

Act i v i t y D i a g r a m s

•

Su m m ar y

Pr oce ss Ch e ck : W e spe n d a m a j or it y of t h is ch a pt e r in t h e Ra t ion a l Un ifie d Pr oce ss ( RUP) r e qu ir e m e n t s disciplin e .

I n t his chapt er, we look int o t he need for soft ware analysis and design and how t o go about it .

To keep t he exam ples relevant , we have chosen t o use port ions of t he case st udy docum ent ed in

Chapt er 16 .

The case st udy describes t he developm ent of an online banking

syst em . To get t he m ost out of t he exam ples, you should review t he " Hom eDir ect sect ion in

Requir em ent s "

Chapt er 16 .

Why Software Analysis and Design? Let 's st ar t by t r y in g t o an sw er a basic qu est ion : Wh y ev en t alk abou t an aly sis an d design ? Aft er all, an aly sis seem s t o h av e fallen off t h e fav or it es list of som e dev eloper s [ 1 ] an d h as ev en b een lab eled as lead in g t o n ot h in g m or e t h an " an aly sis par aly sis. " [ 1]

Ex t r em e Pr ogr am m ing ( XP) , for ex am ple, does not giv e m uch cr edence t o analy sis.

Ther e is alw ay s t he possibilit y t hat som e t eam s m ay get bogged dow n in t he analy sis phase. How ev er , sk ipping analy sis and design alt oget her and j um ping st raight int o im plem ent at ion h ar d ly ap p ear s t o b e t h e b est alt er n at iv e.

Su ppose y ou w an t t o go fr om Poin t A t o Poin t B. I f A an d B ar e fair ly close, an d y ou ar e gen er ally fam iliar w it h t h e ar ea, it sh ou ld be r elat iv ely st r aigh t for w ar d t o u n d er t ak e t h e j ou r n ey w it h ou t bot h er in g t o look at a m ap an d doin g som e adv an ce plan n in g.

On t he ot her hand, if A and B happen t o be a gr eat dist ance apar t , and y ou ar e dealing w it h unchar t ed t er r it or y , y our chances of success ar e gr eat ly im pr ov ed if y ou do som e pr ior plan n in g.

Soft w are developm ent is no different . For sm all soft w are proj ect s using fam iliar t echnology in a com for t able dom ain, per haps y ou can get by w it hout analy sis and design. But it is essent ial in large, unfam iliar t errit ory t ype proj ect s if y ou ar e t o av oid t he pit falls and disast er s t o w hich a v ast m aj or it y of pr oj ect s fall v ict im . [ 2 ] [ 2]

According t o t he St andish Group's Chaos Report , 1998; only " 26 percent of soft w are proj

ect s succeed. "

Problem Analysis Requir em ent s com e in all shapes and for m s and fr om a var iet y of sour ces. For exam ple, t hey m ay be pr esen t ed in t h e f or m of w r it t en docu m en t s by an en d u ser , v ia m eet in gs w it h v isionar ies in t he com pany , or v ia dir ect cust om er in t er act ion an d face -t o-face v isit s.

Proj ect s oft en fail because t he requirem ent s w ere not accurat ely underst ood. This is not t oo su r pr isin g in ligh t of t h e fact t h at lan gu age, w h et h er w r it t en or or al, is im pr ecise by n at u r e an d open t o m u lt iple in t er pr et ation s. So, t h e fir st t h in g t o do is t o m ak e su r e t h e basic r eq u ir em en t s ar e u n d er st ood ; t h at is, g o b ey on d w h at is ob v iou s an d st at ed in t h e requirem ent s docum ent . I t is only t hrough such an approach t hat you can really ident ify t he essen t ial u sag e p at t er n s f or t h e sof t w ar e sy st em y ou w ill be dev elopin g.

This is w her e use cases com e in. You can apply use case m odeling t o develop a pr ecise m odel of w hat is r equir ed of t he sy st em , and t hen ut ilize t he use cases as t he basis for dr iv ing ot her aspect s of y our ent er pr ise sy st em dev elopm ent . I n effect , a use case act s as t he st r ing t hat binds t he beads of a neck lace t oget her . Use cases br idge t he gap bet w een t he end user and t he requirem ent s of t he syst em . They can be used t o est ablish t ract abilit y bet w een funct ion al r equir em ent s and t he sy st em im plem ent at ion it self.

Th e an aly sis is best don e in a gr ou p set t in g. I t h elps t o h av e differ en t people look in g at t h e sam e r equir em ent s fr om t heir indiv idual point s of v iew . I t is usually also helpful t o hav e a dom ain ex per t t ak e par t in t h e discu ssion s. Par t icipat ion of t h e cu st om er , or au t h or of t h e requirem ent s, is also beneficial so t hat you can gain first hand knowledge of t he int ent . All t his deliber at ion m ay sav e y ou a lot of r ew or k lat er . Som e t ech n iqu es t h at can be u sed at t h is st age t o get t o t h e bot t om of a pr oblem in clu de br ain st or m in g session s an d f ish bon e diagr am s.

When going t hr ough t his st age, it is helpful t o t r y t o r educe duplicat e r equir em ent s and dist ill t he ov er all set of r equir em ent s int o a sm aller num ber . Av oid t he t em pt at ion t o do t he design at t h e sam e t im e as gat h er in g r equ ir em en t s. Requ ir em en t -cr eep ( sim ilar t o feat ur e -cr eep w h er e feat u r es con t in u e t o gr ow w ay bey on d t h e or igin al in t en t ) sh ou ld also be av oided by ex er t in g a v igor ou s at t em pt at t r aceabilit y t o t h e cu st om er n eeds.

For a m or e t h or ou gh discu ssion of t h is t opic, see Object -Orient ed Analysis and Design wit h Applicat ions, by Gr ady Booch, Addison-Wesley , 1 9 9 4 , an d Use Cases -Requirem ent s in Cont ext , by Dar y l Kulak et al., Addison-Wesley , 2 0 0 0 .

Use Case Modeling I v ar Jacobson et al. [ 3 ] p op u lar ized t h e ap p licat ion of u se cases f or u n d er st an d in g t h e funct ional syst em r equir em ent s in t he ear ly 1990s. Lat er , use case not at ion w as incor por at ed in t o t he Unified Modeling Language ( UML) . I t is seem ingly sim ple in concept but highly useful, especially in u n der st an din g t h e fu n ct ion al r equ ir em en t s for lar ge an d com plex sy st em s. [ 3]

Jacobson, I v ar , et al. Object -Orient ed Soft ware Engineering. Addison-W e sley , 1 9 9 2 .

I n t h e con t ex t of t h is book , u se cases ar e v er y im por t an t as t h e RUP is v er y m u ch a u se case -driven developm ent process. Not only are use cases used t o capt ure t he requirem ent s, bu t t h ey also pr ov ide t h e fou n dat ion for act iv it ies fr om an aly sis t h r ou g h t est in g .

Th er e ar e t w o f u n dam en t al con cept s in u se case m odelin g:

•

Act or: An act or r epr esen t s som et h in g ( or som eon e) ou t side t h e sy st em , t y pically a user of t he syst em . Act ors int eract w it h t he syst em , w hich result s in som e act ion by t he sy st em . Each dist in ct r ole is r epr esen t ed by an act or .

•

Use case: A use case encapsulat es a sequence of st eps perform ed by t he syst em on beh alf of an act or . Use cases pr ov ide som et h in g of v alu e t o t h e act or . A u se case con sist s of a pr im ar y sequ en ce of ev en t s an d m ay h av e on e or m or e alt er n at e seq u en ces of ev en t s.

Requir em ent s com e in t w o pr im ar y flav or s: funct ional an d nonfunct ional. Funct ional r equ ir em en t s, w h ich ar e f ocu sed on w h at t h e sy st em m u st be able t o do, len d t h em selv es easily t o u se case m odelin g. Non fu n ct io n al r equ ir em en t s ar e f ocu sed on t h in gs su ch as u sabilit y an d per f or m an ce, an d ar e h ar der t o m odel u sin g u se cases.

Let ' s pu t u se case m odelin g in t o pr act ice by apply in g t h ese con cept s t o t h e Hom eDir ect sy st em case st u d y—r equ ir em en t s of w h ich ar e det ailed in

Ch a p t e r 1 6 .

To get t he m ost out of t he r em aining discussion, y ou should r ev iew t he " Hom eDirect Requirem ents " sect ion in

Ch a p t e r 1 6

bef or e con t in u in g on .

We w ill f ocu s on t h e f u n ct ion al r equ ir em en t s t o der iv e t h e u se cases.

Identifying the Actors Act or s ar e usually easier t o ident ify t han use cases. The difficult y in ident ify ing act or s is t w ofold. Fir st , it is easy t o fall int o t he t r ap of cr eat ing m ult iple act or s for t he sam e r ole. Second, act or s can be im plicit in t he r equir em ent s; t hat is, t hey m ay not be iden t if ied as u ser s of t h e sy st em ; an d t h er ef or e, y ou m u st look bey on d t h e obv iou s t o f in d t h em .

As you r ead t he descr ipt ion or gat her r equir em ent s for a pr oj ect , ask your self a few im por t ant qu est ion s: Wh o w ill u se t h is f u n ct ion alit y ? Wh o is su pply in g or obt aining infor m at ion? Who can change t he infor m at ion? Ar e t her e any ot her syst em s t hat int er act w it h t he syst em being d ev elop ed ?

As w e ex am ine t he Hom eDir ect r elat ed infor m at ion, t he follow ing t er m s qualify as r oles: cust om er , user , adm inist r at or , account holder, bank em ployee, vendor, Hom eDirect service, t he sy st em , Mail sy st em , LoansDir ect sy st em , BillsDir ect Ser v ice, and ACMEBank .

Based on t h e r equ ir em en t s an d cou pled w it h ou r com m on u n der st an din g of h ow on lin e ban k in g sy st em s t y pically w or k , it is easy t o est ablish t h at cu st om er , u ser , an d accou n t holder alm ost definit ely all r efer t o t he sam e r ole. So, w e can elim inat e t he r edundant user

an d accou n t h older . Ven dor sou n ds lik e a cu st om er , bu t is r eally m or e t h an a cu st om er because, unlik e a cust om er , it can also r eceiv e pay m ent s. Sim ilar ly , bank em ploy ee and adm inist r at or , alt hough differ ent r oles w it hin t he bank ( i. e. , a bank em ploy ee m ay not necessar ily be a Hom eDir ect adm inist r at or ) alm ost cer t ainly r efer t o t he adm inist r at or r ole.

Recall t hat act or s are out side t he syst em . Suffice it t o say t hat aft er sim ilar reasoning w it h t he r em ain in g it em s on t h e list , w e ar e left w it h a m u ch sh or t er can didat e act or list for t h e Hom eDir ect sy st em :

•

Cu st om er

•

Adm inist r at or

•

Ven d or

•

Mail sy st em

•

Loan sDir ect sy st em

•

BillsDir ect sy st em

Finding the Use Cases Use cases ar e alw ay s ex p r essed f r om t h e p er sp ect iv e of t h e act or ( t h at is, t h e u ser of t h e syst em ) . The idea is t o capt ur e a sequence of event s per for m ed by t he syst em at t he r equest of t h e act or , su ch t h at t h ey y ield some obser v able, v alu able r esu lt t o t h e act or .

Tak e a look at t he " Ho m e D i r e ct

Re q u i r e m e n t s "

sect ion in Ch a p t e r

16,

which deals with the transfer of

f u n ds. Th e f ollow in g sequ en ce of st eps descr ibes t h e t r an sf er of f u n ds:

1.

Th e cu st om er r equ est s a f u n ds t r an sf er .

2.

Th e sy st em ask s t h e u ser t o id en t if y t h e accou n t s b et w een w h ich f u n d s ar e t o b e t r an sf er r ed an d t h e t r an sf er am ou n t .

3.

Th e cu st om er select s t h e accou n t t o t r an sf er f u n ds f r om , t h e accou n t t o t r an sf er f u n ds t o, an d t h en in dicat es t h e am ou n t of f u n ds t o t r an sf er .

4.

The syst em checks t he account fr om w hich funds ar e t o be t r ansfer r ed and confirm s t h at su fficien t fu n ds ar e av ailable.

5.

Th e am ou n t is debit ed t o t h e accou n t f r om w h ich f u n ds ar e t o be t r an sf er r ed an d cr edit ed t o t h e accou n t pr ev iou sly select ed by t h e cu st om er .

Th is is essen t ially t h e m ain sequ en ce of ev en t s f or a u se case, w h ich w e w ill call " Tr ansfer f u n d s. " An alt er n at e seq u en ce of st ep s in t h is case m ay d et ail t h e st ep s p er f or m ed w h en in su fficien t fu n ds ar e av ailable.

An easy w ay t o st ar t discov er ing t he use cases is t o t ak e each act or y ou hav e ident ified and t r y t o ident ify t he b eh av ior or in for m at ion t h e act or u n der con sider at ion r equ ir es fr om t h e sy st em . Th e ch allen ge in discov er in g u se cases is t o av oid goin g t o t oo f in e a gr an u lar it y , leadin g t o a pr olif er at ion of u se cases.

Apply in g t h is m et h od t o t h e Hom eDir ect case st u dy an d u sin g t h e cu st om er act or as t h e st ar t in g poin t y ields t h e f ollow in g r aw list of can didat e u se cases: login , logou t , ch an ge passw or d, v iew account balances, list t r ansact ions, dow nload t r ansact ions, t r ansfer funds, add vendor, delet e vendor, pay bills, ch eck secur it y account balances, br ow se secur it ies, buy secur it y , and sell secur it y .

Recall t hat each use case m ust pr oduce an obser v able r esult and pr ov ide som et hing of v alue t o t h e act or ( i. e. , t h e cu st om er act or ) . Th e login an d logou t can didat e u se cases w e h a v e ident ified do pr oduce obser vable r esult s ( i.e., successful login/ logout ) , but t her e r eally is not m uch value in t hem for t he cust om er. A Hom eDirect cust om er would never j ust login or j ust logou t . Most lik ely , a cu st om er w ou ld login an d logou t in t h e con t ex t of per for m in g som e act ion , lik e pay in g bills or ch eck in g accou n t balan ces. So login an d logou t ar e n ot good can d id at es f or u se cases.

I n f act , login an d logou t f or m par t of all u se cases associat ed w it h t h e cu st om er r ole. For inst ance, in t he t r ansfer funds use case det ailed ear lier , y ou w ould fir st login, t r ansfer funds, an d t h en h av in g com plet ed t h e t r an sf er , logou t .

Th e v iew accou n t balan ces an d br ow se secu r it y accou n t su m m ar y look v er y sim ilar in t h at bot h r eally j ust show you w hat is available in specific t ypes of account s. Perhaps it would be bet t er t o abst r act t hem out as a br ow se account balances scenar io, w hich applies t o all t y pes of accou n t s equ ally w ell.

Act or s as w ell as u se cases can u t ilize t h e in h er it an ce r elat ion sh ip. So, an ot h er p ossibilit y w ould be t o cr eat e a br ow se account balances use case, and t hen hav e t w o specializat ions, one focused on t he invest m ent account s and t he ot her on t he rem aining t ypes of account s. To k eep it sim ple f or n ow , w e w ill j u st u t ilize a sin gle u se case, " Br ow se accou n t balan ces. "

Anot her set of use cases w her e som e r elat ionship lik ely ex ist s is in t he list t r ansact ions and dow nload t r ansact ions. The only r eal differ ence bet w een t he t w o is t hat in t he fir st , t he list is d isp lay ed on scr een , w h er eas t h e secon d " display s" t h e list in a file.

I t is debat able w h et h er add an d delet e v en dor sh ou ld be t w o separ at e u se cases or lu m ped int o a single use case called m odify vendor list . You can even argue t hat t hey are really part of t h e pay bills u se case. Aft er all, w ould a cust om er r eally ev er login t o t he Hom eDir ect sy st em t o j ust add a v endor ? This m ay be a case w her e fur t her clar ificat ion is needed. Som e r eal-life on lin e ban k in g sy st em s act u ally r equ ir e t h e cu st om er t o add a v en dor t o t h e list at least sev er al b u sin ess day s pr ior t o m ak in g a fir st on lin e pay m en t . I f su ch is t h e case, it is r easonable t o ex pect a cust om er t o login, add one or m or e v endor s, and t hen logout w it hout necessar ily m ak ing a bill pay m ent . For sim plicit y , w e w ill use t his as t he clar ification obt ained f r om ACMEBan k an d m odel t h e u se cases as a sin gle " Modif y v en dor list " u se case.

Th e r ef in ed list of can didat e u se cases f ollow s:

•

Ch an g e p assw or d

•

Br ow se accou n t b alan ces

•

List t r an sact ion s

•

Dow n load t r an sact ion s

•

Tr an sfer fu n ds

•

Edit pr ofile

•

Pay b ill

•

Buy secur it y

•

Sell secur it y

Th e com plet e set of u se cases f or t h e Hom eDir ect sy st em is docu m en t ed in

Ch a p t e r 1 6 .

Use Case Diagrams I n t he UML, act ors are represent ed by a st ick figur e, and use cases ar e show n as ellipses. A use case diagr am sim ply show s t he st r uct ur al r elat ionships bet w een t he act or s and t he use cases, not t he dynam ic relat ionships. The relat ionship bet w een act ors and use cases is show n v ia a dir ect ion al associat ion indicat ing t he sour ce of inv ocat ion. Fi g u r e

7-1

shows t he Browse

accou n t an d Tr an sfer fu n ds u se cases for t h e Hom eDir ect sy st em . Bot h ar e in v ok ed by t h e cust om er .

Figure 7 - 1 . A sim ple use case dia gr a m

Use Case Relationships You m ay r ecall t hat w e decided t hat login and logout do not m eet t he lit m us t est of being use cases because t hey do not provide som et hing of value t o t he cust om er. They are really part of t he v ar ious Hom eDir ect use cases, such as Br ow se account balances and Tr ansfer funds. So, w e som eh ow h av e t o r eu se t h e seq u en ce of ev en t s r eq u ir ed f or log in an d log ou t .

The UML not at ion provides " include" and " ext end" relat ionships, which can be used t o m odel su ch r eu se w it h in u se cases.

Include

An include r elat ion sh ip allow s y ou t o capt u r e a com m on piece of fu n ct ion alit y in a separ at e use case, and t hen " include" t he use case in anot her use case via t he include relat ionship. The include relat ionship is show n as a dependency relat ionship st ereot yped as < < include> > . See Fi g u r e 7 - 2 .

Figure 7 - 2 . An exam ple of an include relat ionship

Extend

An ex t end r elat ionship allow s y ou t o m odel opt ional behav ior for a use case. That is, y ou can cap t u r e som e b eh av ior in a sep ar at e u se case an d , w it h in an ot h er u se case, in d icat e t h e ex act point s ( called ext ension point s) w here t he separat e use case m ay opt ionally be invoked as par t of t he use case. An ext end relat ionship is m odeled as a dependency and st ereot yped as < < ex t end> > . See

Fi g u r e 7 - 3 .

Figure 7 - 3 . An exam ple of an ext end relat ionship

Figure 7 - 4

show s anot her, m ore det ailed use case diagr am for t he Br ow se account balances and

List t r an sact ion s u se cases f or t h e Hom eDir ect sy st em .

Figure 7 - 4 . Use ca se rela t ionships for H om eDirect

Ch a p t e r 1 6

pr ov ides a com plet e u se case m odel f or t h e Hom eDir ect case st u dy .

Ty pical pr oblem s en cou n t er ed by t h ose n ew t o u se cases r ev olv e ar ou n d t h e f ollow in g:

•

Cr eat ing use cases t hat ar e t oo coar se-gr ained. For inst ance, " Pr ocess or der " m ay be t oo coar se if it r epr esen t s " Cr eat e n ew or der , " " Su bm it or der , " an d " Ch an ge o rder" f r om t h e u ser ' s per spect iv e.

•

Cr eat in g u se cases t h at ar e t oo f in e-gr ain ed. Con t in u in g w it h t h e pr ecedin g or der ex am ple, " Ch an ge zip code f or or der , " m igh t be an ex am ple of a f in e-g r ain ed u se case.

•

Writ ing t he use cases from a syst em perspect ive. For exam ple, " Obt ain cat alog from d at ab ase" v er su s " Br ow se cat alog . "

•

Get t ing bogged dow n in ex t end v er sus include r elat ionships. An ex t end r elat ionship can easily b e ex p r essed as an in clu d e r elat ion sh ip , so ch oose on e, an d m ov e on .

•

Get t ing car r ied aw ay w it h us e case and act or gener alizat ions. Neit her is essent ial, at least n ot in it ially . Keep in m in d t h at y ou can alw ay s add an act or or u se case gener alizat ion lat er in a subsequent it er at ion once you under st and t he det ails bet t er .

Sequence Diagrams A use case is st ill very m uch a t ext ual descript ion and is subj ect t o int erpre t at ion. A sequence diagr am is u sed t o ex pr ess t h e u se case in m or e pr ecise, t ech n ical t er m in ology . Th is is achiev ed by depict ing t he use case in t er m s of int er act ion bet w een t he act or and t he syst em .

A sequence diagr am is a t y pe of int er act ion diagr am in t he UML. The ot her k ind of int er act ion diagr am is called a collaboration diagr am . Sequence diagr am s capt ur e a specific scenar io, w it h a use case t y pically consist ing of one or m or e scenar ios ( for exam ple, m ain w or kflow and alt er n at e w or k f low s) . Th e em ph asis in a sequ en ce diagr am is on t h e t im e or der in g of t h e in t er act ion . Th u s, t h e v er t ical ax is r epr esen t s t h e t im e dim en sion in a sequ en ce diagr am .

A sequence diagr am ut ilizes t he descr ipt ion of a use case. Figure 7 - 5 show s a sequence diagram for t h e Tr an sfer fu n ds u se case discu ssed ear lier . To cr eat e a sequ en ce diagr am , each st ep from t he t ext ual descript ion for t he use case is placed o n t he left side. Two vert ical lines are u sed t o sh ow t h e lif elin e of t h e act or an d t h e sy st em . Th e act or is r epr esen t ed by t h e act or st ick figu r e sy m bol, an d t h e sy st em is sim ply sh ow n as a r ect an gle.

Figure 7 - 5 . Transfer funds sequence diagram

The int er act ions bet w een t he act or and t he sy st em ar e show n as ar r ow s, w it h t he dir ect ion of t he arrow indicat ing t he direct ion of int eract ion. Specifi cally, a request from t he act or t o t he sy st em is sh ow n as an ar r ow fr om t h e lifelin e of t h e act or t o t h e lifelin e of t h e sy st em , w it h t h e ar r ow poin t in g t o t h e sy st em life line. A r esponse fr om t he sy st em t o t he act or is show n w it h an ar r ow dr aw n f r om t h e sy st em lif elin e t o t h e act or lif elin e an d poin t s t o t h e act or .

The first arrow labeled " select account s" rout es back t o t he cust om er lifeline, indicat ing t hat t h e cu st om er per f or m s accou n t select ion at t h e st ar t of t h e scen ar io. Th is is f ollow ed by a f u n ds t r an sf er r equ est f r om t h e cu st om er t o t h e sy st em , an d so on .

Sequence diagram s sim ply show t he dynam ic int eract ion am ong part icipant s in t he scenario an d d o n ot sh ow t h e s t r uct ur al r elat ionship bet w een t hem . I f a use case has sev er al flow s, sev er al seq u en ce d iag r am s m ay b e r eq u ir ed t o cap t u r e all asp ect s of t h e u se case.

Th e qu est ion of t en com es u p as t o h ow com plet e t h e sequ en ce diagr am s sh ou ld be. I n t h is early phase of r equir em ent s' capt ur e and analysis, t he sequence diagr am s, by necessit y, ar e r elat iv ely sim ple an d m ay be in com plet e. Th is ch an ges as y ou pr ogr ess t h r ou gh u se case analysis and refine t hese sequence diagram s wit h furt her det ails. I t is useful t o have t he m a in flow of each use case capt ur ed as a sequence diagr am ; how ev er , capt ur ing each and ev er y

alt ernat e flow , especially w hen t here m ay be a large num ber of t hem , is not necessary. The m ain idea is t o capt u r e en ou gh of t h em t o h av e con f iden ce t h at y ou h av e su fficient in f or m at ion f or t h e n ex t ph ase of t h e pr oj ect .

Activity Diagrams An alt er n at e, an d som e w ou ld ar gu e a m or e pow er f u l, t ool in t h e UML ar sen al f or su ch u se case analy sis is t he UML act iv it y diagr am . For inst ance, act iv it y diagr am s can m or e easily show m ult iple pat hs t aken as a r esult of act or decision and syst em except ions. This is difficult t o sh ow in a seq u en ce d iag r am as seq u en ce d iag r am s ar e in t en d ed t o sh ow in t er act ion am on g obj ect s in t h e con t ex t of a sin gle scen ar io.

An act ivit y diagram is sim ilar in concept t o a flow char t and is useful for m odeling w or k flow as w ell as illu st r at in g dy n am ic beh av ior of a u se case an d t h e det ailed design of an oper at ion .

An act ivit y diagr am show s t he flow of cont r ol for t he use case fr om one act ivit y t o t he nex t . An act iv it y r epr esent s som e act ion t hat t ak es place dur ing t he ex ecut ion of t he use case. This t y pically m aps t o som e w or k t h at h as t o be don e as par t of t h e w or k f low or ex ecu t ion of an oper at ion in t h e con t ex t of a class.

Act iv it ies ar e r epr esen t ed by a r ou n d-en ded r ect an gle. An act iv it y m ay be decom posed fu r t h er in t o ot h er act iv it ies, r epr esen t ed on an ot h er act iv it y diagr am .

On ce an act iv it y h as com plet ed, ex ecu t ion m ov es t o t h e n ex t st at e as det er m in ed by t h e av ailable t r ansit ions on t he act iv it y . Act iv it y diagr am s also su ppor t decision poin t s. I n addit ion, it is possible t o show par allel w or k r equir ed as par t of an act iv it y diagr am by using t h e con cept of sy n ch r on izat ion bar s.

A sim ple act iv it y diagr am r epr esent ing t he act of placing a phone call is show n in Fi g u r e

7-6.

Figure 7 - 6 . A sim ple a ct ivit y dia gra m

Swim lanes can be used t o show m ult iple obj ect s on an act iv it y diagr am and how t hey w or k t oget h er t o f u lf ill t h e ov er all u se case.

Figure 7 - 7

shows an act ivit y diagram for t he Transfer funds scenario. The vert ical lines indicat e

t he boundar y for t he act or s w it hin t he sy st em . This is an init ial act iv it y diagr am and does not sh ow all t h e det ails, su ch as con dit ion al act iv it y , an d so on .

Figure 7 - 7 . Act ivit y diagram for t he t ransfer funds scenario

Summary Properly capt uring requirem ent s is essent ial t o a syst em 's success and it s long -t erm viabilit y. I n t h e UML, u se case m odelin g offer s a sim ple y et pow er fu l m ean s of capt u r in g y ou r r equ ir em en t s.

I n t he use case m odel, act ors are t he prim ary inst igat ors of use cases and represent ent it ies out side t he syst em . Use cases can be t hought of as a sequence of st eps required t o achieve som et hing useful t o an act or . That is, a use case m ust y ield som et hing useful t o t he end user of t he use case. Sequence diagr ams and act iv it y diagr am s ar e useful for pr ecisely ident ify ing an d u n d er st an d in g t h e b eh av ior of a u se case.

Chapter 8. Creating the Design •

U s e Ca s e A n a l y s i s

•

Us e Ca s e Re a l i z a t i o n s

•

Re f i n e d Us e Ca s e D e s c r i p t i o n

•

Se q u e n ce D i a g r a m s

•

Co l l a b o r a t i o n D i a g r a m s

•

Cl a s s D i a g r a m s

•

Co a l e s c i n g t h e A n a l y s i s Cl a s s e s

•

Pa ck a g i n g

•

Su m m ar y

Pr oce ss Ch e ck : I n t h is ch a pt e r , w e focu s on a n a lysis a s w e progress t hrou gh t h e Ra t ion a l Un ifie d Pr oce ss ( RUP) a n a lysis a n d design discipline.

Once you have capt ured t he use cases, you should t hen analyze t hem furt her and begin t he process of t ransform ing requirem ent s int o syst em design. This involves developing a bet t er underst anding of t he det ails of a use case via a refinem ent of t he use case.

I n t his chapt er , w e discuss how t o go fr om use cases t o t he init ial design of t he syst em .

Use Case Analysis The init ial ex plor at ion of t he int er nal w or k ings of t he sy st em is called Use Case Analy sis. Use Case An aly sis pr ov ides an in it ial, h igh -lev el defin it ion of h ow in t er n al elem en t s in t er act in or der t o sat isf y t h e sy st em ' s f u n ct ion al r equ ir em en t s, an d h ow t h ey r elat e t o each ot h er st at ically . This act iv it y can inv olv e m uch t r ial and er r or bef or e sat isf act or y solu t ion s ar e cr eat ed. For t h is r eason , t im e sh ou ld n ot be spen t cr eat in g r ef in ed descr ipt ion s of in t er n al elem ent s. " Analysis classes," for w hich behaviors are oft en described abst ract ly using nat ural language, suffice. Analysis classes ar e not im plem ent ed in soft w ar e. Rat her , analysis classes ar e r ef in ed lat er in t h e ov er all design pr ocess in t o pr ecisely def in ed design classes an d su b sy st em s.

Use Case Realizations

Thus far, our focus has been on capt uring t he requirem ent s and m aking sure w e underst and w hat w e need t o build. Ev er y t hing w e hav e done is gener ic in t hat no consider at ion has been giv en t o h ow w e w ill act u ally design or im plem en t ou r solu t ion .

Th e sam e set of fu n ct ion al r equ ir em en t s can lead t o v ast ly differ en t sy st em s t h at ar e funct ionally equiv alent but ar e t ot ally differ ent in t he w ay t hey solv e specific pr oblem s. For ex am ple, t he online bank ing sy st em could be offer ed t o t he cust om er base as t w o differ ent pr odu ct s: an applicat ion t h at act u ally dials in t o t h e ban k in g sy st em or a Web -b a sed applicat ion t hat uses t he I nt ernet ( perhaps t he bank w ant s t o m arket t he direct dial version as a m or e u pscale an d secu r e v er sion ) . Th e fu n ct ion al r equ ir em en t s ar e t h e sam e, bu t t h e im plem en t at ion s ar e v ast ly dif f er en t f or t h e t w o solu t ion s.

Use case r ealizat ion s can be u sed t o car r y for t h t h e design of m u lt iple im plem en t at ion s for t he sam e set of r equir em ent s. They allow t he sam e use case t o be im plem ent ed in differ ent ways while m aint aining a link wit h t he original requirem ent s. Use case realizat ions t herefore offer a concret e link t hrough which you can t race back t o t he original requirem ent for all t he differ en t m odels t h at m igh t ex ist for a giv en set of r equ ir em en t s.

We r epr esent use case r ealizat ions gr aphically using a dot t ed -line ellipse. A Unified Modeling Language ( UML) " realize" relat ionship is draw n bet w een t he realizat ion and it s use case. Figure 8-1

sh ow s a u se case r ealizat ion f or a Tr an sf er f u n d s u se case.

Figure 8 - 1 . Use ca se rea liza t ion for Tra nsfer funds

Each use case r ealizat ion can hav e obj ect int er act ion diagr am s and class diagr am s associat ed w it h it . Each obj ect in t er act ion diagr am w e dev elop du r in g Use Case An aly sis sh ow s t h e int er act ions bet w een act or s and inst ances of analy sis classes t hat ar e needed t o suppor t one flow of ev ent s t hr ough a use case. The class diagram s illust rat e t he st at ic st ruct ural relat ions b et w een t h ese in t er n al sy st em elem en t s.

Refined Use Case Description Th e Use Case An aly sis pr ocess is of t en j u m p -st ar t ed by t ak in g t h e cu st om er-con su m able " black box " u se case t ex t u al descr ipt ion s a nd adding " gr ay box " det ails t hat r ev eal som e of t h e sy st em ' s in t er n al pr ocessin g act iv it ies. Th e black box u se case descr ipt ion m igh t be sufficient from a cust om er perspect ive, but it cert ainly is not a sufficient level of det ail t o allow dev eloper s t o im plem en t t h e sy st em .

As an exam ple, consider t he Transfer funds use case t hat w as out lined in t he previous chapt er. Alt h ou gh t h e u se case is accu r at e in t h at it cov er s t h e in t er act ion t h at t ak es place, som e det ails ar e m issin g. For ex am ple, h ow does t h e cu st om er ch oose t h e accou n t ? Does t h e syst em provide a list of account s? When t he cust om er indicat es t he am ount of funds, does it have t o be a w hole num ber or can it be in decim al for m at ? How does t he syst em ver ify t hat t h e accou n t f r om w h ich f u n ds ar e t o be t r an sf er r ed h as su f f icien t f u n ds? Th ese k in ds of q u est ion s f acilit at e r ef in em en t of t h e u se cases d u r in g t h e Use Case An aly sis p h ase.

Th e f ollow in g seq u en ce of ev en t s p r ov id es a m or e elab or at e v er sion of t h is u se case:

1.

Th e cu st om er select s t h e t r an sf er oper at ion .

2.

Th e accou n t in f or m at ion is sen t ov er t h e I n t er n et t o t h e sy st em .

3.

Th e sy st em r et r iev es t h e cu st om er ' s pr ofile.

4.

The sy st em builds a list of account s fr om t he cust om er 's pr ofile and pr ov ides specific det ails about each account , such as t he cur r ent balance, overdraft lim it , and any fees t h at m igh t apply t o t h e t r an sfer fu n ds act ion . Th is in for m at ion is display ed t o t h e cust om er .

5.

Th e cu st om er select s t h e accou n t s t o t r an sf er f u n d s b et w een an d t h e am ou n t t o t ransfer. Transfer am ount s are allowed in any a m ount specified in dollar s and cent s.

6.

Th e sy st em v er if ies t h at t h e am ou n t en t er ed f or t h e t r an sf er is n u m er ical an d is a v alid am ount .

7.

Th e sy st em pr om pt s t h e cu st om er for con fir m at ion pr ior t o pr oceedin g w it h t h e t r an sact ion .

8.

Upon confir m at ion, t he sy st em begin s t h e t r an sf er f u n ds t r an sact ion .

9.

The syst em ret rieves t he current balance for t he account from which funds are t o be t r an sf er r ed.

1 0 . Th e sy st em su bt r act s t h e t ot al am ou n t of t r an sfer fr om t h e accou n t balan ce, alon g w it h any applicable fees, t o confir m t h at su fficien t fu n ds ar e av ailable.

1 1 . Th e am ou n t is debit ed t o t h e accou n t f r om w h ich f u n ds ar e t o be t r an sf er r ed an d cr edit ed t o t h e accou n t t o w h ich f u n ds ar e bein g t r an sf er r ed. 1 2 . The syst em logs t he t r ansfer in t he daily t r ansact ions r egist er and obt ains a reference ident ificat ion num ber . 1 3 . Th e sy st em pr ov ides t h e r efer en ce n u m ber t o t h e cu st om er , con fir m in g t h at t h e t r an sf er h as t ak en p lace.

A m or e d et ailed seq u en ce d iag r am f or t h e u p d at ed u se case is sh ow n in

Fi g u r e 8 - 2 .

Figure 8 - 2 . Sequence diagram for t he revised t ransfer funds use case

Sequence Diagrams On ce g r ay-box det ails hav e been added t o t he t ex t ual use case descr ipt ion, m or e elabor at e sequence diagram s can be creat ed t o reveal t he int ernal work ings of t he syst em . I nst ead of sh ow in g t h e in t er act ion bet w een act or s an d a m on olit h ic sy st em , t h e sy st em is split in t o analysis level obj ect s. The r esponsibilit ies of t he syst em ar e divided am ong t he analysis level obj ect s t o ach iev e a f in er gr ain ed sequ en ce diagr am .

Ther e ar e t hr ee k inds of analysis obj ect s, and each plays a specific r ole in t he r efined m odel of t h e sy st em .

Boundary Objects

As t he nam e suggest s, boundary obj ect s exist at t he periphery of t he syst em . They are on t he f r on t lin e, in t er act in g w it h t h e ou t side w or ld.

I n t he refined m o del, boundar y obj ect s r epr esent all int er act ions bet w een t he sy st em 's inner w or k in gs an d it s su r r ou n din gs. Th ese in clu de in t er act ion w it h a u ser v ia a gr aph ical u ser in t er f ace, in t er act ion s w it h ot h er act or s ( su ch as t h ose r epr esen t in g ot h er sy st em s) , com m u n icat ion s w it h dev ices, an d so on . An ex am ple of a bou n dar y obj ect in t h e on lin e ban k in g ex am ple w ou ld be t h e u ser in t er f ace f or t h e logon scen ar io.

One of t he advant ages of using boundar y obj ect s is t hat t hey ser ve t o isolat e and shield t he r est of t h e s y st em fr om ex t er nal concer ns.

Boundary obj ect s are ident ified via t he < < boundary> > st ereot ype. Alt ernat ely, a circle wit h a per pen dicu lar T can be u sed as t h e icon r epr esen t at ion of a bou n dar y obj ect . Bou n dar y obj ect s are t ransit ional in nat ure and usually, t hough not always, only last for t he lifet im e of a u se case. Gen er ally speak in g, each act or-u se case in t er act ion pair m aps t o a bou n dar y obj ect . Th is is sh ow n in

Fi g u r e 8 - 3 .

Figure 8 - 3 . Each use ca se - act or relat ionship is a pot ent ial boundary obj ect

Entity Objects

Ent it y obj ect s represent inform at ion of significance t o t he syst em . They ar e usually per sist ent an d ex ist f or an ex t en ded du r at ion . Th eir pr im ar y pu r pose is t o r epr esen t an d m an age infor m at ion w it hin t he sy st em .

Key con cept s w it h in a sy st em m an ifest t h em selv es as en t it y obj ect s in t h e m odel. For ex am ple, in t h e on lin e ban k in g case st u dy , in for m at ion abou t t h e cu st om er , t h e accou n t s, an d so on w ou ld b e su it ab le f or m od elin g as en t it y ob j ect s.

Ent it y obj ect s ar e st er eot y ped as < < ent it y > > or show n as a cir cle w it h a t angent ial line at t he bot t om of t he cir cle. En t it y obj ect s u su ally span m u lt iple u se cases an d m igh t ev en ex ist beyond t he exist ence of t he syst em it self. I nfor m at ion needs var y r adically bet w een syst em s, an d so do t h e n u m ber of en t it y obj ect s in a u se case or a sy st em .

See

Fi g u r e 8 - 4

f or an ex am ple of a u se case t o en t it y m appin g.

Figure 8 - 4 . Ent it y obj ect s and use cases

Control Objects

Con t r ol obj ect s ar e u sed t o m odel beh av ior w it h in t h e sy st em . Con t r ol obj ect s do n ot necessarily im plem ent t he behavior , but m ay inst ead w or k w it h ot her obj ect s t o achieve t he b eh av ior of t h e u se case.

Th e idea is t o separ at e t h e beh av ior f r om t h e u n der ly in g in f or m at ion associat ed w it h t h e m odel, m ak in g it easier t o deal in depen den t ly w it h ch an ges in eit h er la t er on .

Cont r ol obj ect s ar e usually t r ansient in nat ur e and cease t o ex ist once t he use case has been com plet ed. They ar e ident ified v ia t he < < cont r ol> > st er eot y pe or as a cir cle w it h an ar r ow icon.

An ex am ple of a cont r ol obj ect w it hin t he sy st em m ay be a n obj ect t hat coor dinat es secur e access t o t he online banking syst em . Ther e m ay be one or m or e cont r ol obj ect s per use case. Th e m appin g is sh ow n in

Fi g u r e 8 - 5 .

Figure 8 - 5 . Cont rol obj ect and use ca se

Fi g u r e 8 - 6

sh ow s a com p osit e v iew of t h e Tr an sf er f u n d s u se case an d t h e an aly sis ob j ect s

ident ified for t he use case t hus far . Not e t he iconic r epr esent at ion of t he boundar y , cont r ol, an d en t it y obj ect s.

Figure 8 - 6 . Transfer funds use case and associat ed ana lysis obj ect s

An updat ed version of t he sequence diagram for t he Transfer fu nds use case, t his t im e w it h t h e sy st em decom posed in t o an aly sis obj ect s, is sh ow n in

Fi g u r e 8 - 7 .

Figure 8 - 7 . Refined sequence diagram for t he t ransfer funds scenario

Th er e ar e a f ew t h in g s t o n ot e in t h e r ef in ed seq u en ce d iag r am sh ow n in Fi g u r e com par e it t o

Fi g u r e 8 - 2

8-7.

I f you

at t h e begin n in g of t h e ch apt er , t h e ov er all scope or det ail of t h e

sequ en ce diagr am h as n ot ch an ged. I n st ead, dif f e r en t p ieces of t h e sy st em ar e n ow collect ively responsible for t he sam e set of responsibilit ies. For inst ance, t he int eract ion wit h t h e cu st om er is t h e r espon sibilit y of t h e Tr an sf er Page [ 1 ] bou n dar y obj ect . Th e bou n dar y obj ect in t ur n int er act s w it h a cont r oller t hat coor dinat es t he act iv it ies w it hin t he use case. Several ent it y obj ect s are involved in fulfilling t he use case. I t should be not ed t hat a separat e sequence diagr am , per haps involving inter act ions bet w een a differ ent set of obj ect s, should be creat ed for each significant com plet e pat h ( flow of event s) t hat can be t aken t hrough t he use case. These pat hs, or scenar ios, m ight be gener at ed as t he act or s dev iat e fr om t he m ost ex pect ed beh av ior or if ex cept ional condit ions occur w it hin t he sy st em . The collect ion of

t hese sequence diagr am s can be par t of t he sam e use case r ealizat ion. They collect ively show t h e possible in t er n al in t er act ion s t h at can occu r as t h e u se case is per f or m ed. [ 1]

Th e t erm " page" is used gener ically in t his cont ex t . This m ay m anifest it self as an HTML

page, a clien t dialog, an d so on at a lat er t im e.

Collaboration Diagrams Collabor at ion diagr am s ar e t h e ot h er t y pe of obj ect in t er act ion diagr am in UML. Un lik e sequence diagram s, w hich are focused on t he t im e ordering of t he int eract ion, collaborat ion diagr am em ph asis is on sh ow in g t h e r elat ion sh ips an d com m u n icat ion lin k s am on g t h e part icipant s. Collaborat ion diagram s provide a bet t er pict ure of t he overall int eract ions for a giv en class.

Sequence diagram s allow you t o convey som e inform at ion, for exam ple, t im ing inform at ion, w h ich can n ot be con v ey ed v ia collabor at ion diagr am s. Collabor at ion diagr am s also t en d t o becom e dif f icu lt t o com pr eh en d on ce y ou ex ceed a f ew obj ect s on t h e d iag r am , w h er eas sequence diagr am s hav e pr ov en t o be capable of handling scenar ios inv olv ing a lar ge num ber of obj ect s.

Th e pr ecedin g cav eat s aside, for all pr act ical pu r poses, t h e dist in ct ion is r eally on e of preference. I t is relat ively st raight forw a r d t o der ive a sequence diagr am fr om a collabor at ion diagr am an d v ice v er sa.

Fi g u r e 8 - 8

sh ow s a collabor at ion diagr am v er sion of t h e sequ en ce diagr am f or t h e Tr an sf er

f u n d s u se case sh ow n in

Fi g u r e 8 - 7 .

Figure 8 - 8 . Transfer funds collaborat ion diagram

Class Diagrams Th u s f ar , w e h av e f ocu sed on iden t if y in g t h e an aly sis classes t h at par t icipat e in a u se case an d dist r ibu t in g t h e r espon sibilit ies of t h e u se case t o t he ident ified classes. This has been done in t he cont ext of int er act ion diagr am s, w hich pr im ar ily capt ur e t he dynam ic behavior of a u se case.

Classes oft en par t icipat e in sev er al use cases, and it is equally im por t ant t o under st and t heir st at ic r elat ion sh ips t o en su r e con sist en cy acr oss t h e sy st em .

We now t ur n our at t ent ion t o t his aspect by defining t he classes and t heir r elat ionships m or e precisely based on t he Use Case Analysis work done t hus far. We use t he Transfer funds use case as a m ean s t o illu st r at e t h ese st at ic r elat ion sh ip s.

Th e UML class diagr am is u sef u l f or capt u r in g t h e st at ic r elat ion sh ips bet w een dif f er en t st r uct ur al elem ent s. A single class diagr am , r efer r ed t o as t he View of Par t icipat ing Classes ( VOPC) diagr am , is cr eat ed for each use case. Th e pu r pose of t h e VOPC diagr am is t o illu st r at e in a sin gle diagr am all aspect s of t h e sy st em ar ch it ect u r e t h at ar e ex er cised by a specif ic u se case.

All in t er act ion diagr am s cr eat ed f or t h e u se case r ealizat ion ar e ex am in ed f or classes, oper at ion s, r elat ion s, an d so on t o b e in clu d ed on t h e VOPC.

As a fir st st ep, w e ident ify and place all t he classes t hat par t icipat e in t he use case on a class diagram . Because we have already dist ribut ed t he behavior of t he use case t o t he classes, it is a relat ively sim ple ex er cise t o cr eat e analysis operat ions for t he responsibilit ies assigned t o t h e class. Each an aly sis oper at ion m aps t o on e of t h e sy st em r espon sibilit ies bor n e by t h e an aly sis class. Th at is, t h er e is a on e-t o-on e m ap p in g b et w een each u n iq u e m essag e in an analy sis -lev el in t er act ion diagr am an d an an aly sis oper at ion .

I t is im por t ant t o not e t hat t hese ar e analy sis oper at ions, m eaning t hat t hese oper at ions w ill m ost lik ely n eed t o ev olv e as w e con t in u e w it h ou r an aly sis an d design ef f or t s.

Fi g u r e 8 - 9

sh ow s t h e Tr an sf er Fu n ds con t r ol class w it h an aly sis oper at ion s r epr esen t in g t h e

r esp on sib ilit ies assig n ed t o t h e class.

Figure 8 - 9 . TransferFunds cont rol class w it h analysis operat ions

An ot h er aspect of flesh in g ou t each in div idu al class is t o iden t ify at t r ibu t es f or t h e class. At t r ibut es r epr esent infor m at ion t hat m ay be r equest ed of t he class by ot her s or t hat m ay be r equir ed by t he class it self t o fulfill it s r esponsibilit ies.

At t r ibu t es ar e of t en iden t if ied v ia r equ ir em en t s t h r ou gh k n ow ledge of t h e dom ain an d t h r ou gh an u n der st an din g of t h e in for m at ion t h at is r equ ir ed t o fu lfill t h e r espon sibilit ies.

At t his st age in t he analysis, it is appropriat e t o ident ify at t ribut es as generic t ypes, such as n u m ber , st r in g, an d so on . Th e ex act t y pe can be sor t ed ou t at a lat er t im e as dict at ed by im plem ent at ion par am et er s. class.

Fi g u r e 8 - 1 0

shows t he at t ribut es for t he cust om er Profile analysis

Figure 8 - 1 0 . Cust om er Profile ent it y class w it h at t ribut es

Keep in m in d t h at in for m at ion m odeled as at t r ibu t es sh ou ld r equ ir e on ly r elat iv ely sim ple behav ior , such as get or set oper at ions. I f t his is not t he case or if t w o or m or e classes shar e t h e in f or m at ion , it is bet t er t o m odel t h at in f or m at ion as a separ at e class.

We com plet e t he class diagram for t he use case by ident ifying t he r elat ionships bet w een t he classes. Th e r elat ion sh ips w e ar e specif ically in t er est ed in ar e associat ion an d in h er it an ce ( see

Ch a p t e r 3

f or a discu ssion on associat ion an d aggr e gat ion) .

A good st art ing point for ident ifying such relat ionships is t he collaborat ion diagram . I f t here are links bet w een classes on a collaborat ion diagram , a need for com m unicat ion exist s, so a r elat ion sh ip is w ar r an t ed.

The direct ion of com m unicat ion s hould also be ident ified. This m ay be unidirect ional such t hat an in st an ce of class A can sen d a m essage t o class B bu t n ot v ice v er sa, or bidir ect ion al, m ean in g t h at eit h er can sen d a m essage t o t h e ot h er par t y in t h e r elat ion sh ip. Each r elat ionship should also be analyzed for m ult iplicit y. For exam ple, if up t o four inst ances of a

class can par t icipat e in an associat ion , t h at en d of t h e associat ion sh ou ld be iden t ified w it h t he m ult iplicit y of 0..4.

I t is alw ays t em pt ing t o add addit ional r elat ionships t o t he class diagram because you believe t hey ar e r equir ed or m ay be r equir ed dow n t he r oad. Just r em em ber t hat t his analy sis is use case dr iv en and unless it is par t of t he use case, it w ould not m ak e sense t o add r elat ionships.

Fi g u r e 8 - 1 1

sh ow s t h e Tr an sf er Fu n d s u se case class d iag r am .

Figure 8 - 1 1 . Tra nsferFunds use ca se cla ss dia gra m

Som e n ot es abou t t h e class diagr am f or t h e Tr an sf er Fu n ds scen ar io: Fir st , n ot e t h at t h e con t r oller does n ot n eed t o k eep r ef er en ces t o t h e cu st om er Pr of ile an d t h e Tr an sact ion sRegist er for r epeat ed access. I nst ead, t hese ar e r et r iev ed each t im e based on t h e cu st om er in v olv ed an d u pon com plet ion of t h e t r an sact ion it self. As su ch , t h ese r elat ion sh ips ar e capt u r ed as depen den cies in st ead of associat ion s. Secon d, in a t r an sf er funds s cenario, t here are t w o account s involved ( from , t o) . This involvem ent of t w o account s ( as opposed t o a sim ple accou n t ) is capt u r ed v ia a m u lt iplicit y of t w o for t h e Tr an sfer Fu n d con t r ol class an d t h e Accou n t en t it y class.

Coalescing the Analysis Classes

Ha ving analyzed all t he use cases and having creat ed t he class diagram s for each use case, it is t im e t o m er ge t he v ar ious analy sis classes t o ar r iv e at a unified analy sis m odel. This is an im por t an t act iv it y , as w e w an t t o ar r iv e at a m in im al set of classes an d av oid u n n ecessar y r edundancy in t he final analy sis m odel.

The key t ask at t his st age revolves around ident ifying classes t hat m ay be duplicat ed across use cases or m asquerading in slight variat ions. For exam ple, cont rol classes t hat have sim ilar b eh a vior or r epr esent t he sam e concept acr oss use cases should be m er ged. Ent it y classes t h at h av e t h e sam e at t r ibu t es sh ou ld also be m er ged, an d t h eir beh av ior com bin ed in t o a sin gle class.

Figure 8 - 1 2

shows t he prelim inary analysis m odel for t he Hom eDirect case st udy aft er an init ial

m er ge of t he m aj or use cases. Not e t he consolidat ion of t he v ar ious cont r ol classes ident ified f or sev er al in div idu al u se cases in t o t h r ee con t r ol classes. Th e r ev ised con t rol classes were ar r iv ed at by m er ging cont r ol classes for closely r elat ed use cases ( e. g. , login, bills, et c. ) .

Figure 8 - 1 2 . Class diagram represent ing a prelim inary version of t he m erged analysis m odel

At t his st age, t hings ar e st ill in flux as som e det ails r em ain t o be r esolv ed. I t is not uncomm on t o go t hr ough som e r eflect ion and w alk t hr oughs t o ar r iv e at an analy sis m odel t hat ev er y one is com for t able w it h.

For m or e det ails of specif ic scen ar ios an d r elat ed issu es, see

Ch a p t e r 1 6 .

Packaging I n t h e r elat iv ely sim ple Hom eDir ect on lin e ban k in g case st u dy u sed in t h is book , w e h av e ident ified about a dozen use cases. Each use case has in t urn result ed in t wo, t hree, or m ore analysis classes, w hich easily adds up t o 30+ classes j ust in t he ver y fir st it er at ion. Clear ly, as w e delv e deeper in t o t h e design an d im plem en t at ion , t h is n u m ber w ill lik ely in cr ease.

Fu r t h er m or e, as pr oj ect s m ov e t o design an d im plem en t at ion , t h e t eam gr ow s, an d it becom es n ecessar y t o m ak e ar r an gem e nt s so t hat w or k can be allot t ed, and ev er y one can w or k sim ult aneously .

Th is is w h er e pack agin g com es in . I t allow s y ou t o m an age com plex it y by gr ou pin g like classes or relat ed classes in t o sep ar at e p ack ag es.

The ar gum ent for placing lik e classes in a pack age is t h at of con v en ien ce. You can easily locat e all t h e classes t h at ar e sim ilar in con cept or pu r pose. I f y ou w er e t o gr ou p all y ou r cont r ol classes in a pack age, for ex am ple, y ou w ould be using t he fir st appr oach -grouping by lik eness or sim ilar it y .

Gro u p in g r elat ed classes h as t h e ad v an t ag e of t h e p ack ag es b ein g som ew h at m or e self-cont ained. I f a t eam is r esponsible for deliver ing a specific set of funct ionalit y, t hey could dev elop, t est , an d deliv er t h e pack age f air ly in depen den t ly .

I n t he UML, t he folder icon represent s a package. A package can cont ain m odel elem ent s such as classes an d in t er f aces. Pack ag es can also b e n est ed .

One of t he k ey challenges in lar ge and com plex pr oj ect s is t o under st and t he dependencies bet w een t he var ious pieces of soft w are. A dependency exist s bet ween packages if class X in package A depends on a class Y in package B. Thus, a change in class Y can pot ent ially have a r ipple ef f ect on class X an d an y ot h er classes t h at depen d on it .

The r ole of pack aging becom es m or e im por t a n t as t h e size an d com plex it y of t h e pr oj ect in cr eases becau se ev en t h e sm allest r ipple can h av e a dr am at ic ef f ect w h en m u lt iplied.

Pack age depen den cy is sh ow n on a diagr am by dr aw in g a dash ed ar r ow f r om t h e pack age t hat has t he dependency t o t he package it has t he dependency on. I t is a good idea t o adopt a convent ion of draw ing all dependency arrow s in t he sam e direct ion ( e.g., t op t o bot t om , left t o r igh t , et c. ) . Th is m ak es it easier t o u n der st an d t h e ch ain of depen den cies.

Figure 8 - 13

show s a sim ple diagr am inv olv ing pack ages. The appr oach t ak en is t hat of gr ouping

lik e classes in pack ages.

Figure 8 - 1 3 . Pa ck a ge de pe nde ncy

Th e pack age depen den cy diagr am s f or t h e Hom eDir ect case st u dy ar e sh ow n in Ch a p t e r

Summary

1 6.

Use Case Analysis provides an init ial, high -level definit ion of how int ernal elem ent s int eract in or der t o sat isf y t h e sy st em ' s f u n ct ion al r equ ir em en t s an d h ow t h ey r elat e t o each ot h er st at ically . This is a fundam ent al act iv it y on t h e w ay t o d esig n an d d ev elop m en t .

Use Case An aly sis is su ppor t ed v ia sequ en ce diagr am s. I n st ead of sh ow in g t h e in t er act ion bet w een act or s and a m onolit hic sy st em , t he sy st em is split int o analy sis lev el obj ect s. The responsibilit ies of t he syst em are divided am ong t he analysis level obj ect s, w hich ar e r efer r ed t o as bou n dar y , con t r ol, an d en t it y obj ect s, t o ach iev e a f in er gr ain ed sequ en ce diagr am . Collabor at ion diagr am s ar e an ot h er aid in su ch an aly sis.

On ce t h e dy n am ic beh av ior h as been capt u r ed in t h e f or m of sequ en ce diagr am s an d collabor at ion diagr am s, class diagr am s can be dev eloped t o capt ur e t he st at ic r elat ionships bet w een t h e v ar iou s elem en t s par t icipat in g in f u lf illin g t h e u se case.

Packaging pr ovides a convenient m echanism for m anaging com plexit y and allot m ent of t eam effor t . An ot h er cr it ical aspect w h er e pack agin g can be lev er aged deals w it h u n der st an din g t h e im pact of ch an ges in t h e pr oj ect v ia depen den cy an aly sis.

Chapter 9. Overview of J2EE Technologies •

Th e Bi g Pi ct u r e

•

Ser v l et s

•

Ja v a S e r v e r Pa g e s ( JS P)

•

En t e r p r i se Ja v a Be a n s ( EJB)

•

Se ssi o n Be a n s

•

En t i t y Be a n s

•

M e s s a g e - D r i v e n Be a n s

•

Asse m b l y a n d D e p l o y m e n t

•

Ca s e S t u d y

•

Su m m ar y

Up t o t his point , we have focused on t he Unified Modeling Language ( UML) and analysis wit hout giving m uch t hought t o t he design det ails of t hese Java 2 Plat form , Ent erprise Edit ion ( J2EE) t echnology com ponent s. Ov er t he nex t few chapt er s, w e'll sw it ch gear s and m ov e t he discussion t o a m ore det ailed level t o discuss each of t he m aj or J2EE com ponent t ypes, highlight ing t he different roles t he UML plays in dealing wit h t hem .

I n t his shor t chapt er , w e out line how t he different J2EE t echnologies fit t oget her, and t hen highlight t he cont ent s of t he rem aining chapt ers. This will allow you t o develop a bet t er underst anding of t he big pict ure and give you t he opport unit y t o focus your at t ent ion only on t hos e chapt ers t hat best suit your needs. Five different J2EE com ponent t ypes and t echnologies will be covered in t he rem aining chapt ers.

The Big Picture Each of t he J2EE t echnologies is int ended for a specific pur pose and ideally suit ed for solv ing specific t y p es of ch allen g es.

Fi g u r e 9 - 1

pr ov ides a 5 0 , 0 0 0 -f oot v iew of h ow t h e v ar iou s t ech n ologies f it t oget h er .

Figure 9 - 1 . The J2 EE big pict ure

Th e m ain poin t t o n ot e is t h at each t ech n ology is design ed t o be u sed in a specif ic t ier , an d each t ier is d esigned t o be v er y focused on t he r ole t hat it play s in t he ov er all J2EE applicat ion dev elopm ent par adigm . This lim it s t he r oles indiv idual com ponent s can play , ev en t hough su r passin g t h ese lim it s m ay be f easible f r om a t ech n ology per spect iv e.

Servlets In

Ch a p t e r 1 0 ,

w e ex am ine t hese t y pically com pact com ponent s. Ser v let s ar e m ost oft en used

as a con d u it f or p assin g d at a b ack an d f or t h b et w een a Web clien t an d an en t er p r ise applicat ion r unning on a ser ver . This is especially t r ue w hen t her e ar e no specific pr esent at ion det ails r equ ir ed of t h e in f or m at ion bein g passed back .

Servlet s com e in t wo flavors: GenericServlet and Ht t pServlet . We discuss bot h ser vlet t ypes t o a necessar y le vel of t echnology det ail, and t hen t alk about how t o m odel t hem and gain t he m ost fr om t heir UML r epr esent at ion, for ex am ple, v ia m odeling of ser v let-t o-ser v let com m u n icat ion , r elat ion sh ips, session m an agem en t , an d so on .

Th is ch apt er is equ ally applicable t o bot h J2EE 1. 3 ( Ser v let specificat ion 2. 3) and J2EE 1. 2 ( Ser v let specificat ion 2.2) .

JavaServer Pages (JSP)

In

Ch a p t e r 1 1 ,

w e look at t h e n ew er J2 EE t ech n ology of JSP. Th e k ey adv an t age of JSP

t echnology is t hat it allow s for bet t er separ at ion of pr esent at ion cont ent and logic, t her eby sim plify ing dev elopm ent and m aint enance.

Alt hough JSPs get com piled int o ser v let s, t hey ar e best suit ed t o a r ole t hat is fundam ent ally differen t . We discu ss t h is in t h e con t ex t of UML m odelin g of JSP t o u n der st an d h ow t o best m odel t h is h y br id t ech n ology an d w h er e t o best u t ilize it .

Enterprise JavaBeans (EJB) Ch a p t e r s 1 3 , 1 4 ,

an d 1 5 deal w it h t he differ ent t y pes of EJB com ponent s. The chapt er s discuss

t hese com p onent s for bot h J2EE 1. 3 ( EJB specificat ion 2. 0) and J2EE 1. 2 ( EJB specificat ion 1.1) .

Session Beans I n Chapt er 12 , w e discuss t his fir st t y pe of EJB com ponent . Because t his is t he fir st chapt er t hat deals w it h EJBs, w e cov er sev er al gener al det ails t hat apply t o all EJB t y pes; lat er chapt er s sim ply r ef er en ce t h is on e w h er e n ecessar y .

Session beans ar e cur r ent ly t he m ost oft en deploy ed EJB t y pe, and t hey ar e oft en used as t he m ain cont roller in an ent erprise applicat ion, com m only t ying servlet s or JSPs t o ent it y beans or ot h er en t er pr ise applicat ion com pon en t s.

We discuss how t o m odel t heir design wit h t he UML, go int o t he t echnology det ails, and t hen discu ss f u r t h er h ow UML m odelin g can assist in t h e ar ea of b ean -t o-bean r elat ion sh ips, session m an ag em en t , t r an sact ion s, an d so on .

Entity Beans In

Chapt er 13 ,

w e highlight how ent it y EJBs help your ent erprise applicat ion by providing m ore

t han j ust m et hods t o access y our dat abase. UML m odeling and m or e t echnology det ails ar e cov er ed.

We also t ou ch on w h y en t it y bean s h av e a br igh t f u t u r e an d w h y EJB dev eloper s m igh t be m or e com pelled t o u se t h em n ow aday s w it h r ecen t t ech n ology en h an cem en t s an d im pr ov em ent s.

I n addit ion, we cover EJB relat ionships in t his chapt er and discuss how t he UML can sim plify t he t ask of de aling wit h m ore com plex com binat ions of EJB com ponent s. We also t alk briefly about t he EJB Query Language, w hat Persist ence Managers do, and how t hey bot h relat e t o t h e Abst r act Per sist en t Sch em a.

Message -Driven Beans In

Ch a p t e r 1 4 ,

w e discu ss t h ese com pact EJBs, w h ich w er e n ew ly in t r odu ced in J2 EE 1 . 3 .

I nt ended for use w it h loosely coupled sy st em s, w e discuss t he UML and t echnology det ails as w ell as g iv e som e in sig h t on w h er e t o gain t h e m ost f r om u sin g m essage-d r iv en b ean s.

Assembly and Deployment In

Ch a p t e r 1 5 ,

w e discu ss m or e of t h e eXt en sible Mar k u p Lan gu age ( XML) deploy m en t

d escr ip t or asp ect s as t h ey apply t o t h e v ar iou s J2 EE com pon en t s.

We also cov er h ow UML com pon en t an d deploy m en t diagr am s can h elp in t h e w h ole en t er pr ise applicat ion assem bly an d deploy m en t pr ocess.

Case Study In

Ch a p t e r 1 6 ,

w e st ep t h r ou gh t h e Hom eDir ect ex am ple in fu r t h er det ail—par t s of w h ich w e

hav e been r efer r ing t o t hr oughout t he chapt er s. Sev er al use cases ar e elabor at ed fully and com plet ed dow n t o t h e im plem en t at ion lev el. Also in clu ded is a d iscu ssion of som e k ey decisions t aken in t he t ransit ion from analysis t o im plem ent at ion and t rade -offs m ade in t he p r ocess.

Summary Th is ch apt er pr ov ided an ov er v iew of t h e J2 EE t ech n ologies an d com pon en t s t h at w ill be cov er ed in t h e r em ain in g ch apt er s of t h e book .

Specif ically , w e w ill cov er ser v let s, JSPs, session bean s, en t it y bean s, an d m essage-driven b ean s as w ell as assem b ly an d d ep loy m en t asp ect s ap p licab le t o t h ese t ech n olog ies.

The final chapt er in t he book pr ov ides a det ailed case st udy t hat show s how t o apply t he UML t o t h e sam p le p r oj ect t h at h as b een u sed t h r ou g h ou t t h e b ook .

Chapter 10. Servlets •

I n t r o d u ct i o n t o Ser v l et s

•

Se r v l e t Li f e Cy cl e

•

Re q u e st Ha n d l i n g

•

Re sp o n se Ge n e r a t i o n

•

H TTP Re q u e s t H a n d l e r s

•

Th e Re q u e st D i sp a t ch e r I n t e r f a ce

•

Mo d e l i n g Se r v l e t s i n UML

•

Mo d e l i n g Ot h e r Se r v l e t Asp e ct s

•

Se r v l e t D e p l o y m e n t a n d W e b Ar ch i v e s

•

I d e n t i f y i n g Se r v l e t s i n En t e r p r i se Ap p l i ca t i o n s

•

Su m m ar y

Pr oce ss Ch e ck : I n t h is ch a pt e r , w e focu s on de sign a s w e pr ogr e ss t h r ou gh t h e Ra t ion a l Un ifie d Pr oce ss ( RUP) a n a lysis a n d de sign disciplin e . W e a lso discu ss som e a spe ct s of im ple m e n t a t ion in t h e con t e x t of t h e se r vle t t e ch n ology .

Recall t he cont rol obj ect TransferFunds from t he discussion in t he final sequence diagram present ed in

Chapt er 6 ,

Chapter 6 .

I f you look closely at

you'll not ice t wo very dist inct t ypes of

int eract ions perform ed by t his class:

•

I nt eract ions wit h boundary obj ect s t o obt ain inform at ion and perform som e basic work

•

I nt eract ions w it h ent it y obj ect s

I m plem ent ing a cont rol class w it h a dual set of responsibilit ies and a large scope w ould m ake t he cont rol class less m aint ainable and less scalable. To m ake t he cont rol class m ore m aint ainable and scalable, it is preferable t o part it ion t he cont rol class int o t wo classes, one focused on t he ext ernal int eract ion and t he ot her responsible for carrying out t he int ernal coordinat ion and logic.

As it t urns out , t he ext ernally focused part of TransferFunds evolves t o a Java servlet . We int roduce t he servlet in t he next sect ion, and t hen discuss how you act ually det erm ine t he responsibilit ies of t he servlet in t he cont ext of t he Hom eDirect case st udy.

Introduction to Servlets Hist or ically speaking, ser vlet s have been around longer and have seen m uch w ider use t han ot her Java 2 Plat form , Ent erprise Edit ion ( J2EE) t echnologies. I n t he past , t hey t ended t o be lar ge in size and com plicat ed t o m aint ain in com par ison t o t he level of Web funct ionalit y t hey act ually provided. Going forward, servlet s will likely cont inue t o see wide use for som e t im e. How ever , t heir t ypical size is shr inking, and t he level of com plexit y t hey t end t o deal w it h is con sist en t ly becom in g less.

The biggest benefit ser v let s offer dev eloper s is t hat t hey are designed specifically t o process Hy per t ex t Tr an sfer Pr ot ocol ( HTTP) r equ est s com in g fr om t h e Web clien t an d pass back a suit able r esponse. They per for m t his funct ion w ell and r equir e few r esour ces t o deliv er t his funct ionalit y .

I n t er m s of st r u ct ure, servlet s are specialized Java classes t hat closely resem ble t he st ruct ure of Jav a applet s, bu t t h ey r u n on a Web ser v er in st ead of a clien t .

An int erest ing point t o not e is t hat servlet s can never have t heir ow n graphical user int erface. Web ser v er s h ost t h ese com pon en t s t h r ou gh t h e u se of a Web con t ain er t h at m an ages all aspect s of t heir life cy cle.

Common Usage

Ser v let s hav e t he dist inct ion of being t he m ost fr equent ly used J2 EE com ponent s cur r ent ly found on t he Wor ld Wide Web. As st at ed ear lier , t hey t ypically involve a com pact , light weight ar chit ect ur e and design. They also t end t o w or k w ell in cases w her e t he r equir em ent s placed on t h is t y pe of Web com pon en t ar e r elat iv ely sm all.

Most Web dev eloper s use ser v let s as t he m ain point of ent r y t o t heir server applicat ion from t h e Web clien t , an d in t h is w ay , t h ey ar e sim ply u sed as a con du it t o pass in for m at ion back an d f or t h bet w een t h e clien t an d t h e ser v er . Allow in g clien t con t r ol t o add or r em ov e Web p ag es or f iles f r om t h e ser v er can also b e a g ood u se f or ser v let s, as lon g as t h e clien t h as sufficient secur it y clear ance. Under st andably , t his usage is less fr equent ly seen in pr act ice.

Best Served Small

I n t h eor y , ser v let s ar e capable of doin g j u st abou t an y t h in g possible t h at can be don e w it h Jav a. Th e qu est ion ar ises as t o w h y Web dev eloper s don ' t j u st bu ild ev er y t h in g t h ey n eed using t hese com ponent s. The problem is t hat building large servlet s t o handle com plex Web in t er act ion s, t r an sact ion s, dat abase sy n ch r on izat ion , an d ot h er in t er n al logic is not a ver y scalable appr oach. Developer s w ould spend m ost of t heir t im e w or king out t he int r icacies of low -lev el t r an sact ion s, st at e m an agem en t , con n ect ion poolin g, an d so on .

I n t h e past , ser v let s w er e of t en bu ilt t o per f or m m ost or all of t h e f ollow in g t ask s:

•

Ch eck an d p r ocess u ser in p u t

•

Han dle sign ifican t bu sin ess logic

•

Per f or m dat abase qu er ies, u pdat es, an d sy n ch r on izat ion

•

Han dle com plex Web t r an sact ion s

•

Gen er at e d y n am ic Web p ag e con t en t as ou t p u t

•

Han d le Web p ag e f or w ar d in g

Mor e adv an ced J2 EE solu t ion s m ak e u se of Jav aSer v er Pages ( JSP) , En t er pr ise Jav aBean s ( EJB) , and Jav aBeans t o split up and offload m uch of t his w or k , oft en using new m echanism s built int o J2EE t o sim plify t he m or e difficult t ask s for t he dev eloper . Ser v let s ar e t hen r espon sible f or a m or e m an ag eab le set of t ask s:

•

Gat h er in g an d v alidat in g u ser in pu t , bu t lit t le or n o act u al pr ocessin g

•

Coor din at ion of ou t pu t , bu t w it h lit t le or n o dir ect gen er at ion of dy n am ic Web page con t en t

•

Minim al business logic

As y ou can see, ser v let s ar e best ser v e d sm all.

I f const ant dem and for new Web sit e funct ionalit y did not exist , huge ser vlet s could be built w it h all t he accom panying aches and pains, and t hey m ight even st and a reasonable chance of bein g adequ at ely m ain t ain ed. How ev er , t h e f act is t h at dem an ds on Web si t es k eep incr easing. Ev er y ser v ice pr ov ider on t he Web m ust cont inually updat e and upgr ade t o giv e t h eir cu st om er s t h at n ew bit of dat a, t h at n ew cool f eat u r e, or t h at pr ized ex t r a t h at differ en t iat es t h eir ser v ice fr om ev er y on e else' s ser v ice.

Un f or t u n at ely , t h e bigger ser v let s com e at t h e cost of an in cr eased ch allen ge of pr ov idin g adequ at e code m ain t en an ce, n ot t o m en t ion t h e in cr eased r isk of br eak in g som e of t h e exist ing funct ionalit y. The blessing of a light w eight ar chit ect ur e at t he out set can easily t urn in t o a w r et ch ed cu r se lat er on if y ou ar e n ot car ef u l.

J2EE Versions

The infor m at ion in t his chapt er applies equally w ell t o ser vlet s using J2EE 1.3 or J2EE 1.2. The differences bet w een t hese t w o specificat ions are insignificant w it h respe ct t o t he basic Unified Modelin g Lan gu age ( UML) m odelin g of t h ese par t icu lar Web com pon en t s.

Servlet Life Cycle As st at ed earlier, servlet s are deployed w it hin a servlet cont ainer, w hich in t urn is host ed by a Web ser v er . Th e par t icu lar capabilit ies an d le v el of com plian ce of t h e Web ser v er det er m in es w h ich v er sion of t h e ser v let specif icat ion y ou n eed t o be w or k in g w it h .

The basic behav ior of a ser v let inv olv es a r equest -response t ype m odel derived from t he w ay t h e HTTP w or k s; t h u s, t h e in h er en t applicabilit y as a Web com pon en t . Th is beh av ior is illu st r at ed v ia a st at ech ar t diagr am in

Fi g u r e 1 0 - 1 .

Figu r e 1 0 - 1 . Se r vle t life cycle

Servlet s are built as Java classes t hat ext end one of t w o basic servlet im plem ent at ion classes: H t t pSe r vle t an d Ge ne r icSe r vle t . The for m er is t he m ost oft en u sed, y et sligh t ly m or e com plex of t h e t w o. Bot h ser v let t y pes em ploy t h e sam e basic life cy cle.

Life Cycle Methods

The servlet life cycle m akes use of t hree basic request handler m et hods, of w hich any or all can be im plem en t ed w it h in t h e ex t e n d ed ser v let class:

•

init: I n it ializes t h e ser v let

•

se r vice : Ser v ices t h e clien t r equ est

•

dest roy: Dest r oy s t h e ser v let

Of t hese t hr ee m et hods, t he se r vice m et hod is t he m ost int er est ing because it act ually does t h e m aj or it y of t h e n ecessar y pr ocessin g. I t t y pically does t h e follow in g:

•

Receiv es t h e r equ est fr om t h e clien t

•

Read s t h e r eq u est d at a

•

Wr it es t h e r esp on se h ead er s

•

Get s t h e w r it er or ou t pu t st r eam obj ect f or t h e r espon se

•

Wr it es t h e r esp on se d at a

Th e se r vice m et hod is at t he hear t of t he Ge n e r icSe r vle t t y pe. How ev er , it is alm ost nev er ov er r idden an d in st ead is split in t o low er lev el HTTP r equ est h an dler s w h en u sed w it h t h e H t t pSe r vle t t y p e.

Th e init an d dest roy life cy cle m et hods ar e alw ay s av ailable t o be ov er r idden, but in sev er al cases m igh t n ot be u sed if t h e ser v let h as n o specif ic obj ect s or con n ect ion s it n eeds t o init ialize or t er m inat e.

A sequence diagr am in Figure 10-2 show s a sim ple ex am ple of a ser v let . This diagr am applies t o bot h t he Ge n e r icSe r vle t and H t t pServlet . I t highlight s a sim ple ex am ple w her e a dat abase qu er y is m ade t o f or m u lat e t h e r espon se t o t h e clien t . Not e t h at t h e se r vice m et h od is fu r t h er r efin ed in t o a specific HTTP r equ est in t h e case of H t t pServlet .

Figu r e 1 0 - 2 . S equence dia gra m show ing servlet life cycle

Convenience Method

Besid es t h e life cy cle m et h ods, ser v let s com m on ly m ak e u se of w h at ar e r efer r ed t o as con v en ien ce m et h ods. On e su ch con v en ien ce m et h od t h at applies f or all ser v let s is get Servlet I nfo, w h ich r et u r n s a gen er al in f o st r in g abou t t h e par t icu lar ser v let—norm ally aut hor , v er sion , u sag e, an d so on .

Required Methods and Tagged Values

Wh en b u ild in g a ser v let t h at ex t en d s t h e Ge n e r icSe r vle t class, t h e se r vice life cycle m et h od m u st be im plem en t ed; ot h er w ise, t h e ser v let is in v alid. All ot h er m et h ods ar e opt ional.

Mult iple t hrea ds m ay call a gener ic ser v let inst ance's se r vice m et hod concur r ent ly . To av oid t his, t he servlet can im plem ent t he SingleThrea dM odel int erface, w hich is really a m et hod of t yping t he ser vlet and indicat ing t o t he Web cont ainer t hat only a single t hr ead sho uld be allow ed t o call t h e m et h od at an y giv en t im e.

I m plem ent ing t he SingleThreadM odel can h av e a v er y sign if ican t ef f ect on h ow t h e con t ain er d ecid es t o allocat e r esou r ces w h en t h e ser v let is d ep loy ed on t h e Web ser v er , w h ich can gr eat ly im pact t h e t ot al n u m ber of con cu r r en t ser v let in st an ces allow ed.

Using t his appr oach m ay be appr opr iat e if you ar e dealing w it h a sit uat ion in w hich t he ser vlet m ay need t o alt er inform at ion t hat is not t hread safe or access resources t hat are not t hread saf e.

I t is not r ecom m ended t hat y ou at t em pt t o ser ialize any of t he ser v let m et hods ot her t han by im plem en t in g t h is in t er face. Th e in t er face it self in t r odu ces n o n ew m et h ods.

Request Handling Ser v let s ar e r equ est -dr iv en an d h av e specific capabilit ies av ailable t o t h em t h at sim plify h an dlin g of in com in g r equ est s.

Recall t hat a request t o a servlet m ay consist of several pieces of dat a ( for exam ple, w hen a for m consist ing of sev er al fields is filled in and subm it t ed) .

Wh en t h e Web con t ain er r eceiv es a r eq u est in t en d ed f or a ser v let , it en capsu lat es t h e in com in g dat a in t o a Servlet Request obj ect ( com m on ly r efer r ed t o as t h e r equ est obj ect ) and passes it on as a par am et er t o t he ser v let 's se r vice m et hod. The servlet can t hen use t he m et hods av ailable in t he Servlet Request in t erface t o quer y t he r equest obj ect . Som e of t he qu er ies ar e con t ain ed in t h e f ollow in g list :

•

ge t Cha r a ct e r Encoding obt ains infor m at ion about t he encoding for m at used for t he r eq u est .

•

isSe cur e f in ds ou t if t h e r equ est w as m ade ov er a secu r e ch an n el.

•

ge t Pa r a m e terN a m es obt ain s a list of all par am et er n am es in t h e r equ est .

•

getRem oteAddr d et er m in es t h e I P ad d r ess of t h e clien t t h at sen t t h e r eq u est .

•

ge t Pa r a m e t e r is used t o r et r iev e t he fir st par am et er v alue associat ed w it h a nam ed par am et er t y pe.

•

ge t Pa r a m e t e r Va lue s is used t o r et r iev e m ult iple par am et er v alues associat ed w it h a n am ed p ar am et er t y p e.

Sev er al ot her m et hods ar e pr ov ided for quer y ing differ ent aspect s of t he r equest obj ect . See j a va x .se r vle t .Se r vle t Re que st [ 1 ] for m or e infor m at ion. A specialized v er sion,

H t t pServlet Request , f or HTTP based ser v let r equ est s is also av ailable. See j avax.servlet .ht t p.H t t pServlet Request for m or e infor m at ion. [ 1]

I f y ou ar e new t o Jav a or unsur e about t his r efer ence, see the " Convent ions " sect ion in t he

Pr ef ace of t h is book .

Fi g u r e 1 0 - 3

sh ow s a sim ple u sage scen ar io in v olv in g a r eq u est ob j ect .

Figu r e 1 0 - 3 Using t he request obj ect

HttpSession session = request.getSession(true); : : // obtain the values for UserID and password String loginID = rquest.getParameter ("USERID"); String loginPassword = request.getParameter ("PASSWORD"); :

Response Generation A r eq u est g en er ally w ar r an t s a r esp on se, an d ser v let s ar e n o ex cep t ion in t h is r eg ar d .

Ser v let s m ak e u se of Servlet Response t o sim plify t his com m on t ask . The Se r vle t Re sponse obj ect , com m only referred t o as t he response obj ect , i s in fact provided t o a ser v let alon g sid e t h e r eq u est ob j ect as a p ar am et er t o t h e se r vice m et h od.

Ou t pu t can be w r it t en in eit h er bin ar y or ch ar act er for m at by obt ain in g a h an dle t o eit h er a Se r vle t Out put St r e a m obj ect or a Pr int W r it e r obj ect , r espect iv ely . Som e of t h e ot h er m et h ods pr ov ided by t h e Servlet Response in t er face ar e con t ain ed in t h e follow in g list :

•

ge t Ou t pu t St r e a m obt ains t he handle t o a Se r vle t Ou t pu t St r e a m obj ect for binar y d at a.

•

ge t W r it e r obt ain s t h e h an dle t o a Pr in t Wr it er obj ect f or ch ar act e r d at a.

•

se t Buffe r Size can b e u sed t o est ab lish t h e b u f f er size f or t h e r esp on se t o en ab le bet t er per f or m an ce t u n in g.

•

flushBuffer f lu sh es t h e cu r r en t con t en t s of t h e bu f f er .

For m or e infor m at ion, see j a va x .se r vle t .Re sponse Obj e ct an d j a va x .se r vle t . Se r v le t Out put St ream .

An HTTP specific r esponse obj ect is also av ailable and pr ov ides addit ional capabilit ies r elat ed t o HTTP r espon se h eader f or m u lat ion . See j avax .servlet . ht t p.H t t pServlet Response for m or e infor m at ion.

Fi g u r e 1 0 - 4

sh ow s a sim p le u sag e scen ar io in v olv in g a r esp on se ob j ect .

Figu r e 1 0 - 4 Generat ing t he response

PrintWriter out; : // set content type response.setContentType("text/html"); : out = response.getWriter(); out.println(""); : out.println("Login Unsuccessful"); : out.flush(); out.close();

Alternatives for Response Generation

I f y ou t ak e a good look at Figure 10-4 , y ou w ill see sev er al HTML t ags inv olv ed in t he generat ion of ou t pu t f r om t h e ser v let . Th is r epr esen t s on ly on e appr oach f or gen er at ion of dy n am ic ou t p u t .

An ot h er sim ilar bu t m or e st r u ct u r ed appr oach is t o u se libr ar ies of HTML files t o gen er at e com m on h ead er s an d f oot er s f or t h e n ecessar y r esp on se Web pages, w it h t h e dy n am ic p or t ion of t h e p ag e st ill g en er at ed m u ch lik e w h at w as sh ow n in

Fi g u r e 1 0 - 4 .

A t hir d and cleaner appr oach is t o use t he pow er of JSP and Jav aBeans w henev er possible. I n t h is appr oach , t h e ser v let sim ply n eeds t o f or w ar d t o a JSP page t h at con t ain s all of t h e n ecessar y pr esen t at ion in f or m at ion an d u se JSP t ech n ology an d Jav aBean s t o f ill in t h e dynam ic cont ent por t ions of t he page. Ot her t han t he for w ar d, t he ser vlet has lit t le else t o do w it h pr esen t at ion ex cept per h aps coor din at in g t h e n ecessar y it em s f or t h e JSP page t o successfully do it s w or k .

We discu ss t h is appr oach f u r t h er in

Ch a p t e r 1 1 .

HTTP Request Handlers Th e H t t pSe r vle t class ex t en d s t h e Ge n e r icSe r vle t class an d t h er ef or e in h er it s all of t h e st an dar d ser v let capabilit ies. I n addit ion t o t h e basic ser v let life cy cle m et h ods an d conv enience m et hod, t he m or e com plex H t t pSe r vle t class ad d s m et h ods t o aid in t h e pr ocessin g of HTTP r equ est s. Th ese com m on ly u sed h an dler m et h ods ar e

•

doGet : Han dles HTTP GET r equ est s

•

doPost: Han dles HTTP POST r equ est s

I n t h e case of doGet , t h er e is an addit ion al m et h od u sed for con dit ion al HTTP GET su ppor t ( t he d ifferent HTTP request t ypes are explained lat er in t his sect ion) . The get La st M odified m et hod is lik e HTTP GET, but only r et ur ns cont ent if it has changed since a specified t im e. This m et hod can only be used if doGe t has also been ov er r idden and is int ended t o be used in cases w h er e y ou ar e d ealin g w it h con t en t t h at d oes n ot ch an g e m u ch f r om r eq u est t o r eq u est .

Advanced Handler Methods

Th er e ar e sev er al ad v an ced h an d ler m et h od s t h at ar e d ef in ed as w ell:

•

doPut: Han dles HTTP PUT r equ est s

•

doDelet e: Handles HTTP DELETE r equ est s

•

doOpt ions: Han dles HTTP OPTI ONS r equ est s

•

doTr a ce : Han dles HTTP TRACE r equ est s

Unlik e t he Ge n e r icSe r vle t class, ser vlet s based on H t t pSe r vle t have alm ost no valid reason t o ov er r ide t h e se r vice m et h od. I n st ead, y ou t y pically ov er r ide t h ese r eq u est h an d ler s, w hich t he base se r vice m et hod im plem ent at ion calls w hen appr opr iat e. The doOpt ions and doTra ce m et hods also have vir t ually no valid r eason t o be over r idden and ar e pr esent only for full HTTP suppor t . An H t t pSe r vle t m u st ov er r ide at least on e m et h od, w h ich u su ally m ean s on e of t h e r em ain in g lif e cy cle m et h ods or r equ est h an dler s.

Quick Guide to HTTP Requests

For t h e m ost com m on ly u sed r equ est h an dler m et h ods, t h e follow in g list pr ov ides a qu ick gu ide of w h at t h e HTTP r equ est s ar e f or :

•

GET: A call t o get infor m at ion fr om t he ser ver and r et ur n it in a r esponse t o t he client . The m et hod pr ocessing t his call m ust not hav e any side effect s, so it can be r epeat ed safely again an d again . A GET call is t y pically u sed w h en a ser v let URL is accessed d ir ect ly fr om a Web br ow ser or v ia a for w ar d fr om a for m on an HTML or JSP page. A GET call show s t he dat a being passed t o t he ser v let as par t of t he display ed URL on m ost Web br ow ser s. I n cer t ain cases, t his m ight not be ver y desir able fr om a secur it y per s pect iv e.

•

POST: A call t o allow t h e clien t t o sen d dat a t o t h e ser v er . Th e m et h od pr ocessin g t his call is allow ed t o cause side effect s, such as updat ing of dat a st or ed on t he ser v er . A POST call can be used inst ead of a GET w hen forw arding from a form on a n HTML or JSP page. Unlike GET, t he use of POST hides fr om view any dat a being passed t o t he servlet . Som e developers choose t o process GET and POST exact ly t he sam e, or sim ply ignor e one or t he ot her if t hey do not w ant t hat par t icular call t o be suppor t e d .

•

PUT: This call is sim ilar t o POST, but allow s t he client t o place an act ual file on a ser v er in st ead of j u st sen din g dat a. I t is also allow ed t o cau se side effect s, j u st lik e POST. Alt hough av ailable, t he use of a PUT call is not v er y com m on.

•

D ELETE: Th is call is sim ilar t o PUT, but allow s t he client t o r em ov e a file or Web page f r om t h e ser v er . I t is also allow ed t o cau se side ef f ect s in t h e sam e w ay as PUT. Alt hough av ailable, t he use of a DELETE call is not v er y com m on.

Th er e is an ot h er r eq u est n ot sp ecifically m ent ioned in t he pr eceding list called HTTP HEAD. This r equest , alt hough v alid in t he cont ex t of t he H t t pSe r vle t class it self, is act ually handled int er nally by m ak ing a call t o t he doGe t m et hod, w hich you m ight have over r idden. I t differ s in t hat it on ly r et u r n s t h e r espon se h eader s t h at r esu lt f r om pr ocessin g doGe t and none of t h e act u al r esp on se d at a.

The RequestDispatcher Interface Given t he sim plicit y of ser vlet s, it m akes sense t o keep each ser vlet focused on a specific t ask, and t hen set u p m ult iple servlet s t o collaborat ively achieve a m ore com plex t ask. Servlet s can t ake care of t he m echanical aspect s of such collaborat ive effort s easily by im plem ent ing t he Request Dispat cher in t er face.

Th e Request Dispat cher in t er f ace pr ov ides t w o k ey capabilit ies:

•

forw ard: Th is m et h od allow s a ser v let t o f or w ar d a r eq u est t o an ot h er Web com ponent . The servlet forw arding t he request m ay process t he request in som e w ay pr ior t o t he for w ar ding. For w ar d can effect iv ely be used t o achiev e ser v let chaining w h er e each lin k in t h e ch ain pr odu ces som e ou t pu t t h at can be m er ged w it h t h e or iginal r equest dat a, and t hen be used as t he input t o t he nex t ser v let in t he chain. Th is is essen t ially sim ilar t o t h e con cept of pipes in t h e UNI X w or ld.

Not e t h at t h e t er m " r edir ect " is som et im es u sed in t er ch an geably w it h " f or w ar d, " in t en din g t h e sam e m ean in g. How ev er , t h is sh ou ld n ot be con f u sed w it h t h e sendRedirect m et hod found on t he ser v let r esponse. A se ndRe dir e ct call does not guar ant ee pr eser v at ion of t he r equest dat a w hen it for w ar ds t o a new page, so it does n ot allow f or t h e sam e ser v let ch ain in g capabilit ies.

•

include : This m et hod perm it s t he cont ent s of anot her Web com ponent t o be included in t he r esponse fr om t he calling ser v let . The fir st ser v let sim ply includes t he o t h er ser vlet at t he appr opr iat e point in t he out put , and t he out put fr om t he ser vlet being included is added t o t he out put st r eam . This is sim ilar in concept t o Ser v er Side I ncludes ( SSI ) . [ 2 ] [ 2]

SSI allow s em beddin g of special t ags in t o an HTML docu m en t . Th e t ags ar e

under st ood by t he Web ser ver and ar e t r anslat ed dynam ically as t he HTML docum ent is ser v ed t o t h e br ow ser . JSPs bu ild on t h is idea.

Modeling Servlets in UML Th e Ge n e r icSe r vle t class is usually m o d eled as a st an d ar d Jav a class w it h t h e < < Ge ne r ic_ Se r vle t > > st er eot y pe applied. Th e pr esen ce of t h e st er eot y pe allow s f or t h e ser v let t o be r epr esen t ed in a com pact f or m an d st ill be easily dist in gu ish ed as a gen er ic ser v let w it hout t he need t o show t he in herit ance t ree on t he sam e diagram . A generic servlet can in clu de an y of t h e life cy cle m et h ods or t h e con v en ien ce m et h od discu ssed ear lier .

A m or e ex panded v iew of t he ser v let class show ing t he inher it ance fr om t he Ge n e r icSe r vle t class can also be u sed. I n m ost cases, t hough, t he m or e com pact st er eot y ped class v iew is su fficien t . Th e com pact an d ex pan ded r epr esen t at ion s of t h e ser v let ar e sh ow n in Figure 10- 5 .

Figu r e 1 0 - 5 . Com pa ct a nd full represent a t ion of a generic servlet

I f t he ser v let im plem ent s t he SingleThreadM odel int er face, w hich c ont r ols ser ializat ion of t h e se r vice m et h od, t h e ser v let can be sh ow n w it h t h e in t er f ace t o h igh ligh t t h is aspect . Opt ion ally , t h e ser v let can be t agged w it h { Single ThreadServlet = True} in st ead t o clear ly iden t ify t h is on t h e diagr am in a som ew h at m or e co m pact for m at .

An ex am ple of a ser v let t h at im plem en t s t h e SingleThreadM odel is sh ow n in

Fi g u r e 1 0 - 6 .

Figu r e 1 0 - 6 . Servlet support ing t he SingleThreadM odel

Th e H t t pSe r vle t class is m odeled sim ilar ly t o Ge ne r icSe r vle t , b u t w it h t h e < < H t t p_ Servlet > > st er eot y p e ap p lied. I t can also include t he life cy cle m et hods, t he con v en ien ce m et h od, an d an y of t h e HTTP r equ est h an dler s pr ev iou sly discu ssed.

Th e SingleThrea dM odel det ails as w ell as t he t agged v alue for Sin gle Th r e a dSe r vle t apply in t h e H t t pSe r vle t class ex act ly t h e sam e w ay as t h ey d id f or Ge ne r icSe r vle t . As st at ed ear lier , y ou sh ou ld n ot at t em pt t o ser ialize an y of t h e ser v let m et h ods ot h er t h an by im plem en t in g t h is in t er face. Th is in t er face does n ot in t r odu ce an y n ew m et h ods.

Modeling Other Servlet Aspects Ot h er aspect s of ser v let s t h at w ar r an t m odelin g ar e ser v let f or w ar d, ser v let in clu de, Ser v let Con t ex t , an d Ser v let Session Man agem en t . Th e f ollow in g sect ion s discu ss t h ese aspect s in m or e det ail.

Servlet Forward

Ser v let for w a r d is a special kind of relat ionsh ip, and m odeling it explicit ly can help clarify t he ov er all applicat ion logic. For ex am ple, it can shed light on t he flow of t he pr ocessing logic. I n com plicat ed for w a r d chains, t he r elat ionship m ay be indicat iv e of som e algor it hm being

im plem en t ed. Tw o specific appr oaches help t o ident ify t he ov er all applicat ion logic in t his r eg ar d .

Fir st , on t he class diagr am , label t he r elat ionships bet w een t he ser v let s t hat inv ok e for w a r d on ot her Web com ponent s wit h t he < < forward> > relat ionship. An exam ple is shown in

Figure

10-7.

Figu r e 1 0 - 7 . M odeling servlet forw a rding on a cla ss dia gra m

For m or e com plicat ed ser v let chaining, an act iv it y diagr am c an be u sed t o sh ow t h e ov er all int er act ion. I f desir ed, r equest and r esponse obj ect s w it h at t r ibut es appr opr iat ely updat ed at specif ic poin t s can be sh ow n t o dem on st r at e t h e ov er all algor it h m . See

Fi g u r e 1 0 - 8 .

Figu r e 1 0 - 8 . M odeling servlet forw a rding w it h a ct ivit y dia gra m

I n t his case, w e have labeled t he t ransit ion w it h t he < < forw ard> > st ereot ype t o em phasize t h at it r ep r esen t s a f or w ar d r elat ion sh ip bet w een t h e elem en t s in v olv ed. Th e com m en t s show n for each occur r ence of t he r esponse obj ect ident ify w hat happens as t he r equest and r esp on se ob j ect s p ass t h r ou g h t h e ch ain .

Servlet Include

I nclude is anot her significant and special r elat ionship as it affect s t he result s produced by a ser vlet . I n fact , include m ay be used as a m eans t o st r uct ur e and or ganize t he ov er all out put in a m odular fashion. Ser v let include r elat ion sh ips ar e m odeled in t h e sam e f ash ion as t h e for w a r d relat ionship, t hat is, as a unidirect ional associat ion st ereot yped < < include> > . The dir ect ion of t h e associat ion is fr om t h e in clu din g ser v let t o t h e r esou r ce bein g in clu ded. An exam ple is show n in Figure 10-9 . I n t he example, a servlet responsible for creat ing a m ort gage am or t izat ion t able includes header and foot er ser v let s w hose sole pur pose is t o gener at e t he page h eader an d f oot er , r espect iv ely .

Figu r e 1 0 - 9 . Servlet include rela t ionship

ServletContext

Each ser v let r uns in som e env ir onm ent . The Se r vle t Cont e x t pr ov ides infor m at ion about t he en v ir on m en t t h e ser v let is r u n n in g in . A ser v let can belon g t o on ly on e Se r vle t Cont e x t a s det erm ined by t he adm inist rat or. Typically, one Se r vle t Cont e x t is associat ed w it h each Web applicat ion deploy ed in a con t ain er . I n t h e case of dist r ibu t e d con t ain er s, on e Se r vle t Cont e x t is associat ed w it h on e Web applicat ion per v ir t u al m ach in e.

Th e Servlet Cont ext int erface can be used by servlet s t o st ore and ret rieve inform at ion and sh ar e in f or m at ion am on g ser v let s. A ser v let obt ain s t h e Se r vle t Cont e x t it is r unning in by u sin g t h e get Servlet Cont ex t m et h od.

Som e of t h e basic ser v ices pr ov ided by t h e Se r vle t Cont e x t int er face ar e

•

set At t ribut e: St or es infor m at ion in t he cont ex t

•

get At t ribut e: Ret r iev es in for m at ion st or ed in t h e Se r vle t Cont e x t

•

getAttributeNam e s: Obt ain s t h e n am es of at t r ibu t es in t h e con t ex t

•

rem oveAt t ribut e: Rem ov es an at t r ibu t e in t h e con t ex t

An appr oach sim ilar t o t he one discussed for ser v let for w ar ding and show n in Figure 10-8 can b e em ploy ed t o m odel ser v let in t er act ion s w it h t h e Servlet Cont ex t .

Servlet Session Management

Giv en t he st at eless nat ur e of t he HTTP pr ot ocol, m anaging r epeat int er act ion and dialog w it h t he sam e client ( such as t hat required for an ongoing shopping session) poses som e serious ch allen ges. Th er e ar e v ar iou s m ean s of ov er com in g t h ese ch allen ges:

•

Hidden fields: Hidden f ields ar e em bedded w it h in t h e page display ed t o t h e clien t . Th ese f ields ar e sen t back t o t h e clien t each t im e a n ew r equ est is m ade, t h er eby p er m it t ing client ident ificat ion each t im e a client m ak es a r equest .

•

Dynam ic URL rewrit ing: Ex t r a infor m at ion is added t o each URL t he client click s on. This ext ra inform at ion is used t o uniquely ident ify each client for t he durat ion of t he client session, f or ex am ple, adding a " ?sessionid= 97859" t o t he end of each URL t he clien t click s t o iden t if y t h at t h e r equ est is associat ed w it h session id 9 7 8 5 9 .

•

Cookies: St or ed in f or m at ion can lat er be passed back t o t h e clien t r epeat edly . Th e Web server provides t he cookie t o t he browser. Cookies are one of t he m ore popular m ean s of set t in g u p a ser v let session .

•

Server-side session obj ect : Cook ies and URL encoding suffer fr om lim it at ions on how m u ch in f or m at ion can be sen t back w it h each r equ est . I n ser v er-sid e session m anagem ent , t he session infor m at ion is m aint ained on t he ser v er in a session obj ect an d can b e accessed as r eq u ir ed . Ser v er-side session obj ect s ar e ex pensiv e t o use, so it is best t o u se t h em spar in gly .

The Java Ser vlet Applicat ion Pr ogr am m ing I nt er face ( API ) provides abst ract ions t hat direct ly su ppor t som e of t h e session m an agem en t t ech n iqu es discu ssed in t h e pr ecedin g list .

Th e cor e abst r act ion pr ov ided by t h e ser v let API is t h e HTTP session, w hich facilit at es h an dlin g of m u lt iple r equ est s fr om t h e sam e u ser .

Fi g u r e 1 0 - 1 0

giv es an ex am ple of ser v let session m an agem en t .

Figu r e 1 0 - 1 0 Se r vle t se ssion usa ge

import.javax.servlet.http.*; ... // locate a session object HttpSession theSession = request.getSession (true); ... // add data to the session object theSession.putValue("Session.id", "98579"); ... // get the data for the session object sessionid =

theSession.getValue("Session.ID");

Act ivit y diagram s can be used t o m odel t he servlet and session in t eract ion. This is sim ilar t o t h e ap p r oach d iscu ssed f or ser v let f or w ar d in g an d sh ow n in

Fi g u r e 1 0 - 8 .

Servlet Deployment and Web Archives A descr ipt or based on XML is u sed in t h e deploy m en t of ser v let s on a Web ser v er . Th e com piled ser vlet class, addit ional suppor t ing Java classes, and t he deploym ent descr ipt or ar e pack aged t oget h er in t o a Web ar ch iv e f ile, also k n ow n as a " . w ar " f ile.

Th e deploy m en t descr ipt or is an XML-b ased f ile t h at con t ain s sp ecific configur at ion and deploy m en t in for m at ion for u se by t h e ser v let con t ain er .

Fi g u r e 1 0 - 1 1

sh ow s an ex am ple of a v an illa XML deploy m en t descr ipt or f or an H t t pServlet .

Addit ional r equir ed fields in t he descr ipt or ar e filled in dur ing configur at ion and deploy m ent on t h e Web ser v er .

Figu r e 1 0 - 1 1 A sim ple va n illa XM L de ploym e n t de scr ipt or for a sa m ple H t t pSe r vle t



LoginServlet LoginServlet

We discuss servlet de ploym ent descr ipt or s and Web ar chive files and t heir r ole in t he cont ext of m odeling in

Ch a p t e r 1 5 .

Identifying Servlets in Enterprise Applications Now t hat y ou hav e becom e int im at ely fam iliar w it h servlet s, it is t im e t o ret urn t o building t he Hom eDir ect online bank ing ex am ple.

At t h e begin n in g of t h is ch apt er , w e iden t if ied t h e n eed t o ev olv e t h e con t r ol obj ect in t h e Tr an sf er f u n ds u se case by split t in g it in t o t w o, on e f ocu sed on t he ex t er nal int er act ion and t h e ot h er f ocu sed on t h e in t er n al in t er act ion .

Of cour se, t he quest ion r em ains: How do y ou act ually ar r iv e at t his div ision of r esponsibilit ies? The answ er is part ly based on underst anding w hat a servlet is capable of doin g and t he rest on j u dgm en t an d ex per ien ce. I n gen er al, t h e r ole of t h e ser v let is t h at of a coor din at or bet w een t h e bou n dar y obj ect s an d t h e r est of t h e sy st em . All t h e in t er act ion bet w een t h e boundar y obj ect and t he com posit e cont r ol class belongs in t he new servlet . How you split t he int eract ion t hat is shown bet ween t he cont rol obj ect and t he ent it y obj ect s is som ewhat less clear . The k ey fact or t o r em em ber is t hat t he ser v let is pr im ar ily a coor dinat or ; and hence, it should only t ake on light weight responsibilit ies, which could include init iat ing som e business logic. How ever , act ual business logic, com put at ions, int er act ion w it h ent it y obj ect s, and so on w ou ld all f all ou t side of t h ese r espon sibilit ies.

Wit h t his in m ind, let ' s t ak e anot her look at t he i n t er act ion s in v olv in g t h e con t r ol obj ect as sh ow n in

Fi g u r e 1 0 - 1 2 .

Figu r e 1 0 - 1 2 . Cont rol obj ect int eract ions

I f we look at all of t he cont rol obj ect responsibilit ies, we see t hat t he lower half is com prised of sev er al act ions t hat t oget her for m a com plet e t r ansact ion. We decide t o separ at e t his par t an d h av e it be h an dled by an in t er n ally focu sed con t r ol obj ect , leav in g t h e r est t o be t ak en car e of by a ser v let .

Fi g u r e 1 0 - 1 3

sh o w s t h e r esu lt of t h is div ision of du t ies.

Figu r e 1 0 - 1 3 . Division of responsibilit ies bet w een t he servlet and int ernal cont rol

I n t h is scen ar io, t h e ser v let is an ex am ple of w h at t h e RUP calls a front com ponent . A fr ont com ponent is t ypically a ser vlet or a JSP t hat is pr im ar ily r esponsible for pr o cessing user input bu t is n ot it self r espon sible f or pr esen t at ion . Rat h er , it act s sim ply as an en t r y poin t t o t h e applicat ion and as a coordinat or w it h ot her com ponent s. Not e t hat t he t erm " TransferPage" is u sed t o gen er ically r epr esen t a u ser in t er f ace. We m ight decide t o m ak e t his a st at ic HTML page or som et hing m or e dy nam ic.

We discu ss w h at t o do w it h t h e ot h er , in t er n al f ocu sed con t r ol obj ect in t h e n ex t ch apt er .

Of t he t wo t ypes of servlet s discussed, an H t t pSe r vle t appears ideally suit ed t o t ake on t he ex t er n al in t er act ion r ole du e t o t h e Web-based n at u r e of t h e Hom eDir ect in t er f ace.

Figure 10-1 4

ex pands fur t her on t his scenar io. Ther e ar e r eally t w o cust om er act ions inv olv ed in

t h is u se case. Th e f ir st is w h er e t h e cu st om er decides t o do a t r an sf er act ion . Th is in v ok es MainServlet , which coordinat es t he ret rieval of t he pert inent account s dat a and displays t his v ia t h e Tr an sfer Page bou n dar y obj ect . Th e cu st om er t h en select s t h e desir ed accou n t s and en t er s t h e am ou n t t o t r an sf er . Con t r ol at t h is poin t is f or w ar ded t o a secon dar y Tr an sfer Ser v let , w h ich coor din at es t h e act u al t r an sfer act ion v ia t h e in t er n ally focu sed con t r ol obj ect .

Figu r e 1 0 - 1 4 . M a inServlet a nd Tra nsferServlet division of responsibilit ies

Figure 10- 15

show s t he det ails of t he servlet s for t his exam ple. We purposely have t he servlet s

h an dlin g as lit t le pr ocessin g as possible, of f loadin g m ost of t h e w or k t o t h e ot h er J2 EE

com pon en t s, w h ich w e discu ss in m or e det a il in lat er chapt er s cov er ing JSP and EJB t echnology .

Figu r e 1 0 - 1 5 . M a inSe r vle t a nd Tr a nsfe r Se r vle t de t a ils

Th e decision t o split u p t h e ser v let r espon sibilit ies w ill v ar y depending on specific needs. I n t h is case, ou r pr efer en ce w as t o m in im ize t h e r espon sibilit ies of t h e Main Ser v let t o bein g a coor dinat or only . A secondar y lev el of ser v let s w as t her efor e dev eloped t o handle t he det ails of in div idu al u se cases.

Summary Ser v let s h av e a ligh t w eigh t ar ch it ect u r e an d ar e ideally su it ed f or r equ est -r esp o n se par adigm s. Ser v let s ar e lik e or dinar y Jav a classes w it h t he ex cept ion t hat specific life cy cle m et h ods m u st ex ist in t h e ser v let . Specific HTTP r equ est h an dler m et h ods ar e u sed f or H t t pServlet . Tw o t y pes of ser v let s, Ge n e r icSe r vle t an d H t t pServlet , ar e def in ed in t h e J2 EE.

Ser v let s ar e m odeled as st er eot y ped Jav a classes. UML m odelin g t ech n iqu es can br in g special f ocu s on som e aspect s of ser v let s, su ch as f or w ar din g, in clu din g, an d session m an agem en t by ser v let s.

An XML deploy m en t descr ipt or is r equ ir ed for deploy in g a ser v let .

Chapter 11. JavaServer Pages •

I n t r o d u ct i o n t o JSP

•

An a t o m y o f a JSP

•

Ta g Li b r a r i e s

•

JS P a n d t h e U M L

•

JSP i n En t e r p r i se Ap p l i ca t i o n s

•

Su m m ar y

Pr oce ss Ch e ck : I n t h is ch a pt e r , w e focu s on de sign a s w e pr ogr e ss t h r ou gh t h e Ra t ion a l Un ifie d Pr oce ss ( RUP) a n a lysis a n d de sign discipline . W e a lso discuss a spe ct s of im ple m e nt a t ion in t he con t e x t of t h e JSP t e ch n ology.

Unt il a few years ago, t he t erm t hin client was unheard of. That changed wit h t he advent of t he Web brow ser and t he subsequent rush t o creat e sophist icat ed Web -based applicat ions in virt ually every indust ry.

Thin client s, as we all know, ut ilize a m arkup language for present at ion. Sophist icat ed server-side applicat ions writ t en in languages such as Java are t hus used t o generat e t he m arkup language for present at ion t o t he client .

This int erm ingling of t he program m ing side of t he applicat ion wit h t he present at ion side has som e drawbacks:

•

Pr esent at ion can change frequent ly. This m eans a lot of recom pilat ion and rebuilding for reasons t hat have not hing t o do wit h t he applicat ion logic.

•

The present at ion has t o be coded in t he cont ext of t he program m ing language using const r uct s such as print ln. This m eans t he present at ion layout is not as readily int elligible as it is encoded wit hin t he applicat ion program m ing language and cannot really be previewed unt il runt im e. From t he servlet designer perspect ive, it is equally hard t o read line aft er line of HTML code em bedded wit hin pr int ln st at em en t s.

•

I n m ost lar ge or ganizat ions, t he Web pr esent at ion developer r ole is dist inct fr om t he soft ware developer role. This coupling has creat ed a drawback such t hat t he Web developers now m ust underst and t he program m ing side t o creat e t he present at ion

layout , and t hey can no longer use specialized t ools available t o t hem for developing t he pr esent at ion.

The JavaServer Pages ( JSP) t echnology was conceived specifically t o address t hese issues.

Introduction to JSP Lik e ser v let s, JSP is a t y pe of Jav a 2 Plat for m , Ent er pr ise Edit ion ( J2EE) Web com ponent . JSP is sim ilar t o ser v er-side script ing t echnology, but t here is a key difference —JSP is com piled, w her eas scr ipt s ar e int er pr et ed. JSP allow s a pr ogr am t o be em bedded in HTML docum ent s, w hich can lat er be parsed by a Web server. JSP ut ilizes t he Java Servlet t echnology t o achieve ser v er-sid e p r ocessin g .

A JSP con sist s of Jav a code em bedded w it h in a st r u ct u r ed docu m en t su ch as HTML or XML. The idea is t o use t he m ar k up language for t he st at ic por t ions of t he pr esent at ion and em bed special t ags w it h in t h e page t o m ar k u p t h e dy n am ic con t en t . Th e t ags ar e also u sed t o pr ocess in com in g r equ est s f r om a clien t an d gen er at e r espon ses as a r esu lt . Wh en a JSP is r equ est ed, t h e JSP code is p r ocessed on t h e ser v er , an d t h e com b in ed r esu lt s of t h e pr ocessin g an d t h e st at ic HTML page ar e sen t back t o t h e clien t .

Use of JSP allow s t h e pr esen t at ion code t o be easily m ain t ain ed as r egu lar HTML code an d sh ield s t h e Web d ev elop er f r om h av in g t o d eal w it h an u n f am iliar lan gu age an d t ools.

Som e m ay ar gu e t h at becau se Jav a is st ill em bedded w it h in a JSP, t h e separ at ion of present at ion from business logic is not a realit y. The key point t o keep in m ind is t hat it is a differ ence of per spect iv e. I n ser v let s, t he present at ion side is forced t o absolut ely live in t he sof t w ar e d ev elop m en t w or ld , w h er eas JSPs ar e p r esen t at ion -cen t r ic com pon en t s w it h car ef u lly pack aged Jav a pieces em bedded w it h in t h em t o h an dle t h e dy n am ic aspect s.

Typical Uses of JSP

The JSP specif icat ion pr ov ides t h e JSP w it h t h e sam e capabilit ies as t h e ser v let , an d it is indeed possible t o creat e a very confusing but legal JSP t hat has all t he code norm ally put in a ser v let . Sim ilar ly , it is equally possible t o t ot ally ignor e t he JSP t echnology and use ser v let s exclusively.

Th e pr oper u sage is a com bin at ion of t h e t w o. Th e idea is t o lev er age t h e JSP f or pr esent at ion-cent ric t asks and ut ilize t he servlet s where logic is param ount . A JSP is ideally suit ed for use in sit uat ions w here dynam ic cont ent m ust be pr esent ed t o t he client . I n gener al, JSP should be focused on pr esent at ion, and any Jav a code em bedded w it hin t he JSP should pr im ar ily be for com m unicat ion w it h ser v let s and/ or ot her cont r ol/ dat a ent it ies.

A JSP does consum e ext ra syst em resources ( e.g., requires com pilat ion) , so it should not be u sed w h er e pr esen t at ion con t en t is st at ic. A plain HTML page sh ou ld be u sed in su ch sit u at ion s.

Model 1 and Model 2 Architectures

Tw o ar chit ect ur es, gener ally r efer r ed t o as Model 1 an d Model 2, w e re especially dom inant in t h e JSP dev eloper com m u n it y w h en JSPs w er e fir st in t r odu ced. Today , m ost dev elopm en t ef f or t s m ak e u se of Model 2 ; h ow ev er , t h er e ar e st ill som e sim pler cases w h er e a Model 1 appr oach h as m er it .

Model 1 ar chit ect ur e is sim ple in t hat it in v olv es u sin g JSPs f or pr esen t at ion as w ell as t h e bu sin ess logic. Th e adv an t age of t h is appr oach lies in it s sim plicit y an d it s ease of im plem en t at ion . Un for t u n at ely , Model 1 can qu ick ly lead t o bloat ed an d br it t le code t h at is h ar d t o m an ag e an d evolv e.

Model 2 ar ch it ect u r e f ollow s t h e Model-View -Cont r oller ( MVC) par adigm . I t is m or e pr ogr am m er fr ien dly as it in v olv es u sin g on e or m or e ser v let s as con t r oller s. Requ est s ar e r eceiv ed by t h e f r on t lin e ser v let ( s) , an d t h en r edir ect ed t o JSPs as w ar r an t e d and required. The key t o success w it h Model 2 is ident ifying t he r ight num ber of ser vlet s r equir ed t o fulfill t he t ask s ( ex t r em e cases being a single ser v let for ev er y t hing and a ser v let for each use case or possible act ion! ) . Anot her k ey elem ent of t his st r at eg y is t h e u se of Jav aBean s as t h e m odel. The JavaBean act s as t he " com m unicat ion" vehicle bet w een t he cont r oller ser vlet ( s) and t he JSPs. The cont r oller fills in t he Jav aBean based on t he r equest , and t he JSP can t hen com pose t he act ual page using values fr om t he Jav aBean. I n t his case, t he JSP t y pically uses t h e j sp: useBean t ag t o access t h e Jav aBean . Mod el 2 p r ov id es a clean er sep ar at ion of t h e pr esen t at ion fr om t h e logic. Alt h ou gh t h e Model 2 appr oach is h ar der t o im plem en t , code d ev elop ed u sin g t h e Mod el 2 ap p r oach is easier t o m an ag e.

Som e d ev elop er s er r on eou sly b eliev e t h at Mod el 1 is ob solet e an d h as essen t ially b een displaced by Model 2 . I n f act , y ou can em ploy eit h er of t h e t w o m odels depen din g on w h at you are t rying t o achieve. Deciding bet w een t he t w o m odels should be dr iv en by t he follow ing gu idelin es:

•

Model 1: Use t h is m odel w h en y ou ar e t r y in g t o bu ild a sim ple Web applicat ion t h at does n ot h av e sign if ican t pr ocessin g r equ ir em en t s.

•

Model 2: Use t his m odel w hen r equest s t y pically k ick off ex t ensiv e pr ocessing, w hich can r esu lt in d iv er se r esp on ses.

I n t h e en d, t h ou gh , t h e best appr oach is t o u se w h ich ev er m odel y ou ar e com f or t able w it h an d w h at ev er w or k s f or y ou r dev elopm en t t eam an d st y le. [ 1 ] [ 1]

You m ight also com e acr oss r efer ences t o Model 1.5. This is sim ilar t o Model 1 ex cept t hat

m ost of t he logic is placed in t he JavaBean inst ead of t he JSP. See t he References sect ion at t h e en d of t h e book for addit ion al sou r ces of in for m at io n .

JSP versus Servlet

All JSPs ar e com piled in t o ser v let s an d t h en ex ecu t ed w it h in t h e ser v let con t ain er env ir onm ent . So, fr om a t echnical per spect iv e, JSPs and ser v let s ar e quit e sim ilar in capabilit ies an d w h at t h ey can be u sed f or .

The follow ing list co n t ain s som e k ey JSP adv an t ages ov er ser v let s:

•

JSPs ar e p r esen t at ion -cen t r ic an d offer a m or e n at u r al dev elopm en t par adigm t o Web p r esen t at ion d ev elop er s.

•

JSPs m ake it possible t o separat e present at ion from cont ent ( we discuss t his furt her in t he cont ex t of JSP t ags and t ag libraries in t he " Tag Libraries " sect ion) . This m eans a pr oj ect ' s pr esen t at ion dev elopm en t can pr oceed in par allel w it h t h at of t h e logic.

•

JSPs h elp in or gan izin g t h e ph y sical aspect of a Web applicat ion .

JSPs ar e com piled aut om at ically , t y pically as par t of t he st andar d deploy m ent pr ocess. Ser v let s, on t h e ot h er h an d, ar e a bit m or e m an u al in n at u r e an d r equ ir e a m an u al com pile st ep w henev er t he y ar e changed unless your ser ver t ools or developm ent envir onm ent t akes car e of t h is for y ou .

JSPs ar e oft en pr efer r ed ov er ser v let s if t he pr esent at ion is ex pect ed t o change fr equent ly . Ser v let s, on t he ot her hand, ar e pr efer r ed for m or e com plex logical t ask s, as t h ey ar e t y pically easier t o debu g du r in g t h e dev elopm en t pr ocess. Th is is pr im ar ily becau se y ou act u ally see t h e code for t h e ser v let y ou ar e ex ecu t in g. Becau se a JSP is au t om at ically com piled t o servlet code for you, t he code t hat is execut ed is in a different form t han t he code you or iginally pr ovided in t he JSP, w hich m akes JSPs a lit t le har der t o debug. How ever , if you ar e j u st h av in g t h e JSP do pr esen t at ion t ask s, t h is u su ally isn ' t a big pr oblem .

Th e ser v let v er su s JSP con sider at ion is n ot a lw ay s an eit h er-or scenar io in t he cont ex t of a specific soft w are syst em . I t is reasonable t o have a m ix of bot h t o achieve a balanced syst em . For ex am ple, y ou m ay w ant t o use a ser v let as a cont r oller such t hat t he r equest s get handled by t he ser v let . Once t he servlet has t aken care of t he request processing ( eit her direct ly or by working wit h ot her elem ent s of t he soft ware such as EJBs) , it could forward t he result s on t o a JSP t o display t h e r esu lt s t o t h e u ser .

Anatomy of a JSP A JSP consist s of t wo bas ic it em s: t em plat e dat a and JSP elem ent s. Tem plat e dat a provides t h e st at ic aspect s, an d JSP elem en t s ar e u sed f or t h e dy n am ic aspect s of a JSP.

Template Data

Tem plat e dat a r efer s t o t he st at ic HTML or XML cont ent of t he JSP. Alt hough it is essent ial for t he JSP pr esent at ion, it is r elat iv ely unint er est ing fr om a JSP pr ogr am m ing point of v iew .

Aside fr om t h e u su al su bst it u t ion s, su ch as t h ose based on qu ot in g an d escape sequ en ces, t h e t em plat e dat a is w r it t en v er bat im as par t of t h e JSP r espon se.

JSP Elements

JSP elem ent s r epr esent t he por t ion of t he JSP t hat get s t r anslat ed and com piled int o a ser vlet by t he JSP com piler . I n sy nt ax , JSP elem ent s ar e sim ilar t o HTML elem ent s in t hat t hey hav e a begin an d an en d t ag ( f or ex am ple, < B> bold t ext < / B> ).

Th er e are t h r ee t y pes of JSP elem en t s defin ed in t h e JSP specificat ion : dir ect iv e elem en t s, act ion elem en t s, an d scr ipt in g elem en t s.

Directive Elements

Direct ive elem ent s provide global inform at ion for t he t ranslat ion phase. These direct ives are gener al in nat ur e, t hat is, not r elat ed t o a specific r equest and t hus do not dir ect ly im pact t he ou t pu t t o t h e clien t .

Dir ect iv e elem ent s t ak e t he follow ing for m :

An ex am ple of a d ir ect iv e elem ent follow s:

A page dir ect iv e an d it s at t r ibu t es pr ov ide a con v en ien t m ech an ism for in st r u ct in g t h e env ir onm ent on t he configur at ion of v ar ious t hings, such as libr ar ies t o be im por t ed, cont ent t y pe of t he page, buffer size, and so on. Wit h t he except ion of t he im por t at t r ibut e, ot her page at t r ibu t es can on ly be def in ed on ce in t h e JSP.

Action Elements

Un lik e dir ect iv e elem en t s, act ion elem en t s com e in t o play du r in g t h e r equ est -pr ocessin g phase. JSP act ions elem e n t s ar e w r it t en u sin g an XML sy n t ax in on e of t h e f ollow in g t w o for m at s:

or

body

The idea is t o est ablish an associat ion bet w een t ags and have a " t ag handler " defined for each t ag , w h ich g et s in v ok ed t o h an d le t h e t ag w h en t h e t ag is en cou n t er ed . Tag h an d ler s ar e essen t ially pieces of code, f or ex am ple:

Act ion s pr efix ed w it h " j sp" ar e st an dar d act ion s. Som e st an dar d act ion s ar e

•

I n clu d e r esp on ses sen t b y ot h er JSPs

•

For w ar d r eq u est s t o ot h er s

•

Qu er y an d u p d at e p r op er t ies of a Jav aBean r esid in g on t h e ser v er

Act ion s m ay cr eat e obj ect s t h at ar e m ade av ailable t o scr ipt in g elem en t s v ia cer t ain v ar iables.

Scripting Elements

Scr ipt ing elem ent s br ing ev er y t hing t oget her in a JSP. These elem ent s can be declar at ions used for defining v ar iables and m et hods, block s of code called scr ipt let s, and ex pr essions for ev alu at ion du r in g r equ est pr ocessin g.

Declarations

Declar at io ns define v ar iables and m et hods. The sy nt ax for declar at ions is < % ! Declar at ion % > w h er e declaration can be a v ar iable or a fu n ct ion , for ex am ple:

Expressions

Ex p r ession s ar e ev alu at ed d u r in g t h e r eq u est -pr ocessing p hase of t he JSP, and t he result s ar e con v er t ed t o a st r in g an d in t er m ix ed w it h t h e t em plat e dat a. Th e r esu lt is placed in t h e sam e p lace w h er e t h e ex p r ession w as locat ed in t h e JSP p ag e.

The sy nt ax of ex pr essions is < % = Som e ex pr ession % > .

I n t he XML sy nt ax , t h e sam e is ex p r essed as:

Some expression

For ex am ple:

Login Count:

Scriptlets

A scr ipt let is a m ini " scr ipt " of code em bedded w it hin t he JSP. I t can cont ain, am ong ot her t hings, declarat ion of variables and m et hods, expressions, and st at em ent s. Like expressions, scr ipt let s get ex ecut ed at r equest -pr ocessing t im e, and any r esult ing out put is placed in t he r esp on se ob j ect .

The sy nt ax for declar ing scr ipt let s is < % Jav a Code % > .

The XML equiv alent is

Java Code

For ex am ple:

:

Congrats, you win!!!

Sorry, try again.

:

Objects Accessible to a JSP Implicitly

Each JSP has acce ss t o som e obj ect s w it h ou t ex plicit ly declar in g t h em in t h e JSP. Th ese obj ect s ar e cr eat ed by t he cont ainer for use w it hin JSPs and can be assum ed t o exist by t he JSP dev eloper s.

These im plicit obj ect s ar e

•

r equest : Repr esen t s t h e in com in g r equ est t h at in it iat ed t h e p r ocessin g

•

response: Rep r esen t s t h e r esp on se t o t h e cu r r en t r eq u est

•

pageCont ext : Pr ov id es access t o p ag e at t r ib u t es an d con v en ien ce m et h od s

•

session : Session obj ect for t h e cu r r en t clien t

•

applicat ion: I d en t if ies t h e associat ed Se r vle t Cont e x t

•

out : Obj ect f or w r it in g t o t h e ou t pu t st r eam

•

config: I den t ifies t h e associat ed ser v let con fig for t h e JSP

•

page: Sim ilar t o this in t he cont ex t of t he cur r ent JSP

•

except ion: I den t if ies t h e ex cept ion t h at led t o t h e er r or page

Tag Libraries On e of t h e ch allen g es in m eet ing t he obj ect iv es of t he JSP t echnology is t o m inim ize t he pr ogr am m in g logic com plex it y t o w h ich con t en t dev eloper s ar e ex posed.

The JSP 1. 1 specificat ion int r oduced a new capabilit y for cr eat ing cust om JSP t ag libr ar ies, w h ich allow for t h e r edu ct ion of com plex it y . The idea is for t he dev eloper t o pr ov ide sim ple and easy t o use cust om t ags t hat can be used by t he cont ent developers t o invoke com plex logic.

A Tag Handler Class

A cu st om t ag is com posed of a t ag h an dler class. Th e t ag h an dler class is r espon sible f or t ellin g t h e sy st em w h at sh ou ld be don e w h en a specif ic t ag is en cou n t er ed. Th e class f ile con t ain s t h e act u al Jav a code t h at is ex ecu t ed du r in g t h e r equ est .

Tags can opt ion ally h av e on e or m or e at t r ibu t es an d a body , bu t n eit h er is r equ ir e d. The sim plest t ag is one wit hout a body or at t ribut es; t he m ost com plex t ag has a body as well as on e or m or e at t r ibu t es.

Th e f ollow in g list sh ow s ex am p les of a t ag w it h ou t a b od y , a t ag w it h ou t a b od y b u t w it h at t r ibu t es, an d a t ag w it h at t r ibu t es an d a body :

• • • • •

A t ag w it h ou t a body :

A t ag w it h ou t a b od y b u t w it h an at t r ib u t e:

A t ag w it h a b od y an d an at t r ib u t e:

•

•

This is the body. It can contain actions, directives and other things

•

For t ags w it hout a body, t he t ag handler class m ust im plem ent t he doSt art Tag m et hod. Tags w it hout a body ar e useful w hen you j ust w ant r elat ively fixed cont ent ( t hat is, som et hing t hat is not very cust om izable from one reference in t he t ag t o anot her) accessible t o t he cont ent dev eloper .

At t r ibut es can be used w it h t ags w it hout a body t o facilit at e cust om izat ion of t he r esult s. I n such cases, t he t ag handler class m ust also im plem ent a set t er m et hod cor r esponding t o t he at t r ibut e nam e and be pr efixed w it h " set " . This per m it s t he set t ing of t he r elevant at t r ibut e( s) pr ior t o t h e call t o t h e doSt art Tag m et h od, t h er eby allow in g differ en t r esu lt s based on t h e v alu e of t h e at t r ibu t es.

For t ags w it h a body , t he t ag handler class m ust also im plem ent t he doEndTa g m et hod. The doEndTag gener ally does not hing m or e t han inst r uct t he sy st em t o cont inue on; how ev er , it is possible f or it t o t ak e ot h er act ion s, su ch as abor t t h e ex ecu t ion of t h e JSP.

Th e code ex am ple in

Fi g u r e 1 1 - 1

sh ow s a t ag h an d ler class f or a t ag w it h ou t a b od y .

Figu r e 1 1 - 1 An exam ple of a sim ple t ag handler class

import java.io.*; import javax.servlet.jsp.*; import javax.servlet.jsp.tagext.*; public class MyTag extends TagSupport { public int doStartTag() { try { JspWriter out = pageContext.getOut(); out.print("A simple tag example"); } catch IOException e) { //handle exception } return (SKIP_BODY); } }

A Tag Library Descriptor

Tags ar e or ganized int o t ag libr ar ies. The t ag libr ar y descr ipt or ( . t ld) file cont ains t he list of t ag n am es an d n am es of associat ed t ag h an d ler classes.

A t ag libr ar y descr ipt or ex am ple is sh ow n in

Fi g u r e 1 1 - 2 .

Figu r e 1 1 - 2 Ta g libra ry descript or ex a m ple



1.1 1.2 example

BlankLine com.taglib.homedirect.BlankLine EMPTY Inserts a blank line



Fi g u r e 1 1 - 3

sh ow s h ow a cu st om t ag is u sed f r om w it h in a JSP.

Figu r e 1 1 - 3 Using a cust om t ag from w it hin a JSP