Apostila ES2 2sem2013

Faculdade de ecnologia de Praia Grande
ENGENHARIA DE SOFTWARE II
Simone Maria Viana Romano
Se eu tivesse oito horas para derrubar uma rvore, passaria seis afiando meu machado (Abraham Lincoln). 2 SEMESTRE DE 2013
ENGENHARIA DE SOFTWARE
Sumrio
INFORMAES IMPORTANTES .................................................................................................................... 7 OBJETIVOS: .................................................................................................................................................. 7 Sugesto de Livros, Revistas e Sites ............................................................................................................... 7 Softwares ......................................................................................................................................................... 7 Quantidade de aulas semanais e Quantidade de faltas permitidas ............................................................... 7 Abono de Faltas .............................................................................................................................................. 8 Contato ............................................................................................................................................................ 8 Avisos .............................................................................................................................................................. 8 Contedo das Avaliaes ................................................................................................................................ 8 Forma de Avaliao........................................................................................................................................ 8 Disciplinas, Dias e Horrios que me encontro na Fatec ............................................................................... 8 Erros da Apostila: ........................................................................................................................................... 8 TRABALHO SEMESTRAL................................................................................................................................. 9 TAREFA 01 - REVISO DE ENGENHARIA DE SOFTWARE I (VALOR : 0,5) ........................................... 10 1BIMESTRE
DESENVOLVIMENTODESOFTWARE.................................................................................................. 14
REQUISITOSDESOFTWARE................................................................................................................................... 16 IMPORTNCIA DOS REQUISITOS............................................................................................................... 17 QUALIDADE DOS REQUISITOS ................................................................................................................... 18 TIPOS DE REQUISITOS .................................................................................................................................. 19 EXEMPLO DE REQUISITOS FUNCIONAIS ............................................................................................... 20 EXEMPLO DE REQUISITOS NO FUNCIONAIS ...................................................................................... 20 EXEMPLO DE REQUISITOS DE DOMINIO ............................................................................................... 20 PROBLEMAS COMUNS NOS REQUISITOS ............................................................................................... 20 CLASSES DE REQUISITOS .......................................................................................................................... 20 ENGENHARIADEREQUISITOS............................................................................................................................... 21 OBJETIVOS DA ENGENHARIA DE REQUISITOS ...................................................................................... 22 TAREFA 02 - QUESTES DE REQUISITOS (0,5) ...................................................................................... 23 ELICITAODEREQUISITOS................................................................................................................................. 26 OBJETIVOS DA ELICITAO DE REQUISITOS ........................................................................................ 28 PASSOS PARA A ELICITAO DE REQUISITOS....................................................................................... 28 QUESTES QUE PRECISAM SER RESPONDIDAS ..................................................................................... 29 DOCUMENTAO DO ELICITAO DE REQUISITOS ............................................................................ 29 IDENTIFICAO E ELICITAO DE REQUISITOS .................................................................................. 30 IDENTIFICAO DOS REQUISITOS ......................................................................................................... 30 PROBLEMAS NA IDENTIFICAO DOS REQUISITOS ............................................................................ 31 EXEMPLO DE DECLARAO DO PROBLEMA ........................................................................................ 31 CARACTERSTICAS DA ELICITAO DE REQUISITOS.......................................................................... 31 DIFERENA ENTRE UMA BOA E UMA M ELICITAO DE REQUISITOS ......................................... 32 TAREFA 03 ELICITAO DE REQUISITOS (0,5) ................................................................................... 33 TCNICAS PARA ELICITAO DE REQUISITOS ................................................................................... 34 ETNOGRAFIA ................................................................................................................................................. 36 ENTREVISTAS ................................................................................................................................................ 37 Etapas ............................................................................................................................................................ 37 Forma de Entrevistar .................................................................................................................................... 37 Perguntas que devem ser respondidas .......................................................................................................... 37 BRAINSTORMING .......................................................................................................................................... 38 BRAINSWRITING ........................................................................................................................................... 39 EXERCCIOS ................................................................................................................................................ 40 JAD ....................................................................................................................................................................... 41
ETAPAS PARA PREPARAR UMA REUNIO JAD..................................................................................................... 41 PREPARAO .............................................................................................................................................. 42 SESSO ......................................................................................................................................................... 46 REVISO ....................................................................................................................................................... 51 PAPEIS DE CADA UM DENTRO DA REUNIO .......................................................................................... 52 O CLIENTE (PATROCINADOR) .................................................................................................................. 52 ENGENHEIRO DE SOFTWARE ................................................................................................................... 52 EQUIPE ........................................................................................................................................................ 53 OBSERVADOR .............................................................................................................................................. 53 DOCUMENTADOR ...................................................................................................................................... 53 LDER DE SESSO OU FACILITADOR ...................................................................................................... 53 FIGURINHAS DIFCIEIS NA REUNIO ..................................................................................................... 54 TAREFA 04 TECNICA JAD (1,0)............................................................................................................... 57 ESPECIFICAO DE REQUISITOS .............................................................................................................. 58 MODELO DE ESPECIFICAO DE REQUISITOS ...................................................................................................... 58 PASSOS PARA ESPECIFICAR OS REQUISITOS ........................................................................................ 58 VISO E ESCOPO ................................................................................................................................................. 60 EXERCCIOS ................................................................................................................................................ 60 TAREFA 05 ESPECIFICAO DE REQUISITOS (0,5) ........................................................................... 61 VERIFICAO E VALIDAO DE REQUISITOS ..................................................................................... 62 TIPOS DE DEFEITO ........................................................................................................................................ 63 OMISSO ...................................................................................................................................................... 64 AMBIGUIDADE ............................................................................................................................................ 64 INCONSISTNCIA ........................................................................................................................................ 64 FATO INCORRETO ...................................................................................................................................... 64 INFORMAO ESTRANHA ......................................................................................................................... 64 DOCUMENTO DE REQUISITOS .............................................................................................................................. 64 DEFEITOS NO DOCUMENTO DE REQUISITOS....................................................................................... 65 CONSEQUENCIAS ....................................................................................................................................... 65 PEQUENO CHECKLIST DE REQUISITOS..................................................................................................... 65 TCNICAS DE VALIDAO DE REQUISITOS ........................................................................................... 65 REVISO DE REQUISITOS ......................................................................................................................... 65 REVISES DE SOFTWARE ............................................................................................................................ 66 TIPOS DE REVISO DE SOFTWARE .......................................................................................................... 66 PROCESSO DE INSPEO DE SOFTWARE .............................................................................................. 67 PROCESSO TRADICIONAL DE INSPEO ............................................................................................... 68 GERENCIAMENTO DE MUDANA DE REQUISITOS .............................................................................. 69 EVOLUO DOS REQUISITOS .................................................................................................................... 71 REQUISITOS PERMANENTES E VOLTEIS............................................................................................... 71 CLASSIFICAO DOS REQUISITOS.......................................................................................................... 71 PLANEJAMENTO DO GERENCIAMENTO DE REQUISITOS ................................................................... 72 RASTREABILIDADE ..................................................................................................................................... 72 SUPORTE FERRAMENTA: ....................................................................................................................... 72 ETAPAS PARA O RASTREAMENTO ............................................................................................................ 73 EXERCCIOS ................................................................................................................................................ 74 MATRIZ DE RASTREABILIDADE ................................................................................................................ 76 RASTREABILIDADE ...................................................................................................................................... 76 OBJETIVOS................................................................................................................................................... 76 MATRIZ DE RASTREABILIDADE DEFINIDAS ........................................................................................................ 78 EXERCCIOS ................................................................................................................................................ 79 ORIENTAO A OBJETOS ............................................................................................................................ 80 HISTRIA ........................................................................................................................................................ 80 CONCEITOS FUNDAMENTAIS ............................................................................................................................... 81 OBJETO ........................................................................................................................................................ 82 ATRIBUTO .................................................................................................................................................... 83
OPERAO X MTODO ............................................................................................................................. 83 CLASSE ......................................................................................................................................................... 84 ESTADO ........................................................................................................................................................ 84 MENSAGEM ................................................................................................................................................. 84 ENCAPSULAMENTO ................................................................................................................................... 84 HERANA ..................................................................................................................................................... 85 POLIMORFISMO ......................................................................................................................................... 86 ANLISE ORIENTADA A OBJETOS ............................................................................................................ 87 EXERCCIOS ................................................................................................................................................ 88 2 BIMESTRE UML ...................................................................................................................................... 91
HISTRIA ............................................................................................................................................................ 91
CONCEITO ....................................................................................................................................................... 92 UTILIZAO ................................................................................................................................................... 93 NOTAO ....................................................................................................................................................... 94 VANTAGENS ....................................................................................................................................................... 94 FASES DO DESENVOLVIMENTO UML ....................................................................................................... 94 COMPONENTES DA UML ...................................................................................................................................... 95 MODELOS DE ELEMENTOS ......................................................................................................................... 95 CLASSES ....................................................................................................................................................... 95 OBJETOS ...................................................................................................................................................... 95 ESTADOS ...................................................................................................................................................... 96 PACOTES ...................................................................................................................................................... 96 COMPONENTES .......................................................................................................................................... 96 RELACIONAMENTOS .................................................................................................................................. 97 MECANISMOS GERAIS ............................................................................................................................. 101 DIAGRAMAS ..................................................................................................................................................... 101 DIAGRAMAS ESTRUTURAIS (ESTTICOS) ............................................................................................. 101 DIAGRAMAS COMPORTAMENTAIS (DINMICOS) ............................................................................... 102 EXERCCIOS .............................................................................................................................................. 103 DIA PORTABLE ............................................................................................................................................... 105 MICROSOFT VISIO 2003 ............................................................................................................................... 107
DIAGRAMA DE MODELO UML ............................................................................................................................ 107
ATIVIDADE DE UML ................................................................................................................................. 108 COLABORAO DE UML ......................................................................................................................... 108 COMPONENTE UML ................................................................................................................................. 109 IMPLANTAO DE UML .......................................................................................................................... 109 SEQUNCIA DE UML ................................................................................................................................ 109 GRFICO DE ESTADO DE UML .............................................................................................................. 109 ESTRUTURA ESTTICA DE UML ............................................................................................................. 110 CASO DE USO ............................................................................................................................................ 110 PROPRIEDADES DA FORMA ...................................................................................................................... 110 OBSERVAES .......................................................................................................................................... 111 DIAGRAMA DE CASO DE USO .................................................................................................................... 112 CASOS DE USO ............................................................................................................................................. 112 ATOR ................................................................................................................................................................ 113 COMO IDENTIFICAR OS ATORES ........................................................................................................... 113 CASO DE USO .................................................................................................................................................... 113 COMO IDENTIFICAR CASOS DE USO .................................................................................................... 114 CENRIO ....................................................................................................................................................... 114 RELACIONAMENTO DE EXTENSO ................................................................................................................ 114 RELACIONAMENTO DE INCLUSO ................................................................................................................. 115 RELACIONAMENTO DE ESPECIALIZAO .................................................................................................... 115 RELACIONAMENTO ENTRE CASOS DE USO ......................................................................................... 115 EXEMPLO: ESTUDO DE CASO LOCADORA DE VECULOS ............................................................. 117 ANLISE DE CASOS DE USO ..................................................................................................................... 118 EXERCCIOS .............................................................................................................................................. 118 TAREFA 06 DIAGRAMA DE CASO DE USO (1,0) ................................................................................. 123
DIAGRAMA DE CLASSES ............................................................................................................................. 124 CLASSE .......................................................................................................................................................... 124 CONVENES ........................................................................................................................................... 125 ATRIBUTOS................................................................................................................................................... 125 OPERAES .................................................................................................................................................. 125 VISIBILIDADE .................................................................................................................................................... 125 RELACIONAMENTOS.................................................................................................................................. 125 ASSOCIAO ............................................................................................................................................. 126 AGREGAO ............................................................................................................................................. 126 COMPOSIO ........................................................................................................................................... 127 CLASSE DE ASSOCIAO ........................................................................................................................ 127 HERANA ................................................................................................................................................... 128 DIAGRAMA DE CLASSE ............................................................................................................................. 129 COMO FAZER UM DIAGRAMA DE CLASSES ......................................................................................... 130 IDENTIFICANDO AS CLASSES ................................................................................................................. 130 IDENTIFICANDO OS ATRIBUTOS ........................................................................................................... 131 IDENTIFICANDO O COMPORTAMENTO ............................................................................................... 131 IDENTIFICANDO GENERALIZAES ..................................................................................................... 131 IDENTIFICANDO ASSOCIAO .............................................................................................................. 131 EXEMPLO ESTUDO DE CASO: LOCADORA DE VECULOS ............................................................. 131 EXERCCIOS .............................................................................................................................................. 132 DIAGRAMA DE OBJETOS ............................................................................................................................ 136 EXERCCIOS ................................................................................................................................................. 137 TAREFA 07 DIAGRAMA DE CLASSES E DIAGRAMA DE OBJETOS (1,0) .......................................... 138 DIAGRAMA DE SEQUENCIAS ..................................................................................................................... 139 EXEMPLO: ESTUDO DE CASO: SISTEMA GESTOR DE VOTAO INTERNA .................................... 142 EXERCCIOS .............................................................................................................................................. 147 TAREFA 8 DIAGRAMA DE SEQUENCIAS (1,0) .................................................................................... 148 ANEXO - SOLUES PARA PROBLEMAS NA ENGENHARIA DE REQUISITOS ............................ 150 ELICITAO DE REQUISITOS ................................................................................................................... 151 PROBLEMAS .............................................................................................................................................. 151 DESAFIOS................................................................................................................................................... 151 PROBLEMA: ENVOLVER INTERESSADOS INAPROPRIADOS .............................................................. 152 PROBLEMA: POLTICA NA ORGANIZAO .......................................................................................... 152 PROBLEMA: A LINGUAGEM NATURAL E A ABSTRAO DOS REQUISITOS DE ALTO NVEL DIFICULTAM O MAPEAMENTO DAS CAPACIDADES MACRO EM REQUISITOS FUNCIONAIS E NO FUNCIONAIS. ............................................................................................................................................. 152 PROBLEMA: SEPARAR PREMISSAS RELACIONADAS AO DESENVOLVIMENTO DO SISTEMA DOS SEUS REQUISITOS .................................................................................................................................... 152 CASOS DE USO .................................................................................................................................................. 153 PROBLEMA: DIFICULDADE NA DESCRIO DE REQUISITOS FUNCIONAIS E NO-FUNCIONAIS. ..................................................................................................................................................................... 153 PROBLEMA: COMPLEXIDADE NO DETALHAMENTO DOS CASOS DE USO PARA DEFINIO DA SOLUO ................................................................................................................................................... 153 PROBLEMA: DETALHAMENTO TCNICO DESNECESSRIO DURANTE A ESPECIFICAO FUNCIONAL DO SISTEMA. ...................................................................................................................... 154 GERNCIA DE REQUISITOS ................................................................................................................................ 154 PROBLEMA: DIFICULDADES DE ESTABELECER UMA ESTRATGIA PARA A ATUALIZAO E REUTILIZAO DE CASOS DE USO ....................................................................................................... 154 PROBLEMA: REPRESENTAR A ATUALIZAO DE CASOS DE USO ................................................... 154 PROBLEMA: DIFICULDADE DE INTEGRAO DAS PRTICAS DE GERNCIA DE REQUISITOS COM GERNCIA DE CONFIGURAO. ................................................................................................. 155 PROBLEMA: TRABALHAR COM O BACKLOG DE CASOS DE USO INEXISTENTES PARA SISTEMAS EM MANUTENO. ................................................................................................................................... 155 PROBLEMA: DIFICULDADE DE IMPLANTAO E MANUTENO DA RASTREABILIDADE DOS REQUISITOS............................................................................................................................................... 155
PROBLEMA: DIFICULDADES DE ESTABELECIMENTO RETROATIVO DE RASTREABILIDADE DOS REQUISITOS............................................................................................................................................... 155
INFORMAES IMPORTANTES
OBJETIVOS: Aplicar um processo de desenvolvimento de software, nfase na definio e elicitao dos requisitos: Apresentar e discutir o Ciclo de Requisitos de Software: Identificao, Elicitao, Anlise, Especificao e Validao; Apresentar e discutir as atividades de Identificao e elicitao de requisitos; Apresentar e discutir as atividades da anlise de requisitos de software; Apresentar as principais tcnicas para especificao de requisitos de software; Apresentar as principais tcnicas para validao de requisitos de software; Apresentar as principais tcnicas para processo de gerenciamento de mudana de requisitos de software. EMENTA: Contexto atual das empresas em relao aos projetos de tecnologia de informao. Modelagem de Negcio para o desenvolvimento de software. Conceitos, evoluo e importncia da Engenharia de Requisitos. Entendendo e analisando os problemas e as necessidades dos usurios, clientes e envolvidos no projeto. Tcnicas de elicitao. Requisitos, seus tipos e matriz de rastreabilidade. Definio do sistema a partir dos requisitos. Gerenciamento de requisitos Sugesto de Livros, Revistas e Sites ENGENHARIA DE SOFTWARE Fundamentos, Mtodos e Padres 3 Edio Editora GEN LTC Autor: Wilson de Pdua Paula Filho 2010; ESPECIFICAO DE SISTEMAS DE SOFTWARE UTILIZANDO ANALISE E PROJETO ESTRUTURADOS Editora UNICAMP Autor: Thelma C. dos Santos Chiossi e Regina Lcia O. Moraes 2006; ENGENHARIA DE SOFTWARE 6 Edio Editora MH - MCGRAW HILL/NACIONAL Autor: Roger S. Pressman 2006; AURUM, A., WOHLIN, C., Engineering and Managing Software Requirements, Springer-Verlag, 2005. REVISTAS E SITES: Revista Engenharia de Software: www.devmedia.com.br; http://engenhariadesoftware.blogspot.com/; http://www.sigsoft.org/; http://rildosan.blogspot.com/; http://www.yuml.me; http://www.wthreex.com/rup/; http://www.engenharia-software.com http://www.facebook.com/connect/uiserver.php?app_id=318148321616976& method=permissions.request&redirect_uri=http%3A%2F%2Fapps.facebook.c om%2Fpromonlogicalisestag%2F%3Ffb_source%3Dsearch%26ref%3Dts%26f ref%3Dts&response_type=none&display=page&auth_referral=1 Softwares Dia Portable, Visio (Fatec), Word. Mquina Virtual na Fatec : Engenharia de Software. Quantidade de aulas semanais e Quantidade de faltas permitidas Quatro (4) aulas semanais e poder ter vinte (20) faltas no semestre.
Abono de Faltas Abono de faltas somente com atestado mdico. No final do semestre, no caso do aluno ter nota e ter entregue no mnimo 70% das atividades poder eliminar as faltas em excesso da seguinte forma: para cada 2 horas/aula excedida dever ser entregue manuscrito um relatrio de apresentao de TCC (DEIXAR NA SECRETARIA). Contato Email: simone_viana@yahoo.com.br e/ou simone@fatecpg.com.br Obs. O email: simonemviana@gmail.com usado somente para envio de formulrios no Google Docs no h acesso da caixa postal. TODOS OS EMAILS ENVIADOS PELO YAHOO OU PELO FATECPG SERO RESPONDIDOS EM UM PRAZO DE 48 HORAS. CASO NO HAJA RESPOSTA, FAVOR ENVIAR NOVAMENTE. Solicito que todos deixem o email atualizado na secretaria da Fatec pois por este email que consta no seu cadastro que eu entro em contato, avisando faltas, reposies, assuntos gerais, etc. Avisos Na pgina de ENGENHARIA DE SOFTWARE sempre ter avisos pertinentes ao contedo da disciplina. Contedo das Avaliaes Sempre o contedo das avaliaes ser o apresentado at uma semana antes das provas bimestrais, podendo ter eventualmente uma reviso antes da avaliao. Forma de Avaliao Haver duas provas bimestrais que podero ser dissertativas ou objetivas com valor de 10,0 pontos; Haver tarefas avaliativas em sala de aula que pode ter valor at 3,0 pontos que sero acrescidos a nota do bimestre; Estas tarefas podero ser feitas em laboratrio, em casa com data de entrega estipulada ou em sala de aula, realizadas em grupo ou individualmente, participao em sala de aula, relatrios a partir de vdeos assistidos, estudos de casos, entre outros. ATENO!!!! CASO O ALUNO FALTE INDEPENDENTE DE TER ATESTADO OU TER ATESTADO NO SER ACEITO A TAREFA POIS O MESMO NO ASSISTIU A AULA. Disciplinas, Dias e Horrios que me encontro na Fatec Engenharia de Software II quinta-feira (13h10 as 16h40); quarta-feira (19h as 22h30); Banco de Dados quarta-feira (13h10 as 16h40); quinta-feira (19h as 22h30); Laboratrio de Banco de Dados quarta e quinta-feira (16h50 as 18h30) Sbado (8h as 11h30). Erros da Apostila: Caso seja encontrado erro na apostila, favor enviar por email.
Obrigada!
TRABALHO SEMESTRAL
O trabalho semestral dever ser entregue na ltima aula do segundo semestre (antes da prova de avaliao do segundo bimestre) e dever ter: Capa contendo o nome dos alunos (mximo 5), o ciclo e o perodo; Estudo de caso descritivo; Agenda da reunio JAD; Ata contendo o resultado da reunio JAD; Especificao de Requisitos (mnimo 4); Diagrama de Caso de Uso (contendo todo o projeto); Diagrama de Classes (contendo todo o projeto); Diagrama de Objetos (com base no diagrama de classes); Diagrama de Sequncia (de um caso de uso). Obs. Poder ser feito manuscrito ou utilizando um software e no necessrio entregar encadernado.
Aviso: eu sou cliente. Portanto quero ver o trabalho pronto e no tiro dvidas do mesmo. Bom Trabalho!!!!
10
TAREFA 01 - REVISO DE ENGENHARIA DE SOFTWARE I (VALOR : 0,5)
1.
a) b)
c) d) e)
Segundo a IEEE Computer Society, a engenharia de software a aplicao de uma abordagem sistemtica, disciplinada e quantificvel ao desenvolvimento, operao e manuteno de software, isto , a aplicao da engenharia ao software. Acerca dos princpios da engenharia de software, assinale a opo correta. (CESPE - 2010 SAD-PE - Analista de Controle Interno Tecnologia da Informao) A engenharia de requisitos de um software, em geral, precede a engenharia dos requisitos do sistema de informaes no qual o software ser usado. A manuteno de software uma atividade da engenharia de software que necessita do emprego de recursos que drenam cerca de 50% do investimento total em um software durante todo o seu ciclo de vida. A gerncia de configurao de software uma atividade que envolve o emprego de conceitos e prticas, tais como identificao de itens de configurao, controle, contabilizao e auditoria. desejvel que o valor da coeso e o do acoplamento, duas importantes propriedades da arquitetura de um software, sejam maximizados durante a engenharia de software. Em ferramentas CASE, como refactoring, melhor adotar-se uma abordagem formal que uma abordagem heurstica.
2. Um requisito de software expressa as necessidades e restries colocadas em um produto de software que contribuem para a soluo de algum problema do mundo real. Acerca desse assunto, assinale a opo correta. (CESPE - 2010 - SAD-PE - Analista de Controle Interno Tecnologia da Informao) a) Os contratantes ou clientes so os principais colaboradores envolvidos no fornecimento de informaes para o processo de levantamento ou elicitao de requisitos de software, os demais grupos de pessoas que podem fornecer informaes so considerados de importncia secundria. b) As necessidades dos usurios a serem atendidas por um produto de software constituem a classe de requisitos funcionais, e as restries mencionadas na definio de requisitos constituem a classe de requisitos no funcionais. c) Entre as fontes de informao para a elicitao de requisitos, destacam-se, alm dos colaboradores, o conhecimento do domnio de aplicao em que o software funcionar, o ambiente operacional do software e o ambiente organizacional. d) A negociao de requisitos, de forma similar observao do ambiente organizacional, uma atividade tpica da fase de elicitao de requisitos. e) A tcnica de casos de uso, empregada em alguns modelos de desenvolvimento de software atuais, mais aderente construo
11
de cenrios durante a construo de prottipos que durante a elicitao de requisitos. 3. O conjunto de atividades e resultados associados que resulta em um produto de software recebe o nome de (UFG - 2010 - UFG - Analista de TI - Desenvolvimento de Sistemas): a) engenharia de software. b) processo de software. c) especificao de software. d) implantao de software. 4. Assim como a Engenharia de Software, existe tambm na rea de informtica a chamada Cincia da Computao. Assinale a alternativa que melhor apresenta a diferena entre Engenharia de Software e Cincia da Computao. (FUNIVERSA - 2009 - IPHAN - Analista Tecnologia da Informao) a) A Cincia da Computao tem como objetivo o desenvolvimento de teorias e fundamentaes. J a Engenharia de Software se preocupa com as prticas de desenvolvimento de software. b) A Engenharia de Software trata da criao dos sistemas de computao (softwares) enquanto a Cincia da Computao est ligada ao desenvolvimento e criao de componentes de hardware. c) A Engenharia de Software trata dos sistemas com base em computadores, que inclui hardware e software, e a Cincia da Computao trata apenas dos aspectos de desenvolvimento de sistemas. d) A Cincia da Computao trata dos sistemas com base em computadores, que inclui hardware e software, e a Engenharia de Software trata apenas dos aspectos de desenvolvimento de sistemas. e) A Cincia da Computao destina-se ao estudo e soluo para problemas genricos das reas de rede e banco de dados e a Engenharia de Software restringe- se ao desenvolvimento de sistemas. 5. Para garantir o desenvolvimento de qualidade, suficiente que a equipe tenha as ferramentas mais atuais de engenharia de software e os melhores computadores. (CESPE - 2010 - BASA - Tcnico Cientfico Tecnologia da Informao - Arquitetura de Tecnologia) _____ Certo ____ Errado 6. Sobre a engenharia de software, considere: I. Atualmente todos os problemas na construo de software de alta qualidade no prazo e dentro do oramento foram solucionados. II. Ao longo dos ltimos 50 anos, o software evoluiu de um produto de indstria para um ferramental especializado em soluo de problemas e anlise de informaes especficas.
12
III. Todo projeto de software iniciado por alguma necessidade do negcio. IV. O intuito da engenharia de software fornecer uma estrutura para a construo de software com alta qualidade. (FCC - 2010 - TRE-RS - Analista Judicirio - Analista de Sistemas Suporte) Est correto o que consta em a) III e IV, somente. b) II e III, somente. c) I, II e IV, somente. d) II, III e IV, somente. e) I, II, III e IV. 7. De acordo com Pressman, a engenharia de software baseada em camadas, com foco na qualidade: (FGV - 2010 - BADESC - Analista de Sistemas - Desenvolvimento de Sistemas): Essas camadas so: a) mtodos, processo e teste. b) ferramentas, mtodos e processo. c) mtodos, construo, teste e implantao. d) planejamento, modelagem, construo, validao e implantao. e) comunicao, planejamento, modelagem, construo e implantao. 8. O objetivo da Engenharia de Software estabelecer uma sistemtica abordagem de desenvolvimento, atravs de ferramentas e tcnicas apropriadas, dependendo do problema a ser abordado, considerando restries e recursos disponveis. A Engenharia de Software: (FCC 2008 - METR-SP - Analista Trainee - Cincias da Computao) I. no se confunde com a Cincia da Computao, pois enquanto esta visa o desenvolvimento de teorias e fundamentaes, a Engenharia de Software se preocupa com as prticas de desenvolvimento de software. II. tem como foco nico o tratamento dos aspectos de desenvolvimento de software, o que a diferencia da Engenharia de Sistemas, que trata dos sistemas baseados em computadores, incluindo hardware e software. III. tem como mtodos as abordagens estruturadas para o desenvolvimento de software que incluem os modelos de software, notaes, regras e maneiras de desenvolvimento. IV. segue princpios, tais como, o da Abstrao, que identifica os aspectos importantes sem ignorar os detalhes e o da Composio, que agrupa as atividades em um nico processo para distribuio aos especialistas. correto o que consta em: a) I e II, apenas. b) III e IV, apenas. c) I, II e III, apenas. d) II, III e IV, apenas. e) I, II, III e IV.
13
9. No processo de engenharia de software, os requisitos funcionais podem ser tambm definidos como requisitos de (FCC - 2008 - METR-SP Analista Trainee - Cincias da Computao): a) qualidade. b) capacidade. c) segurana. d) desempenho. e) manuteno. 10. Analise as seguintes afirmaes relativas Engenharia de Software: I. A anlise de requisitos responsvel pela especificao dos requisitos de software e hardware que sero utilizados durante o processo de desenvolvimento de um sistema. II. A anlise de requisitos define a metodologia de programao a ser utilizada no desenvolvimento do sistema. III. A especificao de requisitos fornece ao desenvolvedor e ao cliente os parmetros para avaliar a qualidade logo que o sistema for construdo. IV. A anlise de requisitos possibilita que o engenheiro de software especifique a funo e o desempenho do sistema e estabelea quais so as restries de projeto que o sistema deve atender. Esto corretos os itens: (ESAF - 2004 - CGU - Analista de Finanas e Controle - rea - Tecnologia da Informao - Prova 3): a) I e II b) II e III c) III e IV d) I e III e) II e IV
14
1 BIMESTRE DESENVOLVIMENTO DE SOFTWARE

