Introdução a Modelagem

de Software

UML – Unified Modeling

Language

Engenharia de Software

hi@[Link]
1
@[Link]
Histórico
⬥ 1950/60 – Sistemas ad hoc
⬥ Época dos fluxogrmas
⬥ 1970 – Programação estruturada
⬥ Tom de Marco, Edward Yourdon
⬥ 1980 – Análise estruturada moderna
⬥ Necessidade de interface mais sofisticada
⬥ DFD, DTE, DER
⬥ 1990 – Análise Orientada a Objetos
⬥ Shaler, Mellor, Booch, Jacobson, Rumbaugh

* Engenharia de software 2 2
orientada a objetos
Técnicas para modelagem
Booch (Booch Method)

Shaler-Mellor - OOA

Coad & Yourdon

*
[Link] Engenharia de software 3 3
Jacobson
orientada a objetos
UML –
Linguagem de Modelagem Unificada
• UML
– é uma linguagem visual para modelar sistemas Orientados a
Objetos
– Define elementos gráficos que podem ser utilizados na
modelagem de sistemas
– Através dos elementos definidos na linguagem podem-se
construir diagramas para representar diferentes perspectivas de
um sistema
– Cada elemento gráfico possui uma
• Sintaxe: forma predeterminada de denehar o elemento
• Semântica: O que significa o elemento e com que objetivo deve ser
usado
* Engenharia
– A sintaxe e a semântica de software
são extensíveis 4 4
orientada a objetos
UML –
Linguagem de Modelagem Unificada
• UML
– É independente de linguagens de programação e de
processo de desenvolvimento
– Definição completa:
• [Link]
• Especificação de leitura complexa voltada a pesquisadores
ou desenvolvedores de ferramentas de suporte

* Engenharia de software 5 5
orientada a objetos
UML –
Linguagem de Modelagem Unificada
• Visões de um sistema
– Um sistema complexo pode ser examinado a partir de
diversas perspectivas.
– Autores da UML definem 5 visões:
• Visão de Casos de uso: Visão externa do sistema que define
a interação entre o sistema e agentes externos.
• Visão de Projeto: Caracterísiticas estruturais e
comportamentais do sistema.
• Visão de Implementação: gerenciamento de versões
construídas pelo agrupamento de módulos e subsistemas.
• Visão de Implantação: Distribuição física do sistema.
* • Visão de Processo: Caracterísiticas
Engenharia de software de concorrência,
6 6
sincronização e desempenho do
orientada a objetos sistema.
UML –
Linguagem de Modelagem Unificada
• Diagramas:
– Os documentos gerados em um processo de
desenvolvimento são chamados de artefatos na UML
– Os artefatos compõe as visões do sistema
– A UML define 13 diagramas
– Esta quantidade de diagramas é justificada pela
necessidade de analisar o sistema por meio de
diferentes perspectivas
– Cada diagrama fornece uma perspectiva parcial do
sistema.
* Engenharia de software 7 7
orientada a objetos
 Diagramas
da UML
UML
Diagramas
Diagramas
comportamentai
estruturais
s

Diagramas Diagramas
de objetos Diagramas de Diagramas de
Implementação Interação de
Atividades
Diagramas Diagramas
de classes Diagramas de
Diagramas de de Casos de
Componentes Seqüência Uso
Diagramas Diagramas
Diagramas
de pacotes Diagramas de de
de
Implantação Colaboraçã
Transições
Diagramas o
de estados
de estrutura Diagramas
de Diagramas
composta UML 2.0
Visão geral de
Da Interação Temporizaç UML 2.0
UML 2.0
ão
* Engenharia de software 8 8
orientada a objetos
UML – Mecanismos gerais

• Componentes da UML
– Blocos de construção básicos
– Regras que restringem como os blocos de
construção podem ser associados
– Mecanismos de uso geral
• Estereótipos, Notas explicativas, Etiquetas
valoradas, Restrições, Pacotes, OCL

* Engenharia de software 9 9
orientada a objetos
UML – Mecanismos gerais

• Estereótipos
– Estende o significado de determinado elemento em
um diagrama
• Existem estereótipos predefinidos
• O usuário pode definir um estereótipo
– Um estereótipo deve ser documentado para evitar
ambigüidades
– Estereótipos gráficos: Ícones gráficos
– Estereótipos textuais: Rótulo junto ao símbolo que
representa.
* Engenharia de software 10 10
orientada a objetos
UML – Mecanismos gerais
• Estereótipos Gráficos • Estereótipos Textuais

<<document>>
<<interface>>
<<entity>>

<<satisfaz>>
<<realiza>>

* Engenharia de software 11 11
orientada a objetos
UML – Mecanismos gerais

