108
http://www.arload.net http://www.arload.net

Framework Engineering_Final

Embed Size (px)

DESCRIPTION

 

Citation preview

Page 1: Framework Engineering_Final

http://www.arload.nethttp://www.arload.net

Page 2: Framework Engineering_Final

Framework is ..Framework is ..

Page 3: Framework Engineering_Final

Framework isFramework is……

Page 4: Framework Engineering_Final

Douglas C. Schmidt Says..Douglas C. Schmidt Says..FrameworksFrameworks define define “semi“semi--complete” applicationcomplete” applicationthat embody domainthat embody domain--specific object structures and functionality.specific object structures and functionality.

Page 5: Framework Engineering_Final

Class Library Class Library Component Component ArchitectureArchitecture

App SpecificApp SpecificLogicLogic

OO DesignOO Design

EventEventLoopLoop

DATABASEDATABASE ADTsADTs

MATHMATH NETWORKINGNETWORKING

GRAPHICSGRAPHICS GUIGUI

SingletonSingleton StrategyStrategy

ReactorReactor AdapterAdapter

StateState Active ObjectActive Object

InvocationsInvocations

SelectionsSelections

Application BlockApplication Block

Design PatternDesign Pattern

Libraries is..Libraries is..

Page 6: Framework Engineering_Final

DATABASEDATABASE

SingletonSingleton

GRAPHICSGRAPHICS

AdapterAdapter

EventEventLoopLoop

ReactorReactor

NETWORKINGNETWORKING

Active ObjectActive Object

GUIGUI

StateState

App SpecificApp SpecificLogicLogic

MATHMATH

ADTsADTs

CallbacksCallbacks

InvocationsInvocations

Application Application FrameworkFrameworkComponent ArchitectureComponent Architecture

But Framework is ..But Framework is ..

Page 7: Framework Engineering_Final

Why Do You Need Framework?Why Do You Need Framework?

Avoid Duplication Productivity

Page 8: Framework Engineering_Final

Welcome toWelcome to

My FrameworkMy Framework

Journey!Journey!

Page 9: Framework Engineering_Final

“Framework Engineering”, TechED 2007 Europe

“Framework Design Guidelines” , Addison Wesley

Krzysztof Cwalina

Program Manager on .NET Framework Team

Page 10: Framework Engineering_Final

5 Topics..5 Topics..

Organization

Planning

Architecture

Design

Development

DO P A V

Page 11: Framework Engineering_Final

The most powerful design toolThe most powerful design tool

O

Page 12: Framework Engineering_Final

Project Management TriangleProject Management Triangle

Scope

Cost Time

O

Page 13: Framework Engineering_Final

Project Management Triangle Project Management Triangle

Organization

O

Page 14: Framework Engineering_Final

DODO understand how understand how organizational structure, organizational structure, culture, and decision making processesculture, and decision making processes impaimpact your product. ct your product.

O

Page 15: Framework Engineering_Final

Conway's lawConway's law

If you have 4 groups working on a compiler,

you’ll get a 4-pass compiler.

O

Page 16: Framework Engineering_Final

Organization Structure

Software Structure

O

Page 17: Framework Engineering_Final

Conway's Clean State ApproachConway's Clean State Approach

1• Define the business mission• Define the business mission

2• Learn the business process from business owners• Learn the business process from business owners

3• Re-engineer these process to fit the mission• Re-engineer these process to fit the mission

4

• Structure the IT organization to support the reengineered business processes.

• Structure the IT organization to support the reengineered business processes.

O

Page 18: Framework Engineering_Final

Your Company Culture Is ..Your Company Culture Is ..

Voluntary ??O

Page 19: Framework Engineering_Final

Familial ??O

Your Company Culture Is ..Your Company Culture Is ..

Page 20: Framework Engineering_Final

Peremptory O

Page 21: Framework Engineering_Final

Organizational InfluencesOrganizational InfluencesSize of OrganizationSize of Organization

