UC00601 - Analisar e planear sistemas de informação

UC00601 - Analisar e planear sistemas de informação

Let's go!

Sumário

• Apresentação
• Balanço de competências
• Resumo sobre unidade.

• Introdução aos Sistemas de Informação (SI)
• Discussão

Continue

Continue

Objetivos da Sessão

• Compreender o conceito de Sistema de Informação (SI).
• Identificar tipos e exemplos práticos de SI.
• Reconhecer os componentes de um SI.
• Relacionar SI com o processo de tomada de decisão.

Continue

O que é um Sistema de Informação

Continue

Sistema

Informação

Um sistema é um conjunto de elementos inter-relacionados que trabalham para atingir um objetivo comum. Características:

• Entradas
• Processamento
• Saídas
• Feedback

Exemplo Sistema de rega: sensores de humidade → controlador → válvulas de água → solo com humidade estável.

Informação = dados organizados, contextualizados e compreensíveis. Valor da informação depende:

• Contexto
• Relevância
• Atualidade
• Fiabilidade

Continue

O que é um Sistema de Informação?

Um Sistema de Informação é um sistema que recolhe, guarda, processa e distribui informação para:Apoiar:

• operações
• gestão
• decisão
• estratégia

Inclui:

• Pessoas
• Processos
• Tecnologia
• Dados

Continue

Funções de um Sistema de Informação

• Recolher dados

• Processar (filtrar, calcular, validar)

• Armazenar

• Distribuir informação

• Apoiar decisões

• Controlar operações

• Automatizar tarefas

Continue

Exemplo: Sistema de gestão de inventário de um armazém.

Continue

Componentes de um Sistema de Informação

• Pessoas – Utilizadores e técnicos que operam o sistema.
• Processos – Conjunto de regras e procedimentos.
• Dados – Informação bruta que será tratada.
• Tecnologia – Hardware e software que suportam o sistema.

Continue

Tipos de Sistemas de Informação

ERP

MRP

CRM

MRP (Material Requirements Planning) é um sistema de planeamento das necessidades de materiais, usado principalmente em empresas de produção e manufatura.

ERP (Enterprise Resource Planning) – sistema de gestão integrada que reúne num único software as principais funções e processos de uma empresa — como finanças, compras, vendas, produção, recursos humanos, logística, e contabilidade. Exemplos ERPs: SAP, Oracle, PHC, Primavera.

CRM – (Customer Relationship Management) é um sistema de gestão de relacionamento com clientes. O seu principal objetivo é organizar, automatizar e melhorar todas as interações que a empresa tem com clientes e potenciais clientes.

Continue

Qual a importância dos SI nas Organizações?

Continue

• Aumentam a eficiência e reduzem erros humanos.
• Facilitam o controlo e a tomada de decisão.
• Permitem integração de dados entre departamentos.
• Apoiam a inovação e competitividade.

Continue

Desvantagens.

• Dependência tecnológica
• Falhas técnicas
• Custos altos de implementação
• Segurança de dados
• Obsolescência
• Resistência dos utilizadore

Continue

Tendências atuais dos SI

• Inteligência Artificial
• Big Data
• Cloud Computing
• IoT
• Automação Robótica (RPA)
• Blockchain

Continue

Caso Prático

Dado um pequeno ginásio, identifique os SI que o podem ajudar.

• objetivos
• processos
• dados recolhidos
• utilizadores
• melhorias esperadas

Continue

Objetivos

• Aumentar a retenção de clientes
• Melhorar o atendimento e personalização dos treinos
• Automatizar tarefas administrativas
• Controlar pagamentos e acessos
• Monitorizar desempenho dos utilizadores

Continue

Processos

• Registo e inscrição de novos membros
• Gestão de mensalidades e pagamentos
• Controlo de acesso (entrada/saída)
• Marcação de aulas e personal trainers
• Gestão de equipamentos e manutenção
• Acompanhamento físico (pesagens, treinos, avaliações)
• Comunicação com clientes (notificações, avisos, promoções)

Continue

Dados Recolhidos

• Dados pessoais dos clientes (nome, idade, contacto)
• Registo biométrico ou cartão de acesso
• Registo de pagamentos e estado das mensalidades
• Histórico de treinos
• Resultados de avaliações físicas (peso, massa gorda, IMC…)
• Disponibilidade de salas, professores e equipamentos
• Estatísticas de utilização do ginásio

Continue

Utilizadores dos Sistemas

• Funcionários de receção
• Instrutores / Personal Trainers
• Clientes / Membros
• Gestor do ginásio
• Equipa de manutenção
• Sistema automático de controlo de acessos

Continue

Melhorias Esperadas com a Implementação de SI

• Redução de erros administrativos
• Check-in automático → menos filas na receção
• Maior controlo das mensalidades e redução de incumprimentos
• Treinos mais personalizados com base nos dados recolhidos
• Melhor planeamento de aulas e lotações
• Acompanhamento mais profissional e motivacional
• Melhor tomada de decisão através de dashboards (ex: horas de maior afluência)
• Comunicação mais eficaz com os clientes
• Aumento da satisfação e fidelização dos membros

Continue

Processo de Decisão e Recolha de Dados

Como os Sistemas de Informação suportam a tomada de decisão e como a recolha de dados influencia a qualidade dessas decisões.

Continue

Objetivos da Sessão

• Explicar as fases do processo de decisão
• Identificar os tipos de decisões numa organização
• Compreender a importância dos dados na decisão
• Reconhecer fontes de dados internas e externas

• Construir mapas de dados e necessidades informacionais

Continue

O Que É Uma Decisão?

Uma escolha consciente entre duas ou mais alternativas, feita para resolver um problema ou alcançar um objetivo.

Elementos de uma boa decisão

• Objetivo – O que quero alcançar?
• Opções – Que alternativas existem?
• Informação – Que dados tenho disponíveis para analisar?
• Consequências – O que pode acontecer com cada escolha?
• Critérios – O que é mais importante? (custo, tempo, qualidade…)

Numa empresa: Escolher um fornecedor com base no preço, qualidade e prazos de entrega. No dia a dia: Decidir se vais trabalhar de carro ou transporte público. Que decisões importantes temos numa oficina automóvel?

Continue

Por Que a Decisão É Importante?

• Tempo e eficiência
• Custos e lucro
• Satisfação do cliente
• Qualidade do serviço
• Cumprimento de prazos
• Reputação do negócio

Quando apoiadas por dados → melhores decisões, menos erros.

Continue

Continue

Continue

Tipos de Decisões

1. Decisões Programadas

2. Decisões Não Programadas

• Rotineiras
• Repetitivas
• Com regras claras

Exemplo?

• Complexas
• Envolvem análise e criatividade

Exemplo?

Continue

Níveis da Decisão

Nível Estratégico (Gestão de topo)

Nível Operacional (Dia-a-dia)

Nível Tático (Gestão intermédia)

• Decisões simples e repetidas

• Organização dos recursos
• Controlo das operações

• Planos a longo prazo
• Objetivos da organização
• Grandes investimentos

Continue

Fases do Processo de Decisão

• Inteligência — Identificar problema
• Modelação — Procurar soluções
• Escolha — Selecionar a melhor
• Implementação — Executar
• Avaliação — O resultado foi positivo?

Cliente reclama atraso → identificar causa → testar opções → mudar fluxo → medir impacto.

Continue

A Importância dos Dados

Sem dados → decisões subjetivas Com dados → decisões objetivas, rápidas e fundamentadas

DADOS PERMITEM:

• Reduzir incerteza
• Reconhecer padrões
• Criar previsões
• Medir desempenho
• Melhorar processos

Gestão de Stocks.

Continue

Tipos de Dados

1. Dados Quantitativos

2. Dados Qualitativos

• Numéricos
• Medidos

• Descritivos
• Observações

Continue

Estrutura dos Dados

• Dados brutos → sem tratamento
• Informação → dados processados
• Conhecimento → interpretação dos dados
• Sabedoria → ação baseada em conhecimento

Continue

Fontes Internas de Dados

As Fontes Internas de Dados são todos os dados que a organização já produz ou armazena no decorrer das suas operações diárias. Em qualquer organização, estas fontes são fundamentais para melhorar processos, apoiar decisões e otimizar o negócio.

• Dados Financeiros
• Dados de Cliente (CRM interno)
• Dados de Recursos Humanos
• Dados de Inventário / Armazém
• Dados de Sistemas Internos / Equipamentos
• Dados Operacionais (Produzidos pelas atividades diárias)

Continue

Dados Financeiros

Exemplos nas organizações:

• Faturas emitidas a clientes
• Custos de artigos e componentes
• Margem por tipo de serviço
• Pagamentos em atraso
• Fluxo de caixa mensal

Como são usados:

• Análise de rentabilidade
• Planeamento financeiro
• Ajuste de preços dos serviços

Continue

Dados de Inventário / Armazém

Informação sobre stocks e artigos. Exemplos:

• Quantidade de peças em armazém
• Entradas e saídas
• Tempo médio de reposição
• Peças mais usadas por tipo de serviço
• Fornecedores e prazos de entrega

