CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Notes: 001
1
Introduction
Office Hours: see web page: www.uwplatt.edu/~rowemi/ (I have a couple more weekly meetings that
may change the current schedule).
Class Website: http://www.uwplatt.edu/~rowemi/classes/2011Fall/se343/se343_543_Object
Oriented Analysis and Design Fall 2011.htm for posting notes and assignments.
Syllabus: http://www.uwplatt.edu/~rowemi/classes/2011Fall/se343/se343_543_Syl.doc
Group Project:
 Some of almost each class session will be allocated for group communications. You will need
significant meeting times each week to work as a group.
 Topic: Cross Country Timing and Reporting System.
 Project will emphasize Analyze and Design phase (not coding).
 Projects will be given group grade. You will need to document which part that each group
member participated in for each of the deliverables. See the time reporting requirements on
the web page. Members who do not participate on the projects will have points taken away –
in extreme cases they can be removed from a project team. At the end of the semester each
team will perform peer performance reviews.
 Remember to mirror all project files periodically (just in case). This is your team’s responsibility.
Shared drives have been known to corrupt!
 Responsibility: Each student must know the theory and practice of each of the assignments.
Quiz and test questions will cover project work.
2
Assignment: Read: Ch. 1, 2 of Stevens, 1 of Fowler
Andersson and Bergstrand (1995) – 70% of Software Development is expended prior to coding!
 Why has this grown from 10% back in the good ole days to 70%? We are going to study this first 70%!
Req Analysis
1960s-1970’s
1980s
1990s

Preliminary Detailed
Design
Design
10%
20%
40%
30%
Coding and
Unit Testing
80%
60%
Integration System
Testing
Testing
10%
20%
30%
What is missing from the about Phases?
o Good systems spend from 40 to 80% of their time and resources on Maintenance. The
initial analysis and design of a system my greatly impact the effort needed to Code, Test,
and Maintain a system.
I use the above table in many of my classes. Why do I use it for multiple classes?
©2011 Mike Rowe
Page 1
2/9/2016 8:30:00 PM
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Notes: 001
3
Lecture Notes:
Using UML, Stevens: Chapter 1.
Note: Both books are based on UML 1.4. UML 2.0 is the current release.
3.1 Analysis & Design Motivation
Most systems cannot be developed by one person or even small groups of people.
 COCOMO 80-600 LOCs (Line of Code – sometime also call SLOC, Source Lines of code) or KSLOC
(1000 SLOC) per person per month.
 Small systems are 100’s of thousand LOCs.
 Large systems are 10’s of millions LOCs.
 Space shuttle has 100,000 LOCs of mission critical code that was completely written by multiple
independent teams, runs on separate computers, and in production, results that are compared
for agreement.
o There are millions of additional lines of code that are not mission-critical.
o Total effort was probably around 1000 person months of analysis, design, development
and testing.
o How long would it take one person to produce 100,000 LOCs?
 1000 person-months /12 month per year is about 83 years!
 If we needed the software done in 1 year we’d need at least 100 people.
One goal of Analysis and Design is to produce an architecture that allows many people to work
independently on a project. It can help estimate how many people can optimally be used on a project.
 Could we get 1000 folks together and complete all of the mission critical code in 1 month? Or
10,000 engineers and complete it in a couple of days?
o Why / why not? What would the problems be?
 Given requirements and a model of a system, methods like COCOMO can be used to estimate
how many people can optimally be used to deliver software and how long that team will need
to produce it.
4
Software Engineering
4.1 What is a good system?



Useful / Features – does something that provides a benefit
Usable – is easy to use, doesn’t required an absurd effort to derive benefit.
o Has anyone had experience with software that was so awkward that you just gave up on
it?
Reliable – produces desired output with few failures
©2011 Mike Rowe
Page 2
2/9/2016 8:30:00 PM
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Notes: 001







Flexible/ Extensibility – does many useful things (not just add a fixed list of numbers), can be
fixed if defects found, and can be extended for new functions.
Affordable – the economics of the system are positive.
o This is why we need to take an economics course!
Performance – does it produce results in a reasonable time.
o Some results are time sensitive, for instance an aircraft collision avoidance system must
be able to figure out that a collision is imminent while there is still time to avoid the
accident.
Scalability – can be enhanced to handle additional capacity (e-commerce sites)
o In the beginning Dell computers took a couple months to sell their first $1,000,000
worth of computers over their website.
o How much are they now selling an hour? Their revenue is above $60,000,000,000.
(2007). If 50% of revenue is derived from web sales, that comes to over $3,000,000 per
hour.
Available – can be readily used
o Computing environment – the right hardware and operating system environment.
o Software must be available to the users that need it
Plus other characteristics unique to systems
F.U.R.P.S. (Features, Usability, Reliability, Performance, Scalability)
o The U.R.P.S. are usually covered by Non-functional requirements
o The F.’s are usually covered by Function requirements.
4.2 Do we have a good system?
4.2.1 Problems that happen along the way











