Univesp - 2021 - Resumo - Engenharia de Software

TEXTO DE REVISÃO\nENGENHARIA DE SOFTWARE (EES001 - UNIVESP)\n\nAlessandra Alanz Macedo\n3º bimestre 2021\n\nEste documento de revisão apresenta um resumo que aborda a lista de assuntos da disciplina de Engenharia de Software - EES001 da Univesp, guiado pelo material de textos-base e de aulas de cada semana.\n\nSEMANA 1: PROCESSOS DE SOFTWARE E DESENVOLVIMENTO ÁGIL\n\nO objetivo da primeira semana foi a definição de conceitos centrais, como software, engenharia de software, engenharia de sistema, processo de software (conjunto de atividades relacionadas que levam à produção de um produto de software) e atividades de software. Foram citados modelos de processo de software (representação simplificada, abstração, de um processo de software) como Cascata, Incremental e Orientado a Reuso. Você também conheceu o modelo de processo unificado RUP (Rational Unified Process) da empresa IBM. Esse processo de desenvolvimento de software combina outros modelos de processo, como prototipação, incremental e iterativo com dinamismo suportado por fases e as atividades estáticas. Além disso, o RUP propõe boas práticas.\n\nIndependentemente do modelo de processo adotado, as atividades fundamentais para o desenvolvimento de software são: especificação, projeto, implementação, validação, evolução. Existem ainda atividades de planejamento, gestão e de apoio. Inclusive, existem modelos de processo que abordam essas atividades, como na Semana 7.\n\nEnfim, o objetivo central da semana foi apresentar modelos para desenvolvimento de software.\n\nSEMANA 2: ENGENHARIA DE REQUISITOS\n\nNesta semana, você diferenciou tipos de requisitos em requisitos de usuários e requisitos de sistema, e requisitos funcionais e requisitos não funcionais. Os requisitos de usuário são apresentados pelo usuário em mais alto nível e geralmente em linguagem natural. Já requisitos de sistema são técnicos, precisos e escritos pelos próprios desenvolvedores. Os requisitos funcionais são as funcionalidades do sistema, enquanto os requisitos não funcionais são atributos de qualidade, performance e restrições.\n\nTambém foram detalhadas as seguintes etapas da atividade de engenharia de requisitos: elicitação de requisitos, análise de requisitos, especificação de requisitos e validação de requisitos. Elicitação envolve a identificação dos fatos que compõem os requisitos do sistema, de forma a prover o mais correto e mais completo levantamento do que é demandado clarificado que é produto.\n\nA elicitação de requisitos envolve a compreensão do domínio da aplicação, o problema específico a ser resolvido, as necessidades e limitações organizacionais e as facilidades específicas necessárias. A análise de requisitos busca descobrir problemas, incompletudes e inconsistências nos requisitos e, para isso, ela normalmente são envolvidas os stakeholders para resolvê-los em um processo de negociação. Usualmente, as atividades de análise intercalam-se em etapas iterativas.\n\nValidação e gerenciamento de requisitos foram descritos em aula, uma vez que são procedimentos fundamentais para processos evolucionários e iterativos de desenvolvimento de software. É importante diferenciar validação de verificação, sendo que validação é a checagem de requisitos para saber se eles representam o sistema correto. Por outro lado, a verificação checa se os requisitos estão representados corretamente, ela será detalhada na Semana 6.\n SEMANA 3: MODELAGEM DE SOFTWARE\n\nNesta semana, você conheceu diferentes tipos de modelos ou diagramas UML para modelagem de análise de software em processo de desenvolvimento. Diagramas de Casos de Uso foram detalhados (veja a Figura 4.6).\n\nEm termos de modelagem, foi iniciada a modelagem dos requisitos com a definição de Diagramas de Casos de Uso usando UML (Unified Modelling Language). Esse tipo de diagrama modela a interação de atores externos e funcionalidades (ou processos) do software em construção.\n\n\n\nFonte: Ian Sommerville, 2011.\n\nDiagramas de Atividades modelam o fluxo de atividades para as funcionalidades do sistema modelado (veja a Figura 5.2). Já os Diagramas de Sequência modelam a sequência de processos para determinada funcionalidade do sistema modelado. Um Diagrama de Sequência pode apresentar a interação entre atores e sistema ou mesmo entre atores e partes do sistema (veja a Figura 5.5). Fonte: Ian Sommerville, 2011.\n\nUm Diagrama de Classes representa a estrutura e as relações das classes de objetos (veja a Figura 5.8), destacando generalização/especialização (veja a Figura 5.11) e associação por agregação dos objetos (veja a Figura 5.12). Esses diagramas e os anteriores são modelos estruturais. Fonte: Ian Sommerville, 2011.\n\nEm termos de modelos comportamentais, especificamente orientado a eventos, você conheceu o Diagrama de Estado. Um Diagrama de Estado ilustra as transições para os eventos do sistema para todos os casos de uso. Os Diagramas de Estado são comumente usados para modelar sistemas críticos e de tempo real, uma vez que esses sistemas são normalmente orientados a eventos.\n\nEnfim, em termos de construção, a modelagem de análise é iniciada com os diagramas de casos de uso, ampliando com outros diagramas estruturais UML na modelagem de projeto (veja na Semana 4). Nos casos de sistemas críticos e de tempo real, pode ser interessante o uso de diagramas de estado.\n\nO objetivo central da semana era conhecer os tipos de modelos UML para modelagem de análise durante o processo de desenvolvimento de software.\n\nSEMANE 4: PROJETO DE SOFTWARE\n\nNa Semana 4, você conheceu modelos de projeto, que são modelos com maior nível de abstração se comparados com modelos de análise da semana anterior. Os modelos de projeto de software identificam os componentes de software e seus relacionamentos com base nos requisitos do cliente. Essa atividade também é crítica como na modelagem de análise, mas exige habilidade técnica, uma vez que está relacionada à implementação do software.\n\nNo contexto de modelagem de projeto também foi incluído o projeto da arquitetura de software e de interfaces (veja as Figuras 7.3 e 7.4). Em termos de arquitetura de software, é importante destacar que elas buscam incluir qualidade a software, uma vez que elas determinam como o sistema deve ser organizado e qual a estrutura geral do sistema. Uma arquitetura de software identifica os principais componentes estruturais do sistema e os relacionamentos entre eles, em destaque para o padrão de arquitetura MVC (veja a Figura 6.2) que tem 3 componentes lógicos: (1) o Modelo que gerencia o sistema de dados e as operações associadas aos dados, (2) o componente Visão que gerencia como os dados vão ser apresentados e (3) o componente Controlador que gerencia a interação do usuário.\n\nFonte: Ian Sommerville, 2011.\n\nVocê também conheceu padrões de projeto que pretendem descrever as melhores práticas de modelagem de software, de modo que se torne possível a outros reusar essa experiência de soluções já testadas.\n\nEnfim, o objetivo central era o entendimento da finalização da modelagem de software, por meios dos modelos UML para modelagem de projeto, os estilos arquiteturais de softwares, as interfaces e os padrões de projeto.\n\nSEMANE 5: ARQUITETURA ORIENTADA A SERVIÇOS E GERENCIAMENTO DE CONFIGURAÇÃO.\n\nNesta semana, você conheceu a arquitetura orientada a serviços, que é um estilo de arquitetura que provê funcionalidades como serviços geralmente acessíveis via web (veja a Figura 19.1). Este exemplo de estilo arquitetural completa o tema da arquitetura de software iniciado na semana anterior. Fonte: Ian Sommerville, 2011.\n\nVocê conheceu também o Gerenciamento de Configuração de Software para suportar o gerenciamento de mudanças dos sistemas de software em evolução para não perder o controle de quais mudanças e versões de componentes foram incorporadas em cada versão do sistema. Dessa maneira, você pode refletir sobre a importância da organização e sistematização dos processos de desenvolvimento de software.\n\nO objetivo central era finalizar o tema de arquitetura de software e discutir sobre terminologias (baselines, check-in, checkout etc.) e as atividades importantes do gerenciamento de configuração para garantir a vida e qualidade de software em evolução (ou manutenção).\n\nSEMANE 6: TESTE DE SOFTWARE\n\nNesta semana, você conheceu conceitos que envolvem o tema do teste de software. O objetivo principal do teste é colocado algumas vezes como determinando que o sistema está livre de defeitos. Contudo, os testes podem mostrar apenas a presença de defeitos, mas não a sua ausência.\n\nDentro das etapas básicas da atividade de desenvolvimento de software, teste é a última etapa antes da entrega do produto. Porem as atividades de teste começam, antes da especificação de requisitos, já estabelecendo disciplinas dentro do ciclo de vida de desenvolvimento.\n\nTestes são parte importante do processo de desenvolvimento de software, pois demonstram a sua qualidade. Os testes podem ser classificados de várias maneiras, tais como a validação e verificação (V&V). Na verdade, teste é uma unidade dinâmica de V&V, enquanto reflete sobre uma abordagem em world-class. Testes e inspeções encontram-se conforme apresentado na Figura 8.2.\n\nFonte: Ian Sommerville, 2011.\n\nForam apresentados teste de unidade, teste de componentes em integração e teste de sistema. Além disso, você tratou das etapas de teste, teste de desenvolvimento, teste de release (aceitação), teste de usuário, formas manuais e automáticas de teste e os tipos de teste por fase de desenvolvimento do software. Testes do tipo caixa preta e caixa branca foram apresentados com destaque da composição de critérios de particionamento para testes.\n\nO objetivo geral era sentir a importância das atividades de teste dentro do contexto de desenvolvimento de software, ainda mais se pensarmos em qualidade desse produto e processo. Atualmente, junto aos modelos ágeis, fala-se em desenvolvimento de software voltado a teste (codificação incremental em conjunto com teste para esse incremento) buscando benefícios como melhor entendimento do código, cobertura mínima de código pelo teste, teste de regressão automatizado, depuração simplificada, e documentação indireta do sistema. Porém, ao final do desenvolvimento, ainda é necessário o desenvolvimento de teste do sistema integrado.\n\nSEMANA 7: REÚSO DE SOFTWARE E DESENVOLVIMENTO BASEADO EM COMPONENTES\n\nNa última semana, surgiu a grande oportunidade de reflexão sobre reúso de software para diminuir custos, aumentar qualidade e fazer entregas mais rápidas. Nesse sentido foram apresentadas diversas abordagens que promovem reúso, por exemplo COTS e ERP.\n\nUma das maneiras de promover o reúso e desenvolver softwares segundo modelos de processo baseados em componentes (Component-based Software Engineering). As atividades são orientadas a objetivos de favorecer componentes para reúso ou mesmo do usar componentes (com reúso). Na atividade, o desenvolvimento deve considerar a criação de componentes com características como padronização, independência, fácil composição, fácil implantação e documentação, além das interfaces de software.\n\nO objetivo geral era permitir reflexões em temas importantes da área relacionados às perspectivas e abordagens atuais de desenvolvimento de software com e para reúso.