Please enable JavaScript.
Coggle requires JavaScript to display documents.
04 - Unified Modeling Language - UML (Artigo Philippe Kruchten (Visão de…
04 - Unified Modeling Language - UML
Diagramas
Diagrama Estrutural: representam aspectos estáticos do sistema.
São eles: Componente, Classes, Implantação, Perfil, Objetos, Estrutura Composta e Pacotes.
Implantação: apresenta layout físico de um sistema, revelando
quais partes do software são executadas em quais partes do hardware
Perfil: Trata-se de uma UML com um conjunto de estereótipos predefinidos, valores atribuídos, restrições e classes de base
Classes: representa propriedades e as operações de uma classe
relacionamentos
Generalização / Especialização (Herança)
Realização: um elemento realiza (implementa/executa) o comportamento que o outro elemento especifica
Associação
Simples
Qualificada (com identificador)
Agregação: o todo está relacionado às suas partes de forma independente (as partes têm existência própria) - Representação: Diamante Vazio
Composição: o todo está relacionado às partes de forma dependente. Nesse relacionamento, as partes não têm existência própria - Representação:
D
iamante
C
heio
Dependência
Objetos: é uma variação do Diagrama de Classes. Contudo, aqui não se trata da estrutura geral, mas de cada instância específica do sistema. No diagrama de objetos, personaliza-se cada instância com seus valores.
Componente: representa o sistema sob uma perspectiva funcional, expondo a organização de seus módulos e as relações entre seus componentes por meio de interfaces.
Estrutura Composta: modelar colaborações internas de classes, interfaces e componentes para especificar uma funcionalidade
Pacotes: representa os pacotes e suas dependências
Diagrama Comportamental: representam aspectos dinâmicos do sistema.
São eles: Máquina de Estados, Casos de Uso, Atividade, Sequência,
Comunicação, Interação Geral e Tempo
.
Casos de Uso: descreve um conjunto de funcionalidades do sistema e interações com elementos externos e entre si. requisitos funcionais.
include (relacionamento obrigatorio, incondicional)
extends (relacionamento opcional)
Atividade: descreve lógica de procedimento, processo de negócio e fluxos de trabalho. a Swimlane agrupa as atividades e as organizam de acordo com suas respectivas responsabilidades, com o auxílio de
ações, bifurcações, fluxos e ramificações
Máquina de Estados: apresenta diversos estados possíveis de um objeto no decorrer da execução de processos de um sistema
Diagrama de Interação: consideram o
relacionamento dinâmico e colaborativo entre os objetos do sistema e suas trocas de informaçõe
Comunicação
semelhante ao diagrama de sequência, mas com ênfase na ordem estrutural e, não, temporal. Possui numeração.
Interação Geral (ou visão geral)
Diagrama de Interação Geral tem o objetivo de dar uma visão geral dos diversos cenários de um caso de uso. Em versões anteriores da UML, era conhecido como Diagrama de Colaboração.
Sequência
é um diagrama de interação que captura o comportamento de um único cenário, mostrando vários exemplos de objetos e mensagens que são trocadas dentro de caso de uso
Tempo
descreve o comportamento dos objetos no decorrer do tempo e a duração na qual eles permanecem em determinados estados.
Artigo Philippe Kruchten
Visão de Processo: é a visão da arquitetura do sistema sob o ponto de vista do integrador, apresentando requisitos não-funcionais (Desempenho, Escalabilidade, etc)
Visão Física (ou Implantação): é a visão da arquitetura do sistema sob o ponto de vista do engenheiro de sistemas, apresentando a topologia ou distribuição física dos componentes
Visão de Desenvolvimento (ou Implementação): é a visão da arquitetura do sistema sob o ponto de vista do programador
Visão de Casos de Uso (Cenários): é a visão da arquitetura do sistema sob o ponto de vista de todos os usuários das outras visões e avaliadores, apresentando a consistência e validade do sistema
Visão Lógica (de Projeto): é a visão da arquitetura do sistema sob o ponto de vista dos usuários finais, apresentando os requisitos funcionais
Análise x Projeto
Análise (Modelagem do Problema) - O que deve ser feito, com foco no cliente.
atividades
categorização das classes de acordo com sua responsabilidade
Classe de Controle (controlar a lógica de execução ou negócio)
Classe de Entidade (armazenam informações persistentes)
Classe de Fronteira (interação entre ator e sistema)
identificação de responsabilidades
comunicar-se com atores (Fronteira); manter as informações do sistema (Entidade); e coordenar a realização de um caso de uso (Controle).
identificação de atributos
descobrir quais são os atributos, sem nenhuma preocupação sobre qual seu tipo (String, Date, Time, Integer, etc)
identificar os relacionamentos
identificam-se os relacionamentos como associações, agregações, composições, dependências, generalizações, especializações, entre outros.
Projeto (Modelagem da Solução) - Como deve ser feito, com foco no programador.
estrutura de classes
arquitetura de software
deve ser capaz de atender aos requisitos funcionais e não-funcionais do sistema. possibilita correção e validação do sistema antes da implementação
Uma boa arquitetura deve ter componentes projetados com baixo acoplamento (nível de dependência entre módulos) e alta coesão (nível de responsabilidade)
A arquitetura em camadas permite melhor separação de responsabilidades; decomposição de complexidade; encapsulamento de implementação; maior reúso e extensibilidade
Model-View-Controler (MVC)
comportamento de classes
modelo de classes
Modelo de classes de Especificação (ou projeto) estende o modelo de classes de análise e contém detalhes específicos inerentes à solução de software escolhida. O Modelo de Projeto
enfatiza o desenho físico, a visão interna, de implementação, concreta, caixa-branca, de baixo nível de abstração
Modelo de classes de Implementação. estende o modelo de classes de projeto e contém detalhes específicos inerentes ao desenvolvimento das classes em alguma linguagem.
Modelo de classes de Análise (ou domínio) representa as classes de domínio do negócio. O Modelo de Análise enfatiza o desenho lógico, a visão externa, conceitual, abstrata, caixa-preta, de alto nível de abstração
Definir a linguagem de programação não afeta em nada a Análise, apesar de afetar o Projeto.
O Modelo de Análise é mais abstrato que um Modelo de Projetos. Esse segundo já começa a pensar na solução do problema, e o primeiro pensa apenas na modelagem do problema.