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).

Aulas 5 & 6

abril 30, 2010

Vou pedir para a Claudia disponibilizar os slides.

Bom que vocês tiveram a oportunidade de escutar da Claudia o trabalho da tese.  Assumo que vocês lerão toda a tese.

Na aula 6, dei uma breve introdução ao framework NFR.  Em notas anteriores do curso mais detalhes podem ser encontrados.  Enfatizei o aspecto da operacionalização.  No fundo é nisso que iremos trabalhar no primeiro trabalho de integrar o SIG de transparência com os processos a serem modelados.

A dissertação da Ana Luisa pode ser encontrada aqui e aqui.

Os elos que vocês precisam para a ferramenta Oryx são os seguintes.

Incluo o elo para o crossoryx também.  Porque isso será utlizado no futuro.

Aulas 3 & 4

abril 5, 2010

Nessas duas aulas procuramos discutir a idéia de transparência segundo dois livros importantes para a fixação do conceito.

Vimos no livro de Holzner e Holzner uma visão mais holística de transparência e sua importância para a criação de um mundo mais aberto a participação de todos.

No livro de Fung et al. vimos a idéia e os exemplos da transparência focada, onde a divulgação da informação leva a que usuários mudem seu comportamento face a novas maneiras de escolher.  O exemplo que ficou mais fácil de entender e ressaltar esse ponto foi o caso dos restaurantes de San Diego.

Volto a lembrar que navegando nesse espaço iremos encontrar uma série de resumos sobre esses livros e os outros dois que não trataremos em particular.

O tema da próxima aula será a primeira parte da tese de Claudia Cappelli (capítulos I, II e II).  Veja a tese aqui.

Aula 2

março 22, 2010

Nessa aula tirei dúvidas sobre o artigo Software Transparency.  Nele cremos que a idéia geral fica clara.  Chamo a atenção de vocês para o papel crucial que o trabalho de Chung e o grupo de Toronto desempenha. Recomendo que, nas notas anteriores, vejam os resumos sobre os artigos que tratam requisitos não-funcionais.  Lembramos que entender Transparência como um requisito não-funcional, e, portanto, uma meta flexível, é um ponto chave.

Para as próximas duas aulas iremos ler os Capítulos 1 e 4 dos livros a) Holzner B., Holzner L., Transparency in Global Change: The Vanguard of the Open Society. University of Pittsburgh Press; 1 edition, 2006. (no dia 24/3 e b)
Fung A. Graham M., Weil D., Full Disclosure, the Perils and Promise of Transparency, Cambridge. University Press, 2007. (no dia 31/3).  Tirei uma cópia dos capítulos e deixei na Biblioteca do Departamento.

Bem-Vindos

março 10, 2010

Essa é a terceira versão do curso de Transparência de Software.  A história dos últimos dois cursos está aqui registrada e você é bem-vindo em pesquisa-la.

Na versão 3.0, estaremos esquematizando o curso em 4 partes distintas, mas que poderá sofrer pequenos ajustes em função de vocês mesmos.

Primeiramente estaremos discutindo a idéia geral de Transparência de Software e a literatura de ciências sociais que foi base para nosso entendimento.  Vou distribuir cópia de recente artigo sobre o tema.

Na segunda parte estaremos lendo a tese de Claudia Cappelli e explorando a idéia de processos transparentes através do uso de uma extensão da ferramenta ORYX.

Na terceira parte estaremos explorando o software Lattesscholar como exemplo de trnasparência.

Na quarta parte estaremos trabalhando em um projeto conjunto ou individual no sentido de operacionalizar os conceitos aprendidos.