Um estudo de avaliação e documentação de arquiteturas de software na indústria

Texto

(1)Universidade Federal do Rio Grande do Norte Instituto Metrópole Digital Programa de Pós-graduação em Engenharia de Software Mestrado Profissional em Engenharia de Software. UM ESTUDO DE AVALIAÇÃO E DOCUMENTAÇÃO DE ARQUITETURAS DE SOFTWARE NA INDÚSTRIA. Júlio Cesar Leoncio da Silva. Natal-RN Agosto / 2016.

(2) Júlio Cesar Leoncio da Silva. Um Estudo de Avaliação e Documentação de Arquiteturas de Software na Indústria. Dissertação de Mestrado apresentada ao Programa de Pós-graduação em Engenharia de Software da Universidade Federal do Rio Grande do Norte como requisito para a obtenção do grau de Mestre em Engenharia de Software.. Orientador: Uirá Kulesza Coorientador: Felipe Alves Pereira Pinto. Natal-RN Agosto / 2016.

(3) Universidade Federal do Rio Grande do Norte - UFRN Sistema de Bibliotecas - SISBI Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede. Silva, Júlio Cesar Leoncio da. Um estudo de avaliação e documentação de arquiteturas de software na indústria / Júlio Cesar Leoncio da Silva. - 2016. 76 f.: il. Dissertação (Mestrado) - Universidade Federal do Rio Grande do Norte, Instituto Metrópole Digital, Programa de Pós-graduação em Engenharia de Software. Natal, RN, 2016. Orientador: Prof. Dr. Uirá Kulesza. Coorientador: Prof. Dr. Felipe Alves Pereira Pinto.. 1. Arquitetura de computadores - Dissertação. 2. Arquitetura de software - Dissertação. 3. Avaliação arquitetural Dissertação. 4. Desempenho - Dissertação. 5. Documentação arquitetural - Dissertação. 6. Requisitos não-funcionais Dissertação. I. Kulesza, Uirá. II. Pinto, Felipe Alves Pereira. III. Título. RN/UF/BCZM. CDU 004.2.

(4) Júlio Cesar Leoncio da Silva. Um Estudo de Avaliação e Documentação de Arquiteturas de Software na Indústria. Trabalho aprovado. Natal-RN, 25 de Agosto de 2016:. Uirá Kulesza Orientador. Felipe Alves Pereira Pinto Coorientador. Fernando Marques Figueira Filho Convidado Interno. Eduardo Martins Guerra Convidado Externo. Natal-RN Agosto / 2016.

(5) Dedico este trabalho ao meu pai Júlio, minha mãe Gilda e à minha esposa Josiane..

(6) Agradecimentos Os agradecimentos principais são direcionados: À Deus, que sempre me dá a força necessária para enfrentar os desafios do dia-a-dia e não permitindo que eu desista dos meus sonhos perante os obstáculos encontrados pelo caminho. Aos meus pais que sempre foram formadores do alicerce de minha educação e em todo momento foram os principais incentivadores do meu crescimento pessoal e profissional. À minha esposa Josiane que sempre está ao meu lado me apoiando em todos os momentos. Ao meu orientador Uirá Kulesza que me ajudou e me deu todo o suporte necessário desde o início para a realização desse estudo. Ao meu coorientador Felipe que com suas observações contribuiu significativamente para a evolução deste trabalho. Aos meus amigos do curso que me acompanharam nessa jornada, em especial ao amigo Eduardo Ribeiro que desde o início foi um apoio importante, principalmente nos momentos finais..

(7) “Qualquer homem pode alcançar o êxito, se dirigir seus pensamentos numa direção e insistir neles até que aconteça alguma coisa.” (Thomas Edison).

(8) Resumo Muitas vezes o arquiteto de software responsável pela definição e avaliação da arquitetura de software não consegue estabelecer quais requisitos não-funcionais devem ser priorizados no desenvolvimento de seus sistemas. Com isso, falhas podem ocorrer durante a execução do sistema demandando mais tempo e recursos para que seja corrigido. Em muitos casos, com a inexperiência dos arquitetos ou a necessidade de disponibilização rápida de um sistema, os requisitos não-funcionais não são considerados durante a definição da arquitetura de software e também não é feita a devida documentação da arquitetura, tornando difícil o acesso e entendimento da arquitetura pelos demais integrantes da equipe e dificultando a manutenção de componentes/módulos da arquitetura e respectivos relacionamentos. Este trabalho buscou levantar junto às empresas de software, públicas e privadas, quais as principais estratégias utilizadas na definição e avaliação da arquitetura, principalmente na obtenção e cumprimento dos requisitos não-funcionais, e documentação arquitetural. Nosso estudo contou com a participação de 17 arquitetos de software para responder o questionário proposto. Com a realização do questionário identificamos que os requisitos não-funcionais de desempenho e confiabilidade são os mais importantes a serem atendidos pela arquitetura e que mesmo com a existência de algumas abordagens para a avaliação de arquiteturas, elas não parecem estar bem difundidas e/ou utilizadas entre os arquitetos. Ao tratar especificamente o requisito de desempenho, os arquitetos julgaram que em uma análise de desempenho de um sistema de software a informação mais importante a ser exibida deve ser o tempo de resposta das requisições a um determinado cenário, acompanhado do tempo de execução dos métodos que fazem parte desse cenário. Em relação à documentação arquitetural, a maioria dos entrevistados afirmaram utilizar, no mínimo, algum tipo de documentação no momento de criação de um sistema de software, destacando-se a utilização de diagramas de classe e de componentes como as formas mais comuns de documentação utilizadas pelos arquitetos. Além disso, o trabalho propõe a utilização de um guia que busca auxiliar arquitetos de software na atividade de avaliação do cumprimento dos requisitos não-funcionais pela arquitetura durante a evolução do sistema, priorizando o requisito não-funcional de desempenho. Ao avaliar a aplicação do guia, os entrevistados apontaram a abordagem de análise de logs para identificar os cenários prioritários numa avaliação de desempenho como uma das principais contribuições do guia e que poderia facilitar na identificação e comparação das versões dos seus sistemas. Palavras-chave: Arquitetura de Software, Avaliação Arquitetural, Desempenho, Documentação Arquitetural, Requisitos Não-Funcionais..

(9) Abstract Usually, the software architect responsible for the software architecture definition and evaluation cannot prioritize which non-functional requirements must be prioritized during the development of their systems. Because of that, failures may happen during the system execution requiring more time and resources to fix them. In many cases, due to the inexperience of architects or the need for rapid deployment of a system, the non-functional requirements are not considered in the software architecture definition phase and its documentation is absent or incomplete, making the software architecture difficult to be understood, modified and envolved by other team members. This work investigates the main strategies and techniques used to document software architectures and to evaluate non-functional requirements by existing software development companies. Our study had the participation of 17 software architects to answer the survey. Our work identified that performance and reliability non-functional requirements are the most important to be addressed by the architecture and even with the existence of some approaches to evaluate architectures, they do not seem to be disseminated and used among architects. The architects judged that in a performance analysis of a software system the most important information to be displayed should be the response time of the system scenarios. Regarding architecture documentation, most interviewees stated that they used some kind of documentation. The use of class diagrams and component diagrams are the most common forms of documentation used by architects. Besides that, we propose a guide to help software architects in the task of achieving such non-functional requirements during the evolution of software systems. The proposed guide prioritizes the non-functional requirement of performance. The logs analysis approach to identify priority scenarios in a performance assessment was pointed out as one of the key contributions of the guide and could facilitate the identification and comparison of the versions of their systems.. Keywords: Software Architecture, Architectural evaluation, Performance, Architectural documentation, Non-Functional Requirements..