Small Team

Simple Design

Consistency Design

Focus on 80/20 Rules

O

Page 22: Framework Engineering_Final

Large Team

Organizational InfluencesOrganizational InfluencesSize of OrganizationSize of Organization

Powerful Design

Lack Consistency

Remove Requirements

O

Page 23: Framework Engineering_Final

Organizational InfluencesOrganizational InfluencesOrganization’s Culture/BiasesOrganization’s Culture/Biases

Customer-Focused

End-2-End Scenarios

O

Page 24: Framework Engineering_Final

Organizational InfluencesOrganizational InfluencesOrganization’s Culture/BiasesOrganization’s Culture/Biases

Technology-Focused

Long Lasting Architecture

O

Page 25: Framework Engineering_Final

Decision Making Process is..Decision Making Process is..

O

Page 26: Framework Engineering_Final

Ensuring we are building the right thing Ensuring we are building the right thing

P

Page 27: Framework Engineering_Final
Page 28: Framework Engineering_Final

P

Page 29: Framework Engineering_Final

Focus: featuresFocus: features

Results: Results: stability, stability,

incremental incremental

improvements, not improvements, not

great great endend--toto--end end

scenariosscenarios

Peanut ButterPeanut Butter

Focus: scenarios Focus: scenarios

Results: Results: Excitement, Excitement,

breakthroughs, but breakthroughs, but

beware of leaving beware of leaving

existing customers existing customers

behind behind

SkyscrapersSkyscrapers

P

Page 30: Framework Engineering_Final

MModeration (oderation (中庸中庸))MileStone = Scenarios + FeatureMileStone = Scenarios + Feature

Planning M1 M2

ReleaseTesting

Feature completeVision statement RTM

Technology Preview Beta 1 Beta 2 RC1

Page 31: Framework Engineering_Final

Ensuring the long term health of the frameworkEnsuring the long term health of the framework

A

Page 32: Framework Engineering_Final

A

Right Way??Right Way??CChoose right types.hoose right types.

Page 33: Framework Engineering_Final

Taxonomy of Taxonomy of TypesTypesLibraries Libraries , Primitives, Abstractions, Primitives, Abstractions

A

Page 34: Framework Engineering_Final

PrimitivesPrimitivesVery little policy (behavior design decisions)

Stable design

Commonly appear in publicly accessible APIs

Almost impossible to evolve/change design;

any design changes have huge breaking change impact on other APIs

Example: Int32, String

A

Page 35: Framework Engineering_Final

Definition:Libraries are types that are not passed between components

ExamplesEventLog, Debug,

Easy to EvolveLeave old in, add new one

Beware of duplication!

A

LibrariesLibraries

Page 36: Framework Engineering_Final

AbstractionsAbstractions

Definition:Abstractions are interfaces or classes with unsealed members that are passed between components.

ExamplesStream, IComponent

Hard to Evolve

Unfortunately, pressure to evolve

A

Page 37: Framework Engineering_Final

Primitive Oriented DesignPrimitive Oriented Design

A.K.A. “Handle based design” (functional)

Great evolvability, poor usability (sometimes)

Low level stable primitives + high level reusable components with limited dependencies other than to the primitives

E.g. Type.GetType(object) – works, but not as convenient as Object.GetType

A

Page 38: Framework Engineering_Final

for primitive.. for primitive.. C# 3.0 New FeatureC# 3.0 New Featurenamespace MyCompany.StringManipulation {

public static class StringExtensions{

public static bool IsNullOrEmpty(this string s){ return String.IsNullOrEmpty(s);

}

}

}

using MyCompany.StringManipulation;

string message= “hello world”;

if(message.IsNullOrEmpty()){

Console.WriteLine(“EMPTY”);

}

Page 39: Framework Engineering_Final

Component Oriented DesignComponent Oriented Design

Rich APIs with lots of features, thus with lots of dependencies

