Kinesia Online Course
Object Oriented Programming
Kinesia LLC, 2003
    1. A Little Taste of Java
    2. Abstraction and Modeling
    3. Objects and Classes
    4. Object Interactions
    5. UML and Relationships between Objects
    6. Collection of Objects
    7. Some Final Concepts
    8. Object Modeling and Use Cases
    9. Modeling of Dynamic Behavaior and Sequence Diagrams
    10. A Deeper Look at Java
    11. Java Layout
    12. Java Events
    
We are what we repeatedly do.
Excellence, then, is not an act, but a habit.
					Aristotle
    Abstraction and Modeling
    1. Simplication Through Abstraction

    2. Abstraction -- a process of recognizing and focusing on the crucial features of a situation or an object, and filtering out or ignoring all nonessential details.

    3. Examples:
      • A road map: As an abstraction, a road map represents those features of a given geographic area relevant to someone trying to navigate with the map: major roads and places of interest, obstacles such as major bodies of water, etc. but ignore many details like buildings, trees, street signs, billboards, traffic lights, restaurants, etc.

    4. Generalization Through Abstraction

    5. When we eliminate a lot of details from an object through abstraction, it may become generic enough to apply to a wide range of specific situations or instances.

    6. Examples:
      • A Generic Cell: The diagram of a generic cell in the human body might include only a few features of the structures that are found in an actual cell:

    7. The simpler an abstraction - that is, the fewer features it presents - the more general it is, and the more versatile it is in describing a variety of real-world situations.

    8. The more complex an abstraction, the more restrictive it is, and thus the fewer situations it is useful in describing.

    9. Organizing Abstractions Into Classification Hierarchies

    10. Classification -- The process that human beings used to cope with the aspect of complexity of a situation or an object by systematically arranging information into categories according to established criteria.

      For example, scientists categorize all natural objects as belonging to either the animal, plant, or mineral kingdom.
      For an object to be classified as an animal, it must satisfy the rules:

      • It must be a living being.
      • It must be capable of spontaneous movement.
      • It must be capable of rapid motor response to stimulation.

      To be classified as a plant, it must satisfy the rules:

      • It must be a living being (same as for an animal).
      • It must lack an obvious nervous system.
      • It must possess cellulose cell walls.
    11. Abstraction hierarchy:

    12. Subtree

      We temporarily reduce the number of concepts that we mentally need to 'juggle' at any one time to a manageable subset of the overall abstraction hierarchy; in the simplistic example above, we are now dealing with only four concepts rather than the original 13. No matter how complex an abstraction hierarchy grows to be, it needn't overwhelm us if it is properly organized.

      Examples:

      Rules for a Bird:

      • Has feathers
      • Has wings
      • Lays eggs
      • Is capable of flying

      Given these rules, neither an ostrich nor a penguin could be classified as a bird, because neither can fly.

      If we attempt to make the rule set less restrictive by eliminating the 'flight' rule, we are left with:

      • Has feathers
      • Has wings
      • Lays eggs
      According to this rule set, we now may properly classify both the ostrich and the penguin as birds.

    13. Simplifying by eliminating redundancy

      Bird rules:

    14. Has feathers
    15. Has wings

      16. Further simplication.

      Bird rules:

    16. Has wings

      Oops!

    17. Abstraction as the Basis for Software Development

      Starting an information systems development project by gathering details about the real world situation on which the system is to be based:

    18. Those that are explicitly offered to us as we interview the intended users of the system.
    19. Those that we otherwise observe.

      20. Then sort out the essentials. As with all abstractions, all of our decisions of inclusion versus elimination when building a software system must be made within the context of the overall purpose and domain, or subject matter focus, of the future system.

      Example: When representing a person in a software system, is their eye color important? How about their genetic profile? Salary? Hobbies? The answer is, any of these features of a person may be relevant or irrelevant, depending on whether the system to be developed is a:

    20. Payroll system
    21. Marketing demographics system
    22. Optometrist's patient database
    23. FBI 'most wanted criminals' tracking system
    24. Public library

      25. We then prepare a model of that situation.

    25. Reuse of Abstractions

      pattern matching and reuse -- the technique of comparing features to find an abstraction that is similar enough to be reused successfully.

    26. Inherent Challenges

      Difficult!! Because:

    27. unlimited number of possiblilities exist
    28. no 'best' or 'correct' model exists; everything is relative;( but 'incorrect' model exists )
    29. no 'acid test' to determine if a model has adequately captured all of a user's reequirement. Need to learn ways to communicate our model concisely and unambiguosly to:
      • intended future users
      • fellow software engineers

    30. Successful Object Modeler

      Appropriate abstraction as the basis for a software system model requires:

    31. Insight into the problem domain

    32. Creativity

    33. Good Listening Skills

    34. Good Observational Skills

      35. Plus:

    35. An organized process for determining what the abstraction should be

    36. A way to communicate the resultant model concisely and unambiguously to our fellow software developers.
      UML -- Unified Modeling Language

    37. A software tool to help us automate the process of producing a 'blueprint'.