Anlise e Projeto de Sistemas II Sexto semestre 2010/01

Ciclo de vida do desenvolvimento de Software

Prof: MsC. Maricy Caregnato cmaricy@gmail.com

Araputanga 2010/02

1 Introduo Praticamente 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 inclui um computador e um software de controle. A a maioria dos setores esto automatizados. Portanto, produzir e manter o software dentro de custos adequados essencial para o funcionamento da economia nacional e internacional. Durante as dcadas de 60 e 70, o desafio primordial era desenvolver hardware que reduzisse o custo de processamento e armazenamento de dados. Durante a dcada de 80, avanos na microeletrnica resultaram em um aumento do poder computacional e a um custo reduzido. Entretanto, tanto o processo de desenvolvimento como o software produzido ainda deixavam muito a desejar: cronogramas no eram cumpridos, 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 custo do software produzido, atravs da introduo de disciplina no desenvolvimento, o que conhecido como engenharia de software. Nessa parte da apostila veremos o ciclo de vida do desenvolvimento de software. O ciclo de vida de um software descreve as fases pelas quais o software passa desde a sua concepo at sua implantao, de uma maneira geral temos 4 fases que so: Anlise, Projeto, Implementao e Implantao, outras fases podem aparecer entre elas. Na prtica para trabalharmos com os chamados modelos de ciclo de vida, processo, ou ainda metodologia, que trazem 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 o Orientado 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 na Internet. 2 Processo de Software A utilizao de um processo de software tm sido apontada como um fator primordial para o sucesso de empresas 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 para desenvolver 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 atividades operarem corretamente e de acordo com os padres requeridos, o resultado desejado produzido. O resultado desejado um software de alta qualidade e baixo custo. Obviamente, um processo que no aumenta a produo (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

RUP

O 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 a notao UML (Unified Modeling Language) para ilustrar os processos em ao. Utiliza tcnicas e prticas aprovadas comercialmente. um processo considerado pesado e preferencialmente aplicvel a grandes equipes de desenvolvimento e a grandes projetos, porm o fato de ser amplamente customizvel torna possvel que seja adaptado para projetos de qualquer escala, um dos motivos pelos quais adotaremos o RUP nessa disciplina por causa de sua flexibilidade. Caractersticas

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 RUP

O processo unificado prev quatro grandes fases: Concepo, Elaborao, Construo e Transio, como mostra a figura 1. As iteraes ocorrem dentro de cada uma dessas fases. Uma fase pode, portanto, ter uma ou vrias iteraes. No existe um nmero predeterminado de iteraes dentro de uma fase.
2.2.1

Concepo

Na 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. Com essas informaes podemos, agora, informar prazo e preo com mais certeza. Essa fase tambm responsvel pelos documentos de Nomenclatura e Glossrio, abordados nesse captulo e que 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 de concepo, agregando valor a cada iterao que sofre. A fase de elaborao se repete ao longo do desenvolvimento, ou seja, o ciclo de vida do software.
2.2.3

Construo

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

Transio

Quando parte do software sai da verso beta e pode ser avaliado como verso de produo, significa que estamos 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.

Workflows que compe o RUP Requisitos Aqui necessrio obter todos os requisitos necessrios para a formao de casos de uso bem escritos, se um software necessitar se amparar em uma documentao, no presente ou futuro, para ser construdo, essa documentao ser os Casos de Uso. Esse workflow est contido tipicamente nas fases de Concepo, Elaborao e Construo.
2.3 2.3.1 2.3.2

Anlise

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

Projeto

Quando samos de uma viso conceitual da construo de classes e diagrama de sequncia, na abstrao requerida, estamos dentro do workflow de projeto. Esse workflow est contido tipicamente nas fases de Concepo, Elaborao e Construo. Muitas vezes, os dois workflows (anlise e projeto) so mesclados em um nico, pois difcil separar de forma documentada e distinta esss duas fases.
2.3.4

Implementao

Esse workflow encontrado quando estamos codificando e compilando algum cdigo. A prpria construo de uma pgina HTML e sua colocao em funcionamento sinal de que estamos executando esse workflow dentro de alguma fase. A transformao do diagrama de classes em componentes, bem como o atendimento do diagrama de sequncia, mostra que estamos nesse workflow. Ele est contido tipicamente nas fases de Elaborao e Construo.
2.3.5

Testes

A 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 por sua data e condio de teste) servir em anlises posteriores. Ele est contido tipicamente nas fases de Elaborao e Construo.

3 UML A Unified Modeling Language (UML) uma linguagem de modelagem no proprietria de terceira gerao. A UML no uma metodologia de desenvolvimento, o que significa que ela no diz para voc o que fazer primeiro e em seguida ou como projetar seu sistema, mas ela lhe auxilia a visualizar seu desenho e a comunicao entre objetos. Basicamente, a UML permite que desenvolvedores visualizem os produtos de seu trabalho em diagramas padronizados. Junto com uma notao grfica, a UML tambm especifica significados, isto , semntica. uma notao independente de processos, embora o RUP (Rational Unified Process) tenha sido especificamente desenvolvido utilizando a UML. A UML tem origem na compilao das "melhores prticas de engenharia" que provaram ter sucesso na modelagem 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 pretende ser 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 Object Management Group (OMG). O OMG pediu informao acerca de metodologias orientadas a objetos que pudessem criar uma linguagem rigorosa de modelao de software. Muitos lderes da indstria responderam na esperana de ajudar a criar o padro. Modelagem de software a atividade de construir modelos que expliquem as caractersticas ou o comportamento de um software ou de um sistema de software. Na construo do software os modelos podem ser usados na identificao das caractersticas e funcionalidades que o software dever prover (anlise de requisitos), e no planejamento de sua construo. Frequentemente a modelagem de software usa algum tipo de notao grfica e so apoiados pelo uso de Ferramentas CASE. A modelagem de software normalmente implica a construo de modelos grficos que simbolizam os artefatos dos componentes de software utilizados e os seus inter-relacionamentos. Uma forma comum de modelagem de programas procedurais (no orientados a objeto) atravs de fluxogramas, enquanto que a modelagem de programas orientados a objeto normalmente usam a linguagem grfica UML. 4

Os esforos para a criao da UML tiveram incio em outubro de 1994, quando Rumbaugh se juntou a Booch na Rational. Com o objetivo de unificar os mtodos Booch e OMT, decorrido um ano de trabalho, foi lanado, em outubro de 1995, o esboo da verso 0.8 do Unified Process - Processo Unificado (como era conhecido). Nesta mesma poca, Jacobson se associou Rational e o escopo do projeto da UML foi expandido para incorporar o mtodo 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 pode submeter um comentrio ou acrscimo ao que j existe na especificao da UML, bastando ser membro da OMG. 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
Atividades Caso de Uso Classe Objeto Sequncia Colaborao Estado --------Componentes Implantao -------------------------

UML 2.0
Atividades Caso de Uso Classe Objeto Sequncia Comunicao Estado Pacotes Componentes Implantao Interao Timing Composite structure diagram Tabela 1 - Comparao dos diagramas da UML 2.0 com verses anteriores Fonte : 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
4.1

Ciclo de vida do Desenvolvimento de Software seguindo o RUP

Concepo Requisitos

4.1.1

Os 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, por exemplo, 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 usurio Declaraes em linguagem natural mais diagramas de servios que o sistema fornece e suas restries operacionais. Escritos para os clientes. Deve descrever requisitos funcionais e no funcionais, de tal modo que sejam compreensveis pelos usurios de sistema que no tm conhecimento tcnico detalhado. Requisitos de usurio so definidos usando uma linguagem simples, tabelas e diagramas quando estes podem ser compreendidos por todos os usurios.

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

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

Leitores de requisitos

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

4.1.1.1.3 Requisitos de domnio Requisitos 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 ser realizados. 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 no padro Z39.50. Devido s restries de direitos autorais, alguns documentos devem ser excludos imediatamente na chegada. Dependendo dos requisitos de usurio, esses documentos sero impressos localmente no servidor de sistema para serem encaminhados manualmente para o usurio ou direcionados para uma impressora de rede. 4.1.1.2 Categorias de requisitos Os requisitos podem ser classificados em duas grandes categorias: 4.1.1.2.1 Requisitos funcionais Declaraes de servios que o sistema deve fornecer, como o sistema deve reagir a entradas especficas e como o 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 um subconjunto a partir dele. O sistema deve fornecer telas apropriadas para o usurio ler os documentos no repositrio de documentos. Para todo pedido deve ser alocado um identificador nico (ORDER_ID) no qual o usurio deve ser capaz de copiar para a rea de armazenamento permanente da sua conta. 4.1.1.2.2 Requisitos no funcionais Estes definem propriedades e restries de sistema, por exemplo, confiabilidade, tempo de resposta e requisitos de 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 de programao ou mtodo de desenvolvimento. . 6

4.1.1.2.3 Classificaes de requisitos no funcionais

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

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

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

4.1.1.2.4 Medidas de requisitos

Tabela 3 - Mtricas para especificar requisitos no funcionais Fonte: 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 Requisitos

Ainda em relao aos requisitos no funcionais, existem aqueles diretamente associados a uma funo e outros que so gerais para o sistema. Normalmente h duas tabelas, uma que relacione os requisitos funcionais 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 de desenvolvimento Uma 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. 8

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, bem como a data do emprstimo e valor previsto para pagamento na devoluo. Requisitos No Funcionais Nome Restrio Categoria Desejvel Permanente NF1.1 Controle de A funo s pode ser acessada por usurio com perfil Segurana ( ) (x) Acesso de operador ou superior. NF1.2 Identificao de Os DVDs devem ser identificadas por um cdigo de Interface ( ) (x) DVDs barras NF1.3 Identificao do O cliente dever ser identificado a partir de seu nome Interface ( ) ( ) cliente NF1.4 Tempo de O tempo para registro de cada DVDs deve ser inferior Performance (x) ( ) registro a um segundo. NF1.5 Janela nica Todas as funes relacionadas a emprstimos devem Interface (x) (x) ser efetuadas em uma nica janela ... ... ... ... ...

F2 Calcular descontos Oculto ( x ) Descrio: O sistema deve calcular descontos nos emprstimos em funo da poltica da empresa. Requisitos No Funcionais Nome Restrio Categoria Desejvel NF2.1 Desconto de fim Nos fins de semana, usurios que levam 4 DVDs Especificao ( ) de semana pagam apenas 3. ... ... ... ...

Permanente ( ) ...

Tabela 4 - RF e RNF Fonte: 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 foram apresentadas na tabela 4 e 5, porm existem muitas outras. Algumas sugestes de categorias dos requisitos no funcionais e sua descrio sero mostradas abaixo: Usabilidade: quais fatores humanos esto envolvidos no sistema? Que tipo de ajuda o sistema vai prover? Quais so as formas de documentao ou manuais disponveis? Como esses manuais sero produzidos? Que tipo de informao eles contero? Seria interessante definir esses tpicos na fase de concepo, visto que o contrato com o cliente deveria especificar muitas dessas questes. Confiabilidade: que tipo de tratamento de falhas o sistema ter? O analista no obrigado a produzir um sistema totalmente tolerante a falhas, mas deve estabelecer que tipo de falhas o sistema ser capaz de gerenciar: falta de energia, falha de comunicao, falha na mdia de gravao, etc. No podemos confundir falha com erro de programao, pois erros de programao so elementos que nenhum software deveria conter. As falhas so situaes anormais 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-se estabelecer, por exemplo, como requisito de eficincia, que nenhuma consulta base de dados de clientes vai demorar mais de cinco segundos. Note que na fase de concepo no definimos como o sistema far para cumprir o requisito, apenas dizemos que de alguma forma ele ter de ser cumprido no projeto. Cabe ao projetista e ao programador garantir que o requisito seja satisfeito. Se o analista por algum motivo conclui que o requisito no pode ser cumprido, ento o requisito passa a ser um risco do sistema e eventualmente necessitar de um estudo ainda mais aprofundado na fase de concepo, para verificar a possibilidade de sua realizao. Configurabilidade: o que pode ser configurado no sistema? Devemos definir os elementos que 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. 9

Segurana: quais so os tipos de usurios e que funes cada um pode executar? Sugere-se definir os perfis de usurios como um requisito suplementar e adicionar um requisito nofuncional de controle de acesso a todos os requisitos funcionais evidentes, para indicar como o acesso s funes de sistema controlado. Implementao: qual linguagem dever ser utilizada? Por que motivo? Que bibliotecas estaro 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 para qual o software est sendo desenvolvido. 4.1.1.3 Levantamento de requisitos
O incio para toda a atividade de desenvolvimento de software o levantamento de requisitos, sendo esta atividade repetida em todas as demais etapas da engenharia de requisitos. Sommerville (2007) prope um processo genrico de levantamento e anlise que contm as seguintes atividades: 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 essa atividade; Classificao: Essa atividade considera o conjunto no estruturado dos requisitos e os organiza em grupos coerentes; Resoluo de conflitos: Quando mltiplos stakeholders esto envolvidos, os requisitos apresentaro conflitos. Essa atividade tem por objetivo solucionar esses conflitos; Definio das prioridades: Em qualquer conjunto de requisitos, alguns sero mais importantes do que outros. Esse estgio envolve interao com os stakeholders para a definio dos requisitos mais importantes; Verificao de requisitos: Os requisitos so verificados para descobrir se esto completos e consistentes e 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 atividade para 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 encontradas O 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 o atendimento recebido em sistemas de informao. 10

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 para extrair 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 sistema no sabe o que quer que o sistema faa ou sabe e no consegue transmitir para o analista; requisitos identificados, mas que no so realistas e no identificam os requisitos similares informados por pessoas diferentes. Um stakeholder errado afetar em perda de tempo e dinheiro para ambas as partes envolvidas no desenvolvimento do sistema. Identifica-se um levantamento de requisitos adequado atravs da boa definio do projeto, da efetividade do projeto, de informaes necessrias a um perfeito diagnstico e de solues inteligentes. Quanto ao levantamento de requisitos inadequado, o resultado um diagnstico pobre com concluses comprometidas, no identificao das causas dos problemas, custos elevados, prazos vencidos ou comprometedores, omisso de processos fundamentais e descrditos.

4.1.1.5 Tcnicas de Levantamento de Requisitos As tcnicas de levantamento de requisitos tm por objetivo superar as dificuldades relativas a esta fase. Todas as tcnicas possuem um conceito prprio e suas respectivas vantagens e desvantagens, que podem ser utilizadas 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 vista Para qualquer sistema, de tamanho mdio ou grande, normalmente h diferentes tipos de usurio final. Muitos stakeholders tm algum tipo de interesse nos requisitos do sistema. Por esse motivo, mesmo para um sistema relativamente simples, existem muitos pontos de vista diferentes que devem ser considerados. Os diferentes pontos de vista a respeito de um problema vem o problema de modos diferentes. Contudo, suas perspectivas no so inteiramente independentes, mas em geral apresentam alguma duplicidade, de modo que apresentam requisitos comuns. As abordagens orientadas a ponto de vista, na engenharia de requisitos, reconhecem esses diferentes pontos de vista e os utilizam para estruturar e organizar o processo de levantamento e os prprios requisitos. Uma importante capacidade da anlise orientada a pontos de vista que ela reconhece a existncia de vrias perspectivas e oferece um framework para descobrir conflitos nos requisitos propostos por diferentes stakeholders. O mtodo VORD (view point-oriented requirements definition definio de requisitos orientada a ponto de vista) foi projetado como um framework orientado a servio para o levantamento e anlise de requisitos. A primeira etapa da anlise de ponto de vista identificar os possveis pontos de vista. Nessa etapa os analistas se renem com os stakeholders e utilizam a abordagem de brainstorming para identificar os servios em potencial e as entidades que interagem com o sistema. A segunda etapa a estruturao de pontos de vista, que envolve agrupar pontos de vista relacionados, segundo uma hierarquia. Servios comuns esto localizados nos nveis mais altos da hierarquia e herdados por pontos de vista de nvel inferior. A etapa de documentao do ponto de vista tem por objetivo refinar a descrio dos pontos de vista e servios identificados. O mapeamento de sistema conforme ponto de vista envolve identificar objetos em um projeto orientado 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 VORD Fonte: Engenharia de Software - SOMMERVILLE, 2007

4.1.1.5.2 Etnografia A etnografia uma tcnica de observao que pode ser utilizada para compreender os requisitos sociais e organizacionais, ou seja, entender a poltica organizacional bem como a cultura de trabalho com objetivo de familiarizar-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. 11

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 os processos 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 gerncias apropriadas para executar as observaes; obter os nomes e funes das pessoas chave que esto envolvidas 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 especfico que est sendo observado; e acumular informaes estatsticas a respeito das tarefas, como: freqncia que 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 o resultado 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 a erros em suas observaes. Mas em geral a tcnica de observao muito til e freqentemente usada para complementar descobertas obtidas por outras tcnicas.

4.1.1.5.3 Workshops Trata-se de uma tcnica de elicitao em grupo usada em uma reunio estruturada. Devem fazer parte do grupo uma equipe de analistas e uma seleo dos stakeholders que melhor representam a organizao e o contexto 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 o objetivo de acionar o trabalho em equipe. H um facilitador neutro cujo papel conduzir a workshop e promover a discusso entre os vrios mediadores. As tomadas de deciso so baseadas em processos bem definidos 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 documentaes que 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 e observador; a convocao deve possuir dia, hora, local, horrio de incio e de trmino; assunto a ser discutido e a documentao do seminrio. 4.1.1.5.4 Prototipagem Prottipo tem por objetivo explorar aspectos crticos dos requisitos de um produto, implementando de forma rpida um pequeno subconjunto de funcionalidades deste produto. O prottipo indicado para estudar as alternativas de interface do usurio; problemas de comunicao com outros produtos; e a viabilidade de atendimento 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 j verificou 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 de todos os interessados no projeto, a focalizao em reas menos compreendidas e a rapidez na construo. 4.1.1.5.5 Entrevistas A entrevista uma das tcnicas tradicionais mais simples de utilizar e que produz bons resultados na fase inicial de 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 fique longa, 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 a entrevista para fazer uso eficiente do tempo, utilizar ferramentas automatizadas que sejam adequadas, tentar descobrir 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 bem contextualizado e ter mais produtividade nos assuntos a serem discutidos na entrevista. 12

 importante determinar um escopo relativamente limitado, focalizando uma pequena parte do sistema para que a reunio no se estenda por mais de uma hora. O usurio tem dificuldade de concentrao em reunies muito 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 necessidade do usurio, que o usurio no mudou de opinio e que o usurio entende a notao ou representao grfica de suas informaes. A atitude do analista em relao entrevista determinar seu fracasso ou sucesso. Uma entrevista no uma competio, deve-se evitar o uso excessivo de termos tcnicos e no conduzir a entrevista em uma tentativa de persuaso. O modo como o analista fala no deve ser muito alto, nem muito baixo, tampouco indiretamente, ou seja, utilizar os termos: ele disse isso ou aquilo na reunio para o outro entrevistado. O modo melhor para agir seria, por exemplo, dizer: O Joo v a soluo para o projeto dessa forma. E o senhor Andr, qual a sua opinio? 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 necessrias ao 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. Neste caso, o analista deve utilizar as suas prprias palavras em lugar das do entrevistado e solicitar ao entrevistado confirmao do que foi dito.

4.1.1.5.6 Questionrios O uso de questionrio indicado, por exemplo, quando h diversos grupos de usurios que podem estar em diversos locais diferentes do pas. Neste caso, elaboram-se pesquisas especficas de acompanhamento com usurios selecionados, que a contribuio em potencial parea mais importante, pois no seria prtico entrevistar 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 a minimizar o tempo gasto em sua resposta. Na fase de preparao do questionrio deve ser indicado o tipo de informao que se deseja obter. Assim que os requisitos forem definidos o analista deve elaborar o questionrio com questes de forma simples, clara e concisa, deixar espao suficiente para as repostas que forem descritivas e agrupar as questes de tpicos especficos em um conjunto com um ttulo especial. O questionrio deve ser acompanhado por uma carta explicativa, 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. A distribuio deve ocorrer junto com instrues detalhadas sobre como preench-lo e ser indicado claramente o prazo para evoluo do questionrio. Ao analisar as respostas dos participantes feito uma consolidao das informaes fornecidas no questionrio, documentando as principais descobertas e enviando uma cpia com estas informaes para o participante como forma de considerao pelo tempo dedicado a pesquisa. 4.1.1.5.7 Brainstorming Brainstorming uma tcnica para gerao de idias. Ela consiste em uma ou vrias reunies que permitem que as 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 contribuies diretas que possam dar durante a sesso. A presena de pessoas bem informadas, vindas de diferentes grupos garantir uma boa representao; Explicar a tcnica e as regras a serem seguidas: O lder da sesso explica os conceitos bsicos de brainstorming e as regras a serem seguidas durante a sesso; Produzir uma boa quantidade de idias: Os participantes geram tantas idias quantas forem exigidas pelos tpicos que esto sendo o objeto do brainstorming. Os participantes so convidados, um por 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 elas freqentemente estimulam os participantes, o que pode levar a solues criativas para o problema. O nmero de idias geradas deve ser bem grande, pois quanto mais idias forem propostas, maior ser a chance de aparecerem boas idias. Os participantes tambm devem ser encorajados a combinar ou enriquecer as idias de outros 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. 13

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

