Arquitertura de Software

...

A arquitetura lógica

A decomposição A arquitetura lógica orientada a objetos suporta principalmente os requisitos funcionais-o que o sistema deve fornecer em termos de serviços aos seus usuários. O sistema é decomposto em um conjunto de abstrações-chave, tomadas (principalmente) de o domínio de problemas, na forma de objectos ou classes de objectos. Eles exploram os princípios da abstração, encapsulamento e herança. Esta decomposição não é apenas para fins de análise funcional, mas também serve para identificar mecanismos comuns e elementos de design entre as várias partes do sistema. Nós usamos a abordagem Rational / Booch para representar a arquitetura lógica, por meio de diagramas de classe e classe templates. 4 Um diagrama de classes mostra um conjunto de classes e suas relações lógicas: associação, uso, composição, herança e assim por diante. Conjuntos de classes relacionadas podem ser agrupados em categorias de classe. Modelos de classe concentrar em cada classe individual; eles enfatizam as principais operações de classe, e identificar as principais características do objeto. Se for importante para definir o comportamento interno de um objecto, isto é feito com a transição de estado diagramas, gráficos ou estaduais. Mecanismos ou serviços comuns são definidos de utilitários de classe. Como alternativa a uma abordagem OO, uma aplicação que é orientada dados muito pode usar alguma outra forma de vista lógico, tais como diagramas ER.

Notação para a visualização lógica

A notação para o ponto de vista lógico é derivado do notation4 Booch. Ele é consideravelmente simplificado para levar em conta apenas os itens que são significativos para a arquitetura. Em particular, os numerosos adornos não são muito úteis neste nível de cartão. Nós usamos Rational Rose para apoiar o design de arquitetura lógica.

Estilo para o ponto de vista lógico

O estilo que usamos para a visualização lógica é um estilo orientado a objetos. A principal diretriz para o projeto da visão lógica é para tentar manter um modelo de objeto único e coerente em todo o sistema, para evitar uma especialização prematura de classes e mecanismos por site ou por processador.

Um PABX estabelece commmunications entre os terminais. Um terminal pode ser um conjunto de telefone, uma linha tronca (ou seja, a linha-office central), uma linha de ligação (ou seja, PABX privado para a linha de PABX), uma linha de telefone de recurso, uma linha de dados, uma linha ISDN, etc. Different linhas são suportados por diferentes placas de interface de linha. A responsabilidade de um controlador de linha é objecto de descodificar e injectar todos os sinais na placa de interface de linha, traduzindo-specific cartão sinais de e para um conjunto pequeno e uniforme de eventos: iniciar, parar, dígitos, etc. O controlador também tem todas as duras restrições de tempo real. Esta classe tem muitas subclasses para atender a diferentes tipos de interfaces. A responsabilidade do objecto do terminal é para manter o estado de um terminal, e negociar serviços em nome dessa linha. Por exemplo, ele usa os serviços do plano de numeração para interpretar a marcação na fase de selecção. A conversa representa um conjunto de terminais envolvido em uma conversa. A conversa utiliza serviços de tradução (diretório, lógicas para mapeamento de endereço físico, rotas), e serviços de conexão para estabelecer um caminho de voz entre os terminais. Para um sistema muito maior, que contém algumas dezenas de classes de importância arquitetônica, figura 3b mostram o diagrama de classe de nível superior de um sistema de controle de tráfego aéreo, contendo 8 categorias de classe (ou seja, grupos de classes).

A arquitetura de Processos

O processo de decomposição A arquitetura processo leva em conta alguns requisitos não-funcionais, como desempenho e disponibilidade. Aborda questões de simultaneidade e distribuição, da integridade do sistema, de tolerância a falhas, e como as principais abstrações do ajuste lógico vista dentro do processo de arquitetura em que thread de controle é uma operação de um objeto realmente executada. A arquitetura processo pode ser descrito em vários níveis de abstração, cada nível abordando diferentes preocupações. No nível mais alto, a arquitectura processo pode ser visto como um conjunto de execução independentemente redes lógicas de programas que comunicam (designados por "processos"), distribuídos através de um conjunto de recursos de hardware ligados por uma LAN ou uma WAN. Podem existir simultaneamente várias redes lógicas, compartilhando os mesmos recursos físicos. Por exemplo, as redes lógicas independentes podem ser utilizados para suportar a separação do sistema operacional on-line a partir do sistema de fora de linha, bem como apoiar a coexistência de versões de simulação ou teste do software. Um processo é um agrupamento de tarefas que formam uma unidade executável. Processos representam o nível em que a arquitetura de processo pode ser taticamente controlada (ou seja, começado, recuperado, reconfigurado, e desligar). Além disso, os processos podem ser replicados para uma maior distribuição da carga de processamento, ou para melhorar a disponibilidade. O software é dividido em um conjunto de tarefas independentes. Uma tarefa é um segmento separado de controlo, que pode ser programado individualmente sobre um nó de processamento. Podemos distinguir então: tarefas principais, que são os elementos arquitetônicos que podem ser abordados de forma única e tarefas menores, que são tarefas adicionais introduzidos localmente por razões de implementação (atividades cíclicas, buffer, time-outs, etc.). Eles podem ser implementadas como tarefas Ada, por exemplo, ou threads leves. Tarefas principais comunicar através de um conjunto de mecanismos bem definidos inter-tarefa de comunicação: serviços de comunicações baseados em mensagens síncronas e assíncronas, chamadas de procedimento remoto, transmissão de eventos, etc. tarefas menores podem se comunicar por encontro ou memória compartilhada. Tarefas importantes não devem fazer suposições sobre a sua colocação no mesmo processo ou nó de processamento. Fluxo de mensagens, cargas de processo podem ser estimadas com base no modelo de processo. Também é possível implementar uma arquitetura de processos "oca" com cargas dummy para os processos, e medir o seu desempenho no sistema de destino, tal como descrito por Filarey et ai. Em seu experimento Eurocontrol.

Notação para a vista de processo

A