# data[].attributes.body
Componentes de Diagrama:

Qual a sua finalidade? Consiste em um diagrama que tem o objetivo de mostrar como as mensagens entre os objetos colaboram em comportamentos ao longo do tempo para  a realização de uma operação.

Componentes:

Atores: São entidades externas que interagem com o sistema e que solicitam serviços. Normalmente, o ator primário é o responsável por enviar a mensagem inicial que inicia a interação entre os objetos.

Objetos: Representam as instâncias das classes representadas no processo.

Gate: Indica um ponto em que a mensagem pode ser transmitida para dentro ou para fora.

Fragmento: Fragmentos de interação como: Alt (Alternativa), Opt (Opcional), Break (Parar), Loop (Repetição) e outras.

Linha de vida: As linhas de vida compõem a dimensão vertical. Uma linha de vida é composta de duas partes, a cabeça e a cauda. A cabeça é representada por um retângulo com dois compartimentos, no compartimento superior a identificação do objeto é exibida e no compartimento inferior (cuja utilização é opcional), aparecem valores para os atributos definidos na classe do objeto. A cauda corresponde a uma linha vertical tracejada.

# data[].attributes.body
Grupo:
Gabriel Da Silva Simões
Bruno Ajala Fernandes
Renan Luiz Thiel

O que é?

Diagrama criado para modelagem da interação entre objetos

Detalha como objetos colaboram para implementar um cenário de caso de uso.

Útil para ajudar na identificação dos métodos das classes .

Caixas representando objetos.

Linhas verticais representando a vida do objeto.

Linhas horizontais representando troca de mensagens.

Decisões

O diagrama de seqüência permite que decisões sejam tomadas durante o fluxo.

Para isso são utilizados quadros (frames) do tipo alt. ou opt. com condições de guarda.

Mensagens

A interação entre objetos é representada por mensagens

Para outros objetos.

Para o mesmo objeto (auto mensagem).

Uma mensagem contém a assinatura do método que está sendo chamado.

Uma barra de ativação indica o escopo de execução do método.

Mensagem de criação – Aponta diretamente para o objeto e é marcada com <>

Mensagem de retorno – Opcional, e normalmente é omitida – Usa seta tracejada.

Marca de destruição – Indica o término da vida de um objeto com um “X”

Repetições

O diagrama de seqüência permite que repetições sejam feitas durante o fluxo.

Para isso são utilizados quadros (frames) do tipo loop.

Relacionamentos

Classes possuem relacionamentos entre elas (para comunicação)  Compartilham informações  Colaboram umas com as outras

Principais tipos de relacionamentos  Associação  Agregação / Composição  Herança  Dependência

Chamada síncrona x assíncrona

É possível utilizar dois tipos de chamada de métodos no diagrama de seqüência:

Chamada síncrona (seta cheia): a execução fica bloqueada até o retorno do método.

Chamada assíncrona (seta vazia): a execução continua em paralelo ao método que foi chamado (fork implícito).

Quando utilizar diagrama de seqüência?

Para representar em alto nível a interação entre diferentes objetos visando atender a um caso de uso

Para ajudar a encontrar os métodos do diagrama de classes

Cuidado: não use diagrama de seqüência...

Para métodos muito simples (ex.: get e set)

Para definição precisa de como será o código

EXEMPLO: Diagrama de Seqüência / JOGO

Para que serve:

Um diagrama de sequência mostra uma interação, que representa a sequência de mensagens entre instâncias de classes, componentes, subsistemas ou atores. O tempo flui para baixo no diagrama e mostra o fluxo de controle de um participante para outro.
É usado os diagramas de sequência para visualizar eventos, em vez de métodos e classes e instâncias. Mais de uma instância do mesmo tipo pode aparecer no diagrama.Também pode aparecer mais de uma ocorrência da mesma mensagem.
Diagramas de sequência UML fazem parte de um modelo UML e existem somente em projetos de modelagem UML.

# data[].attributes.body
-> Descrever os componentes de cada Diagrama
->  Tipos de Relação
-> Pra que serve o diagrama

Podem usar imagens, vídeos, exemplos e textos

Data de entrega: 05/07

# data[].attributes.body
Guilherme e Tamiris

O que é um Diagrama de Componentes?

O diagrama de componentes é um dos diagramas descritos no padrão UML (Unified Modeling Language) que possui ferramentas para ajudar a organizar o projeto de software de forma que fique melhor para visualizar os módulos e suas integrações ao longo do andamento e do seu desenvolvimento.

