Engenharia de Software
Design Principles
Representando SW em UML
OO em C
Pattens úteis para embedded
Rodrigo M A Almeida
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
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.
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. Tightly coupled -many dependencies Loosely coupled -some dependencies Uncoupled -no dependencies
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
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
Design Principles
Interfaces
• Uma unidade de software pode possuir diversas
interfaces que exigem condiuções diferentes do ambiente ou prestam diferentes serviços
Data ________________ _________________ _________________ Operação 1 _________________ _________________ _________________ _________________ Operação 2 _________________ _________________ _________________ _________________ Módulo Interface A Operação 1 () Operação 2 () Operação 4 () Interface B Operação 2 () Operação 3 () Operação 3 _________________ _________________ _________________ _________________ Operação 4 _________________ _________________ _________________ _________________
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)
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.
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
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
Representando SW em UML
Tipos de relações entre classes
association composition aggregation dependency navigation generalization
Representando SW em UML
Diagramas sequênciais
•
Diagramas de interação descrevem como
as operações são realizadas pelo sistema
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
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
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
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.
OO em C
•
Orientação à objeto é um paradigma de
programação
•
É necessário que a linguagem dê suporte
as caracteristicas deste paragma
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
OO em C
•
Porque tudo isso?
– Organização
– Reutilização de código
– Confiabilidade
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:
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
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
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
Singleton Pattern
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
State Diagram Pattern
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
Adpater Pattern
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
Bridge Pattern
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
Facade Pattern
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
