Object oriented analysis and design using UML 9781259006746, 1259006743

Table of contents :
Title
Contents
1 RATIONAL UNIFIED PROCESS
2 RATIONALE FOR OBJECT ORIENTED DEVELOPMENT
3 OOAD—IDENTIFICATION OF CLASSES AND OBJECTS
4 MODELING WITH UML
5 OBJECT ORIENTED ANALYSIS—SCENARIO-BASED MODELS
6 OBJECT ORIENTED DESIGN—LOGICAL MODEL
7 INTERACTION DIAGRAMS
8 OBJECT ORIENTED DESIGN–BEHAVIORAL DESIGN
9 OBJECT ORIENTED DESIGN –PHYSICAL DIAGRAMS
10 OBJECT ORIENTED DEVELOPMENT—SAMPLES
REFERENCES
INDEX

Citation preview

OBJECT ORIENTED ANALYSIS AND DESIGN Using UML

About the Authors Dr D Jeya Mala is currently Associate Professor in Thiagarajar College of Engineering, Madurai, with a rich teaching and research experience of more than 12 years. She has been teaching courses like Object Oriented Analysis and Design (OOAD), Software Engineering and Software Testing. She has successfully guided numerous Software Development-based projects for The Great Mind Challenge (TGMC) contest, an Academic Initiative of IBM. As a researcher, she has investigated the practical aspects of Software Engineering and Object Oriented Paradigms for effective software development. Her work on Software Testing has fetched several grants from the University Grants Commission (UGC) under Major Research Project scheme. In addition, Dr Jeya Mala is a member of the Computer Society of India (CSI) and an invited member of the American Council for an Energy Efficient Economy (ACEEE). She holds a vital role in forming the reviewers’ board in journals like IEEE Transactions on Software Engineering, Elsevier–Information Sciences, and International Journal of Metaheuristics, among others. She has also been listed in Marquis Who’s Who List in 2011. She has completed certification on Software Testing Fundamentals, Brain Bench Certification on Java 1.1 programming, IBM certification as Associate Developer Websphere Application Studio. She is a proud recipient of several laurels from international corporations like Honeywell, IBM and Microsoft for her remarkable contributions in the field of Software Development and Object Orientation. Dr S Geetha is currently Associate Professor in Thiagarajar College of Engineering, Madurai. Having a rich teaching and research experience of more than 12 years, she has been successfully teaching courses like OOAD, Algorithms and Information Security. She has also guided several Software Development-based projects for The Great Mind Challenge (TGMC) contest, an Academic Initiative of IBM. Dr Geetha is a member of the Computer Society of India (CSI) and an invited member of International Conference on Applicable Computer Science and Technology (ICACST). She is also credited for holding a prominent role in forming the reviewers’ board in journals like IEEE Transactions on Information Forensics and Security, Image Processing, Elsevier–Information Sciences, and International Journal of Multimedia Tools and Applications, among others.

OBJECT ORIENTED ANALYSIS AND DESIGN Using UML

D Jeya Mala Associate Professor Thiagarajar College of Engineering Madurai, Tamil Nadu Affiliated to Anna University

S Geetha Associate Professor Thiagarajar College of Engineering Madurai, Tamil Nadu Affiliated to Anna University

McGraw Hill Education (India) Private Limited NEW DELHI McGraw Hill Education Offices New Delhi New York St Louis San Francisco Auckland Bogotá Caracas Kuala Lumpur Lisbon London Madrid Mexico City Milan Montreal San Juan Santiago Singapore Sydney Tokyo Toronto

McGraw Hill Education (India) Private Limited Published by McGraw Hill Education (India) Private Limited P-24, Green Park Extension, New Delhi 110016 Object Oriented Analysis and Design—Using UML Copyright © 2013 by McGraw Hill Education (India) Private Limited. No part of this publication can be reproduced or distributed in any form or by any means, electronic, mechanical, photocopying, recording, or otherwise or stored in a database or retrieval system without the prior written permission of the publishers. The program listings (if any) may be entered, stored and executed in a computer system, but they may not be reproduced for publication. This edition can be exported from India only by the publishers, McGraw Hill Education (India) Private Limited ISBN (13) : 978-1-25900674-6 ISBN (10) : 1-25-900674-3 Vice President and Managing Director: Ajay Shukla Head—Higher Education Publishing and Marketing: Vibha Mahajan Publishing Manager—SEM & Tech. Ed.: Shalini Jha Asst Sponsoring Editor: Smruti Snigdha Editorial Researcher: Amiya Mahapatra Copy Editor: Preyoshi Kundu Manager—Production Systems: Satinder S Baveja Sr Production Executive: Suhaib Ali Asst General Manager—Higher Education Marketing: Vijay Sarathi Sr Product Specialist: Tina Jajoriya Sr Graphic Designer—Cover: Meenu Raghav General Manager—Production: Rajender P Ghansela Manager—Production: Reji Kumar Information contained in this work has been obtained by McGraw Hill Education (India), from sources believed to be reliable. However, neither McGraw Hill Education (India) nor its authors guarantee the accuracy or completeness of any information published herein, and neither McGraw Hill Education (India) nor its authors shall be responsible for any errors, omissions, or damages arising out of use of this information. This work is published with the understanding that McGraw Hill Education (India) and its authors are supplying information but are not attempting to render engineering or other professional services. If such services are required, the assistance of an appropriate professional should be sought. Typeset at Print-O-World, 2579, Mandir Lane, Shadipur, New Delhi 110 008, and printed at Cover Printer :

Contents Foreword Preface

xi xiii

1. 1.1 1.2 1.3 1.4 1.5

Rational Unified Process Basics of Software Development Process 2 Introduction to RUP 5 Components of Rational Unified Process 6 Life Cycle Phases of Unified Process Model 6 Application of Object Oriented Diagrams in RUP 11 Summary 12 Multiple-Choice Questions 13 Exercises 14

2. 2.1 2.2 2.3 2.4 2.5 2.6

Rationale for Object Oriented Development Structured Approach Versus Object Oriented Approach 17 Object Orientation in Software Development Process 20 Flavors of Object Orientation 22 Basic Entities In Object Orientation 23 Object Oriented Constructs 29 Factors Favoring the Choice of Object Oriented Development 37 Summary 41 Multiple-Choice Questions 45 Exercises 47

16

3. 3.1 3.2 3.3 3.4 3.5

OOAD—Identification of Classes and Objects Object Oriented Analysis of Problem Domain 49 Object Oriented Analysis Techniques for Classes and Objects Identification 53 Object Oriented Design of Problem Domain 62 Design Principles in Object Oriented Design 63 Design Patterns in Classes and Objects Identification and Refinement 65 Summary 79 Multiple-Choice Questions 81 Exercises 84

48

4. Modeling with UML 4.1 Analysis and Design Phase 87 4.2 Object Oriented Analysis and Design with UML

1

86 91

Contents

4.3 4.4 4.5 4.6 4.7 4.8 4.9

Visual Modeling 92 Systems of Graphical Notation 93 UML as an Effective Modeling Tool 95 Understanding UML Diagrams 97 Support for OOA and OOD 99 Presence of So Many Diagrams in UML 101 Scope of UML 101 Summary 104 Multiple-Choice Questions 105 Exercises 106

5. 5.1 5.2 5.3 5.4 5.5 5.6

Object Oriented Analysis—Scenario-Based Models Use Case Analysis 109 Primary Use Case Diagram 110 Secondary Use Case Diagram 111 Notations Used in Use Case Diagram 112 Purpose of Use Case Diagram 119 Guidelines to Draw Use Case Diagrams 120 Summary 129 Multiple-Choice Questions 130 Exercises 134

108

6. 6.1 6.2 6.3 6.4

Object Oriented Design—Logical Model UML Class Diagram 137 Basic Notations Used in Class Diagrams 138 Purpose 164 Guidelines for Constructing Class Diagram 164 Summary 170 Multiple-Choice Questions 171 Exercises 173

136

7. Interaction Diagrams 7.1 Interaction Diagrams 179 Summary 201 Multiple-Choice Questions 202 Exercises 204

178

8. Object Oriented Design—Behavioral Design 8.1 State Charts 208 8.2 Activity Diagrams 215 Summary 232 Multiple-Choice Questions 233 Exercises 235

207

Contents

9. 9.1 9.2 9.3

10. 10.1 10.2 10.3 10.4 10.5

Object Oriented Design—Physical Diagrams Package Diagrams 237 Component Diagrams 244 Deployment Diagrams 251 Summary 258 Multiple-Choice Questions 259 Exercises 262

236

Object Oriented Development—Samples Applying Classes and Objects in the Real World 265 IT Service Help Desk 265 Insurance Claim Management System 300 Workflow Management System 312 Desktop Application/Tool Development—Preclean Tool 342

264

References

361

Index

365

Foreword It gives me immense pleasure in writing the foreword for this brilliant book on Object Oriented Analysis and Design or OOAD, by my colleagues, who have been involved in on-field research and classroom teaching experience for more than a decade. It is worth mentioning that this book is the outcome of their dedicated work in this area down the years. To write a book on a subject like OOAD requires skill and thorough knowledge. Being an expert on the subject, Dr Jeya Mala and Dr Geetha have succeeded in compiling this book in a very comprehensive manner, and at the same time, explained the theory by maintaining a student-friendly approach throughout the book. Object Oriented Analysis and Design Using UML discusses the concept of OOAD from its elementary stage; beginning with a basic introduction on Rational Unified Process, followed by the significance of object oriented development. With this as the backdrop, students are next introduced to the object oriented analysis-based models. The latter chapters deal with more advanced concepts on modeling using Unified Modeling Language (UML), object oriented development models, interaction models, behavioral models, and physical models. The last chapter brings together all the topics and concepts learnt with the help of case studies taken from real-life problems. This will help students get acquainted with practical knowledge. One of the highlights of Object Oriented Analysis and Design Using UML is the self-explanatory feature of its diagrams and flow charts at every instance of theory. This is an advantage since it will help students and programmers translate their ideas into meaningful codes and programs smoothly. Detailed explanations of diagrams like use case diagrams and their advantages and weaknesses, UML class diagram, sequence diagram, collaboration diagram along with activity diagram, package diagram, component diagram, and deployment diagram will prove to be an extremely helpful guide in understanding the concepts. This will consequently help system analysts present their software development process accurately so that students and programmers can perform their coding effortlessly. I am sure this book will act as a strong foundation for all Computer Science, Information Technology and Computer Application students, and help teachers in nurturing an interest in the minds of the students. Wishing Dr Jeya Mala and Dr Geetha all the good luck and hope the venture proves to be a great success! Dr R Rajaram Former Dean CSE / IT / MCA Thiagarajar College of Engineering, Madurai

