OBJECT-ORIENTED ANALYSIS AND DESIGN THROUGH UNIFIED MODELING LANGUAGE

Size: px

Start display at page:

Download "OBJECT-ORIENTED ANALYSIS AND DESIGN THROUGH UNIFIED MODELING LANGUAGE"

Betty Bruce
5 years ago
Views:

3 OBJECT-ORIENTED ANALYSIS AND DESIGN THROUGH UNIFIED MODELING LANGUAGE

5 OBJECT-ORIENTED ANALYSIS AND DESIGN THROUGH UNIFIED MODELING LANGUAGE By Gandharba Swain M.C.A (UCE, Burla), M. Tech. (CSE) (NIT, Rourkela) Associate Professor Department of Information Technology G.M.R. Institute of Technology Rajam, Andhra Pradesh UNIVERSITY SCIENCE PRESS (An Imprint of Laxmi Publications Pvt. Ltd.) An ISO 9001:2008 Company BENGALURU CHENNAI COCHIN GUWAHATI HYDERABAD JALANDHAR KOLKATA LUCKNOW MUMBAI RANCHI NEW DELHI BOSTON (USA) ACCRA (GHANA) NAIROBI (KENYA)

6 OBJECT-ORIENTED ANALYSIS AND DESIGN THROUGH UNIFIED MODELING LANGUAGE by Laxmi Publications (P) Ltd. All rights reserved including those of translation into other languages. In accordance with the Copyright (Amendment) Act, 2012, no part of this publication may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, electronic, mechanical, photocopying, recording or otherwise. Any such act or scanning, uploading, and or electronic sharing of any part of this book without the permission of the publisher constitutes unlawful piracy and theft of the copyright holder s intellectual property. If you would like to use material from the book (other than for review purposes), prior written permission must be obtained from the publishers. Printed and bound in India Typeset at Monu Printographics, Delhi First Edition : 2010 ISBN Limits of Liability/Disclaimer of Warranty: The publisher and the author make no representation or warranties with respect to the accuracy or completeness of the contents of this work and specifically disclaim all warranties. The advice, strategies, and activities contained herein may not be suitable for every situation. In performing activities adult supervision must be sought. Likewise, common sense and care are essential to the conduct of any and all activities, whether described in this book or otherwise. Neither the publisher nor the author shall be liable or assumes any responsibility for any injuries or damages arising here from. The fact that an organization or Website if referred to in this work as a citation and/or a potential source of further information does not mean that the author or the publisher endorses the information the organization or Website may provide or recommendations it may make. Further, readers must be aware that the Internet Websites listed in this work may have changed or disappeared between when this work was written and when it is read. All trademarks, logos or any other mark such as Vibgyor, USP, Amanda, Golden Bells, Firewall Media, Mercury, Trinity, Laxmi appearing in this work are trademarks and intellectual property owned by or licensed to Laxmi Publications, its subsidiaries or affiliates. Notwithstanding this disclaimer, all other names and marks mentioned in this work are the trade names, trademarks or service marks of their respective owners. Published in India by Branches & Bengaluru & Chennai , & Cochin , & Guwahati , & Hyderabad , & Jalandhar & Kolkata & Lucknow & Mumbai , & Ranchi UNIVERSITY SCIENCE PRESS (An Imprint of Laxmi Publications Pvt.Ltd.) An ISO 9001:2008 Company 113, GOLDEN HOUSE, DARYAGANJ, NEW DELHI , INDIA Telephone : , Fax : , C info@laxmipublications.com Printed at:

7 CONTENTS Preface (ix) Pages 1. Introduction to Object Technology The Traditional Approach Object Technology 8 Exercises OOP and OOAD Object-Oriented Programming Object-Oriented Analysis and Design 14 Exercises Modeling What is a Model? Importance of Modeling Principles of Modeling Object-Oriented Modeling 23 Exercises An Overview of UML What is UML? Building Blocks of the UML Architecture Software Development Life Cycle 35 Exercises Classes and Relationships Class Common Modeling Techniques of Classes Relationships Common Modeling Techniques of Relationships 47 Exercises 49 (v)

8 (vi) 6. Common Mechanisms and Diagrams Common Mechanisms Common Modeling Techniques of Common Mechanisms Diagrams Common Modeling Techniques of Diagrams 60 Exercises Advanced Classes and Advanced Relationships Advanced Class Common Modeling Techniques of Advanced Classes Advanced Relationships Common Modeling Techniques of Advanced Relationships 77 Exercises Interfaces, Types, Roles and Packages Interface Types and Roles Package 81 Exercises Class Diagram and Object Diagram Class Diagram Common Modeling Techniques of Class Diagram Forward and Reverse Engineering of a Class Diagram Object Diagram Common Modeling Techniques of Object Diagram Forward and Reverse Engineering of Object Diagram 91 Exercises Interaction and Interaction Diagram Interactions Common Modeling Techniques of Interactions Interaction Diagram Common Modeling Techniques of Interaction Diagram Forward and Reverse Engineering of an Interaction Diagram 104 Exercises Use Case and Use Case Diagram Use Case Common Modeling Techniques of Use Cases Use Case Diagram 110

9 (vii) 11.4 Common Modeling Techniques of Use Case Diagram Forward and Reverse Engineering of a Use Case Diagram 112 Exercises Activity Diagram What is an Activity Diagram? Common Modeling Techniques of Activity Diagram Forward and Reverse Engineering of an Activity Diagram 121 Exercises Events and Signals Events and Signals Common Modeling Techniques of Events and Signals 125 Exercises State Machine What is a State Machine? Advanced Features Substates History State 131 Exercises Time and Space Time and Space Common Modeling Techniques of Time and Space 134 Exercises State Chart Diagram State Chart Diagram Common Uses Forward and Reverse Engineering of a State Chart Diagram 140 Exercises Component and Component Diagram Component Common Modeling Techniques of Components Component Diagram Common Modeling Techniques of Component Diagram Forward and Reverse Engineering of a Component Diagram 153 Exercises 154

10 (viii) 18. Deployment and Deployment Diagram Node Common Modeling Techniques of Nodes Deployment Diagram Common Modeling Techniques of Deployment Diagram Forward and Reverse Engineering of a Deployment Diagram 163 Exercises Object-Oriented Analysis What is Analysis? Steps in the Analysis Phase Library Management System (LMS): A Case Study Characteristics of Analysis Phase 183 Exercises Object-Oriented Design What is Design? Aims of the Design Phase Points to Remember in Design Phase Characteristics of the Design Phase Design Phase for Modern Applications Design Guidelines The Design Document Design Document : A Case Study Overview of OOD Methods 198 Exercises 200 Appendix A : UML Notation A.1 Things 201 A.2 Relationships in the UML 204 A.3 UML Diagrams 205 Appendix B : Unified Process Model B.1 The Unified Process 213 B.2 Unified Process Life Cycle 216 B.3 Unified Process is Iterative and Incremental 219 INDEX

11 PREFACE The idea of writing this book came to my mind by seeing the syllabus from different universities and different textbooks available. Since it is related to software development, the practical concepts cannot be easily understood, unless the book is written in a simple English and with easy examples. Due to the rapid growth of Information Technology, starting from the below average students up to the above average students, all are ambitious to pursue IT courses. This book is a common platform across all standards of students. This book will be useful for B.Tech (CSE/IT), M.Tech (CSE/IT), B.C.A, M.C.A, B.Sc (Comp), M.Sc (Comp) and DOEACC Students. The first two chapters represent the fundamentals of Object Technology, OOP and OOAD and how we are inclined towards object-oriented analysis and design from traditional approach. The different approaches suggested by the three pioneers - Booch, Rumbaugh and Jacobson. Chapters 3 to 18 represent the UML language, the building blocks of UML i.e., things, relationships and diagrams and the use of each diagram with an example. Chapter-19 and chapter-20 discuss a case study Library Management System. In this case study one can get a very clear idea what objectoriented analysis and design is and how UML is to be used for that purpose. Appendix-A discusses the different syntactic notations of UML and Appendix-B discusses how the three approaches of Booch, Rumbaugh and Jacobson are unified and about the unified process. I thank to Almighty for his blessings. Author

13 Chapter1 INTRODUCTION TO OBJECT TECHNOLOGY 1.1 THE TRADITIONAL APPROACH The Software Crisis T he traditional focus of computer systems had been on the hardware. Since the early 1950s, computer hardware was quite expensive. At the same time, there were no desktops or personal computers. All computer processing was based on large mainframe or mini computers, which were very expensive and difficult to maintain. However, this pattern started changing towards the 1980s with the introduction of the personal computer. It has changed so dramatically from that point onwards that in the last few years, almost all concerns regarding the hardware have been nullified, and the chief concern of all the concerned parties in a software project is the software itself. All modern organizations and corporations have become information-centric. They have quite a few areas where information constantly keeps coming in, or going out. For instance, in a typical organization, there are a number of departments, such as sales and marketing, research and development, customer service, and so on, each of which receives some information, or has to give it out. This information can be qualitative (e.g., our product has made good inroads in USA market) or quantitative (e.g., we have sold 1000 units of our product in USA). Regardless, the organization must keep track of all this information, whether it is current or of the past, and it must be able to access it as and when required with a very short notice. The result is that information systems play perhaps the most critical role in the day-to-day running of any modern business. The biggest problem faced by the organizations is to trying to keep up with this voluminous data, which seems to keep growing all the time. As we have mentioned, the hardware is no more an issue. New hardware can be bought, or the existing hardware can be upgraded with minimum cost. However, the key now is software. Writing and maintaining complex software has proved to be quite a challenge. There are many aspects of this, as follows: Race between Hardware and Software The biggest problem here is that hardware is upgraded quite frequently to fast processors, more memory and reliable server infrastructures. However, the software has to be constantly on its toes to keep up, and make use of this modern, better hardware. By the time the software seems to have matched the hardware, the hardware takes another leap; it becomes even better. How do we 1

14 2 OBJECT-ORIENTED ANALYSIS AND DESIGN THROUGH UNIFIED MODELING LANGUAGE tackle this situation without impacting any of the areas in a software project? How do we ensure that this race between hardware and software is not won by the hardware all the time? This race is shown in Fig.1.1. New Hardware is available Write New Software to make use of its advantage Fig. 1.1 Race between Hardware and Software Complexity of the Software Systems The second major issue related to modern information systems is the complexity of the software systems. Large corporations require dependable, large-scale software. However, history shows that it is very rare to complete a software product in quick time that works as expected, and that does not have any defects, either. The schedules and budgets are almost always crossed, and worse yet, the resulting software is many times riddled with defects. To make matters worse, generally the software is organized in such a manner that it is very difficult to make alterations to the software in order to deal with defects. Changes made to handle one defect cause the effect of impacting other portions of the software. Thus, removing one defect leads to the creation of one or more new defects. To summarize, the typical challenges faced by major software systems are illustrated in Fig.1.2. Budget Defects M odern Softw are Systems Schedule C om plexity Fig. 1.2 Challenges faced by major software projects Changes in Business Environment Apart from the technical issues just discussed, the business environment itself has become extremely dynamic and volatile. This is more significant to big corporations. The software is either obsolete or is in the verge of becoming outdated, by the time it is delivered. Business requirements,

15 INTRODUCTION TO OBJECT TECHNOLOGY 3 demands and competition is changing so fast that the software projects must be equipped to handle changes right through their lifetime. That is, a software project team cannot refuse changes to the user requirements, as changes have almost become an inevitable aspect of modern software projects. Therefore, the challenge here is to ensure that the software can handle easily today, and that it has the power to easily evolve tomorrow. This is shown in Fig.1.3. Start of a Lifetime of Software a Software Project project Create Customer Update Customer Delete Customer Print Invoice Weekly Report Initial Requirements Create Customer Update Customer Delete Customer Print Invoice M onthly Report Requirements Changed C reate/u pdate Customer Create Sales person Print Invoice Flexible Report Web Enabling Requirements Changed Fig. 1.3 Constantly changing user requirements Many experts call this situation as a software crisis. How do we deal with such issues, and deliver quality software on time within the budget, at least on most occasions, if not every time? In order to understand this, we must first examine the traditional approach for developing software Software Construction The Earliest Approach We shall begin with the earliest perspective to software construction, and quickly take a look at the way this technique has changed, over the years. A computer program is a series of steps that carry out the desired functionality. These steps are written in the form of instructions in a programming language, which a computer can understand and execute. Usually, one person writes one program. Such a program is called as a procedure. This works fine as long as the size of the procedure is manageable (small). The same person is responsible for handling changes to the procedures, and taking design decisions, so as to freely move portions of the procedure s code from one area to the other, and so on. This is shown in Fig Program W hen a program is sm all, it is usually w ritten as a single procedure Procedure Fig.1.4 Program and Procedure

Publications ISBN : 9789380386546 Author : Gandharba

16 Object-Oriented Analysis and Design Through Unified Modeling Language 40% OFF Publisher : Laxmi Publications ISBN : Author : Gandharba Swain Type the URL : Get this ebook

CONTENTS GRAPH THEORY

CONTENTS GRAPH THEORY CONTENTS i GRAPH THEORY GRAPH THEORY By Udit Agarwal M.Sc. (Maths), M.C.A. Sr. Lecturer, Rakshpal Bahadur Management Institute, Bareilly Umeshpal Singh (MCA) Director, Rotary Institute of Management and