• Notas explicativas
– Comenta ou esclarece alguma parte do diagrama
• Textuais
• Linguagem de restrição de objetos (OCL)
– Não modificam nem estendem o significado do
elemento
– Não deve ser usado em excesso

* Engenharia de software 12 12
orientada a objetos
UML – Mecanismos gerais

• Etiquetas valoradas (tagged value)

– Os elementos da UML tem 3 propriedades
predefinidas: nome, lista de atributos e lista de
operações
– Etiquetas valoradas são usadas para definição de
outras propriedades além das 3 predefinidas
– Na UML 2.0 somente pode-se usar uma etiqueta
valorada como um atributo usado sobre um
estereótipo
– Notação
* • {tag=valor} Engenharia de software 13 13
orientada a objetos
UML – Mecanismos gerais

• Restrições
– Podem estender ou alterar a semântica natural de um
elemento gráfico
– Podem ser especificadas formalmente (OCL) ou
informalmente (texto livre)
– Restrições devem aparecer dentro de notas
explicativas

* Engenharia de software 14 14
orientada a objetos
UML – Mecanismos gerais

• Pacotes
– Agrupa elementos semanticamente relacionados
– Um pacote se liga a outro através de uma
relacionamento de dependência
– A dependência pode ser especificada através de um
estereótipo
– Pode agrupar outros pacotes

* Engenharia de software 15 15
orientada a objetos
UML – Mecanismos gerais

• Pacotes

* Engenharia de software 16 16
orientada a objetos
UML – Mecanismos gerais

• OCL (Linguagem de restrição de objetos)

– Linguagem formal para especificar restrições sobre
diversos elementos em um modelo
– Consiste de:
• Contexto: Domínio no qual a declaração em OCL se aplica
• Propriedade: um componente do contexto
• Operação: O que deve ser aplicado sobre a propriedade
– Exemplo:

Context Veículo
inv: [Link]á[Link] >= 18
* Engenharia de software 17 17
orientada a objetos
1º Modelo:

Diagrama de Casos de Uso

18
 Introdução
⬥ Modelos de Casos de Uso
⬥ É uma representação das funcionalidades eternamente
observáveis do sistema e dos elementos externos ao sistema que
interagem com eles
⬥ É um modelo de análise que representa um refinamento dos
requisitos funcionais.
⬥ Idealizado por Ivar Jacobson em 1970 e inserida na UML na
década de 90.
⬥ É o modelo mais popular para a documentação de requisitos
funcionais
⬥ O MCU representa os possíveis usos de um sistema.

⬥ Componentes: Casos de Usos, Atores e Relacionamentos

* Engenharia de software 19 19
orientada a objetos
Notação da UML

* Engenharia de software 20
orientada a objetos
 Casos de Uso
⬥ É a especificação de uma seqüência completa de
interações entre um sistema e um ou mais agentes
externos a este sistema.
⬥ Representa uma determinada funcionalidade de um sistema
conforme percebida externamente.
⬥ Representa também os agentes externos que interagem com o
sistema
⬥ Não revela a estrutura e o comportamento interno do sistema.
⬥ Completa representa um relato fim a fim de um dos usos
do sistema para alcançar um objetivo util.

⬥ Ex: Entrar no sistema não é um caso de uso

* Engenharia de software 21 21
orientada a objetos
 Casos de Uso
⬥ Um MCU pode conter vários casos de uso
⬥ Cada caso de uso se define pela descrição narrativa das
interações entre o agente externo e o sistema.
⬥ Há 3 dimensões para variações das descrições dos casos
de uso
Detalhamento

Abstração

Formato

* 22 22
 Casos de Uso
⬥ Formato: estrutura utilizada para organizar a sua narrativa
textual:
⬥ Contínuo, numerado, tabular

⬥ Formato contínuo

Este caso de uso inicia quando o Cliente chega ao caixa eletrônico e insere
seu cartão. O sistema requisita a senha do Cliente. Após o Cliente fornecer
sua senha e esta ser validada, o Sistema exibe as opções de operações
possíveis. O Cliente opta por realizar um saque. Então o Sistema requisita o
total a ser sacado. O Cliente fornece o valor da quantidade que deseja sacar.
O sistema fornece a quantia desejada e imprime o recibo para o Cliente. O
Cliente retira a quantia e o recibo , e o caso de usa termina.

* Engenharia de software 23 23
orientada a objetos
 Casos de Uso
⬥ Formato numerado

1) Cliente insere seu cartão no caixa eletrônico.

2) O sistema requisita a senha do Cliente.
3) Cliente fornecer sua senha
4) Sistema valida a senha e exibe as opções de operações possíveis.
5) O Cliente opta por realizar um saque.
6) Sistema requisita o total a ser sacado.
7) O Cliente fornece o valor da quantidade que deseja sacar.
8) O sistema fornece a quantia desejada e imprime o recibo para o Cliente.
9) O Cliente retira a quantia e o recibo , e o caso de usa termina.

