2. ESCOPO DA DISCIPLINA
Apresentação
O processo de desenvolvimento de sistemas necessita de métodos específicos para se obter softwares de
qualidade. Através de metodologias adequadas o trabalho do analista se profissionaliza.
Objetivo
Definir as principais funções de um analista de sistemas, e as principais ferramentas para desenvolver sistemas de
média e grande complexidade. Possibilitar a escolha da melhor metodologia e ferramentas conforme as
necessidades dos usuários de sistemas.
Ementa
Apresentar os fundamentos das metodologias de análise de sistemas consagradas no mercado. Detalhar o
processo de modelagem e prototipagem no desenvolvimento de sistemas. Definir as metodologias e as suas
principais ferramentas. Descrever os diagramas da UML.
4. ANÁLISE E MODELAGEM DE SISTEMAS
DEFINIÇÃO
Requisito é uma condição ou capacidade que deve ser alcançada
ou possuída por um sistema ou componente deste para satisfazer
um contrato, padrão, especificação ou outros documentos
formalmente impostos. (Maciaszek ,2000).
7. Estudo feito pelo Standish Group em 1995 (Pfleeger, 2004)
350 companhias e 8.000 projetos de software
Resultados:
31% dos projetos cancelados antes de estarem completos
Em pequenas companhias, somente 16% dos projetos foram entregues no
prazo e no orçamento inicialmente estabelecidos
Em grandes companhias, apenas 9% atenderam esses critérios
ANÁLISE E MODELAGEM DE SISTEMAS
8. Standish Group descreveu 3 categorias de projetos:
Sucesso (16.2%)
Cobre todas as funcionalidades em tempo e dentro do custo previsto
Problemático (52.7%)
Não cobre todas as funcionalidades exigidas, custo aumentado e está
atrasado.
Fracasso (31.1%)
Cancelado durante o desenvolvimento
ANÁLISE E MODELAGEM DE SISTEMAS
10. O custo relativo para o conserto de um problema de requisitos em cada fase
de desenvolvimento de sistema é:
$1 na fase de análise de requisitos
$5 na fase de projeto do sistema
$10 na fase de codificação
$20 na fase de teste de unidade
$200 após a entrega do sistema
(Pfleeger, 2004)
ANÁLISE E MODELAGEM DE SISTEMAS
12. Compreensão do domínio do problema;
Comunicação efetiva com reais usuários do sistema;
Evolução contínua dos requisitos do sistema;
Os problemas são dinâmicos;
Problemas possuem fronteiras mal definidas.
ANÁLISE E MODELAGEM DE SISTEMAS
14. Requisitos Funcionais
Requisitos diretamente ligados a funcionalidade do software,
descrevem as funções que o software deve executar.
Um requisito funcional descreve uma interação entre o sistema e
seu ambiente.
ANÁLISE E MODELAGEM DE SISTEMAS
15. Regra de formação (boa prática)
O software deve permitir que o [responsável pela ação] + [ação]
Exemplo: O software deve permitir que o setor financeiro libere
o pagamento dos funcionários
ANÁLISE E MODELAGEM DE SISTEMAS
16. Requisitos Não Funcionais
São requisitos que expressam condições que o software deve atender ou
qualidades específicas que o software deve ter.
Em vez de informar o que o sistema fará, os requisitos não-funcionais
restrições no sistema.
Exemplo: “As consultas ao sistema devem ser respondidas em menos de três
segundos”.
Também podem especificar o uso de determinadas linguagens de programação,
método de desenvolvimento...
ANÁLISE E MODELAGEM DE SISTEMAS
17. Requisitos Não Funcionais
requisitos de confiabilidade
o sistema deve estar disponível 99% das vezes
requisitos de segurança
os dados devem ser criptografados com chave de 128 bits
requisitos de desempenho
o sistema deve processar X requisições por segundo
requisitos de capacidade
o sistema deve suportar X usuários concorrentemente
requisitos de portabilidade
o sistema deve rodar nas plataformas X e Y
ANÁLISE E MODELAGEM DE SISTEMAS
19. Na elicitação de requisitos, a equipe de desenvolvimento
trabalha com o cliente e usuários finais para descobrir
informações sobre o domínio, funcionalidades, restrições,
etc.
Envolve diferentes tipos de pessoas (stakeholder) –
qualquer pessoa que terá alguma influência direta ou
indireta sobre os requisitos do sistema
ANÁLISE E MODELAGEM DE SISTEMAS
20. ANÁLISE E MODELAGEM DE SISTEMAS
Atividades do processo
compreensão do domínio
coleta de requisitos através da interação com os stakeholders
classificação em grupos estruturados
resolução de conflitos advindos das diferentes visões dos
stakeholders
definição de prioridades
verificação de requisitos (completos e consistentes)
22. ANÁLISE E MODELAGEM DE SISTEMAS
Como identificar os melhores usuários para realização de
entrevistas?
Quais outras fontes de informação podem ser utilizadas para
apoiar a identificação dos requisitos?
Quais são os riscos existentes durante um processo de
identificação de requisitos?
23. ANÁLISE E MODELAGEM DE SISTEMAS
Quais fatores podem contribuir negativamente para a
realização das entrevistas?
Ciclos longos de entregas?
Ciclos curtos de entregas?
24. ANÁLISE E MODELAGEM DE SISTEMAS
Quais fatores podem contribuir positivamente para a
realização das entrevistas?
Conhecimento do domínio?
Experiência com funcionalidades semelhantes?
25. ANÁLISE E MODELAGEM DE SISTEMAS
Práticas a serem evitadas durante o levantamento de
requisitos:
Interromper o entrevistado?
Uso do sistema atual como base?
Reuniões às sextas?
Reuniões muito longas?
Usuários conflitantes na mesma reunião?
26. ANÁLISE E MODELAGEM DE SISTEMAS
Dificuldades do processo:
Stakeholders frequentemente não sabem o que querem do sistema
dificuldades de comunicação entre stakeholders e equipe de
desenvolvimento
Stakeholders sabem o que querem, mas não são capazes de expressar isso
claramente.
Analistas acham que entendem o problema melhor do que os clientes.
Diferentes stakeholders podem expressar de maneiras diferentes o mesmo
requisito
fatores políticos, econômicos e de negócios
27. ANÁLISE E MODELAGEM DE SISTEMAS
Dificuldades do processo (cont.)
Clientes pensam que sabem o que querem, até que você
entregue o que eles disseram que queriam.
Síndrome “Sim, mas”.
Nem todos estão motivados e comprometidos.
Disponibilidade dos envolvidos.
28. ANÁLISE E MODELAGEM DE SISTEMAS
Delinear claramente os limites e objetivos do sistema.
Controlar o nível de detalhe mais adequado para o momento
Cliente especifica detalhes quando você está tentando obter uma
visão inicial.
Cliente responde de forma superficial quando você está tentando
detalhar um aspecto da solução.
Cliente omite detalhes “óbvios”.
29. ANÁLISE E MODELAGEM DE SISTEMAS
Detectar e mediar resolução de conflitos entre os requisitos de
diferentes clientes.
Lidar com problemas políticos (resistências, brigas políticas, etc).
Obter comprometimento e participação efetiva dos clientes no
processo.
Extrair do cliente as reais necessidades quando ele já tem uma
“solução” e apenas quer comunicá-la para você.
31. ANÁLISE E MODELAGEM DE SISTEMAS
Técnicas de Elicitação
Brainstorming
Questionários
Workshop de Requisitos
Etnografia
Prototipação
Entrevistas
32. ANÁLISE E MODELAGEM DE SISTEMAS
Brainstorming - Técnica básica para geração de ideias
Reuniões onde as pessoas sugerem e exploram ideias – sem que
sejam criticadas!
Uma sessão consiste em duas fases:
Geração de ideias
Consolidação
– Processo relativamente não estruturado
33. ANÁLISE E MODELAGEM DE SISTEMAS
Regras:
Estabeleça o objetivo da sessão;
Gere quantas ideias for possível;
Deixe sua imaginação livre;
Não admita críticas ou debates;
Ajuste e combine as ideias.
34. ANÁLISE E MODELAGEM DE SISTEMAS
Questionários
Aplicabilidade a mercados específicos
Onde perguntas são bem definidas
Perguntas relevantes podem ser decididas antecipadamente
Úteis após uma entrevista inicial
35. ANÁLISE E MODELAGEM DE SISTEMAS
Workshop de Requisitos
Idealizado para encorajar o consenso sobre as ações a serem
tomadas em um curto intervalo de tempo.
Formato: reunião intensiva (1 ou 2 dias) com pessoas chaves
visando criar ou revisar as principais funcionalidades do sistema
em desenvolvimento, com a participação de um mediador.
36. ANÁLISE E MODELAGEM DE SISTEMAS
Coloca todos os stakeholders juntos por um período intensivo
(focado);
Facilitador conduz a reunião;
Todos têm sua vez de falar;
Resultados são disponíveis imediatamente;
Provê um ambiente para aplicar outras técnicas de elicitação.
37. ANÁLISE E MODELAGEM DE SISTEMAS
Benefícios:
ajuda na construção de espírito de equipe
todos os interessados no projeto participam das discussões
ajuda a estabelecer consenso
ajuda a expor e resolver questões políticas
como resultado imediato, uma descrição preliminar do
sistema é obtida
38. ANÁLISE E MODELAGEM DE SISTEMAS
Recomendações para um workshop:
venda o conceito (benefícios) do workshop para a
organização
garanta a participação das pessoas chaves
prepare material para ser distribuído para os
participantes se prepararem para o workshop
39. ANÁLISE E MODELAGEM DE SISTEMAS
Etnografia (Observação)
Parte do pressuposto que sistemas de software são
utilizados dentro de um contexto social e organizacional
requisitos do sistema são derivados e/ou limitados por este
contexto
Etnografia é uma técnica de observação que pode ser
utilizada para compreender requisitos sociais e
organizacionais.
40. ANÁLISE E MODELAGEM DE SISTEMAS
Analista se insere no ambiente de trabalho onde sistema será
utilizado
Trabalho diário é observado e tarefas reais em que os participantes
estão envolvidos são anotadas
ideia é capturar os processos reais ao invés dos processos formais
Realizar observação após um primeiro entendimento do que será
observado.
Combinar com perguntas específicas
– E se …? Em alguma situação você …?
41. ANÁLISE E MODELAGEM DE SISTEMAS
Técnica é eficaz na descoberta de dois tipos de requisitos:
requisitos derivados da maneira como as pessoas trabalham
(trabalho real x trabalho formal)
requisitos derivados da cooperação e conscientização das
atividades de outras pessoas
Captura de detalhes que podem ser esquecidos em uma
entrevista.
42. ANÁLISE E MODELAGEM DE SISTEMAS
Prototipação
Usuários podem descobrir quais são as suas reais necessidades através do
exame de um protótipo
Processo de prototipagem
Estudo preliminar dos requisitos do usuário
Construção do protótipo
Avaliação junto dos usuários
A prototipação é benéfica somente se o protótipo puder ser construído bem
mais rápido que o sistema real
43. ANÁLISE E MODELAGEM DE SISTEMAS
Protótipos são modelos do software
Não precisam ser completos
Construídos para permitir a avaliação pelo cliente e pelo desenvolvedor
Paradigmas de prototipagem
Finalidade aberta – Protótipo descartável
Serve apenas para demonstrar requisitos
Normalmente mais úteis para elicitação
Finalidade fechada – Protótipo evolutivo
O protótipo é a primeira evolução do software
47. ANÁLISE E MODELAGEM DE SISTEMAS
São utilizadas para estabelecer ordem, definir padrões e usar
técnicas já provadas no desenvolvimento de sistemas, agilizando
o processo e garantindo maior qualidade no desenvolvimento.
Atualmente existem vários tipos de metodologias, iremos estudar
a estruturada e a orientada por objetos. As diferenças nas
metodologias estão nas técnicas de construção do processo de
negócio, as definições dos dados e os modelos de eventos.
48. ANÁLISE E MODELAGEM DE SISTEMAS
Para apoiar as metodologias foram criadas ferramentas para acompanhar o
ciclo de vida do sistema, auxiliando no desenvolvimento de aplicativos
(ferramentas CASE).
Metodologia Estruturada
Na metodologia estruturada de análise e desenvolvimento de sistemas
estabelecem-se sucessivos detalhamentos dos processos desde o nível macro,
até o detalhe de mais baixo nível. É uma visão top-down de sistemas. Essa é a
metodologia mais antiga, mas ainda é usada por várias instituições
49. ANÁLISE E MODELAGEM DE SISTEMAS
Na Análise Clássica de Sistemas é gerado um documento descrevendo o
sistema proposto. Esse documento é normalmente chamado de
Especificação Funcional do Sistema.
Por ser um documento extremamente formal, costumeiramente os usuários
assinam e não o leem adequadamente.
As principais desvantagens desse tipo de documento com especificações
técnicas clássicas podem ser resumidas da seguinte forma:
São redundantes, dando a mesma informação em diversos locais dentro do documento;
São difícieis de se modificar e manter. Uma simples mudança nos requisitos do usuário
pode acarretar mudanças significativas na especificação;
50. ANÁLISE E MODELAGEM DE SISTEMAS
Ferramentas Da Análise Estruturada
As principais ferramentas que a Análise Estruturada criou na época para a devida
documentação do Sistema foram:
DFD
Dicionário de Dados
MER / DER
51. ANÁLISE E MODELAGEM DE SISTEMAS
Diagrama de Fluxo de Dados
(DFD)
O diagrama de fluxo de dados - DFD -
representa o fluxo de dados num sistema
de informação, assim como as sucessivas
transformações que estes sofrem.
O DFD é uma ferramenta gráfica que
transcreve, de forma não técnica, a lógica do
procedimento do sistema em estudo, sendo
usada por diferentes métodos e
principalmente pelos classificados como
orientados a processos.
O diagrama de fluxo de dados apresenta sempre
quatro objetos de um sistema de informação: fluxo de
dados, processos, arquivos de dados e entidades
externas.
52. ANÁLISE E MODELAGEM DE SISTEMAS
Entidades externas
Pessoa, grupo de pessoas ou
subsistema/sistema fora do sistema em estudo
que recebem dados do sistema e/ou enviam
dados para o sistema. As entidades externas
funcionam sempre como origem/destino de
dados;
Fluxo de dados
Dados que fluem entre processos e arquivos de
dados ou ainda entre processos e entidades
externas, sem nenhuma especificação temporal
(por exemplo ocorrência de processos
simultâneos, ou todas as semanas);
Arquivo de dados
Meio de armazenamento de dados para
posterior acesso e/ou atualização por um
processo;
53. ANÁLISE E MODELAGEM DE SISTEMAS
Processo
Recebe dados de entrada e transforma estes dados num fluxo de saída.
Regras e dicas de DFDs
Cada processo deve ter, pelo menos, uma entrada e uma saída.
Cada armazenamento de dados deve ter, pelo menos, um fluxo de dados de entrada e de um fluxo de dados de
saída.
Dados armazenados em um sistema devem passar por um processo.
Todos os processos em um DFD vão para outro processo ou um armazenamento de dados.
Dados armazenados em um sistema devem passar por um processo.
54. ANÁLISE E MODELAGEM DE SISTEMAS
Níveis e camadas de DFDs: de diagramas de contexto a pseudocódigos
Um diagrama de fluxo de dados pode conter muito mais detalhes ao usar níveis e camadas, focando uma
determinada peça. Níveis de DFDs são numerados 0, 1 ou 2, e, ocasionalmente, atingem o nível 3 ou mais. O
nível de detalhe necessário depende do escopo do que você está tentando realizar.
O DFD nível 0 é também chamado de diagrama de contexto. É uma visão geral básica de todo o sistema ou
processo a ser analisado ou modelado. É projetado para ser uma visão de bater o olho, mostrando o sistema
como um único processo de alto nível, com o seu relacionamento com entidades externas. Deve ser facilmente
compreendido por um público abrangente, incluindo partes interessadas, analistas de negócios, analistas
de dados e desenvolvedores.
55. ANÁLISE E MODELAGEM DE SISTEMAS
O DFD nível 1 oferece maiores detalhes de peças do diagrama de contexto. Ele destaca as principais
funções desempenhadas pelo sistema na medida em que você expande o processo de alto nível do
diagrama de contexto em subprocessos.
O DFD nível 2 aprofunda ainda mais partes do nível 1. Pode ser preciso mais texto para chegar ao nível
necessário de detalhes em relação ao funcionamento do sistema.
A progressão aos níveis 3, 4 e acima é possível, mas é incomum ir além do nível 3. Ela pode criar
complexidades que dificultam a comunicação, compararão ou modelagem de forma eficaz.
56. ANÁLISE E MODELAGEM DE SISTEMAS
Exemplos de como DFDs podem ser utilizados
DFDs na engenharia de software
DFD na análise de negóciosDFDs na reengenharia de processos de negócios
DFDs e desenvolvimento rápido
DFDs em estruturas de sistemas
57. ANÁLISE E MODELAGEM DE SISTEMAS
Exemplos
Processar
pedidos
CLIENTE
Dados de Livros
Dados de Clientes
pedidos
faturas
situação de crédito
58. ANÁLISE E MODELAGEM DE SISTEMAS
Expandindo “processar pedidos”
Mostra funções lógicas que constituem o sistema atual
Inicialmente, devemos:
verificar se os pedidos estão corretamente preenchidos;
tendo um pedido válido, juntá-lo aos pedidos de outros livros da mesma editora, para nos
beneficiarmos do desconto de quantidade.
59. ANÁLISE E MODELAGEM DE SISTEMAS
Verificar
validade do
pedido
CLIENTES
pedidos
EDITORAS
Livros
Clientes
Editoras
Pedidos Pendentes
Preparar
requisição p/
a editora
situação de
crédito
ordens de
compra
endereço
detalhes de
livros
pedidos
válidos
pedidos
agrupados
60. ANÁLISE E MODELAGEM DE SISTEMAS
Dicionário de Dados
É uma listagem
organizada, com
descrições de todos os
elementos de dados
pertinentes ao sistema.
61. ANÁLISE E MODELAGEM DE SISTEMAS
MER e DER – Modelo e Diagrama de
Entidades e Relacionamentos
O Modelo Conceitual de Dados (ou
Modelo de Entidades e Relacionamentos –
MER) é representado por um gráfico
denominado DIAGRAMA de ENTIDADES e
RELACIONAMENTOS (DER), proposto por
Peter Chen (1976). Trata-se de um
diagrama que detalha as associações
existentes entre as entidades de dados e
utiliza componentes semânticos próprios.’
62. ANÁLISE E MODELAGEM DE SISTEMAS
A Elaboração Do Modelo De Entidades E Relacionamentos
Segue Aos Seguintes Princípios:
Cada Entidade é representada por um retângulo na posição horizontal;
Cada tipo de relacionamento é representado por um losango;
Pode haver um tipo de relacionamento entre mais do que duas Entidades;
Os relacionamentos podem conter atributos;
Pode haver mais de um tipo de relacionamento entre duas Entidades.
63. ANÁLISE E MODELAGEM DE SISTEMAS
ENTIDADE
São os componentes físicos e abstratos utilizados pela empresa, sobre os quais são armazenados
dados;
ATRIBUTO
Corresponde à representação de propriedades de uma Entidade. Um atributo não tem vida própria
ou independente. Existe apenas para caracterizar uma Entidade;
RELACIONAMENTO
É uma correspondência entre duas entidades. Uma associação entre dois conjuntos de dados
(entidades);
IDENTIFICADOR ou ATRIBUTO DETERMINANTE
Um atributo ou uma coleção de atributos que determina de modo único uma Ocorrência de
Entidade;
64. ANÁLISE E MODELAGEM DE SISTEMAS
CLASSE DE RELACIONAMENTO ou CARDINALIDADE
Quantas ocorrências de cada entidade estão envolvidas no
relacionamento. Pode ser:
1:1 (um para um)
1:n (um para muitos)
m:n (muitos para muitos)
65. ANÁLISE E MODELAGEM DE SISTEMAS
Recomendações Para Criação Do Diagrama E-R (DER)
Antes de começar a modelar, conheça o “mundo real”.
Identifique quais são as ENTIDADES.
Para cada Entidade represente seus ATRIBUTOS.
Confronte cada Entidade consigo mesma e com as demais na procura de possíveis
RELACIONAMENTOS
Verifique a existência de ATRIBUTOS de RELACIONAMENTO.
Para relacionamentos múltiplos estude a necessidade de AGREGAÇÕES.
Desenhe o DER, com todas as Entidades, Atributos, Relacionamentos,
Analise cuidadosamente todas as restrições que você impôs.
68. ANÁLISE E MODELAGEM DE SISTEMAS
Construir um modelo de entidades e relacionamentos (MER) para
uma companhia de seguros de automóveis com um conjunto de
clientes, onde cada um possui um certo número de automóveis.
Os dados do cliente são código, nome, RG, CPF, endereço e
telefone.
Do carro deve-se armazenar a placa, código RENAVAN, fabricante,
modelo e ano. Associado a cada automóvel há um histórico de
ocorrências. Cada ocorrência deve ter um número (único), data,
local e descrição.
69. ANÁLISE E MODELAGEM DE SISTEMAS
Você foi convidado a elaborar um banco de dados para uma empresa de
consultoria que deseja registrar informações sobre seus projetos e
consultores. De acordo com o solicitado pelo seu cliente, para cada projeto
você deverá armazenar o código, nome e endereço da empresa que solicitou
o projeto, o número do projeto, a data de início e de término do projeto, o
valor do projeto, o número, nome, número do documento de identidade e
especialização dos consultores que participaram do projeto, as horas que
trabalharam em cada projeto e a função que exerceu (líder ou membro). Note
que uma mesma empresa pode solicitar diversos projetos e um mesmo
consultor pode trabalhar em diversos projetos. Utilizando seus
conhecimentos sobre modelo de entidades e relacionamentos (MER), elabore
o desenho inicial deste banco de dados.
71. UML
Linguagem Gráfica para especificar, visualizar construir e documentar os
artefatos de software
Vantagens
Usa notação gráfica: mais clara que a linguagem natural (imprecisa) e código (muito
detalhado)
Ajuda a obter uma visão geral do sistema
Não depende de tecnologia
Diminui a fragmentação, aumenta a padronização
73. UML
Tipos de Diagramas
Diagramas estruturais
Mostram a estrutura estática do sistema e suas partes em diferentes
níveis de abstração e como elas se relacionam.
Não utilizam conceitos relacionados ao tempo
Diagramas Comportamentais
Mostram a natureza dinâmica dos objetos do sistema, que pode ser
descrita como uma serie de mudanças no sistema com o passar do
tempo
75. UML
Diagrama Objetivo Grupo Diagrama
Classes Classe, características e relacionamentos. Estrutural
Componentes Estrutura e conexão de componentes. Estrutural
Estruturas Compostas Decomposição de uma classe em tempo de execução. Estrutural
Instalação Distribuição de artefatos nos nós. Estrutural
Objetos Exemplo de configurações de instâncias. Estrutural
Pacotes Estrutura hierárquica em tempo de compilação. Estrutural
Casos de Uso Como os usuários interagem com um sistema. Comportamental
Atividades Comportamento procedimental e paralelo. Comportamental
Máquinas de Estado Como os eventos alteram um objeto no decorrer de sua vida. Comportamental
Sequência Interação entre objetos; ênfase na sequência. Interação
Comunicação Interação entre objetos; ênfase nas ligações. Interação
Visão Geral da Interação Mistura de diagrama de sequência e de atividades. Interação
Sincronismo Interação entre objetos; ênfase no sincronismo. Interação
76. UML – DIAGRAMA DE CASOS DE USO
“Documento narrativo que descreve a sequência de eventos de um
ator que usa um sistema para completar um processo.”
Representa a interação entre um usuário (humano ou sistema) e o
sistema.
Não descreve como o software deverá ser construído, mas sim
como ele deverá se comportar quando estiver pronto.
Corresponde a um conjunto de ações com um objetivo comum.
77. UML – DIAGRAMA DE CASOS DE USO
Humano ou entidade.
Interage com o sistema.
Iniciam o sistema.
Fornecem dados.
Usam as informações do sistema.
78. UML – DIAGRAMA DE CASOS DE USO
Unidade de um trabalho significante.
Representa um processo.
Iniciado por um ator ou outro caso de uso.
Exemplos: “Login para o sistema”, “Registrar no sistema”,
“Criar pedidos”, etc.
79. UML – DIAGRAMA DE CASOS DE USO
<<include>>
Relacionamento com outro caso de uso que sempre será executado.
<<extend>>
Relacionamento com outro caso de uso que pode ou não ser executado.
80. UML – DIAGRAMA DE CASOS DE USO
Sistema de Pagamento de Serviços
O sistema será responsável por gerenciar os pagamentos dos serviços prestados por
empresas e freelancers. O pagamento do serviço poderá ser efetuado apenas pelo usuário
que possuir o perfil específico para esta função. Ao ser realizado qualquer serviço e
pagamentos, o sistema gera e envia uma mensagem de e-mail aos prestadores do serviço.
81. Pagamento de Serviço
Cenário Principal de Sucesso:
1. O usuário acessa o sistema
2. O usuário pesquisa o serviço a ser pago
3. O sistema apresenta as informações do serviço
4. O usuário inicia o processo de pagamento
5. O sistema envia a confirmação do pagamento ao
prestador do serviço
6. O sistema encerra o processo de pagamento
Extensões:
1a. Usuário não autorizado
1a.1 O usuário não possui perfil para realizar pagamentos
1a.2 O usuário é direcionado ao passo 6.
3a. Serviço não finalizado
3a.1 O sistema apresenta que o serviço não foi finalizado
3a.2 O usuário é direcionado ao passo 6.
Descrição Diagrama
82. UML – DIAGRAMA DE CASOS DE USO
• Exemplo de Caso de Uso para sacar dinheiro
83. UML – DIAGRAMA DE CASOS DE USO
Sistema de Pagamento de Serviços, realizar pesquisa de serviços
85. UML – DIAGRAMA DE CASOS DE USO
O que colocar num Diagrama de Casos de Uso
Melhor fazer menos do que fazer demais.
Breve e fácil de ler.
Preferência na descrição textual.
Limitar os relacionamentos com <<include>> e <<extend>>.
86. UML – DIAGRAMA DE CASOS DE USO
O que não colocar em um Diagrama de Casos de Uso
Textos longos.
Muitas extensões.
Todos diagramas se chamando.
Todas as ações CRUD separadas.
Detalhes da tela (botões, combos, links, etc).
Não é um fluxograma!
89. Estrutura da Classe
Uma classe em UML possui três partes:
Nome da Classe
Atributos
Operações
Podemos abreviar a declaração da classe, caso não
influencie o entendimento do diagrama:
UML – DIAGRAMA DE CLASSES
90. ATRIBUTOS
Um atributo é formado por:
visibilidade nome : tipo [multiplicidade] = valor inicial {propriedades}
UML – DIAGRAMA DE CLASSES
91. OPERAÇÕES
Uma operação é formada por:
visibilidade nome (parâmetros) : tipo de retorno {propriedades}
O parâmetro de um método é formado por:
nome : tipo [multiplicidade] = valor inicial
UML – DIAGRAMA DE CLASSES
92. VISIBILIDADE
Podemos definir as seguintes visibilidades em atributos e
operações:
- private
~ default
# protected
+ public
UML – DIAGRAMA DE CLASSES
93. ATRIBUTOS E OPERAÇÕES ESTÁTICO
Podemos definir atributos e operações como sendo
estáticos, ou seja, são referentes a classe e não aos seus
objetos.
UML – DIAGRAMA DE CLASSES
94. COMENTÁRIO
Os comentários ou notas são utilizados para adicionar
mais informações ao diagrama.
UML – DIAGRAMA DE CLASSES
95. COMENTÁRIO
O comentário pode ser utilizado em qualquer diagrama,
podendo ou não ser vinculado a algum elemento.
Utilizamos também o comentário para definir alguma
regra de restrição, para isto precisamos adicionar { }
entre a restrição:
UML – DIAGRAMA DE CLASSES
96. ASSOCIAÇÕES
Utilizado para representar o relacionamento entre
classes, as associações podem ser:
Associação
Agregação
Composição
Classe de associação
As classes que fazem parte de um relacionamento
também são chamadas de TODO (responsável pelo
relacionamento) e PARTE (usado pelo relacionamento).
UML – DIAGRAMA DE CLASSES
98. AGREGAÇÃO
Informa que uma classe faz parte de outra classe, mas não de forma exclusiva.
UML – DIAGRAMA DE CLASSES
99. COMPOSIÇÃO
Informa que uma classe faz parte de outra classe de forma exclusiva.
UML – DIAGRAMA DE CLASSES
100. AGREGAÇÃO X COMPOSIÇÃO
A diferença entre ambos é:
Agregação – se excluir a classe responsável pelo relacionamento, não deve excluir a classe
que ele possui relacionamento.
Composição – se excluir a classe responsável pelo relacionamento, então deve excluir a
classe que ele possui relacionamento.
UML – DIAGRAMA DE CLASSES
101. CLASSE DE ASSOCIAÇÃO
Utilizamos para realizar o relacionamento entre duas classes:
ou
UML – DIAGRAMA DE CLASSES
102. Podemos também ter uma associação para mesma classe:
ASSOCIAÇÃO
UML – DIAGRAMA DE CLASSES
104. MULTIPLICIDADE
A multiplicidade é utilizada para definir a quantidade de objetos devem ser
criados:
0 .. 1 (zero ou um)
1 (um)
* (zero ou muitos)
UML – DIAGRAMA DE CLASSES
105. MULTIPLICIDADE
Quando utilizamos atributos para informar coleção de objetos, podemos
também adicionar propriedades na multiplicidade:
{ordered} - Ordenado
{unordered} - Não ordenado
{unique} - Único
{nonunique} - Não único
{bag} - Conjunto não ordenado e não único
UML – DIAGRAMA DE CLASSES
106. DEPENDÊNCIA
Utilizado para informar que uma classe depende de outra classe para executar
alguma operação:
UML – DIAGRAMA DE CLASSES
107. ASSOCIAÇÃO X DEPENDÊNCIA
A diferença básica entre ambos:
Associação temos um atributo da classe relacionada.
Dependência utilizamos a classe relacionada, para passar um parâmetro, chamar um
método, criar um objeto, etc.
107
UML – DIAGRAMA DE CLASSES
109. CLASSE ABSTRATA
Utilizado para informar que uma classe não implementa todos os seus
métodos.
UML – DIAGRAMA DE CLASSES
110. HERANÇA
Utilizamos herança quando queremos declarar subclasses, permitindo reutilizar os
códigos já declarados na superclasse.
UML – DIAGRAMA DE CLASSES
111. INTERFACE
Utilizamos interface para definir as operações básicas que uma classe de seu
tipo precisa implementar.
UML – DIAGRAMA DE CLASSES
114. O QUE COLOCAR NO DIAGRAMA DE CLASSES
Concentre-se nas áreas principais do sistema.
O necessário para que as pessoas envolvidas possam entender.
Mantenha as notações simples.
Gere um diagrama de classe flexível, facilitando futuras atualizações.
114
UML – DIAGRAMA DE CLASSES
115. O QUE NÃO COLOCAR NO DIAGRAMA DE
CLASSES
Para não aumentar a complexidade de um diagrama de classes, normalmente
não adicionamos no diagrama:
Classes que representam telas.
Classes de conexão e acesso ao banco de dados.
Classes de API’s da linguagem ou de terceiros.
Não tente usar todas as notações disponíveis no mesmo diagrama.
Não desenhe modelos para tudo, a menos que seja realmente necessário.
115
UML – DIAGRAMA DE CLASSES
117. DIAGRAMA DE OBJETOS
Os diagramas de objetos mostram uma “fotografia” de um sistema
OO em execução
São mostrados os objetos, com os valores de seus atributos e as
ligações (links) entre eles
Os diagramas de objetos são úteis para a modelagem de
estruturas de dados complexas, por exemplo
118. É comum haver centenas ou milhares de objetos em um sistema
em execução, a maioria deles anônimos
Um diagrama de objetos mostra apenas uma parte dos objetos no
sistema
Um diagrama de objetos não mostra a evolução do sistema com o
tempo
DIAGRAMA DE OBJETOS
119. Diagramas de objetos são estáticos
Para mostrar o comportamento de um objeto, use diagramas de
colaboração, diagramas de sequência, ou diagramas de
É comum colocar um diagrama de classes junto com um
diagrama de objetos, para facilitar a identificação dos objetos
DIAGRAMA DE OBJETOS
122. DIAGRAMA DE COMPONENTES
Modela o sistema em termos de componentes e seus relacionamentos
através de interfaces
• Apresenta uma visão estática de como o sistema será implementado e
quais os seus módulos de software, ou seja, os seus componentes.
• Está amplamente ligado a linguagem de programação de
implementação.
Decompõe o sistema em subsistemas que detalham a estrutura interna
Entre muitas motivações para a construção de modelos de
componentes, salientam-se as seguintes:
123. Os clientes podem ver a estrutura final do sistema, mesmo antes deste estar
concluído.
A equipe de desenvolvimento tem uma visão da arquitetura física do sistema,
e assim pode trabalhar de forma mais controlada e sistemática.
O pessoal técnico (que produzem, por exemplo, a documentação do sistema,
manuais de utilizador, manuais técnicos) podem entender melhor sobre o que
estão escrevendo, e detalhar alguns aspectos do sistema antes deste estar
concluído.
DIAGRAMA DE COMPONENTES
126. 127
•Representa um serviço realizado por uma classe ou componente.
•Não possuem implementação ou qualquer especificação interna.
•Quando um componente implementa um interface, ele se relaciona com ela por meio de um
relacionamento de realização.
•Já se um componente utiliza a interface, este se relaciona com ela através de um
relacionamento de dependência
DIAGRAMA DE COMPONENTES
127. Interface Requerida
- Conecta uma interface requerida por um componente com uma outra fornecida por
outro, isto possibilita fornecer serviços que outro componente requeira.
DIAGRAMA DE COMPONENTES
129. Pacotes são estruturas que permitem agrupar qualquer
construção da UML em estruturas de alto nível
Pode mostrar:
Pacotes e suas dependências
Interfaces entre os pacotes
Generalizações entre pacotes
DIAGRAMAS DE PACOTE
130. • Classes que estejam na mesma árvore de herança.
• Classes que estejam em um mesmo jogo de agregação e composição.
• Classes que apareçam em um mesmo diagrama de seqüência com muitas
colaborações (alto acoplamento).
• Um pacote utilitário contém classes sem afinidade direta com o domínio do
problema, porém necessárias.
DIAGRAMAS DE PACOTE