Arquivo para setembro 2006

Resumo da aula 10

setembro 19, 2006

UML

A UML (Unified Modeling Language) provê ferramentas de modelagem amplamente usadas no desenvolvimento e documentação de um software. Dentre essas ferramentas podemos citar:

Diagramas de casos de uso:

Componentes principais:

·        Ator – É quem estimula ou é estimulado pelo sistema

·        Caso de uso – É uma ação realizada pelo sistema. Durante a criação do diagrama é utilizado um verbo no infinitivo para descrever esta ação.

Podemos ter como componentes secundários: Limites do sistema, Generalização, Inclusão e Extensão.

Diagrama de classes:

Este é o diagrama responsável por definir as classes e a relação entre elas. Uma classe é definida a partir dos seguintes parâmetros:

·        Nome

·        Atributos

·        Método

·        Superclasse

As relações mais comuns no diagrama são:

Composição – Definida por uma seta aberta e significa a relação “tem-um” entre as classes.

Herança – Definida por uma seta fechada e significa a relação “é-um” entre as classes.

Também podemos encontrar nessa modelagem relações como:

Agregação – Definida por uma linha com um losango em sua ponta e representa a relação de composição múltipla. Ou seja, uma classe possui uma coleção da outra.

Anúncios

Resumo da aula 09

setembro 19, 2006

Orientação a objetos

Paradigma comumente utilizado no desenvolvimento de software na atualidade. Consiste em composição e herança.

Objetos são criados a partir de uma classe existente no projeto. Uma classe é uma entidade que descreve atributos e métodos que podem ser realizadas pelo objeto.

Atributos

Elementos capazes de guardar um estado da natureza do seu tipo. Exemplo: Um boolean é capaz de guardar apenas os valores {true, false}, mas já um int é capaz de guardar valores entre 2-16 até 216. Não esquecendo que um atributo não se limita a tipos primitivos como citados, mas também a outros objetos, desde que sua classe seja conhecida.

Métodos

Estas são as ações que podem ser realizadas por um determinado objeto. Qualquer método não-estático (não me aprofundarei na explicação destes) têm acesso aos atributos da classe, que possuem valores definidos para uma instância da classe, ou seja, para um objeto.

Resumo da aula 08

setembro 19, 2006

Ciclo autor-leitor

Durante a criação de um documento não só importante é a sua escrita, mas também a sua leitura, ou melhor explicado, sua revisão. Esta etapa é tão importante quanto a primeira, tendo em vista que nela que serão encontradas falhas ou pontos de melhora, gerando um produto com melhor qualidade.

Inspeção

Esta técnica que surgiu com SADT (Structure Analysis Design Technique) foi estudada e melhorada por Fagan, um membro da Microsoft. Esta nova técnica consiste em formar uma equipe com os membros:

  • Moderadores
  • Secretários
  • Autores
  • Revisores

E o processo de produção pode ser dividido nas seguintes partes:

  • Preparação – Produção do documento
  • Leitura – Revisão simples baseada na lista de falhas conhecidas devido a inspeções passadas.
  • Reunião – Falhas encontradas na ultima etapa são discutidas com todos os membros e se obtém as falhas a serem consertadas.
  • Revisão – Procedimento de conserto das falhas encontradas 

Paradigmas

Composição

Comumente utilizado na programação modular. Baseia-se no relacionamento “parte-de” dos módulos. 

Orientação a Objetos

Não somente herda as características da composição como adiciona a relação “é-um” entre os módulos agora chamados de objetos. Este paradigma é amplamente utilizado na produção de software nos dias de hoje (desde pequenas a grandes empresas), fato questionável anos atrás por inserir retardo e complexidade na compilação/interpretação. 

Orientação a Aspectos

É o mais novo paradigma ainda em desenvolvimento por pesquisadores. Consiste em adicionar ao paradigma da Orientação a Objetos interesses transversais chamados de Aspectos. Um bom exemplo seria um traço de um programa, que deve estar espalhado por todo o código porem diz respeito a um único interesse. Em POA é escrito apenas um Aspecto para prover esta característica ao software reunindo em apenas um lugar seu código porém ativo em todo o código. Já existem linguagens com suporte a este paradigma, pode-se citar AspectJ para Java e AspectC++ para C++. Apesar de ser uma bela solução do ponto de vista de engenharia de software, na prática ainda é inviável. O processo realizado é utilizar um pré-compilador que insere no código puro as operações referentes ao aspecto. Para o exemplo citado acima é simples tanto a escrita do Aspecto como sua utilização. Porém considere a tentativa de criar um Aspecto para modelar operações de DBC, como assertivas executáveis no código. Ao encontrar uma falha a partir de uma assertiva, não é possível caminhar pelo código utilizando as ferramentas existentes hoje em dia já que o código original foi alterado pelo pré-compilador, tornando este muitas vezes ilegível.É também mais difícil a criação de documentos tendo em vista que não é visível onde um aspecto insere ou não uma operação. Acredito que esta técnica possa ser um novo passo para a computação, porém após a criação de ferramentas de depuração e técnicas de utilização e documentação para tanto.

Resumo da aula 07

setembro 18, 2006

