Projeto de software

Projeto de Software

•

UPF

Carla Tartari

22/09/2016

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

ag?ia_turismo___objetivo_geral_e_requisitos_funcionais_para_o_sw.docx
Agência de Turismo – Projeto de software
Objetivo Geral
Exemplo 1: O software visa melhorar a organização da empresa e agilizar os procedimentos realizados, auxiliando no gerenciamento das excursões, fornecendo informações precisas e confiáveis, possibilitando análises e auxílio à tomada de decisões, além de facilitar as consultas aos dados. Visa, também, facilitar o gerenciamento financeiro, tornando-a, assim, mais competitiva no mercado.
Exemplo 2: O objetivo principal na implantação do sistema é a informatização da empresa. Com a implantação desse sistema, haverá uma maior segurança e confiabilidade dos dados, permitindo consultas dos dados armazenados na base de dados. Visa dar mais agilidade ao processo de busca de informações para facilitar o trabalho diário do gerente da agência. Permitirá gerar relatórios para suprir as necessidades que cada gerente precisar.
Exemplo 3: O sistema desenvolvido tem como objetivo, em especial, um melhor gerenciamento das excursões e dos clientes, através da atualização contínua das informações, que garantirão a confiabilidade e a integridade dos dados, propiciando a agilidade dos trabalhos realizados na empresa e facilitando o controle financeiro.
Requisitos funcionais
Manter tabela cidades
Manter tabela estados
Manter tabela países
Manter dados de funcionários
Validar CPF
Manter tabela de cargos
Manter dados da frota
Manter tabela de acessórios
Identificar acessórios da frota
Manter dados de excursão
Manter dados de roteiros
Manter dados de passeios
Manter dados de clientes
Manter clientes da excursão
Gerenciar parte financeira
Manter usuários
Emitir folder viagem
Listar disponibilidade de veículos
Listar pessoas por excursão
REQUISITOS NÃO FUNCIONAIS
Restrições sobre serviços ou funções oferecidos pelo sistema
Exemplos: restrições de timing, restrições sobre o processo de desenvolvimento, padrões, etc.
Não dizem respeito diretamente às funções específicas fornecidas pelo sistema
Definem propriedades e restrições de sistema : tempo de resposta, confiabilidade e requisitos de armazenamento
Podem definir restrições para o sistema, como a capacidade dos dispositivos de E/S e as representações de dados utilizadas nas interfaces de sistema
Podem dizer respeito ao sistema como um todo e não a características individuais do sistema
Frequentemente são mais importantes do que os requisitos funcionais individuais (enquanto a falha em cumprir com um requisito funcional individual pode degradar o sistema, a falha em cumprir um requisito não funcional de sistema pode tornar todo o sistema inútil)
Exemplo: se um sistema de aviação não atender a seus requisitos de confiabilidade, ele não será atestado como seguro para a operação
Requisitos não funcionais nem sempre dizem respeito ao sistema de software a ser desenvolvido
Alguns requisitos não funcionais podem restringir o processo que pode ser utilizado para desenvolver o sistema
Exemplos de Requisitos de Processo:
uma especificação dos padrões de qualidade, que deve ser utilizada no processo
uma especificação de que o projeto deve ser produzido com um conjunto especificado de ferramentas CASE
a obrigatoriedade de usar uma determinada linguagem de programação ou método de desenvolvimento
uma descrição do processo a ser seguido
Requisitos não funcionais surgem conforme a necessidade dos usuários em razão de:
restrições de orçamento necessidade de interoperabilidade com outros sistemas de software ou hardware
políticas organizacionais fatores externos, como regulamentos de segurança e legislação sobre privacidade
Os diferentes tipos de requisitos não funcionais podem ser classificados de acordo com a sua procedência em:
Requisitos de produto Requisitos organizacionais Requisitos externos
Requisitos de produto: Requisitos que especificam que o produto entregue deve se comportar de uma maneira particular
Exemplos: Requisitos de desempenho (velocidade de execução e memória requerida); Requisitos de portabilidade; Requisitos de confiabilidade (estabelecem a taxa aceitável de falhas); Requisitos de facilidade de uso, etc
Requisitos organizacionais: Requisitos que são uma consequência de políticas e procedimentos nas organizações do cliente e do desenvolvedor
Exemplos: padrões de processo que devem ser usados; requisitos de implementação, como a linguagem de programação ou o método de projeto utilizado; requisitos de fornecimento, que especificam quando o produto e seus documentos devem ser entregues
Requisitos externos : Requisitos que surgem a partir de fatores externos ao sistema e seu processo de desenvolvimento
Exemplos: Requisitos de interoperabilidade, que definem como o sistema interage com sistemas em outras organizações
Requisitos legais, que devem ser seguidos para assegurar que o sistema opera de acordo com a lei
Requisitos éticos, que garantem que o sistema será aceitável para seus usuários e o público em geral
A distinção entre esses diferentes tipos de requisitos não é tão clara
Um requisito de usuário relacionado à proteção parece ser um requisito não funcional
Quando desenvolvido com mais detalhes, pode levar a outros requisitos que são claramente funcionais, como a necessidade de incluir recursos de autorização de usuários no sistema
Embora seja útil classificar os requisitos dessa maneira quando se discute, se deve lembrar que é, na verdade, uma distinção artificial
Requisitos Não Funcionais para a Agência de Turismo
O sistema deve ser simples para que pessoas com conhecimento básico em informática possam usar.
O sistema implantado deverá ter segurança, podendo assim somente pessoas autorizadas terem acesso (com controle de permissões de acesso).
O tempo de resposta das solicitações feitas pelo usuário que tem o devido acesso, não poderá passar de cinco segundos.
O sistema deve possuir interface intuitiva e amigável.
O Banco de Dados será XXX;
A linguagem de programação é YYY;
O sistema operacional será ZZZ; (pode ser pensado em portabilidade em função de sistema operacional e hardware)
Ferramentas de modelagens utilizadas para modelagem dos diagramas da UML: Astah ou Power Designer;
Outros Softwares utilizados: Microsoft Office, Photoshop CS, IBExpert;
lista_de_exercicios.docx
Atividade discente - Projeto de Software Orientado a Objetos (2014 I)
Resolva as questões abaixo considerando o projeto do software. Resolva as questões 1 a 5 para a primeira atividade a ser entregue no dia 03/06/2014 e as questões 6 a 11 para a segunda atividade a ser entregue no dia 10/06/2014.
1. Considere o seguinte texto: Uma quituteira faz doces e salgados por encomenda. Quando um cliente faz uma encomenda ela anota numa agenda, na data solicitada, os dados do cliente, a hora para a entrega e os produtos encomendados (produto e quantidade). Cabe lembrar que produto é o resultado da realização de uma receita. Se o cliente for bem conhecido, a quituteira aceita a reserva da encomenda para a data, sem a indicação do que será encomendado, podendo isso ser informado posteriormente.
a) Identifique os requisitos funcionais para o projeto do software
b) Apresente o diagrama de Casos de Uso correspondente

