Toda materia onlne Modelagem de Sistemas

Prévia do material em texto

Aula 1
Você sabe o que é mundo real? E mundo simbólico?  Neste tópico, vamos desenvolver esses conceitos.
A passagem do mundo real para o mundo simbólico é feita pelos sentidos , criando-se “imagens” no mundo simbólico sobre uma realidade. Sobre essa imagem, vamos fazer as mais diversas inferência e tomadas de decisão. Assim, é fácil perceber que se a primeira imagem do mundo real for representada errada todo o processamento estará comprometido. Hoje, a tecnologia tem ampliado a nossa capacidade de processamento no mundo simbólico. Pode-se representar mundo real por fotografia, filme, transmissão ao vivo, texto.... 
O outro ponto estratégico é a capacidade de interpretar para o mundo real uma imagem processada. Ao vermos uma fotografia, papel com gravuras, mas a nossa mente é capaz de imaginar uma cena em três dimensões. O mesmo ocorre quando se vê televisão. A nossa mente é capaz de imaginar o tamanho das pessoas, de coisas, baseada no conhecimento que já temos do mundo real. 
Um sistema de informações processa dados (imagens do mundo real) ,segundo conceitos estabelecidos pelo mundo simbólico da empresa. Um sistema, embora físico, faz processamento de imagens, portanto manuseia mundo simbólico. 
Para modelar um sistema, temos que nos preocupar com o mundo simbólico da empresa, como ela “pensa” que imagens são importantes para este tratamento. Que “representação de objetos” devemos armazenar? Como usá-los? Como identificá-los? É nesse ponto que nossa disciplina é importante. Nela vamos desenvolver técnicas e aprender a usar ferramentas padronizadas nas representações de mundo simbólico da observação feita do mundo real.
Mundo real: existe fora da gente, é diferente a cada momento. 
Mundo simbólico: é o mundo das representações e manuseio de informações.
Processo de Software
Passos necessária para a fabricação. Conjunto de atividades organizadas para o desenvolvimento de um software.
Dependendo das características do software que vamos desenvolver, podemos escolher umd os diversos tipos de processos. Prototipação, cascatas, espiral, e XP são algumas das propostas de processos de software. Existem outros, você estudar estes processos e quando devem ser utilizados na cadeira de Engenharia de Software.
Processo Unificado (PU): Permite que se possa fazer o desenvolvimento aos poucos e que mudemos definições de etapas.Assiim podemos desenvolver o projeto de forma estratégica, entregando por partes ao usuário até o seu termino. Permite tb incrementar modificações.
É um processo interativo e consiste em subdividir o projeto em partes. Ele é constituído por quatro fase:
Fase da Concepção: fase onde definimos o escopo do produto, se imagina o produto o que ele fará seu objetivo e principais funções.
Fase da elaboração: fase onde cada função, segundo o escopo do produto, recebe um detalhamento técnico. Inicia a identificação de requisitos funcionais e não funcionais. Nessa fase surge o projeto.
Fase da construção: realização da programação, definição de arquivos, teste pra vê o que se imaginou virando realidade.
Fase de transição: realização da implantação do sistema, testes de integração e aceitação, fase responsável por disponibilizar o produto para uso.
RUP – Rational Unifed Process – é uma plataforma de desenvolvimento de software configurável. É constituído de um conjunto de templates que devem ser gerados durante o desenvolvimento. Implementa-se o PU. Permite definir uma iteração sempre que necessário.
Aula 2
UML
UML foi desenvolvida por Grady Booch, James Rumbaugh e Ivar Jacobson, que são conhecidos como “os três amigos”.  UML  é um conjunto de diagramas padronizados e integrados para ajudar na descrição da análise e projeto de um software.  O UML, foi proposto em 1976, com objetivo de padronizar o uso de ferramentas.  Nessa época existiam vários autores, propondo soluções para a modelagem.  O surgimento do UML possibilitou uma padronização e apóia o projeto de software, desde seu levantamento de requisitos até sua implantação.  O UML , hoje, é controlado pelo OMG.
O UML é um conjunto de diagramas, como mostrado na imagem.
Linguagem de modelagem que irá se associar ao processo para formar método. Representação desenvolvida a partir da aplicação de técnicas com características próprias para atender a natureza da aplicação em estudo. Técnicas possuem uma comunicação direta e se completam. É um conjunto de diagramas padronizados e integrados para ajudar na descrição da análise e projeto de um software.  
Objetivo de padronizar o uso de ferramentas. UML possibilitou uma padronização e apóia o projeto de software, desde seu levantamento de requisitos até sua implantação.
A UML foi definida para ser utilizada na Metodologia Orientada a Objetos, o que significa que ela possui recursos para representação dos conceitos propostos pela metodologia.
Objetivo: Ser independente da linguagem de programação e processo de desenvolvimento. 
Análise Orientada Por Objetos
A orientação a objetos tem-se desenvolvido  desde o lançamento da 1ª linguagem orientada a objetos, a SIMULA.  Autores consagrados da engenharia de software, como:  Peter Coad, Edward Yourdon e Roger Pressman, consideram  a análise orientada a objetos como o maior avanço para o desenvolvimento de software.
 
