Ready to Design by malj

VIEWS: 3 PAGES: 44

									   http://www.youtube.com/watch?v=E6RjpD1vwh8

   http://www.wired.com/dangerroom/2010/10/19-billion-later-
    pentagon-best-bomb-detector-is-a-dog/#ixzz134hGE6Dp

   Here is a webcomic about the Manhattan Project
    http://xkcd.com/809/

   http://www.funderstanding.com/v2/educators/right-brain-vs-left-
    brain/

   http://en.wikipedia.org/wiki/The_Spinning_Dancer
Partitioning
Modularization

   Break up the proposed architecture
       Into FUNCTIONAL, not programmatic
        modules
       If the interfaces are solid, they can be
        done in parallel
       If the interfaces are solid, they will
        isolate changes and errors
       If the interfaces are solid, they can be
        integrated easily
What is a module?

         Storage



                                           Outputs



                   Processing
Inputs



         Simple Block Diagram Form
         Arrows, of course, should be labeled
Data Flow Diagram


         Temporary Storage




                                                Sink

                  Data Conversion
Source



             DFD Standard Shapes
             Arrows, of course, should be labeled
                          MAIN




               State of
                                 Joint X
              Each Joint


           Get Desired         Get Actual
                                                  Adjust
              for X              for X
                                                    Adjust
                                                        Adjust
     X            X          X           X       Shoulder Adjust
   Position    Velocity    Position   Velocity    Drive        Adjust
                                                                  Adjust
                                                     Waist
                                                                  Grasp
                                                     Drive
                                                        Elbow
                                                         Drive
                                                         Wrist Turn
                                                            Drive
                                                            Wrist Bend
                                                               Drive
                                                                  Grasp
                                                                  Drive

Structure Chart - shows levels of supervision
           Structure Chart

                                     Boss
                                                    Data/Status can go
                status                              in both directions




                                         data
                         Worker                 Worker




Tenets:
One supervisor should have (only) 7 +/- 2 workers
Information is never passed laterally (Chain of Command)
Workers never tell the Boss what to do
                          User Interface                           Phrasing



                                                                                       MP3s

       Prediction                                  Rules Db


                                                                                              WAVs
                    Phrase Completion                                                                   Presentation


                                                                         Audio
                                                                      Construction
                                           Stored Menus



                                                                                                             Output




                                                          Phrase


                                                                    Synthesis Engine




                    Menu Presentation-
                      Graphics, Text

                                                                                                             User Feedback



                                     Choice
                                                                                          Logging,
                                                                                        Monitoring, &
                                                                                        Annunciation

                    Build and Release

Edit / Undo/ ReDo




     Block Diagram - shows module relationships
Data Flow Diagram - shows movement, conversion, and storage of data




                                  Operator(s)




                                   User IO




      Sensors                        CAPE                               Result
                 SensorData                       Measurement Results   Database
                 SensorConfig




                                Flight Guidance
                                Data




                                   Aircraft
Cloud Chart - (pre UML) object relationships




                          Generation 2 Configuration Control Detail
                                              = Internal
                                           Communication

                          TCP/IP Stack
                         (HTTP, SNMP,                            Serial
                                            File Sy stem
                            Telnet)                             Terminal




                          Socket Input       File Input        Serial Input




                                             Command
                                             Processor




  Serial Input
 Design Approach
OO, or Structured. or Information
  Flow
Structured – strictly “called” levels of
  supervision. One mediator, calling
  one “helper” routine at a time.
OO – concurrent, selectively persistent
  tasks
Info Flow – a database manager, with
  queries, sorting, and reporting.
Design Approach

Any answer of Yes to the following
  questions:
 Is it algorithm based? – Structured

 Can it be accomplished using
  single-context switching? –
  Structured
 Is there a Real Time OS? – Object
  Oriented is a candidate
Design Approach
   Is the system defined by the data it
    holds and moves? – Info Flow
   Multi-tasking? – Object Oriented
   Persistence, concurrency, and
    garbage collection an issue? –
    Object Oriented
   Is the Language specified? –
       Java – OO
       C – Structured
       C++ - either Structured or OO
Design Approach

   Third-party software to be used
    extensively? – use what they used
    (COTS = commercial off the shelf)
   Event driven? – Object Oriented
    (including Visual Basic)
   Can the system be modeled clearly
    – Object Oriented
Module Characteristics

   Can be a class, group of classes,
    objects, routines, files, anything
   Does one, independent, um, thing
   Provides a service to other modules
   Explicitly exchanges only needed
    information
   Ideal: can be exchanged with a new
    module having the same interface
