Resumo da aula 18 – Versão 1.0

Princípios do XP

  • Cliente está sempre presente com a equipe, onde ocorrem negociações de requisitos e prazos.

  • Pequenas versões – Tem o objetivo de produzir um sistema simples rapidamente, planejando novas versões em um ciclo muito pequeno. Os ciclos duram três semanas.

  • Refactoring

  • Programação em pares – Todo o código produzido é escrito com dois programadores em cada máquina. Em cada ciclo trocam-se os pares de programadores.

  • Propriedade coletiva – Qualquer pessoa pode mudar qualquer código em qualquer tempo.

  • 40 horas por semana – Impõe que a equipe à não trabalhar mais que 40 horas por semana.

  • Padrões de codificação – Os programadores devem escrever o código de acordo com os padrões definidos pela equipe.

  • Teste contínuo – Os programadores continuamente escrevem unidades de teste e os executam para que o processo de desenvolvimento continue. Em cada ciclo os programadores apresentam uma versão testável do software ao cliente.

Autores: Fabrine Pereira, Lourival Neto e Rodolfo Caldeira

Data: 11/06/06

June 11, 2006 at 4:42 pm 3 comments

Resumo da aula 16 -Versão 1.0

Hoje a aula foi no laboratório. Os alunos apresentaram seus trabalhos sobre um sistema de acesso pelo usuário, a partir de um login, senha e cadastro. Utilizando os conceitos de cenários e léxicos em php e mysql.

Autor: Fabrine Pereira, Lourival Neto e Rodolfo Caldeira.

Data: 02/05/06

May 2, 2006 at 1:42 pm 2 comments

Resumo da aula 15 – Versão 2.0

Padrôes de desenho:

A idéia de arquitetura (ou Macro-Arquitetura) veio do livro da Mary Shaw – "Software architecture 94/95".

  • Tubos e filtros — Dois comando que tem no LINUX:

Processos são encadeados. É uma arquitetura onde a passagem de dados são encadeadas pelos tubos e filtros. A vantagem de se ter noção dessa arquitetura é, que a pessoa pode encontrar um problema que essa arquitetura pode resolver com a sua estrutura de solução. Mas isso não é uma solução! 

  • Camada
  • Repositórios:

O quadro negro não processa, ele só guarda. Tem o acoplamento fortíssimo. A idéia de coesão não se aplica no contexto da explicação do quadro negro, no qual o ponto é a idéia de acoplamento (acoplamento forte do modelo).

  • Orientação a Objeto — Arquitetura de redes:

Na orientação a objeto, as comunicações podem ser quaisquer, entre componentes (objetos), o que torna complexa a rede gerada.

  • Programa/Sub-Programa:

Decomposição T.G.S. Fica bem definido do que fala com o que. Organização hierarquica segue os princípios da T.G.S.

É importante saber qual estilo utilizar. Podemos misturar as camadas, mas como nós estamos falando em macro-arquitetura e estamos analizando uma só camada, só um estado acaba sobressaindo.

Framework – Está entre a idéia de arquitetura e padão. Em um sistema pode-se empregrar ou encontrar esse tipo de framework que divide as partes segundo M, V e C.

  • Model
  • Visão
  • Controller

Autores: Fabrine Pereira

Data: 27/04/06

May 2, 2006 at 3:59 am 2 comments

Resumo da aula 14 – Versão 2.0

UML:

Representação:

  • Sub-Linguagens
  • Modelos(Ferramentas)

Padrões de desenho:

Padrões de desenho é uma boa ídeia, pois com os padrões a comunicação fica mais fácil, melhorando a produtividade. 

XML é um dos padrões mais utilizados atualmente.

XML:

A XML é uma linguagem de descrição de dados, flexível e que possibilita o engenheiro de software construir linguagens usando a XML como uma meta linguagem. O XML não é mais uma linguagem de apresentação. Tem a vatagem de criar algo padronizado e de poder ser utilizado.

Em uma cadeia produtiva, você pode reutilizar mas não pode reutilizar o código, e sim uma cópia do código. Com isso a vantagem da reutilização é assim existe uma maior economia de tempo.

Autor: Fabrine Pereira.

Data: 25/04/2006

May 2, 2006 at 3:33 am 1 comment

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

Resumo da aula 08 – Versão 2.0

Primeiro trabalho:

Hoje a aula foi com monitor.

Foi dado um pouco de HTML, PHP e CEL.

HTML:

Como montar um formulário?

<form …> /* Esse "…" é oque o formulário faz*/

…             /* Esse "…" é oque tem no formulario*/

</form>    /* Fecha o formulário */

PHP:

  • Tag:

<?php?> — Para usar o PHP dentro do código HTML

  • Variável:

@$var = NULL;

@$var = "…" ; /* Esse "…" é algum valor que a variavél irá receber*/

  • Como imprimir na tela (Object response):

<?=$var?>

<?php

    print(); /* "var = $var "*/

    echo(); /* "var =" + $var — É uma concatenação*/

?>

  • Blocos:

Igualzinhos aos da linguagem C.

  • Recebendo parametros (Object request):

$x = $_POST['…']; /* Esse "…" é algum valor */

$Y = $_GET['…'];   /* Esse "…" é algum valor */

  • Conexão com o banco de dados:

$BD = mysql_CONNECT("HOST", login, senha) OR DIE ("Erro:", MYSQL_ERROR());

MYSQL_SELECT_BD("BancoDeDados") OR DIE ("Erro ao abrir o bando ce dados);

/* Esses "…" são valores desejados */

$STRMYSQL = "SELECT * FROM TABELA WHERE Campo1DaTabela = ".$_POST['…']." and Campo2DaTabela = ".$_post['…']."";

$NUM_ROWS = MYSQL_NUM_ROWS($RESULT);

$ROW = MYSQL_FETCH_OBJECT(RESULTS);

$Campo1DaTabela = $ROW->Campo1DaTabela;

CEL (C&L):

  • Cenário:

É um tipo de documentação.

  • Como deve ser feito um cenário:

Título

Objetivo

Contexto

Atores

Recursos

Exceção

Epsódio – É algo que acontece numa determinada situação.

O cenário deve ser um comentário no código.

Autores: Fabrine Pereira, Lourival Neto e Rodolfo Caldeira

Data: 30/03/06

March 31, 2006 at 1:04 am Leave a comment

Older Posts


Categories

  • Blogroll

  • Curiosidades

  • Feeds