Tài liệu ..... pdf

O Visual Basic pode ser usado para criar sistemas baseados na Web, acoplaco a tecnologias como Microsoft Transaction Server, Active Server Pages, e Structured Query Language.. Talvez a r

Dusenvorvenvo APLICATIVOS com VISUAL BASIC

PAUL R REED, JR

Projeto e Implementacao de

Aplicativos Orientados a Objeto

ESENVOLVENDO APLICATITVOS com

POSE Uy Này” “4z Hy ee EA i “gee we N

Paul R Reed, Jr

Traducao: Mario Moro Fecchio

Reøisao: José Davi Furlan e Mario Magyar Franco

Autor đo livro “Modelagem de Microsoft Certified System Objetos através da UML” Engineer, Microsoft Certified

da Makron Books Trainer

_ MAKRON Books do Brasil Editora Ltda

Rua Tabapua, 1.348, Itaim-Bibi

CEP 04533-004 — Sao Paulo — SP

(0xx11) 3849-8604 e (0xx11) 3845-6622

e-mail: makron@books.com.br

Sao Paulo s Rio de Janetro © Ribeirao Preto « Belém © Belo Horizonte * Brasilia ¢ Campo Grande

* Cuiabd * Curitiba © Florianopolis ¢ Fortaleza « Goiénia « Manaus ¢ Porto Alegre © Recife « Salvador

Barcelona ¢ Bogota e Buenos Aires * Caracas ¢ Ciudad de México * Frankfurt ¢ Guadalajara

® Lisboa « London ¢ Madrid * Montevideo « New York « Paris * Porto * Santiago

Do original: Developing Applications with Visual Basic and UML Desenvolvendo Aplicativos com Visual Basic e UML

Copyright © 2000 by Addison-Wesley Longman, Inc

Copyright © 2000 MAKRON Books do Brasil Editora Ltda

Todos os direitos para a lingua portuguesa reservados pela MAKRON Books do Brasil Editora Ltda Nenhuma parte desta publicagao podera ser reproduzida, guardada pelo sistema “retrieval” ou transmitida de qualquer modo ou por qualquer outro meio, seja este eletrdnico, mecanico, de fotocdépia, de gravacgao, ou outros, sem prévia

autorizagao, por escrito, da Editora

EDITOR: MILTON MIRA DE ASSUMPCAO FILHO

Sandra Cristina Pedri

Editoracão Eletrônica: ERJ Informatica Ltda

Dados Internacionais de Catalogagao

Desenvolvendo Aplicativos com Visual Basic e UML

Tradugao: Mario Moro Fecchio; Revisao

Técnica: José Davi Furlan

e Mario Magyar Franco

ISBN: 85.346.1198-X

MAKRON

Books

————— Prologo

por Grady Booch

A primeira vista, vocé pode dizer, “Mas 0 Visual Basic nao é orientado a objeto!” Bem para ser realmente exato, o Visual Basic é uma linguagem de programacão ba- seada em objeto, ndo uma linguagem de programagao orientada a objeto (O Visual Basic nao tem a verdadeira heranca, como aquela encontrada em C++ e Java.) Dito isto, Os principios orientados a objeto da abstragao, encapsulamento, e ocultamento

de informag6es se aplicam diretamente ao Visual Basic Além disso, 4 medida que vocé passa para sistemas de escala, aplicam-se também os principios de arquitetura

da separacão de interesses e a đistribuicão equilibrada de responsabilidades É aqui que entra o livro de Paul Ele lhe mostra os principios, processos e pragmaticas do uso do Visual Basic para desenvolver e disponibilizar sistemas de qualidade usando conceitos orientados a objeto

O Visual Basic, na forma como ele existe hoje, esta muito distante do desenvol-

vimento Basic original no colégio Dartmouth na década de 60 Quando ainda estava

na Microsoft, Alan Cooper, considerado o pai do Visual Basic, desenvolveu um pro- grama chamado Ruby, um protétipo que demonstrava uma metdfora para o desen- volvimento do Visual Basic Por volta de 1989, o Ruby foi anexado a um produto chamado QuickBasic, formando assim a primeira versao do Visual Basic Desde en- tao, o Visual Basic vem crescento enormemente O Visual Basic pode ser usado para criar sistemas baseados na Web, acoplaco a tecnologias como Microsoft Transaction Server, Active Server Pages, e Structured Query Language Sem duvida, segundo muitas opinides, o Visual Basic é a linguagem de programacão mais utilizada no

mundo, ultrapassando o número de desenvolvedores que usa COBOL, C++, e Java

Talvez a razao de ele estar em todo o lugar seja por que o Visual Basic (e seu parente,

o VBScript) freqiientemente é usado como o adesivo para juntar sistemas heterogé- neos criados com base nas tecnologias Microsoft

No entanto, um dos desafios na criacao de sistemas usando 0 Visual Basic é que

é muito facil criar coisas simples rapidamente Isso é ao mesmo tempo bom (especial- mente na presenga de cronogramas de desenvolvimento rapido) e ruim (a medida que o sistema inicial cresce baseado em seus primeiros sucessos, ele rapidamente atinge um ponto em que se torna fragil e dificil de mudar, de maneira que acaba en- trando em colapso sob seu prdprio peso) O desenvolvimento de sistemas Visual Ba- sic usando principios orientados a objeto diminui esse risco de falha Além disso, o

V

VỊ Desenvolvendo Aplicativos com Visual Basic e UML

uso da Unified Modeling Language lhe permite desenvolver planos de acão detalha- dos para o sistema que reconcilia os pontos de vista de diferentes patrocinadores e o ajudam a guiar o projeto a medida que ele cresce com 0 tempo

Neste livro, Paul he mostrará como aplicar 0 Visual Basic em um contexto orientado a objeto, usando a Unified Modeling Language como linguagem para os planos de acao detalhados de um sistema Ele lhe mostra como aplicar os principios

đa abstracão, encapsulamento, e ocultamento de informacões para o Visual Basic e como arquitetar sistemas de escala O que eu gosto particularmente no livro de Paul

é seu pragmatismo Ele nao s6 esclarece esses principios, como também lhe mostra como criar sistemas executaveis usando tecnologias como o Microsoft Transaction

Server, Active Server Pages, e Structured Query Language

Grady Booch

Chief Scientist

Rational Software Corporation

MAKRON

Books

— ——~ Prologo

por Francesco Balena

Nao faz muito tempo, muitos programadores consideravam 0 Visual Basic como uma

“linguagem de brinquedo” ou, no melhor caso, como uma “linguagem adesiva”, que servia apenas para juntar diferentes tecnologias, como os controles ActiveX, Data Ac- cess Objects, e Component Object Model

Para ser honesto, as primeiras versões do Visual Basic provavelmente mereciam esse tratamento O Visual Basic V1 nao era sequer capaz de lidar com bancos de da- dos, e o Visual Basic V2 s6 podia fazé-lo por meio das fungdes API Open Database Connectivity (ODBC), que nao eram exatamente a maneira mais simples de acessar dados O Visual Basic V3 acrescentou alguns recursos limitados de banco de dados, mas eles nao foram suficientes para tornd-lo um ambiente robusto para projetos em nivel de empresa

Isso mudou quando a Microsoft entrou na arena cliente/servidor com a versao

do Visual Basic v4, um produto competitivo e poderoso capaz de criar aplicativos N- tier completos Os programadores Visual Basic podiam nao sé desenvolver compo- nentes Component Object Model, como também podiam experimentar o Remote

Automation, o precursor do Distributed COM, e distribuir seus executaveis pela rede

Fazer computag¢ao distribuida nunca foi tao facil Desde entao, o Visual Basic conti- nuou sua evolucao em ritmo acelerado: o Visual Basic v5 incluia um compilador e a capacidade de criar controles ActiveX e varias caracteristicas Internet, e o Visual Basic v6 acrescentou um melhor suporte para Active Data Objects, Internet Information Server, e Dynamic HTML Combine tudo isso com outros produtos como SQL Server

7, Microsoft Transaction Server, e Microsoft Message Queue e vocé percebera que pode criar aplicativos poderosos com o Visual Basic

No entanto, minha impressao, baseado em meus semindrios e trabalhos de con-

sultoria na Europa e nos Estados Unidos e nas opinides dos leitores de meus artigos

e livros, 6 que muitos ainda usam a linguagem principalmente como uma ferramenta Rapid Application Development (RAD) A suposigao (incorreta) é que é a interface de usuario que torna bem-sucedido um aplicativo Embora essa atitude seja adequada para pequenos utilitarios e poderia as vezes ser tolerada para aplicativos de bancos

de dados simples e de tamanho médio, ela é simplesmente inaceitavel para sistemas

cliente /servidor maiores Contudo, muitos projetos comerciais ambiciosos sao inicia-

dos sem uma fase séria de projeto, documentagao preliminar, estimativa de riscos,

Vil

VHI Desenvolvendo Aplicativos com Visual Basic e UML

classe e modelagem, e todas as etapas que deveriam ser executadas antes que sequer uma linha de cédigo fosse escrita Nao deve surpreender ninguém o fato de que mui- tos projetos nao atendem aos seus objetivos e produzem aplicativos que nao execu- tam adequadamente ou que sao dificeis de manter e extender

E aqui que entra o livro Desenvolvendo Aplicativos com Visual Basic e UML Ha muitas razões pelas quais eu realmente gosto desse livro, e estou muito feliz por ter

a oportunidade de escrever 0 prélogo para ele Uma razao é que, embora haja muitos livros sobre Unified Modeling Language e andlise e desenho orientado a objeto, este

é um dos poucos que trata daqueles tópicos do ponto đe vista dos programadores Vi- sual Basic de uma maneira convincente Paul tem uma grande experiéncia em ambos

