Publicado outubro 29, 2006 por Ricardo Costa
Categorias: Resumo

Open Source

Propaganda da IBM sobre o Linux… Será que esta é a solução?

Resumo da aula 20

Publicado outubro 29, 2006 por Carlos
Categorias: Resumo

Primeira prova de Princípios de Engenharia de Software.

Resumo da aula 19

Publicado outubro 29, 2006 por Carlos
Categorias: Resumo

Tempo disponível para estudo.

Resumo da aula 18

Publicado outubro 29, 2006 por Carlos
Categorias: Resumo

Apresentação final do primeiro trabalho de PES.

Resumo da aula 17

Publicado outubro 29, 2006 por Carlos
Categorias: Resumo

Apresentação parcial do primeiro trabalho de PES.

Resumo da aula 16

Publicado outubro 29, 2006 por Carlos
Categorias: Resumo

Arquitetura

             Uma observação pertinente a respeito da conexão de componentes é como projetaremos essa interface. Se a fizermos específica para o projeto em questão, estaremos bloqueando um reuso desse componente em projetos futuros. Surge então a idéia de fazer uma interface mais genérica, a qual acoplaremos um conector que fará a ligação entre os dois componentes em questão. Assim, facilita-se o reuso do componente a um custo baixo para implementar um conector. Contudo, deve-se ter em mente que, caso o componente seja muito genérico, o custo para implementar um conector irá aumentar, dificultando o reuso do componente.

             Desse impasse surge um mantra da engenharia de software: “nem 8, nem 80: 44”. Não só uma recomendação de bom senso diante da realidade, é um chamado à se ter cuidado ao se escolher quão específica será a interface de um componente implementado.

  Micro-arquitetura

             Um livro fundamental para o estudo de micro-arquitetura é “Design Patterns”, dos autores Gamma, Helm, Johnson e Vlissides (a.k.a. The Gang of Four). Seu enfoque maior é a respeito de reuso de elementos em softwares implementados sob Orientação a Objeto. Assim, ele pretende sugerir design patterns que facilitem e aumentem a qualidade do software sendo implementado.

              Para que cada padrão sugerido seja bem definido, os autores sugerem que cada padrão seja descrito a respeito dos seguintes atributos:

  • Objetivo
  • Sinônimo
  • Motivação
  • Aplicabilidade
  • Estrutura
  • Participante
  • Colaboração
  • Consequência
  • Implementação

            Esse número de atributos para descrever um único padrão pretende evitar as falhas existentes na descrição em linguagem natural do mesmo.

Resumo da aula 15

Publicado outubro 29, 2006 por Carlos
Categorias: Resumo

Arquitetura 

            A preocupação de um arquiteto de software se concentra no próprio design do que será implementado. Assim, o arquiteto tentará projetar como os diversos módulos deverão interagir entre si para garantir o bom funcionamento e a qualidade do software desenvolvido. 

            Macro-arquitetura 

            Alguns exemplos de padrões para macro-arquitetura de software:

  • Pipelines & filters: Projeta-se o software como composto por diversos estágios. O tratamento que as entradas receberão começará em um desses estágios e seguirá pelos demais estágios, um após o outro, até que as entradas tenham recebido o tratamento correto, tornando-se, assim, saída.
  • Layers: Software concebido como composto por diversas camadas de círculos concêntricos, onde a troca de informação só é feita por círculos adjacentes através de uma interface bem definida.
  • Blackboard: Projeta-se um espaço de memória centralizado onde todos os demais módulos poderão armazenar e retirar informações, possibilitando-se, assim, a comunicação entre eles, mas com um espaço bem definido onde isso pode acontecer.