Mapeamento entre o modelo de visualização arquitetônica 4 + 1 e a UML

14

Estou um pouco confuso sobre como o modelo de visão arquitetônica 4 + 1 é mapeado para a UML.

Wikipedia fornece o seguinte mapeamento:

  • Vista lógica: diagrama de classes, diagrama de comunicação, diagrama de sequência.
  • Visão de desenvolvimento: Diagrama de componentes, diagrama de pacotes
  • Visão do processo: diagrama de atividades
  • Vista física: diagrama de implementação
  • Cenários: diagrama de casos de uso

O documento Papel das construções do diagrama de seqüência UML no conceito de ciclo de vida do objeto fornece o seguinte mapeamento:

  • Visão lógica (diagrama de classes (CD), diagrama de objetos (OD), diagrama de seqüência (SD), diagrama de colaboração (COD), diagrama de estado (SCD), diagrama de atividades (AD))
  • Visão de desenvolvimento (diagrama de pacote, diagrama de componente),
  • Visão de processo (diagrama de casos de uso, CD, OD, SD, COD, SCD, AD),
  • Visão física (diagrama de implantação) e
  • Use a visão de caso (diagrama de caso de uso, OD, SD, COD, SCD, AD) que combina as quatro mencionadas acima.

A página da web Materiais para visualização da UML 4 + 1 apresenta o seguinte mapeamento :

Porfim,owhitepaper Aplicando a arquitetura de exibição 4 + 1 com a UML 2 fornece mais uma mapeamento:

  • Diagramas de classes Visão lógica , diagramas de objetos, gráficos de estado e estruturas de composição
  • Diagramas de seqüência do Process view , diagramas de comunicação, diagramas de atividades, diagramas de tempo, diagramas de visão geral da interação
  • Diagramas de componentes Visão de desenvolvimento
  • Diagrama de implantação Vista física
  • Visão do caso de uso diagrama de casos de uso, diagramas de atividades

Tenho certeza de que pesquisas adicionais também revelarão outros mapeamentos.

Embora várias pessoas geralmente tenham perspectivas diferentes, não vejo por que esse é o caso aqui. Especialmente, cada diagrama UML descreve o sistema a partir de um aspecto particular. Então, por exemplo, por que o "diagrama de seqüência" é considerado como descrevendo a "visão lógica" do sistema por um autor, enquanto outro autor o considera como descrevendo a "visão de processo"?

Você poderia me ajudar a esclarecer a confusão?

    
por M.S. Dousti 22.03.2014 / 00:36
fonte

3 respostas

18

Embora eu concorde em geral com a resposta de Bart van Ingen Schenau , acho que alguns pontos precisam de uma elaboração adicional.

A vantagem do Modelo de Visualização 4 + 1 é que ele mapeia os interessados para o tipo de informação que eles precisam, sem exigir que as notações de modelagem específicas sejam usadas. A ênfase está em garantir que todos os grupos tenham as informações necessárias para entender o sistema e continuar fazendo seu trabalho.

O Modelo de Arquitetura de Software 4 + 1 foi descrito em Philippe Kruchten's paper Architectural Blueprints - O "4 + 1" View Model of Software Architeture que foi publicado originalmente no IEEE Software (novembro de 1995). Esta publicação não faz referências específicas à UML. De fato, o artigo usa a notação Booch para a visão lógica, extensões para a notação Booch para visão de processo e visão de desenvolvimento, chama a atenção para o uso de "várias formas" de desenvolver uma visão física e uma nova notação para cenários.

Em vez de tentar mapear cada uma das visualizações para tipos específicos de diagramas, considere quem é o público-alvo de cada visualização e quais informações são necessárias. Sabendo disso, observe os vários tipos de modelos e quais (is) fornecem as informações necessárias.

A visão lógica é projetada para atender às preocupações do usuário final em garantir que toda a funcionalidade desejada seja capturada pelo sistema. Em um sistema orientado a objeto, isso geralmente ocorre no nível de classe. Em sistemas complexos, você pode precisar de uma visão de pacote e decompor os pacotes em vários diagramas de classes. Em outros paradigmas, você pode estar interessado em representar os módulos e as funções que eles fornecem. O resultado final deve ser um mapeamento da funcionalidade necessária para os componentes que fornecem essa funcionalidade.

A visão de processo é projetada para pessoas que projetam todo o sistema e, em seguida, integram os subsistemas ou o sistema em um sistema de sistemas. Essa visualização mostra tarefas e processos que o sistema possui, interfaces com o mundo externo e / ou entre componentes dentro do sistema, as mensagens enviadas e recebidas e como o desempenho, a disponibilidade, a tolerância a falhas e a integridade estão sendo resolvidos.

A visão de desenvolvimento é principalmente para desenvolvedores que estarão construindo os módulos e os subsistemas. Ele deve mostrar dependências e relacionamentos entre os módulos, como os módulos são organizados, reutilizados e portáveis.

A visão física é principalmente para os criadores de sistemas e administradores que precisam entender os locais físicos do software, as conexões físicas entre os nós, a implantação e a instalação e a escalabilidade.

Por fim, os cenários ajudam a capturar os requisitos para que todos os envolvidos entendam como o sistema deve ser usado.

Depois de entender o que cada exibição deve fornecer, você pode escolher quais anotações de modelagem usar e em que nível de detalhe é necessário. O último parágrafo de Bart é especialmente verdadeiro - você pode mostrar vários níveis de detalhes em seus modelos UML, concentrando-se em elementos de design específicos ou combinando vários tipos de diagramas em um conjunto. Além disso, você pode considerar ir além da UML para outras notações de modelagem para melhor descrever sua arquitetura de sistema - SysML , Modelagem de relação de entidade ou IDEF .

    
por 22.03.2014 / 11:09
fonte
8

O motivo pelo qual você não pode encontrar um mapeamento um-para-um entre as visualizações do Modelo Arquitetural 4 + 1 e os vários diagramas UML é porque tal mapeamento não existe.

O que todos esses autores estão tentando dizer com seus "mapeamentos" é que, para cada visualização, existe um conjunto diferente de diagramas UML que podem ser úteis para transmitir as informações que você deseja contar nessa visualização.

Além disso, alguns diagramas UML podem ser usados de maneiras diferentes, enfatizando diferentes elementos no diagrama, o que os torna úteis para várias exibições. Mas, mesmo que um tipo de diagrama UML possa ser usado em várias visualizações, você desenharia um diagrama diferente (ou conjunto de diagramas) para cada exibição.

    
por 22.03.2014 / 10:22
fonte
1

Você ainda usa o videocassete que comprou em 1995? 4 + 1 era aplicável naquela época quando o software estava em sua infância. Mas, mesmo assim, ninguém usou mais do que 2 ou 3 "visualizações". Nos últimos 20 anos, a engenharia de software mudou. Hoje em dia, escopo / contexto e conceitual e lógico e físico e ... são todos diferenciados. Muitas soluções COTS devem ser integradas e assim por diante. Hoje, estamos falando de mapas de paisagem, realizações de serviços e dezenas de outras visões e pontos de vista. A melhor maneira de olhar para isso é através de uma estrutura de taxonomia simples como Zachman: 6 visualizações e 6 pontos de vista. Deixe que seja o seu ponto de partida. 6 visualizações são: contextual conceitual ou empresarial lógico ou sistema física ou tecnologia entrega ou artefatos empresa em funcionamento

6 pontos de vista são: dados ou o que função ou como rede ou onde pessoas ou quem tempo ou quando motivação ou porquê

Vamos dar uma olhada. Se estivermos interessados apenas em dados, começaremos com a visão do escopo e dizeremos: "Nosso escopo é CRM". Na visão conceitual para o ponto de vista dos dados, vamos elaborar algum modelo semântico para o CRM. O modelo será conceitual, conceitos de informações de negócios em vez de objetos de dados. Em seguida, na visão lógica, produziremos um modelo de dados lógicos a partir de nosso modelo conceitual de CRM. Podemos usar a metodologia ER para produzir um modelo de dados lógicos. Então, na visão física, produziremos um modelo de dados físico. Aqui, definiremos tipos de dados concretos para a plataforma db de nossa escolha, índices etc. Finalmente, na visualização de entrega, teremos nosso script DDL, enquanto que na visualização corporativa em funcionamento teremos um arquivo binário implementado em algum servidor de banco de dados e mapeado nas estruturas de dados internas do fornecedor do DBMs. Repetimos isso para todos os pontos de vista ou colunas. Além disso, se houver mais de uma parte interessada, criaremos mais de um modelo para cada combinação de ponto de vista / vista. Agora que você tem essa taxonomia em vigor, é possível definir seus próprios pontos de vista e visualizações e alinhá-las nessa taxonomia. Por exemplo, para iniciativas de nível corporativo, os pontos de vista a seguir são todos importantes: cooperação de ator comportamento da aplicação cooperação de aplicação estrutura de aplicação uso de aplicativos função de negócios processo de negócio cooperação em processos de negócios implementação e implantação estrutura de informação a infraestrutura uso de infra-estrutura mapa da paisagem visão global em camadas organizacional realização de serviço etc

O 4 + 1 de Krutchen não poderia satisfazer todas essas necessidades

    
por 12.06.2015 / 19:13
fonte