Como são usados:

• Evitar ruturas de stock
• Identificar peças com baixa rotação
• Automatizar encomendas

Continue

Dados Operacionais (Produzidos pelas atividades diárias)

Incluem toda a informação gerada durante os serviços prestados. Exemplos:

• ?

Como são usados:

• ?

Continue

Exemplos reais na oficina: • Ordens de trabalho • Diagnósticos realizados • Checklists de manutenção • Registos de peças utilizadas • Tempos de execução por tarefa • Histórico de avarias por veículo Como são usados: • Previsão de necessidades de stock • Comparação entre tempo estimado vs. tempo real • Identificação de serviços que demoram mais que o esperado

Continue

Fontes Externas de Dados

As Fontes Externas de Dados são todas as informações obtidas fora da organização, mas que influenciam decisões, planeamento e operações do negócio.

• Fabricantes e Fornecedores de Peças
• Bases de Dados Técnicas e Manuais Oficiais
• Legislação e Normas
• Dados de Clientes em Plataformas Online
• Dados de Mercado e Tendências da Indústria
• Parceiros e Redes de Oficinas

Continue

Fabricantes e Fornecedores de Artigos

Os fabricantes são uma das principais fontes de dados externas.

Exemplos reais:

• Catálogos digitais de peças (Bosch, Monroe, Gates…)
• Tabelas de compatibilidades para cada modelo
• Prazos de entrega
• Listas de preços atualizadas
• Boletins técnicos de instalação

Utilidade:

• Encomendas mais rápidas e precisas
• Garantia de compatibilidade
• Planeamento de armazém com base em tempos de entrega

Continue

O Papel do Sistema de Informação na Recolha de Dados

Os Sistemas de Informação (SI) têm um papel central na forma como a organização capta, organiza e valida dados. Manualmente, a recolha de dados torna-se lenta, sujeita a erros e difícil de utilizar para tomar decisões.

Continue

Automatizam a Recolha de Dados Um SI evita que os dados sejam recolhidos manualmente, reduzindo erros e aumentando a velocidade.Exemplo: Atualização automática do stock quando uma peça é usada

Garantem Consistência e Padronização Os dados seguem sempre o mesmo formato, facilitando análises futuras. Exemplo: Campos obrigatórios: marca, modelo, matrícula

Continue

Recolhem Dados em Tempo Real Permitem decisões imediatas baseadas no estado atual da organização.Exemplo: Atualização imediata do estado da viatura (em diagnóstico, em reparação, concluído)

Reduzem a Recolha Duplicada e Erros HumanosO mesmo dado não é introduzido duas vezes. Exemplo: O cliente é registado uma vez e reutilizado em todas as ordens

Continue

Modelos de Decisão 1. Modelo Racional Baseado em dados e análise. 2. Modelo Intuitivo Experiência e instinto. 3. Modelo ComportamentalInfluenciado por emoções e limitações.

Continue

Exemplo Comparativo 1. Mecânico experiente (intuitivo): "A válvula EGR deve estar entupida." 2. SI / Dados (racional): Erro OBD P0401Pressão anormalHistórico similar no mesmo modelo

Continue

Erros Comuns na Decisão

• Dados incompletos
• Dados incorretos
• Dados desatualizados
• Viés de confirmação
• Subjetividade
• Falta de análise
• Pressão do tempo

Continue

Decidir Baseado Apenas na Intuição Depender apenas do “feeling” sem dados confiáveis.Exemplo na oficina: “Penso que vendemos muitas baterias… deve ser melhor encomendar mais.” → Mas os dados mostram que a procura é sazonal e está a baixar.

Continue

Depender Demasiado de Métricas Isoladas Tomar decisões olhando apenas para um indicador e não para o conjunto.Exemplo: Reduzir o preço da mão-de-obra porque a concorrência é mais barata. → mas sem analisar custos, produtividade e margem real.

Continue

Ferramentas de Apoio à Decisão As ferramentas de apoio à decisão ajudam gestores e equipas a analisar dados

1 . Dashboards e Sistemas de Reporting (BI)

Exemplos na Oficina Automóvel: – Tempo médio de reparação por tipo de serviço – Número de carros em fila / agendamentos do dia – Consumo de peças e stock crítico – Receita diária/semanal

2 - Sistemas de Gestão (ERP / CRM)

– ERP: gestão de stock, compras, faturação – CRM: histórico do cliente, recomendações de serviços, lembretes de revisões Exemplo real: lembrar automaticamente um cliente de trocar a correia de distribuição.

Continue

Mini Caso de Estudo A oficina recebe 40 carros por semana, mas apenas 28 são entregues no prazo. Como um SI pode ajudar?

• Identificação do Problema/Análise do Processo Atual.
• Levantamento dos Dados Necessários.
• Principais Fontes de Dados, internas e externas.
• Ferramentas de Apoio à Decisão Recomendadas.
• Benefícios Esperados.

Proposta?

Continue

Mini Caso de Estudo A oficina recebe 40 carros por semana, mas apenas 28 são entregues no prazo. Como um SI pode ajudar?

O problema:

• Atrasos constantes na entrega dos veículos.

• Repetição de erros no processo (peças em falta, diagnósticos incompletos).

• Queixas por falta de comunicação e prazos incorretos.

Continue

ANÁLISE DE SOFTWARE E RECOLHA DE REQUISITOS

É o momento em que entendemos o problema, os utilizadores, o contexto e definimos o que o sistema deve fazer — antes de programar.

Continue

Objetivos da Sessão

• Compreender o papel da Análise de Software
• Identificar e recolher requisitos essenciais
• Avaliar processos de negócio antes do desenvolvimento
• Elaborar documentação clara e útil

• Entender a importância da comunicação entre stakeholders

Continue

Porque existe? Porque é tão importante?

1. Evita Erros e Retrabalho (o maior custo dos projetos)

• 60% dos problemas em projetos de software vêm de requisitos mal definidos.
• Corrigir erros na fase de desenvolvimento custa até 10x mais do que os identificar na análise.
• Sistemas sem análise tornam-se caros, lentos de implementar e difíceis de manter.

2. Assegura que o Software Resolve o Problema Certo

• A análise garante que entendemos exatamente o processo atual, o que funciona mal e o que precisa de mudar.
• Sem ela, o sistema pode ficar “bonito, mas inútil”.

Continue

Porque existe? Porque é tão importante?

3. Melhora a Comunicação entre Equipas

• Traduz necessidades de negócio → linguagem clara para programadores.
• Evita mal-entendidos entre utilizadores, gestão e equipa técnica.

4. Reduz Custos e Aumenta o Retorno do Investimento (ROI) Planeamento correto evita funcionalidades desnecessárias. Garante que o software apoia diretamente os objetivos da organização.

➡️ Porque é que acham que tantos projetos falham por causa de uma má análise?

Continue

Antes de desenvolver, é preciso…

1. Compreender o Problema Real

• O utilizador descreve o que sente, mas nem sempre descreve o que precisa.
• Antes de pensar em software, é obrigatório perceber:
• Que dor queremos resolver?
• Quem sofre o problema?
• Quando acontece?
• Com que impacto no negócio?

“Se o cliente diz ‘o sistema é lento’, isso é um problema ou um sintoma?”

Continue

Antes de desenvolver, é preciso…

2. Mapear o Processo Atual (AS-IS)

• Identificar como as tarefas são feitas hoje — mesmo que mal feitas.
• Descobrir:
• Responsáveis
• Passos e decisões
• Exceções
• Ferramentas usadas
• Visualizar o processo ajuda a revelar falhas e redundâncias.

Exemplo: oficina automóvel → desde a chegada do cliente até à entrega da viatura: onde existem esperas? quem valida? quem regista?

Continue

Antes de desenvolver, é preciso…

3. Definir Objetivos Claros Não começar por “precisamos de um software novo”. Começar por:

• Queremos reduzir o tempo do processo em 30%
• Queremos evitar erros manuais
• Queremos maior transparência para os clientes
• Queremos registos que cumpram auditorias

Objetivos mal definidos produzem software inútil.

Continue

Antes de desenvolver, é preciso…

4. Recolher Requisitos de Forma Estruturada A análise exige perguntas e investigação:

• O que o sistema vai fazer (funcionais)?
• Como o sistema deve comportar-se (não funcionais)?
• Restrições, integrações, volumes, segurança, acessos…

Ferramentas úteis: entrevistas, workshops, questionários, observação, análise documental.

Continue

Antes de desenvolver, é preciso…

5. Entender os Utilizadores e o Contexto Mais importante que a tecnologia é quem a usa. É necessário identificar:

• Perfis de utilizadores (rececionista, mecânico, gestor…)
• Capacidades tecnológicas
• Tarefas mais críticas
• Frustrações atuais
• Prioridades individuais vs. empresariais

Pergunta crítica: “Quem vai usar isto todos os dias?”

Continue

Antes de desenvolver, é preciso…

6. Validar as Necessidades Antes de Começar Antes do programador tocar no teclado, validar:

• Estamos todos a falar do mesmo?
• As necessidades estão completas?
• Há algo contraditório?
• O que é prioridade?
• O que pode ficar para uma fase 2?

