(7428 - 22159) Metodologias e Projetos de Software

Universidade do Sul de Santa Catarina
Metodologias e Projetos de Software

Disciplina na modalidade a distncia
Palhoa UnisulVirtual 2011
Crditos
Universidade do Sul de Santa Catarina | Campus UnisulVirtual | Educao Superior a Distncia
Reitor Ailton Nazareno Soares Vice-Reitor Sebastio Salsio Heerdt Chefe de Gabinete da Reitoria Willian Corra Mximo Pr-Reitor de Ensino e Pr-Reitor de Pesquisa, Ps-Graduao e Inovao Mauri Luiz Heerdt Pr-Reitora de Administrao Acadmica Miriam de Ftima Bora Rosa Pr-Reitor de Desenvolvimento e Inovao Institucional Valter Alves Schmitz Neto Diretora do Campus Universitrio de Tubaro Milene Pacheco Kindermann Diretor do Campus Universitrio da Grande Florianpolis Hrcules Nunes de Arajo Secretria-Geral de Ensino Solange Antunes de Souza Diretora do Campus Universitrio UnisulVirtual Jucimara Roesler Equipe UnisulVirtual Diretor Adjunto
Moacir Heerdt Avenida dos Lagos, 41 Cidade Universitria Pedra Branca | Palhoa SC | 88137-900 | Fone/fax: (48) 3279-1242 e 3279-1271 | E-mail: cursovirtual@unisul.br | Site: www.unisul.br/unisulvirtual
Coordenadores Graduao
Alosio Jos Rodrigues Ana Lusa Mlbert Ana Paula R.Pacheco Artur Beck Neto Bernardino Jos da Silva Charles Odair Cesconetto da Silva Dilsa Mondardo Diva Marlia Flemming Horcio Dutra Mello Itamar Pedro Bevilaqua Jairo Afonso Henkes Janana Baeta Neves Jorge Alexandre Nogared Cardoso Jos Carlos da Silva Junior Jos Gabriel da Silva Jos Humberto Dias de Toledo Joseane Borges de Miranda Luiz G. Buchmann Figueiredo Marciel Evangelista Catneo Maria Cristina Schweitzer Veit Maria da Graa Poyer Mauro Faccioni Filho Moacir Fogaa Nlio Herzmann Onei Tadeu Dutra Patrcia Fontanella Roberto Iunskovski Rose Clr Estivalete Beche
Marilene de Ftima Capeleto Patricia A. Pereira de Carvalho Paulo Lisboa Cordeiro Paulo Mauricio Silveira Bubalo Rosngela Mara Siegel Simone Torres de Oliveira Vanessa Pereira Santos Metzker Vanilda Liordina Heerdt
Patrcia de Souza Amorim Poliana Simao Schenon Souza Preto
Gerncia de Desenho e Desenvolvimento de Materiais Didticos

Mrcia Loch (Gerente)
Karine Augusta Zanoni Marcia Luz de Oliveira Mayara Pereira Rosa Luciana Tomado Borguetti
Assuntos Jurdicos
Bruno Lucion Roso Sheila Cristina Martins
Gesto Documental
Lamuni Souza (Coord.) Clair Maria Cardoso Daniel Lucas de Medeiros Jaliza Thizon de Bona Guilherme Henrique Koerich Josiane Leal Marlia Locks Fernandes
Desenho Educacional
Marketing Estratgico Portal e Comunicao
Gerncia Administrativa e Financeira

Renato Andr Luz (Gerente) Ana Luise Wehrle Anderson Zandr Prudncio Daniel Contessa Lisboa Naiara Jeremias da Rocha Rafael Bourdot Back Thais Helena Bonetti Valmir Vencio Incio
Vice-Coordenadores Graduao
Adriana Santos Ramm Bernardino Jos da Silva Catia Melissa Silveira Rodrigues Horcio Dutra Mello Jardel Mendes Vieira Joel Irineu Lohn Jos Carlos Noronha de Oliveira Jos Gabriel da Silva Jos Humberto Dias de Toledo Luciana Manfroi Rogrio Santos da Costa Rosa Beatriz Madruga Pinheiro Sergio Sell Tatiana Lee Marques Valnei Carlos Denardin Smia Mnica Fortunato (Adjunta)
Gerncia de Ensino, Pesquisa e Extenso

Janana Baeta Neves (Gerente) Aracelli Araldi
Elaborao de Projeto
Carolina Hoeller da Silva Boing Vanderlei Brasil Francielle Arruda Rampelotte
Cristina Klipp de Oliveira (Coord. Grad./DAD) Roseli A. Rocha Moterle (Coord. Ps/Ext.) Aline Cassol Daga Aline Pimentel Carmelita Schulze Daniela Siqueira de Menezes Delma Cristiane Morari Eliete de Oliveira Costa Elosa Machado Seemann Flavia Lumi Matuzawa Geovania Japiassu Martins Isabel Zoldan da Veiga Rambo Joo Marcos de Souza Alves Leandro Roman Bamberg Lygia Pereira Lis Air Fogolari Luiz Henrique Milani Queriquelli Marcelo Tavares de Souza Campos Mariana Aparecida dos Santos Marina Melhado Gomes da Silva Marina Cabeda Egger Moellwald Mirian Elizabet Hahmeyer Collares Elpo Pmella Rocha Flores da Silva Rafael da Cunha Lara Roberta de Ftima Martins Roseli Aparecida Rocha Moterle Sabrina Bleicher Vernica Ribas Crcio Vanessa de Andrade Manoel (Coord.) Letcia Regiane Da Silva Tobal Mariella Gloria Rodrigues Vanesa Montagna
Rafael Bavaresco Bongiolo Catia Melissa Silveira Rodrigues Andreia Drewes Luiz Felipe Buchmann Figueiredo Rafael Pessi
Gerncia de Produo Design Visual
Arthur Emmanuel F. Silveira (Gerente) Francini Ferreira Dias Pedro Paulo Alves Teixeira (Coord.) Alberto Regis Elias Alex Sandro Xavier Anne Cristyne Pereira Cristiano Neri Gonalves Ribeiro Daiana Ferreira Cassanego Davi Pieper Diogo Rafael da Silva Edison Rodrigo Valim Fernanda Fernandes Frederico Trilha Jordana Paula Schulka Marcelo Neri da Silva Nelson Rosa Noemia Souza Mesquita Oberdan Porto Leal Piantino
Reconhecimento de Curso
Maria de Ftima Martins
Acessibilidade
Multimdia
Secretaria Executiva e Cerimonial

Jackson Schuelter Wiggers (Coord.) Marcelo Fraiberg Machado Tenille Catarina
Extenso Pesquisa
Maria Cristina Veit (Coord.) Daniela E. M. Will (Coord. PUIP, PUIC, PIBIC) Mauro Faccioni Filho (Coord. Nuvem)
Avaliao da aprendizagem
Srgio Giron (Coord.) Dandara Lemos Reynaldo Cleber Magri Fernando Gustav Soares Lima Josu Lange
Assessoria de Assuntos Internacionais

Murilo Matos Mendona
Coordenadores Ps-Graduao
Ps-Graduao Biblioteca
Assessoria de Relao com Poder Pblico e Foras Armadas

Adenir Siqueira Viana Walter Flix Cardoso Junior
Assessoria DAD - Disciplinas a Distncia
Patrcia da Silva Meneghel (Coord.) Carlos Alberto Areias Cludia Berh V. da Silva Conceio Aparecida Kindermann Luiz Fernando Meneghel Renata Souza de A. Subtil
Alosio Jos Rodrigues Anelise Leal Vieira Cubas Bernardino Jos da Silva Carmen Maria Cipriani Pandini Daniela Ernani Monteiro Will Giovani de Paula Karla Leonora Dayse Nunes Letcia Cristina Bizarro Barbosa Luiz Otvio Botelho Lento Roberto Iunskovski Rodrigo Nunes Lunardelli Rogrio Santos da Costa Thiago Coelho Soares Vera Rejane Niedersberg Schuhmacher Acadmica Angelita Maral Flores (Gerente) Fernanda Farias
Anelise Leal Vieira Cubas (Coord.) Salete Ceclia e Souza (Coord.) Paula Sanhudo da Silva Marlia Ignacio de Espndola Renan Felipe Cascaes
Claudia Gabriela Dreher Jaqueline Cardozo Polla Ngila Cristina Hinckel Sabrina Paula Soares Scaranto Thayanny Aparecida B. da Conceio
Conferncia (e-OLA)
Carla Fabiana Feltrin Raimundo (Coord.) Bruno Augusto Zunino Gabriel Barbosa
Gerncia de Logstica Logsitca de Materiais
Produo Industrial
Marcelo Bittencourt (Coord.)
Jeferson Cassiano A. da Costa (Gerente) Carlos Eduardo D. da Silva (Coord.) Abraao do Nascimento Germano Bruna Maciel Fernando Sardo da Silva Fylippy Margino dos Santos Guilherme Lentz Marlon Eliseu Pereira Pablo Varela da Silveira Rubens Amorim Yslann David Melo Cordeiro
Gerncia Servio de Ateno Integral ao Acadmico

Maria Isabel Aragon (Gerente) Ana Paula Batista Detni Andr Luiz Portes Carolina Dias Damasceno Cleide Incio Goulart Seeman Denise Fernandes Francielle Fernandes Holdrin Milet Brando Jenniffer Camargo Jessica da Silva Bruchado Jonatas Collao de Souza Juliana Cardoso da Silva Juliana Elen Tizian Kamilla Rosa Mariana Souza Marilene Ftima Capeleto Maurcio dos Santos Augusto Maycon de Sousa Candido Monique Napoli Ribeiro Priscilla Geovana Pagani Sabrina Mari Kawano Gonalves Scheila Cristina Martins Taize Muller Tatiane Crestani Trentin
Gesto Docente e Discente
Enzo de Oliveira Moreira (Coord.)
Capacitao e Assessoria ao Docente
Assessoria de Inovao e Qualidade de EAD
Gerncia Administrao
Denia Falco de Bittencourt (Coord.) Andrea Ouriques Balbinot Carmen Maria Cipriani Pandini
Assessoria de Tecnologia
Secretaria de Ensino a Distncia

Samara Josten Flores (Secretria de Ensino) Giane dos Passos (Secretria Acadmica) Adenir Soares Jnior Alessandro Alves da Silva Andra Luci Mandira Cristina Mara Schauffert Djeime Sammer Bortolotti Douglas Silveira Evilym Melo Livramento Fabiano Silva Michels Fabricio Botelho Espndola Felipe Wronski Henrique Gisele Terezinha Cardoso Ferreira Indyanara Ramos Janaina Conceio Jorge Luiz Vilhar Malaquias Juliana Broering Martins Luana Borges da Silva Luana Tarsila Hellmann Luza Koing Zumblick Maria Jos Rossetti
Osmar de Oliveira Braz Jnior (Coord.) Felipe Fernandes Felipe Jacson de Freitas Jefferson Amorin Oliveira Phelipe Luiz Winter da Silva Priscila da Silva Rodrigo Battistotti Pimpo Tamara Bruna Ferreira da Silva
Alessandra de Oliveira (Assessoria) Adriana Silveira Alexandre Wagner da Rocha Elaine Cristiane Surian (Capacitao) Elizete De Marco Fabiana Pereira Iris de Souza Barros Juliana Cardoso Esmeraldino Maria Lina Moratelli Prado Simone Zigunovas Anderson da Silveira (Ncleo Comunicao) Claudia N. Nascimento (Ncleo NorteMaria Eugnia F. Celeghin (Ncleo Plos) Andreza Talles Cascais Daniela Cassol Peres Dbora Cristina Silveira Ednia Araujo Alberto (Ncleo Sudeste) Francine Cardoso da Silva Janaina Conceio (Ncleo Sul) Joice de Castro Peres Karla F. Wisniewski Desengrini Kelin Buss Liana Ferreira Luiz Antnio Pires Maria Aparecida Teixeira Mayara de Oliveira Bastos Michael Mattar
Avaliaes Presenciais
Tutoria e Suporte
Nordeste)
Coordenao Cursos Coordenadores de UNA

Diva Marlia Flemming Marciel Evangelista Catneo Roberto Iunskovski
Graciele M. Lindenmayr (Coord.) Ana Paula de Andrade Angelica Cristina Gollo Cristilaine Medeiros Daiana Cristina Bortolotti Delano Pinheiro Gomes Edson Martins Rosa Junior Fernando Steimbach Fernando Oliveira Santos Lisdeise Nunes Felipe Marcelo Ramos Marcio Ventura Osni Jose Seidler Junior Thais Bortolotti
Gerncia de Marketing
Eliza B. Dallanhol Locks (Gerente)
Auxiliares de Coordenao
Ana Denise Goularte de Souza Camile Martinelli Silveira Fabiana Lange Patricio Tnia Regina Goularte Waltemann
Relacionamento com o Mercado Alvaro Jos Souto Relacionamento com Polos Presenciais
Alex Fabiano Wehrle (Coord.) Jeferson Pandolfo
Vera R. Niedersberg Schuhmacher

Livro didtico
Design instrucional Lvia da Cruz 6 edio
Palhoa UnisulVirtual 2011
Copyright UnisulVirtual 2011 Nenhuma parte desta publicao pode ser reproduzida por qualquer meio sem a prvia autorizao desta instituio.
Edio Livro Didtico

Professora Conteudista Vera Rejane Niedersberg Schuhmacher Design Instrucional Dnia Falco de Bittencourt Viviane Bastos Lvia da Cruz (5 ed. rev. e atual.) Assistente Acadmico Aline Cassol Daga (6 edio) ISBN 978-85-7817-291-6 Projeto Grfico e Capa Equipe UnisulVirtual Diagramao Jordana Paula Schulka (6 edio) Reviso Fabric
005.117 S41 Schuhmacher, Vera Rejane Niedersberg Metodologias e projetos de software : livro didtico / Vera Rejane Niedersberg Schuhmacher ; design instrucional Dnia Falco de Bittencourt, Viviane Bastos, Lvia da Cruz ; [assistente acadmico Aline Cassol Daga]. 6. ed. Palhoa : UnisulVirtual, 2011. 271 p. : il. ; 28 cm. Inclui bibliografia. ISBN 978-85-7817-291-6
1. Mtodos orientado a objetos (Computao). 2. UML (Computao). 3. Software de aplicao. I. Bittencourt, Dnia Falco de. II. Bastos, Viviane. III. Cruz, Lvia da. IV. Daga, Aline Cassol. V. Ttulo.
Ficha catalogrfica elaborada pela Biblioteca Universitria da Unisul
Sumrio
Apresentao. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 Palavras da professora. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9 Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11 UNIDADE 1 - Ciclos de vida de um processo de desenvolvimento de software . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17 UNIDADE 2 - Engenharia de requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43 UNIDADE 3 - Anlise estruturada. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67 UNIDADE 4 - Viso geral da UML. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93 UNIDADE 5 - Modelagem de casos de uso. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109 UNIDADE 6 - Modelagem de classes. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145 UNIDADE 7 - Modelos de interaes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187 UNIDADE 8 - Modelos de estados. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205 UNIDADE 9 - RUP e ICONIX. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225 Para concluir o estudo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247 Referncias. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249 Sobre a professora conteudista. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253 Respostas e comentrios das atividades de autoavaliao. . . . . . . . . . . . . . 255 Biblioteca Virtual. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
Apresentao
Este livro didtico corresponde disciplina Metodologias e Projetos de Software. O material foi elaborado visando a uma aprendizagem autnoma e aborda contedos especialmente selecionados e relacionados sua rea de formao. Ao adotar uma linguagem didtica e dialgica, objetivamos facilitar seu estudo a distncia, proporcionando condies favorveis s mltiplas interaes e a um aprendizado contextualizado e eficaz. Lembre-se que sua caminhada, nesta disciplina, ser acompanhada e monitorada constantemente pelo Sistema Tutorial da UnisulVirtual, por isso a distncia fica caracterizada somente na modalidade de ensino que voc optou para sua formao, pois na relao de aprendizagem professores e instituio estaro sempre conectados com voc. Ento, sempre que sentir necessidade entre em contato; voc tem disposio diversas ferramentas e canais de acesso tais como: telefone, e-mail e o Espao Unisul Virtual de Aprendizagem, que o canal mais recomendado, pois tudo o que for enviado e recebido fica registrado para seu maior controle e comodidade. Nossa equipe tcnica e pedaggica ter o maior prazer em lhe atender, pois sua aprendizagem o nosso principal objetivo.
Bom estudo e sucesso! Equipe UnisulVirtual.
Palavras da professora
Caro aluno/a, A disciplina Metodologias e Projetos de Software vai inserilo/a no universo da modelagem de projetos de software. O caminho da modelagem tem sido rduo atravs dos anos, sofrendo inmeras incluses e alteraes, tudo para se adaptar s constantes evolues da linguagem de programao, dos bancos de dados, dos sistemas operacionais, regras de negcio e paradigmas da programao. A comunidade de desenvolvimento percebe a necessidade cada vez maior de documentar seus projetos, uma vez que o volume crescente de linhas de cdigo torna nossa vida cada dia mais informatizada. Esse benefcio, no entanto, cobra seu preo: os softwares sofrem manutenes constantes e as equipes so frequentemente modificadas, mas o arsenal de cdigos continua tendo de ser executado com eficcia e eficincia. Este um dos contextos mais relevantes da modelagem: ela tem de permitir o entendimento do projeto a qualquer membro da equipe em qualquer ponto do processo, seja em uma etapa inicial de anlise de requisitos ou j em fase de manuteno no cliente. A modelagem pode ser comparada ao projeto de uma grande residncia. Se voc desejasse construir um pequeno canil e estivesse seguro/a sobre como faz-lo, bem provvel que nem precisasse de um projeto para constru-lo, uma vez que a edificao seria pequena e no apresentaria muitos riscos. Agora, imagine a construo de uma casa de trs andares. Ser que voc teria coragem de edific-la sem a ajuda de um bom projeto que previsse todos os aspectos relevantes da obra?
Acho que voc concorda comigo: nesse caso, nem pensaria em dispensar um projeto. Pois, nessa mesma relao, imagine a concepo de um software. Tenha a convico de que a modelagem fiel do sistema proporcionar ganhos de qualidade e economia de recursos a longo prazo. Ento, convencido/a da importncia do estudo desta disciplina? Pronto/a para comear? Bons estudos! Professora Vera Schuhmacher
10
Plano de estudo
O plano de estudos visa a orient-lo no desenvolvimento da disciplina. Ele possui elementos que o ajudaro a conhecer o contexto da disciplina e a organizar o seu tempo de estudos. O processo de ensino e aprendizagem na UnisulVirtual leva em conta instrumentos que se articulam e se complementam, portanto, a construo de competncias se d sobre a articulao de metodologias e por meio das diversas formas de ao/mediao. So elementos desse processo:

o livro didtico; o Espao UnisulVirtual de Aprendizagem (EVA); as atividades de avaliao (a distncia, presenciais e de autoavaliao); o Sistema Tutorial.
Ementa
Anlise de requisitos. Introduo ao Rational Unified Process (RUP). O paradigma orientado a objetos. Anlise arquitetural. Modelagem de um sistema utilizando-se a notao UML: modelagem de use cases, anlise e design; realizao de usecase, diagrama geral de classes persistentes, diagrama de interfaces e mapeamento objeto-relacional.
Objetivos
Geral:
Elucidar ao aluno a importncia da etapa de anlise e modelagem do projeto de software e da necessidade de conhecimento de metodologias e notaes que possam ser usados como facilitadores desta etapa.
Especficos:
Propiciar ao/ aluno/a o conhecimento sobre conceitos relacionados ao ciclo de vida de desenvolvimento de um software. Sensibilizar o/a aluno/a sobre a importncia do uso de metodologias de projeto de software para o sucesso efetivo deste projeto. Tornar presente a discusso sobre a relevncia de se dispensar tempo suficiente para as etapas iniciais do projeto, como a anlise de requisitos, procurando uma maturidade na compreenso das necessidades do usurio. Oferecer ao/ aluno/a o arsenal didtico necessrio para compreender o uso de tcnicas e mtodos estruturados de modelagem de sistemas. Capacitar o/a aluno/a a utilizar metodologias orientadas para a modelagem de sistemas.
Carga Horria
A carga horria total da disciplina 120 horas-aula.
12
Contedo programtico/objetivos
Veja, a seguir, as unidades que compem o livro didtico desta disciplina e os seus respectivos objetivos. Estes se referem aos resultados que voc dever alcanar ao final de uma etapa de estudo. Os objetivos de cada unidade definem o conjunto de conhecimentos que voc dever possuir para o desenvolvimento de habilidades e competncias necessrias sua formao. Unidades de estudo: 9
Unidade 1 - ciclos de vida de um processo de desenvolvimento de software

Nesta unidade, so tratados aspectos relativos ao processo de desenvolvimento de software e seus possveis modelos. Voc ter a oportunidade de conhecer as etapas do processo de desenvolvimento de um software e perceber que conduzir um processo de desenvolvimento de software exige um grande processo de gerncia.
Unidade 2 - Engenharia de requisitos

Esta unidade aborda o reconhecimento da importncia da etapa de engenharia de requisitos, tcnicas e artefatos para o desenvolvimento do processo. Voc vai perceber que a engenharia de requisitos um processo interativo que envolve a compreenso do domnio, a coleta de requisitos, a estruturao e o estabelecimento de prioridades para a execuo do projeto.
Unidade 3 - Anlise estruturada

Esta unidade contempla a anlise estruturada, em que so apresentados os requisitos da notao para uma abordagem estruturada. Notaes e caractersticas especficas utilizadas em uma modelagem estruturada e que so fundamentais em sua documentao sero apresentadas.
13
Unidade 4 - Viso geral da UML

Nesta unidade, feita a introduo linguagem de notao UML, seus diagramas e as possveis vises que iniciam a incurso na modelagem orientada a objetos, e so apresentadas as diferenas fundamentais existentes entre a anlise estruturada e a anlise orientada a objetos.
Unidade 5 - Modelagem de casos de uso

Esta unidade aborda o diagrama de casos de uso, sua documentao, nomenclatura e a identificao dos atores. Voc ter a oportunidade de identificar e construir os casos de uso necessrios para descrever o projeto.
Unidade 6 - Modelagem de classes

Nesta unidade, voc perceber que o modelo esttico da UML apresenta o diagrama de classes, responsabilidades, relacionamentos e a diviso das classes do modelo de anlise. O modelo de classes um dos modelos mais ricos em termos de notao e concentra o cerne esttico de todo o projeto.
Unidade 7 - Modelos de interaes

Nesta unidade, voc vai estudar sobre o modelo de interaes, que apresenta as mensagens trocadas entre os objetos na execuo de um determinado cenrio. O uso do modelo de interaes procura descrever o modelo dinmico do sistema propondo a descrio da troca de mensagens entre objetos.
14
Unidade 8 - Modelos de estados

O modelo de estados e atividades apresentado nesta unidade. Voc conhecer os diagramas de transio de estado que modelam o comportamento de um objeto e o diagrama de atividade que modela a sequncia geral de aes para vrios objetos e casos de uso.
Unidade 9 - RUP e ICONIX

Nesta unidade do livro voc ser apresentado aos modelos RUP e ICONIX e estudar sobre seus conceitos, fases e elementos. Voc perceber como o RUP colabora para a estruturao efetiva de tarefas e fluxos de trabalho de profissionais, atuando em equipes de desenvolvimento de software.
15
Agenda de atividades/Cronograma
Verifique com ateno o EVA, organize-se para acessar periodicamente a sala da disciplina. O sucesso nos seus estudos depende da priorizao do tempo para a leitura, da realizao de anlises e snteses do contedo e da interao com os seus colegas e professor. No perca os prazos das atividades. Registre no espao a seguir as datas com base no cronograma da disciplina disponibilizado no EVA. Use o quadro para agendar e programar as atividades relativas ao desenvolvimento da disciplina.
Atividades obrigatrias
Demais atividades (registro pessoal)
16
UNIDADE 1
Ciclos de vida de um processo de desenvolvimento de software

Objetivos de aprendizagem
Compreender as caractersticas do produto de software. Perceber as diversas etapas do processo de desenvolvimento de um software. Definir essas etapas dentro de um modelo de desenvolvimento de projeto.
Sees de estudo
Seo 1 Seo 2 Seo 3 Quais so as caractersticas do software? Quais so as etapas do processo de desenvolvimento de software? Modelo de desenvolvimento de software
Para incio de estudo

Desenvolver softwares uma tarefa rdua e complexa. Lidar com essa complexidade significa compreender claramente os processos relacionados ao desenvolvimento do software. preciso entender claramente o que cobrar e como deve ser cobrado em cada processo, o que pode ser executado em paralelo ou de forma sequencial. Esse conjunto de atribuies constitui as atividades de gerncia. Conduzir o processo de desenvolvimento de software um grande processo de gerncia e, para gui-lo da melhor forma possvel, preciso saber o que se espera de cada etapa. Nesta unidade, voc vai perceber que todo o processo de desenvolvimento, por mais complexo que parea, passa por etapas pr-definidas e universais. Essas etapas so conduzidas de forma diferente, dependendo da natureza do projeto ou mesmo da cultura de cada empresa. Definir a forma como esses processos sero executados fundamental para o bom andamento de todo o processo e at mesmo para a escolha de metodologias futuras. Vamos iniciar esta jornada metodolgica? Bom estudo!
Seo 1 Quais so as caractersticas do software?

Termos como internet, web e software so modernos e esto na mdia diariamente. So termos que, antigamente, eram exclusivos de reas extremamente tcnicas e agora se tornaram de domnio pblico. Ainda que informalmente se tenha uma ideia bsica do significado de internet ou de software, importante que se conhea o seu verdadeiro significado. Sendo assim, voc sabe o que significa software?
Ser que voc sabe realmente o que significa software?
18
Explicar esse conceito no simples, depende da tica pela qual se tenta entender. Voc poderia dizer que software o conjunto de instrues que, ao serem executadas, produzem a funo e o desempenho desejados. Poderia conceituar software como estruturas de dados que possibilitam que os programas manipulem adequadamente a informao. possvel dizer, ainda, que softwares so os documentos que descrevem a operao e o uso dos programas desenvolvidos ou projetados por engenharia, no manufaturados no sentido clssico. Todavia, possvel ser redundante e dizer que softwares so ferramentas pelas quais se explora os recursos do hardware, executa-se determinadas tarefas, resolve-se problemas ao interagir com a mquina e tornam o computador operacional. Conceituar software passa por conhecer suas caractersticas. Vejamos:
O software apresenta caractersticas nicas. Ele no se desgasta, mas se deteriora.
Mas o que isso? Imagine que voc compre uma Ferrari novinha!!! Agora, imagine voc circulando com a Ferrari todos os dias a 200 km/h por uma estrada cheia de buracos. Como estar sua Ferrari daqui a um ano? Com certeza vai estar cheia de rudos e talvez apresente problemas em alguns componentes. Isso acontece devido ao
Unidade 1
19
desgaste do carro. Ao final de dez anos dirigindo o carro por essa mesma estrada, bem provvel que voc tenha um carro cheio de problemas! Agora, imagine que voc tenha uma videolocadora e resolva comprar um software para informatizar todo o processo de atendimento. Abstraindo questes relacionadas ao hardware, esse software daqui a 100 anos ir funcionar da mesma maneira que hoje, ou seja, se tiver algum problema de programao, repetir o mesmo problema em todas as vezes que for executado. Mas se o software no tiver problemas, rodar perfeitamente todas as vezes que voc solicitar sua execuo. Ao final de trs anos, no entanto, mesmo funcionando perfeitamente, talvez esse software no supra mais suas necessidades. Imagine que nesse sistema voc digite o cdigo do DVD para realizar a movimentao, mas agora gostaria que ele lesse o cdigo de barras do DVD. E agora? por isso que dizemos que o software no se desgasta, mas se deteriora em funo de inovaes tecnolgicas e de novas necessidades do cliente. Ele acaba no atendendo mais s suas necessidades, apesar de funcionar, muitas vezes, sem apresentar.
O software desenvolvido ou projetado por engenharia, no manufaturado no sentido clssico.
Quando voc comprou sua geladeira, em algum momento pensou que ela foi fabricada como uma pea nica? Claro que no! Ela foi produzida em uma linha de produo. Agora pense em uma linha de produo de caminhes. Os componentes so incorporados ao projeto para dezenas de unidades. Mas quando se pensa em software, sabe-se que cada produto projetado e pensado como uma pea nica. impossvel visualiz-lo em uma esteira de produo!
20
Imagine as seguintes situaes:
Na linha de produo de caminhes, saem da fbrica 30 unidades dirias, 600 por ms. Dessas 600 unidades, a indstria possui uma estatstica de problemas apresentados em 0,2% da produo durante sua utilizao pelo cliente nos primeiros seis meses. Isso significa uma margem de problemas em um caminho sado da linha de produo mensal. Essa informao pode acabar com o nome da empresa? Qual sua opinio? Agora imagine uma empresa de software. Ela desenvolve o famoso sistema de videolocadora e vende esse produto para 600 clientes. Mas no final do sexto ms, acontece um erro no sistema (por exemplo, o programa no est armazenando corretamente a data de entrega do DVD). Essa mesma verso foi entregue para os 600 clientes e teremos ento 600 clientes com o mesmo problema. E agora? Essa informao pode acabar com o nome da empresa? Qual sua opinio? Sintetizando o problema: Em uma fbrica de software, o sucesso medido pela qualidade de uma nica entidade e no pela qualidade de muitas entidades manufaturadas.
IEEE - Instituto de Engenharia Eltrica e Eletrnica (IEEE) formado pela fuso do Instituto de Engenheiros de Rdio (IRA) com o Instituto Americano de Engenheiros Eltricos (AIEE). A meta do IEEE promover conhecimento no campo da engenharia eltrica e eletrnica estabelecendo padres para formatos de computadores e dispositivos.
Seo 2 Quais so as etapas do processo de desenvolvimento de software?

Existem alguns conceitos que so fundamentais quando falamos de desenvolvimento, e o primeiro deles Engenharia de Software (EGS). Assim como a palavra software, Engenharia de Software tambm um termo que gera discusses sobre a melhor maneira de expor todas as suas nuances. A IEEE definiu Engenharia de Software como a aplicao de uma abordagem sistemtica, disciplinada e quantificvel para o desenvolvimento, a operao e a manuteno do software; o estudo de abordagens e princpios, a fim de se obterem economicamente softwares confiveis e que sejam executados de forma eficiente em mquinas reais.
Unidade 1
21
A primeira definio do termo foi dada por Fritz Bauer em 1969:

Engenharia de software a criao e a utilizao de slidos princpios de engenharia a fim de obter software de maneira econmica, que seja confivel e que trabalhe eficientemente em mquinas reais.
A partir desse conceito, importante que voc entenda o significado de mtodo, procedimento e ferramenta, que so fonte de muita confuso, segundo Pressman (2002):
Mtodos - proporcionam os detalhes de como fazer para construir o software. Os mtodos envolvem um amplo conjunto de tarefas, como o planejamento e estimativa do projeto, a anlise de requisitos de software, o projeto da estrutura de dados, o algoritmo de processamento, a codificao, o teste e a manuteno. Ferramentas - fornecem suporte automatizado aos mtodos. Atualmente existem ferramentas para sustentar cada um dos mtodos. Quando as ferramentas so integradas, estabelecido um sistema de suporte ao desenvolvimento de software, chamado Computer Aided Software Engineering (CASE). Procedimentos - constituem o elo entre os mtodos e ferramentas, eles estabelecem a sequncia em que os mtodos sero aplicados, os produtos (deliverables) que devem ser entregues, os controles que ajudam a assegurar a qualidade e coordenar as alteraes e os marcos de referncia que possibilitam administrar o progresso do software.
Quando se fala em produo de software, muito difcil estabelecer preo, prazo e nmero de pessoas necessrias para o desenvolvimento. Existe uma metodologia chamada ponto por funo que nos ensina a encontrar resultados para as dvidas relacionadas a essas estimativas. Como fazer isso manualmente muito difcil, foram desenvolvidas ferramentas baseadas nesse mtodo, que o automatizam, mas, o ponto por funo uma metodologia que estabelece entrada de informaes e resultados na forma de clculos e relatrios. Os procedimentos sero utilizados para dizer quando as entradas de informaes sero feitas, quais relatrios sero emitidos e em que momento.
22
Segundo Pdua (2001), a EGS trata do software como produto e, como todo produto industrial, o software:
deve ser concebido a partir da percepo de uma necessidade; desenvolvido transformando-se em um conjunto de itens entregue ao cliente; entra em operao utilizado dentro de um processo de negcio e sujeito manuteno quando necessrio; retirado de operao ao final de sua vida til.
O que processo de software?
Wilson de Pdua Paula Filho ser referenciado como Pdua neste livro pelo fato de ser assim conhecido na rea
Quando se fala em processo longo, nos vem mente uma sequncia de passos para atingir um objetivo. E, como afirma Pdua (2001), processo de software exatamente isto: um conjunto de passos ordenados, constitudos por atividades, mtodos, prticas e transformaes, usado para atingir uma meta. Como voc j deve estar imaginando, processos podem ser definidos para atividades em todas as etapas do desenvolvimento de um software. Pressman (2002) sugere a diviso do desenvolvimento em trs processos genricos. Acompanhe a figura:
Figura 1.1 Etapas do desenvolvimento de software Fonte: Pressman (2002).
Unidade 1
23
Cada etapa pode ser detalhada como:
a) Definio
A primeira etapa constitui-se por identificar quais informaes devem ser processadas, qual funo e desempenho so desejados, quais interfaces devem ser estabelecidas, quais restries de projeto existem (por exemplo, o cliente precisa do software em 60 dias!) e quais critrios de avaliao so exigidos para se definir um sistema bem-sucedido (existem, por exemplo, normas internacionais que devem ser obedecidas no cho da fbrica e ser incorporadas ao sistema). A etapa de definio subdivide-se em: Planejamento do projeto no planejamento avaliamos se o projeto vivel, e como o desenvolvimento ser conduzido. Levantamento de requisitos Nessa etapa, o objetivo principal compreender o problema do cliente, suas necessidades, expectativas e restries. Aqui voc deve pensar com o cliente. Quais problemas existem? Como eles acontecem? Existe alguma caracterstica especfica que deve ser observada? De velocidade, portabilidade, interface, por exemplo. Anlise de requisitos Etapa de anlise dos dados da etapa anterior. Na anlise de requisitos ou especificao de requisitos, concebe-se uma estratgia para solucionar problemas e necessidades do cliente. Nessa etapa, voc ainda no precisa se preocupar com questes tecnolgicas. Assim, voc vai dizer o que o sistema deve fazer para apoiar o cliente, a partir de modelos.
b) Desenvolvimento
Nesta fase, voc tenta definir como a estrutura de dados e a arquitetura do software tm de ser projetadas. Durante a segunda etapa, voc ir realizar:
24
O projeto de software no projeto de software, voc deve definir como o sistema vai funcionar para atender aos requisitos levantados. Nessa fase, temos como resultado uma descrio computacional daquilo que o software deve fazer. Normalmente, tem-se aqui o projeto da arquitetura (especificao da configurao de componentes do software funes, classes, objetos e suas interconexes) e o projeto detalhado (que tem por objetivo a concepo e a especificao das estruturas de dados e dos algoritmos, que realizam aquilo que foi especificado para cada componente do software). Implementao Na implementao, o sistema codificado. Teste de software Na etapa de testes ocorre a verificao do que foi implementado. Vrias so as tcnicas: desde corretivas (procura de erros) at de validao com grupos de usurios.
c) Manuteno
Nessa fase ocorrero mudanas no software em consequncia dos erros encontrados. Alm disso, a etapa responsvel pelas adaptaes do software em funo da evoluo do hardware e necessidades do cliente. A manuteno pode ser corretiva (o cliente encontrar defeitos no software), adaptativa (modificaes no software que acomodam mudanas relacionadas evoluo do hardware: por exemplo, o cliente decide trocar o sistema operacional por uma possibilidade open source) e funcional (implementa funes adicionais para o cliente relacionadas expectativa que ele no tinha durante o desenvolvimento, como em uma situao na qual o gerente de recursos humanos precisa de um novo relatrio estatstico). Alm das trs etapas bsicas, devem ser consideradas ainda as atividades complementares fundamentais para o bom andamento do processo:
Unidade 1
25
Revises Efetuadas para garantir que a qualidade seja mantida medida que cada etapa concluda. Documentao desenvolvida e controlada para garantir que informaes completas sobre o software estejam disponveis para uso posterior. Controle das mudanas institudo de forma que as mudanas possam ser aprovadas e acompanhadas pelos gerentes e pela equipe de projeto.
Seo 3 Modelo de desenvolvimento de software