A orientação a objetos não é só teoria, mas uma tecnologia de eficiência e qualidade comprovadas, usadas em inúmeros projetos e para construção de diferentes tipos de sistemas.
Quando o sistema é desenvolvido com esta tecnologia, tem-se:
Melhor reaproveitamento de seu código;
Facilidade de manutenção;
Melhor compreensão do código;
Mais segurança no uso de componentes por parte do programador;
Diagrama de caso de uso
Você sabe o que é um requisito de um usuário?  Sabe como identificá-lo?
A documentação de um caso e uso é muito extensiva e, alguns casos e uso, podem apresentar um conjunto de tarefas repetidas.  Isso quer dizer que estamos documentando duas ou mais vezes a mesma coisa.
Para evitarmos isso, antes de documentarmos o fluxo principal, podemos analisar a descrição dos casos e uso de levantamento e identificarmos conjunto de tarefas iguais.  Esse conjunto de tarefas iguais devem ser destacadas, pois, um dos nossos objetivos é não gerar redundância e re aproveitar código e isto deve ser feito desde o início da análise.
Modelo aplicado para representar os requisitos de sistema.
O que são requisitos? São as necessidades dos usuários, as funcionalidades necessárias para realizar o negócio.
Quais são os tipos? Funcionais: ligados a produção da aplicação. Não-funcionais: necessidades de ambiente e estrutura operacional (operacionalidade, ambiente operacional, etc.);
Nome do caso de uso: ser identificado por verbo e ter o significado claro
Ator: responsável por realizar o caso de uso
Interação Caso de Uso-Ator: representa a realização. <include> estabelece a ligação obrigatória entre os casos de uso. SEMPRE o caso de uso será executado. <extend> estabelece a ligação opcional entre os casos de uso. O caso de uso será executado em atendimento a uma regra de negócio.
Generalização de Ator: representa a classificação de um determinado ator, deve ser usada quando tem mais de um ator
Generalização de sCaso de Uso: Concentra em um caso de uso um conjunto de procedimentos que serão utilizados por vários outros casos de uso que possuem outras particularidades	
Uso de estereotipo
Você verificou que usamos um palavra entre <<        >>.  Isto é, para indicar o que chamamos de estereótipos.  Um estereótipos é uma série de características que servem para classificar alguma coisa.  No diagrama, o estereótipos indica que devemos dar o mesmo tratamento de análise e construção, quando formos construir o sistema.  Assim, o <<include>> indica que devemos tratar todos os arcos da mesma forma (sugiro o tratamento por função ou módulo).  É comum, também, se usar << use >>, com as mesmas características.
O << EXTENDED>> indica o tratamento comum.  Se eu fosse o desenvolvedor, sempre trataria os elementosgerados a partir destas elipses como especiais e os separaria dos demais.  Existem, ainda, o << INTERFACE>>, que é o arco entre o ator e o comando de utilização, nesse caso se informa que o tratamento de chamada deve ser feito do mesmo modo, por exemplo: com telas de entrada. Você pode criar o seu próprio estereótipos, por exemplo: <<ORACLE>> pode indicar que você deseja que os elementos da elipse marcadas com este estereótipos deverão ser implementadas no ORACLE.   O importante é que se apresente o dicionário de estereótipos.
Erros comuns
Muitas pessoas mal informadas consideram o diagrama de caso e uso como se fosse um DFD.  Isto é um erro grave.  O diagrama representa conjunto de atividades.  Os arcos não indicam fluxos de dados.  São chamadas a grupos de atividades.
Assim, é comum vermos diagramas de caso e uso mal feitos, representando programas, como o mostrado abaixo:
Aula 3
OBJETO: todo elemento que representa ou compõe algum conceito dentro de nosso projeto. CLASSE: conjunto de objetos com atributos e comportamentos representados por métodos. Ex.: Classe CLIENTES representa todos os clientes da empresa. ATRIBUTO: característica ou identificação do objeto. Ex.: nome, cpf, email, ...MÉTODOS: operações realizadas para um objeto. Ex.: lerNome() 
Diagrama de Classe
O diagrama de classes é o principal dos diagramas do UML.  O diagrama é como uma fotografia dos elementos usados pela aplicação.  É uma representação estática e não deve ser usado para representar dinâmicas da aplicação, embora também as retrate, como veremos.  Existem vários níveis de diagrama de classes, eles são usados no nível de domínio – conceitual – e em nível de projeto.  Nesta aula vamos abordar o diagrama de classes a partir da observação do mundo real para um determinado contexto, vamos construir o diagrama, em nível de domínio.  Isto é, não se devem representar estruturas de projeto (chaves, arquivos, campos...).  O foco da análise é o negócio.  Imagine que você está no século 15 e que não tem computador – quando estiver fazendo esse modelo.
Identificando Classe
Uma classe é uma forma de representarmos no mundo simbólico um conjunto do mundo real.  Ao observar um conjunto sobre o qual temos alguns interesses  dizemos que temos uma classe.  As propriedades que desejo observar  são chamado de atributos.
Representando  Uma Classe
Existem várias formas gráficas para se representar uma classe, mas em UML, quando temos interesse em um conjunto do mundo real, desenhamos:
	Nome da classe ou Elemento de OBS
	
Propriedades que interessa em observar ou atributos
Queremos observar um conjunto de pessoas, e as informações sobre as quais temos interesse são: nome, endereço, telefone, CPF
	Pessoa
	Nome
Endereço
CPF
Telefone
Ao definir a classe de domínio, definimos um modelo de representação dos elementos do conjunto:
Assim, os elementos 
(Manoel, Rua do Bispo-3, 32116734, 371622571)
(José, Rua Ava-34, 3226216, 37162225881)
Fica representado:
	Pessoa
	Manoel
Rua do Bispo – 3
371622571
32167878
Observe que colocamos os valores que os atributos assumem nas representações.  Nesse caso, dizemos que a classe foi INSTANCIADA, ou seja, recebeu valores.  Cada um dos elementos no mundo das representações é chamado de um objeto da classe.  Então, uma classe representa um conjunto e os elementos do conjunto – objetos – são representados segundo a definição da classe.
Uma classe é a descrição de um tipo de objeto do mundo real.
Usam-se classes para classificar os objetos que identificamos no mundo real.
As classes devem ser retiradas do domínio do problema.
Uma classe completa,  no UML, é  representada por um  retângulo dividido em três compartimentos: o compartimento de nome, que conterá apenas o nome da classe modelada, o de atributos, que possuirá a relação de atributos que a classe possui e o compartimento de operações chamadas de  métodos. Nós veremos o que é método e sua modelagem em aulas futuras
Composição de uma classe no UML: NOME DA CLASSE, PROPRIEDADES A OBSERVAR (ATRIBUTOS)
Relacionamentos: 
Outro elemento importante, para a modelagem de classes, é o relacionamento.  Aqui, o relacionamento tem o mesmo conceito matemático estabelecido em teoria dos conjuntos.  Tem-se um relacionamento, quando estabelecemos alguma “ligação”, do nosso conhecimento, entre os conjuntos.  VIU... Não é uma ligação física... é uma ligação do nosso conhecimento – ou do domínio da aplicação- por isto, não tem como se constatar fisicamente.  É um elemento conceitual. Reflete o conhecimento a respeito de alguma coisa.  Só existe no mundo simbólico.
Um relacionamento é um estabelecimento conceitual entre elementos de um conjunto com outro que depende de que aspecto do mundo real estamos analisando.
Tem-se um relacionamento, quando estabelecemos alguma “ligação”, do nosso conhecimento, entre os conjuntos.
Tipos Relacionamentos: 0..* (um veiculo pertence a um aluno), 0...1 (um aluno tem 1 ou zero pai vivo), 1..* (um aluno cursa uma ou varias disciplinas), padrão 1...1
Multiplicidade Dos Relacionamentos:
Uma informação importante, quando trabalhamos com os relacionamentos é de como os elementos do conjunto se comportam em relação ao outro.  Quando eu tenho um conjunto  A e um conjunto B, na matemática um relacionamento representa um par (a,b) onde a pertence ao conjunto A e b pertence ao conjunto B.
Pode ser que todos os elementos de A tenham o par (a, b), neste caso se fala PARA TODO a pertencente ao conjunto A temos uma imagem b no conjunto B.   Observe que não INTERESSA como chega ou para quem chega ao conjunto B.
Existem quatro possibilidades de multiplicidade do conjunto A em relação ao conjunto B:
Primeira Situação
Analisando A verificamos que de todo elemento do conjunto A sai uma flecha:
Neste caso representamos esta informação junto ao relacionamento no sentido da leitura
LEMOS: Todo Veículo pertence a UM aluno.
Segunda Situação
Observe que da situação anterior UM elemento do conjunto A não tem correspondente no conjunto B. Se existir um elemento (basta um) não ter correspondente que caracterizamos esta situação.
Existem alunos que TÊM  ZERO ou UM pai vivo
	
