Você está na página 1de 22

5

Captulo

Entendendo a Metodologia
de Desenvolvimento

6
A

Introduo
- Alinhando Metodologia com Arquitetura

o captulo anterior vimos como a arquitetura de base proposta pelo jCompany pode ser utilizada

como catalisadora para a definio de uma Arquitetura de Sistemas Corporativa (ASC) madura, com
alto nvel de automao atravs de generalizaes abrangentes. Posicionamos este tipo de soluo de
software como horizontal por resolver problemas comuns a vrias verticais de negcio , dentro de um
portiflio tpico de aplicaes.
J o nosso tema deste captulo, a Metodologia de Desenvolvimento de Sistemas (MDS), se
desenvolver em torno de prticas e padres para a construo da parte vertical da soluo - ou seja,
da soluo de negcio em si.
O ideal que uma MDS reconhea o nvel de abstrao e de generalizao disponveis na ASC, e que a
complemente, otimizando prticas de especificao e construo. Este ideal pode no se
manifestar na prtica por dois motivos:
o

Arquitetura Invisvel ou Anmica. Analistas e/ou desenvolvedores projetando e construindo


camadas horizontais de software em aplicaes de negcio, simplesmente por insuficincia na
padronizao e automao em nvel da arquitetura.

Metodologias Invisveis ou Anmicas. Metodologias inexistentes (desenvolvimento artesanal,


ao sabor das qualidades individuais de cada profissional) ou uso de MDS genricas mal
contextualizadas que, por exemplo, desconhecem a arquitetura.

Discutimos o primeiro motivo no captulo anterior. Vejamos ento o segundo.


O uso de prticas de modelagem, especificao e construo genricas de mercado (como variantes do
Processo Unificado e Design Patterns Java), sem adaptaes que as contextualizem para o reconhecimento da
Arquitetura de Software Corporativa presente, levam os profissionais a projetarem e a construrem em excesso,
com maior esforo e menor eficcia.

Uma sequela tpica de MDS desalinhada com ASC so especificaes prolixas que no reconhecem os
esteretipos da arquitetura e que, por isso, alm de serem mais custosas para serem obtidas,
comunicam mal.
Para o mximo de resultados, imprescindvel que a Arquitetura de Sistemas Corporativa seja to
automatizada quanto possvel e reconhecida pela Metodologia de Desenvolvimento de Sistemas. Deste modo,
analistas e/ou desenvolvedores podem calibrar melhor o nvel de abstrao de seu trabalho, tanto no projeto
quanto na implementao - evitando desperdcios e maximizando o reso.

Do ponto de vista da especificao, o jCompany traz um mdulo chamado jCompany Patterns &
Methods, que prope padres e prticas de especificaes de Casos de Uso, Modelagem de Classes,
Processos geis, dentre outros. um mdulo representado por documentao extensa, somente
disponvel com a licena corporativa do produto.
Do ponto de vista da construo, o jCompany traz roteiros automatizados atravs do recurso de CheatSheets do Eclipse, alm de plugins que geram verses que obedecem a padres concebidos na
metodologia.
Tal como no caso anlogo, da arquitetura, os mtodos e padres propostos pelo jCompany Patterns &
Methods devem servir de base para a definio de uma MDS corporativa, devendo ser considerados
como insumos reutilizveis para este trabalho .

Captulo A5

Especificaes baseadas em metodologias genricas de mercado, mal contextualizadas, so um dos maiores


problemas enfrentados pelos modelos Fbricas de Software atuais. No incomum que empresas adquiram a
sua base de arquitetura de um fabricante e as prticas de especificao de outro este uso pasteurizado da
modelagem de Classes, de Casos de Uso e de padres de interfaces Web termina por subtrai r importantes
benefcios que somente uma abordagem sinrgica pode oferecer.

Processos de Desenvolvimento de Sistemas


Vamos abrir uma pequena discusso sobre PDS, neste ponto, a guisa de estimular o uso de prticas
modernas que contribuam para o nosso sucesso *.
- Definio
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 no conformidades e reforar melhores prticas de produtividade
dever definir atividades, responsabilidades, mtodos, ferramentas e padres 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
so:
o

Concepo (principalmente Levantamento de Requisitos)

Elaborao (principalmente Projetos Lgico e Fsico)

Construo (principalmente Codificao e Testes Unitrios)

Transio (principalmente Testes de Aceitao e Liberao para Produo)

Os frameworks de processo mais pesados e abrangentes iro incluir outras reas tais como Gerncia de
Configurao, Garantia da Qualidade de Processo e Produto, Medio e Anlise etc., alm das reas
fundamentais.
A Figura A6.1. Exemplo das fases de um PDS mais abrangente.Figura A6.1 exibe um grfico com esta
viso mais abrangente, utilizado para representar todo o Gerenciamento de Ciclo de Vida de Aplicaes
(Application Lifecycle Management ALM).

Figura A 6.1. Exemplo das f ases de um PDS mais abrangente.

Por sua complexidade, quase nenhuma empresa define seu PDS inteiramente do zero, j que existem
vrios frameworks de base nesta rea. Alguns exemplos so: o Processo Unificado (Unified Process UP) j citado; e os mais recentes processos geis, tais como SC RUM e XP, em larga popularizao.
Alm destes, podemos citar os modelos de processo mais abrangentes, tais como o CMMI, o MPS.Br
(no Brasil) e o ISO 15504.

E s ta pequena dis cusso s e torna bem mais relevante na medida em que, muitas vezes, a ado o de proc essos inadequados est n a
raiz dos problemas de projeto. N o h s oluo de produtividade que s obreviva a um P D S modelo C ascata, gerenciado c om prticas de
c omunic ao primitivas (ex.: formalidades em papel!) e vis o ignbil ac erca da natureza pec uliar de um projeto de s oftware.

Entendendo a Metodologia de Desenvolvimento

- Metodologia ou Processo?
Neste livro, iremos adotar alguns jarges preferenciais:
o

Metodologia de Desenvolvimento de Sistemas (MDS) quando quisermos nos referir a um


espectro mais restrito de disciplinas, limitado s fases de Concepo, Elaborao, Construo e
Transio de um Processo de Desenvolvimento de Sistemas (PDS).

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, Gerncia de Configurao, Medio e Anlise,
Garantia da Qualidade de Produto e Processo etc.

O jargo do Processo Unificado (UP) [Booch, Jacobson, Rumbaugh 1998] quando falarmos
em mtodos, fases e alguns padres de especificao.

A UML - Unified Modeling Language [Pender, Tom] quando o assunto for modelagem e
especificao de sistemas.

A escolha destes jarges meramente por convenincia, j que so os mais difundidos no mercado. No
h nenhuma restrio especfica das solues de desenvolvimento que apresentaremos, com relao ao
uso de mtodos geis, por exemplo, ou quaisquer outras abordagens convencionais.
- Processos Iterativos x Processo em Cascata
Um ponto-chave na adoo de um processo compreender como ele sugere a distribuio das suas
prticas ao longo do tempo. Por este critrio podemos classificar um processo como enfatizando um
desenvolvimento em Cascata (Waterfall Process) ou Iterativo (Itera tive Process).
Sabemos que Processos em Cascata , apesar de serem os mais comuns em outras engenharias , so
piores para o desenvolvimento de Software . Fatos que corroboram esta tese so colecionados desde a
dcada de 80 e gerados at os dias de hoje.
Praticamente todo livro e artigo em Projeto de Aplicaes, nos ltimos 15 anos ou mais, tem criticado o
desenvolvimento em cascata. (...) Eles funcionam bem quando os requisitos so facilmente garimpados e
raramente mudam. Infelizmente, como a tnica a muda na nos negcios, tais situaes so cada vez mais
raras.
Ref . A 6.1. Pet er Bye e Cris Britton em IT A rchitectures and Middleware. Pg. 207.