4.1.1.5.8 JAD JAD (Joint Application Design) uma tcnica para promover cooperao, entendimento e trabalho em grupo entre os usurios desenvolvedores. O JAD facilita a criao de uma viso compartilhada do que o produto de software deve ser. Atravs da sua utilizao 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 do produto. A tcnica JAD tem quatro princpios bsicos: 1. Dinmica de grupo: so realizadas reunies com um lder experiente, analista, usurios e gerentes, para despertar 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 bem definidas. Possibilita assim, a garantia de uma anlise completa reduzindo as chances de falhas ou lacunas no projeto e cada nvel de detalhe recebe a devida ateno; 4. Utilizao de documentao padro: preenchida e assinada por todos os participantes. Este documento garante 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 especificar os 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 preparao para a sesso, ou seja, organizar a equipe, adaptar o processo JAD ao produto a ser construdo e preparar o material. Na fase de sesso realizado um ou mais encontros estruturados, envolvendo desenvolvedores e usurios onde os requisitos so desenvolvidos e documentados. A fase de finalizao tem por objetivo converter a 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 ser competente, com bom relacionamento pessoal e qualidades gerenciais de liderana; Engenheiro de requisitos: o participante diretamente responsvel pela produo dos documentos de sada das sesses JAD. Deve ser um desenvolvedor experiente para entender as questes tcnicas e detalhes que so discutidos durante as sesses e ter habilidade de organizar idias e express-las com clareza; Executor: o responsvel pelo produto sendo construdo. Tem que fornecer aos participantes uma viso geral dos pontos estratgicos do produto de software a ser construdo e tomar as decises executivas, 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-chave dentro 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 as capacidades dos produtos de software. Seu papel ajudar os usurios a entender o que razovel ou possvel 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 e estimativa 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 e complexo podem ser usadas mltiplas sesses JAD para acelerar a definio dos requisitos do sistema.

14

Tcnicas tradicionais Tabela 5 - Grupos de tcnicas para levantamento de requisitos Fonte: Revista Engenharia de Software Ano: 01 Edio 02

4.1.1.5.9 Anlise de Documentos A 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 produzido uma documentao, que seria ento atualizada por todos os projetos subseqentes. Nesse caso, a equipe de projeto pode comear revendo a documentao e examinando o prprio sistema. Infelizmente, a maioria dos sistemas no bem documentada porque as equipes de projeto deixam de documentar seus projetos ao longo do caminho, e quando terminam no h mais tempo para retornar e fazer a documentao. Portanto, pode no haver informaes atualizadas sobre alteraes recentes do sistema. Entretanto, h muitos documentos teis existentes nas empresas: relatrios em papel, memorandos, manuais de poltica da empresa, manuais de treinamento de usurios, diagramas da empresa e formulrios. Mas esses documentos (formulrios, relatrios, manuais, diagramas) contam a parte histrica. Eles representam o sistema formal que a empresa usa. Com muita freqncia, o sistema informal ou real difere do sistema formal, e essas diferenas, do fortes indicaes de quais necessidades precisam ser alteradas. Por exemplo, formulrios e relatrios que nunca so usados devero ser eliminados. Da mesma maneira, quadros ou perguntas em formulrios que nunca so preenchidos (ou so usados para outras finalidades) deveriam ser repensados. A indicao mais incontestvel de que o sistema precisa ser mudado quando os usurios criam seus prprios formulrios ou acrescentam informaes adicionais aos existentes. Portanto, til revisar tanto os formulrios em branco quanto os preenchidos para identificar essas divergncias. Da mesma maneira, quando os usurios acessam diversos relatrios para satisfazer suas necessidades de informaes um sinal claro de que novas informaes ou novos formatos de informaes so necessrios. O cliente cometeu um erro. Esse campo deveria se intitular Nome do Proprietrio, para evitar confuso. O pessoal da clnica teve que acrescentar informaes adicionais sobre o tipo de animal e a sua data de nascimento. Essa informao deve ser adicionada ao novo

15

Clinica Veterinria Central

Ficha 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__________

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

O cliente no inclui o cdigo de rea no nmero do telefone. Isso deve ser esclarecido ao cliente.

4.1.1.6 Documento de Requisitos O 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, definem padres de documentos de requisitos. O padro mais amplamente conhecido o IEEE/ANSI 8301988, que sugere a seguinte estrutura para os documentos de requisitos: 1. Introduo 1.1. Propsito 1.2. Escopo 1.3. Definies, acrnimos e abreviaturas 1.4. Referncias 1.5. Viso geral do restante do documento 2. Descrio Geral 2.1. Perspectiva do produto 2.2. Funo do produto 2.3. Caractersticas dos usurios 2.4. Restries gerais 2.5. Suposies e dependncias 3. Requisitos Especficos Abrangem requisites funcionais, no funcionais e de interface. 4. Apndices 5. ndice Embora o padro IEEE no seja o ideal, ele contm uma grande quantidade de boas recomendaes de como redigir requisitos e evitar problemas. Ele muito geral para funcionar como um padro em uma organizao, porm pode ser configurado e adaptado para definir um padro dirigido s necessidades de determinada organizao, como demonstrado nos exemplos nessa apostila.

16

4.1.2

Casos de Uso O 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, de entidade externa, por exemplo, um banco. Um ator pode ser algo como um roteador, ele realiza uma atividade 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 na abordagem, mas para todo e qualquer efeito bom sempre ter em mente que um Ator um PAPEL DESEMPENHADO POR ALGUMA COISA EXTERNA ao sistema (no necessariamente uma pessoa). At mesmo 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 respeito dos Atores: Componentes internos do sistema no so Atores: comum o analista imaginar que porque sistemas externos podem ser atores, o banco de dados da aplicao que est sendo desenvolvida deve ser um ator tambm, mas isso errado, lembre que Ator um papel de responsabilidade externa ao sistema. O que deve funcionar dentro da responsabilidade do sistema no 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 o software pressupe que existem e cumpriro seu papel. Ento, so como os componentes do funcionamento interno do software (como o banco de dados da aplicao) e assim sendo, no so Atores. 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 controles industriais podem ter alguns sensores que indicam algum tipo de problema na linha de produo e disparam 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. Outro hardware que pode ser um Ator seria a catraca do controle de ponto (entrada e sada de funcionrios) 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 o Caso 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 realizao dessa 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) b) c) d) e) Quem usa o sistema? Quem mantm ou configura o sistema? Quais outros sistemas de informao utilizam ou so utilizados pelo sistema? Quem busca informao no sistema? Quem fornece informaes para o sistema?

17

Deve-se ento identificar os principais processos de negcio iniciados ou com participao desses atores. 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 desse diagrama est no fato de se poder associar a ele, caso se utilize uma ferramenta CASE, um conjunto de outros 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 Casos de Uso bem modelados e detalhados, talvez por no entender direito por que e para qu definir bonequinhos 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 observar rapidamente as funcionalidades envolvidas no sistema, os usurios envolvidos e integraes com sistemas externos. O propsito maior do Caso de Uso fornecer uma descrio do comportamento do sistema do ponto de vista do usurio. O Caso de Uso uma adio muito importante para a abordagem da Anlise Orientada a Objetos e para 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 de Uso (destacando o timo livro de Alistair Cockburn Writing Effective Use Cases). Modelando ou escrevendo, 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 uma maneira simples. Se no diagrama aparece um Caso de uso chamado Plantar Batata, os usurios no podero dizer que plantar couve est no escopo do sistema. Organizar e dividir o trabalho: O Caso de Uso uma importante unidade de organizao 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 Caso de Uso divide o trabalho da equipe entre as pessoas, fora isso, comum dizer que o Caso de Uso est em Anlise, em Programao ou em Teste. Casos de Uso tambm so entregues separadamente 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 segunda iterao 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 - Use Case Point (Pontos por Caso de Uso) que consiste em classificar os Casos de Uso em nvel de complexidade e somando todos os Casos de Uso do projeto (e mais alguns fatores) voc consegue estimar o esforo do projeto em horas. Alm do UCP, podem ser aplicadas as tcnicas de Pontos de Funo (Function Points) que so mais padronizadas e completas. Direcionar os testes: Os testes do sistema (essencialmente os funcionais que so os mais importantes) so derivados do Caso de Uso. Essa caracterstica uma das mais importantes e geralmente desprezada, pois com Casos de Uso, os testes so planejados no incio do projeto e no no fim, diminuindo os riscos. A partir dos Casos de Uso, Casos de Teste so criados para validar 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 para candidatos 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, mas refere-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 tcnica vista anteriormente que se julgue adequada. A observao somente possvel em casos onde a atividade repetitiva, realizada por um operador ou uma mquina. A entrevista possvel entre pessoas. Essa ltima a mais comum. Assim, precisamos de analista de negcio com boa capacidade de comunicao interpessoal, no confunda com pessoa que vive contando piadas, inconvenientes na maioria das vezes. HCIs significa Habilidade de Comunicao Interpessoal.

18

Com o aprimoramento das HCIs podemos aperfeioar a capacidade de ouvir (ato de entender o que algum 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 consciente captou e pode reproduzir. Alm da capacidade de comunicao interpessoal, o analista de negcio deve conseguir escrever o que ouviu, essa tarefa no fcil, exige habilidade e experincia. Quando iniciar uma extrao de caso de uso, procure saber detalhes do entrevistado. Se ele gosta muito de futebol, leia todo o caderno de esporte do jornal do dia, a fim de se inteirar dos lances mais importantes do campeonato e seu time. Aqui, a cultura geral , tambm, fator importante. Se entrar na sala do entrevistado e ver um pster com a foto de Oscar Schmidt, e iniciar a conversa com: esse jogador de vlei muito bom, no ? Muito provavelmente, ele reduzir sua disposio de conversar contigo em 30% ou 40%. Para reverter esse quadro, 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 Uso Fonte: Desenvolvendo Software com UML 2.0 - Ernani Medeiros

Autores e ferramentas de modelagem UML sugerem outras sees, porm muitas vezes no produtivo porque, 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 do comprometimento dele. 19

4.1.2.6.1 Nome Dar um nome ao Caso de Uso usando um verbo no infinitivo facilitar a sua classificao. Podemos tambm informar um nome interno para o Caso de Uso, como UC03245. Nome interno a forma como a outra aplicao vai se referir a esse caso de uso. 4.1.2.6.2 Descrio Uma breve descrio apenas relata qual o assunto que aquele Caso de Uso trata. Isso facilitar a busca de Caso de Uso por uma indexao XML, por exemplo. 4.1.2.6.3 Pr-condio e Ps-condies Pr-condio qualquer ao ou reao de um subsistema ou ator que possibilite a esse Caso de Uso ter incio. Relate aqui o que provoca o caso de uso. Pode inclusive, ser um conjunto de aes ou reaes. So restries para um Caso de Uso iniciar. Esses dois elementos demonstram restries para um Caso de Uso iniciar e garantias mnimas alcanadas 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 confunda com o evento que inicia o Caso de Uso. A precondio mais comum nos sistemas "O usurio deve estar logado". Vamos imaginar que a arquitetura da nossa aplicao de pedidos seja integrada com a autenticao do domnio da rede, nosso Caso de Uso "Consultar Pedido" ficaria assim: Caso de Uso: Consultar Pedido Ator: 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. Fazemos essa observao, pois muito comum achar alguns escritos "bvios" nas precondies, veja alguns exemplos: 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. Se a nossa aplicao de pedidos no fosse integrada com o login da rede possivelmente teramos um Caso de Uso "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 Pedido Ator: 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] 20

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. As ps-condies so importantes, pois mostram as garantias mnimas que um Caso de Uso deve oferecer.

4.1.2.6.4 Representao doa Atores Os atores envolvidos so separados por vrgula, caso uma busca seja necessria, esse formato trar facilidade, alm de permitir a visualizao de quais atores so responsveis por quais aes. Sempre o entrevistado 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 da anlise de requisitos. Quando se est expandindo um caso de uso preciso proceder a um exame detalhado do processo de negcio. Deve-se descrever o caso de uso passo a passo: como ele ocorre, como a interao entre os usurios e o sistema. Essa descrio passo a passo interessante por no ser estruturada com desvios, a princpio. Ela se baseia em uma seqncia default, ou fluxo principal, na qual se descreve o que acontece quando tudo d certo na interao. Esse fluxo tambm chamado de caminho feliz, pois nele no necessrio dizer o que acontece quando ocorrem excees. Depois de descrever o fluxo principal, passa-se a uma atividade que corresponde a uma das grandes contribuies do caso de uso para descrever a interao entre usurios e sistemas: analisa-se de forma crtica cada passo do caso de uso e procura-se verificar o que poderia dar errado. A partir da identificao de uma possvel exceo, deve-se construir uma descrio de procedimentos para contornar o problema. O caso de uso passa a possuir as chamadas seqncias alternativas (fluxos). Veremos outros 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 descrio do 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 ao desenho. a descrio do Caso de Uso que importante, ela que permite os benefcios j citados, e no o desenho. O desenho serve mais para organizar os Casos de Uso e representar graficamente (que mais amigvel do que o texto) as funcionalidades do sistema. CASO DE USO = DIAGRAMA + DESCRIO Como 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 exemplos claros. A UML no define o modo como uma descrio deve ser descrita. A UML se limita apenas forma de 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 como o Sistema responder a esta ao. A descrio vai ento evoluindo, entre aes do Ator e as respostas do Sistema, 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 Caso de Uso como um programa e tratar a sua descrio como um passo a passo sobre as tarefas internas do sistema. 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: nesse momento 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 selecionar produtos, escolher forma de pagamento, calcular descontos, escolher forma de entrega, porm, tudo isso so 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 essa proliferao de Casos de Uso no sistema perguntar a si mesmo ao criar um Caso de Uso: 21

- Se eu entregar esse Caso de Uso sozinho para os usurios do sistema resolveria algum problema deles? 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 Uso chamado Escolher Forma de Pagamento e entregar ele sozinho para os usurios teria algum valor? Claro que no. Pode ter certeza que os usurios diriam que no serve pra nada fora da funcionalidade Emitir Pedido. IMPORTANTE: Na descrio do Caso de Uso a resposta do sistema deve se limitar somente ao que o Ator 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: O cliente 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 os dados de: nome, sobrenome, logradouro, complemento, CEP, cidade, estado, telefone residencial e comercial, 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 nmero 2. 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 houver problemas em seu cadastro e se os DVDs no estiverem reservados, ele pode solicit-los, ciente do prazo de 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 objetivo da 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 DVD Atores: Cliente e Funcionrio Fluxo Principal: 1. 2. 3. 4. 5. 6. 7. 8. 9. O O O O O O O O O cliente entra no sistema sistema solicita nome de usurio e senha cliente fornece o nome e senha [A1] sistema valida usurio e senha cliente escolhe os DVDs que deseja locar [A2] [A3] [A4] sistema registra cada um dos DVDs. sistema finaliza a locao [A7] sistema lhe informa a hora aproximada da entrega a data de devoluo e o valor total da locao. cliente sai do sistema.

22

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 dbito 7.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 DVD Atores: Cliente e Funcionrio Fluxo Principal: 1. 2. 3. 4. 5. 6. 7. 8. 9. O O O O O O O O O cliente entra no sistema sistema solicita nome de usurio e senha cliente fornece o nome e senha sistema valida usurio e senha cliente escolhe os DVD que deseja locar sistema registra cada um dos DVD. sistema finaliza a locao sistema lhe informa a hora aproximada da entrega a data de devoluo e o valor total da locao. cliente sai do sistema.

Fluxos alternativos: 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. 23

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 dbito 7.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 decidir exatamente 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 de passos 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 existem descries incorretas? As respostas so ambas e sim, respectivamente. Todo o caso de uso tem passos obrigatrios. Esses passos envolvem informaes que passam dos atores para o sistema e do sistema para os atores, sem as quais o caso de uso no faz sentido ou no pode prosseguir. Esses passos devem constar em todos os casos de uso expandidos, e a falta deles faz com que o caso de uso esteja incorretamente descrito. Outros passos como perguntar o nome do cliente, so opcionais. Eles servem para contextualizar o caso de uso, mas no so fundamentais, pois no passam nenhuma informao para o sistema. Passos Obrigatrios Na categoria de passos obrigatrios esto includos todos os passos que indicam de alguma forma troca 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 funcionrio registra o nome do cliente e a identificao dos DVD. Por que esses passos so obrigatrios? Porque sem essas informaes nenhum sistema seria capaz de registrar de forma adequada uma locao, como essas informaes so importantes devem aparecer nos fluxos. Em uma descrio de caso de uso, a informao no surge do nada. Ela transmitida dos atores para o sistema e vice-versa. A ausncia de passos de interao que registrem essa troca de informao deixa os casos de uso sem sentido. Abaixo veremos um exemplo no qual um caso de uso foi mal construdo porque uma informao obrigatria foi omitida. Caso de Uso (mal construdo): Reservar DVD Ator: cliente e funcionrio 1. 2. 3. 4. O O O O cliente entra em contato com o funcionrio da locadora (possivelmente por telefone). cliente informa seu nome. cliente solicita uma reserva. funcionrio confirma a reserva.

A descrio desse caso de uso omite informaes importantes. Esse dilogo no teria sentido no mundo real porque uma reserva de filme necessitaria de mais informaes do que as que foram trocadas entre o cliente e o funcionrio. Como o funcionrio poderia saber o nome do filme se o cliente quem detm essa informao? O nome do filme uma informao sem a qual o processo de reserva no pode ser concludo. Uma verso melhorada poderia ser a descrita abaixo: Caso de Uso Reservar DVD Ator: cliente e funcionrio 24

1. 2. 3. 4.

O O O O

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

Passos no recomendados So os processos internos ao sistema. O caso de uso deve descrever a interao entre o sistema e os atores externos, no o processamento interno. 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 o sistema exibe o total da compra, mas no se deve descrever aqui como ele calculou esse total, pois esse um processo interno. Como opo, o analista poder fazer anotaes sobre a forma como determinados clculos so feitos (regras de negcio), mas espera-se que tais descries estejam no documento 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 difceis como calcular preos e impostos. Pode ter certeza esses pontos envolvem regras complexas e clculos com vrias informaes de diversas tabelas do sistema, porm, os detalhes de como sero resolvidos internamente o Ator no consegue ver. Nesse ponto do projeto nosso trabalho se limita ao que o sistema deve 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 do sistema e principalmente esta regra que permite derivar os Casos de Teste a partir da descrio, pois sabendo o que o sistema deve fazer possvel planejar como testar a funcionalidade independente de como ficar a implementao. 4.1.2.6.6 Tratamento de Excees em Casos de Uso Depois 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. Uma exceo no necessariamente um evento que ocorre raramente, mas sim um evento capaz de impedir o prosseguimento do caso de uso se no for tratado. Por exemplo, quando uma pessoa vai pagar uma conta, ela usa cheque, carto ou dinheiro. Mesmo que apenas 1% das contas sejam recebidas em dinheiro, contra 99% pagas em cheque ou carto, isso no trona o pagamento em dinheiro uma exceo, mas apenas uma opo pouco freqente. Porm, o fato de o cliente no ter meios para pagar a conta constitui uma exceo, pois isso impede que o processo seja concludo. A exceo em um processo no necessariamente algo que impede o processo de ser iniciado, mas normalmente algo que impede sua concluso. Por exemplo, o fato de o cliente no ter cadastro vlido no o impediu de colocar os DVD no carrinho, contudo a concluso do caso de uso dependeria de ele ter uma identificao, 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. Elas nunca 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 do sistema, isso porque quando uma informao passada ao sistema, ele, em muitos casos, realiza certas validaes, (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 no fluxo 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 a exceo ocorreu (2) uma letra para identificar a prpria exceo na linha. Por exemplo, na linha 1 do fluxo principal poderia haver excees identificadas como 1a, 1b, 1c, etc. Para a linha 2 as excees seriam 2a, 2b, 2c, etc. 25

b) Exceo - compe-se de uma frase que explica qual exceo ocorreu, pois em uma mesma linha podem ocorrer diferentes tipos de excees. c) Aes corretivas baseiam-se em um fluxo alternativo, ou seja, uma seqncia de aes que deveriam ser executadas para corrigir a exceo. d) Finalizao ltima linha do fluxo alternativo que indica se e como o caso de uso retorna ao fluxo 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 ou abortar o caso de uso, em geral, no interessante considerar como exceo. Logo, as excees a serem consideradas no fluxo principal, devem ser sempre situaes especficas do passo que est sendo executado e no situaes genricas como desistncia do cliente, falta de luz, defeito do sistema de armazenamento de dados, etc. Esse tipo de situao ser tratado na fase de projeto. * Na descrio do Caso de Uso Emprestar DVD descrito anteriormente podemos definir os fluxos alternativos 3.1, 5.1 e 7.1 como fluxos alternativos contendo excees. Caso de Uso Emprestar DVD Atores: Cliente e Funcionrio Fluxo Principal: 1. 2. 3. 4. 5. 6. 7. 8. 9. O O O O O O O O O cliente entra no sistema sistema solicita nome de usurio e senha cliente fornece o nome e senha sistema valida usurio e senha cliente escolhe os DVD que deseja locar sistema registra cada um dos DVD. sistema finaliza a locao sistema lhe informa a hora aproximada da entrega a data de devoluo e o valor total da locao. cliente sai do sistema.

Fluxos alternativos: 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. 26

7.1 O cliente possui pendncias no cadastro (locao anterior no foi paga). 7.1.1 O cliente paga o seu dbito 7.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 uso Para 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 alguns exemplos com diagramas de Caso de Uso. Vamos entend-lo melhor agora.

