Este sub-processo é composto pelas atividades para identificar metas operacionais e restrições de projeto (5.1), definir pontos de composição (5.2), confirmar propagação (5.3), resolver conflitos (5.4) e atualizar o modelo do sistema de software (5.5).
A atividade para identificar metas operacionais e restrições de projeto (5.1) recebe como dados e entrada os SIGs e a tabela de RNF com aspectos. Nesta atividade deve ser elaborada a tabela de RNF com metas operacionais e
restrições de projeto, que é a tabela de aspectos (Tabela 19) acrescida das colunas: id SIG, meta, origem da meta, meta operacional ou restrição de projeto e descrição. Esta tabela tem a finalidade de registrar a classificação do tipo de meta referente a cada SIG e a ação a ser tomada caso a meta seja classificada como meta operacional ou restrição de projeto.
A tabela de RNF com metas operacionais e restrições de projeto é apresentada na Tabela 20.
Tabela 20 – Tabela de RNF com metas operacionais e restrições de projeto (SGH).
Id Id SIG Meta Origem da Meta Meta
Operacional ou Restrição de
Projeto
Descrição
1 SIG1 O sistema deve ser desenvolvido em plataforma web. Definido pelo engenheiro de requisitos Restrição de
Projeto Definir arquitetura do projeto baseada em plataforma web.
2 SIG2 Utilizar um banco de dados
relacional estruturado. engenheiro de Definido pelo requisitos
Restrição de
Projeto Definição da camada de persistência e modelo de dados baseado em um
banco de dados
relacional.
3 SIG6 Armazenar log das
operações para fins de auditoria.
Definido pelo engenheiro de
requisitos
Meta Operacional Novo caso de uso Armazenar Log.
4 SIG5 A cada novo acesso de usuário solicitar identificação, autenticação e validação de acesso.
NFR Meta Operacional Novo caso de uso Autenticar Usuário.
5 SIG7 Recuperar as informações de log a fim de definir as preferências de usuário.
Definido pelo engenheiro de
requisitos
Meta Operacional Novo caso de uso Definir Preferências.
6 SIG2 Utilizar vários atributos por tupla a fim de obter recuperações de dados em até 2 segundos.
NFR Restrição de
Projeto Definição da camada de persistência e modelo de dados.
7 SIG3 Utilizar controle do processo de software por threads para
manipular reservas
concorrentes.
Tática Restrição de
Projeto Codificação de software com threads.
8 SIG4 Obter os melhores recursos computacionais
disponíveis a fim de processar as reservas em até 20 segundos.
Tática Restrição de
Projeto Definição da arquitetura computacional com os melhores recursos computacionais
disponíveis.
Na representação da tabela de RNF com metas operacionais e restrições (Tabela 20) foram apresentadas as colunas referentes ao conteúdo da tabela de RNF com metas operacionais e restrições de projeto e o identificador dos requisitos, para auxiliar o entendimento desta última atividade.
Nesta tabela podem ser observadas as restrições de projeto a serem impostas ao SGH e os novos casos de uso a serem adicionados no modelo de casos uso. Estes casos de uso são identificados somente para metas operacionais, que requerem a inclusão de novas funções no modelo do sistema de software.
Para o RNF (id 1) foi considerada uma restrição de projeto, pois a arquitetura do SGH deve ser definida com base na plataforma web. Para o RNF (id 3) foi considerada meta operacional, pois uma nova função deve ser adicionada no SGH, através do caso de uso Armazenar Log, para que o registro das operações seja realizada pelo sistema, para fins de auditoria.
A atividade para definir pontos de composição (5.2) tem a finalidade de identificar os pontos no fluxo de seqüência de eventos dos casos de uso, onde as metas operacionais devem ser inseridas. A Tabela 21 apresenta a tabela de RNF com composição, que é a tabela de RNF com metas operacionais e restrições de projeto (Tabela 20), acrescida das colunas: caso de uso, ponto de composição, regra de composição e condições da composição.
Tabela 21 – Tabela de RNF com composição (SGH).
Id Caso de Uso Ponto de
Composição Regra de Composição Condições da Composição
Reservar Quarto 6 sobreposição.depois Nenhuma
Registrar Membros 3, 1A1, 1B1, 1C1 sobreposição.depois Nenhuma
Check in 2 sobreposição.depois Nenhuma
Check out 1 sobreposição.depois Nenhuma
Estabelecer Taxas dos
Quartos 2 sobreposição.depois Nenhuma
Manipular Lista de Espera 1 sobreposição.depois Nenhuma
Ganhar e Resgatar Créditos 2 sobreposição.depois Nenhuma
3
Estabelecer Taxas
Promocionais 3 sobreposição.depois Nenhuma
Reservar Quarto 1 sobreposição.antes Nenhuma
Registrar Membros 1 sobreposição.antes Nenhuma
Check in 1 sobreposição.antes Nenhuma
Check out 1 sobreposição.antes Nenhuma
4
Estabelecer Taxas dos
Quartos 1 sobreposição.antes Nenhuma
As linhas apresentadas na tabela de RNF com composição tratam-se apenas dos RNFs que possuem metas operacionais como resultado da decomposição através dos SIGs. As restrições de projeto não necessitam de definições relacionadas à composição, pois não adicionam novas funções ao sistema.
Nesta tabela são identificados os casos de uso que serão afetados pela meta operacional, o ponto na seqüência de eventos do caso de uso afetado, o tipo de regra de composição e, caso necessário, a condição da composição.
As regras de composições definidas para o SGH são do tipo sobreposição, pois não se fez necessário substituir ou mesmo empacotar nenhum fluxo de eventos dos casos de uso do SGH, por isso, não é necessário o preenchimento da coluna condição da composição.
É possível verificar na Tabela 21 que os requisitos não-funcionais id 3 e id 4 possuem impacto em diversos casos de uso e o requisito não-funcional id 5, impacta apenas o caso de uso Armazenar Log.
Um exemplo, da atividade de definir pontos de composição, relacionado ao requisito não-funcional (id 3) é a composição do caso e uso Armazenar Log, definido para o requisito (id 3) na tabela de RNF com meta operacional e restrição de projetos, ao caso de uso Reservar Quarto, depois da execução do passo 6 do seu fluxo básico.
A atividade para confirmar as propagações (5.3) tem a finalidade de analisar e consolidar as propagações inicialmente identificadas, pois a definição dos pontos de composição pode dar uma visão mais clara sobre onde os novos casos de uso devem ser adicionados.
Inicialmente, não existia propagação prevista no requisito não-funcional id 8 (Tabela 20); no entanto, detectou-se que este requisito propaga-se para o sistema como um todo, pois a utilização de melhores recursos computacionais afeta não somente o caso de uso Reservar Quarto, mas o SGH. Com esta constatação, este requisito é considerado um aspecto. A Figura 57 apresenta o novo SIG após esta revisão.
Figura 57 – SIG 4 atualizado (SGH).
A atividade para a resolver conflitos (5.4) tem a finalidade de verificar se os casos de uso afetados possuem a mesma regra de composição a ser aplicada no mesmo ponto de composição. No SGH não foram detectados conflitos entre casos de uso. Apesar da inexistência de conflitos, a tabela de RNF com conflitos deve ser preenchida com a informação da inexistência de conflitos, conforme regras de preenchimento definidas no Apêndice B. A tabela de RNF com prioridades é a tabela de RNF com composição (Tabela 21) acrescida da coluna prioridades da composição.
A atividade para atualizar o modelo do sistema de software (5.5) tem a finalidade de construir um modelo de casos de uso atualizado com os novos casos de uso incluídos. A Figura 58 apresenta o diagrama de casos de uso atualizado do SGH.
Figura 58 – Diagrama de casos de uso atualizado (SGH).
Os casos de uso destacados são os novos casos de uso incluídos no diagrama. Os casos de uso Armazenar Log e Autenticar Usuário são aspectos do SGH, pis são incluídos por mais de um caso de uso. Estes casos de uso possuem o estereótipo <<aspecto>>. O caso de uso Definir Preferência que não é aspecto SGH, não possui o estereótipo <<aspecto>>. A informação sobre os casos de uso que são ou não considerados aspectos deve ser consultada na coluna aspecto (Tabela 19).
Como pode ser observado na Figura 58, ocorreu o inter-relacionamento entre os novos casos de uso Definir Preferências e Armazenar Log. A existência dessa relação se deve ao fato de que o caso de uso Definir
Preferências utiliza as informações de log para que as preferências do usuário
possam ser atualizadas em seu próximo acesso.
As especificações dos novos casos de uso incluídos também devem ser elaboradas. Um exemplo de especificação do caso de uso Autenticar Usuário pode ser observado na Tabela 22.
Tabela 22 – Exemplo da especificação do caso de uso Autenticar Usuário (SGH).
Nome do Caso de Uso Autenticar Usuário
Descrição Breve Identificar, autenticar e validar acesso de usuários ao sistema.
Evento Inicial Os casos de uso Reservar Quarto, Registrar Membros, Check in, Check out e Estabelecer Taxas dos Quartos solicitam autenticação do usuário no sistema antes da execução de qualquer operação.
Fluxo Básico 1. O usuário digita seu nome e sua senha.
2. O sistema identifica, autentica e valida seu acesso. 3. O sistema verifica suas permissões.
4. O caso de uso termina.
Fluxos Alternativos 2A. Usuário não identificado.
2A1. O sistema emite uma mensagem para usuário não identificado. 2A2. O caso de uso termina.
Sub-Fluxos Nenhum.
Requisitos Especiais 4
Pré-condições O usuário está com a janela de pedido de login e senha.
Pós-condições Usuário logado no sistema.
Pontos de Extensão Nenhum.
Pontos de Inclusão Nenhum.
O campo requisitos especiais é preenchido com o identificador do RNF que deu origem à nova especificação. Demais especificações dos casos de uso incluídos no modelo atualizado de casos de uso do SGH encontram-se em Bombonatti (2010).