Técnicas de simulação são utilizadas nas disciplinas de engenharia por muitos anos. Há várias áreas nas quais o uso de simuladores pode auxiliar na Engenharia de
Software, como por exemplo: avaliação do custo de desenvolvimento do software,
trade-offs entre atributos de qualidade, avaliação de requisitos não funcionais,
educação de engenheiros de software, gerenciamento de risco, melhoria de processo e gerenciamento de aquisição (COLLOFELLO, 2000).
Simuladores também podem auxiliar a visualização dos aspectos dinâmicos de uma arquitetura. Essa visualização da arquitetura em execução é útil para se identificar falhas no projeto arquitetural, tais como, pontos de gargalos, esgotamento de recursos, vazamento de memória e baixo desempenho. Simulações feitas durante o processo de definição e projeto da arquitetura também representam uma alternativa de baixo custo em relação à implementação definitiva (BARBER; HOLT, 2001).
No roteiro, os simuladores também foram utilizados para que os alunos aprendam técnicas de desacoplamento entre os componentes de uma arquitetura, em cenários nos quais um componente, apesar de não estar pronto, já possuía sua interface definida. Alguns exemplos de técnicas para a implementação de simuladores que foram utilizadas no roteiro: loopbacks13 em conexões com bancos de dados,
classes provedoras de autenticação e web services de pagamento, etc.
De acordo com Naraharisetty e Vanka (2012), do ponto de vista pedagógico, técnicas de simulação permitem a experimentação mais profunda do conhecimento aprendido, dado que se trata de um ambiente sem risco, propiciando maior absorção dos conceitos.
Princípio 6 - Métricas de requisitos não funcionais
Métricas de software são reconhecidas tanto por pesquisadores e educadores em Engenharia de Software como de grande importância para melhorar o processo de desenvolvimento de software e, consequentemente, o sistema resultante. Infelizmente, a prática na indústria não dá o devido valor às métricas que, comumente, são ignoradas, e a avaliação da qualidade é trabalhada de uma forma instintiva e subjetiva (THOMAS, 1996). Como os requisitos não funcionais são determinantes para a qualidade final do sistema gerado, é de certa forma surpreendente que a
13 Loopback: conexão através do protocolo Transmission Control Protocol (TCP) para a própria máquina que originou a conexão,
medição desses requisitos seja ignorada durante o desenvolvimento e/ou manutenção do software (PASTERNAK, 2003).
Princípio 7 - Testes arquiteturais
Durante a aplicação do roteiro, são realizados testes dos requisitos funcionais e não funcionais utilizando o conceito definido em Clements et al. (2011), no qual os testes são baseados nos cenários arquiteturais que mapeiam os requisitos de qualidade. Ferramentas de testes automatizados, como, por exemplo, o JMeter, criado pela The Apache Software Foundation (2013), para realização de testes de carga também são previstas no roteiro para a realização de testes arquiteturais.
Princípio 8 - Utilização de táticas arquiteturais
Uma tática arquitetural representa uma decisão de projeto que influencia a obtenção da resposta de um atributo de qualidade. Táticas afetam diretamente a resposta do sistema a alguns estímulos. Táticas são selecionadas de acordo com o requisito não funcional a ser considerado na arquitetura (KIM et al., 2008).
O foco de uma tática arquitetural está restrito à resposta de somente um atributo de qualidade, ou seja, não há trade-offs no contexto de uma tática (BASS; CLEMENTS; KAZMAN, 2012). Os trade-offs impostos pelas escolhas de diversas táticas arquiteturas devem ser feitos pelo arquiteto, baseado na criticidade dos processos de negócio. No roteiro, os alunos definem as táticas conforme o ponto de vista da Engenharia do RM-ODP e as implementam usando mecanismos conforme o ponto de vista de Tecnologia.
Princípio 9 - Trabalho em equipe
Uma organização atinge níveis mais elevados de maturidade quando atividades individuais se tornam atividades de uma equipe (FAVELA; PEÑA-MORA, 2001). Como o desenvolvimento de software tem se globalizado, a proposição de uma abordagem educacional deve considerar experiências em grupo, as quais certamente os estudantes enfrentarão em suas vidas profissionais.
Conforme Paula Filho (2001), um processo educacional em Engenharia de Software deve expor o aluno a normas e padrões largamente reconhecidos. Como nas demais Engenharias, os estudantes devem conhecer e aplicar notações e seguir procedimentos padronizados para as atividades de Engenharia de Software. O roteiro proposto utiliza as normas ISO/IEC 10746-1, ISO/IEC 9126, ISO/IEC 14598-5, apresentadas respectivamente nos itens 2.4, 2.7.1 e 2.7.2. Além dessas normas, o método de avaliação de arquitetura de software ATAM, descrito no item 2.11, também foi utilizado no roteiro.
Princípio 11 - Aspectos culturais envolvidos
Um grande desafio educacional é a integração de várias disciplinas de forma coesa, visando uma formação multidisciplinar dos engenheiros de software. Sem abandonar o aspecto técnico e sistemático característico da engenharia, uma formação mais abrangente, que enfatize importantes aspectos como modelagem do processo de negócio, habilidades humanas de comunicação e expressão, noções de gerenciamento de pessoas e projetos poderia indubitavelmente contribuir na formação de engenheiros mais preparados para assumir cargos de liderança nas mais diversas áreas (YEH, 2002). Segundo o Currículo de Engenharia de Computação proposto pelo IEEE e pela ACM, é esperado do engenheiro de computação uma formação multidisciplinar, uma vez que a maioria dos projetos de que o aluno de Engenharia da Computação participará em sua vida profissional envolvem pessoas de várias áreas, ou seja, são multidisciplinares por natureza (ACM/IEEE-CS JOINT TASK FORCE ON COMPUTING CURRICULA, 2004). Por meio de projetos práticos realizados por uma equipe, o roteiro expõe os alunos a um ambiente de características multidisciplinares, uma vez que envolve desafios de natureza técnica, humana, cultural e organizacional.
Essa abordagem muitas vezes enfrenta resistências culturais por parte dos alunos, que segundo Callahan e Pedigo (2002), deve-se à falta de experiência prática dos estudantes. Uma das formas de se lidar com este problema é adotar uma estratégia educacional que auxilie os alunos na percepção de que a prática da Engenharia de Software deve transcender o tecnicismo puro e interagir com outras disciplinas, formando um engenheiro capaz de liderar processos, projetos e pessoas de forma harmoniosa. O roteiro proposto, através de atividades relacionadas ao processo de negócio, à tomada de decisões baseadas em trade-offs, ao
desenvolvimento de mecanismos arquiteturais para a obtenção de qualidade e ao trabalho em equipe demanda uma atitude multidisciplinar dos alunos, buscando amenizar as resistências culturais que surgem no decorrer das aulas.
Princípio 12 - Abordagem prática
Pesquisadores da área de educação, McCaslin e Lowman, (1995) e Schank e Cleary (1995) afirmam que o processo de aprender fazendo, do inglês learn by doing, é um fator muito importante para a eficácia do processo de aprendizado. Exemplos práticos, ou seja, implementações arquiteturais utilizadas na resolução de um problema real, auxiliam no melhor entendimento dos conceitos de qualidade de arquitetura de software, elucidam os trade-offs entre atributos de qualidade, além de relacionar os conceitos teóricos a uma instância concreta de uma arquitetura.
No roteiro proposto, dada a restrição da duração das disciplinas (em torno de 15 aulas de 4 horas cada), são utilizados sistemas já prontos, para que o aluno possa avaliar a qualidade da arquitetura desse sistema e implementar melhorias.