Nesta aula fomos apresentados a um novo tipo de modelagem chamada de Cenários. Esta é uma forma de modelar situações em linguagem natural. Utiliza-se o seguinte formulário para descrever uma situação:

Titulo: Nome da situação
Objetivo: Objetivo da situação
Contexto: Pré-condição, Localização geográfica e temporal
Recursos: Recursos utilizados na situação
Atores: Quem interfere na situação
Episódios: Sentenças que descrevem a situação

Pode haver restrições em todos os itens. E também são esperadas exceções nos episódios.

O processo de criação dos cenários não somente é importante para a documentação do projeto quanto para a reflexão do projetista sobre o problema a ser solucionado. Durante a criação do cenário este se depara com problemas antes de começar a implementação, dos quais alguns são solucionados e outros se tornam exceções.

A partir do conceito de episódios é possível a criação de sub-cenários podendo detalhar melhor cada situação.

Resumo da aula 06

setembro 2, 2006

Esta aula foi sobre codificação. Falamos sobre as opções que temos ao escrever um código. Sempre existem muitas formas de realizar uma determianda operação porem qual é a melhor? Sempre a que torna o código auto-explicativo! O exemplo dado em sala foi uma tomada de decisão entre a forma if/else e um switch. Para o leitor do código é preferivel a forma que utiliza um switch, que mostra claramente que o programa tomará uma decisão a partir de um valor de entrada. Infelizmente nem sempre é possível utilizar essa forma porque em certos casos é necessária uma comparação mais sofisticada, que o switch não oferece. Este exemplo é muito simples. Em um software maior, temos problemas mais complexos como definir se um dado é de transição ou é um atributo. A ideia é sempre transparecer no código a semantica do que está sendo realizado.

Mais uma vez foi citada a frase: “Para ser eficaz o software deve atender aos requisitos”

Enumerar os requisitos deve ser o passo inicial do desenvolvimento de um projeto. Existem as seguintes formas para tanto:

  • Entrevista com o cliente
  • Conhecer a plataforma 
  • Fazer entrevistas, reuniões e questionários
  • Leitura de documentos
  • Observar o ambiente onde o produto será utilizado
  • Engenharia reversa
  • Participação ativa dos clientes interessados

Devo salientar que um processo muito importante durante o desenvolvimento é verificar se o produto desenvolvido está atendendo aos requisitos para que foi projetado.

Resumo da aula 05

setembro 2, 2006

Nesta aula discutimos sobre modelos. Estes nos trazem benefícios para o desenvolvimento de projetos. O principal benefício é a representação do projeto em uma linguiagem comum, mas também podemos citar como benefícios a simplificação, sistematização e organização da solução.

Para modelr é necessária uma linguagem ou um conjunto de linguagens. Um conjunto de linguagens comulmente utilizado é a UML (Unified Modeling Language).

Foram explicados os seguintes modelos:

  • Fluxograma
  • MER – Modelo entidade relacional
  • Caso de Uso
  • Diagrama de classes

Regras de bom desenho:

  • Information Hidding
  • Coesão alta
  • Acoplamento baixo

Foram também estudadas as técnicas Tabela de decisão e Arvore de decisão. Ambas procuram antecipar problemas que possam ocorrer durante a implementação do projeto.

A conclusão da aula foi feito com a introdução do conceito de baseline. Para defini-lo foi necessária uma breve explicação sobre engenharia de requisitos, que consiste na criação do modelo a partir do triangulo do conhecimento já estudado. Logo, baseline é o produto desta técnica, ou seja, o modelo base a ser utilizados para o desenvolvimento do projeto. Durante o desenvolvimento do projeto, ao modificar um requisito, o baseline também será modificado.

Resumo da aula 04

setembro 2, 2006

Nesta aula foram devidamente explicadas as regras 4, 5 e 6 de disciplina:

 Regra 4 – Nomes de variáveis

Foi explicado que ao dar um nome para ua variavel não se deve colocar qualquer sequencia desconexa de caracteres. Deve ser utilizado um padrão que diga qual o tipo desta variavel e o que é esta variavel. Pore exemplo: ulPosicaoBuffer – o prefixo “ul” indica o tipo desta variável como unsigned long e o resto explica quem ela é, neste caso o indice de marcação em um buffer.

A utilização desta regra torna a escrita do documento mais trabalhosa porém é facilmente justificavel pelo perfeito entendimento deste documento por outro integrante do projeto ou mesmo o autor após um longo período de tempo.

 Regra 5 – “Small is Beaultiful”

Esta regra traz ao modelo a singularidade de cada componente. Isso pode ser explicado da seguinte forma: um componente deve ser responsavel por uma única tarefa. Quanto mais restrito foi o campo de atuação de um componente, melhor explicável torna-se o projeto. Em termos de código podemos citar que quanto menor forem os módulos mais depurável torna-se o software.

Regra 6 – Livro diário 

Esta regra traz a importância de persistir o que foi feito durante o período de trabalho no projeto. Em suma, o indivíduo deve escrever neste diário o que ele fez, ideias que teve, soluções que adotou, decisões que tomou e conclusões que obteve.

Este diário pode ser um pequeno livro, uma agenda ou mesmo um blog como este.