apostila-aps-ii 1

7/23/2019 Apostila-APS-II 1

1/109

Anlise e Projeto de Sistemas IISexto semestre

2010/01

Ciclo de vida do desenvolvimento de Software

Prof: MsC. Maricy [email protected]

Araputanga 2010/02


2/109

2

1 IntroduoPraticamente todos os pases, hoje em dia, dependem de sistemas baseados em computadores. Infra-estruturas

e servios nacionais contam com sistemas baseados em computadores, e a maioria dos produtos eltricos incluium computador e um software de controle. A a maioria dos setores esto automatizados. Portanto, produzir emanter o software dentro de custos adequados essencial para o funcionamento da economia nacional einternacional.Durante as dcadas de 60 e 70, o desafio primordial era desenvolver hardware que reduzisse o custo deprocessamento e armazenamento de dados. Durante a dcada de 80, avanos na microeletrnica resultaramem um aumento do poder computacional e a um custo reduzido. Entretanto, tanto o processo dedesenvolvimento como o software produzido ainda deixavam muito a desejar: cronogramas no eramcumpridos, custos excediam o previsto, o software no cumpria os requisitos estipulados e assim por diante.Portanto o desafio primordial nas ltimas dcadas foi e continua sendo melhorar a qualidade e reduzir o custodo software produzido, atravs da introduo de disciplina no desenvolvimento, o que conhecido comoengenharia de software.Nessa parte da apostila veremos o ciclo de vida do desenvolvimento de software. O ciclo de vida de umsoftware descreve as fases pelas quais o software passa desde a sua concepo at sua implantao, de umamaneira geral temos 4 fases que so: Anlise, Projeto, Implementao e Implantao , outras fases podemaparecer entre elas.Na prtica para trabalharmos com os chamados modelos de ciclo de vida , processo , ou ainda metodologia , quetrazem com sua estrutura padronizada as prprias fases de desenvolvimento.Nessa apostila como modelo utilizaremos o RUP, para a modelagem a linguagem UML e o paradigma ser oOrientado a Objetos com exemplos na linguagem de programao Java.Um estudo de caso que seguir por todas as fases do desenvolvimeno que ser uma Locadora de DVD naInternet.

2 Processo de SoftwareA utilizao de um processo de software tm sido apontada como um fator primordial para o sucesso deempresas de desenvolvimento de software.Para poder melhor compreender o assunto necessrio definir o que um processo de software.Um processo de software pode ser entendido como um conjunto estruturado de atividades exigidas paradesenvolver um sistema de software. Assim Sommerville trs a seguinte definio:"O processo um conjunto de atividades e resultados associados que produzem um produto de software".Jalote conclui que um processo de software:" um conjunto de atividades, ligadas por padres de relacionamento entre elas, pelas quais se as atividadesoperarem corretamente e de acordo com os padres requeridos, o resultado desejado produzido. O resultadodesejado um software de alta qualidade e baixo custo. Obviamente, um processo que no aumenta aproduo (no suporta projetos de software grandes) ou no pode produzir software com boa qualidade no um processo adequado."Temos a nossa disposio vrios processos de desenvolvimento de software como gil, Cleanroom, Iterativo,RAD, RUP, Espiral, Cascata, XP, Scrum dentre vrios outros.Adotaremos para os exemplos nessa apostila o modelo RUP.

2.1 RUPO RUP, abreviao de Rational Unified Process (ou Processo Unificado da Rational).O RUP usa a abordagem da orientao a objetos em sua concepo e projetado e documentado utilizando anotao UML (Unified Modeling Language) para ilustrar os processos em ao. Utiliza tcnicas e prticasaprovadas comercialmente. um processo considerado pesado e preferencialmente aplicvel a grandes equipes de desenvolvimento e agrandes projetos, porm o fato de ser amplamente customizvel torna possvel que seja adaptado para projetosde qualquer escala, um dos motivos pelos quais adotaremos o RUP nessa disciplina por causa de suaflexibilidade.

Caractersticas


3/109

3

Figura 1 Diviso das quatro fases e cinco workflows do RUP

Fonte : Desenvolvendo Software com UML 2.0 - Ernani Sales de Medeiros

2.2 Fases do RUPO processo unificado prev quatro grandes fases: Concepo, Elaborao, Construo e Transio, como mostraa figura 1. As iteraes ocorrem dentro de cada uma dessas fases. Uma fase pode, portanto, ter uma ou vriasiteraes. No existe um nmero predeterminado de iteraes dentro de uma fase.

2.2.1 ConcepoNa fase de concepo pensamos na viso do software, em que o documento de mesmo nome contrudo(conforme veremos no decorrer desse captulo), identificamos os principais requisitos e Casos de Uso. Comessas informaes podemos, agora, informar prazo e preo com mais certeza.Essa fase tambm responsvel pelos documentos de Nomenclatura e Glossrio, abordados nesse captulo eque avanam por todas as fases do processo.

2.2.2 Elaborao nessa fase que os requisitos que ainda no foram identificados so levantados. Ela consolida a fase deconcepo, agregando valor a cada iterao que sofre. A fase de elaborao se repete ao longo dodesenvolvimento, ou seja, o ciclo de vida do software.

2.2.3 ConstruoQuando pensamos em prottipos e nos relacionamos com campos em banco de dados, quando funes oustored procedures conversam com os componentes em Servlets ou EJB, estamos enfrentando a fase deconstruo do RUP.Em funo dos testes, nessa fase que nos livramos dos erros do software.

2.2.4 TransioQuando parte do software sai da verso beta e pode ser avaliado como verso de produo, significa queestamos na fase de transio, em que os erros encontrados devem ser mnimos. Nessa fase ocorre o

treinamento com os usurios finais e a confeco de manuais do sistema.


4/109

4

2.3 Workflows que compe o RUP2.3.1 RequisitosAqui necessrio obter todos os requisitos necessrios para a formao de casos de uso bem escritos, se umsoftware necessitar se amparar em uma documentao, no presente ou futuro, para ser construdo, essadocumentao ser os Casos de Uso.

Esse workflow est contido tipicamente nas fases de Concepo, Elaborao e Construo.2.3.2 AnliseQuando identificamos quem realiza um Caso de Uso ou um de seus cenrios principais, em termos de classes deforma conceitual, estamos dentro do workflow de Anlise.Esse workflow est contido tipicamente nas fases de Concepo, Elaborao e Construo.

2.3.3 ProjetoQuando samos de uma viso conceitual da construo de classes e diagrama de sequncia, na abstraorequerida, estamos dentro do workflow de projeto. Esse workflow est contido tipicamente nas fases deConcepo, Elaborao e Construo.Muitas vezes, os dois workflows (anlise e projeto) so mesclados em um nico, pois difcil separar de formadocumentada e distinta esss duas fases.

2.3.4 ImplementaoEsse workflow encontrado quando estamos codificando e compilando algum cdigo. A prpria construo deuma pgina HTML e sua colocao em funcionamento sinal de que estamos executando esse workflow dentrode alguma fase.A transformao do diagrama de classes em componentes, bem como o atendimento do diagrama desequncia, mostra que estamos nesse workflow. Ele est contido tipicamente nas fases de Elaborao eConstruo.

2.3.5 TestesA criao de um modelo de testes, ou seja, a descrio de por quais testes uma implementao deve passar,relata esse workflow. A compilao dos resultados desses testes (que devem ser anotados e identificados porsua data e condio de teste) servir em anlises posteriores. Ele est contido tipicamente nas fases deElaborao e Construo.

3 UML A Unified Modeling Language (UML) uma linguagem de modelagem no proprietria de terceira gerao. AUML no uma metodologia de desenvolvimento, o que significa que ela no diz para voc o que fazer primeiroe em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicao entreobjetos.Basicamente, a UML permite que desenvolvedores visualizem os produtos de seu trabalho em diagramaspadronizados. Junto com uma notao grfica, a UML tambm especifica significados, isto , semntica. umanotao independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamentedesenvolvido utilizando a UML.A UML tem origem na compilao das "melhores prticas de engenharia" que provaram ter sucesso namodelagem de sistemas grandes e complexos. Sucedeu aos conceitos de Booch, OMT (Rumbaugh) e OOSE(Jacobson) fundindo-os numa nica linguagem de modelagem comum e largamente utilizada. A UML pretendeser a linguagem de modelagem padro para modelar sistemas concorrentes e distribudos.A UML ainda no um padro da indstria, mas esse objetivo est a tomar forma sob os auspcios do ObjectManagement Group (OMG). O OMG pediu informao acerca de metodologias orientadas a objetos quepudessem criar uma linguagem rigorosa de modelao de software. Muitos lderes da indstria responderam naesperana de ajudar a criar o padro.Modelagem de software a atividade de construir modelos que expliquem as caractersticas ou ocomportamento de um software ou de um sistema de software. Na construo do software os modelos podemser usados na identificao das caractersticas e funcionalidades que o software dever prover (anlise derequisitos), e no planejamento de sua construo.Frequentemente a modelagem de software usa algum tipo de notao grfica e so apoiados pelo uso deFerramentas CASE.A modelagem de software normalmente implica a construo de modelos grficos que simbolizam os artefatosdos componentes de software utilizados e os seus inter-relacionamentos. Uma forma comum de modelagem deprogramas procedurais (no orientados a objeto) atravs de fluxogramas, enquanto que a modelagem deprogramas orientados a objeto normalmente usam a linguagem grfica UML.


5/109

5

Os esforos para a criao da UML tiveram incio em outubro de 1994, quando Rumbaugh se juntou a Booch naRational. Com o objetivo de unificar os mtodos Booch e OMT, decorrido um ano de trabalho, foi lanado, emoutubro de 1995, o esboo da verso 0.8 do Unified Process - Processo Unificado (como era conhecido). Nestamesma poca, Jacobson se associou Rational e o escopo do projeto da UML foi expandido para incorporar omtodo OOSE. Nasceu ento, em junho de 1996, a verso 0.9 da UML.Em 1999 j na verso 1.3, a UML passou a ser mantida pela OMG (Object Management Group). Maiores

informaes podem ser encontradas em www.omg.org e em seu site www.uml.org. Hoje qualquer pessoa podesubmeter um comentrio ou acrscimo ao que j existe na especificao da UML, bastando ser membro daOMG.A UML 2.0 a mais recente verso hoje, ela composta por 13 diagramas e a descrio dos casos de uso.Esses diagramas so:

UML 1.x UML 2.0Atividades Atividades Caso de Uso Caso de UsoClasse ClasseObjeto ObjetoSequncia SequnciaColaborao ComunicaoEstado Estado--------- PacotesComponentes ComponentesImplantao Implantao--------- Interao--------- Timing--------- Composite structure diagram

Tabela 1 - Comparao dos diagramas da UML 2.0 com verses anterioresFonte : Desenvolvendo Software com UML 2.0 - Ernani Sales de Medeiros

A especificao da UML pode ser encontrada para download em:http://www.omg.org/ technology/documents/formal/uml .

4 Ciclo de vida do Desenvolvimento de Software seguindo o RUP

4.1 Concepo

