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
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
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)
Code QualitiesEncapsulation Type Encapsulation Polymorphism class Encapsulation «interface» Cli ent IProduct ProductA Prod uctB
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
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
Code QualitiesCoupling Strong/tight coupling class Coupling Cli ent Conc rete Loose coupling class Coupling «interface» Cli ent Abstraction Concr eate
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
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.
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.
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.
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
Design PrinciplesDIP.cmp DIP IRepository IGateway Contr oller Serv ice Gatew ay Repository IGateway IRepository IService IService FakeGatew ay IGateway
cmp DIPDIP Contr oller Presentation IService. Servi ce Serv ice IRepository IServi ce IGateway Resource Access IGateway IRepository Gatew ay Repository
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
Automotive Industry . class IoC Component1Prov iderA Component1 Component1 Prov iderB Ca r Component2Prov iderA Component2 Component2 Prov iderB IoC Configuration
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.
Resources Wrox - Professional ASP.NET Design Patterns @2010 Wikipedia http://lostechies.com/derickbailey/2009/02/11/solid
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
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
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
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
Design PatternsBridge Case Study Creat a system that send notifications :email, sms Use different providers that offer services to send sms, emails
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()
Resources Design Patterns Explained A New Perspective on Object-Oriented Design, 2nd Edition @2004 http://www.oodesign.com http://www.cours.polymtl.ca/inf3700/divers/n
Enterprise Patterns Introduced by Martin Fowler in the book « Patterns of Enterprise Application Architecture” @November 2002
Enterprise Patterns Layers / SoC Horizontal Separation deployment SoC Presentation Layer Busines s Layer Resource Ac cess Layer
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.
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
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
Enterprise PatternsResource Access Layer Repository retrieve and persist your business entities typically includes CRUD methods Query Object an object that represent a database query
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.
Enterprise Patterns Domain Layer Introduced by Eric Evans, in his book “Domain Driven Design – Tackling Complexity in the Heart of Software” @2003
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
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
.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
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
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
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
Resources Wrox - Professional ASP.NET Design Patterns @September, 2010 Patterns of Enterprise Application Architecture @November 2002 Wikipedia