Figura 8 - Diagrama de Caso de Uso Fonte: 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 e Extenso. 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.

27

Figura 9 - Diagrama de Caso de Uso Emprestar DVD

Variantes do Fluxo Principal Admite-se por princpio, que o fluxo principal seja uma seqncia no ramificada e no aninhada de passos de interao. Entretanto, algumas vezes pode ser til representar o caso de uso de uma forma no to plana. O caso de uso devolver DVD, por exemplo, ter que descrever como o emprstimo pago. O pagamento 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, e assim, 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 <<include>>. 2. Outra maneira de representar admitir a possibilidade de variantes como ramificaes do fluxo 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 Gerente Fluxo Principal 1. 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 Variantes 5.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. 28

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 DVD Atores: Cliente e Funcionrio Fluxo Principal 1. 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: <<include>> Devolver DVD pagando com dinheiro <<include>> Devolver DVD pagando com boleto <<include>> Devolver DVD pagando com carto 6. O funcionrio conclui a devoluo Caso de Uso Devolver DVD pagando com dinheiro 1. 2. 3. 4. O O O O cliente entrega a quantia em dinheiro. funcionrio registra a quantia. sistema informa o troco. 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. 2. compra. 3. 4. O cliente entrega o carto de crdito. O funcionrio envia a informao sobre o carto a operadora de carto, bem como o valor da O Servio de autorizao da operadora de carto envia o cdigo de autorizao. O cliente confirma a autorizao.

29

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

Outro exemplo do uso de <<include>> Caso de Uso Emprestar DVD Atores: Cliente Fluxo Principal: 1. O cliente entra no sistema 2. O sistema solicita nome de usurio e senha 3. O cliente fornece o nome e senha 4. O sistema valida usurio e senha 5. O cliente escolhe os DVD que deseja locar 6. 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 valor total da locao. 8. O cliente sai do sistema. Caso de Uso Reservar DVD Ator: Cliente Fluxo Principal: 1. O cliente entra no sistema 2. O sistema solicita nome de usurio e senha 30

3. 4. 5. 6. 7. 8.

O O O O O O

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

Observando os Casos de Uso Emprestar DVD e Reservar DVD descritos acima, observamos que os passos para validao do cliente (do 1 ao 4) possuem um comportamento exatamente igual. Nesse caso, possvel extrair os passos iguais e criar um novo Caso de Uso separado com um relacionamento include entre eles, ficando assim: Caso de Uso Validar Usurio Ator: Cliente Fluxo Principal: cliente entra no sistema sistema solicita nome de usurio e senha cliente fornece o nome e senha sistema valida usurio e senha

1. 2. 3. 4.

O O O O

Caso de Uso Emprestar DVD Ator: Cliente Fluxo Principal: 1. <<include>> Validar Usurio 2. O cliente escolhe os DVD que deseja locar 3. 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 valor total da locao. 5. O cliente sai do sistema. Caso de Uso Reservar DVD Atores: Cliente Fluxo Principal: 1. 2. 3. 4. 5. <<include>> Validar Usurio O cliente escolhe os DVD que deseja reservar e suas respectivas datas O sistema verifica se h disponibilidade dos DVD. O sistema finaliza a reserva, informando os ttulos dos DVD e as datas. O cliente sai do sistema.

provvel que voc esteja questionando: Isso no quebrar o objetivo em Casos de Uso menores ou decomposio funcional? Eu respondo que no. A tcnica de extrair um Caso de Uso de dentro de outro s deve ser aplicada quando visar reutilizao do comportamento que est sendo extrado. Como foi descrito no exemplo, o Caso de Uso Reservar DVD possua um trecho de comportamento que j existia em 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

31

Emprestar DVD ou Reservar DVD. Deste modo, ele no pode ser entregue sozinho para o usurio, o escopo no define que um Ator pode utiliz-lo diretamente. Do mesmo modo, outro conceito que deve ser levado em considerao so as dependncias no modelo UML. Exploraremos melhor este conceito adiante em - Diagrama de Classes, adiantando, a linha tracejada que liga os Casos de Uso com o relacionamento include significa que o elemento que est lanando 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 Emprestar DVD 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 final do 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 de condies para que fluxos alternativos ocorram, mas voc no consegue encontrar em todo o texto uma s ocorrncia da palavra se como: se o Ator fizer isso, ento ocorrer aquilo. Todas as alternativas esto em forma de afirmao. Casos de Uso bem descritos no possuem a palavra se para definir o rumo dentro dos fluxos possveis. Toda ocorrncia da palavra se pode ser substituda por um Fluxo Alternativo para permitir a decomposio de todos os caminhos possveis do Caso de Uso (cenrios). Cenrios so importantes para a criao dos Casos de Teste que validaro a funcionalidade implementada. Os cenrios extrados da descrio para teste so TODAS as combinaes vlidas de caminhos possveis. Todas as maneiras possveis de se navegar em um Caso de Uso so testadas.

4.1.2.6.9 Relacionamento extend entre Casos de Uso A melhor maneira de explicar um conceito entender quais foram os problemas e necessidades que foram enfrentadas para definir a soluo. Quando a tcnica de Caso de Uso se desenvolveu os analistas tinham um problema para acrescentar comportamentos em Casos de Uso que j estavam definidos ou at implantados. Os analistas imaginavam que seria muito bom se o Caso de Uso definido abrisse uma porta para que os novos comportamentos da evoluo do software fossem incorporados. Essa foi a motivao do relacionamento extend. Um Caso de Uso disponibiliza um ponto de extenso (extension point) que outros Casos de Uso podem observar e de acordo com uma condio, este Caso de Uso que est observando pode assumir o controle e embutir os seus comportamentos. Essa tcnica permitiu a soluo do problema que eles tinham e abriu tambm outras possibilidades importantes para os Casos de Uso. Mesmo para Casos de Uso ainda em construo, possvel acrescentar vrios comportamentos simplesmente abrindo uma extension point. Exemplo: 32

Figura 12 - Relacionamento <<extend>> entre Casos de Uso

Os usurios do sistema solicitaram que fosse criado um Help para o Caso de Uso Emprestar DVD. A qualquer momento em Emprestar DVD o usurio poder selecionar o Help. Assim, Consultar Help observa Emprestar DVD, se a condio destacada {usurio selecionou Help} for satisfeita o Caso de Uso Emprestar DVD ir parar (simplesmente parar, e no encerrar) e o Consultar Help iniciar. Quando Consultar Help for encerrado Emprestar DVD continuar de onde parou. Para direcionar melhor o uso do relacionamento extend, podemos afirmar que voc usar esta tcnica quando necessitar que a qualquer momento dada uma condio, o Caso de Uso base dever ser interrompido e outro Caso de Uso dever assumir o controle. Geralmente um extend utilizado quando o Caso de Uso que est estendendo (que atira a seta) um servio assncrono que pode ser utilizado se a condio descrita ocorrer no Caso de Uso base (que foi atingido pela seta). Para exemplificar a narrativa, vamos descrever os Casos de Uso j descritos acima: Caso de Uso Validar Usurio Ator: Cliente Fluxo Principal: cliente entra no sistema sistema solicita nome de usurio e senha cliente fornece o nome e senha sistema valida usurio e senha

1. 2. 3. 4.

O O O O

Caso de Uso Emprestar DVD Ator: Cliente Fluxo Principal: Extension Points: help 1. <<include>> Validar Usurio 2. O cliente escolhe os DVD que deseja locar 3. 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 valor total da locao. 5. O cliente sai do sistema.

33

Note como no existe qualquer meno ao Caso de Uso que est estendendo Consultar Help, vamos descrev-lo: Caso de Uso: Consultar Help 1. O Ator inicia o caso de uso selecionando a opo Help em Emprestar DVD; 2. O Sistema oferece a interface exibindo a ajuda do sistema; O ponto de extenso (extension point) no precisa necessariamente ser definido, e tambm, ele pode ser definido em um ponto especfico da narrativa, e no como em qualquer momento como o exemplo ditou. Uma narrativa deste modo poderia ser assim: Caso de Uso: emprestar DVD (exemplo 2) Ator: Cliente Extension Points: help 1. <<include>> Validar Usurio 2. O cliente escolhe os DVD que deseja locar 3. [extension point: help] 4. O sistema registra cada um dos DVD. 5. O sistema finaliza a locao, lhe informa a hora aproximada da entrega a data de devoluo e o valor total da locao. 6. O cliente sai do sistema.

Neste exemplo 2 do Caso de Uso, a condio {usurio selecionou Help} s seria avaliada no passo 3. 4.1.2.7 Casos de uso de cadastros bsicos (CRUD) Muitas pessoas questionam sobre a aplicao de Casos de Uso para as funcionalidades mais bsicas do Sistema. Uma dessas funcionalidades so os Casos de Uso para manuteno das tabelas bsicas como tipo de cliente, tipo de pedido, cargo do profissional e etc. A dvida surge, pois cada uma das operaes inserir", consultar", "atualizar" e "excluir" pode ser um objetivo do Ator: Consultar DVD, Remover DVD e etc. Desse conjunto de operaes surgiu a sigla "CRUD" (create, retrieve, update, delete), e assim os CRUD Use Cases. A idia geral para esses cadastros de tabelas bsicas juntar todas essas operaes em um nico Caso de Uso chamado "Manter XXX". Onde XXX seria o nome da "entidade", no nosso caso poderia ser "Manter DVDs", vamos descrev-lo: Caso de Uso: Manter DVD Ator: Funcionrio 1. 2. 3. 4. 5. 6. Funcionrio inicia o caso de uso selecionando o cadastro de DVDs; Sistema oferece uma lista de DVDs; Funcionrio informa que deseja incluir um novo DVD Sistema oferece a tela para incluso; Funcionrio entra com as informaes e seleciona salvar; Sistema informa que as informaes foram salvas e retorna ao passo 2. 3.1 Alterar DVD 3.1.1 O Funcionrio seleciona um DVD para alterar; 3.1.2. O Sistema oferece as informaes do DVD para alterao; 3.1.3 O Funcionrio faz as alteraes e salva-as; volta ao passo 2; 3.2 Excluir DVD 3.2.1 O Funcionrio seleciona um DVD para excluso; 3.2.2 O Sistema solicita uma confirmao; 3.2.3 O Funcionrio confirma a excluso; 3.2.4. O Sistema informa que a excluso foi efetuada; volta ao passo 2; 34 O O O O O O

3.3 Selecionar DVD 3.3.1 O Funcionrio digita a informao do DVD; 3.3.2 O Sistema realiza a busca e mostra os DVDs encontrados; 3.3.3 O Funcionrio seleciona o DVD desejado para maiores detalhes; 3.3.4. O sistema volta ao passo 2; Caso de Uso: Manter Cliente Ator: Funcionrio Fluxo Principal: 1. O Funcionrio inicia o caso de uso selecionando Cadastrar Cliente; 2. O Sistema oferece as opes de incluso, excluso e alterao dos dados; 3. O Funcionrio escolhe incluso e entra com as informaes (nome, RG, CPF, endereo completo, telefone, e-mail, login e senha) e seleciona salvar; 4. O Sistema informa que as informaes foram salvas e encerra. Fluxos Alternativos: 3.1 Alterar Cliente 3.1.1 O Funcionrio seleciona a opo para alterar os seus dados; 3.1.2. O Sistema oferece as informaes dele para alterao; 3.1.3 O Funcionrio faz as alteraes, salva-as e encerra. 3.2 Excluir Cliente 3.2.1 O Funcionrio seleciona um cliente para excluso; 3.2.2 O Sistema solicita uma confirmao; 3.2.3 O Funcionrio confirma a excluso; 3.2.4. O Sistema informa que a excluso foi efetuada e encerra. 3.3 Selecionar Cliente 3.3.1 O funcionrio digita a informao do cliente (nome, CPF...); 3.3.2 O Sistema realiza a busca e mostra os clientes encontrados; 3.3.3 O funcionrios seleciona o cliente desejado para maiores detalhes; 3.3.4. O funcionrio encerra o sistema. Nesse exemplo todas as operaes so efetuadas no mesmo Caso de Uso. Isso deixa o seu modelo mais simples e prtico.

Figura 13 - Caso de Uso Manter DVD e Cliente

4.1.2.7.1 Requisitos Especiais Resumo dos requisitos funcionais e no-funcionais. O documento deve conter um resumo dos requisitos pertencentes a esse caso de uso, no necessariamente a descrio do requisito, mas seu indicativo como F1, F6, F9, o tpico seguinte trata em maiores detalhes essa organizao. 35

4.1.2.7.2 Identificao dos Requisitos atravs da descrio dos casos de Uso Observando a descrio dos casos de uso, ou seja, seus fluxos, podemos identificar vrios requisitos, lembrando que um requisito o que o sistema dever fazer (implementar), vamos analisar os Casos de Uso Emprestar DVD e Reservar DVD e identificar alguns dos principais requisitos, ou seja, os requisitos pertencentes camada de domnio: Caso de Uso Emprestar DVD Fluxo Principal: 1. O cliente entra no sistema 2. O sistema solicita nome de usurio e senha 3. O cliente fornece o nome e senha 4. O sistema valida usurio e senha 5. O cliente entra no sistema e inicia a locao 6. O cliente escolhe os DVD que deseja locar 7. O sistema registra cada um dos DVD. 8. O sistema finaliza a locao 9. O sistema lhe informa a hora aproximada da entrega a data de devoluo e o valor total da locao. 10. O cliente sai do sistema.

Fluxos alternativos: 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 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. 5.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 5.3 Um DVD est reservado para outro cliente. 5.3.1 O funcionrio informa que o DVD no est disponvel para locao. 5.3.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 dbito 7.1.2. O sistema registra a quitao do dbito, eliminando assim a pendncia. 7.1.3. Segue o fluxo normal.

Caso de Uso Reservar DVD Fluxo Principal: 1. 2. 3. 4. O O O O cliente entra no sistema sistema solicita nome de usurio e senha cliente fornece o nome e senha sistema valida usurio e senha 36

5. 6. 7. 8.

O O O O

cliente escolhe os DVD que deseja reservar e suas respectivas datas sistema verifica se h disponibilidade dos DVD. sistema finaliza a reserva, informando os ttulos dos DVD e as datas. cliente sai do sistema.

Observando a descrio identificamos um exemplo com requisitos funcionais e tambm seus requisitos no funcionais (restries) relacionados: F1 - O sistema dever validar usurio e senha para entrada no sistema. NF1. 1 O usurio dever ser um e-mail vlido. NF1. 2 O formato da senha dever ser de no mnimo 4 e no mximo 6 caracteres, incluindo letras e nmeros. NF1. 3 O tempo de espera para a validao no deve ultrapassar 15 segundos. NF 1.4 A senha dever obedecer a um formato prprio para senhas que oculte as informaes visuais ao usurio. F2 - O sistema dever realizar o cadastro do usurio. F3 O sistema dever verificar se o DVD solicitado est disponvel. F4 O sistema dever verificar se o cliente no possui pendncias, ou seja, dbitos. F5 - O sistema dever gerar o valor total da locao. F6 - O sistema dever informar a hora aproximada da entrega dos DVDs na casa do cliente. F7- O sistema dever informar a data da devoluo dos DVDs. F8 O sistema dever fornecer opo de reserva de DVDs. F9 O sistema dever informar os ttulos e respectivas datas da reserva.

4.1.2.7.3 Organizao dos requisitos em casos de uso Na fase de concepo necessrio identificar os grandes processos da empresa. As operaes elementares (consultas e alteraes de dados) possivelmente estaro inseridas dentro desses processos. Por exemplo, no caso do sistema de videolocadora, os grandes processos so: Emprestar DVD, Devolver DVD, Reservar DVD, Manter DVD, etc. funes mais simples como cadastrar clientes e pagar despesas podero ocorrer dentro dos processos maiores com mais freqncia do que como processos independentes. No caso da locadora, o cadastramento do cliente acontecer durante o processo de locao de DVD, caso o cliente no possua cadastro. J o pagamento ocorrer nessa locadora apenas como parte do processo de devoluo de DVD. Os grandes processos de negcio da empresa so tambm chamados de casos de uso. Eles devem cobrir as principais atividades da empresa ligada ao sistema que ser implementado. O objetivo de listar os casos de uso levantar informaes sobre como o sistema interage com possveis usurios e quais consultas e transformaes da informao so necessrias alm daquelas j identificadas na fase de levantamento de requisitos. Cada caso de uso ser associado a um conjunto de requisitos funcionais do sistema. Na fase de concepo, os casos de uso s precisam ser listados e descritos em alto nvel. ainda interessante indicar os atores envolvidos e os requisitos correlacionados. Lembrando que um caso de uso uma descrio de como um ator usa o sistema, o que significa quais as funes que o sistema fornece para o usurio. Ele um objetivo do ator e no uma tarefa do sistema.

Nome Emprestar DVD Reservar DVD

Atores Cliente Cliente Tabela 6 - Requisitos agrupados Fonte: Anlise e Projetos de Sistemas

Descrio Requisitos Permite ao cliente emprestar DVDs. F1, F2, F3, F4, F5, F6, F7 Permite ao cliente reservar DVDs. F1, F2, F3, F4, F8, F9 nos Caso de Uso Emprestar DVD e Reservar DVD de Informao Orientados a Objetos - RAUL WAZLAWICK

Para melhor identificao e organizao dos requisitos, devemos represent-los em tabelas como demonstrado abaixo:
F1 Validar Usurio Oculto ()

37

Descrio: O sistema deve validar o usurio, verificando se o login/usurio existe e se a senha referente a esse usurio, assim permitindo sua entrada no sistema. Requisitos No Funcionais Nome Restrio Categoria Desejvel Permanente ( ) (x) NF1. 1 Formato de Confiabilidade O usurio dever ser um e-mail vlido. usurio ( ) (x) NF1. 2 Formato da O formato da senha dever ser de no mnimo 4 Padro senha e no mximo 6 caracteres, incluindo letras e nmeros. (x) ( ) NF1. 3 Tempo de Performance O tempo de espera para a validao no deve Resposta ultrapassar 15 segundos. ( ) (x) NF1. 4 Formato de A senha dever obedecer a um formato prprio Segurana senha para senhas que oculte as informaes visuais ao usurio.

4.1.2.7.4 Dados Na seo de dados, relacionamos os dados encontrados enquanto escrevemos os casos de uso. interessante o tipo de dados e seu tamanho, conforme a linguagem de programao que ser adotada. Normalmente esses dados sero atributos nos diagramas de classes. 4.1.2.7.5 Observaes Na seo de observaes colocamos lembretes, como prever caso de Uso tal para abordar a situao atual, ou lembretes para colegas ou para o entrevistado que prometeu fornecer um relatrio que no estava disponvel na visita inicial, por exemplo.

4.1.3

Documentos iniciais de um software Bons softwares tm documentao, ou seja, uma histria na qual podemos nos apoiar para entend-los. comum vermos que a documentao, freqentemente deixada de lado, ou por preguia, ou pela presso do tempo em se ver algo concreto para a exibio ao usurio. Contudo, isso pode deixar de ser problema, se nos ocuparmos com a documentao como uma das tarefas do desenvolvimento. Aqui propomos trs documentos iniciais que podem ser agregados, pela sua utilidade ou por seu valor histrico, ao seu modelo de desenvolvimento de sua empresa.

4.1.3.1 Documento de Viso ou Requisitos A viso do projeto, (tambm chamado de sumrio executivo, viso de negcio, enunciado do problema, requisio do cliente, entre outros) um relato resumido com os principais tpicos que o negcio a ser automatizado deve fornecer. Normalmente, ele faz parte do contrato de desenvolvimento de software. Esse documento pode abordar aspectos de tecnologia como, quais linguagens e banco de dados sero usados. Apesar disso, ele uma leitura de alto nvel para aqueles que so os contratantes do software. O diagrama de Caso de Uso nvel 0 ou Pacote de <<sistema>> baseia-se nesse documento. Ele uma espcie de contrato, entre quem contratou e quem contratado. Onde o requisitante diz: para isso que estou contratando, e isso que quero como fruto do desenvolvimento que iniciar. E quem desenvolve o software diz: para isso que estou sendo contratado, e baseado nisso que desenvolverei o produto de software. O nascimento desse documento, normalmente se d na primeira reunio com os clientes do software. Aqui, necessrio explicar que clientes no so somente pessoas ou organizaes externas, mas pessoas, divises ou departamentos internos. Modelo de Documento de Viso - Completo 1 Introduo Reserve essa seo para uma descrio geral do trabalho esperado. 2 Escopo Relacione os principais mdulos que sero detalhados em perspectiva do produto (Veja os itens 8.1, 8.2, etc.). 3 Definies Acrnimos e Abreviaturas Faa o possvel para no utilizar termos relativos a rea de informtica, se isso for necessrio fornea o significado. 38

