Software Engineering & Object Oriented Modeling

Jitendra JD Patel

Description

Software Engineering and Object Oriented Modeling: This book is specially written for those who are interested in understanding software engineering and Object Oriented Modeling concepts using UML in the Computer Engineering and Information technology field and want to gain enhanced knowledge about the power of UML Language in software development.

Also everyone with interest in learning UML for Software Engineering for application development can refer to this book to get the knowledge about various features of this subject.

Sujets

• Langages
• Computers
• Informatique
• UML

Informations

• Publié par: eBookIt.com
• Date de parution: 21 février 2013
• Nombre de lectures: 0
• EAN13: 9781456612542
• Langue: English

Extrait

Software Engineering and Object Oriented Modeling
By Jitendra Patel

Overview
Software Engineering and Object Oriented Modeling: This book is specially written for those who are interested in understanding software engineering and Object Oriented Modeling concepts using UML in the Computer Engineering and Information technology field and wants to gain enhance knowledge about power of UML Language in software development.
Also every one with interest in learnign UML for Software Engineering for application development can refer this book to get the knowledge about Various features of this subject.
Copyright © 2012 Jitendra Patel
Software Engineering and Object Oriented Modeling: Copyright reserved by the Author
All rights reserved. No part of this book shall be reproduced, stored in a retrieval system, or transmitted by any means, electronic, mechanical, photocopying, recording, or otherwise, without written permission from the publisher. No patent liability is assumed with respect to the use of the information contained herein. Although every precaution has been taken in the preparation of this book, the publisher and author assume no responsibility for errors or omissions. Nor is any liability assumed for damages resulting from the use of the information contained herein.
Warning and Disclaimer
Every effort has been made to make this book as complete and as accurate as possible, but no warranty or fitness is implied. The information provided is on an "as is" basis. The authors and the publisher shall have neither liability nor responsibility to any person or entity with respect to any loss or damages arising from the information contained in this book.
Dedication
This book is dedicated to my honorable parents and beloved students who are my favorite person in the world.
PREFACE
I want to thank a number of people at my institute for helping me to solve the difficulties of lab manual and finding the solution of various critical problems I faced during writing the development.
As the reader of this book, you are my most important critic and commentator. I value your opinion and want to know what I am doing right, what I could do better, what areas you'd like to see us publish in, and any other words of wisdom you're willing to pass my way.
As an author of this book, I welcome your comments. You can email or write me directly to let me know what you did or didn't like about this book as well as what I can do to make the book better.
When you write, please be sure to include this book's title and author as well as your name, email address, and phone number. I will carefully review your comments on the book.
Contents
Chapter 1 Software Engineering: Disciplined Software Development 1
Why is software engineering different from programming? . 1
Technology Invariance and Skills Survival 1
Towards a Disciplined Realistic Software Development Process . 1
Chapter 2 Coordination in Team-based Software Development: Role of the “Blueprint” . 3
Team Work: The Need for Coordination . 3
Software Blueprint: A Mediating Element for Team Coordination. 4
Chapter 3 Project Management Tools: Timeline Charts and Project Schedule Estimation . 5
Planning and scheduling the activities for Your Project: Gantt and PERT Charts . 5
Gantt Chart 5
PERT Chart 5
Software Cost Estimation . 5
Source Lines of Code . 5
The Scale Drivers . 5
Cost Drivers . 5
COCOMO II Effort Equation . 5
Effort Adjustment Factor 5
COCOMO II Schedule Equation . 5
Staffing Levels . 5
Incremental Efficiency . 5
The SCED Cost Driver 5
Chapter 4 Introduction to the Unified Software Development Process and OO Analysis . 5
The Unified Software Development Process . 5
Limitations of the Unified Process . 5
Design of a PERT Chart Tool: Example of ULM Concepts . 5
Use Cases . 5
Analysis . 5
Design . 5
Implementation . 5
Test 5
Chapter 5 UML Diagrams and How to Use Them ... 5
Why is UML important? . 5
Use case diagrams . 5
Medical clinic diagram, expanded . 5
Class diagrams . 5
Aggregation and Composition . 5
Packages and objects . 5
Object diagrams . 5
Sequence diagrams . 5
Collaboration diagrams . 5
Statechart diagrams . 5
Activity diagrams . 5
Component and deployment diagrams . 5
Chapter 6: Towards a Systems Methodology for Object-Oriented Software Analysis . 5
A Short Review of the System Modeling Methodology . 5
Hierarchy of System specifications . 5
Modeling . 5
System morphisms as a fundamental means for building abstractions . 5
Use case driven design in the system modeling perspective . 5
Improved Software Development Process . 5
System-centered approach for use case descriptions . 5
Architecture for embedded systems . 5
System morphisms as a means to build information models . 5
Application Example: Elevator Control System ... 5
Summary . 5
Chapter 7 Getting the Big Picture: Hierarchical Modular Component Architecture . 5
Systems Hierarchical Modular Composition Framework . 5
Example – The Elevator Revisited . 5
Combining the Hierarchical and Object Views . 5
Summary . 5
Chapter 8 Object Behavior Specification . 5
Is an Object Specification Unambiguous, Complete and Consistent? . 5
State Equation-based Object Behavior Specification . 5
An State-Equation OBS is Unambiguous, Complete and Consistent 5
Example: Read/Write Access . 5
Definition of Object Behavior 5
Chapter 9 Containers: An Object Behavior Specification . 5
Class entity . 5
Container Base Class . 5
Ensemble Methods . 5
Examples . 5
Container Subclasses: Unordered . 5
Bags and Sets . 5
Class set 5
Class Relation . 5
Class Function . 5
Chapter 10 Ordered Containers and Their Implementation . 5
Class Order 5
Stacks and Queues . 5
Object Behavior Specifications for Stack and Queue . 5
List as a Subclass of Order 5
Chapter 11 Testing Based on Behavior Specification . 5
The Look-and-See Method . 5
Testing Rudiments . 5
Blueprint-Based Testing . 5
Constructing Behavior Samples . 5
Normal Behavior Example: Testing the Alarm Class . 5
Testing Constructors for Correct Initialization . 5
State Transition - based Testing . 5
Chapter 12 Systems Based Testing Methodology in Relation UML .. 5
References . 5
Chapter 1 Software Engineering: Disciplined Software Development
Why is software engineering different from programming?