O que processo de software? O que desenvolvimento de software?
Processo de software um conjunto de atividades que objetivam o desenvolvimento e a evoluo de software. Principais atividades so: ESPECIFICAO: define o que o sistema dever fazer, considerando as suas restries. DESENVOLVIMENTO: produo do software. VALIDAO: checagem se o software faz o que o usurio deseja. EVOLUO: mudanas no software para atender s novas demandas. O processo de engenharia de requisitos envolve criatividade, interao de diferentes pessoas, conhecimento e experincia para transformar informaes diversas (sobre a organizao, sobre leis, sobre o sistema a ser construdo etc.) em documentos e modelos que direcionem o desenvolvimento de software (KOTONYA; SOMMERVILLE, 1998).
Figura 1 Processo de Engenharia de Requisitos (Fonte: adaptado de (KOTONYA;SOMMERVILLE, 1998))
J desenvolvimento de software um conjunto de atividades para especificar, projetar, implementar e testar sistemas de software. As atividades necessrias para o desenvolvimento de software so: especificao, projeto, validao e evoluo.
15
Para o sucesso do desenvolvimento do software necessrio um entendimento dos requisitos de software. No importa se foi bem projetado e/ou codificado; se o software tiver tido uma anlise e uma especificao mal feita, o usurio se sentir frustrado. Anlise de requisitos um processo de descoberta, especificao, modelagem e refinamento. O analista de sistema ou engenheiro de software estabelece o escopo1 do software e durante o planejamento do projeto de software vai sendo refinado e seus detalhes sendo aperfeioados e atravs da criao de diagramas, fluxos e modelos, o problema torna-se compreensvel. O analista/engenheiro e o usurio possuem um papel ativo na anlise e especificao de requisitos. O cliente ou usurio tenta reformular um conceito de funo e desempenho de software, sem detalhes concretos. J o analista, indaga, consulta e soluciona os problemas. Porm, a anlise e a especificao de requisitos parece ser uma tarefa simples, mas no bem assim... A comunicao um fator importante, pois as interpretaes erradas e informaes falsas surgem a todo momento. A ambigidade provvel. Podemos entender o dilema, repetindo a declarao de um cliente annimo:
Sei que voc acredita que entendeu o que acha que eu disse, mas no estou certo que percebeu que aquilo que ouviu no o que eu pretendia dizer...
ESCOPO
O QUE EST SENDO PROJETADO!!!!
ESCOPO: entendimento dos objetivos do projeto, dos resultados esperados e descrio sumria do trabalho a ser realizado. feita na etapa de iniciao do projeto e detalhada na etapa de planejamento. Descreve as caractersticas do produto e o trabalho necessrio para realiz-lo. O consenso inicial sobre o escopo do projeto estabelecido entre pessoas, organizaes ou departamentos de organizaes, sendo uma pessoa, empresa, o cliente, o demandante do servio, o prestador de servios designado ou outra pessoa, para faz-lo.
1
16
REQUISITOS DE SOFTWARE
Figura 2 Levantamento de Requisitos (Fonte: Web)
Segundo o IEEE, define requisitos de software como: Uma condio ou uma capacidade de que o usurio necessita para solucionar um problema ou alcanar um objetivo; Uma condio ou uma capacidade que deve ser alcanada ou possuda por um sistema ou componente do sistema, para satisfazer um contrato, um padro, uma especificao ou outros documentos impostos formalmente; Uma representao documentada de uma condio ou capacidade. Outros conceitos de requisitos de software... Requisitos de um sistema so descries dos servios que devem ser fornecidos por esse sistema e as suas restries operacionais (SOMMERVILLE, 2007); Um requisito de um sistema uma caracterstica do sistema ou a descrio de algo que o sistema capaz de realizar para atingir seus objetivos (PFLEEGER, 2004);
17
Um requisito descrito como uma propriedade que o software deve exibir para resolver algum problema no mundo real (SWEBOK, 2004); Um requisito alguma coisa que o produto tem de fazer ou uma qualidade que ele precisa apresentar (ROBERTSON; ROBERTSON, 2006). Existem em diversos nveis:
Figura 3 Requisitos (extrado da WEB)
IMPORTNCIA DOS REQUISITOS

Quanto mais cedo no ciclo de desenvolvimento do sistema se descobre um erro, mais barato fica para acert-lo. FASE CUSTO DE ERRO REQUISITO 1 ANLISE 5 PROJETO 10 IMPLEMENTAO 20 TESTE 50 MANUTENO 200
Figura 4 Custo dos erros nas fases
A dificuldade de descobrir erros na fase de requisitos est no fato de neste momento da anlise, o analista est descobrindo o funcionamento do negcio que ele desconhece, e ainda a relao analista X usurio muito recente, fazendo com que a relao de confiana ainda esteja em avaliao de ambas as partes. Ambiguidades decorrentes de nossa linguagem, omisses e fatos incorretos, so as principais causas. O uso de inspees, validao dos requisitos atravs de encontros sucessivos com o usurio, ajudam a minimizar estes problemas. Pesquisa realizada na Standish Group com 350 companhias e 8.000 projetos diferentes, onde: Sucesso quando cobre todas as funcionalidades em tempo e dentro do custo;
18
Problemtico quando no cobre todas as funcionalidades exigidas, custo maior e atraso; Fracasso quando o projeto foi cancelado durante o desenvolvimento.
Figura 5 Pesquisa de projetos
As causas podem ser:
Figura 6 Tipos de Fatores
Precisamos dos requisitos para entender o que o cliente quer, para documentar o que o cliente quer e para assegurar a qualidade e a satisfao do cliente. Tambm podemos entender o problema do negcio, documentar o escopo do projeto e definir suas restries e definir os critrios de aceitao e gerenciar as expectativas do cliente.
QUALIDADE DOS REQUISITOS

As qualidades desejveis para um requisito so: Verificvel: Tem que existir uma maneira de verificar se o produto contempla o requisito;
19
Priorizvel: Se todos os requisitos tm a mesma prioridade, h algum problema, etc.; Modificvel: As ideias sempre mudam, logo os requisitos devem mudar tambm (Scott Ambler); Inteligvel, Rastrevel, Completo, Claro (no ambguo).
TIPOS DE REQUISITOS
FUNCIONAIS: os requisitos funcionais descrevem o que o sistema deve fazer, isto , as funes necessrias para atender os objetivos do sistema. Exemplos: Cadastrar Clientes; Fazer Anlise de Crdito; Fazer uma Transao com Banco de Dados; Cadastrar um Registro de Atendimento; Imprimir Relatrio, etc. Outras Definies: o Segundo SOMMERVILLE (2007), so declaraes de servios que o sistema deve prover, descrevendo o que o sistema deve fazer; o PFLEEGER (2004), diz que um requisito funcional descreve uma interao entre o sistema e o seu ambiente; o Ainda em SOMMERVILLE (2007) seria como o sistema deve reagir a entradas especficas, como o sistema deve se comportar em situaes especficas e o que o sistema no deve fazer. NO FUNCIONAIS (RNF ou Suplementares): Declaram as caractersticas que o sistema deve possuir e que esto relacionadas s suas funcionalidades. Com as caractersticas: performance, portabilidade, segurana, usabilidade, qualidade do servio (QoS), confidencialidade, confiabilidade, portabilidade, preciso, integridade, eficincia, entre outras. Estes tipos de requisitos so as causas as principais insatisfaes dos usurios com relao ao software. o Os requisitos no funcionais tm origem nas necessidades dos usurios, em restries de oramento, em polticas organizacionais, em necessidades de interoperabilidade com outros sistemas de software ou hardware ou em fatores externos como regulamentos e legislaes (SOMMERVILLE, 2007). DOMNIO: muito relacionado as regras de negcio ou comportamento prprio do sistema numa determinada aplicao ou no contexto funcionando para uma empresa. Outras Definies: o SOMMERVILLE (2007) diz que descrevem restries sobre os servios ou funes oferecidos pelo sistema; o Ou ainda, as quais limitam as opes para criar uma soluo para o problema (PFLEEGER, 2004);
20
EXEMPLO DE REQUISITOS FUNCIONAIS
O software deve permitir que o atendente consulte o relatrio com os resultados dos testes clnicos de um paciente. [RF01] O software deve permitir que o atendente efetue cadastro de clientes; [RF02] O software deve permitir que o caixa efetue o registro de itens vendidos; [RF03] O software deve permitir que o administrador gere o um relatrio de vendas por ms.
EXEMPLO DE REQUISITOS NO FUNCIONAIS
CONFIABILIDADE: O sistema deve estar disponvel 99% das vezes; SEGURANA: dados devem ser protegidos; DESEMPENHO: sistema deve processar x requisies por segundo; CAPACIDADE: deve suportar x usurios concorrentemente.
EXEMPLO DE REQUISITOS DE DOMINIO
[RN1] os campos referente a oramento projeto vinculado s estaro ativos se o tipo de projeto for vinculado; [RN2] o campo valor total orado para o projeto calculado somando-se os valores definidos para todas as rubricas includas no oramento do projeto, seja ele vinculado ou no-vinculado. [RN3] A soma dos percentuais a ser distribudo entre os fundos includos no plano de aplicao deve ser entre 0 e 100%.
PROBLEMAS COMUNS NOS REQUISITOS
Nem sempre so bvios; So originados de vrias fontes (=conflitos de interesse); Nem sempre retratam um problema que possvel ser expressado por palavras; Sempre mudam; Os usurios nem sempre sabem o que desejam; Os usurios tm uma tendncia de privilegiar a sua rea ou o seu ponto de vista; Os analistas pensam que entendem os problemas melhor do que os prprios usurios!
CLASSES DE REQUISITOS
Os requisitos podem ser vistos em trs classes distintas: o Essenciais; o Importantes; o Desejveis. Em princpio, sistema deve resolver todos os requisitos de essenciais para requisitos desejveis.
21
RECORDANDO!!!!! A especificao de um requisito funcional deve determinar O QUE o sistema deve fazer sem a preocupao de COMO fazer.
ENGENHARIA DE REQUISITOS
A Engenharia de Requisitos o processo pelo qual os requisitos de um produto de software so coletados, analisados, documentados e gerenciados ao longo de todo o ciclo de vida do software (AURUM; WOHLIN, 2005). Pode ser descrita como o processo de descobrir, analisar, documentar e verificar as funes e restries do sistema (SOMMERVILLE, 2003). Em resumo, podemos dizer que tratamento de requisitos envolve atividades de desenvolvimento (Levantamento, Anlise e Documentao de Requisitos), gerncia (Gerncia de Requisitos) e controle da qualidade (Verificao, Validao e Garantia da Qualidade de Requisitos).
Figura 7 Etapas da Engenharia de Requisitos (Fonte: extrado da Web)
22
Ao conjunto de atividades relacionadas a requisitos, d-se o nome de Processo de Engenharia de Requisitos. Descreve as atividades relacionadas INVESTIGAO e DEFINIO DE ESCOPO de um sistema. um processo sistemtico de desenvolvimento de requisitos atravs de um processo cooperativo de anlise onde os resultados das observaes so codificados em uma variedade de formatos e as observaes so constantemente verificadas. Pode ser classificada em: PRODUO: levantamento, registro, comprometimento e verificao; A produo de requisitos responsvel por: Levantar Requisitos; Registrar Requisitos; Obter Comprometimento; Verificar requisitos. obteno de
GERNCIA: controle de mudanas, gerncia de configurao, rastreabilidade e gerncia da qualidade de requisitos. A gerncia de requisitos responsvel por: Controlar Mudanas; Gerenciar Configurao; Implementar Rastreabilidade; Gerenciar Qualidade.
OBJETIVOS DA ENGENHARIA DE REQUISITOS