4.1.1 RequisitosOs requisitos de um sistema so descries dos servios fornecidos pelo sistema e suas restries operacionais.Esses requisitos refletem as necessidades dos clientes de um sistema que ajuda a resolver algum problema, porexemplo, controlar um dispositivo, eviar um pedido ou encontrar informaes. O processo de descobrir,analisar, documentar e verificar esses servios e restries chamado de engenharia de requisitos.

4.1.1.1 Tipos de requisitos

4.1.1.1.1 Requisitos de usurioDeclaraes em linguagem natural mais diagramas de servios que o sistema fornece e suas restriesoperacionais. Escritos para os clientes.Deve descrever requisitos funcionais e no funcionais, de tal modo que sejam compreensveis pelos usurios desistema que no tm conhecimento tcnico detalhado.Requisitos de usurio so definidos usando uma linguagem simples, tabelas e diagramas quando estes podemser compreendidos por todos os usurios.

Requisito de usurio para um sistema de contabilidadeFonte: Engenharia de Software - SOMMERVILLE, 2007


6/109

6

4.1.1.1.2 Requisitos de sistemaUm documento estruturado estabelecendo descries detalhadas das funes, servios e restries operacionaisdo sistema. Define o que deve ser implementado e assim, pode ser parte de um contrato entre o cliente e odesenvolvedor.

Leitores de requisitos

Figura 2 - Leitores de diferentes tipos de especificaoFonte: Engenharia de Software - SOMMERVILLE, 2007

4.1.1.1.3 Requisitos de domnioRequisitos que vm do domnio de aplicao do sistema e que refletem as caractersticas desse domnio.Podem restringir os requisitos funcionais existentes ou estabelecer como clculos especificos devem serrealizados.Se os requisitos de domnio no forem satisfeitos, o sistema pode no funcionar.

Exemplos: Deve existir uma interface de usurio padro para todos os bancos de dados que ser baseada nopadro Z39.50.

Devido s restries de direitos autorais, alguns documentos devem ser excludos imediatamente nachegada. Dependendo dos requisitos de usurio, esses documentos sero impressos localmente noservidor de sistema para serem encaminhados manualmente para o usurio ou direcionados para umaimpressora de rede.

4.1.1.2 Categorias de requisitosOs requisitos podem ser classificados em duas grandes categorias:

4.1.1.2.1 Requisitos funcionaisDeclaraes de servios que o sistema deve fornecer, como o sistema deve reagir a entradas especficas e comoo sistema deve se comportar em determinadas situaes.Exemplos:

O usurio deve ser capaz de pesquisar em todo o conjunto inicial de banco de dados ou selecionar umsubconjunto a partir dele.

O sistema deve fornecer telas apropriadas para o usurio ler os documentos no repositrio dedocumentos.

Para todo pedido deve ser alocado um identificador nico (ORDER_ID) no qual o usurio deve ser capazde copiar para a rea de armazenamento permanente da sua conta.

4.1.1.2.2 Requisitos no funcionaisEstes definem propriedades e restries de sistema, por exemplo, confiabilidade, tempo de resposta e requisitosde armazenamento. Restries so capacidades de dispositivos de E/S, representaes de sistema, etc.Requisitos de processo podem tambm ser especificados impondo um sistema CASE particular, linguagem deprogramao ou mtodo de desenvolvimento..


7/109

7

4.1.1.2.3 Classificaes de requisitos no funcionais

Figura 3 - Algumas categorias de requisitos no funcionaisFonte: Engenharia de Software - SOMMERVILLE, 2007

Requisitos de produtoRequisitos que especificam que o produto entregue deve se comportar de uma maneira particular, por exemplo,velocidade de execuo, confiabilidade, etc.Requisitos organizacionaisRequisitos que so uma conseqncia de polticas e procedimentos da organizao, por exemplo, padres deprocesso usados, requisitos de implementao, etc.Requisitos externosRequisitos que surgem a partir de fatores externos ao sistema e seu processo de desenvolvimento, porexemplo, requisitos de interoperabilidade, requisitos legais, etc.

Tabela 2 - Exemplos de Requisitos no FuncionaisFonte: Engenharia de Software - SOMMERVILLE, 2007


8/109

8

4.1.1.2.4 Medidas de requisitos

Tabela 3 - Mtricas para especificar requisitos no funcionaisFonte: Engenharia de Software - SOMMERVILLE, 2007

Diretrizes para escrever requisitos Usar um formato padro e us-lo para todos os requisitos. Usar a linguagem de uma forma consistente. Use deve para requisitos obrigatrios, e deveria para

requisitos desejveis. Realce o texto para identificar as partes principais do requisito. Evitar o uso de jarges de computao.

Exemplo de um formato para escrever RequisitosAinda em relao aos requisitos no funcionais, existem aqueles diretamente associados a uma funo eoutros que so gerais para o sistema. Normalmente h duas tabelas, uma que relacione os requisitosfuncionais e outra que relacione os no-funcionais gerais, tambm chamados de requisitos suplementares.Os requisitos no-funcionais podero ser:- Permanentes -nunca mudam com o tempo, por ex. interface por meio de janelas;- Transitrios - poder mudar no futuro, por ex. a forma de calcular impostos;- Obrigatrios aqueles que devem ser obtidos de qualquer maneira;- Desejveis - aqueles que podem ser obtidos caso isso no cause maiores transtornos no processo dedesenvolvimentoUma possvel estrutura para a tabela de requisitos poderia ter os seguintes campos:

Tabela de Requisitos Funcionais Cdigo do requisito funcional (Ex.: F1, F2, F3,...). Nome do requisito funcional (especificao curta). Descrio (especificao longa e detalhamento do requisito). Categoria funcional: evidente ou oculto.

Tabela de Requisitos No Funcionais Cdigo do requisito no funcional (Ex.: NF1. um NF1. dois,... NF2. um NF2. dois,...). Nome do requisito no funcional (especificao curta). Restrio: especificao (longa) do requisito no funcional. Categoria: tipo de restrio: segurana, performance, compatibilidade, etc.


9/109

9

Obrigatoriedade: se o requisito desejvel ou obrigatrio. Permanncia: se o requisito permanente ou transitrio.

Requisitos Funcionais e No Funcionais Associados F1 Registrar emprstimos Oculto ( )

Descrio: O sistema deve registrar emprstimos de DVDs, indicando o cliente e os DVDs que foram emprestados, bemcomo a data do emprstimo e valor previsto para pagamento na devoluo.Requisitos No FuncionaisNome Restrio Categoria Desejvel PermanenteNF1.1 Controle de

Acesso A funo s pode ser acessada por usurio com perfilde operador ou superior.

Segurana ( ) (x)

NF1.2 Identificao deDVDs

Os DVDs devem ser identificadas por um cdigo debarras

Interface ( ) (x)

NF1.3 Identificao docliente

O cliente dever ser identificado a partir de seu nome Interface ( ) ( )

NF1.4 Tempo deregistro

O tempo para registro de cada DVDs deve ser inferior a um segundo.

Performance (x) ( )

NF1.5 Janela nica Todas as funes relacionadas a emprstimos devemser efetuadas em uma nica janela

Interface (x) (x)

... ... ... ... ...

F2 Calcular descontos Oculto ( x )Descrio: O sistema deve calcular descontos nos emprstimos em funo da poltica da empresa.Requisitos No FuncionaisNome Restrio Categoria Desejvel PermanenteNF2.1 Desconto de fimde semana

Nos fins de semana, usurios que levam 4 DVDspagam apenas 3.

Especificao ( ) ( )

... ... ... ... ...

Tabela 4 - RF e RNFFonte: Anlise e Projetos de Sistemas de Informao Orientados a Objetos - RAUL WAZLAWICK

As categorias podem ser opcionais, e dependem de cada tipo de sistema. Algumas foramapresentadas na tabela 4 e 5, porm existem muitas outras. Algumas sugestes de categorias dosrequisitos no funcionais e sua descrio sero mostradas abaixo:

Usabilidade: quais fatores humanos esto envolvidos no sistema? Que tipo de ajuda osistema vai prover? Quais so as formas de documentao ou manuais disponveis? Comoesses manuais sero produzidos? Que tipo de informao eles contero? Seria interessantedefinir esses tpicos na fase de concepo, visto que o contrato com o cliente deveriaespecificar muitas dessas questes.

Confiabilidade: que tipo de tratamento de falhas o sistema ter? O analista no obrigado aproduzir um sistema totalmente tolerante a falhas, mas deve estabelecer que tipo de falhas osistema ser capaz de gerenciar: falta de energia, falha de comunicao, falha na mdia degravao, etc. No podemos confundir falha com erro de programao, pois erros deprogramao so elementos que nenhum software deveria conter. As falhas so situaesanormais que podem ocorrer mesmo para um software implementado sem nenhum erro de

programao. Performance : que tipo de eficincia e preciso o sistema ser capaz de apresentar? Pode-seestabelecer, por exemplo, como requisito de eficincia, que nenhuma consulta base dedados de clientes vai demorar mais de cinco segundos. Note que na fase de concepo nodefinimos como o sistema far para cumprir o requisito, apenas dizemos que de algumaforma ele ter de ser cumprido no projeto. Cabe ao projetista e ao programador garantir queo requisito seja satisfeito. Se o analista por algum motivo conclui que o requisito no podeser cumprido, ento o requisito passa a ser um risco do sistema e eventualmente necessitarde um estudo ainda mais aprofundado na fase de concepo, para verificar a possibilidade desua realizao.

Configurabilidade : o que pode ser configurado no sistema? Devemos definir os elementosque podero ser configurados pelo usurio sem a necessidade de recopilar o sistema.Exemplos de itens configurveis so: o tipo de modem, impressoras, a moeda do pas,polticas da empresa, etc.


10/109

10

Segurana : quais so os tipos de usurios e que funes cada um pode executar? Sugere-sedefinir os perfis de usurios como um requisito suplementar e adicionar um requisito no-funcional de controle de acesso a todos os requisitos funcionais evidentes, para indicarcomo o acesso s funes de sistema controlado.

Implementao : qual linguagem dever ser utilizada? Por que motivo? Que bibliotecasestaro disponveis? Quais bancos de dados sero acessveis?

Empacotamento : de que forma o software dever ser entregue ao usurio final? Legais : muitas vezes uma equipe de desenvolvimento deve contar com uma assessoria jurdica para saber se est infringindo direito autorais ou normas especficas da rea paraqual o software est sendo desenvolvido.

4.1.1.3 Levantamento de requisitosO incio para toda a atividade de desenvolvimento de software o levantamento de requisitos, sendo estaatividade repetida em todas as demais etapas da engenharia de requisitos.Sommerville (2007) prope um processo genrico de levantamento e anlise que contm as seguintesatividades:

Compreenso do domnio: Os analistas devem desenvolver sua compreenso do domnio da aplicao; Coleta de requisitos: o processo de interagir com os stakeholders (pessoas envolvidas com o sistema)

do sistema para descobrir seus requisitos. A compreenso do domnio se desenvolve mais durante essaatividade; Classificao: Essa atividade considera o conjunto no estruturado dos requisitos e os organiza emgrupos coerentes;

