Ambiente de apoio ao ensino de modelagem de software com máquina de estados: uma extensão para o editor de programação Bluej

Texto

(1)PONTIFÍCIA UNIVERSIDADE CATÓLICA DE SÃO PAULO PUC-SP. Luciano Gaspar. AMBIENTE DE APOIO AO ENSINO DE MODELAGEM DE SOFTWARE COM MÁQUINA DE ESTADOS UMA EXTENSÃO PARA O EDITOR DE PROGRAMAÇÃO BLUEJ. MESTRADO EM TECNOLOGIAS DA INTELIGÊNCIA E DESIGN DIGITAL. SÃO PAULO 2012.

(2) Luciano Gaspar. AMBIENTE DE APOIO AO ENSINO DE MODELAGEM DE SOFTWARE COM MÁQUINA DE ESTADOS UMA EXTENSÃO PARA O EDITOR DE PROGRAMAÇÃO BLUEJ. Dissertação apresentada à Banca Examinadora da Pontifícia Universidade Católica de São Paulo,. como exigên-. cia parcial para obtenção do título de MESTRE em Tecnologias da Inteligência e Design Digital, sob a orientação do Prof. Doutor Ítalo Santiago Vega.. SÃO PAULO 2012.

(3) Luciano Gaspar. Ambiente de Apoio ao Ensino de Modelagem de Software com Máquina de Estados Uma Extensão para o Editor de Programação BlueJ Dissertação apresentada à Banca Examinadora da Pontifícia Universidade Católica de São Paulo,. como exigên-. cia parcial para obtenção do título de MESTRE em Tecnologias da Inteligência e Design Digital.. Professor 1 (Orientador) PUC São Paulo. São Paulo, 10 de Maio de 2012..

(4) À minha esposa, Débora, e aos nossos lhos, Théo e Otávio (in memoriam)..

(5) AGRADECIMENTOS. Agradeço ao professor Dr. Ítalo Santiago Vega pelas contribuições realizadas durante a orientação deste trabalho, por todo incentivo e conança que dele recebi ao longo do mestrado.. Esse eminente educador, hoje, faz parte das referências prossionais que. procuro seguir na minha carreira como docente. Aos professores Daniel Couto Gatti, Mauricio Pontuschka, Júlio Arakaki, Fernando Giorno e Francisco Supino Marcondes pelas importantes contribuições nesta pesquisa. Aos colegas do GEMS (Grupo de Estudo em Modelagem de Software) pelas reexões semanais sobre o desao de desenvolver e ensinar modelagem de sistemas de software. Aos colaboradores da PUC - SP, que sempre me acolheram com respeito, em especial à Sra. Edna que desde o dia da minha matrícula demonstrou extremo carinho pelo seu ofício e deu atenção oferecendo-me o suporte necessário durante o curso. Ao colegas Wendel e Moisés pelo valioso apoio em arquitetura Java. À minha família, pelo exemplo e apoio recebido durante toda minha vida. À minha esposa, Débora, pela presença, paciência e incentivo durante todos os momentos na realização deste trabalho. Ao meu lho Théo, por estar sempre com um sorriso empolgante e me convidar para uma brincadeira nos momentos em que eu mais precisava. Aos meus amigos e familiares, com quem durante o mestrado deixei de compartilhar momentos incríveis, mas que certamente serão compensados. Aos colegas das instituições de ensino por onde passei, pois, fazer parte de times vencedores foi o que me motivou na busca de conhecimento..

(6) Para onde quer que o homem contribua com o seu trabalho deixa também algo do seu coração. Sienkiewicz, Henryk.

(7) RESUMO. Os aspectos que afetam a complexidade no desenvolvimento de sistemas também são barreiras para o processo de ensino-aprendizagem de modelagem de software. Muitas técnicas, ferramentas e processos são adotados nesse tipo especíco de ensino, porém, uma das diculdades encontradas é criar condições para que o aluno vivencie tal complexidade em sala de aula. Como alternativa, a adoção de critérios de análise da qualidade de software, sob a perspectiva arquitetural, pode revelar que mesmo os algorítmos com poucas linhas de código são frágeis e ao longo do seu ciclo de vida apresentam problemas de escalabilidade, manutenção e reuso. Nesse sentido, o propósito desta pesquisa é avaliar se o código produzido pelo aluno, apoiado nos conceitos e técnicas do Modelo de Estados, manifestará características iniciais de uma estrutura modularizada. Uma ferramenta que estende as funcionalidades do ambiente de ensino BlueJ foi desenvolvida e é apresentada neste trabalho. Esta ferramenta, associada aos recursos nativos do BlueJ e aos conhecimentos de Máquina de Estados, permite que o aluno elabore descrições de modelos de software dentro das perspectivas estrutural e comportamental do código.. Palavras-chave: Modelagem de Software; Ambientes de Ensino; Máquina de Estados; Diagramas UML..

(8) ABSTRACT. The aspects that aect the complexity in the development of systems are, also, barriers to the teaching and learning process of software modeling. Many techniques, tools and processes are adopted in this specic kind of teaching, although, one of the greatest issues found in this task is to create conditions in order to make the student experiment such a complexity in the classroom. The adoption of criteria for software quality analysis is an option that, into the architectural prospect, can reveal that, even the algorithm with few code lines are fragile and, along their life cycle, may present problems of scalability, maintenance and reuse.. In this aspect, the purpose of this research is to evaluate if. the codes produced by the student, supported by the concepts and techniques of the State Model, will express the initial characteristics of a modularized structure.. A tool. which extends the functions of the BlueJ teaching environment was developed and it is presented in this paper. That tool, associated with the BlueJ native resources and the State Machines learning make it possible for the student to accomplish software model descriptions according to the structural and environmental code prospects.. Keywords: Software modeling; teaching environments; State Machine; UML Diagrams..

(9) LISTA DE FIGURAS. FIGURA 1. Notação de Evento. ................................................. 23. FIGURA 2. Eventos e Estados. .................................................. 24. FIGURA 3. Estado Inicial. FIGURA 4. Estado Final. FIGURA 5. Estado de Ponto de Escolha. FIGURA 6. Estrutura de um Estado. FIGURA 7. Transição. FIGURA 8. Auto-Transição. FIGURA 9. Elementos do Diagrama de Máquina de Estados. FIGURA 10. Impactos da complexidade no desenvolvimento de um software. FIGURA 11. Quadrantes de modelagem. FIGURA 12. Região crítica do Jogo de Dados, quanto as abstrações no método. play FIGURA 13. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25. ........................................ 25. ............................................ 25. ........................................................... 26. ..................................................... .................... 26. 27. ...... 33. .......................................... 36. .................................................................. 42. Região crítica do Jogo de Dados, quanto as responsabilidades da classe. Craps. ................................................................. FIGURA 14. Região crítica do Jogo de Dados, quanto a separação de preocupações. FIGURA 15. DME do Jogo de Dados Original. FIGURA 16. DME do Jogo de Dados Refatorado. 43. 44. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46. ................................. 47.

(10) FIGURA 17. DME como estímulo a modularização de código. ..................... 48. FIGURA 18. Arquitetura simplicada do BlueJ. .................................. 54. FIGURA 19. Arquitetura simplicada do SAEMOS. FIGURA 20. Área de trabalho do SAEMOS. FIGURA 21. Menu de acesso ao SAEMOS. FIGURA 22. Congurações do SAEMOS. FIGURA 23. Tela para conguração do SAEMOS. FIGURA 24. Barra de Ferramentas. FIGURA 25. Caixa de texto para nomear o Estado. FIGURA 26. Parâmetros de um Estado. FIGURA 27. Exemplo de DME construído com o auxílio do SAEMOS. FIGURA 28. Manipulação de arquivos do SAEMOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58. ...................................... 58. ....................................... 73. ......................................... 74. ................................ 74. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75. ............................... 75. .......................................... 76. ............ 77. .............................. 77.