* Engenharia de software 24 24
orientada a objetos
 Casos de Uso
⬥ Formato Tabular
Cliente Sistema
Insere seu cartão no caixa eletrônico. Requisita a senha do Cliente.

Fornecer sua senha Valida a senha e exibe as opções de operações

possíveis.

Solicita realização de um saque. Requisita o total a ser sacado.

Fornece o valor da quantidade que deseja Fornece a quantia desejada e imprime o recibo
sacar. para o Cliente.

Retira a quantia e o recibo

Tenta prover alguma estrutura à descrição

* Engenharia de software 25
orientada a objetos
 Casos de Uso
⬥ Grau de detalhamento
⬥ Sucinto: Não detalha as interações
⬥ Expandido: Descreve as interações em detalhes

⬥ Grau de abstração
⬥ Existência ou não de menção a aspectos relativos a tecnologia
durante a descrição de um caso de uso
⬥ Real: Se compromete com a solução do projeto
⬥ Ex: O usuário insere o seu cartão magnético
⬥ Essencial: É abstrato no sentido de não mencionar aspectos
relativo ao uso de tecnologias
⬥ Ex: O usuário fornece sua identificação

* Engenharia de software 26
orientada a objetos
 Casos de Uso
⬥ Cenários
⬥ É a descrição de uma das maneiras pelas quais o caso de uso
pode ser utilizada.
⬥ É um episódio de utilização de uma funcionalidade.
⬥ Pode ser utilizada posteriormente na fase de testes
⬥ Pode ser vista como uma instância de um caso de uso.
• Cliente insere seu cartão no caixa eletrônico.
• O sistema apresenta a tela de requisição de senha do Cliente.
• Cliente digita sua senha
• Sistema valida a senha e exibe o menu com as opções de saque,
pagamento ou transferência.
• O Cliente seleciona a opção saque.
• Sistema apresenta tela com a requisição do valor a ser sacado.
• O Cliente digita o valor da quantidade que deseja sacar.
• ...

* Engenharia de software 27
orientada a objetos
Atores
⬥ É qualquer elemento externo ao sistema que interage
com o mesmo
⬥ Atores não fazem parte do sistema
⬥ Atores trocam informações com o sistema
⬥ Um ator representa um papel representado em relação
ao sistema
⬥ Categorias
⬥ Cargos
⬥ Organizações ou divisões de uma organização
⬥ Outros sistemas de software
⬥ Equipamentos que o sistema se comunica
⬥ Atores podem ser Primários ou Secundários
* Engenharia de software 28
orientada a objetos
Diagrama de Casos de Uso

* Engenharia de software 29
orientada a objetos
Relacionamentos
⬥ Componente responsável por representar a interação
entre os atores e casos de usos. (Ator <--> Caso de Uso)
⬥ Também representa ligações entre casos de uso ou entre
atores. (Ator <--> Ator; Caso de Uso <-->Caso de Uso)
⬥ Tipos de Relacionamentos no MCU:
⬥ Comunicação
⬥ Inclusão
⬥ Extensão
⬥ Generalização

* Engenharia de software 30
orientada a objetos
Relacionamentos
⬥ Comunicação:
⬥ Informa a que caso de uso o ator está associado
⬥ Representa as trocas de informação entre os atores e
casos de uso
⬥ É o mais utilizado nos MCU
⬥ Um ator pode estar associado a vários casos de uso
⬥ Um caso de uso pode estar associado a vários atores

* Engenharia de software 31
orientada a objetos
Relacionamentos
⬥ Inclusão:
⬥ Somente entre Casos de Usos
⬥ Quando dois ou mais casos de usos incluem uma
sequencia comum de interações, esta sequencia pode
ser descrita em outro caso de uso
⬥ Vários caos de uso podem incluir o comportamento
deste caso de uso comum.
⬥ Ex: Obter Extrato, Realizar Saque e Transferência
incluem Validar Senha

* Engenharia de software 32
orientada a objetos
Diagrama de caso de Uso - Inclusão

* Engenharia de software 33
orientada a objetos
Relacionamentos
⬥ Extensão:
⬥ Somente entre Casos de Usos
⬥ Modelar situações em que diferentes seqüências de
interações podem ser inseridas em um mesmo caso
de uso. Estas seqüências representam um
comportamento eventual.
⬥ A existência de um caso de uso estendido deve ser
independente da existência de casos de uso que
estendam o primeiro
⬥ Exemplo: Realizar Saque e Transferência podem ser
estendidos por Consultar Extrato

* Engenharia de software 34
orientada a objetos
Diagramas de Caso de Uso - Extensão

