MODELAGEM DE SISTEMAS - RESUMO AULA 1 A 10

Prévia do material em texto

� PAGE \* MERGEFORMAT �21�
MODELAGEM DE SISTEMAS
Aula 01
EVOLUÇÃO DA ENGENHARIA DE SOFTWARE
Como tudo começou...
Criação do Hardware 
Desenvolvimento imediatista 
Procura maior do que a oferta 
Insatisfação dos usuários 
Engenharia de Software
Por que surgiu?
Para instituir padronização na forma de desenvolvimento de softwares, pois era desenvolvido de forma imediatista, baseado no conhecimento dos técnicos, sem garantia de continuidade.
O que é?
É a definição de métodos, técnicas e ferramentas que devem ser aplicados para ordenar o desenvolvimento e se obter maior qualidade.
DISCIPLINAS são as atividades necessárias para realizar o desenvolvimento.
Gerência de Projeto, Levantamento de Requisitos, Análise, Projeto, Implementação, Teste, Implantação, Manutenção e Qualidade.
CICLO DE VIDA define o faseamento necessário para realizar o desenvolvimento.
Cascata, Prototipagem, Espiral, Iterativo e Incremental.	
PROCESSO UNIFICADO
O Processo Unificado é iterativo e consiste em subdividir o projeto para sua implementação por partes.  O PU é constituído de atividades divididas em quatro fases:
Fase da Concepção - Nesta fase se “imagina” o produto, o que fará.  Seu objetivo e suas principais funções.  Pode-se fazer uma estimativa, ainda que “grosseira” de prazos e custo.
Fase da Elaboração - Nesta fase pegamos cada função, segundo o escopo do produto, e lhe damos um tratamento técnico, definindo como será feito.  Nessa fase, o que se “imaginou” na fase anterior deve ganhar forma, isto é, deve ser viabilizado. Nessa fase surge o projeto.
Fase da Construção - As definições feitas na fase de elaboração são construídas.  No caso de software, nesta fase fazemos a programação, definimos arquivos, testamos o que se “imaginou” virar realidade.
Fase da Transição - Após o produto pronto, ele precisa ser disponibilizado.  Nessa fase, fazem-se os ajustes necessários para viabilizar o uso do produto.  No caso de software, fazem-se as implantações. Ajustes em programas e arquivos já existentes.  Testes de integração e aceitação.  Essa fase é responsável por disponibilizar o produto para uso.
RUP OU IBM RATIONAL UNIFIED PROCESS®
É uma plataforma de desenvolvimento de software. Configurável. Esse produto é constituído de um conjunto de templates que devem ser gerados durante o desenvolvimento do software.
Aula 02
SURGIMENTO DO UML (UNIFIED MODELLING LANGUAGE)
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.
APLICAÇÃO DA UML
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 DA UML - 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:
DIAGRAMA DE CASO DE USO - 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).
CASO DE USO é a representação dos requisitos de sistema.
Simbologia
Deve:
ser identificado por verbo, pois tem a conotação de ação;
ter o significado claro traduzindo facilmente a necessidade;
ATOR é a representação do responsável por realizar o caso de uso.
Podem ser: 
Pessoas, Setores, órgãos governamentais, e etc.
Outros Sistemas.
INTERAÇÃO CASO DE USO-ATOR representa a realização do caso de uso.
SIMBOLOGIA
INTERAÇÃO Caso de Uso – Caso de Uso
<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: Temos mais de um ator realizando a mesma tarefa e, algumas tarefas diferenciadas.
GENERALIZAÇÃO DE CASO 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.
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 << 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.
Aula 03
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.
Conceitos Iniciais:
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 do cliente, cpf, email, ...
MÉTODOS: operações realizadas para um objeto. Ex.: lerNome()
IDENTIFICANDO CLASSES
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.
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.
UM RELACIONAMENTO é um estabelecimento conceitual entre elementos de um conjunto com outro que depende de que aspecto do mundo real estamos analisando.
ASSOCIAÇÕES
Ligação estabelecida entre as classes, por necessidade de comportamentos do negócio analisado. 
PAPEL nome da associação, tornando claro no diagrama o ligação estabelecida.
CLASSES DEPENDENTES
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.
Aula 04
DIAGRAMA DE CLASSE
Modelo aplicado para representar as informações necessárias para realização das funcionalidades do sistema em estudo a partir do conceito de CLASSE. 
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, ...
MULTIPLICIDADE define o número de vezes em que o objeto participa da associação. Deve ser representada utilizando os dois sentidos de leitura, sempre associado a um objeto com o resultado na outra classe e levando em consideração os comportamentos desejados do negócio que está sendo analisado.
A representação de multiplicidade possui o seguinte esquema: 
Li ... Ls, onde:
Li define o Limite inferior 
Ls define o Limite superior
Li e Ls poderão ter valores numéricos de 0 a n e 
Ls poderá também ter a representação * que tem como significado infinito/muitos.
CLASSE ASSOCIATIVA Classe que representa os objetos resultados de uma associação, com atributos, características e operações próprias.
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.
ASSOCIAÇÃO ORDENADA as associações entre objetos podem ter uma ordem implícita. O padrão para uma associação é desordenado (ou sem nenhuma ordem especifica). Mas uma ordem pode ser especificada através da associação ordenada. 
QUALIFICADOR (ASSOCIAÇÃO) 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.  O Retângulo do qualificador é parte do cominho e não faz parte da classe. 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 Quando for implementado (código de programação) um objeto, podem-se chamar operações de outros objetos.  Diz-se que de uma classe instanciada podem-se acessar instâncias de outras classes que tem relacionamentos com a primeira classe. Para indicar o sentido da NAVEGAÇÂO, ou seja, como podemos percorrer (chamando funções – veremos na próxima aula), usamos uma flecha no final do relacionamento.
Agregação de Composição: É uma agregação onde uma classe que está contida na outra, “vive” e constitui a outra. Se o objeto da classe que contém for destruído, as classes da agregação de composição serão destruídas juntamente, já que as mesmas fazem parte da outra. 
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.
  Tem a seguinte sintaxe: Nome-do-classificador