(11) LISTA DE TABELAS. TABELA 1. Diagramas da UML 2.0. TABELA 2. Características internas afetadas e suas consequências no software. TABELA 3. Classicação das referências de acordo com objetivo pedagógico e aspectos de Brooks. ............................................. 35. . . 45. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50. TABELA 4. Estratégias estudadas para implementação do SAEMOS. TABELA 5. Abstrações de Estímulos, Estados, classe de Controle, classe de Operação e Métodos de uma aplicação. ............ ..................................... TABELA 6. Uso da tabela proposta no Jogo de Dados refatorado. TABELA 7. Uso da tabela proposta no Jogo de Dados Original. TABELA 8. Classicação das Habilidades e Competências do curso de Análise e Desenvolvimento de Sistemas. ............... 57. 61. 62. . . . . . . . . . . . . . . . . . 62. ......................................... 72.

(12) LISTA DE ABREVIATURAS E SIGLAS. API. Application Programming Interface. BDD. Behavior Driven-Development. CASE. Computer-Aided Software Engineering. DAT. Diagrama de Atividades UML. DCL. Diagrama de Classes UML. DME. Diagrama de Máquina de Estados UML. DOB. Diagrama de Objetos UML. DSM. Diagrama de Sequência de Mensagens UML. ES. Engenharia de Software. IBSS. Indústria Brasileira de Software e Serviços. IDE. Integrated Development Environment. MDD. Model Driven Development. OTAN. Organização do Tratado do Atlântico Norte. POO. Programação Orientada a Objetos. SAEMOS. Sistema de Apoio ao Ensino de Modelagem de Software. SI. Sistemas de Informação. SDK. Software Development Kit. TI. Tecnologia da Informação. UML. Unied Modeling Language.

(13) SUMÁRIO. 1 INTRODUÇÃO. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 1.1 Contexto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 15. 1.2 Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 16. 1.2.1 Objetivo Geral . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 16. 1.2.2 Objetivos Especícos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 16. 1.3 Metodologia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 17. 1.4 Hipótese do Trabalho de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . .. 18. 1.5 Proposta de Pesquisa . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 18. 1.5.1 Estudo de Caso - Jogo de Dados . . . . . . . . . . . . . . . . . . . . . . . . . .. 19. 1.6 Estrutura do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 21. 2 FUNDAMENTOS DO DIAGRAMA DE MÁQUINA DE ESTADOS . 22 2.1 Evento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 22. 2.2 Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 23. 2.3 Transição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 25. 2.4 Ações e Atividades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 26. 2.5 Formação do Diagrama de Máquina de Estados . . . . . . . . . . . . . . .. 26. 2.6 Diagramas de Máquina de Estados e os Objetos . . . . . . . . . . . . . . .. 28. 2.6.1 Caracterização de Sistemas Reativos . . . . . . . . . . . . . . . . . . . . . .. 28. 2.6.2 Caracterização de Sequências de Operações . . . . . . . . . . . . . . . . .. 29. 2.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 29. 3 MODELAGEM DE APLICAÇÕES DE SOFTWARES . . . . . . . . . . . . . . . 31.

(14) 3.1 Barreiras de Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 32. 3.1.1 Complexidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 33. 3.1.2 Conformidade e Flexibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 3.1.3 Intangibilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 34. 3.2 Notação UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 35. 3.3 Quadrantes de Modelagem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 36. 3.3.1 Modelos de Manifestação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 37. 3.3.2 Modelos Descritivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 38. 3.4 Modularização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 3.5 Odores e Heurística do Software . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 39. 3.5.1 Funções e Métodos Devem Ser Pequenos . . . . . . . . . . . . . . . . . . .. 41. 3.5.2 Princípio de Responsabilidade Única . . . . . . . . . . . . . . . . . . . . . .. 42. 3.5.3 Separação de Preocupações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 43. 3.5.4 Estruturas Switch, IF/Else e While . . . . . . . . . . . . . . . . . . . . . . .. 44. 3.6 Modelagem do Jogo de Dados com Modelo de Estados . . . . . . . . .. 45. 3.7 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 48. 4 TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50 4.1 Iniciativas no ensino de programação . . . . . . . . . . . . . . . . . . . . . . . .. 50. 4.2 Ferramenta BlueJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 52. 4.2.1 Extensões do BlueJ. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 52. Sequence Diagram Editor: . . . . . . . . . . . . . . . . . .. 52. PatternCoder: . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 53. SMT Tool: . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 53. 4.2.2 Arquitetura do BlueJ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 53. 4.3 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 54.

(15) 5 RESULTADOS DA PESQUISA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56 5.1 Ambiente de Apoio ao Ensino de Modelagem . . . . . . . . . . . . . . . . .. 56. 5.1.1 Limitações do SAEMOS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 59. 5.2 Benefícios do Modelo de Máquina de Estados no Ensino de Modelagem de Software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 59. 5.3 Proposta de Abstração em Formato Tabular dos Elementos do Modelo de Estados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 60. 5.4 Considerações Finais . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 63. 6 CONCLUSÃO E TRABALHOS FUTUROS . . . . . . . . . . . . . . . . . . . . . . . . . 64 REFERÊNCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66 APÊNDICE A -- CÓDIGO FONTE REFATORADO DO JOGO DE DADOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69 APÊNDICE B -- HABILIDADES E COMPETÊNCIAS DO CURSO DE ANÁLISE E DESENVOLVIMENTO DE SISTEMAS . . . . . . . . . . . . . . . . 72 APÊNDICE C -- MANUAL DO USUÁRIO - SAEMOS . . . . . . . . . . . . . . . . . 73 C.1 Instalação do SAEMOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 73. C.2 Congurações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 74. C.3 Barra de Ferramentas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 75. C.4 Construindo um DME . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. 75. ANEXO A -- CÓDIGO FONTE JOGO DE DADOS . . . . . . . . . . . . . . . . . . . . . 78.

(16) 13. 1 INTRODUÇÃO Os Sistemas de Informação (SI) são considerados hoje um provedor de solução para as mais diversas áreas do conhecimento. É um seguimento que está em franco desenvolvimento impulsionando a indústria, o comércio, os serviços e em especial seguimentos de mercado dependentes de tecnologia (LAUDON;. LAUDON,. 2010).. Em razão da crescente importância do software e ao maior conhecimento (desde 1967) sobre como construí-lo, torna-se necessário oferecer uma formação mais ampla para o programador de computador. Este prossional deve estar preocupado em aplicar conhecimentos especializados para projetar, construir, testar e manter os produtos de software (PARNAS, 1998). Segundo Parnas (1998), desenvolver produtos de software, assim como mantê-los, 1. faz parte do corpo de conhecimento da Engenharia de Software (ES) . Sendo assim, uma das preocupações que se deve ter no ensino dos tópicos da ES é que o aluno seja capaz de projetar sistemas de software que favoreçam, ao longo do seu ciclo de vida, a baixa degradação do código escrito. O número de cursos na área da computação no Brasil vem crescendo nos últimos anos.. Nunes (2008), aponta que, entre os anos 2000 e 2008, foram criados oitocentos. novos cursos para essa área. Tais cursos, direta ou indiretamente, possuem em sua matriz curricular disciplinas que abordam ferramentas, técnicas e processos para a construção de softwares. Para os cursos cujo foco principal não é o desenvolvimento de sistemas interativos, as linguagens utilizadas enquadram-se no paradigma estrutural de programação.. Este. paradigma orienta os programadores para a criação de estruturas simples em seus programas, usando sub-rotinas e funções. Sua estrutura pode ser representada por modelos, porém Brooks (2010) arma que os modelos e o código que os implementa possuem grande similaridade, diminuindo a complexidade na sua produção Já em relação aos cursos, cujo objetivo é a formação de prossionais que lidarão com análise e desenvolvimento de sistemas interativos, o aluno deve ser preparado para 1 Termo. criado em 1968 na Conferência da OTAN (NAUR; RANDELL, 1968).

