Captulo 14: Modelagem da Arquitetura da Aplicao Organizar o seu trabalho uma das coisas mais importantes que voc

c faz. H uma srie de dispositivos apresentados pela UML para ajudar a organizar pacotes, os sistemas, subsistemas e modelos. Este captulo apresenta os dispositivos e fornece uma viso geral da abordagem Processo Unificado Rational (RUP) para organizar o seu trabalho. Pacotes de modelagem O pacote a construo principal em UML para agrupar os elementos do modelo. Um pacote fornece exatamente a mesma funcionalidade que uma pasta no Windows. Ele permite que voc organize elementos agrupando-os e colocando-os em um recipiente. Os pacotes podem conter outros pacotes, assim voc pode criar uma hierarquia de pacotes. Namespaces Um pacote tambm oferece um espao de nomes para classificadores que voc coloca no pacote. O namespace palavra familiar para os programadores C + +. Isso significa que uma vez que voc colocar um elemento de um determinado tipo em um pacote, o seu nome torna-se nico para um elemento desse tipo no pacote. Voc pode criar um elemento de mesmo nome em um pacote diferente, e ter uma definio diferente. Mais uma vez, pensar em termos de Windows Explorer: Voc pode ter um documento do Word chamado UML_Bible.doc em uma pasta chamada X que contm contedo completamente diferente do que um documento do Word chamado UML_Bible.doc em uma pasta chamada Y, ou em uma pasta chamada Z colocado dentro da pasta com o nome X. Os dois documentos tm o mesmo nome, mas porque esto em pastas diferentes, eles so completamente independentes um do outro. Cada pacote tem um namespace associado. Namespaces de pacotes em diferentes nveis da hierarquia containership pode ter o mesmo nome tambm. Por exemplo, voc pode ter um pacote chamado X colocado dentro de um pacote chamado X. Os dois pacotes so distintos e contm diferentes contedos. Um pacote no pode conter em si. Figura 14-1 mostra um pacote X contido em outro (diferente) do pacote X.

Figura 14-1: estrutura de pastas no Windows. Notao pacote Um pacote representado por um smbolo pasta. O nome do pacote pode ser colocado no meio do smbolo, ou na guia do lado esquerdo superior da embalagem, conforme mostrado na Figura 14-2. Normalmente colocado no guia se voc est desenhando o contedo do pacote dentro do smbolo prprio pacote.

Figura 14-2: a notao de Pacote. Um pacote pode ser estereotipada, caso em que o esteretipo listado dentro aspas acima do nome do pacote. Um pacote tambm pode ser abstrata, que simbolizada com a palavra {abstract}, incluindo as chaves, colocado abaixo do nome. O que um pacote contm Um pacote simplesmente um mecanismo de agrupamento geral em que voc coloca classificadores UML, tais como definies de classe, as definies de Casos de Uso, as definies de Estado, as relaes entre esses classificadores, e os diagramas em que estes classificadores podem ser representados. Existem trs tipos de elementos que voc pode colocar em um pacote de elementos de propriedade da prpria embalagem, elementos intercalados ou importado de outro pacote, e elementos acessado a partir de outro pacote, que basicamente visitam o pacote atual. Mesclar e Acesso as relaes entre os pacotes so discutidos na prxima seo. Outros pacotes podem existir dentro de um pacote, para uma infinita do assentamento, cada pacote de proporcionar um espao nico para todos os elementos dentro dele. Um pacote tambm pode conter vrios diagramas de todos e quaisquer tipos de UML. Notao para mostrar os elementos de um pacote Para mostrar que um elemento pertence a um pacote, voc pode criar um hiperlink a partir dele para outro diagrama, e mostrar o contedo do pacote em que o diagrama. Isto tipicamente como voc representar o contedo de pacotes de ferramentas de modelagem. Ou, voc pode simplesmente desenhar os elementos dentro da poro retangular grande do smbolo do pacote, como mostrado na Figura 14-3. Uma notao alternativa desenhar os elementos fora do smbolo do pacote, e anex-las a ele, com linhas que so agrupados no final do pacote por um crculo com uma marca de mais (+) no interior, tambm mostrado na Figura 14-3.

Figura 14-3: Vrias notaes para desenhar um pacote e elementos (classes neste exemplo) dentro dele. O pacote do lado esquerdo agora tem um hiperlink para outro diagrama (no mostrados).