Terceira Situação
De todo elemento de A estabelecemos um relacionamento, mas existem ( no mínimo um) elementos que tem mais de um correspondente no conjunto B.
Lemos do seguinte modo: Um aluno cursa uma ou mais de uma disciplina.
Quarta Situação
No mínimo, um elemento pertencente ao conjunto a não tem correspondente em b e existem elementos no conjunto A com mais de uma imagem.
Na multiplicidade  0..N ou 1..N, estamos representando o mínimo e o Máximo de relacionamento de um elemento, na forma min..max, assim, pode se representar 3..10, indica que existem elementos no conjunto a com um mínimo de 3 correspondentes em B e no máximo 10 correspondentes no conjunto B.
Pode-se ainda substituir o N por *
Dica: De forma resumida para expressar a multiplicidade entre os relacionamentos, um intervalo indica quantos objetos estão  relacionados.  O intervalo pode ser de zero para um (0..1), zero para vários (0..* ou apenas *), um para vários (1..*), dois (2), cinco para 11 (5..11) e assim por diante. É também 
possível expressar uma série de números como (1, 4, 6..12). 
Se não for descrita nenhuma multiplicidade, então é considerado o padrão de um para um (1..1 ou apenas 1).
Classes Dependente
Existem alguns conjuntos que, no processo de modelagem, desejamos condicioná-los à existência de outros conjuntos. São chamados de conjuntos dependentes.  A dependência de conjuntos é uma ferramenta da modelagem.  Nesse caso, o modelador deseja que a identificação do conjunto dependente seja feita a partir do conjunto a.  A representação da dependência é por uma linha tracejada.
O diagrama significa que o familiar deve ser identificado a partir da identificação do empregado.  Na realidade, um objeto dependente só pode ser dependente de um único objeto, por isto é desnecessário a indicação da multiplicidade1.
Associações
Outro recurso importante é a associação.  Uma associação é um conjunto criado com objetivo de ligar outros dois (ou mais) conjuntos existentes.
As classes associadoras são representadas por linhas cheias e a classe que as associa é ligada a esta linha cheia por uma linha pontilhada.
Toda vez que tivermos um relacionamento de multiplicidade ( 0..*) para os dois lados do relacionamento, deve-se usar a classe associativa.  O modelo de classes de objetos é determinista, isto é, devemos saber quem se relaciona com quem, portanto  a multiplicidade 1 é obrigatória nos relacionamentos fora da estrutura associativa.
As classes associadoras são representadas por linhas cheias e a classe que as associa é ligada a esta linha cheia por uma linha pontilhada.
Classe que representa os objetos resultados de uma associação, com atributos, características e operações próprias.
PAPEL nome da associação, tornando claro no diagrama a ligação estabelecida. 
MULTIPLICIDADE define o número de vezes em que o objeto participa da associação. 
RESTRIÇÕES: Complementam o modelo com informações não representadas. 
AGREGAÇÃO POR REFERÊNCIA: Define o conceito <compõe> e associa os objetos indicando que existe referência para várias participações
AGREGAÇÃO POR VALOR: Define o conceito <estar inserido> associando os objetos indicando que existe referência para apenas uma participação e estabelece uma dependência entre as classes associadas.
Aula 4
Diagrama de Classe
O UML específica uma série de informações complementares aos conjuntos identificados do mundo real e seus respectivos relacionamentos.  Essas informações têm o objetivo da implementação.  Sim, porque não devemos esquecer que o objetivo é definir um sistema de informações. Alguns dos instrumentos apresentados são para outros diagramas e vamos aprender a usar estas  ferramentas em outros diagramas.
Completando as associações
Uma associação é um conceito que liga dois conjuntos, matematicamente  é um par (a,b) onde: a pertence a um conjunto e b pertence ao outro conjunto.
Quando apresentamos a associação, mostramos que existem duas informações  - do conjunto A para o conjunto B e do Conjunto B para o conjunto A – e representamos estas informações.  Estávamos NOMEANDO OS  relacionamentos mas,  na prática, não há necessidade de se qualificar estes relacionamentos, pois, o nosso principal objetivo é a multiplicidade.
O que o UML  define para se representar em um relacionamento:
Ordenação: caso se deseja informar que os veículos devem ser ordenados de forma crescente por ano. Nesse caso, indicamos junto ao conjunto com a palavra {ordenado}.
Qualificador: Quando necessitamos qualificar uma associação, com objetivo de reduzir a multiplicidade, é representada no relacionamento com um retângulo menor, onde se faz a qualificação.  A qualificação é uma informação para a implementação – é um conceito voltado para a programação – indica que, na implementação da nota fiscal, deve haver um objeto do tipo produto para cada objeto de item de nota fiscal.  Isto indica que não devem existir dois itens de nota fiscal para um mesmo produto.
Navegabilidade: classe instanciada podem-se acessar instâncias de outras classes que tem relacionamentos com a primeira classe.  Para indicar o sentido da NAVEGAÇÂO usamos uma flecha no final do relacionamento.  Assim: A navegação é de aluno, que é chamada de classe fonte; para veículo é chamada de classe alvo.  Isso indica que da classe aluno podem-se identificar os veículos de um aluno.  Mas, não é possível identificar o aluno dono de um veículo. As classes, normalmente, se relacionam de forma de bidirecional; por definição, a navegação pode ocorrer nos dois sentidos do relacionamento, exceto quando dito ao contrário.
Agregação: Quando desejamos que um conjunto fosse tratado de forma incorporada com outro conjunto. Uma agregação é uma representação que indica que o objeto é composto com outros objetos. Representa-se por um losango vazio, no relacionamento:
Composição: A composição é outra forma de tratarmos a estrutura toda-parte. Uma composição é uma representação que indica que o objeto é composto com outros objetos, tal qual na agregação; em uma agregação, após serem estabelecidas as relações, elas são inalteráveis; eles não poderão ser modificados. Na composição, o objeto todo contém os objetos parte.  Assim ao se instanciar o objeto todo, os partes também são instanciadas; também é chamada de agregação por valor.  Representa-se  o losango de forma cheia.
Especificador de Interface: Um classificador indica um comportamento esperado de um objeto, que está sendo relacionado.  Define o comportamento exigido para se estabelecer o relacionamento. :media>7 (ndica que o relacionamento é feito, quando a média (um dos atributos de aluno aprovado) é maior que sete.)
Mutabilidade: Indica se os relacionamentos estabelecidos são mutáveis (podem ser agregados, apagados).  Quando nada é dito, indica que nenhum indicador é necessário. A propriedade {congelado} indica que após ser criado, nenhum vinculo pode ser feito.  A propriedade {somarSomente} indica que os vínculos podem ser somados.
Visibilidade: A visibilidade é especificada para os atributos de uma classe e também entre classes.   Os indicadores de visibilidade para atributos são: publico, privado ou protegido. ----
Relacionamentos recursivos ou Autorelacionamento
criar relacionamento entre os elementos do próprio conjunto
Dica: É possível conectar uma classe a ela mesma, através de uma associação e que ainda representa, semanticamente, a conexão entre dois objetos; mas os objetos conectados são da mesma classe. Uma associação deste tipo é chamada de associação recursiva.
Apesar de o UML definir o autorelacionamento, no meu entender, não há necessidade de se usar este tipo de recursos, pois, fica pouco claro como ocorre o relacionamento e não se define que objetos estão associados.  Você já tem o recurso do subconjunto, portanto, basta modelar os subconjuntos e estabelecer o relacionamento entre eles.
Assim, no exemplo, temos dois tipos de equipamentos: Simples e Compostos – podemos definir dois subconjuntos e depois associar os componentes.
Sempre que possível, desenvolva a análise, identifique que objeto se relaciona com que objeto.  Isso evitará problemas, na fase de implementação do sistema.
Associação exclusiva: Uma associação exclusiva é uma restrição em duas ou mais associações. Ela especifica que objetos de uma classe podem participar de, no máximo, uma das associações, em um dado momento. Uma associação exclusiva é representada por uma linha tracejada entre as associações, que são partes da associação exclusiva, com a especificação “{ou}” sobre a linha tracejada.
Herança
Generalização : representa os vários tipos de um objeto em uma única classe.
Especialização: representa os vários tipos de um objeto em uma classe distinta relacionando seus próprios atributos e comportamentos. 
Aula5
Diagrama de Seqüência
Os casos e uso devem ser implementados, deve-se definir como devem ser implementados. Os diagramas de interação, que mostram como as classes interagem, são o diagrama de sequência e o diagrama de colaboração. Nesta aula vamos estudar os principais aspectos do diagrama de sequência. No diagrama de sequência estamos definindo que funções devem ser implementadas, se definir como é o código, para que o caso e uso possa ser realizado. O objetivo é identificar funções, que são as unidades para definir novas funções.
Comparando com fatoração de números, no diagrama de sequência “fatoramos” os caso e uso. Não confunda – Um diagrama de sequência mostra a sequência de execução de funções, portanto, não mostra troca de informação. Um diagrama de sequência é uma espécie de algoritmo de alto nível em que se destaca a chamada das funções.
Os casos e uso devem ser implementados, deve-se definir como devem ser implementados. Os diagramas de interação, que mostram como as classes interagem, são o diagrama de sequência e o diagramade colaboração. Nesta aula vamos estudar os principais aspectos do diagrama de sequência. No diagrama de sequência estamos definindo que funções devem ser implementadas, se definir como é o código, para que o caso e uso possa ser realizado. O objetivo é identificar funções, que são as unidades para definir novas funções. Comparando com fatoração de números, no diagrama de sequência “fatoramos” os caso e uso. Não confunda – Um diagrama de sequência mostra a sequência de execução de funções, portanto, não mostra troca de informação. Um diagrama de sequência é uma espécie de algoritmo de alto nível em que se destaca a chamada das funções.
Métodos: Um método é uma função que colocamos dentro da classe, isto quer dizer que a função está encapsulada e só pode ser executada a partir da classe. Não é uma boa prática de modelagem colocar métodos nas classes sem o desenvolvimento de um dos diagramas de interação.
Mensagem: Os objetos precisam trabalhar de forma coordenada, e por isto devem se comunicar através de seus métodos. Um objeto pode chamar a execução de um método de outro objeto. A chamada do método de outra mensagem é o que chamamos de mensagem.
Quando desejamos definir como e quais mensagens são transmitidas, podemos fazer um diagrama de seqüência ou um diagrama de colaboração são chamados de diagramas interativos.
Mostra a sequência de chamada de métodos (MENSAGENS) ao longo do tempo.
Para isto devemos estanciar os objetos que irão ser utilizados.
Para se representar um objeto instanciado, por exemplo, para a classe aluno, temos:
: aluno representa que um objeto qualquer da classe aluno foi instanciado- João 
: aluno representa que o objeto nomeado como João, da classe aluno, foi instanciado.
Um objeto instanciado tem um tempo de existência.  A existência do objeto é representado por um retângulo, desenhado em  um traço na horizontal, chamado linha da vida (representação no tempo) .
Na figura, o início do retângulo indica o momento que o objeto é criado.  Uma classe tem, no mínimo, dois métodos obrigatórios. O método construtor() e o método destrutor().  O método construtor é disponibilizado automaticamente e tem, como objetivo, criar todas as estruturas de dados, mecanismos de software e controles necessários a existência do objeto.  Assim, o início do retângulo indica que foi executada o método construtor da classe.  O método destrutor  é responsável por liberar aéreas de trabalho e estruturas que foram estabelecidas pelo construtor  Assim, o destrutor libera espaço na memória e dispensa a CPU de executar atividades desnecessárias.  Quando não se deseja mais o objeto instanciado deve-se passar a função destrutora, normalmente indica-se isto pela palavra DESTROY, ou KILL, ou FREE.  Quando não se indica a chamada da função destrutora, assume-se que ela ocorre no final da execução do caso e uso.
Um método (ou função encapsulada) é da forma:
   <tipo:retorno> nome (<parâmetros tipo:nome>);
