You are on page 1of 96

Hitórico e Introdução a UML

Prof. André Portugal


O que é um modelo?
•Construímos modelos para compreender melhor o sistema que estamos
desenvolvendo.

•Um modelo é uma simplificação da realidade.


O que é um modelo?
O que é um modelo?
O que é um modelo?
Por que modelar software?
•Ajuda a ter uma visão geral do sistema
•Permite especificar a estrutura e o comportamento do sistema
•Proporciona um guia para a construção do sistema
•Documenta as decisões tomadas
O que é a UML?
•Unified Modeling Language (UML) é...
... uma linguagem gráfica para visualizar, especificar, construir e
documentar os artefatos de um sistema de software.
... resultado da unificação das notações utilizadas nos métodos Booch,
OMT (Object Modeling Technique) e OOSE (Object-Oriented Software
Engineering).
... adotada por grande parte da indústria de software e por fornecedores de
ferramentas CASE como linguagem padrão de modelagem.
… utilizada com qualquer processo de desenvolvimento já que é
independente dele.
A UML é uma Linguagem

•Uma linguagem fornece um vocabulário e as regras para a combinação


de ”palavras” desse vocabulário, com o objetivo de comunicar algo.
•Uma linguagem de modelagem é uma linguagem cujo vocabulário e regras
têm seu foco voltado para a representação conceitual e física de um sistema.
•O vocabulário e as regras de uma linguagem de modelagem indicam como
criar e ler modelos bem formados, mas não apontam quais modelos devem ser
criados e nem em que seqüência.
•Facilita a comunicação entre membros da equipe de desenvolvimento.
Propósito Geral da UML
–Não está presa a uma etapa do desenvolvimento de software
●Análise

●Projeto

●Implementação

●Testes

–Não está presa a um processo


●Ciclo de vida em cascata

●Incremental

●Processo Unificado

●...

–Não está presa a uma linguagem de programação


Segundo OMG - A UML é uma
Linguagem para...
...visualização,
especificação,
construção e
documentação.

http://www.uml.org/
http://www.omg.org/
A UML é uma Linguagem para Visualização

•No processo de desenvolvimento de sistemas de software, é quase impossível


a visualização de toda a estrutura de um sistema sem o uso de modelos que
a represente.
•A UML fornece os símbolos gráficos para a representação de artefatos de
software.
•Por trás de cada símbolo empregado na notação da UML, existe uma sintaxe
e uma semântica bem-definidas.
•Dessa maneira, um desenvolvedor poderá usar a UML para escrever seu
modelo, diminuindo a ambigüidade em sua interpretação.
A UML é uma Linguagem para Especificação

•No presente contexto, especificar significa construir modelos precisos,


completos e sem ambigüidades.
•A UML atende a todas as decisões importantes em termos de análise, projeto
e implementação, que devem ser tomadas para o desenvolvimento e
implantação de sistemas complexos de software.
A UML é uma Linguagem para Construção

•Os modelos de UML podem ser diretamente ”traduzidos” para várias


linguagens de programação.
–Isso significa que é possível mapear os modelos da UML para linguagens de
programação tais como, Java, C++ e Delphi.
–Esse mapeamento permite a realização de uma engenharia de produção:
geração de código a partir de um modelo em UML.
–O processo inverso, a engenharia reversa, também é possível, com a
reconstrução de um modelo a partir de sua implementação.
17/04/2018
Uma linguagem de diagramas

Diagramas de Seqüência

Diagramas de Colaboração
Diagrama de Casos de Uso Modelos
Diagramas de Estado
Diagramas de Classe
Diagramas de Atividade
Diagramas de Objetos

Diagramas de Componentes
Ponto de Vista Dinâmico

Diagrama de Deployment

Ponto de Vista Estático


UML 2.2 tem 14 tipos de
diagramas
Uma colagem de diagramas
UML
Vantagens da Utilização da UML

•Padrão aberto e não proprietário.


•Extensível.
•Independência do processo de desenvolvimento.
•Aplicável a todas as fases do ciclo de desenvolvimento.
•Independência de linguagem de implementação.
Apoio ao Desenvolvimento
Incremental
UML - História