Great usability, poor evolvability

Good for higher level components, not for the core of a platform

A

Page 40: Framework Engineering_Final

A

DODO Manage Dependencies..Manage Dependencies..

Page 41: Framework Engineering_Final

A

Lego, Plug ??

Component is ..

Page 42: Framework Engineering_Final

A

.. a set of types that ship and evolve as a unit.

Page 43: Framework Engineering_Final

A

Dependency

API

Implementation

Circular

Page 44: Framework Engineering_Final

API DependencyAPI Dependency

Component A has an API dependency on component B,

if a type in B shows in the publicly accessible API surface of a type in A.

This includes:Base types and implemented interfaces

Generic parameter constraints

Return types and parameters of members

Applied attributes

Nested types

A

Page 45: Framework Engineering_Final

Implemenatin Implemenatin DependencyDependency

If a type in A uses a type in B in its implementation.

Hard Dependencies (required to run)Soft Dependencies (optional)

A

Page 46: Framework Engineering_Final

Circular Circular DependencyDependency

Component A depends on component B and

Component B depends on component A (even indirectly).

A

Page 47: Framework Engineering_Final

Packaging Packaging PrinciplePrinciple

Package Cohesion PrincipleREP (Release Reuse Equivalency)

CCP (Common Closure Principle)

CRP (Common Reuse Principle)

Package Coupling PrincipleADP (Acyclic Dependencies Principle)

SDP (Stable Dependencies Principle)

SAP (Stable Abstraction Principle)

ARobert C. Martin, Principle of Package Architecture

http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf

Page 48: Framework Engineering_Final

A

Page 49: Framework Engineering_Final

Solution is Layering..Solution is Layering..

A

Page 50: Framework Engineering_Final

xDepend (NxDepend (NDDepend)epend)

NDepend - http://www.ndepend.com

Page 51: Framework Engineering_Final

A

BCLBCL

WPFWPF XMLXML

ReflectionReflection

Page 52: Framework Engineering_Final

Circular Circular DependencyDependency

A

GUIGUI

CommCommAnalysisAnalysis

ProtocolProtocolModem Modem

ControlControl

CommComm

ErrorError

DDatabaseatabase

Page 53: Framework Engineering_Final

Creating a new packaging.Creating a new packaging.

Page 54: Framework Engineering_Final

A

GUIGUI

CommCommAnalysisAnalysis

ProtocolProtocolModem Modem

ControlControl

CommComm

ErrorError

DDatabaseatabase

MessageMessage

ManagerManager

Page 55: Framework Engineering_Final

AA

BB

XX

YY

Circular DependencyCircular Dependency

Page 56: Framework Engineering_Final
Page 57: Framework Engineering_Final

AA

BB

XX

YY<<interface>><<interface>>

BYBY

Adding new interfaceAdding new interface

Page 58: Framework Engineering_Final

Heavy DepedencyHeavy Depedency

A

Page 59: Framework Engineering_Final

A

Page 60: Framework Engineering_Final

Heavy Dependencies and TestabilityHeavy Dependencies and Testability

// your API

public class Tracer {

MessageQueue mq = new MessageQueue(…);

public void Trace(string message){

mq.Send(message);

}

}

// your customer’s program that is hard to test

Tracer tracer = new Tracer();

public void ProcessOrder(Order order){

tracer.Trace(order.Id);

}

Page 61: Framework Engineering_Final

Inversion of ControlInversion of Control

// your better API

public abstract class TraceListener {

public abstract void Trace(string message);

}

public class Tracer {

TraceListener listener;

public Tracer(TraceListener listener){

this.listener = listener;

}

public void Trace(string message){

listener.Trace(message);

}

}

Page 62: Framework Engineering_Final

Dependency InjectionDependency Injection

// your customer’s program that is easier to test

Tracer tracer = new Tracer(new FileListener());