(17) 14 lidar com os aspectos que afetam a produção e manutenção do software ao longo do seu ciclo de vida. Para tanto, faz-se necessário o aprimoramento das ferramentas, técnicas e processos adotados. O campo da computação vem se aprimorando, em especial, após a crise do software. Este termo foi cunhado no nal da década de 1960 para descrever as diculdades enfrentadas no desenvolvimento de softwares. Esta crise marcou o início de uma série de inovações; entre elas incluem-se: a modularidade, a programação estruturada, a proteção de informações (information hiding ), a abstração de dados, os novos ambientes de desenvolvimento, a reutilização de código, a programação visual e a orientada a objeto, os padrões de projetos e as ferramentas CASE (GIBBS, 1994). Passadas duas décadas, Neumann (1994) publicou uma lista das 1.500 falhas desastrosas dos sistemas de software ocorridas desde 1972. A lista foi acrescida de 200 casos em 1993, e em 2010 foi publicado por Eveleens e Verhoef (2010) o relatório de caos rearmando que muitos dos problemas ainda não tinham sido resolvidos. Considerando estas informações, aliadas à crescente demanda por sistemas de software, o número de falhas pode aumentar e transformar projetos de sistemas naquilo que Gibbs (1994) denominou 2. roleta russa . Entre as inovações indicadas acima, destaca-se a Programação Orientada a Objetos (POO). A POO inuenciou diretamente a maneira como os sistemas são desenvolvidos. Nos últimos anos, a POO e os recursos de modelagem têm nos ajudado a lidar com as diculdades oriundas da natureza da produção de softwares (BROOKS, 1995). Referindo-se à POO, Parnas (1998) arma que esse tipo de programação tem sido 3. ensinado como ferramenta e não como princípios de projetos . Neste caso, o resultado é que se obtém pouco valor no pruduto, e se o valor percebido é pequeno, a tecnologia leva mais tempo para ser absorvida. Nesse sentido, o presente trabalho visa apoiar-se em conceitos de orientação a objetos e investigar se o uso de descrições de modelos de software auxiliam o aluno na produção de códigos organizados de maneira que favoreçam uma arquitetura segregada e apontem necessidades de renamentos. Como contribuição, são apresentados os ganhos obtidos na modelagem de software, 2 Expressão. utilizada para fazer referência a um jogo de azar que oferece altos riscos para os participantes 3 Termo projeto utilizado no contexto de gerenciamento de atividades colocando como premissa o paradigma de orientação a objetos.

(18) 15 com foco comportamental, utilizando o Modelo de Máquina de Estados, uma maneira particular de organizar os elementos do sistema em forma de tabela, e um aplicativo denominado SAEMOS (Sistema de Apoio ao Ensino de Modelagem de Software) para elaboração do Diagrama de Máquina de Estados (DME).. 1.1 Contexto Conforme mencionado na introdução deste trabalho, os conhecimentos produzidos na área da Engenharia de Software estão dando suporte a diferentes segmentos da sociedade, em especial, àqueles que apoiam os processos administrativos das organizações. As práticas e os novos conhecimentos nesta área não crescem na mesma proporção que a demanda e a escala dos aplicativos, o que a torna frágil. A crescente demanda é conrmada pela falta de prossionais no mercado. Spinosa (2009), revelou em sua pesquisa que 72,1% das empresas consultadas possuem vagas na área de Tecnologia da Informação (TI) em aberto.. Entre essas vagas, 86,1% são para. analistas/programadores; 50,5% são para analistas de sistemas e 27,2% são vagas para projetistas de software/design de sistemas que não estão ocupadas. Villela (2009) apresenta uma projeção de décit da força de trabalho em ocupações envolvidas na produção de software e serviços de TI, destacando que no ano de 2013 a necessidade será de mais de 140 mil prossionais, considerando-se as demandas da Indústria Brasileira de Software e Serviços de TI (IBSS) e as demais empresas. Com relação ao perl desejado, Spinosa (2009) aponta que 48,2% das empresas consultadas classicam o perl do prossional de TI disponível no mercado como razoável, tendo problemas de recrutamento apenas para certos pers. Porém o autor avaliou essa mesma porcentagem como ruim, declarando ter diculdades para recrutar trabalhadores com as competências desejadas. Apenas 3,6% das empresas consideraram ótimo o prossional disponível, não tendo diculdades para recrutamento. De acordo com os dados apresentados, avalia-se o prossional envolvido na construção de software como incompleto, porém Brooks (2010) arma que as barreiras enfrentadas na atividade de análise e desenvolvimento de sistemas ainda não foram vencidas. Certamente, tanto uma suposta falta de qualicação dos prossionais no mercado quanto a natureza complexa do software têm impacto direto na sua cadeia de produção, o que eleva o número de posições de trabalho..

(19) 16 Diante deste cenário, e levando-se em consideração que o pesquisador deste trabalho está inserido prossionalmente em um contexto de ensino de Engenharia de Software, torna-se necessário que todo o processo de ensino-aprendizagem nesta área seja questionado, estimulando-se o espírito crítico no que tange ao perl do egresso dos cursos de computação, às ferramentas disponíveis e à abordagem no ensino de modelagem de software.. 1.2 Objetivo. 1.2.1 Objetivo Geral O objetivo geral deste trabalho foi identicar os benefícios que o Modelo de Máquina de Estados pode trazer para o processo de ensino-aprendizagem de modelagem de software. Para atingir esse objetivo, foram estudados os conceitos de Máquinas de Estados, modelagem de aplicações de software e uma abordagem denominada Quadrantes de Modelagem, além de critérios de análise de código com vistas à qualidade do software produzido pelo aluno. É importante lembrar que o assunto estudado é abrangente. Consequentemente, foi necessário restringir o estudo aos aspectos mencionados acima, que estão diretamente relacionados ao uso da Máquina de Estados visando à maior qualidade do código produzido pelo aluno.. 1.2.2 Objetivos Especícos Para que o objetivo geral deste trabalho fosse atingido, foram necessários os seguintes subprodutos: 1.. Realizar um levantamento bibliográco das principais ferramentas de ensino. de lógica e linguagens de programação, bem como dos ambientes de desenvolvimento e modelagem de software e classicá-los quanto ao seu objetivo pedagógico. 2.. Realizar um estudo sobre os conceitos, notação, elementos e aplicação da. Máquina de Estados. 3. Elencar critérios para avaliação do uso de Modelos de Máquina de Estados para o ensino de modelagem..

(20) 17 4.. Analisar as contribuições e limitações do Modelo de Máquina de Estados no. ensino. 5. Desenvolver e implementar uma ferramenta de apoio ao ensino de modelagem de software. A ferramenta construída é uma extensão do ambiente de ensino BlueJ proposto por (KöLLING, 1999a).. 1.3 Metodologia Este trabalho foi desenvolvido utilizando-se técnicas de pesquisas bibliográcas e experimental publicadas sobre o assunto. Inicialmente, foi feita uma pesquisa bibliográca sobre as principais ferramentas de ensino de modelagem e programação de software, entre outras técnicas utilizadas para auxiliar o ensino neste domínio. Um estudo da ferramenta BlueJ foi realizado visando identicar as principais extensões, limitações e contribuições, para, em seguida, estender suas funcionalidades por meio de um plugin. De posse do código fonte do software BlueJ, foram utilizadas técnicas de engenharia reversa para a obtenção parcial da sua arquitetura, visando à melhor adequação do software proposto nesta pesquisa. Foi arquitetado um protótipo de software, estendendo-se as funcionalidades do BlueJ, com o objetivo de provê-lo de recursos para a criação do Diagrama de Máquina de Estados. Em seguida, apoiado nos conceitos de Padrões de Projeto, esse protótipo passou por renamentos visando seu aprimoramento e, em seguida, sua implementação. Estudos sobre critérios de qualidade de software foram realizados tendo em vista obter-se recursos de análise sobre os reexos do Modelo de Estados no código fonte do aluno de graduação. Um ensaio de modelagem de software apoiado no Modelo de Estados foi realizado, evidenciando os benefícios deste modelo na organização das linhas de código. Enm, foram registrados os resultados do ensaio da modelagem e apresentada a ferramenta proposta..

(21) 18. 1.4 Hipótese do Trabalho de Pesquisa A utilização do Modelo de Máquina de Estados no processo de ensino-aprendizagem de modelagem de software pode estimular a criação e o renamento inicial da arquitetura do software. Assumindo que a hipótese é verdadeira, têm-se os seguintes benefícios:. •. Contribuição para que o aluno formalize uma abstração de uma elaboração mental em um modelo concreto (linhas de código).. •. A modelagem se torna representativa, pois auxilia o programador (aluno) a reconhecer quais linhas de código produzir, tendo impacto na fase de design, onde são tomadas decisões arquiteturais de como organizar o código.. •. O Diagrama de Máquina de Estados pode ser utilizado como critério inicial de modularização do código.. 1.5 Proposta de Pesquisa Conforme citado nos elementos introdutórios desta pesquisa, a complexa atividade de se desenvolver sistemas de software e seus impactos têm gerado preocupações para as empresas e para os educadores.. Embora possuam objetivos distintos, a origem do. problema está diretamente relacionada a ambos. Lidar com algo complexo em projetos de software ou expor a complexidade do software em sala de aula são desaos que professores e organizações devem superar. Entre os aspectos que afetam a complexidade do ensino e do desenvolvimento do software estão as tarefas essenciais. Um software, para ser produzido, exige um um conjunto de tarefas, que são classicadas por Brooks (1987) como acidentais e essenciais. As tarefas acidentais estão relacionadas à implementação do software, e suas principais preocupações estão ligadas a sintaxe das linguagens, aos limites de hardware, aos ambientes e ferramentas de desenvolvimento e demais aspectos técnicos. As tarefas essenciais estão relacionadas ao processo mental de criação de um conjunto de conceitos que se interligam. Tanto as tarefas acidentais quanto as essenciais criam barreiras para o ensino e o desenvolvimento de softwares. Para Brooks (1987), grande parte das barreiras acidentais.

(22) 19 foram transpostas na última década, e as principais falhas de projetos estão relacionadas às atividades essenciais, que criam barreiras dicilmente superadas. De forma análoga, e neste contexto, pode-se comparar o processo de desenvolvimento de software ao de criação de um texto, no qual as tarefas acidentais estão relacionadas ao domínio de uma ferramenta de edição de textos, à sintaxe e à semântica da língua. Tais tarefas podem criar barreiras para a produção do texto, mas serão superadas com algum nível de estudo ou apoio de terceiros; porém, isso não garante que o texto escrito atenderá aos critérios de qualidade. Logo, o domínio de tarefas acidentais não garante a qualidade do que está sendo produzido. A qualidade será denida pela forma peculiar de criação e organização das ideias atuando sobre a construção mental e essencial que serão descritos de forma textual. A área de interesse desta pesquisa está relacionada aos aspectos essenciais, ou seja, investigar qual a contribuição que o Modelo de Máquina de Estados oferece no constructo mental do software que será implementado por um conjunto de linhas de código em determinada linguagem de programação.. 1.5.1 Estudo de Caso - Jogo de Dados Uma das diculdades encontradas no ensino de programação de computadores é criar condições para que os alunos vivenciem a complexidade de se desenvolver softwares em larga escala. A escassez de tempo ou a carga horária das disciplinas podem fazer com que os exercícios propostos em sala de aula sejam simples e reduzidos, de forma que o aluno não note a necessidade da criação de modelos para entendê-lo. A falta de percepção da necessidade de criação de modelos pode levar o aluno a trabalhar orientado ao código; porém, devido ao fato dos requisitos apresentados pelo professor serem sucientemente ajustados para a conclusão em poucas aulas ou até mesmo no decorrer da disciplina, o aluno apresenta algoritmos cujo comportamento atenda aos requisitos apresentados, tornando a percepção do aluno sobre modelagem como desnecessário. Segundo Sommerville (2007), atender a um requisito signica cumprir com as necessidades dos clientes de um sistema que ajuda a resolver algum problema. Um programa, independentemente da organização de suas linhas de código, descreve uma computação que atenderá aos requisitos do cliente. No entanto, a capacidade de organizar o código de forma que favoreça a manutenção, ganho de escala e reuso, dependem de decisões arquiteturais apoiadas por modelos..

(23) 20 À primeira vista, soluções triviais, quando observadas sob a ótica da qualidade de software com foco na organização das linhas de código, podem revelar situações que exijam conhecimentos técnicos e conceituais para que sejam criadas soluções adequadas que atendam a determinados critérios. Como exemplo desse pressuposto, no decorrer desse trabalho será utilizado um exercício adotado e respeitado há anos denominado Jodo de Dados. extraído de um livro didático da área de programação.. Este exercício foi. Quando cabível, os conceitos. apresentados serão exemplicados e aplicados no código proposto por Deitel e Deitel (2005) para o Jogo de Dados . Enunciado do Exercício:. O Jogo de Dados. O jogador lança dois dados.. Cada um deles com seis faces.. 1, 2, 3, 4, 5 e 6 pontos, respectivamente.. Essas faces contêm. Depois que os dados param de rolar,. calcula-se a soma dos pontos nas faces viradas para cima. Se a soma for 7 ou 11 no primeiro lance, o jogador ganha. Se a soma for 2, 3 ou 12 no primeiro lance (o que é denominado craps), o jogador perde. Se a soma for 4, 5, 6, 8, 9 ou 10 no primeiro lance, essa total torna-se a pontuação do jogador. Para ganhar, ele deve continuar a rolar os dados até fazer sua pontuação (isto é, obter um valor igual à sua pontuação). O jogador perde se obtiver 7 antes de completar a pontuação.. O código (Anexo A) proposto por Deitel e Deitel (2005), está escrito em uma única classe e pode oferecer problemas ao longo do seu ciclo de vida. É uma estrutura monolítica e, consequentemente, fortemente acoplada. Estruturas desta natureza dicultam a manutenção, a escalabilidade e o reuso. O propósito da utilização deste exemplo é avaliar se o código produzido pelo aluno, apoiado nos conceitos e técnicas do Modelo de Máquina de Estados, manifestará características iniciais de uma estrutura modularizada. Os critérios de qualidade e a análise do código são apresentados na Seção 3.5, assim como os resultados obtidos após o uso do DME. O código completo refatorado encontra-se no Apêndice A..

(24) 21. 1.6 Estrutura do trabalho O presente trabalho está organizado conforme descrito a seguir. O primeiro capítulo apresenta o tema e a hipótese que lhe servem de base, incluindo ainda os objetivos geral e especíco, bem como a problemática abordada referente ao tema de estudo. Fundamentos do Diagrama de Máquina de Estados são abordados no segundo capítulo. Esses fundamentos foram adotados na implementação da ferramenta SAEMOS, que é apresentada ao longo dos registros desta pesquisa. Este trabalho adota a notação UML para a representação de modelos de software. Esta notação bem como uma particular abordagem no ensino de modelagem são apresentadas no capítulo três. Além disso, é demonstrado um conjunto de critérios de análise de código e realizada uma análise do Jogo de Dados. Ainda neste capítulo, são introduzidos os temas modularização e barreiras de modelagem. Um conjunto de trabalhos que fazem parte da revisão bibliográca foi classicado quanto ao seu objetivo pedagógico. Entre esses trabalhos, estão relacionadas as principais extensões do BlueJ e suas contribuições ao ensino. Estes estudos são abordados no capítulo quatro. O capítulo cinco apresenta os principais resultados dessa pesquisa, evidenciando a extensão denominada SAEMOS, suas funcionalidades, arquitetura e limitações, assim como a contribuição do Modelo de Máquina de Estados no ensino de modelagem de software. A conclusão desta pesquisa está registrada no capítulo seis. Finalmente, são apresentadas as referências bibliográcas utilizadas para o desenvolvimento desta pesquisa..

