Parte 2 — Linguagem de Modelacao UML — Talvez isto seja um sinal — disse o Inglés, como quem pensa R alto. — Quem falou em sinais? — 0 interesse do rapax.crescia a cada minuto. — Tudo na vida so sinais — disse o Inglés, desta vex fechando a revista que estava a ler. O universo é feito por uma lingua que todo 0 mundo entende, mas que ja se esquecen. E:stou & procura dessa Linguagem Universal, além de outras coisas. Por isso estou aqui. Paulo Coelho, O Alguimista. OUML © UML (Unified Modelling Language) & uma linguagem diagramética, utilizavel para A iniciativa ‘0, visualizacio € documentacao de sistemas de informa especifica de criacio do UML surge em meados da década de 1990 na sequéncia de um esforco de unificagio de trés das principais linguagens de modelagio orientadas por objectos (OMT, Booch ¢ OOS! de norma no Ambito da OMG, tendo vindo a ser adoptado progressivamente pela Seguidamente, adquiriu em 1997 0 estatuto94 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. | industria e academia em todo 0 mundo. © UML apresenta, entre outras, as seguintes caracteristicas principais: (1) é inde- pendente do dominio de aplicagao caracteristic: na Web; s pendente do processo ou metodologia de desenvolvimento; (3) € independente das .. pode ser usado em projectos de diferentes s, tais como sistemas cliente/servidor tradicionais; sistemas baseados temas de informagio geogrificos; sistemas de tempo real); (2) é inde- fecramentas de modelacio; (4) apresenta mecanismos de extensio; (5) agrega um conjunto muito significative de diferentes diagramas dispersos por diferentes lin- guagens (eg., diagramas de casos de utilizagio, de classes, de objectos, de interac- Gli, de actividades, de estados, de componentes, ¢ de instalagio). Ao longo dos Capitulos 4 a 10 da Parte 2 deste livro apresentamos a linguagem UML com um compromisso assumido entre abrangéncia ¢ detalhe. Por um lado, pretende-se que sejam apresentados e discutidos os principais diagramas do UML; por outro lado, pretende-se apresentar os seus principais detalhes e discutir a sua aplicabilidade. O UML e os Dominios de Aplicagao Os exemplos ilustrados ¢ os exercicios sugesidos apresentam um compromisso entre situagdes de modelagio de casos gerais do dia-a-dia (e.g. 0 exemplo da maquina de bebidas, ou os exercicios sobre 0 universo do futebol) ¢ de casos mais especificos do dominio de sistemas de software (eg,, 0 exemplo dos diagramas de classes € de interac¢io do acesso, via JDBC, a um gestor de base de dados, ou o exercicio pedido para modelar o ciclo de vida de um servlet Java). O objective de apresentar exemplos entre estes dois espectros é mostrar que o UML pode ser adoptado em diferentes dominios de aplicagio, de abstracgdo e de generalidade. © UML é uma linguagem grifica cujo objectivo principal é promover ¢ facilitar a comunicacio entre diferentes tipos de intervenientes. Embora 0 foco deste livro tenha a ver com a modelagio de sistemas de informagio, nao é demais sublinhar que © UML pode ser usado noutros contextos ¢ por intervenientes com diferentes formacées (e.g., por gestores, para representarem as suas organizagdes com os res- pectivos recursos e processos de negécio; por juristas, para representarem as rela- des entre leis; por politicos para melhor explicitarem as tomadas de decisio). Organizagao da Parte 2 A Parte 2 € constitufda por sete capitulos complementares. O Capitulo 4 dé a visio hist6tica € geral do UML e o Capitulo 9 descreve sucintamente alguns aspectos considerados “avancados”, nao essenciais para o leitor que apenas pretende usar €Parte 2 — LINGUAGEM DE MopELagAo UML. 95 aplicar as caracteristicas basicas do UML. Os Capitulos 5, 6, 7 € 8 constituem o centro desta parte do livro ¢ deveriio ser lidos de forma sequencial, conforme pro- posto. Finalmente, 0 Capitulo 10 introduz o tema da modelagio de dados em UML e do seu mapeamento para esquemas relacionais, © Capitulo 4, “UML — Visio Geral”, d uma visio geral do UML. Em particular apresenta 0 seu enquadramento histérico, os seus objectivos ¢ principais aspectos que otientaram a sua arquitectura subjacente. Sio apresentados sucintamente os seus principais conceitos, designadamente os tipos de elementos bisicos, de rela- des e de diagramas. Por fim, aprescntam-se alguns dos mecanismos comuns UML (anotagdes ¢ mecanismos de extensio) e consideragées relacionadas com a organi- zagio dos artefactos de um sistema através da nogio de pacotes. Capitulo 5, “UML — Casos de utiliz ficacio e de gestiio de requisitos de um sistema de software e a sua relagio com os \S40”, comeca por discutir a tarefa de especi- diagramas de casos de utilizacio. Sio definidos os conceitos de caso de utilizagio, cenirio, actor, relagdes entre casos de utilizagio (rclacao de genetalizacio, inclusio ow extensio) ¢ entre actores ¢ casos de utilizagio (felagio de comunicagio). Sio aptesentados modelos de cspecificacio textual dos casos de utilizagio, com evi- déncia pata a especificacao das relacées de inclusao ¢ de extensio. Por fim, é dis- cutido a aplicacio dos diagramas de utilizacio através do exemplo da “Maquina de Bebidas”. © Capitulo 6, “UML — Modelagio da Estrutura”, aborda um aspecto basico na modelacio de software, que é a sua estrutura. Esta consiste, segundo a abordagem orientada por objectos, na identificagio de classes € suas respectivas relagdes. O UML providencia os seguintes clementos que permitem a especificagao da estru- tura de um sistema de software: classes, relagdes, interfaces, objectos. Com base nestes elementos, podem-se definir dois tipos de diagramas principais com fins complementares: diagramas de classes € diagramas de objectos. © Capitulo 7, “UML — Modelagao do Comportamento”, parte do pressuposto que a modelagio da estrutura de um sistema é conhecida, e atenta sobre a respectiva modelacio de comportamento, a qual consiste, segundo a abordagem orientada por objectos, em dois tipos distintos de especificacées. Por um lado, na modelagio do comportamento entre objecto: pela identificacio dos seus padrdes de trocas de mensagens (diagramas de interaccao). Por outro lado, na modelacio do compor- tamento dentro de um objecto, pela identificacao dos estados que um objecto pode ter 40 longo do seu ciclo de vida ¢ dos eventos que provocam mudangas nesses estados (diagramas de estados ¢ de actividade). © Capitulo 8, “UML — Modelacio da Arquitectura”, descreve aspectos da fase de implementagio ¢ instalagio de um sistema de informacio, designadamente a96 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — VoL. | estrutura ¢ dependéncias de cédigo fonte e de médulos execuraveis, tal como a sua respectiva instalacao nas diferentes plataformas computacionais subjacentes, atra~ vés dos diagramas de componentes ¢ de instalacio. Os diagramas de componentes sio usados para modelar a arquitectura de um sistema na perspectiva dos seus componentes digitais, explicitando principalmente as suas miltiplas dependéncias. Por outro lado, os diagramas de instalagdo so usados para modelar a arquitectura de um sistema informitico da perspectiva dos seus componentes fisicos explici- tando as dependéncias de comunicacio, ¢ especificando os componentes instala- dos em cada né computacional. © Capitulo 9, “UML — Aspectos Avancados”, apresenta alguns assuntos que con- sideramos “avangados”, e que permitem ao utilizador do UML uma compreensio mais profunda e porventura uma sua melhor aplicagio. Nomeadamente, apresen- tam-se os seguintes aspectos: (1) a estrutura ¢ arquitectura do UML, ¢ em particular a organizacio da camada de metamodelo; (2) os mecanismos de extensio do UML; com alguns exemplos concretos de conjuntos de elementos que estendem o UML, designados por perfis; (3) consideragdes sobre as nocdes de componente, sistemas de componentes (toolkits © frameworks), familias de aplicacdes, € reutilizacio; (4) tipos parametrizéveis em UML, em particular classes parametrizveis € colabora- ges parametrizaveis (no contexto de padrées de desenho); e (5) uma breve introdugio € motivagao para o XMI, que é o standard OMG para interoperagio de modelos UML, em XML. © Capitulo 10, “UML, — Modelagio de Dados”, aborda um aspecto comum da concepgio de sistemas de informagio que € 0 foco na modelagio de dados. Este aspecto envolve os tépicos de modelacio de dados aos scus diferentes niveis, mas também a definigio de regras de mapeamento dos modelos de dados de uma representacao de alto nivel (e.g., em UML) para uma representacao mais proxima do desenho fisico das bases de dados como sejam esquemas $QL/DDL. Casos de Estudo F. usado ao longo da Parte 2 do livro, como motivacio e suporte a patte significa- tiva dos diagramas que sio ilustrados, dois casos de estudo académicos: = GTTI, Sistema colaborativo de gestio de um Glossario de ‘Termos Técnicos Informaticos; e = GPG, sistema da Gest&o de Cursos de Pés-Graduacio.Parte 2 — LINGUAGEM DE MODELAGAO UML 97 GTTI — Glossdrio de Termos Técnicos Informaticos Considere-se que o objectivo do sistema GTTI é permitir, num contexto restrito de participantes, a constituicao ¢ gestdo dinimica de um glossario gerido de forma colaborativa via Web. Cada membro deste sistema pode propor termos (basica- mente um termo em inglés ¢ a sua respectiva tradugio para portugués), os quais ficam pendentes durante um determinado periodo de discussio. Ao longo desse periodo podem surgir comentarios positives ¢ negativos de outros membros; no fim do qual segue-se um periodo de validagio que tem como consequéncia a acei- taco ou rejeigao do termo proposto. Considere-se que os membros do GTTT sao professores ¢ alunos (em geral de pés- graduacio) ao nivel de uma ou mais escolas de ensino superior. Considere-se ainda que existe um actor responsavel pela aceitagio de registos de membros, bem como pela gestao e configuracio geral do glossario. GPG —- Gestao de Pos-Graduagao Descri¢ao Geral Considere o sistema GPG (sistema de informacio “Gestio de Cursos de Pés-Gra- duagio”) que suporta alguns dos requisitos de informagao e processos administra- tivo-académicos de varios actores que vivem no seio de uma Escola de Ensino Superior, tais como: alunos, docentes ¢ técnicos administrativos. Considere que este sistema é focado no sub-universo da gestio do ensino ao nivel de pés-gradua- cio da Escola, Considera-se que esta actividade é coordenada pela figura do Coor- denador do Ensino Pés-Graduado, no ambito da Comissio de Coordenagio do Ensino Pés-Graduado (CCPG), ¢ funcionalmente suportada por técnicos admi- nistrativos da Escola. Todos os membros da CCPG sio docentes doutorados. O sistema deverd gerir varios cursos pés-graduados de diferentes tipos (e.g,, mes- trado, doutoramento, profissional). Cada curso ofetece um detetminado mimero de disciplinas, as quais, dependendo do tipo de curso, podem ser obtigatérias ou opcionais. Uma disciplina pode ser ministrada por varios docentes, mas apenas um com o papel de responsavel, ao qual se designa por regente. O regente tem de ser um docente com doutoramento. Por outro lado, um aluno quando pretende reali- zat um curso, tem de realizar varias accdes, passando designadamente pelas seguintes fases: (1) candidatura, (2) inscrigio, (3) realizacio da componente lectiva, ¢ (4) realizagio da componente de investigacio.98 CENTRO ATLANTICO— UML, METODOLOGIAS & FERRAMENTAS CASE ~ VoL. | Processos a Suportar Considere para o processo de candidatura as seguintes actividades: O aluno gan- didata-se ao curso até a data limite das candidaturas, apresentando o seu CV, certi- ficado de habilitagdes, e uma carta de manifestago de interesse; essa informagio, pata além de ser entregue em papel na secretatia, é também submetida electroni- camente no sistema GPG (0 que implica que 0 candidato tenha de solicitar pre- viamente, também suportado pelo préprio sistema, uma conta de utilizador neste sistema). Com base nos candidatos registados no sistema, a CCPG retine-se, pro- duzindo uma lista com os candidatos aceites e os niio aceite. Hssa informagio é registada no sistema por um técnico-administrativo da Escola, competindo ao sis- tema notificar por e-mail e/ou SMS os candidatos. Para os candidatos aceites, é também indicada a hora ¢ local de entrevista. Nessa entrevista, entre o candidato e um membro designado da CCPG, sio explicadas as regras gerais do funciona- mento do curso e define-se com 0 candidato um documento designado como “Plano de Estudos”. Nesse documento, define-se (1) as disciplinas que o aluno deverd realizar, algumas das quais podem ser do tipo “propedéutica” (Le, disciplina de licenciatura, que o aluno deverd obrigatoriamente realizar) que atesta os conhe- cimentos do aluno em temas considerados nucleares do ambito do curso; ¢ (2) a definicio do orientador cientifico ou, caso tal nao seja possivel definir nessa altura, do conselheiro pedagégico. Este documento devera ser assinado no final dessa reuniio pelo aluno aceite e pelo membro da CCPG que realizou a reunio, sendo de seguida encaminhado para o coordenador da CCPG que teri a fungio de anali- sar ¢ avaliar a correccio geral de todos os Planos de Estudo, Apés a validagio e assinatura pelo coordenador, os documentos sio enviados para a Secretaria da Escola que os registard no sistema. Apés a conclusio do registo dos candidatos aceites ¢ dos seus respectivos Planos de Estudos ¢ apés a validacio global pelo coordenador da CCPG, o sistema enviaré passado uma semana (valor definido por omissio) de forma automatica a informacio rclevante para o sistema de inscricdes da escola , para o sistema PagaJaPropinas).. Considere para 0 processo de realizagio da componente de investigagio as seguintes actividades: A componente de investigacio inicia-se formalmente com a atribuicio do titulo da investigacio ¢ do nome do professor orientador cientifico. Caso 0 orientador seja externo a Escola, tem de existir obrigatoriamente um pro- fessor da escola que desempenhe o papel de co-orientador, F. da tesponsabilidade do técnico da Secretaria o registo dessa informacio (inicial e de posteriores altera- des) com base num formulitio previamente preenchido e assinado pelo aluno, pelo(s) orientador(es), € pelo coordenador da CCPG. O aluno deverd registar na sua “Area de Investigagio”, antes da discuss’o final da dissertagio, a seguinte informagio: titulo da tese, resumo e palavras-chave (em portugués ¢ inglés), €Pane 2 — LINGUAGEM DE MODELAGAO UML. 99 submeter uma versio electténica (em PDF) do documento integral da dissettagao. Apés este registo, 0 orientador do aluno deverd registar nessa area os professores membros do juri propostos (com indicagio do nome, grau académico, e-mail, € nome da Escola respectivo). A constituicdo do jiri tem de ser aprovada pelo coor- denador da CCPG, a qual também é realizada electronicamente através do sistema (eg, existindo um campo logico (ic., checkbufton) ¢ um campo de texto onde, em caso de reprovacio, se justifica o motivo. (Uma possivel situacio de nao aprovagio do jiri é se 0 aluno ainda no tiver pago a propina relativa a sua inscti¢ao anual.) Em qualquer das situagdes 0 professor orientador (¢ co-orientadores, caso existam) sio notificados electronicamente. Apés a aprovacio da constituigio do juri, a Secretaria envia aos professores envolvidos um exemplar da dissertagao em papel com o respectivo oficio e um formulirio de avaliagio/parecet da dissertacio. Os membros do jtiri tem um petiodo determinado (e.g,, 60 dias) para devolver o for- mulirio de avaliagio/parecer preenchido. Caso exista um parecer negativo, o aluno tem um novo perfodo (e.g,, 6 meses) para melhorar € re-submeter a sua investiga- cio, ou pode simplesmente desistir. Caso contrétio é da responsabilidade do orientador (em consonancia com as disponibilidades de todos os envolvido: agendamento das provas da dissertacio, o qual é registada também no sistema, Com base nessa informacio, o sistema notificara todos os envolvidos via e-mail e/ou SMS. Finalmente, apés a realizacio das provas da dissertacio é da responsa- bilidade do técnico da Secretaria 0 registo do resultado final obtido, sendo disso notificado (por e-mail) 0 aluno e respectivo orientador cientifico. Petiodicamente (eg, uma vez por més) o sistema GPG envia electronicamente para o sistema de registo nacional de teses, 0 “RNacionalDT”, a lista de teses concluidas com sucesso durante esse perfodo. Arquitectura Tecnolégica Considere que o sistema GPG providencia uma interface Web para os seus utiliza- dores ¢ é suportado tecnologicamente sobre um sistema de base de dados Oracle 10 (onde se encontra alojada a base de dados “GPG”), que é acedido por controlos empresariais Java (EJBs) ¢ JSPs executados, respectivamente, no context do ser- vidor JBoss e Tomcat. Considere que sistema se encontra suportado por duas maquinas: a primeira, “bd.pgraduacao.escola.pt”, que suporta o sistema de base de dados; e a segunda, “public.pgraduacao.escola pt”, que suporta os restantes componentes aplicacionais. Considere que os JSPs comunicam com os EJBs segundo 0 protocolo “RMI”, ¢ que 0s EJBs comunicam com a base de dados segundo JDBC.Capitulo 4 - UML-—VisAo GERAL Topicos = Introdugao = Visio Histérica * Tipos de Elementos Basicos * Tipos de Relacdes * Tipos de Diagramas Principais "= Organizacao dos Artefactos — Pacotes = Molduras e Fragmentos = Aspectos Especificos do UML 2 = Exercicios 4.1 Introdugao O UML (Unified Modeling Language) é uma linguagem para especificacio, consttugao, visualizacao e documentagio de artefactos de um sistema de informa- cio. E promoyido como standard pelo Object Management Group (OMG), com contribuicdes de diversas empresas da indistria de software. O UML tem sido adoptado pelas empresas ¢ instituicées em todo o mundo, existindo actualmente mais de 50 ferramentas cometciais ¢ académicas para modelagio de software e de negécio baseadas em UML. © UML providencia as seguintes particularidades principais [OMG99]: = Semintica e notacio para tratar um grande nimero de tépicos actuais de mo- delacio.102 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — Vol. | * Seméntica para tratar topics de modelagio futura, relacionados em particular com a tecnologia de componentes, computagio distribuida, frameworks Inter- net. = Mecanismos de extensio de modo a permitir que futuras aproximacdes e nota- ges de modelagio possam continuar a ser desenvolvidas sobre o UML. ilitar a troca de modelos entre ferramentas distin- = Seméntica e sintaxe para fa tas. © UML alarga 0 ambito de aplicagdes alve comparativamente com outros méto- dos existentes, designadamente porque permite, por exemplo, a modelagio de sis- temas concorrentes, distribuidos, para a Web, sistemas de informacao geogrificos, ete ‘A énfase do UML é na definicao de uma linguagem de modelacio standard, € por conseguinte, 0 UML € independente das linguagens de programagio, das fer- ramentas CASE, bem como dos processo de desenvolvimento. © objectivo do UML é que, dependendo do tipo de projecto, da ferramenta de suporte, ou da organizagio envolvida, devem ser adoptados diferentes processos/metodologias, mantendo-se contudo a utilizacéo da mesma linguagem de modelagio. © UML é independente das ferramentas de modelagio. Apesar da especificagio do UML incluir sugestdes para os fabricantes de ferramentas adoptarem na apresenta- cio dessas notagdes (e.g., t6picos como o desenho de diagramas, cor, navegagio entre esquemas, etc), ndo aborda todos os requisitos necessitios por no set esse, propositadamente, o seu objectivo. Um principio basico no esforgo de definicio do UML foi a simplicidade. Outro principio foi a coeténcia na unificagao de diferentes elementos existentes em virios métodos, entre outros Booch [Booch94], OMT [Rumbaugh91] e OOSE [Jacobson92|, ¢ introducio de novos elementos apenas quando tal fosse absoluta- mente necessitio, ie., quando tais elementos nao existissem em métodos anterio- res. Foi recentemente oficializada a versio do UML 2 que representa um salto signifi- cativo relativamente a verso anterior (UML 1 ow 1.5). Apesar das alteracdes signi ficativas deverem-se a aspectos arquitecturais internos, ie. na forma como o metamodelo UML é definido, existem, ainda assim, aspectos visiveis que o utiliza- dor regular do UML se devera aperceber ¢ dominat, tais como mudanga de nomes de diagramas, novos diagramas, ¢ novos conceitos ¢ notagdes. Sio principalmente estes tiltimos aspectos que so preferencialmente abordados neste livro. Os aspectos decorrentes da arquitectura do metamodelo UML 2 sto apenas superfi- cialmente abordados mais 4 frente no Capitulo 9.CaPiTuLo 4 - UML - VisAo GeRAL 103 4.2 Visao Historica A Figura 4.1 da uma visio do enquadramento histérico relativamente ao contexto das linguagens de modelagio de software orientado por objectos e, em particular, do UML. Na primeira metade da década de 1990 assistiu-se a uma proliferagio de métodos € notagées para modelagio segundo a abordagem orientado por objectos (fase da fragmentagio). Por essa altura percebeu-se a necessidade da existéncia de uma lin- guagem que viesse a tornar-se uma norma, que fosse aceite e utilizada quer pela industria, quer pelos ambientes académicos e de investigacio. Surgiram entretanto alguns esforcos nesse sentido de normalizacio, sendo que UML apareceu em 1996 melhor pos ionado como a linguagem “unificadora” de notacdes, diagramas, ¢ formas de representacio existentes em diferentes métodos, em particular nos métodos Booch, OMT e OOSE (fase da unificacio) wz 2001-200 : = 2001 cer [ict Se L : Twa : Jan, 1057 = Jun, 1996 ‘out 1095 eose Figura 4.1: Visio historica do UML.104 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — Vol. | Seguiu-se um esforco significativo nessa unificagio com contributos de varios par- ceiros com vista A normalizagdo no ambito da OMG, 0 que aconteceu em 1997, com a versio 1.0, ¢ anos subsequentes com sucessivos refinamentos ¢ melhorias na especificagio, com versdes 1.1 até A 1.5. (fase da standardizacio ou normalizagio). Notar que as diferencas entre as versdes 1.4 ¢ 1.5 sio pouco significativas (deve- ram-se a refinamentos de inconsisténcias ¢ climinacio de incorreccdes pouco signi- ficativos) ¢ que referiremos ao longo do texto “UML 1” como a versio 1.5 da especificagio UML. Posteriormente a essa fase assiste-se a divulgacio e adopsio generalizada do UML como “a” linguagem de modelagio de software segundo a abordagem orientada por objectos. Assiste-se ao aparecimento de publicagées espectficas sobre UML; de teses, relatérios © artigos técnico-cientificos que usam o UML; de ferramentas CASE que suportam o UML, etc. (fase da industrializacao). A versio UML2 encontra-se divulgada ha mais de um ano, mas apenas com aprovacio final ¢ cor- respondente oficializacio no final de 2004, Hi dois aspectos importantes que se obtém com 0 UML. Por um lado, terminam as diferencas, geralmente inconsequentes, entre as linguagens de modelacio dos anteriores métodos. Por outro lado, 0 UML unifica as distintas perspectivas entre diferentes tipos de sistemas (e.g., modelagdo de negdcio vs. modelagao de soft- ware), fases de um processo e conceitos internos. Uma das preocupacdes mais significativas no desenho e na especificacio do UML foi tomé-lo extensivel © aberto a futuras evolugdes, que inevitavelmente iriam ocorrer. O objectivo era permitir estender 0 UML sem ser necessirio redefinir 0 seu micleo principal. Os elementos introduzidos na definigao do UML 1 sao: = Mecanismos de extensio = Blementos para modelar processos ¢ breads = Blementos para modelar distribuic&io ¢ concorréncia = Padrdes de desenho ¢ colaboragdes = Diagramas de actividade (para modelacio de processos de negdcio) = Refinamento (para tratar relac6es entre diferentes niveis de abstraccio) = Interfaces e componentes = Linguagem de restrig6es (Objest Contraint Language) = Semintica de accdes (Action Semantic’) associada & visio do UML executivelCapiTuLo 4 - UML— VisAo GERAL 105 © UML 1 providencia nove tipos de diagramas segundo trés visbes pincipais: Visio Estatica ou Estrutural — Diagrama de classes — Diagrama de objectos = Diagrama de componentes = Diagrama de instalacio Visio Funcional = Diagrama de casos de utilizagio = Diagrama de actividade Visio Dinamica — Diagrama de estados (statechart diagram) — Diagrama de interacco = Diagrama de sequéncia * Diagrama de colaboracio Por outro lado, o UML 2 providencia treze tipos de diagramas segundo as mesmas trés visbes principais: ‘Visio Estatica ou Estrutural = Diagrama de pacotes — «NOVO» — Diagrama de classes = Diagrama de objectos = Diagrama de estrutura composta (composite structure diagram) «NOVO» — Diagrama de componentes — Diagrama de instalagio Visio Funcional = Diagrama de casos de utilizagio = Diagrama de actividade Visio Dinamica = Diagrama de maquina de estados (state machine diagram) — Diagrama de interaccio = Diagrama de sequéncia * Diagrama de comunicagao «Mudanga de nome»106 CENTRO ATLANTICO ~ UML, METODOLOGIAS E FERRAMENTAS CASE ~ VoL. | Diagrama de visio geral da interacgio (interaction overview diagram) «NOVO» " Diagrama temporal (timing diagram) «NOVO» 4.3 Tipos de Elementos Basicos A estrutura de conceitos do UML é razoavelmente abrangente consistindo num conjunto variado de notagdes, as quais podem ser aplicados em diferentes domi- nios de problemas e a diferentes niveis de abstraccio. A estrutura de conceitos do UML pode ser vista através das seguintes nogoes: (1) “coisas” ou elementos basi- cos, com base nos quais se definem os modelos; (2) relagdes, que relacionam ele- mentos; € (3) diagramas, que definem regras de agrupamento de clementos. Os elementos encontram-se organizados consoante a sua funcionalidade ou res- ponsabilidade. Assim ha elementos de estrutura, comportamento, agrupamento, anotacao e€ testricao. Classe Interface Pacote 2] Z 4 Caso de Utilizagio 7 Figura 4.2: Excemplo dos priicipais elementos do UML. ColaboragSo } ActorCapituto 4 - UML - VisAo GeRAL 107 Comporlamento ‘Agupamente : [Pacete ait Fragmento Combined 7 Meldurs Anclagie e Restigas s WResngio} by aS 2 Figura 4.3: Excemplo dos principais elementos do UML. (cont). Ge A Figura 4.2 ilustra 0 conjunto dos principais elementos de estrutura: classes, clas- ses activas, objectos, interfaces, casos de utilizacio, actores, colaborages, compo- nentes, artefactos € nés. Adicionalmente so ilustrados na Figura 4.3 outros ele- mentos basicos do UML, nomeadamente elementos de especificagio de compor- tamento (estados e actividades), de agrupamento (pacotes ¢ fragmentos) ¢ de ano- tagao e restticao. 4.4 Tipos de Relagées As telagdes so conceitos gerais que apresentam uma sintaxe (neste caso, uma notac%io) ¢ uma semintica bem definida, ¢ que permitem o estabelecimento de interdependéncias entre os elementos basicos acima introduzidos. A Figura 4.4 ilustra os principais tipos de relagdes do UML, nomeadamente rela- ces do tipo associagao, dependéncia, realizacio, generalizagio ¢ agregagio. (Mais 4 frente sera descrito em detalhe a semantica ¢ aplicacao destes diferentes tipos de relacdes.)108 Centro ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — Vol. | Insertacet aintertace> Interface? Classet ‘ associagio seneralizagio agregagio Sub-Classe assemby Figura 4.4: Excemplo de tipos de relagies entre elementos. 4.5 Tipos de Diagramas Principais Os diagramas sio conceitos que traduzem a possibilidade de agrupar elementos basicos e suas relacdes de uma forma que l6gica ou estruturalmente tenha sentido. Existem diferentes tipos de diagramas em UML. Para cada tipo de diagrama é usado um subconjunto dos elementos bisicos acima descritos, ligados por dife- rentes tipos de relagbes, que sejam apliciveis. Por exemplo, um diagrama de classes UML € composto por um conjunto de ico- hes representantes de classes em simulténeo (e opcionalmente) com a representa- io explicita das suas relagdes. Com base no quarto principio de modelagio enumerado na Secgio 2.3.2 (“P4. Nembum modelo é suficiente por si sé. Qualguer sistema nao-trivial é melhor representado através de pequeno mimero de modelos razoavelmente independentes”), 0 UML define diferentes tipos de diagramas, cuja utilizacio ¢ aplicacio permitem dar visdes complementa- res. " Diagramas de casos de utilizagao, que representam a visto do sistema na pers- pectiva dos seus utilizadores. " Diagramas de classes ¢ de objectos que permitem especificar a estrutura esta- tica de um sistema segundo a abordagem orientada por objectos.CapituLo 4 - UML - VisAo GeRAL 109 = Diagramas de interacgio entre objectos (e.g., diagramas de sequéncia ¢ diagra- mas de comunicacio) ¢ diagramas de estados ¢ diagramas de actividade, que petmitem especificar a dinimica ou 0 comportamento de um sistema segundo a abordagem orientada por objectos, * Diagramas de componentes ¢ diagramas de instalacio, que dio uma visio da disposicao dos componentes fisicos (software ¢ hardware) de um sistema. Apresenta-se de seguida, a titulo exemplificativo, alguns diagramas UML aplicados ao caso de estudo GTTI anteriormente descrito. 4.5.1 Diagramas de Casos de Utilizagao Um diagrama de casos de utilizagio descreve a relagiio entre actores e casos de utilizagdio de um dado sistema, Este é um diagrama que permite dar uma visio glo- bal ¢ de alto nivel do sistema, sendo fundamental a definigdo correcta da sua fron- teira. UGestor Figura 4.5: Excemplo de nm diagrama de casos de utilizago, O exemplo da Figura 4.5 ilustra um diagrama de casos de utilizacio relativo as fun- cionalidades do utilizador UAnénimo no sistema GTTIL. Estes diagramas sio utilizados preferencialmente nas tarefas de especificacio de requisitos e/ou de modelagio de processos de negécio. Estes diagramas sio equivalentes aos homélogos existentes no método OOSE de Ivar Jacobson Jacobson92]110 CENTRO ATLANTICO — UML, METODOLOGIAS FERRAMENTAS CASE — VOL. | 4.5.2 Diagramas de Modelagao da Estrutura Os diagramas de classes do UML sio uma integragio de diferentes diagramas de classes existentes, nomeadamente no OMT [Rumbaugh91], Booch [Booch94] ¢ outros métodos OO. Extensdes especificas de determinados processos (e.g. recor- rendo a esterestipos ¢ correspondentes fcones) podem ser definidos em varios dia- gramas para suportarem diferentes estilos de modelacao. inglés: String tportugués: Sting dataValidago: Date] * NCP: int autor nome: Sting motada: Sting WEN int email: String dataProposta: Date Aetaiee Wid estado idade: int teoebePropostas; boolean recebeDiscussoes: boolean data: Date concorda: boolean Figura 4.6: Exemplo de um diagrama de classes. Os diagramas de classes (ver exemplo da Figura 4.6) descrevem a estrutura de um sistema, em particular as entidades existentes, as suas estruturas internas, ¢ relagdes entre si, O exemplo da Figura 4.6 ilustra os principais conceitos do sistema GTTI. Um diagrama de objectos descreve um conjunto de instincias compativeis com determinado diagrama de classes. Permitem ilustrar os detalhes de um sistema em determinado momento, ao providenciarem cendtios de possiveis concretizagies. 4.5.3 Diagramas de Modelagao do Comportamento Interaceao entre Objectos Os padrdes de interacgio entre objectos sto reptesentados por diagramas de inte- (0, 08 quais podem assumir duas formas complementares, cada um focando um aspecto distinto: diagramas de sequéncia ¢ diagramas de comunicagio.CaPiTULO 4 - UML - ViSAO GERAL 111 Diagramas de Sequéncia Os diagramas de sequéncia ilustram interacgdes entre objectos num determinado periodo de tempo (ver exemplo da Figura 4,7 que ilustra um conjunto de interac Ges relativamente ao caso de utilizacio “Subscrever Registo de Membro” do sis- tema GTTI). Em particular, os objectos so representados pelas suas “linhas de vida” e interagem por troca de mensagens ao longo de um determinado periodo de tempo. —_WAnsniid Sea Se eae solicit fornularia de registo de membre acvita submissdo, Figura 4.7: Exemplo de um diagrama de sequéncia. Este tipo de diagrama baseia-se numa variedade de diagramas homélogos existen- tes em distintos métodos OO, segundo diferentes designagdes, como por exemplo interaction diagrams, message sequence charts, message trace, event trace, etc. gramas de Comunicagaéo Os diagramas de comunicacio ilustram interacgSes entre objectos com énfase para a representacdo das ligacdes entre objectos. Como os diagramas de comunicagio io mostram explicitamente 0 tempo (20 contratio do que acontece nos diagramas de sequéncia), a sequéncia de mensagens ¢ de actividades concorrentes é determi- nada usando-se mimeros sequenciais, com diferentes niveis hierarquicos112 CENTRO ATLANTICO— UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. | Este tipo de diagtama foi adoptado, entre outros, a partir do diagrama de objectos de Booch [Booch94], e do diagrama de interaccio de objectos de Fusion [Malan96). Diagramas de Estados Os diagramas de estado descrevem as sequéncias de estados que um objecto ou uma interaccio pode passar ao longo da sua existéncia em fesposta a estimulos recebidos, conjuntamente com as suas respostas € acgGes. Sio baseados nos statecharts de David Harel com pequenas adaptac6es [Harel87, Harel96], sendo designados na versio UML 2 por diagramas de maquina de esta- dos (statemachine diagrams). Diagramas de actividade Os diagramas de actividade representam uma série de acces ¢/ou actividades, ¢ em que as transigdes silo desencadeadas regra geral devido 4 simples conclusio de acgdes/actividades. Coat Vendease Concer Talos Figura 4.8: Exemplo de um diagrama de actividade.CapiTuLo 4 - UML — Visho GERAL 413 A Figura 4.8 exemplifica um diagrama de actividade na descrigao do processo de negécio “realiza reuniao com cliente”. Este tipo de diagrama € adequado para representar © comportamento de algorit- mos, processos de negécio € casos de utilizagio. Pode ser encarado, de alguma forma, como um caso particular de diagramas de estados ¢ é inspirado nos diagra- mas de morkjlow, fluxogramas ou naqueles baseados em SDL (Specification and Description Language) (ITU-T93}. 4.5.4 Diagramas de Arquitectura Os diagramas de arquitectura descrevem aspectos da fase de implementagio ¢/ou instalaco de um sistema de informacio, por exemplo, relativamente 4 estrutura € dependéncias de médulos de cédigo fonte e de médulos executiveis. Estes dia- gramas apresentam-se sob duas formas: diagramas de componentes ¢ diagramas de instalacio. Diagramas de componentes Os diagramas de componentes descrevem as dependéncias entre componentes de software, incluindo componentes de c6digo fonte, cédigo binatio ¢ executiiveis. Os diagramas de componentes so representados na forma de tipos € nio na forma de instincias. Para se descrever instincias de componentes, usam-se os dia- gramas de instalagio. Diagramas de Instalagao Os diagramas de instalagio (deployment diagrams) desctevem a configuragio de ele- mentos de suporte de processamento, ¢ de componentes de software, processos € objectos existentes nesses elementos (ver exemplo da Figura 4.9). es Figura 4.9: Excemplo de um diagrama de instalagio.Conceito 114 CenTRo ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE ~ Vol. | 4.6 Mecanismos Comuns do UML © UML contém um conjunto de mecanismos comuns que podem set utilizados de modo cons tente ¢ independentemente dos diferentes tipos de diagramas que ofe- rece. Desctevem-se de seguida trés dos mecanismos comuns: anotagées, mecanis mos de extensio, e tipos de dados. 4.6.1 Notas (ou Anotacées) ‘Uma nota ilustra um comentirio ¢ niio tem impacto semintico, jé que 0 seu con- tetido no altera em geral o significado do diagrama no qual ela se encontra (ver Figuras 4.9 © 4.10). Por isso é normal a utilizagio de notas para descrever infor- malmente: requisitos, restricdes, observagdes, revisdes ou explicacdes. Notas ou anotagées so elementos comuns que podem existir autonomamente, ie., sem terem de estat directamente associados a um determinado elemento especi- fico. Esta classe é MUITO complexal! Deve ser implementada segundo 0 padiao de desenho “Facade”, IRS, 2005/2/22 ClasseMuito Complexe Para mais detalnes consultar: http:d/intranet.empresa.com/projecto209/ Figura 4.10: Exemplo de notas. Fm geral devem ser tomadas em consideragio as seguintes recomendacdes na uti- lizacao de notas: = Localizagio: Devem ser colocadas graficamente perto dos elementos que deserevem. = Visibilidade: Podem-se esconder ou tornar visiveis isto dependendo das fer- ramentas de suport). = Extensio: Devem-se usar referencias (e.g, nomes de documentos ou URL) caso se pretenda um comentirio mais extenso. = Evolugao: A medida que o modelo evolui as notas mais antigas (cuja relevancia c utilidade deixem de ter sentido) devem ser eliminadas dos modelos.Conceito CAPITULO 4 - UML — VisAo GeRAL 115 4.6.2 Mecanismos de Extenséo O UML providencia os seguintes mecanismos que permitem estendé-lo de forma consistente: esterestipos, marcas e restrigGes. Embora se apresentem na Seccio 9.3 mais detalhes sobre este assunto, interessa desde ja referir alguns aspectos na apli- cagio destes mecanismos, designadamente devem-se ter em consideragio as se- guintes ressalvas: = Introduzir um niimero reduzido destes elementos. " Escolher nomes curtos e com significado pata esteredtipos ¢ marcas. = Sempre que a precisio puder ser relaxada, usar texto livre para especificacio das restriges. Caso contratio, usar a linguagem OCL. O OCL (Object Constraint Language) (Warmer99] & uma linguagem para especificagio formal de restrigdes © € parte integrante do UML [OMG99]. * A definicao destes mecanismos de extensio do UML, em particular a introdu- Gio de estere6tipos, deve ser realizada por um mimero restrito de especialistas em UML e deve ser devidamente documentado. Estereotipos Um esteredtipo é um metatipo, isto é, um tipo que descreve tipos. Permite definir novos tipos de elementos sem se alterar 0 metamodelo do UML, ¢ pot conseguinte permite estender 0 UML. O nome de um esteredtipo é representado entre os caracteres ‘ e ‘y’, podendo-se referir os seguintes exemplos: * Na modelagio de processos de negécio: «trabalhadom, «documento», «poli- tice». Na modelagio de aplicagdes especificas: classes de «interface», «control», «entidade». * Na modelacio de aplicagdes Web, usando 0 Web Application Extension {Conallen00)): classes de «Server Page», «Client Pages, «Form», «Select Elemen. astaredtina «exception» com nome e icon esterestivo com nome ae Lo «exception» *| utereeteo -s«cmetaclass» Overflow /\| eboundery® com icon ModelElement eee z SensorTemperatura Figura 4.11: Exemplo de estereétipas.Conceito 116 ‘CENTRO ATLANTICO ~ UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. | A Figura 4.11 ilustra és formas complementares de apresentacio de esterestipos apenas com icone (eg, SensorTemperatura); apenas com nome (eg, Mode1Element); ¢ com nome ¢ icone (eg., Over flow). A definigio de um esteredtipo tem de ter em conta os seguintes aspectos: * Propriedades (pode providenciar o seu préprio conjunto de marcas) + Semantica (pode providenciar as suas proprias restticdes) * Notagao (pode providenciar o seu proprio icone) = A classe base do metamodelo que vai set estendida (ie., se 0 esterestipo estende uma classe, uma associacao, um componente, etc.) Marcas com Valor Cada elemento em UML tem um conjunto de propriedades. Por exemplo: as ch ses tém um nome, uma lista de atributos ¢ uma lista de operagdes; as associagdes tém um nome ¢ dois ou mais elementos participantes. Enquanto que os esteresti- pos permitem adicionar novos elementos a0 UML, as marcas com valor permi- tem adicionar novas propriedades aos elementos, quer sejam elementos jé existen- tes no UML, quer sejam elementos definidos por recurso a novos esterestipos. marca com velor Aluno 20 nivel da classe “Jo fautor="uB", data="1/1/2005) nome {cor="amareio"} + — morada Jefo ‘marca com valor telefone 20 rivelde un ainbuta Figura 4.12: Exemplo de marcas com valor. Uma marca com valor é um conceito que deve ser entendido como metadata (isto é dados que descrevem dados) pois o seu valor aplica-se ao proprio clemento e nio as suas instancias. Por exemplo, conforme ilustrado na Figura 4.12, pode-se especificar 0 nome do autor ¢ a data de tltima alteragio da classe “Aluno”, ou pode-se especificar que o atributo “nome” deve set marcado com a cor “amarclo”. Um par “marca” e “valor” é delimitado entre os caracteres ‘f° ‘}’. Exemplos de aplicagées usuais: = Para geracio de cédigo, e.g. {language= wa}, {linker=Blinker}. * Na produgio automatica de documentacio, ¢.g;, {autor="|B”, data="1/1/2005”, nota=”..."} = Na gestio de configuragées, e.g: {autor=AMRS}, {data=Conceito Capituto 4- UML — Visio GERAL 117 Restrigdes ‘As restrigdes (consiraints) permitem adicionar ou alterar a semintica assumida por omissio de qualquer elemento UML. Uma restri¢io consiste na especificacao de uma condi¢ao delimitada pelos caracteres ‘{’ e ‘}’. A condigio pode ser especifi- cada numa linguagem formal (e.g,, OCL) ou informal (e.g,, texto em portugués). Uma restrigio permite especificar condigdes que tém de set validadas para que 0 modelo esteja “bem definido”, Exempio 4 Exemplo 2 Dey nt {self mulher genero="f" and partamento: a1 [7 saltsmarido genero="m} 7 Fs P an trebaher | {subset} | gerir 'essoa aa género-{m, FF | muner restrigao formal membro | 1." 4] gestor usando OCL Pessoa Figura 4.13: Exxemplos de utilizaciao de restrigdes. ‘A Figura 4.13 ilustra dois exemplos de especificagio de restrigdes. No primeiro exemplo especifica-se em OCL que “wna pessoa pade estar easada apenas com outra pes- soa do sexo opasto” (Exemplo 1). No segundo exemplo, especifica-se através da res- tricdo (subset }, predefinida em UML, que os elementos da associagio “gerit” tem de existir obrigatoriamente na associagio “trabalhar”, ou seja especifica-se que “uma pessoa para ser gestor de um departamento tem também de ser, necessariamente, memnbro desse departamento” (Exemplo 2). 4.6.3 Tipos de Dados Um tipo de dado é uma abstracc2o utilizada de forma implicita no UML. Os tipos de dados nao sio elementos do modelo e por conseguinte nao é possivel associar~ Ihes esteredtipos, marcas com valor ou restrigGes. Um tipo primitivo é um tipo de dados que nao tem uma subestrutura. Exemplos de tipos de dados: * Primitivos: Integer, String, Time = Enumerados: Boolean, AggregationKind, VisibilityKind * Outros: Expression, Mapping, Name, MultiplicityConceito 118 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. | Note-se que os conceitos de nomes, expresses ou multiplicidade sio tipos de dados UML, definidos informalmente 4 custa de outros tipos primitivos. Por exemplo, 0 tipo Multiplicity € definido como “o conjunto nao vazio de inteitos (Integer) positives, estendido com o caracter *”; © tipo Expression é definido como “uma sequéncia de caracteres (String) cuja sintaxe nao é definida, propositadamente, pelo UML”. 4.7 Organizacao dos Artefactos - Pacotes Um pacote (packag’) em UML é um elemento meramente organizacional. Permite agregar diferentes elementos de um sistema em grupos de forma que semintica ou estruturalmente faca sentido. Um pacote pode conter outros elementos, incluindo: classes, interfaces, compo- nentes, nds, casos de utilizagao, ... e mesmo outros pacotes. Por outro lado, um elemento encontra-se definido em apenas um tinico pacote. A necessidade da existéncia de pacotes torna-se evidente na modelagio de sistemas de média ou grande dimensio, em que, por razées de ordem pritica, se torna impossivel modelizé-los de uma “s6 vez”. Os principais beneficios da sua utiliza- cao sio: (1) facilita a gestio ¢ procura de artefactos; (2) evita os conflitos de nomes (eg, Xi é diferente de Xx¥:A, ¢ diferente de Z::A); e (3) providencia um meca- nismo adicional de controlo de acessos (visibilidade). Elementos de diferentes tipos podem ter 0 mesmo nome dentro de um pacote. Por exemplo, pode existir num pacote uma classe e um componente com 0 nome Ent idade. Contudo, de modo a reduzit ou eliminar possiveis confusdes, sugere- se que tal pratica niio seja adoptada. 4.7.1 Representagao Grafica Em UML os pacotes sio representados graficamente por uma pasta (fabbed folder) com duas zonas complementares: um pequeno rectingulo (designado por tabula- dor ou fab), normalmente com 0 nome do pacote; ¢ um rectingulo maior onde normalmente se especificam os elementos constituintes desse pacote ou, pelo menos, os seus elementos piblicos.CapiTuLo 4 - UML — VisAo GERAL 119 a Utiizadores | (1) +UAnénimo @) +URegstado -Utlizador Regras de Negocio package (‘Docentes') dentro de outro packege ("DE") asl 1 ] Y ® DE! _ = DEI DEI DEI:Docentes oS Docentes - t = F {version=1.4} |__fversion=1 4} pea | oo Docentes Docentes Figura 4.14: Excemplos a representagio de pacotes. A Figura 4.14 ilustra alguns exemplos de representagao de pacotes. No exemplo (1) © pacote tem o nome Utilizadores e descreve os seus elementos. Os simbo- los “+”, ““ ¢ “#” representam informagao de visibilidade, respectivamente visibi- lidade publica, privada e protegida (ver secco seguinte para mais detalhes). O exemplo (2) ilustra uma forma alternativa de representar um pacote em que nao sao apresentados os seus elementos. O nome do pacote Regras de Negécio encontra-se colocado no meio do rectiingulo maior. Por fim, o exemplo (3) ilustra dois aspectos interessantes. Por um lado, a possibili- dade de relagdes de hierarquia ou de inclusio entre pacotes: 0 pacote Docentes esta contido no pacote DET e pode set identificado univocamente pela concatena- cio dos varios nomes separados pelo simbolo “:”. Outro aspecto interessante 6 4 possibilidade de caracterizar 0 pacote através dos mecanismos comuns discutidos na Seccio 4.6, tais como especificacio de marcas (e.g., {(version=1.4}), este- re6tipos ou testricées. 4.7.2 Relagdes entre Pacotes Os pacotes apresentam entre si diferentes tipos de relagdes, em particular relaces de importacao, exportacao e generalizagao.120 CENTRO ATLANTICO ~ UML, METODOLOGIAS E FERRAMENTAS CASE ~ VOL. | Visibilidade og 08 simbolos “+”, ¢ SH" (ou equivalentes, que sfo suportados por diferentes S ferramentas CASE), a semelhanga do que acontece na especificagio de atributos € & operagdes de classes, permitem indicar o tipo de visibilidade que os elementos & comstituintes de um pacote apresentam. = Um clemento com visibilidade publica (prefixado com 0 simbolo “+”) pode ser usado/referenciado pot qualquer outro elemento independentemente do local onde é definido. = Um elemento com visibilidade privada (prefixado com 0 simbolo “-”) pode ser usado/referenciado por elementos definidos no mesmo pacote. = Um clemento com visibilidade protegida (prefixado com o simbolo “#”) pode ser usado/referenciado por um elemento definido no mesmo pacote ou num outro pacote que seja uma especializacio (através da relacao de heranga) do primeiro. = Um elemento com visibilidade de pacote (e., prefixado com o simbolo «~) pode set usado/referenciado por qualquer elemento definido no mesmo pacote, onde o primeiro é definido. ‘A semelhanca do que acontece com algumas linguagens de programagio (¢.g., C++) telativamente @ relacao entre classes, é possivel definir-se uma relagio de friend entre dois pacotes (¢ uma relacio de dependéncia entre pacotes, com estered- tipo «friends). Neste caso, um pacote que ¢ friend de outro pode aceder/referenciar todos os seus elementos independentemente da sua visibilidade. Contudo este tipo de dependéncia deve ser evitado sempre que possivel porque viola os principios do encapsulamento ¢ da minimizacio de dependéncias. Importagao e Exportagao Por definigio, um pacote faz a exportago de todos os seus elementos publicos. Mas tal facto nfo implica que um clemento definido noutro pacote possa ace- det/referenciar um elemento exportado num outro pacote. Para que tal pudesse Conceito ocorrer deveria existir explicitamente uma relacio de importagio entre esses dois pacotes, ‘A relagio de importagao é uma relacio de dependéncia entre pacotes, especifi- cando que 0 pacote base importa todos os elementos piiblicos definidos no pacote destino, ou seja, que os elementos piblicos definidos no pacote destino podem ser usados por elementos no pacote base. A relagio de importagio é representada gra- Conceito ficamente através de uma linha dirigida, a teacejado, com esteredtipo «import».121 04-UML— VisAo GERAL + Consulta Lista de Membros Consults Refaréncas EleciSnicas CConata Tetmos Ofcials + Sunscreve Registo de Memtro Importagao imports Caren unambre [@ + Conigura Opgser Peasoats | + Consulta Temas Proposios |@ + Propie Termo : J + Recede Penodioamente Novas Term Je + Submete Opinido sobre Provasta + Tempotizader @ + wansnime Q + uses: Q + UMembro scimports | + Aceita Pedido de Mambro |@ + Activa Membre |& + Cancela Membro }@ Contiguia Pardmetios Glebais @ Consulta Pedidos de Membros © + Gere Pedidos de Membros |@ + Relelta Pedido de Membro |@) + Suspende Membro Exportagao Figura 4.15: Relagoes de importagao/ exportacéo entre pacotes. Por exemplo, segundo a Figura 4.15, 0 pacote Casos-UGestor importa (todos os elementos piblicos definidos em) Casos-UMembro, ¢ este por sua vex importa todos os elementos piblicos definidos em Casos-UAnénimo. Note-se que a relagio de importacio nao € transitiva. No exemplo da Figura 4.15, o Casos-UGestor importa Casos-UMembro, e este importa Casos- UAndnimo, no entanto Casos-UGestor nio importa o Casos-UAnénimo. Isto significa que os elementos definidos em Casos-UGestor podem aceder ‘aos elementos ptblicos de Casos-UMembro, mas niio aos de Casos- UAandénimo. Para que tal fosse possivel, dever-se-ia definir explicitamente uma relacio de importagao entre esses dois pacotes. Note-se também que a relacio de importacio nao € simétrica. Ou seja, 0 facto dos elementos definidos em Casos-UGestor poderem aceder aos elementos piblicos de Casos-Membro nfio implica que 0 inverso seja verdade. Preferencialmente, os elementos exportados por cada pacote devem ser do tipo interface, uma vez que providenciam uma interface de programagio sem revelarem122 CENTRO ATLANTICO — UML, METODOLOGIAS E FERRAMENTAS CASE — VOL. | os detalhes de implementagio ¢ as relagdes de classes definidas internamente no respectivo pacote. Generalizagao ‘A relagao de genetalizagio entre pacotes semelhante 4 homdloga existente entre classes, ¢ é usada para a especificagao de familias de pacotes, tipicas em sistemas complexos ou flexiveis (¢.g,, significativamente parametrizaveis, multi-plataforma, multi-linguagem). ‘A Figura 4.16 ilustra uma relacio de generalizagio entre pacotes, em que um hipotético pacote WebServer é especializado por dois pacotes distintos: Sun- ISP, que especializa o pacote de topo segundo a tecnologia da Sun (Java Server Pages e Servlets); e MS-ASP.Net, que providencia a mesma funcionalidade segundo a tecnologia equivalente da Microsoft (ASP.NET). WebServer Generalizagao / Especializagao ears MS-ASP.Net Figura 4.16: Relagoes de generalixacdo entre pacotes. 4.7.3 Tipos de Pacotes Na generalidade dos exercicios académicos a dimensio ¢/ou a simplicidade do problema faz com que um pacote seja “simplesmente” um pacote. Contudo, em situacdes reais de modelagio de sistemas de média ou grande dimensio, realizada por equipas de vitios individuos, torna-se necessitio tipificat os proprios pacotes.CapiTULo 4 - UML - Visho GeRAL 123 ‘A especificacio UML prope uma variedade de estereétipos que ajudam a caracte- a semintica de pacotes: + «system: pacote que representa o sistema global; tipicamente este pacote agrega pacotes dos restantes tipos (subsistema, fachada, etc.). + «subsystem: pacote que representa uma parte constituinte do sistema inteiro. = qenodely: pacote que especifiea de modo geral a agregagio de um ou mais modelos UML. = facade»: pacote com elementos (tipicamente classes ¢ interfaces) que consti- tuem a fachada (ou a interface de programacio) providenciada conjunta e coe- rentemente por outros pacotes. A fachada permite esconder os detalhes de arquitectura e de implementagio de varios elementos eventualmente organiza- dos em distintos pacotes. Os clementos definidos numa fachada apenas refe- rem outros elementos definidos nouttos pacotes. = aframeworko: um framenork & uma arquitectura de classes ¢ interfaces com iniimeros pontos de vatiabilidade ou de extensio ¢ com estruturas de objectos padronizadas, conhecidas por padroes de desenho. O desenvolvimento de sistemas baseados em frameworks ¢ em componentes de software é um tépico emergente extremamente actual. # «stub»: um adaptador (stb) é usado quando se pretende partir um sistema em diferentes pacotes por motivos de divisio de trabalho, quer em termos fisi- cos/espaciais, quet em tetmos temporais. Os adaptadores permitem que duas equipas consigam trabalhar paralelamente em diferentes locais, mas mantendo algum nivel de interdependéncia. Em geral os pacotes mais usados sio do tipo sistema ¢ subsistema, podendo con- tudo, surgir situagdes em que um pacote é claramente do tipo fachada, adaptador ou framevork. Por omissio assume-se que um pacote é do tipo sistema (se for de primeiro nivel) © subsistema (se for de segundo ou mais nivel). Recomenda-se a consulta da Seccio 9.4 para uma melhor compreensio dos tipos de pacotes acima refetidos, em particular, dos conceitos de framework, fachada e familias de aplicagio. 4.7.4 Modelagao de Grupos de Elementos Compete a cada proceso de desenvolvimento de software formalizar ou dar sugestdes relativamente & forma de organizar todo 0 processo através de uma estrutura adequada de pacotes. Este aspecto é analisado na Parte 3 do livro. Referem-se, no entanto, algumas das formas clissicas de organizacio dos artefac- tos de projectos em termos de pacotes, por exempl