2. Na empresa Pneus e Serviços PIT STOP além da venda de pneus são prestados serviços de borracharia. No momento em que um cliente se dirige até a borracharia, na maioria das vezes, se ele não tiver cadastro então é preenchido, no computador, um cadastro com os dados pessoais do mesmo. Depois de cadastrado, o cliente pede os serviços que quer que sejam prestados e então tudo que o ele fizer será anotado em uma ordem de serviço que é composta de vários campos onde devem ser preenchidos: a data, o tipo do veículo (caminhão, carro ou caminhonete)
e a placa e o nome do cliente. Nesta ordem existe uma tabela que contém as seguintes colunas: tipo de serviço, onde existe uma lista de serviços que a borracharia realiza (como exemplo: troca de bico de rodoar, conserto de câmara, troca de pneu, etc.); quantidade (onde se deve preencher a quantidade do serviço que foi realizado); descrição (campo opcional que só é preenchido se houver necessidade e onde se faz uma breve descrição do serviço realizado); valor (que corresponde ao valor cobrado para cada serviço, considerando a multiplicação do preço unitário do serviço pela quantidade); e por último, total, onde se faz a soma de todos os serviços realizados e anota-se o valor total que o cliente terá de pagar.
a) Defina o objetivo geral para o projeto do software
b) Identifique os requisitos funcionais
c) Apresente a documentação do Caso de Uso Manter Dados da Ordem de Serviço. Utilize formato numerado ou tabular e grau de detalhamento expandido.
3. Num salão de beleza, para o cliente ser atendido ele deve já possuir uma ficha cadastral com seus dados pessoais. Antes de iniciar o atendimento a recepcionista prepara uma ficha de serviços onde coloca o código do cliente e a data. Esta ficha de serviços já possui todos os serviços oferecidos pré-impressos. De posse da ficha de serviços, o cliente é encaminhado para o(s) devido(s) profissional(is). O profissional ao realizar o serviço anota na ficha de serviços do cliente o seu nome ao lado de cada serviço por ele efetuado. Ao final do atendimento o cliente apresenta a ficha para a recepcionista que calcula o valor devido e apresenta o valor ao cliente, que poderá pagar naquele momento (a recepcionista coloca um carimbo de PAGO na ficha) ou então anotar em sua ficha para pagamento posterior. Caso a recepcionista não esteja presente, um profissional pode preencher a ficha cadastral do cliente, preparar a ficha de serviços e fazer o fechamento da conta.
Para o texto apresentado:
Identifique os requisitos funcionais para o projeto do software
Apresente o Diagrama de Casos de Uso
4. Uma empresa disponibiliza telefones celulares para os funcionários através de um plano de telefonia empresarial. O controle de telefonia é realizado por uma secretária que possui, para cada operadora de telefonia, uma lista de aparelhos disponibilizados pela mesma. Esta lista ela faz usando um editor de textos e nela consta (para cada operadora) o modelo do aparelho, sua descrição e marca. Quando o funcionário tem interesse em algum aparelho a secretária faz um cadastro identificando o nome do funcionário e o seu setor de trabalho dentro da empresa (caso ele ainda não possua este cadastro). Após o funcionário escolhe um aparelho e um plano de uso, dentre os constantes em listas que a secretária apresenta (também feitos usando um editor de textos) e que são fornecidos pelas operadoras; cada plano define condições de uso e valores. A secretária prepara e o funcionário assina uma autorização de desconto em folha mensal dos gastos com telefonia efetuados por ele. Ao final de cada mês cada operadora envia uma lista com todas as ligações e o valor total de cada funcionário. A secretária prepara e entrega para cada funcionário um comprovante indicando todas as suas ligações e o valor total. Prepara também uma lista com o nome do funcionário e o valor total e envia para o RH da empresa (que providenciará a cobrança descontando do salário do funcionário).
Para o texto apresentado:
Defina o objetivo geral para o projeto do software
Identifique os requisitos funcionais para o projeto do software
Identifique os requisitos não funcionais para o projeto do software
Apresente o Diagrama de Casos de Uso
5. Apresente o Diagrama de Atividades do Caso de Uso Manter Ficha de Consultas considerando o texto que segue. Num consultório médico cada paciente possui um envelope identificado com seu nome no qual são guardadas as fichas de consulta. A cada consulta feita é preenchida uma ficha onde são anotados o peso, a temperatura, a pressão arterial do paciente e os sintomas que ele apresenta, bem como o resultado do exame clínico feito, que define o provável diagnóstico (nome de uma ou mais doenças, de acordo com o Cadastro Internacional de Doenças); se houver necessidade é solicitada a realização de algum tipo de exame (é anotado na ficha o nome de cada exame solicitado e quando vem o resultado são feitas anotações complementares); se for indicado algum tratamento, é anotado o nome de cada remédio com a correspondente dosagem. Esta ficha não tem campos pré-estabelecidos; é uma ficha pautada onde o médico vai descrevendo a consulta e seu encaminhamento; se o espaço da ficha termina, ele pega outra ficha (todas ficam guardadas dentro do mesmo envelope). Se necessário, ao final da consulta o médico elabora um atestado, onde indica o nome do paciente, a data (ou período) de validade do atestado e o diagnóstico identificado.
6. Faça o Diagrama de Classes para a seguinte situação: Para que uma pessoa se torne sócia de um Clube é necessário preencher um cadastro (nome, endereço, telefone e profissão). Cada sócio pertence a uma determinada categoria (remido, proprietário, temporário, jubilado, etc), que estabelece o valor mensal a ser pago pelo sócio. Algumas categorias podem não ter valor mensal e para o sócio da categoria Temporário é necessário saber a data inicial e a data final de validade da associação.
7. Na organização de um evento são definidas palestras. Sobre cada palestra deve ser informado: assunto (conforme lista definida pela comissão organizadora, podendo ser acrescentado novo assunto ao definir uma palestra), título, duração, data e hora. Uma palestra tem um ou mais palestrantes e pode usar nenhum, um ou vários equipamentos. Ao fazer o cadastro de uma palestra é necessário já indicar seu(s) palestrante(s) porém o(s) equipamento(s) usados podem ser informados posteriormente. Apresente o Diagrama de Atividades para o Caso de Uso Manter dados de Palestras.
8. Apresente o Diagrama de Classes para o enunciado do exercício 7.
9. Apresente o Diagrama de Classes para a descrição a seguir: Numa Agência de Turismo é do Gerente a responsabilidade pela organização das excursões. Para cada excursão é definida a data de saída e a data de chegada, o horário de saída e o horário previsto para chegada, o valor, o guia, qual o veículo da frota será utilizado (podendo ser informado mais próximo da viagem) e quem serão os motoristas que acompanharão a viagem (normalmente dois). Motoristas e guias são funcionários da empresa, dos quais é necessário saber nome, RG, CPF e cargo. Além disso, para os motoristas é necessário saber número da CNH, modelo e data de validade.
10. Na UnABC o processo de matrícula ainda não é informatizado e é realizado na secretaria de cada curso. Para fazer a matrícula é necessário que o aluno já tenha cadastro (se não tiver, a ficha cadastro é preenchida). Após o aluno se identificar, a atendente solicita as disciplinas de interesse do mesmo e para cada disciplina ela verifica se tem vaga, confirmando a matrícula na disciplina (se não tiver choque de horário com outra já matriculada) ou informando ao aluno sobre a inexistência de vaga. Ao confirmar a matrícula a atendente anota numa ficha o nome da disciplina, o horário e a quantidade de créditos. Ao final do processo a atendente totaliza os créditos e o aluno assina.
Faça o Diagrama de Atividades para a situação apresentada, que se traduz no projeto do software no caso de uso Manter dados de matrícula.
11. No Restaurante Sabor Especial tem várias mesas; cada mesa tem um número e uma capacidade (quantidade de pessoas que acomoda). É possível fazer reservas de mesas (é anotado em uma agenda, no dia solicitado para a reserva, o horário para a reserva, o nome de quem fez a reserva, seu telefone, a quantidade de pessoas e as mesas reservadas). Também é possível que cheguem pessoas sem reserva de mesa – se tiver mesa disponível
e não reservada, as pessoas são encaminhadas para ela. A cada dia, em cada turno, quando o restaurante abre, é atualizado o mapa das mesas, identificando se cada mesa está reservada ou disponível, sendo que, durante o funcionamento do restaurante, a mesa pode ficar ocupada e voltar a ficar disponível.
Apresente o Diagrama de Estados da classe Mesa, considerando a realidade de cada turno de funcionamento do restaurante.
diag_ativ_realizar_contrato.docx
ex_diagrama_de_atividades_emprestimo.docx
diag_casos_de_uso_pjsw_ag?ia_turismo.asta
EntityStore
diagrama_casos_de_uso_pjsw_ag?ia.docx
diag_ativ_palestrante.docx
ex_diagrama_atividades_nota_fiscal.docx
diagrama_atividades_manter_dados_de_pessoas___imobiliaria.docx
diagrama_de_atividades_realizar_contrato_loca?.asta
EntityStore
diag_casos_de_uso.docx
diagrama_de_casos_de_uso_alugu?.asta
EntityStore
diagrama_de_classes_recrutamento.docx
diagramas_de_estados.docx
Diagramas de estados
* Diagrama de estados capturam os ciclos de vida de objetos: eles distinguem os estados que um objeto pode ter e quais os eventos (mensagem recebida, tempo, erros e condições verdadeiras) afetam esses estados ao mesmo tempo
* Um diagrama de estado existe para todas as classes que possuem, claramente, estados identificáveis e comportamentos complexos. Cada classe possui somente um diagrama de estados
* Todos objetos têm um estado
* O estado é o resultado de atividades anteriores realizadas pelo objeto, e é tipicamente determinada por valores de seus atributos
* Uma classe pode possuir um atributo específico para indicar o estado (forma explícita), como pode o estado ser determinado por valores de atributos “normais” no objeto (forma implícita)
- Exemplos de estados de objetos: O pedido (objeto) é atendido (estado);
O carro (objeto) está andando (estado); A máquina (objeto) está parada (estado).
* Um objeto muda de estado quando alguma coisa acontece, o que é chamado de evento
* Há duas dimensões de dinamicidade
Interação: descreve o comportamento externo do objeto e como ele interage com outros objetos (por exemplo, enviando mensagens)
Mudança de estado interno: descreve como os objetos têm alteração de estados através de eventos internos
Representação
- Diagramas de estado podem ter um ponto de início e vários pontos de encerramento
- Cada estado é representado, no diagrama, através de um retângulo com as bordas arredondadas
No Térreo
Subindo
Parado
Descendo
Indo para o
térreo
subir (andar)
Chegar no andar
subir (andar)
Chegar no andar
descer (andar)
tempo de espera
Chegar no térreo
diagrama_classes_associacao_feirantes.docx
exemplo_documentacao_caso_de_uso_manter_dados_de_cidades.doc
Caso de Uso: C01
Manter Dados de Cidades
Objetivo:
Incluir, alterar ou excluir dados de cidades.
Resumo:
Descreve as etapas percorridas pelo ator para incluir, alterar ou excluir uma cidade.
Ator Principal:
Nome-do-ator
Ator Secundário:
Nome-do-ator
Pré-Condições:
O ator deve iniciar a manutenção de cidades.
Pós-Condições:

Fluxo Principal:
Sistema exibe uma tela de cidades já cadastradas.
Ator seleciona a opção para incluir uma nova cidade. (A1) (A2)
Sistema apresenta a tela para inclusão da cidade (código, nome, cep geral,estado.)
Ator informa nome e cep geral
Ator seleciona o estado (RN1)
Ator seleciona a opção gravar. (A3)
Sistema valida campos (RN2)
Sistema grava no banco de dados os dados da nova cidade (com código gerado automaticamente).
Caso de uso é encerrado.
Fluxo Alternativo:
(A1) Ator seleciona uma cidade e a opção alterar.
Sistema coloca o registro em modo de edição.
Ator faz as alterações necessárias.
Ator seleciona a opção gravar. (A3)
Sistema salva as alterações efetuadas.
Caso de uso é encerrado.
(A2) Ator seleciona uma cidade e a opção excluir
Sistema apresenta os dados da cidade
Sistema pede confirmação para exclusão.
Ator confirma a exclusão. (A3)
Sistema exclui o registro. (RN3)
Caso de uso é encerrado.
(A3) Ator seleciona a opção cancelar
Sistema cancela a inclusão, exclusão ou edição do registro e volta ao passo 1 do fluxo principal.
Caso de uso é encerrado.
Restrições/Validações
RN1 RN1 - caso estado não esteja cadastrado executa C0? – Manter dados de estados
RN2 - se tiver campo não preenchido, indica campo a ser prenchido
RN3 - verifica se a cidade não está sendo usada por cliente e fornecedor; se sim, apresenta
mensagem e não exclui
R
Nome do caso de uso – C01
Manter Dados de Cidades
Ator Principal
Nome-do-ator
Atores Secundários
Nome-do-ator
Resumo
Descreve as etapas percorridas pelo ator para incluir, alterar ou excluir uma cidade.
Pré-Condições
O ator deve iniciar a manutenção de cidades.
Pós-Condições

Fluxo Principal (P) – incluir cidades
Ações do Ator
Ações do Sistema

1. exibe uma tela de cidades já cadastradas
2. seleciona a opção para incluir uma nova cidade. (A1) (A2)
3. apresenta a tela para inclusão da cidade (código, nome, cep geral,estado.)
4. informa nome e cep geral
5. seleciona o estado (RN1)
6. seleciona a opção gravar. (A3)
7. valida campos (RN2)
8. grava no banco de dados os dados da nova cidade (com código gerado automaticamente).
9. caso de uso é encerrado.
Fluxo Alternativo (A1) – alterar dados de cidades
Ações do Ator
Ações do Sistema
1. seleciona uma cidade e a opção alterar.

2. coloca o registro em modo de edição
3. faz as alterações necessárias.
4. seleciona a opção gravar. (A3)

5. salva as alterações efetuadas.
6. caso de uso é encerrado
Fluxo Alternativo (A2) – excluir dados de cidades
Ações do Ator
Ações do Sistema
1. seleciona uma cidade e a opção excluir.

2. apresenta os dados da cidade
3. pede confirmação para exclusão
4. confirma a exclusão. (A3)

5. exclui o registro. (RN3)
6. caso de uso é encerrado
Fluxo Alternativo (A3) – cancelar operação
Ações do Ator
Ações do Sistema
1. seleciona a opção cancelar.

2. cancela a inclusão, exclusão ou edição do registro e volta ao passo 1 do fluxo principal.
3. caso de uso é encerrado
Restrições/Validações (R)
RN1 - caso estado não esteja cadastrado executa C0? – Manter dados de estados
RN2 - se tiver campo não preenchido, indica campo a ser prenchido
RN3 - verifica se a cidade não está sendo usada por cliente e fornecedor; se sim, apresenta mensagem e não exclui
documentacao_caso_de_uso_manter_palestras.docx
Nome do caso de uso – C01
Manter Dados de Palestras
Ator Principal
Equipe de palestras, Palestrantes
Atores Secundários

Resumo
Descreve as etapas percorridas para incluir, alterar ou excluir dados de palestras (incluindo seus horários, palestrantes e equipamentos utilizados)
Pré-Condições
O ator deve iniciar a manutenção de palestras
Pós-Condições

Fluxo Principal (P) – incluir palestras
Ações do Ator
Ações do Sistema

1. exibe uma tela de palestras já cadastradas
2. seleciona a opção para incluir uma nova palestra (A1) (A2)
3. apresenta a tela para inclusão da palestra (código, título, assunto, duração)
4. informa título e duração em minutos
5. seleciona o assunto (RN1)
6. seleciona a opção gravar. (A3)
10. se não quer segue para o passo 20
12. seleciona palestrante (RN3)
13. seleciona opção gravar (A3)
17.se tem outro, retorna ao passo 11
19. se não tem segue para o passo 28
21. seleciona equipamento (RN5)
22. informa a quantidade
23. seleciona opção gravar (A3)
27. se tem outro, retorna ao passo 20
29. se não tem segue para o passo 38
31. informa data e horário
32. seleciona prédio e sala (RN7)
33. seleciona a opção gravar (A3)
37. se tem outro, retorna ao passo 30
7. valida campos (RN2)
8. grava no banco de dados os dados da nova palestra com geração automática do código.
9. exibe tela para verificar se já quer identificar palestrante
11. exibe tela para identificar palestrante
14. valida palestrante (RN4)
15. grava no banco de dados a associação palestrante/palestra
16. exibe tela para confirmação de outro palestrante
18.exibe tela para confirmar se tem equipamento
20. exibe tela para identificar equipamento (equipamento, quantidade)
24.valida equipamento (RN6)
25. grava no banco de dados a associação equipamento/palestra
26. exibe tela para confirmação de outro equipamento
28. exibe tela para verificar se já tem horário para cadastrar
30. exibe tela para informar horário (data, horário, prédio, sala)
34. valida horário (RN8) (RN9)
35. grava no banco de dados o horário
36. exibe tela para confirmação de outro horário
38. caso de uso é encerrado.
Fluxo Alternativo (A1) – alterar dados de palestras
Ações do Ator
Ações do Sistema
1. seleciona uma palestra e a opção alterar.

2. coloca o registro em modo de edição
3. faz as alterações necessárias.
4. seleciona a opção gravar. (A3)

5. salva as alterações efetuadas (com as devidas validações).
6. caso de uso é encerrado
Fluxo Alternativo (A2) – excluir dados de palestras
Ações do Ator
Ações do Sistema
1. seleciona uma palestra e a opção excluir.

2. apresenta os dados da palestra
3. pede confirmação para exclusão
4. confirma a exclusão. (A3)

5. exclui o registro. (RN10)
6. caso de uso é encerrado
Fluxo Alternativo (A3) – cancelar operação
Ações do Ator
Ações do Sistema
1. seleciona a opção cancelar.

2. cancela a inclusão, exclusão ou edição do registro e volta ao passo 1 do fluxo principal.
3. caso de uso é encerrado
Restrições/Validações (RN)
RN1 - caso assunto não esteja cadastrado executa C02 – Manter dados de assuntos
RN2 - indica campo(s)obrigatório(s) não preenchido(s) (todos obrigatórios)
RN3 - caso palestrante não esteja cadastrado executa C03 – Manter dados de palestrantes
RN4 - verifica se palestrante já não foi selecionado para a palestra
RN5 - caso equipamento não esteja cadastrado executa C04 – Manter dados de equipamentos
RN6 - verifica se quantidade igual a zero
RN7 - caso prédio/sala não esteja cadastrado executa C05 – Manter dados de prédios/salas
RN8 – verifica se prédio/sala já não está sendo usado para a mesma data e horário
RN9 – verifica se palestrante não está em outra palestra na mesma data e horário
RN10 – verifica se a palestra já ocorreu; se sim, apresenta mensagem e não exclui; se não exclui em cascata a palestra com todos os seus dados associados
Nome do caso de uso – C01
Manter Dados de Palestras
Ator Principal
Equipe de palestras
Atores Secundários

Resumo
Descreve as etapas percorridas para incluir, alterar ou excluir dados de palestras
Pré-Condições
O ator deve iniciar a manutenção de palestras
Pós-Condições

Fluxo Principal (P) – incluir palestras
Ações do Ator
Ações do Sistema

1. exibe uma tela de palestras já cadastradas
2. seleciona a opção para incluir nova palestra (A1) (A2)
3. apresenta a tela para inclusão da palestra (código, título, assunto, duração)
4. informa título e duração em minutos
5. seleciona o assunto (RN1)
6. seleciona a opção gravar. (A3)
09. se já quiser, seleciona opção para identificar palestrantes da palestra e executa Caso de Uso (C22) – Identificar palestrante da palestra
10. se já quiser, seleciona opção para identificar equipamentos da palestra e executa Caso de Uso (C23) – Identificar equipamentos da palestra
11. se já quiser, seleciona opção para definir horários da palestra e executa Caso de Uso (C24) – Definir horários da palestra
7. valida campos (RN2)
8. grava no banco de dados os dados da nova palestra (com código gerado automaticamente).
13. caso de uso é encerrado.
Fluxo Alternativo (A1) – alterar dados de palestras
Ações do Ator
Ações do Sistema
1. seleciona uma palestra e a opção alterar.