exemplo:      int:matrícula ID_ALUNO (string:CPF);
Indica uma função chamada ID_ALUNO que retorna um número inteiro chamado matrícula e que ao ser chamada para executar recebe uma string chamada CPF.
Uma boa prática de desenvolvimento é se numerar a sequência das chamadas de métodos.  Embora o UML especifique como se deve representar um método, algumas pessoas não representam os tipos junto ao retorno e aos parâmetros.  Alguns métodos não precisam de parâmetros  Os retornos das funções pode ser representados por linhas pontilhadas.  Só tem sentido se colocar retornos quando a informação voltada será usada no processamento de um método.
	
Para se representar um objeto instanciado: : aluno representa que o objeto nomeado como João, da classe aluno, foi instanciado.
Um objeto instanciado tem um tempo de existência.  A existência do objeto é representado por um retângulo, desenhado em  um traço na horizontal, chamado linha da vida (representação no tempo). Uma classe tem, no mínimo, dois métodos obrigatórios. O método construtor() e o método destrutor()
Autodelegação: Um método pode ser chamado por outro método dentro de uma classe. Nesse caso, o objeto está enviando uma mensagem para ele mesmo. 
Na prática, as linguagens de programação, ao executarem um método, guardam o endereço desta execução em uma variável especial chamada THIS. Quando se faz a auto delegação, busca-se, para execução do método, o endereço armazenado nessa variável.
Podemos indicar a execução da forma:
 THIS.mesagem()