(10) Lista de ilustrações Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura Figura. 1 – 2 – 3 – 4 – 5 – 6 – 7 – 8 – 9 – 10 – 11 – 12 – 13 – 14 – 15 –. Arquitetura de software . . . . . . . . . . . . . . . . . Visões . . . . . . . . . . . . . . . . . . . . . . . . . . . Etapas do SAAM . . . . . . . . . . . . . . . . . . . . . Um fluxo conceitual da ATAM . . . . . . . . . . . . . Tempo de atuação como arquiteto . . . . . . . . . . . . Participação em projetos como arquiteto . . . . . . . . Tipo de Sistema desenvolvido . . . . . . . . . . . . . . Requisitos não-funcionais . . . . . . . . . . . . . . . . Conhecimento sobre avaliação arquitetural . . . . . . . Utilização de avaliação arquitetural . . . . . . . . . . . Realização de documentação . . . . . . . . . . . . . . . Abordagem para atendimento do RNF de desempenho Fluxo de execução do passo 1 . . . . . . . . . . . . . . Fluxo de execução do passo 2 . . . . . . . . . . . . . . Fluxo de execução do passo 3 . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . .. 21 30 31 34 44 45 45 46 48 48 49 52 56 57 58.

(11) Lista de tabelas Tabela Tabela Tabela Tabela Tabela Tabela Tabela. 1 2 3 4 5 6 7. – – – – – – –. Exemplos de padrões arquiteturais. Táticas de atributo de qualidade . Diagramas Estruturais . . . . . . . Diagramas Comportamentais . . . Distribuição Geográfica . . . . . . Titulação Acadêmica . . . . . . . . Cumprimento de RNFs . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 24 26 28 29 43 44 47.

(12) Lista de abreviaturas e siglas ATAM. Architectural Tradeoff Analysis Method. RNF. Requisito Não-Funcional. SAAM. Software Architecture Analysis Method. SIG. Sistema Integrado de Gestão. SIGAA. Sistema Integrado de Gestão de Atividades Acadêmicas. UFRN. Universidade Federal do Rio Grande do Norte. UML. Unified Modeling Language.

(13) Sumário 1 1.1 1.2 1.3 1.4 1.5 1.6. INTRODUÇÃO . . . . . . . . . Problema Abordado . . . . . . . Limitações de Trabalhos Atuais Justificativa . . . . . . . . . . . . Objetivos . . . . . . . . . . . . . Metodologia . . . . . . . . . . . . Estrutura da Dissertação . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. . . . . . . .. 14 14 15 17 18 19 19. 2 2.1 2.1.1 2.1.2. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. . . . . . . . . . . . .. 21 21 22 24. 2.2. FUNDAMENTAÇÃO TEÓRICA Arquitetura de Software . . . . . Padrões e Estilos Arquiteturais . . . Requisitos não-funcionais . . . . . . Táticas . . . . . . . . . . . . . . . . Documentação Arquitetural . . . . UML 2.0 . . . . . . . . . . . . . . Visões Arquiteturais . . . . . . . . Avaliação de Arquiteturas . . . . . SAAM . . . . . . . . . . . . . . . . ATAM . . . . . . . . . . . . . . . . Survey . . . . . . . . . . . . . . .. 34. 3 3.1 3.2 3.2.1 3.2.2 3.3 3.4 3.5 3.6 3.7 3.8. ESTUDO EXPLORATÓRIO . . . . . . . . . . . . . . . . . . Objetivos do Estudo e Questões de Pesquisa . . . . . . . . . . População e Amostra . . . . . . . . . . . . . . . . . . . . . . . Critério de Inclusão . . . . . . . . . . . . . . . . . . . . . . . . . . Critérios de exclusão . . . . . . . . . . . . . . . . . . . . . . . . . Questionário de pesquisa . . . . . . . . . . . . . . . . . . . . . Meio de Distribuição do Questionário . . . . . . . . . . . . . . Instrumentos de Coleta e Análise de Dados . . . . . . . . . . Análise de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . Limitações do Estudo . . . . . . . . . . . . . . . . . . . . . . . Sumário dos Resultados . . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. . . . . . . . . . . .. 36 36 37 37 37 38 42 42 43 49 50. 4 4.1 4.2. GUIA DE APOIO À AVALIAÇÃO DE RNFS . . . . . . . . . . . . . 51 Abordagem para o RNF de desempenho . . . . . . . . . . . . . . . . 51 Proposta de Aplicação da Abordagem . . . . . . . . . . . . . . . . . . 55. 2.1.2.1. 2.1.3 2.1.4 2.1.5 2.1.6 2.1.6.1 2.1.6.2. 25. 26 27 29 30 30 32.

(14) 4.3 4.4. Avaliação Preliminar do Guia Proposto . . . . . . . . . . . . . . . . . 59 Limitações do Guia Proposto . . . . . . . . . . . . . . . . . . . . . . . 61. 5 5.1 5.2. TRABALHOS RELACIONADOS . . . . . . . . . . . . . . . . . . . . 62 Documentação e Verificação de Arquiteturas de Software . . . . . . 62 Processo de Definição de Arquiteturas de Software . . . . . . . . . . 63. 6 6.1 6.2 6.3. CONCLUSÃO E TRABALHOS Conclusões . . . . . . . . . . . Limitações do Trabalho . . . . Trabalhos Futuros . . . . . . .. REFERÊNCIAS. FUTUROS . . . . . . . . . . . . . . . . . . . . .. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .. . . . .. . . . .. . . . .. . . . .. 66 66 67 67. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69. APÊNDICE A – QUESTIONÁRIO DE PESQUISA . . . . . . . . . 72.

(15) 14. 1 Introdução Ao longo dos últimos anos, o conceito de arquitetura de software tem se tornado bastante importante tanto para a academia quanto para a indústria. A definição e avaliação de uma arquitetura de software é fundamental para o desenvolvimento e evolução de um sistema (BABAR; ZHU; JEFFERY, 2004). A avaliação de arquitetura de software tem sido proposta como um meio para alcançar os requisitos não-funcionais como manutenção e confiabilidade em um sistema. O objetivo da avaliação é analisar se a arquitetura conduzirá aos requisitos não-funcionais desejados. Assim, é possível identificar potenciais riscos e verificar se os requisitos de qualidade foram atendidos no projeto (DOBRICA; NIEMELÄ, 2002). Vários métodos de avaliação de arquitetura tem sido propostos para auxiliar arquitetos e desenvolvedores a estabelecer os requisitos não-funcionais prioritários, assim como definir técnicas para sua análise. A importância da avaliação arquitetural dá-se devido ao impacto que a arquitetura tem no projeto do software. Para definir uma arquitetura, diversos fatores devem ser levados em consideração e observados cuidadosamente, deve-se identificar, por exemplo: (i) quais componentes farão parte da arquitetura; e (ii) quais relacionamentos o sistema realizará com outros componentes ou com outros sistemas. Todos esses fatores de decisão escolhidos são diretamente relacionados com os atributos de qualidade (HARRISON; AVGERIOU, 2013), também conhecidos como requisitos não-funcionais, e que são essenciais para as exigências do sistema e um bom funcionamento dele. Os requisitos não-funcionais são características que o sistema possui, em oposição ao que o sistema faz, como a usabilidade, manutenibilidade, desempenho e confiabilidade. No capítulo seguinte abordaremos com mais detalhes essa definição. A identificação e análise dos requisitos não funcionais de um sistema é uma atividade que tem um papel fundamental na definição da arquitetura e como a própria definição sugere, ela irá proporcionar ao sistema uma maior qualidade caso os mesmo sejam abordados.. 1.1 Problema Abordado Muitas vezes o arquiteto de software responsável pela definição e avaliação da arquitetura não consegue estabelecer quais requisitos não-funcionais devem ser atendidos de forma prioritária no sistema e acaba por não atendê-las no momento da definição da arquitetura. Em muitos casos, seja por desconhecimento dos profissionais, imaturidade da equipe ou pela necessidade de disponibilização rápida de um sistema, os requisitos não-funcionais não são sequer considerados durante a definição da arquitetura de um.

