Is375

Only available on StudyMode
  • Download(s) : 60
  • Published : March 15, 2013
Open Document
Text Preview
IS375
Object-Oriented Analysis and Design

Object-Oriented
Analysis and Design

How to build a Software
Application?
1. Blue print

1. Diagrams

2. Tools

2. UML/PL

3. Construction

3. Code

4. House

4. Product
3

Design and Blueprints

4

Development and Construction

5

Where is the Foundation for this House?

6

Different Types of Languages
 In the Software Industry, we have three types of
languages

1. Specification Language
2. Modeling Language
3. Programming Language

7

Object-Oriented Analysis, Design, Development

Analysis
Investigation of
problem

Design

Logical solution

Construction

Code

Software: why is it hard?
 Software systems can become extremely complex during
the development process
 The best methods for controlling this complexity are
abstraction and encapsulation: if we use some
techniques for building software that is less complex,
we will get benefits in

software that is more flexible: easier to
maintain and modify later
some opportunities to reuse designs and
code

Software Development
 Software includes all documentation necessary to:

Install
Use
Develop, and
Maintain programs
 It also includes all design and analysis documents
required to write and test the code.

The potential of OO
 software that is more maintainable

 most of the changes to the software are performed by
modifying the internals of well-encapsulated classes
 extending the software might be done by building derived classes
 object oriented analysis and design give the maintenance programmers a roadmap to the parts of the software that
need to be changed

 higher initial quality, better productivity in the development cycle

 because the “reuse” of classes can reduce the total amount of code

 shorter development interval
 lower lifecycle cost

 but

there needs to be a well-defined “software development
process” in place to achieve many of these benefits

The traditional software lifecycle
 The most traditional software
development lifecycle model is a linear
process (sometimes called the
“waterfall model”):

 each activity has to be
completed before the next
activity is started

 for example, requirements writing must be
complete before analysis can begin
 no coding work is started before the design
documents are finished

 it is a very efficient process for
solving a well-understood
problem
 but there is no support for
“iteration”: it is difficult to add
in some of the things that are
learned during the development
process

Requirements
Analysis
Design
Coding
Testing
Maintenance

An alternative development process
An “iterative and incremental” development
approach is best when using object oriented
analysis and design

incremental development:

 the development team produces a series of functioning software systems
 each partial system contains an larger and larger subset of the total functionality

iterative development:

 on each cycle, the quality and accuracy of the models is checked  the customer might decide that some parts of the model are incorrect and need revision to change the externally visible behavior

 the developers may decide that some parts of the model have poor performance and need revision to improve the internal
operation

first analysis
model
first design
model
first small
implementation

second analysis
model
second design
model
second
implementation

...

Problems
 The iterative and incremental approach is more difficult to manage:

 it isn’t always possible to say “we are X% complete”  team members are tempted to abandon all attempts at highlevel planning: there is a tendency to revert to “hacking” instead of working to understand system requirements,

developing a complete analysis model, or creating design-level descriptions of the key parts of the solution
 the documentation...
tracking img