O processo de desenvolvimento apresentado na seo 2 um modelo genrico. Isso significa que suas etapas so aplicveis a qualquer modelo, independentemente do paradigma de desenvolvimento utilizado. As diferentes formas de proceder em relao ao processo de desenvolvimento apresentam caractersticas prprias a cada modelo, diferentes necessidades das empresas desenvolvedoras de software ou mesmo ao tipo de sistema desenvolvido. Pressman (2002) define o modelo de desenvolvimento como uma representao abstrata do processo de desenvolvimento que define como as etapas relativas ao desenvolvimento de software sero conduzidas e inter-relacionadas para atingir o objetivo do desenvolvimento do software. Alguns modelos de desenvolvimento esto h muitos anos no mercado, outros so muito recentes. D uma olhadinha, a seguir, nos mais conhecidos por sua utilizao nas empresas.
a) Modelo cascata
No modelo cascata, os subprocessos so executados em uma sequncia rgida. Assim, cada subprocesso passa a ser um marco de controle. Esse modelo exige uma abordagem sistemtica, sequencial, no desenvolvimento de software.
26
Isso acontece da seguinte forma, o desenvolvedor visita a empresa e inicia a etapa de levantamento de requisitos, aps algumas sesses, finaliza essa etapa e inicia outra, denominada etapa de anlise. Finalizada a etapa de anlise, o processo de desenho do sistema, de todo seu projeto. Finalizada esta etapa inicia-se a implantao do cdigo. Observe que no existe retorno a nenhuma etapa anterior. O modelo inflexvel: as etapas so sequenciais e no permitem regresso. Nesse modelo, ao finalizar o desenho do projeto, o desenvolvedor s poder modific-lo na etapa de manuteno. Essa viso burocrtica dos subprocessos gera situaes difceis de resolver pelos analistas. Pense: projetos reais raramente seguem o fluxo sequencial que o modelo prope. No incio de um projeto, difcil estabelecer explicitamente todos os requisitos, existe uma incerteza natural. Mas, o maior problema de todos a falta de visibilidade para o cliente! Somente na etapa de implantao o cliente ter contato com o software.
Figura 1.2 Modelo cascata Fonte: Pdua (2001).
No modelo em cascata, todo o projeto deve ser entendido em suas fases iniciais, seguindo at o final com pouqussima interao com o cliente.
Unidade 1
27
Imagine a situao: voc contratado para desenvolver um projeto em uma fbrica de calados na qual todo o processo de produo ser automatizado. Em seu planejamento, percebe que o processo todo estar finalizado em um prazo de 2 anos. Se voc optar pelo modelo cascata, o cliente ser apresentado ao sistema somente ao final de 2 anos! Ser que ele ter pacincia para esperar por este prazotodo esse tempo?
Outro ponto importante: o levantamento de requisitos feito no incio e o processo segue para a etapa seguinte sem retornar anterior. Ser que, em dois anos, nada vai mudar no processo da empresa? Ser, ento, que este modelo invivel para os tempos atuais? Saiba que foi um dos modelos mais utilizados no mundo e tem baixo custo, devido a sua estrutura sequencial. Nos tempos atuais podemos sugeri-lo quando se tem domnio do problema e/ou o projeto considerado pequeno.
b) Modelo espiral
O modelo em espiral totalmente diferente do anterior. Nele, a palavra de ordem a experimentao e a avaliao. Esse modelo desenvolvido em uma srie de interaes; cada interao corresponde a uma volta na espiral. Cada volta fundamentada na anlise de riscos da soluo que est sendo proposta.
Figura 1.3 Modelo espiral Fonte: Pressman (2002).
28
Na etapa de planejamento so determinados os objetivos, alternativas e restries. Durante o subprocesso de anlise de risco, so analisadas as alternativas e identificados os riscos e resolues possveis. Na construo ocorre o desenvolvimento do produto no nvel seguinte. A avaliao do cliente fundamental, pois nela ocorre a avaliao do produto e o planejamento das novas fases cliente e desenvolvedor refinam os requisitos dos softwares a serem desenvolvidos. O modelo exige dos desenvolvedores experincia na determinao de riscos, sendo portanto, dependente da experincia pessoal da equipe. Talvez voc esteja se perguntando quando poder utilizar esse modelo. uma boa pergunta. Imagine que voc tenha de apresentar uma soluo para um cliente e que voc no esteja certo sobre a tecnologia a ser utilizada ou a forma como a estrutura de dados deva ser construda. A melhor maneira de fazer o melhor servio ser usando o modelo espiral. Utilize prototipao, simulao ou qualquer recurso possvel para avaliar diferentes solues at encontrar a melhor soluo! Quando voc estiver certo da resposta, siga na direo da engenharia, onde temos as etapas padro do processo de desenvolvimento.
Imagine que voc foi contratado para desenvolver um produto que faa vdeoinspeo a distncia de dutos de galerias de drenagem para a prefeitura do Rio de Janeiro. Voc poderia indicar uma soluo de imediato? Ou teria dvidas sobre como faz-lo da melhor maneira, pela grande oferta de recursos tecnolgicos e mesmo restries de projeto existentes?
c) Modelo prototipao
A prototipao envolve a produo de verses iniciais prottipos de um sistema futuro com o qual podem-se realizar verificaes e experimentaes para avaliao de algumas de suas qualidades antes que o sistema venha realmente a ser construdo.
Unidade 1
29
Esse modelo popularmente usado como um mecanismo para identificar os requisitos de software. Imagine voc iniciando um trabalho com um cliente que lhe solicita um software para o controle de uma UTI, mas voc no faz ideia do funcionamento de uma UTI. E o pior que o cliente no parece dispor de muito tempo para explicar novamente o que voc no conseguiu entender.
Figura 1.4 Modelo prototipao Fonte: Pressman (2002).
Na figura 1.4 voc percebe o ciclo de desenvolvimento da prototipao: o processo inicia com a obteno de requisitos, segue-se ento um projeto rpido para o futuro desenvolvimento do prottipo. Finalizado o prottipo, realizada uma avaliao com o cliente ou com a prpria equipe de projeto. Os resultados da avaliao so utilizados para refinar o prottipo, reiniciando o ciclo at a avaliao. O processo se repete at o momento em que o grau de aceitao do prottipo seja considerado aceitvel. A partir deste momento, inicia-se a construo do produto, em que se pode utilizar qualquer outro modelo: cascata, incremental, entre outros.
30
A prototipao pode ser conduzida segundo duas tcnicas especficas de construo: a prototipao horizontal, em que uma camada especfica do sistema construda (a interface do usurio com suas janelas e widgets ou camadas da aplicao, como as funes para transao em bancos de dados); a prototipao vertical, em que uma parte da funcionalidade do sistema escolhida para ser implementada completamente. A prototipao vertical interessante quando aspectos da funcionalidade no esto claros. A partir da validao do prottipo, o modelo segue no processo tradicional de desenvolvimento para a construo do produto. Lembre-se: quando se valida uma informao verbal com o cliente, em muitos casos a ateno dele no total e muitas palavras se perdem durante o dilogo. Um desenho, no papel, do prottipo de uma tela torna-se 100 vezes mais claro e objetivo, alm de conseguirmos 100% da ateno do cliente.
d) Modelo incremental
O modelo incremental foi desenvolvido a partir da combinao entre os modelos linear e de prototipao (PRESSMAN, 2002). Quando voc usa esse modelo, todo o desenvolvimento dividido em etapas que so produzidas de forma incremental at se chegar a um sistema finalizado. Para cada etapa realizado um ciclo completo de desenvolvimento e novas funcionalidades so adicionadas ao sistema. Assim, voc pode dizer que todo o desenvolvimento evolui em verses.
Unidade 1
31
Figura 1.5 Modelo incremental Fonte: Pdua (2001).
Se voc deseja utilizar esse modelo, considere a forma como todo o projeto ser construdo. Pense em questes relacionadas prioridade (o que mais importante para o cliente) e no risco de cada requisito. Tenha estratgia em mente e observe se o que prioritrio pode ser desenvolvido primeiro. No esquea: o primeiro mdulo o carto de visitas de sua empresa para o cliente! Nesse modelo, temos uma forte participao do cliente no projeto. Ele avalia os incrementos emtregues, o que permite corrigir possveis problemas nos mdulos em desenvolvimento e realizar os acertos devidos. Outro ponto importante que voc deve considerar, logo no incio, os requisitos mais arriscados. Fazendo isso, qualquer inconsistncia aparece logo no comeo e voc ter tempo para reagir e solucionar o problema. Fundamental nesse modelo a viso global do sistema. O gerente deve ter em mente a soma de todos os mdulos, evitando redundncias na construo do produto. O modelo incremental um dos mais utilizados na atualidade e em sua estrutura comum percebermos a insero da prototipao.
E as metodologias geis?
32
At pouco tempo, tudo o que se pensava sobre metodologias de desenvolvimento de software parecia extremamente ligado a farta documentao e processos delineados com clareza. Para muitos desenvolvedores, no entanto, passos firmemente delineados e documentados para cada etapa do desenvolvimento eram considerados uma burocracia desnecessria e que por vezes produzia altos custos ao projeto. A divergncia sobre a eficincia do uso de modelos que consideravam aqueles mais tradicionais, limitadores para equipes de desenvolvimento e, no raro, eram apontados como causa de atrasos e dificuldades no desenvolvimento. Por outro lado, pequenas empresas disprovidas de grandes oramentos ficavam margem dos modelos tradicionais por sua incapacidade de comportar a estrutura necessria para sua execuo. A demanda criada a partir dessa situao deu origem a um novo modelo, segundo Soares (2004), voltado a pessoas e no a processos ou algoritmos: os mtodos geis. As metodologias geis possuem caractersticas que determinam um foco maior na codificao e no na documentao, so claramente adaptativas, pois novos fatos que so apresentados no decorrer do projeto so tratados durante o desenvolvimento, e no existe a preocupao de conhecer o todo a partir de uma avaliao preditiva: novidades so adaptadas e incorporadas durante o desenvolvimento. A metodologia gil , portanto, naturalmente interativa, incremental, e acrescenta uma boa participao do usurio no processo. A seguir, conhea duas representantes dessa nova corrente, as metodologias Extreme Programming e SCRUM.
Extreme Programming (XP)

O mtodo XP foi criado por Kent Beck na dcada de 90, e no ano de 1996 tornou-se mundialmente conhecido ao ser utilizado na empresa Daimler Chrysler. Havia um projeto na empresa que durante anos no fora concludo e, ao fazer uso da metodologia, teve sua execuo completa realizada em apenas quatro meses.
Unidade 1
33
Mas o que o XP? Segundo Beck (1999), o XP uma metodologia gil para equipes pequenas e mdias que desenvolvem software baseado em requisitos vagos e que se modificam rapidamente. Nesse processo, a burocracia deve ser mnima, as equipes, pequenas (sugere-se at 10 pessoas), trabalhando de forma incremental, apoiados integralmente pelo futuro usurio do sistema. A anlise dos requisitos ocorre medida que so descritos e solicitados pelo usurio, ou seja, o conhecimento sobre o problema evolui durante seu desenvolvimento. O XP norteado por valores, princpios e regras. Beck (1999) define quatro valores que descrevem o XP: a comunicao, a simplicidade, o feedback e uma boa dose de coragem. A seguir, acompanhe uma breve descrio desses valores, segundo Wuestefeld (2001). Simplicidade Est ligada simplicidade do software, do processo usado no desenvolvimento, na comunicao e em tudo o que norteia o trabalho de desenvolvimento, ou seja, descomplicar. A regra do XP simplificar! Comunicao Ela deve ocorrer em todos os sentidos, desde o uso dos escritos a partir da conveno de padres de codificao para facilitar o entendimento at a preferncia por reunies (presenciais) para discusso de requisitos e dvidas, o trabalho em salas comuns evitando-se o isolamento da equipe, a execuo de revises do projeto em conjunto com toda a equipe. Feedback Os possveis problemas devem ser identificados o mais cedo possvel para que possam ser corrigidos rapidamente. Da mesma forma, oportunidades descobertas devem ser aproveitadas rapidamente. Coragem fundamental para apontar problemas, solicitar ajuda, para alterar e simplificar um que j esteja funcionando, para apresentar prazos que muitas vezes podem no agradar ao seu usurio final, mas que so necessrios para no comprometer a qualidade do projeto.
34
Os valores do XP so fundamentados em alguns princpios como o feedback rpido, a simplicidade que deve ser assumida em todas as etapas do projeto, a conscincia de mudanas que devem acontecer de forma incremental, a compreenso e aceitao das mudanas e a necessidade da qualidade do trabalho. Valores e princpios se entrelaam na definio de prticas bsicas que so adotadas pelo XP (BONA, 2002). As doze prticas bsicas adotadas pelo XP segundo Soares (2004) so: Jogo de planejamento. Nesta prtica, decide-se o que deve ser feito (requisitos) e as prioridades. Tambm determinado o escopo da prxima verso. Divide-se por duas reas: o jogo do planejamento que decide sobre o escopo, a composio das verses e as datas de entrega realizado pela rea de negcios; as estimativas de prazo, o processo de desenvolvimento e o cronograma so determinados pelos programadores. Programao em pares. A programao feita em duplas, dois programadores trabalham sempre juntos na mesma mquina. Enquanto um dos programadores escreve, o segundo confere a padronizao e o raciocnio lgico. Semana de 40 horas. No modelo, a semana de 40 (quarenta) horas. Hora extra abolida, pois parte-se do princpio de que um programador cansado produz mais erros e, portanto, deve ser evitado. Pequenas verses. O sistema baseado em entregas frequentes de verses com tamanho pequeno, que so incrementadas em requisitos continuamente (entregas de verses mensais com feedback de aceitao do cliente, por exemplo). Metforas. O uso de metforas procura descrever o software sem a utilizao de termos tcnicos, facilitando a comunicao com o cliente.
Unidade 1
35
Projeto simples. O sistema precisa ser projetado o mais simplesmente possvel, satisfazendo os requisitos atuais, sem preocupao com requisitos futuros. Teste. A equipe de desenvolvimento descreve em um primeiro momento os casos de testes, aps essa tarefa continua o desenvolvimento. Assim como os desenvolvedores, os clientes tambm escrevem testes a fim de validar o atendimento dos requisitos. Refactoring. Sempre que possvel, o projeto deve ser aperfeioado. Esse aperfeioamento deve propor a clareza do software. Propriedade coletiva. Pertence a todo o grupo. Isso significa que no existe o conceito de propriedade para um algoritmo. Qualquer integrante da equipe pode acrescentar ou alterar, desde que realize os testes necessrios para valid-lo. Integrao contnua. A construo e a integrao do sistema ocorrem vrias vezes por dia. Tarefas so completadas continuamente. Cliente dedicado. O usurio final est disponvel todo o tempo, determinando os requisitos, atribuindo prioridades e, principalmente, respondendo s dvidas. Padronizao do cdigo. O cdigo escrito com um grande cuidado quanto a padronizaes. Isso facilita o entendimento, assegurando a clareza e a comunicao entre programadores e projetistas .
SCRUM (Software Development Process)

Segundo relatos de Sutherland (2004), o SCRUM foi documentado e concebido na empresa Easel Corporation em 1993. A ideia inicial era voltada para empresas automotivas. Mais tarde, a metodologia foi incorporada pelas empresas Advanced Development Methods e VMARK, passando por modificaes e melhorias at chegar em um processo considerado adequado para projetos e desenvolvimento de software orientado a objetos.
36
O SCRUM possui aspectos semelhantes ao XP: tambm formatado para o uso de equipes pequenas, nas quais os requisitos no so claros, com interaes de curta durao e o mximo de visibilidade no processo de desenvolvimento. O SCRUM divide o desenvolvimento em interaes com durao de 30 dias, chamadas de sprints. As equipes multidisciplinares so formadas por projetistas, programadores, engenheiros e gerentes de qualidade. Cada equipe trabalha em torno dos requisitos do projeto que so definidos no incio de um sprint. A cada dia ocorre uma reunio da equipe, na qual se discutem metas, dificuldades e objetivos. Observe que isso acontece todos os dias!
Quais so as caractersticas da metodologia SCRUM?
Schwaber (2002) algumas caractersticas da metodologia SCRUM que caracterizam etapas do seu processo de desenvolvimento. Existem duas fases bem definidas: a primeira de planejamento (pr-game phase) e a segunda, de fechamento (post-game phase), onde os processos so definidos claramente. Durante o planejamento, definem-se requisitos, so estabelecidas prioridades e estimativas e so feitas anlises de necessidades, como treinamento da equipe e sobre as ferramentas. Na fase de sprint ( game phase), todo o processo baseia-se na experincia da equipe. As fases do sprint so gerenciadas por meio de controles que abrangem riscos e a otimizao de questes de flexibilidade. Os sprints no apresentam uma estrutura linear: muitas vezes, o uso da tentativa e do erro funciona para determinar e reconhecer ou conhecer o processo. Ainda assim, importante entender que o sprint acontece de forma tradicional, ou seja, seguindo etapas de anlise, projeto, implementao e testes.
Unidade 1
37
A caracterstica forte do SCRUM o processo rpido: os ciclos duram de sete a 30 dias. Alm disso, todo o desenvolvimento cresce de forma incremental, podendo ser alterado durante todo o processo. O fechamento do projeto baseia-se no ambiente e pode-se dizer que o produto a ser entregue ser determinado durante o projeto. A finalizao (post-game phase) apresenta o produto ao cliente e procura avaliar, com a equipe, a evoluo do projeto. Nessa etapa, so tratadas questes como testes, integraes e documentao.
Quer conhecer mais sobre esses modelos? Acesse na internet o site do Modelo XP Programming, que apresenta uma abordagem de programao em pares, com a definio da etapa de testes no incio do projeto e intensa participao do usurio final.
Qual o melhor modelo, qual o pior? Tais definies dependem da natureza do projeto, da empresa e sua organizao, das ferramentas e dos recursos existentes na empresa de desenvolvimento. Uma ideia que ganha cada vez mais adeptos a combinao de diferentes modelos, aproveitando-se o melhor de cada um.
38
Sntese
Nesta primeira unidade voc teve contato com conceitos e modelos relacionados ao processo de desenvolvimento de software. Tambm estudou sobre a importncia de se estabelecerem claramente, nas empresas de software, os subprocessos existentes no processo de desenvolvimento. Foi possvel perceber que diferentes modelos servem para o desenvolvimento de sistemas com caractersticas especficas. O uso dos modelos tambm pode ser feito de forma combinada para um mesmo projeto. O projeto pode respeitar o modelo incremental, fragmentando suas funcionalidades; para alguns mdulos em que no esto claros os requisitos, pode-se usar a prototipao; para um mdulo em que se necessita avaliar algum risco, o modelo espiral indicado. Assim, misturando-se os modelos, tem-se o melhor de todos eles.
Atividades de autoavaliao
Leia com ateno os enunciados e, aps, realize as questes propostas. 1) Classifique as questes a seguir, em Verdadeira (V) ou Falsa (F). a) ( ) O software pode ser definido como um conjunto de instrues se visto do ponto de vista do programador. b) ( ) Uma das caractersticas mais interessantes do software est relacionada ao fato de ser um produto personalizvel. Isso se deve por ser um produto de engenharia e no manufaturado no sentido clssico. c) ( ) O software e a empresa que o produz so muitas vezes avaliados por apenas uma unidade, pois a mesma pode ser vendida para dezenas de clientes com ou sem customizao. d) ( ) O desgaste do software refere-se apenas adaptao de produtos a novas tecnologias. e) ( ) Uma definio completa de software pode ser sugerida a partir da soma de instrues, documentao e estrutura de dados.
Unidade 1
39
2) Relacione a primeira coluna com a segunda. A. Definio B. Levantamento de requisitos C. Desenvolvimento D. Projeto de software E. Manuteno F. Revises G. Atividades de apoio H. Anlise de requisitos ( ) ( ) ( ) ( ) ( ) Composto por atividades que ocorrem no decorrer de todo o processo de desenvolvimento, como revises, controle de mudanas e documentao. Define o que deve ser feito para apoiar o cliente em seus problemas Nessa etapa, so executados o projeto, codificao e testes do software. Etapa que identifica as necessidades do cliente. a etapa responsvel por alteraes de cunho corretivo e adaptativo do software. Atividades efetuadas para garantir que a qualidade seja mantida. Fazem parte dessa etapa o planejamento do projeto, levantamento e anlise de requisitos. Define como o software ir implementar a soluo do cliente.
( )
( )
( )
3) Assinale as afirmativas corretas. a) ( ) Os mtodos proporcionam detalhes relacionados construo do software para as etapas de planejamento e estimativa. b) ( ) Os mtodos estabelecem detalhes de como fazer para construir um software em todas as etapas do processo; as ferramentas automatizam os mtodos, facilitando sua utilizao; os procedimentos estabelecem controles, artefatos que assegurem a correta utilizao do mtodo. c) ( ) Procedimentos proporcionam os detalhes de como construir o software; ferramentas automatizam os procedimentos; os mtodos formam o elo entre ambos.
40
4) Relacione as caractersticas de cada modelo [C]ascata, [P]rototipao, [I]ncremental ou [E]spiral: a) ( ) Neste modelo de desenvolvimento possvel avaliar riscos de projeto, tomando-se decises baseadas na experimentao de diferentes solues. b) ( ) O modelo facilita a identificao de requisitos para a construo do futuro software por meio de prottipos. c) ( ) O sistema fragmentado, sendo que cada fragmento percorre todo o ciclo de desenvolvimento do software. d) ( ) Nesse modelo, as subtarefas so executadas de forma sequencial e bastante rgida, sendo que o cliente tem contato com o sistema somente quando ocorre sua concluso. 5) Assinale com X qual dos modelos a seguir oferece menor contato com o cliente. a) ( ) Modelo cascata b) ( ) Modelo incremental c) ( ) Modelo prototipao d) ( ) Modelo espiral 6) A empresa CONSTONIS procura sua empresa para solicitar o desenvolvimento de um software, para controle de vendas de imveis. A empresa responsvel pela construo de prdios realiza a venda de seus imveis vista ou por financiamento direto com a construtora. O sistema deve possibilitar o controle das vendas assim como o controle do financiamento, que aceita ouro, carros, imveis, consrcios, dlares ou reais como parte do pagamento. O cliente no deixou muito claro o clculo do saldo devedor do comprador nem a forma como ocorre o acmulo de dbito do cliente. O sistema apresenta, em sua anlise inicial, 30 funcionalidades entre cadastros e relatrios de consulta. Qual o modelo de desenvolvimento que voc adotaria? a) ( ) Modelo cascata b) ( ) Modelo incremental c) ( ) Modelo prototipao d) ( ) Modelo espiral
Unidade 1
41
7) Observe o modelo XP e o modelo SCRUM, e a seguir descreva o que possvel determinar como diferenas fundamentais em relao aos modelos tradicionais.
Saiba mais
Para aprofundar as questes abordadas nesta unidade, voc poder pesquisar os seguintes livros: PRESSMAN, Roger. Engenharia de Software. So Paulo: McGraw-Hill, 2002. SOMMERVILLE, Ian. Engenharia de software. 6. ed. So Paulo: Addison-Wesley, 2003.
42
UNIDADE 2
Engenharia de requisitos
Reconhecer a importncia da anlise de requisitos no processo de desenvolvimento. Perceber as diferentes etapas que fazem parte da engenharia de requisitos. Realizar de forma consistente a atividade de anlise de requisitos.
Sees de estudo
Seo 1 Seo 2 Seo 3 Seo 4 Engenharia de requisitos Levantamento de requisitos Especificao de requisitos Atividades de apoio

Quando voc inicia um projeto de software, existe sempre uma preocupao: fazer o melhor projeto. Mas qual o melhor projeto? Na verdade, aquele que atende o cliente da melhor maneira. A etapa de engenharia de requisitos o momento em que as necessidades so exploradas por parte do desenvolvedor em companhia do cliente e sua empresa. Para que essa etapa seja finalizada com uma proposta de soluo adequada, necessrio que tarefas, como o estudo de viabilidade, licitao e anlise de requisitos, especificao e gerenciamento de requisitos, sejam realizadas de forma cuidadosa e consistente. Nesta unidade voc vai perceber que a engenharia de requisitos um processo interativo que envolve a compreenso do domnio, a coleta de requisitos, a estruturao e o estabelecimento de prioridades para a execuo do projeto. Voc acredita que os requisitos persistem ao longo do tempo? Ser que um projeto iniciado em janeiro ter os mesmos requisitos ao final de 12 meses? A compreenso do projetista sobre o problema dispensa a participao do cliente em etapas de verificao? Nos estudos desta unidade, voc vai encontrar apoio para responder a algumas dessas questes.
Seo 1 Engenharia de requisitos

Voc j esteve envolvido na construo de uma casa? Ou teve algum construindo prximo a voc? Imagine ento que voc construir uma casa e deseja que ela seja espaosa, com dois pavimentos, trs quartos, trs banheiros etc. Qual seria a primeira ao a ser tomada? Pense um pouco a respeito.
44
Bom, a primeira coisa que voc com certeza far contratar o pedreiro, comprar o material e iniciar a obra, pois voc sabe exatamente como sua casa deve ser feita. No verdade? No? Por qu? Isso no acontece porque se sabe da necessidade de ter um projeto claro, em projetar os aspectos relacionados estrutura hidrulica, eltrica, alm de ter profissionais aptos a conceber a melhor soluo para as nossas suas necessidades. Depois de finalizado o projeto que se inicia a construo e, nesse momento, o projeto documentado da planta funciona como um roteiro de gerenciamento, ou seja, tudo o que for construdo deve estar de acordo com o que foi projetado. Isso significa que o que os pedreiros e o mestre de obras realizam com o projeto feito validado por engenheiros e arquitetos. Se voc construsse sem fazer um projeto, acredita que sua casa seria feita dentro de suas expectativas, solucionando suas necessidades? quase certo que isso no aconteceria! O exemplo da casa tambm vlido para a construo de um software, mas infelizmente muitas empresas ainda apostam no desenvolvimento do produto sem passar formalmente pela etapa inicial de definio e projeto, indo direto para a programao. O resultado, porm, muitas vezes desastroso. Ao se iniciar um projeto de software, comea-se uma srie de processos, marcados por entregas de artefatos predeterminados pelos modelos de desenvolvimento utilizados e suas metodologias. A etapa de engenharia de requisitos encontra-se estrategicamente no incio do projeto, pois nessa fase que voc vai compreender as necessidades de seu futuro cliente. Peters (2001) declara com grande propriedade que o grau de compreensibilidade, preciso e rigor da descrio, fornecido por um documento de requisitos de software, tende a ser diretamente proporcional ao grau de qualidade do produto resultante.
Unidade 2
45
Mas o que um requisito?

Requisito de software uma descrio dos principais recursos de um produto de software, seu fluxo de informaes, comportamento e atributos.
Pdua (2001) descreve que requisitos so caractersticas que definem os critrios de aceitao de um produto. Essas caractersticas podem ser divididas em:
caractersticas funcionais que representam o comportamento que o sistema deve apresentar diante das interaes do usurio (o cliente deseja que seu vendedor lance o pedido de vendas para emitir relatrio de comisses mensais por vendedor); caractersticas no funcionais que representam aspectos comportamentais do sistema (o cliente deseja que o pedido seja lanado no momento em que feito pelo cliente, o que pode indicar a necessidade de recursos wireless).
Na maioria das vezes, requisitos no funcionais no so solicitados pelo cliente, mas devem ser inerentes ao projeto. So questes como a portabilidade do sistema, sua segurana e confiabilidade dos dados. Voc ainda pode explicar requisitos a partir do conceito de que so formados por:
requisitos explcitos so as necessidades ou as prprias condies e objetivos propostos pelo cliente (o cliente deseja ter os dados cadastrais de seus fornecedores); requisitos implcitos incluem as diferenas entre os usurios, a evoluo no tempo, as implicaes ticas, as questes de segurana e outras vises subjetivas (o cliente deseja um site de comrcio eletrnico; questes de segurana talvez no sejam a preocupao dele, por falta de conhecimento em tecnologia, mas so requisitos que devem estar implcitos no seu produto);
46
requisitos normativos so decorrentes de normas, leis ou padres (a emisso de uma nota fiscal deve seguir as regras propostas pela federao). Na etapa inicial da anlise de requisitos, fundamental que o analista entenda as necessidades do cliente. Isso significa compreender claramente os requisitos explcitos, implcitos e normativos. Essa compreenso da amplitude do problema proporcional ao sucesso do projeto com seu cliente final. Parece fcil, mas uma das maiores dificuldades nesse processo a comunicao entre cliente e desenvolvedor. Veja a figura a seguir. A viso do que o cliente solicitou ao desenvolvedor, sua necessidade, fica totalmente comprometida por falhas no entendimento e na comunicao. O resultado do que acaba sendo feito tem gerado custos elevados para empresas desenvolvedoras e para seus clientes, que em muitas situaes no conseguem usar o produto desenvolvido.
Figura 2.1 Evoluo dos requisitos Fonte: Pdua (2001).
A dificuldade de entender o cliente um desafio que deve ser encarado a partir de tcnicas, mtodos e pacincia por parte do desenvolvedor.
Lembre-se: A pressa para chegar implementao no ser o caminho mais curto.
Unidade 2
47
Os processos usados durante a engenharia de requisitos variam, dependendo do domnio da aplicao, das pessoas envolvidas e da organizao que est desenvolvendo os requisitos. Existem algumas atividades genricas comuns a todos os processos, que so:

levantamento de requisitos; documentao de requisitos; especificao de requisitos; validao de requisitos; gerenciamento de requisitos.
Nas prximas sees, voc vai estudar sobre as primeiras etapas do processo de engenharia de requisitos, a comear pela etapa de levantamento de requisitos.
Seo 2 Levantamento de requisitos

na etapa de levantamento de requisitos que ocorre a compreenso do problema aplicada ao desenvolvimento de software. Quando voc est nessa fase, fundamental que usurios e desenvolvedores tenham a mesma viso do problema a ser resolvido. Isso significa que voc precisa conhecer os requisitos to bem quanto o prprio cliente. Mas, como obter esses requisitos? Durante o levantamento de requisitos, voc vai se deparar com um grande volume de relatrios, formulrios e documentos. Mas quais so os que voc deve avaliar?
48
Por outro lado, em uma empresa com 500 funcionrios, sero 500 as pessoas envolvidas no processo de levantamento. Voc vai entrevistar todas elas?
nessa hora que voc deve perceber a importncia de ver a floresta em vez das rvores. Detecte as pessoaschave do processo, trabalhe usando amostragens da populao. Escute com ateno a gerncia da empresa e seus objetivos.
Retome o exemplo da construo de uma casa. Para que o arquiteto inicie o projeto, ele precisa perceber o perfil do cliente, suas preferncias e necessidades. Para essa etapa, existem algumas tcnicas teis, como a entrevista, observaes, investigao, entre outras.
a) Entrevista
O uso da entrevista feito pelo uso do formato perguntaresposta. Usando essa tcnica, voc pode obter opinies do usurio, descobrir o que o cliente pensa sobre o sistema atual, obter metas organizacionais/pessoais e levantar procedimentos informais. Quando voc realizar uma entrevista, lembre-se de:
tentar estabelecer com o cliente um clima de confiana e entendimento; manter-se sempre no controle da entrevista; tentar mostrar ao cliente sua importncia dentro do sistema; preparar-se antecipadamente para a entrevista.
Lembre-se: Inclua em sua lista de entrevistados pessoas-chave dentro do futuro sistema.
Unidade 2
49
O que significa preparar-se para a entrevista?
Estude o material previamente, verifique a linguagem utilizada (imagine que, se o software for da rea jurdica, voc precisa falar e entender as nuances e significados dos termos utilizados durante sua entrevista), perceba aspectos relacionados organizao e mesmo sobre o futuro entrevistado. Estabelea claramente os objetivos, saiba o que perguntar, no faa rodeios. Quando voc realizar uma entrevista, marque a data e a hora com antecedncia, com durao de no mnimo 45 minutos e, no mximo, de duas horas. Elabore as questes e a estrutura da entrevista, e durante a entrevista registre tudo o que for possvel, fazendo uso de anotaes ou de um gravador. Ao formular as questes, tome algumas precaues.
Evite usar questes que levem o entrevistado a responder de uma forma especfica ou tendenciosa.
Inadequada: Voc tambm acredita que a prioridade do desenvolvimento deva ser o faturamento, como seu gerente afirmou? Melhor: O que voc acha que deve ser implantado em primeiro plano?
Fazer duas questes em uma torna a pergunta confusa e a resposta pode no ser completa. Ainda possvel que a pessoa acabe respondendo a uma das questes apenas.
Inadequada: Em que situaes voc cancela uma nota fiscal? Quando ocorre o cancelamento de uma nota fiscal, quais os procedimentos?
50
b) Questionrio
O questionrio uma tcnica que permite o levantamento de informaes a partir da coleta de informaes de diferentes pessoas afetadas pelo sistema. Segundo Sommerville (2003), nessa tcnica so abordadas questes relacionadas ao que as pessoas na organizao querem, ao que as pessoas consideram como verdade, ao comportamento das pessoas, s caractersticas delas. Procedimentos e equipamentos so levantados.
Um questionrio deve ter questes claras e no ambguas, ter fluxo bem definido, ter administrao planejada em detalhes e ainda levantar antecipadamente as dvidas das pessoas que iro respond-lo.
Sempre que possvel, use o vocabulrio das pessoas que iro responder. Prefira perguntas curtas e simples. Certifique-se de que as questes esto tecnicamente precisas antes de inclu-las no questionrio.
c) Observao direta
A observao direta pode ser utilizada como validao das entrevistas, identificao de documentos, esclarecimento sobre o que est sendo realizado no ambiente atual e a forma como ocorre. No mecanismo de observao direta, o analista observa sem intervir diretamente no processo. importante planejar a observao e isso significa identificar o que deve ser observado, obter aprovao das gerncias apropriadas, obter as funes e nomes das pessoas envolvidas nas aes que sero observadas. Se voc optar por essa tcnica, prepare os usurios com cuidado, esclarecendo a forma como o processo vai ocorrer.
Uma dica interessante aplicar o questionrio em uma amostra de usurios, solicitando a avaliao sobre a estrutura e o contedo do mesmo.
Unidade 2
51
d) Brainstorming
No sentido exato da palavra, brainstorming uma tempestade de ideias. O uso da discusso em grupos, em que a partir dos resultados das tcnicas acima procura-se compreender corretamente documentos, respostas oferecidas pelos usurios, processos existentes, a base para que se chegue a uma boa especificao. Nessa etapa, inicia-se a formatao de um documento que deve conter os requisitos necessrios ao projeto, dentro de um consenso entre desenvolvedores e cliente. Durante o levantamento dos requisitos, tambm estabelecido o escopo do projeto e, ainda, as possveis restries que possam delinear algum tipo de risco no horizonte. Imagine que, durante a entrevista, o cliente diga para voc que no pretende investir em equipamentos e em novos produtos, como um banco de dados. Talvez essa informao se torne uma forte restrio para as possveis solues e deve, portanto, estar presente na documentao. Como, ento, iniciar o levantamento? Quais pontos voc deve levantar? Peters (2001) sugere o levantamento das seguintes informaes:
Figura 2.2 Componentes da anlise do problema Fonte: Peters (2001).
52
Segundo o autor, o levantamento deve ser feito de forma ordenada, dividido em quatro etapas. Primeiro seriam levantados os requisitos relacionados ao ambiente; depois, s funes existentes; em terceiro lugar, ao modo como as funes so executadas; por fim, os requisitos relacionados aos itens que so inseridos e suas transformaes dentro do processo.
Nunca esquea: nessa etapa avalie os problemas na situao atual. Jamais pense na soluo nessa etapa. Concentre-se nas necessidades do cliente.
e) Viabilidade
Antes de voc prosseguir, importante considerarmos um estudo da viabilidade do sistema, se vale a pena ou no sua implementao. Para tanto, fundamental que esteja claro se o sistema contribui para com os objetivos da organizao, se pode ser construdo usando-se a tecnologia existente ou, ainda, se o oramento comporta o que necessrio para sua implementao. Um fator forte nesse momento de decises a possibilidade de integrao do sistema aos demais j existentes, se for o caso. Quando voc se certifica da viabilidade, est protegendo sua empresa e a empresa do cliente. Esse estudo baseia-se nas informaes coletadas durante o levantamento de requisitos. Sommerville (2003) sugere algumas questes para as pessoas da organizao, que podem ser colocadas em um cenrio de discusso: E se o sistema no fosse implementado? Quais so os problemas do processo atual? Como o sistema proposto ir ajudar? Quais sero os problemas de integrao? So necessrias novas tecnologias? Em quais habilidades? Quais recursos devem ser suportados pelo sistema proposto?
Unidade 2
53
Alguns modelos Em nossa midiateca esto disponveis alguns modelos para o levantamento de requisitos que podem servir para futuros levantamentos. D uma olhadinha: Roteiro para Anlise do Problema baseado em Peters (2001).
Seo 3 Especificao de requisitos

