Contexto do sistema e as interações A primeira fase em qualquer processo de criação de software é desenvolver um entendimento do relações entre o software que

está sendo projetado e seu ambiente externo. Isto é essencial para decidir a forma de fornecer a funcionalidade do sistema exigido e como estruturar o sistema para se comunicar com seu ambiente. entendimento do contexto permite também estabelecer os limites do sistema. Definir os limites do sistema ajuda a decidir quais recursos são implementados no sistema que está sendo projetado e quais recursos estão em outros sistemas associados. em Neste caso, você precisa decidir como a funcionalidade é distribuído entre o controle sistema para todas as estações de tempo, e o software incorporado no clima própria estação. Modelos de contexto do sistema e modelos de interação apresentam visões complementares de as relações entre um sistema e seu ambiente: 1. Um modelo de sistema de contexto é um modelo estrutural que demonstra os outros sistemas no ambiente do sistema que está sendo desenvolvida. 2. Um modelo de interação é um modelo dinâmico que mostra como o sistema interage com o seu meio ambiente, uma vez que é utilizado. O modelo de contexto de um sistema pode ser representado usando associações. associações simplesmente mostrar que existem algumas relações entre as entidades envolvidas na associação. A natureza da relação agora é especificada. Você pode, portanto, documentar o ambiente do sistema, utilizando um diagrama de blocos simples, mostrando as entidades no sistema e das suas associações. Isto é ilustrado na figura 7.1, o que demonstra que os sistemas no ambiente de cada estação meteorológica é um sistema de informações sobre o tempo, um sistema de satélite de bordo e um sistema de controlo. As informações sobre cardinalidade

o link mostra que existe um sistema de controle, mas várias estações meteorológicas, um satélite, e um sistema de informações sobre o tempo em geral. Quando você modelar as interações de um sistema com o seu ambiente, você deve usar uma abordagem abstrata que não inclui muitos detalhes. Uma maneira de fazer isso é utilizar um modelo de caso de uso. Como já discutido nos capítulos 4 e 5, cada caso de uso representa uma a interacção com o sistema. Cada possível interação é nomeado em uma elipse e a entidade externa envolvida na interacção é representado por um boneco. O modelo de caso de uso para a estação meteorológica é mostrado na Figura 7.2. Isto demonstra que a estação meteorológica interage com o sistema de informações sobre o tempo para relatar dados meteorológicos e do estado do hardware estação meteorológica. Outras interações são com um sistema de controle que pode emitir comandos específicos de controle de estações meteorológicas. como eu explica no Capítulo 5, uma figura da vara é utilizado na UML para representar outros sistemas bem como os utilizadores humanos. Cada um desses casos de uso devem ser descritos em linguagem natural estruturada. este ajuda os designers a identificar objetos no sistema e dá-lhes uma compreensão de que o sistema se destina a fazer. Eu uso um formato padrão para essa descrição que identifica claramente quais informações são trocadas, como a interação é iniciada, e assim por diante. Isto é mostrado na figura 7.3, o qual descreve o caso de uso de tempo Reportar Figura 7.2. Exemplos de alguns outros casos de uso são na web.

7.1.2 projeto arquitetônico Uma vez que as interações entre o sistema de software e do ambiente do sistema foram definidos, você pode usar essas informações como base para a concepção do sistema arquitetura. Claro, você precisa combinar com o seu conhecimento geral

os princípios do projeto arquitetônico e com conhecimento de domínio mais detalhado Você identifica os principais componentes que compõem o sistema e suas interações, e, em seguida, pode organizar os componentes utilizando um padrão de arquitetura, como uma camada ou modelo cliente-servidor. No entanto, isto não é essencial nesta fase. O projeto arquitetônico de alto nível para o software de estação meteorológica é mostrado na Figura 7.4. A estação meteorológica é composta por subsistemas independentes que se comunicam pela transmissão de mensagens em uma infra-estrutura comum, como o Link de comunicação na Figura 7.4. Cada subsistema escuta as mensagens de que infra-estrutura e pega as mensagens que são destinados a elas. isto é outra arquitectura utilizada em adição aos descritos no Capítulo 6. Por exemplo, quando o subsistema de comunicação recebe um comando de controlo, como o desligamento, o comando é captado por cada um dos outros subsistemas, que, em seguida, fechou-se para baixo de maneira correta. O principal benefício deste Arquitectura é que é fácil de suportar diferentes configurações de subsistemas porque o remetente de uma mensagem não precisa de lidar com a mensagem a uma determinada subsistema. Figura 7.5 mostra a arquitetura do subsistema de coleta de dados, que é incluída na Figura 7.4. O transmissor eo receptor objetos estão preocupados com Gerenciamento das Comunicações eo objeto WeatherData encapsula as informações que é recolhida a partir dos instrumentos e transmitidos para a informação meteorológica sistema. Este acordo segue o padrão do produtor-consumidor, discutido no Capítulo 20.

7.1.3 Identificação de classe de objeto

Nesta fase do processo de projeto, você deve ter algumas idéias sobre o essencial objetos do sistema que você está projetando. Como a sua compreensão da projeto se desenvolve, a refinar essas idéias sobre os objetos do sistema. O caso de uso descrição ajuda a identificar objetos e operações no sistema. Do descrição do caso de uso Weather Report, é óbvio que os objetos que representam os instrumentos que coletam dados meteorológicos serão necessários, assim como um objeto representando o resumo dos dados meteorológicos. Você também geralmente precisam de um objeto do sistema de alto nível ou objetos que encapsulam as interações do sistema definidos no os casos de uso. Com esses objetos em mente, você pode começar a identificar as classes de objetos no sistema. Houve várias propostas sobre como identificar as classes de objetos em sistemas orientados a objetos: 1. Use uma análise gramatical de uma descrição em linguagem natural do sistema a ser calculado. Objetos e atributos são substantivos; operações ou serviços são verbos (Abbot, 1983). 2. Use entidades tangíveis (coisas) no domínio do aplicativo, tais como aviões, papéis como gerente ou médico, eventos, tais como pedidos, interações, tais como reuniões, locais, tais como escritórios, unidades organizacionais, tais como empresas, e assim por diante (Coad e Yourdon, 1990; Shlaer e Mellor, 1988; Wirfs-Brock et ai., 1990). 3. Use uma análise baseada em cenários onde são identificados vários cenários de uso do sistema e analisadas por sua vez. À medida que cada cenário é analisado, a equipe responsável pela a análise deve identificar os objetos necessários, atributos e operações (Beck e Cunningham, 1989). Na prática, você tem que usar várias fontes de conhecimento para descobrir as classes de objetos.

Classes de objetos, atributos e operações que são inicialmente identificados a partir do informal descrição do sistema pode ser um ponto de partida para o design. Outras informações de conhecimento do domínio de aplicação ou análise de cenário pode ser usado para refinar e estender os objetos iniciais. Esta informação pode ser recolhida a partir de requisitos documentos, discussões com usuários, ou a partir de análises dos sistemas existentes. Na estação meteorológica deserto, identificação de objetos é baseada na tangível hardware no sistema. Eu não tenho espaço para incluir todos os objetos do sistema aqui, mas Eu mostrei cinco classes de objetos na figura 7.6. O termômetro de solo, Anemômetro, e Barómetro objetos são objetos de domínio de aplicação, ea EstaçãoMeteorológica e WeatherData objectos terem sido identificado a partir do sistema descrição eo cenário (caso de uso) Descrição: 1. A classe de objeto EstaçãoMeteorológica fornece a interface básica do tempo estação com o seu ambiente. Suas operações refletem as interações mostradas na Figura 7.3. Neste caso, eu uso uma única classe de objeto para encapsular todos estes interações, mas em outros projetos que você poderia projetar a interface do sistema como vários diferentes classes. 2. A classe de objeto WeatherData é responsável por processar o clima relatório de comando. Ele envia os dados resumidos dos instrumentos Estação Meteorológica o sistema de informações meteorológicas. 3. O termômetro terra, anemômetro, e classes de objetos Barómetro são directamente relacionada com instrumentos no sistema. Eles refletem hardware tangível entidades do sistema e as operações estão preocupados com o controle que hardware. Esses objetos operar de forma autônoma para coletar dados no especificada frequência e armazenar os dados recolhidos no local. Estes dados são entregues ao Objeto WeatherData a pedido. Você usa o conhecimento do domínio da aplicação para identificar outros objetos, atributos,

e serviços. Sabemos que as estações meteorológicas são muitas vezes localizados em lugares remotos e incluir vários instrumentos que às vezes dão errado. Falhas do instrumento deve ser relataram automaticamente. Isto implica que você precisa atributos e operações para verificar o correto funcionamento dos instrumentos. Há muitas estações meteorológicas remotas para cada estação meteorológica deve ter seu próprio identificador. Nesta fase do processo de projeto, você deve se concentrar nos próprios objetos, sem pensando sobre como isso pode ser implementado. Depois de ter identificado o objetos, então você refinar o design do objeto. Você olha para as características comuns e, em seguida, projetar a hierarquia de herança para o sistema. Por exemplo, você pode identificar uma Instrumento superclasse, que define as características comuns de todos os instrumentos, como um identificador, e obter e operações de teste. Você também pode adicionar novos atributos e operações para a superclasse, como um atributo que mantém a freqüência de coleta de dados.

SLIDE 1 A primeira fase em qualquer processo de criação de software é desenvolver um entendimento do relações entre o software que está sendo projetado e seu ambiente externo. Isto é essencial para decidir a forma de fornecer a funcionalidade do sistema exigido e como estruturar o sistema para se comunicar com seu ambiente. entendimento do contexto permite também estabelecer os limites do sistema. Definir os limites do sistema ajuda a decidir quais recursos são implementados no sistema que está sendo projetado e quais recursos estão em outros sistemas associados. em Neste caso, você precisa decidir como a funcionalidade é distribuído entre o controle sistema para todas as estações de tempo, e o software incorporado no clima própria estação.

Modelos de contexto do sistema e modelos de interação apresentam visões complementares de as relações entre um sistema e seu ambiente: 1. Um modelo de sistema de contexto é um modelo estrutural que demonstra os outros sistemas no ambiente do sistema que está sendo desenvolvida. 2. Um modelo de interação é um modelo dinâmico que mostra como o sistema interage com o seu meio ambiente, uma vez que é utilizado. O modelo de contexto de um sistema pode ser representado usando associações. associações simplesmente mostrar que existem algumas relações entre as entidades envolvidas na associação.

SLIDE 2 shows that the systems in the environment of each weather station are a weather information system, an onboard satellite system, and a control system. The cardinality information on the link shows that there is one control system but several weather stations, one satellite, and one general weather information system.

SLIDE 3 Quando você modelar as interações de um sistema com o seu ambiente, você deve usar uma abordagem abstrata que não inclui muitos detalhes. Uma maneira de fazer isso é utilizar um modelo de caso de uso. Como já discutido nos capítulos 4 e 5, cada caso de uso representa uma a interacção com o sistema. Cada possível interação é nomeado em uma elipse ea entidade externa envolvida na interacção é representado por um boneco. O modelo de caso de uso para a estação meteorológica é mostrado na Figura 7.2. Isto demonstra que a estação meteorológica interage com o sistema de informações sobre o tempo para relatar

dados meteorológicos e do estado do hardware estação meteorológica. Outras interações são com um sistema de controle que pode emitir comandos específicos de controle de estações meteorológicas. como eu explica no Capítulo 5, uma figura da vara é utilizado na UML para representar outros sistemas bem como os utilizadores humanos. SLIDE 4 Você identifica os principais componentes que compõem o sistema e suas interações, e, em seguida, pode organizar os componentes utilizando um padrão de arquitetura, como uma camada ou modelo cliente-servidor. No entanto, isto não é essencial nesta fase. O projeto arquitetônico de alto nível para o software de estação meteorológica é mostrado na Figura 7.4. A estação meteorológica é composta por subsistemas independentes que se comunicam pela transmissão de mensagens em uma infra-estrutura comum, como o Link de comunicação na Figura 7.4. Cada subsistema escuta as mensagens de que infra-estrutura e pega as mensagens que são destinados a elas. isto é outra arquitectura utilizada em adição aos descritos no Capítulo 6. Por exemplo, quando o subsistema de comunicação recebe um comando de controlo, como o desligamento, o comando é captado por cada um dos outros subsistemas, que, em seguida, fechou-se para baixo de maneira correta. O principal benefício deste Arquitectura é que é fácil de suportar diferentes configurações de subsistemas porque o remetente de uma mensagem não precisa de lidar com a mensagem a uma determinada subsistema.

SLIDE 5 Figura 7.5 mostra a arquitetura do subsistema de coleta de dados, que é incluída na Figura 7.4. O transmissor eo receptor objetos estão preocupados com

Gerenciamento das Comunicações eo objeto WeatherData encapsula as informações que é recolhida a partir dos instrumentos e transmitidos para a informação meteorológica sistema. SLIDE 6 Na prática, você tem que usar várias fontes de conhecimento para descobrir as classes de objetos. Classes de objetos, atributos e operações que são inicialmente identificados a partir do informal descrição do sistema pode ser um ponto de partida para o design. Outras informações de conhecimento do domínio de aplicação ou análise de cenário pode ser usado para refinar e estender os objetos iniciais. Esta informação pode ser recolhida a partir de requisitos documentos, discussões com usuários, ou a partir de análises dos sistemas existentes.

Houve várias propostas sobre como identificar as classes de objetos em sistemas orientados a objetos: 1. Use uma análise gramatical de uma descrição em linguagem natural do sistema a ser calculado. Objetos e atributos são substantivos; operações ou serviços são verbos 2. Use entidades tangíveis (coisas) no domínio do aplicativo, tais como aviões, papéis como gerente ou médico, eventos, tais como pedidos, interações, tais como reuniões, locais, tais como escritórios, unidades organizacionais, tais como empresas, e assim por diante. 3. Use uma análise baseada em cenários onde são identificados vários cenários de uso do sistema e analisadas por sua vez. À medida que cada cenário é analisado, a equipe responsável pela a análise deve identificar os objetos necessários, atributos e operações.

SLIDE 7 Na estação meteorológica deserto, identificação de objetos é baseada na tangível hardware no sistema. Eu não tenho espaço para incluir todos os objetos do sistema aqui, mas

Eu mostrei cinco classes de objetos na figura 7.6. O termômetro de solo, Anemômetro, e Barómetro objetos são objetos de domínio de aplicação, ea EstaçãoMeteorológica e WeatherData objectos terem sido identificado a partir do sistema descrição eo cenário (caso de uso) Descrição: 1. A classe de objeto EstaçãoMeteorológica fornece a interface básica do tempo estação com o seu ambiente. Suas operações refletem as interações mostradas na Figura 7.3. Neste caso, eu uso uma única classe de objeto para encapsular todos estes interações, mas em outros projetos que você poderia projetar a interface do sistema como vários diferentes classes. 2. A classe de objeto WeatherData é responsável por processar o clima relatório de comando. Ele envia os dados resumidos dos instrumentos Estação Meteorológica o sistema de informações meteorológicas. 3. O termômetro terra, anemômetro, e classes de objetos Barómetro são directamente relacionada com instrumentos no sistema. Eles refletem hardware tangível entidades do sistema e as operações estão preocupados com o controle que hardware. Esses objetos operar de forma autônoma para coletar dados no especificada frequência e armazenar os dados recolhidos no local. Estes dados são entregues ao Objeto WeatherData a pedido.