Resoluo de conflitos: Quando mltiplos stakeholders esto envolvidos, os requisitos apresentaroconflitos. Essa atividade tem por objetivo solucionar esses conflitos;

Definio das prioridades: Em qualquer conjunto de requisitos, alguns sero mais importantes do queoutros. Esse estgio envolve interao com os stakeholders para a definio dos requisitos maisimportantes;

Verificao de requisitos: Os requisitos so verificados para descobrir se esto completos e consistentese se esto em concordncia com o que os stakeholders desejam do sistema.

O levantamento e anlise de requisitos um processo iterativo, com uma contnua validao de uma atividadepara outra, conforme exemplificado pela Figura 2.

Figura 4 - Processo de levantamento e anlise de requisitos Fonte: Engenharia de Software - SOMMERVILLE, 2007

4.1.1.4 Dificuldades encontradasO problema de no saber especificar corretamente o que o sistema dever fazer muito antigo. Pompilho(1995) cita um exemplo do relatrio produzido por McKinsey, em 1968, e mencionado por B. Langefords e B.Sundgren onde se afirmava que dois teros das empresas ali estudadas estavam desapontadas com oatendimento recebido em sistemas de informao.


11/109

11

Aps mais de 30 anos da elaborao do relatrio a situao no muito diferente.Algumas das razes para o baixo grau de satisfao dos usurios para os sistemas destacam-se:

Na fase de levantamento de requisitos do projeto, onde no utilizada uma tcnica adequada paraextrair os requisitos do sistema;

A falha do analista em no descrever os requisitos do sistema de modo claro, sem ambigidades,conciso e consistente com todos os aspectos significativos do sistema proposto.

Entre as dificuldades encontradas na fase de levantamento de requisitos esto: o usurio principal do sistemano sabe o que quer que o sistema faa ou sabe e no consegue transmitir para o analista; requisitosidentificados, mas que no so realistas e no identificam os requisitos similares informados por pessoasdiferentes. Um stakeholder errado afetar em perda de tempo e dinheiro para ambas as partes envolvidas nodesenvolvimento do sistema.Identifica-se um levantamento de requisitos adequado atravs da boa definio do projeto, da efetividade doprojeto, de informaes necessrias a um perfeito diagnstico e de solues inteligentes.Quanto ao levantamento de requisitos inadequado, o resultado um diagnstico pobre com conclusescomprometidas, no identificao das causas dos problemas, custos elevados, prazos vencidos oucomprometedores, omisso de processos fundamentais e descrditos.

4.1.1.5 Tcnicas de Levantamento de RequisitosAs tcnicas de levantamento de requisitos tm por objetivo superar as dificuldades relativas a esta fase. Todasas tcnicas possuem um conceito prprio e suas respectivas vantagens e desvantagens, que podem serutilizadas em conjunto pelo analista.Sero apresentadas de forma resumida algumas tcnicas de levantamento de requisitos.

4.1.1.5.1 Levantamento orientado a pontos de vistaPara qualquer sistema, de tamanho mdio ou grande, normalmente h diferentes tipos de usurio final. Muitosstakeholders tm algum tipo de interesse nos requisitos do sistema. Por esse motivo, mesmo para um sistemarelativamente simples, existem muitos pontos de vista diferentes que devem ser considerados. Os diferentespontos de vista a respeito de um problema vem o problema de modos diferentes. Contudo, suas perspectivasno so inteiramente independentes, mas em geral apresentam alguma duplicidade, de modo que apresentamrequisitos comuns. As abordagens orientadas a ponto de vista, na engenharia de requisitos, reconhecem essesdiferentes pontos de vista e os utilizam para estruturar e organizar o processo de levantamento e os prpriosrequisitos. Uma importante capacidade da anlise orientada a pontos de vista que ela reconhece a existnciade vrias perspectivas e oferece um framework para descobrir conflitos nos requisitos propostos por diferentesstakeholders. O mtodo VORD (view point-oriented requirements definition definio de requisitos orientada aponto de vista) foi projetado como um framework orientado a servio para o levantamento e anlise derequisitos. A primeira etapa da anlise de ponto de vista identificar os possveis pontos de vista. Nessa etapaos analistas se renem com os stakeholders e utilizam a abordagem de brainstorming para identificar osservios em potencial e as entidades que interagem com o sistema. A segunda etapa a estruturao depontos de vista, que envolve agrupar pontos de vista relacionados, segundo uma hierarquia. Servios comunsesto localizados nos nveis mais altos da hierarquia e herdados por pontos de vista de nvel inferior. A etapa dedocumentao do ponto de vista tem por objetivo refinar a descrio dos pontos de vista e serviosidentificados. O mapeamento de sistema conforme ponto de vista envolve identificar objetos em um projetoorientado a objetos, utilizando as informaes de servio que esto encapsuladas nos pontos de vista.A Figura 3 exemplifica a tcnica de levantamento orientado a ponto de vista.

Figura 5 - Mtodo VORDFonte: Engenharia de Software - SOMMERVILLE, 2007

4.1.1.5.2 EtnografiaA etnografia uma tcnica de observao que pode ser utilizada para compreender os requisitos sociais eorganizacionais, ou seja, entender a poltica organizacional bem como a cultura de trabalho com objetivo defamiliarizar-se com o sistema e sua histria. Os cientistas sociais e antroplogos usam tcnicas de observao

para desenvolver um entendimento completo e detalhado de culturas particulares.


12/109

12

Nesta tcnica, o analista se insere no ambiente de trabalho em que o sistema ser utilizado. O trabalho dirio observado e so anotadas as tarefas reais em que o sistema ser utilizado. O principal objetivo da etnografia que ela ajuda a descobrir requisitos implcitos de sistema, que refletem os processos reais, em vez de osprocessos formais, onde as pessoas esto envolvidas.Etnografia particularmente eficaz na descoberta de dois tipos de requisitos:1. Os requisitos derivados da maneira como as pessoas realmente trabalham, em vez da maneira pelas quais as

definies de processo dizem como elas deveriam trabalhar;2. Os requisitos derivados da cooperao e conscientizao das atividades de outras pessoas.Alguns itens importantes que devem ser executados antes, durante e depois do estudo de observao:

Antes, necessrio identificar as reas de usurio a serem observadas; obter a aprovao das gernciasapropriadas para executar as observaes; obter os nomes e funes das pessoas chave que estoenvolvidas no estudo de observao; e explicar a finalidade do estudo;

Durante, necessrio familiarizar-se com o local de trabalho que est sendo observado. Para isso preciso observar os agrupamentos organizacionais atuais; as facilidades manuais e automatizadas;coletar amostras de documentos e procedimentos escritos que so usados em cada processo especficoque est sendo observado; e acumular informaes estatsticas a respeito das tarefas, como: freqnciaque ocorrem estimativas de volumes, tempo de durao para cada pessoa que est sendo observada.Alm de observar as operaes normais de negcios acima importante observar as excees;

Depois, necessrio documentar as descobertas resultantes das observaes feitas. Para consolidar oresultado preciso rever os resultados com as pessoas observadas e/ou com seus superiores.

A anlise de observao tem algumas desvantagens como, consumir bastante tempo e o analista ser induzido aerros em suas observaes. Mas em geral a tcnica de observao muito til e freqentemente usada paracomplementar descobertas obtidas por outras tcnicas.

4.1.1.5.3 WorkshopsTrata-se de uma tcnica de elicitao em grupo usada em uma reunio estruturada. Devem fazer parte dogrupo uma equipe de analistas e uma seleo dos stakeholders que melhor representam a organizao e ocontexto em que o sistema ser usado, obtendo assim um conjunto de requisitos bem definidos.Ao contrrio das reunies, onde existe pouca interao entre todos os elementos presentes, o workshop tem oobjetivo de acionar o trabalho em equipe. H um facilitador neutro cujo papel conduzir a workshop epromover a discusso entre os vrios mediadores. As tomadas de deciso so baseadas em processos bemdefinidos e com o objetivo de obter um processo de negociao, mediado pelo facilitador.Uma tcnica utilizada em workshops o brainstorming. Aps os workshops sero produzidas documentaesque refletem os requisitos e decises tomadas sobre o sistema a ser desenvolvido.Alguns aspectos importantes a serem considerados: a postura do condutor do seminrio deve ser de mediador eobservador; a convocao deve possuir dia, hora, local, horrio de incio e de trmino; assunto a ser discutido ea documentao do seminrio.

4.1.1.5.4 PrototipagemProttipo tem por objetivo explorar aspectos crticos dos requisitos de um produto, implementando de formarpida um pequeno subconjunto de funcionalidades deste produto. O prottipo indicado para estudar asalternativas de interface do usurio; problemas de comunicao com outros produtos; e a viabilidade deatendimento dos requisitos de desempenho. As tcnicas utilizadas na elaborao do prottipo so vrias:interface de usurio, relatrios textuais, relatrios grficos, entre outras.Alguns dos benefcios do prottipo so as redues dos riscos na construo do sistema, pois o usurio chave jverificou o que o analista captou nos requisitos do produto. Para ter sucesso na elaborao dos prottipos necessria a escolha do ambiente de prototipagem, o entendimento dos objetivos do prottipo por parte detodos os interessados no projeto, a focalizao em reas menos compreendidas e a rapidez na construo.

4.1.1.5.5 EntrevistasA entrevista uma das tcnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicialde obteno de dados. Convm que o entrevistador d margem ao entrevistado para expor as suas idias. necessrio ter um plano de entrevista para que no haja disperso do assunto principal e a entrevista fiquelonga, deixando o entrevistado cansado e no produzindo bons resultados.As seguintes diretrizes podem ser de grande auxilio na direo de entrevistas bem sucedidas com o usurio:desenvolver um plano geral de entrevistas, certificar-se da autorizao para falar com os usurios, planejar aentrevista para fazer uso eficiente do tempo, utilizar ferramentas automatizadas que sejam adequadas, tentardescobrir que informao o usurio est mais interessado e usar um estilo adequado ao entrevistar.Para planejar a entrevista necessrio que antes dela sejam coletados e estudados todos os dados pertinentes

discusso, como formulrios, relatrios, documentos e outros. Dessa forma, o analista estar bemcontextualizado e ter mais produtividade nos assuntos a serem discutidos na entrevista.


13/109

13

importante determinar um escopo relativamente limitado, focalizando uma pequena parte do sistema paraque a reunio no se estenda por mais de uma hora. O usurio tem dificuldade de concentrao em reuniesmuito longas, por isso importante focalizar a reunio no escopo definido.Aps a entrevista necessrio validar se o que foi documentado pelo analista est de acordo com a necessidadedo usurio, que o usurio no mudou de opinio e que o usurio entende a notao ou representao grfica desuas informaes.