(25) 22. 2 FUNDAMENTOS DO DIAGRAMA DE MÁQUINA DE ESTADOS O percurso desta pesquisa visa identicar os benefícios que o Modelo de Máquina de Estados pode trazer para o processo de ensino-aprendizagem de modelagem de software. A representação adotada neste estudo e implementada no ambiente de ensino proposto pelo pesquisador é o Diagrama de Máquina de Estados. O Diagrama de Máquina de Estados (DME) descreve uma sequência de transições que ocorre em resposta a estímulos externos.. O Modelo de Estados consiste em vários. Diagramas de Estados, um para cada classe, com comportamento temporal importante para cada aplicação (BLAHA;. RUMBAUGH,. 2006). Este diagrama é utilizado para acom-. panhar a troca de estados que ocorre em uma ou mais instâncias de uma determinada classe durante seu tempo de vida. Booch, Rumbaugh e Jacobson (2005) denem uma Máquina de Estados como um comportamento que especica as sequências de estados pelos quais um objeto passa durante seu tempo de vida em resposta a eventos, juntamente com suas respostas a esses eventos. Em suma, um ou mais Diagramas de Máquina de Estados é uma forma de descrever um modelo de comportamento de objetos e os diferentes estados interessantes que ele assume em seu ciclo de vida, mediante estímulos. Booch, Rumbaugh e Jacobson (2005) denem como um conjunto de elementos para representar Máquinas de Estados concorrentes.. Neste trabalho, só serão apresentados. os principais elementos que compõem um Diagrama de Máquina de Estados. São eles: eventos, estados, transições, ações e atividades.. 2.1 Evento Neste trabalho, o pesquisador tomou como referência a denição de Larman (2005), que dene evento como uma ocorrência signicativa ou digna de nota. No contexto de um DME, um evento é a ocorrência de um estímulo capaz de ativar uma transição de estado (Seção 2.3). Para Blaha e Rumbaugh (2006), o termo evento é usado de forma ambígua:.

(26) 23 algumas vezes refere a uma instância; outras vezes, a uma classe. revela-se a partir do contexto.. O signicado exato. Os autores recomendam diferenciar como ocorrência de. evento ou tipo de evento ; por exemplo: Mensagem e envio de mensagem, onde Mensagem é um tipo de evento e o envio é a ocorrência do evento. A denição de Booch, Rumbaugh e Jacobson (2005) refere-se a evento como uma especicação de uma ocorrência signicativa que tem uma localização no tempo e no espaço. No contexto de Máquina de Estados os eventos são utilizados para representar a ocorrência de um estímulo capaz de alterar um estado. Blaha e Rumbaugh (2006) classicam os eventos em três tipos:. Evento de sinal:. é uma ocorrência no tempo de envio ou recebimento de um. sinal, sendo que sinal é uma mensagem entre objetos.. Evento de mudança:. é um evento causado pela satisfação de uma expressão. booleana. Sempre que a expressão muda de falso para verdadeiro, o evento acontece. Na notação UML, utiliza-se a palavra-chave when seguida de uma expressão booleana entre parênteses. Exemplo: when (carga da bateria < limite mínimo).. Evento de tempo:. é um evento que representa a passagem de um intervalo. de tempo. É usado para modelar o tempo disparando uma transição. Na notação UML, utiliza-se a palavra-chave when seguida de uma expressão entre parênteses.. Exemplo:. when (data = 01/01/2012). Um evento carrega consigo seu nome e seus parâmetros. A Figura 1 apresenta a notação de um evento.. Figura 1: Notação de Evento. 2.2 Estados Larman (2005) dene um estado como uma condição de um objeto em determinado momento no tempo. Entretanto, para Blaha e Rumbaugh (2006) um estado é uma.

(27) 24 abstração dos valores e ligações de um objeto; tais ligações são agrupadas em estados de acordo com o comportamento dos objetos. Um estado pode satisfazer uma condição, realizar alguma atividade ou aguardar algum evento (BOOCH;. RUMBAUGH; JACOBSON,. 2005). Na denição de estados ignoram-se atributos que não afetam o comportamento do objeto e reúnem-se em um único estado todas combinações de valores e ligações que responderão da mesma maneira a um evento. Larman (2005) diferencia evento e estados, denindo evento como uma representação do tempo e estados como representações de intervalos de tempo. A Figura 2 ilustra esta denição.. Figura 2: Eventos e Estados. Para Guedes (2009), um estado pode demonstrar:. •. A espera pela ocorrência de um evento;. •. A reação a um estímulo;. •. A execução de alguma atividade;. •. A satisfação de alguma condição.. Um diagrama de estados é um grafo cujo nós são estados e as setas direcionadas são transições entre estados. Um diagrama especica as sequências de estados causadas por sequências de eventos (LARMAN, 2005). Existem dois estados especiais. O primeiro, representado na Figura 3, é o Estado Inicial, responsável por indicar o local padrão de início para a Máquina de Estados. Além disso, existe o Estado Final, representado na Figura 4, que indica o local em que a execução da Máquina de Estados foi concluída..

(28) 25. Notação de Estados:. Figura 3: Estado Inicial. Figura 4: Estado Final. No Diagrama de Máquina de Estados existe um elemento denominado Estado de Ponto de Escolha. Ele representa um ponto na transição de estados de um objeto em que deve ser tomada um decisão, onde um estado será ou não gerado. Ele é representado por um círculo sem preenchimento, conforme Figura 5.. Figura 5: Estado de Ponto de Escolha. A Figura 6 ilustra a estrutura de um Estado, sendo a parte superior composta pela descrição do seu tipo, e a inferior as possíveis ações ou atividades executadas pelo objeto quando estiver no Estado.. Figura 6: Estrutura de um Estado. 2.3 Transição Larman (2005) dene Transição como um relacionamento entre dois Estados, indicando que quando um evento ocorre, o objeto muda do Estado anterior para o Estado subsequente. Até a Transição iniciar o objeto é considerado no Estado de origem; após a Transição ser iniciada, o objeto passa ao Estado de destino. Booch, Rumbaugh e Jacobson.

(29) 26 (2005) acrescentam o conceito condição, no qual uma Transição representa a mudança de um Estado quando uma condição especíca for satisfeita.. Figura 7: Transição. Quando o objeto exibir o mesmo comportamento em determinado instante de tempo, não é preciso representá-lo separadamente.. Blaha e Rumbaugh (2006) denom-. inam este tipo de Transição de Auto-Transição.. Figura 8: Auto-Transição. 2.4 Ações e Atividades Ações e Atividades são normalmente confundidas, porém Booch, Rumbaugh e Jacobson (2005) diferenciam-nas da seguinte forma:. Atividade é uma execução não-atômica em andamento em uma Máquina de Estados, que acaba resultando em alguma ação formada por computações atômicas executáveis que resultam em uma alteração de Estado ou no retorno de um valor (BOOCH;. RUMBAUGH; JACOBSON,. 2005).. As Atividades são representadas por métodos, e as ações, por instruções ou comandos em linguagens de programação. Guedes (2009) associa Atividade a Estado e uma Ação à Transição, ou seja enquanto um objeto estiver em um determinado estado ele realiza uma atividade (Do ), e no momento em que o objeto assume um estado ou antes de deixá-lo ele executa um ação (Entry ou Exit ).. 2.5 Formação do Diagrama de Máquina de Estados A Figura 9 apresenta os elementos de um DME e a relação entre eles. Observa-se o uso do Estado Inicial (Figura 3) que inicia um DME, seguido de uma Transição (Figura.

(30) 27 7) responsável por interligar os Estados que um ou mais objetos assumem durante a computação. Estados (Figura 6) estes que, estimulados por eventos (Seção 2.1) assumem comportamentos descritos por Ações e Atividades (Seção 2.4). O ciclo de vida de um objeto pode conter condições, que se verdadeiras, causam mundança no Estado.. Tais condições podem estar atreladas ao Estado de Ponto de. Escolha (Figura 5) onde são tomadas decisões se um Estado será ou não gerado. Caso um Estado seja gerado e ele exibir o mesmo comportamento descrito por ações e/ou atividades, este comportamento será representado pela notação de Auto-Transição (Figura 8). Por m, a representação de um comportamento signicativo é encerrada pelo Estado Final (Figura 4).. Figura 9: Elementos do Diagrama de Máquina de Estados.

(31) 28. 2.6 Diagramas de Máquina de Estados e os Objetos Um Diagrama de Máquina de Estados mostra o ciclo de vida de um objeto. Larman (2005), faz a classicação dos objetos de duas formas:. (i) Objetos independentes de Estados: mesma maneira a um Evento.. são aqueles que sempre respondem da. Um objeto recebe uma mensagem e o método responde. a ele sempre da mesma forma. Neste caso, é rara a necessidade de uso do DME. Neste sentido, Booch, Rumbaugh e Jacobson (2005) recomendam que, quando o Estado atual de um objeto não depender de seu Estado passado, não é necessário uma Máquina de Estados para especicá-lo.. (ii) Objetos dependentes de Estados:. são aqueles que reagem de maneira. diferente aos eventos, dependendo do seu estado.. Nestes casos, o uso do DME pode. adicionar valor a um modelo de objetos. Para Larman (2005), sistemas de controle de processos, controle de dispositivos, tratadores de protocolos e domínios de telecomunicações são fortemente dependentes de Estados e devem ser modelados por um DME. A modelagem de objetos dependentes de Estados é utilizada para modelar comportamentos em sistemas reativos (Seção 2.6.1) e para modelar sequências de operações (Seção 2.6.2).. 2.6.1 Caracterização de Sistemas Reativos Para Harel e Politi (1998), um sistema reativo exibe as seguintes características: - Enquanto estiver em uso, o sistema depende do ambiente, usando entradas e saídas ao longo do tempo. As entradas e saídas frequentemente são assíncronas e podem mudar de valor a qualquer momento. - Deve ser capaz de responder a interrupções (eventos de alta prioridade), mesmo quando ele esteja ocupado. - A reação às entradas, devem seguir rigorosamente os requisitos de tempo. - Existem muitas formas de interagir com o ambiente, e devem considerados valores atuais e passados. - Pode ser baseado em processos que trabalham em paralelo. Larman (2005) agrupa os sistemas reativos em:. dispositivos físicos, transações. e objetos de negócios relacionados e objetos mutantes.. Neste último caso, trata-se de.

(32) 29 objetos que mudam seu papel ao longo do tempo. Cada papel pode ser representado por um Estado. No contexto deste trabalho de pesquisa e de uso da ferramenta proposta, os aspectos acima não são caracterizados e validados pela ferramenta, cabendo ao professor, na sua abordagem em sala de aula, apresentar tais características ao aluno, dando condições para que ele escolha os problemas a serem modelados com DME.. 2.6.2 Caracterização de Sequências de Operações Caso um sistema seja composto por um conjunto de componentes, e eles sigam uma ordem de execução em função do tempo, é possivel fazer uso de Diagramas de Máquina de Estados para ajudar a documentar, entender e criar modelos durante o processo criativo. Larman (2005), arma que o uso de DME também pode ser útil em aplicações que possuam uxos ou sequências complexas. São exemplos de uso em aplicações sequenciais e operações, os itens: -. Modelagem de interfaces de usuários:. o DME se torna útil para modelar. sequências adequadas de navegação entre páginas ou janelas de um sistema para internet. -. Controladores ou sessões de uxo da interface do usuário:. o DME é. também de grande utilidade para modelar o uxo de páginas que um servidor de aplicação deve exibir, ou seja, o uxo de controle de uma sessão em andamento no servidor. Por exemplo: uma transação bancária para consulta de saldo via Internet. -. Operações de caso de uso do sistema:. o DME pode modelar a sequência. de casos de uso, tratando cada um deles como um objeto e estabelecendo a sequência em que eles podem ocorrer.. 2.7 Considerações Finais Neste capítulo, foram apresentados os fundamentos do modelo e do Diagrama de Máquina de Estados. Além dos estudos realizados sobre os fundamentos do modelo e o diagrama que o descreve, o pesquisador deste trabalho desenvolveu um protótipo de ferramenta que poderá ser utilizado por professores e alunos no processo de ensinoaprendizagem de modelagem de software. A ferramenta em questão é denominada SAEMOS e permite a criação de Diagramas de Máquina de Estados em projetos elaborados pelo ambiente de ensino BlueJ..

(33) 30 O SAEMOS dá suporte aos conceitos apresentados neste capítulo, porém, não efetua a validação ou correção do diagrama elaborado pelo usuário. Ao longo deste trabalho são apresentadas as contribuições do SAEMOS para antigir os objetivos da pesquisa. O Capítulo 5 detalha sua arquitetura básica e suas funcionalidades..

(34) 31. 3 MODELAGEM DE APLICAÇÕES DE SOFTWARES Sabe-se que existe um limite para a capacidade humana compreender algo complexo. O software possui uma natureza de complexidade crescente, seja pelo número de linhas de códigos ou pela sua intangibilidade (BROOKS, 2010). Logo, a criação de modelos torna-se indispensável para a compreensão do que está sendo desenvolvido. Blaha e Rumbaugh (2006) denem. Modelo. como uma abstração de algo que. facilita seu entendimento antes de construí-lo. Abstração é um processo mental básico que permite lidar com a complexidade, omitindo detalhes não essenciais. No processo de produção do software, criam-se modelos para descrever a estrutura e o comportamento de um software para posterior implementação. Estas descrições de modelos guiam a construção e mantêm registros das decisões tomadas na sua concepção (BOOCH;. RUMBAUGH; JACOBSON,. 2005).. Tradicionalmente, o uxograma foi um modelo de abstração útil para o desenvolvimento de sistemas; contudo, tornou-se limitado para os sistemas que ultrapassam as 10.000 linhas de instruções. Neste caso, técnicas adicionais foram necessárias para lidar com sistemas mais complexos (PARNAS, 1972). Para Booch, Rumbaugh e Jacobson (2005), nenhum modelo único é suciente. Qualquer sistema não-trivial será melhor investigado por meio de um conjunto de modelos quase independentes com vários pontos de vista. Um ou mais modelos podem servir de inspiração para dar origem a uma arquitetura que sustente as necessidades do que está sendo modelado. Segundo Zachman (1997), arquitetura é o conjunto de artefatos ou um descritivo relevante de um objeto, de forma que este possa ser construído de acordo com os requisitos (de qualidade), bem como mantido ao longo da sua vida útil. Neste sentido, modelar um sistema signica determinar e representar um conjunto de informações arquitetadas sob diferentes pontos de vista que servirão de guia de referência para a produção de algo concreto (código fonte). Cada área de conhecimento adota tipos especícos de modelos. Na engenharia de software contemporânea, segundo Booch, Rumbaugh e Jacobson (2005), adota-se uma perspectiva orientada a objetos, onde a UML (Unied Modeling Language ) é empregada.

