AMSI.pptx

ANALISE E MODELAGEM DE SISTEMAS
ANDERSON CUNHA

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.

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).

IMPORTÂNCIA DE SE TRABALHAR COM REQUISITOS

 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

 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

 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)

DESAFIOS AO SE TRABALHAR COM REQUISITOS

 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.

 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.

 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

 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...

 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

 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

 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)

 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?

 Quais fatores podem contribuir negativamente para a
realização das entrevistas?
 Ciclos longos de entregas?
 Ciclos curtos de entregas?

 Quais fatores podem contribuir positivamente para a
realização das entrevistas?
 Conhecimento do domínio?
 Experiência com funcionalidades semelhantes?

 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?

 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

 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.

 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”.

 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ê.

TÉCNICAS DE ELICITAÇÃO DE REQUISITOS

 Técnicas de Elicitação
 Brainstorming
 Questionários
 Workshop de Requisitos
 Etnografia
 Prototipação
 Entrevistas

 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

 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.

 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

 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.

 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.

 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

 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

 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.

 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ê …?

 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.

 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

 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

METODOLOGIAS E ANÁLISE DE SISTEMAS
- METODOLOGIA ESTRUTURADA

 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.

 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

 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;

 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

 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.

 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;

 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.

 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.

 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.

 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

 Exemplos
Processar
pedidos
CLIENTE
Dados de Livros
Dados de Clientes
pedidos
faturas
situação de crédito

 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.

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

 Dicionário de Dados
 É uma listagem
organizada, com
descrições de todos os
elementos de dados
pertinentes ao sistema.

 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.’

 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.

 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;

 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)

 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.

 DEMONSTRAÇÃO

 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.

 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.

UML
Unified Modeling Language
Linguagem de Modelagem Unificada

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

UML
Out/1994
Out/1995
Jun/1996
Jan/1997
Nov/1997
Jun/1998
Dez/1998
2001 2005
2007
James Rumbaugh
e Grady Booch
- Versão 0.8
- Ivar Jacobson
- “três amigos”
Versão 0.9 Versão 1.1 Versão 1.3 Versão 2.1
Versão 1.0 Versão 1.2 Versão 1.4
Versão 1.5
Versão 2.0
2002

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

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

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.

 Humano ou entidade.
 Interage com o sistema.
 Iniciam o sistema.
 Fornecem dados.
 Usam as informações do sistema.

 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.

 <<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.

 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.

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

• Exemplo de Caso de Uso para sacar dinheiro

 Sistema de Pagamento de Serviços, realizar pesquisa de serviços

 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>>.

 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!

 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

ATRIBUTOS
 Um atributo é formado por:
visibilidade nome : tipo [multiplicidade] = valor inicial {propriedades}

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

VISIBILIDADE
 Podemos definir as seguintes visibilidades em atributos e
operações:
- private
~ default
# protected
+ public

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.

COMENTÁRIO
 Os comentários ou notas são utilizados para adicionar
mais informações ao diagrama.

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:

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).

ASSOCIAÇÃO
 Relacionamento simples entre duas classes:

AGREGAÇÃO
 Informa que uma classe faz parte de outra classe, mas não de forma exclusiva.

COMPOSIÇÃO
 Informa que uma classe faz parte de outra classe de forma exclusiva.

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.

CLASSE DE ASSOCIAÇÃO
 Utilizamos para realizar o relacionamento entre duas classes:
 ou

 Podemos também ter uma associação para mesma classe:
ASSOCIAÇÃO

NAVEGABILIDADE
 Podemos informar qual a direção do relacionamento:

MULTIPLICIDADE
 A multiplicidade é utilizada para definir a quantidade de objetos devem ser
criados:
0 .. 1 (zero ou um)
1 (um)
* (zero ou muitos)

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

DEPENDÊNCIA
 Utilizado para informar que uma classe depende de outra classe para executar
alguma operação:

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

ASSOCIAÇÃO X DEPENDÊNCIA
 Exemplo:

CLASSE ABSTRATA
 Utilizado para informar que uma classe não implementa todos os seus
métodos.

HERANÇA
 Utilizamos herança quando queremos declarar subclasses, permitindo reutilizar os
códigos já declarados na superclasse.

INTERFACE
 Utilizamos interface para definir as operações básicas que uma classe de seu
tipo precisa implementar.

INTERFACE
 Exemplo:

PACOTE
 Utilizamos para organizar as classes:
113

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

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

 EXEMPLO

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

 É 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

 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

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:

 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.

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

Interface Requerida
- Conecta uma interface requerida por um componente com uma outra fornecida por
outro, isto possibilita fornecer serviços que outro componente requeira.

 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

• 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

REPRESENTAÇÕES POSSÍVEIS
DIAGRAMAS DE PACOTE

AMSI.pptx

Mais conteúdo relacionado

Semelhante a AMSI.pptx

AMSI.pptx