Na maioria das vezes voc vai usar uma ferramenta de modelagem para desenhar elementos em um diagrama que pertence ao pacote. Lembre-se que alguns elementos, tais como requisitos ou atributos de classe ou mtodos, no so representados graficamente em diagramas. Uma vez traada em um diagrama que est dentro de um pacote, os elementos, incluindo outros pacotes, tornam-se contidos no pacote. Voc , em essncia, a criao de hiperlinks a partir de um smbolo pacote para diagramas criados para o pacote que mostram as informaes do pacote expresso graficamente. Como voc construir diagramas e pacotes desta forma, a ferramenta de modelagem apresenta a estrutura de seus pacotes em um navegador Windows Explorer-like, como mostrado na Figura 14-4. Cada pacote contm elementos UML ou definies, e diagramas de vrios tipos em que essas definies podem ser representados.

Figura 14-4: estrutura Pacote mostra a organizao do projeto. Classificadores contida em um pacote tem uma propriedade que determina se eles esto visveis para os classificadores em outros pacotes. Essa visibilidade pode ser pblica ou privada: Pblica (+): um classificador pblico visvel para classificadores em outros pacotes que tm um acesso ou Mesclar relao com o pacote contendo o classificador pblico. , claro, visvel para outros classificadores no pacote em que reside. Visibilidade pblica indicado por um smbolo + (plus) precedendo o nome do classificador. Privado (-): um classificador privado visvel apenas para os classificadores no pacote em que reside. Ele no visvel para classificadores em outros pacotes. Visibilidade privada representada por um smbolo - (menos) precedendo o nome do classificador.

Algumas ferramentas de modelagem permitem-lhe mostrar ou ocultar os classificadores de um pacote baseado em visibilidade. Por exemplo, uma ferramenta pode permitir-lhe para apagar a exibio de classificadores privados de forma que somente os classificadores pblicos so mostrados em um pacote. Dependncia de pacotes de modelagem Como voc modelo, muitas vezes voc construir relacionamentos entre um classificador em um pacote e outro classificador em um pacote diferente. Para este modelo em um diagrama pertencentes a um dos pacotes, voc precisa acessar ou importar / mesclar o classificador a partir do segundo pacote. Acesso Quando voc acessa um classificador em outro pacote, que classificador permanece em seu pacote, e voc simplesmente construir uma relao com ela. Voc desenha um classificador no pacote em que voc est trabalhando e mostrar que ele pertence a um pacote diferente, especificando o nome do seu pacote antes de seu nome, como PackageName:: ClassifierName. Como voc desenha esta relao entre os classificadores dos pacotes diferentes, voc tambm de modelagem que o pacote fonte tem uma relao de acesso ao segundo, ou alvo, pacote. Uma relao entre dois pacotes de acesso desenhada como uma dependncia linha tracejada com uma seta aberta ponta de seta, etiquetado com o esteretipo acesso. Estabelece o fato de que todos os classificadores no pacote fonte pode legalmente referncia classificadores pblico no pacote de destino. No obrigatrio para desenhar a relao entre os pacotes de acesso antes de desenhar as relaes entre seus classificadores, voc pode desenhar a relao entre os classificadores em primeiro lugar. Algumas ferramentas de modelagem automaticamente desenhar o relacionamento Access correspondente entre os pacotes depois da relao entre os classificadores desenhado. No exemplo mostrado na Figura 14-5, uma Overnight_Shipment classe das Ordens Produto pacote tem uma associao para o Gerenciador de classe do pacote Human_Resources. Esta associao permitido porque uma relao de Acesso foi elaborada a partir do pacote Pedidos Produtos para o pacote Human_Resources.

Figura 14-5: A classe Overnight_Shipment tem uma associao com a classe Manager do pacote Human_Resources porque seu produto pacote Pedidos tem uma relao de dependncia de acesso ao pacote Human_Resources.

Nota importante lembrar que para a relao entre os classificadores a ser desenhado, o acesso (pblico ou privado) do classificador no pacote de destino deve ser suficiente. Se estiver em um pacote diferente, ele deve ter acesso pblico.

Mesclar e Importao 1.x UML permite que voc especifique um relacionamento Import entre os pacotes, o que significa que voc pode trazer uma cpia de um classificador de outro pacote para o pacote que voc est trabalhando dentro A nova cpia do classificador importado pertence ao pacote que voc importou em, enquanto sua verso original ainda existe em sua embalagem original. Na UML 2.0, a relao entre os pacotes de Importao subsumida na relao Merge. Mesclagem leva em conta o fato de que voc precisa para resolver conflitos de nome ao importar alguns classificadores. Ele especifica como lidar com uma situao onde voc mesclar em uma classe chamada Cliente de outro pacote, mas seu pacote j contm uma classe chamada Cliente, com seu prprio conjunto de propriedades. Fuso classificadores de outros pacotes uma coisa vantajosa para fazer. Como voc e os outros modelos, vrios elementos de mesmo nome, que significam a mesma coisa pode ser criada em pacotes diferentes. Mesclar permite que voc especifique que estes elementos se fundiram para o pacote que voc est trabalhando. Por exemplo, digamos que voc est trabalhando com a classe Manager no pacote de pedidos de produtos, e no h outra classe Gerente no pacote Human_Resources com seu prprio conjunto de atributos e mtodos e valores de outras propriedades. No entanto, a classe Manager realmente destinado a ser a mesma classe em ambos os casos. Como voc modelo no pacote de pedidos de produtos, voc pode optar por mesclar a outra definio da classe Manager para o pacote no qual voc est trabalhando, como mostrado na Figura 14-6.

Figura 14-6: Exemplo mostra pacotes antes e depois da fuso fuso. A classe Gerente no pacote Human_Resources tem o nome de atributos, que de carter tipo e comprimento 26, e Employee_Number. A classe Manager no pacote Pedidos

produto tem um atributo de nome de personagem tipo e comprimento 52. Quando o pacote Human_Resources incorporado ao pacote de pedidos de produtos, a classe Manager em Ordens Produto herda o atributo posio de Human_Resources:: Manager. Uma vez que j contm um atributo de nome, ela substitui a definio do atributo Nome da classe Gerente do pacote Human_Resources, portanto, seu carter permanece tipo de comprimento 52. Embora no seja mostrado na figura, cada classe tambm tem um valor de descrio marcados, para o qual Ordens de produto:: Gerente mantm seu prprio valor, substituindo o valor descrio fundiu ao longo da classe Manager em Human_Resources. Quando esta fuso acontece, a classe Manager no pacote de encomendas do produto pode ser considerado como uma especializao da classe Manager no pacote Human_Resources. A classe Gerente herda os atributos da outra classe, e substitui os tipos e valores de quaisquer atributos comuns. Na verdade, voc pode considerar a relao direta de desenho entre dois pacotes como uma forma de atalho de desenhar um relacionamento de herana entre o classificador em um pacote e do classificador de mesmo nome que voc esto se fundindo a partir de outro pacote. A relao direta entre dois pacotes desenhado como uma dependncia linha tracejada com uma seta aberta seta, etiquetado com o esteretipo fuso. Apagando um pacote Quando voc excluir um pacote, voc excluir todos os elementos contidos por ele que ele possui, incluindo pacotes aninhados e seus elementos de propriedade. Elementos que so "visita" de outro pacote atravs de um relacionamento de acesso no so excludos, eles ainda existem em seu pacote de possuir. Elementos que foram fundidos em um pacote de fora continuar a existir na sua embalagem original. Elementos do pacote de excludos que esto sendo usados em outros pacotes, atravs de acesso ou relacionamentos Merge, so excludos os pacotes. Observao A excluso de um diagrama no exclui os elementos que so representados no diagrama. Eles continuaro a existir no pacote.

O diagrama de pacote Um pacote pode conter qualquer nmero de diagramas de qualquer tipo UML. Um tipo de diagrama especfico que tem causado alguma confuso entre os modeladores UML o diagrama de Pacotes. Em 1.x UML, o diagrama de pacote no especificado como um tipo de diagrama. simplesmente um diagrama esttico, como o diagrama de classes, em que voc desenha apenas pacotes. UML 2.0 esclarece a questo, especificando um diagrama. Se voc desenhar principalmente pacotes sobre ele, voc pode chamar isso de um diagrama de Pacotes. Se voc desenhar principalmente aulas sobre ele, voc se referir a ele como um diagrama de classes. Se voc desenhar objetos sobre ela, um diagrama de objeto. Se voc desenhar uma combinao dos trs, ento voc pode cham-lo de que voc gosta. Desenho de um diagrama de pacote opcional. Voc no precisa criar um diagrama que mostra subpacotes de um pacote a menos que voc deseja mostrar seu confinamento, ou gostaria de chamar as relaes entre os pacotes. Para expressar conteno de subpacotes dentro de um pacote, voc tambm pode simplesmente definir essas relaes e confiar

em sua ferramenta de modelagem para refletir a hierarquia dos pacotes do seu projeto em seu navegador. Figura 14-7 mostra um diagrama de classes para o Modelo de Casos de Uso do pacote. Na rea de trabalho diagrama, o subpacotes do pacote Modelo de Casos de Uso so desenhados. Uma vez que os pacotes s so desenhadas, voc pode considerar isso um diagrama de Pacotes. O diagrama normalmente no seria necessria porque a hierarquia do pacote mostrado no navegador esquerda. No entanto, neste caso, o diagrama fornece uma agregar valor, uma vez que tambm mostra um acesso relao entre o pacote de encomendas do produto e da embalagem de Recursos Humanos.

Figura 14-7: Diagrama de pacotes desenhado com um diagrama de classes. Ele mostra todas subpacotes de um pacote.