(35) 32 para a visualização, a especicação, a construção e a documentação de artefatos que orientam o desenvolvimento do software. No contexto de ensino de modelagem de software, Brooks (2010) arma que modelar é importante; e ensinar a modelar é tão importante quanto, pois existem grandes lacunas em cada disciplina de modelagem. Tais lacunas tornam-se evidentes quando se tenta ensinar aos estudantes como conduzir a implementação partindo de modelos formais.. 3.1 Barreiras de Modelagem Conforme apresentado na introdução deste trabalho, Brooks (1987) classica as atividades no processo de desenvolvimento de software como tarefas acidentais e essenciais. As barreiras que as tarefas acidentais estabelecem estão sendo transpostas com as constantes inovações de técnicas, ferramentas e processos.. As barreiras impostas pelas. atividades essenciais ainda não foram superadas e, segundo o autor, poucas iniciativas contribuem para aliviar os problemas causados pela complexidade do software. McConnell (2004) denomina esta complexidade de problema perverso.. Para o. autor, um problema perverso é aquele que precisa ser resolvido uma vez, para ser dendo claramente, e depois resolvido novamente, de modo a ser gerada uma solução que funcione temporariamente até surgir uma nova necessidade. O desao do professor é apresentar conceitos e propor problemas que desenvolvam competências e habilidades para que o aluno aprenda a lidar com os aspectos essencias da produção de software. Abordagens de ensino com foco em linguagens de programação ou ambientes de desenvolvimento não atacam aspectos essenciais.. Isso torna difícil a. construção e formalização de um plano mental para o domínio do problema e da solução, para posterior implementação. Em outra pesquisa realizada pelo autor deste trabalho (não publicada), constatouse que, das competências e habilidades estabelecidas pelas diretrizes Brasil (2008) para os cursos de Análise e Desenvolvimento de Sistemas, apenas 20% são classicadas como essenciais (Apêndice B), ou seja, que capacitam o aluno para lidar com a complexidade em se produzir código escalável e manutenível. Brooks (1987), elenca quatro aspectos essenciais que impactam na produção do software, e consequentemente, no ensino de programação. São eles: complexidade, conformidade, exibilidade e intangibilidade..

(36) 33. 3.1.1 Complexidade Entidades de software possuem uma natureza complexa, e aumentar sua escala não é meramente repetir os mesmos elementos em tamanho maior. É necessário um aumento do número de elementos diferentes, o que amplica a complexidade do todo de forma não linear. Tentar criar modelos que abstraiam essa complexidade elimina aspectos essenciais do modelo, dando origem a outro modelo e não mais àquilo que se quer modelar, perdendo sua integridade conceitual. Vega (2011) classica a programação de software em três tipos: (i) Programação. hobby ; (ii) Programação de softwares pequenos e (iii) Programação colossal. As diferenças entre os tipos estão relacionadas às variáveis: número de pessoas envolvidas, o objetivo que se espera do software (experimental, para atender requisitos do cliente ou respeitar restrições) e o nível de gerenciamento imposto ao processo de desenvolvimento (versionamento, manutenção, reuso, escalabilidade e testes). Cada tipo de software tem maior ou menor impacto nestas variáveis. No contexto atual de ensino de programação dicilmente alcança-se a Programação de softwares pequenos ou colossais para que o aluno vivencie a complexidade de se produzir softwares (VEGA, 2011). A Figura 10 exibe os impactos da complexidade na produção de um software.. Figura 10: Impactos da complexidade no desenvolvimento de um software. Observa-se na Figura 10 que, da complexidade surgem as diculdades de entendi-.

(37) 34 mento do que está sendo produzido, impactando na comunicação entre os membros da equipe de desenvolvimento. Como consequência pode ocorrer deciência do produto. Essa diculdade de entendimento bem como a deciência aumentam os custos afetando o cronograma e a conabilidade no software produzido. Destes fatores vem a diculdade de se entender o comportamento do software e ampliá-lo sem criar efeitos colaterais, tornando árdua a atividade de gerenciar esse trabalho. As restrições de tempo, custo e qualidade, além das diculdades de comunicação em equipe e de gerenciamento dos recursos, aumentam a complexidade e elevam o software para a categoria de Programação colossal.. Expor o aluno a este contexto torna-se um. desao a ser vencido.. 3.1.2 Conformidade e Flexibilidade Outras áreas do conhecimento também lidam com a complexidade crescente, porém, o software não está suscetível às leis naturais e, portanto, é visto como algo exível e de fácil adequação. Entre mudar aspectos que regem a Física, a Mecânica, a Economia ou os negócios, o software é considerado o de mais fácil adequação e conformidade ao uso. Em decorrência da sua complexidade, a versão inicial de um software muitas vezes não atende aos requisitos exigidos em sua plenitude, necessitando de constantes mudanças. Brooks (1987) arma que todo software de sucesso acaba por ser modicado. Logo, um sistema de software deve ser concebido para mudar.. 3.1.3 Intangibilidade Software é intangível; portanto, torna-se difícil criar uma representação visual objetiva e comum para ele.. Ao tentar diagramar uma estrutura de software, descobre-se. que ela não é composta por apenas um, mas sim, por vários diagramas superpostos uns aos outros, sem hierarquias ou relações diretas entre seus elementos, forçando cortes que eliminam conexões nas diferentes visualizações do modelo. Para Brooks (1987), ocorreu um progresso na simplicação das estruturas de software.. Embora os modelos permitam dimensionar seu grau de granularidade, continua. sendo difícil sua representação visual, pois os cortes em diferentes modelos prejudicam não só o processo de design do software, mas também a comunicação entre os membros da equipe de desenvolvimento..

(38) 35. 3.2 Notação UML A presente pesquisa investigou o uso do Modelo de Máquina de Estados visando à contribuição ao código gerado pelo aluno de graduação. No processo de ensino-aprendizagem, os modelos podem contribuir para representar gracamente abstrações de modelos do espaço do problema, da implementação (solução) e da computação. Uma das técnicas para criar abstrações de modelos é a UML (Unied Modeling Language ). A UML nasceu como uma linguagem padrão para elaboração de projetos de software, linguagem esta que permite a visualização, especicação, construção e documentação de artefatos utilizados na produção dos sistemas de softwares.. Trata-se de uma. linguagem expressiva que abrange todas as visões do modelo de software necessárias para sua concepção, implementação e manutenção (BOOCH;. RUMBAUGH; JACOBSON,. 2005).. O vocabulário da UML é composto por itens, relacionamentos e diagramas. Os itens são abstrações de primeira ordem em um modelo e são classicados em: itens estruturais, itens comportamentais, itens de agrupamentos e itens notacionais. Itens estruturais e comportamentais são respectivamente, representações estáticas e dinâmicas dos modelos, devidamente organizados por itens de agrupamentos e explicados por itens anotacionais (comentários). A UML é composta por representações grácas de um conjunto de elementos denominados Diagramas. Os diagramas exibidos na Tabela 1 são formas de representar os diferentes aspectos de um modelo de software.. 1. Diagrama de classes 2. 3. 4. 5. 6. 7.. Diagrama de Diagrama de Diagrama de Diagrama de Diagrama de Diagrama de. objetos componentes estruturas compostas casos de uso sequência comunicações. Diagramas 8. Diagrama de grácos de estados ou máquina de estados 9. Diagrama de atividades 10. Diagrama de implantação 11. Diagrama de pacotes 12. Diagrama de temporização 13. Diagrama de visão geral da interação. Tabela 1: Diagramas da UML 2.0. Parte dos diagramas são representações da estrutura do modelo dando enfâse à organização do código, e parte são representações comportamentais, dando enfâse à dinâmica do sistema. Cada diagrama captura aspectos importantes do sistema, mas são necessários mais de um diagrama para a elaboração de uma descrição completa..

