Metodologias e Projetos de Software PDF

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
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
Reitor Coordenadores Graduao Marilene de Ftima Capeleto Patrcia de Souza Amorim Karine Augusta Zanoni
Ailton Nazareno Soares Alosio Jos Rodrigues Patricia A. Pereira de Carvalho Poliana Simao Marcia Luz de Oliveira
Ana Lusa Mlbert Paulo Lisboa Cordeiro Schenon Souza Preto Mayara Pereira Rosa
Vice-Reitor Ana Paula R.Pacheco Paulo Mauricio Silveira Bubalo Luciana Tomado Borguetti
Sebastio Salsio Heerdt Artur Beck Neto Rosngela Mara Siegel Gerncia de Desenho e
Bernardino Jos da Silva Simone Torres de Oliveira Desenvolvimento de Materiais Assuntos Jurdicos
Chefe de Gabinete da Reitoria Charles Odair Cesconetto da Silva Vanessa Pereira Santos Metzker Didticos Bruno Lucion Roso
Willian Corra Mximo Dilsa Mondardo Vanilda Liordina Heerdt Mrcia Loch (Gerente) Sheila Cristina Martins
Diva Marlia Flemming Marketing Estratgico
Pr-Reitor de Ensino e Horcio Dutra Mello Gesto Documental Desenho Educacional
Lamuni Souza (Coord.) Cristina Klipp de Oliveira (Coord. Grad./DAD) Rafael Bavaresco Bongiolo
Pr-Reitor de Pesquisa, Itamar Pedro Bevilaqua
Ps-Graduao e Inovao Jairo Afonso Henkes Clair Maria Cardoso Roseli A. Rocha Moterle (Coord. Ps/Ext.) Portal e Comunicao
Daniel Lucas de Medeiros Aline Cassol Daga Catia Melissa Silveira Rodrigues
Mauri Luiz Heerdt Janana Baeta Neves
Aline Pimentel
Jorge Alexandre Nogared Cardoso Jaliza Thizon de Bona Andreia Drewes
Pr-Reitora de Administrao Jos Carlos da Silva Junior Guilherme Henrique Koerich Carmelita Schulze Luiz Felipe Buchmann Figueiredo
Acadmica Jos Gabriel da Silva Josiane Leal Daniela Siqueira de Menezes Rafael Pessi
Marlia Locks Fernandes Delma Cristiane Morari
Miriam de Ftima Bora Rosa Jos Humberto Dias de Toledo
Eliete de Oliveira Costa
Joseane Borges de Miranda Gerncia de Produo
Pr-Reitor de Desenvolvimento Luiz G. Buchmann Figueiredo Gerncia Administrativa e Elosa Machado Seemann Arthur Emmanuel F. Silveira (Gerente)
e Inovao Institucional Marciel Evangelista Catneo Financeira Flavia Lumi Matuzawa Francini Ferreira Dias
Renato Andr Luz (Gerente) Geovania Japiassu Martins
Valter Alves Schmitz Neto Maria Cristina Schweitzer Veit
Ana Luise Wehrle Isabel Zoldan da Veiga Rambo Design Visual
Maria da Graa Poyer
Diretora do Campus Mauro Faccioni Filho Anderson Zandr Prudncio Joo Marcos de Souza Alves Pedro Paulo Alves Teixeira (Coord.)
Universitrio de Tubaro Moacir Fogaa Daniel Contessa Lisboa Leandro Roman Bamberg Alberto Regis Elias
Milene Pacheco Kindermann Nlio Herzmann Naiara Jeremias da Rocha Lygia Pereira Alex Sandro Xavier
Onei Tadeu Dutra Rafael Bourdot Back Lis Air Fogolari Anne Cristyne Pereira
Diretor do Campus Universitrio Patrcia Fontanella Thais Helena Bonetti Luiz Henrique Milani Queriquelli Cristiano Neri Gonalves Ribeiro
da Grande Florianpolis Roberto Iunskovski Valmir Vencio Incio Marcelo Tavares de Souza Campos Daiana Ferreira Cassanego
Hrcules Nunes de Arajo Rose Clr Estivalete Beche Mariana Aparecida dos Santos Davi Pieper
Gerncia de Ensino, Pesquisa e Marina Melhado Gomes da Silva Diogo Rafael da Silva
Secretria-Geral de Ensino Vice-Coordenadores Graduao Extenso Marina Cabeda Egger Moellwald Edison Rodrigo Valim
Adriana Santos Ramm Janana Baeta Neves (Gerente) Mirian Elizabet Hahmeyer Collares Elpo Fernanda Fernandes
Solange Antunes de Souza Aracelli Araldi Pmella Rocha Flores da Silva
Bernardino Jos da Silva Frederico Trilha
Diretora do Campus Catia Melissa Silveira Rodrigues Rafael da Cunha Lara Jordana Paula Schulka
Elaborao de Projeto Roberta de Ftima Martins Marcelo Neri da Silva
Universitrio UnisulVirtual Horcio Dutra Mello Carolina Hoeller da Silva Boing
Jucimara Roesler Jardel Mendes Vieira Roseli Aparecida Rocha Moterle Nelson Rosa
Vanderlei Brasil Sabrina Bleicher Noemia Souza Mesquita
Joel Irineu Lohn Francielle Arruda Rampelotte
Equipe UnisulVirtual Jos Carlos Noronha de Oliveira Vernica Ribas Crcio Oberdan Porto Leal Piantino
Jos Gabriel da Silva Reconhecimento de Curso
Jos Humberto Dias de Toledo Acessibilidade Multimdia
Diretor Adjunto Maria de Ftima Martins Vanessa de Andrade Manoel (Coord.) Srgio Giron (Coord.)
Moacir Heerdt Luciana Manfroi
Rogrio Santos da Costa Extenso Letcia Regiane Da Silva Tobal Dandara Lemos Reynaldo
Secretaria Executiva e Cerimonial Rosa Beatriz Madruga Pinheiro Maria Cristina Veit (Coord.) Mariella Gloria Rodrigues Cleber Magri
Jackson Schuelter Wiggers (Coord.) Sergio Sell Vanesa Montagna Fernando Gustav Soares Lima
Marcelo Fraiberg Machado Pesquisa Josu Lange
Tatiana Lee Marques Daniela E. M. Will (Coord. PUIP, PUIC, PIBIC) Avaliao da aprendizagem
Tenille Catarina Valnei Carlos Denardin Claudia Gabriela Dreher Conferncia (e-OLA)
Mauro Faccioni Filho (Coord. Nuvem)
Assessoria de Assuntos Smia Mnica Fortunato (Adjunta) Jaqueline Cardozo Polla Carla Fabiana Feltrin Raimundo (Coord.)
Internacionais Ps-Graduao Ngila Cristina Hinckel Bruno Augusto Zunino
Coordenadores Ps-Graduao Anelise Leal Vieira Cubas (Coord.) Sabrina Paula Soares Scaranto
Murilo Matos Mendona Alosio Jos Rodrigues Gabriel Barbosa
Anelise Leal Vieira Cubas Thayanny Aparecida B. da Conceio
Assessoria de Relao com Poder Biblioteca Produo Industrial
Pblico e Foras Armadas Bernardino Jos da Silva Salete Ceclia e Souza (Coord.) Gerncia de Logstica Marcelo Bittencourt (Coord.)
Adenir Siqueira Viana Carmen Maria Cipriani Pandini Paula Sanhudo da Silva Jeferson Cassiano A. da Costa (Gerente)
Walter Flix Cardoso Junior Daniela Ernani Monteiro Will Marlia Ignacio de Espndola Gerncia Servio de Ateno
Giovani de Paula Renan Felipe Cascaes Logsitca de Materiais Integral ao Acadmico
Assessoria DAD - Disciplinas a Karla Leonora Dayse Nunes Carlos Eduardo D. da Silva (Coord.) Maria Isabel Aragon (Gerente)
Distncia Letcia Cristina Bizarro Barbosa Gesto Docente e Discente Abraao do Nascimento Germano Ana Paula Batista Detni
Patrcia da Silva Meneghel (Coord.) Luiz Otvio Botelho Lento Enzo de Oliveira Moreira (Coord.) Bruna Maciel Andr Luiz Portes
Carlos Alberto Areias Roberto Iunskovski Fernando Sardo da Silva Carolina Dias Damasceno
Cludia Berh V. da Silva Rodrigo Nunes Lunardelli Capacitao e Assessoria ao Fylippy Margino dos Santos Cleide Incio Goulart Seeman
Conceio Aparecida Kindermann Rogrio Santos da Costa Docente Guilherme Lentz Denise Fernandes
Luiz Fernando Meneghel Thiago Coelho Soares Alessandra de Oliveira (Assessoria) Marlon Eliseu Pereira Francielle Fernandes
Renata Souza de A. Subtil Vera Rejane Niedersberg Schuhmacher Adriana Silveira Pablo Varela da Silveira Holdrin Milet Brando
Alexandre Wagner da Rocha Rubens Amorim
Assessoria de Inovao e Jenniffer Camargo
Gerncia Administrao Elaine Cristiane Surian (Capacitao) Yslann David Melo Cordeiro Jessica da Silva Bruchado
Qualidade de EAD Acadmica Elizete De Marco
Denia Falco de Bittencourt (Coord.) Jonatas Collao de Souza
Angelita Maral Flores (Gerente) Fabiana Pereira Avaliaes Presenciais
Andrea Ouriques Balbinot Juliana Cardoso da Silva
Fernanda Farias Iris de Souza Barros Graciele M. Lindenmayr (Coord.)
Carmen Maria Cipriani Pandini Juliana Elen Tizian
Juliana Cardoso Esmeraldino Ana Paula de Andrade
Secretaria de Ensino a Distncia Kamilla Rosa
Maria Lina Moratelli Prado Angelica Cristina Gollo
Assessoria de Tecnologia Samara Josten Flores (Secretria de Ensino) Simone Zigunovas
Mariana Souza
Osmar de Oliveira Braz Jnior (Coord.) Cristilaine Medeiros Marilene Ftima Capeleto
Giane dos Passos (Secretria Acadmica) Daiana Cristina Bortolotti
Felipe Fernandes Adenir Soares Jnior Tutoria e Suporte Maurcio dos Santos Augusto
Felipe Jacson de Freitas Delano Pinheiro Gomes Maycon de Sousa Candido
Alessandro Alves da Silva Anderson da Silveira (Ncleo Comunicao) Edson Martins Rosa Junior
Jefferson Amorin Oliveira Andra Luci Mandira Claudia N. Nascimento (Ncleo Norte- Monique Napoli Ribeiro
Phelipe Luiz Winter da Silva Fernando Steimbach Priscilla Geovana Pagani
Cristina Mara Schauffert Nordeste)
Fernando Oliveira Santos
Priscila da Silva Djeime Sammer Bortolotti Maria Eugnia F. Celeghin (Ncleo Plos) Sabrina Mari Kawano Gonalves
Rodrigo Battistotti Pimpo Lisdeise Nunes Felipe Scheila Cristina Martins
Douglas Silveira Andreza Talles Cascais Marcelo Ramos
Tamara Bruna Ferreira da Silva Evilym Melo Livramento Daniela Cassol Peres Taize Muller
Marcio Ventura Tatiane Crestani Trentin
Fabiano Silva Michels Dbora Cristina Silveira Osni Jose Seidler Junior
Coordenao Cursos Fabricio Botelho Espndola Ednia Araujo Alberto (Ncleo Sudeste) Thais Bortolotti
Coordenadores de UNA Felipe Wronski Henrique Francine Cardoso da Silva
Diva Marlia Flemming Gisele Terezinha Cardoso Ferreira Janaina Conceio (Ncleo Sul) Gerncia de Marketing
Marciel Evangelista Catneo Indyanara Ramos Joice de Castro Peres Eliza B. Dallanhol Locks (Gerente)
Roberto Iunskovski Janaina Conceio Karla F. Wisniewski Desengrini
Jorge Luiz Vilhar Malaquias Kelin Buss Relacionamento com o Mercado
Auxiliares de Coordenao Juliana Broering Martins Liana Ferreira Alvaro Jos Souto
Ana Denise Goularte de Souza Luana Borges da Silva Luiz Antnio Pires
Camile Martinelli Silveira Luana Tarsila Hellmann Maria Aparecida Teixeira Relacionamento com Polos
Fabiana Lange Patricio Luza Koing Zumblick Mayara de Oliveira Bastos Presenciais
Tnia Regina Goularte Waltemann Maria Jos Rossetti Michael Mattar Alex Fabiano Wehrle (Coord.)
Jeferson Pandolfo
Vera R. Niedersberg Schuhmacher
Metodologias e Projetos de
Software
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.
7
Palavras da professora
Caro aluno/a,
A disciplina Metodologias e Projetos de Software vai inseri-

lo/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 use-
case, 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
Metodologias e Projetos de Software
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
1
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 Quais so as caractersticas do software?
Seo 2 Quais so as etapas do processo de

desenvolvimento de software?
Seo 3 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
Seo 2 Quais so as etapas do processo de pela fuso do Instituto

de Engenheiros de Rdio
desenvolvimento de software? (IRA) com o Instituto
Americano de Engenheiros
Eltricos (AIEE). A meta
Existem alguns conceitos que so fundamentais quando falamos
do IEEE promover
de desenvolvimento, e o primeiro deles Engenharia de conhecimento no campo
Software (EGS). Assim como a palavra software, Engenharia de da engenharia eltrica e
Software tambm um termo que gera discusses sobre a melhor eletrnica estabelecendo
maneira de expor todas as suas nuances. padres para formatos
de computadores e
dispositivos.
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:
Wilson de Pdua Paula
Filho ser referenciado
deve ser concebido a partir da percepo de uma como Pdua neste livro
necessidade; pelo fato de ser assim
conhecido na rea
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?
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

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

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 ( ) Composto por atividades que

ocorrem no decorrer de todo o
B. Levantamento de processo de desenvolvimento, como
requisitos revises, controle de mudanas e
C. Desenvolvimento documentao.
D. Projeto de ( ) Define o que deve ser feito para apoiar

software o cliente em seus problemas
E. Manuteno ( ) Nessa etapa, so executados o projeto,

F. Revises codificao e testes do software.
G. Atividades de ( ) Etapa que identifica as necessidades

apoio do cliente.
H. Anlise de
requisitos ( ) 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
2
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 Engenharia de requisitos
Seo 2 Levantamento de requisitos
Seo 3 Especificao de requisitos
Seo 4 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 Lembre-se: A pressa para

Fonte: Pdua (2001). chegar implementao
no ser o caminho mais
A dificuldade de entender o cliente um desafio que deve ser curto.
encarado a partir de tcnicas, mtodos e pacincia por parte do
desenvolvedor.
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 pessoas-
chave 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 pergunta-
resposta. 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 Lembre-se: Inclua em

sistema; sua lista de entrevistados
pessoas-chave dentro do
futuro sistema.
preparar-se antecipadamente para a entrevista.
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.
Uma dica interessante
aplicar o questionrio em
c) Observao direta uma amostra de usurios,
solicitando a avaliao
sobre a estrutura e o
A observao direta pode ser utilizada como validao das
contedo do mesmo.
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.
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
O Rational Unified Process (RUP)
um processo de engenharia de
notao oferecida pela anlise estruturada ou orientada a objetos).
software que pretende aumentar a Essa deciso depende da metodologia que voc estiver utilizando
produtividade da equipe oferecendo ou mesmo do grau de maturidade da empresa.
prticas eficientes executadas
por meio de diretrizes, templates O uso de uma especificao textual pode ser feito na forma de
e orientaes sobre ferramentas
relatrios. Peters (2001) sugere um conjunto de quatro questes
para todas as atividades crticas de
desenvolvimento de software. que devem ser abordadas:
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 Perspectiva do produto: seu relacionamento

2.2 Funes do produto com o sistema maior.
2.3 Caractersticas do usurio Hipteses: indicam como alteraes feitas na
ERS afetam sees especficas da ERS (exemplo:
2.4 Restries quais diagramas de fluxo de dados so afetados
2.5 Hipteses e dependncias ou mudanas de funes ou excluso das
2.6 Distribuio de requisitos mesmas)
3. Requisitos especficos
3.1 Interfaces externas

3.2 Requisitos de processo e dados
3.3 Requisitos de desempenho e qualidade Restries de projeto: polticas regulamentares,
limitaes de hardware, interfaces com outros
3.4 Requisitos de banco de dados lgico aplicativos, operao paralela, segurana e
3.5 Restries de projeto perfil etc.
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).
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
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 BEM-

ESTAR
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
3
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 Anlise estruturada
Seo 2 Diagrama de Fluxo de Dados (DFD)
Seo 3 Dicionrio de dados
Seo 4 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.
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.
Processo
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.
Entidades
externas 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).
Depsito de Todas as informaes do paciente como nome, endereo, telefone sero
dados armazenados em seu HD em um depsito de dados. Neste exemplo, um
nome adequado para o depsito seria Paciente.
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
Fluxo de dados devero passar.
dados 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.).
Quadro 3.1 Smbolos que compem o DFD

Acompanhe na figura 3.1, a seguir, o processo Cadastrar Paciente.
Figura 3.1 DFD (processo Cadastrar Paciente)

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

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

76
Mas, se voc quiser detalhar esses processos, o DFD oferece mais

informaes para o desenvolvedor:
Figura 3.4 DFD Agendar Consulta

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.
Unidade 3 79
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

Gerente
Atendente Cliente
Dados Produto
Dados Pedido
Dados Cliente / Produto
Gerenciar Dados Cliente / Produto Gerenciar

Cadastros Pedidos
Dados Produto
Dados Pedido
Dados Cliente
Dados Produto
1 Dados Cliente 3 Dados Pedido

2 Dados Produto

80
Atendente Cliente
MSG Produto Indisponvel
produto, quantidade
Nome Cliente, tipo
Solicitar
Endereo, telefone, cpf, etc

Produto
nome Cliente
Verificar
MSg Cliente Inexistente
Existncia 1 Dados do Cliente
Cliente
Nome, Endereo, telefone, CPF, etc

Cadastrar
Dados
Cliente
Pedido, produto
Pedido, produto
Dados do Verifica
Produto existncia do
2 Dados do Produto
Produto
Cadastrar
Produto
cdigo, descrio, preo, quantidade, custo
Saldo atual produto

Dados do Pedido
Preenche
dados do
Pedido
Detalhes do Pedido
Imprime
Entrega
Pedido
3 Dados do Pedido

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

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).
Entidade 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
Atributo 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
Relacionamento que o paciente Almir (uma instncia da entidade Paciente) possui n
agendamentos (na entidade Agenda).
Quadro 3.2 Simbologia utilizada em um diagrama ER

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 Nome: Joana da Silva
Telefone: 88890899 Telefone: 8887777
CPF: 483.432.546-65 CPF: 488.444.449-35
Endereo: Rua do Pntano 120 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 Realiza Agenda
Figura 3.10 Recorte de um diagrama ER

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

O que cardinalidade?
Observe os exemplos a seguir. So exemplos de relacionamento,

porm sem a indicao do nmero de relacionamentos existentes
entre eles.
Aloca
Cliente Filmes
Atende
Mdico Pacientes
Contm
Pedidos Produtos
Tem
Cliente Carto
Figura 3.12 Exemplos de relacionamento

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 Carto
Ana Lopes 234567-9
Jean Bondex 237987-9
Carlos Xion 335567-9
Figura 3.13 Cardinalidade 1 para 1 (1:1)

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
Cliente DVD
1 (0,n)
Joo Augusto Tubaro II
Madagascar
Bob Esponja
Figura 3.14 Cardinalidade 1 para N (1:N)

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
Funcionrios Projetos
N N
Folha de
Joo Augusto
Pagamento
Estoque
Carlos Xim
CRM
Contas a
Pagar
Figura 3.15 Cardinalidade N para N (N:N)
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.

Unidade 3 89
Neste caso, o relacionamento seria:
(1) (0,n)
Paciente Agenda Consulta
(0,n)
(1)
Mdico
Figura 3.16 Exemplo de cardinalidade Clnica Bem-Estar

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.

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
1) Relacione os conceitos a seguir, observando que uma mesma opo
pode se repetir.
A. Diagrama de fluxo ( ) Notao utilizada para descrever o

de dados contedo e significado de fluxos,
entidades externas, processos e
depsitos de dados.
B. Dicionrio de dados ( ) Notao que permite representar um

processo em um DFD.
C. Descrio dos ( ) Utilizado para representar o cliente em
processos um DFD.
D. Fluxo de dados ( ) Utilizado para representar um

repositrio de dados em um DFD.
E. Fluxo de dados ( ) Permite descrever os fluxos de
informao e as transformaes
sofridas pelos dados durante a
execuo do processo.
F. Depsito de dados ( ) Utilizado para representar os dados

que sero inseridos no processo em
um DFD.
G. Processo ( ) 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.
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
Professor
audiovisual
(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
4
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 O paradigma da orientao a objetos
Seo 2 A origem das linguagens de modelagem
Seo 3 As cinco vises da UML
Seo 4 Diagramas da UML
Seo 5 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 MTODOS
+
DADOS 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 entrada-
processamento-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

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

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 Hewlett-
Packard, 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 (cdigo-
fonte, 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 VISO DE IMPLANTAO

Diagrama de estados
Utiliza os mesmos diagramas da Diagrama de atividade
viso de projeto 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
VISO DE IMPLEMENTAO VISO DE PROJETO

Diagrama de componentes Diagrama de classes
Diagrama de estado Diagrama de objetos
Diagrama de atividades Diagrama de estados
Diagrama de sequncia Diagrama de atividade
Diagrama de colaborao Diagrama de sequncia
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.
A escolha de alguma dessas
ferramentas fundamental para
que voc continue seus estudos.
Como a UML utiliza-se de uma notao grfica, uma
boa ferramenta agiliza o processo de construo e
recuperao da informao.
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 EclipseUML 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 vice-
versa.
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.
Na midiateca voc tambm
encontra documentao
A partir da prxima unidade, voc vai iniciar a confeco de
sobre algumas das
diagramas, sendo necessrio o uso de uma ferramenta. Todas as ferramentas.
ferramentas apresentam, nas respectivas pginas de download,
tutoriais e manuais de instalao e utilizao.
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.

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
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.
b) ( ) Na anlise orientada a objetos, dados e mtodos so
vistos como uma entidade nica, preocupando-se com
propriedades e comportamentos do objeto.
c) ( ) A anlise estruturada possui como fundamento a viso do
comportamento do processo. Assim, a viso que se impe ao
modelo o processamento dos dados.
d) ( ) A anlise orientada a objetos construda a partir de objetos.
As classes so instncias do objeto.
2) Identifique os elementos a seguir com C para classe e O para objetos.
a) ( ) Caixa
b) ( ) Imposto pago
c) ( ) Joo da Silva
d) ( ) Valor Venda
e) ( ) 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
Descreve a funcionalidade do sistema desempenhada pelos

a) ( )
usurios.
A viso representada por meio dos diagramas de classe,

b) ( ) de objetos, de estados, de atividade, de sequncia e de
colaborao.
Corresponde distribuio fsica do sistema em seus

c) ( )
subsistemas e a conexo entre essas partes.
Abrange o gerenciamento de verses do sistema,

d) ( ) construdas por meio do agrupamento de mdulos e
subsistemas.
A viso representada por meio dos diagramas de casos de

e) ( )
uso, de estados, de atividade, de sequncia e de colaborao.
Enfatiza as caractersticas da concorrncia, sincronizao e

f) ( )
desempenho do sistema.
So enfatizadas as caractersticas do sistema que do

g) ( )
suporte estrutural e comportamental.
Saiba mais

poder pesquisar em:
GILLEANES, T. A. Guedes. UML: uma abordagem prtica.

So Paulo: Novatec, 2004.
108
5
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 O que so casos de uso?
Seo 2 Como identificar os atores?
Seo 3 Relacionamentos entre casos de uso e atores
Seo 4 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 gerenciar gerenciar

cliente locaes filmes
Figura 5.1 Casos de uso de uma videolocadora

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

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.
Atendente
Gerente
Os possveis atores so:
o atendente;
o gerente;
o cliente. Cliente
Figura 5.4 Diagrama de atores da videolocadora

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

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.
gerenciar
cliente
filmes atendente
Figura 5.5 Exemplo de relacionamento de comunicao

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
Realizar cobrana
Figura 5.6 Diagrama de casos de uso da videolocadora

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 inserir

cliente <<extend>> preferncias
Figura 5.7 Relacionamento de extenso

Unidade 5 119
O diagrama geral de casos de uso atualizado seria ento:
cd locadora
Gerenciar filmes
Atendente
Inserir
Preferncias
extend
Gerenciar cliente
Cliente
Gerenciar
Locaes
Gerente
Gerenciar
Relatrios
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

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.
Unidade 5 121
Figura 5.10 Herana entre casos de uso

O diagrama geral de casos de uso atualizado seria ento:
cd locadora
Gerenciar filmes
Atendente
Inserir
Preferncias
extend
Gerenciar cliente
Cliente
Gerenciar
Locaes
Gerente
Gerenciar
Relatrios
Realizar cobrana
Realizar cobrana
pessoalmente Realizar cobrana
telefone
Figura 5.11 Diagrama de casos de uso de videolocadora

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
Atendente
Inserir
Preferncias
extend
Gerenciar cliente
include
Cliente
include
Autenticao Gerenciar
include Locaes
include
Gerente
Gerenciar
include 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

O sistema deve permitir a atualizao dos dados

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
Realizar saque
cliente
include
Realizar extrato Validao Conta

include
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

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 Descrio
O nome do caso de uso deve ser o mesmo nome que consta no

Nome diagrama. No esquea de que o nome de um caso de uso deve ser
nico.
Conveno numrica utilizada para identificar o caso de uso.
Identificador Exemplo: CSU002, CSU001.
Descrio Descrio sucinta do caso de uso.
Ator Primrio O nome do ator que o responsvel pelo incio do caso de uso.
Ator Secundrio Outros atores que fazem parte do caso de uso.
A precondio indica as condies necessrios no sistema para que o

Precondio 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

Fluxo Principal 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

Fluxo alternativa. O fluxo alternativo descreve um comportamento alternativo
Alternativo para o fluxo principal.
Voc deve descrever aqui o estado do sistema aps a execuo do caso

Ps-condio de uso.
Regras de Condies ou restries na execuo do caso de uso.

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
realizar <<include>> validar

saldo conta
cliente
Nome Realizar saldo
Identificador CSU001
Descrio O cliente do banco solicita a emisso do saldo de sua conta corrente.
Ator Primrio Cliente
Precondio Conta e senha do cliente serem vlidas.
1. o cliente informa a conta e agencia
2. o cliente informa a senha
Fluxo Principal 3. o sistema exibe a lista de servios do caixa eletrnico
4. o cliente seleciona a opo saldo
5. o sistema apresenta mensagem informando a emisso do saldo
Fluxo Alternativo 1. O cliente cancela a operao por teclado finalizando o caso de uso
Ps-condio Saldo do cliente impresso
Regras de negcio RN01
Quadro 5.3 - Exemplo de documentao do caso de uso realizar saldo

include
realizar saque realizar saque
cliente
Nome Realizar saque
Identificador CSU003
Descrio O cliente do banco solicita saque de sua conta corrente.
Ator Primrio Cliente
Conta e senha do cliente serem vlidas.

Precondio
Haver saldo na conta superior ou igual ao valor solicitado.
1. o cliente informa a conta e agncia

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
Fluxo Principal 6. o cliente digita o valor a ser sacado
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
128
Fluxo Alternativo 1 1. O cliente cancela a operao por teclado finalizando o caso de uso
1. O sistema informa a mensagem Conta e/ou Senha inconsistente

Fluxo Alternativo 2 2. O sistema finaliza a tarefa por senha ou conta inexistente
1. O sistema informa a mensagem Saldo Insuficiente para Saque
Fluxo Alternativo 3
2. O sistema finaliza a tarefa por saldo insuficiente
Ps-condio Cdulas disponibilizadas
R. Negcio RN02
Quadro 5.4 - Exemplo de documentao do caso de uso realizar saque

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 Descrio da regra de negcio

RN01 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.
RN02 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.
Quadro 5.5 Exemplo de documentao das regras de negcio

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 Se voc no preencheu o documento de anlise do
que oferece uma abordagem problema e especificao de requisitos liste os requisitos
baseada em disciplinas funcionais e no funcionais.
possibilitando a atribuio de
tarefas e responsabilidades no Documente o ator (lembra da tabela 5.1?)
desenvolvimento de software
(SOUZA; BRAGA, 2004).
Insira o diagrama de casos de uso gerais do projeto.
Iconix - O ICONIX um processo
simplificado que unifica conjuntos Uma tabela de documentao do caso de uso (tabelas 5.3
de mtodos de orientao a objetos
e 5.4) para cada caso de uso.
em uma abordagem completa,
com o objetivo de dar cobertura ao
ciclo de vida do desenvolvimento Documente as regras de negcio (tabela 5.5).
de software (ROSENBERG; SCOTT,
1999).
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
Atualizaes
+ Pedidos Cancelados
+ Cadastro de Clientes
+ Pedidos em Aberto
+ 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

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 RF002
Permitir o cadastro de corretores que vendem imveis para a imobiliria.
Cadastro de fiador RF003

Cadastro dos fiadores usados pelos clientes permitindo incluir, alterar, excluir seus dados.
Cadastro de imveis RF004
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
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 RF007
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
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 RF012
Deve ser permitido o registro do pagamento de aluguel de um imvel.
Gerar relatrio RF013
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 Descrio
RN01 O cliente deve ter fiador para contratar aluguel
RN02 CPF do cliente e fiador devem ser vlidos.
RN03 O imvel deve ser aprovado pelo gerente antes de ser cadastrado.
O crdito do cliente deve ser aprovado pelo gerente antes de efetivar o

RN04 contrato de aluguel.
O valor da taxa do boleto, cobrada pelo banco, adicionado no valor

RN05 total do boleto do locador.
A multa por atraso no pagamento do aluguel de 0,1% do valor do

RN06 aluguel por dia de atraso.
O pagamento do boleto aps o vencimento s pode ser efetivado em

RN07 estabelecimento bancrio conveniado imobiliria.
As manutenes ou reformas feitas pelo locatrio no imvel so por

RN08 conta prpria, ou seja, no sero abatidas no valor da mensalidade.
Quadro 5.6 - Regras de negcio do sistema imobilirio

No sistema imobilirio foram identificados quatro atores:
ud Atores
Secretria Corretor Gerente Cliente
Figura 5.15 Atores do sistema imobilirio

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
Gerenciamento Administrao
+ Alugar Imvel
+ Cadastrar Corretor + Buscar imvel
+ Cadastrar Cliente
+ Cadastrar Usurios do Sistema + Cadastro de manuteno
+ Cadastrar de Fiador
+ Efetuar Login + Efetua Pagamento na imobiliria
+ Cadastrar Imvel
+ Gerar relatrio de comisses + Efetuar Pagamento
+ Gerar Contrato
+ Gerar Relatrio de vendas/aluguis + Envia confirmao de pagamento
+ Gerar Contrato de Aluguel
+ Verifica se j existe Usurio + Gerar Boleto Bancrio
+ Gerar Contrato de Venda
+ Gerar Recibo
+ Validar CPF
+ Gerar relatrio de aluguis pendentes
+ Vender Imvel
+ Pagar Boleto no Banco
+ Registrar Pagamento
Figura 5.16 Pacotes de casos de uso do sistema imobilirio

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
Gerar relatrio de Efetuar Login
(from Atores)
comisses include
include
Gerar Relatrio de
v endas/aluguis
Figura 5.17 Diagrama de casos de uso do pacote gerenciamento

136
ud Negociar Imv el
Cadastrar Cliente
include
Validar CPF
include
Cadastrar de
Fiador
include Gerar Contrato de

Aluguel
Cadastrar Imv el
include
Corretor
extend
(from Atores)
include
Alugar Imv el
include Efetuar Login
include (from Gerenciamento)
Vender Imv el
extend
Gerar Contrato de
Venda
Figura 5.18 Diagrama de casos de uso do pacote negociar imvel

Definidos os diagramas voc vai documentar cada caso de uso,

como os exemplos apresentados a seguir:
Unidade 5 137
include
Cadastrar de Fiador Validar CPF
Corretor
(from Atores)
Nome Cadastrar Fiador
Identificador CSU02
Descrio O corretor cadastra as informaes inerentes ao fiador de um cliente.
Ator Primrio Corretor
Precondio Corretor logado no sistema
1. Corretor digita dados do fiador no sistema.

3. Corretor Confirma cadastro.
Fluxo Principal
4. Executa Validar CPF.
5. Dados do Fiador so armazenados.
1. Corretor seleciona boto Cancelar.

Fluxo Alternativo 1
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.

2. Corretor seleciona um fiador cadastrado.
Fluxo Alternativo 3
3. Seleciona boto Excluso.
4. Dados do fiador so excludos do banco de dados.
Ps-condio Dados do fiador atualizados
Regras de Negcio RN02
Figura 5.19 - Documentao do caso de uso cadastrar fiador

138
Cadastrar Imvel
Corretor
(from Atores)
Nome Cadastrar Imvel
Identificador CSU04
Efetua o cadastro do imvel que ficar disponvel na
Descrio imobiliria.
Ator Primrio Corretor
Corretor logado no sistema e o Proprietrio do imvel precisa

Precondio 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.
1. Corretor seleciona boto Cancelar.

Fluxo Alternativo 1 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.
Fluxo Alternativo 2
11. Corretor altera informao
12. Corretor confirma a alterao
13. Dados do Imvel so armazenados
5. Corretor deseja excluir imvel.

6. Corretor seleciona um imvel cadastrado.
Fluxo Alternativo 3
1. Seleciona boto Excluso.
2. Dados do imvel so excludos do banco de dados.
Ps-condio Imvel atualizado no banco de dados.
Regras de Negcio RN03
Figura 5.20 - Documentao do caso de uso cadastrar imvel


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) ( ) Um caso de uso procura apoiar a especificao de detalhes
necessrios implementao do sistema.
b) ( ) O caso de uso documenta as aes necessrias,
comportamentos e sequncias visando atender as
necessidades do usurio.
c) ( ) Em um caso de uso so necessrios trs elementos bsicos: o

caso de uso, a classe de controle e o ator.
d) ( ) O ator de um caso de uso representa apenas os usurios do

sistema.
140
2) Classifique as questes em Verdadeira (V) ou Falsa (F).

a) ( ) Um ator pode ser representado por um organizao ou
mesmo um equipamento de hardware.
b) ( ) 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.
c) ( ) A relao existente entre um caso de uso e um ator pode ser

uma relao de comunicao ou uma relao de extenso.
d) ( ) A relao existente entre dois atores pode ser somente uma

relao de herana.
e) ( ) A relao existente entre dois casos de uso pode ser de

extenso, incluso e comunicao.
f) ( ) A relao existente entre dois casos de uso pode ser de

extenso, incluso e herana.
3) Relacione a primeira com a segunda coluna.
A. Regras de negcio ( ) DVDs em atraso pagam o valor da

locao dos dias atrasados
B. Ator
( ) Atendente
C. Cenrio
( ) A reserva de um DVD pode ser
D. Caso de uso
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

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
6
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 O que so objetos e classes de objetos?
Seo 2 Quais so as responsabilidades das classes?
Seo 3 Como ocorrem os relacionamentos entre objetos?
Seo 4 Como ocorre a diviso das classes do modelo de

anlise?
Seo 5 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
Voc pode dizer tambm que um objeto uma pessoa, um lugar

ou um sistema, como mostra a figura a seguir.
Os objetos tambm so chamados
de instncia.
Figura 6.1 Exemplos de objetos

O que so classes?
Segundo Furlan (1998), classe a representao de um conjunto

de coisas reais ou abstratas que so reconhecidas como sendo
Um objeto sempre uma instncia
de uma classe. Quando voc fala de
do mesmo tipo por compartilhar as mesmas caractersticas de
uma classe, est falando tambm de atributos, operaes, relaes e semntica.
seus objetos.
Booch (2000) define classe como um conjunto de objetos que
compartilham estrutura e comportamento comuns.
Figura 6.2 Classe Clientes

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

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

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 Locao Item_Locao

- Cdigo: int
- Endereo: char - Data_Devoluo: date
- Nome: char - Data_Locao: date
- Telefone: int - Valor: float
Filmes
Cpias
- Ator_Principal1: char
- Ator_Principal2: char - Data_Compra: date
- Cdigo: int - Nmero: int
- Diretor: char - Status: int
- Durao: int
- Estilo: char
- Idioma: char
- Ttulo: char
Figura 6.5 Possveis classes do sistema de videolocadora

A notao de classes apresenta trs compartimentos, porm as

classes podem ser apresentadas em diferentes nveis de abstrao,
como apresentado na seguinte figura.
Cliente
Cliente
Cdigo Cdigo
Nome Nome
Cliente Endereo Endereo
CGC CGC
Limite_Crdito Limite_Crdito
Calcular_Limite( )
Emitir_Relatrio( )
Figura 6.6 Abstraes das classes

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
na segunda etapa, cada participante associado a

uma classe. Assim, cada pessoa passa a pertencer
quela classe e todo o cenrio ser encenado pelos
Para cada classe de objeto
identificada dentro do cenrio,
participantes. Aos poucos cada carto preenchido com
criado um carto CRC. 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 Colaboraes
Inserir/excluir item de venda Item de venda
Editar item de venda Estoque
Totalizar venda Mercadoria
Calcular impostos Mercadoria
Quadro 6.1 - Exemplo de um carto CRC

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 Anlise

Abertura Operao
Venda Provvel classe
Item vendido Provvel classe melhor item de venda
Cdigo do produto Atributo do item da venda
Quantidade Atributo do item da venda
Cliente da mercearia Entidade fora do escopo do produto
Ticket Relatrio
Forma de pagamento Atributo da venda
Baixa Operao
Estoque Possvel classe
Mercadoria Possvel classe
Quadro 6.2 Exemplo lista de classes

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

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

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 Simbologia
Apenas um 1
Zero ou muitos 0..*
Um ou muitos 1..*
Zero ou um 0..1
Intervalo especfico 1i..1s
Quadro 6.3 Simbologia UML

Veja alguns exemplos de multiplicidade:
160
Um paciente possui nenhum ou vrios agendamentos.
Paciente Agenda
Em uma empresa
Paciente de transporte, Agenda
um motorista dirige
apenas um caminho, e cada caminho pode ser dirigido
por apenas um motorista.
Paciente Agenda
No terceiro exemplo,
1..*um funcionrio
1,..* deve estar locado a
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.
Solicita
Paciente Agenda
Figura 6.11 Nomeando uma associao

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

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

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

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

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

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 Apartamento
- num_andares: int - fundo_reserva: float

- Tipo_Construo: char - 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

Unidade 6 169
Agora, relembrando o sistema da videolocadora, observe os

relacionamentos entre as classes candidatas propostas:
cd Data Model
Cliente
- Bairro: char Locao

- Cdigo: int Faz
- Data_Devoluo: date
- Endereo: char
1..* - Data_Locao: date
- Nome: char
- Valor: float
- Telefone: int
1..*
Contm
Item_Locao
0..*
Compe
Filmes
- Ator_Principal1: char
- Ator_Principal2: char Cpias
- Cdigo: int Possuem
- Diretor: char - Data_Compra: date
1..* - Nmero: int
- Durao: int
- Estilo: char - Status: int
- Idioma: char
- Ttulo: char
Figura 6.19 Diagrama de classes sistema videolocadora

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
O sistema deve permitir ao cliente a emisso de
extrato somente da conta corrente.
O sistema deve permitir a atualizao dos dados
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 Conta
Mov imento
- endereo: char - Agncia: int
- estado_civil: int tem - Data_Abertura: date registra - data_mov: date
-
0..* -
nome: char histrico: int
1..* - Nmero: int
- rendimento: double - Saldo: double - nro_conta: int
- telefone: char - Senha: int - valor: double
- tippes: boolean - Tipo: int
Fsica Jurdica Conta_Corrente

Poupana
- CID: char - CNPJ: long - limite: double
- CPF: long - Nro_sorteio: int
- Nro_ext_mes: int
- Rendimento: double
- Nro_saques_mes: int
- TxJuro: float
Figura 6.20 Diagrama de classes sistema caixa eletrnico

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
As classes de controle atuam entre
as classes de interface e as de
representam a lgica do caso de uso, requisitam e consultam
negcio, isto , uma para cada caso informaes das classes de entidade e de interface e no
de uso. gerenciam dados nem tm sada visvel.
Bezerra (2002) define algumas responsabilidades para as classes

de controle:
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
Lembre-se de que os casos
comportar a lgica e as regras de negcio complexas. Isso de uso complexo devem
significa que aes como incluso, alterao, consultas de ser escritos em classes de
cadastros podem tranquilamente ser implementadas em uma Controle.
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.
A representao das classes na UML se d pela seguinte notao:
Figura 6.22 Esteretipos da classe

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

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
Quando fazer uso desse diagrama? Esse diagrama pode ser

bastante til quando voc estiver modelando uma estrutura de
Em alguns livros, voc vai encontrar
o nome diagrama de instncias
dados complexa.
como sinnimo de diagrama de
objetos. 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

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

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.
b) ( ) Uma classe um conjunto de objetos que compartilham
caractersticas de atributos, operaes, relaes e semntica.
c) ( ) possvel dizer que so exemplos de classes em um sistema

Universitrio: Professor, Aluno, Nome Aluno.
d) ( ) possvel dizer que so exemplos de instncias de uma

classe Professor: Joo da Silva, Ana Luiza.
2) Relacione a primeira coluna com a segunda, indicando a camada mais

adequada para cada ocorrncia.
A. Classe de Ccontrole ( ) Mensagens de erro para o usurio.

B. Classe Persistente ( ) Clculo da folha de pagamento.
C. Classe de Fronteira ( ) 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 a) ( ) As classes esto ligadas a associaes
e no a outras classes.
B. Associao ternria
b) ( ) Neste relacionamento, ocorre a
C. Agregao associao de trs classes ao mesmo
D. Herana tempo.
E. Dependncia c) ( ) Uma das classes do relacionamento

uma parte da classe ou est contida
F. Associao em outra classe.
recursiva d) ( ) Este relacionamento possvel entre
dois ou mais elementos em que
G. Classes associativas 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

servio.
Histrico:
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.
cadastro inicial do paciente, que contm nome, endereo, telefone,
data de nascimento, convnio.
convnio e particular, mdicos mais procurados e picos de
movimento.
184
Unidade 6 185
Saiba mais

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
7
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 Quais so os elementos do modelo de interao?
Seo 2 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

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

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

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

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
Para construir um diagrama de
sequncia, necessria a prvia
condies devem ser satisfeitas e quais mtodos devem ocorrer
definio do diagrama de classes entre os objetos envolvidos e sua ordem durante a execuo do
com a indicao das operaes processo (GUEDES, 2006).
associadas.
A descrio sempre uma interao O diagrama de sequncia descreve o comportamento interno,
dentro de uma unidade de tempo. mostrando os eventos entre objetos, mas omite a associao entre
ideal para a especifi-cao de esses objetos.
processos que ocorrem em tempo
real.
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.
194
Figura 7.5 Elementos grficos do diagrama de sequncia

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

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

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 tem-
se 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.

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 a) ( ) So as linhas horizontais com flechas

que ligam uma linha de vida a outra.
2. Mensagem
b) ( ) Objetos so destrudos durante uma
3. New colaborao.
4. Destroyed c) ( ) Os objetos aparecem no topo de uma
linha vertical tracejada.
5. Transient
d) ( ) 1:[preo < 10,00]:Venda aVista
6. Linhas de vida (produto).
7. Clusula interao e) ( ) Utilizado para mensagens sncronas.
8. Call f) ( ) Objetos so criados e destrudos
durante uma colaborao.
9. Send
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) ( ) Prope a troca de mensagens entre atores.
b) ( ) Mensagens so trocadas entre um conjunto de objetos
em um determinado contexto para a realizao de um
propsito.
c) ( ) Pode ser definida como uma solicitao de execuo de uma
operao em outro objeto.
d) ( ) 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.
Saiba mais
Caso voc tenha interesse em aprofundar seus estudos sobre os

assuntos tratados nesta unidade, consulte:

UML. So Paulo: Campus, 2002. (Ler captulo 7.)
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia

204
8
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 Modelo de estados
Seo 2 Modelo de atividades
Seo 3 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

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

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

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

Figura 8.5 Exemplo DTE

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

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

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
Senha Vlida? No
Informa erro
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

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
Dados Aprovados?
Avisa Cliente da Negativa
Sim
Secionar Imvel
Insere dados do aluguel
Contrato
Imprime Contrato
Final
Figura 8.11 - Diagrama Gerar Contrato de Aluguel do Sistema Imobilirio

218
Lembre-se, utilize o diagrama de atividade:

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

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 a) ( ) utilizado em um DA para indicar uma
bifurcao.
B) Estado inicial
b) ( ) Ocorre quando o objeto criado.
C) When
c) ( ) Utilizado para designar a paassagem de um
D) Transient perodo predeterminado de tempo.
E) Join 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.

servio.
Histrico:
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.
marcadas as consultas. Na marcao da consulta colocado o nome
do paciente, horrio e convnio. Trabalham h 3 anos na clnica com
planilhas Excel.
cadastro inicial do paciente, que contm nome, endereo, telefone,
data de nascimento, convnio.
convnio e particular, mdicos mais procurados e picos de movimento.
222
Unidade 8 223
Saiba mais

poder pesquisar em:

UML. So Paulo: Campus, 2002. (Ler captulos 10 e 11.)
BOOCH, G.; RUMBAUGH, J.; JACOBSON, I. UML: guia

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
9
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 Aonde se quer chegar?
Seo 2 Quais so as fases do RUP?
Seo 3 Quais so os elementos do RUP?
Seo 4 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
O processo define: quem
neste caso a entrega eficiente e previsvel de um produto de est fazendo o qu,
software que atenda, de forma completa, todas as necessidades do quando e como est
usurio. sendo feito e as aes para
atingir uma determinada
Mas como inserir qualidade no processo? A qualidade passa pelo meta.
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.
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 Unified
Language 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
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 Unified
e quando faz-las. Alm disso, tambm prov uma Process
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?
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.
O RUP foi desenvolvido para ser aplicvel a qualquer tipo de

projeto. Na literatura, assumido como um framework genrico
Voc pode encontrar esse padro
no site do Rational Software
para processos de desenvolvimento.
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.
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.

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 tem-

se 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
D. Gerncia de projeto envolvidos.
E. Gerncia de c) ( ) Descreve as diferentes vises do

configurao e sistema.
mudanas 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.
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 object-
oriented 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
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
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: Addison-
Wesley, 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.
marcadas as consultas. Na marcao da consulta colocado o nome do
paciente, horrio e convnio.
cadastro inicial do paciente que contm nome, endereo, telefone, data
de nascimento, convnio.
256

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 disciplina
(0,n) (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
a) A
b) B
c) D
d) C
e) A
f) E
g) B
Unidade 5
1) A afirmativa correta : (b).
a) V
b) F
c) F
d) V
e) F
f) V
a) A
b) B
c) C
d) D
e) B
260
f) D
g) A
4) A definio dos requisitos funcionais:
RF01 O sistema deve permitir o gerenciamento de funcionrios e seus dados cadastrais
RF02 O sistema deve controlar o sistema de acesso de acordo com as permisses de cada ator.
RF03 Deve ser possvel realizar o gerenciamento de horrio dos funcionrios.
O sistema deve possibilitar o lanamento de horrios de consulta por meio de uma

RF04 agenda mdica.
RF05 Deve ser possvel a consulta de horrios marcados por mdico, por data.
RF06 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
RF07 clnica opera.
RF08 necessrio que o sistema oferea relatrios estatsticos de atendimento por convnio.
necessrio que o sistema emita relatrios estatsticos de atendimento por rea de

RF09 especializao.
A definio dos atores:
Ator Descrio Responsabilidade
Todos os 34 mdicos possuem especializao,

todos possuem conhecimentos bsicos de
informtica e noo do funcionamento e
Mdicos Gerenciamento de paciente.
procedimentos da clnica. A faixa etria se
encontra entre 30 e 48 anos. Nenhum mdico
possui qualquer deficincia fsica.
Gerenciamento de horrio dos

As 2 atendentes possuem o segundo grau funcionrios.
completo, razovel experincia em informtica Gerenciamento de agenda mdica.
Atendente e conhecimento do processo de funcionamento Permitir consulta de horrios
da clnica. As atendentes esto na clnica h marcados por mdico, por data.
aproximadamente 3 anos. Gerenciamento de paciente
(cadastro).
Pacientes com faixa etria at 14 anos, sob Gerenciamento de agenda mdica

Paciente custdiaa e agendamento dos pais. (marcar consulta).
Mdico especialista possui conhecimentos

bsicos de informtica e noo do
Gerente funcionamento e procedimentos da clnica. Acesso a todas as funcionalidades.
Possui 42 anos no apresenta nenhuma
deficincia fsica.
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
CSU 002 Paciente
extend
Atendente Agendar
horrio
Gerenciamento do cadastro de dados pessoais e horrios

Breve descrio de trabalho de funcionrios da clnica.
Ator primrio Gerente
Ator secundrio Funcionrio
Precondies 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;
Fluxo principal 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;
Fluxo alternativo e excees
1.2
So apresentadas as possibilidades de alterar, excluir ou
finalizar.
Ps-condies Dados do funcionrio armazenados.
RF01 O sistema deve permitir o gerenciamento de

Requisito funcional funcionrios e seus dados cadastrais.
RN01 O funcionrio do tipo mdico s pode ser excludo

Regras de negcio se no houver nenhuma consulta agendada.
262
Caso de uso: CSU002 Agendamento de Horrio

CSU 005
Gerenciar
Ficha Cadastral
CSU 002 Paciente
extend
Atendente Agendar
horrio
Breve descrio O caso de uso permite o agendamento do horrio de consulta do paciente.
Ator primrio Atendente
Ator secundrio Paciente
- O atendente estar devidamente logado no sistema;

Precondies
- 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.
Fluxo principal 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.
Fluxo alternativo
e excees 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.
Ps-condies Consulta marcada.
Requisito RF04 O sistema deve possibilitar o lanamento de horrios de consulta por

funcional meio de uma agenda mdica.
RN02 se o tipo de consulta for retorno, agendar somente 10 minutos na

Regras de negcio agenda. Se for consulta normal, agendar 20 minutos.
263
Caso de uso: CSU003 Cadastro de Convnios
Breve descrio Neste caso ocorre o gerenciamento dos convnios.
Ator primrio Gerente
Ator secundrio
Precondies O gerente deve estar devidamente logado no sistema.
1. O gerente solicita uma incluso de convnio.,

2. Informado o nome do convnio.
Fluxo principal 3. O sistema informa o cdigo interno do convnio.
4. So informados dados cadastrais do convnio.
5. Os dados so armazenados.
No item 2, caso o nome j exista. Nesse caso:

Fluxo alternativo e so apresentados os dados cadastrais do funcionrio;
excees
so apresentadas as possibilidades de alterar, excluir ou finalizar.
Ps-condies Consulta marcada.
RF07 Deve ser possvel incluir novos convnios ou mesmo excluir

Requisito funcional convnios com os quais a clnica opera.
Regras de negcio
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
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 Bem-

Estar 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.

Metodologias e Projetos de Software PDF

Загружено:

Сведения о документе

Оригинальное название

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Metodologias e Projetos de Software PDF

Загружено:

Авторское право:

Доступные форматы

Universidade do Sul de Santa Catarina

Edio Livro Didtico

Projeto Grfico e Capa

1. Mtodos orientado a objetos (Computao). 2. UML (Computao). 3.

Ficha catalogrfica elaborada pela Biblioteca Universitria da Unisul

UNIDADE 1 - Ciclos de vida de um processo de desenvolvimento de

Para concluir o estudo. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247

Este livro didtico corresponde disciplina Metodologias e

O material foi elaborado visando a uma aprendizagem autnoma

Lembre-se que sua caminhada, nesta disciplina, ser

Ento, sempre que sentir necessidade entre em contato; voc tem

Bom estudo e sucesso!

A disciplina Metodologias e Projetos de Software vai inseri-

O caminho da modelagem tem sido rduo atravs dos anos,

A comunidade de desenvolvimento percebe a necessidade cada

Este um dos contextos mais relevantes da modelagem: ela

A modelagem pode ser comparada ao projeto de uma grande

Acho que voc concorda comigo: nesse caso, nem pensaria

Ento, convencido/a da importncia do estudo desta disciplina?

Professora Vera Schuhmacher

O plano de estudos visa a orient-lo no desenvolvimento da

O processo de ensino e aprendizagem na UnisulVirtual leva

So elementos desse processo:

o Espao UnisulVirtual de Aprendizagem (EVA);

as atividades de avaliao (a distncia, presenciais e de

Sensibilizar o/a aluno/a sobre a importncia do uso

Tornar presente a discusso sobre a relevncia de se

Oferecer ao/ aluno/a o arsenal didtico necessrio para

Capacitar o/a aluno/a a utilizar metodologias orientadas

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

Unidade 2 - Engenharia de requisitos

Unidade 3 - Anlise estruturada

Unidade 4 - Viso geral da UML

Unidade 5 - Modelagem de casos de uso

Unidade 6 - Modelagem de classes

Unidade 7 - Modelos de interaes

Unidade 8 - Modelos de estados

Unidade 9 - RUP e ICONIX

Verifique com ateno o EVA, organize-se para acessar

No perca os prazos das atividades. Registre no espao

Use o quadro para agendar e programar as atividades

Demais atividades (registro pessoal)

Ciclos de vida de um processo

Perceber as diversas etapas do processo de

Definir essas etapas dentro de um modelo de

Seo 2 Quais so as etapas do processo de

Seo 3 Modelo de desenvolvimento de software

Para incio de estudo

preciso entender claramente o que cobrar e como deve ser

Nesta unidade, voc vai perceber que todo o processo de

Vamos iniciar esta jornada metodolgica? Bom estudo!

Seo 1 Quais so as caractersticas do software?

Ainda que informalmente se tenha uma ideia bsica do

Ser que voc sabe realmente o que significa software?

Explicar esse conceito no simples, depende da tica pela qual

Voc poderia dizer que software o conjunto de instrues

Poderia conceituar software como estruturas de dados que

possvel dizer, ainda, que softwares so os documentos que

Todavia, possvel ser redundante e dizer que softwares so

Conceituar software passa por conhecer suas caractersticas.

O software apresenta caractersticas nicas. Ele no se

Mas o que isso?

Imagine que voc compre uma Ferrari novinha!!! Agora, imagine