Notas Aula Engenharia Requisitos

UFES - Universidade Federal do Esprito Santo
Engenharia de Requisitos
Notas de Aula
Ricardo de Almeida Falbo

E-mail: falbo@inf.ufes.br
2011/1
ndice
Captulo 1 - Introduo 1.1 Desenvolvimento de Software e Engenharia de Requisitos 1.2 A Organizao deste Texto Captulo 2 Engenharia de Requisitos de Software 2.1 Requisitos 2.2 O Processo de Engenharia de Requisitos 2.3 Engenharia de Requisitos e Normas e Modelos de Qualidade Captulo 3 Levantamento de Requisitos 3.1 Viso Geral do Levantamento de Requisitos 3.2 Tcnicas de Levantamento de Requisitos 3.3 Requisitos e Modelagem de Processos de Negcio 3.4 Escrevendo e Documentando Requisitos de Usurio Captulo 4 Anlise de Requisitos 4.1 Modelagem Conceitual 4.2 A Linguagem de Modelagem Unificada 4.3 O Paradigma Orientado a Objetos 4.4 Um Mtodo de Anlise de Requisitos Funcionais 4.5 Especificao de Requisitos No Funcionais 4.6 O Documento de Especificao de Requisitos Captulo 5 Modelagem de Casos de Uso 5.1 Atores e Casos de Uso 5.2 Diagramas de Casos de Uso 5.3 Descrevendo Casos de Uso 5.4 Relacionamentos entre Casos de Uso 5.5 Trabalhando com Casos de Uso Captulo 6 Modelagem Conceitual Estrutural 6.1 Identificao de Classes 6.2 Identificao de Atributos e Associaes 6.3 Especificao de Hierarquias de Generalizao / Especializao Captulo 7 Modelagem Dinmica 7.1 Tipos de Requisies de Ao 7.2 Diagramas de Transies de Estados 7.3 Diagramas de Sequncia 7.4 Diagramas de Atividades 7.5 Especificao das Operaes 1 1 3 5 5 8 23 29 29 33 52 55 68 70 71 72 79 81 82 85 86 89 91 102 111 116 117 120 132 136 137 140 150 157 163
Captulo 8 Qualidade e Agilidade em Requisitos 8.1 Tcnicas de Leitura de Modelos da Anlise de Requisitos 8.2 Modelagem gil 8.3 Reutilizao na Engenharia de Requisitos Anexo A A Norma ISO/IEC 9126
165 166 170 172 181
Engenharia de Requisitos: Notas de Aula Ricardo de Almeida Falbo UFES - Universidade Federal do Esprito Santo
Captulo 1 - Introduo
Captulo 1 Introduo
Sistemas de software so reconhecidamente importantes ativos estratgicos para diversas organizaes. Uma vez que tais sistemas, em especial os sistemas de informao, tm um papel vital no apoio aos processos de negcio das organizaes, fundamental que os sistemas funcionem de acordo com os requisitos estabelecidos. Neste contexto, uma importante tarefa no desenvolvimento de software a identificao e o entendimento dos requisitos dos negcios que os sistemas vo apoiar (AURUM; WOHLIN, 2005). A Engenharia de Requisitos o processo pelo qual os requisitos de um produto de software so coletados, analisados, documentados e gerenciados ao longo de todo o ciclo de vida do software (AURUM; WOHLIN, 2005). Este texto aborda o processo de Engenharia de Requisitos, concentrando-se nas atividades de levantamento de requisitos e modelagem conceitual. Este captulo apresenta o tema e como o mesmo tratado neste texto. A seo 1.1 discute a relao entre a Engenharia de Requisitos e o processo de software. A seo 1.2 apresenta a organizao deste texto.
1.1 Desenvolvimento de Software e Engenharia de Requisitos

Um processo de software, em uma abordagem de Engenharia de Software, envolve diversas atividades que podem ser classificadas quanto ao seu propsito em: Atividades de Desenvolvimento (ou Tcnicas): so as atividades diretamente relacionadas ao processo de desenvolvimento do software, ou seja, que contribuem diretamente para o desenvolvimento do produto de software a ser entregue ao cliente. So exemplos de atividades de desenvolvimento: levantamento e anlise de requisitos, projeto e implementao. Atividades de Gerncia: envolvem atividades relacionadas ao gerenciamento do projeto de maneira abrangente. Incluem, dentre outras: atividades de planejamento e acompanhamento gerencial do projeto (processo de Gerncia de Projetos), tais como realizao de estimativas, elaborao de cronogramas, anlise dos riscos do projeto etc.; atividades relacionadas gerncia da evoluo dos diversos artefatos produzidos nos projetos de software (processo de Gerncia de Configurao); atividades relacionadas gerncia de ativos reutilizveis de uma organizao (processo de Gerncia de Reutilizao) etc. Atividades de Controle da Qualidade: so aquelas relacionadas com a avaliao da qualidade do produto em desenvolvimento e do processo de software utilizado. Incluem atividades de verificao, validao e garantia da qualidade.
As atividades de desenvolvimento formam a espinha dorsal do desenvolvimento e, de maneira geral, so realizadas segundo uma ordem estabelecida no planejamento. As
atividades de gerncia e de controle da qualidade so, muitas vezes, ditas atividades de apoio, pois no esto ligadas diretamente construo do produto final: o software a ser entregue para o cliente, incluindo toda a documentao necessria. Essas atividades, normalmente, so realizadas ao longo de todo o ciclo de vida, sempre que necessrio ou em pontos prestabelecidos durante o planejamento, ditos marcos ou pontos de controle. A Figura 1.1 mostra a relao entre esses tipos de atividades. Atividades de Gerncia
Atividades de Desenvolvimento
Produto de Software
Atividades de Controle da Qualidade Figura 1.1 Atividades do Processo de Software No que concerne s atividades tcnicas, tipicamente o processo de software inicia-se com o Levantamento de Requisitos, quando os requisitos do sistema a ser desenvolvido so preliminarmente capturados e organizados. Uma vez capturados, os requisitos devem ser modelados, avaliados e documentados. Uma parte essencial dessa fase a elaborao de modelos descrevendo o qu o software tem de fazer (e no como faz-lo), dita Modelagem Conceitual. At este momento, a nfase est sobre o domnio do problema e no se deve pensar na soluo tcnica, computacional a ser adotada. Com os requisitos pelo menos parcialmente capturados e especificados na forma de modelos, pode-se comear a trabalhar no domnio da soluo. Muitas solues so possveis para o mesmo conjunto de requisitos e elas so intrinsecamente ligadas a uma dada plataforma de implementao (linguagem de programao, mecanismo de persistncia a ser adotado etc.). A fase de projeto tem por objetivo definir e especificar uma soluo a ser implementada. uma fase de tomada de deciso, tendo em vista que muitas solues so possveis. Uma vez projetado o sistema, pode dar-se incio implementao, quando as unidades de software do projeto so implementadas e testadas individualmente. Gradativamente, os elementos vo sendo integrados e testados (teste de integrao), at se obter o sistema, quando o todo deve ser testado (teste de sistema). Por fim, uma vez testado no ambiente de desenvolvimento, o software pode ser colocado em produo. Usurios devem ser treinados, o ambiente de produo deve ser configurado e o sistema deve ser instalado e testado, agora pelos usurios no ambiente de produo (testes de homologao ou aceitao). Caso o software demonstre prover as capacidades requeridas, ele pode ser aceito e a operao iniciada. Requisitos tm um papel central no desenvolvimento de software, uma vez que uma das principais medidas do sucesso de um software o grau no qual ele atende aos objetivos e requisitos para os quais foi construdo. Requisitos so a base para estimativas, modelagem, projeto, implementao, testes e at mesmo para a manuteno. Portanto, esto presentes ao longo de todo o ciclo de vida de um software.
Nos estgios iniciais de um projeto, requisitos tm de ser levantados, entendidos e documentados (atividades de Levantamento, Anlise e Documentao de Requisitos). Dada a importncia dos requisitos para o sucesso de um projeto, atividades de controle da qualidade devem ser realizadas para verificar, validar e garantir a qualidade dos requisitos, uma vez que os custos sero bem maiores se defeitos em requisitos forem identificados tardiamente. Mesmo quando coletados de forma sistemtica, requisitos mudam. Os negcios so dinmicos e no h como garantir que os requisitos no sofrero alteraes. Assim, fundamental gerenciar a evoluo dos requisitos, bem como manter a rastreabilidade entre os requisitos e os demais artefatos produzidos no projeto (atividade de Gerncia de Requisitos). Como se pode observar, o tratamento de requisitos envolve atividades de desenvolvimento (Levantamento, Anlise e Documentao de Requisitos), gerncia (Gerncia de Requisitos) e controle da qualidade (Verificao, Validao e Garantia da Qualidade de Requisitos). Ao conjunto de atividades relacionadas a requisitos, d-se o nome de Processo de Engenharia de Requisitos.
1.2 - A Organizao deste Texto

Este texto procura oferecer uma viso geral da Engenharia de Requisitos de Software, discutindo as principais atividades desse processo e como realiz-las. nfase especial dada aplicao das tcnicas de modelagem e especificao de Sistemas de Informao, i.e., sistemas desenvolvidos para apoiar processos de negcio das organizaes. Nos captulos que se seguem, os seguintes temas so abordados: Captulo 2 Engenharia de Requisitos de Software: inicia discutindo o que so requisitos e tipos e nveis de requisitos. A seguir, apresenta o processo de engenharia de requisitos considerado neste texto, o qual contm as seguintes atividades: Levantamento de Requisitos, Anlise de Requisitos, Documentao de Requisitos, Verificao e Validao de Requisitos e Gerncia de Requisitos. Discute-se, tambm, como as principais normas e modelos de qualidade de processos de software tratam a questo dos requisitos. Captulo 3 Levantamento de Requisitos: prov uma viso geral do processo de levantamento de requisitos e aborda tcnicas para levantar requisitos, dentre elas entrevistas, questionrios, observao, investigao de documentos e prototipagem. Aborda-se, tambm, a modelagem de processos de negcio e como ela pode apoiar o levantamento de requisitos. Finalmente, discute-se como escrever e documentar requisitos de usurio. Captulo 4 Anlise de Requisitos: trata da anlise de requisitos, discutindo a anlise e especificao de requisitos funcionais (modelagem conceitual) e no funcionais. O captulo inicia provendo uma introduo modelagem conceitual. Na sequncia apresentada brevemente a Linguagem de Modelagem Unificada (Unified Modeling Language UML), amplamente usada na Anlise de Requisitos e os conceitos da orientao a objetos, paradigma adotado neste texto. Um mtodo de anlise de requisitos funcionais apresentado. A seguir, discute-se a especificao de requisitos no funcionais. Por fim, a documentao da atividade de anlise de requisitos abordada.
Captulo 5 Modelagem de Casos de Uso: discute o papel da modelagem de casos de uso na especificao de requisitos funcionais de sistema. Apresenta os elementos centrais da modelagem de casos de uso, o diagrama de casos de uso da UML e discute como descrever casos de uso textualmente. Captulo 6 Modelagem Estrutural: trata da modelagem dos principais conceitos do domnio, suas relaes e propriedades, permitindo representar o conhecimento do domnio relevante para o sistema em desenvolvimento. A elaborao de diagramas de classes da UML o foco deste captulo. Captulo 7 Modelagem Dinmica: aborda os modelos usados para especificar as mudanas vlidas no estado dos objetos de domnio, bem como para modelar o comportamento esperado do sistema. O foco deste captulo a elaborao de diagramas de estados e diagramas de atividades. Captulo 8 Qualidade e Agilidade em Requisitos: explora tcnicas de leitura de modelos, visando apoiar a verificao da consistncia entre os diversos artefatos produzidos durante a anlise de requisitos; apresenta o enfoque da modelagem gil; e discute abordagens para reutilizao na Engenharia de Requisitos, dentre elas Engenharia de Domnio, Ontologias e Padres de Anlise.
Referncias do Captulo AURUM, A., WOHLIN, C., Engineering and Managing Software Requirements, SpringerVerlag, 2005.
Captulo 2 Engenharia de Requisitos de Software

Requisitos tm um papel central no processo de software, sendo considerados um fator determinante para o sucesso ou fracasso de um projeto de software. O processo de levantar, analisar, documentar, gerenciar e controlar a qualidade dos requisitos chamado de Engenharia de Requisitos. Este captulo d uma viso geral da Engenharia de Requisitos. A seo 2.1 apresenta diferentes definies do conceito de requisito e trata de tipos e nveis de requisitos. A seo 2.2 aborda o processo de engenharia de requisitos, discutindo cada uma de suas atividades. A seo 2.3 discute como as principais normas e modelos de qualidade de processos de software tratam a questo dos requisitos. A seo 2.4 apresenta a Linguagem de Modelagem Unificada (Unified Modeling Language UML), amplamente usada na modelagem conceitual. Finalmente, a seo 2.5 discute os principais conceitos da orientao a objetos, paradigma de desenvolvimento adotado neste texto.
2.1 Requisitos
Existem diversas definies para requisito de software na literatura, dentre elas: Requisitos de um sistema so descries dos servios que devem ser fornecidos por esse sistema e as suas restries operacionais (SOMMERVILLE, 2007). Um requisito de um sistema uma caracterstica do sistema ou a descrio de algo que o sistema capaz de realizar para atingir seus objetivos (PFLEEGER, 2004). Um requisito alguma coisa que o produto tem de fazer ou uma qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON, 2006).
Com base nessas e em outras definies, pode-se dizer que os requisitos de um sistema incluem especificaes dos servios que o sistema deve prover, restries sob as quais ele deve operar, propriedades gerais do sistema e restries que devem ser satisfeitas no seu processo de desenvolvimento. As vrias definies acima apresentadas apontam para a existncia de diferentes tipos de requisitos. Uma classificao amplamente aceita quanto ao tipo de informao documentada por um requisito faz a distino entre requisitos funcionais e requisitos no funcionais. Requisitos Funcionais: so declaraes de servios que o sistema deve prover, descrevendo o que o sistema deve fazer (SOMMERVILLE, 2007). Um requisito funcional descreve uma interao entre o sistema e o seu ambiente (PFLEEGER, 2004), podendo descrever, ainda, como o sistema deve reagir a entradas especficas, como o sistema deve se comportar em
situaes especficas e o que o sistema no deve fazer (SOMMERVILLE, 2007). Requisitos No Funcionais: descrevem restries sobre os servios ou funes oferecidos pelo sistema (SOMMERVILLE, 2007), as quais limitam as opes para criar uma soluo para o problema (PFLEEGER, 2004). Neste sentido, os requisitos no funcionais so muito importantes para a fase de projeto (design), servindo como base para a tomada de decises nessa fase.
Os requisitos no funcionais tm origem nas necessidades dos usurios, em restries de oramento, em polticas organizacionais, em necessidades de interoperabilidade com outros sistemas de software ou hardware ou em fatores externos como regulamentos e legislaes (SOMMERVILLE, 2007). Assim, os requisitos no funcionais podem ser classificados quanto sua origem. Existem diversas classificaes de requisitos no funcionais. Sommerville (2007), por exemplo, classifica-os em: Requisitos de produto: especificam o comportamento do produto (sistema). Referem-se a atributos de qualidade que o sistema deve apresentar, tais como confiabilidade, usabilidade, eficincia, portabilidade, manutenibilidade e segurana. Requisitos organizacionais: so derivados de metas, polticas e procedimentos das organizaes do cliente e do desenvolvedor. Incluem requisitos de processo (padres de processo e modelos de documentos que devem ser usados), requisitos de implementao (tal como a linguagem de programao a ser adotada), restries de entrega (tempo para chegar ao mercado - time to market, restries de cronograma etc.), restries oramentrias (custo, custo-benefcio) etc. Requisitos externos: referem-se a todos os requisitos derivados de fatores externos ao sistema e seu processo de desenvolvimento. Podem incluir requisitos de interoperabilidade com sistemas de outras organizaes, requisitos legais (tais como requisitos de privacidade) e requisitos ticos.
No que se refere aos RNFs de produto, eles podem estar relacionados a propriedades emergentes do sistema como um todo, ou seja, propriedades que no podem ser atribudas a uma parte especfica do sistema, mas que, ao contrrio, s aparecem aps a integrao de seus componentes, tal como confiabilidade (SOMMERVILLE, 2007). Contudo, algumas vezes, essas caractersticas podem estar associadas a uma funo especfica ou a um conjunto de funes. Por exemplo, uma certa funo pode ter restries severas de desempenho, enquanto outras funes do mesmo sistema no apresentam tal restrio. Ainda que a classificao em requisitos funcionais e no funcionais seja a mais amplamente aceita, h outras classificaes de requisitos. Por exemplo, Sommerville (2007) considera, alm de requisitos funcionais e no funcionais, requisitos de domnio. Segundo esse autor, requisitos de domnio so provenientes do domnio de aplicao do sistema e refletem caractersticas e restries desse domnio. Eles so derivados do domnio de aplicao e podem restringir requisitos funcionais existentes ou estabelecer como clculos especficos devem ser realizados, refletindo fundamentos do domnio de aplicao.
Requisitos de domnio na concepo de Sommerville so o que outros autores, tal como Wiegers (2003), chamam de regras de negcio. Por exemplo, em um sistema de matrcula de uma universidade, uma importante regra de negcio diz que um aluno s pode se matricular em uma turma de uma disciplina se ele tiver cumprido seus prrequisitos. Essas regras de negcio geralmente incluem terminologia especfica do domnio e fazem referncia a conceitos do domnio (SOMMERVILLE, 2007). Assim, so mais facilmente capturadas na fase de modelagem conceitual. Os requisitos devem ser redigidos de modo a serem passveis de entendimento pelos diversos interessados (stakeholders). Clientes1, usurios finais e desenvolvedores so todos interessados em requisitos, mas tm expectativas diferentes. Enquanto desenvolvedores e usurios finais tm interesse em detalhes tcnicos, clientes requerem descries mais abstratas. Assim, til apresentar requisitos em diferentes nveis de descrio. Sommerville (2007) sugere dois nveis de descrio de requisitos: Requisitos de Usurio: so declaraes em linguagem natural acompanhadas de diagramas intuitivos de quais servios so esperados do sistema e das restries sob as quais ele deve operar. Devem estar em um nvel de abstrao mais alto, de modo que sejam compreensveis pelos usurios do sistema que no possuem conhecimento tcnico. Requisitos de Sistema: definem detalhadamente as funes, servios e restries do sistema. So verses expandidas dos requisitos de usurio usados pelos desenvolvedores para projetar, implementar e testar o sistema. Como requisitos de sistema so mais detalhados, as especificaes em linguagem natural so insuficientes e para especific-los, notaes mais especializadas devem ser utilizadas.
Vale destacar que esses nveis de descrio de requisitos so aplicados em momentos diferentes e com propsitos distintos. Requisitos de usurio so elaborados nos estgios iniciais do desenvolvimento (levantamento preliminar de requisitos) e servem de base para um entendimento entre clientes e desenvolvedores acerca do que o sistema deve contemplar. Esses requisitos so, normalmente, usados como base para a contratao e o planejamento do projeto. Requisitos de sistema, por sua vez, so elaborados como parte dos esforos diretos para o desenvolvimento do sistema, capturando detalhes importantes para as fases tcnicas posteriores do processo de desenvolvimento, a saber projeto, implementao e testes. Entretanto, no se deve perder de vista que requisitos de sistema so derivados dos requisitos de usurio. Os requisitos de sistema acrescentam detalhes, explicando os servios e funes a serem providos pelo sistema em desenvolvimento. Os interessados nos requisitos de sistema necessitam conhecer mais precisamente o que o sistema far, pois eles esto preocupados com o modo como o sistema apoiar os processos de negcio ou porque esto envolvidos na sua construo (SOMMERVILLE, 2007).
importante notar a distino que se faz aqui entre clientes e usurios finais. Consideram-se clientes aqueles que contratam o desenvolvimento do sistema e que, muitas vezes, no usaro diretamente o sistema. Eles esto mais interessados nos resultados da utilizao do sistema pelos usurios do que no sistema em si. Usurios, por outro lado, so as pessoas que utilizaro o sistema em seu dia a dia. Ou seja, os usurios so as pessoas que vo operar ou interagir diretamente com o sistema.
Uma vez que requisitos de usurio e de sistema tm propsitos e pblico alvo diferentes, til descrev-los em documentos diferentes. Pfleeger (2004) sugere que dois tipos de documentos de requisitos sejam elaborados: Documento de Definio de Requisitos, ou somente Documento de Requisitos: deve ser escrito de maneira que o cliente possa entender, na forma de uma listagem do qu o cliente espera que o sistema proposto faa. Ele representa um consenso entre o cliente e o desenvolvedor sobre o qu o cliente quer. Documento de Especificao de Requisitos: redefine os requisitos de usurio em termos mais tcnicos, apropriados para o desenvolvimento de software, sendo produzido por analistas de requisitos.
Vale ressaltar que deve haver uma correspondncia direta entre cada requisito de usurio listado no documento de requisitos e os requisitos de sistema tratados no documento de especificao de requisitos.
2.2 O Processo de Engenharia de Requisitos

A Engenharia de Requisitos de Software o ramo da Engenharia de Software que envolve as atividades relacionadas com a definio dos requisitos de software de um sistema, desenvolvidas ao longo do ciclo de vida de software (KOTONYA; SOMMERVILLE, 1998). O processo de engenharia de requisitos envolve criatividade, interao de diferentes pessoas, conhecimento e experincia para transformar informaes diversas (sobre a organizao, sobre leis, sobre o sistema a ser construdo etc.) em documentos e modelos que direcionem o desenvolvimento de software (KOTONYA; SOMMERVILLE, 1998). A Engenharia de Requisitos fundamental, pois possibilita, dentre outros, estimar custo e tempo de maneira mais precisas e melhor gerenciar mudanas em requisitos. Dentre os problemas de um processo de engenharia de requisitos ineficiente, podem-se citar (KOTONYA; SOMMERVILLE, 1998): (i) requisitos inconsistentes, (ii) produto final com custo maior do que o esperado, (iii) software instvel e com altos custos de manuteno e (iv) clientes insatisfeitos. A Engenharia de Requisitos pode ser descrita como um processo, ou seja, um conjunto organizado de atividades que deve ser seguido para derivar, avaliar e manter os requisitos e artefatos relacionados. Uma descrio de um processo, de forma geral, deve incluir, alm das atividades a serem seguidas, a estrutura ou sequncia dessas atividades, quem responsvel por cada atividade, suas entradas e sadas, as ferramentas usadas para apoiar as atividades e os mtodos, tcnicas e diretrizes a serem seguidos na sua realizao. Processos de engenharia de requisitos podem variar muito de uma organizao para outra, ou at mesmo dentro de uma organizao especfica, em funo de caractersticas dos projetos. A definio de um processo apropriado organizao traz muitos benefcios, pois uma boa descrio do mesmo fornecer orientaes e reduzir a probabilidade de esquecimento ou de uma execuo superficial. No entanto, no faz sentido falar em processo ideal ou definir algum e imp-lo a uma organizao. Ao invs
disto, as organizaes devem iniciar com um processo genrico e adapt-lo para um processo mais detalhado, que seja apropriado s suas reais necessidades (SOMMERVILLE; SAWYER, 1997). A implantao de processos em uma organizao deve ser feita segundo as necessidades da mesma, ou seja, o processo deve ser definido de acordo com as caractersticas da organizao. Existem, portanto, fatores que contribuem para a variabilidade do processo de engenharia de requisitos, dentre eles a maturidade tcnica, o envolvimento disciplinar, a cultura organizacional e os domnios de aplicao nos quais a organizao atua (KOTONYA; SOMMERVILLE, 1998). Wiegers (2003) destaca alguns benefcios que um processo de Engenharia de Requisitos de alta qualidade pode trazer, dentre eles: menor quantidade de defeitos nos requisitos, reduo de retrabalho, desenvolvimento de menos caractersticas desnecessrias, diminuio de custos, desenvolvimento mais rpido, menos problemas de comunicao, alteraes de escopo reduzidas, estimativas mais confiveis e maior satisfao dos clientes e membros da equipe. Ainda que diferentes projetos requeiram processos com caractersticas especficas para contemplar suas peculiaridades, possvel estabelecer um conjunto de atividades bsicas que deve ser considerado na definio de um processo de engenharia de requisitos. Tomando por base o processo proposto por Kotonya e Sommerville (1998), neste texto considera-se que um processo de engenharia de requisitos deve contemplar, tipicamente, as atividades mostradas na Figura 2.1: levantamento de requisitos, anlise de requisitos, documentao de requisitos, verificao e validao de requisitos e gerncia de requisitos.
Figura 2.1 Processo de Engenharia de Requisitos (adaptado de (KOTONYA; SOMMERVILLE, 1998)) O processo comea pelo levantamento de requisitos, que deve levar em conta necessidades dos usurios e clientes, informaes de domnio, sistemas existentes, regulamentos, leis etc. Uma vez identificados requisitos, possvel iniciar a atividade de anlise, quando os requisitos levantados so usados como base para a modelagem do sistema. Tanto no levantamento quanto na anlise de requisitos, importante documentar requisitos e modelos. Conforme discutido anteriormente, para documentar
10
requisitos, dois documentos so normalmente utilizados: o Documento de Requisitos, contendo uma lista dos requisitos de usurio identificados, e o Documento de Especificao de Requisitos, que registra os requisitos de sistema e os vrios diagramas resultantes do trabalho de anlise. Os documentos produzidos so, ento, verificados e validados. Adicionalmente, um esforo de garantia da qualidade deve ser realizado, visando garantir conformidade em relao a padres e ao processo estabelecidos pela organizao. Caso clientes, usurios e desenvolvedores estejam de acordo com os requisitos, o processo de desenvolvimento pode avanar; caso contrrio, deve-se retornar atividade correspondente para resolver os problemas identificados. Em paralelo a todas as atividades anteriormente mencionadas, h a gerncia de requisitos, que se ocupa em gerenciar mudanas nos requisitos. Vale destacar que no h limites bem definidos entre as atividades acima citadas. Na prtica, elas so intercaladas e existe um alto grau de iterao e feedback entre elas. O processo executado at que todos os usurios estejam satisfeitos e concordem com os requisitos ou at que a presso do cronograma precipite o incio da fase de projeto, o que indesejvel (KOTONYA; SOMMERVILLE, 1998). Alm disso, ao se adotar um modelo de ciclo de vida iterativo, essas atividades podem ser realizadas muitas vezes. Pode-se comear com um levantamento preliminar de requisitos que considere apenas requisitos de usurio. Esses requisitos podem ser documentados em um Documento de Requisitos e avaliados (verificao e validao). Caso haja acordo em relao aos requisitos de usurio, pode-se iniciar um ciclo de levantamento detalhado de requisitos e anlise, produzindo uma verso do Documento de Especificao de Requisitos. Quando h acordo em relao aos requisitos e modelos contidos nesse documento, o desenvolvimento pode prosseguir para a poro tratada nessa iterao, enquanto um novo ciclo de levantamento e anlise se inicia para tratar outros aspectos do sistema. A seguir, as atividades do processo de engenharia de requisitos proposto so discutidas com um pouco mais de detalhes.
2.2.1 Levantamento de Requisitos

O levantamento de requisitos corresponde fase inicial do processo de engenharia de requisitos e envolve as atividades de descoberta dos requisitos. Nessa fase, um esforo conjunto de clientes, usurios e especialistas de domnio necessrio, com o objetivo de entender a organizao, seus processos, necessidades, deficincias dos sistemas de software atuais, possibilidades de melhorias, bem como restries existentes. Trata-se de uma atividade complexa que no se resume somente a perguntar s pessoas o que elas desejam, mas sim analisar cuidadosamente a organizao, o domnio da aplicao e os processos de negcio no qual o sistema ser utilizado (KOTONYA; SOMMERVILLE, 1998). Para levantar quais so os requisitos de um sistema, devem-se obter informaes dos interessados (stakeholders), consultar documentos, obter conhecimentos do domnio e estudar o negcio da organizao. Neste contexto, quatro dimenses devem ser consideradas, como ilustra a Figura 2.2 (KOTONYA; SOMMERVILLE, 1998):
11
Levantamento de requisitos
Figura 2.2 - Dimenses do levantamento de requisitos Entendimento do domnio da aplicao: entendimento geral da rea na qual o sistema ser aplicado; Entendimento do problema: entendimento dos detalhes do problema especfico a ser resolvido com o auxlio do sistema a ser desenvolvido; Entendimento do negcio: entender como o sistema ir afetar a organizao e como contribuir para que os objetivos do negcio e os objetivos gerais da organizao sejam atingidos; Entendimento das necessidades e das restries dos interessados: entender as demandas de apoio para a realizao do trabalho de cada um dos interessados no sistema, entender os processos de trabalho a serem apoiados pelo sistema e o papel de eventuais sistemas existentes na execuo e conduo dos processos de trabalho. Consideram-se interessados no sistema, todas as pessoas que so afetadas pelo sistema de alguma maneira, dentre elas clientes, usurios finais e gerentes de departamentos onde o sistema ser instalado.
A atividade de levantamento de requisitos dominada por fatores humanos, sociais e organizacionais e envolve pessoas com diferentes conhecimentos e objetivos, o que a torna complexa. Christel e Kang (apud PRESSMAN, 2006) citam alguns problemas que tornam o levantamento de requisitos uma tarefa difcil: Problemas de escopo: as fronteiras do sistema so mal definidas ou os clientes/usurios especificam detalhes tcnicos desnecessrios que podem confundir, em vez de esclarecer, os objetivos globais do sistema. Problemas de entendimento: Os clientes/usurios no esto completamente certos do que necessrio, tm pouca compreenso das capacidades e limitaes de um ambiente computacional, no tm pleno entendimento do domnio do problema, tm dificuldade de comunicar suas necessidades, omitem informao que acreditam ser bvia, especificam requisitos que conflitam com as necessidades de outros clientes/usurios ou especificam requisitos que so ambguos ou impossveis de testar.
12
Problemas de volatilidade: Os requisitos mudam ao longo do tempo.
Kotonya e Sommerville (1998) destacam outras dificuldades que complementam e reforam os problemas apontados por Christel e Kang, a saber: Pode ser difcil compreender e coletar informaes quando existem muitos termos desconhecidos, manuais tcnicos etc. Pessoas que entendem o problema a ser resolvido podem ser muito ocupadas e no ter muito tempo para, juntamente como analista, levantar os requisitos e entender o sistema. Polticas organizacionais podem influenciar nos requisitos de um sistema. Os interessados no sabem muito bem o que querem do sistema e no conhecem muitos termos.
Diversas tcnicas podem ser utilizadas no levantamento de requisitos, as quais podem possuir diferentes objetos de investigao ou podem ter foco em tipos diferentes de requisitos. Assim, til empregar vrias dessas tcnicas concomitantemente, de modo a se ter um levantamento de requisitos mais eficaz. Dentre as vrias tcnicas, podem ser citadas (KENDALL; KENDALL, 2010; KOTONYA; SOMMERVILLE, 1998; AURUM; WOHLIN, 2005): Entrevistas: tcnica amplamente utilizada, que consiste em conversas direcionadas com um propsito especfico e com formato pergunta-resposta. Seu objetivo descobrir problemas a serem tratados, levantar procedimentos importantes e saber a opinio e as expectativas do entrevistado sobre o sistema. Questionrios: o uso de questionrios possibilita ao analista obter informaes como postura, crenas, comportamentos e caractersticas de vrias pessoas que sero afetas pelo sistema. Observao: consiste em observar o comportamento e o ambiente dos indivduos de vrios nveis organizacionais. Utilizando-se essa tcnica, possvel capturar o que realmente feito e qual tipo de suporte computacional realmente necessrio. Ajuda a confirmar ou refutar informaes obtidas com outras tcnicas e ajuda a identificar tarefas que podem ser automatizadas e que no foram identificadas pelos interessados. Anlise de documentos: pela anlise de documentos existentes na organizao, analistas capturam informaes e detalhes difceis de conseguir por entrevista e observao. Documentos revelam um histrico da organizao e sua direo. Cenrios: com o uso desta tcnica, um cenrio de interao entre o usurio final e o sistema montado e o usurio simula sua interao com o sistema nesse cenrio, explicando ao analista o que ele est fazendo e de que informaes ele precisa para realizar a tarefa descrita no cenrio. O uso de cenrios ajuda a entender requisitos, a expor o leque de possveis interaes e a revelar facilidades requeridas. Prototipagem: um prottipo uma verso preliminar do sistema, muitas vezes no operacional e descartvel, que apresentada ao usurio para capturar informaes especficas sobre seus requisitos de informao, observar reaes
13
iniciais e obter sugestes, inovaes e informaes para estabelecer prioridades e redirecionar planos. Dinmicas de Grupo: h vrias tcnicas de levantamento de requisitos que procuram explorar dinmicas de grupo para a descoberta e o desenvolvimento de requisitos, tais como Brainstorming e JAD (Joint Application Development). Na primeira, representantes de diferentes grupos de interessados engajam-se em uma discusso informal para rapidamente gerarem o maior nmero possvel de ideias. Na segunda, interessados e analistas se renem para discutir problemas a serem solucionados e solues possveis. Com as diversas partes envolvidas representadas, decises podem ser tomadas e questes podem ser resolvidas mais rapidamente. A principal diferena entre JAD e Brainstorming que, em JAD, tipicamente os objetivos do sistema j foram estabelecidos antes dos interessados participarem. Alm disso, sesses JAD so normalmente bem estruturadas, com passos, aes e papis de participantes definidos.
2.2.2 Anlise de Requisitos

Uma vez identificados requisitos, possvel iniciar a atividade de anlise, quando os requisitos levantados so usados como base para a modelagem do sistema. Conforme discutido anteriormente, requisitos de usurio so escritos tipicamente em linguagem natural, pois eles devem ser compreendidos por pessoas que no sejam especialistas tcnicos. Contudo, til expressar requisitos mais detalhados do sistema de maneira mais tcnica. Para tal, diversos tipos de modelos podem ser utilizados. Esses modelos so representaes grficas que descrevem processos de negcio, o problema a ser resolvido e o sistema a ser desenvolvido. Por utilizarem representaes grficas, modelos so geralmente mais compreensveis do que descries detalhadas em linguagem natural (SOMMERVILLE, 2007). De maneira simples, um modelo uma simplificao da realidade enfocando certos aspectos considerados relevantes segundo a perspectiva do modelo, e omitindo os demais. Modelos so construdos para se obter uma melhor compreenso da poro da realidade sendo modelada. Em essncia, a fase de anlise uma atividade de modelagem. A modelagem nesta fase dita conceitual, pois ela se preocupa com o domnio do problema e no com solues tcnicas para o mesmo. Os modelos de anlise so elaborados para se obter uma compreenso maior acerca do sistema a ser desenvolvido e para especific-lo. Diferentes modelos podem ser construdos para representar diferentes perspectivas. Tipicamente, duas principais perspectivas so consideradas na fase de anlise: Perspectiva estrutural: busca modelar os conceitos, propriedades e relaes do domnio que so relevantes para o sistema em desenvolvimento. Prov uma viso esttica das informaes que o sistema necessita tratar e, portanto, refere-se s representaes que o sistema ter de prover para abstrair entidades do mundo real. Diagramas de classes so usados para modelar esta perspectiva. Perspectiva comportamental: visa modelar o comportamento geral do sistema, de uma de suas funcionalidades ou de uma entidade especfica ao
14
longo do tempo. Prov uma viso do comportamento do sistema ou de uma parcela do sistema. Diagramas de casos de uso, diagramas de atividades, diagramas de estados e diagramas de interao so usados para modelar essa viso. Os modelos criados durante a atividade de anlise de requisitos cumprem os seguintes papis (PRESSMAN, 2006): Ajudam o analista a entender a informao, a funo e o comportamento do sistema, tornando a tarefa de anlise de requisitos mais fcil e sistemtica; Tornam-se o ponto focal para a reviso e, portanto, a chave para a determinao da consistncia da especificao.
A anlise de requisitos uma atividade extremamente vinculada ao levantamento de requisitos. Durante o levantamento de requisitos, alguns problemas so identificados e tratados. Entretanto, determinados problemas somente so identificados por meio de uma anlise mais detalhada. A anlise de requisitos ajuda a entender e detalhar os requisitos levantados, a descobrir problemas nesses requisitos e a obter a concordncia sobre as alteraes, de modo a satisfazer a todos os envolvidos. Seu objetivo estabelecer um conjunto acordado de requisitos completos, consistentes e sem ambiguidades, que possa ser usado como base para as demais atividades do processo de desenvolvimento de software (KOTONYA; SOMMERVILLE, 1998). De forma resumida, pode-se dizer que a anlise atende a dois propsitos principais: (i) prover uma base para o entendimento e concordncia entre clientes e desenvolvedores sobre o que o sistema deve fazer e (ii) prover uma especificao que guie os desenvolvedores na demais etapas do desenvolvimento, sobretudo no projeto, implementao e testes do sistema (PFLEEGER, 2004). O processo de engenharia de requisitos dominado por fatores humanos, sociais e organizacionais. Ele envolve pessoas de diferentes reas de conhecimento e com objetivos individuais e organizacionais diferentes. Dessa forma, comum que cada indivduo tente influenciar os requisitos para que seu objetivo seja alcanado, sem necessariamente alcanar os objetivos dos demais (KOTONYA; SOMMERVILLE, 1998). Problemas e conflitos encontrados nos requisitos devem ser listados. Usurios, clientes, especialistas de domnio e engenheiros de requisitos devem discutir os requisitos que apresentam problemas, negociar e chegar a um acordo sobre as modificaes a serem feitas. Idealmente, as discusses devem ser governadas pelas necessidades da organizao, incluindo o oramento e o cronograma disponveis. No entanto, muitas vezes, as negociaes so influenciadas por consideraes polticas e os requisitos so definidos em funo da posio e da personalidade dos indivduos e no em funo de argumentos e razes (KOTONYA; SOMMERVILLE, 1998). A maior parte do tempo da negociao utilizada para resolver conflitos de requisitos. Quando discusses informais entre analistas, especialistas de domnio e usurios no forem suficientes para resolver os problemas, necessria a realizao de reunies de negociao, que envolvem (KOTONYA; SOMMERVILLE, 1998): Discusso: os requisitos que apresentam problemas so discutidos e os interessados presentes opinam sobre eles.
15
Priorizao: requisitos so priorizados para identificar requisitos crticos e ajudar nas decises e planejamento. Concordncia: solues para os problemas so identificadas, mudanas so feitas e um acordo sobre o conjunto de requisitos acertado.
2.2.3 Documentao de Requisitos

Os requisitos e modelos capturados nas etapas anteriores devem ser descritos e apresentados em documentos. A documentao , portanto, uma atividade de registro e oficializao dos resultados da engenharia de requisitos. Como resultado, um ou mais documentos devem ser produzidos. Uma boa documentao fornece muitos benefcios, tais como (IEEE, 1998; NUSEIBEH; EASTERBROOK, 2000): (i) facilita a comunicao dos requisitos; (ii) reduz o esforo de desenvolvimento, pois sua preparao fora usurios e clientes a considerar os requisitos atentamente, evitando retrabalho nas fases posteriores; (iii) fornece uma base realstica para estimativas; (iv) fornece uma base para verificao e validao; (v) facilita a transferncia do software para novos usurios e/ou mquinas e (vi) serve como base para futuras manutenes ou incremento de novas funcionalidades. A documentao dos requisitos tem um conjunto diversificado de interessados, dentre eles (SOMMERVILLE, 2007; KOTONYA; SOMMERVILLE, 1998): Clientes, Usurios e Especialistas de Domnio: so interessados na documentao de requisitos, uma vez que atuam na especificao, avaliao e alterao de requisitos. Gerentes de Cliente: utilizam o documento de requisitos para planejar um pedido de proposta para o desenvolvimento de um sistema, contratar um fornecedor e para acompanhar o desenvolvimento do sistema. Gerentes de Fornecedor: utilizam a documentao dos requisitos para planejar uma proposta para o sistema e para planejar e acompanhar o processo de desenvolvimento. Desenvolvedores (analistas, projetistas, programadores e mantenedores): utilizam a documentao dos requisitos para compreender o sistema e as relaes entre suas partes. Testadores: utilizam a documentao dos requisitos para projetar casos de teste, sobretudo testes de validao do sistema.
Diferentes interessados tm propsitos diferentes. Assim, pode ser til ter mais do que um documento para registrar os resultados da engenharia de requisitos. Conforme discutido anteriormente, Pfleeger (2004) sugere que dois tipos de documentos de requisitos sejam elaborados: um Documento de Definio de Requisitos e um Documento de Especificao de Requisitos. O Documento de Definio de Requisitos, ou simplesmente Documento de Requisitos, deve conter uma descrio do propsito do sistema, uma breve descrio do domnio do problema tratado pelo sistema e listas de requisitos funcionais, no funcionais e regras de negcio, descritos em linguagem natural (requisitos de usurio).
16
Para facilitar a identificao e rastreamento dos requisitos, devem-se utilizar identificadores nicos para cada um dos requisitos listados. O pblico-alvo deste documento so os clientes, usurios, gerentes (de cliente e de fornecedor) e desenvolvedores. O Documento de Especificao de Requisitos deve conter os requisitos escritos a partir da perspectiva do desenvolvedor, devendo haver uma correspondncia direta com os requisitos no Documento de Requisitos, de modo a se ter requisitos rastreveis. Os vrios modelos produzidos na fase de anlise devem ser apresentados no Documento de Especificao de Requisitos, bem como glossrios de termos usados e outras informaes julgadas relevantes. Deve-se observar que no h um padro definido quanto quantidade e ao nome dos documentos de requisitos. H organizaes que optam por ter apenas um documento de requisitos, contendo diversas sees, algumas tratando de requisitos do usurio, outras tratando de requisitos de sistema. Outras organizaes, por sua vez, fazem uso de vrios documentos distintos, capturando em documentos separados, por exemplo, requisitos funcionais, requisitos no funcionais, modelos de caso de uso e modelos estruturais e comportamentais. De fato, cabe a cada organizao definir a quantidade, o nome e o contedo de cada documento. Para estruturar o contedo, necessrio que a organizao defina seus modelos de documentos de requisitos. Vrias diretrizes tm sido propostas com objetivo de melhorar a estrutura e organizao da documentao de requisitos, dentre elas (SOMMERVILLE; SAWYER, 1997; KOTONYA; SOMMERVILLE, 1998; PRESSMAN, 2006; WIEGERS, 2003): (i) definir um modelo de documento para cada tipo de documento a ser considerado, definindo um padro de estrutura para o documento; (ii) explicar como cada classe de leitores deve usar os diferentes tipos de documentos; (iii) incluir uma seo explicando por que o software necessrio e como ir contribuir para os objetivos gerais de negcio da organizao; (iv) definir termos especializados em um glossrio; (v) organizar o layout do documento para facilitar a leitura; (vi) auxiliar os leitores a encontrar a informao, incluindo recursos tais como listas de contedo e ndices, e organizando os requisitos em captulos, sees e subsees identificadas; (vii) identificar as fontes dos requisitos de modo a manter dados da origem do requisito, de modo que, quando alguma mudana for solicitada, seja possvel saber com quem essa mudana deve ser discutida e avaliada; (viii) criar um identificador nico para cada requisito, de modo a facilitar a rastreabilidade e o controle de mudanas; (ix) documentar tambm as regras do negcio e definir ligaes entre os requisitos e as regras correspondentes e (x) tornar o documento fcil de alterar.
2.2.4 Verificao e Validao de Requisitos

As atividades de Verificao & Validao (V&V) devem ser iniciadas o quanto antes no processo de desenvolvimento de software, pois quanto mais tarde os defeitos so encontrados, maiores os custos associados sua correo (ROCHA; MALDONADO; WEBER, 2001). Uma vez que os requisitos so a base para o desenvolvimento, fundamental que eles sejam cuidadosamente avaliados. Assim, os documentos produzidos durante a atividade de documentao de requisitos devem ser submetidos verificao e validao.
17
importante realar a diferena entre verificao e validao. O objetivo da verificao assegurar que o software esteja sendo construdo de forma correta. Devese verificar se os artefatos produzidos atendem aos requisitos estabelecidos e se os padres organizacionais (de produto e processo) foram consistentemente aplicados. Por outro lado, o objetivo da validao assegurar que o software que est sendo desenvolvido o software correto, ou seja, assegurar que os requisitos, e o software deles derivado, atendem ao uso proposto (ROCHA; MALDONADO; WEBER, 2001). No caso de requisitos, a verificao feita, sobretudo, em relao consistncia entre requisitos e modelos e conformidade com padres organizacionais de documentao de requisitos. J a validao tem de envolver a participao de usurios e clientes, pois somente eles so capazes de dizer se os requisitos atendem aos propsitos do sistema. Nas atividades de V&V de requisitos, examinam-se os documentos de requisitos para assegurar que (PRESSMAN, 2006; KOTONYA; SOMMERVILLE, 1998; WIEGERS, 2003): (i) todos os requisitos do sistema tenham sido declarados de modo no-ambguo, (ii) as inconsistncias, conflitos, omisses e erros tenham sido detectados e corrigidos, (iii) os documentos esto em conformidade com os padres estabelecidos e (iv) os requisitos realmente satisfazem s necessidades dos clientes e usurios. Em outras palavras, idealmente, um requisito, seja ele uma regra de negcio, requisito funcional ou no funcional, deve ser (WIEGERS, 2003; PFLEEGER, 2004): Completo: o requisito deve descrever completamente a funcionalidade a ser entregue (no caso de requisito funcional), a regra de negcio a ser tratada (no caso de regras de negcio) ou a restrio a ser considerada (no caso de requisito no funcional). Ele deve conter as informaes necessrias para que o desenvolvedor possa projetar, implementar e testar essa funcionalidade, regra ou restrio. Correto: cada requisito deve descrever exatamente a funcionalidade, regra ou restrio a ser construda. Consistente: o requisito no deve ser ambguo ou conflitar com outro requisito. Realista: deve ser possvel implementar o requisito com a capacidade e com as limitaes do sistema e do ambiente de desenvolvimento. Necessrio: o requisito deve descrever algo que o cliente realmente precisa ou que requerido por algum fator externo ou padro da organizao. Passvel de ser priorizado: os requisitos devem ter ordem de prioridade para facilitar o gerenciamento durante o desenvolvimento do sistema. Verificvel e passvel de confirmao: deve ser possvel desenvolver testes para verificar se o requisito foi realmente implementado. Rastrevel: deve ser possvel identificar quais requisitos foram tratados em um determinado artefato, bem como identificar que produtos foram originados a partir de um requisito.
Neste contexto til (WIEGERS, 2003):
18
Realizar revises dos documentos de requisitos, procurando por problemas (conflitos, omisses, inconsistncias, desvios dos padres etc) e discutindo solues. Definir casos de teste para os requisitos especificados. Definir critrios de aceitao de requisitos, i.e., os usurios devem descrever como vo determinar se o produto atende s suas necessidades e se adequado para uso.
De maneira geral, i.e., sem estarem restritas a requisitos, as atividades de V&V envolvem anlises estticas e dinmicas. A anlise dinmica (ou testes) objetiva detectar defeitos ou erros no software por meio da execuo do produto. J a anlise esttica no envolve a execuo do produto, sendo feita por meio de revises dos artefatos a serem avaliados (ROCHA; MALDONADO; WEBER, 2001). No caso de requisitos, podem-se realizar revises dos documentos de requisitos para avaliar requisitos e modelos (anlise esttica), bem como possvel utilizar prototipagem para validar requisitos (anlise dinmica). A anlise dinmica, neste caso, se justifica, pois, muitas vezes, as pessoas encontram dificuldades em visualizar como os requisitos sero traduzidos em um sistema. Essa dificuldade pode ser amenizada por meio de prottipos, que auxiliam os usurios na identificao de problemas e na sugesto de melhorias dos requisitos. Dessa forma, a prototipagem pode ser utilizada no processo de validao de requisitos. Entretanto, sua utilizao nessa fase tem uma relao custo-benefcio mais efetiva quando ela tiver sido empregada tambm na fase de levantamento de requisitos (KOTONYA; SOMMERVILLE, 1998). Das atividades de verificao e validao, a atividade de teste considerada um elemento crtico para a garantia da qualidade dos artefatos produzidos ao longo do desenvolvimento e, por conseguinte, do produto de software final (ROCHA; MALDONADO; WEBER, 2001). Contudo, exceto por meio de prottipos ou especificaes de requisitos executveis (estas um recurso muito pouco utilizado na prtica), no possvel testar requisitos. Entretanto, uma das caractersticas de qualidade de um requisito bem elaborado ser testvel e, portanto, uma boa maneira de identificar problemas nos requisitos definir casos de teste para os mesmos. Se um requisito est incompleto, inconsistente ou ambguo, pode ser difcil definir casos de teste para ele (KOTONYA; SOMMERVILLE, 1998). Definir casos de teste para requisitos e avaliar prottipos so importantes meios de se verificar e validar requisitos. Contudo, imprescindvel, ainda, realizar revises dos documentos de requisitos. De maneira geral, em uma reviso, processos, documentos e outros artefatos so revisados por um grupo de pessoas, com o objetivo de avaliar se os mesmos esto em conformidade com os padres organizacionais estabelecidos e se o propsito de cada um deles est sendo atingido. Assim, o objetivo de uma reviso detectar erros e inconsistncias em artefatos e processos, sejam eles relacionados forma, sejam eles em relao ao contedo, e apont-los aos responsveis pela sua elaborao (ROCHA; MALDONADO; WEBER, 2001). Em um formato de reviso tcnica formal, o processo de reviso comea com o planejamento da reviso, quando uma equipe de reviso formada, tendo frente um lder. A equipe de reviso deve incluir membros da equipe que possam ser efetivamente
19
teis para atingir o objetivo da reviso. Muitas vezes, a pessoa responsvel pela elaborao do artefato a ser revisado integra a equipe de reviso (ROCHA; MALDONADO; WEBER, 2001). O propsito da reviso deve ser previamente informado e o material a ser revisado deve ser entregue com antecedncia para que cada membro da equipe de reviso possa avali-lo. Uma vez que todos estejam preparados, uma reunio convocada pelo lder. Dando incio reunio de reviso, normalmente, o autor do artefato apresenta o mesmo e descreve a perspectiva utilizada para a sua construo. O lder orientar o processo de reviso, passando por todos os aspectos relevantes a serem revistos. Todas as consideraes dos vrios membros da equipe de reviso devem ser discutidas e as decises registradas, dando origem a uma ata de reunio de reviso, contendo uma lista de defeitos encontrados. Essa reunio deve ser relativamente breve (duas horas, no mximo), uma vez que todos j devem estar preparados para a mesma (ROCHA; MALDONADO; WEBER, 2001). No que se refere reviso de requisitos, diversas tcnicas de leitura podem ser usadas. A mais simples a leitura ad-hoc, na qual os revisores aplicam seus prprios conhecimentos na reviso dos documentos de requisitos. Diferentemente de uma abordagem ad-hoc, outras tcnicas buscam aumentar a eficincia dos revisores, direcionando os esforos para as melhores prticas de deteco de defeitos. Tcnicas de leitura baseada em listas de verificao (checklists), leitura baseada em perspectivas e leitura de modelos orientados a objetos so bastante usadas na verificao e validao de documentos de requisitos. Checklists definem uma lista de aspectos que devem ser verificados pelos revisores, guiando-os no trabalho de reviso. Podem ser usados em conjunto com outras tcnicas, tais como as tcnicas de leitura baseada em perspectiva e leitura de modelos orientados a objetos. A tcnica de leitura baseada em perspectiva foi desenvolvida especificamente para a verificao e validao de requisitos. Ela explora a observao de quais informaes de requisitos so mais ou menos importantes para as diferentes formas de utilizao do documento de requisitos. Cada revisor realiza a reviso segundo uma perspectiva diferente. Algumas perspectivas tipicamente consideradas so as perspectivas de clientes, desenvolvedores e testadores. Checklists para cada uma dessas perspectivas podem ser providos (ROCHA; MALDONADO; WEBER, 2001). A leitura de modelos orientados a objetos prope um conjunto de tcnicas de leitura para reviso dos diferentes diagramas utilizados durante um projeto orientado a objetos. Cada uma das tcnicas definida para um conjunto de diagramas a serem analisados em conjunto. O processo de leitura realizado de duas maneiras: a leitura horizontal diz respeito consistncia entre artefatos elaborados em uma mesma fase, procurando verificar se esses artefatos esto descrevendo consistentemente diferentes aspectos de um mesmo sistema, no nvel de abstrao relacionado fase em questo; a leitura vertical refere-se consistncia entre artefatos elaborados em diferentes fases (anlise e projeto) (ROCHA; MALDONADO; WEBER, 2001).
20
2.2.5 Gerncia de Requisitos

Mudanas nos requisitos ocorrem ao longo de todo o processo de software, desde o levantamento e anlise de requisitos at durante a operao do sistema. Elas so decorrentes de diversos fatores, tais como descoberta de erros, omisses, conflitos e inconsistncias nos requisitos, melhor entendimento por parte dos usurios de suas necessidades, problemas tcnicos, de cronograma ou de custo, mudana nas prioridades do cliente, mudanas no negcio, aparecimento de novos competidores, mudanas econmicas, mudanas na equipe, mudanas no ambiente onde o software ser instalado e mudanas organizacionais ou legais. Para minimizar as dificuldades impostas por essas mudanas, necessrio gerenciar requisitos (TOGNERI, 2002). O processo de gerncia de requisitos envolve as atividades que ajudam a equipe de desenvolvimento a identificar, controlar e rastrear requisitos e gerenciar mudanas de requisitos em qualquer momento ao longo do ciclo de vida do software (KOTONYA; SOMMERVILLE, 1998; PRESSMAN, 2006). Os principais objetivos desse processo so (KOTONYA; SOMMERVILLE, 1998): Gerenciar alteraes nos requisitos acordados. Gerenciar relacionamentos entre requisitos. Gerenciar dependncias entre requisitos e outros documentos produzidos durante o processo de software.
Para tal, o processo de gerncia de requisitos deve incluir as seguintes atividades, ilustradas na Figura 2.3 (WIEGERS, 2003): controle de mudanas, controle de verso, acompanhamento do estado dos requisitos e rastreamento de requisitos.
Figura 2.3 - Atividades da Gerncia de Requisitos (WIEGERS, 2003) O controle de mudana define os procedimentos, processos e padres que devem ser utilizados para gerenciar as alteraes de requisitos, assegurando que qualquer proposta de mudana seja analisada conforme os critrios estabelecidos pela organizao (KOTONYA; SOMMERVILLE, 1998). Mudanas podem ser necessrias em diferentes momentos e por diferentes razes. De maneira geral, o controle de mudanas envolve atividades como (KOTONYA; SOMMERVILLE, 1998; WIEGERS, 2003):
21
Verificar se uma mudana vlida. Descobrir quais os requisitos e artefatos afetados pela mudana, o que envolve rastrear informaes. Estimar o impacto e o custo das mudanas. Negociar as mudanas com os clientes. Alterar requisitos e documentos associados.
Para garantir uma abordagem consistente, recomenda-se que as organizaes definam um conjunto de polticas de gerncia de mudana, contemplando (KOTONYA; SOMMERVILLE, 1998): o processo de solicitao de mudana e as informaes necessrias para processar cada solicitao; o processo de anlise de impacto e de custos da mudana, alm das informaes de rastreabilidade associadas; os membros que formalmente avaliaro as mudanas; as ferramentas que auxiliaro o processo.
Se as mudanas no forem controladas, alteraes com baixa prioridade podem ser implementadas antes de outras mais importantes e modificaes com custo alto, que no so realmente necessrias, podem ser aprovadas (TOGNERI, 2002). Ao se detectar a necessidade de alterao em um ou mais requisitos, deve-se registrar uma solicitao de mudana, a qual deve ser avaliada por algum membro da equipe do projeto de software. Nessa avaliao, o impacto da alterao deve ser determinado e valores de custo, esforo, tempo e viabilidade devem ser repassados ao solicitante da mudana. Assim, uma parte crtica do controle de mudanas a avaliao do impacto de uma mudana no restante do software. Para que seja possvel efetuar essa avaliao, cada requisito deve estar identificado unicamente e deve ser possvel, por exemplo, saber quais so os requisitos dependentes desse requisito e em quais artefatos do processo de software esse requisito tratado. Portanto, necessrio estabelecer uma rede de ligaes de modo que um requisito e os elementos ligados a ele possam ser rastreados. Surge, ento, o conceito de rastreabilidade. A rastreabilidade pode ser definida como a habilidade de se acompanhar a vida de um requisito em ambas as direes do processo de software e durante todo o ciclo de vida. Ela fornece uma base para o desenvolvimento de uma trilha de auditoria para todo o projeto, possibilitando encontrar outros requisitos e artefatos que podem ser afetados pelas mudanas solicitadas (PALMER, 1997). Para tal, necessrio haver ligaes entre requisitos e entre requisitos e outros elementos do processo de software. Assim, a identificao da composio de requisitos, das dependncias entre requisitos, de requisitos conflitantes, da origem dos requisitos e de seus interessados, alm da identificao de em quais artefatos produzidos durante o desenvolvimento de software um requisito tratado, de fundamental importncia para que a rastreabilidade possa ser implementada (WIEGERS, 2003; ROBERTSON; ROBERTSON, 2006; KOTONYA; SOMMERVILLE, 1998).
22
Matrizes de rastreabilidade so os principais artefatos produzidos na fase de gerncia de requisitos. Elas relacionam os requisitos identificados a um ou mais aspectos do sistema ou do seu ambiente, de modo que elas possam ser procuradas rapidamente para entender como uma modificao em um requisito vai afetar diferentes aspectos do sistema. Dentre as muitas possveis matrizes de rastreabilidade, h as seguintes: Matriz de rastreabilidade de dependncia: indica como os requisitos esto relacionados uns com os outros. Matriz de rastreabilidade requisitos requisito. Matriz de rastreabilidade requisitos que tratam os requisitos. fontes: indica a fonte de cada subsistemas: indica os subsistemas
Matriz de rastreabilidade requisitos de usurio casos de uso: indica os casos de uso que detalham um requisito funcional ou tratam um requisito no funcional ou regra de negcio.
Alm das matrizes de rastreabilidade de requisitos, outras matrizes de rastreabilidade entre outros artefatos do processo podem ser construdas, de modo a apoiar a gerncia de requisitos. Por exemplo, ao se estabelecer uma matriz de rastreabilidade casos de uso classes, indicando que classes de um modelo de anlise so necessrias para se tratar um caso de uso, possvel, em conjunto com uma matriz de rastreabilidade requisitos de usurio casos de uso, saber que classes so importantes no tratamento de um requisito de usurio. Davis (apud KOTONYA; SOMMERVILLE, 1998) aponta quatro tipos de rastreabilidade interessantes para que uma anlise de impacto de mudanas possa ser feita mais facilmente, como ilustra a Figura 2.4:
Rastreabilidade regressiva a partir dos requisitos
Rastreabilidade progressiva a partir dos requisitos
Fonte do Requisito
Requisitos
Outros Artefatos: -Projeto (Design) - Cdigo - Testes etc.
Rastreabilidade progressiva em direo aos requisitos
Rastreabilidade regressiva em direo aos requisitos
Figura 2.4 Tipos de Rastreabilidade
23
Regressiva a partir dos requisitos (backward-from traceability): relaciona requisitos com suas origens (outros documentos ou pessoas); Progressiva a partir dos requisitos (forward-from traceability): relaciona requisitos aos artefatos do projeto (planos, modelos de anlise e projeto, cdigo etc.); Regressiva em direo aos requisitos (backward-to traceability): relaciona artefatos do projeto aos requisitos; Progressiva em direo aos requisitos (forward-to traceability): relaciona as fontes (p.ex., documentos que precederam o documento de requisitos) aos requisitos relevantes.
Embora a rastreabilidade de requisitos no possa ser completamente automatizada, porque o conhecimento das ligaes se origina na mente dos membros da equipe de desenvolvimento, uma vez identificadas essas ligaes, ferramentas de apoio so importantssimas para ajudar a gerenciar a grande quantidade de informaes de rastreabilidade (WIEGERS, 2003). Requisitos guiam vrias atividades do processo de software, dentre elas planejamento, projeto (design), codificao e testes, e, portanto, esses artefatos devem ser rastreveis para e a partir dos requisitos. A seguir so citadas algumas situaes, em diversas etapas, nas quais os requisitos so importantes (WIEGERS, 2003): Planejamento de Projeto: requisitos so teis para dimensionar o projeto, sendo utilizados para estimar o tamanho do produto. Planos devem ser atualizados caso haja mudanas em requisitos e requisitos prioritrios so usados para direcionar iteraes, quando modelos de ciclo de vida iterativos so adotados. Projeto e Codificao: requisitos, com destaque para os no funcionais, so usados para direcionar o projeto da arquitetura do sistema e so alocados a componentes. Mudanas em requisitos devem ser rastreadas para o projeto e o cdigo gerado, de modo a guiar as alteraes. Testes: requisitos so a base para diversos tipos de testes, dentre eles testes de sistema e de aceitao.
2.3 Engenharia de Requisitos e Normas e Modelos de Qualidade

Visando qualidade no processo de software, modelos e normas de qualidade de processo de software tm sido propostos, dentre eles o CMMI (Capability Maturity Model Integration) (SEI, 2006) e o MPS.BR (SOFTEX, 2009). O CMMI um modelo de qualidade de processo desenvolvido pelo Instituto de Engenharia de Software (Software Engineering Institute SEI) da Universidade de Carnegie Mellon. O CMMI para Desenvolvimento (CMMI-Dev) (SEI, 2006) enfoca o processo de software e tem como objetivo fornecer diretrizes para a definio e melhoria de processos de software de uma organizao. O CMMI, em sua representao em estgio, possui cinco nveis de maturidade: 1- Inicial, 2- Gerenciado, 3- Definido, 4Gerenciado Quantitativamente e 5- Em Otimizao.
24
O CMMI-Dev trata de requisitos tanto no nvel 2, atravs da rea de processo Gesto de Requisitos, quanto no nvel 3, por meio da rea de processo Desenvolvimento de Requisitos. Na Gesto de Requisitos o objetivo gerenciar os requisitos dos produtos e componentes de produto do projeto e identificar inconsistncias entre esses requisitos e os planos e produtos de trabalho do projeto (SEI, 2006). Para isso, o CMMI sugere as seguintes prticas: SG 1 Gerenciar Requisitos SP 1.1 Obter um entendimento dos requisitos. SP 1.2 Obter comprometimento com os requisitos. SP 1.3 Gerenciar mudanas de requisitos. SP 1.4 Manter rastreabilidade bidirecional dos requisitos. SP 1.5 Identificar inconsistncias entre o trabalho de projeto (planos de projeto, produtos de trabalho) e requisitos. O Desenvolvimento de Requisitos, por sua vez, visa produzir e analisar os requisitos de cliente, de produto e de componente de produto (SEI, 2006). Neste caso, o CMMI sugere as seguintes prticas: SG 1 Desenvolver os Requisitos de Cliente SP 1.1 Levantar os requisitos. SP 1.2 Desenvolver os requisitos de cliente. SG 2 Desenvolver Requisitos de Produto SP 2.1 Estabelecer os requisitos de produto e de componentes de produto. SP 2.2 Alocar os requisitos de componentes de produto. SP 2.3 Identificar os requisitos de interface. SG 3 Analisar e Validar Requisitos SP 3.1 Estabelecer conceitos e cenrios operacionais. SP 3.2 Estabelecer uma definio da funcionalidade requerida. SP 3.3 Analisar os requisitos. SP 3.4 Analisar os requisitos visando ao equilbrio. SP 3.5 Validar os requisitos com mtodos detalhados. O MPS.BR (Melhoria de Processo do Software Brasileiro) (SOFTEX, 2009) tem como objetivo auxiliar micro, pequenas e mdias empresas a definirem e a melhorarem seus processos de software, sendo um modelo direcionado para a realidade brasileira. Na concepo do MPS.BR foram consideradas as normas ISO/IEC 12207 e ISO/IEC 15504, alm do CMMI. Essa abordagem visa garantir que o MPS.BR est em conformidade com padres internacionais. Assim como o CMMI, o MPS.BR organizado em nveis de maturidade. No caso do MPS.BR, contudo, so sete nveis, a saber: G- Parcialmente Gerenciado, F- Gerenciado, E- Parcialmente Definido, DLargamente Definido, C- Definido, B- Gerenciado Quantitativamente, A- Em Otimizao. O MPS.BR procura manter uma correspondncia entre seus nveis de maturidade e os nveis de maturidade do CMMI. Assim, o nvel 2 do CMMI corresponde ao nvel F do MPS.BR, o nvel 3 do CMMI ao nvel C do MPS.BR, o nvel 4 do CMMI ao nvel B do MPS.BR e finalmente o nvel 5 do CMMI corresponde ao nvel A do MPS.BR.
25
O MPS.BR define, em seu nvel G, o processo de Gerncia de Requisitos e no nvel D o processo de Desenvolvimento de Requisitos. O propsito do processo de Gerncia de Requisitos gerenciar os requisitos do produto e dos componentes do produto do projeto e identificar inconsistncias entre os requisitos, os planos do projeto e os produtos de trabalho do projeto (SOFTEX, 2009). Esse processo tem como resultados esperados: GRE 1. Os requisitos so entendidos, avaliados e aceitos junto aos fornecedores de requisitos, utilizando critrios objetivos; GRE 2. O comprometimento da equipe tcnica com os requisitos aprovados obtido; GRE 3. A rastreabilidade bidirecional entre os requisitos e os produtos de trabalho estabelecida e mantida; GRE 4. Revises em planos e produtos de trabalho do projeto so realizadas visando identificar e corrigir inconsistncias em relao aos requisitos; GRE 5. Mudanas nos requisitos so gerenciadas ao longo do projeto. O Desenvolvimento de Requisitos, por sua vez, tem por objetivo definir os requisitos do cliente, do produto e dos componentes do produto (SOFTEX, 2009). Esse processo tem como resultados esperados: DRE 1. As necessidades, expectativas e restries do cliente, tanto do produto quanto de suas interfaces, so identificadas; DRE 2. Um conjunto definido de requisitos do cliente especificado a partir das necessidades, expectativas e restries identificadas; DRE 3. Um conjunto de requisitos funcionais e no-funcionais, do produto e dos componentes do produto que descrevem a soluo do problema a ser resolvido, definido e mantido a partir dos requisitos do cliente; DRE 4. Os requisitos funcionais e no-funcionais de cada componente do produto so refinados, elaborados e alocados; DRE 5. Interfaces internas e externas do produto e de cada componente do produto so definidas; DRE 6. Conceitos operacionais e cenrios so desenvolvidos; DRE 7. Os requisitos so analisados, usando critrios definidos, para balancear as necessidades dos interessados com as restries existentes; DRE 8. Os requisitos so validados. De uma maneira geral, pode-se constatar que a Engenharia de Requisitos, pela sua importncia no contexto do desenvolvimento de software, cuidadosamente tratada pelos principais modelos de qualidade de processo de software.
26
Leitura Complementar Os livros de Kotonya e Sommerville (1998), Wiegers (2003) e Robertson e Robertson (2006) so dedicados integralmente Engenharia de Requisitos e, portanto, contemplam vrios dos aspectos tratados neste captulo e muito mais. Em (KOTONYA; SOMMERVILLE, 1998) h uma excelente discusso sobre Engenharia de Requisitos. O processo apresentado neste texto fortemente baseado no processo proposto nesse livro. Em especial, os seguintes captulos tm informaes muito relevantes para complementar os estudos baseados nestas notas de aula: Captulo 1 Introduction na forma de um FAQ (Frequently Asked Questions), aborda as noes de requisitos e engenharia de requisitos; o Captulo 2 Requirements Engineering Process d uma viso geral do processo de engenharia de requisitos, o qual detalhado posteriormente nos captulos 3 Requirements Elicitation and Analysis, 4 Requirements Validation e 5 Requirements Management. Ainda neste livro, o Captulo 8 Non-functional Requirements discute requisitos no funcionais. Em (WIEGERS, 2003) h tambm vrios captulos que abordam temas discutidos nestas notas de aula. Sugere-se, em especial, a leitura dos captulos 1, 3 e 17. O Captulo 1 The Essential Software Requirements aborda o que so requisitos, nveis e tipos de requisitos, os processos de desenvolvimento e gerncia de requisitos e caractersticas de qualidade de requisitos. O Captulo 3 Good Practices for Requirements Engineering d uma viso geral do processo de engenharia de requisitos, apontando boas prticas. Indica, ainda, outros captulos do livro que discutem em detalhes as atividades do processo de engenharia de requisitos. O Captulo 17 Beyond Requirements Development discute as relaes entre requisitos e outros artefatos do processo de software, dentre eles planos de projeto, projeto (design), cdigo e testes. Em (ROBERTSON; ROBERTSON, 2006) o foco tambm a Engenharia de Requisitos e, portanto, h vrios captulos que abordam temas discutidos nestas notas de aula. Sugere-se, em especial, a leitura dos captulos 1 e 2. O Captulo 1 What are Requirements? aborda o que so requisitos e tipos de requisitos. Apresenta, ainda, brevemente o processo de requisitos proposto no livro, denominado Volere, e o modelo de documento de requisitos proposto. O Captulo 2 The Requirements Process d uma viso geral do processo de requisitos, indicando os demais captulos do livro que discutem em detalhes as suas atividades. Livros de Engenharia de Software tambm abordam a Engenharia de Requisitos, tendo em vista que requisitos so parte fundamental do processo de software. Dentre os diversos livros de Engenharia de Software, sugerem-se trs: (SOMMERVILLE, 2007), (PFLEEGER, 2004) e (PRESSMAN, 2006). Em (SOMMERVILLE, 2007), a parte 2 Requisitos como o prprio nome indica, dedicada ao tema. Merecem ateno especial os captulos 6 e 7. O Captulo 6 Requisitos de Software trata de tipos e nveis de requisitos, bem como da documentao de requisitos. O Captulo 7 Processos de Engenharia de Requisitos apresenta e discute um processo de engenharia de requisitos (tambm muito similar ao apresentado neste texto) e suas atividades. Em (PFLEEGER, 2004), o Captulo 4 Identificando Requisitos tem uma boa discusso sobre requisitos. Em relao aos temas abordados nestas notas de aula,
27
merecem destaque as sees 4.1, 4.2, 4.3, 4.6, 4.7, 4.8 e 4.9, as quais tratam dos seguintes assuntos: requisitos, processo de requisitos, tipos de documentos de requisitos, tipos de requisitos, caractersticas de requisitos (sees 4.1, 4.2 e 4.3), prototipagem de requisitos (seo 4.6), documentao de requisitos (seo 4.7), participantes no processo de requisitos (seo 4.8) e validao de requisitos (seo 4.9). Em (PRESSMAN, 2006), o Captulo 7 Engenharia de Requisitos aborda vrios dos temas discutidos neste captulo, com destaque para as sees 7.2 (Tarefas da Engenharia de Requisitos), 7.3 (Incio do Processo de Engenharia de Requisitos), 7.4 (Levantamento de Requisitos), 7.7 (Negociao de Requisitos) e 7.8 (Validao de Requisitos). Por fim, as sees 3.4 e 3.6 de (ROCHA; MALDONADO; WEBER, 2001) discutem, respectivamente, a Verificao e Validao (V&V) de Software e Revises de Software. Trata-se de discusses gerais para quaisquer artefatos e no discusses focadas em requisitos, mas mesmo assim muito teis. Em especial a subseo 3.6.2 importante, pois discute as tcnicas de leitura de requisitos baseada em perspectivas e as tcnicas de leitura de projetos orientados a objetos. Referncias do Captulo AURUM, A., WOHLIN, C., Engineering and Managing Software Requirements, Springer-Verlag, 2005. BLAHA, M., RUMBAUGH, J., Modelagem e Projetos Baseados em Objetos com UML 2, Elsevier, 2006. IEEE, IEEE Recommended Practice for Software Requirements Specifications: IEEE Std 830-1998. New York: IEEE, 1998. KENDALL, K.E., KENDALL, J.E.; Systems Analysis and Design, Prentice Hall, 8th Edition, 2010. KOTONYA, G., SOMMERVILLE, I., Requirements engineering: processes and techniques. Chichester, England: John Wiley, 1998. NUSEIBEH, B., EASTERBROOK, S., Requirements engineering: a roadmap. In: Proceedings of the Conference on the Future of Software Engineering, Limerick, Ireland, 2000. PALMER, J.D., Traceability. In: THAYER, H. R.; DORFMAN, M. (Org.) Software requeriments engineering. 2nd edition, Los Alamitos, California: IEEE Computer Society, p.364-374, 1997. PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo: Prentice Hall, 2 edio, 2004. PRESSMAN, R.S., Engenharia de Software, McGraw-Hill, 6 edio, 2006. ROBERTSON, S., ROBERTSON, J. Mastering the Requirements Process. 2nd Edition. Addison Wesley, 2006. ROCHA, A.R.C., MALDONADO, J.C., WEBER, K.C., Qualidade de Software: Teoria e Prtica. So Paulo: Prentice Hall, 2001.
28
SEI, CMMI for Development, Version, 1.2, CMMI-Dev V1.2, CMU/SEI-2006-TR-008, 2006. SOFTEX, MPS.BR Melhoria de Processo do Software Brasileiro Guia Geral: 2009, Junho 2009. SOMMERVILLE, I., Engenharia de Software, 8 Edio. So Paulo: Pearson Addison Wesley, 2007. SOMMERVILLE, I., SAWYER, P., Requirements engineering: a good practice guide. Chichester, England: John Wiley, 1997. TOGNERI, D.F., Apoio Automatizado Engenharia de Requisitos Cooperativa. Dissertao (Mestrado em Informtica), Universidade Federal do Esprito Santo (UFES), Vitria, 2002. WIEGERS, K.E., Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle. 2nd Edition, Microsoft Press, Redmond, Washington, 2003.
Captulo 3 Levantamento de Requisitos
29

Analistas e desenvolvedores trabalham com clientes e usurios para saber mais sobre o problema a ser resolvido, os servios a serem providos pelo sistema, restries etc. Isso no significa apenas perguntar o que eles desejam do sistema. Ao contrrio, requer uma anlise criteriosa da organizao, do domnio do problema e dos processos de negcio que sero apoiados pelo sistema. O quadro fica ainda mais complicado, por causa de diversos fatores, dentre eles: raramente os clientes tm uma viso clara de seus requisitos; diferentes pessoas em uma organizao tm diferentes requisitos, s vezes conflitantes; e h limitaes financeiras, tecnolgicas e de prazos. Assim, levantar requisitos no uma tarefa simples (KOTONYA; SOMMERVILLE, 1998). Este captulo enfoca o levantamento de requisitos. A seo 3.1 procura dar uma viso geral dessa atividade, discutindo problemas tpicos e tarefas a serem realizadas no levantamento de requisitos. A seo 3.2 apresenta algumas tcnicas para apoiar o levantamento de requisitos. A seo 3.3 discute como a modelagem de processos de negcio pode ajudar na captura de requisitos de software. Finalmente, a seo 3.4 discute formas de se escrever e documentar requisitos.
3.1 Viso Geral do Levantamento de Requisitos

O levantamento de requisitos preocupa-se com o aprendizado e entendimento das necessidades dos usurios e patrocinadores do projeto, com o objetivo final de comunicar essas necessidades para os desenvolvedores do sistema. Uma parte substancial do levantamento de requisitos dedicada a descobrir, extrair e aparar arestas dos desejos de potenciais interessados (AURUM; WOHLIN, 2005). A fase de levantamento de requisitos envolve buscar junto aos usurios, clientes e outros interessados, seus sistemas e documentos todas as informaes possveis sobre as funes que o sistema deve executar (requisitos funcionais) e as restries sob as quais ele deve operar (requisitos no funcionais). O produto principal dessa fase so os documentos de requisitos (WAZLAWICK, 2004). Entretanto, conforme citado anteriormente, levantar requisitos no uma tarefa fcil. Esta uma tarefa de natureza multidimensional e os analistas (ou engenheiros de requisitos) se veem diante de vrios desafios, dentre eles (KOTONYA; SOMMERVILLE, 1998): O conhecimento acerca do domnio de aplicao encontra-se disperso em uma variedade de fontes, tais como livros, manuais e, sobretudo, nas cabeas das pessoas que trabalham na rea. Alm disso, muitas vezes, envolve uma terminologia especializada que no imediatamente compreensvel pelo analista. As pessoas que entendem o problema a ser resolvido frequentemente esto muito ocupadas para despender tempo ajudando os analistas a entender os requisitos para um novo sistema. Elas podem, inclusive, no estar convencidas da necessidade do
30
novo sistema e, por conseguinte, no quererem se envolver no processo de engenharia de requisitos. Fatores polticos e questes organizacionais podem influenciar os requisitos para o sistema, bem como o estabelecimento de suas prioridades. Clientes e usurios frequentemente no sabem o que realmente querem do sistema, exceto em termos muito gerais. Mesmo quando eles sabem o que querem, eles tm dificuldade para articular os requisitos. Alm disso, podem ter demandas no realistas por no estarem cientes dos custos de suas solicitaes. O ambiente de negcio no qual ocorre o levantamento de requisitos est em constante mudana. Os requisitos podem mudar, a sua importncia pode mudar e novos requisitos podem surgir de novos interessados.
Dadas todas essas dificuldades, o levantamento de requisitos deve ser conduzido de forma bastante cuidadosa, fazendo uso de tcnicas para capturar e especificar os requisitos levantados. Uma boa prtica consiste em fazer o levantamento de requisitos de forma incremental. Inicialmente, em um levantamento preliminar de requisitos, apenas requisitos de usurio so capturados. Depois, em vrias iteraes, outros requisitos de usurio so capturados e requisitos de sistema vo sendo detalhados e especificados. Neste contexto, importante realar que o levantamento e a anlise de requisitos so atividades estreitamente relacionadas e, portanto, devem ocorrer em paralelo. Assim, medida que os requisitos vo sendo detalhados, eles devem ser modelados e especificados. O levantamento preliminar de requisitos tem por objetivo prover uma viso do todo para se poder definir o que mais importante e depois dividir o todo em partes para especificar os detalhes. Nessa fase, o levantamento rpido e genrico, sendo feito em extenso e no em profundidade, i.e., o analista deve entender a extenso do que o sistema deve fazer, mas sem entrar em detalhes. Somente nos ciclos iterativos os requisitos sero detalhados, especificados e modelados (WAZLAWICK, 2004). O levantamento preliminar de requisitos inicia-se com uma declarao de alto nvel, informal e incompleta, da misso do projeto. Essa declarao pode ser apresentada na forma de um conjunto de metas, funes e restries fundamentais para o sistema ou como uma explicao sobre os problemas a serem resolvidos. Esses resultados preliminares formam a base para investigao adicional e para o refinamento dos requisitos, de maneira tipicamente iterativa e incremental. Assim, o levantamento de requisitos pode ser visto como um processo realizado de forma incremental, ao longo de mltiplas sesses, iterativamente em direo a nveis de detalhe cada vez maiores e pelo menos parcialmente em paralelo com outras atividades do processo de software (AURUM; WOHLIN, 2005). O levantamento de requisitos envolve um conjunto de atividades que deve permitir a comunicao, priorizao, negociao e colaborao com todos os interessados relevantes. Deve prover, ainda, uma base para o aparecimento, descoberta e inveno de requisitos, como parte de um processo altamente interativo (AURUM; WOHLIN, 2005). Zowghi e Coulin, em (AURUM; WOHLIN, 2005), indicam que as atividades do processo de levantamento de requisitos podem ser agrupadas em cinco tipos fundamentais de atividades, a saber:
31
Entendimento do Domnio de Aplicao: importante investigar e examinar em detalhes a poro do mundo real onde o sistema vai residir, dita o domnio de aplicao. Aspectos sociais, polticos e organizacionais, bem como processos de trabalho existentes e problemas a serem resolvidos pelo sistema, precisam ser descritos em relao a metas e questes do negcio. Identificao de Fontes de Requisitos: requisitos podem estar espalhados em vrias fontes e podem existir em vrios formatos. Assim, podem existir muitas fontes de requisitos para um sistema e elas devem ser identificadas. Interessados representam a fonte de requisitos mais bvia. Em especial, clientes, usurios e especialistas de domnio so os mais indicados para fornecerem informao detalhada sobre os problemas e as necessidades. Sistemas e processos existentes so tambm fontes de requisitos, especialmente quando o projeto envolve a substituio de um sistema existente. A documentao acerca desses sistemas e processos de negcio, incluindo manuais, formulrios e relatrios, bem como de padres da indstria, leis e regulamentaes, prov informao til sobre a organizao e seu ambiente. Outras fontes incluem especificaes de requisitos de sistemas (quando o sistema envolve hardware e software e existe uma especificao de mais alto nvel), problemas reportados e solicitaes de melhoria para sistemas correntes, e observao do dia a dia dos usurios. A necessidade de se obter requisitos a partir de mltiplas perspectivas e fontes ilustra bem a natureza de comunicao intensiva da engenharia de requisitos Anlise de Interessados: conforme citado anteriormente, interessados (stakeholders) so pessoas que tm interesse no sistema ou so afetadas de alguma maneira por ele e, portanto, precisam ser consultadas durante o levantamento de requisitos. Interessados incluem tanto pessoal interno quanto externo organizao. O cliente ou patrocinador do projeto tipicamente o interessado mais aparente de um projeto. Contudo, os usurios so, na maioria das vezes, os interessados mais importantes. Outras partes cuja esfera de interesse pode ser afetada pela operao do sistema, tais como parceiros e clientes da organizao, devem ser consideradas interessadas. Assim, um dos primeiros passos no processo de levantamento de requisitos consiste em analisar e envolver todos os interessados relevantes. Seleo de Tcnicas de Levantamento de Requisitos: Nenhuma tcnica individualmente suficiente para levantar requisitos. Alm disso, a escolha das tcnicas a serem adotadas fortemente dependente de caractersticas do projeto e de seus envolvidos. Diferentes tcnicas devem ser empregadas, visando capturar diferentes tipos de informao e em diferentes estgios do processo de levantamento de requisitos. Assim, importante selecionar adequadamente as tcnicas a serem aplicadas. Levantamento de Requisitos de Interessados e Outras Fontes: Uma vez identificados as fontes de requisitos e os interessados relevantes, o levantamento de requisitos propriamente dito pode ser iniciado, aplicando-se as tcnicas selecionadas.
Assim, antes de iniciar a descoberta de requisitos propriamente dita, ou mesmo durante o levantamento de requisitos, til realizar algumas tarefas, a saber (KOTONYA; SOMMERVILLE, 1998):
32
Compreender os objetivos gerais do negcio a ser apoiado, esboar uma descrio do problema a ser resolvido e identificar por que o sistema necessrio e quais so restries sobre o mesmo, tais como restries oramentrias, de cronograma e de interoperabilidade. Levantar informaes do contexto do desenvolvimento, dentre eles conhecimento acerca da organizao onde o sistema ser implantado, informaes sobre o domnio da aplicao e informaes sobre sistemas que esto em uso e sero substitudos pelo sistema em desenvolvimento. Organizar as informaes levantadas, descartando conhecimento irrelevante e priorizando as metas da organizao. Alm disso, importante identificar interessados (stakeholders) e seus papis na organizao.
O envolvimento de clientes e usurios um fator crtico para o sucesso do projeto. Assim, importante engajar representantes deles desde o incio do projeto. Para definir esses representantes, deve-se (WIEGERS, 2003): Identificar diferentes classes de usurios. Usurios podem ser agrupados por diferentes aspectos, tais como: (i) a frequncia com que usam o sistema, (ii) experincia no domnio de aplicao e percia com sistemas computadorizados, (iii) caractersticas do sistema que eles usam, (iv) tarefas que eles realizam no apoio a seus processos de negcio e (v) nveis de privilgio de acesso e segurana. Selecionar e trabalhar com indivduos que representem cada grupo de usurios; Estabelecer um acordo sobre quem sero as pessoas responsveis por tomar decises relativas a requisitos, sobretudo no que concerne a estabelecer prioridades e resolver conflitos.
Cada classe de usurios tem seu prprio conjunto de requisitos, tanto funcionais quanto no funcionais. Alm disso, h classes de usurios que so mais importantes que outras. Essas classes devem ter tratamento preferencial na definio de prioridades e resoluo de conflitos (WIEGERS, 2003). Ainda em relao seleo de usurios, deve-se evitar obter requisitos de intermedirios entre a fonte de requisitos efetivamente e os analistas. Essa prtica abre espao para problemas de comunicao e, portanto, sempre que possvel, deve-se ir diretamente fonte. Contudo, alguns desses intermedirios podem adicionar informao importante. Neste caso, oua-os tambm. Entretanto, tome cuidado com gerentes de usurio (e tambm com desenvolvedores) que pensam que sabem as necessidades dos usurios sem sequer consultlos (WIEGERS, 2003). No que se refere aos responsveis por tomar decises relativas a requisitos, no incio do projeto deve-se definir quem vai resolver requisitos conflitantes advindos de diferentes classes de usurio, reconciliar inconsistncias, definir prioridades e arbitrar questes de escopo que venham a surgir. Uma boa estratgia a tomada de deciso consultiva e participativa, na qual se obtm ideias e opinies de diversos interessados antes de se tomar uma deciso (WIEGERS, 2003). interessante notar que, ao longo do processo de levantamento de requisitos, o engenheiro de requisitos (ou analista de sistema, como mais conhecido popularmente) desempenha diversos papis e assume diferentes responsabilidades. Por exemplo, um analista frequentemente desempenha o papel de um facilitador em sesses de levantamento de
33
requisitos em grupo, guiando e apoiando os participantes no endereamento de questes relevantes, bem como garantindo que os participantes se sentem confortveis e seguros com o processo, tendo oportunidade suficiente para contribuir. Outro papel importante o de mediador. Em muitos casos, a priorizao de requisitos ou negociao de requisitos conflitantes por diferentes classes de interessados fonte de debate e disputa. Neste contexto, o analista deve negociar uma soluo adequada e obter o compromisso dos envolvidos (AURUM; WOHLIN, 2005).
3.2 Tcnicas de Levantamento de Requisitos

Uma vez que levantar requisitos no tarefa fcil, imprescindvel que essa atividade seja cuidadosamente conduzida, fazendo uso de diversas tcnicas. Dentre as diversas tcnicas que podem ser aplicadas para o levantamento de requisitos, destacam-se: entrevistas, questionrios, workshops de requisitos, observao, investigao de documentos, prototipagem, cenrios, abordagens baseadas em objetivos e reutilizao de requisitos. Kendall e Kendall (2010) classificam os mtodos de levantamento de requisitos em dois grandes grupos: mtodos interativos e mtodos no obstrutivos. Os mtodos interativos envolvem a interao com membros da organizao, como o caso de entrevistas, questionrios e workshops de requisitos. Os mtodos no obstrutivos procuram no interferir no trabalho dos membros da organizao. Este o caso de mtodos como observao e investigao de documentos. Alexander e Beus-Dukic (2009), por sua vez, organizam as tcnicas de levantamento de requisitos pelo contexto no qual pode se dar a descoberta de requisitos. Esses contextos podem ser a descoberta de requisitos a partir de indivduos (entrevistas, por exemplo), a partir de grupos (p.ex., workshops de requisitos) ou a partir de coisas (p.ex., investigao de documentos). Os principais mtodos de levantamento de requisitos envolvem um processo geral que contm as seguintes atividades: Planejamento: visa definir o objetivo da atividade de levantamento de requisitos a ser conduzida, as pessoas (no caso de mtodos interativos) ou as coisas (no caso de mtodos no obstrutivos) envolvidas, quando a atividade vai ser realizada e sua durao, e como ela vai ser realizada, incluindo material de apoio. Assim, o planejamento envolve quatro perguntas bsicas: Por que?, Quem? (ou O qu?), Quando? e Como? Conduo: a realizao da atividade de levantamento de requisitos propriamente dita. Registro: consiste no registro das informaes obtidas na atividade realizada. Validao dos achados: envolve submeter o registro das informaes obtidas para avaliao pelas pessoas que participaram da atividade de levantamento de requisitos.
A seguir algumas das tcnicas citadas anteriormente so apresentadas.
34
3.2.1 Entrevistas
Entrevistas so, provavelmente, a tcnica mais comumente utilizada no levantamento de requisitos (AURUM; WOHLIN, 2005). Uma entrevista uma conversa direcionada com um propsito especfico, que utiliza um formato pergunta-resposta (KENDALL; KENDALL, 2010). Entrevistas so usadas em quase todos os esforos de levantamento de requisitos. Nelas, os analistas formulam questes para os interessados e os requisitos so derivados das respostas a essas perguntas (SOMMERVILLE, 2007). Uma entrevista feita tipicamente por meio de uma reunio envolvendo o analista (entrevistador) e um interessado no sistema (entrevistado). Assim, um mtodo interativo de levantamento de requisitos a partir de um indivduo. Contudo, uma entrevista pode envolver mais de um entrevistador e mais de um entrevistado. Uma entrevista pode ser, por exemplo, realizada por dois entrevistadores, um fazendo a maior parte das perguntas, enquanto o outro registra as informaes obtidas e presta ateno em requisitos possivelmente perdidos. possvel, ainda, entrevistar dois ou trs interessados de uma s vez, mas deve-se evitar envolver pessoas demais, pois se pode perder o controle da entrevista e o dilogo descambar para uma discusso geral (ALEXANDER; BEUS-DUKIC, 2009). As entrevistas podem ser de dois tipos principais (SOMMERVILLE, 2007): Entrevistas fechadas, nas quais o interessado responde a um conjunto de perguntas predefinidas. Entrevistas abertas, nas quais no existe um roteiro predefinido. O analista explora vrios assuntos com o interessado e, assim, desenvolve uma maior compreenso de suas necessidades.
Geralmente, as entrevistas so uma combinao desses dois tipos. As respostas a algumas perguntas podem levar a outros questionamentos, discutidos de maneira menos estruturada. As discusses completamente abertas dificilmente funcionam bem. A maioria das entrevistas requer algumas perguntas como ponto de partida e para manter o foco em um aspecto do sistema a ser desenvolvido (SOMMERVILLE, 2007). Entrevistas so teis para, dentre outros (SOMMERVILLE, 2007; KENDALL; KENDALL, 2010; KOTONYA; SOMMERVILLE, 1998): obter objetivos organizacionais e pessoais; obter um entendimento geral sobre o problema, sobre o que os interessados fazem e como eles podem interagir com o sistema; conhecer os sentimentos do entrevistado sobre os sistemas atuais e as dificuldades que eles tm com os mesmos; levantar procedimentos informais para interao com tecnologias da informao.
No entanto, entrevistas podem no ser boas para o analista compreender ou aprender sobre o domnio da aplicao. Especialistas de domnio, muitas vezes, usam terminologia e jarges especficos, o que provoca mal entendidos por parte dos analistas. Alm disso, alguns conhecimentos so to familiares para os interessados que so considerados difceis de explicar; outros so considerados to bsicos que os especialistas de domnio consideram que no vale a pena mencion-los (SOMMERVILLE, 2007).
35
Em uma entrevista, o engenheiro de requisitos est, provavelmente, estabelecendo um relacionamento com uma pessoa estranha a ele. Assim, importante: (i) construir uma base de confiana e entendimento; (ii) manter o controle da entrevista; e (iii) vender a ideia do sistema, provendo informaes relevantes ao entrevistado (KENDALL; KENDALL, 2010). Uma vez que entrevistas so essencialmente atividades sociais envolvendo pessoas, sua efetividade depende em grande extenso da qualidade da interao entre os participantes. Assim, os resultados de entrevistas podem variar bastante, em funo da habilidade do entrevistador (AURUM; WOHLIN, 2005). As informaes obtidas em entrevistas complementam outras informaes obtidas de documentos, observaes de usurios etc. Assim, essa tcnica deve ser usada em conjunto com outras tcnicas de levantamento de requisitos (SOMMERVILLE, 2007). Uma entrevista precisa ser planejada. Tipicamente, o planejamento de uma entrevista, assim como o de outras atividades de levantamento de requisitos, deve considerar as quatro perguntas bsicas: Por que?: a primeira coisa a ser feita estabelecer os objetivos da entrevista. As primeiras entrevistas tm, normalmente, um carter exploratrio, quando se desejam capturar objetivos da organizao para o sistema, propsito do sistema, reas de negcio afetadas etc. Na medida em que o analista ganha entendimento sobre o problema, seu foco tende a ficar mais restrito, visando um aprofundamento em um tema ou aspecto especfico do sistema. Entrevista uma boa opo, dentre outros, para capturar metas (organizacionais ou pessoais) e sentimentos e necessidades em relao ao sistema (perspectivas de diferentes envolvidos), ou para melhorar/aprofundar o entendimento sobre o problema. Por outro lado, no uma boa opo para aprender sobre o domnio. Quem?: tendo em mente o objetivo da entrevista, o prximo passo identificar quais membros da organizao tm conhecimento acerca do assunto a ser tratado e selecionar as pessoas a serem entrevistadas. interessante levantar, ainda, o papel e a posio do potencial entrevistado na organizao. Pessoas da alta gerncia tm normalmente uma viso mais abrangente dos objetivos organizacionais e estratgicos, mas, por outro lado, no conhecem detalhes mais operacionais. Assim, o objetivo da entrevista deve guiar a seleo do entrevistado. O cliente ou patrocinador do projeto pode ajudar na identificao das pessoas mais indicadas para uma entrevista. Quando houver muitos bons candidatos a entrevistas em um mesmo papel/posio, pode-se usar amostragem para selecionar uma amostra gerencivel. Quando?: no que se refere questo temporal de uma entrevista, dois aspectos devem ser considerados: primeiro, a data e o horrio; segundo, a durao. No que se refere ao agendamento da entrevista, deve-se marcar a entrevista com certa antecedncia (preferencialmente de alguns dias) e informar o objetivo da entrevista e o tema a ser abordado, de modo que o entrevistado possa se preparar para responder s perguntas. No que se refere durao, deve-se ter em mente que o entrevistado vai interromper seu trabalho para atender o analista. Assim, deve-se evitar tomar muito o seu tempo. Entrevistas com pontos de discusso focados devem ter, em mdia, uma hora de durao. Entrevistas exploratrias, ou em situaes especiais, podem durar um pouco mais. Neste caso, bom senso fundamental e a preparao para a entrevista deve ser feita com cuidado para
36
aproveitar ao mximo a oportunidade, sobretudo quando a entrevista envolve membros da alta gerncia. Como?: conhecendo o objetivo, o entrevistado (e seu perfil) e o tempo disponvel, resta preparar a entrevista cuidadosamente para que a mesma seja o mais produtiva possvel. A preparao envolve, dentre outros, a definio do tipo das questes a serem feitas, a redao das questes propriamente dita, a definio da ordem em que as perguntas sero feitas e a definio de como a entrevista ser registrada durante a sua conduo.
Visando responder s questes acima, Kendall e Kendall (2010) sugerem que o planejamento da entrevista envolva os seguintes passos: 1. Estudar material existente sobre o domnio e a organizao. Ateno especial deve ser dada linguagem usada pelos membros da organizao, procurando estabelecer um vocabulrio comum a ser usado na elaborao das questes da entrevista. Este passo visa, sobretudo, otimizar o tempo despendido nas entrevistas, evitando-se perguntar questes bsicas e gerais. 2. Estabelecer objetivos. De maneira geral, h algumas reas sobre as quais o analista desejar fazer perguntas, tais como fontes de informao, formatos da informao, frequncia na tomada de deciso, estilo da tomada de deciso etc. 3. Decidir quem entrevistar. importante incluir na lista de entrevistados as pessoaschave das diversas classes de interessados afetados pelo sistema. O cliente pode ajudar nesta seleo. 4. Preparar o entrevistado. Uma entrevista deve ser marcada com antecedncia, de modo que o entrevistado tenha tempo para pensar sobre a entrevista. A durao deve ser de 45 minutos a uma hora. 5. Preparar a entrevista. Deve-se decidir, dentre outros, sobre os tipos de questes e a estrutura da entrevista e o modo como a mesma ser registrada. Em relao ao tipo, questes podem ser de trs tipos principais (KENDALL; KENDALL, 2010): Questes subjetivas: permitem respostas abertas. Ex.: O que voc acha de [...]?; Explique como voc [...]?. Seus pontos positivos so: (i) proveem riqueza de detalhes; (ii) revelam novos questionamentos; e (iii) colocam o entrevistado mais vontade, permitindo maior espontaneidade. Contudo, h tambm desvantagens, dentre elas: (i) podem resultar em muitos detalhes irrelevantes; (ii) podem levar perda do controle da entrevista; (iii) podem ter respostas muito longas para se obter pouca informao til; e (iv) podem dar a impresso de que o entrevistador est perdido e sem objetivo. Questes objetivas: limitam as respostas possveis. Ex: Quantos [...]?; Quem [...]?; Quanto tempo [...]?; Qual das seguintes informaes [...]?. Como vantagens, questes objetivas: (i) permitem ganho de tempo, uma vez que elas vo direto ao ponto em questo, (ii) permitem manter o controle da entrevista e (iii) levam a dados relevantes. Como desvantagens, podem ser citadas: (i) questes objetivas podem ser maantes para o entrevistado, (ii) podem falhar na obteno de detalhes importantes e (iii) no constroem uma afinidade entre entrevistador e entrevistado.
37
Questes de aprofundamento: permitem explorar os detalhes de uma questo. Podem ser subjetivas ou objetivas. Ex: Por que?; Voc poderia dar um exemplo?; Como isto acontece?.
A Tabela 3.1 apresenta um quadro comparativo de caractersticas obtidas com questes objetivas e subjetivas. Tabela 3.1 Quadro Comparativo Questes Objetivas x Subjetivas (adaptado de (KENDALL; KENDALL, 2010)). Subjetivas Confiabilidade dos dados Uso eficiente do tempo Preciso dos dados Amplitude e profundidade Habilidade requerida do entrevistador Facilidade de anlise Baixa Baixo Baixa Alta Alta Baixa Objetivas Alta Alto Alta Baixa Baixa Alta
A estrutura de uma entrevista diz respeito organizao das questes em uma sequncia lgica. De acordo com (KENDALL; KENDALL, 2010), h trs formas bsicas de se organizar as questes de uma entrevista: Estrutura de Pirmide (abordagem indutiva): inicia com questes detalhadas e objetivas e, medida que a entrevista progride, questes mais gerais, subjetivas, so colocadas. til para situaes em que o entrevistado necessita de um aquecimento para falar no assunto ou quando o analista deseja obter uma finalizao sobre o assunto. comea com questes especficas
termina com questes mais gerais Estrutura de Funil (abordagem dedutiva): inicia com questes gerais subjetivas e, medida que a entrevista avana, perguntas mais especficas, usando questes objetivas, so feitas. Essa estrutura prov um meio fcil e mais amigvel para se comear uma bateria de entrevistas. Permite levantar informao detalhada, sendo desnecessrias longas sequncias de questes objetivas e de aprofundamento. comea com questes genricas e subjetivas termina com questes especficas
38
Estrutura de Diamante: uma combinao das duas anteriores, comeando com questes especficas, passando a questes gerais e fechando a entrevista novamente com questes especficas. uma boa forma de se estruturar uma entrevista, j que mantm o interesse do entrevistado em uma variedade de questes. Contudo, tende a ser mais longa. inicia com questes especficas examina questes gerais fecha com questes especficas
Estruturar entrevistas um meio de planejar a priori a ordem em que as questes sero feitas. Obviamente, h a opo de no se definir essa ordem antecipadamente, em uma abordagem de entrevista no estruturada, na qual no h uma definio da sequncia das questes. De acordo com o andar da entrevista, caminhos possveis so avaliados e a sequncia estabelecida. Normalmente, requer mais tempo. Entretanto, vale ressaltar que, ainda que a sequncia das questes no seja definida a priori, as questes devem ser definidas antecipadamente, ou seja, o planejamento necessrio. Na vspera da reunio, recomenda-se que o analista entre em contato com o entrevistado para confirmar o horrio e o local da entrevista. Por ocasio da realizao da entrevista, interessante que o analista diga ao entrevistado o que ser feito com as informaes coletadas e assegure seu aspecto confidencial. Ao trmino da entrevista, pergunte se h algo mais sobre o assunto que o entrevistado ache importante voc saber, faa um resumo da entrevista e d um retorno acerca de suas impresses gerais. Informe o entrevistado sobre os passos seguintes e pergunte se h outra pessoa com a qual ele acha que voc deveria conversar. Quando for o caso, marque nova entrevista (KENDALL; KENDALL, 2010). Ao finalizar a entrevista, resta ainda escrever um relatrio sobre a mesma. Para escrever um bom relatrio, fundamental que, durante a conduo da entrevista, sejam feitas anotaes. Contudo, escrever um processo lento, enquanto falar rpido. Assim, as anotaes devem capturar a essncia do que foi dito (ALEXANDER; BEUS-DUKIC, 2009). O relatrio ou ata da entrevista deve capturar os pontos principais da entrevista e deve ser escrito to rpido quanto possvel para assegurar qualidade (KENDALL; KENDALL, 2010). De maneira geral, os seguintes itens devem ser registrados: entrevistado(s), entrevistador(es), data e hora, durao, assunto, objetivos e principais pontos discutidos. Uma vez escrito, esse relatrio deve ser enviado para avaliao por todos os participantes. Uma forma alternativa de se registrar o andamento de uma entrevista consiste em grav-la. A gravao permite o registro completo da entrevista e a reproduo para outros membros da equipe posteriormente. Contudo, muitos entrevistados no gostam de serem gravados e, por conseguinte, ficam pouco vontade. Alm disso, transcrever registros gravados uma atividade que consome tempo e confiar em gravaes para posteriormente tirar dvidas pode ser perigoso, deixando de se clarear uma dvida na hora da entrevista (ALEXANDER; BEUS-DUKIC, 2009).
39
3.2.2 Workshops de Requisitos

A coleta colaborativa de requisitos uma tcnica muito comumente empregada. Grupos so particularmente efetivos, porque eles envolvem e estabelecem o compromisso diretamente com os interessados e porque promovem cooperao (AURUM; WOHLIN, 2005). H muitas abordagens diferentes de coleta colaborativa de requisitos, tais como Workshops de Requisitos, JAD e Brainstorming. Todas aplicam, de alguma maneira, as seguintes diretrizes bsicas (PRESSMAN, 2006): (i) as reunies envolvem representantes de diferentes grupos de interessados, sendo estabelecidas regras de preparao e participao; (ii) um facilitador, que pode ser o analista ou outro participante, controla a reunio; (iii) mecanismos de anotao, tais como quadro branco, flipcharts, papis adesivos, etc., so usados para registrar as ideias levantadas; e (iv) a meta identificar ou debater um problema, propor elementos da soluo, negociar diferentes abordagens e especificar um conjunto preliminar de requisitos da soluo. Geralmente, o facilitador desempenha um papel crtico no planejamento, seleo dos participantes e, sobretudo, na conduo da reunio, de modo a encorajar a participao para se atingir objetivos de modo consensual. Se uma pessoa est participando pouco, o facilitador deve tentar traz-la para a discusso, dando espao para ela se manifestar (WIEGERS, 2003). Uma tcnica de coleta colaborativa de requisitos so os Workshops de Requisitos. Workshop de Requisitos o nome dado a um nmero de diferentes tipos de reunies envolvendo diversas pessoas, cujo foco a descoberta e desenvolvimento de requisitos (AURUM; WOHLIN, 2005). Workshops de requisitos colocam um grupo de pessoas junto, com o objetivo comum de levantar requisitos para um problema compartilhado, para o qual essas pessoas tm vises distintas. O propsito obter conhecimento e energia suficientes para levantar requisitos rpida e eficientemente (ALEXANDER; BEUS-DUKIC, 2009). Em alguma extenso, o trabalho em grupo (workshop de requisitos) se sobrepe ao trabalho com indivduos (entrevistas). Entretanto, um grupo rene informaes de vrias fontes, coloc-as juntas, permite ouvir vrios pontos de vista, refina o entendimento coletivo e atinge concordncia de uma maneira que no possvel com outras tcnicas de levantamento de requisitos (ALEXANDER; BEUS-DUKIC, 2009). Para um workshop ser bem sucedido, os participantes devem estar de acordo com alguns princpios operacionais bsicos, tais como comear e terminar a reunio nos horrios predefinidos, manter apenas uma conversa de cada vez, permitir a contribuio de todos e enfocar comentrios e crticas em questes e no em indivduos. Diferentes interessados tipicamente tm um objetivo comum, mas tm diferentes vises do problema e sub-objetivos bastante distintos. Ningum deve esquecer seus prprios sub-objetivos, mas o credo de todos os participantes deve ser: Meu ponto de vista um dentre vrios e o mais importante o objetivo final comum. Deve-se considerar, ainda, que o sucesso de um workshop de requisitos depende fortemente da habilidade do facilitador e dos participantes trabalharem como uma equipe inovadora. Alm disso, deve ser possvel dar voz a todos os participantes (WIEGERS, 2003; ALEXANDER; BEUS-DUKIC, 2009). Um workshop de requisitos no simplesmente uma reunio. Um workshop uma reunio com propsito definido e atividades planejadas. Assim, requer planejamento endereando as quatro questes bsicas:
40
Por que?: a primeira coisa a ser feita estabelecer os objetivos do workshop. Workshops so provavelmente o principal meio de tomar decises e fechar um acordo entre membros de um grupo. Vrias informaes podem ser alvo de descoberta em um workshop de requisitos, dentre elas as influncias que interessados tm uns sobre os outros, objetivos, riscos, fronteiras do sistema, restries e atributos de qualidade (requisitos no funcionais) e prioridades (ALEXANDER; BEUS-DUKIC, 2009). Quem?: grupos pequenos (at seis participantes) tendem a funcionar melhor. melhor organizar grupos menores em diferentes workshops do que ter um grupo muito grande. As pessoas devem ser convidadas em funo dos objetivos e das atividades planejadas para o workshop e da contribuio que as pessoas podem dar. Especialistas e pessoas com poder de deciso sobre os requisitos so bons candidatos a participantes (WIEGERS, 2003; ALEXANDER; BEUS-DUKIC, 2009). Quando?: da mesma forma que entrevistas, workshops devem ser agendados com antecedncia, em datas acordadas com todos os participantes. No que se refere durao, deve-se ter em mente que todos os participantes vo interromper seu trabalho para atender ao workshop. Assim, sesses de workshops devem ser to curtas quanto possvel, idealmente com durao de uma a duas horas. Contudo, alguns projetos podem requerer sesses mais longas, algumas vezes com durao de alguns dias (ALEXANDER; BEUS-DUKIC, 2009). Como?: durante a preparao, defina os recursos necessrios (computadores, projetores, quadros brancos, flipcharts etc) e garanta que eles estaro disponveis no perodo do workshop. Proveja o material de preparao necessrio para os participantes com antecedncia. O layout da sala tambm importante. Layouts em crculo ou na forma de U funcionam bem, uma vez que eles colocam todos os participantes em um mesmo nvel de importncia. Por fim, obviamente, a definio de tpicos a serem discutidos deve ser feita cuidadosamente. Tpicos complexos podem ser divididos em sries de questes mais simples, tais como: Quais os objetivos dos interessados para o assunto em questo? Que conflitos podem surgir? Como podemos ver isso funcionando (cenrios)? Quais os argumentos de cada lado? possvel imaginar diferentes solues para o problema? Quais so prioridades? (ALEXANDER; BEUS-DUKIC, 2009).
Durante a conduo do workshop, enfatize que o tempo limitado e minimize distrbios, solicitando, p.ex., que as pessoas desliguem seus celulares. Atribua papis s pessoas, tais como responsvel por controlar o tempo, responsvel por controlar se a discusso est fugindo do assunto, responsvel por fazer anotaes etc. Uma vez terminado, as informaes descobertas no workshop devem ser registradas em um relatrio, o qual deve ser validado pelos participantes (ALEXANDER; BEUS-DUKIC, 2009). Workshops de requisitos podem ser combinados com diversas tcnicas. Durante um workshop de requisitos, por exemplo, cenrios podem ser elaborados. Por outro lado, resultados obtidos em diversas entrevistas podem ser levados discusso em um workshop.
41
3.2.3 Questionrios
Questionrio ou survey uma tcnica de levantamento de informaes que permite ao analista capturar, de vrias pessoas afetadas pelo sistema, atitudes, crenas, comportamentos e caractersticas. Atitudes referem-se a o que as pessoas na organizao dizem querer; crenas referem-se a o que as pessoas pensam ser realmente verdade; comportamento o que as pessoas fazem; caractersticas so propriedades de pessoas ou coisas (KENDALL; KENDALL, 2010). H muitas similaridades entre questionrios e entrevistas e pode ser til utilizar as duas abordagens em conjunto para refinar respostas no claras de um questionrio em uma entrevista ou para projetar um questionrio com base no que foi descoberto em uma entrevista. Usando questionrios aps a realizao de entrevistas, um analista pode estar procurando quantificar o que foi levantado em entrevistas ou determinar como um sentimento expresso em uma entrevista realmente difundido ou limitado. Por outro lado, questionrios podem ser usados para examinar uma grande amostra de usurios para sentir problemas ou levantar questes importantes, antes de se programar entrevistas (KENDALL; KENDALL, 2010). Questionrios proveem um meio eficiente de coletar informaes de vrios interessados. Entretanto, so limitados no que tange profundidade do conhecimento que pode ser levantado, uma vez que no permitem que um tpico seja aprofundado ou que ideias sejam expandidas (AURUM; WOHLIN, 2005). Questionrios so teis quando (KENDALL; KENDALL, 2010): As pessoas necessrias esto geograficamente dispersas. H um grande nmero de pessoas envolvidas no projeto do sistema e necessrio saber qual proporo de um dado grupo aprova ou desaprova uma particular caracterstica do sistema proposto. Se deseja saber uma opinio global antes de se definir qualquer direo especfica para o projeto, em um estudo exploratrio. Deseja-se assegurar que os problemas com o sistema corrente foram identificados e tratados em entrevistas que se seguem.
Uma vez que questionrios e entrevistas seguem uma abordagem pergunta-resposta, seria bastante razovel pensar que as consideraes feitas para entrevistas aplicam-se tambm para questionrios. Contudo, importante ressaltar que h diferenas fundamentais entre essas tcnicas e, portanto, outros aspectos devem ser considerados. Em primeiro lugar, entrevistas permitem interao direta com o entrevistado a respeito das questes e seus significados. Em uma entrevista, o analista pode refinar uma questo, definir um termo obscuro, alterar o curso do questionamento e controlar o contexto de modo geral. Isto no necessariamente verdade para um questionrio e, portanto, o planejamento de um questionrio e de suas questes deve ser mais cuidadoso. Assim, um questionrio deve ter questes claras e no ambguas, fluxo bem definido e administrao planejada em detalhes. Alm disso, devem-se levantar, antecipadamente, as dvidas das pessoas que vo respond-lo (KENDALL; KENDALL, 2010).
42
Em relao s quatro perguntas bsicas, valem as seguintes consideraes: Por que?: assim como os demais mtodos, a primeira coisa a ser feita estabelecer os objetivos de um questionrio. Conforme citado anteriormente, questionrios podem ser usados para quantificar o que foi levantado com outros mtodos, para determinar como um sentimento capturado por meio de outras tcnicas de levantamento de requisitos realmente difundido ou limitado, ou para examinar uma grande amostra de usurios para sentir problemas ou levantar questes importantes. Quem?: a definio de quem dever responder o questionrio deve ser feita em conjunto com a definio de seus objetivos. Usar amostragem pode ajudar a determinar quais classes de pessoas so necessrias e o tipo de respondentes. As pessoas que vo efetivamente responder o questionrio so escolhidas, dentre outros, em funo de sua posio, tempo de servio, responsabilidades e interesse no sistema corrente ou proposto. importante garantir que um nmero suficiente de respondentes ser includo, de modo a permitir uma amostra razovel, considerando que algumas pessoas no vo responder ou vo responder erradamente e tero seus questionrios descartados. Quando?: esta questo est fortemente relacionada ao mtodo de aplicao do questionrio a ser adotado. Quando se decide reunir todos os respondentes em um mesmo lugar e momento, deve-se definir data, hora e durao. Quando os respondentes so livres para administrar o preenchimento do questionrio, deve-se indicar at que data isso deve ser feito e qual a durao esperada para se responder o questionrio. Como?: dentre os aspectos a serem considerados no projeto de um questionrio, podem ser citados os tipos e a redao das questes, escalas e meio de aplicao.
Questionrios podem ter questes objetivas ou subjetivas. Questes subjetivas so particularmente adequadas a situaes em que se deseja saber a opinio dos membros da organizao acerca de algum aspecto do sistema, sendo impossvel, portanto, listar efetivamente todas as respostas possveis para uma pergunta. Quando se decidir utilizar questes subjetivas em um questionrio, deve-se antecipar o tipo de resposta que se espera obter. Essas questes devem ser restritas o suficiente para guiar as pessoas, de modo que respondam de uma maneira especfica (KENDALL; KENDALL, 2010). Deve-se tomar cuidado com perguntas que permitam respostas muito amplas, pois isso pode dificultar a comparao e a interpretao dos resultados Questes objetivas, por outro lado, devem ser utilizadas em um questionrio quando o engenheiro de requisitos capaz de listar as possveis respostas e quando h uma grande amostra de pessoas a examinar. Respostas a questes objetivas so mais facilmente quantificadas, enquanto respostas a questes subjetivas so analisadas e interpretadas de maneira diferente. A Tabela 3.2 compara o uso de questes objetivas e subjetivas em questionrios (KENDALL; KENDALL, 2010).
43
Tabela 3.2 Uso de questes subjetivas e objetivas em questionrios (adaptado de (KENDALL; KENDALL, 2010)). Questes Subjetivas Tempo gasto para responder Natureza exploratria Amplitude e profundidade Facilidade de preparao Facilidade de anlise Alto Alta Alta Alta Baixa Questes Objetivas Baixo Baixa Baixa Baixa Alta
Assim como ocorrem com as entrevistas, a linguagem utilizada na elaborao de questionrios extremamente importante para a sua efetividade. prudente escrever as questes de modo a refletir a terminologia particular do negcio. Assim, tanto as perguntas quanto as respostas sero mais fceis de interpretar. Para verificar a linguagem utilizada, aplique o questionrio antecipadamente em um grupo piloto, pedindo ateno adequabilidade dos termos empregados. Kendall e Kendall (2010) recomendam que, dentre outras, as seguintes diretrizes sejam observadas na redao de um questionrio: Sempre que possvel, use o vocabulrio das pessoas que iro responder. Prime pela simplicidade. Utilize perguntas simples e curtas. Evite redao tendenciosa. Garanta que as questes esto tecnicamente precisas antes de inclu-las no questionrio.
Em questionrios, escalas so usadas para atribuir nmeros ou outros smbolos para um atributo ou caracterstica com o propsito de medir esse atributo ou caracterstica. Escalas so frequentemente arbitrrias e podem no ser nicas (por exemplo, escalas de temperatura em oC, oF, K). H duas formas de escalas de medio comumente usadas por analistas de sistemas (KENDALL; KENDALL, 2010): Nominal: utilizada para classificar coisas. a forma mais fraca de medio, uma vez que s obtm totais para cada classificao. Ex: Que tipo de software voc mais usa? 1- Editor de Texto 2- Planilha 3- Grfico 4- Outros de Intervalo: tem como trao marcante o fato de intervalos entre os nmeros das opes serem iguais, o que permite que sejam feitas operaes matemticas sobre os dados obtidos do questionrio e, portanto, uma anlise mais completa. Ex.: escala de temperaturas.
Seja a questo abaixo: Quo til o suporte tcnico do Centro de Informao? 1- Nada til 2 3 4 5- Extremamente til Claramente, ela no exatamente uma escala de intervalo, mas ao ancorar a escala em ambas as extremidades, permite ao analista assumir que os respondentes vo perceber os intervalos como iguais, tornando anlises quantitativas possveis.
44
Na construo de escala, alguns problemas podem ocorrer. A seguir so listados alguns desses problemas e possveis solues (KENDALL; KENDALL, 2010): Condescendncia: a pessoa responde a todas as questes do mesmo jeito. Soluo: mover a categoria mdia para a esquerda ou direita em relao ao centro. Tendncia Central: a pessoa responde tudo na mdia. Soluo: tornar as diferenas menores nos extremos, ajustar a fora dos descritores ou criar uma escala com mais pontos. Efeito Aurola: a impresso formada em uma questo levada para a prxima. Soluo: mesclar questes sobre objetos diferentes.
Um questionrio relevante e bem projetado pode aumentar a taxa de respostas. As seguintes diretrizes podem ser teis durante o projeto um questionrio (KENDALL; KENDALL, 2010): Deixe espaos em branco. Deixe espao suficiente para as respostas (para questes subjetivas). Torne fcil para os respondentes marcar claramente suas respostas (para questes objetivas). Seja consistente no estilo.
Questionrios podem ser aplicados de diversas maneiras. Quando se decide aplicar um questionrio por email ou pela Web, consideraes adicionais de planejamento relativas a confidencialidade, autenticao de identidade e problemas com mltiplas respostas devem ser levadas em conta. No caso de questionrios disponveis na Web, use formatos de entrada de dados comumente usados, tais como caixas de texto, check boxes, radio buttons, drop-down menu etc (KENDALL; KENDALL, 2010). Para ordenar as questes, considere os objetivos e, ento, determine a funo de cada questo para atingir esses objetivos. Use um grupo piloto para auxiliar ou observe o questionrio com olhos de respondedor. Algumas orientaes devem ser seguidas, dentre elas (KENDALL; KENDALL, 2010): Coloque questes que so importantes para os respondentes primeiro. Agrupe itens de contedo similar e observe tendncias de associao. Coloque questes menos controversas primeiro.
Por fim, no que se refere ao mtodo de aplicao do questionrio, h diversas possibilidades, cada uma delas apresentando vantagens e desvantagens. Pode-se, por exemplo, reunir todos os respondedores em um mesmo local para a aplicao do questionrio. Isso permite alto retorno, instrues uniformes e resultado rpido. Contudo, pode ser difcil reunir todas as pessoas em s lugar ao mesmo tempo e o respondedor pode ter coisas importantes a fazer (KENDALL; KENDALL, 2010). De maneira geral, permite-se que os respondentes administrem quando vo responder o questionrio. Neste caso, corre-se o risco das pessoas esquecerem ou propositalmente ignorarem o questionrio. Contudo, refora-se a sensao de anonimato e, por conseguinte, podem-se obter respostas menos protegidas (KENDALL; KENDALL, 2010).
45
Aplicar questionrios eletronicamente, seja por email seja por meio de formulrio na Web, um meio de rapidamente chegar aos respondentes. Evitam-se custos com cpias, as respostas podem ser dadas de acordo com a convenincia dos respondedores e automaticamente coletadas e armazenadas eletronicamente. Alguns sistemas para aplicar questionrios permitem que o respondedor comece a responder, salve suas respostas e volte ao questionrio posteriormente para completar seu preenchimento. Lembretes aos respondentes podem ser facilmente enviados por email, assim como notificaes ao analista sobre quando o respondente abriu a mensagem. Pesquisas mostram que questionrios pela Web podem encorajar respostas francas e consistentes. Questes que podem ser difceis de serem colocadas pessoalmente podem ser aceitveis de serem respondidas em um survey pela Web (KENDALL; KENDALL, 2010).
3.2.4 - Observao
As pessoas, muitas vezes, tm dificuldade em articular detalhes de seu trabalho, pois esto imersas nele e fazem muitas coisas de maneira intuitiva. Contudo, os contextos social e organizacional em que as pessoas trabalham so importantes para o desenvolvimento de um sistema e podem derivar requisitos e restries (SOMMERVILLE, 2007). Assim, observar o comportamento e o ambiente do indivduo, sobretudo aquele que toma decises, pode ser uma forma bastante eficaz de levantar informaes que, tipicamente, passam despercebidas quando outras tcnicas so usadas (KENDALL; KENDALL, 2010). A etnografia o estudo de pessoas em seu ambiente natural. No contexto do levantamento de requisitos, envolve a participao ativa ou passiva do analista nas atividades normais dos usurios, durante um perodo de tempo, enquanto coleta informaes a respeito dos processos sendo realizados. Tcnicas de etnografia so especialmente teis para enderear fatores contextuais e de ambientes de trabalho cooperativo (AURUM; WOHLIN, 2005). A observao uma das tcnicas de etnografia mais usadas no levantamento de requisitos. Como o prprio nome indica, o analista observa os usurios executando os processos, sem interferncia direta (AURUM; WOHLIN, 2005). Ela empregada para compreender requisitos sociais e organizacionais, bem como para compreender como as tarefas so realizadas efetivamente. O analista se insere no ambiente de trabalho onde o sistema ser usado, observa o trabalho do dia-a-dia e faz anotaes acerca das tarefas reais nas quais os participantes esto envolvidos (SOMMERVILLE, 2007). Atravs da observao possvel capturar (SOMMERVILLE, 2007; KENDALL; KENDALL, 2010): Requisitos derivados da maneira como as pessoas realmente trabalham e no da maneira como os processos so documentados ou explicados. possvel derivar requisitos implcitos que refletem os processos reais (e no os formais) com os quais as pessoas esto envolvidas. Requisitos derivados do relacionamento entre o indivduo que toma decises e outros membros da organizao. Esses requisitos so derivados da colaborao e do conhecimento das atividades de outras pessoas.
Por outro lado, essa tcnica no apropriada para obter requisitos de domnio, bem como pode ser difcil identificar novas caractersticas a serem acrescentadas ao sistema. Assim, a observao deve ser combinada com outras tcnicas de levantamento de requisitos.
46
Quando aplicadas em conjunto, observao pode ser usada para confirmar ou negar informaes de entrevistas e/ou questionrios. Tambm se podem entrevistar as pessoas observadas para completar informaes obtidas de uma observao. A observao pode ser combinada tambm com a prototipagem. Uma vez construdo um prottipo, podem-se observar os usurios utilizando o prottipo, de modo a avaliar o mesmo e derivar novos requisitos (SOMMERVILLE, 2007; KENDALL; KENDALL, 2010; KOTONYA; SOMMERVILLE, 1998). Alm disso, deve-se ressaltar que a efetividade de uma observao pode variar na medida em que os usurios tm tendncia a ajustar o modo como realizam suas tarefas quando sabem que esto sendo observados (AURUM; WOHLIN, 2005). Como outras tcnicas de levantamento de requisitos, a observao envolve planejamento, conduo e o registro de resultados. No planejamento, o analista deve definir o que observar, quem observar, quando, onde, porque e como. Kotonya e Sommerville (1998) apontam que no h uma forma padro de se conduzir estudos etnogrficos, contudo, indicam algumas diretrizes para a aplicao dessa tcnica, dentre elas: muito importante despender um tempo conhecendo as pessoas envolvidas e estabelecendo uma relao de confiana. Deve-se assumir que as pessoas que esto sendo observadas so boas em seu trabalho e procurar capturar meios no padronizados de trabalhar. Esses meios frequentemente apontam para eficincias no processo de trabalho que foram incorporadas a partir da experincia individual. Devem-se tomar notas detalhadas das prticas de trabalho durante a observao e redigir um relatrio. possvel aprender bastante com os detalhes de como as pessoas trabalham. Somente aps diversos desses detalhes terem sido coletados, que um quadro coerente vai emergir. til que o analista, antes de iniciar o trabalho, informe as pessoas e diga como a observao vai ser conduzida e seu propsito.
No que se refere definio de quando realizar a observao, importante no considerar apenas se o indivduo (ou indivduos) a serem observados estaro trabalhando nos processos de interesse no perodo agendado, mas tambm se esse processo de negcio de interesse tem uma ocorrncia significativa no perodo considerado.
3.2.5 Prototipagem
Muitas vezes as pessoas acham difcil visualizar como um requisito especificado na forma de uma sentena escrita ou por um conjunto de modelos vai se materializar em um sistema de software. De maneira geral, pessoas tm dificuldade de descrever suas necessidades sem ter algo tangvel sua frente. Nesses casos, se um prottipo do sistema desenvolvido para demonstrar requisitos, fica mais fcil para usurios e outros interessados encontrar problemas e sugerir como os requisitos podem ser melhorados. Afinal, criticar mais fcil do que criar (KOTONYA; SOMMERVILLE, 1998; WIEGERS, 2003). Um prottipo uma verso inicial do sistema que desenvolvido no incio do processo de desenvolvimento. No contexto da engenharia de requisitos, um prottipo desenvolvido com o propsito de apoiar o levantamento e a validao de requisitos. Assim, nesse contexto, uma caracterstica essencial de um prottipo que ele seja desenvolvido rapidamente (KOTONYA; SOMMERVILLE, 1998).
47
A prototipagem uma tcnica valiosa para o levantamento de requisitos. Ela torna os requisitos mais reais e diminui lacunas de entendimento. Ao colocar o usurio na frente de uma poro inicial ou uma imitao do sistema, a prototipagem estimula os usurios a pensar e a estabelecer um dilogo sobre os requisitos. As consideraes tecidas sobre o prottipo ajudam a se obter um entendimento compartilhado dos requisitos (WIEGERS, 2003). Alm disso, a prototipagem muito til quando os interessados esto pouco familiarizados com as solues disponveis (AURUM; WOHLIN, 2005). Este o caso, por exemplo, da introduo de novas tecnologias. Prottipos podem servir a outros propsitos, alm do propsito de clarear e completar o entendimento sobre requisitos. Prottipos podem ser usados para explorar alternativas de projeto (design), sobretudo no projeto de interfaces com o usurio, bem como a prototipagem pode ser usada como parte de uma estratgia de desenvolvimento, na qual prottipos iniciais vo sendo gradativamente transformados no produto final, atravs de uma sequncia de iteraes de desenvolvimento. Contudo, do ponto de vista da Engenharia de Requisitos, foco deste texto, a principal razo para se desenvolver um prottipo resolver incertezas a respeito dos requisitos do sistema o mais cedo possvel. Assim, essas incertezas devem ser usadas para decidir que partes do sistema prototipar e o que se espera aprender com as avaliaes do prottipo (WIEGERS, 2003). A prototipagem permite capturar as reaes iniciais do usurio em relao ao sistema. Essas reaes podem ser obtidas atravs de observao, entrevistas, questionrio ou relatrio de avaliao e podem ser usadas pelo engenheiro de requisitos para guiar iniciativas em direo de melhor atender as necessidades dos usurios, bem como para ajudar a estabelecer (ou rever) prioridades e redirecionar planos. Usurios, por sua vez, podem vislumbrar novas capacidades, no imaginadas antes da interao com o prottipo e que surgiram da experimentao com o mesmo (KENDALL; KENDALL, 2010): Se um prottipo for desenvolvido para apoiar o levantamento de requisitos, faz sentido utiliz-lo posteriormente na validao. Contudo, no vale a pena desenvolver um prottipo apenas para apoiar a validao de requisitos (KOTONYA; SOMMERVILLE, 1998). Diferentes tipos de prottipos podem ser desenvolvidos, sendo que diferentes autores denominam esses tipos de forma diferente. Quanto s camadas da arquitetura que so efetivamente implementadas, um prottipo pode ser: Prottipo no-operacional ou de interface: apenas a camada de interface com o usurio implementada; as demais camadas da arquitetura do sistema no so e, portanto, o sistema no faz nenhum processamento propriamente dito. Wiegers (2003) denomina este tipo de prottipo de prottipo horizontal, exatamente porque ele no trata todas as camadas da arquitetura do sistema. til para avaliar certos aspectos do sistema quando a codificao requerida pela aplicao custosa e a noo bsica do que o sistema pode ser transmitida pela anlise de suas interfaces (KENDALL; KENDALL, 2010). Prottipos no operacionais mostram as opes de funes que estaro disponveis para o usurio e a aparncia das interfaces. Contudo no contm funcionalidade real. s vezes, a navegao pode funcionar, mas em alguns pontos o usurio pode se deparar apenas com uma mensagem descrevendo o que seria realmente mostrado. Os dados que aparecem em resposta a uma consulta so apenas ilustrativos e muitas vezes so constantes, definidas no prprio cdigo do prottipo. Mesmo quando isso feito, deve-se procurar usar dados reais para realar a validade do prottipo como um modelo do
48
sistema real. Normalmente, essa simulao boa o suficiente para os usurios fazerem um julgamento se h funcionalidade faltando, errada ou desnecessria (WIEGERS, 2003). Prottipo operacional: funciona como se supe que o sistema real deveria funcionar e implementa de alguma forma todas as camadas da arquitetura do sistema. Wiegers (2003) denomina este tipo de prottipo de prottipo vertical, uma vez que ele trata em alguma extenso de todas as camadas da arquitetura do sistema. Um prottipo vertical tipicamente usado para reduzir riscos durante o projeto, podendo ser usado, dentre outros, para avaliar se uma arquitetura vivel e slida, ou para testar requisitos crticos. Prottipos verticais so construdos usando ferramentas de produo, ou seja, as mesmas usadas para construir o prprio sistema (WIEGERS, 2003).
Quanto ao uso futuro do prottipo como base para o sistema real, ou no, um prottipo pode ser: Prottipo descartvel: um prottipo exploratrio e no se pretende utiliz-lo como uma parte real do sistema a ser fornecido (PFLEEGER, 2004). O prottipo construdo apenas para apoiar o levantamento e a validao de requisitos, sendo descartado aps essas fases. Prottipos descartveis enfatizam o desenvolvimento rpido, sem prestar ateno a princpios de engenharia e qualidade de software. Eles no devem ser mais elaborados do que o necessrio para atingir seus objetivos. Assim, alguns atributos de qualidade, como robustez, confiabilidade e desempenho, podem no ser levados em conta. O uso de prottipos descartveis mais apropriado quando a equipe se depara com incertezas, ambiguidade, falta de completeza e impreciso nos requisitos (WIEGERS, 2003). Prottipo evolutivo: desenvolvido para se aprender mais sobre o problema e se ter a base de uma parte ou de todo o software a ser fornecido (PFLEEGER, 2004). Em contraste com um prottipo descartvel, o prottipo parte (ou uma verso) do produto final e deve prover uma base para construir esse produto de forma incremental. Portanto, deve considerar princpios de engenharia e qualidade de software (WIEGERS, 2003). Prottipo de caractersticas selecionadas: apenas uma poro do sistema implementada no prottipo. Prottipo completo: o prottipo apresenta todas as caractersticas do que se imagina ser o sistema real.
Quanto ao conjunto de funcionalidades provido pelo prottipo, um prottipo pode ser:
Essas diferentes classificaes de prottipos so em certa extenso ortogonais e podem ser combinadas. Por exemplo, um primeiro prottipo que implementa apenas parte das interfaces de um sistema, mas que usado como base para o desenvolvimento posterior pode ser classificado como um prottipo de interface, evolutivo e de caractersticas selecionadas. J o que Kendall e Kendall (2010) chamam de um prottipo arranjado s pressas (i.e., um prottipo que possui toda a funcionalidade do sistema final, mas que no foi construdo com o devido cuidado e que, portanto, sua qualidade e desempenho so deficientes) pode ser considerado um prottipo operacional e completo, podendo ser descartvel ou evolutivo, dependendo se ele for ser usado, ou no, como base para o desenvolvimento do produto final. O que Kendall e Kendall (2010) chamam de um prottipo primeiro de uma srie (i.e., um
49
sistema piloto desenvolvido para ser avaliado antes de ser distribudo) pode ser considerado um prottipo operacional, completo e evolutivo. Contudo, nem todas as categorias podem ser combinadas entre si. Por exemplo, um prottipo no operacional necessariamente um prottipo de caractersticas selecionadas, uma vez que ele certamente no implementa todas as caractersticas que se imagina ter o sistema real. Diferentes tipos de prottipos podem ser combinados para apoiar um mesmo projeto de desenvolvimento. Por exemplo, no estgio de levantamento preliminar de requisitos, prottipos de interface podem ser usados para refinar requisitos. Esses requisitos so ento gradativamente refinados e implementados em uma srie de prottipos evolutivos, considerando inicialmente apenas os principais processos de negcio (caractersticas selecionadas) e algumas camadas do software (interface com o usurio e lgica de negcio). Outros elementos so incorporados ao produto final, por meio de incrementos e iteraes sucessivas, at se obter o produto de software final. A prototipagem tambm requer planejamento. Devem-se definir porque, quando e que tipo de prottipo usar, selecionar usurios para avaliar o prottipo e definir como o feedback do usurio ser obtido. Usurios so fundamentais na prototipagem. Para capturar as reaes dos usurios em relao ao prottipo, outras tcnicas de levantamento de informao devem ser usadas em conjunto. Durante a experimentao do usurio com o prottipo, pode-se utilizar observao. Para capturar opinies e sugestes, podem ser empregados, alm da observao, entrevistas e questionrios (KENDALL; KENDALL, 2010). Para o desenvolvimento do prottipo, as seguintes diretrizes podem ser teis (KENDALL; KENDALL, 2010; WIEGERS, 2003): Defina o propsito de um prottipo antes de comear a constru-lo. Trabalhe com mdulos gerenciveis: para fins de prototipagem no necessrio e muitas vezes, nem desejvel, construir um sistema completo. Construa o prottipo rapidamente: a construo de um prottipo durante as fases de levantamento e anlise de requisitos no pode consumir tempo em demasia, caso contrrio perde sua finalidade. Para acelerar a construo, use ferramentas adequadas. Modifique o prottipo em iteraes sucessivas: o prottipo deve ser alterado em direo s necessidades do usurio. Cada modificao requer uma nova avaliao. Enfatize a interface com o usurio: as interfaces do prottipo devem permitir que o usurio interaja facilmente com o sistema. Um mnimo de treinamento deve ser requerido. Sistemas interativos com interfaces grficas so muito indicados prototipagem.
A prototipagem pode trazer uma srie de benefcios, dentre eles (KENDALL; KENDALL, 2010): Permite alterar o sistema mais cedo no desenvolvimento, adequando-o mais de perto s necessidades do usurio (menor custo de uma alterao). Permite descartar um sistema quando este se mostrar inadequado (anlise de viabilidade).
50
Possibilita desenvolver um sistema que atenda mais de perto as necessidades e expectativas dos usurios, na medida em que permite uma interao com o usurio ao longo de todo o ciclo de vida do desenvolvimento.
Contudo, a prototipagem tambm pode ser fonte de problemas, dentre eles (KENDALL; KENDALL, 2010; AURUM; WOHLIN, 2005; WIEGERS, 2003): Gerncia do projeto: Normalmente, vrias iteraes so necessrias para se refinar um prottipo. Sob esta tica, surge uma importante questo: quando parar? Se essa questo no for tratada com cuidado, a prototipagem pode se estender indefinidamente. importante, pois, delinear e seguir um plano para coletar, analisar e interpretar as informaes de feedback do usurio. Alm disso, em alguns casos, trabalhar com prottipos pode ser caro e demandar muito tempo. Considerar o prottipo como sendo o sistema final: o maior risco da prototipagem que usurios, ao verem um prottipo rodando, concluam que o projeto est prximo de seu fim, achando que o prottipo o sistema final. Analogamente, os desenvolvedores podem se sentir tentados a transformar prottipos descartveis no sistema, no levando em conta que a qualidade pode no ter sido apropriadamente considerada. Assim, gerenciar expectativas fundamental para um uso bem sucedido da prototipagem. Todos que veem o prottipo devem entender seu propsito e suas limitaes.
3.2.6 Outras Tcnicas de Levantamento de Requisitos

Alm das tcnicas discutidas anteriormente, h vrias outras igualmente teis. Dentre elas, podem ser citadas: Investigao ou Anlise de Documentos: em qualquer negcio, h vrios documentos cuja interpretao pode ajudar no levantamento de informaes, tais como relatrios usados na tomada de deciso, fichas e uma variedade de formulrios. Documentos com formato pr-determinado, tais como relatrios e formulrios, tm um propsito especfico e um pblico-alvo e trazem informaes muito teis. Relatrios de desempenho, por exemplo, podem mostrar metas da organizao, a distncia em que a organizao se encontra da meta e a tendncia atual. Relatrios usados no processo de tomada de deciso mostram informaes compiladas e podem incorporar algum conhecimento sobre a estratgia da organizao. Formulrios, assim como fichas, so muito teis para o levantamento de requisitos de informao. Tais informaes so difceis de serem obtidas atravs de outras tcnicas de levantamento de requisitos, como entrevistas e observao (KENDALL; KENDALL, 2010). Cenrios: so descries narrativas ou histrias de processos correntes e futuros, incluindo aes e interaes entre usurios e o sistema. O enredo da histria se refere a uma poro do trabalho que est sendo estudada. O termo enredo usado para designar que a poro de trabalho dividida em um nmero de passos ou cenas. Explicando-se esses passos, explica-se o trabalho. Muitas vezes, cenrios so usados para se chegar a um entendimento acerca de um caso de uso, mostrando, passo a passo, como um caso de uso realizado. Uma vez que casos de uso capturam uma poro discreta de funcionalidade, interessante definir cenrios para contar a histria de um caso de uso. As pessoas geralmente
51
consideram mais fcil relatar exemplos de situaes reais do que abstrair descries e, da vem a utilidade dos cenrios. Um cenrio pode comear com um esboo da interao e, durante o levantamento de requisitos, detalhes podem ser adicionados para criar uma descrio mais completa dessa interao. Neste sentido, cenrios requerem uma abordagem incremental e interativa de desenvolvimento. Alm disso, cenrios tipicamente no consideram a estrutura interna do sistema (AURUM; WOHLIN, 2005; ROBERTSON; ROBERTSON, 2006; SOMMERVILLE, 2007). Coleta Colaborativa de Requisitos: alm dos Workshops de Requisitos discutidos anteriormente, outras duas tcnicas de coleta colaborativa de requisitos so bastante utilizadas: o Brainstorming: neste tipo de reunio, representantes de diferentes grupos de interessados engajam-se em uma discusso informal para gerar rapidamente tantas ideias quanto possvel, sem focar a ateno em nenhuma delas. Normalmente no propsito de uma sesso de brainstorming resolver maiores questes ou tomar decises. Essa tcnica frequentemente utilizada para desenvolver uma declarao preliminar da misso e dos requisitos do sistema. Um diferencial dessa tcnica que ela promove a livre expresso, favorecendo a descoberta de solues novas e inovadoras para problemas existentes (AURUM; WOHLIN, 2005). o JAD (Joint Application Development): envolve a participao de diferentes interessados na investigao, por meio de discusses, tanto de problemas a serem resolvidos quanto das solues disponveis para esses problemas. Com as diversas partes envolvidas representadas, decises podem ser tomadas e questes resolvidas mais rapidamente. Em uma sesso JAD, ao contrrio de uma sesso de brainstorming, as metas do sistema j esto definidas. Contudo, o foco de uma seo JAD de requisitos ainda recai nas necessidades e desejos de usurios e do prprio negcio e no em detalhes tcnicos (AURUM; WOHLIN, 2005). Reso de Requisitos: sempre uma boa prtica de engenharia de software reutilizar tanto conhecimento quanto possvel durante o desenvolvimento de um novo sistema. Isso no diferente no caso de requisitos (KOTONYA; SOMMERVILLE, 1998). O reso de requisitos possvel em diversas situaes, dentre elas: (i) requisitos relacionados ao mesmo domnio de aplicao; (ii) requisitos relacionados mesma tarefa; (iii) requisitos de sistemas considerados similares; e (iv) requisitos que refletem polticas organizacionais. Alm disso, modelos podem ser reutilizados, conforme discutido no Captulo 8 deste texto.
3.2.7 Aplicando as Tcnicas de Levantamento de Requisitos

Duas importantes questes que precisam ser abordadas em relao s tcnicas de levantamento de requisitos so (AURUM; WOHLIN, 2005): Que tcnica(s) aplicar durante uma atividade de levantamento de requisitos? Quais dessas tcnicas so complementares?
52
Em ltima instncia, cada situao , em alguma extenso, nica e, portanto, as respostas a essas perguntas so dependentes do contexto do projeto (AURUM; WOHLIN, 2005). De maneira geral, as principais tcnicas discutidas neste texto so complementares. Algumas informaes so difceis de serem obtidas atravs de entrevistas ou observao, tais como dados sobre um determinado objeto ou evento, informao financeira e contextos da organizao. Tais informaes revelam, tipicamente, um histrico da organizao e sua direo. Nestes casos, a investigao de documentos uma boa opo, pois fatos obtidos em uma investigao podem explicar o desempenho passado da organizao. Por outro lado, metas projetam o futuro. Entrevistas so importantes para se determinar metas, obter necessidades e perspectivas individuais. A coleta colaborativa de requisitos pode ser uma boa alternativa ao uso de entrevistas, sobretudo para se ter um entendimento coletivo e para decidir sobre requisitos. Questionrios podem ser usados para quantificar o que foi levantado usando outras tcnicas de levantamento e, portanto, um questionrio pode ser definido com base no que foi levantado preliminarmente, por exemplo, em uma entrevista. Questionrios tambm podem ser usados para examinar uma grande amostra de usurios do sistema para sentir problemas ou levantar questes importantes, antes de se programar entrevistas (KENDALL; KENDALL, 2010). Observao pode ser usada para confirmar ou refutar informaes levantadas em entrevistas, workshops de requisitos e/ou questionrios, bem como para capturar informao complementar sobre os interessados, seus processos de negcio e o seu ambiente de trabalho. De maneira inversa, podem-se utilizar outras tcnicas para completar informaes obtidas em uma observao. A observao pode ser combinada tambm com a prototipagem. Uma vez construdo um prottipo, podem-se observar os usurios utilizando o prottipo, de modo a avaliar o mesmo e derivar novos requisitos. Para capturar as reaes dos usurios em relao ao prottipo, outras tcnicas de levantamento de requisitos tambm podem ser usadas, tais como entrevistas e questionrios para capturar opinies e sugestes. Por fim, cenrios podem ser usados para derivar prottipos e prottipos podem ser apresentados no contexto da discusso de um cenrio, sendo tcnicas complementares (KENDALL; KENDALL, 2010; SOMMERVILLE, 2007). De fato, quase todas as tcnicas so complementares em alguma extenso, podendo ser alternativas em outras. Assim, importante avaliar cada caso e escolher o melhor conjunto de tcnicas a serem aplicadas, levando em considerao, dentre outros, a experincia dos analistas no uso das diversas tcnicas, o perfil dos interessados e o tempo disponvel.
3.3 Requisitos e Modelagem de Processos de Negcio

O uso de sistemas de informao tem por objetivo principal apoiar aes dos processos de negcio das organizaes. Deve-se ter em mente que o principal interesse dos clientes no o sistema de informao em si, mas sim os efeitos positivos gerados pela sua utilizao. Assim, durante o levantamento de requisitos, necessrio compreender o contexto organizacional, no qual o sistema ser inserido, bem como se alinhar aos objetivos desse contexto. Se o entendimento do contexto organizacional no ocorre, os requisitos levantados tendem a ficar mais centrados em aspectos tecnolgicos, sem levar em considerao fatores organizacionais, tais como (CARVALHO, 2009):
53
Regras de negcio que tm impacto sobre o sistema; Usurios que utilizam as informaes geradas pelo sistema; Impactos gerados pelo sistema na forma de execuo dos processos de negcio da organizao.
A relao entre os processos de negcio e o entendimento do domnio de um sistema de informao constatada por diversos autores. Frye e Gulledge (2007), por exemplo, afirmam que os sistemas de informao habilitam os processos de negcio e que, se os processos de negcio e os sistemas no estiverem alinhados, ento os sistemas no atendero s expectativas de seus usurios. Essa falta de alinhamento apontada como sendo uma das principais causas do fracasso de projetos de desenvolvimento de sistemas de informao. Assim, o uso de tcnicas de levantamento de requisitos de sistemas de informao baseadas em processos de negcio torna-se relevante, pois esses sistemas mantm estreita relao com o ambiente organizacional. Um tratamento dissociado do aparato de levantamento de requisitos da viso de negcios pode levar subutilizao de potencialidades tecnolgicas (CARVALHO, 2009). Um modelo de negcio (business model) , na verdade, um conjunto de modelos que prov uma visualizao dos processos de negcio, de como estes so executados, quais so as suas metas, como cada processo trabalha para atingir essas metas, quais as unidades organizacionais e os papis das pessoas envolvidos em cada atividade do processo, quais as localidades onde a organizao est distribuda e quais eventos deflagram seus processos e atividades (KNIGHT, 2004). A Figura 3.1 esquematiza os diferentes aspectos envolvidos em um modelo de negcio.
Figura 3.1 Aspectos Envolvidos em um Modelo de Negcio (KNIGHT, 2004). Como ilustra a Figura 3.2, para modelar esses diferentes aspectos, diferentes tipos de modelos podem ser elaborados, dentre eles (KNIGHT, 2004): Modelo organizacional: representa as unidades organizacionais, seus papis e seus relacionamentos;
54
Modelo de localizao geogrfica: representa as localidades pelas quais a organizao est distribuda e os relacionamentos entre localidades e unidades organizacionais; Modelo de objetivos: mostra os objetivos da organizao e seus relacionamentos, o desdobramento dos objetivos em subobjetivos e o relacionamento entre os objetivos e os processos de negcio; Modelo de processos: representa os processos de negcio executados na organizao (com suas atividades e relacionamentos) e seus desdobramentos em subprocessos e atividades; Modelo de atividades: mostra o relacionamento entre as atividades executadas nos processos de negcio, seus responsveis, objetos de negcio e eventos que disparam ou so disparados com a execuo das atividades.
Modelo Organizacional Modelo de Localidades
Modelo de Processos
Estrutura Organizacional
executa
possui
Localizao Geogrfica
Processo
atende
realizada em possui
Atividade manipula
dispara
Evento Objetivo
desmembrado em
Objeto
Modelo de Objetivos
Modelo de Atividades
Figura 3.2 Submodelos do Modelo de Negcio (adaptado de (KNIGHT, 2004)). H muitas notaes utilizadas para representar os vrios tipos de modelos citados anteriormente, sendo que alguns autores propem o uso de diagramas da UML ou extenses deles para essa finalidade. Em especial, os diagramas de casos de uso e de atividades so bastante utilizados para a representao de modelos de processos de negcio. Diferentes propostas usam diferentes tipos de modelos para derivar requisitos. Um dos usos mais comuns de modelos de processo na Engenharia de Requisitos a derivao de casos de uso a partir da anlise das informaes capturadas nos diagramas que representam os aspectos do negcio, incluindo a identificao das atividades dos processos que sero apoiadas pelo sistema, bem como a identificao dos atores dos casos de uso a partir dos executores (pessoas ou mquinas) relacionados aos processos. Segundo Davenport (2000), dentre os principais benefcios da implantao de sistemas de informao para apoiar processos de negcio esto: (i) a automatizao de tarefas antes realizadas manualmente, (ii) a racionalizao dos dados, (iii) a implementao de melhorias
55
nos processos da organizao, (iv) ajuste das interfaces entre reas, (v) aperfeioamento dos servios aos clientes e (vi) gerao de informaes gerenciais. No decorrer da modelagem de processos, a reunio dos envolvidos no processo permite que seja estabelecida uma viso abrangente de todo o contexto, possibilitando a identificao de divergncias e abrindo espaos para a melhoria, o que pode levar reengenharia dos processos de negcio. Processos correntes (processos AS IS) podem dar origem a novos processos, mais eficazes, a serem implantados na organizao (processos TO BE). O contexto no qual o sistema ser inserido considerado como parte integral na aplicao da abordagem orientada a modelos de processos, permitindo que o sistema seja considerado um agente de mudanas e no apenas a automatizao das prticas correntes, sejam elas boas ou no. A modelagem de processos complementa as prticas convencionais de engenharia de requisitos, auxiliando o cliente a adquirir maturidade acerca da complexidade do seu prprio negcio e revelando o grau de adequao dos requisitos levantados com os processos (e objetivos) da organizao (CARDOSO; ALMEIDA; GUIZZARDI, 2008). importante realar que a modelagem de processos de negcios independe do desenvolvimento de sistemas e pode ser conduzida independentemente para a construo de uma arquitetura organizacional de referncia (enterprise architecture). Quando necessria a construo de um sistema que d apoio a partes dos processos modelados nessa arquitetura, necessrio retornar ao cliente somente para levantar requisitos de sistema e no para levantar requisitos de negcio (CARDOSO; ALMEIDA; GUIZZARDI, 2008).
3.4 Escrevendo e Documentando Requisitos de Usurio

Os resultados do levantamento de requisitos tm de ser registrados em um documento, de modo que possam ser verificados, validados e utilizados como base para outras atividades do processo de software. Para que sejam teis, os requisitos tm de ser escritos em um formato compreensvel por todos os interessados. Alm disso, esses interessados devem interpret-los uniformemente. Normalmente, requisitos so documentados usando alguma combinao de linguagem natural, modelos, tabelas e outros elementos. A linguagem natural quase sempre imprescindvel, uma vez que a forma bsica de comunicao compreensvel por todos os interessados. Contudo, ela geralmente abre espaos para ambiguidades e m interpretao. Assim, interessante procurar estruturar o uso da linguagem natural e complementar a descrio dos requisitos com outros elementos. Conforme discutido no Captulo 2, diferentes abordagens podem ser usadas para documentar requisitos. Neste texto, sugerimos elaborar dois documentos: o documento de definio de requisitos (ou somente documento de requisitos) e o documento de especificao de requisitos. O documento de requisitos mais sucinto, escrito em um nvel mais apropriado para o cliente e contempla apenas os requisitos de usurio. O documento de especificao de requisitos mais detalhado, escrito a partir da perspectiva dos desenvolvedores (PFLEEGER, 2004), normalmente contendo diversos modelos para descrever requisitos de sistema. Os requisitos de usurio devem ser descritos de modo a serem compreensveis pelos interessados no sistema que no possuem conhecimento tcnico detalhado. Eles devem
56
especificar apenas o comportamento externo do sistema, em uma linguagem simples, direta e sem usar terminologia especfica de software (SOMMERVILLE, 2007). O Documento de Definio de Requisitos (ou simplesmente Documento de Requisitos) tem como propsito descrever os requisitos de usurio, tendo como pblico-alvo clientes, usurios, gerentes (de cliente e de fornecedor) e desenvolvedores. H muitos formatos distintos propostos na literatura para documentos de requisitos. Neste texto, proposta uma estrutura bastante simples para esse tipo de documento, contendo apenas quatro sees: 1. Introduo: breve introduo ao documento, descrevendo seu propsito e estrutura. 2. Descrio do Propsito do Sistema: descreve o propsito geral do sistema. 3. Descrio do Minimundo: apresenta, em um texto corrido, uma viso geral do domnio, do problema a ser resolvido e dos processos de negcio apoiados, bem como as principais ideias do cliente sobre o sistema a ser desenvolvido. 4. Requisitos de Usurio: apresenta os requisitos de usurio em linguagem natural. Trs conjuntos de requisitos devem ser descritos nesta seo: requisitos funcionais, requisitos no funcionais e regras de negcio. As trs primeiras sees no tm nenhuma estrutura especial, sendo apresentadas na forma de um texto corrido. A introduo deve ser breve e basicamente descrever o propsito e a estrutura do documento, podendo seguir um padro preestabelecido pela organizao. A descrio do propsito do sistema deve ser direta e objetiva, tipicamente em um nico pargrafo. J a descrio do minimundo um pouco maior, algo entre uma e duas pginas, descrevendo aspectos gerais e relevantes para um primeiro entendimento do domnio, do problema a ser resolvido e dos processos de negcio apoiados. Contm as principais ideias do cliente sobre o sistema a ser desenvolvido, obtidas no levantamento preliminar e exploratrio do sistema. No se devem incluir detalhes. A seo 4, por sua vez, no deve ter um formato livre. Ao contrrio, deve seguir um formato estabelecido pela organizao, contendo, dentre outros: identificador do requisito, descrio, tipo, origem, prioridade, responsvel, interessados, dependncias em relao a outros requisitos e requisitos conflitantes. A definio de padres organizacionais para a definio de requisitos essencial para garantir uniformidade e evitar omisso de informaes importantes acerca dos requisitos (SOMMERVILLE, 2007; WIEGERS, 2003). Como consequncia, o padro pode ser usado como um guia para a verificao de requisitos. A Tabela 3.4 apresenta o padro tabular sugerido neste texto. Sugerem-se agrupar requisitos de um mesmo tipo em diferentes tabelas. Assim, a informao do tipo do requisito no aparece explicitamente no padro proposto. Alm disso, informaes complementares podem ser adicionadas em funo do tipo de requisito. A seguir, discute-se como cada um dos itens da tabela pode ser tratado, segundo uma perspectiva geral. Na sequncia, so tecidas consideraes mais especficas sobre a descrio dos diferentes tipos de requisitos. Tabela 3.4 Tabela de Requisitos.
Identificador Descrio Origem Prioridade Responsvel Interessados Dependncias Conflitos
Os requisitos devem possuir identificadores nicos para permitir a identificao e o rastreamento na gerncia de requisitos. H diversas propostas de esquemas de rotulagem de
57
requisitos. Neste texto, recomenda-se usar um esquema de numerao sequencial por tipo de requisito, sendo usados os seguintes prefixos para designar os diferentes tipos de requisitos: RF requisitos funcionais; RNF requisitos no funcionais; RN regras de negcio. Para outros esquemas de rotulagem, vide (WIEGERS, 2003). importante destacar que, quando um requisito eliminado, seu identificador no pode ser atribudo a outro requisito. A descrio do requisito normalmente feita na forma de uma sentena em linguagem natural. Ainda que expressa em linguagem natural, importante adotar um estilo consistente e usar a terminologia do usurio ao invs do jargo tpico da computao. Em relao ao estilo, recomenda-se utilizar sentenas em um dos seguintes formatos para descrever requisitos funcionais e no funcionais: O sistema deve <verbo indicando ao, seguido de complemento>: use o verbo dever para designar uma funo ou caracterstica requerida para o sistema, ou seja, para descrever um requisito obrigatrio. Exemplos: O sistema deve efetuar o controle dos clientes da empresa. O sistema deve processar um pedido do cliente em um tempo inferior a cinco segundos, contado a partir da entrada de dados. O sistema pode <verbo indicando ao, seguido de complemento>: use o verbo poder para designar uma funo ou caracterstica desejvel para o sistema, ou seja, para descrever um requisito desejvel, mas no essencial. Exemplos: O sistema pode notificar usurios em dbito. O sistema pode sugerir outros produtos para compra, com base em produtos colocados no carrinho de compras do usurio.
Em algumas situaes, pode-se querer explicitar que alguma funcionalidade ou caracterstica no deve ser tratada pelo sistema. Neste caso, indica-se uma sentena com a seguinte estrutura: O sistema no deve <verbo indicando ao, seguido de complemento>. Wiegers (2003) recomenda diversas diretrizes para a redao de requisitos, dentre elas: Escreva frases completas, com a gramtica, ortografia e pontuao correta. Procure manter frases e pargrafos curtos e diretos. Use os termos consistentemente. Defina-os em um glossrio. Prefira a voz ativa (o sistema deve fazer alguma coisa) voz passiva (alguma coisa deve ser feita). Sempre que possvel, identifique o tipo de usurio. Evite descries genricas como o usurio deve [...]. Se o usurio no caso for, por exemplo, o caixa do banco, indique claramente o caixa do banco deve [...]. Evite termos vagos, que conduzam a requisitos ambguos e no testveis, tais como rpido, adequado, fcil de usar etc. Escreva requisitos em um nvel consistente de detalhe. O nvel de especificao de um requisito deve ser tal que, se o requisito satisfeito, a necessidade do cliente atendida. Contudo, evite restringir desnecessariamente o projeto (design). Escreva requisitos individualmente testveis. Um requisito bem escrito deve permitir a definio de um pequeno conjunto de testes para verificar se o requisito foi corretamente implementado.
58
Evite longos pargrafos narrativos que contenham mltiplos requisitos. Divida um requisito desta natureza em vrios menores.
Conforme apontado anteriormente, requisitos devem ser testveis. Robertson e Robertson (2006) sugerem trs maneiras de tornar os requisitos testveis: Especificar uma descrio quantitativa de cada advrbio ou adjetivo, de modo que o significado dos qualificadores fique claro e no ambguo. Trocar os pronomes pelos nomes das entidades. Garantir que todo nome (termo) importante seja definido em um glossrio no documento de requisitos.
A origem de um requisito deve apontar a partir de que entidade (pessoa, documento, atividade) o requisito foi identificado. Um requisito identificado durante uma investigao de documentos, p.ex., tem como origem o(s) documento(s) inspecionado(s). J um requisito levantado em uma entrevista com um certo usurio tem como origem o prprio usurio. A informao de origem importante para se conseguir rastrear requisitos para a sua origem, prtica muito recomendada no contexto da gerncia de requisitos. Requisitos podem ter importncia relativa diferente em relao a outros requisitos. Assim, importante que o cliente e outros interessados estabeleam conjuntamente a prioridade de cada requisito. muito importante saber quem o analista responsvel por um requisito, bem como quem so os interessados (clientes, usurios etc.) naquele requisito. So eles que estaro envolvidos nas discusses relativas ao requisito, incluindo a tentativa de acabar com conflitos e a definio de prioridades. Assim, deve-se registrar o nome e o papel do responsvel e dos interessados em cada requisito. Um requisito pode depender de outros ou conflitar com outros. Quando as dependncias e conflitos forem detectados, devem-se listar os respectivos identificadores nas colunas de dependncias e conflitos.
3.4.1 - Escrevendo Requisitos Funcionais

As diretrizes apresentadas anteriormente aplicam-se integralmente a requisitos funcionais. Assim, no h outras diretrizes especficas para os requisitos funcionais. Deve-se realar apenas que, quando expressos como requisitos de usurio, requisitos funcionais so geralmente descritos de forma abstrata, no cabendo neste momento entrar em detalhes. Detalhes vo ser naturalmente adicionados quando esses mesmos requisitos forem descritos na forma de requisitos de sistema. Uma alternativa largamente empregada para especificar requisitos funcionais no nvel de requisitos de sistema a modelagem. Uma das tcnicas mais comumente utilizadas para descrever requisitos funcionais como requisitos de sistema a modelagem de casos de uso.
3.4.2 - Escrevendo Regras de Negcio

Toda organizao opera de acordo com um extenso conjunto de polticas corporativas, leis, padres industriais e regulamentaes governamentais. Tais princpios de controle so coletivamente designados por regras de negcio. Uma regra de negcio uma declarao que
59
define ou restringe algum aspecto do negcio, com o propsito de estabelecer sua estrutura ou controlar ou influenciar o comportamento do negcio (WIEGERS, 2003). Sistemas de informao tipicamente precisam fazer cumprir as regras de negcio. Ao contrrio dos requisitos funcionais e no funcionais, a maioria das regras de negcio originase fora do contexto de um sistema especfico. Assim, as regras a serem tratadas pelo sistema precisam ser identificadas, documentadas e associadas aos requisitos do sistema em questo (WIEGERS, 2003). Wiegers identifica cinco tipos principais de regras de negcio, cada um deles apresentando uma forma tpica de ser escrito: Fatos ou invariantes: declaraes que so verdade sobre o negcio. Geralmente descrevem associaes ou relacionamentos entre importantes termos do negcio. Ex.: Todo pedido tem uma taxa de remessa. Restries: como o prprio nome indica, restringem as aes que o sistema ou seus usurios podem realizar. Algumas palavras ou frases sugerem a descrio de uma restrio, tais como deve, no deve, no pode e somente. Ex.: Um aluno s pode tomar emprestado, concomitantemente, at trs livros. Ativadores de Aes: so regras que disparam alguma ao sob condies especficas. Uma declarao na forma Se <alguma condio verdadeira ou algum evento ocorre>, ento <algo acontece> indicada para descrever ativadores de aes. Ex.: Se a data para retirada do livro ultrapassada e o livro no retirado, ento a reserva cancelada. Quando as condies que levam s aes so uma complexa combinao de mltiplas condies individuais, ento o uso de tabelas de deciso ou rvores de deciso indicado. As figuras 3.4 e 3.5 ilustram uma mesma regra de ativao de aes descrita por meio de uma rvore de deciso e de uma tabela de deciso, respectivamente.
Sem atraso de pagamento registrado Volume de negcios R$ 1 milho Tempo de trabalho 20 anos Tempo de trabalho < 20 anos
Tratamento Prioritrio Prioritrio
Com atraso de pagamento registrado
Normal Normal
Volume de negcios < R$ 1 milho
Figura 3.4 Exemplo de rvore de Deciso.
60
Tratamento de Clientes Volume de Negcios R$ 1 milho? Atraso de pagamento registrado? Tempo de trabalho 20 anos? Tratamento Prioritrio Tratamento Normal Figura 3.5 Exemplo de Tabela de Deciso. Inferncias: so regras que derivam novos fatos a partir de outros fatos ou clculos. So normalmente escritas no padro se / ento, como as regras ativadoras de ao, mas a clusula ento implica um fato ou nova informao e no uma ao a ser tomada. Ex.: Se o usurio no devolve um livro dentro do prazo estabelecido, ento ele torna-se um usurio inadimplente. Computaes: so regras de negcio que definem clculos a serem realizados usando algoritmos ou frmulas matemticas especficos. Podem ser expressas como frmulas matemticas, descrio textual, tabelas etc. Ex.: Multa = Valor de Locao * Nmero de Dias de Atraso. S N X S S S X X X S S N N -
Ao contrrio de requisitos funcionais e no funcionais, regras de negcio no so passveis de serem capturadas por meio de perguntas simples e diretas, tal como Quais so suas regras de negcio?. Regras de negcio emergem durante a discusso de requisitos, sobretudo quando se procura entender a base lgica por detrs de requisitos e restries apontados pelos interessados (WIEGERS, 2003). Assim, no se deve pensar que ser possvel levantar muitas regras de negcio em um levantamento preliminar de requisitos. Pelo contrrio, as regras de negcio vo surgir principalmente durante o levantamento detalhado dos requisitos. Wiegers (2003) aponta diversas potenciais origens para regras de negcio e sugere tipos de questes que o analista pode fazer para tentar capturar regras advindas dessas origens: Polticas: Por que necessrio fazer isso desse jeito? Regulamentaes: O que o governo requer? Frmulas: Como este valor calculado? Modelos de Dados: Como essas entidades de dados esto relacionadas? Ciclo de Vida de Objetos: O que causa uma mudana no estado desse objeto? Decises de Atores: O que o usurio pode fazer a seguir? Decises de Sistema: Como o sistema sabe o que fazer a seguir? Eventos: O que pode (e no pode) acontecer?
Regras de negcio normalmente tm estreita relao com requisitos funcionais. Uma regra de negcio pode ser tratada no contexto de uma certa funcionalidade. Neste caso, a regra de negcio deve ser listada na coluna de dependncias do requisito funcional (vide Tabela 3.4). H casos em que uma regra de negcio conduz a um requisito funcional para fazer
61
cumprir a regra. Neste caso, a regra de negcio considerada a origem do requisito funcional (WIEGERS, 2003). importante destacar a importncia das regras (restries) obtidas a partir de modelos conceituais estruturais, ditas restries de integridade. Elas complementam as informaes de um modelo deste tipo e capturam restries relativas a relacionamentos entre elementos de um modelo que normalmente no so passveis de serem capturadas pelas notaes grficas utilizadas na elaborao de modelos conceituais estruturais. Tais regras devem ser documentadas junto ao modelo conceitual estrutural do sistema. Seja o exemplo do modelo conceitual estrutural da Figura 3.6. Esse fragmento de modelo indica que: (i) um aluno cursa um curso; (ii) um aluno pode se matricular em nenhuma ou vrias turmas; (iii) um curso possui um conjunto de disciplinas em sua matriz curricular; (iv) uma turma de uma disciplina especfica. Contudo, nada diz sobre restries entre o estabelecimento dessas vrias relaes. Suponha que o negcio indique que a seguinte restrio deve ser considerada: Um aluno s pode ser matricular em turmas de disciplinas que compe a grade curricular do curso que esse aluno cursa. Essa restrio tem de ser escrita para complementar o modelo.
Figura 3.6 Exemplo de Fragmento de Modelo de Dados com Restrio de Integridade. Outro tipo de restrio importante so as regras que impem restries sobre funcionalidades de insero, atualizao ou excluso de dados, devido a relacionamentos existentes entre as entidades. Voltando ao exemplo da Figura 3.7, a excluso de disciplinas no deve ser livre, uma vez que turmas so existencialmente dependentes de disciplinas. Assim, a seguinte regra de integridade referencial de dados deve ser considerada: Ao excluir uma disciplina, devem-se excluir todas as turmas a ela relacionadas. Essas regras so denominadas neste texto como restries de processamento e, uma vez que dizem respeito a funcionalidades, devem ser documentadas junto com a descrio do caso de uso que detalha a respectiva funcionalidade.
3.4.3 - Escrevendo Requisitos No Funcionais

Clientes e usurios naturalmente enfocam a especificao de requisitos funcionais e regras de negcio. Entretanto para um sistema ser bem sucedido, necessrio mais do que entregar a funcionalidade correta. Usurios tambm tm expectativas sobre quo bem o sistema vai funcionar. Caractersticas que entram nessas expectativas incluem: quo fcil usar o sistema, quo rapidamente ele roda, com que frequncia ele falha e como ele trata condies inesperadas. Essas caractersticas, coletivamente conhecidas como atributos de qualidade do produto de software, so parte dos requisitos no funcionais do sistema. Essas
62
expectativas de qualidade do produto tm de ser exploradas durante o levantamento de requisitos (WIEGERS, 2003). Clientes geralmente no apontam suas expectativas de qualidade explicitamente. Contudo, informaes providas por eles durante o levantamento de requisitos fornecem algumas pistas sobre o que eles tm em mente. Assim, necessrio definir o que os usurios pensam quando eles dizem que o sistema deve ser amigvel, rpido, confivel ou robusto (WIEGERS, 2003). H muitos atributos de qualidade que podem ser importantes para um sistema. Uma boa estratgia para levantar requisitos no funcionais de produto consiste em explorar uma lista de potenciais atributos de qualidade que a grande maioria dos sistemas deve apresentar em algum nvel. Por exemplo, o modelo de qualidade externa e interna de produtos de software definido na norma ISO/IEC 9126-1, utilizado como referncia para a avaliao de produtos de software, define seis caractersticas de qualidade, desdobradas em subcaractersticas, a saber (ISO/IEC, 2001): Funcionalidade: refere-se existncia de um conjunto de funes que satisfaz s necessidades explcitas e implcitas e suas propriedades especficas. Tem como subcaractersticas: adequao, acurcia, interoperabilidade, segurana de acesso e conformidade. Confiabilidade: diz respeito capacidade do software manter seu nvel de desempenho, sob condies estabelecidas, por um perodo de tempo. Tem como subcaractersticas: maturidade, tolerncia a falhas, recuperabilidade e conformidade. Usabilidade: refere-se ao esforo necessrio para se utilizar um produto de software, bem como o julgamento individual de tal uso por um conjunto de usurios. Tem como subcaractersticas: inteligibilidade, apreensibilidade, operacionalidade, atratividade e conformidade. Eficincia: diz respeito ao relacionamento entre o nvel de desempenho do software e a quantidade de recursos utilizados sob condies estabelecidas. Tem como subcaractersticas: comportamento em relao ao tempo, comportamento em relao aos recursos e conformidade. Manutenibilidade: concerne ao esforo necessrio para se fazer modificaes no software. Tem como subcaractersticas: analisabilidade, modificabilidade, estabilidade, testabilidade e conformidade. Portabilidade: refere-se capacidade do software ser transferido de um ambiente para outro. Tem como subcaractersticas: adaptabilidade, capacidade para ser instalado, coexistncia, capacidade para substituir e conformidade.
interessante observar que, mesmo dentre as subcaractersticas de funcionalidade, h atributos que geralmente no so pensados pelos usurios como funes que o sistema deve prover, tais como interoperabilidade e segurana de acesso. Assim, importante avaliar em que grau o sistema em questo necessita apresentar tais caractersticas.
63
Outro ponto importante a destacar que diferentes autores listam diferentes caractersticas de qualidade, usando classificaes prprias. Por exemplo, Bass, Clements e Kazman (2003) consideram, dentre outros, os seguintes atributos de qualidade: Disponibilidade: refere-se a falhas do sistema e suas consequncias associadas. Uma falha ocorre quando o sistema no entrega mais um servio consistente com sua especificao. Modificabilidade: diz respeito ao custo de modificao do sistema. Desempenho: refere-se a tempo. Segurana: est relacionada habilidade do sistema impedir o uso no autorizado, enquanto ainda prov seus servios para os usurios legtimos. Testabilidade: refere-se ao quo fcil testar o software. Usabilidade: diz respeito ao quo fcil para o usurio realizar uma tarefa e o tipo de suporte ao usurio que o sistema prov.
Alm das caractersticas de qualidade que se aplicam diretamente ao sistema, ditas caractersticas de qualidade de produto, Bass, Clements e Kazman (2003) listam outras caractersticas relacionadas a metas de negcio, dentre elas: tempo para chegar ao mercado (time to market), custo-benefcio, tempo de vida projetado para o sistema, mercado alvo, cronograma de implementao e integrao com sistemas legados. Wiegers (2003), por sua vez, agrupa atributos de qualidade do produto em duas categorias principais: atributos importantes para os usurios e atributos importantes para os desenvolvedores. Como atributos importantes para os usurios so apontados os seguintes: disponibilidade, eficincia, flexibilidade, integridade, interoperabilidade, confiabilidade, robustez e usabilidade. Como atributos importantes para os desenvolvedores, so enumerados os seguintes: manutenibilidade, portabilidade, reusabilidade e testabilidade. Uma vez que no h um consenso sobre quais atributos de qualidade considerar, cada organizao deve definir as categorias de requisitos no funcionais a serem consideradas em seus projetos de software. Alm disso, essa informao deve ser adicionada tabela de requisitos no funcionais e, portanto, a Tabela 3.4, quando usada para descrever requisitos no funcionais, deve ter uma coluna adicional para indicar a categoria do requisito no funcional. Em um mundo ideal, todo sistema deveria exibir os valores mximos para todos os atributos de qualidade. Contudo, como no mundo real isso no possvel, fundamental definir quais atributos so mais importantes para o sucesso do projeto. Uma abordagem para tratar essa questo consiste em pedir para que diferentes representantes de usurios classifiquem cada atributo em uma escala de 1 (sem importncia) a 5 (muito importante). As respostas ajudam o analista a determinar quais atributos so mais importantes. Obviamente, conflitos podem surgir e precisam ser resolvidos (WIEGERS, 2003). Um aspecto a considerar que diferentes partes do produto podem requerer diferentes combinaes de atributos de qualidade. Assim, importante tambm diferenciar caractersticas que se aplicam ao produto por inteiro daquelas que so necessrias para certas partes do sistema (WIEGERS, 2003). Uma vez priorizados os atributos de qualidade, o analista deve passar, ento, a trabalhar com os usurios no sentido de especificar requisitos mensurveis, e por conseguinte testveis, para cada atributo considerado importante. Se os atributos de qualidade so
64
especificados de maneira no passvel de verificao, no possvel dizer posteriormente se eles foram atingidos ou no. Quando apropriado, devem-se indicar escalas ou unidades de medida para cada atributo e os valores mnimo, alvo e mximo. Se no for possvel quantificar todos os atributos importantes, deve-se, pelo menos, definir suas prioridades. Pode-se, ainda, perguntar aos usurios o que constituiria um valor inaceitvel para cada atributo e definir testes que tentem forar o sistema a demonstrar tais caractersticas (WIEGERS, 2003). Robertson e Robertson (2006) sugerem definir critrios de ajuste (fit criteria) para permitir quantificar requisitos (tanto funcionais como no funcionais) e associ-los descrio dos requisitos. primeira vista, alguns requisitos no funcionais podem parecer serem difceis de quantificar. Entretanto, deve ser possvel atribuir nmeros a eles. Se no se consegue quantificar e medir um requisito, ento provvel que o requisito no seja de fato um requisito. Ele pode ser, por exemplo, vrios requisitos descritos em um s. Seja a seguinte situao. No desenvolvimento de um sistema para uma biblioteca, o usurio coloca o seguinte requisito no funcional: O sistema deve ser amigvel ao usurio. Esse requisito vago, ambguo e no passvel de ser expresso em nmeros. Como quantificar se o sistema amigvel ao usurio? Primeiro, preciso entender o que o usurio quer dizer com amigvel ao usurio. Significa ser fcil de compreender? Fcil de aprender? Fcil de operar? Atrativo? Clareando a inteno do usurio, possvel sugerir uma escala de medio. Suponha que o usurio diga que ser amigvel ao usurio significa que os usurios sero capazes de aprender rapidamente a usar o sistema. Uma vez definido que se est falando sobre facilidade de aprender, possvel definir como escala de medio o tempo gasto para dominar a execuo de certas tarefas. A partir disso, pode-se estabelecer como critrio de aceitao o seguinte: Novos bibliotecrios devem ser capazes de efetuar emprstimos em um intervalo de tempo de at 30 minutos aps a sua primeira tentativa de realizar esta tarefa usando o sistema. Determinar critrios de ajuste (ou critrios de aceitao) ajuda a clarear um requisito. Ao se estabelecer uma escala de medio e os valores aceitveis, o requisito transformado de uma inteno vaga, e at certo ponto ambgua, em um requisito mensurvel e bem formado. Estabelecida uma escala, pode-se perguntar ao usurio o que considerado uma falha em atender ao requisito, de modo a definir o critrio de aceitao. Contudo, pode ser difcil, seno impossvel, obter um requisito completo e mensurvel em primeira instncia (ROBERTSON; ROBERTSON, 2006). Assim, na descrio de requisitos de usurio pode ser suficiente capturar a inteno e depois, na especificao de requisitos de sistema, transformar essa inteno em um requisito mensurvel, adicionando a ele um critrio de ajuste. muito comum que, neste processo, um requisito no funcional de usurio d origem a vrios requisitos no funcionais de sistema. Leitura Complementar Em (KOTONYA; SOMMERVILLE, 1998), o Captulo 3 Requirements Elicitation and Analysis trata do processo de levantamento de requisitos, discutindo tambm, de forma breve, algumas tcnicas de levantamento de requisitos, dentre elas entrevistas, cenrios, observao, reutilizao de requisitos e prototipagem. Em (WIEGERS, 2003) h vrios captulos que abordam temas discutidos nestas notas de aula. Sugere-se, em especial, a leitura dos captulos 5, 6, 7, 9, 10, 12 e 13. O Captulo 5
65
Establishing the Product Vision and Project Scope discute a estrutura de um documento de escopo e viso, que documenta preliminarmente os requisitos, de maneira anloga ao documento de requisitos discutido neste texto. O Captulo 6 Finding the Voice of the Customer discute, dentre outros, fontes de requisitos, classes de usurios e seus representantes. O Captulo 7 Hearing the Voice of the Customer discute a tcnica de workshop de requisitos e a classificao das informaes obtidas de clientes e usurios. O Captulo 9 Playing by the Rules trata de regras de negcio, seus tipos e como documentlas. O Captulo 10 Documenting the Requirements discute a estrutura de um documento de especificao de requisitos, que detalha os requisitos, de maneira anloga ao documento de especificao de requisitos discutido neste texto. Alm disso, este captulo discute como rotular e escrever requisitos. O Captulo 12 Beyound Functionality: Software Quality Attributes discute a parte dos requisitos no funcionais relacionadas a atributos de qualidade de produto de software. Finalmente, o Captulo 13 Risk Reduction Through Prototyping dedicado prototipagem. Em (ROBERTSON; ROBERTSON, 2006) h tambm vrios captulos que abordam temas discutidos nestas notas de aula. Sugere-se, em especial, a leitura dos captulos 5, 7, 8, 9, 10 e 12. O Captulo 5 Trawling the Requirements aborda a coleta de requisitos, discutindo diversas tcnicas de levantamento de requisitos, dentre elas entrevistas, workshops de requisitos, brainstorming e investigao de documentos. O Captulo 7 Functional Requirements aborda a captura e descrio de requisitos funcionais, enquanto o Captulo 8 Nonfunctional Requirements aborda requisitos no funcionais. O Captulo 9 Fit Criteria trata da definio de critrios de ajuste para complementar a descrio de requisitos, tornando-os mensurveis e testveis. O Captulo 10 Writing the Requirements discute a documentao de requisitos, tomando por base o modelo de documento de especificao de requisitos Volere, proposto pelos autores. Finalmente, o Captulo 12 Prototyping the Requirements dedicado prototipagem. O Captulo 2 de (AURUM; WOHLIN, 2005) Requirements Elicitation: A Survey of Techniques, Approaches and Tools, mais especificamente sua seo 2.3 (Techniques and Approaches for Requirements Elicitation) faz um timo apanhado sobre tcnicas de levantamento de requisitos. Vrios dos comentrios feitos neste texto foram baseados nas descries feitas por Zowghi e Coulin, autores dessa seo de (AURUM; WOHLIN, 2005). Uma das principais fontes para as descries feitas neste texto sobre as tcnicas de entrevistas, questionrios, observao e investigao de documentos foi a parte II de (KENDALL; KENDALL, 2010) Information Requirements Analysis, a qual contm trs captulos bastante usados nestas notas de aula, a saber: Captulo 4 Information Gathering: Interactive Methods, que trata, dentre outros, de entrevistas e questionrios; Captulo 5 Information Gathering: Unobtrusive Methods, que aborda investigao de documentos e observao; e Captulo 6 Agile Modeling and Prototyping, que discute prototipagem. Outra fonte importante sobre tcnicas de levantamento de requisitos a parte II de (ALEXANDER; BEUS-DUKIC, 2009) Discovery Contexts. Esta parte contm quatro captulos, sendo trs deles relacionados a aspectos discutidos neste texto, a saber: Captulo 11 Requirements from Individuals, que trata de entrevistas e observao; Captulo 12 Requirements from Groups, que aborda workshops de requisitos; e Captulo 13 Requirements from Things, que discute prototipagem e reutilizao de requisitos. Em (SOMMERVILLE, 2007), o Captulo 6 Requisitos de Software trata de tipos e nveis de requisitos, bem como da documentao de requisitos. No Captulo 7 Processos de
66
Engenharia de Requisitos, a seo 7.2 dedicada ao levantamento e anlise de requisitos. Nesta seo so brevemente discutidas algumas tcnicas de levantamento de requisitos, dentre elas entrevistas, cenrios e etnografia. Em (PFLEEGER, 2004), a seo 4.7, que trata da documentao de requisitos, merece destaque. Em (PRESSMAN, 2006), merecem destaque as sees 7.3 (Incio do Processo de Engenharia de Requisitos) e 7.4 (Levantamento de Requisitos). Por fim, no que se refere modelagem de processos de negcio e sua sinergia com a engenharia de requisitos, em (CARVALHO, 2009) e (CARDOSO, 2007) h timas discusses. Em especial, o Captulo 5 de (CARVALHO, 2009) Apresentao de Algumas Abordagens de Identificao de Requisitos de Sistemas a partir dos Processos de Negcio apresenta diversas abordagens que fazem uso da modelagem de processos de negcio para apoiar o levantamento de requisitos. Uma viso resumida, mas muito boa, do trabalho de Cardoso (2007) apresentada em (CARDOSO; ALMEIDA; GUIZZARDI, 2008). Referncias do Captulo AURUM, A., WOHLIN, C., Engineering and Managing Software Requirements, SpringerVerlag, 2005. BASS, L., CLEMENTS, P., KAZMAN, R., Software Architecture in Practice, Second edition, Addison Wesley, 2003. CARDOSO, E.C.S., Uma Comparao entre Requisitos de Sistema Gerados por Tcnicas de Modelagem de Processos com Requisitos de Sistema Gerados por Tcnicas Convencionais de Engenharia de Requisitos, Projeto de Graduao (Engenharia de Computao), Universidade Federal do Esprito Santo, 2007. CARDOSO, E., ALMEIDA, J.P.A., GUIZZARDI, G., Uma Experincia com Engenharia de Requisitos baseada em Modelos de Processos. In: Proceedings of the XI Iberoamerican Workshop on Requirements Engineering and Software Environments (IDEAS 2008), Recife, 2008. CARVALHO, E.A., Engenharia de Processos de Negcio e a Engenharia de Requisitos: Anlise e Comparaes de Abordagens e Mtodos de Elicitao de Requisitos de Sistemas Orientada por Processos de Negcio, Dissertao de Mestrado, Programa de PsGraduao em Engenharia de Produo, COPPE/UFRJ, Rio de Janeiro, 2009. DAVENPORT, T. H., Mission Critical: realizing the promise of enterprise systems. 1st edition. Boston: Harvard Business School Press, 2000. FRYE, D. W., GULLEDGE, T. R., End-to-end Business Process Scenarios. Industrial, Management & Data Systems, v. 107, n. 6, pp.749761, 2007. ISO/IEC 9126-1, Software Engineering - Product Quality - Part 1: Quality Model, 2001. ISO/IEC TR 9126-2:2003, Software Engineering Product Quality Part 2: External Metrics, 2003a. ISO/IEC TR 9126-3:2003, Software Engineering Product Quality Part 3: Internal Metrics, 2003b. KENDALL, K.E., KENDALL, J.E.; Systems Analysis and Design, Prentice Hall, 8th Edition, 2010.
67
KNIGHT, D. M. Elicitao de Requisitos de Software a partir do Modelo de Negcio. Dissertao (Mestrado em Informtica). Ncleo de Computao Eletrnica (NCE), Universidade Federal do Rio de Janeiro. Rio de Janeiro, 2004 KOTONYA, G., SOMMERVILLE, I., Requirements engineering: processes and techniques. Chichester, England: John Wiley, 1998. PFLEEGER, S.L., Engenharia de Software: Teoria e Prtica, So Paulo: Prentice Hall, 2 edio, 2004. PRESSMAN, R.S., Engenharia de Software, McGraw-Hill, 6 edio, 2006. ROBERTSON, S., ROBERTSON, J. Mastering the Requirements Process. 2nd Edition. Addison Wesley, 2006. SOMMERVILLE, I., Engenharia de Software, 8 Edio. So Paulo: Pearson Addison Wesley, 2007. WAZLAWICK, R.S., Anlise e Projeto de Sistemas de Informao Orientados a Objetos, Elsevier, 2004. WIEGERS, K.E., Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle. 2nd Edition, Microsoft Press, Redmond, Washington, 2003.
Captulo 4 Anlise de Requisitos
68

Requisitos de usurio resultam diretamente da atividade de levantamento de requisitos, sendo tipicamente descritos em linguagem natural, em um nvel relativamente pequeno de detalhes. Assim, uma vez identificados os requisitos de usurio, necessrio detalh-los, colocando-os no nvel de descrio de requisitos de sistema. Este o propsito da anlise de requisitos. Requisitos de sistema resultam dos esforos dos analistas de organizar e detalhar requisitos de usurio, compreendendo um conjunto de modelos abstratos do sistema, agora em um nvel alto de detalhes. A correta derivao de requisitos de sistema a partir de requisitos de usurio fundamental para assegurar que nenhum equvoco arbitrariamente introduzido pelos analistas durante o processo de especificao de requisitos (AURUM; WOHLIN, 2005). Durante a anlise de requisitos, requisitos funcionais e no funcionais devem ser expressos em um nvel de detalhes que permita guiar as etapas subsequentes do desenvolvimento de software (projeto, implementao e testes). Alm disso, ateno especial deve ser dada s regras de negcio. Elas tm de ser capturadas e incorporadas s funcionalidades do sistema. Para descrever requisitos funcionais detalhadamente, na maioria das vezes necessrio produzir um conjunto de modelos, cada um deles capturando uma perspectiva diferente do sistema. A linguagem natural ainda utilizada, mas em uma escala reduzida, circunscrita a descries de certos modelos ou s definies em glossrios ou dicionrios de dados. Grande parte das informaes tratadas na anlise de requisitos funcionais melhor comunicada por meio de diagramas do que por meio de texto. Assim, a modelagem conceitual uma atividade essencial da anlise de requisitos. A modelagem conceitual visa definir em detalhes as funes requeridas pelo sistema e o conhecimento necessrio para realiz-las. O produto principal da modelagem conceitual o esquema conceitual do sistema (OLIV, 2007). O esquema ou modelo conceitual2 de um sistema captura as funes e informaes que o sistema deve prover e gerenciar. Ele deve ser concebido com foco no domnio do problema e no no domnio da soluo, mas deve tratar tanto uma viso externa do sistema (como o sistema percebido pelos usurios) quanto uma viso interna do mesmo (como as abstraes do domnio so representadas e relacionadas). Os termos anlise de sistemas e anlise de requisitos so muitas vezes empregados para designar as atividades de modelagem conceitual (anlise de requisitos funcionais). Assim, a maioria dos mtodos de anlise de sistemas concentra-se na anlise de requisitos funcionais, nada falando sobre a anlise de requisitos no funcionais. Entretanto, durante a
Oliv (2007) utiliza o termo esquema conceitual para designar o conjunto de artefatos que capturam o conhecimento que um sistema de informao necessita para realizar suas funes. Contudo, a maioria dos textos, tais como (WAZLAWICK, 2004) e (BLAHA; RUMBAUGH, 2006), utiliza o termo modelo conceitual para designar esse conjunto de artefatos. Oliv utiliza o termo modelo conceitual para designar tipos de modelos, tais como modelos de objetos, modelos de casos de uso etc. Nestas notas de aula, o termo modelo conceitual usado como na maioria dos textos, no sendo feita uma distino precisa entre as duas acepes do termo. De maneira geral, o contexto indica ao que se refere o termo.
69
atividade de anlise de requisitos, tanto requisitos funcionais quanto requisitos no funcionais devem ser especificados em detalhes. O produto de trabalho principal da anlise de requisitos o Documento de Especificao de Requisitos. Esse documento deve conter os requisitos funcionais e no funcionais descritos em nvel de requisitos de sistema. Conforme citado anteriormente, os requisitos funcionais de sistema so descritos por um conjunto de modelos interrelacionados. Os requisitos no funcionais de sistema detalham os requisitos no funcionais de usurio, adicionando a eles critrios de aceitao. importante apontar que h uma forte dependncia entre os mtodos e tcnicas usados na modelagem conceitual e o paradigma de desenvolvimento adotado. Isso ocorre porque um modelo uma representao do sistema segundo um particular metamodelo. Esse metamodelo corresponde ao conjunto de elementos de modelagem (estruturais e comportamentais) e regras de uso desses elementos, o qual permite construir modelos segundo o respectivo paradigma (AURUM; WOHLIN, 2005). Assim, para a modelagem conceitual de requisitos funcionais necessrio escolher um paradigma de desenvolvimento (e o correspondente metamodelo subjacente a ele) a partir do qual os modelos sero construdos. O paradigma orientado a objetos, por exemplo, fornece um conjunto de elementos de modelagem que permite modelar um sistema como sendo composto de objetos organizados em classes que se comunicam entre si por meio de troca de mensagens. Uma classe define as propriedades (atributos, relacionamentos e operaes) que todos os objetos dela podem possuir. Assim, classes, objetos, associaes, atributos e operaes, dentre outros, so elementos do metamodelo subjacente ao paradigma orientado a objetos. Neste texto, o paradigma adotado o da orientao a objetos. Uma vez que a modelagem conceitual uma tarefa essencial e complexa, til seguir um mtodo. Um mtodo pode ser visto como uma maneira sistemtica de trabalhar para se obter um resultado desejado (PASTOR; MOLINA, 2007). H diversos mtodos de anlise orientada a objetos propostos na literatura, dentre eles os apresentados em (LARMAN, 2007), (WAZLAWICK, 2004)3, (BLAHA; RUMBAUGH, 2006) e (PASTOR; MOLINA, 2007). Vale ressaltar que no h um mtodo reconhecido como um mtodo padro para o desenvolvimento de software orientado a objetos. Diferentes projetos podem requerer diferentes processos e, portanto, no h como definir um mtodo adequado a quaisquer situaes. Neste captulo apresentado um mtodo que incorpora ideias de vrios mtodos, o qual tem se mostrado eficaz na prtica, sobretudo, no desenvolvimento de sistemas de informao. Este captulo trata da anlise de requisitos, discutindo a anlise de requisitos funcionais (modelagem conceitual) e no funcionais. A seo 4.1 discute a modelagem conceitual com foco em sistemas de informao e os tipos de modelos comumente utilizados no desenvolvimento de software orientado a objetos. A seo 4.2 apresenta a Linguagem de Modelagem Unificada (Unified Modeling Language UML), amplamente usada na modelagem conceitual. A seo 4.3 discute os principais conceitos da orientao a objetos, paradigma de desenvolvimento adotado neste texto. A seo 4.4 apresenta o mtodo de anlise de requisitos funcionais sugerido, indicando suas atividades e modelos a serem produzidos. A seo 4.5 trata da especificao de requisitos no funcionais. Finalmente, a seo 4.6 discute a documentao de requisitos em nvel de sistema.
O mtodo apresentado em (WAZLAWICK, 2004) , segundo o prprio autor, uma interpretao e um detalhamento do mtodo de anlise e projeto apresentado por Larman.
3
70
4.1 Modelagem Conceitual

Todo sistema incorpora um esquema conceitual. Assim, para que o desenvolvimento de um sistema seja bem sucedido, necessrio explicitar esse esquema. Esse o propsito da modelagem conceitual (OLIV, 2007). O esquema conceitual de um sistema de informao a especificao de seus requisitos funcionais. Um sistema de informao um sistema projetado para coletar, armazenar, processar e distribuir informao sobre o estado de um domnio. Assim, um sistema dessa natureza tem tipicamente trs propsitos ou funes principais (OLIV, 2007): Funo de Memria: sob esta tica, o objetivo de um sistema de informao manter uma representao interna do estado do domnio. O estado do domnio geralmente alterado com frequncia e de muitas maneiras. O sistema precisa acompanhar essas alteraes e atualizar sua representao interna adequadamente. Funo Informativa: o sistema deve prover aos usurios informaes sobre o estado do domnio. A funo informativa no altera o estado do domnio; ela apenas prov a informao solicitada pelos usurios. Funo Ativa: o sistema pode realizar aes que modificam o estado do domnio. Para realizar essa funo, o sistema precisa conhecer as aes que ele pode tomar, quando elas devem ser tomadas e como elas vo afetar o estado do domnio.
Todos os sistemas de informao convencionais realizam, pelo menos, as funes de memria e informativa. Para ser capaz de realizar suas funes, um sistema tem de ter um conhecimento geral sobre o domnio da aplicao e sobre as funcionalidades que ele deve executar. Na rea de sistemas de informao, esse conhecimento denominado de esquema conceitual (OLIV, 2007). O modelo conceitual de um sistema tipicamente composto de vrios modelos, cada um deles enfocando uma perspectiva diferente, mas guardando alguma relao com outros modelos. Os diferentes tipos de modelos conceituais podem ser agrupados em duas grandes categorias: Modelos Estruturais: procuram capturar os principais conceitos do domnio, suas relaes e propriedades, que so relevantes para o sistema que se est desenvolvendo. Abstrao um mecanismo chave e a definio do que relevante definido com base no propsito do sistema. Dentre os tipos de modelos estruturais, destacam-se o Modelo de Entidades e Relacionamentos e o Modelo de Objetos (Diagrama de Classes) na Orientao a Objetos. Modelos Comportamentais: especificam as mudanas vlidas no estado do domnio, bem como as aes que o sistema pode realizar (OLIV, 2007). Tipos de modelos comportamentais bastante utilizados no desenvolvimento orientado a objetos incluem Modelos de Casos de Uso e Modelos Dinmicos, tais como Diagramas de Transio de Estados e Diagramas de Interao.
71
4.2 A Linguagem de Modelagem Unificada

A Linguagem de Modelagem Unificada (Unified Modeling Language UML) uma linguagem grfica padro para especificar, visualizar, documentar e construir artefatos de sistemas de software (BOOCH; RUMBAUGH; JACOBSON, 2006). A UML foi criada na dcada de 1990, a partir de uma tentativa de se unificar dois dos principais mtodos orientados a objetos utilizados at ento: a Tcnica de Modelagem de Objetos (Object Modeling Technique OMT) (RUMBAUGH et al., 1994) e o Mtodo de Booch (BOOCH, 1994). Inicialmente, buscava-se criar um mtodo unificado. A este esforo juntou-se tambm Ivar Jacobson, fundindo tambm seu mtodo OOSE (JACOBSON, 1992). Contudo, percebeu-se que no era possvel estabelecer um nico mtodo adequado para todo e qualquer desenvolvimento. De fato, um mtodo composto por uma linguagem estabelecendo a notao a ser usada na elaborao dos artefatos a serem produzidos e de um processo descrevendo que artefatos construir e como constru-los. A linguagem pode ser unificada, mas a deciso de quais artefatos produzir e que passos seguir no passvel de padronizao, j que pode variar at mesmo de projeto para projeto. Assim, ao invs de criarem um mtodo unificado, Rumbaugh, Booch e Jacobson propuseram a UML, incorporando as principais notaes para os produtos de seus mtodos e de vrios outros, com a colaborao de vrias empresas e autores. A UML foi aprovada em novembro de 1997 pelo OMG Object Management Group pondo fim a uma guerra de mtodos orientados a objeto. Sua verso mais recente, a UML 2.0, foi adotada no incio de 2005 e resultado de um esforo de diversos colaboradores, envolvendo empresas e pesquisadores sob a coordenao de uma fora tarefa do OMG. Vale realar que a UML somente uma linguagem e, portanto, apenas parte de um mtodo de desenvolvimento de software. Ela independente do processo de software a ser usado, ainda que seja mais adequada a processos de desenvolvimento orientados a objetos. Ela se destina a visualizar, especificar, construir e documentar artefatos de software (BOOCH; RUMBAUGH; JACOBSON, 2006). No contexto da Engenharia de Requisitos, a UML prov diversos diagramas que podem ser usados na modelagem de requisitos, tanto segundo a perspectiva estrutural quanto segundo a perspectiva comportamental. Para a modelagem conceitual estrutural, os diagramas de classes so amplamente utilizados. Para a modelagem comportamental, podem ser usados diagramas de casos de uso, de interao, de estados e de atividades. A seguir, apresentada uma descrio sucinta de cada um desses diagramas, baseada em (BOOCH; RUMBAUGH; JACOBSON, 2006): Diagramas de Classes: Um diagrama de classes exibe um conjunto de classes e seus relacionamentos. Diagramas de classes proveem uma viso esttica da estrutura de um sistema e, portanto, so usados na modelagem conceitual estrutural. Diagramas de Casos de Uso: Um diagrama de casos de uso mostra um conjunto de casos de uso e atores e seus relacionamentos. Os casos de uso descrevem a funcionalidade do sistema percebida pelos atores externos. Um ator interage com o sistema, podendo ser um usurio humano, dispositivo de hardware ou outro sistema. Diagramas de casos de uso proveem uma viso das funcionalidades do sistema, sendo importantes para a organiz-las e model-las. Diagramas de Grfico de Estados (ou simplesmente Diagramas de Estados): mostram os estados pelos quais um objeto pode passar ao longo de sua vida, em
72
resposta a estmulos recebidos, juntamente com suas aes. Os diagramas de estados proveem uma viso dinmica de um objeto, sendo importantes para modelar o comportamento dos objetos de uma classe em resposta ocorrncia de eventos. Diagramas de Atividades: mostram a estrutura de um processo. Proveem uma viso dinmica do sistema (ou de uma poro do sistema) e podem ser usados tanto para modelar processos de negcio quanto para modelar funes do sistema. Um diagrama de atividades d nfase ao fluxo de controle entre objetos. Diagramas de Interao: Um diagrama de interao mostra um conjunto de objetos ou papis interagindo, incluindo as mensagens que podem ser trocadas entre eles. Diagramas de interao proveem uma viso dinmica do comportamento de um sistema ou de uma poro do sistema. H dois tipos de diagramas de interao: o Diagramas de Sequncia: so um tipo de diagrama de interao cuja nfase est na ordenao temporal das mensagens. o Diagramas de Comunicao: tm o mesmo propsito dos diagramas de sequncia, apresentando, contudo, nfase diferente. A nfase dos diagramas de comunicao est na organizao estrutural dos objetos que enviam ou recebem mensagens. No contexto da Engenharia de Requisitos, alm dos diagramas anteriormente citados, merecem ateno tambm os diagramas de pacotes. Na UML, pacote um mecanismo de propsito geral usado para organizar elementos de modelagem em grupos. Assim, um diagrama de pacotes mostra a decomposio de um modelo em unidades menores e suas dependncias (BOOCH; RUMBAUGH; JACOBSON, 2006). Vale ressaltar mais uma vez, que a UML uma linguagem de modelagem, no um mtodo de desenvolvimento OO. Os mtodos consistem, pelo menos em princpio, de uma linguagem de modelagem e um procedimento de uso dessa linguagem. A UML no prescreve explicitamente esse procedimento de utilizao. Assim, a UML deve ser aplicada no contexto de um processo, lembrando que domnios de problemas e projetos diferentes podem requerer processos diferentes.
4.3 O Paradigma Orientado a Objetos

Para conduzir o processo de engenharia de requisitos, sobretudo a modelagem conceitual estrutural, necessrio adotar um paradigma de desenvolvimento. Um dos paradigmas mais adotados atualmente a orientao a objetos (OO). Segundo esse paradigma, o mundo visto como sendo composto por objetos, onde um objeto uma entidade que combina estrutura de dados e comportamento funcional. No paradigma OO, os sistemas so modelados como um nmero de objetos que interagem. A orientao a objetos oferece um nmero de conceitos bastante apropriados para a modelagem de sistemas. Os modelos baseados em objetos so teis para a compreenso de problemas, para a comunicao com os especialistas e usurios das aplicaes, e para a realizao das tarefas ao longo do processo de desenvolvimento de software. O paradigma OO utiliza uma perspectiva humana de observao da realidade, incluindo objetos, classificao e compreenso hierrquica.
73
Para fazer bom uso do paradigma OO, importante conhecer os princpios adotados por ele na administrao da complexidade, bem como seus principais conceitos. 4.3.1 Princpios para Administrao da Complexidade O mundo real algo extremamente complexo. Quanto mais de perto o observamos, mais claramente percebemos sua complexidade. A orientao a objetos tenta gerenciar a complexidade inerente dos problemas do mundo real, abstraindo conhecimento relevante e encapsulando-o dentro de objetos. De fato, alguns princpios bsicos gerais para a administrao da complexidade norteiam o paradigma orientado a objetos, entre eles abstrao, encapsulamento e modularidade. Abstrao Uma das principais formas do ser humano lidar com a complexidade atravs do uso de abstraes. As pessoas tipicamente tentam compreender o mundo, construindo modelos mentais de partes dele. Tais modelos so uma viso simplificada de algo, onde apenas os elementos relevantes so considerados. Modelos, portanto, so mais simples do que os complexos sistemas que eles modelam. Seja o exemplo de um mapa representando um modelo de um territrio. Um mapa til porque abstrai apenas as caractersticas do territrio que se deseja modelar. Se um mapa inclusse todos os detalhes do territrio, provavelmente teria o mesmo tamanho do territrio e, portanto, no serviria a seu propsito. Da mesma forma que um mapa precisa ser significativamente menor que o territrio que ele mapeia, incluindo apenas as informaes selecionadas, um modelo deve abstrair apenas as caractersticas relevantes de um sistema para seu entendimento. Assim, pode-se definir abstrao como sendo o princpio de ignorar aspectos no relevantes de um assunto, segundo a perspectiva de um observador, tornando possvel uma concentrao maior nos aspectos principais do mesmo. De fato, a abstrao consiste na seleo que um observador faz de alguns aspectos de um assunto, em detrimento de outros que no demonstram ser relevantes para o propsito em questo. A Figura 2.4 ilustra o conceito de abstrao.
Mapa Rodovirio
So Paulo
Mapa de Temperaturas
Figura 2.4 Ilustrao do Conceito de Abstrao.
74
Encapsulamento No mundo real, um objeto pode interagir com outro sem conhecer seu funcionamento interno. Uma pessoa, por exemplo, utiliza um forno de microondas sem saber efetivamente qual a sua estrutura interna ou como seus mecanismos internos so ativados. Para utiliz-lo, basta saber usar seu painel de controle (a interface do aparelho) para realizar as operaes de ligar/desligar, informar o tempo de cozimento etc. Como essas operaes produzem os resultados, no interessa ao cozinheiro. A Figura 2.5 ilustra o conceito de encapsulamento.
Estrutura Interna
Interface
Figura 2.5 Ilustrao do Conceito de Encapsulamento. O encapsulamento consiste na separao dos aspectos externos de um objeto, acessveis por outros objetos, de seus detalhes internos de implementao, que ficam ocultos dos demais objetos (BLAHA; RUMBAUGH, 2006). A interface de um objeto deve ser definida de forma a revelar o menos possvel sobre o seu funcionamento interno. Abstrao e encapsulamento so conceitos complementares: enquanto a abstrao enfoca o comportamento observvel de um objeto, o encapsulamento oculta a implementao que origina esse comportamento. Encapsulamento frequentemente conseguido atravs da ocultao de informao, isto , escondendo detalhes que no contribuem para suas caractersticas essenciais. Tipicamente, em um sistema orientado a objetos, a estrutura de um objeto e a implementao de seus mtodos so encapsuladas (BOOCH, 1994). Assim, o encapsulamento serve para separar a interface contratual de uma abstrao e sua implementao. Os usurios tm conhecimento apenas das operaes que podem ser requisitadas e precisam estar cientes apenas do qu as operaes realizam e no como elas esto implementadas. A principal motivao para o encapsulamento garantir estabilidade aos sistemas. Um encapsulamento bem feito pode servir de base para a localizao de decises de projeto que necessitam ser alteradas. Uma operao pode ter sido implementada de maneira ineficiente e, portanto, pode ser necessrio escolher um novo algoritmo. Se a operao est encapsulada, apenas o objeto que a define precisa ser modificado, garantindo estabilidade ao sistema. Modularidade Os mtodos de desenvolvimento de software buscam obter sistemas modulares, isto , construdos a partir de elementos que sejam autnomos e conectados por uma estrutura simples e coerente. Modularidade visa obteno de sistemas decompostos em um conjunto
75
de mdulos coesos e fracamente acoplados e crucial para se obter sistemas fceis de manter e estender. Abstrao, encapsulamento e modularidade so princpios sinergticos, isto , ao se trabalhar bem com um deles, est-se aperfeioando os outros tambm. 4.3.2 Principais Conceitos da Orientao a Objetos De maneira simples, o paradigma OO traz uma viso de mundo em que os fenmenos e domnios so vistos como colees de objetos interagindo entre si. Essa forma simples de se colocar a viso do paradigma OO esconde conceitos importantes da orientao a objetos que so a base para o desenvolvimento OO, tais como classes, associaes, generalizao etc. A seguir os principais conceitos da orientao a objetos so discutidos. Objetos O mundo real povoado por entidades que interagem entre si, onde cada uma delas desempenha um papel especfico. Na orientao a objetos, essas entidades so ditas objetos. Objetos podem ser coisas concretas ou abstratas, tais como um carro, uma reserva de passagem area, uma organizao etc. Do ponto de vista da modelagem de sistemas, um objeto uma entidade que incorpora uma abstrao relevante no contexto de uma aplicao. Um objeto possui um estado (informao), exibe um comportamento bem definido (dado por um nmero de operaes para examinar ou alterar seu estado) e tem identidade nica. O estado de um objeto compreende o conjunto de suas propriedades, associadas a seus valores correntes. Propriedades de objetos so geralmente referenciadas como atributos e associaes. Portanto, o estado de um objeto diz respeito aos seus atributos/associaes e aos valores a eles associados. Operaes so usadas para recuperar ou manipular a informao de estado de um objeto e se referem apenas s estruturas de dados do prprio objeto, no devendo acessar diretamente estruturas de outros objetos. Caso a informao necessria para a realizao de uma operao no esteja disponvel, o objeto ter de colaborar com outros objetos. A comunicao entre objetos d-se por meio de troca de mensagens. Para requisitar uma operao de um objeto, necessrio enviar uma mensagem para ele. Uma mensagem composta do nome da operao sendo requisitada e dos argumentos requeridos. Assim, o comportamento de um objeto representa como esse objeto reage s mensagens a ele enviadas. Em outras palavras, o conjunto de mensagens a que um objeto pode responder representa o seu comportamento. Um objeto , pois, uma entidade que tem seu estado representado por um conjunto de atributos e associaes (uma estrutura de informao) e seu comportamento representado por um conjunto de operaes. Cada objeto tem uma identidade prpria que lhe inerente. Todos os objetos tm existncia prpria, ou seja, dois objetos so distintos, mesmo se seus estados e comportamentos forem iguais. A identidade de um objeto transcende os valores correntes de suas propriedades. Classes No mundo real, diferentes objetos desempenham um mesmo papel. Seja o caso de duas cadeiras iguais. Apesar de serem objetos diferentes, elas compartilham uma mesma estrutura e um mesmo comportamento. Entretanto, no h necessidade de se despender tempo
76
modelando cada cadeira. Basta definir, em um nico lugar, um modelo descrevendo a estrutura e o comportamento desses objetos. A esse modelo d-se o nome de classe. Uma classe descreve um conjunto de objetos com a mesma estrutura (atributos e associaes), o mesmo comportamento (operaes) e a mesma semntica. Objetos que se comportam da maneira especificada pela classe so ditos instncias dessa classe. Todo objeto pertence a uma classe, ou seja, instncia de uma classe. De fato, a orientao a objetos norteia o processo de desenvolvimento atravs da classificao de objetos, isto , objetos so agrupados em classes, em funo de exibirem caractersticas similares, sem, no entanto, perda de sua individualidade, como ilustra a Figura 2.6. Assim, a modelagem orientada a objetos consiste, basicamente, na definio de classes. O comportamento e a estrutura de informao de uma instncia so definidos pela sua classe. Objetos com propriedades e comportamento idnticos so descritos como instncias de uma mesma classe, de modo que a descrio de suas propriedades possa ser feita uma nica vez, de forma concisa, independentemente do nmero de objetos que tenham tais propriedades em comum. Deste modo, uma classe captura as caractersticas comuns a todas as suas instncias. Enquanto um objeto individual uma entidade real, que executa algum papel no sistema como um todo, uma classe captura a estrutura e o comportamento comuns a todos os objetos que ela descreve. Assim, uma classe serve como uma espcie de contrato que deve ser estabelecido entre uma abstrao e todos os seus clientes.
Figura 2.6 Ilustrao do conceito de Classificao (BOOCH, 1994). Ligaes e Associaes Em qualquer sistema, objetos relacionam-se uns com os outros. Por exemplo, em o empregado Joo trabalha no Departamento de Pessoal, temos um relacionamento entre o objeto empregado Joo e o objeto Departamento de Pessoal. Ligaes e associaes so meios de se representar relacionamentos entre objetos e entre classes, respectivamente. Uma ligao uma conexo entre objetos. No exemplo anterior, h uma ligao entre os objetos Joo e Departamento de Pessoal. Uma associao, por sua vez, descreve um conjunto de ligaes com estrutura e semntica comuns. No exemplo anterior, h uma associao entre as classes Empregado e Departamento. Todas as
77
ligaes de uma associao interligam objetos das mesmas classes e, assim, uma associao descreve um conjunto de potenciais ligaes da mesma maneira que uma classe descreve um conjunto de potenciais objetos (BLAHA; RUMBAUGH, 2006). Uma associao comum entre duas classes representa um relacionamento estrutural entre pares, significando que essas duas classes esto em um mesmo nvel, sem que uma seja mais importante do que a outra. Alm das associaes comuns, a UML considera dois tipos de associaes especiais entre objetos: composio e agregao. Ambos representam relaes todo-parte. A agregao uma forma especial de associao que especifica um relacionamento entre um objeto agregado (o todo) e seus componentes (as partes). A composio, por sua vez, uma forma de agregao na qual o tempo de vida do todo e das partes coincidente. As partes podem at ser criadas aps a criao do todo, mas uma vez criadas, vivem e morrem com o todo. Uma parte pode ainda ser removida explicitamente antes da morte do todo (BOOCH; RUMBAUGH; JACOBSON, 2006). Generalizao / Especializao Muitas vezes, um conceito geral pode ser especializado, adicionando-se a ele novas caractersticas. Seja o exemplo do conceito de estudante no contexto de uma universidade. De modo geral, h caractersticas que so intrnsecas a quaisquer estudantes da universidade. Entretanto, possvel especializar esse conceito para mostrar especificidades de subtipos de estudantes, tais como estudantes de graduao e estudantes de ps-graduao. De maneira inversa, pode-se extrair de um conjunto de conceitos caractersticas comuns que, quando generalizadas, formam um conceito geral. Por exemplo, ao se avaliar os conceitos de carros, motos, caminhes e nibus, pode-se notar que eles tm caractersticas comuns que podem ser generalizadas em um supertipo veculo automotor terrestre. As abstraes de especializao e generalizao so muito teis para a estruturao de sistemas. Com elas, possvel construir hierarquias de classes. A herana um mecanismo para modelar similaridades entre classes, representando as abstraes de generalizao e especializao. Atravs da herana, possvel tornar explcitas propriedades e operaes comuns em uma hierarquia de classes. O mecanismo de herana possibilita reutilizao, captura explcita de caractersticas comuns e definio incremental de classes. No que se refere definio incremental de classes, a herana permite conceber uma nova classe como um refinamento de outras classes. A nova classe pode herdar as similaridades e definir apenas as novas caractersticas. A herana , portanto, um relacionamento entre classes (em contraposio s associaes que representam relacionamentos entre objetos das classes), no qual uma classe compartilha a estrutura e o comportamento definidos em outras (uma ou mais) classes. A classe que herda caractersticas4 dita subclasse e a que fornece as caractersticas, superclasse. Desta forma, a herana representa uma hierarquia de abstraes na qual uma subclasse herda de uma ou mais superclasses. Tipicamente, uma subclasse aumenta ou redefine caractersticas de suas superclasses. Assim, se uma classe B herda de uma classe A, todas as caractersticas descritas em A tornamse automaticamente parte de B, que ainda livre para acrescentar novas caractersticas para seus propsitos especficos.
4
O termo caracterstica usado aqui para designar estrutura (atributos e associaes) e comportamento (operaes).
78
A generalizao permite abstrair, a partir de um conjunto de classes, uma classe mais geral contendo todas as caractersticas comuns. A especializao a operao inversa e, portanto, permite especializar uma classe em um nmero de subclasses, explicitando as diferenas entre as novas subclasses. Deste modo possvel compor a hierarquia de classes. Esses tipos de relacionamento so conhecidos tambm como relacionamentos um tipo de, onde um objeto da subclasse tambm um tipo de objeto da superclasse. Neste caso, uma instncia da subclasse dita uma instncia indireta da superclasse. Quando uma subclasse herda caractersticas de uma nica superclasse, tem-se herana simples. Quando uma classe definida a partir de duas ou mais superclasses, tem-se herana mltipla. importante observar, no entanto, que na herana mltipla podem ocorrer dois problemas: coliso de nomes herdados a partir de diferentes superclasses e a possibilidade de herana repetida. A Figura 2.7 ilustra esses dois casos. Classe A x Classe A Classe B y x w y x Classe C Classe B w z Classe C r (a) Classe D r (b)
Figura 2.7 - (a) Coliso de nomes. (b) Herana repetida. No primeiro caso, a classe C herda das classes A e B. Entretanto ambas possuem uma caracterstica com nome x. Assim, como ser a caracterstica x em C? Igual definida na classe A ou igual da classe B? No segundo caso, a classe D herda das classes B e C, que, por sua vez, herdam da classe A. Assim, temos um caso de herana repetida, j que, indiretamente, a classe D herda duas vezes da classe A. Mensagens e Mtodos A abstrao incorporada por um objeto caracterizada por um conjunto de operaes que podem ser requisitadas por outros objetos, ditos clientes. Mtodos so implementaes reais de operaes. Para que um objeto realize alguma tarefa, necessrio enviar uma mensagem a ele, solicitando a execuo de um mtodo especfico. Um cliente s pode acessar um objeto atravs da emisso de mensagens, isto , ele no pode acessar ou manipular diretamente os dados associados ao objeto. Os objetos podem ser complexos e o cliente no precisa tomar conhecimento de sua complexidade interna. O cliente precisa saber apenas como se comunicar com o objeto e como ele reage. Assim, garante-se o encapsulamento. As mensagens so o meio de comunicao entre objetos e so responsveis pela ativao de todo e qualquer processamento. Dessa forma, possvel garantir que clientes no sero afetados por alteraes nas implementaes de um objeto que no alterem o comportamento esperado de seus servios.
79
Classes e Operaes Abstratas Nem todas as classes so projetadas para instanciar objetos. Algumas so usadas simplesmente para organizar caractersticas comuns a diversas classes. Tais classes so ditas classes abstratas. Uma classe abstrata desenvolvida basicamente para ser herdada por outras classes. Ela existe meramente para que um comportamento comum a um conjunto de classes possa ser colocado em uma localizao comum e definido uma nica vez. Assim, uma classe abstrata no possui instncias diretas, mas suas classes descendentes concretas, sim. Uma classe concreta uma classe passvel de instanciao, isto , que pode ter instncias diretas. Uma classe abstrata pode ter subclasses tambm abstratas, mas as classes-folhas na rvore de herana devem ser classes concretas. Classes abstratas podem ser projetadas de duas maneiras distintas. Primeiro, elas podem prover implementaes completamente funcionais do comportamento que pretendem capturar. Alternativamente, elas podem prover apenas a definio de um protocolo para uma operao, sem apresentar um mtodo correspondente. Tal operao dita uma operao genrica ou abstrata. Neste caso, a classe abstrata no completamente implementada e todas as suas subclasses concretas so obrigadas a prover uma implementao para suas operaes abstratas. Assim, diz-se que uma operao abstrata define apenas a assinatura5 a ser usada nas implementaes que as subclasses devero prover, garantindo, assim, uma interface consistente. Mtodos que implementam uma operao genrica tm a mesma semntica. Uma classe concreta no pode conter operaes abstratas, porque seno seus objetos teriam operaes indefinidas. Assim, toda classe que possuir uma operao genrica no pode ter instncias diretas e, portanto, obrigatoriamente uma classe abstrata.
4.4 Um Mtodo de Anlise de Requisitos Funcionais

Uma vez que tipicamente diversos modelos do sistema so produzidos, surgem algumas importantes questes: Que modelos produzir? Em que sequncia? Quais as relaes existentes entre esses modelos? Essas questes podem ser parcialmente respondidas pela adoo de um mtodo de anlise. Um mtodo composto por uma linguagem estabelecendo a notao a ser usada na elaborao dos artefatos a serem produzidos e de um processo descrevendo que artefatos construir e como constru-los. O mtodo sugerido neste texto adota a Linguagem de Modelagem Unificada (Unified Modeling Language UML) (BOOCH; RUMBAUGH; JACOBSON, 2006) como linguagem de modelagem e prescreve o processo ilustrado na Figura 4.1. Nessa figura, as atividades de modelagem propriamente ditas esto destacadas em amarelo. As demais atividades correspondem a atividades de documentao e verificao e validao do Documento de Especificao de Requisitos.
nome da operao, parmetros e retorno
80
Figura 4.1 O Mtodo de Anlise de Requisitos Funcionais Proposto. O primeiro modelo do sistema a ser construdo segundo a abordagem proposta o modelo de casos de uso. Sua escolha como primeiro modelo a ser elaborado deve-se ao fato do modelo de casos de uso ser passvel de compreenso tanto por desenvolvedores analistas, projetistas, programadores e testadores como pela comunidade usuria clientes, usurios e demais interessados. O modelo de casos de uso um modelo comportamental, mostrando as funes do sistema, mas de maneira esttica. Ele composto de dois tipos principais de artefatos: os diagramas de casos de uso e as descries de casos de uso. Um diagrama de casos de uso um diagrama bastante simples, que descreve o sistema, seu ambiente e como sistema e ambiente esto relacionados. Assim, ele descreve o sistema segundo uma perspectiva externa. As descries dos casos de uso descrevem o passo a passo para a realizao dos casos de uso e so essencialmente textuais. A modelagem de casos de uso estudada em detalhes no Captulo 5. Tomando por base casos de uso e suas descries, possvel passar modelagem conceitual estrutural, quando os conceitos e relacionamentos envolvidos no domnio so capturados em um conjunto de diagramas de classes. Neste momento importante definir, tambm, o significado dos conceitos e de suas propriedades, bem como restries sobre eles. Essas definies so documentadas em um dicionrio de dados do projeto. A modelagem conceitual estrutural o foco do Captulo 6. Algumas classes do modelo estrutural apresentam um comportamento dependente de seu estado. Para essas classes, til elaborar diagramas de estados, mostrando os estados pelos quais um objeto da classe pode passar ao longo de sua existncia e os eventos que provocam transies de um estado para outro. Alm disso, uma vez que os casos de uso foram representados apenas de maneira esttica, pode ser til tambm mostrar a dinmica de um
81
caso de uso, representando como objetos do diagrama de classes interagem para realizar um caso de uso. Os diagramas de interao so elaborados com este propsito. Finalmente, pode ser til representar os passos de um caso de uso na forma de um diagrama, mostrando objetos gerados e os atores envolvidos em cada passo. Para tal, diagramas de atividades podem ser elaborados. A elaborao de diagramas de estados, de interao e de atividades o foco da atividade de modelagem comportamental dinmica, a qual discutida com maiores detalhes no Captulo 7. Deve-se frisar que, apesar da Figura 4.1 sugerir que os passos do mtodo so sequenciais, na prtica, isso no ocorre. Paralelamente modelagem de casos de uso, pode-se iniciar a modelagem conceitual estrutural. Os diagramas de atividade podem tambm ser elaborados em conjunto com a definio dos casos de uso, de maneira a complementar a descrio de casos de uso especficos. Diagramas de estado e de interao requerem a definio preliminar de casos de uso e classes. Contudo, podem ter sido definidos apenas alguns casos de uso e classes (e no todos eles) para j iniciar a elaborao desses diagramas. Assim, as atividades mostradas na Figura 4.1 so fortemente paralelas e iterativas. Paralelamente a todas as atividades de modelagem, o documento de especificao de requisitos deve ir sendo elaborado. Mesmo a verificao e a validao podem ser feitas por partes e no para o documento como um todo. Por exemplo, bastante comum validar primeiro somente os casos de uso. Verificaes de consistncia, tais como as feitas entre casos de uso e classes, ou casos de uso, diagramas de interao e diagramas de classes, podem ser feitas separadamente uma das outras. Assim, as atividades de documentao, verificao e validao so atividades contnuas que ocorrem paralelamente modelagem conceitual.
4.5 Especificao de Requisitos No Funcionais

Assim como os requisitos funcionais precisam ser especificados em detalhes, o mesmo acontece com os requisitos no funcionais. Para os atributos de qualidade considerados prioritrios, o analista deve trabalhar no sentido de especific-los de modo que eles se tornem mensurveis e, por conseguinte, testveis. Deve-se procurar indicar a unidade de medida e uma escala para cada atributo e os valores mnimo, alvo e mximo. Pode-se, ainda, perguntar aos usurios o que constituiria um valor inaceitvel para cada atributo e definir testes que tentem forar o sistema a demonstrar tais caractersticas (WIEGERS, 2003). Ao se estabelecer uma escala de medio e os valores aceitveis, o requisito transformado de uma inteno vaga, e at certo ponto ambgua, em um requisito mensurvel e bem formado. Estabelecida uma escala, pode-se perguntar ao usurio o que considerado uma falha em atender ao requisito, de modo a definir o critrio de aceitao do mesmo (ROBERTSON; ROBERTSON, 2006). Assim, na especificao de requisitos de sistema, importante transformar um requisito de usurio em um requisito mensurvel, adicionando a ele um critrio de aceitao. A ISO/IEC 9126 pode ser uma boa fonte de medidas. As partes 2 (Medidas Externas) (ISO/IEC, 2003a) e 3 (Medidas Internas) (ISO/IEC, 2003b) dessa norma apresentam diversas medidas que podem ser usadas para especificar objetivamente os requisitos no funcionais. Nas partes 2 e 3 da norma, medidas so sugeridas para as diversas subcaractersticas de qualidade externa e interna descritas na Parte 1, indicando, dentre outros, nome e propsito da medida, mtodo de aplicao e frmula, e como interpretar os valores da medida.
82
Seja o exemplo de um sistema que tem como requisito no funcional ser fcil de aprender. Esse requisito poderia ser especificado conforme mostrado na Tabela 4.1. Tabela 4.1 Especificao de Requisito No Funcional.
RNF01 A funcionalidade Efetuar Locao de Item deve ser fcil de aprender. Medida: (ISO/IEC, 2003a) Descrio: Propsito: Mtodo de Aplicao: Medio: Facilidade de aprender a realizar uma tarefa em uso. Quanto tempo o usurio leva para aprender a realizar uma tarefa especificada eficientemente? Observar o comportamento do usurio desde quando ele comea a aprender at quando ele comea a operar eficientemente. T = soma do tempo de operao do usurio at que ele consiga realizar a tarefa em um tempo especificado (tempo requerido para aprender a operao para realizar a tarefa).
Critrio de Aceitao:
T <= 15 minutos, considerando que o usurio est operando o sistema eficientemente quando a tarefa Efetuar Locao realizada em um tempo inferior a 2 minutos.
4.6 O Documento de Especificao de Requisitos

Os requisitos de sistema, assim como foi o caso dos requisitos de usurio, tm de ser especificados em um documento, de modo a poderem ser verificados e validados e posteriormente usados como base para as atividades subsequentes do desenvolvimento de software. O Documento de Especificao de Requisitos tem como propsito registrar os requisitos escritos a partir da perspectiva do desenvolvedor e, portanto, deve incluir os vrios modelos conceituais desenvolvidos, bem como a especificao dos requisitos no funcionais detalhados. Diferentes formatos podem ser propostos para documentos de especificao requisitos, bem como mais de um documento pode ser usado para documentar os requisitos de sistema. Neste texto, prope-se o uso de um nico documento, contendo as seguintes informaes: 1. Introduo: breve introduo ao documento, descrevendo seu propsito e estrutura. 2. Modelo de Casos de Uso: apresenta o modelo de casos de uso do sistema, incluindo os diagramas de casos de uso e as descries de casos de uso associadas. 3. Modelo Estrutural: apresenta o modelo conceitual estrutural do sistema, incluindo os diagramas de classes do sistema. 4. Modelo Dinmico: apresenta os modelos comportamentais dinmicos do sistema, incluindo os diagramas de estados, diagramas de interao e diagramas de atividades. 5. Dicionrio do Projeto: apresenta as definies dos principais conceitos capturados pelos diversos modelos e restries de integridade a serem consideradas, servindo como um glossrio do projeto. 6. Especificao dos Requisitos No Funcionais: apresenta os requisitos no funcionais descritos no nvel de sistema, o que inclui critrios de aceitao. importante frisar que dificilmente um sistema simples o bastante para ser modelado como um todo. Quase sempre til dividir um sistema em unidades menores, mais
83
fceis de serem gerenciveis, ditas subsistemas. til organizar a especificao de requisitos por subsistemas e, portanto, cada uma das sees propostas acima pode ser subdividida por subsistemas. Um modelo estrutural para uma aplicao complexa, por exemplo, pode ter centenas de classes e, portanto, pode ser necessrio definir uma representao concisa capaz de orientar um leitor em um modelo dessa natureza. O agrupamento de elementos de modelo em subsistemas serve basicamente a este propsito, podendo ser til tambm para a organizao de grupos de trabalho em projetos extensos. A base principal para a identificao de subsistemas a complexidade do domnio do problema. Atravs da identificao e agrupamento de elementos de modelo em subsistemas, possvel controlar a visibilidade do leitor e, assim, tornar os modelos mais compreensveis. A UML prov um tipo principal de item de agrupamento, denominado pacote, que um mecanismo de propsito geral para a organizao de elementos da modelagem em grupos. Um diagrama de pacotes mostra a decomposio de um modelo em unidades menores e suas dependncias, como ilustra a Figura 4.4. A linha pontilhada direcionada indica que o pacote origem (no exemplo, o pacote Atendimento a Cliente) depende do pacote destino (no exemplo, o pacote Controle de Acervo).
Figura 4.4 Exemplo de um Diagrama de Pacotes Leitura Complementar O Captulo 1 de (OLIV, 2007) Introduction d uma tima introduo modelagem conceitual. O Captulo 2 de (BLAHA; RUMBAUGH, 2006) Modelagem como uma Tcnica de Projeto discute o que so modelos, seus papis e principais tipos de modelos. J o Captulo 1 Introduo apresenta uma boa introduo orientao a objetos e seus principais conceitos. Em (WIEGERS, 2003), os captulos 10 e 11 esto relacionados a temas discutidos neste captulo. O Captulo 10 Documenting the Requirements discute a estrutura de um documento de especificao de requisitos, enquanto o Captulo 11 A Picture is Worth 1024 Words discute a modelagem de requisitos, descrevendo diversos modelos que podem ser empregados nesta tarefa. De (ROBERTSON; ROBERTSON, 2006) sugere-se a leitura do Captulo 9 Fit Criteria para a definio de critrios de aceitao para complementar a descrio de requisitos, tornando-os mensurveis e testveis. Para apoiar a definio desses critrios, recomenda-se utilizar as medidas definidas nas partes 2 e 3 da norma ISO/IEC 9126 (ISO/IEC, 2003a; ISO/IEC, 2003b). Em (BASS; CLEMENTS; KAZMAN, 2003), o Captulo 4 Understanding Quality Attributes discute atributos de qualidade de sistemas de software e como especificar requisitos especficos desses atributos na forma de cenrios.
84
Por fim, o Captulo 2 de (BOOCH; RUMBAUGH; JACOBSON, 2006) Introduo UML apresenta uma viso geral da UML, incluindo uma breve apresentao de seu metamodelo, descrevendo seus itens estruturais, comportamentais, de agrupamento e de anotao. O Captulo 7 Diagramas faz uma breve apresentao dos principais diagramas da UML e o Captulo 12 Pacotes trata de pacotes e diagramas de pacotes. Referncias do Captulo AURUM, A., WOHLIN, C., Engineering and Managing Software Requirements, SpringerVerlag, 2005. BASS, L., CLEMENTS, P., KAZMAN, R., Software Architecture in Practice, Second edition, Addison Wesley, 2003. BLAHA, M., RUMBAUGH, J., Modelagem e Projetos Baseados em Objetos com UML 2, Elsevier, 2006. BOOCH, G., Object-Oriented Analysis and Design with Applications, 2nd edition, Benjamin/Cummings Publishing Company, Inc, 1994. BOOCH, G., RUMBAUGH, J., JACOBSON, I., UML Guia do Usurio, 2a edio, Elsevier Editora, 2006. ISO/IEC 9126-1, Software Engineering - Product Quality - Part 1: Quality Model, 2001. ISO/IEC TR 9126-2:2003, Software Engineering Product Quality Part 2: External Metrics, 2003a. ISO/IEC TR 9126-3:2003, Software Engineering Product Quality Part 3: Internal Metrics, 2003b. JACOBSON, I.; Object-Oriented Software Engineering, Addison-Wesley, 1992. LARMAN, C., Utilizando UML e Padres, 3 edio, Bookman, 2007. OLIV, A., Conceptual Modeling of Information Systems, Springer, 2007. PASTOR, O., MOLINA, J.C., Model-Driven Architecture in Practice: A Software Production Environment Based on Conceptual Modeling, Springer, 2007. ROBERTSON, S., ROBERTSON, J., Mastering the Requirements Process. 2nd Edition. Addison Wesley, 2006. RUMBAUGH, J., et al.; Modelagem e Projetos Baseados em Objetos, 1 Edio, Editora Campus, 1994. WAZLAWICK, R.S., Anlise e Projeto de Sistemas de Informao Orientados a Objetos, Elsevier, 2004. WIEGERS, K.E., Software Requirements: Practical techniques for gathering and managing requirements throughout the product development cycle. 2nd Edition, Microsoft Press, Redmond, Washington, 2003. YOURDON, E., Object-Oriented Systems Design: an Integrated Approach, Yourdon Press Computing Series, Prentice Hall, 1994.
Captulo 5 Modelagem de Casos de Uso
85

A anlise de requisitos um processo que envolve a construo de diversos modelos. Modelos de objetos (diagramas de classes) e modelos de interao (diagramas de sequncia, por exemplo) incluem detalhes relacionados estrutura interna dos objetos, suas associaes, como eles interagem dinamicamente e como invocam o comportamento dos demais. Essas informaes so necessrias para projetar e construir um sistema, mas no so suficientes para comunicar requisitos com clientes e usurios. Elas no capturam o conhecimento sobre as tarefas a serem realizadas e, portanto, difcil avaliar se o sistema a ser construdo a partir de um modelo desse tipo, isoladamente, vai realmente atender s necessidades dos usurios. Assim, o primeiro modelo a ser construdo deve ser passvel de compreenso tanto por desenvolvedores analistas, projetistas, programadores e testadores como pela comunidade usuria clientes e usurios. Esse modelo inicial deve descrever o sistema, seu ambiente e como sistema e ambiente esto relacionados. Modelos de caso de uso (use cases) so uma forma de estruturar essa viso. Como o prprio nome sugere, um caso de uso uma maneira de usar o sistema. Usurios interagem com o sistema, interagindo com seus casos de uso. Tomados em conjunto, os casos de uso de um sistema representam a sua funcionalidade. Casos de uso so, portanto, os itens que o desenvolvedor negocia com seus clientes. O propsito do modelo de casos de uso capturar e descrever a funcionalidade que um sistema deve prover. Um sistema geralmente serve a vrios atores, para os quais ele prov diferentes servios. Tipicamente, a funcionalidade a ser provida por um sistema muito grande para ser analisada como uma nica unidade e, portanto, importante ter um mecanismo de dividir essa funcionalidade em partes menores e mais gerenciveis. O conceito de caso de uso muito til para esse propsito (OLIV, 2007). importante ter em mente que casos de uso so fundamentalmente uma ferramenta textual. Ainda que casos de uso sejam tambm descritos graficamente (p.ex., fluxogramas ou algum diagrama da UML, dentre eles diagramas de casos de uso, diagramas de sequncia e diagramas de atividades), no se deve perder de vista a natureza textual dos casos de uso. Olhando casos de uso apenas a partir da UML, que no trata do contedo ou da escrita de casos de uso, pode-se pensar, equivocadamente, que casos de uso so uma construo grfica ao invs de textual. Em essncia, casos de uso servem como um meio de comunicao entre pessoas, algumas delas sem nenhum treinamento especial e, portanto, o uso de texto para especificar casos de uso geralmente a melhor escolha. Casos de uso so amplamente usados no desenvolvimento de sistemas, porque, por meio sobretudo de suas descries textuais, usurios e clientes conseguem visualizar qual a funcionalidade a ser provida pelo sistema, conseguindo reagir mais rapidamente no sentido de refinar, alterar ou rejeitar as funes previstas para o sistema (COCKBURN, 2005). Assim, um modelo de casos de uso inclui duas partes principais: (i) os diagramas de casos de uso e (ii) as descries de atores e de casos de
86
uso, sendo que essas ltimas podem ser complementadas com outros diagramas associados, tais como os diagramas de atividade e de sequncia da UML6. Outro aspecto a ser realado que os modelos de caso de uso so independentes do mtodo de anlise a ser usado e at mesmo do paradigma de desenvolvimento. Assim, podese utilizar a modelagem de casos de uso tanto no contexto do desenvolvimento orientado a objetos (foco deste texto), como em projetos desenvolvidos segundo o paradigma estruturado. De fato, o uso de modelos de caso de uso pode ser ainda mais amplo. Casos de uso podem ser usados, por exemplo, para documentar processos de negcio de uma organizao. Contudo, neste texto, explora-se a utilizao de casos de uso para modelar e documentar requisitos funcionais de sistemas. Assim, geralmente so interessados7 (stakeholders) nos casos de uso: as pessoas que usaro o sistema (usurios), o cliente que requer o sistema, outros sistemas com os quais o sistema em questo ter de interagir e outros membros da organizao (ou at mesmo de fora dela) que tm restries que o sistema precisa garantir. Este captulo aborda a tcnica de modelagem de casos de uso, discutindo os principais elementos de modelos de casos de uso. A seo 5.1 discute os dois principais conceitos empregados na modelagem de casos de uso: atores e casos de uso. A seo 5.2 aborda os diagramas de casos de uso e sua notao segundo a UML. A seo 5.3 trata da especificao de casos de uso. A seo 5.4 discute os tipos de relacionamentos que podem ser estabelecidos entre casos de uso, a saber: incluso, extenso e generalizao / especializao. Finalmente, a seo 5.5 discute como trabalhar com casos de uso e como us-los em outras atividades do processo de software.
5.1 Atores e Casos de Uso

Nenhum sistema computacional existe isoladamente. Todo sistema interage com atores humanos ou outros sistemas, que utilizam esse sistema para algum propsito e esperam que o sistema se comporte de certa maneira. Um caso de uso especifica um comportamento de um sistema segundo uma perspectiva externa e uma descrio de uma sequncia de aes realizada pelo sistema para produzir um resultado de valor para um ator (BOOCH; RUMBAUGH; JACOBSON, 2006). Segundo Cockburn (2005), um caso de uso captura um contrato entre os interessados (stakeholders) em um sistema sobre o seu comportamento. Um caso de uso descreve o comportamento do sistema sob certas condies, em resposta a uma requisio feita por um interessado, dito o ator primrio do caso de uso. Assim, os dois principais conceitos da modelagem de casos de uso so atores e casos de uso.
5.1.1 - Atores
D-se nome de ator a um papel desempenhado por entidades fsicas (pessoas, organizaes ou outros sistemas) que interagem com o sistema em questo da mesma maneira, procurando atingir os mesmos objetivos. Uma mesma entidade fsica pode desempenhar diferentes papis no mesmo sistema, bem como um dado papel pode ser desempenhado por diferentes entidades (OLIV, 2007).
O uso de diagramas de atividade e de sequncia para complementar a especificao de um caso de uso discutido no Captulo 7. 7 Algum ou algo com interesse no comportamento do sistema sob discusso (COCKBURN, 2005).
6
87
Atores so externos ao sistema. Um ator se comunica diretamente com o sistema, mas no parte dele. A modelagem dos atores ajuda a definir as fronteiras do sistema, isto , o conjunto de atores de um sistema delimita o ambiente externo desse sistema, representando o conjunto completo de entidades para as quais o sistema pode servir (BLAHA; RUMBAUGH, 2006; OLIV, 2007). Uma dvida que sempre passa pela cabea de um iniciante em modelagem de casos de uso saber se o ator a pessoa que efetivamente opera o sistema (p.ex., o atendente de uma locadora de automveis) ou se a pessoa interessada no resultado do processo (p.ex., o cliente que efetivamente loca o automvel e atendido pelo atendente). Essa definio depende, em essncia, da fronteira estabelecida para o sistema. Sistemas de informao podem ter diferentes nveis de automatizao. Por exemplo, se um sistema roda na Internet, seu nvel de automatizao maior do que se ele requer um operador. Assim, importante capturar qual o nvel de automatizao requerido e levar em conta o real limite do sistema (WAZLAWICK, 2004). Se o caso de uso roda na Internet (p.ex., um caso de uso de reserva de automvel), ento o cliente o ator efetivamente. Se o caso de uso requer um operador (p.ex., um caso de uso de locao de automvel, disponvel apenas na locadora e para ser usado por atendentes), ento o operador o ator. Quando se for considerar um sistema como sendo um ator, deve-se tomar o cuidado para no confundir a ideia de sistema externo (ator) com produtos usados na implementao do sistema em desenvolvimento. Para que um sistema possa ser considerado um ator, ele deve ser um sistema de informao completo (e no apenas uma biblioteca de classes, por exemplo). Alm disso, ele deve estar fora do escopo do desenvolvimento do sistema atual. O analista no ter a oportunidade de alterar as funes do sistema externo, devendo adequar a comunicao s caractersticas do mesmo (WAZLAWICK, 2004). Um ator primrio um ator que possui metas a serem cumpridas atravs do uso de servios do sistema e que, tipicamente, inicia a interao com o sistema (OLIV, 2007). Um ator secundrio um ator externo que interage com o sistema para prover um servio para este ltimo. A identificao de atores secundrios importante, uma vez que ela permite identificar interfaces externas que o sistema usar e os protocolos que regem as interaes ocorrendo atravs delas (COCKBURN, 2005). De maneira geral, o ator primrio o usurio direto do sistema ou outro sistema computacional que requisita um servio do sistema em desenvolvimento. O sistema responde requisio procurando atend-la, ao mesmo tempo em que protege os interesses de todos os demais interessados no caso de uso. Entretanto, h situaes em que o iniciador do caso de uso no o ator primrio. O tempo, por exemplo, pode ser o acionador de um caso de uso. Um caso de uso que roda todo dia meia-noite ou ao final do ms tem o tempo como acionador. Mas o caso de uso ainda visa atingir um objetivo de um ator e esse ator considerado o ator primrio do caso de uso, ainda que ele no interaja efetivamente com o sistema (COCKBURN, 2005). Para nomear atores, recomenda-se o uso de substantivos no singular, iniciados com letra maiscula, possivelmente combinados com adjetivos. Exemplos: Cliente, Bibliotecrio, Correntista, Correntista Titular etc.
88
5.1.2 Casos de Uso

Um caso de uso uma poro coerente da funcionalidade que um sistema pode fornecer para atores interagindo com ele (BLAHA; RUMBAUGH, 2006). Um caso de uso corresponde a um conjunto de aes realizadas pelo sistema (ou por meio da interao com o sistema), que produz um resultado observvel, com valor para um ou mais atores do sistema. Geralmente, esse valor a realizao de uma meta de negcio ou tarefa (OLIV, 2007). Assim, um caso de uso captura alguma funo visvel ao ator e, em especial, busca atingir uma meta desse ator. Deve-se considerar que um caso de uso corresponde a uma transao completa, ou seja, um usurio poderia ativar o sistema, executar o caso de uso e desativar o sistema logo em seguida, e a operao estaria completa e consistente e atenderia a uma meta desse usurio (WAZLAWICK, 2004). Ser uma transao completa uma caracterstica essencial de um caso de uso8, pois somente transaes completas so capazes de atingir um objetivo do usurio. Casos de uso que necessitam de mltiplas sees no passam nesse critrio e devem ser divididos em casos de uso menores. Seja o exemplo de um caso de uso de concesso de emprstimo. Inicialmente, um atendente interagindo com um cliente informa os dados necessrios para a avaliao do pedido de emprstimo. O pedido de emprstimo , ento, enviado para anlise por um analista de crdito. Uma vez analisado e aprovado, o emprstimo concedido, quando o dinheiro entregue ao cliente e um contrato assinado, dentre outros. Esse processo pode levar vrios dias e no realizado em uma seo nica. Assim, o caso de uso de concesso de emprstimo deveria ser subdividido em casos de uso menores, tais como casos de uso para efetuar pedido de emprstimo, analisar pedido de emprstimo e formalizar concesso de emprstimo. Por outro lado, casos de uso muito pequenos, que no caracterizam uma transao completa, devem ser considerados passos de um caso de uso maior9. Seja o exemplo de uma biblioteca a qual cobra multa na devoluo de livros em atraso. Um caso de uso especfico para apenas calcular o valor da multa no relevante, pois no caracteriza uma transao completa capaz de atingir um objetivo do usurio. O objetivo do usurio efetuar a devoluo e, neste contexto, uma regra de negcio (a que estabelece a multa) tem de ser levada em conta. Assim, calcular a multa apenas um passo do caso de uso que efetua a devoluo, o qual captura uma ao do sistema para garantir a regra de negcio e, portanto, satisfazer um interesse da biblioteca como organizao. Um caso de uso rene todo o comportamento relevante de uma parte da funcionalidade do sistema. Isso inclui o comportamento principal normal, as variaes de comportamento normais, as condies de exceo e o cancelamento de uma requisio. O conjunto de casos de uso captura a funcionalidade completa do sistema (BLAHA; RUMBAUGH, 2006). Casos de uso fornecem uma abordagem para os desenvolvedores chegarem a uma compreenso comum com os usurios finais e especialistas do domnio, acerca da funcionalidade a ser provida pelo sistema (BOOCH; RUMBAUGH; JACOBSON, 2006).
Esta regra tem como exceo os casos de uso de incluso e extenso, conforme discutido mais adiante na seo que trata de relacionamentos entre casos de uso. 9 As mesmas excees da nota anterior se aplicam aqui, conforme discutido mais adiante.
89
Os objetivos dos atores so um bom ponto de partida para a identificao de casos de uso. Pode-se propor um caso de uso para satisfazer cada um dos objetivos de cada um dos atores. A partir desses objetivos, podem-se estudar as possveis interaes do ator com o sistema e refinar o modelo de casos de uso. Cada caso de uso tem um nome. Esse nome deve capturar a essncia do caso de uso. Para nomear casos de uso sugere-se usar frases iniciadas com verbos no infinitivo, seguidos de complementos, que representem a meta ou tarefa a ser realizada com o caso de uso. As primeiras letras (exceto preposies) de cada palavra devem ser grafadas em letra maiscula. Exemplos: Cadastrar Cliente, Devolver Livro, Efetuar Pagamento de Fatura etc. Um caso de uso pode ser visto como um tipo cujas instncias so cenrios. Um cenrio uma execuo de um caso de uso com entidades fsicas particulares desempenhando os papis dos atores e em um particular estado do domnio de informao. Um cenrio, portanto, exercita um certo caminho dentro do conjunto de aes de um caso de uso (OLIV, 2007). Alguns cenrios mostram o objetivo do caso de uso sendo alcanado; outros terminam com o caso de uso sendo abandonado (COCKBURN, 2005). Mesmo quando o objetivo de um caso de uso alcanado, ele pode ser atingido seguindo diferentes caminhos. Assim, um caso de uso deve comportar todas essas situaes. Para tal, um caso de uso normalmente descrito por um conjunto de fluxos de eventos, capturando o fluxo de eventos principal, i.e., o fluxo de eventos tpico que conduz ao objetivo do caso de uso, e fluxos de eventos alternativos, descrevendo excees ou variantes do fluxo principal.
5.2 - Diagramas de Casos de Uso

Basicamente, um diagrama de casos de uso mostra um conjunto de casos de uso e atores e seus relacionamentos, sendo utilizado para ilustrar uma viso esttica das maneiras possveis de se usar o sistema (BOOCH; RUMBAUGH; JACOBSON, 2006). Os diagramas de casos de uso da UML podem conter os seguintes elementos de modelo, ilustrados na Figura 5.1 (BOOCH; RUMBAUGH; JACOBSON, 2006): Assunto: o assunto delimita a fronteira de um diagrama de casos de uso, sendo normalmente o sistema ou um subsistema. Os casos de uso de um assunto descrevem o comportamento completo do assunto. O assunto exibido em um diagrama de casos de uso como um retngulo envolvendo os casos de uso que o compem. O nome do assunto (sistema ou subsistema) pode ser mostrado dentro do retngulo. Ator: representa um conjunto coerente de papis que os usurios ou outros sistemas desempenham quando interagem com os casos de uso. Tipicamente, um ator representa um papel que um ser humano, um dispositivo de hardware ou outro sistema desempenha com o sistema em questo. Atores no so parte do sistema. Eles residem fora do sistema. Atores so representados por um cone de homem, com o nome colocado abaixo do cone. Caso de Uso: representa uma funcionalidade que o sistema deve prover. Casos de uso so parte do sistema e, portanto, residem dentro dele. Um caso de uso representado por uma elipse com o nome do caso de uso dentro ou abaixo dela.
90
Relacionamentos de Dependncia, Generalizao e Associao: so usados para estabelecer relacionamentos entre atores, entre atores e casos de uso, e entre casos de uso.
Figura 5.1 - Diagrama de Casos de Uso Conceitos e Notao. Atores s podem estar conectados a casos de uso por meio de associaes. Uma associao entre um ator e um caso de uso significa que estmulos podem ser enviados entre atores e casos de uso. A associao entre um ator e um caso de uso indica que o ator e o caso de uso se comunicam entre si, cada um com a possibilidade de enviar e receber mensagens (BOOCH; RUMBAUGH; JACOBSON, 2006). Atores podem ser organizados em hierarquias de generalizao / especializao, de modo a capturar que um ator filho herda o significado e as associaes com casos de uso de seu pai, especializando esse significado e potencialmente adicionando outras associaes como outros casos de uso. A Figura 5.2 mostra um diagrama de casos de uso para um sistema de caixa automtico. Nesse diagrama, o assunto o sistema como um todo. Os atores so: os clientes do banco, o sistema bancrio e os responsveis pela manuteno do numerrio no caixa eletrnico. Cliente e mantenedor so atores primrios, uma vez que tm objetivos a serem atingidos pelo uso do sistema. O sistema bancrio um ator, pois o sistema do caixa automtico precisa interagir com o sistema bancrio para realizar os casos de uso Efetuar Saque, Emitir Extrato e Efetuar Pagamento.
91
Figura 5.2 - Diagrama de Casos de Uso Caixa Automtico. Um caso de uso descreve o que um sistema deve fazer. O diagrama de casos de uso prov uma viso apenas parcial disso, uma vez que mostra as funcionalidades por perspectiva externa. necessrio, ainda, capturar uma viso interna de cada caso de uso, especificando o comportamento do caso de uso pela descrio do fluxo de eventos que ocorre internamente (passos do caso de uso). Assim, uma parte fundamental do modelo de casos de uso a descrio dos casos de uso.
5.3 - Descrevendo Casos de Uso

Um caso de uso deve descrever o que um sistema faz. Exceto para situaes muito simples, um diagrama de casos de uso insuficiente para este propsito. Assim, deve-se especificar o comportamento de um caso de uso pela descrio textual de seu fluxo de eventos, de modo que outros interessados possam compreend-lo. A especificao ou descrio de um caso de uso deve conter, dentre outras informaes, um conjunto de sentenas, cada uma delas escrita em uma forma gramatical designando um passo simples, de modo que aprender a ler um caso de uso no requeira mais do que uns poucos minutos. Dependendo da situao, diferentes estilos de escrita podem ser adotados (COCKBURN, 2005). Cada passo do fluxo de eventos de um caso de uso tipicamente descreve uma das seguintes situaes: (i) uma interao entre um ator e o sistema, (ii) uma ao que o sistema realiza para atingir o objetivo do ator primrio ou (iii) uma ao que o sistema realiza para proteger os interesses de um interessado. Essas aes podem incluir validaes e mudanas do estado interno do sistema (COCKBURN, 2005). No h um padro definido para especificar casos de uso. Diferentes autores propem diferentes estruturas, formatos e contedos para descries de casos de uso, alguns mais indicados para casos de uso essenciais e mais complexos, outros para casos de uso cadastrais e mais simples. Mais alm, pode ser til utilizar mais de um formato dentro do mesmo
92
projeto, em funo das peculiaridades de cada caso de uso. De todo modo, recomendvel que a organizao defina modelos de descrio de casos de uso a serem adotados em seus projetos, devendo definir tantos modelos quantos julgar necessrios. Cockburn (2005) recomenda que pelo menos dois modelos de descrio de casos de uso sejam definidos: um casual, escrito como um texto corrido livre, a ser usado em projetos com pouca formalidade; outro completo, com uma estrutura bem definida, para projetos de maior formalidade. As seguintes informaes so um bom ponto de partida para a definio de um modelo de descrio de casos de uso: Nome: nome do caso de uso, capturando a sua essncia Escopo: diz respeito ao que est sendo documentado pelo caso de uso. Tipicamente pode ser um processo de negcio, um sistema ou um subsistema. Vale lembrar que este texto no aborda a utilizao de casos de uso para a modelagem de processos de negcio. Assim, o escopo vai apontar o sistema / subsistema do qual o caso de uso faz parte. Descrio do Propsito: uma descrio sucinta do caso de uso, na forma de um nico pargrafo, procurando descrever o objetivo do caso de uso. Ator Primrio: nome do ator primrio, ou seja, o interessado que tem um objetivo em relao ao sistema, o qual pode ser atingido pela execuo do caso de uso. Interessados e Interesses: um interessado algum ou algo (um outro sistema) que tem um interesse no comportamento do caso de uso sendo descrito. Nesta seo so descritos cada um dos interessados no sistema e qual o seu interesse no caso de uso, incluindo o ator primrio. Pr-condies: o que deve ser verdadeiro antes da execuo do caso de uso. Se as pr-condies no forem satisfeitas, o caso de uso no pode ser realizado. Ps-condies: o que deve ser verdadeiro aps a execuo do caso de uso, considerando que o fluxo de eventos normal realizado com sucesso. Fluxo de Eventos Normal: descreve os passos do caso de uso realizados em situaes normais, considerando que nada acontece de errado e levando em conta a maneira mais comum do caso de uso ser realizado. Fluxo de Eventos Alternativos: descreve formas alternativas de realizar certos passos do caso de uso. H duas formas alternativas principais: fluxos variantes, que so considerados dentro da normalidade do caso de uso; e fluxos de exceo, que se referem ao tratamento de erros durante a execuo de um passo do fluxo normal (ou de um fluxo variante ou at mesmo de um outro fluxo de exceo). Requisitos Relacionados: listagem dos identificadores dos requisitos (funcionais, no funcionais e regras de negcio) tratados pelo caso de uso sendo descrito, de modo a permitir rastrear os requisitos. Casos de uso podem ser usados para conectar vrios requisitos, de tipos diferentes. Assim, essa listagem ajuda a manter um rastro entre requisitos funcionais, no funcionais e regras de negcio, alm de permitir verificar se algum requisito deixou de ser tratado.
93
Classes / Entidades: classes (no paradigma orientado a objetos) ou entidades (no paradigma estruturado) necessrias para tratar o caso de uso sendo descrito. Esta seo normalmente preenchida durante a modelagem conceitual estrutural e igualmente importante para permitir rastrear requisitos para as etapas subsequentes do desenvolvimento (projeto e implementao, sobretudo).
5.3.1 Descrevendo os Fluxos de Eventos

Uma vez que o conjunto inicial de casos de uso estiver estabilizado, cada um deles deve ser descrito em mais detalhes. Primeiro, deve-se descrever o fluxo de eventos principal (ou curso bsico), isto , o curso de eventos mais importante, que normalmente ocorre. O fluxo de eventos normal (ou principal) uma informao essencial na descrio de um caso de uso e no pode ser omitido em nenhuma circunstncia. O fluxo de eventos normal , portanto, a principal seo de uma descrio de caso de uso, a qual descreve o processo quando tudo d certo, ou seja, sem a ocorrncia de nenhuma exceo (WAZLAWICK, 2004). Variantes do curso bsico de eventos e tratamento de excees que possam vir a ocorrer devem ser descritos em cursos alternativos. Normalmente, um caso de uso possui apenas um nico curso bsico, mas diversos cursos alternativos. Seja o exemplo de um sistema de caixa automtico de banco, cujo diagrama de casos de uso mostrado na Figura 5.2. O caso de uso Efetuar Saque poderia ser descrito como mostrado na Figura 5.3. Como visto nesse exemplo, um caso de uso pode ter um nmero de cursos alternativos que podem levar o caso de uso por diferentes caminhos. Tanto quanto possvel, esses cursos alternativos, muitos deles cursos de exceo, devem ser identificados durante a especificao do fluxo de eventos normal de um caso do uso. Vale realar que uma exceo no necessariamente um evento que ocorre muito raramente, mas sim um evento capaz de impedir o prosseguimento do caso de uso, se no for devidamente tratado. Uma exceo tambm no algo que impede o caso de uso de ser iniciado, mas algo que impede a sua concluso. Condies que impedem um caso de uso de ser iniciado devem ser tratadas como pr-condies. As pr-condies nunca devem ser testadas durante o processo do caso de uso, pois, por definio, elas impedem que o caso de uso seja iniciado. Logo, seria inconsistente imaginar que elas pudessem ocorrer durante a execuo do caso de uso. Se uma pr-condio falsa, ento o caso de uso no pode ser iniciado (WAZLAWICK, 2004). Observa-se que a maioria das excees ocorre nos passos em que alguma informao passada dos atores para o sistema. Isso porque, quando uma informao passada para o sistema, muitas vezes ele realiza validaes. Quando uma dessas validaes falha, tipicamente ocorre uma exceo (WAZLAWICK, 2004).
94
Nome: Efetuar Saque Escopo: Sistema de Caixa Automtico Descrio do Propsito: Este caso de uso permite que um cliente do banco efetue um saque, retirando dinheiro de sua conta bancria. Ator Primrio: Cliente Interessados e Interesses: Cliente: deseja efetuar um saque. Banco: garantir que apenas o prprio cliente efetuar saques e que os valores dos saques sejam compatveis com o limite de crdito do cliente. Pr-condies: O caixa automtico deve estar conectado ao sistema bancrio. Ps-condies: O saque efetuado, debitando o valor da conta do cliente e entregando o mesmo valor para o cliente em espcie. Fluxo de Eventos Normal O cliente insere seu carto no caixa automtico, que analisa o carto e verifica se ele aceitvel. Se o carto aceitvel, o caixa automtico solicita que o cliente informe a senha. O cliente informa a senha. O caixa automtico envia os dados do carto e da senha para o sistema bancrio para validao. Se a senha estiver correta, o caixa solicita que o cliente informe o tipo de transao a ser efetuada. O cliente seleciona a opo saque e o caixa solicita que seja informada a quantia. O cliente informa a quantia a ser sacada. O caixa envia uma requisio para o sistema bancrio para que seja efetuado um saque na quantia especificada. Se o saque autorizado, as notas so preparadas e liberadas. Fluxos de Eventos de Exceo O carto no aceitvel: Se o carto no aceitvel, seja porque sua tarja magntica no passvel de leitura seja porque de um tipo incompatvel, uma mensagem de erro de leitura mostrada. Senha incorreta: Se a senha informada est incorreta, uma mensagem mostrada para o cliente que poder entrar com a senha novamente. Caso o cliente informe trs vezes senha incorreta, o carto dever ser bloqueado. Saque no autorizado: Se o saque no for aceito pelo sistema bancrio, uma mensagem de erro exibida e a operao abortada. No h dinheiro suficiente disponvel no caixa eletrnico: Uma mensagem de erro exibida e a operao abortada. Cancelamento: O cliente pode cancelar a transao a qualquer momento, enquanto o saque no for autorizado pelo sistema bancrio. Requisitos Relacionados: RF01, RN01, RNF01, RNF0210 Classes: Cliente, Conta, Carto, Transao, Saque. Figura 5.3 Descrio do Caso de Uso Efetuar Saque.
So as seguintes as descries dos requisitos listados: RF01 O sistema de caixa automtico deve permitir que clientes efetuem saques em dinheiro; RN01 No devem ser permitidas transaes que deixem a conta do cliente com saldo inferior ao de seu limite de crdito; RNF01 O sistema de caixa automtico deve estar integrado ao sistema bancrio; RNF02 As operaes realizadas no caixa automtico devem dar respostas em at 10s a partir da entrada de dados.
10
95
Em sistemas de mdio a grande porte, pode ser til considerar a fuso de casos de uso fortemente relacionados em um nico caso de uso, contendo mais de um fluxo de eventos normal. Em muitos sistemas necessrio dar ao usurio a possibilidade de cancelar ou alterar dados de uma transao efetuada anteriormente com sucesso. Se cada uma dessas possibilidades for considerada como um caso de uso isolado, o nmero de casos de uso pode crescer demasiadamente, aumentando desnecessariamente a complexidade do modelo de casos de uso. Alm disso, o fluxo de eventos normal de um caso de uso desse tipo tende a ser muito simples, no justificando documentar todo um conjunto de informaes para adicionar apenas duas ou trs linhas descrevendo os passos do caso de uso. Assim, em situaes dessa natureza, interessante considerar apenas um caso de uso, contendo diversos fluxos de eventos principais. Essa abordagem bastante recomendada para casos de uso cadastrais, em que um nico caso de uso inclui fluxos de eventos normais para criar, alterar, consultar e excluir entidades. Fluxos de eventos normais podem ser descritos de diferentes maneiras, dependendo do nvel de formalidade que se deseja para as descries. Dentre os formatos possveis, h dois principais: Livre: o fluxo de eventos normal escrito na forma de um texto corrido, como no exemplo da Figura 5.3; Enumerado: cada passo do fluxo de eventos normal numerado, de modo que possa ser referenciado nos fluxos de eventos alternativos ou em outros pontos do fluxo de eventos normal. A Figura 5.4 reapresenta o exemplo da Figura 5.3 neste formato. As sees iniciais foram omitidas por serem iguais s da Figura 5.3. Neste texto, advogamos em favor do uso do formato enumerado.
Cada exceo deve ser tratada por um fluxo alternativo de exceo. Fluxos alternativos de exceo devem ser descritos contendo as seguintes informaes (WAZLAWICK, 2004): um identificador, uma descrio sucinta da exceo que ocorreu, os passos para tratar a exceo (aes corretivas) e uma indicao de como o caso de uso retorna ao fluxo principal (se for o caso) aps a execuo das aes corretivas. Quando um formato de descrio enumerado utilizado, no necessrio colocar uma verificao como uma condicional no fluxo principal. Por exemplo, no caso da Figura 5.4, o passo 3 no deve ser escrito como 3. Se o carto vlido, o caixa automtico solicita que o cliente informe a senha.. Basta o fluxo alternativo, no exemplo, o fluxo 2a. Ainda quando o formato de descrio enumerado utilizado, o identificador da exceo deve conter a linha do fluxo de eventos principal (ou eventualmente de algum outro fluxo de eventos alternativo) no qual a exceo ocorreu e uma letra para identificar a prpria exceo (WAZLAWICK, 2004), como ilustra o exemplo da Figura 5.4. Uma informao que precisa estar presente na descrio de um fluxo de eventos de exceo diz respeito a como finalizar o tratamento de uma exceo. Wazlawick (2004) aponta quatro formas bsicas para finalizar o tratamento de uma exceo: Voltar ao incio do caso de uso, o que no muito comum nem prtico. Voltar ao incio do passo em que ocorreu a exceo e execut-lo novamente. Esta a situao mais comum. Voltar para algum um passo posterior. Esta situao ocorre quando as aes corretivas realizam o trabalho que o passo (ou a sequncia de passos) posterior
96
deveria executar. Neste caso, importante verificar se novas excees no poderiam ocorrer. Abortar o caso de uso. Neste caso, no se retorna ao fluxo principal e o caso de uso no atinge seus objetivos.
Nome: Efetuar Saque Fluxo de Eventos Normal 1. 2. 3. 4. 5. O cliente insere seu carto no caixa automtico. O caixa automtico analisa o carto e verifica se ele aceitvel. O caixa automtico solicita que o cliente informe a senha. O cliente informa a senha. O caixa automtico envia os dados do carto e da senha para o sistema bancrio para validao. 6. O caixa automtico solicita que o cliente informe o tipo de transao a ser efetuada. 7. O cliente seleciona a opo saque. 8. O caixa automtico solicita que seja informada a quantia. 9. O cliente informa a quantia a ser sacada. 10. O caixa automtico envia uma requisio para o sistema bancrio para que seja efetuado um saque na quantia especificada. 11. As notas so preparadas e liberadas. Fluxos de Eventos de Exceo 2a O carto no aceitvel: Se o carto no aceitvel, seja porque sua tarja magntica no passvel de leitura seja porque de um tipo incompatvel, uma mensagem de erro de leitura mostrada e se retorna ao passo 1. 5a Senha incorreta: 5a.1 1 e 2 tentativas: Uma mensagem de erro mostrada para o cliente. Retornar ao passo 3. 5a.2 3 tentativa: bloquear o carto e abortar a transao. 10a - Saque no autorizado: Uma mensagem de erro exibida e a operao abortada. 11a - No h dinheiro suficiente disponvel no caixa eletrnico: Uma mensagem de erro exibida e a operao abortada. 1 a 9: Cancelamento: O cliente pode cancelar a transao, enquanto o saque no for autorizado pelo sistema bancrio. A transao abortada. Figura 5.4 Descrio do Caso de Uso Efetuar Saque Formato Enumerado Alm dos fluxos de exceo, h outro tipo de fluxo de eventos alternativo: os fluxos variantes. Fluxos variantes so considerados dentro da normalidade do caso de uso e indicam formas diferentes, mas igualmente normais, de se realizar uma certa poro de um caso de uso. Seja o caso de um sistema de um supermercado, mais especificamente um caso de uso para efetuar uma compra. Um passo importante desse caso de uso a realizao do pagamento, o qual pode se dar de trs maneiras distintas: pagamento em dinheiro, pagamento em cheque, pagamento em carto. Nenhuma dessas formas de pagamento constitui uma exceo. So todas maneiras diferentes, mas normais, de realizar um certo passo do caso de
97
uso e, portanto, pode-se dizer que o fluxo principal possui trs variaes. A descrio de um fluxo variante deve conter: um identificador, uma descrio sucinta do passo especializado e os passos enumerados, como ilustra a Figura 5.5. Nome: Efetuar Compra Fluxo de Eventos Normal ... 1. De posse do valor a ser pago, o atendente informa a forma de pagamento. 2. Efetuar o pagamento: 2a. Em dinheiro 2b. Em cheque 2c. Em carto 3. O pagamento registrado. Fluxos de Eventos Variantes 2a Pagamento em Dinheiro: 2a.1 O atendente informa a quantia em dinheiro entregue pelo cliente. 2a.2 O sistema informa o valor do troco a ser dado ao cliente. 2b Pagamento em Cheque: 2b.1 O atendente informa os dados do cheque, a saber: banco, agncia, conta e valor. 2c Pagamento em Carto: 2c.1 O atendente informa os dados do carto e o valor da compra. 2.c.2 O sistema envia os dados informados no passo anterior, junto com a identificao da loja para o servio de autorizao do Sistema de Operadoras de Carto de Crdito. 2c.3 O Sistema de Operadoras de Carto de Crdito autoriza a compra e envia o cdigo da autorizao. Figura 5.5 Descrio Parcial do Caso de Uso Efetuar Compra com Variantes Por fim, em diversas situaes, pode ser desnecessariamente trabalhoso especificar casos de uso segundo um formato completo, seja usando uma descrio dos fluxos de eventos no formato livre seja no formato enumerado. Para esses casos, um formato simplificado, na forma de uma tabela, pode ser usado. O formato tabular normalmente empregado para casos de uso que possuem uma estrutura de interao simples, seguindo uma mesma estrutura geral, tais como casos de uso cadastrais (ou CRUD11) e consultas. Casos de uso cadastrais de baixa complexidade tipicamente envolvem incluso, alterao, consulta e excluso de entidades e seguem o padro de descrio mostrado na Figura 5.6.
CRUD do ingls: Create, Read, Update and Delete; em portugus: Criar, Consultar, Atualizar e Excluir, ou seja, casos de uso que proveem as funes bsicas de manipulao de dados de uma entidade de interesse do sistema.
11
98
Fluxos de Eventos Normais Criar [Novo Objeto] O [ator] informa os dados do [novo objeto], a saber: [atributos e associaes do objeto]. Caso os dados sejam vlidos, as informaes so registradas. Alterar Dados O [ator] informa o [objeto] do qual deseja alterar dados e os novos dados. Os novos dados so validados e a alterao registrada. Consultar Dados O [ator] informa o [objeto] que deseja consultar. Os dados do [objeto] so apresentados. Excluir [Objeto] O [ator] informa o [objeto] que deseja excluir. Os dados do [objeto] so apresentados e solicitada uma confirmao. Se a excluso for confirmada, o [objeto] excludo. Fluxos de Eventos de Exceo Incluir [Novo Objeto] / Alterar Dados Dados do [objeto] invlidos: uma mensagem de erro exibida, solicitando correo da informao invlida. Figura 5.6 Padro Tpico de Descrio de Casos de Uso Cadastrais. Assim, para simplificar a descrio de casos de uso cadastrais, recomenda-se utilizar o modelo tabular mostrado na Tabela 5.1. Quando essa tabela for empregada, estar-se- assumindo que o caso de uso envolve os fluxos de eventos indicados (I para incluso, A para alterao, C para consulta e E para excluso), com a descrio base mostrada na Figura 5.5. Tabela 5.1 Modelo de Descrio de Casos de Uso Cadastrais Caso de Uso Aes Possveis Observaes Requisitos <nome do caso de uso> < I, A, C, E >
Classes
A coluna Observaes usada para listar informaes importantes relacionadas s aes, tais como os itens informados na incluso, uma restrio a ser considerada para que a excluso possa ser feita, uma informao que no pode ser alterada ou uma informao do objeto que no apresentada na consulta. Deve-se indicar antes da observao a qual ao ela se refere ([I] para incluso, [A] para alterao, [C] para consulta e [E] para excluso). As colunas Requisitos e Classes indicam, respectivamente, os requisitos que esto sendo (ou que devem ser) tratados pelo caso de uso e as classes do domnio do problema necessrias para a realizao do caso de uso. O objetivo dessas colunas manter a rastreabilidade dos casos de uso para requisitos e classes, respectivamente, de maneira anloga ao recomendado no formato completo. A Tabela 5.2 ilustra a descrio de casos de usos cadastrais do subsistema Controle de Acervo de uma videolocadora.
99
Tabela 5.2 Descrio de Casos de Uso Cadastrais Controle de Acervo de Videolocadora

Caso de Uso Cadastrar Filme Aes Possveis I, A, C, E Observaes [I] Informar: ttulo original, ttulo em portugus, pas, ano, diretores, atores, sinopse, durao, gnero, distribuidora, tipo de udio (p.ex., Dolby Digital 2.0), idioma do udio e idioma da legenda. [E] No permitida a excluso de filmes que tenham itens associados. [E] Ao excluir um filme, devem-se excluir as reservas associadas. [I] Informar: filme, tipo de mdia, data de aquisio e nmero de srie. [E] No permitido excluir um item que tenha locaes associadas. [I] Informar: razo social, CNPJ, endereo, telefone e pessoa de contato. [E] No permitido excluir uma distribuidora que tenha filmes associados. [I] Informar: nome e valor de locao. [E] No permitido excluir um tipo de mdia que tenha itens associados. [E] Ao excluir um tipo de mdia, devem-se excluir as reservas que especificam apenas esse tipo de mdia. Requisitos RF9, RNF1 Classes Filme, Distribuidora
Cadastrar Item
I, A, C, E
RF9, RNF1, RNF3 RF10, RNF1
Item, Filme, TipoMidia
Cadastrar Distribuidora
I, A, C, E
Distribuidora
Cadastrar Tipo de Mdia
I, A, C, E
RF9, RNF1
TipoMidia
Para casos de uso de consulta mais abrangente do que a consulta de um nico objeto (j tratada como parte dos casos de uso cadastrais), mas ainda de baixa complexidade (tais como consultas que combinam informaes de vrios objetos envolvendo filtros), sugere-se utilizar o formato tabular mostrado na Tabela 5.3. Tabela 5.3 Modelo de Descrio de Casos de Uso de Consulta Caso de Uso Observaes Requisitos Classes <nome do caso de uso> A coluna Observaes deve ser usada para listar informaes importantes relacionadas consulta, tais como dados que podem ser informados para a pesquisa, totalizaes feitas em relatrios etc. As colunas Requisitos e Classes tm a mesma funo de suas homnimas no modelo da Tabela 5.1, ou seja, indicam, respectivamente, os requisitos que esto sendo tratados (ou que devem ser) pelo caso de uso e as classes do domnio do problema necessrias para a realizao do mesmo. A Tabela 5.4 ilustra a descrio de um caso de usos de consulta do subsistema Controle de Acervo de uma videolocadora.
100
Tabela 5.4 Descrio de Casos de Uso de Consulta Controle de Acervo de Videolocadora

Caso de Uso Consultar Acervo Observaes Requisitos As consultas ao acervo podero ser RF11, RNF1, feitas informando uma (ou uma RNF2 combinao) das seguintes informaes: ttulo (ou parte dele), original ou em portugus, gnero, tipo de mdia disponvel, ator, diretor, nacionalidade e lanamentos. Classes Filme, Item, TipoMidia, Distribuidora
5.3.2 Descrevendo Informaes Complementares

As descries dos fluxos de eventos principal, variantes e de exceo so cruciais em uma descrio de casos de uso. Contudo, h outras informaes complementares que so bastante teis e, portanto, que devem ser levantadas e documentadas. Conforme listado no incio desta seo, so informaes complementares importantes: atores, interessados e interesses, pr-condies, ps-condies, requisitos relacionados e classes relacionadas. Conforme discutido na seo 5.1, um ator representa um papel que entidades fsicas podem desempenhar na interao com o sistema. Essas entidades fsicas so tipicamente pessoas, dispositivos ou outros sistemas que so externos ao sistema em desenvolvimento. Muitas vezes, apenas o nome de um ator, como mostrado em um diagrama de casos de uso, pode ser pouco para um real entendimento do que representa esse ator. Assim, importante que uma descrio sucinta dos atores seja feita. Uma vez que um mesmo ator pode atuar em vrios casos de uso, a descrio dos atores no deve ser feita dentro da descrio dos casos de uso, mas separada, como uma seo especfica dentro do Documento de Especificao de Requisitos. Inicialmente, atores podem ser documentados em uma tabela de duas colunas, contendo o nome e a descrio do ator. Como atores interagindo com o sistema definem as interfaces do sistema com o mundo externo, pode ser til adicionar informaes sobre o perfil do ator nessa interao. Quando o ator um ator humano, esse perfil indicaria as habilidades e a experincia do ator, informaes valiosas para o projeto da interface com o usurio. Adicionalmente, pode-se incluir uma classificao segundo aspectos como nvel de habilidade, nvel na organizao e membros em diferentes grupos. Pressman (2006) prope uma classificao que considera trs grupos principais: Usurio novato: conhece pouco a interface para utiliz-la eficientemente (conhecimento sinttico; p.ex., no sabe como atingir uma funcionalidade desejada) e entende pouco as funes e objetivos do sistema (conhece pouco a semntica da aplicao) ou no sabe bem como usar computadores em geral; Usurio conhecedor e espordico: possui um conhecimento razovel da semntica da aplicao, mas tem relativamente pouca lembrana dos mecanismos de interao providos pela interface (informaes sintticas necessrias para utilizar a interface); Usurio conhecedor e frequente: possui bom conhecimento tanto sinttico quanto semntico e buscam atalhos e modos abreviados de interao.
101
No so apenas os atores os interessados em um caso de uso. Outras pessoas ou unidades de uma organizao podem ter interesse nos resultados do caso de uso. Seja o caso de uma locadora de automveis. Em um caso de uso de locao, o nico papel a interagir com o sistema o de funcionrio do atendimento. Contudo, o cliente, o setor de preparao de automveis, a contabilidade, dentre outros, so tambm interessados neste caso de uso. Assim, mesmo que essas pessoas no interajam diretamente com o sistema para a realizao do caso de uso, elas devem ser listadas como interessados. Deve-se lembrar que o sistema deve satisfazer os interesses de todos os envolvidos, direta ou indiretamente. Assim, na seo Interessados e Interesses, deve-se listar os diversos interessados e uma descrio sucinta de seus interesses em relao execuo do caso de uso. Ao analisar esses interesses possvel, dentre outros, capturar regras de negcio e informaes e descobrir aes que o sistema tem de realizar para atender a essas expectativas, tais como validaes, atualizaes e registros. (WAZLAWICK, 2004; COCKBURN, 2005). Pr-condies estabelecem o que precisa ser verdadeiro antes de se iniciar um caso de uso. Ps-condies, por sua vez, estabelecem o que ser verdadeiro aps a execuo do caso de uso. Pr-condies precisam ser verdadeiras para que o caso de uso possa ser iniciado. No se deve confundi-las com excees. Pr-condies no so testadas durante a execuo do caso de uso (como ocorre com as condies que geram excees). Ao contrrio, elas so testadas antes de iniciar o caso de uso. Se a pr-condio falsa, ento no possvel executar o caso de uso. Para documentar as pr-condies, recomenda-se listar as condies que tm de ser satisfeitas na seo Pr-condies. Pr-condies devem ser escritas como uma simples assero sobre o estado do mundo no momento em que o caso de uso inicia (COCKBURN, 2005). Muitas vezes, uma pr-condio para ser atendida requer que um outro caso de uso j executado tenha estabelecido essa pr-condio. Contudo, um erro bastante comum escrever como uma pr-condio algo que frequentemente, mas no necessariamente, verdadeiro (COCKBURN, 2005). Seja o caso de uma locadora de vdeos em que clientes em atraso no podem locar novos itens at que regularize suas pendncias. Neste caso, uma pr-condio do tipo cliente no est em atraso como pr-condio de um caso de uso efetuar locao inadequada. Observe que a identificao do cliente parte do caso de uso efetuar locao e, portanto, no possvel garantir que o cliente no est em atraso antes de iniciar o caso de uso. Esta situao tem de ser tratada como uma exceo e no como uma pr-condio. As sees de requisitos e classes relacionados so importantes para a gerncia de requisitos. A primeira estabelece um rastro entre casos de uso e os requisitos de usurio documentados no Documento de Requisitos, permitindo, em um primeiro momento, analisar se algum requisito no foi tratado. Em um segundo momento, quando uma alterao em um requisito solicitada, possvel usar essa informao para analisar o impacto da alterao. Para documentar os requisitos relacionados, recomenda-se listar os identificadores de cada um dos requisitos na seo de Requisitos Relacionados. A seo de classes relacionadas indica quais so as classes do modelo conceitual estrutural necessrias para a realizao do caso de uso. Essa seo permite rastrear casos de uso para classes em vrios nveis, uma vez que h uma grande tendncia de as mesmas classes do modelo conceitual estrutural estarem presentes nos modelos de projeto e no cdigo-fonte. Para documentar as classes relacionadas, recomenda-se listar o nome de cada uma das classes envolvidas na seo de Classes Relacionadas. Vale ressaltar que essa informao tipicamente preenchida durante a modelagem conceitual estrutural ou at mesmo depois,
102
durante a elaborao de modelos de interao. A partir das informaes de requisitos e classes relacionados, pode-se, por exemplo, construir matrizes de rastreabilidade.
5.4 - Relacionamentos entre Casos de Uso

Para permitir uma modelagem mais apurada dos casos de uso em um diagrama, trs tipos de relacionamentos entre casos de uso podem ser empregados. Casos de uso podem ser descritos como verses especializadas de outros casos de uso (relacionamento de generalizao/ especializao); casos de uso podem ser includos como parte de outro caso de uso (relacionamento de incluso); ou casos de uso podem estender o comportamento de um outro caso de uso (relacionamento de extenso). O objetivo desses relacionamentos tornar um modelo mais compreensvel, evitar redundncias entre casos de uso e permitir descrever casos de uso em camadas. A seguir esses tipos de relacionamentos so abordados.
5.4.1 - Incluso
Uma associao de incluso de um caso de uso base para um caso de uso de incluso significa que o comportamento definido no caso de uso de incluso incorporado ao comportamento do caso de uso base. Ou seja, a relao de incluso incorpora um caso de uso (o caso de uso includo) dentro da sequncia de comportamento de outro caso de uso (o caso de uso base) (BLAHA; RUMBAUGH, 2006; OLIV, 2007). Esse tipo de associao til para extrair comportamento comum a vrios casos de uso em uma nica descrio, de modo que esse comportamento no tenha de ser descrito repetidamente. O caso de uso de incluso pode ou no ser passvel de utilizao isoladamente. Assim, ele pode ser apenas um fragmento de uma funcionalidade, no precisando ser uma transao completa. A parte comum includa por todos os casos de uso base que tm esse caso de uso de incluso em comum e a execuo do caso de uso de incluso anloga a uma chamada de subrotina (OLIV, 2007). Na UML, o relacionamento de incluso entre casos de uso mostrado como uma dependncia (seta pontilhada) estereotipada com a palavra-chave include, partindo do caso de uso base para o caso de uso de incluso, como ilustra a Figura 5.6.
Figura 5.6 Associao de Incluso na UML Uma associao de incluso deve ser referenciada tambm na descrio do caso de uso base. O local em que esse comportamento includo deve ser indicado na descrio do caso de uso base, atravs de uma referncia explcita chamada ao caso de uso includo. Assim, a descrio do fluxo de eventos (principal ou alternativo) do caso de uso base deve conter um passo que envolva a chamada ao caso de uso includo, referenciada por Incluir nome do caso de uso includo. Para destacar referncias de um caso de uso para outro, sugere-se que o nome do caso de uso referenciado seja sublinhado e escrito em itlico.
103
No exemplo do caixa automtico, todos os trs casos de uso tm em comum uma poro que diz respeito validao inicial do carto. Neste caso, um relacionamento de incluso deve ser empregado, conforme mostra a Figura 5.7.
Figura 5.7 - Diagrama de Casos de Uso Caixa Automtico com Incluso. O caso de uso Validar Carto extrai o comportamento descrito na Figura 5.8. Ao isolar este comportamento no caso de uso de Validar Cliente, o caso de uso Efetuar Saque passaria a apresentar a descrio mostrada na Figura 5.9. Deve-se observar que no necessariamente o comportamento do caso de uso includo precisa ser executado todas as vezes que o caso de uso base realizado. Assim, possvel que a incluso esteja associada a alguma condio. O caso de uso includo inserido em um local especfico dentro da sequncia do caso de uso base, da mesma forma que uma subrotina chamada de um local especfico dentro de outra subrotina (BLAHA; RUMBAUGH, 2006).
104
Nome: Validar Carto Fluxo de Eventos Normal 1. 2. 3. 4. 5. O cliente insere o carto no caixa automtico. O caixa automtico analisa o carto e verifica se ele aceitvel. O caixa automtico solicita que o cliente informe a senha. O cliente informa a senha. O caixa automtico envia os dados do carto e da senha para o sistema bancrio para validao. 6. O caixa automtico solicita que o cliente informe o tipo de transao a ser efetuada. Fluxos de Eventos de Exceo 2a O carto no aceitvel: Se o carto no aceitvel, seja porque sua tarja magntica no passvel de leitura seja porque de um tipo incompatvel, uma mensagem de erro de leitura mostrada e se retorna ao passo 1. 5a Senha incorreta: 5a.1 1 e 2 tentativas: Uma mensagem de erro mostrada para o cliente. Retornar ao passo 3. 5a.2 3 tentativa: bloquear o carto e abortar a transao. 1 a 5: Cancelamento: O cliente solicita o cancelamento da transao e a transao abortada. Figura 5.8 Descrio do Caso de Uso Validar Carto Nome: Efetuar Saque Fluxo de Eventos Normal 1. 2. 3. 4. 5. Incluir Validar Carto. O cliente seleciona a opo saque. O caixa automtico solicita que seja informada a quantia. O cliente informa a quantia a ser sacada. O caixa automtico envia uma requisio para o sistema bancrio para que seja efetuado um saque na quantia especificada. 6. As notas so preparadas e liberadas. Fluxos de Eventos de Exceo 5a - Saque no autorizado: Uma mensagem de erro exibida e a operao abortada. 6a - No h dinheiro suficiente disponvel no caixa eletrnico: Uma mensagem de erro exibida e a operao abortada. 1 a 3: Cancelamento: O cliente pode cancelar a transao, enquanto o saque no for autorizado pelo sistema bancrio. A transao abortada. Figura 5.9 Descrio do Caso de Uso Efetuar Saque com incluso. Por fim, importante frisar que no h um consenso sobre a possibilidade (ou no) de um caso de uso includo poder ser utilizado isoladamente. Diversos autores, dentre eles Oliv (2007) e Blaha e Rumbaugh (2006), admitem essa possibilidade; outros no. Em (BOOCH; RUMBAUGH; JACOBSON, 2006), diz-se explicitamente que um caso de uso includo
105
nunca permanece isolado, mas apenas instanciado como parte de alguma base maior que o inclui. Neste texto, admitimos a possibilidade de um caso de uso includo poder ser utilizado isoladamente, pois isso permite representar situaes em que um caso de uso chama outro caso de uso (como uma chamada de subrotina), mas este ltimo pode tambm ser realizado isoladamente. A Figura 5.10 ilustra uma situao bastante comum, em que, ao se realizar um processo de negcio (no caso a reserva de um carro em um sistema de locao de automveis), caso uma informao necessria para esse processo (no caso o cliente) no esteja disponvel, ela pode ser inserida no sistema. Contudo, o cadastro da informao tambm pode ser feito dissociado do processo de negcio que o inclui (no caso, o cliente pode se cadastrar fora do contexto da reserva de um carro). Ao no se admitir a possibilidade de um caso de uso includo poder ser utilizado isoladamente, no possvel modelar situaes desta natureza, as quais so bastante frequentes.
Figura 5.10 Exemplo de Associao de Incluso.
5.4.2 - Extenso
Uma associao de extenso entre um caso de uso de extenso e um caso de uso base significa que o comportamento definido no caso de uso de extenso pode ser inserido dentro do comportamento definido no caso de uso base, em um local especificado indiretamente pelo caso de uso de extenso. A extenso ocorre em um ou mais pontos de extenso especficos definidos no caso de uso base. A extenso pode ser condicional. Neste caso, a extenso ocorre apenas se a condio verdadeira quando o ponto de extenso especificado atingido. O caso de uso base definido de forma independente do caso de uso de extenso e significativo independentemente do caso de uso de extenso (OLIV, 2007; BOOCH; RUMBAUGH; JACOBSON, 2006). Um caso de uso pode ter vrios pontos de extenso e esses pontos so referenciados por seus nomes (BOOCH; RUMBAUGH; JACOBSON, 2006). O caso de uso base apenas indica seus pontos de extenso. O caso de uso de extenso especifica em qual ponto de extenso ele ser inserido. Por isso, diz-se que o caso de uso de extenso especifica indiretamente o local onde seu comportamento ser inserido. A associao de extenso como uma relao de incluso olhada da direo oposta, em que a extenso se incorpora ao caso de uso base, em vez de o caso de uso base incorporar explicitamente a extenso. Ela conecta um caso de uso de extenso a um caso de uso base. O caso de uso de extenso geralmente um fragmento, ou seja, ele no aparece sozinho como uma sequncia de comportamentos. Alm disso, na maioria das vezes, a relao de extenso possui uma condio associada e, neste caso, o comportamento de extenso ocorre apenas se a condio for verdadeira. O caso de uso base, por sua vez, precisa ser, obrigatoriamente, um caso de uso vlido na ausncia de quaisquer extenses (BLAHA; RUMBAUGH, 2006).
106
Na UML, a associao de extenso entre casos de uso mostrada como uma dependncia (seta pontilhada) estereotipada com a palavra chave extend, partindo do caso de uso de extenso para o caso de uso base, como ilustra a Figura 5.11. Pontos de extenso podem ser indicados no compartimento da elipse do caso de uso, denominado extension points (pontos de extenso). Opcionalmente, a condio a ser satisfeita e a referncia ao ponto de extenso podem ser mostradas por meio de uma nota12 anexada associao de extenso (OLIV, 2007). Assim, no exemplo da Figura 5.11, o Caso de Uso de Extenso 1 executado quando o ponto de extenso 1 do Caso de Uso Base for atingido, se a condio for verdadeira.
Figura 5.11 Associao de Extenso na UML Uma importante diferena entre as associaes de incluso e extenso que, na primeira o caso de uso base est ciente do caso de uso de incluso, enquanto na segunda o caso de uso base no est ciente dos possveis casos de uso de extenso (OLIV, 2007). Assim como no caso da incluso, uma associao de extenso deve ser referenciada na descrio do caso de uso base. Neste caso, contudo, o caso de uso base apenas aponta o ponto de extenso, sem fazer uma referncia explcita ao caso de uso de extenso. O local de cada um dos pontos de extenso deve ser indicado na descrio do caso de uso base, atravs de uma referncia ao nome do ponto de extenso seguido de : ponto de extenso. Assim, a descrio do fluxo de eventos (principal ou alternativo) do caso de uso base deve conter indicaes explcitas para cada ponto de extenso. No exemplo do caixa automtico, suponha que se deseja coletar dados estatsticos sobre os valores das notas entregues nos saques, de modo a permitir alimentar o caixa eletrnico com as notas mais adequadas para saque. Poder-se-ia, ento, estender o caso de uso Efetuar Saque, de modo que, quando necessrio, outro caso de uso, denominado Coletar Estatsticas de Notas, contasse e acumulasse o tipo das notas entregues em um saque, conforme mostra a Figura 5.12. A Figura 5.13 mostra a descrio do caso de uso Efetuar Saque indicando o ponto de extenso entrega do dinheiro.
Nota o nico item de anotao da UML. Notas so usadas para explicar partes de um modelo da UML. So comentrios includos para descrever, esclarecer ou fazer alguma observao sobre qualquer elemento do modelo. Assim, uma nota apenas um smbolo para representar restries e comentrios anexados a um elemento ou a uma coleo de elementos. Graficamente, uma nota representada por um retngulo com um dos cantos com uma dobra de pgina, acompanhado por texto e anexada ao(s) elemento(s) anotados por meio de linha(s) pontilhada(s) (BOOCH; RUMBAUGH; JACOBSON, 2006). No exemplo da Figura 5.11, a nota est anexada ao relacionamento de extenso, adicionando-lhe informaes sobre o ponto de extenso e a condio associados extenso.
12
107
Figura 5.12 - Diagrama de Casos de Uso Caixa Automtico com Extenso. Nome: Efetuar Saque Fluxo de Eventos Normal 1. 2. 3. 4. 5. Incluir Validar Carto. O cliente seleciona a opo saque. O caixa automtico solicita que seja informada a quantia. O cliente informa a quantia a ser sacada. O caixa automtico envia uma requisio para o sistema bancrio para que seja efetuado um saque na quantia especificada. 6. As notas so preparadas. entrega do dinheiro: ponto de extenso. 7. As notas so liberadas Fluxos de Eventos de Exceo 5a - Saque no autorizado: Uma mensagem de erro exibida e a operao abortada. 6a - No h dinheiro suficiente disponvel no caixa eletrnico: Uma mensagem de erro exibida e a operao abortada. 1 a 3: Cancelamento: O cliente pode cancelar a transao, enquanto o saque no for autorizado pelo sistema bancrio. A transao abortada. Figura 5.13 Descrio do Caso de Uso Efetuar Saque com extenso.
108
5.4.3 Generalizao / Especializao

Um relacionamento de generalizao / especializao entre um caso de uso pai e um caso de uso filho significa que o caso de uso filho herda o comportamento e o significado do caso de uso pai, acrescentando ou sobrescrevendo seu comportamento (OLIV, 2007; BOOCH; RUMBAUGH; JACOBSON, 2006). Na UML, relacionamentos de generalizao / especializao so representados como uma linha cheia direcionada com uma seta aberta (smbolo de herana), como ilustra a Figura 5.14.
Figura 5.14 Associao de Generalizao / Especializao entre Casos de Uso na UML Voltando ao exemplo do sistema de caixa automtico, suponha que haja duas formas adotadas para se validar o carto: a primeira atravs de senha, como descrito anteriormente, e a segunda por meio de anlise da retina do cliente. Neste caso, poderiam ser criadas duas especializaes do caso de uso Validar Cliente, como mostra a Figura 5.15.
Figura 5.15 Exemplo de Generalizao / Especializao entre Casos de Uso A descrio do caso de uso pai teria de ser generalizada para acomodar diferentes tipos de validao. Esses tipos de validao seriam especializados nas descries dos casos de uso filhos. A Figura 5.16 mostra as descries desses trs casos de uso. A generalizao / especializao aplicvel quando um caso de uso possui diversas variaes. O comportamento comum pode ser modelado como um caso de uso abstrato e especializado para as diferentes variaes (BLAHA; RUMBAUGH, 2006). Contudo, avalie se no fica mais simples e direto descrever essas variaes como fluxos alternativos variantes na descrio de casos de uso. Quando forem poucas e pequenas as variaes, muito provavelmente ser mais fcil captur-las na descrio, ao invs de criar hierarquias de casos de uso. A Figura 5.17 mostra uma soluo anloga da Figura 5.16, sem usar, no entanto, especializaes do caso de uso.
109
Nome: Validar Carto Fluxo de Eventos Normal 1. O cliente insere o carto no caixa automtico. 2. O caixa automtico analisa o carto e verifica se ele aceitvel. 3. O caixa automtico solicita informao para identificao do cliente. 4. O cliente informa sua identificao. 5. O caixa automtico envia os dados do carto e da identificao para o sistema bancrio para validao. 6. O caixa automtico solicita que o cliente informe o tipo de transao a ser efetuada. Fluxos de Eventos de Exceo 2a O carto no aceitvel: Se o carto no aceitvel, seja porque sua tarja magntica no passvel de leitura seja porque de um tipo incompatvel, uma mensagem de erro de leitura mostrada e se retorna ao passo 1. 5a Dados de Identificao Incorretos: 5a.1 1 e 2 tentativas: Uma mensagem de erro mostrada para o cliente. Retornar ao passo 3. 5a.2 3 tentativa: bloquear o carto e abortar a transao. 1 a 5: Cancelamento: O cliente solicita o cancelamento da transao e a transao abortada. Nome: Validar Carto por Anlise de Retina Fluxo de Eventos Normal 3. O caixa automtico solicita que o cliente se posicione corretamente para a captura da imagem da retina. 4. O caixa automtico retira uma foto da retina do cliente. 5. O caixa automtico envia os dados do carto e a foto da retina para o sistema bancrio para validao. Nome: Validar Carto por Autenticao de Senha Fluxo de Eventos Normal 3. O caixa automtico solicita a senha. 4. O cliente informa a senha. 5. O caixa automtico envia os dados do carto e a senha para o sistema bancrio para validao. Figura 5.16 Descrio do Caso de Uso Validar Carto e suas Especializaes.
110
Nome: Validar Carto Fluxo de Eventos Normal 1. O cliente insere o carto no caixa automtico. 2. O caixa automtico analisa o carto e verifica se ele aceitvel. 3. Validar carto. 4. O caixa automtico solicita que o cliente informe o tipo de transao a ser efetuada. Fluxos de Eventos Variantes 3a Validar carto por autenticao de senha: 3a.1 O caixa automtico solicita a senha. 3a.2 O cliente informa a senha. 3a.3 O caixa automtico envia os dados do carto e a senha para o sistema bancrio para validao. 3b Validar carto por anlise de retina: 3b.1 O caixa automtico solicita que o cliente se posicione corretamente para a captura da imagem da retina. 3b.2 O caixa automtico retira uma foto da retina do cliente. 3b.3 O caixa automtico envia os dados do carto e a foto da retina para o sistema bancrio para validao. Fluxos de Eventos de Exceo 2a O carto no aceitvel: Se o carto no aceitvel, seja porque sua tarja magntica no passvel de leitura seja porque de um tipo incompatvel, uma mensagem de erro de leitura mostrada e se retorna ao passo 1. 5a Dados de Identificao Incorretos: 5a.1 1 e 2 tentativas: Uma mensagem de erro mostrada para o cliente. Retornar ao passo 3. 5a.2 3 tentativa: bloquear o carto e abortar a transao. 1 a 5: Cancelamento: O cliente solicita o cancelamento da transao e a transao abortada. Figura 5.17 Descrio do Caso de Uso Validar Carto com Variantes.
111
5.4.4 Diretrizes para o Uso dos Tipos de Relacionamentos entre Casos de Uso
Os relacionamentos entre casos de uso devem ser utilizados com cuidado para evitar a introduo de complexidade desnecessria. As seguintes orientaes so teis para ajudar a decidir quando usar relacionamentos entre casos de uso em um diagrama de casos de uso: A incluso tipicamente aplicvel quando se deseja capturar um fragmento de comportamento comum a vrios casos de uso. Na maioria das vezes, o caso de uso de incluso uma atividade significativa, mas no como um fim em si mesma (BLAHA; RUMBAUGH, 2006). Ou seja, o caso de uso de incluso no precisa ser uma transao completa. Um relacionamento de incluso empregado quando h uma poro de comportamento que similar ao longo de um ou mais casos de uso e no se deseja repetir a sua descrio. Para evitar redundncia e assegurar reso, extrai-se essa descrio e se compartilha a mesma entre diferentes casos de uso.Desta maneira, utiliza-se a incluso para evitar ter de descrever o mesmo fragmento de comportamento vrias vezes, capturando o comportamento comum em um caso de uso prprio (BOOCH; RUMBAUGH; JACOBSON, 2006). No se deve utilizar o relacionamento de generalizao / especializao para compartilhar fragmentos de comportamento. Para este propsito, deve-se usar a relao de incluso (BLAHA; RUMBAUGH, 2006). A relao de extenso bastante til em situaes em que se pode definir um caso de uso significativo com recursos adicionais. O comportamento bsico capturado no caso de uso base e os recursos adicionais nos casos de uso de extenso. Use a relao de extenso quando o sistema puder ser usado em diferentes configuraes, algumas com os recursos adicionais e outras sem eles (BLAHA; RUMBAUGH, 2006). Tanto a incluso quanto a extenso podem ser usadas para dividir o comportamento em partes menores. A incluso, entretanto, implica que o comportamento includo uma parte necessria de um sistema configurado, mesmo que seu comportamento no seja executado todas as vezes, ou seja, mesmo que o comportamento includo esteja associado a uma condio. A extenso, por sua vez, implica que o sistema sem o comportamento adicionado pela extenso significativo (BLAHA; RUMBAUGH, 2006).
5.5 Trabalhando com Casos de Uso

Para se utilizar a modelagem de casos de uso para o refinamento de requisitos de usurio em requisitos de sistema necessrio proceder um exame detalhado do processo de negcio a ser apoiado pelo sistema. Assim, atividades de levantamento de requisitos, como entrevistas, observao, workshop de requisitos e cenrios, dentre outras, certamente acontecero em paralelo com a modelagem de casos de uso. Uma boa maneira de trabalhar com casos de uso consiste em, a partir dos requisitos funcionais de usurio descritos no Documento de Requisitos, procurar derivar casos de uso. Este apenas um ponto de partida, uma vez que vrios casos de uso podem ser derivados a partir de um mesmo requisito funcional de usurio.
112
Uma maneira complementar de identificar casos de uso comear pela identificao de atores. Cada ator deve ter um propsito nico e coerente, o qual deve ser descrito e documentado. Para cada ator identificado, pode-se, ento, levantar quais so as funcionalidades por ele requeridas, listando-as na forma de casos de uso. Cada caso de uso deve representar uma transao completa que seja algo de valor para os atores envolvidos. Contudo, antes de identificar atores e casos de uso, necessrio determinar claramente os limites do sistema. Sem deixar claro quais so os limites do sistema, muito difcil identificar atores ou casos de uso (BLAHA; RUMBAUGH, 2006). Uma vez identificados atores e casos de uso, pode-se elaborar uma verso preliminar do diagrama de casos de uso. Vale lembrar que, at mesmo para sistemas de pequeno porte, til trabalhar com subsistemas, procurando agrupar casos de uso em pacotes. Assim, importante procurar agrupar casos de uso relacionados em pacotes, construindo tambm diagramas de pacotes medida que os casos de uso vo sendo agrupados. Uma vez identificados e agrupados os casos de uso, interessante fazer uma descrio sucinta de seu propsito. No se deve partir diretamente para os detalhes, descrevendo fluxos de eventos e outras informaes. Fazendo apenas uma descrio sucinta, possvel levar mais rapidamente os casos de uso discusso com os clientes e usurios, permitindo identificar melhor quais so efetivamente os casos de uso a serem contemplados pelo sistema. Alm disso, pode-se dividir o trabalho, designando diferentes analistas para trabalhar com casos de uso (ou pacotes) especficos. Somente ento se deve passar para a descrio detalhada dos casos de uso. Inicialmente, o foco deve ser no fluxo de eventos principal, ou seja, aquele em que tudo d certo na interao. Depois de descrever o fluxo de eventos normal, deve-se analisar de forma crtica cada passo desses fluxos de eventos, procurando verificar o que pode dar errado (WAZLAWICK, 2004), bem como se devem investigar maneiras alternativas, ainda normais, de realizar o caso de uso, permitindo a identificao de fluxos variantes. A partir da identificao de possveis excees e variaes, deve-se trabalhar na descrio de fluxos alternativos de exceo (descrevendo procedimentos para contornar os problemas) e variantes (descrevendo maneiras alternativas de realizar com sucesso uma certa poro do caso de uso). Assim, uma maneira adequada para trabalhar com casos de uso consiste em identificlos, model-los e descrev-los com diferentes nveis de preciso. O seguinte processo resume a abordagem descrita anteriormente: 1. Listar atores e casos de uso relacionados: neste momento, montada apenas uma lista dos atores associados aos casos de uso de seu interesse. Apenas o nome do caso de uso indicado. 2. Para cada caso de uso identificado, fazer uma descrio sucinta do mesmo. Essa descrio deve conter, em essncia, o objetivo do caso de uso. 3. Elaborar um ou mais diagramas de casos de uso. 4. Revisar a exatido e a completude do conjunto de casos de uso com os interessados e priorizar os casos de uso. 5. Definir o formato de descrio de caso de uso a ser usado (e o correspondente modelo de descrio de caso de uso a ser adotado) para cada caso de uso.
113
6. Definir os fluxos de eventos principais a serem comportados pelo caso de uso: de maneira anloga ao passo 1, apenas uma lista dos fluxos de eventos principais elaborada, sem descrev-los ainda. 7. Descrever cada um dos fluxos principais de eventos do caso de uso, segundo o modelo de descrio de caso de uso estabelecido no passo anterior. De acordo com o modelo predefinido, levantar informaes adicionais como pr-condies e requisitos relacionados. 8. Identificar fluxos alternativos: neste momento, levantada apenas uma lista de excees e variaes que podem ocorrer no fluxo principal de eventos do caso de uso, sem no entanto definir como o sistema deve trat-las. 9. Descrever os passos dos fluxos alternativos: descrever como o sistema deve responder a cada exceo ou como ele deve funcionar em cada variao. Vale ressaltar que a descrio de casos de uso na fase de anlise de requisitos deve ser feita sem considerar a tecnologia de interface. Neste momento no interessa saber a forma das interfaces do sistema, mas quais informaes so trocadas entre o sistema e o ambiente externo (atores). O analista deve procurar abstrair a tecnologia e se concentrar na essncia das informaes trocadas. Assim, diz-se que a descrio de caso de uso na fase de anlise uma descrio essencial. A tecnologia de interface ser objeto da fase de projeto do sistema. Agindo dessa maneira, abre-se caminho para se pensar em diferentes alternativas de interfaces durante o projeto do sistema (WAZLAWICK, 2004). Uma tcnica de levantamento de requisitos bastante til para apoiar a escrita de casos de uso so os cenrios. Pode-se pedir para que o usurio descreva alguns cenrios na forma de exemplos situados de um caso de uso em ao, mostrando o ator usando o sistema para realizar o caso de uso em questo (COCKBURN, 2005). Um cenrio uma sequncia especfica de aes que ilustra o comportamento de um caso de uso. Assim, os cenrios so, na verdade, instncias de um caso de uso. Os modelos de casos de uso so uma maneira eficaz para analistas, clientes, especialistas de domnio e usurios chegarem a uma compreenso comum acerca das funcionalidades que o sistema deve prover. Alm disso, servem para ajudar a verificar e validar o sistema medida que ele vai sendo desenvolvido. Neste contexto, os casos de uso podem ser utilizados como base para o projeto de casos de teste para o sistema, em uma abordagem de testes baseada em casos de uso, na qual casos de teste so projetados a partir dos fluxos de eventos principal e alternativos dos casos de uso, procurando explorar diferentes cenrios de uso do sistema. No contexto da Engenharia de Requisitos, casos de uso tm dois importantes papis: Casos de uso especificam os requisitos funcionais de um sistema. Um modelo de caso de uso descreve detalhadamente o comportamento de um sistema atravs de um conjunto de casos de uso. O ambiente do sistema definido pela descrio dos diferentes atores que utilizam o sistema realizando os casos de uso. Casos de uso oferecem uma abordagem para a modelagem de sistemas. Para gerenciar a complexidade de sistemas reais, comum apresentar os modelos do sistema em um nmero de diferentes vises. Em uma abordagem guiada por casos de uso, pode-se construir uma viso para cada caso de uso, isto , em cada viso so modelados apenas aqueles elementos que participam de um caso de uso especfico.
114
Essa abordagem especialmente til para a modelagem comportamental feita utilizando diagramas de atividade e de sequncia. Um particular elemento (uma classe, p.ex.) pode, claro, participar de vrios casos de uso. Isto significa que um modelo do sistema completo s visto atravs de um conjunto de vises. Para se definir todas as responsabilidades de um elemento, deve-se olhar os casos de uso onde esse elemento tem um papel. importante destacar que a modelagem casos de uso pode (e deve) ser realizada com algum grau de paralelismo em relao modelagem conceitual estrutural. A identificao de conceitos relevantes para tratar um caso de uso pode ajudar a descobrir outros casos de uso relevantes, sobretudo de natureza cadastral. Assim, uma vez iniciada a descrio dos casos de uso, a modelagem conceitual estrutural pode ser tambm iniciada. Alm de serem uma ferramenta essencial na especificao dos requisitos funcionais de um sistema, casos de uso tm um papel fundamental no planejamento e controle de projetos iterativos. Casos de uso podem ser usados para definir o escopo de uma iterao do projeto ou mesmo do projeto como um todo. Neste contexto, uma tcnica interessante para administrar discusses de escopo so as listas dentro / fora (COCKBURN, 2005). Uma lista dentro / fora , na verdade, uma tabela com trs colunas. A primeira coluna enumera casos de uso; as duas outras colunas so rotuladas Dentro e Fora. Sempre que no for claro se um caso de uso est dentro ou fora do escopo da discusso (projeto ou iterao), ele includo na tabela e deve-se perguntar aos interessados se o caso de uso est dentro ou fora do escopo. Assim, possvel capturar as diferentes vises dos diferentes interessados, sendo essas vises muitas vezes conflitantes. Identificados conflitos, os mesmos devem ser negociados e resolvidos. Ainda no que se refere ao planejamento e controle de projetos iterativos, pode ser uma boa estratgia priorizar os casos de uso, de modo a definir o que considerar ou no em uma iterao (ou mesmo no projeto). Para os casos de uso considerados dentro do escopo do projeto, pode-se indicar em qual verso o caso de uso deveria ser tratado. Por exemplo, se foram planejados trs iteraes para o desenvolvimento de um certo sistema, os interessados poderiam indicar em qual verso (1, 2 ou 3) cada caso de uso deveria ser tratado. Essas listas de prioridades so usadas como ponto de partida para a negociao e o planejamento das iteraes do projeto. Leitura Complementar Os captulos 7 e 8 de (BLAHA; RUMBAUGH, 2006) Modelagem de Interaes e Modelagem Avanada de Interaes, respectivamente abordam a modelagem de casos de uso. Mais especificamente, recomenda-se a leitura da seo 7.1 (Modelos de Casos de Uso), que d uma viso geral de atores, casos de uso e diagramas de casos de uso, e da seo 8.1 (Relaes entre Casos de Uso), que discute as relaes de incluso, extenso e generalizao e especializao entre casos de uso. O Captulo 15 de (OLIV, 2007) Use Cases d uma viso geral da modelagem de casos de uso, discutindo de maneira breve, mas bastante didtica, os conceitos de ator e de caso de uso, a especificao de casos de uso e os relacionamentos entre casos de uso. O livro Escrevendo Casos de Uso Eficazes: Um guia prtico para desenvolvedores de software (COCKBURN, 2005) inteiramente dedicado ao processo de escrita de casos de uso. Esse livro uma tima referncia para os interessados em aperfeioar seu processo de escrita de casos de uso, contendo diversas diretrizes incorporadas nestas notas de aula.
115
Em (WAZLAWICK, 2004), tanto o Captulo 2 (Concepo) quanto o Captulo 3 (Expanso dos Casos de Uso) abordam a modelagem de casos de uso. Em (BOOCH; RUMBAUGH; JACOBSON, 2006), merecem ateno os captulos 17 (Casos de Uso) e 18 (Diagramas de Casos de Uso). As notaes da UML para diagramas de casos de uso so tratadas com mais detalhes do que nas demais referncias citadas anteriormente, precisamente por se tratar este de um livro sobre a UML. Referncias do Captulo BLAHA, M., RUMBAUGH, J., Modelagem e Projetos Baseados em Objetos com UML 2, Elsevier, 2006. BOOCH, G., RUMBAUGH, J., JACOBSON, I., UML Guia do Usurio, 2a edio, Elsevier Editora, 2006. COCKBURN, A., Escrevendo Casos de Uso Eficazes: Um guia prtico para desenvolvedores de software, Porto Alegre: Bookman, 2005. OLIV, A., Conceptual Modeling of Information Systems, Springer, 2007. WAZLAWICK, R.S., Anlise e Projeto de Sistemas de Informao Orientados a Objetos, Elsevier, 2004.
Captulo 6 Modelagem Conceitual Estrutural
116

Um modelo conceitual estrutural uma abstrao da realidade segundo uma conceituao. Ele pode ser usado para comunicao, aprendizado e anlise de aspectos relevantes do domnio subjacente (GUIZZARDI, 2005). O modelo conceitual estrutural de um sistema tem por objetivo descrever as informaes que esse sistema deve representar e gerenciar. A modelagem conceitual a atividade de descrever alguns dos aspectos do mundo fsico e social a nossa volta, com o propsito de entender e comunicar. Os modelos resultantes das atividades de modelagem conceitual so essencialmente destinados a serem usados por pessoas e no por mquinas (MYLOPOULOS, 1992). Assim, modelos conceituais devem ser concebidos com foco no domnio do problema e no no domnio da soluo e, por conseguinte, um modelo conceitual estrutural um artefato do domnio do problema e no do domnio da soluo. As informaes a serem capturadas em um modelo conceitual estrutural devem existir independentemente da existncia de um sistema computacional para trat-las. Assim, o modelo conceitual deve ser independe da soluo computacional a ser adotada para resolver o problema e deve conter apenas os elementos de informao referentes ao domnio do problema em questo. Elementos da soluo, tais como interfaces, formas de armazenamento e comunicao, devem ser tratados apenas na fase de projeto (WAZLAWICK, 2004). Uma vez que requisitos no-funcionais de produto (atributos de qualidade) so inerentes soluo computacional, geralmente eles no so tratados na modelagem conceitual. Ou seja, no se consideram elementos de informao para tratar aspectos como desempenho, segurana de acesso, confiabilidade, formas de armazenamento etc. Esses atributos de qualidade do produto so considerados posteriormente, na fase de projeto. Os elementos de informao bsicos da modelagem conceitual estrutural so os tipos de entidades e os tipos de relacionamentos. A identificao de quais os tipos de entidades e os tipos de relacionamentos que so relevantes para um particular sistema de informao uma meta crucial da modelagem conceitual (OLIV, 2007). Na modelagem conceitual segundo o paradigma orientado a objetos, tipos de entidades so modelados como classes. Tipos de relacionamentos so modelados como atributos e associaes. Assim, o propsito da modelagem conceitual estrutural orientada a objetos definir as classes, atributos e associaes que so relevantes para tratar o problema a ser resolvido. Para tal, as seguintes tarefas devem ser realizadas: Identificao de Classes Identificao de Atributos e Associaes Especificao de Hierarquias de Generalizao/Especializao
117
importante notar que essas atividades so dependentes umas das outras e que, durante o desenvolvimento, elas so realizadas, tipicamente, de forma paralela e iterativa, sempre visando ao entendimento do domnio do problema, desconsiderando aspectos de implementao. Este captulo aborda a modelagem conceitual estrutural, discutindo os principais aspectos dessa importante tarefa, quando realizada segundo o paradigma orientado a objetos. A seo 6.1 discute o processo de identificao de classes. A seo 6.2 aborda a identificao de atributos e associaes. Finalmente, a seo 6.3 discute a especificao de hierarquias de generalizao / especializao.
6.1 Identificao de Classes

Classificao o meio pelo qual os seres humanos estruturam a sua percepo do mundo e seu conhecimento sobre ele. Sem ela, no possvel nem entender o mundo a nossa volta nem agir sobre ele. Classificao assume a existncia de tipos e de objetos a serem classificados nesses tipos. Classificar consiste, ento, em determinar se um objeto ou no uma instncia de um tipo. A classificao nos permite estruturar conhecimento sobre as coisas em dois nveis: tipos e instncias. No nvel de tipos, procuramos encontrar as propriedades comuns a todas as instncias de um tipo. No nvel de instncia, procuramos identificar o tipo do qual o objeto uma instncia e os valores particulares das propriedades desse objeto (OLIV, 2007). Tipos de entidade so um dos mais importantes elementos em modelos conceituais. Definir os tipos de entidade relevantes para um particular sistema de informao uma tarefa crucial na modelagem conceitual. Um tipo de entidade pode ser definido como um tipo cujas instncias em um dado momento so objetos individuais identificveis que se consideram existir no domnio naquele momento. Um objeto pode ser instncia de vrios tipos ao mesmo tempo (OLIV, 2007). Por exemplo, seja o caso dos tipos Estudante e Funcionrio em um sistema de uma universidade. Uma mesma pessoa, por exemplo Joo, pode ser ao mesmo tempo um estudante e um funcionrio dessa universidade. Na orientao a objetos, tipos de entidade so representados por classes, enquanto as instncias de um tipo de entidade so objetos. Assim, uma atividade crucial da modelagem conceitual estrutural segundo o paradigma orientado a objetos (OO) a identificao de classes. Na UML, classes so representadas por um retngulo com trs compartimentos: o compartimento superior relativo ao nome da classe; o compartimento do meio dedicado especificao dos atributos da classe; e o compartimento inferior dedicado especificao das operaes da classe. A Figura 6.1 mostra a notao de classe na UML.
Figura 6.1 Notao de Classes na UML. Para nomear classes, sugere-se iniciar com um substantivo no singular, o qual pode ser combinado com complementos ou adjetivos, omitindo-se preposies. O nome da classe deve ser iniciado com letra maiscula, bem como os nomes dos complementos, sem dar um espao
118
em relao palavra anterior. Acentos no devem ser utilizados. Ex.: Cliente, PessoaFisica, ItemPedido. Tomando por base os requisitos iniciais do usurio e, sobretudo, o modelo de casos de uso, possvel iniciar o trabalho de modelagem da estrutura do sistema. Esse trabalho comea com a descoberta de quais classes devem ser includas no modelo. O cerne de um modelo OO exatamente o seu conjunto de classes. Durante a anlise de requisitos, tipicamente o analista estuda, filtra e modela o domnio do problema. Dizemos que o analista filtra o domnio, pois apenas uma parte desse domnio far parte das responsabilidades do sistema. Assim, um domnio de problemas pode incluir vrias informaes, mas as responsabilidades de um sistema nesse domnio podem incluir apenas uma pequena parcela deste conjunto. As classes de um modelo representam a expresso inicial do sistema. As atividades subsequentes da modelagem estrutural buscam obter uma descrio cada vez mais detalhada, em termos de associaes e atributos. Contudo, deve-se observar que, medida que atributos e associaes vo sendo identificados, se ganha maior entendimento a respeito do domnio e naturalmente novas classes surgem. Assim, as atividades da modelagem conceitual so iterativas e com alto grau de paralelismo, devendo ser realizadas concomitantemente. Um aspecto fundamental no processo de modelagem conceitual a interao constante com os especialistas de domnio. Tcnicas de levantamento de requisitos, tais como entrevistas, anlise de documentos e reunies JAD, tm um papel fundamental nesta etapa. Assim, o levantamento de requisitos continua acontecendo paralelamente modelagem conceitual. Conforme apontado anteriormente, dois importantes insumos para a atividade de identificao de classes so o Documento de Requisitos e o Modelo de Casos de Uso. Uma maneira bastante prtica e eficaz de trabalhar a identificao de classes consiste em olhar esses dois documentos, em especial a descrio do minimundo e as descries de casos de uso, procura de classes. Diversos autores, dentre eles Jacobson (1992) e Wazlawick (2004), sugerem que uma boa estratgia para identificar classes consiste em ler esses documentos procurando por substantivos. Esses autores argumentam que uma classe , tipicamente, descrita por um nome no domnio e, portanto, aprender sobre a terminologia do domnio do problema um bom ponto de partida. Ainda que um bom ponto de partida, essa heurstica ainda muito vaga. Se o analista segui-la fielmente, muito provavelmente ele ter uma extensa lista de potenciais classes, sendo que muitas delas podem, na verdade, se referir a atributos de outras classes. Alm disso, pode ser que importantes classes no sejam capturadas, notadamente aquelas que se referem ao registro de eventos de negcio, uma vez que esses eventos muitas vezes so descritos na forma de verbos. Seja o seguinte exemplo de uma descrio de um domnio de locao de automveis: clientes locam carros. Seriam consideradas potenciais classes: Cliente e Carro. Contudo, a locao um evento de negcio importante que precisa ser registrado e, usando a estratgia de identificar classes a partir de substantivos, Locao no entraria na lista de potenciais classes. Assim, neste texto sugere-se que, ao examinar documentos de requisitos e modelos de casos de uso, os seguintes elementos sejam considerados como candidatos a classes: Agentes: entidades do domnio do problema que tm a capacidade de agir com inteno de atingir uma meta. Em sistemas de informao, h dois tipos principais
119
de agentes: os agentes fsicos (tipicamente pessoas) e os agentes sociais (organizaes, unidades organizacionais, sociedades etc.). Em relao s pessoas, deve-se olhar para os papis desempenhados pelas diferentes pessoas no domnio do problema. Objetos: entidades sem a capacidade de agir, mas que fazem parte do domnio de informao do problema. Podem ser tambm classificados em fsicos (p.ex., carros, livros, imveis) e sociais (p.ex., cursos, disciplinas, leis). Entretanto, h tambm outros tipos de objetos, tais como objetos de carter descritivo usado para organizar e descrever outros objetos de um domnio (p.ex., modelos de carro), algumas vezes denominados objetos de especificao. Objetos sociais e de descrio (ou especificao) tendem a ser coisas menos tangveis, mas so to importantes para a modelagem conceitual quanto os objetos fsicos. Eventos: representam a ocorrncia de aes no domnio do problema que precisam ser registradas e lembradas pelo sistema. Eventos acontecem no tempo e, portanto, a representao de eventos normalmente envolve a necessidade de registrar, dentre outros, quando o evento ocorreu (ponto no tempo ou intervalo de tempo). Deve-se observar que muitos eventos ocorrem no domnio do problema, mas grande parte deles no precisa ser lembrada. Para capturar os eventos que precisam ser lembrados e, portanto, registrados, devem-se focalizar os principais eventos de negcio do domnio do problema. Assim, em um sistema de locao de automveis, so potenciais classes de eventos: Locao, Devoluo e Reserva. Por outro lado, a ocorrncia de eventos cadastrais, tais como os cadastros de clientes e carros, tende a ser de pouca importncia, no sendo necessrio lembrar a ocorrncia desses eventos. Seja qual for a estratgia usada para identificar classes, sempre importante que o analista tenha em mente os objetivos do sistema durante a modelagem conceitual. No se devem representar informaes irrelevantes para o sistema e, portanto, a relevncia para o sistema o principal critrio a ser adotado para decidir se um determinado elemento deve ou no ser includo no modelo conceitual estrutural do sistema. O resultado principal da atividade de identificao de classes a obteno de uma lista de potenciais classes para o sistema em estudo. Um modelo conceitual estrutural para uma aplicao complexa pode ter dezenas de classes e, portanto, pode ser necessrio definir uma representao concisa capaz de orientar um leitor em um modelo desta natureza. O agrupamento de classes em subsistemas serve basicamente a este propsito, podendo ser til tambm para a organizao de grupos de trabalho em projetos extensos. Conforme discutido no Captulo 5, a base principal para a identificao de subsistemas a complexidade do domnio do problema. Atravs da identificao e agrupamento de classes em subsistemas, possvel controlar a visibilidade do leitor e, assim, tornar o modelo mais compreensvel. Assim, da mesma maneira que casos de uso so agrupados em pacotes, classes tambm devem ser. Quando uma coleo de classes colabora entre si para realizar um conjunto coeso de responsabilidades (casos de uso), elas podem ser vistas como um subsistema. Assim, um subsistema uma abstrao que prov uma referncia para mais detalhes em um modelo de anlise, incluindo tanto casos de uso quanto classes. O agrupamento de classes em subsistemas permite apresentar o modelo global em uma perspectiva mais alta. Esse nvel
120
ajuda o leitor a rever o modelo, bem como constitui um bom critrio para organizar a documentao. Uma vez identificadas as potenciais classes, deve-se proceder uma avaliao para decidir o que efetivamente considerar ou rejeitar. Conforme discutido anteriormente, a relevncia para o sistema deve ser o critrio principal. Alm desse critrio, os seguintes tambm devem ser considerados nessa avaliao: Estrutura complexa: o sistema precisa tratar informaes sobre os objetos da classe? Tipicamente, uma classe deve ter, pelo menos, dois atributos. Se uma classe apresentar apenas um atributo, avalie se no melhor trat-la como um atributo de uma classe existente13. Atributos e associaes comuns: os atributos e as associaes da classe devem ser aplicveis a todas as suas instncias, isto , a todos os objetos da classe. Classes no redundantes: duas classes so redundantes quando elas tm sempre a mesma populao14. Seja o exemplo de um modelo conceitual que tenha as classes Pessoa e Funcionrio. Se o sistema est interessado apenas nas pessoas empregadas na organizao (ou seja, funcionrios), ento a populao dessas duas classes ser sempre a mesma. A introduo de classes redundantes afeta e simplicidade do modelo e, portanto, um modelo conceitual no deve incluir classes redundantes. Existncia de instncias: toda classe deve possuir uma populao no vazia. Uma potencial classe que possui uma nica instncia tambm no deve ser considerada uma classe. Tipicamente uma classe possui vrias instncias e a populao da classe varia ao longo do tempo.
6.2 Identificao de Atributos e Associaes

Conforme apontado anteriormente, uma classe tpica de um modelo conceitual estrutural deve apresentar estrutura complexa. A estrutura de uma classe corresponde a seus atributos e associaes. Conceitualmente, no h diferena entre atributos e associaes. Atributos so, na verdade, tipos de relacionamentos binrios. Em um tipo de relacionamento binrio, h dois participantes. Em alguns tipos de relacionamentos, esses participantes so considerados colegas, porque eles desempenham funes anlogas e nenhum deles subordinado ao outro. Seja o caso do tipo de relacionamento aluno cursa um curso. Um aluno no pode cursar sem haver um curso, bem como um curso no pode ser cursado se no houver um aluno. A ordem dos participantes no modelo no implica uma relao de prioridade ou subordinao entre eles (OLIV, 2007). Na orientao a objetos, esse tipo de relacionamento modelado como uma associao. Entretanto, h alguns tipos de relacionamentos nos quais usurios e analistas consideram um participante como sendo uma caracterstica do outro. Seja o exemplo do tipo de relacionamento filme possui gnero. Algum pode argumentar que o participante gnero uma caracterstica de filme e, portanto, subordinado a este. Esse tipo de relacionamento
Uma classe que possui um nico atributo, mas vrias associaes, tambm satisfaz a esse critrio. A populao de uma classe em um dado momento o conjunto de instncias que existem no domnio naquele momento (OLIV, 2007).
14 13
121
modelado como um atributo. Assim, um atributo um tipo de relacionamento binrio em que um participante considerado uma caracterstica de outro. Por conseguinte, um atributo igual a uma associao, exceto pelo fato de usurios e analistas adicionarem a interpretao que um dos participantes subordinado ao outro (OLIV, 2007). De uma perspectiva mais prtica, atributos podem ser vistos como informaes alfanumricas ligadas a um conceito. Associaes, por sua vez, consistem em um tipo de informao que liga diferentes conceitos entre si (WAZLAWICK, 2004). Atributos ligam classes do domnio do problema a tipos de dados. Tipos de dados podem ser primitivos ou especficos de domnio. Os tipos de dados primitivos so aplicveis aos vrios domnios e sistemas, tais como strings, datas, inteiros e reais, e so considerados como sendo predefinidos. Os tipos de dados especficos de um domnio de aplicao, por outro lado, precisam ser definidos. So exemplos de tipos de dados especficos: CPF, ISBN de livros, endereo etc. Neste texto so considerados os seguintes tipos de dados primitivos: String: cadeia de caracteres; boolean: admite apenas os valores verdadeiro e falso; Integer (ou int): nmeros inteiros; Float (ou float): nmeros reais; Currency: valor em moeda (reais, dlares etc.); Date: datas, com informao de dia, ms e ano; Time: horas em um dia, com informao de hora, minuto e segundo; DateTime: combinao dos dois anteriores; YearMonth: informao de tempo contendo apenas ms e ano; Year: informao de tempo contendo apenas ano.
6.2.1 Atributos
Um atributo uma informao de estado para a qual cada objeto em uma classe tem o seu prprio valor. Os atributos adicionam detalhes s abstraes e so apresentados na parte central do smbolo de classe. Conforme discutido anteriormente, atributos possuem um tipo de dado, que pode ser primitivo ou especfico de domnio. Ao identificar um atributo como sendo relevante, deve-se definir qual o seu tipo de dado. Caso nenhum dos tipos de dados primitivos se aplique, devese definir, ento, um tipo de dados especfico. Por exemplo, em domnios que lidem com livros, necessrio definir o tipo ISBN15, cujas instncias so ISBNs vlidos. Em domnios que lidem com pessoas fsicas e jurdicas, CPF e CNPJ tambm devem ser definidos como tipos de dados especficos. Usar um tipo de dados primitivo nestes casos, tais como String ou
O ISBN - International Standard Book Number - um sistema internacional padronizado que identifica numericamente os livros segundo o ttulo, o autor, o pas, a editora, individualizando-os inclusive por edio. Utilizado tambm para identificar software, seu sistema numrico pode ser convertido em cdigo de barras.
15
122
int, insuficiente, pois no so quaisquer cadeias de caracteres ou nmeros que se caracterizam como ISBNs, CPFs ou CNPJs vlidos. Tipos de dados especficos podem apresentar propriedades. Por exemplo, CPF um nmero de 11 dgitos, que pode ser dividido em duas partes: os 9 primeiros dgitos e os dois ltimos, que so dgitos verificadores. Um tipo de dados especial a enumerao. Na enumerao, os valores do tipo so enumerados explicitamente na forma de literais, como o caso do tipo DiaSemana, que tipicamente definido como um tipo de dados compreendendo sete valores: Segunda, Tera, Quarta, Quinta, Sexta, Sbado e Domingo. importante observar que tipos de dados enumerados s devem ser usados quando se sabe priori quais so os seus valores e eles so fixos. Assim, so bons candidatos a tipos enumerados informaes como sexo (M/F), estado civil, etc. Tipos de dados geralmente no so representados graficamente em um modelo conceitual estrutural, de modo a torn-lo mais simples. Na maioria das situaes, basta descrever os tipos de dados especficos de domnio no Dicionrio de Dados do Projeto. Contudo, se necessrio, eles podem ser representados graficamente usando o smbolo de classe estereotipado com a palavra chave <<dataType>>. Tipos enumerados tambm podem ser representados usando o smbolo de classe, mas com o esteretipo <<enumeration>>, sendo que ao invs de apresentar atributos de um tipo de dados, enumeram-se os valores possveis da enumerao. A Figura 6.2 ilustra a notao de tipos de dados na UML.
Figura 6.2 Notao de Tipos de Dados na UML. Uma dvida tpica e recorrente na modelagem estrutural se um determinado item de informao deve ser modelado como uma classe ou como um atributo. Para que o item seja considerado uma classe, ele tem de passar nos critrios de incluso no modelo discutidos na seo anterior. Entretanto, h alguns itens de informao que passam nesses critrios, mas que ainda assim podem ser melhor modelados como atributos, tendo como tipo um tipo de dado complexo, especfico de domnio. Um atributo deve capturar um conceito atmico, i.e., um nico valor ou um agrupamento de valores fortemente relacionados que sirva para descrever outro objeto. Alm disso, para que um item de estrutura complexa seja modelado como um atributo, ele deve ser compreensvel pelos interessados simplesmente pelo seu nome. bom realar que, com o tempo, as classes do domnio do problema tendem a permanecer relativamente estveis, enquanto os atributos provavelmente se alteram. Atributos podem ser bastante volteis, em funo de alteraes nas responsabilidades do sistema. muito importante lembrar tambm que, uma vez que atributos e associaes so tipos de relacionamentos, no devemos incluir na lista de atributos de uma classe, atributos representando associaes (ou atributos representando chaves estrangeiras como a classe
123
fosse uma tabela de um banco de dados relacional). Associaes j tm sua presena indicada pela notao de associao, ou seja pelas linhas que conectam as classes que se relacionam. Um aspecto bastante importante na especificao de atributos a escolha de nomes. Deve-se procurar utilizar o vocabulrio tpico do domnio do problema, usando nomes legveis e abrangentes. Para nomear atributos, sugerem-se nomes iniciando com substantivo, o qual pode ser combinado com complementos ou adjetivos, omitindo-se preposies. O nome do atributo deve ser iniciado com letra minscula, enquanto os nomes dos complementos devem iniciar com letras maisculas, sem dar um espao em relao palavra anterior. Acentos no devem ser utilizados. Atributos monovalorados devem iniciar com substantivo no singular (p.ex., nome, razaoSocial), enquanto atributos multivalorados devem iniciar com o substantivo no plural (p.ex., telefones). A sintaxe de atributos na UML, em sua forma plena, a seguinte (BOOCH; RUMBAUGH; JACOBSON, 2006):
visibilidade nome: tipo [multiplicidade] = valorInicial {propriedades}
A visibilidade de um atributo indica em que situaes esse atributo visvel por outras classes. Na UML h quatro nveis de visibilidade, os quais so marcados pelos seguintes smbolos: + pblico : o atributo pode ser acessado por qualquer classe; # protegido: o atributo s passvel de acesso pela prpria classe ou por uma de suas especializaes; - privado: o atributo s pode ser acessado pela prpria classe; ~ pacote: o atributo s pode ser acessado por classes declaradas dentro do mesmo pacote da classe a que pertence o atributo. A informao de visibilidade inerente fase de projeto e no deve ser expressa em um modelo conceitual. Assim, em um modelo conceitual, atributos devem ser especificados sem nenhum smbolo antecedendo o nome. O tipo indica o tipo de dado do atributo, o qual deve ser um tipo de dado primitivo ou um tipo de dado especfico de domnio. Tipos de dados especficos de domnio devem ser definidos no Dicionrio de Dados do Projeto. Para tornar os modelos conceituais mais simples, de modo a facilitar a comunicao com clientes e usurios, tipos de dados de atributos podem ser omitidos do diagrama de classes. A multiplicidade a especificao do intervalo permitido de itens que o atributo pode abrigar. O padro que cada atributo tenha um e somente um valor para o atributo. Quando um atributo for opcional ou quando puder ter mais do que uma ocorrncia, a multiplicidade deve ser informada, indicando o valor mnimo e o valor mximo, da seguinte forma:
valor_mnimo .. valor_mximo
A seguir, so dados alguns exemplos: nome: String instncias da classe tm obrigatoriamente um e somente um nome. instncias da classe tm uma ou nenhuma carteira. instncias da classe tm um ou vrios telefones.
carteira: String [0..1]
telefones: Telefone [0..*]
124
pessoasContato: String [2] contato.
instncias da classe tm exatamente duas pessoas de
Atributos podem ter um valor padro inicial, ou seja, um valor que, quando no informado outro valor, ser atribudo ao atributo. O campo valorInicial descreve exatamente este valor. O exemplo abaixo ilustra o uso de valor inicial. origem: Ponto = (0,0) a origem, quando no informado outro valor, ser o ponto (0,0) Finalmente, podem ser indicadas propriedades dos atributos. Uma propriedade que pode ser interessante mostrar em um modelo conceitual a propriedade readonly, a qual indica que o valor do atributo no pode ser alterado aps a inicializao do objeto. No exemplo abaixo, est-se indicando que o valor do atributo numeroSocio de um scio de um clube no pode ser alterado. numSocio: int {readonly} Alm das informaes tratadas na declarao de um atributo seguindo a sintaxe da UML, outras informaes de domnio, quando pertinentes, podem ser adicionadas no Dicionrio de Dados do Projeto, tais como unidade de medida, intervalo de valores possveis, limite, preciso etc.
6.2.2 Associaes
Uma associao um tipo de relacionamento que ocorre entre instncias de duas ou mais classes. Assim como classes, associaes so tipos. Ou seja, uma associao modela um tipo de relacionamento que pode ocorrer entre instncias das classes envolvidas. Uma instncia de uma associao (dita uma ligao) conecta instncias especficas das classes envolvidas na associao. Seja o exemplo de um domnio em que clientes efetuam pedidos. Esse tipo de relacionamento pode ser modelado como uma associao Cliente efetua Pedido. Seja Pedro uma instncia de Cliente e Pedido100 uma instncia de Pedido. Se foi Pedro quem efetuou o Pedido100, ento a ligao (Pedro, Pedido100) uma instncia da associao Cliente efetua Pedido. Associaes podem ser nomeadas. Neste texto sugere-se o uso de verbos conjugados, indicando o sentido de leitura. Ex.: Cliente (classe) efetua > (associao) Locao (classe). Cada classe envolvida na associao desempenha um papel, ao qual pode ser dado um nome. Cada classe envolvida na associao possui tambm uma multiplicidade16 nessa associao, que indica quantos objetos podem participar de uma instncia dessa associao. A notao da UML tipicamente usada para representar associaes em um modelo conceitual ilustrada na Figura 6.3.
Figura 6.3 Notao de Associaes na UML.
Multiplicidades em uma associao so anlogas s multiplicidades em atributos e especificam as quantidades mnima e mxima de objetos que podem participar da associao. Quando nada for dito, o padro 1..1 como no caso de atributos. Contudo, para deixar os modelos claros, recomenda-se sempre especificar explicitamente as multiplicidades das associaes.
16
125
Na ilustrao da figura, um objeto da Classe1 se relaciona com no mnimo c e no mximo d objetos da Classe2. J um objeto da Classe2 se relaciona com no mnimo a e no mximo b objetos da Classe1. Objetos da Classe1 desempenham o papel de papelClasse1 nesta associao, enquanto objetos da Classe2 desempenham o papel de papelClasse2 nessa mesma associao. importante, neste ponto, frisar a diferena entre sentido de leitura (ou direo do nome) de uma associao com a navegao da associao. O sentido de leitura diz apenas em que direo ler o nome da associao, mas nada diz sobre a navegabilidade da associao. A navegabilidade (linha de associao com seta direcionada) usada para limitar a navegao de uma associao a uma nica direo e um recurso a ser usado apenas na fase de projeto. Em um modelo conceitual, todas as associaes so no direcionais, ou seja, navegveis nos dois sentidos. Ainda que nomes de associaes e papis sejam opcionais, recomenda-se us-los para tornar o modelo mais claro. Alm disso, h algumas situaes em que fica invivel ler um modelo se no houver a especificao do nome da associao ou de algum de seus papis. Seja o exemplo da Figura 6.4. Em uma empresa, um empregado est lotado em um departamento e, opcionalmente, pode chefi-lo. Um departamento, por sua vez, pode ter vrios empregados nele lotados, mas apenas um chefe. Sem nomear essas associaes, o modelo fica confuso. Rotulando os papis e as associaes, o modelo torna-se muito mais claro. Na figura 6.4, um departamento exerce o papel de departamento de lotao do empregado e, neste caso, um empregado tem um e somente um departamento de lotao. No outro relacionamento, um empregado exerce o papel de chefe e, portanto, um departamento possui um e somente um chefe.
Figura 6.4 Exemplo: Nomeando Associaes. Ao contrrio das classes e dos atributos que podem ser encontrados facilmente a partir da leitura dos textos da descrio do minimundo e das descries de casos de uso, muitas vezes, as informaes sobre associaes no aparecem to explicitamente. Casos de uso descrevem aes de interao entre atores e sistema e, por isso, acabam mencionando principalmente operaes. Operaes transformam a informao, passando um objeto de um estado para outro, por meio da alterao dos seus valores de atributos e associaes. Uma associao, por sua vez, uma relao esttica que pode existir entre duas classes. Assim, as descries de casos de uso esto repletas de operaes, mas no de associaes (WAZLAWICK, 2004). Contudo, conforme discutido na seo anterior, h alguns eventos que precisam ter sua ocorrncia registrada e, portanto, so tipicamente mapeados como classes. Esses eventos esto descritos nos casos de uso e podem ter sido capturados como associaes. Seja o exemplo de uma concessionria de automveis. Neste domnio, clientes compram carros, como ilustra a
126
parte (a) da Figura 6.5. Contudo, a compra um evento importante para o negcio e precisa ser registrado. Neste caso, como ilustra a parte (b) da Figura 6.5, a compra deve ser tratada como uma classe e no como uma associao.
Figura 6.5 Exemplo: Associao x Classe de Evento Lembrado. Deve-se notar pelo exemplo acima que o evento representado por uma classe, enquanto as associaes continuam representando relacionamentos estticos entre as classes e no operaes ou transformaes (WAZLAWICK, 2004). Assim, deve-se tomar cuidado com a representao de eventos como associaes, questionando sempre se aquela associao relevante para o sistema em questo. Seja o exemplo da Figura 6.6. Nesse exemplo, o caso de uso aponta que funcionrios so responsveis por cadastrar livros em uma biblioteca. Seria necessrio, pois, criar uma associao Funcionrio cadastra Livro no modelo estrutural? A resposta, na maioria dos casos, no. Apenas se explicitamente expresso pelo cliente em um requisito que necessrio saber exatamente qual funcionrio fez o cadastro de um dado livro (o que muito improvvel de acontecer), que tal relao deveria ser considerada. Mesmo se houver a necessidade de auditoria de uso do sistema (requisito no funcional relativo segurana), no h a necessidade de modelar esta associao, pois requisitos no funcionais no devem ser considerados no modelo conceitual, uma vez que solues bastante distintas do uso dessa associao poderiam ser adotadas.
Figura 6.6 Exemplo: Associao x Caso de Uso. Na modelagem conceitual fundamental saber a quantidade de objetos que uma associao admite em cada um de seus papis, o que capturado pelas multiplicidades da associao. Esta informao bastante dependente da natureza do problema e do real significado da associao (o que se quer representar efetivamente), especialmente no que se refere associao representar apenas o presente ou o histrico (WAZLAWICK, 2004).
127
Retomemos o exemplo da Figura 6.4, no qual se diz que um empregado est lotado em um departamento e, opcionalmente, pode chefi-lo. Para definir precisamente as multiplicidades, necessrio investigar os seguintes aspectos: Um empregado pode mudar de lotao? Se sim, necessrio registrar apenas a lotao atual ou necessrio registrar o histrico de lotaes dos empregados (ou seja, registrar o evento de lotao de um empregado em um departamento)? Um departamento pode, ao longo do tempo, mudar de chefe? Se sim, necessrio registrar o histrico de chefias do departamento (ou seja, registrar o evento de nomeao do chefe do departamento)? Como colocado no modelo da Figura 6.4, est-se representando apenas a situao presente. Se houver mudana de chefe de um departamento ou do departamento de lotao de um empregado, perder-se- a informao histrica. Na maioria das vezes, essa no uma soluo aceitvel. Na maioria dos domnios, as pessoas querem saber a informao histrica. Assim, nota-se que parte das responsabilidades do sistema registrar a ocorrncia dos eventos de nomeao do chefe e de lotao de empregados. Assim, um modelo mais fidedigno a essa realidade o modelo da Figura 6.7, o qual introduz as classes do tipo evento lembrado NomeacaoChefia e Lotacao.
Figura 6.7 Registrando Histricos. Ainda que este modelo seja mais fidedigno realidade, ele ainda apresenta problemas. Por exemplo, o modelo diz que um empregado pode ter uma ou mais locaes. Mas o empregado pode ter mais de uma lotao vigente? O mesmo vale para o caso da nomeao de chefia. Um empregado pode ser chefe de mais de um departamento ao mesmo tempo? Um departamento pode ter mais do que um chefe nomeado ao mesmo tempo? Infelizmente, o modelo incapaz de responder a essas perguntas. Para eliminar essas ambiguidades, necessrio capturar regras de negcio do tipo restries de integridade. No exemplo acima, as seguintes regras se aplicam: Um empregado s pode estar lotado em um nico departamento em um dado momento. Um empregado s pode estar designado como chefe de um nico departamento em um dado momento. Um departamento s pode ter um empregado designado como chefe em um dado momento.
Observe que, como um departamento pode ter vrios empregados nele lotados ao mesmo tempo, no necessrio escrever uma restrio de integridade, pois este o caso mais
128
geral (sem restrio). Assim, restries de integridade devem ser escritas apenas para as associaes que so passveis de restries. Restries de integridade so regras de negcio e poderiam ser lanadas no Documento de Requisitos. Contudo, como elas so importantes para a compreenso e eliminao de ambiguidades do modelo conceitual, til descrev-las no prprio modelo conceitual. Alm das restries de integridade relativas s multiplicidades n, diversas outras restries podem ser importantes para tornar o modelo mais fiel realidade. Ainda no exemplo da Figura 6.7, poder-se-ia querer dizer que um empregado s pode ser nomeado como chefe de um departamento, se ele estiver lotado nesse departamento. Restries deste tipo so comuns em pores fechadas de um diagrama de classes. Assim, toda vez que se detectar uma poro fechada em um diagrama de classes, vale a pena analis-la para avaliar se h ali uma restrio de integridade ou no. Havendo, deve-se escrev-la. Restries de integridade tambm podem falar sobre atributos das classes. Por exemplo, a data da portaria de nomeao de um empregado e como chefe de um departamento d deve ser igual ou posterior data da portaria de lotao do empregado e no departamento d. Geralmente, restries de integridade so escritas em linguagem natural, uma vez que no so passveis de modelagem grfica. Contudo, conforme j discutido anteriormente, o uso de linguagem natural pode levar a ambiguidades. Visando suprir essa lacuna na UML, o OMG17 incorporou ao padro uma linguagem para especificao formal de restries, a OCL (Object Constraint Language). Contudo, restries escritas em OCL dificilmente sero entendidas por clientes e usurios, o que dificulta a validao das mesmas. Assim, neste texto, sugere-se escrever as restries de integridade em linguagem natural mesmo. Vale ressaltar que a UML prov alguns mecanismos para representar restries de integridade em um modelo grfico. As prprias multiplicidades so uma forma de capturar restries de integridade (ditas restries de integridade de cardinalidade). Alm das multiplicidades, a UML prov o recurso de restries, as quais so representadas entre chaves ({restrio}). Restries podem ser usadas, dentre outros, para restringir a ocorrncia de associaes. Seja o seguinte exemplo: em uma concessionria de automveis compras podem ser financiadas ou por financeiras ou por bancos. Para capturar essa restrio, pode-se usar a restrio xor da UML, como ilustra a Figura 6.8.
Figura 6.8 Restrio XOR entre Associaes.
17
Object Management Group (http://www.omg.org/) uma organizao internacional que gerencia padres abertos relativos ao desenvolvimento orientado a objetos, dentre eles a UML.
129
Nesta figura, uma compra ou est relacionada a um banco ou a uma financeira. No possvel que uma compra esteja associada aos dois ao mesmo. Como as multiplicidades mnimas do lado de banco e financeira so zero, uma compra pode no ser financiada. Ainda em relao s multiplicidades, vale frisar que associaes muitos-para-muitos so perfeitamente legais em um modelo orientado a objetos, como ilustra o exemplo da Figura 6.9. Nesse exemplo, est-se dizendo que disciplinas podem possuir vrios pr-requisitos e podem ser pr-requisitos para vrias outras disciplinas.
Figura 6.9 Associao Muitos-para-Muitos. Deve-se observar, no entanto, que muitas vezes, uma associao muitos-para-muitos oculta a necessidade de uma classe do tipo evento a ser lembrado. Seja o seguinte exemplo: em uma organizao, empregados so alocados a projetos. Um empregado pode ser alocado a vrios projetos, enquanto um projeto pode ter vrios empregados a ele alocados. Tomando por base este fato, seria natural se chegar ao modelo da Figura 6.10(a). Contudo, se quisermos registrar as datas de incio e fim do perodo em que o empregado esteve alocado ao projeto, esse modelo insuficiente e deve ser alterado para comportar uma classe do tipo evento lembrado Alocacao, como mostra a Figura 6.10(b).
Figura 6.10 Associao Muitos-para-Muitos e Classes de Evento Lembrado. De fato, o problema por detrs do modelo da Figura 6.10(a) o mesmo anteriormente discutido na Figura 6.7: a necessidade ou no de se representar informao histrica. Contudo, de maneira mais abrangente, pode-se pensar que, se uma associao apresenta atributos, melhor trat-la como uma nova classe. Seja o seguinte exemplo: em uma loja, um cliente efetua um pedido, discriminando vrios produtos, cada um deles em uma certa quantidade. O modelo da Figura 6.11(a) procura representar essa situao, mas uma questo permanece em aberto: onde representar a informao da quantidade pedida de cada produto? Essa informao no pode ficar em Produto, pois diferentes pedidos pedem quantidades diferentes de um mesmo produto. Tambm no pode ficar em Pedido, pois um mesmo pedido tipicamente especifica diferentes quantidades de diferentes produtos. De fato, quantidade no nem um atributo da classe Pedido nem um atributo da classe Produto, mas sim um atributo
130
da associao especifica. Assim, uma soluo possvel introduzir uma classe ItemPedido, reificando18 essa associao, como ilustra a Figura 6.11(b).
Figura 6.11 Reificando uma Associao A UML oferece uma primitiva de modelagem, chamada classe de associao, que pode ser usada para tratar a reificao de associaes (OLIV, 2007). Uma classe de associao pode ser vista como uma associao que tem propriedades de classe (BOOCH; RUMBAUGH; JACOBSON, 2006). A Figura 6.12 mostra o exemplo anterior, sendo modelado como uma classe de associao, segundo a notao da UML.
Figura 6.12 Notao da UML para Classes Associativas. Classes associativas so ainda representaes de associaes. Assim como uma instncia de uma associao, uma instncia de uma classe associativa um par ordenado conectando duas instncias das classes envolvidas na associao. Assim, se Pedido100 uma instncia de Pedido, Lpis uma instncia de Produto e o Pedido100 especifica 5 Lpis, ento uma instncia de ItemPedido a tupla ((Pedido100, Lpis), 5). Classes associativas podem ser usadas tambm para representar eventos cuja ocorrncia precisa ser lembrada, como nos exemplos das figuras 6.7 e 6.10. Entretanto, importante observar que o uso de classes associativas nesses casos pode levar a problemas de modelagem. Seja o seguinte contexto: em um hospital, pacientes so tratados em unidades mdicas. Um paciente pode ser tratado em diversas unidades mdicas diferentes, as quais podem abrigar diversos pacientes sendo tratados. A Figura 6.13(a) mostra um modelo que busca representar essa situao usando uma classe associativa. Como uma classe associativa, as instncias de Tratamento so pares ordenados (Paciente, Unidade Mdica). Assim, cada vez que um paciente tratado em uma unidade mdica diferente tem-se um tratamento. Esta pode, contudo, no ser precisamente a concepo do problema original. Poder-se-ia imaginar que um tratamento um tratamento de um paciente em vrias unidades mdicas. A classe de
Reificar uma associao consiste em ver essa associao como uma classe. A palavra reificao vem da palavra do latim res, que significa coisa. Reificao corresponde ao que em linguagem natural se chama nominalizao, que basicamente consiste em transformar um verbo em um substantivo (OLIV, 2007).
18
131
associao no captura isso. Assim, um modelo mais fiel ao domnio aquele que representa Tratamento como uma classe do tipo evento a ser lembrado e que est relacionada com Paciente e Unidade Mdica da forma mostrada na Figura 6.13(b).
Figura 6.13 Classes Associativas x Classes do Tipo Evento a Ser Lembrado. At o momento, todas as associaes mostradas foram associaes binrias, i.e., associaes envolvendo duas classes. Mesmo o exemplo da Figura 6.9 (Disciplina tem como pr-requisito Disciplina) ainda uma associao binria, na qual a mesma classe desempenha dois papis diferentes (disciplina que possui pr-requisito e disciplina que pr-requisito). Entretanto, associaes n-rias so tambm possveis, ainda que bem menos corriqueiramente encontradas. Uma associao ternria, por exemplo, envolve trs classes, como ilustra o exemplo da Figura 6.14. Nesse exemplo, est-se dizendo que fornecedores podem fornecer produtos para certos clientes.
Figura 6.14 Associao Ternria. Na UML, associaes n-rias so mostradas como losangos conectados s classes envolvidas na associao por meio de linhas slidas, como mostra a Figura 6.14. O nome da associao colocado dentro ou em cima do losango, sem direo de leitura. Normalmente, multiplicidades no so mostradas, dada a dificuldade de interpret-las. Finalmente, algumas associaes podem ser consideradas mais fortes do que as outras, no sentido de que elas, na verdade, definem um objeto como sendo composto por outros (WAZLAWICK, 2004). Essas associaes todo-parte podem ser de dois tipos principais: agregao e composio.
132
A composio o tipo mais forte de associao todo-parte. Ela indica que um objetoparte s pode ser parte de um nico todo. J a agregao no implica nessa exclusividade. Um carro, por exemplo, tem como partes um motor e quatro ou cinco rodas. Motor e rodas, ao serem partes de um carro, no podem ser partes de outros carros simultaneamente. Assim, esta uma relao de composio, como ilustra a Figura 6.15(a). O exemplo da Figura 6.15(b) ilustra o caso de comisses compostas por professores. Nesse caso, um professor pode participar de mais de uma comisso simultaneamente e, portanto, trata-se uma relao de agregao. Na UML, um losango branco na extremidade da associao relativa ao todo indica uma agregao. J um losango preto indica uma composio.
Figura 6.15 Agregao e Composio. Relaes todo-parte podem ser empregadas em situaes como: Quando h clareza de que um objeto complexo composto de outros objetos (componente de). Ex.: Motor um componente de um carro. Para designar membros de colees (membro de). Ex.: Pesquisadores so membros de Grupos de Pesquisa.
Muitas vezes pode ser difcil perceber a diferena entre uma agregao / composio e uma associao comum. Quando houver essa dvida, melhor representar a situao usando uma associao comum, tendo em vista que ela impe menos restries.
6.3 Especificao de Hierarquias de Generalizao / Especializao

Um dos principais mecanismos de estruturao de conceitos a generalizao / especializao. Com este mecanismo possvel capturar similaridades entre classes, dispondo-as em hierarquias de classes. No contexto da orientao a objetos, esse tipo de relacionamento tambm conhecido como herana. importante notar que a herana tem uma natureza bastante diferente das associaes. Associaes representam possveis ligaes entre instncias das classes envolvidas. J a relao de herana uma relao entre classes e no entre instncias. Ao se considerar uma classe B como sendo uma subclasse de uma classe A est-se assumindo que todas as instncias de B so tambm instncias de A. Assim, ao se dizer que a classe EstudanteGraduacao herda da classe Estudante, est-se indicando que todos os estudantes de graduao so estudantes. Em resumo, deve-se interpretar a relao de herana como uma relao de subtipo entre classes. A Figura 6.16 mostra a notao da UML para representar herana.
133
Figura 6.16 Notao de Herana da UML. A relao de herana aplicvel quando for necessrio fatorar os elementos de informaes (atributos e associaes) de uma classe. Quando um conjunto de classes possuir semelhanas e diferenas, ento elas podem ser organizadas em uma hierarquia de classes, de forma a agrupar em uma superclasse os elementos de informao comuns, deixando as especificidades nas subclasses. De maneira geral, no faz sentido criar hierarquias de classes quando as especializaes (subclasses) no tiverem nenhum elemento de informao diferente. Quando isso ocorrer, normalmente suficiente criar um atributo tipo para indicar os possveis subtipos da generalizao. Seja o caso de um domnio em que se faz distino entre clientes normais e clientes especiais, dos quais se quer saber exatamente as mesmas informaes. Neste caso, criar uma hierarquia de classes, como ilustra a Figura 6.17(a), desnecessrio. Uma soluo como a apresentada na Figura 6.17(b), em que o atributo tipo pode ser de um tipo enumerado com os seguintes valores {Normal, Especial}, modela satisfatoriamente o problema e mais simples e, portanto, mais indicada.
Figura 6.17 Uso ou no de Herana.
134
Tambm no faz sentido criar uma hierarquia de classes em que a superclasse no tem nenhum atributo ou associao. Informaes de estados pelos quais um objeto passa tambm no devem ser confundidas com subclasses. Por exemplo, um carro de uma locadora de automveis pode estar locado, disponvel ou em manuteno. Estes so estados e no subtipos de carro. De fato, interessante considerar alguns critrios para incluir uma subclasse (ou superclasse) em um modelo conceitual. O principal deles o fato da especializao (ou generalizao) estar dentro do domnio de responsabilidade do sistema. Apenas subclasses (superclasses) relevantes para o sistema em questo devem ser consideradas. Alm desse critrio bsico, os seguintes critrios devem ser usados para analisar hierarquias de herana: Uma hierarquia de classes deve modelar relaes -um-tipo-de, ou seja, toda subclasse deve ser um subtipo especfico de sua superclasse. Uma subclasse deve possuir todas as propriedades (atributos e associaes) definidas por suas superclasses e adicionar mais alguma coisa (algum outro atributo ou associao). Todas as instncias de uma subclasse tm de ser tambm instncias da superclasse.
Ateno especial deve ser dada nomeao de classes em uma hierarquia de classes. Cada especializao deve ser nomeada de forma a ser auto-explicativa. Um nome apropriado para a especializao pode ser formado pelo nome de sua superclasse, acompanhado por um qualificador que descreve a natureza da especializao. Por exemplo, EstudanteGraduacao para designar um subtipo de Estudante. Hierarquias de classes no devem ser usadas de forma no criteriosa, simplesmente para compartilhar algumas propriedades. Seja o caso de uma loja de animais, em que se deseja saber as seguintes informaes sobre clientes e animais: nome, data de nascimento e endereo. No faz nenhum sentido considerar que Cliente uma subclasse de Animal ou viceversa, apenas para reusar um conjunto de atributos que, coincidentemente, igual. No que se refere modelagem de superclasses, deve-se observar se uma superclasse concreta ou abstrata. Se a superclasse puder ter instncias prprias, que no so instncias de nenhuma de suas subclasses, ento ela uma classe concreta. Por outro lado, se no for possvel instanciar diretamente a superclasse, ou seja, se todas as instncias da superclasse so antes instncias das suas subclasses, ento a superclasse abstrata. Classes abstratas so representadas na UML com seu nome escrito em itlico e no devem herdar de classes concretas. Quando modeladas hierarquias de herana, necessrio posicionar atributos e associaes adequadamente. Cada atributo ou associao deve ser colocado na classe mais adequada. Atributos e associaes genricos, que se aplicam a todas as subclasses, devem ser posicionados no topo da estrutura, de modo a serem aplicveis a todas as especializaes. De maneira mais geral, se um atributo ou associao aplicvel a um nvel inteiro de especializaes, ento ele deve ser posicionado na generalizao correspondente. Por outro lado, se algumas vezes um atributo ou associao tiver um valor significativo, mas em outras ele no for aplicvel, deve-se rever seu posicionamento ou mesmo a estrutura de generalizao-especializao adotada. Inevitavelmente, o processo detalhado de designar atributos e associaes a classes conduz a um entendimento mais completo da hierarquia de herana do que era possvel em
135
um estgio anterior. Assim, deve-se esperar que o trabalho de reposicionamento de atributos e associaes conduza a uma reviso da hierarquia de classes. Por fim vale a pena mencionar que, durante anos, o mecanismo de herana foi considerado o grande diferencial da orientao a objetos. Contudo, com o passar do tempo, essa nfase foi perdendo fora, pois se percebeu que o uso da herana nem sempre conduz melhor soluo de um problema de modelagem. Hoje a herana considerada apenas mais uma ferramenta de modelagem, utilizada basicamente para fatorar informaes, as quais, de outra forma, ficariam repetidas em diferentes classes (WAZLAWICK, 2004). Leitura Complementar O livro Conceptual Modeling of Information Systems, de Antoni Oliv (OLIV, 2007) dedicado modelagem conceitual de sistemas. Esse livro uma tima referncia para os interessados em se aperfeioar no trabalho de modelagem conceitual. , contendo diversas diretrizes incorporadas nestas notas de aula. Os captulos 2, 3, 4, 6, 7, 9 e 10 discutem, respectivamente, tipos de entidades, tipos de relacionamentos, restries de cardinalidade, reificao de associaes, tipos genricos de relacionamentos (incluindo relaes todo parte), restries de integridade e relaes de generalizao / especializao. O Captulo 5 de (WAZLAWICK, 2004) Modelagem Conceitual d uma viso geral da modelagem estrutural, discutindo de maneira bastante didtica, diversos de seus aspectos. Em (BOOCH; RUMBAUGH; JACOBSON, 2006), merecem ateno os captulos 4 (Classes), 5 (Relacionamentos), 8 (Diagramas de Classes), 9 (Classes Avanadas) e 10 (Relacionamentos Avanados). As notaes da UML para diagramas de classes so tratadas com mais detalhes do que nas demais referncias citadas anteriormente, precisamente por se tratar este de um livro sobre a UML. Referncias do Captulo BOOCH, G., RUMBAUGH, J., JACOBSON, I., UML Guia do Usurio, 2a edio, Elsevier Editora, 2006. GUIZZARDI, G., Ontological Foundations for Structural Conceptual Models, Telematics Instituut Fundamental Research Series, The Netherlands, 2005. JACOBSON, I.; Object-Oriented Software Engineering, Addison-Wesley, 1992. MYLOPOULOS, J., Conceptual Modeling and Telos, In: Conceptual Modeling, Databases and CASE, Wiley, 1992. OLIV, A., Conceptual Modeling of Information Systems, Springer, 2007. WAZLAWICK, R.S., Anlise e Projeto de Sistemas de Informao Orientados a Objetos, Elsevier, 2004.
Captulo 7 Modelagem Dinmica
136

Um sistema de informao realiza aes. O efeito de uma ao pode ser uma alterao em sua base de informao e/ou a comunicao de alguma informao ou comando para um ou mais destinatrios. Um evento de requisio de ao (ou simplesmente uma requisio) uma solicitao para o sistema realizar uma ao. O esquema comportamental de um sistema visa especificar essas aes (OLIV, 2007). Uma parte importante do modelo comportamental de um sistema o modelo de casos de uso, o qual fornece uma viso das funcionalidades que o sistema deve prover. O modelo conceitual estrutural define os tipos de entidades (classes) e de relacionamentos (atributos e associaes) do domnio do problema que o sistema deve representar para poder prover as funcionalidades descritas no modelo de casos de uso. Durante a realizao de um caso de uso, atores geram eventos de requisio de aes para o sistema, solicitando a execuo de alguma ao. O sistema realiza aes e ele prprio pode gerar outras requisies de ao. necessrio, pois, modelar essas requisies de aes, as correspondentes aes a serem realizadas pelo sistema e seus efeitos. Este o propsito da modelagem dinmica. Em uma abordagem orientada a objetos, requisies de ao correspondem a mensagens trocadas entre objetos. As aes propriamente ditas e seus efeitos so tratados pelas operaes das classes19. Assim, a modelagem dinmica est relacionada com as trocas de mensagens entre objetos e a modelagem das operaes das classes. Os diagramas de classes gerados pela atividade de modelagem conceitual estrutural representam apenas os elementos estticos de um modelo de anlise orientada a objetos. preciso, ainda, modelar o comportamento dinmico da aplicao. Para tal, necessrio representar o comportamento do sistema como uma funo do tempo e de eventos especficos. Um modelo de dinmico indica como o sistema ir responder a eventos ou estmulos externos e auxilia o processo de descoberta das operaes das classes do sistema. Para apoiar a modelagem da dinmica de sistemas, a UML oferece trs tipos de diagramas (BOOCH; RUMBAUGH; JACOBSON, 2006): Diagrama de Grfico de Estados: mostra uma mquina de estados que consiste dos estados pelos quais objetos de uma particular classe podem passar ao longo de seu ciclo de vida e as transies possveis entre esses estados, as quais so resultados de eventos que atingem esses objetos. Diagramas de grfico de estados (ou diagramas de transio de estados) so usados principalmente para modelar o comportamento de uma classe, dando nfase ao comportamento especfico de seus objetos.
De fato, abordagens distintas podem ser usadas, tal como representar tipos de requisies como classes, ditas classes de evento, e os seus efeitos como operaes das correspondentes classes de evento, tal como faz Oliv (2007).
19
137
Diagrama de Interao: descreve como grupos de objetos colaboram em um certo comportamento. Diagramas de interao podem ser de dois tipos: diagramas de comunicao e diagramas de sequncia. Um diagrama de sequncia um diagrama de interao que d nfase ordenao temporal das mensagens trocadas por objetos. J um diagrama de comunicao d nfase organizao estrutural dos objetos que enviam e recebem mensagens. Ambos so usados para ilustrar a viso dinmica de um sistema. Diagrama de Atividades: mostra o fluxo de uma atividade para outra em um sistema, incluindo sequncias e ramificaes de fluxo, subatividades e objetos que realizam e sofrem aes. Diagramas de atividades so usados principalmente para se fazer a modelagem das funes de um sistema, dando nfase ao fluxo de controle na execuo de um comportamento.
Diagramas de estados focalizam o comportamento de objetos de uma classe especfica. Diagramas de interao e de atividades enfocam o fluxo de controle entre vrios objetos e atividades. Enquanto os diagramas de interao do nfase ao fluxo de controle de um objeto para o outro, os diagramas de atividade do nfase ao fluxo de controle de uma etapa (atividade) para outra. Um diagrama de interao observa os objetos que passam mensagens; um diagrama de atividades focaliza as atividades, suas entradas e sadas, i.e., objetos passados de uma atividade para outra (BOOCH; RUMBAUGH; JACOBSON, 2006). Este captulo aborda a modelagem dinmica, discutindo os principais aspectos dessa importante tarefa, quando realizada segundo o paradigma orientado a objetos. A seo 7.1 discute os diferentes tipos de requisies de aes e como os diagramas dinmicos da UML podem ser usados para model-los. A sees 7.2, 7.3 e 7.4 tratam, respectivamente, dos diagramas de transio de estados, diagramas de sequncia e diagramas de atividades. A seo 7.4 aborda a especificao de operaes. Finalmente, a seo 7.5 explora as relaes existentes entre os vrios modelos elaborados durante a anlise de requisitos, as quais devem ser atentamente avaliadas durante a atividade de verificao de requisitos.
7.1 Tipos de Requisies de Ao

Um sistema de informao mantm uma representao do estado do domnio em sua base de informaes. Esse estado de coisas do domnio em um dado ponto no tempo corresponde ao conjunto de instncias dos tipos de entidades (classes) e de relacionamentos (associaes) relevantes que existem no domnio naquele momento. O esquema estrutural se preocupa com essa perspectiva. Entretanto, o sistema tambm realiza aes. O efeito de uma ao pode ser uma alterao em sua base de informao e/ou a comunicao de alguma informao ou comando para um ou mais destinatrios. Um evento de requisio de ao (ou simplesmente uma requisio) uma solicitao para que o sistema realize uma ao. Na anlise de requisitos, assume-se que a tecnologia perfeita e, por conseguinte, que o sistema executa as aes requisitadas instantaneamente (OLIV, 2007). Dependendo de como so iniciadas, requisies podem ser explcitas, temporais ou geradas. Uma requisio explcita iniciada explicitamente por um ator (requisio externa) ou por uma outra ao (requisio induzida), como parte de seu efeito. Uma requisio temporal iniciada pela passagem do tempo, ocorrendo independentemente do sistema. Por fim, uma requisio gerada iniciada quando uma condio de gerao da requisio satisfeita. O sistema detecta que a condio foi satisfeita e gera a correspondente requisio.
138
Por exemplo, em um sistema de controle de estoque, uma requisio de compra pode ser gerada quando a quantidade mnima de um produto for atingida (OLIV, 2007). A maioria das requisies externa. Dois importantes tipos de requisies externas so notificaes de eventos de domnio e consultas. Uma consulta uma requisio externa que prov alguma informao para o ator que iniciou a requisio. Consultas no alteram a base de informaes do sistema. Uma notificao de evento de domnio uma requisio externa cujo efeito uma mudana na base de informaes do sistema, correspondendo a um evento de domnio. Nem todas as mudanas na base de informaes de um sistema so admissveis. Os fatos nessa base mudam ao longo do tempo, mas no de maneira arbitrria. Os eventos de domnio definem, exatamente, as mudanas admissveis. Por meio de notificaes de eventos de domnio, atores dizem para o sistema que um evento de domnio ocorreu (OLIV, 2007). Por exemplo, quando ocorre no mundo real o evento de reserva de um carro em uma locadora de automveis, um usurio, ao realizar o caso de uso correspondente (p.ex., Reservar Carro), est notificando o sistema que esse evento ocorreu, o que inicia uma sequncia de aes (os passos do caso de uso), por meio da qual o sistema sabe que o evento ocorreu no domnio. Um evento de domnio corresponde a um conjunto no vazio de eventos estruturais, percebido ou considerado como uma alterao nica no domnio. Um evento estrutural, por sua vez, uma ao elementar que insere ou remove um fato na base de informaes do sistema. H quatro tipos bsicos de eventos estruturais: insero de entidade, remoo de entidade, insero de relacionamento e remoo de relacionamento. Esses eventos so ditos estruturais, porque eles so completamente determinados pelo esquema conceitual estrutural e no so explicitamente mostrados no esquema comportamental (OLIV, 2007). No desenvolvimento orientado a objetos, os eventos estruturais correspondem a operaes bsicas das classes. Assim, toda classe tem, implicitamente, operaes para: criar objetos da classe (evento estrutural de insero de entidade), dita mtodo construtor da classe; eliminar objetos (evento estrutural de remoo de entidade), dita mtodo destruidor da classe; estabelecer ligaes e atribuir valores para atributos (eventos estruturais de insero de relacionamentos); e remover ligaes ou excluir valores de atributos (eventos estruturais de remoo de relacionamentos). Essas operaes so consideradas bsicas e no precisam ser mostradas explicitamente no modelo conceitual. Seja o exemplo de um sistema de controle de produtos, cujo modelo estrutural parcialmente apresentado na Figura 7.1. Nesse exemplo, quando a companhia comea a trabalhar com um novo produto (p.ex., Prod1), o estado do domnio se altera, caracterizando um evento de domnio. Esse evento de domnio corresponde a cinco eventos estruturais, a saber: (1) a criao do objeto Prod1, (2) a atribuio de um valor para o atributo codigo, (3) a atribuio de um valor para o atributo valor, (4) a atribuio de um valor para o atributo quantidadeEstoque e (5) o estabelecimento da associao fornece com seu fornecedor. Esse novo produto considerado um evento de domnio, porque o conjunto de cinco eventos estruturais que o compe visto como um evento nico. muito mais fcil para um usurio dizer ao sistema que o evento de domnio ocorreu do que dizer explicitamente cada um dos eventos estruturais.
139
Figura 7.1 Fragmento do Modelo Estrutural de um Sistema de Controle de Produtos. Cada evento de domnio possui um conjunto de eventos estruturais, chamado de efeito do evento. A correspondncia entre eventos e seus efeitos dada por uma expresso de mapeamento. O efeito do evento pode ser definido segundo duas abordagens: a abordagem de ps-condio e a abordagem procedimental. Na abordagem de ps-condio, o efeito de um evento definido por uma condio da base de informaes do sistema que deve ser satisfeita aps a aplicao do efeito do evento. Na abordagem procedimental, o efeito de um evento definido por um procedimento, indicando os eventos estruturais que compem o evento de domnio (OLIV, 2007). Neste texto, enfocamos apenas a abordagem procedimental. Na abordagem procedimental, quando o paradigma orientado a objetos adotado, o efeito de um evento definido como uma operao de uma classe. O corpo dessa operao deve ser tal que sua execuo produza o conjunto de eventos estruturais que compe o evento de domnio. A execuo dessa operao vai deixar a base de informaes em um novo estado, o qual deve satisfazer a todas as restries estticas (definidas no modelo estrutural). Assim, durante a definio da operao correspondente ao efeito de um evento de domnio, devem-se levar em conta as restries capturadas no modelo estrutural e garantir que o novo estado da base de informaes do sistema vai satisfazer a todas elas. Em outras palavras, os eventos de domnio do esquema comportamental devem estar consistentes com o esquema estrutural (OLIV, 2007). A ideia de efeito de um evento de domnio estende-se, na verdade, para quaisquer requisies. Ou seja, o efeito de uma requisio pode ser representado por meio de uma operao, de maneira anloga ao descrito anteriormente para eventos de domnio. No que concerne a consultas, na modelagem conceitual define-se apenas o contedo de informao das respostas, abstraindo-se detalhes que dizem respeito ao formato e a caractersticas de dispositivos de sada (OLIV, 2007). Para que as informaes de atributos e associaes possam ser recuperadas para serem mostradas como parte das respostas a consultas, as classes precisam prover operaes bsicas para obter essas informaes. Assim como as demais operaes bsicas, assume-se que toda classe possui implicitamente operaes para se obter os valores correntes de seus atributos e associaes. Durante a realizao de um caso de uso, atores geram requisies para o sistema, solicitando a execuo de aes. O sistema realiza aes e ele prprio pode gerar outras requisies de ao. O conjunto de casos de uso tem de ser consistente com o conjunto de requisies definidas no esquema comportamental do sistema. Essa consistncia compreende duas propriedades (OLIV, 2007): Cada requisio gerada por um caso de uso deve ser definida no esquema comportamental; Cada requisio no esquema comportamental deve ser gerada por um ou mais casos de uso.
140
O mapeamento de casos de uso para as requisies feitas durante a sua execuo pode ser modelado por meio de diagramas de sequncia. Requisies geradas por condies baseadas em estados e requisies temporais so melhor modeladas com diagramas de transies de estados (OLIV, 2007).
7.2 - Diagramas de Transies de Estados

Todo objeto tem um tempo de vida. Na criao, o objeto nasce; na destruio, ele deixa de existir. Entre esses dois momentos, o objeto poder interagir com outros objetos, enviando e recebendo mensagens (BOOCH; RUMBAUGH; JACOBSON, 2006). Essas interaes representam o comportamento do objeto e ele pode ser varivel ao longo do ciclo de vida do objeto. Ou seja, muitas vezes, o comportamento dos objetos de uma classe depende do estado em que o objeto se encontra em um dado momento. Nestes casos, til especificar o comportamento usando uma mquina de estados. Classes com estados (ou classes modais) so classes cujas instncias podem mudar de um estado para outro ao longo de sua existncia, mudando possivelmente sua estrutura, seus valores de atributos ou comportamento dos mtodos (WAZLAWICK, 2004). Classes modais podem ser modeladas como mquinas de estados finitos. Uma mquina de estados finitos uma mquina que, em um dado momento, est em um e somente um de um nmero finito de estados (OLIV, 2007). Os estados de uma mquina de estados de uma classe modal correspondem s situaes relevantes em que as instncias dessa classe podem estar durante sua existncia. Um estado considerado relevante quando ele ajuda a definir restries ou efeitos dos eventos. Em qualquer estado, uma mquina de estados pode receber estmulos. Quando a mquina recebe um estmulo, ela pode realizar uma transio de seu estado corrente (dito estado origem) para um outro estado (dito estado destino), sendo que se assume que as transies so instantneas. A definio do estado destino depende do estado origem e do estmulo recebido. Alm disso, os estados origem e destino em uma transio podem ser o mesmo. Neste caso, a transio dita uma autotransio (OLIV, 2007). Diagramas de Transies de Estados so usados para modelar o comportamento de instncias de uma classe modal na forma de uma mquina de estados. Todas as instncias da classe comportam-se da mesma maneira. Em outras palavras, cada diagrama de estados construdo para uma nica classe, com o objetivo de mostrar o comportamento ao longo do tempo de vida de seus objetos. Diagramas de estados descrevem os possveis estados pelos quais objetos da classe podem passar e as alteraes dos estados como resultado de eventos (estmulos) que atingem esses objetos. Uma mquina de estado especifica a ordem vlida dos estados pelos quais os objetos da classe podem passar ao longo de seu ciclo de vida. A Figura 7.2 mostra a notao bsica da UML para diagramas de grfico de estados.
141
Figura 7.2 - Notao Bsica da UML para Diagramas de Grfico de Estados. Um estado uma situao na vida de um objeto durante a qual o objeto satisfaz alguma condio, realiza alguma atividade ou aguarda a ocorrncia de um evento (BOOCH; RUMBAUGH; JACOBSON, 2006). Estados so representados por retngulos com os cantos arredondados, sendo que o nome de um estado deve ser nico em uma mquina de estados. Uma regra prtica para nomear estados consiste em atribuir um nome tal que sejam significativas sentenas do tipo o <<objeto>> est <<nome do estado>> ou o <<objeto>> est no estado <<nome do estado>>. Por exemplo, em um sistema de locadora de automveis, um estado possvel de objetos da classe Carro seria Disponvel. A sentena o carro est disponvel tem um significado claro (OLIV, 2007). Quando um objeto fica realizando uma atividade durante todo o tempo em que permanece em um certo estado, deve-se indicar essa atividade no compartimento de aes do respectivo estado. importante realar que uma atividade tem durao significativa e, quando concluda, tipicamente a concluso provoca uma transio para um novo estado. A notao da UML para representar atividades de um estado : do / <<nomeAtividade>>. Transies so representadas por meio de setas rotuladas. Uma transio envolve um estado origem, um estado destino e normalmente um evento, dito o gatilho da transio. Quando a mquina de estados se encontra no estado origem e recebe o evento gatilho, ento o evento dispara a transio e a mquina de estados vai para o estado destino. Se uma mquina recebe um evento que no um gatilho para nenhuma transio, ento ela no afetada pelo evento (OLIV, 2007). Uma transio pode ter uma condio de guarda associada. s vezes, h duas ou mais transies com o mesmo estado origem e o mesmo evento gatilho, mas com condies de guarda diferentes. Neste caso, a transio disparada somente quando o evento gatilho ocorre e a condio de guarda verdadeira (OLIV, 2007). Quando uma transio no possuir uma condio de guarda associada, ento ela ocorrer sempre que o evento ocorrer. Por fim, quando uma transio disparada, uma ao instantnea pode ser realizada. Assim, o rtulo de uma transio pode ter at trs partes, todas elas opcionais: evento [condioGuarda] / ao
142
Basicamente a semntica de um diagrama de estados a seguinte: quando o evento ocorre, se a condio de guarda verdadeira, a transio dispara e a ao realizada instantaneamente. O objeto passa, ento, do estado origem para o estado destino. Se o estado destino possuir uma atividade a ser realizada, ela iniciada. O fato de uma transio no possuir um evento associado normalmente aponta para a existncia de um evento implcito. Isso tipicamente ocorre em trs situaes: (i) o evento implcito a concluso da atividade do estado origem e a transio ocorrer to logo a atividade associada ao estado origem tiver sido concluda; (ii) o evento implcito temporal, sendo disparado pela passagem do tempo; (iii) o evento implcito torna a condio de guarda verdadeira na base de informaes do sistema, mas o evento em si no modelado. Embora ambos os termos ao e atividade denotem processos, eles no devem ser confundidos. Aes so consideradas processos instantneos; atividades, por sua vez, esto sempre associadas a estados e tm durao no tempo. Vale a pena observar que, no mundo real, no h processos efetivamente instantneos. Por mais rpida que seja, uma ao ocorrer sempre em um intervalo de tempo. Esta simplificao de se considerar aes instantneas no modelo conceitual pode ser associada ideia de que a ao ocorre to rapidamente que no possvel interromp-la. Em contraste, uma atividade passvel de interrupo, sendo possvel, por exemplo, que um evento ocorra, interrompa a atividade e provoque uma mudana no estado do objeto antes da concluso da atividade. s vezes quer se modelar situaes em que uma ao instantnea realizada quando se entra ou sai de um estado, qualquer que seja a transio que o leve ou o retire desse estado. Seja o exemplo de um elevador. Neste contexto, ao parar em um certo andar, o elevador abre a porta. Suponha que a abertura da porta do elevador seja um processo que no possa ser interrompido e, portanto, que se opte por model-lo como uma ao. Essa ao dever ocorrer sempre que o elevador entrar no estado Parado e deve ser indicada no compartimento de aes desse estado como sendo uma ao de entrada no estado. A notao da UML para representar aes de entrada em um estado : entry / <<nomeAo>>. Para representar aes de sada de um estado a notao : exit / <<nomeAo>>. Restam ainda na Figura 7.2 dois tipos especiais de estados: os ditos estados inicial e final. Conforme citado anteriormente, um objeto est sempre em um e somente um estado. Isso implica que, ao ser instanciado, o objeto precisa estar em algum estado. O estado inicial precisamente esse estado. Graficamente, um estado inicial mostrado como um pequeno crculo preenchido na cor preta. Seu significado o seguinte: quando o objeto criado, ele colocado no estado inicial e sua transio de sada automaticamente disparada, movendo o objeto para um dos estados da mquina de estados (no caso da Figura 7.2, para o Estado1). Toda mquina de estados tem de ter um (e somente um) estado inicial. Note que o estado inicial no se comporta como um estado normal20, uma vez que objetos no se mantm nele por um perodo de tempo. Ao contrrio, uma vez que eles entram no estado inicial, sua transio de sada imediatamente disparada e o estado inicial abandonado. A transio de sada do estado inicial tem como evento gatilho implcito o evento responsvel pela criao do objeto (OLIV, 2007) e, na UML, esse evento no explicitamente representado. Estados iniciais tm apenas transies de sada. As transies de sada de um estado inicial podem ter condies de guarda e/ou aes associadas. Quando houver condies de guarda, deve-se garantir que sempre pelo menos uma das transies de sada poder ser disparada.
Por no se comportar como um estado normal, o estado inicial considerado um pseudoestado no metamodelo da UML.
20
143
Quando um objeto deixa de existir, obviamente ele deixa de estar em qualquer um dos estados. Isso pode ser dito no diagrama por meio de uma transio para o estado final. O estado final indica, na verdade, que o objeto deixou de existir. Na UML um estado final representado como um crculo preto preenchido com outro crculo no preenchido ao seu redor, como mostra a Figura 7.2. As transies para o estado final definem os estados em que possvel excluir o objeto. Classes cujos objetos no podem ser excludos, portanto, no possuem um estado final (OLIV, 2007). Assim como o estado inicial, o estado final no se comporta como um estado normal, uma vez que o objeto tambm no permanece nesse estado (j que o objeto no existe mais). Ao contrrio do estado inicial, contudo, uma mquina de estados pode ter vrios estados finais. Alm disso, deve-se representar o evento que elimina o objeto (na Figura 7.2, eventoDestruio). Os eventos mostrados nas transies so os mesmos eventos de requisio de ao discutidos na seo 7.1. Contudo, importante indicar no diagrama de estados os eventos maiores (eventos de domnio e requisies de aes) e no os eventos estruturais que efetivamente alteram o estado do objeto. Assim, neste texto sugere-se indicar como eventos de transies de uma mquina de estados as requisies de realizao de casos de uso do sistema (ou de fluxos de eventos especficos, quando um caso de uso tiver mais de um fluxo de eventos normal). Para facilitar a rastreabilidade, sugere-se usar como nome do evento exatamente o mesmo nome do caso de uso (ou do fluxo de eventos). Seja o exemplo de uma locadora de automveis, que possua, dentre outros, os casos de uso mostrados na Figura 7.3, os quais possuem os fluxos de eventos mostrados nas notas anexadas aos casos de uso.
Figura 7.3 Locadora de Automveis - Casos de Uso e Fluxos de Eventos Associados.
144
A classe Carro tem o seu comportamento definido pela mquina de estados do diagrama de grfico de estados da Figura 7.4. Ao ser adquirido (fluxo de eventos Comprar Carro, do caso de uso Negociar Carro), o carro colocado Em Preparao. Quando liberado para uso (fluxo de eventos Liberar Carro para Uso, do caso de uso Efetuar Manuteno de Carro), o carro fica Disponvel. Quando o cliente retira o carro (fluxo de eventos Retirar Carro, do caso de uso Efetuar Locao), este fica Em Uso. Quando devolvido (fluxo de eventos Devolver Carro, do caso de uso Efetuar Locao), o carro fica novamente Em Preparao. Quando Disponvel, um carro pode ser transferido de uma localidade para outra (fluxo de eventos Transferir Carro para Outra Localidade do caso de uso Transferir Carro). Durante o trnsito de uma localidade para outra, o carro est Em Trnsito, at ser recebido na localidade destino (fluxo de eventos Receber Carro Vindo de Outra Localidade, do caso de uso Transferir Carro), quando novamente colocado Em Preparao. Finalmente, carros Em Preparao podem ser vendidos (fluxo de eventos Vender Carro, do caso de uso Negociar Carro), quando deixam de pertencer locadora e so eliminados de sua base de informaes.
Figura 7.4 Diagrama de Grfico de Estados da Classe Carro Disponibilidade (adaptado de (OLIV, 2007)). Nem todas as classes precisam ser modeladas como mquinas de estados. Apenas classes modais, i.e., classes que apresentam comportamento varivel em funo do estado de seus objetos, necessitam ser modeladas como mquinas de estados. Alm disso, para os diagramas de estados serem efetivamente teis, recomenda-se modelar uma mquina de estados somente se a classe em questo tiver trs ou mais estados relevantes. Se uma classe possuir apenas dois estados relevantes, ainda cabe desenvolver uma mquina de estados. Contudo, de maneira geral, o diagrama tende a ser muito simples e a acrescentar pouca informao relevante que justifique o esforo de elaborao e manuteno do correspondente diagrama. Neste caso, os estados e transies podem ser levantados, sem no entanto elaborar um diagrama de estados.
145
Para algumas classes, pode ser til desenvolver mais do que um diagrama de estados, cada qual modelando o comportamento dos objetos da classe por uma perspectiva diferente. Em um determinado momento, um objeto est em um (e somente um) estado em cada uma de suas mquinas de estado. Cada diagrama define seu prprio conjunto de estados nos quais um objeto pode estar, a partir de diferentes pontos de vista (OLIV, 2007). Seja novamente o exemplo da classe Carro. A Figura 7.4 mostra os possveis estados de um carro segundo um ponto de vista de disponibilidade. Entretanto, independentemente da disponibilidade, do ponto de vista de possibilidade de negociao, um carro pode estar em dois estados (No Venda, Venda), como mostra a Figura 7.5. Vale ressaltar que os diferentes diagramas de estados de uma mesma classe no devem ter estados comuns. Cada diagrama deve ter seu prprio conjunto de estados e cada estado pertence a somente um diagrama de estados. J os eventos podem aparecer em diferentes diagramas de estados, inclusive de classes diferentes. Quando um evento aparecer em mais de um diagrama de estados, sua ocorrncia vai disparar as correspondentes transies em cada uma das mquinas de estados em que ele aparecer (OLIV, 2007).
Figura 7.5 Diagrama de Grfico de Estados da Classe Carro Possibilidade de Negociao (adaptado de (OLIV, 2007)). A Figura 7.5 mostra duas transies em que os eventos no so declarados explicitamente. No primeiro caso (quilometragem > 50000Km), o evento implcito torna a condio de guarda verdadeira na base de informaes do sistema. Esse evento corresponde ao registro no sistema de qual a quilometragem corrente do carro. Caso esse registro ocorra sempre no ato da devoluo do carro pelo cliente (fluxo de eventos Devolver Carro, do caso de uso Efetuar Locao) e/ou no ato do recebimento do carro vindo de outra localidade (fluxo de eventos Receber Carro Vindo de Outra Localidade, do caso de uso Transferir Carro), esses eventos poderiam ser explicitamente declarados. Contudo, se o registro pode ocorrer em vrios eventos diferentes, melhor deixar o evento implcito. O segundo caso (dataCorrente dataAquisicao > 1 ano) trata-se de um evento temporal, disparado pela passagem do tempo. Todos os estados mostrados at ento so estados simples, i.e., estados que no possuem subestados. Entretanto, h tambm estados compostos, os quais podem ser decompostos em um conjunto de subestados disjuntos e mutuamente exclusivos e um conjunto de transies (OLIV, 2007). Um subestado um estado aninhado em outro estado. O uso de estados compostos e subestados bastante til para simplificar a modelagem de comportamentos complexos. Seja o exemplo da Figura 7.4, que trata da disponibilidade de um carro. Suponha que seja necessrio distinguir trs subestados do estado Em Uso, a saber: Em Uso Normal, quando o carro no est quebrado nem em atraso; Quebrado, quando o cliente reportar um defeito no carro; e Em Atraso, quando o carro no foi devolvido na data de devoluo prevista e no est quebrado. A Figura 7.6 mostra a mquina de estados da classe
146
Carro considerando, agora, que, quando um carro est em uso, ele pode estar nesses trs subestados.
Figura 7.6 Diagrama de Estados da Classe Carro (Disponibilidade) com Subestados de Em Uso (adaptado de (OLIV, 2007)). Nesse diagrama, no est sendo mostrado que os estados Em Uso Normal, Em Atraso e Quebrado so, de fato, subestados do estado Em Uso e, portanto, transies comuns (por exemplo, aquelas provocadas pelo evento Devolver Carro) so repetidas. Isso torna o modelo mais complexo e fica claro que esta soluo representando diretamente os subestados (e omitindo o estado composto) no escalvel para sistemas que possuem muitos subestados, levando a diagramas confusos e desestruturados (OLIV, 2007). A Figura 7.7 mostra uma soluo mais indicada, em que tanto o estado composto quanto seus subestados so mostrados no mesmo diagrama. Uma outra opo ocultar a decomposio do estado composto, mantendo o diagrama como o mostrado na Figura 7.4, e mostrar essa decomposio em um diagrama de estados separado. Se um objeto est em um estado composto, ento ele deve estar tambm em um de seus subestados. Assim, um estado composto pode possuir um estado inicial para indicar o subestado padro do estado composto, como representado na Figura 7.7. Entretanto, deve-se considerar que as transies podem comear e terminar em qualquer nvel. Ou seja, uma transio pode ir (ou partir) diretamente de um subestado (OLIV, 2007). Assim, uma outra opo para o diagrama da Figura 7.7 seria fazer a transio nomeada pelo evento Retirar
147
Carro chegar diretamente ao subestado Em Uso Normal, ao invs de chegar ao estado composto Em Uso.
Figura 7.7 Diagrama de Estados da Classe Carro (Disponibilidade) com Estado Composto Em Uso (adaptado de (OLIV, 2007)). O estado de um objeto deve ser mapeado no modelo estrutural. De maneira geral, o estado pode ser modelado por meio de um atributo. Esse atributo deve ser monovalorado e obrigatrio ([1..1]). O conjunto de valores possveis do atributo o conjunto dos estados possveis, conforme descrito pela mquina de estados (OLIV, 2007). Assim, bastante natural que o tipo de dados desse atributo seja definido como um tipo de dados enumerado. Um nome adequado para esse atributo estado. Contudo, outros nomes mais significativos para o domnio podem ser atribudos. Em especial, quando uma classe possuir mais do que uma mquina de estado e, por conseguinte, mais do que um atributo de estado for necessrio, o nome do atributo de estado deve indicar a perspectiva capturada pela correspondente mquina de estados. interessante observar que algumas transies podem mudar a estrutura da classe. Quando os diferentes estados de um objeto no afetam a sua estrutura, mas apenas, possivelmente, os valores de seus atributos e associaes, diz-se que a transio estvel e os
148
diferentes estados podem ser mapeados para um simples atributo (WAZLAWICK, 2004), conforme discutido anteriormente. Entretanto, h situaes em que, conforme um objeto vai passando de um estado para outro, ele vai ganhando novos atributos ou associaes, ou seja, h uma mudana na estrutura da classe. Seja o exemplo de uma locao de carro. Como mostra a Figura 7.8, quando uma locao criada, ela est ativa, em curso normal. Quando o carro no devolvido at a data de devoluo prevista, a locao passa a ativa com prazo expirado. Se a locao estendida, ela volta a ficar em curso normal. Quando o carro devolvido, a locao fica pendente. Finalmente, quando o pagamento efetuado, a locao concluda.
Figura 7.8 Diagrama de Estados da Classe Locao. Locaes ativas (e em seus subestados, obviamente) tm como atributos: data de locao, data de devoluo prevista, valor devido e cauo. Quando uma locao vai para o estado pendente, necessrio registrar a data de devoluo efetiva e os problemas observados no carro devolvido. Finalmente, quando o pagamento efetuado, preciso registrar a data do pagamento, o valor e a forma de pagamento. Diz-se que as transies dos estados de Ativa para Pendente e de Pendente para Concluda so monotnicas21, porque a cada mudana de estado, novos relacionamentos (atributos ou associaes) so acrescentados (mas nenhum retirado). Uma soluo frequentemente usada para capturar essa situao no modelo conceitual estrutural consiste em criar uma nica classe (Locacao) e fazer com que certos atributos sejam nulos at que o objeto mude de estado, como ilustra a Figura 7.9. Essa forma de modelagem, contudo, pode no ser uma boa opo, uma vez que gera classes complexas com regras de consistncia que tm de ser verificadas muitas vezes para evitar a execuo de um mtodo que atribui um valor a um atributo especfico de um estado (WAZLAWICK, 2004), tal como dataPagamento.
Monotnico diz respeito a algo que ocorre de maneira contnua. Neste caso, a continuidade advm do fato de um objeto continuamente ganhar novos atributos e associaes, sem perder os que j possua.
21
149
Figura 7.9 Classe Locao com atributos inerentes a diferentes estados. possvel modelar essa situao desdobrando o conceito original em trs: um representando a locao efetivamente, outro representando a devoluo e outro representando o pagamento. Desta forma, captura-se claramente os eventos de locao, devoluo e pagamento, colocando as informaes de cada evento na classe correspondente, como ilustra a Figura 7.10.
Figura 7.10 Distribuindo as responsabilidades. Finalmente, vale pena comentar que estados de uma classe modal podem ser tratados por meio de operaes ao invs de atributos. Seja o exemplo anterior de locaes de carros (Figura 7.10). O estado de uma locao pode ser computado a partir dos atributos e associaes da classe Locacao, sem haver a necessidade de um atributo estado. Se uma locao no tem uma devoluo associada, ento ela est ativa. Estando ativa, se a data corrente menor ou igual data de devoluo prevista, ento a locao est em curso normal; caso contrrio, ela est com prazo expirado. Se uma locao possui uma devoluo, mas no possui um pagamento associado, ento ela est pendente. Finalmente, se a locao possui um pagamento associado, ento ela est concluda. Em casos como este, pode-se optar por tratar estado como uma operao e no como um atributo. Opcionalmente, pode-se utilizar a operao para calcular o valor de um atributo derivado22 estado. Atributos derivados so representados na UML precedidos por uma barra (no exemplo, /estado).
Um atributo derivado quando seu valor pode ser deduzido ou calculado a partir de outras informaes (atributos e associaes) j existentes no modelo estrutural.
22
150
7.3 - Diagramas de Sequncia

Uma das coisas mais difceis de compreender e capturar em um sistema orientado a objetos o fluxo global de controle. As descries de casos de uso capturam de maneira textual esse fluxo, mas isso normalmente insuficiente para definir as trocas de mensagens entre os objetos do sistema. Diagramas de interao tm por objetivo ajudar a visualizar essa sequncia, tendo como foco o fluxo de controle de um objeto para outro. Tipicamente, um diagrama de interao captura o comportamento de um grupo de objetos em um caso de uso isolado, mostrando um nmero de objetos-exemplos e as mensagens que so passadas entre esses objetos no contexto do caso de uso. Assim, os diagramas de interao so utilizados para modelar aspectos dinmicos dos sistemas, com nfase na distribuio de responsabilidades entre classes e no fluxo de controle ao longo das mesmas. A modelagem de aspectos dinmicos de sistemas pode ser feita construindo-se roteiros de cenrios (p.ex., fluxos de eventos de casos de uso, fragmentos deles ou operaes) que envolvem a interao entre certos objetos de interesse e as mensagens trocadas entre eles. Na UML, a modelagem desses roteiros feita com o uso dos diagramas de interao (BOOCH; RUMBAUGH; JACOBSON, 2006). Tipicamente, um diagrama de interao ilustra o comportamento de um grupo de objetos colaborando para a realizao de um certo caso de uso (ou de um fluxo de eventos de um caso de uso), mostrando um nmero de instncias exemplares de classes e as mensagens que so trocadas entre eles no contexto do caso de uso. H dois tipos de diagramas de interao: diagramas de sequncia e diagramas de comunicao. Os diagramas de sequncia do nfase ordenao temporal das mensagens, enquanto os diagramas de comunicao do nfase organizao estrutural dos objetos. Esses dois tipos de diagramas so semanticamente equivalentes. Ou seja, possvel converter um no outro sem perda de informao (BOOCH; RUMBAUGH; JACOBSON, 2006). Neste texto, so abordados somente os diagramas de sequncia. Conforme citado acima, um diagrama de sequncia um diagrama de interao que d nfase ordenao temporal das mensagens. Ele organizado ao longo de dois eixos. Os objetos que participam da interao so colocados no eixo horizontal, na parte superior do diagrama. O objeto que inicia a interao colocado esquerda e os objetos subordinados vo aparecendo direita. Quando um diagrama de sequncia modela um cenrio de execuo de um caso de uso iniciado por um ator, tipicamente uma instncia desse ator o objeto mais esquerda no diagrama. As mensagens que os objetos enviam e recebem so colocadas ao longo do eixo vertical, na ordem cronolgica de envio, de cima para baixo. Isso proporciona ao leitor uma clara identificao do fluxo de controle ao longo do tempo. A Figura 7.11 ilustra os principais elementos de modelagem de diagramas de sequncia.
151
Figura 7.11 Elementos de Modelagem de Diagramas de Sequncia da UML. Como ilustra a figura acima, um objeto mostrado como um retngulo com uma linha vertical pontilhada anexada. Essa linha chamada de linha de vida do objeto e representa a existncia do objeto durante a interao. Cada mensagem representada por uma seta direcionada entre as linhas de vida dos objetos emissor e receptor da mensagem. A ordem temporal das mensagens trocadas de cima para baixo. Opcionalmente, nmeros antes das mensagens so usados para indicar a sua ordem. Cada mensagem rotulada com pelo menos o nome da mensagem. Adicionalmente, podem-se incluir tambm parmetros da mensagem e alguma informao de controle, tal como uma condio de guarda ([condio]), indicando que a mensagem s enviada se a condio for verdadeira. H diferentes tipos de mensagens (BOOCH; RUMBAUGH; JACOBSON, 2006): Uma mensagem de criao indica que o objeto receptor est sendo criado naquele momento. Assim, ao contrrio dos demais objetos, ele aparece nivelado na altura do envio da mensagem e no na parte superior do diagrama. Uma mensagem sncrona de chamada invoca uma operao no objeto receptor, passando o controle para esse objeto. Um objeto pode enviar uma mensagem para ele mesmo, resultando em uma chamada local de uma operao.
152
Uma mensagem assncrona envia um sinal para o objeto receptor, mas o objeto emissor continua sua prpria execuo. O objeto receptor recebe o sinal e decide de forma independente o que fazer. A representao de mensagens assncronas ligeiramente diferente da representao de mensagens sncronas. A primeira tem uma seta fina, enquanto a segunda tem uma seta grossa. Uma mensagem de retorno indica uma resposta a uma mensagem sncrona (retorno de chamada) e no uma nova mensagem. Para diferenciar, mensagens de retorno so simbolizadas por uma linha tracejada com uma seta fina. A mensagem de retorno pode ser omitida, j que h um retorno implcito aps qualquer chamada (mensagem sncrona de chamada). Contudo, muitas vezes til mostrar os valores de retorno. Por fim, uma mensagem de destruio elimina o objeto receptor, deixando o mesmo de existir. As mensagens de destruio so acompanhadas do smbolo de destruio de objeto.
O foco de controle mostra o perodo durante o qual um objeto est desempenhando uma ao, diretamente ou por meio de um procedimento subordinado. Ele mostrado como um retngulo estreito sobre a linha de vida do objeto. A parte superior do retngulo alinhada com o incio da ao; a parte inferior alinhada com a sua concluso e pode ser delimitada por uma mensagem de retorno (BOOCH; RUMBAUGH; JACOBSON, 2006). Durante a modelagem do comportamento de um sistema, muitas vezes importante mostrar condicionais, laos e a execuo concorrente de sequncias. Para modelar essas situaes, operadores de controle podem ser utilizados. Um operador de controle apresentado como uma regio retangular no diagrama de sequncias, contendo um rtulo no canto superior esquerdo, informando o tipo de operador de controle. Os tipos de operadores de controle mais comuns so (BOOCH; RUMBAUGH; JACOBSON, 2006): Execuo opcional (rtulo opt): o corpo do operador de controle executado somente se a condio de guarda na entrada do operador for verdadeira. Execuo alternativa (rtulo alt): o corpo do operador de controle dividido em subregies por linhas horizontais tracejadas, sendo que cada subregio representa um ramo de um condicional e executada somente se sua condio de guarda for verdadeira. Execuo paralela (rtulo par): o corpo do operador de controle dividido em subregies por linhas horizontais tracejadas, sendo que cada subregio representa uma computao paralela (concorrente). Execuo iterativa (rtulo loop): o corpo do operador de controle executado repetidamente enquanto a condio de guarda na entrada do operador for verdadeira. A condio de guarda testada no incio de cada iterao.
Ainda que a UML proveja um conjunto de operadores de controle para representar fluxos de controle alternativos, paralelos e iterativos, diagramas de sequncia no so muito apropriados para representar processos com muito comportamento condicional e repetitivo. Para esses casos, ainda que seja possvel utilizar os operadores de controle, normalmente melhor utilizar diagramas separados para fluxos de eventos de exceo ou variantes.
153
H uma certa controvrsia em relao fase do desenvolvimento em que diagramas de sequncia devem ser elaborados. Alguns autores utilizam diagramas de sequncia simplificados durante a anlise de requisitos e julgam que s cabe elaborar diagramas de sequncia completos na fase de projeto. Blaha e Rumbaugh (2006), por exemplo, representam o sistema como um nico objeto do tipo caixa preta e mostram apenas o dilogo e a interao entre os atores e o sistema. Wazlawick (2004) aponta que essa tambm uma opo, mas acha mais til representar o sistema como dois objetos genricos, identificando dois nveis da futura arquitetura (a ser efetivamente produzida na fase de projeto). O primeiro objeto representa a interface do sistema e o segundo, mais interno, representa o controlador do sistema. O ator s pode se comunicar diretamente com a classe de interface e esta, por sua vez, comunica-se com o controlador. Assim, em abordagens como as propostas por Blaha e Rumbaugh (2006) e Wazlawick (2004), os diagramas de sequncia basicamente capturam eventos de sistema (ou seja, requisies dos atores para o sistema) e respostas do sistema (ou seja, envio de informaes do sistema para os atores). Seja o exemplo de um caso de uso Devolver Exemplar de Livro de um sistema de biblioteca, cuja descrio a seguinte:
1. 2.
3. 4.
O bibliotecrio informa cada um dos exemplares que esto sendo devolvidos. Para cada exemplar devolvido: 2.1 Caso o exemplar esteja em atraso (data corrente > data de devoluo prevista), calcular multa (multa = valor de referncia de multa * nmero de dias de atraso) 2.2 Adicionar o valor da multa ao valor a ser pago. 2.3 Verificar se h um reserva pendente para o livro do exemplar. 2.4 Se no h reserva pendente, tornar o exemplar disponvel; caso contrrio colocar o exemplar no estado reservado. Se o valor a ser pago for maior do que zero, informar valor a ser pago, solicitando pagamento. Registrar a devoluo, indicando os exemplares devolvidos e o valor pago de multa e atribuindo a data corrente data de devoluo.
A Figura 7.12 mostra um diagrama de sequncia em que o sistema representado como um nico objeto do tipo caixa preta, mostrando apenas as interaes entre os atores e o sistema. Requisies internas do sistema so mostradas como mensagem do sistema para o prprio sistema. Quando se opta por representar o sistema por meio de dois objetos genricos (interface e controlador), o ator se comunica com a classe de interface e esta, por sua vez, comunica-se com o controlador, como mostra a Figura 7.13. Neste caso merecem destaque os esteretipos da UML para classes de interface (um crculo com uma pequena linha vertical associada esquerda) e classes controladoras (um crculo com uma seta em sua parte superior), distinguindo objetos de interface e controladores de outros objetos comuns (representados por retngulos). Outro ponto a destacar que, normalmente, representam-se as interaes entre atores e interfaces do sistema indicando apenas as informaes enviadas de um para o outro (entradas e sadas do sistema). Cabe interface enviar uma requisio para o controlador do sistema realizar uma operao efetivamente.
154
Figura 7.12 Diagrama de Sequncia com sistema representado por um nico objeto. O efeito geral das duas abordagens, contudo, no muito diferente. Ambas capturam apenas as interaes entre atores e sistema e as requisies geradas internamente pelo sistema. Assim, pouca informao acrescentada em relao descrio do caso de uso. Basicamente, melhora-se a visualizao de fluxos de controle. Entretanto, com essas abordagens no se exploram a distribuio de responsabilidades entre classes do domnio e o fluxo de controle ao longo das mesmas e, por conseguinte, no so identificadas operaes das classes de domnio. Uma terceira opo de elaborao de diagramas de sequncia consiste em representar, j na fase de anlise de requisitos, interaes envolvendo objetos do domnio do problema. A ideia representar objetos do domnio interagindo entre si e com os objetos controladores do sistema, de modo a executar as requisies feitas. Com essa abordagem, possvel identificar operaes de classes do domnio do problema. A Figura 7.14 ilustra essa abordagem, tomando por base o diagrama de classes do domnio mostrado na Figura 7.15, o qual mostra apenas o fragmento do modelo estrutural relevante para o caso de uso em questo.
155
Figura 7.13 Diagrama de Sequncia com sistema representado por dois objetos: Interface e Controlador. O principal problema da abordagem da Figura 7.14 que ela requer mais suposies relativas arquitetura do sistema. Assim como na abordagem mostrada na Figura 7.13, assume-se que um sistema possui diferentes tipos de classes. Neste caso so considerados trs tipos: classes de interface, responsveis pela interao com os atores; classes controladoras, responsveis por receber as informaes da interface e enviar requisies para classes do negcio; e classes do negcio, que correspondem aos conceitos do domnio. Porm, dependendo do padro arquitetnico escolhido, as interaes podem se dar de diferentes formas. Esta a principal argumentao para elaborar diagramas de sequncia completos apenas na fase de projeto. Neste texto, sugere-se escolher, dentre os objetos conhecidos a priori (aqueles informados pelo ator via interface), aquele que mais indicado para responder requisio e, navegando suas associaes, mostrar as interaes entre os objetos do domnio do problema. Outras responsabilidades no passveis de distribuio para objetos do domnio devem ficar a cargo da classe controladora do sistema.
156
Figura 7.14 Diagrama de Sequncia mostrando objetos do domnio do problema. Mensagens trocadas entre objetos em um diagrama de sequncia devem ser mapeadas como operaes na classe do objeto receptor da mensagem. Assim, toda mensagem que chega a um objeto aponta para a necessidade de um mtodo com mesma assinatura na classe desse objeto, contribuindo de maneira decisiva para a identificao de mtodos nas classes. Assim, a partir do diagrama de sequncia da Figura 7.14, chegam-se s operaes nas classes de domnio, conforme ilustra a Figura 7.15. Nessa figura no so mostradas as operaes bsicas (get, set, criar), o que aponta para o fato do diagrama de sequncia da Figura 7.15 ter sido til para identificar as trs operaes mostradas no diagrama de classes (devolver e calcularMulta da classe Exemplar e existeReservaPendente da classe Livro), bem como as sequncias de chamadas a operaes bsicas que as compem.
157
Figura 7.15 Diagrama de Classes com operaes advindas do Diagrama de Sequncia. A elaborao de diagramas de sequncia tende a ser trabalhosa e, portanto, deve-se analisar a relao custo-benefcio de se elaborar esses diagramas. Neste texto, sugerimos usar diagramas de sequncia para complementar as descries de casos de uso que sejam complexos, normalmente aqueles associados aos principais processos de negcio sendo apoiados pelo sistema. Elaborar diagramas de sequncia para casos de uso simples, tais como casos de uso cadastrais e de consulta, dificilmente adicionar algum valor ao projeto. As operaes descobertas a partir das mensagens trocadas em um caso de uso dessa natureza so, na maioria das vezes, operaes bsicas e, portanto, h pouca utilidade prtica na elaborao desses diagramas. Os diagramas de sequncia capturam o dilogo e a interao entre atores e o sistema e entre os objetos do sistema, mas eles no mostram claramente alternativas, decises e fluxos concorrentes. Normalmente, elabora-se um diagrama de sequncia para o fluxo principal de eventos e um diagrama adicional para cada fluxo de exceo ou variante. Diagramas de atividade permitem consolidar todo esse comportamento em um nico diagrama, documentando ramificaes, bifurcaes e unies do fluxo de controle (BLAHA; RUMBAUGH, 2006). Assim, os diagramas de atividades servem para refinar modelos de casos de uso, de modo que um desenvolvedor possa estudar fluxos de trabalho complexos. Eles suplementam o foco centrado em objetos e suas trocas de mensagens, capturado por diagramas de sequncia (BOOCH; RUMBAUGH; JACOBSON, 2006).
7.4 - Diagramas de Atividades

Um diagrama de atividades como um fluxograma, no sentido que focaliza o fluxo de controle de uma atividade para outra. Entretanto, ao contrrio de um fluxograma tradicional, um diagrama de atividades mostra, alm de fluxos sequenciais e ramificaes de controle, fluxos concorrentes (BOOCH; RUMBAUGH; JACOBSON, 2006; BLAHA; RUMBAUGH, 2006). O propsito de um diagrama de atividades mostrar as etapas de um processo complexo e a sequncia entre elas (BLAHA; RUMBAUGH, 2006). Diagramas de atividades so usados para representar processos, sendo utilizados tanto para modelar processos de negcio quanto para representar a realizao de um caso de uso. Eles foram adicionados UML relativamente tarde, adquirindo status de um tipo de diagrama
158
somente na UML 2.0. At a UML 1.5, diagramas de atividades eram considerados um tipo especial de diagrama de estados. Os diagramas de atividades so muito usados para modelar processos de negcio e fluxos de trabalho em organizaes (ver seo 3.3), uma vez que esses processos / fluxos de trabalho envolvem muitas pessoas e unidades organizacionais que realizam atividades concorrentemente (BLAHA; RUMBAUGH, 2006). Principalmente no contexto de sistemas corporativos e de misso crtica, o sistema em desenvolvimento estar funcionando no contexto de processos de negcio de mais alto nvel e pode ser til usar diagramas de atividades para modelar esses processos com o intuito de investigar as formas como humanos e os vrios sistemas automatizados colaboram (BOOCH; RUMBAUGH; JACOBSON, 2006). Esse uso importante do diagrama de atividades, contudo, est fora do escopo deste texto e, portanto, no ser aqui abordado. No contexto da modelagem comportamental de sistemas (foco deste texto), os diagramas de atividades podem ser usados para modelar o fluxo de trabalho em um caso de uso. Para essa finalidade, os principais elementos de modelagem dos diagramas de atividades da UML utilizados so: atividades, fluxos de controle, pontos de iniciao e concluso, desvios (ou ramificaes), bifurcao e unio, fluxos de objetos e regies de expanso. Na modelagem de processos, utilizam-se tambm raias para indicar quem (que pessoa ou unidade organizacional) responsvel por uma atividade. Uma atividade uma poro significativa de trabalho dentro de um fluxo de trabalho. Atividades podem ser atmicas ou complexas. Uma atividade atmica (i.e., que no pode ser decomposta) dita uma ao na UML. Uma atividade complexa composta de outras atividades (atmicas ou complexas) e na UML representada por um n de atividade. Assim, um n de atividade representa um grupo de aes ou de outros ns de atividade aninhados, que possui uma subestrutura visvel, representada em um outro diagrama de atividades (BOOCH; RUMBAUGH; JACOBSON, 2006). Atividades so representadas por elipses alongadas. Quando uma atividade concluda, o fluxo de controle passa imediatamente para a atividade seguinte. O fluxo de controle mostrado por meio de uma seta no rotulada de uma atividade para a sua sucessora. Um fluxo de controle inicia e termina em algum lugar. Os pontos de iniciao e de concluso do fluxo de controle so mostrados em um diagrama de atividades usando a mesma notao de estados inicial e final de diagramas de grficos de estados, respectivamente. Quando um diagrama de atividades ativado, o fluxo de controle inicia no ponto de iniciao e avana por meio de seta(s) de fluxo de controle em direo (s) primeira(s) atividade(s) a ser(em) realizada(s). Quando o ponto de concluso atingido, todo o processo encerrado e a execuo do diagrama de atividades termina (BOOCH; RUMBAUGH; JACOBSON, 2006; BLAHA; RUMBAUGH, 2006). A Figura 7.16 mostra a notao da UML para atividades, fluxos de controle e pontos de iniciao e concluso.
159
Figura 7.16 - Notao Bsica da UML para Diagramas de Atividades. Os elementos da Figura 7.16 s permitem modelar sequncias de atividades. Contudo, a maioria dos fluxos de trabalho envolve fluxos alternativos, concorrentes e/ou iterativos. Para representar essas estruturas de controle, so necessrios outros elementos de modelagem. Em diagramas de atividades da UML, fluxos alternativos, concorrentes e/ou iterativos podem ser representados por meio de desvios (ou ramificaes), bifurcaes e unies, e regies de expanso, respectivamente. Um desvio ou ramificao permite especificar caminhos alternativos a serem seguidos, tomando por base alguma expresso booleana. Uma ramificao possui um fluxo de entrada e dois ou mais de sada. Em cada fluxo de sada colocada uma expresso booleana, a qual avaliada quando o controle atinge a ramificao. As condies no podem se sobrepor, pois seno o fluxo de controle poderia seguir por mais de um caminho, o que no admissvel em uma ramificao. Alm disso, elas tm de cobrir todas as possibilidades, pois, caso contrrio o fluxo de controle pode ficar sem ter para onde seguir em alguma situao. Para evitar esse problema, pode-se utilizar a condio else, a qual satisfeita caso nenhuma outra condio seja satisfeita (BOOCH; RUMBAUGH; JACOBSON, 2006; BLAHA; RUMBAUGH, 2006). Uma ramificao representada na UML por um losango. Quando dois caminhos de controle alternativos se fundem novamente, pode-se utilizar o mesmo smbolo para mescllos. Na fuso, contudo, h duas ou mais setas de fluxo de controle de entrada e somente uma de sada. A Figura 7.17 ilustra a notao de desvios e fuses.
Figura 7.17 Ramificaes em Diagramas de Atividades da UML.
160
Para mostrar atividades realizadas concorrentemente, podem-se utilizar bifurcaes e unies, as quais so representadas por barras de sincronizao. Uma barra de sincronizao representada por uma linha grossa horizontal ou vertical. Uma bifurcao tem de ter um nico fluxo de controle de entrada e dois ou mais fluxos de sada, cada um deles representando um fluxo de controle independente. As atividades associadas a cada um desses caminhos prosseguem paralelamente, indicando que as atividades ocorrem concorrentemente. J uma unio representa a sincronizao de um ou mais fluxos de controle concorrentes. Uma unio tem de ter dois ou mais fluxos de entrada e apenas um fluxo de controle de sada. Na unio, os fluxos concorrentes de entrada so sincronizados, significando que cada um deles aguarda at que todos os fluxos de entrada tenham atingido a unio, a partir da qual o fluxo de controle de sada prossegue. De maneira geral, deve haver um equilbrio entre bifurcaes e unies, indicando que o nmero de fluxos de controle que deixam uma bifurcao deve ser equivalente ao nmero de fluxos que chegam a uma unio correspondente (BOOCH; RUMBAUGH; JACOBSON, 2006). A Figura 7.18 ilustra a notao de bifurcaes e unies.
Figura 7.18 Bifurcaes e Unies em Diagramas de Atividades da UML. Para representar atividades que ocorrem vrias vezes, operando sobre elementos de um conjunto, pode-se utilizar regies de expanso. Uma regio de expanso representa um fragmento do diagrama de atividades que realizado operando sobre os elementos de uma lista ou conjunto. Ela representada por uma linha tracejada em torno da regio do diagrama que envolve as atividades iterativas. A regio executada uma vez para cada elemento do conjunto de entrada (BOOCH; RUMBAUGH; JACOBSON, 2006). Muitas vezes til representar os objetos requeridos (entradas) e produzidos (sadas) por uma atividade em um diagrama de atividades. possvel especificar os objetos envolvidos nas atividades, conectando-os s atividades que os produzem ou consomem. Alm de representar objetos e o seu fluxo nas atividades, pode-se representar, ainda, o estado em que se encontra o objeto. A Figura 7.19 mostra a notao de objetos, fluxos de objetos e estado do objeto.
161
Figura 7.19 Objetos e Fluxos de Objetos em Diagramas de Atividades da UML. Um fluxo de objetos implica em um fluxo de controle, pois representa o fluxo de um objeto de uma atividade para outra. Portanto, desnecessrio desenhar um fluxo de controle entre as atividades conectadas por fluxos de objetos (BOOCH; RUMBAUGH; JACOBSON, 2006). Algumas diretrizes devem ser observadas na elaborao de diagramas de atividades. Primeiro, as atividades em um diagrama de atividades devem estar em um mesmo nvel de detalhes. No devem coexistir em um mesmo diagrama de atividades em um nvel fino de detalhe e atividades muito abstratas. Esta orientao muito importante, sobretudo, quando diagramas de atividades so usados para modelar processos de negcio. Segundo, em ramificaes, apenas uma (e somente uma) das condies deve ser satisfeita. Por fim, para ajudar os usurios a entender um diagrama de atividades, pode ser til ilustrar a execuo do mesmo usando fichas de atividade. Uma ficha colocada no ponto de iniciao do diagrama e ela vai sendo deslocada pelas atividades do diagrama. Quando houver uma bifurcao, mltiplas fichas vo surgir, uma para cada fluxo de sada. De maneira anloga, uma unio do controle reduz o conjunto de fichas de entrada para uma nica ficha de sada (BLAHA; RUMBAUGH, 2006). Neste texto, defendemos o uso de diagramas de atividades para complementar a viso comportamental de casos de uso complexos. Elaborar diagramas de atividade para casos de uso simples, tais como casos de uso cadastrais e de consulta, dificilmente adicionar algum valor ao projeto e, portanto, tais diagramas so dispensveis. A Figura 7.20 mostra um diagrama de atividades para o mesmo caso de uso usado como exemplo para a elaborao do diagrama de sequncia da Figura 7.14. Nessa figura, a rea demarcada por uma linha tracejada corresponde a uma regio de expanso, indicando que as atividades nessa regio so realizadas para todo conjunto de exemplares sendo devolvidos.
162
Figura 7.20 Diagramas de Atividades: Exemplo de Devoluo de Livros. Vale a pena destacar quais so as informaes clarificadas com a elaborao desse diagrama. Sequncias, desvios e atividades que podem ser realizadas paralelamente so melhor visualizadas aqui. Alm disso, fcil representar fluxos alternativos, como o caso da no confirmao do pagamento. Por fim, a mudana de estado dos objetos tambm visvel neste diagrama.
163
7.5 Especificao das Operaes

Uma vez estudado o comportamento do sistema, tem-se uma base para a definio das operaes das classes que compem o sistema. Operaes correspondem a servios que podem ser solicitados aos objetos de uma classe e so apresentadas na seo inferior do smbolo de classe, com a seguinte sintaxe23 para a sua assinatura (BOOCH; RUMBAUGH; JACOBSON, 2006):
visibilidade nome(lista_de_parmetros): tipo_de_retorno
A visibilidade de uma operao indica em que situaes ela visvel por outras classes, podendo uma operao ser pblica, protegida, privada e de pacote, da mesma forma que atributos (ver seo 6.2.1). A informao de visibilidade inerente fase de projeto e no deve ser expressa em um modelo conceitual. Para nomear uma operao, sugere-se o uso de um verbo no infinitivo, o qual pode ser combinado com complementos, omitindo-se preposies. A exceo fica por conta de operaes com retorno booleano, para as quais sugere-se usar um nome que d uma noo de uma pergunta sendo feita. O nome do atributo deve ser iniciado com letra minscula, enquanto os nomes dos complementos devem iniciar com letras maisculas, sem dar um espao em relao palavra anterior. Acentos no devem ser utilizados. Ex.: calcularValor, estahAtrasado. Na assinatura de uma operao, podem ser indicados zero ou mais parmetros separados por vrgula, cada um deles com a sintaxe abaixo24, onde nome o nome para referenciar o parmetro, tipo seu tipo de dados ou classe, e valor_padro o valor que ser assumido se um valor no for informado.
nome: tipo [= valor_padro]
O tipo_de_retorno indica a classe ou o tipo de dado do valor retornado pela operao, o qual pode ser uma classe, um tipo de dado primitivo ou um tipo de dado especfico de domnio. Caso uma operao no tenha retorno, nada especificado. Conforme discutido anteriormente, h operaes, ditas bsicas, que simplesmente manipulam atributos e associaes, criam ou destroem objetos. Essas operaes no so representadas nos diagramas de classes, nem especificadas e documentadas no Dicionrio de Projeto, j que podem ser deduzidas do modelo conceitual estrutural. As demais operaes devem ser descritas no Dicionrio de Projeto, dando uma descrio sucinta de seu propsito. Leitura Complementar Conforme apontado no Captulo 6, o livro Conceptual Modeling of Information Systems, de Antoni Oliv (OLIV, 2007) dedicado modelagem conceitual de sistemas e, portanto, uma tima referncia para os interessados em se aperfeioar nessa rea. Vrias das discusses feitas nesse livro foram incorporadas nestas notas de aula. Os captulos 11 e 12 discutem, respectivamente, eventos de domnio e eventos de requisio de aes, discutidos na seo 7.1 destas notas de aula. Os captulos 13 e 14 desse livro abordam a elaborao de diagramas de transio de estados.
A UML admite outras informaes na assinatura de uma operao. Entretanto, essas so as notaes mais comumente utilizadas. 24 Idem comentrio anterior.
23
164
O Captulo 4 de (WAZLAWICK, 2004) Operaes e Consultas de Sistema discute aspectos relacionados elaborao de diagramas de sequncia. No Captulo 5 Modelagem Conceitual h uma boa discusso sobre classes modais, ainda que no se aborde a elaborao de diagramas de estados. Em (BOOCH; RUMBAUGH; JACOBSON, 2006), merecem ateno os captulos 19 (Diagramas de Interao), 20 (Diagramas de Atividades), 22 (Mquinas de Estados) e 25 (Diagramas de Grficos de Estados). As notaes da UML para os diagramas abordados neste captulo so tratadas com bastante detalhes, uma vez que este um livro sobre a UML. Alm desses captulos, merece ateno a parte do Captulo 9 (Classes Avanadas) que trata da sintaxe de operaes. Finalmente, em (BLAHA; RUMBAUGH, 2006), os captulos 5, 6 e 12 abordam o desenvolvimento de diagramas de estados, enquanto os captulos 7, 8 e 13 discutem a elaborao de diagramas de sequncia e de atividades, dentre outras coisas. Referncias do Captulo BLAHA, M., RUMBAUGH, J., Modelagem e Projetos Baseados em Objetos com UML 2, Elsevier, 2006. BOOCH, G., RUMBAUGH, J., JACOBSON, I., UML Guia do Usurio, 2a edio, Elsevier Editora, 2006. OLIV, A., Conceptual Modeling of Information Systems, Springer, 2007. WAZLAWICK, R.S., Anlise e Projeto de Sistemas de Informao Orientados a Objetos, Elsevier, 2004.
Captulo 8 Qualidade e Agilidade em Requisitos
165

Durante o processo de Engenharia de Requisitos, diversos documentos e modelos podem ser elaborados. Durante o levantamento de requisitos, requisitos de usurio so capturados em um Documento de Requisitos. Na fase de anlise, esses requisitos so especificados usando diagramas diversos organizados em dois modelos principais: o modelo estrutural e o modelo comportamental. O modelo conceitual estrutural de um sistema tem por objetivo descrever as informaes que esse sistema deve representar e gerenciar. O modelo comportamental, por sua vez, prov uma viso ampla do comportamento do sistema. No que tange modelagem do comportamento de um sistema, em um nvel superior, os diagramas de casos de uso proveem uma viso externa da funcionalidade do sistema e dos atores nela envolvidos. O comportamento dos casos de uso elaborado por meio de descries de casos de uso. Essas descries podem ser refinadas por meio de diagramas de atividade ou de sequncia. Os diagramas de sequncia tipicamente mostram vises parciais. Eles, geralmente, so desenvolvidos apenas para fluxos de eventos principais ou so desenvolvidos um diagrama de sequncia para o fluxo principal de eventos e diagramas adicionais para os fluxos de exceo e variantes. Diagramas de atividade permitem consolidar todo esse comportamento em um nico diagrama, documentando ramificaes, bifurcaes e unies do fluxo de controle. Diagramas de sequncia so bons para mostrar colaboraes entre objetos em um caso de uso. J os diagramas de atividade so teis para focalizar as atividades de um processo complexo. Contudo, esses dois tipos de diagramas no so apropriados para observar o comportamento de um objeto isolado ao longo de vrios casos de uso. Para tal, so utilizados diagramas de grfico de estados. Neste contexto, uma questo importante precisa ser tratada: como fazer a engenharia dos requisitos de um sistema com qualidade, mas ao mesmo tempo de maneira gil, sem despender tempo elaborando diagramas que acrescentam pouco valor ao projeto? No se deve perder de vista que o propsito da modelagem ajudar a entender o problema de modo que se possa produzir um sistema que atenda s necessidades do usurio. Produzir artefatos desnecessrios transforma o trabalho de Engenharia de Software em burocracia de software. Para tratar essa questo, primeiro deve-se considerar a tica da qualidade. Sob esse ponto de vista, fundamental garantir consistncia entre os diversos artefatos produzidos. Os diversos documentos e modelos proveem diferentes vises de um mesmo sistema e, portanto, devem estar compatveis entre si. importante observar que os modelos produzidos envolvem conceitos comuns, dentre eles classes, objetos e operaes, e que essencial manter as informaes rastreveis. Ambos os modelos, estrutural e comportamental, so necessrios para um completo entendimento de um problema, embora a importncia de cada um dos diagramas envolvidos varie de projeto para projeto e em funo do tipo de aplicao a ser desenvolvida. Esses modelos se unem para dar forma s classes com atributos, associaes e operaes, que sero a base para o projeto e a implementao. Em especial, as operaes
166
envolvem dados (objeto destino, argumentos, variveis e retorno), controle (sequncia) e interaes (mensagens e chamadas). Assim, para uma completa especificao das classes, o que envolve a especificao de suas operaes, so necessrios os modelos estrutural e comportamental. Alm disso, necessrio compar-los para garantir que no h inconsistncias entre eles (BLAHA; RUMBAUGH, 2006). Para apoiar a verificao da consistncia, tcnicas de leitura de modelos de anlise podem ser aplicadas. Algumas dessas tcnicas so discutidas na seo 8.1. Do ponto de vista de agilidade no processo de Engenharia de Requisitos, merece destaque a modelagem gil. A modelagem gil prov uma srie de princpios e valores que podem ser aplicados para nortear a deciso de quais diagramas produzir, de modo que o esforo despendido na anlise de requisitos seja compensador. A modelagem gil discutida na seo 8.2. Por fim, visando tanto qualidade quanto a agilidade, podem ser aplicadas tcnicas de reutilizao de requisitos. A reutilizao tende a proporcionar qualidade, uma vez que os requisitos, modelos ou outros artefatos reutilizados j foram avaliados em outros contextos e, por conseguinte, tendem a prover solues j avaliadas. Do ponto de vista da agilidade, ao se reutilizar algum artefato da Engenharia de Requisitos, espera-se que haja um aumento da produtividade, uma vez que no se est partindo do zero. A reutilizao na Engenharia de Requisitos discutida na seo 8.3.
8.1 Tcnicas de Leitura de Modelos da Anlise de Requisitos

Na verificao da consistncia entre os diversos modelos e diagramas produzidos durante um processo de software orientado a objetos, devem ser consideradas tcnicas de leitura de modelos orientados a objetos, as quais podem ser de dois tipos: tcnicas para leitura vertical e para leitura horizontal. As tcnicas para leitura horizontal dizem respeito consistncia entre artefatos elaborados em uma mesma fase, procurando verificar se esses artefatos esto descrevendo consistentemente diferentes aspectos de um mesmo sistema, no nvel de abstrao relacionado fase em questo. Tcnicas verticais referem-se consistncia entre artefatos elaborados em diferentes fases. Neste texto, o foco recai sobre tcnicas de leitura horizontal, mais especificamente entre os modelos produzidos durante a anlise de requisitos. A Figura 8.1 mostra as relaes existentes entre os diferentes artefatos elaborados na fase de anlise de requisitos, indicando as tcnicas de leituras associadas. Essa figura destaca a importncia de dois artefatos produzidos na anlise de requisitos: as descries de casos de uso e os diagramas de classes. Como se pode notar pela figura, esses dois artefatos tm relaes com quase todos os demais, o que mostra o papel central que eles desempenham no processo de desenvolvimento orientado a objetos. Na sequncia, cada uma das tcnicas referenciadas na Figura 8.1 descrita.
167
H9 Dicionrio de Projeto H5 H2 Diagrama de Atividades H8
Descries de Casos de Uso
H1
Diagrama de Casos de Uso
H6
H7
Diagrama de Classes
H3
Diagrama de Estados H4
Diagrama de Sequncia
H10 Figura 8.1 Tcnicas de Leitura Horizontal de Modelos Orientados a Objetos Fase de Anlise de Requisitos.
H1 Descries de Casos de Uso x Diagrama de Casos de Usos Os seguintes aspectos devem ser verificados nas relaes entre diagramas de casos de uso e descries de casos de uso: a) Para cada caso de uso identificado em um diagrama de casos de uso, deve haver uma descrio de caso de uso associada. b) Os nomes dos casos de uso nos dois artefatos devem ser os mesmos. c) As descries dos casos de uso devem fazer meno aos atores envolvidos nos casos de uso e os atores identificados nos dois artefatos devem ser consistentes. d) Quando um diagrama de casos de uso apontar uma associao entre casos de uso (incluso ou extenso), a descrio correspondente deve fazer meno explicitamente realizao do caso de uso associado. H2 Dicionrio de Projeto x Diagrama de Classes Os seguintes aspectos devem ser verificados nas relaes entre dicionrios de projeto e diagramas de classes: a) Para cada classe existente no diagrama de classes deve haver uma entrada no dicionrio de projeto, associada a uma descrio sucinta da mesma. b) Todos os atributos e operaes apresentados no diagrama de classes devem estar enumerados e sucintamente descritos na entrada do dicionrio de projeto referente correspondente classe. c) Restries de integridade no passveis de registro pela notao da UML devem ser explicitamente declaradas no modelo de classes. As classes, associaes e atributos envolvidos em uma restrio de integridade devem estar consistentes com o diagrama de classes e suas descries no dicionrio de projeto.
168
H3 Diagrama de Estados x Diagrama de Classes Os seguintes aspectos devem ser verificados nas relaes entre diagramas de estados e diagramas de classes: a) Um diagrama de estados deve estar relacionado a uma classe modelada no diagrama de classes. b) A classe correspondente no diagrama de classes deve conter atributos, associaes e/ou operaes capazes de indicar todos os estados pelos quais um objeto da mesma pode passar. H4 Diagrama de Sequncia x Diagrama de Classes Os seguintes aspectos devem ser verificados nas relaes entre diagramas de sequncia e diagramas de classes: a) Todos os objetos em um diagrama de sequncia devem ter a indicao de a qual classe pertencem. Essas classes devem estar modeladas no diagrama de classes. b) Para cada mensagem enviada a uma linha de vida de um objeto em um diagrama de sequncia, deve haver uma operao definida (com mesma assinatura) na correspondente classe. Operaes bsicas no precisam ser mostradas no diagrama de classes. c) Quando uma mensagem enviada a uma linha de vida corresponder a uma operao construtora (criao) na classe, a notao correspondente dever ser usada no diagrama de sequncia, dando incio linha de vida. d) Quando uma mensagem enviada a uma linha de vida corresponder a uma operao destruidora (excluso) na classe, a notao correspondente dever ser usada no diagrama de sequncia, encerrando a linha de vida. e) Quando retornos de mensagens forem especificados em um diagrama de sequncia, os mesmos devem corresponder aos respectivos retornos das operaes correspondentes no diagrama de classes. H5 Descries de Casos de Uso x Diagrama de Classes Os seguintes aspectos devem ser verificados nas relaes entre descries de casos de uso e diagramas de classes: a) As classes, associaes, atributos e operaes modelados no diagrama de classes devem ser necessrios e suficientes para realizar cada um dos fluxos de eventos apontados nas descries de casos de uso. b) Quando uma descrio de caso de uso fizer meno a dados de uma classe no diagrama de classes, ento a descrio do caso de uso deve ser consistente com os atributos modelados na correspondente classe do diagrama de classes (e viceversa). c) Para manter os modelos rastreveis, a descrio de caso de uso deve enumerar as classes envolvidas em sua realizao.
169
H6 Diagrama de Estados x Descries de Casos de Uso Os seguintes aspectos devem ser verificados nas relaes entre descries de casos de uso e diagramas de estados: a) Os eventos associados a transies entre estados em um diagrama de estados devem corresponder a fluxos de eventos ou a casos de uso em uma descrio de casos de uso. b) Quando pertinente, a descrio de caso de uso deve fazer uma meno explcita transio para o novo estado. H7 Diagrama de Sequncia x Descries e Diagrama de Casos de Uso Os seguintes aspectos devem ser verificados nas relaes entre diagramas e descries de casos de uso e diagramas de sequncia: a) Um diagrama de sequncia deve mostrar as interaes no contexto de um fluxo de eventos de um caso de uso, modelado em um diagrama de casos de uso e descrito em uma descrio de casos de uso. De maneira geral, cursos alternativos no devem ser mostrados ou, se necessrio model-los, isso no deve ser feito no mesmo diagrama de sequncia. b) A sequncia de interaes entre objetos em um diagrama de sequncia deve estar consistente com a sequncia de passos da descrio do caso de uso correspondente. c) Quando um ator estiver envolvido no fluxo de eventos do caso de uso sendo modelado por um diagrama de sequncia, ento esse ator deve ser consistente com o ator modelado no diagrama de casos de uso. H8 Diagrama de Atividade x Diagrama de Classes Os seguintes aspectos devem ser verificados nas relaes entre diagramas de atividades e diagramas de classes: a) Todos os objetos em um diagrama de atividades devem ter a indicao de a qual classe pertencem. Essas classes devem estar modeladas no diagrama de classes. b) Algumas atividades em um diagrama de atividades, tipicamente aquelas que apontam um processamento a ser feito pelo sistema, podem indicar a necessidade de uma operao na classe de um dos objetos que so entrada para essa atividade. H9 Diagrama de Atividades x Descries de Casos de Uso Os seguintes aspectos devem ser verificados nas relaes entre descries de casos de uso e diagramas de atividades: a) Um diagrama de atividades deve mostrar as atividades no contexto de um fluxo de eventos de um caso de uso, modelado em um diagrama de casos de uso e descrito em uma descrio de casos de uso. Cursos alternativos (de exceo ou variantes) devem ser mostrados no mesmo diagrama de atividades.
170
b) A sequncia de atividades em um diagrama de atividades deve estar consistente com a sequncia de passos da descrio do caso de uso correspondente. H10 Diagrama de Atividade x Diagrama de Estados Os seguintes aspectos devem ser verificados nas relaes entre diagramas de atividades e diagramas de estados: a) Quando um objeto em um diagrama de atividades indicar o estado do objeto e houver um diagrama de estados para a classe desse objeto, ento os estados devem estar consistentes, inclusive em relao ao evento que altera o estado do objeto.
8.2 Modelagem gil

Ao contrrio da modelagem conceitual estrutural em que o modelo de classes basicamente o modelo a ser construdo, na modelagem comportamental h diversos modelos e diagramas que podem ser empregados (modelos de casos de uso, diagramas de estados, diagramas de sequncia e diagramas de atividades). Cada um desses diagramas trabalha uma perspectiva diferente e, portanto, diferentes diagramas podem e devem ser elaborados para prover uma viso abrangente do comportamento de um sistema. Entretanto, fundamental considerar a relao custo-benefcio do uso desses modelos. Neste contexto, importante levar em considerao princpios da Modelagem gil. A Modelagem gil (AMBLER, 2004) uma coleo de valores, princpios e prticas de modelagem de software que pode ser aplicada a projetos de desenvolvimento de software de modo a torn-los mais leves e efetivos. Dentre os princpios de modelagem propostos por Ambler, destacamos os seguintes: O sistema de software seu objetivo principal; possibilitar o prximo trabalho seu objetivo secundrio: o principal objetivo de um projeto de desenvolvimento de software produzir um sistema de software de qualidade e no criar uma documentao. Contudo, durante o desenvolvimento, necessrio preparar o terreno para a prxima atividade, que no caso da modelagem de anlise pode ser a fase de projeto ou mesmo de manuteno. Para apoiar atividades subsequentes do processo de software, ser necessrio ter tambm uma documentao suficiente e de qualidade. Modele com um propsito: para que um certo diagrama seja elaborado, deve-se ter uma finalidade em mente. Um diagrama deve ser til para comunicar informaes para clientes e usurios, ajudando a se obter um entendimento comum dos requisitos, ou deve ajudar desenvolvedores a compreender melhor algum aspecto de software. Com base na meta estabelecida, deve-se escolher o tipo de diagrama mais apropriado para atingir a meta e o nvel de detalhe a ser utilizado. Use mltiplos modelos: h muitos modelos / diagramas e nveis de descrio (notao) que podem ser usados descrever sistemas de software. Contudo, normalmente apenas um pequeno subconjunto deles essencial para a maioria dos projetos. Assim, para que a elaborao de um certo diagrama se justifique, ele deve adicionar valor ao projeto. Ou seja, apenas aqueles diagramas que ofeream valor sua audincia alvo devem ser usados.
171
Diminua a carga de trabalho (Viaje leve): cada um dos modelos e diagramas elaborados, se conservado ao longo do desenvolvimento, precisa ser mantido medida que mudanas nos requisitos acontecem. Isso representa trabalho para a equipe e, portanto, toda vez que se decide conservar um modelo, est-se comprometendo a agilidade em prol da convenincia de se ter aquela informao disponvel para a equipe. A diretriz, portanto, conservar apenas aqueles modelos que fornecero valor em longo prazo e descartar o restante. Esse princpio tem vrias consequncias: o Deve-se selecionar apenas um pequeno conjunto de modelos e diagramas para serem elaborados, mantendo-se em linha com o princpio anterior; o Caso se opte por elaborar um certo diagrama para compreender melhor um certo aspecto do software, ele pode ser elaborado, mas no precisa ser necessariamente incorporado documentao. s vezes, um esboo em uma folha de papel cumpre o propsito e o diagrama pode ser descartado em seguida; o Praticamente todos os modelos e diagramas elaborados na fase de anlise podem ser refinados na fase de projeto, incorporando detalhes relativos soluo especfica a ser adotada. Modelos de classes, de casos de uso, diagramas de estados, de sequncia e de atividades, por exemplo, podem ter verses de anlise e projeto. Contudo, nem sempre vale pena refinar todos esses diagramas. Deve-se avaliar criteriosamente quais deles refinar na fase de projeto.
Adote a simplicidade: pressuponha que a soluo mais simples a melhor e mantenha os modelos to simples quanto puder. No modele seu sistema em excesso hoje, mostrando caractersticas adicionais no requeridas. Conhea os modelos e as ferramentas usadas para cri-los: Entenda o propsito de cada modelo / diagrama, seus pontos fortes e fracos e as principais notaes a serem empregadas em cada fase do processo de desenvolvimento. Conhea tambm as ferramentas usadas para cri-los e suas limitaes. Isso dar agilidade ao desenvolvimento de modelos.
Ao considerar esses princpios na modelagem segundo o paradigma orientado a objetos, chega-se ao seguinte conjunto de orientaes: Modelos de casos de uso e de classes so essenciais para o desenvolvimento e devem ser elaborados durante a anlise de requisitos. Descries de casos de uso completas s devem ser elaboradas para casos de uso mais complexos, tipicamente aqueles relacionados aos principais processos de negcio sendo apoiados pelo sistema em desenvolvimento. Diagramas de estados s devem ser elaborados para classes com comportamento dependente do estado. Recomenda-se elaborar diagramas de estados apenas para as classes que possurem trs ou mais estados relevantes. Se julgado til para a compreenso, pode ser elaborado um diagrama de estados para uma classe com apenas dois estados relevantes. Entretanto, deve-se avaliar se o mesmo no pode ser descartado aps cumprir seu propsito, no sendo incorporado documentao do projeto.
172
Diagramas de sequncia s devem ser elaborados para refinar o entendimento de casos de uso com certa complexidade, tipicamente aqueles relativos a processos de negcio apoiados pelo sistema. Deve-se escolher a abordagem mais indicada para o propsito em mente: representar o sistema como um objeto caixa-preta, como dois objetos (interface e controlador) ou mostrando objetos do domnio do problema. Esta ltima abordagem permite a identificao de operaes das classes do domnio, mas invariavelmente incorpora alguma deciso de projeto arquitetnico. Assim, uma opo postergar sua elaborao para a fase de projeto. Diagramas de atividades s devem ser elaborados quando forem teis para refinar o entendimento provido pela descrio de um caso de uso complexo, normalmente com vrias atividades paralelas, iterativas, condicionais ou alternativas. Diagramas de atividades tambm so uma boa opo para a modelagem de processos de negcio (ver seo 3.3). Em relao ao refinamento de modelos e diagramas na fase de projeto, de maneira geral, modelos de classe devem ser refinados, uma vez que eles so a base para a implementao. O mesmo no ocorre com os modelos comportamentais (modelos de casos de uso, diagramas de estados, sequncia e atividades), os quais, na maioria das vezes, basta manter a verso de anlise.
8.3 Reutilizao na Engenharia de Requisitos

A reutilizao no desenvolvimento de software tem como objetivos melhorar o cumprimento de prazos, diminuir custos e obter produtos de maior qualidade (GIMENES; HUZITA, 2005). Artefatos de software so reutilizados com o intuito de diminuir o tempo de desenvolvimento, investindo-se esforo na sua adaptao ao invs de se investir esforo na sua construo a partir do zero. Ao longo do processo de software, diversos tipos de artefatos podem ser reutilizados, dentre eles modelos, especificaes, planos, cdigo-fonte etc. Nesta seo, o foco na reutilizao como apoio Engenharia de Requisitos. Analisando o processo de Engenharia de Requisitos, possvel notar que a reutilizao pode ser til, sobretudo no reso de requisitos de sistemas similares e de modelos conceituais. Contudo, na prtica, na grande maioria das vezes, requisitos e modelos so construdos a partir do zero. Ou seja, requisitos de usurio so levantados junto aos interessados e posteriormente refinados em requisitos de sistema, quando modelos so construdos levandose em conta os requisitos inicialmente capturados. Entretanto, essa abordagem tem se mostrado insuficiente, pois desconsidera a reutilizao do conhecimento j existente na organizao acerca do domnio do problema (FALBO et al., 2007). Ao especificar requisitos para um sistema interessante ter em mente que muito provavelmente algum j desenvolveu algum sistema muito parecido ou at mesmo idntico ao que est sendo desenvolvido. Assim, caso se tenha acesso aos requisitos de um sistema similar ao que ser desenvolvido, certamente o esforo para se obter requisitos para o mesmo ser bem menor (ROBERTSON; ROBERTSON, 2006). O reso na Engenharia de Requisitos tem por objetivo a utilizao de requisitos (e outros artefatos relativos s fases da Engenharia de Requisitos) de projetos anteriores com o intuito de auxiliar a obteno dos requisitos para um novo sistema a ser desenvolvido. Requisitos podem ser reutilizados de diversas maneiras, dentre elas pelo reso de especificaes de projetos similares ao projeto atual, informalmente atravs da experincia
173
das pessoas ou pela reutilizao de artefatos desenvolvidos previamente com vistas ao reso. Por exemplo, ao se analisar um projeto similar, desenvolvido para um mesmo domnio de aplicao, pode-se concluir que diversos requisitos funcionais, no funcionais e at regras de negcio podem se aplicar ao novo projeto em desenvolvimento. Neste caso, os requisitos podem ser copiados, e adaptados, quando necessrio, de um projeto para o outro. Outra abordagem bastante utilizada pelas organizaes consiste em definir equipes que atuam sistematicamente em um certo domnio de aplicaes, de modo que seus membros possam reutilizar o conhecimento que tm sobre esse domnio no desenvolvimento de novos projetos. Ainda que essas abordagens mais informais e oportunistas tragam alguns benefcios, elas no exploram adequadamente as potencialidades de uma reutilizao sistemtica. Em uma abordagem sistemtica de desenvolvimento para e com reutilizao, primeiramente artefatos so concebidos explicitamente para serem reutilizados. Depois, os projetos de desenvolvimento reutilizam esses artefatos, fazendo as adaptaes necessrias. Uma vez que esses itens tenham sido desenvolvidos para reso, o esforo de adaptao e reutilizao tende a ser menor. Assim, para se obter os reais benefcios da reutilizao, importante que os artefatos j sejam desenvolvidos pensando no reso posterior. Neste contexto, merecem destaque trs abordagens, discutidas na sequncia: Engenharia de Domnio, Ontologias e Padres de Anlise.
8.3.1 Engenharia de Domnio

A Engenharia de Domnio representa um enfoque sistemtico para a produo de componentes reutilizveis que engloba atividades de anlise, projeto e implementao de domnio, as quais objetivam, respectivamente, representar requisitos comuns de uma famlia de aplicaes por meio de modelos de domnio, disponibilizar modelos arquiteturais para aplicaes a partir de um nico modelo de domnio e disponibilizar implementaes de componentes que representam funcionalidades bsicas de aplicaes relacionadas a um domnio (GIMENES; HUZITA, 2005). A Anlise de Domnio a atividade diretamente ligada reutilizao na Engenharia de Requisitos. A Anlise de Domnio visa capturar os elementos relevantes de um domnio de aplicaes e disponibiliz-los para serem utilizados no desenvolvimento de diferentes sistemas de apoio a negcios neste domnio. Assim, a Anlise de Domnio busca explicitar e modelar aspectos de domnio, produzindo artefatos (tipicamente modelos) que contm informaes sobre o domnio e que podem ser reutilizados no desenvolvimento de sistemas. Pode-se fazer um paralelo entre a Anlise de Domnio e a Anlise de Requisitos: ambas enfocam a modelagem conceitual de um domnio de aplicaes. Entretanto, enquanto a anlise de requisitos convencional enfoca a modelagem dos aspectos do domnio que so relevantes para um sistema especfico, a anlise de domnio mais abrangente e visa capturar elementos de informao do domnio potencialmente relevantes para o desenvolvimento de diversos sistemas neste domnio, estando, portanto, em nvel mais alto de abstrao. Em outras palavras, ao invs de explorar requisitos de uma aplicao especfica, na anlise de domnio, os requisitos explorados dizem respeito a uma famlia de aplicaes de uma determinada rea (ARANGO; PRIETO-DAZ, 1994). Neste sentido, pode-se considerar que a Anlise de Domnio direciona a Engenharia de Requisitos, pois seus modelos de domnio, mais abstratos, fornecem uma base para o trato com requisitos no contexto de um projeto especfico.
174
Para se fazer uma anlise de domnio, pode-se trabalhar de maneira anloga anlise de requisitos convencional, consultando-se especialistas do domnio e modelando o conhecimento capturado, de modo que esse conhecimento possa ser reutilizado nos vrios projetos que faam parte desse domnio (ROBERTSON; ROBERTSON, 2006). H, ainda, diversos mtodos de anlise de domnio, os quais procuram explorar as especificidades dessa atividade, dentre eles FODA, ODM, EDLC, FORM, RSEB e Catalysis (GIMENES; HUZITA, 2005). Contudo, qualquer que seja a abordagem de anlise de domnio empregada, deve-se ter em mente que um modelo de domnio deve conter os elementos comuns s vrias aplicaes do domnio e no detalhes especficos de uma ou de todas as aplicaes. Assim, para ser realmente reutilizvel, um modelo de domnio deve ser mais geral e abstrato, contendo o conhecimento de senso comum a respeito do domnio, sem incluir detalhes que podem ser relevantes apenas para uma ou para poucas aplicaes. Deve-se apontar, ainda, que a anlise de domnio apenas ser uma abordagem interessante, caso haja uma real necessidade de reso no domnio em questo. A anlise de domnio uma atividade complexa que consome tempo e recursos, podendo ser anterior ou paralela a um processo de desenvolvimento de software. Assim, se no houver uma real possibilidade de reso nesse domnio, a anlise de domnio torna-se invivel. A Figura 8.2 ilustra o processo de Engenharia de Domnio e como ele pode apoiar o processo de desenvolvimento de um sistema de software.
Figura 8.2 Abordagens para e com Reso na Engenharia de Domnio. Nuseibeh e Easterbrook (2000), em seu mapa para o futuro da Engenharia de Requisitos, colocaram o reso de modelos como um dos maiores desafios da Engenharia de Requisitos para os anos 2000. Eles acreditavam que, para muitos domnios de aplicao, modelos de referncia para especificao de requisitos seriam desenvolvidos, de modo que o esforo de desenvolver modelos de requisitos a partir do zero fosse reduzido. De alguma forma, isso, de fato, vem ocorrendo, ainda que no propriamente na forma de modelos de
175
referncia, mas por meio da construo de diversas ontologias de domnio e pelo crescente nmero de padres de anlise disponveis (FALBO et al., 2007), assuntos discutidos a seguir.
8.3.2 Ontologias de Domnio

Uma grande dificuldade atual no desenvolvimento de sistemas para apoiar processos de negcio em um mesmo domnio, sobretudo quando os mesmos precisam trabalhar de maneira integrada, a existncia de diversas vises parciais sobre esse domnio. Cada viso parcial carrega consigo um vocabulrio e determinados valores prprios, dificultando a integrao entre os diversos profissionais pela ausncia de padronizao. Esse problema pode ser minimizado se a conceituao envolvida no domnio for, pelo menos parcialmente, explicitada, o que pode ser feito por meio de uma ontologia de domnio. Uma ontologia de domnio um artefato de engenharia que busca explicitar a conceituao de um domnio particular. Uma conceituao, por sua vez, corresponde ao conjunto de conceitos usados para interligar abstraes de entidades de um dado domnio. Assim, uma ontologia de domnio tem como objetivo explicitar e formalmente definir os conceitos, relaes, propriedades e restries em um domnio particular (GUIZZARDI, 2005). Ontologias de domnio tm diversos usos, dentre eles (JASPER; USCHOLD, 1999): (i) apoio comunicao entre pessoas envolvidas no domnio; (ii) integrao de dados e interoperabilidade de sistemas desenvolvidos para o domnio e (iii) especificao reutilizvel para a construo de sistemas no domnio. Ontologias de domnio podem ser usadas como modelos de domnio em uma abordagem de Engenharia de Domnio. Assim, como discutido na seo anterior, pode-se pensar que o processo de Engenharia de Domnio, neste caso, envolveria atividades de Modelagem da Ontologia, Projeto da Ontologia e Implementao da Ontologia. Do ponto de vista da Engenharia de Requisitos, est-se mais interessado em ontologias como modelos conceituais. Assim, o foco est nas ditas ontologias de referncia, as quais representam um modelo de consenso dentro de uma comunidade. Uma ontologia de referncia uma especificao independente de soluo, com o objetivo de fazer uma descrio clara e precisa de entidades do domnio, para propsitos de comunicao, aprendizado e resoluo de problemas (ZAMBORLINI; GONALVEZ; GUIZZARDI, 2008). Vale a pena destacar similaridades e diferenas entre modelos de domnio em uma abordagem tradicional de Engenharia de Domnio e em uma abordagem baseada em ontologias. Ambos tm como propsito capturar a conceituao de um certo domnio, estando em um nvel de abstrao mais elevado do que um modelo conceitual de um sistema. Entretanto, ontologias so desenvolvidas com vrios propsitos em mente (e no somente de servir como uma especificao base para o desenvolvimento de sistemas), o que faz com que tenha de ser especificada com mais rigor, normalmente exigindo o consenso em uma comunidade, tornando-a mais geral do que modelos de domnio. Uma vez que uma ontologia um artefato complexo de engenharia, ela deve ser construda usando mtodos apropriados. H diversos mtodos existentes para o desenvolvimento de ontologias, dentre eles SABiO (FALBO, 2004), Neon (SUREZFIGUEROA et al., 2007) e Methontology (GOMEZ-PEREZ; CORCHO; FERNANDEZLOPEZ, 2007).
176
8.3.3 Padres de Anlise

Padres de software formalizam solues para problemas recorrentes no desenvolvimento de software, com base na experincia de especialistas, permitindo que essas solues possam ser reutilizadas em vrias outras situaes, por outros especialistas. Na engenharia de software, padres so usados para descrever solues de sucesso para problemas de software comuns. Esses padres refletem a estrutura conceitual dessas solues e podem ser aplicados vrias vezes na anlise, projeto e produo de aplicaes, em um contexto particular (DEVEDZIC, 1999). O uso pelos engenheiros de software de solues j conhecidas e testadas ajuda a aumentar o nvel de abstrao, a produtividade e a qualidade dos projetos nas vrias fases do desenvolvimento de sistemas (COTA, 2004). No contexto de desenvolvimento de software, padres procuram representar a experincia de muitos esforos de reengenharia de desenvolvedores que tentaram adquirir maior reusabilidade e flexibilidade em seus produtos de software. Representam tambm, a formalizao de uma soluo para determinada situao que desenvolvedores sempre se depararam na sua experincia em desenvolver sistemas. Diante de uma situao recorrente, observa-se que pode ser aplicada uma soluo que j foi adotada em vrios contextos e, com isso, estabelece-se um padro. Os desenvolvedores no inventam padres de software, descobrem-nos da experincia em construir sistemas na prtica (DEVEDZIC, 1999). Em outras palavras, os padres so descobertos e no inventados. Por exemplo, modelos se tornam padres somente quando se descobre que eles podem ter uma utilidade comum. Ou seja, padres so coisas que os desenvolvedores conhecem e reconhecem que podem ser teis em diferentes contextos. Ou seja, a partir da anlise de diversos eventos de negcio do mesmo tipo, um padro de anlise pode ser derivado por meio da abstrao de elementos comuns (ROBERTSON; ROBERTSON, 2006). Com um padro, apresentada uma aproximao genrica para resolver um problema. Assim, padres tm que ser trabalhados e adaptados para casos especficos. Padres existem em vrias fases do desenvolvimento de software. A comunidade de padres de software primeiro descobriu, descreveu e classificou um certo nmero de padres de projeto (GAMMA et al.,1995). Mais recentemente foram identificados outros padres relacionados a outras fases e aspectos do desenvolvimento de software, como os padres de anlise (FOWLER, 1997) e padres para arquiteturas de software (FOWLER, 2003). Para a Engenharia de Requisitos, os padres de interesse so os padres de anlise. Padres de anlise so definidos a partir de modelos conceituais de aplicaes. Ao se criar um modelo conceitual, os analistas percebem que muitos aspectos de projetos anteriores se repetem. Se ideias usadas em projetos anteriores so teis atualmente, ento, eles melhoram essas ideias e as adaptam para atender a uma nova demanda. Para reutilizar um padro de anlise em outra aplicao, preciso reinterpretar cada classe no padro como uma classe correspondente no novo sistema. A estratgia a abstrao do modelo inicial, de onde novos modelos podem ser desenvolvidos. Fowler (1997) se refere a padres de anlise como grupos de conceitos que representam uma construo comum na modelagem de negcios. Eles podem ser relevantes para somente um domnio ou podem ser expandidos para vrios domnios. Os padres de anlise lidam com problemas gerais de modelagem, sendo apresentados atravs de um problema particular em um domnio, onde mais fcil de entend-los. Conhecendo-os, so identificadas inmeras situaes onde aplic-los. No citado livro, so descritos padres para
177
vrios domnios de negcios, de acordo com a experincia pessoal do autor em aplicar modelagem de objetos a sistemas de informao de grandes corporaes. Padres de maneira geral so registrados em catlogos. Um catlogo de padres uma coleo de padres com uma estrutura e uma organizao. Os padres so subdivididos em categorias e h relaes entre eles. A classificao em um catlogo facilita o aprendizado e direciona os esforos para encontrar novos padres, torna-os teis para os leitores, que podem lembrar dos padres, identific-los em diferentes situaes e reutiliz-los no desenvolvimento de algum sistema. Para tal, a cada padro de software dado um nome, que serve como um guia para facilitar a discusso do padro e a informao que ele representa. Um dos catlogos de padres de anlise mais conhecidos o descrito por Fowler em seu livro Analysis Patterns: Reusable Objects Models (Padres de Anlise: Modelos de Objetos Reutilizveis) (FOWLER, 1997), onde h mais de 40 padres de anlise, contendo modelos j aplicados em projetos nos quais o autor trabalhou. Os padres neste catlogo so organizados em dez categorias principais, a saber: Responsabilidades, Observaes e Medies, Observaes para Finanas Coorporativas, Referncia a Objetos, Inventrio e Contabilidade, Uso de Modelos de Contabilidade, Planejamento, Negociao, Contratos Derivados e Pacotes de Negociao. Os padres de anlise relativos a responsabilidades, por exemplo, buscam capturar situaes em que uma pessoa ou organizao responsvel por outra. uma noo abstrata que pode empregada em vrias situaes, incluindo estrutura organizacional, contratos e relaes de emprego. Dentre os padres dessa categoria podem ser citados: Parte (Party), Hierarquia Organizacional (Organization Hierarquies) e Estrutura Organizacional (Organization Structure). Os padres de anlise de negociao, por sua vez, tratam o comrcio de mercadorias sob uma perspectiva de vendedor / comprador. Esses padres tratam compra e venda de mercadorias e o valor dessas mercadorias com respeito s mudanas nas condies de mercado. Nesta categoria h, dentre outros, os seguintes padres: Contrato (Contract) e Carteira de Negcios (Portfolio). As figuras 8.3, 8.4 e 8.5 mostram alguns exemplos de modelos estruturais propostos em padres de anlise, adaptados de (FOWLER, 1997). Na Figura 8.3, apresentado o padro Pessoa, cujo propsito tratar situaes em que pessoas fsicas e jurdicas tm responsabilidades similares. Neste caso, a soluo adotada criar um tipo Pessoa, como um supertipo de Pessoa Fsica e Pessoa Jurdica, reunindo propriedades comuns s duas.
Figura 8.3 Padro de Anlise Pessoa.
178
As figuras 8.4 e 8.5 mostram diferentes verses de um mesmo padro: o padro Plano. O problema envolvido neste caso o planejamento de aes. Na verso da Figura 8.4, considera-se que uma ao definida exclusivamente para um plano. Na verso da Figura 8.5, considera-se que uma ao proposta pode fazer parte de diversos planos.
Figura 8.4 Padro de Anlise Plano Verso 1.
Figura 8.5 Padro de Anlise Plano Verso 2. Utilizar ontologias e padres de anlise para a modelagem conceitual de sistemas abre espao para uma viso mais abrangente do domnio tratado, levando a um melhor entendimento do mesmo. Isso pode diminuir o tempo gasto na especificao de requisitos, pois os analistas j tm uma fonte preliminar para aprender sobre o domnio, que estabelece uma terminologia comum aos especialistas do negcio (COTA, 2004). Padres de Anlise, assim como ontologias, descrevem aspectos no nvel de conhecimento. Assim, uma vez que eles proveem conhecimento sobre solues bem sucedidas a problemas recorrentes no desenvolvimento de software, eles favorecem a reutilizao. No entanto, ontologias capturam a estrutura conceitual intrnseca de um domnio, enquanto padres de anlise focalizam a estrutura de uma aplicao (DEVEDZIC, 1999). Em (FALBO et al., 2007) proposto um processo de Engenharia de Requisitos baseado em reutilizao de ontologias e padres de anlise, voltado para o desenvolvimento
179
de sistemas de informao. O processo proposto visa contribuir para a institucionalizao de prticas de reso na Engenharia de Requisitos. O processo comea com um levantamento preliminar de requisitos, cujo objetivo definir o escopo do projeto e enumerar os principais requisitos funcionais e no-funcionais. Paralelamente, um modelo conceitual elaborado, tomando por base ontologias e padres de anlise relacionados ao domnio do problema. Os requisitos so ento detalhados e os modelos detalhados. Como produto, um documento de especificao de requisitos produzido. Leitura Complementar Em (AMBLER, 2004) so apresentados em detalhes os princpios e valores da modelagem gil. Em especial, os captulos 3 e 4 apresentam os princpios dessa abordagem. Em (GIMENES; HUZITA, 2005), o Captulo 3 aborda aspectos relacionados Engenharia de Domnio. Finalmente, em (FOWLER, 2007), so apresentados diversos padres de anlise. Em especial, os captulos de 2 a 11 apresentam diversos padres de anlise agrupados em categorias. Referncias do Captulo AMBLER, S.W., Modelagem gil: Prticas Eficazes para a Programao eXtrema e o Processo Unificado, Porto Alegre: Bookman, 2004. ARANGO, G., PRIETO-DAZ, R., Domain Analysis Concepts and Research Directions, Workshop on Software Architecture, USC Center for Software Engineering, Los Angeles, EUA, 1994. BLAHA, M., RUMBAUGH, J., Modelagem e Projetos Baseados em Objetos com UML 2, Elsevier, 2006. COTA, R.I.; Um Estudo sobre o Uso de Ontologias e Padres de Anlise na Modelagem de Sistemas de Gesto Empresarial. Dissertao de Mestrado, Mestrado em Informtica, UFES, 2004. DEVEDZIC, V.; Ontologies: Borrowing from Software Patterns, Intelligence, vol. 10, issue 3 (Fall 1999), 1999, p. 14-24. FALBO, R. A.; Experiences in Using a Method for Building Domain Ontologies Proceedings of the 16th International Conference on Software Engineering and Knowledge Engineering, International Workshop on Ontology In Action, Banff, Canada, 2004. FALBO, R.A., MARTINS, A.F., SEGRINI, B.M., BAICO, G., DAL MORO, R., NARDI, J.C.; Um Processo de Engenharia de Requisitos Baseado em Reutilizao e Padres de Anlise, VI Jornadas Iberoamericanas de Ingeniera del Software e Ingeniera del Conocimiento (JIISIC07), Lima, Peru, 2007. FOWLER, M.; Analysis Patterns: Reusable Object Models. Addison-Wesley Professional Computing Series, 1997. FOWLER, M., Patterns of Enterprise Application Architecture, Addison-Wesley, 2003.
180
GAMMA, E., HELM, R., JOHNSON, R., VLISSIDES, J.M., Design Patterns - Elements of Reusable Object-Oriented Software. Addison-Wesley, 1995. GIMENES, I.M.S., HUZITA, E.H.M.; Desenvolvimento Baseado em Componentes: Conceitos e Tcnicas. Editora Cincia Moderna, 2005. GMEZ-PREZ, A., CORCHO, O., FERNANDEZ-LOPEZ, M.; Ontological Engineering: with examples from the areas of Knowledge Management, e-Commerce and the Semantic Web, 2nd edition, Springer, 2007. GUIZZARDI, G., Ontological Foundations for Structural Conceptual Models, Telematics Instituut Fundamental Research Series, The Netherlands, 2005. JASPER, R., USCHOLD, M.; A Framework for Understanding and Classifying Ontology Applications, Proceedings of the IJCAI99 Workshop on Ontologies and Problem-Solving Methods, Stockholm, Sweden, 1999. NUSEIBEH, B., EASTERBROOK, S., Requirements Engineering: A Roadmap, In: Procedings of the Future of Software Engineering, ICSE2000, Ireland, 2000, p. 37-46. ROBERTSON, S., ROBERTSON, J. Mastering the Requirements Process. 2nd Edition. Addison Wesley, 2006. SUREZ-FIGUEROA, M.A., et al., NeOn Development Process and Ontology Life Cycle, 2007. Disponvel em http://www.neon-project.org/webcontent/index.php?option=com_weblinks&view=category&id=17&Itemid=73. ZAMBORLINI, V., GONALVEZ, b., GUIZZARDI, G.; Codification and Application of a Well-Founded Heart-ECG Ontology, Proceedings of the 3rd Workshop on Ontologies and Metamodels in Software and Data Engineering, Campinas, Brazil, 2008.
Anexo A A Norma ISO/IEC 9126
181
A ISO/IEC 9126 uma famlia de normas que trata da avaliao da qualidade de produtos de software. Ela estabelece um modelo de qualidade para produtos de software e apresenta diversas medidas para aferir qualitativa e quantitativamente a presena dos atributos de qualidade descritos em seu modelo. A ISO/IEC 9126 dita uma famlia ou srie de normas, pois dividida em partes, a saber: Parte 1 Modelo da qualidade Parte 2 Mtricas externas Parte 3 Mtricas internas Parte 4 Mtricas de Qualidade em uso
A ISO/IEC 9126 encontra-se em fase de transio para uma nova famlia de normas, a ISO/IEC 25000 - Software Product Quality Requirement and Evaluation (SQuaRE). Entretanto, o modelo de qualidade de produto de software proposto nessa norma continua vlido. Esse modelo, descrito na ISO/IEC 9126-1 (ISO/IEC, 2001), dividido em duas partes: (i) qualidade interna e externa; (ii) qualidade em uso. O modelo de qualidade interna e externa especifica seis caractersticas, as quais so por sua vez subdivididas em subcaractersticas. Essas subcaractersticas so manifestadas externamente quando o software utilizado e so resultado de atributos internos. Qualidade externa a qualidade do produto percebida quando o software executado, ou seja, uma percepo da qualidade do ponto de vista do usurio. A qualidade interna, por sua vez, referese percepo da qualidade do ponto de vista de desenvolvedores. A Figura B.1 mostra o modelo de qualidade interna e externa da ISO/IEC 9126-1, suas seis caractersticas de qualidade, desdobradas em subcaractersticas.
Qualidade externa e interna
182
Funcionalidade
Confiabilidade
Usabilidade
Eficincia
Manutenibilidade
Portabilidade Adaptabilidade Capacidade para ser instalado Co-existncia Capacidade para substituir Conformidade
Adequao Acurcia Interoperabilidade Segurana de acesso Conformidade
Maturidade Tolerncia a Falhas Recuperabilidade Conformidade
Inteligibilidade Apreensibilidade Operacionalidade Atratividade Conformidade
Comportamento em relao ao tempo Comportamento em relao aos recursos
Conformidade
Analisabilidade Modificabilidade Estabilidade Testabilidade Conformidade
Figura B.1 Modelo de Qualidade da ISO/IEC 9126-1 para Qualidade Externa e Interna (adaptado de ISO/IEC, 2001). importante notar que em todas as caractersticas temos uma subcaracterstica denominada conformidade. A conformidade se refere capacidade do produto de software de estar de acordo com normas, convenes ou regulamentaes em leis e prescries similares relacionadas caracterstica de qualidade em questo. Ela utilizada para avaliar o quanto o software obedece aos requisitos de legislao e todo o tipo de padronizao ou normalizao aplicvel ao contexto. O modelo de qualidade em uso especifica quatro caractersticas, mas no apresenta o modelo de qualidade abaixo do nvel de caracterstica. Qualidade em uso mede o quanto um usurio pode alcanar de seus objetivos num ambiente particular. Seu foco no uso do software e no nas propriedades do software em si. Uma vez que o enfoque da qualidade em uso no recai sobre as propriedades do software em si, as caractersticas de qualidade em uso so mais importantes para a avaliao de produtos de software do que para a definio de requisitos. Para apoiar a definio de requisitos, a parte do modelo relativa qualidade interna e externa mais relevante. A seguir, so descritas as caractersticas de qualidade enumeradas na ISO/IEC 9126-1. Caractersticas de Qualidade Externa e Interna As seis caractersticas de qualidade externa e interna descritas na ISO/IEC 9126-1 (ISO/IEC, 2001) so: Funcionalidade: refere-se existncia de um conjunto de funes que satisfaz s necessidades explcitas e implcitas e suas propriedades especficas. Tem como subcaractersticas: o Adequao: capacidade do produto de software de prover um conjunto apropriado de funes para tarefas e objetivos do usurio especificados; o Acurcia: capacidade do produto de software de prover resultados ou efeitos corretos ou acordados com o grau de preciso necessrio; o Interoperabilidade: capacidade do produto de software de interagir com um ou mais sistemas especificados;
183
o Segurana de Acesso: capacidade do produto de software de proteger informaes e dados de forma que pessoas ou sistemas no autorizados no possam l-los nem modific-los e pessoas ou sistemas autorizados no faam acessos danosos a eles; Confiabilidade: diz respeito capacidade do software manter seu nvel de desempenho, sob condies estabelecidas, por um perodo de tempo. Tem como subcaractersticas: o Maturidade: capacidade do produto de software de evitar falhas decorrentes de defeitos no software; o Tolerncia a Falhas: capacidade do produto de software de manter um nvel de desempenho especificado em casos de defeitos no software ou de violao de sua interface especificada; o Recuperabilidade: capacidade do produto de software de reestabelecer seu nvel de desempenho e recuperar os dados diretamente afetados no caso de uma falha; Usabilidade: refere-se capacidade do produto de software ser compreendido, aprendido, usado pelo usurio e atrativo ao usurio, quando usado sob condies especificadas. Tem como subcaractersticas: o Inteligibilidade: capacidade do produto de software de permitir ao usurio compreender se o software se aplica a suas necessidades e como ele pode ser usado para determinadas tarefas e condies de uso; o Apreensibilidade: capacidade do produto de software de permitir ao usurio aprender sua aplicao; o Operacionalidade: capacidade do produto de software de permitir o usurio oper-lo e control-lo; o Atratividade: capacidade do produto de software de ser atrativo ao usurio; Eficincia: diz respeito capacidade do produto de software de fornecer desempenho apropriado, relativo quantidade de recursos usados, sob condies especificadas. Tem como subcaractersticas: o Comportamento em relao ao tempo: capacidade do produto de software de fornecer tempo de resposta e tempo de processamento apropriados e taxas de throughput quando executando suas funes, sob condies estabelecidas; o Comportamento em relao aos recursos: capacidade do produto de software de usar quantidade e tipos de recursos apropriados quando o software executa suas funes sob condies estabelecidas; Manutenibilidade: concerne ao esforo necessrio para se fazer modificaes no software. Tem como subcaractersticas: o Analisabilidade: capacidade do produto de software de permitir o diagnstico de deficincias ou causas de falhas no software, ou a identificao de partes a serem modificadas;
184
o Modificabilidade: capacidade do produto de software de permitir que a modificao especificada seja implementada; o Estabilidade: capacidade do produto de software de minimizar efeitos inesperados de modificaes de software; o Testabilidade: capacidade do produto de software permitir que o software modificado ser testado; Portabilidade: refere-se capacidade do software ser transferido de um ambiente para outro. Tem como subcaractersticas: o Adaptabilidade: capacidade do produto de software de ser adaptado para diferentes ambientes especificados sem necessidade de aplicao de outras aes ou meios alm daqueles fornecidos para essa finalidade pelo software considerado; o Capacidade para ser Instalado: capacidade do produto de software para ser instalado em um ambiente especificado; o Coexistncia: capacidade do produto de software para coexistir com outros softwares independentes em um ambiente comum compartilhando recursos comuns; o Capacidade para Substituir: capacidade do produto de software para ser usado em substituio de outro produto de software especificado para o mesmo propsito no mesmo ambiente. Caractersticas de Qualidade em Uso As quatro caractersticas de qualidade em uso descritas na ISO/IEC 9126-1 (ISO/IEC, 2001) so: Eficcia: capacidade do produto de software de permitir aos usurios atingir metas especificadas com acurcia e completude em um contexto de uso especificado; Produtividade: capacidade do produto de software de permitir ao usurio usar a quantidade de recursos apropriados em relao eficcia atingida quando o produto de software utilizado em um contexto de uso especificado; Segurana: capacidade do produto de software de atingir nveis aceitveis de riscos de danos para pessoas, negcios, software, propriedades ou ambiente em um contexto de uso especificado; Satisfao: capacidade do produto de software satisfazer os usurios em um contexto de uso especificado.

Notas Aula Engenharia Requisitos

Transféré par

Informations du document

Description originale:

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Notas Aula Engenharia Requisitos

Transféré par

Droits d'auteur :

Formats disponibles

UFES - Universidade Federal do Esprito Santo

Ricardo de Almeida Falbo

165 166 170 172 181

1.1 Desenvolvimento de Software e Engenharia de Requisitos

1.2 - A Organizao deste Texto

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

2.2 O Processo de Engenharia de Requisitos

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

2.2.1 Levantamento de Requisitos

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

Problemas de volatilidade: Os requisitos mudam ao longo do tempo.

Captulo 2 Engenharia de Requisitos de Software

2.2.2 Anlise de Requisitos

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

2.2.3 Documentao de Requisitos

Captulo 2 Engenharia de Requisitos de Software

2.2.4 Verificao e Validao de Requisitos

Captulo 2 Engenharia de Requisitos de Software

Neste contexto til (WIEGERS, 2003):

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

2.2.5 Gerncia de Requisitos

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

Rastreabilidade regressiva a partir dos requisitos

Rastreabilidade progressiva a partir dos requisitos

Outros Artefatos: -Projeto (Design) - Cdigo - Testes etc.

Rastreabilidade progressiva em direo aos requisitos

Rastreabilidade regressiva em direo aos requisitos

Figura 2.4 Tipos de Rastreabilidade

Captulo 2 Engenharia de Requisitos de Software

2.3 Engenharia de Requisitos e Normas e Modelos de Qualidade

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

Captulo 2 Engenharia de Requisitos de Software

Captulo 3 Levantamento de Requisitos

Captulo 3 Levantamento de Requisitos

3.1 Viso Geral do Levantamento de Requisitos

Captulo 3 Levantamento de Requisitos

Captulo 3 Levantamento de Requisitos

Captulo 3 Levantamento de Requisitos

Captulo 3 Levantamento de Requisitos

3.2 Tcnicas de Levantamento de Requisitos

A seguir algumas das tcnicas citadas anteriormente so apresentadas.

Captulo 3 Levantamento de Requisitos

Captulo 3 Levantamento de Requisitos

Captulo 3 Levantamento de Requisitos

Captulo 3 Levantamento de Requisitos

Captulo 3 Levantamento de Requisitos

Captulo 3 Levantamento de Requisitos

3.2.2 Workshops de Requisitos

Captulo 3 Levantamento de Requisitos

Captulo 3 Levantamento de Requisitos