2. coloca o registro em modo de edição
3. faz as alterações necessárias.
4. seleciona a opção gravar. (A3)

5. salva as alterações efetuadas. (RN2)
6. caso de uso é encerrado
Fluxo Alternativo (A2) – excluir dados de palestras
Ações do Ator
Ações do Sistema
1. seleciona uma palestra e a opção excluir.

2. apresenta os dados da palestra
3. pede confirmação para exclusão
4. confirma a exclusão. (A3)

5. exclui o registro. (RN3)
6. caso de uso é encerrado
Fluxo Alternativo (A3) – cancelar operação
Ações do Ator
Ações do Sistema
1. seleciona a opção cancelar.

2. cancela a inclusão, exclusão ou edição do registro e volta ao passo 1 do fluxo principal.
3. caso de uso é encerrado
Restrições/Validações (R)
RN1 - caso assunto não esteja cadastrado executa C02 – Manter dados de assuntos
RN2 - indica campo(s) obrigatório(s) não preenchido(s) (todos obrigatórios)
RN3 - verifica se a palestra já ocorreu; se sim, apresenta mensagem e não exclui; se não exclui em cascata a palestra com todos os seus dados associados
documentacao_cadastrar_im?.docx
Nome do caso de uso – C01
Cadastrar imóvel
Ator Principal
Secretária, Proprietários
Atores Secundários

Resumo
Descreve as etapas percorridas para cadastrar um novo imóvel ou alterar algum dado do imóvel, inclusive seus proprietários
Pré-Condições
Proprietários(s) deve(m) deixar imóvel para alugar
Pós-Condições

Fluxo Principal (P) – cadastrar imóvel
Ações do Ator Proprietário
Ações do Sistema (Secretária)

01. pergunta se é um novo imóvel ou alteração de dados de imóvel já cadastrado
02. informa que é novo imóvel (A1)
03. solicita cópia do registro (escritura) do imóvel
04. apresenta a escritura (RN1)

Observação:
os passos de 06 a 11 só são descritos se a identificação de proprietários está dentro deste caso de uso, senão, ao invés da descrição destes passos deve ser realizado o Caso de Uso: Identificar Proprietários do Imóvel.
05. extrai da escritura
e transcreve para a ficha o endereço completo, a área, o tipo do imóvel, as características do imóvel
06. identifica o proprietário
07. pega a pasta com o cadastro do proprietário (A4)
08. anota na ficha cadastro do imóvel o nome do proprietário com o respectivo percentual de propriedade
09. verifica na escritura se tem outro proprietário
10. se tem, volta ao passo 06 do fluxo principal
11. confirma se a soma dos percentuais é igual a 100 (RN2)
12. pergunta ao proprietário o valor desejado pelo aluguel e a data para recebimento do valor do aluguel
13. proprietário informa

14. anota os dados na ficha cadastro
15. anota a forma padrão de reajuste
16. faz anotação de imóvel disponível
17. confere o preenchimento dos campos (RN3)
18. verifica preenchimento do cadastro (RN3)

19. guarda a ficha na pasta pertinente ao tipo do imóvel com situação disponível

20. Caso de uso encerrado
Fluxo Alternativo (A1) – alterar dados do imóvel
Ações do Ator
Ações do Sistema

01. pergunta qual o tipo do imóvel e o endereço
02. proprietário informa

03. pergunta se o imóvel está alugado
04. informa que sim (A5)

05. busca a pasta de imóveis não alugados do tipo e localiza pelo endereço
06. pergunta o que quer alterar (dados ou proprietários)
07. informa o que quer alterar (valor do aluguel, dia de vencimento, área, características) (A2)

08. anota novos dados
09. recoloca ficha na pasta e a guarda
10. caso de uso é encerrado
Fluxo Alternativo (A2) – alterar proprietários
Ações do Ator
Ações do Sistema

01. pergunta se é alteração somente de percentuais ou de proprietário
02. informa que é percentuais (A3)

03. pede os novos percentuais e altera, confirmando se o somatório é 100

04. confirma os novos percentuais
05. caso de uso é encerrado
Fluxo Alternativo (A3) – alterar proprietários
Ações do Ator
Ações do Sistema

01.solicita nome e percentual de propriedade
02. informa nome e percentual

Observação:
os passos de 03 a 06 só são descritos se a identificação de proprietários está dentro deste caso de uso, senão, ao invés da descrição destes passos deve ser realizado o Caso de Uso: Identificar Proprietários do Imóvel.
03. pega a pasta com o cadastro do proprietário (A4)
04. anota na ficha cadastro do imóvel o nome do proprietário com o respectivo percentual de propriedade
05. verifica se tem outro proprietário
06. se tem, volta ao passo 01 do fluxo alternativo A3
11. confirma se a soma dos percentuais é igual a 100 (RN2)
12. caso de uso é encerrado
Fluxo Alternativo (A4) – cadastrar proprietários

01. caso proprietário ainda não possua cadastro, realiza do Caso de Uso Cadastrar Pessoa
02. Retorna ao passo 08 do Fluxo Principal
Fluxo Alternativo (A5) – alterar dados de imóvel alugado

01. busca a pasta de imóveis alugados do tipo e localiza pelo endereço
02. pergunta o que quer alterar (dados ou proprietários)
03. informa o que quer alterar (valor do aluguel, dia de vencimento, área, características) RN4 (A2)

04. anota novos dados
05. recoloca ficha na pasta e a guarda
06. caso de uso é encerrado
Restrições/ Regras de Negócio/ Validações

RN1 - caso não possua a escritura, pode informar os dados básicos mas terá que trazer a mesma posteriormente para confirmar os dados
RN2 – se a soma dos percentuais é diferente de 100 confirma os valores corretos
RN3 – verifica se todos os campos obrigatórios foram preenchidos (a princípio todos devem ser preenchidos)
RN4 – se o contrato não está próximo de renovação, não pode ser alterado o valor e nem o dia de vencimento (pode ser feita uma observação na ficha do imóvel)
documentacao_cadastrar_imovel.docx
Nome do caso de uso – C01
Cadastrar imóvel
Ator Principal
Secretária, Proprietários
Atores Secundários

Fluxo Principal (P) – cadastrar imóvel
Ações do Ator Proprietário
Ações do Sistema (Secretária)

05. extrai da escritura e transcreve para a ficha o endereço completo, a área, o tipo do imóvel, as características do imóvel

Observação:
os passos de 06 a 11 só são descritos se a identificação de proprietários está dentro deste caso de uso, senão, ao invés da descrição destes passos deve ser realizado o Caso de Uso: Identificar Proprietários do Imóvel.
06. identifica o proprietário
07. pega a pasta com o cadastro do proprietário (A4)
08. anota na ficha cadastro do imóvel o nome do proprietário com o respectivo percentual de propriedade
09. verifica na escritura se tem outro proprietário
10. se tem, volta ao passo 06 do fluxo principal
11. confirma se a soma dos percentuais é igual a 100 (RN2)
12. pergunta ao proprietário o valor desejado pelo aluguel e a data para recebimento do valor do aluguel
13. proprietário informa

14. anota os dados na ficha cadastro
15. anota a forma padrão de reajuste
16. confere o preenchimento dos campos (RN3)
17. verifica preenchimento do cadastro (RN3)

18. guarda a ficha na pasta pertinente ao tipo do imóvel

19. Caso de uso encerrado
Fluxo Alternativo (A1) – alterar dados do imóvel
Ações do Ator
Ações do Sistema

01. pergunta qual o tipo do imóvel e o endereço
02. proprietário informa

03. busca a pasta do tipo e localiza pelo endereço
04. pergunta o que quer alterar
05. informa valor do aluguel e/ou data de vencimento (A2)

06. verifica se imóvel não está alugado (RN4)
07. anota novos dados
08. coloca fica na pasta e a guarda
09. caso de uso é encerrado
Fluxo Alternativo (A2) – alterar proprietários
Ações do Ator
Ações do Sistema

01. pergunta se é alteração somente de percentuais ou de proprietário
02. informa que é percentuais (A3)

03. pede os novos percentuais e altera, confirmando se o somatório é 100

04.confirma os novos percentuais
05. caso de uso é encerrado
Fluxo Alternativo (A3) – alterar proprietários
Ações do Ator
Ações do Sistema

01.solicita nome e percentual de propriedade
02. informa nome e percentual

Observação:
os passos de 03 a 06 só são descritos se a identificação de proprietários está dentro deste caso de uso, senão, ao invés da descrição destes passos deve ser realizado o Caso de Uso: Identificar Proprietários do Imóvel.
03. pega a pasta com o cadastro do proprietário (A4)
04. anota na ficha cadastro do imóvel o nome do proprietário com o respectivo percentual de propriedade
05. verifica na escritura se tem outro proprietário
06. se tem, volta ao passo 01 do fluxo alternativo A3
11. confirma se a soma dos percentuais é igual a 100
(RN2)
12. caso de uso é encerrado
Fluxo Alternativo (A4) – cadastrar proprietários

