Qual das alternativas melhor descreve a entrada e a saída de uma fase de projeto?

Arquitetura de Software

A organiza��o das funcionalidades de software de um sistema � explicitada atrav�s da arquitetura de software. H� uma grande quantidade de estilos arquiteturais que trazem caracter�sticas peculiares a cada estilo, e estes, por sua vez, podem ser combinados gerando novos estilos. A heterogeneidade de estilos arquiteturais � salutar. Na verdade, isto ocorre devido � necessidade da arquitetura prover suporte a um conjunto de requisitos, �s vezes conflitantes, dentre eles os requisitos n�o funcionais, tema abordado neste artigo.

Conte�do relacionado: Cursos de Engenharia de Software

Requisitos N�o Funcionais e Arquitetura de Software

O projeto da arquitetura de software � uma etapa essencial no desenvolvimento de sistemas de software de grande porte e complexos. Dentro deste contexto, a arquitetura de software � fundamental para o desenvolvimento de linhas de produ��o de software onde se tem um conjunto de funcionalidades concebidas e implementadas a partir da mesma arquitetura (de software) base. Entretanto, antecedendo a etapa de projeto da arquitetura de software, h� a necessidade de fazer o levantamento dos requisitos do sistema.

De um modo geral, o conjunto de requisitos de um sistema � definido durante as fases iniciais do processo de desenvolvimento. Tal conjunto de requisitos � visto como uma especifica��o do que deveria ser implementado. Os requisitos s�o descri��es de como o sistema deveria se comportar, e cont�m informa��es do dom�nio da aplica��o e restri��es sobre a opera��o do sistema.

Durante a fase de elicita��o de requisitos, um projetista ou arquiteto de software faz uso de sua experi�ncia a fim levantar os requisitos, buscando identificar caracter�sticas do sistema a ser desenvolvido. Al�m disso, informa��es do dom�nio juntamente com informa��es de estilos arquiteturais existentes podem ser utilizados como fontes de dados que auxiliam na identifica��o dos requisitos.

Outro recurso que pode ser usado pelo projetista � construir cen�rios. Os cen�rios de uso oferecem suporte a requisitos espec�ficos e visam tanto a elicita��o quanto a an�lise de requisitos. Uma vez que o conjunto de requisitos tenha sido obtido, o projetista/arquiteto de software estar� em condi��es de iniciar o projeto da arquitetura de software, conforme ilustrado na Figura 1.

Este processo de levantamento e an�lise de requisitos, em conjunto com o uso de cen�rios, � usado no suporte da defini��o da arquitetura de software, como � discutido ao longo do artigo. � importante observar que a etapa de projeto arquitetural pode precisar fazer uso de cen�rios de uso ou mesmo uma re-an�lise a fim de refinar a arquitetura a ser empregada no sistema a ser desenvolvido.

O processo de desenvolvimento baseado na arquitetura considera a arquitetura de software como fator orientador do processo. Isto acarreta em colocarmos os requisitos n�o funcionais associados � arquitetura como principais aspectos do processo de desenvolvimento. Note que o desenvolvimento de um sistema de software centrado na arquitetura inicia-se com um arquiteto de software, de posse de um conjunto de requisitos do sistema. Nesse momento, busca-se identificar qual estilo ou combina��o destes oferece suporte mais adequado a esses requisitos e, portanto, derivar uma arquitetura de software que atenda �s caracter�sticas do sistema a ser desenvolvido. Vale ressaltar que a complexidade de um sistema de software � determinada tanto por seus requisitos funcionais � o que ele faz � quanto requisitos n�o funcionais � como ele faz. Tal distin��o � baseada nas seguintes defini��es

Confira nosso Guias Engenharia de Software

Requisito funcional

Um requisito de sistema de software que especifica uma fun��o que o sistema ou componente deve ser capaz de realizar. Estes s�o requisitos de software que definem o comportamento do sistema, ou seja, o processo ou transforma��o que componentes de software ou hardware efetuam sobre as entradas para gerar as sa�das. Esses requisitos capturam as funcionalidade sob o ponto de vista do usu�rio.

Requisito n�o funcional

Em engenharia de sistemas de software, um requisito n�o funcional de software � aquele que descreve n�o o que o sistema far�, mas como ele far�. Assim, por exemplo, t�m-se requisitos de desempenho, requisitos da interface externa do sistema, restri��es de projeto e atributos da qualidade. A avalia��o dos requisitos n�o funcionais � feita, em parte, por meio de testes, enquanto que outra parte � avaliada de maneira subjetiva.

Perceba que tanto os requisitos funcionais quanto os n�o funcionais possuem import�ncia no desenvolvimento de um sistema de software. Entretanto, os requisitos n�o funcionais, tamb�m denominados de atributos de qualidade, t�m um papel relevante durante o desenvolvimento de um sistema, atuando como crit�rios na sele��o e/ou composi��o de uma arquitetura de software, dentre as v�rias alternativas de projeto.