* Engenharia de software 35
orientada a objetos
Relacionamentos
⬥ Generalização:
⬥ Pode existir entre dois casos de Uso ou entre dois atores
⬥ Permite que um caso de uso (ou um ator) herde comportamento
de outro caso de uso (ou ator)
⬥ O caso de uso mais genérico pode ser Abstrato ou concreto.
⬥ É recomendado que o caso de uso pai sempre seja abstrato para
evitar problemas na especificação
⬥ O caso de uso pai é utilizado apenas para representar a
natureza dos casos de uso filho.
⬥ Não há especificação de comportamento para o caso de uso
abstrato.

* Engenharia de software 36
orientada a objetos
Relacionamentos
⬥ Generalização:
⬥ Exemplos:
⬥ Requisitar Produtos é generalização de Requisitar produtos
na loja, Requisitar produtos pela internet

⬥ Usuário é generalização de Professor e Aluno

* Engenharia de software 37
orientada a objetos
 Diagramas de Caso de Uso -
Generalização

* Engenharia de software 38
orientada a objetos
Diagramas de Casos de Uso

Diagrama de Caso de Uso

Elementos da UML

* Engenharia de software 39
orientada a objetos
 Quando usar relacionamentos
⬥ Inclusão
⬥ Quando o mesmo comportamento se repete em mai de um caso
de uso
⬥ O Comportamento comum necessariamente contido em todos os
cenários do caso de uso inclusor
⬥ O caso de uso inclusor não está completo sem o caso de uso
incluso
⬥ Extensão
⬥ Quando um comportamento eventual do caso de uso tiver que ser
descrito
⬥ Para estender o comportamento do caso de uso sem modificar o
original

* Engenharia de software 40 40
orientada a objetos
 Quando usar relacionamentos
⬥ Generalização de caso de uso
⬥ Identifica-se vários casos de uso com o mesmo comportamento
⬥ Se o comportamento do pai difere em alguma coisa do do filho, não use
generalização, mas extensão.
⬥ Generalização de Ator
⬥ Precisa definir um ator que desempenha papel já desempenhado por
outro ator em relação ao sistema, mas que também possui
comportamento particular
⬥ A legibilidade tem preferência sobre a formalização
⬥ Nunca use muitos relacionamentos de extensão, inclusão e
generalização

* Engenharia de software 41 41
orientada a objetos
 Quando usar relacionamentos
⬥ DFD X 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

* Engenharia de software 42 42
orientada a objetos
 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?

* Engenharia de software 43 43
orientada a objetos
 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?

* Engenharia de software 44 44
orientada a objetos
 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
* Engenharia de software 45 45
orientada a objetos
 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
* Engenharia de software 46 46
orientada a objetos
 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

* Engenharia de software 47 47
orientada a objetos
 Construção do MCU

* Engenharia de software 48 48
orientada a objetos
 Construção do MCU

⬥ Documentação de Atores
⬥ Nome: Papel desempenhado pelo ator
⬥ Breve descrição: uma ou duas frases

* Engenharia de software 49 49
orientada a objetos
 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.

* Engenharia de software 50 50
orientada a objetos
 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)

* Engenharia de software 51 51
orientada a objetos
 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.

* Engenharia de software 52 52
orientada a objetos
 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.
* Engenharia de software 53 53
orientada a objetos
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
* Engenharia de software 54 54
orientada a objetos
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
* Engenharia de software 55 55
orientada a objetos
EXEMPLO DE CASO DE USO

56
 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
não funcionais:

* Engenharia de software 57 57
orientada a objetos
 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.
⬥ 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
Engenharia cadastrais sobre
de software 58 o alunos e o seu 58
histórico escolar. orientada a objetos
 RFNs
⬥ RFN1. Quantidade máxima de inscrições em um período letivo
⬥ O aluno só pode se inscrever em 20 créditos por semestre
⬥ RFN2. Quantidade de alunos por disciplinas
⬥ Em uma disciplina só podem ser matriculados 40 alunos no máximo
⬥ RFN3. Habilitação pra lecionar disciplina
⬥ Um professor só pode lecionar uma disciplina para o qual esteja
habilitado
⬥ ...
⬥ RFN6. 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
* Engenharia de software 59 59
orientada a objetos
 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...

* Engenharia de software 60 60
orientada a objetos
 DiagramaSistema
de caso de uso
de Controle Acadêmico
Casos de uso
opostos
RF05

RF01

Casos de uso
que precedem RF09
ou sucedem
outro

* Engenharia de software 61 61
orientada a objetos
 DiagramaSistema
de caso de uso
de Controle Acadêmico

* Engenharia de software 62 62
orientada a objetos
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

* Engenharia de software 63
orientada a objetos
 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

* Engenharia de software 64
orientada a objetos
 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.

* Engenharia de software 65
orientada a objetos
 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

* Engenharia de software 66
orientada a objetos