Objetivo da atividade

Segundo Pressman & Maxim, modelos ajudam a representar aspectos relevantes do sistema durante a análise e o projeto. Em Sommerville, diferentes modelos representam diferentes perspectivas de um mesmo sistema. Nesta atividade, vocês trabalharão com duas perspectivas:

• fluxo do processo;
• interações entre participantes ao longo do tempo.

Parte 1: Tutorial rápido de PlantUML

Antes da atividade prática, vocês irão aprender somente o necessário para construir os dois diagramas pedidos.

O objetivo não é dominar PlantUML, mas aprender uma forma simples de transformar uma representação textual em um diagrama.

1.1. Estrutura básica

Todo código PlantUML começa e termina com:

@startuml

' conteúdo do diagrama

@enduml

O código pode ser escrito em um editor PlantUML ou em ferramentas compatíveis.

1.2. Diagrama de Atividades

Um Diagrama de Atividades representa o fluxo de um processo.

Exemplo

@startuml

start

:Receber solicitação;

if (Solicitação válida?) then (sim)
    :Processar solicitação;
else (não)
    :Informar erro;
endif

stop

@enduml

Elementos mínimos

Pergunta que esse modelo responde

Qual é o fluxo do processo e quais caminhos diferentes podem ocorrer?

1.3. Diagrama de Sequência

Um Diagrama de Sequência representa quem interage com quem e em qual ordem.

Exemplo

@startuml

actor Usuario
participant Sistema
participant Servico

Usuario -> Sistema : solicitar operação
Sistema -> Servico : verificar informação
Servico --> Sistema : resultado
Sistema --> Usuario : apresentar resultado

@enduml

Elementos mínimos

Pergunta que esse modelo responde

Quem interage com quem, e em qual ordem, para realizar um cenário?

1.4. O papel do PlantUML

PlantUML transforma uma descrição textual do diagrama em uma representação gráfica.

Por exemplo, o PlantUML consegue desenhar:

Estudante -> Sistema : solicitar reserva

Mas ele não sabe sozinho se:

• Estudante deveria aparecer;
• Sistema é um participante adequado;
• a mensagem está na ordem correta;
• a interação realmente existe nos requisitos.

Essas decisões são de modelagem e continuam sendo responsabilidade do grupo.

Parte 2: Atividade prática

Cenário: Sistema de Reserva de Salas

A universidade disponibiliza um sistema para que estudantes reservem salas para atividades acadêmicas.

Um estudante pode consultar as salas disponíveis para uma determinada data e horário. Depois de escolher uma sala, informa o período desejado e solicita a reserva.

O sistema verifica novamente se a sala está disponível naquele período.

Se a sala não estiver disponível, o sistema informa o conflito e permite que o estudante escolha outra sala.

Algumas salas de uso especial exigem aprovação. Quando uma dessas salas é solicitada, a reserva é registrada como pendente e encaminhada para um administrador. O administrador pode aprovar ou rejeitar a solicitação.

Para as demais salas, a reserva é confirmada imediatamente.

Quando uma reserva é confirmada, o estudante recebe uma notificação de confirmação. Caso uma solicitação seja rejeitada pelo administrador, o estudante também deve ser notificado.

Diagrama de Casos de Uso fornecido

O diagrama abaixo é uma das entradas da atividade.

Vocês não precisam recriá-lo.

@startuml
left to right direction

actor "Estudante" as Estudante
actor "Administrador" as Admin

rectangle "Sistema de Reserva de Salas" {

    usecase "Consultar salas\ndisponíveis" as UC1
    usecase "Solicitar\nreserva" as UC2
    usecase "Consultar situação\nda reserva" as UC3
    usecase "Avaliar solicitação\nde reserva" as UC4

}

Estudante -- UC1
Estudante -- UC2
Estudante -- UC3

Admin -- UC4

@enduml

O laboratório deverá se concentrar principalmente no caso de uso:

Solicitar reserva

Missão 1: Diagrama de Atividades

Criem um Diagrama de Atividades em PlantUML para representar o processo de solicitação de uma reserva.

O modelo deve deixar claro, no mínimo:

• início da solicitação;
• escolha da sala e do período;
• verificação da disponibilidade;
• o que acontece quando existe conflito;
• decisão sobre necessidade de aprovação;
• aprovação ou rejeição, quando necessária;
• confirmação da reserva;
• notificação ao estudante;
• término do processo.

Não é necessário representar telas, botões ou detalhes de implementação.

Pergunta que o modelo deve responder

Qual é o fluxo seguido por uma solicitação de reserva e quais caminhos diferentes ela pode percorrer?

Uso do LLM na Missão 1

O grupo deve usar um LLM como apoio.

Etapa A: interpretação antes da geração

Antes de pedir código PlantUML, peçam ao LLM para analisar o cenário.

Exemplo:

Estamos modelando o sistema descrito abaixo.

Antes de produzir qualquer código PlantUML:

1. identifique as atividades;
2. identifique as decisões;
3. identifique os caminhos alternativos;
4. indique informações que não estejam explícitas nos requisitos;
5. não invente funcionalidades.

Depois apresente sua proposta de estrutura para um Diagrama de Atividades.

[COLE A DESCRIÇÃO DO SISTEMA]

Etapa B: geração em PlantUML

Depois da análise:

Agora gere o Diagrama de Atividades em PlantUML.

Use apenas:
- start/stop;
- atividades;
- if/else/endif.

Mantenha o diagrama simples e baseado somente nos requisitos fornecidos.

Etapa C: revisão

