Aulas 13 & 14 & 15

julho 22, 2010

Conversando comigo o Henrique expressou uma opinião que creio importante.

Ele disse que ficou uma impressão de que a Transparência de Software é muito abstrata.

Vale a pena comentar sobre isso.

1) O conceito de qualidade é de difícil tratamento sob a ótica formal.  Como nos ensinou Herbet Simon em Ciências do Artificial, tratar do desenho de sistemas artificiais leva a que aspectos a uma necessidade de flexibilidade menos mecanicistas. Ele expressou isso cunhando um termo que mostra que muitas vezes soluções ótimas em todos os sentidos são menos desejáveis do que solução aceitáveis. Então usou o termo “satisfice” querendo referir-se a soluções aceitáveis e para diferenciar de soluções que satisfazem os critérios estabelecidos.  Portanto,  a importância de tratarmos a qualidade de transparência usando os conceitos da área de requisitos não-funcionais.  Ao usar essa sistematização passamos a explicitar a semântica que leva  a que fique claro como um característica de qualidade pode ser implantada (através da operacionalização).

2) Lidamos com operacionalização no nível concreto ao modificarmos os processos de negócio.  Os processos de negócio podem ser visto de forma análoga a um software, principalmente sob o aspecto da estrutura de controle seqüencial.  Fluxos de trabalho são concretos na medida em que podem retratar algo que ocorre na realidade (daí o uso de concreto).  Ou seja, para tornar o processo com uma característica que “help” transparência foi necessário adicionar algo na sua descrição (operacionalização).

3) Chegamos até a indicar o código do software LattesScholar, que funciona, mas que no momento tem um pequeno problema de configuração.  De maneira semelhante ao que foi feito nos processos, a idéia era identificar e operacionalizar o software com a ótica de transparência.

4) No entanto, como é uma área que estamos a definir, muitos pontos ficam ainda pouco claros ou “abstratos”.  Além disso como me referi acima, as ferramentas (software ) de trabalho ainda estão em evolução. Um dos pontos que é pouco claro é novamente sobre a transparência da informação ou transparência do processo sob a ótica de quem a usa. Podemos falar de software transparente, quando estamos na verdade querendo saber se o serviço prestado pelo software é transparente (nesse caso queremos que as informações sobre o serviço sejam transparentes) isso gera confusão.  Lembrem da   úlima figura o artigo de Transparência de Software.  O primeiro que lemos.

As aulas foram ministradas e planejadas como um grupo de estudo que continuaria.  A continuação poderá se dar de várias maneiras, dependendo dos tópicos que elegerem para a continuação do trabalho.

O entendimento do que é Transparência de Software é pouco trivial.  A tarefa de mapear a ontologia de Transparência é árdua e extremamente  trabalhosa.  Bom que vocês poderam contribuir.  Os passos seguintes envolvem conhecimentos diferenciados: sob a ótica de organização envolve principalmente ontologias e reutilização de software e sob a ótica de operação envolve desde trabalhos de programação (operacionalização) a trabalhos que lidam com o conceito de variabiliade de software, construção de arquiteturas e requisitos intencional entre outros.  As oportunidades de trabalhos de ponta são inúmeras.

Passei por correio eletrônico um conjunto de literatura: 1) a dissertação da UFPE que propõe um catálogo de Usabilidade usando o framework NFR, 2) Um artigo que propõe o reuso de qualidade, 3) Um artigo que será apresentado na RE 10, a mais importante conferência de Engenharia de Requistos, onde se propõe uma maneira de organizar catálogos NFR (portanto algo que poderia ser usada em Transparência).

Além disso vale a pena dar uma olhada em dissertações já defendidas no grupo bem como artigos recentemente publicados.

Dúvidas sobre o relatório final, e só falar.

Anúncios

Aulas 10 & 11 &12

julho 22, 2010

Nessas aulas exploramos a estratégia de modularização orientada a aspectos como uma operacionalização importante para as caractéristicas de usabilidade e entendimento, em particular.

Veja que o aspecto de modularização é principalmente importante quanto falamos da transparência da informação, e o caso particular dessa representação estar detalhando o processo.

Vale lembrar o artigo de Osterweil Software processes are software too.