Meyer Harel
Diagramas de Estado
Pré e Pós-Condições

Booch Gamma
Estruturas e Padrões
Booch Method

HP Fusion
Rumbaugh Descrição de Operações e
OMT Numeração de mensagens

Jacobson Embley
Classes simples e
OOSE
visão de alto nível

Shlaer - Melor Odell Wirfs-Brock


Ciclo de Vida dos Objetos Classificação Responsabilidades
História dos métodos
orientado a objetos e
notações
Breve História da UML

2004 - 2005 UML 2.0

2003 UML 1.5

2001 UML 1.4

1999 UML 1.3

UML 1.1
1997

UML 1.0

1996
UML 0.9

1995 Unified Method 0.8

1994 Outros Método OMT OOSE


métodos de Booch (Rumbaugh) (Jacobson)
UML : Diagrama de Casos de Uso
UML – Casos de Uso
•Introdução – Casos de uso
•Elementos do diagrama de casos de uso
•Descrição de casos de uso
•Exemplo: Blog
•Ferramentas de modelagem
•Bibliografia
Introdução – Casos de Uso
•Os casos de uso:

Descrevem como os usuários interagem com o sistema


(as funcionalidades do sistema)

Facilitam a organização dos requisitos de um sistema

Dão uma visão externa do sistema

O conjunto de casos de uso deve ser capaz de comunicar a funcionalidade e


o comportamento do sistema para o cliente

Descrevem o que o sistema faz, mas NÃO especificam como isso deve ser
feito
Elementos – Diagrama de
Casos
•Elementos do de Uso
diagrama:

–Atores
–Casos de uso
–Relacionamentos
•Associação
•Generalização
•Dependência: Extensão e Inclusão
–Fronteira do sistema
Elementos – Diagrama de
Casos
•Elementos do de Uso
diagrama

–Atores
–Casos de uso
–Relacionamentos
•Associação
•Generalização
•Dependência: Extensão e Inclusão
–Fronteira do sistema
Elementos – Diagrama de
•Atores Casos de Uso
–Representam os papéis desempenhados por
elementos externos ao sistema
•Ex: humano (usuário), dispositivo de hardware ou
outro sistema (cliente)
–Elementos que interagem com o sistema

Notação:
Elementos – Diagrama de
Casos
Exemplo: Loja de Uso
de CDs

Identificando os atores
–Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade
ilimitada de discos e para isto, ele deve se dirigir à loja. A loja possui um atendente cuja função
é atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função
é administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao
atendente, ou seja, ele também atende os clientes durante a venda dos discos.
Elementos – Diagrama de
Casos
Exemplo: Loja de Uso
de CDs

Identificando os atores

•E o cliente?
–Não é ator, pois, ele não interage com o sistema!
Elementos – Diagrama de
Casos
•Elementos do de Uso
diagrama

–Atores
–Casos de uso
–Relacionamentos
•Associação
•Generalização
•Dependência: Extensão e Inclusão
–Fronteira do sistema
Elementos – Diagrama de
•Caso de Uso Casos de Uso
–Representa uma funcionalidade do sistema
(um requisito funcional)

–É iniciado por um ator ou por outro caso de uso

Dicas:
Nomeie os casos de uso iniciando por um verbo

Notação:

Nome do Caso de Uso


Elementos – Diagrama de
Casos
Exemplo: Loja de Uso
de CDs

Identificando os casos de uso


–Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade
ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é
atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é
administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao
atendente, ou seja, ele também atende os clientes durante a venda dos discos.
Elementos – Diagrama de
Casos
Exemplo: Loja de Uso
de CDs

Identificando os casos de uso

Vender CDs

Administrar estoque
Elementos – Diagrama de
Casos
•Elementos do de Uso
diagrama

–Atores
–Casos de uso
–Relacionamentos
•Associação
•Generalização
•Dependência: Extensão e Inclusão
–Fronteira do sistema
Elementos – Diagrama de
Casos
•Relacionamento de associação de Uso
–Indica que há uma interação (comunicação) entre
um caso de uso e um ator
–Um ator pode se comunicar com vários casos de uso

Dicas:
NÃO use setas nas associações
Associações NÃO representam fluxo de informação