A subetapa de especificao de requisitos visa estabelecer um conjunto de requisitos consistentes e sem ambiguidades que possa ser usado como base para o desenvolvimento do software. Nessa etapa tambm comum a negociao para resolver conflitos detectados. A especificao de um requisito de software a descrio de um produto de software, programa ou conjunto de programa especfico que executa uma srie de funes do ambiente de destino (IEEE, 1993). Em resumo, pode-se dizer que na especificao propomos a soluo para o problema do cliente. A especificao pode ser totalmente descritiva (como o caso de alguns documentos da metodologia RUP proposta pela Rational Rose), ou iniciar a construo de modelos (utilizando-se da notao oferecida pela anlise estruturada ou orientada a objetos). Essa deciso depende da metodologia que voc estiver utilizando ou mesmo do grau de maturidade da empresa. O uso de uma especificao textual pode ser feito na forma de relatrios. Peters (2001) sugere um conjunto de quatro questes que devem ser abordadas:
O Rational Unified Process (RUP) um processo de engenharia de software que pretende aumentar a produtividade da equipe oferecendo prticas eficientes executadas por meio de diretrizes, templates e orientaes sobre ferramentas para todas as atividades crticas de desenvolvimento de software.
54
a primeira delas refere-se s funcionalidades que devem ser definidas e elaboradas, e que o sistema deve suportar; a segunda refere-se s interfaces externas do sistema (outros sistemas, equipamentos de hardware); a terceira relaciona-se ao desempenho esperado pelo produto (questes como tempo de resposta durante uma consulta); a quarta relaciona-se a atributos de qualidade (a capacidade do software de ser utilizado em diferentes plataformas, por exemplo) e a restries impostas pelo cliente, pelo ambiente ou pelo prprio desenvolvedor.
Figura 2.3 Questes bsicas ao se escrever uma ERS Fonte: Peters (2001).
A especificao dos requisitos faz parte da documentao do sistema, e pode-se dizer que um de seus principais artefatos. Sabendo disso, necessrio decidir o que deve ser documentado sobre essa etapa. Peters (2001) sugere uma estrutura composta de quatro pontos principais:
Introduo (onde so descritas caractersticas do documento); Descrio global (onde so referenciados perspectivas do produto, riscos associados e funcionalidades requeridas);
Unidade 2
55
Requisitos especficos (apresenta um esqueleto de interfaces e necessidades que devem ser suportadas pelo produto em termos de atributos e performance); Rastreabilidade dos requisitos (que incluem casos de teste para a validao do futuro projeto).
1. Introduo 1.1 Objetivo 1.2 Escopo 1.3 Definies, acrnimos e abreviaes 1.4 Referncias 1.5 Viso geral 2. Descrio global 2.1 Perspectiva do produto 2.2 Funes do produto 2.3 Caractersticas do usurio 2.4 Restries 2.5 Hipteses e dependncias 2.6 Distribuio de requisitos 3. Requisitos especficos 3.1 Interfaces externas 3.2 Requisitos de processo e dados 3.3 Requisitos de desempenho e qualidade 3.4 Requisitos de banco de dados lgico 3.5 Restries de projeto 3.6 Atributos de sistema de software 3.7 Organizao de requisitos especficos 4. Rastreabilidade dos requisitos Apndice ndice remissivo Quadro 2.1 - Estrutura para documentao do sistema Fonte: Elaborao da autora (2008). Perspectiva do produto: seu relacionamento com o sistema maior. Hipteses: indicam como alteraes feitas na ERS afetam sees especficas da ERS (exemplo: quais diagramas de fluxo de dados so afetados ou mudanas de funes ou excluso das mesmas)
Restries de projeto: polticas regulamentares, limitaes de hardware, interfaces com outros aplicativos, operao paralela, segurana e perfil etc.
56
Quer conhecer mais? Se voc estiver interessado nesse modelo oferecido por Peters, leia o captulo 2 do livro: PETERS, J. F.; PEDRYCZ, W. Engenharia de software: teoria e prtica. Rio de Janeiro: Campus, 2001.
Modelos
A especificao tambm pode ser feita na forma de modelos. Mas voc sabe o que um modelo? Um modelo uma representao de alguma coisa do mundo real, uma abstrao da realidade. Alm disso, tem a finalidade de servir como fundamento para o projeto de software, facilitando a compreenso do fluxo de dados e de controle, do processamento funcional, da operao comportamental e do contedo da informao. Nas primeiras etapas do processo de desenvolvimento (levantamento de requisitos e anlise), o engenheiro de software representa o sistema por meio de modelos conceituais, considerando caractersticas do sistema independentemente do ambiente computacional (hardware e software) no qual o sistema ser implementado nas etapas posteriores. Na etapa seguinte, as caractersticas lgicas (caractersticas dependentes de um determinado tipo de sistema computacional) e fsicas (caractersticas dependentes de um sistema computacional especfico) so representadas em novos modelos. A representao dos modelos lgicos e fsicos pode ser feita por meio da anlise estruturada, da anlise essencial ou da anlise orientada a objetos. Os diagramas utilizados nessas metodologias apoiam e facilitam o entendimento da soluo.
Unidade 2
57
Visite o EVA, ferramenta Midiateca. L voc encontrar modelos para a especificao de requisitos sem a utilizao de modelos de anlise totalmente textuais. Leia sobre: Roteiro para Especificao de Requisitos baseado em Peters (2001). Software Requirements Specification (without Use-Case) da metodologia RUP Rational Unified Process.
importante salientar: Ao finalizar a especificao, solicite a assinatura do cliente. Essa assinatura faz com que sua especificao valha como um contrato.
Seo 4 Atividades de apoio

As atividades de documentao, verificao, validao e gerenciamento no so exclusivas da etapa de anlise de requisitos s atividades de apoio, mas estaro presentes em todo o processo de desenvolvimento do software. Dentro do processo de anlise de requisitos, essas atividades no ocorrem de forma obrigatoriamente sequencial, mas sim de forma paralela.
a) Documentao de requisitos
a atividade de representar os resultados da engenharia de requisitos em um documento, contendo os requisitos do software.
b) Verificao e validao de requisitos

Verificar e validar os requisitos uma etapa do processo que no pode ser menosprezada. Na verificao de requisitos, voc avalia se a especificao de requisitos est sendo construda de forma
58
correta, seguindo os padres previamente definidos, evitando requisitos confusos, duplicados, incoerentes ou incompletos. A validao verifica se os requisitos e modelos documentados so o reflexo das reais necessidades e requisitos do cliente. Se voc passar por essa etapa em seu projeto, vai evitar a descoberta de interpretaes errneas ou mesmo deficincias do projeto em etapas futuras. Isso significa uma economia de tempo e dinheiro significativa.
O que voc deve observar na validao?
Sommerville (2003) sugere um check-list. Observe: O sistema fornece as funes que melhor apoiam as necessidades do usurio? H algum conflito nos requisitos? Todas as funes exigidas pelo cliente foram includas? Os requisitos podem ser implementados com o oramento e a tecnologia disponveis? O requisito foi apropriadamente compreendido? A origem do requisito foi claramente estabelecida? O requisito pode ser alterado sem um grande impacto em outros requisitos? Existem algumas tcnicas que apoiam a validao de requisitos: As revises de requisitos pela anlise sistemtica e regular dos requisitos.
Unidade 2
59
O uso da prototipao para validar entradas e sadas, por exemplo, por meio de prottipos no funcionais de telas e relatrios (procure envolver equipe e cliente nessas revises). A gerao de casos de teste para os requisitos, verificando se possvel construir os casos de teste e mesmo testar aquele requisito.
c) Gerenciamento de requisitos
A tarefa de gerenciar requisitos se preocupa com as mudanas nos requisitos que j haviam sido acertadas entre cliente e desenvolvedor. Em outras palavras, preciso: documentar essas mudanas, gerenciar os relacionamentos entre os requisitos e suas dependncias que podem afetar outros requisitos e outros artefatos, produzidos no processo de software; verificar a credibilidade da solicitao de mudana com a empresa.
O gerenciamento deve manter as alteraes de requisitos de forma controlada, tornando as alteraes sustentveis durante o desenvolvimento.
Fazer mudanas nos requisitos no deve ser uma catstrofe: comum a dificuldade de reconhecer todos eles em uma etapa inicial. O importante documentar, relacionar, controlar essas mudanas, repassando-as a todo o processo de desenvolvimento. Agora, para praticar os conhecimentos conquistados nesta unidade, realize as atividades propostas.
60
Sntese
O objetivo do desenvolvedor de software sempre deve ser o fornecimento de um software de qualidade que atenda s necessidades dos clientes. Nesta unidade voc aprendeu que, para obter essa qualidade, preciso realizar a etapa de anlise de requisitos de forma consistente, utilizando metodologias apropriadas que permitam a reviso constante de todo o processo. O uso de diferentes tcnicas, como entrevistas e questionrios durante o levantamento de requisitos, ajuda a variar o foco da observao do projetista. Na especificao, o uso de diferentes modelos pode ser adaptado de acordo com as caractersticas da empresa. As atividades de apoio, como o gerenciamento de requisitos, permitem rastrear alteraes de requisitos e comunicar essas alteraes a toda a equipe envolvida. A engenharia de requisitos um momento de conhecimento, reconhecimento e de exploso de ideias. O bom aproveitamento dessa etapa fundamental; estudos demonstram que o custo de alteraes em etapas posteriores anlise de requisitos pode chegar a 100% do custo original do projeto. Nesta unidade, voc tambm percebeu que a engenharia de requisitos incorpora o uso de modelos. O uso de modelos permite desenvolver o software de maneira previsvel em um determinado perodo, com utilizao eficiente e eficaz de recursos. O modelo ajuda a visualizar o sistema como desejamos, simplificando seu entendimento.
Unidade 2
61
Leia com ateno os enunciados e, aps, realize as questes propostas. 1) Quanto ao requisito, correto afirmar: a) ( ) Um requisito expresso por suas caractersticas funcionais. b) ( ) O requisito de software pode ser expresso por caractersticas implcitas, explcitas e normativas. c) ( ) As caractersticas normativas de um requisito esto relacionadas s suas caractersticas comportamentais. d) ( ) O requisito mais importante em uma anlise o requisito explcito. 2) Na anlise de requisitos, temos as seguintes etapas: ( a ) levantamento ( b ) especificao ( c ) validao ( d ) gerncia Relacione as descries abaixo com a etapa correspondente. a) ( ) Responsvel pelo controle de alteraes de requisitos. b) ( ) Utiliza-se de tcnicas, como observao direta, entrevistas e questionrios, para apurar informaes pertinentes ao processo. c) ( ) Avalia se a especificao de requisitos est seguindo os padres previamente definidos, evitando requisitos confusos, duplicados, incoerentes ou incompletos. d) ( ) Responsvel pela definio de restries, funcionalidades, atributos, interfaces externas e desempenho.
62
3) No texto abaixo voc tem a solicitao para desenvolvimento de software de um cliente proprietrio de uma clnica mdica. A partir do texto levantado com o cliente, preencha o documento de anlise do problema que dar incio documentao do futuro sistema.
Empresa : Clnica Bem-Estar

1) Funo: fomos contratados para analisar seu processo atual e verificar como expandir suas operaes e melhorar seu nvel de servio. Histrico: A clnica, fundada h 5 anos, atua no atendimento clnico peditrico. A clnica possui 34 mdicos cadastrados em diferentes especialidades como: cardiologia, clnica geral, dermatologia etc. Todos os mdicos utilizam internet e e-mail. A faixa etria predominante de 30, 35, 40, 42, 44 e 48 anos. Todos os mdicos so aptos do ponto de vista fsico. O paciente pode ser atendido de forma particular ou por convnios. Os convnios atendidos so o Bruxtr, Vpfzm e UIOlk. Cada mdico faz 3 plantes semanais de 4 horas seguidas; as consultas possuem um intervalo de 30 minutos. Existe a possibilidade de a consulta ser de retorno, nesse caso so apenas 15 minutos. A clnica 24 horas. Cada mdico possui uma agenda preta onde so marcadas as consultas. Na marcao da consulta colocado o nome do paciente, horrio e convnio. Trabalham h 3 anos na clnica com planilhas Excel. A clnica possui 2 atendentes que so responsveis por preencher o cadastro inicial do paciente, que contm nome, endereo, telefone, data de nascimento, convnio. O mdico, ao atender o paciente, preenche sua ficha manualmente, informando peso, altura, idade, motivo da consulta, queixa principal, doenas anteriores, diagnstico, prescrio. A prescrio pode ser a solicitao de exames ou medicamentos com posologia. A clnica possui de 700 a 800 fichas, sendo que cerca de 600 so de atendimento por convnio. O gerente da clnica est ansioso, pois no consegue controlar questes relacionadas ao nmero de pacientes atendidos por convnio e particular, mdicos mais procurados e picos de movimento. Volume de atendimentos: 56 por dia. Outra questo de interesse manter um controle de laboratrios conveniados, pois o mdico poderia indicar o laboratrio j no momento da prescrio.
Unidade 2
63
TEMPLATE PARA REALIZAO DA ANLISE DO PROBLEMA CLNICA BEMESTAR

1) Nome da empresa ______________________________________ 2) Contato ______________________________________________ 3) Descrio do problema
4) Identificao do principal objetivo do cliente
5) Descrio dos usurios do sistema (para cada usurio descreva cargo e possveis funes dentro do processo)
6) Descrio detalhada dos processos existentes (COMO O SISTEMA ATUAL FUNCIONA?) Para marcao da consulta
64
Como funciona o processo de atendimento
7) Itens produzidos no sistema (quais so os relatrios e consultas existentes ou solicitados pelos clientes)
8) Volume de informaes do sistema atual
9) Descrio de situaes consideradas crticas e atores envolvidos
10) Restries do projeto
Unidade 2
65
Saiba mais
Para aprofundar as questes abordadas nesta unidade, pesquise em: SOMMERVILLE, Ian. Engenharia de software. 6. ed. So Paulo: Addison-Wesley, 2003.
66
UNIDADE 3
Anlise estruturada
Reconhecer objetivos e caractersticas inerentes ao uso da modelagem estruturada. Fazer uso de conceitos e diagramas da modelagem estruturada. Compreender e reconhecer uma estrutura que se utilize da modelagem estruturada. Empreender o uso da modelagem estruturada.
Sees de estudo
Seo 1 Seo 2 Seo 3 Seo 4 Anlise estruturada Diagrama de Fluxo de Dados (DFD) Dicionrio de dados Modelagem de dados

Quando se inicia o processo de desenvolvimento de um software, so realizadas tarefas especficas que podem ser estruturadas dentro de um modelo de desenvolvimento (como voc estudou na primeira unidade da disciplina). No incio do processo tem-se a etapa de engenharia de requisitos (assunto estudado na segunda unidade), na qual voc confrontado com as reais necessidades de seu cliente. Ainda que voc esteja ansioso por comear o processo de desenvolvimento e efetivamente iniciar a etapa de codificao, a etapa crucial do processo ainda est por vir: o projeto de desenvolvimento de software. O projeto est contido na etapa de desenvolvimento do software, e nela que voc vai desenhar o modelo da soluo que deve resolver as necessidades apontadas no levantamento de requisitos. Existem diferentes metodologias para cumprir essa etapa, mas as mais conhecidas so a anlise estruturada e a anlise orientada a objetos. Na anlise estruturada, o desenvolvimento do sistema voltado para as funes (processos) que ele deve realizar. Nesta unidade, voc conhecer as notaes e caractersticas especficas utilizadas em uma modelagem estruturada e que so fundamentais em sua documentao.
Seo 1 Anlise estruturada

A anlise estruturada foi desenvolvida nos anos 1970 por Gane, Sarson e De Marco. A tcnica baseada na utilizao de uma linguagem grfica para construir modelos de um sistema, incorporando tambm conceitos relacionados s estruturas de dados.
68
Yourdon (1992) discorre sobre as caractersticas da anlise estruturada: Nesta tcnica, preciso ter em mente que todo o desenvolvimento do sistema voltado para as funes que o sistema deve realizar. O que so essas funes? Imagine o sistema de uma videolocadora. Nele voc tem cadastro de clientes, cadastro de DVDs, relatrio de clientes da locadora, entre outras funes que o sistema deve executar. As funes utilizam e produzem informaes para o ambiente (na funo cadastro do DVD, o atendente faz a entrada de dados, digitando informaes sobre o DVD, como nome do filme, dos atores, do tipo de filme etc.). Essas informaes so repassadas s entidades externas (que pode ser o cliente ou o atendente da locadora) por meio de fluxos de dados ou armazenadas em depsitos de dados (so os depsitos que vo armazenar em seu HD as informaes do cliente, dos DVDs etc.). Retome o exerccio da Clnica Bem-Estar, apresentado na unidade anterior.
Empresa: Clnica Bem-Estar

1) Funo: fomos contratados para analisar seu processo atual e verificar como expandir suas operaes e melhorar seu nvel de servio. Histrico: A clnica, fundada h 5 anos, atua no atendimento clnico peditrico. A clnica possui 34 mdicos cadastrados em diferentes especialidades como: cardiologia, clnica geral, dermatologia etc. Todos os mdicos utilizam internet e e-mail. A faixa etria predominante de 30, 35, 40, 42, 44 e 48 anos. Todos os mdicos so aptos do ponto de vista fsico. O paciente pode ser atendido de forma particular ou por convnios. Os convnios atendidos so o Bruxtr, Vpfzm e UIOlk. Cada mdico faz 3 plantes semanais de 4 horas seguidas; as consultas possuem um intervalo de 30 minutos. Existe a possibilidade de a consulta ser de retorno, nesse caso so apenas 15 minutos.
Unidade 3
69
A clnica 24 horas. Cada mdico possui uma agenda preta onde so marcadas as consultas. Na marcao da consulta colocado o nome do paciente, horrio e convnio. Trabalham h 3 anos na clnica com planilhas Excel. A clnica possui 2 atendentes que so responsveis por preencher o cadastro inicial do paciente, que contm nome, endereo, telefone, data de nascimento, convnio. O mdico, ao atender o paciente, preenche sua ficha manualmente, informando peso, altura, idade, motivo da consulta, queixa principal, doenas anteriores, diagnstico, prescrio. A prescrio pode ser a solicitao de exames ou medicamentos com posologia. A clnica possui de 700 a 800 fichas, sendo que cerca de 600 so de atendimento por convnio. O gerente da clnica est ansioso, pois no consegue controlar questes relacionadas ao nmero de pacientes atendidos por convnio e particular, mdicos mais procurados e picos de movimento. Volume de atendimentos: 56 por dia. Outra questo de interesse manter um controle de laboratrios conveniados, pois o mdico poderia indicar o laboratrio j no momento da prescrio.
Se voc fosse listar alguns dos requisitos funcionais, certamente listaria:
Cadastro de mdicos que possibilite inserir, alterar e excluir os dados dos mdicos da clnica. Cadastro de pacientes que permita inserir, alterar e excluir os dados dos pacientes da clnica. Agenda mdica onde deve ser possvel o agendamento, consulta e excluso do agendamento de consulta de um paciente, com um determinado mdico, em um determinado horrio. Ficha mdica que permita o lanamento e consulta de dados sobre a consulta do paciente.
70
Emisso de relatrio estatstico sobre o atendimento de convnios. Emisso de relatrio estatstico sobre o atendimento por mdicos. Emisso de relatrio estatstico sobre o nmero de atendimentos durante o ano. Cadastro de laboratrios conveniados clnica.
Se fssemos listar os requisitos no funcionais:
O sistema deve operar de forma confivel no lanamento de todos os dados de pacientes e consultas e sua gravao. O sistema deve proteger o acesso s informaes histricas da ficha do paciente, sendo que seu acesso deve ser exclusivo para a equipe mdica O sistema deve ser desenvolvido sobre uma plataforma open source permitindo portabilidade. O sistema deve seguir requisitos de usabilidade para as interfaces, sendo de fcil aprendizado, pois a rotatividade das atendentes grande.
A partir da lista de requisitos, voc pode iniciar o processo de modelagem. Para tanto, necessrio entender alguns conceitos bsicos. A notao da anlise estruturada composta pelos seguintes elementos:

Diagrama de Fluxo de Dados (DFD); dicionrio de dados; especificao dos processos; modelagem de dados (ER).
Nas prximas sees, voc conhecer detalhadamente cada um desses elementos.
Unidade 3
71
Seo 2 Diagrama de Fluxo de Dados (DFD)

Segundo Gane (1983), um Diagrama de Fluxo de Dados (DFD) uma tcnica grfica de representao que permite explicitar os fluxos de informao e as transformaes que so aplicadas, medida que os dados se deslocam da entrada em direo sada.
O DFD permite particionar o sistema, demonstrando seus componentes ativos (como usurios, equipamentos, arquivos) e o interfaceamento de dados que ocorre entre eles.
Para realizar um DFD, so necessrios alguns smbolos que o compem. Conhea cada um:
A bolha ou crculo que representa o processo. O processo um executor de tarefas funes, atividades. Representa tarefas de processamento do sistema. Quando voc colocar nome em um processo, procure utilizar um nome que descreva o que o processo faz. Um exemplo de processo pode ser: Cadastrar Paciente, Cadastrar Mdico, Agendar Consulta. O retngulo representa entidades externas (EE), que representa origens e destinos dos dados que percorrem o sistema. Quando voc pensar em entidade externa, pense que so criadores e/ou consumidores de dados/ informao. Uma EE pode ser uma pessoa, organizao ou outros sistemas que interagem com o sistema para envio e/ou recebimento de informaes. Pode representar a interface entre o sistema e o mundo externo. A EE pode ser ento, no caso da Clnica Mdica, o Paciente, o Atendente, o Mdico. Se na clnica houver um laboratrio que de alguma maneira receba dados da clnica por meio do sistema, ento, neste caso, o Laboratrio pode ser considerado uma EE. A caixa aberta, ou linha dupla preenchida com um rtulo, representa o depsito de dados. Na verdade, so os locais onde ocorre o armazenamento de dados, um repositrio de dados (temporrios ou permanentes). Todas as informaes do paciente como nome, endereo, telefone sero armazenados em seu HD em um depsito de dados. Neste exemplo, um nome adequado para o depsito seria Paciente.
Processo
Entidades externas
Depsito de dados
72
O fluxo de dados expresso por setas rotuladas que interligam os processos e que permitem indicar o caminho seguido pelos dados. O fluxo de dados realiza a comunicao entre os processos, os depsitos e as entidades externas. O fluxo de dados no significa sequncia de um mdulo de programa para outro. Mas a seta indica o caminho pelo qual uma ou mais estruturas de dados devero passar. Quando estamos realizando o processo Cadastrar Paciente, deve existir um fluxo de dados, em que so repassadas do paciente ao processo Cadastrar Paciente as suas informaes cadastrais (nome, endereo etc.).
Fluxo de dados
Quadro 3.1 Smbolos que compem o DFD Fonte: Elaborao da autora (2008).
Acompanhe na figura 3.1, a seguir, o processo Cadastrar Paciente.
Figura 3.1 DFD (processo Cadastrar Paciente) Fonte: Elaborao da autora (2008).
So possveis perguntas que voc pode realizar: Por que Cadastrar Paciente (crculo) est representado como um processo? Resposta: Ele um processo porque representa uma execuo, uma funo que deve ser executada no sistema para que o usurio alcance seu objetivo, que fazer o cadastro do paciente para a clnica. Quem so as entidades externas (retngulo) para esse processo?
Unidade 3
73
Resposta: So todos os consumidores e criadores das informaes que esse processo vai gerar. Observe que, para cadastrar um paciente, necessrio que o paciente informe seus dados. Alm dele, temos a atendente que vai inserir os dados do paciente no sistema. Assim, esse processo tem no mnimo duas entidades externas: Paciente e Atendente. Por que Dados Paciente um depsito de dados no diagrama? Resposta: Todas as informaes do paciente devem ser armazenadas no sistema (se no fosse assim, o paciente teria de informar seus dados a cada consulta na clnica). Para representar a armazenagem dos dados, a notao usada o depsito de dados. Portanto, nesse processo (figura 3.1) os dados do paciente representam um depsito de dados em que as informaes do paciente sero guardadas pelo sistema na clnica. Seria assim: a entidade externa informa seus dados para o processo Cadastrar Paciente (nome, endereo e telefone), a Atendente (entidade externa), por sua vez, informa os dados ao processo Cadastrar Paciente (por meio do fluxo de dados). Aps alimentarem o processo, essas informaes so transformadas e os dados do paciente so armazenados no depsito de Dados Paciente. Observe que na figura 3.1 h um nmero 1 no processo Cadastrar Paciente e um nmero 1 no depsito de Dados Paciente. Esses nmeros so utilizados apenas para organizar o DFD para facilitar sua leitura. Na verdade, so sequenciais e sua utilizao opcional. Na documentao, voc pode se referir ao processo por seu nmero no sendo necessrio escrever todo o nome do processo. Quando se elabora um DFD, faz-se necessria a observao de algumas diretrizes.
74
Lembre-se de que, quando usamos fluxos de dados, estamos representando o deslocamento de informaes. Isso pode acontecer somente entre: um processo e uma entidade externa; dois processos; um processo e um depsito de dados.
Quando voc nomear o processo, procure utilizar verbos no infinitivo. As entidades externas, os fluxos de dados e os depsitos devem ser identificados por substantivos. Existe um fator muito importante em um DFD: ele no um fluxograma, portanto ele jamais deve representar a sequncia em que os processos so ativados. O DFD que apresentado na figura 3.2 bastante genrico e pode deixar margens a dvidas. Quando isso acontece, possvel explodir o DFD em nveis de profundidade diferentes. A deciso do nmero de nveis necessrios depende da complexidade do projeto: quanto maior o nmero de nveis, melhor a descrio do comportamento do sistema.
Mas como ocorre essa exploso em nveis?
Os nveis podem ser descritos como: a) Nvel 0 (Topo) tambm chamado de Diagrama de Contexto. formado por um nico processo que representa o sistema inteiro.
Unidade 3
75
Figura 3.2 DFD Nvel 0 Fonte: Elaborao da autora (2008).
b) Nvel n (Folhas): neste caso, os processos so primitivos, sua descrio fica em um nvel alto, pois as funes so simples, com poucas E/S. Nvel 1 a n-1 (Intermedirios): neste caso, os processos so decompostos em nveis. O n+i a decomposio/particionamento de processos, fluxos e depsitos do nvel i. Em outras palavras: voc pode decompor o DFD de forma granular, chegando a um detalhamento minucioso. Veja o exemplo do DFD Agendar Consulta. Ele pode ser apresentado em um nvel apenas:
Figura 3.3 Agenda Consulta Nvel 1 Fonte: Elaborao da autora (2008).
76
Mas, se voc quiser detalhar esses processos, o DFD oferece mais informaes para o desenvolvedor:
Figura 3.4 DFD Agendar Consulta Fonte: Elaborao da autora (2008).
A figura 3.4 um exemplo da exploso do DFD Agendar Consulta. Agora j possvel perceber que existem pelo menos quatro subprocessos envolvidos no agendamento da consulta:
solicitar agendamento (disparado pela entidade externa EE paciente). verificar cadastro paciente (onde ser verificada a existncia ou no de cadastro do paciente na clnica mdica).
Unidade 3
77
verificar agenda (nela ser verificado o horrio solicitado, o mdico e suas disponibilidades para a consulta). realizar agendamento (processo que efetiva a marcao da consulta, armazenando a informao no depsito de dados).
Dicas para a construo de DFDs

Os DFDs so construdos a partir da lista de funcionalidades propostas para o sistema. a) Escolha nomes significativos para os processos, os fluxos, os depsitos e as entidades externas. Os nomes devem ser facilmente identificados, principalmente pelo vocabulrio do usurio. b) Numere os processos. Em um sistema grande, a numerao pode ser muito til. c) Sempre tenha em mente a facilidade de entendimento do DFD. Se o DFD estiver confuso, refaa-o at que lhe parea suficientemente claro.
A figura 3.5 apresenta um DFD que representa os processos a serem realizados para o controle e faturamento de um sistema de pedidos. Observe que nesse caso temos trs processos envolvidos para a realizao do pedido: dois depsitos de dados (Faturas e Pedidos) e apenas uma entidade externa (Clientes). A comunicao entre processos evolui pela passagem de dados por meio dos fluxos de dados.
78
Figura 3.5 DFD Controle de Pedidos Fonte: Yourdon (1992).
Que tal acompanhar mais um exerccio?
Observe a seguinte situao: voc recebe a misso de desenvolver a modelagem estruturada de um sistema o qual se pretende o desenvolvimento de um controle de pedidos para uma floricultura atacadista. A empresa em questo faz a revenda de flores e folhagens para floriculturas da cidade no tendo venda a varejo. Os requisitos funcionais da floricultura so:
manter o cadastro de seus produtos venda (a venda exclusivamente de flores e folhagens); manter o cadastro de seus clientes; manter o seu controle de pedidos; e controlar o pagamento de pedidos realizado por seus clientes.
79
Unidade 3
O requisito no funcional da floricultura :
a manuteno da simplicidade do cdigo permitindo a facilidade na manuteno.
Cliente Gerente Gerenciar Floricultura
Atendente
Figura 3.6 DFD Nvel 0 Sistema Floricultura Fonte: Elaborao da autora (2008).
Gerente Atendente
Dados Produto Dados Pedido
Cliente
Dados Cliente / Produto
Gerenciar Cadastros
Dados Cliente
Dados Cliente / Produto Dados Produto
Gerenciar Pedidos
Dados Pedido Dados Produto
Dados Cliente
Dados Produto
Dados Pedido
80
MSG Produto Indisponvel
Atendente
Cliente
nome Cliente
MSg Cliente Inexistente
Verificar Existncia Cliente
Dados do Cliente
Cadastrar Dados Cliente
Nome, Endereo, telefone, CPF, etc
Endereo, telefone, cpf, etc 2 Dados do Produto Imprime Pedido Entrega Pedido, produto Pedido, produto
Solicitar Produto
Dados do Produto Cadastrar Produto
Verifica existncia do Produto
cdigo, descrio, preo, quantidade, custo Saldo atual produto Preenche dados do Pedido
Dados do Pedido Detalhes do Pedido
Dados do Pedido
Nome Cliente, tipo produto, quantidade
Unidade 3
81
Seo 3 Dicionrio de dados

O dicionrio de dados uma descrio precisa de todas as informaes presentes no DFD para que usurios e analistas possam compreender todo o modelo de forma simplificada. Quando se constri um DFD, os componentes so identificados por um rtulo nico. Apenas o rtulo apresentado no DFD no define a estrutura dos dados que representaro a informao. Essa definio feita no dicionrio de dados.
Mas o que deve ser descrito no depsito de dados?
Pode-se definir o significado de depsitos, a descrio dos fluxos de dados, a estrutura dos arquivos e a especificao lgica dos processos. As notaes mais diversas podem ser utilizadas para definir as estruturas dos dados, sendo que uma proposta de notao possvel, de acordo com Mazzola (2011), inclui as seguintes informaes: nome o identificador principal do item de dados, do depsito de dados ou de uma entidade externa; e, eventualmente, outros nomes utilizados para o mesmo item; especificao numrico, alfanumrico, data, inteiro, tamanho mximo, formatao, domnio; utilizao em que contexto (onde e como) o item de informao utilizado; descrio uma notao que permita explicitar o contedo do item; informaes complementares a respeito do item de dados, como valores iniciais, restries etc.
82
Observe o exemplo de um dicionrio de dados para o depsito de dados Paciente (figura 3.9).
Depsito
Nome do depsito: Paciente. Especificao: banco de dados cadastrais do paciente, volume aproximado 3500 registros. Descrio: o depsito de dados Paciente deve armazenar todos os dados cadastrais do paciente da clnica tendo como chave o nome do paciente. Utilizao: o depsito ser usado no processo Cadastrar Paciente, Agendar Consulta. Atributos do depsito de Dados Paciente: Nome do atributo: Nome_Paciente. Especificao: campo alfanumrico, tamanho 50, chave primria do depsito de dados. Descrio: nome do paciente. Nome do atributo: Endereo_Paciente. Especificao: campo alfanumrico, tamanho 60 caracteres. Descrio: endereo do paciente. Nome do atributo: Telefone_Paciente. Especificao: campo alfanumrico, tamanho 12. Descrio: telefone do paciente. Nome do atributo: Sexo_Paciente Especificao: campo alfanumrico, tamanho 1, assume os valores F ou M. Descrio: sexo do paciente. Figura 3.9 Exemplo de dicionrio de dados para o depsito de dados do Paciente Fonte: Elaborao da autora (2008).
Seo 4 Modelagem de dados

A modelagem de dados tambm conhecida como diagrama ER (Entidade-Relacionamento). Essa tcnica foi desenvolvida originalmente para dar suporte ao projeto de bancos de dados (CHEN, 1990).
O modelo ER uma tcnica utilizada para representar os dados a serem armazenados em um sistema.
Unidade 3
83
A simbologia utilizada em um diagrama ER composta pelos seguintes elementos:

Uma entidade representa um objeto concreto ou abstrato em que sero armazenadas as informaes. Uma entidade pode ser uma pessoa, uma instituio, elementos do domnio da aplicao (Paciente, Agenda). Quando voc cria uma entidade, ela composta por um conjunto de instncias. Cada instncia uma nica ocorrncia de uma determinada entidade. Em um depsito Paciente, Joo Dirceu uma instncia de Paciente. Os atributos so utilizados para descreverem caractersticas ou propriedades elementares de entidades e relacionamentos. Os atributos representam o contedo de uma entidade. Pensando no exemplo da clnica, alguns atributos so NomePaciente, TelefonePaciente, SexoPaciente etc. Um relacionamento uma abstrao de uma associao entre duas ou mais entidades. Pode haver mais de um relacionamento entre objetos. Um exemplo de relacionamento ocorre quando pensamos que o paciente Almir (uma instncia da entidade Paciente) possui n agendamentos (na entidade Agenda).
Entidade
Atributo
Relacionamento
Quadro 3.2 Simbologia utilizada em um diagrama ER Fonte: Elaborao da autora (2008).
Imagine o sistema da clnica. Quais entidades voc consegue identificar? Com certeza necessrio armazenar os dados do Paciente, os dados e as informaes do Mdico, os dados para o agendamento da consulta, o Agenda_Consultas e os dados da Consulta (informaes do mdico durante a consulta). Assim voc identificou grandes grupos de informao que necessariamente precisam ser armazenados para uso futuro na forma de consultas e relatrios (que so processos que atuaro sobre os dados). A entidade Paciente teria os seguintes atributos.
84
Nome da entidade: Paciente Chave identificadora: Nome Paciente Atributos da entidade: CPF Telefone Endereo Convnio Data de nascimento
Exemplos de instncias do objeto Paciente seriam: Nome: Paulo Lopes Telefone: 88890899 CPF: 483.432.546-65 Endereo: Rua do Pntano 120 Nome: Joana da Silva Telefone: 8887777 CPF: 488.444.449-35 Endereo: Rua do Rio 26
Na figura a seguir, voc pode ver um recorte de um diagrama ER. Observe que a relao entre a entidade paciente que realiza um agendamento na clnica.
Paciente
Figura 3.10 Recorte de um diagrama ER Fonte: Elaborao da autora (2008).
Realiza
Agenda
Se voc pensar na entidade Paciente existente na clnica, pode representar seus atributos por meio da notao grfica. O atributo Nome sublinhado porque considerado que ele uma chave nessa entidade. Cada um dos crculos representa um atributo.
Unidade 3
85
Paciente
NomePaciente
CPF
DataNascimento
Convnio
Figura 3.11 Notao grfica entidade Paciente Fonte: Elaborao da autora (2008).
O que cardinalidade?
Observe os exemplos a seguir. So exemplos de relacionamento, porm sem a indicao do nmero de relacionamentos existentes entre eles.
Cliente Mdico Pedidos Cliente Aloca Atende Contm Tem Filmes Pacientes Produtos Carto
Figura 3.12 Exemplos de relacionamento Fonte: Elaborao da autora (2008).
86
Observe na figura 3.12 as entidades e o relacionamento entre elas:
Cliente (entidade que armazena os dados de um cliente de videolocadora) Aloca Filme (entidade que armazena os dados de filmes na locadora). Mdico (entidade que armazena os dados dos mdicos na clnica) Atende Paciente (entidade que armazena os dados de pacientes na clnica). Pedidos (entidade que armazena os dados de um pedido de compras) Contm Produtos (entidade que armazena os dados dos produtos). Cliente (entidade que armazena os dados de um cliente de um banco) Tem Carto (entidade que armazena os dados da conta e do carto que o cliente possui do banco).
Quando voc identifica quantas vezes cada instncia de uma entidade pode participar do relacionamento, voc est determinando a classe desse relacionamento. A cardinalidade indica o nmero mximo e mnimo de associaes possveis em um relacionamento. Voc pode ter classes de: a) Cardinalidade 1 para 1 (1:1) Quando a cardinalidade de 1 para 1, significa que cada instncia da primeira entidade pode ser relacionada com exatamente uma instncia da segunda entidade. Ou seja, cada cliente tem um carto, como no exemplo a seguir, em que Ana Lopes tem um, e apenas um carto, cujo nmero 23456-7, e o carto tem somente 1 cliente, a Ana Lopes.
Unidade 3
87
Classe 1:1 Tem
Cliente Ana Lopes Jean Bondex Carlos Xion
Carto 234567-9 237987-9 335567-9
Figura 3.13 Cardinalidade 1 para 1 (1:1) Fonte: Elaborao da autora (2008).
b) Cardinalidade 1 para N (1:N) Se a cardinalidade for 1:N, tem-se ento uma situao como a ilustrao a seguir, na qual um cliente pode ter de zero (nenhuma) a n DVDs alocados. A instncia Joo tem trs DVDs (instncias) alocados.
Classe 1:N Aloca 1 (0,n)
Cliente
DVD
Joo Augusto
Tubaro II Madagascar Bob Esponja
Figura 3.14 Cardinalidade 1 para N (1:N) Fonte: Elaborao da autora (2008).
c) Cardinalidade N para N (N:N) A situao N para N representa uma situao de relacionamento de muitos para muitos. Nesse caso, uma instncia da primeira entidade se relaciona com uma ou mais instncias da segunda entidade, que tambm estabelece relacionamento com uma ou mais instncias da primeira entidade. No exemplo a seguir, o funcionrio Joo Augusto pode estar relacionado a diversos projetos. O projeto Folha de pagamento tem alocados vrios funcionrios.
88
Classe N:N Aloca N N
Funcionrios
Projetos Folha de Pagamento Estoque
Joo Augusto
Carlos Xim CRM Contas a Pagar
Figura 3.15 Cardinalidade N para N (N:N) Fonte: Elaborao da autora (2008).
Observe algumas dicas importantes. Identifique, primeiro, quais so as entidades do sistema. Identifique, ento, os atributos para cada entidade. Determine as chaves das entidades: lembre-se de que a chave deve ser um atributo que distinga a instncia de forma nica em relao s outras instncias da entidade: Um exemplo disso o registro do CPF. Cada cidado possui o seu, nico, no existe nenhum outro brasileiro que possua o mesmo nmero. Portanto, o CPF uma excelente chave. Identifique os relacionamentos entre as entidades. Por fim, determine a cardinalidade. Agora pense no caso da Clnica Bem-Estar visto na unidade 2, exerccio das atividades de autoavaliao. Vamos identificar pelos menos trs entidades: Paciente; Mdico; Agenda_Consultas.
89
Unidade 3
Neste caso, o relacionamento seria:

Paciente (1) (0,n) Agenda Consulta (0,n) Mdico (1)
Figura 3.16 Exemplo de cardinalidade Clnica Bem-Estar Fonte: Elaborao da autora (2008).
Um paciente pode ter nenhuma, uma ou vrias consultas agendadas. Mas para cada consulta s haver um paciente e haver relacionado um mdico, mas um mdico pode ter vrias consultas agendadas. Agora, para praticar os conhecimentos conquistados nesta unidade, realize as atividades propostas a seguir.
Sntese
Nesta unidade, voc estudou os principais conceitos adotados nessa metodologia. Durante o estudo, o uso das ferramentas como o DFD, o dicionrio de dados, a descrio do processo e o diagrama ER foi abordado, evidenciando sua importncia na concepo do modelo previsto para a soluo do problema do cliente. O uso do DFD torna clara equipe de projeto e ao usurio a forma como as informaes transitaro nos futuros processos e a transformao sofrida durante sua evoluo. Foi possvel tambm abordar a importncia da normalizao, evitando redundncias na futura base de dados do sistema. A anlise estruturada foi um movimento inicial do uso de uma metodologia de projeto que permitisse documentar o futuro projeto de forma clara e consistente. A evoluo, no entanto, era inevitvel.
90
Leia com ateno os enunciados e, aps, realize as questes propostas. 1) Relacione os conceitos a seguir, observando que uma mesma opo pode se repetir. A. Diagrama de fluxo de dados ( ) Notao utilizada para descrever o contedo e significado de fluxos, entidades externas, processos e depsitos de dados. Notao que permite representar um processo em um DFD. Utilizado para representar o cliente em um DFD. Utilizado para representar um repositrio de dados em um DFD. Permite descrever os fluxos de informao e as transformaes sofridas pelos dados durante a execuo do processo. Utilizado para representar os dados que sero inseridos no processo em um DFD. Utilizado para representar em um DFD uma empresa que participa de alguma maneira no processo, por exemplo, uma instituio bancria em um processo de contas a receber.
B. Dicionrio de dados C. Descrio dos processos D. Fluxo de dados E. Fluxo de dados
( ) ( ) ( ) ( )
F. Depsito de dados
( )
G. Processo
( )
Unidade 3
91
2) Defina a cardinalidade e as entidades existentes para as situaes propostas a seguir. a) Um professor leciona vrias disciplinas em sua universidade. b) A universidade emprega vrios funcionrios. c) Os funcionrios so lotados em um departamento. d) Um aluno pode estar matriculado em nenhuma ou vrias disciplinas e uma disciplina pode ter vrios alunos nela matriculados. Exemplo de resoluo: um equipamento de audiovisual alocado a um professor. Equipamento audiovisual Professor (0,1) (0,1)
Saiba mais
Para conhecer um pouco mais sobre a anlise estruturada, voc deve dar uma olhadinha nos seguintes livros: DEMARCO, Tom. Anlise estruturada e especificao de sistema. Rio de Janeiro: Campus, 1989. YOURDON, Edward. Anlise estruturada moderna. Rio de Janeiro: Campus, 1992.
92
UNIDADE 4
Viso geral da UML

Compreender as diferenas fundamentais existentes entre a anlise estruturada e a anlise orientada a objetos. Perceber as diferentes vises da UML e os diagramas oferecidos para viabilizar seu entendimento. Conhecer a histria e o surgimento da linguagem de modelagem UML e suas diferentes possibilidades de aplicao.
Sees de estudo
Seo 1 Seo 2 Seo 3 Seo 4 Seo 5 O paradigma da orientao a objetos A origem das linguagens de modelagem As cinco vises da UML Diagramas da UML Ferramentas

Nesta unidade voc vai iniciar seu estudo acerca da anlise orientada a objetos. Para compreender esse conceito, necessrio que voc perceba suas diferenas em relao anlise estruturada e suas diversas vises relacionadas ao processo de desenvolvimento. Voc pode usar a UML para modelar vrias fases de um sistema, desde a anlise do problema at a gerao do cdigo. A linguagem pode ser aplicada em qualquer tipo de sistema de desenvolvimento de software,em sistemas mecnicos de engenharia ou na organizao de processos de uma organizao. A UML hoje uma das abordagens mais utilizadas no mundo, esse sucesso se deve, em parte, por sua padronizao, facilidade de reutilizao, flexibilidade e possibilidade de abstrao de dados. A partir desta unidade voc vai submergir, aos poucos, no mundo orientado a objetos, usando conceitos e ferramentas.
Seo 1 O paradigma da orientao a objetos

Como j apresentado, a principal nfase sempre dada aos procedimentos. Os procedimentos so implementados em blocos e a comunicao entre eles se d pela passagem de dados. Na orientao a objetos, os dados e procedimentos fazem parte de um s elemento bsico. Isso significa que se encontram encapsulados em um s elemento.
94
ANLISE ESTRUTURADA DADOS + FUNES
ANLISE ORIENTADA A OBJETOS ATRIBUTOS DADOS + MTODOS FUNES
Figura 4.1 Viso comparativa da anlise Fonte: Pacheco (1994).
Pode-se dizer que, na viso estruturada, a perspectiva adotada a de um algoritmo, em que o bloco principal de construo do software o procedimento ou a funo. A viso do desenvolvedor ser a de decompor algoritmos maiores em menores. Assim, voc pode dizer que a anlise estruturada desenvolve uma viso de desenvolvimento baseada em um modelo entradaprocessamento-sada. Com o passar do tempo, a manuteno pode tornar-se difcil, pois o sistema totalmente construdo a partir do foco do algoritmo. Quando se adota a viso orientada a objetos, o bloco de construo do software passa a ser o objeto ou a classe. Mas voc sabe o que um objeto?
O objeto uma abstrao de conjunto de coisas do mundo real; pode ser uma mquina, uma organizao, um carro, uma passagem de nibus.
A figura 4.2 apresenta coisas do mundo real, e portanto so objetos sob o ponto de vista da orientao a objetos.
Unidade 4
95
Figura 4.2 - Objetos Fonte: Elaborao da autora (2010).
E uma classe? A classe pode ser vista como a descrio de um tipo de objeto, com propriedades semelhantes (atributos), o mesmo comportamento (operaes), os mesmos relacionamentos com outros objetos e a mesma semntica. Por exemplo: a classe Aluno de uma escola, com um conjunto de alunos que apresentam as mesmas informaes. Todos os objetos so instncias de classes. A classe, por sua vez, deve descrever as propriedades e os comportamentos daquele objeto.
Uma classe descreve um grupo de objetos.
Observe que os objetos apresentados na figura 4.2 podem ser agrupados por apresentarem atributos, caractersticas ou comportamentos semelhantes. Isso permite que sejam criadas as classes Animais, Edificaes e Transportes.
96
Classe Animais
Classe Edificaes
Classe Transportes
Figura 4.3 Agrupamento de objetos em classes Fonte: Elaborao da autora (2010).
Observe que possvel perceber atributos comuns assim como caractersticas e comportamentos e, por esse motivo, possvel agrupar esses objetos. Veja que na classe Animais pode se indicar alguns atributos como espcie, data nascimento, nome que so comuns a qualquer animal, assim como podemos indicar comportamentos comuns como comer, correr, dormir. Essa proximidade o primeiro passo na identificao de uma classe. A orientao a objetos pressupe que o mundo composto por objetos, sendo um objeto uma entidade que combina estrutura de dados e comportamento funcional. No paradigma orientado a objetos, os sistemas so estruturados a partir dos objetos que existem no domnio do problema, isto , os sistemas so modelados como um nmero de objetos que interagem. Mas o que voc entende pela expresso orientado a objetos? Se voc teve dificuldade em conceituar, no se preocupe. Mesmo experts nessa rea passaram anos engalfinhando-se, tentando esclarecer seu significado. Pages-Jones (2001), lista seus principais conceitos, que juntos explicam o mtodo:
Unidade 4
97
Encapsulamento o agrupamento de ideias afins em uma unidade. Permite ao programador esconder os detalhes da representao dos dados por trs de um conjunto de operaes (como a interface). Reflita sobre o seguinte: voc sabe como funciona internamente o seu micro-ondas? Mas voc sabe como lig-lo, program-lo e deslig-lo. Voc interage com o micro-ondas por meio de sua interface sem se preocupar com os detalhes da implementao: esse um exemplo de encapsulamento. Ocultao de informaes e implementaes exatamente o uso do encapsulamento que restringe a visibilidade de detalhes e informaes que ficam internas estrutura do encapsulamento. Mensagens solicitao de um objeto para que outro objeto efetue uma de suas operaes. Os objetos mandam mensagens entre si. As mensagens resultam na chamada de mtodos que executam as aes necessrias. Classes as classes so conjuntos de objetos com caractersticas semelhantes. Herana o mecanismo de herana permite que uma classe seja criada a partir de outra classe (superclasse), e a nova classe (subclasse) herda todas as suas caractersticas. Poliformismo a propriedade segundo a qual uma operao pode se comportar de modos diversos em classes diferentes.
Sistemas orientados a objetos so flexveis a mudanas, possuem estruturas bem conhecidas e oferecem a oportunidade de criar e implementar componentes totalmente reutilizveis.
Quer conhecer mais? Para saber um pouco mais sobre orientao a objetos e suas caractersticas, leia o captulo 1 do livro Fundamentos do desenho orientado a objetos, de Pages-Jones, editora Makron Books, 2001.
98
Seo 2 A origem das linguagens de modelagem

As linguagens de modelagem orientada a objetos comearam a surgir na dcada de 1970. Nessa dcada, tambm apareceram no mercado computadores mais modernos e acessveis, iniciando uma grande expanso computacional. No incio da dcada de 1990, surgiram as primeiras metodologias orientadas a objeto. Muitos foram os mtodos oferecidos como soluo para especificao de projetos orientados a objetos, mas alguns se destacaram tornando-se referncia por suas caractersticas:
O mtodo Booch (1993) Considerado expressivo nas fases de projeto e construo, apresenta o projeto como um conjunto de vises, cada viso pode ser descrita por modelos e diagramas. A simbologia do modelo bastante complexa. O mtodo OOSE (Object Oriented Software Engineering), de Jacobson (1993) Excelente no controle da captura de requisitos, anlise e projeto de alto nvel. Utiliza-se de use cases para definir os requisitos iniciais do sistema, vistos por um ator externo. O mtodo OMT (Object Modeling Technique) de Rumbaugh (1995) Bastante usado para anlise e sistemas de informaes com uso intensivo de dados. Possui um forte foco para o teste de modelos, baseado nas especificaes da anlise de requisitos do sistema.
Alm dos mtodos citados, existiam muitos outros; cada mtodo utilizava-se de notaes diferentes. Com o passar do tempo, a percepo de que os mtodos poderiam ser complementares a partir de suas melhores caractersticas fez com que os trs autores se unissem na especificao de um novo mtodo, proporcionando estabilidade e uma linguagem clara e madura que auxiliasse com problemas que, provavelmente, nenhum dos trs mtodos poderia resolver.
Unidade 4
99
Qual a origem da Linguagem de Modelagem Unificada (UML)?
Em 1994, nas dependncias da Rational Software, iniciou-se a juno do mtodo Booch e OMT. Em 1995, Jacobson se uniu equipe e decidiram a incorporao do mtodo OOSE. A primeira verso (0.9) da UML foi lanada ao mercado em 1996. A partir desse lanamento, profissionais da rea contriburam com crticas e sugestes ao modelo. Empresas, como a HewlettPackard, I-Logix , DEC, IBM, Microsoft, Oracle Texas, entre outras, investiram maciamente no aperfeioamento do mtodo. Os pesquisadores Booch, Jacobson e Rumbaugh foram os idealizadores do projeto, mas o produto final em sua verso 1.3 foi resultado de um trabalho de equipe por meio da participao de diversos colaboradores, contribuindo com suas experincias e seu ponto de vista. Em 1997, a UML foi aprovada como padro pela Object Management Group (OMG). A UML uma linguagem completamente visual. Por meio de elementos grficos ela permite a representao de conceitos da orientao a objetos utilizados na estrutura de elaborao de um projeto de software. Voc pode representar o sistema por diferentes perspectivas dependendo do diagrama que voc utilizar. Cada um de seus diagramas possui uma forma predeterminada de desenhar o elemento, uma semntica que define o significado desse elemento e onde ele pode ser utilizado. No existe dependncia de linguagem no uso da UML ou de processos de desenvolvimento. Ela pode servir para qualquer linguagem que o desenvolvedor venha a utilizar. Alm de ser utilizada como uma linguagem de especificao para construir modelos, a UML oferece a possibilidade de conectar seus modelos a diversas linguagens como JAVA, C++, Visual Basic e, inclusive, bancos de dados. Em outras palavras, voc pode gerar cdigo a partir de um modelo UML em uma linguagem de alto nvel como JAVA.
100
Seo 3 As cinco vises da UML

Na UML todas as abstraes de um sistema so organizadas em modelos, no qual cada um deles representa uma viso do sistema. Se voc olhar para o desenvolvimento como um todo, perceber etapas bem definidas. Cada etapa pode ser representada por meio de diagramas e modelos de elementos, de forma a proporcionar ao projetista uma viso eficiente e completa daquela etapa. Ento, voc pode assumir que as vises mostram diferentes aspectos do sistema que est sendo modelado. A viso vai apresentar um aspecto particular do sistema. Segundo Bezerra (2002), a UML pode ser apresentada por cinco vises:
Viso de casos de uso Descreve a funcionalidade do sistema desempenhada pelos usurios. A viso use case central, pois seu contedo fundamental para a composio das demais vises do sistema. Viso de projeto So enfatizadas as caractersticas do sistema que do suporte estrutural e comportamental. Viso de implementao Abrange o gerenciamento de verses do sistema construdas por meio do agrupamento de mdulos e subsistemas. Viso de implantao Corresponde distribuio fsica do sistema em seus subsistemas e a conexo entre essas partes. Viso de processo Esta viso enfatiza as caractersticas da concorrncia, sincronizao e desempenho do sistema.
O uso das vises durante o projeto depende do tipo de projeto a ser construdo. A viso do processo, por exemplo, irrelevante se o sistema for construdo sobre apenas um processo. Se o sistema composto por apenas um mdulo, redundante a utilizao da viso de implementao.
Unidade 4
101
A empresa decide pela escolha das vises que sero contempladas e, consequentemente, os diagramas, que sero desenvolvidos no projeto a partir do tipo de domnio do projeto, modelo de desenvolvimento, riscos, restries e caractersticas do processo.
Seo 4 Diagramas da UML

Um diagrama procura representar graficamente a projeo de um sistema. Alguns elementos aparecem em mais de um diagrama, alguns em todos, outros em nenhum. A UML possui nove diagramas (Furlan, 1998): a) Diagrama de casos de uso descrevem a funcionalidade do sistema percebida por atores externos. O ator (um usurio, um equipamento, uma organizao) interage com o sistema. b) Diagrama de classes representa a estrutura esttica do sistema, as classes, os relacionamentos entre suas instncias (objetos), restries e hierarquias. c) Diagramas de interao formado por: Diagramas de sequncia: mostram a colaborao dinmica entre um nmero de objetos. O objetivo principal mostrar a sequncia de mensagens enviadas entre objetos. Diagramas de comunicao: tm o mesmo propsito dos diagramas de sequncia. So desenhados como diagramas de objetos, onde so mostradas as mensagens trocadas entre os objetos. d) Diagramas de estados mostram as sequncias de estados do objeto a partir dos estmulos recebidos, suas respostas e aes. uma variao dos diagramas de
102
estado, em que a maioria dos estados estado de ao e a maioria das transies ativada por concluses das aes. e) Diagramas de implementao composto por dois diagramas: Diagrama de componentes: so mostradas as dependncias entre componentes de software (cdigofonte, cdigo binrio e componentes executveis). Diagrama de implantao: mostra elementos de configurao do processamento em tempo de execuo, os componentes de software, processos e dispositivos fsicos. Os diagramas da UML podem ser situados a partir de suas cinco vises:
VISO DE PROCESSO Utiliza os mesmos diagramas da viso de projeto VISO DE IMPLANTAO Diagrama de estados Diagrama de atividade Diagrama de implantao Diagrama de sequncia Diagrama de colaborao
VISO DE CASOS DE USO Diagrama de casos de uso Diagrama de estados Diagrama de atividade Diagrama de sequncia Diagrama de colaborao
VISO DE IMPLEMENTAO Diagrama de componentes Diagrama de estado Diagrama de atividades Diagrama de sequncia Diagrama de colaborao
VISO DE PROJETO Diagrama de classes Diagrama de objetos Diagrama de estados Diagrama de atividade Diagrama de sequncia Diagrama de colaborao
Figura 4.2 As 5 vises dos diagramas da UML Fonte: Booch (2000).
Unidade 4
103
Os aspectos estticos do sistema so capturados pelos diagramas de classes, de objetos e de componentes; os aspectos dinmicos, pelos diagramas de casos de uso, de estado, de atividade, de seqncia e de colaborao. O modelo funcional suportado pelos diagramas de componente e execuo.
Seo 5 Ferramentas
Para modelar um sistema utilizando a notao UML, fundamental que voc utilize uma ferramenta que automatize o mtodo.
Como a UML utiliza-se de uma notao grfica, uma boa ferramenta agiliza o processo de construo e recuperao da informao.
A escolha de alguma dessas ferramentas fundamental para que voc continue seus estudos.
As ferramentas disponveis subdividem-se na categoria software livre e demos (ferramentas pagas que oferecem 30 dias para avaliao). A seguir esto listadas algumas delas:
a) Software livre:
Orqudea uma ferramenta case, que possui as seguintes funcionalidades: construo de diagrama de classes e de diagramas de sequncia na notao UML, gerao e leitura de cdigo C++; gerao de documentao web em HTML ou HTM.
104
EclipseUML uma plataforma aberta para integrao de ferramentas criada por uma comunidade aberta de provedores de ferramentas. A IDE Eclipse foi criada sobre o paradigma Open Source baseada na Common Public License. Omondo EclipseUM L um plugin para a Eclipse que auxilia na construo de diagramas UML. Com esse plugin, voc pode criar diagramas de classe, sequncia, estados, use cases, atividades etc. Alteraes no diagrama automaticamente se refletem no cdigo-fonte e viceversa.
b) Verses demo:
Rational Rose Ferramenta de modelagem que suporta todos os diagramas previstos na linguagem de modelos UML. Seu custo extremamente alto, sua grande vantagem que ela pertence a Rational, originalmente criadora da linguagem UML. Enterprise Architect (EA) Ferramenta da Sparxsystems da Austrlia, suporta todos os diagramas previstos pela UML e toda notao da OMG. Gera cdigos e engenharia reversa para manuteno dos modelos. Apresenta uma interface mais amigvel e simples de se usar. Poseidon Baseada no mesmo engine do ArgoUML, mas com melhorias. Possui uma Comunity Edition gratuita. No permite funcionalidades de impresso de diagramas, mas possibilita a exportao das imagens dos diagramas.
A partir da prxima unidade, voc vai iniciar a confeco de diagramas, sendo necessrio o uso de uma ferramenta. Todas as ferramentas apresentam, nas respectivas pginas de download, tutoriais e manuais de instalao e utilizao.
Na midiateca voc tambm encontra documentao sobre algumas das ferramentas.
Unidade 4
105
Quer conhecer mais? Se voc quer aprofundar seu conhecimento sobre as diferentes vises da UML, leia o captulo 2, Introduo a UML, do livro UML: guia do usurio, de BOOCH, RUMBAUGH e JACOBSON, editora Campus, 2000.
Agora, para praticar os conhecimentos conquistados nesta unidade, realize as atividades propostas a seguir.
Sntese
Voc estudou as diferenas existentes entre a anlise estruturada e a anlise orientada a objetos. Voc percebeu que a UML surgiu a partir da evoluo de outros mtodos orientados a objetos e que, de certa maneira, complementaram-se dentro de uma linguagem de modelagem padronizada. Ao estudar a unidade, apresentaram-se as diferentes vises que, de diferentes formas, apoiam os projetistas na melhor visualizao de todas as etapas do ciclo de desenvolvimento do software. Alm da introduo conceitual, da anlise orientada a objetos e UML, tambm foram apresentadas algumas ferramentas que suportam o mtodo.
106
Leia com ateno os enunciados e, aps, realize as questes propostas. 1) correto afirmar que (pode haver mais de uma afirmativa correta): a) ( ) A anlise estruturada possui como fundamento a viso da funcionalidade. Assim, a viso que se impe ao modelo o processamento dos dados. Na anlise orientada a objetos, dados e mtodos so vistos como uma entidade nica, preocupando-se com propriedades e comportamentos do objeto. A anlise estruturada possui como fundamento a viso do comportamento do processo. Assim, a viso que se impe ao modelo o processamento dos dados. A anlise orientada a objetos construda a partir de objetos. As classes so instncias do objeto.
b) ( )
c) ( )
d) ( )
2) Identifique os elementos a seguir com C para classe e O para objetos. a) ( ) b) ( ) c) ( ) d) ( ) e) ( ) Caixa Imposto pago Joo da Silva Valor Venda Cliente
3) Observe os conceitos a seguir e realize as devidas inseres. Encapsulamento Herana Poliformismo Mensagens
a) ___________ pode explicar situaes nas quais pode haver vrias formas de fazer uma determinada coisa. b) ___________ permite que detalhes internos sejam escondidos. c) ___________ especifica informaes a serem passadas para a operao que deve ser executada por um objeto receptor. d) Voc define uma classe chamada Conta (para um sistema bancrio) com caractersticas e comportamento genrico. Posteriormente, voc define duas classes, chamadas Poupana e Conta_Corrente; cada uma delas possui propriedades especficas que a outra no possui, mas agregam a elas o comportamento genrico da classe Conta. Isso chamado de ___________.
Unidade 4
107
4) As vises da UML permitem o uso de diferentes diagramas, adaptando o uso do diagrama s necessidades do projeto. Relacione conceitos e diagramas utilizados ao tipo de viso associado: A. Viso de casos de uso B. Viso de projeto C. Viso de implementao D. Viso de implantao E. Viso de processo a) ( ) Descreve a funcionalidade do sistema desempenhada pelos usurios. A viso representada por meio dos diagramas de classe, de objetos, de estados, de atividade, de sequncia e de colaborao. Corresponde distribuio fsica do sistema em seus subsistemas e a conexo entre essas partes. Abrange o gerenciamento de verses do sistema, construdas por meio do agrupamento de mdulos e subsistemas. A viso representada por meio dos diagramas de casos de uso, de estados, de atividade, de sequncia e de colaborao. Enfatiza as caractersticas da concorrncia, sincronizao e desempenho do sistema. So enfatizadas as caractersticas do sistema que do suporte estrutural e comportamental.
b) ( )
c) ( )
d) ( )
e) ( ) f) ( ) g) ( )
Saiba mais
Para aprofundar as questes abordadas nesta unidade, voc poder pesquisar em: GILLEANES, T. A. Guedes. UML: uma abordagem prtica. So Paulo: Novatec, 2004.
108
UNIDADE 5
Modelagem de casos de uso

Compreender a importncia da utilizao de casos de uso para identificao clara dos objetivos do usurio. Entender o significado dos diferentes elementos existentes em um caso de uso. Reconhecer meios para identificar atores e casos de uso. Compreender o mecanismo de documentao e sua importncia na descrio dos casos de uso.
Sees de estudo
Seo 1 Seo 2 Seo 3 Seo 4 O que so casos de uso? Como identificar os atores? Relacionamentos entre casos de uso e atores Identificando casos de uso

Nesta unidade, voc vai iniciar o estudo sobre os diagramas oferecidos na UML e suas representaes utilizadas na modelagem orientada a objetos. Este estudo inicia com os casos de uso que representam o eixo central do modelo, pois descrevem a sequncia de interaes realizadas pelo sistema que visam prover algum valor mensurvel ao usurio do sistema. O caso de uso permite mapear o escopo do sistema facilitando a comunicao com o usurio do sistema e facilitando a gerncia do projeto. Mas, para descrever o caso de uso, no suficiente concebermos apenas o diagrama de caso de uso, preciso entender todos os seus elementos e sua documentao. Nesta unidade, voc vai iniciar seu processo de aprendizagem identificando e construindo os casos de uso necessrios para descrever essa viso do projeto.
Seo 1 O que so casos de uso?

Um sistema sempre interage com usurios, outros sistemas ou equipamentos. Todos eles esperam pelos resultados dessa interao que normalmente so previsveis ou pelo menos deveriam ser. Um caso de uso procura documentar as aes necessrias, os comportamentos e as sequncias para que o resultado esperado pelo usurio ocorra. Ento voc pode dizer que modelo de casos de uso modela os requisitos funcionais do sistema. Antes de iniciar a definio dos casos de uso, voc deve estar consciente dos requisitos funcionais e no funcionais necessrios ao sistema
110
Como o caso de uso no especifica detalhes de implementao, voc vai, na verdade, pensar em como o sistema ser utilizado. Agora imagine a seguinte situao: voc realizar o projeto usando UML para uma pequena videolocadora. Nesse pequeno projeto, os requisitos funcionais listados so:
O gerente deseja cadastrar seu acervo de DVDs com informaes gerais sobre cada filme, como: nome do filme; durao; diretor; principais atores; gnero; idiomas disponveis. fundamental que o atendente possa realizar o cadastro de clientes possibilitando o cadastro de endereo, telefone do cliente e trs possibilidades para digitao de nomes de pessoas autorizadas para retirar DVDs. necessrio que o sistema permita o controle de entrega e recebimento dos DVDs. O gerente deseja um relatrio estatstico dos DVDs mais locados Deve ser possvel um relatrio de consulta dos DVDs em atraso. Relatrio que apresente os 50 maiores clientes da locadora.
Agora tente identificar os casos de uso. Ento, quantos voc encontrou? Voc pode listar os seguintes casos de uso: Gerenciar cliente ser responsvel por cadastro, consulta, excluses e alteraes de dados cadastrais do cliente. Gerenciar filmes ser responsvel por cadastro, consulta, excluses e alteraes de dados dos DVDs da videolocadora.
Unidade 5
111
Gerenciar locaes deve permitir o controle de entregas e recebimentos dos DVDs e clculo de multas, quando necessrio. Gerenciar relatrios deve possibilitar a impresso dos relatrios estatsticos de locao, maiores clientes e controles de atraso de entrega. Se voc representar graficamente os casos de uso, ter os mesmos representados por um crculo. Veja a figura 5.1. Retome o exemplo da videolocadora. A figura 5.1 mostra trs casos de uso possveis para esse projeto.
gerenciar cliente
gerenciar locaes
gerenciar filmes
Figura 5.1 Casos de uso de uma videolocadora Fonte: Elaborao da autora (2008).
O modelo de casos de uso composto por casos de uso, atores e relacionamentos. O caso de uso descreve um conjunto de sequncias, cada um representando a interao entre atores com o prprio sistema. Esses comportamentos so funes em alto nvel que voc vai visualizar, especificar, construir e documentar tentando mostrar de forma clara o comportamento pretendido do sistema durante a anlise de requisitos.
Quando voc nomear o caso de uso, esse nome deve ser nico dentro do projeto, diferenciando-o dos demais casos de uso. Voc pode usar qualquer caractere textual no nome do caso de uso, mas evite o uso de dois-pontos. Procure utilizar expresses verbais ativas.
112
O que o diagrama de casos de uso?
Se um caso de uso sempre iniciado a partir do momento em que um ator envia sua mensagem (estmulo), o diagrama de casos de uso criado para visualizar os relacionamentos entre atores e casos de uso. O diagrama de casos de uso pode ser utilizado para representar um caso de uso e seus relacionamentos, todos os casos de uso para um ator ou ainda todos os casos de uso a serem implementados em um ciclo de desenvolvimento. A notao do diagrama faz uso de um boneco para identificar o ator, abaixo do boneco inserido o nome do ator cliente. A elipse identifica o caso de uso, o nome do caso de uso pode ser escrito no interior ou externo a elipse (caso de uso: gerenciar cliente). A linha reta indica o relacionamento de comunicao entre o ator e o caso de uso.
gerenciar cliente
cliente
Figura 5.2 Caso de uso gerenciar cliente Fonte: Elaborao da autora (2008).
Seo 2 Como identificar os atores?

Um ator representa um conjunto coerente de papis que os usurios de casos de uso desempenham quando interagem com esses casos de uso. Um ator pode representar um papel que um ser humano, um dispositivo de hardware ou at outro sistema que desempenha alguma interao com o sistema (BOOCH, 2000).
Unidade 5
113
O ator troca informaes com o sistema, ele no faz parte do sistema apenas interage com ele. Um ator pode participar de vrios casos de uso. Voc pode ter em seu sistema diferentes tipos de atores:

pessoas (professor, aluno, secretria, coordenador); organizaes (empresa fornecedora, bancos, receita federal); outros sistemas (mdulos que venham a interagir com seu sistema, como contas a pagar, credirio, estoque); e equipamentos (coletor de dados, leitora de cdigo de barras, balanas).
Quando voc escolhe o nome do ator lembre-se de que ele representa um papel no sistema, nunca utilize nomes pessoais. Imagine: um indivduo pode representar o papel de funcionrio em alguns momentos e em outros pode representar o papel de gerente.
Nesse caso, nomes que representam o papel poderiam ser Gerente, Professor, Vendedor, Fornecedor.
Mas como identificar os atores do sistema?
Primeiro voc deve identificar quais as fontes de informao que sero processadas e quais os destinos das informaes geradas. Sempre avalie quais os departamentos da empresa que sero afetados e que potencialmente podem ter atores que interagem com o sistema.
114
Bezerra (2002) oferece algumas dicas na forma de perguntas que apoiam a descoberta dos atores do sistema: Que rgos, empresas ou pessoas utilizaro o sistema? Que outros sistemas iro se comunicar com o sistema a ser construdo? Algum deve ser informado de alguma ocorrncia no sistema? Quem est interessado em um certo requisito funcional do sistema?
cliente
gerente
leitora_cdigo_barras
sistema_financeiro
Figura 5.3 Exemplos de atores Fonte: Elaborao da autora (2008).
ud Use Case Model
Voc consegue listar os atores da videolocadora? Pense um pouco sobre o assunto. Os possveis atores so:

Atendente
Gerente
o atendente; o gerente; o cliente.

Cliente
Figura 5.4 Diagrama de atores da videolocadora Fonte: Elaborao da autora (2008).
Unidade 5
115
S definir os atores no o suficiente, voc deve descrever caractersticas e responsabilidades desses atores. Caractersticas importantes podem ser cargos, funes, grau de escolaridade, permisses de acesso, frequncia de uso, conhecimento em informtica, conhecimento no processo do negcio. Os atores podem ser divididos em primrios e secundrios, o ator primrio inicia a sequncia de aes de um caso de uso. J os atores secundrios supervisionam, operam, mantm ou auxiliam na utilizao do sistema.
Nro. Ator Descrio Definio indivduo que realiza locaes de DVDs na videolocadora. Frequncia de uso dirio, semanal Conhecimento em informtica relativo, alguns clientes possuem outros no 1 Cliente Conhecimento no processo sim, grande maioria possui uma noo clara do funcionamento do processo de locao de DVDs Grau de escolaridade desde fundamental a ps-graduao Permisses de acesso deve ser disponibilizado ao cliente a consulta ao acervo. Definio funcionrio da videolocadora responsvel por operaes de abertura, fechamento, controle de funcionrio, controle de compras e pagamentos da videolocadora. Frequncia de uso dirio 2 Gerente Conhecimento em informtica aplicativos Word, Browsers, Windows XP Conhecimento no processo domina todo o processo do negcio Grau de escolaridade graduao Permisses de acesso ter acesso a todas as funcionalidades do sistema Quadro 5.1 - Exemplo de descrio de atores Fonte: Elaborao da autora (2008).
A descrio detalhada do ator ajuda na definio de perfis que influenciam no projeto da interface.
116
Seo 3 Relacionamentos entre casos de uso e atores

Para que um caso de uso seja executado, necessria a existncia de atores que interajam com o caso de uso. Essa interao ocorre por meio dos relacionamentos de comunicao, incluso, extenso e generalizao.
O que relacionamento de comunicao?
Quando se usa um relacionamento de comunicao, voc estar representando quais atores esto associados a um caso de uso. Isso significa que o ator vai interagir trocando informaes com o caso de uso. o relacionamento mais comum onde ocorre troca de informaes.
cliente
gerenciar filmes
atendente
Figura 5.5 Exemplo de relacionamento de comunicao Fonte: Elaborao da autora (2008).
O ator cliente oferece informaes ao caso de uso como nome e ttulo do filme que deseja, j o ator atendente oferece ao caso informaes como o cdigo. Agora observe o diagrama geral de casos de uso a partir dos requisitos funcionais apontados na seo 1. O diagrama geral apresenta de forma genrica os casos de uso solicitados sendo que todo o relacionamento existente de comunicao.
Unidade 5
117
cd locadora
Gerenciar filmes
Atendente
Gerenciar cliente
Cliente
Gerenciar Locaes
Gerente Gerenciar Relatrios
R ealizar cobrana
Figura 5.6 Diagrama de casos de uso da videolocadora Fonte: Elaborao da autora (2008).
O que relacionamento de extenso?
Os casos de uso possuem na maioria das vezes um fluxo principal e vrios fluxos alternativos. Os casos de uso secundrios so muitas vezes inseridos no caso de uso por meio do relacionamento de extenso. O relacionamento de extenso deve ser usado para representar:
um comportamento opcional;
118
um comportamento que s ocorre sob certas condies (alarmes, por exemplo); em fluxos alternativos dependentes da escolha de um ator.
Para entender melhor, considere a seguinte situao: Quando o ator decide executar o caso de uso extensor, ele executa e aps sua execuo retorna ao caso de uso estendido. Voc pode comparar um caso de uso extensor a uma funo que voc desenvolve em um algoritmo de programao. Veja a seguinte situao: Em nosso estudo de caso da videolocadora, o contratante do projeto deseja a insero no cadastro do cliente das preferncias do cliente, por exemplo, as preferncias do cliente a respeito do tipo de filme (comdia, romance, fico etc.), diretores, atores. Para voc inserir esta funcionalidade na modelagem dos casos de uso segue o seguinte raciocnio:
O caso de uso gerenciar cliente vai descrever a sequncia de interaes para inserir os dados cadastrais do cliente. Normalmente o cliente informa apenas as informaes cadastrais e salva seus dados, esse ento o fluxo normal de interaes. MAS caso o cliente deseje, ele pode ainda inserir informaes sobre as suas preferncias relacionadas aos filmes. Esta possibilidade de inserir preferncias opcional e depende da solicitao do usurio, ento pode ser definido como um caso de uso estendido.
Veja como esse relacionamento representado :
cliente
gerenciar cliente
<<extend>>
inserir preferncias
Figura 5.7 Relacionamento de extenso Fonte: Elaborao da autora (2008).
Unidade 5
119
O diagrama geral de casos de uso atualizado seria ento:

cd locadora
Gerenciar filmes
Inserir Preferncias extend Gerenciar cliente
Atendente
Cliente
Gerenciar Locaes
Realizar cobrana
Utilize a extenso somente quando um comportamento opcional de um caso de uso precisar ser descrito.
O que o relacionamento de generalizao?
Quando voc faz uso da generalizao significa que um caso de uso ou um ator herda caractersticas de um caso de uso ou um ator mais genrico.
120
Nesses casos existem caractersticas comuns que podem ser compartilhadas, um relacionamento entre um elemento geral e um outro mais especfico. Nesse caso, o elemento mais especfico possui todas as caractersticas do elemento geral e alm destas contm ainda mais particularidades.
Figura 5.9 Herana entre atores Fonte: Elaborao da autora (2008).
Na generalizao entre atores, como na figura acima, o ator gerente herda todos os casos de uso do ator atendente. O ator atendente pode realizar os casos de uso gerenciar filmes, gerenciar cliente e gerenciar locaes . O ator gerente herda todos esses casos de uso (pode realizar gerenciar filmes, cliente e locaes), mas alm destes, o ator gerente pode realizar o caso de uso gerenciar relatrios (que so especficos para esse ator). Se a generalizao for entre casos de uso, ento podemos ter uma situao como a da figura 5.10. Imagine uma funcionalidade no sistema da videolocadora onde ser controlada a cobrana de clientes que sejam devedores, a cobrana pode ser realizada pessoalmente ou por telefone. Nessa situao, o caso de uso Pessoalmente e Telefone, herda o comportamento do caso de uso realizar Cobrana, ou seja, alm de herdar comportamentos bsicos do caso realizar Cobrana, os dois casos possuem tambm fluxos de interaes especficas para cada um deles.
121
Unidade 5
Figura 5.10 Herana entre casos de uso Fonte: Elaborao da autora (2008).
O diagrama geral de casos de uso atualizado seria ento:

cd locadora
Gerenciar filmes
Inserir Preferncias extend Gerenciar cliente
Atendente
Cliente
Gerenciar Locaes
Realizar cobrana
Realizar cobrana pessoalmente
Realizar cobrana telefone
Figura 5.11 Diagrama de casos de uso de videolocadora Fonte: Elaborao da autora (2008).
122
O que relacionamento de incluso?
O caso de uso A inclui o caso de uso B quando representa uma atividade complexa e comum a vrios casos de uso (PDUA, 2001). Esse relacionamento s possvel entre casos de uso.
Em outras palavras, o caso de uso pode ser includo quando a sequncia de interaes dele ocorre em mais de um caso de uso. Ainda pensando no sistema da videolocadora observa-se que apenas o gerente tem acesso a cobrana e aos relatrios do futuro sistema. Para obter o acesso seguro, o sistema deve apresentar uma funcionalidade que permita o controle do acesso por meio da autenticao do usurio no sistema. Essa autenticao ser realizada para todos os casos de uso, verificando se o acesso est sendo realizado por um usurio credenciado a usar a funo no sistema. Nessa situao, todos os casos de uso faro uso do caso de uso Autenticao, sendo um caso tpico de incluso, pois o mesmo caso de uso est relacionado a vrios casos de uso.
Unidade 5
123
cd locadora
Gerenciar filmes
Inserir Preferncias extend include Gerenciar cliente
Atendente
Cliente include
Autenticao include
Gerenciar Locaes
include Gerente include Gerenciar Relatrios
Realizar cobrana
Pessoalmente
Telefone
Um exemplo comum de incluso a autenticao por meio de contas e senhas. Quando voc est em um caixa eletrnico com as possibilidades de saque, extrato, pagamento, apesar de cada uma delas possuir sequncias de interaes e comportamento especfico, tm em comum a autenticao de conta e senha. Logo, esse caso pode ser includo, pois em todos os processos ele vai acontecer com a mesma sequncia de interaes.
Utilize o relacionamento de incluso em situaes onde o comportamento se repete em mais de um caso de uso.
124
Seo 4 Identificando casos de uso