Estabelecer uma viso comum entre o cliente e a equipe de projeto em relao aos requisitos que sero atendidos pelo projeto de software; Registrar e acompanhar requisitos ao longo de todo o processo de desenvolvimento; Documentar e controlar os requisitos alocados para estabelecer uma baseline para uso gerencial e da equipe de desenvolvimento; Manter planos, artefatos e atividades de software consistentes com os requisitos alocados.
23
TAREFA 02 - QUESTES DE REQUISITOS (0,5)
1) Segundo Ian Sommerville, existe uma srie de tcnicas de validao de requisitos que podem ser utilizadas em conjunto ou individualmente. So elas: a) gerao de casos de teste, revises de requisitos, gerenciamento de mudanas e prototipao. b) revises de requisitos, prototipao, gerao de casos de teste e anlise automatizada da consistncia. c) prototipao, anlise automatizada da consistncia, revises de requisitos e gerenciamento de mudanas. d) gerenciamento de mudanas, anlise automatizada da consistncia, revises de requisitos e gerao de casos de teste. e) anlise automatizada da consistncia, prototipao, gerenciamento de mudanas e gerao de casos de teste 2) Um requisito de software expressa as necessidades e restries colocadas em um produto de software que contribuem para a soluo de algum problema do mundo real. Acerca desse assunto, assinale a opo correta. a) Os contratantes ou clientes so os principais colaboradores envolvidos no fornecimento de informaes para o processo de levantamento ou elicitao de requisitos de software, os demais grupos de pessoas que podem fornecer informaes so considerados de importncia secundria. b) As necessidades dos usurios a serem atendidas por um produto de software constituem a classe de requisitos funcionais, e as restries mencionadas na definio de requisitos constituem a classe de requisitos no funcionais. c) Entre as fontes de informao para a elicitao de requisitos, destacam-se, alm dos colaboradores, o conhecimento do domnio de aplicao em que o software funcionar, o ambiente operacional do software e o ambiente organizacional. d) A tcnica de casos de uso, empregada em alguns modelos de desenvolvimento de software atuais, mais aderente construo de cenrios durante a construo de prottipos que durante a elicitao de requisitos. e) A negociao de requisitos, de forma similar observao do ambiente organizacional, uma atividade tpica da fase de elicitao de requisitos. 3) Sobre os processos de engenharia de requisitos, na elicitao e na anlise ocorre total interao com os stakeholders no sistema, sendo o principal objetivo: a) obteno dos requisitos. b) homologao do sistema. c) elaborao do manual do usurio.
24
d) converso de especificaes em requisitos. e) execuo do estudo de viabilidade do sistema. 4) A respeito de anlise de requisitos, julgue os itens a seguir. I O usurio deve ser capaz de pesquisar tanto no banco de dados inteiro como em uma parte dele. II A interface de usurio para o sistema deve ser implementada em HTML sem frames ou em applets Java. III O sistema deve fornecer vises apropriadas para que o usurio possa ler documentos. IV Cada ordem deve ter um identificador nico (OSID), que o usurio deve poder copiar na rea permanente de armazenamento da conta. V O processo de desenvolvimento do sistema e os documentos devem ser realizados conforme o padro interno da empresa. So requisitos funcionais apenas os itens: a) I, II e III. b) I, II e V. c) ) I, III e IV. d) II, IV e V. e) III, IV e V. 5) Identifique com V as afirmativas verdadeiras e com F, as falsas. ( ) Os requisitos no funcionais restringem o sistema que est sendo desenvolvido e o processo de desenvolvimento que deve ser usado e esto, frequentemente, relacionados s propriedades emergentes do sistema de modo que se aplicam ao sistema em sua totalidade. ( ) A prototipao no considerada uma tcnica usada para validao de requisitos, pois ocorre na fase final do processo de desenvolvimento, representado a entrega do sistema aos usurios finais e clientes. ( ) Pode-se considerar que a entrada para o estudo de viabilidade consiste em um conjunto preliminar de requisitos de negcios, um esboo da descrio do sistema e como esse sistema pretende apoiar os processos de negcios. A alternativa que contm a sequncia correta, de cima para baixo, a: a) V V F b) V F V c) F F V d) F V F e) V V V 6) A engenharia de requisitos ajuda os engenheiros de software a compreender melhor o problema que eles vo trabalhar para resolver. Ela inclui um conjunto de tarefas que levam a um entendimento de qual ser o impacto do software sobre o negcio, do que o cliente quer e de como os usurios finais vo interagir com o software. A funo de negociao no processo de engenharia de requisitos:
25
a) especifica, revisa e valida o problema de modo a garantir que seu entendimento e o entendimento do cliente sobre o problema coincidam. b) refina e modifica os requisitos. uma ao de modelagem de anlise composta de vrias tarefas de modelagem e refinamento. c) define quais so as prioridades, o que essencial, o que necessrio. Clientes, usurios e outros interessados so solicitados a ordenar os requisitos e depois discutir os conflitos de prioridade. d) ajuda o cliente a definir o que necessrio. e) define o escopo e a natureza do problema a ser resolvido. 7) Requisitos no-funcionais esto diretamente relacionados com a satisfao dos usurios. Assinale a alternativa que no indique um requisito no-funcional: a) O sistema de arquivos deve ser protegido, para acesso, apenas, de usurios autorizados. b) O software deve ser implementado usando os conceitos de orientao a objetos. c) O tempo de desenvolvimento do software no deve ultrapassar seis meses. d) O software poder ser executado em plataforma windows e linux. e) O software deve emitir relatrios de vendas a cada quinze dias. 8) As declaraes de servios que o sistema deve fornecer, de como ele deve reagir a entradas especficas ou se comportar em determinadas situaes, so chamadas de requisitos: a) No-funcionais b) De domnio. c) De sistema. d) Funcionalidades. e) De usurio. 9) Considerando-se a especificao de requisitos de um software, incorreto afirmar: a) a fase de especificao de requisitos pode ser iniciada logo aps as fases de anlise e projeto. Por essa razo, fundamental que haja a participao ativa do usurio. b) h tcnicas para a elicitao dos requisitos; entre elas, est o uso de entrevista e brainstorm com os potenciais usurios. c) quanto mais cedo for identificado um problema na fase de anlise de requisitos, menor ser o custo de corrigi-lo. d) o gerenciamento de requisitos contempla um conjunto de atividades que auxiliam no controle e alteraes dos requisitos durante a execuo projeto. e) o seu objetivo representar as necessidades e restries dos usurios de um sistema.
26
ELICITAO DE REQUISITOS
A parte mais rdua na construo de um software consiste exatamente em identificar o que construir. Nenhuma outra parte do trabalho compromete tanto o resultado do trabalho se elaborado de forma incorreta. Nenhuma outra parte oferece tanta dificuldade para efetuar correes posteriores." Fred Brook Uma das partes mais crticas do processo de desenvolvimento de software a elicitao (levantamento) de requisitos. H estudos que indicam que os requisitos detectados depois do software implementado ou erros de anlise custam at vinte vezes mais caros que qualquer outro tipo de erro. FASES DE UMA ELICITAO DE REQUISITOS Um projeto de elicitao de requisitos tm as seguintes fases:
Figura 8 Etapas de uma Elicitao de Requisitos (Fonte: extrado da Web)
Nesta etapa um dos artefatos2 principais a criao do documento viso.
Produto de trabalho do processo: os papis usam os artefatos para executar atividades e produzem artefatos ao executarem as atividades (http://www.wthreex.com/rup/manuals/intro/kc_artifact.htm acessado em 08/12/2011)
27
Figura 9 Esquema para criao do documento viso (Fonte: extrado da Web)
Figura 10 Erros de Requisitos (Fonte: extrado da Web)
A elicitao de requisitos corresponde a identificar junto aos stakeholders3 quais so os objetivos do sistema ou produto, o que deve ser acompanhado, como o sistema ou produto se 'encaixa no contexto das necessidades do negcio e, finalmente, como ser a utilizao do sistema ou produto no dia-a-dia. um processo complexo, porm simples. H diversas razes para a complexidade, dentre elas, destacam-se os seguintes problemas:
Qualquer pessoa ou organizao que tenha interesse, ou seja, afetado pelo projeto. A palavra deriva de stake (interesse, participao, risco) e holder (aquele que possui).
28
Escopo: Os limites do sistema so geralmente definidos de forma incompleta, ou os clientes4 ou usurios especificam detalhes tcnicos desnecessrios; Compreenso: Os clientes ou usurios geralmente no esto completamente certos das necessidades, tm uma pouca compreenso ou do domnio do seu negcio, omitem informaes que julgam bvias, etc.; Volatilidade: Os requisitos mudam o tempo todo.
OBJETIVOS DA ELICITAO DE REQUISITOS

O objetivo da elicitao de requisitos obter conhecimento relevante para o problema e prover o mais correto entendimento de o que esperado do software/sistema.
PASSOS PARA A ELICITAO DE REQUISITOS

Avaliar a viabilidade tcnica e de negcio para o sistema proposto; Identificar as pessoas que vo auxiliar a especificar os requisitos e compreender seus preconceitos organizacionais; Definir o ambiente tcnico no qual o sistema ser instalado; Identificar regras de domnio que limitam a funcionalidade ou desempenho do software que ser construdo; Definir um ou mais mtodos de elicitao de requisitos; Solicitar participao de vrias pessoas para que os requisitos sejam definidos a partir de diversos pontos de vista; Identificar claramente a justificativa de existncia para cada requisito registrado; Identificar requisitos ambguos que sero candidatos a prototipao.
H uma diferena entre cliente e usurio. O primeiro refere-se a quem contratou o desenvolvimento do sistema que no necessariamente ser quem utilizar o sistema (usurio).
29
QUESTES QUE PRECISAM SER RESPONDIDAS
Figura 11 Questes que precisam ser respondidas
DOCUMENTAO DO ELICITAO DE REQUISITOS

Os documentos criados atravs da elicitao de requisitos iro depender do tamanho do sistema que ser construdo. Estes documentos incluem as seguintes informaes: As necessidades e viabilidade estruturadas; O limite de escopo do software/sistema; Lista de clientes, usurios e outros stakeholders participaram da atividade de elicitao de requisitos; Descrio do ambiente tcnico do sistema; Lista de requisitos e as regras de domnio aplicveis a cada um. Conjunto de cenrios de uso capazes de prover uma ideia do uso do sistema ou produto sob diferentes condies de operao; Qualquer prottipo que eventualmente desenvolvido para melhor definir os requisitos. tenha sido que
Cada um destes documentos deve ser revisado por todas as pessoas que tenham participado da elicitao de requisitos.
30
IDENTIFICAO E ELICITAO DE REQUISITOS

O sucesso no desenvolvimento de um projeto de software depende basicamente da elicitao de requisitos, pois, a base que permitir ao Analista tirar concluses sobre as situaes, problemas ou fenmenos e, assim, sugerir propostas que possam contribuir para a soluo do problema. Entretanto, esta atividade, nem sempre est presente no processo de desenvolvimento, raramente ela elaborada de forma metodolgica, geralmente tem uma abordagem intuitiva. As informaes podem ser identificadas ou encontradas em diversas fontes, como: analista de negcio, clientes, documentos, Domain Experts5 especificaes tcnicas, sistemas legadospatrocinadores ou usurios.
IDENTIFICAO DOS REQUISITOS
Tambm chamada de descoberta de requisitos, tem o objetivo de identificar os requisitos a ideia inicial do sistema para compreender o domnio do problema. Identificar as funcionalidades do software que deve ter para atender as necessidades do usurio. Para identificar podemos fazer as seguintes perguntas para identificar tambm as principais caractersticas do software:
Quanto a performance, qual tempo de resposta adequado?
Quais funcionalidades ele deve ter?
O que o software deve fazer?
Quanto usabilidade, o software identifica visualmente a empresa e possui interface amigvel?
Quais so os requisitos de segurana que o software precisa?
Especialista em uma ou mais rea de negcio.
31
Os requisitos encontrados no devem ser descritos neste momento, precisamos apenas identific-los (informao de alto nvel). Os requisitos de software podem ser identificados no texto da declarao do problema (geralmente so verbos que identificam algumas aes). Este documento classifica os requisitos em dois tipos.
PROBLEMAS NA IDENTIFICAO DOS REQUISITOS
ESCOPO: Limite do sistema mal definido ou detalhes tcnicos desnecessrios confundem os objetivos globais; ENTENDIMENTO: Clientes/usurios no esto completamente certos dos que necessrio, no tem pleno entendimento do domnio do problema, tm dificuldade de comunicar as necessidades, tm pouca compreenso das capacidades; VOLATILIDADE: Requisitos mudam com o tempo.
EXEMPLO DE DECLARAO DO PROBLEMA
Acompanhamento das estatsticas de aprendizado do aluno e da turma (professor); Informao: Relatrio de aproveitamento do aluno e da turma(s). REQUISITOS FUNCIONAIS: o Sistema deve registrar as principais aes de cada usurio; o O sistema deve fornecer um relatrio do aproveitamento do aluno; O relatrio de aproveitamento do aluno deve conter o tempo de uso do software, o nmero de exerccios feitos, o nmero de acertos e o de erros. o O sistema deve fornecer um relatrio do aproveitamento da turma. O relatrio de aproveitamento da turma deve conter a mdia e o desvio-padro dos seguintes dados: tempo de uso do software, nmero de exerccios feitos, nmero de acertos e erros de cada exerccio. REQUISITOS NO-FUNCIONAIS: o O sistema deve usar grficos comparativos do aproveitamento do aluno com a mdia da turma; o O sistema deve usar cores na construo dos grficos; o O tempo de resposta na elaborao do relatrio no pode ser superior a 15 segundos.
CARACTERSTICAS DA ELICITAO DE REQUISITOS

Definir as tcnicas de coleta de requisitos baseadas em fatores operacionais, tticos e financeiros;
32
Criar um planejamento com objetivo de alcanar as metas estabelecidas, tais como: Prazos, Custos e Qualidade; Promover a integrao e o comprometimento de todos os envolvidos no processo, por exemplo: Clientes, Fornecedores, Usurios e o Patrocinador; Identificar os documentos e procedimentos que definem as polticas de negcios da empresa.
DIFERENA ENTRE UMA BOA E UMA M ELICITAO DE REQUISITOS
Figura 12 Diferena entre uma boa e uma m elicitao (Fonte: extrado da Web)
33
TAREFA 03 ELICITAO DE REQUISITOS (0,5)
No caa-palavras abaixo, encontre os itens:
34
TCNICAS PARA ELICITAO DE REQUISITOS No existe maneira nica de especificar os requisitos. A identificao e elicitao de requisitos uma tarefa que parece simples, mas, no devemos nos enganar, s vezes, para obtermos algumas informaes exigida muita dedicao, persistncia e tcnica. Esta parte apresenta e discute as principais tcnicas para identificao e elicitao de requisitos de software. Cenrios: representar tarefas que executam e as que desejam executar; Tcnicas tradicionais: questionrios, entrevistas, anlise de documentao existente; Tcnicas de elicitao de grupo: Dinmica de grupo;
Prototipao: quando existe alto grau de incerteza e necessita de um rpido feedback.
Tipos de Tcnicas Existem vrias tcnicas para a elicitao de requisitos, todas elas possuem seus prprios conceitos, vantagens e desvantagens. Dentre elas, destacam-se (KENDALL; KENDALL, 2010; KOTONYA; SOMMERVILLE, 1998; AURUM; WOHLIN, 2005): WORKSHOP DE REQUISITOS: idealizado para encorajar o consenso acerca dos requisitos da aplicao e acerca das aes a serem tomadas em um curto intervalo de tempo. Formato: reunio intensiva (mximo 2 dias) com pessoas chaves visando criar ou revisar as principais funcionalidade do sistema em desenvolvimento, com a participao de um mediador; QUESTIONRIOS: o uso de questionrios possibilita ao analista obter informaes como postura, crenas, comportamentos e caractersticas de vrias pessoas que sero afetas pelo sistema; Quem so os usurios (ou perfis de usurio)? Quem o cliente? Eles tm necessidades diferentes em relao ao sistema? Onde mais pode ser encontrada uma soluo para este problema? Estas questes nos foram a ouvir antes de sair propondo uma soluo para o problema. OBSERVAO: consiste em observar o comportamento e o ambiente dos indivduos de vrios nveis organizacionais. Utilizando-se essa tcnica, possvel capturar o que realmente feito e qual tipo de suporte computacional realmente necessrio. Ajuda a confirmar ou refutar informaes obtidas com outras tcnicas e ajuda a identificar tarefas que podem ser automatizadas e que no foram identificadas pelos interessados;
35
ANLISE DE DOCUMENTAO: pela anlise de documentos existentes na organizao, analistas capturam informaes e detalhes difceis de conseguir por entrevista e observao. Documentos revelam um histrico da organizao e sua direo. CENRIOS: com o uso desta tcnica, um cenrio de interao entre o usurio final e o sistema montado e o usurio simula sua interao com o sistema nesse cenrio, explicando ao analista o que ele est fazendo e de que informaes ele precisa para realizar a tarefa descrita no cenrio. O uso de cenrios ajuda a entender requisitos, a expor o leque de possveis interaes e a revelar facilidades requeridas; PROTOTIPAGEM (PROTOTIPAO): um prottipo uma verso preliminar do sistema, muitas vezes no operacional e descartvel, que apresentada ao usurio para capturar informaes especficas sobre seus requisitos de informao, observar reaes iniciais e obter sugestes, inovaes e informaes para estabelecer prioridades e redirecionar planos; VANTAGENS: o permitem aos clientes e usurios do sistema experimentar o sistema; o entendendo melhor como o sistema pode ser usado para dar suporte aos seus trabalhos; o mal-entendidos entre projetistas e usurios podem ser identificados quando a funcionalidade do sistema demonstrada usando o prottipo; o funes que esto faltando podem ser detectadas usando o prottipo; o durante o desenvolvimento de um prottipo, requisitos incompletos e inconsistentes so descobertos. DESVANTAGENS: o custo do desenvolvimento de um prottipo; o tempo requerido para desenvolver um prottipo (que pode aumentar o tempo de entrega ao usurio); o o uso de um prottipo pode induzir os usurios a prestarem mais ateno na interface com o usurio do que nos requisitos da aplicao; o os usurios podem tornar-se familiares com uma interface com o usurio antes da verso final do sistema estar desenvolvida. LINGUAGEM NATURAL: na maioria das organizaes, os requisitos so escritos como pargrafos de linguagem natural, adicionados por diagramas e equaes. o Vantagem: Linguagem natural a nica notao que geralmente entendvel por todos os leitores potenciais dos requisitos. o Desvantagem: Os requisitos em linguagem natural podem ser ambguos, pouco claros e causar mal entendidos.
36
Exemplo: Casos (sentenas).
de
Uso
Lista
de
Caractersticas
DINMICAS DE GRUPO: h vrias tcnicas de levantamento de requisitos que procuram explorar dinmicas de grupo para a descoberta e o desenvolvimento de requisitos, tais como: brainstorming, brainswriting e JAD.
ETNOGRAFIA
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. 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 de sistema implcitos, 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: frequncia 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;
37
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 frequentemente usada para complementar descobertas obtidas por outras tcnicas.
ENTREVISTAS
Tcnica amplamente utilizada, que consiste em conversas direcionadas com um propsito especfico e com formato perguntaresposta. Seu objetivo descobrir problemas a serem tratados, levantar procedimentos importantes e saber a opinio e as expectativas do entrevistado sobre o sistema. Deve ser bem planejada e preparada cuidadosamente para saber quem foi entrevistado, definir os objetivos da entrevista, preparar antecipadamente as questes que sero formuladas (ou parte delas).
Etapas
Apresentar-se; Repassar a agenda (objetivos, patrocinador, motivo da escolha do entrevistado); Postura do entrevistador: credibilidade, iseno, discrio; no criar ressentimentos; Deixar o entrevistado falar (reduo da interferncia); Direcionar a discusso para os objetivos; Evitar perguntas fechadas; No ultrapassar o tempo; Notar sinais de impacincia.
Forma de Entrevistar
Relacione a parte da entrevista c/ partes do sistema; Obtenha pontos de vista alternativos; Solicite detalhes do item que voc estiver interessado; Estabelea a dependncia do assunto com outros; Confirme os dados obtidos; Focalize os requisitos (no os problemas tcnicos); No confunda sintomas com o problema.
Perguntas que devem ser respondidas
Quem so o cliente e o usurio? Possuem necessidades diferentes? Quais so suas: Capacidades, Backgrounds, Ambientes, etc. Qual o problema?
38
Como resolvido atualmente? Qual a razo para resolv-lo? Qual o valor de uma soluo bem-sucedida? Onde mais uma soluo pode ser encontrada?
BRAINSTORMING
Representantes de diferentes grupos de interessados engajam-se em uma discusso informal para rapidamente gerarem o maior nmero possvel de ideias focadas em um objetivo claro e pr-definido. Regras devem ser seguidas em uma sesso de Brainstorm: No permitir crticas ou debate; Deixar a imaginao voar; Gerar tantas ideias quanto for possvel; Mudar e combinar ideias; Sesso consiste em duas fases: GERAO DE IDEIAS e CONSOLIDAO; Processo relativamente no estruturado que pode ou no produzir a mesma qualidade ou nvel de detalhe de outros processos. TECNICAS PARA CONDUZIR Inicie a sesso divulgando CLARAMENTE os objetivos; Certifique-se que cada participante compreendeu exatamente os objetivos (obter feedback); Convide escriba para anotar cada ideia no flip-chart; Anote com clareza e preciso evite telegrafar; No deixe que se percam as ideias havendo vrias ideias simultneas, pea que cada um anote as suas ideias numa folha para depois pass-las para o flip-chart. Incentive a participao de todos; Evite que ideias sejam discutidas, seja qual for o pretexto; No tente esmiuar, detalhar ou entender uma ideia; No permita que hajam justificativas para uma ideia; A sesso deve durar entre 15 e 60 minutos; O clima deve ser descontrado, mas no CIRCO! Aps uma sesso de Brainstorming as pessoas PRECISAM relaxar! Aps a sesso de brainstorming, deve haver um estudo de viabilidade e adequao para cada ideia (organizar as ideias).
BALDE DE GUA GELADA Isso no possvel... No temos tempo para... Tudo isso j foi tentado... No momento no estamos em condies...
39
Na prtica as coisas so diferentes... Se isso fosse til, algum j teria tido a ideia... Isso muito antiquado... Isso moderno demais... Vamos voltar a conversar no incio do prximo ano... J temos muitos projetos... Voc sabe que isso no funciona... Vamos nomear uma comisso para cuidar disso... No temos nada com isso... No problema do nosso departamento... Vamos esperar os acontecimentos... Melhor seria pensarmos um pouco mais... Outra vez voc com essas suas ideias... Se voc acha que no nosso Pas isso vai funcionar... Isso contra o regulamento... Parece bom, mas... duvido que funcione... Isso s vai dar mais trabalho pr gente ... Acho que algum vai ficar furioso quando souber disso...
Exemplos: 1) Contexto: automao de iluminao. Aspecto surgido no brainstorming: Configurao de iluminao automtica. Sentena descritiva: O dono de casa deve poder definir uma programao da iluminao da casa baseado nos horrios do dia. 2) Contexto: Sistema de entrada de ordens de venda. Aspecto surgido no brainstorming: Rapidez. Sentena descritiva: O tempo de resposta deve ser suficientemente bom para no interferir na realizao das aes do processo de venda. 3) Contexto: Sistema de rastreamento de falhas. Aspecto surgido no brainstorming: Notificao automtica. Sentena descritiva: Todos os grupos cadastrados devem ser notificados por email quando houver alguma modificao no processo de fabricao.
BRAINSWRITING
Dividir os participantes em grupos de 4 ou 5 pessoas. Os grupos recebem uma questo. O trabalho: - Escrever a sua opinio sobre a questo; - Ao terminar, colocar a folha no centro da mesa; - Pegar a folha de respostas de outro integrante do grupo; - Criticar as colocaes encontradas;
40
- Criticar todos os trabalhos do grupo, por escrito; - Completado o ciclo, o grupo pode receber nova pergunta; - Os presentes criticam todas as posies dos grupos. Observaes: - Pode haver um relator por grupo; - Cada grupo pode receber uma questo diferente. - Exige um relator do trabalho final.
EXERCCIOS
1. Vamos conduzir uma entrevista: em dupla fazer uma entrevista a respeito de um sistema de controle de tarefas. Estas tarefas so semanais, feitas de forma individual com notas entre 1,0 e 10,0 pontos. 2. Baseado na tcnica BRAINWRITING em grupo de cinco pessoas, discutir sobre o assunto: COMO RESOLVER O PROBLEMA DE QUALIDADE DO SERVIO NA EDUCAO.
41
J AD Tradicionalmente, JAD tem sido um mtodo utilizado por profissionais de processamento de dados e usurios para definio de requisitos de sistemas. Por isto o nome JAD Joint Application Design (ou Development). Atualmente, o JAD tem sido um mtodo utilizado por todos que desejam trabalhar em projetos, sejam da rea de informtica ou no, ou que queiram tomar decises que afetem mltiplas reas da organizao. O conceito de JAD surgiu na IBM em 1977, e entrou no Brasil na dcada de 80, mas s comeou a ser utilizado efetivamente, aps alguns nomes de peso na anlise de sistemas avalizarem tal metodologia. Tcnica que rene determinado nmero de pessoas em sesses bem estruturadas para, com tempo e esforo reduzidos, consolidar um objetivo pr-determinado.
Figura 13 JAD
ETAPAS PARA PREPARAR UMA REUNIO JAD
Figura 14
Etapas para preparao do JAD
42
PREPARAO
- OBJETIVOS
Garantir a escolha dos participantes apropriados; Garantir que a Agenda seja preparada de forma adequada; Garantir o acordo do Grupo quanto aos objetivos e produtos a serem obtidos; Garantir que todo o material necessrio tenha sido providenciado.
- ETAPAS
1. Examinar, se a utilizao do JAD adequada; 2. Planejar as Sesses (quantas, de que tipo, quando...); 3. Elaborar a Perspectiva Gerencial (ideia clara do projeto e da sesso, obtidas do Patrocinador do projeto finalidade, escopo, objetivos e restries); 4. Familiarizar-se com as reas de negcio sob estudo (glossrio, entrevistas preliminares bem curtas,...); 5. Preparar a Agenda da Sesso (roteiro de passos a serem seguidos); 6. Preparar os participantes (mtodos e abordagem da sesso, informaes a providenciar previamente, resultados de sesses anteriores); 7. Preparar a Agenda Detalhada (desdobramento do roteiro da sesso com durao prevista para cada item, lembretes, dicas, ...); 8. Preparar as ferramentas para documentao (ex.: Metodologia p/ Mapeamento de Processos e ARIS da IDS SCHEER, Questionrios e Formulrios).
Figura 15 Responsabilidades na etapa de Preparao do JAD
43
- AGENDA
Identificar a finalidade e os objetivos da reunio (Sesso); Identificar os produtos (resultados esperados); Identificar as informaes conhecidas; Esboar as etapas da agenda; Verificar se etapas so logicamente coerentes; Identificar os participantes provveis; Identificar as etapas que os participantes no tm condio de realizar na sesso; Identificar que informaes devem ser providenciadas antes da sesso, para viabilizar o item 7; Rever: esboo satisfaz os itens 1 e 2 ? Refinar o trabalho, incluindo a documentao necessria. CRITRIOS PARA A ESCOLHA DOS PARTICIPANTES: Possui conhecimento e capacidade analtica em relao ao assunto; Tem habilidade na resoluo de divergncias e sabe resolver suas diferenas em confrontos de ideias e pontos de vista; Pode ser afetado pelas decises tomadas, tendo a oportunidade de compartilhar suas expectativas com o grupo; Concorda de antemo com as regras de soluo de conflitos e de tomada de deciso determinadas pelo grupo; Tem disponibilidade para participar com criatividade e eficcia;
EXEMPLO DE CARTA CONVITE PARA: Ver Lista de Distribuio 2002 DE: Yyyyyy Patrocinador do projeto Cargo REF.: Projeto XPTO Sesso de Trabalho Foi selecionado para participar da Sesso de Mapeamento de Processos do projeto XPTO. Esta Sesso integra o mtodo JAD, j apresentado, que vem sendo utilizado com sucesso por grandes empresas. O seu tempo ser mais produtivo do que se voc participasse de entrevistas individuais. Voc foi selecionado pela sua habilidade, relao com o assunto e capacidade de contribuir com ideias criativas e indispensveis produo de um trabalho de alto nvel. Voc ter meu completo apoio e suporte. A Sesso ter a durao de trs dias, de 27/05/2002 at 29/05/2002, com realizao na parte da manh de cada dia, das 9:00h s 13:00h, na Sala Nxxx do SENAI Artes Grficas, localizado na Rua So Francisco Xavier N xx, bairro da Tijuca. Veja em anexo, a agenda de convocao detalhando a Finalidade, Objetivos, Escopo (Tpicos), Lder da Sesso, Participantes, Documentos a Levar e Informaes Necessrias, Restries e Eventuais Observaes. Quaisquer dvidas devero ser imediatamente encaminhadas ao Sr. Xxxxxx,. Grato pela sua cooperao, Yyyyyy Patrocinador do Projeto XPTO. Rio de Janeiro, 21 de Maio de
44
MODELO DE AGENDA DE CONVOCAO:
Figura 16 Modelo de Agenda TOPICOS PARA A AGENDA PADRO
Introduo: Breve reviso do mtodo JAD (s se no for conhecido); Horrios, intervalos, facilidades, etc.; Apresentao dos participantes; Apresentao da agenda, esclarecendo o que ser tratado em cada etapa.
Reviso da Perspectiva Gerencial: Definies estabelecidas p/ o projeto pelo Patrocinador; Abertura pelo Patrocinador (s para 1 sesso): Discurso de 5 min. mostrando a importncia do projeto no contexto do negcio, o que se espera alcanar e porque aquela equipe foi escolhida. Viso da rea de Informtica: Rpida posio do Engenheiro de Software sobre o andamento dos trabalhos, prximas etapas e informaes tecnolgicas de interesse. Regras de Conduta: Cdigo de cooperao estabelecido pelo Facilitador com o Grupo, para maior produtividade da sesso.
45
Abordagem da Sesso: Roteiro passo a passo das etapas especficas (dirigidas aos produtos metodolgicos) para se alcanar os objetivos da sesso. Reviso das Pendncias: Atualizao do Controle de Pendncias documentando o item, data de registro, situao, responsvel pela soluo, data de trmino prevista. Reviso Geral: Reviso do material produzido na sesso, verificando se est coeso e de acordo com o que estava previsto. Avaliao e Encerramento da Sesso: Avaliao dos participantes sobre o mtodo desempenho do lder, para melhoria contnua.
DEVERES DAS PESSOAS CONVOCADAS PARA O JAD
usado
e o
Avaliar a agenda divulgada; Reunir informaes e arquivos; Convocar subordinados para esclarecimentos; Preparar-se para contribuir efetivamente durante a realizao da reunio; Estar certo de que compreendeu os objetivos e tpicos, questionando-se: Onde posso contribuir melhor? O que no entendo e no me compete? (Devo silenciar nestas horas) O que gostaria de alcanar e o que me satisfaz se for alcanado? Que elementos devo levar para a reunio? Preciso realizar contatos prvios? Usarei recursos audiovisuais? A sala suporta sua utilizao? O que preciso alterar na minha agenda, em funo da reunio?
ATIVIDADES A SEREM REALIZADAS NO DIA ANTERIOR A SESSO
Providenciar todo o material necessrio: Transparncias; Folhas de flip-chart; Projetor; Tela; Canetas para quadro; Material a ser projetado e/ou transparncias; Fita colante; Pastas do Projeto JAD para os participantes, etc. Revisar a Agenda Detalhada (aquela que contm o script a ser seguido pelo facilitador). Posicionar os documentadores quanto aos pontos em que so esperadas as suas participaes, atravs de reunio em que lhes disponibilizada uma cpia da Agenda Detalhada. Providenciar equipamentos dos documentadores: Micros com os softwares necessrios instalados, Impressoras, Questionrios, Checklists, Formulrios, etc.
46
Arrumar a sala de reunio. Montar e testar equipamentos.
Figura 17 Layout da sala de reunio de JAD
SESSO
OBJETIVOS
Realizar reunio com os participantes definidos na fase de Preparao; Produzir as informaes necessrias para obteno dos resultados previstos na fase de Preparao; Buscar a criao de sinergia do Grupo no desenvolvimento de ideias e conceitos; Obter consenso quanto aos resultados.
ETAPAS
Preparao do Ambiente (condies adequadas, arrumao das mesas, equipamentos, material necessrio, auxlios visuais, pastas dos participantes) no dia anterior ao da realizao da sesso; Conduo da Sesso (conforme Agenda Detalhada); Documentao (providenciar ferramentas formulrios, micro, software, impressora,...; observar passos da Agenda Detalhada; documentar decises; documentar detalhes; ler o que j foi documentado; gerar a documentao do dia para os participantes);
47
Encerramento da Sesso (verificar atendimento de todos os itens, avaliar a sesso, entregar a documentao produzida, apresentar os resultados da ltima sesso);
Figura 18 Responsabilidades da etapa Sesso de JAD TCNICAS PARA APOIAR A SESSO
Figura 19 Tcnicas de Apoio
Passo 1: Definir o problema e despersonaliz-lo, escrevendo-o no quadro ou no chart, para que se torne problema do grupo; Passo 2: Fazer o grupo gerar possveis solues;
48
Passo 3: Avaliar as solues com o grupo, atravs de critrios estabelecidos, evitando que algum se considere dono de alguma delas; Passo 4: Fazer o grupo decidir sobre a mais adequada; Passo 5: Fazer o grupo determinar o mtodo de implementao da soluo escolhida, se necessrio; Passo 6: Se problema no desapareceu, coloc-lo na Lista de Pendncias.
AVALIAO DA SESSO
49
50
Figura 20 Relatrio de Avaliao de Sesso AVALIAO DE ACORDO COM O TOTAL OBT IDO
Aps Preenchidos Todos os Itens da Avaliao, Some Todos os Graus e Obtenha o Total Geral: Entre 0 e 7 significa que suas reunies esto boas; De 8 a 14 suas reunies podem ser melhoradas; De 15 a 22 suas reunies comeam a preocupar; De 23 em diante, suas reunies andam MAL, muito h que ser feito para que alcancem o nvel ideal. fundamental que cada um tambm se inclua como causador dos problemas e disfunes da lista de verificao. No se deve julgar somente os outros, mas principalmente ns mesmos.
51
ANALISADOR DA REUNIO PARA TODOS OS PARTICIPANTES
Figura 21 Modelo de anlise da reunio
REVISO
Rever a documentao produzida na sesso; Examinar possveis melhorias na sistemtica adotada.

ETAPAS
Rever a Documentao (verificar informaes incompletas, corrigir falhas de comunicao entre facilitador e documentadores, sumarizar os resultados, encaminhar verso definitiva da documentao para os participantes); Examinar Avaliaes (visa processo permanente de aperfeioamento; efetua tabulao e anlise comparativa entre as sesses); Preparar a Pasta do Projeto JAD contendo: o Perspectiva Gerencial; o Plano de Sesses; o Carta-convite para participao do grupo; o Agenda de cada sesso; o Lista de Participantes de cada sesso; o Documentao produzida em cada sesso; o Questionrios de Avaliao.
52
Figura 22 Responsabilidades na etapa de Reviso do JAD
Ao final da reviso deve ser preparado um resumo do que foi produzido na sesso, para ser apresentado ao Patrocinador do projeto.
PAPEIS DE CADA UM DENTRO DA REUNIO

H dois grupos de participantes:
O CLIENTE (PATROCINADOR)
Detm autoridade formal sobre as reas de negcios afetadas pelo sistema. O cliente estabelece as diretrizes e objetivos do projeto. responsvel pela abertura da primeira sesso de trabalho, na qual o grupo ter oportunidade de sentir o real interesse da administrao superior pelo sucesso do projeto e em dar o seu apoio.
ENGENHEIRO DE SOFTWARE
o responsvel pelo sucesso ou fracasso do projeto; Participa do JAD na condio de membro da equipe; o principal contato do Lder da Sesso; Familiariza o Lder da Sesso com o projeto e com a equipe envolvida.
53
EQUIPE
So os responsveis pelo contedo da sesso. Representam as reas envolvidas no projeto, incluindo a de informtica. Os participantes so escolhidos entre as pessoas-chave das reas de negcio, seja no nvel operacional ou no. O importante que, na sesso, no h distino hierrquica, todos so iguais.
OBSERVADOR
Interessado no projeto especificamente ou em conhecer a sistemtica utilizada; No um participante no podendo, por isso, opinar durante a sesso.
DOCUMENTADOR
o responsvel pelo registro das decises e especificaes produzidas; No caso Xerox, ele tambm um membro de equipe; Segue orientao do Lder da Sesso no que respeita aquilo que considerado relevante para ser documentado.
LDER DE SESSO OU FACILITADOR
o responsvel pela conduo da reunio. Deve ser um guia do grupo. O seu trabalho conduzir os participantes ao longo da agenda, garantindo que todos so ouvidos e que h consenso em torno das decises tomadas. Deve ser um facilitador.
PERFIL DO LDER
Pessoa com facilidade de comunicao; Capacidade de sntese; Facilidade para resumir, esclarecer e sumarizar ideias e conceitos, inclusive escolhendo as frases mais apropriadas que reflitam os argumentos/ideias apresentados pelos participantes; Falar claramente, precisamente; Falar pausadamente e sem bairrismos; Capacidade de dirigir discusses para o ponto objetivo; Evitar disperses em consideraes no relevantes; Evitar dilogos paralelos; Controlar o horrio de incio e fim dos trabalhos; Controlar e informar passo a passo as etapas da agenda; Separe as ideias das pessoas; Mostre um interesse natural; Oua bem, inclusive com os olhos; Mantenha os papis claramente definidos; No confundir os participantes com jarges da rea de sistemas.
54
DICAS PARA SER UM BOM LDER
No No No No No No No No No
se irrite; se ofenda; brigue; monopolize; seja o dono da verdade; faa o tipo sabido leve tudo na brincadeira; ignore algum participante; permita uma dupla em debate.
DOCUMENTADOR OU ESCRIBA
um auxiliar do lder de sesso. responsvel pelo registro das decises e especificaes produzidas. Apenas as informaes relevantes so documentadas, segundo orientao do lder de sesso.
OBSERVADORES
So interessados em conhecer a sistemtica utilizada ou interessados no projeto especificamente. Os observadores no so participantes, portanto, no esto autorizados a opinar durante a sesso.
FIGURINHAS DIFCIEIS NA REUNIO
O ATRASADINHO
Sempre chega atrasado s reunies; D seu show na chegada; Insiste em interromper a sequncia de argumentao do grupo. Sempre que algum chegar atrasado, evidencie sutilmente, atravs do cumprimento. Convide-o a olhar a memria do grupo e no faa uma reviso. Isso seria punir os que chegaram na hora.
O QUE SAI MAIS CEDO
Abala a energia e a moral do grupo saindo da reunio antes de seu trmino. Na primeira oportunidade, procure saber o motivo do padro de comportamento. Sugira, ao agendar a prxima reunio, que todos optem por um horrio em que podero estar integralmente.
O DISCO QUEBRADO
Joga areia em todas as ideias; Superctico e crtico; Sempre esfriando o entusiasmo do grupo, dizendo algo do tipo isso nunca vai funcionar.
55
Evidenciar para o grupo os pontos que o ctico no concorda, buscando obter consenso do grupo.
O MENEADOR
Expressa discordncia ativamente via linguagem corporal e tiques no-verbais, tais como: Revirar os olhos, balanar a cabea, cruzar e descruzar os braos, etc; Indiretamente influencia o grupo a rejeitar uma ideia, uma reunio, etc. Procure interpel-lo, questionando se ele discorda de alguma coisa, ou se gostaria de enriquecer o que foi dito.
O COCHICHADOR
Vive cochichando durante as reunies, mantendo conversas paralelas; Coloca o lder da sesso, assim como os membros do grupo, em segundo plano. Neste caso, s intervir quando houver absoluta certeza de que os cochichos esto sendo negativos para a reunio. Algumas vezes, basta aproximar-se dos cochichadores para que a conversa diminua.
O DESINTERESSADO
Senta afastado da mesa ou no fundo da sala; Expressa desaprovao ou desinteresse, ignorando os procedimentos; Pode cochilar, ler alguma coisa, ficar rabiscando papis, para evitar qualquer tipo de engajamento na sesso. Uma boa estratgia envolver o desinteressado em alguma atividade de apoio.
O AGRESSIVO
Dispara ataques verbais e pessoais contra outros membros do grupo e/ou contra o lder da sesso; Constantemente ridiculariza um determinado ponto de vista ou posio de outra pessoa. Relembre as regras do grupo, lembrando que devemos respeitar as opinies alheias. Quando estas medidas no forem suficientes, colocar no quadro a essncia das discordncias e iniciar o procedimento de obteno de consenso.
O REI DA VOZ
Fala muito e excessivamente alto; Domina a discusso; Aparentemente impossvel faz-lo calar;
56
Pode ser algum de nvel hierrquico acima dos demais membros, o que o torna ainda mais inabalvel. Procurar aproximar-se da pessoa, ou sugerir que faa anotaes individuais.
O INTRPRETE
Sempre fala por outra pessoa, normalmente sem ser solicitado; Recoloca as ideias alheias, frequentemente distorcendo-as durante a sua explanao. Confirme com o dono da ideia se ela foi recolocada pelo intrprete com fidelidade.
O FOFOQUEIRO
Traz boatos ou rumores para a reunio; Tenta ampliar seu poder, dando a impresso que tem informaes de cocheira; Leva o grupo a debater ou argumentar baseado na veracidade daquelas informaes. Sempre que as assertivas forem do tipo ouvi dizer, Acho que tem uma circular, o lder da sesso deve tentar esclarecer: quem disse isso?, Qual mesmo a circular?.
O "MVEIS E UTENSLIOS"
Usa credenciais, idade, tempo de casa, etc, no debate de uma questo; Focaliza a ateno do grupo em aspectos circunstanciais, ao invs de explorar o verdadeiro assunto. Acolher as observaes e relembrar que o objetivo do projeto ampliar a viso do problema e ter a aceitao do grupo. Essas so pessoas do tipo que muito resistente a mudanas.
O LDER FRUSTRADO
Vive dizendo ao lder da sesso o que fazer ou o que no fazer; Tenta controlar a reunio, diminuindo os esforos do lder. Acate as sugestes que no alterem a estrutura de sua agenda, e as que interferirem, agradea a colaborao e mostre seu ponto de vista.
O OCUPADO
Sempre entrando e saindo das reunies com papis e pastas debaixo dos braos; Permite que seja chamado com frequncia por outras pessoas; Tenta dar a impresso de muito ocupado para dar ateno integral reunio e ao grupo. Pedir ao prprio ocupado que sugira o que fazer para no haver interrupes (sugira outros horrios de reunio, anotar recados...)
57
O MAL-EDUCADO
Entra no meio das discusses, interrompendo os comentrios de algum; Demonstra impacincia; Fica insatisfeito quando suas prprias ideias no so bem recebidas. O grupo sempre espera, neste caso, a interveno do lder da sesso. Sugira que ele espere os colegas completar o raciocnio antes de contestlos.
O CARENTE
Gasta mais tempo e energia preocupado em obter aprovao do lder da sesso do que com o contedo da reunio. Quando este estiver iniciando alguma colocao olhando diretamente para voc, voc deve indicar que ele deve se dirigir ao grupo.
TAREFA 04 TECNICA JAD (1,0)
Em grupo de cinco pessoas, identifi que um componente, resolva o estudo de caso abaixo:
papel
para
cada
Controle de Estoque de uma Rede de Supermercados O sistema de controle de estoque de uma rede de supermercados mantm na base de dados a descrio de todas as informaes que permitem a manuteno de seu estoque de mercadorias. O controle efetuado para cada ponto de venda da rede, mas centralizado em uma nica base de dados, que efetua os pedidos de compra para todos os pontos de venda ao mesmo tempo. Quando um novo produto deve ser comprado, emitida uma ordem de compra com a quantidade total comprada, indicando tambm a quantidade do produto que deve ser entregue em cada ponto de venda. Um pedido de compra pode incluir tambm mais do que um produto comprado do mesmo fornecedor. Para que esse sistema possa funcionar, o sistema de controle de estoque mantm trs informaes fundamentais: o estoque de cada produto existente em cada ponto de venda da rede, as informaes sobre os fornecedores e as informaes sobre os pedidos em andamento. O estoque consiste na descrio de cada produto, incluindo a maneira como ele medido (por volume, unidade, peso, etc.), como embalado e nmero de embalagens disponveis em cada armazm. Mantm-se tambm os dados sobre os preos de compra e venda, e taxa esperada e medida de venda por ms. Como essas informaes so tratadas de maneira centralizada, elas so atualizadas em lotes por meio da comunicao de cada ponto de venda com a central, e no para cada produto vendido em caixa. Sobre os fornecedores so registrados dados gerais como identificadores, endereos, pontos de distribuio, etc., e tambm a relao de produtos disponveis e prazos de entrega. Todos os pedidos so mantidos num histrico, onde as vrias atividades correspondentes so registradas, alm de datas, valores e produtos envolvidos. As atividades de um pedido so: emisso do pedido de compra, entregas em cada ponto de venda e pagamentos efetuados. Estas atividades podem assumir status de parciais ou totais, alm de confirmao ou no do aceite o pedido e seu respectivo encerramento. Note que em pedido pode constar de mais de um produto e, nesse caso, cada produto dever ser tratado separadamente.
58
ESPECIFICAO DE REQUISITOS No documento da especificao de requisitos descrevemos os requisitos funcionais (obrigatrios) e requisitos no-funcionais (opcionais). Obs. H um outro exemplo de especificao de requisitos no Anexo A.
MODELO DE ESPECIFICAO DE REQUISITOS
Figura 23 Modelo de especificao de requisitos
Onde: Caso de Uso: nome do caso de uso; Objetivo: breve descrio do caso de uso; Atores: envolvidos naquele caso de uso; Condio de incio: o que dispara a funcionalidade no contexto do sistema; Fluxo Principal: interao entre sistema e ator para que o objetivo seja atingido; Fluxo alternativo: apoio do fluxo principal para que seja possvel atingir os objetivos secundrios. Regras de negcio: restries nas funcionalidades.
PASSOS PARA ESPECIFICAR OS REQUISITOS
1. Identifique quais os REQUISITOS e relacione com os CASOS DE USO; 2. Identifique tambm os ATORES e seus respectivos PAPIS; 3. D um nome para o CASO DE USO, lembre-se que este nome deve ser nico no modelo; 4. Escreva os CENRIOS para o CASO DE USO; 5. Compile os CENRIOS em nico FORMULRIO e 6. Faa o Diagrama de Caso de Uso.
59
Exemplo: Clientes so pessoas fsicas e possuem nome, endereo e telefone:

CASO DE USO: CADASTRAR CLIENTE OBJETIVO: PERMITIR QUE O FUNCIONARIO INSIRA, EXCLUA, ALTERE OU CONSULTE CLIENTES NO SISTEMA. ATOR: FUNCIONARIO CONDICAO DE INICIO: FUNCIONARIO SELECIONA A OPCAO CADASTRAR CLIENTE Obs. Dever ser definido como ser aps o cadastrar cliente. Como ser o dilogo? O sistema dever apresentar na tela um conjunto de clientes j cadastrados e no final apresentar as opes de inserir, excluir ou alterar um cliente selecionado, pois ao lado de cada nome haver a opo de seleo para trabalhar com as opes de excluir ou alterar. FLUXO PRINCIPAL: 1. O sistema apresenta tela de cadastro de cliente contendo: - Lista de Clientes cadastrados com as informaes para cada cliente: * Opo de Seleo * Nome * Endereo * Telefone - Apresenta ao final as opes: * Incluir novo * Excluir cliente * Editar cliente 2. O Funcionrio seleciona a opo Incluir novo [A16] [A27] 3. O sistema apresenta a tela de incluso de novo cliente contendo: - Nome - Endereo - Telefone - As Opes: * Salvar * Cancelar 4. O funcionrio informa os dados do cliente e seleciona a opo salvar [A3 8] 5. O sistema conclui a incluso do novo cliente Decidir: retorna a tela principal ou o caso de uso encerrado? 6. O sistema retorna para a tela inicial. 7. O caso de uso encerrado. No final de cada fluxo importante destacar para que parte ou tela do sistema ser desviado e informar que o caso de uso est encerrado. FLUXO ALTERNATIVO: PODERO OU NO SER EXECUTADOS [A1] O funcionrio seleciona a opo excluir Cliente. 1. O sistema exclui o cliente selecionado. 2. O sistema retorna ao passo 1 do fluxo principal. [A2] O funcionrio seleciona a opo editar Cliente. 1. O sistema apresenta a tela com as informaes do cliente selecionado para edio: - Nome - Endereo - Telefone - As opes: * Salvar * Cancelar 2. O funcionrio informa os dados do cliente e seleciona a opo salvar. [A4] 3. O sistema atualiza os dados do cliente.
6
Excluir Cliente Editar cliente CANCELAR fluxo alternativo
60
4. O sistema retorna ao passo 1 do fluxo principal. [A3] O funcionrio seleciona a opo Cancelar. 1. O sistema retorna ao passo 1 do fluxo principal.
VISO E ESCOPO
O documento que deve ser criado deve ter a viso e o escopo do programa a ser desenvolvido deve apresentar e deixar claro o que ser feito. Deve ser focado a no cliente, levantando os requisitos principais na viso macro, sem detalhamento para que o cliente perceba o que est sendo feito. Os objetivos so levantamentos com reunies semanais at fechar pois depois comea o levantamento de requisitos. Nesta viso temos os objetivos principais e as prioridades dele. Para seguir uma linha de raciocnio que definido pelo cliente ou representantes deste cliente (stakeholders envolvidos no projeto). Para que quando for levantar os requisitos no sair da viso sabendo que vai ser feito e o que no vai ser feito (documento do escopo), onde s poder ser feito o que est definido. Deve ter nvel alto de abstrao e dever ter se haver ou no: manuais, treinamentos e se for um sistema grande dever ser dividido em subsistemas e depois poder ser integrado. A equipe precisa lembrar o processo de usabilidade (caso parar um o outro permanece funcionando) e tambm poder ser reutilizado. O escopo deve conter tudo que o projeto deve fazer. importante verificar se todo o escopo est sendo mantido (PLANEJAMENTO, DEFINIO, VERIFICAO E CONTROLE DO ESCOPO). importante criar uma estrutura analtica do projeto (EAP) onde so definidos os blocos de trabalho para completar o projeto como um todo.
EXERCCIOS
1) Funcionrios so identificados pelo seu nmero de matrcula, e devem conter ainda nome, endereo, telefone e dependentes (nome e data de nascimento), alm de estar associado, obrigatoriamente a uma filial. a) Requisito Funcional: CADASTRAR FUNCIONRIO 2) O sistema deve permitir que o setor de atendimento ao cliente consulte os clientes cadastrados por nome, cpf, data de nascimento e status (se est em dia ou inadimplente) b) Requisito Funcional: CONSULTAR CLIENTES 3) Ponto de Venda: Um cliente chega no caixa com os itens que deseja comprar. O caixa usa o sistema para registrar cada item. A cada item comprado, o sistema apresenta o subtotal da compra e os detalhes do item. O cliente entra com informao do pagamento, o qual o sistema
61
valida e registra. O sistema atualiza o estoque. O cliente recebe um recibo do sistema e vai embora com os itens. c) Requisito Funcional: PROCESSAR VENDA 4) Jogo de Banco Imobilirio. Requisito Funcional: JOGAR
TAREFA 05 ESPECIFICAO DE REQUISITOS (0,5)
O Setor de Reserva do Hotel recebe um telefonema de cliente que solicita uma reserva de apartamentos para data. O cliente informa o perodo, ou seja, data de chegada e partida, e qual tipo de apartamento ele precisa. O funcionrio do Setor de Reserva verifica a disponibilidade do apartamento e informa que no tem disponibilidade de apartamento para o perodo informado pelo cliente e oferece um outro tipo de apartamento. O cliente no aceita a proposta do funcionrio e a reserva no confirmada.
62
VERIFICAO E VALIDAO DE REQUISITOS
Ser que realmente entendi o que o cliente deseja?
Um software considerado com qualidade se est em conformidade com as especificaes e padres de desenvolvimento documentados e que atenda as necessidades dos usurios. Para garantir a qualidade do software, um conjunto de atividades tcnicas devem ser aplicadas durante todo o processo de desenvolvimento. O objetivo garantir que tanto o processo de desenvolvimento quanto o produto de software atinjam nveis de qualidade especificados. A validao e a verificao (VV&T) tem o objetivo de garantir a qualidade do software, assegurando que este cumpra as suas especificaes e atenda s necessidades de seus usurios. Validao importante uma vez que o custo para remover um erro de requisitos grande. De acordo com o IEEE, define validao e verificao como: VALIDAO: avalia um sistema ou componente para determinar se ele satisfaz os requisitos para ele especificados; O software deve atender s necessidades dos usurios. VERIFICAO: avalia um sistema ou componente para determinar se os produtos de uma dada atividade de desenvolvimento satisfazem as condies impostas no incio desta atividade. Os artefatos construdos devem estar de acordo com a especificao do software.
VALIDAR : Estamos construindo o produto certo??? VERIFICAR : Estamos construindo certo o produto??
63
Usamos mtodos para validar e verificar para: Resultados de estudos experimentais evidenciam benefcios da utilizao destes mtodos no desenvolvimento de software; A utilizao destes mtodos na indstria tm mostrado resultados positivos considerando PRODUTIVIDADE e QUALIDADE. Ao inspecionar o software, h um aumento significativo na produtividade, qualidade e estabilidade dos projetos. Corrigir um defeito aps a entrega do produto 100 vezes mais caro do que corrigi-lo durante as atividades de requisitos e projeto do sistema (Boehm, Basili, 2001).
TIPOS DE DEFEITO
A maior parte de origem humana; So gerados na comunicao e na transformao de informaes; Permanecem presentes nos diversos produtos de software produzidos e liberados; A maioria encontra-se em partes do produto de software raramente utilizadas e/ou executadas. A principal causa a traduo incorreta das informaes e quanto antes ser identificada, menor o custo de correo do defeito e maior a probabilidade de corrigi-lo corretamente, por isto sempre importante introduzir atividades de verificao e validao ao longo de todo o desenvolvimento.
Figura 24 Tipos de Defeitos
64
OMISSO
Algum requisito importante relacionado funcionalidade, ao desempenho, s restries de projeto, ao atributo, ou interface externa no foi includo; No est definida a resposta do software para todas as possveis situaes de entradas de dados; Faltam sees na especificao de requisitos; Faltam referncias de figuras, tabelas e diagramas; Falta definio de termos e unidades de medidas.
AMBIGUIDADE
Um requisito tem vrias intepretaes devido a diferentes termos utilizados para uma mesma caracterstica ou vrios significados de um termo para um contexto em particular.
INCONSISTNCIA
Dois ou mais requisitos conflitantes.
FATO INCORRETO
Um requisito descreve um fato que no verdadeiro, considerando as condies solicitadas para o sistema.
INFORMAO ESTRANHA
As informaes fornecidas no requisito no so necessrias ou mesmo usadas.
DOCUMENTO DE REQUISITOS
Por ser o primeiro artefato tangvel a ser produzido pois descreve todas as caractersticas e as funes que o software a ser desenvolvido deve possuir. Atua como um contrato entre o cliente e o desenvolvedor e a base para todas as etapas subsequentes do desenvolvimento e normalmente escrito em linguagem natural.
65
DEFEITOS NO DOCUMENTO DE REQUISITOS
Figura 25 Defeitos no Documento de Requisitos
CONSEQUENCIAS
Estimativas de esforo e prazo deixam de fazer sentido; Desperdcio de recursos; Produto final no atende as necessidades do usurio; Corrigir defeitos aps a entrega do produto pode ser at cem vezes mais caro que corrigi-los nas primeiras fases do desenvolvimento; Em projetos recentes de software, teramos um esforo de retrabalho entre 40% a 50% do esforo total.
PEQUENO CHECKLIST DE REQUISITOS

VALIDADE. O sistema fornece as funes que melhor atende as necessidades do usurio? CONSISTNCIA. Existem conflitos de requisitos? COMPLETEZA. Todas as funes necessrias para o cliente esto includas? REALISMO. Os requisitos podem ser implementados com a tecnologia e oramento disponveis? FACILIDADE DE VERIFICAO. Os requisitos podem ser checados?
TCNICAS DE VALIDAO DE REQUISITOS

REVISO DE REQUISITOS
Anlise manual sistemtica dos requisitos.
66
Revises regulares devem ocorrer durante a formulao da definio dos requisitos; Tanto o cliente quanto a equipe contratada devem estar envolvidos nas revises; As revises podem ser formais (com documentos completos) ou informais. Uma boa comunicao entre os desenvolvedores, clientes e usurios pode resolver problemas em estgios iniciais. VERIFICAO DE REVISES VERIFICABILIDADE. O requisito realisticamente testvel? COMPREENSIBILIDADE. O requisito propriamente entendido? RASTREABILIDADE. estabelecida? A origem do requisito claramente
ADAPTABILIDADE. O requisito pode ser modificado sem grande impacto sobre outros requisitos?
REVISES DE SOFTWARE
o processo ou atividade para leitura de um artefato de seu software visando assegurar que ele cumpre sua especificao e atende s necessidades de seus usurios e ocorre em diferentes momentos do software. Tem como objetivo validar e verificar os artefatos de software. Pode ser aplicada a qualquer artefato produzido ao longo do processo de desenvolvimento de software. As revises podem ser: PARES (PEER-REVIEWS): aumenta a probabilidade de defeitos a serem encontrados. Utilizam: o ANNIMIDADE: relacionamentos pessoais no afetam a reviso. o INDEPENDNCIA DOS REVISORES EM RELAO AO ARTEFATO A SER REVISADO: permite uma avaliao objetiva sem conflitos de interesse.
TIPOS DE REVISO DE SOFTWARE
INSPEO DE SOFTWARE
Os benefcios e custos so: Inspees vm sendo utilizadas h mais de duas dcadas; Existe evidncia experimental de sua usabilidade e adequabilidade; Provem um bom meio para o gerente do projeto monitorar a qualidade e progresso do projeto;
67
Podem amenizar atividades de manuteno, evitando que erros se propaguem pelo ciclo de vida; Apresentam baixo custo devido ao fato do revisor no precisar investir muito tempo ou mesmo no demandar ferramentas sofisticadas para realiz-las. Entretanto uma alta taxa de atividades de inspeo ao longo do pr0ocesso pode acrescer de 5% a 10% o custo final.
Figura 26 Comparativo de Com e Sem Inspeo
PROCESSO DE INSPEO DE SOFTWARE
Figura 27 Processo de Inspeo
Composta por PAPEIS E ATIVIDADES
68
PAPEIS: atuam ao longo das atividades da inspeo para que no final do processo tenha um documento com os requisitos de software bem elaborados. - moderador: - inspetor; - autor do documento. ATIVIDADES: - planejamento: efetuado pelo moderador que identificada baseada nas caractersticas do artefato, quem seriam os mais interessados em participar da inspeo e distribua para as pessoas selecionadas nesta atividade; - preparao individual: recebiam o material e se preparavam para a reunio para identificar defeitos. - reunio de inspeo: depois marcava a reunio e durante ela era feito a leitura critica do documento de requisitos para encontrar os defeitos. No final tinha-se a lista de defeitos que era entregue ao autor - retrabalho: fazer os reajustes de acordo com o que foi elaborado. - continuao: verifica se precisa ou no passar por outra inspeo.
PROCESSO TRADICIONAL DE INSPEO
PLANEJAMENTO Responsvel: moderador Tarefas: - Definir contexto da inspeo: descrio da inspeo, como a preparao individual dever ocorrer, documento a ser inspecionado, autor do documento, entre outros. - Selecionar inspetores: recomenda-se utilizar entre 3 e 5 inspetores em uma inspeo. - Distribuir material. PREPARAO INDIVIDUAL - Responsvel: Inspetor - Tarefas: estudar os artefatos e fazer anotaes sobre os artefatos. REUNIO DE INSPEO - Envolvidos: moderador, inspetores e autor - Tarefas: - Leitura do documento com a equipe discutindo possveis defeitos (durao recomendada 2 horas); - Produzir uma lista de defeitos; - Em casos de discordncia a deciso sobre registrar um defeito ou no (falso positivo) do moderador. RETRABALHO - Responsvel: Autor - Tarefa: corrigir os defeitos encontrados. CONTINUAO - Responsvel: Moderador - Tarefa:
69
- Analisar correes do autor e inspeo como um todo; - Re-avaliar qualidade do artefato inspecionado; - Decidir sobre a necessidade de uma nova inspeo.
WALKTHROUGHS
Alternativa com um processo menos rigoroso do que o de inspees de software. Papis sugeridos: lder, autor, escrivo e revisores. Procedimento: os participantes so guiados atravs dos artefatos pelo lder (que eventualmente o prprio autor) em uma reunio. Durante est reunio deve interromper a apresentao caso encontrem defeitos. Muitas vezes condies de entrada e sada e decises so pressupostos pelo lder que segue sua linha de raciocnio durante a apresentao. Possuem custo aproximadamente igual ao de inspees mas seus resultados so inferiores: No providenciar resultados mensurveis; No fornecer base para a aplicao de controle estatstico de processos, necessrios para evoluir na maturidade de processos de software. Pode ser usado para atividades de brainstorming para explorar alternativas de projeto e resoluo de problemas (focadas em encontrar defeitos). GERENCIAMENTO DE MUDANA DE REQUISITOS
Figura 28 Esquema do Gerenciamento de Requisitos (Fonte: extrado da Web)
Gerenciamento de Mudana de Requisitos o processo de controlar as mudanas nos requisitos durante o processo de engenharia de requisitos e desenvolvimento. Requisitos so inevitavelmente incompletos e inconsistentes:
70
Novos requisitos surgem durante o processo de desenvolvimento. Diferentes pontos de vista possuem diferentes requisitos e esses so frequentemente contraditrios.
Mudanas nos requisitos A prioridade dos requisitos pode mudar para atender novas demandas de negcio; Requisitos podem sofrer alterao quando muda a regra de negcio; As pessoas que pagam pelo software/sistema podem especificar os requisitos de maneira conflitantes com os requisitos das pessoas que iro utilizar o software/sistema; A empresa e o ambiente tcnico do software/sistema se modificam durante o processo de desenvolvimento. Os principais objetivos desse processo so (KOTONYA; SOMMERVILLE, 1998): Gerenciar alteraes nos requisitos acordados; Gerenciar relacionamentos entre requisitos; Gerenciar dependncias entre requisitos e outros documentos produzidos durante o processo de software. Para tal, o processo de gerncia de requisitos deve incluir as seguintes atividades:
Figura 29 Atividades de Gerncia de Requisitos (Fonte:
WIEGERS, 2003)
O controle de mudana define os procedimentos, processos e padres que devem ser utilizados para gerenciar as alteraes de requisitos, assegurando que qualquer proposta de mudana seja analisada conforme os critrios estabelecidos pela organizao (KOTONYA; SOMMERVILLE, 1998). Mudanas podem ser necessrias em diferentes momentos e por
71
diferentes razes. De maneira geral, o controle de mudanas envolve atividades como (KOTONYA; SOMMERVILLE, 1998; WIEGERS, 2003): Verificar se uma mudana vlida; Descobrir quais os requisitos e artefatos afetados pela mudana, o que envolve rastrear informaes; Estimar o impacto e o custo das mudanas; Negociar as mudanas com os clientes; Alterar requisitos e documentos associados.
EVOLUO DOS REQUISITOS
Figura 30 Evoluo dos Requisitos (Fonte: extrado da Web)
REQUISITOS PERMANENTES E VOLTEIS

REQUISITOS PERMANENTES: Requisitos estveis, derivados da atividade principal da organizao. Exemplo: Em um hospital sempre haver requisitos relativos aos pacientes, aos mdicos, s enfermeiras e aos tratamentos. REQUISITOS VOLTEIS: Requisitos que se modificam durante o desenvolvimento ou quando o software/sistema est em uso. Requisitos resultantes de polticas governamentais ou resultantes de regra de negcio da empresa. Exemplo: Plano de sade; Mudana na poltica de venda.
CLASSIFICAO DOS REQUISITOS
Requisitos Mutveis: Requisitos que se modificam por causa do ambiente do sistema; Requisitos Emergentes: Requisitos que surgem medida que a compreenso do cliente do sistema se desenvolve;
72
Requisitos Consequentes: Requisitos que resultam da introduo do sistema de computador. Requisitos de compatibilidade: Requisitos que dependem de outros sistemas ou processos de negcio especficos dentro da organizao.
PLANEJAMENTO DO GERENCIAMENTO DE REQUISITOS
Durante o processo de engenharia de requisitos, ser necessrio planejar: IDENTIFICAO DOS REQUISITOS: Como os requisitos so individualmente identificados; PROCESSO DE MUDANA DE GERENCIAMENTO: O processo seguinte anlise de uma mudana de requisito; POLTICAS DE RASTREABILIDADE: quantidade de informaes (histrico) sobre o relacionamento entre requisitos que mantida. Como rastrear as mudanas de requisitos e seus possveis impactos. SUPORTE FERRAMENTA: suporte ferramenta necessrio para auxiliar no Gerenciamento de Mudanas de Requisitos.
RASTREABILIDADE
Rastreabilidade preocupa-se com as relaes entre requisitos, suas fontes e o projeto do software/sistema. RASTREABILIDADE DE FONTE: links de requisitos para stakeholders que propuseram os requisitos; RASTREABILIDADE dependentes; DE REQUISITOS: links entre requisitos
RASTREABILIDADE DO PROJETO: links dos requisitos para o projeto.
SUPORTE FERRAMENTA:
Armazenamento dos requisitos: Os requisitos devem gerenciados em uma memria de dados segura e gerenciada;
ser
Mudana de gerenciamento: O processo de mudana de gerenciamento um processo de fluxo de trabalho cujos estgios podem ser definidos e o fluxo de informao entre esses estgios parcialmente automatizado. Gerenciamento de rastreabilidade: Recuperao automtica dos links entre requisitos.
73
Gerenciamento de Mudanas de Requisitos: Deve ser feita em qualquer proposta de mudana de requisito. PRINCIPAIS ESTGIOS: Anlise do problema e especificao da mudana. Discute-se os problemas com os requisitos e prope-se mudanas; Anlise e custo da mudana. Avalia-se os efeitos da mudana em outros requisitos do sistema; Implementao das mudanas. O documento de requisitos e outros documentos so alterados de forma a refletir as mudanas.
Figura 31 Principais Estgios do Gerenciamento de Mudanas de Requisitos (Fonte: extrado da Web)
ETAPAS PARA O RASTREAMENTO
1.Rastrear requisitos do usurio nos do sistema; 2.Rastrear requisitos no projeto; 3.Rastrear requisitos nos procedimentos de teste; 4.Rastrear requisitos do usurio no plano.
Figura 32 Etapas para o Rastreamento (Fonte: extrado da Web)
74
EXERCCIOS
1) Assinale a opo correta quanto a requisitos de software.( CESPE - 2010 TRE-MT - Tcnico Judicirio - Programao de Sistemas) a)Requisitos funcionais descrevem as propriedades emergentes do sistema, como segurana e tempo de resposta. b)Requisitos no funcionais so descritos de forma qualitativa e no quantitativa c) Requisitos so provenientes de pessoas relevantes para o sistema, e no de outros sistemas que interagem com o sistema que est sendo especificado. d)A matriz de rastreabilidade no oferece suporte para requisitos funcionais. e)Reviso de requisitos, prototipao e gerao de casos de teste so exemplos de tcnicas de validao de requisitos. 2) Segundo Ian Sommerville, existe uma srie de tcnicas de validao de requisitos que podemser utilizadas em conjunto ou individualmente. So elas (FUNCAB - 2010 - SEJUS-RO - Analista de Sistemas): a) gerao de casos de teste, revises de requisitos, gerenciamento de mudanas e prototipao. b) revises de requisitos, prototipao, gerao de casos de teste e anlise automatizada da consistncia. c) prototipao, anlise automatizada da consistncia, revises de requisitos e gerenciamento de mudanas. d) gerenciamento de mudanas, anlise automatizada da consistncia, revises de requisitos e gerao de casos de teste. e) anlise automatizada da consistncia, prototipao, gerenciamento de mudanas e gerao de casos de teste. 3) No que diz respeito aos sistemas de software, teste um conjunto de atividades que podem ser planejadas antecipadamente e conduzidas sistematicamente. Um tipo I de teste se refere ao conjunto de atividades que garante que o software implementa corretamente uma funo especfica, associado construo do produto de forma correta ou no, enquanto um tipo II se refere a um conjunto de atividades diferente que garante que o software construdo corresponde aos requisitos do cliente, associado construo do produto certo. Esses testes do tipo I e II so denominados, respectivamente (FGV - 2010 - FIOCRUZ - Tecnologista em Sade - TI - Sistemas de Informao): a) Depurao e homologao. b) Homologao e aceitao. c) Aceitao e verificao. d) Verificao e validao. e) Validao e depurao. 4) Verificao e validao so atividades da anlise de software, necessrias para se identificar o que o software precisa executar, seguida
75
de uma avaliao do usurio quanto s atividades definidas. (CESPE - 2011 TJ-ES - Tcnico de Informtica - Especficos) ___ CERTO ___ ERRADO 5) Os produtos de trabalho resultantes da engenharia de requisitos so avaliados quanto qualidade durante a etapa de validao de requisitos. Analise os itens a seguir referentes a essa etapa: I. Um dos principais mecanismos de validao de requisitos a avaliao tcnica formal. II. O modelo de anlise pode garantir que os requisitos foram consistentemente declarados. III. frequentemente til examinar cada requisito em face de um conjunto de questes do tipo checklist. IV. A equipe de reviso que avalia os requisitos inclui apenas pessoas com conhecimento tcnico na rea de TI, como engenheiros de softwares, desenvolvedores etc. Est correto o que consta em: a) I, II, III e IV b) II e IV c) I, II e IV d) II, III e IV e) I, II e III 6) Assim como o software, os requisitos tambm devem ser avaliados quanto qualidade. A validao, atividade da engenharia de requisitos, responsvel por garantir que os requisitos tenham sido declarados de forma clara e precisa. Alm disso, a validao busca detectar inconsistncias, erros e omisses, objetivando alinhar os requisitos s normas estabelecidas para o projeto, produto e processo. (CESPE - 2011 TJ-ES - Analista Judicirio - Anlise de Sistemas - Especficos) ___ CERTO ___ ERRADO
76
MATRIZ DE RASTREABILIDADE Matrizes de rastreabilidade so os principais artefatos produzidos na fase de gerncia de requisitos. Elas relacionam os requisitos identificados a um ou mais aspectos do sistema ou do seu ambiente, de modo que elas possam ser procuradas rapidamente para entender como uma modificao em um requisito vai afetar diferentes aspectos do sistema.
RASTREABILIDADE
Tcnica usada para prover relacionamento entre requisitos, projeto e implementao final do sistema. uma caracterstica de sistemas nos quais os requisitos so claramente ligados s suas fontes e aos artefatos criados durante o ciclo de vida de desenvolvimento de sistema. a habilidade de descobrir a histria de toda caracterstica do sistema, dado que os impactos de mudanas nos requisitos podem ser identificados. (Hamilton, 1991)
Figura 33 Esquema Rastreabilidade
OBJETIVOS
GERENCIAR O PROJETO: o Acompanhar a evoluo desenvolvimento;
dos
requisitos
ao
longo
do
77
o Registrar status de cada requisito em relao ao desenvolvimento, em relao a modificaes aceitas e justificativas associadas; o Estabelecer uma viso comum entre o cliente e a equipe de projeto em relao aos requisitos que sero atendidos pelo projeto de software; ACOMPANHAR AS MUDANAS: o Atualmente tem-se a convico que mudanas em requisitos ao longo do processo de desenvolvimento de software fazem parte do processo; o Motivos: necessidades no identificadas inicialmente, alteraes no contexto, correo de erros ou mesmo novas perspectivas por parte dos stakeholders; o Alteraes em requisitos podem implicar em mudanas em artefatos de projeto, cdigo, casos de testes, etc. GARANTIA DE QUALIDADE: o Aspectos relacionados a qualidade: modelo CMM, CMMI, ISO 9001. A rastreabilidade auxilia: ANLISE DE COMPLETUDE NA ALOCAO DE REQUISITOS A COMPONENTES DO SOFTWARE: A avaliao dos links de rastreabilidade de requisitos a artefatos de design e implementao identifica requisitos ainda no alocados ou implementados; RESOLUO DE REQUISITOS EM CONFLITO: diferentes representantes do cliente ou usurio trazem suas necessidades em relao ao sistema. Essas necessidades iro gerar requisitos que podem ser conflitantes. A rastreabilidade possibilita identificar rapidamente as origens dos requisitos em conflito, para soluo do problema detectado; VERIFICAO: na anlise de cobertura de requisitos nos testes, a rastreabilidade entre requisitos e casos de testes permite identificar requisitos ou funcionalidades para os quais foram previstos casos de testes; CORREO DE DEFEITOS (BUGS): aps a identificao do componente que originou o erro, a anlise do problema pode indicar que a origem do defeito no est no cdigo propriamente dito, mas nos requisitos ou em artefatos de design. Os links indicaro quais artefatos devero ser revistos e corrigidos, incluindo testes; VALIDAO: a etapa final de validao do sistema criado junto ao conjunto de clientes e usurios se beneficia da rastreabilidade, permitindo mostrar a completude da implementao em relao aos requisitos acordados entre clientes e desenvolvedores;
78
ANLISE DE IMPACTO NA EVOLUO DO SISTEMA: a existncia de links de rastreabilidade entre requisitos e componentes possibilita identificar rapidamente quais componentes sero afetados por mudanas em um requisito ou mesmo por incluso de novos requisitos; PREVISO DE CUSTOS E PRAZOS: quando uma nova funcionalidade deve ser includa no sistema em implementao ou quando uma mudana num requisito j implementado solicitada, o gerente de projeto necessita de estimativas confiveis para poder negociar custos e prazos junto ao cliente;
GERENCIAMENTO DE RISCOS: a rastreabilidade apoia a identificao de artefatos atingidos por cada fator de risco, possibilitando a elaborao de estratgias para tratamento ou mitigao dos riscos (por exemplo, riscos associados a custos e cronograma); UPGRADE DE HARDWARE E/OU AMBIENTE OPERACIONAL: em sistemas embarcados ou em software utilitrio existem relacionamentos fortes entre componentes do hardware e do software. Na mudana de verso do ambiente operacional ou na troca de hardware, links de rastreabilidade possibilitam identificar rapidamente componentes atingidos; REUSO DE COMPONENTES: obter ativos reusveis a partir de sistemas existentes tem incrementado o reuso na indstria; uma abordagem que propicia este incremento utiliza a recuperao de links de rastreabilidade entre cdigo e documentos escritos em linguagem natural.
MATRIZ DE RASTREABILIDADE DEFINIDAS