01. caso proprietário ainda não possua cadastro, realiza do Caso de Uso Cadastrar Pessoa
02. Retorna ao passo 08 do Fluxo Principal
Restrições/Validações (R)
RN1 - caso não possua a escritura, pode informar os dados básicos mas terá que trazer a mesma posteriormente para confirmar os dados
RN2 – se a soma dos percentuais é diferente de 100 confirma os valores corretos
RN3 – verifica se todos os campos obrigatórios foram preenchidos (a princípio todos devem ser preenchidos)
RN4 – se o imóvel está alugado e não está próximo do reajuste, não pode ser alterado o valor (pode ser feita uma observação na ficha do imóvel)
documentacao_manter_contrato_prestacao_servico.docx
Nome do caso de uso – C01
Manter Dados de Contrato de Prestação de Serviços
Ator Principal
Gerente, Proprietários
Atores Secundários

Resumo
Descreve as etapas percorridas para incluir, alterar ou excluir dados de contratos de prestação de serviços
Pré-Condições
O ator deve iniciar a manutenção do contrato
Pós-Condições

Fluxo Principal (P) – incluir contrato
Ações do Ator
Ações do Sistema

01. exibe uma tela de contratos de prestação de serviços já cadastrados
(número do contrato e endereço do imóvel, data do contrato)
02. seleciona a opção para incluir um novo contrato (A1) (A2)
03. apresenta a tela para inclusão de um contrato (código, imóvel, taxa de serviço, duração do contrato, data do contrato)
04. seleciona imóvel (RN1)
05. informa taxa de serviço, duração do contrato e data do contrato
06. seleciona OK (A3)

07. apresenta tela com os dados do imóvel e de seus proprietários e mais os campos taxa de serviço, duração do contrato, data do contrato
08. seleciona a opção gravar. (RN2) (A3)

09. valida campos (RN3)
10. grava no banco de dados os dados do novo contrato
11. Realiza Caso de Uso Imprimir Contrato
12. Realiza Caso de Uso Emitir Procuração
13. Caso de Uso é encerrado
Fluxo Alternativo (A1) – alterar dados de contratos
Ações do Ator
Ações do Sistema
1. seleciona um contrato e a opção alterar

2. coloca o registro em modo de edição (mostra dados do imóvel, dados do(s) proprietário(s), taxa de serviço, duração do contrato, data do contrato)
3. faz as alterações necessárias em taxa de serviço e/ou duração do contrato e/ou data do contrato
4. se for necessário alterar dados do imóvel ou do(s) proprietário(s), Executa Caso de Uso C02 - Manter Dados do Imóvel e retorna ao passo 2 do fluxo alternativo A1
5. seleciona a opção gravar. (A3)

5. valida campos (RN3)
6. salva as alterações efetuadas
7. Executa Caso de Uso Imprimir Contrato
8. caso de uso é encerrado
Fluxo Alternativo (A2) – excluir dados de contratos
Ações do Ator
Ações do Sistema
1. seleciona um contrato e a opção excluir.

2. apresenta os dados do contrato (mostra dados do imóvel, dados do(s) proprietário(s), taxa de serviço, duração do contrato, data do contrato)
3. pede confirmação para exclusão
4. confirma a exclusão. (A3)

5. exclui o registro. (RN4)
6. caso de uso é encerrado
Fluxo Alternativo (A3) – cancelar operação
Ações do Ator
Ações do Sistema
1. seleciona a opção cancelar.

2. cancela a inclusão, exclusão ou edição do registro e volta ao passo 1 do fluxo principal.
3. caso de uso é encerrado
Restrições/Validações (R)
RN1 - caso Imóvel não esteja cadastrado executa C02 – Manter dados de Imóveis
RN2 – caso os dados do imóvel ou do(s) proprietário(s) tenham problema, Executa Caso de Uso C02 – Manter Dados do Imóvel e retorna ao passo 07 do Fluxo Principal
RN3 – verifica se os campos obrigatórios foram preenchidos (campos imóvel, taxa de serviço, duração do contrato, data do contrato); se tiver campo não preenchido, sinaliza o campo e retorna ao passo 4 do fluxo principal
RN4 – verifica se existe Contrato de Aluguel ativo para o imóvel em questão; se sim, apresenta mensagem e não exclui
diagrama_de_estados.jpg
diagrama_de_estados_exemplo.docx
Diagrama de Estados.
Um diagrama de estados mostra os possíveis estados de um objeto e as transações responsáveis pela mudança de seu estado.
A figura 1, diagrama de estados de contas a receber, mostra os possíveis estados da conta que uma empresa tem a receber de seus clientes.
atividade_discente_1_passo_fundo.docx
Atividade discente - Projeto de Software Orientado a Objetos (2014 I)
Resolva as questões abaixo considerando o projeto do software. Resolva as questões 1 a 5 para a primeira atividade a ser entregue no dia 03/06/2014 e as questões 6 a 11 para a segunda atividade a ser entregue no dia 10/06/2014.
1. Considere o seguinte texto: Uma quituteira faz doces e salgados por encomenda. Quando um cliente faz uma encomenda ela anota numa agenda, na data solicitada, os dados do cliente, a hora para a entrega e os produtos encomendados (produto e quantidade). Cabe lembrar que produto é o resultado da realização de uma receita. Se o cliente for bem conhecido, a quituteira aceita a reserva da encomenda para a data, sem a indicação do que será encomendado, podendo isso ser informado posteriormente.
a) Identifique os requisitos funcionais para o projeto do software
Manter dados de clientes
Manter dados de cidades
Manter dados de produtos (receitas)
Manter dados de encomendas
Identificar produtos encomendados
b) Apresente o diagrama de Casos de Uso correspondente
2. Na empresa Pneus e Serviços PIT STOP além da venda de pneus são prestados serviços de borracharia. No momento em que um cliente se dirige até a borracharia, na maioria das vezes, se ele não tiver cadastro então é preenchido, no computador, um cadastro com os dados pessoais do mesmo. Depois de cadastrado, o cliente pede os serviços que quer que sejam prestados e então tudo que o ele fizer será anotado em uma ordem de serviço que é composta de vários campos onde devem ser preenchidos: a data, o tipo do veículo (caminhão, carro ou caminhonete) e a placa e o nome do cliente. Nesta ordem existe uma tabela que contém as seguintes colunas: tipo de serviço, onde existe uma lista de serviços que a borracharia realiza (como exemplo: troca de bico de rodoar, conserto de câmara, troca de pneu, etc.); quantidade (onde se deve preencher a quantidade do serviço que foi realizado); descrição (campo opcional que só é preenchido se houver necessidade e onde se faz uma breve descrição do serviço realizado); valor (que corresponde ao valor cobrado para cada serviço, considerando a multiplicação do preço unitário do serviço pela quantidade); e por último, total, onde se faz a soma de todos os serviços realizados e anota-se o valor total que o cliente terá de pagar.
a) Defina o objetivo geral para o projeto do software
O software visa melhorar o funcionamento da empresa, agilizando os serviços realizados, propiciando dados confiáveis e seguros, facilitando a geração e emissão das ordens de serviço, permitindo assim um melhor controle financeiro e auxílio na tomada de decisões.
ou
O software visa melhorar a organização da empresa e agilizar os procedimentos realizados, auxiliando no gerenciamento das ordens de serviço, fornecendo informações precisas e confiáveis, possibilitando análises e auxílio à tomada de decisões, além de facilitar as consultas aos dados. Visa, também, facilitar o gerenciamento financeiro,
tornando-a, assim, mais competitiva no mercado.
b) Identifique os requisitos funcionais
Manter dados de clientes
Manter dados de cidades
Manter dados de serviços
Manter dados da ordem de serviço (OS)
Identificar serviços da OS
Emitir OS
c) Apresente a documentação do Caso de Uso Manter Dados da Ordem de Serviço. Utilize formato numerado ou tabular e grau de detalhamento expandido.
Caso de Uso: C01
Manter Dados da Ordem de Serviço
Objetivo:
Incluir ordem de serviço e os serviços realizados. É possível também alterar e excluir uma ordem de serviço
Resumo:
Descreve as etapas percorridas pelo ator para incluir, alterar e excluir uma ordem de serviço
Ator Principal:
Cliente, Funcionário
Pré-Condições:
Iniciar a Manutenção de ordem de serviço
Pós-Condições:

Fluxo Principal: Incluir Ordem de Serviço
Sistema apresenta tela com ordens de serviços cadastradas
Ator seleciona Incluir OS (A1)(A2)(A3)
Sistema apresenta tela para preenchimento de número de OS, data, nome do cliente, endereço, o tipo do veículo (caminhão, carro ou caminhonete) e a placa
Ator informa a data e a placa do veículo
Ator seleciona cliente (RN1)
Ator seleciona tipo de veículo
Ator seleciona gravar (A4)
Sistema valida campos obrigatórios (RN2)
Sistema grava OS com número gerado automaticamente e Valor Total da OS = 0 (zero)
Sistema apresenta botão para Incluir (Identificar) Serviços da Ordem
Ator não deseja incluir itens no momento (A5)
Caso de uso é encerrado.
Fluxo Alternativo A1: alterar OS
Falta descrever (lembrar que se for alterar os itens de serviço vai alterar também o valor total)
Fluxo Alternativo A2: excluir OS
Ator seleciona OS e a opção excluir
Sistema apresenta OS e seus itens na tela
Sistema pede confirmação de exclusão
Ator confirma (A4)
Sistema verifica que OS já foi paga (RN4)
Se OS paga, sistema exclui a OS, os serviços da OS e registros de pagamentos associados
Caso de uso encerrado
Fluxo Alternativo A3: sair do processo
Ator seleciona Sair do processo
Sistema pede confirmação
Ator confirma (A4)
Sistema retorna ao Menu Principal
Caso de uso encerrado
Fluxo Alternativo A4: cancelar operação
Ator seleciona cancelar operação de inclusão, alteração e exclusão
Sistema retorna ao passo 1 do fluxo principal
Caso de uso encerrado
Fluxo Alternativo A5: incluir itens de serviços
Sistema apresenta tela para preenchimento do tipo do serviço, descrição do tipo, quantidade, observações, preço do serviço e valor do item
Ator seleciona tipo
Sistema apresenta a descrição do tipo e o preço do serviço
Ator informa quantidade e observações (RN3)
Sistema calcula valor do item (quantidade x preço do serviço) e apresenta
Sistema acumula valor total da OS (valor total da OS = valor total da OS + valor do item)
Ator seleciona incluir item
Sistema verifica se já existe este item na ordem
Se existe cancela o item e segue para o passo 22
Sistema associa item à ordem
Sistema apresenta valor total da OS
Ator seleciona incluir novo item (A6)
Sistema volta ao passo 1do fluxo alternativo A1
Fluxo Alternativo A6: encerrar OS
Ator seleciona encerrar OS
Sistema pergunta se quer imprimir OS
Ator informa que sim (RN5)
Sistema Executa Caso de Uso Imprimir OS
Caso de uso encerrado
Restrições/Validações
RN1 RN1 – caso o cliente não tenha cadastro, realiza o Caso de Uso Manter dados de Cliente
RN2 – Todos os campos são obrigatórios
RN3 – Observação é opcional
RN4 – Se OS ainda não paga, não permite excluir e apresenta mensagem
RN5 – uma OS pode ser impressa posteriormente
3. Num salão de beleza, para o cliente ser atendido ele deve já possuir uma ficha cadastral com seus dados pessoais. Antes de iniciar o atendimento a recepcionista prepara uma ficha de serviços onde coloca o código do cliente e a data. Esta ficha de serviços já possui todos os serviços oferecidos pré-impressos. De posse da ficha de serviços, o cliente é encaminhado para o(s) devido(s) profissional(is). O profissional ao realizar o serviço anota na ficha de serviços do cliente o seu nome ao lado de cada serviço por ele efetuado. Ao final do atendimento o cliente apresenta a ficha para a recepcionista que calcula o valor devido e apresenta o valor ao cliente, que poderá pagar naquele momento (a recepcionista coloca um carimbo de PAGO na ficha) ou então anotar em sua ficha para pagamento posterior. Caso a recepcionista não esteja presente, um profissional pode preencher a ficha cadastral do cliente, preparar a ficha de serviços e fazer o fechamento da conta.
Para o texto apresentado:
a) Identifique os requisitos funcionais para o projeto do software
Manter dados de clientes
Manter ficha de serviços
Manter tabela de serviços
Informar serviços realizados
Manter dados de profissionais
Calcular valor devido
Registrar pagamentos
Manter conta a receber
b) Apresente o Diagrama de Casos de Uso
4. Uma empresa disponibiliza telefones celulares para os funcionários através de um plano de telefonia empresarial. O controle de telefonia é realizado por uma secretária que possui, para cada operadora de telefonia, uma lista de aparelhos disponibilizados pela mesma. Esta lista ela faz usando um editor de textos e nela consta (para cada operadora) o modelo do aparelho, sua descrição e marca. Quando o funcionário tem interesse em algum aparelho a secretária faz um cadastro identificando o nome do funcionário e o seu setor de trabalho dentro da empresa (caso ele ainda não possua este cadastro). Após o funcionário escolhe um aparelho e um plano de uso, dentre os constantes em listas que a secretária apresenta (também feitos usando um editor de textos) e que são fornecidos pelas operadoras; cada plano define condições de uso e valores. A secretária prepara e o funcionário assina uma autorização de desconto em folha mensal dos gastos com telefonia efetuados por ele. Ao final de cada mês cada operadora envia uma lista com todas as ligações e o valor total de cada funcionário. A secretária prepara e entrega para cada funcionário um comprovante indicando todas as suas ligações e o valor total. Prepara também uma lista com o nome do funcionário e o valor total e envia para o RH da empresa (que providenciará a cobrança descontando do salário do funcionário).
Para o texto apresentado:
Defina o objetivo geral para o projeto do software
O software visa melhorar o controle do plano de telefonia empresarial, agilizando os contratos realizados, propiciando dados confiáveis e seguros, facilitando a geração e emissão das autorizações e dos comprovantes de ligações, agilizando a comunicação com o RH permitindo assim um melhor controle financeiro.
Ou
O sistema desenvolvido tem como objetivo, em especial, um melhor gerenciamento do uso de planos de telefonia pelos funcionários, através da atualização contínua das informações, que garantirão a confiabilidade e a integridade dos dados, propiciando a agilidade dos trabalhos realizados na empresa e facilitando o controle financeiro.
Identifique os requisitos funcionais para o projeto do software
Manter dados de funcionários
Manter dados de setores
Manter dados de operadoras
Manter dados de planos
Manter dados de aparelhos
Manter dados de modelos de aparelhos
Manter dados de marcas
Manter dados de contratos
Manter dados de uso
Listar aparelhos por operadora
Listar planos
Emitir comprovante de uso
Emitir autorização
Gerar lista de cobrança
Manter dados de cidades
Manter dados de estados
Manter dados de países
Identifique os requisitos não funcionais para o projeto do software
- O sistema deve ser simples para que pessoas com conhecimento básico em informática possam usar.
- O sistema implantado deverá ter segurança, podendo assim somente pessoas autorizadas terem acesso (com controle de permissões de acesso).
- O tempo de resposta das solicitações feitas pelo usuário que tem o devido acesso, não poderá passar de cinco segundos.
- O sistema deve possuir interface intuitiva e amigável.
- O Banco de Dados será XXX;
- A linguagem de programação é YYY;
- O sistema operacional será ZZZ; (pode ser pensado em portabilidade em função de sistema operacional e hardware)
- Ferramenta de modelagem utilizada para a construção dos diagramas da UML: Astah;
- Outros Softwares utilizados: Microsoft Office;
Apresente o Diagrama de Casos de Uso
5. Apresente o Diagrama de Atividades do Caso de Uso Manter Ficha de Consultas considerando o texto que segue. Num consultório médico cada paciente possui um envelope identificado com seu nome no qual são guardadas as fichas de consulta. A cada consulta feita é preenchida uma ficha onde são anotados o peso, a temperatura, a pressão arterial do paciente e os sintomas que ele apresenta, bem como o resultado do exame clínico feito, que define o provável diagnóstico (nome de uma ou mais doenças, de acordo com o Cadastro Internacional de Doenças); se houver necessidade é solicitada a realização de algum tipo de exame (é anotado na ficha o nome de cada exame solicitado e quando vem o resultado são feitas anotações complementares); se for indicado algum tratamento, é anotado o nome de cada remédio com a correspondente dosagem. Esta ficha não tem campos pré-estabelecidos; é uma ficha pautada onde o médico vai descrevendo a consulta e seu encaminhamento; se o espaço da ficha termina, ele pega outra ficha (todas ficam guardadas dentro do mesmo envelope). Se necessário, ao final da consulta o médico elabora um atestado, onde indica o nome do paciente, a data (ou período) de validade do atestado e o diagnóstico identificado.
Este é da engenharia de requisitos – ainda não tive tempo de fazer o do projeto do software.
diagrama_de_atividades.ppt
*
UML
Diagrama de atividades
É utilizado para criar boas descrições de casos de uso, ou seja, é a especificação de um caso de uso
É aproximadamente equivalente a um algoritmo
Dificilmente haverá um diagrama de atividades para todos os casos de uso de um sistema
*
*
UML
Diagrama de atividades
Utiliza-se para os casos de uso em cenários mais complexos, em que o negócio a ser modelado é de difícil compreensão
Um caso de uso interpretado ou escrito de maneira equivocada gerará um diagrama de atividades igualmente equivocado
Ao escrever o diagrama de atividades pode ser necessário retornar ao caso de uso para reescrevê-lo
*
*
UML
Diagrama de atividades (composição)
É composto de vários elementos
*
Representa uma atividade
Representa passagens de uma atividade para outra
Representa uma decisão
Representa o ponto de entrada de um processo
Representa o ponto de saída de um processo
Representa o fork, onde uma atividade foi dividida em mais de uma
Representa o join, onde mais de uma atividade foram unidas em uma
*
*
*
*
*
*
Calcular
valor total
Efetuar
compra
[se valor < 100]
Solicitar
aprovação
[se valor >= 100]
[ se aprovado]
[ se não aprovado]
*
Realizar matrícula
*
*
Realizar pedidos e pagamentos fast-food on line
*
*
Login e Logout
*
*
Incluir e Excluir Clientes
*
*
Alterar Cliente , Selecionar e Visualizar Modelos
*
*
Gerar contrato de venda – Plano de Saúde
*
diagrama_atividades_media_final.docx
diagrama_atividades_media_semestral.docx
exemplo_documentacao_caso_de_uso_ficha_crediario__analise.doc
Caso de Uso: C01
Cadastrar clientes
Objetivo:
Preencher o cadastro do cliente
Resumo:
Descreve as etapas percorridas pelo ator para cadastrar um cliente, alterar seus dados ou excluí-lo.
Ator Principal:
Cliente, Funcionário
Ator Secundário:

Pré-Condições:
O funcionário solicita a documentação do cliente
Pós-Condições:

Fluxo Principal:
Funcionário inicia o preenchimento do cadastro. (A1) (A2)
Funcionário preenche o nome do cliente, filiação, data de nascimento, sexo, CPF e rg.
Funcionário solicita outros dados.
Cliente informa endereço completo, telefone e estado civil.
Funcionário solicita nomes de bancos e lojas onde o cliente tem conta.
Cliente informa dados.
Funcionário preenche os campos do cadastro.
Funcionário pede nome, telefone e endereço de uma pessoa como referência.
Cliente informa.
Funcionário solicita nome e RG de pessoas autorizadas.
Cliente informa nome e RG de cada pessoa que ele autoriza.
Funcionário preenche o valor de salário do cliente.
Funcionário consulta SPC.
Se tudo certo, cliente assina a ficha cadastro, se não o cadastro é cancelado.
Caso de uso é encerrado.
Fluxo Alternativo:
(A1) Funcionário altera dados do cliente.
Funcionário confirma os dados do cliente.
Se tiver alguma informação desatualizada, funcionário altera os dados, solicitando comprovantes, se for o caso.
Caso de uso é encerrado.
(A2) Funcionário exclui dados do cliente.
Funcionário verifica as fichas cadastro de clientes.
Se o cliente não tem compras nos últimos 5 anos, exclui o cadastro.(RN1)
Caso de uso é encerrado.
Restrições/Validações
RN1 RN1 - Se o cliente tiver algum débito, encaminha para o setor financeiro e não exclui.
diagrama_de_classes.doc
Diagrama de classes
- é o mais utilizado da UML; é o mais rico em termos de notação
- utilizado na construção do modelo de classes desde o nível de análise até o nível de especificação
- seu objetivo é permitir a visualização das classes utilizadas pelo sistemas (os tipos de objetos do sistema) e os vários tipos de relacionamentos que existem entre elas
- mostra atributos e operações das classes e as restrições à maneira com que os objetos são conectados.
- considerado estático: a estrutura descrita é sempre válida, em qualquer ponto do ciclo de vida do sistema
- apresenta a visão estática de como as classes estão organizadas, definindo sua estrutura lógica
- pode ser utilizado para definir o modelo lógico de um banco de dados, quando se assemelha a um MER
- importante salientar que uma classe não corresponde a uma tabela em um BD
- eventualmente uma classe pode representar repositório lógico dos atributos de uma tabela, no entanto, a classe não é a tabela, uma vez que os atributos de seus objetos são armazenados em memória, ao passo que uma tabela armazena seus registros fisicamente em disco
- além disso, uma classe possui métodos (que não existem numa tabela)
- em um modelo lógico de BD, os métodos de uma classe podem corresponder às operações que serão realizadas sobre a tabela
Classes
- uma classe é representada como um retângulo subdividido em, no máximo, 3 compartimentos separados por linhas horizontais que nessa ordem armazenam:
* o nome da classe (no singular),
* os atributos da classe (informações que um objeto armazena) e
* as operações (ações que um objeto sabe realizar)
Nome_da_Classe

Evento
Observações:
- se necessário, compartimentos podem ser nomeados, cujos nomes devem ser representados com uma fonte diferente, centralizados no topo do compartimento
atributos
nome
horaInicio
duração
dataRealizacao
descricao

- compartimentos adicionais (não definidos pela UML) podem ser incluídos e usados como extensões das ferramentas de modelagem, com o intuito de exibir outras informações do modelo, como regras de negócios, responsabilidades, exceções, etc. A maior parte desses compartimentos exibe apenas uma lista de strings, entretanto são possíveis outros formatos definidos pelas ferramentas
operações
cadastraEvento()
remarcarEvento()

- a UML permite que em algumas visualizações os detalhes sejam omitidos, isto é, é possível mostrar: apenas o nome da classe ou o nome da classe e seus atributos ou o nome da classe e suas operações (o nome é obrigatório)
responsabilidades
Controla o cadastro de ...