Mas, como identificar os casos de uso do sistema?
Identifique os objetivos do usurio e no funes no sistema. Para identificar esses casos de uso, Pdua (2001) sugere:

Verifique quais as tarefas de cada ator. Que informao cada ator cria, armazena, consulta, altera ou remove. Que informao cada caso de uso cria, armazena, consulta, altera ou remove. Que mudanas externas sbitas devem ser informadas ao produto pelos atores. Que ocorrncias no produto devem ser informadas a algum ator.
Imagine uma situao em que voc convidado a desenvolver um projeto para um caixa eletrnico bancrio. O projeto prev o atendimento dos seguintes requisitos funcionais:
O sistema deve permitir ao cliente a emisso de saldo somente da conta corrente. O sistema deve permitir ao cliente a emisso de extrato somente da conta corrente. O sistema deve permitir a atualizao dos dados cadastrais do cliente. O sistema deve permitir o saque em dinheiro no caixa eletrnico.
Unidade 5
125
O sistema deve permitir a consulta a toda a movimentao financeira do cliente (conta corrente, poupana e aplicaes ) no caixa eletrnico. O acesso as funcionalidades do sistema deve ser possvel somente aps a verificao da conta e senha do cliente ou gerente.
ud Use Case Model
R ealizar saque
cliente Realizar extrato
include include Validao Conta
include Realizar saldo include
include Gerenciar cadastro Gerente banco
Gerenciar consultas
extend
extend
extend
Aplicaes
Poupana
Conta Corrente
Figura 5.13 Diagrama de casos de uso do caixa eletrnico Fonte: Elaborao da autora (2008).
Como documentar o caso de uso?
126
Ao definir um caso de uso, necessria uma descrio narrativa das interaes entre os elementos externos e o sistema. E o que deve ser documentado para o caso de uso? Existem alguns aspectos que so fundamentais:
Campo Nome Identificador Descrio Ator Primrio Ator Secundrio Precondio Descrio O nome do caso de uso deve ser o mesmo nome que consta no diagrama. No esquea de que o nome de um caso de uso deve ser nico. Conveno numrica utilizada para identificar o caso de uso. Exemplo: CSU002, CSU001. Descrio sucinta do caso de uso. O nome do ator que o responsvel pelo incio do caso de uso. Outros atores que fazem parte do caso de uso. A precondio indica as condies necessrios no sistema para que o caso de uso ocorra. Ex: Para realizar o caso de uso saldo, a precondio pode ser a validao positiva de conta e senha. O fluxo principal descreve a sequncia de aes que deve ocorrer quando o caso de uso realizado.Seja breve na descrio, o fluxo deve ser escrito utilizando-se a terminologia do usurio. Descreve a sequncia de aes quando o ator faz uma escolha alternativa. O fluxo alternativo descreve um comportamento alternativo para o fluxo principal. Voc deve descrever aqui o estado do sistema aps a execuo do caso de uso. Condies ou restries na execuo do caso de uso.
Fluxo Principal Fluxo Alternativo Ps-condio Regras de Negcio
Quadro 5.2 - Documentao do caso de uso Fonte: Bezerra (2000).
A seguir, um exemplo do diagrama de caso de uso documentado:
Unidade 5
127
cliente
realizar saldo
<<include>>
validar conta
Nome Identificador Descrio Ator Primrio Precondio
Realizar saldo CSU001 O cliente do banco solicita a emisso do saldo de sua conta corrente. Cliente Conta e senha do cliente serem vlidas. 1. 2. 3. 4. 5. o cliente informa a conta e agencia o cliente informa a senha o sistema exibe a lista de servios do caixa eletrnico o cliente seleciona a opo saldo o sistema apresenta mensagem informando a emisso do saldo
Fluxo Principal
Fluxo Alternativo Ps-condio Regras de negcio
1. O cliente cancela a operao por teclado finalizando o caso de uso Saldo do cliente impresso RN01
Quadro 5.3 - Exemplo de documentao do caso de uso realizar saldo Fonte: Elaborao da autora (2008).
realizar saque cliente
include
realizar saque
Realizar saque CSU003 O cliente do banco solicita saque de sua conta corrente. Cliente Conta e senha do cliente serem vlidas. Haver saldo na conta superior ou igual ao valor solicitado. 1. o cliente informa a conta e agncia 2. o cliente informa a senha 3. executa caso de uso Validao Conta 4. o sistema exibe a lista de servios do caixa eletrnico 5. o cliente seleciona a opo saque 6. o cliente digita o valor a ser sacado 7. o cliente informa a senha 8. verifica se o saldo suficiente 9. executa caso de uso Validao Conta 10. o valor do saldo da conta atualizado 11. as cdulas so liberadas no dispenser de cdulas
Fluxo Principal
128
Fluxo Alternativo 1 Fluxo Alternativo 2 Fluxo Alternativo 3 Ps-condio R. Negcio
1. O cliente cancela a operao por teclado finalizando o caso de uso 1. O sistema informa a mensagem Conta e/ou Senha inconsistente 2. O sistema finaliza a tarefa por senha ou conta inexistente 1. O sistema informa a mensagem Saldo Insuficiente para Saque 2. O sistema finaliza a tarefa por saldo insuficiente Cdulas disponibilizadas RN02
Quadro 5.4 - Exemplo de documentao do caso de uso realizar saque Fonte: Elaborao da autora (2008).
Quais so as regras de negcio?
Quando voc especifica uma regra de negcio voc est especificando alguma condio, uma restrio, uma poltica ou uma norma que pode de alguma maneira interferir no processo que ser realizado por seu projeto. Regras de negcio mudam de uma empresa para outra, outras so comuns a vrias empresas. Veja alguns exemplos de regras de negcio:
no sistema de caixa eletrnico o cliente s poder realizar o saque se e somente se: o saldo de sua conta corrente for superior ou igual ao valor a ser sacado. Se o saldo for inferior ao valor a ser sacado e se o cliente possui um valor de limite de crdito em sua conta corrente, ento o saque no pode ser superior ao valor do saldo do valor limite da conta corrente. no sistema de estoque, na baixa do estoque quando a quantidade em estoque de um produto for inferior a quantidade de estoque mnimo deve ser gravada uma solicitao de pedido para esse item. A quantidade solicitada ser a diferena de quantidade sobre a quantidade mnima.
Unidade 5
129
As regras de negcio podem ser documentadas por meio de uma identificao e descrio. Cada regra pode estar ligada a um ou mais casos de uso, nesse caso o identificador deve ser anexado ao caso de uso.
Identificador RN01 Descrio da regra de negcio O nmero mximo de impresso de saldos no ms de 3 saldos mensais O cliente s poder realizar o saque se e somente se: o saldo de sua conta corrente for superior ou igual ao valor a ser sacado. Se o saldo for inferior ao valor a ser sacado e se o cliente possui um valor de limite de crdito em sua conta corrente, ento o saque no pode ser superior ao valor do saldo do valor limite da conta corrente.
RN02
Quadro 5.5 Exemplo de documentao das regras de negcio Fonte: Elaborao da autora (2008).
Sugesto para documentao dos casos de uso

importante estruturar a sequncia em que voc vai organizar esta documentao. Existem metodologias que apoiam estas decises como o RUP e o Iconix. Uma sugesto de documentao pode obedecer esta sequncia:
Rational Unified Process (RUP) definido como um processo de engenharia de software que oferece uma abordagem baseada em disciplinas possibilitando a atribuio de tarefas e responsabilidades no desenvolvimento de software (SOUZA; BRAGA, 2004). Iconix - O ICONIX um processo simplificado que unifica conjuntos de mtodos de orientao a objetos em uma abordagem completa, com o objetivo de dar cobertura ao ciclo de vida do desenvolvimento de software (ROSENBERG; SCOTT, 1999).
Se voc no preencheu o documento de anlise do problema e especificao de requisitos liste os requisitos funcionais e no funcionais. Documente o ator (lembra da tabela 5.1?) Insira o diagrama de casos de uso gerais do projeto. Uma tabela de documentao do caso de uso (tabelas 5.3 e 5.4) para cada caso de uso. Documente as regras de negcio (tabela 5.5).
130
E o que so pacotes?
O uso de pacotes permite a visualizao mais organizada principalmente em sistemas grandes. Se houver muitos casos de uso ou atores, voc pode usar os pacotes de casos de uso para estruturar ainda mais o modelo de casos de uso. Um pacote de casos de uso contm vrios atores, casos de uso, seus relacionamentos e outros pacotes.
Imagine que voc tenha a seguinte lista de casos de uso:

Cadastro de Clientes; Pedidos em Aberto; Gerenciamento de Vendas; Relatrio de Data de Validade Vencidas; Cadastro de Produtos; Lista de Clientes; Lista de Produtos; Relatrio de Produtos Mais Vendidos; Pedidos de Cancelamento.
O projetista pode agrupar casos de uso que apresentam aspectos comuns, como o tipo de funo, atores que utilizam ou questes organizacionais. Observe a figura a seguir: os casos de uso foram divididos em trs pacotes, e esse agrupamento facilita a visualizao, principalmente em sistemas com um grande nmero de casos de uso.
Unidade 5
131
ud Formal Requirements Consultas + Pedidos Cancelados + Pedidos em Aberto Atualizaes + Cadastro de Clientes + Cadastro de Produtos + Gerenciamento de Vendas
Relatrios + Data Validade Vencidas + Lista de Clientes + Lista de Produtos + Produtos Mais Vendidos
Figura 5.14 Diagrama de pacotes Fonte: Elaborao da autora (2011).
Quer conhecer mais ? Para melhorar seus conhecimentos sobre esta unidade voc pode ler:
O captulo 4 do livro: Princpios de Anlise e Projeto de Sistemas com UML, de Eduardo Bezerra, publicado em 2002.
Na Midiateca voc vai achar dois artigos interessantes abordando o assunto, sob os links:
UML - Linguagem de Modelagem Unificada Diagrama de caso de uso
Imagine que vocs foi contratado para modelar um sistema de imobiliria. Aps a anlise os requisitos funcionais foram assim definidos:
132
RF01 -> Requisito Funcional + numerao sequencial

Cadastro de clientes RF001
Permitir a incluso, alterao e excluso de clientes para compra, venda ou aluguel de imveis. Cadastro de corretores Permitir o cadastro de corretores que vendem imveis para a imobiliria. Cadastro de fiador RF003 RF002
Cadastro dos fiadores usados pelos clientes permitindo incluir, alterar, excluir seus dados. Cadastro de imveis Cadastra todos os dados dos imveis que so negociados na imobiliria. Imveis podem ser para locao ou venda: casa, apartamento, quitinete, comercial. Alugar imvel RF005 RF004
Cadastra os dados de aluguel de um imvel para um cliente, como data de locao, data de trmino de contrato, valor do aluguel. Vender imvel RF006
Cadastro das vendas realizadas pelos corretores permitindo incluir, alterar e excluir registros de venda. Gerar contrato Gera o contrato para ser impresso no ato da venda ou aluguel do imvel. A gerao do contrato e dados deve ser automtica. Emitir boleto bancrio RF008 RF007
Emite o boleto de cobrana para clientes que alugam imveis com dados como valor do aluguel, IPTU, descontos e multas. Controle das comisses RF009
Emite um extrato com os imveis alugados ou vendidos indicando o valor da comisso do corretor.
Unidade 5
133
Busca de imvel
RF010
Propiciar a realizao da busca de imvel por parmetros informados como bairro, nmero de quartos, valor aproximado de aluguel. Gerar relatrio de cobrana RF011
Permitir a gerao de um relatrio com os imveis alugados que esto com mensalidade atrasada. Cadastra pagamento Deve ser permitido o registro do pagamento de aluguel de um imvel. Gerar relatrio RF013 RF012
Gerar um relatrio com quantidade de vendas e aluguis realizados e desfeitos. Classificado por ms e ano. Cadastrar usurio do sistema RF014
Permitir o cadastro de usurios do sistema, para que se possam definir nveis de acesso por meio de contas e senhas. Login de usurio RF015
Efetuar login para identificar quem est usando o sistema e definir os acessos que ele possui. Cadastro de manutenes RF016
Cadastra dados de manutenes feitas no imvel armazenando o tipo de manuteno, o valor gasto, data da manuteno e uma breve descrio.
Requisitos no funcionais
RNF01 -> Requisito No Funcional + numerao sequencial
Tempo de resposta RNF01
O tempo de resposta para consultas ao sistema, como a busca de imvel, no devem ser inferiores a 5 segundos. Manutenibilidade RNF02
O sistema deve ser construdo obedecendo viso de camadas facilitando futuras manutenes.
134
Durante a anlise perceberam-se as regras de negcio relacionadas ao funcionamento do processo na imobiliria:

Identificador RN01 RN02 RN03 RN04 RN05 RN06 RN07 RN08 Descrio O cliente deve ter fiador para contratar aluguel CPF do cliente e fiador devem ser vlidos. O imvel deve ser aprovado pelo gerente antes de ser cadastrado. O crdito do cliente deve ser aprovado pelo gerente antes de efetivar o contrato de aluguel. O valor da taxa do boleto, cobrada pelo banco, adicionado no valor total do boleto do locador. A multa por atraso no pagamento do aluguel de 0,1% do valor do aluguel por dia de atraso. O pagamento do boleto aps o vencimento s pode ser efetivado em estabelecimento bancrio conveniado imobiliria. As manutenes ou reformas feitas pelo locatrio no imvel so por conta prpria, ou seja, no sero abatidas no valor da mensalidade.
Quadro 5.6 - Regras de negcio do sistema imobilirio Fonte: Elaborao da autora (2008).
No sistema imobilirio foram identificados quatro atores:

ud Atores
Secretria
Corretor
Gerente
Cliente
Figura 5.15 Atores do sistema imobilirio Fonte: Elaborao da autora (2008).
A partir dos requisitos funcionais foram definidos os casos de uso. Os casos de uso foram subdivididos em trs pacotes Negociar Imvel, Gerenciamento e Administrao. Os casos de uso relacionados a cada pacote encontram-se inseridos no mesmo.
Unidade 5
135
ud Use Case Model Negociar Imv el + Alugar Imvel + Cadastrar Cliente + Cadastrar de Fiador + Cadastrar Imvel + Gerar Contrato + Gerar Contrato de Aluguel + Gerar Contrato de Venda + Validar CPF + Vender Imvel Gerenciamento + Cadastrar Corretor + Cadastrar Usurios do Sistema + Efetuar Login + Gerar relatrio de comisses + Gerar Relatrio de vendas/aluguis + Verifica se j existe Usurio Administrao + Buscar imvel + Cadastro de manuteno + Efetua Pagamento na imobiliria + Efetuar Pagamento + Envia confirmao de pagamento + Gerar Boleto Bancrio + Gerar Recibo + Gerar relatrio de aluguis pendentes + Pagar Boleto no Banco + Registrar Pagamento
Figura 5.16 Pacotes de casos de uso do sistema imobilirio Fonte: Elaborao da autora (2008).
O diagrama de casos de uso pode ser feito de forma geral ou por pacotes, observe a seguir diagrama de casos de uso dos pacotes Gerenciamento e Negociar Imvel:
ud Gerenciamento
Verifica se j existe Usurio
include Cadastrar Usurios do Sistema
include Gerente (from Atores)
Gerar relatrio de comisses
include
Efetuar Login
include
Gerar Relatrio de v endas/aluguis
Figura 5.17 Diagrama de casos de uso do pacote gerenciamento Fonte: Elaborao da autora (2008).
136
ud Negociar Imv el
Cadastrar Cliente include Validar CPF
include Cadastrar de Fiador
include Cadastrar Imv el include Corretor (from Atores) extend include
Gerar Contrato de Aluguel
Alugar Imv el include Efetuar Login
include Vender Imv el
(from Gerenciamento)
extend Gerar Contrato de Venda
Figura 5.18 Diagrama de casos de uso do pacote negociar imvel Fonte: Elaborao da autora (2008).
Definidos os diagramas voc vai documentar cada caso de uso, como os exemplos apresentados a seguir:
Unidade 5
137
Cadastrar de Fiador Corretor (from Atores)
include
Validar CPF
Cadastrar Fiador CSU02 O corretor cadastra as informaes inerentes ao fiador de um cliente. Corretor Corretor logado no sistema 1. Corretor digita dados do fiador no sistema.
Fluxo Principal
3. Corretor Confirma cadastro. 4. Executa Validar CPF. 5. Dados do Fiador so armazenados.
Fluxo Alternativo 1
1. Corretor seleciona boto Cancelar. 2. Os dados da janela so limpos. 1. Corretor deseja alterar dados de algum fiador 2. Corretor seleciona um fiador cadastrado. 3. Sistema mostra informaes do fiador.
Fluxo Alternativo 2
4. Corretor altera informao 5. Executa Validar CPF. 6. Corretor confirma a alterao 7. Dados do Fiador so armazenados 1. Corretor deseja excluir fiador.
Fluxo Alternativo 3
2. Corretor seleciona um fiador cadastrado. 3. Seleciona boto Excluso. 4. Dados do fiador so excludos do banco de dados.
Ps-condio Regras de Negcio
Dados do fiador atualizados RN02
Figura 5.19 - Documentao do caso de uso cadastrar fiador Fonte: Elaborao da autora (2008).
138
Cadastrar Imvel Corretor (from Atores)
Cadastrar Imvel CSU04 Efetua o cadastro do imvel que ficar disponvel na imobiliria. Corretor Corretor logado no sistema e o Proprietrio do imvel precisa estar cadastrado no sistema como cliente. 1. Corretor informa cdigo do cliente
Fluxo Principal
2. Corretor insere dados do imvel no sistema. 3. Corretor confirma cadastro.
Fluxo Alternativo 1
1. Corretor seleciona boto Cancelar. 2. Os dados da janela so limpos. 8. Corretor deseja alterar dados do imvel 9. Corretor seleciona um imvel cadastrado. 10. Sistema mostra informaes do imvel. 11. Corretor altera informao 12. Corretor confirma a alterao 13. Dados do Imvel so armazenados 5. Corretor deseja excluir imvel.
Fluxo Alternativo 2
Fluxo Alternativo 3
6. Corretor seleciona um imvel cadastrado. 1. Seleciona boto Excluso. 2. Dados do imvel so excludos do banco de dados.
Ps-condio Regras de Negcio
Imvel atualizado no banco de dados. RN03
Figura 5.20 - Documentao do caso de uso cadastrar imvel Fonte: Elaborao da autora (2008).
Agora, para praticar os conhecimentos conquistados nesta unidade, realize a seguir as atividades propostas.
Unidade 5
139
Sntese
Nesta unidade, voc aprendeu a identificar os casos de uso mais significantes e seus principais elementos. Durante o estudo tambm foram identificados os possveis relacionamentos existentes entre atores e casos de uso. Voc percebeu que o caso de uso estabelece a estrutura principal da modelagem permitindo uma comunicao fcil e precisa com o usurio, pois esta viso no inclui aspectos relacionados implementao facilitando a interpretao por parte de desenvolvedor e usurios, identificando as aes necessrias ao sistema para que o usurio alcance a soluo de suas necessidades. A partir dos conceitos elementares voc seguiu em direo concepo do diagrama e da documentao necessria para o bom entendimento do modelo.
Leia com ateno os enunciados e, aps, realize as questes propostas: 1) Assinale a afirmativa correta: a) ( ) b) ( ) Um caso de uso procura apoiar a especificao de detalhes necessrios implementao do sistema. O caso de uso documenta as aes necessrias, comportamentos e sequncias visando atender as necessidades do usurio. Em um caso de uso so necessrios trs elementos bsicos: o caso de uso, a classe de controle e o ator. O ator de um caso de uso representa apenas os usurios do sistema.
c) ( ) d) ( )
140
2) Classifique as questes em Verdadeira (V) ou Falsa (F). a) ( ) b) ( ) Um ator pode ser representado por um organizao ou mesmo um equipamento de hardware. O uso de um nome pessoal para um determinado ator cria uma identificao pessoal do usurio com a especificao do caso de uso, facilitando sua validao com o usurio. A relao existente entre um caso de uso e um ator pode ser uma relao de comunicao ou uma relao de extenso. A relao existente entre dois atores pode ser somente uma relao de herana. A relao existente entre dois casos de uso pode ser de extenso, incluso e comunicao. A relao existente entre dois casos de uso pode ser de extenso, incluso e herana.
c) ( ) d) ( )
e) ( )
f) ( )
3) Relacione a primeira com a segunda coluna. A. Regras de negcio B. Ator C. Cenrio D. Caso de uso ( ) ( ) ( ) DVDs em atraso pagam o valor da locao dos dias atrasados Atendente A reserva de um DVD pode ser realizada pessoalmente, em que o cliente informa seu nome, o DVD desejado e a data da reserva. Caso o DVD no esteja reservado, o atendente realiza a reserva. O DVD pode ser reservado na pgina da videolocadora. Informando seu nome, o cliente seleciona o DVD e informa a data da reserva. A reserva efetiva somente pelo envio da confirmao para o e-mail do cliente. Devoluo de DVDs Fornecedor de DVDs Gerenciar compra de DVDs O cliente pode retirar no mximo 3 DVDs com devoluo para 24 horas.
( ) ( ) ( ) ( )
Unidade 5
141
4) No texto a seguir, identifique: a) Os requisitos funcionais b) Os atores c) Os casos de uso d) Documente dois casos de uso Requisitos funcionais:
O projeto que voc vai realizar ser para a clnica peditrica Bem-Estar e tem como objetivo principal a marcao de consultas mdicas. O paciente pode realizar o agendamento da consulta pessoalmente ou por telefone. Em qualquer dos dois mtodos os procedimentos so idnticos. O paciente solicita a consulta informando o nome do mdico ou a especialidade desejada, posteriormente informa a data desejada. A atendente verifica a possibilidade de marcao da consulta (observando se o mdico em questo possui horrio vago para a data desejada). Se existe horrio disponvel, a atendente solicita ao paciente o tipo de convnio ou se particular. Se for convnio, verificado se um convnio vlido; se for particular, informado o valor da consulta. A atendente atualiza a agenda com o nome do paciente e o tipo de consulta (convnio/particular). O tempo para cada consulta de 20 minutos ou 10 minutos para retorno. A consulta pode ser uma consulta de retorno. Nesse caso, a atendente verifica se a data est ainda dentro do prazo de retorno de 15 dias. Neste caso a consulta marcada na agenda. Caso o mdico solicitado esteja indisponvel, a atendente procura informar o nome de outro mdico disponvel naquele horrio ou o prximo horrio disponvel. O paciente pode telefonar desmarcando a consulta, nesse caso o nome do paciente riscado da agenda, ficando o horrio vago novamente. Ao chegarem na clnica, os mdicos recebem as fichas dos pacientes separadas previamente. Se for paciente novo, a ficha contm somente o nome do paciente e o telefone. As fichas so classificadas por ordem de horrio. Se o paciente j possui cadastro, o mesmo convidado a adentrar no consultrio do mdico. A partir desse momento, o mdico solicita informaes procedimentais para o futuro diagnstico, preenchendo a ficha do paciente. Finalizada a consulta, o paciente liberado e a ficha recolhida pela atendente, sendo novamente arquivada. Se o paciente for novo, a atendente solicita o preenchimento da ficha cadastral com dados pessoais.
142
Saiba mais
Para aprofundar as questes abordadas nesta unidade, voc poder pesquisar: BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usurio. Rio de Janeiro: Campus, 2000. (Ler captulos 16 e 17.)
Unidade 5
143
UNIDADE 6
Modelagem de classes
Identificar o papel do diagrama de classes no processo de anlise. Conhecer e reconhecer termos tcnicos, conceitos e relacionamentos utilizados durante a construo do diagrama de classes. Identificar as possveis classes de um projeto. Utilizar o diagrama de classe com a notao UML na construo de um modelo de projeto.
Sees de estudo
Seo 1 Seo 2 Seo 3 Seo 4 Seo 5 O que so objetos e classes de objetos? Quais so as responsabilidades das classes? Como ocorrem os relacionamentos entre objetos? Como ocorre a diviso das classes do modelo de anlise? O que diagrama de objetos?

Voc j estudou um dos aspectos mais fortes do projeto, que so os casos de uso. Eles permitem aos atores a visualizao de resultados esperados, relatrios e processamentos. De qualquer maneira, a possibilidade da existncia dessa colaborao depende de aspectos estticos e dinmicos do sistema. Entre objetos do sistema, o aspecto dinmico est fortemente ligado troca de mensagens, enquanto o aspecto esttico mostra como o sistema est estruturado internamente e passa por trs nveis de abstrao: o primeiro deles, o modelo de classe de domnio, representa a classe de domnio sem se preocupar com detalhes sobre a tecnologia; o segundo nvel o modelo da classe de especificao que acrescenta detalhes relacionados soluo do software escolhida pelo modelo do domnio; o terceiro nvel, o modelo de classe de implementao uma extenso do modelo de especificao. Ocorre neste nvel a implementao em alguma linguagem de programao. Para voc entender a utilizao desses nveis de abstrao, necessrio conhecer conceitos e relacionamentos vinculados ao modelo de classes. O modelo de classes um dos modelos mais ricos em termos de notao e concentra o cerne esttico de todo o projeto. Ento, que tal escalar o mundo conceitual das classes?
146
Seo 1 O que so objetos e classes de objetos?

De acordo com Pdua (2001), as entidades de domnio so representadas na modelagem orientada a objetos por objetos. O objeto representa uma entidade que pode ser fsica ou de software. Na realidade, um objeto sempre descrito por meio do estado, do comportamento e da identidade.
A identidade uma propriedade que ir distingui-lo dos demais. O estado de um objeto compreende caractersticas herdadas ou distintas que contribuem para que se torne nico. O comportamento de um objeto define como se daro sua ao e reao a estmulos em termos de mudanas de estados e mensagens.
Classe Cliente Identidade Cliente Estado Nome Cdigo Endereo Telefone Permisso Comportamento: Adicionar Cliente( ) Excluir Cliente( ) Consultar Cliente( )
Unidade 6
147
Os objetos tambm so chamados de instncia.
Voc pode dizer tambm que um objeto uma pessoa, um lugar ou um sistema, como mostra a figura a seguir.
Figura 6.1 Exemplos de objetos Fonte: Elaborao da autora (2010).
O que so classes?
Um objeto sempre uma instncia de uma classe. Quando voc fala de uma classe, est falando tambm de seus objetos.
Segundo Furlan (1998), classe a representao de um conjunto de coisas reais ou abstratas que so reconhecidas como sendo do mesmo tipo por compartilhar as mesmas caractersticas de atributos, operaes, relaes e semntica. Booch (2000) define classe como um conjunto de objetos que compartilham estrutura e comportamento comuns.
Figura 6.2 Classe Clientes Fonte: Elaborao da autora (2010).
Conforme voc pode observar na figura 6.2, Luis, Ana, Bruno e Carla so objetos ou instncias da classe. Mas qual a notao utilizada para identificar uma classe? A classe representada por um retngulo dividido em trs compartimentos que contm o nome da classe, os atributos e as operaes.
148
Figura 6.3 Notao da classe Fonte: Elaborao da autora (2008).
O que so atributos?
O atributo a descrio dos dados armazenados pelos objetos de uma classe. O atributo de uma classe est associado a um conjunto de valores que o atributo pode assumir. Est correto afirmar que os atributos no tm comportamento. Cada valor de um atributo particular para um dado objeto. Uma classe pode ter qualquer nmero de atributos ou nenhum atributo. Os atributos so sempre individuais e cada objeto da classe possui seus prprios atributos. Recordando do projeto da videolocadora, voc pode definir as classes? possvel detectar imediatamente trs classes nesse projeto:

Classe Cliente (dados e mtodos do cliente); Classe Filmes (dados e mtodos dos filmes); Classe Locao (dados e mtodos sobre a locao).
O que so operaes?
Unidade 6
149
As operaes implementam servios que podem ser solicitados por algum objeto da classe para modificar o comportamento, ou seja, todos os objetos da classe vo compartilhar essas operaes. As operaes so executadas quando um objeto recebe uma mensagem de outro objeto. Entretanto, existem situaes em que uma classe pode no ter nenhuma operao ou mesmo ter vrias operaes.
bairro
Figura 6.4 Classe Cliente Fonte: Elaborao da autora (2008).
Observe que:
para nomear a classe, voc deve escolher um substantivo, por exemplo: fornecedor, produtos, cliente; para nomear uma operao, faa uso de um verbo ou de um verbo mais um substantivo. A escolha do nome da operao deve possuir um nome que indique o resultado da operao (Cancelar_Fornecedor) acrescentando-se os parnteses ( ) ao final do nome da operao; para nomear atributos, utilize substantivos simples ou verbos substantivados. Se voc for construir uma classe para um sistema de controle de estoque chamada Produtos, os atributos da classe Produto podem ser cdigo, descrio_Produto ou unidade; para os trs casos, ao atribuir nomes, utilize uma definio concisa e clara, no dando margem a interpretaes errneas.
150
Quais seriam os atributos para a classe Filmes? Voc poderia ter nesse caso:

Nome_; Cdigo_; Diretor_; Durao_; Ator_Principal1; Ator_Principal2; Tipo_; Idiomas_.
Agora tente imaginar as possveis operaes: Incluir_Filme; Excluir_Filme; Consultar_Filme; Listar_Filme. Observe algumas classes que fariam parte do domnio do sistema da videolocadora.
Unidade 6
151
cd Data Model Cliente Bairro: char Cdigo: int Endereo: char Nome: char Telefone: int Locao Data_Devoluo: date Data_Locao: date Valor: float Item_Locao
Filmes Ator_Principal1: char Ator_Principal2: char Cdigo: int Diretor: char Durao: int Estilo: char Idioma: char Ttulo: char -
Cpias Data_Compra: date Nmero: int Status: int
Figura 6.5 Possveis classes do sistema de videolocadora Fonte: Elaborao da autora (2008).
A notao de classes apresenta trs compartimentos, porm as classes podem ser apresentadas em diferentes nveis de abstrao, como apresentado na seguinte figura.
Cliente
Cdigo Nome Endereo CGC Limite_Crdito Calcular_Limite( ) Emitir_Relatrio( )
Cliente
Cdigo Nome Endereo CGC Limite_Crdito
Cliente
Figura 6.6 Abstraes das classes Fonte: Elaborao da autora (2008).
152
Seo 2 Quais so as responsabilidades das classes?

Uma responsabilidade um contrato ou obrigaes de uma determinada classe, ou seja, representam o conhecimento e as aes que possibilitam que as classes cumpram seu papel nos casos de uso (PDUA, 2001). Por exemplo: uma classe Cliente responsvel pelo conhecimento sobre os dados pessoais (cdigo, nome, endereo etc.) do cliente, alm de ser responsvel por incluir, excluir e consultar os dados do cliente. Mas definir as classes existentes em um futuro sistema e suas responsabilidades no uma tarefa fcil. O mais adequado voc procurar o apoio de mtodos reconhecidos que procuram facilitar sua realizao. Para isso, existem dois mtodos popularizados para essa etapa, que so: os cartes CRC e a anlise dos casos de uso. a) Os cartes Classes Responsabilidades e Colaboraes (CRC) O uso dos cartes CRC identifica as responsabilidades dos atributos e das operaes apoiando a identificao de classes ou de candidatos s classes. Cada ficha corresponde a uma classe, contm o nome da classe e duas colunas com descrio de suas responsabilidades e colaboraes. As colaboraes representam outras classes que interagem com a classe descrita para o cumprimento de suas responsabilidades. O uso do carto CRC realizado com o envolvimento de toda a equipe. Para isso, uma sesso organizada. Para realizar a sesso:
o primeiro passo a escolha do grupo de pessoas que representar um cenrio, ou seja, exatamente o cenrio do domnio do problema;
Unidade 6
153
Para cada classe de objeto identificada dentro do cenrio, criado um carto CRC.
na segunda etapa, cada participante associado a uma classe. Assim, cada pessoa passa a pertencer quela classe e todo o cenrio ser encenado pelos participantes. Aos poucos cada carto preenchido com as responsabilidades e os colaboradores. Durante a sesso pela explorao dos cenrios, comum que novos cartes sejam criados pela descoberta de novas classes. Observe o carto CRC criado a partir do seguinte cenrio: O balconista faz a abertura da venda. O balconista registra os itens de venda podendo inserir novos itens, exclu-los e edit-los. O sistema totaliza a venda para o cliente. O sistema calcula os impostos sobre a venda. O balconista encerra a venda.
Nome da Classe: Venda Responsabilidades Inserir/excluir item de venda Editar item de venda Totalizar venda Calcular impostos Colaboraes Item de venda Estoque Mercadoria Mercadoria
Quadro 6.1 - Exemplo de um carto CRC Fonte: Elaborao da autora (2008).
Voc pode documentar as responsabilidades no prprio diagrama de classes. Neste caso, insira a descrio na forma de texto no final da caixa da classe, ou seja, na notao grfica voc tem mais um compartimento logo abaixo das operaes.
154
b) Anlise dos casos de uso Se voc optar por utilizar a anlise de casos de uso para identificar as classes candidatas e suas responsabilidades, importante analisar os casos de uso e todos os seus fluxos (principais e alternativos). Mas como funciona esse mtodo? Bom, a partir da anlise so identificados os substantivos existentes nos casos de uso e os sinnimos so eliminados. Muitas vezes, um substantivo pode ser um ator, o qual deve ser eliminado. Assim, os nomes que permaneceram so as classes candidatas. Observe o exemplo a seguir:
Pdua (2001) mostra a anlise de um estudo de caso para um sistema de vendas de uma pequena mercearia. Ao analisar o estudo de caso procurando as classes candidatas, os atores so selecionados em itlico, o sistema aparece em negrito e os substantivos em sublinhado. O balconista faz a abertura da venda. O balconista registra os itens vendidos informando cdigo do produto e quantidade do item. O sistema totaliza a venda para o cliente. O balconista encerra a venda. O sistema emite o ticket para o cliente. O balconista registra a forma de pagamento. O sistema faz a baixa no estoque das mercadorias vendidas.
Unidade 6
155
Ao analisar o caso de uso, voc deduz a possvel lista de classes candidatas, operaes e atributos:
Classe Candidata Abertura Venda Item vendido Cdigo do produto Quantidade Cliente da mercearia Ticket Forma de pagamento Baixa Estoque Mercadoria Quadro 6.2 Exemplo lista de classes Fonte: Elaborao da autora (2008). Anlise Operao Provvel classe Provvel classe melhor item de venda Atributo do item da venda Atributo do item da venda Entidade fora do escopo do produto Relatrio Atributo da venda Operao Possvel classe Possvel classe
Observe que o item abertura pode ser descrito como uma operao, assim como venda passa a ser uma possvel classe. J cdigo do produto tem as caractersticas de um atributo. Note que j possvel identificar inclusive a qual classe o atributo pertence, como no caso da quantidade. A partir da identificao possvel determinar no exemplo as classes candidatas do sistema de controle de mercearia:
Figura 6.7 Classes candidatas Fonte: Elaborao da autora (2008).
156
Apesar da possibilidade de utilizar essas tcnicas, o grande universo de informaes do domnio do problema muitas vezes dificulta a identificao. Existem algumas dicas que podem ser utilizadas para descobrir as classes de um domnio de aplicao observando os seguintes elementos:
informaes que devem ser armazenadas, transformadas, analisadas ou manipuladas de alguma forma; outros sistemas e terminadores externos que se comunicam ou interagem com o sistema em questo, atentando para as informaes que esto sendo trocadas; dispositivos fsicos com os quais o sistema em estudo ter de interagir, sem considerar a tecnologia para implementar o sistema em si; modelos, bibliotecas de classe e componentes gerados em projetos anteriores.
Coad e Yourdon (1992) tambm sugerem alguns indicadores:
coisas que so parte do domnio de informao do problema; ocorrncias ou eventos que precisam ser registrados e lembrados pelo sistema; papis desempenhados pelas diferentes pessoas que interagem direta ou indiretamente com o sistema; locais fsicos ou geogrficos e lugares que estabelecem o contexto do problema; unidades organizacionais (departamentos, divises etc.) que possam ser relevantes para o sistema.
Lembra-se do projeto da Clnica Bem-Estar visto na unidade 2, atividade 3, de autoavaliao? Que tal definir as possveis classes candidatas?
Unidade 6
157
Classe Paciente; Classe Mdico; Classe Convnio; Classe Laboratrio; Classe Agenda; Classe Ficha_Mdica.
Agora quais os atributos que voc considera pertinentes para a classe Convnio? Voc pode listar para a classe convnio atributos como:

Cdigo_Convnio; Nome_Convnio; Telefone_Convnio; Caractersticas_Convnio; Status_Convnio.
Se voc listar os possveis atributos da classe Mdico:

Nome_Mdico; CRM_Mdico; Endereo_Mdico; Telefone_Mdico; Celular_Mdico; Especialidades_Mdico; Horrio_Mdico.
158
Seo 3 Como ocorrem os relacionamentos entre objetos?

