COLÉGIO ESTADUAL ANDRÉ SEUGLING ENSINO
FUNDAMENTAL MÉDIO E PROFISSIONAL
CURSO TÉCNICO EM INFORMÁTICA
MEIRE DOS SANTOS AGUIAR
DIAGRAMAS DA ANÁLISE DE PROJETO
CORNÉLIO PROCÓPIO
2012
MEIRE DOS SANTOS AGUIAR
DIAGRAMAS DA ANÁLISE DE PROJETO
Trabalho apresentado no Curso Profissionalizante do Colégio Estadual André Seugling, Curso de Técnico em Informática, como requisito parcial para a aprovação na disciplina Análise e Projeto, sob orientação da Professora Érica Costa.
CORNÉLIO PROCÓPIO
2012
INTRODUÇÃO
Este trabalho reúne algumas definições, características e funcionalidades dos
diagramas de fluxo de dados, caso de uso, de classe, de pacotes, de interação que
engloba os diagramas de sequência e colaboração, de estado e de atividade.
Diagramas
Diagrama de fluxo de Dados
O DFD é uma ferramenta que nos permite imaginar um sistema como uma
rede de processos funcionais, interligados por “dutos” e “tanques de
armazenamento” de dados. Também pode ser chamado de:
• Diagrama de bolhas;
• DFD (abreviatura que utilizaremos);
• Modelo de Processo;
• Diagrama de fluxo e trabalho;
• Modelo funcional;
• “uma representação do que está acontecendo por aqui”.
Características dos DFD:
Gráficos
Particionados
Multidimensionais
Realçam fluxos de dados
Não realçam fluxos de controlo
Elementos do DFD:
Fluxos de dados
Processos
Arquivos
Fontes e destinos de dados
Objetivo da Diagramação de fluxos de dados:
Configurar quais são os primitivos funcionais do nosso sistema e como se
Inter-relacionam.
Funcionalidades
Cadastro de Produto; Cadastro de Movimento; Cadastro de Tipo Movimento;
Relatórios de
Produtos por Ordem Alfabética; Relatório de Tipo de Movimentos por Ordem
Alfabética;
Relatório de Movimento agrupado por data por Ordem Crescente; Relatório
de Movimento
agrupado por Tipo de Movimento; Relatório de Produtos que estão abaixo do
Estoque Mínimo.
Exemplo:
Diagrama de Caso de Uso
É uma forma do engenheiro de especificar requisitos dos limites e das
funcionalidades do sistema.
• Permite:
– Que clientes e usuários validem o sistema;
– Que os desenvolvedores construam o que é esperado.
• Componentes:
– Atores;
– Casos de Uso.
• Atores são papéis de elementos externos ao sistema e que interagem diretamente
com o sistema.
• Exemplo de atores:
– Cliente;
– Secretária;
– Sistema de Vendas (desde que não seja o sistema em desenvolvimento);
– Glicosímetro (conectado ao computador por um cabo).
• Casos de Uso são funcionalidades que o sistema realiza e que fornece um
benefício a um ator específico;
• Características:
– Sempre iniciados por um ator;
– Sempre retornam um resultado ao ator;
– Especifica uma funcionalidade completa.
Exemplo:
Diagrama de Classes
É uma estrutura lógica estática em uma superfície de duas dimensões
mostrando uma coleção de elementos declarativos de modelo, como classes, tipos e
seus respectivos conteúdos e relações. [Furlan, 1998]
O diagrama de classes representa a estrutura do sistema, recorrendo ao
conceito de classe e suas relações. O modelo de classes resulta de um processo de
abstração onde são identificados os objetos relevantes do sistema em estudo. Um
objeto é uma ocorrência que tem interesse para o sistema em estudo e que se
pretende descrever no seu ambiente, contendo identidade e comportamento. O
comportamento de um objeto define o modo como ele age e reage a estímulos
externos e a identidade de um objeto é um atributo que o distingue de todos os
demais, sendo preservada quando o seu estado muda. Um objeto não é mais do
que uma instância da classe.
Os objetos de modelação contemplados por este diagrama são:
Classe: é a representação de um conjunto de objetos que partilham os mesmos
atributos e comportamentos;
Relação: representa a ligação entre classes.
Objetivo dos diagramas de classes:
•Um diagrama de classes serve para modelar o vocabulário de um sistema, do
ponto de vista do utilizador/problema ou do implementador/solução.
- Ponto de vista do utilizador/problema – na fase de captura e análise de
requisitos, em paralelo com a identificação dos casos de utilização.
- Vocabulário do implementador/solução – na fase de projeto (design).
• Construído e refinado ao longo das várias fases do desenvolvimento do software,
por analistas, projetistas (designers) e implementadores.
•Também serve para:
- Especificar colaborações (no âmbito de um caso de utilização ou mecanismo).
- Especificar esquemas lógicos de bases de dados.
- Especificar vistas (estrutura de dados de formulários, relatórios, etc.).
•Modelos de objectos de domínio, negócio, análise e desig.
Exemplo:
Diagrama de Pacotes
Pacotes
•São utilizados para agrupar elementos e fornecer denominações para esses
grupos.
•Um pacote pode representar um sistema, um subsistema, uma biblioteca, entre
outras alternativas.
•Pode conter outros pacotes.
Pacotes normalmente contém dependência entre si.
Um relacionamento de dependência informa que o elemento dependente
necessita de alguma forma do elemento do qual depende.
Visibilidade do Pacote:
* Privado - Só o pacote que define determinadas classes tem acesso a elas.
* Protegido - Só os pacotes gerados a partir do pacote podem acessar suas classes.
* Público - O conteúdo do pacote pode ser acessado por outros elementos.
* Implementação - Idêntico a definição do pacote privado com algumas restrições.
Sua finalidade é tratar a modelagem estrutural do sistema dividindo o modelo
em divisõeslógicas e descrevendo as interações entre ele em alto nível.
São usados para agrupar classes.
Os pacotes são descritos como uma forma de agrupar casos de uso. No
entanto, essa mesma seção deixa claro que um pacote é um mecanismo de
agrupamento geral que pode ser utilizado para agrupar vários artefatos de um
modelo (não só casos de uso).
Descreve como os elementos do modelo estão organizados em pacotes e
demonstra as dependências entre eles.
Pode ser utilizado ainda para representar um conjunto de subsistemas
integrados (representados por pacotes) ou ainda os módulos englobados por um
sistema.
Quando usar:
- Ao término da análise do subsistema de caso de uso. �
- Ao término de um módulo.�
- Para sistemas grandes, talvez grandes áreas, ou talvez você tenha optado por�
subdividir um grande módulo em outros pequenos.
Exemplo:
Diagrama de Interação
Diagramas de Interação são modelos que descrevem como grupo de objetos
colaboram em um determinado comportamento.
Um diagrama de interação captura o comportamento entre objetos dentro de
um único use case.
Utiliza-se o diagrama de atividade para representar o comportamento de
objetos entre vários use cases.
Tipos: Diagrama de Sequência e Diagrama de Colaboração.
Diagrama de Sequência
Consiste em um diagrama que tem o objetivo de mostrar como as mensagens
entre os objetos são trocadas no decorrer do tempo para a realização de uma
operação.
Em um diagrama de sequência, os seguintes elementos podem ser encontrados:
Linhas verticais representando o tempo de vida de um objeto (lifeline);
Estas linhas verticais são preenchidas por barras verticais que indicam
exatamente quando um objeto passou a existir. Quando um objeto
desaparece, existe um "X" na parte inferior da barra;
Linhas horizontais ou diagonais representando mensagens trocadas entre
objetos. Estas linhas são acompanhadas de um rótulo que contém o nome da
mensagem e, opcionalmente, os parâmetros da mesma. Observe que
também podem existir mensagens enviadas para o mesmo objeto,
representando uma iteração;
Uma condição é representada por uma mensagem cujo rótulo é envolvido por
colchetes;
Mensagens de retorno são representadas por linhas horizontais tracejadas.
Este tipo de mensagem não é frequentemente representada nos diagramas,
muitas vezes porque sua utilização leva a um grande número de setas no
diagrama, atrapalhando o entendimento do mesmo. Este tipo de mensagem
só deve ser mostrada quando for fundamental para a clareza do diagrama.
Exemplo:
Diagrama de Colaboração
A grande diferença entre um diagrama de colaboração e um de sequência
consiste no fato de que o tempo não é mais representado por linhas verticais, mas
sim através de uma numeração, que pode ser de duas formas:
simples (1,2,3,...)
composta (1.1, 1.2, 1.2.1, ...)
Um objeto é representado como um retângulo, contendo no seu interior um
rótulo, que informa o nome do objeto e o nome da classe, separados por dois
pontos. Detalhe: ambos podem ser omitidos.
A troca de mensagens entre os objetos segue o mesmo padrão que o
apresentado nos diagramas de sequência.
Exemplo:
Diagrama de Estado
Definição
Trata-se de um complemento para a descrição das classes, documentando os
estados possíveis que objetos de uma certa classe podem assumir, além de
mostrar ainda os eventos do sistema que geram tais mudanças.
Os diagramas de estado não são escritos para todas as classes de um
sistema, mas apenas para aquelas que possuem um número definido de estados
conhecidos e onde o comportamento das classes é afetado e modificado pelos
diferentes estados.
Através da análise da mudança de estados dos tipos de objetos de um
sistema, podemos prever todos os possíveis comportamentos de um objeto de
acordo com os eventos que o mesmo possa sofrer.
Diagramas de estado capturam o ciclo de vida dos objetos, subsistemas e
sistemas.
Eles mostram os estados que um objeto pode possuir e como os eventos
(mensagens recebidas, timer, erros, e condições sendo satisfeitas) afetam estes
estados ao passar do tempo.
Todos os objetos possuem um estado que significa o resultado de atividades
executadas pelo objeto, e é normalmente determinada pelos valores de seus
atributos e ligações com outros objetos.
Um objeto muda de estado quando acontece algo, o fato de acontecer alguma
coisa com o objeto é chamado de evento.
Os objetos de uma classe habitualmente possuem um ciclo de vida: são
gerados, assumem posições durante a sua vida, dão origem a outros objetos em
classes relacionadas e deixam de existir no momento de sua destruição.
Um diagrama de estado não capta – e não deve captar – todas as facetas e
algoritmos possíveis da classe.
Se o diagrama de estado está se tornando uma “miscelânea” de estados e
condições, então muito provavelmente é necessário repensar sua classe.
Devemos usar esse diagrama quando tivermos uma classe com mais de um
atributo, que reflitam o estado de seus objetos em um determinado tempo, e que
esses atributos mereçam ser modelados visando simplificar sua complexidade.
Se o relacionamento de classes não está claro o suficiente em função do
estado dos objetos, isso será uma pista de que deve usar este diagrama. Essa
percepção é pessoal.
Exemplo:
Diagrama de Atividades
O diagrama de atividades é um diagrama UML utilizado para modelar o
aspecto comportamental de processos. É um dos diagramas que mais sofreu
mudanças em seu meta-modelo, desde seu surgimento no UML 1.0.
Neste diagrama, uma atividade é modelada como uma sequência estruturada
de ações, controladas potencialmente por nós de decisão e sincronismo. Em seu
aspecto mais simples, um diagrama de atividades pode ser confundido com um
fluxograma.
Entretanto, ao contrário de fluxogramas, os diagramas de atividades UML
suportam diversos
Outros recursos, tais como as partições e os nós do tipo fork e merge, além
da definição de regiões de interrupção, que permitem uma modelagem bem mais
rica do que simplesmente um fluxograma.
O objetivo do diagrama de atividades é mostrar o fluxo de atividades em um
único processo. O diagrama mostra como uma atividade depende uma da outra.
Um diagrama de atividade pode ser regiões denominadas swimlanes. Estas
regiões e são associadas a um objeto do modelo. Desta forma, dentro de cada
região, encontram-se as atividades relativas ao objeto da região.
As atividades são conectadas através de arcos (transições), que mostram as
dependências entre elas.
Exemplo:
CONCLUSÃO
O tema diagramas da análise de projeto é muito extenso e envolve inúmeras
informações. A intenção do trabalho é dar uma visão geral ou talvez até superficial
do mesmo.
REFERÊNCIAS
http://www.apibrasil.com.br/esof/aula6.pdf
http://www.reocities.com
http://www.si.lopesgazzani.com.br/TFC/monografias/TRABALHO_FINAL_CURSO-final1.pdf
http://www.macoratti.net/vb_dfd1.htm
http://www.dmo.fee.unicamp.br/~henrique/cursoc++/diagrama.pdf
http://celodemelo.wordpress.com/category/uml/
http://julianoribeiro.com.br/blog/tag/diagrama-de-classes/
http://joaomorais.com.br/jm/uploads/Links/uml.pdf
http://twiki.fe.up.pt/pub/ASI1LCI0506/Asi1Documentos0506/UML-classes-redux.pdf
http://www.dai.ifma.edu.br
http://techblog.desenvolvedores.net/2011/06/29/diagrama-de-pacote-uml/
http://www.deinf.ufma.br
http://subversion.assembla.com
http://www.dsc.ufcg.edu.br
http://www.deinf.ufma.br
http://www.wthreex.com
http://www.dca.fee.unicamp.br
http://www.selectgame.com.br