Notação:
Elementos – Diagrama de
Casos
Exemplo: Loja de Uso
de CDs

Identificando os relacionamentos de
associação
–Uma loja de CDs possui discos para venda. Um cliente pode comprar uma quantidade
ilimitada de discos para isto ele deve se dirigir à loja. A loja possui um atendente cuja função é
atender os clientes durante a venda dos discos. A loja também possui um gerente cuja função é
administrar o estoque para que não faltem discos. Além disso é ele quem dá folga ao
atendente, ou seja, ele também atende os clientes durante a venda dos discos.
17/04/2018
Elementos – Diagrama de
Casos
•Elementos do de Uso
diagrama

–Atores
–Casos de uso
–Relacionamentos
•Associação
•Generalização
•Dependência: Extensão e Inclusão
–Fronteira do sistema
Elementos – Diagrama de
Casos de Uso
•Relacionamento de generalização
Generalização de atores
–Quando dois ou mais atores podem se comunicar
com o mesmo conjunto de casos de uso
–Um filho (herdeiro) pode se comunicar com todos
os casos de uso que seu pai se comunica.

Dica: coloque os herdeiros embaixo

Notação:
17/04/2018
Elementos – Diagrama de
Casos
•Relacionamento dede Uso
generalização
Generalização de casos de uso
–O caso de uso filho herda o comportamento e
o significado do caso de uso pai
–O caso de uso filho pode incluir ou sobrescrever o
comportamento do caso de uso pai
–O caso de uso filho pode substituir o caso de uso pai
em qualquer lugar que ele apareça

Dica: deve ser aplicada quando uma condição resulta na definição de diversos
fluxos alternativos.

Notação:
Pai

Filho 1 Filho 2
Elementos – Diagrama de
Exemplo: Loja de CDs
Casos de Uso
Identificando generalização de casos de uso

Novos requisitos:
–As vendas podem ser à vista ou a prazo. Em ambos os casos o estoque é atualizado e uma
nota fiscal, entregue ao consumidor.

•No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5 CDs de
uma só vez ganham um desconto de 1% para cada ano de cadastro.

•No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com um acréscimo
de 20%. As vendas a prazo podem ser pagas no cartão ou no boleto. Para pagamento com
boleto, são gerados boletos bancários que são entregues ao cliente e armazenados no sistema
para lançamento posterior no caixa. Para pagamento com cartão, os clientes com mais de 10
anos de cadastro na loja ganham o mesmo desconto das compras a vista.
17/04/2018
Elementos – Diagrama de
Exemplo: Loja de CDs
Casos de Uso
Identificando mais generalização de casos de uso

Novos requisitos:
–As vendas podem ser à vista ou a prazo. Em ambos os casos o estoque é atualizado e uma
nota fiscal, entregue ao consumidor.

•No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5 CDs de
uma só vez ganham um desconto de 1% para cada ano de cadastro.

•No caso de uma venda a prazo, ela pode ser parcelada em 2 pagamentos com um acréscimo
de 20%. As vendas a prazo podem ser pagas no cartão ou no boleto. Para pagamento com
boleto, são gerados boletos bancários que são entregues ao cliente e armazenados no sistema
para lançamento posterior no caixa. Para pagamento com cartão, os clientes com mais de 10
anos de cadastro na loja ganham o mesmo desconto das compras a vista.
17/04/2018
Elementos – Diagrama de
Casos
•Elementos do de Uso
diagrama

–Atores
–Casos de uso
–Relacionamentos
•Associação
•Generalização
•Dependência: Extensão e Inclusão
–Fronteira do sistema
Elementos – Diagrama de
Casos
•Relacionamento dede Uso
dependência:
Extensão:
–Representa uma variação/extensão do
comportamento do caso de uso base
–O caso de uso estendido só é executado
sob certas circunstâncias
–Separa partes obrigatórias de partes opcionais
•Partes obrigatórias: caso de uso base
•Partes opcionais: caso de uso estendido
–Fatorar comportamentos variantes do sistema (podendo reusar este comportamento em
outros casos de uso)

Notação: <<extends>>

<<extends>>
Elementos – Diagrama de
Casos
Exemplo: Loja de Uso
de CDs