Preface Introduction In today’s world, computerized systems and software have grown to become inseparable; the latter being the tool that drives the former. Sadly, software is not available naturally to everyone. People have to write it, understand it, analyze it, use it, and update it for changes in future versions. It is this intertwining aspect between the humans and the programming world that positions modeling complex systems on levels of construction, that are higher than “normal” programming languages. This also puts forth the need for methodologies to guide software engineers and programmers in coping with the modeling process itself. In order to devise a high-level modeling approach, an expert diagrammatic reasoning is required. But explanations with the help of only diagrams or flow charts are not enough. Languages of diagrams are equally important which can be understood with the help of computerized support for validation and analysis. Over the years, Structured Analysis (SA), and Object Oriented Analysis (OOA) have assumed a prominent position in high-level approaches. SA was started in the late 1970s by DeMarco, Yourdon and others, and is based on “lifting” classical procedural programming concepts up to the modeling level graphically. The result calls for modeling system structure by functional decomposition and flow of information, depicted by data flow diagrams. Object Oriented Analysis and Design (also known as Object Oriented Modeling) came into existence in the late 1980s. The basic idea for system structure was to “lift” concepts from object-oriented programming up to modeling level, graphically. Over the last 78 years, object oriented methodologists have been meticulously working with each other at close quarters. They have successfully formulated a general Unified Modeling Language (UML), in the hope of bringing together the best of the various object oriented modeling approaches. This is a breakthrough achievement since more and more software engineers can now claim more kinds of software that are best developed and available in object oriented fashion. For capturing system structure, the UML indeed adopts a diagrammatic language for classes and objects that is based on the entity relationship approach. For early stage behavioral analysis, it recommends use cases and utilizes sequence diagrams. For full constructive specification of behavior, on the other hand, it adopts state charts, as modified in the aforementioned executable object modeling work. The recent wave of UML popularity will bring forth a stream of books, papers, reports, seminars and tools describing, utilizing and elaborating upon the UML. Among the many books that are available in the market, this book distinguishes itself by the way the ideas are organized and presented.

Preface

About the Book Object Oriented Analysis and Design explains the subject with the help of UML while maintaining the interest of the students through an innovative approach to the subject. The book is designed to provide the readers with a set of chapters that they can grasp theoretically and also apply in the real world. Systems analysis and design are activities that should take place in the context of object oriented approach. The first four chapters set the development of information systems based on object oriented paradigm, in this context. Every chapter in the book begins with a concept map and learning objectives which provide a clear picture of the topics that will follow in the subsequent pages along with pointing out their importance. This is an added advantage since it sets a strong foundation and a perspective on the subject of object orientation. The chapter-end questions are structured as Remember, Understand, Apply, Analysis and Create to test students’ level of understanding. The worked out examples given in Chapter 10 will be of great help to both students as well as course instructors. The knowledge gathered by both can be applied to any application domain. The examples provided are not a closed set of example; instead they have been selected from diverse company projects, thus, making it part of practical knowledge. Therefore, the solutions provided can be used for any similar type of application. Altogether, these features make this book a helpful, complete and comprehensive material in the object oriented method of software development. This book will prove to be an extremely helpful study material for students undertaking courses in Computer Science, Information Technology and Computer Application. It will also be useful to those who want to understand how business information systems are developed or programmers who want to learn how the tools of UML help in design. Business analysts and clients who need to communicate with the system developers on a daily basis can also refer to this book. Object Oriented Analysis and Design Using UML deals with the most practical aspects of the UML diagrams, role of each diagram, notations to draw them, and how to apply them using realistic case studies. UML provides a common ground for business and technical professionals. The examples and case studies given at appropriate places are very practical and useful for establishing a common language. They also describe critical business systems by breaking down the diagrams, and clearly explaining why and how they can be used.

Salient Features of the Book Easy to read, compelling, and consistent language In-depth coverage of all important topics like Software Development Life Cycle, Identification of Objects and Classes, Object Oriented Diagrams, UML and its Applications Practical approach applied in case studies, examples, and real-life situations Concept map at the beginning of each chapter; enabling students to visualize the hierarchy of concepts

Preface

Unique graded exercises Categorized into Remember, Understand, Apply, and Analyze Explains conversion of pseudo-code UML examples into programming examples

Chapter Organization The book consists of 10 chapters. Chapter 1 introduces the reader to various software life cycle developments, and specifically the significance of Rational Unified Process of developing software and the related concepts. Chapter 2 points out the way OOA differentiates itself from SA, and the rationale for the choice of object orientation, along with the classes, abstractions and the instances. Chapter 3 explains how the real-world modeling is incorporated and also the OOA and OOD portions of identifying classes and instances in a system. Chapter 4 gives an overall view of the UML modeling tool, the support offered for object oriented-based software development compared to that of other visual modeling tools. Chapters 5 to 8 discuss in detail the various diagramming elements available in UML in a systematic way, i.e., the symbols available, the usage and application of each notation. All these diagrams are explained with the help of case studies, which run throughout the book. This gives a better and complete understanding of all the UML diagrams. Chapter 9 is dedicated to discussing package diagram, component diagram, and deployment diagram with the help of case studies. Chapter 10 is exclusively written to present four specific case studies varying from desktop application, intranet-based application, client-server application, and of course, a web-based application. These problems are picked up from real-time projects that will facilitate students during their internship in various companies. The complete object oriented-based analysis and design of these systems including the possible set of UML diagrams are also provided.

Web Supplements Following supplements are available for students and instructors at http://www.mhhe.com/jeya_mala/ooad Rational Rose Tool Kit – Guide to use it for UML Diagrams (Integrated with book) Chapter wise Quiz Link to Reference Material Case Studies PowerPoint Slides Link to authors’ video

Acknowledgements We thank the following reviewers for providing us with invaluable support, ideas and suggestions: Rajeev Pande University Institute of Technology, RGPV Snehal Gandhi Sarvajanik College of Engineering & Technology, Surat, Gujarat M Rajesh Babu Dr. NGP Institute of Technology, Coimbatore, Chennai A Chitra Devi P S N Engineering College, Tirunelveli, Tamil Nadu S Ramakrishnan Dr Mahalingam College of Engineering & Technology, Pollachi, Tamil Nadu

Preface

We would like to thank our family members for their support and patience during the time of writing this book, and Thiagarajar College of Engineering Management, Our Principal and our colleagues for their support. Special thanks to Dr R Rajaram, the former Dean of Computer Science Department, TCE, for his moral encouragement coupled with great enthusiasm in making progress every single day of his life. We would also like to thank the editorial team of McGraw-Hill Education (India) for managing the internal publication process. The entire staff was very responsive and helpful and we thank each one of them for their continued support, without which this book would not have been possible.

Feedback Utmost care has been taken to provide our readers with the best material. If, in case, you come across any misprint/error or have any feedback/suggestions, you may write to us at [email protected] or [email protected]. We will try and incorporate them in the next edition.

Publisher’s Note Do you have a feature request or a suggestion? We are always open to new ideas (the best ideas come from you!). You may send your comments to [email protected] (don’t forget to mention the title and authors’ names in the subject line).

CONCEPT MAP

Concept Map

Learning Objectives Learning objectives point out the significance of studying the chapter.

Example: In C++, a file created with ‘.h’ extension acts as an interface In Java, an interface is created as below: public interface employee_category { int emp_category; void add_employee(); void delete_employee(); void insert_category(); } In C#, it is created with the first letter “I”: public interface Iemployee_category { int emp_category; void add_employee(); void delete_employee(); void insert_category(); }

Case Study Case studies help in relating and applying the studied topics in real life.

LEARNING OBJECTIVES After learning this chapter, readers will be able to

Programming Examples UML examples are converted into programming examples in Chapter 2 and 3.

CASE STUDY FOR OOA TECHNIQUES 1. Banking application development (a) Entity similarity, e.g., Customers (b) Operational similarity, e.g., Transactions (c) Service-based similarity, e.g., Accounts, Loans (d) Internal working-based similarity, e.g., Deposit accounts Abstraction-based analysis There are a collection of accounts such as current account, savings account, fixed deposit account, term deposit account, recurring deposit account, and so on. Similarly there are several kinds of persons interacting in this domain which includes, banking staff, current account holders, savings accounts holders, business account holders and so on. Several kinds of transactions such as deposit, withdrawal, money transfer, Demand draft, cheque book request, Housing loan, Education loan, land purchase loan, festival loan happening in this domain. When these entities are identified in the problem domain, the problem of finding similarities arises which helps in discovering the crisply defined boundaries between them. They have been grouped as Accounts, Transactions, Loans, and Services. Entities analysis i. Tangible things Customers, Passbook (Customer Details), Employee in the bank (Employee), Main Branch, Vilangudi Branch, etc., (Branch) Quarterly Report, Annual Report, Loan Report, etc. (Reports), etc.

VISUAL WALKTHROUGH

Concept map at the beginning of each chapter introduces the flow of topics.

Solved Problems

SOLVED PROBLEMS To understand the application of various diagrams, this book takes into consideration two more applications apart from “Mobile Watch Dog Software”. Here, the applications description is provided. At the end of each chapter, the relevant diagrams are placed and the reader can refer to the system specification given here when they are studying the subsequent chapters:

Summary Summary at the end of each chapter lists the important concepts discussed.

SUMMARY Class diagrams represent the static behavior of a system and facilitate the representation of OOP concepts like inheritance, abstraction, etc. The class diagrams illustrate classes, interfaces, and their associations. They are used for static object modeling and are also called Structural Modeling Diagrams. A class diagram gives an overview of a system by showing its classes and the relationships among them. Class diagrams display what interacts but not what happens when they do interact Classes participate in four principal relationships: association, aggregation, composition, and generalization. Association is the “uses a” relationship. Aggregation and composition are “has a” relationships. Aggregations are relationships between a class and a reference object. Compositions are relationships between a class and a value object. Generalization is the ‘is a’ relationship, and is used to denote inheritance. The various elements and the respective notations in a class diagram are learnt. The systematic approach for constructing a class diagram for a given domain is being presented

MULTIPLE-CHOICE QUESTIONS 1. What are the two different types of state chart/ state machine diagram in UML 2.0? (a) Single and Multi-stage state machines (b) Behavioral and protocol state machines (c) Class and component state machines (d) Complex and Simple state machines. 2. Identify which of the following modeling element is not associated with Activity Diagrams. (a) Associations (b) Swimlanes (c) Initial node, final node (d) Fork and join nodes 3. In an activity diagram, which of the following steps in the flow of events is called a(n)? (a) Join (b) Form (c) Decision (d) Action

Exercises Exercises are cateogorized as Remember, Understand, Apply, and Analyze, to test students’ understanding of concepts and principles.

Solved problems illustrate how the theories may be applied in solving problems.

Multiple-Choice Questions A large number of choice questions further enhance comprehension and solving ability.

multiple(MCQs) students’ problem-

EXERCISES Remember 1. Name the two types of interaction diagrams and give very simple example of the same using one type of diagram and the other. 2. Write down the purposes of interaction diagrams. 3. What is a found message? What does it mean?

Understand 1. How is a destroyed object depicted in a sequence diagram? 2. Compare and contrast collaboration and sequence diagrams. 3. Creation and Deletion of objects supported in collaboration diagrams? If so, how?