4 Referncias Relate a fonte na qual esse documento se baseou e os participantes desses eventos. Nomeie as pessoas, seus cargos e localidades. 5 Oportunidades de Negcio Descreva qual a oportunidade de negcio que est em apreciao como motivao para o surgimento desse software. 5.1 Problema a ser solucionado Descreva qual o problema que est sendo solucionado com esse software. 6 Descrio de Stakeholders Relacione os stakeholders, ou seja, todas as pessoas envolvidas com o software, seus cargos, nomes, telefones, e-mails. Isso ser uma boa referncia para futuros participantes. 6.1 Ambiente atual dos clientes Descreva o ambiente atual de informtica relativo a esse software que ser construdo, como sistema operacional, tecnologias, entre outros. 8 Mdulos 8.1 Perspectiva do Produto: Nome do mdulo I 8.2 Perspectiva do Produto: Nome do mdulo II 8.3 Perspectiva do Produto: Nome do mdulo III.. Descreva nesses tpicos os detalhes que cada mdulo atender. Procure descrever o que o mdulo faz, para que serve e como se relacionar com outros mdulos. Cada mdulo ser um componente no diagrama de Caso de Uso. 9 Precedncia e prioridades Indique qual a prioridade dos mdulos e se ela ter a mesma ordem de precedncia para o desenvolvimento. Explique porque adotou essa estratgia ao invs de outras. Isso ser importante para reunies onde podem perguntar: Mas por que no fizemos isso dessa maneira? 10 Requisitos No Funcionais Relate aqui as dependncias de softwares externos, particularmente de performance que so esperados, grandes necessidades de treinamento, entre outras. 11 Requisitos de Sistemas e Ambientes Descreva o sistema operacional escolhido, a linguagem de programao e os bancos de dados que sero utilizados, se ser utilizados um servidor de aplicao e qual ser, assim como outros servidores e softwares. 12 Requisitos de documentao Descreva em quais partes a documentao ser dividida, quais so essas partes e o que o cliente pode esperar de cada uma. 13 Viso Geral UML Insira uma figura que represente o diagrama de Caso de Uso.
Tabela 7 - Modelo de Documento de Viso - Completo Fonte: Desenvolvendo Software com UML 2.0 - Ernani Medeiros

Vamos agora supor que o cliente contratante aprovou nosso contrato, nosso documento Viso, e entendemos nosso diagrama de Caso de Uso para o documento Viso, o de nvel 0. Estamos prontos para o incio da anlise propriamente dita. Essa fase comea com o documento Nomenclatura. 4.1.1.1 Documento Nomenclatura Esse documento serve para criarmos um padro nico de pr e ps fixao para todas as palavras envolvidas em estrutura de cdigo, escrita de Caso de Uso ou mesmo de criao de tabelas em banco de dados. Novos colaboradores que se unirem equipe devero se adequar a esse formato de escrita. O benefcio dessa deciso , principalmente, o de no termos vrios estilos de cdigo para lermos. Nesse documento, as regras de documentao de cdigo devem ser explcitas, a fim de no gerar ms interpretaes. A notao Hungariana (HN) uma conveno de nomes que foi originalmente feita por Charles Simony, da Microsoft, e que usada ao longo de todo o cdigo-fonte do sistema operacional Windows. A especificao original um pouco complexa e especfica para a linguagem de programao C, porm ela pode ser convertida para outras linguagens e, em nosso caso, iremos port-la para Java. Essa deciso se d em razo de que todos os nossos exemplos sero em Java, e temos que escolher uma linguagem, voc poder fazer as adaptaes para seu caso especfico. 39

Para maiores informaes sobre a notao HN, entre no site da Hungarian Notation for C Programming. Modelo de Nomenclatura Variveis, Objetos e Classes As variveis so constitudas de diversas partes, quais sejam: Escopo da varivel + Tipo da Varivel + Nome da Varivel + Qualificador Escopo Em C, o escopo representa a visibilidade de uma varivel, como global, local, etc. Em Java, o escopo pode ser privado, pblico, protegido, etc. Tipo Indica o tipo de dado ou classe de uma varivel; a parte mais importante da notao hungariana. Para isso usamos um nico caractere em minsculo, indicando o tipo primitivo em Java. Nos casos em que isso se repetir, usaremos a criatividade dos programadores. Tipos de Dados Bsicos boolean int Double, Double [] ... Prefixo b i d
Tabela 8 - Tipo de dados bsicos em Java Fonte: Desenvolvendo Software com UML 2.0 - Ernani Medeiros

Tipos de Classes e outros tipos Character List Button ...

Prefixo c lst btn

Tabela 9 - Tipos de Classes e outros tipos em Java Fonte: Desenvolvendo Software com UML 2.0 - Ernani Medeiros

As excees a essas regras so relativas a variveis que tem um escopo relativamente pequeno, por exemplo, loops. Nesse caso, ser adotado o uso das letras i, j,k, l, etc. e em minsculo. Segue um exemplo de cdigo abaixo: for (int i=0; i< num; i++) { ... } Nome da varivel O nome de uma varivel deve seguir a quantidade de palavras necessrias para explicar o seu sentido. Cada palavra se iniciar por uma letra em minscula, e quando mudar a palavra, o incio da palavra iniciar em maiscula. Exemplo, iCodigoCliente, indicando que seu tipo inteiro em Java e seu contedo o cdigo do cliente. Seguem outros exemplos vlidos: cRua, fSalario, bEstadoCivil. Nome de banco de dados e tabelas Normalmente, esse tpico no da alada de quem est desenvolvendo, mas sim do DBA (Data Base Administrator). Nome das janelas Os arquivos que sero dialog no Java recebem a prefixao de dlg, arquivos HTML recebem, no caso de formulrios, frm. Se as pginas forem de processamento que no aparecem para o usurio final recebero a prefixao de proc, significando processamento. As pginas de resultados recebem a prefixao de rst. 40

Nomes de operaes e mtodos de classes As operaes ou mtodos de classes devem ser prefixadas de seu retorno. Essa prefixao deve seguir palavras que identifiquem o que o mtodo faz. Sempre que possvel, essa parte deve ser iniciada com um verbo no infinitivo obter, incluir, alterar, etc., seguida de outras palavras que indiquem o alvo daquela ao. Exemplos: strObterNomeCliente Indica que o mtodo retorna o nome de um cliente, e seu retorno uma String. bAlterarNomeCliente Indica que o mtodo alterar o nome de um cliente, e seu retorno boolean. 4.1.1.2 Documento Glossrio O documento de glossrio traduz, para algum que no conhece o software, todos os termos utilizados pelo usurio contratante e outros stakeholders. Deve ser disponibilizado na intranet da empresa a fim de permitir constantes pesquisas. A finalidade desse documento agir como um tradutor entre os participantes da anlise, do desenho, da codificao, dos testes, e vocabulrio particular da empresa. Esse documento existe para todos os softwares. Cada software possui um documento Glossrio que pode e deve ser acrescido de termos, conforme a necessidade.

4.1.2

Estudo de Caso Locao de DVD pela Internet- Parte 1

Exemplo dos documentos: Documento de Viso - Resumido Software: Locao de DVD pela Internet Data: 04 de agosto de 2008 Requisitantes: Empresa Cliente Principais contatos: Contato 1 cmaricy@gmail.com 65-84035338 Contato 2 cmaricy@gmail.com 65-84035338 Contato 3 cmaricy@gmail.com 65-84035338 Descrio Esse software tem o objetivo de disponibilizar a locao de DVDs, via Internet, a clientes j cadastrados ou novos. O software deve prever o cadastramento de usurios locadores, com seus dados pessoais, principalmente os dados de endereo, que so to importantes para a entrega como para a recuperao de produtos alugados. O software atender a todas as cidades onde o cliente contratante tiver depsito de DVD. Sero disponibilizados somente DVDs da cidade onde o cliente locador residir, visando entrega. O cliente locador deve informar o modelo de seu equipamento de DVD, a fim de se avaliar se ele ou no adequado a reproduzir o filme. O cliente locador ter, no mximo, cinco dias para a devoluo de um DVD alugado, sendo que esse perodo depender do tipo de DVD, que pode ser: desde lanamentos at DVDs antigos. O processo de fidelizar o cliente locador leva em considerao tanto o nmero de locaes quanto as devolues pontuais. A no devoluo de um DVD no prazo estipulado implica pagamento de multa. O cliente locador pode designar, desde que apresente a documentao necessria, beneficirios capazes de efetivar um aluguel de DVD. As entregas sero feitas somente dentro da cidade em que o locador reside. Os administradores do site podero controlar o Programa de fidelidade, Programa de Promoes, Preo e Marketing. Os pagamentos sero feitos em dinheiro, carto de crdito ou boleto bancrio. Ass. Cliente Contratante _______________________ Ass. Equipe de Desenvolvimento ____________________________ 41

____________________________

Tabela 10 - Documento de Viso Resumido Fonte: Desenvolvendo Software com UML 2.0 - Ernani Medeiros

Glossrio Software: Locao de DVD pela Internet Locao Ato de alugar um produto disponvel no estoque da empresa. Usurio ou Cliente Locador Aquele que aluga um produto. Pode ser o locador principal ou seu beneficirio. Beneficirio Aquele que um agregado, por parentesco ou designao de um cliente locador. Cliente Contratante Aquele que fez a requisio do software. Equipamento de DVD Aparelho que permite a execuo de discos de DVD. Nesse sentido, so agregadas todas as especificaes desse aparelho. DVD Lanamento Aquele disco de DVD que representa data de lanamento do filme inferior a trs meses. DVD Antigo Aquele disco de DVD que representa data de lanamento do filme superior a trs meses. Multa Valor monetrio pago empresa detentora do produto. Fidelidade Programa que visa estimular o retorno de um cliente locador empresa.
Tabela 11 - Glossrio Fonte: Desenvolvendo Software com UML 2.0 - Ernani Medeiros

Documento da Descrio (Fluxos) do Caso de Uso Emprestar DVD Revisado UC001 Emprestar DVD

Breve descritivo: Este caso de Uso descreve o processo de locar DVD Pr-condies: Cliente seleciona grupos de produtos para locar Ator: Cliente Fluxo Principal: 1. O Cliente visualizar os grupos de produtos existentes, a partir de uma lista criada com os gneros, Infantil, Adulto, Ao, Policial, Romance, comdia, Drama e todos. 2. O cliente escolhe um tipo de grupo selecionando o gnero. 3. O cliente escolhe o gnero, e busca por nome de ator, nome do diretor ou ttulo do filme. 4. O cliente informa o texto relativo busca, com mais de trs caracteres. 5. O cliente visualiza os resultados com 20 resultados por pgina, com a capa e o resumo do DVD. 6. O cliente seleciona o filme e o adiciona a cesta de locao. 7. O sistema deduz a quantidade do DVD escolhido do estoque de cpias. 8. O cliente executa novamente a busca a fim de obter outros ttulos. 9. O cliente identifica-se pelo usurio/login e senha 10. O sistema valida o login, certificando-se que o cliente j possui cadastro. 11. O cliente seleciona a opo de pagamento <<include>> Pagar locao com dinheiro <<include>> Pagar locao com boleto <<include>> Pagar locao com carto 42

12. O sistema informa o tempo aproximado de entrega, em horas, no endereo listado pelo cliente como endereo de entrega. 13. O cliente encerra saindo do sistema. Fluxos Alternativos 1.1 O cliente escolhe um filme de promoo ou lanamento, sem recorrer a busca. 1.1.1 O sistema mostra o filme com a capa e resumo. 1.1.2 O fluxo segue no passo 6. 4.1 Cliente usa padro de busca com menos de trs caracteres 4.1.1 O sistema alerta o cliente sobre o padro. 4.1.2 Segue o fluxo normal. 5.1 No h resultado a ser exibido 5.1.1 Retorna ao passo 4. 5.2 No h resultado a ser exibido 5.2.1 Sai do sistema sem locar o filme. 10.1 Login inexistente 10.1.1 O sistema informa ao usurio para cadastrar-se, <<include>> Manter Cliente 10.1.2 Segue no passo 10. 10.2 Senha incorreta 10.2.1 Retorna ao passo 9. 12.1 Cliente altera endereo de entrega 12.1.2 Sistema fornece as opes para alterao. 12.1.3 Cliente altera e salva. 12.1.4 Segue fluxo normal no passo 13. Requisitos Especiais Podemos colocar os requisitos aqui ou ento, organizados em tabelas, preferimos organiz-los em tabelas. Ver tabelas 1, 2, 3, 4,5... Observao: Prever os Casos de Uso, Manter DVD e Manter Cliente. Analista de negcio: Joo da Silva Jr. Entrevistado: Jos Manuel dos Santos rea: Direo de Lojas Data: 08/08/2008 Verso: 1.0

UC002 Pagar DVD com dinheiro Fluxo Principal 1 O cliente seleciona a opo de pagamento com dinheiro (podendo ser transferncia) 2 O cliente escolhe pagar com dinheiro. 3 O sistema oferece as opes de contas. 43

4 O cliente transfere o dinheiro para a conta escolhida. 5 O sistema confirma o pagamento. 4.1 Cliente no possui saldo para transferir 4.1.1 O sistema informa ao cliente para escolher outra forma de pagamento ou encerrar. 4.2 Conta invlida 4.2.1 Sistema solicita que cliente procure a administrao do sistema ou a agncia. 4.2.2 Cliente fecha o sistema sem realizar a locao.

UC002 Pagar DVD com boleto Fluxo Principal 1 O cliente seleciona a opo de pagamento com boleto 2 O cliente escolhe pagar com boleto. 3 O sistema gera o boleto. 4 O cliente paga o boleto. 5 O sistema confirma o pagamento. UC003 Pagar DVD com carto Fluxo Principal 1 O cliente seleciona a opo de pagamento com carto 2 O sistema oferece as opes de carto. 3 O cliente entra com as informaes do carto. 4 O sistema envia a solicitao para a operadora de carto. 5 O sistema confirma o pagamento. 3.1 Carto invlido 3.1.1 Sistema solicita que cliente procure a agncia. 3.1.2 Cliente fecha o sistema sem realizar a locao. 4.1 Operadora de carto no autoriza. 4.1.1 Sistema retorna ao passo 2 ou encerra.

Tabela 12 - Documento da Descrio (Fluxos) do Caso de Uso Emprestar DVD Revisado

Obs. Lembre-se que representamos nos fluxos alternativos as seguintes situaes: Uma escolha do usurio como no fluxo alternativo 1.1 onde o cliente pode escolher a busca por um DVD (que o convencional e mais utilizado), mas tambm tem a opo de seguir direto por uma promoo. Outra situao so as excees que podem ocorrer impedindo o ator de continuar naquele processo, como o caso do fluxo alternativo 10.1 Login inexistente, onde o cliente precisa sair do processo atual, fazer o seu cadastro e depois retornar ao processo. Podemos representar os fluxos alternativos e depois os fluxos alternativos contendo excees. Caso de Uso relativo ao documento Viso

44

Figura 14 - Caso de Uso relativo ao documento Viso nvel 0 Fonte: Desenvolvendo Software com UML 2.0 - Ernani Medeiros

Alguns autores no colocam a figura do quadrado, para designar os limites boundary do software. No h regra que se sustente aqui. A nica regra voc saber que a notao UML deve ser mantida. Os Casos de Uso devem representar macroatividades a serem realizadas e os atores representam aqueles que executam essas atividades. Um caso de Uso no tem reflexo direto na codificao, ele um instrumento de visualizao da complexidade e sua abstrao.
4.1.3

Software de Apoio Ferramenta CASE - Jude - http://jude.change-vision.com/jude-web/index.html

Exerccio 1 Escolher um tema para um estudo de caso e fazer o seguinte: Reunir-se em equipes de quatro acadmicos, onde cada um ter um papel especfico (a ser sorteado). Utilizar as tcnicas para levantamento dos requisitos: o Ponto de Vista; o Workshop; o Prototipagem com GUI; o Brainstorming. o Outras que julgar necessrias. Fazer as descrio dos requisitos, ou seja o que o sistema dever fazer, por exemplo: O sistema dever validar usurio e senha para entrada no sistema. (Nesse momento no ser usado nenhum padro).

Exerccio 2

45

A partir da viso descrita abaixo resolver as seguintes questes: Identificar os atores e Casos de Uso; Descrever todos os Casos de Uso em fluxos; Desenhar o diagrama de Caso de Uso; Identificar todos os requisitos, organizar os requisitos em casos de uso (usar a tabela 7 como modelo), organizar os requisitos funcionais e no funcionais em tabelas (usar a tabela 4 como modelo) A empresa Brain, organizadora de concursos pblicos, necessita de um sistema que controle todo o processo seletivo. O sistema deve gerar informaes para serem disponibilizadas aos candidatos, no site da empresa. Todas as provas aplicadas por essa empresa consistem em questes objetivas com cinco alternativas ou questes discursivas. Outro tipo de prova a prtica, cujos critrios de avaliao (exceto a nota final obtida pelo candidato) no sero informatizados, pois so especficos a cada caso. Nos editais dos concursos existem diversas informaes relevantes para os candidatos (como por exemplo: critrios de admisso). Todavia, para o nosso sistema sero controladas apenas as informaes relevantes para a informatizao do processo. Vejamos quais so essas informaes: Ao ser contratada para comandar um processo seletivo, a empresa-objeto do concurso deve fornecer alguns dados, como: Nome da empresa-objeto (ou rgo); Nmero do edital do concurso; Relao de cargos oferecidos no concurso. Para cada cargo importante informar: o Seu nome (ex. Analista de Sistema); o As localidades de trabalho, incluindo UF e municpio; o Para cada localidade, nmero de vagas totais e para deficientes fsicos (ex. 5 vagas para Rio de Janeiro-RJ, 10 vagas para Belo Horizonte-MG); o Relao de provas a serem aplicadas, constando cada uma: o tipo de prova (objetiva, discursiva ou prtica); rea de conhecimento (ex. Lngua Portuguesa); nmero inicial e final das questes (exceto para a prova prtica); peso; carter de aprovao (eliminatria ou classificatria); data de realizao; percentual mnimo para critrio de eliminao (ex. se o candidato acertar menos de que 20% da prova estar eliminado); para as questes objetivas, deve-se obter o nmero da questo, a pontuao e o gabarito oficial; o Critrios de desempate; relao de provas que, na ordem determinada, desempatam o resultado. Em caso de persistir o empate, sabe-se que o critrio final quanto ao candidato mais velho; o O valor da taxa de inscrio. Perodo de inscries; Percentual mnimo para o critrio de eliminao quanto ao conjunto de provas (ex. se o candidato acertar menos de 30%, do conjunto de pontos possveis em todas as provas, estar eliminado). Uma vez que o edital seja divulgado e as inscries tenham incio, os dados dos candidatos precisam ser armazenados. So elas: nome do candidato; endereo (logradouro, nmero, complemento, bairro, CEP, cidade e UF); telefones de contato; e-mail; data de nascimento; sexo; nmero e tipo de documento de identificao civil; cargo, localidade escolhida; se o candidato deficiente fsico e qual a deficincia. S deve ser permitido o cadastramento de candidatos at cinco dias aps o trmino das inscries. O nmero de inscrio de cada candidato gerado ao ser efetuado seu cadastro. De posse das informaes sobre a realizao da prova, temos para cada prova a ser aplicada: local, (endereo e sala); horrio de realizao. A partir da aplicao das provas, so cadastradas as seguintes informaes, para cada prova: Relao de candidatos que no compareceram; Gabarito das provas objetivas dos candidatos que compareceram. O sistema dever ser atualizado com o gabarito oficial para que seja feita automaticamente a correo das questes objetivas. O cadastro e a correo automatizada so de responsabilidade exclusiva do Supervisor de Seleo. 46

Recursos so interpostos e a partir desses so cadastradas para cada recurso, prova e questo de referncia. Aps anlise do recurso, pode haver mudana de gabarito ou anulao da questo. O sistema deve emitir, quando solicitado, para controle interno da empresa e divulgao em seu site: Lista de candidatos X locais de prova (s poder sem impresso sete dias aps a data de trmino das inscries e cadastros dos locais de prova); Relao candidato/vaga (s poder sem impresso sete dias aps a data de trmino das inscries); Carto de confirmao do candidato (s poder sem impresso sete dias aps a data de trmino das inscries); Gabarito oficial das provas (s poder sem impresso sete dias aps a data de trmino das inscries); Resultado parcial da correo das notas sem classificao; Resultado final com classificao; Relatrio financeiro do processo de seleo; O controle das in formaes sobre o concurso pblico (empresaobjeto e dados sobre os cargos) e das inscries dos candidatos feita pelo Departamento de Seleo. O controle do lanamento das provas aplicadas e dos recursos realizado pelo Departamento de Resultados. Diagrama de Atividades Um diagrama de atividades na verso anterior a UML era considerado um caso especial do diagrama de estados. Na UML 2.0 o diagrama de atividades foi redesenhado para usar uma semntica semelhante a um grfico de Petri, no lugar da mquina de estados. A verso atual do diagrama est mais coerente com um diagrama de fluxo de dados ou workflow. O diagrama de atividades completo ligado a um classificador como um caso de uso, um pacote ou a implementao de uma operao. Esse diagrama tem o propsito de focalizar um fluxo de atividades que ocorrem internamente em um processamento, dentro de um perodo de tempo.
4.1.4

4.1.4.1 Modelando Diagramas de Atividade Para termos uma primeira idia do que seja um diagrama de atividades, vamos pensar como poderamos modelar atividades simples de nossa vida, como Sair para Trabalhar. A descrio desse conjunto de atividades pode ser feito de maneira simplificada como: comearmos saindo de casa. Logo aps, escolhemos um meio de transporte. Se o transporte escolhido for um nibus, deve-se ir para o ponto de nibus, pegar a conduo, pagar e aguardar chegar prximo ao trabalho. Voltando um pouco em nossa escolha, se esta for por metr, devemos ir at a estao, comprar um ticket, pegar o metr e aguardar chegar a estao prxima ao trabalho. Nos dois casos, devemos descer e nos dirigir ao trabalho. Vejamos na figura, como ficaria esse diagrama de atividades.