Com a matriz abaixo possvel visualizar as ligaes entre os requisitos de software.
79
Figura 34 Matriz de Rastreabilidade
A matriz de rastreabilidade de requisitos destinada a apoiar o trabalho do engenheiro de software nas atividades do processo de desenvolvimento, criando automaticamente elos de rastreabilidade entre os requisitos e cenrios de aplicao.
<nome da empresa> APROVAES Nome Assinatura Nome Assinatura <nome do projeto> Matriz de Rastreabilidade de Requisitos Data: dia/ms/ano Elaborado por: <nome(s) do(s) elaborador(es)> ID Requisito Descrio Prioridade Responsvel / Verso Caso de Teste Data Data Proprietrio Alterao Concluso Id do Descrio Prioridade requisito (Feature) do elencada identificado no requisito. para o Documento requisito. (Anlise) de Requisitos. Figura 35 Modelo de Matriz Nome do Nmero Identificao Data de Data de responsvel da verso do caso de alterao concluso pela do teste elaborado do do execuo e requisito. para o requisito. requisito. controle do requisito. requisito. de Rastreabilidade (Fonte: extrado da Web) Data
Data
EXERCCIOS
1) As polticas de rastreabilidade de requisitos so decididas durante o estgio de (FCC - 2010 - MPE-RN - Analista de Tecnologia da Informao - Engenharia de Software)
80
a) Agregao dos requisitos funcionais, apenas. b) implementao do sistema, apenas. c) implementao do sistema. d) eliminao dos requisitos no funcionais. e) gerenciamento de requisitos. 2) O gerenciamento de requisitos deve compreender e controlar mudanas nos requisitos de sistema, alm de avaliar os seus impactos. Para atingir esse propsito, podem ser mantidas informaes de rastreabilidade a serem usadas para avaliar quais outros requisitos seriam afetados por uma mudana, bem como o impacto da mudana de requisitos no projeto e na implementao do sistema. (CESPE - 2009 - SECONT-ES - Auditor do Estado Tecnologia da Informao) ___ CERTO ____ ERRADO
ORIENTAO A OBJETOS
Adaptado da Revista: ENGENHARIA DE SOFTWARE MAGAZINE
HISTRIA
Em 1962, Ole-Johan Dahl e Kristen Nygaard criaram uma linguagem chamada Simula, baseada na linguagem Algol 60 que tinha o objetivo permitir o projeto de simulaes. Surgia a primeira linguagem orientada a objetos, apresentando os conceitos de classe e herana. Essa foi a semente que inspirou o desenvolvimento de uma nova linguagem, a primeira totalmente orientada a objetos o SmallTalk. Nela, no existem tipos primitivos, tudo representado em forma de objeto: nmeros, caracteres etc. Disponibilizada ao pblico no incio dos anos 80, SmallTalk solidificou para a comunidade os conceitos de classe, objeto, atributo, mtodo, encapsulamento, herana e mensagem. A partir da, novas linguagens surgiram, como o C++ (verso OO da linguagem C), Object Pascal (verso OO do Pascal), Eiffel e Java (criado a partir do C++).
81
http://zeromeia.net84.net/smalltalk/programando.html
Figura 36 Tela do programa Smalltalk
CONCEITOS FUNDAMENTAIS
Figura 37 Conceitos fundamentais da UML
Surgiu devido a necessidade em se enfatizar unidades discretas, e obter a reutilizao de cdigo, mantendo-se a qualidade do software.
82
O foco da Orientao a Objetos sobre os dados, em vez dos processos, compondo mdulos auto-suficientes os objetos , encerrando em sua estrutura todo o conhecimento dos dados e dos processos para manipulao desses dados. Objetivo Principal: possibilidade de se abstrair diretamente os conceitos do mundo real, sem subterfgios para se chegar soluo computacional. Se um dos conceitos fundamentais de orientao a objetos no for atendido, no podemos afirmar que determinada tecnologia possa ser nomeada como orientada a objetos. Exemplo: Visual Basic, que antes da sua verso .NET no implementava todos os conceitos.
OBJETO
Figura 38 Exemplo de Objeto
Objeto qualquer coisa existente no mundo real, em formato concreto ou abstrato, ou seja, que exista fisicamente ou apenas conceitualmente, o qual se pode caracterizar e identificar comportamentos. Podemos afirmar que um objeto uma caixa-preta que recebe e envia mensagens, ou seja, num sistema orientado a objetos, os objetos trocam informaes por meio de mensagens. Num sistema orientado a objetos no modelamos apenas objetos de negcio. Muitas vezes, de acordo com a arquitetura utilizada, modelamos objetos computacionais, visuais ou no. Exemplo: ao levantarmos os requisitos para informatizar uma concessionria, encontraremos o objeto automvel (fsico), da mesma forma que podemos modelar o objeto venda (conceitual).
83
ATRIBUTO
Figura 39 Exemplo de Atributo
So as caractersticas ou propriedades associadas aos objetos. Para os objetos de negcio, comum usarmos o conceito de atributo. Para os objetos visuais, utilizamos o conceito de propriedade. Exemplos: atributos da classe Cargo: descricao e salario; atributos da classe Automvel: modelo, cor, numeroPortas, ano, placa, etc.
OPERAO X MTODO
Figura 40 - Exemplo de Operao x Mtodo
O comportamento dos objetos representado pelas operaes. Contudo, a operao para um objeto representa apenas a definio do servio que ele oferece a outras estruturas. Quando tratamos da implementao dessa operao, ou seja, da sua representao em cdigo, estamos nos referindo ao seu mtodo. Os mtodos de uma classe manipulam somente as estruturas de dados daquela classe, ou seja, para se ter acesso aos dados de outra classe, isso deve ser feito por meio de mensagens.
84
Exemplo: operaes da classe Cargo: cadastrar() e reajustarSalario(percentual: float). RESUMINDO: as operaes so mtodos ou funes que atuam sobre os objetos e afetam o comportamento dos mesmos.
CLASSE
Ao modelarmos uma classe precisamos sempre considerar o contexto. Se no fosse isso, bastaria um famoso metodologista publicar as solues para todas as classes de negcio. EXEMPLOS: EXEMPLO 1: Desta forma, no teremos necessariamente os mesmos atributos e operaes para a classe aluno, por exemplo, modelada num sistema acadmico de uma escola de nvel mdio, e a mesma classe aluno, modelada num sistema acadmico de uma Universidade. No garantia termos os mesmos atributos e operaes nem se considerarmos dois sistemas acadmicos modelados para distintas Universidades. EXEMPLO 2: classe Automvel. Se estivermos no contexto de uma concessionria, teremos operaes como: cadastrar, alterarProprietario, etc. Em contrapartida, se estivermos no contexto de um simulador para auto-escola, seu comportamento deve reproduzir o objeto real, com operaes como: ligar, aumentar marcha, reduzir marcha, acelerar etc.
ESTADO
So os valores assumidos pelos atributos de um objeto. Exemplo: em um determinado objeto cargo, o estado do seu atributo salario o valor R$ 5000,00.
MENSAGEM
a solicitao que um objeto faz a outro, invocando a execuo de um determinado servio. Por exemplo, para que um objeto possa calcular a folha de pagamento, ele precisa saber o salrio de cada funcionrio. Assim, ele passa uma mensagem ao objeto cargo, solicitando a execuo do servio obterSalario, que nada mais do que uma operao do objeto cargo.
ENCAPSULAMENTO
a utilizao de um sistema orientado a objetos que no deve depender de sua implementao interna, e sim de sua interface. Isso garante que os atributos e os mtodos estaro protegidos, s podendo ser acessados pela interface disponibilizada pelo objeto, ou seja, sua lista de servios. Essa proteo garante que os usurios de uma classe no sejam influenciados por quaisquer alteraes feitas em seu contedo. Exemplo:
85
Na prtica, imagine uma classe Produto que possua a operao obterPrecoVenda: float. Essa operao pblica, tornando-se um servio disponibilizado a outras classes. Em qualquer rotina que se queira mostrar o preo de venda de um produto, basta instanciar um objeto Produto, e passar uma mensagem para executar o servio, ou seja, chamar a execuo da operao obterPrecoVenda. Suponha que as rotinas A, B, C e D usem esse servio e que at ontem esse valor de venda fosse obtido apenas com um clculo simples: precoVenda = precoCusto * (1 + lucro/100) Esse clculo est na implementao de uma operao, ou seja, o seu mtodo, e fica encapsulado (escondido). Suponha agora que hoje foi colocada uma nova verso da classe Produto, na qual esse clculo passa a ser: precoVenda = precoCusto * (1 + lucro/100) precoVenda = precoVenda * (1 - descontoMes/100) As rotinas A, B, C e D recebero uma exceo em virtude da regra de clculo ter sido alterada? No, eu respondo. transparente para essas rotinas (e precisa ser assim) que houve alterao na forma de clculo do preo de venda. Se estivermos diante de um componente (por exemplo, uma dll), absolutamente nada ser preciso fazer com essas rotinas. Se estivermos com as rotinas dentro do mesmo pacote que a classe, basta recompilar tudo.
HERANA
Ao refinarmos a modelagem de um sistema comum encontrarmos caractersticas redundantes entre objetos. Essa redundncia pode ser evitada pela separao dos atributos e operaes numa classe comum, identificada como superclasse. Essa classe comum (superclasse) passa a ser a generalizao de outras classes que encerram em si apenas os atributos e operaes especficos a cada uma. Exemplo: Suponha que temos duas classes: Cliente e Funcionario. So atributos dessas classes: Cliente (cpf, nome, dataNascimento, endereco, dataPrimeiraCompra); Funcionario (cpf, nome, dataNascimento, endereco, dataAdmissao, funcao). Imagine que existem operaes que validam o CPF, retornam a idade de um cliente ou funcionrio, ou formatam o endereo. E que todas essas funes apaream em duplicidade nas classes Cliente e Funcionrio. Numa situao dessas, o que se espera na orientao a objetos que essa redundncia seja eliminada com a herana. Assim, cria-se uma superclasse Pessoa, e a ela so atribudos todos os atributos e operaes comuns Cliente e Funcionario. Sobram nas subclasses (Cliente e Funcionario) somente os atributos e operaes especficos a cada um. Na prtica, ao se usar uma subclasse, tem-se acesso a todos os elementos das classes ascendentes, como se tivessem sido criadas na prpria classe filha. Abaixo o resultado:
86
CLASSES Antes da herana Cliente
ATRIBUTOS cpf nome dataNascimento endereco dataPrimeiraCompra cpf nome dataNascimento endereco dataAdmissao funo
Funcionario
cpf nome dataNascimento endereco Cliente dataPrimeiraCompra Funcionrio dataAdmissao funcao Quando uma subclasse possui mais do que uma superclasse dito que temos uma herana mltipla. A herana no precisa se limitar aos objetos de negcio. Pelo contrrio, um dos maiores ganhos que ns temos com a orientao a objetos a possibilidade de se estender todo esse conceito de utilizao para todos os componentes do nosso sistema. Exemplo: podemos criar uma classe para um relatrio, com o logotipo da empresa, dados de identificao do cabealho e do rodap, e a partir dessa classe, herdar todos os outros relatrios do sistema, particularizando em cada um, as caractersticas especficas. Imagine o esforo necessrio para se trocar o logo e incluir o nome do usurio logado em todos os 1000 relatrios de um sistema: calculo uns dois minutos.
POLIMORFISMO
Aps a herana Pesoa
Uma operao pode ter implementaes diferentes em diversos pontos da hierarquia de classes. Isso significa que ela ter a mesma assinatura (mesmo nome, lista de argumentos e retorno), porm implementaes diferentes (mtodos). Isso o polimorfismo (poli = muitas; morphos = forma). Exemplo: H uma operao calcularSalario() que pertence classe Funcionario. Herdamos de Funcionario a classe Professor, o que resulta automaticamente na herana de calcularSalario(). Contudo o clculo do salrio de um professor no o mesmo que o clculo do salrio de um
87
funcionrio, o que nos leva a ter a mesma operao, porm com mtodos diferentes.
ANLISE ORIENTADA A OBJETOS O que anlise????
A anlise visa investigar e resolver um problema. O objetivo da anlise levar o analista ou projetista a investigar e a descobrir como tratar o problema que ele tem em mos. Ao finalizar a anlise, dever ocorrer uma compreenso completa do problema e, portanto, o projeto ser a sua soluo. A anlise orientada a objetos uma atividade essencial num processo de desenvolvimento de software. Seu objetivo principal identificar objetos, atributos desses objetos e as operaes que atuam sobre eles. Note que a anlise essencial para criao de um modelo de classes do sistema a partir dos casos de uso (da etapa de levantamento de requisitos). O objetivo da anlise identificar as classes necessrias para implementar os casos de uso do sistema, como discutido adiante. Um processo de desenvolvimento de software compreende um conjunto de atividades, dentre elas, levantamento de requisitos, anlise e projeto como etapas iniciais do processo de desenvolvimento de software. Antes de iniciar a modelagem com uma linguagem como a UML, devemos proceder a anlise orientada a objetos, que compreende os seguintes passos: 1) Entender o problema do cliente e identificar e documentar os requisitos; 2) Descrever os requisitos funcionais usando diagramas de casos de uso da UML; 3) Identificar objetos e classes a partir das informaes no documento de requisitos, descrio do sistema e especificao de casos de uso; 4) Identificar relacionamentos entre as classes do item 3; 5) Identificar atributos e operaes (para as classes identificadas no item 3); 6) Elaborar e analisar os diagramas de classes de sistema, adicionando e/ou corrigindo atributos e operaes, bem como revisando os relacionamentos identificados.
88
EXERCCIOS
1)
O paradigma de orientao a objetos centrado em conceitos que envolve os seguintes princpios fundamentais: abstrao, encapsulamento, herana e polimorfismo. Esse paradigma evoluiu desde a sua concepo original e tornou-se uma fora pivotal no desenvolvimento da cincia, da tecnologia e de quaisquer outros domnios em que aplicada, inclusive na rea de desenvolvimento de software. A esse respeito, assinale a opo correta. (CESPE 2010 - SAD-PE - Analista de Controle Interno Tecnologia da Informao)
Na implementao de linguagens de programao orientada a objetos (POO), o polimorfismo , usualmente, possvel por meio do emprego da tcnica de ligao esttica, de modo que a escolha da implementao especfica que tratar determinado envio de mensagem ser efetuada em tempo de compilao. O conceito de abstrao, presente na POO, oferece maior suporte aos mtodos de desenvolvimento embasados em refinamentos top-down que aos embasados em refinamentos bottom-up. Na POO, o encapsulamento aplica-se, fundamentalmente, aos campos ou variveis de estado de determinado objeto, sendo de pouca utilidade a sua aplicao a mtodos. Uma das formas comuns de se evitar o uso excessivo de herana como mecanismo de refinamento de POO o emprego de delegao, que evita a criao de nmero excessivo de subclasses em modelos orientados a objetos. Nas linguagens orientadas a objeto da atualidade, comum o uso de herana mltipla, que permite a determinada classe herdar diretamente das implementaes de uma ou mais classes, possibilitando mais expressividade semntica e facilitando a manipulao do sistema de tipos nessas linguagens.
a)
b) c) d)
e)
2) Com relao ao emprego de conceitos do paradigma de orientao a objetos na anlise e no projeto de sistemas de software, assinale a opo correta. (CESPE - 2010 - SAD-PE - Analista de Controle Interno Tecnologia da Informao)
a) Os mtodos clssicos de anlise e de projeto orientado a objetos buscam refinar aplicao orientada a objetos, desde os requisitos at o cdigo, empregando o conceito de desenvolvimento sem compartimentos, no qual as abstraes orientadas a objeto de nvel mais elevado so transformadas em novo conjunto de abstraes que pouco preservam as relaes com nvel superior por meio da transio bem definida entre as fases do processo de desenvolvimento. Um modelo orientado a objetos em nvel de anlise , tipicamente, composto por grande nmero de classes inter-relacionadas, contendo cada uma delas um conjunto de variveis de estado e mtodos em sua interface. Na modelagem orientada a objetos, a nfase reside nos dados mantidos pelas abstraes do modelo, em oposio ao que ocorre nos mtodos estruturados, cuja nfase inicial recai sobre as funes realizadas pelas abstraes do modelo.
b)
c)
89
d) e)
Aspectos como concorrncia, distribuio e persistncia so mais comumente trabalhados na fase de projeto orientado a objetos que na fase de anlise. Um conjunto de cartes adequadamente desenvolvidos por meio da tcnica CRC (Class-Responsibilities-Colaborators) constitui um artefato til para um desenvolvedor iniciar o processo de codificao de um programa orientado a objetos, na linguagem de programao na qual tenha proficincia.
3)
Considere: Casas ABC Ltda., Empresa e Nome da Empresa. Na orientao a objetos, os itens acima representam, respectivamente, (FCC - 2008 - TCE-AL - Programador) a) Atributo, classe e objeto. b) Classe, atributo e objeto. c) Classe, objeto e atributo. d) Objeto, atributo e classe. e) Objeto, classe e atributo. Os conceitos de generalizao e especializao da orientao a objetos esto diretamente relacionados ao conceito de (FCC - 2008 TCE-AL - Programador) a) Agregao b) Associao c) Encapsulamento d) Polimorfismo e) Herana Os componentes de uma biblioteca de software, no modelo orientado a objetos, correspondem a (FCC - 2008 - TCE-AL Programador) a) Objetos b) Classes c) Subclasses d) Mtodos e) Mensagem Sobre os conceitos de orientao a objetos, considere: I. Classe encapsula dados para descrever o contedo de alguma entidade do mundo real. II. Objetos so instncias de uma classe que herdam os atributos e as operaes da classe. III. Superclasse uma especializao de um conjunto de classes relacionadas a ela. IV. Operaes, mtodos ou servios fornecem representaes dos comportamentos de uma classe. Est completo e correto o que consta em (FCC - 2011 - TRT - 23 REGIO (MT) - Analista Judicirio - Tecnologia da Informao) a) I, II, III e IV
4)
5)
6)
90
b) I, II e IV, apenas. c) II, III e IV, apenas. d) I e II, apenas e) II e IV, apenas. 7) A Anlise e Projeto Orientado a Objetos, um recurso tem como meta principal reduzir o nmero de variveis globais usadas dentro de um programa, consistindo na separao dos aspectos externos de um objeto, permitindo que a sua implementao possa ser modificada sem que afete as aplicaes que o utilizam. Este recurso denominado: a) Encapsulamento b) Independncia c) Polimorfismo d) Modularidade e) Herana 8) Orientao a Objetos um paradigma de anlise, projeto e programao de sistemas de software. A respeito desse paradigma, assinale a afirmativa incorreta. (FGV - 2009 - MEC Analista de Sistemas - Especialista) a) Um objeto pode ser considerado um conjunto de dados. b) Os objetos possuem identidade, estado e comportamento. c) Um evento pode existir se no houver um objeto a ele associado. d) Um objeto pode existir mesmo que no exista nenhum evento associado a ele. e) A orientao a objetos implementa o conceito de abstrao, classe, objeto, encapsulamento, herana e polimorfismo. 9) Em desenvolvimento de sistemas, focalizar nos aspectos essenciais inerentes a uma entidade e ignorar propriedades significa concentrar-se no que um objeto e faz antes de se decidir como ele ser implementado. Na orientao a objetos, este um conceito tpico (FCC - 2011 - TRE-RN - Tcnico Judicirio - Programao de Sistemas) a) Herana b) Reusabilidade c) Abstrao d) Encapsulamento e) Compartilhamento
91
2 BIMESTRE UML
Adaptado da Revista Engenharia de Software Magazine
HISTRIA
Figura 41 Os trs amigos da UML
No incio da dcada de 90 havia mais de 50 mtodos disputando o mercado para se tornar o mtodo principal para a orientao a objetos. Contudo, a maior parte desses mtodos cometia um grave pecado: ser uma extenso dos mtodos estruturados. Os maiores prejudicados eram os usurios que no conseguiam encontrar uma soluo nica e devidamente discutida. Em 1995, mesmo com contribuies valiosas de outros metodologistas, trs metodologias comearam a dominar o mercado: OMT Object Modeling Technique de James Rumbaugh, mtodo Booch de Grady Booch e OOSE Object-Oriented Software Engineering de Ivar Jacobson. Nasceu ainda como um mtodo, teve a mudana de perspectiva, passando a ser uma linguagem de modelagem, desacoplando o processo de desenvolvimento. Nascia a UML Unified Modeling Language na sua verso 0.9.
92
Figura 42 Evoluo da UML (site official da OMG)
Em 1996, a UML j era vista pelas organizaes como uma tima estratgia para seus negcios. A OMG (Object Management Group) emitiu uma RFP (Request for Proposals), que objetivava receber propostas de padronizao para uma metodologia de desenvolvimento orientado a objetos. Respostas foram recebidas da comunidade de engenharia de software e de grandes empresas (Digital, HP, IBM, Microsoft, Oracle e Unisys, entre outras) fortalecendo a proposta da UML. Os objetivos que levaram os desenvolvedores da linguagem UML a lanarem sua verso 2.0 foi reestrutur-la e refin-la de maneira a torn-la mais fcil de aplicar, implementar e adaptar, melhorando sua preciso e capacidade de reutilizao.
CONCEITO
A UML uma linguagem usada para especificar, visualizar e documentar os artefatos de um sistema baseado em objeto, sob desenvolvimento. Ela representa a unificao das notaes de Booch, Rumbaugh e Jacobson, bem como as melhores ideias de uma quantidade de outros tericos de metodologia. Unificando as notaes usadas por esses mtodos baseados em objeto, a Unified Modelling Language oferece a base para um padro de fato no domnio de anlise e projeto baseado em objeto, apoiada em uma ampla base de experincia (Rational Software Corporation).
93
Figura 43 Planta de uma casa
Ou seja, uma linguagem para visualizar, especificar, construir e documentar artefatos de sistema de software. apenas uma abordagem de notao e no propem/define como organizar as atividades de projeto. Por isto, pode ser ajustada para satisfazer a diferentes situaes de desenvolvimento e ciclos de vida. Onde: VISUALIZAR: facilitar entendimento dos modelos projetados; ESPECIFICAR: permite construir modelos precisos, no ambguos e completos; CONSTRUIR: por possuir semntica, os elementos da UML podem estar associados a linguagens de programao.
UTILIZAO
A UML pode ser usada para modelar visualmente: A interao de sua aplicao com o mundo externo; O comportamento de sua aplicao; A estrutura de seu sistema; Os componentes de seu sistema; A arquitetura de sua empresa; Ajuda a visualizar o sistema; Especifica a estrutura e o comportamento; Proporciona um guia para a construo do sistema; Documenta as decises tomadas.
94
NOTAO
Possui semntica bem definida; Satisfaz bem as necessidades para representao de um sistema; bem entendida pelos participantes; genrica e flexvel; No especifica para linguagem de programao.
VANTAGENS
Padro aberto e no proprietrio; Independncia do processo de desenvolvimento; Aplicvel a todas as fases do ciclo de desenvolvimento; Independncia de linguagem de implementao; Integrao das melhores prticas de modelagem; Extensvel; Suporte a conceito de alto nvel.
FASES DO DESENVOLVIMENTO UML