Mas, apesar de sua ineficcia ser hoje de um consenso geral, o modelo em cascata , de forma acidental,
ainda o mais utilizado! Acidental porque, na prtica, tem, muitas vezes, sido utilizado desta forma
inconscientemente, especialmente por grandes e mpresas que trabalham com terceirizao de projetos
e equipes distribudas geograficamente.
O Processo Unificado um exemplo tpico de Processo Iterativo que muito frequentemente se transforma em
Cascata quando implantado - e assim subutilizado no dia a dia por culpa de customizaes mal feitas.

E qual seriam os motivos desta distoro? Os processos em cascata so mais simples de se entender
por serem os mais conhecidos pela humanidade nas engenharias clssicas. Qualquer estudante ir
compreender uma analogia dos Processos de Desenvolvimento de Sistemas com os Processos da
Engenharia Civil, por exemplo simplificao que contribui para manter o atraso cultural nas reas de
TI desde os anos 70.
Este tipo de analogia, perigosamente didtica, no expressa de forma apropriada a natureza nica do
software, um bem invisvel, abstrato e de simulao da dinmica de negcios. uma natureza que
requer um paradigma diferenciado, atualmente melhor representado p or mtodos Iterativos e geis.
"A noo de 'requisitos-projeto-implementao' em cascata to intuitivamente correta"... O que pode estar
errado com ela? Na prtica, existem trs problemas principais. Primeiro, os usurios finais e de negcio no
conhecem seus requisitos, so incapazes de express-los com rigor suficiente ou, at pior, tm requisitos
contraditrios. Introduzir uma nova aplicao de TI muda o trabalho das pessoas e elas tm dificuldade de
visualizar o que preciso para o novo sistema funcionar.
(...) O segundo problema a dificuldade de expressar a especificao de uma maneira compreensvel e
utilizvel por ambos, o programador (...) e os patrocinadores do negcio (...)
O terceiro problema que a diviso de responsabilidades entre requisitos, especificao (projeto) e
implementao leva ao excesso de engenharia. "Isto particularmente verdadeiro em grandes organizaes,
onde um grupo especifica requisitos e outro faz o projeto e a implementao."
Ref . A 6.2. Pet er Bye e Cris Britton. IT A rchitectures and Middleware. Pg. 206.

Por todos estes motivos, no h hoje estudiosos na rea de TI ou nenhum framework de


processo que preconize o modelo Cascata. O que existe, porm, so implantaes imperfeitas de
processos Iterativos como citamos, ressaltando o caso do Processo Unificado . Aplicados desta forma, tais

Captulo A5

processos trazem os mesmos resultados medocres j conhecidos da poca da Engenharia da Informao.


Como diz o ditado:
insensatez querer fazer algo sempre da mesma forma e esperar por resultados diferentes
Ref . A 6.3. A tribudo a A lbert Einstein

A Figura A6.2. Diagrama do Processo Unificado, destacando em branco uma iterao.mostra um esquema
simplificado com relao Figura A6.1. Exemplo das fases de um PDS mais abrangente., evidenciando
o aspecto iterativo do Processo Unificado.

Figura A 6.2. Diagrama do Processo Unif icado, destacando em branco uma iterao.

No diagrama clssico do UP, uma iterao representada graficamente atravs dos montinhos, que
sugerem a intensidade da ocorrncia de uma determinada disciplina em cada fase.
Note que, na iterao #2 destacada durante a fase de Elaborao, alm de anlise e projeto, so
esperadas boas quantidades de trabalhos simultneos de implementao (codificao de programas) e
inclusive de testes! Como faz-lo em modelos clssicos de fbricas de software?
- Processos Iterativos e Fbricas de Software
Alm dos trs problemas citados por Peter Bye e Cris Britton, h um quarto problema que podemos
acrescentar, certamente de grande peso: As empresas tm decidido por adotar processos em Cascata
como soluo comercial para viabilizar contratos e m preo fechado para terceirizao da fase de
Construo, por trs motivos:
1.

Complexidade da Construo em eBusiness. A fase de Construo tornou-se exponencialmente mais


complexa do que era em geraes passadas, distanciando ainda mais os Analistas de Negcio de um ambiente
onde possam prototipar e explorar os resultados de levantamento, aprendendo sobre a soluo juntamente com
seus usurios.

2.

Maior controle contratual para diminuio de custos e riscos. Gestores financeiros anseiam por mais
controle sobre os contratos de TI, visando reduo de custos e riscos, e muitas vezes no aceitam
desenvolvedores de terceiros alocados ao lado de seus Analistas de Negcio.

3.

Melhorar a produtividade via especializao de funes. A mesma complexidade observada no item 1 pode
ser amenizada com pessoal especializado em tecnologias especficas.

Mas o fato que o modelo contratual de terceirizao em preo fechado dificulta tremendamente a
instaurao de um processo verdadeiramente iterativo:
o

Exige uma grande viso de projeto antecipada, para efeitos de contratao (Anlise Big-Bang);

Produz dificuldades contratuais que degradam a adaptabilidade (controles de mudana rigorosos,


que inibem a agilidade);

Gera problemas srios de comunicao que embotam a colaborao (a nalistas contra


desenvolvedores);

E, o que pior, elimina o contexto necessrio para se evoluir uma soluo da forma ideal, desde
a sua Concepo, o que exige graus de programao durante a concepo e de anlise de
requisito durante a construo em um cenrio de explorao e adaptao contnuas.

Entendendo a Metodologia de Desenvolvimento

Como o jCompany pode contribuir, inserido neste contexto?


1.

Complexidade da Construo em eBusiness. Neste sentido, o jCompany poder ajudar decisivamente, pois
as prticas de alta produtividade ensinadas neste livro viabilizam o retorno de uma prototipao com
aproveitamento posterior do cdigo, mesmo se tratando de aplicaes complexas de eBusiness utilizando Java
EE e MVC.
Se h um cenrio de requisitos instveis e todos os outros elementos que requerem u m desenvolvimento
iterativo esto presentes, os Analistas de Negcio ou Projetistas treinados conseguiro usar o jCompany
mesmo em fases iniciais do processo (Concepo ou Elaborao) para realizar prototipaes -chave para
elicitao de requisitos, junto aos usurios. Isso porque no precisar de conhecimentos profundos em Java,
Java EE, HTML, Javascript, CSS etc., para apresentar resultados com razovel profundida de.
Esta uma possibilidade que deve ser explorada e pode ser decisiva para o sucesso de um grande nmero de
projetos de TI de natureza desafiadora!

2.

Maior controle contratual para diminuio de custos e riscos. Este um mito. No h contrato que
compense os prejuzos 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 apresentvel aos usurios em iteraes de semanas,
no meses. Eis a uma frmula que, comprovadamente, contribui para reduzir custo e riscos.

