Chapter 3 Models and Modeling

1
Chapter 3 Models and Modeling

• 3.1. Definitions
• 3.2. Models as Aid to Understanding
• 3.3. Early Methods (Pre-Modeling)
• 3.4. Models in Systems Development
• 3.5. Some Early Models

2
3.1 Definitions

• ? Data
• ? Information
• ? Model
• ? Abstraction

3
? Data

• What comes first into your mind when hear the
  word Data?
• Information (Information is data that has in some
  way been made useful for someone.)
• Numbers
• Bits
• Bytes
• Facts
• All of these are right . . .

4
Definition of Data

• Data is the plural of the Latin Datum meaning
  Fact.
• Note statisticians usually say The data are . .
  .
• Programmers typically say The data is . . .
• So Data means Facts
• I like to call them Raw Facts since they are
  not yet processed in any way

5
3.1 Definitions

• ??Data
• ? Information
• ? Model
• ? Abstraction

6
? Information

• What is the difference between
• data
• and
• Information?

7
? Information

• To manage the Department, your professor and
  her/his colleagues need to know in detail
• What day this is
• What class this is
• Who should be here
• Who actually showed up
• Who is teaching

8
? Information

• We have summarized our raw data, and
• Presented it, so
• The President now has useful information,
• Useful for Decision-Making

9
? Information

• Definition
• Information is derived from Data by some form of
  processing which makes it useful in some way,
  typically for making decisions.

10
3.1 Definitions

• ? Data
• ? Information
• ? Model
• ??Abstraction

11
? What comes to mind when you hear the word
Model?

• Smaller than real thing
• Looks the same (model vs reality)
• Made of different stuff
• Does some of the same things

• A representation
• For trying things out
• For understanding something

12
Heres an example of a model

• Q How do auto designers decide what shape a car
  should be?
• A1 Build one and drive it.
• WRONG!
• A2 Build one and put it in a wind tunnel.
  Closer.
• A3 Build a MODEL and put it in a wind tunnel.
• RIGHT !!!

13
But does the model look like a real car?Not
Exactly.

• Same shape
• 1/3 scale
• Clay over wood frame

• No doors
• No motor
• No windows
• No seats
• No paint

14
It has the right shape . . .

• So the air will flow around it just like the real
  thing
• In other words
• It has what it needs for the problem at hand

15
Mannequins in a clothing store

• Do well at displaying clothes,
• Lack certain essential features of a real person,
• But they have what they need,
• For the job at hand.

16
Other Models

• House plans
• Electrical schematics
• Maps
• Blueprints
• Program flowcharts
• Equations - a Mathematical Model
• Each of these in some way represents something in
  the real world that is too big or complex to
  understand as it stands. So each is simplified,
  or reduced in size, scope or scale.

17
??Model - Definition

• Thus, a Model is a simplified representation of a
  complex reality, usually for the purpose of
  understanding that reality, and having all the
  features necessary for the current task or
  problem.

18
3.1 Definitions

• ? Data
• ? Information
• ? Model
• ? Abstraction

19
? Abstraction

• Modeling is actually a form of abstraction.
• Model - we build something,
• With the features needed for the problem at
  hand.
• This is the essence of Abstraction.

20
? Abstraction

• Definition
• The process of focusing on those features that
  are essential for the task at hand, and ignoring
  those that are not.

21
SUMMARY

• ?Data Facts
• ?Information Useful
• ?Model Simplification of a complex
  reality.
• ?Abstraction Focussing on what is relevant
  for the task.

22
3.2 Models as an Aid to Understanding

• The Pervasiveness of Models
• Any equation that describes something in the
  real world is a model
• A Childs First model
• Each of us has been using objects implicitly all
  our lives.

23
The Pervasiveness of Models

• Models are
• Usually for the purpose of understanding
• Models can be
• Equations
• Simulations (including video games)
• Physical models
• Mental models
• Etc.

24
A Childs First Model. . .
25
Since birth (or perhaps before) we have all
been using object models. . .
26
Mental Models and our World View
A newborn baby is Bombarded by random sensory
inputs
27
Mental Models and our World View
A newborn baby is bombarded by random sensory
inputs and postulates the existence of OBJECTS
28
(No Transcript)
29
These objects

• Have attributes
• Have attribute values
• Are capable of behavior
• Exhibit this behavior in response to messages

30
These objects

• Have attributes
• Have attribute values
• Are capable of behavior
• Exhibit this behavior in response to messages