Quando o especificador é omitido, é por que se tem acesso a todos os elementos da classe.
Exemplo:
Indica que o relacionamento é feito, quando a média (um dos atributos de aluno aprovado) é maior que sete.
MULTABILIDADE 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:
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.
Aula 05
DIAGRAMA DE CLASSE
AUTO ASSOCIAÇÃO - Define quando um objeto de uma classe está relacionado com outro objeto da mesma classe para atender a algum comportamento. 
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. 
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. 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.
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.
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 á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.
MÉTODO - 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.
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.
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>);
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. Um 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>>.
MENSAGENS 
A UML indica a forma de sincronismo durante a transferência das mensagens, por variações na ponta da flecha:
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 flexa 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. m diagrama de sequência, usando todas as representaçõ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.
Aula 06
DIAGRAMA DE COLABORAÇÃO
O diagrama de colaboração mostra como as classes se colaboram. O diagrama de colaboração expressa, de forma diferente, as mesmas informações do diagrama de sequência. O diagrama de colaboração mostra uma interação organizada em torno de um conjunto limitado de objetos, por isto é, normalmente, preferido pelos programadores.
O diagrama de colaboração é constituído de dois elementos: 
a) Instâncias de classes de projeto;
b) Métodos trocados entre as instâncias desses objetos; 
ARQUITETURA DE CAMADAS
No projeto, o projetista precisa organizar o código, de modo a atender as classes de domínio. Além disso, deve ter outras preocupações de projeto, como facilitar a manutenção futura, garantir estabilidade do código, garantir reutilização e outras características. Assim, aparece uma nova preocupação que organizar o código para facilitar a sua existência física, de acordo com padrões de engenharia. 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:
Apresentação
Controle 
Negócio
Exemplo:Para se tratar um objeto de domínio como aluno temos:
PADRÕES DE PROJETOS
Um padrão de projeto é uma solução já estabelecida para um determinado problema.
Os padrões GRASP (General Responsibility Assignment Software Patterns) definem princípios gerais para atribuição de responsabilidades as classes( usa-se também no diagrama de sequência). Existem cinco padrões GRASP:
ESPECIALISTA DA INFORMAÇÃO: Atribuir a responsabilidade do método à classe que tem a informação, isto é, onde existe o atributo.
CREATOR: 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.
ACOPLAMENTO FRACO: 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ícil de ser compreendida isoladamente. São difíceis de serem reutilizadas pois exigem a presença de outras classes.
OU SEJA, Atribuir responsabilidades de modo que a dependência entre elementos fique o mais baixa possível.
ALTA COESÃO: 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:
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.
CONTROLADOR: Criar uma classe responsável por tratar o evento.
O controlador ou coordenador não executa nenhum trabalho, apenas delega para outros objetos. É um intermediário para a camada de domínio, a partir da camada de interface. O uso do controlador permite que outra interface chame o controlador e isto melhora a reutilização do código.
AULA 07
Diagramas de Componente e Implantação
	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:
A dependência entre componentes é mostrada como uma linha tracejada com uma seta, simbolizando que um componente precisa do outro para o seu funcionamento. O diagrama de componentes 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. 
Exemplo de diagrama:
O diagrama de componente mostra o sistema pelo seu lado funcional, mostrando a organização de seus módulos e como se dará a sua execução. 
Portanto, representa o desenho da estrutura do código gerado.
Definição de componentes: 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.
Diagrama de implantação
O 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ído 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 instâncias de componentes indicando que os itens residem nas instâncias d do tipo de nó (sublinhar o nome do nó).
Sintaxe:
Um tipo de nó: <tipo do nó>
Para uma instância: <nome do nó> “: “ <tipo do nó>
EX: Computador de Pedro: Pentium 300Mhz (É uma instância do tipo de nó Pentium 300Mhz)
Aspectos para se alocar componentes em um nó
O diagrama de implantação/execução mostra a arquitetura física do hardware e do software no sistema. Pode mostrar os atuais computadores e periféricos junto com as conexões que eles estabelecem entre si.  
O diagrama de execução demonstra a arquitetura rotim de processadores, componentes físicos (devices), e de software que rodam no ambiente onde o sistema será utilizado. É a última descrição física da topologia do sistema, descrevendo as estruturas de hardware e software que executam em cada unidade.
AULA 08
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 essencialexiste 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. Nesse diagrama, 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.
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. Normalmente, dois estados não são representados no gerúndio o estado inicial (inicio) e o estado final (fim), os demais, obrigatoriamente, estarão no gerúndio, como por exemplo, apresentando tela – indica que uma tela esta sendo apresentada em um determinado instante de tempo para determinadas condições-. Normalmente, representados dentro de uma elipse.
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).
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.
AULA 09
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.
Diagramas de atividade 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 pode ser usado com diferentes propósitos inclusive:
Elementos usados no UML para representar diagramas de atividades:
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.
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.
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. Exemplo de um diagrama de atividade:
Swinlines - 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.  Estas linhas são chamadas de “swinlanes”.
AULA 10
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.
PRIVADO (private) - É 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.
Exemplo:
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.
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 - Visibilidade é a capacidade de um objeto fazer referencia e utilizar métodos e valores de outro objeto.
Diagramas 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. 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.
Visibilidade de pacotes
PRIVADA - Somente o pacote que possui o elemento pode usá-lo.
PROTEGIDA - 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.
IMPLANTAÇÃ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.