Apply 1. Develop two sequence diagrams, for a Banking Application. 2. Show a normal and successful transaction.

RATIONAL UNIFIED PROCESS

1 CONCEPT MAP

LEARNING OBJECTIVES After learning this chapter, readers will be able to

Object Oriented Analysis and Design

1.1

BASICS OF SOFTWARE DEVELOPMENT PROCESS

Software development process is considered as a sequence of well-defined activities done throughout its life cycle. Usually, the development process starts from planning, which is usually considered as a 0th-level activity, and is followed by requirements-elicitation process. The requirements-elicitation process helps to understand the problem domain by means of conducting interviews, issuing questionnaires, discussions, frequent meetings with customers or customer representatives, and so on. Once the requirements are collected, they are analyzed during the analysis phase in which incomplete requirements, misunderstood requirements, missing requirements, etc., are identified and corrected. The work product of the analysis phase is the Software Requirements Specification (SRS) document, which will be reviewed and agreed upon by the development team as well as the customers. This SRS is then used as the basis for design, coding, and testing phases. The design phase involves the development of design documents relevant to the application being developed using either Structured Analysis and Design (SAD) or by means of Object Oriented Analysis and Design (OOAD) methods. Then the coding phase begins using the specified software and hardware requirements given in the SRS and design documents as the baseline. If the product is developed using an agile-based methodology or an evolutionary development model, the development is done in an iterative and incremental way with the major focus as change management and dynamic input from customers. Once the product is developed and unit tested by the developers, and system tested by the testing team and accepted by the customer by means of user acceptance testing, the product is deployed in the customers site. Then onwards, the maintenance process starts with the focus on preserving the functionality of the deployed software, updating the existing functionality based on users needs and correcting the defects which might have occurred in the customers’ site. To develop the software by following the engineering approach, several models have been proposed by several researchers in the past. The broad categories of such software development life cycle models are: 1. Waterfall Model 2. Incremental Model 3. Evolutionary Development Model 4. Agile Model

1.1.1 Waterfall Model It is a linear sequential development model proposed by Winston Royce in 1970. The process flow of the waterfall model has phases starting from communication and planning, requirements analysis, design, coding, testing, and maintenance being carried out in sequential nature. The outcome of one phase is used as the input for the next phase. The steps involved in the waterfall model include the following: 1. Requirements collection from customers and business perspectives. 2. Development of a project plan to estimate cost and schedule for the project. 3. Preparation of SRS document from the collected requirements. 4. Designing of a set of design documents to act as blueprints for coding. 5. Development of software as per the design documents as modules or units. 6. Integration of modules and testing them to ensure that all the customers’ requirements met. 7. Deployment of the complete tested software with user documentation and manual to the customers.

Rational Unified Process

Advantages If the requirements are known well in advance, it is easy to develop the product as a linear sequence of phases.

Disadvantages 1. In real-time applications, the requirements may not be clearly known in advance as the customers may not be able to explicitly state their requirements completely during the initial phase itself. 2. As the product is available to the customers only at the end of the life cycle, feedback from the customers will be arrived too late and it may not be possible to fix up the errors or any requirements slippage at later stages. 3. Redoing of activities once again from analysis till testing may lead to cost and schedule slippage.

Which Types of Projects can be Developed Using it? The projects in which the requirements are known well in advance such as the following can be developed using this model: 1. Language compilers, interpreters 2. Operating systems 3. Device drivers

1.1.2 Incremental Model In this model, the entire software is broken down into increments that satisfy individual functionalities. The customers will be asked to assign priority to their stated requirements and the first increment will be developed on the basis of the highest priority requirements. If the development of an increment is started, no further modifications can be made on that increment. Based on the feedback gathered from the first increment, the next set of increments will be developed. The final increment will deliver the complete functionalities stated by the customers.

Advantages 1. Incremental delivery of project is based on the system functionality. 2. Regular feedback from the customers is available on the basis of the increments. 3. As higher priority functionality is developed first, risk is reduced on the overall functionality of the project.

Disadvantages 1. As the specification is not concrete, it is not possible to completely test the functionality of the system after each increment. 2. Due to frequent changes in the software based on the delivered increment to the customers, the structure of the software will be lost. Also, it increases the cost and time of the project.

Which Types of Projects can be Developed Using it? Applications that need intermittent workable software follow this model. Some of the applications that can be developed using this model are: 1. Client-server applications such as hospital management system, stock management system, and insurance management system. 2. Web applications specifically meant for intranet-based applications, that is, applications that run within an organization.

Object Oriented Analysis and Design

1.1.3 Evolutionary Model This is an incremental, iterative type of model that contains all the life cycle phases stated in the software development life cycle. Apart from that, the model has users’ feedback at the end of each evolutionary cycle, and the next spiral incorporates the feedback information in the next cycle. The most important aspect of evolutionary model is risk assessment. If the user or customer is satisfied at a level, the project manager terminates the project, which is done explicitly during each phase. As the users’ involvement is present throughout the development life cycle, failure is very less. It has the following types: 1. Spiral model 2. Prototyping model 3. Concurrent development model

Advantages 1. Risk analysis. 2. Users’ involvement throughout the life cycle. 3. Validation of requirements at the end of each spiral.

Disadvantages 1. If the customers are not convinced, then the number of iterations needed will be tremendously increasing which will lead to uncontrollable development scenario. 2. Risk assessment should be done rigorously; otherwise, it will lead to major failure in the software.

Which Types of Projects can be Developed Using it? Applications that need proper risk analysis and intermittent software delivery follow this model. Some of the applications are: 1. Hard real-time applications that have high probability of risks, such as patient monitoring system, aomic reactor system, and temperature monitoring system in an atomic power plant. 2. Soft real-time systems that have high probability of risks such as banking applications, finance applications, weather monitoring systems, ERP applications.

1.1.4 Agile Model The agile model focuses on continuous collaboration with the customers as the changes are inevitable. To incorporate the changing requirements given by the customers, the agile process model provides support for having customers/customer representatives/users as part of their development phase. The continuous delivery of the software to the customer as developed user stories, there is a continuous update to the software as per the change requests given by the customers. The developers–customers interaction plays a vital role in the agile model by means of frequent brainstorming meetings conducted by the project manager having all the stakeholders to discuss their ideas about the quality delivery of the software product. The code is also developed by applying refactoring techniques which aids in simplicity and extensibility of the software.

Advantages 1. Well suited for small- and medium-sized projects in which frequent interaction with the customers is possible.

Rational Unified Process

2. Highly motivated small development team makes software development faster. 3. High cohesive/jelled team structure enables frequent updates to the software based on the customers reviews. 4. Test-driven development helps to improve quality of the software by assuring customers requirements throughout the development. 5. As it emphasizes on the final product, the functionality of the software will never be omitted.

Disadvantages 1. As the agile model does not emphasize on documentation, there will be frequent changes according to the changing customers requirements due to which it is not suitable for large projects. 2. Highly motivated and technically experienced people are the key requirements of an agile team. If it is not available this will lead to degenerate into code-and-fix. 3. Keeping customers, developers and testers together for each user story development is costly and if not properly planned will lead to chaos. 4. As the changes are unavoidable, test planning, test case design and test execution are often difficult as there is no proper specification from the customers based on their requirements.

Which Types of Projects can be Developed Using it? Applications that require constant changes in users’ requirements, continuous users’ involvement and highly motivated development team can be developed using this model. For instance, 1. Standard applications used in organizations like Accounting Software such as Tally, Online Web Portals that have huge customers base, etc., and 2. Social websites such as Facebook, Twitter, etc.

1.2

INTRODUCTION TO RUP

When the software development process came into the picture, there was an ultimate need for a collection of phases in the development process. In Section 1.1, we discussed about various software development models in which the phases are completely distinct and they have not showed their interest on overlapping some of the phases during the development process. None of the existing traditional life cycle models addresses the risky components at the earlier phase of the life cycle. They have not insisted on having milestones during software development but they simply focused on the set of outcomes at the end of each cycle. This leads to the development of unique object oriented software development life cycle model namely Unified Process (UP) or Rational Unified Process (RUP). This process model was proposed by Booch, Jacobson and Rumbaugh. This process model reduces risk by concentrating on more risky components earlier before focusing on less risky components. It also helps in developing prototypes for the software and wire frames for the user interface which helps the users to better understand the system and can easily find out the risky aspects earlier before the entire product release is done. The RUP is an iterative process which helps in repeating the same set of steps to add or update the components to the software based on the feedbacks from the previous iteration. This process model helps in providing milestones at the end of each iteration, which thus helps in evaluating the software for its progressiveness.

Object Oriented Analysis and Design

1.3

COMPONENTS OF RATIONAL UNIFIED PROCESS

This process is also sometimes called Unified Software Development Process (USDP) and is used specifically for object oriented systems development. It is an iterative process as shown in Fig. 1.1 and combines the best practices of both evolutionary and agile process models such as extreme programming, scrum and other agile process models. This leads the UP process to blend the features such as refactoring, test driven development and integration at the end of each iteration and regular meeting practice to monitor the progress of the software. The iterative nature of the UP makes Fig. 1.1 Unified process model with normal life it dynamic in nature to refine the stated cycle phases requirements and other development artefacts. This leads to the insertion of major and minor milestones throughout the process development. The system is refined based on feedback given by the customers and the product is well planned and developed to accommodate the changes given by the customers and other stakeholders. Here, an iteration may take one to eight weeks. At the end of each iteration, a minor milestone is provided. Once a particular iteration is completed, the process is verified for satisfying the minor milestone in terms of the intermittent work products and other review results. As UP combines the best practices of evolutionary and agile process models, the development is short-time boxed, iterative and adaptive in nature. The other features of UP includes, managing high value risk in early iterations, continuous monitoring, evaluation and adaptation to changes and feedbacks on requirements from customers, high cohesive core architecture development in early iteration and continual verification of quality by means of regular tests done throughout the development process. It also includes the practices for change management by having a set of umbrella activities being conducted throughout the process.

1.4

LIFE CYCLE PHASES OF UNIFIED PROCESS MODEL

As other life cycle process models, the RUP also has four major phases, namely 1. Inception 2. Elaboration 3. Construction 4. Transition

1.4.1 Inception This is the first phase of the UP model. During this phase, the communication with customers takes place to capture the initial set of requirements and further analysis over it. This phase is not meant to define all the customer requirements as in the requirements analysis phase of waterfall life cycle model. It is the preparatory phase that analyzes the purpose and objective of the project, feasibility analysis of the project in terms of technical, economical and resources, taking make/buy decision, usage of off-

Rational Unified Process