According to the IEEE definition, software engineering is the application of a systematic, disciplined, quantifiable approach to the development, operation and maintenance of software that is, the application of engineering to software.

Disciplined approaches to software development are gaining greater acceptance in practice these days. This is especially true in projects where safety is absolutely critical, such in airplane control software, or where a software crash could cause a major foul-up such as in the telephone system. But it is also true in general as software developers strive to achieve higher levels of maturity on the Software Enterprise Institute’s (SEI ) scale (Figure 1).


Figure 1 The SEI Levels of Maturity

The SEI hierarchy is a model of achievement that is becoming widely accepted as a credential necessary to qualify to bid on a contract. So it is important that students not only have the basic programming skills but also the understanding of formal principles that enable them to fit into high SEI-ranking software organizations.

Object-orientation provides a powerful way to build complex software systems, a claim supported by the overwhelming adoption of C++ and Java as programming languages of choice, with installations in the hundreds of thousands. Nevertheless, a programming language by itself does not provide a set of sound principles to use -- you can just as easily program poorly in C++ as in its non-object-oriented predecessor, C. Thus, this course offers principles for object-oriented system development that guide the effective application of object-oriented programming constructs.
Technology Invariance and Skills Survival
Technology is moving toward increased networked and distributed computing and this will certainly influence the programming language standard. Java currently is the object-oriented language for World Wide Web programming. But standards and specifications are more permanent than languages and technologies. We can see this as the premise underlying the effort to define a Common Object Request Broker Architecture (CORBA). This effort, supported by many of the world’s leading information age companies, is to provide workable specifications that will enable objects to interact by adhering to common interfaces while hiding the details of their implementations (vendors, languages, technologies, etc.).

Principles are even more permanent than specifications. So the concepts we present here, while shown to work in C++ and Java, are also aimed at future languages, technologies and systems that are likely to be distributed, parallel and global. They will help you surf with the waves of technology change that can be expected in the next century.

Towards a Disciplined Realistic Software Development Process
What distinguishes a principled software engineering process from programming practice? A series of diagrams will suggest the answer. Figure 2 caricatures our natural programming tendencies. There are three steps:

conceptualize : think about the problem
write code : express your ideas directly in programming form
debug : execute and modify the code until it does what you want

Figure 2 Common Programming Practice
On the other hand, software engineering texts prescribe methodologies for software development that are much more disciplined. Figure 3 illustrates one version of such a methodology. According to it you should:

1. formulate requirements to express the desired behavior the software
2. specify : express the behavior e