oo analysis and design n.
Download
Skip this Video
Loading SlideShow in 5 Seconds..
OO Analysis and Design PowerPoint Presentation
Download Presentation
OO Analysis and Design

Loading in 2 Seconds...

play fullscreen
1 / 33

OO Analysis and Design - PowerPoint PPT Presentation


  • 54 Views
  • Uploaded on

OO Analysis and Design. CMPS 2143. OOA/OOD. Cursory explanation of OOP emphasizes Syntax classes, inheritance, message passing, virtual, static Most important aspect: Design technique to create a universe of autonomous interacting agents

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'OO Analysis and Design' - tabib


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
ooa ood
OOA/OOD
  • Cursory explanation of OOP emphasizes
    • Syntax
      • classes, inheritance, message passing, virtual, static
  • Most important aspect:
    • Design technique to create a universe of autonomous interacting agents
    • We will focus on the OOD technique called responsibility-driven design
responsibility
Responsibility
  • Implies degree of independence and noninterference
  • Client code doesn’t need to worry about representation/implementation
  • Responsibility design elevates information hiding from a technique to an art.
    • Vitally important for “programming in the large”
begin with behavior
Begin with Behavior
  • Why?
    • Usually it is understand long before any other aspect
  • Do this before data structures / order of function calls
  • Structural elements usually only understood after considerable amount of analysis
  • Customers understand system behavior
ooa describing a system
OOA: Describing a system
  • Initial system specifications are sketchy, ambiguous
  • Often describe actions to be performed  behavior
    • Perfect for responsibility driven design
  • How? With scenarios
    • Act out the running of the application – example in book
  • Use these to rewrite the specifications
  • THEN identify components
    • Component == abstract entity that can perform tasks to fulfill responsibilities
characteristics of a component
Characteristics of a Component
  • Must have a small, well-defined set of responsibilities
  • Interacts with other components to the minimal extent possible
component responsibility collaborator crc modeling
Component-Responsibility-Collaborator (CRC) Modeling
  • OOA classes have “responsibilities”
    • Responsibilities are the attributes and operations encapsulated by the component/class
  • OOA classes collaborate with one another
    • Collaborators are other components/classes that are required to provide a component/class with the information needed to complete a responsibility.
    • In general, a collaboration implies either a request for information or a request for some action.
identifying components
Identifying Components
  • Analyze specifications (problem description) and scenarios
  • Underline nouns/circle verbs (ignore system, data, information….too vague)
  • Nouns  components or attributes of components  classes and member data
  • Verbs  responsibilities of components  methods
why you should use index cards
Why you should use index cards!!!
  • Cheap, widely available, erasable
  • Encourages EXPERIMENTATION
    • Try different designs, throw them away…
  • Forces you to keep components PHYSICALLY separate
  • Constrains complexity
    • Divide components
    • Move some responsibilities
  • Start of documentation
interactive intelligent kitchen helper
Interactive Intelligent Kitchen Helper
  • Read 3.4.1
  • Read Figure 3.2
  • Read 3.6
  • Good example/walkthrough of thought process of designer
in class work
In class work

Working in teams of two, complete the steps below. Your team may be asked to display your work for the whole class to review.

1. Treat the problem description above as a problem narrative and do the necessary "underlining/circling".

2. Propose a class to be used in this problem. Propose a set of properties (member data) Propose a set of responsibilities (methods) for the class. Mention any collaborators.

3. Create a CRC card. Be sure to include both the behavioral and knowledge responsibilities. The “back” of the CRC card can be where you list the properties – indicate the type for each property.

slide13

Problem: SPU is a new over-night shipping company. They have asked you to write a program to keep track of their packages. Specifically, they want a program that will store data about individual packages including the sender’s name and address, the receiver’s name and address, the weight of the package (in pounds and ounces), the location of the package (represented with a special SPU code), the status of the package (delivered or not), and the type of shipping (1 day air, 2 day air, any-time-soon). The program should allow an operator to find out any of these pieces of information about a package and change the status and location. Operators should be able to ask for the weight in pounds/ounces or kilograms/grams.

class
Class: ???

Responsibilities

Collaborators

knowledge
Knowledge

data

type

object models
Object models
  • Object models describe the system in terms of object classes and their associations.
  • An object class is an abstraction over a set of objects with common attributes and the services (operations) provided by each object.
  • Various object models may be produced
    • Simple object models
    • Inheritance models
    • Aggregation models
    • Interaction models
  • UML notations exist for these…
object model class diagram
Object Model: Class Diagram

Classname

attributes

operations

inheritance models
Inheritance models
  • Organize the domain object classes into a hierarchy.
  • Classes at the top of the hierarchy reflect the common features of all classes.
  • Object classes inherit their attributes and services from one or more super-classes. These may then be specialised as necessary.
object aggregation
Object Aggregation
  • An aggregation model shows how classes that are collections are composed of other classes.
  • Aggregation models are similar to the part-of relationship in semantic data models.
object behaviour modelling
Object behaviour modelling
  • Diagrams so far illustrate static relationships between components
  • Dynamic interactions also need to be described
  • A behavioural model
    • shows the interactions between objects
    • to produce a behaviour that was specified as a use-case
  • Collaboration diagrams in UML are used to model interaction between objects
    • Example: Sequence diagrams
interaction sequence diagrams
Interaction | Sequence diagrams
  • These show the sequence of events that take place during some user interaction with a system.
  • You read them from top to bottom to see the order of the actions that take place.
state
State
  • Components are NOT just characterized by behavior, but also by the information they contain
  • State – all the information (data values) within a component at any given moment in time
  • Class refers to a set of objects with similar behavior
  • Object/Instance refers to an individual representative of a class
other concepts in chapter 3
Other concepts in chapter 3
  • Cohesion
    • Degree to which the responsibilities of a single component form a meaningful unit
    • Aim for high cohesion / associate related tasks w/i same component
  • Coupling
    • Degree that software components are related
    • Aim for low coupling / reduce the amount that one component must access the data values – the state- of another component
other concepts in chapter 31
Other concepts in chapter 3
  • Interface
    • Discussed already
    • Just goes into more detail
  • Naming
implementation
Implementation
  • Choose your language
  • Implement the representation  choose your data structures
    • Choose a classic data structure
    • Make up your own
  • Implement components’ desired behavior
    • Choose your algorithms
slide32
Test
  • Unit test individual components
    • Need drivers (for example: MyQueueTest.java)
  • Integration test
    • Start combining components
    • If a component isn’t finished – stub it out