Identificando dependência: extensão

Novos requisitos:
–No caso de uma venda à vista, clientes cadastrados na loja e que compram mais de 5
CDs de uma só vez ganham um desconto de 1% para cada ano de cadastro.

–No caso de uma venda a prazo...


...Para pagamento com cartão, os clientes com mais de 10 anos de cadastro na
loja ganham o mesmo desconto das compras à vista.
17/04/2018
Elementos – Diagrama de
Casos
•Relacionamento dede Uso
dependência:
Inclusão:
–Evita repetição ao fatorar uma atividade
comum a dois ou mais casos de uso
–Um caso de uso pode incluir vários casos de uso

Notação: <<includes>>
<<includes>>
Elementos – Diagrama de
Casos
Exemplo: Loja de Uso
de CDs

Identificando dependência: inclusão

Novos requisitos:
–Para efetuar vendas ou administrar estoque, atendentes e gerentes terão que validar
suas respectivas senhas de acesso ao sistema.
17/04/2018
Elementos – Diagrama de
Casos
•Elementos do de Uso
diagrama

–Atores
–Casos de uso
–Relacionamentos
•Associação
•Generalização
•Dependência: Extensão e Inclusão
–Fronteira do sistema
Elementos – Diagrama de
•Fronteira do Sistema Casos de Uso
–Elemento opcional (mas essencial para um bom entendimento)
–Serve para definir a área de atuação do sistema

Notação:
17/04/2018
Descrição de Casos de Uso
•A descrição é mais importante do que o diagrama
•UML não especifica padrão

•Pode ser:
–Informal
–Típica
–Detalhada
Descrição de Casos de Uso
•Descrição Informal
–Contém o nome do caso de uso e
uma descrição textual de sua funcionalidade

Exemplo:
Descrição de Casos de
•Descrição Típica
–Contém:
Uso
•Identificação do ator que iniciou o caso de uso
•Pré-requisitos (se houver) do caso de uso
•Descrição textual do:
–Fluxo normal
–Fluxos alternativos (se houver)
Exemplo:
Descrição de Casos de Uso
•Descrição Típica
–Contém:
•Identificação do ator que iniciou o caso de uso
•Pré-requisitos (se houver) do caso de uso
•Descrição textual do:
–Fluxo normal
–Fluxos alternativos (se houver)
Exemplo:
Descrição de Casos de Uso
•Descrição Detalhada (Ex.1)
–Contém:
•Identificação do ator que iniciou o caso de uso
•Objetivo
•Nível
•Pré-requisitos (se houver) do caso de uso
•Condições de disparo (triggers)
•Descrição textual do:
–Fluxo normal
–Fluxos alternativos (se houver)
Exemplo 1:
Descrição de Casos de Uso
•Descrição Detalhada (Ex.2)
–Contém:
•Nome
•Descrição sucinta
•Atores
•Pré-condições
•Pós-condições
•Fluxo básico
•Fluxos alternativos
•Fluxos de exceção
•Estruturas de dados
•Regras de negócio
•Observações
Exemplo 2: (usar nos trabalhos!)
Exemplo 2 (continuação)
Exemplo 2 (continuação.)
Exemplo: Blog
•Um blog é uma ferramenta de colaboração

•Um blog é formado por um conjunto de conteúdos:


–notas

–comentários sobre as notas

•Os conteúdos possuem as seguintes informações: texto, data de criação e


autor

•Os usuários de um blog podem ser:


–Usuário: pode ler conteúdos de um blog, comentar uma nota, remover comentários, e
pode criar um blog.

–Dono do blog: além de todas as funcionalidades de um usuário comum, o dono do blog


pode criar notas e remover notas

•Para remover um conteúdo o usuário precisa ler o conteúdo antes


Exemplo: Blog
UML : Diagrama de Casos de Uso
●Regras
Quando usar relacionamentos

DFD X Modelo de Cados de Uso (MCU)


DFD:
Modelo funcional representa uma visão do comportamento interno do sistema,
mesmo que em alto nível
Processos se comunicam. Trocam informações.
Identifica as funções do sistema
MCU:
Representa uma visão externa
Não existe troca de informações entre casos de uso
Identifica os objetivos do usuário
Identificação dos elementos do MCU