In this way the child learns to predict and then
to manipulate its environment.
31
So the child is able to make sense of, and to
work with, what must seem to her/him like
an INCREDIBLY COMPLEX UNIVERSE.
32
So the child is able to make sense of, and to
work with, what must seem to her/him like
an INCREDIBLY COMPLEX UNIVERSE.
THIS IS THE SAME TASK AN ANALYST FACES WHEN
TRYING TO UNDERSTAND A USERS BUSINESS!!
33
OBJECTS ARE A MOST NATURAL AND EFFECTIVE WAY TO
HANDLE AND UNDERSTAND COMPLEXITY
34
3.3 Early Methods (Pre-Modeling)

• The Systems Development Life-Cycle (SDLC)
• 1950s and Early 1960s Unsystematic
• Late 1960s Output-Oriented

35
The Systems Development Life-Cycle (SDLC)

• Recognized circa 1970
• Development follows a pattern
• Reproducible
• All steps are necessary

36
The Systems Development Life-Cycle (SDLC)

• Analysis What users need system to do
• Design Plan of how the system will do it.
• Construction Write and Test the code
• Implementation
• Install software in production
• Train users
• Parallel run
• We will revisit the SDLC in Chapter 6

37
1950s and Early 1960s Unsystematic

• The Process of Systems Analysis was not well
  understood.
• The Problems were poorly understood.
• Focus was often on solutions.
• Efficiency vs Effectiveness.

38
Efficiency vs Effectiveness

• Efficiency is doing the job right
• Effectiveness is
• doing the right job!!

39
Before we begin to solve a problem We must
clearly Understand and Define it. This is what
Analysis is all about, but this was not generally
recognized until the late 1960s. . .
40
Late 1960s Output-Oriented Methodologies

• Methodology
• A body of methods, rules and postulates (i.e.,
  beliefs), or a set of procedures, employed by
  some discipline (in this case MIS.)

41
Late 1960s Output-Oriented Methodologies

• Start with users vision of output reports
• Work back through calculation and storage to
  input.

42
Late 1960s Output-Oriented MethodologiesBenefi
ts

• Added organization and rigor to the process
• Completeness check

43
Late 1960s Output-Oriented MethodologiesProblem
s

• Design is customized to the known set of outputs
• System difficult to change as users needs
  inevitably change.
• Small change can cause a cascade of changes back
  through the system
• Maintenance still a problem

44
3.4 Models in Systems Development

• First, some general comments about using models
  for systems development