the-shelf components from previous products, estimated cost and time to complete the product and cost benefit analysis of the product. During this phase, the zeroth activity of project development namely project planning takes place which includes the preparation of Gantt charts and work breakdown structures for planned work over the time line and budget estimates by means of various cost estimation models. The outcomes of this phase are: product scope, vision document and business case. The product scope specifies the expected functionality and objective of the proposed project. The vision document specifies the high-level goals and constraints. The business case indicates whether the development of the project is economically feasible or not. Finally, this phase leads the organization to get concurrence with all the stakeholders about the scope, vision and business case of the project. Some of the other intermittent work products of this phase apart from vision document, business case, primary use case model of the initial set of functional requirements, non-functional or supplementary requirements, risk list, and risk mitigation plan, iteration plan, phase by phase development plan, development case, prototypes, verification base lines and glossary of terms. The UP applies a systematic approach to manage the requirements which are not being stated clearly by the stakeholders. The UP approach provides a way to find, document which organize and track changes in the requirements in a form (normally a System Requirements Specification [SRS] document) which then acts as a medium of interaction between the development team and the customers. The requirements collected during the inception phase are classified into functional and nonfunctional requirements. The functional requirements are the basic functionalities required from the product. The non-functional requirements include quality attributes which are normally associated with the performance of the product. Both functional and non-functional requirements are categorized as FURPS+ model; where F is Functional, U is Usability, R is Reliability, P is Performance and S is Supportability. Here, the functional aspects include features, capabilities and security requirements of the system. Usability indicates how well the system is easily usable by the end users, help facility and documentation of the software. Reliability measure indicates the frequency of failure, recoverability and predictability of the functionality of the software after its deployment. Finally, supportability attribute includes adaptability, maintainability, internationalization and configurability. To verify the collected requirements, the quality attributes, namely F, U, R, P and S are used as the verification criteria for non-functional requirements (NFRs). Also, the behavioral aspects of the system are collected as functional requirements (FRs). As a result of this phase, the following intermittent work products or artifacts are generated: 1. Requirements specification document This document contains the objectives, scope, functional requirements and technical requirements of the system. 2. Primary use case diagram This captures the functional requirements of the system. It also depicts the ways in which the various external entities of the system are interacting with the functionalities. This diagram is primarily used for capturing only the functional requirements. 3. Supplementary specification document Its primary purpose is to capture non-functional requirements such as performance and other non-expressible functional requirements by means of use cases and other reports. 4. Glossary It contains the key terms and their description used in the product development. This can be used as a data dictionary which records objects (in terms of attributes and operations), their associated requirements, constraints, validation rules and so on.

Object Oriented Analysis and Design

5. Vision statement It is the short summary statement or business case of the project that shows the high-level requirements to provide an overview on the project’s objective. 6. Business rules or domain rules They describe the policies that are to be followed in the software development pertaining to a particular domain or business. They are usually kept in a central business rules repository which can be shared by all the analysts of the organization for better reusability during analysis. 7. Test specification document This document is derived from the requirements specification document and supplementary specification document. This contains the set of test data and the expected outcome when the test data is executed against the specified functionality.

1.4.2 Elaboration After the inception phase is completed, the elaboration phase begins. During this phase, requirements analysis and development of architecture and design documents are done. This phase is used to identify most of the requirements that were invisible during inception phase, estimate the overall schedule and the expected amount of resources in terms of hardware, software, man power and other external and internal resources and build the core architecture for the system as a whole. High-risk components are identified, mitigated and resolved during this phase. Elaboration phase is normally carried out by means of two or more iterations. Each iteration has a definite ending time to complete the set of activities in that iteration. There are several internal stakeholders involved in the elaboration phase, such as system analysts, architects, designers and developers. During the elaboration phase, the analysts create some models from the perspective of logical view. The models which are prepared are use case model and domain model. The use case model comprises of use case scenarios, primary and secondary use case diagrams, use case realizations and preconditionpost condition and invariants of each use case scenario. The domain model comprises of class diagram in logical view. During this phase, the architects prepare architectural model for the software to be developed. They map the overall system structure in terms of physical view. For instance, they look into the final implementation architectural style like MVC, struts or hibernate, etc., to be used, the layers of the software that are to be placed into the corresponding tiers of those architectures and also the deployment of developed components to the final target system. Also, the designers work during the elaboration phase to develop design model. They find out the classes that are part of each module and the interaction of the identified classes to achieve the specified behavior. Also, the design patterns are effectively employed to refine the classes identified and for the identification of new classes which are invisible during earlier identification process. The developers also start their work during the elaboration phase. They give priority to develop critical components before the other components development starts. The development work starts here for the critical components so that any changes required in these components or the testing up of these components can be done well before the other less critical components development. This helps in ensuring the quality of the software product as none of the critical components will be left untested. Then they will proceed on for the development of a preliminary user interface (normally it may be a wireframe) and will be used as a prototype for verification by the customers. This aid in identifying changes earlier well before the actual development starts as a whole during construction phase.

Rational Unified Process

The artifacts which are developed at the end of elaboration phase are: 1. Use case descriptions It is a detailed description associated with each primary use case identified during the inception phase. The information placed in this document is based on the outcome of the requirements document prepared during the inception phase and other related information are gathered using interviews, questionnaires and other informal methods. For each use case scenario, the pre-conditions, post-conditions and the actual processes are identified. They are then written up as ‘use case descriptions’. Each use case description contains (a) a list of primary and secondary actors associated with the corresponding primary use case, (b) main scenario’s description, and (c) normal flows and alternate flows based on the result of the process. 2. Detailed use case diagrams Once the use case descriptions are written for each primary use case, the detailed use case diagrams or secondary use case diagrams are drawn on the basis of the use case descriptions. For each use case scenario, there will be a corresponding use case diagram. 3. Domain model or domain class diagram A domain model is a representation of the classes in the application domain. To draw the domain model, class diagrams are used. For developing a domain class diagram, the list of key abstractions in terms of entities, actions or processes are identified and are grouped as classes, and then the relationship between these classes are identified. Once the classes and their relationships are identified, the class diagram can be drawn. Each class contains a set of attributes, operations and relationships with other classes. 4. System sequence diagrams This diagram shows how actors and the system interact to complete the behavior of the system. It shows message passing between various entities in the domain. This sequence diagram also represents objects interaction in terms of message invocation, the life time of each object and the state of each object during system function. In Unified Modeling Language (UML) representation, this can be done using two diagrams namely Sequence and Collaboration diagrams. 5. Activity diagrams They are created to show the internal activities associated with each process specified in the use case diagram. These diagrams normally represent the decisions, parallel processes and internal sub processes associated with each use case scenario. They can be drawn either as a single complete activity to show the entire system’s behavior or by means of a ‘Swimlane activity’ diagram to depict the activities performed by each role in the system. 6. State diagrams These diagrams are used to show the system’s state based on various events occurred during its operation. Using these diagrams, the designer can specify the name of the state, the set of actions or functionalities that can be taken when the system is in that particular state and the event which is responsible for the system to go to a specified state. 7. Package diagrams These diagrams show the grouping of related classes that perform a particular functionality. 8. Component diagrams A collection of packages, classes and other externally available events which are needed for a particular functionality are grouped as a component. These diagrams show the various components, their parts and components interactions. 9. Deployment diagram This diagram shows the physical view of the system. It can be used as a physical model to show how the product should be deployed in the target system after the software is developed. Using this diagram, the developers can understand the devices, the processors and the components which are residing in each of these devices and processors and the communication links between the devices and processors.

Object Oriented Analysis and Design

1.4.3 Construction It is the next phase in software development life cycle in RUP. During this phase, the developers are provided with the design documents which are designed during the elaboration phase and will start the development process. During this phase, both development and testing activities are conducted. The individual modules being allocated to the team members are developed independently using the target programming language constructs. RUP encourages the use of reusability which helps the developers in identifying the existing off the shelf components being developed as part of the previous project development and some of the components from the language library available as part of the development platform. Apart from that, the new components are developed as per the object oriented principles and practices and will also be provided as class libraries which can then be used for other projects as reusable components. These individual developed components are unit tested by means of unit test cases which are derived from the requirements specification and design documents produced during the previous phases of the RUP process. This process includes all the white box testing techniques being normally applied for any code testing. The unit tested components are integrated and integration testing is conducted using the test plan along with customer’s stated requirements. This process utilizes the black box testing techniques being used to ensure the stated requirements against the functionality of the software. Apart from these regular testing methods, the testing techniques appropriate to OO are also applied in terms of use-based, thread-based, class-level, inter-class–level and relationship-based approaches. Once all these tests are being conducted successfully, the software as a whole is subjected for system testing which tests the entire behavior of the system under various conditions. Some of the system testing techniques include stress testing, load testing, performance testing, and smoke testing. Once the system testing is over, if any error has been identified, then appropriate corrective measures will be taken to uncover the errors and fix up the errors for further retesting. If there are no errors identified during the system testing, then the product is being sent for transition phase. Hence, at the end of construction phase, the complete coding part will be finished with test reports based on their performance at the host environment. The artifacts which are delivered at the end of this phase are: 1. Source code The code that has been developed in the target programming language specified in the requirements specification document. 2. Object code or intermittent code The intermittent code that is generated from the source code after compilation. 3. Test Reports: Unit Test reports, Test cases generated, Integrate testing

1.4.4 Transition Once the construction phase finishes with the complete workable product with stated requirements without any errors (99.9%), then it will be ready for release to the customer side. The transition phase is used to perform user acceptance testing and deployment of developed software to the customer side. Prior to the release of the software product, the transition phase includes the user acceptance testing activity which is done in two ways: Alpha and Beta testing. Alpha testing ensures the product’s functionality by getting the customer’s representatives or end users to come to the development organization to check its functionality. The user’s feedbacks will be collected and are then used for revising the product before the actual delivery of the product.

Rational Unified Process

If the product is a general purpose product being targeted for huge users such as Google, Gmail, etc., then a Beta testing will be conducted. This testing will normally be carried at the customer or user’s place with the final version of the product being released as a Beta release. The feedbacks will be sent to the developers’ organization for possible revising of the product based on the suggestions. Once user acceptance testing is completed, the product will be deployed to the customer side. Hence, the developed software product will be transited from the development site to the customer’s site. Then there onwards, support and maintenance process starts which helps the customers during their operations with the newly developed software. The following artifacts are the outcome of the transition phase: 1. Executables The executable file of the source code and other associated executables which are mandatory for the product to work in the target environment. 2. User manual and documentations The user manual and documentation should be provided along with the software to facilitate easy learning and working of the product. This may be a hard copy of the documentation, a help option built inside the software itself or by means of an online help facility which can be provided as a forum or a help desk facility. 3. Test cases repository The collection of test cases used for testing the software is kept in this repository. This is used at later stages such as maintenance and support to test the software for its intended functionality. 4. Test documentation This documentation provides the set of procedures followed in testing for different kinds of testing techniques applied to verify and validate the software product. 5. Test reports These reports are generated based on the outcome of the test data against the software. Both pass and fail test reports and the corrective actions taken to fix the errors are placed in these reports.

1.5

APPLICATION OF OBJECT ORIENTED DIAGRAMS IN RUP

