Wednesday, November 22, 2006
Tuesday, November 21, 2006
Aula 24 (v.2)
Nesta aula, vimos que um gerente de projeto de software utliza-se de indicadores de produtividade para avaliar a evolução do trabalho realizado. Uma das formas de medir a produtividade de um projeto desta natureza é a taxa de número de linhas de código geradas por dia, por cada programador que faz parte da equipe de projeto. Este indicador (LOC) é o mais utilizado atualmente. Como exemplos temos:
- 1999: 37/dia.
- 2001: 25/dia.
- Windows Vista: 4,2/dia.
- Empresas que utilizam UML: 32/dia.
Existem outras formas de medir a produtividade, como os "pontos por função" criado pela IBM e que utiliza elementos abstratos para gerar um resultado.
Vimos também que as principais atividades de um gerente de projeto são:
- Organizar: identificação e estudo de disponibilidade dos recursos necessários para cumprir seu objetivo.
- Planejar: é a geração de um "blueprint" que contenha a maneira pela qual o objetivo será atingido.
- Coordenar: garantir que os membros da equipe do projeto, artefatos, técnicas e infraestrutura estejam apontando para o objetivo.
- Controlar: assegurar que o plano esteja sendo cumprido.
- 1999: 37/dia.
- 2001: 25/dia.
- Windows Vista: 4,2/dia.
- Empresas que utilizam UML: 32/dia.
Existem outras formas de medir a produtividade, como os "pontos por função" criado pela IBM e que utiliza elementos abstratos para gerar um resultado.
Vimos também que as principais atividades de um gerente de projeto são:
- Organizar: identificação e estudo de disponibilidade dos recursos necessários para cumprir seu objetivo.
- Planejar: é a geração de um "blueprint" que contenha a maneira pela qual o objetivo será atingido.
- Coordenar: garantir que os membros da equipe do projeto, artefatos, técnicas e infraestrutura estejam apontando para o objetivo.
- Controlar: assegurar que o plano esteja sendo cumprido.
Aula 23
A arquitetura sob ótica de reuso foi discutida nesta aula. Novamente observamos que quanto mais trabalho é desprendido durante a codificação, através de preocupação com flexibilidade, armazenamento e catalogamento, mais fácil será o re-uso do código no futuro. Ao passo que menos trabalho, preocupando-se apenas com descrições, buscas e integrações, mais difícil se torna o re-uso.
Em orientação a objetos, devemos reduzir a distância conceitual entre o mundo real e o código, ao definirmos os objetos que virão a interagir entre si, a fim de garantirmos o re-uso do mesmo. Algumas estratégias para reduzir esta distância, organizando de formas distintas os componentes são:
- Design Patterns: Não utiliza o conceito de hierarquias ao adicionar funcionalidades aos componentes.
- Tagging: Os componentes são etiquedados através de palavras-chaves sugeridas pelos usuários.
- Reuso Generativo: Como o nome sugere, visa a generalização dos componentes.
- Rúben Prieto-Diaz: Nome do autor e método, que consiste em organizar os componentes em pares de triplas.
Em orientação a objetos, devemos reduzir a distância conceitual entre o mundo real e o código, ao definirmos os objetos que virão a interagir entre si, a fim de garantirmos o re-uso do mesmo. Algumas estratégias para reduzir esta distância, organizando de formas distintas os componentes são:
- Design Patterns: Não utiliza o conceito de hierarquias ao adicionar funcionalidades aos componentes.
- Tagging: Os componentes são etiquedados através de palavras-chaves sugeridas pelos usuários.
- Reuso Generativo: Como o nome sugere, visa a generalização dos componentes.
- Rúben Prieto-Diaz: Nome do autor e método, que consiste em organizar os componentes em pares de triplas.
Aula 22 (v.2)
Vimos nesta aula o conceito de refatoração e os benefícios que este processo traz ao programador. Ao refatorar um código, devemos nos guiar por 3 principais regras: acoplamento, coesão e encapsulamento. Durante esta re-estruturação, as duplicidades são removidas a fim de garantir coesão, o código pode ser simplificado para facilitar o acoplamento de outros módulos e as informações que podem ocasionar falhas de segurança são encapsuladas.
Fan-in é o termo utilizado para avaliar o número de "inputs" que um módulo recebe, e fan-out, o de "outputs" que um módulo utiliza. Com estes conceitos, podemos inferir que a situação ideal após a refatoração é o aumento de fan-in e a diminuição de fan-out.
O paradigma da orientação a aspectos é auxiliar o programador na separação de interesses, como forma de melhorar a modularização do código. Para tanto são identificadas e removidas as redundâncias de funcionalidades de um código.
Um dos 12 princípios de XP é justamente a refatoração. Os princípios são:
- Jogo de Planejamento;
- Pequenas versões;
- Metáfora;
- Desenho simples;
- Processo de testes;
- Refatoração;
- Programação em pares;
- Propriedade de código coletiva;
- Integração contínua;
- Carga horária sustenstável;
- Alta disponibilidade do cliente;
- Padrões de codificação.
Fan-in é o termo utilizado para avaliar o número de "inputs" que um módulo recebe, e fan-out, o de "outputs" que um módulo utiliza. Com estes conceitos, podemos inferir que a situação ideal após a refatoração é o aumento de fan-in e a diminuição de fan-out.
O paradigma da orientação a aspectos é auxiliar o programador na separação de interesses, como forma de melhorar a modularização do código. Para tanto são identificadas e removidas as redundâncias de funcionalidades de um código.
Um dos 12 princípios de XP é justamente a refatoração. Os princípios são:
- Jogo de Planejamento;
- Pequenas versões;
- Metáfora;
- Desenho simples;
- Processo de testes;
- Refatoração;
- Programação em pares;
- Propriedade de código coletiva;
- Integração contínua;
- Carga horária sustenstável;
- Alta disponibilidade do cliente;
- Padrões de codificação.
Thursday, November 16, 2006
Aula 20 (v.2)
Nesta aula discutimos as principais estratégias de desenvolvimento de software através da adoção de métodos, técnicas e ferramentas (MTF's): Cascata, Prototipação, Espiral, V, RUP e XP.
Cascata:
É a estratégia de desenvolvimento mais comum e consiste em uma sequência de passos (definição, arquitetura e implementação). Como toma bastante tempo e sua validação e verificação se dão após a implementação, o produto torna-se muito caro e dificil de se modificar.
Prototipação:
Apresenta ciclo de vida mais curto, oferecendo ao cliente a possibilidade de realizar modificações há qualquer momento, já que ele tem contato direto com os construtos ainda antes de sua versão final de produção.
Espiral:
Transforma a linearidade da estratégia de cascata em ciclos. Ao final destes são realizadas análises de riscos a fim de garantir a organização do processo e a evolução mais saudável do software.
V:
Desenvolvido na Alemanha, esta estatégia também se assemelha à técnica de cascata, mas busca validar e verificar constantemente (após cada etapa) não só o que está sendo desenvolvido, mas como se está desenvolvendo.
RUP:
Bastante utilizado em projetos orientados a objetos, o Rational Unified Process pode ser visto como uma adaptação do modo espiral que utiliza-se de quatro fundamentais ciclos: lógico, processo, físico e desenvolvimento.
XP:
Uma forma recente e agressiva de produzir softwares. É iniciado com a criação de testes para código ainda inexistente. Representa a quebra de padrões, já que a implementação antescede o próprio design. Traz como vantagem a velocidade com que as primeiras versões são apresentadas ao cliente.
Cascata:
É a estratégia de desenvolvimento mais comum e consiste em uma sequência de passos (definição, arquitetura e implementação). Como toma bastante tempo e sua validação e verificação se dão após a implementação, o produto torna-se muito caro e dificil de se modificar.
Prototipação:
Apresenta ciclo de vida mais curto, oferecendo ao cliente a possibilidade de realizar modificações há qualquer momento, já que ele tem contato direto com os construtos ainda antes de sua versão final de produção.
Espiral:
Transforma a linearidade da estratégia de cascata em ciclos. Ao final destes são realizadas análises de riscos a fim de garantir a organização do processo e a evolução mais saudável do software.
V:
Desenvolvido na Alemanha, esta estatégia também se assemelha à técnica de cascata, mas busca validar e verificar constantemente (após cada etapa) não só o que está sendo desenvolvido, mas como se está desenvolvendo.
RUP:
Bastante utilizado em projetos orientados a objetos, o Rational Unified Process pode ser visto como uma adaptação do modo espiral que utiliza-se de quatro fundamentais ciclos: lógico, processo, físico e desenvolvimento.
XP:
Uma forma recente e agressiva de produzir softwares. É iniciado com a criação de testes para código ainda inexistente. Representa a quebra de padrões, já que a implementação antescede o próprio design. Traz como vantagem a velocidade com que as primeiras versões são apresentadas ao cliente.
Aula 17 (v.2)
Entrega do Trabalho 1
Links:
Philippe: http://pes.inf.puc-rio.br/c0311895/site/index.html
Andre:http://pes.inf.puc-rio.br/e0220628/site/index.html
Links:
Philippe: http://pes.inf.puc-rio.br/c0311895/site/index.html
Andre:http://pes.inf.puc-rio.br/e0220628/site/index.html
Wednesday, November 15, 2006
AULA 16
DESIGN PATTERNS
Foi comentado novamente sobre a gangue dos 4. Que foi visto na aula passada. O assusto de arquitetura de sofware foi retomado. Mas enfatizando o problema de acoplamento. A aula se resumiu em acoplamento forte e fraco.
O interessante de fazer um acoplamento fraco é que o software se torna mais maleável. Podendo reaproveitar módulos do software para reutilização. Pondendo assim se utilizado num projeto futuro. Economizando tempo e dinheiro.
Foi feita a comparação entre Lego e Quebra-cabeças. O Lego tem n possibilidades de encaixe enquanto o Quebra-cabeça só tem uma. Uma forma de ilustrar o que já foi dito a cima.
A independência dos componentes custa caro e leva tempo. Mas a possibilidade de reúso, paga os prejuízos da produção.
O livro da gangue dos 4 mostra padrões que devem ser seguidos para contruir visando reutilização.
Todo modelo deve ter :
Foi comentado novamente sobre a gangue dos 4. Que foi visto na aula passada. O assusto de arquitetura de sofware foi retomado. Mas enfatizando o problema de acoplamento. A aula se resumiu em acoplamento forte e fraco.
O interessante de fazer um acoplamento fraco é que o software se torna mais maleável. Podendo reaproveitar módulos do software para reutilização. Pondendo assim se utilizado num projeto futuro. Economizando tempo e dinheiro.
Foi feita a comparação entre Lego e Quebra-cabeças. O Lego tem n possibilidades de encaixe enquanto o Quebra-cabeça só tem uma. Uma forma de ilustrar o que já foi dito a cima.
A independência dos componentes custa caro e leva tempo. Mas a possibilidade de reúso, paga os prejuízos da produção.
O livro da gangue dos 4 mostra padrões que devem ser seguidos para contruir visando reutilização.
Todo modelo deve ter :
- Objetivo
- Sinônimo
- Motivação
- Aplicabilidade
- Estrutura
- Participante
- Colaboração
- Conseqüência
- Implementação
AULA 15
ARQUITETURA
Começamos a falar sobre a Microsoft especificamente de Bill Gates. Ele fala que é o Arquiteto chefe da Microsoft em vez de dono. Isso porque ele queria mostrar a importância da arquitetura de software, presente em sua empresa. O arquiteto se preocupa com a melhor forma de ser implementado o software. Como será a interação entre as partes.
O livro Software Design Patterns, da gangue dos 4 é adotado como bíblia pelos defensores do OO.
Falamos sobre Macro-Arquitetura e foram mostrados alguns exemplos :
Tubos & Filtros --> É parecido com DFD em que a saída de um estágio e seguido pela entrada de outro estágio em forma de cascata.
Camadas --> O diagrama é visto como diversas camadas de círculos concêntricos. A informação passa pelos círculos adjacentes com as camadas anteriores através de mensagens.
BlackBoard --> É um espaço de memória centralizado. Onde todos os outros módulos interagem armazenando ou retirando informação dessa memória central. Existe a desvantagem do acoplamento forte.
Orientação a Objetos --> Muito conhecido em arquitetura de software e já comentado em aulas passadas.
Começamos a falar sobre a Microsoft especificamente de Bill Gates. Ele fala que é o Arquiteto chefe da Microsoft em vez de dono. Isso porque ele queria mostrar a importância da arquitetura de software, presente em sua empresa. O arquiteto se preocupa com a melhor forma de ser implementado o software. Como será a interação entre as partes.
O livro Software Design Patterns, da gangue dos 4 é adotado como bíblia pelos defensores do OO.
Falamos sobre Macro-Arquitetura e foram mostrados alguns exemplos :
Tubos & Filtros --> É parecido com DFD em que a saída de um estágio e seguido pela entrada de outro estágio em forma de cascata.
Camadas --> O diagrama é visto como diversas camadas de círculos concêntricos. A informação passa pelos círculos adjacentes com as camadas anteriores através de mensagens.
BlackBoard --> É um espaço de memória centralizado. Onde todos os outros módulos interagem armazenando ou retirando informação dessa memória central. Existe a desvantagem do acoplamento forte.
Orientação a Objetos --> Muito conhecido em arquitetura de software e já comentado em aulas passadas.
AULA 14
Assunto da aula: SADT
SADT ==> Structured Analysis Design Technique
O SADT “nasceu pelas mãos” de Douglas T. Ross num projeto de desenvolvimento de uma linguagem estruturada para programação de máquinas-ferramenta, no MIT, no fim da década de 60 (MARCA & MACGOWAN, 1988). Este formalismo trazia algumas características revolucionárias que auxiliaram sobremaneira a descrição e desenvolvimento dos sistemas de software complexos que começavam a aparecer. São elas a decomposição funcional e o fato de serem baseados numa representação esquemática simples (VERNADAT, 1996). Estas características disseminaram a aplicação deste formalismo e também o seu desenvolvimento em direção a abordagens estruturadas completas destinadas a diferentes aplicações, principalmente para a análise de sistemas.
O SADT é baseado num diagrama conhecido como “actigrama”. Este diagrama é composto por “caixas” que representam as atividades. Estas caixas são ligadas por linhas e dispostas tal a formar uma ordem de condução das atividades seguindo da esquerda para a direita. As linhas que chegam e saem na lateral das caixas representam inputs e outputs de informação. As que chegam no topo são controles e embaixo mecanismos. Com mais algumas poucas regras além das aqui apresentadas tem-se todo o formalismo necessário para descrever estes modelos.
Por sua simplicidade e facilidade de uso (existência de ferramentas computacionais para auxílio da modelagem) o SADT é uma das principais ferramenta de modelagem de empresa(VERNADAT, 1996; CANTAMESSA & PAOLUCCI, 1998). Uma ferramenta que traz consigo grandes desvantagens. Segundo VERNADAT(1996) possuem semântica imprecisa, não provê com clareza o comportamento dinâmico do sistema, não manipula fluxos mas dependências entre as atividades, a modelagem de informações é limitada e baixa consistência devida a não integração entre os diferentes modelos. Já CANTAMESSA & PAOLUCCI (1998) aludem principalmente à necessidade de grande cuidado no desenvolvimento do modelo, alta possibilidade de desvios causados e tempo grande para a modelagem devido a necessidade excessiva de revisões para garantir a consistência do modelo.
Assim, VERNADAT(1996) sugere que esta arquitetura seria mais apropriada para modelos pequenos e restritos às visões de maior nível de abstração, portanto, com menor complexidade. Já CANTAMESSA & PAOLUCCI (1998) apresentam propostas de diversos autores para a alteração nesta arquitetura afim de saltar estes obstáculos e propõem um novo caminho complementando o formalismo SADT com com outros modelos.
Os autores desse texto são: Daniel Amaral e Henrique Rozenfeld.
Foi retirado deste link.
Na aula usamos o exemplo de um caixa eletrônico.
Objetivo: Moldar o funcionamento da caixa eletrônico.
Ponto de vista: Consumidores de caixas eletrônicos, estudantes de eng. de software.
É obrigatório ter as setas controle e saída. Senão o modelo está errado.
SADT não precisa necessáriamente de entrada. Por isso ele é melhor que o DFD.
DFD é uma visão de fluxo.
SADT é relacionamento entre partes. Decisões bem mais fundamentadas. Não tem a visão do depósito de dados.
SADT ==> Structured Analysis Design Technique
O SADT “nasceu pelas mãos” de Douglas T. Ross num projeto de desenvolvimento de uma linguagem estruturada para programação de máquinas-ferramenta, no MIT, no fim da década de 60 (MARCA & MACGOWAN, 1988). Este formalismo trazia algumas características revolucionárias que auxiliaram sobremaneira a descrição e desenvolvimento dos sistemas de software complexos que começavam a aparecer. São elas a decomposição funcional e o fato de serem baseados numa representação esquemática simples (VERNADAT, 1996). Estas características disseminaram a aplicação deste formalismo e também o seu desenvolvimento em direção a abordagens estruturadas completas destinadas a diferentes aplicações, principalmente para a análise de sistemas.
O SADT é baseado num diagrama conhecido como “actigrama”. Este diagrama é composto por “caixas” que representam as atividades. Estas caixas são ligadas por linhas e dispostas tal a formar uma ordem de condução das atividades seguindo da esquerda para a direita. As linhas que chegam e saem na lateral das caixas representam inputs e outputs de informação. As que chegam no topo são controles e embaixo mecanismos. Com mais algumas poucas regras além das aqui apresentadas tem-se todo o formalismo necessário para descrever estes modelos.
Por sua simplicidade e facilidade de uso (existência de ferramentas computacionais para auxílio da modelagem) o SADT é uma das principais ferramenta de modelagem de empresa(VERNADAT, 1996; CANTAMESSA & PAOLUCCI, 1998). Uma ferramenta que traz consigo grandes desvantagens. Segundo VERNADAT(1996) possuem semântica imprecisa, não provê com clareza o comportamento dinâmico do sistema, não manipula fluxos mas dependências entre as atividades, a modelagem de informações é limitada e baixa consistência devida a não integração entre os diferentes modelos. Já CANTAMESSA & PAOLUCCI (1998) aludem principalmente à necessidade de grande cuidado no desenvolvimento do modelo, alta possibilidade de desvios causados e tempo grande para a modelagem devido a necessidade excessiva de revisões para garantir a consistência do modelo.
Assim, VERNADAT(1996) sugere que esta arquitetura seria mais apropriada para modelos pequenos e restritos às visões de maior nível de abstração, portanto, com menor complexidade. Já CANTAMESSA & PAOLUCCI (1998) apresentam propostas de diversos autores para a alteração nesta arquitetura afim de saltar estes obstáculos e propõem um novo caminho complementando o formalismo SADT com com outros modelos.
Os autores desse texto são: Daniel Amaral e Henrique Rozenfeld.
Foi retirado deste link.
Na aula usamos o exemplo de um caixa eletrônico.
Objetivo: Moldar o funcionamento da caixa eletrônico.
Ponto de vista: Consumidores de caixas eletrônicos, estudantes de eng. de software.
É obrigatório ter as setas controle e saída. Senão o modelo está errado.
SADT não precisa necessáriamente de entrada. Por isso ele é melhor que o DFD.
DFD é uma visão de fluxo.
SADT é relacionamento entre partes. Decisões bem mais fundamentadas. Não tem a visão do depósito de dados.
AULA 13
Falamos sobre o primeiro trabalho que é sobre um site com login/cadastro. E como devemos usar os cenários e léxicos no trabalho.
Falamos sobre as siglas :
SGBD >> Sistema de Gerenciamento de Banco de Dados.
CRM >> Customer Relationship Management.
ERP >> Enterprise Resource Planning.
O professor falou sobre os painéis da conferência que ele foi. Em específico sobre Rastreabilidade.
Foi comentado sobre a necessidade da comunicação entre a equipe de requisitos e a de testes.
Falamos sobre as siglas :
SGBD >> Sistema de Gerenciamento de Banco de Dados.
CRM >> Customer Relationship Management.
ERP >> Enterprise Resource Planning.
O professor falou sobre os painéis da conferência que ele foi. Em específico sobre Rastreabilidade.
Foi comentado sobre a necessidade da comunicação entre a equipe de requisitos e a de testes.
AULA 12
Nesta aula falamos sobre DFD.
DFD - > Data Flow Diagram
TGS -> Teoria Geral do sistemas , ligada a estrutura de dados( árvore ).
O.O. -> Orientação a objeto, ligada a um grafo.
É muito mais fácil trabalhar com árvore do que com gráfo.
OMG –> controla os padrões da UML.
Diagrama de contexto
Mantra : "Tudo que sai, sai; Tudo que entra, entra. "
Os seus elementos são:
Setas que representam as entradas e saídas.
Círculo que representa o sistema.
Retângulo que representa entidades externas.
O nível zero serve como planejamento básico de como o sistema iterage com o ambiente.
Os níveis seguintes ao zero será mantida toda relação , porem o que se faz agora é demonstrar as relações anteriores com maiores detalhes, identificando cada subsistema. O mantra deve ser obedecido sempre.
Depósito de dados é um local de armazenamento de dados.
Veja mais sobre esse assunto neste link.
DFD - > Data Flow Diagram
TGS -> Teoria Geral do sistemas , ligada a estrutura de dados( árvore ).
O.O. -> Orientação a objeto, ligada a um grafo.
É muito mais fácil trabalhar com árvore do que com gráfo.
OMT –> gerou a primeira versão da UML.
OMG –> controla os padrões da UML.
Diagrama de contexto
Mantra : "Tudo que sai, sai; Tudo que entra, entra. "
Os seus elementos são:
Setas que representam as entradas e saídas.
Círculo que representa o sistema.
Retângulo que representa entidades externas.
O nível zero serve como planejamento básico de como o sistema iterage com o ambiente.
Os níveis seguintes ao zero será mantida toda relação , porem o que se faz agora é demonstrar as relações anteriores com maiores detalhes, identificando cada subsistema. O mantra deve ser obedecido sempre.
Depósito de dados é um local de armazenamento de dados.
Veja mais sobre esse assunto neste link.
AULA 11
Toda aula foi trabalhada em cima de um exemplo. E esse foi um sistema de controle de elevador. Onde foi utilizado diversos diagramas.
Diagrama de classes
Em programação, um diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos.
É uma modelagem muito útil para o sistema, define todas as classes que o sistema necessita possuir e é a base para a construção dos diagramas de comunicação, sequência e estados.
Diagrama de Sequência
Diagrama de Colaboração
Este diagrama irá se concentrar mais no papel dos objetos, mas sem perder a preocupação com a ordem em que as interações entre os objetos irá ocorrer. Os objetos (representados por retângulos) interagem através de mensagens (representadas através de setas) que são identificadas por números. Assim, esses números poderão traduzir a sequência em que as interações entre os diversos objetos modelados irão ocorrer.
Diagrama de Estados
Representa os estados que um objeto pode ter e as ações necessárias para haver mudança de estados, possibililtando a visualização de um ciclo de vida do objeto.
O estado inicial é representado por um círculo preenchido enquanto o final, por um círculo preenchido envolto por outro. Estados intermerdiários são representados por retângulos e as transações de estados, por setas.
Subscribe to:
Posts (Atom)