An Introduction to Object-Oriented Analysis; Objects in plain English by gegeshandong

VIEWS: 3 PAGES: 74

									             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
            3.1 Definitions

 Data
   Information
   Model
   Abstraction
                         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 . . .
            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
           3.1 Definitions
   Data

 Information
 Model
 Abstraction
     Information
What is the difference between
           “data”
             and
     “Information?”
                      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
                Information
• We have summarized our raw data, and
• Presented it, so
• The President now has useful information,

• Useful for Decision-Making
                Information
Definition:

Information is derived from Data by some
    form of processing which makes it
   useful in some way, typically for
              making decisions.
         3.1 Definitions
 Data
 Information
 Model
 Abstraction
        What comes to mind when
  you hear the word “Model?”
• Smaller than real
  thing                     • A representation
• Looks the same            • For trying things out
  (model vs reality)        • For understanding
• Made of different stuff     something
• Does some of the
  same things
 Here’s 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 !!!
 But does the model look like a
           real car?
               Not Exactly.
• Same shape             • No doors
• 1/3 scale              • No motor
• Clay over wood frame   • No windows
                         • No seats
                         • No paint
 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
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.
                   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.
 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.
         3.1 Definitions
 Data
 Information
 Model

   Abstraction
                 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.
                 Abstraction

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

Data        = Facts
Information = Useful
Model       = Simplification of a complex
                   reality.
Abstraction = Focussing on what is relevant
                   for the task.
     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 Child’s First model
  – Each of us has been using objects
   implicitly all our lives.
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.
A Child’s First
  Model. . .
      Since birth
 (or perhaps before)
we have all been using
  object models. . .
Mental Models and our World View




      A newborn baby is
      Bombarded by random
      sensory inputs
Mental Models and our World View




        A newborn baby is bombarded
        by random sensory inputs
        and postulates the existence
        of OBJECTS
              These objects:
• Have attributes
• Have attribute values
• Are capable of behavior
• Exhibit this behavior in response to
 messages
              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.
So the child is able to make sense of,
         and to work with,
 what must seem to her/him like an
INCREDIBLY COMPLEX UNIVERSE.
          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 USER’S BUSINESS!!
  OBJECTS ARE A MOST
 NATURAL AND EFFECTIVE
  WAY TO HANDLE AND
UNDERSTAND COMPLEXITY
3.3 Early Methods (Pre-Modeling)

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


 • Recognized circa 1970
 • Development follows a pattern
 • Reproducible
 • All steps are necessary
     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
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.
   Efficiency vs Effectiveness

Efficiency is doing the job right;

        Effectiveness is

     doing the right   job!!
  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. . .
 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.)
  Late 1960s: Output-Oriented
         Methodologies

• Start with user’s vision of output reports

• Work back through calculation and storage
  to input.
Late 1960s: Output-Oriented
       Methodologies
           Benefits:
• Added organization and rigor to the
 process

• Completeness check
Late 1960s: Output-Oriented
       Methodologies
         Problems:
• 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
             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)
                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
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
 To understand the users’ world
     we need three things:


  • Modeling notations

  • Modeling techniques

  • People sensitivity
 To understand the users’
world we need three things:


• Modeling notations
    • To document what we learn
    • To communicate with the users
 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
  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
 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)
 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
This data represents all the
  things the users need to
 know at each step of their
job to make their business
            run.
  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 ).
 Development effort moved up front
         (graph on pg 40)

                                                         Old way

                                                         New way




   Analysis   Design   Coding   Implementation Maintenance
 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.”
      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.
               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
                  Quality
• Used to be defined in terms of the product
• The modern definition of Quality is in terms of
 the Customer.


Quality = Customer Satisfaction
      3.5 Some Early Models


• Functional Decomposition

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

• Decomposition = Breaking Down.
• Breaking down the users’ functions or
  processes into smaller functions.
• Helpful for process,
• Does not address data.
   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)
 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.
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.
 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 Chen’s Entity-
  Relationship Diagrams (ERDs) to model the data needs of
  the organization - see Chapter 4.
           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.
              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.
             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, OOA&D, 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.
            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!
                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.
End of Chapter 3

								
To top