Each of the life cycle phases of the RUP has been associated with development of UML diagrams which represent the object oriented design documents. This has been discussed in the following section. During inception phase, using the customers’ requirements, a use case view of the system is captured. This view helps to find out the primary processes or functionalities needed in the system with users who are interacting with the system through those processes or functionalities. This provides an overall view of the system based on the usage of the various persons, software, hardware and other resources such as servers being used in the system. At the end of inception phase, a primary use case diagram will be prepared. The details related to the development of this diagram will be discussed in detail in Chapter 6. During the elaboration phase, the hidden requirements are also collected and these are being provided as detailed user scenarios. The user’s interaction with the system and resources are established in a logical view. For each user scenarios, which are called as use case scenarios, a detailed or secondary use case diagram is drawn which shows the detailed view of user interactions with the processes in the system. Also, during this phase, class diagram which exhibits the presence of objects, their groupings into classes and their interactions is drawn. Using the class diagram as a basis, an object interaction diagram is prepared by creating objects for each classes represented in the class diagram with messages being represented as the interaction between them.

Object Oriented Analysis and Design

Once the logical view is over, the system is then analyzed from physical view which is used to show the state changes of the system with events triggering the state change by means of a state chart diagram. The internal activities of each process or functionality are represented by means of activity diagram. This diagram shows the parallel activities, decision sequences and internal division of activities among various entities of the system. In the physical view, a component diagram, package diagram, and deployment diagrams are developed. In a package diagram, a collection of classes performing similar functions or providing a single functionality are placed into a package, and likewise several packages are developed and their interactions are shown. These collections of packages are placed into components and these components and their interactions are showed in the component diagram. Then the final deployment of developed components into the appropriate processors and devices is represented by means of deployment diagram. During the construction phase, these diagrams are used as the basis for developing the reusable components in RUP. These design documents are also used for deriving test cases for testing the developed components. During the deployment phase, the developed components deployment to the target environment in terms of processors and devices is done using deployment diagram. Hence, all object oriented diagrams designed using UML are used in all the phases of the RUP model for better product development.

SUMMARY 1. Traditional life cycle models such as waterfall, incremental model, evolutionary life cycle model and agile models have both advantages and disadvantages in developing software. Each model is suitable for developing some applications of their nature. 2. The RUP model helps in developing the software using well defined development life cycle phases with clearly defined set of activities in each phase. All the applications that have object orientation can be developed using this model. The various phases in this development model have a specific purpose: (a) Inception During this phase, the communication with customers takes place to capture the initial set of requirements and further analysis over it. (b) Elaboration During this phase, requirements analysis and development of architecture and design documents are done. This phase is used to identify most of the requirements that were invisible during inception phase and estimation of schedule and the expected amount of resources. High-risk components are identified, mitigated and resolved during this phase. (c) Construction During this process, the developers are provided with the design documents which are designed during the elaboration phase and will start the development process. During this phase, both development and testing activities are conducted. (d) Transition The transition phase is used to perform user acceptance testing and deployment of developed software to the customer side. 3. The UML diagrams such as use case, class, interaction, state chart, activity, package, component and deployment diagrams are also drawn during the initial two phases of RUP which are then used during construction and transition for development and testing.

Rational Unified Process

MULTIPLE-CHOICE QUESTIONS 1. RUP is (a) iterative and incremental (b) use case driven (c) architecture centric (d) None of these (e) All the above 2. Rational Unified Process-System Engineering (RUP-SE), a version of RUP is tailored by ________ for System Engineering. (a) SPSS (b) History of IBM (c) Rational Software (d) IBM 3. The UP is a/an ________ process. (a) computer programming (b) iterative model with milestone (c) software deployment (d) IBM rational Unified process 4. In the UP, ________ are used to capture the functional requirements and to define the contents of the iterations. (a) IBM Rational Unified Process (b) Unified Modeling Language (c) Use case (d) Ivar jacobson 5. The name Unified Process as opposed to ________ is generally used to describe the generic process, including those elements which are common to most refinements. (a) Grady Booch (b) Ivar jaconson (c) Unified Modeling Language (d) IBM Rational Unified Process 6. Which of the following is not a software life cycle model? (a) Waterfall model (b) Spiral model (c) Prototyping model (d) Capability Maturity model 7. SDLC stands for (a) Software design life cycle (b) Software development life cycle (c) System development life cycle (d) System design life cycle 8. Waterfall model is not suitable for (a) Small projects (b) Accommodating change

Object Oriented Analysis and Design

9.

10.

11.

12.

13.

(c) Complex projects (d) None of these If requirements are easily understandable and defined, which of the following models is best suited? (a) Waterfall model (b) Prototyping model (c) Spiral model (d) None of these If requirements are frequently changing, which of the following models is to be selected? (a) Waterfall model (b) Prototyping model (c) RAD model (d) Agile mode If user participation is available, which of the following models is to be chosen? (a) Waterfall model (b) Agile mode (c) Spiral model (d) RAD model Unified process is iterative model with milestone (a) Iterative (b) Incremental (c) Evolutionary (d) All of these How many phases are in the unified process? (a) 4 (b) 5 (c) 2 (d) None of the above

EXERCISES Remember 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

What is the Unified Process (UP)? What is Iterative and Evolutionary Development? What are the benefits of iterative development? Why is Waterfall failure prone? What is the need for feedback and adaptation? What are agile methods? Name five agile principles. What is Agile modelling? What is an agile UP? What are the different UP Phases?

Rational Unified Process

11. 12. 13. 14. 15. 16. 17.

What is Inception? List any five inception artifacts. Define Requirements. What is meant by Elaboration Phase? What is the first iteration in the elaboration phase? What is Elaboration? What happens in inception?

Analyze 1. 2. 3. 4. 5. 6. 7. 8. 9.

How long is the Inception phase can be? What are the types and categories of requirements? What are the key requirement artifacts? What happened in the inception phase while entering the elaboration phase? What are the key ideas and best practices that manifest in elaboration? What artifacts may start in elaboration? What are the criteria used in planning the next iteration during elaboration phase? What are the likely activities and artifacts in inception? Why do we need use case description?

Understand 1. 2. 3. 4. 5.

Which object oriented diagrams are generated during inception phase? Which object oriented diagrams are generated during elaboration phase? Which object oriented diagrams are generated during construction phase? Which object oriented diagrams are generated during transition phase? How UML helps in RUP in developing software product using object oriented methods? Explain.

Create Create your own use case scenario and a use case description for an application which processes user’s feedback based on a survey.

RATIONALE FOR OBJECT ORIENTED DEVELOPMENT

2 CONCEPT MAP Rationale for OO Development

discusses

Software Development

Flavors of OO

done by

like

Structured Approach

OO Approach

Structured Vs. OO Approach

Entities

OO Constructs

includes

includes

Class Objects Attributes Methods Interface Package Components

Abstraction Encapsulation Information Hiding Hierarchy Polymorphism Message Passing

LEARNING OBJECTIVES After learning this chapter, readers will be able to

Factors Favoring OO

differentiated based on

Abstraction Hierarchy Decomposition

Rationale for Object Oriented Development

Have you ever noticed that the invention of a new technology has its dominance and profound effects on the existing similar types of technologies? The same effect happened in the software development field due to the invention of object orientation in the development process. Nowadays, the software developed to meet the real world requirements is highly complex in nature which cannot be solved by means of laboratory-based simple collection of computational steps. Consider that you belong to a software development organization which has its primary focus on developing software products to the real world problems such as banking applications, finance applications, tradeand commerce-based applications, medical, telecommunications, embedded applications, and so on. The development of these sorts of applications cannot be thought of as a simple program development having a sequence of computational tasks which are accomplished by means of a collection of algorithms. Rather it should be considered as a collection of interactions among various well-defined entities. The focus should be now on how these various entities in that domain interact with each other to achieve the required functionality. The paradigm shift now is on the collaboration of the entities to provide the expected functionality rather than on how to achieve the functionality. This improves not only the performance, reliability and availability of the software; but also improves the extensibility and reusability of the entities in the problem domain.

2.1 STRUCTURED APPROACH VERSUS OBJECT ORIENTED APPROACH Software development can be done using either of the following two ways: 1. Structured approach 2. Object-based or object oriented approach

2.1.2 Structured Approach During the early days of programming, the programmers applied a series of computational steps to process the data. They named this sequence of steps as algorithms. The data that they processed is stored in a systematic way so that storage and retrieval becomes easier. This type of representation is called data structure and is processed by means of algorithms. Such programming practices are called procedural oriented approaches or function oriented approaches or structured programming approaches. In this approach, the developer will code the algorithms as functions and related functions are grouped together to provide a higher level of function. Whenever there is a need, the higher level function will invoke the lower level functions. There will not be separate state for these functions; rather they all will be stored in the same shared memory in the program’s address space. Here, structured analysis and design method is applied and structure chart is developed as a design model. Structured programming practices include conventional approaches such as top-down or bottom-up to develop any software system. 1. Top-Down approach This approach leads to the decomposition of a larger system into a number of subsystems and each subsystem is then divided into a number of sub-subsystems which are further decomposed into components and then into elements which will form the last level of decomposition. This is depicted in Fig. 2.1. When top-down integration is applied, the system is developed by decomposing the system and when bottom-up is applied, the system is developed by combining elements at the same level to form the component at the next higher level and so on.

Object Oriented Analysis and Design

Fig. 2.1 Top Down approach in structured programming

Example: Employee Pay Roll Processing System In top-down-based structured approach, the system is decomposed as shown in Fig. 2.2, using a structure chart.

Fig. 2.2 Structure chart for pay roll application in structured approach

Rationale for Object Oriented Development

2. Bottom-up approach In the case of bottom-up approach, we will start from the aggregation and development from the leaves or the final level units at each level of the hierarchy. Here, the lower level components or units are first developed, and then they are combined to form the immediate higher level component, and once the components at that level are developed, they are combined based on their usage, integrated to form the next higher level of subsystem. The various subsystems at that level are then developed to form the complete system. The order proceeds in the following manner: Elements/units " Component (s) " Subsystem(s) " System Example: Employee Pay Roll Processing System In bottom-up-based structured approach, the system is decomposed as shown in Fig. 2.2, but in an upside down pattern using a structure chart. Here, units at the leaf level such as, calculate pf, calculate tax and other deductions, read personal details, read pay details, calculate allowances are completed first. Then based on their availability and applicability, the next higher level components are formed. In the given application, calculate deductions, calculate gross pay, read employee details are formulated using the appropriate lower level units. This is continued to the next higher levels till the entire system is developed by integrating the immediate lower level subsystems. 3. Combined approach Both top-down and bottom-up approaches may be used and combined in several ways that will depict the aggregation-and-uses relationships. In certain situations, some aggregate component needs some intermittent component to be developed even prior to other components in the same hierarchy or before all the elements at the lower level are finished. In those situations, both top-down and bottom-up approaches are mandatory. In Fig. 2.2, after a top-down approach is done to find out the deductions of an employee, it explores the hierarchy from Empoyee Pay Roll System " Payroll Processing " Calculate NetPay"Calculate Deductions. Once this level is reached, the bottom-up approach is applied which will invoke ‘Calculate PF’ and ‘Calculate Tax’ and other deductions module.