Um relacionamento representa a interao entre as classes e os objetos, ele apoia o refinamento das classes. Existem diferentes tipos de relacionamentos possveis entre as classes identificadas. Os mais importantes so as associaes, as dependncias e as generalizaes.
Figura 6.8 Relacionamento entre objetos Fonte: Adaptado de Booch (2000).
Conhea ento, a partir de agora, as principais caractersticas sobre os tipos mais comuns de relacionamentos entre objetos. a) Relacionamento de associao Segundo Furlan (1998), associao uma relao que descreve um conjunto de vnculos entre elementos de modelo: quando duas classes ou mesmo uma classe, consigo prpria, apresenta interdependncia; ou quando uma determinada instncia de uma das classes origina ou se associa a uma ou mais instncias da outra classe, voc pode dizer que se tem um relacionamento de associao.
Unidade 6
159
Funcionamento
Projeto
Paciente
Ficha_Mdica
Figura 6.9 Relacionamento de associao entre as classes Fonte: Elaborao da autora (2008).
O que multiplicidade dentro desse tipo de relacionamento?
Quando se menciona associaes, possvel representar a quantidade de objetos aos quais o outro objeto est associado. Um exemplo prtico: um projeto existe sem que seja alocado um funcionrio para esse projeto? Quantos projetos podem ser alocados para cada funcionrio? Quantos funcionrios podem ser alocados para cada projeto? Na notao UML, isso chamado de multiplicidade. Alguns autores tambm utilizam o termo cardinalidade. Mas como represent-lo em um diagrama? Observe ento a tabela a seguir que apresenta essa simbologia:
Nome Apenas um Zero ou muitos Um ou muitos Zero ou um Intervalo especfico Quadro 6.3 Simbologia UML Fonte: Elaborao da autora (2008). Simbologia 1 0..* 1..* 0..1 1i..1s
Veja alguns exemplos de multiplicidade:
160
Um paciente possui nenhum ou vrios agendamentos.

Paciente Agenda
Paciente de transporte, Agenda Em uma empresa um motorista dirige apenas um caminho, e cada caminho pode ser dirigido por apenas um motorista. Paciente Agenda
No terceiro exemplo, um funcionrio deve estar locado a 1..* 1,..* um ou mais projetos. E cada projeto tem pelo menos um funcionrio alocado.
1..* 1,..*
1..*
1,..*
Imagine um projeto para uma mercearia em que se pretende controlar os fornecedores, seus produtos e os pedidos de compra de produtos. Imediatamente voc identifica pelo menos trs classes candidatas:
Classe Fornecedor (que vai armazenar dados como endereo, nome, telefone etc.); Classe Produtos (que deve armazenar dados como cdigo, descrio, unidade etc.); Classe Item de Compra (que deve armazenar preo, quantidade comprada etc.).
Voc tem a classe Fornecedor, que pode ter de 0 a n produtos (ou seja, o fornecedor oferece mercearia vrios produtos para compra; veja o exemplo de uma revenda de bebidas que possui diferentes tipos de refrigerante e cerveja). Os produtos, por sua vez, podem ter de 0 a n fornecedores (posso ter mais de um fornecedor para o mesmo refrigerante).
Unidade 6
161
Cada item de compra pode ter apenas um fornecedor, mas cada fornecedor pode ter de 0 a n itens de compra (no momento da compra vou ter um fornecedor apenas para aquele determinado item para aquela determinada nota fiscal).
Figura 6.10 Multiplicidade Fonte: Adaptado de Pdua (2001).
Como nomear uma associao?
H vrias maneiras de nomear associaes. No entanto, voc deve escolher o nome pensando na descrio da natureza do relacionamento. Prefira o uso de um verbo ou uma frase verbal. Alm de indicar um nome, voc pode ainda indicar a direo da leitura da associao inserindo um tringulo de orientao.
Paciente Solicita Agenda
Figura 6.11 Nomeando uma associao Fonte: Elaborao da autora (2008).
Alm desses recursos, observe que a classe, ao participar de uma associao, recebe um papel especfico que utilizado em um dos lados de uma associao com a finalidade de indicar qual o papel que a classe a seu lado apresenta para a classe do lado oposto.
162
Um papel define o propsito ou a capacidade de uma classe. Utilize substantivos para indicar os papis (BEZERRA, 2002).
Na figura 6.12, h a classe Pessoa desempenhando o papel de funcionrio na associao com a classe Banco, que desempenha o papel de empregador.
Figura 6.12 Papis em uma associao Fonte: Elaborao da autora (2008).
O que significa agregao para o relacionamento de associao?
A agregao um caso particular da associao. A agregao indica que uma das classes do relacionamento uma parte ou est contida em outra classe (GUEDES, 2006). Mas as duas classes esto no mesmo nvel, ou seja, no existe uma classe mais importante do que a outra na associao.
As palavras-chave usadas para identificar uma agregao so: consiste em, contm ou parte de. Outra dica importante que as partes no morrem obrigatoriamente com o todo, e uma mesma parte pode estar em mais de um todo. Graficamente voc vai representar a associao de agregao por uma linha e um diamante aberto na extremidade.
Observe o exemplo de uma transportadora. Pode-se dizer que a empresa tem departamento, e a transportadora contm caminhes.
Unidade 6
163
Figura 6.13 Agregao Fonte: Booch (2000).
A composio um tipo especial de agregao em que a multiplicidade do lado todo sempre 1. As partes vivem e morrem obrigatoriamente com o todo. Uma mesma parte no pode estar em mais de um todo. Os objetos da classe Parte no existem de forma independente da classe Todo. A composio, segundo Rumbaugh (1994), um tipo forte de associao em que um objeto agregado composto de vrios objetos componentes.
Figura 6.14 Composio Fonte: Elaborao da autora (2008).
164
Na representao das classes, de acordo com a figura 6.14, a associao de composio exprime que o Item de Pedido no existe sem o Pedido, ou seja , o Item de Pedido no existe de forma independente no sistema. As classes Motor e Bateria nesse exemplo no existem de forma independente da classe Veculo. Elas fazem parte do todo Veculo. A figura 6.15 um exemplo de classes para um sistema de controle de turmas em uma universidade. Nesse exemplo, a universidade oferece cursos aos alunos. Os cursos, por sua vez, oferecem disciplinas ministradas por professores aos alunos matriculados.
Figura 6.15 Relacionamentos entre classes Fonte: Elaborao da autora (2008).
As classes Universidade e Cursos possuem um relacionamento de composio, ou seja, a classe Curso no existe sem a classe Universidade. Se a classe Universidade for extinta, automaticamente a classe Cursos deixa de existir. J as classes Aluno e Professor apresentam um relacionamento de agregao, pois fazem parte de outra classe. A classe Aluno est contida na classe Universidade e a classe Cursos contm a classe Professor.
Unidade 6
165
O que so classes associativas?
Para Bezerra (2002), as classes associativas esto ligadas a associaes e no a outras classes. Simplificando, existem situaes na anlise em que atributos e operaes so partes do relacionamento como um todo e no de cada uma das classes envolvidas. Nesse caso, em vez de se associarem esses atributos/ operaes a um participante, criada uma classe associativa que absorve esses atributos/operaes.
Figura 6.16 Classe associativa Fonte: Pdua (2001).
No exemplo ilustrado na figura 6.16, voc v uma situao em que uma pessoa trabalha em vrias empresas e uma empresa tem vrios empregados. Os atributos salrio e dataContrataao no pertencem classe Empresa nem classe Pessoa (que mantm dados cadastrais do empregado). Neste caso, uma classe associativa Emprego foi criada para comportar esses atributos para cada par (empregado/empregador).
166
b) Relacionamento de dependncia A dependncia indica a ocorrncia de um relacionamento entre dois ou mais elementos, no qual uma classe Cliente dependente de algum servio da classe Fornecedora.
Quando voc precisar indicar que um item depende de outro, utilize o relacionamento de dependncia.
Bezerra (2002) indica situaes que levam a um relacionamento de dependncia, como:
dependncia por atributo a classe A possui um atributo cujo tipo B; dependncia por varivel global a classe A utiliza uma varivel global cujo tipo B; dependncia por varivel local A possui alguma operao cuja implementao utiliza uma varivel local do tipo B; dependncia por parmetro A possui pelo menos uma operao que possui pelo menos um parmetro cujo tipo B.
Figura 6.17 Dependncia Fonte: Elaborao da autora (2008).
Para que as operaes da classe Filme sejam executadas, a existncia da classe Canal fundamental, pois existe uma dependncia de parmetros entre as classes.
Unidade 6
167
c) Relacionamento de generalizao A generalizao um relacionamento entre itens gerais (superclasses) e tipos mais especficos desses itens (as subclasses). A subclasse herda as propriedades da superclasse, principalmente atributos e operaes. Um relacionamento de especializao/generalizao indica que objetos do elemento especializado (subclasse) podem substituir os objetos do elemento generalizado (superclasse). A subclasse tem todos os atributos e as operaes da superclasse, porm pode ter outros atributos e operaes.
Imagine a seguinte situao: voc tem uma classe em seu sistema chamada Funcionrios. Essa classe possui atributos como nome, endereo, entre outras informaes. Existe, no entanto, um tipo de funcionrio chamado motorista. Esse funcionrio possui atributos especficos como itinerrio e horrio das rotas. Os motoristas fazem parte da classe Funcionrios, mas por suas caractersticas especficas formam outra classe. Neste caso, a classe Motorista herda as caractersticas da classe Funcionrio.
Segundo Guedes (2006), a generalizao, tambm conhecida como herana, pode ser simples ou mltipla.
Herana simples A subclasse herda estrutura e ou comportamento de uma nica superclasse. Herana mltipla A subclasse herda a estrutura e o comportamento de mais de uma superclasse.
Mas talvez voc esteja se questionando: o que uma subclasse pode herdar de uma superclasse?
A subclasse pode herdar atributos, operaes e relacionamentos. Alm das caractersticas herdadas, a subclasse possui atributos, operaes ou relacionamentos adicionais.
168
Na figura 6.18, a classe Imvel possui atributos e operaes comuns, como rea, endereo e IPTU. Mas Apartamento possui caractersticas especficas, como valor do condomnio e fundo de reserva. O mesmo acontece com a classe Casa. Assim, as subclasses possuem todas as caractersticas da superclasse, e, alm disso, possuem caractersticas especficas de cada subclasse. As subclasses so especializaes da superclasse Imvel.
cd Data Model Casa num_andares: int Tipo_Construo: char Apartamento fundo_reserva: float num_apto: char valor_condomnio: double
Imv el rea: double Bairro: char cod_proprietrio: int cdigo: int descrio: char dormitrios: int Endereo: char IPTU: float valor: int
Figura 6.18 Relacionamento de herana Fonte: Elaborao da autora (2008).
Unidade 6
169
Agora, relembrando o sistema da videolocadora, observe os relacionamentos entre as classes candidatas propostas:
cd Data Model Cliente Bairro: char Cdigo: int Endereo: char Nome: char Telefone: int Locao Faz 1..* Data_Devoluo: date Data_Locao: date Valor: float 1..* Contm
Item_Locao
0..* Compe Filmes Ator_Principal1: char Ator_Principal2: char Cdigo: int Diretor: char Durao: int Estilo: char Idioma: char Ttulo: char Cpias 1..* Data_Compra: date Nmero: int Status: int
Possuem
Figura 6.19 Diagrama de classes sistema videolocadora Fonte: Elaborao da autora (2008).
170
Lembra-se do exemplo sobre o sistema bancrio? Imagine uma situao em que voc convidado a desenvolver um projeto para um caixa eletrnico bancrio. O projeto prev o atendimento dos seguintes requisitos funcionais:
O sistema deve permitir ao cliente a emisso de saldo somente da conta corrente. O sistema deve permitir ao cliente a emisso de extrato somente da conta corrente. O sistema deve permitir a atualizao dos dados cadastrais do cliente. O sistema deve permitir o saque em dinheiro no caixa eletrnico. O sistema deve permitir a consulta a toda a movimentao financeira do cliente (conta corrente, poupana e aplicaes) no caixa eletrnico. O acesso s funcionalidades do sistema deve ser possvel somente aps a verificao da conta e senha do cliente ou gerente.
Observe o possvel diagrama de classes para esse exemplo:

cd Data Model - banco Pessoa endereo: char estado_civil: int nome: char rendimento: double telefone: char tippes: boolean tem 1..* Conta Agncia: int Data_Abertura: date Nmero: int Saldo: double Senha: int Tipo: int registra 0..* -
Mov imento data_mov: date histrico: int nro_conta: int valor: double
Fsica CID: char CPF: long -
Jurdica CNPJ: long -
Poupana Nro_sorteio: int Rendimento: double -
Conta_Corrente limite: double Nro_ext_mes: int Nro_saques_mes: int TxJuro: float
Figura 6.20 Diagrama de classes sistema caixa eletrnico Fonte: Elaborao da autora (2008).
Unidade 6
171
Seo 4 Como ocorre a diviso das classes do modelo de anlise?

A diviso, ou categorizao, das classes est fortemente relacionada com as futuras mudanas no sistema. Com a diviso das classes a partir de suas responsabilidades, no momento em que forem necessrias alteraes no sistema, estas passam a ser pontuais. As classes do modelo de anlise podem ser divididas em trs camadas: a) classes de Fronteira; b) classes de Entidade; c) classes de Controle. Conhea a partir de agora as caractersticas de cada uma dessas camadas de classes. a) Classes de fronteira Tratam da comunicao com o ambiente do produto, modelando as interfaces do produto com usurios e outros sistemas (entrada e sada de dados).
Cada formulrio usado pelo programa um objeto criado por uma classe de fronteira, que faz a interface entre um ator e o sistema, uma para cada formulrio, relatrio ou interface com outro sistema.
172
Segundo Bezerra (2002), as classes de fronteira tm tipicamente as seguintes responsabilidades:
notificar as classes de controle sobre eventos gerados externamente ao sistema; notificar atores do resultado da interao entre os objetos internos.
So alguns exemplos de classes de fronteira: Formulrio Cadastro Cliente, Formulrio Cadastro DVDs e Formulrio Movimentao DVDs. b) Classes de entidade Modelam informaes persistentes do sistema, normalmente independentes da aplicao ou das entidades do mundo real. As classes de entidade criam objetos que gerenciam dados. Assim, voc pode v-los de forma correspondente ao banco de dados. Um ator no tem acesso a uma classe Entidade e a comunicao ocorre por meio de outros objetos. Exemplos de classes de entidade: Cliente, Filmes, Locao, Cpias. As classes de entidades armazenam as informaes mantidas pelo sistema. Tambm importante para o projeto uma definio da performance esperada no acesso aos objetos da classe.
Lembra-se do estudo de caso apresentado no artigo A importncia de utilizar UML para modelar sistemas: estudo de caso, estudado na unidade 5? Ele se encontra na midiateca. Esse estudo discorre sobre um sistema de vendas de CDs musicais pela internet. A figura 6.21 mostra as classes persistentes encontradas para esse projeto.
Unidade 6
173
Figura 6.21 Diagrama de classes Persistente Fonte: Figueira (2005).
c) Classes de controle Objetos de controle so pontes de comunicao entre objetos de fronteira e objetos de entidade. Essas classes so responsveis por controlar a lgica de execuo correspondente ao caso de uso. Voc pode dizer que elas representam a lgica do caso de uso, requisitam e consultam informaes das classes de entidade e de interface e no gerenciam dados nem tm sada visvel. Bezerra (2002) define algumas responsabilidades para as classes de controle:
As classes de controle atuam entre as classes de interface e as de negcio, isto , uma para cada caso de uso.
realizar monitoraes respondendo a eventos gerados pelas classes de fronteira; coordenar a realizao do caso de uso por meio de mensagens das classes de entidade e de fronteira; assegurar que as regras de negcio do caso de uso esto sendo seguidas;
coordenar a criao de associaes entre classes de Entidade.

174
So exemplos de classes de controle: Controlador Cliente, Controlador Entrada DVDs, Controlador Sada DVDs, Controlador Atrasos. O uso da classe de controle opcional em um sistema. Voc deve avaliar claramente. O objetivo da classe de controle comportar a lgica e as regras de negcio complexas. Isso significa que aes como incluso, alterao, consultas de cadastros podem tranquilamente ser implementadas em uma classe de fronteira.
Voc se lembra do software de declarao do imposto de renda disponibilizado pelo governo federal? As interfaces do sistema com o usurio podem ser descritas pelas classes de Fronteira (tela de cadastro, de registro de bens, entre outras), os dados existentes sobre o trabalhador, rendas, despesas e bens so descritos pelas classes de entidade e o clculo do imposto de renda ser descrito na classe de controle.
Lembre-se de que os casos de uso complexo devem ser escritos em classes de Controle.
A representao das classes na UML se d pela seguinte notao:
Figura 6.22 Esteretipos da classe Fonte: Elaborao da autora (2008).
Unidade 6
175
Voc deve estar se perguntando: por que uma classe de entidade no deve cuidar de aspectos relacionados s entradas e sadas? Por que sugerido o uso de uma classe de fronteira? Imagine que no sistema de videolocadora a aplicao foi desenvolvida para desktop, mas agora o cliente deseja que o software rode na internet (o que significa uma interface bastante diferente). Bem, se o projeto foi constitudo considerando as trs classes de Domnio, a equipe de desenvolvimento deve apenas reconstruir as classes de Fronteira, na qual temos as telas do sistema. Isso contribui para a eficincia da manuteno do produto. Para o sistema de videolocadora, voc pode ter algumas classes candidatas:

classes de entidade: Filme, Cliente, Locao, Cpias; classes de fronteira: interface para o cadastro do Cliente (Form_Cliente), interface para o cadastro do Filme (Form_Filme), interface para o movimento da locao (Form_Locao) so alguns exemplos; classes de controle: o cadastro do cliente pode ter uma classe de controle para implementao de mtodos (Ctrl _Cliente) assim como o movimento da locao (Ctrl_ Locao).
O que fazer ento depois de realizada a etapa de identificao das classes?
Finalizada a etapa de identificao das classes de controle, fronteira e entidades, voc pode organizar essas classes em pacotes lgicos.
Pacotes lgicos so agrupamentos de elementos de um modelo. O uso de pacotes agrupa classes que possuem um critrio comum, facilitando a comunicao.
176
Quando uma coleo de classes colabora entre si para realizar um conjunto coeso de responsabilidades, ela pode ser vista como um subsistema. De acordo com Pressman (2002), quando visto de fora, um subsistema pode ser tratado como uma caixa-preta que contm um conjunto de responsabilidades e suas prprias colaboraes.
Figura 6.23 Pacotes lgicos Fonte: Elaborao da autora (2008).
importante ressaltar que o pacote deve ter um nome nico e textual.
Seo 5 O que diagrama de objetos?

Os diagramas de objetos so como uma fotografia de um sistema orientado a objetos em execuo.
O diagrama de objetos um complemento do diagrama de classes, pois fornece uma viso dos valores armazenados pelos objetos de um diagrama de classes em um determinado momento da execuo de um processo de software (GUEDES, 2006).
Unidade 6
177
Em alguns livros, voc vai encontrar o nome diagrama de instncias como sinnimo de diagrama de objetos.
Quando fazer uso desse diagrama? Esse diagrama pode ser bastante til quando voc estiver modelando uma estrutura de dados complexa. O diagrama de objetos representado por um retngulo com dois compartimentos. Na parte superior, voc identifica o objeto (sublinhado). Na parte inferior, voc referencia os atributos com seus valores. Analise a figura a seguir. Note que na parte superior esto as trs classes associadas: Pedido, itemPedido e Produtos. A instncia Pedido est associada a duas instncias do itemPedido, que consequentemente est ligada a uma instncia do Produto.
Figura 6.24 Diagrama de objetos Fonte: Adaptado de Bezerra (2000).
Qual a nomenclatura a ser utilizada na especificao de um diagrama de objetos?
178
Existem duas possibilidades: os atributos e as operaes. a) Atributos Os atributos foram apresentados at o momento utilizando-se apenas o nome, mas com certeza em seu projeto voc ter de explicit-los de forma mais detalhada. A sintaxe a ser apresentada :
[1] visibilidade nome:tipo=valor inicial
A visibilidade refere-se ao nvel de acesso: quantos atributos de um objeto estaro visveis a outros objetos. Pode ser:
+ Pblica Todos tm acesso, podendo ser utilizado por operaes declaradas dentro de outras classes. # Protegida Pode ser acessado apenas por operaes dentro da prpria classe, pelas classes da hierarquia e pelas classes do pacote. Privada S pode ser acessado por operaes dentro da prpria classe.
O uso das propriedades de visibilidade apoia um dos conceitos da orientao a objetos: o encapsulamento. Assim, voc s deixa visvel atributos realmente necessrios aos demais objetos enquanto outros atributos tornam-se invisveis.
Figura 6.25 Nomenclatura de atributos Fonte: Elaborao da autora (2008).
Unidade 6
179
Sobre a figura 6.25, acompanhe:

Nome Identificador do atributo. Tipo O tipo depende da linguagem de programao. Mas comum o uso de uma tipologia abstrata em que so definidos os tipos como inteiro, real, caractere, string, float, data ou outra classe. Valor Inicial Voc pode informar um valor inicial para um atributo. Quando o objeto da classe for instanciado, ele pegar o valor automaticamente (veja limiteCredito).
b) Operaes As operaes representam o conjunto de funcionalidades da classe. Para cada operao, especifica-se sua assinatura:

Nome Identificador para o mtodo. Tipo Quando o mtodo tem um valor de retorno, o tipo desse valor. Lista de argumentos Quando o mtodo recebe parmetros para sua execuo, o tipo e um identificador para cada parmetro. In parmetro de entrada; out para um parmetro de sada; e inout para parmetros de entrada que podem ser modificados. Visibilidade Utiliza-se dos mesmos recursos usados para os atributos, definindo o quo visvel uma operao a partir de objetos de outras classes.
Figura 6.26 Exemplo de operao Fonte: Elaborao da autora (2008).
180
Sntese
Agora que voc j estudou a modelagem de classes, aproveite para praticar os conhecimentos conquistados nesta unidade realizando as atividades propostas a seguir. Nesta unidade, voc aprendeu que um objeto algo que tem estado, comportamento e identidade. Uma classe uma definio abstrata de um conjunto de objetos que compartilham uma estrutura e um comportamento comuns todo sistema, porm, engloba muitos objetos que cooperam entre si para produzir a funcionalidade desejada. A produo das funcionalidades s possvel pela existncia de diferentes tipos de relacionamentos, como a associao, a dependncia e a generalizao. Entre as caractersticas do relacionamento de associao, a multiplicidade uma das mais importantes. A multiplicidade indica o nmero de instncias que participam dessa associao. Voc tambm viu que as operaes determinam como um objeto age e reage s mensagens que ele recebe e que possvel agrupar esses objetos e classes em pacotes lgicos, criando uma viso mais clara do sistema. Voc tambm estudou a importncia de modelar o sistema em diferentes camadas, como as camadas de Controle, Fronteira e Persistente. Essa modelagem cuidadosa facilita futuras manutenes no seu projeto. Em resumo, esta unidade englobou conceitos e abstraes relacionadas aos aspectos estticos do sistema. Mas, para o bom andamento do projeto, necessrio ter uma viso dinmica desses objetos.
Unidade 6
181
Leia com ateno os enunciados e realize as questes propostas. 1) Assinale a afirmativa correta. a) ( ) Uma classe um conjunto de objetos, que, por sua vez, so identificados por comportamento e estado e nem sempre so nicos. Uma classe um conjunto de objetos que compartilham caractersticas de atributos, operaes, relaes e semntica. possvel dizer que so exemplos de classes em um sistema Universitrio: Professor, Aluno, Nome Aluno. possvel dizer que so exemplos de instncias de uma classe Professor: Joo da Silva, Ana Luiza.
b) ( ) c) ( ) d) ( )
2) Relacione a primeira coluna com a segunda, indicando a camada mais adequada para cada ocorrncia. A. Classe de Ccontrole B. Classe Persistente C. Classe de Fronteira ( ) ( ) ( ) ( ) ( ) ( ) Mensagens de erro para o usurio. Clculo da folha de pagamento. Cria ou destri um objeto (exclui produto). Dados do produto. Telas de consulta de produtos. Dados do cliente.
182
3) Relacione a primeira coluna com a segunda, indicando as caractersticas dos diferentes relacionamentos: A. Associao B. Associao ternria C. Agregao D. Herana E. Dependncia F. Associao recursiva G. Classes associativas a) ( ) As classes esto ligadas a associaes e no a outras classes. b) ( ) Neste relacionamento, ocorre a associao de trs classes ao mesmo tempo. c) ( ) Uma das classes do relacionamento uma parte da classe ou est contida em outra classe. d) ( ) Este relacionamento possvel entre dois ou mais elementos em que uma classe Cliente dependente de algum servio da classe Fornecedora. e) ( ) Neste caso, os objetos da prpria classe esto se relacionando. f) ( ) Quando ocorre este tipo de relacionamento, a subclasse herda as propriedades da superclasse, principalmente atributos e operaes. g) ( ) Ocorre quando duas classes ou mesmo uma classe, consigo prpria, apresenta interdependncia.
4) Com base no texto a seguir relacionado Clnica Bem-Estar: a) Identifique as classes persistentes (nome e descrio da classe): b) A partir dessa identificao, construa o diagrama de classes Persistentes, apontando os relacionamentos existentes entre as classes.
Unidade 6
183

184
Unidade 6
185
Saiba mais
Para aprofundar as questes abordadas nesta unidade, voc poder pesquisar: BEZERRA, E. Princpios de anlise e projeto de sistemas com UML. So Paulo: Campus, 2002. (Ler captulos 5, 6 e 8.) BOOCH, G. ; RUMBAUGH, J. ; JACOBSON, I. UML: guia do usurio. So Paulo: Campus, 2000. (Ler captulos 8 e 9.) PAULA FILHO, Wilson de Pdua. Engenharia de software. So Paulo: Campus, 2001. (Ler captulo 4.) Voc encontra uma boa leitura sobre modelagem de chaves no captulo 4 do livro UML: uma abordagem prtica, de Gilleanes T. A. Guedes.
186
UNIDADE 7
Modelos de interaes
Entender os elementos existentes no modelo de interao oferecido pela UML. Compreender as caractersticas existentes entre as diferentes mensagens utilizadas na comunicao entre objetos. Perceber quando o uso de diagramas de interao pode ser interessante para a compreenso de um projeto de software.
Sees de estudo
Seo 1 Seo 2 Quais so os elementos do modelo de interao? O que diagrama de interao?

A modelagem de casos de uso identifica o que o sistema deve fazer e para quem deve ser feito. Apesar de fazer essa descrio, no so especificados mais detalhes relacionados ao comportamento interno do sistema na execuo das funcionalidades. O modelo de classes de domnio estudado na unidade 6 agrega ao projeto a viso esttica e estrutural do sistema. Sob essa viso, voc construiu a definio das classes e responsabilidades. Apesar de voc j ter at aqui uma ideia clara do sistema com esses dois modelos, nenhum aspecto relacionado ao mecanismo de comunicao e comportamento entre objetos foi tratado at este momento. Por isso, nesta unidade, voc vai estudar sobre o modelo de interaes, que apresenta as mensagens trocadas entre os objetos na execuo de um determinado cenrio. O uso do modelo de interaes procura descrever o modelo dinmico do sistema propondo a descrio, inclusive temporal, da troca de mensagens entre objetos.
Seo 1 Quais so os elementos do modelo de interao?

Segundo Booch (2000), interao como um comportamento que abrange um conjunto de mensagens trocadas entre um conjunto de objetos em um determinado contexto para a realizao de um propsito.
188
Figura 7.1 Interao entre objetos Fonte: Elaborao da autora (2008).
A interao empregada para a modelagem do fluxo de controle de uma operao, uma classe, um componente, um caso de uso ou do sistema como um todo. O uso de interaes tambm introduz mensagens que so enviadas de objeto a objeto. Essas mensagens envolvem a chamada a uma operao ou o envio de um sinal. No decorrer do seu estudo, voc j leu vrias vezes a palavra mensagem, certo? provvel que voc j tenha uma ideia sobre o significado dessa palavra, e, por isso, nessas trs ltimas unidades parecia irrelevante conceituar esse substantivo. Mas, nesta unidade, essa palavra se torna o elemento fundamental do modelo.
Segundo Bezerra (2002), uma mensagem uma solicitao de execuo de uma operao em outro objeto. Um objeto pode ainda enviar uma mensagem para si mesmo (mensagem reflexiva).
O uso de uma mensagem em um diagrama de interao permite a passagem de informaes que so repassadas para a operao, que ser executada no objeto receptor.
Figura 7.2 Interao entre objetos de operao de voo Fonte: Elaborao da autora (2008).
Unidade 7
189
Na figura 7.2, so considerados objetos: t:ControladorTrfegoAreo e p:PlanoVoo; 1: getPosioNoHorrio() e 1.1 : getltimoCheckpoint() so consideradas mensagens. Os nmeros 1 e 1.1 nas mensagens so nmeros de sequncia usados para organizar a sequencializao das mensagens. As mensagens so representadas graficamente por linhas com uma direo e quase sempre incluem os nomes de suas operaes, os objetos e seus vnculos, como ilustra a figura 7.2, na qual a troca de mensagens ocorre entre os objetos Plano Voo e Controlador Trfego Areo. Os objetos de uma interao desempenham determinados papis, como voc pode perceber na figura 7.3. Nessa figura, a classe Pessoa representa o papel do empregado e a classe Empresa, o papel do empregador. J os vnculos constituem normalmente uma instncia de uma associao. Um vnculo especifica um caminho pelo qual um objeto pode enviar uma mensagem para outro objeto ou para o mesmo objeto (BOOCH, 2000). Observe a figura a seguir:
Figura 7.3 Interao entre objetos Fonte: Booch (2000).
190
Quais so os tipos de mensagem?
A notao UML descreve a possibilidade de trs tipos de mensagens (BEZERRA, 2002):
Mensagem simples Este tipo de mensagem utilizado quando a natureza da mensagem irrelevante. Mensagem sncrona Indica que o objeto remetente espera que o objeto receptor processe a mensagem antes de recomear o seu processamento. Neste caso, o objeto receptor ficar bloqueado at que a requisio seja atendida. Mensagem assncrona O objeto remetente no espera resposta para prosseguir seu processamento.
A mensagem representada por uma seta em que o sentido do objeto remetente para o objeto receptor. As mensagens possuem um rtulo que procura especificar as informaes que devem transmitir. Voc pode usar a seguinte sintaxe:
Expresso-sequncia recorrncia: v := mensagem
Unidade 7
191
Assim, tem-se: a) Expresso-sequncia As mensagens so passadas de um objeto para outro. Esse fluxo de mensagens forma uma sequncia. As sequncias devem ter um ponto de partida indicando o incio do processo. A expresso de sequncia elimina ambiguidades acerca de quando a mensagem foi enviada em relao s demais.
1: AtenderChamado() Sequncia o nmero 1, a expresso AtenderChamado()
Figura 7.4 Sequenciamento das mensagens Fonte: Booch (2000).
Na figura 7.4, observe a numerao das mensagens (1 e 2), que indica a direo e a ordem em que elas acontecem. b) Recorrncia s vezes o envio de uma mensagem est condicionado ao valor de uma expresso lgica (verdadeiro ou falso) ou ao nmero de vezes que a mensagem ser enviada. Se a recorrncia for uma clusula-condio, ento a mensagem ser enviada somente se a condio for verdadeira.
192
Sua sintaxe sempre entre colchetes: [clusula-condio]

[existe produto estoque] EfetuarVenda() A repetio ordenada pelo uso de asterisco: *[clusula iterao] *[enquanto Nmero_Itens < 10] InserirItem()
c) Varivel Identifica uma varivel que recebe o valor de retorno da operao executada pelo receptor.
1.2.1: Z :=verificarEstoque(e) A varivel Z vai receber o retorno da operao verificarEstoque.
Quando uma mensagem enviada, voc est especificando uma comunicao entre objetos, que possuem uma expectativa de realizao de uma atividade. Quando a mensagem passada, o resultado uma ao na forma de uma instruo executvel. Voc pode fazer a modelagem de vrios tipos de ao, como:
Call (mensagens sncronas) Solicita uma operao em um objeto. Send (mensagens assncronas) Envia um sinal para um objeto. Create Cria um objeto. Destroy Destri um objeto. Return (retorno) Retorna o controle a quem ativou um Call.
Unidade 7
193
Seo 2 O que Diagrama de Interao?

Um diagrama de interao mostra uma interao formada por um conjunto de objetos e seus relacionamentos, incluindo as mensagens que podero ser trocadas entre eles. O diagrama mostra como devem ser implementadas as aes focalizando os objetos que devem ser criados para a implementao da funcionalidade requerida no caso de uso (LIMA, 2005).
Um diagrama de interao pode modelar um caso de uso, assim como pode ser necessrio o uso de vrios diagramas para modelar a interao de um caso de uso que possui diferentes cenrios.
Existem dois diagramas de interao: o diagrama de sequncia e o diagrama de comunicao. a) Diagrama de sequncia O diagrama de sequncia mostra a sequncia de eventos que ocorrem em um determinado processo, e apresenta quais condies devem ser satisfeitas e quais mtodos devem ocorrer entre os objetos envolvidos e sua ordem durante a execuo do processo (GUEDES, 2006). O diagrama de sequncia descreve o comportamento interno, mostrando os eventos entre objetos, mas omite a associao entre esses objetos. A notao usada pela UML para representar o diagrama de sequncia utiliza-se de atores, objetos, classes e mensagens, conforme mostra a figura a seguir.
Para construir um diagrama de sequncia, necessria a prvia definio do diagrama de classes com a indicao das operaes associadas. A descrio sempre uma interao dentro de uma unidade de tempo. ideal para a especifi-cao de processos que ocorrem em tempo real.
194
Figura 7.5 Elementos grficos do diagrama de sequncia Fonte: Elaborao da autora (2008).
Atores Participam do diagrama de sequncia opcionalmente, dependendo do cenrio do caso de uso. Objetos A ordem na qual os objetos aparecem no predefinida, mas normalmente utiliza-se a ordem da esquerda para a direita: ator, objetos de fronteira, objetos de controle, objetos de entidade e atores secundrios. Classes Aparece no diagrama quando uma mensagem for endereada para a classe e no para o objeto. Linhas de vida Cada objeto aparece no topo de uma linha vertical tracejada, a linha de vida. Mensagem So as linhas horizontais com flechas que ligam uma linha de vida a outra. As flechas horizontais so rotuladas com as mensagens.
Unidade 7
195
1.3
Figura 7.6 Diagrama de sequncia Fonte: Elaborao da autora (2008).
Focos de Controle Os focos de controle so as caixas retangulares que esto sobre a linha de vida do objeto. O foco de controle indica o tempo necessrio para que o objeto realize uma ao. O incio do foco deve estar na altura da flecha de mensagem. O final deve coincidir com o final da atividade realizada pelo objeto.
A figura 7.7 mostra o diagrama de sequncia de um caso de uso para registro de uma venda. O ator Atendente envia uma mensagem para totalizar o objeto Venda. Em seguida, o ator dispara a mensagem para registrar o modo de venda para o objeto Venda. A partir de ento, uma recorrncia condicional estabelecida: se a venda for a prazo, envia a mensagem Inserir, sendo o parmetro o prprio objeto Venda para o objeto Contasareceber. Se a venda for vista, envia a mensagem registrapagamento para o objeto Caixa.
196
Figura 7.7 - Diagrama de sequncia Fonte: Pdua (2001).
Agora observe a figura a seguir:
Figura 7.8 Diagrama de sequncia Fonte: Pdua (2001).
Unidade 7
197
No diagrama da figura 7.8, so utilizadas classes de Fronteira (Tela de Mercadorias), classes de Controle (Controlador de Mercadorias e Pedido de Compra) e classes Persistentes (Mercadoria e Fornecedor). Todas as mensagens esto sequenciadas (1-5) indicando a ordenao temporal das mensagens. Lembre-se de que o diagrama de sequncia est baseado na descrio do caso de uso, ento ele um reflexo do que foi documentado. Observe o diagrama de sequncia para o sistema de videolocadora para o caso de uso Gerenciar Locaes. Perceba que foram usadas apenas as classes de Fronteira e de Entidade.
sd Sequncia
Atendente Form_Locacao Cliente Locacao Item_Locacao
1. Verifica Existencia Cliente() 2.Consulta_existencia() 3. Verifica_Atrasos() 4. Registra_Locacao() 5. Locar()
loop Enquanto nro. filmes < 10 6. Registra_Locacao() 7. Thrue
8. Mensagem ("Locacao registrada !")
Figura 7.9 Diagrama de sequncia para o sistema de videolocadora Fonte: Elaborao da autora (2008).
b) Diagrama de colaborao O diagrama de colaborao um modo alternativo para representar a troca de mensagens entre um conjunto de objetos. O diagrama de colaborao sempre mostra os objetos relevantes para a execuo do caso de uso (GUEDES, 2006).
198
Nesse diagrama, a ordem em que as mensagens foram enviadas no apresentada, pois no existe a dimenso de tempo (linhas de vida do diagrama de sequncia), o que obrigatoriamente temse expresses de sequncia em todas as mensagens (1, 1.1, 1.2...). Diagramas de colaborao apresentam nfase no sistema, ou seja, so usados para obter uma viso geral do sistema:
os objetos que so criados durante uma colaborao so especificados como {new}; os que so destrudos durante uma colaborao so especificados com {destroyed}; e os que so criados e destrudos na mesma colaborao so especificados com {transient}.
A leitura do diagrama ou a sequncia das mensagens organizada pelas setas no rtulo da mensagem.
Figura 7.10 Exemplo de um diagrama Fonte: Adaptado de Ambler (1998).
O objeto MainWindow recebe a mensagem NewCustomer e cria um objeto Customer. Um CustomerWindow criado e o objeto Customer ento passado para o CustomerWindow, o qual atualiza os dados do Customer. No exemplo a seguir, voc ver o diagrama de colaborao de um sistema de emprstimo para uma biblioteca.
Unidade 7
199
Figura 7.11 Diagrama de comunicao Fonte: Liesenberg (2005).
O diagrama inicia a comunicao pela mensagem confirmarEmprstimo e finaliza-se pela mensagem adicionarTransiao no objeto Log. Observe que o diagrama apresenta a relao existente entre os diferentes objetos de forma bastante legvel pelo uso da numerao e do direcionamento das mensagens por meio de setas.
Afinal, diagrama de sequncia ou diagrama de colaborao?
Um diagrama de sequncia de sistema representa uma sucesso de eventos de entrada, gerados por um ator ao executar um fluxo de um caso de uso. Nos diagramas de sequncia, existe uma linha de vida do objeto, que a linha tracejada vertical que representa a existncia de um objeto em um perodo de tempo. Alm disso, existe o foco de controle que mostra o perodo durante o qual um objeto est desempenhando uma ao, diretamente ou por meio de um procedimento subordinado.
200
Esse diagrama interessante na descrio de uma sequncia particular de funcionamento, mas pode ser confuso quando existem muitas sequncias alternativas. Os diagramas de colaborao sempre apresentam o caminho que indica como um objeto est vinculado a outro. Alm disso, existe o nmero de sequncia para indicar a ordem temporal de uma mensagem. Se voc precisa de um diagrama que demonstre o fluxo de eventos no decorrer do tempo, ento deve utilizar o diagrama de sequncia; se a nfase for o contexto do sistema, a melhor opo o diagrama de colaborao.
Quer conhecer mais? Para conhecer um pouco mais sobre os modelos de interao, acesse a Midiateca. O texto Exemplo Sequencia&Colaborao apresenta o diagrama de colaborao e de sequncia para um sistema de videolocadora.
Agora, para praticar os conhecimentos conquistados nesta unidade, realize a seguir as atividades propostas.
Sntese
Nesta unidade, voc foi apresentado ao modelo dinmico do projeto. Foi possvel perceber que essa viso aborda aspectos internos do sistema, chegando ao nvel das funes que sero implementadas futuramente. O uso de diagramas de interao permite visualizao e entendimento do funcionamento temporal da troca de mensagens entre os diversos objetos. Voc pode representar as mensagens por
Unidade 7
201
meio de diferentes notaes, em que possvel apresentar relaes sncronas, assncronas e de retorno entre os objetos. O uso da representao temporal da troca das mensagens pode ou no ser representado. Se a dimenso de tempo fundamental para o entendimento, voc pode utilizar o diagrama de sequncia. Mas se a dimenso do contexto do sistema o mais importante, utilize o diagrama de colaborao.
Leia com ateno os enunciados e, em seguida, realize as questes propostas. 1) Relacione os conceitos a seguir. Observe que uma mesma opo pode se repetir. 1. Clusula condio 2. Mensagem 3. New 4. Destroyed 5. Transient 6. Linhas de vida 7. Clusula interao 8. Call 9. Send a) ( ) So as linhas horizontais com flechas que ligam uma linha de vida a outra. b) ( ) Objetos so destrudos durante uma colaborao. c) ( ) Os objetos aparecem no topo de uma linha vertical tracejada. d) ( ) 1:[preo < 10,00]:Venda aVista (produto). e) ( ) Utilizado para mensagens sncronas. f) ( ) Objetos so criados e destrudos durante uma colaborao. g) ( ) 2:* [l_codigo]. h) ( ) Utilizado para mensagens assncronas. i) ( ) Objetos so criados durante uma colaborao.
202
2) Construa o diagrama de sequncia da Clnica Bem-Estar para o caso de uso Agendar Horrio.
Unidade 7
203
3) correto afirmar sobre interao: a) ( ) b) ( ) Prope a troca de mensagens entre atores. Mensagens so trocadas entre um conjunto de objetos em um determinado contexto para a realizao de um propsito. Pode ser definida como uma solicitao de execuo de uma operao em outro objeto. Na mensagem sncrona, o objeto remetente no espera resposta para prosseguir com seu processamento; j na assncrona o objeto remetente espera que o objeto receptor processe a mensagem antes de recomear o seu processamento.
c) ( ) d) ( )
Saiba mais
Caso voc tenha interesse em aprofundar seus estudos sobre os assuntos tratados nesta unidade, consulte: BEZERRA, E. Princpios de anlise e projeto de sistemas com UML. So Paulo: Campus, 2002. (Ler captulo 7.) BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usurio. So Paulo: Campus, 2000. (Ler captulos 18 e 27.)
204
UNIDADE 8
Modelos de estados
Reconhecer objetivos e caractersticas existentes na modelagem da viso dinmica do projeto. Compreender a notao utilizada nos diagramas que complementam a especificao do modelo dinmico do sistema. Reconhecer as possibilidades de utilizao e as notaes envolvidas no diagrama de estados e no diagrama de atividades.
Sees de estudo
Seo 1 Seo 2 Seo 3 Modelo de estados Modelo de atividades Consideraes sobre o uso da orientao a objetos

