object-oriented analysis modeling language2. oop and ooad 11–19 2.1 object-oriented programming 11...

16

Upload: others

Post on 28-Feb-2020

13 views

Category:

Documents


0 download

TRANSCRIPT

OBJECT-ORIENTED ANALYSIS

AND

DESIGN THROUGH UNIFIED

MODELING LANGUAGE

OBJECT-ORIENTED ANALYSISAND

DESIGN THROUGH UNIFIEDMODELING LANGUAGE

By

Gandharba SwainM.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 ● HYDERABADJALANDHAR ●  KOLKATA ●  LUCKNOW ●  MUMBAI ●  RANCHI ● NEW DELHI

BOSTON (USA) ●  ACCRA (GHANA) ●  NAIROBI (KENYA)

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 : 2010ISBN 978-93-80386-54-6

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

UNIVERSITY SCIENCE PRESS(An Imprint of Laxmi Publications Pvt.Ltd.)

An ISO 9001:2008 Company113, GOLDEN HOUSE, DARYAGANJ, NEW DELHI - 110002, INDIA Telephone : 91-11-4353 2500, 4353 2501 Fax : 91-11-2325 2572, 4353 2528 C—www.laxmipublications.com [email protected] Printed at:

& Bengaluru 080-26 75 69 30

& Chennai 044-24 34 47 26, 24 35 95 07

& Cochin 0484-237 70 04, 405 13 03

& Guwahati 0361-254 36 69, 251 38 81

& Hyderabad 040-27 55 53 83, 27 55 53 93

& Jalandhar 0181-222 12 72

& Kolkata 033-22 27 43 84

& Lucknow 0522-220 99 16

& Mumbai 022-24 91 54 15, 24 92 78 69

& Ranchi 0651-220 44 64

Bran

ches

CONTENTS

Preface (ix)

Pages

1. Introduction to Object Technology 1–10

1.1 The Traditional Approach 1

1.2 Object Technology 8

Exercises 10

2. OOP and OOAD 11–19

2.1 Object-Oriented Programming 11

2.2 Object-Oriented Analysis and Design 14

Exercises 19

3. Modeling 20–23

3.1 What is a Model? 20

3.2 Importance of Modeling 21

3.3 Principles of Modeling 22

3.4 Object-Oriented Modeling 23

Exercises 23

4. An Overview of UML 24–36

4.1 What is UML? 24

4.2 Building Blocks of the UML 26

4.3 Architecture 34

4.4 Software Development Life Cycle 35

Exercises 36

5. Classes and Relationships 37–49

5.1 Class 37

5.2 Common Modeling Techniques of Classes 41

5.3 Relationships 43

5.4 Common Modeling Techniques of Relationships 47

Exercises 49

(v)

6. Common Mechanisms and Diagrams 50–62

6.1 Common Mechanisms 50

6.2 Common Modeling Techniques of Common Mechanisms 54

6.3 Diagrams 57

6.4 Common Modeling Techniques of Diagrams 60

Exercises 62

7. Advanced Classes and Advanced Relationships 63–78

7.1 Advanced Class 63

7.2 Common Modeling Techniques of Advanced Classes 68

7.3 Advanced Relationships 69

7.4 Common Modeling Techniques of Advanced Relationships 77

Exercises 78

8. Interfaces, Types, Roles and Packages 79–84

8.1 Interface 79

8.2 Types and Roles 80

8.3 Package 81

Exercises 84

9. Class Diagram and Object Diagram 85–92

9.1 Class Diagram 85

9.2 Common Modeling Techniques of Class Diagram 85

9.3 Forward and Reverse Engineering of a Class Diagram 89

9.4 Object Diagram 89

9.5 Common Modeling Techniques of Object Diagram 90

9.6 Forward and Reverse Engineering of Object Diagram 91

Exercises 92

10. Interaction and Interaction Diagram 93–104

10.1 Interactions 93

10.2 Common Modeling Techniques of Interactions 96

10.3 Interaction Diagram 98

10.4 Common Modeling Techniques of Interaction Diagram 100

10.5 Forward and Reverse Engineering of an Interaction Diagram 104

Exercises 104

11. Use Case and Use Case Diagram 105–113

11.1 Use Case 105

11.2 Common Modeling Techniques of Use Cases 108

11.3 Use Case Diagram 110

(vi)

11.4 Common Modeling Techniques of Use Case Diagram 110

11.5 Forward and Reverse Engineering of a Use Case Diagram 112

Exercises 113

12. Activity Diagram 114–122

12.1 What is an Activity Diagram? 114

12.2 Common Modeling Techniques of Activity Diagram 118

12.3 Forward and Reverse Engineering of an Activity Diagram 121

Exercises 122

13. Events and Signals 123–127

13.1 Events and Signals 123

13.2 Common Modeling Techniques of Events and Signals 125

Exercises 127

14. State Machine 128–132

14.1 What is a State Machine? 128

14.2 Advanced Features 129

14.3 Substates 130

14.4 History State 131

Exercises 132

15. Time and Space 133–137

15.1 Time and Space 133

15.2 Common Modeling Techniques of Time and Space 134

Exercises 137

16. State Chart Diagram 138–140

16.1 State Chart Diagram 138

16.2 Common Uses 138

16.3 Forward and Reverse Engineering of a State Chart Diagram 140

Exercises 140

17. Component and Component Diagram 141–154

17.1 Component 141

17.2 Common Modeling Techniques of Components 144

17.3 Component Diagram 148

17.4 Common Modeling Techniques of Component Diagram 148

17.5 Forward and Reverse Engineering of a Component Diagram 153

Exercises 154

(vii)

18. Deployment and Deployment Diagram 155–164

18.1 Node 155

18.2 Common Modeling Techniques of Nodes 157

18.3 Deployment Diagram 159

18.4 Common Modeling Techniques of Deployment Diagram 159

18.5 Forward and Reverse Engineering of a Deployment Diagram 163

Exercises 164

19. Object-Oriented Analysis 165–183

19.1 What is Analysis? 165

19.2 Steps in the Analysis Phase 166

19.3 Library Management System (LMS): A Case Study 167

19.4 Characteristics of Analysis Phase 183

Exercises 183

20. Object-Oriented Design 184–200

20.1 What is Design? 184

20.2 Aims of the Design Phase 184

20.3 Points to Remember in Design Phase 185

20.4 Characteristics of the Design Phase 185

20.5 Design Phase for Modern Applications 185

20.6 Design Guidelines 187

20.7 The Design Document 190

20.8 Design Document : A Case Study 192

20.9 Overview of OOD Methods 198

Exercises 200

Appendix A : UML Notation 201–212

A.1 Things 201

A.2 Relationships in the UML 204

A.3 UML Diagrams 205

Appendix B : Unified Process Model 213–220

B.1 The Unified Process 213

B.2 Unified Process Life Cycle 216

B.3 Unified Process is Iterative and Incremental 219

INDEX 221–225

(viii)

PREFACE

The idea of writing this book came to my mind by seeing the syllabus from different universitiesand different textbooks available. Since it is related to software development, the practical conceptscannot 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 tothe above average students, all are ambitious to pursue IT courses. This book is a common platformacross 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 OOADand how we are inclined towards object-oriented analysis and design from traditional approach. Thedifferent 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 anddiagrams and the use of each diagram with an example. Chapter-19 and chapter-20 discuss a casestudy—“Library Management System”. In this case study one can get a very clear idea what object-oriented analysis and design is and how UML is to be used for that purpose. Appendix-A discussesthe different syntactic notations of UML and Appendix-B discusses how the three approaches ofBooch, Rumbaugh and Jacobson are unified and about the unified process.

I thank to Almighty for his blessings.

Author

Chapter1 ����������� ��

���� �� ������

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 orpersonal computers. All computer processing was based on large mainframe or mini

computers, which were very expensive and difficult to maintain. However, this pattern startedchanging towards the 1980s with the introduction of the personal computer. It has changed sodramatically from that point onwards that in the last few years, almost all concerns regarding thehardware have been nullified, and the chief concern of all the concerned parties in a softwareproject is the software itself.

All modern organizations and corporations have become information-centric. They have quitea few areas where information constantly keeps coming in, or going out. For instance, in a typicalorganization, there are a number of departments, such as sales and marketing, research anddevelopment, customer service, and so on, each of which receives some information, or has to giveit 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 organizationmust keep track of all this information, whether it is current or of the past, and it must be able toaccess it as and when required with a very short notice. The result is that information systems playperhaps 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 voluminousdata, which seems to keep growing all the time. As we have mentioned, the hardware is no more anissue. 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 bequite 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 itstoes to keep up, and make use of this modern, better hardware. By the time the software seems tohave matched the hardware, the hardware takes another leap; it becomes even better. How do we

� ��������� �� � ������ � � ����� ������ � ����� ������ � �� �����

tackle this situation without impacting any of the areas in a software project? How do we ensurethat this race between hardware and software is not won by the hardware all the time? This race isshown in Fig.1.1.

N e w H a rd w a reis a v a ila b le

W r ite N e w S o ftw a re tom a k e u s e o f i tsa d v a n ta g e

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 thesoftware systems. Large corporations require dependable, large-scale software. However, historyshows that it is very rare to complete a software product in quick time that works as expected, andthat does not have any defects, either. The schedules and budgets are almost always crossed, andworse 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 thesoftware in order to deal with defects. Changes made to handle one defect cause the effect ofimpacting other portions of the software. Thus, removing one defect leads to the creation of one ormore new defects. To summarize, the typical challenges faced by major software systems areillustrated in Fig.1.2.

B u d g e t D e f e c ts

M o d e rn S o ftw a reS y s te m s

S c h e d u le C o m p le x ity

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 becomeextremely dynamic and volatile. This is more significant to big corporations. The software is eitherobsolete or is in the verge of becoming outdated, by the time it is delivered. Business requirements,

����������� �� ���� �� ������ �

demands and competition is changing so fast that the software projects must be equipped to handlechanges right through their lifetime. That is, a software project team cannot refuse changes to theuser 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 hasthe power to easily evolve tomorrow. This is shown in Fig.1.3.

Start of a Lifetime of

Software a Software

Project project

⇓ ⇓

C re a te C u sto m e rU p d a te C u s to m e rD e le te C u sto m e rP r in t In v o ic eW e e k ly R e p o rt

C re a te C u sto m e rU p d a te C u s to m e rD e le te C u sto m e rP r in t In v o ic eM o n th ly R e p o rt

In it ia l R e q u ir e m e n ts R e q u ire m e n ts C h a n g e d

C re a te /U p d a teC u sto m e rC re a te S a le s p e rs o nP r in t In v o ic eF le x ib le R e p o rtW e b E n a b lin g

R e q u ire m e n ts C h a n g e d

Fig. 1.3 Constantly changing user requirements

Many experts call this situation as a software crisis. How do we deal with such issues, anddeliver quality software on time within the budget, at least on most occasions, if not every time? Inorder to understand this, we must first examine the traditional approach for developing software.

������ ��������� ������������

The Earliest Approach

We shall begin with the earliest perspective to software construction, and quickly take a lookat the way this technique has changed, over the years. A computer program is a series of steps thatcarry out the desired functionality. These steps are written in the form of instructions in a programminglanguage, 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 ismanageable (small). The same person is responsible for handling changes to the procedures, andtaking design decisions, so as to freely move portions of the procedure’s code from one area to theother, and so on. This is shown in Fig. 1.4.

P ro g ra m

W h e n a p ro g ra m iss m a ll, i t is u s u a llyw rit te n a s a s in g lep ro c e d u re

P ro c e d u re

Fig.1.4 Program and Procedure

Object-Oriented Analysis and DesignThrough Unified Modeling Language

Publisher : Laxmi Publications ISBN : 9789380386546 Author : Gandharba Swain

Type the URL : http://www.kopykitab.com/product/10313

Get this eBook

40%OFF