Previously on EcoFlow…

Presented By: Joe Bolinger

12/3/09

What is EcoFlow?The Concept

“An innovative decision support tool that helps maximize the financial and societal benefits of industrial ecology – converting waste to profit”

“Eco-FlowTM is the first software tool that couples visual editing of network structures with real-time mathematical optimization”

What is EcoFlow?The Business Context

EcoFlow is primarily a methodology of analysis developed by OSU’s Center for ResilienceA standard way of modeling industrial ecology

problemsA standard way of engaging multiple industry

partners to do the analysis

Initially a Spreadsheet was used to implement the modeling and analysis

What is EcoFlow?The New Software

EcoFlow Workbench

3: The Architecture

Presented By: Joe Bolinger

12/3/09

Today’s Outline

ArchitectureFor the Design ProcessConceptual Modeling & Multiple Views

As an Output of Design Software Frameworks & Patterns

Our GoalsDemonstrate an Architectural Process Example ArtifactsWatch for “patterns” again

ArchitectureFor the Design Process

2 Important Conceptual Views of an ArchitectureThe Clients’ Conceptual ViewThe Developers’ Conceptual View

As we go try to see how…Analysis of the Clients’ View lead to the design of the

Developers’ ViewAnalysis of the Developers’ View lead to the selection

of technology and implementation patternsThe Process influenced the artifacts

ArchitectureFor the Design Process

The Clients’ Conceptual View

Network Structure

Output:Costs, Flows,

Emissions

Optimization Solver

Database

Graphical

Interface

ArchitectureFor the Design Process

What does this tell us? Important Visualize Model Analyze workflow

This was always emphasized during requirements discussions Network Structure (i.e. data model) very critical

Highly volatile during discussion too

Only Conceptual To date there is no database But there is persistence What’s the difference?

Think of some use cases…. Searching a Network Model for something Searching a set of Network Models for something

Network Structure

Output:Costs, Flows,

Emissions

Optimization Solver

Database

Graphical

Interface

ArchitectureAn Output of Design

The Developers’ Conceptual View

ArchitectureDesigning for Modifiability: Extensibility

Why?

Decouple Visualize Model Analyze workflow

1 2 3

ArchitectureModifiability: Variability & Maintainability

Break network model into 2 parts Same data used in multiple

ways Easier to extend data for

future modeling or analysis needs

Reuse of editor

ArchitectureMultiple Views

ArchitectureLeading to an Implementation

“Generics & Specifics”EcoFlow’s design includes a few Generic Software

Frameworks Such as the 2 Part Model And the Graphical Editor High skill, reuse potential

And lots of Specifics built on the frameworks Such as the actual data model that’s used to define EcoFlow

Models And the behavior of the Graphical Editor & Diagramming tools Lower skill, little reuse

Architecture“Pareto’s Principle”

Eclipse RCP & GEF Framework provide ~80% of what is needed for EcoFlow’s Generic Graphical Editor Framework

Extending Eclipse’s framework to use our 2 Part Model completes the Generic Framework

ArchitectureLeading to an Implementation

In EcoFlow around 20% of the implementation is for building out critical frameworks These are the pieces that lead to the most customer value The *-ilities that are most critical to control

And most of these are minor extensions of other major reusable components Like GEF & the 2 Part Model Pareto Principle again!

The rest of the implementation effort just follows these general patterns Much less skill involved at this point Perfect for rapid prototyping!

Little harder to do when building out the Generics More next time…

ArchitectureRecap

Modeling & Multiple Views Communicate at Different Levels of Detail

Like between Customer & Architect Structural & Behavioral

Communicate Different Kinds of Concerns No examples here 1 person development team

Note use of context diagramming Less use of class, sequence, & other development diagramming

Use of Frameworks An application architecture has just a few major patterns or frameworks

Relative to their use Most application architectures only require a few novel pieces

Recall the trend to integrate (and expand) rather than build from scratch (or re-invent)

Next Time

Design Patterns & Implementation

4: The Software

Presented By: Joe Bolinger

12/3/09

Today’s Outline

ImplementationDesign PatternsA look inside EcoFlowCode examples

Our GoalsDemonstrate Software Design TechniquesWatch for “patterns” again

Design PatternsThe Pattern Approach

Patterns are reusable ‘idioms’ of designUseful at different scopes for various design processes Business/Enterprise Patterns

“Designing a business” Business Development Organizational Patterns

“Designing a team” Project Management Architecture Patterns

“Designing a product or service offering” Analysis & Software Design

Software Design Patterns “Building a piece of a product or service” Software Implementation

Software Design PatternsBackground

Patterns are documented ways of solving common problemsNot like code or specifications!Do not be fooled!

Describe when to use “Forces”

Explain the consequences of useOften appear in groups in a standardized formatPattern “languages”May be domain or industry specific

Software Design PatternsClassical Examples

Some “classical” families of patternsCreational Ex. Factory, Pool, Singleton

Behavioral Ex. Adapter, Decorator, Proxy

Structural Ex. Command, Mediator, Memento, Null/Default Object

Now a real example…

EcoFlow ExampleAdapter Pattern

Adapter is one of the simplest patternsYou’ve probably already used it, now you can talk

about itName: Adapter (Structural Pattern)An adapter is responsible for translating one interface into

another, typically so that incompatible interfaces can be made compatible without changes to the original interfaces.

Adapters are usually small and simple. Compare to a Mediator or Decorator which may add additional behavior.

See the typical structure of this pattern on Wikipedia

EcoFlow ExampleAdapter Pattern

Typical Structure of an AdapterClientAdaptorAdaptee

Image Source: Wikipedia

EclipseWhy an Adapter?

Important “Forces”Eclipse & GEF FrameworksPlug-in Architecture Lots of plug-ins that need to Interoperate Tons of reusable functionality

For example, Zooming, Panning, a Thumbnail View Everything needs a Thumbnail!

How to build an adapter?Use Interfaces? Sometimes…

EclipseAdapter #1

Eclipse’s IAdaptable interfaceThe Adapter is merged with the Adaptee Inside EcoFlow’s “Network Editor”

EclipseAdapter #1

Simple enough…But the editor has to “know” how to adapt itself Sub-classing or using a wrapper class has similar consequences

Okay here, but often a problem…

What if we want to add images to thingsSo that anything can be adapted to an image but

doesn’t need to know it canAn important change in the “forces”Why?

EclipseAdapter #2

Need a “run-time” adapter for thisOne Way to do this is…1. Provide an “Singleton” Adaptor “Factory” that

anyone can use to adapt things.2. Register your image adaptor with that factory that

is responsible for converting things to images.

Looks like…

EclipseAdapter #2

The Adaptor Factory Manager in Eclipse*

The Image Adapter

*Note adapters in Eclipse can be plugged-in and out dynamically. Why might this be important?

Design PatternsRecap

Common language for designLook for patterns everywhereDesign BooksAPI Documentation

Use them as way to document your design Favor reuse or invention unless you have a good reason

They are not solutions, only suggestions

ConclusionA Pattern Approach

We’ve used a pattern approach in this seriesWhy?Can you find a connection?

ConclusionA Pattern Approach

We’ve used a pattern approach in this seriesWhy?Can you find a connection?

How about “Generics & Specifics”?What kind of developers should build the core frameworks?How will using frameworks change your architecture?How might the design of a framework change the design of

a team or vice versa?Check out Conway’s Law…

The End

Thank You!