47

Figura 15 - Exemplo de diagrama de atividades sobre "Sair para trabalhar" Fonte: MELO Ana Cristina, Desenvolvendo Aplicaes com UML 2.0.

Conceitos em diagramas de atividades 4.1.4.1.1 Ao (Action) Uma ao por definio uma unidade bsica existente para a especificao de um comportamento, que venha a representar alguma transformao ou processamento na modelagem de um sistema. Um uso comum de uma ao a modelagem de um passo especfico da execuo de um processo de workflows. Uma ao mostrada graficamente como um retngulo de cantos arredondados. O nome da ao colocado dentro da figura. 48

Pode-se definir pr e ps condies para aes, que correspondam ao que deve ser verdadeiro antes da ao ser executada e ao que deve ser verdadeiro aps a execuo da ao.

Figura 16 - Exemplo de aes Fonte: MELO Ana Cristina, Desenvolvendo Aplicaes com UML 2.0

4.1.4.1.2 Atividade (Activity) Uma atividade composta de uma seqncia de aes ou outras atividades. Atividades podem conter aes de vrios tipos, como: Ocorrncias de funes primitivas; Chamadas de comportamentos; Aes de comunicao, como envio de sinais; Manipulao de objetos, como leitura e escrita de atributos. 4.1.4.1.3 Fluxo de controle (Control Flow) Mostra o fluxo que conecta aes e atividades, ou seja, mostra a seqncia de execuo. Representa a concluso de uma atividade e incio da prxima, ou seja, a passagem de uma tividade para outra, essa passagem pode ser considerada como um gatilho (trigger), acrescentar efeitos (effect) ou resultados e apontar o efeito na ponta da seta . Na verso anterior da UML era definido como transio. representada graficamente como uma linha simples acompanhada de uma seta de direo.

Figura 17 - Exemplo de fluxo de controle Fonte: MELO Ana Cristina, Desenvolvendo Aplicaes com UML 2.0

Ns de controle Apresenta-se de diversas formas: 4.1.4.1.4 N inicial (Initial node) Indica o n que inicia um fluxo quando uma seqncia de atividades invocada. Estado inicial.

4.1.4.1.5 Atividade Final (Activity final) Indica o n que pra todos os fluxos numa atividade. Estado final.

4.1.4.1.6 Fluxo Final (Flow final) Indica o n final que termina um fluxo numa atividade. Utilizado para finalizar algum fluxo, mas no todos.

49

4.1.4.1.7 N de deciso (Decision node) Permite que a partir de condio de guarda, sejam escolhidos entre mais de um fluxo de sada. Utilizado para simular a construo de um if-then-else, ou seja, se nada der certo (se nada for verdadeiro) execute o meu fluxo alternativo (fluxo else). A representao grfica de uma deciso a figura de um losango. A figura recebe uma seta, representando o fluxo de chegada e partem dela duas ou mais setas, representando fluxos de sada. 4.1.4.1.8 N de intercalao (Merge node) A mesma representao grfica da deciso utilizada para marcar o fim de fluxos disparados por uma deciso. Esta representao identificada como uma intercalao (merge). A figura abaixo mostra os dois tipos de ns.

Figura 18 - Exemplo de deciso e intercalao Fonte: MELO Ana Cristina, Desenvolvendo Aplicaes com UML 2.0

4.1.4.1.9 N de bifurcao (Fork node) A bifurcao separa um fluxo de entrada em vrios fluxos concorrentes, sendo que todos eles so disparados ao mesmo tempo. A representao grfica feita atravs de uma linha grossa (formato de barra). 4.1.4.1.10 N de unio (Join node) A unio um n que sincroniza mltiplos fluxos concorrentes, ou seja, a unio concatena fluxos de regies concorrentes em um nico fluxo simples. A representao grfica feita atravs de uma linha grossa (formato de barra). Abaixo a figura que representa esses ns.

50

Figura 19 - Exemplo de bifurcao e unio Fonte: MELO Ana Cristina, Desenvolvendo Aplicaes com UML 2.0

4.1.4.1.11 Raias Aes e atividades podem ser organizadas dentro de raias (swimlanes), que so usadas para agrupar responsabilidades para aes ou responsabilidades. Elas normalmente correspondem a unidades organizacionais num modelo de negcios. Um diagrama de atividades pode ser dividido visualmente em raias, cada qual separada de suas raias vizinhas p linhas verticais de ambos os lados. Fluxos podem atravessar as zonas das raias. A UML 2.0 acrescenta uma segunda maneira de mostrar responsabilidades so os nomes de diviso (partition names). Este caso usado quando no possvel fazer o uso das raias. Assim, a soluo colocar o nome da parte responsvel entre parnteses, dentro do retngulo da ao.

51

Figura 20 - Exemplo de raias Fonte: MELO Ana Cristina, Desenvolvendo Aplicaes com UML 2.0

A UML 2.0 trouxe Regies de Atividades Interrompidas. Vamos supor que um produto, em um carrinho de compras, pode ser cancelado a qualquer tempo, exceto no momento que a compra foi finalizada e o processo de pagamento terminado. A figura 21 mostra as regies de interrupo em um retngulo com as bordas tracejadas. Esse diagrama est simplificado para fins didticos.

52

Figura 21 - Regies de interrupo Fonte : Desenvolvendo Software com UML 2.0 - Ernani Sales de Medeiros

A qualquer momento, dentro da regio de interrupo, a atividade Cancelar Carrinho pode ser invocada, No tnhamos isso at a UML 1.x, mas fazamos exatamente isso. Adicionalmente, introduzimos um smbolo de uma atividade abstrata, em nosso caso, representando um evento solicitou o Cancelamento da Compra. Esse smbolo chamado, tambm, de n de objeto, porm falamos aqui de atividade e no de objetos em si. chamado de n de objeto, porque essa atividade ser parte do fluxo da atividade de um objeto. A seta de uma atividade abstrata parte dela em ziguezague, como mostra a Figura 22. Sinais de aceitao. So eventos que podem ser representados sendo enviados e recebidos e provocam uma transio quando recebidos, assim tambm como o smbolo de atividades peridicas. Veja o seguinte exemplo:

Figura 22 - Periodicidade e sinais de aceitao Fonte : Desenvolvendo Software com UML 2.0 - Ernani Sales de Medeiros

1 Esse o smbolo de periodicidade; coloco-a juntamente com uma condio. Use o smbolo de ampulheta para designar atividades que ocorrem com periodicidade. 2 Uma atividade comum. 3,4 Um sinal enviado (3) e um sinal aceito (4) que ocorrem e geram uma transio. 5 Uma atividade comum. 53

Utilizamos regies de interrupo na figura 21, mas poderamos ter utilizado eventos de aceitao tambm. Podemos usar qualquer dessas notaes dando a semntica que acharmos necessria. A UML 2.0 introduziu o significado de atividade paramtrizada, ou seja, uma atividade pode receber e enviar um parmetro. Isso representado por meio de um pequeno retngulo colado atividade, chamado de PIN. A finalidade que aes recebam e gerem resultados. A finalidade que aes recebam e gerem resultados. Provavelmente isso ser figurado em mtodos de classes. Veja a figura 23, para a notao da atividade parametrizada.

Figura 23 - Atividades parametrizadas - PIN Fonte : Desenvolvendo Software com UML 2.0 - Ernani Sales de Medeiros

Agora conhecendo a notao desse diagrama, podemos fazer o nosso primeiro diagrama de atividade relativo atividade de alugar DVDs. Vamos pensar no ponto crucial do negcio. O diagrama ser representado nas figuras 24 e 25. Aqui utilizamos a abstrao do processo de alugar um DVD e no do cadastramento. Da forma como esse processo est modelado, caso o cliente locador escolha um DVD e no esteja cadastrado, ser possvel seu cadastramento ou de um beneficirio. Caso no desejar se cadastrar poder sair do processo.

54

Figura 24 - Primeira parte do diagrama de atividades referente locao Fonte : Desenvolvendo Software com UML 2.0 - Ernani Sales de Medeiros

Outra novidade que, no momento que se adiciona o DVD na cesta, o cliente locador pode retornar busca e pesquisar novo DVD.

55

Figura 25 - Segunda parte do diagrama de atividades referente locao Fonte : Desenvolvendo Software com UML 2.0 - Ernani Sales de Medeiros

A novidade mostrada na figura 25, uma linha divisria que separa o que o ator cliente locador faz das aes executadas pelo site. Essa linha divisria recebe o nome de swimlane na UML. Podemos ter vrias swimlanes nos diagramas de atividades, ela apenas define ou divide as responsabilidades de um ator para outro.

56

Figura 26 - ltima parte do diagrama de atividades referente locao Fonte : Desenvolvendo Software com UML 2.0 - Ernani Sales de Medeiros

Outra novidade, em termos de notao nesse diagrama, o uso da nota. O smbolo da nota um retngulo com uma pequena dobra no canto, ele pode ser usado a qualquer momento e em qualquer diagrama da UML. As informaes que esto divididas com uma barra significam na primeira parte trigger e na segunda effect. O caso de uso referente ao processo de Emprestar DVD est descrito abaixo, abaixo descrevemos o caso de uso Manter Locador, referente ao cadastro do locador. Caso de Uso Emprestar DVD Atores: Cliente e Funcionrio UC001

Emprestar DVD

Breve descritivo: Este caso de Uso descreve o processo de locar DVD Pr-condies: Cliente seleciona grupos de produtos para locar Ator: Cliente Fluxo Principal: 1. O Cliente visualizar os grupos de produtos existentes, a partir de uma lista criada com os gneros, Infantil, Adulto, Ao, Policial, Romance, comdia, Drama e todos. 2. O cliente escolhe um tipo de grupo selecionando o gnero. 3. O cliente escolhe o gnero, e busca por nome de ator, nome do diretor ou ttulo do filme. 4. O cliente informa o texto relativo busca, com mais de trs caracteres. 5. O cliente visualiza os resultados com 20 resultados por pgina, com a capa e o resumo do DVD. 57

6. O cliente seleciona o filme e o adiciona a cesta de locao. 7. O sistema deduz a quantidade do DVD escolhido do estoque de cpias. 8. O cliente executa novamente a busca a fim de obter outros ttulos. 9. O cliente identifica-se pelo usurio/login e senha 10. O sistema valida o login, certificando-se que o cliente j possui cadastro. 11. O cliente seleciona a opo de pagamento <<include>> Pagar locao com dinheiro <<include>> Pagar locao com boleto <<include>> Pagar locao com carto 12. O sistema informa o tempo aproximado de entrega, em horas, no endereo listado pelo cliente como endereo de entrega. 13. O cliente encerra saindo do sistema. Fluxos Alternativos 1.1 O cliente escolhe um filme de promoo ou lanamento, sem recorrer busca. 1.1.1 O sistema mostra o filme com a capa e resumo. 1.1.2 O fluxo segue no passo 6. 4.1 Cliente usa padro de busca com menos de trs caracteres 4.1.1 O sistema alerta o cliente sobre o padro. 4.1.2 Segue o fluxo normal. 5.1 No h resultado a ser exibido 5.1.1 Retorna ao passo 4. 5.2 No h resultado a ser exibido 5.2.1 Sai do sistema sem locar o filme. 10.1 Login inexistente 10.1.1 O sistema informa ao usurio para cadastrar-se, <<include>> Manter Cliente 10.1.2 Segue no passo 10. 10.2 Senha incorreta 10.2.1 Retorna ao passo 9. 12.1 Cliente altera endereo de entrega 12.1.2 Sistema fornece as opes para alterao. 12.1.3 Cliente altera e salva. 12.1.4 Segue fluxo normal no passo 13. Requisitos Especiais Podemos colocar os requisitos aqui ou ento, organizados em tabelas, preferimos organiz-los em tabelas. Ver tabelas 1, 2, 3, 4,5... Observao: Prever os Casos de Uso, Manter DVD e Manter Cliente. Analista de negcio: Joo da Silva Jr. Entrevistado: Jos Manuel dos Santos rea: Direo de Lojas Data: 08/08/2008 58

Verso: 1.0

UC002 Pagar DVD com dinheiro Fluxo Principal 1 O cliente seleciona a opo de pagamento com dinheiro (podendo ser transferncia) 2 O cliente escolhe pagar com dinheiro. 3 O sistema oferece as opes de contas. 4 O cliente transfere o dinheiro para a conta escolhida. 5 O sistema confirma o pagamento. 4.1 Cliente no possui saldo para transferir 4.1.1 O sistema informa ao cliente para escolher outra forma de pagamento ou encerrar. 4.2 Conta invlida 4.2.1 Sistema solicita que cliente procure a administrao do sistema ou a agncia. 4.2.2 Cliente fecha o sistema sem realizar a locao.

UC002 Pagar DVD com boleto Fluxo Principal 1 O cliente seleciona a opo de pagamento com boleto 2 O cliente escolhe pagar com boleto. 3 O sistema gera o boleto. 4 O cliente paga o boleto. 5 O sistema confirma o pagamento. UC003 Pagar DVD com carto Fluxo Principal 1 O cliente seleciona a opo de pagamento com carto 2 O sistema oferece as opes de carto. 3 O cliente entra com as informaes do carto. 4 O sistema envia a solicitao para a operadora de carto. 5 O sistema confirma o pagamento. 3.1 Carto invlido 3.1.1 Sistema solicita que cliente procure a agncia. 3.1.2 Cliente fecha o sistema sem realizar a locao. 4.1 Operadora de carto no autoriza. 4.1.1 Sistema retorna ao passo 2 ou encerra.

UC004 Ator: Cliente

Manter Cliente Locador

Fluxo Principal: 1. O Cliente inicia o caso de uso selecionando Cadastrar Cliente; 2. O Sistema oferece as opes de incluso e alterao dos dados; 3. O Cliente escolhe incluso e entra com as informaes (nome, RG, CPF, endereo completo, telefone, email, login e senha) e seleciona salvar; 4. O Sistema informa que as informaes foram salvas e encerra. Fluxos Alternativos: 59

2.1 Alterar Dados 2.1.1 O Cliente seleciona a opo para alterar os seus dados; 2.1.2. O Sistema solicita login e senha e valida-as; 2.1.3 O Sistema oferece as informaes dele para alterao; 2.1.4 O cliente faz as alteraes, salva-as e encerra. Fluxos de Exceo: 3.1 Dados incompletos 3.1.1 O sistema informa que possuem dados obrigatrios que ainda no foram preenchidos; 3.1.2 O sistema permanece no passo 3, indicando os campos que devem ser preenchidos 3.2 Login j existe 3.2.1 O sistema informa que aquele login informado j existe; 3.2.2 O sistema permanece no passo 3, indicando o campo de login para novamente ser preenchido. 3.2 Formato incorreto de senha 3.2.1 O sistema informa que a senha deve seguir o formato informado; 3.2.2 O sistema permanece no passo 3, indicando o campo de senha para novamente ser preenchido.

Elaborao Cada ciclo iterativo dentro do processo unificado consiste em elaborao e construo. A fase de elaborao inicia-se com uma subfase de anlise e prossegue com a subfase de projeto. A fase de construo divide-se em implementao e teste do cdigo produzido. A subfase de anlise comporta trs atividades, na ordem: Expanso dos casos de uso e determinao a) Dos eventos de sistema. b) Construo de modelo conceitual. c) Elaborao dos contratos das operaes de sistema. A expanso dos casos de uso foi analisada em tpicos anteriores para no haver falta de seqncia no contedo.
4.2 4.2.1

Projeto da Arquitetura Geralmente nossos clientes querem um novo sistema porque ainda no existe um sistema ou porque h aspectos indesejveis no sistema antigo. Em ambos os casos, os documentos de requisitos nos informam sobre o problema que o sistema deve resolver. O projeto o processo criativo de transformar o problema em uma soluo; a descrio de uma soluo tambm chamada de projeto. O projeto arquitetural especifica uma soluo particular. Utilizamos a especificao dos requisitos para definir o problema. Depois, declaramos que determinada soluo adequada a um problema, se ela satisfizer a todos os requisitos da especificao. Existem diversos paradigmas de projeto de arquitetura de software, a utilizao depende do tipo de projeto que ser desenvolvido, alguns exemplos so: - Projeto de software Orientado a Componentes; - Projeto de software em Tempo Real; - Projeto de software Orientado a Aspectos; - Projeto de software Orientado a Servios; - Projeto de software Orientado a Agentes; - Projeto de software Orientado a Objetos. Utilizaremos o paradigma da Orientao a Objetos pelo fato deste ainda ser o mais utilizado na maioria dos sistemas e por sua flexibilidade.

4.2.1.1 Projeto de software Orientado a Objetos A orientao a objetos, tambm conhecida como Programao Orientada a Objetos (POO) ou ainda em ingls Object-Oriented Programming (OOP) um paradigma de anlise, projeto e programao de sistemas de software baseado na composio e interao entre diversas unidades de software chamadas de objetos. Em alguns contextos, prefere-se usar modelagem orientada ao objeto, em vez de programao. 60

A anlise e projeto orientados a objetos tm como meta identificar o melhor conjunto de objetos para descrever um sistema de software. O funcionamento deste sistema se d atravs do relacionamento e troca de mensagens entre estes objetos. Na programao orientada a objetos, implementa-se um conjunto de classes que definem os objetos presentes no sistema de software. Cada classe determina o comportamento (definidos nos mtodos) e estados possveis (atributos) de seus objetos, assim como o relacionamento com outros objetos. Smalltalk, Python, Ruby, C++, Object Pascal, Java e C# so exemplos de linguagens de programao orientadas a objetos. Perl (a partir do 5), PHP (a partir do 4.0), ColdFusion, Javascript, ActionScript e VB.NET so exemplos de linguagens de programao com suporte a orientao a objetos. Nessa aopostila utilizaremos Java quando precisarmos demostrar o cdigo.

4.2.1.1.1 Conceito e exemplo de classe Em software orientado a objetos, possvel ter muitos objetos do mesmo tipo que tem caractersticas em comum. Um modelo de software para objetos chamado de classe. A definio de classes e seus inter-relacionamentos o principal resultado da etapa de projeto de software. Em geral, esse resultado expresso em termos de alguma linguagem de modelagem, tal como UML. Uma classe um gabarito para a definio de objetos. Atravs da definio de uma classe, descreve-se que propriedades ou atributos o objeto ter. A definio de uma classe descreve tambm qual o comportamento de objetos da classe, ou seja, que funcionalidades podem ser aplicadas a objetos da classe. Essas funcionalidades so descritas atravs de mtodos. Um mtodo nada mais que o equivalente a um procedimento ou funo, com a restrio que ele manipula apenas suas variveis locais e os atributos que foram definidos para a classe. Uma vez que estejam definidas quais sero as classes que iro compor uma aplicao, assim como qual deve ser sua estrutura interna e comportamento, possvel criar essas classes em Java. Na Unified Modeling Language (UML), a representao para uma classe no diagrama de classes tipicamente expressa na forma grfica, como mostrado na Figura 27. Como se observa nessa figura, a especificao de uma classe composta por trs regies: o nome da classe, o conjunto de atributos da classe e o conjunto de mtodos da classe.

NomeClasse visibilidade nomeAtributo : tipo = valor default visibilidade nomeAtributo : tipo = valor default visibilidade nomeMtodo(listaArgumentos) : tipoRetorno visibilidade nomeMtodo(listaArgumentos) : tipoRetorno

Figura 27 - Uma classe em UML

O nome da classe um identificador para a classe, que permite referenci-la posteriormente por exemplo, no momento da criao de um objeto. O conjunto de atributos descreve as propriedades da classe. Cada atributo identificado por um nome e tem um tipo associado. Em uma linguagem de programao orientada a objetos pura, o tipo o nome de uma classe. Na prtica, a maior parte das linguagens de programao orientada a objetos oferecem um grupo de tipos primitivos, como inteiro, real e caractere, que podem ser usados na descrio de atributos. O atributo pode ainda ter um valor_default opcional, que especifica um valor inicial para o atributo. Os mtodos definem as funcionalidades da classe, ou seja, o que ser possvel fazer com objetos dessa classe. Cada mtodo especificado por uma assinatura, composta por um identificador para o mtodo (o nome do mtodo), o tipo para o valor de retorno e sua lista de argumentos, sendo cada argumento identificado por seu tipo e nome. O modificador de visibilidade pode estar presente tanto para atributos como para mtodos. Em princpio, trs categorias de visibilidade podem ser definidas: -pblico, denotado em UML pelo smbolo +: nesse caso, o atributo ou mtodo de um objeto dessa classe pode ser acessado por qualquer outro objeto (visibilidade externa total);

61

-privativo, denotado em UML pelo smbolo -: nesse caso, o atributo ou mtodo de um objeto dessa classe no pode ser acessado por nenhum outro objeto (nenhuma visibilidade externa); -protegido, denotado em UML pelo smbolo #: nesse caso, o atributo ou mtodo de um objeto dessa classe poder ser acessado apenas por objetos de classes que sejam derivadas dessa atravs do mecanismo de herana. Sintaxe em Java: Obs. Utilizaremos durante toda a apostila, as cores padro da IDE Eclipse para nossos cdigos fonte, para tornar o cdigo mais claro e intuitivo. nomeClasse { // declara o nome da classe e abre seu escopo } // fecha a classe encerrando seu escopo Os programas fonte Java so formados por espao em branco, identificadores, comentrios, literais, operadores, separadores e palavras-chave.