O modelo dinmico do sistema completa-se a partir de cinco diagramas: o de atividades, o de sequncia, os de colaborao, o de estados e o de casos de uso. Cada um desses diagramas especifica e esclarece aspectos diferentes do sistema. At este momento, voc estudou trs desses diagramas (casos de uso, colaborao e sequncia). Nesta unidade, sero apresentados os diagramas de transio de estado que modelam o comportamento de um objeto e o diagrama de atividade que modela a sequncia geral de aes para vrios objetos e casos de uso. Imagine um semforo de rua. possvel prever trs estados para ele: verde, amarelo e vermelho. O diagrama que permite especificar essa transio entre os eventos o diagrama de estados. A mudana de estado dispara aes diferentes do sistema, que, por sua vez, modificam o estado do objeto (sinal vermelho: ao parar!). J os diagramas de atividade conseguem especificar situaes, como paralelismos e sincronizaes, que so impossveis de serem especificadas no diagrama de casos de uso.
Seo 1 Modelo de estados

Os objetos de um sistema modificam seu estado de forma anloga a objetos do mundo real. Pense no cozimento do macarro. Em seu primeiro estado, ele est duro, pois no est cozido. Depois de cozido ele amolecer e assim entra em outro estado. Essa modificao chamada de transio entre estados. Voc pode dizer que um estado representa o resultado de atividades executadas por um objeto, determinada pelos valores de seus atributos e pela sua ligao com outros objetos (FURLAN, 1998).
206
Os objetos do sistema passam por vrios estados. Essa transio faz com o prprio sistema se modifique. Na verdade, a transio ocorre porque um evento (mensagens, timer, erros, condies sendo satisfeitas, entre outros) disparado no sistema faz com que o objeto realize determinadas aes, que fazem com que o objeto modifique seu estado.
O diagrama de estados (DTE) deve ser utilizado somente para algumas classes, ou seja, somente para aqueles que possuem estados bem definidos e onde a mudana de estados propicia a mudana do comportamento das classes.
No diagrama a seguir, possvel mapear os possveis estados dos objetos e as aes e condies necessrias para que ocorra a mudana de estados entre os objetos.
Figura 8.1 Diagrama de estados elevador Fonte: Elaborao da autora (2008).
O DTE dessa figura mostra:

os estados de um objeto; os eventos ou as mensagens que causam transio; as aes que resultam de uma mudana de estado.
Unidade 8
207
Quais so os componentes de um diagrama de estados?
A existncia de estado em um objeto indica a ordem em que as operaes so executadas. No DTE, importante a descrio da ordem das operaes no tempo, pois essa ordem pode formalizar a caracterizao do comportamento de um objeto. O DTE utiliza-se de alguns componentes, so eles: a) Estado uma situao na vida de um objeto durante a qual ele satisfaz alguma condio ou realiza alguma atividade em resposta a um evento ou espera a ocorrncia de algum evento. No diagrama DTE, o estado representado por um retngulo arredondado.
Emitindo nota/O macarro est cozido/O menino est nadando. Objetos: nota, macarro, menino. Estado: emitindo, cozido, nadando.
Figura 8.2 Exemplos de estados Fonte: Elaborao da autora (2008).
b) Estado inicial O estado inicial de um objeto ocorre quando ele criado. Ele representado por um pequeno crculo fechado. Indica a partir de onde o DTE deve ser lido. Para cada DTE, voc s tem um estado inicial.
208
Figura 8.3 Estado inicial Fonte: Elaborao da autora (2008).
c) Estado final O estado final indica o final do ciclo de vida de um objeto. Ele representado por um crculo eclipsado. O estado final opcional e pode existir mais de um em um mesmo DTE.
Figura 8.4 Estado final Fonte: Elaborao da autora (2008).
Figura 8.5 Exemplo DTE Fonte: Elaborao da autora (2008).
No diagrama da figura 8.5, o estado final acontece logo depois da atualizao do estoque que modifica o estado do objeto em estoque. d) Transio Quando a ao ou atividade de um estado est completa, o fluxo de controle passa ao estado seguinte de ao. Especifica-se esse fluxo utilizando transies para mostrar o caminho de um estado de ao ou de atividade para o estado seguinte. Graficamente voc representa a transio por uma linha simples com uma direo. As transies no ativadas podem ter condies de proteo, significando que a transio ser iniciada somente se essa condio for satisfeita.
Unidade 8
209
Imagine quando voc est no banheiro pronto para iniciar o banho. Automaticamente voc pensa em duas possibilidades: o estado do chuveiro est ligado ou desligado. Em outras palavras: voc pode representar isso em um diagrama de estados. Nesse DTE, o evento girar a torneira; e as aes so abrir e fechar.
Figura 8.6 Exemplo DTE tomar banho Fonte: Elaborao da autora (2008).
Furlan (1998) define quatro possibilidades de eventos em um DTE:
Recibo de sinal explcito do outro objeto So gatilhos de uma transio (recibo de mensagens). O objeto recebe um sinal de outro objeto e muda de estado. Neste tipo de evento, o objeto que envia a mensagem fica esperando a sua finalizao. Passagem de perodo designado de tempo O evento acontecer aps um determinado perodo de tempo, disparando a mudana de estados. Nesse tipo de evento, utiliza-se a clusula after. Por exemplo: se voc tiver o evento after (1 minuto), significa que o evento ser executado um minuto depois de o objeto entrar no estado atual. Uma condio tornando-se verdadeira mostrada uma condio de guarda em uma transio de estados. Nesse caso, voc utiliza a clusula when, por exemplo, when (quantidade < 5), e ento a transio disparada se a quantidade for menor que 5. Recibo de chamada de operao pelo prprio ou por outro objeto mostrada como uma assinatura de evento em transio de estado. Um objeto solicita um servio a outro objeto.
210
Figura 8.7 DTE para matrcula de um curso Fonte: Esmin (1999).
Quando voc possui uma ao, ela possui um processo, que a transio do estado. Essa transio normalmente um processo de curta durao e que no pode ser interrompido. Muitas vezes, em vez de aes voc pode ter atividades relacionadas. Quando isso acontece, voc tambm possui um processo associado, mas o processo est associado a um estado. O processo mais duradouro e a atividade pode ser eventualmente interrompida por um evento.
A condio de guarda uma expresso de valor lgico usada em uma transio. Voc pode definir a condio utilizando-se parmetros, referncias e ligaes da classe. Observe na figura 8.7: s ser includo um aluno no curso se o contador for menor que 10.
Unidade 8
211
Quando voc define uma condio de guarda, ela s disparada se o evento associado ocorrer e se a condio for verdadeira. A condio de guarda sempre aparece no DTE com o uso de colchetes, como:
Realizar_saque (quantia) [quantia=saldo]/sacar (quantia)
No diagrama da figura 8.8, Lima (2005) apresenta um DTE para Pedidos. O pedido pode ser confirmado ou cancelado pelo cliente. O estado Pendente possui uma ao reflexiva Pedidos Pendentes. Ao finalizar o Pedido, o estado do Pedido estar alterado.
Figura 8.8 DTE Emitir Pedido Fonte: Lima (2005).
212
Lembre-se, utilize o diagrama de transio de estados para:
descrever o comportamento de um objeto ao longo de vrios casos de uso; modelar objeto dotado de comportamento muito dinmico.
Seo 2 Modelo de atividades

O diagrama de atividades o quarto diagrama responsvel pela descrio dos aspectos dinmicos de um caso de uso. O diagrama de atividade modela a lgica utilizada em um caso de uso. Neste caso, o diagrama de atividade permite apresentar interaes, decises e passos executados em paralelo impossveis de representar somente com o caso de uso. Pode ser utilizado para descrever um processo de negcio, a partir da necessidade de entender melhor um problema. O diagrama vai permitir que voc entenda melhor o comportamento do sistema, no decorrer dos diversos casos de uso. Esse modelo tambm utilizado para especificar a programao com multithreading. O diagrama de atividade lembra muito o antigo fluxograma, lembra-se dele? O diagrama de atividade deve ser usado em situaes em que todos ou a maioria dos eventos representam a concluso das aes geradas internamente ou seja, os fluxos processuais de controle e em situaes onde acontecem eventos assncronos. O diagrama permite escolher a ordem pela qual as coisas devem ser feitas, indicando as regras essenciais de sequncia que devem ser seguidas.
Unidade 8
213
O conceito de multithreading utiliza o conceito de thread que considerado um processo leve, em que o espao de endereamento compartilhado por vrios programas. No ambiente multithreading, no existe a ideia de programas associados a processos, mas a threads. O processo nesse ambiente tem um thread de execuo, mas compartilha o espao de endereamento com inmeros outros threads (MACHADO, 2002).
Para Furlan (1998), os diagramas de atividades podem modelar o sistema de duas maneiras:
Para modelar o fluxo de trabalho As atividades so focalizadas conforme visualizadas pelo ator. Por exemplo, no fluxo de trabalho de processamento de um pedido incluir classes como Pedido e Cobrana. As instncias dessas duas classes sero produzidas por determinadas atividades (processar pedido criar um objeto Pedido, por exemplo); outras atividades podero alterar esses objetos (por exemplo, Enviar pedido modificar o estado do objeto Pedido a ser preenchido). Para modelar uma operao Os diagramas so empregados como fluxogramas. O diagrama permite visualizar, especificar, construir e documentar o comportamento de qualquer elemento da modelagem. Os diagramas de atividades podem ser anexados a classes, interfaces, componentes, ns, casos de uso e colaborao.
Na figura 8.9, observe os possveis componentes de um diagrama de atividades.
214
Figura 8.9 Modelo de um diagrama de atividades Fonte: Elaborao da autora (2008).
O diagrama sempre tem um estado inicial e um estado final. A transio de trmino liga um estado a outro, ou seja, o trmino de um passo o incio de outro. Cada uma das aes disparada no momento em que ocorre o trmino do evento anterior. Os pontos de ramificaes so pontos em que, a partir de uma transio de entrada, voc pode ter vrias transies de sada. o caso das condies de guarda do diagrama. Os objetos apresentados no diagrama podem ser:

Atividade Representada pelo retngulo ovalado. Objeto Representado por um retngulo.
Unidade 8
215
Seta cheia Relao de precedncia entre atividades. Seta pontilhada Consumo ou produo de objeto por atividade. Linha horizontal cheia Ponto de sincronizao. Pequeno crculo cheio Estado inicial. Pequeno crculo eclipsado Estado final.
No diagrama, voc percebe que existem dois fluxos paralelos (atividade 3 e 4) e que no existe limitao para o nmero de processos paralelos, pois a sincronizao desses fluxos acontece pelo uso de uma barra paralela. A barra pode ser utilizada para bifurcao ou juno. Se for uma barra de juno (join) (no diagrama aparece como sincronizao), dois ou mais fluxos de transio sero unidos em um nico fluxo. Se for uma barra de bifurcao a partir de uma transio de entrada, so criados dois ou mais fluxos paralelos (no diagrama aparece a bifurcao na condio de guarda se). Na figura a seguir, voc v o diagrama de atividade para o caso de uso realizar saque do sistema de caixa eletrnico.
216
ad Activity Diagram
Incio
Verificar existncia da conta e validade da senha
Seleciona a opo Saque
Informa o valor do saque
Cliente digita a senha
Informa erro
Senha Vlida?
No
Saldo Suficiente Informa Saldo Insuficiente
Realiza contagem das cdulas
Disponibiliza cdulas
Atualiza Saldo
Final
Figura 8.10. Diagrama Realizar Saque do Sistema de Caixa Eletrnico Fonte: Elaborao da autora (2008).
Unidade 8
217
possvel observar pelo diagrama a sequncia de atividades que devem ser realizadas e a precedncia de cada atividade. Na figura a seguir, apresentado o diagrama de atividade para o caso de uso Gerar Contrato de Aluguel do sistema Imobilirio:
ad CSU05 Incio
Corretor Efetua Login
Selecionar Cliente
Selecionar Fiador
Avisa Cliente da Negativa
Dados Aprovados?
Sim
Secionar Imvel
Insere dados do aluguel
Contrato Imprime Contrato
Final
Figura 8.11 - Diagrama Gerar Contrato de Aluguel do Sistema Imobilirio Fonte: Elaborao da autora (2008).
218
Lembre-se, utilize o diagrama de atividade:

Para explicitar comportamentos paralelos; na modelagem de workflow; em caso de programao com multithreading; para melhor entendimento de workflow entre vrios casos de uso.
Workflow descreve tarefas dos processos de negcio (conjunto de uma ou mais atividades relacionadas que, coletivamente, atingem um objetivo) em um nvel conceitual necessrio para compreender, avaliar e reprojetar o processo de negcio (BORTOLI, 2004).
Seo 3 Consideraes sobre o uso da orientao a objetos

Durante este estudo no foram apresentados todos os diagramas e todas as vises possveis da UML. Na verdade, foram privilegiadas as vises consideradas fundamentais para qualquer desenvolvimento de software. A complementao pode ser feita por meio da leitura do livro UML: guia do usurio escrito por Booch, Rumbaugh e Jacobson, em 2000. Ao finalizar esta unidade, importante retomar um tema importante: quais so os benefcios do uso da orientao a objetos? Pode-se afirmar que o uso desse paradigma proporciona o melhor gerenciamento das funes do sistema, o aumento da produtividade pelo uso da reutilizao, a melhor qualidade dos servios oferecidos e a facilidade do mapeamento do mundo real versus o mundo computacional. Apesar de todas essas vantagens, o mercado ainda no absorveu completamente essa metodologia. Por qu? Furlan (1998) lista alguns motivos para tal quadro:

incerteza; falta de mo de obra qualificada;
Unidade 8
219
ferramentas imaturas; O investimento da empresa j realizada em ferramentas no orientadas a objetos.
A introduo da UML, suas facilidades e o grande nmero de ferramentas que suportam sua notao vm gradativamente revertendo esse quadro. O grande potencial de comunicao e reaproveitamento pela reutilizao de modelos em futuras aplicaes tem aproximado empresas de desenvolvimento do modelo orientado a objetos. Agora, para praticar os conhecimentos conquistados nesta unidade, realize a seguir as atividades propostas.
Sntese
Com esta unidade, voc complementou seu conhecimento sobre a representao dinmica do sistema por meio de seus diagramas de atividade e estado. Os fluxos de estado so excelentes na descrio de fluxos complexos, permitindo a visualizao da execuo do caso de uso. O diagrama de estado descreve muito bem o comportamento de um nico objeto, mas quando o comportamento envolve diversos objetos mais adequado o uso do diagrama de atividades. O diagrama de atividades suporta a descrio de comportamentos paralelos modelando o fluxo de trabalho, principalmente quando diferentes casos de uso interagem entre si ou utilizam multiprocessamento. Outra situao de uso comum para o diagrama de atividade seu uso para entender o comportamento, dependncias das aes e as prprias aes necessrias na realizao do caso de uso.
220
Leia com ateno os enunciados e realize as questes propostas. 1) Complete as afirmaes a seguir. a) Esta modificao chamada de _______________ entre estados. b) Os ______________ representa o resultado de atividades executadas por um objeto. c) O ______________ indica o final do ciclo de vida de um objeto. d) Os ______________ de um sistema modificam seu estado de forma anloga a objetos do mundo real. 2) Indique se os conceitos a seguir fazem parte do diagrama de estados (DTE) ou do diagrama de atividade (DA). a) ( ) O diagrama mostra os estados de um objeto. b) ( ) O diagrama explicita comportamentos paralelos. c) ( ) O diagrama mostra os eventos ou as mensagens que causam uma transio. d) ( ) O diagrama apoia o entendimento de workflow entre vrios casos de uso. 3) Relacione os conceitos a seguir. Observe que uma mesma opo pode se repetir. A) After B) Estado inicial C) When D) Transient E) Join a) ( ) utilizado em um DA para indicar uma bifurcao. b) ( ) Ocorre quando o objeto criado. c) ( ) Utilizado para designar a paassagem de um perodo predeterminado de tempo. d) ( ) utilizado para representar uma condio de guarda. e) ( ) utilizado em um DA para indicar uma sincronizao.
Unidade 8
221
4) Construa o diagrama de atividades do caso de uso Agendar Horrio da Clnica Bem-Estar a partir da viso do ator Atendente.

222
Unidade 8
223
Saiba mais
Para aprofundar as questes abordadas nesta unidade, voc poder pesquisar em: BEZERRA, E. Princpios de anlise e projeto de sistemas com UML. So Paulo: Campus, 2002. (Ler captulos 10 e 11.) BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usurio. So Paulo: Campus, 2000. (Ler captulos 18 e 19.) BORTOLI, A. O uso do workflow para apoiar a elicitao de requisitos. Workshop em engenharia de requisitos. 2004 FURLAN, Jos. Modelagem de objetos. So Paulo: Makron Books, 1998. (Ler captulo 6.)
224
UNIDADE 9
RUP e ICONIX

Entender o que o RUP, seus elementos e conceitos. Discutir e analisar nuanas do processo de desenvolvimento orientado a objetos utilizando-se o RUP. Entender como o RUP colabora para a estruturao efetiva de tarefas e fluxos de trabalho de profissionais, atuando em equipes de desenvolvimento de software. Compreender o processo ICONIX e seus componentes.
Sees de estudo
Seo 1 Seo 2 Seo 3 Seo 4 Aonde se quer chegar? Quais so as fases do RUP? Quais so os elementos do RUP? ICONIX

Quando voc l um artigo sobre empresas de desenvolvimento de software, raro encontrar discusses sobre a dificuldade da empresa em dominar uma tecnologia como um banco de dados, uma linguagem de programao ou mesmo um sistema operacional. Por outro lado, voc vai encontrar dezenas de matrias relatando os problemas relacionados a cronogramas, entregas, produtividade da equipe, qualidade do produto, uso de metodologias e padronizao das diferentes etapas. Ensinar UML a uma equipe de projeto pode no ser uma tarefa to rdua, como propor a essa equipe todo um processo de desenvolvimento voltado para uma metodologia, utilizando essa notao. O Rational Unified Process (RUP) um processo de engenharia de software que pretende aumentar a produtividade da equipe, oferecendo prticas eficientes executadas por meio de diretrizes, templates e orientaes sobre ferramentas para todas as atividades crticas de desenvolvimento de softwares. O ICONIX, no entanto, um mtodo menos complexo, com um volume menor de documentao que o RUP, mas que apresenta grande aceitao no mercado.
Seo 1 Aonde se quer chegar?

Quando olhamos ao redor, percebemos nossa total dependncia dos sistemas de informao. Mas o que feito em nossa vida moderna que no envolva recursos computacionais? Poucas so as atividades que nos restam em que no temos como apoio um software. Alm da dependncia, temos os riscos
226
envolvidos nesse problema complexo. Antigamente se imaginava arriscado um software existente em uma aeronave que, ao falhar, poderia fazer com que ela casse. Ou um sistema de controle de uma usina nuclear. Hoje os riscos extrapolam questes vitais. Imagine os riscos financeiros provenientes de milhares de transaes bancrias, os riscos em uma fraude eleitoral ou mesmo os riscos existentes em um software de defesa de um pas, como a Inglaterra.
O desenvolvimento de software uma atividade de alto risco. Entre lucros gerados nessa atividade, muitos foram os prejuzos, na maioria das vezes causados pelo mau planejamento, pela m gerncia e pela baixa qualidade do produto final.
Mas como gerenciar o processo de desenvolvimento de software aumentando sua qualidade se a empresa de desenvolvimento de software no conhece seu prprio processo de desenvolvimento? Segundo Booch (2000), um processo um conjunto de passos parcialmente ordenados com a inteno de atingir metas. A meta neste caso a entrega eficiente e previsvel de um produto de software que atenda, de forma completa, todas as necessidades do usurio. Mas como inserir qualidade no processo? A qualidade passa pelo uso de metodologias e reconhecimento formal do processo. Apenas modelar o sistema no o suficiente. O uso de uma notao voltada orientao a objetos como a Unified Modeling Language (UML) pode colocar sua empresa na vanguarda em termos de notao, porm pouco garante quanto qualidade de todo o processo. A UML uma linguagem de especificao. O seu uso garante a confeco de diagramas precisos. Mas, se esses diagramas no forem usados de forma sistemtica, documentados e servirem como pontos de controle e avaliao do processo, de pouco serviro para a adequao de qualidade do produto.
O processo define: quem est fazendo o qu, quando e como est sendo feito e as aes para atingir uma determinada meta.
Unidade 9
227
Em resumo, somente descrever os diagramas no o suficiente para garantir um processo de desenvolvimento com qualidade. necessrio o uso de uma metodologia que unifique o esforo da equipe dentro de um processo formal e mensurvel.
Team-Based Development
Modeling Language
Unified Process
Figura 9.1 Mtodos Fonte: IBM (2005).
Como est estruturado o Rational Unified Process (RUP)?
O RUP usa a abordagem da orientao a objetos em sua concepo. Sua projeo e documentao utilizam a notao UML para especificar, modelar e documentar artefatos com os quais se procura ilustrar os processos em ao.
O RUP foi desenvolvido pela Rational Software Corporation, sendo ento um mtodo proprietrio de desenvolvimento de software.
Segundo IBM (2005), o RUP se apresenta como um processo de engenharia de software que oferece uma abordagem baseada em disciplinas para atribuir tarefas e responsabilidades dentro de uma organizao de desenvolvimento, permitindo o gerenciamento eficiente do processo.
228
Sua meta garantir a produo de software de alta qualidade que atenda s necessidades dos usurios dentro de um cronograma e oramento previsveis (IBM, 2005). Kroll e Kruchten (2003) apresentam trs definies para o RUP:
uma maneira de desenvolvimento de software que iterativa, centrada arquitetura e guiada por casos de uso. um processo de engenharia de software bem definido e bem estruturado. O RUP define claramente quem responsvel pelo que, como as coisas devem ser feitas e quando faz-las. Alm disso, tambm prov uma estrutura bem definida para o ciclo de vida de um projeto RUP, articulando claramente os marcos essenciais e pontos de deciso. tambm um produto de processo que oferece uma estrutura de processo customizvel para a engenharia de software. O produto IBM RUP suporta a customizao e autoria de processos e uma vasta variedade de processos ou configurao de processos. Essas configuraes do RUP podem ser criadas para suportar equipes grandes e pequenas e tcnicas de desenvolvimento disciplinadas ou menos formais.
Quais so as diretrizes do RUP?
Unified Process
O RUP apresenta caractersticas prprias no processo de desenvolvimento (IBM, 2005):
O uso de um processo iterativo O problema e a soluo so organizados em pequenas partes e para cada pequena parte do sistema feita uma iterao. A iterao segue o modelo sequencial tradicional, com identificao de necessidades, anlise, projeto, implementao e desenvolvimento.
Unidade 9
229
O processo incremental Cada interao acrescenta incrementalmente novas caractersticas ao produto. Assim, a cada ciclo a soluo delineada aperfeioada. Dirigido por casos de uso O processo guiado pelas interaes entre o sistema e os usurios. Todos os casos de uso de um sistema compem a especificao funcional do sistema (modelo de casos de uso), ou seja, definem os requisitos e objetivos do sistema do cliente. Assim os casos de uso associam todos os workflows de forma conjunta, dirigindo vrias atividades de desenvolvimento como a criao e validao da arquitetura do sistema, a criao de casos de teste, o planejamento das iteraes, a criao de documentao do usurio e a implantao do sistema. Os casos de uso sincronizam contedo dos modelos criados em cada workflow. Centrado na arquitetura Neste caso, o processo focaliza o desenvolvimento inicial e a linha de base da arquitetura de software utilizando-se de relacionamentos claros entre componentes da arquitetura. Voc pode ver o sistema como a soma de diversas partes menores (componentes). Cada componente possui a funcionalidade necessria. Sob o ponto de vista da aderncia ao negcio ou em termos de implementao, esses componentes se comunicam por meio de interfaces. O uso de componentes torna a manuteno e a reutilizao muito mais eficientes.
Voc pode encontrar esse padro no site do Rational Software Corporation. Para que voc o utilize da forma mais adequada, ele dever ser configurado de acordo com as necessidades da empresa ou mesmo do projeto.
O RUP foi desenvolvido para ser aplicvel a qualquer tipo de projeto. Na literatura, assumido como um framework genrico para processos de desenvolvimento.
230
Seo 2 Quais so as fases do RUP?

As fases de um projeto podem ser definidas como o perodo de tempo necessrio entre dois marcos de progresso de um processo, em que um objetivo alcanado, artefatos so concludos e decises sobre a etapa seguinte so tomadas. Segundo o site da IBM Rational Software, o RUP composto por quatro fases: a) Concepo ou inicial Estabelece o caso de negcio para o projeto. estabelecido o escopo e a viabilidade econmica do projeto. b) Elaborao Nesta fase so estabelecidos o plano de projeto e uma arquitetura slida. Os principais riscos so eliminados. Ao final da etapa, estabelecida a arquitetura, a partir da qual o sistema vai evoluir. c) Construo Nesta etapa o sistema desenvolvido. O produto completo desenvolvido iterativamente.
Para saber Workflow a automao de processos de negcio, em que as atividades so passadas de um participante para o outro, de acordo com um conjunto de regras definidas. Framework No desenvolvimento do software, um framework uma estrutura de suporte definida em que um outro projeto do software pode ser organizado e desenvolvido. Tipicamente, um framework pode incluir programas de apoio, bibliotecas de cdigo, linguagens de script e outros softwares para ajudar a desenvolver e juntar diferentes componentes do seu projeto.
Unidade 9
231
d) Transio Fornece o sistema aos seus usurios finais, normalmente por uma verso beta do sistema. Se necessrio, no final da fase pode ser iniciado um novo ciclo de desenvolvimento para a evoluo do produto.
Figura 9.2 Fases do RUP Fonte: Adaptado de IBM (2005).
A cada fase ocorre um ciclo completo de desenvolvimento, da anlise ao produto executvel. Cada fase finalizada com um marco de progresso (milestone), no qual so verificados se os objetivos da fase foram alcanados. A cada iterao (elaborao, construo, transio) so realizadas atividades listadas esquerda do grfico. As curvas apresentadas no grfico indicam o esforo dedicado s atividades a cada fase do projeto.
As interaes so ciclos completos de desenvolvimento. Cada interao passa por vrios fluxos de trabalho do processo com nfases diferentes.
Como foi comentado na primeira seo, o RUP direcionado pelos casos de uso. Mas como isso acontece?
232
A cada iterao so identificados e especificados os casos de uso mais relevantes. So feitos ento a anlise e o projeto dos casos de uso, sempre usando a arquitetura como guia. A partir desse ponto so implementados os componentes que realizam o que foi projetado e, finalmente, verifica-se se os componentes que satisfazem o que foi previsto como objetivos de cada caso de uso. Os casos de uso so usados durante todo o processo:

O caso de uso utilizado para especificar os requisitos. Na etapa de anlise, projeto e implementao, os casos de uso so executados. Na etapa de testes, voc vai verificar se o sistema realiza o que est descrito no modelo de casos de uso. E, finalmente, os casos de uso so a ferramenta fundamental no planejamento e acompanhamento de todas as iteraes.
Seo 3 Quais so os elementos do RUP?

Segundo Booch (2000), quando voc utiliza a metodologia RUP, percebe-se imediatamente a existncia de cinco elementos principais: os papis, os artefatos, as atividades, a disciplina e os fluxos de atividade (subdividido em fluxos principais e fluxos de apoio). a) Papis Um papel (ou perfil) define o comportamento e as responsabilidades de um determinado indivduo ou grupo de indivduos que trabalham dentro de uma equipe. importante que voc perceba que os papis no so indivduos, mas sim o papel que ele assume no processo. Veja alguns papis:
Unidade 9
233
O analista de sistema em que o indivduo que assume esse papel coordena a obteno dos requisitos, a modelagem dos casos de uso e a definio do escopo do projeto. O projetista de testes, responsvel por toda a estruturao da etapa de testes, do planejamento avaliao dos resultados dos testes.
Assim, em um projeto voc pode ter vrios indivduos executando um mesmo papel. b) Atividade Uma atividade uma unidade de trabalho que um indivduo executa quando est exercendo um determinado papel, produzindo um resultado para o contexto do projeto. A atividade composta de objetivos, passos, entradas e sadas, o responsvel pela atividade e os guias e padres que devem ser seguidos pela atividade.
Exemplo: uma atividade pode ser a definio dos atores, a definio dos casos de uso ou mesmo conduzir uma etapa de testes.
c) Artefato O artefato o produto de um projeto. o resultado de uma etapa. Apesar de aparecerem como resultado do desenvolvimento do projeto, podem ser utilizados como entrada de uma atividade e ainda assim no final da atividade vai gerar outro artefato como sada. Normalmente o artefato baseado em modelos de como devem ser feitos ou mesmo por documentos que possuem j um formato padronizado.
Exemplo: um artefato pode ser um modelo de caso de uso, um caso de uso, um cdigo-fonte etc.
d) Disciplinas Uma disciplina mostra todas as atividades que voc deve realizar para produzir um determinado conjunto de artefatos. As disciplinas so descritas em nvel geral, com um resumo de todos os papis, atividades e artefatos envolvidos.
234
Em alguns pontos do projeto, voc precisa de um detalhamento maior. Neste caso, ocorre o detalhamento da disciplina por meio do fluxo de trabalho.
Um fluxo de trabalho uma sequncia de atividades que so executadas para a produo de um resultado para o projeto. Fluxos de trabalho podem ser representados por diagramas de sequncia, diagramas de colaborao e diagramas de atividades da linguagem UML.
e) Fluxos de trabalhos O RUP desenvolvido baseando-se em nove fluxos de trabalho de processo, que podem ser divididos em fluxos principais e fluxos de apoio, definidos em Booch (2000). Acompanhe, a seguir.
Fluxos principais
Modelagem do Negcio (Business Modeling) Envolve o entendimento da estrutura e dinmica da organizao cliente, garantindo que clientes, usurios e desenvolvedores tenham a mesma viso da organizao para a qual ser feito o desenvolvimento. Requisitos (Requirements) Esta disciplina visa estabelecer e manter concordncia com os clientes e outros envolvidos, sobre o que o sistema deve fazer, utilizando-se para isso dos casos de uso. Tambm definida a delimitao do sistema, so definidas as bases para planejamento do contedo tcnico das interaes, estimativas de custo, o tempo de desenvolvimento do sistema e a definio da interface do usurio com o sistema, focando nas necessidades e metas dos usurios. Anlise e Projeto ( Analysis and Design) Envolve a traduo dos requisitos numa especificao que descreve como implementar o sistema, adaptando o design para que corresponda ao ambiente de implementao, projetando-o para fins de desempenho. nesse momento que so descritas as diferentes vises do sistema.
Unidade 9
235
Implementao (Implementation) Envolve o desenvolvimento de cdigo: classes, objetos etc., teste de unidades e integrao de subsistemas. Teste (Test) Descreve todos os casos de teste, procedimentos e medidas para o acompanhamento dos erros ocorridos. Entrega (Deployment) Abrange a configurao do sistema a ser entregue (empacotamento, distribuio, instalao, treinamento de usurios, planejamento e conduo de beta teste). So descritos trs modos de implantao de produto: a instalao personalizada, o produto em uma forma compacta e o acesso ao software por meio da internet.
Fluxos de atividades de apoio
Gerncia de Projeto (Project Management) Enfatiza principalmente o gerenciamento de risco, o planejamento de um projeto iterativo por meio do ciclo de vida e de uma iterao particular. O monitoramento do progresso de um projeto iterativo e o uso de mtricas. Aspectos relacionados gerncia de pessoal, aos contratos e ao oramento no so observados. Gerncia de Configurao e Mudanas (Configuration and Change Management) O fluxo controla as modificaes mantendo a integridade dos artefatos do projeto. Envolve a identificao dos itens de configurao, a restrio de mudanas, a auditoria das mudanas feitas e a definio e o gerenciamento das configuraes desses itens. Ambiente (Environment) Envolve a infraestrutura necessria para que o desenvolvimento ocorra. A meta oferecer organizao o ambiente de desenvolvimento de software, processos e ferramentas que daro suporte equipe de desenvolvimento.
Quais so os modelos do RUP?
236
Quais os prs e contras do Rational Unified Process?
A discusso sobre vantagens e desvantagens do RUP bastante acirrada. Uma grande vantagem a ser considerada o uso de princpios de engenharia de software na sua abordagem de desenvolvimento iterativa, incremental, orientada a requisitos e baseada em arquitetura. O sistema desenvolvido com o RUP tende a tolerar melhor mudanas de requisitos e alteraes no produto. Os componentes desenvolvidos ao longo de um projeto podem ser reutilizados em outros projetos, diminuindo o tempo de desenvolvimento e, consequentemente, os custos para o cliente. Um dos aspectos mais importantes a capacidade de gerncia por meio de fases e millestones incorporados ao projeto. Ao lado de suas vantagens, tambm temos limitaes do mtodo, entre elas o fato de o RUP no abordar a gesto de pessoal e contratos, como a ferramenta ser um sistema de hipertexto dificultando as integraes com outras ferramentas. Talvez um dos fatores mais crticos do mtodo seja o fato de o mtodo ser previsto para qualquer porte de empresa. A implantao em empresas de pequeno porte tem se mostrado, no entanto, difcil pelo volume de responsabilidades e a quantidade de atividades de cada fluxo de atividade.
Quer conhecer mais? Para aprofundar seus conhecimentos sobre esta unidade, acesse a Midiateca no EVA. Leia o texto Um mtodo de desenvolvimento de sistemas de grande porte baseado no processo RUP. Com ele, voc vai poder avaliar melhor o processo RUP.
Unidade 9
237
Seo 4 ICONIX
O ICONIX uma metodologia de desenvolvimento de software com caractersticas interativas e incrementais. Classificar o ICONIX difcil, pois por um lado possui uma veia tradicional com um processo bem definido, por outro lado aproxima-se dos mtodos geis procurando a reduo da documentao e a simplicidade no processo. Mastelari (2004) define ICONIX Software Engineering como um processo enxuto e robusto voltado para o trabalho com equipes pequenas e desenvolvimentos de tamanho pequeno e mdio. O processo ICONIX teve seu incio muitos anos antes da concepo da UML e do processo unificado. Foi elaborado por Doug Rosenberg e Kendall Scott Poe, voltando-se a uma abordagem de orientao a objetos. Silva e Videira (2001) apresentam o ICONIX como uma metodologia prtica, intermediria entre a complexidade do RUP e a simplicidade do XP (Extreme Programming). A UML usada integralmente no mtodo suportando e respondendo a questes impostas pela metodologia por meio de seus diagramas. So, segundo Borillo (2000), trs as caractersticas fundamentais no ICONIX:
O modelo iterativo e incremental e, portanto, vrias iteraes acontecem da definio do modelo de domnio identificao dos casos de uso. Rastreabilidade Todos os passos do processo referenciam os requisitos. O modelo permite ento verificar em todas as fases se os requisitos foram atendidos. Desta forma, pode-se determinar qual o impacto que a alterao de um requisito tem em todos os artefatos do sistema.
238
Aerodinmica da UML A metodologia incorpora o uso da UML por meio de diagramas. Os mais usados so: os diagramas de casos de uso, diagramas de sequncia e colaborao, diagramas de robustez e diagramas de classes.
Figura 9.3 Processo Iconix Fonte: Rosenberg et al. (2005).
O ICONIX fundamenta-se em dois modelos: o esttico e o dinmico. O modelo esttico modela o funcionamento do sistema sem se preocupar com interaes e aspectos dinmicos do sistema. So dois os diagramas usados nessa representao: o diagrama de domnio e o diagrama de classe. O modelo dinmico apresenta as interaes do sistema mostrando a interao do usurio com o sistema. O modelo dinmico representado por diagramas de sequncia, de casos de uso e o diagrama de robustez. O ICONIX determina um ciclo com quatro etapas bem determinadas, a anlise de requisitos, a anlise e o projeto preliminar, o projeto e a implementao.
Unidade 9
239
Anlise de requisitos
Na anlise de requisitos, ocorre a identificao das necessidades do cliente por meio dos requisitos funcionais. Nessa fase o contato com o cliente estreito. Segundo Silva e Videira (2001), a tarefa de anlise de requisitos consiste em realizar as seguintes tarefas:
Identificar os objetos do domnio do problema. Nessa identificao utiliza-se o diagrama de classes. Desenvolver prottipos da interface, do dilogo e da navegao proporcionando para o cliente o melhor entendimento sobre a proposta. Identificar os casos de uso e os atores associados a esses casos de uso. Essa tarefa ser realizada por meio dos diagramas de casos de uso. Finalizada a identificao dos casos de uso, eles devem ser organizados por meio de grupos que permitam sua melhor compreenso e visualizao. Essa estruturao ocorre por meio do diagrama de pacotes. Os requisitos funcionais devem ser claramente associados aos casos de uso e aos objetos do domnio, de forma a tornar visvel qual caso e classe solucionar o requisito funcional.
Anlise e projeto preliminar