os campos e pode portanto ser um mediador eficaz entre os puritanos da programa- cão orientada a objeto e os aficcionados do Visual Basic Como prova disso, leia no Capitulo 2 a andlise mais inteligente sobre os recursos de orientacão a objeto do Vi- sual Basic

Em vez de oferecer um guia de referéncia para toda a Unified Modeling Lan- guage, Paul correta e inteligentemente decidiu focalizar as caracteristicas que sao in- dispensaveis para criar excelentes aplicativos Visual Basic N-tier Ao mesmo tempo, ele proporciona informagoées suficientes, bem como uma bibliografia precisa, sobre aquilo que ele nao discute exaustivamente, assim os leitores mais curiosos sabem onde encontrar um refinamento para suas especialidades

Estou certo de que todos os programadores Visual Basic apreciardo a aborda- gem pratica que esta nessas paginas Foi muito bom conhecer um forma de combinar

teoria com tecnologias como ActiveX, Active Data Objects, Internet Information Ser- ver, Component Object Model, e a Distributed Internet Architecture A discussdo am-

pla das varias técnicas para conduzir dados entre aplicativos Windows é um excelente exemplo do compromisso que as vezes deve ser assumido passando-se da teoria pura para a pratica da vida real De forma semelhante, a descrigao sobre como escrever codigo que funciona com e sem o Microsoft Transaction Server demonstra o quanto o autor se preocupa com os detalhes pequenos mas essenciais que contribuem grandemente para o sucesso de um aplicativo

Deixe-me concluir com um pequeno conselho Não passe rapidamente de uma capa a outra, e fique longe do editor de codigo Visual Basic por algum tempo Leia

tudo com muito cuidado, digerindo as varias nogdes oferecidas em cada capitulo, e

aproveite o seu tempo para construir as suas classes e bancos de dados, usando uma ferramenta de modelagem, se possível Só então você perceberá que a Unified Mode- ling Language combinada com uma fase de desenho bem pensada pode lhe econo-

mizar dias, semanas, e até mesmo meses em projetos maiores

Francesco Balena

www.vb2themax.com

Editor-in-Chief, Visual Basic Journal, Italia

Editor Contribuinte, Visual Basic Programmer’s Journal

Autor, Programming Microsoft Visual Basic 6 (Microsoft Press)

MAKRON

Books

Prefacio

Por que Ler Este Livro?

Muitos projetos de software empreendidos nos dias de hoje nao chegam a atingir seus objetivos originais ou suas datas estimadas de conclusao Meus argumentos para isso S40 que a maioria das equipes de projeto não tem sequer uma nogao sobre o que

é um processo de desenvolvimento ou como personalizar um para as caracteristicas proprias do projeto Além disso, muitos projetos sao deficientes na andlise e nos ar- tefatos de projeto para mostrar como chegaram onde estao Ou seja, tradicionalmente falta rastreabilidade aos projetos

Dito isto, a maioria dos autores de livros sobre VB nunca fazem uma considera-

cão ampla Em vez disso, eles focalizam mal, enchendo as paginas com lindas rotinas para carregar caixas de lista e podem chamar fungdes API Windows Embora essa vi- s4o também seja necessaria, infelizmente parece que ninguém chega sequer a tocar no planejamento de projeto, processo de software, e na metodologia para criar aplicati- vos VB com status comercial Isto ocorre por que se trata do tdpico mais dificil de ex- plorar e apresentar

Este livro focaliza a abordagem mais poderosa disponivel hoje para modelar e criar aplicativos em nivel industrial: a Unified Modeling Language (UML) adotada

em 1997 pelo Object Management Group (OMG) como padrao para modelagem de aplicativos baseadas em objeto Com a UML, e um bom ciclo de vida de desenvolvi- mento (que eu apresento como 0 processo Synergy nesse livro), os projetos VB podem

se aproximar mais do sucesso previsivel, ao contrario das alteragdes menos deseja- veis, do tipo que depende da sorte Além disso, embora 0 foco desse livro esteja no

VB, quase todos os conceitos apresentados podem ser aplicados a qualquer lingua- gem de programacao (C++, Java) quando acoplado com a UML

X Desenvolvendo Aplicativos com Visual Basic e UML

a DB2, da IBM, coisa que muitos de vocés hoje chamam de “aplicativos antigos” No entanto, eu prefiro chamar de sistemas “de heranga” ou “sénior” em vez de “anti- gos” Eu nao s6 aprendi a trabalhar com algumas excelentes ferramentas e com pes- soas superbrilhantes, como também aprendi o valor do planejamento do projeto e a estabelecer uma clara arquitetura e desenho do aplicativo desejado Eu vi essa recom- pensa em grande estilo na forma de um processo bem estabelecido e com uma clara comunicacao para a equipe de projeto Mais importante ainda, proporcionou-me os degraus para completar um projeto bem-sucedido

Em 1990, eu trabalhei em um aplicativo cliente/servidor de primeira geracao

usando Smalltalk na plataforma OS/2 Esse foi o inicio de uma nova carreira para mim, e eu fiquei chocado com o “processo” usado para criar 0 aplicativo de “produ-

¢ao” no ambiente cliente /servidor O planejamento era indiferente, como era também

o fornecimento de artefatos de andlise e desenho (algo que mostrava por que criamos aquilo que criamos)

Esse padrao de desenvolvimento de software do tipo “shooting from the hip” continuou com meu uso do PowerBilder e mais tarde o VB As aplicagdes produzidas com esses produtos funcionavam, mas eram frageis Creio que nos dias de hoje, mui- tos aplicativos que ưsam o rótulo de “cliente/servidor” sao aplicativos tao antiqua- dos quanto alguns de seus correspondentes mainframe, se nao mais Pior ainda, eles

se tornaram aplicativos antiquados um ou dois meses apos terem sido produzidos A

falha não estava na ferramenta, mas sim, na falta de um bom modelo e metodologia

de processo que garantisse a producão daquilo que os usuarios realmente queriam, e que aquilo que foi projetado nao se desfizesse na primeira vez em que fosse modifi- cado

Lentamente eu comecei a aplicar minhas próprias opiniões sobre processo e me- todologia, aos aplicativos criados no ambiente cliente /servidor Isso funcionou muito

bem Os aplicativos eram mais resilientes e aceitavam alteragdes mais facilmente, e os

usuarios tipicamente sorriam quando o projeto era completado

Esse livro combina toda a minha experiéncia na criacgao de aplicativos clien- te/servidor com a UML, que eu acho que é o melhor repositério de artefatos para do- cumentar a andlise e design de um aplicativo nos dias de hoje Eu espero que vocé goste de ler esse livro tanto quanto eu gostei de escrevé-lo

Quem Deve Ler Esse Livro

Esse livro se destina a todos aqueles que querem ter sucesso na cria¢ao de aplicativos

VB que possam resistir ao tempo Ele proporciona um roteiro preciso para todos que querem atingir os seguintes objetivos:

e Estabelecer um bom plano de projeto (apresentado em detalhes no Apêndice E)

® Estimar projetos com confianca, e não com a abordagem hit-and-miss (apre- sentada em detalhes no Apéndice A)

e Entender e descrever os requisitos do aplicativo usando os modelos supor- tados pela UML

® Usar uma ferramenta de modelagem visual como a Rational Rose da Ratio-

nal Software, ou o Visual Modeler da Microsoft, nado somente para criar e

rastrear artefatos UML, mas também para gerar esqueletos para o cddigo componente (Nota: o Visual Modeler é um subconjunto do Rational Rose

oferecido pela Microsoft Com excecão da criacão de modelos dinâmicos, o

Visual Modeler pode ser usado em vez da Rational Rose neste livro.)

e Usar eficazmente as mais recentes tecnologias Microsoft, como o Distributed Component Object Model (DCOM), Microsoft Transaction Server (MTS) e a Internet por meio do Active Server Pages (ASP), VBScript, e JavaScript Qualquer um que esteja criando aplicativos VB hoje precisa desse livro

O Que Vocé Precisa Saber Para Usar Esse Livro

Talvez seja melhor comecar com aquilo que vocé nao precisa saber para se beneficiar deste livro

Primeiro, vocé nao precisa conhecer coisa alguma sobre a UML Eu apresento os aspectos essenciais da UML, e 0 que é mais importante, como eles se relacionam com

os produtos VB Embora a UML esteja expressa com nove diagramas separados, vocé

se beneficiará mais com um core set

Segundo, vocé nao precisa ter um conhecimento basico formal sobre conceitos

de orientagao a objeto Eu discuto as construcões de objetos padrão no texto e revejo muitos deles no Apéndice C

Terceiro, vocé nao precisa conhecer COM ou DCOM Eu uso ambos extensiva- mente em todo o livro e discuto alguns dos problemas de “plumbing” envolvidos no Apéndice D

Finalmente, vocé nao precisa de um entendimento formal das principais tecno- logias que envolvem o MTS e a World Wide Web (Web) Cada um desses tdpicos re-

cebe tratamento detalhado neste livro

Este livro supGe que vocé tenha um conhecimento pratico do VB Tanto o pro- gramador novato quanto o experiente serdo beneficiados No entanto, eu não poderia

discutir os fundamentos basicos de simples construgdes VB, assumindo que isso vocé

ja conhece Se vocé ainda n&o teve contato com o VB, compre este livro mesmo assim

e abra-o apos ter tido algum treinamento inicial naquela linguagem de programacao

XII Desenvolvendo Aplicativos com Visual Basic e UML

Este livro também sup6e que vocé tenha experiéncia com a Structured Query Language (SQL) e bancos de dados relacionais Alguns conhecimentos de Active Data Objetct (ADO) e Open Database Connectivity (ODBC) também ajudarao O projeto usado como modelo nesse livro usa ADO exclusivamente com drivers ODBC

Estrutura do Livro

A seguir esta um resumo dos capitulos e conteúdo

Capitulo 1: O Dilema do Projeto

Esse capitulo revé o estado atual do desenvolvimento de software e minhas opiniões sobre por que esta na forma em que esta hoje Revé também o conceito de desenvol- vimento de software interativo e incremental e fornece uma visdo geral da minha me- todologia Synergy usada como guia neste livro Apresento também os componentes primários da UML que serão discutidos em mais detalhes mais adiante no livro Capitulo 2: Visual Basic, Orientagao a Objeto, e UML

Esse capitulo discute alguns dos beneficios que resultam da adogao do VB como um ambiente de desenvolvimento Ele os apresenta no contexto da implementacão do en- capsulamento, heranga, e polimorfismo do VB Em seguida, mapeia a UML para va- rios produtos VB Os destaques incluem mapeamento da classe UML para médulos

de classe VB; mapeamento de caminhos de casos de uso para a entidade VB; tipos de classes interface e controladora; e mapeamento de diagramas de componente para executaveis e DLLs VB e opcionalmente para MTS

Capitulo 3: Iniciando o Projeto

Esse capitulo explora o estudo de caso usado no livro, a Remulak Productions Essa empresa ficticia vende equipamento musical e precisa de um novo sistema de entrada

de pedidos O capitulo introduz um planejamento de projeto, juntamente com uma ferramenta chamada de tabela de eventos, para ajudar a solidificar rapidamente as ca- racteristicas do aplicativo Além disso, o capitulo mapeia eventos para o primeiro mo- delo UML, o caso de uso

Capitulo 4: Casos de Uso

Esse capitulo revé o caso de uso, um dos principais diagramas UML Ha incluido um modelo para documentar o caso de uso Sao definidos os atores e suas funcdes no caso de uso O capitulo revé 0 conceito de caminhos de caso de uso, bem como ar- quitetura de implementacao preliminar do projeto E apresentada também uma abor- dagem para estimar projetos que sao criados usando a abordagem caso de uso

Prefacio XIII

Capitulo 5: Classes

Esse capitulo explora o diagrama de classe UML, o principal dentre os diagramas UML Ele oferece dicas para identificar boas selegdes de classes e define os varios ti- pos de associag6es Ele também discute a caracterizacao das regras comerciais e como essas regras podem ser traduzidas em operacoes e atributos da classe Finalmente, ele

điscute a utilizacão da ferramenta de modelagem visual, Rational Rose, como um

meio de melhor gerenciar todos os artefatos UML

Capitulo 6: Criando um Primeiro Protétipo

Esse capitulo examina requisitos de interface de usuario de cada caso de uso Ele de- senvolve um primeiro fluxo protótipo e um eventual prototipo grafico Finalmente, ele mapeia o que foi aprendido durante o protótipo para os artefatos UML

Capitulo 7: Os Elementos Dinamicos do Aplicativo

Esse capitulo discute os modelos dinamicos suportados pela UML, explorando em detalhes os dois principais diagramas, geralmente chamados de diagramas de intera- cão, sequência e colaboracão Esses são então ligados diretamente aos caminhos en- contrados nos usos đe casos Outros diagramas dinâmicos discutidos incluem os điagramas de estado e đe atividade

Capítulo 8: Horizonte TecnológIco

Este capitulo descreve a importancia de se separar servicos l6gicos que sejam concor- dantes com DNS Ele explora as solugdes de tecnologia especificas para o estudo de caso da Remulak Productions, incluindo solugdes distribuidas com DCOM, MTS, e a Internet usando formuldrios HTML e ASP Duas linguagens de script sao usadas para

a parte Internet dos aplicativos, VBScript e JavaScript

Capitulo 9: Persisténcia de Dados: Armazenando os Objetos

Este capitulo explora os passos necessarios para trasformar o diagrama de classe em

um desenho relacional para ser suportado pelos bancos de dados Microsoft SQL Ser- ver e Oracle Ele oferece sugestdes de regras praticas referentes a como lidar com he- ranca de classe e as possiveis alternativas de desenho resultantes ao transformar o diagrama de classe em um RDBMS Ele também explora 0 suporte do VB as classes data-aware, bem como a importancia de uma camada separada de Servicos de Trans- formacao de Dados contendo ldégica SQL relacionada com cada classe

Capitulo 10: Aplicando a Infra-estrutura

Esse capitulo finaliza o desenho necessdrio para implementar as varias camadas da aplicagao Ele também apresenta o mecanismo de comunicagao utilizado entre cama- das e as alternativas possiveis Cada classe é delegada a um dos trés tipos: entidade,

XIV Desenvolvendo Aplicativos com Visual Basic e UML

interface, ou controle Estes sao usados como base para a implementagao de desenho

e como solug¢ao para proporcionar estratégias alternativas de disponibilizacão

Capitulo 11: Gerando Codigo a Partir do Diagrama de Classe UML (Parte 1)

Esse capitulo explora os problemas da geracao de cédigo VB diretamente a partir do diagrama de classe, novamente usando Rational Rose Ele apresenta as etapas de se- tup necessdrias para que o processo funcione bem e discute a importancia do proces-

so inteiro da reengenharia, juntamente com um processo para garantir que ele ocorra

Capitulo 12: Gerando Codigo a Partir do Diagrama de Classe UML (Parte 2)

Esse capitulo preenche o corpo da classe VB gerada no capitulo anterior, focalizando

um único caminho ao longo de um caso de uso Ele também apresenta todo o cdédigo necessario para transforma-lo em realidade, da interface do usuario até o fim

Capitulo 13: Criando uma Implementacao Distribuida: DCOM e MTS

Esse capitulo usa as solucdes criadas nos Capitulos 12 e 13 para explorar as etapas necessárias para disponibilizá-las em várias configuracões đe servidor Ele điscute to- das as tarefas necessárias para garantir uma implementacão DCOM bem-sucedida, incluindo o uso đo assistente de disponibilizacão e o uso de vários utilitários para ga- rantir que tanto o cliente quanto o servidor estejam corretamente configurados

Capftulo 14: Interfaces Alternativas: a Internet

Esse capitulo discute uma das dreas mais quentes de hoje: a Internet E aqui que todo

o trabalho de desenho discutido nos capitulos anteriores realmente produz seus efei- tos compensadores No capitulo, é criado um front-end baseado em HTML para a funcão de consulta de entrada de pedido ASP é usado como interface entre o brow- ser e as camadas do aplicativo VB O capitulo explora o VBScript como linguagem primdria de scripting no servidor Web e o JavaScript conforme é usado no browser

O Visual InterDev da Microsoft é usado como ferramenta de desenvolvimento para essa parte do projeto

Atualizacoes e Informacoes

Eu tenho a grande sorte de trabalhar com grandes empresas e organizagGes nao sé

nos Estados Unidos, como também na Europa, Asia, e América do Sul Em minhas

viagens, estou sempre tendo novas idéias sobre como usar e aplicar a UML para criar aplicativos mais resilientes que usem nao apenas o VB mas também C++ e Java Por favor, visitem meu site Web em www.jacksonreed.com, onde vocé pode obter tudo que

ha de mais novo em servicos de treinamento e consultoria que eu ofereco, bem como todo o cédigo-fonte apresentado neste livro Seus comentarios sao bem-vindos e vocé pode me contatar em prreed@jacksonreed.com

Eu gostaria de agradecer a Coby Sparks, Dale McElroy, Richard Dagit, Mike Ri- chardson, John Peiffer, Kurt Herman, Steve Symonds, Dave Remy, David Neustadt,

Selena Wilson, John Girt, Robert Folie, Terry Lelievre, Bill Carson, Larry Deniston,

Jeff Kluth (é 0 Jeffery Homes do livro, um excelente tocador de guitarra, e proprieta-

rio da verdadeira Remulak, uma firma de consultoria DB2) Agradecimentos também

a Ellen Gottesdiener da EBG Consulting (www.ebgconsulting.com) por sua maravilhosa assisténcia em planejamentos de projeto, casos de uso, e regras comerciais

Eu tenho o grande privilégio de trabalhar com grandes clientes, tanto nos Esta-

dos Unidos quanto no exterior Um agradecimento especial vai para Rick Cassidy e Kevin Boettcher da Lockheed-Martin’s Advanced Concepts Center (AAC) por me proporcionar ocasionalmente interessantes atribuig6es orientadas a objeto Eu gosta- ria também de agradecer ao pessoal da Manatron, Inc (www.manatron.com) cujos grandes esforcos me proporcionaram muitas idéias sobre como usar o Visual Basic (VB) em uma maneira comercial Em particular, na Manatron, quero agradecer a Lar-

ry Deniston, John Gumpper, Mark Murphy, Dilawar Jaulikar, e Gina Riggs Gostaria também de agradecer a Vicki Cerda da Florida Power and Light, Jones Wu e Daniel

Yee da Pacific Gas and Electric, Daryl Kulak da CBSI, Inc., todos os meus amigos da

Ford Motor Company, Mansoor Osmani na IIT House (Arabia Saudita), Lawrence Lim da LK Solutions (Singapura, Malasia, e Emirados Arabes — www.lks.com.my), Tony Shaw da Technology Transfer Institute (USA), Jeremy Hall da Technology Transfer Institute, LTD (Londres), e Ricardo Quintero da Panama Canal Commission Minhas consideracões especiais vao para minha esposa, Jeanette, que abriu mao

de sua bem-sucedida carreira como programadora de sistemas MVS/DB2 e Oracle

DBA para cuidar de nossos bens mais preciosos, Micaela e Connor Também foi Jea-

nette, juntamente com meu grande amigo Mike Richardson, que em 1992 me encara- ram e me perguntaram, “Por que vocé esta trabalhando para os outros?” Isso levou

& criacao da Rackson-Reed, Inc., e nunca mais voltamos atrás

Quero deixar meu agradecimento especial ao meu amigo Steve Jackson Steve é

o “Consultor Emérito” da Jackson-Reed, Inc (www.jacksonreed.com) Ele, juntamente com seu sécio Bryan Foertsch, fundou a bem-sucedida empresa de aquisig¢6es Omni

XV

XVI Desenvolvendo Aplicativos com Visual Basic e UML

International (www.omninow.com) em 1998 Steve me deu duas ligdes muito importan- tes que eu nunca vou esquecer A primeira foi como “fazer 0 negécio” A segunda, foi que a coisa mais importante é sempre se certificar de que quando alguém sai da empresa seu sorriso seja sempre maior do que quando chegou

Por ultimo, agradecimentos especiais a J Carter Shanklin da Addison-Wesley por ter a visao de dispensar uma séria condieragao a um td6pico VB/ UML Agradeci- mentos a Krysia Bebick por me mostrar os caminhos da editoragao e a Kristin Erick- son pelo apoio continuo que ela me proporcionou e aos revisores deste livro Um grande agradecimento também a Diane Freed da Diane Freed Publishing Services, Inc., que me poupou de ficar louco durante o processo de producao deste livro E um agradecimento especial ao meu agente, Margo Maley da Waterside Productions, que aplainou o meu caminho

Agora, os verdadeiros herdis deste projeto sao os revisores que trabalharam os meus primeiros rascunhos e faziam suas criticas quando necessdrio S40 eles Larry

Deniston, Diretor da Software Research and Development, Manatron, Inc.; Jim Conal-

len, Rational Software,Inc.; Matt A Arnold, Intelligent Algorithms Enterprises, Ltd.; Gary Cernosek; John Moody; e Steve Nordmeyer Finalmente, meu muito obrigado a Francesco Balena por alguns ajustes técnicos de ultima hora

MAKRON

Books

Sumario

OBJETIVOS 2 ee eee nen ene tenn eee een n ees 1

O Dilema do ProjetO eee cee eees 2 Desenvolvimento de Software Interativo e Incremental 2 Desenvolvimento Baseado em RiscO Ặ Q eens 4

O Modelo de Processo de Software Interativo 0 eee eens 5 Combinando Interativo com Incremental: Visdo Multidimensional 7

O Modelo do Processo SynergV_ co cee ence ees 8 Vendendo a Idéia de um Processo de Software para a Empresa 9 The Unified Modeling Language_ 10

A DML e seu Lugar no Processo de SoÍtware 10

A Essência da Modelagem Q.0 na 11

Os Diagramas UML, 12

The Unified Modeling Language e a Visualizacão da Arquitetura “4+1” 13 Usando os Diagramas em Contexto UML 14

0i 0 ee eee eee eee eee en eee eee en ee eee eee 15

Onde Chegamos_ nhu nu va 15 Para Onde Vamos a SeØUlr QQQ Q HQ HH ke 16

2 V¡isual Bastc, Ortentacao a ObJeto, e LŨML 17 OBJETIVOS Q.0 LG Q Q n ng HH HH ng HH kg ky kh KH k ki ki và 17

O Visual Basic como uma Ferramenta de Desenvolvimento de Forca Industrial 17 Visual Basic e o Conceito de Orlentacão a OblJefo_ 19

Visual Basic e CÏasses ẶQ QQQ Q HQ Q HH HH HH kh kà 20

Visual Basic e Tipos Complexos co 23

XVIII Desenvolvendo Aplicativos com Visual Basice UML

Visual Basic e Passagem de Mensagem_ 23 Visual Basic e Encapsulamento 24 Visual Basic e Heranca QQQQQ Q QQ n ng nu rà 26 Visual Basic e Heranca de Interface 29

A Alternativa Visual Basic para a Heranca de Implementacão 31 Visual Basic e Polimorfismo 2Q Du 31 Por que ML e Visual Basic? 33 Diagrama de CÏlasse 34 Diagrama de Seqlência QQQQQQQ nu 36 Diagrama de Componenfe Q Ốc 36 Diagrama de Implementacão_ 36 Suporte à Ferramenta de Modelagem Visual_ 37

ĐC CO IOuùơơơ7ơ7—ơ7—aA.qggẶ.ốềốềốầốầốốốốốốeeeốewéeéeeeénứn 37 Onde Chegamos_ Ốc cu 37 Para Onde Vamos a Seguir 37

))19400 (0 39 Estabelecendo o Planejamento do Projeto 40

O Modelo de ProcessO QQQQQQQ nnn nhu va 40 Modelo Prático do Planejamento do Projeto 40 0V 9 g4 ete eee eneenenes 43 Lista de Eventos e Tabela de Eventos 44 Planejamento do Projeto: Interacão Ủm 48 Interacão Um Completa QQQQQ QQQ nu 48 T€SƯMNO Q0 QQ Q QQ Q ng HH HH HH nh ng nu HT gà tv Hi Kà và k vn tuy 48 Onde Chegamos_ Q.2 48 Para Onde Vamos a Seguir 49

OBJETIVOS Q.0 cen cece nen eee nee tteeeeenenas 51

O Exemplo de Projeto 0.0 icc cc ccc cnet cette eneeveennennes 52

O Modelo de Processo_ 2Q nu 52 Casos de SO Q.0 Q ng ng ng ng n HH ng nu kg vn ky v 52 Procurando os Caminhos por meio dos Casos đe Uso_ 58 Procurando o Happy Path QQQ nu vu 59 Procurando os Alternate Pathways QQQQ cu 59

Sumario XIX

Localizando os Exception Pathways 06 sees cece eens 60

Casos đe Uso Mascarados (Shadow)_ nh he 61

Detalhando o Happy Path_ - {nhe 63 Caso de Uso para Processamento Completo de Pedidos 64 Preparando a Arquitetura Preliminar 0 cess eee eee eee een ees 65 Planejamento do Projeto: Incrementos e Estimativas - 67 INCrEMENtOS 6 ee eee eee ee erent e teen neta 67 EstimativaS 2.0.0 cece cece ee ee eee ee ene een ete ene teenies 67

Ñ€SUmO non HH non HH n nh HH ĐH Hy ki ky kg gà ki ki hi ko 69

Onde Chegamos_ S2 nh nh nh ng 69 Para Onde Vamos a Seguir ch ke 70

CÏASS€S Ặ QC HQ HH HH HE HH HH kh kh ko Hà ko ki Kha 71

OBJETIVOS_ HQ HH HQ nh HH nh HH nh Hy Hy ko nh hư và Z1 Fase de Elaboracão Q Qn Q nn n n n HH HH nh kh sa 72 Detalhando os Caminhos HH Xa 73 Identificando e Classificando Business Rules - 73 Descobrindo as CÏasses - SH ng nho 75 Interacão 1: Papel do Diagrama de Classe UML - 5

O Que Torna Boa uma CÏasse? .cŸẶŸ Z6

Aplicando Regras đe Filragem_ nhe nở 77 Tipos de Classes n2 HH n HH nh nh nh ki ở hàn nà hi nở 78 Classes Entidade_ - TQ Q nh hà ha 80 Classes ÏnterfaCe -c Q eee HH HH n HE HH nh kg kh ko k và 81 Classes ContrOole SH HH HH HH HH nh kh nha 81 RelacionamentOS ẶcQ nQ n Q n n n n n ng HH nh Hi kh HH hi va 82 Estabelecendo AssOciaCÕ@S c0 QQ Q n n HH nh HH nh hư sa 83 Estabelecendo os Papéếis nh nh nh nh kớ 84 Estabelecendo Multiplicidade_ ỂSSSc 85 Associacões Avancadas_ nh HH nh nhà 8ó Associacões de Agregacão e CompOSICãO ào no 86

Associacões de Ligacão (classe e de assoclacão) co 88

Associacões Reflexivas HH nh nh nh nh HH hà 88 Associacões de Qualificacão che 89

Generalizacão On HH ng nh hàn kh hà 89

Criando o Diagrama de CÏasse_ Ăn nh ha 90 Identificando Atributos e QperaCÕ€§ ch nh nhe non ke 92

XX Desenvolvendo Aplicativos com Visual Basic e UML

AtributOs 2.0 ccc cence eter tere n ten teneeneeus 92

OperagOes 6 vị rđdẦAẠẢẦA 93

Diagrama ObjetO 2.0.0 ccc nen tenet ete e tense ene eneeney 94 Encerrando: Ô Modelo de Análise 95

€SU.O cee tence tenner tented te nt eneenbentenney 96 Onde Chegamos_ Q.0 96

Para Onde Vamos a Seguir cu 96 6 Criando um Primeiro ProlÓHpO c co 99 OBJETIVOS 2.0 ence enn e nee n teen tenet e en eenenes 99 Criando um Primeiro ProtótipO_ c cu 100 O PrototipO 2.6 cence nee nee eee teen eee eenes 100 Reunindo os RequisitOS cu 101 Protótipo de Interface de Usuário TH ng ng tk kia 101 Fronteiras para Ator e Caso de so_ 102

Artefatos da Interface de Usuário 103

Acoplamento de Caso de so c 104

Interacão Ứm .QQQ Q Q0 Q Q ng ng ng ngu kh v và và v2 106 Graficos de Estrutura de Tela 106

Criando o Protốtipo_ c eet e nee e ence eeanes 108 Coletando Informacões do Usudrio Usando Didlogos de Tela 119

Aprendendo com 0 ProtÓtipO cv cv 119 RESUMO 2 ce nen cent e eee tenn e bbe e nee eeey 126 Onde Chegamos 00 c cece cece tence estes e ee eeeeeenees 126 Para Onde Vamos a Seguir 126

7 Os Elementos Dindmicos do AplicaHuo 129

OBJETIVOS Q.0 Q Q QQ Q ng ng HH ented een teense eee eens 129 O Próximo Passo da Fase đe Elaboracão 129

Modelagem Dinâmica_ 130

Tipos de Modelos Dinâmicos_ 131

O Diagrama de Seqiiéncia 2 cc center teen tenes 133 Diagrama de Seqiência do Happy Path 134

Diagrama de Seqiência para um Caminho Alternativo 141

Transferindo Conhecimento para o Diagrama de Classe_ 141

Percorrendo o Diagrama đe Seqiência 144

O Diagrama de Colaboracão 144

Sumáro XXI

O Diagrama de Estado_ -.ẶQQ QQQ HQ HH HQ HH HH nà ko 146 Modelando o Diagrama de Estado da Classe Pedido đa

Remulak Productions Ặ 147 Forma Alternativa đe Ver os Diagramas de Estado 149

O Diagrama de Atividade_ QQQ 150 Selecionando o Diagrama CertO_ teen ees 151 Extensões Não-UML no Desenho: Matrizes de Utilizacão 152

A Matriz Evento/FrequÊncia Q.Q 152

A Matriz ObJeto/Localizacão ke 154

A Matriz Objeto/Volume QQQ QQ Q nnnnn n he 155 R€SUMmO Q0 Q Q ng HH HH HH HH HH tt HH ky kh kh kh vn ki và 157 Onde Chegamos_ Q0 e eee e ees 157 Para Onde Vamos a Seguir 157

OBJETIVOS Q.0 QQ Q Q0 Q HH HH HH nh HH ky kh vk Kà 159 Prĩximo Passo da Fase de Elaboracão 160 S5eparando Se€rVICOS_ ng ng HH HH HH Ho Hy kh ke 161 Enfileiramento Lĩgico versus Físico 163 Estratégia de Enfileiramento da Microsoft 165 Comunicacão Entre as Seis Camadas_ 165

Arquitetura de Comunicacão Entre rocessos 1ĩ6

Arquitetura de Comunicacão de Camadas_ 167 Por Dentro da Comunicacão CƠM Ặ cu 167 Cinco ©Opcões Sobre em Que Basear uma Arquitetura de Infra-estrutura 169 Gerenciando o Escopo đe Transacão dentro do Aplicativo e do Microsoft

Transaction SerV€T Q0 n n n n n HH HH nh ki ki hy a 171 Incorporando a Internet na Solucão Ốc 174 Arquitetura Executiva da Remulak Productions 176 S0 eee eee eee een e teen ene ee nen nes 176 Onde Chegamos_ Tra aA ees 176 Para Onde Vamos a Segulr c2 178

Persistêncin de Lados: Artmmazenando ÓJelos 179

OBJETIVOS QQQQQ QQ0Q Q0 Q Q Q HQ ng HH HH ng ky ky kh ky ky k km 179

Fase de ConstrUuCãO - LH Q HQ HH HH HH no HE Hà ky kh kà v và 180

Conceitos Orientados a Objeto e sua Transformacão em Desenho Físico 180

XXII Desenvolvendo Aplicativos com Visual Basic e UML

Mapeando Classes para Tabelas 182 Mapeando Associacöes Simples nà 183 Mapeando Heranga para o Banco de Dados Relacional 187 Mapeando Agregacão e Composicão para o Banco de Dados Relacional 189 Mapeando Associa¢gées Reflexivas para o Banco de Dados Relacional 190 Estruturas de Chave (Key) e Normalizacão 191 Usando uma Ferramenta de Modelagem Visual para Gerar Data Definition

Language ee eee ee nee nee e eee e eee tebe eet teen bette 193 Aperfeicoando a Ferramenta de Modelagem Visual 196 Stored procedures e Triggers e 0 Projeto Orientado a Objeto_ 201 Suporte Visual Basic de Classes Data-AwWare c 202

As Camadas dos Servicos de Transformacão de Dados e Servicos de Acesso

Fs DD: o (¢)- Q Q ng HH HH HH ng kh kh Hi kh kh k ha 202

` nh ÝưnNỚndiiiiidiii 206 Onde Cheøgamos_ 2Q HH nhở 206 Para Onde Vamos a Seguir co ca 207

OBJEIIVOS L0 Q0 Q HH HH HH HH HH HH HH kh Hi ko kh va 209 Fase de ConstrUCão nQ Q Q Q n ng HH HH Hy nu kh hà và 210 [TrOC€SSO SVHN€TĐV .QQ QQ ee cee ee HH HH nh n Hi nh hà va 210 Problemas Componente-Infra-estrutura e Comunicacão com Todas

as Camadas_ Q QQ Q 0Q Q Q Q n n n HH n HH HH HH HH y và 210 Explorando a Camada Servicos de Apresentacão em Nível de

CompOonenfe c c n Q eee ee eee eee eee renee 212 Explorando a Camada Servicgos de Contexto de Negocio em Nivel de

Componente 00.6 ccc eee teen t een e eee en ennes 215 Explorando a Camada Servicgos de Regras de Negocio em Nivel de

Componente 0 eee ee ene e ene b bene beens 216

Classes em Cooperacgao em Nivel de Componente: Interface, Controle e

Entidade 1.2 cece ccc eee cece ne eee eee teen een e ees 217 Comunicagao Componente-Camada 218 Implantacão da Infra-estrutura em Nível de Componente 220 Revisitando o Diagrama de Classe UML para Refinar as Assinaturas de |

oa (er (0 Q Q Q Q Q HQ HH HH HH HH ni ky ko k ky ky ky 221 l€SUmO - Q.0 Q Q0 Q Q Q Q Q HH HQ HH HH kg ng KH kg Hy k ki kà 224 Onde Chegamos_ 0Q Q nh nu xa 224 Para Onde Vamos a Seguir 224

11

Sumario XXIII

Gerando Codigo a Partir do Diagrama de Classe UML (Parte 1) 225

OBJETIVOS 0 cence eee HH HH HH kh kh hà hà hà 225 Fase de ConsfrUCcão c e eee teen e teen e teen eee 226

¡v90 và 4¡1223-3/NadiiiiiadaiiiẳiẳiẳiẳiỒẦỒẦdẢẢ 226 Modelagem Visual — A Missão da Ferramenta de Modelagem Visual no

que se Refere ao ProjetO hs 227 Modelagem Visual — A Missão da Ferramenta de Modelagem Visual no

que se Refere à Geracão de Cĩdigo de Programa_ 228 Revisão dos Problemas de Setup na Preparacão para Gerar o Cĩdigo do

ÏrOgrama_ eee enn eee eee Ee Ee ees 228 Modificando os Parâmetros de Geracão de Cĩdigo 230 Atribuindo Classes aos Componenfes 231 Gerando Nosso Primeiro Cĩdigo a partir da Ferramenta de Modelagem

ViSUẠ Q0 Q Q Q Q Q Q Q n n HH HH HH nh HH ngà nà Hi ko kh kh ko vi hà 232 Gerando o Cĩdigo Restante a partir da Ferramenta de Modelagem

Visual — Servicos đe Traducão de Dados 233 Gerando o Cĩdigo Restante por meio da Ferramenta de Modelagem

Visual — Servicos de Regras de Negĩclo 235 Gerando o Cĩdigo Restante por meio da Ferramenta de Modelagem

Visual — Servicos de ApresentacãO co 237 Itens de Revisão a Observar apĩs a Geracão estar Completa_ 237 Explore como Fazer a Engenharia Reversa do Cĩdigo de Programa de

Volta para o Diagrama de Modelagem Visual 237 Acrescentando Cédigo para Realizar um Caminho de Caso de Uso 241 Explore o Cédigo Necessdario Que Deve Ser Acrescentado para Suportar uma Simples Transagdo do Início ao Fim_ cà 241 Camada Servico de Acesso a Dados: Componente DASVC 241 Conectando à Fonte de Dados e Executando uma Select Query 241 Fechando a Conexão com a Fonte de Dados 245 Conectando à Data Source e Executando uma Query Insert, Update ou

P02 ằnắốắẮaa4 HH Had 246 Camada Servicos de Traducão de Dados: Componente DTSVC 250 Criando a SQL para Ser Executada pela Camada Servicos de Acesso a

Dados 0Q Q0 Q0 Q n HH HH HH HH HH Hà nu kh km k tk tk na 250 Camada Servicos de Regras c de Negĩcio: Componente BRSVC 254 Criando as Regras que Controlam o Processamento 254 Camada Servicos de Apresentacão: Componente UISVC 258

O Que o Dsuário Vê: Ligando a Interface de Usuário à Camada Servicos

de Regras de Negĩcio ẶQ nh 258

XXIV Desenvolvendo Aplicativos com Visual Basic e UML

12

13

Blocos Bõsicos para o FutUrO cv 262 [@SUMmO LG Q Q Q Q Q Q HH HH HH HH HH ki ki ki vỏ ky xỏ 262 Onde Chegamos_ co 262 Para Onde Vamos a Seguir 263

Gerando Cờdigo a Partir do Diagrama de Classe UML (Parte 2) 265

OBJETIVOS 2.0 ccc ener n ne HH nh HH HH tk ky vỏ 265 Fase de ConstrUuCọO -cQQQQ Q Q eee e ng HH HQ xa 266 Aperfeicoando a Consulta de Cliente e Introduzindo a Nocọo dos Objetos Superficiais e Expandidos 266 Mudangas de Cờdigo para a Consulta de Relacionamento de Cliente 268 Alteracửðes do Cờdigo para Suportar Objetos em Expansọo 269 Facilitando a Vida para a Interface de Usuario: Tipos Definidos pelo

USUaTIO 6 cere een eee HH HH nu kh va 275 Ter ou Nao Ter Objetos no Lado Cliente 285 Uma Tendờncia Perturbadora com o Advento das Implementađờes

Distribuẻdas_ QQQ HQ Q Q HH HH kh xa 286 Atualizando Informacửes da Interface de Usuõrio para o Servidor

(Back-End)_ Q0 Q HQ HH nhu nu va 287 Persistindo os ObjetOs QQQ QQ QQ Q n n HH nh hỏ ha 296 ICSD 0 Q Q Q Q n n HH HH HH HH ng Hỏ Hỏ ky vn 300 Onde Chegamos_ QQQQQ nu 300 Para Onde Vamos a Seguir 300

Criando uma Implementagao Distribuida: DCOM e MTS 301

OBJETIVOS 2.0 ccc cence ence ene nh nhỏ nu ky 301

Fase de Construcọo QC QQ Q Q Q ng HQ ng n n n na 301

PrOCessO SVN€TBYV .Q HQ HH HH HH HH HH nh vn vo 301 Construcọo — Aplicativos Distribuợdos: Nirvana ou Devastacọo? 302 Construcọo — Estratờgia đe Distribuicọo da Remulak Productions

Tempo de Retorno do Investimento 303 Solucửes Remotas — Modelo de Objeto de Componente Distribufdo_ 305 Construcọo — Preparando os Componentes para Distribuicọo DCOM 305 Construcọo — Distribuindo os Componentes Servidor 308 Construcọo — Instalando os Componentes no Servidor 313 Construcọo — Aprontando o Cliente para Testar a Instalacọo DCOM 317 Construcọo — Criando um Pacote đe Instalacọo Cliente 320 Solucửes Remotas — Microsoft Transaction Server 323

Sumario XXV

Construcão — Chegando à Interface - 324 Construcão — Tipos de Transacão nhe 326 Construcão — Tipos de Transacão da Remulak Productions_ 327 Construcão — Administragao MTS ccc cee eee eee ees 328 Construcao — Modificando a Remulak para Usar Gerenciamento de

Transacões MĨTS HH nh nh kh nh ha 336 Construcão — Apoiando o Direito de Voto cccenn no 339 Construcão — Mudancas Remulak: Compromisso - 340 MTS — 19 Round de Alteracões -.Ặ on 341 MTS — 29 Round de Alteracðes - . -c ca 344 MTS — 3° Round de Alteracões ằằẶằ 347 Construcão — Gerenciamento de Transacão - 349

Ñ€SUmO Kon on non HH HH Ho Ho nh By By km to Hi Ki Ki hi tà 350

Onde Chegamos_ - nh nh nh nh ke 350 Para Onde Vamos em Seguida -. {c{Ÿ 351

14 Interfaces Alternativas: a IHÍ€YH€E he 353 OBJETIVOS ẶQQQ Q Q Q Q Q n HH nh HH nh Hà nen enenees 353 Fase de ConstrucÃo_ TQ nh nh nh nh he nh kở 353

xe s22 0œ 353

O Papel da Web nọ HH n nh HH nh khe hư nà 354 Tecnologias Web_ cà nh nh nh nh nh hà 355 Reconfiguracão de Componenfte che 356 Criando os Componentes Web nh ng 357 Formulário HTML de Consulta de Pedidos -.- 358

Xà >a/¬0 1 ằ ằeằeeốẽẮeẮ ene e eens 361

Um Cliente Mais Dinâmico com JavaScript - 366 COutras Possibilidades {ST nhà 368

RÑesumO c Q Q Q Q Q non HH HH HH hon HH th k R Kon ki Ki vn Kha 369

Onde Chegamos - nh nh nh nhớ 369

Apéndice A — Estimando Projetos Usando Casos de Uso . 371

AtOTES 20 eee ớớẶ tenet nee ene 371

Casos de USO_ SH HH HH nh Ho Hy kh nh Hi kh kh sở 373

Fatores TẾCniCOS - co HH non HH Hi Ho HH hi K hà 374

Participantes do ProjetO ch nh nh nhe nh nh hờ 375

XXYVI_ Desenvolvendo Aplicativos com Visual Basic e UML

Pontos de Casos de so ¬ eee eee eee eens 376

A Estimativa do ProjetO Qua 377

Apéndice B — Acrescentando Funcionalidade Adicional aos Recursos da

Lineuaseem de Defimcao de Dados RaHonal Rose 379

Aperfeicoamentos — Atributos Persistentes e Transientes 379 Modificando o Rational Rose — Configuracão do Atributo Persistente 380 Modificando o Rational Rose — Rodando o Script de Definigéo 383 Modificando 0 Rational Rose — Mudando o Script para Reconhecer o

AtriDut0 20 eee nee nee teen n nee e eee e ne eaas 384 Outras Áreas de Alteracão - Ốc 2 387

Apêndice C — LĨĩma CarHlha da Orientacão a oÙJefl0 389

O Que Significa Orientado a Objeto? 2.0 ccc eee eee ees 389 Orientacao a Objeto — Esta Bem La no Seu Quintal 389 Subprodutos da Orientacão a Objeto_ 390

Heranca_ Q.0 QQ Q Qn Q ene tenn et ene ky vở 390

EncapsulamenfO c2 HH HH HH nh ha xa 391 PolimorflsmO eee eee e eee n n KH ko ok vn 392 Não é Facil ¬_ eee ne bene eben teen en aas 392

Apêndice D — Cơmponent ObJect Model e COM+ 393

COM — O Canal Q.0 HH nu 393 COM — InfÍra-estrutura cv 394

O COM em Servicd 0 .aaadẦAẠ 396 Visual Basic — Compatibilidade de Versão 397 Nenhuma Compatibilidade - 398 Compatibilidade de Projeto 1 cece erect eet eeeenee 399 Compatibilidade Binária 399 69)0/) DU NHHgg( ốm 400

Apéndice E — Plano de Projeto Orientado a Objefo 403

OPlano Q Q Q Q HQ Q n Q HH HH HH HH ng k ve 404

Apéndice F — Resultados do Exemplo de um Projetfo 411

Caso de Uso — Detalhes de Caso de Uso para o Incremento1 411 Caso de so — Etapas de Tarefa de Happy Path 419

Sumario XXVII

Processar Pedidos (O cliente liga e pede uma guitarra e acess6rios e paga

com cartão de crếditO) SH HH na 420 Manter Pedidos (O cliente liga para perguntar sobre a situacão de um

pedido) HQ Q Q n n HH HH HH HH ng HH HH hn và 420 Manter Inventário (O produto chega no armazém com uma cópia da

ordem đe pagamento anexada) "¬ cee ee eee eee 421 Expedicao (Um pedido inteiro é enviado do estoque disponivel para

O CÏÏẨTf©) cece cece ee eee ene ee een tenn een e ee neee 421 Faturamento (Um pedido é faturado e enviado ao cliente indicando

pagamento efetuado por cartão de crédito) 421 Manter Relacionamentos (O cliente liga para mudar seu endereco) 421 Suporte à Decisão (O gerente solicita um relatério de pedidos pendentes) 422 Suporte ao Banco de Dados co e eens 422

Microsoft SQL Server v7.Ũ c cQ Q Q HH HH HH kh va 422

Data Definition Language para Oracle (v7.3,2) 426

6.) nHt''=iaiầaẳẳẳẮẮẢẮẢ nes 431 Capítulo 4_ Q Q Q HH HH HH HH HH HH HH HH ng HH nh ki hà 431 Capitulo 5 HQ HQ HQ ng ng HH nh HH Hà Hi nh vo 432 Capitulo ô ôẺ ga äẼ sẽ = 432 Capitulo 8_ ẶQQ Q ng ng nh nh HH HH ha 432 Capítulo l1 CĐ ng HH ng nh ke 432 Capitulo 13 TQ Q ng HH HH HH ng HH Hà ky và 432 Apêndice À -QQQ Q Q Q Q HH HH HH nh nh nh HH sa 432

MAKRON

Books

capitucot O Dilema do Projeto

]á vi mais projetos que perderam seus objetivos iniciais do que aqueles que os atingiram Isto acontece por que muitas equipes de projeto nao tinham a minima idéia do que era um processo

de desenvolvimento, ou como personalizar um processo para as caracteristicas especiais de um projeto Isso também se deve ao fato de que a maioria dos projetos tinha pouca relagao com o modo de andlise e os artiftcios de desenho para mostrar como chegaram até la Para o empreen- dimento como um todo faltava a habilidade de ser rastreado, ou seja, faltava a rastreabilidade Esse capitulo lanca os fundamentos para um processo de software chamado Synergy O processo Synergy se baseia na minha extensiva andlise, desenho, e experiéncia de construcao, criando aplicativos cliente/servidor, bem como muitos aplicativos baseados em computacao centralizada Ele usa a The Unified Modeling Language (UML), como seu artefato pioneiro primário Esse processo, juntamente com a UML, pode assegurar que o seu proximo projeto Visual Basic (VB) terd os recursos necessdrios para vencer E o mais importante, esses projetos passarao no teste do tempo Eles terão a habilidade de se adaptar tanto aos negocios subjacentes que suportam, como também a estrutura tecnoldgica sob a qual foram criados Eles não serao declarados como aplicativos antigos antes mesmo de atingirem o ponto de produgao

% Examinar o dilema enfrentado pelos projetos

% Explorar a natureza de um processo de desenvolvimento de software inte-

rativo, incremental e baseado em riscos

© Familiarizar-se com o modelo de processo de software usado neste livro, chamado Synergy

<= Examinar como a equipe de projeto pode vender o uso do processo Synergy para os patrocinadores do projeto

<= Examinar a UML e seus artefatos e como ela serve como ferramenta de mo-

delagem primária para o processo Synergy

2 Desenvolvendo Aplicativos com Visual Basice UML Cap 1

O Dilema do Projeto

Sao poucos Os projetos que transcorrem conforme o planejado Muitos comegam com grande entusiasmo mas geralmente terminam em uma corrida desenfreada para con- seguir produzir alguma coisa O resultado freqientemente é prejudicado por impre- cisOes Ou, pior ainda, provoca respostas inenarraveis dos patrocinadores do projeto

A Figura 1.1 mostra uma comparacdo tempo/esforco de gastos em homem-hora para muitos projetos que nao atingem seus objetivos

FIGURA 1.1 —_Linha do tempo com aumento exponencial em horas

e acrescentando funcionalidade até que, quase chegando ao fim, vocé percebe que

“nao vamos conseguir” Vocé esta distante demais da meta e comega a acrescentar mais recursos ao trabalho Logo, vocé comega a descartar a funcionalidade, por exem- plo, atividades funcionais de relatórios, arquivos, seguranca e auditoria Vocé acaba tendo um produto pobre que fica mal perante o departamento de Tecnologia da In- formacão (TT) e posteriormente confirma para os patrocinadores do projeto que vocé não

consegue desenvolver software algum, dentro do prazo e orcamento alocados

Infelizmente, assim como acontece com a corrida dos lemmings ao mar, as em-

presas repetem essa saga continuamente

Desenvolvimento de Software Interativo e Incremental

Esse dilema resulta da recusa tanto do departamento de Tecnologia da Informagao quanto dos patrocinadores do projeto em adotar a abordagem aprenda-enquanto-faz

do desenvolvimento de software, mais formalmente conhecida como desenvolvi- mento de software interativo e incremental

Cap.1 O Dilema do Projeto 3

No contexto de um projeto de software, muitas pessoas confundem os termos interativo e incremental O American Heritage Dictionary, Second College Edition, define esses termos da seguinte maneira:

Interativo — 3 procedimento para se produzir um resultado desejado pela repeti¢ao de uma série de operacgdes que sucessivamente melhor se aproximam do resultado desejado

Incremental — 1 Um aumento em ntmero, tamanho, ou extensao 2 Alguma coisa acres-

centada ou ganha 4 Uma série de adicões ou contribuicões regulares

Vamos dar a essas defini¢des académicas um pouco de “sabor” de software

Interativo: A aplicacão de tarefas de uma forma repetitiva que funciona no sentido de me- lhorar um produto intermediario ou final

Incremental: A criacao de produtos interinos de forma que cada um acrescenta um valor significativo ao projeto como um todo, sustenta-se por si mesmo ou opera dentro de uma in- terface bem definida, ou pode tomar parte como um subcomponente de algum produto final

Como exemplo, suponha que vocé esteja construindo um playground em ma- deira para criangas Vocé comeca simplificando 0 projeto dividindo-o em duas partes incrementais: (1) a torre com o escorregador e (2) a estrutura com o balanco Vocé exe- cuta o projeto fazendo a interacão pela construgao de cada incremento As interagdes podem se destinar primeiramente a criar um desenho em detalhe, depois para com- prar, medir, e cortar a madeira, em seguida para juntar as pegas, e finalmente pintar

a madeira Cada interagéo aproxima mais o objetivo de produzir um produto que sustenta-se por si mesmo Essa abordagem é poderosa porque muitas das mesmas ta- refas interativas (isto é, desenhar, serrar, parafusar e pintar) serao aplicadas a cada incremento (ou seja, torre/escorregador e balanco)

O desafio, porém, é assegurar que o primeiro incremento possa ser fixado (in- terface) nos incrementos subseqtientes Isso requer que você conheca suficientemente bem todos os incrementos para poder prever como eles funcionarao juntos como um produto integrado Veja na Figura 1.2 um exemplo de uma linha do tempo para um projeto usando uma abordagem interativa, incremental

FIGURA 1.2 Linha do tempo com fluxo interativo/incremental

Incremento 1 Incremento 2 Incremento 3

Tempo Decorrido (%) por Incremento

4 Desenvolvendo Aplicativos com Visual Basic e UML Cap 1

Não tenho dúvida de que a aplicacão, durante anos, desses conceitos a muitos tipos diferentes de projetos, usando muitas ferramentas e linguagens diferentes, é a única maneira pela qual se pode desenvolver software de forma bem-sucedida, tanto hoje quanto no futuro

Desenvolvimento Baseado em Risco

A experiéncia tem-me ensinado a ser sempre um pessimista mudo ao abordar qual- quer novo projeto Isso resulta da observagdo repetida de que alguma coisa esté sem- pre a espreita, por perto, pronta para desviar o projeto de seu curso em direcao a um eventual desastre Embora essa atitude possa parecer uma maneira negativa de enca- rar 0 desenvolvimento de um projeto, é isso que tem salvo muitos projetos do desastre

A equipe de projeto tem de estar sempre a procura de riscos Os riscos devem ser trazidos a tona 0 mais cedo e freqiientemente possivel Uma maneira de fazer isso

€ estender a filosofia de desenvolvimento do projeto, que além de ser interativa e in- cremental passa também a ser baseada em risco No Apéndice E ha um exemplo de planejamento de um projeto representando o processo synergy Vocé vera facilmente que a tarefa “avaliar e aliviar os riscos” ocorre freqiientemente A Figura 1.3 mostra uma representacao visual de como deve ser uma estrutura de projeto interativa e in- cremental fundamentada em uma abordagem baseada em risco

FIGURA 1.3 Estrutura de projeto interativa, incremental, com minimizacao dos riscos

Revisão dos Planos de Avaliacão

e Minimizacão dos Riscos Riscos Iniciais, Escopo

Um efeito secundario bastante positivo dessa abordagem é a melhora continua

do produto final Além disso, os riscos sao solucionados prontamente porque aqueles componentes do projeto que apresentam os maiores riscos sao apresentados primeiro

Cap.1 O Dilema do Projeto 5

O Modelo de Processo de Software Interativo

E util visualizar como fica graficamente a combinacgao da nogao de desenvolvimento interativo e incremental A Figura 1.4 fornece uma visao de um modelo de processo interativo e incremental

FIGURA 1.4 = Modelo de processo interativo e incremental: uma dimensao

A fase de Inicio é uma fase de descoberta, um tempo para solidificar o planeja- mento do projeto e incorporar um claro entendimento de quais as caracteristicas que

O projeto implementara

Na fase de Elaboragao, os primeiros requisitos identificados na fase de Inicio sao solidificados e é acrescentado mais rigor ao processo Essa fase também detalha a na- tureza dinâmica da aplicacão e tenta modelar os usos reais do sistema que sao pre- vistos pelos patrocinadores do projeto

6 Desenvolvendo Aplicativos com Visual Basice UML Cap 1

Na fase de Construcão, as perspectivas tanto estatica quanto dinamica do apli- cativo sao materializadas na forma de uma linguagem (por exemplo, VB) e uma for-

ma de armazenamento persistente (por exemplo, Oracle)

Na fase de Transicão, os componentes produzidos na fase de Construcao sao empacotados em unidades disponibilizdveis Essa fase também detalha os problemas

de suporte que envolvem o aplicativo e como o projeto sera mantido em um ambiente

de producão

Dentro de cada fase, ocorrerao tipicamente multiplas interagdes O processo Sy- nergy introduzido neste livro tem um minimo de trés interag6es distintas para cada fase, conforme ilustra a Figura 1.5

FIGURA 1.5 _—Interacdes dentro das fases

O número de interacões dentro de cada fase pode variar, dependendo dos re-

quisitos especiais do projeto Para projetos com um fator de risco mais elevado ou mais elementos desconhecidos, mais tempo sera gasto aprendendo e descobrindo O conhecimento resultante terd de ser traduzido para outros produtos em um arranjo

em camadas

Para tornar 0 projeto ainda mais interessante, as atividades tradicionalmente as- sociadas com qualquer uma das fases podem ser executadas em fases anteriores ou posteriores Por exemplo, se 0 projeto tem um componente visual forte e unico ou esta desvendando novos campos, vocé talvez precise simular um protdétipo durante

a fase de Inicio sé para gerar idéias e solidificar a prova do conceito que virá

Cap.1 ODilema do Projeto 7

Nada no processo Synergy diz que vocé deve executar uma tarefa em uma de- terminada ordem No entanto, para muitos aplicativos, existe uma ordem de processo predominante Além disso, um artefato pioneiro relacionado, usando diagramas UML, sera razoavelmente comum na maioria dos projetos

Combinando Interativo com Incremental: Visao Multidimensional Dado que um processo interativo é benéfico, visualizamos em seguida o fluxo ante- rior aplicado a um cronograma de entrega incremental A Figura 1.6 ilustra a nature-

za interativa dos projetos tipicos de desenvolvimento de software e mostra que diferentes incrementos estarao em diferentes estagios do ciclo de vida

FIGURA 1.6 Modclo de processo interativo e incremental

Elaboracão

:Transicão

8 Desenvolvendo Aplicativos com Visual Basice UML Cap 1

Note que cada incremento (as trés espirais superiores) esta em uma fase diferen-

te de sua evolugao Cada fase (por exemplo, a fase de Inicio) pode também estar em seu proprio ciclo de interacdo A primeira vista, vocé pode pensar que tudo isso pa- rece demasiadamente complexo Do ponto de vista do gerente de projeto, mais coisas precisam ser controladas No entanto, do ponto de vista do usuario, analista, proje- tista e desenvolvedor, existe uma demarcagdo clara entre cada incremento A razao para essa abordagem é, uma vez mais, minimizar o risco desfazendo as jungoes légi- cas do aplicativo e entao atacando cada incremento individualmente

O Modelo do Processo Synergy

O processo Synergy, que se baseia em desenvolvimento de software interativo e in- cremental, combina-se com um plano de projeto de implementacão que lhe serve como mapa para apontar os marcos que vocé deve seguir para assegurar 0 sucesso

do seu projeto Conforme detalha este livro, o modelo do processo Synergy sera re- visitado e destacado e o plano do projeto de apoio também ira aparecendo a medida que revisamos cada tarefa a ser executada, bem como os exemplos de produto

A Figura 1.7 proporciona uma visualizacão prévia do modelo do processo Sy- nergy As caixas (por exemplo, Ciclo de Liberacgao e Escopo de Projeto) representam categorias de atividades ou processos Elas estao ligadas por meio de um fluxo ou or- dem, embora devamos lembrar que algumas tarefas podem ser executadas mais cedo

ou mais tarde, dependendo das necessidades do projeto

FIGURA 1.7 — Modelo do processo Synergy

Cap.1 O Dilema đo Projeto 9

As barras verticais denominadas Início, Elaboracão, Construcão, e Transicão re- presentam as fases do projeto Note que a barra Início atravessa as caixas Análise de Caso de Uso e Modelos Preliminares Isto mostra graficamente que na parte inicial do ciclo de vida do projeto, nés iremos “sobrevoar” ou interar por meio de algumas des- sas atividades de forma a estimar a duragao e custo do nosso projeto

O modelo do processo Synergy sera explicado em detalhes 4 medida que você for lendo o livro Vocé verá que um bom modelo de processo de software, combinado com um plano de projeto detalhado e a habilidade da UML para mostrar a natureza

na vida real de um projeto ao longo de seus nove diagramas, demonstrara ser uma combinagao bastante poderosa

Vendendo a Idéia de um Processo de Software para a Empresa

Para vender uma abordagem de desenvolvimento de software interativo, incremen- tal, baseado em riscos, todos nés precisamos nos tornar melhores negociantes A pri- meira vista, a comunidade dos negocios provavelmente nao gostara da idéia dessa abordagem Por qué? Quando se diz aos patrocinadores de um projeto que a solucao sera fornecida em multiplos incrementos, a reagdo deles, segundo suas experiéncias

no passado, lhes diz que a fase II nunca acontecera Projetos sao cancelados, recursos

sao redirecionados para outras atividades, e as prioridades mudam Assim, como re-

gra, eles se esforcarao por colocar tudo o que for possivel dentro daquele primeiro incremento Portanto o maior desafio é vender a idéia para os patrocinadores do pro- jeto

Aqui estao alguns dos principais beneficios de um processo de projeto de soft- ware que devem ser trabalhados no seu plano de negociacão

¢ Aemppresa obtém valiosos incrementos de modo que se aperfeicoa continua- mente caminhando para o produto final

® Cada incremento fornece beneficios de valor agregado, ao mesmo tempo em que aumenta a confian¢a de que o projeto pode ser flexivel o bastante para

se ajustar as necessidades da empresa em continua evolucao Se a empresa nao permanece estatica, como se pode esperar que o software permaneca es- tatico?

¢ Cada incremento tem uma duragao relativamente curta, de 3 a 9 meses, e as- sim a possibilidade de que o projeto se transforme em um “trem descarrila- do” diminui dramaticamente

¢ Quaisquer problemas com o projeto ou a tecnologia aparecem logo cedo, e nao quando o projeto estiver a 90% de seu tempo de duracao

e Usuarios, analistas, projetistas e desenvolvedores permanecem bastante fo- calizados em cada incremento Eles podem comemorar 0 sucesso bem mais cedo A confianca que isso traz para a equipe nao tem prego

Este livro tem como objetivo o acompanhamento de um bom plano de projeto, usando um processo de desenvolvimento comprovado como guia Para facilitar a co- municacão e direcionar tanto os requisitos quanto o desenho do sistema, é aplicada uma linguagem de modelagem: a UML

10 Desenvolvendo Aplicativos com Visual BasiceUML Cap 1

The Unified Modeling Language

O Object Management Group (OMG) adotou a UML v1.0 em novembro de 1997 Este foi um evento marcante e raramente visto antes, pois assinalou a aceitacão de uma linguagem padronizada de modelagem baseada nas melhores praticas atuais para a

andlise, desenho, e desenvolvimento do software orientado a objeto

A UML surgiu dos esforcos combinados dos “trés amigos”: Grady Booch com seu método Booch, James Rumbaugh com sua Object Modeling Technique (OMT) e Ivar Jacobson com seu método Object Oriented Software Engineering (OOSE) Conforme mencionamos antes, parte da terminologia e filosofia encontrada no processo Synergy

é baseada no Objectory Process de Jacobson

Comecando em 1994, sob os auspicios da Rational Software, a UML comegou a

tomar forma Embora a UML reflita claramente as abordagens combinadas dos trés metoddlogos, ela também inclui as melhores praticas de organizacdes como a Hewlett

Packard, IBM, e Microsoft, bem como outros integrantes da idustria como

Shlaer/ Mellor, Coad/Yourdon, e Martin/Odell A UML foi também foi proposta como uma resposta formal a Request for Proposal da OMG para uma notacaéo padrao

de modelagem orientada a objeto

As ramificagdes da adogao da UML pela OMG nao podem ser superestimadas Aqueles dentre nós que cresceram no mundo da Análise Estruturada e Projeto Estru- turado (Structured Analysis/Structured Design — SA/SD) tinham a sua escolha nume- rosas notacdes de diagramag¢ao e varios modelos de processo de software para aplicar Nao teria sido maravilhoso se pessoas como Ed Yourdon, James Martin e

Tom DeMarco, para citar alguns, tivessem se reunido na década de 70 e de comum

acordo colocado de lado seus “egos” e adotado uma nota¢ao para a abordagem SA/SD para o desenvolvimento de software? Se tivesse havido apenas uma maneira

de expressar o domínio do aplicativo, muitas organizacões teriam se beneficiado sig- nificativamente Não só os modelos de todas as organizacões teriam sido similares, como também a mudanga individual de uma empresa para outra ou de um dominio

de aplicativo para outro teria uma notagaéo comum como linha basica

A UML € entao a primeira notacao que atingiu o consenso entre a maioria dos profissionais, vendedores de software e académicos como o padrdo real para expres- sar um dominio comercial da solucao de software

A UML e seu Lugar no Processo de Software

A UML nao é um modelo de processo de software ou uma metodologia de desenvol- vimento de sistemas; ela €é uma notagdo, um mecanismo para “apontar o problema”

de forma a expor a esséncia do dominio de um aplicativo A combinagao da UML com um bom modelo de processo (o Unified Process da Rational ou o processo Sy- nergy usado neste livro) resulta em uma poderosa combina¢aéo para a criacão de apli- cativos bem-sucedidos

O objetivo da UML é duplo Um deles é proporcionar consisténcia informando

o patrocinador do projeto de que o dominio do problema esta bem entendido O ou- tro é proporcionar um modelo de consisténcia para a implementacão adequada do software No entanto, se vocé tenta usar a UML sem um bom modelo de processo e

Cap.1 ODilema do Projeto 11

plano de projeto (discutido no decorrer deste livro e apresentado amplamente no Apéndice E), o seu projeto falhara

Todos os artefatos que a UML fornece sao rastredveis Se feitos em conjunto com

um bom modelo de processo, os modelos podem se completar uns aos outros Esse elemento da rastreabilidade é fundamental para o projeto Com a UML, 0 projeto nao

so produzira menos produtos inuteis e “sem destino”, mas também servird como um ponto de controle da qualidade do modelo anterior Como os modelos UML sAo in- ter-relacionados na sua criacão, é mais facil identificar quando um componente esta faltando ou esta potencialmente incorreto

Alguns artefatos usados no modelo de processo Synergy nao sao diagramas UML Conforme sera explorado mais adiante neste livro, a UML no resolve direta- mente alguns aspectos de um projeto, incluindo estes a seguir:

e Interface grafica de usuario (GUI)

e Distribuicão do processo

® Distribuicão de dados

Em todos os casos no entanto, as informacões necessárias dessas areas vitais se

baseiam no conhecimento adquirido com os diagramas UML Por exemplo, um arte-

fato útil em sistemas distribuídos é a matriz Objeto /Localizacão Essa matriz detalha

øgeograficamente localizacõðes de interesse no domínio e avalia o tipo de uso que elas pretendem para os objetos no sistema Suas entradas sao as classes identificadas no diagrama de classes e as localizacgdes expostas nos casos de uso Uma vez mais, todos

os artefatos sao rastreáveis; caso contrario, nao vale a pena cria-los

A Esséncia da Modelagem

Um beneficio fundamental da modelagem é que ela proporciona um canal de comu- nicagaéo para membros de equipes de projetos Sem bons modelos, os membros da equipe adquirem o conhecimento do sistema por meio de suas préprias perspectivas

Um projeto nao pode tolerar perspectivas individualizadas, por exemplo, de requisi- tos Se isso ocorreu, então o projeto acabou nao atingindo os requisitos “pretendidos”

E independente do que o planejamento do projeto diz, a equipe de projeto ainda seria culpada por nao satisfazer a agenda de alguém

Grady Booch diz que a modelagem devera atingir os quatro objetivos a seguir:

1 Ajudar a equipe de projeto a visualizar um sistema como ele é ou como ele pretende ser

2 Ajudar a especificar a estrutura ou comportamento do sistema

3 Proporcionar um modelo que servia de guia na construcao do sistema

4 Documentar as decisGes tomadas pela equipe de desenvolvimento de projeto Todos esses objetivos ecoam 0 tema comum da manutencao de uma boa comuni-

cagao Sem boa comunicagao, 0 projeto falhara A UML precisa desses objetivos, e mais.