Cabe salientar que � medida que os sistemas tornam-se maiores e mais complexos, o suporte a requisitos n�o funcionais depende cada vez mais de decis�es tomadas no projeto da arquitetura de software. Trata-se de uma vis�o compartilhada pelos profissionais da �rea e, especificamente, pela comunidade de arquitetura de software.

Requisitos N�o Funcionais

Requisitos n�o funcionais s�o aqueles que n�o est�o diretamente relacionados � funcionalidade de um sistema. O termo requisitos n�o funcionais � tamb�m chamado de atributos de qualidade. 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. Desconsiderar ou n�o considerar adequadamente tais requisitos � dispendioso, pois torna dif�cil a corre��o uma vez que o sistema tenha sido implementado. Suponha, por exemplo, que uma decis�o tenha sido feita de modularizar a arquitetura de um sistema de modo a facilitar sua manuten��o e adi��o de novas funcionalidades. Entretanto, modularizar um sistema adicionando uma camada a mais pode comprometer um outro requisito, o de desempenho. Portanto, faz-se necess�rio definir logo cedo quais requisitos n�o funcionais ser�o priorizados na defini��o de uma arquitetura.

Os requisitos n�o funcionais abordam aspectos de qualidade importantes em sistemas de software. Se tais requisitos n�o s�o levados em considera��o, ent�o o sistema de software poder� ser inconsistente e de baixa qualidade, conforme discutido acima. Para tanto, quanto mais cedo forem definidos os crit�rios arquiteturais, mais cedo o projetista pode identificar o estilo, ou combina��o de estilos, mais apropriado ao sistema considerado.

Ao desenvolver um novo sistema de software bem como sua arquitetura, os projetistas ou engenheiros de software apresentam um conjunto de atributos de qualidade ou requisitos n�o funcionais que o sistema deveria suportar. Exemplo destes requisitos s�o desempenho, portabilidade, manutenibilidade e escalabilidade.

A arquitetura de software deveria oferecer suporte a tais requisitos. sto resulta da associa��o existente entre arquitetura de software e requisitos n�o funcionais. Importante observar que cada estilo arquitetural (isto �, a forma na qual o c�digo do sistema � organizado) suporta requisitos n�o funcionais espec�ficos. A estrutura��o de um sistema � determinante no suporte oferecido a um requisito n�o funcional. Por exemplo, o uso de camadas permite melhor separar as funcionalidades de um sistema, tornando-o mais modular e facilitando sua manuten��o.

Considere, por exemplo, o padr�o IEEE-Std 830-1993 [IEEE 1993] que lista um conjunto de 13 requisitos n�o funcionais a serem considerados no documento de especifica��o de requisitos de software. Este padr�o inclui, dentre outros, requisitos de desempenho, confiabilidade, portabilidade e seguran�a.

Embora haja um conjunto de propostas, consideradas como complementares, concentraremos nossas aten��es num conjunto de requisitos diretamente associados a um sistema de software e, especificamente, � arquitetura de software. Este conjunto � baseado numa classifica��o apresentada por Sommerville, onde � feita a distin��o entre requisitos externos, de produto, e de processo [Sommerville 2007].

A Figura 2 � uma adapta��o da proposta de Sommerville, onde consideramos os requisitos de produto, associados � arquitetura de software, bem como adicionamos outros n�o presentes na proposta original de Sommerville. � importante observar que a Figura 2 mostra um subconjunto de requisitos n�o funcionais, denominados de requisitos de produtos os quais est�o associados � arquitetura de um sistema de software. Note que a classifica��o apresentada em [Sommerville 2007] ainda considera os requisitos de processo e requisitos externos como sendo requisitos n�o funcionais, al�m dos requisitos de produtos. A figura exibe um conjunto de 7 requisitos n�o funcionais, sendo alguns destes ainda decompostos.

Usabilidade

Usabilidade � um dos atributos de qualidade ou requisitos n�o funcionais de qualquer sistema interativo, ou seja, no qual ocorre intera��o entre o sistema e seres humanos. A no��o de usabilidade vem do fato que qualquer sistema projetado para ser utilizado pelas pessoas deveria ser f�cil de aprender e f�cil de usar, tornando assim f�cil e agrad�vel a realiza��o de qualquer tarefa.

Requisitos de usabilidade especificam tanto o n�vel de desempenho quanto a satisfa��o do usu�rio no uso do sistema. Dessa forma, a usabilidade pode ser expressa em termos de:

