1 / 34

Previously on EcoFlow …

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”

nibaw
Download Presentation

Previously on EcoFlow …

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. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Previously on EcoFlow… Presented By: Joe Bolinger 12/3/09

  2. 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”

  3. What is EcoFlow?The Business Context • EcoFlow is primarily a methodology of analysis developed by OSU’s Center for Resilience • A standard way of modeling industrial ecology problems • A standard way of engaging multiple industry partners to do the analysis • Initially a Spreadsheet was used to implement the modeling and analysis

  4. What is EcoFlow?The New Software • EcoFlow Workbench

  5. 3: The Architecture Presented By: Joe Bolinger 12/3/09

  6. Today’s Outline • Architecture • For the Design Process • Conceptual Modeling & Multiple Views • As an Output of Design • Software Frameworks & Patterns • Our Goals • Demonstrate an Architectural Process • Example Artifacts • Watch for “patterns” again

  7. ArchitectureFor the Design Process • 2 Important Conceptual Views of an Architecture • The Clients’ Conceptual View • The Developers’ Conceptual View • As we go try to see how… • Analysis of the Clients’ View lead to the design of the Developers’ View • Analysis of the Developers’ View lead to the selection of technology and implementation patterns • The Process influenced the artifacts

  8. ArchitectureFor the Design Process Graphical Interface Database Network Structure Optimization Solver Output:Costs, Flows, Emissions • The Clients’ Conceptual View

  9. ArchitectureFor the Design Process Graphical Interface Database Network Structure Optimization Solver Output:Costs, Flows, Emissions • 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

  10. ArchitectureAn Output of Design • The Developers’ Conceptual View

  11. ArchitectureDesigning for Modifiability: Extensibility • Why? • Decouple Visualize  Model  Analyze workflow 1 2 3

  12. 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

  13. ArchitectureMultiple Views

  14. 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

  15. Architecture“Pareto’s Principle” Eclipse RCP & GEF Framework provide ~80% of what is needed for EcoFlow’sGeneric Graphical Editor Framework Extending Eclipse’s framework to use our 2 Part Model completes the Generic Framework

  16. 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…

  17. 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)

  18. Next Time • Design Patterns & Implementation

  19. 4: The Software Presented By: Joe Bolinger 12/3/09

  20. Today’s Outline • Implementation • Design Patterns • A look inside EcoFlow • Code examples • Our Goals • Demonstrate Software Design Techniques • Watch for “patterns” again

  21. Design PatternsThe Pattern Approach • Patterns are reusable ‘idioms’ of design • Useful 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

  22. Software Design PatternsBackground • Patterns are documented ways of solving common problems • Not like code or specifications! • Do not be fooled! • Describe when to use • “Forces” • Explain the consequences of use • Often appear in groups in a standardized format • Pattern “languages” • May be domain or industry specific

  23. Software Design PatternsClassical Examples • Some “classical” families of patterns • Creational • Ex. Factory, Pool, Singleton • Behavioral • Ex. Adapter, Decorator, Proxy • Structural • Ex. Command, Mediator, Memento, Null/Default Object • Now a real example…

  24. EcoFlow ExampleAdapter Pattern • Adapter is one of the simplest patterns • You’ve probably already used it, now you can talk about it • Name: 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

  25. EcoFlow ExampleAdapter Pattern • Typical Structure of an Adapter • Client • Adaptor • Adaptee Image Source: Wikipedia

  26. EclipseWhy an Adapter? • Important “Forces” • Eclipse & GEF Frameworks • Plug-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…

  27. EclipseAdapter #1 • Eclipse’s IAdaptable interface • The Adapter is merged with the Adaptee • Inside EcoFlow’s “Network Editor”

  28. 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 things • So that anything can be adapted to an image but doesn’t need to know it can • An important change in the “forces” • Why?

  29. EclipseAdapter #2 • Need a “run-time” adapter for this • One Way to do this is… • Provide an “Singleton” Adaptor “Factory” that anyone can use to adapt things. • Register your image adaptor with that factory that is responsible for converting things to images. • Looks like…

  30. 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?

  31. Design PatternsRecap • Common language for design • Look for patterns everywhere • Design Books • API 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

  32. ConclusionA Pattern Approach • We’ve used a pattern approach in this series • Why? • Can you find a connection?

  33. ConclusionA Pattern Approach • We’ve used a pattern approach in this series • Why? • 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…

  34. The End Thank You!

More Related