3.

Melhorar a produtividade via especializao. Quanto mais se generaliza solues repetitivas para
arquiteturas ricas e utilizam-se geraes de cdigo suplementares, menos trabalho braal, tpicos de
manufatura, restam aos Desenvolvedores.
Em jCompany, restam para os desenvolvedores mais atividades de projeto do cdigo fonte, ou seja, trabalho
inteligente; e menos atividades do tipo replicar a frma de cdigo, ou seja, trabalho braal. Neste cenrio, seria
mais apropriado chamar os desenvolvedores de co-projetistas ou projetistas de cdigo e no de
implementadores. E como trabalham em mais alto nvel, a aproximao entre desenvolvedores jCompany
(Projetistas de Cdigo) e Analistas de Negcio (Projetistas de Caso de Uso) deve ser estimulada, podendo
inclusive ser decisiva para o sucesso de projetos complexos.

- Prticas para Especificao - Projeto Lgico e Fsico


O mdulo jCompany Patterns & Methods traz material que discute, mais a fundo, sugestes para a
fase de Elaborao (Projetos Lgico e Fsico), dando subsdios para a criao de prticas de modelagem
eficazes que comuniquem bem e produze m modelos que se preservem atualizados ao longo do ciclo de
vida de uma aplicao.
Algumas aes sugeridas so:
o

Automao bidirecional, com gerao de classes a partir de modelos e de modelos a partir de


classes;

A eliminao de hiatos de modelagem (vrias camadas de modelos e de transformaes


MDA desnecessrias);

E o estabelecimento de esteretipos com base na UML, que produzam uma comunicao


direta com relao a abstraes da arquitetura, padres e prticas de construo do jCompany.

Neste captulo e nos prximos, iremos apenas apresentar conceitos bsicos suficientes para entendermos
as especificaes que encontraremos nos tutoriais do mdulo B.
- Prticas para Construo Java EE
Esta a rea principal de foco do jCompany. Sua produtividade diferenciada advm, principalmente, da
padronizao de solues em um patamar de abstrao mais alto que qualquer outro framework ou
ferramenta de desenvolvimento.
Os padres em nvel de Caso de Uso automatizados pelo jCompany permitem ao desenvolvedor, em
questo de minutos - no horas ou dias, produzir solues MVC2-P completas e flexveis para um bom
percentual de problemas tpicos de aplicaes comerciais com qualidade de produo!
E esta alegao no pouca coisa: se somarmos o resultado de todos tutoria is encontrados nos livros de
Hibernate/JPA, JSF, JBoss Seam, Spring e Eclipse, por exemplo, que fazem parte de nossa
referncia bibliogrfica, no 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 benefcios da
maioria destes produtos. Mas, alm disso, tambm se deve ao elevado nvel de especializaes e
padronizaes presentes nas diversas dimenses de arquitetura, mtodos, padres e tcnicas de
automao.

Captulo A5

Mantendo Agregaes de Objetos


- Agregaes de Objetos
Entender o conceito de Agregao de Objetos fundamental para a introduo aos Casos de Uso
Padres do jCompany que veremos inicialmente. Portanto, iremos recapitular este conceito de OO,
tomando como base o Modelo de Classes da Figura A6.3.

Figura A 6.3. Modelo de Classe de Exemplo .

O trecho acima um recorte de um modelo maior que utilizaremos neste livro, representando um grafo
cujos vrtices so classes e as arestas so associaes. Chamaremos a este recorte, portanto, de
Grafo de Classes, no qual podemos identificar 3 vrtices e 2 arestas.
o

3 (trs) classes: Uf, UnidadeOrganizacional e Endereco.

1 (uma) agregao de classes: Entre UnidadeOrganizacional e Endereco.

1 (uma) associao Simples: Entre Endereco e Uf.

Estas classes definem estruturas possve is de dados, mas so os objetos ou instncias destas classes
que iro conter os dados em si durante a execuo de uma aplicao e compor os formulrios de nossa
aplicao visveis para o usurio, que representam documentos eletrnicos de negcio.
Tal como no grafo de classes, estes objetos se relacionam conforme a estrutura definida pelas classes,
variando conforme o estado (situao corrente) da aplicao.
A Figura A6.4 representa um Grafo de Objetos hipottico para uma possvel configurao de objetos,
em um determinado momento de execuo da aplicao. Podemos compreender este diagrama, de forma
anloga, como um Grafo de Objetos, que representa instncias do Grafo de Classes que o define.

E s te diagrama traz um mix de modelagem diferente dos tradicionais. P erceba que us a tipos J ava juntamente c om restri es e
opera es em nvel c onceitual. O s tamanhos (multiplicidade) de propriedades tambm s o atpicos, alm de diversos es tereti pos.
E s te tipo de padro des c rito na doc umentao do jC ompany Patterns & M ethods

Entendendo a Metodologia de Desenvolvimento

Figura A 6.4. Graf o de Objet os hipott ico em um det erminado estado da aplicao.

Na Figura A6.4, seccionamos o nico grafo formado por todo o modelo em trs subgrafos, para fins
didticos, porque normalmente so estes subgrafos que compem a estrutura de um documento tpico de
negcio (ou formulrio da aplicao), como pode ser conferido na Figura A6.5.
- Grafos de Objetos x Agregaes de Objetos
Quando falamos em Manuteno do Ciclo de Vida comum visualizarmos inicialmente um formulrio,
digamos, do tipo Manter Funcionrio, mantendo dados de um nico objeto.
Mas com uma aplicao real em mos descobriremos que Manutenes de Ciclo de Vida tpicas no
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 rgida (imagem de dados
alterados) e outras sofisticaes em um cenrio bem mais complexo que nossa abstrao inicial.
Vamos pegar um exemplo bem simples:
Quando delimitamos grafos e agregaes de objetos na Figura A6.4, a hiptese a de que estamos
realizando manuteno sobre objetos de UnidadeOrganizacional (Departamentos, como rotulados no
formulrio abaixo) e Endereco, e consultando objetos de UF. Veja exemplo no formulrio da Figura
A6.5.

Figura A 6.5. Exemplo de f ormulrio possvel para manter o esquema de objet os da f igura 4.

Aqui retornamos ao nosso ponto inicial para estabelecermos algumas convenes de nomenclatura e
modelagem OO importantes:
o

Formulrios do negcio lidam no com um objeto, mas com um Grafo de Objetos.

J um Grafo de Objetos um corte do Modelo de Objetos envolvido em uma transao,


exemplificados na Figura A6.4 pelos Subgrafos 1, 2 e 3.

Por sua vez, uma Agregao de Objetos aquele subconjunto de objetos do Grafo,
modificados simultaneamente, exemplificados na Figura A6.4 pelas Agregaes 1, 2 e 3.

As classes UnidadeOrganizacional e Endereco so partes de uma mesma agregao


de classes/objetos, mas no Uf.

No entanto, Uf participa do mesmo Grafo de Objetos utilizado no formulrio de


Manuteno de Departamentos (UnidadeOrgacional).

Captulo A5