A atitude do analista em relao entrevista determinar seu fracasso ou sucesso. Uma entrevista no umacompetio, deve-se evitar o uso excessivo de termos tcnicos e no conduzir a entrevista em uma tentativa depersuaso. O modo como o analista fala no deve ser muito alto, nem muito baixo, tampouco indiretamente, ouseja, utilizar os termos: ele disse isso ou aquilo na reunio para o outro entrevistado. O modo melhor para agirseria, por exemplo, dizer: O Joo v a soluo para o projeto dessa forma. E o senhor Andr, qual a suaopinio? Em uma entrevista o analista nunca deve criticar a credibilidade do entrevistado.O analista deve ter em mente que o entrevistado o perito no assunto e fornecer as informaes necessriasao sistema. Para elaborar perguntas detalhadas necessrio solicitar que o usurio:

Explique o relacionamento entre o que est em discusso e as demais partes do sistema; Descreva o ponto de vista de outros usurios em relao ao item que esteja sendo discutido; Descreva informalmente a narrativa do item em que o analista deseja obter informaes; Perguntar ao usurio se o item em discusso depende para a sua existncia de alguma outra coisa, para

assim poder juntar os requisitos comuns do sistema, formando assim um escopo conciso.Pode-se utilizar a confirmao, para tanto o analista deve dizer ao usurio o que acha que ouviu ele dizer. Nestecaso, o analista deve utilizar as suas prprias palavras em lugar das do entrevistado e solicitar ao entrevistadoconfirmao do que foi dito.

4.1.1.5.6 QuestionriosO uso de questionrio indicado, por exemplo, quando h diversos grupos de usurios que podem estar emdiversos locais diferentes do pas. Neste caso, elaboram-se pesquisas especficas de acompanhamento comusurios selecionados, que a contribuio em potencial parea mais importante, pois no seria prticoentrevistar todas as pessoas em todos os locais.Existem vrios tipos de questionrios que podem ser utilizados. Entre estes podemos listar: mltipla escolha,lista de verificao e questes com espaos em branco. O questionrio deve ser desenvolvido de forma aminimizar o tempo gasto em sua resposta.Na fase de preparao do questionrio deve ser indicado o tipo de informao que se deseja obter. Assim queos requisitos forem definidos o analista deve elaborar o questionrio com questes de forma simples, clara econcisa, deixar espao suficiente para as repostas que forem descritivas e agrupar as questes de tpicosespecficos em um conjunto com um ttulo especial. O questionrio deve ser acompanhado por uma cartaexplicativa, redigida por um alto executivo, para enfatizar a importncia dessa pesquisa para a organizao.Deve ser desenvolvido um controle que identifique todas as pessoas que recebero os questionrios. Adistribuio deve ocorrer junto com instrues detalhadas sobre como preench-lo e ser indicado claramente oprazo para evoluo do questionrio. Ao analisar as respostas dos participantes feito uma consolidao dasinformaes fornecidas no questionrio, documentando as principais descobertas e enviando uma cpia comestas informaes para o participante como forma de considerao pelo tempo dedicado a pesquisa.

4.1.1.5.7 BrainstormingBrainstorming uma tcnica para gerao de idias. Ela consiste em uma ou vrias reunies que permitem queas pessoas sugiram e explorem idias.As principais etapas necessrias para conduzir uma sesso de brainstorming so:

Seleo dos participantes: Os participantes devem ser selecionados em funo das contribuiesdiretas que possam dar durante a sesso. A presena de pessoas bem informadas, vindas de diferentesgrupos garantir uma boa representao;

Explicar a tcnica e as regras a serem seguidas: O lder da sesso explica os conceitos bsicos debrainstorming e as regras a serem seguidas durante a sesso;

Produzir uma boa quantidade de idias: Os participantes geram tantas idias quantas foremexigidas pelos tpicos que esto sendo o objeto do brainstorming. Os participantes so convidados, umpor vez, a dar uma nica idia. Se algum tiver problema, passa a vez e espera a prxima rodada.

No brainstorming as idias que a princpio paream no convencionais, so encorajadas, pois elasfreqentemente estimulam os participantes, o que pode levar a solues criativas para o problema. O nmerode idias geradas deve ser bem grande, pois quanto mais idias forem propostas, maior ser a chance deaparecerem boas idias. Os participantes tambm devem ser encorajados a combinar ou enriquecer as idias deoutros e, para isso, necessrio que todas as idias permaneam visveis a todos os participantes.

Nesta tcnica designada uma pessoa para registrar todas as idias em uma lousa branca ou em papel. medida que cada folha de papel preenchida, ela colocada de forma que todos os participantes possam v-la.


14/109

14

Analisar as idias a fase final do brainstorming . Nessa fase realizada uma reviso das idias, uma de cadavez. As consideradas valiosas pelo grupo so mantidas e classificadas em ordem de prioridade.

4.1.1.5.8 JADJAD ( Joint Application Design ) uma tcnica para promover cooperao, entendimento e trabalho em grupoentre os usurios desenvolvedores.

O JAD facilita a criao de uma viso compartilhada do que o produto de software deve ser. Atravs da suautilizao os desenvolvedores ajudam os usurios a formular problemas e explorar solues.Dessa forma, os usurios ganham um sentimento de envolvimento, posse e responsabilidade com o sucesso doproduto.A tcnica JAD tem quatro princpios bsicos:1. Dinmica de grupo: so realizadas reunies com um lder experiente, analista, usurios e gerentes, paradespertar a fora e criatividade dos participantes.O resultado final ser a determinao dos objetivos e requisitos do sistema;2. Uso de tcnicas visuais: para aumentar a comunicao e o entendimento;3. Manuteno do processo organizado e racional: o JAD emprega a anlise top down e atividades bemdefinidas. Possibilita assim, a garantia de uma anlise completa reduzindo as chances de falhas ou lacunas noprojeto e cada nvel de detalhe recebe a devida ateno;4. Utilizao de documentao padro: preenchida e assinada por todos os participantes. Este documentogarante a qualidade esperada do projeto e promove a confiana dos participantes.A tcnica JAD composta de duas etapas principais: planejamento, que tem por objetivo elicitar e especificaros requisitos; e projeto, em que se lida com o projeto de software.Cada etapa consiste em trs fases: adaptao, sesso e finalizao. A fase de adaptao consiste na preparaopara a sesso, ou seja, organizar a equipe, adaptar o processo JAD ao produto a ser construdo e preparar omaterial. Na fase de sesso realizado um ou mais encontros estruturados, envolvendo desenvolvedores eusurios onde os requisitos so desenvolvidos e documentados. A fase de finalizao tem por objetivo convertera informao da fase de sesso em sua forma final (um documento de especificao de requisitos).H seis tipos de participantes, embora nem todos participem de todas as fases:

Lder da sesso: responsvel pelo sucesso do esforo, sendo o facilitador dos encontros. Deve sercompetente, com bom relacionamento pessoal e qualidades gerenciais de liderana;

Engenheiro de requisitos: o participante diretamente responsvel pela produo dos documentos desada das sesses JAD. Deve ser um desenvolvedor experiente para entender as questes tcnicas edetalhes que so discutidos durante as sesses e ter habilidade de organizar idias e express-las comclareza;

Executor: o responsvel pelo produto sendo construdo. Tem que fornecer aos participantes umaviso geral dos pontos estratgicos do produto de software a ser construdo e tomar as decisesexecutivas, tais como alocao de recursos, que podem afetar os requisitos e o projeto do novo produto;

Representantes dos usurios: so as pessoas na empresa que iro utilizar o produto de software.Durante a extrao de requisitos, os representantes so freqentemente gerentes ou pessoas-chavedentro da empresa que tem uma viso melhor do todo e de como ele ser usado;

Representantes de produtos de software: so pessoas que esto bastante familiarizadas com ascapacidades dos produtos de software. Seu papel ajudar os usurios a entender o que razovel oupossvel que o novo produto faa;

Especialista: a pessoa que pode fornecer informaes detalhadas sobre um tpico especfico.O conceito do JAD de abordagem e dinmica de grupo poder ser utilizado para diversas finalidades, como:planejamento de atividades tcnicas para um grande projeto, discusso do escopo e objetivos de um projeto eestimativa da quantidade de horas necessrias para desenvolver sistemas grandes e complexos.A maioria das tcnicas JAD funciona melhor em projetos pequenos ou mdios. Para um sistema grande ecomplexo podem ser usadas mltiplas sesses JAD para acelerar a definio dos requisitos do sistema.


15/109

15

Tcnicas tradicionaisTabela 5 - Grupos de tcnicas para levantamento de requisitos

Fonte: Revista Engenharia de Software Ano: 01 Edio 02

4.1.1.5.9 Anlise de DocumentosA equipe de projeto freqentemente usa a anlise de documentos para compreender o sistema no

estado. Sob circunstncias ideais, a equipe de projeto que desenvolveu o sistema existente ter produzidouma documentao, que seria ento atualizada por todos os projetos subseqentes.

Nesse caso, a equipe de projeto pode comear revendo a documentao e examinando o prpriosistema.

Infelizmente, a maioria dos sistemas no bem documentada porque as equipes de projeto deixamde documentar seus projetos ao longo do caminho, e quando terminam no h mais tempo para retornare fazer a documentao. Portanto, pode no haver informaes atualizadas sobre alteraes recentes dosistema. Entretanto, h muitos documentos teis existentes nas empresas: relatrios em papel,memorandos, manuais de poltica da empresa, manuais de treinamento de usurios, diagramas daempresa e formulrios.

Mas esses documentos (formulrios, relatrios, manuais, diagramas) contam a parte histrica. Elesrepresentam o sistema formal que a empresa usa. Com muita freqncia, o sistema informal ou realdifere do sistema formal, e essas diferenas, do fortes indicaes de quais necessidades precisam seralteradas.

Por exemplo, formulrios e relatrios que nunca so usados devero ser eliminados. Da mesmamaneira, quadros ou perguntas em formulrios que nunca so preenchidos (ou so usados para outrasfinalidades) deveriam ser repensados.

A indicao mais incontestvel de que o sistema precisa ser mudado quando os usurios criamseus prprios formulrios ou acrescentam informaes adicionais aos existentes. Portanto, til revisartanto os formulrios em branco quanto os preenchidos para identificar essas divergncias. Da mesma

maneira, quando os usurios acessam diversos relatrios para satisfazer suas necessidades deinformaes um sinal claro de que novas informaes ou novos formatos de informaes sonecessrios.

O cliente cometeu um erro. Essecampo deveria se intitular Nome doProprietrio , para evitar confuso.

O pessoal da clnica teveque acrescentar informaes adicionaissobre o tipo de animal e asua data de nascimento.Essa informao deve ser adicionada ao novo


16/109

16

Figura 6 - Executando uma Anlise de DocumentosFonte: DENNIS; HALEY WIXOM, 2005

4.1.1.6 Documento de RequisitosO documento de requisitos a declarao oficial do que requisitado pelos desenvolvedores do

sistema.Deve incluir ambos, uma definio dos requisitos de usurio e uma especificao dos requisitos de

sistema.NO um documento de projeto. Logo que possvel, ser preciso definir O QU o sistema deve

fazer ao invs de COMO deve ser feito.

4.1.1.6.1 Estrutura de documento de requisitos

