SlideShare une entreprise Scribd logo
1  sur  18
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, talvezgrandes á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 definidode 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, podemosprever 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 possuemum 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 classehabitualmente 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 estadose
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 diagramade atividades é um diagrama UML utilizado para modelar o
aspectocomportamental 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 denominadasswimlanes. 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

Contenu connexe

Tendances (20)

Metodologia orientado a objetos
Metodologia orientado a objetosMetodologia orientado a objetos
Metodologia orientado a objetos
 
Modelagem - Diagrama de objetos by Kiwia
Modelagem - Diagrama de objetos by KiwiaModelagem - Diagrama de objetos by Kiwia
Modelagem - Diagrama de objetos by Kiwia
 
Modelagem Aplicações Web com UML
Modelagem Aplicações Web com UMLModelagem Aplicações Web com UML
Modelagem Aplicações Web com UML
 
Relatório da uml
Relatório da umlRelatório da uml
Relatório da uml
 
Uml
UmlUml
Uml
 
Modelagem de casos de uso e diagramas de sequência
Modelagem de casos de uso e diagramas de sequênciaModelagem de casos de uso e diagramas de sequência
Modelagem de casos de uso e diagramas de sequência
 
Modelagem de Sistemas de Informação 08 - Diagrama de Classes
Modelagem de Sistemas de Informação 08 - Diagrama de ClassesModelagem de Sistemas de Informação 08 - Diagrama de Classes
Modelagem de Sistemas de Informação 08 - Diagrama de Classes
 
Curso Básico de UML
Curso Básico de UMLCurso Básico de UML
Curso Básico de UML
 
Análise e Modelagem com UML
Análise e Modelagem com UMLAnálise e Modelagem com UML
Análise e Modelagem com UML
 
Introdução à linguagem UML
Introdução à linguagem UMLIntrodução à linguagem UML
Introdução à linguagem UML
 
Uml ppoint
Uml ppointUml ppoint
Uml ppoint
 
Uml Diagramas Estruturais
Uml   Diagramas EstruturaisUml   Diagramas Estruturais
Uml Diagramas Estruturais
 
Apostila de uml
Apostila de umlApostila de uml
Apostila de uml
 
UML
UMLUML
UML
 
Aula 7 diagramas_classes2
Aula 7 diagramas_classes2Aula 7 diagramas_classes2
Aula 7 diagramas_classes2
 
Modelo caso uso
Modelo caso usoModelo caso uso
Modelo caso uso
 
diagrama de componentes
diagrama de componentesdiagrama de componentes
diagrama de componentes
 
Engenharia de Software II - Atividade: Diagramas da UML
Engenharia de Software II - Atividade: Diagramas da UMLEngenharia de Software II - Atividade: Diagramas da UML
Engenharia de Software II - Atividade: Diagramas da UML
 
A Linguagem UML
A Linguagem UMLA Linguagem UML
A Linguagem UML
 
Componentes
ComponentesComponentes
Componentes
 

En vedette

Roteiro de aula montagem e manutenção 2012
Roteiro de aula montagem e manutenção 2012Roteiro de aula montagem e manutenção 2012
Roteiro de aula montagem e manutenção 2012Carlos Melo
 
Projecto de investimento
Projecto de investimentoProjecto de investimento
Projecto de investimentoQuirino Vieira
 
Analise de sistemas 1 semestre portfólio individual
Analise de sistemas 1 semestre portfólio individualAnalise de sistemas 1 semestre portfólio individual
Analise de sistemas 1 semestre portfólio individualJean Alves
 
Elaboração projeto investimento
Elaboração projeto investimentoElaboração projeto investimento
Elaboração projeto investimentoAlexandra Alcantara
 
Modelagem de Sistemas de Informação
Modelagem de Sistemas de InformaçãoModelagem de Sistemas de Informação
Modelagem de Sistemas de InformaçãoHelder Lopes
 
Caso de uso de biblioteca
Caso de uso de bibliotecaCaso de uso de biblioteca
Caso de uso de bibliotecapersye
 
Conceitos básicos de programação orientada a objetos
Conceitos básicos de programação orientada a objetosConceitos básicos de programação orientada a objetos
Conceitos básicos de programação orientada a objetosLeonardo Melo Santos
 
Gerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoes
Gerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoesGerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoes
Gerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoesJucioliver
 

En vedette (9)

Exercicios
ExerciciosExercicios
Exercicios
 
Roteiro de aula montagem e manutenção 2012
Roteiro de aula montagem e manutenção 2012Roteiro de aula montagem e manutenção 2012
Roteiro de aula montagem e manutenção 2012
 
Projecto de investimento
Projecto de investimentoProjecto de investimento
Projecto de investimento
 
Analise de sistemas 1 semestre portfólio individual
Analise de sistemas 1 semestre portfólio individualAnalise de sistemas 1 semestre portfólio individual
Analise de sistemas 1 semestre portfólio individual
 
Elaboração projeto investimento
Elaboração projeto investimentoElaboração projeto investimento
Elaboração projeto investimento
 
Modelagem de Sistemas de Informação
Modelagem de Sistemas de InformaçãoModelagem de Sistemas de Informação
Modelagem de Sistemas de Informação
 