ANLISE DE REQUISITOS: captura as decises e necessidades dos usurios (funes); diagrama de caso de uso mostra que os futuros usurios podem esperar do aplicativo e no se preocupando de como ser implementado. Mostra o que o usurio vai fazer. Ou seja, documento com todas as funes que ele precisa; ANALISE: objetos e mecanismos que estaro no domnio problema. As classes se relacionam (diagrama de classes); do
DESIGN: O resultado da analise atravs de perifricos,. Banco de dados, comunicao entre sistemas, integrao, componentes que precisam ser colocados; PROGRAMAO: as classes do design so convertidas para a linguagem orientada a objeto, como Java, .Net. Esta converso dependendo da linguagem pode ou no ser fcil; TESTES: unidade (classes individuais ou grupos, feita por programadores), integrao (classes e componentes integrados para verificar se as classes esto cooperando uma com as outras e aceitao (testa o sistema como uma caixa preta verificando todo o sistema. Se est de acordo com os requisitos).
95
COMPONENTES DA UML
VISES: mostra diferentes aspectos do sistema que esta sendo modelado. uma abstrao com base em diversos diagramas; MODELOS DE ELEMENTOS: representam definies comuns como mensagens, relacionamentos entre as classes, casos de uso, etc.; MECANISMOS GERAIS: comentrios suplementares, ou seja, informaes ou semnticas sobre os componentes do modelo. Podem ter mecanismos de extenso para estender a UML em um mtodo ou processo; DIAGRAMAS: grficos que descrevem as vises; TESTES: h documentao de testes. Como por exemplo, casos de teste.
MODELOS DE ELEMENTOS
So os conceitos utilizados nos diagramas. Pode ser uma representao grfica presente em diversos diagramas ou definido para que faa parte de um diagrama. So eles: CLASSES, OBJETOS, ESTADOS, PACOTES, COMPONENTES e RELACIONAMENTOS9.
CLASSES
Descrio de um tipo de objeto. Objeto uma instncia de uma classe que define os seus atributos e comportamentos. Exemplo:
Figura 44 Exemplo de Classe
OBJETOS
Elemento que pode manipular, acompanhar seu comportamento, criar, destruir, etc. Tem a semntica de ser exibido sublinhado e antes da classe vem o nome do objeto instanciado. Exemplo:
Usado para conectar outros modelos de elementos.
96
Figura 45 Exemplo de Objetos
ESTADOS
Todos os objetos possuem um estado que significa o resultado de atividades executadas pelo objeto, e normalmente determinada pelos valores de seus atributos e ligaes com outros objetos.
PACOTES
Mecanismo de agrupamento, onde todos os modelos de elementos podem ser agrupados.
Figura 46 Exemplo de Pacotes
COMPONENTES
Pode ser tanto um cdigo em linguagem de programao como um cdigo executvel j compilado.
97
Figura 47 Exemplo de Componentes
RELACIONAMENTOS
Os relacionamentos ligam as classes/objetos entre si criando relaes lgicas entre estas entidades. Tipos de relacionamentos: ASSOCIAO; GENERALIZAO; DEPENDNCIA E REFINAMENTOS.
TIPOS DE ASSOCIAO
NORMAIS: tipo mais comum. apenas uma conexo entre classes. Possui um verbo ou substantivo na linha da associao e pode ter uma seta indicando a direo.
Figura 48 Exemplo de Associao
RECURSIVA: possvel conectar uma classe a ela mesma atravs de uma associao e que ainda representa semanticamente a conexo entre dois objetos, mas os objetos conectados so da mesma classe.
98
Figura 49 Exemplo de Recursividade
QUALIFICADA: associaes classificadas so usadas como associaes de um para vrios (1..*) ou de vrios para vrios (*).
Figura 50 Exemplo de Qualificada
EXCLUSIVA: uma restrio em duas ou mais associaes. Onde os objetos s podem participar de uma classe em determinado momento (linha tracejada).
Figura 51 Exemplo de Exclusividade
ORDENADA: as associaes entre objetos podem ter uma ordem implcita. O padro para uma associao desordenada. CLASSE: uma classe pode ser associada a uma outra associao.
99
Figura 52 Exemplo de classe associativa
TERNRIA: mais de duas classes podem ser associadas entre si, a associao ternria associa trs classes.
Figura 51 Exemplo de classe ternria
AGREGAO: caso particular da associao. Pode ser: o COMPARTILHADA: quando uma das classes uma parte, ou est contida da outra, mas esta parte pode fazer estar contida na outras vrias vezes em um mesmo momento;
Figura 52 Exemplo de agregao
100
COMPOSIO: uma classe que est contida na outra vive e constitui a outra. Se o objeto da classe que contm for destrudo, as classes da agregao de composio sero destrudas juntamente j que as mesmas fazem parte da outra.
Figura 53 Exemplo de composio
GENERALIZAO: relacionamento entre um elemento geral e um outro mais especfico. Pode ser:
Figura 54 Exemplo de generalizao
NORMAL: a classe mais especfica (subclasse) herda tudo da classe mais geral (superclasse); RESTRITA: especifica informaes mais precisas sobre como a generalizao deve ser usada e estendida no futuro. As restries definem a generalizaes restritas com mais de uma subclasse: DEPENDNCIAS: conexo semntica entre dois modelos de elementos, um independente e outro dependente.
101
Figura 55 Exemplo de dependncia
REFINAMENTOS: tipo de relacionamento entre duas descries de uma mesma coisa, mas em nveis de abstrao diferentes e podem ser usados para modelar diferentes implementaes de uma mesma coisa.
MECANISMOS GERAIS
ORNAMENTO: anexado ao modelo acrescentando semntica. Exemplo separar o tipo de instancia que colocado em negrito. Uma classe colocada em negrito e se h um objeto colocado sublinhado. Outro a multiplicidade; NOTA: nem tudo pode ser definido na linguagem e para colocar observaes usamos notas em UML e pode ser colocada em qualquer lugar do diagrama.
DIAGRAMAS
Um diagrama uma representao grfica parcial ou total de um modelo. Apresentao grfica de uma coleo de elementos de modelo, geralmente processados como um grfico de arcos (relacionamentos) e vrtices (outros elementos de modelo) conectados. A UML 2.0 (verso atual) define 13 tipos de diagramas divididos em duas categorias de modelagem: ESTTICA (ESTRUTURAL) ou DINMICO (COMPORTAMENTO).
DIAGRAMAS ESTRUTURAIS (ESTTICOS)
Definem estaticamente a arquitetura de um modelo. So usados para modelar as coisas que compem um modelo - as classes, os objetos, as relaes e os componentes fsicos. Alm disso, tambm so usados para modelar os relacionamentos e as dependncias entre elementos. Fazem parte dos diagramas da modelagem estruturada: DIAGRAMA DE CLASSES apresenta classes conectadas por relacionamentos. Usado para exibir entidades do mundo real, alm de elementos de anlise e projeto; DIAGRAMA DE OBJETOS apresenta objetos e valores de dados. Corresponde a uma instncia do diagrama de classes, mostrando o estado de um sistema em um determinado ponto do tempo;
102
DIAGRAMA DE COMPONENTES mostra as dependncias entre componentes de software, apresentando suas interfaces; DIAGRAMA DE ESTRUTURA COMPOSTA usado para mostrar a composio de uma estrutura. til em estruturas compostas de estruturas complexas ou em projetos baseados em componentes; DIAGRAMA DE PACOTES usado para organizar elementos de modelo e mostrar dependncias entre eles; DIAGRAMA DE IMPLANTAO mostra a arquitetura do sistema em tempo de execuo, as plataformas de hardware, artefatos de software e ambientes de software (como sistemas operacionais e mquinas virtuais).
DIAGRAMAS COMPORTAMENTAIS (DINMICOS)
Os diagramas dinmicos ou de comportamento apresentam as variedades da interao e do estado instantneo dentro de um modelo enquanto executado. So eles: DIAGRAMA DE CASOS DE USO mostra os casos de uso, atores e seus relacionamentos que expressam a funcionalidade de um sistema; DIAGRAMA DE ATIVIDADES representa a execuo de aes ou atividades e os fluxos que so disparados pela concluso de outras aes ou atividades; DIAGRAMA DE MQUINA DE ESTADOS representa as aes ocorridas em resposta ao recebimento de eventos; DIAGRAMAS DE INTERAO: o DIAGRAMA DE SEQUNCIAS mostra as interaes que correspondem a um conjunto de mensagens trocadas entre objetos e a ordem que essas mensagens acontecem; o DIAGRAMA DE COMUNICAO antigo diagrama de colaborao, que mostra objetos, seus inter-relacionamentos e o fluxo de mensagens entre eles; o DIAGRAMA TEMPORAL mostra a mudana de estado de um objeto numa passagem de tempo, em resposta a eventos externos; o DIAGRAMA DE VISO GERAL DE INTERAO uma variao do diagrama de atividades que mostra de uma forma geral o fluxo de controle dentro de um sistema ou processo de negcios. Cada n ou atividade dentro do diagrama pode representar outro diagrama de interao.
103
Pode-se afirmar que possvel se completar a modelagem de um sistema de pequeno ou mdio porte, com sucesso, com apenas trs diagramas (casos de uso, classes e sequncias), tendo o suporte, dependendo do contexto, de trs outros diagramas (objetos, atividades e mquina de estados). O paradigma da orientao a objetos veio definitivamente ocupar um espao que h muito se necessitava no mercado de desenvolvimento. Cabe aos desenvolvedores entenderem a importncia de se respeitar todos os seus conceitos, para que se obtenha o melhor do que ele nos prope.
EXERCCIOS
1)
Os diagramas UML da categoria comportamental so os de (FCC 2008 - TCE-AL - Programador) a) Classes, Objetos e componentes b) Casos de Uso, Sequncias e Classes c) Classes, Atividades e Sequncias d) Casos de uso, atividades e mquina de estados e) Objetos, estrutura composta e mquinas de estado Um diagrama UML uma apresentao grfica de uma coleo de elementos do modelo de um sistema. O diagrama utilizado pela UML que apresenta a interao entre os objetos em relao ao tempo o de (FESMIP-BA - 2011 - MPE-BA Analista de Sistemas)
2)
a) Componentes b) Implantao c) Estado d) Classes e) Sequncia 3)
Na UML, os diagramas de sequncia e os diagramas de atividade, tambm denominados diagramas de interao, auxiliam a modelar os aspectos dinmicos de sistemas. Um diagrama de interao formado pelo conjunto de objetos e seus relacionamentos e inclui as mensagens que podero ser enviadas entre eles. (CESPE - 2010 TRE-BA - Tcnico Judicirio - Programao de Sistemas)
__ Certo __ Errado 4) Analise as seguintes afirmativas sobre os Diagramas de Interao da UML. I. Um Diagrama de Interao mostra a interao entre um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podero ser trocadas entre eles. II. Diagramas de Sequncia e Diagramas de Colaborao so Diagramas de Interao e modelam aspectos dinmicos de sistemas.
104
III. Diagramas de Colaborao do nfase ordenao temporal das mensagens trocadas entre os objetos. Marque a alternativa CORRETA: (FUMARC - 2011 - BDMG - Analista de
Sistemas)
a) Afirmativas I e II so verdadeiras. b) Afirmativas I e III so verdadeiras. c) Afirmativas II e III so verdadeiras. d) Todas as afirmativas so verdadeiras. 5) A respeito da linguagem UML correto afirmar que (Concurso Serpro-2001): a) no se trata de uma linguagem de documentao. b) voltada para a representao conceitual e fsica de um sistema. c) no abrange a documentao para a realizao de testes. d) no deve ser empregada para a documentao de artefatos que faam uso de sistemas completos de software. e) uma linguagem utilizada para a realizao de testes de programas. 6) Entre outros, a UML inclui os diagramas de (Concurso Serpro-2001): a) classes, objetos, fluxo de dados e de atividades. b) classes, implantao, grficos de estado e de sequncias. c) objetos, classes, contexto, implantao. d) classes, objetos, testes, implantao. e) objetos, casos de uso, contexto, implantao. 7) Na UML, as classes A e B legam suas estruturas e comportamentos classe C. Considerando apenas o fato apresentado nessa circunstncia, correto afirmar que a se aplica tipicamente o conceito de (FCC - 2009 - TRT - 7 Regio (CE) - Analista Judicirio - Tecnologia da Informao) a) delegao. b) derivao. c) herana mltipla. d) mtodo polimrfico. e) multiplicidade. 8) A UML define em sua verso 2.0, treze tipos de diagramas, divididos em duas categorias: diagramas estruturais e diagramas dinmicos. Assinale a alternativa que no indique um diagrama estrutural da UML. (FGV - 2009 - MEC - Analista de Sistemas - Especialista) a) Diagrama de Viso Geral. b) Diagrama de Implantao. c) Diagrama de Pacotes. d) Diagrama de Classes. e) Diagrama de Objetos.
105
DIA PORTABLE
Figura 56 Tela principal do Dia Portable
O Dia Portable uma ferramenta baseada no Microsoft Visio, com a qual pode-se compor layouts, fluxogramas, organogramas e diagramas em geral, contando tambm com objetos para modelagem UML e de sistemas Estruturados. Este programa pode ser utilizado tanto em seu computador como a partir de um pendrive. Auxilia os analistas e desenvolvedores de sistemas na criao e integrao dos diagramas de dados da UML com a lgica. Com ele possvel especificar recursos, transaes, trocas de comunicao, plano de custos com tempo, esforo, entre outras. Alm disto, alm de modelagem de negcio voltada para informtica, tambm possvel montar diversos tipos de diagramas. A interface disposta de forma que no centro est o espao para o projeto, acima esto os menus e opes e esquerda encontram-se as ferramentas para modelagem. Ainda com relao a estas ferramentas, elas esto dispostas em dois grupos. O mais acima possui formas geomtricas, textos, setas e opes de linha para ligao. Logo abaixo esto os objetos de um diagrama conforme categoria. Basicamente estas categorias so quatro: variados, fluxograma, UML e outras folhas. Esta ltima categoria contm 35 grupos de objetos, constando entre eles alguns relacionados ciberntica, luzes, peas de quebra cabea, hidrulicos, banco de dados, UML, BPMN,
106
cisco, entre muitos outros. Desta forma, muito pouco provvel que voc no venha a encontrar o desenho que precisa para seu diagrama. Para utiliz-lo simples, basta abrir um novo projeto e comear a desenhar seus diagramas. Para inserir novos objetos, primeiro escolha uma categoria na caixa de opes no lado esquerdo da tela. Feito isto, escolha as formas que deseja inserir em seu projeto e para adicion-las basta clicar sobre a figura com o mouse e arrast-la at o quadro (ou clicar sobre a figura e sobre o quadro) medida que uma figura vai sendo posicionada na tela, voc pode observar seu enquadramento correto por meio do fundo quadriculado e das rguas horizontais e verticais dispostas para tal funo. Se aps inserir a figura houver algum problema, para apag-la basta selecionar e utilizar o delete do teclado. Na barra de ferramentas situada na borda superior do programa esto disponveis diversos tipos de opes para ajudar em seu desenho, como opes de criao de camadas, exibio de grade, posicionamento, mtodos de entrada, seleo, gravao de seu diagrama, entre outras.
107
MICROSOFT VISIO 2003
Figura 57 Tela principal do Visio 2003
Na barra de ferramentas situada na borda superior do programa esto disponveis diversos tipos de opes para ajudar em seu desenho, como opes de criao de camadas, exibio de grade, posicionamento, mtodos de entrada, seleo, gravao de seu diagrama, entre outras. Clique em Software e Banco de Dados e escolha...
DIAGRAMA DE MODELO UML
Surge a tela a seguir:
108
Figura 58 Tela do Diagrama do Modelo UML
Divide-se em:
ATIVIDADE DE UML
Figura 59 Atividade de UML
COLABORAO DE UML
Figura 60 Colaborao de UML
109
COMPONENTE UML
Figura 61 Componente UML
IMPLANTAO DE UML
Figura 70 Implantao de UML
SEQUNCIA DE UML
Figura 62 Sequncia de UML
GRFICO DE ESTADO DE UML
Figura 63 Grfico de Estado de UML
110
ESTRUTURA ESTTICA DE UML
Figura 64 Estrutura Esttica de UML
Nesta rea se encontra as formas para o diagrama de classes.

CASO DE USO
Figura 65 Caso de Uso
PROPRIEDADES DA FORMA
Para inserir uma forma necessrio selecion-la e arrast-la para a rea de trabalho. Com a forma na rea de trabalho, d um clique duplo e surge a tela de propriedades de acordo com a forma escolhida.
111
Figura 66 Exemplo de Propriedades
Para salvar o arquivo como imagem basta escolher o menu ARQUIVO, SALVAR ou SALVAR COMO e escolher em SALVAR COMO TIPO, o Formato JPEG (*.jpg):
Figura 67 Tela do Salvar Como
OBSERVAES
Neste site h uma apostila sobre o assunto: http://www.projetoderedes.com.br/apostilas/apostilas_so.php Serial: PHGVY-62VQH-6YR3J-46D86-TG2MT
112
DIAGRAMA DE CASO DE USO
Figura 68 Etapas do caso de uso
CASOS DE USO
Descreve um conjunto particular de funcionalidades do sistema, modelando o dilogo que uma entidade externa, chamada ator, realiza com o sistema. Especifica o comportamento de um sistema ou parte dele. tambm uma descrio do conjunto de passos que o sistema executar para desempenhar suas funes. baseado em um cenrio descritivo de como a entidade externa interage com o sistema. Identifica eventos que podem ocorrer e descreve a resposta do sistema para estes eventos. Quando combinados, os casos de uso constituem todas as formas de uso do sistema e fornecem uma viso do sistema focada na funcionalidade. Possibilita um formato de apresentao compreensvel que pode ser utilizado para aprimorar a comunicao, especialmente entre os projetistas da aplicao e os clientes. So muito usados nas fases posteriores do ciclo de vida, ajudando na identificao dos objetos, desenvolvimento de planos de teste e documentao.
113
Figura 57 Exemplo de diagrama de caso de uso
O fator mais importante para o caso de uso a ESPECIFICAO PARA CADA CASO DE USO. Anlise tradicional: O QUE O SISTEMA DEVE FAZER? Anlise por caso de uso: O QUE O SISTEMA DEVE FAZER... E PARA QUEM?
ATOR
So entidades do meio ambiente (externa ao sistema) que interagem com o sistema para obter alguma funcionalidade. Podem ser: humanos, outros sistemas, organizaes, dispositivos externos, etc., que interagem com o sistema. Alguns atores do incio a eventos enquanto outros interagem com o sistema em decorrncia do resultado de outros eventos.
COMO IDENTIFICAR OS ATORES
Quem utilizar as funcionalidades do sistema? Quem ir manter, administrar e fazer com que o sistema permanea em operao? Quem se interessa pelos resultados produzidos pelo sistema? Com quais outros dispositivos ou sistemas o sistema em foco ir interagir?
CASO DE USO
Utilizado para representar as funcionalidades do sistema. Representar o que o sistema faz (no como).
uso.
A descrio do caso de uso ocorre na especificao de casos de
Exemplo: Cliente de banco pode usar um caixa automtico para sacar dinheiro, transferir dinheiro ou consultar o saldo da conta:
114
Ator: CLIENTE Casos de Uso: sacar dinheiro, transferir dinheiro e consultar saldo.
COMO IDENTIFICAR CASOS DE USO
O ator precisa ler, criar, destruir, modificar ou armazenar algum tipo de informao no sistema? O trabalho do ator pode ser simplificado ou tornado mais eficiente atravs de novas funes no sistema? Quais as funes que o ator necessita no sistema? O que o ator necessita fazer? Quais so os principais problemas com a implementao atual do sistema? Quais so as entradas e as sadas desejadas?
CENRIO
Um cenrio a descrio de uma das maneiras pelas quais um caso de um pode ser realizado. Um cenrio tambm chamado de instncia de um caso de uso. Normalmente h diversos cenrios para um mesmo um caso de uso.
RELACIONAMENTO DE EXTENSO
Um caso de uso pode ser estendido por outro (funcionalidade). Pode ser usada para: Simplificar fluxos de eventos complexos; Representar comportamentos opcionais; Lidar com excees. A extenso ocorre em pontos especficos (pontos de extenso).
115
A extenso pode ou no ser usada pelo caso de uso de origem. O <<extend>> ocorre somente entre casos de uso. Em uma especificao de caso de uso, a extenso seria o fluxo alternativo (comportamento opcional).
RELACIONAMENTO DE INCLUSO
Um caso de uso pode ser incluir outro no sentido de sempre utilizar suas funcionalidades. Pode ser usada para: Representar comportamentos reutilizveis; Simplificar fluxos de eventos complexos. O <<include>> um vnculo obrigatrio, ou seja, SEMPRE usar as suas funcionalidades (inclui todo o comportamento do caso de uso que est sendo includo).
RELACIONAMENTO DE ESPECIALIZAO
Um caso de uso pode ser especializar outro (adio/refinamento do fluxo de eventos original). Especializao permite modelar comportamento de estruturas de aplicao em comum. Este tipo de relacionamento ocorre entre atores e entre casos de uso.
RELACIONAMENTO ENTRE CASOS DE USO
GENERALIZAO: classes;
mesma
semntica
da
generalizao
entre
INCLUDE: caso de uso base incorpora o comportamento do caso de uso includo (reutilizao); EXTEND: caso de uso base incorpora o comportamento de um outro caso de uso em local especificado. Utilizamos este relacionamento quando necessrio modelar parte do caso de uso que o usurio pode ver como comportamento opcional do sistema.
116
Figura 71 Tipos de Relacionamentos
As setas do <<include>> e do <<extend>> so tracejadas, o que muda o sentido da seta: no include, a seta parte do caso de uso base para o caso de uso a ser includo. J no extend a seta parte do caso de uso que estende para o caso de uso estendido. Exemplo de INCLUDE:
Figura 72 Exemplo de diagrama de caso de uso <<include>>
117
Exemplo de EXTEND:
Figura 73 Exemplo de diagrama de caso de uso <<extend>>
EXEMPLO: ESTUDO DE CASO LOCADORA DE VECULOS Uma locadora de veculos deseja um sistema para facilitar o atendimento a seus clientes. O processo de aluguel de carros atual confuso e est gerando insatisfao entre os clientes. A locadora composta basicamente pelos seus funcionrios e carros para aluguel. Os funcionrios so identificados por cpf, nome, endereo, telefone. J os carros esto divididos em diversos tipos: popular, luxo, utilitrio, etc. As informaes importantes sobre os carros a serem armazenadas so: cdigo (chapa do carro), tipo, modelo, ano, cor, chassis, km e valor do aluguel (dirias e semanais). Os funcionrios sero responsveis pelo cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o aluguel de um carro para o cliente e dar baixa no aluguel. Existem clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto e um valor de quilometragem extra para seus aluguis. Qualquer cliente identificado por RG, nome, CPF, telefone, endereo, cidade. Desta forma, o cliente poder solicitar o aluguel de carros a um funcionrio da locadora. Os tpicos abaixo descrevem as funcionalidades do sistema. Alugar Carro: cliente deve solicitar ao funcionrio o aluguel do carro. O sistema verifica se o carro solicitado pelo cliente est disponvel. Caso esteja, o processo de locao concludo e o carro passa a estar indisponvel. A data de aluguel deve ser guardada para calculo do valor do aluguel na devoluo. Dar Baixa: cliente faz devoluo do carro para o funcionrio e solicita nota fiscal (recibo) com a quilometragem percorrida e o valor do aluguel. O funcionrio coloca o status do carro novamente como disponvel, solicita ao sistema para calcular o valor a ser pago e emite o recibo para o cliente. Cadastrar Cliente: cliente solicita ao funcionrio que o cadastre na locadora. O funcionrio recebe os dados e cadastra-o.
118
Cadastrar Carro: funcionrio cadastra o carro adquirido.
CASOS DE USO: Alugar carro, dar baixa, cadastrar cliente e cadastrar carro; ATOR: Funcionario.
ANLISE DE CASOS DE USO