(16) Capítulo 1. Introdução. 15. software. É comum também que os desenvolvedores que lidam com a arquitetura do software desconheçam métodos existentes de definição e avaliação de arquiteturas de software (PATIDAR; SUMAN, 2015) que permitem analisá-las de forma sistemática. Vários métodos para avaliar a arquitetura de software foram criados com diferentes abordagens e técnicas. Os métodos de avaliação arquitetural concentram-se em vários requisitos não-funcionais (RNFs), como a reutilização, disponibilidade, desempenho, facilidade de manutenção, segurança e capacidade de teste. Cada método possui diferentes estratégias para analisar a arquitetura e em estados diferentes no processo de ciclo de vida do software. Diante deste cenário, a ausência de estudos que indiquem se os métodos de avaliação estão, de fato, sendo usados na prática ou de que forma os RNFs são avaliados na arquitetura prejudicam uma afirmação sobre a forma que arquitetos têm avaliado suas arquiteturas de software. Outra atividade que muitas vezes é tratada como algo secundário ou até mesmo ignorada em muitas empresas é a atividade de documentação da arquitetura. Essa atividade é bastante importante no processo de definição da arquitetura, já que não adianta ter uma arquitetura bem definida e atenta aos requisitos não-funcionais, mas que será de difícil acesso e entendimento pelos demais integrantes da equipe por não estar documentada, dificultando a modificação e manutenção de componentes/módulos da arquitetura e respectivos relacionamentos. De acordo com Visaggio (1999), o mantenedor pressionado pelo tempo, muitas vezes, infelizmente, não consegue atualizar a documentação de forma coerente com as modificações realizadas no código. Isto gera inconsistências internas e torna a documentação inadequada para a compreensão do sistema. Com isso, a documentação da arquitetura de software é também essencial para a análise de seus RNFs por permitir: (i) a identificação de módulos críticos do sistema; e (ii) a identificação das interações entre os módulos que podem afetar um dado RNF. Dessa forma, a ausência ou fraca definição e documentação de arquiteturas de software de um sistema podem trazer problemas para o atendimento dos requisitos nãofuncionais, tais como, confiabilidade, manutenibilidade, desempenho, entre outros. É comum também que as equipes de desenvolvimento tenham que lidar com tais problemas em sistemas de software que já estejam em funcionamento. De forma geral, a ausência de documentação traz dificuldades para avaliação da arquitetura.. 1.2 Limitações de Trabalhos Atuais Muito embora possamos encontrar na literatura diversos estudos que foram produzidos nos últimos anos na área de arquitetura de software sobre documentação e avaliação arquitetural, como também de métodos e técnicas para realizar estas tarefas, não encontramos nenhum estudo que seja voltado especificamente para o levantamento da adoção.

(17) Capítulo 1. Introdução. 16. dessas práticas pelos desenvolvedores e empresas de softwares e que descreva como esses processos são de fato realizados, quais as dificuldades encontradas ao se utilizar um ou outro método de avaliação arquitetural ou documentação de arquitetura, como também não encontramos uma formalização dos passos a serem executados para que seja avaliado o cumprimento de requisitos não-funcionais pela arquitetura. O trabalho realizado por Tang et al. (2013), motivado por esta diferença cada vez maior entre o crescente número de linguagens arquiteturais produzidas pela academia e as que, de fato, são adotadas pelas empresas em seus processos de definição arquitetural, realizou um survey investigando quais são as principais necessidades da indústria e qual a opinião sobre as linguagens arquiteturais existentes. O survey foi realizado com 48 arquitetos com experiência no uso de linguagens arquiteturais e levou às seguintes constatações: (i) As linguagens arquiteturais utilizadas na indústria são desenvolvidas na própria indústria, embora sejam inspiradas em linguagens arquiteturais produzidas na academia. (ii) As linguagens arquiteturais devem possuir recursos para apoiar a comunicação entre os stakeholders. Em Melo et al. (2016) é realizado um estudo quali-quantitativo que busca entender como é a percepção de alguns questionamentos acerca da arquitetura de software pelos profissionais da indústria, tais como: linguagens para documentação arquitetural, técnicas para visualização de arquitetura de software, entre outros. Nesse estudo foram consultados 395 profissionais da indústria onde 58 participaram da primeira e segunda etapa do estudo e 337 participaram da última etapa respondendo algumas perguntas relacionadas à visão da indústria sobre temas da arquiteturas de software. Esse estudo levou às seguintes conclusões sobre a opinião da indústria acerca dos conceitos de arquitetura de software: (i) Não existe uma única definição para arquitetura de software, podendo esta ser constituída por diversos aspectos do sistema; (ii) Os profissionais concordam que a documentação arquitetural é uma atividade importante. Contudo, esta atividade depende do escopo de cada projeto, da cultura da empresa e dos profissionais que trabalham nela; (iii) Os profissionais mostraram: não conhecer muitas ferramentas de apoio à atividade de verificação de conformidade arquitetural e suas ferramentas; não ter muito interesse em conhecê-las. No estudo realizado por Clerc, Lago e Vliet (2007) também é conduzido a realização de um survey para identificar as experiências da indústria sobre arquitetura de software. O survey teve a participação efetiva de 107 arquitetos de software e foi realizado na Holanda. Os resultados apontaram que a mentalidade dos arquitetos de software entrevistados é focada na entrega de soluções e no desenvolvimento mínimo da arquitetura de forma específica para cada solução desenvolvida . Com isso, os resultados obtidos apontaram que o conhecimento arquitetural e suas visões arquiteturais ainda não são muito difundidos na indústria mas é amplamente reconhecido pelos entrevistados a importância da arquitetura para a comunicação entre os stakeholders. Embora Tang et al. (2013), Melo et al. (2016) e.

(18) Capítulo 1. Introdução. 17. Clerc, Lago e Vliet (2007) também tenham como objetivo entender a visão da indústria sobre conceitos relacionados à arquitetura de software, nosso estudo buscou identificar quais as principais ferramentas e estratégias utilizadas pelos profissionais da indústria para o entendimento dos requisitos não-funcionais pela arquitetura. No estudo de Oliveira e Nakagawa (2009), a partir da investigação de métodos de avaliação de arquiteturas específicas, como arquiteturas orientadas a serviço e arquiteturas orientadas à aspectos, são estudados dois métodos de avaliação arquitetural, SAAM e ATAM, tais métodos são brevemente descritos no estudo e posteriormente é realizada uma análise sobre o comportamento desses métodos em arquiteturas específicas. Entretanto, mesmo diante desses estudos e recomendações sobre a utilização de métodos existentes de documentação e avaliação arquitetural, neste trabalho buscamos indícios que poucos arquitetos de software de fato utilizam esses métodos já produzidos e recomendados. Um dos motivos da não utilização dos métodos de avaliação arquitetural segundo Babar, Zhu e Jeffery (2004) é a necessidade de recursos organizacionais e esses recursos normalmente acarretam em um custo significativo, por este motivo tal prática é recomendada normalmente para grandes empresas de software. Muitos desses métodos não proveem nenhuma informação sobre os custos da avaliação ou a quantidade de recursos requeridos. Nossa pesquisa busca avaliar tal aspecto, identificando entre os arquitetos de software quais são as estratégias que eles utilizam nas empresas em que gerenciam a arquitetura, procurando saber se é utilizado algum método de definição, avaliação e/ou documentação de arquiteturas de software, quais as principais dificuldades encontradas para utilizar algum dos métodos existentes, entre outros questionamentos acerca desse processo.. 1.3 Justificativa Neste contexto, este trabalho busca levantar quais os principais desafios e dificuldades que os arquitetos e desenvolvedores de empresas de software encontram para a realização das seguintes atividades: 1. Documentar suas arquiteturas de software; 2. Definir estratégias para manter a documentação da arquitetura atualizada; 3. Definir quais técnicas e métodos eles utilizam para avaliação de suas arquiteturas de software no atendimento dos requisitos não-funcionais. Além disso, diante deste levantamento, propomos um guia que auxilie arquitetos e desenvolvedores na atividade de cumprimento do requisito não-funcional de desempenho.

(19) Capítulo 1. Introdução. 18. na arquitetura de sistemas web, considerando o tempo de resposta como propriedade analisada. A motivação principal para a realização desse estudo é a necessidade de entender como é encarada as atividades de avaliação e documentação arquitetural por arquitetos/desenvolvedores em empresas de software, investigando quais as principais técnicas utilizadas e quais são os requisitos não-funcionais que os arquitetos julgam mais relevantes para seus sistemas. Algumas empresas, com a necessidade de lançar um produto rapidamente no mercado, insistem em deixar em nível secundário algumas atividades que são fundamentais para o projeto de software, dando prioridade ao desenvolvimento do sistema sem a realização de uma análise detalhada. Mais cedo ou mais tarde, a fim de contornar problemas ou para evolução do sistema, será necessário realizar uma análise da arquitetura do sistema existente. Além disso, as empresas também possuem dificuldades em definir uma arquitetura de software bem estruturada devido ao desconhecimento dos métodos existentes de avaliação arquitetural. Porém o abandono dessas atividades pode comprometer a execução das funcionalidades ao qual o sistema se propõe a executar. Diante disso, a partir do levantamento de como é realizada essa atividade em algumas empresas, propomos também um guia com técnicas e abordagens que possam auxiliar as empresas de modo que possa servir de apoio no momento do atendimento ao requisito não-funcional de desempenho pela arquitetura.. 1.4 Objetivos Os objetivos principais deste trabalho são: (i) entender como arquitetos e desenvolvedores de software avaliam e documentam arquiteturas de software; e (ii) elaborar um guia de busca ao atendimento do requisito não funcional de desempenho que possa auxiliar o trabalho de tais arquitetos durante esse processo. Os objetivos específicos deste trabalho são: a) Conduzir um estudo qualitativo para entendimento do processo de documentação e avaliação de arquitetura em empresas de software; b) Elaborar um guia com abordagens a serem utilizadas para obtenção do cumprimento do requisito não-funcional de desempenho pela arquitetura a partir dos resultados obtidos no estudo; c) Propor a aplicação do guia proposto em um ambiente real indicando estratégias e ferramentas específicas que se adequam à realidade da empresa..

(20) Capítulo 1. Introdução. 19. 1.5 Metodologia Este trabalho foi desenvolvido seguindo o conjunto de atividades descritas abaixo: a) Revisão bibliográfica para embasamento teórico de trabalhos na área de análise arquitetural e documentação de sistemas existentes; b) Realização de um estudo junto a arquitetos de empresas de software através da aplicação de um questionário a ser respondido por eles sobre as formas como são avaliadas e documentadas suas arquiteturas; c) Proposição de um guia para buscar a obtenção do RNF de desempenho em arquiteturas de software de sistemas web. d) Propôr uma instanciação do guia para ser aplicada no ambiente da Superintendência de Informática (SINFO) da Universidade Federal do rio Grande do Norte. e) Realização de entrevista com arquitetos para obter feedbacks e uma avaliação preliminar do guia.. 1.6 Estrutura da Dissertação A dissertação está dividida em 6 capítulos, incluindo este capítulo introdutório. O capítulo 2 apresenta a fundamentação teórica utilizada na pesquisa. Ele elenca os principais itens necessários e utilizados que permitem a compreensão dos principais termos que cercam a avaliação e a documentação de uma arquitetura. O capítulo 3 descreve de forma detalhada como foi realizado o estudo, o público-alvo da pesquisa, de que forma serão aplicados os questionários e quais serão as perguntas que estarão inseridas na realização dessa pesquisa. Além disso, neste capítulo será realizada a análise dos dados obtidos através da execução dos questionários, organizando as informações de forma que possamos identificar as práticas mais utilizadas e as principais dificuldades informadas pelos arquitetos nas suas respectivas empresas. O capítulo 4 apresenta o guia proposto de técnicas para auxiliar as empresas no momento de buscar o atendimento do requisito não-funcional de desempenho em seus sistemas de software com base nas informações coletadas a partir da aplicação do questionário. Além disso, também será proposta a aplicação do guia em um ambiente real, sugerindo abordagens e ferramentas específicas para a busca do cumprimento do RNF de desempenho pela arquitetura. O capítulo 5 apresenta os trabalhos que, de alguma forma, se relacionam diretamente com o nosso estudo proposto e também destaca possíveis benefícios e/ou desvantagens.

(21) Capítulo 1. Introdução. 20. entre a solução proposta no nosso estudo e os estudos já realizados na área da arquitetura de software. Por último, o capítulo 6 descreve as conclusões que a realização desta dissertação de mestrado possibilitou, assim como também apresentar os trabalhos futuros que esse estudo pode conduzir..

(22) 21. 2 Fundamentação Teórica Este capítulo aborda todos os conceitos relevantes para o entendimento e compreensão do estudo realizado através de pesquisas na literatura sobre os temas inerentes ao trabalho. Dentre os temas que estaremos conceituando, de acordo com a literatura, podemos citar: Arquitetura de software, padrões e estilos arquiteturais, táticas, visões, avaliação de arquiteturas e documentação arquitetural. Para isso, estaremos subdividindo este capítulo em seções que abordem individualmente cada tema em uma seção específica.. 2.1 Arquitetura de Software A partir da década de 70 o termo Arquitetura de Software passou a ser definido por alguns autores e com o aumento dos sistemas tanto em nível de tamanho como em nível de complexidade este termo passou a ser cada vez mais abordado principalmente a partir da década de 90. De acordo com Perry e Wolf (1992), a arquitetura de software é um conjunto de elementos arquiteturais (de dados, de processamento, de conexão) que possuem alguma organização. Os elementos e sua organização são definidos por decisões tomadas para satisfazer objetivos e restrições, a figura 1 procura ilustrar esta fórmula sobre a definição apresentada.. Figura 1: Arquitetura de software Dentre os elementos arquiteturais destacados por Perry e Wolf (1992) estão: a) Elementos de processamento: São elementos que usam ou transformam informação; b) Elementos de dados: São elementos que contêm a informação a ser usada e transformada; c) Elementos de conexão: São elementos que ligam elementos de qualquer tipo entre si. Apesar de organizar os elementos arquiteturais, esta definição não se aproxima muito dos conceitos de software, diferentemente da definição de Shaw e Garlan (1996), onde, de acordo com eles, a arquitetura define o que é o sistema em termos de componentes computacionais e, os relacionamentos entre estes componentes, os padrões que guiam a sua.