Antes de aceitar o modelo:

Revise o código PlantUML gerado.

Para cada elemento do diagrama:
- indique qual trecho dos requisitos justifica sua existência;
- destaque qualquer suposição ou decisão de modelagem.

Missão 2: Diagrama de Sequência

Criem um Diagrama de Sequência em PlantUML para o cenário específico abaixo:

Um estudante solicita uma sala de uso especial. A sala está disponível, mas a reserva precisa ser aprovada pelo administrador. O administrador aprova a solicitação e o estudante recebe a confirmação.

Vocês podem considerar, por exemplo:

Estudante
Sistema de Reservas
Administrador
Serviço de Notificação

Outras decomposições são aceitas, desde que façam sentido e sejam justificadas.

O diagrama deve mostrar:

• quem inicia a interação;
• a ordem das interações;
• a verificação da disponibilidade;
• o encaminhamento para aprovação;
• a decisão do administrador;
• a confirmação;
• a notificação ao estudante.

Pergunta que o modelo deve responder

Quem interage com quem, e em qual ordem, para realizar esse cenário?

Uso do LLM na Missão 2

Exemplo de prompt:

Queremos modelar o cenário abaixo por meio de um
Diagrama de Sequência UML.

Os alunos ainda não estudaram Orientação a Objetos.

Portanto:
- trate os elementos apenas como participantes;
- não assuma classes ou objetos;
- não use conceitos de herança;
- não invente componentes internos desnecessários.

Primeiro identifique:
1. participantes;
2. interações;
3. ordem das interações;
4. decisões de modelagem necessárias.

Depois gere código PlantUML simples.

[CENÁRIO]

Regra principal do laboratório

O LLM gera uma proposta. O grupo continua sendo responsável pela modelagem.

Antes de aceitar qualquer sugestão, verifiquem:

• essa informação realmente está na descrição?
• o LLM inventou algum participante?
• o LLM inventou alguma funcionalidade?
• existe alguma decisão importante que foi ignorada?
• a ordem das interações faz sentido?
• o modelo responde à pergunta para a qual foi criado?
• existe algum detalhe desnecessário?
• o diagrama pode ser simplificado sem perder informação relevante?

Alteração manual obrigatória

Depois de gerar pelo menos um dos diagramas com apoio do LLM, o grupo deverá fazer pelo menos uma alteração manual no código PlantUML.

A alteração pode ser, por exemplo:

• corrigir uma atividade;
• remover um elemento inventado;
• alterar um participante;
• mudar uma decisão;
• corrigir uma interação;
• simplificar o modelo;
• ajustar a ordem dos eventos.

O grupo deverá registrar essa alteração no entregável.

Exemplo

Alteração realizada: o LLM adicionou um participante chamado BancoDeDados. Removemos esse participante porque a descrição do sistema não especifica como os dados são armazenados.

Cronograma sugerido: 30 minutos

O limite de tempo é proposital. Os modelos devem ser simples, legíveis e úteis, não exaustivos.

Entregável

Cada grupo deverá enviar um único arquivo PDF no Moodle.

O PDF deve conter:

1. Diagrama de Atividades

Incluam:

• diagrama renderizado;
• código PlantUML utilizado.

2. Diagrama de Sequência

Incluam:

• diagrama renderizado;
• código PlantUML utilizado.

3. Decisões de modelagem ou de projeto

Incluam 3 a 5 decisões tomadas pelo grupo.

Exemplos:

Decisão 1: Retorno após conflito: interpretamos que, quando a sala escolhida não está disponível, o fluxo retorna à escolha de uma sala.

Decisão 2: Serviço de Notificação: representamos a notificação como um participante separado no Diagrama de Sequência, embora a descrição não determine como essa funcionalidade é implementada.

Decisão 3: Administrador: tratamos a aprovação como parte do mesmo processo de solicitação, porque o resultado interfere diretamente no estado da reserva.

4. Uso do LLM

Informem:

• nome do LLM utilizado;
• um prompt principal utilizado;
• uma sugestão do LLM que o grupo aceitou, corrigiu ou rejeitou;
• breve explicação da decisão tomada pelo grupo.

Não é necessário incluir todo o histórico da conversa.

5. Alteração manual

Descrevam brevemente:

• qual alteração manual foi realizada no código PlantUML;
• por que ela foi necessária.

Checklist antes da entrega

Antes de gerar o PDF, verifiquem:

• Os dois diagramas representam o mesmo sistema?
• O Diagrama de Atividades mostra claramente decisões e caminhos alternativos?
• O Diagrama de Sequência mostra claramente a ordem das interações?
• As interações são compatíveis com o cenário fornecido?
• O LLM inventou algum elemento que deveria ser removido?
• Qualquer suposição relevante foi registrada?
• O grupo realizou pelo menos uma alteração manual no PlantUML?
• Os diagramas estão legíveis?
• O PDF contém os códigos PlantUML?
• As decisões de modelagem foram justificadas?

Observação final

Não existe necessariamente um único modelo correto.

Diferentes grupos podem produzir soluções distintas e ainda assim coerentes com os requisitos.

O mais importante é que:

1. o modelo seja compatível com a descrição fornecida;
2. as decisões tomadas pelo grupo sejam justificadas;
3. o diagrama seja adequado à pergunta que pretende responder;
4. o grupo consiga avaliar criticamente as sugestões produzidas pelo LLM.

Nesta atividade, o LLM ajuda a escrever PlantUML. O grupo continua sendo responsável por fazer Engenharia de Software.