Atores
Identificar quais as fontes de informação a ser
processadas
Identificar os destinos das informações geradas
Se o sistema for uma empresa, identificar as áreas que
serão afetadas
Perguntas a ser respondidas para identificação:
Quais órgãos, departamentos ou pessoas usarão o sistema?
Que equipamentos se comunicarão com o sistema?
Quem vai ser informado sobre os resultados do sistema?
Quem tem interesse em um determinado requisito?
Identificação dos elementos do MCU

Casos de Usos Primários


Representam os objetivos dos atores
Perguntas a ser respondidas para a identificação:
Quais as necessidades e objetivos de cada ator em relação ao
sistema?
Que informações o sistema deve produzir?
O sistema deve realizar alguma ação que ocorre regularmente no
tempo?
Para cada requisito funcional, existe um (ou mais) caso(s) de uso para
atendê-lo?
Identificação dos elementos do MCU

Casos de Usos Primários que podem surgir:


Casos de uso opostos: desfazem o resultado.
Ex: Efetuar Pedido X Cancelar Pedido
Casos de uso que precedem outro caso de uso: pré-requisitos pra realização
de um caso de uso
Ex: Realizar um pedido  Cadastro realizado
Casos de uso que sucedem outro caso de uso:
Ex: Realizar compra por internet -> Agendar entrega
Casos de uso temporais: Tarefas automáticas
Ex: Gerar folha de pagamento mensal automaticamente
Casos de uso relacionado a uma condição interna
Ex: Notificar o usuário que chagaram novos e-mails

73
Identificação dos elementos do MCU

Casos de Usos Secundários


Não traz benefícios diretos para os atores
Necessário para que o sistema funcione adequadamente
Deve ser explicitamente definido para evitar ambigüidades
Categorias:
Manutenção de cadastros
Manutenção de usuários e seus perfis
Manutenção de informações provenientes de outros sistemas
Iniciar pelos MCU Primários - Objetivos
Construção do MCU

Critérios para divisão de diagramas


Diagrama que exibe um caso de uso e seus
relacionamentos
Diagrama que exibe todos os casos de uso para um ator
Diagrama que exibe todos os casos de uso que serão
implementados em uma iteração
Diagrama que exibe todos os casos de uso de uma divisão
da organização
Construção do MCU
Construção do MCU

Documentação de Atores
Nome: Papel desempenhado pelo ator
Breve descrição: uma ou duas frases
Construção do MCU

Documentação de Casos de Uso


Usar os itens de descrição que realmente sejam úteis e
inteligíveis para o usuário.
Sugestão:
Nome: Mesmo nome do DCU; Cada caso de uso deve ter um nome
único.
Identificador: Identifica os casos de uso em atividades que exijam
referência cruzada ou rastreamento.
Ex: CSU01, CSU02
Importância: Categorias de importância (Riscos X Prioridades).
Sumário: Breve declaração do objetivo do ator ao usar o caso de uso.
Construção do MCU

Documentação de Casos de Uso


Sugestão (cont.)
Ator Primário: Nome do ator – Um único ator
Atores secundários: Nome dos atores – Vários atores
Precondições: Hipóteses assumidas como verdadeiras para que o
caso de uso inicie
Fluxo principal: Descrição de seqüência de passos que normalmente
acontece. (Não usar jargões computacionais).
Fluxos alternativos: Descreve situações quando o ator resolve usar o
caso de uso de forma diferente ou descrever escolhas exclusivas ente
si. (não é obrigatório)
Fluxos de exceção: Descreve o que acontece quando algo
inesperado ocorre (erro, uso inválido, cancelamento)
Construção do MCU

Documentação de Casos de Uso


Sugestão (cont.)
Pós-condição: Estado que o sistema alcança após um caso de uso
ter sido executado. Escrito no pretérito.
Regras de negócios: Políticas, condições ou restrições do domínio da
organização.
Histórico: Autor, data, modificações no conteúdo do caso de uso.
Notas de implementação: Capturar idéias de implementação do caso
de uso. Não é usada na validação.
Documentação suplementar ao MCU

