Object Oriented Analysis and Design Introduction.

Slides:



Advertisements
Similar presentations
September 2008Mike Woodard Rational Unified Process Key Concepts Mike Woodard.
Advertisements

The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Object-Oriented Software Development CS 3331 Fall 2009.
CS487 Software Engineering Omar Aldawud
 2004 by SEC Chapter 2 Software Development Process Models.
MapleLeaf, LLC SDLC Methodology. MapleLeaf, LLC, has established standard phases and processes in regards to project management methodologies for planning.
Ch 3 System Development Environment
Object-Oriented Analysis and Design
Chapter Extension 19 Alternative Development Techniques © 2008 Pearson Prentice Hall, Experiencing MIS, David Kroenke.
Fall 2007CS 225 Introduction to Software Design Chapter 1.
1 SOFTWARE LIFE-CYCLES Beyond the Waterfall. 2 Requirements System Design Detailed Design Implementation Installation & Testing Maintenance The WATERFALL.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Week 8 Implementation Design Alex Baker. Implementation Design System Design – Describes what the system should do Implementation Design – Describes what.
CS350/550 Software Engineering Lecture 1. Class Work The main part of the class is a practical software engineering project, in teams of 3-5 people There.
1 CMSC 132: Object-Oriented Programming II Nelson Padua-Perez William Pugh Department of Computer Science University of Maryland, College Park.
© Copyright Eliyahu Brutman Programming Techniques Course.
COMP 350: Object Oriented Analysis and Design Lecture 2
Objectives Explain the purpose and various phases of the traditional systems development life cycle (SDLC) Explain when to use an adaptive approach to.
CHAPTER 17 Building Software to Support an Agile Organization
Mastering OOA/OOD with UML. Contents Introduction Requirements Overview OOAOOD.
Introduction to Software Design Chapter 1. Chapter 1: Introduction to Software Design2 Chapter Objectives To become familiar with the software challenge.
Chapter 1 The Systems Development Environment
Chapter 2: Approaches to System Development
Introduction to RUP Spring Sharif Univ. of Tech.2 Outlines What is RUP? RUP Phases –Inception –Elaboration –Construction –Transition.
1 IBM Software Group ® Mastering Object-Oriented Analysis and Design with UML 2.0 Module 1: Best Practices of Software Engineering.
2Object-Oriented Analysis and Design with the Unified Process Objectives  Explain the purpose and various phases of the traditional systems development.
Transforming Organizations
Business Driven Technology Unit 5 Transforming Organizations McGraw-Hill/Irwin Copyright © 2013 by The McGraw-Hill Companies, Inc. All rights reserved.
The Rational Unified Process
-Nikhil Bhatia 28 th October What is RUP? Central Elements of RUP Project Lifecycle Phases Six Engineering Disciplines Three Supporting Disciplines.
Chapter 1: The Object-Oriented Systems Development Environment Object-Oriented Systems Analysis and Design Joey F. George, Dinesh Batra, Joseph S. Valacich,
Understand Application Lifecycle Management
1 ISA&D7‏/8‏/ ISA&D7‏/8‏/2013 Systems Development Life Cycle Phases and Activities in the SDLC Variations of the SDLC models.
©Ian Sommerville 2000, Mejia-Alvarez 2009 Slide 1 Software Processes l Coherent sets of activities for specifying, designing, implementing and testing.
MCS 270 Spring 2014 Object-Oriented Software Development.
Introduction to Software Design Chapter 1. Chapter Objectives  To become familiar with the software challenge and the software life cycle  To understand.
CPSC 2150 August 21, Chapter 1 Object Oriented Software Development This is an introductory course In this chapter we will look at 3 topics Challenges.
Introduction To System Analysis and Design
Object-oriented Analysis and Design Stages in a Software Project Requirements Writing Analysis Design Implementation System Integration and Testing Maintenance.
Chapter 7 Software Engineering Introduction to CS 1 st Semester, 2015 Sanghyun Park.
Chapter 2 Iterative, Evolutionary, and Agile You should use iterative development only on projects that you want to succeed. - Martin Fowler 1CS
GRASP: Designing Objects with Responsibilities
Rational Unified Process Mr Hisham AlKhawar. Iterative versus Waterfall  We need to use a life cycle model in order to approach developing a system easily,
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
2 2009/10 Object Oriented Technology 1 Topic 2: Introduction to Object-Oriented Approach Reference: u Ch.16 Current Trends in System Development (Satzinger:
CIS 112 Exam Review. Exam Content 100 questions valued at 1 point each 100 questions valued at 1 point each 100 points total 100 points total 10 each.
Chapter 7 The Practices: dX. 2 Outline Iterative Development Iterative Development Planning Planning Organizing the Iterations into Management Phases.
WATERFALL DEVELOPMENT MODEL. Waterfall model is LINEAR development lifecycle. This means each phase must be completed before moving onto the next!!! WHAT.
The principles of an object oriented software development process Week 04 1.
Software Engineering and Object-Oriented Design Topics: Solutions Modules Key Programming Issues Development Methods Object-Oriented Principles.
The System and Software Development Process Instructor: Dr. Hany H. Ammar Dept. of Computer Science and Electrical Engineering, WVU.
Process Asad Ur Rehman Chief Technology Officer Feditec Enterprise.
Rational Unified Process Fundamentals Best Practices of Software Engineering Rational Unified Process Fundamentals Best Practices of Software Engineering.
1 SYS366 Week 1 - Lecture 1 Introduction to Systems.
Software Development Process CS 360 Lecture 3. Software Process The software process is a structured set of activities required to develop a software.
Introduction Requirements and the Software Lifecycle (3)
Systems Development Life Cycle
Software Development. The Software Life Cycle Encompasses all activities from initial analysis until obsolescence Analysis of problem or request Analysis.
Software Development.
Process 4 Hours.
Methodologies and Algorithms
Object-Oriented Software Engineering Using UML, Patterns, and Java,
Unified Process Source & Courtesy: Jing Zou.
COMP 350: Object Oriented Analysis and Design Lecture 2
Chapter 2 – Software Processes
Software life cycle models
SOFTWARE LIFE-CYCLES Beyond the Waterfall.
Logical Architecture & UML Package Diagrams
Presentation transcript:

Object Oriented Analysis and Design Introduction

Contents 2  Analysis & Design  Software Life Cycle  Iterative Development  UML

Analysis and Design 3  Analysis and design is part of the software life cycle  It is the process by which the nature of the problem is understood and a solution is developed  In the early days of software, this part of the process was often ignored  Today, it is seen as a crucial part of the software development process

The Importance of Design 4  Software is one of the most complex creations of man  The complexity of software increases exponentially with its size  As the size of software increases, design becomes more important  Design lets you think of the best implementation technique before you build it

But, I Don’t Need to Design 5  Of course you don’t  You have only been working on small problems  Design is not essential for  small problems  Problems worked on by one person  Design is important for  Larger problems  Difficult problems  Problems being worked on by groups of programmers

The Benefits of Design 6  Well-selected classes  Well designed methods  Data structures which are consistent across the project  Proper class hierarchies  A simple, logical architecture  Appropriate use of design patterns  Games which are  Simpler to understand  Easier to extend and modify  Less costly to build and maintain

Design Alternatives 7  We will look at several approaches to software design  The Big Ball of Mud  Spaghetti Code  Spaghetti & Meat Balls  Non-object-oriented design  Object-oriented design

Big Ball of Mud 8  Code is in one big program  Code is not broken into logical sections  Logic is distributed throughout the code  Evaluation:  Difficult to modify and maintain  Logic is difficult to discover

Spaghetti Code 9  Code where  Following the logic is like following a piece of spaghetti through a bowl  Little or no design  Somehow it actually works  Evaluation  Code cannot be understood  Almost impossible to modify or maintain  Easier to re-write than understand

Spaghetti & Meat Balls 10  The object-oriented version of spaghetti code  Objects (meat balls) are connected by spaghetti code  Programmers claim benefits of object oriented code  Evaluation  Just as bad as regular spaghetti

Non-Object Oriented Design  Uses functional decomposition  Break problem into smaller problems  Write a function for each smaller problem  Put them together to make a solution  Evaluation  Design ignores data  Functions are created based on functionality and ignore data  This results in poor  Low cohesion  High coupling 11

The Cohesion Principle  Software must have a good reason to be together  It should  Do few things, ideally just one  Access few data structures, ideally just one  Highly cohesive software is good software 12

The Coupling Principle  Coupling refers to the connections between functions  A connection could be  Passing of data to a function  A function accessing data outside its scope  Functions accessing global data  Functions accessing data maintained by other functions  Accessing data without using functions to do so  Coupling is minimized in good software 13

Object-Oriented Design  Is based on  Identification of objects  Encapsulation of data so it cannot be accessed outside the class  Addition of methods to access and manipulate data in the class  Evaluation  High cohesion since methods deal with one data structure  Low coupling as all data is in classes and can only be accessed via methods  High-quality designs 14

Software Development Life Cycle (SDLC) 15  There is more to software than writing the code  Software has a long life cycle that extends past when it is shipped  There is a definite order in which the steps in the life cycle must occur  Understanding the life cycle is one of the keys to a good software process

Life Cycle Phases 16  Requirements  Identifying what the software must do  Analysis  Translating the requirements into software  Design  Tailoring the software for the environment  Implementation  Coding, testing, installation  Support

Waterfall Model 17 Requirements Analysis Design Implementation Testing Deployment

Problems with the Waterfall Model 18  It proceeds only in the forward direction  If a mistake is found in a later step, there is no way to go back to a previous step  It assumes that each step is performed perfectly  It does not reflect how people think and work

Iterative Model 19 project is split into smaller projects each smaller project is like a big project any step can be repeated until it is correct

Rational Unified Process 20

RUP 21  The Rational Unified Process is organized along two dimensions  A horizontal time axis showing the major phases of a project  A vertical axis depicting the disciplines or major activities of a project  The graph shows the amount of activity in each discipline in the different phases of the project

RUP Disciplines 22  Technical Disciplines  Business modeling discipline  Requirements discipline  Analysis and design discipline  Implementation discipline  Test discipline  Deployment discipline  Supporting Disciplines  Project management discipline  Configuration and change management discipline  Environment discipline

RUP Phases 23  Inception  State the project vision  State the business case for the project  Elaboration  Planning the project  Designing the software  Construction  Building the product  Adapting the architecture to changing requirements  Transition  Passing the product to the users  Training the users  Maintaining the product

Iterating 24  RUP assumes that you will not get things right the first time and that you will have to iterate the phases of the project  For example, a product might have three versions produced  Create an initial version of the product -> V1  Add additional features to the product -> V2  Incorporate requirement changes -> V3  Each version is built by following all phases of the project

Iteration 25  Iteration allows the product to  Be built in smaller parts  Tested as each part is added  Have flaws identified and corrected in the next iteration  Each iteration involves all phases

RUP In Practice 26  RUP Seeks to  Build system is smaller parts  Make frequent deliveries to the client  Get rapid feedback from the client  Each iteration provides a verifiable deliverable for the client

RUP Strengths & Weaknesses 27  Strengths  Well defined with tool support  Combines many best practices  Comprehensive  Weaknesses  Large and difficult to manage  Can get bogged down in process and forget you are trying to write software  Requires customization for each project  Tools limited to Rational

The Problems with Non-Iterative Approaches 28  They assume that requirements do not change  People change, environments change, requirements change  They assume that a correct design can be created on paper before the software is built  True if it is a simple project with well-known technology and nothing novel  The goal is to produce the next document and freeze it so you can move on to the next phase of the project

How Iteration Helps 29  Changing requirements are dealt with in the next iteration  The design for the next phase is performed after evaluating the results of the previous phase  Nothing is frozen until, maybe, the end of the project  Documents do not rule the project

Benefits of Iteration 30  Highest risk is attacked early  Change is properly managed  More and consistent user feedback  Proper prioritization  Early detection of inconsistencies  Continuous iterative testing  Development team learns from mistakes and improves  Stakeholders and users involved throughout the project  Higher level of reuse  Better project quality

Game Life Cycle 31  Requirements  Game Design Document  Analysis and Design  Recognition of objects  Design of classes  Testing  Unit testing  Integration testing  Testing gameplay  Delivery  Packaging game for shipment

The Design Process  Analyze the game design document  Identify classes which need to be created  Use a notation to represent the classes  which is less work than coding the classes  Which can be changed easily as design ideas change  Which allows the design of details to be delayed  Which captures much less detail than actual coding  Create demos to show how to use the classes  Create diagrams to show the high level components  Create diagrams to explain complex algorithms  Create diagrams showing how to install software 32

The Unified Modeling Language 33  UML is a graphical and textual notation that is designed to  Capture the design of the software  Show how the software components interact with one another  Show how the software can be deployed  Benefits  Lets the software be viewed in several ways  Is fast to work out design ideas  Takes much less time than writing code

One Game, Many Views  Games are made from complex software  You cannot see the whole thing with one picture  UML Provides  Class diagrams – to show classes and relationships  Object diagrams – to show how classes exist in actual use  Sequence diagrams – to show how classes are used to solve a problem 34