Aula 04 - Princípios de Projeto

Download Aula 04 - Princípios de Projeto

Post on 22-Dec-2015

229 views

Category:

Documents

14 download

Embed Size (px)

DESCRIPTION

Princpios de Projeto

TRANSCRIPT

<ul><li><p>Princpios de Projeto Aula 04 </p><p>Prof. Kleinner Farias Programa Interdisciplinar de Ps-Graduao </p><p>em Computao Aplicada PIPCA Universidade do Vale do Rio dos Sinos </p><p>4 </p><p>3/26/14 @KleinnerFarias 1 </p></li><li><p>Agenda </p><p> Sintomas de degradao arquitetural Princpios de projeto Exemplos de aplicao dos princpios </p><p>2 </p></li><li><p>Sintomas de Degradao Arquitetural </p><p> Rigidez Fragilidade Imobilidade Viscosidade </p><p>3 </p></li><li><p>Sintomas de Rigidez </p><p>Rigidez </p><p>Rigidity is the tendency for soMware to be dicult to change, even in simple </p><p>ways. (Robert MarUn) </p><p>4 </p></li><li><p>Sintomas de Rigidez </p><p> Mudanas nos requisitos causam uma cascata de subsequentes mudanas entre mdulos dependentes do sistema </p><p>Efeito Domin Efeito na Equipe 5 </p></li><li><p>Sintomas de Rigidez </p><p> Tudo comea com um dia de trabalho que se transforma em 2, 3, n....semanas de mudanas tentando encontrar por onde comear </p><p> Consequncia: Alto risco de realizar mudanas Medo de resolver problemas crUcos Gestor sente receio de autorizar modicaes Imprevisibilidade do m da aUvidade de mudana </p><p>6 </p></li><li><p>Sintomas de Fragilidade </p><p>Fragilidade </p><p>Fragility is the tendency of the soMware to break in many places every Ume it is changed. (Robert MarUn) </p><p>7 </p></li><li><p>Sintomas de Fragilidade </p><p> Mudana em um Mdulo A do sistema provoca mudanas indesejadas em um Mdulo B sem qualquer relao conceitual </p><p> Quanto mais resolvo problema, mais problemas surgem </p><p> Consequncias: As mudanas so imprevisveis, no possvel mensurar o impacto/consequncia de mudanas </p><p>Torna-se dihcil esUmar os custos e as entregas 8 </p></li><li><p>Sintomas de Imobilidade </p><p>Imobilidade </p><p>Immobility is the inability to reuse soMware from other projects or from parts of the same project. (Robert MarUn) </p><p>9 </p></li><li><p>Sintomas de Imobilidade </p><p> Um mdulo que foi projetado para ser reusado torna-se altamente acoplado </p><p> Framework criado na empresa que deixa de ser framework devido ao alto grau de dependncia </p><p> Consequncias: Baixo grau de reuso de soMware Menor produUvidade do Ume de desenvolvimento Maior custo de desenvolvimento </p><p>10 </p></li><li><p>Sintomas de Viscosidade </p><p>Viscosidade When faced with a change, engineers usually nd more than one way to make the change. Some of the ways </p><p>preserve the design, others do not. (Robert MarUn) </p><p>11 </p></li><li><p>Sintomas de Viscosidade </p><p> mais fcil usar arUhcios de programao (vulgo gambiarra) que implementar da forma correta Quando vericamos isso? </p><p> Fazendo engenharia reversa Analisando o cdigo </p><p> Consequncias: Arquitetura em desacordo com o cdigo Refactoring.... </p><p>12 </p></li><li><p>O que provoca a degradao arquitetural? </p><p>13 </p></li><li><p>Causas de Degradao </p><p> Mudanas no antecipadas: Os requisitos mudam de tal forma que a arquitetura inicial no suporta as modicaes </p><p>Desenvolvedores novos em um Ume no esto familiarizados com a cultura da empresa/padro de trabalho </p><p>Documento de requisitos um dos artefatos mais volteis dentro do processo de desenvolvimento </p><p>14 </p></li><li><p>Causas de Degradao </p><p> Gerncia de Dependncia Os sintomas de degradao esto diretamente ligados ao gerenciamento de dependncia entre os mdulos </p><p>Arquiteto tem diculdade de visualizar e preservar a arquitetura, dada a diculdade de controlar as mudanas </p><p>15 </p></li><li><p>Aplicando princpios de projetos e padres de projetos para minimizar o impacto das mudanas e gerenciar as dependncias </p><p>16 </p></li><li><p>Princpios de Projetos OO </p><p> OCP: The Open Closed Principle OCP: The Open Closed Principle SRP: The Single Responsibility Principle DIP: The Dependency Inversion Principle LSP: The Liskov SubsUtuUon Principle SDP: The Stable Dependencies Principle SAP: The Stable AbstracUons Principle </p><p>17 </p></li><li><p>Princpios de Projetos OO </p><p> CRP: The Common Reuse Principle CCP: The Common Closure Principle CRP: The Common Reuse Principle ADP: The Acyclic Dependencies Principle GRASP: General Responsibility Assignment SoMware Paserns </p><p>18 </p></li><li><p>OCP: The Open Closed Principle </p><p>A module should be open for extension but closed for modica6on. (Bertrand Meyer) </p><p>19 </p></li><li><p>OCP: The Open Closed Principle </p><p>Devemos escrever mdulos visando que os mesmos sejam estendidos sem ter a necessidade de serem modicados. </p><p>20 </p></li><li><p>Exemplo </p><p>Somar dois nmeros </p><p>Subtrair dois nmeros </p><p>Casos de Uso </p><p>Obje7vo: implementar uma calculadora </p><p>Desao: implementar algo que seja exvel o bastante para suportar evolues 21 </p></li><li><p> Exemplo </p><p>Soma </p><p>+ somar(a,b): double </p><p>Subtracao </p><p>+ subtrair(a,b): double </p><p>Calculadora </p><p>+ executarOperacao(Upo: String, a: double, b: double): double </p><p>Resultado: possvel diagrama de classe </p><p>22 </p></li><li><p> Exemplo </p><p> Resultado: possvel implementao da classe Calculadora </p><p>23 </p></li><li><p> Exemplo </p><p> Resultado: possvel implementao da classe Soma e Subtrao </p><p>24 </p></li><li><p>Exemplo </p><p>Somar dois nmeros </p><p>Subtrair dois nmeros </p><p>Casos de Uso </p><p>Evoluo: implementar diviso e mulUplicao </p><p>Dividir dois nmeros </p><p>MulUplicar dois nmeros </p><p>25 </p></li><li><p>Qual o </p><p>da evoluo? 26 </p></li><li><p> Exemplo </p><p>Soma </p><p>+ somar(a,b): double </p><p>Subtracao </p><p>+ subtrair(a,b): double </p><p>Calculadora </p><p>+ executarOperacao(Upo: String, a: double, b: double): double </p><p>ANTES: possvel diagrama de classe </p><p>27 </p></li><li><p> Exemplo </p><p>Soma </p><p>+ somar(a,b): double </p><p>Subtracao </p><p>+ subtrair(a,b): double </p><p>Calculadora </p><p>+ executarOperacao(Upo: String, a: double, b: double): double </p><p>Resultado da Evoluo: possvel diagrama de classe </p><p>Divisao </p><p>+ dividir(a,b): double </p><p>MulUplicacao </p><p>+ mulUplicar(a,b): double 28 </p></li><li><p> Exemplo </p><p> Resultado Anterior: implementao da classe Calculadora </p><p>Mudar Aqui </p><p>Mudar Aqui </p><p>29 </p></li><li><p> Exemplo </p><p> Resultado Depois: possvel implementao da classe Calculadora </p><p>30 </p></li><li><p> Exemplo </p><p>IOperacao </p><p>+ executar(a: double, b: double): double </p><p>Soma </p><p>+ executar(...): double </p><p>Subtracao </p><p>+ executar(...): double </p><p>interface </p><p>realizao </p><p>CalculadoraOCP </p><p>+ executarOp(...): double </p><p>Com Open-Closed: possvel diagrama de classe </p><p>31 </p></li><li><p> Exemplo </p><p> Resultado: possvel implementao da classe CalculadoraOCP </p><p>32 </p></li><li><p> Exemplo </p><p> Resultado: possvel implementao da interface, Soma e Subtrao </p><p>O que mudou? </p><p>33 </p></li><li><p> Exemplo </p><p>IOperacao </p><p>+ executar(a: double, b: double): double </p><p>Soma </p><p>+ executar(...): double </p><p>Subtracao </p><p>+ executar(...): double </p><p>MulUplicacao </p><p>+ executar(...): double </p><p>Divisao </p><p>+ executar(...): double </p><p>interface </p><p>realizao </p><p>CalculadoraOCP </p><p>+ executarOp(...): double </p><p>Com Open-Closed: possvel diagrama de classe </p><p>34 </p></li><li><p> Exemplo </p><p> Resultado: possvel implementao da interface, Soma e Subtracao </p><p>O que mudou? </p><p>35 </p></li><li><p>OCP: The Open Closed Principle </p><p>Em resumo: objeUvo arquitetural do Open-Closed </p><p> Criar mdulos que sejam extensveis, </p><p>porm sem ser modificados </p><p>36 </p></li><li><p>SRP: The Single Responsibility Principle </p><p> SRP: there should never be more than one reason for a class to change [MarUn2002] </p><p> Inicialmente proposto como Coeso por Tom DeMarco [DeMarco79] e Meilir Page-Jones [PageJones88] </p><p> Cada responsabilidade um eixo de mudana </p><p>3/26/14 @KleinnerFarias 37 </p></li><li><p>SRP: The Single Responsibility Principle Se uma classe assume mais de uma responsabilidade, ento existe mais de uma razo para modic-la </p><p> Se uma classe tem mais de uma responsabilidade, ento as responsabilidade se tornam acopladas </p><p> Consequncia: Fragile Design: o projeto quebra de forma inesperada quando modicado </p><p>3/26/14 @KleinnerFarias 38 </p></li><li><p>SRP: The Single Responsibility Principle </p><p> Exemplo [MarUn2002]: + draw() [desenha o retngulo na tela] + area() [calcula a rea do retngulo] </p><p>3/26/14 @KleinnerFarias 39 </p></li><li><p>SRP: The Single Responsibility Principle </p><p> Observaes: Duas aplicaes diferentes usam Rectangle Computa6onal Geometry Applica6on </p><p> Usa a classe Rectangle para calcular a rea: + area() Nunca desenha retngulo na tela: + draw() </p><p>Graphical Applica6on Pode calcular rea: + area() Desenha retngulo na tela: + draw() </p><p>3/26/14 @KleinnerFarias 40 </p></li><li><p>SRP: The Single Responsibility Principle Classe Rectangle viola o SRP: </p><p>Tem duas responsabilidades Calcula a rea do retngulo: + area() Desenha o retngulo na tela: + draw() </p><p>3/26/14 @KleinnerFarias 41 </p></li><li><p>SRP: The Single Responsibility Principle Consequncias: </p><p>Acoplamento transi6vo Computa6onal Geometry Applica6on (CGA) depende de Rectangle que depende de GUI. Logo, CGA depende de Rectangle que depende de GUI </p><p>3/26/14 @KleinnerFarias 42 </p></li><li><p>SRP: The Single Responsibility Principle Consequncias: </p><p>Propagao de mudana Se Rectangle mudar por causa de GraphicalApplica6on, esta mudana pode levar modicaes em CGA </p><p> Se no gerenciarmos este Upo de acoplamento, a aplicao pode sofrer propagaes imprevisveis </p><p>3/26/14 @KleinnerFarias 43 </p></li><li><p>SRP: The Single Responsibility Principle Recomendao: separar as responsabilidades </p><p>3/26/14 @KleinnerFarias 44 </p></li><li><p>SRP: The Single Responsibility Principle Consequncias: </p><p>Acoplamento transiUvo eliminado Isolamento da classe Computa6onalGeometryApplica6on em relao forma de desenhar o retngulo </p><p>A classe CGA no depende mais indiretamente de GraphicalApplica6on </p><p>Mudanas na forma como o retngulo desenhado no afetar CGA </p><p>3/26/14 @KleinnerFarias 45 </p></li><li><p>SRP: The Single Responsibility Principle </p><p>Anal, o que seria responsabilidade? </p><p>3/26/14 @KleinnerFarias 46 </p></li><li><p>SRP: The Single Responsibility Principle </p><p> Responsabilidade: a reason for change Se idenUcamos mais de um moUvo para mudar um classe, ento ele ter mais de uma responsabilidade </p><p> Modem tem quantas responsabilidades? </p><p>3/26/14 @KleinnerFarias 47 </p></li><li><p>SRP: The Single Responsibility Principle </p><p> Duas responsabilidades: Gerenciamento de conexo: dial e hangup Comunicao de dados: send e recv </p><p>3/26/14 @KleinnerFarias 48 </p></li><li><p>SRP: The Single Responsibility Principle </p><p> Duas responsabilidades: Gerenciamento de conexo: dial e hangup Comunicao de dados: send e recv </p><p> Observaes: As responsabilidades tm quase nada em comum Mudam por diferentes razes Sero chamadas por diferentes partes da aplicao, as quais mudaro por diferentes razes tambm </p><p> 3/26/14 @KleinnerFarias 49 </p></li><li><p>SRP: The Single Responsibility Principle Um responsabilidade por interface: </p><p>Gerenciamento de conexo: dial e hangup Comunicao de dados: send e recv </p><p>3/26/14 @KleinnerFarias 50 </p></li><li><p>DIP: The Dependency Inversion Principle </p><p> DIP1: mdulos de mais alto nvel no devem depender de mdulos de mais baixo nvel. Ambos devem depender de abstraes </p><p> DIP2: abstraes no devem depender de detalhes. </p><p> Principal princpio uUlizado para projetar frameworks </p><p> 3/26/14 @KleinnerFarias 51 </p></li><li><p>DIP: The Dependency Inversion Principle </p><p> Mdulos de mais alto nvel: aqueles que implementam regras de negcio suas caractersUcas idenUcam a aplicao devem ser desacoplados de mdulos de mais baixo nvel </p><p> Mdulos de mais baixo nvel: responsveis por detalhes de implementao </p><p> 3/26/14 @KleinnerFarias 52 </p></li><li><p>DIP: The Dependency Inversion Principle </p><p> Segundo Booch: toda arquitetura bem estruturada deve ter </p><p>uma denio clara de suas camadas, com cada camada fornecendo uma conjunto coerente de servios atravs de uma interface bem denida </p><p>e controlada. [MarUn2002] </p><p>3/26/14 @KleinnerFarias 53 </p></li><li><p>DIP: The Dependency Inversion Principle </p><p> Exemplo: </p><p>3/26/14 @KleinnerFarias 54 </p></li><li><p>DIP: The Dependency Inversion Principle Exemplo: </p><p>3/26/14 @KleinnerFarias 55 </p><p>Qual seria o problema com esta arquitetura? </p></li><li><p>DIP: The Dependency Inversion Principle Problema: dependncia transiUva </p><p>3/26/14 @KleinnerFarias 56 </p></li><li><p>DIP: The Dependency Inversion Principle Soluo: cada camada superior dene uma interface com os servios que ela necessita </p><p>3/26/14 @KleinnerFarias 57 </p></li><li><p>DIP: The Dependency Inversion Principle Observaes: </p><p>Camada superior: Interage com a camada inferior considerando os servios declarados nas suas interfaces </p><p> Fica totalmente desacoplada das camadas inferiores Camada inferior: </p><p> denida considerando os servios denidos na(s) interface(s) da camada superior </p><p> A camada inferior depende das interfaces (das abstraes) </p><p> 3/26/14 @KleinnerFarias 58 </p></li><li><p>DIP: The Dependency Inversion Principle Exemplo: </p><p>3/26/14 @KleinnerFarias 59 </p></li><li><p>DIP: The Dependency Inversion Principle Exemplo: </p><p>3/26/14 @KleinnerFarias 60 </p></li><li><p>DIP: The Dependency Inversion Principle Exemplo: </p><p>Bu#on depende diretamente da Lamp Observaes: </p><p> Sempre que Lamp mudar Bu#on tambm mudar No ser possvel reusar Bu#on sem reusar Lamp No ser possvel reusar Bu#on para controlar um Motor </p><p> Ou seja, Bu#on apenas controla Lamp </p><p>3/26/14 @KleinnerFarias 61 </p></li><li><p>DIP: The Dependency Inversion Principle Exemplo: </p><p>Bu#on depende diretamente da Lamp </p><p>3/26/14 @KleinnerFarias 62 </p></li><li><p>DIP: The Dependency Inversion Principle Exemplo: </p><p>3/26/14 @KleinnerFarias 63 </p><p>Button depende diretamente da Lamp </p><p>Button no depende diretamente da Lamp </p><p>Importante: DIP pode ser aplicado sempre que uma classe enviar uma mensagem para outra. </p></li><li><p>LSP: The Liskov SubsUtuUon Principle </p><p>Subclasses should be subs6tutable for their base classes. (Barbar Liskov) </p><p>Design by contract (Bertrand Meyer) </p><p>64 </p></li><li><p>if S is a subtype of T, then objects of type T in a program may be replaced with objects of type S without altering any of the desirable properties of that program (e.g., correctness). (Barbara Liskov) </p><p>65 </p><p>LSP: The Liskov SubsUtuUon Principle </p><p> Em outras palavras </p></li><li><p>O User deve ser capaz de usar qualquer subclasse de Base Por que? </p><p>User usa a classe Base porque ela especica um contrato muito bem denido Respeita o contrato </p><p>denido por Base </p><p>Dene o contrato </p><p>66 </p><p>LSP: The Liskov SubsUtuUon Principle </p></li><li><p> LSP no Exemplo da Calculadora </p><p>IOperacao </p><p>+ executar(a: double, b: double): double </p><p>Soma </p><p>+ executar(...): double </p><p>Subtracao </p><p>+ executar(...): double </p><p>MulUplicacao </p><p>+ executar(...): double </p><p>Divisao </p><p>+ executar(...): double </p><p>interface </p><p>realizao </p><p>CalculadoraOCP </p><p>+ executarOp(...): double </p><p>67 </p></li><li><p> LSP no Exemplo da Calculadora </p><p>IOperacao </p><p>+ executar(a: double, b: double): double </p><p>Soma </p><p>+ executar(...): double </p><p>Subtracao </p><p>+ executar(...): double </p><p>MulUplicacao </p><p>+ executar(...): double </p><p>Divisao </p><p>+ executar(...): double </p><p>interface </p><p>realizao </p><p>CalculadoraOCP </p><p>+ executarOp(...): double </p><p>Com Open-Closed: possvel diagrama de classe User Base </p><p>Derived </p><p>68 </p></li><li><p> LSP no Exemplo da Calculadora </p><p>IOperacao </p><p>+ executar(a: double, b: double): double </p><p>Soma </p><p>+ executar(...): double </p><p>Subtracao </p><p>+ executar(...): double </p><p>MulUplicacao </p><p>+ executar(...): double </p><p>Divisao </p><p>+ executar(...): double </p><p>realizao </p><p>CalculadoraOCP </p><p>+ executarOp(...): double </p><p>CalculadoraOCP usa a IOperacao porque ela muito bem denida no que se compromete a fazer </p><p>69 </p></li><li><p> LSP no Exemplo da Calculadora </p><p>IOperacao </p><p>+ executar(a: double, b: double): double </p><p>Soma </p><p>+ executar(...): double </p><p>Subtracao </p><p>+ executar(...): double </p><p>MulUplicacao </p><p>+ executar(...): double </p><p>Divisao </p><p>+ executar(...): double </p><p>realizao </p><p>CalculadoraOCP </p><p>+ executarOp(...): double </p><p>CalculadoraOCP usa a IOperacao porque espera que as subclasses respeitem o contrato </p><p>70 </p></li><li><p>IOperacao </p><p>+ executar(a: double, b: double): double </p><p>Soma </p><p>+ executar(...): double </p><p>Subtracao </p><p>+ executar(...): double </p><p>MulUplicacao </p><p>+ executar(...): double </p><p>Divisao </p><p>+ executar(...): double </p><p>realizao </p><p>CalculadoraOCP </p><p>+ executarOp(...): double </p><p>Mudana de requisitos, e agora? Para qual 7po de mudanas estamos preparados? ! Adio de novas operaes calculadora </p><p>Exponencial </p><p>+ executar(...): double 71 </p></li><li><p>Onde as mudanas no podem ocorrer? </p><p>Qual o impacto? </p><p>72 </p></li><li><p>Mudanas em classes abstratas e interfaces com alto grau de acoplamento aferente </p><p>73 </p></li><li><p>IOperacao </p><p>+ executar(a: double, b: double): double </p><p>Soma </p><p>+ executar(...): double </p><p>Subtracao </p><p>+ executar(...): double </p><p>MulUplicacao </p><p>+...</p></li></ul>

Recommended

View more >