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