4.2.1.1.2 Conceito de Objeto Um objeto uma abstrao de software que pode representar algo real ou virtual. Um objeto formado por um conjunto de variveis/atributos e mtodos relacionados. As variveis/constantes (atributos) possuem um tipo, que define os possveis valores que a varivel pode representar, como um nmero inteiro, nmero real ou string. Os mtodos so rotinas que, quando executadas, realizam alguma tarefa, como alterar o contedo de uma varivel do objeto. O objeto automvel possui propriedades (dados/variveis/atributos/estado), como velocidade, nmero de portas e limite de passageiros. O objeto automvel tambm possui procedimentos (cdigo/mtodos/comportamento), como ligar, desligar, acelerar e parar. Ex. de Objeto Bicicleta As bicicletas tm estado (marcha atual, ritmo atual, duas rodas, nmero de marchas) e o comportamento (freando, acelerando, diminuindo a velocidade, mudando de marcha). Um objeto mantm seu estado em uma ou mais variveis/constantes. Um objeto implementa seu comportamento com mtodos. Um objeto tambm chamado de instncia de classe. Sintaxe para a criao de um objeto em Java: NomeDaClasse objeto = new NomeDaClasse(); Declaramos um objeto (nomeObjeto) do tipo da classe (NomeClasse), o operador new aloca memria para o objeto, e novamente o nome da classe seguido de parnteses ( ) especifica o mtodo construtor da classe. Sintaxe para a utilizao de um objeto: Os objetos interagem e comunicam-se com outros emitindo mensagens a eles. Os objetos fazem o que se chama de troca de mensagens, atravs de chamada a um mtodo ou atributo. objeto.mtodo(); objeto.atributo;

Diagrama em UML

62

Figura 28 - Diagrama das Classes Cliente e Principal

Cdigo Java import javax.swing.JOptionPane; public class Cliente { String nome; String cpf;

public void inicializaCliente(String cpf, String nome) { this.cpf = cpf; this.nome = nome; } public void imprimeDados() { JOptionPane.showMessageDialog(null, "NOME: " + nome + "\n CPF: " + cpf); } }

public class Principal { public static void main(String[] args) { Cliente cli = new Cliente(); cli.inicializaCliente("Angelina Jolie", "71254862900"); cli.imprimeDados(); } } 4.2.1.1.3 Encapsulamento O encapsulamento o mecanismo que permite agrupar em uma nica entidade o cdigo e os dados que esse cdigo manipula. Tais elementos ficam assim protegidos contra interferncias externas e utilizao inadequada. Linguagens orientadas a objetos fornecem as facilidades do encapsulamento que apresentam o usurio de um objeto com uma coleo de interfaces externas. Estas interfaces dizem que pedidos o objeto responder (ou na terminologia da orientao do objeto, quais objetos compreender).

63

Palavra-chave this

Pelo fato de Java ser uma linguagem totalmente orientada a objetos, muitas vezes pode surgir a necessidade de um mtodo precisa fazer uma referncia prpria instncia do objeto que o contm. Java viabiliza isso com o uso da palavra-chave this. This pode ser usada dentro de qualquer mtodo para referir-se ao objeto atual. Ou seja, this sempre uma referncia ao objeto para o qual o mtodo foi invocado. this pode ser usado em qualquer lugar em que uma referncia a um objeto do tipo da classe atual permitida.

import javax.swing.JOptionPane; public class SemThis { int a, b; void exibe(int a, int b){ a=a; b=b; int c = a + b; JOptionPane.showMessageDialog(null,"soma =" + c); } } confuso? import javax.swing.JOptionPane; public class ComThis { int a, b; void exibe(int a, int b){ this.a=a; this.b=b; int c = a+ b; JOptionPane.showMessageDialog(null,"soma =" + c); } }
Mtodos getters e setters

O acesso aos atributos privados so feitos por mtodos get/set. Na maioria dos casos, declara-se os atributos como private e os mtodos get e set como public, onde os mtodos get() armazenam o valor dos atributos e os set() alteram seu valor; por exemplo:

Diagrama em UML

64

Figura 29 - Diagrama de classe com encapsulamento

Cdigo Java import javax.swing.JOptionPane; public class Cliente { private String nome; private String cpf; public Cliente(String nome, String cpf) { this.setCpf(cpf); this.setNome(nome); } public void imprimeDados() { JOptionPane.showMessageDialog(null, "NOME: " + this.getNome() + "\n CPF: " + this.getCpf()); } public String getNome() { return nome; } public void setNome(String nome) { this.nome = nome; } public String getCpf() { return cpf; } public void setCpf(String cpf) { this.cpf = cpf; } }

65

import javax.swing.JOptionPane; public class Principal { public static void main(String[] args) { Cliente cli = new Cliente("Angelina Jolie", "71254862900"); cli.imprimeDados(); cli.setNome("Antonio Banderas"); JOptionPane.showMessageDialog(null, "NOME: " + cli.getNome()); } }
Modificadores de Acesso:

Java oferece quatro especificadores de acesso: . public private protected default

O especificador de acesso protected aplica-se somente quando h envolvimento de herana. Quando um membro de uma classe modificado pelo especificador public, esse membro pode ser acessado por qualquer parte do cdigo do programa. Quando um membro de uma classe especificado como private, esse membro somente pode ser acessado por outros membros de sua classe. Esse o motivo porque main() sempre precedido pelo especificador de acesso public. Ele chamado por cdigo que est fora do programa, qual seja, o sistema runtime de Java. Quando nenhum especificador de acesso usado, ento por default o membro de uma classe public dentro de seu prprio package, mas no pode ser acessado fora de seu package. O conceito de package ser discutido em outro ponto deste curso. Nas classes desenvolvidas at agora, todos os membros de uma classe usaram o modo de acesso default, que por enquanto, podemos considerar equivalente a public. Porm para ser fiel aos princpios de orientao a objetos, normalmente no isso que se deseja. Geralmente, desejvel restringir o acesso aos membros de dados de uma classe. Idealmente, esse acesso somente deve ser possvel atravs de mtodos. Tambm h ocasies em que interessante definir mtodos que so private, sendo acessveis somente para a prpria classe. Um especificador de acesso aparece no incio da linha, antes do tipo de um membro. Em conjunto, os vrios recursos de Java para essa finalidade proporcionam ao programador um fino controle sobre o acesso e a visibilidade de variveis e mtodos dentro de classes, sub-classes e packages. Tanto as classes quanto os packages funcionam como formas de encapsular e conter o espao de nomes e o escopo de variveis e mtodos. Os packages funcionam como repositrios de classes e tambm de outros packages. As classes funcionam como repositrios de dados e cdigo. A classe a menor unidade de abstrao de Java. Levando em conta as classes e os packages, podemos definir quatro nveis de visibilidade para os membros das classes: Subclasses do mesmo package No-subclasses do mesmo package Subclasses em packages diferentes Classes que no so subclasses nem esto no mesmo package

Os especificadores de acesso private, public e protected proporcionam as formas necessrias para a criao dos vrios nveis de acesso exigidos por essas categorias. A tabela abaixo resume todas as possibilidades: 66

private Mesma classe Subclasse do mesmo package Sim No

Sem modificador Sim Sim

protected Sim Sim

public Sim Sim

No-subclasse do mesmo package

No

Sim

Sim

Sim

No Subclasse de outro package No-subclasse de outro package No

No No

Sim No

Sim Sim

Embora esse mecanismo de controle de acesso possa parecer complicado, podemos deduzir algumas regras simples da tabela acima: aquilo que declarado public pode ser acessado em qualquer lugar (ltima coluna da tabela) aquilo que declarado private no pode ser visto fora de sua classe (primeira coluna da tabela) Quando no h um especificador de acesso, o membro visvel para as subclasses e para as outras classes do mesmo package (segunda coluna); este o chamado acesso default protected permite que um membro seja visvel para as subclasses, dentro ou fora do mesmo package (terceira coluna) A tabela e as regras acima aplicam-se aos membros das classes. As classes propriamente ditas tm somente dois nveis de acesso: default: acessvel somente dentro de seu package public: acessvel por qualquer outro cdigo

Eis alguns exemplos: public int intVar; private double dVar; private int umMetodo(int i, char ch) { // . . .

4.2.1.1.4 Polimorfismo O termo polimorfismo, etimologicamente, quer dizer "vrias formas"; todavia, na Informtica, e em particular no universo da OOP, definido como sendo um cdigo que possui "vrios comportamentos" ou que produz "vrios comportamentos"; em outras palavras, um cdigo que pode ser aplicado vrias classes de objetos.
Overload Sobrecarga de mtodos

Java permite definir dois ou mais mtodos dentro da mesma classe utilizando o mesmo nome, desde que suas declaraes de parmetros sejam diferentes. Esse procedimento conhecido como sobrecarga de mtodos (method overload). Dizemos que os mtodos esto sendo sobrecarregados (overloaded). A sobrecarga de mtodos uma das formas de implementar o polimorfismo. Inicialmente, o conceito da sobrecarga pode parecer estranho. Mas veremos que a sobrecarga de mtodos um dos recursos mais interessantes e poderosos de Java. Quando um mtodo sobrecarregado chamado, Java utiliza o tipo e o nmero dos argumentos como um guia para determinar qual verso do mtodo sobrecarregado deve ser de fato executada. Por isso, mtodos sobrecarregados devem diferir no tipo ou no nmero de seus parmetros (ou em ambos, tipo e nmero). 67

Embora mtodos sobrecarregados possam retornar tipos diferentes, somente o tipo retornado no suficiente para fazer a distino entre duas verses de um mtodo. Quando Java encontra uma chamada a um mtodo sobrecarregado, o ambiente executa a verso do mtodo cujos parmetros casam com os argumentos passados na chamada. O exemplo abaixo ilustra a sobrecarga de mtodos: Diagrama em UML

Figura 30 - Diagrama de classe com polimorfismo

Cdigo Java import javax.swing.JOptionPane; public class Cliente { private String nome; private String cpf; public Cliente(String nome, String cpf) { this.setCpf(cpf); this.setNome(nome); } public void imprimeDados() { JOptionPane.showMessageDialog(null, "NOME: " + this.getNome() + "\n CPF: " + this.getCpf()); }

public double realizarPagamento(double valor){ JOptionPane.showMessageDialog(null,valor); return valor; } public double realizarPagamento(double valor, double desconto){ double total = valor - desconto; 68

JOptionPane.showMessageDialog(null,total); return total; } public double realizarPagamento(double valor, double acrscimo, double multa){ double total = valor - (acrscimo + multa); JOptionPane.showMessageDialog(null,total); return total; }

public String getNome() { return nome; } public void setNome(String nome) { this.nome = nome; } public String getCpf() { return cpf; } public void setCpf(String cpf) { this.cpf = cpf; } }

import javax.swing.JOptionPane; public class Principal { public static void main(String[] args) { Cliente cli = new Cliente("Angelina Jolie", "71254862900"); cli.imprimeDados(); cli.setNome("Antonio Banderas"); JOptionPane.showMessageDialog(null, "NOME: " + cli.getNome()); cli.realizarPagamento(560.50); cli.realizarPagamento(500,50); cli.realizarPagamento(500,50,50); } } 4.2.1.1.5 Associao Uma associao um relacionamento simples entre as classes, um relacionamentos binrios, como o nome indica acontece entre duas classes, representada por uma linha slida entre elas. Esse tipo de relacionamento o mais comum em uma aplicao voltada para comrcios e servios. As associaes podem ser unidirecionais ou bidirecionais, a bidirecional mostrada como uma linha simples (ou com duas pontas), a unidirecional mostrada com uma seta em uma das extremidades. Uma associao unidirecional implica um objeto da classe partir do qual est originado (por exemplo, a classe que tem o lado sem seta da associao) pode chamar os mtodos na classe na direo a qual a seta est apontando. No Java, isso representado como uma varivel de instncia na classe que pode chamar os mtodos. Cada extremidade da associao um papel na terminologia UML e pode ser nomeada, da perspectiva da implementao no Java, os papis podem ser definidos com os nomes das variveis de instncia nas respectivas classes. Geralmente ser til nomear um papel se ele adicionar valor compreenso do modelo. No exemplo da figura 31 titular o nome de um dos papis e na figura 32 temos os papis titular, agencia e conta. 69

A figura 31 mostra um exemplo de associao unidirecional.

Figura 31 - Associao unidirecional entre classes

Cdigo Java public abstract class Conta { ... private Cliente titular; ... Observe que dentro da classe Conta h uma referncia a classe Cliente, ou seja um atributo (chamado titular) que faz referncia a classe Cliente. A maioria das associaes do tipo unidirecional, mas possvel que algumas associaes sejam bidirecionais. Uma associao bidirecional significa que qualquer um dos objetos na associao pode chamar os mtodos na outra. No Java isso resulta em uma varivel de instncia em cada classe com base no tipo da outra classe. Um exemplo de associao bidirecional mostrado na figura 32.

70

Figura 32 - Associao bidirecional entre classes

Cdigo Java public abstract class Conta { ... private Agencia agencia; ...

public ...

class Agencia {

private Conta conta ; ... Observe que tanto dentro da classe Conta quanto na classe Agencia existem atributos que referenciam a classe associada, nesse caso representamos a associao bidirecional em Java. Multiplicidade (Cardinalidade) A multiplicidade mostra quantos objetos uma classe pode possuir e por quantos objetos uma classe possuda. o nmero de instncias de uma classe relacionada com uma instncia de outra classe. Para cada associao, h uma multiplicidade em cada direo. A notao usada pela UML, para os indicadores de multiplicidade, : Muitos Apenas Um Zero ou Muitos Um ou Muitos Zero ou Um Intervalo Especfico * 1 0..* 1..* 0..1 2..4

A navegabilidade mostra, explicitamente, de quem a responsabilidade de obter as informaes. 71

Em termos de implementao Java, a multiplicidade representada como uma varivel de instncia com diversos valores. Por exemplo, suponha que uma empresa empregue vrias pessoas e uma pessoa possa trabalhar para um mximo de trs empresas. Para a multiplicidade de variveis sem um limite superior fixo isso pode se traduzir em uma coleo representando as pessoas que trabalham para uma nica empresa. Para a pessoa que trabalha para trs empresas diferentes, isso resultaria em um array de trs elementos. A figura 33 mostra um relacionamento com multiplicidade entre cliente, conta e agencia. Onde um cliente tem uma ou mais contas, e uma agncia possui uma ou vrias contas.

Figura 33 Multiplicidade

Cdigo Java public abstract class Conta { ... private Agencia agencia; ...

public ...

class Agencia {

private conta (Collection<Conta>); ...

public abstract class Cliente { ... private conta[ ] Titular; ...

Estrutura todo-parte 72

Estruturas todo-parte so representadas por de uma associao chamada de agregao, que pode ser de dois tipos: agregao e agregao por composio, chamaremos esse ltimo de composio. Agregao A agregao a forma mais forte de uma associao. usada para mostrar uma relao de incluso lgica, ou seja, um inteiro formado por partes. Embora as partes possam existir independente do todo, sua exigncia basicamente para formar o todo. Por exemplo um computador pode ser modelado como uma agregao de uma placa me, por exemplo, pois ela pode existir de modo independente (como em uma loja); porm, sua existncia no contexto do todo mais apropriada. A agregao modelada como uma associao com um losango vazado na classe que forma o todo. Como uma associao, uma agregao suporta o conceito de papis e multiplicidade. Em termos de implementao no Java, uma agregao mapeia as variveis de instncia de uma classe. A figura 34 mostra um exemplo de agregao entre as classes Banco e Agencia, onde o banco o todo, ou seja formado por vrias agncias.

Figura 34 - Agregao entre duas classes

Cdigo Java public abstract class Banco { ... private Agencia agencia[ ]; ...

public ...

class Agencia {

private Banco banco; private conta (Collection<Conta>); ... 73

Composio A composio a outra forma de associao e parecida com a agregao at certo grau, porm menos ambgua. Implica em um acoplamento muito mais forte do todo com a parte entre os participantes de modo que as partes no possam existir sem o todo. Ou seja, as partes compartilham o cliclo de vida do todo. So criadas quando o todo criado e destrudas quando o todo deixar de existir. Como revista e artigo; time e atletas; nota fiscal e itens de nota fiscal. A composio mostrada da mesma maneira que a agregao, exceto que o losango preenchido. Em termos de implementao no Java, segue a mesma regra da agregao. A figura 35 mostra um exemplo de composio, onde a classe ItensFaturaCartao fortemente dependente da classe FaturaCartao, se a fatura deixar de existir os itens tambm deixaro.

4.2.1.1.6 Herana O conceito de herana permite definir uma nova classe, com base em uma j existente. A classe criada (subclasse ou classe derivada) automaticamente herda todas as variveis e mtodos da classe j existente (superclasse). O mecanismo de herana permite ainda que a subclasse inclua ou sobreponha novas variveis e mtodos da superclasse (especializa/generalizao). 4.2.1.1.7 Superclasse e subclasse Os sistemas orientados a objetos fazem isso como uma etapa adicional e permitem que as lasses sejam definidas nos termos de outras classes. Chamamos de superclasse a classe da qual estamos herdando e de subclasse aquela classe que est herdando de outra classe(superclasse) 4.2.1.1.8 Overriding superposio de mtodos Superposio de mtodos (method overriding), um procedimento que lembra a sobrecarga, mas que tem algumas diferenas fundamentais. Dizemos que um mtodo de uma subclasse se superpe (overrides) a um mtodo de uma superclasse quando o mtodo da subclasse tem a mesma assinatura , ou seja: retorna o mesmo tipo tem o mesmo nmero e os mesmo tipos de parmetros tem o mesmo nome

74

Quando o mtodo superposto chamado de dentro da subclasse, a verso executada sempre aquela definida na subclasse. A verso do mtodo definida na superclasse fica oculta; por isso dizemos que o mtodo da subclasse se superpe ao da superclasse.

Diagrama em UML

Figura 35 - Diagrama de classe com herana

Cdigo Java import javax.swing.JOptionPane; public class Cliente { public static int PESSOA_JURIDICA; public static int PESSOA_FISICA; private String nome; private String cpf; private int categoria; public Cliente(String nome, String cpf, int categoria) { this.setCpf(cpf); this.setNome(nome); this.setCategoria(categoria); } public void imprimeDados() { String cat = ""; if (categoria == PESSOA_FISICA){ 75

cat = "Pessoa fisica"; } else{ cat = "Pessoa juridica"; } JOptionPane.showMessageDialog(null, "NOME: " + this.getNome() + "\n " + "CPF:" + this.getCpf()+ "\n " + "Categoria:" + cat); }

public String getNome() { return nome; } public void setNome(String nome) { this.nome = nome; } public String getCpf() { return cpf; } public void setCpf(String cpf) { this.cpf = cpf; } public int getCategoria() { return categoria; } public void setCategoria(int categoria) { this.categoria = categoria; } }

import javax.swing.JOptionPane; public abstract class Conta { private double saldo; private String numero; private Cliente titular; Conta(String numero, Cliente titular) { this.numero = numero; this.titular = titular; } Conta(double saldo, String numero, Cliente titular) { this(numero, titular); this.saldo = saldo; } public abstract void saque(double valor);

void deposito(double valor) { if(valor > 0){ 76

} positivo!"); } }

saldo = saldo + valor; else { JOptionPane.showMessageDialog(null,"Valor do deposito deve ser

void imprimeDados() { JOptionPane.showMessageDialog(null, "\n" + "NUMERO: "+numero + "\n" + "SALDO: "+saldo); } public String getNumero() { return numero; } public double getSaldo() { return saldo; } public void setSaldo(double saldo) { this.saldo = saldo; } public Cliente getTitular() { return titular; } public void setTitular(Cliente titular) { this.titular = titular; } }

import javax.swing.JOptionPane; public class ContaEspecial extends Conta{ private double limite; public ContaEspecial(double saldoInicial, String numero, Cliente titular, double limite) { super(saldoInicial, numero, titular); this.limite = limite; } public ContaEspecial(String numero, Cliente titular, super(numero, titular); this.limite = limite; } public void imprimeDados() { double saldoTotal = getSaldo()+limite; JOptionPane.showMessageDialog(null, "CONTA ESPECIAL com limite de R$ "+limite); //super.imprimeDados(); JOptionPane.showMessageDialog(null, "Saldo Total: "+saldoTotal); } public void saque(double valor) { 77 double limite) {

double saldoTotal = getSaldo() + limite; JOptionPane.showMessageDialog(null,"Realizando saque de R$ " + valor + " da conta " + getNumero()); if (valor > 0) { if (saldoTotal >= valor) { setSaldo(getSaldo() - valor); } else JOptionPane.showMessageDialog(null,"Saldo insuficiente"); } else { JOptionPane.showMessageDialog(null,"O valor de saque deve ser positivo"); } } public double getLimite() { return limite; } public void setLimite(double limite) { this.limite = limite; } }

import javax.swing.JOptionPane; public class ContaPoupanca extends Conta { private String dataAniversario; double limite = 500; public ContaPoupanca(double saldoInicial, String numero, Cliente titular, String dataAniversario) { super(saldoInicial, numero, titular); this.dataAniversario = dataAniversario; } public ContaPoupanca(String numero, Cliente titular, String dataAniversario) { super(numero, titular); this.dataAniversario = dataAniversario; } public void saque(double valor) { double saldoTotal = getSaldo() + limite; JOptionPane.showMessageDialog(null,"Realizando saque de R$ " + valor + " da conta " + getNumero()); if (valor > 0) { if (saldoTotal >= valor) { setSaldo(getSaldo() - valor); } else JOptionPane.showMessageDialog(null,"Saldo insuficiente"); } else { JOptionPane.showMessageDialog(null,"O valor de saque deve ser positivo"); 78

} } public String getDataAniversario() { return dataAniversario; } public void setDataAniversario(String dataAniversario) { this.dataAniversario = dataAniversario; }

public void imprimeDados() { JOptionPane.showMessageDialog(null, "CONTA POUPANCA"); JOptionPane.showMessageDialog(null, "Data de Aniversario: " + dataAniversario); super.imprimeDados(); } }

import javax.swing.JOptionPane; public class Principal { public static void main(String[] args) { Cliente cli = new Cliente("Angelina Jolie", "71254862900", 1); ContaEspecial ce = new ContaEspecial("12345", cli, 1500); cli.imprimeDados(); cli.setNome("Antonio Banderas"); JOptionPane.showMessageDialog(null, "NOME: " + cli.getNome()); ce.deposito(500); ce.saque(100); ce.imprimeDados(); } }
4.2.2

Modelagem conceitual

O modelo conceitual uma representao da viso que o usurio tem das informaes gerenciadas pelo sistema. 4.2.2.1 Elementos bsicos do Modelo Conceitual O modelo conceitual representa somente o aspecto esttico da informao. Dessa maneira, no podem existir no modelo conceitual referncias a operaes ou aspectos dinmicos do sistema. Quando se trabalha modelagem conceitual com diagramas de classes da UML, existem precisamente trs elementos para representar informao: a) Conceitos- que so representados por classes. Conceitos na modelagem conceitual so a representao da informao complexa, que no pode ser descrita meramente por tipos alfanumricos. Exemplos de conceitos no sistema de videolocadora so: fita, cliente, emprstimo e reserva. b) Atributos - so informaes alfanumricas diretamente ligadas aos conceitos. Exemplos de atributos no sistema de videolocadora so: idade do cliente, data do pagamento, nome do filme e endereo do cliente. c) Associaes muitas vezes so pouco compreendidas e consistem em um tipo de informao que liga diferentes conceitos entre si. Porm, a associao mais do que uma mera ligao: ela prpria um tipo de informao conceitual importante. Exemplos de associaes so 79

 dono de entre uma pessoa e seu automvel, contraiu entre um cliente e um emprstimo, emprega entre uma empresa e um grupo de funcionrios. 4.2.2.2 Como encontrar conceitos e atributos O processo de descoberta dos elementos pode variar conforme o mtodo. Porm, uma forma til, quando se trabalha com ciclos iterativos, olhar para os textos da descrio dos casos de uso (fluxos/cenrios). A partir desse texto deve-se tentar descobrir todos os elementos textuais que eventualmente referenciam informao a ser guardada e/ou processada. Em geral esses elementos textuais so compostos por substantivos, como pessoa, emprstimo, conta, etc., ou por expresses que denotam substantivos, como item de locao, autorizao de pagamento, etc. Alm disso, no texto, algumas vezes certos verbos podem indicar conceitos, pois o verbo pode exprimir um ato que corresponde a um substantivo, como por exemplo: pagar, que corresponde ao substantivo pagamento, devolver que corresponde ao substantivo devoluo, etc. O processo de identificao dos conceitos e atributos, ento, consiste em: a) Identificar no texto dos casos de uso as palavras ou sintagmas que correspondem a conceitos sobre os quais se tem interesse em manter a informao do sistema. b) agrupar as palavras ou expresses que so sinnimos, como por exemplo, emprstimo e locao, cliente e pessoa que faz locao, etc. c) Identificar quais dos itens considerados correspondem a conceitos complexos e quais deles so meros atributos. Os atributos so aqueles elementos que podem ser considerados alfanumricos, usualmente: nomes, nmeros em geral, cdigos, datas, valores em moeda, valores booleanos (verdadeiro ou falso) etc. Ainda considerando alguns objetos do mundo real como, por exemplo, pessoa possui altura, peso, cor dos olhos, etc. Um computador possui fabricante (Dell, Sun, Apple, IBM, etc.) tipo de tela, tamanho da memria, do disco, etc. Identificamos muitos atributos das classes de nosso sistema procurando palavras e frases descritivas nos cenrios, para cada uma que desempenha um papel significativo no sistema, criamos um atributo e o atribumos a uma ou mais classes identificadas.

80

Ao analisar cada um dos termos identificados nos fluxos, pode-se chegar as seguintes concluses: a) Cliente: um conceito importante e complexo. b) Balco: um conceito complexo, mas possivelmente fora do escopo das informaes que o sistema vai gerenciar. c) Fitas: um conceito importante e complexo. Embora as fitas sejam referenciadas no plural nesse exemplo, o conceito deve ser identificado no singular: Fita. d) Locar ou locao: um conceito importante e complexo. o Mesmo que emprstimo. e) Nome ou nome do cliente um atributo do cliente. f) Funcionrio: um conceito complexo, mas, ao observar os objetivos do sistema (requisitos), no h nenhuma referncia sobre gerenciamento da informao de funcionrios. Se no existe a necessidade de armazenar informaes sobre funcionrios no sistema, ento no h tambm a necessidade de representar esse conceito. g) Data de devoluo: atributo da locao. Poderia ser atributo da fita? No porque a cada locao que uma fita participa poder corresponder uma data de devoluo diferente. h) Valor da locao: atributo do emprstimo. i) Cadastro ou dados para cadastro: meramente outra forma de se referenciar ao cliente e seus atributos. j) Pendncias: apenas um sinnimo para dbito. k) Dbito: um conceito importante. Caso seja necessrio manter um histrico de dbitos, que poderia ser um conceito complexo associado ao cliente. Se apenas a existncia ou no de um dbito no momento atual for necessrio, saber o dbito poder ser apenas um atributo do cliente. l) Quitao de dbito. Se o dbito for um conceito complexo, a quitao poder ser um de seus atributos, ou mesmo um conceito complexo associado. Caso contrrio a quitao ser apenas uma operao que consiste em zerar o dbito. 81

