C:\Fakepath\Combating Software Entropy 2


Published on

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • In this session we are going to talk about how to tackle inherently complex nature of a software. I am going to show you 'most important principles, tools and techniques you can use to 'combat software entropy'. Together, we will gain an insight in to the heart of the software design. We will talk about the heuristics associated with the software design and architectural patterns and practices. Intended audience of this session in-general includes all the stake holders in software development process i.e. from Developer to Architect to Project and Program Manager and even CTOs and CIOs. However I have focused specially on targeting Software and Solutions Architects, i.e. individuals or teams responsible for the overall design and architecture of the solution. So, if you consider yourself as a stake holder in Software development process then you have come to the right place. Before I proceed further I would like to request you that feel free to participate in the discussion. I am very keen to hear from you and answer your questions as we walkthrough the slides. However if we run out of time, which tends to happen a lot :), then I should be available at the community lounge to answer your questions.
  • Lets get rolling then, shall we?Heres an agenda:
  • Using the term software in its broadest possible sense.There are two broad categories that software development falls into. First and the foremost is the 'Writing new code' classification. - Use-Case 1: Writing new code In this scenario we are mandated to develop new systems, mostly from the scratch but usually using some existing pieces of code e.g. Class libraries, frameworks, services etc etc. In this scenario we have more freedom and control over design and we can implement patterns and practices the way we would like it to be. Generally speaking, we are trying to solve real world problems, like business automation, weather forecasting, algorithmic trading etc etc. There is an inherent disconnect between the real world and our software programming model and that very fact is at the heart of software complexity. - Use-Case 2: Now, how many time do we get to write new software? Lets do a show of hands here. I am guessing that most of the time we end up working on existing code bases, where we have to - find that tormenting bug and fix it. - add a new exciting feature - and if you are lucky or unlucky like me then review it and refactor it so that i can handle change in a better way This scenario is complex because. 1- We generally find it difficult to understand some one else’s code 2- We believe ‘we would have done it in a different/better way’ 3- 2 is true even if we ourselves were the author of that code few years back
  • As Architects how do we identify the good, the bad and the ugly of Software Design.For that perhaps we need some metrics such that we can always measure and identify which side of the fence our software belongs to.
  • How many times have you come across the code that you can qualify as a ‘bad design’? Or atlease and most commonly would have said, That’s not the way I would have done it.Before we move on. Lets agree on what's a bad design? Ok it’s a bit difficult to be exact about the metrics of bad design in software. But lets agree on some common aspects of bad design.Rigidity FragilityImmobilityCode that’s hard to change is bad… Rigid code is bad!Code that has lots of ripple effects.. A single change break lots of other code. Fragile code is bad!Code that cant be re-used… Code that cant be ‘extended’ is bad.. Immobile
  • Now that we know what the bad design is. Lets see how we can fix it? Would you be interested in identifying the principles and practices that will help you make sure that your design, architecture and code is not rigid, your solutions are not fragile and your frameworks are not immobile.Wouldn’t you like to have flexibility in your design, resiliency in your architecture and agility in your frameworks such that they can adapt to the ever changing business requirements.Lets drill down to each of these principles and see what can we do to fix our bad design.
  • If a class has more then one responsibility, then the responsibilities become coupled. Changes to one responsibility may impair or inhibit the class’ ability to meet the others. This kind of coupling leads to fragile designs that break in unexpected ways when changed.
  • What is responsibility? … It is a reason for change.We should consider each responsibility as an axis of change. The more axis of changes the more dimension effected.As a right hand rule, there should never be more than one reason for a class to change.The term separation of concerns was probably coined by Edsger W. Dijkstra in his 1974 paper "On the role of scientific thought"[1].Let me try to explain to you, what to my taste is characteristic for all intelligent thinking. It is, that one is willing to study in depth an aspect of one's subject matter in isolation for the sake of its own consistency, all the time knowing that one is occupying oneself only with one of the aspects. We know that a program must be correct and we can study it from that viewpoint only; we also know that it should be efficient and we can study its efficiency on another day, so to speak. In another mood we may ask ourselves whether, and if so: why, the program is desirable. But nothing is gained --on the contrary!-- by tackling these various aspects simultaneously. It is what I sometimes have called "the separation of concerns", which, even if not perfectly possible, is yet the only available technique for effective ordering of one's thoughts, that I know of. This is what I mean by "focusing one's attention upon some aspect": it does not mean ignoring the other aspects, it is just doing justice to the fact that from this aspect's point of view, the other is irrelevant. It is being one- and multiple-track minded simultaneously.
  • BusinessPartner
  • Example do demonstrate role based interfaces IVE examples
  • Mention ronald’s session here.
  • Classes should have a single responsibility or jobDevelopers should have that job in mind when they work on a classA developer should easily be able to write a block comment at the top of a class identifying its job.That comment should not have the word AND in it.As architects and leads we should be able to ask this question.. Whats the job of this class? a developer should always have this job in mind use intuitive and simple names remember! no conjunctions (ANDS)
  • Add an example
  • - “All systems change during their life cycles. This must beborne in mind when developing systems expected to last longer than the first version.” - SOFTWARE ENTITIES(CLASSES,MODULES,FUNCTIONS,ETC.) SHOULD BE OPEN FOR EXTENSION, BUT CLOSED FOR MODIFICATION- Bertrand Myers in 1988It says that you should design modules that never change . When requirements change, you extend the behaviour of such modules by adding new code, not by changing old code that already works.When a single change to a program results in a cascade of changes to dependent modules,that program exhibits the undesirable attributes that we have come to associate with “bad”design. The program becomes fragile, rigid, unpredictable and unreusable. The openclosedprinciple attacks this in a very straightforward way. It says that you should designmodules that never change. When requirements change, you extend the behavior of suchmodules by adding new code, not by changing old code that already works.The modules that follow OCP have the following two characteristics:=-1. They are “Open For Extension”.This means that the behaviour of the module can be extended. That we can make the module behave in new and different ways as the requirements of the application change, or to meet the needs of new applications.2. They are “Closed for Modification”.The source code of such a module is inviolate. No one is allowed to make source code changes to it.
  • Composabilityvsinheritence
  • Define degenrate methodsShow an example here.
  • *Uml compatible.
  • - Inversion of control is the basic feature of any framework in a way that frameworks are differentiated from libraries by offering the support for ‘Hollywood Principal’ (‘Don’t call us , we will call you’)- One important characteristic of a framework is that the methods defined by the user to tailor the framework will often be called from within the framework itself, rather than from the user's application code. The framework often plays the role of the main program in coordinating and sequencing application activity. This inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application.--Ralph Johnson and Brian Foote
  • Afferent Couplings (Ca): The number of other packages that depend upon classes within the package is an indicator of the package's responsibility. -------------Show how visual studio does it.
  • Efferent Couplings (Ce): The number of other packages that the classes in the package depend upon is an indicator of the package's independence.
  • Instability (I): The ratio of efferent coupling (Ce) to total coupling (Ce + Ca) such that I = Ce / (Ce + Ca). This metric is an indicator of the package's resilience to change. The range for this metric is 0 to 1, with I=0 indicating a completely stable package and I=1 indicating a completely instable package.
  • MI: http://blogs.msdn.com/fxcop/archive/2007/11/20/maintainability-index-range-and-meaning.aspx 0-100 range.20-100 is green.The maintainability index has been re-set to lie between 0 and 100.  How and why was this done?The metric originally was calculated as follows (based on the work in Carnegie Mellon University although we modified the Halstead Volume calculation a little since we don't include comments anywhere in our calculation): Maintainability Index = 171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code)This meant that it ranged from 171 to an unbounded negative number.  We noticed that as code tended toward 0 it was clearly hard to maintain code and the difference between code at 0 and some negative value was not useful.   I'll post some tech ed sample code showing very low maintainability or you can try on your own code to verify.  As a result of the decreasing usefulness of the negative numbers and a desire to keep the metric as clear as possible we decided to treat all 0 or less indexes as 0 and then re-base the 171 or less range to be from 0 to 100. Thus, the formula we use is:Maintainability Index = MAX(0,(171 - 5.2 * ln(Halstead Volume) - 0.23 * (Cyclomatic Complexity) - 16.2 * ln(Lines of Code))*100 / 171)On top of that we decided to be conservative with the thresholds.  The desire was that if the index showed red then we would be saying with a high degree of confidence that there was an issue with the code.  This gave us the following thresholds (as mentioned in this blog previously):For the thresholds we decided to break down this 0-100 range 80-20 so that we kept the noise level low and only flagged code that was really suspicious. We have:0-9 = Red 10-19 = Yellow 20-100 = Green-----------------------------------------------------------------------------------------------------------------------------------------------CC: http://en.wikipedia.org/wiki/Cyclomatic_complexityCyclomatic complexity is computed using the control flow graph of the program: the nodes of the graph correspond to indivisible groups of commands of a program, and a directed edge connects two nodes if the second command might be executed immediately after the first command. Cyclomatic complexity may also be applied to individual functions, modules, methods or classes within a program.Limiting complexity during developmentOne of McCabe's original applications was to limit the complexity of routines during program development; he recommended that programmers should count the complexity of the modules they are developing, and split them into smaller modules whenever the cyclomatic complexity of the module exceeded 10.[2] This practice was adopted by the NIST Structured Testing methodology, with an observation that since McCabe's original publication, the figure of 10 had received substantial corroborating evidence, but that in some circumstances it may be appropriate to relax the restriction and permit modules with a complexity as high as 15. As the methodology acknowledged that there were occasional reasons for going beyond the agreed-upon limit, it phrased its recommendation as: "For each module, either limit cyclomatic complexity to [the agreed-upon limit] or provide a written explanation of why the limit was exceeded."[5]
  • Since closure cannot be complete, it must be strategic. That is, the designer must choose the kinds of changes against which to close his design. This takes a certain amount of prescience derived from experience. The experienced designer knows the users and the industry well enough to judge the probability of different kinds of changes. He then makes sure that the open-closed principle is invoked for the most probable changes.So in a way its not just the language and the compiler and the ide itself. But the effort on the part of the designer to think and re think about these aspects and then do/refactor the design
  • We believe we have given you an insight into the heart of the software complexity and stability in the face of change.Now, not only you can judge your design using these principals.you can measure them quality of your design using software design metrics. What are those metrics and how do they work is beyond the scope of this discussion but definitely worth looking at.Code metrics:Maintainability IndexCyclomatic Complexity Depth of InheritenceClass Coupling http://msdn.microsoft.com/en-us/library/bb385914(VS.100).aspx VS has it,
  • C:\Fakepath\Combating Software Entropy 2

    1. 1.
    2. 2. ARC202 - Combating Software Entropy with Design Patterns and Principles<br />Hammad Rajjoub<br />Solutions Architect @ Infusion<br />Microsoft MVP<br />
    3. 3. Cogito, Ergo , Sum<br />Microsoft MVP – Connected Systems (5+ yrs)<br />Solutions Architect at Infusion<br />The coolest company in town<br />Develop. Design. Venture.  Join us!<br />Speaker, Author & Community Leader<br />I do: Blog + Twitter + PodCast<br />Bing me http://www.bing.com/search?q=hammadrajjoub<br />
    4. 4. Agenda<br /> Why is Software Complex?<br /> What is bad design?<br /> How to Fix it?<br /> Summary<br /> References<br />QnA<br />
    5. 5. Why is Software Complex<br />Writing new software<br />Mandated to develop new systems<br />Generally from scratch <br />But still mostly relying on existing libraries and frameworks<br />Real-world problems are sometimes complex<br />Modifying Existing Software<br />Find that ‘bug’ and ‘fix’ it<br />Add a new exciting feature<br />Review and refactor to a better design<br />
    6. 6. What is bad design?<br />
    7. 7. Bad design is...<br />Hard to change!<br />A single change break lots of other code<br />Rigid<br />Fragile<br />Can’t be ‘extended’ <br />Immobile<br />
    8. 8. How to fix it?<br />Using design principles and practices<br />The Single Responsibility Principle<br />The Open Closed Principle<br />Liskov Substitution Principle<br />Dependency Inversion Principle<br />Using Software Design Metrics<br />And yes a whole lot of refactoring <br />
    9. 9. Single Responsibility Principle<br />None but Buddha himself must take the responsibility of giving out occult secrets...<br />E. Cobham Brewer 1810–1897.<br />Dictionary of Phrase and Fable. 1898.<br />SRP<br />
    10. 10. The Single responsibility principal<br />"A responsibility is a reason to change, a class or module should have one, and only one, reason to change."<br />
    11. 11. The Single Responsibility Principal<br />Responsibility is a ‘Reason for change’<br />Each responsibility is an axis of change<br />There should never be more than one reason for a class to change<br />Dijkstra’s SoC: Separation of Concerns<br />This helps us evaluate a class ‘s<br /> exposure to change<br />
    12. 12. BusinessPartnerValidtor Module<br />Example:<br />
    13. 13. BusinessPartnerValidator<br />BusinessPartner<br />Validator<br />DB<br />Trade<br />What is wrong here: Changes if DB changes or Business Logic Changes<br />
    14. 14. Counterparty Validator – Iter 1<br />internal class BusinessPartnerValidator<br />{<br />public void AssertValid(Trade t)<br /> {<br />varsql = "SELECT COUNT(*) FROM BusinessPartner WHERE name=@Name";<br />using (varconn = CreateOpenConnection())<br /> {<br />varcmd = new SqlCommand(sql, conn);<br />cmd.Parameters.Add("@Name", SqlDbType.VarChar);<br />cmd.Parameters["@name"].Value = t.BusinessPartnerName;<br />var count = (Int32) cmd.ExecuteScalar();<br />if (count != 1) throw new InvalidBusinessPartyException(t.BusinessPartyName);<br /> }<br /> }<br />...<br />Where is the business logic? <br />Hidden by database code.<br />
    15. 15. BusinessPartyValidator – Iter 2<br /> internal class BusinessPartnerValidator<br /> {<br />private readonlyBusinessPartnerValidatorbusinessPartnersource;<br />public BusinessPartyValidator(BusinessPartnerSourceBusinessPartySource)<br /> {<br />this.businessPartnerSource = BusinessPartnerSource;<br /> }<br /> public void AssertValid(Trade t)<br /> {<br />if (BusinessPartnerSource.FindByName(t.BusinessPartnerSource) == null) <br /> throw new InvalidBusinessPartnerException(t.BusinessPartnerName);<br /> }<br /> }<br />BusinessPartyValidator now has a single responsibility<br />
    16. 16. RefactoredBusinessPartnerValidator<br />BusinessPartner<br />Validator<br />BusinessPartner<br />Source<br />Trade<br />DB<br />What's its job?<br />Classes must have an identifiable single responsibility. <br />
    17. 17. Open Closed Principle<br />“..this is the heart of Object Oriented Programming...”<br />OCP<br />
    18. 18. The Open Closed Principle<br />Realise that generally systems outlive their expected timelines<br />All software entities should be closed for change and opened for extension<br />Your design modules should never change<br />You should just extend the behaviour<br />
    19. 19. Liskov Substitution Principle<br />There is a theory which states that if ever anybody discovers exactly what the Universe is for and why it is here, it will instantly disappear and be replaced by something even more bizarre and inexplicable. There is another theory which states that this has already happened. <br />Douglas Adams (1952 - 2001)<br />
    20. 20. The Liskov substitution principal<br />“Functions that reference a base class must be able to use objects of derived classes without knowing it."<br />
    21. 21. Using Inheritance for OCP?<br />RateCalculator<br />Trade<br />Option<br />Fee<br />
    22. 22. Trade Rate Calculation<br />public decimal CalulateRate(Trade t)<br />{<br />if (t is Fee)<br /> {<br />return 1.0m;<br /> }<br /> return t.BaseAmount/t.QuotedAmount;<br />}<br /><ul><li>Use of convention rather than design
    23. 23. Fragile: sensitive to any change in Trade Fee Hierarchy</li></li></ul><li>Better Trade Rate Calculation<br /> public abstract class Trade<br /> {<br />...<br /> public abstract decimal Rate { get; }<br /> }<br /> public class Fee : Trade<br /> {<br />...<br />public override decimal Rate<br /> {<br /> get { return 1.0m; }<br /> }<br /> }<br /><ul><li> Open for extension
    24. 24. Design forces implementation</li></li></ul><li>The Liskov substitution principal<br />Be vary of ‘is-a’ relationship<br />LSP is prime enabler of OCP<br />Important Pointers for LSP compliance:<br />Hollow methods (Degenerate Functions)<br />Sub type = substitutable<br />
    25. 25. Dependency Inversion<br />It may be that the old astrologers had the truth exactly reversed, when they believed that the stars controlled the destinies of men. The time may come when men control the destinies of stars. Arthur C. Clarke (1917 - ), First on the Moon, 1970 <br />
    26. 26. Dependency Inversion Principal<br /><ul><li>High level modules should not depend upon low level modules. Both should depend upon abstractions.
    27. 27. Abstractions should not depend upon details. Details should depend upon abstractions.</li></li></ul><li>BusinessParty Validator<br />Introduce stability with abstraction<br />High Level (Less Stable)<br />BusinessParty<br />Source<br />BusinessParty<br />Validator<br />Trade<br />DB<br />Low Level<br />(More Stable)<br />
    28. 28. Better BusinessPartner Validator<br /><Interface><br />IBusinessPartnerSource<br />BusinessPartnerValidator<br />BusinessPartySource<br />Trade<br />DB<br />
    29. 29. Extensible BusinessParty Validator<br /><Interface><br />IBusinessPartnerSource<br />BusinessPartyValidator<br />Trade<br />WSBusinessPartnerSource<br />DbBusinessPartySource<br />DB<br />Cloud<br />
    30. 30. DI & IoC<br />IoC is key part of Frameworks<br />Interfaces, Closures & Events<br />Hollywood Principal (Don’t call us, We will call you)<br />IoC is a very general name and hence the Dependency Injection*<br />Suits Test Driven Development<br />Number of dependencies indicate stability<br />*http://martinfowler.com/articles/injection.htm l<br />
    31. 31. Software Design Metrics<br />
    32. 32. Some Key Design Metrics - Ca<br />Afferent Couplings - Ca<br />The number of other packages that depend upon classes within the package is an indicator of the package's responsibility.<br />BPackage<br />APackage<br />Package<br />Class<br />
    33. 33. Some Key Design Metrics<br />Efferent Couplings – Ce<br />The number of other packages that the classes in the package depend upon is an indicator of the package's independence. <br />BPackage<br />APackage<br />Package<br />Class<br />
    34. 34. Some Key Design Metrics<br />Instability – I = Ce / (Ce + Ca)<br />This metric is an indicator of the package's resilience to change. <br />The range for this metric is 0 to 1, <br />0 indicating a completely stable package<br />1 indicating a completely instable package. <br />
    35. 35. Use Visual Studio Code Metrics<br />Maintainability Index<br />Cyclomatic Complexity<br />Depth of Inheritance<br />Class Coupling<br />Lines of Code<br />Code Coverage<br />
    36. 36. Further reading<br />
    37. 37. What else can I do?<br />ISP: Interface Segregation Principle  Avoid fat interfaces<br />REP: The Release Reuse Equivalency Principle  The granule of reuse is the granule of release. <br />CCP: The Common Closure Principle  Classes that change together are packaged together.<br />CRP: The Common Reuse Principle  Classes that are used together are packaged together.<br />SDP: The Stable Dependencies Principle  Depend in the direction of stability. <br />
    38. 38. Strategic Closure<br />No significant program can be 100% closed<br />Closures cant be complete<br />Closures must be ‘Strategic’<br />Stability metrics can indicate hotpots<br />Designer must choose the changes against which her design should be closed<br />
    39. 39. Summary<br />Remember your application will outlive your expectation<br />Follow these design principles<br />Be Agile!<br />Refactor ++<br />Use Code Metrics<br />
    40. 40. References<br />Uncle Bob http://butunclebob.com/ArticleS.UncleBob.PrinciplesOfOod<br />Agile Principles, Patterns and Practices in C#<br />Martin Fowler’s Blog:<br />http://martinfowler.com/bliki/<br />
    41. 41. question & answer<br />
    42. 42. Required Slide<br />Speakers, <br />TechEd 2010 is not producing <br />a DVD. Please announce that <br />attendees can access session <br />recordings at TechEd Online. <br />www.microsoft.com/teched<br />Sessions On-Demand & Community<br />www.microsoft.com/learning<br />Microsoft Certification & Training Resources<br />http://microsoft.com/technet<br />Resources for IT Professionals<br />http://microsoft.com/msdn<br />Resources for Developers<br />Resources<br />
    43. 43. Required Slide<br />Complete an evaluation on CommNet and enter to win an HTC HD2!<br />
    44. 44. Required Slide<br />© 2010 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.<br />The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.<br />