• Listening skills (SA is a people-oriented
  profession
• Notations, techniques and sensitivity
• Users get a new view of their job
• Development effort moved up front
• Early detection of errors
• Quality
• Then, two kinds of earlier models
• Functional decomposition
• Process models Data Flow Diagrams (DFDs)

45
? Listening Skills

• God gave us two ears and one mouth!

• Analyst is here to listen and learn about Users
  business operation and their problems.
• Listening is a skill that needs to be developed.
• Modeling methods add structure to user interviews
• They are tools for effective Analysis and Design

46
It is by interacting with people and observing
people that we learn to understand our users
world, and the difficulties they have with some
parts of it
47
? To understand the users world we need three
things

• Modeling notations
• Modeling techniques
• People sensitivity

48
? To understand the users world we need three
things

• Modeling notations
• To document what we learn
• To communicate with the users

49
? To understand the users world we need three
things

• Modeling techniques
• To ensure we use the tools properly
• To give an accurate picture of the users
  operation

50
? To understand the users world we need three
things

• People sensitivity
• Interviewing and listening skills
• To ensure that we gather all relevant
  information
• So our models form a complete and accurate
  picture of the users business

51
? Users get a new view of their job

• The users have probably never considered their
  own business from the point of view of the data
  and info.
• The information aspects of their operation are
  something totally new to most users.
• Object modeling will give them a new view of
  their own world
• This can give them new insights, often leading to
  improvements in the way they operate
• Thus, OOA is now also used by management
  consultants for Business Process Reengineering
  (BPR)

52
? Users get a new view of their job

• We can say that
• A business is driven by its data
• or alternatively
• A business rests upon a
• Pool of Data

53
This data represents all the things the users
need to know at each step of their job to make
their business run.
54
? Development effort moved up front

• All modeling-based methods force us to do more
  work on the earliest stages of a project.
• This is important, since we must first understand
  and define the problem before we begin designing
  a solution.
• This is related to the need to correct errors
  early (see next section ?).

55
? Development effort moved up front(graph on pg
40)
Old way
New way
Analysis
Design
Coding
Implementation
Maintenance
56
? Development effort moved up front

• But there is a problem
• Management expect see results for all the time
  and money spent,
• But we could model for weeks or months and not
  produce any code or screens.
• Modern methodologies thus focus on Deliverables.

57
? Development effort moved up front

• Deliverables Documentation or other products
  that are produced at the end of each phase and
  sub-phase of the project.
• Producing them tells us we have reached the end
  of that phase.

58
? Early detection of errors

• In systems development,
• 56 of errors are in determining the users
  requirements.
• But 81 of time, effort and expense are used to
  correct those 56 of the errors.

59
? Early detection of errors
Error found Mar 13
Error found Feb 13
Error occurs Jan 13
Work (person-days)
10
20
Time
Work proceeds at (say) 10 person- days per month
10 person-days of work has been done assuming
the error is not there. Now this must be redone.
If error found this late, 20 person-days must be
redone
60
? Early detection of errors

• So we must get it right the first time.

• The earlier we are in the project, the more
  important it is to get it right.
• When we do make an error, it is critical to find
  and fix it ASAP.

61
? Quality

• We must build an information system that does
• The right job (Effectiveness)
• Well (Efficiency)
• The way the users need it done
• For an adequate number of years
• With flexibility for changes,
• i.e., Maintainability

62
? Quality

• Used to be defined in terms of the product
• The modern definition of Quality is in terms of
  the Customer.
• Quality Customer Satisfaction

63
3.5 Some Early Models

• Functional Decomposition
• Process models Data Flow Diagrams (DFDs)

64
Functional Decomposition

• Decomposition Breaking Down.
• Breaking down the users functions or processes
  into smaller functions.
• Helpful for process,
• Does not address data.

65
Data Flow Diagrams (DFDs)

• Promoted in 1970s by such as Yourdon, DeMarco,
  Gane and Sarson, Michael Jackson(!) and others
• Do not fully address data.
• In the 1980s were used alongside data models
  (ERDs)

66
3.6 Shortcomings of Output-based and
Process-based Methods

• Each was a step ahead from what went before.
• Both gave a good design,
• Based on the users current needs.
• Neither was good at handling change in how the
  users do their business.

67
3.6 Shortcomings of Output-based and
Process-based Methods

• It was less urgent

• But more important
• To have a system that could be easily modified as
  the years went by,
• To reflect changes in the users needs.

68
3.6 Shortcomings of Output-based and
Process-based Methods

• DFDs made sure the Requirements Definition gave
  a truer picture of what the users actually needed.

• DFDs and Structured Programming both made systems
  more modular.
• This early form of Encapsulation made the systems
  more resilient to change,
• Giving better systems,
• But the maintenance problem was still with us.
• The next step toward a solution was Chens
  Entity-Relationship Diagrams (ERDs) to model the
  data needs of the organization - see Chapter 4.

69
Chapter 3 Summary

• A model is a simplified representation of a
  complex reality, typically for the purpose of
  understanding that reality, and having all the
  features of that reality for the task at hand.

• Modeling is a form of abstraction.
• Object-oriented modeling works well because it is
  one of the fundamental ways people organize their
  experience internally.

70
Chapter 3 Summary
The Systems Development Life Cycle has a number
of steps or phases

• Analysis Study the users world to find what the
  users need the system to DO, without considering
  how the system will do it. Output Requirements
  Definition.
• Design A plan showing how the system will do it.
  H/w s/w platform, language, O.S., DBMS, etc.
  Output Design Specs Program Specs.
• Construction Programs are coded, debugged, and
  then tested first by team and then with users.
  Output working software.
• Implementation System installed, users trained,
  parallel run. Output A functioning installed
  system.

71
Chapter 3 Summary

• The History of Systems Analysis
• 1960s Unsystematic, Seat-of-the-Pants
• Late 60s Output-Oriented
• 1970s Process-Oriented DFDs
• 1980s Data-Oriented ERDs
• 1990s Object-Oriented, OOAD, OOP.

• Earlier methodologies focused on only the
  business processes.
• Object modeling first considers the data in terms
  of objects, the things people need to know about.

72
Chapter 3 Summary

• Analysis modeling forces us to spend more
  up-front time with users.

• Must identify and understand the problem before
  we look for a solution.
• A perfect solution to the wrong problem gets us
  nowhere.
• You start coding while I go see what they need!
• We techies are notorious for thinking we
  understand when in fact we only have half the
  story!

73
Chapter 3 Summary

• Object modeling has shown the greatest reductions
  in both initial coding and maintenance.

• Objects cause much more reuse of code and
  analysis, plus get it closer to right the first
  time.
• Cost is time spent in analysis.
• Benefit is errors found earlier.
• Overall
• Higher quality
• Reduced cost
• Compared with earlier methods.

74
End of Chapter 3