CSCE 431 Lecture 7

« previous | Tuesday, February 4, 2014 | next »

Design

Specification and domain properties imply the requirements

Come up with a design that satisfies the requirements

There's a semantic gap between requirements and design.

Lots of advice on how to bridge
Hard to give concrete methods (no silver bullet)
Our focus: object-oriented analysis and design
object-oriented analysis in general gives good understanding

Analysis

Formalize requirements specification
- examine exceptional cases, boundary conditions
Object-Oriented Analysis
- developers build an object model of the application domain
- Extend model with how actors and system interact with application domain objects

Trade-Offs

Create design that matches requirements as closely as possible?

versus

Reuse existing designs/implementations as much as possible, at expense of less direct match to requirements.

Create class hierarchy that closely matches problem domain?

versus

Create class hierarchy that supports extensibility, reuse, etc. and uses abstractions from implementation domain

UML Models

Functional: Functionality of the system from user's point of view; use-case diagrams
Object: structure of system; objects, attributes, associations, operations; analysis of object model → system design object model → design object model
Dynamic: describes behavior of objects (states, state transitions, control flow, data flow); Interaction diagrams; State machines; Activity diagrams

Used by both analysts and developers:

During requirements analysis to model application domain concepts
During system design to model subsystems
During object design to specify classes in detail, including methods and attributes.

Static Structure of System

What kind of objects are in the system?

Classes
Relations between classes

Many notations exist:

Entity-Relationship (ER) models
UML Class diagrams

Class Diagrams

Classes: name, attributes, operations
Associations: navigation arrows, multiplicities, qualifications, qualifications, roles
Association Classes

Object Modeling

Most of the real world can be modeled with objects.

Goal: find important abstractions

understand the system
serve as blueprint of an implementation

Note: As a useful guideline, implementation should be a refinement of analysis classes.

Process

Iterate in some order, until convergence:

Identify classes
Find attributes
Find operations
Find associations between classes

(too vague)

Example, Abbott's Technique

The customer enters the store to buy a toy

Map grammatical constructs to model components:

"Monopoly" is a type of a toy. Therefore it can be an instance or a subclass of type Toy
Customers enter a store, so there should be a Store class with an enter() method that the user would call

Use this method with caution

Class Elicitation

Clearly associated abstraction, which can be described as a data abstraction or abstract machine
Class name is noun or adjective
Class represents one or more possible run-time objects
Commands available to change internal state

Three types of classes:

Analysis: belong to problem space; describe data abstractions directly drawn from the domain model
Design: belong to solution space; describe architectural choices
Implementation: belong to solution; describe abstractions introduced for internal needs of algorithms