Resumo Aula 25/04/06

April 26, 2006

A aula de hoje foi sobre padrões e o Julio nos introduziu o conceito do “DESIGN PATTERNS” que especificam formas de separar e isolar o que é igual do que é diferente entre situações. Um bom link sobre o tema que nós encontramos pode ser visto aqui.

E aqui está o livro recomendado pelo Julio.

Nos foi apresentado um padrão que é citado no livro acima, que é o padrão Strategy. Sua intenção seria definir uma família de algoritmos de ordenação de um arranjo, encapsular cada um deles e torná-los intercambiáveis. Além da intenção, devem ser definidas especificados também:

– Nome e classificação; sinônimo; motivação; aplicabilidade; estrutura; participantes; colaboração; conseqüências; implementação; código exemplo; usos conhecidos e padrões relacionados. 

Encontramos esse trabalho, que é um excelente material sobre o assunto.

Resumo Aula 20/04

April 25, 2006

Foi nos apresentado a UML que compreende em desenho, estruturação e especificação de software orientado à objetos e tenta equilibrar o nível de detalhes com o formalismo.
Ela é uma formadora de padrões composta pelas OMT, CU e Bosch que formam a OMG ( Object Management Group ).

Criadas pela UML são as sub-linguagens utilizadas e abaixo estão algumas:

  • casos de uso: (Bosch) diagramas onde estão as interatividades do sistema estático.
  • classe
  • seqüência: diagrama que trata da seqüência de mensagens que são recebidas pelo objeto. Possuem linha de vida e é dinâmico.
  • colaboração: tem mesmo propósito da seqüência, mas sem linha de vida, pode ser visto como diagrama geral do programa e também é dinâmico.
  • estado: alusão à maquina de Turing onde se tem as transações conhecidas ou não para cada novo estado e seus atributos podem ser constantemente mudados.
  • atividade: é um fluxograma que tem poder de decisão ao contrário do SDT. A maior característica são as raias no diagrama.
  • componentes/distribuição/implementação: são diagramas de empacotação.

Resumo Aula 11/04/06

April 12, 2006

Na aula de hoje o Julio falou sobre o SADT (Structured Analysis and Design Technique) que é conhecido, pelo Departamento de Defesa Americano, como IDEF 0.
O SADT foi desenvolvido por Douglas Ross e consiste em uma técnica para a construção de modelos. Cada modelo deve ter um objetivo e um ponto de vista.
O ponto de vista é necessário para ficar bem especificado sobre qual “ótica” estamos modelando o sistema. Toda modelagem dependerá disto. A modelagem pode ser feita sob o ponto de vista do usuário, ou do engenheiro de software, ou do possível cliente que exige o software. Cada ponto de vista ocasionará em modelagens diferentes.
A diferença entre objetivo e ponto de vista é que o objetivo realiza o conjunto de atividades representadas nos diagramas que decompõem o SADT. Já o ponto de vista é como os aspectos reais são tratados pelas atividades modeladas.
Existem duas perspectivas de modelos:
– Processo (actigrama)
– Dados (datagrama)
No curso vamos nos focar no actigrama, que é o modelo de atividades (verbos) do SADT e precisa ter, necessariamente, uma saída e um controle.
Os modelos são construídos segundo os princípios de decomposição, que segue a norma da disciplina: mínimo de 3 e máximo de 6 partes.Dessa maneira os modelos não ficam muito complicados.
A aula terminou com um exemplo de modelagem de aluguel de DVDs. Nesse exemplo, nosso objetivo foi “descrever as principais atividades que um artefato software deve apoiar para que DVD’s sejam alugados”. O ponto de vista foi “engenheiros de software com conhecimento geral sobre o funcionamento de locadoras de DVD”

Resumo Aula 06/04

April 10, 2006

Foi nos apresentado TGS, Objetos e Aspectos:

TGS ( Teoria Geral dos Sistemas ) iniciado por Von Bertalanffy que se dá pela união de conhecimentos gerais para ser aplicados em várias áreas.

Sistemas: conjunto de partes relacionadas para atingir um objetivo, usa Decomposição Hierárquica e tem como principais características:

  • objetividade (propósito);
  • entropia: o sistema se deteriora se não houver mudanças ao longo do tempo;
  • homeostazia: tendência a se adaptar;
  • globalidade: qualquer mudança, por menor que seja, altera o sistema.
  • todo sistema é um subsistema de um maior.