public void ProcessOrder(Order order){

tracer.Trace(order.Id);

}

Page 63: Framework Engineering_Final

// customer’s program that is even easier to test

Tracer tracer = container.Resolve<Tracer>();

public void ProcessOrder(Order order){

tracer.Trace(order.Id);

}

Check out DI Containers (a.k.a. IoC Containers): autofac, Castle Windsor, PicoContainer.NET, Spring.NET, StructureMap, Unity, nInject and others.

http://www.nInject.org

Page 64: Framework Engineering_Final

DO balance advances with compatibility.

A

Page 65: Framework Engineering_Final

Types of “Compatibility” Types of “Compatibility”

A

CrossCross--VersionVersion

BackwardBackward

ForwardForward

Page 66: Framework Engineering_Final

A

CrossCross--RedistRedist..

Page 67: Framework Engineering_Final

A

Page 68: Framework Engineering_Final

Define what’s a “breaking change”

This definition depends on the objectiveE.g. Enable portable code between Silverlight and .NET Framework

E.g. Enable cross-version portability?

For example, Silverlight interfaces cannot have less members than .NET interfaces, but concrete types can.

A

Page 69: Framework Engineering_Final

AVOID duplication and overlap.

A

Page 70: Framework Engineering_Final

A

ProblemProblem SpaceSpace Show and TellShow and Tell

PLoP – Capable, Productive and Satisfied Patterns for Productivity

http://hillside.net/plop/plop98/final_submissions/P54.pdf

Page 71: Framework Engineering_Final

When the new technology is “10x better”

Make sure you understand the impact on the ecosystem

What would happen if the BCL team added a new String?

What’s the migration path for code using the old API?

A

Page 72: Framework Engineering_Final

This is where quality happensThis is where quality happens

D

Page 73: Framework Engineering_Final

Is using your framework correctly like…Is using your framework correctly like…

Running across a desert?Running across a desert?

Page 74: Framework Engineering_Final

A

Page 75: Framework Engineering_Final

DO design APIs by

first writing code samples for the main scenarios

and then

defining the object model to support the code samples.

D

Page 76: Framework Engineering_Final

Code SamplesCode Samples

D

Page 77: Framework Engineering_Final

Read FileRead File

static void Main(string[] args)

{

StreamReader sr = File.OpenText("MyFile.txt");

string s = sr.ReadLine();

while (s != null)

{

s = sr.ReadLine();

Console.WriteLine(s);

}

}

D

Page 78: Framework Engineering_Final

static void Main(string[] args)

{

foreach (string s in File.ReadAllLines("MyFiles.text"))

{

Console.WriteLine(s);

}

}

Feedback (Read File)Feedback (Read File)

D

Page 79: Framework Engineering_Final

Object Model ListingObject Model Listing

D

Page 80: Framework Engineering_Final

Framework Design Studio Framework Design Studio Assembly ExploerAssembly Exploer

Project -> Add -> Assembly

Download here - http://code.msdn.microsoft.com/fdsD

Page 81: Framework Engineering_Final

Framework Design Studio Framework Design Studio Assembly Review CommentAssembly Review Comment

D

Page 82: Framework Engineering_Final

Framework Design StudioFramework Design StudioCompare API VersionsCompare API Versions

D

Page 83: Framework Engineering_Final

Framework Design StudioFramework Design StudioCompare API VersionsCompare API Versions

Red is removed,

Green is added,

Grey means inherited.

D

Page 84: Framework Engineering_Final

Framework Design StudioFramework Design StudioExporting to Microsoft WordExporting to Microsoft Word

Tools -> Export to Document

Page 85: Framework Engineering_Final

DO treat simplicity as a feature.

D

Page 86: Framework Engineering_Final

Remove Requirements

Reuse Existing Concepts or APIs

Adjust Abstraction Level

Three Example (Evolving Frameworks)

D

Page 87: Framework Engineering_Final

DO measure, measure, and measure!