Coupling

   The strength of module inter-
    connection
   One module's dependence on
    another
   The strength and exposure of the
    relationship to other modules
   any method call reflects at least
    some coupling
     Simple Data Coupling

        data




     process           status

                                    error
                                    handling

               Only required data


Simple Data Coupling
         Simple Data Coupling

 A module is self-contained
 Defers to other modules only to get
  necessary, pre-processed data
 Communicates only results, DOWNWARD
Example?
Write_String_To_File( FileNumber, "Hi");
       What's coupled? Just called and calling
        routines, through easily-understood data.
       Note: status not returned
In "structure chart" form

                 main


                             fileNumber
                             String




           Write_String_To_File
Control Coupling


 A module has all necessary data,
  but waits until a command comes to
  tell it what to do
 Flags passed between modules

Example?
 Look at DbMgr
e.g. Db Mgr


                request (operation type)
                           is it data or status?


         Edit, Add, or
        Delete a Record
     Better this way



still
control                Database       action routed here – control
coupling
            request    Manager        implemented by supervision
                                      rather than data


            Get       Add         Delete        Edit
           Request
Control Coupling 2

   Module calls another for assistance,
    and then it receives back an error
    message
   Inversion of Authority
                              Output

                          Error

                             Write to
                             Device
                Output


                         Status?
                                   Is this even
                Device             Necessary?
                Driver
 Error Packet



 Error                     Who "oversees"
Handling                   the error?
     Object Coupling

        Instantiation couples one object to
         another – “has a”relationship


                 JFrame win = new JFrame();


     main
                                              JFrame




Simple Object Coupling
    Common Coupling

       Both use the same global data



  Record Music                                Play Music




                  Data Structure – mp3 File

Common Coupling
Common Coupling

   A global variable is shared
   What if - you attempt to fix one
    module by changing the global
    variable type?
     Stamp Coupling

        Both act on the same data,
         although affect it differently
         (different fields of the same record)


                                            $$ Transaction
  Bank Customer




                   Person   Balance   Account #

                                            Bound data
Stamp Coupling
Stamp Coupling

   A record is shared
   Same "what if?"
   The invisible danger of untraceable
    associations
   Change one, change the record…
    what happens to all the other
    modules that depend on it?
        Pathological (or Content) Coupling
       The worst use of a go-to
       Jump into, and out-of, a routine outside
        of the normal call procedure
       A method you do not return from…




                        Internal to internal



Pathological Coupling
Cohesion

   The tendency of one module, to do
    one, well-defined, independent job
   The question always is… Should
    these behaviors be placed in a
    single module, or split up?
   Signs of trouble…
       does too much
       can't think of a descriptive name
       weak verb
       multiple verbs
Example

   An output module - should it handle
    output to file, screen, and printer,
    and just take in a flag telling it what
    to do?
   Or should you write three modules,
    and call the correct one?
   Consider coupling at the same time
Functional cohesion

   One function, one job
   Gets only the data it needs
   Produces an output in its simplest
    form
Temporal Cohesion

   Behaviors are grouped together
    because the happen at the same
    time
   “Init” routines - order is not
    important, they just all need to be
    done together.
Sequential Cohesion

   Behaviors are grouped together
    because they usually happen in
    order, the output of one behavior
    being the input to the next

e.g. Individual bit-processing in byte
  construction, individual character
  processing in word processing, etc.
Procedural

   Sequential, order is important, but
    data is not passed between
    behaviors within the same routine

e.g. Bringing up a system through a
  step-by-step process (watch your
  PC boot: disk, ports, network,
  display, the order is important)
Communicational

   Behaviors are grouped because they
    act on the same data
Logical

   Only a loose association
   A furnace module: raise temp,
    lower temp, test temp
The thermostat in your home….



                          Desired Temperature



                 Furnace
                 Control
           (test, raise, lower)
well partitioned….



                    Furnace
                   Controller




Get       Get           Raise    Lower
Desired   Actual        Temp     Temp

                                why?
Coincidental

   No association
   You group behaviors into a single
    module because you hate typing
Spaghetti

   Information takes a circuitous route
   Usually the result of bad cohesion
    and bad coupling
   We want…
       Strong Cohesion
       Weak Coupling
Order the types of Coupling

   Data - good / weak / exposed
   Control Down, Control Up
   Object
   Stamp, Common
   Pathological - bad / strong / hidden
Order the types of Cohesion
   Functional - good / strong / independent
   Sequential – order + data
   Communicational – data but no order
   Procedural – order but no data
   Temporal – no order or data
   Logical
   Coincidental - bad / weak association of
    behaviors / unrelated within the module

								
To top