Arquiteturas de Referncia Definies IEEE 1471ISOIEC 42010 2007

  • Slides: 17
Download presentation
Arquiteturas de Referência

Arquiteturas de Referência

Definições – IEEE 1471/ISO/IEC 42010: 2007 • Visão: – representação de um software (ou

Definições – IEEE 1471/ISO/IEC 42010: 2007 • Visão: – representação de um software (ou parte) a partir de uma perspectiva particular. – coleção de modelos representando a arquitetura do software.

Alguns modelos de arquitetura em múltiplas visões • Kruchten 4+1 • IEEE 1471 •

Alguns modelos de arquitetura em múltiplas visões • Kruchten 4+1 • IEEE 1471 • Siemens (Soni et al)

Logical View • Relativo principalmente aos requisitos funcionais (o que o software deve fazer).

Logical View • Relativo principalmente aos requisitos funcionais (o que o software deve fazer). • Identificação dos principais pacotes, subsistemas e classes • Diagrams mais comuns: – UML Class, Package and Sequence diagrams. – ER diagrams

Process View • Um processo é um grupo de tarefas. • A comunicação entre

Process View • Um processo é um grupo de tarefas. • A comunicação entre tarefas ocorre de várias formas: síncrona, assíncrona, broadcast, . . . • A visão de processos preocupa-se com tópicos como: – concorrência e distribuição, – integridade do software, – tolerância a falhas, – Como abstrações da visão lógica operam na visão de processos da arquitetura.

Process View • Principais estilos: client/server, pipes and filters, publish-subscribe middleware. • Essa visão

Process View • Principais estilos: client/server, pipes and filters, publish-subscribe middleware. • Essa visão mostra onde e como classes/elementos definidos na visão lógica são usados. • Notações usadas: Sequence diagrams, Activity diagrams, Class diagrams (focus on active classes), Components

Implementation/Development view • Organização de módulos do software (código, arquivos de dados, componentes, executáveis,

Implementation/Development view • Organização de módulos do software (código, arquivos de dados, componentes, executáveis, bibliotecas, . . . ) • Principais elementos: módulos, subsistemas, camadas. • Normalmente o estilo é em camadas • A visão de desenvolvimento considera requisitos como facilidade de desenvolvimento, e restrições do ambiente de desenvolvimento e da linguagem

Implementation/Development view • A visão de desenvolvimento é a base para: – alocação de

Implementation/Development view • A visão de desenvolvimento é a base para: – alocação de requisitos e de trabalho entre equipes – Avaliação de custos – Monitoração do projeto – Reuso, portabilidade e segurança.

Physical/Deployment View • Elementos identificados: redes, processadores, tarefas, objetos, e o mapeados em vários

Physical/Deployment View • Elementos identificados: redes, processadores, tarefas, objetos, e o mapeados em vários nós. • Várias configurações físicas diferentes podem ser usadas: algumas para desenvolvimento e testes, outras para a implantação do software em diferentes locais/clientes. • Mostra como os vários executáveis e componentes são mapeados para plataformas e nós físicos • Mostra distribuição física de elementos do sistema • Notações: proprietária, pacotes, nós, UML deployment diagram

Scenario/Use Case View • Mostra como os elementos das 4 visões trabalham juntos. •

Scenario/Use Case View • Mostra como os elementos das 4 visões trabalham juntos. • Notações: – Use Cases – Linguagem natural – Pode-se especificar os use-cases com diagramas UML (Sequência, Atividades) • Principais objetivos: – Direção para descobrir os elementos da arquitetura – Validação e ilustração da arquitetura do software – Ponto de partida para desenvolvimento e testes

ANSI-IEEE 1471 -2000/ ISO/IEC 42010: 20 Systems and Software Engineering -- Recommended practice for

ANSI-IEEE 1471 -2000/ ISO/IEC 42010: 20 Systems and Software Engineering -- Recommended practice for architectural description of software-intensive systems 07

Análise do Framework • Um sistema existe em um ambiente (contexto). O ambiente do

Análise do Framework • Um sistema existe em um ambiente (contexto). O ambiente do sistema pode influenciar o sistema. • O ambiente determina as circunstâncias de desenvolvimento, operacionais, e políticas. • O ambiente determina os limites que definem o escopo do sistema em relação a outros sistemas. • Um sistema possui um ou mais stakeholders. Cada stakeholder tipicamente possui interesses (concerns) no sistema. • Um sistema existe para realizar uma ou mais missões. • Todo sistema possui uma arquitetura. • Uma arquitetura (conceito) é estabelecida por uma descrição de arquitetura (produtos concretos).

Exemplo

Exemplo

Quantas visões? • Nem todo software precisa de todas as 5 visões do 4+1

Quantas visões? • Nem todo software precisa de todas as 5 visões do 4+1 • Nem todo software precisa de várias visões • Ex. – Um único processador → não precisa da visão de deployment – Um único processo → não precisa da visão de processos

Siemens • Diferentes estruturas são usadas em diferentes fases do processo de desenvolvimento. –

Siemens • Diferentes estruturas são usadas em diferentes fases do processo de desenvolvimento. – A arquitetura conceitual descreve o sistema em termos dos principais elementos de design e suas relações – A arquitetura de interconexão de módulos é composta por duas estruturas ortogonais: decomposição funcional e camadas. – A arquitetura de execução descreve a estrutura dinâmica de um sistema. – A arquitetura de código descreve as bibliotecas e o código fonte organizados no ambiente de desenvolvimento.