O diagrama de componentes é um gráfico (desenho) que modela os componentes do projeto, conectando-os por relacionamentos de dependência, ou seja, se um componente depender do outro, serão ligados por uma seta apontada para o que é dependente.

Pra que serve um diagrama de componentes:

A finalidade do diagrama de componentes é definir os módulos físicos do software e seus relacionamentos uns com os outros. Isso oferece um meio de definir o software como um conjunto de unidades modulares e intercambiáveis, que podem ser montadas para criar unidades sucessivamente maiores, modulares e intercambiáveis.

Modelos de Ícone de Componentes Versão UML 1.4 (esquerda) e versão UML 2.0  (direita  Estereótipo é uma maneira de destacar determinados componentes do diagrama, tornando explícito que tais componentes executam alguma função um pouco diferente dos demais componentes apresentados no diagrama, ou seja, é o tipo do componente.  A UML prevê diversos estereótipos prontos para o Diagrama de Componentes, tais como:

Executável (executable)– Este estereótipo determina que o componente em questão é um arquivo executável, ou seja, um arquivo já compilado e link-editado em linguagem de máquina que pode executar uma série de instruções

Biblioteca (library)-Este estereótipo refere-se a bibliotecas contendo funções e sub-rotina que podem ser compartilhadas por diversos componentes executáveis, podendo  esta ser fornecidas pela própria linguagem em que o sistema será desenvolvido ou ser criadas pelos próprios desenvolvedores do sistema.

Tabela (table) –Este estereótipo refere-se a repositórios físicos de dados onde os registros produzidos pelo sistema deverão ser armazenados.

Documento (document) –Este estereótipo faz referência a arquivo texto utilizado por outros componentes do sistema, como por exemplo, arquivo de ajuda (help).

Arquivo (file) –Este estereótipo pode ser referir a qualquer outro arquivo que componha o sistema, como arquivos de código-fonte dos módulos do sistema, por exemplo.

Tipos de Relações:

Relação de Dependência

Duas classes possuem um relacionamento de Dependência quando uma alteração em uma dessas classes pode afetar a outra classe. Representa-se uma relação de Dependência apontando de uma classe que possui um método ou operação para a classe que é utilizada como um parâmetro para essa operação.

Relação de generalização:

Duas classes possuem um relacionamento de Generalização quando uma das classes especializa ou detalha a outra. A classe genérica é denominada de SuperClasse ou Classe Pai e a outra classe de SubClasse ou classe Filha. A relação de Generalização é identificada por meio do texto “é um“.

Relação de associação:

Informa que uma classe faz parte da estrutura de outra.

O Relacionamento de Associação pode ser subdivido em:

• Plana: representa uma relação estrutural onde as classes possuem a mesma importância. Uma linha ligando duas classes representa graficamente essa relação.

• Agregação: representa a estrutura todo-parte. Ela é representada por uma linha ligando as duas classes da relação e a presença de um símbolo diamante (losango).

Relação de composição:

Essa variação adiciona um grau de importância semântica à relação. Ela define a relação de posse ou possessão. Isso significa que um objeto da classe pertence apenas e exclusivamente ao objeto da outra classe.

Como a classe mais importante (ou todo) é responsável pela disposição das partes. Isso significa que ela precisa gerenciar a criação e destruição das partes que a compõe.

Relação de herança:

É uma hierarquia de abstrações na qual uma subclasse herda a estrutura e/ou comportamento de uma ou mais superclasses.

# data[].attributes.body
Marcelo, Gabriel, Barbara

# data[].attributes.body
Para que serve o diagrama de classes?

O diagrama de classes serve para demonstrar de uma forma visual as classes, seus objetos, métodos e seus relacionamentos. É uma modelagem muito útil para o desenvolvimento de sistemas pois defina todas as classes e os relacionamentos que o sistema deve possuir.

Componentes do diagrama de classes:

Classe: Elemento abstrato que representa um conjunto de objetos. A classe contém a especificação do objeto; suas características: atributos e métodos (ações / comportamentos).
Atributo: Define características da classe como:
Visibilidade: Pública onde outras classes podem ter acesso ao atributo. Privada o atributo somente é acessado diretamente pela própria classe e Protegida ou Pacote que é acessado pelo relacionamento da classe com a classe externa,.
Nome: Identificação do atributo.
Tipo de dados: Tipo de dado do atributo.
Multiplicidade: Relacionamentos.
Valor inicial: Depende da linguagem de programação, valor opcional.
Propriedade: Características do elemento, opcional.
Operação: Função requerida a um objeto.
Nome, Visibilidade e Parâmetros.
Associação: Relacionamentos entre classes.
Nome: Nome da associação.
Multiplicidade
Navegação: De onde vem as informações da classe e para onde vai.

Qual a finalidade?

O diagrama de classes é uma representação da estrutura e relações das classes que servem de modelo para objetos.
É uma modelagem muito útil para o desenvolvimento de sistemas, pois define todas as classes que o sistema necessita possuir e é a base para a construção dos diagramas de comunicação, sequência e estados.

# data[].attributes.body
+ Uso

O Diagrama de Estados serve para mostrar todos os estados possíveis dos objetos de uma classe do modelo, e que eventos do sistema causam essas mudanças de estado. Não há a necessidade de representar os estados dos objetos de todas as classes.

+ Componentes

Estado: Condição ou situação durante a vida de um objeto na qual ele satisfaz algumas condições, executa algumas atividades ou espera por eventos.

Transição: O relacionamento entre dois estados, indicando que o objeto que está no primeiro estado irá passar para o segundo estado mediante a ocorrência de um determinado evento e em certos casos uma condição.

Condição: causa necessária para que haja a transição de estado. Decorre da ocorrência de um evento ou circunstância que propicia a transição de estado.

Estado inicial: Estado por onde se começa a leitura de um diagrama de estado.

Estado final: Estado que representa o fim de uma máquina.

Barra de Sincronização: Semelhante a um Fork do Diagrama de Atividade.

Estado composto: Estado composto por outras máquinas de estado organizadas em regiões que são executadas em paralelo.

Ação: atividade do sistema que efetua a transição de estado

Luis e Marcos

# data[].attributes.body
Mayra e José

►Descrever os componentes de cada Diagrama

♥   Eixo vertical - Mostra o tempo de vida de um objeto (lifeline). Indica a execução do objeto durante a sequência;

♥   Eixo horizontal - Mostra os objetos envolvidos na sequência de alguma atividade. Elas são acompanhadas de um rótulo que contém o nome da mensagem e, opcionalmente, os parâmetros da mesma;

♥   Comunicação entre os objetos - Representada por uma linha com setas horizontais simbolizando as mensagens entre as linhas de vida dos objetos;

♥   Números sequenciais - As mensagens podem possuir também números sequenciais, eles são utilizados para tornar mais explícito a sequência no diagrama;

♥   Seta especifica - Mostra se a mensagem é síncrona (o objeto de origem envia uma mensagem e aguarda por uma mensagem de retorno), assíncrona (mensagens que são processadas em paralelo sem um tempo definido para a sua realização) ou simples;

♥   Mensagens de retorno - São representadas por linhas horizontais tracejadas. Este tipo de mensagem não é frequentemente representada nos diagramas. Este tipo de mensagem só deve ser mostrada quando for fundamental para a clareza do diagrama;

♥   Condição - Representada por uma mensagem cujo rótulo é envolvido por colchetes;

►Tipos de Relação

Só existe associação, não tem relação!

► Pra que serve o diagrama

O diagrama que tem o objetivo de mostrar como as mensagens entre os objetos são trocadas no decorrer do tempo para a realização de uma operação. Representa uma perspectiva, orientada por tempo, da colaboração entre os objetos.

# data[].attributes.body
Filipe, Flavio e Paulo

Componentes

Na Modelagem UML, OS Componentes São Elementos de modelo that representam contraditório Independentes e intercambiáveis ​​de um Sistema. ELES estão em conformidade e realiza Uma UO Mais de interfaces fornecidas e requeridas, that determinam o Comportamento dos Componentes.

Instancias de Componentes

Na Modelagem UML, como instancias de Componentes São Elementos de modelo that representam Entidades reais em hum Sistema.

Pacotes

OS pacotes agrupam Elementos de Modelos Relacionados de Todos os Tipos, incluíndo página Outros Pacotes de Viagens.

Artefatos

Em modelos UML, Artefatos São Elementos representam de modelo that como Entidades software Físicas em um Sistema de. Os Artefatos representam unidades Físicas de Execução, Como Por Exemplo, Arquivos executáveis, Bibliotecas, Componentes de software, Documentos e Bancos de Dados.

Interfaces

Em Modelagem UML, interfaces de São Elementos do modelo that definem Conjuntos de Operações Que Outros Elementos do modelo, as classes Como UO Componentes devem implementar. Um elemento de modelo de Execução Realiza Uma interface de Pela substituição de Cada um dos operandos that uma interface de Declara.

Relacionamentos em Diagramas de Componentes

Na UML, um Relacionamento E UMA Conexão Entre Elementos de Modelo. Um Relacionamento UML e Um tipo de Elementos de modelo that inclui semântica em um modelo, definindo a Estrutura EO Comportamento Entre OS Elementos de Modelo.

Tipos de relação

O Diagrama de Componentes mostra o lado funcional, expondo a relação entre seus componentes e suas dependências.

# data[].attributes.body
Rafael, João
O Diagrama de Classes

O diagrama de classes é considerado por muitos autores como o mais importante e o mais utilizado diagrama da UML. Seu principal enfoque está em permitir a visualização das classes que irão compor o sistema com seus respectivos atributos e métodos, bem como em demonstrar como as classes do sistema se relacionam, se complementam e transmitem informações entre si. Este diagrama apresenta uma visão estática de como as classes estão organizadas, preocupando-se em definir a estrutura lógica das mesmas. O diagrama de classes serve como base para a construção da maior parte dos demais diagramas da UML.

Basicamente, o diagrama de classes é composto por suas classes e pelas associações existentes entre elas, ou seja, os relacionamentos entre as classes. Segundo Guedes em seu livro “UML – Uma Abordagem Prática”, o objetivo do diagrama de classes é mostrar os relacionamentos existentes entre as classes que são abstraídas no projeto, e como esses relacionamentos colaboram para a execução de um processo específico.

Diagramas de Classe

Existem três perspectivas que você pode usar quando projetar diagramas de classes:

·       Conceitual: Se tomarmos a perspectiva conceitual, você projeta um diagrama que representa os conceitos do domínio que está sendo estudado. Estes conceitos serão naturalmente relacionados às classes que irão executá-los. Na verdade, um modelo conceitual deve ser projetado com pouca ou nenhuma preocupação com o software que poderá implementá-lo. Portanto, deve ser considerado independente da linguagem implementada. Esta perspectiva recebe o nome de perspectiva essencial.

·       Especificação: Agora estamos examinando o software, mas estamos analisando as suas interfaces, não a sua implementação. O desenvolvimento orientado a objetos dispõe muita ênfase na diferença entre interface e implementação, mas isso é freqüentemente negligenciado na prática porque a noção que temos de classe em uma linguagem orientada a objetos combina interface com implementação.

·       Implementação: Nesta visão, realmente temos classes e estamos pondo a implementação às claras. Esta é, provavelmente, a perspectiva usada com mais freqüência.

A compreensão das diversas perspectivas é crucial tanto para desenhar como para ler diagramas de classes. Infelizmente, as linhas entre as perspectivas não são rígidas, e a maioria dos analistas de sistemas não se preocupa em ter suas perspectivas classificadas quando eles estão desenvolvendo a modelagem de um sistema.

# data[].attributes.body
Fernando e Wesley

//partes do diagrama
Cenário:  Sequência de eventos que acontecem quando um usuário interage com o sistema.
Ator:  Usuário do sistema, ou melhor, um tipo de usuário.
Use Case:  É uma tarefa ou uma funcionalidade realizada pelo ator (usuário).
Comunicação:  É o que liga um ator com um caso de uso.

// descrição (pra que serve)
O diagrama de uso de caso descreve as principais funcionalidades do sistema e a interação dessas funcionalidades de acordo com a necessidade do usuário. Nesse diagrama não nos aprofundamos em detalhes técnicos que dizem como o sistema faz.

Univoco é quando o ator tem relação com apenas um caso de uso, e biunívoco é quando o ator tem relação com mais de um caso de uso.

# data[].attributes.body
Alexandre e Gustavo

O Diagrama de Atividades serve para mostrar o fluxo em um único processo, assim, mostrando o relacionamento  entre atividades, como uma atividade depende de outra.

Captura Ações e resultados das mudanças de cada objeto.

Executa relações em sequência estruturada de ações, onde cada próximo estagio é executado sem uma especifica necessidade de eventos.