Documentação UML

1. Visão Geral do Sistema

O sistema PsiCare é uma plataforma SaaS para gestão de clínicas psicológicas. O foco principal é a segurança dos dados (LGPD), agilidade no agendamento e registro clínico estruturado. Esta documentação apresenta os diagramas UML que modelam a estrutura e comportamento do sistema.

Escopo da Modelagem

Diagrama de Casos de Uso - Funcionalidades e atores
Diagrama de Classes - Estrutura de dados e relacionamentos
Diagrama de Sequência - Fluxo temporal de operações
Diagrama de Atividade - Fluxos de processo
Diagrama de Componentes - Arquitetura do sistema

2. Diagrama de Casos de Uso

Este diagrama ilustra as interações entre os atores (Psicólogo, Paciente, Administrador) e as funcionalidades do sistema. Cada caso de uso representa uma funcionalidade completa que entrega valor ao usuário.

usecaseDiagram actor "👨‍⚕️ Psicólogo" as P actor "👤 Paciente" as PA actor "👨‍💼 Administrador" as A package "📦 Sistema PsiCare" { usecase "📅 Gerenciar Agenda" as UC1 usecase "📋 Emitir Prontuário" as UC2 usecase "📹 Realizar Teleconsulta" as UC3 usecase "💰 Gerenciar Financeiro" as UC4 usecase "👁️ Visualizar Prontuário" as UC5 usecase "📝 Agendar Consulta" as UC6 usecase "⚙️ Configurar Sistema" as UC7 usecase "👥 Cadastrar Paciente" as UC8 } P --> UC1 P --> UC2 P --> UC3 P --> UC4 P --> UC5 P --> UC8 PA --> UC6 PA --> UC5 PA --> UC3 A --> UC7 A --> UC4 A --> UC8

Legenda

👨‍⚕️ Psicólogo: Profissional que utiliza o sistema para gestão clínica completa

👤 Paciente: Usuário final que agenda consultas e acessa seu prontuário

👨‍💼 Administrador: Responsável pela configuração e financeiro da clínica

3. Diagrama de Classes

Representação da estrutura de dados e relacionamentos entre as entidades principais. Note a relação de composição entre Psicologo e Prontuario, e a herança entre Usuario e suas especializações.

classDiagram class Usuario { +int id +string nome +string email +string senhaHash +date createdAt +login() +logout() +updateProfile() } class Psicologo { +string crp +string especialidade +float valorConsulta +string endereco +gerarRelatorio() +exportarDados() } class Paciente { +string dataNascimento +string telefone +string endereco +string anamnese +string status +getHistorico() } class Prontuario { +int id +string evolucao +date dataSessao +bool sigiloso +string observacoes +criarEvolucao() +editarEvolucao() +exportarPDF() } class Agenda { +int id +date data +time horaInicio +time horaFim +string tipo +string status +confirmar() +cancelar() +reagendar() } class Pagamento { +int id +float valor +string status +string metodo +date dataVencimento +processarPagamento() +emitirRecibo() } Usuario <|-- Psicologo Usuario <|-- Paciente Psicologo "1" *-- "0..*" Prontuario : possui Paciente "1" *-- "0..*" Prontuario : possui Psicologo "1" *-- "0..*" Agenda : gerencia Paciente "1" *-- "0..*" Agenda : participa Agenda "1" --> "0..1" Pagamento : gera

Relacionamentos Importantes

Herança (--|>): Psicólogo e Paciente herdam de Usuário
Composição (*--): Prontuário pertence a Psicólogo e Paciente
Associação (-->): Agenda gera Pagamento (opcional)
Multiplicidade: 1 psicólogo tem 0..* prontuários, 1 paciente tem 0..* agendas

4. Diagrama de Sequência (Fluxo de Agendamento)

Detalha a interação temporal entre o Paciente, a Interface, a API e o Banco de Dados durante o processo de marcar uma consulta. Mostra a sequência exata de mensagens trocadas entre os objetos do sistema.

sequenceDiagram autonumber participant P as 👤 Paciente participant UI as 🖥️ Interface Web participant API as ⚙️ API Backend participant DB as 💾 Banco de Dados participant Email as 📧 Serviço de E-mail P->>UI: Seleciona Horário Disponível UI->>API: POST /api/agendamentos (dados) API->>DB: Verificar disponibilidade DB-->>API: Horário Livre ✅ API->>DB: Salvar Agendamento DB-->>API: Sucesso (ID: 123) API->>Email: Enviar confirmação Email-->>API: E-mail enviado ✅ API-->>UI: Retorna Confirmação UI->>P: Exibe Mensagem de Sucesso UI->>P: Envia E-mail de Confirmação

Explicação do Fluxo