Capturing the users’ current needs – valid requirements
Keeping track of users’ needs as they change
Estimating efforts – if we are not diligent in our planning, things are generally more complex
and take longer than we initially estimate
Keeping everyone on the team working productively – specialists / non-specialists
Quality
Marketing/market – needs may change due to market/competition
Deployment and redeployment mechanisms
Support – training, user documentation, supporting multiple older versions of software.
Maintainability – add and modify features and platforms while maintaining compatibility with
existing functionality.
Technology may change – look back to games 5 years ago, what are the differences?
3rd party dependencies
©2011 Mike Rowe
Page 3
2/9/2016 8:30:00 PM
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Notes: 001
What happens if we fail in the above?
 What characteristics of a good system will be missing? Examples of failures. See the book, Y2k,
Mars Lander(s), etc.
4.2.2 Statistics on Software Projects -- 1994
(Chaos Report: http://www.standishgroup.com/sample_research/chaos_1994_1.php):
“





Resolution Type 1, or project success 16.2% (drops to 9% for large companies): The project
is completed on-time and on-budget, with all features and functions as initially specified.
Resolution Type 2, or project challenged 52.7%: The project is completed and operational
but over-budget, over the time estimate, and offers fewer features and functions than
originally specified.
Resolution Type 3, or project impaired 31.1%: The project is canceled at some point during
the development cycle.
o Who picked the below colors????
 Red is good
 Green is not complete failure
 Yellow is failure
Cost and schedule over runs average (across all companies) is 189% of the original cost estimate.
Why don’t we just multiply all estimates by 2 to play it safe?
4.2.3 Chaos Report 2004
We are getting better: Chaos Report 2004 http://www.infoq.com/articles/Interview-JohnsonStandish-CHAOS
Also at se343_543_Chaos2004.doc
©2011 Mike Rowe
Page 4
2/9/2016 8:30:00 PM
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Notes: 001
Watch out they changed the colors between 1994 (red is now bad) and 2004 (green is good)!
What happened in 1996? Failure rates increased from 31% to 40% (a +30% increase in failures).
 A new type of system became popular – Web-based systems. This also may account for
other changes in recent years. http://www.infoq.com/articles/chaos-1998-failure-stats
©2011 Mike Rowe
Page 5
2/9/2016 8:30:00 PM
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Notes: 001
4.3 What are good Systems Like

Good Structure or Modular: Structure/Modules – somewhat generic term for a chunk of a
system that makes sense to considered separately. (Files, subroutines, libraries, classes, etc.)
o Good systems are structured into pieces that make as independent as possible.
©2011 Mike Rowe
Page 6
2/9/2016 8:30:00 PM
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Notes: 001

Minimal Coupling / minimal Dependence – Module A depends on Module B if it is possible for
some change to Module B to mean that Module A also needs to be changed.
o Is this good?
4.3.1 Encapsulation: low coupling




Low coupling is almost always good. We want to minimize the cases where a change in one
module necessitates a change to another module.
Encapsulation – prevent access to the details of how a module provides its service. PRIVATE
functions and data, accessors.
Y2K problem: Which would be easier to fix? a) manipulation of dates all over a system (for
example: couts, i/o, db transactions, manipulations, checks, etc.), or b) a single class, lets call it
Date, that contains all of the above functionality and provides all date services to the rest of a
system?
A useful way of thinking about Modules is by classifying them as service providers (servers) or
service users (clients).
Interfaces – define features that a client may rely on the server to provide.
 The clients can only use the features of a server module through an interface. An interface
hides the details of providing the service from the clients – it encapsulates the details.
 Store interface – we understand the various interfaces for a pizza store.
o Do we need to understand the details of making a good crust or sauce to order a pizza?
 Syntactic dependency checking – checking the parts of an interface for type and number
consistency; like is done by a compiler. Strongly typed languages do this at compiler time and
prevent us from screwing up type sensitive information.
int paid = 15, cost = 10;
float refundIndex = paid / cost;
if( refundIndex > 1 ) refund( );
// will I get my refund?
A very strongly typed language would warn you of a possible loss in precision when dividing
using two ints.


