Conceitos Essenciais em Engenharia de Software

Análise de Conceito

O conceito de análise consiste em entender as regras de negócio e os requisitos de software a fim de propor uma solução ótima para o problema, com objetivos claros e definidos. Ele também define o escopo do projeto e os requisitos funcionais e não funcionais. A análise é composta de várias etapas:

• Reconhecer o Problema: que envolve o reconhecimento dos elementos básicos do problema, conforme percebido pelos usuários finais.
• Avaliação e Síntese: que avalia o conteúdo da informação, define e desenvolve todas as funções do software, descrevendo seu comportamento em resposta a eventos que afetam o sistema.
• Modelagem: onde modelos de sistemas são criados a fim de melhor compreender os objetivos e o comportamento do sistema.
• Especificação: onde se realiza a especificação formal do software.
• Análise Final: onde se realiza uma verificação final de todo o processo.

Conceito e Metodologia do Modelo

O modelo serve para explicar e apresentar uma solução para um problema; ele não é estático, mas dinâmico. No entanto, a metodologia é um conjunto de procedimentos, técnicas e ferramentas que ajudam a alcançar a solução objetivada, portanto, é dinâmica. Em termos gerais, a metodologia é utilizada em conjunto com os modelos.

Conceito Arquitetônico

A arquitetura é o mais alto nível da estrutura de um sistema, definida em termos de componentes e da interação entre eles. Ela mostra a correspondência entre os requisitos do sistema e os elementos construídos, e exibe as propriedades gerais do sistema, tais como escalabilidade, performance, consistência e compatibilidade, etc.

Conceito de Estilo Arquitetônico

Um estilo arquitetônico é a descrição dos tipos de componentes e um padrão de controle de execução e/ou transferência de dados.

Um estilo arquitetural define uma família de sistemas em termos de padrões de organização estrutural. Um estilo define:

• Vocabulário: (componentes e conectores)
• Restrições: sobre como combinar os elementos.
• Semântica: modelos que determinam como definir propriedades globais a partir das propriedades das partes.

Alguns estilos arquitetônicos comuns são: tubos e filtros, objetos em camadas, cliente-servidor, etc.

Conceito de Componente

Um componente corresponde a uma peça de software responsável por encapsular um conjunto de funções que operam sobre uma parte do modelo de dados da solução. Em alguns casos, corresponde à parte que funciona AutoMon e se integra com outros componentes.

Conceito de Requisito

Requisitos são as descrições dos desejos ou necessidades do usuário em relação a um produto. Eles dão origem a condições que devem ser atendidas para que o produto cumpra suas finalidades. Podemos distinguir entre:

• Requisitos (O Quê): Descrevem o que o sistema deve fazer, como resolver um problema ou atingir um objetivo.
• Requisito (Como): Detalha como implementar os pré-requisitos de software necessários para resolver o problema.

Conceito de Caso de Uso

Um caso de uso é uma técnica utilizada para especificar a funcionalidade e o comportamento de um sistema por meio de sua interação com usuários e/ou outros sistemas.

O diagrama de caso de uso é composto por:

• Atores
• Relacionamentos
• Cenários

Conceito de Requisito Não Funcional

Requisitos não funcionais especificam o que se espera do sistema em termos de qualidades não funcionais específicas, tais como velocidade, facilidade de uso, robustez, confiabilidade, adaptabilidade e portabilidade. Estes são requisitos que não podem ser classificados como "programáveis", mas que devem ser considerados na construção do software.

Conceito de Diagrama de Componentes

Diagramas de componentes representam partes do software que compõem o sistema. Podem ser arquivos simples, pacotes, bibliotecas carregadas dinamicamente, etc.

É composto por:

• Componentes: uma unidade física de implementação com interfaces bem definidas, projetada para ser usada como uma peça de reposição.
• Interface: uma lista de operações que um recurso de software ou hardware pode executar.

Comparação entre Diagramas de Componentes e de Classes

Um diagrama de componentes tem um nível maior de abstração do que um diagrama de classes – geralmente um componente é implementado por uma ou mais classes (ou objetos) em tempo de execução.