Paciente seleciona horário na interface
Interface envia dados para API via POST
API verifica disponibilidade no banco de dados
Se disponível, salva o agendamento
API solicita envio de e-mail de confirmação
Confirmação é retornada para interface e paciente

5. Diagrama de Atividade (Fluxo de Atendimento)

Fluxograma lógico das etapas que o psicólogo percorre durante uma sessão clínica no sistema. Inclui decisões, paralelismo e pontos de sincronização.

flowchart TD Start([🟢 Início da Sessão]) --> CheckPac{Paciente
Presente?} CheckPac -- ❌ Não --> Cancel[Cancelar/
Remarcar] CheckPac -- ✅ Sim --> OpenPront[Abre
Prontuário] OpenPront --> Review[Revisar Sessão
Anterior] Review --> Session[Realizar
Atendimento] Session --> Notes[Redigir
Evolução] Notes --> Save{Salvar
Dados?} Save -- ✅ Sim --> Encrypt[Criptografar
Registro] Save -- ❌ Não --> Notes Encrypt --> Log[Registrar
Log de Auditoria] Log --> Notify[Notificar
Paciente] Notify --> Finish([🔴 Fim da Sessão]) Cancel --> Finish style Start fill:#38a169,color:white style Finish fill:#e53e3e,color:white style Encrypt fill:#2c7a7b,color:white style Log fill:#d69e2e,color:white

Pontos de Segurança

Criptografar Registro: Dados sensíveis são criptografados antes de salvar
Registrar Log: Toda ação é auditada para conformidade LGPD
Decisão de Salvamento: Psicólogo pode revisar antes de confirmar

6. Diagrama de Componentes (Arquitetura)

Visão macro da arquitetura do software, separando Frontend, Backend e Serviços Externos. Utiliza notação C4 para clareza na comunicação entre componentes.

C4Context title Diagrama de Contexto do Sistema PsiCare Person(psicologo, "👨‍⚕️ Psicólogo", "Profissional que utiliza o sistema para gestão clínica.") Person(paciente, "👤 Paciente", "Usuário final que agenda consultas e acessa portal.") Person(admin, "👨‍💼 Administrador", "Responsável pela configuração e financeiro da clínica.") System_Boundary(b1, "📦 PsiCare System") { Container(web_app, "🖥️ Aplicação Web", "HTML5/CSS3/JS", "Interface principal para todos os usuários.") Container(api, "⚙️ API REST", "Node.js/Python", "Regras de negócio e autenticação.") ContainerDb(db, "💾 Banco de Dados", "PostgreSQL", "Armazenamento de dados clínicos e usuários.") ContainerDb(files, "📁 Object Storage", "AWS S3", "Armazenamento seguro de documentos e anexos.") } System_Ext(email, "📧 Serviço de E-mail", "SendGrid/AWS SES", "Envio de lembretes e recuperações.") System_Ext(payment, "💳 Gateway de Pagamento", "Stripe/Pagar.me", "Processamento de cartões.") System_Ext(video, "📹 Videoconferência", "Zoom/Google Meet", "Consultas online.") Rel(psicologo, web_app, "Utiliza", "HTTPS") Rel(paciente, web_app, "Agenda/Acessa", "HTTPS") Rel(admin, web_app, "Gerencia", "HTTPS") Rel(web_app, api, "Consome", "JSON/HTTPS") Rel(api, db, "Lê/Escreve", "SQL") Rel(api, files, "Upload/Download", "HTTPS") Rel(api, email, "Envia Notificações", "SMTP") Rel(api, payment, "Processa Transações", "API") Rel(api, video, "Gera Links", "API")

Componentes Principais

🖥️ Aplicação Web: Frontend responsivo acessível via navegador

⚙️ API REST: Backend que processa regras de negócio

💾 Banco de Dados: PostgreSQL para dados estruturados

📁 Object Storage: AWS S3 para documentos e anexos

7. Resumo da Modelagem UML

Diagrama	Propósito	Público-Alvo	Status
Casos de Uso	Funcionalidades e atores do sistema	Stakeholders, Analistas	Completo
Classes	Estrutura de dados e relacionamentos	Desenvolvedores, DBA	Completo
Sequência	Fluxo temporal de operações	Desenvolvedores Backend	Completo
Atividade	Fluxos de processo e decisões	Analistas de Negócio	Completo
Componentes	Arquitetura e integrações	Arquitetos, DevOps	Completo

Benefícios da Modelagem UML

Comunicação clara: Diagramas facilitam entendimento entre equipe e stakeholders
Documentação viva: UML serve como referência durante todo o ciclo de vida
Detecção precoce de erros: Problemas de design são identificados antes da codificação
Manutenibilidade: Nova equipe entende o sistema rapidamente através dos diagramas