Durante a etapa de anlise e projeto, so descritos os casos de uso identificando-se seus cenrios. Nessa etapa do processo, so construdos os diagramas de robustez e so refinados e finalizados os diagramas de classe.
Projeto
A etapa de projeto permite equipe a especificao do comportamento esperado nos casos de uso, a identificao dos objetos e atores e as mensagens trocadas entre os elementos. Para essa tarefa, o diagrama de sequncia torna-se essencial.
240
Nesse momento j possvel inserir no diagrama de classes seus atributos e mtodos. So assim concludos os diagramas do modelo esttico validando se todos os requisitos prescritos foram atendidos.
Implementao
Para a etapa de implementao, a equipe apresenta seu maior esforo na gerao do cdigo, na realizao de testes de unidade, integrao e aceitao do cliente. Agora, para praticar os conhecimentos conquistados nesta unidade, realize a seguir as atividades propostas.
Sntese
Nesta unidade, voc teve contato com o RUP e o ICONIX, seus conceitos e principais modelos. Foi possvel perceber a importncia do processo incremental iterativo oferecido pelo modelo e a preocupao de tornar a gerncia e a manuteno do produto mais eficiente em todas as etapas do desenvolvimento. Voc percebeu que dentro do mtodo fundamental a definio clara dos papis e das responsabilidades. Um dos pontos fortes do modelo a padronizao e a definio de artefatos para cada etapa do projeto. A utilizao de uma arquitetura baseada nos casos de uso aproxima o usurio final do desenvolvimento, melhorando a qualidade do processo, refinando em etapas bastante iniciais o processo de validao do sistema. Apesar das controvrsias relacionadas ao seu uso, o RUP temse mostrado uma metodologia eficiente no mercado, sendo que sua utilizao vem crescendo gradativamente. Um dos fatores mais fortes para isso a possibilidade de adaptao do modelo s necessidades e exigncias da empresa.
Unidade 9
241
Um ponto forte do ICONIX a identificao e representao do modelo de domnio e dos casos de uso. A partir desse ponto o processo de desenvolvimento passa a ser iterativo e incremental. Os casos de uso so documentados e a ele anexado o respectivo diagrama de robustez. Na sequncia identificam-se novos objetos e detalhes que so incorporados ao diagrama de domnio. Na etapa seguinte, os diagramas de sequncia so feitos procurando a identificao de objetos. Na ltima etapa, operaes so adicionadas assim como os atributos ao diagrama de classe. O ICONIX uma sugesto de processo de desenvolvimento de software e tem tido uma grande aceitao no mercado. Parte desse sucesso se deve forma sucinta com que trata a documentao. Outro aspecto relevante a importncia do modelo na etapa de entendimento dos requisitos do cliente. Essa preocupao tem transformado o modelo em um modelo de sucesso.
Leia com ateno os enunciados e realize as questes. 1) Assinale as afirmativas corretas (mais de uma, caso necessrio): a) ( ) O RUP utiliza-se do modelo iterativo para o desenvolvimento do software. Isso significa a definio clara de etapas em um ciclo rgido e formal. b) ( ) O RUP visto como um produto de processo de engenharia customizvel. c) ( ) O RUP centrado na construo do produto. Baseia-se fundamentalmente no uso de uma linguagem orientada a objetos. d) ( ) O RUP centrado na arquitetura, estabelecendo de forma clara e segura todos os relacionamentos existentes entre seus componentes.
242
2) Entre os elementos do RUP temos os papis. Qual a sua importncia dentro do modelo? Faa uma pesquisa e descreva dois papis existentes no modelo.
3) Relacione os fluxos de atividades do RUP. A. Modelo de negcios a) ( ) Procura manter a integridade dos artefatos do projeto. B. Requisitos b) ( ) Procura manter uma viso uniforme C. Anlise e projeto sobre o projeto para todos os envolvidos. D. Gerncia de projeto E. Gerncia de configurao e mudanas c) ( ) Descreve as diferentes vises do sistema. d) ( ) Enfatiza o gerenciamento de riscos. e) ( ) Neste fluxo definida a delimitao do sistema.
Unidade 9
243
4) Dos nove modelos oferecidos pelo RUP, defina trs que voc considera fundamentais para que o projeto seja bem aceito pelo cliente final.
244
Saiba mais
Para aprofundar as questes abordadas nesta unidade, acesse a Midiateca.
Uma outra metodologia bastante aplicada em empresas de software atualmente o ICONIX ((link ICONIX_guj.pdf). No artigo escrito por Jos Anzio Maia, voc vai perceber que uma metodologia simples e menos burocrtica do que o RUP. Vale a pena conferir!
Unidade 9
245
Para concluir o estudo

Com este livro, voc aprendeu os conceitos e particularidades da anlise estruturada e da anlise essencial. Conheceu as anlises, caractersticas e particularidades de implementao que tornam o projeto mais claro, facilitando sua compreenso, inclusive para o usurio final. O uso das metodologias torna o trabalho do gerente mais objetivo e sua cobrana perante a equipe mais eficiente. Isso se deve pela possibilidade de gerao de diferentes tipos de artefatos que podem ser utilizados como marcos de projeto para acompanhamento da equipe. A anlise estruturada foi pioneira em termos de aceitao como metodologia de documentao de projetos. Seu uso ainda hoje expressivo pela facilidade de utilizao de sua notao e benefcios advindos de seu uso. O segundo livro da disciplina dar nfase metodologia orientada a objetos fazendo uso da linguagem de notao Linguagem de Modelagem Unificada (LMU). Alm de explorar seus diagramas mais utilizados, tambm ser feita uma breve abordagem sobre o Rational Unified Process (RUP). Durante todo o seu estudo nesta disciplina, voc foi apresentado a trs paradigmas diferentes: a anlise estruturada, a anlise essencial e a anlise orientada a objetos. Voc conheceu caractersticas e particularidades de implementao de cada um. Foi possvel perceber que a orientao a objetos encaixa-se muito bem no paradigma atual de implantao, mas que todos esses tipos de anlise, sem exceo, colaboram para que o projeto fique claro para toda a equipe de projeto.
Esperamos que o estudo da disciplina tenha lhe proporcionado a oportunidade de reconhecer a metodologia mais adequada para seus projetos, assim como o entendimento sobre seus conceitos e diagramas. Professora Vera Schuhmacher
248
Referncias
AMBLER, S. W. Anlise e projeto orientados a objetos. Rio de Janeiro: Infobook, 1998. ARAGO, S. Modelagem visual de objetos UML . So Paulo: [s.e.], 2005. BECK, K. Programao extrema explicada. Porto Alegre: Bookman, 1999. BEZERRA, E. Princpios de anlise e projeto de sistemas com UML. So Paulo: Campus, 2002. BONA, Cristina. Avaliao de processos de software: um estudo de caso em XP e Iconix. 2002. Dissertao (Mestrado em Engenharia de Produo) - Universidade Federal de Santa Catarina. Florianpolis, 2002. BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia do usurio. So Paulo: Campus, 2000. BORTOLI, A. O uso do workflow para apoiar a elicitao de requisitos. Workshop em Engenharia de Requisitos. 2004. CHEN, Peter. Gerenciando banco de dados: a abordagem entidade-relacionamento para projeto lgico. So Paulo: McGraw-Hill, 1990. COAD, Peter; YOURDON, Edward. Anlise baseada em objetos. Rio de Janeiro: Campus, 1992. COMUNIDADE IBM RUP (2005). Disponvel em: <http://www-130. ibm.com/developerworks /rational/community>. Acesso: 10 ago. 2005. COUTO, A. B. CMMI: integrao dos modelos de capacitao e maturidade de sistemas. Rio de Janeiro: Cincia Moderna, 2007. DEMARCO, Tom. Anlise estruturada e especificao de sistema. Rio de Janeiro: Campus, 1989. ENGHOLM JUNIOR, Helio. Engenharia de software na prtica. So Paulo: Novatec, 2010. ESMIN, A. A. A. Modelando com UML - Unified Modeling Language. II SECICOM - Universidade Federal de Lavras UFLA. Lavras, nov., 1999.
FIGUEIRA, J. M.; COSTA, W. S. A importncia de utilizar UML para modelar sistemas: estudo de caso. Disponvel em: <http://www.cefetsp. br/edu/sinergia/6p10c.html>. Acesso em: 10 ago. 2005. FOWLER, M. UML Distilled Second Edition: a brief guide to the standard object modeling language. Nova Jersey: Prentice-Hall International, 1997. FURLAN, J. D. Modelagem de objetos atravs da UML . So Paulo: Makron Books, 1998. GANE, C. Anlise estruturada de sistemas. Rio de Janeiro: LTC, 1983. GILLEANES, T. A. G. UML: uma abordagem prtica. So Paulo: Novatec, 2004. ______. UML: uma abordagem prtica. So Paulo: Novatec, 2006. GUEDES, Gilleanes T. A. UML 2: uma abordagem prtica. So Paulo: Novatec, 2009. IBM RATIONAL UNIFIED PROCESS. Verso 2003.06.12.01 (2005). Disponvel em: <http://www-306.ibm.com/software/awdtools/rup/>. Acesso em: 13 set. 2005. IBM RUP (2004) Disponvel em: <http://www-130.ibm.com/ developerworks/rational/products/rup>. Acesso em: 12 set. 2005. IEEE COMPUTER SOCIETY. IEEE Recommended Practice for Software Requirements Specifications. Nova Iorque, EUA: The Institute of Electrical and Electronics Engineers, 1993. KROLL, P.; KRUCHTEN P. The Rational Unified Process Made Easy: a Practitioners Guide to the RUP, Addison Wesley, 2003. LARMAN, Craig. Applying UML and Patterns: an introduction to objectoriented analysis and design and the unified process. Prentice Hall, 2001. LIESENBERG, H. Diagramas de colaborao. Disponvel em: <http://www. unicamp.br/~hans/mc426/#program>. Acesso em: 10 ago. 2005. LIMA, A. S. UML 2.0: do requisito soluo. So Paulo: Erica, 2005. MACHADO, F. M.; MAIA, L. P. Arquitetura de sistemas operacionais. 3. ed. Rio de Janeiro: LTC, 2002. MASTALARI, N. Contribuio ao processo de integrao de informaes da manufatura para empresas de pequeno e mdio porte. 2004. Tese (Doutorado em Engenharia Mecnica) - Faculdade de Engenharia Mecnica - Universidade Estadual de Campinas. Campinas, SP, 2004. MAZOLLA, V. Engenharia de software. Disponvel em: <http://pt.scribd. com/doc/48071734/Vitorio-Bruno-Mazzola-Engenharia-de-Software>. Acesso em: 24 abr. 2011. NIEDERAUER, Mastelari. Contribuio ao processo de integrao de informaes da manufatura para empresas de pequeno e
250
mdio porte. 2004. Dissertao (Mestrado em Engenharia Mecnica) Universidade Estadual de Campinas / Faculdade Engenharia Mecnica, Campinas, SP, 2004. PACHECO, R.; MONTENEGRO, F. Orientao a objetos em C++. So Paulo: Cincia Moderna, 1994. PAGES-JONES, M. Fundamentos do desenho orientado a objetos. So Paulo: Makron Books, 2001. PAULA FILHO, Wilson de Pdua. Engenharia de software: fundamentos, mtodos e padres. Rio de Janeiro: LTC, 2001. PETERS, J. F.; PEDRYCZ, W. Engenharia de software: teoria e prtica. Rio de Janeiro: Campus, 2001. PRESSMAN, Roger. Engenharia de software. So Paulo: McGraw-Hill, 2002. ROSENBERG, D.; STEPHENS, M.; COLLINS-COPE, M. Agile development with ICONIX process: people, process, and pragmatism. [S.L.]: Apress L. P., 2005. RUMBAUGH, J. Modelagem e projetos baseados em objetos. Rio de Janeiro: Campus, 1994. SCHWABER, K.; BEEDLE, M. Agile Software Development with SCRUM. Prentice-Hall, 2002. SILVA, A. M. R.; VIDEIRA C. A. E. UML: metodologias e ferramentas case. Lisboa: Centro Atlntico, 2001. SOARES, M. S. Metodologias geis extreme programming e scrum para o desenvolvimento de software. RESI - Revista Eletrnica de Sistemas de Informao. 4 ed. Ano III, vol. III, n. I. nov. 2004. SOMMERVILLE, Ian. Engenharia de software. 6. ed. So Paulo: AddisonWesley, 2003. SOUZA, Francisco Flavio de; BRAGA, Rosana Teresinha Vaccare. Um mtodo de desenvolvimento de sistemas de grande porte baseado no processo RUP. In: 1 Simpsio Brasileiro de Sistemas de Informao. Anais do 1 SBSI. Porto Alegre, 2004. p. 31-38. SUTHERLAND, Jeff. Agile development: lessons learned from the first scrum. Cutter Agile Project Management Advisory Service: Executive Update, 2004. TONSIG, Srgio Luiz. Engenharia de software: anlise e projeto de sistemas. So Paulo: Futura, 2003. YOURDON, Edward. Anlise estruturada moderna. Rio de Janeiro: Campus, 1992. WUESTEFELD, Klaus. Xisp: Extreme Programming. 2001. Disponvel em: <http://www.xispe.com.br/index.html>. Acesso em: 18 mar. 2002.
251
Sobre a professora conteudista

Vera Rejane Niedersberg Schuhmacher mestre em Engenharia de Produo com nfase em Usabilidade de Software pela Universidade Federal de Santa Catarina (UFSC). Professora da Unisul desde 1998, em disciplinas oferecidas nos cursos de Cincia da Computao e Sistemas de Informao e Ps-graduao. Pesquisadora do Ncleo de Computao, atua como coordenadora do Ncleo de Pesquisas em Usabilidade (NPU) prestando consultoria em Engenharia de Software e Usabilidade em empresas de tecnologias e projetos financiados por rgos de fomento como Finep, CNPq e Funcitec.
Respostas e comentrios das atividades de autoavaliao

A seguir so apresentadas respostas curtas e comentrios sobre as atividades de autoavaliao propostas durante as unidades. Para melhor aproveitamento de seus estudos, realize a sua conferncia somente depois de fazer as atividades.
Unidade 1
1) a) V b) V c) V d) F e) V 2) Sequncia correta: G, D, C, B, E, F, A, D. 3) A afirmativa correta (b). 4) a) E b) P c) I d) C 5) A alternativa correta : (a). 6) A alternativa correta : (c). O nmero de funcionalidades bastante pequeno, por outro lado as regras de negcio sugerem uma certa confuso para o bom entendimento do analista, o que torna apropriado o uso do modelo prototipao para a identificao de requisitos. 7) Observe o modelo XP e o modelo SCRUM, e a seguir descreva o que possvel determinar como diferenas fundamentais em relao aos modelos tradicionais.
So citadas abaixo caractersticas existentes em ambos os modelos: Tanto o Scrum como o XP apontam como de grande importncia a comunicao entre a equipe e seus colaboradores; isso se evidencia por meio de reunies formais e informais. Outro aspecto bastante diferenciado est relacionado ao volume de documentao dos projetos; em ambos os modelos procura-se racionalizar evitando o excesso. Um terceiro aspecto a participao do usurio de forma efetiva no processo de desenvolvimento. Os modelos so apontados como ideais para equipes pequenas e com interaes rpidas.
Unidade 2
1) A alternativa correta : (b). 2) A sequncia correta : d, a, c, b. 3) Relatrio de anlise do problema. Observe que foram acrescentadas informaes com o intuito de mostrar os itens de forma mais completa. 1 Nome da Empresa: Clnica Bem-Estar 2 Contato: Sr. Julibio Ritz (gerente) Fone : 3339090 Cel.: 9987878 3 Descrio do problema. A clnica possui 34 mdicos cadastrados em diferentes especialidades e presta atendimento a pacientes conveniados aos planos Bruxtr, Vpfzm e UIOlk ou particular. A clnica funciona com um pequeno nmero de atendentes responsveis pela marcao de consultas, preenchimento inicial de dados cadastrais. Cada mdico faz 3 plantes semanais de 4 horas seguidas, as consultas possuem um intervalo de 30 minutos. Existe a possibilidade de a consulta ser de retorno, neste caso so apenas 15 minutos. A clnica 24 horas. Cada mdico possui uma agenda preta onde so marcadas as consultas. Na marcao da consulta colocado o nome do paciente, horrio e convnio. A clnica possui 2 atendentes que so responsveis por preencher o cadastro inicial do paciente que contm nome, endereo, telefone, data de nascimento, convnio.
256
O mdico, ao atender o paciente, preenche sua ficha manualmente, informando peso, altura, idade, motivo da consulta, queixa principal, doenas anteriores, diagnstico, prescrio. A prescrio pode ser a solicitao de exames ou medicamentos com posologia. 4 Identificao do principal objetivo do cliente. O objetivo principal o aumento na eficincia e tempo de resposta no processo de marcao de consultas. 5 Descrio dos usurios do sistema. Mdicos Todos os 34 mdicos possuem especializao, todos possuem conhecimentos bsicos de informtica e noo do funcionamento e procedimentos da clnica. A faixa etria se encontra entre 30 e 48 anos. Nenhum mdico possui qualquer deficincia fsica. Atendente As 2 atendentes possuem o segundo grau completo, razovel experincia em informtica e conhecimento do processo de funcionamento da clnica. As atendentes esto na clnica h aproximadamente 3 anos. Paciente Existem aproximadamente 800 fichas na clnica. A clnica no sabe precisar se sua clientela possui acesso internet. A clnica possui aproximadamente 85% das consultas realizadas por convnio. 6 Descrio detalhada dos processos existentes ( COMO O SISTEMA ATUAL FUNCIONA?). Marcao da consulta O paciente pode realizar o agendamento da consulta pessoalmente ou por telefone; em qualquer dos dois mtodos os procedimentos so idnticos. O paciente solicita a consulta informando o nome do mdico ou a especialidade desejada, posteriormente informa a data desejada. A atendente verifica a possibilidade de marcao da consulta (observando se o mdico em questo possui horrio vago para a data desejada). Se existe horrio disponvel, a atendente solicita ao paciente o tipo de convnio ou se particular. Se for convnio, verificado se um convnio vlido; se for particular, informado o valor da consulta. A atendente atualiza a agenda com o nome do paciente e o tipo de consulta (convnio/particular). O tempo para cada consulta de 20 minutos ou 15 minutos para retorno. O mdico possui intervalo de 10 minutos. A consulta pode ser uma consulta de retorno, nesse caso a atendente verifica se a data est ainda dentro do prazo de retorno de 15 dias. Em caso afirmativo, a consulta marcada na agenda. Mdico indisponvel Caso o mdico solicitado esteja indisponvel, a atendente procura informar o nome de outro mdico disponvel naquele horrio ou o prximo horrio disponvel.
257
Atendimento Se o paciente j possui cadastro, o mesmo convidado a adentrar no consultrio do mdico. A partir desse momento, o mdico solicita informaes procedimentais para o futuro diagnstico, preenchendo a ficha do paciente. Finalizada a consulta, o paciente liberado e a ficha recolhida pela atendente, sendo novamente arquivada. Se o paciente for novo, a atendente solicita o preenchimento da ficha cadastral com dados pessoais. 7 Itens produzidos no sistema (quais so os relatrios e consultas existentes ou solicitados pelos clientes). Nesse momento a clnica possui os seguintes documentos: Agenda So anotados o nome do paciente (60 caracteres), horrio (hora/minuto) e convnio (Bruxtr, Vpfzm e UIOlk ou particular). Ficha do paciente Nome (60 caracteres), endereo (60 caracteres), telefone (12 caracteres), data de nascimento (date), convnio (Bruxtr, Vpfzm e UIOlk ou particular). Ficha mdica Apresenta peso do paciente (numrico (03V2), altura (numrico (2V2), idade (numrico 3), motivo da consulta (Alfanumrico 100), queixa principal (Alfanumrico 100), doenas anteriores (Alfanumrico 150), diagnstico (Alfanumrico 150), prescrio (Alfanumrico 200). A prescrio pode ser a solicitao de exames ou medicamentos com posologia. Relao de horrios mdicos A listagem contm nome do mdico (Alfanumrico 50), data (date) e horrio (numrico 2V2) de atendimento do mdico na clnica. Relao de atendimentos por tipo O relatrio emitido mensalmente, apresentando o nome do convnio, listando a partir dele o nome do mdico e o total de consultas realizadas para o convnio. Ao final apresentado o total de atendimentos por convnio. Obs.: 3V2 significa uma variao numrica de at 999,99. 8 Volume de informaes do sistema atual. A clnica possui aproximadamente 800 pacientes cadastrados, 34 mdicos ativos e 2 atendentes. Apresenta convnio mdico com 3 empresas, mas possibilidades de aumentar esse nmero. A clnica realiza em torno de 56 consultas por dia. 9 Descrio de situaes consideradas crticas e atores envolvidos. A clnica apresenta situaes crticas relacionadas marcao incorreta de horrio, com mdico indesejado ou mesmo data e horrio indesejados. As atendentes poderiam ser orientadas para telefonar ao paciente confirmando a consulta com trs horas de antecedncia.
258
10 Restries do projeto. O cliente no deseja dispender recursos com a plataforma de sistema operacional e o banco de dados, sendo que deve ser considerada uma possibilidade open source.
Unidade 3
1) Sequncia correta : B, G, D, F, C, E, D. 2) a) Um professor leciona vrias disciplinas em sua universidade.
disciplina professor 0.n 0.1
b) A universidade emprega vrios funcionrios.

universidade funcionrio 1 0.n
c) Os funcionrios so lotados em um departamento.

departamento funcionrio 1 0.n
d) Um aluno pode estar matriculado em nenhuma ou vrias disciplinas.

aluno (0,n) disciplina
(0,n)
Unidade 4
1) As alternativas corretas so: (a) e (b). 2) A sequncia : a) C b) O c) O d) O e) C
259
3) A sequncia correta : a) Poliformismo b) Encapsulamento c) Mensagem d) Herana 4) A sequncia correta : a) A b) B c) D d) C e) A f) E g) B
Unidade 5
1) A afirmativa correta : (b). 2) A sequncia correta : a) V b) F c) F d) V e) F f) V 3) A sequncia correta : a) A b) B c) C d) D e) B
260
f) D g) A 4) A definio dos requisitos funcionais: RF01 RF02 RF03 RF04 RF05 RF06 RF07 RF08 RF09 O sistema deve permitir o gerenciamento de funcionrios e seus dados cadastrais O sistema deve controlar o sistema de acesso de acordo com as permisses de cada ator. Deve ser possvel realizar o gerenciamento de horrio dos funcionrios. O sistema deve possibilitar o lanamento de horrios de consulta por meio de uma agenda mdica. Deve ser possvel a consulta de horrios marcados por mdico, por data. O sistema deve possibilitar o gerenciamento de paciente (cadastro e ficha mdica). Deve ser possvel incluir novos convnios ou mesmo excluir convnios com os quais a clnica opera. necessrio que o sistema oferea relatrios estatsticos de atendimento por convnio. necessrio que o sistema emita relatrios estatsticos de atendimento por rea de especializao.
A definio dos atores: Ator Descrio Todos os 34 mdicos possuem especializao, todos possuem conhecimentos bsicos de informtica e noo do funcionamento e procedimentos da clnica. A faixa etria se encontra entre 30 e 48 anos. Nenhum mdico possui qualquer deficincia fsica. As 2 atendentes possuem o segundo grau completo, razovel experincia em informtica e conhecimento do processo de funcionamento da clnica. As atendentes esto na clnica h aproximadamente 3 anos. Pacientes com faixa etria at 14 anos, sob custdiaa e agendamento dos pais. Mdico especialista possui conhecimentos bsicos de informtica e noo do funcionamento e procedimentos da clnica. Possui 42 anos no apresenta nenhuma deficincia fsica. Responsabilidade
Mdicos
Gerenciamento de paciente.
Atendente
Gerenciamento de horrio dos funcionrios. Gerenciamento de agenda mdica. Permitir consulta de horrios marcados por mdico, por data. Gerenciamento de paciente (cadastro). Gerenciamento de agenda mdica (marcar consulta).
Paciente
Gerente
Acesso a todas as funcionalidades.
261
Os diagramas de 3 casos de uso e a tabela de documentao do caso de uso: Caso de uso: CSU001 Gerenciamento de Funcionrio
CSU 005 Gerenciar Ficha Cadastral Paciente
Atendente
CSU 002 Agendar horrio
extend
Breve descrio Ator primrio Ator secundrio Precondies
Gerenciamento do cadastro de dados pessoais e horrios de trabalho de funcionrios da clnica. Gerente Funcionrio O gerente estar devidamente logado no sistema. 1. O gerente solicita uma incluso de funcionrio; 2. O gerente informa o nome do funcionrio; 3. O sistema informa o cdigo do funcionrio; 4. O gerente informa os dados pessoais do funcionrio; 5. O gerente informa os horrios em que o mesmo estar na clnica(CSU); 6. O registro do funcionrio armazenado. No item 2, caso o nome j exista. Nesse caso: 1.1 So apresentados os dados cadastrais do funcionrio; 1.2 So apresentadas as possibilidades de alterar, excluir ou finalizar. Dados do funcionrio armazenados. RF01 O sistema deve permitir o gerenciamento de funcionrios e seus dados cadastrais. RN01 O funcionrio do tipo mdico s pode ser excludo se no houver nenhuma consulta agendada.
Fluxo principal
Fluxo alternativo e excees
Ps-condies Requisito funcional Regras de negcio
262
Caso de uso: CSU002 Agendamento de Horrio

CSU 005 Gerenciar Ficha Cadastral Paciente
Atendente
CSU 002 Agendar horrio
extend
O caso de uso permite o agendamento do horrio de consulta do paciente. Atendente Paciente - O atendente estar devidamente logado no sistema; - horrios mdicos disponibilizados. 1. O paciente informa o nome do mdico, data e horrio desejado; 2. O atendente solicita a consulta para o mdico informado nas datas solicitadas; 3. O atendente verifica se primeira consulta na clnica. a. Se sim, executa o caso de uso gerenciar ficha cadastral paciente 4. O atendente solicita o tipo de consulta; 5. O agendamento do horrio armazenado. 6. A atendente informa novamente data, hora e mdico da consulta para o paciente. No item 1, caso o paciente no informe o nome do mdico. Nesse caso: a atendente sugere o nome de um dos mdicos segundo sua especialidade. No item 2, caso no haja horrio disponvel para o mdico. Nesse caso: a atendente sugere outro horrio, ou o nome de um segundo mdico segundo sua especialidade. Consulta marcada. RF04 O sistema deve possibilitar o lanamento de horrios de consulta por meio de uma agenda mdica. RN02 se o tipo de consulta for retorno, agendar somente 10 minutos na agenda. Se for consulta normal, agendar 20 minutos.
Fluxo principal
Fluxo alternativo e excees
Ps-condies Requisito funcional Regras de negcio
263
Caso de uso: CSU003 Cadastro de Convnios
Neste caso ocorre o gerenciamento dos convnios. Gerente
O gerente deve estar devidamente logado no sistema. 1. 2. 3. 4. 5. O gerente solicita uma incluso de convnio., Informado o nome do convnio. O sistema informa o cdigo interno do convnio. So informados dados cadastrais do convnio. Os dados so armazenados.
Fluxo principal
Fluxo alternativo e excees Ps-condies Requisito funcional Regras de negcio
No item 2, caso o nome j exista. Nesse caso: so apresentados os dados cadastrais do funcionrio; so apresentadas as possibilidades de alterar, excluir ou finalizar. Consulta marcada. RF07 Deve ser possvel incluir novos convnios ou mesmo excluir convnios com os quais a clnica opera.
Unidade 6
1) As alternativas corretas so: (b) e (d). 2) A sequncia : a) c b) a c) a d) b e) c f) b
264
3) A sequncia : a) G b) B c) C d) E e) F f) D g) A
4) a) As classes persistentes. possvel identificar: A classe Paciente que armazena os dados cadastrais do paciente. A classe Agendamentos que armazena o horrio das consultas, nome do paciente e mdico. A classe Funcionrio armazena os dados dos funcionrios, inclusive do funcionrio mdico. A classe Horrio que armazena o horrio de atendimentos da equipe mdica A classe Ficha Mdica armazena a ficha de atendimento do paciente.
b)
265
Unidade 7
1) A sequncia correta : a) B b) D c) F d) A e) H f) E g) G h) I i) C
266
2) No diagrama a seguir, so descritos dois diagramas: o Listar Agenda e o Agendamento do Horrio. CSU002 Agendamento de Horrio
3) Alternativa correta: b.
267
Unidade 8
1) a) Esta modificao chamada de transio entre estados. b) Os estados representam o resultado de atividades executadas por um objeto. c) O estado final indica o final do ciclo de vida de um objeto. d) Os objetos de um sistema modificam seu estado de forma anloga a objetos do mundo real.
2) a) DTE b) DA c) DTE d) DA
3) a) E b) B c) A d) C e) E
268
4) Diagrama de atividades do caso de uso Marcar Consulta da Clnica BemEstar a partir da viso do ator Atendente.
269
Unidade 9
1) As afirmativas corretas so: (b) e (d). 2) Um papel uma definio abstrata de um conjunto de atividades executadas e dos respectivos artefatos. Analista de Sistemas O papel do Analista de Sistemas liderar e coordenar a identificao de requisitos e a modelagem de casos de uso, delimitando o sistema e definindo sua funcionalidade; por exemplo, estabelecendo quais so os atores e casos de uso existentes e como eles interagem. Analista de Teste O papel do Analista de Teste inicialmente identificar e posteriormente definir os testes necessrios, monitorar a abrangncia dos testes e avaliar a qualidade geral obtida ao testar os Itens de Teste-alvo. Este papel tambm envolve a especificao dos Dados de Teste necessrios e a avaliao do resultado dos testes conduzidos em cada ciclo de teste
3) a) E b) A c) C d) D e) B
4) O modelo utilizado ser dependente do tipo de produto a ser desenvolvido e da dinmica da empresa desenvolvedora, mas podemos citar 3 modelos que podem ser considerados interessantes em qualquer tipo de projeto:

Modelo de domnio que procura estabelecer o contexto do sistema; Modelo de caso de uso que estabelece os requisitos funcionais do sistema; Modelo do processo que estabelece os mecanismos de concorrncia e de sincronizao do sistema.
270
Biblioteca Virtual
Veja a seguir os servios oferecidos pela Biblioteca Virtual aos alunos a distncia:
Pesquisa a publicaes on-line <www.unisul.br/textocompleto> Acesso a bases de dados assinadas <www.unisul.br/bdassinadas> Acesso a bases de dados gratuitas selecionadas <www.unisul.br/bdgratuitas > Acesso a jornais e revistas on-line <www.unisul.br/periodicos> Emprstimo de livros <www.unisul.br/emprestimos> Escaneamento de parte de obra*
Acesse a pgina da Biblioteca Virtual da Unisul, disponvel no EVA, e explore seus recursos digitais. Qualquer dvida escreva para: bv@unisul.br
* Se voc optar por escaneamento de parte do livro, ser lhe enviado o sumrio da obra para que voc possa escolher quais captulos deseja solicitar a reproduo. Lembrando que para no ferir a Lei dos direitos autorais (Lei 9610/98) pode-se reproduzir at 10% do total de pginas do livro.

(7428 - 22159) Metodologias e Projetos de Software

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

(7428 - 22159) Metodologias e Projetos de Software

Încărcat de

Drepturi de autor:

Formate disponibile

Universidade do Sul de Santa Catarina

Metodologias e Projetos de Software

Palhoa UnisulVirtual 2011

Patrcia de Souza Amorim Poliana Simao Schenon Souza Preto

Gerncia de Desenho e Desenvolvimento de Materiais Didticos

Bruno Lucion Roso Sheila Cristina Martins

Marketing Estratgico Portal e Comunicao

Gerncia Administrativa e Financeira

Gerncia de Ensino, Pesquisa e Extenso

Carolina Hoeller da Silva Boing Vanderlei Brasil Francielle Arruda Rampelotte

Gerncia de Produo Design Visual

Secretaria Executiva e Cerimonial

Assessoria de Assuntos Internacionais

Assessoria de Relao com Poder Pblico e Foras Armadas

Assessoria DAD - Disciplinas a Distncia

Gerncia de Logstica Logsitca de Materiais

Marcelo Bittencourt (Coord.)

Gerncia Servio de Ateno Integral ao Acadmico

Gesto Docente e Discente

Enzo de Oliveira Moreira (Coord.)

Capacitao e Assessoria ao Docente

Assessoria de Inovao e Qualidade de EAD

Secretaria de Ensino a Distncia

Coordenao Cursos Coordenadores de UNA

Eliza B. Dallanhol Locks (Gerente)

Vera R. Niedersberg Schuhmacher

Metodologias e Projetos de Software

Design instrucional Lvia da Cruz 6 edio

Palhoa UnisulVirtual 2011

Edio Livro Didtico

Ficha catalogrfica elaborada pela Biblioteca Universitria da Unisul

Bom estudo e sucesso! Equipe UnisulVirtual.

Universidade do Sul de Santa Catarina

Universidade do Sul de Santa Catarina

Metodologias e Projetos de Software

Unidade 1 - ciclos de vida de um processo de desenvolvimento de software

Unidade 2 - Engenharia de requisitos

Unidade 3 - Anlise estruturada

Universidade do Sul de Santa Catarina

Unidade 4 - Viso geral da UML

Unidade 5 - Modelagem de casos de uso

Unidade 6 - Modelagem de classes

Unidade 7 - Modelos de interaes

Metodologias e Projetos de Software

Unidade 8 - Modelos de estados

Unidade 9 - RUP e ICONIX

Universidade do Sul de Santa Catarina

Demais atividades (registro pessoal)

Ciclos de vida de um processo de desenvolvimento de software

Universidade do Sul de Santa Catarina

Para incio de estudo

Seo 1 Quais so as caractersticas do software?

Metodologias e Projetos de Software

Universidade do Sul de Santa Catarina

Metodologias e Projetos de Software

Imagine as seguintes situaes:

Seo 2 Quais so as etapas do processo de desenvolvimento de software?

Universidade do Sul de Santa Catarina

A primeira definio do termo foi dada por Fritz Bauer em 1969:

Metodologias e Projetos de Software

Figura 1.1 Etapas do desenvolvimento de software Fonte: Pressman (2002).

Universidade do Sul de Santa Catarina

Cada etapa pode ser detalhada como: