E.1 Quem são os interessados em um sistema de software?
É comum termos como principais interessados no ciclo de vida de um software os seus usuários e desenvolvedores. Acontece que eles não são os únicos envolvidos ou, ao menos, são grupos homogêneos em termos de interesses e necessidades. Entretanto, para termos um ponto de partida, vamos considerar um cenário em que existem apenas esses dois grupos e algumas simplificações. Nesse cenário, eles ambos os grupos são homogêneos, ou seja, todos os usuários e desenvolvedores apresentam os mesmos interesses e necessidades, e os usuários se encarregam de impor as necessidades, enquanto os desenvolvedores cuidam para que essas necessidades sejam alcançadas através do produto de software. Para montarmos esse cenário, vamos partir de um sistema parecido com o nosso estudo de caso e, pouco a pouco, retirar interesses e necessidades dos envolvidos para observar suas influências no software e em sua arquitetura. Esse processo é ilustrado através do Exemplo E.1.
Exemplo E.1. Vamos considerar uma simplificação do SASF que chamaremos SSF (Sis- tema de Streaming de Filmes). Ele é mais simples porque realiza apenas uma das duas principais funcionalidades do SASF: transmitir filmes. Por sua semelhança, consideramos que ele possui um conjunto de interessados parecido com o do SASF. Entretanto, para com- pormos um cenário sem conflitos, vamos começar descartando as distribuidoras de filmes desse conjunto. Com isso, passamos a responsabilidade de disponibilizar filmes aos usuários que inicialmente usam o software apenas para assisti-los. Contudo, as distribuidoras não são consideradas interessadas apenas por disponibilizarem filmes. Elas têm também a preocu- pação com que o software respeite os direitos autorais desses filmes. Para tanto, o SASF e o SSF são obrigados a só permitir a transmissão de filmes a pessoas autorizadas e impedir a redistribuição de vídeos por parte dos usuários. Essas obrigações têm efeito na arquitetura de ambos os produtos, que tem que prover não só meios de autenticar e autorizar usuários, para distinguir usuários que assistem dos usuários que distribuem filmes, como também prover meios de impedir ou dificultar a redistribuição do conteúdo transmitido.
A autenticação e autorização são feitas por um módulo responsável pelo cadastro e auten- ticação de usuários e criação de sessões de uso. Esse módulo provê opções para se cadastrar como distribuidor ou consumidor de filmes. Para o cadastro, o usuário deve prover informa- ções para contato qualquer que seja seu papel. Porém, enquanto a conta para um consumidor
E.1 Quem são os interessados em um sistema de software? 115 é criada assim que o número de seu cartão de crédito seja verificado junto a operadora, o mesmo não acontece para a conta do distribuidor. Para o cadastro de um consumidor ser efe- tivado, é necessária uma verificação não-automática de sua autenticidade. Essa verificação é iniciada a partir de uma notificação por e-mail, que indica o distribuidor recém-cadastrado e que é enviado às pessoas do departamento responsável pela verificação de usuários.
A proteção contra redistribuição do conteúdo transmitido, por sua vez, é feita por meio da Gestão de Direitos Digitais (GDD)1. Por isso, a arquitetura não só define o servidor de
stream, mas também o aplicativo cliente e reprodutor de filmes que é o único capaz de
decodificar o vídeo.
Por outro lado, ao descartarmos as distribuidoras de filmes de seu grupo de interessados, o SSF fica livre das restrições impostas por elas e passar a não necessitar de uma arquitetura que permita autenticação e autorização para distribuição de filmes, nem proteção do conteúdo distribuído. Por isso, sua arquitetura pode ser simplificada. Uma forma de simplificar é não mais usar a GDD. Dessa maneira, fica decidido que a transmissão será feita usando qualquer formato de vídeo amplamente adotado por reprodutores de mídia. Essa decisão exclui até o que antes era a necessidade: implementar um reprodutor de filmes próprio, mas também melhora a usabilidade, uma vez que agora o usuário está livre para assistir a filmes com o reprodutor que desejar.
Deixar de considerar um único grupo de interessados causou mudanças profundas tanto nos atributos de segurança, quanto nos de usabilidade do sistema e, como consequência, causou mudanças também na arquitetura. Se continuarmos a simplificação de nosso cenário e desconsiderarmos o cliente do software, poderemos então descartar a necessidade de um baixo custo de desenvolvimento e operação. Assim, para alcançarmos desempenho esperado pelos consumidores de filmes, a arquitetura do SSF poderia adotar uma técnica simples, porém cara: para servir mais rápido, basta apenas dispor de mais recursos computacionais, por exemplo, processadores, HDs, memória e conexões maiores, mais rápidos e em maior número. Com essa decisão de aumentar os recursos não se importando com o preço, o SSF poderá não só servir os usuários mais rápido, como também servir a mais usuários.2 Essa
1Digital Rights Management (DRM)
2Desempenho é um atributo comumente esperado pelos usuários, que nunca querem esperar pelo serviço. Já escalabilidade não é um atributo requerido explicitamente por eles, mas se torna necessária quando o número de usuários aumenta e não se aceita que o desempenho degrade.
E.1 Quem são os interessados em um sistema de software? 116 abordagem de apenas melhorar o hardware para servir a uma maior demanda é o que no próximo capítulo chamamos de escalabilidade vertical. A escalabilidade vertical costuma ser bem cara e ter um limite menor de crescimento em relação à sua alternativa, que é a escalabilidade horizontal. Nesse segundo tipo de escalabilidade, a organização do software e como ele se comunica realiza um papel essencial para atender à grande demanda de usuários, mesmo quando executando em hardware de menor capacidade. Em outras palavras, há um melhor aproveitamento dos recursos disponíveis, algo que só pode ser alcançado por meio
de uma arquitetura bem pensada. !
É importante lembrar que dentro de um mesmo grupo de interessados podem existir interesses conflitantes entre si. Afinal, um grupo pode se organizar em subgrupos de interes- ses comuns, mas um subgrupo pode demonstrar interesses conflitantes com outro subgrupo. Portanto, subgrupos diferentes de usuários ou de desenvolvedores resultam em requisitos diferentes, que significam atributos de qualidade diferentes e que são frutos de arquitetu- ras diferentes. Podemos observar isso no estudo de caso (também citado no Exemplo E.1), quando o grupo de usuários se organiza em dois subgrupos: os que se cadastram no sistema para alugar filmes e as distribuidoras de filmes. O resultado dessa divisão e o conflito po- dem também ser observados no exemplo (e na Figura E.1). Por um lado, as distribuidoras impõem seus requisitos de proteção aos direitos autorais. Por outro, os usuários têm a forma de interação com o sistema modificada, uma vez que devem usar um reprodutor de filmes específico para que os requisitos das distribuidoras sejam alcançados. Em resumo, mesmo fazendo parte de um mesmo grupo de envolvidos, a influência de cada subgrupo não pode ser desconsiderada, uma vez que ela pode ser grande o bastante para modificar, inclusive, a forma de outros subgrupos interagirem com o sistema.
E.1.1 Importância dos interessados
Observe que no Exemplo E.1 a presença ou ausência de um interessado tem grande influência na arquitetura. Além disso, é comum que sua ausência dê espaço para simplificações nas decisões arquiteturais.3 Entretanto, no mundo real, os envolvidos não se limitam a usuários e
desenvolvedores. Há diversos outros tipos de envolvidos que influenciam o desenvolvimento
3Note que uma arquitetura mais simples não necessariamente significa um produto com desenvolvimento mais barato ou execução mais rápida.
E.1 Quem são os interessados em um sistema de software? 117
Figura E.1: Stakeholders de um mesmo grupo, mas divergindo nos requisitos.
do software de diversas maneiras diferentes. Esses envolvidos que influenciam o ciclo de vida do software também são chamados stakeholders. Devido ao conceito de stakeholder ser bastante amplo e transcender a Engenharia de Software, preocupamo-nos apenas com aqueles que impactam a arquitetura e, por isso, usamos a definição dada por Rozanski e Woods:
Definição E.1. (stakeholder). “Um stakeholder em uma arquitetura de software é uma pessoa, grupo ou entidade com um interesse ou preocupações sobre a realização da arquite-
tura.”4
Alguns stakeholders têm diferentes responsabilidades durante o ciclo de vida do software. Entre as responsabilidades, podemos citar financiamento, projeto, desenvolvi- mento, teste, uso, manutenção e até passagem de conhecimento sobre ele. Outros stakehol- ders, por sua vez, esperam que o software funcione de alguma forma específica: eles têm necessidades em relação ao software. Por exemplo, é comum para um usuário esperar que o resultado alcançado pelo software seja confiável ou que seja alcançado em um tempo hábil. Quando estamos no espaço do problema, costumamos chamar essas responsabilidades e ne- cessidades de requisitos do software. Por outro lado, quando estamos no espaço da solução, costumamos chamá-las de atributos de qualidade. Logo, os stakeholders têm forte influência sobre a arquitetura de um software porque ela é uma ferramenta essencial para proporcionar
4N. Rozanski and E. Woods. Software Systems Architecture: Working With Stakeholders Using Viewpoints and Perspectives, Addison-Wesley Professional 2005.
E.2 Tipos de stakeholders e sua relação com os atributos de qualidade 118