Csc 480 software engineering
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

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
Csc 480 software engineering

CSC 480Software Engineering

OOAD Process


  • 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