(39) 36. 3.3 Quadrantes de Modelagem Embora a UML ofereça treze diagramas para representação de modelos de software, Vega (2011) apresenta uma abordagem para o ensino de modelagem que adota um subgrupo de diagramas UML, composto por: Diagrama de Classe (DCL), Diagrama de Objetos (DOB), Diagrama de Sequência (DSM), Diagrama de Máquina de Estados (DME) e Diagrama de Atividades (DAT). Com este subgrupo, o aluno é capaz de descrever modelos estruturais e comportamentais do software usando a UML. Nota-se então que a UML, no processo de ensino-aprendizagem, pode auxiliar o aluno a criar e representar abstrações de software sem a necessidade de conhecer uma linguagem de programação. A partir desta premissa, o foco do ensino passa a contemplar a concepção mental da descrição de um modelo que atenda a um conjunto de requisitos. O resultado desse momento é considerado por Brooks (1987) como a essência para se lidar com a complexidade do software. A abordagem sobre os Quadrantes de Modelagem é representada gracamente na Figura 11.. Figura 11: Quadrantes de modelagem. Observa-se na Figura 11 que elementos como. código e computação são propostos. para uma classicação didática dos diagramas. Neste caso, um diagrama pode expressar.

(40) 37 1. um modelo de estrutura descritiva do código e de sua manifestação . O mesmo ocorre com os diagramas comportamentais, que podem representar comportamentos descritivos do código ou comportamentos de sua manifestação, a computação. Os Quadrantes de Modelagem permitem observar se um modelo está ou não completo.. Por exemplo, caso seja produzido um DME em conjunto com o DAT, embora. existam duas vistas do código, observa-se apenas a parte da descrição do comportamento do modelo. A manifestação deste código e as vistas estruturais não foram concebidas; logo, uma implementação em linguagem de programação deste modelo pode apresentar um comportamento inesperado. O uso dos diagramas da UML como recurso de modelagem nos diferentes quadrantes possibilita que o aluno crie abstrações do domínio do problema (análise) e do domínio da implementação (design e codicação). Os diagramas também guiam o estudante na organização das linhas de códigos que atendam aos princípios básicos de modelagem. Como suporte ao ensino nos diferentes quadrantes, pode-se utilizar o BlueJ, que possui como função nativa a elaboração do DCL. Östling (2004) desenvolveu uma extensão para o BlueJ que permite a elaboração do DSM. O presente trabalho de pesquisa tem como um de seus objetivos especícos a publicação de uma extensão que permita a construção de DMEs, dando condições para que o aluno descreva modelos dos quadrantes I, II e IV. Nas seções 3.3.1 e 3.3.2 será detalhada a contribuição para o ensino da abordagem dos diagramas nos quadrantes de modelagem.. 3.3.1 Modelos de Manifestação Segundo Vega (2011), os modelos criados na programação estruturada e a computação gerada por um código que os descreve são passíveis de inferência. Na programação orientada a objetos, o modelo estático (Descritivo) não corresponde ao modelo dinâmico (Manifestação), ou seja, nem todos os aspectos capturados no modelo implementado pelo código aparecem nos modelos que descrevem a computação. Por exemplo, itens de agrupamento da UML que registram decisões na relação entre classes e são representados nos modelos descritivos (estáticos) não são representados no modelo da computação. Da mesma forma, decisões arquiteturais também possuem representações diferentes nos modelos descritivos (estáticos) e de manifestação (dinâmico). 1É. o resultado da execução das instruções do código fonte (VEGA, 2011).

(41) 38 Para a modelagem orientada a objetos, a UML possui um conjunto de diagramas que ajuda nas representações da computação.. Vega (2011), nos quadrantes de mode-. lagem III e IV, classica o DOB e o DSM como ferramentas de modelagem estrutural e comportamental da computação. O DOB é um diagrama que mostra um conjunto particular de objetos e suas ligações em determinado instante do tempo.. Tem relação direta com algumas classes. denidas no DCL, diferente do DSM, que, além de mostrar um conjunto particular de objetos, apresenta a ordem de instanciação de classes concretas denidas em um DCL, assim como o uxo de mensagens entre objetos. A ferramenta Sequence Diagram Editor, proposta por Östling (2004), permite representar, por um DSM, instância especíca de um projeto BlueJ; logo, é possível extender a funcionalidade do BlueJ para dar suporte ao ensino do DCL (nativo) e DSM.. 3.3.2 Modelos Descritivos Pode-se observar na Figura 11 que os quadrantes descritivos (I e II) são classicadores do DCL (Quadrante I), DAT e DME (Quadrante II). Ambos estão relacionados à descrição do modelo do código, sob a perspectiva estrutural e comportamental. O DAT auxilia o aluno a representar um comportamento por meio de passos computacionais (procedimental). Uma sequência de passos computacionais em execução atenderá a um requisito. Este diagrama induz o aluno a pensar em dois elementos simultaneamente: os. passos computacionais e a sequência em que eles devem ocorrer.. A relação do DME com o DAT é de ordem temporal, sendo que o DME determina os passos computacionais, mantendo o foco na sequência e os reexos nos objetos que estão sendo modelados. Encontrar passos computacionais e a sequência em que eles ocorrem não atacam a complexidade crescente do código fonte.. Tem-se agora um problema de. outra natureza que o DCL auxilia a resolver: a organização das linhas de código. A abordagem de ensino com o apoio dos diagramas destes quadrantes permite que o aluno mantenha o foco apenas nos elementos pertinentes ao ponto de vista que está modelando; sendo assim, ora o estudante observa e obtém elementos separadamente, ora manipula o modelo descritivo completo (algoritmo, sequência e organização do código)..

(42) 39. 3.4 Modularização Sabe-se que um dos fatores que aumenta a complexidade no desenvolvimento do software é o seu entendimento completo, seja conceitual ou no nível de implementação de um sistema. Parte desta diculdade está relacionada ao crescente número de linhas de código e seu entrelaçamento. Historicamente, na área da computação, diferentes desaos surgem e algumas técnicas são apresentadas a m de resolvê-los. Uma importante técnica com foco na organização do código é a Modularização (PARNAS, 1972). Esta técnica propõe a divisão do sistema em partes de programas. A modularização inclui decisões que devem ser tomadas antes de se iniciar o desenvolvimento dos módulos. Todas as decisões dos níveis de sistema devem ser descritas, pois podem afetar mais de um módulo. Para Parnas (1972), as decisões de modularização devem ser tomadas com os seguintes objetivos: - Redução do tempo de desenvolvimento, pois um ou mais grupos podem trabalhar em cada módulo; - Ganho de exibilidade, uma vez que será possível efetuar grandes mudanças no módulo sem a necessidade de se alterar outros módulos; - Facilidade de compreensão do sistema, pois será possível estudar o módulo separadamente. Atualmente, os Padrões de Projeto (GAMMA. et al.,. 1995) e os princípios de mod-. elagem (MARTIN, 2008) visam à modularização apoiados em critérios de separação por responsabilidades, por conceitos, por comportamentos e por níveis de abstrações, dando origem a uma arquitetura favorável à manutenção, reuso e escalabilidade. O uso de modelos favorece o entendimento parcial ou integral dos módulos e seus relacionamentos. No contexto desta pesquisa investigou-se o uso do Modelo de Máquina de Estados como critério inicial de modularização.. 3.5 Odores e Heurística do Software A hipótese que fundamenta este trabalho de pesquisa é a de que o Modelo de Estados, representado pelo Diagrama de Máquina de Estados, pode ser utilizado no ensino de modelagem de software visando maior qualidade do código. Para corroborar esta.