Esta compreenso nos ajudar a especificar de forma simples e objetiva um grande nmero de Casos de
Uso, bem comuns.
- Automatizando a Manuteno de Agregaes de Objetos
Uma Agregao um cluster de objetos associados que ns tratamos como uma unidade para o propsito de
mudanas de dados. Cada Agregao tem uma raiz e um contorno. O contorno define o que est dentro da
Agregao. A raiz uma nica Entidade, dentre as contidas na Agregao, e a nica para a qual objetos
externos agregao podem manter referncias
Ref . A 6.4. Eric Evans em Domain-Drive n Design [Evans, Eric 2004]. Pgs. 126-127.

O esteretipo raiz agregao, utilizado na classe UnidadeOrganizacional da Figura A6.3 e a linha


pontilhada que delineia o contorno da Agregao foram baseados em sugestes de Evans. Esta e outras
convenes de modelagem so discutidas no mdulo jCompany Patterns & Methods.
Existem diversos comportamentos tpicos que caracterizam e devem ser assegurados para uma
Agregao, sendo alguns: ao excluir-se um objeto raiz, deve-se excluir toda a Agregao, deve-se
reforar restries invariveis para a Agregao como um todo. Vrios destes comportamentos so
expostos em [Evans, Eric 2004] e fogem ao nosso escopo atual de discusso. Mas h uma sugesto
bastante pertinente de Evans, que desejamos citar:
Pode ser de grande ajuda ter um framework tcnico que permita a voc declarar Agregaes e ento
automaticamente garantir suas restries. Sem este apoio, a equipe deve ter a autodisciplina para codificar
consistentemente com as regras da Agregao
Ref . A 6.5. Eric Evans em Domain-Drive n Design [Evans, Eric 2004]. Pg. 129.

Esta uma das estratgias que o jCompany adota e realiza de forma bastante extensiva e interessante.
O jCompany permite que declaremos em seus metadados, no somente a estrutura da Agregao principal,
composta das classes que sofrem alteraes em conjunto, como tambm todo o Grafo de classes participante,
incluindo as classes de consulta. A partir da, padroniza solues e as generaliza completamente em todas as
camadas MVC-P, ao ponto de dispensar totalmente o uso de cdigo procedimental Java at um estgio
avanado.

Alm da parte procedimental, a soluo generalizada para Manuteno de Agregaes do jCompany


ainda inclui padres na camada Viso, produzindo Interfaces com o Usu rio com formulrio nico, por
Agregao*. Deste modo, os formulrios refletem de forma direta os documentos de negcio com
ganhos tanto em usabilidade quanto em performance e escalabilidade!
//todo alterar print?

A o quebrar, s em nec essidade, a manuten o de uma A gregao em vrios formulrios de C RUD do tipo mantm um objeto da
agrega o por vez, exige - se do us urio que navegue por vrias pginas, provocando dezenas de trans misses na rede e requis ies
ao A pp Server desnecessrias (muitas vezes at transaes de SG BD). E sta abordagem de Web - D esign uma verdadeira
abomina o para aplicaes c orporativas multiusurio, c om entrada de dados mas siva.

Entendendo a Metodologia de Desenvolvimento

Figura A 6.6. Formulrio nico que mantm a A gregao Funcionario -> Dependente -> Hist. Prof issional.

- Generalizando Manutenes em Arquitetura MVC


Alm de lidar com Agregaes complexas e produzir formulrios com ergonomias apropriadas, outro
complicador para generalizao das Manutenes de Ciclo de Vida faz -la respeitando-se a arquitetura
MVC.
Em Cliente/Servidor, fazamos um CRUD de forma muito simples, ligando campos de jane las a colunas de
tabelas no Banco de Dados. Isso ainda possve l em Java EE (e muitas vezes exemplificado at em livros
recentes do JSF ou JBoss Seam, por exemplo), mas o fato que no queremos retroceder nesta rea: a
arquitetura MVC hoje aceita como pauta mnima de arquitetura.
O jCompany realiza um trabalho de generalizao 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
mantm o respeito a esta arquitetura.

Figura A 6.7. Solues generalizadas em todas as camadas MVC-P.

Casos de Uso Padres do jCompany


- Casos de Uso com cenrios similares
Alistair Cockburn, em seu livro Escrevendo Casos de Uso Eficazes [Cockburn, Alistair. 2003], discute o
que chama de Casos de Uso CRUD e tambm Casos de Uso Parametrizados.
o

Os Casos de Uso CRUD se referem manuteno de ciclo de vida de documentos do


negcio, englobando funes de criao, recuperao, atualizao e excluso (C -Create, RRetrieve, U-Update e D-Delete) atravs de cenrios que pouco ou nada variam de documento
para documento.

J os Casos de Uso Parametrizados se referem s outras situaes recorrentes e que


poderiam levar a uma proliferao de cenrios quase idnticos, onde o melhor exemplo so

Captulo A5

consultas para seleo de documentos do tipo Encontrar um Cliente, normalmente


envolvendo uma entrada com amostra de dados e subsequente pesquisa de relao resultante
que atende aos critrios.
Tanto no primeiro quanto no segundo caso, os cenrios dos Casos de Uso so repetitivos. O que ir
variar sero os documentos especificamente adotados em cada caso . Portanto, para evitar esta
redundncia de especificao, prope 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 . A 6.6. A listair Cockburn em Escrevendo Casos de Uso Ef icazes. Pg. 149.

Em seguida, Cockburn sugere que se definam somente as diferenas de cenrios (argumentos e


operadores a serem utilizados para pesquisa, campos retornados etc.), em Subcasos de Uso, deste modo
promovendo a prtica da Especificao por Exceo.
Prosseguindo em seu exemplo sobre os Casos de Uso Parametrizados:
O comportamento de pesquisa comum localizado e escrito apenas uma vez. A consistncia entre
mecanismos de procura garantida, (...). De fato, a equipe de implementao foi encorajada a dar apenas uma
especificao para seu mecanismo de pesquisa (...)
Ref . A 6.7. A listair Cockburn em Escrevendo Casos de Uso Ef icazes. Pg. 150.

O que Alistair Cockburn sugere so dicas para se eliminar o trabalho de especificao repetitiva que estas
duas categorias de Caso de Uso tendem a produzir, e por esta trilha que o jCompany caminha. No
somente identificando com mais detalhes estes Casos de Uso Padres no jCompany Patterns &
Methods, como provendo generalizaes avanadas via jCompany FS Framework e, por fim, gerando
artefatos especficos 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 Padres para Manuteno do Ciclo de Vida de Agregaes de Objetos
ou, resumidamente, de Padres para Manuteno.

O jCompany tambm padroniza e atende com implementaes genricas os Casos de Uso


Parametrizados, chamados de Casos de Uso Padres para Exibio de Colees de Agregaes
(Ex.: selees, consultas e relatrios) ou, resumidamente, Padres de Exibio. Neste caso,
atravs de simples declaraes de argumentos e operadores, o jCompany ir realizar um QBE
(Query By Example) MVC-P, dispensando codificao Java.

- Padres para Manuteno


A produtividade nas manutenes obtida atravs do uso dos Padres de Caso de Uso relacionados na
Figura A6.8.

Figura A 6.8. Casos de Uso Padres para Manuteno de Ciclo de Vida.

A tabela a seguir resume o objetivo de cada Caso de Uso Padro, que sero detalhados ao longo dos
prximos captulos quando estaremos implementando efetivame nte vrios deles.

