Desenho Detalhado de Software PDF

© Nuno Pina 2024 Análise e Especificação de Requisitos: Desenho de...

© Nuno Pina 2024 Análise e Especificação de Requisitos: Desenho de Análise vs Capturar e entender o que o software deve fazer. Identificar os requisitos funcionais software (funcionalidades) e não funcionais (desempenho, segurança, etc.). Desenho Foco nos problemas e necessidades do cliente ou utilizador final. Desenho de Software: Determinar como o software irá funcionar. Traduzir os requisitos em uma solução técnica detalhada. Foco na arquitetura, componentes e interação entre os módulos. 2 © Nuno Pina 2024 © Nuno Pina 2024 Análise e Especificação de Requisitos: Design Arquitetural: Definir a estrutura geral do sistema (ex.: arquitetura em Elicitação: camadas, microserviços). Escolher padrões arquiteturais (ex.: MVC, REST). Atividades Reuniões com stakeholders para identificar necessidades. Atividades Design de Componentes: Ferramentas: entrevistas, questionários, observações. Realizadas Modelação de Requisitos: Realizadas Detalhar os módulos ou componentes do sistema e suas responsabilidades. na Análise Criar diagramas (ex.: casos de uso, diagramas de no Design de Dados: contexto). Modelar as bases de dados (ex.: diagramas ER). Documentação dos requisitos em linguagem clara e Desenho Estruturar classes e atributos (em sistemas orientados a objetos). compreensível. Validação e Priorização: Design de Interfaces: Garantir que os requisitos atendem às necessidades Definir interfaces entre módulos e também a interface com o utilizador. do cliente e são viáveis. Especificação Técnica: Gestão de Requisitos: Criar diagramas detalhados (ex.: UML) que mostram Rastrear mudanças nos requisitos ao longo do projeto. interações entre os elementos. 3 4 © Nuno Pina 2024 © Nuno Pina 2024 Documento de Requisitos de Software (DRS): Diagramas UML: Diagramas de classes, sequência, Lista detalhada dos requisitos Entregáveis - funcionais e não funcionais. componentes e estados. Análise e Especificações técnicas detalhadas: Especificação Modelos de requisitos: Arquitetura do sistema e descrição de de Requisitos Entregáveis - algoritmos. Diagramas de casos de uso, diagramas Desenho Protótipos ou mockups (opcional): de contexto, histórias de utilizador. Esboço das interfaces do utilizador. Matriz de rastreabilidade: Modelos de dados: Diagramas de entidade-relacionamento e Relaciona requisitos a funcionalidades especificações do banco de dados. e módulos. 5 6 © Nuno Pina 2024 © Nuno Pina 2024 Análise e Especificação de Análise e Especificação de Requisitos: Requisitos: Envolve fortemente stakeholders Técnicas: Brainstorming, entrevistas, externos (clientes, utilizadores finais) e workshops. analistas de negócios. Ferramentas Ferramentas: Jira, Confluence, Microsoft Envolvimento O foco é traduzir as necessidades em Word, Lucidchart. de Utilizadas Stakeholders requisitos claros. Desenho de Software: Desenho de Software: Técnicas: Design centrado no utilizador, Envolve stakeholders internos desenho baseado em padrões. (arquitetos, desenvolvedores) para Ferramentas: Visual Paradigm, definir a implementação técnica. Enterprise Architect, Draw.io, Figma, O cliente normalmente não está ferramentas UML. diretamente envolvido. 7 8 © Nuno Pina 2024 © Nuno Pina 2024 Análise e Especificação de Riscos: Requisitos: Riscos e Requisitos incompletos ou Alta abstração. Problemas mal definidos. Não se preocupa com a Nível de implementação técnica, mas sim com Comuns - Análise e Especificação de Mudanças frequentes nas as necessidades do negócio e do necessidades do cliente. Abstração utilizador. Requisitos: Desenho de Software: Problemas: Falta de comunicação entre Média a baixa abstração. analistas e stakeholders. O foco é criar soluções técnicas detalhadas para implementar os Ambiguidade na descrição requisitos. dos requisitos. 9 10 © Nuno Pina 2024 © Nuno Pina 2024 Riscos: Análise de Requisitos → Design excessivamente complexo Desenho de Software: Riscos e ou incompatível com os O desenho só pode começar após a requisitos. Dependência conclusão de uma análise clara e problemas Decisões arquiteturais que não completa dos requisitos. e comuns - escalam ou são difíceis de Continuidade Os requisitos servem como base para todas as decisões no desenho do manter. Desenho software. Problemas: Retroalimentação: Falta de alinhamento entre desenvolvedores e arquitetos. Durante o desenho, problemas com os Ausência de documentação requisitos podem ser descobertos, o que pode levar a ajustes na fase de análise. detalhada. 11 12 © Nuno Pina 2024 © Nuno Pina 2024 Análise e Desenho de Aspeto Especificação de Software Requisitos Como o software Pergunta O que o software será principal deve fazer? implementado? Resumo da Comparação Foco Necessidades do cliente/utilizador Solução técnica Design de Software Documento de Diagramas técnicos Entregáveis requisitos e arquiteturas Stakeholders Cliente, utilizador Arquitetos, principais final, analistas desenvolvedores Nível de Alta Média a baixa abstração 13 14 © Nuno Pina 2024 © Nuno Pina 2024 1. Design de Dados/Classes: Define estruturas de dados e classes específicas. O desenho de software abrange princípios e práticas que resultam em sistemas de alta qualidade. 2. Design Arquitetural: Estabelece a organização geral do Essencial para traduzir os requisitos em soluções sistema. práticas. INTRODUÇÃO AO DESIGN Permite a criação de sistemas escaláveis, flexíveis e robustos. COMPONENTES 3. Design de Interfaces: Garante DO DESIGN DE comunicação eficiente entre DE utilizadores e componentes. SOFTWARE Evolui constantemente com novas metodologias, SOFTWARE como desenho ágil e modelagem orientada a objetos. 4. Design de Componentes: Detalha a lógica interna de cada Exemplo: Traduzir um diagrama de requisitos em um módulo do software. diagrama UML. Benefício: Facilita a comunicação entre analistas, arquitetos e Exemplo prático: Um sistema programadores. bancário que divide responsabilidades em classes como Conta, Cliente e Transações. 15 16  1. Design de Dados/Classes © Nuno Pina 2024 1. Design de Dados/Classes Estruturas de dados: Inclui tabelas, coleções, ou objetos de dados que armazenarão informações essenciais para o sistema. O desenho de dados/classes é uma etapa essencial que define as estruturas de dados e as classes que serão utilizadas para Classes e objetos: Classes são descritas no desenho orientado a objetos, incluindo seus representar a lógica de negócios e o armazenamento no software. atributos, métodos e relações (como herança e agregação). Ferramentas e técnicas: Objetivos principais: Diagramas UML (como diagrama de classes). Análise de cardinalidade (relação entre objetos, como "um para muitos"). Criar um modelo lógico que represente entidades e suas relações. Exemplo: Se o sistema gere encomendas, classes como Cliente, Encomenda, e Produto Definir atributos e métodos associados às classes. serão criadas, definindo atributos (nome, quantidade, etc.) e métodos (calcularTotal()). Garantir que a estrutura de dados suporte os requisitos do sistema. © Nuno Pina 2024 18 17 Exemplo 1: Sistema Exemplo 2: Sistema de Gestão de Encomendas de Gestão Escolar Classes: Estilo Arquitetural: Cliente com atributos como nome, Arquitetura em Camadas. email, e telefone. Classes: Encomenda com atributos como idEncomenda, data, e status. Aluno com atributos como Métodos em Encomenda: nome, matrícula, e curso. adicionarProduto(), Disciplina com atributos removerProduto(), e calcularTotal(). como nomeDisciplina, código, e cargaHorária. Estruturas de dados: Utilizar uma Relacionamento: Um aluno tabela na base de dados para pode estar matriculado em armazenar as encomendas, incluindo campos como idCliente, idProduto, e várias disciplinas, e uma quantidade. disciplina pode ter vários alunos (relação muitos para muitos). © Nuno Pina 2024 19 © Nuno Pina 2024 20 © Nuno Pina 2024 2. Desenho Arquitetural 2. Desenho Arquitetural © Nuno Pina 2024 Componentes principais: Identifica subsistemas ou camadas, como interface do utilizador, lógica O desenho arquitetural estabelece a estrutura global do sistema, de negócios e banco de dados. definindo componentes de alto nível e como eles se comunicam. É a "visão macro" do software. Interconexões: Define como os módulos se comunicam (ex.: APIs, chamadas de função, eventos). Tecnologias e padrões: Objetivos principais: Arquitetura RESTful para sistemas distribuídos. Padrões como Event-Driven Architecture ou Microservices. Dividir o sistema em módulos ou camadas para facilitar o desenvolvimento, Exemplo: Num sistema de e-commerce, o desenho arquitetural pode seguir o padrão em manutenção e escalabilidade. camadas: Camada de apresentação: Interface do utilizador. Escolher o estilo arquitetural apropriado (ex.: arquitetura em camadas, microserviços, Camada de negócios: Regras de processamento das encomendas. MVC). Camada de persistência: Gestão da base de dados. 21 22 Papel do Desenho Arquitetural no © Nuno Pina 2024 © Nuno Pina 2024 Processo de Desenvolvimento de Componentes do Desenho Arquitetural Software Estilo ou Padrão Definir a Estrutura do Identifica os principais componentes (módulos, serviços ou subsistemas) e como eles interagem. Diagramas Arquiteturais Arquitetural Interfaces e Integrações Decisões Arquiteturais Estabelece a separação de responsabilidades entre os componentes. Sistema: Diagramas de Exemplo: Arquitetura em Especificação de APIs e Documentação das Componentes: camadas, cliente- protocolos de escolhas feitas, como Representam os servidor, microserviços, comunicação. tecnologias, frameworks Satisfazer Requisitos Atende às necessidades como desempenho, segurança, escalabilidade, disponibilidade e manutenibilidade. principais blocos do sistema e suas arquitetura orientada a eventos. Detalhes sobre a interoperabilidade com e padrões. Justifições e possíveis Serve para alinhar o sistema às restrições técnicas e organizacionais. interações. Não Funcionais: Diagramas de O estilo escolhido depende das outros sistemas. impactos futuros. Implantação: Detalham características do como os componentes projeto. Orientar o Fornece diretrizes para que os desenvolvedores implementem os componentes conforme o desenho. serão distribuídos em Facilita a comunicação entre equipes técnicas e não técnicas, promovendo um entendimento comum. servidores ou Desenvolvimento: dispositivos físicos. Diagramas de Sequência ou Fluxo de Dados: Suporte à Tomada de Permite a escolha de tecnologias, padrões e frameworks que melhor atendem aos objetivos do projeto. Mostram como os dados fluem entre os Facilita a análise de riscos e mitigação de problemas antes da implementação. Decisões: componentes. 23 24  Ferramentas para o Desenho © Nuno Pina 2024 © Nuno Pina 2024 Arquitetural Modelação Visual: UML, C4 Model, Archimate. Diagrama de Arquitetura Plataformas Colaborativas: Lucidchart, Draw.io, em Visio. Camadas Documentação: Markdown, Wikis corporativos, ADR (Architecture Decision Records). 25 26 © Nuno Pina 2024 Diagrama de microserviços © Nuno Pina 2024 28 27 © Nuno Pina 2024 © Nuno Pina 2024 29 30 Exemplo 1: Aplicação © Nuno Pina 2024 de Streaming de Música Estilo Arquitetural: Arquitetura baseada em Microserviços. Microserviços: Serviço de Reprodutor de Música. Serviço de Recomendação. Serviço de Gestão de utilizadores. Comunicação: Utilização de APIs RESTful para troca de informações. © Nuno Pina 2024 32 31  © Nuno Pina 2024 O desenho de interfaces é uma etapa fundamental no processo de desenvolvimento de software. Desenho de Trata da conceção e estruturação da interação entre os utilizadores e o sistema. interfaces Desenho de interfaces Esta etapa visa garantir que o software seja intuitivo, funcional e eficiente, tendo em conta tanto os objetivos dos utilizadores como os requisitos técnicos do projeto 33 © Nuno Pina 2024 34 © Nuno Pina 2024 © Nuno Pina 2024 É a atividade de criar o layout e os elementos visuais Facilidade de uso: Permitir que os que compõem a interação de um utilizador com um utilizadores realizem tarefas de forma sistema. eficiente e com o mínimo esforço. O que é o Acessibilidade: Garantir que o sistema desenho de seja acessível a pessoas com diferentes níveis de capacidade e dispositivos. interfaces? Isto inclui botões, menus, formulários, janelas e Principais outros componentes visuais. objetivos Consistência: Manter padrões visuais e funcionais para reduzir a curva de aprendizagem dos utilizadores. Contudo, vai além do aspeto estético: o foco principal Estética funcional: Criar interfaces é proporcionar: visualmente apelativas, mas sem uma experiência de - garantir uma boa comprometer a usabilidade. utilizador (UX) positiva usabilidade (UI). 35 36 © Nuno Pina 2024 © Nuno Pina 2024 a) Pesquisa e planeamento Compreensão do utilizador: Estudar o público-alvo (personas, comportamentos, necessidades). Ferramentas de Definição de objetivos: Identificar o que o software precisa alcançar para os utilizadores e a empresa. desenho: Figma, Adobe Mapeamento de tarefas: Compreender os fluxos de trabalho e tarefas que os utilizadores irão realizar. XD, Sketch. b) Criação de protótipos Etapas do Wireframes: Esboços simples para definir a estrutura e o layout inicial. Prototipagem rápida: desenho de Mockups: Versões mais detalhadas, com elementos visuais realistas. Ferramentas InVision, Marvel App. Protótipos interativos: Modelos funcionais que simulam a interfaces navegação e as interações. utilizadas c) Testes de usabilidade Validar o protótipo com utilizadores reais para identificar problemas de desenho. Obter feedback sobre a clareza, funcionalidade e eficiência da interface. Testes de usabilidade: d) Iteração Maze, UsabilityHub. Ajustar e melhorar a interface com base nos resultados dos testes. Repetir o processo até que a interface esteja otimizada. 37 38 © Nuno Pina 2024 © Nuno Pina 2024 A interface deve ser desenhada Maior satisfação do utilizador: tendo em conta as limitações e Interfaces bem desenhadas reduzem possibilidades tecnológicas, como a frustração e melhoram a frameworks front-end (React, experiência. Angular) e linguagens de programação. Redução de erros: Um desenho claro e intuitivo minimiza mal-entendidos Integração Benefícios e ações incorretas. A colaboração entre arquitetos e programadores é essencial para Melhor retenção: Os utilizadores garantir que o desenho seja tendem a continuar a usar sistemas implementado como planeado. que oferecem uma experiência agradável. 39 40 © Nuno Pina 2024 © Nuno Pina 2024 O desenho de componentes é uma etapa no desenvolvimento de software que detalha a Um componente é uma unidade lógica lógica interna de cada módulo ou do software que encapsula uma componente do sistema. funcionalidade específica e pode interagir com outros componentes. Esta atividade foca-se em definir como cada componente será implementado Pode ser representado por um módulo, Desenho de internamente, desde a organização do seu classe, função ou mesmo um conjunto componentes código até as interações internas que suportam as funcionalidades desejadas. Componente de objetos que desempenham uma tarefa concreta dentro do sistema. Exemplo: É uma parte essencial do desenho de Num sistema de e-commerce, o componente software, pois garante que cada parte do "Gestão de Carrinho de Compras" é sistema seja eficiente, reutilizável e responsável por adicionar, remover e calcular funcionalmente correta. itens no carrinho. 41 42 © Nuno Pina 2024 © Nuno Pina 2024 Definir a lógica interna de forma clara e modular, Estrutura Interna separando responsabilidades. Identificar e projetar as funções/métodos principais. Definir as classes ou estruturas de dados usadas dentro do componente. Garantir que o componente tenha uma interface externa clara, escondendo detalhes de implementação. Garantir a coesão interna, ou seja, todos os elementos dentro de um componente devem estar Fluxo de Dados relacionados à funcionalidade que ele oferece. Detalhar como os dados fluem através do componente: entradas, saídas e transformações internas. Utilizar diagramas de fluxo de dados ou pseudocódigo para ilustrar o Promover a reutilização de código ao projetar funcionamento. componentes genéricos que podem ser usados Gestão de Estados Objetivos noutras partes do sistema. Elementos Definir como o componente gerirá o seu estado interno. Exemplo: Num componente de autenticação, o estado pode incluir dados do utilizador autenticado e tokens de sessão. Facilitar a manutenção e evolução do software ao Tratamento de Erros dividir a lógica em unidades bem definidas. Incluir lógica para prever e gerir falhas internas, como validação de dados ou gestão de exceções. Interações Internas Reduzir o acoplamento, para que as dependências Especificar como as partes internas do componente comunicam entre si. entre componentes sejam minimizadas. Exemplo: Métodos privados que auxiliam métodos públicos. 43 44 © Nuno Pina 2024 © Nuno Pina 2024 UML (Unified Modeling Language): Definir o objetivo do componente: Para desenhar diagramas de classes, O que este componente deve fazer? Quais são as entradas e saídas esperadas? de sequência ou de atividades. Projetar a interface externa: Diagramas de Fluxo de Dados: Para Passos para o Quais métodos ou funções o componente irá expor para outros módulos? representar como os dados são desenho de Exemplos: API REST, funções públicas, eventos. processados internamente. componentes Detalhar a lógica interna: Criar diagramas ou pseudocódigo para descrever o funcionamento interno. Ferramentas Ferramentas de desenho: Identificar subcomponentes, classes ou estruturas de suporte. Lucidchart, Draw.io ou Microsoft Identificar dependências: Visio para criar diagramas. Listar outros componentes, serviços ou bibliotecas necessárias. Testar a lógica interna: Pseudocódigo: Para descrever o Garantir que cada unidade de funcionalidade funciona como fluxo lógico de algoritmos. esperado através de testes unitários. 45 46 © Nuno Pina 2024 © Nuno Pina 2024 Interface externa: Métodos: Um desenho de qualidade deve: CriarUtilizador(dados) Exemplo: AtualizarUtilizador(id, novosDados) - Ser modular, - Usar padrões arquiteturais - Garantir - Representar DIRETRIZES EliminarUtilizador(id) facilitando interfaces requisitos Design de um ObterUtilizador(id) manutenção e reconhecidos (ex.: MVC, simples e claramente e DE escalabilidade. intuitivas. ser rastreável. componente Lógica interna: Microservices). "Gestão de QUALIDADE NO Métodos privados: Utilizadores" ValidarDados(dados) GerarHashSenha(senha) DESENHO Gestão de dados: Estrutura interna: Classe Utilizador com atributos Exemplo: Uso do padrão MVC como nome, email e senha. em aplicações web para separar Tratamento de erros: lógica de apresentação e Exceções para dados inválidos ou utilizadores não processamento. encontrados. 47 48 © Nuno Pina 2024 © Nuno Pina 2024 1. Abstração: Foco nos aspetos essenciais, ignorando detalhes desnecessários. 1. O desenho deve ser rastreável aos requisitos. 2. Modularidade: Divisão do sistema em partes menores e independentes. 2. Desenvolva iterativamente para ajustar e refinar. PRINCÍPIOS CONCEITOS 3. Ocultação de Informação: Limita o acesso a DE 3. Priorize representações compreensíveis e FUNDAMENTAIS detalhes internos para reduzir dependências. MODELAÇÃO acessíveis. DE DESENHO DE DESENHO 4. Adapte o desenho a diferentes abordagens, 4. Independência Funcional: Altamente coeso e como ágil ou cascata. com baixo acoplamento entre módulos. Exemplo: Refinar diagramas UML durante o ciclo de desenvolvimento para incluir novos requisitos. Exemplo: Criar APIs para encapsular funcionalidades complexas e expor apenas métodos necessários. 49 50 © Nuno Pina 2024 O desenho de software é uma etapa crítica para sistemas eficientes e manuteníveis. Diretrizes e princípios ajudam a manter qualidade e escalabilidade. Abstração, modularidade e ocultação de RESUMO E informação simplificam a complexidade. CONCLUSÃO Design iterativo é chave para acomodar mudanças nos requisitos. Exemplo final: Uso de ferramentas como UML, padrões de desenho e revisão de código para manter a qualidade. 51