Modelo de casos de uso capturam apenas os requisitos


funcionais do sistema
Requisitos Não Funcionais, Regras de Negócios e
Requisitos de interface são capturados nas especificações
suplementares
Utiliza-se texto informal ou descrição estruturada
Utilizar um identificador. Ex:
RN01 para Regras de Negócios
RNF01 para Requisitos Não Funcionais
RI01 para Requisitos de Interface
Pode-se utilizar tabelas para a documentação.
MCU no processo Iterativo

Divida os casos de uso em grupos


Cada grupo é uma iteração
A cada iteração um grupo de casos de uso é detalhado e desenvolvido
Ordem de desenvolvimento:
Risco alto e Prioridade alta
Risco alto e Prioridade baixa
Risco baixo e Prioridade alta
Risco baixo e Prioridade baixa
MCU no processo Iterativo
Procedimento utilizado no processo iterativo:
Concepção: Identifique atores e casos de uso.
Elaboração:
Desenhe os diagramas de casos de uso
Escreva os casos de uso em formato de alto nível e essencial
Ordene a lista de casos de uso de acordo com prioridades e riscos
Planejamento (Elaboração para construção)
Associe cada grupo de casos de uso a uma iteração da fase de construção
Construção (n-esima iteração)
Detalhe os casos de uso
Implemente estes casos de uso
EXEMPLO DE CASO DE USO
Descrição da situação
Uma faculdade precisa de uma aplicação para controlar alguns processos
acadêmicos, como inscrições em disciplinas, lançamento de notas, alocação de
recursos a turmas, etc.
Após a elicitação inicial dos requisitos, os analistas chegam a seguinte lista de
requistos funcionais e não funcionais:
RFs
RF1. O sistema deve permitir que os alunos visualizem as notas obtida por
semestre letivo
RF2. O sistema deve permitir o lançamento das notas das disciplinas
lecionadas em um período letivo e controlar os prazos e atrasos nestes
lançamentos
RF3. O sistema deve manter informações cadastrais sobre disciplinas no
currículo escolar.
RF4. O sistema deve permitir a abertura de turmas para uma disciplina assim
como a definição de salas e laboratórios e horários e dias da semana em que
haverá aulas.
RFs
RF5. O sistema deve permitir que o aluno realize inscrição nas disciplinas do
semestre.
RF6. O sistema deve permitir o controle do andamento das inscrições dos
alunos.
RF7. O sistema deve permitir comunicação com o sistema de RH para coletar
dados dos professores.
RF8. O sistema deve se comunicar com o sistema de faturamento para
informar inscrições do alunos.
RF9. O sistema deve manter informações cadastrais sobre o alunos e o seu
histórico escolar.
RNFs
RNF1. Quantidade máxima de inscrições em um período letivo
O aluno só pode se inscrever em 20 créditos por semestre
RNF2. Quantidade de alunos por disciplinas
Em uma disciplina só podem ser matriculados 40 alunos no máximo
RNF3. Habilitação pra lecionar disciplina
Um professor só pode lecionar uma disciplina para o qual esteja habilitado
...
RNF6. Política de avaliação de alunos
A nota de um aluno em uma disciplina é obtida pela média aritmética de duas
notas de avaliações no semestre e pela freqüência de aulas:
Se o aluno obtiver nota >= 7.0 será aprovado
Se o aluno obtiver nota >= 5.0 nota <= 7.0 deverá fazer avaliação final
Se o aluno obtiver nota < 5.0 será reprovado por média
Se um aluno tiver frequencia < 75% será reprovado por faltas
Documentação do MCU

Atores
Aluno: Indivíduo que está matriculado da faculdade, que tem interesse
em se inscrever em disciplinas do curso
Professor: .....aqui a definição de professor....
Coordenador: ....aqui a definição de coordenador....
Departamento de Registro Escolar: Departamento da faculdade
interessado em manter informações sobre os alunos matriculados e
sobre seu histórico.
Sistemas de RH: Sistema legado responsável por manter informações
sobre os recursos humanos da escola, como os professores.
Sistema de faturamento: ...aqui a definição de sistema de
faturamento...
Diagrama de caso de uso

