Analise Projeto Sistemas Mail

e-Tec Brasil/CEMF/Unimontes
Escola Tcnica Aberta do Brasil

Informtica
Anlise e Projeto
de Sistemas
Nilton Alves Maia
Snia Beatriz de Oliveira e Silva Maia

Ministrio da
Educao
Informtica
Anlise e Projeto
de Sistemas
Nilton Alves Maia
Montes Claros - MG
2011
Ministro da Educao
Fernando Haddad
Secretrio de Educao a Distncia
Carlos Eduardo Bielschowsky
Coordenadora Geral do e-Tec Brasil
Iracy de Almeida Gallo Ritzmann
Governador do Estado de Minas Gerais
Antnio Augusto Junho Anastasia
Secretrio de Estado de Cincia, Tecnologia
e Ensino Superior
Alberto Duque Portugal
Reitor
Joo dos Reis Canela
Vice-Reitora
Maria Ivete Soares de Almeida
Pr-Reitora de Ensino
Anette Marlia Pereira
Diretor de Documentao e Informaes
Huagner Cardoso da Silva
Coordenador do Ensino Profssionalizante
Edson Crisstomo dos Santos
Diretor do Centro de Educao Profssonal e
Tecnlogica - CEPT
Masa Tavares de Souza Leite
Diretor do Centro de Educao Distncia
- CEAD
Jnio Marques Dias
Coordenadora do e-Tec Brasil/Unimontes
Rita Tavares de Mello
Coordenadora Adjunta do e-Tec Brasil/
CEMF/Unimontes
Eliana Soares Barbosa Santos
Coordenadores de Cursos:
Coordenador do Curso Tcnico em
Agronegcio
Augusto Guilherme Dias

Coordenador do Curso Tcnico em Comrcio
Carlos Alberto Meira

Coordenador do Curso Tcnico em Meio
Ambiente
Edna Helenice Almeida
Coordenador do Curso Tcnico em
Informtica
Frederico Bida de Oliveira
Coordenadora do Curso Tcnico em
Vigilncia em Sade
Simria de Jesus Soares
Coordenadora do Curso Tcnico em Gesto
em Sade
Zaida ngela Marinho de Paiva Crispim
ANLISE E PROJETO DE SISTEMAS
Elaborao
Nilton Alves Maia
Projeto Grfco
e-Tec/MEC
Superviso
Wendell Brito Mineiro
Diagramao
Hugo Daniel Duarte Silva
Marcos Aurlio de Almeida e Maia
Impresso e Acabamento
Grfca RB Digital
Designer Instrucional
Anglica de Souza Coimbra Franco
Ktia Vanelli Leonardo Guedes Oliveira
Reviso
Maria Ieda Almeida Muniz
Patrcia Goulart Tondineli
Rita de Cssia Silva Dionsio
Presidncia da Repblica Federativa do Brasil
Ministrio da Educao
Secretaria de Educao a Distncia
e-Tec Brasil/CEMF/Unimontes Anlise e Projetos de Sistemas
AULA 1
Alfabetizao Digital
3
Prezado estudante,
Bem-vindo ao e-Tec Brasil/Unimontes!
Voc faz parte de uma rede nacional pblica de ensino, a Escola
Tcnica Aberta do Brasil, instituda pelo Decreto n 6.301, de 12 de dezem-
bro 2007, com o objetivo de democratizar o acesso ao ensino tcnico pblico,
na modalidade a distncia. O programa resultado de uma parceria entre
o Ministrio da Educao, por meio das Secretarias de Educao a Distancia
(SEED) e de Educao Profssional e Tecnolgica (SETEC), as universidades e
escola tcnicas estaduais e federais.
A educao a distncia no nosso pas, de dimenses continentais e
grande diversidade regional e cultural, longe de distanciar, aproxima as pes-
soas ao garantir acesso educao de qualidade, e promover o fortalecimen-
to da formao de jovens moradores de regies distantes, geografcamente
ou economicamente, dos grandes centros.
O e-Tec Brasil/Unimontes leva os cursos tcnicos a locais distantes
das instituies de ensino e para a periferia das grandes cidades, incenti-
vando os jovens a concluir o ensino mdio. Os cursos so ofertados pelas
instituies pblicas de ensino e o atendimento ao estudante realizado em
escolas-polo integrantes das redes pblicas municipais e estaduais.
O Ministrio da Educao, as instituies pblicas de ensino tc-
nico, seus servidores tcnicos e professores acreditam que uma educao
profssional qualifcada integradora do ensino mdio e educao tcnica,
no s capaz de promover o cidado com capacidades para produzir, mas
tambm com autonomia diante das diferentes dimenses da realidade: cul-
tural, social, familiar, esportiva, poltica e tica.
Ns acreditamos em voc!
Desejamos sucesso na sua formao profssional!
Ministrio da Educao
Janeiro de 2010
Apresentao e-Tec Brasil/CEMF/
Unimontes
AULA 1
Alfabetizao Digital
5
Indicao de cones
Os cones so elementos grfcos utilizados para ampliar as formas
de linguagem e facilitar a organizao e a leitura hipertextual.
Ateno: indica pontos de maior relevncia no texto.
Saiba mais: oferece novas informaes que enriquecem o assunto ou
curiosidades e notcias recentes relacionadas ao tema estudado.
Glossrio: indica a defnio de um termo, palavra ou expresso utilizada
no texto.
Mdias integradas: possibilita que os estudantes desenvolvam atividades
empregando diferentes mdias: vdeos, flmes, jornais, ambiente AVEA e
outras.
Atividades de aprendizagem: apresenta atividades em diferentes nveis
de aprendizagem para que o estudante possa realiz-las e conferir o seu
domnio do tema estudado.
AULA 1
Alfabetizao Digital
Sumrio
7
Palavra do professor conteudista .............................................9
Projeto instrucional ........................................................... 11
Aula 1 Sistema de informaes ............................................ 13
1.1 Introduo ............................................................ 13
1.2 Conceito de sistema de informaes ............................. 13
Resumo ................................................................... 14
Atividades de aprendizagem ........................................... 14
Aula 2 Modelagem de sistemas de software ............................. 15
2.1 Introduo ........................................................... 15
2.2 Construo de sistemas de software ............................. 15
Resumo ................................................................... 17
Aula 3 O paradigma da orientao a objetos ............................ 19
3.1 Introduo ........................................................... 19
3.2 Classes e objetos .................................................... 21
3.3 Mensagens ........................................................... 21
3.4 Viso geral dos princpios da orientao a objetos ............ 22
Resumo ................................................................... 25
Aula 4 Evoluo histrica da modelagem de sistemas .................. 27
4.1 Introduo ........................................................... 27
4.2 Resumo histrico .................................................... 27
Resumo ................................................................... 28
Aula 5 A linguagem de modelagem unifcada (UML) .................... 29
5.1 Introduo ........................................................... 29
5.2 Em que a UML pode me ajudar? .................................. 30
5.3 Por que a UML uma linguagem?................................. 30
5.4 Que caminho deve ser seguido para aprend-la? ............... 31
5.5 UML e o desenvolvimento de software .......................... 31
Resumo ................................................................... 31
Aula 6 O processo de desenvolvimento de software ................... 33
6.1 Introduo ........................................................... 33
6.2 Atividades tpicas de um processo de desenvolvimento ....... 34
Resumo ................................................................... 39
Aula 7 Modelagem Baseada em UML ...................................... 41
7.1 Introduo ............................................................ 41
7.2 Um breve histrico .................................................. 42
e-Tec Brasil/CEMF/Unimontes Informtica 8
7.3 Diagramas da UML .................................................. 43
7.4 Processo adotado neste caderno .................................. 45
7.5 Casos de uso ......................................................... 46
7.6 Classes ................................................................ 53
7.7 Interaes ............................................................ 65
7.8 Componentes de software ........................................ 77
Resumo ................................................................... 84
Aula 8 Estudo de caso ...................................................... 85
8.1 Introduo ........................................................... 85
Referncias ..................................................................... 86
Currculos dos professores conteudistas ................................... 87
AULA 1
Alfabetizao Digital
9
Bem-vindos caros alunos!
A partir do contedo trabalhado neste caderno, que trata-se da
disciplina Anlise e Projeto de Sistemas, voc aprender a utilizar diversos
recursos para modelagem de sistemas.
Voc aprender sobre a anlise e projeto de sistemas, entender
sobre a caracterizao e aplicao de metodologias e ferramentas de mo-
delagem de sistemas orientados a objetos, aprender sobre aplicaes de
metodologias de desenvolvimento de sistemas de software, ter uma reviso
dos mtodos de desenvolvimento de software, aprender sobre aplicao de
metodologia atravs de experincia prtica de desenvolvimento de softwa-
re, tambm aprender a empregar aspectos fundamentais no processo de
desenvolvimento visando maior qualidade do produto de software.
Ao longo deste material, voc encontrar diversas atividades a se-
rem desenvolvidas durante o decorrer da disciplina. Assim, ao resolv-las,
possvel realizar uma reviso do que foi apresentado e refetir sobre a impor-
tncia do contedo trabalhado e como ele poder ajud-lo em seu cotidiano,
principalmente como aluno de um curso tcnico e futuro profssional.
Este caderno est dividido em oito aulas e seu contedo ser apre-
sentado no encontro presencial deste curso. Como complementao de estu-
do, algumas atividades sero propostas, alm de apresentao de curiosida-
des, destaques para conceitos importantes.
Vamos nos empenhar para aproveitar ao mximo o contedo dessa
disciplina?
Bom trabalho!
Palavra do professor conteudista
AULA 1
Alfabetizao Digital
11
Disciplina: Anlise e Projeto de Sistemas (carga horria: 60h).
Ementa: Introduo anlise e projeto de sistemas. Caracterizao
e aplicao de metodologias e ferramentas de modelagem de sistemas orien-
tados a objetos. Apresentao e aplicao de uma metodologia de desenvol-
vimento de sistemas de software. Reviso dos mtodos de desenvolvimento
de software. Aplicao de metodologia atravs de experincia prtica de
desenvolvimento de software. Empregar aspectos fundamentais no processo
de desenvolvimento visando maior qualidade do produto de software.
AULA OBJETIVOS DE
APRENDIZAGEM
MATERIAIS CARGA
HORRIA
Aula 1.
Sistemas de
informaes
- Conhecer conceitos sobre infor-
mao, sistemas de informao e
sistemas de software.
4h
Aula 2.
Modelagem de
sistemas de
software
- Conhecer as caractersticas de
sistemas de software;
- Entender o conceito de modelo no
desenvolvimento de sistemas;
- Compreender o conceito do prin-
cpio da abstrao;
- Entender a importncia da comu-
nicao entre as pessoas envolvidas
no processo de desenvolvimento de
sistemas.
4h
Aula 3.
O paradigma
da orientao a
objetos
- Conhecer o conceito de paradig-
ma;
- Compreender o conceito de para-
digma da orientao a objetos;
- Conhecer os princpios da orienta-
o a objetos;
- Conhecer o conceito de classes,
objetos, mensagens;
- Conhecer os princpios do paradig-
ma da orientao a objetos.
8h
Aula 4.
Evoluo hist-
rica da modela-
gem de sistemas
- Conhecer o histrico da evoluo
das tcnicas de desenvolvimento de
sistemas.
2h
Projeto instrucional
Aula 5.
A linguagem de
modelagem uni-
fcada UML
- Saber em que a UML pode nos
ajudar;
- Saber por que a UML uma lin-
guagem;
- Conhecer os caminhos que deve-
mos seguir para aprender a UML; e
- Conhecer a UML e o processo de
desenvolvimento de software.
6h
Aula 6.
O processo de
desenvolvimen-
to de software
- Conhecer as atividades tpicas de
um processo de desenvolvimento
de software;
- Compreender a importncia de
cada atividade no decorrer de um
processo de desenvolvimento de
software.
4h
Aula 7.
Modelagem Ba-
seada em UML
- Conhecer um breve histrico da
UML;
- Conhecer os principais diagramas
da UML;
- Saber a identifcar um caso de
uso;
- Aprender a identifcar atores;
- Aprender a desenhar um diagrama
de caso de uso;
- Conhecer os cuidados necessrios
ao se criar diagramas de caso de
uso;
- Aprender a identifcar classes;
- Aprender a identifcar relaciona-
mentos;
- Conhecer extenses e mecanis-
mos;
- Aprender a desenhar diagramas
de classes;
- Conhecer os tipos de diagramas
de interao;
- Conhecer o diagrama de colabo-
rao;
- Conhecer diagramas de sequncia;
de sequncia;
- Aprender sobre os diagramas de
estados e sua funo;
de estados;
- Aprender sobre diagramas de
atividades;
de atividades;
- Conhecer componentes de software;
de componentes;
de implantao.
24h
Aula 8.
Estudo de caso
- Criar um projeto de software
utilizando conhecimentos de orien-
tao a objetos e da linguagem de
modelagem unifcada.
8h
AULA 1
Alfabetizao Digital
13
Aula 1 Sistema de informaes
Objetivos
- Conhecer conceitos sobre informao, sistemas de informao e
sistemas de software.
1.1 Introduo
No decorrer da histria, diversos tipos de bens serviram de base
para o desenvolvimento da economia. Propriedade, mo de obra, mquinas
e capital so exemplos desses bens. Atualmente, est surgindo um novo tipo
de bem econmico: a informao. Dessa forma, a empresa que dispe de
mais informaes sobre seus processos de negcio est em vantagem em
relao a suas competidoras (BEZERRA, 2002).
Em consequuncia do crescimento da importncia da informao,
surgiu a necessidade de gerenciar informaes de uma forma adequada e
efciente e, dessa necessidade, surgiram os denominados sistemas de infor-
maes (BEZERRA, 2002).
1.2 Conceito de sistema de informaes
Um sistema de informaes uma combinao de pessoas, dados,
processos, interfaces, redes de comunicao e tecnologia que interagem
com o objetivo de dar suporte e melhorar o processo de negcio de uma
organizao empresarial com relao s informaes que nela fuem. Consi-
derando o carter estratgico da informao nos dias de hoje, pode-se dizer
tambm que os sistemas de informaes tm o objetivo de prover vantagens
para uma organizao do ponto de vista competitivo (BEZERRA, 2002).
O objetivo principal e fnal da construo de um sistema de infor-
maes a adio de valor empresa ou organizao na qual esse sistema
ser utilizado. O termo adio de valor implica que a produtividade nos
processos da empresa na qual o sistema de informaes ser utilizado deve
aumentar de uma forma signifcativa, de tal forma a compensar os recursos
utilizados na construo do sistema. Para que um sistema de informaes
adicione valor a uma organizao, tal sistema deve ser economicamente jus-
tifcvel (BEZERRA, 2002).
O desenvolvimento de um sistema de informaes uma tarefa
das mais complexas. Um dos seus componentes denominado sistema de
software. Esse componente compreende os mdulos funcionais computado-
rizados que interagem entre si para proporcionar ao(s) usurio(s) do sistema
a automatizao de diversas tarefas (BEZERRA, 2002).
Resumo
Nesta aula, voc aprendeu:
conceitos sobre informao, sistemas de informao e sistemas
de software.
Atividades de aprendizagem
1) Conceitue informao?
2) Qual o conceito de sistemas de informao?
3) Qual o objetivo dos sistemas de informao?
4) Conceitue sistemas de software?
AULA 1
Alfabetizao Digital
15
Aula 2 Modelagem de sistemas de
software
Objetivos
- Conhecer as caractersticas de sistemas de software;
- Entender o conceito de modelo no desenvolvimento de sistemas;
- Compreender o conceito do princpio da abstrao;
- Entender a importncia da comunicao entre as pessoas envolvi-
das no processo de desenvolvimento de sistemas.
2.1 Introduo
Uma caracterstica importante dos sistemas de software a com-
plexidade de seu desenvolvimento. Esta complexidade cresce medida que
cresce o tamanho do sistema. Para se ter uma ideia da complexidade en-
volvida na construo de alguns sistemas, considere o tempo e os recur-
sos materiais necessrios para se construir uma casa de um cachorro. Para
construir essa casa, provavelmente tudo de que se precisa de algumas
ripas de madeira, alguns pregos, uma caixa de ferramentas e certa dose de
amor por seu cachorro. Depois de alguns dias, a casa estaria pronta. O que
dizer da construo de uma casa para sua famlia? Certamente tal emprei-
tada no seria realizada to facilmente. O tempo e os recursos necessrios
seriam uma ou duas ordens de grandeza maiores do que o necessrio para
a construo da casa de cachorro. O que dizer, ento, da construo de um
edifcio? Certamente, para se construir habitaes mais complexas (casas e
edifcios), algum planejamento adicional necessrio. Engenheiros e arqui-
tetos constroem plantas dos diversos elementos da habitao antes do incio
da construo propriamente dita. Na terminologia da construo civil, plan-
tas hidrulicas, eltricas, de fundao, entre outras so projetadas e devem
manter consistncia entre si. Provavelmente, uma equipe de profssionais es-
taria envolvida na construo e aos membros dessa equipe seriam delegadas
diversas tarefas, no tempo adequado para cada uma delas (BEZERRA, 2002).
2.2 Construo de sistemas de software
Na construo de sistemas de software, assim como na construo
de sistemas habitacionais, tambm h um aumento de complexidade. Para
a construo de sistemas de software mais complexos, tambm necessrio
um planejamento inicial anterior. O equivalente ao projeto das plantas da
engenharia civil tambm deve ser realizado. Essa necessidade leva ao con-
ceito de modelo, to importante no desenvolvimento de sistemas. De uma
perspectiva mais ampla, um modelo pode ser visto como uma representao
idealizada de um sistema a ser construdo. Maquetes de edifcios, de avies
e plantas de circuitos eletrnicos so apenas alguns exemplos de modelos.
So vrias as razes para a utilizao de modelos durante a construo de
sistemas (BEZERRA, 2002).
Portanto, a utilizao de modelos durante o processo de construo
de sistemas ocorre em funo dos seguintes motivos:
Gerenciamento da complexidade: uma das principais razes pelas
quais modelos so utilizados que h limitaes no ser humano em lidar
com a complexidade. Pode haver diversos modelos de um mesmo sistema,
cada modelo descrevendo uma perspectiva do sistema a ser construdo. Por
exemplo, um avio pode ter um modelo para representar sua parte eltri-
ca, outro modelo para representar sua parte aerodinmica, etc. Atravs de
modelos de um sistema, os indivduos envolvidos no seu desenvolvimento
podem fazer estudos e predizer comportamentos do sistema em desenvolvi-
mento. Como cada modelo representa uma perspectiva do sistema, detalhes
irrelevantes que podem difcultar o entendimento do sistema podem ser ig-
norados por um momento estudando-se separadamente cada um dos mode-
los. Alm disso, modelos se baseiam no denominado Princpio da Abstrao, o
qual advoga que s as caractersticas relevantes resoluo de um problema
devem ser consideradas. Modelos revelam as caractersticas essenciais de
um sistema; detalhes no-relevantes e que s aumentariam a complexidade
do problema podem ser ignorados (BEZERRA, 2002).
Comunicao entre as pessoas envolvidas: certamente, o desenvolvi-
mento de um sistema envolve a execuo de uma quantidade signifcativa
de atividades. Essas atividades se traduzem em informaes sobre o sistema
em desenvolvimento. Grande parte dessas informaes corresponde aos mo-
delos criados para representar o sistema. Nesse sentido, os modelos de um
sistema servem tambm para promover a difuso de informaes relativas
ao sistema entre os indivduos envolvidos em sua construo. Alm disso,
diferentes expectativas em relao ao sistema geralmente aparecem quando
da construo dos seus modelos, j que estes servem como um ponto de
referncia comum (BEZERRA, 2002).
Reduo dos custos no desenvolvimento: no desenvolvimento de sis-
temas, seres humanos esto invariavelmente sujeitos a cometerem erros,
que podem ser tanto erros individuais,quanto erros de comunicao entre os
membros da equipe. Certamente, a correo desses erros menos custosa
quando detectada e realizada ainda no(s) modelo(s) do sistema (por exem-
plo, muito mais fcil corrigir uma maquete do que pr abaixo uma parte de
um edifcio). Lembre-se: modelos de sistemas so mais baratos de construir
do que sistemas. Consequuentemente, erros identifcados sobre modelos
tm um impacto menos desastroso (BEZERRA, 2002).
Predio do comportamento futuro do sistema: o comportamento do sis-
tema pode ser discutido atravs da anlise dos seus modelos. Os modelos ser-
vem como um laboratrio, onde diferentes solues para um problema rela-
cionado construo do sistema podem ser experimentadas (BEZERRA, 2002).
e-Tec Brasil/CEMF/Unimontes Anlise e Projetos de Sistemas 17
Uma outra questo importante sobre como so construdos os
modelos de sistemas de software. Em construes civis, frequuentemente h
profssionais analisando as plantas da construo sendo realizadas. A partir
dessas, que podem ser vistas como modelos, os homens tomam decises
sobre o andamento da obra. Modelos de sistemas de software no so muito
diferentes dos modelos de sistemas da construo civil. Nas prximas aulas,
apresentaremos diversos modelos cujos componentes so desenhos grfcos
que seguem algum padro lgico. Esses desenhos so normalmente deno-
minados diagramas. Um diagrama uma apresentao de uma coleo de
elementos grfcos que possuem um signifcado predefnido (BEZERRA, 2002).
Atravs de desenhos grfcos que modelam o sistema os desenvol-
vedores tm uma representao concisa do sistema. No entanto, modelos de
sistemas de software tambm so compostos de informaes textuais. Em-
bora um diagrama consiga expressar diversas informaes de forma grfca,
em diversos momentos h a necessidade de adicionar informaes na forma
de texto, com o objetivo de explicar ou defnir certas partes desse diagrama.
Dado um modelo de uma das perspectivas de um sistema, diz-se que os seus
diagramas, juntamente com a informao textual associada, formam a docu-
mentao desse modelo (BEZERRA, 2002).
Resumo
sobre as caractersticas de sistemas de software;
sobre o conceito de modelo no processo de desenvolvimento de
sistemas;
sobre o conceito do princpio da abstrao; e
sobre a importncia da comunicao entre as pessoas envolvidas
no processo de desenvolvimento de sistemas.
1) Cite uma caracterstica de sistemas de software?
2) D o conceito de modelo no processo de desenvolvimento de sistemas de
informao?
3) D o conceito do princpio da abstrao?
4) Quais so as razes da utilizao de modelos para a construo de siste-
mas de informaes?
A modelagem de
sistemas de software
consiste na utilizao
de notaes grfcas e
textuais com o objetivo
de construir modelos
que representam as
partes essenciais de um
sistema, considerando-
se diversas perspectivas
diferentes e
complementares.
AULA 1
Alfabetizao Digital
19
Aula 3 O paradigma da orientao a
objetos
Objetivos
- Conhecer o conceito de paradigma;
- Compreender o conceito de paradigma da orientao a objetos;
- Conhecer os princpios da orientao a objetos;
- Conhecer o conceito de classes, objetos, mensagens;
- Conhecer os princpios do paradigma da orientao a objetos.
3.1 Introduo
Um conceito essencial para o desenvolvimento atual de sistemas de
software o paradigma da orientao a objetos. Esta aula descreve o signifca-
do desse termo e justifca por que a orientao a objetos importante para
a modelagem de sistemas.
Pode-se comear pela defnio da palavra paradigma. Essa palavra
possui diversos signifcados distintos, mas o que mais se aproxima do signi-
fcado aqui utilizado pode ser encontrado no dicionrio Aurlio Sculo XXI
(BEZERRA, 2002):
Paradigma. [ Do gr. pardeigma, pelo lat. tard. paradigma.]
S.m. Termo com o qual Thomas Kuhn designou as realiza-
es cientfcas (p. ex., a dinmica de Newton ou a qumica
de Lavoisier) que geram modelos que, por perodo mais ou
menos longo e de modo mais ou menos explcito, orientam
o desenvolvimento posterior das pesquisas exclusivamente
na busca da soluo para os problemas por elas suscitados.
Outra defnio, mais restrita e mais apropriada ao contexto desta
aula: um paradigma uma forma de abordar um problema. Como exemplo,
considere a famosa histria da ma caindo sobre a cabea de Isaac Newton,
citado na defnio anterior. Em vez de pensar que somente a ma estava
caindo sobre a Terra, Newton tambm considerou a hiptese de o prprio
planeta tambm estar caindo sobre a ma! Essa outra maneira de abordar o
problema pode ser vista como um paradigma (BEZERRA, 2002).
Pode-se dizer, ento, que o termo paradigma da orientao a ob-
jetos uma forma de abordar um problema. H alguns anos, Alan Kay,
um dos pais do paradigma da orientao a objetos, formulou a chamada
analogia biolgica. Nessa analogia, ele imaginou como seria um sistema de
software que funcionasse como um ser vivo. Nesse sistema, cada clula
interagiria com outras clulas atravs do envio de mensagens para realizar
um objetivo comum. Adicionalmente, cada clula se comportaria como uma
unidade autnoma (BEZERRA, 2002).
De uma forma mais geral, Kay pensou em como construir um siste-
ma de software a partir de agentes autnomos que interagem entre si. Ele,
ento, estabeleceu os seguintes princpios da orientao a objetos (BEZER-
RA, 2002):
Qualquer coisa um objeto.
Objetos realizam tarefas atravs da requisio de servios a ou-
tros objetos.
Cada objeto pertence a uma determinada classe. Uma classe
agrupa objetos similares.
A classe um repositrio para comportamento associado ao ob-
jeto.
Classes so organizadas em hierarquias.
Vamos ilustrar esses princpios com a seguinte histria proposta por
BEZERRA (2002): suponha que algum queira comprar uma pizza. Chame
este algum de Joo. Joo est muito ocupado em casa e resolve pedir a
sua pizza por telefone. Joo liga para a pizzaria e realiza o seu pedido. Joo
informa ao atendente (digamos, o Jos) seu nome, as caractersticas da pizza
desejada e o seu endereo. Jos, que s realiza a funo de atendente, ento
comunica Maria, funcionria da pizzaria responsvel por fazer as pizzas,
qual pizza deve ser feita. Quando Maria termina de fazer a pizza, Jos cha-
ma Antnio, o entregador. Finalmente, Joo recebe a pizza desejada das
mos de Antnio meia hora depois de t-la pedido.
Pode-se observar, que o objetivo de Joo foi atingido atravs da
colaborao de diversos agentes, que so denominados objetos. H diversos
objetos na histria (1 princpio): Joo, Maria, Jos, Antnio. Todos cola-
boram com uma parte, e o objetivo alcanado quando todos trabalham
juntos (2
princpio). Alm disso, o comportamento esperado de Antnio

o mesmo esperado de qualquer entregador. Diz-se que Antnio um
objeto da classe Entregador (3 princpio). Um comportamento comum a
todo entregador, no somente ao Antnio, o de entregar a mercadoria
no endereo especifcado (4 princpio). Finalmente Jos, o atendente,
tambm um ser humano, tambm mamfero, tambm um animal etc (5
princpio) (BEZERRA, 2002).
Mas o que o paradigma da orientao a objetos tem a ver com a
modelagem de sistemas? Antes da orientao a objetos, um outro para-
digma era utilizado na modelagem de sistemas: o paradigma estrutura-
do. Nesse paradigma, os elementos so dados, e processos. Processos agem
sobre dados para que um objetivo seja alcanado (BEZERRA, 2002). Por
outro lado, no paradigma da orientao a objetos, h um elemento, o
objeto, uma unidade autnoma que contm seus prprios dados que so
manipulados pelos processos defnidos para o objeto e que interage com
outros objetos para alcanar um objetivo. o paradigma da orientao a
objetos que os seres humanos utilizam no cotidiano para a resoluo de
problemas. Uma pessoa atende a mensagens (requisies) para realizar
um servio; essa mesma pessoa envia mensagens a outras para que estas
realizem servios (BEZERRA, 2002).
3.2 Classes e objetos
O mundo real formado de coisas. Como exemplos de coisas po-
dem-se citar um cliente, uma loja, uma venda, um pedido de compra, um
fornecedor, etc. No paradigma de orientao a objetos, essas coisas do mun-
do real so denominadas objetos (BEZERRA, 2002).
Por outro lado, seres humanos costumam agrupar os objetos. Prova-
velmente, os seres humanos realizam esse processo mental de agrupamento
para tentar gerenciar a complexidade de entender as coisas do mundo real.
Realmente, bem mais fcil entender a ideia cavalo do que entender todos
os cavalos que existem. Na terminologia da orientao a objetos, cada ideia
denominada classe de objetos, ou simplesmente classe. Uma classe uma
descrio dos atributos e servios comuns a um grupo de objetos. Sendo
assim, pode-se entender uma classe como sendo um molde a partir do qual
objetos so construdos. Ainda sobre terminologia, diz-se que um objeto
uma instncia de uma classe (BEZERRA, 2002).
Por exemplo, quando se pensa em um cavalo, logo vem mente um
animal de quatro patas, cauda, crina etc. Pode ser que algum dia voc veja
dois cavalos, um mais baixo que o outro, um com cauda maior que o outro,
ou mesmo, por um infeliz acaso, um cavalo com menos patas que o outro. No
entanto, voc ainda ter certeza de estar diante de dois cavalos. Isso porque
a ideia (classe) cavalo est formada na mente dos seres humanos, indepen-
dentemente das pequenas diferenas que possa haver entre os exemplares
(objetos) da ideia cavalo (BEZERRA, 2002).
importante notar que uma classe uma abstrao das caracters-
ticas de um grupo de coisas do mundo real. Na maioria das vezes, as coisas
do mundo real so muito complexas para que todas as suas caractersticas
sejam representadas em uma classe. Alm disso, para fns de modelagem de
um sistema, somente um subconjunto de caractersticas pode ser relevante.
Portanto, uma classe representa uma abstrao das caractersticas relevantes
do mundo real (BEZERRA, 2002). Finalmente, preciso atentar para o fato de
que alguns textos sobre orientao a objetos utilizam os termos classe e ob-
jeto equivalentemente para denotar uma classe de objetos (BEZERRA, 2002).
3.3 Mensagens
Os objetos no executam suas operaes aleatoriamente. Para que
uma operao em um objeto seja executada, deve haver um estmulo envia-
do a esse objeto. Se um objeto for visto como uma entidade ativa que repre-
senta uma abstrao de algo do mundo real, ento faz sentido dizer que tal
O paradigma da
orientao a objetos
visualiza um sistema
de software como uma
coleo de agentes
interconectados
chamados objetos. Cada
objeto responsvel
por realizar tarefas
especfcas. atravs
da interao entre
objetos que uma
tarefa computacional
realizada.
Tanto o paradigma
estruturado quanto o
paradigma orientado
a objetos surgiram
nas linguagens de
programao, para
depois serem aplicados
modelagem de
sistemas. De fato, as
ideias de Alan Kay
foram aplicadas na
construo de uma das
primeiras linguagens de
programao orientadas
a objetos: o Small Talk.
Um sistema de software
orientado a objetos
consiste de objetos
em colaborao com o
objetivo de realizar as
funcionalidades desse
sistema. Cada objeto
responsvel por
tarefas especfcas.
atravs da cooperao
entre objetos que a
computao do sistema
se desenvolve.
objeto pode responder a estmulos a ele enviados (assim como faz sentido
dizer que seres vivos reagem a estmulos que eles recebem). Independen-
temente da origem do estmulo, quando ele ocorre, diz-se que o objeto em
questo est recebendo uma mensagem requisitando que ele realize alguma
operao (BEZERRA, 2002).
Quando se diz que objetos de um sistema esto trocando mensa-
gens signifca que esses objetos esto enviando mensagens uns aos outros
com o objetivo de realizar alguma tarefa dentro do sistema no qual eles
esto inseridos (BEZERRA, 2002).
Figura 1: Objetos interagem atravs do envio de mensagens.
Fonte: Bezerra (2002).
3.4 Viso geral dos princpios da orientao a
objetos
Nesta aula, vamos apresentar os princpios do paradigma da orien-
tao a objetos. A Figura XX mostra uma viso geral dos princpios utilizados
em Orientao a Objetos.
Figura 2: Viso geral dos princpios da orientao a objetos.
A descrio dos princpios de Encapsulamento, de Abstrao, de
Polimorfsmo e de Herana realizada nos itens seguintes.
3.4.1 Abstrao
Uma abstrao qualquer modelo que inclui os aspectos mais im-
portantes, essenciais de alguma coisa, ao mesmo tempo em que ignora os
detalhes menos importantes. Abstraes permitem gerenciar a complexida-
de e concentrar a ateno nas caractersticas essenciais de um objeto. Note
que uma abstrao dependente da perspectiva: o que importante em um
contexto pode no ser importante em outro (BEZERRA, 2002).
3.4.2 Encapsulamento
Os Objetos possuem comportamento. O termo comportamento diz
respeito a operaes realizadas por um objeto e tambm ao modo pelo qual
essas operaes so executadas. O mecanismo de encapsulamento uma
forma de restringir o acesso ao comportamento interno de um objeto. Um
objeto que precise da colaborao de outro objeto para realizar alguma ta-
refa simplesmente envia uma mensagem a este ltimo. O mtodo que o
objeto requisitado usa para realizar a tarefa no conhecido dos objetos
requisitantes (BEZERRA, 2002).
Certamente, o objeto requisitante precisa conhecer quais as tarefas
que um outro objeto sabe fazer ou que informao ele conhece. Para tanto,
a classe de um objeto descreve o seu comportamento. Na terminologia da
orientao a objetos, diz-se que um objeto possui uma interface. Em termos
bastante simples, a interface de um objeto o que ele conhece e o que ele
sabe fazer, sem descrever como o objeto conhece o faz. A interface de um
objeto defne os servios que ele pode realizar e consequuentemente as
mensagens que ele recebe. Uma interface pode ter vrias formas de im-
plementao. Mas, pelo Princpio do Encapsulamento, a implementao de
um objeto requisitado no importa para um objeto requisitante (BEZERRA,
2002).
Atravs do encapsulamento, a nica coisa que um objeto precisa
saber para pedir a colaborao de outro objeto conhecer a sua interface.
Isso contribui para a autonomia dos objetos. Cada objeto envia mensagens
a outros objetos para realizar certas tarefas, sem se preocupar em como as
tarefas so realizadas. A aplicao da abstrao, neste caso, est em escon-
der os detalhes de funcionamento interno de um objeto (BEZERRA, 2002).
Figura 3: Princpio do encapsulamento: visto externamente, o objeto a sua
interface.
3.4.3 Polimorfsmo
O polimorfsmo indica a capacidade de abstrair vrias implementa-
es diferentes em uma nica interface. H algum tempo atrs, o controle
remoto de meu televisor quebrou. (Era realmente cansativo ter de levantar
para desligar o aparelho ou para trocar de canal). Um tempo depois, comprei
um videocassete do mesmo fabricante de meu televisor. Para minha surpre-
sa, o controle remoto do videocassete tambm funcionava para o televisor!
Esse um exemplo de aplicao do Princpio do Polimorfsmo. Note
mais uma vez que a abstrao tambm aplicada aqui: um objeto pode en-
viar a mesma mensagem para objetos semelhantes, mas que implementam a
sua interface de formas diferentes (BEZERRA, 2002).
3.4.4 Herana
A herana outra forma de abstrao utilizada na orientao a
objetos. As caractersticas e o comportamento comuns a um conjunto de
objetos podem ser abstrados em uma classe. A herana pode ser vista como
um nvel de abstrao acima da encontrada entre classes e objetos (BEZER-
RA, 2002).
Na herana, classes semelhantes so agrupadas em hierarquias (ver
Figura 1-4). Cada nvel de uma hierarquia pode ser visto como um nvel de
abstrao. Cada classe em um nvel da hierarquia herda as caractersticas
das classes nos nveis acima. Esse mecanismo facilita o compartilhamento
de comportamento comum entre um conjunto de classes semelhantes. Alm
disso, as diferenas ou variaes de uma classe em particular podem ser
organizadas de forma mais clara (BEZERRA, 2002).
Figura 4: Princpio da herana: classes podem ser organizadas em hierarquias.
Resumo
sobre o conceito de paradigma;
sobre o conceito de paradigma da orientao a objetos;
sobre o conceito dos princpios da orientao a objetos;
sobre o conceito de classes, objetos, mensagens; e
sobre os princpios do paradigma da orientao a objetos.
1) D o conceito de paradigma?
2) Qual o conceito de paradigma da orientao a objetos?
3) D o conceito dos princpios da orientao a objetos?
4) D o conceito de classes, objetos e mensagens?
5) Explique os princpios do paradigma da orientao a objetos.
AULA 1
Alfabetizao Digital
27
Aula 4 Evoluo histrica da modela-
gem de sistemas
Objetivos
- Conhecer o histrico da evoluo das tcnicas de desenvolvi-
mento de sistemas.
4.1 Introduo
O rpido crescimento da capacidade computacional das mquinas
resultou na demanda por sistemas de software cada vez mais complexos,
que tirassem proveito de tal capacidade. O surgimento desses sistemas com-
plexos resultou na necessidade de reavaliao da forma de se desenvolver
sistemas. Em funo disso, desde o aparecimento do primeiro computador
at os dias de hoje, as tcnicas utilizadas para a construo de sistemas
computacionais tm evoludo de forma impressionante, principalmente no
que tange modelagem de sistemas (BEZERRA, 2002).
4.2 Resumo histrico
A seguir, apresentado um breve resumo histrico da evoluo das
tcnicas de desenvolvimento de acordo com BEZERRA (2002). O objetivo da
apresentao do resumo histrico esclarecer como se chegou s tcnicas
atualmente utilizadas.
Dcadas de 1950/60: os sistemas de software eram bastante sim-
ples. O desenvolvimento desses sistemas era feito de forma
ad-hoc. Os sistemas eram signifcativamente mais simples e,
consequentemente, as tcnicas de modelagem tambm eram
mais simples: era a poca dos fuxogramas e dos diagramas de
mdulos.
Dcada de 1970: nesta poca, computadores mais avanados e
acessveis comearam a surgir. Houve uma grande expanso do
mercado computacional. Sistemas mais complexos comeavam a
surgir. Por conseguinte, modelos mais robustos foram propostos.
Neste perodo, surgem programao estruturada e o projeto
estruturado. Os autores Larry Constantine e Edward Yourdon so
grandes colaboradores nessas tcnicas.
Dcada de 1980: nesta fase, os computadores se tornaram ainda
mais avanados e baratos. Surge necessidade por interfaces
mais sofsticadas, o que originou a produo de sistemas de sof-
twares mais complexos. A Anlise Estruturada surgiu no incio
deste perodo com os trabalhos de Edward Yourdon, Peter Coad,
Tom DeMarco, James Martin e Chris Gane.
O termo ad-hoc
signifca direto ao
assunto ou direto ao
que interessa. Talvez
o uso deste termo
denote a abordagem
desta primeira fase do
desenvolvimento de
sistemas, na qual no
havia um planejamento
inicial. O cdigo-fonte
do programa a ser
construdo era ele
prprio, o modelo.
Incio da Dcada de 1990: este o perodo em que surge um novo
paradigma de modelagem, a Anlise Orientada a Objetos. Gran-
des colaboradores deste paradigma so Sally Shlaer, Stephen
Mellor, Rebecca Wirfs-Brock, James Rumbaugh, Grady Booch e
Ivar jacobson.
Fim da Dcada de 1990: o paradigma da orientao a objetos atin-
ge sua maturidade. Os conceitos de padres de projeto, fra-
meworks, componentes e qualidade comeam a ganhar espao.
Surge a Linguagem de Modelagem Unifcada (UML).
Resumo
sobre o histrico da evoluo das tcnicas de desenvolvimento
de sistemas.
1) Explique com suas palavras o histrico da evoluo das tcnicas de desen-
volvimento de sistemas.
AULA 1
Alfabetizao Digital
29
Aula 5 A linguagem de modelagem uni-
fcada (UML)
Objetivos
- Saber em que a UML pode nos ajudar;
- Saber por que a UML uma linguagem;
- Conhecer os caminhos que devemos seguir para aprender a UML;
- Conhecer a UML e o processo de desenvolvimento de software.
5.1 Introduo
Todo profssional ligado informtica reconhece a importncia da
criao de modelos para que sistemas de qualidade sejam obtidos. H uma
srie de justifcativas que envolvem a criao de modelos, no entanto a mais
forte recai sobre o teste. Analogamente ao trabalho do engenheiro, bvio
que prefervel verifcar os erros de construo de uma casa baseando-se
em um modelo, que constru-Ia e colocar pessoas morando para depois espe-
rar que apaream os erros (MATOS, 2002).
Na verdade, os modelos so uma importante ferramenta que en-
volve muitos outros aspectos teis na conduo do desenvolvimento de um
sistema computacional, tais como:
diminuio da complexidade do sistema, j que difcil enten-
der a complexidade do todo;
simplifcao da realidade por meio de uma abstrao que pode
ser facilmente entendida;
possibilidade de enxergar os problemas do sistema antes mesmo
que aconteam;
possibilidade de simular situaes que seriam perigosas ou at
danosas caso fossem executadas no sistema em ao.
Embora a concepo da UML tenha sido infuenciada por vrios m-
todos de anlise e projeto orientados a objeto, h particularmente trs no-
taes das quais a UML derivada:
000 (Projeto Orientado a Objetos) - Grady Booch;
OMT (Tcnica de Modelagem de Objetos) - James Rumbaugh.
OOSE (Engenharia de Software Orientada por Objetos) - Ivar Ja-
cobson.
Em 1997, a OMG (Object Management Group) tornou a UML uma
linguagem de modelagem padro para aplicaes orientadas a objeto. A im-
portncia dessa padronizao est no fato de que a OMG possui mais de 800
fliados, incluindo empresas como IBM, HP, Borland, etc. Ou seja, os princi-
pais softwares que utilizamos so modelados e idealizados por meio da UML
(MATOS, 2002).
5.2 Em que a UML pode me ajudar?
Esta uma inquietao bvia de qualquer pessoa que nunca ouviu
falar em UML. Particularmente, a inquietao da maioria dos estudantes
de Engenharia de Software que questiona (pblica ou individualmente): ...
para que estou aprendendo isso?.
A Orientao a Objetos era, at ento, um termo obscuro e at
certo ponto mstico. A Programao Estruturada e, consequentemente, todos
os conceitos relacionados Anlise Estruturada j haviam tomado conta do
modus operandi de qualquer analista ou projetista. Ento surge a questo:
esta a nica forma de criar sistemas?
A UML uma composio das boas caractersticas de outras nota-
es de ferramentas direcionadas orientao a objetos. Ou seja, a UML a
ferramenta ideal para criar, compreender, testar, validar, arquitetar (lgica
e fsicamente) e ainda identifcar todos os possveis comportamentos do sis-
tema, especialmente os sistemas orientados e objeto (MATOS, 2002).
Convm salientar que a orientao a objetos o cerne da maioria
dos sistemas construdos atualmente: desde os sistemas comerciais (basea-
dos em componentes, eventos e hierarquias de formulrios) at os comple-
xos sistemas para Web. Em suma, o porqu de conhecer a UML est simples-
mente relacionado realidade do processo de desenvolvimento de software
(MATOS, 2002).
5.3 Por que a UML uma linguagem?
Realmente soa estranho dizer que a UML uma linguagem, sabendo
que sua funo bem parecida com a de outras ferramentas de modelagem,
tais como o Diagrama de Fluxo de Dados (DFD), o Diagrama de Entidades
e Relacionamentos (DER), o Diagrama de Transio de Estados (DTE), etc.
Obviamente que se questiona: ... quer dizer que esses outros diagramas
tambm so uma linguagem?
Uma linguagem (mesmo as do mundo da informtica) deve se-
guir uma gramtica (em que todos os elementos bsicos de representa-
o sejam indicados) e tambm a um conjunto de regras sintticas, tal
qual o nosso portugus. Talvez faltasse aos outros diagramas essa rigidez
sinttica em que um outro diagrama (mesmo que no seu nvel de abstra-
o), devesse obedecer sua sinttica mantendo a semntica trazida de
outro diagrama, ou seja, um diagrama, efetivamente, no se encaixava
no outro, a no ser que se fzesse um grande esforo para enxergar, por
exemplo, o que um DFD tem a ver com o seu respectivo DER (MATOS, 2002).
O esforo da UML permitir que desde a representao das
funes bsicas do sistema (e seus respectivos responsveis) at o pla-
nejamento da arquitetura de implementao, todo o processo acontea
de maneira coerente e com uma estreita ligao com o plano anterior
(MATOS, 2002).
5.4 Que caminho deve ser seguido para apren-
d-la?
O ponto de partida conhecer o Paradigma de Orientao a
Objetos. Mesmo aqueles que j programam usando a orientao a ob-
jetos precisam conhecer detalhes que, s vezes, passam despercebidos
aos programadores. E aqueles que no conhecem a orientao a objetos
faro um grande exerccio de abstrao; no entanto, no se pode con-
siderar que o no-conhecimento prvio da Programao Orientao a
Objetos seja um empecilho para utilizar a UML (MATOS, 2002).
O uso de um software de apoio modelagem muito importan-
te por dois motivos: primeiro porque os modelos comearo a fcar to
longos que o papel fcar pequeno, segundo porque uma tima maneira
de checar se as associaes entre os modelos esto corretas (MATOS,
2002).
5.5 UML e o desenvolvimento de software
Outra questo muito importante como o software, enfm, vai ser
produzido. Que caminho aconselhvel para chegar a esse ponto? Quais so
os requisitos mnimos para que o software produzido tenha qualidade?
H cinco etapas bem distintas em qualquer processo de desen-
volvimento de software: levantamento de requisitos, anlise de requi-
sitos, projeto, implementao, testes e implantao. Independente de
qual forma foi escolhida, de qual ttica ser adotada, imprescindvel
que essas seis fases surjam de alguma forma (MATOS, 2002).
Na verdade, a UML no prescreve nenhum roteiro, apenas per-
mite que a criatividade e o bom senso permeiem um desenvolvimento
com qualidade. A qualidade surge obviamente de qualquer processo em
que o produto fnal foi testado e verifcado se foi desenvolvido conforme
as necessidades do cliente (MATOS, 2002).
Resumo
sobre a UML e em que ela pode nos ajudar, e tambm porque ela
considerada uma linguagem;
sobre os caminhos que devemos seguir para aprender a UML; e
sobre a UML e os processos de desenvolvimento de software.
1) Leia com ateno todos os itens relacionados aula 5, para gravar seus
conceitos.
AULA 1
Alfabetizao Digital
33
Aula 6 O processo de desenvolvimento
de software
Objetivos
- Conhecer as atividades tpicas de um processo de desenvolvi-
-mento de software;
- Compreender a importncia de cada atividade no decorrer de um
processo de desenvolvimento de software.
6.1 Introduo
O desenvolvimento de software uma atividade complexa. Essa
complexidade corresponde sobreposio das complexidades relativas ao
desenvolvimento dos seus diversos componentes: software, hardware, pro-
cedimentos etc. Isso se refete no alto nmero de projetos de software que
no chegam ao fm, ou que extrapolam recursos de tempo e de dinheiro
alocados (BEZERRA, 2002).
Para dar uma idia da complexidade no desenvolvimento de sis-
temas de software, so listados a seguir alguns dados levantados no Chaos
Report, um estudo feito pelo Standish Group sobre projetos de desenvolvi-
mento.
Porcentagem de projetos que terminam dentro do prazo estima-
do: 10%;
Porcentagem de projetos que so descontinuados antes de che-
garem ao fm: 25%;
Porcentagem de projetos acima do custo esperado: 60%;
Atraso mdio nos projetos: um ano.
Tentativas de lidar com essa complexidade e de minimizar os pro-
blemas envolvidos no desenvolvimento de software envolvem a defnio de
processos de desenvolvimento de software. Um processo de desenvolvimento
de software (ou simplesmente processo de desenvolvimento) compreende
todas as atividades necessrias para defnir, desenvolver, testar e manter um
produto de software (BEZERRA, 2002).
Alguns objetivos de um processo de desenvolvimento so: defnir
quais as atividades a serem executadas ao longo do projeto; quando, como e
por quem tais atividades sero executadas; prover pontos de controle para
verifcar o andamento do desenvolvimento; padronizar a forma de desenvol-
ver software em uma organizao (BEZERRA, 2002).
6.2 Atividades tpicas de um processo de de-
senvolvimento
Um processo de desenvolvimento classifca em atividades as tare-
fas realizadas durante a construo de um sistema de software. H vrios
processos de desenvolvimento propostos. Alm disso, no existe o melhor
processo de desenvolvimento. Cada processo tem suas particularidades em
relao ao modo de arranjar e encadear as atividades de desenvolvimento.
Entretanto, podem-se distinguir atividades que, com uma ou outra modifca-
o, so comuns maioria dos processos existentes. Abaixo, descreveremos
essas atividades (BEZERRA, 2002).
6.2.1 Levantamento de requisitos
A atividade de levantamento de requisitos corresponde etapa de com-
preenso do problema aplicada ao desenvolvimento de software. O principal
objetivo do levantamento de requisitos que usurios e desenvolvedores te-
nham a mesma viso do problema a ser resolvido. Nessa etapa, os desenvol-
vedores, juntamente com os clientes, tentam levantar e defnir as necessi-
dades dos futuros usurios do sistema a ser desenvolvido. Essas necessidades
so geralmente denominadas requisitos (BEZERRA, 2002).
Formalmente, um requisito uma condio ou capacidade que
deve ser alcanada ou possuda por um sistema ou componente deste para
satisfazer um contrato, padro, especifcao ou outros documentos formal-
mente impostos. Normalmente os requisitos de um sistema so identifcados
a partir do domnio do negcio. Denomina-se domnio do negcio a rea de
conhecimento especfca na qual um determinado sistema de software ser
desenvolvido. Ou seja, o domnio do negcio corresponde parte do mundo
real que relevante ao desenvolvimento de um sistema, no sentido de que
algumas informaes e processos desse domnio precisam ser includos no
sistema. O domnio do negcio tambm chamado de domnio do problema ou
domnio da aplicao (BEZERRA, 2002).
Durante o levantamento de requisitos, a equipe de desenvolvimen-
to tenta entender o domnio do negcio que deve ser automatizado pelo
sistema de software. O levantamento de requisitos compreende tambm um
estudo exploratrio das necessidades dos usurios e da situao do siste-
ma atual (se este existir). H vrias tcnicas utilizadas para isso, como por
exemplo: leitura de obras de referncia e livros-texto, observao do am-
biente do usurio, entrevistas com os usurios, entrevistas com especialistas
do domnio, reutilizao de anlises anteriores, comparao com sistemas
preexistentes do mesmo domnio do negcio (BEZERRA, 2002).
O produto do levantamento de requisitos o documento de requi-
sitos, que declara os diversos tipos de requisitos do sistema. Normalmente
esse documento escrito em uma notao informal (em linguagem natural).
As principais sees de um documento de requisitos so listadas a seguir
(BEZERRA, 2002).
Requisitos funcionais: defnem as funcionalidades do sistema. Al-
guns exemplos de requisitos funcionais so listados a seguir.
O sistema deve permitir que cada professor realize o lanamen-
to de notas das turmas nas quais lecionou;
O sistema deve permitir que um aluno realize a sua matrcula
nas disciplinas oferecidas em um semestre;
Os coordenadores de escola devem poder obter o nmero de
aprovaes, reprovaes e trancamentos em todas as turmas em
um determinado perodo.
Requisitos no-funcionais: declaram as caractersticas de quali-
dade que o sistema deve possuir e que esto relacionadas s suas funciona-
lidades. Alguns tipos de requisitos no-funcionais so enumerados a seguir.
Confabilidade: corresponde a medidas quantitativas da confa-
bilidade do sistema, tais como tempo mdio entre falhas, recu-
perao de falhas ou quantidade de erros por milhares de linhas
de cdigo-fonte.
Desempenho: requisitos que defnem tempos de resposta espe-
rados para as funcionalidades do sistema.
Portabilidade: restries sobre as plataformas de hardware e de
software nas quais o sistema ser implantado e sobre o grau de
facilidade para transportar o sistema para outras plataformas.
Segurana: limitaes sobre a segurana do sistema em relao
a acessos no-autorizados.
Usabilidade: requisitos que se relacionam ou afetam a usabilida-
de do sistema. Exemplos incluem requisitos sobre a facilidade de
uso e a necessidade ou no de treinamento dos usurios.
Restries: declarao de restries impostas sobre o desenvolvi-
mento do sistema. Restries defnem, por exemplo, a adequao a custos e
prazos, a plataforma tecnolgica, aspectos legais (licenciamento), limitaes
sobre a interface com o usurio, componentes de hardware e software a
serem adquiridos etc.
Uma das formas de se medir a qualidade de um sistema de softwa-
re atravs de sua utilidade. E um sistema ser til para seus usurios se
atender aos requisitos defnidos. Portanto, os requisitos devem ser expressos
de uma maneira tal que eles possam ser verifcados e comunicados a leitores
tcnicos e no-tcnicos. A equipe tcnica (leitores tcnicos) deve entender
o documento de requisitos de tal forma a poder obter solues tcnicas
apropriadas. Clientes (leitores no-tcnicos) devem entender esse documen-
to para que possam priorizar o desenvolvimento dos requisitos, conforme as
necessidades da organizao (BEZERRA, 2002).
Um ponto importante sobre o documento de requisitos que ele
no deve conter informaes sobre as solues tcnicas que sero adotadas
para desenvolver o sistema. O enfoque prioritrio do levantamento de re-
quisitos responder claramente questo O que o usurio necessita do
novo sistema?. Lembre-se sempre: novos sistemas sero avaliados pelo seu
grau de conformidade aos requisitos, no importa quo complexa a soluo
tecnolgica tenha sido. Requisitos defnem o problema a ser resolvido pelo
sistema de software; eles no descrevem o software que resolve o problema
(BEZERRA, 2002).
O levantamento de requisitos a etapa mais importante em termos
de retorno em investimentos feitos para O projeto de desenvolvimento. Mui-
tos sistemas foram abandonados ou nem chegaram a uso porque os membros
da equipe no dispensaram tempo sufciente para compreender as necessi-
dades do cliente em relao ao novo sistema. Por outro lado, um sistema de
informaes normalmente utilizado para automatizar processos de negcio
de uma organizao: Portanto, esses processos devem ser compreendidos
antes da construo do sistema de informaes (BEZERRA, 2002).
O documento de requisitos serve como um termo de consenso entre
a equipe tcnica (desenvolvedores) e o cliente. Esse documento constitui
a base para as atividades subsequentes do desenvolvimento do sistema e
fornece um ponto de referncia para qualquer validao futura do software
construdo. O envolvimento do cliente desde o incio do processo de desen-
volvimento ajuda a assegurar que o produto desenvolvido realmente atenda
s necessidades identifcadas (BEZERRA, 2002).
Alm disso, o documento de requisitos estabelece o escopo do sistema
(isto , o que faz parte e o que no faz parte do sistema). O escopo de um
sistema muitas vezes muda durante o seu desenvolvimento. Desta forma, se
o escopo muda, tanto clientes quanto desenvolvedores tm um parmetro
para decidirem o quanto dos recursos de tempo e fnanceiros devem mudar.
Contudo, o planejamento inicial do projeto deve se basear no escopo inicial
(BEZERRA, 2002).
Um outro ponto importante sobre os requisitos a sua caractersti-
ca de volatilidade. Um requisito voltil aquele que pode sofrer modifcaes
durante o desenvolvimento do sistema. Nos primrdios da modelagem de sis-
temas, era comum a prtica de congelar os requisitos levantados antes de
se iniciar a construo do sistema. Isto , os requisitos considerados eram os
mesmos do incio ao fm do projeto de desenvolvimento. Atualmente, a vola-
tilidade dos requisitos um fato com o qual a equipe de desenvolvimento de
sistemas tem de conviver e consequentemente o congelamento de requisitos
impraticvel. Isso porque, nos dias atuais, as organizaes precisam se
adaptar a mudanas cada vez mais rapidamente. Durante o perodo em que o
sistema est em desenvolvimento, as tecnologias utilizadas, as expectativas
dos usurios, e as regras do negcio mudam. E isso para mencionar apenas
algumas possveis mudanas (BEZERRA, 2002).
Isso parece se contrapor ao fato de que o documento de requisitos
deve defnir de forma clara quais so os requisitos do sistema. Na realidade,
o documento de requisitos serve como um consenso inicial. O ponto principal
do levantamento de requisitos compreender o sistema o mximo possvel
antes de comear a ser construdo. A regra defnir completamente qual-
quer requisito j conhecido, mesmo os mais simples. medida que novos
requisitos sejam detectados (ou que requisitos preexistentes mudem), os
desenvolvedores devem verifcar cuidadosamente o impacto das mudanas
resultantes no escopo do sistema. Dessa forma, os clientes podem decidir
se tais mudanas devem ser consideradas no desenvolvimento, uma vez que
infuenciam o cronograma de desenvolvimento e os recursos fnanceiros alo-
cados (BEZERRA, 2002).
A menos que o sistema a ser desenvolvido seja bastante simples e
esttico (caractersticas raras nos sistemas atuais), praticamente imposs-
vel pensar em todos os detalhes a princpio. Alm disso, quando o sistema
entrar em produo e os usurios comearem a utiliz-lo, eles prprios des-
cobriro requisitos nos quais no tinham pensado inicialmente. Em resumo,
os requisitos de um sistema complexo inevitavelmente mudaro durante o
seu desenvolvimento (BEZERRA, 2002).
Uma caracterstica desejvel a um documento de requisitos ter
os seus requisitos ordenados pelos usurios em funo do seu grau de prio-
ridade. O grau de prioridade de um requisito para os usurios normalmente
estabelecido em funo da adio de valor que o desenvolvimento desse
requisito no sistema trouxer aos usurios. Saber o grau de prioridade de um
requisito permite que a equipe de desenvolvimento (mais particularmente o
gerente do projeto) decida em que momento cada requisito deve ser consi-
derado durante o desenvolvimento. As prioridades atribudas aos requisitos
permitiro ao gerente de projeto tomar decises acerca do momento no qual
cada requisito deve ser considerado durante o desenvolvimento do sistema
(BEZERRA, 2002).
6.2.2 Anlise de requisitos
Formalmente, o termo anlise corresponde a quebrar um sistema
em seus componentes e estudar como tais componentes interagem com o
objetivo de entender como esse sistema funciona. No contexto dos sistemas
de software, esta a etapa na qual os analistas realizam um estudo detalha-
do dos requisitos levantados na atividade anterior. A partir desse estudo, so
construdos modelos para representar o sistema a ser construdo. A anlise de
requisitos tambm chamada de especifcao de requisitos.
Assim como no levantamento de requisitos, a anlise de requisitos
no leva em conta o ambiente tecnolgico a ser utilizado. Nesta atividade,
o foco de interesse tentar construir uma estratgia de soluo sem se
preocupar com a maneira como essa estratgia ser realizada. A razo desta
prtica tentar obter a melhor soluo para o problema sem se preocupar
com os detalhes da tecnologia a ser utilizada. necessrio saber o que o sis-
tema proposto deve fazer para, ento, defnir como esse sistema ir faz-Io
(BEZERRA, 2002).
O termo paralisia da anlise conhecido no desenvolvimento
de sistemas de software. Esse termo denota a situao em que h uma es-
tagnao da fase de anlise: os analistas passam muito tempo construindo
o modelo do sistema. Embora essa situao certamente exista, na prtica
raramente poderamos encontr-Ia. O que ocorre frequentemente na prtica
exatamente o contrrio: equipes de desenvolvimento que passam para a
construo da soluo sem antes terem defnido completamente o problema.
Portanto, os modelos construdos na fase de anlise devem ser cuidadosa-
mente validados e verifcados, atravs da validao e verifcao dos modelos,
respectivamente (BEZERRA, 2002).
O objetivo da validao assegurar que as necessidades do cliente
esto sendo atendidas pelo sistema: ser que o software correto est sendo
construdo? J a verifcao tem o objetivo de verifcar se os modelos constru-
dos esto em conformidade com os requisitos defnidos: ser que o software
est sendo construdo corretamente? Na verifcao dos modelos da anlise,
analisada a exatido de cada modelo em separado e a consistncia entre
os modelos (BEZERRA, 2002).
Em um processo de desenvolvimento orientado a objetos, o resul-
tado da anlise so modelos que representam as estruturas das classes de
objetos componentes do sistema. Alm disso, a anlise tambm resulta em
modelos que especifcam as funcionalidades do sistema de software (BEZER-
RA, 2002).
6.2.3 Projeto
O foco principal da anlise so os aspectos lgicos e independen-
tes de implementao de um sistema (os requisitos). Na fase de projeto,
determina-se como o sistema funcionar para atender aos requisitos, de
acordo com os recursos tecnolgicos existentes (a fase de projeto considera
os aspectos fsicos e dependentes de implementao). Aos modelos constru-
dos na fase de anlise so adicionadas as denominadas restries de tecno-
logia (BEZERRA, 2002). Exemplos de aspectos a serem considerados na fase
de projeto: arquitetura do sistema, padro de interface grfca, a linguagem
de programao, o gerenciador de banco de dados etc.
Esta fase produz uma descrio computacional do que o software
deve fazer e deve ser coerente com a descrio feita na anlise. Em alguns
casos, algumas restries da tecnologia a ser utilizada j foram amarradas
no levantamento de requisitos. Em outros casos, essas restries devem ser
especifcadas. Mas, em todos os casos, a fase de projeto do sistema dire-
cionada pelos modelos construdos na fase de anlise e pelo planejamento
do sistema (BEZERRA, 2002).
O projeto consiste de duas atividades principais: projeto da arqui-
tetura (tambm conhecido como projeto de alto nvel) e projeto detalhado
(tambm conhecido como projeto de baixo nvel). .
Em um processo de desenvolvimento orientado a objetos, o projeto
da arquitetura consiste em distribuir as classes de objetos relacionadas do
sistema e subsistemas e seus componentes. Consiste tambm em distribuir
esses componentes fsicamente pelos recursos de hardware disponveis. Os
diagramas da UML normalmente utilizados nesta fase do projeto so os dia-
gramas de implementao. O projeto da arquitetura normalmente realiza-
do por um arquiteto de software (BEZERRA, 2002).
No projeto detalhado, so modeladas as colaboraes entre os ob-
jetos de cada mdulo com o objetivo de realizar as funcionalidades do mdu-
lo. Tambm so realizados o projeto da interface com o usurio e o projeto
de dados. Os diagramas da UML utilizados nesta fase do projeto so: diagra-
ma de classes, diagrama de casos de uso, diagrama de interao, diagrama
de estados e diagrama de atividades.
Embora a anlise e o projeto sejam descritos em sees separadas
neste caderno, importante notar que no h uma distino assim to cla-
ra entre essas duas fases. Principalmente no desenvolvimento de sistemas
orientados a objetos, as atividades dessas duas fases frequentemente se
misturam (BEZERRA, 2002).
6.2.4 Implementao
Na implementao, o sistema codifcado, ou seja, ocorre a tradu-
o da descrio computacional da fase de projeto em cdigo executvel
atravs do uso de uma ou mais linguagens de programao.
Em um processo de desenvolvimento orientado a objetos, a imple-
mentao envolve a defnio das classes de objetos do sistema utilizando
linguagens de programao como C++,Java etc. Alm da codifcao desde
o incio, a implementao pode tambm utilizar componentes de software
e bibliotecas de classes preexistentes para agilizar a atividade (BEZERRA,
2002).
6.2.5 Testes
Diversas atividades de teste so realizadas para verifcao do siste-
ma construdo, levando-se em conta a especifcao feita na fase de projeto.
O principal produto dessa fase o relatrio de testes, contendo informaes
sobre erros detectados no software. Aps a atividade de testes, os diversos
mdulos do sistema so integrados, resultando fnalmente no produto de
software (BEZERRA, 2002).
6.2.6 Implantao
O sistema empacotado, distribudo e instalado no ambiente do
usurio. Os manuais do sistema so escritos, os arquivos so carregados, os
dados so importados para o sistema e os usurios so treinados para utilizar
o sistema corretamente. Em alguns casos, aqui tambm ocorre migrao de
sistemas de software e de dados preexistentes (BEZERRA, 2002).
Resumo
sobre as atividades tpicas de um processo de desenvolvimento
de software;
sobre a importncia de cada atividade no decorrer de um pro-
cesso de desenvolvimento de software.
1) Qual o conceito do processo de desenvolvimento de software?
2) Quais so os objetivos de um processo de desenvolvimento de software?
3) Quais so as atividades tpicas de um processo de desenvolvimento de
software? Descreva de forma sucinta cada atividade.
4) Qual o conceito de requisitos?
5) Como chamado o produto do levantamento de requisitos?
6) D o conceito de requisitos funcionais e requisitos no-funcionais? Cite
exemplos dos dois tipos de requisitos.
7) Qual o objetivo da validao e da verifcao dos modelos construdos
na fase de anlise?
AULA 1
Alfabetizao Digital
41
Aula 7 Modelagem Baseada em UML
Objetivos
- Conhecer um breve histrico da UML;
- Conhecer os principais diagramas da UML;
- Saber a identifcar um caso de uso;
- Aprender a identifcar atores;
- Aprender a desenhar um diagrama de caso de uso;
- Conhecer os cuidados necessrios ao se criar diagramas de caso de uso;
- Aprender a identifcar classes;
- Aprender a identifcar relacionamentos;
- Conhecer extenses e mecanismos;
- Aprender a desenhar um diagrama de classes;
- Conhecer os tipos de diagramas de interao;
- Conhecer diagramas de colaborao;
- Conhecer diagramas de sequncia;
- Aprender a desenhar diagramas de sequncia;
- Aprender sobre diagramas de estados e sua funo;
- Aprender a desenhar diagramas de estados;
- Aprender sobre diagramas de atividades;
- Aprender a desenhar diagramas de atividades;
- Conhecer componentes de software;
- Aprender a desenhar diagramas de componentes;
- Aprender a desenhar diagramas de implantao.
7.1 Introduo
Finalmente vamos conhecer a UML. O importante que alguns lem-
bretes permaneam at a ltima aula:
UML baseada em um conjunto de diagramas, portanto o mo-
delo no termina no primeiro diagrama, a no ser que se deseje
um aspecto bem reduzido do problema;
Cada diagrama da UML enfoca um aspecto distinto do problema,
ou seja, necessrio, a cada diagrama, um exerccio de abstra-
o diferente;
UML no uma linguagem de programao, mas de modelagem,
ou seja, aqui os testes no so sob os erros de execuo, mas os
de consistncia;
Por ltimo, todos os diagramas esto de alguma forma ligados,
portanto, o desenho de um diagrama tem que obrigatoriamente
ser coerente com o que j foi proposto (MATOS, 2002).
7.2 Um breve histrico
A UML uma linguagem criada com o propsito de permitir espe-
cifcaes, visualizaes e documentao de artefatos de sistemas. Ou seja,
permitido usar a UML para entender e manipular todos os elementos que
direta ou indiretamente infuenciam na construo do software (artefatos).
Dessa forma, possvel, tambm, a avaliao da modelagem do negcio ou
de quaisquer outros aspectos no necessariamente computacionais (MATOS,
2002).
No entanto, para chegar a essa especifcao, alguns detalhes his-
tricos foram importantes.
O primeiro foi a constatao de que o software possui valor estra-
tgico nos negcios de uma empresa. Ou seja, so necessrias tcnicas que
automatizem a produo do software, mas no perdendo de vista a arquite-
tura do sistema e do negcio.
Nesse contexto, o segundo detalhe histrico ocorria no fnal da
dcada de 80. O panorama do desenvolvimento de software, nesta poca,
vislumbrava a utilizao de vrias tcnicas e ferramentas baseadas na orien-
tao a objetos. Por causa dessa confuso, em 1994, dois importantes au-
tores imaginaram a fuso dos conceitos de seus mtodos com vistas criao
de um mtodo unifcado (Grady Booch e James Rumbaugh). Com a fuso de
seus mtodos (Booch e OMT - Object Modeling Technology de Booch e Rum-
baugh respectivamente), uma semente para a criao de um padro havia,
enfm, sido plantada (MATOS, 2002).
Um questionamento perdurava: o que fazer, ento, com os mto-
dos que ainda existiam?. Neste caso, o grande trunfo da idia de Booch e
Rumbaugh era que, criando um padro, a indstria participaria, opinaria e
iniciaria a construo de recomendaes. Este pensamento nos remete ao
terceiro importante detalhe histrico - a verso draft 0.8 da UML, idealizada
em outubro de 1995 (MATOS, 2002).
Muitas empresas ligadas informtica perceberam nessa nova pro-
posta uma importante alavanca para a melhoria da qualidade dos proces-
sos de software orientado a objetos. Dessa forma, um grupo importante de
empresas reunidas sob a OMG (Object Management Group) destacou pontos
importantes para essa nova recomendao e idealizou a primeira proposta
completa da linguagem a verso 0.9 da UML. Nesta verso, caractersticas
de outro mtodo foram includas (OOSE - Object Oriented Software Enginee-
ring de Ivar Jacobson) (MATOS, 2002).
Sob a proteo da OMG (a UML marca registrada da OMG), fcou
estabelecido (desde sua origem j estava defnido) que se trataria de uma
proposta no proprietria e aberta, ou seja, as empresas membro da OMG
teriam a liberdade de propor recomendaes e adendos especifcao ori-
ginal, permitindo que novas funcionalidades fossem assumidas. Neste con-
texto, a UML j est na sua verso 2.3 e suas modifcaes tm sido ampla-
mente discutidas em eventos e listas de discusso (MATOS, 2002).
7.3 Diagramas da UML
A proposta bsica (efetuada pela OMG) indica cinco nveis de abs-
trao:
Identifcar as funes do sistema e seus respectivos responsveis
por meio de um Diagrama de Caso de Uso:
Figura 5: Representao de um diagrama de caso de uso.
Fonte: Matos (2002).
Identifcar as estruturas mnimas de informao por meio de um
Diagrama de Classes:
Figura 6: Representao de um diagrama de classes.
Modelar e compreender o comportamento e o dinamismo das
classes por meio de Diagramas de Interao (Sequncia ou Co-
laborao).
Figura 7: Representao de um diagrama de sequncia.
Compreender os estados das execues, permitindo identif-
car o comportamento das classes por meio de Diagramas de
Estado e de Atividade.
Figura 8: Representao de um diagrama de estado.
Esquematizar o processo de implementao e o de implan-
tao, por meio dos componentes (hardware ou software)
previstos para o sistema, por intermdio de Diagramas de
Componentes e de Implantao.
Figura 9: Representao de um diagrama de componentes e de implantao.
7.4 Processo adotado neste caderno
A abordagem que ser apresentada neste caderno no nenhum
processo formal de software. Apenas por uma questo de melhor entendi-
mento e de percepo da relao existente entre os diagramas foi organiza-
da a distribuio (MATOS, 2002).
Os Casos de Uso so o primeiro tpico, haja vista a sua importncia
no princpio de qualquer processo de software - determinar o que o siste-
ma?
As classes atuam no apenas como complementaes aos casos de
uso, mas tambm podem ser desenhadas para que os diagramas de interao
possam validar suas estruturas (MATOS, 2002).
As interaes, representadas pelas sequncias e colaboraes, so
a melhor viso do funcionamento das operaes, ou os mtodos que sero
parte das classes (MATOS, 2002).
Estados e atividades permitem que eventos possam ser identifca-
dos e estudados, ou seja, pode-se ter uma noo completa dos estados ines-
perados ou at mesmo os esperados na execuo das operaes (MATOS,
2002).
Por fm, estudaremos formas de estruturar os programas e tambm
de arquitetar a organizao do hardware envolvido no sistema.
7.5 Casos de uso
Geralmente quando nos deparamos com a necessidade de iniciar o
modelo de um sistema, vem-nos mente o desejo de criar uma lista das fun-
es que o sistema precisa implementar. Existem tcnicas e ferramentas que
apiam essa iniciativa, no entanto do ponto de vista da orientao a objetos
essa no uma boa idia (MATOS, 2002). As funes tm o seu local bem
determinado - so parte de uma classe e so diretamente executadas pelos
objetos dessas classes. Se este no o ponto de partida, ento qual seria?
Na verdade, construmos sistemas computacionais para que usu-
rios pessoas possam utiliz-los ou para que eles sejam entrada ou sada de
outros sistemas. Portanto, o ponto de partida saber quem ou o que intera-
ge com o sistema (MATOS, 2002).
Os Casos de uso (do ingls Use Case) so utilizados para identifcar
as regras do negcio e so uma excelente forma de entender o ponto de vista
do usurio simplesmente pelo fato de que modela o que ele precisa executar
(MATOS, 2002).
Internamente, um caso de uso uma sequncia de aes que per-
meiam a execuo completa de um comportamento esperado para o sistema.
Este o ponto de partida de todo o processo, por isso necessrio
ter muito cuidado e no incluir detalhes demais. Um Diagrama de Caso de
Uso deve ser simples, porm no pode ser incompleto (MATOS, 2002).
7.5.1 Identifcando um caso de uso
A primeira coisa que precisa fcar clara a distino que existe
entre um processo de um Diagrama de Fluxo de Dados e um Caso de Uso.
Enquanto processos representam fuxos de dados e precisam, portanto,
de dados de entrada e geram dados de sada, um caso de uso apenas a
representao de uma funo, manipulada por uma entidade do sistema,
conhecida como Ator, ou seja, no nos interessa o fuxo dos dados, pois
essa transformao cabe aos mtodos da classe (e sero tratados no Dia-
grama de Interao). Nosso enfoque nesse momento no so as classes
ou as interaes (MATOS, 2002).
Figura 10: Representao de um diagrama de fuxo de dados e de um diagrama de
caso de uso.
Um caso de uso no deve se preocupar com o como das funes,
mesmo que este como seja apenas conhecer o fuxo de entrada e sada de
dados. importante encapsular aes que em conjunto sejam relevantes e
que de alguma forma infuenciam algo ou algum no sistema (MATOS, 2002).
Identifcar um caso de uso, portanto, um esforo que envolve:
descobrir um ator (algum que infuencia ou infuenciado pelo
sistema;
verifcar para esse ator aes das quais ele participaria;
agrupar tais aes de forma que possuam um nome em comum
(geralmente um. verbo no infnitivo).
7.5.2 Identifcando atores
O ator est relacionado a um papel. No contexto do sistema,
papel diz respeito viso dada ao sistema. Por exemplo, em um hospi-
tal teramos pelo menos quatro papis distintos: paciente, enfermeira,
mdico e o setor administrativo, haja vista que o tipo de informao que
um manipula jamais seria manipulado por outro (por exemplo, uma en-
fermeira no pode receitar nada a um paciente) (MATOS, 2002).
O que se pretende concluir com esta idia o seguinte: os dados
que uma enfermeira veria em seu formulrio do sistema seriam diferen-
tes dos dados que o mdico veria, ou seja, h o ator mdico e tambm
h o ator enfermeira, cujos casos de uso seriam distintos (MATOS, 2002).
7.5.3 Desenho de um diagrama de caso de uso
Um lembrete importante antes de iniciar qualquer modelo (diagra-
ma) entender o PORQU de estar desenhando aquilo. Como j conhecemos
o objetivo do Diagrama de Caso de Uso, imprescindvel que se tenha em
mente, desde j, a necessidade de identifcao de atores e suas respectivas
vises. No entanto, para que fque simples e tenhamos um roteiro que facili-
te, abaixo seguem alguns passos que devem ser observados na criao de um
Diagrama de Caso de Uso (MATOS, 2002).
Figura 11: Passos para a criao de um diagrama de caso de uso.
Um exemplo clssico est ligado s tarefas cotidianas de uma clni-
ca mdica.
Seguindo os passos indicados anteriormente, teramos:
Figura 12: Identifcao dos atores.
Este um passo relativamente simples. s vezes, bom fazer a se-
guinte comparao: enfm, quem vai fcar frente do computador operando
o sistema?. Esta pergunta no resolve por completo a identifcao de todos
os atores, no entanto permite que se deixe uma certa vazo para aquelas
responsabilidades que no foram cobertas (MATOS, 2002).
Figura 13: Identifcao dos atores e seus casos de uso.
Ao identifcar um ator, obviamente, percebe-se no que especifca-
mente ele atuar. Os passos 2 e 3 so teis para rotular o que cada ator far
ou responsabilizar-se- no sistema (MATOS, 2002).
Diagramas de Caso de Uso tambm so teis para a identifcao de
duas situaes relacionadas a qualquer sistema computacional.
SITUAO 1: muito comum que mais de uma funo do sistema
execute tarefas parecidas. Na fgura apresentada em seguida, espera-se que
em trs momentos distintos seja feita uma identifcao antecipada do pa-
ciente. Essa identifcao importante em todas essas situaes, pois, caso
contrrio, no se sabe quem est sendo atendido (MATOS, 2002). Os momen-
tos citados so os seguintes:
quando o paciente chega clnica e atendido pela enfermeira;
quando o paciente decide, enfm, marcar uma consulta;
quando o mdico avalia as condies do paciente mediante seus
sintomas e decide aplicar um tratamento (diagnstico).
Esta situao indica a existncia de uma tpica relao uses entre
casos de uso. O termo uses bem elucidativo: o caso de uso em questo usa
o caso de uso indicado (MATOS, 2002).
necessrio ressaltar que o caso de uso usado somente rele-
vante para ser representado se for compartilhado entre outros casos de uso.
Caso contrrio, estaramos apenas detalhando o comportamento esperado
de um nico caso de uso. Esse detalhamento, na verdade, vai ser analisado
apenas nos diagramas de interao e de classe (MATOS, 2002).
Figura 14: Identifcao de relaes entre casos de uso do tipo uses.
SITUAO 2: quando alguma recorrncia surge. Por exemplo, no
prximo diagrama percebe-se que pode existir a situao em que o paciente
nunca foi atendido nessa clnica (MATOS, 2002). Situaes inesperadas como
estas indicam a existncia de relaes do tipo extends.
Figura 15: Identifcao de relaes entre casos de uso do tipo extends.
7.5.4 Cuidados com os diagramas de caso de uso
A primeira ao que NO deve ser representada a incluso de
aspectos de implementao. Conforme j citado anteriormente, o como
deve ser deixado para outros nveis de abstrao, ou seja, para os diagramas
de classes e de interao (MATOS, 2002).
No entanto, o aspecto mais perigoso nesse momento seria o abuso
de uses e extends. A relao uses somente deve ser empregada quando
houver realmente um compartilhamento da funo indicada; caso contrrio,
estaremos abusando do detalhamento e produzindo um diagrama exagerada-
mente pormenorizado (MATOS, 2002).
Na Figura seguinte, a inteno do caso de uso Verifcar Histrico
de Tratamento uma ao que pode at ser bvia em qualquer consultrio
mdico, todavia, no se trata de algo que seria compartilhado por outros
casos de uso, ou seja, na verdade, uma parte do caso de uso Diagnosticar
Paciente (MATOS, 2002).
Figura 16: Cuidados na criao dos diagramas dos casos de uso.
O que convm ser salientado, portanto, que um Diagrama de
Caso de Uso deve ser o mais simples possvel. Detalhes devem ser deixa-
dos para outros diagramas, pois eles foram idealizados justamente com
este objetivo (MATOS, 2002).
No entanto, problemas complexos necessitam obviamente ser sim-
plifcados. Nesse caso, o importante permitir que a complexidade seja
gerenciada desde o incio. No caso especfco de Diagramas de Caso de Uso,
isso signifcaria produzir diagramas que ressaltem quais so as fronteiras do
negcio, tal como o diagrama seguinte:
Figura 17: Pacotes representando os subsistemas de um sistema para controle de
clnicas.
Nesse caso, cada subsistema poderia ser modelado por um dia-
grama de caso de uso particular. Por exemplo, o setor relacionado
enfermeira poderia ser visto como:
Figura 18: Diagrama de casos de uso do subsistema enfermeira.
E o subsistema do mdico seria modelado como:
Figura 19: Diagrama de casos de uso do subsistema mdico.
Em suma, Diagramas de Caso de Uso so ferramentas que nos
ajudam a enxergar o todo do sistema por intermdio da constatao das
responsabilidades que os usurios diretos do sistema tm (MATOS, 2002).
Outros aspectos, tais como: como cada caso de uso efetiva-
mente utilizado ou onde fcaro armazenados os dados que so utilizados
para fazer os casos de uso funcionarem. Esses so assuntos para discus-
so em prximos diagramas (MATOS, 2002).
7.6 Classes
A UML adequada para a modelagem de sistemas, cuja abrangn-
cia pode incluir sistemas de informao corporativos a serem distribudos
para aplicaes baseadas em Web e at sistemas complexos embutidos de
tempo real (MATOS, 2002).
Em qualquer aplicao orientada a objetos, classes so importantes
por quatro motivos:
Na verdade, so a real estrutura de dados, ou seja, so o objeti-
vo fnal para o incio da etapa de programao;
Dar ao programador a noo do domnio do problema;
Projetar uma soluo de implementao ao problema;
Traar perspectivas de escalabilidade ao sistema (onde e como o
sistema pode crescer em termos funcionais).
A princpio, para quem apenas possui experincia com a modela-
gem de dados, o Diagrama de Classes pode parecer uma simples coleo de
entidades mais complexas, no entanto esta uma idia errada, pois o mo-
delo de classes especializa-se na representao do COMPORTAMENTO e no
apenas dos dados (MATOS, 2002).
A construo de um Diagrama de Classes est, obviamente, base-
ada no conceito de Classe. Desse fato, pode-se concluir que Diagramas de
Classes so estticos, ou seja, devem apenas esboar o que interage e no
o que acontece quando as classes interagem. Portanto, para que se crie um
Diagrama de Classes, imprescindvel conhecer todos os conceitos do Pa-
radigma de Orientao a Objetos relacionados noo de classes (MATOS,
2002).
7.6.1 Identifcando classes
Uma classe uma abstrao de um conjunto de coisas que possuem
caractersticas e operaes em comum. Ou seja, uma classe um conjunto
de objetos (MATOS, 2002). No Paradigma de Objetos, um objeto uma uni-
dade fundamental. Somos forados a pensar nos nossos programas no como
um conjunto de registradores da memria, mas como realmente o mundo
real - um conjunto de coisas (que possuem atributos e operaes).
Partindo desse fato, h alguns aspectos que facilitam a identifca-
o de classes. O primeiro aspecto o fato de que uma classe surge da unio
de vrios objetos que possuem coisas em comum. Por exemplo, se em um
hospital percebe-se a importncia de que vrias pessoas pertenam a um
mesmo convnio e essas pessoas comeam a se tornar comuns e em grande
quantidade, alguma operao pode uni-Ias e mais, alguma funcionalidade do
sistema poder ser importante para esse conjunto de pessoas. Talvez esse
seja o caso de criar uma classe para pessoas conveniadas, em vez de apenas
ter um atributo diferenciador (MATOS, 2002).
As Classes so uma sntese de um conjunto de coisas. Essas coisas
podem ser facilmente identifcadas no contexto do problema, tais como:
Eventos, Papis, Recursos, Equipamentos, Sociedades, Responsabilidades,
etc.
bom salientar que uma classe no , efetivamente, uma entidade
(do modelo Entidade-Relacionamento). Uma entidade existe como um repo-
sitrio de dados e uma classe como um ENCAPSULAMENTO de atributos e
mtodos (MATOS, 2002).
Em UML, uma classe esquematicamente representada por:
Figura 20: Representao de uma classe.
A UML apenas uma linguagem, ou seja, apesar de existir uma
noo padronizada de que linguagens em informtica relacionam-se apenas
a Linguagens de Programao, a UML uma espcie de linguagem cuja in-
teno no passar por um processo de compilao e gerao de cdigo da
maneira como se conhece, mas servir de padro para facilitar a conduo do
processo de desenvolvimento do software (MATOS, 2002).
Os componentes da linguagem de modelagem unifcada (UML) so
importantes para a representao tanto conceitual quanto fsica do sistema.
Nessa aula, sero discutidos todos os recursos relacionados com o Diagrama
de Classes, porm muitos desses recursos tambm so aplicveis a outros
diagramas da UML (MATOS, 2002).
7.6.2 Relacionamentos
Uma classe no um ponto isolado e totalmente autnomo dentro
de um sistema de software. Para que uma classe obtenha sucesso e real-
mente execute suas tarefas, invariavelmente, aes vindas de outras classes
sero necessrias (MATOS, 2002).
Para os programadores de Java, C++, SmallTalk, Eifel e outras lin-
guagens orientadas ou baseadas em objetos (at mesmo Delphi ou Object
Pascal poderiam ser citados), a afrmao do pargrafo anterior no soaria
estranho.
Por exemplo:
H quatro tipos de relacionamento possveis em um modelo de UML:
Dependncias
Relacionamentos no qual a modifcao em um item superior (uma
superclasse, por exemplo) ocasiona modifcaes em itens inferiores. Por
exemplo, uma ao que passa a ser executada de uma forma diferenciada
em um item superior seria tambm executada de maneira diferenciada em
um item inferior (MATOS, 2002).
A representao para esse relacionamento indicada em seguida:
Figura 21: Representao de um relacionamento de dependncia.
H duas observaes relacionadas representao em seguida:
Todo mtodo, em qualquer classe, convencionalmente repre-
sentado por dois parnteses para indicar a presena ou no de
parmetros. Por exemplo, regular();
A adio de uma pessoa lista ou sua retirada indica a neces-
sidade de um objeto da classe Pessoa, ou seja, esses mtodos
dependem de como um objeto Pessoa est organizado.
A princpio, representar uma dependncia pode parecer desneces-
srio, mas extremamente importante conhecer o limite de classes uti-
lizadas na implementao, alm de dar um limite ao escopo do problema
(MATOS, 2002).
Herana
Uma forma de criar hierarquias entre classes e entender o esquema
de herana inerente a qualquer aplicao orientada a objetos entender as ge-
neralizaes. Uma generalizao um relacionamento do tipo um tipo de.
Ou seja, a classe inferior uma classifcao da classe superior (MATOS, 2002).
Uma classe generalizada (especializada) herda operaes e atribu-
tos da classe superior, ou seja, no necessrio refazer mtodos ou identi-
fcar atributos de classes generalizadas, pois eles j foram defnidos em um
nvel superior (MATOS, 2002).
No entanto, h situaes em que mtodos ou atributos podem ser
redefnidos. Esse caso, conhecido como polimorfsmo, permite que mtodos
ou atributos com a mesma assinatura tenham corpo distinto.
Em UML muitos aspectos do sistema podem ser representados: des-
de o software do sistema em si at aspectos de implementao e implanta-
o. Dessa forma, pode-se utilizar esse relacionamento para tambm repre-
sentar a generalizao entre componentes fsicos, tais como: pontos de uma
rede de computadores (MATOS, 2002).
Esquematicamente a herana representada da seguinte forma:
Figura 22: Representao de relacionamento de herana.
Associao/Agregao
A associao um relacionamento em que representada a cone-
xo de um objeto a outro. No entanto, existem duas facetas para essa cone-
xo. O primeiro aspecto diz respeito conexo entre um objeto e outro de
onde possa surgir um vnculo com ela (MATOS, 2002).
Essa associao representada por:
O termo assinatura
utilizado em UML (ou na
orientao a objetos)
para indicar como a
declarao/defnio
da interface de uma
classe (seus mtodos e
atributos). Por exemplo,
adicionar (Pessoa p)
a assinatura do mtodo
adicionar que indica
que sua execuo exige
este formato.
Figura 23: Representao de relacionamento de associao.
O termo Trabalha para com a respectiva direo representa o
vnculo criado entre os objetos das classes e permite imprimir um sentido
de navegao na leitura do diagrama (MATOS, 2002).
Este, no entanto, no o nico tipo de associao. O outro tipo,
e talvez o mais comum, a agregao que representa uma relao do
tipo todo/parte e tem propsitos diferenciados de uma associao como
a representada anteriormente. Enquanto em uma associao pura podem
ser identifcados os papis (que em determinados casos podem mudar),
por exemplo, entre pessoa e empresa podem existir os papis (emprega-
do e empregador). Em uma agregao, o que fca mais ntido o todo e
a parte. Alm desse fato, em uma agregao, ambas as classes esto no
mesmo nvel, no havendo distino entre o papel mais importante e o
papel coadjuvante (MATOS, 2002).
importante ressaltar que esse tipo de agregao conhecido
como agregao fraca ou agregao simples, pelo fato de esse relaciona-
mento no interferir no tempo de vida de suas partes, nem de haver
um signifcado de navegao importante, como havia no exemplo ante-
rior (MATOS, 2002).
O exemplo seguinte pode soar estranho, mas o intuito identif-
car a Escola como sendo um todo, formado no de tijolos, mas de partes
quais sejam os alunos e os professores. Esta no uma viso potica do
problema, mas possvel que a realidade do sistema modelado indique
essa situao (MATOS, 2002).
Figura 24: Representao de relacionamento de agregao.
Relacionamentos como as agregaes tornam-se complexos,
caso informaes adicionais no sejam identifcadas, por exemplo, ser
que existe alguma restrio quantitativa para o relacionamento? Este
tipo de questionamento, na verdade, pode ser adequadamente comple-
mentado pela multiplicidade (MATOS, 2002). Por exemplo:
Figura 25: Representao de multiplicidade entre relacionamento.
Onde se l: cada pessoa reside em um municpio e apenas nes-
te, no entanto em cada municpio podem residir vrias pessoas.
H uma variante mais forte da agregao, em que cada classe que
uma parte do todo tambm se torna um componente fsico do todo. Esses
tipos de agregao so representados por um losango cheio (MATOS, 2002).
Por exemplo:
Figura 26: Representao de relacionamento de agregao forte.
Uma instncia da classe Endereo torna-se, na verdade, parte de
alguma instncia da classe Pessoa, pois o endereo tambm uma caracte-
rstica de qualquer pessoa (MATOS, 2002).
7.6.3 Extenses e mecanismos
possvel representar, em diagramas da UML, informaes que
auxiliam no processo de modelagem. Enquanto existem recursos que so
apenas extenses aos recursos que j existem, outros so mecanismos cuja
funo dar maior clareza ao modelo (MATOS, 2002).
Nesta aula estudaremos os seguintes recursos: esteretipos, inter-
faces, pacotes, restries e notas.
Esteretipos
Esteretipo o tpico recurso que se parece com a expresso
carta embaixo da manga ou o famoso plano B. Ou seja, esteretipos
podem ser utilizados para indicar um comportamento que se espera para
determinado componente. Poderamos dizer que um esteretipo um
metatipo, ou seja, aquele tipo que seria usado para ajudar na defnio
de outro tipo (MATOS, 2002).
Agregao forte uma
prtica muito perigosa
- se endereo um
atributo de Pessoa,
ento deveria ter
sido modelado como
atributo e no como
outra classe, a no
ser que o Endereo
seja importante, no
contexto, como uma
classe parte.
Existem alguns esteretipos predefnidos, tais como: use (em
relacionamentos de casos de uso) e abstract (para indicar classes abstra-
tas). E alm desses, esteretipos podem ser criados e incorporados ao
modelo em desenvolvimento. Todas as ferramentas CASE de desenho de
UML incorporam tanto os esteretipos prontos como permitem a defni-
o de novos esteretipos (MATOS, 2002).
Em suma, esteretipos so recursos que agilizam a defnio
de algum componente, permitindo que comportamentos sejam incorpo-
rados. Ou seja, se a palavra extends aparece, um conjunto de comporta-
mentos j fca subentendido (MATOS, 2002).
A presena de um esteretipo sempre acompanhada dos smbo-
los << extends >>, como em << uses >>.
Esteretipos so recursos utilizados em todos os diagramas da
UML, no estando restritos apenas s defnies de classe (MATOS, 2002).
Interfaces
Existem classes cuja existncia puramente virtual, ou seja, exis-
tem apenas para indicar que a interface de determinado objeto deve seguir.
Em UML, a representao dessas interfaces feita pela indicao de um es-
teretipo <<type>>. A insero do esteretipo importante, pois fca claro
que a interface no possuir atributos e os mtodos defnidos so apenas as-
sinaturas, cuja implementao dar-se- em outras instncias (MATOS, 2002).
Figura 27: Representao de esteretipo <<type>>.
Parece simplrio demais, mas uma interface exime o programador
da chata tarefa de ter que pesquisar tudo o que um determinado objeto
deveria fazer. Obviamente que nem todas as situaes podem ser aplicadas,
por exemplo, no caso mostrado anteriormente, espera-se que toda mquina
de lavar roupas faa as tarefas indicadas, com o perigo de haver mquinas
muito distintas (MATOS, 2002).
Pacotes
Uma analogia que soa estranho, mas que efcaz para compreen-
der este conceito entender o que fazem os empacotadores em supermer-
cados. Todos os produtos que so similares vo para os mesmos pacotes (ou
sacolas). O objetivo simples: organizar, facilitar o transporte dos produtos
(MATOS, 2002).
Em um Diagrama de Classes, pacotes podem ser criados para dimi-
nuir a complexidade do problema: classes que possuam caractersticas em
comum podem ser includas em pacotes separados, tornando a manuteno
e at mesmo as implementaes menos complexas (MATOS, 2002).
Figura 28: Representao de pacotes.
O que se prope neste exemplo a distribuio da complexidade
do problema em dois pacotes. Cada pacote implementa uma viso diferen-
ciada do problema (MATOS, 2002).
Restries
Dentro de um modelo, as restries so regras que permitem expli-
citar o comportamento esperado de alguns relacionamentos. As restries
podem ser descritas utilizando descries informais ou por meio de uma
linguagem especfca para a descrio de restries - OCL (Object Constraint
Language) (MATOS, 2002).
Exemplo em que representao da restrio no utiliza formalismos.
Figura 29: Representao de restries.
O prximo exemplo mostra a utilizao de OCL que complemen-
ta a indicao de que h funcionrios que so chefes e so objetos cujo
atributo tipo possuir o valor chefe (MATOS, 2002).
Figura 30: Representao de restries com utilizao de OCL.
Notas
Assim como em qualquer linguagem de programao, possvel
fazer comentrios que facilitem o entendimento do cdigo. Em UML, este
recurso tambm existe em todos os diagramas (MATOS, 2002).
Por exemplo:
Figura 31: Representao de notas.
Alm de ser um simples comentrio, notas podem conter estere-
tipos que no caso do exemplo j determinam que tipo de comportamento
a nota possuir. No exemplo, trata-se da identifcao dos requisitos que o
atributo possui para que possa ser manipulado (MATOS, 2002).
7.6.4 Desenho de um diagrama de classes
No basta sabermos identifcar o que uma classe ou como elas se
relacionam. Atributos e mtodos so, na verdade, a parte mais importante
na criao de uma classe (MATOS, 2002).
Outros diagramas, tais como: o Diagrama de Interao e o de Esta-
do, facilitam a identifcao dos atributos e dos mtodos; no entanto, nesta
aula vamos iniciar o trabalho de fltrar essas caractersticas que devem exis-
tir em uma classe. Para tanto, continuaremos nos reportando Clnica Mdi-
ca que vem sendo discutida nos exemplos, agora por meio de uma descrio
textual (MATOS, 2002).
Suponha que os trabalhos da Clnica Mdica iniciem com a chegada
de um Paciente. O provvel paciente dirige-se Enfermeira que est na por-
taria e se identifca lhe dizendo seu Nome e o nmero de algum Documento.
A Enfermeira verifca se o Paciente j foi atendido em alguma Data anterior.
Caso seja constatado que o Paciente nunca foi atendido na Clnica, ele for-
nece Informaes Pessoais Enfermeira que efetua o seu cadastramento.
Aps esse passo, o Paciente est apto a marcar uma Consulta, caso seja do
seu interesse. A Enfermeira precisa se organizar e identifcar uma Data e
um Horrio em que a Consulta possa ser marcada. O Paciente, ento, est
apto a entrar na sala do Mdico, que previamente muniu-se de Informaes
do Paciente. Neste momento, o Paciente precisa esboar ao Mdico todos os
Sintomas, Problemas e Restries que o levaram Clnica. O Mdico, ento,
avalia essas Informaes da Sade do Paciente e efetua um Diagnstico que
pode ser seguido de um Pedido de Exames, alm de um Receiturio de Me-
dicamentos, alm da indicao de um Retorno. Ao sair da sala do Mdico, o
Paciente precisa informar Enfermeira os Dados do Pagamento que podem
ser feitos em dinheiro ou por algum Convnio Mdico (MATOS, 2002).
Analisando os nomes que aparecem em maisculo neste texto, po-
demos identifcar classes e atributos peculiares de algumas classes. Dessa
forma, um primeiro modelo de classes poderia ser feito da seguinte maneira:
Figura 32: Representao das classes identifcadas.
Este Modelo de Classes inicial proposto apresenta algumas falhas
que, quase sempre, passam despercebidas. Esse trabalho inicial de avaliar as
classes potenciais e seus atributos essencialmente semntico, ou seja,
necessrio avaliar se cada item foi colocado no seu devido lugar. Aps chegar
a uma concluso, passaremos a discutir os relacionamentos entre as classes
(MATOS, 2002).
Um problema que pode ser identifcado neste modelo trata dos
atributos. Alguns atributos so imprescindveis, mas esto prejudicando a
modelagem (MATOS, 2002). Por exemplo:
Figura 33: Representao dos problemas e solues no contexto dos atributos.
Para complementar o modelo proposto, os atributos em questo
sero direcionados para os locais corretos e os relacionamentos sero criados
da seguinte maneira (MATOS, 2002):
Figura 34: Representao do diagrama de classes proposto.
Ainda no possumos o modelo defnitivo, mas podem ser discu-
tidas duas dvidas (MATOS, 2002):
1) Como tratar a incluso de mtodos?
2) Exame e doena parecem ter uma existncia dependente da
classe Diagnstico. No seriam os relacionamentos entre essas classes do
tipo dependncia ou de agregao?
As respostas a essas dvidas complementam o modelo que exi-
bimos como exemplo (MATOS, 2002). As respostas so:
1) Mtodos podem at ser includos nesse momento, mas pre-
cisam ser validados (confrmados). A validao ocorre nos Diagramas de
Sequncia e de Estados que sero discutidos posteriormente; no entan-
to, conveniente ressaltar que dois mtodos so comumente sugeridos.
Mtodos get (obter) e set (confgurar) so sugeridos por se tratar de uma
ao muito comum aos atributos. Obter o valor de um atributo (get)
saber qual o seu valor atual, e confgurar o valor de um atributo (set)
atribuir-lhe algo.
2) No h necessidade de representar agregao ou dependncia.
Basta confrontar com situaes que ocorrem em outros contextos, por exem-
plo, um hospital ou at mesmo se tratar-se de um diagnstico em clnicas de
vrias especialidades (psicologia, odontologia e at medicina alternativa).
Diagnsticos no precisam ter, necessariamente, pedidos de exames ou o
paciente pode no ter tido doenas no passado e alm desse fato, a maneira
como o diagnstico tratado no infuencia nos exames (um exame de raio X
continuar sendo o mesmo, apesar de um mdico mudar sua rotina de diag-
nosticar um paciente). Associar um exame e um histrico de doenas a um
diagnstico mdico no signifca construir um todo.
7.7 Interaes
Objetos so entidades dinmicas, ou seja, no possvel ns ima-
ginarmos os objetos como depsitos estticos de dados, mas sim como um
ponto de referncia do processo de execuo das tarefas. Neste sentido,
necessria uma forma de modelar como esse comportamento dinmico
conduzido (MATOS, 2002).
Programas orientados a objeto so, na verdade, constantes tro-
cas de mensagens. Em conjunto, essas mensagens colaboram na obteno
de um determinado propsito. Os diagramas de interaes so, portanto, a
representao do comportamento dinmico que uma sociedade de objetos
necessita ter para que a execuo de alguma tarefa possa ser acompanhada
(MATOS, 2002).
Estudaremos nesta aula duas formas de representar interaes, e
como essas representaes podem ser teis no entendimento do processo de
desenvolvimento de um software.
7.7.1 Por que devemos representar as interaes
Representar interaes permitir que saibamos como um deter-
minado conjunto de operaes permitir que o que se deseja do sistema
seja realmente executado. muito improvvel que apenas a constatao
emprica de que haja estruturas de dados sufcientes seja razovel para se
confrmar exatido na execuo de tais operaes (MATOS, 2002).
De certa forma, os diagramas de interao so, na verdade, ferra-
mentas de constatao. possvel validar um Diagrama de Classes, ou at
mesmo complement-Io pela anlise de um Diagrama de Interao. O resul-
tado um processo de software menos sofrido e menos emprico (MATOS,
2002).
Percebemos ento que representar interaes um misto de vali-
dao e complementao. Validao, porque possvel constatar-se que a
construo de outros diagramas est realmente de acordo com o modelo que
vem sendo proposto, e complementao, pois cada possvel falha visualizada
pode ser corrigida conforme sua validao (MATOS, 2002).
Interaes indicam que um conjunto de objetos esteja se comuni-
cando. Essa comunicao ocorre por meio da troca de mensagens. Mensa-
gens so, na verdade, uma invocao a alguma tarefa previamente defnida
para ocorrer em algum objeto (MATOS, 2002). Esquematicamente, uma men-
sagem pode ser identifcada como:
Figura 35: Representao de interao atravs de mensagens.
A fgura 35 representa a vontade que um objeto da classe Cliente
chamado cl001 possui de se comunicar com um objeto da classe Conta, espe-
cifcamente o ct001. Nesse momento, o objetivo de cl001 mudar o ESTADO
de ct001, ou seja, da conta em questo retirado o valor de R$1.560,00. A
mensagem surgiu porque o cliente, representado pelo objeto cl001, decidiu
retirar essa quantia d conta em questo, ou seja, esse foi um momento de
ocorrncia de uma interao entre dois objetos (MATOS, 2002).
Podemos dizer ento, que sem a representao de interaes, a
modelagem dos sistemas torna-se incompleta, haja vista que no se conhece
como uma tarefa est sendo executada, e tambm no se conhece como um
objeto dispara e fnaliza uma tarefa. Essa representao feita atravs dos
Diagramas de Interao e conforme identifcaremos, atravs de dois tipos de
diagramas: Diagramas de Colaborao e Diagramas de Sequncia (MATOS,
2002).
7.7.2 Tipos de diagramas de interaes
Por meio de diagramas de interao podemos observar como os
objetos esto relacionados. Questes como o entendimento das associaes
entre as classes de um diagrama de classes fcam mais ntidas ao identifcar
como um objeto realmente se comunica com outro (MATOS, 2002). Por exem-
plo, analisemos a situao exposta no diagrama de classes da fgura 36.
Figura 36: Representao de interao atravs da associao entre as classes.
Mensagens so, na
grande maioria das
vezes, executadas
entre objetos. No
faz sentido, a priori,
que classes troquem
mensagens. Neste caso,
h uma lembrana que
deve ser feita: a sintaxe
usada na representao
para indicar que se
trata de um objeto
que est indicado pelo
sublinhado e pelas
inicias em minsculo,
por exemplo:
cliente:Cliente indica
que cliente (com c
minsculo) objeto da
classe Cliente (com C
maisculo).
possvel que em algum instante da vida de um objeto da classe
Paciente ocorra o seguinte:
Figura 37: Representao de interao atravs de mensagens.
O que ocorre nesta representao, que se trata de um trecho de
um diagrama de sequncia, que um objeto da classe Paciente, denomina-
do pac, teve a necessidade de marcar uma consulta. Essa ao foi traduzida
em uma mensagem, ou seja, o pedido de execuo de um mtodo em outra
classe, neste caso, no objeto cons, da classe Consulta. Isso constata a neces-
sidade de uma associao entre as classes Paciente e Consulta no diagrama
de classes (MATOS, 2002).
Na verdade, este no o nico tipo de mensagem que objetos tro-
cam. Quando se trata de uma interao, podemos ter as seguintes mensa-
gens:
Automensagens: quando as mensagens so enviadas para o pr-
prio objeto que originou o pedido (MATOS, 2002). Como exemplo tem a
fgura 38, que retrata uma mensagem que necessita ser executada no
mesmo local de onde se originou a requisio.
Figura 38: Representao de interao atravs de automensagens.
Mensagens de destruio (destroy): quando se trata de efeti-
vamente desativar a sequncia de aes de um objeto. Essa destruio
pode ser ativada por um objeto distinto ou pelo mesmo objeto. Esse tipo
de mensagem pode ser acompanhado do esteretipo destroy (MATOS,
2002).
Figura 39: Representao de interao atravs de mensagens <<destroy>>.
Fonte: Matos, 2002.
O uso do esteretipo <<destroy>> pode ser substitudo pela repre-
sentao da fecha com o acompanhamento de um smbolo de x, conforme
visualizado na fgura 40.
Figura 40: Outra forma de representao de interao atravs de mensagens
<<destroy>>.
Fonte: Matos (2002, p.).
Mensagens de criao (create): de outro lado, mensagens podem
exigir a criao de um objeto. Por exemplo:
Figura 41: Outra forma de representao de interao atravs de mensagens
<<create>>.
Fonte: Matos (2002, p.)
Esta situao apresentada pode parecer estranha, mas muito
simples de interpretar: um objeto, para dar continuao a alguma tarefa
iniciada, precisou criar um objeto. Esse objeto em questo, no instante,
no possua identifcao, mas, bastava ser indicado que se tratava de
uma instncia da classe Diagnstico. A leitura que pode ser feita da fgura
, portanto, que o mdico (objeto med) precisou fazer um novo diagns-
tico de paciente (MATOS, 2002).
O conhecimento do comportamento das mensagens importan-
te para o entendimento dos diagramas de interao (MATOS, 2002). Os
diagramas discutidos nesta aula podem seguir dois enfoques distintos:
baseando-se na ordem temporal das mensagens;
baseando-se no contexto e na familiaridade de um conjunto de
objetos.
Em particular, a ordem temporal representada pelo Diagrama
de Sequncia e o outro enfoque representado pelo Diagrama de Cola-
borao (MATOS, 2002).
7.7.3 Diagrama de colaborao
A primeira viso de interao que teremos a colaborao. O dia-
grama de colaborao fxa a ateno em como os objetos esto se organizan-
do para realizar uma tarefa (MATOS, 2002). como se uma cadeia de ajuda
fosse realizada com a inteno de que um desejo fosse alcanado.
Na troca de mensagens, em um diagrama de colaborao, cada ob-
jeto possui uma identifcao esperada pelos outros objetos (MATOS, 2002).
Na verdade, o que se usa o nome que os outros utilizam para identifc-Io.
Visualizamos esta afrmao da seguinte maneira:
Figura 42: Representao de diagrama de colaborao.
Fonte: Matos, 2002.
Estudaremos agora os tipos de mensagens em diagramas de interao:
Mensagens sncronas: aquelas em que o objeto remetente espera
o destino para fnalizar sua tarefa para continuar a execuo. Essa espera
deve-se ao fato de que o destino possui uma resposta sem a qual o remeten-
te no pode continuar. O desenho de uma seta, seja no diagrama de cola-
borao, seja no diagrama de sequncia, indica que h sincronismo (MATOS,
2002).
Mensagens assncronas: nesse tipo de mensagem, o objeto reme-
tente no precisa esperar pelo destino. A linha de execuo pode continuar
sem que haja uma resposta ao remetente. Mensagens assncronas esto, na
grande maioria dos casos, relacionadas a problemas de tempo real, em que
pode ocorrer paralelismo de execuo (MATOS, 2002).
As mensagens podem ser representadas da seguinte forma:
Figura 43: Representao de mensagens.
Fonte: prpria.
7.7.4 Diagrama de sequncia
Os diagramas de sequncia descrevem o comportamento dos obje-
tos do sistema, que se relacionam pela troca de mensagens em interaes
sequenciais no tempo, enfatizando, portanto, o ordenamento temporal das
aes. Cada diagrama mostra um cenrio, isto , um conjunto de mensagens,
ordenadas no tempo, com um determinado objetivo. Assim, para a elabora-
o de um diagrama de sequncia, importante que os objetivos do sistema
j tenham sido descritos nos cenrios dos casos de uso (SBROCCO, 2011). Os
diagramas de sequncia devem ser construdos conforme determinadas con-
venes, descritas a seguir:
Linhas verticais: utilizadas para representar e separar os obje-
tos envolvidos. Elas devem apresentar uma informao comple-
mentar representada por um retngulo, utilizada para indicar o
tempo de vida dos objetos.
Setas horizontais: para representar as mensagens passadas en-
tre os objetos. As setas tambm podem receber rtulos, que
correspondem aos nomes das operaes.
Anotaes: as representaes dos elementos de um diagrama
de sequncia pode ser complementadas e esclareci das por meio
de anotaes.
Os casos de uso so a base para o desenvolvimento dos diagramas
de sequncia, pois pelo estudo da lgica dos casos de uso que podemos
organizar roteiros que representam seu desdobramento. Quando observamos
que existem diferentes caminhos lgicos que podem ser seguidos, convm
criar diagramas de sequncia separados para cada um dos caminhos (SBROC-
CO, 2011).
7.7.5 Desenho de um diagrama de sequncia
O ponto de partida uma anlise dos casos de uso que foram cria-
dos. Os diagramas de sequncia so facilmente criados a partir dessa anlise.
Este seria o primeiro e mais importante passo. Para facilitar, um resumo de
passos que podem ser seguidos apresentado (MATOS, 2002).
Passo 1: transforme um caso de uso em uma descrio algortmica.
O objetivo identifcar todos os passos envolvidos nesse caso de uso;
Passo 2: avalie quais classes podem fazer parte desse caso de uso.
Esta uma anlise que pode se basear tanto na observao dos nomes que
apaream na descrio, como na observao dos atores;
Passo 3: para cada passo que foi includo na descrio do passo 1,
escolha uma classe que seja responsvel por fazer a tarefa indicada;
Passo 4: se a tarefa for muito complexa para apenas um objeto da
classe executar, divida-a. O objetivo tanto perceber se haver outras clas-
ses no modelo, como se o caso de uso no est complexo demais.
Para facilitar, continuaremos utilizando o exemplo da clnica mdi-
ca. Em especial, o diagrama de casos de uso, apresentado na fgura 16. O
caso de uso eleito para ser avaliado nos passos de 1 a 4 propostos anterior-
mente foi Marcar Consulta. Esse caso de uso tem como ator responsvel
a Enfermeira, mas, obviamente, o estmulo que permite o incio de tudo
a chegada do paciente e seu respectivo interesse em ser atendido. Ento,
vamos iniciar, descrevendo os passos desse caso de uso (MATOS, 2002).
Passo 1: descrio do caso de uso em linguagem algortmica.
1. Paciente relata interesse em marcar uma consulta (este o estmulo en-
dereado enfermeira).
2. A enfermeira precisa verifcar se o paciente j est cadastrado na clnica.
Para isso, so pedidos os seus dados pessoais. Caso ainda no seja cadastra-
do, seu cadastro requisitado.
3. Verifcadas as informaes do paciente, a enfermeira verifca se h vagas
para a consulta. Essa verifcao consiste da constatao de data e horrio.
4. Caso haja vagas, a consulta enfm marcada. Caso contrrio, o paciente
recebe uma negativa.
Passo 2 e 3: avaliao das classes participantes.
1. A melhor estratgia tomar cada passo da descrio anterior e eleger
classes (MATOS, 2002).
2. Enfermeira - neste ponto, apenas a Enfermeira estaria participando, pois
a receptora do estmulo inicial.
3. Enfermeira e Paciente - a classe Enfermeira participa, pois a estimula-
dora de uma verifcao na classe Paciente que, por sua vez, tambm deve
participar, pois a classe que possui as informaes que esto sendo verif-
cadas e/ou cadastradas.
4. Enfermeira e Consulta - a classe Enfermeira recebe, da classe Paciente,
uma resposta que d incio s atividades de marcao da consulta, portanto
a classe Consulta tambm participa dessa etapa.
Paciente e Consulta - as informaes para a consulta so checadas.
Caso haja espao na agenda da clnica, a classe Consulta recebe um estmu-
lo para agendar a consulta; caso contrrio, a classe Paciente informada.
Nesse momento, o processo de marcao de consulta termina, com ou sem
sucesso. Se no houve sucesso, todo o processo pode se repetir com um novo
estmulo para a Enfermeira (MATOS, 2002).
Passo 4: avaliao da complexidade.
A complexidade no facilmente medida apenas com a consta-
tao textual. Nesse instante, necessrio que se construa um primeiro
modelo. Conforme o comportamento esperado nos passos 2 e 3, um modelo
inicial seria o representado na fgura 44.
Figura 44: Representao de diagrama de sequncia proposto.
7.7.6 Diagrama de estados
Normalmente, um sistema aberto reage a estmulos provenientes
de fora dele ou ainda estmulos temporais por ele mesmo desencadeado.
Essa reao pode originar respostas externas ao sistema. Essa dinmica exis-
tente nos sistemas fruto da colaborao entre objetos, os quais estaro em
determinado estado em um certo momento no tempo (TONSIG. 2003).
O Diagrama de Estados usado para mostrar os possveis estados
dos objetos de uma classe. A mudana de um estado para outro chamada
de transio de estados. Os eventos do diagramas de estados causam uma
transio de um estado para outro e as aes resultam na mudana de esta-
do. Cada diagrama de transio de estados est associado a uma classe ou a
um diagrama de transio de estados de um nvel mais alto (TONSIG, 2003).
O incio de um diagrama de estados indicado pelo chamado esta-
do inicial, cuja representao grfca um crculo preenchido. Na verdade,
ele no expressa um estado especfco do objeto da classe, indica apenas
o incio do diagrama. Na sequncia, se conecta o primeiro estado real com
uma transio, rotulado ou no. Em cada diagrama de estado h somente um
estado inicial (TONSIG, 2003).
A notao grfca de um estado inicial mostrada na fgura 45.
Figura 45: Representao do estado inicial de um diagrama de estado.
Fonte: Tonsig, 2003.
Um estado demonstra uma situao no tempo de algum aspecto
do sistema sobre o qual existe interesse de controle. Durante a vida de um
objeto, pode vir a existir controle sobre vrias situaes, cada qual podendo
assumir diversos estados possveis no tempo. Um objeto permanece em um
estado por um tempo fnito (TONSIG, 2003).
A notao grfca e um exemplo de estado so mostrados na Figura 46.
Figura 46: Representao de um diagrama de estado.
Fonte: Tonsig (2003).
O estado fnal representa o trmino do ciclo previsto de controle
para mudanas de um dos aspectos do sistema (TONSIG. 2003). Na Figura
47 verifca-se a representao grfca do estado fnal, mediante dois
crculos, sendo o interno totalmente preenchido.
A mudana de um estado para outro chamado de transio de
estados. Trata-se de relacionamento entre dois estados (TONSIG. 2003).
Para o objeto passar de um estado para outro, necessrio dois me-
canismos: condio e ao. A condio, se existir, dever ser satisfeita
para que a ao seja executada.. Essa ao a responsvel pela transi-
o dos estados.
Figura 47: Representao de transio de estados.
Fonte: Tonsig (2003).
7.7.7 Diagrama de atividades
Do ponto de vista da representao de aspectos dinmicos do sis-
tema, dois diagramas possuem caractersticas muito comuns: o diagrama de
atividades e o diagrama de estados.
Atravs deste diagrama vamos ter uma viso da representao
do fuxo de operaes (MATOS, 2002).
Antes de mais nada necessrio diferenciar atividade de estado.
Atividade: trata-se de algo que est em execuo, portanto no
fnalizado. Quando uma atividade termina, alguma ao ocorre (MATOS,
2002).
Pelo conceito exposto, podemos traar algumas diferenas entre
estado e atividade:
em uma atividade a ao a fnalizao, ou seja, no h
aes internas, assim como ocorre em um estado;
quando se fala em um estado, representamos algo que j foi
atingido e cujo interesse questionar o que ocorre quando
ele alcanado;
uma atividade , na verdade, uma operao obviamente relacio-
nada a um objeto. Enquanto um diagrama de estados enfatiza os
fuxos das operaes em uma classe, um diagrama de atividades
relaciona as atividades entre classes.
A ltima diferena a mais importante. Aqueles que vem o diagra-
ma de atividades pela primeira vez, em no conhecendo essa diferena, vo
imaginar que a mesma coisa que o diagrama de estados. Na verdade, pode-
-se considerar que os recursos so semelhantes, mas no so efetivamente
os mesmos (MATOS, 2002).
Desenhamos um diagrama de atividades com a inteno de deixar
claro o que acontece na cooperao entre os objetos de classes distintas,
mas no com o enfoque de um diagrama de sequncia, cujo foco so as men-
sagens trocadas e as respostas a esse estmulo. Grady Booch e outros autores
costumam salientar que o diagrama de estados ressalta o aspecto interno do
que ocorre em um diagrama de interao (MATOS, 2002).
Outra observao til aos modelistas o fato de que um diagrama
de atividades pode ser visto como um verdadeiro fuxograma estendido -
uma viso do fuxo das operaes, decises e fnalizaes (MATOS, 2002).
Para estudarmos a criao de um diagrama de atividades e seus
respectivos conceitos, apresentamos o seguinte problema: a marcao de
uma consulta (MATOS, 2002).
Figura 48: Representao de um diagrama de atividades.
Apesar de este diagrama conter as mesmas operaes do diagrama
de sequncias do captulo 7.7.4, sua semntica diferente. Sua representa-
o indica como as atividades so conduzidas at que se chegue ao objetivo
fnal - agendar uma consulta (MATOS, 2002).
Algumas representaes na fgura 48 podem ter causado estranhe-
za, mas vamos explic-las:
A presena de estados
Os estados inicial e fnal ainda so importantes, pois um diagrama
de atividades representa um fuxo de operaes, ou seja, necessrio indi-
car o incio e o fm delas (MATOS, 2002).
A presena de uma reta escura ( ___________ )
Trata-se de uma barra de sincronizao. A funo dessa barra
representar momentos em que ocorre uma bifurcao ou unio do fuxo. Por
exemplo, Cadastrar Paciente e Verifcar Paciente so atividades que levam
mesma atividade - Checar Agenda. conveniente ressaltar que se trata de
um fuxograma estendido, portanto h momentos em que o fuxo bifurcado
e unido (MATOS, 2002).
A presena de um smbolo de deciso
Mais um motivo para considerar o diagrama de atividades distinto
do diagrama de estados. Em um diagrama de estados o foco no est na
identifcao de caminhos alternativos e nem na unio de caminhos. Devido
a essa preocupao, diagramas de atividade so considerados extenses a
fuxogramas, da a importncia de um smbolo como o de deciso (MATOS,
2002).
Na verdade, essas no so as nicas representaes importantes em
um diagrama de atividades. possvel indicar as classes envolvidas no fuxo.
Essa representao d-se por meio de raias (ou swinlanes).
Figura 49: Representao de um diagrama de atividades e suas raias.
Fonte: Matos, 2002.
Conforme se observa, as raias so, na verdade, uma diviso de ta-
refas, facilitando assim o entendimento de como as atividades esto distri-
budas em um modelo de classes (MATOS, 2002).
Enfm, o que se observa que a construo de um diagrama de
atividades parte de duas fontes: ou da avaliao dos casos de uso e/ou da
avaliao dos atores que participam do sistema (MATOS, 2002).
7.8 Componentes de software
Muitos programadores j devem ter percebido a seguinte consta-
tao: muitas tarefas pequenas constantemente reaparecem no desenvol-
vimento de um novo software, mas geralmente em pontos e situaes di-
ferentes. Um componente de software seria o elemento que surgiria com a
implementao da interface esperada para esse objeto novo, diminuindo
a sensao de que o mesmo trabalho seria feito novamente (MATOS, 2002).
Apesar de um componente assemelhar-se muito a um objeto de
uma classe, pode-se diferenciar um componente de um objeto por suas ca-
ractersticas adicionais quanto ao reuso de cdigo (e de projeto) (MATOS,
2002).
Componentes so desenvolvidos baseando-se na juno de classes.
Na verdade
,
so a soluo para um determinado problema, cujas interfaces
so conhecidas, no entanto, ainda no haviam sido implementadas (MATOS,
2002).
Componentes podem atuar em conjunto. Neste caso, precisam ser
empacotados, pois a implementao de vrias interfaces individuais implica
no esqueleto e um sistema completo (MATOS, 2002).
Modelar um componente em UML prover recursos de gerencia-
mento da confgurao e verso do software. Ou seja, como cada componen-
te e software possuem uma relao intrnseca com outros, bem provvel
que se criem dependncias entre componentes. Dessa forma, qualquer mo-
difcao pode ser previamente avaliada. Obviamente que o impacto dessas
modifcaes pode ser simulado e o resultado fnal validado (MATOS, 2002).
Alm dessa viso de projeto, um componente, enfm, pode ser vis-
to como um elemento cuja interface (a viso do seu conjunto de operaes
e dados) mutvel. Essa mutabilidade gerenciada pelos elementos que
compem o componente e permitem que ele seja reutilizado (MATOS, 2002).
7.8.1 Diagrama de componentes
Escrever cdigo-fonte um trabalho artesanal. E no difcil cons-
tatar-se esse fato. Um programador um indivduo criativo; suas idias fuem
no escopo de um mundo - o mundo dos bits e bytes. A idealizao de uma
soluo um caminho similar ao de um pintor, at que se chegue arte fnal,
no se distanciando, obviamente, da realidade em que a soluo do proble-
ma vai repousar (MATOS, 2002).
Construir um diagrama de componentes criar um roteiro para essa
tempestade de criatividade (MATOS, 2002). Obviamente que poderamos
ser questionados pelo menos de trs formas:
Como criar um roteiro de criatividade para algum sendo que
este um trabalho individual?
Como algum externo pode gerar um roteiro criativo para outra
pessoa?
Por que criar um roteiro criativo se isso pode limitar a inventivi-
dade de uma pessoa?
Diante dessas dvidas, vamos esclarecer no que realmente se tra-
duz um diagrama de componentes.
Um diagrama de componentes a relao de todos os itens de
software que colaboram na confeco do produto fnal (MATOS, 2002). Nes-
te diagrama, as maneiras como os elementos se relacionam e dependem
permitem que o reuso de cdigo e empacotamento de componentes sejam
avaliados.
O exemplo representado atravs da fgura 50 pode ajudar a enten-
der a funo de um diagrama de componentes.
Figura 50: Representao de um diagrama de componentes.
Fonte: Matos, 2002.
Observando este exemplo, as funes de um diagrama de compo-
nentes fcam mais claras:
componentes so elementos de alto nvel. No se trata de um
pacote, mas de um elemento que permite o agrupamento de
vrias interfaces. Por exemplo, o Gerenciador de Senhas no
necessariamente precisa implementar os mtodos indicados a
partir de uma nica classe;
conforme ser melhor discutido no diagrama de implantao,
o sistema pode ser visto como uma diviso de ns, e cada n
agrupa um conjunto de componentes similares.
Na verdade, o desenho de um diagrama de componentes deve ser
guiado pela conjuno da viso dos seguintes elementos de software:
Cdigo-fonte
Bibliotecas e interfaces
Documentao e arquivos complementares
Ou seja, um diagrama de componentes permite que se conhea a
dependncia que existe entre os diferentes elementos de software (MATOS,
2002).
Na fgura 51, vamos esboar a organizao de um software verifca-
dor de senhas e usurios para um terminal de um banco.
Figura 51: Representao de um diagrama de componentes para um terminal de banco.
Fonte: Matos, 2002.
Obviamente que essa organizao dependente da soluo adota-
da - esse conjunto de cdigo peculiar a um ambiente de programao em
Java. Neste sentido, conveniente ressaltar que um diagrama de compo-
nentes refete o que se espera da linguagem de programao usada (MATOS,
2002).
Podemos incluir outros recursos de programao importantes em
diagramas de componentes, tais como, tabelas de banco de dados e docu-
mentaes. Estaremos visualizando estes recursos na fgura 52.
Figura 52: Representao de um diagrama de componentes com tabelas de banco
de dados.
Fonte: Matos, 2002.
7.8.2 Diagrama de implantao
Devemos visualizar que em qualquer processo ou ciclo de vida
de software, um sistema computacional no apresenta apenas uma parte
lgica. Analistas, projetistas e tomadores de deciso precisam preocu-
par-se com o hardware - afnal de contas onde o software desenvolvido
ser executado (MATOS, 2002).
Os sistemas distribudos exigem muito mais dos projetistas de
sistemas, pois um componente de software passa a ser muito mais do que
um simples trecho de cdigo esttico, passando a ter uma responsabilida-
de e mobilidade imprescindvel (MATOS, 2002).
Se adaptar uma plataforma de hardware para um software dis-
tribudo no uma tarefa simplria e de deciso meramente baseada em
anlises de confguraes, devemos estudar um meio de modelar essa
situao (MATOS, 2002).
Em UML, diagramas de implantao so o recurso ideal para a
discusso da adequao do hardware (MATOS, 2002). A partir do conceito
de n podemos vislumbrar a distribuio do hardware e dos respectivos
componentes de software necessrios. Devemos ento entender o conceito
de n. N qualquer elemento de hardware em que um componente de sof-
tware possa ser executado, ou seja, entende-se como n um elemento que
possua capacidade de processamento (MATOS, 2002).
A modelagem de ns facilita a tomada de decises e diminui a
distncia de vocabulrio e entendimento que geralmente existe entre pro-
gramadores e analistas de sistemas (MATOS, 2002). Obviamente que no se
espera que gestores e analistas tornem-se excelentes analistas de hardware,
mas a discusso pela plataforma ideal torna-se mais simples (MATOS, 2002).
Devemos salientar que a criao de diagramas de implantao um
recurso da UML que melhor exemplifca a necessidade de extensabilidade
(prevista pela linguagem). Nesse caso, o uso de esteretipos plenamente
aconselhvel e podem indicar muito mais do uma simples relao de depen-
dncia (MATOS, 2002).
Componentes e ns possuem estreita relao e podem ser repre-
sentados como na fgura 53. No entanto, diagramas de implantao no
se restringem a apenas indicar essa relao existente entre componentes
e seus respectivos ns de implementao (MATOS, 2002). importante ar-
quitetar a organizao lgica do hardware participante de um ambiente.
Figura 53: Representao de um diagrama de componentes com n.
Fonte: Matos, 2002.
comum o uso do diagrama de implantao para a confeco de
uma viso simplifcada de uma organizao de hardware (MATOS, 2002). Na
verdade, o que se v na fgura 54 uma relao de ligao que permite,
inclusive, que se infra como esto distribudas as funes de um ambiente
de gerenciamento de uma rede Internet, porm esse mesmo esquema pode
ser estendido para uma situao mais real conforme podemos visualizar na
fgura 55.
Figura 54: Representao de um diagrama de componentes mostrando funes de
ambiente de gerenciamento de uma rede internet.
Fonte: Matos, 2002.
Figura 55: Representao completa de um diagrama de componentes mostrando
funes de ambiente de gerenciamento de uma rede internet.
Fonte: Matos, 2002.
Resumo
sobre o histrico da UML;
sobre os principais diagramas da UML;
como identifcar um caso de uso;
como desenhar um diagrama de caso de uso;
como os principais diagramas da UML;
sobre os cuidados necessrios ao se criar diagramas de caso de uso;
como identifcar classes;
como identifcar relacionamentos;
sobre extenses e mecanismos;
como desenhar um diagrama de classes;
sobre os tipos de diagramas de interao;
sobre diagramas de colaborao;
sobre diagramas de sequncia;
como desenhar diagramas de sequncia;
sobre os diagramas de estados e sua funo;
como desenhar diagramas de estados;
sobre diagramas de atividades;
como desenhar diagramas de atividades;
sobre componentes de software;
como desenhar diagramas de componentes; e
como desenhar diagramas de implantao.
As atividades referentes aula 7 Modelagem Baseada em UML
estaro disponveis na plataforma moodle.
AULA 1
Alfabetizao Digital
85
Aula 8 Estudo de caso
Objetivos
- Criar um projeto de software utilizando conhecimentos de orien-
tao a objetos e da linguagem de modelagem unifcada.
8.1 Introduo
Atravs do estudo de caso, o aluno estar colocando em prtica os
conhecimentos obtidos neste caderno.
O estudo de caso ser disponibilizado na plataforma moodle.
Referncias
BEZERRA, Eduardo. Princpios de anlise e projeto de sistemas com UML. 8
ed. Rio de Janeiro: Editora Elsevier, 2002.
MATOS, Alexandre Veloso de. UML: Prtico e Descomplicado. 2 ed. So Paulo:
Editora rica, 2002.
SBROCCO, Jos Henrique Teixeira de Carvalho. UML 2.3: teoria e prtica. So
Paulo: Editora rica, 2011.
TONSIG, Srgio Luiz. Engenharia de software. So Paulo: Editora Futura,
2003.
Currculos dos professores conteudistas
Nilton Alves Maia
Doutor em Engenharia Eltrica - rea de concentrao Engenharia de Com-
putao e Telecomunicaes pela UFMG (2006), mestre em Administrao
- rea de concentrao produo e sistemas pela UFRGS (1999), especialista
em Anlise de Sistemas rea de Concentrao em Computao pela UFMS
(1997), especialista em Tpicos Avanados em Telecomunicaes pela UFMS
(1996), especialista em Administrao de Sistemas e de Informaes Geren-
ciais pela UCDB (1994) e graduado em Engenharia Eltrica - Opo Eletrnica
pelo INATEL (1979). Atualmente professor adjunto da Universidade Estadual
de Montes Claros e das Faculdades Santo Agostinho. Possui experincia nas
reas de Engenharia Eltrica e Sistemas de Informao, atuando principal-
mente nos seguintes temas: sistemas de telecomunicaes, engenharia de
trfego, computao autonmica, inteligncia computacional, anlise e pro-
gramao de sistemas de informao orientados objetos.
Mestranda em Administrao com nfase em Gesto Pblica, especialista
em Anlise de Sistemas rea de Concentrao em Computao pela UFMS
(1997) formada em Tecnologia de Processamento de Dados pelo CESUP
(1994). Atualmente professora da Universidade Estadual de Montes Claros.
Possui experincia em Sistemas de Informao, atuando principalmente nos
seguintes temas: Engenharia de Software, Anlise Estruturada e Gerncia de
Projetos.

Analise Projeto Sistemas Mail

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Analise Projeto Sistemas Mail

Încărcat de

Drepturi de autor:

Formate disponibile

e-Tec Brasil/CEMF/Unimontes

Escola Tcnica Aberta do Brasil

princpio). Alm disso, o comportamento esperado de Antnio

S-ar putea să vă placă și