Advanced Object-Oriented Analysis - PowerPoint PPT Presentation

Loading...

PPT – Advanced Object-Oriented Analysis PowerPoint presentation | free to download - id: 197782-ZDc1Z



Loading


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation
Title:

Advanced Object-Oriented Analysis

Description:

SJSU -- CmpE. L3-S1 Analysis Heuristics. Advanced Object-Oriented Analysis & Design ... changing technology. 10. Heuristic #2: Speculate About Likely Changes. 2003 ... – PowerPoint PPT presentation

Number of Views:13
Avg rating:3.0/5.0
Slides: 30
Provided by: fay6
Learn more at: http://www.engr.sjsu.edu
Category:

less

Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: Advanced Object-Oriented Analysis


1
Advanced Object-Oriented Analysis Design
  • Dr. M.E. Fayad, Professor
  • Computer Engineering Department, Room 283I
  • College of Engineering
  • San José State University
  • One Washington Square
  • San José, CA 95192-0180
  • http//www.engr.sjsu.edu/fayad

2
Lesson 3 Analysis Heuristics
2
3
Lesson Objectives
  • Overview of previous lectures.
  • Understand the analysis heuristics
  • Go Beyond the Problem Domain
  • Speculate About Likely Changes
  • Separate General Functionality from Specific
    Policy
  • Object should have Cohesive Interfaces
  • Objects Should Be Intelligent Agents
  • Objects Should Export Services
  • Avoid Object Machismo

3
4
Overview Life Cycle
  • RA
  • Design
  • Code
  • Test
  • Deploy
  • What
  • How
  • Build
  • Test
  • Use
  • What is the customer really wants?
  • How the best solution
  • How do we construct (implement) the system
  • Test
  • - Are customer requirements testable?
  • - Does the how logically follow from what?
  • - Does the built system do what it is suppose to
    do?
  • How do we enhance /or repair the built system?

4
5
Overview Analysis vs. Design
  • Analysis Design
  • What is the problem? How to solve the problem?
  • Problem Space Solution Space
  • Mostly one Problem Many Solutions

5
6
Overview Process Properties
  • Practical
  • Concrete Action
  • Can be measured
  • Repeatable
  • Tailorable
  • Must be documented
  • Hierarchical
  • Specify who, what, when, how and ignore the why?

6
7
Overview Model Properties
  • Simple
  • Complete (most likely to be correct)
  • Stable to technological changes
  • Testable
  • Easy to understand
  • Visual or graphical

7
8
Heuristic 1 Go Beyond the Problem Domain
  • A system structure is based on the Real World,
    locks in todays problem domain relationships.
  • This makes it difficult to adapt the system to
    future requirements.
  • Look for relationships and generalizations that
    transcend the current problem domain
  • Ask What is it?

8
9
Heuristic 1 Go Beyond the Problem Domain
  • Build these into the analysis model
  • Developing an adaptable architecture does not
    happen just because you are using OOD and/or C
    (any more than extensibility or reuse occur
    automatically)
  • Generalize Early Generalize Vigorously

9
10
Heuristic 2 Speculate About Likely Changes
  • The Real World is the best model of today but
    it only hints at what tomorrow will bring
  • Basic for speculation
  • Changing user requirements
  • Changing customer base
  • Competitive products
  • changing technology

10
11
Heuristic 2 Speculate About Likely Changes
  • Build the analysis model so it can adapt to these
    likely changes
  • You do not have to be 100 correct.
  • Developing an adaptable architecture does not
    happen just because you are using OOD and/or C
    (any more than extensibility or reuse occur
    automatically) Exs Hooks, HotSpots, Design
    Patterns

11
12
Heuristic 3 Separate General Functionality from
Specific Policy
  • Place general functionality in entity objects
    (class)
  • Entity object (class) will now be more reusable.
  • Place specific policy in control objects (active
    class)
  • Policy is localized so that it is easier to
    introduce changes to this policy

12
13
Heuristic 3 Separate General Functionality from
Specific Policy
  • Conservation of Policy
  • There is no way to eliminate or ignore all policy
  • The policy will be in the delivered system
  • All we can do is structure the policy so that it
    is easy to adapt and change it.
  • Mechanism Rich Policy Free

