Engenharia de Software

Transcrição

1 Engenharia de Software Design Principles Representando SW em UML OO em C Pattens úteis para embedded Rodrigo M A Almeida

2 Design Principles Design Principles são guias para decompor as funcionalidades e comportamentos do software em módulos As seis diretivas principais Modularidade Interface Proteção de informação Desenvolvimento incremental Abstração Generalização

3 Design Principles Modularidade Modularidade é a capacidade do sistema de manter separados os diversos aspectos do seu comportamento Se bem aplicado, cada módulo tem um único propósito e será relativamente bem separado dos demais É mais simples entender cada um dos módulos e programá-los É mais facil realizar mudanças no sistema Para determinar quão bom é um projeto com relação a modularidade utilizamos duas medidas de independência: acoplamento e coesão.

4 Design Principles Acoplamento Dois módulos estão fortemente acoplados se estes dependem fortemente um do outro. Módulos fracamente acoplados possuem alguma interdependência, mas esta relação é pequena Módulos desacoplados não possuem qualquer ligação. Uncoupled - Loosely coupled - no dependencies Tightly coupled - some dependencies many dependencies

5 Design Principles Acoplamento Existem diversas maneiras de um módulo ser dependente de outro: Pela quantidade de referências para outro módulo Pela quantidade de dados passados de um módulo para outro Pela quantidade de controle que um módulo tem sobre outro

6 Design Principles Interfaces A interface define quais serviços a unidade de software provém para o restante do sistema e como as outras unidades podem utilizá-la Uma interface deve também definir quais são os requeimentos, em termos de prerequisitos de serviços, para que o software funcione corretamente A unidade de interface do software descreve quais os requerimentos do ambiente são necessários para seu funcionamento e qual as funcionalidades ela disponibiliza para o ambiente

7 Design Principles Interfaces Uma unidade de software pode possuir diversas interfaces que exigem condiuções diferentes do ambiente ou prestam diferentes serviços Módulo Data Operação 1 Operação 2 Interface A Operação 3 Operação 4 Operação 1 () Operação 2 () Operação 4 () Interface B Operação 2 () Operação 3 ()

8 Design Principles Interfaces A especificação de uma interface de software descreve as características disponiveis para as outras unidades Uma especificação de interface deve comunicar ao outro desenvolvedor tudo que ele precisa para utilizar a unidade de software corretamente. Propósito Pré-condições (suposições) Protocolos Pós-condições (efeitos visíveis) Atributos qualitativos

9 Design Principles Abstração Uma abstração é um modelo ou representação que omite alguns detalhes para que o observador possa se concentrar nos demais A definição sobre quais detalhes devem ser deixados for a do modelo é vaga, pois existem diferentes abstrações para diferentes propósitos, omitindo detalhes diferentes.

10 Design Principles Generalização Generalização é a diretiva de desing que faz com que o módulo de software seja aplicado de modo mais abrangente possível, para que possa ser reutilizado no futuro Melhora-se a generalidade do software fazendo com que o software possa ser utilizado numa quantidade maior de contextos. Algumas maneiras de fazê-lo: Parametrizando informações específicas do contexto Removendo pré-condições Simplificando as pós-condições

11 Representando SW em UML UML é um conjunto de modelos para representação de padrões de projeto que é popular para descrever soluções OO Ela pode ser utilizada para visualizar, especificar ou documentar um projeto de software É especialmente útil para descrever diferentes alternativas de projeto e até mesmo documentar decisões

12 Representando SW em UML Tipos de relações entre classes association composition aggregation generalization dependency navigation

13 Representando SW em UML Diagramas sequênciais Diagramas de interação descrevem como as operações são realizadas pelo sistema

14 Representando SW em UML Diagramas de estado Um diagrama de estado apresenta os possíveis estados em que um objeto pode estar e os eventos que podem modificar este estado

15 Representando SW em UML Diagrama de Atividades Diagramas de atividades são utilizados para apresentar o fluxo de execução dentro de um módulo

16 Design Patterns Um design pattern codifica decisões de projeto e boas práticas para solucionar alguns problemas em particular. Design patterns não são a mesma coisa que bibliotecas (software libraries). Eles não são soluções empacotadas que podem ser usadas "out-of-the-box". Estão mais para guias de como desenvolver uma solução

17 Design Patterns É uma representação abstrata das melhores práticas para resolver problemas comumente conhecidos num determinado ramo de aplicação. A vantagem é construir um padrão comum a diferentes programadores que permite reduzir o custo e o tempo de projeto.

18 OO em C Orientação à objeto é um paradigma de programação É necessário que a linguagem dê suporte as caracteristicas deste paragma Não é exatamente o caso de C

19 OO em C A linguagem C é basicamente uma linguagem estruturada e funcional (orientada à funções) Não existem estruturas para desenvolvimento de classes, objetos, heranças, etc Mas é possível utilizar os conceitos de OO em C

20 OO em C Porque tudo isso? Organização Reutilização de código Confiabilidade Porque o professor quer =)

21 OO em C Não existe o conceito objeto nem instanciação, mas é possível trabalhar com classes estáticas Todas as classes serão estáticas, tanto métodos como variáveis Cada classe será representada por um conjunto de arquivos: classe.c, classe.h, classe_prm.h e classe_type.h

22 OO em C classe.c Possui a implementação de todas as funções da classe Implementa os protótipos das funções privadas Define as variáveis privadas Inclui apenas classe.h classe.h Implementa os protótipos das funções públicas Define as variáveis públicas Inclui classe_prm.h e classe_type.h

23 OO em C classe_prm.h Reúne todas as definições alteráveis pelo programador Tamanho do buffer, tempo de delay do debounce Normalmente o programador não deve alterar os demais arquivos classe_types.h Reúne todos os "typedef's" utilizados na classe Visa evitar referências circulares em classes extremamente acopladas Facilita o entendimento do sistema

24 Pattens úteis para embedded Singleton Implementa situações onde apenas pode haver uma instância da classe Como não há o conceito de instanciação, por definição, todas as classes são singletons Útil pra que? Apesar de todas serem singletons, algumas classes podem ser agrupadas por função (seriala, serialb, etc) É importante quando queremos explicitar que aquela funcionalidade é exclusiva.

25 Singleton Pattern

26 Pattens úteis para embedded State Diagram Pattern A classe responde de modo diferente dependendo do seu estado atual Implementação As funções que são modificadas são implementadas com "case"

27 State Diagram Pattern

28 Pattens úteis para embedded Adapter Realiza o parser entre duas classes incompatíveis Porquê usar? Quando as classes já são conhecidas e testadas é melhor realizar apenas uma adaptação externa do que modificá-las. A modificação pode quebrar outras partes do código.

29 Adpater Pattern

30 Pattens úteis para embedded Bridge Visa separar duas classes de modo que estas possam operar independentemente Muitas vezes confundido com o Adapter Porquê usar? Simplifica a interface entre as classes. É bom para esconder a complexidade de hardware (driver) permitindo uma interface única para a aplicação

31 Bridge Pattern

32 Pattens úteis para embedded Facade Permite utilizar uma biblioteca de modo mais simples Torna o código mais simples de entender Reduz as dependências externas Facilita a utilização de uma determinada funcionalidade que depende de várias tarefas

33 Facade Pattern

34 Pattens úteis para embedded Observer Reune informações sobre um determinado comportamento do sistema e avisa os interessados quando acontecer uma mudança. Toda interrupção é um observer implementada em hardware. Implementação Exige a utilização de callbacks/signals Porquê usar? Disponibiliza tempo do processador para outras tarefas.

35 Observer Pattern

36 Exemplo

37 Exemplo

38 Exemplo

39 Exemplo

40 Exemplo

41 Exemplo