• Facilidade de aprender: Associado ao tempo e esfor�o m�nimo exigido para alcan�ar um determinado n�vel de desempenho no uso do sistema.
• Facilidade de uso: Relacionado � velocidade de execu��o de tarefas e � redu��o de erros no uso do sistema.

Os requisitos de usabilidade s�o coletados juntamente com outros requisitos (de dados e funcionais) usando algumas das t�cnicas de elicita��o de requisitos como entrevistas ou observa��o. A coleta desses dados pode ocorrer, por exemplo, verificando o log de a��es do usu�rio quando do uso de funcionalidade do sistema.

Esses requisitos de usabilidade podem ser expressos atrav�s de m�tricas de usabilidade, expressas em termos de medidas de desempenho. Tyldesley apresentou um conjunto de crit�rios que podem ser utilizados durante a medi��o de usabilidade [Tyldesley 1988]. A sele��o de crit�rios a serem usados para mensurar a usabilidade depende do tipo de sistema. Exemplos de crit�rios de medi��o de usabilidade s�o apresentados na Figura 3.

A defini��o das metas de usabilidade atrav�s de m�tricas � parte do processo denominado de engenharia de usabilidade. Neste processo, faz-se necess�rio tamb�m estabelecer os n�veis desejados de usabilidade. Se, por exemplo, o usu�rio tem dificuldade em encontrar a funcionalidade desejada no sistema e, conseq�entemente, precisa recorrer � ajuda (Help) ou expressa insatisfa��o, ent�o se observa que dois dos crit�rios da Figura 3 s�o considerados. A quantidade de vezes que essas ocorr�ncias s�o observadas serve de indicador do suporte oferecido � usabilidade pelo sistema.

A usabilidade � um dos atributos de qualidade de um sistema e tem sido cada vez mais levada em considera��o durante o desenvolvimento de software. A usabilidade pode ser afetada pelos componentes funcional (ou de aplica��o) e de apresenta��o de um sistema. Mesmo que esses componentes sejam bem projetados, ainda assim a usabilidade poder� ficar comprometida se a arquitetura do sistema n�o levar em considera��o a facilidade de efetuar uma modifica��o.

� importante acrescentar que a simples separa��o arquitetural entre componente de aplica��o e apresenta��o em sistemas interativos n�o � suficiente para assegurar a usabilidade do mesmo. Assim, para determinar se uma arquitetura de software satisfaz a aspectos de usabilidade, torna-se necess�rio desenvolver cen�rios de uso do sistema. Em tais cen�rios, busca-se assegurar que informa��es corretas estejam dispon�veis ao usu�rio no momento adequado, bem como encaminhar corretamente as instru��es/comandos dos usu�rios a componentes apropriados do sistema. Note que a arquitetura de software do sistema tem um papel de suma import�ncia visto que tais informa��es ser�o trocadas entre componentes do sistema e entre estes e o usu�rio, fluindo atrav�s de conectores da arquitetura.

Manutenibilidade

O termo manuten��o de software � geralmente empregado quando nos referimos �s modifica��es feitas ap�s o sistema de software ter sido disponibilizado para uso. Na realidade, o termo manutenibilidade � um tanto abrangente j� que ele envolve tanto a atividade de reparo (de algum defeito existente no sistema de software) quanto a atividade de altera��o/evolu��o de caracter�sticas existentes ou adi��o de novas funcionalidades n�o previstas ou capturadas no projeto inicial.

O reparo de um sistema de software ocorre quando defeitos s�o detectados, fazendo-se necess�ria a corre��o deles. A capacidade de efetuar um reparo depende do n�mero de componentes do sistema. Por exemplo, se o sistema � monol�tico, ou seja, constitu�do de um �nico componente, ent�o tornar-se mais dif�cil efetuar o reparo se este sistema de software � de grande porte.

No entanto, se o sistema de software � modularizado, ent�o tende a ser mais f�cil analisar e reparar o existente. Podemos dizer que a modularidade favorece a capacidade de fazer reparo, permitindo que defeitos fiquem confinados a poucos m�dulos, considerando-se que se tenha a funcionalidade adequadamente separada. Uma observa��o importante � que a necessidade de fazer reparo � minimizada � medida que a confiabilidade do sistema aumenta.

Similarmente a outros sistemas, os sistemas de software evoluem ao longo do tempo, seja com a adi��o de novas funcionalidades ou com a modifica��o das existentes. Esta capacidade de evolu��o de um sistema de software � tamb�m influenciada pela modularidade do sistema. Note que se a arquitetura do sistema n�o considerar sua possibilidade de evolu��o por meio da adi��o e/ou altera��o de funcionalidades do sistema, modifica��es tornar-se-�o cada vez mais dif�ceis � medida que o software evolui.