13
14
Heuristic 3 Illustrated Example The Problem
State Tax
Calculator
File System
Federal Tax
14
Forms
15
Heuristic 3 Illustrated Example The Solution
State Tax
MRPR
Federal Tax
MRPR
Forms
MRP
Calculator
MRPF
15
File System
MRPF
16
Heuristic 4 Objects Should Have Cohesive
Interfaces
  • In the Real World, a remote Controller for home
    electronics may have 50 buttons for controlling
    your TV, VCR, Stereo , and others.
  • Modeling this controller as a single, real-life
    object will not be adaptable to future changes.

16
17
Heuristic 4 Objects Should Have Cohesive
Interfaces
  • It may be better to
  • First model each different set of operations as a
    separate object with a strongly cohesive
    interface.
  • Model the combined functionality as a separate
    object that uses other objects.
  • Result is more adaptable and reusable
  • Do One Thing

17
18
Heuristic 5 Objects Should Intelligent Agents
  • Intelligent (Responsible) Objects
  • Incorporate important knowledge
  • Incorporate knowledge that is difficult to
    produce, find, or replicate
  • Know how to synthesize knowledge

18
19
Heuristic 5 Objects Should Intelligent Agents
  • Agents are capable of (limited) autonomous
    behavior
  • Know that they are supposed to do, and they do.
  • Work best with limited supervision.
  • Adapt to their environment
  • Know how to delegate work to other objects

19
20
Heuristic 5 Objects Should Intelligent Agents
  • Agents are capable of (limited) autonomous
    behavior
  • Know how to find objects to which they can
    delegate work
  • Have the information they need or know where to
    get the information or know where to get
    information on getting information or can
    interpret information given to them.
  • Are highly adaptable, extensible, and reusable
  • Are expensive to design and build

20
21
Heuristic 6 Objects Should Export Services
  • Objects that only export attributes or data must
    be manipulated by clients. (aka. dead data)
  • Objects that only export basic operations require
    clients to direct and supervise all activity
    (aka. stupid objects)
  • Objects that export services make life easier for
    their clients
  • Server selects the best way to perform the
    service
  • Server finds and manages the resources

21
22
Heuristic 6 Objects Should Export Services
  • Services should define What not How
  • Can Drive to Work be replaced by Get to Work
  • Enhances extensibility
  • Enhances reusability
  • Distributes intelligence

22
  • Move Complexity From the Clients to the Servers

23
Heuristic 6 Stack Example
Stack Implementations
Type Stack
push ( )
pop ( )
DLL
SLL
length ( )
Stack Interfaces
empty ( )
ARY
HT
full ( )
23
24
Heuristic 7 Avoid Object Machismo
  • Object machismo
  • Equating the value of an object with how big
    and/or complex it is (e.g., Lines of Code, of
    methods, or complexity of algorithms it uses).
  • Macho objects tend to be central controllers that
    are difficult to design, difficult to understand,
    have to much policy, are hard to extend, and low
    reuse potential.

24
25
Heuristic 7 Avoid Object Machismo
  • The value of an object is based on many factors
  • Does it do something useful
  • Does it have a simple and clean interface
  • Does it have well-specific behavior
  • Does it model an essential quality of the system
  • Can it be composed with other objects to perform
    more complex tasks.

25
26
Heuristic 7 Avoid Object Machismo
  • The value of an object is also based on other
    objects
  • An object perfectly suited for one model may be
    totally wrong in another model
  • The object must be placed in context to see
    whether or not it is a good and valuable object.
  • A Valuable Object Works and Plays Well with
    Others.

26
27
Discussion Questions
  • Explain the following statements
  • 1. Objects should be intelligent agents
  • 2. Mechanism rich and policy free
  • 3. A valuable object works and plays well with
    others
  • 4. Analysis model should not be too elaborate or
    too formal
  • Explain how to build an analysis model
  • Explain how do you make the analysis model more
    adaptable
  • Essay Topic Analysis Guidelines

27
28
Questions for the Next Lecture
  • Modeling Concepts, such as
  • Concepts
  • Roles
  • Actors
  • Systems
  • Logical forms
  • Structures
  • Abstraction

28
29
Tasks for Next Lecture
  • Task 1 Problem Statement for team projects are
    needed (see sample problems on OOPSLA
    DesignFest). This is due on the third week of
    the semester.
  • Task 2 Identify the team members of your team.
    Select a team name and e-mail me, the team name,
    teams members names, their e-mails, phone
    numbers -- Immediately.
  • Task 3 Think about extra assignments and writing
    essays. E-mail me if you like to start right
    away.
  • Please note that problem statements must be
    submitted electronically as MS Word format.

29
About PowerShow.com