Introdução
- Alinhando Metodologia com Arquitetura
N
N
o capítulo anterior vimos como a arquitetura de base proposta pelo jCompany pode ser utilizada como catalisadora para a definição de uma Arquitetura de Sistemas Corporativa (ASC) madura, com alto nível de automação através de generalizações abrangentes. Posicionamos este tipo de solução de software como “horizontal” por resolver problemas comuns a várias verticais de negócio, dentro de um portifólio típico de aplicações.Já o nosso tema deste capítulo, a Metodologia de Desenvolvimento de Sistemas (MDS), se
desenvolverá em torno de práticas e padrões para a construção da parte “vertical” da solução - ou seja, da solução de negócio em si.
O ideal é que uma MDS reconheça o nível de abstração e de generalização disponíveis na ASC, e que a complemente, otimizando práticas de especificação e construção. Este ideal pode não se
manifestar na prática por dois motivos:
o Arquitetura Invisível ou Anêmica. Analistas e/ou desenvolvedores projetando e construindo camadas horizontais de software em aplicações de negócio, simplesmente por insuficiência na padronização e automação em nível da arquitetura.
o Metodologias Invisíveis ou Anêmicas. Metodologias inexistentes (desenvolvimento artesanal, ao sabor das qualidades individuais de cada profissional) ou uso de MDS genéricas mal
contextualizadas que, por exemplo, desconhecem a arquitetura. Discutimos o primeiro motivo no capítulo anterior. Vejamos então o segundo.
O uso de práticas de modelagem, especificação e construção genéricas de mercado (como variantes do Processo Unificado e Design Patterns Java), sem adaptações que as contextualizem para o reconhecimento da Arquitetura de Software Corporativa presente, levam os profissionais a projetarem e a construírem em excesso, com maior esforço e menor eficácia.
Uma sequela típica de MDS desalinhada com ASC são especificações prolixas que não reconhecem os estereótipos da arquitetura e que, por isso, além de serem mais custosas para serem obtidas, comunicam mal.
Para o máximo de resultados, é imprescindível que a Arquitetura de Sistemas Corporativa seja tão
automatizada quanto possível e reconhecida pela Metodologia de Desenvolvimento de Sistemas. Deste modo, analistas e/ou desenvolvedores podem calibrar melhor o nível de abstração de seu trabalho, tanto no projeto quanto na implementação - evitando desperdícios e maximizando o reúso.
Do ponto de vista da especificação, o jCompany traz um módulo chamado jCompany Patterns & Methods, que propõe padrões e práticas de especificações de Casos de Uso, Modelagem de Classes, Processos Ágeis, dentre outros. É um módulo representado por documentação extensa, somente disponível com a licença corporativa do produto.
Do ponto de vista da construção, o jCompany traz roteiros automatizados através do recurso de Cheat-Sheets do Eclipse, além de plugins que geram versões que obedecem a padrões concebidos na
metodologia.
Tal como no caso análogo, da arquitetura, os métodos e padrões propostos pelo jCompany Patterns & Methods devem servir de base para a definição de uma MDS corporativa, devendo ser considerados como “insumos reutilizáveis” para este trabalho.
5
A6
Entendendo a Metodologia
de Desenvolvimento
Especificações baseadas em metodologias genéricas de mercado, mal contextualizadas, são um dos maiores problemas enfrentados pelos modelos Fábricas de Software atuais. Não é incomum que empresas adquiram a sua base de arquitetura de um fabricante e as práticas de especificação de outro – este uso pasteurizado da modelagem de Classes, de Casos de Uso e de padrões de interfaces Web termina por subtrair importantes benefícios que somente uma abordagem sinérgica pode oferecer.
Processos de Desenvolvimento de Sistemas
Vamos abrir uma pequena discussão sobre PDS, neste ponto, a guisa de estimular o uso de práticas modernas que contribuam para o nosso sucesso*.
- Definição
Na Wikipedia, um Processo de Desenvolvimento de Sistemas (PDS) é definido como “a estrutura imposta ao desenvolvimento de um produto de software”.
Uma empresa que queira eliminar “não conformidades” e reforçar “melhores práticas” de produtividade deverá definir atividades, responsabilidades, métodos, ferramentas e padrões para diversas fases do desenvolvimento de sistemas em si e áreas de apoio relacionadas.
Segundo o Processo Unificado [Booch, Jackobson, Rumbaugh 1998], as fases fundamentais de um PDS são:
o Concepção (principalmente Levantamento de Requisitos) o Elaboração (principalmente Projetos Lógico e Físico) o Construção (principalmente Codificação e Testes Unitários)
o Transição (principalmente Testes de Aceitação e Liberação para Produção)
Os frameworks de processo mais pesados e abrangentes irão incluir outras áreas tais como Gerência de Configuração, Garantia da Qualidade de Processo e Produto, Medição e Análise etc., além das áreas “fundamentais”.
A Figura A6.1. Exemplo das fases de um PDS mais abrangente.Figura A6.1 exibe um gráfico com esta visão mais abrangente, utilizado para representar todo o Gerenciamento de Ciclo de Vida de Aplicações (Application Lifecycle Managment – ALM).
Figura A6.1. Exemplo das fases de um PDS mais abrangente.
Por sua complexidade, quase nenhuma empresa define seu PDS inteiramente do zero, já que existem vários frameworks de base nesta área. Alguns exemplos são: o “Processo Unificado (Unified Process - UP)” já citado; e os mais recentes processos ágeis, tais como “SCRUM” e “XP”, em larga popularização. Além destes, podemos citar os “modelos de processo” mais abrangentes, tais como o CMMI, o MPS.Br (no Brasil) e o ISO 15504.
* Esta “pequena” discussão se torna bem mais relevante na medida em que, muitas vezes, a adoção de processos inadequados está na
raiz dos problemas de projeto. Não há solução de produtividade que sobreviva a um PDS modelo “Cascata”, gerenciado com práticas de comunicação primitivas (ex.: formalidades em papel!) e visao ignóbil acerca da natureza peculiar de um projeto de software.
- Metodologia ou Processo?
Neste livro, iremos adotar alguns jargões preferenciais:
o “Metodologia de Desenvolvimento de Sistemas” (MDS) quando quisermos nos referir a um espectro mais restrito de disciplinas, limitado às fases de Concepção, Elaboração, Construção e Transição de um Processo de Desenvolvimento de Sistemas (PDS).
o “Processos de Desenvolvimento de Sistemas” (PDS) quando quisermos nos referir a um espectro maior, englobando áreas adicionais conforme identificadas por frameworks de processo tais como o CMMI, ISO ou MPS.Br. Por exemplo, Gerência de Configuração, Medição e Análise, Garantia da Qualidade de Produto e Processo etc.
o O jargão do Processo Unificado (UP) [Boock, Jacobson, Rumbaugh 1998] quando falarmos em métodos, fases e alguns padrões de especificação.
o A UML - Unified Modeling Language [Pender, Tom] quando o assunto for modelagem e especificação de sistemas.
A escolha destes jargões é meramente por conveniência, já que são os mais difundidos no mercado. Não há nenhuma restrição específica das soluções de desenvolvimento que apresentaremos, com relação ao uso de métodos ágeis, por exemplo, ou quaisquer outras abordagens convencionais.
- Processos Iterativos x Processo em Cascata
Um ponto-chave na adoção de um processo é compreender como ele sugere a distribuição das suas práticas ao longo do tempo. Por este critério podemos classificar um processo como enfatizando um desenvolvimento em “Cascata” (Waterfall Process) ou “Iterativo” (Iterative Process).
Sabemos que Processos em Cascata, apesar de serem os mais comuns em outras engenharias, são piores para o desenvolvimento de Software. Fatos que corroboram esta tese são colecionados desde a década de 80 e gerados até os dias de hoje.
“Praticamente todo livro e artigo em Projeto de Aplicações, nos últimos 15 anos ou mais, tem criticado o desenvolvimento em cascata. (...) Eles funcionam bem quando os requisitos são facilmente garimpados e raramente mudam. Infelizmente, como a tônica é a mudança nos negócios, tais situações são cada vez mais raras.”
Ref. A6.1. Peter Bye e Cris Britton em “IT Architectures and Middleware”. Pág. 207.
Mas, apesar de sua ineficácia ser hoje de um consenso geral, o modelo em cascata é, de forma acidental, ainda o mais utilizado! “Acidental” porque, na prática, tem, muitas vezes, sido utilizado desta forma inconscientemente, especialmente por grandes empresas que trabalham com terceirização de projetos e equipes distribuídas geograficamente.
O Processo Unificado é um exemplo típico de “Processo Iterativo” que muito frequentemente se transforma em “Cascata” quando implantado - e assim é subutilizado no dia a dia por culpa de “customizações” mal feitas.
E qual seriam os motivos desta distorção? Os processos “em cascata” são mais simples de se entender
por serem os mais conhecidos pela humanidade nas engenharias clássicas. Qualquer estudante irá compreender uma analogia dos “Processos de Desenvolvimento de Sistemas” com os “Processos da Engenharia Civil”, por exemplo – simplificação que contribui para manter o atraso cultural nas áreas de TI desde os anos 70.
Este tipo de analogia, perigosamente didática, não expressa de forma apropriada a natureza única do software, um bem “invisível”, “abstrato” e de “simulação” da dinâmica de negócios. É uma natureza que requer um paradigma diferenciado, atualmente melhor representado por métodos Iterativos e Ágeis.
“A noção de ‘requisitos-projeto-implementação’ em cascata é tão intuitivamente correta... O que pode estar errado com ela? Na prática, existem três problemas principais. Primeiro, os usuários finais e de negócio não conhecem seus requisitos, são incapazes de expressá-los com rigor suficiente ou, até pior, têm requisitos contraditórios. Introduzir uma nova aplicação de TI muda o trabalho das pessoas e elas têm dificuldade de visualizar o que é preciso para o novo sistema funcionar.
(...) O segundo problema é a dificuldade de expressar a especificação de uma maneira compreensível e utilizável por ambos, o programador (...) e os patrocinadores do negócio (...)
O terceiro problema é que a divisão de responsabilidades entre requisitos, especificação (projeto) e
implementação leva ao ‘excesso de engenharia’. Isto é particularmente verdadeiro em grandes organizações, onde um grupo especifica requisitos e outro faz o projeto e a implementação.”
Ref. A6.2. Peter Bye e Cris Britton. “IT Architectures and Middleware”. Pág. 206.
Por todos estes motivos, não há hoje estudiosos na área de TI ou nenhum framework de
processo que preconize o modelo “Cascata”. O que existe, porém, são implantações imperfeitas de processos Iterativos como citamos, ressaltando o caso do Processo Unificado. Aplicados desta forma, tais
processos trazem os mesmos resultados medíocres já conhecidos da época da Engenharia da Informação. Como diz o ditado:
“É insensatez querer fazer algo sempre da mesma forma e esperar por resultados diferentes”
Ref. A6.3. Atribuído a Albert Einstein
A Figura A6.2. Diagrama do Processo Unificado, destacando em branco uma iteração.mostra um esquema simplificado com relação à Figura A6.1. Exemplo das fases de um PDS mais abrangente., evidenciando o aspecto iterativo do Processo Unificado.
Figura A6.2. Diagrama do Processo Unificado, destacando em branco uma iteração.
No diagrama clássico do UP, uma iteração é representada graficamente através dos “montinhos”, que sugerem a intensidade da ocorrência de uma determinada disciplina em cada fase.
Note que, na iteração #2 destacada durante a fase de Elaboração, além de “análise” e “projeto”, são esperadas boas quantidades de trabalhos simultâneos de “implementação” (codificação de programas) e inclusive de “testes”! Como fazê-lo em modelos clássicos de fábricas de software?
- Processos Iterativos e Fábricas de Software
Além dos três problemas citados por Peter Bye e Cris Britton, há um quarto problema que podemos acrescentar, certamente de grande peso: As empresas têm decidido por adotar processos “em Cascata” como solução comercial para viabilizar contratos em “preço fechado” para terceirização da fase de Construção, por três motivos:
1. Complexidade da Construção em eBusiness. A fase de Construção tornou-se exponencialmente mais
complexa do que era em gerações passadas, distanciando ainda mais os Analistas de Negócio de um ambiente onde possam prototipar e explorar os resultados de levantamento, aprendendo sobre a solução juntamente com seus usuários.
2. Maior controle contratual para diminuição de custos e riscos. Gestores financeiros anseiam por mais
controle sobre os contratos de TI, visando redução de custos e riscos, e muitas vezes não aceitam desenvolvedores de terceiros alocados ao lado de seus Analistas de Negócio.
3. Melhorar a produtividade via especialização de funções. A mesma complexidade observada no item 1 pode
ser amenizada com pessoal especializado em tecnologias específicas.
Mas o fato é que o modelo contratual de “terceirização em preço fechado” dificulta tremendamente a instauração de um processo verdadeiramente iterativo:
o Exige uma grande visão de projeto antecipada, para efeitos de contratação (Análise “Big-Bang”); o Produz dificuldades contratuais que degradam a adaptabilidade (controles de mudança rigorosos,
que inibem a agilidade);
o Gera problemas sérios de comunicação que embotam a colaboração (analistas “contra” desenvolvedores);
o E, o que é pior, elimina o contexto necessário para se evoluir uma solução da forma ideal, desde a sua Concepção, o que exige graus de programação durante a concepção e de análise de requisito durante a construção – em um cenário de “exploração e adaptação” contínuas.
Como o jCompany pode contribuir, inserido neste contexto?
1. Complexidade da Construção em eBusiness. Neste sentido, o jCompany poderá ajudar decisivamente, pois
as práticas de alta produtividade ensinadas neste livro viabilizam o retorno de uma “prototipação com
aproveitamento posterior do código”, mesmo se tratando de aplicações complexas de eBusiness utilizando Java EE e MVC.
Se há um cenário de requisitos instáveis e todos os outros elementos que requerem um desenvolvimento iterativo estão presentes, os Analistas de Negócio ou Projetistas treinados conseguirão usar o jCompany mesmo em fases iniciais do processo (Concepção ou Elaboração) para realizar “prototipações-chave” para elicitação de requisitos, junto aos usuários. Isso porque não precisarão de conhecimentos profundos em Java, Java EE, HTML, Javascript, CSS etc., para apresentar resultados com razoável profundidade.
Esta é uma possibilidade que deve ser explorada e pode ser decisiva para o sucesso de um grande número de projetos de TI de natureza desafiadora!
2. Maior controle contratual para diminuição de custos e riscos. Este é um mito. Não há contrato que
compense os prejuízos que um processo inadequado, em “Cascata”, possa produzir. E este processo inadequado, por si, introduz e anaboliza riscos, como muitas empresas continuam constatando. A produtividade e qualidade liberadas pelo jCompany possibilitam entregas de produto “apresentável aos usuários” em iterações de semanas, não meses. Eis aí uma fórmula que, comprovadamente, contribui para reduzir custo e riscos.
3. Melhorar a produtividade via especialização. Quanto mais se generaliza soluções repetitivas para
arquiteturas ricas e utilizam-se gerações de código suplementares, menos trabalho braçal, típicos de “manufatura”, restam aos Desenvolvedores.
Em jCompany, restam para os desenvolvedores mais atividades de “projeto do código fonte”, ou seja, trabalho inteligente; e menos atividades do tipo “replicar a fôrma de código”, ou seja, trabalho braçal. Neste cenário, seria mais apropriado chamar os desenvolvedores de “co-projetistas” ou “projetistas de código” – e não de
implementadores. E como trabalham em mais alto nível, a aproximação entre desenvolvedores jCompany (“Projetistas de Código”) e Analistas de Negócio (“Projetistas de Caso de Uso“) deve ser estimulada, podendo inclusive ser decisiva para o sucesso de projetos complexos.
- Práticas para Especificação - Projeto Lógico e Físico
O módulo jCompany Patterns & Methods traz material que discute, mais a fundo, sugestões para a fase de Elaboração (Projetos Lógico e Físico), dando subsídios para a criação de práticas de modelagem eficazes que comuniquem bem e produzem modelos que se preservem atualizados ao longo do ciclo de vida de uma aplicação.
Algumas ações sugeridas são:
o Automação bidirecional, com geração de classes a partir de modelos e de modelos a partir de classes;
o A eliminação de “hiatos” de modelagem (várias camadas de modelos e de transformações MDA desnecessárias);
o E o estabelecimento de estereótipos com base na UML, que produzam uma comunicação direta com relação a abstrações da arquitetura, padrões e práticas de construção do jCompany. Neste capítulo e nos próximos, iremos apenas apresentar conceitos básicos suficientes para entendermos as especificações que encontraremos nos tutoriais do módulo B.
- Práticas para Construção Java EE
Esta é a área principal de foco do jCompany. Sua produtividade diferenciada advém, principalmente, da padronização de soluções em um patamar de abstração mais alto que qualquer outro framework ou ferramenta de desenvolvimento.
Os padrões em nível de “Caso de Uso” automatizados pelo jCompany permitem ao desenvolvedor, em questão de minutos - não horas ou dias, produzir soluções MVC2-P completas e flexíveis para um bom percentual de problemas típicos de aplicações comerciais com qualidade de produção!
E esta alegação não é pouca coisa: se somarmos o resultado de todos tutoriais encontrados nos livros de Hibernate/JPA, JSF, JBoss Seam, Spring e Eclipse, por exemplo, que fazem parte de nossa
“referência bibliográfica”, não obteremos um resultado funcional que chegue à metade do que produziremos neste livro.
Este resultado, inicialmente, deve-se ao fato de o jCompany trabalhar reutilizando os benefícios da maioria destes produtos. Mas, além disso, também se deve ao elevado nível de especializações e padronizações presentes nas diversas dimensões de arquitetura, métodos, padrões e técnicas de automação.
Mantendo Agregações de Objetos
- Agregações de Objetos
Entender o conceito de “Agregação de Objetos” é fundamental para a introdução aos Casos de Uso Padrões do jCompany que veremos inicialmente. Portanto, iremos recapitular este conceito de OO, tomando como base o Modelo de Classes da Figura A6.3.
Figura A6.3. Modelo de Classe de Exemplo*.
O trecho acima é um recorte de um modelo maior que utilizaremos neste livro, representando um grafo cujos vértices são “classes” e as arestas são “associações”. Chamaremos a este recorte, portanto, de “Grafo de Classes”, no qual podemos identificar 3 vértices e 2 arestas.
o 3 (três) classes: Uf, UnidadeOrganizacional e Endereco.
o 1 (uma) agregação de classes: Entre UnidadeOrganizacional e Endereco. o 1 (uma) associação Simples: Entre Endereco e Uf.
Estas classes definem estruturas possíveis de dados, mas são os objetos ou “instâncias destas classes” que irão conter os dados em si durante a execução de uma aplicação e compor os formulários de nossa aplicação visíveis para o usuário, que representam “documentos eletrônicos de negócio”.
Tal como no grafo de classes, estes objetos se relacionam conforme a estrutura definida pelas classes, variando conforme o “estado” (situação corrente) da aplicação.
A Figura A6.4 representa um “Grafo de Objetos” hipotético para uma possível configuração de objetos, em um determinado momento de execução da aplicação. Podemos compreender este diagrama, de forma análoga, como um “Grafo de Objetos”, que representa instâncias do “Grafo de Classes” que o define.
* Este diagrama traz um mix de modelagem diferente dos tradicionais. Perceba que usa tipos Java juntamente com restrições e
operações em nível conceitual. Os “tamanhos” (multiplicidade) de propriedades também são atípicos, além de diversos estereótipos. Este tipo de padrão é descrito na documentação do jCompany Patterns & Methods
Figura A6.4. Grafo de Objetos hipotético em um determinado “estado” da aplicação.
Na Figura A6.4, seccionamos o único grafo formado por todo o modelo em três subgrafos, para fins didáticos, porque normalmente são estes subgrafos que compõem a estrutura de um documento típico de negócio (ou formulário da aplicação), como pode ser conferido na Figura A6.5.
- Grafos de Objetos x Agregações de Objetos
Quando falamos em “Manutenção do Ciclo de Vida” é comum visualizarmos inicialmente um formulário, digamos, do tipo “Manter Funcionário”, mantendo dados de um único objeto.
Mas com uma aplicação real em mãos descobriremos que “Manutenções de Ciclo de Vida” típicas não raramente lidam com grafos de cinco a dez objetos de uma só vez, modificando alguns e consultando outros. Tais grafos podem envolver ainda arquivos anexados, auditoria rígida (imagem de dados alterados) e outras sofisticações em um cenário bem mais complexo que nossa “abstração” inicial. Vamos pegar um exemplo bem simples:
Quando delimitamos “grafos” e “agregações” de objetos na Figura A6.4, a hipótese é a de que estamos realizando manutenção sobre objetos de “UnidadeOrganizacional” (Departamentos, como rotulados no formulário abaixo) e “Endereco”, e consultando objetos de “UF”. Veja exemplo no formulário da Figura A6.5.
Figura A6.5. Exemplo de formulário possível para manter o esquema de objetos da figura 4.
Aqui retornamos ao nosso ponto inicial para estabelecermos algumas convenções de nomenclatura e modelagem OO importantes:
o Formulários do negócio lidam não com um objeto, mas com um “Grafo de Objetos”. o Já um Grafo de Objetos é um corte do Modelo de Objetos envolvido em uma transação,
exemplificados na Figura A6.4 pelos “Subgrafos 1, 2 e 3”.
o Por sua vez, uma Agregação de Objetos é aquele subconjunto de objetos do Grafo, modificados simultaneamente, exemplificados na Figura A6.4 pelas “Agregações 1, 2 e 3”. o As classes “UnidadeOrganizacional” e “Endereco” são partes de uma mesma agregação
de classes/objetos, mas não “Uf”.
o No entanto, “Uf” participa do mesmo Grafo de Objetos utilizado no formulário de “Manutenção de Departamentos” (“UnidadeOrgacional”).
Esta compreensão nos ajudará a especificar de forma simples e objetiva um grande número de Casos de Uso, bem comuns.
- Automatizando a Manutenção de Agregações de Objetos
“Uma Agregação é um cluster de objetos associados que nós tratamos como uma unidade para o propósito de mudanças de dados. Cada Agregação tem uma raiz e um contorno. O contorno define o que está dentro da Agregação. A raiz é uma única Entidade, dentre as contidas na Agregação, e a única para a qual objetos externos à agregação podem manter referências”
Ref. A6.4. Eric Evans em Domain-Driven Design [Evans, Eric 2004]. Págs. 126-127.
O estereótipo “raiz agregação”, utilizado na classe “UnidadeOrganizacional” da Figura A6.3 e a linha pontilhada que delineia o contorno da Agregação foram baseados em sugestões de Evans. Esta e outras convenções de modelagem são discutidas no módulo jCompany Patterns & Methods.
Existem diversos comportamentos típicos que caracterizam e devem ser assegurados para uma Agregação, sendo alguns: “ao excluir-se um objeto raiz, deve-se excluir toda a Agregação”, “deve-se reforçar restrições invariáveis para a Agregação como um todo”. Vários destes comportamentos são expostos em [Evans, Eric 2004] e fogem ao nosso escopo atual de discussão. Mas há uma sugestão bastante pertinente de Evans, que desejamos citar:
“Pode ser de grande ajuda ter um framework técnico que permita a você declarar Agregações e então automaticamente garantir suas restrições. Sem este apoio, a equipe deve ter a autodisciplina para codificar consistentemente com as regras da Agregação”
Ref. A6.5. Eric Evans em Domain-Driven Design [Evans, Eric 2004]. Pág. 129.
Esta é uma das estratégias que o jCompany adota e realiza de forma bastante extensiva e interessante. O jCompany permite que declaremos em seus metadados, não somente a estrutura da Agregação principal, composta das classes que sofrem alterações em conjunto, como também todo o Grafo de classes participante, incluindo as classes de consulta. A partir daí, padroniza soluções e as generaliza completamente em todas as camadas MVC-P, ao ponto de dispensar totalmente o uso de código procedimental Java até um estágio avançado.
Além da parte procedimental, a solução generalizada para “Manutenção de Agregações” do jCompany ainda inclui padrões na camada Visão, produzindo Interfaces com o Usuário com formulário único, por Agregação*. Deste modo, os formulários refletem de forma direta os “documentos de negócio” com
ganhos tanto em usabilidade quanto em performance e escalabilidade!
Figura A6.6. Formulário único que mantém a Agregação “Funcionario -> Dependente -> Hist. Profissional”.
*Ao quebrar, sem necessidade, a manutenção de uma Agregação em vários “formulários de CRUD” do tipo “mantém um objeto da
agregação por vez”, exige-se do usuário que navegue por várias páginas, provocando dezenas de transmissões na rede e requisições ao App Server desnecessárias (muitas vezes até transações de SGBD). Esta abordagem de “Web-Design” é uma verdadeira abominação para aplicações corporativas multi-usuário, com entrada de dados massiva.
- Generalizando Manutenções em Arquitetura MVC
Além de lidar com Agregações complexas e produzir formulários com ergonomias apropriadas, outro complicador para generalização das Manutenções de Ciclo de Vida é fazê-la respeitando-se a arquitetura MVC.
Em Cliente/Servidor, fazíamos um CRUD de forma muito simples, ligando campos de janelas a colunas de tabelas no Banco de Dados. Isso ainda é possível em Java EE (e muitas vezes exemplificado até em livros recentes do JSF ou JBoss Seam, por exemplo), mas o fato é que não queremos retroceder nesta área: a arquitetura MVC é hoje aceita como “pauta mínima” de arquitetura.
O jCompany realiza um trabalho de generalização em todas as camadas MVC2-P para automatizar o resultado de um Caso de Uso por completo (por isso o framework é chamado de Full Stack), enquanto mantém o respeito a esta arquitetura.
Figura A6.7. Soluções generalizadas em todas as camadas MVC-P.
Casos de Uso Padrões do jCompany
- Casos de Uso com cenários similares
Alistair Cockburn, em seu livro “Escrevendo Casos de Uso Eficazes” [Cockburn, Alistair. 2003], discute o que chama de “Casos de Uso CRUD” e também “Casos de Uso Parametrizados”.
o Os “Casos de Uso CRUD” se referem à manutenção de ciclo de vida de documentos do negócio, englobando funções de criação, recuperação, atualização e exclusão (C-Create, R-Retrieve, U-Update e D-Delete) através de cenários que pouco ou nada variam de documento para documento.
o Já os “Casos de Uso Parametrizados” se referem às outras situações recorrentes e que poderiam levar a uma proliferação de cenários “quase idênticos”, onde o melhor exemplo são consultas para seleção de documentos do tipo “Encontrar um Cliente”, normalmente envolvendo uma entrada com amostra de dados e subsequente pesquisa de relação resultante que atende aos critérios.
Tanto no primeiro quanto no segundo caso, os “cenários” dos Casos de Uso são repetitivos. O que irá variar serão os documentos especificamente adotados em cada caso. Portanto, para evitar esta redundância de especificação, propõe Cockburn:
“Devemos criar um caso de uso parametrizado, que funcione como um apelido para cada um destes itens. Escolhemos chamar esse caso de uso de Encontrar um <Qualquer>. (...)”
Ref. A6.6. Alistair Cockburn em “Escrevendo Casos de Uso Eficazes”. Pág. 149.
Em seguida, Cockburn sugere que se definam somente as diferenças de cenários (argumentos e
operadores a serem utilizados para pesquisa, campos retornados etc.), em Subcasos de Uso, deste modo promovendo a prática da “Especificação por Exceção”.
Prosseguindo em seu exemplo sobre os Casos de Uso Parametrizados:
“O comportamento de pesquisa comum é localizado e escrito apenas uma vez. A consistência entre
mecanismos de procura é garantida, (...). De fato, a equipe de implementação foi encorajada a dar apenas uma especificação para seu mecanismo de pesquisa (...)”
O que Alistair Cockburn sugere são dicas para se eliminar o trabalho de especificação repetitiva que estas duas categorias de Caso de Uso tendem a produzir, e é por esta trilha que o jCompany caminha. Não somente identificando com mais detalhes estes Casos de Uso Padrões no jCompany Patterns &
Methods, como provendo generalizações avançadas via jCompany FS Framework e, por fim, gerando artefatos específicos para cada camada MVC-P, via jCompany IDE.
o No jCompany, esta primeira categoria de “Casos de Uso CRUD” é chamada, de forma mais extensa, de “Casos de Uso Padrões para Manutenção do Ciclo de Vida de Agregações de Objetos” ou, resumidamente, de “Padrões para Manutenção”.
o O jCompany também padroniza e atende com implementações genéricas os “Casos de Uso Parametrizados”, chamados de “Casos de Uso Padrões para Exibição de Coleções de Agregações” (Ex.: seleções, consultas e relatórios) ou, resumidamente, “Padrões de Exibição”. Neste caso, através de simples declarações de argumentos e operadores, o jCompany irá realizar um QBE (Query By Example) MVC-P, dispensando codificação Java.
- Padrões para Manutenção
A produtividade nas manutenções é obtida através do uso dos Padrões de Caso de Uso relacionados na Figura A6.8.
Figura A6.8. Casos de Uso Padrões para Manutenção de Ciclo de Vida.
A tabela a seguir resume o objetivo de cada Caso de Uso Padrão, que serão detalhados ao longo dos próximos capítulos quando estaremos implementando efetivamente vários deles.
Casos de Uso Padrões de Manutenção
Primários Representam as manutenções mais comuns e independentes.
Manter Classe Este Caso de Uso prevê a manutenção de todos os objetos de uma classe, de uma só vez. Por isso, somente deve ser utilizado em classes com poucos objetos.
Manter Agregação Simples Este Caso de Uso prevê a manutenção de uma “Agregação de Objetos Simples”, que não envolva composição do tipo Mestre-Detalhe e variantes.
Manter Agregação
Mestre/Detalhe Este Caso de Uso prevê a manutenção de uma “Agregação de Objetos” que inclua uma composição do tipo Mestre-Detalhe. Manter Agregação
Mestre/Detalhe/SubDetalhe Este Caso de Uso prevê a manutenção de uma “Agregação de Objetos” que inclua uma composição do tipo Mestre-Detalhe-SubDetalhe.
Manter Coleção
Modalidade A Este Caso de Uso prevê a manutenção de um “Coleção de Objetos” de uma só vez, filtrados de uma classe mas que necessariamente não referenciem objetos pré-existentes.
Secundários Representam as manutenções complementares às primárias, que requeiram que classes raiz já existam e tenham sido mantidas por outros padrões anteriormente.
Manter Coleção
Modalidade B Este Caso de Uso prevê a manutenção de um “Coleção de Objetos” de uma só vez, filtrados de uma classe e que partem da seleção de um objeto pré-criado, referenciado pela coleção de objetos selecionada.
Manter Agregação
Consulta-Mestre/Mantém-Detalhe Este Caso de Uso prevê a manutenção de uma “Agregação de Objetos” que inclua uma composição do tipo Mestre-Detalhe, onde o Mestre (raiz da agregação) já tenha sido incluído por outro Caso de Uso Padrão.
Manter Agregação Consulta- Mestre/Mantém-Detalhe-Subdetalhe
Este Caso de Uso prevê a manutenção de uma “Agregação de Objetos” que inclua uma composição do tipo Mestre-Detalhe-Subdetalhe, onde o Mestre (raiz da agregação) já tenha sido incluído por outro Caso de Uso Padrão.
Casos de Uso Padrões de Manutenção
Da Aplicação Representam Casos de Uso que não são do negócio necessariamente, mas que são comuns ao se criar uma aplicação. Normalmente ocorrem “um de cada por aplicação”.
Manter Preferência de Aplicação Este Caso de Uso prevê a manutenção de preferências globais do responsável (administrador) pela aplicação. Também conhecidos como parâmetros globais.
Manter Preferência de Usuário
(para a Aplicação) Este Caso de Uso prevê a manutenção de preferências de cada usuário para a aplicação, podendo este registrar opções de personalização de uso ou outras que se façam necessárias.
- Padrões para Exibição (Consulta e Impressão)
Para exibição de informações, o jCompany também prevê dois Casos de Uso Padrões, exibidos na Figura A6.9.
Figura A6.9. Casos de Uso Padrões para Exibição. Casos de Uso Padrões de Exibição
Consultar Objetos Este Caso de Uso prevê a consulta em formato não otimizado para impressão (HTML, sem quebras) de coleções de grafos contendo informações de diversos objetos.
Consultar/Imprimir
Objetos Este Caso de Uso prevê a consulta em formato otimizado para impressão (PDF, com quebras) de coleções de grafos contendo informações de diversos objetos.
Subcasos de Uso Padrões do jCompany
Como vimos, a padronização em nível de Caso de Uso é um dos grandes alcances do jCompany. Neste nível, o padrão resulta não em uma solução técnica, mas em um valor tangível para o negócio. Por isso, podemos chamá-lo de “padrão de última milha”.
Descendo um pouco mais em nível de detalhe, encontraremos variações típicas dos Casos de Uso Padrões que não podem ser utilizadas de forma isolada, mas são padronizadas pelo jCompany para compor cenários mais complexos. Estas variações podem ser consideradas Subcasos de Uso, como chamados por Alistair Cockburn [Cockburn, Alistair. 2003], se subdividindo nas duas categorias típicas de “Inclusão” (Include) e “Extensão” (Extend).
- Subcasos de Uso Padrões para Inclusão
Os Subcasos de Uso Padrões para Inclusão são aqueles que fazem parte de cenários principais e que ocorrem de maneira “síncrona”, frequentemente exemplificados como similares a “sub-rotinas”, reutilizadas por vários Casos de Uso.
A Figura A6.10 ilustra os diversos Subcasos de Uso Padrões de Inclusão do jCompany, relevantes para os Casos de Uso Padrões de Manutenção.
Figura A6.10. Subcasos de Uso Padrões para Inclusão. Subcasos de Uso Padrões para Inclusão
Inclui Exclusão Lógica Este Subcaso de Uso provê cenário adicional para a exclusão, que deixa de ser física (eliminação da agregação) para se tornar uma alteração de propriedade padrão “sitHistoricoPlc” de “A” (Ativo) para “I” (Inativo). Agregações onde sitHistoricoPlc=”I” são então consideradas excluídas para o ponto de vista de usuários.
Inclui Auditoria Rígida Este Subcaso de Uso provê cenário adicional para registrar objetos contendo “imagens” de dados alterados, incluídos ou excluídos em outras classes “espelho”, para efeitos de auditoria.
Inclui Auditoria
Recursiva Obs.: somente disponível em versões anteriores do jCompany (3.x).
Inclui Pesquisa
Paginada Este Subcaso de Uso provê cenários adicionais que alteram a pesquisa de coleções contendo grafos de objetos para evitar que traga registros em demasiado em seleções de objeto visando edição para manutenção, limitando a quantidade por página.
Inclui Arquivo
Anexado Este Subcaso de Uso provê cenários adicionais que permitem a anexação (upload) de arquivos e sua recuperação (download) juntamente com a agregação principal.
Inclui Aprovação Obs.: somente disponível em versões anteriores do jCompany (3.x). Recomenda-se o jCompany Extension para BPMS (BPMN 2.0) para fins de Workflow (Fluxos de Aprovação)
- Subcasos de Uso Padrões para Extensão
Um outro tipo de reúso padronizado pelo jCompany abaixo do nível de Caso de Uso se dá com
extensões, que são opções disponíveis para acionamento “assíncrono” pelo usuário e que, portanto, não participam do cenário principal do Caso de Uso.
A Figura A6.11 ilustra os diversos Subcasos de Uso Padrões de Extensão do jCompany.
Figura A6.11. Subcasos de Uso Padrões para Extensão. Subcasos de Uso Padrões para Extensão
Extensão Exportação Este Subcaso de Uso provê cenários alternativos (que podem ou não ser acionados pelo usuário, após uma pesquisa de seleção ou consulta) para exportação dos dados resultantes para formatos tais como CSV ou XML. Obs.: Somente disponível em versões anteriores do jCompany (em revisão para JSF 2.0)
Extensão Assistente Este Subcaso de Uso provê cenários alternativos (que podem ou não ser acionados pelo usuário, durante a entrada de dados) para acionar diálogos de assistente de entrada de dados, passo a passo (Wizards).
Obs.: Somente disponível em versões anteriores do jCompany (em revisão para JSF 2.0)
Extensão Exploração
de Dados Este Subcaso de Uso provê cenários alternativos que podem ou não ser acionados pelo usuário durante a entrada de dados para que uma treeview seja exibida contendo uma hierarquia de dados definida pelo
desenvolvedor, que pode ser utilizada como um menu “alternativo”, orientado a dados, similar ao Explorador do Windows.
Extensão Detalhe por
Demanda Este Subcaso de Uso provê cenários alternativos que podem ou não ser acionados pelo usuário, provocando a recuperação de coleções de objetos de detalhe quando são declarados como “por demanda”.
Introdução ao Projeto Lógico do “RH Tutorial”
A melhor forma de se conhecer os Padrões de Caso de Uso do jCompany é utilizá-los na prática. É o que faremos nos capítulos de tutoriais que se seguirão, no módulo B. Neste capítulo, vamos apenas
apresentar os Modelos de Casos de Uso de Contexto para a aplicação que iremos desenvolver.
A aplicação “RH Tutorial” é uma simplificação de uma automação de RH, área de negócio escolhida por trazer conceitos básicos bem familiares aos trabalhadores em geral e que, por este motivo, não exigirão maiores explicações sobre o Domínio*.
*Exposições sobre um domínio complexo seriam monótonas em nosso contexto atual. Por isso, nós não iremos explicar em detalhes
- Casos de Uso de Contexto em Nível Resumido para “RH Tutorial”
Por hora, vamos entender nosso escopo. A Figura A6.12 mostra um Diagrama de Casos de Uso em Nível Resumido, elaborado em tempo de planejamento, representando nosso desejo de realizar duas versões para a aplicação que desenvolveremos neste livro e alguns Atores principais.
Como representa o diagrama, pretendemos ter duas versões de nosso sistema de exemplo, sendo que primeira será desenvolvida nos módulos A ao F (Versão 1.0), e a segunda em volumes subsequentes deste livro.
Figura A6.12. Diagrama de Caso de Uso em escopo de Planejamento (Negócio)
- Casos de Uso de Contexto em Nível de Objetivos do Usuário – Versão 1.0
O Diagrama de Casos de Uso de Contexto da Versão 1.0, apresentado na Figura A6.13, descreve todos os Casos de Uso que desenvolveremos nos primeiros módulos.
São os seguintes os objetivos dos Atores em cada Caso de Uso da Figura 12:
Ator Número Caso de Uso Objetivo
Administrador UC001 Manter Estrutura Organizacional Incluir e manter atualizadas informações (nome e endereço) de Unidades Organizacionais da empresa, incluindo matriz e filiais. UC008 Auditar Operações Verificar alterações
realizadas no cadastro de Funcionários e seus dados, para fins de segurança. RH UC002 Registrar Funcionários Registrar e manter
atualizados os funcionários, na medida em que são contratados.
UC003 Consultar/Imprimir Ficha
Funcional Consultar uma ficha completa incluindo dados de Funcionário, Dependentes, Histórico Funcional e Lotação em qualidade boa também para impressão. FolhaPagamento UC004 Registrar Proventos e Descontos Registrar débitos e créditos
para o Funcionário ao longo do mês.
UC005 Calcular Folha de Pagamento Realizar cálculos de pagamentos mensais, considerando-se salário base atual, proventos e
descontos. UC006 Consultar/Imprimir Folha de
Pagamentos Realizar consulta com qualidade de impressão com relação de todos os funcionários e salários, com quebra e totalizações por lotação.
- Casos de Uso de Contexto da Aplicação – Versão 2.0
A versão 2.0 contemplará integrações típicas da realidade corporativa em diversos cenários, como ilustra a Figura A6.14. Estes casos de uso utilizam tecnologias de WOA (RESTFull Services), Dashboards e outras.
São os seguintes os objetivos dos Atores para a Versão 2.0:
Ator Número Caso de Uso Objetivo
Anônimo UC009 Consultar Estrutura
Organizacional Usuários anônimos, via Web-Site, devem ser capazes de consultar dados da Estrutura Organizacional, tais como Nome e Endereço de Matriz e Filiais.
Chefia UC010 Consultar Perfil de Equipe Usuários em cargos de chefia devem poder sindicalizar conteúdos em formato RSS/RDF contendo a relação de sua equipe de subordinados imediatos. Sistema SOA UC011 Consultar Nível de Salário
de Funcionário Serviço que deve permitir consulta de nível salarial, para um funcionário.
UC012 Registrar Promoção de
Funcionário Serviço que deve realizar a promoção de um Funcionário, inclusive consumindo o serviço UC0011.
Executivo UC013 Consultar Gráfico Total de Despesa Folha Pagto por Unidade Organizacional
Consultar gráfico que possa ser utilizado em Dashboard baseado em Gadgets.
Contabilidade
Externa UC014 Gerar arquivo XML com resultados de cálculo de Folha
Receber por email os dados de cálculo de Folha em anexo, criptografados.
Esta segunda versão nos possibilitará a implementação de integrações típicas de eBusiness, tais como: o Integração de determinadas transações da aplicação em Web-Sites (para acesso anônimo),
usando sindicalização de HTML simples.
o Integração com Portais Corporativos via exportação de dados para XML, usando sindicalização RDF/RSS.
o Integração envolvendo serviço e consumo de Web-Services (REST preferencialmente) para estratégias de SOA.
o Integração com padrões diversos
o Integração através de Gadgets para uso em Dashboard privados (MyPortal) ou comunitários (iGoogle)
o Integração via envio de email com arquivo anexado para usuários desconectados (off-line)
Níveis de Casos de Uso
- Introdução
O leitor mais interessado em Casos de Uso pode ter reparado que o diagrama da Figura A6.12 encerra os nomes dos Casos de Uso com “+”, enquanto os demais encerram com “!”. Além disso, a coloração é branca para os Casos de Uso da Figura A6.12 e azulada para os demais.
Esta notação é recomendada por Alistair Cockbur [Cockburn, Alistair. 2003] e diz respeito ao Nível de Objetivo do Caso de Uso. São os seguintes os níveis principais sugeridos:
Nível Cor Símbolo
Sufixo Significado
Resumo
(Céu) Branca + São Casos de Uso utilizados para representação do contexto maior da aplicação, agrupando objetivos do usuário.
Objetivos do Usuário (Nível do Mar)
Azul Clara ! São Casos de Uso de maior interesse que realizam um objetivo concreto do usuário, correspondentes ao “processo de negócio elementar”.
Sub-funções (Fundo do Mar)
Azul Escuro - São Casos de Uso que representam atividades menores do usuário dentro de um Caso de Uso objetivo. (Na UML atualizada, são Casos de Uso estereotipados como Colaborações, estando em
um nível mais próximo da implementação)
Para uma discussão sobre a importância de se destacar “Níveis de Objetivo” nos Casos de Uso, sugerimos a referência [Cockburn, Alistair. 2003]. Para nós, esta segmentação é especialmente importante porque desejamos partir da especificação para a implementação de modo claro e automatizado.
Neste sentido, temos que distinguir bem entre este “Nível de Objetivo” e o “Nível de Implementação”: o Para o Projeto Lógico em si, o importante é uma boa marcação do Nível de Objetivo nos
modelos de Caso de Uso, nível mais importante para o usuário.
o Para o Projeto Físico (e rastreamento com a implementação), o mais importante é a
diferenciação de um Caso de Uso como “Concreto”, para deixar claro que ele está em Nível de Implementação - especialmente quando já existam padrões definidos na Arquitetura com suporte direto para sua implementação, que é o nosso caso*.
Um bom exemplo sobre a distinção entre estes níveis pode ser obtido através da Figura A6.13. Todos os Casos de Uso deste diagrama estão em Nível de Objetivo do Usuário (!), mas nem todos são “Concretos”! O “UC001 Manter Estrutura Organizacional!” é modelado como “Abstrato", o que percebemos pelo texto em itálico, padrão de notação UML para estes casos.
- Analisando Níveis em “UC001 Manter Estrutura Organizacional!”
O Caso de Uso UC001 é modelado como “Abstrato” porque, muito embora esteja no Nível de Objetivo do usuário†, ele não possui um padrão de implementação que o mapeie para uma solução
diretamente. Portanto, ele não está no Nível de Implementação.
A Figura A6.15 mostra um detalhamento do Caso de Uso “UC001 Manter Estrutura Organizacional”, composto por dois Casos de Uso “em Nível de Implementação” e mostrados com notação e cor sugeridos por Alistair Cockburn, para “abaixo do nível do mar”. Neste nível, são dois Casos de Uso “Concretos” e para cada um deles temos soluções de implementação padronizadas definidas através dos estereótipos, em cada um.
Nota: Os dois Casos de Uso abaixo utilizarão padrões de implementação distintos para manter o ciclo de vida de objetos do Modelo de Classes da Figura A6.3: O “UC001.1” manterá o ciclo de vida das Unidades da Federação (UF), e o “UC001.2” manterá o ciclo de vida das Unidades Organizacionais, seu endereço e associações, inclusive com UF.
Figura A6.15. Casos de Uso “Concretos” em Nível de Implementação.
Aqui, vale uma consideração: Esta especificação somente é válida porque, em nosso exemplo, estamos supondo que a classe de UF não seja “de uso corporativo”. Em nossa hipótese, de forma simplificada, ela
* Uma outra dica para percebermos que estamos em Nível de Implementação é o detalhamento do Caso de Uso. Abaixo de um nível
Padrão de Implementação teremos forçosamente que introduzir conceitos de Realizações de Caso de Uso via Colaborações do Projeto Físico, que veremos mais adiante.
† Ou seja, o resultado de uso relevante para usuários é definir toda a Estrutura Organizacional, composta de Matriz, Filiais, seus
serve apenas ao propósito de normalizar dados para o cadastro de Endereços de Unidades Organizacionais.
Como “Manter UF-“ não é considerado com um “Objetivo do Usuário” por si, algumas consequências podem acontecer em nossa aplicação como, por exemplo, a classe “Uf” pode conter instâncias de UFs somente para as Unidades Organizacionais existentes*.
- Analisando Níveis em “UC002 Registrar Funcionários!”
Se agora analisarmos o Caso de Uso UC002 veremos que o mesmo, coincidentemente, está tanto no Nível de Objetivo do Usuário quanto no Nível de Implementação. Sabemos disso porque ele está com exclamação em azul claro (!) e não está representado com título em itálico.
E isso também é verdade para todos os demais Casos de Uso, que iremos desenvolver ao longo dos tutoriais deste livro.
- Projeto Lógico para “UC001.1 Manter UF-”
O primeiro Caso de Uso que desenvolveremos será o “UC001.1”. Devido à existência de um padrão para este Caso de Uso, ele poderá ser especificado, com precisão, simplesmente como o diagrama da Figura A6.16.
Figura A6.16. Especificação Lógica “por exceção”, reutilizando o padrão de implementação.
Note que a especificação acima ainda independe de implementarmos ou não em jCompany! Portanto, ela ainda está em nível lógico, sendo suficiente para se especificar para qualquer outro contexto tecnológico de desenvolvimento que defina padrões neste nível.
Outras observações importantes:
o A representação acima é apenas uma “Visão Estrutural”. A “Visão Comportamental”, representada tipicamente pelos Cenários de Caso de Uso ou Diagramas de Sequência, nem precisa ser representada, já que não identificamos nenhuma variação importante de comportamento com relação ao comportamento do Caso de Uso Padrão “Manter Classe”†.
o O estereótipo <<plcManClasse>> indica que o padrão do Caso de Uso “Manter UF-“ é o “Manter Classe” e que, portanto, nosso Caso de Uso deve herdar os cenários deste padrão. No repositório da ferramenta CASE existe um relacionamento de herança entre os Casos de Uso para facilitar rastreabilidade, não representado em nosso diagrama.
o Restrições invariáveis (que não mudam, conforme os Casos de Uso) estão
representadas junto às Entidades de Domínio. Deste modo, ficam encapsuladas, sendo
* Este é um cenário apenas didático. No mundo real, para que uma empresa evite tabelas redundantes de “UF”, o Caso de Uso
“UC001.1 – Manter UF-“ teria que ser promovido para “UC001 - Manter UF!”, em Nível do Objetivo do Usuário.
†Para facilitar a compreensão deste padrão de modelagem foram inseridos dois capítulos do jCompany Patterns & Methods, no
Apêndice A deste livro. Consulte-os, por exemplo, para conhecer a descrição dos cenários para o Caso de Uso para o padrão “Manter Classe”.
mais bem entendidas e naturalmente reutilizadas. Uma “decoração” importante foi a
representação de tamanhos nas propriedades, o que torna também a representação suficiente para o uso de mapeamento Objeto-Relacional e definição de tamanhos padrões para campos correspondentes na interface.
o Mesmo a especificação da Interface com o Usuário está sucinta, mas suficiente, já que
navegação, leiautes e barras de botões são todos padronizados na Arquitetura de Software, não apresentando variações em nosso caso.
Introdução ao Projeto Físico do “RH Tutorial”
Incluiremos no Projeto Físico qualquer modelo ou abstração que possua uma dependência de nosso ambiente de implementação, neste caso composto por tecnologias Java EE 6 Open Source integradas e especializadas pelo jCompany.
Até aqui, como vimos, nossas abstrações para generalizações de Casos de Uso de Manutenção de Ciclo de Vida e Consulta de Agregações, além de Subcasos de Uso de Inclusão e Extensão, podem ser aplicados a qualquer tecnologia.
Iremos notar que, devido à profundidade e abrangência da Arquitetura de Software proposta no
jCompany, que padroniza e traz generalidades para todas as camadas MVC2-P, conseguiremos trabalhar com um alto nível de abstração mesmo no Projeto Físico.
- Colaborações Padrões do jCompany
Além de padrões no nível de Caso de Uso, o jCompany Patterns & Methods traz padrões para
Realizações dos Casos de Uso Padrões. Estas realizações são representadas por “Colaborações” que, na UML 2.x, são representadas como elipses com borda tracejada, como na Figura A6.17.
Figura A6.17. Projeto Físico para Caso de Uso “UC001.1 Manter UF-“.
Perceba que o diagrama acima é um Projeto Físico suficiente para nosso Caso de Uso Padrão “Manter UF-". É um exemplo minimalista de Projeto “por Exceção”, que somente define uma Colaboração padrão “plcTabular” e inclui ainda o estereótipo no formulário, indicando para seguir o padrão de formulário para a Colaboração, em tecnologia XHTML.
É uma especificação minimalista, tão simples quanto possível - poderíamos inclusive não diagramá-la, a exceção do formulário. De fato, quando não há muita diferenciação com relação aos padrões, somente temos que projetar “o reúso”, evitando repetições de cenários na especificação.
Importante: No caso acima, definimos o nome da Colaboração coincidente com o nome da URL, que segue convenções do jCompany (“/uf”). Isso significa que implementaremos para Web e que teremos uma relação “um para um” entre uma Colaboração e uma URL! Estas são convenções importantes para rastreamento do projeto com implementações em jCompany.
São as seguintes as “Colaborações Padrões” do jCompany:
Padrões de Colaboração do jCompany
Estereótipo Nome Objetivo
Manutenção: Colaborações que implementam formulários e operações de Manutenção do
Ciclo de Vida de Agregações de Objetos, com fluxo MVC-P generalizado em todas as camadas. plcTabular Tabular Realização “um para um” com o Caso de Uso Padrão “Manter Classe”, oferecendo um formulário e implementações genéricas que recuperam e atualizam
simultaneamente todos os objetos de uma classe.
plcCrud CRUD Simples Colaboração utilizada no Caso de Uso Padrão “Manter Agregação Simples”, oferecendo um formulário e implementações genéricas que recuperam e atualizam uma Agregação que não contenha composição do tipo Mestre-Detalhe.
plcCrudTabular CRUD Tabular Colaboração utilizada no Caso de Uso Padrão “Manter Coleção”, oferecendo um formulário e implementações genéricas que recuperam uma coleção de objetos através de filtro e permitem atualização. plcMestreDetalhe Mestre-Detalhe Colaboração utilizada no Caso de Uso
Padrão “Manter Agregação Mestre-Detalhe”, oferecendo um formulário e implementações genéricas que recuperam e atualizam uma Agregação que contenha composição do tipo Mestre-Detalhe.
plcMantemDetalhe Mantém-Detalhe Idem acima, com o Mestre sendo apenas de consulta.
plcSubdetalhe
Mestre-Detalhe-SubDetalhe Colaboração utilizada no Caso de Uso Padrão “Manter Agregação Mestre-Detalhe”, oferecendo um formulário e implementações genéricas que recuperam e atualizam uma Agregação que contenha composição do tipo Mestre-Detalhe.
plcMantemSubdetalhe
Mantém-SubDetalhe Idem acima, com o Mestre sendo apenas de consulta. plcPrefUsuario Preferência do
Usuário Realização “um para um” com o Caso de Uso Padrão “Manter Preferência de Usuário”, oferecendo um formulário e implementações genéricas que incluem, recuperam e atualizam um único objeto por usuário.
plcPrefAplicacao Preferência da
Aplicação Realização “um para um” com o Caso de Uso Padrão “Manter Preferência de Aplicação”, oferecendo um formulário e implementações genéricas que incluem, recuperam e atualizam um único objeto por aplicação.
Exibição/Seleção: Colaborações que implementam formulários e operações de Pesquisa ou
Consulta de Agregações de Objetos, com fluxo MVC-P generalizado em todas as camadas. plcSelecao Seleção Colaboração utilizada com os Casos de
Uso de manutenção que mantém uma Agregação por vez para permitir pesquisa e seleção da agregação a ser editada.
plcSelMantemDetalhe Seleção Para Manter
Detalhes Colaboração utilizada com os Casos de Uso de manutenção que mantém uma Agregação por vez, com Mestre de consulta, para permitir pesquisa e seleção da agregação a ser editada. plcConsulta Consulta Realização “um para um” com o Caso de
Uso Padrão “Consultar Objetos”, oferecendo um formulário e implementações genéricas que
recuperam coleções de grafos de objetos com base em amostras de informações do usuário (argumentos de consulta). plcRelatorio Relatório Realização “um para um” com o Caso de
Uso Padrão “Consultar/Imprimir Objetos”, oferecendo um formulário e implementações genéricas que
recuperam coleções de grafos de objetos com base em amostras de informações do usuário (argumentos de consulta),
exibindo-as em formato apropriado para impressão
Estes diagramas de Realização de Casos de Uso (Visão Estrutural) serão apresentados para discussão mais detalhada, caso a caso, antes de inicarmos o desenvolvimento de cada um deles, no próximo módulo.
Sumário
Neste capítulo, fizemos uma breve introdução aos métodos e padrões propostos pelo jCompany, discutindo a importância de que sejam inseridos em um Processo de Desenvolvimento de Sistemas verdadeiramente Iterativo.
Revimos fundamentos úteis para a compreensão da Modelagem de Classes, definindo o conceito de Grafos e Agregações de Classes/Objetos e analisando como estes se relacionam com
documentos/formulários corporativos. A seguir, discutimos as motivações para automatizarmos a
Manutenção do Ciclo de Vida de Agregações de Objetos e Consultas básicas em MVC através de Casos de Uso Padrões suportados pela arquitetura e metodologia.
Relacionamos, então, os Casos de Uso Padrões do jCompany, além de Inclusões, Extensões e Colaborações relacionadas que utilizaremos neste livro.
Por fim, apresentamos os modelos para a aplicação “RH Tutorial”, em suas duas versões, enfatizando o primeiro Caso de Uso que desenvolveremos no próximo capítulo.
