Your SlideShare is downloading. ×

Framework Engineering Revisited

220

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
220
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. http://www.arload.nethttp://www.arload.net
  • 2. Frameworkis ..Frameworkis ..
  • 3. Framework isFramework is……
  • 4. Douglas C. Schmidt Says..Douglas C. Schmidt Says.. FrameworksFrameworks definedefine “semi“semi--complete” applicationcomplete” application that embody domainthat embody domain--specific object structures and functionality.specific object structures and functionality.
  • 5. App SpecificApp Specific LogicLogic EventEvent LoopLoop DATABASEDATABASE ADTsADTs MATHMATH NETWORKINGNETWORKING GRAPHICSGRAPHICS GUIGUI SingletonSingleton StrategyStrategy InvocationsInvocations Application BlockApplication Block Libraries is..Libraries is.. Class LibraryClass Library ComponentComponent ArchitectureArchitecture OO DesignOO Design LoopLoop SingletonSingleton StrategyStrategy ReactorReactor AdapterAdapter StateState Active ObjectActive Object SelectionsSelections Design PatternDesign Pattern
  • 6. EventEvent ReactorReactor NETWORKINGNETWORKING Active ObjectActive Object GUIGUI StateState App SpecificApp Specific LogicLogic MATHMATH InvocationsInvocations But Framework is ..But Framework is .. DATABASEDATABASE SingletonSingleton GRAPHICSGRAPHICS AdapterAdapter EventEvent LoopLoop LogicLogic ADTsADTs CallbacksCallbacks ApplicationApplication FrameworkFramework Component ArchitectureComponent Architecture
  • 7. Why Do You Need Framework?Why Do You Need Framework? Avoid Duplication Productivity
  • 8. Welcome toWelcome to My FrameworkMy FrameworkMy FrameworkMy Framework Journey!Journey!
  • 9. “Framework Engineering”, TechED 2007 Europe “Framework Design Guidelines” , Addison Wesley Krzysztof Cwalina Program Manager on .NET Framework Team
  • 10. 5 Topics..5 Topics.. OrganizationDevelopment Planning Architecture Design DO P A V
  • 11. ThemostpowerfuldesigntoolThemostpowerfuldesigntool O
  • 12. Project Management TriangleProject Management Triangle Scope Cost Time O
  • 13. Organization Project Management TriangleProject Management Triangle Organization O
  • 14. DODO understand howunderstand how organizational structure,organizational structure, culture, and decision making processesculture, and decision making processes impaimpa ct your product.ct your product. O
  • 15. Conway's lawConway's law If you have 4 groups working on a compiler, you’ll get a 4-pass compiler. O
  • 16. Organization Structure Software Structure O
  • 17. 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 reengine ered business processes. • Structure the IT organization to support the reengine ered business processes. O
  • 18. Your Company Culture Is ..Your Company Culture Is .. Voluntary ?? O
  • 19. Your Company Culture Is ..Your Company Culture Is .. Familial ?? O
  • 20. Peremptory O
  • 21. Organizational InfluencesOrganizational Influences SizeofOrganizationSizeofOrganization Simple Design Consistency Design Small Team Consistency Design Focus on 80/20 Rules O
  • 22. Organizational InfluencesOrganizational Influences SizeofOrganizationSizeofOrganization Powerful Design Lack Consistency Large Team Lack Consistency Remove Requirements O
  • 23. Organizational InfluencesOrganizational Influences Organization’sCulture/BiasesOrganization’sCulture/Biases Customer-Focused End-2-End Scenarios O
  • 24. Organizational InfluencesOrganizational Influences Organization’sCulture/BiasesOrganization’sCulture/Biases Technology-Focused Long Lasting Architecture O
  • 25. Decision Making Process is..Decision Making Process is.. O
  • 26. Give this book your boss..Give this book your boss..
  • 27. EnsuringwearebuildingtherightthingEnsuringwearebuildingtherightthing P
  • 28. P
  • 29. P
  • 30. Peanut ButterPeanut Butter SkyscrapersSkyscrapers Focus: featuresFocus: features Results:Results: stability,stability, incrementalincremental improvements, notimprovements, not greatgreat endend--toto--endend scenariosscenarios Focus: scenariosFocus: scenarios Results:Results: Excitement,Excitement, breakthroughs, butbreakthroughs, but beware of leavingbeware of leaving existing customersexisting customers behindbehind P
  • 31. MModeration (oderation (中庸中庸)) MileStone =Scenarios+FeatureMileStone =Scenarios+Feature Planning M1 M2 Release Testing Feature completeVision statement RTM Planning M1 M2 Testing Technology Preview Beta 1 Beta 2 RC1 P
  • 32. EnsuringthelongtermhealthoftheframeworkEnsuringthelongtermhealthoftheframework A
  • 33. Right Way??Right Way?? CChoose right types.hoose right types. A
  • 34. Taxonomy ofTaxonomy of TypesTypes LibrariesLibraries,Primitives,Abstractions,Primitives,Abstractions A
  • 35. PrimitivesPrimitives Very 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
  • 36. Definition: Libraries are types that are not passed between com ponents Examples EventLog, Debug, LibrariesLibraries EventLog, Debug, Easy to Evolve Leave old in, add new one Beware of duplication! A
  • 37. AbstractionsAbstractions Definition: Abstractions are interfaces or classes with unsealed member s that are passed between components. Examples Stream, IComponent Hard to EvolveHard to Evolve Unfortunately, pressure to evolve A
  • 38. 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 dep endencies other than to the primitives E.g. Type.GetType(object) – works, but not as convenient as Object.GetType A
  • 39. for primitive..for primitive.. C#3.0NewFeatureC#3.0NewFeature namespace 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”); }
  • 40. 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 platformGood for higher level components, not for the core of a platform A
  • 41. A DODO Manage Dependencies..Manage Dependencies.. A
  • 42. Component is .. A Lego, Plug ??
  • 43. A .. a set of types that ship and evolve as a unit.
  • 44. API A Dependency Implement ation Circular
  • 45. APIDependencyAPIDependency 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
  • 46. ImplemenatinDependencyImplemenatinDependency If a type in A uses a type in B in its implementation. Hard Dependencies (required to run) Soft Dependencies (optional) A
  • 47. CircularDependencyCircularDependency Component A depends on component B and Component B depends on component A (even indirectly). A
  • 48. A
  • 49. Solution is Layering..Solution is Layering.. A
  • 50. xDepend (NxDepend (NDDepend)epend) NDepend - http://www.ndepend.com
  • 51. WPFWPF XMLXML A BCLBCL ReflectionReflection
  • 52. Createa newpackage.Createa newpackage. A
  • 53. GUIGUI CommComm AnalysisAnalysis ModemModem DDatabaseatabase circulardependencycirculardependency A ProtocolProtocol ModemModem ControlControl CommComm ErrorError DDatabaseatabase MessageMessage ManagerManager
  • 54. AA XX IndirectcirculardependencyIndirectcirculardependency AA BB XX YY A
  • 55. AA XX UseInterface.UseInterface. AA BB XX YY A <<interface>><<interface>> BYBY
  • 56. Heavy Depedency..Heavy Depedency.. A
  • 57. A
  • 58. Heavy Dependency.Heavy Dependency. // 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); … } A
  • 59. Inversionof ControlInversionof 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); } } A
  • 60. 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); … } A
  • 61. // 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 A
  • 62. PackagingPrinciplePackagingPrinciple Package Cohesion Principle REP (Release Reuse Equivalency) CCP (Common Closure Principle) CRP (Common Reuse Principle) Package Coupling PrinciplePackage Coupling Principle ADP (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
  • 63. DO balance advances with compatibility. A
  • 64. Types of “Compatibility”Types of “Compatibility” BackwardBackward A CrossCross--VersionVersion ForwardForward
  • 65. A CrossCross--RedistRedist..
  • 66. A
  • 67. Define what’s a “breaking change” This definition depends on the objective E.g. Enable portable code between Silverlight and . NET FrameworkNET Framework E.g. Enable cross-version portability? A
  • 68. AVOID duplication and overlap. A
  • 69. TeamTeam SpaceSpace Show and TellShow and Tell A PLoP – Capable, Productive and Satisfied Patterns for Productivity http://hillside.net/plop/plop98/final_submissions/P54.pdf ProblemProblem SpaceSpace
  • 70. 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? Support Automatic Migration Tool. (VB -> VB.NET, .NET 1.0 -> .NET 2.0) Provide Code Based Migration Manual. COM+ -> WCF , ASP.NET Web Service -> WCF A KC1
  • 71. 슬라이드 70 KC1 This slide needs major work Krzysztof Cwalina, 2007-10-19
  • 72. ThisiswherequalityhappensThisiswherequalityhappens D
  • 73. Is using your framework correctly like…Is using your framework correctly like… Running across a desert?Running across a desert? D
  • 74. D
  • 75. DO design APIs by first writing code samples for the main scenarios and then defining the object model to support the code samples. D
  • 76. Code SamplesCode Samples D
  • 77. 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
  • 78. static void Main(string[] args) { foreach (string s in File.ReadAllLines("MyFiles.text")) { Feedback (Read File)Feedback (Read File) { Console.WriteLine(s); } } D
  • 79. Object Model ListingObject Model Listing D
  • 80. Framework Design StudioFramework Design Studio Assembly ExploerAssembly Exploer Project -> Add -> Assembly Download here - http://code.msdn.microsoft.com/fds D
  • 81. Framework Design StudioFramework Design Studio Assembly ReviewCommentAssembly ReviewComment D
  • 82. Framework Design StudioFramework Design Studio CompareAPIVersionsCompareAPIVersions D
  • 83. Framework Design StudioFramework Design Studio CompareAPIVersionsCompareAPIVersions Red is removed, Green is added, Grey means inherited.Grey means inherited. D
  • 84. Framework Design StudioFramework Design Studio Exporting toMicrosoft WordExporting toMicrosoft Word Tools -> Export to Document D
  • 85. DO treat simplicity as a feature. D
  • 86. Remove Requirements (ATAM). Reuse Existing Concepts or APIs Adjust Abstraction Level Consider framework users(experience, knowledge) Three Example D
  • 87. DO measure, measure, and measure! D
  • 88. Specification Document: QualitiesSpecification Document: Qualities Performance Goals (XML Parser..) Baseline: What do is the best my API could do? Measure delta from the baseline Threat Models (Security ..) Threat: What is the worst that my component couldThreat: What is the worst that my component could do? Mitigate the threats Keep a balance between many other qualities you want your framework to have (ATAM) D
  • 89. THE POWER OF SAMENESS D
  • 90. 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?? D
  • 91. Oh, down to lock…Oh, down to lock… D
  • 92. How to use a key…How to use a key… D
  • 93. Oh, youOh, you pushpush the PRESS button…the PRESS button… D
  • 94. Who actuallyWho actually needsneeds this data?this data? D
  • 95. 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 carTherefore, you can drive your rental car That is… D
  • 96. http://blogs.msdn.com/fxcophttp://blogs.msdn.com/fxcop D
  • 97. Thebitscustomersget,…ornotThebitscustomersget,…ornot V
  • 98. Branches and IntegrationsBranches and Integrations --FeatureCrewFeatureCrew MainMain PU-stagingPU-staging PU-stagingPU-staging PU-stagingPU-staging V PU-staging Branch PU-staging Branch Feature Branch Feature Branch Feature Branch Feature Branch PU-staging Branch PU-staging Branch PU-staging Branch PU-staging Branch http://www.codeplex.com/BranchingGuidance/Wiki/View.aspx?title=Feature%20Crews%3a% 20How%20Microsoft%20Does%20It
  • 99. AVOID integrating unfinished features. V
  • 100. Functional Specification Developer Design Specification Test Plan Threat Model API review Architectural ReviewArchitectural Review Dependency Management Static Analysis Code Coverage Testing (Unit and Integration Tests) 0 Bugs Performance V
  • 101. DO pay your debt. V
  • 102. Planning M1 M2 Release Testing Feature completeVision statement RTM Technology Preview Beta 1 Beta 2 RC1 Milestone Quality V
  • 103. 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 subsystemsRefactoring of fragile subsystems Internal implementation documentation Bugs backlog V
  • 104. DO understand how organizational structure, culture, and decision making proc esses 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 dDO design APIs by first writing code samples for the main scenarios and then d efining 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.
  • 105. Krzysztof Cwalina, Brad AbramsKrzysztof Cwalina, Brad Abrams Framework Design Guidelines: Conventions, Idioms, and Patterns for Reusable .NET Libraries http://channel9.msdn.com/pdc2008/PC58/ http://www.gotdotnet.com/team/fxcop
  • 106. Douglas C. Schmidt (PLoP Editor, POSA 2, 4 Writter) JAWS: An Application Framework for High Performance Web System http://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 Frameworks http://st-www.cs.uiuc.edu/users/droberts/evolve.html (En) http://arload.wordpress.com/2008/09/15/evolvingframeworks/ (Kr)
  • 107. Robert C. Martin Principles of Package Architecture (Design Principles and Design Patterns) http://www.objectmentor.com/resources/articles/Principles_and_Pattern s.pdf (En) http://www.devpia.com/net2/EvaCast/Lecture/?cu=view&r=108 (Kr) For Korean People.. Load to Architect http://www.arload.net EvaCast (Online Free Lecture) http://www.evacast.net
  • 108. 이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다. This work is licensed under Creative Commons Korea Attribution 2.0 License.

×