Entendendo a Metodologia de Desenvolvimento

Casos de Uso Padres de Manuteno


Primrios

Representam as manutenes mais comuns e


independentes.

M anter C lasse

E s te C aso de U s o prev a manuten o de todos os objetos de uma


c las se, de uma s vez. P or is s o, s omente deve ser utilizado em
c las ses c om pouc os objetos.

M anter A gregao Simples

E s te C aso de U s o prev a manuten o de uma A gregao de


O bjetos Simples, que no envolva c omposi o do tipo M estreD etalhe e variantes.

M anter A gregao
M es tre/Detalhe

E s te C aso de U s o prev a manuten o de uma A gregao de


O bjetos que inc lua uma c omposio do tipo M estre-D etalhe.

M anter A gregao
M es tre/Detalhe/SubDetalhe

E s te C aso de U s o prev a manuten o de uma A gregao de


O bjetos que inc lua uma c omposio do tipo M estre-D etalheSubD etalhe.

M anter C oleo
M odalidade A

E s te C aso de U s o prev a manuten o de um C ole o de O bjetos


de uma s vez, filtrados de uma c las se mas que nec essariamente
no referenc iem objetos pr - existentes.

Secundrios

Representam as manutenes complementares s


primrias, que requeiram que classes raiz j existam e
tenham sido mantidas por outros padres anteriormente.

M anter C oleo
M odalidade B

E s te C aso de U s o prev a manuten o de um C ole o de O bjetos


de uma s vez, filtrados de uma c las se e que partem da s eleo
de um objeto pr- c riado, referenciado pela c oleo de objetos
s elecionada.

M anter A gregao C onsultaM es tre/Mantm- Detalhe

E s te C aso de U s o prev a manuten o de uma A gregao de


O bjetos que inc lua uma c omposio do tipo M estre-D etalhe, onde
o M es tre (raiz da agregao) j tenha s ido inc ludo por outro C aso
de U s o P adro.

M anter A gregao C onsultaM es tre/Mantm- DetalheSubdetalhe

E s te C aso de U s o prev a manuten o de uma A gregao de


O bjetos que inc lua uma c omposio do tipo M estre-D etalheSubdetalhe, onde o M es tre (raiz da agrega o) j tenha s ido
inc ludo por outro C aso de U so P adro.

C as os de U so P adres de M anuteno
Da A plicao

Representam Casos de Uso que no so do negcio


necessariame nte, mas que so comuns ao se criar uma
aplicao. Normalmente ocorrem um de cada por
aplicao.

M anter P referncia de A plicao

E s te C aso de U s o prev a manuten o de preferncias globais


do res ponsvel (administrador) pela aplicao. T ambm
c onhec idos c omo parmetros globais.

M anter P referncia de U surio


(para a A plic ao)

E s te C aso de U s o prev a manuten o de preferncias de c ada


us urio para a aplic ao, podendo es te registrar op es de
pers onalizao de us o ou outras que s e fa am nec essrias.

- Padres para Exibio (Consulta e Impresso)


Para exibio de informaes, o jCompany tambm prev dois Casos de Uso Padres, exibidos na Figura
A6.9.

Captulo A5

Figura A 6.9. Casos de Uso Padres para Exibio.

Casos de Uso Padres de Exibio


C ons ultar O bjetos

E s te C aso de U s o prev a c onsulta em formato no otimizado para


impres s o (H TML, s em quebras) de c olees de grafos c ontendo
informa es de diversos objetos.

C ons ultar/Imprimir
O bjetos

E s te C aso de U s o prev a c onsulta em formato otimizado para impresso


(P D F, c om quebras ) de c olees de grafos c ontendo informa es de
divers os objetos.

Subcasos de Uso Padres do jCompany


Como vimos, a padronizao em nvel de Caso de Uso um dos grandes alcances do jCompany. Neste
nvel, o padro resulta no em uma soluo tcnica, mas em um valor tangvel para o negcio. Por isso,
podemos cham-lo de padro de ltima milha.
Descendo um pouco mais em nvel de detalhe, encontraremos variaes tpicas dos Casos de Uso
Padres que no podem ser utilizadas de forma isolada, mas so padronizadas pelo jCompany para
compor cenrios mais complexos. Estas variaes podem ser consideradas Subcasos de Uso, como
chamados por Alistair Cockburn [Cockburn, Alistair. 2003], se subdividindo nas duas categorias tpicas de
Incluso (Include) e Extenso (Extend).
- Subcasos de Uso Padres para Incluso
Os Subcasos de Uso Padres para Incluso so aqueles que fazem parte de cenrios principais e que
ocorrem de maneira sncrona, frequentemente exemplificados como similares a sub -rotinas,
reutilizadas por vrios Casos de Uso.
A Figura A6.10 ilustra os diversos Subcasos de Uso Padres de Incluso do jCompany, relevantes para
os Casos de Uso Padres de Manuteno.

Figura A 6.10. Subcasos de Uso Padres para Incluso.

Entendendo a Metodologia de Desenvolvimento

Subcasos de Uso Padres para Incluso


I nc lui E xcluso L gica E s te Subcaso de U so prov c enrio adicional para a exc luso, que deixa de
s er fs ic a (eliminao da agregao) para s e tornar uma altera o de
propriedade padro s itHistoricoPlc de A (A tivo) para I (I nativo).
A gregaes onde s itHistoricoPlc=I s o ento c onsideradas excludas para
o ponto de vis ta de us urios.
I nc lui Auditoria Rgida E s te Subcaso de U so prov c enrio adicional para registrar objetos
c ontendo imagens de dados alterados, inc ludos ou exc ludos em outras
c las ses es pelho, para efeitos de auditoria.
I nc lui Auditoria
Rec urs iva

O bs .: s omente disponvel em vers es anteriores do jC ompany (3 .x).

I nc lui P esquisa
P aginada

E s te Subcaso de U so prov c enrios adicionais que alteram a pes quisa de


c ole es c ontendo grafos de objetos para evitar que traga regis tros em
demas iado em s elees de objeto visando edio para manuteno,
limitando a quantidade por pgina.

I nc lui Arquivo
A nexado

E s te Subcaso de U so prov c enrios adicionais que permitem a anexa o


(upload) de arquivos e s ua rec uperao (download) juntamente c om a
agrega o principal.

I nc lui Aprovao

O bs .: s omente disponvel em vers es anteriores do jC ompany (3 .x).


Rec omenda-se o jC ompany E xtension para BPMS (BPMN 2 .0 ) para fins de
Workflow (Fluxos de A provao)

- Subcasos de Uso Padres para Extenso


Outro tipo de reso padronizado pelo jCompany abaixo do nvel de Caso de Uso se d com extenses,
que so opes disponveis para acioname nto assncrono pelo usurio e que , portanto, no participam
do cenrio principal do Caso de Uso.
A Figura A6.11 ilustra os diversos Subcasos de Uso Padres de Extenso do jCompany.

Figura A 6.11. Subcasos de Uso Padres para Extenso.

Subcasos de Uso Padres para Extenso


E xtenso E xportao

E s te Subcaso de U so prov c enrios alternativos (que podem ou no s er


ac ionados pelo us urio, aps uma pes quisa de s eleo ou c onsulta) para
exporta o dos dados resultantes para formatos tais c omo C SV ou XM L.
O bs .: Somente disponvel em vers es anteriores do jC ompany (em reviso
para J SF 2 .0 )