Semantic dependency checking – go beyond syntax, to test whether the services provided by a
module are consistent in meaning with the use of the client.
o Mars Lander – Server was giving range as floating point numbers, Client was using these
numbers as a range, there was not a Syntactic dependency problem (floats), but there
was a semantic mismatch in that one module thought the numbers should be in English
units and the other thought they were metric units.
 What is the difference with respect to landing velocity?
Context dependency – what a service module must have in order to provide its service.
o What must a Pizza store have to provide service?
©2011 Mike Rowe
Page 7
2/9/2016 8:30:00 PM
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Notes: 001
Benefits of Modularity with defined interfaces
 Anything that reduces what we need to know is helpful when we are dealing with large systems
(for example a system with 10,000,000 SLOC).
 We do not need to know the details of how all servers work, just how to use their interfaces to
request and receive these services.
 Bugs (actually we should refer to these as defects) should be easier to isolate if specific
functionality is isolated/modularized (cohesion). We don’t have the “needle and the haystack”
problem. For example Y2K.
 It makes reuse possible. Why is reuse easier?
A module may have multiple interfaces. Too many interfaces usually means a module may not be
cohesive or coupling may be high.
 Would it make sense for a pizza store to also have a taxidermy interface?
4.3.2 Abstraction:




Reducing/simplifying the amount of detail that a client needs for know to obtain a service. A
good interface abstracts the details of the service.
Difference between Encapsulation and Abstraction is that Encapsulation prevents clients from
seeing the details, whereas Abstraction reduces the amount of information that a client needs
to know to obtain a service.
o Abstraction – we don’t need to know the details about how a store makes a pizza in
order to obtain one.
o Encapsulation – we are not allowed in the kitchen of the pizza store to even find out
how the pizza is made.
Cohesion of a module – how well the service that it provides are related to a single
theme/purpose. Services of a good module should be very similar.
o Is “Tan and Wash” a cohesive service?
o Would “Tan and Wash” be a good concept in Lake Havasu , AZ? In July of this year the
temperature got to 122 (an by the way it was sunny).
o What about pizza store and taxidermy?
A highly cohesion with little coupling provides good reuse.
o Can the concept of “Tan and Wash” be reused as well as two separate entities one
“Tan’ and the other “Wash”?
4.3.3 Architecture and components



Component – some chunk of software that can be reused.
Component Based Development (CBD) – paying particular attention to developing reusable
components and not just producing the current system. COTS software (Commercial Off The
Shelf) software promotes CBD.
What promotes reuse:
©2011 Mike Rowe
Page 8
2/9/2016 8:30:00 PM
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Notes: 001
o Low coupling – if we reuse component A in a new system, how many other modules do we
have to pull in to make component A work – the fewer the better!
o High cohesion – if we reuse component A in a new system, we don’t want to bring in a lot of
extra code that is never used!
o Good documentation of service and interface – hopefully is point does not need further
documentation ☺!
o Encapsulation and abstraction of something useful
o Context of use – rewards for reuse COTS content v. pay for LOCs written.
 Many LARGE government contracts have reuse requirements – this promotes reuse.
 If I pay you by LOCS written – this does not promote reuse.
o Pluggability – is component easily callable. If we are writing a system in C++ , how easy
would it be to plug in some functionality written in CoBoL
 .Net is improving pluggability in that we can easily interface source written in several
different languages.
o Opportunity – is the functionality of a component common to other systems.
 EDS (was one of the largest software service companies in the world, over 100,000
people. Was purchased by HP) started off doing systems for managing the Medicare for
the State of Texas.
o How hard was it for them to do the same system for other states once they had
one state working?
o How different are banks?
 What functionalities are common?
o For many systems once you have the first one down there are tremendous
opportunities for reuse. If this is in the long term plan a system can be designed
to be even more reusable.
CBD considerations:
 Need to consider components early in the design process. It is hard to extract components
from already developed systems. OOA&D can significantly improve the development of
components.
 The earlier we identify the opportunity for reuse the more we can reuse.
o Reuse of Design
o Reuse of Code
o Reuse of Test
o Reuse of Documentation
o Commonality in “Look and feel”
o ...
4.4 How are good systems built?



Its NOT just a random process!
We DON”T just start coding!
Use a defined process
©2011 Mike Rowe
Page 9
2/9/2016 8:30:00 PM
CS/SE3430 / CS5430 - Object-Oriented Analysis and Design
Notes: 001





Have a clear set of requirements to satisfy
Regard verification and validation as important
Keeps project knowledge, architecture and components under configuration control
Learn from experience – if something in the process doesn’t work, we fix it so that it will not be
a problem next time. Continuous Process Improvement.
Makes use of appropriate tools.
©2011 Mike Rowe
Page 10
2/9/2016 8:30:00 PM