A descri¸c˜ao da arquitetura da aplica¸c˜ao constru´ıda segue a ADL definida pelo FRAME para representar seus componentes e conex˜oes [Pinto et al. 2010][Pinto 2010], baseado em
uma nota¸c˜ao que usa XML [W3C. Extensible Markup Language (XML)]. As figuras a seguir mostram a descri¸c˜ao arquitetural da aplica¸c˜ao, por´em somente as partes impor- tantes para esse estudo de caso, j´a que a ADL do FRAME tamb´em apresenta informa¸c˜oes sobre pol´ıticas de QoS, entre outras informa¸c˜oes, essas partes foram suprimidas aqui nesse cap´ıtulo. Na Figura 26 iniciamos a descri¸c˜ao da aplica¸c˜ao, a qual chamamos de Case Study Example. A aplica¸c˜ao possui um componente raiz (root) como toda aplica¸c˜ao FRAME. Em seguida temos a declara¸c˜ao de um componente chamado crypt que usa uma defini¸c˜ao externa (adl.cs crypt hex ). Este ´e o componente respons´avel pela criptografia e que ser´a compartilhado entre o cliente e o servidor.
Figura 26: Descri¸c˜ao arquitetural do estudo de caso (Parte I)
Ainda sobre a Figura 26, ap´os a declara¸c˜ao de crypt temos a declara¸c˜ao e defini¸c˜ao do componente chamado cliente, que tem como classe Java application.cs.Client. O cliente possui duas interfaces: a primeira chamada iclient, que representa a interface Java ap- plication.cs.IService e indica um servi¸co requerido (role=Client); e a segunda chamada icrypt clt que tamb´em indica um servi¸co requerido (role=Client) e representa a interface Java application.cs.ICrypt.
Internamente ao cliente, temos a defini¸c˜ao do componente chamado Consumer, que ser´a respons´avel por receber e exibir o fluxo multim´ıdia. Isto ´e feito usando as bibliote- cas do JMF (Java Media Framework [Sun Microsystems. JMF, Java Media Framework]). Consumer possui um atributo que representa o tipo do v´ıdeo consumido (videoType). Esse atributo pode ser acessado via interface controladora de atributos definida pelo FRAME application.cs.IAttrConsumer. Como esperado, Consumer tamb´em possui uma interface
de stream para entrada de dados (role=Input) com nome in.
De maneira semelhante teremos a defini¸c˜ao do componente servidor logo em seguida, como mostrado na Figura 27. O componente chamado server possui uma interface provida (role=Server ) chamada iserver. ´E atrav´es dessa interface que o servidor disponibiliza a possibilidade do cliente enviar coment´arios sobre o filme em execu¸c˜ao. Ela representa a interface Java application.cs.IService, que ´e a mesma indicada pelo cliente.
Figura 27: Descri¸c˜ao arquitetural do estudo de caso (Parte II)
Assim como no cliente, o servidor possui uma interface requerida chamada icrypt clt para um servi¸co de criptografia. Internamente no servidor, ´e definido o componente producer. O produtor ´e respons´avel por enviar bytes de um v´ıdeo para o consumidor. Dessa forma, ele possui um atributo chamado videoName que indica o nome do v´ıdeo usado no streaming. Como esperado novamente, o produtor define uma interface de stream para sa´ıda de dados (role=Output) chamada out.
Ainda sobre a Figura 27, podemos ver os bindings estabelecendo os relacionamentos entre os componentes. O primeiro Binding (bind crypt clt) liga client e crypt, enquanto o segundo (bind crypt srv ) liga server e crypt, satisfazendo as interfaces para criptografia
requeridas pelo cliente e pelo servidor. Logo em seguida, um terceiro Binding liga o cliente ao servidor, atrav´es da interface definida para o servi¸co que tem como assinatura application.cs.IService.
Finalmente, chega o momento de conectar os componentes participantes do streaming multim´ıdia atrav´es de suas interfaces de stream. Dessa forma, uma Connection, chamada conn, ´e criada tendo como origem (source) a interface out do producer e como alvo (target) a interface in do consumer. As demais propriedades da conex˜ao tamb´em s˜ao configuradas, como protocolo, buffer, etc. Mesmo sendo uma interface de streaming, o MoSAC ir´a tratar como uma interface normal.
A comunica¸c˜ao entre esse modelo de descri¸c˜ao e o MoSAC se deu atrav´es da imple- menta¸c˜ao de um parser que transforma a descri¸c˜ao mostrada no formato de dados do MoSAC (se¸c˜ao 4.2).
5.3
Levantamento dos Requisitos N˜ao Funcionais Uti-
lizados
Na escolha dos crit´erios foram levados em considera¸c˜ao aqueles levantados em tra- balhos anteriores realizados no contexto do framework Cosmos Lopes 2006, mais especi- ficamente os crit´erios que envolvem o dom´ınio das aplica¸c˜oes de TV Digital e crit´erios espec´ıficos da aplica¸c˜ao relacionados com qualidade envolvida em criptografia. Para sim- plificar a estrat´egia de sele¸c˜ao, a fim de validar o estudo de caso foram propostos os seguintes crit´erios, os quais dividiremos em trˆes grupos:
• Crit´erios Espec´ıficos de Criptografia: Esses crit´erios foram levantados consi- derando os principais requisitos n˜ao funcionais que s˜ao discutidos em pesquisas nesse dom´ınio [Alvaro, Almeida e Meira 2007] [Menezes, Vanstone e Oorschot 1996], onde s˜ao considerados os seguintes:
– Seguran¸ca: verifica o n´ıvel de seguran¸ca (de fun¸c˜ao de criptografia) sobre os dados envolvidos;
– Utiliza¸c˜ao de Mem´oria: verifica o quanto ´e gasto de mem´oria para executar os c´alculos de criptografia sobre uma massa de dados;
– Tipo de Cifra: identifica o tipo de cifra utilizado, normalmente as empregadas s˜ao as cifras modernas (usam dados, chaves e l´ogica bin´aria), cifras por bloco (monoalfabetos) e cifras cont´ınuas (multialfabetos);
– Tipo de Chaves: identifica o tipo de chave a ser aplicado na criptografia, os quais podem ser sim´etricas (mais eficientes, por´em o n´umero de chaves cresce com o quadrado dos envolvidos) ou assim´etricas (utiliza menos chaves, por´em ´e menos eficiente);
• Crit´erios de Distribui¸c˜ao: Esses crit´erios s˜ao baseados em estudos emp´ıricos realizados em [Silva et al. 2008]. Esses testes elegeram os principais crit´erios que os componentes do Cosmos deveriam possuir para serem analisados no processo de sele¸c˜ao. Essa bateria de testes desenvolvida por [Silva et al. 2008] rendeu os seguintes crit´erios considerados como relevantes no processo de avalia¸c˜ao dos com- ponentes: latˆencia de adapta¸c˜ao, tamanho do buffer de recep¸c˜ao e latˆencia de carga. Por´em, por simplifica¸c˜ao decidiu- se utilizar apenas o seguinte crit´erio:
– Tamanho do Buffer de Recep¸c˜ao: medida da estimativa de buffer necess´ario para manipular stream de dados.
• Crit´erios Gerais: s˜ao crit´erios considerados de car´ater geral que eventualmente poder˜ao ser considerados como fatores adicionais a serem usados pelo processo aqui proposto, de acordo com [Alves, Alencar e Castro 2000] e [Tran e Liu 1997]. S˜ao eles:
– Tempo M´edio de Uso: indica o tempo m´edio de uso do componente, funcio- nando como um medidor de confian¸ca do componente;
– Vers˜ao: indicador de vers˜ao e maturidade de desenvolvimento; – Custo: pre¸co correspondente ao componente que se deseja usar; – Fornecedor: entidade respons´avel pela distribui¸c˜ao do componente.
Para representar tais crit´erios, optou-se por utilizar a descri¸c˜ao atrav´es do uso de XML. O anexo A desse documento mostra a estrat´egia de sele¸c˜ao descrita na forma de XML juntamente com os valores utilizados na sele¸c˜ao. A implementa¸c˜ao de um parser que lˆe de XML e converte para o formato de dados do MoSAC tamb´em foi necess´ario, semelhantemente como ocorreu no caso da descri¸c˜ao arquitetural.