Contexto do sistema e as interaes A primeira fase em qualquer processo de criao de software desenvolver um entendimento do relaes entre o software que

e 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 tambm estabelecer os limites do sistema. Definir os limites do sistema ajuda a decidir quais recursos so implementados no sistema que est sendo projetado e quais recursos esto em outros sistemas associados. em Neste caso, voc precisa decidir como a funcionalidade distribudo entre o controle sistema para todas as estaes de tempo, e o software incorporado no clima prpria estao. Modelos de contexto do sistema e modelos de interao apresentam vises complementares de as relaes 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 interao um modelo dinmico 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 associaes. associaes simplesmente mostrar que existem algumas relaes entre as entidades envolvidas na associao. A natureza da relao agora especificada. Voc pode, portanto, documentar o ambiente do sistema, utilizando um diagrama de blocos simples, mostrando as entidades no sistema e das suas associaes. Isto ilustrado na figura 7.1, o que demonstra que os sistemas no ambiente de cada estao meteorolgica um sistema de informaes sobre o tempo, um sistema de satlite de bordo e um sistema de controlo. As informaes sobre cardinalidade

o link mostra que existe um sistema de controle, mas vrias estaes meteorolgicas, um satlite, e um sistema de informaes sobre o tempo em geral. Quando voc modelar as interaes de um sistema com o seu ambiente, voc deve usar uma abordagem abstrata que no inclui muitos detalhes. Uma maneira de fazer isso utilizar um modelo de caso de uso. Como j discutido nos captulos 4 e 5, cada caso de uso representa uma a interaco com o sistema. Cada possvel interao nomeado em uma elipse e a entidade externa envolvida na interaco representado por um boneco. O modelo de caso de uso para a estao meteorolgica mostrado na Figura 7.2. Isto demonstra que a estao meteorolgica interage com o sistema de informaes sobre o tempo para relatar dados meteorolgicos e do estado do hardware estao meteorolgica. Outras interaes so com um sistema de controle que pode emitir comandos especficos de controle de estaes meteorolgicas. como eu explica no Captulo 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 compreenso de que o sistema se destina a fazer. Eu uso um formato padro para essa descrio que identifica claramente quais informaes so trocadas, como a interao 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 so na web.

7.1.2 projeto arquitetnico Uma vez que as interaes entre o sistema de software e do ambiente do sistema foram definidos, voc pode usar essas informaes como base para a concepo do sistema arquitetura. Claro, voc precisa combinar com o seu conhecimento geral

os princpios do projeto arquitetnico e com conhecimento de domnio mais detalhado Voc identifica os principais componentes que compem o sistema e suas interaes, e, em seguida, pode organizar os componentes utilizando um padro de arquitetura, como uma camada ou modelo cliente-servidor. No entanto, isto no essencial nesta fase. O projeto arquitetnico de alto nvel para o software de estao meteorolgica mostrado na Figura 7.4. A estao meteorolgica composta por subsistemas independentes que se comunicam pela transmisso de mensagens em uma infra-estrutura comum, como o Link de comunicao na Figura 7.4. Cada subsistema escuta as mensagens de que infra-estrutura e pega as mensagens que so destinados a elas. isto outra arquitectura utilizada em adio aos descritos no Captulo 6. Por exemplo, quando o subsistema de comunicao 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 benefcio deste Arquitectura que fcil de suportar diferentes configuraes de subsistemas porque o remetente de uma mensagem no precisa de lidar com a mensagem a uma determinada subsistema. Figura 7.5 mostra a arquitetura do subsistema de coleta de dados, que includa na Figura 7.4. O transmissor eo receptor objetos esto preocupados com Gerenciamento das Comunicaes eo objeto WeatherData encapsula as informaes que recolhida a partir dos instrumentos e transmitidos para a informao meteorolgica sistema. Este acordo segue o padro do produtor-consumidor, discutido no Captulo 20.

7.1.3 Identificao de classe de objeto

Nesta fase do processo de projeto, voc deve ter algumas idias sobre o essencial objetos do sistema que voc est projetando. Como a sua compreenso da projeto se desenvolve, a refinar essas idias sobre os objetos do sistema. O caso de uso descrio ajuda a identificar objetos e operaes no sistema. Do descrio do caso de uso Weather Report, bvio que os objetos que representam os instrumentos que coletam dados meteorolgicos sero necessrios, assim como um objeto representando o resumo dos dados meteorolgicos. Voc tambm geralmente precisam de um objeto do sistema de alto nvel ou objetos que encapsulam as interaes do sistema definidos no os casos de uso. Com esses objetos em mente, voc pode comear a identificar as classes de objetos no sistema. Houve vrias propostas sobre como identificar as classes de objetos em sistemas orientados a objetos: 1. Use uma anlise gramatical de uma descrio em linguagem natural do sistema a ser calculado. Objetos e atributos so substantivos; operaes ou servios so verbos (Abbot, 1983). 2. Use entidades tangveis (coisas) no domnio do aplicativo, tais como avies, papis como gerente ou mdico, eventos, tais como pedidos, interaes, tais como reunies, locais, tais como escritrios, 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 anlise baseada em cenrios onde so identificados vrios cenrios de uso do sistema e analisadas por sua vez. medida que cada cenrio analisado, a equipe responsvel pela a anlise deve identificar os objetos necessrios, atributos e operaes (Beck e Cunningham, 1989). Na prtica, voc tem que usar vrias fontes de conhecimento para descobrir as classes de objetos.

Classes de objetos, atributos e operaes que so inicialmente identificados a partir do informal descrio do sistema pode ser um ponto de partida para o design. Outras informaes de conhecimento do domnio de aplicao ou anlise de cenrio pode ser usado para refinar e estender os objetos iniciais. Esta informao pode ser recolhida a partir de requisitos documentos, discusses com usurios, ou a partir de anlises dos sistemas existentes. Na estao meteorolgica deserto, identificao de objetos baseada na tangvel hardware no sistema. Eu no tenho espao para incluir todos os objetos do sistema aqui, mas Eu mostrei cinco classes de objetos na figura 7.6. O termmetro de solo, Anemmetro, e Barmetro objetos so objetos de domnio de aplicao, ea EstaoMeteorolgica e WeatherData objectos terem sido identificado a partir do sistema descrio eo cenrio (caso de uso) Descrio: 1. A classe de objeto EstaoMeteorolgica fornece a interface bsica do tempo estao com o seu ambiente. Suas operaes refletem as interaes mostradas na Figura 7.3. Neste caso, eu uso uma nica classe de objeto para encapsular todos estes interaes, mas em outros projetos que voc poderia projetar a interface do sistema como vrios diferentes classes. 2. A classe de objeto WeatherData responsvel por processar o clima relatrio de comando. Ele envia os dados resumidos dos instrumentos Estao Meteorolgica o sistema de informaes meteorolgicas. 3. O termmetro terra, anemmetro, e classes de objetos Barmetro so directamente relacionada com instrumentos no sistema. Eles refletem hardware tangvel entidades do sistema e as operaes esto preocupados com o controle que hardware. Esses objetos operar de forma autnoma para coletar dados no especificada frequncia e armazenar os dados recolhidos no local. Estes dados so entregues ao Objeto WeatherData a pedido. Voc usa o conhecimento do domnio da aplicao para identificar outros objetos, atributos,

e servios. Sabemos que as estaes meteorolgicas so muitas vezes localizados em lugares remotos e incluir vrios instrumentos que s vezes do errado. Falhas do instrumento deve ser relataram automaticamente. Isto implica que voc precisa atributos e operaes para verificar o correto funcionamento dos instrumentos. H muitas estaes meteorolgicas remotas para cada estao meteorolgica deve ter seu prprio identificador. Nesta fase do processo de projeto, voc deve se concentrar nos prprios objetos, sem pensando sobre como isso pode ser implementado. Depois de ter identificado o objetos, ento voc refinar o design do objeto. Voc olha para as caractersticas comuns e, em seguida, projetar a hierarquia de herana para o sistema. Por exemplo, voc pode identificar uma Instrumento superclasse, que define as caractersticas comuns de todos os instrumentos, como um identificador, e obter e operaes de teste. Voc tambm pode adicionar novos atributos e operaes para a superclasse, como um atributo que mantm a freqncia de coleta de dados.

SLIDE 1 A primeira fase em qualquer processo de criao de software desenvolver um entendimento do relaes 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 tambm estabelecer os limites do sistema. Definir os limites do sistema ajuda a decidir quais recursos so implementados no sistema que est sendo projetado e quais recursos esto em outros sistemas associados. em Neste caso, voc precisa decidir como a funcionalidade distribudo entre o controle sistema para todas as estaes de tempo, e o software incorporado no clima prpria estao.

Modelos de contexto do sistema e modelos de interao apresentam vises complementares de as relaes 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 interao um modelo dinmico 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 associaes. associaes simplesmente mostrar que existem algumas relaes entre as entidades envolvidas na associao.

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 interaes de um sistema com o seu ambiente, voc deve usar uma abordagem abstrata que no inclui muitos detalhes. Uma maneira de fazer isso utilizar um modelo de caso de uso. Como j discutido nos captulos 4 e 5, cada caso de uso representa uma a interaco com o sistema. Cada possvel interao nomeado em uma elipse ea entidade externa envolvida na interaco representado por um boneco. O modelo de caso de uso para a estao meteorolgica mostrado na Figura 7.2. Isto demonstra que a estao meteorolgica interage com o sistema de informaes sobre o tempo para relatar

dados meteorolgicos e do estado do hardware estao meteorolgica. Outras interaes so com um sistema de controle que pode emitir comandos especficos de controle de estaes meteorolgicas. como eu explica no Captulo 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 compem o sistema e suas interaes, e, em seguida, pode organizar os componentes utilizando um padro de arquitetura, como uma camada ou modelo cliente-servidor. No entanto, isto no essencial nesta fase. O projeto arquitetnico de alto nvel para o software de estao meteorolgica mostrado na Figura 7.4. A estao meteorolgica composta por subsistemas independentes que se comunicam pela transmisso de mensagens em uma infra-estrutura comum, como o Link de comunicao na Figura 7.4. Cada subsistema escuta as mensagens de que infra-estrutura e pega as mensagens que so destinados a elas. isto outra arquitectura utilizada em adio aos descritos no Captulo 6. Por exemplo, quando o subsistema de comunicao 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 benefcio deste Arquitectura que fcil de suportar diferentes configuraes de subsistemas porque o remetente de uma mensagem no 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 includa na Figura 7.4. O transmissor eo receptor objetos esto preocupados com

Gerenciamento das Comunicaes eo objeto WeatherData encapsula as informaes que recolhida a partir dos instrumentos e transmitidos para a informao meteorolgica sistema. SLIDE 6 Na prtica, voc tem que usar vrias fontes de conhecimento para descobrir as classes de objetos. Classes de objetos, atributos e operaes que so inicialmente identificados a partir do informal descrio do sistema pode ser um ponto de partida para o design. Outras informaes de conhecimento do domnio de aplicao ou anlise de cenrio pode ser usado para refinar e estender os objetos iniciais. Esta informao pode ser recolhida a partir de requisitos documentos, discusses com usurios, ou a partir de anlises dos sistemas existentes.

Houve vrias propostas sobre como identificar as classes de objetos em sistemas orientados a objetos: 1. Use uma anlise gramatical de uma descrio em linguagem natural do sistema a ser calculado. Objetos e atributos so substantivos; operaes ou servios so verbos 2. Use entidades tangveis (coisas) no domnio do aplicativo, tais como avies, papis como gerente ou mdico, eventos, tais como pedidos, interaes, tais como reunies, locais, tais como escritrios, unidades organizacionais, tais como empresas, e assim por diante. 3. Use uma anlise baseada em cenrios onde so identificados vrios cenrios de uso do sistema e analisadas por sua vez. medida que cada cenrio analisado, a equipe responsvel pela a anlise deve identificar os objetos necessrios, atributos e operaes.

SLIDE 7 Na estao meteorolgica deserto, identificao de objetos baseada na tangvel hardware no sistema. Eu no tenho espao para incluir todos os objetos do sistema aqui, mas

Eu mostrei cinco classes de objetos na figura 7.6. O termmetro de solo, Anemmetro, e Barmetro objetos so objetos de domnio de aplicao, ea EstaoMeteorolgica e WeatherData objectos terem sido identificado a partir do sistema descrio eo cenrio (caso de uso) Descrio: 1. A classe de objeto EstaoMeteorolgica fornece a interface bsica do tempo estao com o seu ambiente. Suas operaes refletem as interaes mostradas na Figura 7.3. Neste caso, eu uso uma nica classe de objeto para encapsular todos estes interaes, mas em outros projetos que voc poderia projetar a interface do sistema como vrios diferentes classes. 2. A classe de objeto WeatherData responsvel por processar o clima relatrio de comando. Ele envia os dados resumidos dos instrumentos Estao Meteorolgica o sistema de informaes meteorolgicas. 3. O termmetro terra, anemmetro, e classes de objetos Barmetro so directamente relacionada com instrumentos no sistema. Eles refletem hardware tangvel entidades do sistema e as operaes esto preocupados com o controle que hardware. Esses objetos operar de forma autnoma para coletar dados no especificada frequncia e armazenar os dados recolhidos no local. Estes dados so entregues ao Objeto WeatherData a pedido.