Caso de uso de biblioteca
Caso de uso de bibliotecaCaso de uso de biblioteca
Caso de uso de biblioteca
 
Conceitos básicos de programação orientada a objetos
Conceitos básicos de programação orientada a objetosConceitos básicos de programação orientada a objetos
Conceitos básicos de programação orientada a objetos
 
Gerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoes
Gerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoesGerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoes
Gerenciamento de-projetos-exercicios-resolvidos-estudo-de-casos-e-simulacoes
 

Similaire à Trabalho de análise e projeto 2

342336684-GSI030-Aula08-projetoImplementacao.pdf
342336684-GSI030-Aula08-projetoImplementacao.pdf342336684-GSI030-Aula08-projetoImplementacao.pdf
342336684-GSI030-Aula08-projetoImplementacao.pdfGabrielMarchesan
 
Aula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semanaAula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semanaGabriel Moura
 
Documentar Requisitos Usando Modelos
Documentar Requisitos Usando ModelosDocumentar Requisitos Usando Modelos
Documentar Requisitos Usando ModelosBarbara Lima
 
Diagrama de implantação
Diagrama de implantaçãoDiagrama de implantação
Diagrama de implantaçãoelliando dias
 
CursoUML - Unified Modeling Language
CursoUML - Unified Modeling LanguageCursoUML - Unified Modeling Language
CursoUML - Unified Modeling Languageelliando dias
 
Aula modelagem de dados
Aula modelagem de dadosAula modelagem de dados
Aula modelagem de dadosGabriel Moura
 
design patterns - introdução
design patterns - introduçãodesign patterns - introdução
design patterns - introduçãoelliando dias
 
Apresentação sobre Diagrama de Classes com exemplos
Apresentação sobre Diagrama de Classes com exemplosApresentação sobre Diagrama de Classes com exemplos
Apresentação sobre Diagrama de Classes com exemplosmauroladeiafilho
 
Aulas de análise
Aulas de análiseAulas de análise
Aulas de análiseFrank Lira
 

Similaire à Trabalho de análise e projeto 2 (20)

Diagramas uml
Diagramas umlDiagramas uml
Diagramas uml
 
Aula 5 uml1 (1)
Aula 5   uml1 (1)Aula 5   uml1 (1)
Aula 5 uml1 (1)
 
4º semestre
4º semestre4º semestre
4º semestre
 
07 Modelagem (Sommer)
07 Modelagem (Sommer)07 Modelagem (Sommer)
07 Modelagem (Sommer)
 
Aula-04-UML.pptx
Aula-04-UML.pptxAula-04-UML.pptx
Aula-04-UML.pptx
 
342336684-GSI030-Aula08-projetoImplementacao.pdf
342336684-GSI030-Aula08-projetoImplementacao.pdf342336684-GSI030-Aula08-projetoImplementacao.pdf
342336684-GSI030-Aula08-projetoImplementacao.pdf
 
Aula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semanaAula desesenvolvimento segunda semana
Aula desesenvolvimento segunda semana
 
Documentar Requisitos Usando Modelos
Documentar Requisitos Usando ModelosDocumentar Requisitos Usando Modelos
Documentar Requisitos Usando Modelos
 
Diagrama de implantação
Diagrama de implantaçãoDiagrama de implantação
Diagrama de implantação
 
CursoUML - Unified Modeling Language
CursoUML - Unified Modeling LanguageCursoUML - Unified Modeling Language
CursoUML - Unified Modeling Language
 
Aula modelagem de dados
Aula modelagem de dadosAula modelagem de dados
Aula modelagem de dados
 
design patterns - introdução
design patterns - introduçãodesign patterns - introdução
design patterns - introdução
 
UML1.pdf
UML1.pdfUML1.pdf
UML1.pdf
 
Motivação
MotivaçãoMotivação
Motivação
 
Diagrama de classes
Diagrama de classesDiagrama de classes
Diagrama de classes
 
Artigo c#
Artigo c#Artigo c#
Artigo c#
 
UMLIntro.pptx
UMLIntro.pptxUMLIntro.pptx
UMLIntro.pptx
 
Apresentação sobre Diagrama de Classes com exemplos
Apresentação sobre Diagrama de Classes com exemplosApresentação sobre Diagrama de Classes com exemplos
Apresentação sobre Diagrama de Classes com exemplos
 
Trabalho uml
Trabalho umlTrabalho uml
Trabalho uml
 
Aulas de análise
Aulas de análiseAulas de análise
Aulas de análise
 

Trabalho de análise e projeto 2

  • 1. 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
  • 2. 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
  • 3. 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.
  • 4. 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.
  • 5. 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:
  • 6. 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.
  • 7. 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:
  • 8. •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:
  • 9. 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.
  • 10. 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, talvezgrandes á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.
  • 11. 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:
  • 12. 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:
  • 13. 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 definidode 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, podemosprever 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.
  • 14. Todos os objetos possuemum 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 classehabitualmente 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 estadose 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:
  • 15. Diagrama de Atividades O diagramade atividades é um diagrama UML utilizado para modelar o aspectocomportamental 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 denominadasswimlanes. 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:
  • 16.
  • 17. 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.