Drawbacks of Structured Approach Structured approach does not extend its support for reusability and extensibility. If any new functionality needs to be added or anything has to be updated, the entire program logic has to be revised irrespective of the amount of functionality required. In a real world scenario, one cannot expect that everything is in structured or algorithmic way. Rather, based on human perspective, everything in the world is viewed as a collection of objects. Say, for example, if you are looking around, you can see a variety of objects such as pen, pencil, monitor, CPU, keyboard, and so on. Each of these objects has different properties and their own purposes. If a problem is viewed as a collection of objects and the collaboration among them, instead of a collection of computational steps, problem solving will be an easier task. This leads the analysts to think about applying object oriented or object-based approach to the development process. Thus, object orientation comes into the picture.

2.1.2 Object Oriented Approach During the 1960s, object oriented (OO) approach came into problem solving. Several methodologies have been proposed by many researchers. Some of the methodologies include Booch Notation, Jacobson Methodology and UML-based approach. Before proceeding onto these different methodologies, one should understand the basic concepts of object oriented approach which is discussed in this chapter.

Object Oriented Analysis and Design

Fig. 2.3 A typical view of object oriented approach

Object orientation can be visualized by means of Fig. 2.3. Example: Employee Pay Roll Processing System Objects in the system: Employees at various levels, administrator, pay detail for each employee, pay slip and pay roll and other reports Base classes in the system: Person, employee, administrator, pay details, reports Support classes: DB access, user interface Interfaces: Employee category, pay calculation Packages/Name Spaces: Employee details, pay details, pay process, reports generation Components: Input data, process data, output generation Folder/Assembly: Pay roll process

2.2 OBJECT ORIENTATION IN SOFTWARE DEVELOPMENT PROCESS 2.2.1 Need for an Object Oriented Approach Real world applications are highly industrial strength software, which are not developed by amateur programmers working in isolation; rather they are developed by a team of efficient people in an organization who come out with competent software. This involves proper learning of the system.

Rationale for Object Oriented Development

Basically, any industrial strength software is very complex in nature and has a lot of disorderliness in it. This chaos must be brought to an order by applying some efficient techniques otherwise this will lead to software crisis—a situation in which the cost and schedule slippage occurs; organization’s reputation goes off and the limiting or omitting of customers requirements to avoid these will also happen. To avoid this, a competent approach that provides a perspective of the problem domain as having a collection of entities as the object oriented approach and not as a collection of computational steps as in the case of structured approach. Hence, the techniques such as abstraction, hierarchy and decomposition are applied in the problem domain to bring some order to the disorderliness to the chaos. We will see the difference between algorithmic approaches and object oriented approach as below: 1. Algorithmic versus object oriented abstraction 2. Algorithmic versus object oriented decomposition 3. Algorithmic versus object oriented hierarchy

2.2.2 Algorithmic Versus Object Oriented Abstraction Considering only the essential features of the system by omitting the inessential things is termed as abstraction. An abstraction may be viewed as an entity in isolation which has a very clear boundary from other abstractions. Some examples may be class, use case, document, etc. In a structured programming approach, a computational step or an algorithm is considered as one abstraction. These abstractions cannot be easily extended since if a computational step is modified, this will adversely affect all the modules depending on it. In an object oriented approach, each object, class, use case, etc., will be considered as an abstraction. These abstractions can be easily extended as they occur as distinct entities in the problem domain.

2.2.3 Algorithmic Versus Object Oriented Decomposition A problem domain cannot be solved with its present level of complexity. It must be decomposed into several subsystems which in turn must be divided into sub-subsystems and then into a collection of components and then into a collection of modules and so on till there are no further needs for decomposition as the final coarse of decomposition is reached. Usually this final level of decomposition is purely based on the perspective of the system analyst. When a system is being analyzed for its decomposition, it is usually done with the help of a domain expert. A domain expert is a person who has a sound understanding of the problem domain. This indicates that, a domain expert need not be a good developer or a higher level person. He/she can be an end user who is going to use the software after its deployment, or can be a floor level manager or even the CEO of the organization for which the software is going to be developed. The decomposition of a system involves, dividing the system into a collection of well-defined information and then applying some methodology over it to solve the system. The decomposition can be achieved in two ways: 1. Algorithmic 2. Object Oriented 1. Algorithmic decomposition The system is viewed as a set of computational steps, each of which is considered as one module in the system. Based on that, a top-down structured approach is applied. Usually, structure charts are used to show this top-down integration of the system functionalities. This highlights the order of events. This approach is very much suitable for structured programming

Object Oriented Analysis and Design

languages and not well suited for object oriented and object-based languages. Also, they are not well suitable for high complex systems. As it was discussed earlier, algorithmic-based decomposition considers each major step in the overall process as a module. It usually highlights the order of events in a pure top-down or bottomup way. It does not address the important properties needed in object-based and object oriented programming languages such as data abstraction, information hiding and concurrency. 2. Object oriented decomposition The risk of developing system from the scratch is avoided by working from small and then to the large complex systems is done in this type of approach. The system is viewed as a collection of autonomous entities working in isolation and can pass messages to other entities and can also process the messages from the entities acting on them. The entities are termed as objects which act and react based on the messages sent to them. An object can be a client or a server entity by which it can get the service from other objects and can provide service to other objects. The classes are used as the primitive building blocks of the object oriented system, which depict the similarities between objects. In the case of object oriented decomposition, the entire problem domain is decomposed as a collection of well-defined abstractions. The reusability and extensibility are highly feasible in this type of decomposition. It helps the developer to take intelligent decisions in dividing the system so that the complexity can be brought to an order. It visualizes the entire problem domain as having a collection of autonomous entities which are acting as agents that can either cause an action or the actions are carried out. This approach improves the important quality attributes of a complex system such as reusability, understandability, extensibility, dependability, and reliability measures.

2.2.4 Algorithmic Vs. Object Oriented Hierarchy Algorithmic Hierarchy Algorithmic hierarchy is top-down structured and is showed as having a collection of subsystems under a system and further when it is split up, this will be fine tuned till the primitive components are reached. The subsystems collaborate to provide a complete system.

Object Hierarchy Object hierarchy can be established in two ways: 1. Object hierarchy The object hierarchy shows how objects have values for their properties. It is usually depicted by ‘part of’ relationship. Consider a ‘Vehicle’ object. It has parts as engine, wheel, fuel tank, brake system, etc. Here, each of these parts themselves are objects and are placed inside the ‘vehicle’ object. This is an example for object hierarchy. 2. Class hierarchy The class hierarchy shows how classes are related with each other and it purely depicts ‘is a’ kind of relationship. Consider a ‘Vehicle’ class. This class can be used to create other classes like ‘Two Wheeler’, ‘Three Wheeler’, and ‘Four Wheeler’, etc. Here each of the created class is a type of ‘Vehicle’ class. This type of relationship is called ‘is a’ relationship and the hierarchy is called class hierarchy. Both of these two types of hierarchies are useful for analyzing the system and to formulate the object oriented model for the system. A typical system, after object oriented analysis and design contains both object hierarchy and class hierarchy.

Rationale for Object Oriented Development

2.3 FLAVORS OF OBJECT ORIENTATION According to Alan Kay, object oriented programming is based on the principle of recursive design. He visualized object oriented programming as a paradigm having the following characteristics: 1. Everything in the system is an object. 2. Objects perform computation by making requests of each other through the message passing. 3. Every object has its own memory, which may consist of other objects. 4. Every object is an instance of a class. A class groups similar objects. 5. A class is a repository for behavior associated with an object. 6. Classes are organized into singly-rooted tree structure called an inheritance hierarchy. From the above, one could wonder what are these classes and objects? Why do we need them? How to identify them from a given problem definition? So on. Let us see about the basic concepts of object orientation.

2.4 BASIC ENTITIES IN OBJECT ORIENTATION The basic entities in object orientation are given below. 1. Class 2. Object 3. Attributes 4. Methods 5. Access specifiers 6. Interface 7. Package 8. Component

2.4.1 What is a Class? “A class acts as a logical entity that works as a template for creating similar kinds of objects. It acts as a template to create similar kinds of objects. It shows the common properties of a collection of objects.” It usually acts as an abstraction for developing code in Object Oriented Programming (OOP). Using a class, one can create any number of instances that will hold their own values for the common properties. These values in turn are used to distinguish one object from another object even though they are instances of the same class. Some of the real world examples of classes are: book, car, trainer, vehicle, hardware, country, flower, etc. By using these classes, we can create similar kind of objects with same properties but with different values. Consider an example system, “Employee Pay Roll System.” This system has the following classes: employee, pay details and report. Using these classes we can create any number of employees in that organization, pay details for each of the employee and different reports such as monthly, quarterly, halfyearly, and yearly based on the user’s request.

Sample Class: Employee Class In C++: class employee { public: void read_emp_details();

Object Oriented Analysis and Design

void calc_pay(); void report_gen(); private: char* name; int empid; char* address; char* designation; }; In Java: class employee{ public void read_emp_details(); public void calc_pay(); public void report_gen(); private char[] name; private int empid; private char[] address; private char[] designation; } In C#: class employee{ public void read_emp_details(); public void calc_pay(); public void report_gen(); private char[] name; private int empid; private char[] address; private char[] designation; }

2.4.2 What is an Object? “An object is an instance of a class that has a well-defined collection of behaviors.” During the lifetime of an object, it can be in a state determined by the values of its attributes. It persists in a domain unless and until it is deleted. An object is a real world entity that exhibits some well-defined behavior at any point of time. The behavior of an object is composed of the current state of its attributes in terms of values and the operations it performs. Each object has a unique identity to distinguish it from all other objects in the problem domain. The following are some of the definitions of an object: 1. An object is an instance of a class. 2. An object occupies space in memory and has a definite life time. 3. An object is a real world entity that has a well-defined state and behavior. 4. A collection of similar types of objects is considered as a class.

Rationale for Object Oriented Development

5. An object combines values of the attributes (state) and the operations performed on these values (member functions/behavior). Example: From the previous code on the sample class ‘employee’, a collection of objects can be created as below: employee e1=new employee(“Jeya Mala,” 10, “Abraham Street,” “Professor”); employee e2=new employee(“Geetha,” 15, “Jesus Cottage,” “Professor”); employee e2, e4; Where, e1, e2, e2 and e4 are objects created from the class “employee.”

2.4.3 Attributes The attributes are the data portion of a class and they provide the state information of an object. They represent the properties that each object has and may be of different data types such as int, float, char, Boolean, etc. The values of the attributes in an object determine the current state of an object. In object oriented analysis, an attribute is associated with its type and the constraints imposed on it. When an instance is created, an initial value is assigned to it. Its value can be manipulated by means of the methods local to the object which provides services to other objects. Until object deletion, the attributes hold their values. In the “employee” class, the attributes are: private char* name; private int empid; private char* address; private char* designation; Here, private, public, protected, etc., are called access specifiers and are dealt in Section 2.4.8. An attribute may be of four types: 1. Direct attributes These are the basic attributes in a class which provide the current state information of the object created from the class. Example: In C++: private char* name; private int empid; private char* address; private char* designation; 2. Reference attributes These are the foreign attributes referenced from other classes. Example: protected int bpay; - present in pay_detail class If this attribute is used in employee class, then it is called a reference attribute. 3. Derived attributes They are derived from one or more direct attributes of a class. Example: protected int bpay; protected int hra, da, cca, ma; protected int allowance; Here, allowance is not a direct attribute; it is calculated from the direct attributes hra, da, cca and ma. So it is called a derived attribute.

