Guia Requisitos, Modelagem e UML

Principais Anomalias Arquiteturais de Software

Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Para efetuar o download você precisa estar logado. Clique aqui para efetuar o login
Confirmar voto
0
 (5)  (0)

Entenda quando o mal planejamento arquitetural impacta na qualidade do ciclo de vida do software.

Fique por dentro
Este artigo tem por objetivo mostrar para o leitor como as más decisões aplicadas no planejamento de projetos arquiteturais podem ocasionar o surgimento de sintomas conhecidos por anomalias arquiteturais, e que podem comprometer a qualidade do ciclo de vida de software preterindo a sua evolução e manutenção. São descritas as anomalias catalogadas até o momento, como são caracterizados estes sintomas, quais os tipos de anomalias e como cada anomalia impacta negativamente a arquitetura e o desenvolvimento de software.

No processo de desenvolvimento de software, as necessidades do cliente são coletadas e analisadas no processo de engenharia de requisitos. Após a análise de requisitos, estas necessidades são formalizadas e documentadas para servir de referência para o processo de análise e projeto do sistema a ser desenvolvido. Na etapa de projeto de sistema, são analisados que tipos de tecnologias, modelos e estruturas de software serão utilizados para desenvolver o software, que deverá atender as necessidades do cliente. Nesta etapa, são desenvolvidos os projetos arquiteturais de software.

Os projetos arquiteturais são documentações produzidas para descrever a estrutura arquitetural de software e seus componentes. Através desta documentação, o analista consegue compreender como deve ser a organização, estrutura e o comportamento dos elementos arquiteturais de software que, após ser implantado e colocado em execução possa atender as necessidades do cliente de forma satisfatória. É no processo de desenvolvimento da arquitetura do software, que os elementos arquiteturais são modelados de forma que atenda às necessidades do cliente, sejam elas de requisitos funcionais ou não funcionais. Necessidades estas como: alto desempenho, segurança, processamento paralelo, processamento em tempo real e etc. Desse modo, o projeto do desenvolvimento arquitetural de software corresponde a uma das etapas necessárias para o desenvolvimento de software; porque sem ela não é possível estruturar o código do software de forma que venha a conciliar o máximo das necessidades do cliente possível. No entanto, assim como qualquer outra etapa do processo de desenvolvimento de software, o processo de desenvolvimento arquitetural não acontece de forma ideal e perfeita devido a diversos fatores como: limitações no prazo de entrega e/ou atualização do software; baixa interação entre os membros da equipe; necessidades de negócios, gerenciamento de dívida técnica e etc. Estes e demais fatores, consequentemente, podem ocasionar o desenvolvimento arquitetural mal planejado devido a tomadas de decisões inadequadas na modelagem e elaboração da estrutura arquitetural do sistema. Desse modo, o mal planejamento arquitetural devido a tomadas de decisões inadequadas na elaboração da arquitetura do software podem ocasionar o surgimento de sintomas conhecidos como Anomalias Arquiteturais (GARCIA et al., 2009).

As Anomalias Arquiteturais são conhecidas na literatura como sintomas, provenientes do mal planejamento arquitetural, que impactam de forma negativa nas propriedades do ciclo de vida do software comprometendo a sua qualidade. Entre as propriedades que podem sofrer impacto negativo são a manutenção e o reuso de software. A manutenção, porque o projeto arquitetural mal elaborado vai demandar tempo e esforço para a sua correção. O reuso, porque a má elaboração pode inibir a evolução e/ ou adaptação do software ou seus componentes para o desenvolvimento de outros softwares. Além disso, as anomalias arquiteturais surgem quando elementos arquiteturais de software não são modelados de forma adequada, mesmo que a modelagem esteja de acordo com os padrões e regras formais de modelagem utilizadas, como por exemplo, Diagramas UML (BOX 1). Desse modo, a qualidade do projeto arquitetural fica comprometida, podendo acarretar problemas na etapa de codificação que poderiam ser evitados com uma modelagem arquitetural adequadamente projetada (GARCIA et al., 2009).

Para facilitar o entendimento sobre as anomalias arquiteturais, alguns especialistas na área descrevem as anomalias por meio de notação UML, através de componentes arquiteturais ou Diagrama de Arquitetura UML. Desse modo, será feita uma breve descrição sobre a Engenharia de Software Baseada em Componentes para compreensão do contexto sobre componentes arquiteturais.

BOX 1. UML
A UML, Unified Modeling Language – Linguagem de Modelagem Unificada, é uma das várias e mais conhecidas linguagens de modelagem utilizada na área de Engenharia de Software para a modelagem de sistemas computacionais. Esta linguagem foi desenvolvida e é mantida pela organização OMG (Object Management Group). De um modo geral, esta linguagem é composta de 15 padrões de modelagem, que podem ser utilizados em todas as etapas do processo de desenvolvimento de software, sendo eles: Diagrama de Casos de Uso, Diagrama de Componentes, Diagrama de Atividades, Diagrama de Classes, Diagrama de Implantação, dentre outros.

Engenharia de Software Baseada em Componentes

A Engenharia de Software Baseada em Componentes é uma abordagem para o desenvolvimento de software orientada a reutilização de sistemas, visando um rápido desenvolvimento e a redução de custos. Esta abordagem surgiu devido a característica intrínseca do software que, durante o seu ciclo de vida, tende sempre a crescer tanto em linhas de código quanto no número de artefatos, se tornando cada vez mais complexo. Logo, se torna uma tarefa cada vez mais difícil fazer manutenção e a evolução do software. Desse modo, esta abordagem visa abstrair o software como um conjunto de componentes interconectados que disponibilizam serviços de forma autônoma, ou seja, a arquitetura do software passa a ser modelada baseada em modelo de componentes. Estes serviços podem ser prestados entre componentes, diretamente com o usuário ou com sistemas de terceiros. Cada componente fu"

[...]
Este artigo é exclusivo para assinantes. Descubra as vantagens
  • 473 Cursos
  • 10K Artigos
  • 100 DevCasts
  • 30 Projetos
  • 80 Guias
Tenha acesso completo
 
Você precisa estar logado para dar um feedback. Clique aqui para efetuar o login
Receba nossas novidades
Suporte ao aluno - Deixe a sua dúvida.