Archive for April, 2006

Resumo da aula 13 – Versão 2.0

Essa aula foi no laboratório… Vimos um tutorial da Borland, onde tinham perguntas sobre a matéria. Este tutorial é indicado pelo professor Julio, em seu blog sobre UML(1) no dia 19/04/2006. O professor Julio ficou tirando dúvidas durante a aula…

Observação Importante: Perguntas parecidas com as do tutorial da Borland estarão na prova!

Autor: Fabrine Pereira

Data: 20/04/06

April 23, 2006 at 6:14 pm 1 comment

Resumo da aula 12 – Versão 2.0

UML:

  • Caso de uso
  • Fluxo de dados
  • Diagrama de classes — É mais parecido com uma rede.

SADT:

  • Decomposição
  • Modularização
  • Modelos, análise e desenho — Especificação diferente de requisitos.
  • Não tem a idéia de fluxo, como é o ponto principal do DFD.

Processo de decomposição em diagramas do tipo DFD (Diagrama de Fluxo de Dados):

  • No diagrama DFD tem um diagrama inicial chamado de diagrama de contexto (Não vê o contexto como um todo, só tem o conceito de entradas transformadas em saídas). Portanto o DFD expõe claramente o conceito de contexto.
  • DFD é uma linguagem simples.
  • DFD é orientada a fluxo.
  • DFD tem o conceito de hierarquia (decomposição).

Observação Importante: O DFD não é uma sub-linguagem da UML, mas pelas quatro razões acima, vimos que o DFD tem uma visão importante sobre fluxo de dados.

Diagrama de contexo: 

Diagrama de nível 0 (ou diagrama de contexto) é o local em que as informações, sobre entradas e saídas, se encontram (já que são fornecidadas ou se destinam à entidades externas).

Autor: Fabrine Pereira

Data: 18/04/06

April 23, 2006 at 5:49 pm 1 comment

Resumo da aula 11 – Versão 2.0

SADT (STRUCTURED ANALISIS E DESIGN TECNIQUE)

É uma tecnica para construções de modelos. Cada modelo deve ter um objetivo e um ponto de vista. Existem duas perspectivas de modelos:

  • Processo (Actigrama)
  • Dados (Datagrama)

Os modelos são construidos segundo os princípios de decomposição.

A decoposição segue a norma da disciplina [3 ; 6].

Visões aplicadas ao modelo pescar:

Visão de processos:

Preparar ————– Adquirir ————– Locomover

Visão de dados:

Equipamento ———— Isca ———— Veículo

SADT é uma possibilidade que permite comparar as duas perspectivas.

Qual o objetivo?

Atingir um maior universo.

Faça o modelo de processos descanse dois dias e faça o modelo de daods e depois compare os dois. Esse método é ótimo sob o ponto de vista da qualidade, mas tem um custo muito grande.

A folha de SADT segue as regras dadas na aula 03. 

Autores: Fabrine Pereira

Data: 11/04/06

April 12, 2006 at 5:31 pm 1 comment

Resumo da aula 10 – Versão 2.0

Tecnologia geral de sistemas (TGS), Objeto e aspectos:

– U (União) –> Conhecimentos de varias áreas

  • Descartes (Especialização)
  • Realistica
  • Decomposição (Hierarquia)

Sistema é um conjunto de partes relacionadas para atingir um objetivo.

Características básicas:

  • Objetividade (propósito)
  • Entropia <– Tempo
  • Homeostazia = Tende a se adaptar
  • Globalidade

Conceitos:

  • Sist/Subs
  • Todo sistema é um sub-sistema de um sistema maior (condição parada universo).

Dividir para conquistar:

Sistemas complexos são divididos em partes. Existem conexões n(n-1) / 2 (número máximo possível de interconexões) para ligar as partes do sistema.

Qual a solução para o número de interconexões?

Seria aplicar a ideia de hierarquia! A decomposição hierárquica (princípio da TGS).

Mas para dividir o sistema em partes é preciso saber muito sobre as partes e como relaciona-las.

Acoplamento forte e fraco:

  • Forte:

Acoplamento de partes, como funções, componentes e módulos que se comunicam. É quando é passado controles ou estrutura de dados complexas ou áreas comuns de dados.

O acoplamento forte deve ser evitado, pois não se pode dividir dados em uma área de memória comum.

  • Fraco:

Acoplamento de dados.

Dois módulos distintos precisam passar dados (parametros ou controles). Qual a melhor maneira?

Seria a coesão forte. A coesão forte é funcional. Cada componete faz uma coisa e apenas uma única coisa (coesão funcional).

TGS é fundametal, pois vivemos dividindo sistemas complexos, mas de maneira organizada.

Information hiding é um conceito de modularização e tem a ver com a idéia de coesão.

Um agente não fala para outro agente oque sabe. Pois se um agente for capturado existem poucas possibilidades do outro ser capturado.

Publique a interface, mas não publique o seu conteúdo.

Modularização é a aplicação do TGS.

Autores: Fabrine Pereira

Data: 06/04/06

April 12, 2006 at 4:56 pm 1 comment

Resumo da aula 09 – Versão 1.0

Multitude de opiniões

Conceitos que foram relembrados:

  • Universo de Informações — É tudo que rodeia o software a ser desenvolvido, todas as informações e situações que devem ser conhecidas para o processo de produção.
  • Partes do Processo de Desenvolvimento de um Software — <definição, desenho, implantação>.

Como lidar com a complexidade de diferentes contextos durante a produção de software?

  • A definição do software sempre está relacionada à implantação de outro artefato, que eventualmente pode ainda não estar implantado ou terminado. Artigo da Professora Mary Lou Maher.
  • Diferentes atores do universo de informação podem ter opiniões diferentes sobre constituintes do universo de informações (processo de engenharia de requisitos). Artigo “Viewpoints on Viewpoints”.
  • Os desenvolvedores de software podem escolher qual o conjunto de métodos, técnicas e ferramentas querem utilizar no processo de produção.

Estratégias para aquisição de conhecimento (elicitação de requisitos):

  • Entrevistas:

Podem ser estruturadas ou simplesmente elucidativas. Sempre com o relacionamento de “um para um”.

  • Reuniões:

O ponto principal da reunião é que ela pode ser n para m e permite a discussão de idéias, podendo até ser geradora de idéias como a técnica “braisntorming”.

  • Leitura de Documentos:

Possibilita ao Engenheiro de Software dispor de um agente responsável pela leitura e extração de conhecimentos importantes dos documentos.

  • Observação
  • Questionários
  • Etnografia:

A etnografia prega que o engenheiro de software/engenheiro de requisitos “viva” no UdI e reporte sua experiência de maneira que respeite os princípios culturais do UdI.

  • Reutilização
  • Análise de Protocolos
  • Participação dos Clientes/Usuários

Autores: Fabrine Pereira, Lourival Neto e Rodolfo Caldeira

Data: 04/04/06

April 4, 2006 at 1:56 pm Leave a comment


Calendar

April 2006
M T W T F S S
 12
3456789
10111213141516
17181920212223
24252627282930

Posts by Month

Posts by Category