Uma srie de grandes organizaes, como o departamento de defesa dos EUA e o IEEE, definempadres de documentos de requisitos. O padro mais amplamente conhecido o IEEE/ANSI 830-1988, que sugere a seguinte estrutura para os documentos de requisitos:

1. Introduo1.1. Propsito1.2. Escopo1.3. Definies, acrnimos e abreviaturas1.4. Referncias1.5. Viso geral do restante do documento

2. Descrio Geral2.1. Perspectiva do produto2.2. Funo do produto2.3. Caractersticas dos usurios2.4. Restries gerais2.5. Suposies e dependncias

3. Requisitos EspecficosAbrangem requisites funcionais, no funcionais e de interface.

4. Apndices5. ndice

Embora o padro IEEE no seja o ideal, ele contm uma grande quantidade de boas recomendaes decomo redigir requisitos e evitar problemas. Ele muito geral para funcionar como um padro em umaorganizao, porm pode ser configurado e adaptado para definir um padro dirigido s necessidades dedeterminada organizao, como demonstrado nos exemplos nessa apostila.

Clinica Veterinria CentralFicha informativa do Paciente

Nome: Buffy Pat Smith ______________________ Nome do animal: Buffy Collie 6/7/99 __________ Endereo: Rua Bandeirantes, 100 ________________

____________ Rio de Janeiro RJ _______________ Telefone: _________ (21) 2000-3400 ___________ Possui Seguro:_______ Sim ____________________ Seguradora: _______________ Animed ___________ Nmero da Aplice: ________ KA-5493243 __________

O cliente no inclui ocdigo de rea no nmero

do telefone. Isso deve ser esclarecido ao cliente.


17/109

17

4.1.2 Casos de UsoO caso de uso a parte mais importante da construo de software orientado a objetos utilizando a UML.Nesse processo a UML apenas a ferramenta.

4.1.2.1 O que um Caso de Uso?Para entendermos o conceito de Caso de Uso precisamos conhecer o de Ator.

4.1.2.2 O que um ator?Um ator pode ser uma pessoa, um sistema, ou mesmo, o que chamvamos na anlise estruturada, deentidade externa, por exemplo, um banco. Um ator pode ser algo como um roteador, ele realiza umaatividade e sempre atua sobre um Caso de Uso.Imaginemos um palco e nele, para a realizao de uma pea, precisamos de quem represente um papel.Na UML este o significado dado, algum ou alguma coisa atua ou interage com outras pessoas ou coisas,para que algo seja realizado. Esse ao ator. E por essa razo que esse nome adequado.

O Ator, em um diagrama de Casos de Uso (uc), tambm pode ser confuso para os novatos naabordagem, mas para todo e qualquer efeito bom sempre ter em mente que um Ator um PAPELDESEMPENHADO POR ALGUMA COISA EXTERNA ao sistema (no necessariamente uma pessoa). Atmesmo o tempo pode ser um Ator para tarefas que ocorrem com freqncia temporal.

Essa definio ainda aparenta no ser to simples, vou demonstrar os erros mais comuns a respeitodos Atores:

Componentes internos do sistema no so Atores: comum o analista imaginar queporque sistemas externos podem ser atores, o banco de dados da aplicao que est sendodesenvolvida deve ser um ator tambm, mas isso errado, lembre que Ator um papel deresponsabilidade externa ao sistema. O que deve funcionar dentro da responsabilidade do sistemano pode ser extrado como um Ator.

Hardwares internos do sistema no so Atores: Voc pode imaginar que um servidor externo ao sistema, ou uma impressora em um Caso de Uso que precise imprimir alguma coisa externa ao sistema tambm, porm, esses itens externos ao sistema so componentes que osoftware pressupe que existem e cumpriro seu papel. Ento, so como os componentes dofuncionamento interno do software (como o banco de dados da aplicao) e assim sendo, no soAtores. Alguns tipos de hardwares podem ser Atores, mas somente quando for importante para a

anlise do sistema destacar a presena desse hardware. Por exemplo, softwares para controlesindustriais podem ter alguns sensores que indicam algum tipo de problema na linha de produo edisparam algum comportamento (Caso de Uso) no sistema. Este sim pode ser um hardware que um Ator no sistema, pois importante destacar isso para o funcionamento do Caso de Uso. Outrohardware que pode ser um Ator seria a catraca do controle de ponto (entrada e sada defuncionrios) para um sistema de Administrao de Pessoal. Ela desempenha um papel no sistema,seria um Ator.

A definio de Atores (e Casos de Uso) no o controle de acessos da aplicao: Esse erro tambm comum: confundir a definio de Atores com o que os usurios podem ou no fazer dentro do sistema.No essa a idia! A representao do Ator somente destaca o papel que um usurio assume ao usar oCaso de Uso.Um caso de uso pode ser explicado como uma macroatividade que encerra diversas tarefas ou atividades.Essas tarefas visam consecuo dessa macroatividade.Um caso de uso pode ser, tambm, uma representao descritiva de variadas aes para a realizaodessa macroatividade, enquanto tivermos afinidade entre as aes realizadas, teremos um caso de uso.

4.1.2.3 Como descobrir casos de uso?Para descobrir os casos de uso, devem-se identificar os atores envolvidos com o sistema

(funcionrios, gerentes, clientes, etc.). Para tanto, o analista deve responder a algumas perguntas, como:

a) Quem usa o sistema?b) Quem mantm ou configura o sistema?c) Quais outros sistemas de informao utilizam ou so utilizados pelo sistema?d) Quem busca informao no sistema?e) Quem fornece informaes para o sistema?


18/109

18

Deve-se ento identificar os principais processos de negcio iniciados ou com participao dessesatores. A cada grande processo corresponder um caso de uso.Existe um diagrama na UML para representar casos de uso e seus atores. A principal utilidade dessediagrama est no fato de se poder associar a ele, caso se utilize uma ferramenta CASE, um conjunto deoutros artefatos que representam a interao entre os atores e o sistema.

4.1.2.4 Para qu Casos de Uso?Quem est iniciando projetos usando objetos e UML pode questionar sobre a importncia de Casosde Uso bem modelados e detalhados, talvez por no entender direito por que e para qu definirbonequinhos e elipses com nomes de funcionalidades e o que isso adiciona ao projeto.

Olhando para um diagrama de Casos de Uso, pela sua simplicidade, um analista poder observarrapidamente as funcionalidades envolvidas no sistema, os usurios envolvidos e integraes com sistemasexternos. O propsito maior do Caso de Uso fornecer uma descrio do comportamento do sistema doponto de vista do usurio.

O Caso de Uso uma adio muito importante para a abordagem da Anlise Orientada a Objetos epara o Processo Interativo de Engenharia de Software. A modelagem do diagrama de Casos de Uso simples e muitos autores ensinam sobre as mais variadas tcnicas para descrever em texto um Caso deUso (destacando o timo livro de Alistair Cockburn Writing Effective Use Cases). Modelando ouescrevendo, o principal para entender a importncia do Caso de Uso so os objetivos dele:

Definir Escopo: Um conjunto de Casos de Uso define o escopo do sistema de umamaneira simples. Se no diagrama aparece um Caso de uso chamado Plantar Batata, os usuriosno podero dizer que plantar couve est no escopo do sistema.

Organizar e dividir o trabalho: O Caso de Uso uma importante unidade deorganizao do trabalho dentro do projeto, geralmente nas equipes de projeto comum ouvir que

o Z est trabalhando no Caso de Uso X e o Joo est com o Caso de Uso Y. A unidade do Casode Uso divide o trabalho da equipe entre as pessoas, fora isso, comum dizer que o Caso de Usoest em Anlise, em Programao ou em Teste. Casos de Uso tambm so entreguesseparadamente aos usurios em conjuntos divididos em fases ou iteraes no projeto. Ento,dizemos que a primeira iterao (ou entrega) ter os Casos de Uso X, Y, Z e W e na segundaiterao ter os Casos de Uso T, H, I e J.

Estimar o tamanho do projeto: O Caso de Uso fornece mtricas para definir o tempo

de desenvolvimento. Uma das mtricas que pode ser aplicada sobre Casos de Uso a UCP - UseCase Point (Pontos por Caso de Uso) que consiste em classificar os Casos de Uso em nvel decomplexidade e somando todos os Casos de Uso do projeto (e mais alguns fatores) voc consegueestimar o esforo do projeto em horas. Alm do UCP, podem ser aplicadas as tcnicas de Pontosde Funo (Function Points) que so mais padronizadas e completas.

Direcionar os testes: Os testes do sistema (essencialmente os funcionais que so osmais importantes) so derivados do Caso de Uso. Essa caracterstica uma das mais importantese geralmente desprezada, pois com Casos de Uso, os testes so planejados no incio do projeto eno no fim, diminuindo os riscos. A partir dos Casos de Uso, Casos de Teste so criados paravalidar o funcionamento do software.

4.1.2.5 Quem deve fazer extrao de Casos de Uso?Existem departamentos de recrutamento e seleo aplicando vastos testes de matemtica paracandidatos a analista de negcios; acredita-se que isso possa ser um grande engano.O analista de negcios que extrai Casos de Uso faz o que o nome do seu cargo indica: analisa negcios,como so criados e realizados. Negcio, aqui, no tem o sentido de estabelecimento comercial, masrefere-se atividade principal, abstrao do negcio comercial, daquela empresa.A extrao de um Caso de Uso possvel por duas vias a observao e a entrevista, ou outra tcnicavista anteriormente que se julgue adequada. A observao somente possvel em casos onde aatividade repetitiva, realizada por um operador ou uma mquina. A entrevista possvel entrepessoas. Essa ltima a mais comum.Assim, precisamos de analista de negcio com boa capacidade de comunicao interpessoal, noconfunda com pessoa que vive contando piadas, inconvenientes na maioria das vezes.HCIs significa Habilidade de Comunicao Interpessoal.


19/109

19

Com o aprimoramento das HCIs podemos aperfeioar a capacidade de ouvir (ato de entender o quealgum quer nos dizer) em contraposio ao ato de escutar (ato mecnico de perceber os sons). (www.reinsner.com.br ).O ato de extrair Casos de Uso implica muito mais em ouvir o interlocutor do que o de escutar. Aqui,apenas o subconsciente registrou o que escutamos e, definitivamente, interessa-nos o que o conscientecaptou e pode reproduzir.Alm da capacidade de comunicao interpessoal, o analista de negcio deve conseguir escrever o queouviu, essa tarefa no fcil, exige habilidade e experincia.Quando iniciar uma extrao de caso de uso, procure saber detalhes do entrevistado. Se ele gosta muitode futebol, leia todo o caderno de esporte do jornal do dia, a fim de se inteirar dos lances maisimportantes do campeonato e seu time.Aqui, a cultura geral , tambm, fator importante. Se entrar na sala do entrevistado e ver um pstercom a foto de Oscar Schmidt, e iniciar a conversa com: esse jogador de vlei muito bom, no ? Muitoprovavelmente, ele reduzir sua disposio de conversar contigo em 30% ou 40%. Para reverter essequadro, ter o dobro do trabalho.E o que essas habilidades tm a ver com a matemtica? Talvez nada.

4.1.2.6 Como representar um Caso de Uso?

Figura 7 - Sugesto de estrutura de Caso de UsoFonte: Desenvolvendo Software com UML 2.0 - Ernani Medeiros

Autores e ferramentas de modelagem UML sugerem outras sees, porm muitas vezes no produtivoporque, quanto mais se quebra um documento em pedaos, mais difcil fica sua leitura.Lembre-se de que o entrevistado dever assinar o Caso de Uso descrito, isso faz parte docomprometimento dele.


20/109

20

4.1.2.6.1 NomeDar um nome ao Caso de Uso usando um verbo no infinitivo facilitar a sua classificao. Podemostambm informar um nome interno para o Caso de Uso, como UC03245 . Nome interno a forma como aoutra aplicao vai se referir a esse caso de uso.

4.1.2.6.2 DescrioUma breve descrio apenas relata qual o assunto que aquele Caso de Uso trata. Isso facilitar a busca deCaso de Uso por uma indexao XML, por exemplo.

4.1.2.6.3 Pr-condio e Ps-condiesPr-condio qualquer ao ou reao de um subsistema ou ator que possibilite a esse Caso de Uso terincio. Relate aqui o que provoca o caso de uso. Pode inclusive, ser um conjunto de aes ou reaes. Sorestries para um Caso de Uso iniciar.

Esses dois elementos demonstram restries para um Caso de Uso iniciar e garantias mnimasalcanadas quando este terminar.

O Caso de Uso possui uma precondio e geralmente vrias ps-condies.A precondio uma restrio sobre quando um Caso de Uso pode ser iniciado. PRESTE ATENO!

a CONDIO que o Sistema deve se encontrar para permitir que o Caso de Uso inicie. No confundacom o evento que inicia o Caso de Uso. A precondio mais comum nos sistemas "O usurio deve estarlogado". Vamos imaginar que a arquitetura da nossa aplicao de pedidos seja integrada com aautenticao do domnio da rede, nosso Caso de Uso "Consultar Pedido" ficaria assim:

Caso de Uso: Consultar PedidoAtor: Vendedor

Precondio: O usurio deve estar logado.1. O Ator inicia o caso de uso selecionando Consultar Pedido;2. O Sistema oferece a interface de consulta para pedidos;3. O Ator informa o nmero do pedido desejado;4. O Sistema exibe os dados do pedido;

[os fluxos alternativos foram suprimidos] importante ressaltar que a pr-condio um elemento opcional da narrativa do Caso de Uso. O

que descrevemos na pr-condio deve ser importante e agregar um valor observvel anlise. Fazemosessa observao, pois muito comum achar alguns escritos "bvios" nas precondies, veja algunsexemplos:

O usurio deve ter acesso a um terminal O usurio deve saber escrever O sistema deve estar funcionando A base de dados deve estar configurada

Geralmente a precondio de um Caso de Uso uma ps-condio de um Caso de Uso anterior. Sea nossa aplicao de pedidos no fosse integrada com o login da rede possivelmente teramos um Caso deUso "Login" que teria como ps-condio "O usurio deve estar logado".

Vamos ver quais seriam as ps-condies de Consultar Pedidos:

Caso de Uso: Consultar PedidoAtor: Vendedor

Precondio: O usurio deve estar logado.5. O Ator inicia o caso de uso selecionando Consultar Pedido;6. O Sistema oferece a interface de consulta para pedidos;7. O Ator informa o nmero do pedido desejado;

8. O Sistema exibe os dados do pedido;[os fluxos alternativos foram suprimidos]


21/109

21

Ps-condies: Um pedido selecionado; No existem pedidos para consulta.

As ps-condies descrevem os resultados observveis de sucesso ou de falha do Caso de Uso. Asps-condies so importantes, pois mostram as garantias mnimas que um Caso de Uso deve oferecer.

4.1.2.6.4 Representao doa AtoresOs atores envolvidos so separados por vrgula, caso uma busca seja necessria, esse formato trarfacilidade, alm de permitir a visualizao de quais atores so responsveis por quais aes. Sempre oentrevistado deve estar nessa seo com o ator, e seu papel nesse momento deve ser claro. No interessante conversar com o jardineiro sobre algo que acontece no almoxarifado.

Expanso dos Casos de Uso

A expanso, detalhamento ou descrio como so chamados corresponde ao aprofundamento daanlise de requisitos.

Quando se est expandindo um caso de uso preciso proceder a um exame detalhado do processode negcio. Deve-se descrever o caso de uso passo a passo: como ele ocorre, como a interao entre osusurios e o sistema. Essa descrio passo a passo interessante por no ser estruturada com desvios, aprincpio. Ela se baseia em uma seqncia default , ou fluxo principal , na qual se descreve o queacontece quando tudo d certo na interao. Esse fluxo tambm chamado de caminho feliz, pois neleno necessrio dizer o que acontece quando ocorrem excees.

Depois de descrever o fluxo principal, passa-se a uma atividade que corresponde a uma dasgrandes contribuies do caso de uso para descrever a interao entre usurios e sistemas: analisa-se deforma crtica cada passo do caso de uso e procura-se verificar o que poderia dar errado. A partir daidentificao de uma possvel exceo, deve-se construir uma descrio de procedimentos para contornaro problema. O caso de uso passa a possuir as chamadas seqncias alternativas (fluxos). Veremosoutros exemplos adiante.

Assim a primeira atividade da anlise dentro da fase de elaborao consiste em:a) Identificar a seqncia de passos principal (fluxo principal).b) Identificar as seqencias alternativas associadas s possveis excees, ou seja, os

fluxos alternativos .4.1.2.6.5 Fluxo Principal

importante citar que quando dizemos Caso de Uso, estamos mais preocupados com a descriodo Caso de Uso do que com o desenho da elipse no diagrama, ou o prprio diagrama.

Isso porque nos projetos, associamos o termo Caso de Uso ao texto, descrio, e no aodesenho. a descrio do Caso de Uso que importante, ela que permite os benefcios j citados, e noo desenho. O desenho serve mais para organizar os Casos de Uso e representar graficamente (que maisamigvel do que o texto) as funcionalidades do sistema.

CASO DE USO = DIAGRAMA + DESCRIOComo j disse, existem inmeros formatos ou templates de preenchimento de uma descrio de

Caso de Uso. O objetivo aqui apresentar o conceito que se aplica a maioria dos formatos com exemplosclaros. A UML no define o modo como uma descrio deve ser descrita. A UML se limita apenas formade diagramar o modelo de Casos de Uso (notao).

A descrio do Caso de Uso um texto passo a passo sobre as aes que o Ator pode tomar e comoo Sistema responder a esta ao. A descrio vai ento evoluindo, entre aes do Ator e as respostas doSistema, para o objetivo do Ator, at este ser alcanado.

Um dos erros mais comuns que vemos nas descries de Casos de Uso o analista imaginar o Casode Uso como um programa e tratar a sua descrio como um passo a passo sobre as tarefas internas dosistema. O analista tambm pode errar se quebrar o objetivo do Ator em diversos Casos de Uso menores

j imaginando como o sistema ser implementado (como a decomposio funcional). Lembre-se: nessemomento o seu foco deve ser o objetivo do Ator, e no como o sistema resolver esse objetivo.

Como exemplo: o Caso de Uso Emitir Pedido envolve vrias tarefas menores como selecionarprodutos, escolher forma de pagamento, calcular descontos, escolher forma de entrega, porm, tudo issoso partes do objetivo maior que emitir o pedido.

O Caso de Uso um objetivo do Ator e no uma tarefa do sistema. Uma das formas de evitar essaproliferao de Casos de Uso no sistema perguntar a si mesmo ao criar um Caso de Uso:


22/109

22

- Se eu entregar esse Caso de Uso sozinho para os usurios do sistema resolveria algum problemadeles? Agregaria algum valor para os usurios? Com esse Caso de Uso o usurio conseguiria resolver algum problema que o sistema deve atender?

Essas perguntas so suficientes. Como exemplo, no caso acima, se o analista criar um Caso de Usochamado Escolher Forma de Pagamento e entregar ele sozinho para os usurios teria algum valor? Claroque no. Pode ter certeza que os usurios diriam que no serve pra nada fora da funcionalidade EmitirPedido.IMPORTANTE: Na descrio do Caso de Uso a resposta do sistema deve se limitar somente ao que oAtor consegue ver. No necessrio se preocupar em como o sistema obteve ou calculou os dados.Limite-se a escrever o que o sistema responde e no como ele obtm a resposta.Cada Fluxo Principal tem tarefas, e voc deve ser especfico nessa descrio. Informaes vagas como: Ocliente seleciona o tipo de cadastro e informa seus dados, devem ser evitadas.Perguntas devem ser feitas:O que ?Para que?Por qu?Como?Ento voc ter um fluxo bem escrito.A situao que acaba de ser descrita poderia ser reescrita para: Selecione cadastre-se, informando osdados de: nome, sobrenome, logradouro, complemento, CEP, cidade, estado, telefone residencial ecomercial, CPF e RG, a fim de poder efetivar compras no site.Excees no so previstas aqui, o mundo perfeito descrito no fluxo principal.Numere o fluxo principal com 1, 2, 3, 4, 5, 6, 7... por exemplo. E os fluxos alternativos com 1.2, 1.3, 2.3,esse ltimo, por exemplo, significa que o terceiro fluxo alternativo pertencente ao fluxo principal nmero2.

Para exemplificar uma descrio, vamos descrever o Caso de Uso Emprestar DVD em texto:

Caso de uso: Emprestar DVD

Um cliente solicita a locao de alguns DVD. Aps identificar-se e identificar os DVD, se no houverproblemas em seu cadastro e se os DVDs no estiverem reservados, ele pode solicit-los, ciente do prazode devoluo e do valor a ser pago.

Exemplo de caso de uso de alto nvel.O analista deve ter em mente que o caso de uso de alto nvel usado na fase de concepo deve

descrever sucintamente o funcionamento dos principais processos do sistema. No , portanto o objetivoda verso de alto nvel o detalhamento de todas as possveis excees do processo.

Apenas a verso expandida que vai tentar esgotar todas as possibilidades.Abaixo apresentamos um exemplo de caso de uso expandido com suas seqncias/fluxos

alternativos:

Caso de Uso Emprestar DVDAtores: Cliente e Funcionrio

Fluxo Principal:

1. O cliente entra no sistema2. O sistema solicita nome de usurio e senha3. O cliente fornece o nome e senha [A1]4. O sistema valida usurio e senha5. O cliente escolhe os DVDs que deseja locar [A2] [A3] [A4]6. O sistema registra cada um dos DVDs.7. O sistema finaliza a locao [A7]8. O sistema lhe informa a hora aproximada da entrega a data de devoluo e o valor total da locao.9. O cliente sai do sistema.


23/109

23

Fluxos alternativos:

A1.3. O cliente no possui cadastro.3.1. O cliente deve informar seus dados para cadastro.3.2. O sistema registra o cadastro.3.3. Retorna ao fluxo principal no passo 3.

