Software Design Fundamentals


Published on

An overview of software qualities, principles, patterns, practices.
Building a maintainable, scalable and testable application architecture.

Published in: Technology, Education
  • Be the first to comment

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

No notes for slide

Software Design Fundamentals

  1. 1. Software Design Fundamentals Cristi Salcescu @2012 V5.1
  2. 2. QuestionHow to create software that is ? Easy to read and understand Easy to change Easy to test
  3. 3. UML Unified Modeling Language The most basic of UML diagrams is the Class Diagram. It describes classes and shows the relationships among them.
  4. 4. UMLUML Notation for Relationships Inheritance class Relations A generalizes B A B derives from A Class A {} B Class B : A {}
  5. 5. UMLUML Notation for Relationships Association class Relations A uses B A B Class field Methode parameter Methode Return Type class A Local variable { void Methode1() { B var1 = new B(); … } }
  6. 6. UMLUML Notation for Relationships Aggregation class Relations Shared Association A B A aggregates B B is part of A class RelationsClass B {}Class A Airport Aircraft{B FieldB;}
  7. 7. UMLUML Notation for Relationships Composition class Relations Not-Shared Association A B A is composed of BClass B {} class RelationsClass A Person Leg{B FieldB;}
  8. 8. Resource
  9. 9. Content System-Quality Attributes Code Qualities Design Principles Design Patterns Enterprise Patterns
  10. 10. System-Quality Attributes Maintainability Flexibility Reusability Readability Testability
  11. 11. System-Quality Attributes Maintainability  A measure of how easy it is to modify the software to correct faults, improve performance or other attributes. Flexibility  A measure of how easy it is to change software in response to different requirements
  12. 12. System-Quality Attributes Reusability  the capability for components and subsystems to be uses in other applications and in other scenarios  Readability  A measure of how easy it is to read and understand code.  Testability  A measure of how easy it is to create test criteria
  13. 13. Resources
  14. 14. Code Qualities  Encapsulation  Cohesion  No Redundancy  Coupling
  15. 15. Code Qualities Encapsulation  Information hiding  Means any kind of hiding  Encapsulation of data  Encapsulation of methods  Encapsulation of type (behind an abstract class or interface)
  16. 16. Code QualitiesEncapsulation  Type Encapsulation  Polymorphism class Encapsulation «interface» Cli ent IProduct ProductA Prod uctB
  17. 17. Code Qualities Cohesion  Cohesion refers to how much (or how little) the internal parts of something are working on the same issue  No Redundancy  Anything that could change should be in a single place in the system
  18. 18. Code Qualities  Coupling  Coupling refers to the degree of direct knowledge that one class has of another.  Strong coupling occurs when a dependent class contains a pointer directly to a concrete class  Loose coupling occurs when the dependent class contains a pointer only to an interface that the concrete class implements
  19. 19. Code QualitiesCoupling Strong/tight coupling class Coupling Cli ent Conc rete Loose coupling class Coupling «interface» Cli ent Abstraction Concr eate
  20. 20. Code QualitiesCoupling Strong/tight coupling
  21. 21. Code QualitiesCoupling Loose coupling
  22. 22. Code QualitiesCoupling Strong coupling - Keyboard - Sound
  23. 23. Code QualitiesCoupling Loose coupling - Keyboard - Sound
  24. 24. Resources Addison Wesley - Emergent Design @2008, Chapter 7 Wikipedia
  25. 25. Design Principles SOLID Design Principles were introduced by Robert Martin in the book “Agile Principles, Patterns, and Practices in C#” @2002 Code becomes more flexible and adaptable to change, as well as more maintainable
  26. 26. Design Principles SOLID Principles  Single Responsibility Principle  Open-Closed Principle  Liskov Substitution Principle  Interface Segregation Principle  Dependency Inversion Principle Other Principles  Don’t Repeat Yourself (DRY)  Separation of Concerns (SoC)
  27. 27. Design Principles Single Responsibility Principle  The principle states that every object should only have one reason to change and a single focus of responsibility
  28. 28. Design Principles Open-Closed Principle  Open for extension, but closed for modification  Extend softwares capabilities without changing it
  29. 29. Design PrinciplesOPC. class OPC «interface» Cli ent IProduct ProductA ProductB ProductC
  30. 30. Design PrinciplesOCP.
  31. 31. Design Principles Liskov Substitution Principle  The principle dictates that you should be able to use any derived class in place of a parent class and have it behave in the same manner without modification.
  32. 32. Design PrinciplesLSP.
  33. 33. Design PrinciplesLSP.
  34. 34. Design Principles Interface Segregation Principle  States that clients should not be forced to depend on interfaces they don’t use.  Is all about separating fat interfaces into small, specific groups of related functionality.
  35. 35. Design PrinciplesDIP Dependency Inversion Principle (DIP)  High-level modules should not depend on low-level modules. Both should depend on abstractions.  Abstractions should not depend upon details. Details should depend upon abstractions.  => DIP Is about isolating your classes from concrete implementations and having them depend on abstract classes or interfaces.
  36. 36. Design PrinciplesDIP.cmp DIP Serv ice IRepository IService IGateway
  37. 37. Design PrinciplesDI Dependency Injection (DI) is a technique that is used to allow calling code to inject the dependencies the class needs when is instantiated  3 Primary techniques : constructor injection, method injection, property injection
  38. 38. Design PrinciplesDIP.
  39. 39. Design PrinciplesDIP.
  40. 40. Design PrinciplesDIP.cmp DIP IRepository IGateway Contr oller Serv ice Gatew ay Repository IGateway IRepository IService IService FakeGatew ay IGateway
  41. 41. cmp DIPDIP Contr oller Presentation IService. Servi ce Serv ice IRepository IServi ce IGateway Resource Access IGateway IRepository Gatew ay Repository
  42. 42. Design PrinciplesIoC Inversion of Control Container (IoC)  an implementation of DIP and DI  responsible for object graph instantiation  initiated at application startup via code or configuration  an "assembler” that makes object coupling a run-time
  43. 43. Automotive Industry . class IoC Component1Prov iderA Component1 Component1 Prov iderB Ca r Component2Prov iderA Component2 Component2 Prov iderB IoC Configuration
  44. 44. Design PrinciplesIoC.
  45. 45. Design PrinciplesIoC.
  46. 46. Design PrinciplesIoC .class MVC Repository Controller Serv ice IRepository IGateway «flow» IService IService Us er IRepository Gateway IGateway
  47. 47. Design PrinciplesTesting Testing in isolation using Mock objectsclass Coupling class Coupling «interface» «interface» IDependecyA IDependencyA MockDependecyA ConcreteDependecyA «interface» «interface» IDependecyB Module IDependencyB MockDependecyB Module ConcreteDependecyB «interface» «interface» IDependecyC ConcreteDependecyC IDependencyC MockDependecyC
  48. 48. Design Principles Don’t Repeat Yourself (DRY)  Variation: "One rule, one place”  Have only one place where a rule is implemented. Separation of Concerns (SoC)  Is the process of divide your application into distinct features.  Modularity A software can be divided into separate elements called modules and that are integrated to solve the problem.
  49. 49. Resources Wrox - Professional ASP.NET Design Patterns @2010 Wikipedia
  50. 50. Design Patterns Introduced by The Gang of Four in the book “Design Patterns: Elements of Reusable Object-Oriented Software” @1994 Reusable solution to a commonly occurring problem
  51. 51. Design Patterns Strategy Adapter Bridge Factory
  52. 52. Design Patterns GOF Design Principles Design to interfaces Favor aggregation over inheritance Find what varies and encapsulate it (behind an abstract class or interface) Separate use from construction
  53. 53. Design Patterns Strategy define a family of algorithms lets the algorithm vary independently from clients that use it Case Study Compute primes for different insurer companies
  54. 54. Design PatternsStrategy .class Strategy class Strategy InusurerAGatew ay InsurerAGatew ay + +ComputePrim e()e() : void ComputePrim : void Serv ice Serv ice Serv ice InsurerGateway InsurerGateway + + ComputePrim e() : void ComputePrimComputePrime() : :void ++ ComputePrim e() void e() : void gateway.ComputePrime() InsurerBGatew ay InsurerBGatew ay + ComputePrim e() : void + ComputePrim e() : void
  55. 55. Design PatternsStrategy . class Strategy  «interface» Context IStrategy Concre teStra tegy1 ConcreteS trategy2
  56. 56. Design PatternsStrategy Case Study  interchange between 3rd party logging libraries
  57. 57. Design PatternsStrategy . class Strategy class Strategy Serv ice class Strategy + MethodeA() : void Serv ice Serv ice ILogger Ilogger log() + Log() : void + MethodeA() : void + Log() : void logger.Log() Log4NetLogger EnterpriseLi braryLogger + Log() : void + Log() : void Log4NetLogger EnterpriseLi braryLogger + Log() : void + Log() : void
  58. 58. Design Patterns Adapter converts the interface of a class into another interface that the clients expect
  59. 59. Design PatternsAdapter Case Study  Develop a system that communicates with an external device  Integrate a 3rd party object that communicates with the device at the end of the project
  60. 60. Design Patterns . class Adapter class Adapter Cli ent IGateway Cli ent IGateway + GetMeasure() : double + GetMeasure () : void FakeGatew ay RealGatew ayAdapter + GetMeasure() : double + GetMeasure() : double FakeGatew ay 3rdPartyObject.MeasureMethode() RealGatew ay + GetMeasure () : void + GetMeasure () : void 3rdPartyObj ect + MeasureMetho de() : void
  61. 61. Design PatternsAdapter . class Adapter «interface» Cli ent ITarget + methodA() : void Adapter Adaptee + methodA() : void + methodB() : void
  62. 62. Design PatternsAdapter Adapt a 3 party library interface to an existing interface used in the project
  63. 63. Design PatternsAdapter . class Adapter class Adapter Cli ent Cli ent ILogger ILogger + + log() : void Log() : void Log4NetAdapter EnterpriseLi braryAdapter + Log4NetLogger log() : void + log() : void EnterpriseLi braryLogger + Log() : void + Log() : void Log4NetLogger EnterpriseLi braryLogger + logMethodA () : void + logMethodB () : void
  64. 64. Design PatternsAdapter .
  65. 65. Design Patterns Bridge Separate an abstraction from its implementation so that the two can vary independently Separate a varying entity from a varying behavior so that the two can vary independently
  66. 66. Design PatternsBridge Case Study  Creat a system that send notifications :email, sms  Use different providers that offer services to send sms, emails
  67. 67. Design PatternsBridge. class Bridge class Bridge class Bridge class Bridge Notifi cation Serv iceAgentA Serv iceAgentA Notification + +SendEmail () : : void SendEmail () void + Send() : void Notification IServiceAgent + +SendSms() : :void SendSms() void IServ ic eAgent +Notifi cation void Send() : + SendEmail () : void + SendSms() : void + Send() : void + SendEmail () : void Serv ice AgentB Email Sms + SendSms() : void + SendEmail () : void + Serv ice AgentB SendSms() : void Em ai l Sm s + SendEmail () : void + Send()l : void Em ai + Sm s Send() : void + SendSms() : void Emai l EmailAgentA : void EmailAgentB + Send() Sms SmsAgentA + Send() : void SmsAgentB + Send() : void + Send() : void serviceAgent.SendEmail() serviceAgent.SendSms()
  68. 68. Design PatternsBridge. class Bridge «interface» Abstraction Implementor ConcreteAbstraction ConcreteIm plementor
  69. 69. Design Patterns Factory hides the complexities of creating objects
  70. 70. Design PatternsFactory class Factory «interface» Cli ent IProduct Factory Concrete Product + createProduct() : IProduct
  71. 71. Design PatternsFactory . class Factory «interface» Cli ent IProduct Factory Concrete ProductB ConcreteProductA + createProduct(char) : IProduct reflection parameters(xml, database, flat file)
  72. 72. Resources Design Patterns Explained A New Perspective on Object-Oriented Design, 2nd Edition @2004
  73. 73. Enterprise Patterns Introduced by Martin Fowler in the book « Patterns of Enterprise Application Architecture” @November 2002
  74. 74. Enterprise Patterns Layers / SoC Horizontal Separation deployment SoC Presentation Layer Busines s Layer Resource Ac cess Layer
  75. 75. Enterprise Patterns  Presentation Layer  MVP (Model View Presenter)  Model : holds the data to show on the View  View : displays the model data obtained via the presenter and delegates user input to the presenter.  Presenter : coordinates the updates between View and Model  MVC (Model View Controller)  Model : holds the data to show on the View  View : displays the model data supplied from the controller.  Controller : It is the initial contact for a request handling It interacts with the model based on the request and selects the appropriate view to render.
  76. 76. Enterprise Patterns  Service Layer  Services  the service layer simply coordinates the business use case transaction and delegates work to the business objects for all the lower-level implementation details
  77. 77. Enterprise PatternsService Layer Messaging Patters  The Document Message  simplifies the communication by encapsulating all information within an object (DTO)  The Request-Response  ensures that responses as well as requests use the Document Message pattern  Data Tranfer Objects (DTOs)  An object used to transfer data between subsystems
  78. 78. Enterprise PatternsResource Access Layer  Repository  retrieve and persist your business entities  typically includes CRUD methods  Query Object  an object that represent a database query
  79. 79. Enterprise PatternsResource Access Layer  Gateway  An object that encapsulates access to an external system or resource.  Service Agent  a component acting as the front-end of communications towards Web Services. It should be solely responsible for actions of direct consumption of Web Services.
  80. 80. Enterprise Patterns Domain Layer  Introduced by Eric Evans, in his book “Domain Driven Design – Tackling Complexity in the Heart of Software” @2003
  81. 81. Enterprise PatternsModels pkg Models Doma in M odel Enti ties ValueObj ects «flow» «flow» Relati onal Model Dimens ional Model Fac ts Tables «flow» Dimensions
  82. 82. Enterprise PatternsDomain Layer  Entities  An object that is not defined by its attributes, but rather by its identity  Value Objects  An object that contains attributes but has no conceptual identity
  83. 83. .Invoices Id IdContract Contracts Id Number Clients Id Name ContractDescription Description IdIndustry IdStatus IdClient IdType Number IdGenericContract IdGroup IssueDate IdRefContract CorporateFunds IdType Address1 PaymentDue Address2 IdCurrency ZipCode ExchangeRate City IdPlaceOfSupply IdCountry SubscriberName Phone SubscriberPhone Fax aspnet_Users ApplicationId UserId UserName LoweredUserName MobileAlias IsAnonymous LastActivityDate
  84. 84. . .
  85. 85. Enterprise PatternsDomain Layer  Aggregate  groups logical entities and value objects  Aggregate Root  an entity, which is the only member of the aggregate that any object outside the aggregate is allowed to hold a reference to
  86. 86. Domain Layer class DDD. A1 A2 A3 E1 B5 E2 B1 E3 B4 E4 B2 B3
  87. 87. DDD N-Layered Architecture - Use Case : User Authenticationpkg DDD N Layered - Use writes credentials and Presentation Layer submits the request - Controller receives the request View s and delegates the responsibility to Controllers /Presenters Service - Service coordinates the use case - Step1 : delegate AD Service Layer authentication to Repository - Step 2: delegate logging to Serv ices Repository - Service returns that the Use case was completed successfully - The Controller gets the response Business/Domain Layer and decides what view to display Enti ties - The User see the View Resource Access Layer Reposi tories Gate w ays
  88. 88. Use Case : User Authentication .sd Class Model 1: authenticate() 1.2: authenticate() 1.3: authenticateAD() Controller Serv ice Gateway Actor3 «flow» 1.1: create() 1.4: log() View Repository
  89. 89. Resources Wrox - Professional ASP.NET Design Patterns @September, 2010 Patterns of Enterprise Application Architecture @November 2002 Wikipedia