(23) Capítulo 2. Fundamentação Teórica. 22. composição e restrições. Através deste conceito eles trazem uma visão mais aproximada de um software. Para eles, arquitetura de software se torna necessária quando o tamanho e a complexidade dos sistemas de software crescem. Assim, o problema de se construir sistemas vai além da escolha dos algoritmos e estruturas de dados, envolvendo outros fatores, tais como: Decisões sobre as estruturas que formarão o sistema, controle, protocolos de comunicação, sincronização e acesso a dados, atribuição de funcionalidade a elementos do sistema, distribuição física dos elementos escalabilidade e desempenho e outros atributos de qualidade; e seleção de alternativas de projeto. Segundo Bass, Clements e Kazman (2003), a arquitetura de um sistema não se resume apenas em identificar quantos elementos o compõem e quais as conexões entre eles. A arquitetura, de acordo com ele, consiste em compreender qual a natureza dos elementos, quais são suas responsabilidades, qual o significado das conexões e qual o significado da disposição dos elementos.. 2.1.1 Padrões e Estilos Arquiteturais Segundo Buschmann et al. (1996), os padrões arquiteturais expressam esquemas de organização estrutural fundamentais para sistemas de software. Eles fornecem um conjunto de subsistemas predefinidos, especificando as suas responsabilidades, e incluindo regras e orientações para organizar a relação entre eles. Padrões e estilos arquiteturais procuram demonstrar a disposição em que os elementos da arquitetura estão organizados, fornece um conjunto de subsistemas predefinidos, especifica responsabilidades e incluindo regras e diretrizes para organizar a relação entre esses subsistemas. Há uma grande quantidade de padrões e estilos disponíveis que podem ser utilizados nos projetos de desenvolvimento de software. Para Broemmer (2003), a utilização de padrões na construção de um software pode significar um grande ganho na corretude do software e, consequentemente, na sua qualidade. Além disso, o entendimento do software por parte dos arquitetos e programadores poderá se tornar mais claro, o que vem a acrescentar um grande benefício no desenvolvimento do projeto de software. Buschmann et al. (1996) apresenta 8 exemplos de padrões arquiteturais listados na Tabela 1: Padrão Arquitetural Layer. Descrição Ajuda a estruturar as aplicações que podem ser decompostas em grupos de subtarefas no qual cada grupo de subtarefa está em um nível particular de abstração. Continua na próxima página.

(24) Capítulo 2. Fundamentação Teórica. 23. Tabela 1 : Exemplos de padrões arquiteturais. Padrão Arquitetural. Descrição. Pipes e Filters. Proporciona uma estrutura para sistemas que processam um fluxo de dados. Cada passo de processamento é encapsulado em um componente de filtro. Os dados são passados através de tubos entre filtros adjacentes. Recombinando filtros permite que você construa famílias de sistemas relacionados.. BlackBoard. Este padrão é útil para os problemas para os quais não são conhecidas as estratégias de solução. No blackboard vários subsistemas especializados montam seu conhecimento para construir uma solução possivelmente parcial ou aproximada.. Broker. pode ser usado para estruturar sistemas de software distribuídos com componentes desacoplados e que interagem por invocações de serviços remotos. Um componente broker é responsável pela coordenação de comunicação, tais como pedidos de encaminhamento, bem como para a transmissão de resultados e exceções.. Model-View-Controller. Divide uma aplicação em três componentes. O modelo contém a funcionalidade do núcleo e dados. A View exibe informações para o usuário. A Controller tem a função de lidar com a entrada do usuário. Views e controllers em conjunto compõem a interface do usuário. Um mecanismo de mudança de propagação assegura a consistência entre a interface do usuário e do modelo. Continua na próxima página.

(25) Capítulo 2. Fundamentação Teórica. 24. Tabela 1 : Exemplos de padrões arquiteturais. Padrão Arquitetural. Descrição. Presentation-Abstraction-Control. Define uma estrutura para os sistemas de software na forma de uma hierarquia de agentes cooperantes. Cada agente é responsável por um aspecto específico da funcionalidade da aplicação e é composto por três componentes: apresentação, abstração e controle.. Mikrokernel. Aplica-se a sistemas de software que deve são capazes de se adaptar aos novos requisitos do sistema. Ele separa um núcleo funcional mínimo de funcionalidade estendida e partes específicas do cliente.. Reflection. Fornece um mecanismo para alterar a estrutura e o comportamento de sistemas de software dinamicamente. Ele suporta a modificação de aspectos fundamentais, tais como estruturas do tipo e mecanismos de chamada de função. Tabela 1: Exemplos de padrões arquiteturais.. Outro objetivo dos padrões arquiteturais é a construção de sistemas de software com propriedades não-funcionais já previstas. Os Padrões arquiteturais, portanto, são construídos para atender o desenvolvimento de software, o reuso, a mudança e assim por diante. A escolha do padrão arquitetural deve estar associada ao tipo de sistema e seus requisitos não-funcionais.. 2.1.2 Requisitos não-funcionais Um dos termos bastante utilizados quando tratamos sobre a elaboração de uma arquitetura na engenharia de software é o de requisitos não-funcionais, já que os mesmos podem influenciar na definição do padrão arquitetural que será utilizado conforme a seção anterior. De acordo com Filho (2008), os requisitos não funcionais são aqueles que não estão diretamente relacionados à funcionalidade de um sistema. Para ele, um requisito não funcional de software é aquele que descreve não o que o sistema fará, mas como ele fará. Os requisitos não funcionais são propriedades de produtos através do qual as partes interessadas (stakeholders) julgam a sua qualidade. Dentre alguns dos exemplos de requisitos não-funcionais que os stakeholders podem julgar a qualidade dos sistemas de software.

(26) Capítulo 2. Fundamentação Teórica. 25. podemos incluir: Disponibilidade, usabilidade, interoperabilidade, configurabilidade, desempenho, segurança, manutenibilidade, confiabilidade, portabilidade, etc. O grau em que um sistema de software atende as suas exigências de requisitos não-funcionais depende de sua arquitetura Assim, decisões arquiteturais são feitas para promover vários requisitos não-funcionais e uma mudança na arquitetura para atender um requisito não-funcional, muitas vezes poderá afetar outros requisitos não-funcionais. Então, atingir os requisitos não-funcionais só pode acontecer através de uma escolha racional da arquitetura. Para Sommerville (2009), os requisitos não funcionais, como o próprio nome sugere, são requisitos que não são diretamente os serviços prestados pelo sistema para seus usuários. Os requisitos não funcionais são muitas vezes mais importantes do que os requisitos funcionais. Os usuários do sistema podem geralmente encontrar maneiras de contornar uma funcionalidade do sistema que realmente não atenda às suas necessidades. No entanto, deixando de atender a um requisito não-funcional pode significar que todo o sistema é inutilizável. Por exemplo, se um sistema de aeronaves não cumprir os seus requisitos de confiabilidade, ele não vai ser certificado como seguro para a operação e se tornará inutilizável. Ainda de acordo com Sommerville (2009) os requisitos não-funcionais podem ser classificados em: 1. Requisitos de produto: Define o comportamento e qualidade do produto; 2. Requisitos organizacionais: Relaciona à qualidade do projeto; 3. Requisitos externos: Abrange os comportamentos emergentes com a integração com outros sistemas. Na figura abaixo podemos identificar como está organizada essa classificação: Os requisitos não funcionais têm um papel de suma importância durante o desenvolvimento de um sistema, podendo ser usados como critérios de seleção na escolha de alternativas de projeto, estilo arquitetural e forma de implementação. (FILHO, 2008). 2.1.2.1 Táticas Uma tática é uma decisão de concepção que influencia o controle de um atributo de qualidade. Uma coleção de táticas pode ser chamada de estratégias arquiteturais. (BASS; CLEMENTS; KAZMAN, 2003). Uma tática arquitetural consiste em um conhecimento mais abstrato, utilizado principalmente para auxiliar o atendimento a um tipo de requisito de qualidade. Portanto, por serem mais abstratas, essas táticas descrevem principalmente possíveis características que uma arquitetura deve apresentar para atender a um determinado tipo de requisito. (SPíNOLA, 2008)..