Uma mensagem é uma chamada a esse método. Pode-se indicar o acesso a um atribulo, ou método de um objeto, indicando o nome do objeto. 
Funções
Encapsuladas na classe.
Também se diz que são os serviços que a classe oferece.
Podemos chamar a função construtora, que vai criar o objeto.  Suponha que desejamos o objeto  João.
As linguagens, geralmente, fazem isso por um método com o mesmo nome da função ou pelo operador new.
 Aluno João:  /aluno é um novo tipo e foi criado o objeto João.
João = new aluno; / João é um objeto que foi criado da classe aluno.
Podem-se acessar os atributos da classe, indicando o objeto e a estrutura que desejamos de dentro da classe.
     Nome   --> indica que estamos acessando a variável nome do objeto João
     João.Telefone = “23657854”.  --> indica que o telefone 23657854 foi atribuído a variável telefone no objeto João.
     João.transferir(); --> indica que foi ativada (executar) a função transferir, a partir do objeto João e com as características existentes no objeto, na hora da chamada.
Mensagens Etiquetadas
Já vimos nos itens anteriores  o que UML classifica como uma mensagem etiquetada.   Uma mensagem etiqueta é quando se estabelece uma série de condições que devem ser cumpridas para se enviar a mensagem
De acordo com a UML a sintaxe da etiqueta é:
<Predecessor><condição><expressão><retorno> := <mensagem> (<parâmetros>);
 
<predecessor> é uma lista de números separada por virgulas terminando por uma “/”
          Exemplo:  1.1, 1.2, 1.2.1, 1.2.2, 1.2.2.3/
Casos especiais de representação
Tempo Real: Um sistema em tempo real, em principio, tem o tempo como o principal fator para sua execução.  O sistema precisa responder conforme projetado, permitindo a execução simultânea  de processos em paralelo.  Precisa-se definir tempo de resposta, comportamento, comunicação entre processos.  
Embedded System : Um sistema de tempo real, normalmente, tem os processos muito integrados a dispositivos de hardware.  Este tipo de sistema é chamado de Embedded System.
Classe ativa: Normalmente os objetos (de uma classe passiva) só são instanciandos quando recebem mensagens – as classes que vimos nos exemplos anteriores-.  Uma objeto de uma classe ativa pode tomar iniciativa para executar ações sem enviar mensagens.  Para isto deve-se representar os métodos com a preocupação de definir a forma de comunicação entre os objetos ativos e sua sincronização.  Na UML uma classe ativa é representado com a indicação do estereótipos <<classe ativa>>.
Sincronismo de mensagens: 
Ponta de flecha sólida: indica que a chamada do procedimento é síncrono. Indica que a sequência aninhada (níveis) é toda completada antes da sequência acionadora.  Isto indica que métodos no mesmo nível devem esperar.  O remetente da mensagem esperará pelo destinatário esperará a conclusão do método antes de continuar o seu processamento.
Ponta de flecha fina: Fluxo de  controle assíncrono. Mostra que o controle é passado sem haver preocupação com a comunicação., também se indica o retorno com a flecha do voltando do objeto solicitado para o solicitante.
Meia ponta: Indica que o remetente envia a mensagem e continua imediatamente o seu processamento sem esperar pelo destinatário.
Mensagem de Intervalo: Indica que o remetente esperará pelo destinatário por um período fixo de tempo antes de interromper o processo de transmissão da mensagem e continuar o seu processamento.
Metodo criar: Pode-se indicar a criação de um objeto na forma.
Um diagrama de sequência, usando todas asrepresentações da UML, dá para o implementador uma série de informações importantes.
Quando o diagrama de sequência envolve vários objetos, pode-se ter dificuldadade de visualizar o método que se está desenhando.  Para resolver isto temos um outro tipo de diagrama chamado diagrama de colaboração.  O diagrama de colaboração tem o mesmo objetivo do diagrama de sequência, mas permite uma melhor visualização, pois só se representa as classes envolvidas no método.
Seja simples:
 1 - Não queira iniciar usando todas as representações apresentadas nesta aula. Use as básicas e a medida que for ganhando experiência vá introduzindo novas representações 
