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

Resumo da aula 07 – Versão 2.0

Ancorando o conhecimento:

Foi discutido em aula:

• Base
• Vocabulário
• Fundação

Oque significam as perguntas: “ É correto? ” e “ É consistente? ”

• “ É correto? ” pode  ser respondida sem a intervenção dos clientes/usuários.
• “ É consistente? ” requer a presença de pelo menos um  ator para que seja respondida. Um modelo consistente pode estar incorreto.

Conceito de validação e verificação:

O teste é uma validação, pois procura comparar as expectativas com os resultados demonstrados. Um teste determina defeitos, para encontrar erros é preciso de um outro processo. A verificação pode ser feita sem a intervenção do cliente/usuário. Com isso é passível de tratamento por uma máquina.

Passos para especificar (modelar) os requisitos de um software:

• Delimitar o universo de informações
• Identificar atores, livros, documentos e a cultura da situação
• Encapsular o conhecimento do universo de informaçôes e listar o universo de desejos (Todas as necessidades do cliente/usuário)
• Criar um novo dicionário que tenha denotação e conotação para estabelecer um âncora

Existe uma necessidade de ancorar o conhecimento de um determinado universo de informação para que ele seja devidamente compartilhado e utilizado na construção de um software. Para que o mundo real (mundo de interesse para uma determinada máquina de software) seja delimitado, é fundamental o conceito do universo de informação.

Autores: Fabrine Pereira, Lourival Neto e Rodolfo Caldeira

Data: 30/03/06

Resumo da aula 06 – Versão 1.0

Conceitos básicos de codificação:

• Espaço de nomes:

Está apresentado no livro “Code Complete”, de Steve McConnell. No contexto de nome de variáveis em uma estrutura de repetição.

Na aula foi dado um exemplo simples para facilitar o entendimento da nomeação adequada de variáveis. Tal exemplo foi sobre:

Um simples cálculo de médias que poderia servir tanto para:

Médias de uma turma de 20 alunos com 5 notas ou média de temperaturas de 20 cidades tomadas 5 vezes no ano ou média das 20 escolas de samba segundo nota geral de 5 jurados.

Nomes significativos ajudam e devem ser norma, e também levam mais tempo para serem digitados. Poderia ser adotada uma estratégia de “prettyprinter” para formatar códigos que utilizem mnemônicos.

Como por exemplo:

• Softmetas – Nesse caso foi comparando a facilidade de leitura com a velocidade na codificação.
• Série de dicas de John Bentley (sobre sintonia fina de programas) – Onde as duas softmetas: Economia de espaço e economia de tempo pode ser conflitante. É colocado um determinado conjunto de sentenças dentro de um programa ou é feito do mesmo programa, uma chamada para uma função que conterá esse conjunto de sentenças. Além da economia de espaço e da economia de tempo, existem outras duas softmetas, que são facilidade de leitura e facilidade de manutenção.

• Entrelaçamento de código com sua especificação:

Na maioria das vezes é visto como documentação/comentário (Com a segunda regra de disciplina: Pré-condições e Pós-condições).

Autores: Fabrine Pereira, Lourival Neto e Rodolfo Caldeira

Data: 28/03/06

Resumo da aula 05 – Versão 1.0

Conceito de "baseline":

Antes de explicar o conceito de "baseline", foi feito em aula um exercício de mapeamento de condições.

– Criatividade

– Tabelas de decisões:

• Permite mapear estrutura de seleção.
• Ajuda a visualizar, esquematizar as ações de acordo com as condições.
• Tem o objetivo de facilitar o entendimento do problema.
• Sua tarefa é organizar o espaço de condições. Ao fazer isso é possível que inconsistências sejam identificadas na tabela.
• É útil para estruturas de repetição (no que diz respeito a condição)

– Seqüência

– Seleção:

• Só poderá ser utilizada quando for mapeada.

– Repetição  

Exercício de mapeamento    

Suponha o seguinte uso:    

Uma empresa de segurança tem normas para determinar se um candidato a seguro pode obter um seguro e em que condições essas regras poderiam ser sumarizadas abaixo  

1) Pessoas acima de 65 anos não podem ser seguradas, a não ser que:

     a) Tenham exame médico ou

     b) Não tenham acidentes nos últimos cinco anos

2) Pessoas envolvidas com mais de 2 acidentes não podem renovar/fazer seguro.   

3) Pessoas menores de 25 anos podem fazer seguro se e somente se:

     a) Submeterem-se a exame médico

     b) Não tiverem mais que x pontos na carteira

4) Jovens menores de 25 anos podem fazer seguro se:

     a) Pagarem prêmio extra

     b) Tiverem até x pontos na carteira

Existe inconsistência na descrição desse sistema! Não cabe ao engenheiro de software decidir se está correto ou não, mas cabe a ele ter a preocupação de satisfazer o cliente. O correto é esclarecer a inconsistência do sistema com o cliente/usuário que escreveu as regras sobre o problema detectado.

Autores: Fabrine Pereira, Lourival Neto e Rodolfo Caldeira

Data: 23/03/06

Referências:

Hurley, R.B. Decision tables in software engineering, Van Nostrand Reinhold Company, 1983

Resumo da aula 04 – Versão 2.0

O papel do desenhador: 

Desenhador — Trabalho braçal + Trabalho intelectual 

O algoritmo de Böhm & Jacopini:

“O conceito de programação estruturada foi introduzido em 1962 através de artigos escritos por E.W.Dijkstra e C.Bohm & G.Jacopini, os dois últimos afirmavam que era possível escrever qualquer programa utilizando os três construtores básicos: sequência, repetição e decisão, eles afirmavam que utilizando estes construtores, a programação tornar-se-ia mais fácil de entender e manter. A partir destas idéias, no início dos anos 70, foram surgindo os conceitos do projeto estruturado (W.Stevens. – G.Myers – L.Constantine), no qual se organizavam as funções de um programa de forma hierárquica, sobre a qual estão presentes dois conceitos fundamentais: acoplamento – comunicação entre os módulos do sistema; e coesão – relações internas dos módulos. O produto final só estaria em um nível aceitável de qualidade para ser colocado em produção, quando possuísse baixo acoplamento e alta coesão. Mais tarde, Chris Gane e T.Sarson, Tom Demarco e Edward Yourdon publicaram livros descrevendo um método estruturado de analisar sistemas.” Existe ainda a dificuldade de determinar as condições de controle de estruturas como:

• Seqüência
• Seleção
• Iteração

Observações ao texto acima:

A forte coesão e o baixo acoplamento são opcões, mas não significa que todo o desenho tenha que ter essa caractéristica. A preocupação com as condições estão ligadas com as estruturas de repetição, principalmente, e com a estrutura de seleção!

Essas estruturas devem estar bem mapeadas antes dessas condições serem utilizadas numa descrição mais próxima do programa ou até mesmo do próprio programa. Como por exemplo, os fluxogramas:

• É uma maneira de organizar o pensamento procedural.
• “Não é algo aplicável apenas a programas de computador, é útil também para descrever determinados procedimentos.”

Autores: Fabrine Helena Pereira, Lourival Neto e Luiz Rodolfo Neves Caldeira

Data: 22/03/06

Resumo da aula 03 – Versão 2.0

Modelo orientado a metas:

Intencional/Aspect Oriented
O exemplo de modelo intencional é o V-Graph um modelo orientado a metas
O objetivo do CEL é apresentar a complexidade. O modelo do CEL não é complexo e sim a aplicação.

 Disciplina:

Criatividade X Disciplina
Artista X Artesão
O trabalho cooperativo é o processo de construir software, a disciplina em si não é um trabalho cooperativo. O processo tem que Utilizar a disciplina, tanto em nível de grupo como a nível individual. Regras da disciplina:   

• Primeira regra:   
  • Todo documento (é tudo aquilo produzido pelo engenheiro de software. Como por exemplo, no processo de produção o programa fonte é um documento) produzido deve ter:
    a) Título
    b) Autor
    c) Versão
    d) Data
    e) Indicador de conteúdo/unicidade 
• Segunda regra:
  • Utilizar "sempre que possível" o princípio de pré e pós Condição (assertivas).
    pré-condição — Oque eu sabia.
    pós-condição — Oque eu aprendi. Critério de qualidade sob o ponto de vista da compreensão.
• Terceira regra:
  • Quando decompor algo o faça de forma que a decomposição gere no mínimo três pedaços e no máximo seis pedaços.
• Quarta regra:
  • Evite inventar terminologias!
• Quinta regra:
  • Trabalhar com conteúdos de tamanho pequeno, fazer desenhos os mais limpos possíveis e procurar soluções simples, mas não simplistas.
    "Small is beautiful" — "Clean design" — "Simple solutions"
• Sexta regra:
  • Mantenha um livro diário, um local onde são feitas as suas anotações sobre o seu trabalho. Desde diários elaborados como a proposta de PSP, ou como o que  o Knuth utilizou para manter os eventuais erros encontrados no Tex. Neste diário Knuth registrou durante 10 anos 867 entradas descrevendo os erros e como eles foram tratados (programação literária).   

Autores: Fabrine Helena Pereira, Lourival Neto e Luiz Rodolfo Neves Caldeira

Data: 14/03/06

Resumo da aula 02 – Versão 2.0

Engenharia de requisitos                   

Programação orientada aspecto:    

A programação orientada aspecto, assim como a Programação Orientada a Objetos, introduz um novo paradigma e um conjunto de diretrizes para facilitar o desenvolvimento de software. Pode ser vista como um estilo de programação, por abordar de maneira mais elegante questões que poderiam ser resolvidas de outras formas. Lida com um problema específico:   Capturar unidades consistentes de um sistema de software que as limitações dos modelos de programação tradicionais forçam a ficar espalhados por diversos pontos do sistema.

Para entender o espírito da programação orientada aspecto, é preciso entender alguns conceitos fundamentais:  

• Responsabilidades (concerns)  
• Sistemas de software consistem de um conjunto de “áreas de interesse” ou responsabilidades distintas como, por exemplo, responsabilidades funcionais e não-funcionais. Existem também as preocupações relacionadas com o processo de desenvolvimento de software, como clareza de entendimento, facilidade de manutenção e simplicidade de evolução do software.
• Responsabilidades transversais (crosscutting concerns):  
• Em sistemas complexos, sempre existem responsabilidades de interesse comum que são utilizadas por vários módulos. As responsabilidades não-funcionais geralmente têm esta característica, mas também algumas funcionais. Estas responsabilidades são difíceis de isolar, pois são necessárias em vários pontos do código. Em programação orientada objeto, uma classe oferece uma boa maneira de se separar à maioria das responsabilidades funcionais, mas é bastante limitada quando se trata de responsabilidades transversais. Com a programação orientada objeto, os crosscutting concerns ficam espalhados por vários módulos em pequenos trechos de código que são, em geral, repetitivos, resultando em sistemas difíceis de projetar, entender, implementar, manter e evoluir.  

A programação orientada aspecto complementa a programação orientada objeto por introduzir uma nova dimensão para a decomposição das responsabilidades transversais: os aspectos.  

O paradigma da programação orientada aspecto consiste na separação das responsabilidades transversais de um sistema em aspectos (unidades modulares) e a sua posterior composição junto às classes, formando um sistema único. Os aspectos podem ser inseridos, alterados ou removidos em tempo de compilação. Por estarem em um único bloco de código, sua manutenção é mais simples, diminuindo a complexidade do sistema e facilitando o seu entendimento. Além disso, o código das classes fica livre do código relacionado às responsabilidades transversais, o que facilita sua reutilização em diferentes contextos, combinando diferentes aspectos dependendo das necessidades da aplicação.  

AspectJ – Nova técnica de modelagem:  

O AspectJ é uma ferramenta open source que acrescenta os conceitos de programação orientada aspecto à linguagem Java, através de uma extensão à linguagem: os “aspects”. Ele utiliza Java como a linguagem para a implementação dos concerns individuais, e tem construções para a especificação das regras de weaving, que são especificadas em termos de join points, pointcuts e advices, e tudo isto é encapsulado em um aspect.  

Um requisito não pode ser abstrato!  

Existem várias maneiras de modelar requisitos. O V-Graph é um tipo de modelo de metas (é satisfeita totalmente através do conjunto de submetas e tarefas nas quais elas se decompõem), softmetas (é parcialmente satisfeita pelas metas, softmetas e tarefas que contribuem ou estão correlacionadas positivamente a ela) e tarefas. Esses são os três elementos dessa linguagem que possui três relacionamentos:  

• Contribuição:  
• A contribuição é utiliza com o mesmo sentido da decomposição.  
• Make (++), help (+), unknown (?), hurt (-) e break (–).
• Correlação:  
• A correlação é utilizada para representar relacionamentos de contribuição horizontal entre diferentes árvores ou subávores, indicando menor acoplamento do que os elos de decomposição e contribuição.  
• Make (++), help (+), unknown (?), hurt (-) e break (–).  
• Decomposição  
• AND, XOR ou OR.  

A contribuição e a correlação são maneiras de decomposição da meta e da softmeta. Oque muda entres essas relações são onde elas serão utilizadas.  

Cada elemento (metas, softmetas e tarefas) é composto de duas partes:  

• Tipo:  
• Descreve uma função genérica ou um requisito não-funcional genérico.  
• Tópico:
• Captura a informação contextual para o elemento. 

Autores: Fabrine Helena Pereira, Lourival Neto e Luiz Rodolfo Neves Caldeira

Data: 09/03/2006

Resumo da aula 01 – Versão 2.0

Oque é engenharia de software? 

É uma disciplina que com o passar do tempo vem se tornando cada vez mais importante. Muito pouco é feito hoje em dia sem o software. A tendência com o tempo é o software estar cada vez mais presente nas nossas vidas.  A engenharia de software é uma disciplina de conjunto de MTFs que tem como objetivo melhorar o custo/benefício do artefato projetado pelo engenheiro. Esse conjunto de MTFs é:

• Métodos
• Técnicas
• Ferramentas

A falta de utilização de MTFs acarreta graves problemas na produção e/ou uso do software. Foram mencionados, em sala, vários casos onde a falta do uso de MTFs adequadas levou à desastres bastante conhecidos no mundo do software. Como a crise do ano 2000 e o caso do sistema de ambulâncias de Londres. Produzir software é uma tarefa difícil, portanto exige um grande volume de conhecimento para que o processo de produção seja conduzido com qualidade. E ao mesmo tempo, o aumento do conhecimento, também aumenta a dificuldade de aplicá-lo de maneira integrada.
Para produzir um software é necessário possuir pelo menos três tipos de conhecimento:  

• Conhecimento de engenharia de software
• Conhecimento do contexto
• Conhecimento da máquina computacional 

A engenharia de software tem o desafio de prover MTFs que ajudem os engenheiros de software a entenderem o contexto onde o software irá atuar e as limitações da máquina computacional (é uma combinação de hardware e software) em que o software irá residir. Para isso é inevitável que o engenheiro de software trate o problema da transição de descrições informais para descrições formais e que também modele adequadamente as restrições da máquina escolhida.   A engenharia de software pode ser vista por dois prismas:

• Construção da disciplina — Ciência E Tecnologia 
• Utilizada por profissionais

Autores: Fabrine Helena Pereira, Lourival Neto e Luiz Rodolfo Neves Caldeira

Data: 07/03/2006