(27) Capítulo 2. Fundamentação Teórica. 26. Para Harrison, Avgeriou e Zdun (2010), as táticas são implementadas como funcionalidades, cada tática tem um design (que é geralmente decomposta em componentes), conectores (interligando os componentes) e um comportamento que deve ser requerido. Dessa forma, segue-se que a estrutura e o comportamento de uma tática impactam diretamente sobre a estrutura e o comportamento do sistema. Segundo Sabry (2015), as táticas são medidas tomadas para melhorar os atributos de qualidade. A tática pode ser facilmente implementada usando estruturas como um padrão de arquitetura em particular. Consequentemente, uma tática pode exigir uma significativa refatoração na estrutura de comportamento do padrão ou então aplicar novas estruturas ou comportamentos inteiros. Nesse caso, a aplicação da tática será mais difícil e exigirá um esforço maior de testes. Desta forma podemos dizer que as táticas podem ser encaradas como decisões arquiteturais tomadas pelo arquiteto e que irão influenciar a resposta dada por um sistema com relação a um ou mais atributo de qualidades. Na tabela 2 podemos listar algumas táticas que podem ser utilizadas de acordo com o atributo de qualidade ao qual está relacionado. Atributo de qualidade Confiabilidade Desempenho. Usabilidade Segurança. Manutenibilidade Portabilidade. Táticas Ping/echo, Heartbeat, Exceções. Reduzir overhead computacional, Aumentar a disponibilidade de recursos, escalonamento. Manter modelos: da tarefa, do usuário, do sistema, separar a interface da aplicação. Autenticar usuários, limitar acessos, confidencialidade dos dados, detecção de intrusão. Coerência semântica, separar a interface da aplicação, ocultação de informação. Linguagens, bibliotecas e mecanismos de persistência capazes de rodar em diferentes plataformas operacionais.. Tabela 2: Táticas de atributo de qualidade. 2.1.3 Documentação Arquitetural A documentação da arquitetura de software é um elemento essencial e parte integrante do processo de projeto de arquitetura e que ajuda os arquitetos a identificar e registrar as decisões de projeto necessárias (SHAHIN; LIANG; KHAYYAMBASHI, 2009)..

(28) Capítulo 2. Fundamentação Teórica. 27. A arquitetura é um exemplo da parte de um software que não é materializável. Durante uma inspeção, por exemplo, é o documento arquitetural que deve ser revisado, por impossibilidade de se inspecionar diretamente a arquitetura projetada. Sendo assim, durante o seu projeto, a arquitetura tem que ser documentada para que ela possa ser usada para os seus devidos fins. (SPíNOLA, 2008). Mesmo devido a essa importância, a fase de documentação da arquitetura de software é ignorada por algumas empresas. Para Gorton (2011), a documentação da arquitetura muitas vezes é uma questão problemática nos projetos de TI. É muito comum que haja pouca ou nenhuma documentação que cubra a arquitetura nesses projetos. Às vezes, quando há alguma documentação, ela é obsoleta, inadequada e, basicamente, não muito útil. Documentar uma arquitetura de software é uma questão de documentar as visões mais relevantes e, em seguida, adicionar informações que se aplicam a essas visões. Um primeiro passo é escolher as visões mais importantes, e esta escolha, por sua vez depende de utilizações anteriores, ou seja, as visões mais utilizadas serão priorizadas na documentação. A documentação pode ser utilizada para conduzir a análise, para restringir uma implementação, para gerenciar um projeto, ou para transmitir uma visão geral introdutória de um sistema. (CLEMENTS et al., 2002). Ainda de acordo com Clements et al. (2002), a documentação da arquitetura deve servir a propósitos variados. Deve ser suficientemente abstrata, que é rapidamente entendida por novos colaboradores, ela deve ser suficientemente detalhada para que sirva como um modelo para construção e deve conter informação suficiente para que ela possa servir como base para a análise.. 2.1.4 UML 2.0 De acordo com Gorton (2011), UML 2.0 é uma importante atualização da linguagem de modelagem. Acrescenta vários novos recursos que formalizam muitos aspectos da linguagem. Esta formalização ajuda de duas maneiras. Para os designers, elimina ambiguidade dos modelos, ajudando a aumentar a inteligibilidade. Em segundo lugar, suporta o desenvolvimento por modelos, em que modelos UML são usados para a geração de códigos. As notações de modelagem UML 2.0 abrangem aspectos de sistemas de software tanto estrutural e comportamental. Os diagramas estruturais definem a arquitetura de um modelo estático e, especificamente, podem ser: • Diagrama de classes; • Diagramas de componentes; • Diagrama de pacotes;.

(29) Capítulo 2. Fundamentação Teórica. 28. • Diagrama de implantação; • Diagrama de objetos; • Diagrama de estrutura composta; A tabela 3 detalha um pouco mais sobre cada tipo de diagrama estrutural e expõe suas principais características.. DIAGRAMAS ESTRUTURAIS Diagrama de classes Mostra as classes do sistema e seus relacionamentos. Diagrama de componentes Descreve a relação entre componentes com interfaces bem definidas. Os componentes compreendem normalmente múltiplas classes. Diagrama de pacotes Divide o modelo em grupos de elementos e descreve a as dependências entre eles a um nível elevado. Diagrama de implantação Mostra como componentes e outros artefatos de software como os processos são distribuídos para hardware físico. Diagrama de Objetos Descreve como os objetos são relacionados e usados em tempo de execução. Diagramas de estrutura composta Mostra a estrutura interna das classes ou componentes em termos de seus objetos compostos e seus relacionamentos. Tabela 3: Diagramas Estruturais Diagramas de comportamento mostram as interações e as mudanças de estado que ocorrem como elementos no modelo de execução e são: • Diagrama de atividade; • Diagramas de comunicação; • Diagrama de sequência; • Diagrama de máquina de estado; • Diagrama de visão geral de integração; • Diagrama de tempo; • Diagrama de caso de uso;.

