Resumo 6 – Versão 1.0

Aula 16

 Aula no laboratório. Os alunos apresentaram seus trabalhos de tela de login. Júlio olhou o código e questionou alguns pontos.

Aula 17

 Discutimos sobre QOS, TQM (Total Quality Management), sobre o ciclo de vida de um software, sobre protótipo e sobre XP.
 
 O tema da aula foi a programação XP. Ela possui as seguintes características:
  -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.

 No trabalho final do curso será adotada essa técnica.

Aula 18

 Discutimos Verificação e Validação e para isso o professor mostrou o processo de inspeção de Fagan.
 Foi levantada a importância de um gerente de projeto para coordenar a equipe em todo o processo.
 O gerente deve escolher as MTFs corretas para que as metas sejam atingidas.

 Fatoração e Re-Fatoração:
  
  Preservação do Comportamento -> Funcional

  -Protótipo = trabalho tentando entender o problema como um todo, a implementação vai crescendo, vai crescendo, e devido a sua evolução, devido ao acúmulo de erros, o programa para de se comunicar, até mesmo de funcionar, a implementação do protótipo vai estar cada vez mais complexo
  -Fatoração = com a fatoração o seu programa vai estar funcionando muito bem para aquela pequena parte(fatorado) do problema.
  -Re-Fatoração = A idéia que esta atrás da re-fatoração é preservar o comportamento.

 A fatoração realmente preseva o comportamento?
  -A literatura diz que sim, mas na realidade talvez cria mudança nos aspectos não funcionais (Ex: Falha de segurança, maior uso de memória, perda de velocidade). Fatoração pode ter problemas de integração de módulos.

 Reuso ou Reutilização de Software:

  -Construção com o reuso = escolha, integração
  -Construção para reuso = generalidade, organização, classificação, armazenamento, acesso, homologação

  Existem 2 tipos de reuso:

   -Reuso Caixa Branca = pega o código e muda
   -Reuso Caixa Preta = você integra o código e não sabe como esta escrito e não muda nada.

  Wrapper = mistura do código caixa branca e caixa preta.

June 28, 2006 at 3:32 pm 4 comments

Resumo 5 – Versão 1.0

Aula 13

  • Aula prática no laboratório de graduação. Estudamos um tutorial da Borland sobre UML, para exemplificar o que havíamos conversado em sala de aula. O professor tirou dúvidas enquanto os alunos respondiam às questões do site.

Aula 14

  • A aula foi sobre padrões de desenho. Um dos mais utilizados atualmente é o XML. Discutiram-se as vantagens do XML em relação à flexibilidade. Ele é muito utilizado para descrever arquivos de configuração e meta-linguagens em linguagens de programação.

Aula 15

  • Foi discutido o modelo MVC (Model View Controller). Esse modelo se baseia em 3 camadas. O View controla a saída gráfica e textual.O Controller interpreta as entradas e o Model controla o comportamento dos dados.
  • Também foram apresentados exemplos de arquitetura de Redes (existe qualquer tipo de comunicação entre os objetos), Repositórios (acoplamento forte). Conversamos sobre a importância de saber utilizar cada estilo.

June 28, 2006 at 3:24 pm 1 comment

Resumo 4 – Versão 1.0

TGS, OBJETO, ASPECTOS (06 / 04 / 2006)

 

Existem algumas Características Básicas dos Sistemas que é importante ressaltarmos:

  • Objetividade (propósito);
  • Entropia (tempo): todo programa se degrada com o tempo;
  • Homeostazia;
  • Globalidade: qualquer modificação produz efeito em todo o sistema.

 

 

Os Sistemas podem ser:

  • Abertos
  • Fechados

 

  • Naturais
  • Artificiais

 

  • Concretos
  • Abstratos

 

Um conceito importante passado foi o de Sistema e Subsistema:

  • Todo Sistema é um subsistema de um sistema maior, onde a condição de parada é o universo;

 

Cada vez mais se torna muito importante desenvolver Sistemas susceptíveis a mudanças.

ACOPLAMENTO / COESÃO

 

Melhor que dividir um problema em partes é hierarquizá-lo em partes e subpartes.

O acoplamento pode ser encarado de duas maneiras distintas e bem diferente uma da outra:

ACOPLAMENTO FORTE X ACOPLAMENTO FRACO

= ACOPLAMENTO FRACO X JUST IN TIME

Acoplamento Fraco: é a passagem simples de dados por parâmetros. Pode ser ilustrado pelo pátio de reserva de matéria prima para produção de uma empresa. Ou seja, o dado transmitido (a matéria prima reservada para ser transmitida) caracteriza um menor acoplamento. Consequentemente uma maior facilidade para mudanças.

 

Acoplamento Forte: podemos exemplificar como o compartilhamento de um mesmo espaço de dados. Ou mesmo de uma mesma estrutura. Se caracteriza por não ser nada susceptível a mudanças.

 

COESÃO: um componente deve fazer uma coisa e somente uma coisa, num dado nível de abstração.

 

INFORMATION HIDING (David Parnas*): Os módulos devem saber o menos possível um do outro. Pois, caso haja mudanças no sistema, o outro módulo não será afetado. Ou será fracamente afetado.

 

DAVID LORGE PARNAS: nasceu em 10 de fevereiro de 1941. É um pioneiro da Engenharia de Software, desenvolveu o conceito de design de módulo que é o fundamento da programação Orientada a Objeto hoje. (Fonte: Wikipedia – http://en.wikipedia.org/wiki/David_Parnas)

ORIENTAÇÃO A OBJETO

 

  • O Objeto é suficiente para qualquer um que o solicite. Ou seja, independente da complexidade, o objeto satisfaz a qualquer requerente, pois ele só possui aquilo que faz parte da sua “essência” enquanto um objeto específico.
  • A Orientação a Objeto nos remete a um conceito muito importante:
    • Hierarquia em OO se transforma em Herança. Exemplo: cadeira e mesa herdam as características de móvel.

ORIENTAÇÃO A ASPECTOS: métodos que servem a variados tipos de objetos. Objetos com características transversais. Ou seja, características comuns a muitas instâncias.

 

 

 

SADT – Structured Analysis and Design Techinique (11 / 04 / 2006)

  • Desenvolvido pela Softtech nos Estados Unidos em 1976.;*
  • Usado em processos industriais na ITT, Thonson; *
  • Pode ser utilizado para descrever qualquer Software não importa qual seja o sistema que estiver sendo executado; *

 

* Fonte: Mamoun Alissali – http://www-ic2.univ-lemans.fr/~alissali/Enseignement/Polys/GL/node50.html

 

SADT é uma técnica para construção de Modelos, onde cada modelo deve ter um objetivo e um ponto de vista.

 

IDEF 0: Derivada do SADT é um método projetado para modelar as decisões, ações e atividades de uma organização ou sistema (http://www.idef.com/IDEF0.html).

 

Existem duas perspectivas de modelo:

  • PROCESSO (ACTIGRAMAS);
  • DADOS (DATAGRAMAS);

 

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

 

May 5, 2006 at 7:25 pm 2 comments

Resumo 3 – Versão 1.0

ANCORANDO CONHECIMENTOS (28 / 03 / 2006)

Nesta aula discutimos sobre base, vocabulário e fundação.

Foi desenhado o ciclo de feedback, e como passar de um universo de informações para um modelo. Como podemos verificar se o modelo é consistente e se ele é correto.

Verificamos os passos para especificar, modelar um projeto:

1)      Delimitar o Universo de Informação.

2)      Identificar atores, livros, documentos.

3)      Cultura da Situação

4)      Encapsular o conhecimento do Universo de Informação, listar o universo de desejos.

5)      Criar um dicionário que tenha denotação e conotação para estabelecer uma âncora

6)      Criar dicionário de dados

MONITORIA SINTAXE PHP, CENÁRIOS E LÉXICOS (30 / 03 / 2006)

Foi nos passado pelo monitor além de alguns conhecimentos básicos de html, um pouco da sintaxe do PHP e funções básicas para que possamos fazer o a tela de login, trabalho 1 da disciplina.

Dentre outras coisas, podemos citar algumas tags e funções mais importantes como: tag form method post, input type text e input type submit; impressão na tela “print”, declaração de variáveis, recebimento e passagem de parâmetros de uma página para outra através das funções _POST[…] e _GET[…].Para Conexão com Banco de Dados também aprendemos alguns conceitos como: criação de strings de conexão, funções para conexão com o banco através da string de conexão, como fazer consultas no banco pelo código PHP e alguns conceitos básico de SQL. Além disso, como acessar cada túpla de uma consulta onde várias túplas são retornadas.Passando para a parte de Cenários e Léxicos aprendemos:

  • Cenário é um conjunto de informações que descreve uma situação. Para o CEL é preciso estruturar essas informações em alguns campos como: Título, Objetivo, Contexto, Autores, Recursos, Exceção e Episódios.
    • O contexto é tudo que envolve a situação ou que leva a ação acontecer.
    • Os atores são as pessoas que, de alguma forma estão envolvidas na situação.
    • Os recursos são todos os objetos envolvidos.
    • Exceção, como o próprio nome já diz, é aquilo que não está previsto no objetivo e que precisa ser tratado para uma ação específica.
    • Os Episódios são todas as ações que envolvem a situação, inclusive as tratadas em virtude da existência de exceções.

 

  • Foi nos passado o exemplo do aluno que vai a biblioteca pegar um livro para estudar. Vamos descrevê-lo:
    • Título: Reservar livro na biblioteca.
    • Objetivo: pegar livro emprestado.
    • Contexto: aluno precisa estudar e aluno não tem o livro, dentre outros.
    • Autores: aluno e bibliotecária.
    • Recursos: biblioteca, carteira de identificação, livros, computador, etc.
    • Exceção: Livro não está na biblioteca.
    • Episódios: aluno chega, aluno pega livro, aluno faz a reserva caso não haja o livro na estante, etc.
  • Léxico: se divide em Noções e Impactos. A partir do exemplo acima podemos entender esses conceitos da seguinte forma:
    • Noções: aluno escolhe o livro, aluno vai pegar o livro emprestado, bibliotecária pega o livro na estante, etc.  
    • Impactos: aluno pegou o livro emprestado, aluno fez uma reserva de livro, bibliotecária vasculhou toda a biblioteca a procura do livro, etc.

MULTITUDE DE OPINIÕES (04 / 04 / 2006 )

Alguns conceitos foram relembrados nessa aula, como o de Universo de Informação: “é 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”.

Outro conceito relembrado foi o que diz respeito às partes do Processo de Desenvolvimento de um Software:

PROCESSO:   DEFINIÇÃO  ->   DESENHO  ->   IMPLEMENTAÇÃO

Além disso, vimos outros conceitos igualmente importantes:

  • O que é implementado em um determinado momento pode ser o Universo de Informação no qual um processo de definição ira ocorrer.
  • Um Universo de Informação conterão interessados (atores) com diferentes pontos de vista.
  • No Universo de Informação, interessados da classe de Desenvolvedores de Software optarão por uma determinada perspectiva.

Os itens acima nos remetem, dentre outros, a alguns conceitos específicos: reuso de código, multiplicidade de conhecimentos e visão a frente do projeto.

Ou seja, num projeto tudo que é implementado pode ser base ou âncora para um outro processo futuro. Essa consideração nos leva a pensar no reuso de código, onde algo que foi codificado anteriormente passa a ser objeto de conhecimento para uma outra aplicação.  E ainda: o profissional da Engenharia de Software deve, não só saber lhe dar com pontos de vistas diferentes em áreas diferentes como ter um conhecimento mínimo das diversas áreas envolvidas no processo. Assim poderá trabalhar com a antecipação de resultados para desenvolver alguma parte subseqüente à outra ainda não terminada.

Numa segunda parte da aula foram nos passado alguns processos de Elicitação do Conhecimento:

  • Entrevista
  • Reunião
  • Leitura de Documentos
  • Questionários
  • Observação
  • Etnografia
  • Reutilização
  • Análise de Protocolo
  • Participação do Cliente / Usuário

A Entrevista pode ser estruturada ou simplesmente elucidativa. Sempre relacionamento “1 para 1”.

Dentre todos os processos citados queremos enfatizar a Reunião como um método muito eficiente, pois pode ser capaz de trazer muitas idéias diferentes e concorrentes, devido a possível presença de uma diversidade de pessoas, naturalmente com pensamentos distintos. Ainda citamos o Brainstorm, método para reuniões onde o interesse está no surgimento das mais diversas idéias não importando a validade delas.

Além da Reunião a Etnografia também é um poderoso processo de obtenção de conhecimentos do dia a dia e das necessidades do cliente. Relacionamento “1 para n” ou mesmo “n para n”.

Na parte de leitura de documentos, é importante ressaltar que possibilita ao Engenheiro de Software dispor de um agente responsável pela leitura e extração de conhecimentos importantes dos documentos.

April 6, 2006 at 11:43 am 2 comments

Resumo 2 – Versão 1.0

Importância do Papel do Desenhador (16/03/2006)
Responsável pela arquitetura, criatividade, e pelo desenho do software.
– A arquitetura é juntar o trabalho braçal com o intelectual (MTF = Método, Técnica, Ferramenta).
– O desenho tem que ser a junção da visão da Arquitetura com a visão de dados.
– Livro Diário = descrever o processo de desenvolvimento leva a eficiência, qualidade e a "antecipação".
– Teorema Boehin e Jacobin = Sequência, relação, iterção.
O Conceito da Base Line – Dificuldades no processo de desenvolvimento ( 21/03/2006)
-Tabela de decisão / Árvore de decisão = Permite mapear estratégias de seleção. Dado uma determinada condição, mapea a ação a ser tomada.
-Baseline = Configuração que servirá como guia no processo de desenvolvimento. É uma âncora, uma base, um ponto de referência.
– transformar em um modelo as necessidades e desejos do usuário. Hoje a baseline evolui e muda constantemente, o que aumenta a complexidade do trabalho do engenheiro de software.
– Conhecimento tácito = conhecimento "trivial" para uns que não é passado adiante.
-Espaço de nomes = Utilizar nomes intuitivos para as variáveis, priorizando desta forma a facilidade de leitura.
Codificando – Dicas para sintonia fina (23/03/2006)
– Codificação = importância de variáveis com nomes sujestivos. Facilidade de escrita contribui negativamente com a facilidade de leitura.
– Espaço por tempo:
– Utilizar estrutura de dados
– Guardar resultados intermediários
– Cashing ( economia de espaço contribui negativamente para a economia de tempo e vice-versa).
– Tempo por espaço:
– Comprensão
– Empacotamento
– INterpretadores
– Minimizar complexidade de algoritmos
– Verificar a possibilidade de tirar sentenças fora de loop.
– Combinar testes para reduzir condições.
– Desenrolar um loop.
– Remoção de seleção sempre que possível.
– Substituição de expressões lógicas por expressões algébricas.
– Priorizar testes mais baratos em relação a testes mais complexos.
– Eleminação de variáveis booleanas.
– Co-rotinas
– Preferir iteração versus recursão.

March 29, 2006 at 4:20 pm 1 comment

Resumos da primeira a terceira aula – versão 1.0

Primeira Aula de Princípios de Engenharia de Software

  • O que é Engenharia de Software?
    Engenharia de Software é uma abordagem sistemática sobre como se produz, opera e mantém um software. Com ela nós dispomos de Métodos, Técnicas e Ferramentas para gerar na construção de softwares um custo-benefício otimizado.
    Existem aqueles que constroem a Disciplina no meio acadêmico e os que a utilizam que são os profissionais da área de computação.
  • O que são Marcadores?
    Os Marcadores servem para guardar endereços visitados na Web e também para associar “tags” e conceitos pessoais aos endereços. Ou seja, para cada link, existe uma opinião de quem o guardou associada. Assim, compartilha-se com todos os melhores “links” sobre assuntos específicos.
  • ACM (Association for Computing Machinery):
    É uma associação internacional e educacional dedicada à ciência e tecnologia.
  • SBC (Sociedade Brasileira de Computação):
    Diferentemente das outras sociedades de computação, a brasileira é mais voltada ao meio acadêmico que para o meio profissional. Ela fomenta e desenvolve a pesquisa científica na área de Computação.
  • Quem é Edward Yourdon?
    Autor de mais de 20 livros e 500 artigos técnicos, Yourdon é o principal nome da Engenharia de Software. Trabalhou por 40 anos na indústria computacional, e participou de muitos projetos pioneiros em sua área. Contribuiu dentre muitas outras coisas, para a parte de análise de orientação a objeto.

 

 

 


   

 

Segunda Aula de Princípios de Engenharia de Software – Engenharia de Requisitos

  • Dentro da engenharia de requisitos temos a programação orientada a ?aspectro?.
    Este visa acoplar todos os ?concern? dos requisitos.
  • V-Graph = Linguagem de modelagem de requisitos. Podemos modelar metas,
    softmetas, tarefas, contribuição e correlação.
  • Tarefas = Maneira de se implementar a meta.
    Metas = Objetivos.
    Softmeta = Não é um objetivo ?forte?.  

    Contribuição e correlação = Decomposições da meta.

    Meta e SoftMeta se correlacionam através das seguintes formas: make, help,
    unknown, hurt, break.

    Tarefas contribuem com Metas e Softmetas através das seguintes formas: and,
    or, xor, make, help, unknown, hurt, break.

 

 


   

 

Terceira Aula de Princípios de Engenharia de Software

   

  • Na terceira aula discutimos sobre produtividade
    Todo processo produtivo envolve CRIATIVIDADE X DISCIPLINA, ARTISTA X ARTESÃO.
    Percebemos que até mesmo os ARTISTAS precisam de DISCIPLINA.
    A disciplina é uma peça chave para organização, cumprimento de metas, criação de documentos, ou seja, disciplina é fundamental para um Engenheiro de Software.
  • Vimos as quatro primeiras regras de disciplina
    o Primeira Regra = Todo documento produzido deve ter título, autor, versão, data e indicador de conteúdo
    o Segunda Regra = Utilizar sempre que possível o princípio de pré e pós condição (assertivas)
    o Terceira Regra = Quando decompor algo, faça-o de tal forma que a decomposição gere no mínimo 3 pedaços e no máximo 6 pedaços
    o Quarta Regra = Evite inventar Terminologia
  • Pesquisa : Quem foi Watts Humphrey ?
    Foi fundador do Software Process Program do Software Engineering Institute
    (SEI) na Carnegie Mellon University. De 1959 a 1986 foi parceiro da IBM
    aonde era diretor de programação. Possui várias publicações de Engenharia
    de Software entre papers e livros.

 

 


   

 

March 15, 2006 at 11:55 pm 1 comment

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!

March 15, 2006 at 7:47 pm 1 comment


Categories

  • Bookmarks

  • Feeds