Portanto ao tornarmos o processo mais transparente com a inclusão de operacionalizações estamos no fundo contribuindo negativamente (“hurt” do NFR) para a transparência da informação sobre o processo.

A tese da Claudia propõe uma estratégia que minimiza essa problema.  Ela parte da idéia de que a modularização de informação sobre processos transparentes pode ser beneficiada com o uso da idéia de aspectos.  Portanto empregar a estratégia de aspectos é uma operacionalização do conceito de entendimento quando da transparência da informação.

O conceito de aspectos surgiu em função de problemas que programadores de orientação a objetos enfrentam.  A programação orientada a objetos prega o pensamento taxonômico pensando que coisas estão organizadas segundo famílias cujos os membros herdam características de seus antepassados.  Essa idéia de herança facilita o tratamento da redundância, porque concentra características nas descrições dos antepassados.  Na linguagem de orientação a objetos estamos falando de classes que concentram características de seus antepassados.   Essa estratégia é desejada justamente porque economiza repetições e organiza a memória.

No entanto, a medida que sistemas de software ficam complexos, várias famílias (classes) passam a pertencer (mereologicamente) a um conjunto que tem objetivos comuns (sistema).  Quando isso ocorre, operações que são necessárias em uma família passam também a ser necessária a outras famílias.  Usamos em aula o exemplo das famílias de móveis, veículos e calçados.  Cada uma dessa famílias tem suas características comuns fatoradas na classe, mas se por exemplo estivermos pensando na característica lustrar (uma característica funcional) esta estará presente em todas as três famílias.  Essa repetição torna a descrição do sistema mais complexa.

A idéia de aspectos é uma idéia de fatoração onde a característica fatorada sabe onde deve ser aplicada.  Portanto a fatoração clássica em software, implementada por uma referência de chamada (instruções do tipo “call” ou “função”) são substituídas por estruturas que encapsulam as características fatoradas e que sabem onde devem ser aplicadas.

Com isso é desnecessário explicitar em classes as características comuns a várias classes, porque essas serão tratadas a parte e elas próprias saberão onde serão utilizadas.

Essa inversão de responsabilidade da fatoração é um grande ganho para que as representações fiquem mais simples e mais abstratas, mas recaem em um problema que é como as características comuns sabem onde serão úteis?

Aulas 7 & 8 & 9

julho 22, 2010

Partimos de dois processos.  Um processo que mapeia o ingresso na pós-graduação e outro que reporta procedimentos na vice-reitoria.

Um dos problemas enfrentados foi o foco da transparência.  Estamos buscando que a descrição (modelo)  fique mais transparente ou estamos buscando que o processo como um todo fique mais transparente?

Explicamos a diferença usando os conceitos de eficácia e eficiência.  A eficácia é relativa ao alcance de objetivos e a eficiência é relacionada ao consumo de recursos, a produtividade.

Com base nisso postulamos:

1) A correta inclusão da transparência preserva a eficácia do processo (preserva a semântica funcional).

2) A inclusão da transparência não muda o processo, derivado de 1)

3) A correta inclusão da transparência modifica a eficiência do processo (preserva a semântica funcional).

4) A correta inclusão de transparência modifica o modelo que representa o processo, tornando explícito conhecimentos tácitos.

Vale frisar que a transparência do modelo que representa o processo, passa claro a ter importância, porque torna-se o espelho do processo.

A operacionalização da transparência (através do catálogo (tipo [processo de negócio])) gera um processo mais detalhado sob o ponto de vista da descrição.  Essa descrição é mais complexa porque tem aumentado o seu volume de descrição.

Aqui reside  um problema de conflito do tipo de  transparência.  Ou seja: a transparência do  processo leva a que o processo seja modificado tornando-o mais transparente, o que pode acarretar que sua representação (modelo) seja mais complexa, o que, sob o ponto de vista da  transparência da informação, torne a informação menos transparente.

A aplicação do catálogo é portanto difícil, porque não só contribuições de diferentes tendências podem conflitar, mas porque o tratar de processo e informação podem também gerar conflitos em outro nível.

Procurem lembrar dos exemplos que discutimos em sala (com base na retro-alimentação que forneci sob o trabalho).