De um modo geral, a manutenibilidade � um dos requisitos mais relacionados com a arquitetura de um sistema de software. A facilidade de fazer altera��o no sistema existente, seja adicionando ou modificando alguma funcionalidade, depende muito da arquitetura deste. Se considerarmos a necessidade de incrementar a quantidade de componentes encarregados do processamento de uma liga��o telef�nica (numa central telef�nica) ou de transa��es eletr�nicas, ent�o esta adi��o de novos componentes deve ocorrer sem a necessidade de modificar a arquitetura existente e ainda comprometer pouco (ou nada) o desempenho atual do sistema. Tal suporte � manutenibilidade (seja para corre��o ou evolu��o do sistema) deve ser facilmente acomodada pela arquitetura de software.

� importante lembrar que uma arquitetura de software define os componentes e conex�es entre estes e, portanto, tamb�m definem sob que circunst�ncias componentes ou conectores podem ser alterados. Dessa forma, uma arquitetura ou estilo arquitetural de um sistema de software deveria efetivamente acomodar as modifica��es que precisarem ser feitas tanto durante seu desenvolvimento quanto ap�s o sistema entrar em opera��o.

Confiabilidade

Confiabilidade de software � a probabilidade de o software n�o causar uma falha num sistema durante um determinado per�odo de tempo sob condi��es especificadas. A probabilidade � uma fun��o da exist�ncia de defeitos no software. Assim, os est�mulos recebidos por um sistema determinam a exist�ncia ou n�o de algum defeito. Em outras palavras, a confiabilidade de software, geralmente definida em termos de comportamento estat�stico, � a probabilidade de que o software ir� operar como desejado num intervalo de tempo conhecido. Tamb�m, a confiabilidade caracteriza-se um atributo de qualidade de software o qual implica que um sistema executar� suas fun��es como esperado.

Os requisitos de confiabilidade compreendem restri��es sobre o comportamento do sistema de software em tempo de execu��o. Na realidade, tem-se um conjunto de m�tricas de confiabilidade de software associadas a esses requisitos. Geralmente, as falhas de um componente de software s�o de natureza transit�ria, ou seja, elas ocorrem apenas para algumas entradas (est�mulos) enquanto o sistema poder� continuar operando normalmente em outras circunst�ncias. Isto distingue o software do hardware j� que as falhas no segundo s�o de natureza permanente. Vale ressaltar que falha � o que se observa pelos usu�rios (externamente) enquanto que os defeitos, de origem interna ao sistema, s�o os motivadores das falhas.

N�o � t�o simples relacionar a disponibilidade de um sistema de software a uma falha existente, pois isto depende de v�rios fatores, tais como grau de corrup��o de dados em decorr�ncia de algum defeito de software e tempo de re-inicializa��o, dentre outros. Exemplos de m�tricas utilizadas para avaliar a confiabilidade de software compreendem:

• Disponibilidade: Esta � uma medida de qu�o dispon�vel o sistema estaria para uso, isto �, qu�o dispon�vel o sistema estaria para efetuar um servi�o solicitado por algum usu�rio. Por exemplo, um servi�o de um sistema de software ter� uma disponibilidade de 999/1.000. Isto significa que dentre um conjunto de 1.000 solicita��es de servi�o, 999 dever�o ser atendidas. Esta m�trica � muito importante em sistemas de telecomunica��es, por exemplo.
• Taxa de ocorr�ncia de falha: Esta � uma medida da freq��ncia na qual o sistema falha em prover um servi�o como esperado pelo usu�rio, ou seja, a freq��ncia na qual um comportamento inesperado � prov�vel de ser observado. Por exemplo, se temos uma taxa de ocorr�ncia de falha de 2/1.000, isto significa que 2 falhas s�o prov�veis de acontecerem para cada 1.000 unidades de tempo.
• Probabilidade de falha durante fase operacional: Esta � uma medida da probabilidade que o sistema ir� comporta-se de maneira inesperada quando em opera��o. Esta m�trica � de suma import�ncia em sistemas cr�ticos que requerem uma opera��o cont�nua.
• Tempo m�dio at� a ocorr�ncia de falha ou Mean Time To Failure (MTTF): Esta � uma medida do tempo entre falhas observadas. Note que esta m�trica oferece um indicativo de quanto tempo o sistema permanecer� operacional antes que uma falha aconte�a.

Qualquer m�trica que venha a ser utilizada para avaliar a confiabilidade de um sistema depender� da forma como o sistema � usado. Note ainda que o tempo � um fator considerado nas m�tricas. Ele � escolhido de acordo com a aplica��o. H� sistemas de software que operam de forma cont�nua, enquanto outros operam de maneira peri�dica.