Object Oriented Analysis and Design

4. Qualified attributes They are used to qualify a class for its association with other classes. Example: In employee_ personal_details class, we have the following attributes: protected int age; protected int experience; When this class is associated with Retired_Staff_Detail class, then age will be used as a qualified attribute which provides the insight into the association as it is based only on age and not on other attributes.

Representation of Attributes in Object Dictionary Once the attributes are created they are placed in the object dictionary for future reference. A typical specification of an attribute in an object dictionary is given below: 1. Name of the attribute 2. Informal description of the attribute 3. Purpose 4. Range of values 5. Related data items 6. Formal data structure applied

2.4.4 Methods The methods are also called operations, actions, and member functions. They provide a way to access the data inside the class which are provided by means of attributes. These methods contain the functionalities that each object will perform. They act as an agent to access the data members in a secured way. In the ‘employee’ class, the operations are: public read_emp_details(); public calc_pay(); public report_gen(); Example: From the above created objects, the operations can be invoked in the following manner: e2.read_emp_details(); e4=e1; e4.calc_pay(); e4.report_gen(); …

Representation of Methods in Object Dictionary 1. 2. 3. 4. 5. 6.

Name of the operation/method Informal description of the method Purpose Preconditions (to be satisfied by the client) Post-conditions (to be satisfied by the server) Input and output attributes (if present)

2.4.5 Interfaces An interface acts as an intermediate buffer that helps the classes to collaborate with each other. Usually, an interface is used to improve extensibility and reusability of classes. It contains only the attributes or attributes assigned with values and the method signatures (declarations) alone.

Rationale for Object Oriented Development

As the implementation or the definition is separated, the extensibility of the functional aspect of the system can be done by simply including the method signature without modifying the existing internal logic of the system. Example: In C++, a file created with ‘.h’ extension acts as an interface In Java, an interface is created as below: public interface employee_category { int emp_category; void add_employee(); void delete_employee(); void insert_category(); } In C#, it is created with the first letter “I”: public interface Iemployee_category { int emp_category; void add_employee(); void delete_employee(); void insert_category(); }

2.4.6 Packages A package is a collection of classes that exhibit a similar functionality or they together provide a specific behavior of the system. It is used to compartmentalize the software system by grouping the related classes and interfaces together under a single block. A software system may have any number of packages depending upon the similarity between the classes. A class that may be a part of one package can also be put up as a part of another package if it contributes the expected functionality of the package. A package can also contain a number of subpackages. Usually, a package improves reusability and extensibility by means of its cohesive nature. A version control system maintained for the software system will usually have these packages as their control points to give version to the older components when new functionalities are included. Example: In C++, a package is simply another ‘.h’ file which contains the other ‘.h’ files and other classes as part of it. In Java, a package is created by providing a keyword ‘package’ at the top of the class which needs to be a part of that particular package. package emp; import java.io.*; import java.lang.*; import java.sql.*; public class employee { …. …. }

Object Oriented Analysis and Design

public interface employee_category { …. } Now, the class employee and interface ‘employee_category’ are part of the package ‘emp’. To use this package in the next application, an ‘import’ statement should be used. import emp.*; public class payprocess { …. } In C#, the package is represented as a “namespace” which compartmentalizes the classes into different blocks. namespace emp; { public class employee { …. } public interface Iemployee_category {….} } Now, the class “employee” and interface ‘Iemployee_category’ are part of the namespace ‘emp’. To use this package in the next application, a “using” statement should be used. using emp; public class payprocess { …. …. }

2.4.7 Components A component is a modular building block for computer software. As per Object Management Group (OMG), it is defined as a modular, deployable, and replaceable part of a system that encapsulates implementation and exposes a set of interfaces. It is a collection of packages that provide a specific functionality. A system may contain any number of components. A payroll process component has the packages ‘emp’ and ‘pay’ as its parts. These packages collaborate among themselves by means of the operations performed in the classes inside them and provide the required functionality. Also, a component should collaborate and communicate with other components and other external entities (other hardware and software components) in the environment to provide the intended functionality. In structured approach, a component is usually called a module and acts as either a control component, problem domain component, or an infrastructure component. In object oriented approach, it contains a collection of collaborating classes compartmentalized as packages. Each class in turn consists of the fully implemented attributes, operations, and interfaces. The components will contain base classes, interfaces and other needed support classes to collaborate with the environment.

Rationale for Object Oriented Development

Components in an object oriented system design facilitate the following: 1. Easy maintenance as they are independent and provide a particular functionality. 2. Modification and extension are easier. 3. Optimizes the development process by means of reusability. 4. Improves reliability and security. In order to have these advantages, the components must be developed with clearly defined interfaces, hides the implementation details and the coupling with other components should be minimal but cohesiveness of the internal parts should be higher.

2.4.8 Access Specifiers/Visibility Control Basically, all the attributes are local to the objects and are global to the services or the methods inside the same objects. Apart from attributes and methods, a class or an interface can also be provided with the following access specifiers: 1. Public The member data and member functions/methods with this access specifier can be viewed and manipulated by any other class. They provide an external view to all other classes. 2. Private The member data and member functions/methods with this access specifier can be manipulated only within a class. They provide an internal (implementation) view which can be accessible only within the class definition. 3. Protected The member data and member functions/methods with this access specifier are accessible within the class definition or within the definition of child classes. In Java, protected is used to mean accessibility within the same package. 4. Static It means that all instance share the same value. A single memory location will be allocated per class. 5. Friend It means that even the private attributes can be accessed by the derived classes and the classes which created objects for the friend classes. The following access modifiers are unique to C#. 1. Internal Access is limited to classes in the same assembly or types derived from the containing class. This is the default access for all C# classes. 2. Private Applies only to a nested class. Access is limited to the container class. 3. Protected internal The only case where multiple modifiers may be used. 4. Final It is available in Java only, and means it will not be reassigned. (C++ has const keyword that is similar, although not exactly the same.) Typically methods are public and data fields are private, but either can be placed in either category.

2.5 OBJECT ORIENTED CONSTRUCTS Any object oriented programming paradigm has the following constructs: 1. Abstraction 2. Encapsulation and information hiding 3. Inheritance 4. Polymorphism 5. Message passing

Object Oriented Analysis and Design

2.5.1 Abstraction This property hides the inessential details and shows only the necessary details in order to bring out more clearly the structure of a process or an artifact. Any system is considered as a collection of well-defined abstractions. This may be given as levels of details. Each level will have its own level of abstraction. When preceded to the next level, it may reveal some details; yet hiding inessential ones at that level. For example, in developing a system, at the highest level, a “program” is considered as an abstraction of interacting objects. The next level of abstraction is a “Package” or “NameSpace” in Java and C# respectively which allows a developer to surround a collection of objects with a layer and control the visibility of these objects from outside the layer. The next level of abstraction may be the relationship between two individual objects in such a way that one is providing service and the other is receiving the service. At this level, classes and interfaces are used to provide this type of abstraction. public interface stack { public void push (Object val); public Object top () throws EmptyStackException; public Object pop () throws EmptyStackException; } Next we look at the class LinkedList which uses the interface “stack” and provide the implementation part: public class LinkedList implements Stack { public Object pop () throws EmptyStackException { ... } ...} Here, the first level of abstraction is at the highest level which is provided by means of the interface ‘stack’. The next level is ‘LinkedList’ class. Say, you want to implement a Circularly LinkedList then, it can be created from the abstraction LinkedList. Now, each method’s implementation can be either directly used from the abstraction LinkedList or can be a modification or an extension of the existing method implementation details. public class CircularlyLinkedList extends LinkedList { ... public Object pop () throws EmptyStackException { if (isEmpty()) throw new EmptyStackException(); removeFirst(); // delete first element of list }... } Because of this clear separation of concerns at each level, it is very easy for the developers to often move quickly back and forth between levels.

2.5.2 Encapsulation This is the most important and crucial property of Object Orientation. Using this flavor, one can place the member data and the member functions which act on those data to be placed in a single capsule. This can be visualized using Fig. 2.4. As shown in Fig. 2.4, the member functions and member data are placed in a capsule and if any code wants to access the member data of this capsule, this can be done only through the member functions. Hence, this will avoid the direct access to the member data. The access will now be given in a highly

Rationale for Object Oriented Development

systematic manner in which the member functions as per the functionality given in them will access the member data. For instance, consider a class called ‘employee’, which has the following definition: class employee { public: void read_emp_details(); void calc_pay(); void report_gen(); private: char* name; int empid; char* address; char* designation; };

Member data

Member functions

Member functions

Member data

Fig. 2.4 Encapsulation of member data and member functions

The member data and member functions of ‘employee’ class are now placed in a wrapper and to access any member data, the other clients should use only the member functions.

2.5.3 Information Hiding A developer who wants to develop an object and does not want to show how the internal details work, he will use interface-implementation separation. The implementation details are hidden from any other developer who simply wants to reuse the software component developed by another developer. He needs only to understand the mechanism to invoke the functions by means of the interface. It is not necessary for the other developers to have detailed information concerning matters such as the techniques used to implement the component. Thus, the interconnectedness between software systems is reduced. This will further reduce the complexity of the software development process. Also, any inadvertent changes could be avoided by means of this interface implementation separation based information hiding approach. This helps the developer to divide the implementation and interface thus allows a secured access to the data members by hiding them from external access. The “interface part” provides an “outside view” or “service view” which describes the functionalities an object provides. By seeing it, the others can understand how to invoke functions to manipulate the data members in the object. The “implementation view” or an “inside view” describes how an object does these specified functionalities. These internal details are not visible to the others who are in need of a service from an object. Example: Consider an example in C++ The interface part is – “emp.h” which is created as below: #ifndef _emp_h #define _emp_h class employee {

Object Oriented Analysis and Design

public: void read_emp_details(); void calc_pay(); void report_gen(); private: char* name; int empid; char* address; char* designation; }; #endef The implementation part is emp.cpp which is created as below: #include “emp.h” employee:: void read_emp_details() { cout name; coutempid; coutaddress; coutdesignation;} In this example code, the implementation of “read_emp_details()” is taken out and is hidden from the other developers as they were allowed to see only the interface part “emh.h”. As, the function’s signature is only available in the interface it restricts the improper accessing of method implementation. Now, to access this method, an object for the class employee is created and is used to access this method. employee e; e.read_emp_details(); For the outside world, this method signature is used to get the functionality which thus leads the internal implementation details be hidden from the other developers. This has helped the implementation details be hidden from the other classes or components.