(30) Capítulo 2. Fundamentação Teórica. 29. Já a tabela 4 detalha sobre cada tipo de diagrama comportamental e expõe suas principais características.. Diagrama Diagrama Diagrama Diagrama. Diagrama ção Diagrama. Diagrama. DIAGRAMAS COMPORTAMENTAIS de atividade Utilizado para definir a lógica do programa e processos de negócios. de comunicação Descreve a sequencia de chamadas entre objetos em tempo de execução. de sequência Mostra a sequência de mensagens trocadas entre objetos. e máquina de estado Descreve os detalhes internos de um objeto, mostrando seus estados e eventos, e as condições que causam as transições de estado. de visão geral de integra- Mostra o fluxo de controle através de um número de cenários mais simples. de tempo Descreve vários estados de um objeto ao longo do tempo e as mensagens que alteram o estado do objeto. de caso de uso Mostra as interações entre o sistema e seu ambiente, incluindo usuários e outros sistemas. Tabela 4: Diagramas Comportamentais. 2.1.5 Visões Arquiteturais Talvez o conceito mais importante associado à documentação de arquitetura de software é o conceito de visão. Uma visão é uma representação de um conjunto de elementos arquiteturais e seus relacionamentos (CLEMENTS et al., 2002). Uma visão arquitetural tem como objetivo principal a representação do sistema ou de parte dele da perspectiva de um conjunto de interesses relacionados. A prática de descrever uma arquitetura, usando múltiplos pontos de vista, é um consenso na comunidade de engenharia de software. Um ponto de vista é uma técnica de abstração, que usa um conjunto de conceitos arquiteturais e regras de estruturação, com foco em certos interesses, dentro de um sistema. (PUTMAN, 2001). Penedo e Riddle (1993) reforçam esta ideia, afirmando que uma arquitetura de software deve ser vista e descrita sob diferentes perspectivas (ou visões) e deve identificar seus componentes, relacionamento estático, interações dinâmicas, propriedades, características e restrições. Diante dessas conceituações, uma visão arquitetural procura representar as informações encontradas na arquitetura de forma a se adequar às necessidades de um ou mais.

(31) Capítulo 2. Fundamentação Teórica. 30. interessados, facilitando, assim, o entendimento da arquitetura por parte deles, já que vai ilustrar a informação de acordo com as suas necessidades.. Figura 2: Visões Na figura 2, Clements et al. (2002) utiliza o conceito de visões para ilustrar a importância das visões na documentação de arquiteturas de software. Um pacote de documentação para uma arquitetura de software é composto de várias partes. A principal parte do pacote consiste em um ou mais documentos de visões. O restante é composto por documentação que explica como as visões referem-se umas às outras, apresentando o pacote aos seus leitores, e orientando-os através dele.. 2.1.6 Avaliação de Arquiteturas A avaliação arquitetural é uma técnica ou método que determina as propriedades, pontos fortes e fracos da arquitetura de software, estilo arquitetural ou um padrão de design. Além disso, fornece estratégias que auxiliarão os desenvolvedores de modo que a sua arquitetura escolhida buscará satisfazer os requisitos funcionais e não-funcionais. (SHANMUGAPRIYA; SURESH, 2012). Uma das principais finalidades da avaliação arquitetural consiste em estabelecer uma consistência entre as informações que são encontradas no documento que contém a arquitetura descrita, relacionando-a com a forma que está desenvolvida, implementada, representando uma coesão entre essas informações e atendendo, assim, o que foi especificado para o software/sistema em questão. Podemos identificar como os principais métodos de avaliação de arquitetura, o SAAM e o ATAM. 2.1.6.1 SAAM De acordo com Filho (2009), o método SAAM foi inicialmente concebido com o objetivo de auxiliar arquitetos de software a compararem soluções arquiteturais, tendo.

(32) Capítulo 2. Fundamentação Teórica. 31. sido o precursor de outros métodos de análise arquitetural. O método SAAM compreende os seguintes objetivos: • Definir um conjunto de cenários que representem usos importantes do sistema no domínio, envolvendo os pontos de vista de todos aqueles que possuem papéis influenciadores no sistema. • Utilizar cenários para gerar uma partição funcional do domínio, uma ordenação parcial das funções e um acoplamento dos cenários às várias funções existentes na partição. • Usar a partição funcional e ordenação parcial, juntamente com cenários de uso, a fim de realizar a análise das arquiteturas propostas. Segundo Oliveira e Nakagawa (2009), o SAAM é aplicado no início do ciclo de desenvolvimento e provê ao arquiteto a possibilidade de optar por uma arquitetura com um trade-off aceitável entre os atributos de qualidade. Esse método é composto por cinco principais etapas: desenvolvimento dos cenários, descrição da arquitetura de software, classificação, priorização e avaliação individual de cada cenário, interação entre cenários e avaliação global. Na Figura 3, apresentam-se as etapas do SAAM, bem como os relacionamentos entre as etapas.. Figura 3: Etapas do SAAM O método consiste em cinco passos, começando com a documentação da arquitetura de uma forma que todos os participantes da avaliação consigam entender. Depois, cenários que descrevam o uso pretendido do sistema são criados. Os cenários devem representar os.

(33) Capítulo 2. Fundamentação Teórica. 32. interesses de todos os stakeholders. Os cenários são avaliados e um conjunto que representa os aspectos que devem ser avaliados é selecionado. Cenários que interagem entre si são identificados como uma maneira de medir a modularidade da arquitetura. Os cenários são ordenados de acordo com a prioridade e impacto previsto na arquitetura. (LIMA ADRIANA CARNIELLO, 2014). 2.1.6.2 ATAM ATAM é um método arquitetural baseado em cenários para a avaliação dos atributos de qualidade, tais como: modificabilidade, portabilidade, extensibilidade e integralidade. Além da avaliação dos atributos de qualidade, o método ATAM explora a interação entre os atributos de qualidade e suas interdependências destacando os mecanismos de trade-off entre diferentes qualidades. (IONITA; HAMMER; OBBINK, 2002). Para Pontes e Arakaki (2012), o ATAM é um método de avaliação que estende a análise de sistemas permitindo que ela seja repetível e transacional. Ter um método estruturado ajuda a buscar que as questões importantes sobre a arquitetura são levantadas o mais cedo possível. Durante os estágios de levantamento de requisitos e projeto podem ser descobertos mais cedo são mais baratos para resolver. Esse método guia os stakeholders na observação dos conflitos e para resolução destes conflitos na arquitetura de software. O ATAM é assim chamado porque revela o quão bem um arquiteturas satisfaz seus objetivos particulares de qualidade, e (porque reconhece que decisões de arquitetura tendem a afetar mais de um atributo de qualidade) que fornecem insights sobre como as metas de qualidade interagem. (BASS; CLEMENTS; KAZMAN, 2003). Conforme Kazman, Klein e Clements (2000), o ATAM é um método organizado de análise acerca de estilos arquiteturais que são os principais determinantes de atributos de qualidade da arquitetura. O método centra-se na identificação de objetivos de negócio que levam a metas de atributos de qualidade. Metas baseadas nos qualidade de atributos, usamos a ATAM analisar como estilos arquiteturais ajudam na realização destes objetivos. Os passos do método são como se segue: 1. Apresentar o ATAM: O método é apresentado aos stakeholders (Normalmente, representantes dos clientes, o arquiteto ou equipe de arquitetura, representantes dos usuários, mantenedores, administradores, gerentes, testadores, integradores e etc.). 2. Apresentar motivações de negócio: O gerente de projeto descreve os objetivos de negócio que estão motivando o desenvolvimento e, portanto, quais serão os requisitos arquiteturalmente relevantes (por exemplo, alta disponibilidade ou time-to-market ou alta segurança)..