A2.3. O cliente escolhe selecionar por nome do DVDs (Filme, cantor...)3.1 O sistema fornece uma lista com os nomes dos DVD em ordem alfabtica.3.2 Vai para o passo 6

A3.3. O cliente escolhe selecionar por nome Gnero (Filme, msica, software...)3.1 O sistema fornece uma lista com os gneros dos DVDs em ordem alfabtica.3.2 Vai para o passo 5

A5.5. Um DVD est reservado para outro cliente.5.1. O funcionrio informa que o DVD no est disponvel para locao.5.2. Prossegue a locao do passo 6 sem incluir o DVD reservado.

A7.7. O cliente possui pendncias no cadastro (locao anterior no foi paga).7.1. O cliente paga o seu dbito7.2. O sistema registra a quitao do dbito, eliminando assim a pendncia.7.3. Segue o fluxo normal.

Existem diversas maneiras de representar os fluxos de um caso de uso, apresentamos a seguir

outra maneira de representar:Caso de Uso Emprestar DVDAtores: Cliente e Funcionrio

Fluxo Principal:

1. O cliente entra no sistema2. O sistema solicita nome de usurio e senha3. O cliente fornece o nome e senha4. O sistema valida usurio e senha5. O cliente escolhe os DVD que deseja locar6. O sistema registra cada um dos DVD.7. O sistema finaliza a locao8. O sistema lhe informa a hora aproximada da entrega a data de devoluo e o valor total da locao.9. O cliente sai do sistema.


3.1 O cliente no possui cadastro.3.1.1 O cliente deve informar seus dados para cadastro.3.1.2. O sistema registra o cadastro.3.1.3. Retorna ao fluxo principal no passo 3.

5.2 O cliente escolhe selecionar por nome do DVD (Filme, cantor...)5.2.1 O sistema fornece uma lista com os nomes dos DVD em ordem alfabtica.


24/109

24

5.2.2 Vai para o passo 6

5.3 O cliente escolhe selecionar por nome Gnero (Filme, msica, software...)5.3.1 O sistema fornece uma lista com os gneros dos DVD em ordem alfabtica.5.3.2 Vai para o passo 5

5.1 Um DVD est reservado para outro cliente.5.1.1 O funcionrio informa que o DVD no est disponvel para locao.5.1.2. Prossegue a locao do passo 6 sem incluir o DVD reservado.

7.1 O cliente possui pendncias no cadastro (locao anterior no foi paga).7.1.1 O cliente paga o seu dbito7.1.2. O sistema registra a quitao do dbito, eliminando assim a pendncia.7.1.3. Segue o fluxo normal.

Uma das grandes dvidas dos analistas que trabalham com casos de uso costuma ser decidirexatamente o que pode e/ou deve ser colocado como passo do caso de uso expandido.

De fato, duas pessoas que descrevam o mesmo processo quase sempre usaro uma seqncia depassos diferente. Uma pode fazer constar um passo no qual o funcionrio pergunta o nome do cliente.Outra excluir esse passo e informar que o cliente simplesmente chega ao balco e se identifica.

A pergunta : qual das abordagens est correta? Se ambas esto corretas, ento existemdescries incorretas? As respostas so ambas e sim, respectivamente.

Todo o caso de uso tem passos obrigatrios. Esses passos envolvem informaes que passam dosatores para o sistema e do sistema para os atores, sem as quais o caso de uso no faz sentido ou nopode prosseguir. Esses passos devem constar em todos os casos de uso expandidos, e a falta deles fazcom que o caso de uso esteja incorretamente descrito. Outros passos como perguntar o nome docliente, so opcionais. Eles servem para contextualizar o caso de uso, mas no so fundamentais, poisno passam nenhuma informao para o sistema.

Passos Obrigatrios

Na categoria de passos obrigatrios esto includos todos os passos que indicam de alguma formatroca de informaes entre os atores e o sistema. Logo, um fluxo principal como o da locao de DVD,visto antes, deve conter obrigatoriamente os passos que indicam os momentos nos quais o funcionrioregistra o nome do cliente e a identificao dos DVD. Por que esses passos so obrigatrios? Porque semessas informaes nenhum sistema seria capaz de registrar de forma adequada uma locao, como essasinformaes so importantes devem aparecer nos fluxos.

Em uma descrio de caso de uso, a informao no surge do nada. Ela transmitida dos atorespara o sistema e vice-versa. A ausncia de passos de interao que registrem essa troca de informaodeixa os casos de uso sem sentido. Abaixo veremos um exemplo no qual um caso de uso foi malconstrudo porque uma informao obrigatria foi omitida.

Caso de Uso (mal construdo): Reservar DVDAtor: cliente e funcionrio

1. O cliente entra em contato com o funcionrio da locadora (possivelmente por telefone).2. O cliente informa seu nome.3. O cliente solicita uma reserva.4. O funcionrio confirma a reserva.

A descrio desse caso de uso omite informaes importantes. Esse dilogo no teria sentido nomundo real porque uma reserva de filme necessitaria de mais informaes do que as que foram trocadasentre o cliente e o funcionrio. Como o funcionrio poderia saber o nome do filme se o cliente quemdetm essa informao? O nome do filme uma informao sem a qual o processo de reserva no podeser concludo. Uma verso melhorada poderia ser a descrita abaixo:

Caso de Uso Reservar DVDAtor: cliente e funcionrio


25/109

25

1. O cliente entra em contato com o funcionrio da locadora (possivelmente por telefone).2. O cliente informa seu nome.3. O cliente solicita uma reserva informando o nome do filme.4. O funcionrio confirma a reserva, informando o prazo de validade.

Passos no recomendadosSo os processos internos ao sistema.O caso de uso deve descrever a interao entre o sistema e os atores externos, no o processamentointerno. Esses aspectos sero descritos na fase de projeto.Na descrio dos casos de uso, o analista deve se concentrar em descrever a informao que passada dos usurios para o sistema (por exemplo, o sistema apresenta o valor da compra). Deve-se,portanto omitir quaisquer aspectos sobre o funcionamento interno do sistema. Pode-se dizer que osistema exibe o total da compra, mas no se deve descrever aqui como ele calculou esse total, poisesse um processo interno. Como opo, o analista poder fazer anotaes sobre a forma comodeterminados clculos so feitos (regras de negcio), mas espera-se que tais descries estejam nodocumento de requisitos, e no no caso de uso expandido.

Note que o Caso de Uso no revela sobre como o sistema dever resolver algumas questes difceiscomo calcular preos e impostos. Pode ter certeza esses pontos envolvem regras complexas e clculoscom vrias informaes de diversas tabelas do sistema, porm, os detalhes de como sero resolvidosinternamente o Ator no consegue ver. Nesse ponto do projeto nosso trabalho se limita ao que o sistemadeve fazer (escopo), e no como ele ir fazer (implementao).

Essa regra de escrever somente o que o usurio v importante para agilizar a fase de anlise dosistema e principalmente esta regra que permite derivar os Casos de Teste a partir da descrio, poissabendo o que o sistema deve fazer possvel planejar como testar a funcionalidade independente decomo ficar a implementao.

4.1.2.6.6 Tratamento de Excees em Casos de UsoDepois de descrever o fluxo principal do caso de uso, deve-se imaginar o que poderia dar errado em

cada um dos passos descritos, gerando assim, os fluxos alternativos responsveis pelas excees. Umaexceo no necessariamente um evento que ocorre raramente, mas sim um evento capaz de impedir oprosseguimento do caso de uso se no for tratado.

Por exemplo, quando uma pessoa vai pagar uma conta, ela usa cheque, carto ou dinheiro. Mesmoque apenas 1% das contas sejam recebidas em dinheiro, contra 99% pagas em cheque ou carto, issono trona o pagamento em dinheiro uma exceo, mas apenas uma opo pouco freqente. Porm, o fatode o cliente no ter meios para pagar a conta constitui uma exceo, pois isso impede que o processo sejaconcludo.

A exceo em um processo no necessariamente algo que impede o processo de ser iniciado, masnormalmente algo que impede sua concluso. Por exemplo, o fato de o cliente no ter cadastro vlido noo impediu de colocar os DVD no carrinho, contudo a concluso do caso de uso dependeria de ele ter umaidentificao, o que no ocorreu. Portanto embora o processo tenha iniciado, ele no pde ser concludo.Em geral, condies que impedem um processo de ser iniciado so tratadas como precondies. Elasnunca devem ser testadas durante o processo, pois elas devem ser testadas antes do processo iniciar,caso elas sejam falsas, deve-se iimpedir que o processo inicie.

Observa-se na prtica que a maioria das excees ocorre nos passos correspondentes a eventos dosistema, isso porque quando uma informao passada ao sistema, ele, em muitos casos, realiza certasvalidaes, (o cliente cadastrado? Tem crdito? O nmero mximo de locaes no foi excedido?).Quando uma dessas verificaes falha, ocorre uma exceo.

Cada exceo deve ser tratada por um fluxo alternativo, que corresponde a uma ramificao nofluxo principal. Um tratamento de exceo tem pelo menos quatro elementos:

a) Identificador consiste em duas partes: (1) o nmero da linha do fluxo principal no qual aexceo ocorreu (2) uma letra para identificar a prpria exceo na linha. Por exemplo, na linha1 do fluxo principal poderia haver excees identificadas como 1a, 1b, 1c, etc. Para a linha 2 as

excees seriam 2a, 2b, 2c, etc.


26/109

26

b) Exceo - compe-se de uma frase que explica qual exceo ocorreu, pois em uma mesma linhapodem ocorrer diferentes tipos de excees.

c) Aes corretivas baseiam-se em um fluxo alternativo, ou seja, uma seqncia de aes quedeveriam ser executadas para corrigir a exceo.

d) Finalizao ltima linha do fluxo alternativo que indica se e como o caso de uso retorna aofluxo principal depois das aes corretivas.

Existem 4 formas bsicas para finalizar o tratamento de uma exceo:a) Voltar ao incio do caso de uso, o que no muito comum e nem prtico.b) Voltar ao incio do passo que causou a exceo e execut-lo novamente.c) Depois das aes corretivas, em vez de voltar para o mesmo passo, ir para algum passo posterior.d) Abortar o caso de uso.

Deve-se, no entanto, observar que quando a ao corretiva consiste simplesmente em cancelar ouabortar o caso de uso, em geral, no interessante considerar como exceo.Logo, as excees a serem consideradas no fluxo principal, devem ser sempre situaes especficasdo passo que est sendo executado e no situaes genricas como desistncia do cliente, falta deluz, defeito do sistema de armazenamento de dados, etc. Esse tipo de situao ser tratado nafase de projeto.

* Na descrio do Caso de Uso Emprestar DVD descrito anteriormente podemos definir os fluxosalternativos 3.1, 5.1 e 7.1 como fluxos alternativos contendo excees.

Caso de Uso Emprestar DVDAtores: Cliente e Funcionrio

Fluxo Principal:

1. O cliente entra no sistema2. O sistema solicita nome de usurio e senha3. O cliente fornece o nome e senha4. O sistema valida usurio e senha5. O cliente escolhe os DVD que deseja locar6. O sistema registra cada um dos DVD.

7. O sistema finaliza a locao8. O sistema lhe informa a hora aproximada da entrega a data de devoluo e o valor total da locao.9. O cliente sai do sistema.


5.1 O cliente escolhe selecionar por nome do DVD (Filme, cantor...)5.1.1 O sistema fornece uma lista com os nomes dos DVD em ordem alfabtica.3.1.2 Vai para o passo 6

5.2 O cliente escolhe selecionar por nome Gnero (Filme, msica, software...)5.2.1 O sistema fornece uma lista com os gneros dos DVD em ordem alfabtica.5.2.2 Vai para o passo 5

Fluxos de Excees:

3.1 O cliente no possui cadastro.3.1.1 O cliente deve informar seus dados para cadastro.3.1.2. O sistema registra o cadastro.3.1.3. Retorna ao fluxo principal no passo 3.

5.1 Um DVD est reservado para outro cliente.

5.1.1 O funcionrio informa que o DVD no est disponvel para locao.5.1.2. Prossegue a locao do passo 6 sem incluir o DVD reservado.


27/109

27

7.1 O cliente possui pendncias no cadastro (locao anterior no foi paga).7.1.1 O cliente paga o seu dbito7.1.2. O sistema registra a quitao do dbito, eliminando assim a pendncia.7.1.3. Segue o fluxo normal.

4.1.2.6.7 Diagrama de caso de usoPara iniciarmos a confeco de qualquer diagrama UML, necessrio conhecermos a sua notao, ou seja,a forma como devemos represent-lo e suas semnticas.O diagrama de Caso de Uso tem uma notao bem simples. Embora j tenhamos utilizado algunsexemplos com diagramas de Caso de Uso. Vamos entend-lo melhor agora.

Figura 8 - Diagrama de Caso de UsoFonte: Desenvolvendo Software com UML 2.0 - Ernani Medeiros

1. Este um Stick Man ou Ator.2. Aqui temos a representao de um caso de uso ou use case, em ingls. Ambas as

denominaes so utilizadas por autores nacionais.3. Relao de dependncia significa que Cadastrar Beneficirio depende diretamente da

concluso do Caso de Uso Cadastrar Cliente. Esse comportamento vale para Incluso eExtenso.

4. Incluso de um Caso de Uso em outro Caso de Uso.5. Extenso de um Caso de Uso para com outro Caso de Uso.


28/109

28

Figura 9 - Diagrama de Caso de Uso Emprestar DVD

Variantes do Fluxo PrincipalAdmite-se por princpio, que o fluxo principal seja uma seqncia no ramificada e no aninhadade passos de interao. Entretanto, algumas vezes pode ser til representar o caso de uso de umaforma no to plana.O caso de uso devolver DVD, por exemplo, ter que descrever como o emprstimo pago. Opagamento pode ser de pelo menos trs maneiras: dinheiro, cheque ou carto de crdito.Nenhuma dessas constitui uma exceo, de acordo com o significado estabelecido anteriormente, eassim, so apenas maneiras diferentes de realizar um mesmo processo.H dois modos de tratar esse tipo de situao:1. O primeiro considerar que se trata de trs casos de uso : devolver DVD pagando com

dinheiro, devolver DVD pagando com cheque, devolver DVD pagando com carto,representados na UML com o esteretipo .

2. Outra maneira de representar admitir a possibilidade de variantes como ramificaes dofluxo principal. Pode-se dizer ento que o fluxo principal pode ter trs fluxos variantes.

Representao do caso de uso com variantes:

Caso de Uso Devolver DVD

Atores: Cliente e Funcionrio e GerenteFluxo Principal1. O cliente entrega os DVDs que deseja devolver.2. O funcionrio identifica cada um dos DVDs.3. O funcionrio indica que no h mais DVDs para devolver.4. O sistema informa o valor total a ser pago.5. O cliente seleciona forma do pagamento:

- Dinheiro: Ver variante 5.1.- Boleto: Ver variante 5.2.- Carto: Ver variante 5.3.

6. O funcionrio conclui a devoluo

Variantes5.1: Dinheiro :5.1.1. O cliente entrega a quantia em dinheiro.5.1.2. O funcionrio registra a quantia.5.1.3. O sistema informa o troco.5.1.4. O funcionrio entrega o troco ao cliente

5.2: Boleto: 5.2.1. O sistema gera o boleto.5.2.2. O cliente paga o boleto.

5.3: Carto :5.3.1. O cliente entrega o carto de crdito.5.3.2. O funcionrio envia a informao sobre o carto ao servio de autorizao, bem como o

valor da compra.5.3.3. O Servio de autorizao envia o cdigo de autorizao.


29/109

29

5.3.4. O cliente confirma a autorizao.

4.1.2.6.8 Relacionamento include entre Casos de Uso

Representao com trs casos de uso:

Caso de Uso Devolver DVDAtores: Cliente e Funcionrio

Fluxo Principal1. O cliente entrega os DVD que deseja devolver.2. O funcionrio identifica cada um dos DVD.3. O funcionrio indica que no h mais DVD para devolver.4. O sistema informa o valor total a ser pago.5. O cliente seleciona forma do pagamento:

Devolver DVD pagando com dinheiro Devolver DVD pagando com boleto Devolver DVD pagando com carto

6. O funcionrio conclui a devoluo

Caso de Uso Devolver DVD pagando com dinheiro

1. O cliente entrega a quantia em dinheiro.2. O funcionrio registra a quantia.3. O sistema informa o troco.4. O funcionrio entrega o troco ao cliente

Caso de Uso Devolver DVD pagando com boleto

1. O sistema gera o boleto.2. O cliente paga o boleto.

Caso de Uso Devolver DVD pagando com carto

1. O cliente entrega o carto de crdito.2. O funcionrio envia a informao sobre o carto a operadora de carto, bem como o valor da

compra.3. O Servio de autorizao da operadora de carto envia o cdigo de autorizao.4. O cliente confirma a autorizao.


30/109

30

Figura 10 - Diagrama de Caso de Uso com trs casos de uso inclusos

Outro exemplo do uso de

Caso de Uso Emprestar DVDAtores: Cliente

Fluxo Principal:

1. O cliente entra no sistema2. O sistema solicita nome de usurio e senha3. O cliente fornece o nome e senha4. O sistema valida usurio e senha5. O cliente escolhe os DVD que deseja locar6. O sistema registra cada um dos DVD.7. O sistema finaliza a locao, lhe informa a hora aproximada da entrega a data de devoluo e o valortotal da locao.8. O cliente sai do sistema.

Caso de Uso Reservar DVDAtor: Cliente

Fluxo Principal:

1. O cliente entra no sistema2. O sistema solicita nome de usurio e senha


31/109

31

3. O cliente fornece o nome e senha4. O sistema valida usurio e senha5. O cliente escolhe os DVD que deseja reservar e suas respectivas datas6. O sistema verifica se h disponibilidade dos DVD.7. O sistema finaliza a reserva, informando os ttulos dos DVD e as datas.8. O cliente sai do sistema.

Observando os Casos de Uso Emprestar DVD e Reservar DVD descritos acima, observamos queos passos para validao do cliente (do 1 ao 4) possuem um comportamento exatamente igual. Nessecaso, possvel extrair os passos iguais e criar um novo Caso de Uso separado com um relacionamentoinclude entre eles, ficando assim:

Caso de Uso Validar UsurioAtor: Cliente

Fluxo Principal: 1. O cliente entra no sistema2. O sistema solicita nome de usurio e senha3. O cliente fornece o nome e senha4. O sistema valida usurio e senha

Caso de Uso Emprestar DVDAtor: Cliente

Fluxo Principal:

1. Validar Usurio2. O cliente escolhe os DVD que deseja locar3. O sistema registra cada um dos DVD.4. O sistema finaliza a locao, lhe informa a hora aproximada da entrega a data de devoluo e o valortotal da locao.5. O cliente sai do sistema.

Caso de Uso Reservar DVDAtores: Cliente

Fluxo Principal:

1. Validar Usurio2. O cliente escolhe os DVD que deseja reservar e suas respectivas datas3. O sistema verifica se h disponibilidade dos DVD.

4. O sistema finaliza a reserva, informando os ttulos dos DVD e as datas.5. O cliente sai do sistema.

provvel que voc esteja questionando: Isso no quebrar o objetivo em Casos de Uso menoresou decomposio funcional? Eu respondo que no. A tcnica de extrair um Caso de Uso de dentro deoutro s deve ser aplicada quando visar reutilizao do comportamento que est sendo extrado. Como foidescrito no exemplo, o Caso de Uso Reservar DVD possua um trecho de comportamento que j existiaem Emprestar DVD, por esse motivo o Caso de Uso Validar Usurio foi extrado. Se no existisse

Reservar DVD, o comportamento de Validar Usurio ainda ficaria dentro de Emprestar DVD.Ou ento voc poderia perguntar: Agregaria algum valor para o usurio entregar o Caso de Uso

Validar Usurio isoladamente? Observe melhor o diagrama da figura 11, o Caso de Uso Validar Usurio no est relacionado com nenhum Ator diretamente, assim sendo, ele no pode ser utilizado fora de


32/109

32

Emprestar DVD ou Reservar DVD. Deste modo, ele no pode ser entregue sozinho para o usurio, oescopo no define que um Ator pode utiliz-lo diretamente.

Do mesmo modo, outro conceito que deve ser levado em considerao so as dependncias nomodelo UML. Exploraremos melhor este conceito adiante em - Diagrama de Classes, adiantando, a linhatracejada que liga os Casos de Uso com o relacionamento include significa que o elemento que estlanando a seta depende do elemento que est sendo atingido pela seta. Assim, o Caso de Uso

Emprestar DVD depende de Validar Usurio. No possvel atingir o objetivo do Ator em EmprestarDVD sem Validar Usurio, o mesmo acontece com Reservar DVD.

Figura 11 - Diagrama de Caso de Uso com include Validar usurio

Como j foi citado, o Caso de Uso um importante meio de dividir o sistema em fases entregveis(iteraes) visando disponibilizar o sistema em pedaos incrementais para os usurios, e no tudo no finaldo projeto. Este um modo importante de reduzir o risco. Observar as dependncias de Casos de Uso um instrumento importante para definir o que entra em uma iterao.

IMPORTANTE: Note que em toda descrio do Caso de Uso esto descritas vrias regras decondies para que fluxos alternativos ocorram, mas voc no consegue encontrar em todo o texto umas ocorrncia da palavra se como: se o Ator fizer isso, ento ocorrer aquilo. Todas as alternativasesto em forma de afirmao.

Casos de Uso bem descritos no possuem a palavra se para definir o rumo dentro dos fluxospossveis. Toda ocorrncia da palavra se pode ser substituda por um Fluxo Alternativo para permitir adecomposio de todos os caminhos possveis do Caso de Uso (cenrios). Cenrios so importantes para acriao dos Casos de Teste que validaro a funcionalidade im

apostila-aps-ii 1

Documents