SOA: Nome novo para a velha teoria – parte 2

No último texto apresentei uma das raízes teóricas que originaram a orientação a objetos, recebi vários comentários e algumas questões, uma delas me chamou a atenção:

“Se eu partir do pressuposto apresentado no texto, posso concluir que SOA (arquitetura orientada a serviços) também é um nome novo para a velha teoria?”

O objetivo da arquitetura orientada a serviços é propor soluções para automatizar os processos de negócios. Aplicações que permitam aprimorar/dinamizar as tarefas manuais de uma organização são considerados elementos importantes em uma arquitetura orientada a serviços. A referida arquitetura possibilita aos usuários finais percepções e informações mais detalhadas e precisas de um processo de negócio. O acesso aos diversos níveis de informações (operacional, tático e estratégico) deve ser feito através da WEB ou por meio de um dispositivo móvel.  Pode-se dizer que SOA é fundamentada em 5 pilares:

• Pessoa,
• Processo,
• Informação,
• Conectividade,
• Reuso de sistemas legados.

SOA possibilita o desenvolvimento de aplicações customizadas para o seu negócio, as facilidades para responder as demandas do mercado em uma economia globalizada é um benefício a ser considerado neste tipo de arquitetura.

É importante salientar que a implementação de uma estratégia consistente de componentização durante o processo de produção de software é uma das prerrogativas que delinearão o sucesso ou fracasso de uma estratégia SOA. O levantamento dos requisitos, a modelagem do processo de negócio, o desenho da arquitetura e o design das funcionalidades devem possuir grande consistência e, por fim, a reutilização de controle dos serviços já existente também faz parte das diretrizes que compõem uma arquitetura orientada a serviços.

Não quero jogar água no café de ninguém, mas ao analisar a definição apresentada concluo que:

Os analistas de sistemas trabalham com a modelagem de processos, organizam informações, estabelecem formas de conectar estações de trabalho e procuram reutilizar os sistemas já existentes a mais de 30 anos. Veja um velho e bom diagrama de fluxo de dados que você dará conta disto.  

Enfim, a evolução tecnológica é eminente e deve ser considerada (surgimento da WEB e dos dispositivos movéis), porém a quebra de um paradigma teórico não ocorre todo dia. Projetar uma aplicação orientada a serviços é sinônimo do desenvolvimento orientado a processo. Nome novo para a velha teoria.

Abraços

J. A. Fabri

fabri@femanet.com.br

Nome novo para a velha teoria – parte 1

Na semana passada lá estava eu apresentando a idéia de mapas mentais para uma turma de último ano. Durante a aula um aluno me questionou:

“Poxa professor… tu falas de uma teoria proposta em 1942, não existe nada mais atual para apresentar na aula?”

Por favor, me dê um exemplo!

“Posso enumerar vários artefatos que são mais novos que os mapas mentais, programação orientação a objetos (POO) e diagrama de classes são bons exemplos.”

Muito bem, quando surgiu tal forma de programar e tal diagrama?

Final da década de 1990, correto?

Não.

A programação orientada a objetos surgiu na década 1970 com a linguagem SIMULA, esta, por sua vez, era parte integrante da linguagem Smalltalk, desenvolvida pela Xerox PARC. Os conceitos sobre POO levaram mais de 10 anos para amadurecerem, por isso muitos dizem que a programação orientada a objetos é algo relativamente novo.

Já, segundo a minha singular visão, o diagrama de classes é uma adaptação do conceito de Frame popularizado por Marvin Minsky em 1975. Marvin propôs a aplicação do referido conceito na representação de conhecimento (veja a figura no início do post).

Na figura é possível encontrar dois frames, cada um representa um objeto do mundo real, algo bem parecido com o que conhecemos hoje como diagrama de classes.

Concluindo.

Ao trabalhar com POO e diagrama de classes lembre-se, estamos utilizando conceitos da década de 1970.

Deixo uma pequena provocação para os interlocutores deste blog:

É possível relacionar o conceito de mapa mental com frame? Será que a origem das classes não contempla as prerrogativas delineadas por Tony Buzan 1942?

Enfim, tudo nome novo para a velha teoria.

Abraços

J. A. Fabri

fabri@femanet.com.br

O que é software?

Se consultarmos a literatura, obteremos a seguinte definição:

Segundo Sommerville, software é caracterizado como um programa de computador e toda a documentação associada a ele. Já Pressman define software como um elemento de sistema lógico, e não físico que não se desgasta.

De posse destas duas definições questiono: O desenvolvimento de parte de um processador pode ter características de software em algum momento de seu ciclo de vida?

Antes de emitirmos qualquer resposta gostaria que todos analisassem o seguinte exemplo:

Os engenheiros da Intel estão trabalhando, ativamente, na implementação de um conjunto de circuitos integrados de um novo processador, estes circuitos devem ser conectados seguindo uma sistematização lógica, estabelecida em um projeto arquitetônico. Posteriormente, os projetistas de mascaras entram em ação e, por fim a fabricação do processador é concebida na sala limpa, aquela velha história que todos nós conhecemos – veja o filme abaixo.

De posse do exemplo podemos concluir que uma grande parte da fabricação de um processador possui as características do desenvolvimento de software. O filme deixa isso claro – É necessário definir os requisitos do processador, desenvolver o documento arquitetônico, implementar os circuitos e as mascaras, simular a implementação e, posteriormente, materilizar o ”projeto programado do processador” sobre o silício (é somente neste ponto que o hardware é concebido).

Para sustentar minha posição, parto das definições propostas por Stallings (2002, pg. 341) e Ercegovac et. al. (2000)

“O conjunto de instruções da máquina constitui o limite que o projetista e o programador de computadores enxergam uma mesma máquina. Do ponto de vista do projetista, o conjunto de instruções de máquina fornece os requisitos funcionais para CPU: implementar CPU é uma tarefa que envolve, em grande parte, implementar o conjunto de instruções de máquina”.

Implementar instruções de máquina é construir software.

O estudo ou implementação de qualquer sistema digital envolve sua especificação e implementação. A especificação de um sistema refere-se a uma descrição de sua função e de outras características, necessárias para seu uso, como por exemplo: A velocidade e tecnologia a ser utilizada – Ercegovac et. al. (2000).

Especificação de documento e implementação  são características intrínsecas de software.

Enfim, ao analisar o exemplo que tem como personagem principal os engenheiros da Intel e as definições extraídas de Stallings e Ercegovac é possível concluir que a fronteira entre software e hardware é extremamente tênue. Aquilo que encaramos como hardware hoje, um dia teve algumas características de um projeto de software. Ressalto, nosso processador se configurou como hardware após ser materializado fisicamente. Antes disso ele teve que ser, no mínimo, documentado e implementado.

Será que apresentamos essa visão aos nossos alunos nos cursos de engenharia de software?

José Augusto Fabri

Fontes de consulta:

Ercegovac M. et. al. “Introdução aos Sistemas Digitais”, Porto Alegre. Bookman. 2000.

PRESSMAN, R. S. Engenharia de Software. Rio de Janeiro: McGraw-Hill, 2002.

SOMMERVILLE I. Engenharia de Software. 6ª Edição. Addison Wesley, 2003.

Stallings W. Arquitetura e Organização de Computadores. São Paulo. Prentice Hall. 2002.

Ensinamos corretamente a engenharia de software?

A questão acima foi delineada por um interlocutor deste blog que trabalha em uma empresa do setor produtivo de software. Dentro da referida empresa ele é responsável por recrutar programadores e testadores.

Bem, confesso que não respondi a questão no momento que ela foi elaborada. Aproveito a oportunidade para afirmar que tenho várias dúvidas sobre organização curricular das disciplinas da área de engenharia de software. A questão que intitula este post me levou a delinear algumas reflexões.

A ordem que as disciplinas são apresentadas está correta?

A grande maioria dos cursos de computação e informática apresenta, em um primeiro momento, aos seus alunos as disciplinas introdutórias da área de programação. Posteriormente são tratados os conteúdos referentes às estruturas de dados. Aspectos relacionados ao levantamento de requisitos, e modelagem sistêmica ocupam terceiro lugar nesta ordem. As informações inerentes ao projeto de software são configuradas como o quarto item. Saliento que alguns cursos possuem algumas disciplinas que apóiam o desenvolvimento do projeto, geralmente estas apresentam IDEs e linguagens de programação aos alunos, possibilitando-lhes a própria “materialização” do software. Os aspectos ligados a teste de software, em quase 100% dos cursos, são tocados (quando são) de forma superficial.

Será que não seria mais interessante organizar o currículo da área de engenharia de software a partir da seguinte equação?

Engenharia de Software = {analise de sistemas + [projeto de software + (programação + teste) + implantação+manutenção]} + processo e gestão de projetos de software

Na equação, primeiramente, resolvemos os parênteses, ou seja, as disciplinas de lógica, algoritmo e estrutura de dados seriam apresentadas nos semestres iniciais. Posteriormente proponho que os aspectos formais ligados a testes sejam discutidos na disciplina de Engenharia de Software I. Em Engenharia de Software II seriam apresentados os conceitos relacionados a projeto de software. O corpo de conhecimento ligado a implantação e manutenção do software seriam apresentados, concomitantemente, à disciplina de Engenharia de Software II. Por fim aspectos ligados a análise de sistemas, fator que requer um maior nível de abstração, seria visto no final, em Engenharia de Software III.

Ao ensinar algoritmo devemos apresentar uma linguagem de programação?

Trabalho com a disciplina de Algoritmos e Estrutura de Dados I, meu plano de ensino contempla o ensino da linguagem C (nota: nesta disciplina existem outros professores, não tenho pleno poder de decisão sobre o plano). É interessante ensinar C? Será que um compilador portugol não seria menos indigesto para os alunos? Como minimizar o número de reprovações nestas disciplinas? Fiz algumas experiências e materializei-as neste post.

Em que momento do curso devemos apresentar os conceitos ligados a orientação a objetos?

Alguns currículos apresentam a OO logo nas séries iniciais, outros inserem tais conceitos na metade. Qual é o melhor momento para apresentar estes conceitos? Sinceramente, não tenho uma posição definida sobre este assunto.

Qualidade de software é um tema importante?

Será que nosso aluno conhece os conceitos ligados a qualidade de software? Todos sabem o que é um processo produção de software? Aspectos ligados a qualidade do processo e do produto são delineados nos cursos de computação? Na maioria dos cursos, tenho a impressão que estes conteúdos são comentados superficialmente junto aos alunos.

A gestão de projetos é um conteúdo que deve ser ministrado por um professor da área de engenharia de software ou da área de administração?

Aspectos ligados a tempo e esforço para o desenvolvimento de um projeto deve ser apresentados aos alunos. Tenho certeza os conteúdos ligados a gestão de projetos são de extrema importância. Em alguns currículos, vejo que tais conteúdos estão ligados as disciplinas da à administração. Não seria interessante que um professor da área de engenharia internalizasse esse conteúdo junto aos alunos.

Acredito que a maior parte das reflexões delineadas é compartilhada por toda comunidade. A discussão está aberta, espero que todos a fomente.

J. A.

fabri@femanet.com.br

Resposta a questão: Será que o Sistema Bancário Financeiro pode ser colocado em cheque?

 

Pessoal, o post Será que a qualidade do sistema bancário pode ser colocada em cheque? Gerou alguns comentários pertinentes e interessantes.

Tentarei responder, rapidamente, a questão apresentada no título do post… Lembrando está é a minha visão sobre o assunto… Fique a vontade para contrapô-la…

A resposta para a questão é Sim. Aceito a hipótese que temos uma falha sistêmica e não uma falha de software.  Para justificar minha afirmação, vamos partir das seguintes proposições:

Se o banco não registrar os boletos é possível burlar sempre a seqüência numérica.

Proposição caracterizada como verdadeira.  Posso adiantar a data Juliana em alguns dias e buscar um dígito que a valide, neste sentindo também posso alterar o valor do pagamento. A consistência ligada à alteração de números só irá funcionar caso exista um elemento de comparação, em nosso caso a seqüência exata do boleto, fator esse que não ocorre, pois o boleto não é registrado.

O processo para registro do boleto não é trivial.

Proposição caracterizada como verdadeira. Vamos partir do seguinte cenário. Eu J. A. possuo uma empresa A, presto um serviço X e possuo uma conta corrente no banco H. Cobro meus clientes com boleto bancário. Para cada boleto emitido, devo enviar a sua seqüência numérica para o banco H. H armazena as seqüências em seu depósito de dados (o registro do boleto). Neste caso devo possuir uma comunicação rápida, estável e segura com o banco em questão. Outrora, lembre-se que meus clientes – hipoteticamente – podem pagar o boleto em qualquer agência bancária (isto inclui o internet home banking) “dentro do vencimento”.  Ao tentar realizar o pagamento, no banco K, fora do vencimento com a seqüência supostamente alterada, o número digitado deve ser enviado para o banco H (lembre-se H registrou os boletos emitidos por A). Neste momento o elemento de comparação é estabelecido.  Para que isto ocorra todos os bancos devem estar interligados, fato este que já ocorre com o sistema de compensação de cheques. Isso não é trivial e custa caro para a empresa cedente.

Os empresários organizam os seus processos para evitar a “possível” falha.

Proposição caracterizada como falsa. No post que coloca em cheque tal sistema, os empresários não sabem desta falha.  Vamos contrapor o argumento. Se os empresários fossem comunicados, com certeza um processo de conciliação de boleto seria organizado em suas empresas. Alguma entidade iria verificar se a seqüência do boleto digitada pelo seu cliente está condizente com o boleto que foi emitido. Neste caso o problema seria resolvido, pois o elemento de comparação seria institucionalizado na empresa cedente.

A aceitação das duas primeiras proposições e negação da terceira me leva a crer que o sistema bancário financeiro pode ser colocado cheque, na questão do pagamento de boletos. Ou o sistema opta por registrar o boleto, cenário apresentado na segunda proposição, ou banco comunica as empresas cedentes da possível falha.

Alguém deve assumir a responsabilidade dentro deste contexto. Este blog apenas apresentou o problema.

Em tempo, tentarei responder as demais questões do referido post em um momento oportuno.

J.A.

fabri@femanet.com.br

JEDI: Java Education and Development Initiative

O JEDI é uma iniciativa para desenvolvimento e educação JAVA a distância. Manuais, slides de apresentação das aulas, provas, exercícios,  material de referência e vídeo-aulas estão disponíveis para download. Para os iniciantes é uma boa pedida.

Link para acesso:

Abraços

J. A

Como deve ser configurado o trabalho de conclusão em um curso superior de tecnologia?

 

A questão apresentada no título surgiu durante o processo de autorização de um curso superior de tecnologia (CST) de sistemas para internet.

Antes de ler minhas reflexões sobre o assunto, recomendo a leitura do catalogo nacional de cursos de tecnologia/  disponibilizado pelo Ministério de Educação e Cultura/.

É importante salientar que o trabalho de conclusão (TCC) em cursos desta natureza não é obrigatório. Eu, particularmente, acredito que deveria existir uma obrigatoriedade neste sentido, pois o TCC neste contexto, quando bem aplicado, poderia embutir uma maior qualidade na formação dos tecnólogos.

O TCC em um CST deve possuir um caráter prático. A partir desta premissa, a IES ao organizar o trabalho de conclusão de curso deve:

Configurar um banco de empresas que atuam na área tecnológica do curso proposto.

Com este objeto a IES responde uma das principais questões dos formandos: Ao terminar o curso, quais as empresas que me contratarão? A configuração deste banco, também, provê uma aproximação entre empresa e IES, o estabelecimento de parcerias, o que é interessante para ambos os lados.

O TCC deve ser encarado como uma disciplina que complementa às 2000 horas previstas para esta categoria de curso.

O professor da disciplina em questão será responsável pela organização da logística de todo o trabalho de conclusão. Ele deve materializar, com o apoio da IES, o banco de empresas; mediar à relação entre alunos e orientadores; estabelecer o calendário para o desenvolvimento do trabalho; ser um elo entre IES e empresa. A carga de trabalho deste professor é bastante intensa, minha sugestão que ele possua um bom número de horas (por semana) para realização destas atribuições.

O aluno deve possuir dois orientadores, um da IES e outro da empresa.

O orientador na empresa terá um contato diário com o aluno. Poderá direcioná-lo nas questões técnicas relacionadas ao mercado produtivo de software e, principalmente, poderá reportar a IES o desempenho do aluno. O orientador da IES irá prover subsídios metodológicos quanto à organização do TCC.  Dúvidas relacionadas aos problemas eminentes do mercado também devem ser sanadas por ele. Este último, também, é responsável por avaliar o aluno no desempenho de suas atividades. Seria interessante que ambos os orientadores trocassem informações sobre o desenvolvimento do trabalho.

Carga horária e as atribuições do formando na empresa

O tempo de permanência do aluno na empresa, para a configuração do trabalho, deve variar entre 200 e 400 horas. Vamos partir do exemplo que o aluno esteja matriculado em um curso superior de tecnologia de análise e desenvolvimento de sistemas. Neste caso o formando deve ter contato, no mínimo, com as atividades que permeiam um processo de produção de software. Se a empresa é uma subcontratada em um contexto de outsourcing o formando irá desempenhar as funções de programador e testador. Se a empresa aplicar todo o ciclo de produção, o formando deve ter contato com aspectos relacionados à modelagem, projeto, implementação e teste de software. É importante que o formando se especialize durante o desenvolvimento do TCC em uma ou duas atividades do processo.

Produto gerando com o desenvolvimento do TCC

Vários professores ligam o termo TCC à palavra monografia. Neste caso esta premissa não é, totalmente, verdadeira. Em nosso contexto, o TCC deve gerar artefatos pertinentes ao processo de produção de software.

Se o curso é de análise e desenvolvimento de sistemas, o aluno deve apresentar a banca examinadora, o modelo sistêmico, o projeto do software, a implementação e um relatório de testes.

Se o curso é de banco de dados, o aluno deve apresentar a estrutura do banco implementada, as normalizações e as SQL’s desenvolvidas.

Se o curso é de desenvolvimento de jogos, o aluno deve apresentar um jogo implementado. Projeto de interface, os aspectos de inteligência artificial aplicados ao jogo e o projeto do software em si, podem complementar a apresentação.

O nível de detalhamento de cada artefato vai depender do tempo de contato com cada atividade do processo.

Seria interessante que o futuro tecnólogo desenvolvesse um manual de utilização do jogo, do banco ou do software. Com isto aspectos ligados a comunicação e expressão fariam parte do escopo do TCC.

Composição da banca de avaliação

Fazem parte da banca de avaliação os professores orientadores e um terceiro professor da IES. A banca irá analisar os artefatos apresentados e argüir o formando.

Enfim, volto a salientar que a disciplina TCC em um CST não é obrigatória. Neste texto apresentei alguns pontos que poderiam ser implementados, caso a IES opte por oferecer a referida disciplina.  São sugestões e uma visão particular sobre o assunto. Cabe a sociedade balizar a pertinência ou não das palavras transcritas neste post. A discussão está aberta…

José Augusto Fabri

Ferramentas que auxiliam o ensino de algoritmos

 

Em 15 de abril de 2008 postei um relato sobre como motivar o aluno nas disciplinas introdutórias da área de programação. O relato trata, basicamente, da utilização da linguagem Logo e o desenvolvimento de jogos na Faculdade de Tecnologia de Ourinhos (FATEC-OU) (http://engenhariasoftware.wordpress.com/2008/04/15/como-motivar-o-aluno-nas-disciplinas-introdutorias-da-area-de-programacao/). De lá para cá, vários colegas compartilharam as suas experiências e ferramentas aplicadas no ensino de algoritmos e estruturas de dados. Em virtude deste fato, tomei a liberdade de relatar neste texto aquelas que achei mais interessante (nota: algumas destas informações foram capturadas na lista sbc-l e na alg-prog-l).

 

·          Webportugol (http://www.univali.br/webportugol): Criado pela Universidade do Vale do Itajaí, essa ferramenta, como o próprio nome sugere, permite construir online programas em português estruturado ou portugol. 

 

·          Visualg (http://www.apoioinformatica.inf.br/download.htm): Criado pela “Apoio Informática Ltda – Consultoria e Desenvolvimento de Sistemas”, o Visualg é um “programa para edição e interpretação de algoritmos” em português estruturado ou portugol. Possui boa documentação. Informação disponibilizada por Loiane Groner.

 

·          AMBAP – Ambiente de Aprendizado de Programação (http://www.ufal.br/tci/ambap/): Usa também o português estruturado ou portugol, como os dois anteriores. Foi desenvolvido pela Universidade Federal de Alagoas. Informação disponibilizada por Loiane Groner.

 

·          ASA – Ambiente de Simulação e Animação de Algoritmos (http://mybloop.com/go/rEJV0D): O ASA, também conhecido como Construtor, é um software para criar algoritmos usando fluxogramas. Desenvolvido pela equipe do SENAC, é distribuído gratuitamente junto com o livro “Lógica de Programação”, disponibilizado pelo própria Editora SENAC no Google Books. Informação disponibilizada por Loiane Groner.

 

·          G-Portugol é uma linguagem de programação estruturada, totalmente em português, derivada do que é conhecido hoje como “portugol” (uma notação muito utilizada para descrever algoritmos em português de forma livre e espontânea). Este projeto envolve o desenvolvimento da linguagem e de ferramentas relacionadas, todas disponíveis sob uma licença livre (a GPL). Informação disponibilizada por Thiago Silva.

 

·          Portugol 2.1: desenvolvido na Universidade de Tomar, ele gera o fluxograma automático, baseado no portgugol ou vice-versa (http://orion.ipt.pt/~manso/Portugol/). Informação disponibilizada por Mariangela Gomes Setti.

 

·          Projeto Alice: Ambiente de programação 3D que possibilita a criação de jogos e de animações para contar histórias http://www.alice.org/). Informação disponibilizada por Ely.

 

·          Processing: Linguagem de programação open source voltadas para pessoas que querem desenvolver animações interativas (http://processing.org/). Informação disponibilizada por Tânia.

 

·          Scratch é uma nova linguagem de programação torna fácil para você criar suas próprias histórias interativas, animações, jogos, música e arte e também compartilhar suas criações na Internet (http://scratch.mit.edu/about). Informação disponibilizada por Henrique Monteiro Cristóvão.

 

·          Jeliot – Ambiente utilizado no ensino de orientação a objetos com Java (http://cs.joensuu.fi/jeliot/index.php): O Jeliot é caracterizado como uma aplicação que possibilita visualizar como os programa em Java são interpretados. A aplicação foi criada pelo Weizmann Institute of Science – Finlândia.

 

·          Robocode é um programa pequeno desenvolvido em Java para usuários que querem aprender um pouco desta linguagem brincando. Trata-se de uma arena de combate onde blindados de guerra se enfrentam até que reste apenas um sobrevivente — ou um time. O detalhe está no controle deles: ao invés de você os manipular com teclado e mouse, você deve programá-los para combater por conta. É bem divertido e algumas pessoas que eu conheço começaram a aprender java por esse programinha (http://robocode.sourceforge.net/). Informação disponibilizada por Loiane Groner.

 

·          BlueJ: Ambiente Integrado JAVA desenvolvido para introduzir o conceito de orientação a objetos junto aos alunos (http://www.bluej.org/). Informação disponibilizada na lista sbc-l.

 

 

Todos nós sabemos que ensino de algoritmo e estrutura de dados requer uma atenção especial por parte dos professores. Existem muitos pesquisadores preocupados com este aspecto. É importante que todos tenham em mente que para se obter sucesso na área de engenharia de software em contexto nacional é necessário formamos, no mínimo, bons programadores.  Uma boa fonte de informação sobre este assunto é a lista alg-prog-l mantida pela Sociedade Brasileira de Computação (www.sbc.org.br).

 

Enfim, se você têm uma experiência nesta área, por favor, compartilhe conosco.

 

José Augusto Fabri

Fundação Educacional do Município de Assis

Faculdade de Tecnologia de Ourinhos

 

 

 

o SOFTWARE pode ser chamado de SISTEMA?

Vários profissionais que atuam no mercado utilizam a palavra SISTEMA para denominar um produto caracterizado como SOFTWARE, desta forma,  a palavra SISTEMA  pode ser utilizada como sinônimo de SOFTWARE? Todo SOFTWARE pode ser classificado como SISTEMA?

Segundo Sommerville, Pressman, Paula Filho e Pedrycz, o termo SOFTWARE é definido como um programa de computador, uma seqüência lógica de instruções a serem seguidas e/ou executadas, na manipulação de um determinado conjunto de informações. SOFTWARE, também, pode ser classificado como um conjunto de produtos desenvolvidos durante o processo de software, por exemplo: programa de computador, manuais, especificações e planos de teste.

Já Ludwig von Bertalanffy define SISTEMA como um conjunto de elementos que se conectam, harmonicamente, com o objetivo de formar um todo unificado (é importante afirmar que isso acontece com o SOFTWARE, somente quando o mesmo é dividido em partes). Em grego (primeira língua a utilizar a palavra em questão), SISTEMA significa combinar, ajustar e formar um conjunto. A partir da obra de Bertalanffy, é possível inferir alguns conceitos primários da teoria de SISTEMA:

1.     Todo SISTEMA está ligado à totalidade de um corpo de conhecimento ou a uma teoria específica (conceito aderente a idéia de SOFTWARE).

2.    Um SISTEMA pode sofrer constante mecanização ou automação agilizando, assim, a execução de seus processos (nesse caso o SOFTWARE passa a ser caracterizado apenas como uma ferramenta e não como um SISTEMA).

3.    Um SISTEMA só é criado quando surge uma nova teoria (conceito pouco aderente a idéia de SOFTWARE).

Com base nos relatos de Bertalanffy e nas definições de propostas por Sommerville, Pressman, Paula Filho e Pedrycz, acredito que SOFTWARE não deva ser denominado como SISTEMA, tal afirmação está alicerçada nos três conceitos destacados anteriormente.

Não podemos classificar como SISTEMA um SOFTWARE que controla a parte acadêmica de uma universidade ou de uma escola. O SISTEMA de controle acadêmico foi modelado  com o surgimento da própria universidade (datada do século XII) ou da própria escola. Foi com a criação da “teoria sistêmica universitária” que os processos de controle de freqüência, de matrícula e de controle de notas foram criados. O SISTEMA bancário pode ser considerado outro exemplo: o SOFTWARE ou um conjunto de SOFTWARES apenas automatizam o processo dentro desse SISTEMA (no Brasil tal SISTEMA surgiu em 12 de outubro de 1808). Não desenvolvemos o SISTEMA para controle bancário, mas um SOFTWARE para controle bancário.

Um dos poucos SOFTWARES que podem ser chamado de SISTEMA, é o SISTEMA operacional computacional, o qual surgiu com o advento do computador (uma nova teoria ou uma nova invenção).

Na maioria das situações, cometemos um grande erro ao denominar SOFTWARE como SISTEMA. Não é trivial criar um SISTEMA, podemos modelá-lo. SISTEMA está ligado a alguma coisa nova, a uma nova teoria, a uma invenção, a um novo paradigma.

É fundamental destacar que essa é a minha posição sobre o assunto. E a sua?

Prof. José Augusto Fabri

Fontes de Consulta:

BERTALANFFY, Ludwig von. Teoria Geral dos Sistemas. Tradução de Francisco M. Guimarães. 2ª. Edição. Petrópolis, Vozes. 1975.

Como motivar o aluno nas disciplinas introdutórias da área de programação?

Vários cursos, das mais variadas áreas do conhecimento, possuem em sua estrutura curricular a disciplina de lógica de programação, na qual esta trabalha, basicamente, com o ensino de algoritmos e linguagens de programação. Na maioria das universidades, centros universitários e faculdades isoladas o ensino, direcionado pela disciplina em questão, está focado predominantemente no paradigma estruturado aliado a utilização de linguagens procedurais como C e Pascal. Um fato chama a atenção nestas disciplinas: A QUANTIDADE DE REPROVAS OU DESISTÊNCIAS. Os dados apresentados a seguir comprovam minha afirmação:

·          Os cursos de lógica de programação iniciam com uma média de 50 alunos e em poucos meses, constata-se que taxa de reprovação (ou desistência) chega a 60% (dados extraído de Rocha (1993)).

·          Os dados delineados por Rocha (1993) são compartilhados pelas instituições que apadrinham o autor deste texto, a Fundação Educacional do Município de Assis (www.femanet.com.br) e a Faculdade de Tecnologia de Ourinhos (www.fatecou.edu.br), vejam só:

o     Faculdade de Tecnologia de Ourinhos – Ingressantes: 200 alunos. Concluintes: cerca de 50%.

o     Fundação Educacional do Município de Assis – Ingressantes: 70 alunos. Concluintes: cerca de 55%.

Com base nos números apresentados é possível constatar que nós professores estamos com um problema eminente nas mãos.  Será que existem meios que possibilitem o ensino de lógica de programação com mais eficiência e eficácia? As linguagens e o paradigma nos cursos de lógica de programação são adequados ao ensino? Como motivar o aluno dentro das disciplinas introdutórias da área de programação? Alguns trabalhos buscam constantemente uma solução para estas questões, entre eles é possível citar Baranauskas (1993), Fernandes et. al. (2000), Fernandes e Menezes (2001) e Prus (2001). Vale à pena dar uma olhada neles.

Neste texto gostaria de tratar uma questão em especial: a motivação dos alunos nas disciplinas introdutórias de programação.

É de conhecimento da comunidade que os alunos ingressantes nos cursos, de computação, nasceram na era da informação, tem um contato estreito com diversas mídias, e seu raciocínio não é linear. Alguns fatos chamam a atenção na formação básica destes alunos, destaco três deles, fique a vontade para apresentar um número maior:

·          A leitura não é um hábito cultivado sistematicamente. Em uma pesquisa feita com meus alunos pude constatar que cerca de 90% não leram livro algum em 2007.

·          A maioria dos alunos não possui o hábito de passar horas e horas estudando. A necessidade de estudar algumas horas durante todos os dias não é uma idéia bem aceita entre eles.

·          Adoram jogar, isto mesmo, trabalhamos com a geração dos jogos digitais.

Ao contrapor os itens citados às características que permeiam as disciplinas introdutórias da área de programação esbarramos na seguinte “regra de produção”.

SE os alunos não possuem o hábito de ler E não passam horas estudando ENTÃO os cursos de lógica de programação possuem altos índices de reprovação ou abandonos.

(A regra de produção está contextualizada para o ensino de lógica de programação. Será que ela pode ser generalizada?).

Para que a regra apresentada não seja disparada, é necessário que nós professores motivemos nossos alunos. Parto do seguinte premissa: as tarefas mais interessantes são menos árduas de realizar. Dentro deste contexto desenvolvi uma experiência junto aos alunos do primeiro ano, do curso de Análise de Sistemas e Tecnologias da Informação, da FATEC de Ourinhos, tal experiência é baseada no trabalho “O Ensino de Lógica de Programação e o Desenvolvimento de Jogos Educacionais: Um Caso Aplicado aos Alunos do Curso de Licenciatura Plena em Matemática”, publicado no final do ano de 2007. Para contextualizar a idéia de algoritmo, propus aos alunos o desenvolvimento de um jogo. Apresentei, a eles, em 6 horas, o conceito básico de algoritmo e alguns comandos da linguagem logo (logo é caracterizada como uma linguagem interpretada voltada, principalmente, para o ensino de crianças e aprendizes em programação, para maiores informações faça o download em www.nied.unicamp.br/publicacoes/pub.php?classe=software&cod_publicacao=70). E, por fim, incentivei-os a desenvolver um jogo para ensinar matemática e aritmética para crianças.

Para o desenvolvimento do jogo estabeleci o seguinte processo:

1.     Atividade 1 – Desenvolvimento e validação, junto ao professor, da interface do jogo.

2.     Atividade 2 – Programação do jogo. Importante: Os conceitos de testes formais não foram abordados.

Após terminar o desenvolvimento, propus os alunos que apresentassem os seus joguinhos em uma seção pública, veja só alguns resultados:

·          Jogo 1: Passeio com a TAT. Objetivo: Fazer com que a TAT leve seus amiguinhos para passear, utilizando meios como distância e ângulos. Os comandos utilizados nesse jogo é pf (para frente); pt (para trás); pe (para esquerda) e pd (para direita). Público alvo: Criança alfabetizadas. Autoras: Camila, Lorena, Marija e Tamirys.

·          Jogo 2: Super Turtle 2008. Objetivos: Cada participante terá que levar a sua tartaruga até o fim do tabuleiro. O jogo é para dois jogadores. Público alvo: Crianças alfabetizadas. Autores: Cleiton, Carla e Karoline.

·          Jogo 3: Caça ao Tesouro. Objetivos: Levar a tartaruga TAT ao mapa, a chave, a pá e ao tesouro. Público alvo: Crianças alfabetizadas.  Autores: Rafael, Julcimar, Rodrigo e Rodrigo Mascari.

As interfaces dos jogos 1, 2 e 3 podem ser verificadas no arquivo Interface dos jogos.

Com o desenvolvimento dos jogos foram colhidos alguns resultados resultado qualitativos, detaco alguns deles::

1.    Aumento da motivação do aluno para com a disciplina. Os alunos questionam se é possível fazer algo mais elaborado com a linguagem C. Respondo que sim, porém é necessário, neste momento, termos uma boa “alfabetização algorítmica”.

2.     Aumento do conhecimento e habilidades dos alunos dentro da área de lógica programação. O programa de computador foi desmistificado logo no início da disciplina.

3.     Expectativa de continuidade dos estudos dentro da área de desenvolvimento de jogos educacionais, principalmente, nos próximos anos da faculdade.

4.     O aluno tem consciência que para produzir um programa é necessário algumas horas de estudo.

A experiência apresentada encontra-se em um estágio inicial, resultados quantitativos relacionados ao número de desistências e reprovas só serão obtidos no final deste semestre. Fica a sugestão para os professores trabalharem com produção de um jogo logo no início da disciplina de programação. Por favor, não se esqueça de estabelecer um processo de produção para trabalhar com este tipo de desenvolvimento.

José Augusto Fabri

Referências

Rocha, H. V. (1993). Representações Computacionais Auxiliares ao Entendimento de Conceitos de Programação. In: “Computadores e Conhecimento: Repensando a Educação”. Livro organizado por Valente, J. A. Editora Unicamp.

Prus, E. M. (2001). “Um Modelo de Sistema Tutor Inteligente Aplicado ao Ensino da Programação Estruturada”. Dissertação de mestrado ao Departamento de Engenharia de Produção e Sistemas da Universidade Federal de Santa Catarina.

Baranauskas, M. C. C. (1993). Uma Abordagem Construcionista ao Design de um Ambiente para Programação em Lógica. In: “Computadores e Conhecimento: Repensando a Educação”. Livro organizado por Valente, J. A. Editora Unicamp.

Fernandes, C. S.; Menezes, P. B. (2001) Metodologia do Ensino de Ciência da Computação: Uma Proposta Para Criança. In: “Anais do Workshop de Informática na Escola”. Fortaleza – Ceará.

Fernandes, C. S., Menezes, P. B., Accorsi, F. (2000) A Propose of Teaching Computer Sciencefor Children. In: “Internacional Conference on Engineering and Computer Education – ICECE”, São Paulo.

Fabri. J. A. O Ensino de Lógica de Programação e o Desenvolvimento de Jogos Educacionais: Um Caso Aplicado aos Alunos do Curso de Licenciatura Plena em Matemática. In Anais do Simpósio Brasileiro de Informática na Educação. São Paulo, 2007.