Os Casos de uso expressam o qu o sistema dever fazer. E no como fazer. Casos de uso formam a base para testes e documentao do sistema. O modelo de casos de uso expressam todos os casos de uso do sistema e os seus relacionamentos. As tcnicas para criar e expressar casos de uso em uma aplicao Web so as mesmas para construir outros sistemas de software. OBJETIVOS: Identificar os atores; Identificar os casos de uso; Desenhar os casos de uso; Escrever cenrios.
EXERCCIOS
1) A figura abaixo ilustra um Diagrama de Casos de Uso e utilizada no desenvolvimento de projetos de sistemas, utilizando ferramentas da Anlise Orientada a Objetos. O relacionamento entre o ator Cliente e o caso de uso Comprar um produto, denominado e definido como: (FGV - 2009 - MEC - Analista de Sistemas - Especialista)
119
a) b) c) d) e)
Associao/uma funcionalidade do sistema do ponto de vista usurio Generalizao/uma funcionalidade do sistema do ponto de vista usurio. Associao/uma funcionalidade do sistema do ponto de vista relacionamento. Globalizao/uma funcionalidade do sistema do ponto de vista relacionamento. Generalizao/ uma funcionalidade do sistema do ponto de vista relacionamento.
do do do do do
2)
ESTUDO DE CASO: RESERVA DE PASSAGENS AREAS:
120
Com base na lista de requisitos funcionais, elabore o diagrama de caso de uso: RF1: Sistema deve permitir o cadastro de usurios. RF2: Sistema deve permitir que usurio se identifique. RF3: Sistema deve consultar a classe de voo. RF4: Sistema deve consultar o trecho da viagem. RF5: Sistema deve permitir consulta aos aeroportos. RF6: Sistema deve permitir consulta as datas disponveis de ida e volta. RF7:Sistema deve permitir que usurio consulta as formas de pagamento. RF8:Sistema deve enviar para os usurios cadastrados e-mails promocionais. RF9: Sistema deve permitir que usurio consulta CEP no sistema de correios RF10: Sistema deve permitir que o usurio solicite a reserva on-line. RF11: Sistema deve gerar cdigo da reserva. RF12: Sistema deve emitir e-mail para usurio confirmando a reserva com dados. RF13: Sistema deve permitir que usurio cancela a reserva. RF14: Sistema deve permitir que o administrador emita relatrio de reservas confirmadas. RF15: Sistema deve permitir que o administrador emita relatrio de reservas canceladas. RF16: Sistema deve validar o pagamento junto com a operadora de carto. RF17: Sistema deve permitir que o Administrador emita relatrio de usurio cadastrados. RF18: Sistema deve permitir que usurio edite seus dados pessoais. 3) ESTUDO DE CASO: GESTO DE USURIO DE SISTEMAS DE FORMAO: RF1:O software deve identificar e validar todos os usurios que desejarem acess-lo, identificando o seu perfil. RF2:O software deve disponibilizar ao usurio identificado: as funcionalidades associadas ao seu perfil e ao seu papel no sistema (coordenador, bolsista, etc), as funcionalidades de acesso restrito e as funcionalidades de acesso pblico. RF3:O software deve disponibilizar ao usurio no identificado somente as funcionalidades pblicas. RF4:O software deve permitir ao usurio recuperar a sua senha, caso esquea. RF5:O software deve permitir que o administrador inclua, altere ou exclua usurios. RF6:O software deve permitir que o administrador inclua, altere ou exclua perfis de acesso.
121
RF7:O software deve permitir que o administrador associe as funcionalidades disponveis nos mdulos aos perfis cadastrados ou exclua dos perfis as funcionalidades previamente associados. RF8:O software deve permitir que o administrador associe um usurio a um perfil de acesso. RF9:O software deve permitir ao administrador consultar as funcionalidades associadas a um perfil. RF10:O software deve permitir ao administrador consultar aos usurios associados a um determinado perfil. RF11:O software deve permitir ao administrador indicar se determinado usurio pode administrar seus substitutos ou no. RF12:O software deve permitir que os usurios devidamente autorizados designem um ou mais substitutos com os respectivos perodos de substituio (data inicial e final) e selecionem um subconjunto das suas funcionalidades as quais os substitutos tero acesso. RF13:O software deve permitir que todos os usurios faam a manuteno de seus dados pessoais: email, localizao, senha e telefones. RF14:O software deve permitir que os administradores reenviem a senha de qualquer usurio e que os usurios reenviem a prpria senha. RF15:O software deve gerar senhas temporrias, vlidas somente no primeiro login, quando as senhas forem reenviadas pelos administradores ou pelos prprios usurios. RF16:O software deve solicitar a troca de senha, aps o login, para todas as senhas que j expiraram. RF17:O software deve, caso o usurio corrente seja um substituto, apresentar a lista de usurios que ele est substituindo na data corrente. RF18:O software deve, caso o usurio corrente seja um substituto, permitir que ele selecione o usurio com o qual vai atuar, caso ele seja substituto de mais de um usurio. 4) Estudo de Caso: Transportadora: Os funcionrios da transportadora devem cadastrar clientes, filiais, veculos, funcionrios, tipos de veculos, cidades, distancias, categorias de frete e fretes de clientes. Clientes so pessoas fsicas e possuem: nome, endereo e telefone. Filiais tm: nome, endereo, telefone, funcionrio responsvel e vrios veculos. Veculos devem possuir placa e um tipo de veiculo, alm de ser necessariamente de uma filial. Funcionrios so identificados pela matricula e tm ainda: nome, endereo, telefone e dependentes (nome e data de nascimento), alm de estar associado, obrigatoriamente a uma filial. Tipo de
122
veculo apresenta uma descrio (caminho, moto, etc) e o peso mximo que Pode transportar alm de estar associado a veculos. Cidades contm nome e estado a que pertence, representando as cidades abrangidas pela empresa. Distncia envolve as cidades origem e destino e para cada par de cidades atendidas, deve haver a distncia em quilmetros entre elas.
Categoria do frete deve conter descrio e um percentual, que deve incidir sobre o valor do frete onde, por exemplo, entregas rpidas tm aumento de 10% entregas super-rpidas tem aumento de 30% e entrega normal no tem acrscimo no valor. Cada frete tem um cdigo, um cliente, o veiculo deve efetuar o frete, cidade origem e destino, funcionrio responsvel e itens a serem transportados, no podendo haver um frete sem os dados citados. Ainda precisa ter o valor a ser calculado atravs da distncia percorrida entre as cidades: origem e destino e da categoria do frete. Para isso, deve existir um valor padro para o km rodado. Um item de transporte cada objeto a ser transportado num frete e deve possuir apenas uma descrio e seu peso. Por fim, temos que o sistema ainda deve emitir Nota Fiscal com todas as informaes de um determinado frete, logo aps o seu cadastramento.
a) Diagrama de Caso de Uso; b) Especificao do caso de uso: Cadastrar Cliente. 5) Com base nos requisitos funcionais, criar um diagrama de caso de uso: RF01 Cadastrar aparelho de refrigerao RF02 Efetuar logon de funcionrio RF03 Cadastrar funcionrio RF04 Consultar histrico RF05 Consultar temperatura de ambiente RF06 Alterar temperatura de ambiente RF07 Encaminhar ordem de servio RF08 Gerar relatrio de gastos RF09 Gerar relatrio de performance e consumo RF10 Consultar funcionrio RF11 Remover funcionrio RF12 Consultar aparelho de refrigerao RF13 Remover aparelho de refrigerao 6) ESTUDO DE CASO: LOCADORA DE VECULOS Uma locadora de veculos deseja um sistema para facilitar o atendimento a seus clientes. O processo de aluguel de carros atual confuso e est gerando insatisfao entre os clientes. A locadora formada basicamente pelos seus clientes e carros para aluguel. Os carros esto divididos em diversos tipos: popular, luxo e utilitrio. As informaes importantes sobre os carros a serem armazenadas so:
123
cdigo (placa do carro), tipo, modelo, ano, cor, chassis, quilometragem e valor do aluguel (diria). Os funcionrios sero responsveis pelo cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o aluguel de um carro para o cliente e dar baixa no aluguel. Existem clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto e um valor de quilometragem extra para seus aluguis. Qualquer cliente identificado por RG, nome, CPF, telefone, endereo, contato. a) Diagrama de Caso de Uso; b) Especificao do caso de uso: Cadastrar Cliente e Efetuar Aluguel. 7) ESTUDO DE CASO: SALO DE FESTAS
RF01 - O software dever permitir que o gerente cadastre sales de festas. RF02 - O software dever permitir que o gerente cadastre profissionais. RF03 - O software dever permitir que o gerente realize o cadastramento de servios utilizados em uma festa de casamento, como buffet, carros utilizados. RF04 - O software dever permitir que o cliente realize o cadastramento da lista de convidados. RF05 O software dever permitir que o cliente realize o cadastramento das lojas de presentes. RF06 - O software dever permitir que o cliente elabore da configurao da festa pelo cliente. RF07 - O software dever permitir a gerao do oramento para o cliente. RF08 - O software dever permitir que o gerente realize a impresso de relatrios de festas. RF09 - O software dever permitir que o cliente cadastre a lista de presentes. RF10 - O software dever permitir que o gerente realize o cadastramento de usurios. RF11 - O software dever permitir a autenticao dos usurios
a) Diagrama de caso de uso;

TAREFA 06 DIAGRAMA DE CASO DE USO (1,0)
Para este sistema, o gerente deve cadastrar agncias, clientes e abrir e fechar contas bancrias. Um cliente possui nome, endereo e telefone. Um cliente pode abrir vrias contas e uma conta pode ser de vrios clientes, para o caso de contas conjuntas. Contas so de uma determinada agncia (que possui nome e nmero), alm de poderem estar vinculadas a uma conta de investimento, que nada mais que outra conta bancria. Contas ainda devem possuir um nmero (formado pelo nmero da agncia e pelo nmero da prpria conta) e saldo disponvel, podendo ser corrente normal, corrente especial e poupana. Para contas poupana, devem-se armazenar os dias de vencimento e, para contas corrente especiais, informar o limite de crdito. Contas ainda possuem movimentaes de saque e depsito,
124
que devem ter data e valor, alm do tipo de movimento, que pode ser dbito ou crdito. Clientes ainda podem solicitar cartes de contas bancrias, que devem ter nmero, validade e senha para cada cliente, alm de tales de cheques para contas correntes, que devem armazenar o nmero inicial e final das folhas do talo. O sistema ainda deve permitir aos clientes consultar saldos e extratos. DIAGRAMA DE CLASSES Representao dos dados manipulados e armazenados pelos programas de acordo com os conceitos de Orientao a Objetos. Notao fortemente baseada no Diagrama Entidade-Relacionamento de Peter Chen. Deve-se observar que o Diagrama de Classes privilegia a descrio segundo o paradigma OO. Resumindo: Trata de dados e funes.
CLASSE
uma descrio de um conjunto de objetos que compartilham os mesmos atributos, operaes, relacionamentos e semntica. Representa a abstrao de um conjunto de OBJETOS do Mundo Real que possuem tipos de caractersticas e de comportamento em comum. Exemplo: PESSOA.
Figura 75 Elementos de uma Classe (Fonte: RAMOS - USP)
Toda classe deve representar uma abstrao conceitual do domnio do problema ou da soluo. Assim, uma classe bem estruturada deve ser uma abstrao de um conceito presente no domnio do problema ou da soluo, ser fortemente coesa e possui baixo acoplamento.
125
CONVENES
O nome da classe deve comear por letra maiscula; O nome do atributo deve iniciar por minsculo, porm o segundo nome deve ser maisculo. Exemplo: Cliente ou SensorTemperatura; O nome da classe deve ser no singular; Pode-se ter classes sem atributos ou mtodos; Deve ter um nome que a diferencie das outras classes; Normalmente so substantivos ou expresses breves;
ATRIBUTOS
Um atributo uma propriedade nomeada de uma classe que descreve um intervalo de valores que as instncias podem apresentar. Uma classe pode ter qualquer nmero de atributos ou mesmo nenhum atributo. Representa alguma propriedade do item que est sendo modelado, compartilhado por todos os objetos desta classe. Um objeto de uma classe poder ter valores especficos para cada um dos seus atributos. Exemplo: Todo estudando possui nome, data de nascimento, e sexo.
OPERAES
Uma operao a assinatura de uma implementao de um servio que pode ser solicitado por algum objeto da classe para modificar seu estado.
VISIBILIDADE
uma propriedade cujo valor (pblico, protegido ou privado) denota como o elemento poder ser visto externamente: PBLICO (+): qualquer objeto pode acessar os atributos ou operaes da classe que se relacione com a classe que o possui; PROTEGIDO (#): atributos e operaes de uma classe so acessveis apenas por suas subclasses, ou seja, pode ser acessado apenas pelos descendentes da classe; PRIVADO(-): atributos e operaes de uma classe so acessveis apenas pela prpria classe.
RELACIONAMENTOS
Especifica como as classes se relacionam. Podem ser de trs tipos:
126
ASSOCIAO
Especifica que objetos de um elemento esto conectados a objetos de outros elementos.
Figura 76 Exemplo de Associao entre Classes (Fonte: RAMOS - USP)
ASSOCIAO COM NAVEGAO possvel navegar de objetos de um tipo at objetos do outro tipo. A menos que seja especifico o contrrio, a navegao ser bidirecional. A seta indica a direo a ser seguida.
Figura 77 Exemplo de Associao com Navegao (Fonte: RAMOS - USP)
AGREGAO
A informao de agregao representada por um losango colocado junto classe que representa o elemento agregador ou o todo, ou seja, o diamante indica a classe todo (a que agrega). RESUMO: FAZ PARTE.
127
Figura 78 Exemplo de Agregao entre Classes (Fonte: RAMOS - USP)
COMPOSIO
Tambm chamada de AGREGAO COMPOSTA uma variante agregao simples, em que adicionada a seguinte semntica: (1) forte pertena do todo em relao parte; (2) tempo de vida delimitado (as partes no podem existir sem o todo). Adicionalmente, o todo responsvel pela disposio das suas partes, ou seja, o todo responsvel pela criao e destruio das suas partes. A informao de agregao composta representada por um losango cheio colocado junto classe que representa o elemento agregador ou o todo.
Figura 79 Exemplo de Composio entre Classes (Fonte: RAMOS - USP)
CLASSE DE ASSOCIAO
A associao entre classes pode tambm ter os seus prprios atributos (e eventualmente operaes), devendo ser, por conseguinte, modelada tambm como uma classe. A este tipo chamamos de CLASSE DE ASSOCIAO.
128
Figura 80 Exemplo de Classe Associao (Fonte: RAMOS - USP)
HERANA
Simplifica a definio de classes que so quase iguais s que j foram definidas. Permite a reutilizao de definies comuns. Geralmente identifica-se uma herana quando diz-se a palavra um.
Figura 81 Exemplo de Herana (Fonte: RAMOS - USP)
HERANA MLTIPLA Na herana nica, uma classe tem um conjunto de pais (uma cadeia de superclasse). A herana mltipla envolve do que uma cadeia de superclasses. Problemas: Choques de nomes de atributos ou mtodos; Dificulta a manuteno do cdigo fonte.
129
Figura 82 Exemplo de Herana Mltipla (Fonte: RAMOS - USP)
MULTIPLICIDADE Embora a multiplicidade seja especificada para classes, ela define a quantidade de objetos que participam de um relacionamento. Existem dois indicadores de multiplicidade para cada associao ou agregao (uma em cada final de linha).
Figura 85 Exemplo de Multiplicidade
DIAGRAMA DE CLASSE
utilizado para: modelar a viso esttica do projeto de um sistema; modelar o relacionamento entre os diversos objetos que faro parte do sistema; capturar o vocabulrio do problema; ancorar os comportamentos em suas classes;
130
gerar as declaraes da estrutura das classes.
Figura 86 Exemplo de diagrama de classe
Explicao do diagrama de classes: CLIENTE pode estar associado a 0 OU N PEDIDOS e este est associado a pelo menos um tipo de pagamento (abstrata, no instanciada: crdito, dinheiro ou cheque). PEDIDO composto de partes (agregao): detalhes do pedido, ou seja, um ou mais detalhes de pedido e est associado a um item do estoque que ser dado baixa. A dificuldade elaborar o diagrama e no na leitura, principalmente quando h muitas informaes. H projetos com 100 classes e tende a ter complexidade alta e quando o domnio definido mais fcil. COMO FAZER UM DIAGRAMA DE CLASSES Identifique um primeiro conjunto de classes; Adicione atributos e comportamentos; Encontre generalizaes; Adicione associaes; Reveja o modelo construdo adicionando ou removendo classes, atributos, associaes ou generalizaes.
IDENTIFICANDO AS CLASSES
Ler a especificao de requisitos; Extrair nomes: simples ou compostos; Eliminar os que so: redundantes, representam instncias, so vagos ou genricos demais e desnecessrios para a soluo do problema; Atentar na especificao para os nomes que indicam atores que interagem com o usurio; Decida baseando-se em seu conhecimento do domnio, na especificao de requisitos ou em um especialista do domnio os dados que devem ser contidos em cada classe.
131
IDENTIFICANDO OS ATRIBUTOS
Se um subconjunto de atributos de uma classe formam um grupo coerente pode ser interessante criar uma outra classe para estes atributos.
IDENTIFICANDO O COMPORTAMENTO
Ler a especificao de requisitos; Extrair verbos: simples ou compostos; Eliminar os que so: redundantes, representam instncias, so vagos ou genricos demais ou desnecessrios para a soluo do problema; Colocar os comportamentos extrados nas classes identificadas.
IDENTIFICANDO GENERALIZAES
Existem duas formas para identificao de generalizao: o BOTTOM-UP: agrupa classes simulares criando uma superclasse; o TOP-DOWN: procurar por classes mais genricas para ento, se preciso, especializ-las.
IDENTIFICANDO ASSOCIAO
Comear com as classes considerando mais centrais e importantes; Decidir quais os relacionamentos destas com as outras; Uma associao existe se uma classe: possui, controla, est conectada para, est relacionada para, parte de, tem como parte, membro de e tem como membro; Alguma outra classe no modelo; Evite adicionar muitas associaes a uma classe. O acoplamento fica muito alto; Especifique a multiplicidade.
EXEMPLO ESTUDO DE CASO: LOCADORA DE VECULOS
Vamos fazer juntos ????
Este estudo est completo na pgina 89. Alugar Carro: cliente deve solicitar ao funcionrio o aluguel do carro. O sistema verifica se o carro solicitado pelo cliente est disponvel. Caso esteja, o processo de locao concludo e o carro passa a estar
132
indisponvel. A data de aluguel deve ser guardada para calculo do valor do aluguel na devoluo. Dar Baixa: cliente faz devoluo do carro para o funcionrio e solicita nota fiscal (recibo) com a quilometragem percorrida e o valor do aluguel. O funcionrio coloca o status do carro novamente como disponvel, solicita ao sistema para calcular o valor a ser pago e emite o recibo para o cliente. Cadastrar Cliente: cliente solicita ao funcionrio que o cadastre na locadora. O funcionrio recebe os dados e cadastra-o. Cadastrar Carro: funcionrio cadastra o carro adquirido. PASSOS PARA IDENTIFICAR AS CLASSES (HEURSTICA) 1. Descrio dos requisitos; 2. Extrair os substantivos; 3. Tentativa de classes; 4. Eliminar classes estranhas; 5. Classes identificadas.
EXERCCIOS
1) Em relao aos relacionamentos abaixo responda: a) Qual a representao mais correta a primeira ou segunda relao? Por qu?
2)Qual a diferena de intepretao entre as duas representaes? Qual seria mais indicada para um tribunal regional eleitoral?
133
3) Com base nos requisitos funcionais abaixo, defina um diagrama de classes:
RF01 - O software dever permitir que o gerente cadastre sales de festas. RF02 - O software dever permitir que o gerente cadastre profissionais. RF03 - O software dever permitir que o gerente realize o cadastramento de servios utilizados em uma festa de casamento, como buffet, carros utilizados. RF04 - O software dever permitir que o cliente realize o cadastramento da lista de convidados. RF05 O software dever permitir que o cliente realize o cadastramento das lojas de presentes. RF06 - O software dever permitir que o cliente elabore da configurao da festa pelo cliente. RF07 - O software dever permitir a gerao do oramento para o cliente. RF08 - O software dever permitir que o gerente realize a impresso de relatrios de festas. RF09 - O software dever permitir que o cliente cadastre a lista de presentes. RF10 - O software dever permitir que o gerente realize o cadastramento de usurios. RF11 - O software dever permitir a autenticao dos usurios
4) Com base no estudo de caso abaixo faa o diagrama de classes: Os funcionrios da transportadora devem cadastrar clientes, filiais, veculos, funcionrios, tipos de veculos, cidades, distancias, categorias de frete e fretes de clientes. Clientes so pessoas fsicas e possuem: nome, endereo e telefone. Filiais tm: nome, endereo, telefone, funcionrio responsvel e vrios veculos. Veculos devem possuir placa e um tipo de veiculo, alm de ser necessariamente de uma filial. Funcionrios so identificados pela matricula e tm ainda: nome, endereo, telefone e dependentes (nome e data de nascimento), alm de estar associado, obrigatoriamente a uma filial. Tipo de veculo apresenta uma descrio (caminho, moto, etc) e o peso mximo que Pode transportar alm de estar associado a veculos. Cidades contm nome e estado a que pertence, representando as cidades abrangidas pela empresa. Distncia envolve as cidades origem
134
e destino e para cada par de cidades atendidas, deve haver a distncia em quilmetros entre elas.
Categoria do frete deve conter descrio e um percentual, que deve incidir sobre o valor do frete onde, por exemplo, entregas rpidas tm aumento de 10% entregas super-rpidas tem aumento de 30% e entrega normal no tem acrscimo no valor. Cada frete tem um cdigo, um cliente, o veiculo deve efetuar o frete, cidade origem e destino, funcionrio responsvel e itens a serem transportados, no podendo haver um frete sem os dados citados. Ainda precisa ter o valor a ser calculado atravs da distncia percorrida entre as cidades: origem e destino e da categoria do frete. Para isso, deve existir um valor padro para o km rodado. Um item de transporte cada objeto a ser transportado num frete e deve possuir apenas uma descrio e seu peso. Por fim, temos que o sistema ainda deve emitir Nota Fiscal com todas as informaes de um determinado frete, logo aps o seu cadastramento.
4) Com base nos requisitos funcionais abaixo, faa o diagrama de caso de uso e o diagrama de classe: RF01. O sistema deve permitir secretaria cadastrar cursos contendo cdigo, descrio e professor coordenador. RF02. O sistema deve permitir secretaria cadastrar disciplinas de cursos contendo cdigo, descrio, carga horria, ementa, bibliografia e prrequisitos; RF03. O sistema deve permitir secretaria cadastrar alunos contendo matrcula, o nome, endereo, telefone e curso para o qual aprovado. RF04. O sistema deve permitir ao departamento de recursos humanos (RH) cadastrar professores, contendo nome, endereo, telefone e titulao mxima (graduao, especializao, mestrado, doutorado) e cursos que esteja vinculado. RF05. O sistema deve permitir secretaria abrir turmas de disciplinas e cursos, informando ano e semestre, dias da semana e horrios de realizao. RF06. O sistema deve permitir aos coordenadores de curso alocar professores a determinadas turmas. RF07. O sistema deve permitir a secretaria matricular alunos em turmas. RF08. O sistema deve permitir aos professores lanar avaliaes (duas notas parciais, nota da prova final e frequncia) dos alunos das turmas que estejam sob sua responsabilidade. RF09. O sistema deve permitir aos alunos consultar suas avaliaes. RF10. O sistema deve permitir secretaria emitir dirios de classes de turmas. RF11. O sistema deve permitir secretaria emitir histricos escolares de alunos. RF12. O sistema deve efetuar o clculo da aprovao de alunos em turmas, sendo que para ser aprovado, deve-se ter frequncia mnima de 75%. Alm disso, para aprovao sem prova final, a mdia das notas
135
parciais deve ser maior ou igual a 70. Para reprovao direta esta mdia deve ser menor que 30. Mdias entre 30 (inclusive) e 70 (exclusive) colocam o aluno em prova final. Se mdia da prova final com a mdia anterior for menor que 50, o aluno est reprovado, caso contrrio, aprovado. RF09. O sistema deve controlar a situao de um aluno, podendo estar matriculado, trancado, formado, ou ter abandonado o curso. 5) Faa o diagrama de classes do estudo de caso abaixo: Uma locadora de veculos deseja um sistema para facilitar o atendimento a seus clientes. O processo de aluguel de carros atual confuso e est gerando insatisfao entre os clientes. A locadora formada basicamente pelos seus clientes e carros para aluguel. Os carros esto divididos em diversos tipos: popular, luxo e utilitrio. As informaes importantes sobre os carros a serem armazenadas so: cdigo (placa do carro), tipo, modelo, ano, cor, chassis, quilometragem e valor do aluguel (diria). Os funcionrios sero responsveis pe3lo cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o aluguel de um carro para o cliente e dar baixa no aluguel. Existem clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto e um valor de quilometragem extra para seus aluguis. Qualquer cliente identificado por RG, nome, CPF, telefone, endereo, contato. 6) Faa o diagrama de controle de respostas das questes de uma prova: A Instituio de Ensino UniLinense deseja controlar todas as respostas referentes s questes, de uma determinada prova, aplicadas aos alunos da instituio. Sabe-se que uma prova tem que ter obrigatoriamente uma questo e pode ter vrias, as questes por sua vez fazem parte da prova e s podem estar vinculada a uma determinada prova. Cada prova tem somente um professor responsvel e um mesmo professor pode se responsabilizar por vrias provas. Os alunos a serem controlados se subdividem em alunos regulares e alunos dependentes. Ambos alunos respondem vrias questes e uma questo aplicada a vrios alunos. Para cada questo aplicada a um aluno deseja-se armazenar uma resposta. 7) Faa o diagrama de controle de venda de veculos: O objetivo principal desse sistema controlar as vendas de veculos, direto da fbrica, realizadas pelos Concessionrios aos clientes. Sabe-se que um Concessionrio pode vender vrios Veculos diretamente da fbrica e que os veculos podem ser vendidos em vrios concessionrios (por exemplo, um Gol pode ser vendido por vrios concessionrios). Toda Venda destinada a um e somente um Cliente e todo cliente pode comprar vrios veculos.
136
DIAGRAMA DE OBJETOS Representa a instncia (uma ocorrncia) do diagrama de classes. Para cada classe temos um objeto (instncia) em um determinado tempo. Podemos enxergar dados reais facilitando a compreenso e a modelagem de estrutura complexas de dados. Auxilia ainda na identificao de problemas na execuo de uma aplicao. A representao grfica semelhante classe, um retngulo com duas partes. Na primeira exibido o nome do objeto sublinhado (pode ser omitido desde que mantenha os dois pontos e o nome da classe e na segunda os seus atributos um em cada linha com seus respectivos valores:
Nome do Objeto: nome do objeto : nome da classe. Exemplo:
func1: Funcionrio : Funcionrio Funcionrio1
Nome do Atributo: nome do atributo : tipo = valor. Exemplo:

Produto1:Produto descrio= Sala cor = azul tamanho = 40 preo = 15,00
O relacionamento entre os objetos feito atravs de links que a instncia de uma associao. Um nome de papel pode ser mostrado no final de cada link. Multiplicidade no pode ser exibida para links, pois esto instanciadas. Podem ser exibidos os adornos de agregao, composio, navegao e qualificadores, notas, restries e pacotes. Exemplo:
Diagrama de Classes
Funcionrio nome : string cargo : string salrio : real 1..* 1
gerencia trabalha
Projeto 1 0..1 descrio:string inicio: date fim : date custo : real
FuncionrioContratado carteiraProfissional: string dataAdmisso:date
FuncionrioTerceirizado
inicioContrato:date terminoContrato:date prestadoraServicos:string taxaAdministracao:real
137
Diagrama de Objetos
P1:Projeto descrio= Desenvolvimento do Sistema DKA inicio = 01/12/2006 fim = 02/02/2007 custo = 6000,00
gerente
F1:FuncionarioContratado nome = Porsidnio Souza cargo = Analista de Sistemas salrio = 3500,00 carteiraProfissional = 02468-0 dataAdmissao = 01/10/2000 F1:FuncionarioContratado nome = Firminiano Neves cargo = Analista de Sistemas salrio = 3800,00 carteiraProfissional = 01357-9 dataAdmissao = 15/01/1995
F1:FuncionarioTerceirizado nome = Silvio Abreu cargo = Analista de Sistemas salrio = 2500,00 inicioContrato = 02/12/2006 fimContrato = 26/02/2007 prestadoraServio = SISTEM taxaAdministrativa = 6
Figura 75 Modelo de Diagrama de Objetos
EXERCCIOS
01. Desenhe um diagrama de objetos para o diagrama de classes abaixo:
138
02. Suponha um objeto Matemtica de uma classe Disciplina. Escreva as formas nas quais podemos representar esse objeto. 03. Marque dentre os elementos abaixo quais podem ser colocamos em um diagrama de objetos: ( ) tipo dos atributos ( ) valor dos atributos ( ) nome de papel ( ) nome de associao ( ) multiplicidade ( ) agregao ( ) composio ( ) navegao ( ) notas ( ) restries 04. Em UML, um diagrama de objetos Tcnico/Programador de Computador): (Concurso Serpro-2001-
a) a representao de um conjunto de classes. b) a representao do relacionamento entre interfaces. c) representa retratos estticos de instncias de itens encontrados em diagramas de classes. d) abrange a viso dinmica de um sistema. e) mostra a configurao dos ns de processamento em tempo de execuo.
TAREFA 07 DIAGRAMA DE CLASSES E DIAGRAMA DE OBJETOS (1,0)
Para este sistema, o gerente deve cadastrar agncias, clientes e abrir e fechar contas bancrias. Um cliente possui nome, endereo e telefone. Um cliente pode abrir vrias contas e uma conta pode ser de vrios clientes, para o caso de contas conjuntas. Contas so de uma determinada agncia (que possui nome e nmero), alm de poderem estar vinculadas a uma conta de investimento, que nada mais que outra conta bancria. Contas ainda devem possuir um nmero (formado pelo nmero da agncia e pelo nmero da prpria conta) e saldo disponvel, podendo ser corrente normal, corrente especial e poupana. Para contas poupana, devem-se armazenar os dias de vencimento e, para contas corrente especiais, informar o limite de crdito. Contas ainda possuem movimentaes de saque e depsito, que devem ter data e valor, alm do tipo de movimento, que pode ser dbito ou crdito. Clientes ainda podem solicitar cartes de contas bancrias, que devem ter nmero, validade e senha para cada cliente, alm de tales de cheques para contas correntes, que devem armazenar o nmero inicial e final das folhas do talo. O sistema ainda deve permitir aos clientes consultar saldos e extratos.
139
DIAGRAMA DE SEQUENCIAS Vamos imaginar a seguinte situao:

Preciso da lista de vendedores com o total de vendas.
Relatrio de Comisses
Resposta: 100 Afonso 15.000,00 215 Andra 30.000,00 A quem pertence a matrcula 100?
RESPOSTA: 100 - Afonso
Figura 87 Exemplo de situao do cotidiano
Um diagrama de sequncias exibe a troca de mensagens entre os objetos na ordem em que elas acontecem, no mostrando os detalhes do que precisa para isto acontecer. A representao grfica feita assim: o OBJETOS: retngulo alinhado no topo do diagrama partindo dele uma linha vertical tracejada chamada LINHA DE VIDA desenhada at o fim do diagrama. Exemplo:
LivroA:Livro
Figura 88 Exemplo de Objeto
o CRIAO DE UM OBJETO: a seta que representa essa mensagem desenhada de forma a apontar sua cabea para o smbolo do objeto. Pode conter o esteritipo <<create>>.
:Funcionrio
novo()
:ContraCheque
Figura 89 Exemplo de criao de objetos
o DESTRUIO DE UM OBJETO: a seta que representa essa mensagem direcionada a um grande X colocado no final da linha de vida. Pode conter o esteritipo <<destroy>>.
140
:Funcionrio
:Benefcio
excluirBenefcio()
Figura 90 Exemplo de destruio de objeto
o MENSAGENS: so enviadas de um objeto a outro, por meios das setas que partem de uma linha de vida a outra, identificadas por um nome de operao. Estas mensagens podem ser numeradas. Ativao: quando um mtodo de um objeto est sendo executado. Exemplo:
:Curso
obterNome(matrcula) Ativao
:Aluno
Mensagem de retorno Mensagem
Figura 91 Exemplo de troca de mensagens
A iterao representa o envio da mesma mensagem diversas vezes para o mesmo objeto, sendo comum o tratamento de colees de objetos. A representao feita dentro de colchetes, incluindo ates do colchete inicial, o asterisco (*). Exemplo: *[para cada aluno da turma] CalcularMedia() Chamada recursiva ou auto-chamada quando um objeto passa mensagem para ele prprio. Exemplo:
Iterao
cursoX:Curso Coordenador disc1:Disciplina
obterGrade() Grade
*[para cada disciplina] obterInfDisciplina(cursoX)
[se a Disciplina tem obterPreRequisito(disc1)
PreReq]
condio: s se for verdadeira
auto-chamada
Figura 92 Exemplo de iterao
O diagrama de sequncias pode ser desenhado dentro de um frame (verso 2.0) que identificar o diagrama. Use o prefixo sd(sequence diagram) para indicar o tipo de interao.
141
sd DiagramaSeq1
objeto1
objeto2
mensagem
Figura 93 Exemplo de diagrama sequncia
O diagrama de sequncias frequentemente usado para representar cenrios de casos de uso. Exemplo: CASO DE USO REGISTRAR VENDAS: Diagrama de Classes:
Vendedor matrcula : string nome : string dataAdmissao : date salarioBruto : real /salarioLiquido : real percentualComissao : real obterListaVendedoresAtivos() calcularSalarioLiquido(dataRef) : real Venda numero : integer data : date valor : real grava()
0..*
Figura 94 Exemplo de Diagrama de Classes
Caso de Uso: Registrar vendas Objetivo: permite cadastrar as vendas efetuadas pelos vendedores. Ator: assistente de gerncia Cenrio Principal 1. O sistema prepara uma lista dos vendedores cadastrados na loja. 2. O usurio informa o nmero da venda. 3. O usurio informa ainda: a data da venda e o valor da venda. 4. O usurio seleciona o vendedor que efetuou a venda, a partir da lista j montada pelo sistema. 5. O sistema efetua a gravao da venda. Cenrio Alternativo: Venda j cadastrada. 2. Se o nmero da venda j estiver cadastrado, informar ao usurio, mostrar as informaes da venda na tela e entrar em modo de alterao dos dados.
142
Diagrama de Sequncias:
:TelaCadastro :Venda :Vendedor
Assistente de Gerncia
obterListaVendedoresAtivos() numero_venda busca(nmero_venda)
data, valor seleo do vendedor grava()
Figura 95 Exemplo de diagrama de sequncia
EXEMPLO: ESTUDO DE CASO: SISTEMA GESTOR DE VOTAO INTERNA
Vamos fazer juntos???
143
Figura 96 Estudo de caso diagrama de sequncia
144
Com base nas especificaes de caso de uso abaixo, vamos criar o diagrama de sequncias:
Listagem 1. UC Manter Eleio Descrio: Este caso de uso tem por objetivo manter o cadastro de eleies, permitindo a incluso, alterao, excluso ou consulta de eleies. Atores: Coordenadoria de Eleies Cenrio principal: 1. O sistema prepara uma lista de eleies cadastradas, exibindo para cada uma: objetivo, data da eleio, status da apurao. 1.1. O usurio pode pesquisar uma eleio, informando os seguintes critrios: - objetivo ou - perodo inicial e final em que ocorreu a eleio 2. O sistema habilita as seguintes opes para o usurio: 2.1. Incluso de eleio 2.2. Alterao de eleio 2.2.1. Para alterao, o usurio deve pr-selecionar a eleio 2.3. Excluso de eleio 2.3.1. Para excluso, o usurio deve pr-selecionar a eleio 3. Para a opo de Incluso ou Alterao: 3.1. O usurio informa/edita: 3.1.1. objetivo da eleio 3.1.2. data da eleio 4. Para a opo de Excluso: 4.1. O sistema exibe os dados do item 3.1 desabilitados para edio. 4.2. O usurio confirma a excluso da eleio. 5. O usurio confirma a operao. 5.1. O sistema atualiza o cadastro de eleies. Cenrios alternativos: Pesquisa de eleio 1.a. A pesquisa de eleio deve desconsiderar caixa alta e baixa, acentuao e realizar a localizao dos trechos em qualquer ordem que os mesmos apaream no cadastro. 1.b. A pesquisa de perodo deve ser feita considerando os perodos inicial e final, inclusive; podendo ser informado apenas um dos perodos. Permisso de Alterao da eleio 2.a. Se j houver data que indique o incio da votao, a eleio no poder ser alterada. Exibir mensagem de erro e retornar ao passo 1. Permisso de Excluso da eleio 2.b. Se j houver data que indique o incio da votao, a eleio no poder ser excluda. Exibir mensagem de erro e retornar ao passo 1. Validao da data de eleio 3.a. Se o usurio informar uma data de eleio que no seja futura, exibir mensagem de erro e retornar ao passo 3. 3.a. Se o usurio informar uma data de eleio futura que j esteja cadastrada para outra eleio, exibir mensagem de erro informando a qual eleio a data j est cadastrada e retornar ao passo 3.
145
Listagem 2. UC Manter Candidatos Descrio: Este caso de uso tem por objetivo manter o cadastro de candidatos, permitindo a incluso, alterao, excluso ou consulta de candidatos. Atores: Coordenadoria de Eleies Pr-condio: existir cadastro prvio de eleies. Cenrio principal: 1. O sistema prepara uma lista de eleies cadastradas, que ainda no tenham ocorrido a votao (incio de votao em branco), exibindo para cada uma: objetivo, data da eleio, lista de candidatos cadastrados. Para cada candidato cadastrado, exibir: nmero e nome. 2. O usurio seleciona uma eleio. 3. O sistema habilita as seguintes opes para o usurio: 3.1. Incluso de candidato 3.2. Alterao de candidato 3.2.1. Para alterao, o usurio deve pr-selecionar tambm o candidato. 3.3. Excluso de candidato 3.3.1. Para excluso, o usurio deve pr-selecionar tambm o candidato. 4. Para a opo de Incluso ou Alterao: 4.1. O usurio informa/edita: 4.1.1. nmero do candidato 4.1.2. nome do candidato 4.1.3. foto do candidato 5. Para a opo de Excluso: 5.1. O sistema exibe os dados do item 4.1 desabilitados para edio. 5.2. O usurio confirma a excluso da eleio. 6. O usurio confirma a operao. 6.1. O sistema atualiza o cadastro de candidatos. Cenrios alternativos: Validao do nmero do candidato 4.a. Se o usurio informar um nmero de candidato j cadastrado na eleio escolhida, exibir mensagem de erro informando a que candidato est associado e retornar ao passo 4. Listagem 3. UC Iniciar Votao Descrio: Este caso de uso tem por objetivo dar incio votao de uma eleio. Atores: Mesrio Pr-condio: existir uma eleio cuja data igual data vigente e que ainda no tenha tido a votao iniciada. Cenrio principal: 1. O sistema busca a eleio cuja data igual data vigente. 2. O usurio confirma o incio da votao. 2.1. O sistema atualiza o cadastro de eleies, registrando a data e hora atual no campo incio da votao. Cenrios alternativos: No se aplica
146
Listagem 4. UC Habilitar Eleitor Descrio: Este caso de uso tem por objetivo validar o eleitor e liberar a urna para votao. Atores: Mesrio Pr-condio: existir uma eleio cuja data igual data vigente e cujo incio da votao j tenha sido preenchido. Cenrio principal: 1. O usurio informa a matrcula do eleitor. 1.1. O sistema busca o eleitor, exibindo o seu nome. 2. O usurio libera a urna para votao. Cenrios alternativos: Validao da matrcula do eleitor 1.a. Se o usurio informar um nmero de matrcula que no exista no cadastro, exibir mensagem de erro e retornar ao passo 1. 1.b. Se o eleitor j tiver votado na eleio corrente, exibir mensagem de erro e retornar ao passo 1. Permisso para liberar a urna 2.a. Se o eleitor anterior ainda no tiver finalizado a votao, exibir mensagem de erro e retornar ao passo 1. Listagem 5. UC Votar Descrio: Este caso de uso tem por objetivo permitir que o eleitor registre o seu voto. Atores: Eleitor Pr-condio: a urna estar liberada para votao. Receber a identificao da eleio e do eleitor habilitado para votao. Cenrio principal: 1. O sistema busca e exibe todos os candidatos associados eleio identificada. 1.1. Para cada candidato, o sistema exibe: nmero do candidato, nome do candidato e foto do candidato. 2. O sistema habilita as opes Nulo e Branco. 3. O usurio seleciona um dos candidatos ou uma das opes Nulo ou Branco. 4. O usurio confirma a votao. 5. O sistema atualiza o cadastro de votao. 5.1. O sistema registra que o eleitor identificado j efetuou seu voto, sem associ-lo ao voto. 5.2. O sistema computa 1 voto para o candidato selecionado ou para as opes Nulo ou Branco. 5.3. O sistema libera a urna. Cenrios alternativos: Permisso de correo da votao 4.a. O usurio pode solicitar a correo do seu voto, no momento de confirmar a votao. Nesse caso, o sistema deve retornar ao passo 3.
147
EXERCCIOS
01. No diagrama de sequncias, o que representa a dimenso vertical? 02. No diagrama de sequncias, como chamada a linha que parte da representao do objeto? 03. No diagrama de sequncias, o que representa um grande X no final da linha de vida? 04. Como as mensagens so enviadas num diagrama de sequncias? 05. O que representa a ativao num diagrama de sequncias? 06. Indique quais elementos abaixo no aparecem em um diagrama de sequncias: objetos, mensagens, iterao, ns, condies, relacionamento de agregao, ator e estado. 07. Faa o diagrama de sequncia para abertura de conta comum: Inicialmente o Cliente solicita ao Funcionrio a abertura de uma conta, ento o Banco faz uma consulta do cliente pelo seu CPF (Mtodo), na classe Fsica, se o cliente se encontra cadastrado, a consulta retorna com os Dados do Cliente, se no o cadastro do cliente dever ser realizado. No cadastro do cliente (Fsica), dever conter um mtodo para validar o CPF, evitando assim, o cadastro de clientes com CPF inexistente. Aps o cadastro do cliente o funcionrio receber uma resposta do Sistema informando que o cliente est atualizado, da mesma forma que o funcionrio comunica ao cliente que seu cadastro foi aprovado. Ao receber a resposta do funcionrio, o cliente deve informar valor do depsito a ser feito e sua senha. Essa mensagem ir disparar um mtodo para abertura de uma nova conta comum, que por sua vez, ir registrar esse histrico. O Cliente dever ser informado sobre o status de sua conta, ou seja, que a abertura da conta foi concluda. 08. Faa o digrama de sequncia para o encerramento de uma conta: Neste caso o Cliente solicita ao Funcionrio o encerramento de sua conta, o Funcionrio por sua vez deve verificar a conta, neste momento, necessria a senha do cliente e em seguida se existe Saldo. Se o Funcionrio receber a resposta de que o saldo positivo, deve haver o saque do valor.
148
Assim como qualquer movimentao, havendo o saque deve-se registrar o histrico referente ao Saque. Aps a confirmao do saque, deve ser disparado o mtodo de encerramento de Conta. Em seguida avisar ao cliente. 09. Diagrama referente a solicitao de Extrato de uma conta comum atravs de um caixa eletrnico. 10. Com base na especificao de caso de uso abaixo, criar um diagrama de sequncias:
Criar Matrcula (CSU001) Sumrio: O aluno solicita do sistema, sua matrcula em uma determinada disciplina. O sistema verifica se o aluno possui os pr-requisitos necessrios e em caso afirmativo registra a matrcula. Ator Primrio: Aluno Pr-condies: O aluno est logado no sistema. Fluxo Principal 1. O aluno solicita o formulrio (tela) de matrcula. 2. O sistema solicita um cdigo de disciplina. 3. O aluno fornece um cdigo de disciplina. 4. O sistema exibe o nome completo (descrio) da disciplina. 5. O sistema verifica a grade do curso para conhecer os pr-requisitos para aquela disciplina. 6. O sistema verifica o histrico do aluno para determinar se ele possui os prrequisitos necessrios. 7. Se sim, o sistema registra a nova matrcula, emite uma mensagem de aceitao. 8. O sistema oferece alternativa de mais matrculas ou de encerramento. 10. O aluno seleciona encerramento e o caso de uso se encerra. Fluxo Alternativo: O aluno seleciona mais matrculas e o caso de uso retorna ao passo 2 (pode acontecer no passo 8). Fluxo de exceo: O aluno no possui os pr-requisitos (pode acontecer no passo 6). 1. O sistema reporta essa situao e retorna ao passo 8. Ps-condies: As matrculas efetuadas tornam-se disponveis aos coordenadores de curso para avaliao. Regras de Negcio: Um aluno no pode se matricular em disciplinas que no tenha cursado seus pr-requisitos.
TAREFA 8 DIAGRAMA DE SEQUENCIAS (1,0) Uma locadora de veculos deseja um sistema para facilitar o atendimento a seus clientes. O processo de aluguel de carros atual confuso e est gerando insatisfao entre os clientes. A locadora formada basicamente pelos seus clientes e carros para aluguel. Os carros esto divididos em diversos tipos: popular, luxo e utilitrio. As informaes importantes sobre os carros a serem armazenadas so:
149
cdigo (placa do carro), tipo, modelo, ano, cor, chassis, quilometragem e valor do aluguel (diria). Os funcionrios sero responsveis pe3lo cadastro dos clientes e dos carros adquiridos pela locadora, por efetuar o aluguel de um carro para o cliente e dar baixa no aluguel. Existem clientes especiais e clientes comuns. Os especiais possuem uma taxa de desconto e um valor de quilometragem extra para seus aluguis. Qualquer cliente identificado por RG, nome, CPF, telefone, endereo, contato.
a) Cadastrar cliente; b) Efetuar aluguel.
150
ANEXO - SOLUES PARA PROBLEMAS NA ENGENHARIA DE REQUISITOS
Figura 64 Requisitos
Recordando, engenharia de requisitos, descreve o conjunto de atividades para a produo de requisitos e gerencia de requisitos. H dois grupos de atividades: PRODUO DE REQUISITOS o LEVANTAMENTO: atividade que se relaciona com a obteno dos requisitos e para isto temos analistas e engenheiros que trabalham junto com o usurio para levantar as limitaes de hardware, o funcionamento do sistema, desempenho do sistema, e outras informaes necessrias para dar continuidade da produo do software. H varias atividades como entrevistas, JAD, BRAINTORMING, WORKSHOP DE REQUISITOS, USO DE PROTOTIPOS PARA APOIAR O REQUISITO. o Registro: uma vez identificados precisam ser documentados para servir de base para o resto do desenvolvimento. Ou seja especificao, descrio dos requisitos levantamentos junto com o cliente neste contexto. Administrar o grande volume de informaes levantados um problema, preciso identificar o nvel de detalhe correto para suprir as necessidades de diferentes atividades no ciclo de vida do projeto. o VALIDAO: comprometimento do cliente de acordo com os requisitos levantados; aceite do cliente sobre determinado artefato. Ou seja identificamos o que o software atende.
151
o VERIFICAO: examina a especificao do software assegurando que todos os requisitos foram definidos, sem omisso, ambiguidade, detectando e corrigindo defeitos na fase de definio dos requisitos, fornecendo uma melhor qualidade nos requisitos que est sendo elaborada. GERENCIA DE REQUISITOS Os requisitos so volteis e diversos fatores contribuem para isto (mudana externa, por exemplo: legislao, mercado, posicionamento estratgico da empresa, erros ocorridos no processo de requisitos). E isto traz a necessidade de alterao nos requisitos e esta alterao precisa ser ordenada para que no haja perda de custo e prazo. CONTROLE DE MUDANA: como so volteis, sofrem mudanas e para conduzir a mudana necessrio o preparo e planejamento. Uma forma para organizar definir um processo mais formal para ter controle sobre a mudana e sobre isto h uma analise de impacto para achar em que momento a mudana pode ser atendida e o impacto desta mudana no software e esta mudana pode ser aprovada ou rejeitada que dever apresentar os motivos da rejeio. GERENCIA DE CONFIGURAO: Assunto amplo. Garantir que estamos trabalhando com as verses corretas dos diferentes itens de configurao que esta sendo criado no desenvolvimento e a especificao de requisitos um destes documentos. Para garantir que a equipe esteja trabalhando na ultima verso. RASTREABILIDADE: permite identificar ou entender como os diferentes conceitos ou elementos esto sendo tratados nas diferentes fases do desenvolvimento e devemos garantir que as transformaes estejam correndo e de forma correta. Podemos verificar a analise de impacto de uma alterao. GERENCIAMENTO DA QUALIDADE DE REQUISITOS: garante que as atividades do produto produzido esto sendo seguidas corretamente.
ELICITAO DE REQUISITOS
Por ser onde identificamos os requisitos, ou seja a ideia inicial do sistema, necessrio a compreenso do problema.
PROBLEMAS
Escopo; Entendimento; Volatilidade.
DESAFIOS
Falta de conhecimento do usurio das suas reais necessidades;
152
Falta de conhecimento do desenvolvedor do domnio do problema; Domnio do processo de elicitao de requisitos pelos desenvolvedores; Comunicao inadequada entre os desenvolvedores e usurios; Dificuldade do usurio tomar decises; Problemas de comportamento; Questes tcnicas.
PROBLEMA: ENVOLVER INTERESSADOS INAPROPRIADOS

SOLUO
Identificar interessados apropriados; Verificar constantemente a necessidade de participao de outros usurios; Utilizar tcnicas de apoio como workshop e requisitos JAD.
PROBLEMA: POLTICA NA ORGANIZAO

SOLUO
Ciclo de vida iterativo incremental; Obteno explcita do comprometimento com os requisitos; Anlise de impacto.
PROBLEMA: A LINGUAGEM NATURAL E A ABSTRAO DOS REQUISITOS DE ALTO NVEL DIFICULTAM O MAPEAMENTO DAS CAPACIDADES MACRO EM REQUISITOS FUNCIONAIS E NO FUNCIONAIS.
SOLUO
Necessrio aumentar a interao entre o engenheiro de requisitos e o usurio; Iniciar as entrevistas com o cliente com perguntas abertas; Possibilidade de empregar tcnicas de elicitao complementares como etnografia (observao do ambiente operacional do cliente).
PROBLEMA: SEPARAR PREMISSAS RELACIONADAS AO DESENVOLVIMENTO DO SISTEMA DOS SEUS REQUISITOS

SOLUO
Estabelecer templates e diretrizes que orientem a separao adequada do contedo do documento de requisitos; Fazer uso de revises tcnicas para assegurar a qualidade dos documentos produzidos.
153
CASOS DE USO
Figura 65 Exemplo de Especificao de Caso de Uso
PROBLEMA: DIFICULDADE NA DESCRIO DE REQUISITOS FUNCIONAIS E NOFUNCIONAIS.

SOLUO
Utilizao de revises tcnicas formais; Treinamentos podem ser conduzidos encontrados nas inspees.
focando
nos
problemas
PROBLEMA: COMPLEXIDADE NO DETALHAMENTO DOS CASOS DE USO PARA DEFINIO DA SOLUO

SOLUO
Manter os passos simplificados, contudo assegurando que todas as informaes necessrias (informaes recebidas, opes disponibilizadas, informaes fornecidas e aes realizadas) estejam descritas; A separao do caso de uso em diversos casos de uso relacionados atravs de incluses (includes) e extenses (extends).
154
PROBLEMA: DETALHAMENTO TCNICO ESPECIFICAO FUNCIONAL DO SISTEMA.

SOLUO
DESNECESSRIO
DURANTE
Utilizao de revises tcnicas formais; Treinamento pode ser fornecido para esclarecer o contedo apropriado da especificao funcional.
GERNCIA DE REQUISITOS
PROBLEMA: DIFICULDADES DE ESTABELECER UMA ATUALIZAO E REUTILIZAO DE CASOS DE USO
SOLUO
ESTRATGIA
PARA
Criar uma biblioteca de casos de uso estruturada de acordo a diviso funcional (mdulos) dos sistemas da organizao; Tratar cada caso de uso como um item de configurao.
PROBLEMA: REPRESENTAR A ATUALIZAO DE CASOS DE USO

SOLUO
Preenchimento de um histrico de verses dos casos de uso, informando a data, as alteraes realizadas e o responsvel pelas alteraes. Tratar cada caso de uso como um item de configurao e inserir no processo de gerncia de configurao.
Figura 63 Exemplo de histrico de verses
155
PROBLEMA: DIFICULDADE DE INTEGRAO DAS PRTICAS DE GERNCIA DE REQUISITOS COM GERNCIA DE CONFIGURAO.
SOLUO
Definir um processo de gerncia de configurao padro. A evoluo dos requisitos deve estar alinhada com a evoluo das baselines de requisitos; Os requisitos acordados em uma baseline somente podem ser alterados atravs de solicitaes de mudana.
PROBLEMA: TRABALHAR COM O BACKLOG DE CASOS DE USO INEXISTENTES PARA SISTEMAS EM MANUTENO.
SOLUO
Considerar uma abordagem evolutiva para a criao dos casos de uso, onde inicialmente a documentao consiste de um resumo do caso de uso (contendo, por exemplo, apenas o fluxo principal).
E MANUTENO DA
PROBLEMA: DIFICULDADE DE IMPLANTAO RASTREABILIDADE DOS REQUISITOS.

SOLUO
Estabelecer um processo de desenvolvimento que integre as atividades relacionadas ao estabelecimento da rastreabilidade com as prprias atividades de engenharia do software; Algumas ferramentas CASE permitem o estabelecimento dos links de rastreabilidade no momento da criao e atualizao dos artefatos.
ESTABELECIMENTO RETROATIVO DE
PROBLEMA: DIFICULDADES DE RASTREABILIDADE DOS REQUISITOS

SOLUO
O estabelecimento retroativo de rastreabilidade pode ser extremamente custoso e uma anlise de custo/benefcio deve ser considerada antes de realizar esta tarefa.
BOAS FRIAS!!!! Obrigada por tudo e me desculpe por alguma coisa.

Apostila ES2 2sem2013

Transféré par

Informations du document

Description originale:

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Apostila ES2 2sem2013

Transféré par

Droits d'auteur :

Formats disponibles

Faculdade de ecnologia de Praia Grande

PROBLEMA: DIFICULDADES DE ESTABELECIMENTO RETROATIVO DE RASTREABILIDADE DOS REQUISITOS............................................................................................................................................... 155

TAREFA 01 - REVISO DE ENGENHARIA DE SOFTWARE I (VALOR : 0,5)

1 BIMESTRE DESENVOLVIMENTO DE SOFTWARE

Figura 1 Processo de Engenharia de Requisitos (Fonte: adaptado de (KOTONYA;SOMMERVILLE, 1998))

Figura 2 Levantamento de Requisitos (Fonte: Web)

Figura 3 Requisitos (extrado da WEB)

IMPORTNCIA DOS REQUISITOS

Figura 5 Pesquisa de projetos

As causas podem ser:

Figura 6 Tipos de Fatores

QUALIDADE DOS REQUISITOS

EXEMPLO DE REQUISITOS FUNCIONAIS

EXEMPLO DE REQUISITOS DE DOMINIO

Figura 7 Etapas da Engenharia de Requisitos (Fonte: extrado da Web)

OBJETIVOS DA ENGENHARIA DE REQUISITOS

TAREFA 02 - QUESTES DE REQUISITOS (0,5)

Figura 8 Etapas de uma Elicitao de Requisitos (Fonte: extrado da Web)

Nesta etapa um dos artefatos2 principais a criao do documento viso.

Figura 9 Esquema para criao do documento viso (Fonte: extrado da Web)

Figura 10 Erros de Requisitos (Fonte: extrado da Web)

OBJETIVOS DA ELICITAO DE REQUISITOS

PASSOS PARA A ELICITAO DE REQUISITOS

QUESTES QUE PRECISAM SER RESPONDIDAS

Figura 11 Questes que precisam ser respondidas

DOCUMENTAO DO ELICITAO DE REQUISITOS

IDENTIFICAO E ELICITAO DE REQUISITOS

Quanto a performance, qual tempo de resposta adequado?

Quais funcionalidades ele deve ter?

O que o software deve fazer?

Quanto usabilidade, o software identifica visualmente a empresa e possui interface amigvel?

Quais so os requisitos de segurana que o software precisa?

Especialista em uma ou mais rea de negcio.

CARACTERSTICAS DA ELICITAO DE REQUISITOS

DIFERENA ENTRE UMA BOA E UMA M ELICITAO DE REQUISITOS

TAREFA 03 ELICITAO DE REQUISITOS (0,5)

No caa-palavras abaixo, encontre os itens:

Prototipao: quando existe alto grau de incerteza e necessita de um rpido feedback.

Exemplo: Casos (sentenas).

Perguntas que devem ser respondidas

ETAPAS PARA PREPARAR UMA REUNIO JAD

Etapas para preparao do JAD

Figura 15 Responsabilidades na etapa de Preparao do JAD

MODELO DE AGENDA DE CONVOCAO:

Figura 16 Modelo de Agenda TOPICOS PARA A AGENDA PADRO

ATIVIDADES A SEREM REALIZADAS NO DIA ANTERIOR A SESSO

Arrumar a sala de reunio. Montar e testar equipamentos.

Figura 17 Layout da sala de reunio de JAD

Figura 18 Responsabilidades da etapa Sesso de JAD TCNICAS PARA APOIAR A SESSO

Figura 19 Tcnicas de Apoio

ANALISADOR DA REUNIO PARA TODOS OS PARTICIPANTES

Figura 21 Modelo de anlise da reunio

Rever a documentao produzida na sesso; Examinar possveis melhorias na sistemtica adotada.

Figura 22 Responsabilidades na etapa de Reviso do JAD

PAPEIS DE CADA UM DENTRO DA REUNIO

DICAS PARA SER UM BOM LDER

MODELO DE ESPECIFICAO DE REQUISITOS

Figura 23 Modelo de especificao de requisitos

Exemplo: Clientes so pessoas fsicas e possuem nome, endereo e telefone:

Excluir Cliente Editar cliente CANCELAR fluxo alternativo

VERIFICAO E VALIDAO DE REQUISITOS

Ser que realmente entendi o que o cliente deseja?