Conceitos de Engenharia de Software
Técnicas de Desenvolvimento de software
* Define uma estratégia para a construção de visões do sistema em diferentes níveis de abstração.
Top-down:
Parte de elementos mais completos do sistema e desce até os níveis mais detalhados do sistema.
Bottom-up:
Parte de componentes menores do sistema, estes são agrupados para formar os principais componentes do sistema (de mais alto nível)
Middle-out:
* parte de componentes intermediários os elementos mais complexos são compostos e os mais simples são identificados
Fan-In:
* O fan-in de um módulo indica o número de módulos que o utilizam, ou seja, que tem relações de uso com o modulo.
* Um fan-in alto indica que o módulo representa uma abstração bem definida, muito utilizada por outros módulos.
Fan-Out:
* O fan-out de um módulo indica o número de módulos que são utilizados por ele, ou seja, o número de módulos com quem ele tem relações de uso.
Profundidade:
* A profundidade de um diagrama de estruturas indica o número de níveis da arvore (ou DAG) de relações.
Coesão:
* Um módulo com alta coesão realiza uma única tarefa, necessitando de pouca interação com tarefas realizadas em outros módulos.
* Em termos práticos, um módulo altamente coeso realiza uma única tarefa, sem precisar executar rotinas de outros módulos.
Acoplamento:
* O acoplamento é uma medida de interconexão entre os módulos de um sistema
* O acoplamento depende da complexidade da interface entre módulos
* O acoplamento é medido entre dois módulos, definindo o grau de dependência entre eles
Visibilidade de Atributos:
* Publica (simbolo +)
– Qualquer classe pode acessar o atributo
* Privada (simbolo -)
– Apenas objetos da classe acessam o atributo
* Protegida (Simbolo #)
– Apenas objetos da classe e seus descendentes acessar o atributo
Associações
Cardinalidade:
* A Cardinalidade indica o número de objetos participando em cada lado da associação
* Indica o número mínimo e máximo de objetos
* Se o máximo for igual ao mínimo, apresenta um único número
* Tipos mais comuns de associação:
1 – Exatamente 1 objeto
0..* – Zero ou mais objetos
1..* – Um ou mais objetos
0..1 – Zero ou mais objetos
4..7,9 – 4,5,6,7 ou 9 objetos
Agregação
Uma agregação é uma associação especial, utilizada quando existe uma relação de contedor-conteúdo entre as classes
Exemplo:
– Um carro contém um motor
– Uma cidade contém bairros
É utilizado um diamante no lado da classe que contém o elemento, no exemplo anterior o diamante estaria no lado do carro.
Auto-relacionamento
Ocorre quando uma classe possui um objeto da mesma classe como atributo, ou seja, quando uma classe possui uma associação ou agregação consigo mesma.
– Um auto-relacionamento é representado por uma linha conectando a classe a si mesma.
– Um auto-relacionamento de agregação possui um “diamante” em um dos lados da linha.
Diagramas da UML
Diagramas de Sequencia
Defeitos de Software
Omissão:
Um ou mais diagramas de projeto que deveria conter algum conceito dos requisitos gerais ou do documento de requisitos não contêm uma representação para o conceito.
Fato Incorreto:
Um diagrama de projeto contém uma representação errada de um conceito descrito nos requisitos gerais ou no documento de requisitos.
Inconsistência:
Uma representação de um conceito em um diagrama de projeto não concorda com uma representação do mesmo conceito no mesmo ou em outro diagrama de projeto.
Ambiguidade:
Uma representação de um conceito no projeto não está clara, e poderia levar o usuário do documento (projetista de baixo nível, desenvolvedor, etc.) a interpretar de forma diferente ou não entender o significado do conceito.
Informação Estranha:
O projeto inclui informação que, enquanto talvez verdadeira não se aplica a este problema e não deveria estar incluída no projeto.
Técnicas para Detecção de Defeitos
Ad-hoc:
Inspetor lê o documento de acordo com a sua perspectiva
Checklist:
Inspetor segue uma lista de itens com características a serem revisadas, mas ainda aplica leitura Ad-hoc para identificar os defeitos.
Arqcheck:
É uma abordagem para a avaliação de documentos arquiteturais baseada em checklists. Tem como objetivo identificar defeitos em documentos arquiteturais, aumentando a qualidade do software.
Técnicas de leitura:
Desenvolvedores são treinados para escrever artefatos de software mas raramente possuem habilidades para revisá-lo;
Desenvolvedores confiam em técnicas ad-hoc e não seguem um procedimento bem definido.
Tipos de Testes:
– Unidade:
– Integração:
– Regressão:
– Sistema:
– Validação (Aceitação):
– Instalação:
Medições em Engenharia de Software
Métodos Ponderados por Classe (WMC)
é uma métrica que representa a complexidade da classe por meio de seus métodos. O cálculo da métrica é dado pelo somatório das complexidades dos métodos que constituem a classe. Fica em aberto a definição para complexidade.
– A quantidade de métodos de uma classe e a complexidade de tais métodos constituem um indicador do esforço de manutenção da classe.
– Classe com um grande número de métodos têm potencial de reúso limitado, pois tendem a ter um uso especifico da aplicação da qual fazem parte.
Profundidade de Árvore de Herança (DIT)
Indica a posição de uma classe na árvore de herança de um software, que é dada pela distância máxima da classe até a raiz da árvore.
– Essa métrica é considerada um indicador da complexidade de desenho e de predição do comportamento de uma classe, visto que quanto maior a profundidade da classe na árvore de herança, mais classes, e portanto mais métodos e atributos, estarão envolvidos na análise.
Número de Filhos (NOC)
Indica a quantidade de sub-classes imediatas de uma classe.
– É um indicador da importância que uma classe tem no sistema, pois quanto mais sub-classes possuir uma classe, maior a importância de seu teste no sistema.
Acoplamento entre Classes de Objetos (CBO)
É um totalizador do número de classes às quais uma determinada classe está acoplada. Para Chidamber e Kemerer, o acoplamento entre duas classes existe quando métodos de uma delas usa métodos ou variáveis da instancia da outra.
– A razão da existência desta métrica é justificada pelos autores pela necessidade de redução de acoplamento entre classes de objetos para atender fatores como melhoria de modularidade e aumento de reusabilidade.
Resposta de Classe (RFC)
Apresenta o resultado do número de métodos que podem ser executados em resposta a uma mensagem recebida por um objeto da classe. Este resultado é dado pela quantidade de métodos da classe somada à quantidade de metodos invocados por cada método da classe.
– Como CBO, é um indicador de conectividade de uma classe. Enquanto CBO mostra a quantas outras classes uma classe está conectada, RFC é um detalhamento desta informação, pois apresenta por quantos caminhos uma classe está conectada a outras classes.
Ausência de Coesão em Métodos (LCOM)
É uma métrica da ausência de coesão entre métodos de uma classe. Chidambler e Kemerer consideram que a coesão entre os métodos de uma classe é definida pela similaridade entre eles.
– Dois métodos de uma classe C são coesos se compartilham variáveis de instância de C.
– Baixos valores para essa métrica indicam bom nível de similaridade, portanto de coesão, entre os métodos da classe avaliada.
– Um valor alto para LCOM indica qual a classe não provem uma funcionalidade bem específica.
Métricas MOOD
– O conjunto de métricas MOOD (Metrics for Object Oriented Design) foi proposto por Abreu & Carapuça em 1994.
– As métricas MOOD avaliam os aspectos de herança, ocultação de informação, acoplamento, polimorfismo e reusabilidade em um software orientado por objetos.
– O cálculo de uma métrica MOOD é dado por uma razão na qual o numerador é o número de ocorrências encontradas no sistema para o aspecto avaliado e o denominador é o maior número possível de ocorrências no sistema para tal aspecto.
– Desta forma, o resultado de qualquer métrica MOOD é sempre um valor entre 0 e 1.
– Esse tipo de resultado fornece uma dimensão para a métrica independente do tamanho do sistema avaliado.
Fator Herança de Método (MIF)
Essa métrica indica o percentual de métodos herdados no sistema.
Seja Ci uma classe do sistema a ser avaliado. Para a definição da métrica MIF, são consideradas as seguintes métricas básicas:
– Métodos herdados: Mh(Ci) São os métodos que uma classe possui em decorrência de herança e que não foram redefinidos na classe.
– Métodos novos: Mn(Ci). São métodos criados na classe, que não foram herdados nem redefinidos.
– Métodos redefinidos: Mr(Ci). São métodos herdados que têm uma redefinição na classe.
– Métodos definidos: Md(Ci). Englobam os métodos novos e os métodos redefinidos na classe.
– Métodos disponíveis: Mdis(Ci). É a totalidade de métodos que uma classe possui, o que engloba métodos definidos nela e os métodos herdados por ela.
– Total de classes do sistema: TC
* O cálculo de MIF é realizado da seguinte forma: para cada classe do sistema, verifica-se a quantidade de métodos herdados e a quantidade de métodos disponíveis.
– Uma valor de MIF igual a zero informa que o sistema não utilizou o recurso de herança de métodos, ou se usou a herança foram todos os métodos redefinidos.
Fator Herança de Atributo (AIF)
Indica o percentual de atributos herdados no sistema. Um raciocínio similar ao realizado no calculo do fator herança de métodos é realizado para o fator herança de atributos AIF.
O valor de AIF é dado pela razão entre o somatório do número de atributos herdados (TAh) de cada classe do sistema e o somatório do número de atributos disponíveis (TAdis) de cada classe do sistema
Métricas para Avaliação de Ocultação de Informação:
– A ocultação de informação é um conceito importante relacionado à modularidade, pois a sua aplicação potencializa a independência de módulos.
– Quanto mais ocultos os serviços e as informações de uma classe, menor a necessidade de as demais classes conhecerem sua organização interna e, consequentemente, mais fraco é o nível de interdependência entre as classes.
– Uma classe deve ser conhecida somente pelos serviços que ela disponibiliza.
– Na orientação por objetos, a ocultação de informação é obtida principalmente pelo uso de atributos e métodos privados nas classes.
Fator Ocultação de Método (MHF)
Esta métrica representa o percentual de métodos ocultos no sistema. Para seu cálculo, as seguintes métricas básicas são definidas considerando-se Ci uma classe qualquer do sistema a ser avaliado.
– Métodos visíveis: Mv(Ci). São os métodos que constituem a interface da classe.
– Métodos ocultos: Mo(Ci). São os métodos privados da classe.
– Métodos definidos: Md(Ci). São os métodos visíveis e os métodos ocultos da classe.
* O MHF é a razão entre o número de métodos ocultos em todas as classes e o número de métodos definidos em todas as classes.
Fator de Ocultação de Atributo (AHF)
Essa métrica é o percentual de atributos ocultos no sistema. Similarmente a MHF, o cálculo de AHF é dado pela razão entre o número de atributos ocultos em todas as classes e o número de atributos definidos em todas as classes.
Ao – número de atributos ocultos na classe.
Ad – número de atributos disponíveis na classe.
Métrica para Acoplamento:
O Conjunto MOOD define a métrica COF (Fator Acoplamento) como um indicador do grau de conectividade do software.
– COF (Fator Acoplamento): para a avaliação de acoplamento considera-se o conceito de relação cliente-servidor entre as classes constituintes de um software.
– Segundo esse conceito, uma classe A é cliente de uma classe B quando A referencia pelo menos um membro de B, seja este membro um atributo ou um método.
– Uma relação cliente-servidor entre duas classes corresponde à existência de uma conexão entre elas. Em um software com n classes, o maior numero possível de conexões é n(n-1).
– A métrica COF é dada pela razão entre o numero total de conexões existentes entre as classes do software e o maior número possível de conexões para o software. Um software totalmente conectado possui COF=1.
– COF é uma métrica impostante, pois indica quão conectado é um software. Um software fortemente conectado possui estrutura rígida, baixo grau de independência entre os módulos e, consequentemente, o custo na sua manutenção é explosivo.