Capítulo 7 – Projeto e implementação
7.1 Projeto orientado a objetos com UML
7.3 Questões de implementação 7.4 Desenvolvimento open source
Cont
eúdo
Projeto e implementação
Objetivos
Os objetivos deste capítulo são apresentar o projeto de software orientado a objetos usando a UML e destacar os interesses importantes de implementação. Com a leitura deste capítulo, você:
t compreenderá as atividades mais importantes em um processo geral de projeto orientado a objetos;
t compreenderá alguns dos diferentes modelos que podem ser usados para documentar um projeto orientado a objetos; t conhecerá a ideia de padrões de projeto e como eles são uma
forma de reusar conhecimento e experiência de projeto;
t terá sido apresentado a questões fundamentais que precisam ser consideradas na implementação do software, incluindo o reúso de software e desenvolvimento open source.
O
projeto e implementação de software é um estágio do processo no qual um sistema de software executável é desenvolvido. Para alguns sistemas simples, o projeto e implementação de software é a engenharia de sof- tware, e todas as outras atividades são intercaladas com esse processo. No entanto, para grandes sistemas, o projeto e implementação de software é apenas parte de um conjunto de processos (engenharia de requisitos, verificação e validação etc.) envolvidos na engenharia de software.As atividades de projeto e implementação de software são invariavelmente intercaladas. O projeto de software é uma atividade criativa em que você identifica os componentes de software e seus relacionamentos com base nos requisitos do cliente. A implementação é o processo de concretização do projeto como um programa. Às vezes, existe um estágio de projeto separado e esse projeto é modelado e documentado. Em outras ocasiões, um projeto está ‘na cabeça’ do progra- mador ou esboçado em um quadro ou em papel. Um projeto trata de como resolver um problema, por isso, sempre existe um processo de projeto. No entanto, nem sempre é necessário ou apropriado descrever o projeto em detalhes usando a UML ou outra linguagem de descrição.
O projeto e a implementação estão intimamente ligados e, ao elaborar um projeto, você deve levar em consideração os problemas de implementação. Por exemplo, usar a UML para documentar um projeto pode ser a coisa certa a fazer se você estiver programando em uma linguagem orientada a objetos como Java ou C#. Mas é menos útil, penso eu, se você estiver desenvolvendo em uma linguagem com tipagem dinâmica como Python, e não faz sentido se você estiver imple-
125
Capítulo 7 Projeto e implementação
mentando seu sistema, configurando um pacote de prateleira. Como discutido no Capítulo 3, os métodos ágeis normal- mente funcionam a partir de esboços informais do projeto e deixam muitas decisões para os programadores.
Uma das decisões de implementação mais importantes que precisa ser tomada em um estágio inicial de um projeto de software é se você deve ou não comprar ou construir o software de aplicação. Atualmente, é possível comprar sistemas de prateleira (COTS, do inglês commercial off-the-shelf ) em uma ampla variedade de domínios. Os sistemas podem ser adaptados e ajustados aos requisitos dos usuários. Por exemplo, se você quiser implementar um sistema de prontuário médico, você pode comprar um pacote que já seja usado em hospitais. Essa abordagem pode ser mais barata e rápida do que desenvolver um sistema em uma linguagem de programação convencional.
Quando você desenvolve uma aplicação dessa forma, o processo de projeto preocupa-se em ‘como’ usar os recursos de configuração desse sistema para cumprir os requisitos do sistema. Usualmente, você não desenvolve modelos de pro- jeto do sistema, como modelos de objetos do sistema e suas interações. No Capítulo 16 discuto essa abordagem para o desenvolvimento baseado em COTS.
Presumo que a maioria dos leitores deste livro já tem experiência em projeto e implementação de programas. Isso é algo que você adquire quando aprende a programar e dominar os elementos de uma linguagem de programação como Java ou Python. Você provavelmente já aprendeu as boas práticas da programação nas linguagens de programação que estudou, bem como a forma de depurar os programas que desenvolveu. Portanto, não tratarei dos tópicos de programa- ção aqui. Em vez disso, este capítulo tem dois objetivos:
1. Mostrar como a modelagem de sistema e o projeto de arquitetura (tratados nos capítulos 5 e 6) são colocados em
prática no desenvolvimento de um projeto de software orientado a objetos.
2. Apresentar questões importantes de implementação que geralmente não são discutidas em livros de programa-
ção. Estas incluem o reúso de software, o gerenciamento de configuração e o desenvolvimento open source. Como existe um grande número de plataformas de desenvolvimento diferentes, este capítulo não é voltado para uma linguagem de programação ou tecnologia de implementação específica. Portanto, apresento todos os exemplos usando a UML em vez de uma linguagem de programação como Java ou Python.
7.1 Projeto orientado a objetos com UML
Um sistema orientado a objetos é composto de objetos interativos que mantêm seu próprio estado local e ofe- recem operações nesse estado. A representação do estado é privada e não pode ser acessada diretamente, de fora do objeto. Processos de projeto orientado a objetos envolvem projetar as classes de objetos e os relacionamentos entre essas classes. Essas classes definem os objetos no sistema e suas interações. Quando o projeto é concebido como um programa em execução, os objetos são criados dinamicamente a partir dessas definições de classe.
Sistemas orientados a objetos são mais fáceis de mudar do que os sistemas desenvolvidos com abordagens funcionais. Os objetos incluem os dados e as operações para manipulá-los. Portanto, eles podem ser entendidos e modificados como entidades autônomas. Alterar a implementação de um objeto ou adicionar serviços não deve afetar outros objetos do sistema. Como os objetos são associados com coisas, muitas vezes existe um mapeamen- to claro entre entidades do mundo real (como componentes de hardware) e seus objetos de controle no sistema, o que melhora a inteligibilidade e, portanto, a manuteniblidade do projeto.
Para desenvolver um projeto de um sistema desde o conceito até o projeto detalhado orientado a objeto, existem várias atitudes que você precisa tomar:
1. Compreender e definir o contexto e as interações externas com o sistema. 2. Projetar a arquitetura do sistema.
3. Identificar os principais objetos do sistema. 4. Desenvolver modelos de projeto.
5. Especificar interfaces.
Como todas as atividades criativas, o projeto não é um processo sequencial claro. Você desenvolve um projeto tendo ideias, propondo soluções e refinando essas soluções assim que as informações ficam disponíveis. Quando os problemas surgem, inevitavelmente você tem de voltar atrás e tentar novamente. Às vezes, você explora as opções detalhadamente para ver se elas funcionam; em outros momentos, você ignora os detalhes até o fim do processo, porque isso implicaria a possibilidade de o projeto ser pensado como uma sequência de atividades. Na verdade, todas essas atividades são intercaladas e, assim, influenciam-se mutuamente.
126 Engenharia de software
Essas atividades de processo mencionadas são ilustradas com o projeto de parte do software para a estação meteorológica no deserto que apresentei no Capítulo 1. As estações meteorológicas no deserto são implantadas em áreas remotas. Cada estação meteorológica registra informações meteorológicas locais e periodicamente as transfere para um sistema geral de informações por meio de um link de satélite.
7.1.1 Contexto e interações do sistema
O primeiro estágio de qualquer processo de projeto de software é o desenvolvimento de uma compreensão dos relacionamentos entre o software que está sendo projetado e seu ambiente externo. Isso é essencial para de- cidir como oferecer a funcionalidade requerida para o sistema e como estruturar o sistema para se comunicar com seu ambiente. A compreensão do contexto também permite estabelecer os limites do sistema.
Definir os limites do sistema ajuda a decidir quais recursos serão implementados no sistema que está sendo projetado e quais recursos estão em outros sistemas associados. Nesse caso, você precisa decidir como a funcio- nalidade é distribuída entre o sistema de controle para todas as estações meteorológicas e o software embutido na estação meteorológica em si.
Modelos de contexto do sistema e modelos de interação apresentam visões complementares dos relaciona- mentos entre um sistema e seu ambiente:
1. Um modelo de contexto do sistema é um modelo estrutural, que demonstra os outros sistemas no ambiente
do sistema a ser desenvolvido.
2. Um modelo de interação é um modelo dinâmico que mostra como o sistema interage com seu ambiente
quando ativo.
O modelo de contexto de um sistema pode ser representado por associações. Estas simplesmente mostram que existem alguns relacionamentos entre as entidades envolvidas na associação. Nesse momento, a natureza dos relacionamentos é especificada. Portanto, você pode documentar o ambiente do sistema com um diagrama de blocos simples, mostrando as entidades do sistema e de suas associações. Essa situação é ilustrada na Figura 7.1, que mostra que os sistemas no ambiente de cada estação meteorológica são um sistema de informações meteorológicas, um sistema de satélites a bordo e um sistema de controle. As informações de cardinalidade sobre o link mostram que há um sistema de controle com várias estações meteorológicas, um satélite e um sistema de informações climáticas gerais.
Quando você modela as interações de um sistema com seu ambiente, deve usar uma abordagem abstrata sem muitos detalhes. Uma maneira de fazer isso é usar um modelo de caso de uso. Como discutido nos capítulos 4 e 5, cada caso de uso representa uma interação com o sistema. Cada interação possível é nomeada em uma elipse, e a entidade externa envolvida na interação é representada por um boneco palito.
O modelo de caso de uso para a estação meteorológica está na Figura 7.2. Este mostra que a estação meteo- rológica interage com o sistema de informações meteorológicas para relatar dados meteorológicos e o status do hardware da estação. Outras interações são com um sistema de controle que pode emitir comandos específicos de uma estação do tempo. Como expliquei no Capítulo 5, um boneco palito é usado na UML para representar outros sistemas, bem como usuários humanos.
Cada um desses casos de uso deve ser descrito em linguagem natural estruturada. Isso ajuda os projetistas a identificarem objetos no sistema e oferece uma compreensão do que o sistema se destina a fazer. Eu uso um
Figura 7.1 Sistema de contexto para estação meteorológica
Sistema de informações meteorológicas Estação meteorológica Satellite Sistema de controle Satélite 1 1 1 1 1 1 1 1..n 1..n 1..n Sommerville_Cap_07.indd 126 31/05/2011 15:08:14
127
Capítulo 7 Projeto e implementação
formato-padrão para essa descrição, o qual identifica claramente as informações que são trocadas, como a intera- ção é iniciada, e assim por diante. Isso é mostrado no Quadro 7.1, que descreve o caso de uso ‘Relatar clima’ a partir da Figura 7.2. Exemplos de alguns outros casos de uso estão disponíveis na Internet.
7.1.2 Projeto de arquitetura
Uma vez definidas as interações entre o sistema de software e o ambiente do sistema, você pode usar essa informação como base para projetar a arquitetura do sistema. Certamente, você precisa combinar essa informação com seu conhecimento geral dos princípios de projeto de arquitetura e com conhecimentos mais detalhados so- bre o domínio. Você identifica os principais componentes do sistema e suas interações e, então, pode organizar os componentes usando um padrão de arquitetura, como um modelo em camadas ou cliente-servidor. No entanto, nesse estágio, isso não é essencial.
O projeto de arquitetura em alto nível para o software da estação meteorológica é mostrado na Figura 7.3. A estação meteorológica é composta de subsistemas independentes que se comunicam pela transmissão de men- sagens em uma infraestrutura comum, apresentada na Figura 7.3 como ‘Link de comunicação’. Cada subsistema escuta as mensagens sobre essa infraestrutura e pega as mensagens destinadas a eles. Esse é outro estilo de arqui- tetura comumente usado, além dos estilos já descritos no Capítulo 6.
Figura 7.2 Casos de uso da estação meteorológica
Desligar Relatar clima Reiniciar Relatar status Reconfigurar Sistema de informações meteorológicas Sistema de controle Economizar energia Controlar remoto
Quadro 7.1 Descrição de caso de uso – Relatar clima
Caso de uso: Relatar clima
Atores: Sistema de informações meteorológicas, estação meteorológica
Dados: A estação meteorológica envia um resumo dos dados meteorológicos coletados a partir dos instrumentos, no período de coleta, para o sistema de informações meteorológicas. Os dados enviados são o máximo, mínimo e médio das temperaturas de solo e de ar; a máxima, mínima e média da pressão do ar; a velocidade máxima, mínima e média do vento; a precipitação de chuva total e a direção do vento, amostrados a cada cinco minutos.
Estímulo: O sistema de informações meteorológicas estabelece um link de comunicação via satélite com a estação e solicita a transmissão dos dados.
Resposta: Os dados resumidos são enviados para o sistema de informações meteorológicas.
Comentários: Geralmente, solicita-se que as estações meteorológicas enviem relatórios a cada hora, mas essa frequência pode diferir de uma estação para a outra e pode ser modificada no futuro.
128 Engenharia de software
Por exemplo, quando o subsistema de comunicações recebe um comando de controle, como o desligamento, o comando é capturado por cada um dos outros subsistemas, que se desligam de maneira correta. A principal vantagem dessa arquitetura é que é fácil suportar diferentes configurações de subsistemas, pois o remetente de uma mensagem não precisa endereçar a mensagem a um subsistema específico.
A Figura 7.4 mostra a arquitetura do subsistema de coleta de dados, incluída na Figura 7.3. Os objetos ‘Transmis- sor’ e ‘Receptor’ estão preocupados com o gerenciamento das comunicações, e o objeto ‘Dados meteorológicos’ encapsula a informação capturada a partir dos instrumentos e transmitida ao sistema de informações meteoroló- gicas. Essa organização segue o modelo produtor-consumidor discutido no Capítulo 20.
7.1.3 Identificação dos objetos de classe
Nesse estágio do processo, você deve ter algumas ideias sobre os objetos essenciais para o sistema que está projetando. Enquanto sua compreensão do projeto se desenvolve, você refina suas ideias sobre os objetos do sis- tema. A descrição do caso de uso ajuda a identificar objetos e operações no sistema. A partir da descrição do caso de uso ‘Relatar clima’, é óbvio que os objetos que representam os instrumentos que coletam dados meteorológicos serão necessários, assim como um objeto representando o resumo desses dados. Geralmente, você também pre- cisa de um objeto do sistema de alto nível ou objetos que sintetizem as interações do sistema definidas nos casos de uso. Com esses objetos em mente, você pode começar a identificar as classes de objeto no sistema.
Foram feitas várias propostas sobre como identificar as classes de objetos em sistemas orientados a objetos:
1. Usar uma análise gramatical de uma descrição em linguagem natural do sistema a ser construído. Objetos e
atributos são substantivos, operações ou serviços são verbos (ABBOTT, 1983).
2. Usar entidades tangíveis (coisas) no domínio de aplicação, como aviões; papéis, como gerente ou médico; even-
tos, como pedidos; interações, como reuniões; locais, como escritórios; unidades organizacionais, como empresas, e assim por diante (COAD e YOURDON, 1990; SHLAER e MELLOR, 1988; WIRFS-BROCK et al., 1990).
3. Usar uma análise baseada em cenários, na qual diversos cenários de uso do sistema são identificados e analisa-
dos separadamente. À medida que cada cenário é analisado, a equipe responsável pela análise deve identificar os objetos necessários, atributos e operações (BECK e CUNNINGHAM, 1989).
Figura 7.3 Arquitetura de alto nível da estação meteorológica
«Subsistema» Coleta de dados «Subsistema» Comunicações «Subsistema» Gerenciador de configuração «Subsistema» Gerenciador de defeitos «Subsistema» Gerenciador de energia «Subsistema» Instrumentos Link de comunicação
Figura 7.4 Arquitetura do sistema de coleta de dados
Coleta de dados
Transmissor Receptor DadosMeteo-
-rológicos
129
Capítulo 7 Projeto e implementação
Na prática, você precisa usar diversas fontes de conhecimento para descobrir as classes de objetos. As classes de objetos, atributos e operações, inicialmente identificados a partir da descrição informal do sistema, podem ser um ponto de partida para o projeto. A partir do conhecimento do domínio de aplicação ou da análise de cenário, mais informações podem ser usadas para refinar e estender os objetos iniciais. Essa informação pode ser coletada a partir de documentos de requisitos, conversas com usuários, ou a partir de análises dos sistemas existentes.
Na estação meteorológica no deserto, a identificação de objetos é baseada no hardware tangível no sistema. Eu não tenho espaço para incluir todos os objetos do sistema aqui, mas na Figura 7.5 mostro cinco classes de objetos. Os objetos ‘Termômetro de chão’, ‘Anemômetro’ e ‘Barômetro’ são objetos de domínio de aplicação, e os objetos ‘EstaçãoMeteorológica’ e ‘DadosMeteorológicos’ foram identificados a partir da descrição de sistema e da descrição de cenário (caso de uso):
1. A classe de objeto EstaçãoMeteorológica fornece a interface básica da estação meteorológica com seu am-
biente. Suas operações refletem as interações mostradas no Quadro 7.1. Nesse caso, eu uso uma classe única de objeto para encapsular todas essas interações, mas em outros projetos você poderia projetar a interface do sistema como várias classes diferentes.
2. A classe de objeto DadosMeteorológicos é responsável por processar o comando ‘Relatar clima’. Este envia os
dados resumidos dos instrumentos da estação meteorológica para o sistema de informações meteorológicas.
3. As classes de objeto Termômetro de chão, Anemômetro e Barômetro estão diretamente relacionadas com os
instrumentos do sistema. Estes refletem as entidades tangíveis de hardware no sistema, e as operações estão inte- ressadas em controlar o hardware. Esses objetos funcionam de forma autônoma para coletar dados na frequência especificada e armazenam os dados coletados localmente. Quando requisitados, esses dados são entregues ao objeto DadosMeteorológicos.
Você usa o conhecimento do domínio da aplicação para identificar outros objetos, atributos e serviços. Sabe- mos que, muitas vezes, as estações meteorológicas estão em lugares remotos e incluem diversos instrumentos que, eventualmente, falham. Falhas do instrumento devem ser comunicadas automaticamente. Isso significa que você precisa de atributos e operações para verificar o correto funcionamento dos instrumentos. Existem muitas estações meteorológicas remotas, e cada uma deve ter seu próprio identificador.
Nesse estágio do processo de projeto, você deve concentrar-se nos próprios objetos, sem pensar em como eles podem ser implementados. Depois de identificar os objetos, você deve refinar o projeto do objeto. Você observa as características comuns e, em seguida, projeta a hierarquia de herança para o sistema. Por exemplo, você pode identificar uma superclasse ‘Instrumento’, que define as características comuns de todos os instrumentos, assim como um identificador, e obter operações e testar. Você também pode adicionar novos atributos e operações à superclasse, tal como um atributo que mantenha a frequência da coleta de dados.
Figura 7.5 Objetos da estação meteorológica
Identificador relatarClima( ) relatarStatus( ) economizarEnergia (instrumentos) controlarRemoto (comandos) reconfigurar(comandos) reiniciar (instrumentos) desligar (instrumentos) EstaçãoMeteorológica temperaturaAr temperaturaChão velocidadeVento direçãoVento pressão precipitaçãoChuva coletar ( ) resumir ( ) DadosMeteorológicos Anemômetro obter ( ) testar ( ) an_Ident velocidadeVento direçãoVento Barômetro obter ( ) testar ( ) bar_Ident pressão altura Termômetro de chão obter( ) testar( ) get_Ident temperatura Sommerville_Cap_07.indd 129 31/05/2011 15:08:16
130 Engenharia de software
7.1.4 Modelos de projeto
Modelos de projeto ou de sistema, como discuti no Capítulo 5, mostram os objetos ou classes de objetos em um sistema. Eles também mostram as associações e relacionamentos entre essas entidades. Esses modelos são a ponte entre os requisitos do sistema e a implementação de um sistema. Eles precisam ser abstratos, para que os detalhes desnecessários não escondam os relacionamentos entre eles e os requisitos do sistema. No entanto, tam- bém devem incluir detalhes suficientes para que os programadores possam tomar decisões de implementação.
Geralmente, você contorna esse tipo de conflito desenvolvendo modelos em diferentes níveis de detalhe. Sempre que houver links estreitos entre os engenheiros de requisitos, projetistas e programadores, os modelos abstratos podem ser tudo o que é necessário. Decisões específicas de projeto podem ser feitas enquanto o sistema é implementado, com