Por exemplo, considere um caixa eletr�nico de banco. Este � um exemplo de sistema que opera periodicamente, isto �, um caixa eletr�nico encontra-se parte do tempo em opera��o, enquanto no restante do tempo fica ocioso (embora dispon�vel para uso por algum cliente do banco). No exemplo de um caixa eletr�nico de banco, uma unidade de tempo mais adequada � o n�mero de transa��es. Assim, um exemplo de falha seria a perda de dados entrados por um usu�rio. Neste caso, a especifica��o de confiabilidade poderia ser a ocorr�ncia de uma falha dessa natureza a cada 10.000 transa��es.

A arquitetura de software influenciar� na confiabilidade de um sistema. O tempo m�dio at� a ocorr�ncia de uma falha ou MTTF poder� ser reduzido se houver replica��o de componentes cr�ticos. A perda de um desses componentes incorre em falha.

Uma forma de evitar isto ou contornar a perda de um componente � provendo uma arquitetura tolerante a falha onde uma r�plica de um componente assume o processamento do componente com falha, evitando assim qualquer interrup��o na opera��o de um sistema. Outra alternativa � degradar o desempenho do sistema sobrecarregando um componente com um n�mero maior de requisi��es do que ele foi projetado. Dessa forma, a qualidade do sistema � degradada, mas ainda assim o sistema continua a funcionar (embora de modo prec�rio at� que uma a��o corretiva seja tomada). A medida de confiabilidade pode ser definida em termos do tempo m�dio entre a ocorr�ncia de falhas, ou Mean Time Between Failure (MTBF). Esta medida � dada por:

MTBF = MTTF + MTTR (MTTR ou Mean Time To Repair � o tempo m�dio de reparo)

A medida de disponibilidade tamb�m pode ser descrita em termo do MTTF e � definida como:

Disponibilidade = MTTF x 100% / (MTTF + MTTR)

Se considerarmos essas medidas, � importante observar que se o MTTR � reduzido, ent�o a disponibilidade e confiabilidade do sistema ser�o maiores. Isto pode ser obtido arquiteturalmente se a separa��o de interesses for considerada durante o projeto. Perceba que qu�o menor � o tempo para proceder o reparo da falha, mais rapidamente o sistema voltar� a ficar operacional e, portanto, a ficar dispon�vel. Este atributo de projeto leva a uma maior integra��o, bem como maior facilidade nas modifica��es necess�rias no sistema.

Note que adicionar componentes redundantes a um sistema de software implicar� numa maior confiabilidade. Esta redund�ncia � acrescentada na forma de verifica��es adicionais realizadas a fim de detectar erros antes que eles ocasionem falhas no sistema. Todavia, o uso de componentes redundantes acarreta numa redu��o de desempenho do sistema como discutido a seguir.

Desempenho

Desempenho � um atributo de qualidade importante para sistemas de software. Considere, por exemplo, um sistema de uma administradora de cart�es de cr�dito. Em tal sistema, um projetista ou engenheiro de software poderia considerar os requisitos de desempenho para obter uma resposta de tempo para autoriza��o de compras por cart�o.

Note que os requisitos de desempenho t�m impacto mais global sobre o sistema e, por essa raz�o, est�o entre os requisitos n�o funcionais mais importantes. Contudo, � geralmente dif�cil lidar com os requisitos de desempenho e com outros requisitos n�o funcionais uma vez que eles est�o em conflito, conforme discutido acima. No in�cio da atividade de projeto da arquitetura de software torna-se necess�rio definir quais requisitos n�o funcionais ser�o priorizados, dada a possibilidade de conflito entre eles.

Adicionalmente, desempenho � importante porque afeta a usabilidade de um sistema. Se um sistema de software � lento, ele certamente reduz a produtividade de seus usu�rios ao ponto de n�o atender �s suas necessidades. Tamb�m, se o sistema de software requer muito espa�o em disco para armazenamento de informa��es, pode ser oneroso utiliz�-lo. Por exemplo, se um sistema de software exige muita mem�ria para ser executado, ele pode afetar outras aplica��es que s�o executadas no mesmo ambiente. Al�m disso, ele pode executar t�o lentamente que o sistema operacional tenta balancear o uso de mem�ria entre as diversas aplica��es. De um modo geral, o requisito de desempenho pode ser decomposto em termos de tempo e espa�o, como ilustrado na Figura 4.

O requisito de desempenho restringe a velocidade de opera��o de um sistema de software. Isto pode ser visto em termos de:

Requisitos de resposta

Especificam o tempo de resposta de um sistema de software aceit�vel para usu�rios. Neste caso, um projetista poderia especificar que o sistema deveria responder � solicita��o de um servi�o espec�fico de um usu�rio dentro de um intervalo de 2 segundos. Por exemplo, num caixa eletr�nico, ap�s o usu�rio inserir o cart�o magn�tico do banco no local apropriado (leitor do equipamento), o sistema deveria exibir uma nova tela, num intervalo de 2 segundos, requerendo que o usu�rio digite sua senha de conta corrente. Numa outra situa��o, o usu�rio pode ser solicitado a digitar sua senha e n�o o faz dentro de um per�odo de 20 segundos, quando ent�o um timeout ocorre e o sistema retorna � tela inicial.