2 – O diagrama de seqüência é para ser simples.  Por isto desenhe apenas o desenvolvimento de um método ou caso e uso completo por diagrama.  Não resolva vários caso-uso ou método no mesmo diagrama
3 – pratique, este é o segredo.  Lembre-se que ao desenhar um diagrama de seqüência você esta definindo código.
Aula 6
Diagrama de Colaboração
Mostra como as classes se colaboram, expressa de forma diferente as mesmas informações do diagrama de seqüência. Mostra uma interação organizada em torno de um conjunto limitado de objetos, por isso é preferido pelos programadores. Para se escolher qual dos diagramas utilizar, uma regra é escolher o diagrama de colaboração quando o objeto e seus vínculos facilitam a compreensão da iteração e escolher o diagrama de seqüência apenas se a seqüência precisa ser evidenciada.
A diferença básica é que no Diagrama de Seqüência conseguimos visualizar claramente a seqüência da troca de mensagens entre os objetos, sendo válido para avaliação da consistência das operações e, no Diagrama de Colaboração esta seqüência não fica totalmente clara, mas é possível interpretar todas as mensagens recebidas pelos objetos, sendo muito válido para definição de parâmetros, planejamento de desenvolvimento e outros aspectos para o projeto em si. 
Arquitetura de camadas
No projeto é necessário se preocupar com a organização para facilitar a manuntenção futura. Então aparece uma nova preocupação de organizar o código. Assim surge outro nível de abstração, que é a de camada. 
Neste estudo, vamos desenvolver o nosso projeto considerando uma camada de software cuja preocupação é a apresentação (telas, relatórios) outra é a camada onde se encontra o código que faz controle do aplicativo e o código que trata as regras de negócio e uma camada onde se encontra o código relativo ao acesso e armazenamento de objetos. Assim aparecerá um conjunto de novas classes que irão conter métodos com objetivos, segundo a camada que se encontra.
Essa proposta cria três níveis de abstração para se organizar o código que irá ser desenhado
As classes, poderão ser marcadas com o estereotipos de apresentação ou “view” é comum representar essas classes na forma: 
Ex: Tela_aluno indica que foi instanciado um objeto que contém métodos de apresentação (métodos como ativar(); apresentar ();...) e que estão definidos na classe tela_aluno.
As classes definidas como “controles” contém o código que permite controlar a instanciação de novas classes ou mesmo ordenar como será executado um método. Entre um objeto de apresentação e um objeto de negócios sempre deverá exisitr um objeto de controle, isso dará mais reutilização ao código.
As classes de negocio, que são originarias da analise e onde se tem as regras de negócio:
Padrões de Projeto: O diagrama de colaboração serve para desenhar alguns padrões de projeto. Um padrão de projeto é uma solução já estabelecida para um determinado problema. Existe uma categoria de problema para a qual já foi dada uma solução, por desenvolvedores experientes e esta deve ser adaptada para uma situação semelhante. Isso é que chamamos de padrão.
Normalmente, o padrão tem uma sintaxe da forma:
Nome do padrão:
Problema que resolve:
Solução:
Vamos aprender de forma resumida sobre os padrões GRASP. Padrões GRASP: definem princípios gerais para atribuição de responsabilidades as classes.Existem 5 padrões GRASP: Especialista na Informação, Creator, Coesão Alta, Acoplamento Fraco, Controlador
Os padrões GRASP definem princípios gerais para atribuição de responsabilidades das classes (usa-se também nos diagramas de sequencia).
Existem cinco padrões GRASP:
Especialista na informação (information expert)
Problema que resolve:
Durante o projeto orientado a objetos, ao se definirem as interações entre objetos, precisamos definir onde os métodos serão colocados. Uma boa escolha torna os sistemas mais fáceis de entender e manter, além de favorecerem a reutilização.
Solução:
Atribuir a responsabilidade do método à classe que tem a informação, isto é, onde existe o atributo.
Creator
Quem deve ser responsável pela criação de uma nova instância de um objeto?
Atribuir a uma classe B a responsabilidade de criar uma instância de A em uma das condições:
B agrega objetos de A.
B contém objetos de A
B contém dados para inicialização na criação do objeto A
B registra instâncias de objetos de A.
Coesão Alta
Como manter a complexidade de um projeto sob controle?
A coesão é um conceito que define o quanto elementos devem permanecer juntos. Uma classe de coesão baixa normalmente são difíceis de compreender, difíceis de manter e de se reutilizarem.
Solução:
Solução:
Manter o acoplamento fraco entre classes e manter uma alta coesão nas classes deve ser o objetivo de um projeto
A coesão e o acoplamento devem ser avaliados de forma conjunta. O ideal é termos altas coesões com baixos acoplamentos.
Acoplamento Fraco
Como se ter pequenos impactos na manutenção do código e favorecer a reutilização?
O acoplamento mede o quanto um elemento(código) está conectado ao outro, ou precisa dos outros para funcionar. Um acoplamento forte exige que se tenha outros elementos para o funcionamento correto. Tal situação, normalmente, é indesejável, pois, não favorece a reutilização, além de provocar um volume alto de manutenção em casos de modificação no código. 
Uma classe que tem acoplamentos fortes é difícel de ser compreendida isoladamente. São difíceis de serem reutilizadas pois exigem a presença de outras classes.
Solução:
Atribuir responsabilidades de modo que a dependência entre elementos fique o mais baixa possível.
Controlador
Quem deve ser responsável por tratar um evento de um sistema? Que operações e métodos devem ser executados? Em que sequência?
Solução:
Criar uma classe responsável por tratar o evento.
Aula 7
Diagrama de Componente
Um componente pode ser tanto um código em linguagem de programação como um código executável já compilado.
Por exemplo, em um sistema desenvolvido em Java, cada arquivo .java ou .class é um componente do sistema, e será mostrado no diagrama de componentes que os utiliza.
Um componente se representa graficamente na forma:
 