m) Paga: atributo de emprstimo. n) Fita reservada: conceito complexo reserva, pois um reserva feita para um cliente, por um prazo, etc. o) Fita danificada: um atributo de fita, cujo valor inicial sempre falso. p) Fita disponvel: disponvel ser um atributo booleano da fita. q) Filme: aparentemente um sinnimo de fita. O resultado dessa anlise pode ser transportado para um diagrama de classes UML, como um enriquecimento do modelo conceitual definido na fase de concepo.

4.2.2.3 Classe controladora do Sistema Deve-se adicionar ao diagrama uma classe que representa o sistema como um todo. A essa classe so associados todos os conceitos independentes, correspondentes aos cadastros do sistema. Cliente e Fita so elementos a serem cadastrado quando da operao do sistema. J Emprstimo e Reserva no so cadastros, mas elementos associados aos clientes e fitas j cadastrados. Assim. O diagrama com a incluso da classe controladora ficaria assim:

Figura 19 - Diagrama de classes UML com classe controladora 4.2.2.4 Associaes A informao correspondente aos conceitos e atributos pode ser facilmente encontrada no texto dos casos de uso, porm o mesmo no ocorre com as associaes. Associao versus Operao 82

Os casos de uso mencionam associaes com pouca freqncia. Como os casos de uso descrevem aes de interao entre usurios e o sistema, ento a sua descrio acaba mencionando as operaes. A diferena : a) Associao: relao esttica possvel de existir entre duas classes, complementando a informao que se tem sobre eles em um determinado instante, ou referenciando informao associativa nova. b) Operao: ato de transformar a informao, passando de um estado a outro, recuperando ou modificando o valor dos atributos. Como encontrar associaes Em resumo at aqui foi dito que se deve evitar usar os fluxos como fonte para determinar as associaes, pois esse texto faz mais referncia a operaes e no a associaes. No entanto, como encontrar as associaes entre as classes? A sugesto tentar observar cada classe e se perguntar se a informao representada por ela completa. Se no for, deve-se criar uma associao entre uma classe e outra a fim de complementar a informao necessria para que ela faa sentido. No exemplo da videolocadora o questionamento pode ser respondido assim: a) Cliente: aparentemente uma informao completa, que no necessita de associaes parta se complementar. b) Emprstimo: esta classe no faz sentido, caso no saibamos qual foi o cliente que efetuou o emprstimo e quais foram as fitas emprestadas. Enquanto o Cliente pode ser compreendido independentemente de outras classes, o emprstimo no pode. Assim, necessrio estabelecer associaes entre o emprstimo e o cliente e entre o emprstimo e a fita. c) Fita: tal como a fita, pode ser compreendido sem a necessidade de associao com outros elementos. d) Reserva: uma reserva no faz sentido, caso no saiba qual foi o cliente que a efetuou e qual foi a fita reservada. Logo, necessria a criao de associaes entre a reserva e essas classes. Chamaremos de classes dependentes aquelas que precisam estar ligadas a outras classes para fazer sentido. As demais sero chamadas de independentes. Normalmente, as classes dependentes estaro ligadas a outras classes e as classes independentes estaro ligadas classe controladora do sistema.

4.2.3

Estudo de Caso Locao de DVD pela Internet- Parte 3

83

Figura 36 - Diagrama de Classes do caso de uso Locar DVD Fonte: Desenvolvendo Software com UML 2.0 - Ernani Medeiros 4.2.4

Diviso do software em Camadas A fase de projeto de software visa produzir uma soluo identificada pela anlise. Pode-se dividir a atividade de projeto em diversas tarefas com objetivos distintos. Em primeiro lugar, importante realizar o projeto da camada de domnio do software.

4.2.4.1 Camada de domnio (ou lgica) Pode-se dividir a atividade de projeto em diversas tarefas com objetivos distintos. Em primeiro lugar importante realizar o projeto da camada de domnio do software. Essa camada corresponde ao conjunto de classes que vai realizar toda a lgica do sistema de informao; as demais camadas* persistncia, interface, segurana, etc.) so derivadas ou dependentes da camada de domnio. Nessa fase iremos elaborar o diagrama de classes do projeto, o qual se baseia em primeiro lugar no modelo conceitual adicionado de algumas informaes que no era possvel obter na fase de anlise, como por exemplo, o sentido das associaes e os mtodos a serem implementados. 4.2.4.1.1 Inicializao do Diagrama de classes do Projeto A primeira verso do diagrama de classes de projeto (DCP), construda no primeiro ciclo iterativo, constitui-se de uma cpia do modelo conceitual. Nos ciclos iterativos seguintes, o modelo conceitual sofrer acrscimos. As modificaes bsicas a serem feitas no DCP durante o projeto de camadas de domnio so: a) Adio dos mtodos. b) Adio da direo das associaes, na fase de anlise tnhamos apenas direo de leitura, agora teremos direo de navegao e visibilidade. c) Detalhamento dos atributos, pois na fase de anlise pode ser que nem todos os tipos tenham sido definidos. d) Papis para as associaes. e) Alterao na estrutura das classes e associaes. Pode ser necessrio criar mais classes, ou alterar algumas. f) Criao de atributos privados ou protegidos, no modelo conceitual no nos preocupava, pois estvamos representando apenas a informao e no a representao. 84

As classes do DCP so convertidas em linguagem de programao. Utilizaremos Java em nossos exemplos. Exemplo da representao:

Classes:

class Cliente { };

Criao de uma classe e seu respectivo cdigo Java

class Cliente { private String nome; private Float debito; private Integer idade; }
Criao de uma classe e seus atributos Como as variveis que armazenam os atributos so sempre privadas, a classe deve implementar mtodos para acessar e alterar os valores de seus atributos (get e set). Em hiptese alguma outro mtodo, mesmo sendo da prpria classe poder acessar ou alterar tais variveis diretamente. Isso acontece porque quando o mecanismo de persistncia for implementado, ser necessrio ter controle sobre as alteraes sofridas pelos objetos, para verificar consistncia com o banco de dados.

class Cliente { private String nome; private Float debito; private Integer idade; public void setNome(String nome) { this.nome = nome; } public void setDebito(Float debito) { this.debito = debito; } public void setIdade(Integer idade) { this.idade = idade; } public String getNome() { return nome; } public Float getDebito() { return debito; } public Integer getIdade() { return idade; } }
Criao de uma classe com mtodos para alterar e acessar seus atributos

Gerao de cdigo Uma vez definidos os diagramas de colaborao e o diagrama de classes de projeto, a gerao de cdigo uma tarefa passvel de automatizao. 85

Trata-se aqui de gerar o cdigo das classes correspondentes camada de domnio da aplicao, ou seja, as classes que realizam toda a lgica do sistema a partir das operaes de sistema. As demais camadas (persistncia, interface, etc.) so geradas em outra fase do processo. Pode-se admitir, porm, que, uma vez gerada a camada de domnio, todas as demais camadas sero derivadas e dependentes desta. 4.2.4.2 Camada de Interface Esta camada subdivide-se em duas camadas: a) Apresentao - Classes que representam objetos grficos de interface, s recebem dados e comandos do usurio e retornam resultados a ele. b) Aplicao Controla a lgica da interface, abrindo e fechando janelas, habilitando e desabilitando botes. O prottipo pode auxiliar na identificao de quais janelas compes o sistema e quais eventos permitem ao usurio navegar de uma janela para outra. Utiliza dos casos de uso ou apenas alguns fluxos alternativos. Eventos = boto. 4.2.4.3 Operaes e Consultas do Sistema O texto/descrio dos casos de uso ter basicamente duas utilizaes: -Como fonte de informao para encontrar conceitos para o modelo conceitual (veremos no prximo tpico). -Como fonte de informao para encontrar as operaes e consultas de sistema, as quais originaro os mtodos que fazem a interface do sistema com o mundo externo. Operaes de sistema so mtodos ativados a partir de um evento de sistema, ou seja, como resposta a uma ao de um usurio. As operaes de sistema, por definio indicam um fluxo de informaes do exterior para o interior do sistema, e, portanto elas alteram as informaes gerenciadas pelo sistema. Consultas de sistema so mtodos correspondentes a simples verificao de informao j armazenada. Essa informao pode ser apresentada exatamente como est armazenada, ou modificada pela aplicao de funes (por exemplo: mdia, total, etc.). No entanto, por definio, uma consulta, de sistema no deve ser responsvel por inserir, remover ou alterar informaes armazenadas. Pode-se definir que as operaes e consultas de sistema, em conjunto, correspondem a totalidade das funes possveis do sistema, isto , a funcionalidade total do sistema. Nos casos de uso encontram-se operaes de sistema a partir da observao de aes do usurio que produzem modificaes no sistema, ou seja, aes que levam informaes dos atores para o sistema. As consultas so identificadas por passo que trazem informaes do sistema para os atores.

Operaes

Consultas Figura 25 - Operaes e consultas 4.2.4.4 Ainda identificando operaes Uma operao um servio que os objetos de uma classe fornecem aos usurios da classe. Pense nas operaes de alguns objetos do mundo real como pessoa, andar, falar, estudar, receber salrio, etc. Podemos derivar vrias operaes de cada classe examinando os verbos e frases com verbos-chave nos cenrios, relacionamos ento cada um deles a classes do nosso sistema.

86

4.2.4.5 Identificando parmetros Identificamos os parmetros de uma operao examinando quais dados a operao requer para realizar uma tarefa, por exemplo, andar requer direo e distncia. Figura 26 Seqncia de eventos do diagrama de seqncia do caso de uso emprestar DVD.
4.3

Diagrama de Seqncia da UML

O diagrama de seqncia um dos tipos de diagrama de interao, um diagrama de interao mostra as interaes por meio de uma viso dinmica do sistema. Podendo representar um sistema, subsistema, operao, classe ou fluxos em um caso de uso, sendo a ltima a mais freqente. Ele formado por objetos relacionamentos e mensagens, eles se apresentam na verso 2.0 da UML, de quatro formas: - Diagrama de seqncia - Diagrama de comunicao - Diagrama de viso geral - Diagrama temporal Esses diagramas possuem aspectos que o diferenciam. O diagrama de seqncia enfatiza a seqncia de mensagens dentro de uma linha de tempo, enquanto que o de comunicao enfatiza o relacionamento estrutural entre os objetos, sem se preocupar com o tempo determinado para cada interao. O diagrama de comunicao at a verso 1.4 era conhecido como diagrama de colaborao. O diagrama de seqncia e o de comunicao apresentam diferentes formas de representar a mesma informao. Por exemplo: quando vou ao restaurante Popular sei que nesse local o garom leva 10 minutos para trazer o pedido e eu levo 20 minutos comendo, espero mais 5 minutos pela conta e 5 pelo troco. Quando vou ao restaurante Vip, no me preocupo com o tempo, fao o pedido, o garom traz meu jacar ao molho madeira, como, recebo a conta, pago, pego o troco e saio feliz e saltitante. Assim o restaurante Popular seria semelhante ao diagrama de seqncia, na qual as mensagens so trocadas entre os objetos (nesse caso Cliente e Garom), com demonstrao do tempo de processamento. O restaurante Vip seria semelhante ao diagrama de comunicao, no qual as mensagens so passadas de um objeto a outro sem indicar o tempo de processamento de cada uma. Em nosso exemplo usaremos o diagrama de seqncia para representar a seqncia dos eventos de sistema em um cenrio de um caso de uso. O diagrama de seqncia tem como elementos instncias de atores, representados por figuras humanas esquematizadas, e instncias de objetos constituintes do sistema. O sistema poder ser representado como um nico objeto, porm mais til represent-lo como dois objetos genricos, indicando dois nveis da futura arquitetura. O primeiro objeto representa a interface do sistema, ou classe de aplicao, e o segundo, mais interno, representa o controlador do sistema, classe videolocadora. O ator s pode s pode se comunicar diretamente com a aplicao e esta, por sua vez, comunica-se com o controlador. Cada um desses elementos ter uma linha de tempo, representada pelas linhas verticais, na qual os eventos podem ocorrer. Quando a linha est tracejada, o ator ou sistema est inativo. Quando a linha est cheia, significa que o ator ou sistema est ativo (operando ou esperando o resultado de alguma operao). Aes que devem ser repetidas so envolvidas por um retngulo rotulado com um asterisco (ou esteretipo <<iteration>>). As linhas horizontais representam o fluxo de informao. Existem trs tipos de envio de informao nestes diagramas: a) Entre atores (comunicao entre atores) b) Dos atores para o sistema (eventos de sistema) c) Do sistema para os atores (respostas do sistema) Cada uma das operaes e consultas identificadas dever ser um contrato, e essas operaes, em conjunto, correspondero a toda funcionalidade do sistema. O diagrama de seqncia pode ser construdo para o fluxo principal do caso de uso, e eventualmente tambm para alguns cenrios com fluxos alternativos.

87

Cenrio do caso de uso Emprestar DVD utilizado para extrair a seqncia de eventos

88

Diagrama de seqncia do caso de uso Emprestar DVD

4.3.1.1 Associao de eventos e Respostas de sistema com Operaes e Consultas Definies: a) Evento de sistema: uma ao realizada por um ator que envia alguma informao ao sistema, sendo representada no diagrama por um fluxo de informao do ator para a camada de aplicao. b) Resposta de sistema: informaes que o sistema repassa aos atores, representada no sistema como setas tracejadas do controlador para a aplicao e desta para os atores. c) Operao de sistema: mtodo que o sistema executa internamente em resposta a um evento de sistema. A operao de sistema deve, deve, por definio, alterar alguma informao armazenada. No diagrama um fluxo de aplicao para o controlador que no pode possuir resposta de sistema na seqncia imediata. d) Consulta de sistema: um mtodo cuja execuo faz o sistema retornar alguma informao importante para os atores. As consultas no devem alterar os dados armazenados no sistema e sim exibir esses dados de uma maneira apropriada para o usurio. No diagrama, as consultas so representadas como fluxos da aplicao para o controlador, aos quais se segue imediatamente uma resposta de sistema. e) Comunicao entre atores: no tem efeito direto sobre o sistema. Serve apenas para ilustrar a forma de interao entre dois ou mais atores enquanto realizam um caso de uso. No diagrama a comunicao entre atores representada como fluxos entre os atores. A cada evento do sistema corresponde uma operao de sistema e a cada resposta de sistema corresponde uma consulta de sistema. A forma mais simples de implementao ter apenas um controlador (contolador-fachada), no caso, a classe Videolocadora. Entretanto, possvel ter mais de uma classe controladora; uma para cada caso de uso, por exemplo. Anlise do caso de uso Emprestar DVD com as operaes e consultas associadas a cada passo: a) O cliente chega ao balco com os DVDs que deseja locar. Esse passo apenas descreve informao complementar, sem interao com o sistema. 89