Sem validação → retrabalho → custos → atrasos → frustração.

Continue

O que são Requisitos?

Requisitos são declarações verificáveis sobre o que o sistema deve fazer (funcionais) ou como deve comportar-se (não funcionais).São um contrato: quem pede (negócio) e quem faz (equipa técnica) devem entender e aceitar o mesmo.

Continue

Por que são críticos?

• Evitam mal-entendidos entre utilizador e equipa técnica.
• Permitem estimar corretamente esforço, custos e prazos.
• Servem de base para testes (criterios de aceitação).
• Minimizar retrabalho e desperdício.

Tipos de requisitos

• Funcionais (O QUE): ações, processos e funcionalidades (ex.: “Sistema deve gerar orçamento”).
• Não funcionais (COMO): desempenho, segurança, usabilidade, disponibilidade (ex.: “Resposta < 3s”).
• Requisitos de domínio: regras ou restrições específicas do setor (ex.: normas ambientais).
• Requisitos de interface: integrações com outros sistemas (ex.: faturação automática para o software X).

Continue

Exemplos requisitos funcionais

• Criar ordens de reparação
• Registar entrada de viaturas
• Associar mecânico a um serviço
• Enviar SMS ao cliente quando a viatura está pronta
• Integrar com o software de faturação

Exemplos de requisitos não funcionais.

• Disponibilidade do sistema de 99,5%
• Página inicial carrega em < 2 segundos
• Backups automáticos diários
• A interface deve ser compatível com telemóveis

Continue

Como escrever um requisito bom (boas práticas)

Use regras e modelos para requisitos testáveis e claros:

• INVEST (User Stories): Independente, Negociável, Valiosa, Estimável, Pequena, Testável.
• SMART (para objetivos / NFs): Específico, Mensurável, Atingível, Relevante, Temporal.
• Formato recomendado (requisito funcional): “O sistema deve [verbo + objeto] [condição opcional]”.

Ex.: “O sistema deve gerar o orçamento detalhado (peças + mão de obra) ao guardar a ordem de serviço.”

Continue

Perguntas ESSENCIAIS para fazer aos stakeholders

Sobre o problema / contexto

• Qual é o problema que queremos resolver?
• Com que frequência ocorre? Qual o impacto?

Sobre a funcionalidade

• O que exatamente espera que o sistema faça? Pode dar um exemplo real?
• Que dados entram e que resultados espera receber?

Sobre exceções e regras

• O que acontece se faltar uma peça? E se o cliente recusar o orçamento?
• Existem tempos máximos aceitáveis (SLA)?

Continue

Perguntas ESSENCIAIS para fazer aos stakeholders

Sobre prioridades

• Qual é mais importante: tempo de resposta, segurança ou custo?
• Se tivermos de escolher, o que deve ficar para uma fase posterior?

Sobre utilizadores

• Quem usa isto hoje? Quem usará amanhã? Que proficiência têm com tecnologia?
• Quem valida/assina o resultado (quem aprova o orçamento)?

Sobre testes e aceitação

• Como vamos saber que isto funciona? Que prova aceitaria?
• Quais os critérios mínimos para considerar a funcionalidade aceite?

Continue

Critérios de aceitação (exemplos concretos)

Transforma um requisito numa check list testável: Requisito: “Gerar orçamento ao guardar ordem” Critérios:

• Inclui peças e mão de obra com preço unitário e subtotal.
• Calcula IVA automaticamente.
• Permite editar antes de enviar.
• Guarda versão com timestamp e autor.
• Envia notificação ao cliente (email/SMS) se solicitado.

Continue

Exemplos práticos (Oficina Automóvel)

Funcionais:

• RF-01: “O sistema deve criar uma ordem de serviço ao registar a entrada da viatura, com matrícula, cliente, km e observações.”
• RF-02: “O sistema deve sugerir peças compatíveis com base no modelo e ano da viatura.”

Não funcionais:

• RNF-01: “O tempo de resposta para carregar a ficha de viatura deve ser ≤ 2s.”
• RNF-02: “Os dados sensíveis do cliente devem estar encriptados em repouso (AES-256).”

Continue

Exemplos práticos (Oficina Automóvel)

Critérios de aceitação (RF-01):

• Ficha criada com todos os campos obrigatórios preenchidos;
• Ordem aparece imediatamente no dashboard do mecânico;
• ID da ordem gerado automaticamente;
• Histórico da ordem acessível pelo cliente.

Continue

Técnicas de Análise

• Fluxogramas
• Casos de Uso (UML)
• User Stories (métodos ágeis)

• Mockups e protótipos

Continue

Fluxogramas e Modelação

Um fluxograma é uma representação visual de um processo, mostrando passos, decisões, entradas e saídas de forma clara e sequencial.

Serve para:

• Compreender processos complexos
• Identificar falhas, redundâncias e desperdícios
• Comunicar de forma simples com qualquer utilizador
• Apoiar a análise e recolha de requisitos
• Criar bases para automatização de tarefas

Continue

Elementos Principais de um Fluxograma

• Início/Fim → indica onde o processo começa e termina
• Processo/Tarefa → ação executada
• Decisão → ponto onde há uma escolha (Sim/Não)
• Entrada/Saída → informação que entra ou sai
• Conectores → continuidade do fluxo
• Documentos/Registos → formulários, relatórios, ordens de trabalho

Continue

Fluxo recepção.

Continue

Casos de Uso

Um Caso de Uso descreve como um utilizador interage com o sistema para atingir um objetivo.

Inclui:

• Ator
• Objetivo
• Fluxo principal
• Fluxos alternativos
• Exceções

Qual o ator mais crítico numa oficina? Justifica.

Continue

Caso de Uso: Criar Orçamento de Reparação

Ator: MecânicoObjetivo: Orçamentar reparação de viatura Fluxo Principal:

1. Seleciona viatura
2. Regista problemas
3. Sistema sugere peças
4. Sistema calcula valores
5. Mecânico confirma
6. Orçamento é enviado ao cliente

Fluxo Alternativo: Peça não existe em stock → pedido sugerido automaticamente.

Continue

User Stories

As User Stories são descrições curtas e simples que representam uma necessidade real de um utilizador dentro do sistema. São usadas em métodos ágeis (Scrum, Kanban) para comunicar funcionalidades de forma clara, sem linguagem técnica complexa.

Formato:“Como [utilizador], quero [ação], para [benefício].”

Exemplos:

• Como mecânico, quero registar o tempo de trabalho, para garantir orçamentos corretos.
• Como cliente, quero receber notificações SMS, para acompanhar o estado da reparação.
• Como rececionista, quero gerar uma fatura automaticamente, para reduzir erros de digitação.

Continue

Mockups ou Prototipagem

Prototipar é criar uma versão simplificada, rápida e interativa do sistema antes de o desenvolver totalmente. Serve para testar ideias, validar requisitos e evitar erros caros.

Tipos de Protótipos : Protótipo de Baixa Fidelidade

• Rascunhos em papel Esboços simples (wireframes)
• Focado na navegação e estrutura
• Rápido de criar e fácil de alterar

Exemplo: Um desenho simples da interface da “Receção de Viaturas”.

Protótipo de Média Fidelidade Mais próximo do visual real Criado em ferramentas como Figma, Balsamiq, Miro Permite testar fluxos e interações básicas Exemplo: Ecrã clicável para registar uma nova intervenção na oficina.

Continue

Mockups ou Prototipagem

Exemplo aplicado à Oficina Automóvel Imaginem que a oficina quer um módulo para: “Registar veículos e abrir ordens de reparação.” Protótipo típico:

• Ecrã inicial → lista de viaturas
• Botão “Nova Receção”
• Formulário com matrícula, cliente, quilometragem
• Botão “Criar OR”
• Fluxo para anexar fotografias da viatura

O cliente pode testar e dizer: “Falta a opção de indicar o estado dos pneus.” “O campo dos danos devia aceitar fotos.” 👉 Estas correções são baratas, antes do código existir.

Quando usar protótipos?

• No início do projeto
• Quando há muitas incertezas
• Quando o cliente “não sabe o que quer”
• Para validar requisitos com utilizadores reais
• Para explicar o sistema à equipa de desenvolvimento

Continue

Mini Caso Prático — Sistema de Gestão de Ginásio Um ginásio local pretende modernizar o seu processo de gestão. Atualmente, os registos são feitos em Excel e papel. Querem um sistema de informação que permita:

• Gerir inscrições e mensalidades
• Controlar presenças
• Gerir aulas e horários
• Registar treinos personalizados
• Comunicar com os clientes

Tarefas

• 5 requisitos funcionais (RF)
• 3 requisitos não funcionais (RNF)
• 1 caso de uso
• 1 user story
• 1 fluxograma simples

Continue

Introdução à UML e Visual Paradigm

A importância da modelação no desenvolvimento de software Nesta sessão vamos:

• Introduzir a linguagem UML Perceber porque é essencial antes de programar
• Criar os primeiros diagramas

Continue

Objetivos da Sessão

• Entender a importância da modelação
• Explicar o que é a UML e para que serve
• Identificar os principais tipos de diagramas
• Ler e criar modelos simples

Continue

Porque Modelamos?

Modelamos para… ➡ Entender • ➡ Comunicar • ➡ Reduzir erros • ➡ Planear • ➡ Criar melhor software

Continue

1. Para Entender o Problema Antes de Criar a Solução

• Evita desenvolver algo errado ou incompleto.
• Ajuda a clarificar o que o cliente realmente quer — e não apenas o que “parece que quer”.
• Reduz ambiguidades e interpretações diferentes entre equipa, cliente e utilizadores.

2. Para Comunicar Melhor

• A modelação torna ideias visíveis.
• Diagramas permitem que programadores, analistas, gestores e clientes falem a mesma linguagem.
• Promove alinhamento entre todos, reduzindo falhas de comunicação.

3. Para Reduzir Riscos, Retrabalho e Custos

• Identifica problemas logo no início — quando ainda são baratos de resolver.
• Permite prever comportamentos, dependências e falhas antes de escrever qualquer linha de código.
• Diminui retrabalho, atrasos e frustração do cliente.

Continue

4. Para Organizar o Pensamento e Estruturar o Sistema

• Obriga o analista a pensar de forma lógica e sequencial.
• Torna o sistema mais simples de compreender, dividir, estimar e planear.
• Cria uma visão global e detalhada do que será construído.

5. Para Aumentar a Qualidade do Software

• Modelos melhoram a consistência entre requisitos, casos de uso e implementação.
• Facilita testes: a equipa sabe exatamente o que deve acontecer em cada cenário.
• Ajuda a garantir que o software cumpre o propósito e funciona bem.

6. Para Criar Documentação Útil e Duradoura

• Diagramas tornam-se documentação para:
• novas funcionalidades
• onboarding de novos programadores
• auditorias
• manutenção ao longo dos anos

Continue

O que é a UML?

(Unified Modeling Language) é uma linguagem padrão usada para modelar, visualizar e documentar sistemas de software, independentemente da tecnologia, linguagem de programação ou tipo de aplicação.

Continue

O que não é a UML?

❌ Não é uma linguagem de programação ❌ Não é uma metodologia de desenvolvimento ✔ É apenas uma forma de representar modelos que podem ser usados em Scrum, Waterfall, Kanban, XP, etc.

Continue

Para que Serve?

• Representa processos, regras, funcionalidades, arquiteturas e interações.
• Cria uma visão comum entre analistas, programadores, gestores, clientes e testers.
• Ajuda a passar do “problema” para uma solução organizada e estruturada

Porque foi criada?

• Antes da UML, cada empresa usava os seus próprios diagramas → muita confusão.
• A UML tornou a modelação unificada, compreensível e standard.
• Permite que qualquer pessoa da área entenda o modelo criado por outra equipa.

Continue

Os 3 Grandes Tipos de Diagramas da UML

Categoria O que representam Exemplos

Estruturais Como o sistema é composto Classes, Objetos, Pacotes

Comportamentais Como o sistema se comporta Casos de uso, Atividades, Sequência

Interação Como partes do sistema interagem Sequência, Comunicação

Continue

Benefícios de Usar UML

• Reduz erros e ambiguidades
• Melhora a comunicação entre equipas
• Acelera o desenvolvimento
• Serve como documentação de longo prazo
• Facilita testes e validação de requisitos

Continue

Exemplos onde sao usados

Nos bancos

• Modelos de risco para decidir aprovações de crédito.
• Fluxogramas de atendimento ao cliente.
• Modelos de dados para contas, cartões e movimentos.

Em aplicações do dia-a-dia Uber / Bolt:

• Modelo de procura vs. oferta para calcular “surge pricing”.

Netflix / YouTube:

• Modelos de recomendação baseados no comportamento do utilizador.
• Diagramas de fluxo interno de processamento de vídeo.

E-commerce (Amazon, Worten, etc.):

• Modelos de carrinho → pagamento → entrega.
• Fluxograma de devoluções e trocas.

Continue

Exemplos onde sao usados

Na saúde

• Processos de triagem num hospital.
• Modelos de dados do doente: histórico, exames, prescrições.
• Protocolos clínicos representados como fluxogramas.

Na vida pessoal

• Planeamento mensal de despesas (modelo financeiro pessoal).
• Organização de tarefas (Kanban, listas, prioridades).
• Preparação de refeições (diagramas simples: compra → preparo → conservação).

Sempre que precisas de organizar, explicar, simplificar ou prever algo → estás a modelar.

Continue

Tipos de Diagramas

Como representamos visualmente um sistema?

A UML oferece vários tipos de diagramas, cada um com um propósito específico. Todos servem para compreender melhor o sistema antes de o construir.

Continue

Tipos de Diagramas

Diagramas Estruturais (estáticos)

Representam a estrutura, os componentes e as relações do sistema.Mostram como “as coisas estão organizadas”.

Continue

Diagramas Estruturais

Mostram a estrutura do sistema: elementos, entidades, objetos e relações.

Diagrama de Classes Representa os “blocos” principais do sistema. Exemplos: Biblioteca Digital Classe: Livro

• título: “O Alquimista”
• ISBN: 978-972-23-1234-5
• ano: 1988

Continue

Diagramas Estruturais

Classe: Autor

• nome: Paulo Coelho
• nacionalidade: Espanhola

Classe: Utilizador

• nome: Sofia Mendes
• ID: 5502
• tipo: Estudante

Relações:

• Autor —< escreve >— Livro
• Utilizador —< requisita >— Livro

Diagrama de Classes.

Continue

Diagramas Comportamentais (o “comportamento” do sistema)

Descrevem como o sistema funciona ao longo do tempo e como os utilizadores interagem.

Mostra funcionalidades vistas pelos utilizadores.

Ele mostra:

• Quem usa o sistema (os atores).
• O que o sistema permite fazer (os casos de uso).
• Como cada ator interage com essas funcionalidades.

É uma visão macro — não mostra detalhes técnicos, mas sim o que o sistema faz do ponto de vista do utilizador.

Continue

Elementos principais

Atores São pessoas, sistemas externos ou dispositivos que interagem com o sistema. Exemplos:

• Utilizador (cliente)
• Administrador
• Sistema de Faturação (outro sistema)

Continue

Elementos principais

Casos de Uso São ações ou funcionalidades que o ator realiza no sistema. Exemplos:

• Criar Ticket
• Consultar Estado
• Atribuir Técnico
• Gerar Relatório

Continue

Elementos principais

Exemplo Sistema: Gestão de Tickets Atores:

• Cliente
• Técnico
• Administrador

Casos:

• Criar ticket
• Consultar ticket
• Fechar ticket
• Atribuir técnico

Continue

Actividades

Mostra fluxos de trabalho.

Exemplo (Processo de Check-in num Hotel):

• Cliente chega
• Rececionista confirma reserva
• (Decisão) Reserva encontrada?
• Não → Criar nova reserva
• Sim → Continuar
• Solicitar documento
• Emitir chave do quarto
• Finalizar check-in

Continue

Sequência

Mostra ordem das mensagens

Exemplo (Sistema de Bilhética de Metro): Objetos: Passageiro → Torniquete → Sistema Central → Cartão

1. Passageiro aproxima cartão
2. Torniquete lê chip
3. Torniquete envia pedido ao Sistema Central
4. Sistema Central verifica saldo
5. Se saldo OK → aprovar
6. Torniquete abre
7. Sistema Central regista viagem

Continue

Estados

Mostra o “ciclo de vida” de algo.

Exemplo (Estado de uma Encomenda Online):

1. Criada
2. Confirmada
3. Em preparação
4. Enviada
5. Em transporte
6. Entregue
7. Arquivada

(Com transições claras entre estados.)

Continue

Visual Paradigm

O que é o Visual Paradigm?

• Ferramenta líder de modelação UML, BPMN, ERD, SysML, ArchiMate…
• Usada por +300 000 empresas e universidades
• Versões: Community (grátis), Standard, Enterprise, Modeler
• Funciona em Windows, macOS e Linux

Continue

Visual Paradigm - Interface

• Project Browser (esquerda)
• Diagramas abertos (centro)
• Barra superior rápida

Continue

Visual Paradigm - New project

Passo a passo:

• Project → New

• Escolher Tipo UML
• Dar nome (ex: “Sistema Biblioteca”)
• Clicar “Create Blank Project”

Continue

Visual Paradigm - Tipos de diagramas mais usados

• Use Case Diagram
• Class Diagram
• Sequence Diagram
• Activity Diagram
• State Machine Diagram
• BPMN Business Process Diagram
• Entity Relationship Diagram (ERD)

Continue

Mini Caso Pratico

Sistema de Gestão de Reservas de Campos de Padel

Contexto do Caso Um centro desportivo dispõe de vários campos de padel que podem ser reservados pelos clientes. Os clientes podem consultar horários, fazer reservas e pagar. Os funcionários podem gerir campos, ver reservas e registar pagamentos presenciais. O sistema deve permitir operações simples, rápidas e acessíveis via web.

Continue

Mini Caso Pratico

Sistema de Gestão de Reservas de Campos de Padel

Requisitos Funcionais

• O sistema deve permitir que o cliente consulte horários disponíveis dos campos.
• O sistema deve permitir ao cliente efetuar uma reserva indicando data, hora e número de jogadores.
• O sistema deve enviar uma confirmação de reserva por e-mail.
• Os funcionários devem poder registar manualmente reservas presenciais.
• O sistema deve permitir ao cliente cancelar reservas até 2h antes do horário marcado.

Continue

Mini Caso Pratico

Sistema de Gestão de Reservas de Campos de Padel

Requisitos Funcionais

• O sistema deve permitir que o cliente consulte horários disponíveis dos campos.
• O sistema deve permitir ao cliente efetuar uma reserva indicando data, hora e número de jogadores.
• O sistema deve enviar uma confirmação de reserva por e-mail.
• Os funcionários devem poder registar manualmente reservas presenciais.
• O sistema deve permitir ao cliente cancelar reservas até 2h antes do horário marcado.

Continue

DIAGRAMAS DE CASOS DE USO

Continue

Objetivos da Sessão

• Compreender o que são Casos de Uso
• Identificar Atores e Interações
• Desenhar Diagramas de Casos de Uso
• Relacionar casos de uso (include, extend, generalização)

Continue

O que é um Caso de Uso?

Um caso de uso descreve como um utilizador (ator) interage com o sistema para atingir um objetivo.

O foco é sempre no que o utilizador quer fazer, não no funcionamento interno.

Continue

Não representa um..

• Não é um diagrama de fluxo
• Não mostra como o sistema funciona internamente
• Não mostra código nem base de dados
• Não representa layout de ecrãs

✔ É apenas sobre interações entre utilizadores e sistema.

Continue

A solução

• Descrevem a interação entre um ator e o sistema
• Foco no “O quê” e “Porquê”, não no “Como”
• Linguagem simples (quase natural)
• Servem de contrato entre cliente e equipa técnica

Continue

Erros mais comuns (e como evitar)

• Escrever tudo num único caso de uso gigante
• Misturar interface (botões, telas) dentro do caso de uso
• Esquecer fluxos alternativos e de exceção
• Usar Include/Extend sem critério

Continue

Onde são usados?Em que altura do processo?

• Levantamento de requisitos
• Comunicação com stakeholders
• Base para testes funcionais
• Base para prototipagem
• Definição do âmbito do projeto
• No desenvolvimento da documentação

Continue

Template oficial de Caso de Uso

• Nome do Caso de Uso
• Atores
• Objetivo
• Pré-condições
• Pós-condições (sucesso + falha)
• Casos de uso
• As ações/objetivos do ator.
• Relacionamentos
• Include, extend, generalização
• Fluxo Principal (passos numerados)
• Fluxos Alternativos (A1, A2…)
• Fluxos de Exceção (E1, E2…)

Continue

Atores: Exemplos. Quem são?

Pessoa ou sistema externo que interage com o nosso sistema

Exemplos no Padel:

• Cliente (ator principal em quase tudo)
• Funcionário
• Sistema de Pagamentos (ator secundário)
• Serviço de Email

• Cliente
• Administrador
• Funcionário
• Sistema Externo (ex: API de Pagamentos)
• Cron job / sistema de envio automático

Dica: Atores são sempre “fora” do sistema.

Continue

Como identificar atores?

Perguntas úteis:

✔ Quem usa o sistema?✔ Quem beneficia da funcionalidade?✔ Quem fornece informação ao sistema?✔ Quem recebe informação do sistema?

Continue

Pré-condições vs Pós-condições

Pré-condição = o que tem de estar verdadeiro ANTES Ex: “Cliente autenticado”, “Campo existe” Pós-condição de sucesso = o que fica verdadeiro DEPOIS Ex: “Reserva criada”, “Email enviado” Pós-condição de falha = o que fica verdadeiro se correr mal Ex: “Nenhum dado alterado”, “Mensagem de erro exibida”

Continue

Fluxo Principal = Caminho Feliz

Passos numerados 1, 2, 3…Ação do ator → Resposta do sistema (alternar) Verbo no presente, linguagem ativa Ex:

1. O cliente seleciona o horário
2. O sistema apresenta formulário de reserva

Continue

Fluxos Alternativos e de Exceção

A1 – Horário já não disponível E1 – Erro de ligação à base de dados Sempre referenciar em que passo “sai” do fluxo principa

Continue

Relação «include»

Quando um comportamento é usado por vários casos de usoEx: “Autenticar Utilizador” é incluído em quase todos → Evita repetição

Continue

Relação «extend»

Comportamento opcional ou condicional Ex: “Aplicar Desconto Promoção” estende “Efetuar Reserva” apenas se o cliente tiver código

Continue

Quando usar Include vs Extend?

Include → Obrigatório e reutilizável Extend → Opcional ou condicional

Continue

Notação visual básica - diagrama

Bonequinhos → Atores Ovais → Casos de uso Sistema → Caixa retangular Linhas → Associações

Continue

Exemplo Ginásio

Casos de Uso

Efetuar Check-in na Entrada Marcar Aula de Grupo Renovar Mensalidade Registar Novo Sócio (presencial) Comprar Produto na Loja (proteína, toalha, água…) Cancelar Inscrição no Ginásio Receber Lembrete de Aula (automático)

Continue

Exemplo Ginásio

Efetuar Check-in na Entrada Ator principal: Sócio Objetivo: Registar a entrada no ginásio Fluxo principal:

• Sócio aproxima o cartão ou QR code
• Sistema valida cartão ativo
• Sistema regista hora de entrada
• Torniquete/porta abre

Pós-condição: Entrada registada e sócio dentro do ginásio

Continue

Exemplo Ginásio

Marcar Aula de Grupo Ator principal: Sócio Objetivo: Reservar lugar numa aula (Crossfit, Zumba, Yoga…) Fluxo principal:

• Sócio faz login na app/site
• Escolhe dia e hora
• Seleciona aula disponível
• Sistema verifica lotação
• Reserva efetuada

Pós-condição: Sócio tem lugar reservado + recebe lembrete 1h antes

Continue

Exemplo Ginásio

Renovar Mensalidade Ator principal: Sócio Objetivo: Pagar o mês seguinte Fluxo principal:

• Sócio recebe notificação 5 dias antes do vencimento
• Acede à área de pagamentos
• Escolhe método (MB Way, cartão, débito direto)
• Efetua pagamento
• Sistema renova plano automaticamente

Pós-condição: Plano ativo por mais 30 dias

Continue

Exemplo Ginásio

Registar Novo Sócio (presencial) Ator principal: Rececionista Objetivo: Criar ficha de novo membro Fluxo principal:

• Rececionista preenche dados pessoais + foto
• Escolhe plano (Basic, Premium, Familiar…)
• Sócio assina contrato digital
• Sistema gera cartão/QR code

Pós-condição: Novo sócio fica ativo no sistema

Continue

Exemplo Ginásio

Comprar Produto na Loja (proteína, toalha, garrafa…) Ator principal: Sócio Objetivo: Comprar artigo na receção Fluxo principal:

• Sócio pede artigo
• Rececionista regista venda no POS
• Sócio paga (numerário, MB Way ou débito na mensalidade)
• Sistema atualiza stock

Pós-condição: Produto entregue e stock atualizado

Continue

Exemplo Ginásio

Cancelar Inscrição no Ginásio Ator principal: Sócio Objetivo: Dar baixa definitiva Fluxo principal:

• Sócio pede cancelamento com 30 dias de antecedência
• Preenche formulário de saída
• Sistema bloqueia renovação automática

Pós-condição: Plano termina no final do mês pago

Continue

Exemplo Ginásio

Receber Lembrete de Aula (automático) Ator principal: Sistema Objetivo: Enviar notificação 1 hora antes da aula marcada (Este é desencadeado pelo sistema – ator temporal)

Continue

Continue

Casos de Uso – Site de E-commerce

Pesquisar Produtos – Cliente Adicionar ao Carrinho – Cliente Finalizar Compra – Cliente Efetuar Pagamento – Cliente (include obrigatório) Criar Conta – Visitante → Cliente Fazer Login – Cliente Aplicar Cupão de Desconto – Cliente (extend opcional) Escolher Morada de Entrega – Cliente (include) Rastrear Encomenda – Cliente Pedir Devolução/Reembolso – Cliente (após entrega)

Continue

Continue

DIAGRAMAS DE CASOS DE USO - Pratica

Continue

Objetivos da Sessão

• Desenvolver Diagramas Casos de Uso
• Trabalho Prático

Continue

Diagramas de Classes (UML)

Continue

Objetivos da Sessão

• Explicar o que é um Diagrama de Classes
• Identificar classes, atributos e métodos
• Representar relações entre classes
• Compreender multiplicidades
• Ler e interpretar diagramas reais
• Criar um diagrama de classes no Visual Paradigm

Continue

O que é um Diagrama de Classes?

Um Diagrama de Classes é um diagrama da UML que representa a estrutura estática de um sistema. Ele mostra:

• Quais são as classes do sistema
• Que informação cada classe guarda
• Que comportamentos cada classe tem
• Como as classes se relacionam entre si

Continue

Para que serve um Diagrama de Classes?

• Traduz requisitos em estrutura técnica
• Apoia o desenho da base de dados
• Facilita a comunicação entre analistas e programadores
• Ajuda a evitar inconsistências
• Serve de base para desenvolvimento e testes

Se o diagrama de classes estiver errado, o sistema quase de certeza também estará.

Continue

Para que serve um Diagrama de Classes?

• Traduz requisitos em estrutura técnica
• Apoia o desenho da base de dados
• Facilita a comunicação entre analistas e programadores
• Ajuda a evitar inconsistências
• Serve de base para desenvolvimento e testes

Se o diagrama de classes estiver errado, o sistema quase de certeza também estará.

Continue

Relação com outros Diagramas

• Casos de Uso → dizem o que o sistema faz
• Diagramas de Classes → dizem com o quê o sistema é construído
• Diagramas de Sequência → mostram como as classes comunicam

Continue

O que é uma Classe?

Uma classe representa um conceito do mundo real ou do negócio.

Exemplos:

• Cliente
• Reserva
• Campo de Padel
• Fatura

Uma classe é como um molde que define como os objetos vão ser criados.

Continue

Elementos de uma Classe

Cada classe é composta por 3 partes:

Nome da Classe

• Identifica o conceito
• Deve ser claro e em singular

Exemplo: Reserva

Continue

Elementos de uma Classe

Cada classe é composta por 3 partes:

Atributos (dados)

• Informação que o sistema precisa guardar

Exemplo:

• data
• hora
• estado

Continue

Elementos de uma Classe

Cada classe é composta por 3 partes:

Métodos (ações)

• O que a classe pode fazer

Exemplo:

• confirmarReserva()
• cancelarReserva()

Continue

Relações entre Classes

Os diagramas de classes também mostram como as classes se ligam:

• Associação (ligação simples)
• Agregação (tem, mas pode existir sem)
• Composição (faz parte e depende)
• Herança (é um tipo de)

Estas relações ajudam a perceber:

• Dependências
• Regras do negócio
• Impacto de alterações no sistema

Continue

Associação (Exemplo Campo de Padel)

Uma associação representa uma ligação simples entre duas classes, indicando que objetos dessas classes estão relacionados, mas continuam a existir de forma independente.

Um Cliente pode efetuar reservas de um Campo de Padel.

• O cliente existe independentemente das reservas
• O campo existe mesmo que não esteja reservado
• A reserva liga temporariamente o cliente ao campo

Continue

Associação (Exemplo Campo de Padel)

Classes envolvidas Cliente

• idCliente
• nome
• email

CampoPadel

• idCampo
• numero
• tipo (Interior / Exterior)

Continue

Associação (Exemplo Campo de Padel)

Multiplicidades Indicam quantos objetos podem estar relacionados Um Cliente pode reservar vários campos ao longo do tempo Cliente 1 ─── 0..* CampoPadel Um Campo de Padel pode ser reservado por vários clientes, em horários diferentes CampoPadel 1 ─── 0..* Cliente

Continue

Agregação

A agregação é um tipo especial de associação que representa uma relação “tem um”, onde:

• As classes estão relacionadas
• Mas podem existir de forma independente

É uma relação fraca, representada por um losango branco (◇).

Continue

Exemplo no contexto do Padel

Um Clube de Padel possui vários Campos de Padel.

• O clube “tem” campos
• Os campos pertencem ao clube
• Mas um campo pode existir mesmo que o clube deixe de existir (por exemplo, mudança de gestão)

Relação de Agregação ClubePadel ◇────── CampoPadel

Continue

Interpretação prática

• Apagar o clube não apaga fisicamente os campos
• Os campos podem ser reassociados a outro clube
• Os campos não dependem totalmente do ciclo de vida do clube

Regra de ouro Se a “parte” pode existir sem o “todo”, então estamos perante agregação.

Continue

Composição

A composição é uma relação forte “parte de”, onde:

• Uma classe não pode existir sem a outra
• A parte depende totalmente do ciclo de vida do todo
• Se o todo é eliminado, as partes também são eliminadas

É representada por um losango preto (◆).

Continue

Composição - Exemplo no contexto do Padel

Uma Reserva faz parte de um Campo de Padel.

• A reserva não existe sozinha
• Só faz sentido existir associada a um campo
• Se o campo for removido do sistema, as reservas associadas deixam de existir

Relação de Composição CampoPadel ◆────── Reserva

Continue

Interpretação prática

• Não faz sentido manter reservas sem campo
• A reserva depende totalmente do campo
• O campo controla o ciclo de vida das reservas

Regra de ouro

Se a “parte” não pode existir sem o “todo”, então estamos perante composição.

Continue

Generalização (Herança)

A generalização (ou herança) é uma relação em que uma classe herda características de outra.

• Existe uma classe mais genérica (superclasse)
• Existem classes mais específicas (subclasses)
• As subclasses herdam atributos e métodos da superclasse

Continue

Exemplo no contexto do Padel

No sistema de gestão de um clube de padel, existem vários tipos de utilizadores. Todos partilham características comuns, mas têm comportamentos diferentes.

Utilizador (superclasse) idUtilizador nome email telefone Métodos comuns: autenticar() atualizarDados()

Cliente (subclasse) nivelJogo historicoReservas Métodos específicos: efetuarReserva() cancelarReserva()

Funcionario (subclasse) cargo horarioTrabalho Métodos específicos: registarReservaPresencial() gerirCampos()

Continue

Generalização (Herança)

Continue

Padel

Continue

Mini Caso Pratico - Diagrama de classes de um ginásio.

Classes Ginasio Socio Instrutor Sala Pagamento ReservarAula Aula Equipamento

Continue

Diagramas de Sequencia (UML)

Continue

Objetivos da Sessão

• Explicar o que é um Diagrama de Sequencia
• Entender o seu Papel
• Conhecer a notação UML
• Saber quando e como aplicar
• Criar diagramas corretos e legíveis

Continue

O que é um Diagrama de Sequência?

• É um diagrama UML de interação
• Representa como os elementos de um sistema comunicam entre si
• Mostra a ordem temporal das mensagens trocadas
• O tempo flui de cima para baixo
• Cada linha vertical representa a vida de um objeto ao longo do tempo

Continue

O que este diagrama responde?

• Quem comunica com quem?
• Em que ordem acontecem as ações?
• Que mensagens são trocadas?
• Em que momento cada objeto executa uma ação?

Continue

Quando usar Diagrama de Sequência?

• Detalhar um caso de uso
• Explicar lógica de negócio
• Descrever processos complexos
• Apoiar desenvolvimento e testes

Continue

O que NÃO mostra?

• Estrutura interna das classes
• Detalhes de implementação de código
• Algoritmos complexos

Em termos simples: Um diagrama de sequência é como uma história passo a passo que explica o que acontece primeiro, depois e no fim quando um utilizador ou sistema executa uma ação.

Continue

Componentes Principais

• Ator
• Objeto
• Linha de Vida (Lifeline)
• Mensagens
• Ativações

Continue

Ator

• Entidade externa ao sistema
• Pode ser humano ou outro sistema
• Inicia interações
• Representado por boneco ou nome

Ativação

• Retângulo fino sobre a lifeline
• Indica período de execução
• Pode haver ativações aninhadas
• Representa processamento

Objeto

• Instância de uma classe
• Notação: objeto:Classe
• Participa na troca de mensagens
• Representa parte interna do sistema

Mensagens

• Comunicação entre objetos
• Representadas por setas
• Ordem indica sequência temporal
• Podem ter parâmetros

Linha de Vida (Lifeline)

• Linha vertical tracejada
• Representa existência do objeto no tempo
• Começa quando o objeto é criado
• Termina quando é destruído

Tipos de Mensagens

• Síncronas
• Assíncronas
• Retorno
• Criação
• Destruição

Continue

Mensagem Síncrona

• Chamada de método
• Remetente fica bloqueado
• Seta cheia
• Muito comum em chamadas diretas

Mensagem Assíncrona

• Não bloqueia remetente
• Usada em eventos e filas
• Seta aberta
• Execução paralela possível

Continue

Mensagem de Retorno

• Resposta à chamada
• Representada por linha tracejada
• Opcional no diagrama
• Pode mostrar valores devolvidos

Mensagem de Destruição

• Finaliza existência do objeto
• Representada por um “X” Indica
• libertação de recursos

Mensagem de Criação

• Cria uma nova instância
• Seta aponta para início da lifeline
• Objeto passa a existir a partir daí

Continue

Fragmentos Combinados

• Controlam o fluxo do diagrama
• Representados por uma moldura
• Possuem operador lógico
• Tornam o diagrama mais expressivo

Continue

Fragmento ALT

Fragmento LOOP

• Representa alternativa (if / else)
• Cada bloco tem uma condição
• Apenas um fluxo é executado

• Repetição de mensagens
• Pode indicar condição
• Pode indicar número de iterações

Fragmento OPT

Fragmento PAR

• Opção simples (if)
• Executado apenas se condição for verdadeira
• Não existe alternativa

• Execução paralela
• Múltiplos fluxos simultâneos
• Muito usado em sistemas distribuídos

Continue

Continue

Continue

Continue

Continue

Continue

Mini Caso Pratico

Desenhar os diferentes diagramas para os seguintes caso de uso:

Login no Sistema

Processamento de Encomenda

Levantamento em ATM

Reserva de Voo + Hotel

Continue

Pratica

Desenhar os diferentes diagramas para os seguintes caso de uso da oficina:

Recepção Viatura

Reparação da Viatura

Continue

Diagramas de Actividades (UML)

Continue

Objetivos da Sessão

• Compreender o Diagrama de Atividades
• Identificar os seus componentes
• Modelar processos simples e complexos
• Aplicar o diagrama a casos reais
• Evitar erros comuns de modelação
• Desenhar Diagramas no Visual Paradigm

Continue

O que é um Diagrama de Atividades?

• O Diagrama de Atividades é um diagrama comportamental da UML
• Representa processos, fluxos de trabalho e sequências de ações
• Mostra o que acontece, em que ordem e sob que condições
• É semelhante a um fluxograma, mas com regras UML mais formais
• Foca-se no comportamento dinâmico

Continue

O que este diagrama descreve?

• As etapas de um processo
• A ordem de execução das atividades
• Decisões que alteram o caminho do processo
• Atividades paralelas que ocorrem ao mesmo tempo
• Responsabilidades de cada ator ou sistema

Continue

O que NÃO é o objetivo deste diagrama?

• Detalhar classes ou atributos
• Mostrar chamadas de métodos entre objetos
• Representar lógica técnica de código
• Substituir diagramas de sequência

Continue

Em termos simples: Um Diagrama de Atividades funciona como um fluxograma inteligente, que explica passo a passo o que acontece num processo, desde o início até ao fim.

Continue

Quando usar um Diagrama de Atividades?

• Para analisar requisitos funcionais
• Para explicar processos a pessoas técnicas e não técnicas
• Para documentar workflows de negócio
• Para identificar gargalos ou passos desnecessários

Continue

Exemplo de Processos

• Pedido de férias
• Compra online
• Marcação de campo de padel
• Abertura de ticket

Continue

Elementos do Diagrama de Atividades

• Nó inicial
• Atividade / Ação
• Fluxo de controlo
• Nó final
• Decisão
• Paralelismo
• Swimlanes

Continue

Nó Inicial

Um círculo preto preenchido, isolado Texto por baixo: Nó Inicial Explicação

• Indica onde o processo começa
• Existe apenas um por diagrama
• Não tem entradas, apenas saídas

Continue

Atividade / Ação

Retângulo com cantos arredondados Texto dentro: Validar Pedido Explicação Representa um passo do processo Deve usar verbo no infinitivo Ex.: “Verificar disponibilidade”, “Enviar email”

Continue

Fluxo de Controlo

Seta simples entre duas atividades Explicação Define a ordem de execução Liga atividades, decisões e nós

Continue

Nó Final

Círculo duplo (alvo) Texto: Fim do Processo Explicação Indica o término do fluxo Pode existir mais do que um Quando atingido, o processo termina

Continue

Nó de Decisão

Losango Duas ou mais setas de saída: [Sim] [Não] Explicação Representa uma escolha Apenas um caminho é seguido As saídas devem ter condições claras

Continue

Nó de Junção (Merge)

Losango Várias setas a entrar Uma seta a sair Explicação Junta caminhos alternativos Usado após decisões Não cria paralelismo

Continue

Paralelismo — Fork

Barra grossa horizontal Uma seta a entrar Duas ou mais setas a sair Explicação Divide o fluxo em atividades paralelas Todas começam ao mesmo tempo Ex.: “Enviar email” e “Atualizar sistema”

Continue

Sincronização — Join

Barra grossa horizontal Duas ou mais setas a entrar Uma seta a sair Explicação Junta fluxos paralelos O processo só continua quando todas terminam

Continue

Swimlanes (Pistas)

Diagrama dividido em colunas ou linhas Títulos no topo: Cliente Sistema Administrador Explicação Indicam quem é responsável por cada atividade Melhoram a leitura e organização Muito usadas em processos de negócio

Continue

Continue

10

Diagramas de Estados (UML)

Continue

Objetivos da Sessão

• Compreender o que é um Diagrama de Estados
• Identificar os seus componentes
• Saber quando utilizar este diagrama
• Modelar estados simples e complexos
• Analisar exemplos reais
• Desenhar Diagramas no Visual Paradigm

Continue

O que é um Diagrama de Estados?

Um Diagrama de Estados é um diagrama comportamental da UML que descreve os diferentes estados pelos quais um objeto, sistema ou entidade passa ao longo do seu ciclo de vida, bem como as transições entre esses estados, provocadas por eventos. Este diagrama responde essencialmente às perguntas:

• Em que estado o objeto se encontra?
• O que pode acontecer nesse estado?
• O que faz o objeto mudar de estado?

É especialmente útil quando o comportamento do sistema depende fortemente do estado atual.

Continue

Características principais

• Representa situações estáveis (estados)
• Mostra mudanças de estado (transições)
• É orientado a eventos
• Modela regras de negócio e ciclos de vida
• Foca-se num objeto ou entidade específica

Continue

Quando usar um Diagrama de Estados?

• Quando um objeto tem vários estados bem definidos
• Quando as ações possíveis dependem do estado atual
• Quando existem regras condicionais (ex.: só pagar se estiver reservado)
• Em sistemas reativos ou orientados a eventos

Continue

Elementos do Diagrama de Estados

• Estado
• Estado inicial
• Estado final
• Transição
• Evento
• Ação / Atividade

Continue

Estado

• Situação em que um objeto se encontra
• Tem significado no negócio
• Representado por retângulo arredondado
• Ex.: Pago, Em análise, Cancelado

Continue

Estado Inicial

• Indica o início do ciclo de vida
• Apenas um por diagrama
• Representado por círculo preenchido

Continue

Estado Final

• Indica o fim do ciclo de vida
• Pode haver vários
• Representado por círculo duplo

Continue

Transição

• Mudança de um estado para outro
• Representada por seta
• Geralmente ativada por um evento

Continue

Evento

• Algo que acontece no sistema
• Provoca a transição
• Ex.: Pagamento recebido, Cancelar pedido

Continue

Exemplos

Pedido Online

• Novo
• Pago
• Enviado
• Entregue
• Cancelado

Continue

Exemplos

Pedido de Suporte

• Aberto
• Em análise
• Em resolução
• Resolvido
• Fechado

Continue

Exemplos

Marcação de Campo de Padel

• Disponível
• Reservado
• Pago
• Cancelado
• Concluído

Continue

Estados Compostos

• Estados que contêm outros estados
• Permitem organizar complexidade
• Muito usados em sistemas grandes

Continue

Exemplo de Estado Composto

Pagamento

• Aguardando pagamento
• Pago
• Falhou

Continue

Estados Paralelos

• Permitem comportamento simultâneo
• Usam regiões paralelas
• Representam atividades independentes
• Só sai do estado paralelo quando todas as regiões terminarem.

Continue

Estados Paralelos

Quando usar?

• Quando há processos independentes
• Quando atividades ocorrem simultaneamente
• Quando o progresso de uma parte não bloqueia a outra

Continue

Estado composto: Em Processamento Dentro deste estado, ocorrem duas atividades em paralelo: Região 1 — Pagamento

• Aguardando confirmação
• Pagamento confirmado

Região 2 — Preparação da Encomenda

• Separar produtos
• Embalar pedido

📍 Ambos acontecem ao mesmo tempo.

Exemplo

Continue

Continue

Guardas (Condições)

• Condições associadas às transições
• Representadas entre []
• Ex.: [saldo suficiente]

Continue

Transições Internas

As transições internas representam eventos que ocorrem dentro de um estado, sem provocar mudança para outro estado. 👉 O objeto permanece no mesmo estado, mas executa uma ação associada ao evento.

Exemplo Pedido Online Estado: Pago Evento: enviarLembrete Ação: enviar email ao cliente O pedido continua no estado Pago

• Não alteram o estado atual
• São ativadas por eventos
• Executam ações internas
• Não disparam ações entry nem exit
• Mantêm o comportamento encapsulado no estado

Continue

Resumo

• Estados representam situações
• Transições mostram mudanças
• Eventos disparam comportamento
• Ideal para ciclos de vida

• Diagrama de Estados é essencial
• Muito usado em sistemas reais
• Facilita regras de negócio
• Complementa outros diagramas UML

Continue

Casos Praticos

• E-commerce – Ciclo de Vida de uma Encomenda
• Gestão de Projetos – Ciclo de Vida de uma Tarefa num Software de Gestão (ex: Jira/Trello)
• Processo de Entrada de um Sócio num Ginásio (check-in / acesso às instalações).
• Automotivo – Sistema de Ar Condicionado do Carro

Continue

11

RGPD – Regulamento Geral sobre a Proteção de Dados

Continue

Objetivos da Sessão

• O que é o RGPD
• Porque é importante
• Como cumprir
• Impacto nas organizações

Continue

O Que é o RGPD?

• Definição: Regulamento (UE) 2016/679, aprovado em 2016 e em vigor desde 25 de maio de 2018.

• Objetivo: Proteger os dados pessoais dos cidadãos da UE, harmonizando leis de privacidade em 27 países membros + EEE (Espaço Economico Europeu).

• Âmbito: Aplica-se a qualquer entidade que processe dados de residentes da UE, independentemente da localização (extraterritorialidade).

Continue

Por Que Foi Criado?

• Contexto: Crescimento da economia digital, escândalos como Cambridge Analytica (2018).

• Substitui a Diretiva 95/46/CE, que era fragmentada.

• Foco em direitos individuais na era da IA, big data e redes sociais.

Continue

Diferenças com Leis Anteriores

• Tabela comparativa: Diretiva 95/46 vs. RGPD (ex.: multas mais altas, DPO( Data Protection Officer) obrigatório, consentimento explícito).

• Atualizações recentes (2026): Integração com IA Act (2024) e Digital Services Act (2022).

Continue

História e Evolução do RGPD

• 1950: Convenção Europeia dos Direitos Humanos (Artigo 8: Direito à privacidade).

• 1995: Diretiva de Proteção de Dados.
• 2012-2016: Negociações e aprovação.
• 2018: Entrada em vigor.
• Pós-2018: Decisões do TJUE (ex.: Schrems II em 2020, invalidando Privacy Shield).
• 2024-2026: Adaptações para IA e dados biométricos.

Continue

Impacto Global

• Influenciou leis como LGPD (Brasil, 2020), CCPA (Califórnia, 2018) e PDPA (Singapura).
• Exemplos: Empresas como Google e Meta multadas em bilhões.

Continue

Princípios Fundamentais do RGPD

Os 7 Princípios Chave (Artigo 5)

1. Legalidade, lealdade e transparência.
2. Limitação das finalidades.
3. Minimização dos dados.
4. Exatidão.
5. Limitação da conservação.
6. Integridade e confidencialidade.
7. Responsabilização (accountability).

Continue

Direitos dos Titulares de Dados

Visão Geral dos Direitos (Artigos 12-23) Lista: Acesso, retificação, remover os dados, restrição, portabilidade, oposição, decisões automatizadas.

Continue

Obrigações dos Responsáveis e Subcontratantes

Definições Responsável pelo Tratamento (Controller): Decide o "porquê" e "como" (ex.: empresa que recolhe os dados).Subcontratante (Processor): Processa por conta do responsável (ex.: serviço de cloud).

Continue

Obrigações dos Responsáveis e Subcontratantes

Obrigações Principais

• Consentimento (Artigo 7): Explícito, livre, revogável.
• Avaliação de Impacto (DPIA, Artigo 35): Para tratamentos de alto risco.
• Registros de Atividades (Artigo 30).
• Notificação de Violações (Artigo 33-34): 72 horas para autoridade.
• Exemplos: Uso de cookies em sites (necessidade de banner de consentimento).
• Tabela: Diferenças entre Controller e Processor.

Continue

Violações de Dados

Definição: Perda, alteração ou acesso não autorizado. Procedimentos: Notificação à CNPD (Portugal) ou EDPB. Exemplos: Equifax (2017, multa de €100M+), TikTok (2023, violações com dados de menores).

Continue

Importância do RGPD

Para Indivíduos: Empodera contra abuso de dados, promove confiança na digitalização. Para Empresas: Evita riscos financeiros/reputacionais, fomenta inovação ética (ex.: privacy by design). Sociedade: Reduz desigualdades digitais, integra com sustentabilidade (dados como recurso). Impacto Econômico: Estudo da UE estima €2.3B em benefícios anuais.

Continue

Casos Reais

Caso 1: Google Analytics (violações em transferências, decisão austríaca 2022). Caso 2: Hospital Português multado por acesso indevido (CNPD, 2020). Caso 3: IA e RGPD (ex.: ChatGPT sob escrutínio em 2023-2025).

Continue

Melhores Práticas

Implementar Privacy by Design/Default (Artigo 25). Treinamentos internos, auditorias regulares. Ferramentas: Uso de software como OneTrust ou políticas de dados.

Continue

Igualdade de Género em Portugal (2025) – Um Direito Fundamental que se cruza com a Proteção de Dados

Portugal no Índice de Igualdade de Género (EIGE 2025) Pontuação: 63,4 / 100 (igual à média da UE-27) Posição: 10.º lugar na União Europeia (subiu 5 posições!) Progresso desde 2015: +9,1 pontos (principalmente no domínio do Poder) Domínios Principais:

• Trabalho → 74,9 pontos (6.º lugar na UE)
• Dinheiro → 79,9 pontos
• Saúde → 80,6 pontos
• Poder → 36,8 pontos (grande melhoria recente)
• Conhecimento → 55,5 pontos
• Tempo → 67,0 pontos

Continue

Igualdade de Género em Portugal (2025) – Um Direito Fundamental que se cruza com a Proteção de Dados

O RGPD protege dados pessoais sensíveis relacionados com género, orientação sexual e saúde reprodutiva → ajuda a combater discriminação algorítmica e violações de privacidade que afetam desproporcionalmente mulheres e minorias de género. Princípios comuns: Transparência • Não discriminação • Accountability • Proteção de direitos fundamentais. "A igualdade de género não é só um direito humano – é também uma questão de proteção de dados justos e éticos na era digital."

Continue

Desenvolvimento Sustentável

Processo de crescimento que atende o presente sem comprometer o futuro

Como os Sistemas de Informação impulsionam isso?

• Eficiência Energética → Green Computing: Data centers com energia 100% renovável (ex.: >70% em Portugal)
• Dados para Decisões Verdes → Big Data + IA para monitorar emissões, otimizar recursos e relatórios ESG
• Economia Circular Digital → Blockchain e IoT para rastrear materiais e reduzir desperdício
• Transparência e Accountability → Sistemas de informação garantem relatórios fiáveis (ex.: pegada de carbono digital)
• Tendências 2025/2026 → IA verde, software sustentável e Green Digital Action Hub (COP30 legado)

Continue

FIM

Continue

Centraliza informações sobre contactos, histórico de compras, comunicações e oportunidades de negócio. Ajuda as equipas de vendas, marketing e apoio ao cliente a trabalharem de forma coordenada. Permite acompanhar o ciclo de vida do cliente, desde o primeiro contacto até à fidelização. 📈 Principais benefícios: Melhora o atendimento e a experiência do cliente. Aumenta as vendas e a retenção. Facilita o acompanhamento de leads e campanhas. Fornece relatórios e métricas para apoiar decisões estratégicas. 🔹 Exemplos de CRMs populares: Salesforce, HubSpot, Zoho CRM, Pipedrive, Dynamics 365.

Calcula quando e quanto comprar ou produzir. Baseia-se em três dados principais: 1. Plano de produção (o que e quando se vai produzir) 2. Listas de materiais (BOM – Bill of Materials) 3. Stocks atuais e encomendas em curso Ajuda a otimizar o inventário, reduzir custos e melhorar prazos de entrega.

Um Sistema de Informação (SI) é um conjunto organizado de pessoas, processos, dados e tecnologias que trabalham em conjunto para recolher, processar, armazenar e distribuir informação.

Centraliza informações sobre contactos, histórico de compras, comunicações e oportunidades de negócio. Ajuda as equipas de vendas, marketing e apoio ao cliente a trabalharem de forma coordenada. Permite acompanhar o ciclo de vida do cliente, desde o primeiro contacto até à fidelização. 📈 Principais benefícios: Melhora o atendimento e a experiência do cliente. Aumenta as vendas e a retenção. Facilita o acompanhamento de leads e campanhas. Fornece relatórios e métricas para apoiar decisões estratégicas. 🔹 Exemplos de CRMs populares: Salesforce, HubSpot, Zoho CRM, Pipedrive, Dynamics 365.

Centraliza informações sobre contactos, histórico de compras, comunicações e oportunidades de negócio. Ajuda as equipas de vendas, marketing e apoio ao cliente a trabalharem de forma coordenada. Permite acompanhar o ciclo de vida do cliente, desde o primeiro contacto até à fidelização. 📈 Principais benefícios: Melhora o atendimento e a experiência do cliente. Aumenta as vendas e a retenção. Facilita o acompanhamento de leads e campanhas. Fornece relatórios e métricas para apoiar decisões estratégicas. 🔹 Exemplos de CRMs populares: Salesforce, HubSpot, Zoho CRM, Pipedrive, Dynamics 365.

Calcula quando e quanto comprar ou produzir. Baseia-se em três dados principais: 1. Plano de produção (o que e quando se vai produzir) 2. Listas de materiais (BOM – Bill of Materials) 3. Stocks atuais e encomendas em curso Ajuda a otimizar o inventário, reduzir custos e melhorar prazos de entrega.