Requisitos de processamento (throughput)

Estes requisitos especificam a quantidade de dados que deveria ser processada num determinado per�odo de tempo. Um exemplo seria exigir que o sistema de software possa processar, no m�nimo, 6 transa��es por segundo.

Requisitos de temporiza��o

Este tipo de requisito especifica qu�o rapidamente o sistema deveria coletar dados de entrada de sensores antes que outras leituras de dados de entrada, feitas posteriormente, sobrescrevam os dados anteriores. Assim, por exemplo, poderia ser especificado que o sistema deveria efetuar leitura de dados 5 vezes por segundo, como condi��o m�nima.

Requisitos de espa�o

Em alguns casos, os requisitos de espa�o podem ser considerados. Aqui, podemos nos referir � mem�ria principal ou secund�ria. Por exemplo, a mem�ria principal para executar uma aplica��o poderia ser considerada como um requisito de desempenho uma vez que ela est� relacionada ao comportamento do sistema em tempo de execu��o.

� importante observar que o desempenho depende da intera��o existente entre os componentes de um sistema de software e, portanto, est� muito associado � arquitetura. Neste caso, os mecanismos de comunica��o utilizados pelos componentes de um sistema t�m influ�ncia sobre o desempenho obtido. Conforme vimos anteriormente, desempenho est� relacionado a outros requisitos n�o funcionais. Por exemplo, a confiabilidade melhora com o uso de componentes redundantes. Todavia, o desempenho fica bastante comprometido, implicando na sua redu��o.

Portabilidade

Portabilidade pode ser definida como a facilidade na qual o software pode ser transferido de um sistema computacional ou ambiente para outro. Em outras palavras, o software � dito port�vel se ele pode ser executado em ambientes distintos. Note que o termo ambiente pode referir-se tanto � plataforma de hardware quanto a um ambiente de software como, por exemplo, um sistema operacional espec�fico.

De um modo geral, a portabilidade refere-se � habilidade de executar um sistema em diferentes plataformas. � importante observar que � medida que aumenta a raz�o de custos entre software e hardware, a portabilidade torna-se cada vez mais importante. Adicionalmente, podemos ter a portabilidade de componentes e a portabilidade de sistemas. Esta �ltima situa��o pode ser vista como caso especial de reusabilidade. O reuso de software ocorre quando todo o sistema de software � reutilizado, implementando-o em diferentes sistemas computacionais.

A portabilidade de um componente ou sistema de software � proporcional � quantidade de esfor�o necess�rio para que funcione num novo ambiente. Se uma quantidade menor de esfor�o � exigida quando comparada ao trabalho de desenvolvimento, ent�o o sistema � dito port�vel.

Dois aspectos relevantes na portabilidade de programas s�o a transfer�ncia e adapta��o. A transfer�ncia � o movimento de componente (c�digo de um programa e dados associados) de um ambiente para outro. A adapta��o engloba as modifica��es exigidas para fazer com que o programa seja executado em um novo ambiente.

Cabe salientar que o ambiente no qual um sistema de software opera � normalmente composto de hardware, sistema operacional, sistema de entrada e sa�da (E/S), bem como a aplica��o. Uma abordagem geral que poderia ser adotada para obter um sistema port�vel tentaria separar as partes do sistema que dependem do ambiente externo numa camada ou interface de portabilidade, conforme ilustrado na Figura 5.

A interface de portabilidade mostrada na figura acima poderia ser vislumbrada e projetada como um conjunto de tipos de dados abstratos ou objetos, os quais iriam encapsular os elementos n�o port�veis procurando esconder caracter�sticas do software da aplica��o. Assim, quando o sistema de software muda de hardware ou sistema operacional, apenas a interface de portabilidade precisaria ser alterada. Alguns problemas de portabilidade surgem, geralmente, devido � ado��o de diferentes conven��es para representar informa��o em arquiteturas de m�quinas distintas, ou seja, hardware diferente.

Reusabilidade

Uma caracter�stica das engenharias � fazer uso de projetos existentes a fim de reutilizar componentes j� desenvolvidos, objetivando minimizar o esfor�o em novos projetos. Dessa forma, componentes que j� tenham sido desenvolvidos e testados podem ser reutilizados. Considere os elevados n�veis de reusabilidade que encontramos tanto na ind�stria de autom�veis quanto de aparelhos eletr�nicos. Na ind�stria de autom�veis, por exemplo, um motor � geralmente reutilizado de um modelo de carro para outro.