b) O cliente informa o nome e entrega os DVDs ao funcionrio. A interao ocorre entre dois atores. A informao passada o nome do cliente e os DVDs, que possivelmente possuem algum tipo de cdigo impresso nelas. c) O funcionrio registra o nome do cliente e inicia a locao. A ao bsica no sistema o registro do nome (envio de informao): este evento inicia a locao. Logo, pode ser identificado um evento de sistema inicia locao ou identifica cliente como um parmetro que o nome do cliente. A operao de sistema correspondente poder ser anotada como identificaCliente (nome). d) O funcionrio registra cada uma dos DVDs. Aqui existe uma interferncia do ator com o sistema. O funcionrio registra cada uma das DVDs. Seria possvel modelar um evento de sistema registrar DVDs, passando como parmetro uma lista de cdigos ou opcionalmente registrar DVD, passando como parmetro uma lista de cdigos ou opcionalmente registra DVD, passando como parmetro um nico cdigo e assumindo que esse evento de sistema seja executado uma vez para cada DVD a registrar. Para fins de apresentao foi escolhida a segunda opo, e a operao de sistema correspondente fica definida como: emprestarDVD (cdigo). e) O funcionrio finaliza a locao, devolve os DVDs ao cliente e lhe informa a data de devoluo e o valor total da locao. Aqui existem duas situaes. Em primeiro lugar o funcionrio finaliza a locao. O funcionrio no est enviando nenhuma informao alfanumrica para o sistema. Contudo, a indicao de que o emprstimo terminou importante para o sistema produzir o resultado final, o qual consiste nas informaes das datas de devoluo e do valor total da locao. O mais importante nessa linha, porm, o retorno do sistema, que d origem a duas consultas consultaValor () e consultaPrazos (). f) O cliente vai embora com os DVDs. No h interao com o sistema nesse passo. possvel identificar dois tipos fundamentais de eventos de sistema: a) Eventos informativos, que passam dados para o sistema. Assume-se que sero passados sempre dados alfanumricos (nmeros, textos, datas, booleanos, etc.). b) Eventos de controle (por exemplo, eventos que indicam o final de uma seqncia de outros eventos) que no passam dados para o sistema.

4.3.2

Diagrama de sequncia

O diagrama de seqncia um dos tipos de diagrama de interao, um diagrama de interao mostra as interaes por meio de uma viso dinmica do sistema. Podendo representar um sistema, subsistema, operao, classe ou fluxos em um caso de uso, sendo a ltima a mais freqente. Ele formado por objetos relacionamentos e mensagens, eles se apresentam na verso 2.0 da UML, de quatro formas: - Diagrama de seqncia - Diagrama de comunicao - Diagrama de viso geral - Diagrama temporal Esses diagramas possuem aspectos que o diferenciam. O diagrama de seqncia enfatiza a seqncia de mensagens dentro de uma linha de tempo, enquanto que o de comunicao enfatiza o relacionamento estrutural entre os objetos, sem se preocupar com o tempo determinado para cada interao. O diagrama de comunicao at a verso 1.4 era conhecido como diagrama de colaborao. O diagrama de seqncia e o de comunicao apresentam diferentes formas de representar a mesma informao. Por exemplo: quando vou ao restaurante Popular sei que nesse local o garom leva 10 minutos para trazer o pedido e eu levo 20 minutos comendo, espero mais 5 minutos pela conta e 5 pelo troco. Quando vou ao restaurante Vip, no me preocupo com o tempo, fao o pedido, o garom traz meu jacar ao molho madeira, como, recebo a conta, pago, pego o troco e saio feliz e saltitante. Assim o restaurante Popular seria semelhante ao diagrama de seqncia, na qual as mensagens so trocadas entre os objetos (nesse caso Cliente e Garom), com demonstrao do tempo de processamento. O restaurante Vip seria semelhante ao diagrama de comunicao, no qual as mensagens so passadas de um objeto a outro sem indicar o tempo de processamento de cada uma. Em nosso exemplo usaremos o diagrama de seqncia para representar a seqncia dos eventos de sistema em um cenrio de um caso de uso. O diagrama de seqncia tem como elementos instncias de 90

atores, representados por figuras humanas esquematizadas, e instncias de objetos constituintes do sistema. O sistema poder ser representado como um nico objeto, porm mais til represent-lo como dois objetos genricos, indicando dois nveis da futura arquitetura. O primeiro objeto representa a interface do sistema, ou classe de aplicao, e o segundo, mais interno, representa o controlador do sistema, classe videolocadora. O ator s pode s pode se comunicar diretamente com a aplicao e esta, por sua vez, comunica-se com o controlador. Cada um desses elementos ter uma linha de tempo, representada pelas linhas verticais, na qual os eventos podem ocorrer. Quando a linha est tracejada, o ator ou sistema est inativo. Quando a linha est cheia, significa que o ator ou sistema est ativo (operando ou esperando o resultado de alguma operao). Aes que devem ser repetidas so envolvidas por um retngulo rotulado com um asterisco (ou esteretipo <<iteration>>). As linhas horizontais representam o fluxo de informao. Existem trs tipos de envio de informao nestes diagramas: d) Entre atores (comunicao entre atores) e) Dos atores para o sistema (eventos de sistema) f) Do sistema para os atores (respostas do sistema) Cada uma das operaes e consultas identificadas dever ser um contrato, e essas operaes, em conjunto, correspondero a toda funcionalidade do sistema. O diagrama de seqncia pode ser construdo para o fluxo principal do caso de uso, e eventualmente tambm para alguns cenrios com fluxos alternativos. 4.3.2.1 Mais sobre a representao dos digramas de seqncia e UML 2.0 Alm dos recursos descritos anteriormente, novos recursos foram includos na UML 2.0. O diagrama de seqncia pode ser desenhado como um frame que identificar o diagrama. Na rea de cabealho do frame ficar o ttulo do diagrama, representada por um retngulo de canto cortado, localizado no ngulo superior esquerdo. O ttulo do diagrama dever conter um prefixo que descreve o tipo de interao que foi colocado no frame, no exemplo o prefixo sd indica sequence diagram, ou seja, diagrama de seqncia.

Figura 37 - Representao do diagrama de sequncia com frame Fonte : Desenvolvendo Aplicaes com UML 2.0, Ana Cristina Melo

O cabealho pode ser utilizado em todos os diagramas UML. Quando desenhamos diagramas de seqncia para expressar os fluxos principal e alternativos de um caso de uso, ficamos muitas vezes diante de uma redundncia de mensagens. Para resolver esse problema, a UML 2 nos oferece a possibilidade de termos dentro de um diagrama a incluso de outro pequeno diagrama. Essa interao chamada na UML 2 de ocorrncia de interao (interaction occurrence). Analise o exemplo a seguir, imagine que o trecho desse diagrama de seqncia referente busca de um produto aparea em vrios outros diagramas. Sendo assim, seria interessante que pudssemos reutilizar esse trecho em outros diagramas, ao invs de redesenh-lo toda vez que precisssemos dele. 91

Figura 38 - Diagrama de sequncia com eventos Fonte : Desenvolvendo Aplicaes com UML 2.0, Ana Cristina Melo

Assim, separaramos esse trecho definindo-o como outra interao. Em nosso caso outro diagrama de seqncia.

Figura 39 - Separando o trecho retilizvel como uma interao Fonte : Desenvolvendo Aplicaes com UML 2.0, Ana Cristina Melo

Para fazer referncia a nossa interao reutilizvel, usamos a ocorrncia de interao, isso consiste em desenharmos um frame UML, colocando no seu cabealho o operador ref. No corpo do frame colocamos o ttulo da interao que ser reutilizada.

92

Figura 40 - Diagrama de Sequncia utilizando uma ocorrncia de interao Fonte : Desenvolvendo Aplicaes com UML 2.0, Ana Cristina Melo

Alm do operador ref., a UML 2.0 nos oferece outros operadores, os principais so: - opt : permite definir um trecho da interao como opcional; - loop: permite a repetio de um trecho da interao; - alt: permite definir trechos alternativos dentro de uma interao. Para utilizamos opt, cercamos o trecho que s deve ser executado em determinada condio com um frame.

93

Figura 41 - Diagrama de Sequncia com operador opt Fonte : Desenvolvendo Aplicaes com UML 2.0, Ana Cristina Melo

No operador loop, podemos definir um trecho que repete por n vezes. Junto ao operador loop, podemos definir um valor mnimo e mximo, alm de uma condio. Ex.: loop 1, 3 [senha no confere]

94

Figura 42 - Diagrama de Sequncia com operador alt Fonte : Desenvolvendo Aplicaes com UML 2.0, Ana Cristina Melo

No operador alt, o frame da interao dividido em sees com interao dentro de cada seo, cada seo dever ter uma condio. A validao dessa condio que determinar qual seo ser executada. A ltima seo poder ser a condio else, que ser executada caso nenhuma condio for verdadeira.

Figura 43 - Diagrama de Sequncia com operador loop e break Fonte : Desenvolvendo Aplicaes com UML 2.0, Ana Cristina Melo

Atividades do projeto de interface Determinar quais so as janelas do sistema e as possibilidades de navegao entre uma janela e outra. Fazer o projeto grfico das janelas, associando controles a eventos de navegao, operaes de sistema e seus parmetros, consultas de sistema com seus parmetros e resultados e operaes de controle de transao (commit, rollback, etc.). Determinar os possveis estados de janelas modais, indicando quais controles de interface estaro habilitados e/ou visveis nos diferentes estados. Indicar quais funes devero estar habilitadas nos diferentes nveis de segurana. Definir os casos de uso reais da aplicao. 95

4.3.3

Estudo de Caso Locao de DVD pela Internet- Parte 4

96

Figura 44 - Diagrama de Sequncia do caso de uso Locar DVD Fonte: Desenvolvendo Software com UML 2.0 - Ernani Medeiros 4.4

Diagrama de Estados de Navegao O diagrama de estados de navegao indica quais so as janelas que compe o sistema e quais eventos permitem ao usurio navegar de uma para outra. Eventos internos s janelas (transies de uma janela para ela mesma) no so mostrados neste diagrama, mas devero aparecer nos diagramas de estado das janelas modais.

97

Cada evento que rotula as transies do diagrama ser posteriormente associado com um controle (um boto, por exemplo) da janela na origem da transio. desejvel que desde j os nomes dos eventos correspondam aos nomes dos controles de interface que efetivaro a transio. Projeto Grfico e Associao de Controles Verificar: Quais so os eventos de navegao que saem da janela no diagrama de estados de navegao? Quais as operaes de sistema realizadas na janela? Quais as consultas de sistema realizadas na janela? Quando as transaes tero BEGIN, COMMITT e ROLLBACK? Janela de Login

98

Associao de Controles da Janela Login

Campo nome do usurio: Parmetro nome da operao de sistema login(nome,senha). Campo senha: Parmetro senha da operao de sistema login(nome,senha). Boto login: Ativador da operao de sistema login(nome,senha). Navegao para Principal condio: consulta de sistema loginOk() = true. Boto encerrar: Navegao para Fim.

Janela Principal

Associao de Controles da Janela Principal

99

Boto emprestar fitas: Navegao para Emprstimo de Fitas. Boto cadastrar cliente: Navegao para Cadastro de Cliente. Boto pagar dbito: Navegao para Pagamento de Dbito Boto novo login: Navegao para Login. Boto encerrar: Navegao para Fim.

Janela Emprstimo de DVDs

Associao de Controles da Janela Emprstimo de DVDs

100

Inicializao: Ativ a a consulta de sistema listaNomesDeClientes() . Menu nome do cliente. Resultado da consulta de sistema listaNomesDeClientes(). Item selecionado parmetro nome da operao de sistema identific aCliente(nome). Ev ento de seleo ativa operao de sistema identificaCliente(nome) . Menu cdigo da fita. Resultado da consulta de sistema listaCodigosDeFitas(). Item selecionado parmetro codigo da operao de sistema emprestaFita(codigo). Ev ento de seleo causa: Ativ ao da operao de sistema emprestaFita(codigo). Ativ ao da consulta de sistema consultaFita(). Lista titulo/prazo/valor: Resultado da consulta de sistema consultaFita() . Campo valor total. Resultado da consulta de sistema consultaValorTotal(). Boto confirmar emprstimo: Ativ ador da operao de sistema finalizaEmprestimo(). Ativ ador da consulta de sistema consultaValorTotal(). COMMIT. Boto cancelar: ROLLBACK. Boto voltar: Nav egao para Principal.

Diagrama de Estados de uma Janela Modal

101

Associao de Controles Modais

Inicializao: Ativa consulta de sistema listaNomesDeClientes(). Hab il ita menu nome do cliente e boto voltar. Desabilita demais controles. Menu nome do cliente. Resultado da consulta de sistema listaNomesDeClientes(). Item sel ecionado parmetro nome da operao de sistema identificaCliente(nome). Evento de seleo causa: A tiva operao de sistema identifica Cliente(nome). Desabi lita menu nome do clien te. Desabi lita boto voltar. Habilita menu cdigo da fita. Habilita boto cancelar. L impa campos cdigo da fita, ttulo/prazo/valor e valor total. Menu cdigo da fita. Resultado da consulta de sistema listaCodigosDeFitas(). Item sel ecionado parmetro codigo da operao de sistema emprestaFita(codigo). Evento de seleo causa: A tivao da operao de sistema emprestaFita(codigo). A tivao da consulta de sistema consultaFita(). Habilita boto confirmar emprstimo. Lista titulo/prazo/val or: Resultado da consulta de sistema consultaFita(). Campo valor total. Resultado da consulta de sistema consultaValorTotal(). Boto confirmar empr stimo: Ativador da operao de sistema fin alizaEmpr estimo(). Ativador da consulta de sistema consultaValor Total(). CO MMIT. Hab il ita menu nome do cliente Desabilita boto cancelar. Hab il ita boto voltar. Boto cancelar: RO LLBACK. Limpa todos os campos. Hab il ita menu nome do cliente e boto voltar. Desabilita demais controles. Boto voltar: Navega o para Principal.

Controle de Acesso

102

Associao de Controles com Segurana de Acesso

Inicializao: Nvel 1: Desabilita todos os botes. Nvel 2: Habilita botes emprestar fitas, novo login e encerrar. Desabilita demais botes. Nvel 3: Habilita todos os botes. Boto emprestar fitas: Navegao para Emprstimo de Fitas. Boto cadastrar cliente: Navegao para Cadastro de Cliente. Boto pagar dbito: Navegao para Pagamento de Dbito Boto novo login: Navegao para Login. Boto encerrar: Navegao para Fim.

103

Casos de Uso Reais Uma ltima atividade do projeto de interface poder ser a transcrio do caso de uso essencial para uma verso real, a qual vai indicar claramente como a tecnologia usada para realizar os processos de negcio. Esse caso de uso poder ser importante para auxiliar o analista encarregado da fase de testes de integrao do sistema, e tambm poder ser um bom comeo para a elaborao de um manual de uso do sistema, j que todas as principais rotinas de uso estaro claramente indicadas.

Caso de Uso: Locar Fitas

Fluxo Principal: 1. O cliente chega ao balco com as fitas que deseja locar. 2. O cliente informa seu nome e entrega as fitas ao funcionrio. 3. O funcionrio acessa a janela Emprstimo de Fitas pressionando o boto emprestar fitas na janela Principal. 4. O funcionrio registra o nome do cliente no menu nome do cliente e inicia a locao. 5. O funcionrio registra cada uma das fitas no menu cdigo da fita. 6. O sistema apresenta o ttulo, prazo de locao e valor de cada fita na janela Titulo/Prazo/Valor. 7. O funcionrio finaliza a locao pressionando confirma emprstimo, dev olv e as fitas ao cliente e lhe informa a data de dev oluo e o valor total da locao. 6. O cliente vai embora com as fitas.

4.4.1.1 Camada de persistncia Cada classe equivale a uma tabela relacional. Cada atributo de uma classe equivale a uma coluna na respectiva tabela e cada instncia de uma classe (objeto) equivale a uma linha na respectiva tabela. A classe controladora no deve ser persistente, pois ela Singleton. *Singleton, um padro de projeto de software (do ingls Design Pattern). Este padro garante a existncia de apenas uma instncia de uma classe. Equivalncia entre o Projeto Orientado a Objetos e o Modelo Relacional O BD relacional reflete exatamente as instncias das classes, mas com organizao distinta Classes e Atributos

104

Tabela: Cliente #IUOCliente (chave, unico) 3476 23984 2983 nome (unico) Joo Maria Pedro idade 34 35 53 debito 0,00 23,00 12,00

Associaes de * para * Associaes de 1 para 1

Tabela: Curso_oferece_Disciplina #IUOCurso (chave) 235 235 376 568 #IUODisciplina (chave) 8746 347 347 899

Associaes de 1 para 1

105

Tabela: Pagamento_referenteA_Venda #IUOPagamento (chave, unico) 678 965 908 #IUOVenda(chave, unico) 543 67 561

Associaes Ordenadas

Tabela: Voo_guarda_Reserva #IUOVoo (chave) 1233 1233 5645 5645 5645 2344 #IUOReserva(chave, unico) 12232 4345435 344386 234323 67665 23722 Ordem 2 1 2 3 1 1

Associaes Qualificadas Qualificador um atributo da classe qualificada: implementa-se como associao para *. Qualificador externo: implementa-se como a associao ordenada, trocando o ndice pelo valor do qualificador externo. Classe de associao

106

Tabela: Emprego IUOEmprego 2 21 645 233 34 346 IUOPessoa 44 44 345 33 63 55 IUOEmpresa 233 278 233 233 278 3332 salario 1000 1200 3200 3400 2300 780 dataContratacao 12/03/98 14/10/02 11/03/90 30/11/98 07/02/00 14/09/01

Herana

Tabela: PagamentoEmCheque #IUOPagamentoEmCheque (chave) numeroDoCheque 7887879 9876978 9877655 8976678 8768769 6743680 8976876 4354545 valor 60,00 12,00 99,88 80,90 vencimento 13/02/04 15/02/04 12/05/03 17/09/04

107

4.4.2 4.4.3 4.4.4

Diagrama de Componentes Diagrama de Pacotes Software de Apoio

4.4.5 4.5

Estudo de Caso - Parte 2

Construo Linguagens de programao 4.5.2 Documentao 4.5.3 Atualizaes CVS (repositrios) 4.5.4 Testes 4.5.4.1 Teste unitrio 4.5.4.2 Teste Caixa Preta 4.5.4.3 Teste Caixa Branca 4.5.4.4 Caminho Bsico 4.5.4.5 Estruturas de Controle 4.5.4.6 Integrao
4.5.1

4.5.4.7 Software de Apoio

4.5.5 4.6 4.6.1 4.6.2 4.6.3 4.6.4 4.6.5 4.6.6

Estudo de Caso parte 3 Transio Validao Manual do sistema Treinamento ao usurio Diagrama de Distribuio Diagrama de Implantao Estudo de Caso parte 4

Bibliografia SOMMERVILLE IAN, Engenharia De Software, oitava edio, So Paulo: Pearson Addison Wesley, 2007. FOWLER, Martin; FOEMMEL, Matthew. Continuous http://martinfowler.com/articles/continuousIntegration.html>. Integration, Disponvel em:

JEFFRIES, Ron. XP Magazine Contents: XProgramming.com an Extreme Resource, Disponvel em:<http://www.xprogramming.com/xpmag/index.htm>.

Programming

REIS, Christian. A commentary on the Extreme Programming development process, .Disponvel em: <http://www.async.com.br/~kiko/papers/xp/>. PRADO, Darci Santos do. Planejamento e controle de projetos. Belo Horizonte: Editora de Desenvolvimento Gerencial, 2001. VARGAS, Ricardo. Gerenciamento de projetos: estabelecendo diferenciais competitivos. 6.ed. atual. Rio de Janeiro: Brasport, 2005. VARGAS, Ricardo. Manual prtico do plano do projeto. 3.ed. Rio de Janeiro: Brasport, 2007. CARVALHO, Adriane M. B. Rizzoni; CHIOSSI, Thelma C. dos Santos. Introduo engenharia de software. Campinas, SP. Ed UNICAMP, 2001. 108

FILHO, Wilson de Pdua Paula. Engenharia de software Fundamentos, Mtodos e Padres. Rio de Janeiro, RJ. Ed LTC, 2001. FOURNEIR, Roger. Guia prtico para desenvolvimento e manuteno de sistemas estruturados. So Paulo. Ed. Makron Books, 1994. Pompilho, S. Anlise Essencial Guia Prtico de Anlise de Sistemas. Rio de Janeiro: Ed Cincia Moderna Ltda, 1995. PRESSMAN, Roger S. Engenharia de Software. So Paulo. Ed. Markon Books, 1995 Rezende, Denis Alcides. Engenharia de software e sistemas de informao. 2.ed. Rio de Janeiro: Ed. Brasport, 2002. Somervile, I. Engenharia de software. 6 ed. Traduo Maurcio de Andrade. So Paulo: Ed Addison-Wesley, 2003. MAXIMIANO, Antonio Cesar Amaru. Administrao de projetos: como transformar idias em resultados. 2. ed. So Paulo: Atlas, 2002. Pankaj Jalote An Integrated Approach to Software Engineering, Third Edition. Springer. Alan Dennis - Barbara Haley Wixon. Anlise e Projeto de Sistemas -, Segunda Edio, LTC, 2005 Rio de Janeiro. Melo Ana Cristina, Desenvolvendo Aplicaes com UML 2.0. 2. Ed. Rio de Janeiro: Brasport, 2004. GIRARDI, R. Agent-Based Application Engineering, In Proceedings of the 3rd International Conference on Enterprise Information Systems (ICEIS 2001), Setubal, Portugal, 2001. HYACINTH, S. N. Software Agents: An Overview, Knowledge Engineering Review, v. 11(3), pp. 205-244, 1996. WOOLDRIDGE, M. Intelligent Agents, In: Multi-Agent Systems - A Modern Approach to Distributed Artificial Intelligence, G. Weiss (ed.), The MIT Press, 1999.

109