(34) Capítulo 2. Fundamentação Teórica. 33. 3. Apresentar a arquitetura: O arquiteto irá descrever a arquitetura proposta, focando como ele irá abordar os impulsionadores do negócio. 4. Identificar abordagens arquiteturais: As abordagens de arquitetura são identificadas pelo arquiteto, mas não são analisadas. 5. Gerar árvore de atributos: Os fatores de qualidade que compreendem a "utilidade"(desempenho, disponibilidade, segurança, modificabilidade, etc.) do sistema são extraídas, especificando-os até o nível de cenários, anotando com estímulos e respostas, e priorizando-os. 6. Analisar abordagens arquiteturais: Com base nos fatores de alta prioridade identificados no passo 5, as abordagens de arquitetura que abordam esses fatores são extraídas e analisadas. 7. Brainstorm e priorização de cenários: Com base nos cenários gerados nos exemplares da etapa da árvore de utilidades, um conjunto maior de cenários são elicitados a partir do stakeholders. Este conjunto de cenários é priorizado através de um processo de votação envolvendo todos os stakeholders do grupo. 8. Analisar abordagens arquiteturais: Este passo reitera a etapa 6, mas aqui os cenários mais relevantes no passo 7 são considerados para serem testados para a análise da arquitetura. Estes cenários de caso de teste pode revelar abordagens adicionais de arquitetura, riscos, pontos de sensibilidade e pontos de trade-offs que são então documentadas. 9. Apresentar resultados: Com base nas informações recolhidas (estilos, cenários, questões específicas de atributos, a árvore de utilidade, riscos, pontos de sensibilidade, compensações) a equipe ATAM apresenta o resultado para os stakeholders e, potencialmente, escreve um relatório detalhando estas informações junto com todas as estratégias de mitigação propostas. A figura 4 exibe o fluxo do ATAM onde a arquitetura de software e os elementos de negócio são extraídos a partir de tomadas de decisões de projeto. Estes elementos são refinados em cenários e as decisões de arquitetura que são feitas baseiam-se em cada um dos cenários. A análise dos cenários e decisões resultam na identificação dos riscos, não-riscos, pontos de sensibilidade e pontos de trade-off na arquitetura. Os riscos são sintetizados em um conjunto de temas de risco, mostrando como cada um pode ameaçar os elementos de negócio..

(35) Capítulo 2. Fundamentação Teórica. 34. Figura 4: Um fluxo conceitual da ATAM. 2.2 Survey De acordo com Pfleeger e Kitchenham (2001), os surveys são, provavelmente, o método de pesquisa mais utilizado em todo o mundo. Trabalhos survey são visíveis não só porque vemos muitos exemplos de pesquisa na engenharia de software, mas também porque muitas vezes somos convidados a participar de pesquisas, como eleitores, consumidores, ou usuários de serviços. Ainda de acordo com Pfleeger e Kitchenham (2001), o survey não é apenas o instrumento (questionário ou checklist) para coleta de informações. É um sistema abrangente que recolhe informações para descrever, comparar ou explicar conhecimentos, atitudes e comportamento. Assim, o instrumento de pesquisa é parte de um processo de pesquisa maior com atividades claramente definidas: 1. Definição dos objetivos mensuráveis específicos; 2. Planejamento e programação do survey; 3. Assegurar que os recursos adequados estejam disponíveis; 4. Projetando a pesquisa; 5. Preparação do instrumento de coleta de dados; 6. Validação do instrumento;.

(36) Capítulo 2. Fundamentação Teórica. 35. 7. Seleção dos participantes; 8. Administrando e marcando o instrumento; 9. Análise dos dados; 10. Divulgação dos resultados. Para Groves et al. (2009), osurvey é um método sistemático para recolher informações a partir de (uma amostra de) entidades para efeitos de construção de descritores quantitativos dos atributos de uma larga população de que sejam membros . A palavra "sistemática"é deliberada e significativamente distingue dos levantamentos de informações de outras formas de coleta. A frase "(uma amostra de)"aparece na definição, porque às vezes examina a tentativa de medir todos em uma população e, por vezes, apenas uma amostra..

(37) 36. 3 Estudo Exploratório Este capítulo aborda o estudo conduzido como parte desta dissertação. A Seção 3.1 apresenta os objetivos e questões de pesquisa do estudo. A Seção 3.2 descreve a população e amostra da pesquisa, definindo os critérios de inclusão e exclusão de participantes. A seção 3.3 apresenta o questionário utilizado. Na seção 3.4 é apresentado o meio de distribuição do questionário. A seção 3.5 traz os instrumentos de coleta e análise dos dados. Em seguida, na seção 3.6 os dados são analisados. E, por último, na seção 3.7 é apresentado o sumário dos resultados com as descobertas realizadas com a realização dessa pesquisa.. 3.1 Objetivos do Estudo e Questões de Pesquisa O estudo foi conduzido com o objetivo de compreender como arquitetos e desenvolvedores de empresas de software brasileiras realizam a documentação e a avaliação da arquitetura de seus sistemas de softwares, assim como também identificar as principais ações executadas e dificuldades encontradas durante esse processo. A realização deste estudo nos permitiu investigar questões que são fundamentais para definirmos a proposta que objetiva esse trabalho. .Essas questões são importantes pois conduzirão das informações fornecidas pelos arquitetos • Que estratégias arquitetos usam para lidar com RNFs específicos? • Os métodos de avaliação arquitetural fazem parte de tais estratégias? • Que estratégias arquitetos usam para documentar a arquitetura e manter essa documentação atualizada? • Quais informações arquitetos julgam importantes em um relatório de análise de desempenho? Para isso, nosso estudo envolveu a condução de um questionário com um conjunto de perguntas a serem respondidas por arquitetos de software. Essas perguntas foram separadas em três blocos de tal forma que possamos conhecer um pouco sobre o perfil do profissional que está sendo entrevistado como também a realidade sobre o uso de determinadas técnicas no processo de avaliação e documentação dos sistemas. Mais adiante, apresentaremos detalhadamente as etapas que serão realizadas para a realização desta pesquisa..

(38) Capítulo 3. Estudo Exploratório. 37. 3.2 População e Amostra Para realizar essa pesquisa selecionamos como população do estudo os arquitetos de software de empresas de software, públicas e privadas. Dentre as empresas e instituições públicas que realizamos a entrevista com alguns de seus arquitetos destaca-se à UFRN através da Superintendência de Informática - SINFO, mas também de arquitetos que atuam em outras empresas como: Amazon, E-SIG Software, GE, entre outras. O grupo de estudos que selecionamos como população deste questionário foram usuários participantes do Pangea. O Pangea é uma rede social formada por profissionais e acadêmicos interessados na evolução da arquitetura de software no Brasil. A população selecionada não se limitou apenas à localização geográfica em que o estudo foi realizado, o RN, havendo assim entrevistados de outras cidades e estados na qual podemos citar: DF, PB, MG, RJ, SP. Como também não se limitou apenas no Brasil, havendo entrevistados do Canadá e Irlanda.. 3.2.1 Critério de Inclusão O critério de inclusão utilizado para que o entrevistado esteja apto para contribuir e responder ao questionário é possuir um nível avançado de experiência na área de arquitetura de software. Nessa pesquisa nós adotamos para mensurar o nível de experiência do entrevistado três critérios: • A quantidade de anos atuando como arquiteto de software. • A quantidade de projetos que já tenha atuado no papel de arquiteto de software. • A recomendação através de outros arquitetos que tenham atingido os critérios anteriores. A escolha por esse perfil está diretamente relacionada à facilidade que esses arquitetos possuem para identificar e apresentar as informações necessárias para responder os questionamentos acerca de avaliação e documentação arquitetural, expondo sua experiência nos processos em questão.. 3.2.2 Critérios de exclusão O critério utilizado para exclusão de entrevistado também se dá em relação ao nível de experiência do entrevistado em arquitetura de software, excluindo os que, porventura, não tenham preenchido os pré-requisitos da seção anterior. Arquitetos de software com pouca experiência poderiam não ter uma informação precisa sobre os questionamentos levantados e poderiam comprometer o estudo por não conter uma bagagem considerável que pudesse contribuir com a pesquisa..