Upload
morgan-allen
View
26
Download
8
Tags:
Embed Size (px)
DESCRIPTION
Object Oriented Analysis and Design. Introduction. Contents. Analysis & Design Software Life Cycle Iterative Development UML. Analysis and Design. Analysis and design is part of the software life cycle - PowerPoint PPT Presentation
Citation preview
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
software13
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