O diagrama de componentes: mostra as dependências entre os elementos de um software.
A dependência é mostrada como uma linha tracejada com uma seta, simbolizando que um componente precisa do outro para o seu funcionamento; visualiza que módulos de software (arquivos.dll, .exe, .com, .bat, .htm e outros executáveis) são necessários para executar a aplicação; mostra o sistema pelo seu lado funcional, mostrando a organização de seus módulos e como se dará a sua execução; representa a estrutura do código gerado. Um componente é definido a partir de condições físicas, definições de projeto nas implementações de classes e métodos definidos nos diagramas de sequência (ou colaboração). São tipicamente os arquivos implementados no ambiente de desenvolvimento.
Definição de um componente
Para se definir um componente, deve–se levar em consideração as condições físicas que o sistema irá executar, por exemplo, tamanho de memória, tempo de execução, módulos mais utilizados, tamanho dos módulos.  Além do critério do reaproveitamento do código.  O ideal é criar componentes que possam ser utilizados em vários softwares.
Suponha, por exemplo, o módulo de logon em um software.Suponha que o módulo para efetuar o login é de 5 Mbytes e que o software compilado tem 60 Mbytes.
O módulo de login deve ser compilado juntamente com o restante do software gerando um único componente executável?
Não, pois o módulo de login irá executar uma única vez, e irá ocupar a memória com 5 Mbytes de código que não será mais executado.  Além disto, se este módulo for projetado devidamente, poderá ser reutilizado em outros produtos, de forma que o ideal é termos um único componente de software para tratar o login e outro componente que chamaremos de principal, que chamarão componente login, que, após executado, não mais será chamado. 
Quando definimos componentes a partir dos diagramas de colaboração, pode-se ter situações em que um componente tenha parte da execução de um método ou contenha mais de um método.  Assim, ao ser chamado, precisa que se indique que método será executado ao entrar o componente, e as características necessárias ao método (assinatura da função).  Neste caso, o componente terá várias formas de entrada e deve-se indicar a forma de chamada do componente.  Cada forma de entrada é chamada de interface do componente.  No diagrama de componentes, deve-se indicar que interface está sendo chamada. 
Um componente poderá ter várias interfaces.
Na definição de um componente, para garantir o seu funcionamento correto, podemos escrever um módulo, a ser compilado dentro do componente, que verifique as suas condições de execução.  Ou seja, verifica se existem os outros componentes necessários para o seu trabalho, ou faz o controle dos métodos ou interfaces que estão sendo usados.  Este módulo é um controle e é chamado de controle do componente.
Diagrama de implantação
também chamado por alguns autores de diagrama de execução, mostra a organização do hardware e a ligação do software aos dispositivos físicos. O diagrama é constituídos de nós conectados. 
Nó 1: Na uml um nó representa um dispositivo físico com memória ou capacidade de processamento. Podemos ser contidas intancias de componentes indicando que os itens residem nas instancias d do tipo de nó. 
Sintaxe:
Um tipo de nó: <tipo do nó>
Para uma instância: <nome do nó> “: “ <tipo do nó>
Ex: Pentium 300 mhz é um tipo de nó. 
Computador do Pedro, Pentium 300mz é uma instancia do tipo de nó Pentium 300 mhz.
Aspectos para se alocar componentes em um nó: 
Segurança: estabelecer direitos de acesso e proteção de dados; 
Acesso a dispositivos: avaliar as necessidades individuais de dispositivos em um nó; 
Localização geográfica: determinar que funcionalidades necessitem estar disponibilizadas localmente para o melhor desempenho;
Utilização de recursos: distribuir de forma a obter desempenho máximo do hardware utilizado.
Aulo 8
Diagrama de estado: 
O diagrama de estados é uma ferramenta desenvolvida em estudos de máquinas finitas, na matemática, e tem sido adaptado a várias aplicações na informática.  Na análise essencial existe uma variação destes diagramas que são chamados de diagramas de transição de estados (DTE).  Em todas essas variações, usam-se os mesmos conceitos com representações diferentes.
Representamos os eventos, que podem ser para um caso e uso ou para tratamento de uma classe e também se modelam processos, por isto, é comum alguns “processos” serem analisados e documentados com diagramas de estado. Ilustram-se os estados, eventos e as mudanças provocadas por estes eventos
ESTADO - Um estado é um conjunto de condições que estão ocorrendo em um momento no tempo, por isto, obrigatoriamente, um estado é indicado pelo verbo no gerúndio, exceto o estado inicial (inicio) e o final (fim). Inicio representado por um bola cheia, e o fim uma bola cheia e uma bola vazia em volta.
EVENTO – É uma ocorrência significativa que pode alterar um estado, provocando uma mudança; pode ser uma entrada de dados, um acionamento de um comando, ou mesmo um elemento temporal (exemplo: são seis horas).
Transposição ou mudança de estado
Os eventos devem ser registrados junto ao estado onde provocam a mudança. A transposição de um estado para outro é indicado por um arco entre o antigo e o novo estado.
O evento que provou a mudança deve ser indicado no arco junto ao estado que provocou a mudança.
Ilustram-se os estados, eventos e as mudanças provocadas por estes eventos.  Exemplo:
Um diagrama de estados pode, por exemplo, mostrar o ciclo de vida de um objeto. Mostrando detalhes simples ou complexos de acordo com o que estamos analisando.
Podem-se estudar os eventos externos do sistema para tratar um caso e uso
Vamos, por exemplo, modelar o Caso e Uso Processar venda.  Nesse caso, devemos conhecer a descrição do caso e uso. Suponha que ao processarmos vendas não se pode fazer pagamento com cartão de crédito até o evento terminar venda ocorra.
Notação para estado segundo o UML
O UML padroniza que um estado seja indicado em um retângulo com cantos arredondados com três compartimentos: compartimento do nome do estado, das variáveis do estado e da atividade interna.
Os atributos sublinhados indicam a chave primária de cada relação, enquanto que os assinalados em vermelho constituem chaves estrangeiras.
Observe que o diagrama de estados pode ter mais de um início e mais de um fim.
Subestado e superestado
Subestados: um estado em um diagrama de estado pode ser decomposto em outro diagrama de estado.
Subestados simultâneo: quando um estado pode acontecer ao mesmo tempo com outro estado.
Subestados seqüencial: quando um estado ocorre após o outro.
O diagrama de estados é uma ferramenta que deve ser usada na análise, devido a sua simplicidade  e clareza.  A sua utilização facilita a modelagem de processos em tempo real.  Na prática, muitos desenvolvedores colocam informações de código, como comentários, informações condicionais.
Aula 9
Diagrama de atividades
O diagrama de atividades, para alguns autores, é um caso especial do diagrama de transição de estados, quando a maioria das transições é comandada por termino de ações nos seus estados precedentes.
Capturam ações e seus resultados de casos e usos. O seu objetivo é o de capturar ações e seus resultados em termos das mudanças de estados dos objetos. 
Um diagrama de atividade é uma maneira alternativa de se mostrar interações, que ocorrem em um caso e uso com a possibilidade de expressar que ações são executadas.
Pode ser usado pelos seguintes propósitos: 
Para capturar os trabalhos que serão executados quando uma operação é disparada (ações). Este é o uso mais comum para o diagrama de atividade; 
Para capturar o trabalho interno em um objeto; 
Para mostrar como um grupo de ações relacionadas pode ser executado, e como elas vão afetar os objetos em torno delas; 
Para mostrar como uma instância pode ser executada em termos de ações e objetos; 
Para mostrar como um negócio funciona em termos de trabalhadores (atores), fluxos de trabalho, organização, e objetos (fatores físicos e intelectuais usados no negócio).
Elementos utilizados para representar diagrama de estados: 
ATIVIDADE - <verbo-complemento>: Representa o desempenho de alguns componentes no fluxo de atividades. Pode ser ou não atômica. Normalmente o nome da atividade é constituído de um verbo no infinitivo e um complemento.
TRANSIÇÃO --: São usadas para mostrar a passagem do controle do fluxo de execução entre as atividades. Normalmente são disparadas pela complementação das atividades.
DECISÃO: Ao se estabelecer o fluxo de trabalho entre as atividades, existem pontos onde se deve decidir que fluxo se deve seguir. São os pontos de decisão. Neles encontram-se as condições de guarda que permitem que se estabeleça o fluxo de acordo com a condição encontrada. Também pode ser representado também na forma:
BARRA DE SINCORNIZAÇÃO: Em um fluxo de trabalho existem atividades que podem ser desenvolvidas em paralelo.  a barra de sincronização permite especificar fluxos de trabalho que podem ser feitos ao mesmo tempo (em paralelo).  Também mostram quando o conjuntode fluxos de trabalho (atividades) deve ser completado para iniciar outro fluxo (ou atividade).
INICIO: O Inicio indica o inicio do fluxo de trabalho. Pode-se ter mais de um inicio (pouco comum) em um diagrama de atividades.
FIM: Determinar o fim do fluxo de trabalho.  Pode-se ter mais de um fim (comum) em um diagrama de atividades
Construção de um diagrama de atividades para um caso e uso
Um diagrama de atividade é uma maneira alternativa de se mostrar interações, que ocorrem em um caso e uso com a possibilidade de expressar que ações são executadas.
Construção de um diagrama de atividades para um processo
O diagrama de atividades também é útil para o desenvolvimento de um processo.  Vamos supor que desejamos estabelecer uma série de procedimentos para criar um curso e abrir matriculas para um conjunto de cursos catalogados.
Swinlanes: No diagrama de atividades podemos informar quem ou onde as atividades são feitas, para isto, usamos “raias” (faixas), como em uma piscina, para indicar onde (ou quem) as atividades são feitas.
O diagrama de atividades também pode ser usado para definição de métodos como mostrado no exemplo abaixo e também pode conter especificações de mensagens enviadas e recebidas como partes de ações executadas.
O diagrama de atividades é um diagrama que deve ser usado na especificação de projetos administrativos do sistema, ou na complementação, do estudo das interações com o sistema.  Como mostrado também serve para definir métodos.
Aula 10
Agora que aprendemos na aula anterior - diagrama de sequência – o que um método, o que uma mensagem podemos falar sobre uma característica importante em orientação a objetos que é a visibilidade das classes.
Visibilidade de Atributos
Uma classe é encapsulada para proteger seus dados e métodos. Assim quando se especifica um método ou uma classe eles devem ser protegidos quanto ao acesso, mas muitas vezes precisamos acessar estes dados ou métodos de fora da classe. Assim neste tópico vamos analisar como isto é tratado.
Visibilidade das classes: Privado, Publico, Protegido, 
Privado
É a condição de criação de um método ou atributo significa que só podem ser usados dentro da classe onde estão especificados. Os métodos podem utilizar diretamente as variáveis ou outros métodos internos à classe, são considerados como globais no escopo da classe. Quando não se especifica o tipo de atributo assume-se como privado.
Publico (public)
Quando explicitamente se deseja liberar o acesso feito de forma externa a classe. Não é uma situação desejável, pois é contra o conceito de implementação de uma classe, que é de proteger de forma encapsulada seus métodos e atributos. Deve-se usado com muito cuidado, estes métodos, na prática, quando colocados nas classes não devem acessar diretamente os atributos da classe, isto deve ser feito com ajuda de métodos privados por uma questão de segurança.
Protegido (protected)
Só deve ser usado quando temos uma estrutura gen-esp. Quando um método ou atributo é especificado como protected ele é visível por todas as classes que estão na estrutura GEN-ESP.
Podem-se abrir os métodos de uma classe A para uma classe B declarando que a Classe B é amiga de A. Neste caso você pode considerar que os métodos e atributos privados A são totalmente visíveis para B. Isto é implementado em algumas linguagens de programação da seguinte forma:
Classe A friend classe B; Dá-se acesso a métodos e atributos da classe A para os métodos da classe B.
Algumas linguagens limitam este recurso e não permite o acesso a toda a classe, permitindo acesso apenas para algumas funções da classe. Neste caso se desejamos que a classe B tenha acesso a alguns métodos da classe B isto deve ser especificado junto aos métodos atributos na classe A. Usa-se a cláusula Friend classe B;
A representação de classe no UML já considera que estamos definindo a visibilidade de atributos e funções e usa a seguinte notação na frente do atributo ou método:
+ significa que o método ou atributo é público (public)
- significa que o método ou atributo é privado (private)
# significa que o método ou atributo é protegido (protected)
Visibilidade de objetos: é a capacidade de um objeto fazer referencia e utilizar métodos e valores de outro objeto.
Visibilidade por atributo – B é um atributo de A. / Visibilidade por parâmetro – B é um parâmetro de um método de A. / Visibilidade local - B é um objeto definido em um método de A. / Visibilidade global – B é definido como global, portanto, visível a A.
Diagrama de pacotes: Um pacote é um recurso para definição de grupamentos. Seu uso mais comum é o grupamento de classes, embora possa se fazer grupamentos para tipos de elementos no UML. É um recurso que pode ser usado para organizar o sistema seja pelo aspecto tecnológico ou administrativo. 
Um pacote é representado na forma:
<nome do pacote> ou <conteúdo do pacote>
Os pacotes podem ser membros de outros pacotes. Pode-se definir uma hierarquia de pacotes. Um pacote pode conter um ou mais pacotes e assim sucessivamente.
Observe na representação que se o conteúdo do pacote é exibido deve-se colocar o nome na aba, senão for pode-se colocar o nome no meio do meio do retângulo. Se for necessário, ainda, pode-se usar o recurso de estereótipo usando a indicação “<<” e “>>” com o nome dado.
As classes têm escopo dentro de pacotes onde são definidas. Uma classe X definida dentro de um pacote em a seguinte sintaxe:
 
 NomeDoPacote :: NomeDaClassse
 
Se for necessário uma classe pode incluir um caminho completo de pacote no qual está presente. Se forem pacotes encadeados deve-se grupar os nomes dos pacotes separados por:
Nomedopaacote1::NomeDo Pacote2::NomeDoPacote3::NomeDaClasse
 
Um pacote não pode modificar atributos ou métodos de uma classe. E deve manter a navegabilidade de associações dentro do pacote. Um pacote deve ter sua visibilidade indicada para os outros pacotes (como podem acessá-lo).
Visibilidade de pacotes:
Privada: Somente o pacote que possui o elemento pode usá-lo.
Protegido: Além dos elementos do pacote é possível que pacotes que participem de generalização acessem.
Publica: Todos os elementos podem acessar o conteúdo do pacote. É o default quando nada é indicado.
Implementação: Similar a visibilidade privada, mas os elementos de modelos que têm uma dependência com um pacote não podem usar os elementos dentro daquele pacote.
Dentro e um pacote s classes são públicas ou privadas. Se uma classe de um pacote precisa ser usada por outra classe de um outro pacote estabelece-se uma dependência entre os pacotes.
Os pacotes também podem ser definidos contendo casos e usos. Aplica-se as mesmas regras
Um pacote possui vários modelos de elementos, e isto significa que estes não podem ser incluídos em outros pacotes.
Na grande maioria dos casos, os pacotes possuem relacionamentos com outros pacotes. Embora estes não possuam semânticas definidas para suas instâncias. Os relacionamentos permitidos entre pacotes são de dependência, refinamento e generalização (herança).
Se um pacote for destruído, todo o seu conteúdo também será.