CONTENTS Preface xe troduction 4. AN OVERVIEW OF OBJECT: ORIENTED SYSTEMS DEVELOPMENT 4.4 Introduction 1.2 Two Orthogonal Views of the Software 13 Object-Oriented Systems Devalopment Methodology 1.4 Why an Object Orientation? 1.5 Overview of the Unified Approach 1.8 Organization of This Book 17 Summary 2. OBJECT BASICS 21 Introduction ‘2.2 An Object-Oriented Philosophy 23 Objects: 24 Objects: Are Grouped in Classes J 2.5 Attributes: Object State and 2.7 Objects Respond to Motsagos 2.8 Encapaulation and tnformation Hiding 2.9 Class Hierarchy 2.9.1 Inheritance 2.9.2 Multiple Inberitaisoe 2.10 Polymorphism 2.11 Object Relationships and Associations QL Consumer-Producer Association 2.42 Aggragations and Object ‘Containment 2.19 Case Study; A Payroll Program 2.13.1 Steuctured Approach 213.2 The Object-Oriented Approach at] 16 " 8 Tyviii comments: 2.14 Advanced Topics 52 4.3 Rumbaugh ét ais Object 2.141 Object and Tentity R Modeiog Teteias = 2.14.2 Static ind Dynamic Sl ie Oli Ho * Binding M 4.32 The OMT Dynamic Model 63 ZA4S Object Pexritence a 4.3.3 The OMT Functional Model’ 64 24 Meta-Clasees i444 The Booch Methodology 65 245 Summary 3s 4.4.1 The Macro Development “ 3, OBJECT-ORIENTED SYSTEMS: wastrel ne DEVELOPMENT LIFE CYCLE » Tie Mian Beveloprsant a aan 2. 4.5 The Jacobson et al. 3.2 The Soltware Development metnodotogies é oe 2 4.5.1 Use Cases 3 a8 Ruling MijhCasity SoRware 42 45.2. Object-Oriented Software a eet Oriented ooere Engineering: Objectory ” Development: so-Case 4.53 Object-Oriented Business peas, gir ; % Engineering v 3.4.1 Object-Oriented Analysig— n Use-Case Driven ee SRE 5, 4.6.1 Generative and 3.2 Object-Oriented Design a7 Nonpebisiitn Paloma n 34.3 Prototyping “7 4.62 Panes Template 8 3.4.4 Implementation; Component- 4.6.3 Antipatierns Bilet Decloorent 2 4.64 Capturing Panems 6 345 incremental Testing a <7 aianete - 25 Feaieabilty, ” 4.8 The Unified Approach ® 3.6 Summary Sa 48-1 Object-Oriented Analysis 79 48.2 Object-Ciemed Design 80 4.3.3 lerative Development and ‘Continuous Testing, aa Te S| 43.4: Modeling Bused on the . Unified Modeling Language 80 Methodology, Modeling, and 48,5 The UA Proposed Unilied Moveting Language Repository al 4.8.6 The Layered Approach to 4. OBJECT-ORIENTED METHODOLOGIES i Sina Dereeanen 5 - Toward 44.01 The Business Layer Unification—Too Many 486.2 The User Interface (View) Mothodologies ot dayer " 4.2 Survey of Some of the Object- 4803 The Access Layer et Oriented Methodologies 62 4.9 Summary et5. UNIFIED MODELING LANGUAGE 49 5.1 Introduetion, 5.2 Static and Dynamic Models 5.2.1 Static Model 52:2 Dynamic Model 5.3 Why Modeling? 5.4 Introduction to tha Unified Modeling Language 5.5 UML Diagrams 5.6 UML Class Diagram 5.6.1 Class Notation; Static Structure 4.62 Object Diagram 3.63 Class Interface Notation 3.64 Binary Association Notation 5.6.5 Association Role 5.6.6 Qualifier 5.6.7 Multiplicity 4.6.8 OR Association $.69 Association Class 5.610 N-Ary Association 5.6.11 Aggregation arid ‘Composition 5.6.12 Generalization 5:7 Use-Gase Diagram 5.8 UML Dynamic Modeling 5.8.1 UML Interaction Diagtinis SAL UML Sequence Dizgrata $12 UME Collaboration Diagram $3.2 UML Statechart Diagram $8.3 UML Activity Diagram 58.4 Implemeiiation Diagrams SAL Component Diagram 5.84.2 Deployment Diagram 5.9 Model Management: Packages and Model Grganization 5.10 UML Extensibility 5.10.1 Model Constraints and Comments 99. 90 90 a 92 cc Ee 4 38 95 98. S38 £83435 85 S 8 rot toa Tos: 2 conTenTs ie 5.102 Note $.10:3 Steeeotype 5.11 UML Mate-Modat 5.12 Summary ur ur 17 ty Object-Oriented Analysis: Use-Case Driven 6. OBJECT-ORIENTED ANALYSIS: PROCESS: IDENTIFYING USE CASES 6.41 Introduction 6.2 Why Analysis Is 8 Difficult Activity 6.3 Business Object Analysis: Understanding the Business Layer 6.4 Use-Case Driven Object- Orlented Analysis: The Unified Approach 8.5 Business Process Modeling 6.8 Use-Case Mote! 6.6.1 Use Cases under the Microscope 6.6.2 Uses and Extends Associations 66,3 Identifying the Actors 6:64 Guidelines for Finding Use Cases 6.63. How Detiled Must a Use (Case Be? When to Stop Decomposing and When to Continue 6.66 Dividing Use Cases into Packages 6.6.7 Naming a Use Case Ww 128 i 10 136 iW iatCONTENTS 6.7 Developing Effective: Documentation 6.7.1 Organizing Conventions for Documentation 6.7.2 Guidelines for Developing ive Documentation 6.8 Case Study! Analyzing the Viatiet Bank ATM—The Use-Case Driven Process 6.8.1 Background 6.8.2 Identifying Actors and Use Cases for the ViaNet Bank ATM System 6.83 The ViuNet Bank ATM Systems’ Packages 8.9 Summary 7. OBJECT ANALYSIS: CLASSIFICATION: 7.1 Introduction 7.2 Claasitications Theory 7.3 Approaches for Identitying Classes 7.4 Noun Phrase Approach 74.1 Identifying Tentative Classes 7.42 Selecting Classes from the Relevant and Fuzzy : Categories 7AZ The ViaNet Bank ATM System: Identifying Classes by Using Noun Phrase Approach 7.44 Initial List of Noun Phrases: Candidate Classes TAS Reviewing the Redundamt Classes and Building » Common Vocabulary 74,6 Reviewing the Classes Containing Adjectives iI 1st 132 is 134 13 159 7.4.7 Reviewing the Possible Attribites TAB Reviewing the Class Purpose 7.5 Common Class Patterns Approach 7.8.1 The ViaNet Bank ATM System: Identifying Clastes by Using Common Class Patterns 77.8 Usi-Case Driven Approach: Behaviors thraugh Sequences Collaboration Modeling 7.6.1 Implementation of Scenarios 7.6.2 The ViaNet Bank ATM System: Decomposing & Use-Case Scenario with a Sequence Diagram: Object Behavior Analysis, 7.7 Classes, Responsibilities, and Collaborators. 7.7.1 Classes, Responsiblties, and Collaborators Process 7.42 ‘The ViaNet Bank ATM System: Identifying Clisses by Using Classes, Responsibilities, and Collaborutor 7.8 Naming Classes 7.0 Summary 8. IDENTIFYING OBJECT RELATIONSHIPS, ATTRIBUTES, AND METHODS: Identifying Associations 8.2.2 Guidelines for Identifying Associations $.2.3 Common Association Patlens 160 16h 183 m Ww m4 Ww vt 7% ne8.24 Eliminate Unnecessary Associations 8.3 Supor-Sub Class Relationships 8.3.1 Guidelines for idemifying Super-Sub Rehitionship, a ‘Generalization 8.4 A-Partot Ralationships— ‘Aggregation Si] A-Pant-of Relatioaship Patterns 8.5 Case Study: Relationship Analysis for the Wiaiet Bank ATM System &S.1 Identifying Classes" Relationships 85.2 Developing a UML Class Diagram Based on the Use-Case Analysis 8.5.3 Defining Avsociation Relationships §.5.4 Defining Super-Sub Relatienships 8.5.5 Mentifying the Aggregation’ a-Pur-af Relationstup 86 Glass Responsibility; | identifying Attributes and Methods 8.7 Class Responsibility: Defining Attributes by Analyzing Use ‘Cases and Other UML Diagrams $7.1 Guidelines. for Defining. Auributes 8.8 Defining Attributes for ViaNet Bank Objects 2.8.1 Defining Attributes for the BankClient Class $8.2 Defining Attributes for the Account Class * 8.8.3 Defining Auributes for the Transaction Class conrenrs xd 8.84 Defining Attributes for the 18 ATMMachine Class 1 8.9 Object Responsibility: Methods rat and Messages wt 8.6.1 Defining Methods by Analyzing UML Diagrams 58H and-Use Cases 192 8.10 Defining Methods for ViaNet Be Bank Objects 12 8.10.1 Defining Account Class i Operations 2 ‘8.10.2 Defining BangClient ims Class Operations ios $10.3 Defining Checking Account i ‘Cluss Operations 193 8.11 Summary 1b tad ————— ——S ns F Ohject-Oriented Design 16 x 9, THE OBJECT-ORIENTED DESIGN it PROCESS AND DESIGN AXIOMS 197 4.1 Introduction 199 29.2 The Object-Oriented Design ied Process 200) +9. Object-Oriented Design Axioms 202 )84 Corollaries 203 a 94.1 Corollary 1, Unouupled Design with Less my Information Content 208 O41.) Coupting Se] 190 94.1.2 Cohesion 206 942 Corollary 2 Single Purpose 206 190 9.4.3 Corollary 3. Large Nuruber of Simpler Classes, 190 Reusability 206 9.4.4 Corollary 4. Strong Mapping 207 ia 9.4.5 Corollary 3. Standardization 208ARID coments 94.6 Corollary 6. Designing with Inhentance 1 Achieving Multiple Inheritance in @ Single Iniieritance System 9.4.6.2 Avoiding Inheriting Inapproprice Behaviors 95 Design Patterns 9.6 Summary a 10. DESIGNING CLASSES 10.1 Introduction 10.2 The Object-Oriented Design Philosophy 10,8 UML Object Constraint Language 10.4 Designing Classes: ‘The Process 40.5 Class Visibility: Designing ‘Woll-Defined Public, Private, and Protected Protocols 10.5.1 Private and Protected Proiece! Layers: intemal 10.5.2 Public Protocol Layer, External >y 10.6 Designing Classes: Refining Attributes. 10.6.1 Attribute Types 102° UML Auribute Presentation 10.7 Refining Attributes for the Viahet Bank Objects: 10.7.1 Refining Auributes for the BankClient Class 107.2 Refining Attributes for the Account Class 10-73 Refining Auributes for the Transsetion Class Problem 10,1 2 m 2 2 2B 22 a 24 10.7.4 Refining Atiributes for the ATMMachine Clase 107.5 Refining Attributes for the Checking Account Class 10.7.6 Refining Auributes for the SavingsAccount Class »» 10.8 Designing Methods and 5 10.8.1 Design tases: Avoiding Design Pitfalls 1082 UML Operation Presentation 10.8 Designing Methods tor the ‘Viatet Bank Objects 10.91 BankClient Class VetityPaxsword Method 10.9.2 Account Class Deposit Method 10.9.3 Account Class Withdraw Method 10.9.4 Account Class ‘Create Transaction. Method 10.9.5 Checking Account Chiss Withdraw Method 10.9.6 ATMMachine Class ‘Operations. 10.10 Packages and Managing Classes 10,11 Summary 41. ACCESS LAYER: OBJECT ‘STORAGE AND OBJECT INTEROPERABILITY V1.1 Introduction 41.2 Object Store nnd Persistence: An Overview 24 2 20 230 230 aa7 27conrents xiii 11.9 Database Management 11.8 Object-Relational Systems: Systems: BD ‘The Practical World 285 113.1 Database: Views 240 11.8.1 Object-Relation Mapping. 256 113.2 Database Models aan 182 Table-Clans Mapping 237 11.32.) Hierarchical Model 240 BN Tabs: iltips Clpssos a Mapping 2H Deane Tp: ae 11.8.4 Table-Inherlted Classes 1132.3 (Relational Moitet me Mapping 258 14.33 Database Interface m2 1 Tables-toherited Classes. L133. Devibase Schein doi Meppine = Data Definition Language 247 TESS oe Se Lae favigation 332 furetpmadacion poe 11.9 Multidatabase Systems 260 Cupabilisies ET 11.9.1 Open Phatabase Connectivity: 11.4 Logical and Physical Database Mulitnbise’Appileu Cupinestion and: Kanone Ae Programming Interfuces. 262 11.10 Designing Access Layer 1141 Shareability and Clesses ea i Tene: ” 1110.1 The Preicess 265 1142 Concurrency Poligy 3:91: een Rasp Dehlanteg the 11.5 Distributed Databases and ‘Access Layer for the ViaNlet Gllent-Servar Computing 245 ‘Bank ATM 268 HS... Whats Client-Server 1.11.1 Creating an Access ‘Computing? m5 ‘Class for the 115.2 Distributed and PhnkC Hien Cans 10 Cooperative Processing 24g 11.12 Summary ms 11.6 Distributed Objects Computing: 12. VIEW LAYER: DESIGNING The Next Generation of Client- INTERFACE OBJECTS 71 Server Computing 250 12.1 Introduction 281 11.6.1 Common Object Request 12.2 User Intertace Design as 0 Broker Architecture 3 Creative Process 28h 11.62 Microsoft's 12.3 Designing View Layer Classen ze ActiveX/DCOM 282 12.4 Macro-Level Process: ‘11.7 Object-Oriented Database identifying View Classes by Management Systems: Analyzing Use Cases. 288 The Pure World 252 12.5 Micro-Level Process 27 17. Object-Oriented Datinbases 12.5.1 Ul Design Rule 1. versus Traditional Making the Interface Databases 284 Simple 236xiv contents 12.5.2 Ul Design Rule 2 Making the Interface ‘Transparent and Nutural 12.5.8 Ul Design Rale 3. Allowing Users to Be in Control of the: Software FRSA Make the Interfoce Forgiving FLAA2 Make the interface Vieuwt 125.43 Provide fmomediate Feedback 12.5.3:4, Avoid Modes ILERS Make the laterface Consiszent 12.8 Tho Purpose of a View Layer Interface 12.6.1 Guidelines for Designing Forme sind Dats Entry Windows: 12.6.2 Guidelines for Designing Dialog Boxes and Error Messages 12.6.3 Guidelines for the Command Buttons. Layout 12.64 Guidelines for Designing Application Windows 12.6.5 Guidelines for Using. Colors 12.65 Guidelines for Using Fonts 12.7 Prototyping the User Interface 12.8 Case Study: Designing User Interface for the ViaNet Bank aT 2B. The View Layer Macro Process 12.8.2 The View Layer Micro Process 12.8.3 The BankClientAccessUT Imerface Object 12.8.4 The MainUl Object Interface =e 12.8.5 The AccountTransactionUT Interface Object cr] 12.8.6, ‘The CheckingAccountlT 200 and SavingsAccoumUT Interface Objects mI aa .7 Defining the Interface 29 Behavior a FASTIN hdenuifving Evehee ond a1 Actions for the BankCHentAc- ie cerstit Interface Olyert 3S F2RB7E blemiifying Everety canch ion ‘Actions for the Maint =a Interfere Object 3 i 282 bdentifying Events cd * Actions jor the Savings Account} Interface Object 314 (2.874 Inentifiing Events and. = ‘Adifons for the Acvount: Transactional! Interface Object us Ez) 12.9 Summary 317 309 Software Quality 43, SOFTWARE QUALITY ASSURANCE a8 19,1 Introduction Rs eH 13.2 Quality Assurance Tests 26 13,3 Testing Strategies: a6 13.3.1 Black Box Testing 8 308 133.2 White Box Teiting 8 13:3.3 Top-Down Testing m9 305 13.3.4 Bouom-Up Testing 0 «13.4 Impact of Object Orientation 308 ‘on Testing 320 134.1. Impact of Inheritance in 308 Testing 3INTRODUCTION The objective of Part 1 is 10 provide an overview of object-oriented systems developmesit and why we should study it. In this part, we alse look at ob- ject basics and the systems development lite cycle. Part I consists of Chap- ters , and 3,An Overview of Object- Oriented Systems Development ‘Chapter Objectives should be able bo define and werstanl = The object-aricnied phikioophy and why we need 10 meaty i ‘= The unified speach: Software development ix dynamiciand always-undergoing major change The methods we will ose in the furure no doubt will differ significantly from those cur- rently im practice, We can anticipate which methods and tools are going to suc~ ‘bat we cannot predict the future, Factors other than just technical superior- ay will likely determine which concepts prevail. Today @ vast umber of ioals and methodologies are available for systems de~ velopment. Systems development refers to all activitics that go into. producing an isformation ¢ystems solution. Syiters development activities consist of systems ssalysis, modeling, design, implementation, testing, and maintenunce. A software development methodology is 0 series of processes that, if followed, can lead 10 the evelopment of an application. The soltware processes describe how the work is to be carried out to achieve the original goal based on the system requirements Furthermore, cach process consists of a number of steps and nutes that should be performed during developmicnt, The software development process will continue fo.exist a¢ long as the develapmeat system fs in operation “This chapter provides an overview of objectoriented sysienis development and discusses why Wwe should stady. it, Furthermore, we stady the unified approach, sehich is the methodology used in this book for learning about object-orkentad sys emis development,@ Paar ONE: inTRCbUCTION 1.2 TWO ORTHOGONAL VIEWS OF THE SOFTWARE ‘Object-oriented systems developineint methods differ from traditional development techniques in that the traditional techniques view software as. x collection of pr- grams (or functions) and isolated data. What is a program? Niklaus Wirth (8). the ineventor of Pascal, suis it up eloquently in hls book entitled, interestingly enough, Algorithms + Data Structures ™ Programs. "A software system is a stt of mech- anisms for performing certain action on certain dita" ‘This mons that there are two diferent, yet complementary ways. to ‘lew soft- ‘wire constriction: We can focus primarily on the functions or peimarily on the data, The Heart of the distinction between triditional system development method logics and newer object-oriented methodologies lies in their primary foeus, where the traditional approach focuses on the functions of the aystem-— What is it do- ing?—object-oriented systems development cemters on the object, which combines data and functionality. As we will éee, this seemingly simple shift in focus radi- cally changes the process of software development, 1.3 OBJECT-ORIENTED SYSTEMS DEVELOPMENT METHODOLOGY (Object-ariented development offers a different model from the traditional software development approach, which is based on functions and procedures. In simplificd terms, object-oriented systems development is a way’ t0 develop software by. build ing self-contained modules or objects thut can be easily replaced, modified, and reuéed. Furthermore, it encourages a view of the world as-a sytem of cooperative and collaborating objects. In an object-oriented eavironmem, scfiware ts a collec tion of discrete objects that encapsulate their darn as well ws the functionality 10 model real-world “objects" An object orientation yields important benefits to the practice of software ‘construction. Each object has attributes (data) and methods {functions}. Objects are grouped into classe4: in object-oriented terms, we discover anid describe the classes involved in the problem dornain, In.an object-oriented sytem, everything is an object ancl each object ts réspon- sible for itself. For example, every Windows application needs Windows objects that can open themselves on screcn and either display something or accept input. A Windewes object is responsible for things like opening, sizing, and closing itsalf, Frequently, when a window displays something, that something also is an object (a chart, for example), A-chart object is respomsible for things like maintaining its data and labels and even for drawing itself ‘The object-oriented environment emphasizes its cooperative philosophy by allocating tks among the objécts of the applications. In other words, rather than writing a lot of code-to do all the things that have to be done, you tend to create a Jol of helpers that take on an active role, spirit, and that form a com- munity whose interactions become the application, Instead of saying, “System, compute the payroll of this employee,” you tell the employee object, “compute your payroll.” This has.a powerful effect on the way. we approach software develapmicisGHAPTER 1; AN OVERVIEW OF OSJECT-ORIEMTED SYSTEMS DEVELOPMENT 5 1.4 WHY AN OBJECT ORIENTATION? Object-oriented methods enable us to create Set of objects that work together syn- ergistically to produce software that better model their pfalem domains than sim- ilar xystems produced by traditional tgehniques. ‘The systems are easier to adapt to changing requirements, easier to maintain, more robust, and promote greater de- sign and code fetise; Object-oriented development allows us to create modules of functionality, Once objects-are defined, it can be taken for granted that they will perform their desired functions and you can seal theri olf in your mind like black boxes. Your attention as a programmer shifts to what they do rather than how they. do it, Here are some reasans why object orientation works (3-7] * Higher tevel of abstraction. The top-down approach supports abstraction at the, function level: The object-oriented approsch supports abstraction at the object level, Since abjects encapsulate both dota (attributes) and functions: (methods), they’ work at a higher level of abstraction, The devélopment catr proceed at the object level and ignore the rest of the system for as long-as necessary. This makes designing. coding, testing, and maintaining the system much simpler. * Seamless rransition among different phases of softwere development, The traul- onal approach to software: development requires different styles and method- ologies for each step of the process, Moving from onc phase to another requires. a complex transition of perspective between models that almost ean be in dif ferent worlds. This transition not only can slaw the development process fut also increases the sive of the projéct and the chance for errors introduced in moving from one language to another. The object-oriented approach, on the other hand, cescntially uses the same Fanguage to talk about analysis, design, programminig, and database design. This seamless approach reduces the level of complexity and redundancy and makes for clearer, mie robust system development. + Encouragement of good programming techniques, A class in an object-oriented system carefully delineates between its interface (specifications of whar the class cnn do) and the implementation. of that interface (how the class does what it does). ‘The routines and attributes: within a class are held together tightly. In a properly designed system, the classes will be grouped into subsystems. but re- main independent: therefore, changing one class his tio impact on other classes, and 0, the impact is minimized. However, the object-oriented approach is nat a panacea; nothing is magical bere that will promote perfect design or perfect code: But, by rising the level of abstraction from the function level to the ob- ject level and by focusing on the real-world aspects of the system, the abject- ‘oriented method tends to promote clearer designs, which are easier to. imple- ment, and provides for better overall communication, Using object-oriented language is not strictly necessary to achieve the benefits of an object orientation However, ait objectioriented language such as C++, Smalltalk, or Java adds support for object-oriented design and makes it easier to pradace more modular and reusable code via the concept of class and inheritance [5], '* Promotion of reusability, Objects are reusable because they are modeled directly, out of @tealsworld problem domain. Each object stands by itielf or within & small circle of peers (other objects). Within this framework, the class does not1 PART ONE: INTROQUCTION ‘coocem itself with the rest of the system or how it is going to be! wied: wi particular system, This means that classes are designed generically, with reuse fas 6 constant bockground geal. Furthermore, the object orientation udds-inficel- tance, which is.a.powerful technique that allows classes 10 be built from each ‘other, and therefore, only differences and enhancements between the classes need fo be designed and coded. All the previous functionality remains abd cat be reused without change. 1.5 OVERVIEW OF THE UNIFIED APPROACH ‘This book is organized around the unified wpprodcti for a beter understanding of object-oriented concepts and system development. The wnified approwch (LIA) is & methodology For safware development that is proposed by the author, and used in this book, The UA, based on methodologies. by Booch, Rumbaugh, asd Jacobsori, ities to combine the beet practices, processes, and guidelines:along with the Object Management Group's unified modeling language. The wniffed modeling language (UML) is a set of notations and conventions used to describe and model an-appli- cation, However, the UML does not specify a methodology or what steps. to follow ta develop an application; that would be the tisk of the UA. Figure !—1 depicts the essence of the unified spprocch. The heart of the LIA is Jacobuen’s use case. The: use ease represents a typical interaction between a user and a computer system ter capture the users" goals and needs, 10 its simplest usage, you caprure # use case by talking to typical users and discussing the various ways they might want to use the. system, The use cases are entered into all ather activities of the UA. ‘The main advantage of an object-ontented system is that the class tree fe-dy- namic and can grow Your function as a developer in an object-ori¢nted. environ ment is to foster the growth of the class tree by defining new, more specialized classes to perform the tasks your applications require. Aber yéout first few projects, you will accumulate repository or class library of your own, one that the operations your-apptications most often require. At that point, creating adli- tional applications will require no more than assembling classes from the class li- brary. Additionally, applying lessons learned from past developmental effirts te fu- ture projects will improve the quality of the produet and redoge the cast and development time. Thiv book uses a layertd'wrchitectire to develop applications. Layered wrchi- Iecture is an approach to software development thas ulkws ts fo creute objects that represeht tangible elements of the business independent of low they are repre- sented to the nser through an interface or physically stored ina database, The lay- ered approach consists of view or user ioterfixce, business, ancl access layers. This approach reduces the interdependence of the user interface, datubase access, and ‘business control: therefore. it allows for a mere robust und flexible systera 1.6 ORGANIZATION OF THIS BOOK Chapter 2 introduces the basics of thy object-oriented approach and why we aliould study it. Furthermae, we learn that the main thrust of ihe object-oriented approach7, Beg he acres ayer (Cage 19 Anal 1 erty ware Chae Sovatarealie ng “The Uniting approach rtd tings,'B PART ONE: InTROOUCTION is to: provide a set of objects that closely reflects the underlying application. For example, the user who needs to develop a financial application could develop it in ‘a finaneiul language with considerably less difficulty, An object-oriented approach allows the base concepts of the language be extended to include ideas closer to those of its application, You cun define a new data type (object) in terms of an ex~ lating data type until i€appears that the language directly smpports the primitives of the application. The real advantage of using an object-oriented approach is that you can build om what you already have. Chapter # explains the object-oriented system development life cycle (SDLCI, “he essence of the software proctss is the transformation of useds’ needs in the ap: plication domain into a software solution that is executed in the implementation domain, The concept of use case or st of scendrias can be a valuable tool for un- derstanding the users’ needs. We will learn that an gbject-oriemted approach ré- quires 4 moré rigorows process up front to do things tight, We need to spend more time gathering requirements, developing x requirements model, developing an analysis model, then turning that into the design model. This chapter concludes Past T (Introduction) of the book. ‘Chapter 4 is the first chapter of Part Il (Methodology, Modeling. and Unified Modeling Language). Chapter 4 looks at the current tread in object-oriented methodologies, which is toward combining the best aspects of today's most pop- ular methods: We also take a closer look at the unified approach, Chapter § describes the unified modeling language in detail, The UML merges the best of the notations developed by the so-called ire amigos—Booch, Rum- ‘bough. sind Jucobson—in their atterypt to unify their modeling efforts. The unified modeling language originally: was. called the unified metiad (UM). However, the mmgthodologies that Were-an integral part of the Booch, Rumbaugh, and Jacobson ‘thethods were separated from the notation; and the-unification efforts of Booch, Jacobson, and Rumbaugh eventuully focused more on the graphical modeling lan- ‘guage and its semantics and less om the underlying process and methodology. They som up the reason for the name as follows: ‘The UML i: ienended 19 be-a universal languinge for modeling systersa; meaning that it can enptess models of ray different kinds and purposes, just as a progfammitig Len- guage or & rumural language can be used in many different ways, This. 2 single wntves- 4! process for all styles of developniens did mat seein possible or even desirable: what warks for a shrink-wrapped software project is probably wrong for a oxt~ota kd lob ally: distbuted, hurmas-cricical family’ of systems. However, the UML can be sed to express the artifacts of all of theie different provesses, aumely, the models that are peo- diced. Our move 10 the UML dock not mean that we are ignoring the isses uf process, Indized, the UML assumes 3 process thas is wee case-driven, atchitecture-cemered, iter: ative aad incremental. It it our obéervation that the details of this general development process mast be adapted to the panicular development culture or apptication domain of a specific eeganizition, We are also working on process issues, but xt have chosen to separate the modeling Language from the process. By risking the mnodebog Innguage asd fis jrocess neurly independent, we therefare give users and other methodologists con siderable degrees of freedom 16 craft a specific geocess yet sill we a common languageCHAPTER 7: AN OVERVIEW OF GSUECTORIENTED SYSTEMS DEVELOPMENT. ‘of mapression. This is pot unlike blueprints for buildings: there i a commoely under stood language for blueprints, bat there are a number of different ways to build. de- ponding apon the nature of whet is being built and who is doing he building, This is why ‘we say that the UML is exsenially the langusge of blueprints for software. (2, p. $] The UML. has decome the standard notation for object-oriented modeling sys~ tems. Iris an evolving notation that is sil under development. Chapter $ concludes this part of the book, Chapter 6 i the first chapler of Pan 11] (Object-Oriented Analysis: Use-Case Dniven). The gaa! of object-oriented is is to first understand the doniain of the problem and the system's responsi by understanding how the ssers use of wall use the system, The main task of the analysis is t¢ capture 2 complete, un- emibiguous, tind comsistent picture of the requitements of the: system. This is ac- complished by constructing seversl models of the system. These models concen- ‘wate on describing whut the wystem does rather than how it does it, Separating the behavior of a system from the way it is implemented requires viewing the eystem front the users’ perspective rather than that of tle machine. This analysis is forwsed 0 the domain of the problem and concersied with externally visible behavior [1]. ‘Other activities of objoct-oriemed analysis are to identify the objects that make. ip he system, their behaviors, and their relmionships. Chapter 6 explains the object- oniented analysis process und provides a detailed discussion of use-case driven objectoriemted anulysis, The use case i a typical interaction between a uset and © computer system utilized to capture users’ goals und needs. The nse-case model represents the users’ view of the system or the users’ rived. In its simplest usage, you coptute a use case by tilking to typical users and discussing the variows things they might want to do with the system. The heart of the VIA ii the Iuicobsan’s use site, The use cases are a part of all other activities of the UA (see Figure: 11) The main activitics of the object-oriented analysis are to identify classes in the systern, Finding classes is one of the hardest activities in the analysis. There is no eosh @.thing as the perfect class-summcture of the right set of objects. Nevertheless, several technigues. such as the use-case driven approach or the noun phrase and other classification methods, can offer us‘guidelines and general rules for idemi- fying the elusses in the piven problem domain. Furthermore, identifying classes ix a iterative process, and as you gain more experience, you will get better at den- safying classes. In Chapter 7, we study four appreaches to identifying ef tn an object-oriented envirenment, objects take on an active rote in a system, ‘Thete objects do not etist in isolation but interact with each other. Indeed, their ioteractions and relationships become the application, Chapter § deseribes. the guidelines for identifying object relationships, attributes, and methods. Chapter 8 conchides the object-oriented analysis part af the: bok. Chapter 9 is the first chapter of Part [V (Object-Oriented Design) In this part ‘ofthe book, we leam how te elevate the analysis model into actual objects that can perform the required lask. Emphasis is shifted from the application domain to im- plementation. The classes identified during analysis provide a framework for the910 FART One: wirROOUCTION tiesign phase. Object-oriented design and object-onented analyels are distinct dis- ciplines, but they ure intertwined as well. Object-oriented development is highly incremental: in ather words,-yow start with object-oriented analysis, mode! it, ere- ate an object-oriented désign, then some more of each, agains and again, gendually refining and completing the models. of the system. Fart LV describes object-oriented design. Other activities of object-oriented design are the user interface design and: prototype and the design of the dawbuse access, Chapter 9 explainy the object- oriented design process und desigh axioms. The main objective of the axiomaite approach is to formalize the design process and assist in establishing a seie foundation for the object-oriented design process,’s0 a8 to provide a fundamental basis of the creation of systems, These guidelines, with incremental and evohi~ tionary styles of software development, will provide you a powerful way for de- signing systems. In Chapter 10, we look at guideline’ aid approaches that you ean use to desige: objects. and their methods. Althongh the design concepts to be discussed in this chapter are general, We concentnite oh designing the business objects. Chapter 10 describes the first step of the object-oriented design process, which esnstits of apt plying design axioms to design objects and their attributes, methods, sssociations; structures, and protocols. Chapter 11 introduces iasies regarding abject storage, relational and object- oriented database management systems, and object interoperability. We then lo At current trends to combine abject and relationsl systems to provide a very prac- tical solution to the problem of ebject storage. ‘We conclude the chapter with low to design the access layer objects. The rimin idea behind the access layer is up cre- ate a set of classes that know bow to commmnicate with the data source, regard- Jess of theit format, whether it is a file, relational database, mainfiame, or Inter- net. The access classes must be able to translate any data-related requests fromthe business layer into the uppropdate protocol for dats access. Access layer classes provide easy migration to.emenging distributed object technology, such as CORBA and DCOM. Furthermore, they should be able to address the (relatively) modest needs of two-tier client-server architectures a5 well as the difficult demands of fine-grained, peer-to-peer distributed-object architectures, The main goals of view layer objects are to display and obtain the information nweded in an accessible, efficient manner. The design of your user interface and view layer objects, more than anything else, affects how a user interacts and there fore experiences the application. A wellicsigned uicr interface has visual appeal that motivates users to. use the application. in Chapter 12, we learn how to design the view layer by mapping the user interface objects to the view layer objects. we took at user interface design rules, which arc bused on several design axioms, and finally at the guidelines for developing a graphical user interface. This chapter can- cludes the object-oriented design part af the book. Chapter 13 is the: first chapter of Part V (Software Quality}, which discusses «if ferent aspects of software quality and testing, In Chapter 13, we look at testing Strategies, the impact of object otientation on software quality. and guidelines for developing comprehensive test cases and plaits that ean detect and ideritify poten- tial problems before delivering the software 16 the users.(CHAPTER i) AN OVERVIEW OF CANECTORIENTED sySTEMS Devanorment 14 Usability testing is different from quality assurance testing im that, rather than Finding programming defects, you assess how well the interface ar the toftware fits users’ needs and expectations. Furthermore, to ennure usability of the system, we must measure user satisfaction throughout the system development. Chapter 14. de- scribes usability and user satisfection tests. We study how to develop user satis- faction and wéability tests based on the use cases identified during the analysis Appeodix A containé a template Yor documenting « system requiretient, template in this appendix is not to replace the documentation capability of a CASE tol but to be tised ts an example for isiues ot modeling elements that are needed for creating an effective system document. Finally, Appendix B provides a review of Windows and graphical user interface basics. 1.7 SUMMARY In-an object-oriented environment, software is 4 collection of discrete objects that encapsulate their data and the functionality to model real-world “objects.” Once objects are defined, you can take it for gramed that they will perform their desired functions and so seal them off in your mind like black boxes. Your attenting as a programmer shifts to what they do rather than how they do it. The object-oriented life ¢ycle encourages a view of the world as a system of coopermtive and collabn- rating: agents, An object orientation produces syslems that are easier to evolve, more flexible, more robust, and more reusable than a top-down structure approstch. An object ort entation + Allows working atu higher level of abstraction, + Provides:4 seamless transition among different phases of softwate development + Encourages good developmen practices, * Promotes reusability. ‘The unified approach (UA) is the methodology for software development pro- posed and used in this book. Hased on the Booch, Rumbaugh, and Jacobson methodologies, the UA consists of the following concepts: * Use-case driven development, + Utilizing the unified modeling language for modelin, * Object-oriented analysis (utilizing use cases and object modeling). * Object-oriented design, + Repositories of reusable classes ind maximum reuse. » The layered approach, + Incremental development and pooistyping + Continuoss testing. KEY TERMS Layered architecture (p. 6) Software development methodology (p.'3)