CSC 395 –Software Engineering

Lecture 16:

Object-Oriented Design –or–Laziness is a Designer’s Best Friend

In This Lecture

Continue to develop the detailed design Break classes’ responsibilities into methods Develop design that is reusable & maintainable Include ability for project to be updated Check that detailed design can actually work

Data Flow Analysis

Real data flow diagrams are complex

No simple solution exists Must rely on logic, experience, & iteration

Data Flow Is Not Enough

Data flow good at finding mid-level modules Split into input, output, & processing methods

Not good at high-level cohesion & coupling Does not show control flow for methods

Diagrams flow between modules Includes both data & control flow

Cohesion determined by describing module Coupling presented in far more pronounced way

Structural Flow Diagram

Modules Complete

Modules complete (for now) Remain open to revision when faults found Do not change otherwise -- real developers ship

Architectural design portion complete (May or may not be part of design workflow)

Process now moves to detailed design Always part of the design workflow

Why Design Workflow Is Hard

Design team should not do too much Design should not perform implementation Design should not include any code

Design team cannot do too little Essential to produce complete detailed design Can dramatically reduce implementation &

maintenance costs

OO Detailed Design Tasks

Convert from domain to solution concepts Domain concepts: street, Pez dispenser, name Solution concepts: Queue, Stack, & String

Determine signatures & visibility How is each module outwardly visible?

Also state important module assumptions Preconditions: what must be true at module start Postconditions: what is true at module completion Invariants: what should not change during module

First Detailed Design Steps

Identify missing attributes and operations Check expected operations performed Develop constructors, destructors, accessors, etc.

Specify signatures and visibility State ranges of values to guarantee correct types Consider class relationships to determine visibility

Specify constraints & exceptions Constraints specify where behavior is defined Exceptions used when behavior violated

Move to Solution Concepts

Examine using or kludging existing modules Try replace new development with JFC classes Modify AWT or Swing classes for user interface

Use past results of experienced developers Do not reinvent wheel or otherwise be an idiot Their knowledge increases your web surfing time

Identify & modify existing app. frameworks Reusable partial application into which we plug

classes to produce custom application Examples include game and graphic engines

¡Viva la Laziness!

Consider if creating new framework worthwhile Needs concrete designs, algorithms, & code that can be

modified to support many possible uses Combine with new or existing class libraries

Collect related classes performing tasks in non-domain specific manner

Could instead consider design patterns Combines abstract designs with cooperating classes to

simplify common processes All very good tools to increase chance of reuse

Optimization Activities

Some limited optimizations can be helpful Sometimes small specificity greatly improves

performance Must decide whether solution-specificity harms

potential reuse or maintenance Only optimize very commonly used tasks

Company Person SkillEmploys Has-skill

Company PersonlanguageSpeaks language

1

*

1 **

*

Other Optimizations

May collapse objects into attributes Only for class with few attributes & little behavior Weigh against maintenance & reuse costs

Some tasks more expensive than others Always delay expensive computations Perform on Just-In-Time (JIT) basis

Can cache (save) expensive results Expense could be in time, space, or resources Triple-check that saved (but out-of-date) results

could not be used accidentally

Data Store Management

Data stores provide clean separation points Usually performed with files or databases Selection requires trade-off between:

Cost Access time Capacity Reliability

Not easy to convert between the two Usually must choose one or other

Handling Global Resources

Multiple modules may use limited resource Physical units - processors, tape drives, satellites Space - disk, screen, buttons Names - objects IDs, filenames

Must consider how resource conflicts handed Direct access is fastest, but may introduce errors Guards & locks limit access, but come with a cost

Decision determined by client’s needs Of course, client is not around anymore

Detailed Design Formats

Complete Class Diagrams

Add format for each attribute in diagram Deduce attribute formats from analysis artifacts Dates use 10 chars whether month or day is first

Promote fields & methods whenever possible Use abstract methods if portion is class specific Do not promote if not applicable to all subclasses

Remove fields whenever possible Fields store objects’ state throughout object Adding unnecessary fields confuses design

Class Diagram With Attributes

Minimize Rework At All Costs

Software engineering all about browsing web Programming is hard; this will not go away Tries giving programmers time to get coffee, relax Simplify process through pseudo-scientific means

Delay decisions as long as possible Wait until all information is available

Similarly delay work until last moment Do not add to UML diagrams until necessary Rework is not bad, but has psychological cost

Testing a Design

Perform design review for all artifacts Correctly reflects specifications at start

Must complete scenarios correctly Must inspect all aspects of design

Small design faults can have large effects

Testing a Design

Programmer must have confidence in design Positive attitudes lead to fewer faults

Proving implementation correct is hard Formal techniques during detailed design helps Developing design using correctness proof

reduces faults Keep expectations in check

Design will change during implementation

In The Next Lecture

Most important, least understood code Provides users first and last impressions Controls every interaction with program Dominant paradigm unchanged in decades

Links to readings on syllabus on web Readings are not optional Monday (& Wednesday) largely discussion-based