- a UML define algumas normas de estilo como:
* nome da classe centralizado e negritado
* para todas as linguagens que distinguem entre caracteres minúsculos e maiúsculos, escrever as iniciais dos nomes das classes em maiúsculas, inclusive as primeiras letras de nomes compostos (ex. AlunoUniversitario, PessoaFisica, Funcionario)
*os atributos e as operações devem ser escritos com formatação normal e alinhados à esquerda
* os nomes de atributos e operações devem iniciar com letra minúscula, entretanto as iniciais das palavras compostas seguintes devem iniciar com letra maiúscula (ex. reajustarSalario, matricular, dataNascimento, salário)
Relacionamentos / Associações
- as classes dentro do contexto da modelagem de um sistema, na sua maioria, não trabalham sozinhas
- as classes costumam possuir relacionamentos entre si, chamados associações, que as permitem compartilhar informações e colaborar para a execução dos processos pelo sistema
- a existência de um relacionamento entre 2 objetos possibilita a troca de mensagens
- uma associação descreve um vínculo que ocorre entre os objetos de uma ou mais classes
- associações são representadas por linhas ligando as classes envolvidas, podendo também possuir setas em suas extremidades para indicar a navegabilidade da associação; podem possuir títulos para determinar o tipo de vínculo estabelecido entre os objetos da classe
- no diagrama de classes tem-se os relacionamentos de associação, generalização e dependência
- como variação do relacionamento de associação ainda é possível modelar relacionamentos de agregação e composição
Associação
- é um relacionamento que conecta duas (associação binária) ou mais classes (associação ternária ou de ordem-n), demonstrando a colaboração entre as instâncias de classe
( Associação binária : conecta exatamente duas classes; é o relacionamento entre objetos de duas classes. Ex: uma cidade possui diversos alunos; é uma associação entre as classes Cidade e Aluno

( Associação unária ou reflexiva : é um tipo de associação binária de uma classe com ela própria; existe um relacionamento de um objeto da classe com objetos da mesma classe. Ex: um funcionário tem um supervisor que também é um funcionário, portanto tem-se uma associação da classe Empregado com ela própria
( Associação ternária ou N-ária : possui mais de duas classes ligadas pelo relacionamento; conectam objetos de mais de duas classes. São representadas por um losango para o qual convergem todas as ligações da associação. Ex: Professor-Turma-Sala de Aula
Em UML a associação pode ser de 3 tipos diferentes: associação simples (exemplos anteriores), agregação e composição
( Agregação : Usada para denotar relacionamento todo/parte, pode ocorrer somente entre duas classes. É identificável a partir da notação de uma linha sólida entre as duas classes, a classe denominada todo-agregado recebe um losango (diamante) vazio, enquanto a outra ponta da linha é ligada à classe denominada parte-constituinte. Tenta-se demonstrar que as informações de um objeto (chamado objeto-todo ou todo-agregado) podem ser complementadas pelas informações contidas em um ou mais objetos de outra classe (chamados objeto-parte ou parte-constituinte). A destruição de um objeto todo não implica necessariamente a destruição do objeto parte. Por exemplo, na fig abaixo, se uma das equipes das quais um jogador é membro for extinta por algum motivo, este jogador ainda poderá continuar membro de outras equipes.
Outro exemplo:
O exemplo abaixo mostra uma agregação compartilhada, na qual o componente parte está associado como agregação de vários conceitos ao mesmo tempo.
( Composição : Usada para denotar relacionamento todo/parte, pode ocorrer somente entre duas classes. É identificável a partir da notação de uma linha sólida entre as duas classes, a classe denominada todo-composta recebe um losango (diamante) cheio (preenchido), enquanto a outra ponta da linha é ligada à classe denominada parte-componente. Tenta-se demonstrar que as informações de um objeto (chamado objeto-todo ou todo-composto) devem ser complementadas pelas informações contidas em um ou mais objetos de outra classe (chamados objeto-parte ou parte-componente). Objetos-parte não podem ser destruídos por um objeto diferente do objeto-todo. Na composição os objetos parte pertencem a um único todo. Ex: Item_Empréstimo com Empréstimo
Importante:
Agregação e composição são associações especiais e devem ser usadas com muito cuidado no modelo, isto é, só se deve usar quando se tem certeza. Erros comuns são associar por agregação elementos que não constituem parte-todo. Por exemplo, um cliente não é parte de um empréstimo, visto que um cliente é um ente físico e um empréstimo é uma transação. Agregações e composições devem unir elementos de mesma natureza. Como outro exemplo, pode-se citar que um DVD não faz parte de uma reserva, pois o DVD é um objeto físico e a reserva mais uma vez é uma transação. Um DVD associa-se a uma reserva, mas uma reserva não é feita de DVDs. Já um empréstimo, pode-se dizer, é feito de itens de empréstimo, pois são elementos de mesma natureza (transações).
( Generalização / Especialização : Indica relacionamento entre um elemento mais geral (classe-mãe ou superclasse) e um elemento mais específico (classe-filha ou subclasse), demonstrando a ocorrência de herança e possivelmente de métodos polimórficos nas subclasses. O elemento mais específico pode conter somente informação adicional acerca do elemento mais geral. No diagrama de classes é representada por uma flecha partindo da subclasse em direção à superclasse. Alternativamente pode-se juntar as flechas de todas as subclasses de uma classe. Ex: Cliente – Cliente_Físico – Cliente_Jurídico
( Dependência : Identifica um certo grau de dependência de uma classe em relação à outra. Relacionamento entre elementos, um independente e outro dependente, onde uma mudança no elemento independente afetará o elemento dependente. Representado por uma linha tracejada entre duas classes, contendo uma seta apontando para a classe da qual a classe posicionada na outra extremidade do relacionamento é dependente. Nas classes as dependências existem por várias razões: uma classe manda uma mensagem para outra; uma classe tem outra como parte de seus dados; uma classe menciona uma outra como um parâmetro para uma operação. Se uma classe muda a sua interface, qualquer mensagem que ela mande pode não ser mais válida.
( Associativa : Classes associativas são classes que estão ligadas a associações, em vez de estarem ligadas a outras classes. Classes associativas são produzidas quando ocorrem associações que possuem multiplicidade muitos (*) em todas as suas extremidades. Utilizada para denotar relacionamentos entre
classes correlatas. Conexão semântica entre tuplas de objetos. Representada por uma linha tracejada ligada a uma associação. Uma classe associativa pode ser substituída por uma classe comum.
Características importantes:
( Multiplicidade: Quantidade de correspondência de um objeto na classe A em objetos equivalentes na classe B. Cada associação possui 2 multiplicidades, uma em cada extremo da linha que a representa.

Existem infinitas possibilidades de associação ente objetos; estas associações podem ser agrupadas em apenas 3 tipos: “muitos para muitos”, “um para muitos”, “um para um”.
( Conectividade: tipo de associação entre 2 classes. A conectividade depende dos símbolos de multiplicidade que são utilizados na associação.
Conectividade
Multiplicidade de um extremo
Multiplicidade de outro extremo
Um para um
0..1 ou 1
0..1 ou 1
Um para muitos
0..1 ou 1
* ou 1..* ou 0..*
Muitos para muitos
* ou 1..* ou 0..*
* ou 1..* ou 0..*
( Navegabilidade : representa o sentido em que as informações são transmitidas entre os objetos das classes envolvidas. Utiliza uma seta na extremidade. Ex: Pedido ( Cliente . Um pedido tem a responsabilidade de informar a qual cliente pertence, mas um cliente em particular não tem a habilidade correspondente de dizer quais pedidos possui.
� EMBED Word.Document.8 \s ���
_1427215074.doc
Multiplicidade
Significado
0..1
zero ou um
1
somente 1
0..*
maior ou igual a zero
*
maior ou igual a zero
1..*
maior um igual a um
1..15
de 1 a 15, inclusive
23..*
acima de 23 (inclusive)
projeto_de_software_em_camadas.ppt
*
Projeto de Software em Camadas
Prof. Cristiano Roberto Cervi
Profª. Jane Costi Colossi
Universidade de Passo Fundo
Instituto de Ciências Exatas e Geociências
*
*
Introdução
A separação de um software em camadas surgiu na década de 90 com os sistemas com arquitetura cliente-servidor
Nesses sistemas, existem geralmente duas camadas
Interface gráfica com o usuário
Persistência
Geralmente um banco de dados relacional
*
*
Introdução
Ferramentas comuns para o lado Cliente eram
Delphi
Visual Basic
Power Builder
Essas ferramentas tornaram fácil a criação de aplicações que faziam o uso intensivo de dados
Disponibilizavam componentes visuais que trabalhavam com SQL
O problema surgiu com a lógica de domínio
Regras de negócio
Validações
Cálculos
A lógica era feita diretamente nas telas da interface com o usuário
Há 2 possibilidades de implementação para esses sistemas
*
*
Possibilidade 1
Lógica da aplicação estar embutida junto com o código da interface gráfica com o usuário
 Com o crescimento dos sistemas, bem como o aumento da complexidade, essa técnica pode gerar problemas:
Grande quantidade de redundâncias, principalmente em nível de programação
Uma pequena mudança pode ter um impacto enorme na aplicação
 Isso é o que se pretende evitar em sistemas corporativos
*
*
Possibilidade 2
Colocar a lógica da aplicação em stored procedures* no banco de dados
 Essa solução também tem suas desvantagens
Perda de portabilidade
Dificuldade de trabalhar com transações quando está envolvido mais de um SGDB
* Procedimentos Armazenados
- Funções que os SGBDs possuem para realização de alguma tarefa no banco de dados
- Podem encapsular a lógica de negócio da aplicação
*
*
Como resolver ???
Diante desses problemas, surgiu a necessidade de se evoluir para o desenvolvimento em três camadas
► Camada de Apresentação
► Camada de Acesso aos Dados
(ou camada de persistência)
► Camada de Domínio
*
*
Como resolver ???
Martin Fowler diz, em Fowler (2006) que o “abalo sísmico” para tal evolução foi o advento da Web ... As pessoas passaram a querer utilizar aplicações cliente-servidor usando um navegador Web
Se toda a lógica do negócio estiver na aplicação cliente, toda ela precisaria ser refeita para haver uma interface Web
Um sistema bem projetado, em 3 camadas, poderia simplesmente acrescentar uma nova camada de apresentação e estaria pronto
*
*
As 3 camadas
Camada de Apresentação
Como tratar a interação entre o usuário e o software
Definição da interface gráfica com o usuário
Definição da lógica por trás da interface
Tem a responsabilidade de exibir informações para o usuário e traduzir comandos do usuário em ações sobre o domínio do sistema e a camada de dados
*
*
As 3 camadas
Camada de Acesso aos Dados
(ou camada de persistência)
Forma de armazenamento dos dados
Lógica para manipulação dos dados
Pode incluir a comunicação entre o software e outros sistemas
*
*
As 3 camadas
Camada de Domínio
Trata a lógica do negócio do cliente
Informações e regras do “mundo real” que o software precisa manipular
O trabalho que um software precisa realizar sobre os dados para cumprir seus requisitos
Deve expressar “como as coisas funcionam” no ambiente onde o software será implantado
*
*
As 3 camadas
As camadas de persistência e de domínio não deveriam ser dependentes da camada de apresentação
Essa dependência pode gerar duplicação de código
Os dados de uma aplicação podem ser mostrados em diferentes partes e de diferentes maneiras e, conseqüentemente, acarretaria muito trabalho alterar qualquer parte do sistema
Fowler (2006) define a diferença entre as funções das camadas de apresentação e persistência
“A camada de apresentação é um serviço que seu sistema presta para alguém, pode ser um ser humano ou outro sistema. A camada de persistência é uma interface para coisas que estão provendo ao seu sistema”.
*
*
Vantagens
Redução da complexidade
Agrupam componentes e simplificam a comunicação entre eles
Redução da dependência/acoplamento
A regra de comunicação evita dependências diretas entre componentes de camadas diferentes
Favorecem a coesão
Componentes de responsabilidades relacionadas são agrupados
Promovem reusabilidade
Camadas podem ser reutilizadas em outros sistemas ou podem ser substituídas
É um padrão arquitetural conhecido
Facilita a comunicação e entendimento entre desenvolvedores
*
*
Desvantagens
Limitadas pela tecnologia
Algumas regras precisam ser quebradas por limitações tecnológicas
Apenas complicam um sistema muito simples
Não é qualquer sistema que exige o uso de camadas
Possibilidade de overdose
Muitos arquitetos acabam criando camadas demais e tornando a aplicação extremamente complexa
*
*
Importante
A parte mais difícil da arquitetura em camadas é decidir quais camadas devem existir e qual a responsabilidade de cada uma delas
*
*
Importante
Para aplicações simples, que não irão crescer e nem mudar com frequência, não é recomendável que se pense em um projeto de software utilizando-se camadas
Camadas apenas complicam um sistema simples
Agora, se a aplicação for corporativa, que tenha de exibir muitos dados complexos para diferentes usuários, a replicação de código de acesso ao banco de dados é grande
A perda de desempenho é maior em aplicações multicamadas, pois existem muito mais chamadas a métodos do que se o código de acesso ao banco de dados estiver localizado diretamente no código da interface gráfica
Em aplicações corporativas onde existem diversas tarefas a serem realizadas,