Em Engenharia de Software, � medida que aumenta a press�o para reduzir custos de desenvolvimento e manuten��o de sistemas de software, bem como pela obten��o de sistemas com qualidade elevada, torna-se necess�rio considerar a reusabilidade como requisito n�o funcional no desenvolvimento de novos sistemas.

O reuso pode ser visto sob diferentes perspectivas. Ele pode ser orientado a componentes, orientado a processos ou orientado ao conhecimento espec�fico de um dom�nio. Note que ainda poder�amos considerar o reuso de requisitos. Entretanto, aqui, iremos concentrar nossa aten��o no reuso orientado a componentes. Exemplos desse tipo de reuso s�o:

• Aplica��o: Toda a aplica��o poderia ser reutilizada.
• Subsistemas: Os principais subsistemas de uma aplica��o poderiam ser reutilizados.
• Objetos ou m�dulos: Componentes de um sistema, englobando um conjunto de fun��es, podem ser reutilizados.
• Fun��es: Componentes de software que implementam uma �nica fun��o (como uma fun��o matem�tica) podem ser reutilizados.

Dois tipos de reuso que estamos mais interessados s�o o reuso de subsistemas e objetos ou componentes, que chamaremos, simplesmente, de reuso de componentes. Este tipo de reuso n�o envolve apenas o c�digo, mas tamb�m engloba a arquitetura e projeto associados.

� importante observar que podemos obter ganhos se reutilizarmos tanto projetos quanto arquiteturas. Isto minimiza esfor�os de desenvolvimento e requer menos altera��es ou adapta��es. Na realidade, quando se tem em mente que � necess�rio prover suporte � f�cil modifica��o, indiretamente, obtemos componentes reutiliz�veis.

Assim, o requisito reusabilidade pode envolver a arquitetura de um sistema de software ou componentes deste. O que determinar� qu�o f�cil ser� conseguir componentes reutiliz�veis � a interdepend�ncia ou acoplamento entre os componentes. Por exemplo, uma biblioteca de componentes que oferece um conjunto de funcionalidades j� implementadas e testadas oferece ao usu�rio (programador) um recurso valioso, j� que basta incorporar esses componentes ao seu c�digo e acessar suas funcionalidades atrav�s de sua interface.

Seguran�a

Em um sistema de software, este requisito n�o funcional caracteriza a seguran�a de que acessos n�o autorizados ao sistema e dados associados n�o ser�o permitidos. Portanto, � assegurada a integridade do sistema quanto a ataques intencionais ou acidentes. Dessa forma, a seguran�a � vista como a probabilidade de que a amea�a de algum tipo ser� repelida.

Adicionalmente, � medida que os sistemas de software tornam-se distribu�dos e conectados a redes externas, os requisitos de seguran�a v�o se tornando cada vez mais importantes. Exemplos de requisitos de seguran�a s�o:

• Apenas pessoas que tenham sido autenticadas por um componente de controle acesso e autentica��o poder�o visualizar informa��es dado que a confidencialidade permite esse tipo de acesso apenas �s pessoas autorizadas.
• As permiss�es de acesso ao sistema podem ser alteradas apenas pelo administrador de sistemas.
• Deve ser feito c�pias (backup) de todos os dados do sistema a cada 24 horas e estas c�pias devem ser guardadas em um local seguro, sendo preferencialmente num local diferente de onde se encontra o sistema.
• Todas as comunica��es externas entre o servidor de dados do sistema e clientes devem ser criptografadas.

Requisitos de seguran�a s�o essenciais em sistemas cr�ticos, tais como sistemas de controle de v�o de aeronaves, uma vez que � imposs�vel confiar num sistema deste tipo se ele n�o for seguro. Assim, pode-se dizer que todos os sistemas cr�ticos possuem associados a eles requisitos de seguran�a. Os requisitos n�o funcionais de seguran�a envolvem diferentes aspectos. A Figura 6 mostra tipos de seguran�a que podemos encontrar.

Tamb�m � importante considerar as diferentes �nfases encontradas para seguran�a:

• Disponibilidade: Refere-se a assegurar o sistema contra qualquer interrup��o de servi�o.
• Integridade: O foco na integridade ocorre principalmente em sistemas comerciais, onde se busca assegurar que acesso ou atualiza��es n�o autorizadas ocorram.
• Confidencialidade: A �nfase aqui � a de n�o permitir a revela��o n�o autorizada de informa��es.
• Seguran�a operacional: Refere-se � fase considerada para o sistema em uso.

Note que para satisfazer ao requisito de qualidade n�o funcional de seguran�a em um sistema de software, alguns m�todos podem ser empregados. Esses m�todos podem ser vistos como um refinamento da meta de prover seguran�a a um sistema de software. Como exemplos desses m�todos, podemos considerar:

