do acervo. Cada vídeo possui ainda fotos de divulgação, trailers, sinopse, lista de usuários que já alugaram e lista de usuários com o filme na fila de locação. Essas informações devem sempre estar disponíveis ao usuário para ajudá-lo na decisão de alugar um filme.
C.3.5 Tempos de resposta
Por fim, observamos que o SASF disponibiliza um grande volume de informação, seja para o usuário comum, através do streaming, da busca ou do aluguel de filmes, seja para o adminis- trador, através da monitoração e ação sobre o estado do sistema. Esse volume de informação aumenta naturalmente o tempo de resposta dessas operações. Por outro lado, tempos de res- posta acima do especificado ou acima da expectativa do usuário contribuem para o fracasso de um sistema. Assim, as diversas operações providas pelo SASF devem ser realizadas na velocidade da satisfação de cada usuário em questão.
No SASF, diferentes classes de usuários têm diferentes operações à sua disposição. Além disso, essas operações são bastante diferentes entre classes de usuários. Por exemplo, um ad- ministrador pode obter a velocidade média da realização da operação de aluguel executada por dado conjunto de servidores ao longo da última semana, enquanto um usuário quer ape- nas ver as cinco últimas críticas a determinado filme. Por isso, todas as operações disponíveis não terão o mesmo tempo de resposta, mas tempos diferentes de acordo com o volume de dados que opera, sua criticidade, e o stakeholder envolvido. Isto será observado ao longo do livro, ao exemplificarmos mais aspectos do SASF.
C.4 Resumo
Como podemos observar através de suas capacidades, o SASF se mostra um estudo de caso significativo devido à relativa complexidade de seus requisitos. Esses requisitos dificultam ou mesmo impossibilitam seu desenvolvimento se não houver um mínimo de planejamento para atendê-los ou ainda caso não seja adotada uma abordagem, digamos, arquitetural para atendê-los.
Nos próximos capítulos estudaremos os aspectos fundamentais para que possamos de- senvolver um sistema como o SASF e, passo a passo, mostraremos como esses aspectos se
C.4 Resumo 78 aplicam ao estudo de caso em questão.
Apêndice D
Fundamentos de Arquitetura de Software
No capítulo introdutório, mencionamos que o Design de Software pode ser dividido em duas atividades: design de alto-nível ou arquitetural e design detalhado e que ambas as atividades têm um papel importante no ciclo de desenvolvimento do software. Como o objeto de estudo deste livro é Arquitetura de Software, voltamo-nos agora para a primeira atividade em questão.
Este capítulo tem como objetivo expor o leitor aos fundamentos de Arquitetura de Software ou, em outras palavras, fazer com que seja capaz de:
• Reconhecer, entender, e comparar as diferentes definições existentes do termo arqui-
tetura de software
• Relacionar as diferentes definições de arquitetura de software com o padrão ISO/IEEE 1471
• Identificar as características e benefícios proporcionados por uma boa arquitetura
• Avaliar os benefícios de explicitamente projetar a arquitetura durante o desenvolvi- mento do software
D.1 Motivação para desenvolver melhores sistemas
Desenvolver software não é uma tarefa fácil. É por esse motivo que muitos projetos de software fracassam durante seu desenvolvimento ou ao obter seus resultados. Entre esses
D.1 Motivação para desenvolver melhores sistemas 80 maus resultados, encontramos os que custaram muito acima do orçamento, os incompletos e os que não solucionam os problemas como deveriam resolver.
Não é fácil alcançar um bom produto de software devido à complexidade envolvida em seu processo de desenvolvimento. Além de lidar com a complexidade inerente ao problema, devemos também nos preocupar em como o software resolve esse problema. Assim, o software deve, além de resolver o problema, resolvê-lo da forma esperada. Ou em outras palavras:
Espera-se que, além de função, o produto de software possua os atributos de qualidade esperados.
Exemplo D.1. Considere um programa que realize as quatro operações: soma, subtração, multiplicação e divisão. Se o tempo de resposta de suas operações for sempre maior do que o tempo que seu usuário está disposto a esperar, esse programa não terá utilidade mesmo que
sempre retorne o resultado correto. !
Podemos observar no Exemplo D.1 que o programa funciona corretamente, mas, por não exibir o desempenho esperado, acaba sendo abandonado. Por outro lado, consertar esse programa para que seja útil é relativamente fácil. Por exemplo, se o programa não multiplica rápido o bastante, basta apenas reimplementar a função de multiplicação para que tenha um melhor desempenho.
Exemplo D.2. Considere agora o SASF, já apresentado no Capítulo C. Considere também que ele se mostra incapaz de responder em menos de dois segundos às operações de aluguel de filmes. Uma vez que os usuários não estão dispostos a esperar esse tempo pela principal operação do sistema, isso resultará numa má experiência de uso, que será motivo para que seus usuários deixem de usá-lo e também deixem de pagar pelo serviço. ! Acontece que diminuir o tempo de resposta de uma funcionalidade no SASF, dado o ta- manho do sistema, pode não ser tão simples quanto diminuir o tempo de execução de uma função matemática. O alto tempo de resposta de um serviço no SASF pode ser função de uma ou mais decisões tomadas ao longo do desenvolvimento que resultaram na sua estrutura e organização interna. Essa estrutura e organização é o que chamamos de arquitetura. Como o atendimento aos atributos de qualidade do software se deve em grande parte à sua arqui- tetura, surge a necessidade de estudá-la. E, por fim, é através do estudo das características e técnicas de projeto de arquitetura que poderemos projetar e desenvolver melhores produtos
D.2 O que é Arquitetura de Software 81