D

Page 88: Framework Engineering_Final

Specification Document: QualitiesSpecification Document: Qualities

Performance GoalsBaseline: What do is the best my API could do?

Measure delta from the baseline

Threat ModelsThreat: What is the worst that my component could do?

Mitigate the threats

Same for many other qualities you want your framework to have

D

Page 89: Framework Engineering_Final

THE POWER OF SAMENESS

D

Page 90: Framework Engineering_Final

When you pick up your rental car….When you pick up your rental car….

Push the seat all the way back

Find an NPR station

Find the exit

Read the manual??Read the manual??

Page 91: Framework Engineering_Final

Oh, down to lock…Oh, down to lock…

Page 92: Framework Engineering_Final

How to use a key…How to use a key…

Page 93: Framework Engineering_Final

Oh, you Oh, you pushpush the PRESS button…the PRESS button…

Page 94: Framework Engineering_Final

Who actually Who actually needs needs this data?this data?

Page 95: Framework Engineering_Final

You know how to drive your car

All cars work basically the same way

Your rental car is a car

Therefore, you can drive your rental car

That is…

Page 96: Framework Engineering_Final

http://blogs.msdn.com/fxcophttp://blogs.msdn.com/fxcop

Page 97: Framework Engineering_Final

The bits customers get, … or notThe bits customers get, … or not

V

Page 98: Framework Engineering_Final

Branches and IntegrationsBranches and Integrations

Main

PU-staging

branch

Feature

branch

Feature

branch

PU-staging

branch

PU-staging

branch

V

Page 99: Framework Engineering_Final

AVOID integrating unfinished features.

V

Page 100: Framework Engineering_Final

Functional SpecificationDeveloper Design SpecificationTest PlanThreat ModelAPI reviewArchitectural ReviewDependency ManagementStatic AnalysisCode CoverageTesting (Unit and Integration Tests)0 BugsPerformance

V

Page 101: Framework Engineering_Final

DO pay your debt.

V

Page 102: Framework Engineering_Final

Planning M1 M2

ReleaseTesting

Feature completeVision statement RTM

Technology Preview Beta 1 Beta 2 RC1

Milestone Quality

Page 103: Framework Engineering_Final

Milestone Quality (MQ)Milestone Quality (MQ)

Initiatives that are hard to do in regular milestones

Large productivity and efficiency improvements

Infrastructure changes

For example, a new source control system

Refactoring of fragile subsystems

Internal implementation documentation

Bugs backlog

V

Page 104: Framework Engineering_Final

DO understand how organizational structure, culture, and decision making processes impact your product.

AVOID peanut-butter in Scenario Based Application.

DO manage your dependencies.

DO balance advances with compatibility.

AVOID duplication and overlap.

DO design APIs by first writing code samples for the main scenarios and then defining the object model to support the code samples.

DO treat simplicity as a feature.

DO measure, measure, and measure!

AVOID integrating unfinished features.

DO pay your debt.

Page 106: Framework Engineering_Final

Douglas C. Schmidt (PLoP Editor, POSA 2, 4 Writter)

JAWS: An Application Framework for High Performance Web Systemhttp://citeseer.ist.psu.edu/81775.html (En)http://www.devpia.com/net2/EvaCast/Lecture/?cu=view&r=11 (Kr)

Ralph Johnson (GoF , Design Patterns)

Evolving Frameworkshttp://st-www.cs.uiuc.edu/users/droberts/evolve.html (En)http://arload.wordpress.com/2008/09/15/evolvingframeworks/ (Kr)

Page 107: Framework Engineering_Final

Robert C. MartinPrinciples of Package Architecture (Design Principles and Design Patterns)

http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf (En) http://www.devpia.com/net2/EvaCast/Lecture/?cu=view&r=108 (Kr)

For Korean People..

Load to Architecthttp://www.arload.net

EvaCast (Online Free Lecture)http://www.evacast.net