E xtenso Assistente

E s te Subcaso de U so prov c enrios alternativos (que podem ou no s er


ac ionados pelo us urio, durante a entrada de dados ) para ac ionar dilogos
de as s istente de entrada de dados , passo a pas so (Wizards ).
O bs .: Somente disponvel em vers es anteriores do jC ompany (em reviso
para J SF 2 .0 )

E xtenso E xplorao
de D ados

E s te Subcaso de U so prov c enrios alternativos que podem ou no s er


ac ionados pelo us urio durante a entrada de dados para que uma treeview
s eja exibida c ontendo uma hierarquia de dados definida pelo
des envolvedor, que pode s er utilizada como um menu alternativo,

Captulo A5

orientado a dados , s imilar ao E xplorador do Windows .


E xtenso D etalhe por
D emanda

E s te Subcaso de U so prov c enrios alternativos que podem ou no s er


ac ionados pelo us urio, provocando a rec uperao de c olees de objetos
de detalhe quando s o declarados c omo por demanda.

Introduo ao Projeto Lgico do RH Tutorial


A melhor forma de se conhecer os Padres de Caso de Uso do jCompany utiliz-los na prtica. o que
faremos nos captulos de tutoriais que se seguiro, no mdulo B. Neste captulo, vamos apenas
apresentar os Modelos de Casos de Uso de Contexto para a aplicao que iremos desenvolver.
A aplicao RH Tutorial uma simplificao de uma automao de RH, rea de negcio escolhida por
trazer conceitos bsicos bem familiares aos trabalhadores em ge ral e que, por este motivo, no exigiro
maiores explicaes sobre o Domnio *.
- Casos de Uso de Contexto em Nvel Resumido para RH Tutorial
Por hora, vamos entender nosso escopo. A Figura A6.12 mostra um Diagrama de Casos de Uso em Nvel
Resumido, elaborado em tempo de planejamento, representando nosso desejo de realizar duas verses
para a aplicao que desenvolveremos neste livro e alguns Atores principais.
Como representa o diagrama, pretendemos ter duas verses de nosso sistema de exemplo, sendo que
primeira ser desenvolvida nos mdulos A ao F (Verso 1.0), e a segunda em volumes subsequentes
deste livro.

Figura A 6.12. Diagrama de Caso de Uso em escopo de Planejamento (Negcio)

- Casos de Uso de Contexto em Nvel de Objetivos do Usurio Verso 1.0


O Diagrama de Casos de Uso de Contexto da Verso 1.0, apresentado na Figura A6.13, descreve todos os
Casos de Uso que desenvolveremos no s primeiros mdulos.

E xpos ies s obre um domnio c omplexo s eriam montona s em nos so c ontexto atual. P or isso, ns no iremos explicar em detalhes
c ada C aso de U so, deixando para faz -lo progressivamente na medida em que evoluirmos no tutorial de c onstruo da aplicao.

Entendendo a Metodologia de Desenvolvimento

Figura A 6.13.Casos de Uso para a verso 1.0 do RH Tutorial

So os seguintes os objetivos dos Atores em cada Caso de Uso da Figura 12:


A tor

Nmero

Caso de Uso

Objet ivo

A dministrador

U C 001

M anter E s trutura O rganizacional

I nc luir e manter atualizadas


informa es (nome e
endere o) de U nidades
O rganizacionais da empresa,
inc luindo matriz e filiais.

U C 008

A uditar O peraes

V erificar alteraes
realizadas no c adastro de
Func ionrios e s eus dados,
para fins de s egurana.

U C 002

Regis trar Funcionrios

Regis trar e manter


atualizados os func ionrios,
na medida em que s o
c ontratados.

U C 003

C ons ultar/Imprimir Ficha


Func ional

C ons ultar uma fic ha


c ompleta incluindo dados de
Func ionrio, D ependentes,
H is trico Funcional e
L ota o em qualidade boa
tambm para impres s o.

U C 004

Regis trar Proventos e D escontos Regis trar dbitos e c rditos


para o Func ionrio ao longo
do ms .

U C 005

C alc ular Folha de P agamento

Realizar c lculos de
pagamentos mensais,
c ons iderando-se s alrio base
atual, proventos e
des c ontos.

U C 006

C ons ultar/Imprimir Folha de


P agamentos

Realizar c onsulta c om
qualidade de impres so com
rela o de todos os
func ionrios e s alrios, c om
quebra e totalizaes por
lota o.

RH

FolhaP agamento

Captulo A5

- Casos de Uso de Contexto da Aplicao Verso 2.0


A verso 2.0 contemplar integraes tpicas da realidade corporativa em diversos cenrios, como ilustra
a Figura A6.14. Estes casos de uso utilizam tecnologias de WOA (RESTFull Services), Dashboards e
outras.

Figura A 6.14. Casos de Uso para a verso 2.0 do RH Tutorial".

So os seguintes os objetivos dos Atores para a Verso 2.0:


A tor

Nmero

Caso de Uso

Objet ivo

A nnimo

U C 009

C ons ultar E strutura


O rganizacional

U s urios annimos, via Web- Site,


devem s er c apazes de c onsultar
dados da E s trutura O rganizacional,
tais c omo N ome e E ndereo de
M atriz e Filiais.

C hefia

U C 010

C ons ultar P erfil de E quipe

U s urios em c argos de c hefia


devem poder s indic alizar c ontedos
em formato RSS/RD F c ontendo a
rela o de s ua equipe de
s ubordinados imediatos.

Sis tema SO A

U C 011

C ons ultar N vel de Salrio


de Func ionrio

Servi o que deve permitir c onsulta


de nvel s alarial, para um
func ionrio.

U C 012

Regis trar Promoo de


Func ionrio

Servi o que deve realizar a


promo o de um Func ionrio,
inc lus ive consumindo o s ervio
U C 0011.

E xec utivo

U C 013

C ons ultar G rfico T otal de


D es pesa Folha P agto por
U nidade O rganizacional

C ons ultar grfico que pos sa s er


utilizado em D as hboard bas eado
em G adgets .

C ontabilidade
E xterna

U C 014

G erar arquivo XM L c om
res ultados de c lculo de
Folha

Rec eber por email os dados de


c lc ulo de Folha em anexo,
c riptografados.

Esta segunda verso nos possibilitar a implementao de integraes tpicas de eBusiness, tais como:
o

Integrao de determinadas transaes da aplicao em Websites (para acesso annimo),


usando sindicalizao de HTML simples.

Integrao com Portais Corporativos via exportao de dados para XML, usando sindicalizao
RDF/RSS.

Entendendo a Metodologia de Desenvolvimento

Integrao envolvendo servio e consumo de Web-Services (REST preferencialmente) para


estratgias de SOA.

Integrao com padres diversos

Integrao atravs de Gadgets para uso em Dashboard privados (MyPortal) ou comunitrios


(iGoogle)

Integrao via envio de email com arquivo anexado para usurios desconectados (off-line)

Nveis de Casos de Uso


- Introduo
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 !. Alm disso, a colorao
branca para os Casos de Uso da Figura A6.12 e azulada para os demais.
Esta notao recomendada por Alistair Cockbur [Cockburn, Alistair. 2003] e diz respeito ao Nvel de
Objetivo do Caso de Uso. So os seguintes os nveis principais sugeridos:
Nvel

Cor

Smbolo
Suf ixo

Signif icado

Res umo
(C u)

Branc a

So C as os de U so utilizados para repres entao do c ontexto


maior da aplic ao, agrupando objetivos do us urio.

O bjetivos do
U s urio
(N vel do M ar)

A zul C lara

So C as os de U so de maior interesse que realizam um


objetivo c oncreto do us urio, c orrespondentes ao proc esso
de negc io elementar.

Sub- fun es
A zul E s curo (Fundo do M ar)

So C as os de U so que representam atividades menores do


us urio dentro de um C as o de U so objetivo. (N a U ML
atualizada, s o Casos de U so es tereotipados c omo
C olaboraes, es tando em um nvel mais prx imo da
implementao)

Para uma discusso sobre a importncia de se destacar Nveis de Objetivo nos Casos de Uso, sugerimos
a referncia [Cockburn, Alistair. 2003]. Para ns, esta segmentao especialmente importante porque
desejamos partir da especificao para a implementao de modo claro e automatizado.
Neste sentido, temos que distinguir bem entre este Nvel de Objetivo e o Nvel de Implementao:
o

Para o Projeto Lgico em si, o importante uma boa marcao do Nvel de Objetivo nos
modelos de Caso de Uso, nvel mais importante para o usurio.

Para o Projeto Fsico (e rastreamento com a implementao), o mais importante a


diferenciao de um Caso de Uso como Concreto, para deixar claro que ele est em Nvel de
Implementao - especialmente quando j existam padres definidos na Arquitetura
com suporte direto para sua implementao, que o nosso caso*.

Um bom exemplo sobre a distino entre estes nveis pode ser obtido atravs da Figura A6.13. Todos os
Casos de Uso deste diagrama esto em Nvel de Objetivo do Usurio (!), mas nem todos so
Concretos! O UC001 Manter Estrutura Organizacional! modelado como Abstrato", o que
percebemos pelo texto em itlico, padro de notao UML para estes casos.
- Analisando Nveis em UC001 Manter Estrutura Organizacional!
O Caso de Uso UC001 modelado como Abstrato porque, muito embora esteja no Nvel de Objetivo do
usurio , ele no possui um padro de implementao que o mapeie para uma soluo
diretamente. Portanto, ele no est no Nvel de Implementao.

O utra dic a para perc ebermos que es tamos em N vel de I mpl ementao o detalhamento do C aso de U so. A baixo de um nvel P adro
de I mplementao teremos forosamente que introduzir c onceitos de Realizaes de C aso de U s o via C olaboraes do P rojeto Fsi co,
que veremos mais adiante.

O u s eja, o res ultado de us o re levante para us urios definir toda a E s trutura O rganizacional, c omposta de M atriz, Filiais, s eus
endere os - e inc luindo relao de U Fs, de apoio para es te fim.

Captulo A5

A Figura A6.15 mostra um detalhamento do Caso de Uso UC001 Manter Estrutura Organizacional,
composto por dois Casos de Uso em Nvel de Implementao e mostrados com notao e cor sugeridos
por Alistair Cockburn, para abaixo do nvel do mar. Neste nvel, so dois Casos de Uso Concretos e
para cada um deles temos solues de implementao padronizadas definidas atravs dos esteretipos,
em cada um.
Nota: Os dois Casos de Uso abaixo utilizaro padres de implementao 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 Federao (UF), e o UC001.2 manter o ciclo de vida das Unidades Organizacionais, seu endereo e
associaes, inclusive com UF.

Figura A 6.15. Casos de Uso Concret os em Nvel de Implementao.

Aqui, vale uma considerao: Esta especificao somente vlida porque, em nosso exemplo, estamos
supondo que a classe de UF no seja de uso corporativo. Em nossa hiptese, de forma simplificada, ela
serve apenas ao propsito de normalizar dados para o cadastro de Endereos de Unidades
Organizacionais.
Como Manter UF- no considerado com um Objetivo do Usurio por si, algumas consequncias
podem acontecer em nossa aplicao como, por exemplo, a classe Uf pode conter instncias de UFs
somente para as Unidades Organizacionais existentes*.
- Analisando Nveis em UC002 Registrar Funcionrios!
Se agora analisarmos o Caso de Uso UC002 veremos que o mesmo, coincidentemente, est tanto no
Nvel de Objetivo do Usurio quanto no Nvel de Implementao. Sabemos disso porque ele est
com exclamao em azul claro (!) e no est representado com ttulo em itlico.
E isso tambm verdade para todos os demais Casos de Uso, que iremos desenvolver ao longo dos
tutoriais deste livro.
- Projeto Lgico para UC001.1 Manter UF-
O primeiro Caso de Uso que desenvolveremos ser o UC001.1. Devido existncia de um padro para
este Caso de Uso, ele poder ser especificado, com preciso, simplesmente como o diagrama da Figura
A6.16.

E s te um c enrio apenas didtico. N o mundo real, para que uma empres a evite tabelas redundantes de U F, o C as o de U so
U C 0 01.1 M anter U F- teria que s er promovido para U C001 - M anter U F!, em N vel do O bjetivo do U s urio.

Entendendo a Metodologia de Desenvolvimento

Figura A 6.16. Especif icao Lgica por exceo, reutilizando o padro de implementao.

Note que a especificao acima ainda independe de implementarmos ou no em jCompany! Portanto,


ela ainda est em nvel lgico, sendo suficiente para se especificar para qualquer outro contexto
tecnolgico de desenvolvimento que defina padres neste nvel.
Outras observaes importantes:
o

A representao acima apenas uma Viso Estrutural. A Viso Comportamental,


representada tipicamente pelos Cenrios de Caso de Uso ou Diagramas de Sequncia, nem
precisa ser representada, j que no identificamos nenhuma variao importante de
comportamento com relao ao comportamento do Caso de Uso Padro Manter Classe*.

O esteretipo <<plcManClasse>> indica que o padro do Caso de Uso Manter UF- o


Manter Classe e que, portanto, nosso Caso de Uso deve herdar os cenrios deste
padro. No repositrio da ferramenta CASE existe um relacionamento de herana entre os
Casos de Uso para facilitar rastreabilidade, no representado em nosso diagrama.

Restries invariveis (que no mudam, conforme os Casos de Uso) esto


representadas junto s Entidades de Domnio. Deste modo, ficam encapsuladas, sendo
mais bem entendidas e naturalmente reutilizadas. Uma decorao importante foi a
representao de tamanhos nas propriedades, o que torna tambm a representao suficiente
para o uso de mapeamento Objeto-Relacional e definio de tamanhos padres para campos
correspondentes na interface.

Mesmo a especificao da Interface com o Usurio est sucinta, mas suficiente, j que
navegao, leiautes e barras de botes so todos padronizados na Arquitetura de Software, no
apresentando variaes em nosso caso.

Introduo ao Projeto Fsico do RH Tutorial


Incluiremos no Projeto Fsico qualquer modelo ou abstrao que possua uma dependncia de nosso
ambiente de implementao, neste caso composto por tecnologias Java EE 6 Open Source integradas e
especializadas pelo jCompany.
At aqui, como vimos, nossas abstraes para generalizaes de Casos de Uso de Manuteno de Ciclo
de Vida e Consulta de Agregaes, alm de Subcasos de Uso de Incluso e Extenso, podem ser
aplicados a qualquer tecnologia.
Iremos notar que, devido profundidade e abrangncia da Arquitetura de Software proposta no
jCompany, que padroniza e traz generalidades para todas as camadas MVC2-P, conseguiremos trabalhar
com um alto nvel de abstrao mesmo no Projeto Fsico.

P ara fac ilitar a c ompreenso deste padro de modelagem foram ins eridos dois captulos do jCompany Patterns & Met hods, no
A pndice A des te livro. C onsulte -os, por exemplo, para c onhecer a des crio dos c enrios para o C as o de U so para o padro M anter
C lasse.

Captulo A5

- Colaboraes Padres do jCompany


Alm de padres no nvel de Caso de Uso, o jCompany Patterns & Methods traz padres para
Realizaes dos Casos de Uso Padres. Estas realizaes so representadas por Colaboraes que,
na UML 2.x, so representadas como elipses com borda tracejada, como na Figura A6.17.

Figura A 6.17. Projet o Fsico para Caso de Uso UC001.1 Manter UF-.

Perceba que o diagrama acima um Projeto Fsico suficiente para nosso Caso de Uso Padro Manter UF ". um exemplo minimalista de Projeto por Exceo, que somente define uma Colaborao padro
plcTabular e inclui ainda o esteretipo no formulrio, indicando para seguir o padro de formulrio para
a Colaborao, em tecnologia XHTML.
uma especificao minimalista, to simples quanto possvel - poderamos inclusive no diagram -la, a
exceo do formulrio. De fato, quando no h muita diferenciao com relao aos padres, somente
temos que projetar o reso, evitando repeties de cenrios na especificao.
Importante: No caso acima, definimos o nome da Colaborao coincidente com o nome da URL , que
segue convenes do jCompany (/uf). Isso significa que implementaremos para Web e que teremos
uma relao um para um entre uma Colaborao e uma URL! Estas so convenes importantes
para rastreamento do projeto com implementaes em jCompany.
So as seguintes as Colaboraes Padres do jCompany:
Padres de Colaborao do jCompany
Esteretipo

Nome

Objet ivo

Manuteno: C olaboraes que implementam formulrios e operaes de M anuteno do


C ic lo de V ida de A gregaes de O bjetos, c om fluxo M VC-P generalizado em todas as c amadas.
plc T abular

T abular

Realizao um para um c om o C as o de
U s o P adro M anter C lasse, oferec endo
um formulrio e implementaes
genric as que rec uperam e atualizam
s imultaneamente todos os objetos de
uma c las se.

plc C rud

C RU D Simples

C olaborao utilizada no C aso de U s o


P adro M anter Agregao Simples,
oferec endo um formulrio e
implementaes genricas que
rec uperam e atualizam uma A gregao
que no c ontenha c omposio do tipo
M es tre-Detalhe.

plc C rudTabular

C RU D T abular

C olaborao utilizada no C aso de U s o


P adro M anter Coleo, oferec endo um
formulrio e implementa es genricas
que rec uperam uma c oleo de objetos
atravs de filtro e permitem atualizao.

plc M estreDetalhe

M es tre-Detalhe

C olaborao utilizada no C aso de U s o


P adro M anter Agregao M estre D etalhe, oferec endo um formulrio e
implementaes genricas que
rec uperam e atualizam uma A gregao
que c ontenha c omposio do tipo M estreD etalhe.

plc M antemDetalhe

M antm- Detalhe

I dem ac ima, c om o M es tre s endo apenas

Entendendo a Metodologia de Desenvolvimento

de c ons ulta.
plc Subdetalhe

M es tre-DetalheSubD etalhe

C olaborao utilizada no C aso de U s o


P adro M anter Agregao M estre D etalhe, oferec endo um formulrio e
implementaes genricas que
rec uperam e atualizam uma A gregao
que c ontenha c omposio do tipo M estreD etalhe.

plc M antemSubdetalhe

M antmSubD etalhe

I dem ac ima, c om o M es tre s endo apenas


de c ons ulta.

plc P refUsuario

P referncia do
U s urio

Realizao um para um c om o C as o de
U s o P adro M anter P referncia de
U s urio, oferec endo um formulrio e
implementaes genricas que inc luem,
rec uperam e atualizam um nic o objeto
por us urio.

plc P refAplicacao

P referncia da
A plicao

Realizao um para um c om o C as o de
U s o P adro M anter P referncia de
A plicao, oferec endo um formulrio e
implementaes genricas que inc luem,
rec uperam e atualizam um nic o objeto
por aplic ao.

Exibio/Seleo : C olaboraes que implementam formulrios e operaes de P esquisa ou


C ons ulta de A gregaes de O bjetos, c om fluxo M VC-P generalizado em todas as c amadas.
plc Selecao

Sele o

C olaborao utilizada c om os C asos de


U s o de manuten o que mantm uma
A gregao por vez para permitir
pes quisa e s eleo da agregao a s er
editada.

plc SelMantemD etalhe

Sele o P ara Manter C olaborao utilizada c om os C asos de


D etalhes
U s o de manuten o que mantm uma
A gregao por vez, c om M estre de
c ons ulta, para permitir pes quisa e
s eleo da agregao a s er editada.

plc C onsulta

C ons ulta

Realizao um para um c om o C as o de
U s o P adro C onsultar O bjetos,
oferec endo um formulrio e
implementaes genricas que
rec uperam c olees de grafos de objetos
c om bas e em amos tras de informaes
do us urio (argumentos de c onsulta).

plc Relatorio

Relatrio

Realizao um para um c om o C as o de
U s o P adro C onsultar/Imprimir
O bjetos, oferec endo um formulrio e
implementaes genricas que
rec uperam c olees de grafos de objetos
c om bas e em amos tras de informaes
do us urio (argumentos de c onsulta),
exibindo- as em formato apropriado para
impres s o

Estes diagramas de Realizao de Casos de Uso (Viso Estrutural) sero apresentados para discusso
mais detalhada, caso a caso, antes de iniciarmos o desenvolvimento de cada um deles, no prximo
mdulo.

Captulo A5

Sumrio
Neste captulo, fizemos uma breve introduo aos mtodos e padres propostos pelo jCompany,
discutindo a importncia de que sejam inseridos em um Processo de Desenvolvimento de Sistemas
verdadeiramente Iterativo.
Revimos fundamentos teis para a compreenso da Modelagem de Classes, definindo o conceito de
Grafos e Agregaes de Classes/Objetos e analisando como estes se relacionam com
documentos/formulrios corporativos. A seguir, discutimos as motivaes para automatizarmos a
Manuteno do Ciclo de Vida de Agregaes de Objetos e Consultas bsicas em MVC atravs de Casos de
Uso Padres suportados pela arquitetura e metodologia.
Relacionamos, ento, os Casos de Uso Padres do jCompany, alm de Incluses, Extenses e
Colaboraes relacionadas que utilizaremos neste livro.
Por fim, apresentamos os modelos para a aplicao RH Tutorial, em suas duas verses, enfatizando o
primeiro Caso de Uso que desenvolveremos no prximo captulo.