csc 480 software engineering n.
Skip this Video
Download Presentation
CSC 480 Software Engineering

Loading in 2 Seconds...

play fullscreen
1 / 15

CSC 480 Software Engineering - PowerPoint PPT Presentation

  • Uploaded on

CSC 480 Software Engineering. OOAD Process. Topics . Overview: OOAD Process The object model Identifying classes Responsibilities and collaborations Hierarchy: inheritance and aggregation. Macro Development Process. The process can be roughly divided into three major phases

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

PowerPoint Slideshow about 'CSC 480 Software Engineering' - lynley

Download Now 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
  • Overview: OOAD Process
  • The object model
  • Identifying classes
  • Responsibilities and collaborations
  • Hierarchy: inheritance and aggregation
macro development process
Macro Development Process
  • The process can be roughly divided into three major phases
  • Analysis: focusing on what are required
  • Design: answering the questions of how to fulfill the requirements
    • Resulting in blueprints that map functional needs to program units (interrelated classes)
  • Implementation: realizing the design with a working system
down to the ground level
Down to the Ground-Level



in the air


Needs statement



Functional spec




Design docs




System under dev.

System in production

analysis phase
Analysis Phase
  • Specify system needs in a conceptual model
    • High-level, with details omitted
    • Document: system requirement specification (SRS)
  • Completeness
    • a contract between client and developers
  • Consistency: without contradiction
  • Readability: customer & developer (C-&D-) req’ts
  • Addressing all shareholders interests
  • Testability: can be tested against reality
requirements engineering
Requirements Engineering
  • There is no clear-cut boundary between phases
  • In OOA process, use cases are a powerful means to present and organize requirements
    • RUP claims to be use-case-driven
    • Good for revealing both external and internal needs (user and system requirements)
    • Can be used for design, implementation, testing, and user training purposes
the design phase
The Design Phase
  • The goal is to find and present a solution
    • The key is decomposition
      • Interrelated classes: class responsibilities collaborations
      • Focusing on architecture (key classes + interfaces), omitting implementation details
  • The outcome is system design document (SDD)
    • Class diagrams
    • Sequence diagrams
    • State diagrams
design phase
Design Phase
  • Also known as high-level design
    • Classes at various levels of abstraction
    • Relationships among classes
      • Dependency
      • Inheritance
      • aggregation
  • Product design or UI design may be needed
    • Story-boarding
    • Screen navigation charts
implementation phase
Implementation Phase
  • Better known as the construction phase
    • Detail design: sub-class level
      • Data structures, algorithms
    • Coding
    • Unit testing
    • Gradual integration and repeated “system” testing
    • Deployment
object and class
Object and Class
  • An object is characterized by its
    • State:
    • Behavior:
    • Identity
  • A class specifies objects with the same behavior
  • An instance of a class is an object that belongs to the given class
micro development process
Micro Development Process
  • Largely driven by the stream of scenarios and architectural products
    • Identifying classes and objects
    • Identifying semantics of classes and objects
    • Identifying the relationships among classes and objects
    • Implementing classes and objects
identifying classes
Identifying Classes
  • A rule of thumb is to look for nouns in SRS
    • Class candidates usually fall in following categories
      • Tangible things
      • Agents
      • Events and transactions
      • Users and roles
      • Systems
      • System interfaces and devices
      • Foundational classes
identifying responsibilities
Identifying Responsibilities
  • Responsibilities can be mapped to a functional requirement
  • Responsibilities include
    • Things an object need to know: state
    • Operations an object can perform: behavior
  • Assign a responsibility to exactly one class
  • Assign responsibilities as evenly among classes as possible
identifying relationships
Identifying Relationships
  • Relationship types
    • Hierarchical
      • Inheritance
      • Aggregation
    • Association
      • Dependency: aka collaborations
object collaborations
Object Collaborations
  • An object tends to fulfill its responsibilities by collaborating with other objects
  • Client-server contract
    • Client: the object receiving a service
    • Server: the object providing the service
    • Contract: the interface definition through which a service may be requested
    • The client and server roles may change in different collaborations