ࡱ> PRO9 ,bjbj.@(lppppppp4""2>*> !!!!!!!$T# t%~!pJJJ!&pp!&&&Jpp!&J!&&r Tpp! `i8F !!!0""!z%:%!&pppp INCLUDEPICTURE "http://www.varginha.br/unis.gif" \* MERGEFORMATINET  DIAGRAMAS DE CLASSES OS ELEMENTOS BSICOS William Ribeiro de Oliveira Jaderson Satler Barreto Ranieri Miranda de Lacerda 5 perodo de Cincia da Computao Varginha - Junho de 2001 DIAGRAMA DE CLASSES Um diagrama de classes uma metodologia usada para descrever os tipos de objetos no sistema e os vrios tipos de relacionamento esttico existente entre eles, bem como atributos e operaes de uma classe e as restries. PERSPECTIVAS Existem trs perspectivas que voc pode usar quando usar quando projetar diagramas de classes ou, de fato, qualquer modelo, mas esta classificao mais perceptvel em conexo com diagramas de classes. Conceitual: Se tomarmos a perspectiva conceitual, voc projeta um diagrama que representa os conceitos no domnio que est sendo estudado. Estes conceitos sero naturalmente relacionados s classes que iro executa-los. Na verdade, um modelo conceitual deve ser projetado com pouca ou nenhuma ou nenhuma preocupao com o software que poder implementa-lo, portanto dever ser considerado independente da linguagem implementada.(perspectiva essencial). Especificao: Agora estamos examinando o software, mas estamos analisando as suas interfaces, no a sua implementao. O desenvolvimento orientado a objetos pe muita nfase na diferena entre interface e implementao, mas isso freqentemente negligenciado na prtica porque a noo que temos de classe em uma linguagem orientada a objetos combina interface com implementao. Implementao: Nesta viso, realmente, temos classes e estamos pondo e implementao s claras. Esta , provavelmente, a perspectiva usada com mais freqncia, mas, de vrias formas, a perspectiva de especificao freqentemente a melhor para ser usada. A compreenso das diversas perspectivas crucial tanto para desenhar como para ler diagramas de classes. Infelizmente , as linhas entre as perspectivas no so rgidas, e a maioria dos modeladores no se preocupa em ter suas perspectivas classificadas quando eles esto modelando. ASSOCIAES Associaes representam relaes entre ocorrncia de classes. Ex. (uma pessoa trabalha para uma companhia; a companhia tem vrios escritrios. Da perspectiva conceitual, associaes representam relaes conceituais entre classes. O diagrama indica que um pedido pode vir de um nico cliente e que um cliente pode fazer vrios pedidos no decorrer do tempo. Cada um destes pedidos tem vrias linhas de pedido, cada uma das quais refere-se a um nico produto. Cada associao tem duas pontas de associao, cada ponta ligada a uma ponta na associao. Cada ponta de associao tem multiplicidade, que uma indicao de quantos objetos podem participar de um dado relacionamento. O * na ponta do pedido da associao com o cliente indica que um cliente tem muitos pedidos associados a ele, na outra ponta indica que um pedido vem somente de um cliente. Geralmente, a multiplicidade indica limites inferiores e superiores para objetos participantes. O * representa uma variao de 0 .. a infinito: um cliente no precisa ter feito um pedido, e no h limite superior(ao menos na teoria!) para o nmero de pedidos que um cliente pode fazer. O 1 representa 1...1 : um pedido deve ser feito exatamente por um cliente Dentro da perspectiva de especificao, associaes representam responsabilidades. O diagrama de classes implica que existem um ou mais mtodos associados ao cliente que diro quais pedidos um dado cliente fez. Similarmente, existem mtodos dentro do pedido que permitiro saber qual cliente fez um dado pedido e quais linhas de item esto em um pedido. Se a navegabilidade existir somente em uma direo, chamamos a associao de associao unidirecional. Uma associao bidirecional contm navegabilidades nas duas direes.UML usa as associaes sem flexas para indicar que a navegabilidade desconhecida ou que a associao bidirecional Atributos: Atributos so muito semelhantes a associaes. Devemos pensar nos atributos como classes simples e pequenas, tais como string, date, money e valores primitivos, tais como integer e real. A sintaxe de UML define: visibilidade nome: tipo = valor_por_omisso. Visibilidade pode ser +(pblico), #(protegido), ou (privado). No nvel conceitual, um atributo nome do Cliente indica que Clientes tm nomes, no havendo diferenas nesta perspectiva entre atributos e associaes. No nvel de especificao, este atributo indica que um objeto Cliente pode lhe dizer o seu nome e tem vrias maneiras de atribuir valor a nome. Nesta perspectiva atributos diferem de associaes, pois atributos indicam navegabilidade somente do tipo para o atributo, ou seja, sempre unidirecional. No nvel de implementao, o Cliente tem um campo para armazenar seu nome. Atributos indicam que o tipo contm a sua prpria cpia do objeto atributo, implicando que qualquer tipo usado como atributo tem uma semntica de valor em vez de referncia, diferindo assim de associaes na perspectiva de implementao. Operaes: Operaes so os processos que a classe sabe realizar. Operaes correspondem claramente a mtodos em uma classe. A sintaxe completa da UML : visibilidade nome (lista_de_parmetros): expresso_de_tipo_de_retorno{string_de_propriedades} Onde: visibilidade + (pblico), # (protegido), ou (privado). Nome um string. Lista_de_parmetros contm parmetros separados por vrgulas, com a sintaxe: direo nome: tipo = valor_por_omisso. O elemento direo usado para mostrar se o parmetro de entrada (in), sada (out) ou ambos (inout). Se no houver valor de direo assume-se que seja in. expresso_de_tipo_de_retorno uma lista de tipos de retorno separados por vrgula. string_de_propriedades indicam propriedades de valor que se aplicam dada operao. Linguagens tm suas prprias convenes de denominao. Em C++ operaes so chamadas funes-membro (member functions) e em Smalltalk chama-se operaes de mtodos (methods). UML usa o termo feature para se referir tanto a um atributo quanto a uma operao. Generalizao: Este fenmeno est sujeito a diferentes interpretaes em diferentes tipos de modelagem: Conceitualmente, a idia chave que tudo o que dissermos sobre um supertipo associaes, atributos, operaes tambm seja verdadeiro para um subtipo deste supertipo. Em um modelo de especificao, generalizao significa que a interface do subtipo deve incluir todos os elementos da interface do supertipo. A interface do subtipo deve seguir a interface do supertipo. Generalizao na perspectiva de implementao associada herana nas linguagens de programao. A subclasse herda todos os mtodos e campos da superclasse e pode sobrescrever mtodos herdados. Com qualquer uma destas formas de Generalizao, voc deve sempre garantir que a generalizao conceitual tambm se aplica. Regras de Restrio: As construes bsicas de associao, de atributo e de generalizao fazem muito para especificar restries importantes, mas elas no podem indicar cada restrio. Estas restries ainda precisam ser capturadas; o diagrama de classes um bom lugar para faz-lo. UML permite que voc use qualquer coisa para descrever restries. A nica regra que voc as coloque entre chaves ({}). UML tambm fornece uma linguagem formal de restries de objetos (OCL Object Constraint Language); De modo ideal, regras devem ser implementadas como asseres na sua linguagem de programao. Projeto por Contrato: Projeto por contrato uma tcnica de projeto valiosa que pode ser utilizada com qualquer linguagem de programao, e no somente com a linguagem Eiffel que possui esta tcnica como caracterstica central. No centro do projeto por contrato est a assero. Uma assero uma declarao booleana que no deveria nunca ser falsa e, portanto, s ser falsa devido a um erro (bug). Tipicamente, asseres so checadas apenas durante a depurao (debug) e no so checadas durante a execuo em produo. De fato, um programa no deve assumir que as asseres esto sendo checadas. Projeto por contrato usa trs tipos de asseres: ps-condies, pr-condies, e invariantes. Pr-condies e ps-condies se aplicam a operaes. Uma ps-condio uma declarao de como o mundo deveria parecer depois da execuo de uma operao. Uma pr-condio uma declarao de como o mundo deveria ser antes da execuo de uma operao. A pr-condio torna explcito que o chamador responsvel pela verificao. Ser explcito a respeito de quem responsvel ajuda a reduzir a complexidade. Uma invariante uma assero a respeito de uma classe. A invariante verdadeira para todas as instncias da classe qualquer hora que o objeto estiver disponvel para ter uma operao executada nele. A invariante pode se tornar falsa durante a execuo de um mtodo, mas deveria retornar a ser verdadeira no momento em que outro objeto possa fazer qualquer coisa para o receptor. Na prtica, isso ajuda a assegurar que as subclasses se comportem adequadamente. QUANDO ULTILIZAR DIAGRAMAS DE CLASSES Diagramas de Classes so a base de quase todas as metodologias implementadas em Orientao a Objetos, portanto voc ir utiliza-lo o tempo todo. O problema com diagramas de classes que eles so muito ricos e podem e podem ser muito complexos de se usar. As dicas so as seguintes: No tente utilizar todas as notaes que voc dispe. Comece com o material simples deste : classes, associaes, atributos, generalizao e restries. Ajuste a perspectiva na qual voc est desenhando os modelos para o estgio do projeto. Se voc estiver fazendo anlise, desenhe modelos conceituais. Quando voc estiver trabalhando com software, concentre-se nos modelos de especificao. Desenhe modelos de implementao somente quando voc estiver ilustrando uma particular tcnica de implementao No desenhe modelos para tudo; em vez disso, concentre-se nas reas principais. melhor ter poucos diagramas que voc usa e mantm atualizados do que ter muitos mtodos esquecidos e obsoletos. O maior perigo com diagrama de classes que voc pode ficar detido em detalhes de implementao muito facilmente. Para combater isso, concentre-se nas perspectivas conceituais e de especificao. FIJM[cd{' ' A J V '|CIKOQVw~  DHVi+0JQegihvx 6mHsH 5mHsH 5CJ \5CJ`OJQJ\^JmHsHmHsHB*mHphsHjB*UphNJKLMNX[cd{|}~ ^`^$a$,'() & & ' A B C D E F G H I J V  & F$ & Fa$V W X "'{|`  M DVi$ & F -^-a$ $h^`ha$$ & F -^-a$$a$`$`a$&'+56789:OPX 7!!!!z"#M$%d'''$a$`$`a$&JW :O !!!!"!,!-!!!M$Z$]$j$$$$$%%'',, 5mHsHmHsH#'''''''r((((()).***++,,, & F & F & F`$a$,1h/ =!"#$% sDd4b   s A@jhttp://www.varginha.br/unis.gifyK _topyK 0http://www.fepesmig.br/b%*AEmW)+tDpn*AEmW)+tPNG  IHDR~D PLTEZZZccckkkk!k!s!s!!)s)s){)1{1119{999BBBBBJJJRRRRRZZZZZZcccckkkksssss{{{{΄΄΄΄֌Ό֌Ό֌֔Δ֔֔֜֜֜֜ޜ֜ޥ֥ޥޭޭޭ޵޵޵޵޽޽"9pbKGDH cmPPJCmp0712Hs~IDATx^[ oǰފGtC*EEB3J44ٲídP8N[shRɋw/a`jhd‡sQTeOx 2b KBmuˡ Z=f5 x</ 3^R,}/k_+RZgvP- kv'U9rWgo8_v{z'mcL`0(8!b/9NYO$6+].goQܝvrAɣiDs%Z9nb X 1ӓD¬>Lċ ÓZ>lmIKiɇ\c~%Z`waR6ͬKp3Ddp&ePLQ(!E]Ir!HXfh0?ArL>5@IGo;.-+GaUHDs Lk\)V$=z)@áݲw`Ha^.cd&OB-OoQecxӜuB0#G/#Gp #,J+ɓgJPz3})G3 5 su]< 1W<>e}Fd[c[04WI4=1 _94Ƿ%K! ܰ_,PŁE N]300Iʅzy$Nձϋ.)P4 @5F]H&4Q4CS+@|ei0QUh$|Voyu"#^OO@EaO!P1ycX#Ƽ_? /r,"`jm&F 3!HSfX׎v{Xn3.c;~8}-u ڢ 2 qN=J eb<$:G&[)j(Fa Ga;n$ rz@h?#<̾Ezr5 `.,r 3 PHeHfrKfD}w"khdEznߦ373~὚-"wB.s8/{7 r0е!e zϗ%T4nX5lk&t<4Vˎ_jgH%alyiɶym@OP e6'05j f(Qq:p (f\@/E;ڭL"RDӞreAck<L*Tg  p\xQ7q8ãfh.vs;E`"O+ƵjSImlߞ(cC*l!A(E48 r/> AyM"C9c`~Ղy<g.BM1̶Ҍ gfNmܸ̟Ne6sfmaڥ !l!ߺ;o^ʙS{a3r>,ty|n_䎷%(mUǫ-Z\? QO~GӺa)1Lbf 3VO|=Hh6l WDDn;3wY:`ح聱XtkK›%^mpK 㥘 ]|X|SQ~qeOn\s%D|1=\ R6; j`-?|^N2Y%c; 3o CXN"*by)<*C\[ 33b`Ȟ%?d`$ %&61appxa/kO? 2]0㙽gMy'b6QcW7[ #KafPL\36Ͳ,pħR2s^c&d&8sPO3< {آL߈ Lf+\if&8{[zLf7o04Sr: -' 4c \7MfZC?saf3H v ]gwmt6㞬0ׄ}k&#x;'"pH3̲g}ξ 3tsx}w uMy7X"fv%nkܝ8ߟMmK\ +D!a.IT Cf108`2 ^vY/6R u0ӝo&gOApG2Ydf96݋$y՛>;kQk[;|n&S'V8G^' 'x0Q ڼlA9?Ɂ' xʮ6I=9FY`,g}6l?>4H_˯e (M&!nuH' OՉcj0W`So.NBN4YQjرFN%NFQԡU%dL7T熫6u^,vT}1(=EUr3kH+JN^ZJ9J&ZO9VJPi)%F}ʭh_CKVr.{Wӫ9H/wk+Zf>?3{ 5֕wK{j(v&W 7 7V zjIU z4WEu"_ԷJ6-WO\Rt|A~Qy5جN()[7sV .zW:ig`fGM9ѡSneWjH?z4gHnsVMmؕ-+kQ˖cgJ+W;.3uXmc9jޢ弦YŒtB61f4yh)M7Je.PVZl;0P;"ɧKJZLٰ6;Tf#ϭWFST ~H mUؠL"A5,^bAO_T|vZgũyNQ?&c<?C!l5xz`m|Zgc^gVG3ei]3D{Vcp9S_nBKJQM=\.*ZEǢQx5\D?X,C_rg|q\h,g\uEi`$OpIENDB` i8@8 NormalCJ_HaJmH sH tH N@N Ttulo 1$$@&a$5CJ`OJQJ\^JmHsH<@< Ttulo 2$$@&a$ CJ4mHsH<@< Ttulo 3$$@&a$ CJ(mHsH8@8 Ttulo 4$@&5\mHsH6A@6 Fonte parg. padro>B@> Corpo de texto$a$mHsHXC@X Recuo de corpo de texto$`a$mHsH4>@4 Ttulo$a$5\mHsH(@JKLMNX[cd{|}~'() &&'ABCDEFGHIJVWX" ' { |   M DVi&'+56789:OPX7zM !d#########r$$$$$%%.&&&''(((000000000[0[0d0d0d0d0d0d0d0d0d0d0d0d0d0d(0d008000000800 0 0 0  0  0  0 0 0 0 0 0 0 0 0 0 0 0 800J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0J0[00000000[0 0 0 0 0 0  0  0  0 0  0  0 0 0[000000000000[0:0:0:0:0[0000000000000000000 0 0 0% 0% 0% 00000,V ',,FH(C _Hlt517631128 _Hlt517631129(@@II(TZQVw~Vi*+0iwx~ !+,4 !$@ K o!w!!!!"+"""(   &  CDKTUiI###q$3%%F't''',(((NX JX(FACECAC:\DIAGRAMA DE CLASSES.docFACECA8\\Ntserver01\Pasta Compartilhada\DIAGRAMA DE CLASSES.docFACECA8\\Ntserver01\Pasta Compartilhada\DIAGRAMA DE CLASSES.docFACECAuC:\WINNT\Profiles\faceca\Dados de aplicativos\Microsoft\Word\Salvamento de AutoRecuperao de DIAGRAMA DE CLASSES.asdFACECA8\\Ntserver01\Pasta Compartilhada\DIAGRAMA DE CLASSES.docFACECA8\\Ntserver01\Pasta Compartilhada\DIAGRAMA DE CLASSES.docFACECAuC:\WINNT\Profiles\faceca\Dados de aplicativos\Microsoft\Word\Salvamento de AutoRecuperao de DIAGRAMA DE CLASSES.asdFACECA8\\Ntserver01\Pasta Compartilhada\DIAGRAMA DE CLASSES.doc WANDERSON8\\Ntserver01\Pasta Compartilhada\DIAGRAMA DE CLASSES.docHelio Lemes Costa2C:\FrontPage Webs\Content\Helionet\files\trab7.docvhd\ U|+~&Pc.@(=Nh ^`OJQJo(h pp^p`OJQJo(oh @ @ ^@ `OJQJo(h ^`OJQJo(h ^`OJQJo(oh ^`OJQJo(h ^`OJQJo(h PP^P`OJQJo(oh   ^ `OJQJo(h ^`OJQJo(h pp^p`OJQJo(oh @ @ ^@ `OJQJo(h ^`OJQJo(h ^`OJQJo(oh ^`OJQJo(h ^`OJQJo(h PP^P`OJQJo(oh   ^ `OJQJo( hh^h`OJQJo(h ^`OJQJo(hpp^p`.h @ @ ^@ `OJQJo(h ^`OJQJo(h ^`OJQJo(oh ^`OJQJo(h ^`OJQJo(h PP^P`OJQJo(oh   ^ `OJQJo(vPc.@(=U|+                           #(@hIqL(p@UnknownG:Times New Roman5Symbol3& :Arial?5 :Courier New;Wingdings"qhdzVdzVf!GY20)&2QDIAGRAMA DE CLASSESFACECAHelio Lemes Costa Oh+'0 $ @ L Xdlt|DIAGRAMA DE CLASSESIAGFACECAAACEACE Normal.dot Helio Lemes CostaS2liMicrosoft Word 9.0@G@!F@!Ff! ՜.+,D՜.+,D hp  CNECwG) DIAGRAMA DE CLASSES Ttulo$ 8@ _PID_HLINKSA 8{Ghttp://www.fepesmig.br/n)G http://www.varginha.br/unis.gif  "#$%&'()*+-./0123456789:;<=>@ABCDEFHIJKLMNQRoot Entry F6q8FSData !s1Table,%WordDocument.@SummaryInformation(?DocumentSummaryInformation8GCompObjoObjectPool6q8F6q8F  FDocumento do Microsoft Word MSWordDocWord.Document.89q