Conceitos de Acoplamento[1] e Coesão[2]:

  1. forte ou fraco: o primeiro é mais rápido, menos prático para mudanças e o segundo é ao contrário.
  2. cada componente fazer uma única função(modularização).

Para se fazer um sistema que precise ser duradouro deve usar o acoplamento fraco com forte coesão para que seu programa esteja dentro das características de sistema.

Outro ponto dentro de Sistema foi o INFORMATION HIDING elaborado por Parna: que pode ser bem identificado como conceito de modularização.

Objetos:

característica chave: herança(como por exemplo a linguagem Java). São dados e processos através de mensagens e um objeto pode atender a vários senhores que vai contra ao TGS.

Aspectos: não tem decomposição hierárquica e serve para várias causas.

Resumo Aula 28/03

April 9, 2006

A aula começou com um nome tanto famoso no mundo da computação que é Wirth que disse que "dados + algoritmos = software" 

1- Dado esse fato começamos a tentar delimitar o Universo de Informação:

– verificar a consistência do modelo, usando o feedback para ter certeza se era  o que o cliente realmente espereva;

– verificar se o modelo está correto junto ao mundo real (atendendo ao U.I.).

2- Especificar os Atores (engenheiros, usuários, documentos);

3- Estar interado à cultura da situaçao; saber o vocabulário para haver plena comunicação.

4- encapsular o conhecimento do U.I.; listar as necessidades do cliente.

Resumo Aula 5 – 21/03/06

March 24, 2006

Foi apresentado em sala uma proposta de aceitação de segurados. Usamos o que aprendemos por TABELA DE DECISÃO, que faz uma espécie de mapeamento de condições e permite uma análise mais minuciosa do problema em questão. Nossa tabela nos levou a concluir algumas inconsistências na proposta.

O que fazer nesses casos de inconsistência? O ideal é voltar ao idealizador da proposta e questioná-lo sobre aquilo que nos foi apresentado e a falha encontrada, ainda que por bom senso tivesse sido possível encontrar uma solução bem razoável. A esse processo de verificação, damos o nome de feedback.

De uma forma sintetizada, o Engenheiro de Software deve transformar as necessidades e desejos do cliente em um modelo, utilizando uma determinada linguagem de representação e, caso seja detectada uma inconsistência (um método para encontrar seria a tabela de decisão), deveria ser adotada a estratégia de feedback.

Conhecimento tácito foi explicado como sendo o conhecimento que é tão óbvio e presente no seu universo que você sequer cogita explicar para uma outra pessoa.

O último conceito ensinado, baseline, seria uma referência para as etapas seguintes da construção (desenhar e implementar).

Resumo Aula 4 – 16/03/06

March 22, 2006

A aula foi basicamente sobre organização do programador.

Foi-nos apresentado o Teorema de Böhm & Jacopini que diz que todos programas podem ser feitos à partir de 3 princípios, sem a necessidade do GOTO, que são:

  • Seqüência: dados executados em ordem, n -> n+1;
  • Seleção: código if {bloco de dados} else {bloco de dados};
  • Iteração: a repetição de certo bloco de dados com uma certa condição de parada, Código for (condições) { bloco de dados }

Num trabalho muito importante, Bohm e Jacopini demonstraram em 1966 que qualquer programa pode ser escrito sem usar a instrução goto, usando apenas três tipos de estruturas de controle de entrada e de saída únicas. Isso evita os problemas criados pelas entradas e saídas múltiplas, e permite a escrita de programas muito mais fáceis de serem compreendidos.
Essas estruturas de controle são a seqüência, a seleção e a repetição.

As linguagens de computador estruturadas são linguagens que usam essas estruturas de entrada/saída únicas, e não usam ou não tem a instrução goto. A linguagem Java é estruturada e não possui a instrução goto. “

por http://www.cefetba.br/fisica/NFL/Java/linguagemestruturada.html#biblio2

Também Djisktra foi lembrado por salientar a abolição do comando GOTO, mais informações e até a carta enviada por ele para leitura informativa está disponível aqui: http://david.tribble.com/text/goto.html

Foi destacado a importância de se ter, quanto programador, um livro diário ou um PSP que servem para que você anote todas suas ações daquele dia para que futuramente haja uma antecipação de erros. Também foi introduzido por Donald E. Knuth a linguagem TeX que é um programação literária e alterada por Leslie Lamport (LaTeX).

Resumo Aula 3 – 14/03/06

March 21, 2006

Nessa terceira aula o professor Julio ressaltou a importância da disciplina para um engenheiro de software. O conceito de produtividade foi exposto da seguinte maneira:PRODUTIVIDADE:

CRIATIVIDADE X DISCIPLINA

De forma que a disciplina é essencial para um engenheiro de software que desempenha, necessariamente, um trabalho cooperativo.

Quando pensamos em disciplina, existem quatro regras fundamentais para serem seguidas por um engenheiro de software no desenvolvimento de um trabalho:

1. todo documento (tudo produzido pelo engenheiro de software no processo de produção) deve ter:

– título;

– autor;

– versão;

– data;

– indicador de conteúdo.

2. utilizar sempre que possível o princípio de pré e pós condição.

– o que aprendeu, o que não entendeu, o que duvida, etc.

3. quando decompor algo, faça-o de tal forma que a decomposição gere no mínimo três e no máximo seis pedaços.

4. evite inventar terminologia.

Para finalizar a aula, nos foi pedido para que procurássemos por Watts Humphrey.

Resumo Aula 2

March 15, 2006

A aula dada pela professora Lyrene teve como principal ponto fornecer informações sobre “Engenharia de Requisitos” que consiste em:

  1. Definir os requisitos do software;
  2. Analisar a praticidade e custo destes requisitos;
  3. Modelar o Software.

O que apesar de apresentar 3 passos, é muito trabalhoso preenchê-los, como nos foi mostrado em aula um modelo orientado à metas (postarei foto do modelo mais tarde).

Pesquisando no Google obtive pelo site da PUC-Rio a seguinte definição para E.R.:

A Engenharia de Requisitos, uma sub-área da Engenharia de Software, estuda o processo de definição dos requisitos que o software deverá atender.”
A postura da Engenharia de Requisitos é a de prover ao Engenheiro de Software, métodos, técnicas e ferramentas que auxiliem o processo de compreensão e registro dos requisitos que o software deve atender.”

Foi nos apresentado também o modelador de metas chamado V-Graph.
Em um modelador existem 3 tipos de aspectos ( concerns ) a serem lidados:

  • metas: representada em um modelado envolvido por um octágono e as metas são aspectos de um software que podemos, realmente, assegurar sua completa funcionalidade;
  • softmetas: representada em um modelado envolvido por uma nuvem e são aspectos abstratos do software, como segurança, que não se pode assegurar total firmeza de funcionalidade;
  • tarefas: representada em um modelado envolvido por um hexágono e são as características do programa que dão forma, consistência para as metas e softmetas.

Ao linkar estes 3 aspectos é formada a correlação ( make++, help+, unknow?, hurt-, break– ) e a contribuição ( and, or, xor ) entre eles, que serão melhor observados quando postarmos o modelo.

Resumo Aula 1 – 07/03/06

March 8, 2006

O professor começou a apresentação dizendo seu nome, Julio Leite e, disse como acessar a página do curso e seu blog.

Foi explicado o critério de avaliação:

Grau 1: desenvolvimento de um trabalho individual

Grau 2: prova a ser feita antes do dia 25/05

Grau 3: média da avaliação do projeto e da avaliação do resumo

Grau 4: marcadores (‘tags’) individuais e relatório final do projeto

Os resumos podem ser feitos em grupos de 3 (três) e são lançados como um blog.

Bibliografia recomendada:

Engenharia de Software de Ian Sommerville (tem disponível na biblioteca da informática)

Julio falou sobre software de marcadores, que funcionam como uma espécie de favoritos onde você pode cadastrar o site por algum nova que te remeta ao assunto abordado. Um exemplo é o del.icio.us. Falou também sobre plágios e citou o site www.plagiarism.org

CACM (Communications of the ACM) => uma publicação mensal da ACM que traz novidades no campo da computação e tecnologia.

ACM (Association for Computing Machinery) => Uma associação de computação que integra estudantes e profissionais de mais de 100 países.

IEEE (Institute of Electrical and Electronics Engineers)

SBC (Sociedade Brasileira de Computação) => Segundo o Julio, ela tem maior perfil acadêmico que a IEEE e a ACM.

O Julio explicou que a disciplina disponibiliza métodos, técnicas e ferramentas (MTFs) que ajudam na construção de um software e contou casos sobre prejuízos e tragédias que podem resultar de um pequeno erro no software. Como:

Bug do Milênio

Therac 25

Ambulância de Londres

Citou também Edward Yourdon.