Desenho de Software PDF

Desenho de software © Nuno Pina 2024 Análise e Especificação de Requisitos: Capturar e entender o que o software deve fazer. Análise vs Identificar os requisitos funcionais...

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