Casos de uso
Sistema de Controle Acadêmico opostos
RF05

RF01

Casos de uso
que precedem RF09
ou sucedem
outro
Diagrama de caso de uso

Sistema de Controle Acadêmico


Descrição do Caso de Uso no formato
Essencial e Expandido
Realizar Inscrição (CSU01)
Sumário: Aluno usa o sistema para realizar inscrição em
disciplinas
Ator Primário: Aluno
Ator Secundário: Sistema de faturamento
Precondições: O aluno está identificado pelo sistema

17/04/2018 92
Fluxo Principal:
1.O aluno solicita a realização da inscrição
2.O sistema apresenta as disciplinas para as quais o aluno tem pré-requisitos
(conforme a RN03), excetuando-se as que este já tenha cursado
3.O aluno define a lista de disciplinas que deseja cursar no próximo semestre letivo e
as relaciona para inscrição
4.Para cada disciplina selecionada, o sistema designa o aluno para uma turma que
apresente uma oferta para tal disciplina.
5.O sistema informa as turmas para as quais o aluno foi designado. Para cada turma o
sistema informa o professor, horário, local da aula.
6.O aluno confere as informações fornecidas. Aqui é possível que o caso de uso
retorne ao passo 3, conforme o aluno queira atualizar a lista de disciplinas
7.O sistema registra a inscrição do aluno e envia os dados para o sistema de
faturamento e o caso de uso termina

17/04/2018 93
Fluxo alternativo (4): Inclusão em lista de espera
a.Se não há oferta disponível para alguma disciplina selecionada pelo aluno
(conforme RN02), o sistema reporta o fato ao aluno e fornece a
possibilidade de inserir em uma lista de espera.
b.Se o aluno aceitar, o sistema o insere na lista de espera e apresenta a
posição em que o aluno foi inserido na lista. O caso de uso retorna
ao passo 4
c.Se o aluno não aceitar, o caso de uso prossegue a partir do passo 4.

17/04/2018 94
Fluxo de Exceção (4): Violação de RN01
a.Se o aluno atingiu a quantidade máxima de inscrições possíveis em um
semestre letivo(conforme RN01), o sistema informa ao aluno a quantidade
de disciplinas que ele pode selecionar e o caso de uso retorna ao passo 2.

Pós-condições: O aluno foi inscrito em uma das turmas


de cada uma das disciplinas desejadas, ou foi
adicionado a uma ou mais listas de espera.

Regra de negócios: RN01, RN02, RN03

17/04/2018 95
Estudo de Caso: Mini-Projeto SCA

 O Sistema de Controle Acadêmico (SCASENAI) será utilizado na Secretaria do Curso, por


exemplo, Curso de Análise e Desenvolvimento de Software. No que diz respeito aos
indivíduos envolvidos, somente o pessoal da secretária terá acesso ao SCASENAI. Entre as
pessoas que atuam na Secretaria e poderiam utilizar o sistema estão: o chefe da
secretaria, a secretária, alguns professores e alguns estagiários. Na verdade, apesar de
tratarem de indivíduos diferentes, quando estiverem utilizando o sistema todos assumirão o
mesmo papel de Secretaria. Preliminarmente, supõe-se que alguns documentos deverão
ser imressos pelo SCASENAI, como, Histórico Escolar, Diária de Classe, Conteúdo,
Comprovante de matrícula, Diário de Notas, Ata de Realização de Prova, etc. Como o
volume de informações (alunos, professores, disciplinas, etc) pode ser grande optou-se
pelo uso de um Sistema Grenciador de Banco de Dados para armazenamento dos dados
acadêmicos.
 O(A) Sr(a) está na função de analista de requisitos e de acordo com a figura abaixo, que
mostra onde está inserido a especificação de requisitos. É necessário que sejam
lenvantados os requisitos iniciais do SCASENAI:
 O que se pede:
 1) Observando o texto acima, responda as perguntas que estão abaixo;
 Quem são os Atores?
 Quais são os Casos de Uso?
 Quais os Relacionamentos?
 2) Faça um Diagrama de Caso de Uso completo.
 3) Descreva na forma numerada os Casos de Uso.

You might also like