2.5.4 Hierarchy There are two types of hierarchies used in object oriented approach to reduce the complexity involved in the software development process. 1. Class hierarchy 2. Object hierarchy

Class Hierarchy This is also called ‘is a’ hierarchy which shows the class structure in a system. Each hierarchy is layered in which at the top most level, an abstract class will be placed and then the detailed classes are added in the subsequent levels till the final primitive classes. As a simple real world example, consider a vehicle. A two wheeler is a vehicle; a four wheeler is a vehicle; a three wheeler is a vehicle. A bike is a two wheeler and is basically a vehicle. A car is a four

Rationale for Object Oriented Development

Fig. 2.5 Example of class hierarchy

wheeler and is basically a vehicle and so on. This sort of relationship is called as “is a” relationship. It is depicted in the following Fig. 2.5. For a real world application, consider that you are involved in an “Employee Management System for a University.” Here, ‘employee’ class is at the top level which shows only an abstract view of the common properties of employees in an organization. If it is a University, then at the next level, the ‘employee’ class may be detailed as ‘teaching’ and ‘non_teaching’. Then ‘teaching’ is detailed as ‘professor’, ‘assistant_professor’, ‘lecturer’, etc. Similarly, ‘non-teaching’ is detailed as ‘office_clerk’, ‘assistant’, ‘peon’, etc. This level can be treated as the primitive level if it cannot be further detailed. Here, ‘lecturer’ class is a type of ‘teaching’ class which in turn is a type of ‘employee’ class. Hence, the ‘is a’ relationship exists in class structure. This is depicted in the following code: class employee {} class teaching extends employee {} class non_teaching extends employee {} class professor extends teaching {} class assistant_professor extends teaching {} class office_clerk extends non_teaching {}

Object Hierarchy This is also called ‘part of’ hierarchy which shows the object structure. This shows how the objects are contained within each of the created objects. Consider that you have a collection of two wheelers namely TVS Apache, Honda Activa, Splender Pro and Discoverer. From Fig. 2.5, it has been inferred that, these entities are created from the class ‘Bike’ which is basically a two wheeler by means of instance creation. These are termed as objects as they now have properties unique to them. When you analyze these two wheelers, you could have identified a lot of internal parts such as engine, brake system, fuel tank, speedo meter, indicator, etc., each of them are from different makes and with different capacities. Each of these internal parts themselves is a class and the unique objects are manufactured based on their expected properties. The classes, objects, and object hierarchy for ‘vehicle’ class is showed in Fig. 2.6.

Object Oriented Analysis and Design

Fig. 2.6 Example of object hierarchy

Everybody knows that, a bike has an engine in it. This engine can be a two-stroke engine, four-stroke engine or a 225CC engine, etc., which can be fit up with a bike. Here, ‘engine’ is a class and other entities are objects. Now, say TVS Apache has 225CC engine; this indicates that an object named TVS Apache contains another object named 225CC engine. Similar to that, a particular two wheeler can have ‘n’ number of parts each of them in turn are objects. Each such object may contain other objects too. This is called as ‘part of’ relationship. It leads to the object hierarchy and is depicted by means of the Fig. 2.6. Now, coming back to the same real world example ‘Employee Management System for a University’; in this example, ‘pay_details’ is a part of ‘lecturer’, ‘assistant_professor’, and ‘professor’ classes but is not a kind of employee. So, an object created from ‘pay_details’ class is considered to have ‘part of’ relationship with the said classes. This is depicted in the following code: class employee {} class pay_details {} class professor extends employee { Public: void paycalc(); … } professor:: void paycalc() {

Rationale for Object Oriented Development

pay_details p; p.getdetails(); …} When an object is created for ‘professor’ class, the object hierarchy will contain an object for the ‘professor’ class at the highest level and then an object for ‘pay_details’ class which is a part of the professor class.

2.5.5

Polymorphism

It is an essential feature of an object oriented approach. It builds upon inheritance property. It allows run-time interpretation of object type for a given class hierarchy. It is also known as late binding. It is implemented in C++ using virtual functions. It is the run-time determination of which function to call for a particular object of a derived class based on the type of the argument. In C++, by declaring a member function to be virtual, it instructs the compiler to generate code that guarantees dynamic binding. The dynamic binding requires passby-reference. Example: In Java, we have pay_calc() method in base and the derived classes. The invocation of the right method is done by means of dynamic binding. class employee { void pay_calc(); } class teaching extends employee { void pay_calc(); void pay_calc(char[] qualification); } class non_teaching extends employee { void pay_calc(); } When an object is created for teaching class, which pay_calc() function will be invoked? At this point, there are three pay_calc methods two in the same class and one in the base class ‘employee’. By passing the parameter at runtime, the appropriate method is called for. If no parameter is passed, then again there is a conflict on which pay_calc() to be called either the base class method or the derived class method. This can be avoided by means of run-time binding of requests using super keyword in the derived class method. Polymorphism thus allows different versions of a function to be called in the same manner, with some overhead.

2.5.6 Message Passing Assume that, you are an organizer of an event. To accomplish the tasks associated with it, you need to pass the messages to your colleagues or to your classmates by sending either an e-mail message or an SMS or an MMS, and so on. By means of it, you facilitate the communication with others and establish a collaborative work which thus leads to the success of the event. Similar to that, to achieve the required behavior of the software, the identified objects must collaborate with each other by means of establishing the proper communication between them.

Object Oriented Analysis and Design

In object oriented approach, the methods in a class are the communication vehicles which pass the messages between objects by performing some actions in response to the requests. An object can request a service from another object by calling a method which is present in that object. Similarly, an object can provide service by accepting requests from other objects. This is called message passing. If an object provides a service in response to a request, then it is called a server object and an object which sends the request is called a client object. In some cases, an object may act as an agent between the client and the server which will receive the request from the client and forward it on to the server to get the process to be done. Consider that, you want to build a house. For doing this, you will approach a building contractor who can do the job of brick works and floor works; an electrical contractor to establish electrical works and a plumber to carry out the job of plumbing work for your home. To have these jobs to be done, you will establish a contract between these people in which you need to satisfy certain preconditions in terms of giving funds at periodic intervals, providing materials and so on; and in turn the contractors should perform the required activities by satisfying the post conditions with respect to the plan and the expected completion of the work in the expected manner. In this example, you are the client who has to follow certain protocols in terms of the preconditions and the contractors are the servers who are providing service to you by satisfying the post conditions. If any of the preconditions or the post conditions is violated, then the contract will break which lead to problem in getting the required functionality done. Similar to this, an object which needs some service will send a request by means of method invocation. For this, the requesting object has to satisfy some of the prerequisites, further the messages should be passed only by following the method signatures. These will now collectively act as the preconditions. If any of these preconditions are not satisfied, this will be termed as a precondition violation. To start up a proper communication, the client should first satisfy the preconditions. Once the request is received by the object which has the functionality to provide the intended operation, it has to process the request and send back the proper response to the client. This object is called a server and the response type that it has to respond is imposed in the method signature itself. Based on the outcome, the state and behavior of the system should change in the expected manner. If not, this will be considered as a post-condition violation. Hence, to achieve the required functionality of the system, the client object and the server object should satisfy the preconditions and the post conditions respectively. This is called contract-based modeling. In C++, Java and other object oriented programming languages, this is done by creating an object for a server class and then invoking the required method from that object. In the above example, the ‘professor’ class created an instance for ‘pay_details’ class and then the getdetails() method is called through this object which is a part of the pay_details class. Here, the object for professor class is called a client and the object created for pay_details class is called the server. To prevent precondition violation, the method signature should not be changed. void professor:: paycalc() { paydetails p; p.getdetails(); …} …. professor pro; pro.paycalc(); Here, object ‘pro’ created from professor class is acting as a client and the paydetails object ‘p’ acts as a server as it provides service to the professor object.

Rationale for Object Oriented Development

2.6 FACTORS FAVORING THE CHOICE OF OBJECT ORIENTED DEVELOPMENT The following are the major reasons for the industries moving towards object oriented software development: 1. Difficulty in visualizing the real world problem domain as a collection of functions. 2. Lack of visibility in collecting the data from the domain in structured approach. 3. Less reusability of software components in structured approach. 4. Object oriented approach works based on the higher level abstractions. 5. Less redundancy of code and development process steps. 6. Secured access of data by means of encapsulation and information hiding. 7. Improved coding practices are encouraged by means of object oriented concepts such as abstraction, encapsulation, Interface-implementation separation, polymorphism and inheritance. 8. Reusability of code by means of classes and objects.

Object Oriented Analysis and Design

CASE STUDIES Case Study 1: Library Management System

Structured V. Object Oriented Abstraction and Decomposition Structured approach The abstractions are nothing but the key functionalities. List of functionalities 1. Apply for membership 2. Access the system 3. Issue of books 4. Search 5. Catalog 6. Entry for the new books 7. Procurement of the books 8. Return of books 9. Distributed functionality 10. Availability of the books 11. Outstanding 12. Fine calculation 13. Books maintenance 14. Managing library transactions like issue return, etc. 15. Maintaining member details 16. Procuring books from suppliers 17. Managing suppliers

Object oriented approach 1. 2. 3. 4. 5. 6.

Book Member Supplier Librarian Book transaction Purchase As the entire problem domain is decomposed into six abstractions, it is now possible to assign the responsibilities to each of these abstractions and specify the collaborations between them to establish the required behavior of the system.

Abstractions and their responsibilities Member Apply for Membership, Access the system, Search, Return of books, Outstanding. Librarian Issue of books, Return of books, Availability of the books, Taking care of books, Procuring books from suppliers, Fine calculation. Book Books Maintenance, Search, Catalog, Entry for the new books, Procurement of the books. Book transaction Issue of books, Return of books, Availability of the books, Fine calculation.

Rationale for Object Oriented Development

Supplier Managing suppliers. Purchase Procuring books from suppliers. As we have seen, if any new functionality needs to be added to the system, it is easier in object oriented approach as the responsibilities are associated to the objects based on their intended behavior. Also, it is easier to identify the collaboration among the objects based on the operations which are responsible for providing a collaborative behavior. In the above example, Librarian abstraction has its collaboration with all the other abstractions only in the specified ways. Member abstraction is associated with Librarian, Book and Book Transaction alone. Supplier abstraction is related with Librarian, Book and Purchase alone. Now, a clear separation is provided between the abstractions based on their collaborative behavior. In the case of structured approach, any extension of the existing functionality will lead to a lot of rework as each operation is highly coupled with other operations and is dependent on one another for the proper functioning of the system.

CASE STUDY 2 Consider a Program to Accept the Radius of a Circle and Display the Area and the Perimeter. Accept the Height of a Cone and use the Same Circle as its Base and Calculate its Area and Perimeter.

Structured Vs. Object Oriented Hierarchy Algorithmic approach Main() { float radius, area, peri; cin >> radius; area = 2.14 * radius * radius; peri = 2 *2.14 * radius; cout