Identifica��o

Identifica o nome do usu�rio, informando ao sistema quem est� utilizando-o.

Autentica��o

Visa assegurar que os usu�rios s�o, de fato, quem afirmam ser. Para tanto, fazem um teste de identidade. Este m�todo envolve alguns aspectos, tais como:

• Tipo de protocolo usado: isto requer opera��o de senha.
• Quantidade de autentica��es: pode requerer uma �nica senha ou m�ltiplas senhas ou procedimentos. Por exemplo, alguns bancos j� fazem uso de m�ltiplas senhas durante opera��o de autentica��o.
• Partes envolvidas: isto pode envolver a autentica��o de uma parte envolvida (cliente) ou de ambas as partes envolvidas (cliente e sistema).

Tempo de acesso

Busca limitar o tempo de acesso ao sistema a fim de reduzir qualquer tipo de amea�a.

Auditoria de seguran�a

Objetiva habilitar pessoal autorizado a monitorar o sistema e, seletivamente, rastrear eventos importantes.

Alarme

Esta opera��o visa prevenir acessos, potencialmente suspeitos �s informa��es vitais ou dados do sistema, notificando esses acessos � supervis�o de seguran�a do sistema ou devidas autoridades.

A Figura 7 apresenta alguns m�todos que podem ser empregados em requisitos de seguran�a.

� importante observar que a arquitetura de um sistema de software deve levar em considera��o esses aspectos a fim de atender aos requisitos de seguran�a. Entretanto, o tipo de sistema determinar� quais fatores precisar�o ser levados em conta. Assim, poder� haver a inser��o de componentes espec�ficos de seguran�a bem como a conex�o destes com outros componentes funcionais.

Conclus�o sobre Requisitos N�o Funcionais

A elicita��o de requisitos funcionais e n�o funcionais � etapa fundamental no desenvolvimento de sistemas de software. Elementos de entrada desse processo de elicita��o compreendem os principais influenciadores do sistema, envolvendo projetista, arquiteto e usu�rios.

Aliado a isso, a experi�ncia do arquiteto de software � de grande import�ncia. Como sa�da deste processo, tem-se um conjunto de requisitos funcionais oferecendo suporte �s funcionalidades do sistema e uma lista de requisitos n�o funcionais oferecendo suporte � arquitetura de software. Cabe destacar que, quando da an�lise de arquiteturas candidatas para um sistema de software, um arquiteto ou engenheiro de software considera os requisitos n�o funcionais como um dos principais crit�rios para sua an�lise.

Por fim, � importante notar que uma cobertura completa de todos os poss�veis requisitos n�o funcionais est� fora do objetivo deste artigo. Para tanto, o leitor pode consultar o livro intitulado NonFunctional Requirements in Software Engineering de L. Chung, E. Yu, and J. Mylopoulos. Todavia, um subconjunto dos mais proeminentes requisitos n�o funcionais foi apresentado. Esses requisitos servem, via de regra, como crit�rio para an�lise arquitetural objetivando a defini��o da arquitetura de software de um sistema.

Links �teis

• Voc� conhece o m�todo chin�s?:
  O m�todo chin�s � uma t�cnica de depura��o manual, amplamente utilizada no meio acad�mico, mas especialmente �til quando precisamos analisar um c�digo sem ter o apoio de um editor.
• Criando meu primeiro projeto no Java:
  Neste curso voc� aprender� a criar o seu primeiro programa com Java, e n�o, ele n�o ser� um simples �Hello, World!�.
• Delphi Exceptions: Trabalhando com exce��es em Delphi:
  Neste curso voc� aprender� a realizar o tratamento de exce��es no Delphi, t�cnica que visa garantir o bom funcionamento da aplica��o mesmo na ocorr�ncia de certos erros.

Saiba mais sobre Engenharia de Software ;)

• O que � TDD?:
  Test Driven Development � uma t�cnica de desenvolvimento de software muito utilizada, por possuir algumas boas vantagens.
• Guias Engenharia de Software:
  Encontre aqui os Guias de estudo sobre os principais temas da Engenharia de Software. De metodologias �geis a testes, de requisitos a gest�o de projetos!
• Gest�o de Projeto:
  Neste guia voc� encontrar� o conte�do que precisa para saber como gerenciar projetos de software. Confira abaixo a sequ�ncia de posts que te guiar�o do b�sico ao avan�ado em Gest�o de Projetos.

Refer�ncias:

• Non-Functional Requirements in Software Engineering
• Are All Quality Goals Created Equal? Functional vs. Non-Functional
• Acquisition Practices: Good and Bad
• SEI�s Software Architecture Technology Initiative
• The Software Architecture Portal

Confira outros conte�dos: