Estratégia e perguntas freqüentes da modelagem do Visual Studio 2005 Team System
Microsoft Corporation
Maio de 2005
Aplica-se a:
| • | Microsoft Visual Studio 2005 Team System |
Resumo: os clientes e parceiros têm muito interesse em compreender a estratégia da Microsoft para o desenvolvimento controlado por modelos e o respectivo suporte no Visual Studio Team System. Quando explicamos nossa estratégia, eles freqüentemente expressam interesse em alguns dos mesmos tópicos e demonstram algumas das mesmas preocupações. Neste documento, definimos nossa estratégia para desenvolvimento controlado por modelos como uma série de perguntas e respostas que abordam esses tópicos e essas preocupações. As primeiras cinco perguntas tratam dos principais pilares de nossa estratégia, que descrevemos com respostas e explicações detalhadas. Outras perguntas freqüentes são reunidas em uma seção convencional na última seção. (15 páginas impressas)
Nesta página
 | Por que modelar? |
| Como as DSLs são usadas no desenvolvimento controlado por modelos? |
| E quanto ao UML? |
| E quanto ao MDA? |
| O que são fábricas de software? |
| Outras perguntas freqüentes |
Por que modelar?
Os clientes nos disseram que muitas das ferramentas CASE compradas nos anos 80 e no início dos anos 90 não agregaram valor suficiente ao processo de desenvolvimento. Os benefícios prometidos quando elas foram vendidas não se concretizaram, e até mesmo os bons produtos foram superestimados pela promessa de tecnologia.
Se os modelos com suporte dessas ferramentas não refletiam o código e outros artefatos de implementação, elas se tornavam irrelevantes rapidamente. Quando esses modelos eram usados para gerar código, eles normalmente saíam de sincronia assim que os desenvolvedores adicionavam outro código em torno do código gerado. Até mesmo os produtos que fizeram um bom trabalho ao executar o código gerado até o fim algumas vezes surpreendiam os desenvolvedores com a complexidade da solução desse problema. Normalmente, esses problemas eram agravados porque as ferramentas CASE tentavam operar em um nível alto demais de abstração em relação à plataforma de implementação base. Isso provocou a geração de grandes quantidades de código, dificultando ainda mais a solução de problemas provocados pela mistura de código escrito manualmente e código gerado.
Apesar desses problemas, as pessoas envolvidas no desenvolvimento de software acreditam que, de algum modo, a modelagem pode ser aplicada de forma a facilitar suas vidas. Nossa visão é alterar a maneira como os desenvolvedores percebem o valor da modelagem. Alterar sua percepção de que a modelagem é uma atividade sem muita importância que precede o desenvolvimento propriamente dito, para o reconhecimento de que a modelagem é uma tarefa de desenvolvimento importante e não uma atividade voltada principalmente para a documentação. Quando modelos são considerados como artefatos de desenvolvimento de primeira classe, os desenvolvedores escrevem código menos convencional, pois abstrações mais poderosas do aplicativo podem ser implantadas. O desenvolvimento controlado por modelos é, portanto, inerentemente mais produtivo e ágil. Além disso, outras pessoas envolvidas no desenvolvimento, desde analistas comerciais, arquitetos, designers até a equipe de rede e os especialistas de gerenciamento de sistemas, passarão a ver como a modelagem agrega valor para as tarefas pelas quais são responsáveis. Quando os modelos são aplicados ao desenvolvimento e às atividades de tempo de execução dessa maneira, a comunicação entre as pessoas pode ser otimizada e a capacidade de rastreamento por todo o ciclo de vida pode ser habilitada em qualquer direção. Acreditamos que, com o uso mais difundido da modelagem, poderemos mudar essencialmente os custos do desenvolvimento de software e garantir que os sistemas de software atendam às necessidades de uma empresa. Essa abordagem de desenvolvimento controlado por modelos faz parte de uma iniciativa da Microsoft chamada de Fábricas de software.
Observação: as fábricas de software são descritas em profundidade no livro "Software Factories: Assembling Applications with Patterns, Models, Frameworks and Tools" (em inglês), de Jack Greenfield e Keith Short, com Steve Cook e Stuart Kent.
Como as DSLs são usadas no desenvolvimento controlado por modelos?
A Microsoft aprendeu com experiências passadas da indústria e planeja evitar as ciladas das ferramentas CASE adotando uma abordagem de desenvolvimento controlado por modelos com base nas seguintes idéias:
| • | Um modelo deve ser um artefato de primeira classe em um projeto, e não apenas uma parte da documentação aguardando a desatualização. Os modelos possuem uma sintaxe precisa, normalmente são editados e exibidos de maneira melhor com uma ferramenta gráfica e incorporam a semântica que determina como conceitos específicos ao domínio em modelos são mapeados para outros artefatos de implementação, como código, estruturas do projeto e arquivos de configuração. Dessa maneira, um modelo é muito parecido com um arquivo de código-fonte, e os mecanismos que o sincronizam com outros artefatos de implementação são muito parecidos com compiladores. |
| • | Um modelo representa um conjunto de abstrações que oferecem suporte ao desenvolvedor em um aspecto de desenvolvimento bem definido. Por exemplo, considere a tarefa de produzir um aplicativo orientado a serviços que conecta componentes usando serviços da Web. Consideradas todas as outras tarefas nas quais um desenvolvedor precisa se concentrar para criar esse aplicativo, deverá haver um momento em que ele poderá se concentrar apenas na definição da conectividade global do aplicativo em termos de contratos de serviço e das mensagens trocadas. O Application Designer do Visual Studio Team Edition for Software Architects oferece suporte exatamente a esse aspecto do desenvolvimento e gerencia os relacionamentos entre o modelo de conectividade de um aplicativo e todos os outros artefatos (arquivos WSDL, arquivo do projeto, arquivo de código, arquivos de configuração, etc.) que devem ser desenvolvidos para implementar as interconexões definidas pelo modelo. Os modelos criados para serem usados como artefatos de origem dessa maneira possuem o benefício adicional de fornecer uma exibição holística dos detalhes, que de outra forma estariam dispersos, e podem simplificar a comunicação entre os diferentes grupos envolvidos no design, na criação e na implementação de aplicativos modernos e complexos. |
| • | Como os modelos podem abstrair e agregar informações de vários artefatos, eles podem oferecer suporte de maneira mais imediata à verificações de consistência e a outras formas de análise. Por exemplo, um modelo de conectividade de aplicativo pode oferecer suporte à validação do protocolo de contrato, à análise de segurança ou à análise de desempenho. |
| • | Os modelos podem ser implementados por um processo semelhante à compilação, no qual o código, os arquivos de configuração e outros artefatos de implementação gerados pelo compilador nunca são editados manualmente. No entanto, eles são implementados mais freqüentemente por uma combinação de artefatos gerados e editados manualmente. Nesses casos, é realmente importante gerenciar cuidadosamente a maneira como os artefatos gerados e editados manualmente se encaixam. Conforme mencionado acima, não fazer isso de maneira eficiente era uma das principais limitações dos produtos CASE. Temos usado várias técnicas para garantir que os artefatos gerados e editados manualmente sejam mantidos separados e que o código adicionado por um desenvolvedor nunca seja afetado quando o código padronizado exigido por uma ferramenta é gerado. Essas técnicas incluem o uso de delegação e herança de classes e, principalmente, o uso de "classes parciais", um novo recurso das linguagens do .NET no Visual Studio 2005 que foi definido especificamente com essa tarefa em mente. |
Chamamos as linguagens de modelagem definidas dessa maneira como Linguagem Específica de Domínio ou DSL. Imagine uma DSL como uma linguagem pequena e altamente focada na solução de alguns problemas claramente identificáveis que um analista, arquiteto, desenvolvedor, testador ou administrador de sistemas precisa resolver. Os desenvolvedores já estão familiarizados com exemplos de DSLs, de SQL para a manipulação de dados, de XSD para a definição da estrutura de documentos XML e assim por diante. Outro exemplo do Visual Studio Team Edition for Software Architects é uma DSL para modelagem da estrutura lógica das configurações do hardware do datacenter e do software do host. Essa DSL e seu designer gráfico relacionado podem ser usados para a validação, durante o tempo de design, de que os aplicativos estão configurados de acordo com seus objetivos de implementação pretendidos, alertando o desenvolvedor sobre problemas quando eles ainda podem ser corrigidos de forma menos dispendiosa.
Boas maneiras de se localizar DSLs qualificadas consistem em identificar os padrões usados pelos desenvolvedores e, em seguida, encapsulá-los em uma linguagem de modelagem ou trazer à tona os conceitos em uma estrutura de software como abstrações em uma linguagem de modelagem que possa, então, gerar quantidades pequenas de código que estendam a estrutura. Essas técnicas permitem controlar a quantidade e a complexidade do código gerado, oferecendo valor real aos desenvolvedores, sem a confusão que caracterizava os produtos CASE.
Recentemente, a Microsoft anunciou as ferramentas DSL, as quais permitirão que os clientes e parceiros criem DSLs usando a mesma tecnologia no Visual Studio 2005 que usamos na criação de ferramentas de modelagem que serão fornecidas com o Visual Studio Team Edition for Software Architects. Essa tecnologia, que pode ser entendida como "ferramentas para criar ferramentas", simplifica a tarefa de definir DSLs e reduz o esforço e as habilidades necessárias para criar editores e compiladores gráficos para elas.
E quanto ao UML?
Muitas pessoas que lêem nossas opiniões sobre o desenvolvimento controlado por modelos assumem que nossa ênfase em DSLs nos coloca em uma posição contrária ao UML. Queremos deixar claro que isso não é verdade. Antes do UML, havia uma diversidade não produtiva de abordagens para a modelagem, e sua convergência para o UML 1.0 foi uma etapa significativa em direção ao uso de modelos no desenvolvimento de software.
Mas, por qualquer que sejam os motivos, a existência do UML e de ferramentas baseadas no UML não alteraram significativamente a maneira como os desenvolvedores criam os aplicativos. E também não contribuiu significativamente para a produtividade do desenvolvedor. Como a Microsoft fornece uma das ferramentas UML mais usadas, uma ferramenta baseada no Visio que foi fornecida primeiramente com o Visual Studio Enterprise Architect, fizemos uma pesquisa anônima com desenvolvedores (e não apenas com clientes) sobre o uso da ferramenta. Descobrimos que a população que declara usar ferramentas UML para oferecer suporte a suas tarefas é muito pequena, e a maior parte do uso está concentrada em torno de diagramas de classe. Quando analisamos detalhadamente os que afirmam usar diagramas de classe, descobrimos que uma fração muito pequena realmente os usa para gerar código.
Essa foi uma das forças que impulsionaram as ferramentas de desenvolvimento controlado por modelos no Visual Studio Team Edition for Software Architects. Queríamos realmente executar as tarefas que os desenvolvedores acham difíceis e descobrir maneiras que fizessem as ferramentas de modelagem adicionar valor e ajudá-los. Somos defensores apaixonados da notação e dos diagramas UML. Se você caminhar pelos escritórios dos desenvolvedores em um corredor da Microsoft, descobrirá quadros de comunicações com diagramas de classe e de seqüência UML. Usamos a notação UML em documentos de especificações e em muitos outros diagramas preparados para apresentações e esboços em guardanapos do restaurante. Para oferecer suporte a nossos clientes para que eles possam produzir documentação e esboços conceituais, continuaremos a fornecer o conjunto de ferramentas UML com o Visual Studio 2005. Na verdade, na Microsoft, geralmente usamos UML para muitas finalidades, como para documentação ou compartilhamento de idéias conceituais, mas quase nunca para nenhuma finalidade em que esses documentos sejam realmente artefatos de desenvolvimento de software.
Os mesmos quadros de comunicações em escritórios e corredores também estão cobertos com código rabiscado. Mas, novamente, são apenas esboços. Raramente eles são uma fonte perfeita de programa compilável. Essa é uma diferença-chave para os desenvolvedores. Qualquer artefato que contribua com desenvolvimento de software real deve ser capaz de manipulação digital. O código-fonte tem uma sintaxe bem definida, uma semântica abrangente, normalmente definida de maneira comportamental pela transformação do compilador em um código de nível mais baixo ou IL, e pode ser manipulado consistentemente por compiladores, depuradores e programas de refatoração, para citar apenas alguns. Para ser útil aos desenvolvedores, um modelo deve ter o mesmo status que o código-fonte. Ele também deve ter uma sintaxe precisa, uma semântica abrangente e mapeamentos bem definidos para o código-fonte ou outros modelos bem definidos. Ele precisa ser mais do que apenas documentação.
Pense no Application Designer do Visual Studio Team Edition for Software Architects, por exemplo. Ele não é apenas documentação, embora possa atender a esse objetivo. Em vez disso, ele permite que o desenvolvedor (ou arquiteto) se concentre em um aspecto do seu sistema: a conectividade entre serviços em uma arquitetura baseada em serviços. Ele pode projetar esse aspecto do sistema antes de criar projetos, arquivos WSDL, código e esquemas ou pedir à ferramenta para documentar a conectividade entre serviços se esses artefatos já existirem. Como as informações sobre conectividade estão dispersas entre os muitos artefatos de desenvolvimento, a visão holística, como a fornecida por um diagrama, é fundamentalmente útil mesmo que todas as informações que ela contemple possam ser deduzidas pela análise cuidadosa dos artefatos de implementação. O Application Designer possui uma sintaxe bem definida (seu metamodelo DSL) e previsível, com mapeamentos sempre sincronizados para os vários artefatos de implementação. A estrutura básica do designer desempenha a função de um compilador para diagramas do Application Designer, muito semelhante à função desempenhada por um compilador tradicional em relação aos arquivos do código-fonte.
Mas por que não criamos essa nova "linguagem" de conectividade de serviços apenas como uma extensão ao UML, especialmente com os aperfeiçoamentos feitos no UML 2.0?
Bem, quando olhamos para a direção tomada pela especificação do UML 2.0, compreendemos que havia vários motivos pelos quais ele não podia ser a base para qualquer coisa além de documentação. A especificação do UML 2.0 adicionou complexidade ao padrão com ainda mais sublinguagens entrelaçadas, mas ele ainda não resolveu problemas críticos do desenvolvimento moderno de aplicativos, como design do banco de dados, teste, implantação, orientação de serviço, desenvolvimento baseado em componentes e construção da interface do usuário de uma maneira natural. Como nenhuma sublinguagem natural do UML se ajusta aos requisitos de conectividade de serviços, teríamos que recorrer à descrição de nossa DSL de Design de Aplicativo usando estereótipos e marcas em uma sublinguagem UML existente. Isso levaria a um modelo excessivamente complicado dentro do que foi descrito por muitos da indústria como uma especificação já inflada e complexa. O uso da notação UML padrão, na qual uma forma existente correspondente a qualquer sublinguagem estendida é reutilizada, teria comprometido a habilidade de leitura e a objetividade dos diagramas. Finalmente, teríamos sido pressionados pela falta de precisão na especificação de áreas-chave e pela incompatibilidade de sistemas de tipo inerentes ao UML em comparação com linguagens .NET e XML.
Por esses motivos, decidimos definir a DSL de Design de Aplicativo usando um metamodelo criado com esse objetivo, definido por si mesmo como um membro de uma família de metamodelos relacionados. Isso nos dá uma base natural e precisa para a conectividade de serviços e um mapeamento de alta fidelidade para os artefatos de implementação subjacentes que incluem, naturalmente, uma certa quantidade de código. Chegamos à mesma conclusão em relação a outras tarefas de desenvolvimento direcionadas, e isso levou a DSLs semelhantes para o Class Designer e o Logical Data Center Designer descritos em outros white papers. Portanto, o suporte a DSLs extensíveis, criadas como uma família, com mapeamentos bem definidos entre eles e outros artefatos de desenvolvimento tornou-se a base da estratégia de desenvolvimento controlado por modelos da Microsoft.
Para resumir, recomendamos usar o UML e as ferramentas baseadas em UML para:
| • | Criação de esboços. |
| • | Quadros de comunicações. |
| • | Documentação. |
| • | Desenhos conceituas que não estão diretamente relacionados ao código. |
Recomendamos DSLs e ferramentas baseadas em DSL definidas precisamente para:
| • | Abstrações precisas das quais o código é gerado. |
| • | Abstrações precisas que mapeiam para pontos de variação em estruturas e componentes. |
| • | Mapeamentos precisos entre DSLs. |
| • | Desenhos conceituais que tenham mapeamentos precisamente especificáveis para outras DSLs ou para artefatos de código. |
Não recomendamos nenhum dos itens acima para a programação visual da lógica detalhada do programa (pelo menos pelos próximos anos).
E quanto ao MDA?
O MDA é uma marca licenciada para o OMG que tem como base o uso de UML para desenvolvimento controlado por modelos. Ele coloca uma grande ênfase em modelos independentes de plataforma e em técnicas produtivas. De acordo com as perguntas freqüentes do OMG:
"O MDA é uma nova maneira de escrever especificações e de desenvolver aplicativos, baseada em um PIM (modelo independente de plataforma). Uma especificação completa de MDA consiste em um modelo básico definitivo de UML independente de plataforma, mais um ou mais PSMs (modelos específicos de plataforma) e conjuntos de definições de interface, cada um descrevendo como o modelo básico é implementado em uma plataforma diferente de middleware. Um aplicativo MDA completo consiste em um PIM definitivo, além de um ou mais PSMs e implementações completas, uma para cada plataforma para a qual o desenvolvedor do aplicativo decidir oferecer suporte".
O MDA, conforme definido pelo OMG, resolve apenas um pequeno subconjunto do que acreditamos ser os problemas reais que devem ser resolvidos para permitir um desenvolvimento eficiente controlado por modelos. Uma metodologia de desenvolvimento controlado por modelos eficiente deve resolver problemas pragmáticos, como:
| • | Que tipos de sistemas podem ser desenvolvidos? Como existem diferenças muito reais entre sistemas diferentes, uma metodologia de desenvolvimento controlado por modelos deve reconhecer essas diferenças. Para ser eficiente, ela deve começar descrevendo o problema a ser resolvido e, em seguida, identificar tecnologias específicas que podem ser usadas para resolvê-lo, mostrando onde cada tecnologia se ajusta na solução e como as várias tecnologias funcionam em conjunto para fornecer a solução. | ||||||||||||
| • | Qual é a arquitetura de um determinado tipo de sistema? A resposta a essa pergunta está relacionada não apenas às tecnologias que podem ser usadas, mas também à identificação das características dessas tecnologias que são importantes para o design de cada parte do sistema, além de estar relacionada à configuração de cada uso de cada tecnologia. Esse é o assunto da arquitetura de software, que é amplamente reconhecida como uma das disciplinas mais importantes do ciclo de vida do software. Uma arquitetura de software define as decisões de alto nível do design que fornecem a estrutura a um sistema e que determinam seus atributos qualitativos. Como os modelos são principalmente usados para descrever partes importantes relativas à arquitetura de um sistema, eles devem estar estreitamente integrados com o desenvolvimento da arquitetura do software. | ||||||||||||
| • | O que deve ser modelado para um determinado tipo de sistema? Como diferentes sistemas podem ter arquiteturas muito diferentes, nenhum conjunto único de modelos pode descrever todos os sistemas possíveis de maneira eficaz. Portanto, a resposta a essa pergunta varia para tipos diferentes de sistemas. Em nossa opinião, um PIM e um PSM únicos por plataforma de destino, todos desenvolvidos usando uma linguagem de modelagem com uma finalidade geral, conforme descrito pelo MDA, são insuficientes para oferecer suporte a níveis significativamente superiores de automação prometidos pelo desenvolvimento controlado por modelos. A automação sofisticada do ciclo de vida do software requer muitos tipos adicionais de modelos, como modelos que:
| ||||||||||||
| • | Como as técnicas controladas por modelos devem ser integradas com as técnicas de desenvolvimento focadas no código? Os modelos devem ser usados para ajudar os desenvolvedores com tarefas de implementação, como a consulta e a navegação pela base de código, a depuração, a determinação de perfis, a análise de cobertura, a aplicação e refatoração de padrões e devem estar estreitamente integrados a ambientes de desenvolvimento orientados por arquivos. |
Além disso, pelas razões declaradas acima, a ênfase no uso do metamodelo UML publicado é problemática para nós. Finalmente, embora a ênfase na independência de plataforma seja uma preocupação para alguns clientes, cada vez ouvimos mais sobre sua necessidade de produtividade, capacidade de previsão, segurança, controle e maneiras eficientes de implantar e gerenciar aplicativos. No entanto, concordamos com o foco do MDA no uso de modelos para construir aplicativos e na importância de mapeamentos bem definidos entre modelos. Também reconhecemos o valor que os modelos podem fornecer para a construção de aplicativos que se estendem por plataformas heterogêneas com componentes interoperáveis.
Algumas organizações que perseguem o desenvolvimento controlado por modelos aceitam uma interpretação mais ampla do termo MDA do que a interpretação do OMG. Na verdade, conforme descrevemos, elas precisam fazer isso para obter êxito. O uso de qualquer uma das especificações do OMG para orientar o desenvolvimento controlado por modelos é normalmente conhecido como MDA, quer ele envolva ou não PIMs e PSMs. Algumas organizações, por exemplo, vêem a especificação de MOF do OMG como a chave para o MDA. Essa visão conta com novas linguagens de modelagem definidas com o uso do MOF, não com linguagens de modelagem que estão predefinidas no UML, e é efetivamente semelhante à nossa abordagem. Ofereceremos suporte ao intercâmbio com ferramentas UML e MOF populares em outras plataformas, por meio de XMI ou de formatos nativos, para ajudar os clientes que as estão usando a obterem sucesso com o desenvolvimento controlado por modelos.
O que são fábricas de software?
Como já dissemos, nossa abordagem ao desenvolvimento controlado por modelos faz parte de uma iniciativa da Microsoft chamada de Fábricas de software. Em vez de adotar uma abordagem genérica, padronizada, as fábricas de software usam coleções personalizadas de DSLs para oferecer conjuntos personalizados de abstrações para atender às necessidades de famílias específicas de sistemas, como comércio eletrônico, arbitragem financeira ou aplicativos de home banking. Com as fábricas de software, os modelos são usados não apenas para análise e design, mas para oferecer suporte a muitos tipos variados de computação durante todo o ciclo de vida do software, até mesmo em tempo de execução. Esse é um princípio fundamental das fábricas de software e também da DSI (Dynamic Systems Initiative) da Microsoft, que implementa e complementa a iniciativa de fábricas de software.
Precisamos considerar as fábricas de software como um MDA abrangente e estendido, em que o MDA é definido em um sentido mais amplo do que a definição oficial baseada em PIMs e PSMs. As fábricas de software vão além dos modelos genéricos independentes e específicos de plataformas para resolver os problemas adicionais descritos na seção anterior.
Uma fábrica de software define uma metodologia personalizada para uma família específica de sistemas usando um gráfico de pontos de vista. Cada ponto de vista define algum aspecto do ciclo de vida para membros da família do sistema, como captura dos requisitos, design do banco de dados ou definição do contrato de serviço. A fábrica associa ativos reutilizáveis a cada ponto de vista e os entrega no contexto daquele ponto de vista para os membros de desenvolvimento da equipe da família do sistema, eliminando a necessidade de pesquisar ativos aplicáveis, permitindo a validação e oferecendo suporte à aplicação de diretrizes manuais e automáticas.
O gráfico de pontos de vista, chamado de esquema da fábrica de software, relaciona o trabalho feito em um nível de abstração, em uma parte do sistema ou em uma fase do ciclo de vida ao trabalho feito em outros níveis ou em outras partes e fases. Ele pode ser usado para gerar artefatos completa ou parcialmente, incluindo modelos, código-fonte, arquivos de configuração e assim por diante; de outros artefatos, principalmente de modelos; para manter os artefatos sincronizados durante o desenvolvimento; para validar os artefatos desenvolvidos manualmente; para avaliar o impacto de defeitos ou alterações nos requisitos; para organizar e aplicar padrões e outras práticas recomendadas; para capturar metadados durante o desenvolvimento do sistema a fim de oferecer suporte à operação e à manutenção do sistema; e para fornecer outras formas de orientação e controle.
As fábricas de software automatizam o empacotamento e a entrega de ativos reutilizáveis, incluindo modelos e ferramentas controlados por modelos, outros tipos de ferramentas, como assistentes, modelos e utilitários, processos de desenvolvimento, componentes de implementação, como bibliotecas de classes, estruturas e serviços, e ativos de conteúdo, como padrões, folhas de estilos, arquivos de ajuda, arquivos de configuração e documentação. Como o esquema da fábrica de software é um modelo, as fábricas podem ser manipuladas com o uso de ferramentas. Fábricas maiores podem ser criadas por meio da combinação de fábricas menores, e fábricas especializadas pela personalização de fábricas genéricas.
A criação de uma fábrica é muito semelhante à criação de um estrutura. Ela envolve a coleta e implementação de padrões e outras práticas recomendadas para facilitar sua aplicação pelos desenvolvedores. Usar uma fábrica é mais eficiente do que criar sistemas manualmente a partir do zero, por que em vez de examinar catálogos e repositórios, esperando localizar componentes reutilizáveis, os desenvolvedores que usam uma fábrica têm componentes reutilizáveis apropriados para cada aspecto do sistema em desenvolvimento imediatamente disponíveis no contexto da arquitetura e do processo de desenvolvimento do sistema.
Naturalmente, a iniciativa de fábricas de software não é apenas limitada à Microsoft e aos produtos que fornecemos. Ao contrário, nós vemos as fábricas como a base de um ecossistema amplo no qual nossos clientes e parceiros participam, criando fábricas personalizadas sobre as fundações que fornecemos e oferecendo componentes de fábrica a outros membros do ecossistema.
A reação dos clientes e parceiros em relação às fábricas de software é muito positiva. Recomendamos as fábricas de software como a melhor direção a ser tomada pelas organizações modernas que desejam aperfeiçoar sua abordagem de desenvolvimento em linha com expectativas comerciais, e estamos fornecendo o Visual Studio Team Edition for Software Architects, as ferramentas DSL e outros novos recursos no VSTS como produtos iniciais da iniciativa de fábricas de software.
Para obter mais informações, consulte Software Factories Workbench (em inglês).
Outras perguntas freqüentes
Geral
Qual suporte para o desenvolvimento controlado por modelos é fornecido no Visual Studio 2005?
O Visual Studio 2005 contém uma nova estrutura avançada de modelagem que ativa o Visual Studio 2005 Class Designer e o Distributed System Designers no Visual Studio 2005 Team System. Com o tempo, vamos expor a plataforma de modelagem subjacente para os usuários finais a fim de permitir que outras pessoas criem ferramentas de desenvolvimento sofisticadas controladas por modelos. As ferramentas de DSL da Microsoft são o primeiro passo na direção desse objetivo.
O Visual Studio 2005 Class Designer é um aperfeiçoamento da produtividade do desenvolvedor que permite visualizar a estrutura de classes e seus relacionamentos, criar novas classes usando um ambiente de design visual e refatorar classes facilmente. O Class Designer trata das construções específicas ao .NET, como as classes parciais e genéricas, como cidadãos de primeira classe, permitindo que você modele os aplicativos do .NET com alta fidelidade. Permanecendo em sincronia contínua com o código, o Class Designer fornece ao desenvolvedor uma representação visual de seu código em todos os momentos. Para obter mais informações, consulte Visual Studio 2005 Class Designer (em inglês).
O Visual Studio 2005 Team Edition for Software Architects inclui o Distributed System Designers, que é destinado ao design de aplicativos orientados a serviços, principalmente os que dependem de serviços da Web baseados em ASMX.
O Distributed System Designers consiste em quatro designers:
| • | O Application Designer, que permite que os desenvolvedores e arquitetos definam aplicativos que serão configurados em sistemas para implantação. |
| • | O Logical Datacenter Designer, usado para criar diagramas de hosts interconectados que representam a estrutura lógica de um datacenter para fins de comunicação de informações importantes para o desenvolvedor sobre o ambiente de implantação de destino. |
| • | O System Designer, usado para compor aplicativos em sistemas. |
| • | O Deployment Designer, usado para ligar aplicativos de um sistema com servidores lógicos (hosts do aplicativo) modelados no Logical Datacenter Designer. |
Os arquitetos de aplicativos podem visualizar seus aplicativos orientados a serviços e os desenvolvedores podem trabalhar com o código gerado enquanto mantêm as alterações no código sincronizadas com o design visual. Os arquitetos de infra-estrutura podem criar abstrações lógicas de seu datacenter e validá-las em relação às restrições do aplicativo/datacenter criado pelo arquiteto do aplicativo antes da implantação real. Relatórios gerados a partir dessa validação ajudam a documentar o mapeamento da implantação.
Para os clientes que requerem as ferramentas OOA&D (Object-Oriented Analysis and Design), continuamos a fornecer suporte ao Visio for Enterprise Architects como parte do Visual Studio 2005 Team System. O Visio for Enterprise Architects fornece uma solução completa de desenho, diagramação, geração de código e engenharia reversa para os clientes que desejam ferramentas de modelagem UML tradicionais. Vários fornecedores terceirizados também oferecerão ferramentas UML integradas ao Visual Studio 2005.
Qual é a funcionalidade fornecida pelo Visio for Enterprise Architects?
Com o uso do Microsoft Visio for Enterprise Architects, os usuários podem criar e comunicar a arquitetura do aplicativo, os requisitos comerciais, o design do banco de dados e os processos comerciais. Os arquitetos que usam o Microsoft Visual C++ .NET, o Microsoft Visual Basic .NET ou o Microsoft Visual C# .NET podem usar modelos UML (Unified Modeling Language) 1.3 para especificar a arquitetura e a funcionalidade do aplicativo, reduzir o tempo de desenvolvimento por meio da geração direta de classes, funções e métodos e documentar o código existente do aplicativo por projetos de engenharia reversa. O Visio for Enterprise Architects permite que os desenvolvedores criem designs e modelos arquitetônicos que podem ser compartilhados com o restante da equipe.
O Visio for Enterprise Architects fornece suporte completo à modelagem de banco de dados, incluindo visões conceituais, lógicas e físicas. Os analistas comerciais podem inserir facilmente regras comerciais usando o Fact Editor, que, por sua vez, gera um modelo de banco de dados subjacente que pode ser refinado por um analista de banco de dados. A engenharia de ida e volta garante que as alterações feitas em qualquer uma das exibições serão refletidas por toda a parte, melhorando a comunicação entre a equipe de desenvolvimento.
O Visual Studio Team System oferece suporte a qual versão do UML?
O Visio for Enterprise Architects oferece suporte à especificação de linguagem UML 1.3.
A Microsoft continua a acreditar no valor das ferramentas de modelagem do UML? Nesse caso, por que a Microsoft não oferece suporte ao UML 2.0?
Sim, absolutamente. Acreditamos que o UML continua a ter seu lugar nos estágios iniciais do ciclo de vida do desenvolvimento de software e continuamos a oferecer suporte a vários parceiros que produzirão ferramentas do UML 2.0 para o Visual Studio 2005. Nossos próprios designers específicos de domínio também oferecerão suporte a convenções de notação do UML quando apropriado.
Da Microsoft, veremos vários designers que tratam os modelos como cidadãos de primeira classe e que podem ser usados para realmente orientar o desenvolvimento, e não apenas para criar documentação. Os Distributed System Designers no Visual Studio 2005 Team Edition for Software Architects são o primeiro exemplo desse tipo de ferramenta.
A Microsoft está tentando ignorar o padrão UML e limitar os clientes a suas próprias linguagens de modelagem?
Não. O padrão UML é fraco e, por esse motivo, a maioria das ferramentas UML não são capazes de interoperar de maneira transparente. Embora reconheçamos o valor do UML para a documentação e para o entendimento do design do software, as linguagens específicas de domínio permitirão que você trabalhe em níveis mais altos de abstração e se concentre em problemas relevantes a domínios específicos.
Com o tempo, a Microsoft fornecerá ferramentas de modelagem adicionais específicas de domínio e continuaremos a trabalhar com nossos parceiros para trazer ferramentas UML para o Visual Studio 2005, criadas sobre nossa estrutura de modelagem.
Posso importar meus diagramas UML existentes no Visual Studio Team System?
A maioria das ferramentas de design de classes baseadas em UML usam variantes características de XMI para exportar e importar informações que refletem suas implementações dos padrões UML. Não estamos nos comprometendo a produzir uma ferramenta personalizada de importação/exportação de XML para cada uma dessas ferramentas. É possível "importar" logicamente diagramas de classe UML existentes, primeiro gerando código a partir dos diagramas e exibindo esse código por meio do Class Designer.
O Visual Studio Team System oferece suporte à modelagem comportamental e a diagramas de Caso de Uso?
Sim, a modelagem comportamental e os diagramas de Caso de Uso com geração de código e engenharia reversa têm suporte por meio do Visio for Enterprise Architects, incluído no Visual Studio Team System. No entanto, o Visual Studio Team Edition for Software Architects não oferece suporte nativo a esses tipos de diagramas. Tipos personalizados de diagramas também podem ser criados com base na avançada estrutura de modelagem do Visual Studio 2005, com o uso das ferramentas da Microsoft para linguagens específicas de domínio, lançadas recentemente.
Ferramentas da Microsoft para linguagens específicas de domínio
O que são linguagens específicas de domínio?
Uma DSL (linguagem específica de domínio) é uma linguagem criada para uma tarefa específica em uma área com um problema determinado, em comparação com uma linguagem com uma finalidade geral. As DSLs estão ganhando popularidade no campo da engenharia de software para melhorar a produtividade, a capacidade de manutenção e de reutilização de artefatos de software e para permitir a expressão e a validação de conceitos no nível de abstração do domínio problemático.
Usando linguagens específicas de domínio, é possível criar ferramentas de modelagem personalizadas e essencialmente definir uma nova linguagem de modelagem e implementá-la de maneira bastante simples. Por exemplo, uma linguagem especializada pode ser usada para descrever uma interface do usuário, um processo comercial, um banco de dados ou o fluxo de informações e, em seguida, pode ser usada para gerar código a partir dessas descrições.
O Visual Studio 2005 Team Edition for Software Architects inclui vários designers visuais de alta qualidade, baseados em linguagens específicas de domínio, para o design de sistemas distribuídos e a validação desses sistemas com um datacenter lógico.
Quais são as ferramentas da Microsoft para linguagens específicas de domínio?
As ferramentas da Microsoft para linguagens específicas de domínio permitem descrever os conceitos relevantes de um domínio com um problema específico e servir como base para a geração de designers visuais personalizados no Visual Studio 2005. Elas permitem construir seus próprios designers personalizados sobre a mesma infra-estrutura que alimenta o Visual Studio Team System Distributed System Designers (Visual Studio 2005 Team System: Designing Distributed Systems for Deployment, em inglês) e o Class Designer (Visual Studio 2005 Class Designer, em inglês) e são a chave para a concretização das fábricas de software. Essas ferramentas e as instruções passo a passo correspondentes podem ser encontradas no DSL Tools workbench, no Visual Studio Team System workshop (em inglês).
Quais produtos do Visual Studio oferecerão suporte às ferramentas de DSL da Microsoft?
A autoria de DSL terá suporte no Visual Studio Professional Edition e versões posteriores. O consumo de DSL terá suporte no Visual Studio Standard Edition e versões posteriores.
Quais tipos de designers podem ser criados usando as ferramentas de DSL recém-lançadas?
As ferramentas de DSL podem ser usadas para construir designers visuais personalizados adaptados para qualquer domínio problemático. Por exemplo, é possível criar uma ferramenta de modelagem de processo comercial usando ferramentas DSL para descrever os conceitos específicos à maneira como sua organização modela processos comerciais. Se você estiver criando uma ferramenta de gráfico de estado, poderá descrever o que é um estado, as propriedades do estado, os tipos de estados existentes, como são definidas as transações entre estados, etc. Naturalmente, a noção de um gráfico de estado usado para descrever o status de contratos em uma empresa de seguros e a noção de um gráfico de estado para descrever a interação do usuário nas páginas de um site são conceitualmente semelhantes, mas têm implementações bastante diferentes. Com a criação de um designer personalizado, é possível definir claramente o conceito de gráfico de estado necessário em sua ferramenta.
A Microsoft tem o suporte da indústria para as linguagens específicas de domínio e as fábricas de software?
Além do suporte abrangente dentro da comunidade acadêmica, incluindo muitos clientes e parceiros, a Microsoft tem o suporte das seguintes empresas:
| • | Borland, a criadora do UML 2.0. |
| • | Unisys, fábricas de software para uma variedade de indústrias. |
| • | Siemens, fábricas de software de dispositivos de sistemas de imagens médicas. |
| • | Kinzan, ferramentas específicas de domínio para desenvolvimento da Web. |
| • | Nationwide, ferramentas específicas de domínio para o mercado financeiro. |
Class Designer e Visio
O que é o Visual Studio Class Designer?
O Visual Studio Class Designer permite visualizar a estrutura de classes e seus relacionamentos, criar novas classes usando um ambiente de design visual e refatorar classes facilmente. Para obter mais informações, consulte:
| • | Visual Studio 2005 Class Designer (em inglês) |
| • | Designing an API with the Visual Studio 2005 Class Designer (em inglês) |
| • | Blog da equipe do Class Designer (em inglês) |
Quais versões do Visual Studio conterão o novo Class Designer?
O Visual Studio 2005 Standard Edition e versões posteriores conterão o Class Designer.
Quais linguagens têm suporte no Class Designer?
O Class Designer oferece suporte a C#, VB.NET e J#. O Class Designer no Visual Studio 2005 não oferece suporte ao C++, mas essa é uma prioridade para o próximo lançamento comercial do Visual Studio.
Qual a diferença entre o Class Designer e o Visio?
O Visual Studio Class Designer permite visualizar a estrutura de classes e seus relacionamentos, criar novas classes usando um ambiente de design visual e refatorar classes facilmente. As alterações feitas no diagrama de classes são refletidas imediatamente no código e as alterações feitas no código afetam imediatamente a aparência do designer. Esse relacionamento síncrono entre o designer e o código facilita a criação e a configuração de tipos complexos de CLR visualmente. O Class Designer é útil para entender o código existente, o design de classes, o refatoramento do código e a criação da documentação. O Class Designer está integrado de maneira transparente ao Visual Studio 2005 (Visual Studio Standard Edition e versões posteriores) e foi criado para funcionar com o .NET Framework e o CLR.
É possível importar diagramas existentes do Visio, do Rational Rose ou do Rational XDE no novo Class Designer?
Sim, é possível "importar" logicamente diagramas de classe UML existentes, primeiro gerando o código dos diagramas e exibindo esse código por meio do Class Designer.
O Class Designer oferece suporte à importação/exportação de XMI?
Não, o Class Designer não oferece suporte à importação/exportação de XMI. Os usuários podem gerar o código de seus modelos existentes e, em seguida, usar o Class Designer para visualizar esse código. Como as ferramentas de design de classes baseadas em UML usam variantes características de XMI para oferecer suporte a suas implementações, não estamos nos comprometendo a produzir um XMI personalizado para a ferramenta de importação/exportação do Class Designer para todos os produtos de terceiros.
O Visio oferece suporte à importação/exportação de XMI?
Atualmente, o Visio oferece suporte à exportação de XMI, por meio de um download autônomo separado. Para obter mais informações, consulte Visio 2003 UML To XMI Export (em inglês).
Qual é a direção futura do Visio? Como o Visio e o Class Designer se encaixam na contexto mais amplo das fábricas de software?
O Visio for Enterprise Architects é fornecido como parte do Visual Studio 2005 para oferecer compatibilidade retroativa com os investimentos existentes em Visio dos clientes, e o suporte à funcionalidade do Visio continuará existindo. No entanto, o novo Class Designer desfruta de integração transparente com o Visual Studio 2005 e foi especialmente criado para funcionar com o .NET Framework e o CLR. O Visual Studio Class Designer permite visualizar a estrutura de classes e seus relacionamentos, criar novas classes usando um ambiente de design visual e refatorar classes facilmente. As alterações feitas no diagrama de classes são refletidas imediatamente no código e as alterações feitas no código afetam imediatamente a aparência do designer. Esse relacionamento síncrono entre o designer e o código facilita a criação e a configuração de tipos complexos de CLR visualmente. O Class Designer é útil para entender o código existente, o design de classes, o refatoramento do código e a criação da documentação. As novas ferramentas de linguagem específica de domínio, como parte do SDK do Visual Studio 2005, permitem que os clientes e parceiros criem designers personalizados adequados para o seu domínio problemático. Por exemplo, a Borland anunciou planos de criar um conjunto completo de designers de UML 2.0 com base nessa estrutura. Essa é a mesma estrutura sobre a qual o Class Designer e os Distributed System Designers foram criados.
Fábricas de software
O que são fábricas de software?
As fábricas de software consistem em ferramentas, processos e outros ativos especializados, como padrões, arquiteturas, estruturas, modelos, requisitos, casos de teste e topologias de implantação, que encapsulam o conhecimento comercial e técnico de domínios com problemas específicos. Por exemplo, uma fábrica de software da indústria de assistência médica pode consistir em ferramentas de modelagem personalizadas para criar soluções de assistência médica, orientação do processo que explica e orienta os desenvolvedores pelos aspectos exclusivos da indústria de assistência médica e estruturas arquitetônicas que fornecem classes básicas comuns para soluções de assistência médica. Esse tipo de fábrica de software automatizará as tarefas rotineiras e braçais que um desenvolvedor precisa executar para criar soluções de assistência médica, liberando-os para aplicar sua criatividade e experiência para concluir o projeto.
As fábricas de software vão industrializar o desenvolvimento de software e eliminar a necessidade de programadores habilidosos?
Ao contrário das conotações do século 19 sobre o termo "fábrica", as fábricas de software não são de nenhuma maneira uma forma de transformar desenvolvedores em trabalhadores braçais. Em vez disso, as fábricas de software tornarão os desenvolvedores mais produtivos, automatizando tarefas rotineiras e braçais e ajudando-os a trabalhar em níveis mais altos de abstração. Tínhamos em mente conotações mais atuais do termo "fábrica" quando adotamos o termo, principalmente o uso de robôs que automatizam o trabalho manual. Ferramentas programáveis fornecidas por fábricas permitirão que os desenvolvedores dediquem mais tempo pensando sobre como solucionar problemas e menos tempo fazendo todo o trabalho braçal para criar, construir e implantar suas soluções.
O que foi anunciado na OOPSLA 2004?
Na OOPSLA 2004, anunciamos:
| • | Um modelo de extensibilidade para criar ferramentas de design visual personalizadas para o Visual Studio 2005 Team System para domínios com problemas específicos. |
| • | A disponibilidade imediata de uma Community Technology Preview de uma ferramenta para criar ferramentas de design visual personalizadas no Visual Studio 2005 Team System. |
| • | Suporte abrangente de parceiros e da indústria para estender as ferramentas de design visual no Visual Studio 2005 Team System por meio de ambientes de modelagem específicos de domínio, conforme descrito acima. |
Onde posso obter mais informações sobre fábricas de software?
Para obter mais informações, consulte Software Factories Workbench (em inglês).