object-oriented analysis modeling language2. oop and ooad 11–19 2.1 object-oriented programming 11...
TRANSCRIPT
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