Desenho de Processos

ALYSSON FÉLIX RODRIGUES
UM GUIA PARA A CRIAÇÃO DE MODELOS DE
DESENHO DE SOFTWARE NO PRAXIS SYNERGIA
Belo Horizonte
21 de março de 2007
Universidade Federal de Minas Gerais
Instituto de Ciências Exatas
Programa de Pós-Graduação em Ciência da Computação
UM GUIA PARA A CRIAÇÃO DE MODELOS DE
DESENHO DE SOFTWARE NO PRAXIS SYNERGIA
Dissertação apresentada ao Curso de Pós-

Graduação em Ciência da Computação da Uni-
versidade Federal de Minas Gerais como requi-
sito parcial para a obtenção do grau de Mestre
em Ciência da Computação.
ALYSSON FÉLIX RODRIGUES
Belo Horizonte
21 de março de 2007
Resumo
O desenvolvimento dirigido por modelos é o processo pelo qual sistemas de software são cons-
truídos a partir de representações sobre seus domínios. O não sucesso de projetos de software
tem relação a aspectos únicos e especícos de cada projeto, mas todos os projetos de sucesso
são semelhantes em vários aspectos. Existem vários elementos que contribuem para um projeto
bem-sucedido; um desses componentes é a utilização da modelagem. A escolha dos modelos
a serem criados tem profunda inuência sobre a maneira como um determinado problema é
atacado e como uma solução é denida. Cada modelo pode ser expresso em diferentes níveis
de precisão. Determinar o que modelar e como modelar em sistemas complexos não é uma
tarefa fácil. Este trabalho propõe a denição de diretrizes sobre quais elementos, atributos e
visões de dados para análise e modelagem devem ser observados durante o desenvolvimento
de um software. A meta de trabalho é que as denições sejam fundamentadas em técnicas
e conceitos consagrados pela literatura, como os conceitos sobre Model Driven Architecture.
Para validar as denições sugeridas e exemplicar como as mesmas podem ser aplicadas, este
trabalho prevê também a descrição de sua aplicação no processo Praxis Synergia, para o
contexto de aplicações web.
i
Abstract
Model Driven Development is a software engineering process based on systems' domain mo-
deling. Each unsuccessful software project has it's own unique failure causes, but all successful
projects are similar at all. There are many elements that make a well done project; one of
them is modeling. Right chosen models have huge inuence on how problems are treated for
providing solutions. Models can be specied in dierent precision levels. In complex software
systems to gure out what should be modeled and how to do it isn't an easy issue. This work
proposes rules on what elements, attributes and modeling views must be observed during
the software development process. Our goal is to dene rules based on well known literature
concepts, as Model Driven Architecture. For validating the propositions and show how them
can be applied, this work contains a self applying description for web based applications and
Praxis Synergia software development process.
ii
Dedico este trabalho a meus pais, Sônia e Geraldo.
iii
Agradecimentos
Agradeço aos meus pais, sempre presentes.
Agradeço aos amigos do Synergia pelo constante auxílio e capacitação oferecidos.
Agradeço ao professor Wilson de Pádua Paula Filho pela valiosa orientação neste trabalho.
Agradeço aos professores Clarindo Isaías Pereira da Silva e Pádua e Geraldo Robson Mateus
pela conança em mim depositada e pelas inúmeras oportunidades de aprendizagem que o
Synergia tem me oferecido.
Finalmente, agradeço a todos os amigos essenciais ao meu bem estar e serenidade.
iv
Sumário
1 Introdução 1
1.1 Motivação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2 Objetivos do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.3 Limites do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 Organização deste documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Desenvolvimento dirigido por modelos 8
2.1 Modelos e processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.1 Introdução ao processo Praxis Synergia . . . . . . . . . . . . . . . . . 9
2.1.2 O arcabouço MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.2 Padrões e recomendações para o desenvolvimento dirigido por modelos . . . . 12
2.2.1 A notação UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.2 Visões de modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2.3 Padrões de desenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
v
2.2.4 Colaborações . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2.5 Arquitetura de software . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Denição das diretrizes 19
3.1 Diretrizes e o processo Praxis Synergia . . . . . . . . . . . . . . . . . . . . . . 19
4 Aplicação das diretrizes 29
4.1 Visão de desenho externo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
4.2 Visão de solução de desenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2.1 A denição e comunicação entre camadas . . . . . . . . . . . . . . . . 36
4.2.2 O modelo de domínio . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.2.3 A persistência de dados . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.4 O cadastro de itens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
5 Conclusões 49
5.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
6 Anexos 51
6.1 Informações sobre o MDSw web gabarito . . . . . . . . . . . . . . . . . . . . . 51
Referências Bibliográcas 122
vi
Lista de Figuras
2.1 Artefatos denidos pelo MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1 O ciclo de desenvolvimento no Praxis Synergia . . . . . . . . . . . . . . . . . . . 20
3.2 Exemplos de colaborações de desenho externo . . . . . . . . . . . . . . . . . . . . 25
3.3 Exemplos de mecanismos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.4 Comunicação entre camadas Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . 27
4.1 Estrutura estática Tela de Itens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
4.2 Estrutura de navegação Tela de Itens . . . . . . . . . . . . . . . . . . . . . . . . . 32
4.3 Estrutura estática Tela de Mercadorias . . . . . . . . . . . . . . . . . . . . . . . . 32
4.4 Estrutura estática Tela de Edição de Mercadoria . . . . . . . . . . . . . . . . . . 33
4.5 Visão geral Colaborações de desenho externo . . . . . . . . . . . . . . . . . . . . 33
4.6 Diagrama de estrutura Colaboração Gestão de Mercadorias . . . . . . . . . . . . 35
4.7 Padrão MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.8 Padrão MVC e camadas Praxis Synergia . . . . . . . . . . . . . . . . . . . . . . . 38
vii
4.9 Detalhes Tratador de requisição HTTP . . . . . . . . . . . . . . . . . . . . . . . . 38
4.10 Fluxo de desenho Colaboração Tratamento de Requisição de Usuário . . . . . . . 39
4.11 Detalhes Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.12 Visão geral Camada de entidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.13 Detalhes Adaptador de Sessão de Banco de Dados . . . . . . . . . . . . . . . . . 43
4.14 Detalhes Adaptador de Transação de Banco de Dados . . . . . . . . . . . . . . . 43
4.15 Detalhes Adaptador de Atualização de Objeto Persistente . . . . . . . . . . . . . 43
4.16 Detalhes Execução de Exclusão de Item . . . . . . . . . . . . . . . . . . . . . . . 44
4.17 Detalhes Execução de Salvamento de Item . . . . . . . . . . . . . . . . . . . . . . 45
4.18 Visão geral Colaborações de Cadastro . . . . . . . . . . . . . . . . . . . . . . . . 46
4.19 Visão geral Camada de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.20 Detalhes Tela de Listagem de Itens . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.21 Detalhes Tela de Edição de Item . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
6.1 Visão geral Tipos de Campos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
6.2 Visão geral Tipos de Comandos . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
6.3 Estrutura estática Caixa de Mensagem . . . . . . . . . . . . . . . . . . . . . . . . 54
6.4 Estrutura estática Elemento de Interface de Usuário . . . . . . . . . . . . . . . . 54
6.5 Diagrama Estados Tela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
viii
6.6 Diagrama Estados Painel de Itens de Edição . . . . . . . . . . . . . . . . . . . . . 56
6.7 Diagrama Estados Tela de Edição de Item . . . . . . . . . . . . . . . . . . . . . . 56
6.8 Diagrama Estados Tela de Gestão de Itens . . . . . . . . . . . . . . . . . . . . . . 57
6.9 Diagrama Estados Tela de Seleção de Itens . . . . . . . . . . . . . . . . . . . . . 57
6.10 Estrutura estática Item de Linha . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
6.11 Estrutura estática Tela de Edição de Item . . . . . . . . . . . . . . . . . . . . . . 58
6.12 Estrutura estática Tela de Itens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.13 Estrutura de navegação . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
6.14 Estrutura estática Tela Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
6.15 Visão geral Funções do produto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
6.16 Listagem de Itens - Fluxo Principal . . . . . . . . . . . . . . . . . . . . . . . . . . 62
6.17 Listagem de Itens - Subuxo Listagem de Itens . . . . . . . . . . . . . . . . . . . 63
6.18 Listagem de Itens - Subuxo Restrição de Listagem de Itens . . . . . . . . . . . . 63
6.19 Listagem de Itens com Pesquisa - Subuxo Pesquisa a Itens Cadastrados . . . . . 64
6.20 Listagem de Itens com Pesquisa - Fluxo alternativo Listagem com Pesquisa . . . 65
6.21 Gestão de Cadastro - Fluxo alternativo Alteração de Item . . . . . . . . . . . . . 66
6.22 Gestão de Cadastro - Fluxo alternativo Edição de Item . . . . . . . . . . . . . . . 67
6.23 Gestão de Cadastro - Fluxo alternativo Exclusão de Item . . . . . . . . . . . . . 68
6.24 Gestão de Cadastro - Fluxo alternativo Finalização de Edição de Item . . . . . . 69
ix
6.25 Gestão de Cadastro - Fluxo alternativo Inclusão de Novo Item . . . . . . . . . . 70
6.26 Gestão de Cadastro - Fluxo alternativo Visualização de Item . . . . . . . . . . . 71
6.27 Gestão de Cadastro com Detalhes - Fluxo alternativo Alteração de Item de Detalhe 72
6.28 Gestão de Cadastro com Detalhes - Fluxo alternativo Exclusão de Item de Detalhe 73
6.29 Gestão de Cadastro com Detalhes - Fluxo alternativo Inclusão de Novo Item de
Detalhe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
6.30 Gestão de Cadastro com Detalhes - Fluxo alternativo Seleção de Novo Item de
Detalhe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.31 Gestão de Cadastro com Detalhes - Fluxo alternativo Visualização de Item de
Detalhe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6.32 Gestão de Cadastro com Detalhes - Subuxo Edição de Item de Detalhe . . . . . 77
6.33 Estrutura estática Tela de Usuários . . . . . . . . . . . . . . . . . . . . . . . . . . 78
6.34 Estrutura estática Tela de Edição de Mercadoria . . . . . . . . . . . . . . . . . . 79
6.35 Estrutura estática Tela de Mercadorias . . . . . . . . . . . . . . . . . . . . . . . . 80
6.36 Estrutura estática Tela de Seleção de Mercadorias . . . . . . . . . . . . . . . . . 80
6.37 Visão geral Colaboração Gestão de Usuários . . . . . . . . . . . . . . . . . . . . . 81
6.38 Diagrama de Estrutura Gestão de Usuários . . . . . . . . . . . . . . . . . . . . . 82
6.39 Visão geral Colaboração Gestão de Mercadorias . . . . . . . . . . . . . . . . . . . 83
6.40 Diagrama de Estrutura Gestão de Mercadorias . . . . . . . . . . . . . . . . . . . 84
6.41 Visão geral Camada de controle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
x
6.42 Visão geral Camada de controle::cadastro . . . . . . . . . . . . . . . . . . . . . . 86
6.43 Visão geral Camada de controle::util . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.44 Visão geral Camada de entidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.45 Detalhes Adaptador Atualização de Objeto Persistente . . . . . . . . . . . . . . . 88
6.46 Visão geral Camada de fronteira . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.47 Detalhes Tela . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.48 Detalhes Tela de Listagem de Itens . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.49 Detalhes Tela de Edição de Item . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
6.50 Detalhes Gerente de Aplicação . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.51 Detalhes Tratador de Requisição HTTP . . . . . . . . . . . . . . . . . . . . . . . 91
6.52 Detalhes Adaptador Sessão de Banco de Dados . . . . . . . . . . . . . . . . . . . 92
6.53 Detalhes Adaptador Transação de Banco de Dados . . . . . . . . . . . . . . . . . 92
6.54 Visão geral Camada de sistema::mensagem . . . . . . . . . . . . . . . . . . . . . 93
6.55 Visão geral Colaboração Tratamento de Requisição de Usuário . . . . . . . . . . 94
6.56 Tratamento de Requisição de Usuário - Fluxo Principal . . . . . . . . . . . . . . 95
6.57 Visão geral Colaborações de cadastro . . . . . . . . . . . . . . . . . . . . . . . . . 96
6.58 Gestão de Cadastro de Item - Fluxo alternativo Alteração de Item . . . . . . . . 97
6.59 Gestão de Cadastro de Item - Fluxo alternativo Exclusão de Item . . . . . . . . . 98
6.60 Gestão de Cadastro de Item - Fluxo alternativo Inclusão de Novo Item . . . . . . 99
xi
6.61 Gestão de Cadastro de Item - Fluxo alternativo Salvamento de Item . . . . . . . 100
6.62 Gestão de Cadastro de Item - Fluxo alternativo Visualização de Item . . . . . . . 101
6.63 Gestão de Cadastro de Item com Detalhes - Fluxo alternativo Alteração de Item
de Detalhe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
6.64 Gestão de Cadastro de Item com Detalhes - Fluxo alternativo Exclusão de Item
de Detalhe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
6.65 Gestão de Cadastro de Item com Detalhes - Fluxo alternativo Inclusão de Novo
Item de Detalhe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
6.66 Gestão de Cadastro de Item com Detalhes - Fluxo alternativo Seleção de Novo
Item de Detalhe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
6.67 Gestão de Cadastro de Item com Detalhes - Fluxo alternativo Visualização de Item
de Detalhe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6.68 Visão geral Colaborações de listagem . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.69 Gestão de Itens - Fluxo Principal . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
6.70 Gestão de Itens com Pesquisa - Fluxo alternativo Listagem com Pesquisa . . . . 110
6.71 Visão geral Colaborações de persistência . . . . . . . . . . . . . . . . . . . . . . . 111
6.72 Exclusão de Item - Detalhe Execução de Exclusão de Item . . . . . . . . . . . . . 113
6.73 Exclusão de Item - Detalhe Execução de Exclusão de Item Ignorando Alertas . . 114
6.74 Salvamento de Item - Detalhe Execução de Salvamento de Item . . . . . . . . . . 115
6.75 Salvamento de Item - Detalhe Execução de Salvamento de Item Ignorando Alertas 116
6.76 Recuperação de Itens - Detalhe Recuperação de Item . . . . . . . . . . . . . . . . 117
xii
6.77 Recuperação de Itens - Detalhe Recuperação de Itens . . . . . . . . . . . . . . . . 118
6.78 Recuperação de Itens - Detalhe Recuperação de Itens Filtrados . . . . . . . . . . 119
6.79 Recuperação de Itens - Detalhe Totalização de Itens . . . . . . . . . . . . . . . . 120
6.80 Recuperação de Itens - Detalhe Totalização de Itens Filtrados . . . . . . . . . . . 121
xiii
Lista de Tabelas
2.1 Interessados (Stakeholders ) x Necessidades em comunicação . . . . . . . . . . . . 13
xiv
Capítulo 1
Introdução
Uma empresa de software bem-sucedida é aquela que produz software de qualidade e capaz
de atender às necessidades dos respectivos usuários. O crescimento contínuo da demanda por
produtos de software cada vez maiores e mais complexos, robustos e conáveis, tem exigido
o uso de técnicas de desenvolvimento mais apuradas. Uma empresa que consiga desenvolver
sistemas de software de maneira previsível e em determinado período, com utilização eciente
e ecaz de recursos, será uma empresa com um negócio viável.
Diante disso, sistemas de software de grande porte, extensíveis e conáveis têm sido pro-
duzidos segundo técnicas dirigidas por processos de Engenharia de Software.
Em processos de Engenharia de Software a modelagem é parte central de várias ativi-
dades que levam ao desenvolvimento de um bom software. Os modelos são construídos para
comunicar a estrutura e o comportamento do que é esperado para o sistema, visualizar e
controlar sua arquitetura, compreender melhor o sistema em elaboração, expor oportunidades
de simplicação e reaproveitamento, gerenciar riscos, dentre outros objetivos especícos.
O desenvolvimento dirigido por modelos é o processo pelo qual sistemas de software são
construídos a partir de representações, denições, sobre seus domínios. Os modelos de software
são, portanto, abstrações representativas de sistemas. Um modelo é uma simplicação da
realidade. Fornece uma cópia do projeto de um sistema e pode conter planos detalhados,
1
1. Introdução 2
assim como planos mais gerais com uma visão panorâmica do sistema considerado.
O não sucesso de projetos de software tem relação a aspectos únicos e especícos de
cada projeto, mas todos os projetos de sucesso são semelhantes em vários aspectos. Existem
vários elementos que contribuem para um projeto bem-sucedido; um desses componentes é a
utilização correta da modelagem. A modelagem é uma técnica de engenharia aprovada e bem
aceita mundialmente [Bettin, 2004, Clements et al., 2006].
Existem várias maneiras de se denir tipos de modelos. Com maior freqüência, encontram-
se modelos estruturais que ajudam a visualização e especicação de partes de sistemas e os
relacionamentos existentes entre essas partes. Atualmente, as duas maneiras mais comuns são
provenientes da perspectiva de um algoritmo ou da perspectiva orientada a objetos.
A visão tradicional no desenvolvimento de softwares adota a perspectiva de um algoritmo.
Nessa visão, o principal bloco de construção do software é o procedimento ou função. Os
desenvolvedores tem seu foco de atenção dirigido para questões referentes ao controle e à
decomposição de algoritmos maiores em outros menores. Uma grande desvantagem desta
abordagem é permitir sistemas instáveis, pois à medida que os requisitos se modicam e o
sistema cresce, ca difícil fazer a manutenção a partir do foco em algoritmos [Jacobson, 1992].
A visão contemporânea no desenvolvimento de software adota a perspectiva orientada a
objetos. Nessa visão, o principal bloco de construção de todos os sistemas é o objeto ou a
classe. De maneira simplista um objeto é alguma coisa geralmente estruturada a partir do
vocabulário do espaço do problema ou do espaço da solução; uma classe é uma descrição de
um conjunto de objetos comuns.
O método orientado a objetos para o desenvolvimento de software é, com certeza, pri-
mordial, simplesmente porque tem sido provado seu valor para a construção de sistemas em
todos os tipos de domínios de problemas, abrangendo todos os graus de tamanho e de com-
plexidade. Além disso, muitas linguagens e ferramentas da atualidade são, de alguma forma,
orientadas a objetos, fortalecendo a visão de mundo em termos de objetos. A modelagem e
desenvolvimento orientados a objetos fornecem, por m, os fundamentos conceituais para a

1. Introdução 3
montagem de sistemas de software de qualidade a partir de componentes reutilizáveis.
Uma prova da importância das atividades de modelagem é a constante adoção destes con-
ceitos em arcabouços como o Model Driven Architecture (MDA) [Klepe et al., 2003], proposto
pelo Object Management Group (OMG) [OMG, 2006a] e processos como o Rational Unied
Process [IBM, 2003] e o Praxis [Filho, 2002].
1.1 Motivação
Os modelos são construídos para compreender melhor um determinado sistema em desen-
volvimento e por isso provêem o alcance de alguns objetivos como:
• Ajudam a visualização do sistema como ele é ou como desejamos que seja.
• Permitem especicar a estrutura ou o comportamento de um sistema.
• Proporcionam um guia para a construção do sistema.
• Documentam as decisões tomadas.
O uso da modelagem tem uma vasta aplicação em todas as disciplinas de Engenharia de
Software. Porém, a experiência sugere princípios básicos de modelagem, nem sempre triviais
de serem seguidos ou alcançados.
Em primeiro lugar, a escolha dos modelos a serem criados tem profunda inuência sobre
a maneira como um determinado problema é atacado e como uma solução é denida. Em
essência, modelagem é um procedimento realizado para compreender um problema difícil,
dividindo-o em vários problemas menores solucionáveis. Portanto, modelos bem escolhidos
ajudarão de modo brilhante na resolução dos problemas de desenvolvimento mais complicados;
modelos inadequados causarão confusões, desviando a atenção para questões irrelevantes.
Segundo, cada modelo pode ser expresso em diferentes níveis de precisão. Ao desenvolver
um sistema complexo, às vezes é necessária uma visão geral para ajudar os envolvidos a
1. Introdução 4
visualizar a aparência e o funcionamento do futuro sistema. Em outras situações, pode ser
preciso retornar ao nível dos alicerces quando existe uma rotina cuja execução é crítica ou
um componente estrutural pouco comum, por exemplo.
Terceiro, os melhores modelos estão relacionados à realidade. No entanto, todos os modelos
simplicam a realidade; o segredo é ter certeza de que sua simplicação não ocultará detalhes
importantes.
Além disso, nenhum modelo único é suciente. Qualquer sistema não-trivial será melhor
analisado por meio de um pequeno conjunto de modelos inter-relacionados cada qual especí-
co a um domínio como processos de negócio, análise de requisitos, desenho de solução e
implementação. Para compreender um sistema é necessário recorrer a esses vários modelos
complementares uns aos outros. Em conjunto, os modelos representam a base do projeto do
software.
Contudo, apesar dos benefícios trazidos, a implementação das técnicas e conceitos com-
preendidos no desenvolvimento dirigido por modelos não é uma tarefa fácil.
Por um lado, existe grande quantidade de informação e complexidades envolvidas em um
software de grande porte. Há tantos aspectos a serem observados que torna-se necessário
selecionar apenas um subconjunto restrito por vez. E, essa seleção deve ser cuidadosa, pois
conceitos importantes associados às características do sistema não podem ser excluídos nem
tão pouco descritos em níveis de abstração que omitam aspectos relevantes.
Outra diculdade consiste em denir e padronizar o processo de modelagem das infor-
mações. É necessário criar e documentar os procedimentos, padronizar o uso dos elementos
disponíveis para modelagem, e estabelecer critérios para as perspectivas selecionadas. Caso
contrário, diferentes interpretações de modelagem pelas pessoas envolvidas podem inuenciar
no sistema construído, criando divergências entre o especicado e o concebido.
Por esses motivos, embora existam várias regras sobre modelagem e utilização de modelos,
ainda existem lacunas sobre como determinar o que modelar e como modelar.
1. Introdução 5
Uma possível abordagem para lidar com essas questões seria escolher não apenas um
processo de desenvolvimento de software especíco mas analisar os pontos, aspectos, comuns
a toda modelagem de sistemas de software e denir diretrizes a cerca do que deve ser modelado
e em quais níveis de abstração.
1.2 Objetivos do trabalho
A proposta principal deste trabalho consiste em denir diretrizes sobre quais elementos de
modelagem devem ser observados durante o desenvolvimento de um sistema para o contexto
de um processo de desenvolvimento de software, o Praxis Synergia [Pádua et al., 2006].
A escolha de um processo de desenvolvimento de software bem denido tem por objetivo
a estruturação e organização destas diretrizes segundo práticas e necessidades do próprio
processo, denindo e padronizando a modelagem das informações.
A meta do trabalho é que as denições de diretrizes propostas atendam aos seguintes
requisitos:
• Servir de guia, exemplo, para adaptações e aplicações em diferentes processos em de-
senvolvimento de sistemas de software.
• Ser fundamentado em técnicas e conceitos consagrados pela literatura, como os con-
ceitos sobre Model Driven Architecture [Klepe et al., 2003], e amplamente utilizados
pela comunidade de desenvolvimento de software.
Para validar as denições sugeridas e exemplicar como as mesmas podem ser aplicadas,
este trabalho prevê também a descrição de sua aplicação no processo Praxis Synergia, para o
contexto de aplicações web.

1. Introdução 6
1.3 Limites do trabalho
Não menos importante que enumerar os objetivos do trabalho é esclarecer os seus limites,
visando delimitar mais precisamente o escopo do que será abordado.
Em primeiro lugar, é importante ressaltar que o produto deste trabalho são diretrizes de
modelagem e não um modelo ou processo padrão. O processo Praxis Synergia será o processo
de desenvolvimento dirigido por modelos base para aplicação destas diretrizes.
A segunda observação é referente ao Praxis Synergia. O trabalho proposto limita-se ao
uxo de Desenho deste processo, e, especicamente ao artefato de Modelo de Desenho de
Software (MDSw).
1.4 Organização deste documento
O trabalho de denição das diretrizes seguiu uma seqüência bem denida de atividades, que
foi utilizada como base para a estruturação dos capítulos deste documento.
A primeira atividade consistiu no estudo de conceitos relacionados à área de desenvolvi-
mento dirigido por modelos, envolvendo aspectos teóricos, métodos e práticas de modelagem,
além de padrões e recomendações estabelecidos internacionalmente. O resultado desse es-
tudo é descrito no Capítulo 2, e foi utilizado como fundamentação para todo o restante do
trabalho.
A segunda atividade foi a estruturação e organização destes conceitos em diretrizes de

modelagem segundo a aplicação destes conceitos no processo Praxis Synergia. A descrição
completa das denições elaboradas encontra-se no Capítulo 3.
Em seguida, procedeu-se com a aplicação dessas mesmas diretrizes para o Modelo de
Desenho de Software (MDSw) proposto para aplicações web. A descrição completa do modelo
construído encontra-se no Capítulo 4.

1. Introdução 7
Finalmente, o Capítulo 5 apresenta as contribuições e conclusões observadas ao longo
do trabalho, além de apontar sugestões de melhorias e novos trabalhos que podem ser desen-
volvidos com base nos resultados obtidos.
O documento conta, ainda, com a seção de Anexos com informações que complementam
alguns aspectos apontados ao longo do texto.
Capítulo 2
Desenvolvimento dirigido por modelos
Este capítulo contém alguns dos conceitos e recomendações existentes na literatura sobre
desenvolvimento dirigido por modelos [Bettin, 2004], os quais foram utilizados como referência
para a elaboração deste trabalho.
2.1 Modelos e processos
O desenvolvimento dirigido por modelos é o processo pelo qual sistemas de software são
construídos a partir de representações, denições, sobre seus domínios. Modelos de software
são, portanto, abstrações representativas de sistemas. Um modelo é uma simplicação da
realidade.
Os modelos fornecem uma cópia do projeto de um sistema e podem conter planos detalha-
dos, assim como planos mais gerais com uma visão panorâmica do sistema considerado. Um
bom modelo deve incluir aqueles componentes que têm ampla repercussão e omitir os com-
ponentes menores que não são relevantes em um determinado nível de abstração. Um mesmo
sistema pode ser descrito sob diferentes aspectos, com a utilização de modelos distintos, e
cada modelo será, portanto, uma abstração semanticamente especíca do sistema.
8
2. Desenvolvimento dirigido por modelos 9
O processo de modelagem não se aplica apenas a grandes sistemas. Até os sistemas de
software mais simples poderão receber os benefícios da modelagem. Porém, é verdadeiro que,
quanto maior e mais complexo for o sistema, maior será a importância da modelagem, pois
modelos de sistemas complexos são construídos porque não é possível compreendê-los em sua
totalidade.
Neste trabalho, o processo de desenvolvimento dirigido por modelos em estudo será o
Praxis Synergia.
2.1.1 Introdução ao processo Praxis Synergia
O processo Praxis Synergia 2.1 [Pádua et al., 2006] é uma adaptação industrial do Praxis
2.0 [Filho, 2002] para o Synergia um núcleo de Engenharia de Software e Sistemas ligado ao
Departamento de Ciência da Computação (DCC) da Universidade Federal de Minas Gerais.
O Praxis é um processo completo de desenvolvimento de software, descrito em [Filho, 2002].
Baseia-se em modelos e padrões reconhecidos em Engenharia de Software, como os padrões
IEEE [IEEE, 1994], o modelo CMM [Mark et al., 1995] de maturidade de processos de soft-
ware e a notação UML [Booch et al., 2005]. É voltado principalmente para o desenvolvimento
de aplicativos grácos interativos, baseados na tecnologia orientada a objetos. O processo
abrange tanto métodos técnicos quanto gerenciais incluindo modelos de documentos e roteiros
de revisão, que facilitam a elaboração dos artefatos e sua posterior revisão.
O processo Praxis Synergia, alvo deste trabalho, será detalhado e estendido para a denição
e aplicação de diretrizes de modelagem a partir do Capítulo 3 deste texto.
2.1.2 O arcabouço MDA
O Model Driven Architecture (MDA) [OMG, 2006b, Klepe et al., 2003, Mellor et al., 2004],
especicado pelo Object Management Group (OMG) [OMG, 2006a], é um arcabouço para o
desenvolvimento de software, cujo ponto chave é a importância do uso de modelos durante o

processo de desenvolvimento de sistemas de software.
O ciclo de vida denido pelo MDA não se distancia dos ciclos de vida denidos por diver-
sos processos de desenvolvimento de software. Em geral, as mesmas fases são identicadas. A
maior diferença, porém, está na natureza dos artefatos criados durante o processo de desen-
volvimento. Os artefatos são modelos formais compreensíveis por computadores e não apenas
seres humanos. Os modelos denidos pelo arcabouço MDA são os seguintes.
Modelo Independente de Plataforma
O primeiro modelo, Modelo Independente de Plataforma Plataform Independent Model
(PIM) denido pelo arcabouço é um modelo cujo nível de abstração independe de qualquer
tecnologia de implementação.
O PIM descreve sistemas de software especícos a uma lógica de negócio. A ótica de
modelagem limita-se à aspectos inerentes ao negócio e a um domínio de aplicação; não sendo
observados detalhes de implementação como tecnologias, linguagens de programação, platafor-
mas e etc.
Modelo Especíco a Plataforma
O próximo modelo denido pelo arcabouço é o Modelo Especíco a Plataforma Plataform
Specic Model (PSM). Um modelo especíco a plataforma visa especicar o sistema de soft-
ware em detalhes de implementação em tecnologias especícas. Um PIM é transformado em
um ou mais PSMs. Para cada tecnologia especíca é gerado um PSM em separado.
Código-fonte
Como passo nal no desenvolvimento de software, tem-se a transformação de cada PSM em
código-fonte. Dada a proximidade entre o PSM e a tecnologia em uso esta geração de código
é quase direta.
Portanto, o arcabouço MDA dene os artefatos PIM, PSM e Código-fonte, especicando
como estes interagem, conforme ilustrado na gura 2.1. Um PIM deve ser criado, então
transformado em um ou mais PSMs que por sua vez são transformados em código-fonte de
sistemas de software. A habilidade em transformar um modelo PIM em PSM provê o nível
de abstração no qual um desenvolvedor pode trabalhar, pois permite ao mesmo lidar com
sistemas complexos com menor esforço.
Figura 2.1: Artefatos denidos pelo MDA
Os modelos são construídos sobre padrões abertos que compreendem parte do MDA:
• UML: notação de modelagem de análise e desenho [Booch et al., 2005, OMG, 2003b].
• Meta Object Facility (MOF) [OMG, 2003a, OMG, 2004]: notação para metamodelagem
incluindo especicação, implementação e manutenção de metamodelos independentes
de soluções, tecnologias e plataformas de domínios.
• XML Metadata Interchange (XMI) [OMG, 2002]: denição de padronização de docu-
mentação de metamodelos em documentos. É baseado na Extensible Markup Language
(XML) [Bray et al., 2000].

A automação das transformações é prevista pelo arcabouço MDA, visando lidar com
questões comuns e constantes em Engenharia de Software relacionadas a produtividade,
manutenção e documentação durante o desenvolvimento de sistemas de software.
• Produtividade, pois centra as atividades de desenvolvimento no artefato PIM. Os mod-
elos especícos as plataformas são gerados através de transformações sobre o modelo
independente de plataforma. Os detalhes de implementação podem ser desconsiderados
e postergados às especicações das transformações, que são denidas uma única vez e
aplicáveis a vários sistemas. Conseqüentemente, há menos esforço envolvido sobre o
PIM, maior foco no negócio, e ganhos em produção dada a automação provida pelas
transformações.
• Manutenção e documentação, pois o esforço se concentra nos artefatos de modelo, sendo
o código-fonte um retrato destes modelos obtido a partir de transformações sobre os mes-
mos. Portanto, a manutenção e documentação dos conceitos envolvidos estará disponível
de maneira natural.
2.2 Padrões e recomendações para o desenvolvimento dirigido
por modelos
O uso de modelos durante o desenvolvimento de software tem por objetivo ajudar a visualizar
sistemas como eles são ou como desejamos que sejam, permitir especicar estruturas ou com-
portamentos de sistemas, proporcionar guias para a construção de sistemas e documentar as
decisões tomadas. Assim, remete-se a uma tradição em Engenharia de Software: documen-
tação. Documentação implica em criação de artefatos, modelos no contexto deste trabalho.
Portanto, documentar um sistema de software torna-se uma atividade concreta.
Documentação de software é tanto prescritiva quanto descritiva. Para uns, prescreve o
que deve ser verdadeiro, denindo restrições sobre decisões a serem tomadas. Para outros,
descreve o que é verdadeiro, baseando-se em decisões tomadas sobre a modelagem do sistema
envolvido.
Compreender os diferentes propósitos da documentação é essencial para se determinar as-
pectos importantes em seu conteúdo e forma. Fundamentalmente, documentação de software
resume-se a três propósitos [Clements et al., 2006]:
• Servir como meio de capacitação. Uso educacional durante a capacitação de novas
pessoas a cerca do sistema. Os novatos podem ser novos membros da equipe, analistas
externos ou até mesmo arquitetos de software.
• Servir como veículo de comunicação entre os interessados. Uma comunicação
ecaz através da documentação proposta depende dos interessados envolvidos. Alguns
exemplos de interesses são citados na tabela 2.1.
Interessados Necessidades em comunicação

Arquitetos e En- Negociações e tomada de decisões sobre requisitos.
genheiros de re-
quisitos
Arquitetos e De- Resoluções sobre recursos disponíveis, atributos de performance e
senhistas outros tipos de variáveis de consumo de recursos.
Arquitetos e Im- Resoluções sobre soluções e restrições de implementação e unidades
plementadores de reuso de software.
Testadores e Inte- Especicações sobre a correta integração comportamental entre os
gradores componentes do sistema.
Gerentes Informações base para formação de equipes de desenvolvimento
sobre atividades identicadas e alocadas, conforme estrutura
analítica do projeto, planejamento, alocação de recursos e instru-
mentos de acompanhamento e controle de execução.
Tabela 2.1: Interessados (Stakeholders ) x Necessidades em comunicação
• Servir como base de análise do sistema. Para possibilitar análises, a documen-
tação deve conter informação necessária as especicidades dos tipos de análise execu-
tadas. Para análises de conformidade com objetivos em qualidade, a documentação deve
conter informação necessária à avaliação de atributos como segurança, desempenho, us-
abilidade, disponibilidade e estensibilidade, por exemplo.
Assim, a experiência em Engenharia de Software demonstrou, durante o passar dos anos,
algumas regras, práticas comuns, sobre documentação de software. Regras que visam organi-
zar e fomentar o correto uso de documentação em Engenharia de Software [Clements et al., 2006].
As regras citadas são:
1. Escrever a documentação a partir do ponto de vista do leitor. A documentação
é escrita uma única vez e revista algumas, se bem escrita será consumida inúmeras vezes.
2. Evitar redundância desnecessária. Cada tipo informação deve ser disposto em um
único lugar padrão, isto torna a documentação de mais fácil consumo e manutenção,
evitando confusões durante a leitura.
3. Evitar ambigüidade. A omissão e/ou excesso de detalhes que propiciem margem a
múltiplas interpretações a cerca de um mesmo ponto é prejudicial à credibilidade da
documentação proposta.
4. Usar padrões de documentação, notação. Deve ser estabelecido um esquema
padrão, estrutural, para a documentação proposta e certicar-se de que o leitor tenha
conhecimento sobre este padrão, pois isto facilita a navegação, tornando o consumo da
informação mais rápido e eciente.
5. Manter histórico de alternativas e decisões tomadas. Documentar as soluções
propostas é importante, pois alterações de requisitos e soluções são inerentes ao processo
de desenvolvimento de software e, portanto, este histórico pode poupar tempo de análise
por novas opções de solução e documentação.
6. Manter a documentação coerente e coesa mas não muito atual. Uma documen-
tação atualizada reforça o seu próprio uso e credibilidade. Porém, é oneroso mantê-la
sempre em dia. Devem ser denidos meios de atualização incremental conforme neces-
sidades e recursos disponíveis.
7. Rever a conformidade da documentação com os objetivos traçados. É im-
portante obter informações sobre o consumo da documentação proposta junto aos seus
leitores. Estas informações são importantes para evolução e manutenção dos artefatos
produzidos.
2.2.1 A notação UML
A UML [Booch et al., 2005, OMG, 2003b] (Unied Modeling Language ) é uma linguagem
padrão para a elaboração da estrutura de modelos, particularmente modelos de software.
Por ser uma linguagem, a UML é somente parte de um método para desenvolvimento
de software. A UML é independente do processo, apesar de ser perfeitamente utilizada em
processo orientado a casos de usos, centrado na arquitetura, interativo e incremental.
A notação é destinada a visualizar, especicar, construir e documentar os artefatos de um
sistema complexo de software através do uso de modelos de software, conforme abordado no
início deste capítulo. O uso da UML para elaborar modelos visa a criação de modelos explícitos
que facilitem a comunicação através de regras formais de documentação e linguagem.
A UML não é uma linguagem visual de programação, mas seus modelos podem ser di-
retamente conectados à várias linguagens de programação. Isso permite mapear os modelos
da UML em linguagens de programação tais como Java, C++, Visual Basic ou até tabelas
de bancos de dados relacionais ou o armazenamento de dados persistentes em um banco de
dados orientado a objetos.
A linguagem UML abrange três tipos de blocos de construção: itens, relacionamentos
e diagramas. Os itens são abstrações identicadas como cidadãos de primeira classe em um
modelo; os relacionamentos reúnem esses itens; os diagramas agrupam coleções sob determina
visão de itens. Para cada tipo de bloco de construção da UML existem tipos de elementos,
regras, denições e padrões de uso, conforme pode ser visto em [Booch et al., 2005]. A notação
é, portanto, aderente ao desenvolvimento dirigido por modelos, pois destina-se a visualizar,
especicar, construir e documentar os artefatos, modelos e visões, de um sistema de software.
2.2.2 Visões de modelo
Ao longo do desenvolvimento de um projeto diferentes envolvidos como usuários nais, ana-
listas, desenhistas, implementadores, testadores e gerentes de projetos trazem contribuições

próprias ao projeto e observam o sistema de maneira distinta em momentos diferentes. Assim,
visualizar, especicar, construir e documentar sistemas complexos de software são tarefas que
requerem a visualização de um sistema sob várias perspectivas; as visões de modelo. Cada
visão constitui uma projeção na organização e estrutura do sistema, cujo foco está voltado
para determinado aspecto do sistema.
Conseqüentemente, uma visão por si só não é capaz de representar todo o sistema de
software. E ainda, não é razoável imaginar visões que não possuem correlações em alguns
aspectos. A essência das visões é omitir informações não necessárias ao ponto de vista abor-
dado, porém é importante que existam relações de complementaridade entre as mesmas, pois
o conjunto de todas as visões denidas constitui a descrição dos padrões de desenho do sistema
durante seu ciclo de vida.
2.2.3 Padrões de desenho
"Cada padrão descreve um problema que ocorre inúmeras vezes em nosso ambiente, e então
descreve o ponto central da solução para este problema, de maneira que esta solução pode ser
usada milhões de vezes durante o passar do tempo, sem que seja empregada da mesma maneira
duas vezes" - Christopher Alexander [Alexander et al., 2007].
Embora o autor desta frase estivesse se referindo a padrões em construção civil, o que
ele diz é aplicável a padrões de desenho de software. As soluções de software propostas são
expressas em termos de objetos e interfaces ao invés de paredes e portas, mas o objetivo de
ambos os padrões é a solução para um problema em um dado contexto.
Em geral padrões de desenho possuem quatro elementos essenciais [Gamma et al., 2003]:
1. Nome. O nome de um padrão é usado para descrever o problema abordado, sua solução
e conseqüências.
2. Problema. O problema descreve o cenário onde o padrão é aplicável, expondo as questões
e contexto envolvidos.
3. Solução. A solução descreve os elementos de desenho, seus relacionamentos, responsabi-
lidades e colaborações que satisfazem as condições impostas pelo problema. A solução
não é uma solução de desenho e implementação em particular, pois um padrão oferece
um gabarito aplicável a diferentes situações que retratam o mesmo problema.
4. Conseqüências. As conseqüências são os resultados e relações de custo-benefício de
aplicação do padrão. Essas relações são essenciais para análise de alternativas de desenho
e entendimento das conseqüências da aplicação do padrão.
Um padrão de desenho nomeia, cria abstrações e colaborações, e identica pontos chave
a respeito de estruturas de desenho que são úteis durante a criação de desenhos reutilizáveis.
O padrão de desenho identica as classes participantes e suas instâncias, seus papéis e co-
laborações, e a distribuição de responsabilidades. O gabarito oferecido foca em um problema
de modelagem especíco, especicando quando pode ser aplicado, se deve ser aplicado diante
de determinadas restrições de desenho, e as conseqüências de sua aplicação. Cada padrão é
relativamente independente, mas os padrões não são isolados uns dos outros. É comum o uso
de um padrão propiciar o uso de outros ou outros só serem aplicáveis na presença de alguns
[Gamma et al., 2003].
2.2.4 Colaborações
No contexto de desenvolvimento de um sistema, uma colaboração permite nomear um agru-
pamento conceitual que abrange aspectos estáticos e dinâmicos. Uma colaboração nomeia um
conjunto de classes, interfaces e outros elementos que trabalham em conjunto para fornecer
algum comportamento cooperativo maior do que a soma de todas as suas partes. As co-
laborações são empregadas para especicar a realização de casos de uso e operações e para
fazer a modelagem de mecanismos signicativos da arquitetura de sistemas. Uma colab-
oração é denida através de um nome, estrutura e comportamento, conforme denido em
[Booch et al., 2005]. O conjunto de padrões de desenho e suas colaborações constituem a
arquitetura de software de um sistema.

2.2.5 Arquitetura de software
Arquitetura de software é, ao mesmo tempo, o componente que faz com que as partes de
um sistema trabalhem juntas como um todo e com sucesso; e, é o padrão organizacional
fundamental de um sistema e seus componentes, seus inter-relacionamentos e relacionamentos
com o ambiente e princípios diretores de desenho e evolução [IEEE, 2000].
Arquitetura é, portanto, desenho, mas nem todo desenho (design ) é arquitetura. Muitas
decisões de solução são postas de lado pelo desenho arquitetural e deixadas a cargo do bom
senso e compreensão dos desenhistas e implementadores. A arquitetura estabelece restrições
sobre as atividades de desenho a serem realizadas, e estas atividades devem produzir artefatos
aderentes com as denições arquitetônicas, mas a arquitetura não nos diz como isso deve ser
implementado.
Quais as decisões de desenho são arquiteturais? Quais as questões e decisões de solução
devem ser postergadas ao julgamento dos demais? A denição de Arquitetura de Software
citada a seguir fornece alguns pontos a serem observados que podem nos ajudar a responder
estas perguntas.
"Arquitetura de software é a estrutura de estruturas de um sistema, cada qual contendo

componentes, propriedades externamente visíveis destes componentes, e as suas relações entre
si" [Clements et al., 2006]. Então, se uma propriedade de um elemento arquitetural não é
visível, ou perceptível, a qualquer outro elemento arquitetural, este elemento não é arquite-
tural.
Capítulo 3
Denição das diretrizes
Para guiar a seleção dos elementos que irão compor o conjunto base para denição de diretrizes
sobre o desenvolvimento dirigido por modelos (DDM), este trabalho seguiu a denição de
seqüência de atividades de desenho e implementação proposta pelo próprio processo Praxis
Synergia.
Cada atividade, conceitos envolvidos, assim como contexto de aplicação são apresentados,
detalhados e estendidos para a denição de diretrizes de modelagem. O objetivo é, então,
denir o que modelar durante o desenvolvimento dirigido por modelos, e, para isso, quais
elementos de modelagem devem ser observados, denindo como modelar e dispor cada item.
3.1 Diretrizes e o processo Praxis Synergia
O Praxis Synergia 2.1, assim como o Praxis 2.0 [Filho, 2002], usa o conceito de fases e uxos
(disciplinas), inspirados nos elementos correspondentes do Processo Unicado [Jacobson et al., 1999],
com o intuito de utilizar a mesma nomenclatura deste processo. E ainda, dene as iterações
Ativação, Modelagem de Negócios, Identicação de Requisitos, Levantamento de Requisitos,
Análise de Requisitos, Desenho Implementável, Liberações, Testes Alfa, Testes Beta e Oper-
ação Piloto. As iterações são marcos, agrupamentos, conceituais e temporais para os grupos
19
3. Definição das diretrizes 20
de atividades executadas ao longo de cada fase do processo.
A gura 3.1 ilustra a relação entre as fases e uxos para o Praxis Synergia. As fases são
executadas ao longo do tempo de forma seqüencial, abrangendo atividades dos diversos uxos.
A diferença é que, dependendo da fase, as atividades de um mais uxos são predominantes em
relação aos demais. As atividades do uxo de Implementação, por exemplo, concentram-se
na fase Construção.
Figura 3.1: O ciclo de desenvolvimento no Praxis Synergia
O uxo de Desenho, uxo abordado neste trabalho, tem por objetivo prover uma estrutura
implementável para um produto de software que atenda aos requisitos especicados para
ele. O foco é a concepção de estruturas e mecanismos (modelos) robustos, que tornem a
implementação mais conável e produtiva. A disciplina abrange as atividades de desenho
arquitetônico, desenho das interfaces, detalhamento dos casos de uso, desenho das entidades,
desenho da persistência, realização dos casos de uso, desenho das liberações e revisão do
desenho.
O desenho arquitetônico tem por objetivo resolver aspectos estratégicos de desenho externo
e interno denindo a divisão do produto em subsistemas e escolhendo as tecnologias mais
adequadas. O desenho das interfaces visa o desenho em detalhe das interfaces reais do produto
em seu ambiente denitivo de implementação. E, o detalhamento dos casos de uso, resolve
os detalhes dos uxos dos casos de uso, considerando os componentes reais das interfaces e
todos os uxos alternativos.
O desenho das entidades tem por objetivo transformar as classes de entidade do Modelo
de Análise nas classes correspondentes do Modelo de Desenho. O desenho da persistência
contempla o desenho das estruturas externas de armazenamento persistente, como arquivos
e bancos de dados. A realização dos casos de uso determina como os objetos das classes
de desenho colaborarão para realizar os casos de uso de desenho. O desenho das liberações
determina como a implementação do produto será dividida entre as liberações. E, por m, a
revisão do desenho visa validar os resultados do Desenho, confrontando-os com os resultados
dos Requisitos e da Análise.
Os aspectos citados, são documentados através do artefato Modelo de Desenho de Software
(MDSw). O MDSw representa a continuidade do Modelo de Análise de Software (MASw)
produzido durante o uxo de Análise, porém com maior nível de detalhes. No MDSw as estru-
turas de solução do domínio são introduzidas e passam a ser descritas de forma mais detalhada
quando é necessário resolver questões de solução. Os casos de uso, requisitos funcionais do
sistema, passam a se referir aos detalhes de interfaces de usuário, e são considerados aspectos
como relacionamentos, navegabilidade, controle de acessos e contratos de serviços disponíveis.
Diante deste cenário, para o MDSw propõe-se a seguir um série de diretrizes de estrutu-
ração e organização de conteúdo visando denir melhor como cada elemento a ser modelado
deve ser disposto. A preocupação com a estruturação e organização através de diretrizes tem
o objetivo de garantir duas propriedades operacionais essenciais:
• Comunicação: de posse das diretrizes, outras pessoas devem ser capazes de saber o
que foi padronizado, como isso foi feito, e o que foi incluído e excluído na abordagem
de estruturação proposta.
• Repetição: de posse das denições feitas, outras pessoas devem ser capazes de realizar
as mesmas atividades e alcançar essencialmente os mesmos objetivos visados pelas di-

retrizes apontadas.
Se a denição das diretrizes não garantir a padronização, a interpretação dos resultados
torna-se inviável, pois é necessário que os padrões de modelagem estejam bastante claros para
se obter qualquer conclusão prática. Se, por outro lado, a repetição não for garantida, o valor
dos padrões e diretrizes criados ca dependente da interpretação do responsável por seu uso.
Organização do Modelo de Desenho de Software
A visualização, especicação, construção e documentação de sistemas complexos de software
requerem a análise desses sistemas sob várias perspectivas. Desta necessidade surge a primeira
diretriz para uso no MDSw:
• Separação lógica entre as diferentes perspectivas de modelagem em visões, através do
uso de pacotes especícos a cada perspectiva de análise.
E ainda, com o objetivo de dimensionar adequadamente os níveis de detalhamento e
abstração necessários para modelar cada visão é importante denir, em conformidade com os
conceitos apresentados no Capítulo 2:
1. Enfoque associado a visão.
2. Padrões de modelagem associados a cada visão.
3. Elementos participantes, para cada padrão de modelagem associado a cada visão.
4. Colaborações, para cada elemento participante de cada padrão de modelagem associado
a cada visão.
O Praxis distingue duas visões principais de modelagem: a visão de desenho externo e a
visão de desenho interno. A primeira visa abordar a descrição estrutural e comportamental
dos casos de uso do sistema conforme é visto pelos seus usuários nais. A documentação
é centrada nas interações entre o usuário e as interfaces de usuário. A segunda, visão de
desenho interno, tem por objetivo abordar aspectos de implementação para uma solução de
implementação proposta. É uma visão especíca à tecnologia e plataforma de desenvolvimento
escolhidas. Para o Praxis Synergia propõe-se a divisão do MDSw em três visões principais:
desenho externo, solução de desenho, e implementação.
A visão de desenho externo, semelhante por denição a mesma visão no Praxis, não
determina realmente a organização do sistema de software. No entanto, ela existe para especi-
car como será a solução dada aos requisitos do sistema segundo visto pelos usuários nais.
É dividida em subseções, cada qual com um propósito, diretriz, especíco.
Assim, para o desenho externo são denidos os seguintes padrões de modelagem e enfoque
aplicáveis a cada subseção descrita em seqüência:
• Uso de pacotes especícos a cada propósito de análise, para orientar o agrupamento de
informações e conceitos. O pacote Componentes das interfaces de usuário, por exemplo,
para descrever as relações estáticas e de navegação entre as interfaces de usuário.
• Uso de pacotes para subdividir os contratos de desenho (soluções de desenho para os
casos de uso) de acordo com as especicações dos contratos e, uso de pacotes para
subdividir as realizações dos casos de uso, mantendo estruturas de subpacotes para
cada realização.
• Uso de nomes de pacotes e classes escritos na forma correta denida pela linguagem
natural em uso para descrever os itens de desenho mapeáveis aos itens de análise. Acen-
tuações, espaços entre as palavras, letras maiúsculas e minúsculas devem ser considera-
dos.
Subseção Aspectos gerais do processo: são descritos os aspectos do perl dos
usuários que inuenciaram o desenho das interfaces do produto. Essa informação deve ser
consistente com as informações disponíveis no Modelo de Análise de Software (MASw), porém
em um nível maior de detalhes, resultante dos estudos de usabilidade do produto, por exemplo.
Subseção Aspectos gerais do produto: são descritos os aspectos gerais do produto
aplicáveis a todos os requisitos, casos de uso do sistema. Padrões comportamentais e estrutu-
rais podem ser descritos nesta seção através de documentação textual ou através do uso dos
recursos da linguagem UML.
Subseção Componentes das interfaces de usuário: são descritas as relações estáti-
cas entre as classes que representam as interfaces de usuário e como é possível navegar entre
os objetos da mesmas.
Diagramas de estrutura estática, diagramas de classes em UML, descrevem os relaciona-
mentos de agregação e composição existentes entre as classes de interfaces de usuário. Os
diagramas de navegação, diagramas de classes em UML, descrevem as ativações das classes de

interfaces de usuário através de relacionamentos de associação com o estereótipo navigate.
Quando o comportamento da interface não é óbvio, conforme estado, diagramas de grácos
de estados são usados. Em geral, os diagramas de grácos de estados são usados para explicar
o comportamento de interfaces cujos comandos possam estar desabilitados ou que variem de
aspecto conforme estado.
E o detalhamento dos campos das interfaces de usuário é tipicamente feito com pro-
priedades dos estereótipos como eld e command. Faz-se, ainda, o uso de protótipos
de desenho externo para ilustrar as ativações e estados das interfaces de usuário. Os
protótipos são intermediários a solução nal.
Subseção Funções do produto: são descritas as funções do produto, detalhando os
casos de uso em colaborações de uso. Essas colaborações de uso são descritas em nível de
detalhe muito maior, com referências aos elementos das interfaces de usuário. Apenas aspectos
visíveis ao usuário devem ser mostrados. São modelados: restrições de acesso, uxo principal
e uxos secundários, diagramas de grácos de estados, condições de exceção e mensagens. Os
casos de uso de desenho são descritos através do uso de colaborações da UML, as colaborações
de desenho externo.
Figura 3.2: Exemplos de colaborações de desenho externo
Os uxos dos casos de uso de análise são realizados através de interações das colaborações
de uso. As interações são realizações, e, como tal, podem ter aparência muito diferente dos
uxos que realizam; apenas o comportamento externo é o mesmo.
Listas de condições de exceção descrevem as possíveis condições anormais de uso. As listas
de mensagem contêm as possíveis mensagens de tratamento diante das exceções. A documen-
tação das condições de exceção e das mensagens é feita de maneira textual, tipicamente em
planilhas.
O uso de colaborações de desenho externo, na visão de desenho externo, tem por objetivo
descrever as realizações dos casos de uso sob a ótica de interação entre as interfaces de usuário
e usuário. E o uso de diagramas de uxo de desenho, visa descrever os uxos principais e uxos
complementares (uxos alternativos e subuxos) dos casos de uso.
Por m, planilhas de exceções e mensagens de desenho externo, descrevem as condições
anormais de uso de uma determinada função e mensagens de tratamento exibidas ao usuário.
Já a visão de solução de desenho tem por objetivo abordar a modelagem da solução

de desenho para a lógica de negócio envolvida independentemente da solução tecnológica a ser
adotada, em conformidade com a proposta prevista pelo arcabouço Model Driven Architecture.
Figura 3.3: Exemplos de mecanismos
Ao fazer a modelagem desta perspectiva é realizada, de fato, a modelagem da infra-
estrutura de uma arquitetura inteira que se planeja reutilizar e adaptar, transformar, em
um determinado contexto. A denição deve ser baseada, portanto, em mecanismos, padrões
de projeto e arcabouço oferecido.
Conforme abordado no segundo capítulo deste trabalho, um padrão de projeto deve
fornecer uma solução comum para um problema básico em um determinado contexto. Um
mecanismo é um padrão de projeto aplicado a uma sociedade de classes. Interfaces de usuário,
interfaces com bancos de dados, interfaces de comunicação de dados, interfaces de dispositivos,
o uso de serviços do sistema operacional, dentre outros podem caracterizar padrões e mecan-
ismos arquitetônicos. O desenho de tais mecanismos deve ser, conseqüentemente, considerado
em processos como o Praxis Synergia segundo diretriz sugerida a seguir:
• Modelar mecanismos como colaborações em UML com enfoque em aspectos arquitetôni-
cos da solução de desenho. A gura 3.3 ilustra exemplos de mecanismos, colaborações,
para persistência de dados em bancos de dados.
E ainda, o conjunto de mecanismos fornece um arcabouço (framework ). Um arcabouço é
um padrão arquitetural que fornece um gabarito extensível à aplicações dentro de um domínio.

A denição do arcabouço deve determinar aspectos estratégicos quanto à separação de com-
ponentes em pacotes lógicos. Os pacotes lógicos devem encapsular classes correlatas de acordo
com um critério signicativo, facilitar o arquivamento e recuperação das classes, agrupar-se
em torno das principais funções arquitetônicas e facilitar a divisão de trabalho de desenho
e implementação. Portanto, sistemas bem-estruturados são repletos de padrões de projeto,
para os quais destacam-se as seguintes diretrizes propostas para o Praxis Synergia:
• Uso de cinco camadas (layers ) arquiteturais, vide gura 3.4, como esquema de agru-
pamento de informações e conceitos de solução dentro do domínio de uma aplicação
qualquer. Classes de fronteira implementam as interfaces do produto. Classes de cont-
role implementam aspectos especícos, como uxos de casos de uso, lógica e algoritmos.
Classes de entidade implementam unidades de informação potencialmente reutilizáveis
dentro de um domínio e freqüentemente persistentes. Classes de persistência convertem
dados entre a camada de entidade e os mecanismos físicos de persistência, como banco
de dados ou arquivos. Classes de sistema implementam serviços comuns utilizados por
outras classes.
• Uso de diagramas de visão geral, por componente e pacotes, que agrupam semantica-
mente elementos de modelo. Esta regra é aplicável tanto em agrupamentos baseados
em orientação por funcionalidade do domínio de negócio quanto em agrupamentos por
camada arquitetural.
Figura 3.4: Comunicação entre camadas Praxis

• Uso invertido da nomenclatura de nomes de domínios na internet como nomes de pacotes
no modelo de desenho. Objetivos: criar cenários para aplicações dirigidas por modelo,
prover o reuso desses cenários, e servir de base para subseqüente transformações em
código-fonte (destino físico de código-fonte e mapeamento de nomes).
• Uso de nomes de pacotes e classes escritos na forma correta denida pela linguagem
natural em uso, na visão de solução de desenho, suprimindo os espaços entre as palavras.
Quando a tecnologia impor restrições aos nomes documentar essas restrições no processo,
com referência explícita a à origem das restrições, e segregar as classes cabíveis em
pacotes dependentes de tecnologia.
• Uso de nomes de pacotes escritos em letras minúsculas, na visão de solução de desenho,
para facilitar a diferenciação entre pacotes e classes.
• Uso de nomes diferentes para Interfaces e os Componentes ou Classes que as realizam,
na visão de solução de desenho. Esta não é uma regra essencial ao modelo, mas é uma
boa prática para geração de código legível.
• Uso de colaborações de desenho interno, na visão de solução de desenho, para descrever
as realizações dos mecanismos e padrões arquitetônicos.
Finalmente, a visão de implementação contempla aspectos de implementação para a
modelagem da solução de desenho proposta. Visão especíca à tecnologia e plataforma de
desenvolvimento escolhidas. Segue as denições de conteúdo propostas para a visão de solução
de desenho, porém com enfoque em aspectos de implementação, tecnologia e plataforma.
Camadas (layers ) arquiteturais, podem ser denidos através de execuções de transformações
a partir da visão de solução de desenho.
Essa visão, segundo arcabouço MDA, deve ser obtida através de execuções de transfor-
mações sobre a visão de solução de desenho. As transformações podem ser realizadas sobre o
próprio MDSw criando a visão em questão ou podem criar um novo modelo que a contenha
em separado. A junção das visões no MDSw visa facilitar o entendimento desta abordagem,
diante desta documentação.

Capítulo 4
Aplicação das diretrizes
Este capítulo exemplica como as diretrizes para criação de modelos podem ser aplicadas. Isto
é feito através da criação de um gabarito para modelos de desenho de sistemas de software
para a web.
Os objetivos que motivaram a aplicação das diretrizes para sistemas web foram:
• Exemplicar como as diretrizes, apresentadas no Capítulo 3, podem ser aplicadas ao
contexto de um cenário real.
• Fornecer os subsídios necessários, ao processo Praxis Synergia, para a adoção gradual
das práticas e técnicas abordadas.
O Praxis 2.0 padrão inclui como exemplo de uso do processo os artefatos produzidos
para uma aplicação destinada ao controle de vendas, compras, fornecedores e estoque de
uma mercearia. Esta aplicação é chamada Merci. As estratégias propostas neste trabalho
foram exercitadas e validadas através da modelagem dos casos de uso Gestão de Usuários e
Gestão de Mercadorias desta aplicação. Para distinguí-lo do Merci, chamamos este produto
de Merci-Web.
A aplicação das diretrizes contempla as atividades de desenho arquitetônico, desenho das
29
4. Aplicação das diretrizes 30
interfaces, detalhamento dos casos de uso, desenho das entidades e realização dos casos de uso
segundo as visões de desenho externo, solução de desenho e implementação, em acordo com
as denições presentes no terceiro capítulo deste trabalho.
Para facilitar a leitura deste capítulo, apenas os diagramas de modelo mais estratégicos
serão exibidos. O conjunto completo de diagramas obtido está disponível na seção de Anexos.
4.1 Visão de desenho externo
Enfoque: Detalhar o desenho das interfaces com os usuários, mostrando-se a realização dos
casos de uso de análise em termos dessas interfaces, assim como a estrutura dos componentes
de interface através das colaborações de uso.
Padrões, elementos participantes, colaborações por pacote (sub-visão):
praxis.cliente. Denições gerais de reuso de desenho externo para aplicações web.
praxis.cliente.Aspectos gerais de processo.Tipos. Denições de tipos de campos e co-
mandos de interfaces de usuário para aplicações web como Linha de Texto, Caixa de
Texto, Botão de Apertar, Hiperligação e outros.
praxis.cliente.Componentes das interfaces de usuário.Básicos. Denições de tipos bási-
cos de interfaces de usuário como Tela, Tela de Edição, Conjunto de Abas, Caixa de
Mensagens e outras.
praxis.cliente.Componentes das interfaces de usuário.Cadastro. Denições de tipos
de interfaces de usuário para cadastro como Tela de Edição de Item, Tela de Gestão de
Itens, Tela de Seleção de Itens e outras.
praxis.cliente.Componentes das interfaces de usuário.Principal. Denições sobre a in-
terface de usuário central ao sistema, a Tela Principal, e os itens de cardápio (Item de
cardápio ) presentes no menu principal.

praxis.cliente.Funções do produto. Denições de colaborações base de desenho externo
como Listagem de Itens, Listagem de Itens com Pesquisa e Gestão de Cadastro, dentre
outras.
com.uhackers.merci. Cenário para a aplicação Merci-Web. As denições de sub-pacotes
seguem as denições previstas na seção 3.1, ou seja, Aspectos gerais de processo, Aspectos
gerais do produto, Componentes das interfaces de usuário, Funções do produto.
Cada sub-visão apresenta diagramas especícos que descrevem as relações estruturais e
comportamentais das interfaces de usuário, assim como o detalhamento das colaborações de
uso.
Para as denições de tipos de interfaces de usuário para cadastro, por exemplo, temos os
seguintes diagramas de estrutura estática e navegação:
Figura 4.1: Estrutura estática Tela de Itens

Figura 4.2: Estrutura de navegação Tela de Itens
Para as denições de interfaces de usuário de cadastro no Merci-Web, temos a aplicação
destas denições de reuso (praxis.cliente) aos casos de uso contemplados; como por exemplo
o caso de uso Gestão de Mercadorias:
Figura 4.3: Estrutura estática Tela de Mercadorias

Figura 4.4: Estrutura estática Tela de Edição de Mercadoria
Como denições base para reuso de colaborações em desenho externo (praxis.cliente.Funções
do produto), tem-se as colaborações:
Figura 4.5: Visão geral Colaborações de desenho externo

As colaborações Listagem de Itens, Listagem de Itens com Pesquisa, Gestão de Cadastro
e Gestão de Cadastro com Detalhes constituem as colaborações gabarito para reuso durante
o desenho externo. As colaborações gabarito visam abstrair alguns aspectos estruturais e
comportamentais, de uma colaboração plena, de uma maneira completamente independente
de domínio. Assim, através das colaborações gabarito é possível vincular as abstrações a um
determinado contexto.
Os uxos de desenho de cada colaboração base, assim como todo o restante do arcabouço
de desenho externo, estão descritos no capítulo de Anexos.
Para o caso de uso Gestão de Mercadorias tem-se, por exemplo, a aplicação das denições
previstas pelas colaborações base de desenho externo conforme descrito na gura 4.6.
4. Aplicação das diretrizes
Figura 4.6: Diagrama de estrutura Colaboração Gestão de Mercadorias
35
4.2 Visão de solução de desenho
Enfoque: Detalhar aspectos signicativos do desenho interno do produto, descrevendo a
estratégia de arquitetura e diagramas das principais decisões de desenho.
As seções a seguir descrevem os mecanismos previstos para a arquitetura de software
segundo a aplicação das diretrizes previstas, vide Capítulo 2.
4.2.1 A denição e comunicação entre camadas
A arquitetura de um produto expressa uma divisão desse produto em pacotes lógicos e sub-
sistemas. A denição das camadas abrange um conjunto de decisões signicativas como a
organização do sistema de software; a seleção dos elementos estruturais e suas interfaces; seu
comportamento, conforme especicado nas colaborações entre esses elementos e a composição
desses elementos.
O padrão Model View Controller (MVC) [Fowler, 2005] é o padrão adotado por este tra-
balho como padrão conceitual de macro denição e comunicação entre camadas.
Figura 4.7: Padrão MVC

O MVC dene uma solução para o domínio abordado onde o acesso aos dados é indepen-
dente do tipo de cliente. Todos os clientes devem ter acesso a lógica de negócio especicada.
E, um novo tipo de cliente ou a alteração de um tipo existente não deve inuenciar nos de-
mais componentes do sistema. Este é o cenário real de aplicações web, onde há um número de
clientes potencialmente grande acessando o sistema, via redes como a Internet ou intranets,
através de seus navegadores (aplicações clientes).
O padrão provê a separação entre o acesso aos dados e a representação dos mesmos através
da denição de três camadas (gura 4.7): model, view e controller.
• A camada view tem acesso aos dados através da camada model e é responsável pela
denição da lógica de apresentação.
• A camada controller deve interagir com a camada view convertendo ações requeridas
em serviços disponibilizados pelo model.
• A camada model é a responsável pela denição e implementação da lógica de domínio
inerente ao negócio.
É importante notar que a camada controller do MVC, por denição, não corresponde a
camada de controle do Praxis Synergia. A primeira, visa suportar e prover a interatividade
entre as interfaces de usuário (views ) e os usuários. A segunda, visa a implementação de
aspectos especícos do domínio, como uxos de casos de uso, lógica e algoritmos. A gura
4.8 descreve o acoplamento entre as camadas Praxis Synergia e o padrão MVC.

Figura 4.8: Padrão MVC e camadas Praxis Synergia
A camada controller, portanto, está associada a mecanismos de conversão entre as ações
requeridas pelos usuários em operações disponíveis no modelo camadas controle, entidade,
persistência e sistema no Praxis Synergia. Em aplicações web complexas existem várias ações
a executar ao receber múltiplas requisições de usuário, em especial ações para prover as
interfaces de usuário aos usuários.
O padrão Front Controller visa consolidar mecanismos de conversão entre as ações requeri-
das pelos usuários em operações disponíveis no modelo através da centralização do tratamento
das requisições em um único objeto, o request handler tratador de requisições. As guras
4.9 e 4.10 retratam o padrão de desenho em questão.
Figura 4.9: Detalhes Tratador de requisição HTTP

Figura 4.10: Fluxo de desenho Colaboração Tratamento de Requisição de Usuário
O tratador de requisições é responsável por determinar qual ação disponível no con-

troller deve ser acionada dada uma requisição qualquer. As ações são encapsuladas em múlti-
plos objetos, os front controllers controladores frontais.
Os controladores frontais são responsáveis por determinar qual operação disponível no

modelo deve ser acionada dada uma ação qualquer.
Estes padrões de desenho constituem o conjunto de macro decisões signicativas para a
denição e comunicação entre camadas para a arquitetura de aplicações web proposta. A
gura 4.11 a seguir apresenta a visão geral destas denições.

Figura 4.11: Detalhes Arquitetura
4.2.2 O modelo de domínio
Em sistemas de grande porte a lógica de negócio é, em geral, muito complexa. Regras des-
crevem diferentes aspectos estruturais e comportamentais envolvidos em cada aspecto de
domínio. O padrão Domain model [Fowler, 2005], modelo de domínio, dene uma rede de ob-
jetos interconectados, onde cada objeto representa algum conceito singular, para representar
a lógica de negócio de um sistema de software.

Figura 4.12: Visão geral Camada de entidade
O uso do padrão em aplicações é orientado por camadas, layers. Para o Praxis Syner-
gia a respectiva camada é a camada de entidade. As classes de entidade implementam as
unidades de informação potencialmente reutilizáveis dentro de um domínio e freqüentemente
persistentes.
Para a camada de entidade proposta, são denidas classes e interfaces para representar
abstrações sobre os dados e lógica de um domínio qualquer. A classe EntidadeAbstrata é
o tipo abstrato padrão do qual todos os demais objetos de um domínio devem herdar. A
classe ColeçãoAbstrata é responsável por encapsular as colaborações de negócio inerentes ao
domínio, como as regras para criação e recuperação de objetos por exemplo.
As entidades devem, ainda, implementar a interface InterfaceEntidade, conforme visto na
gura 4.12. Esta interface contém, em especial, métodos especícos para a implementação
de regras de negócio inerentes às validações de salvamento e exclusão de objetos assim como

regras inerentes à execução de salvamento e exclusão dos mesmos. Os métodos são, respec-
tivamente: validarSalvamento, validarExclusão, executarSalvamento e executarEx-

clusão.
Os métodos de validação são responsáveis por executar regras que identiquem condições
que violem a respectiva operação requerida. Os métodos de execução são responsáveis por
implementar regras de dependências entre objetos, como por exemplo composições onde há
uma dependência de ciclo de vida entre um objeto e suas partes (outros objetos). Em casos
de violação destas regras uma lista de mensagens informativas é criada para exibição nas
interfaces de usuário envolvidas. Estes mecanismos são acionados pelo serviço de persistência
de dados, conforme será descrito na seção a seguir.
4.2.3 A persistência de dados
Armazenar, recuperar, atualizar e excluir dados em bancos de dados, em geral, são atividades
típicas em sistemas de software. Para isso, a arquitetura de software deve prover mecanismos
de persistência de dados, através de contratos de serviços bem denidos. O conjunto de
contratos, interfaces, fornecidos constituem a camada de persistência.
Um arcabouço arquitetônico pode prover sua própria camada de persistência ou pode
utilizar um subsistema de software como serviço de persistência de dados. As denições apre-
sentadas nesta seção baseiam-se no uso de subsistemas de persistência orientados a objetos.
Uma prática comum de desenho é diminuir a comunicação e dependências entre os diversos
subsistemas que compõem um sistema. O padrão Adapter [Gamma et al., 2003], adaptador,
converte uma interface requerida do subsistema em uma interface esperada por um cliente,
denindo uma interface em alto nível que diminui o acoplamento entre o sistema e o subsistema
em uso.
Cada adaptador criado dene uma interface de acesso a uma determinada interface do
subsistema de persistência, provendo serviços para armazenar, recuperar, atualizar e excluir
dados; conforme descrito abaixo.

Figura 4.13: Detalhes Adaptador de Sessão de Banco de Dados
Figura 4.14: Detalhes Adaptador de Transação de Banco de Dados
Figura 4.15: Detalhes Adaptador de Atualização de Objeto Persistente
Em especial, o AdaptadorAtualizaçãoDeObjetoPersistente dene mecanismos para a exe-
cução e validação de regras de domínio de salvamento e exclusão de objetos persistentes.
Ao acionar os serviços oferecidos por este adaptador, o mesmo é responsável por delegar a
execução destas regras ao objeto persistente, conforme descrito pelos diagramas 4.16 e 4.17.
44
Figura 4.16: Detalhes Execução de Exclusão de Item
45
Figura 4.17: Detalhes Execução de Salvamento de Item
4.2.4 O cadastro de itens
Em aplicações de software que envolvem cadastro de dados é comum a presença de operações
como criar, recuperar, atualizar e remover itens de cadastro em alguns casos de uso. Estes
casos de uso são chamados de casos de uso CRUD (Create, Retrieve, Update, Delete ). Por
serem funcionalidades típicas e em geral independentes do item a cadastrar, é possível criar
mecanismos gerais aplicáveis a maioria dos casos de uso CRUD. Estes mecanismos foram
representados pelas colaborações Gestão do Cadastro de Item e Gestão do Cadastro de Item
com Detalhes.
Figura 4.18: Visão geral Colaborações de Cadastro
Os uxos de desenho interno destas colaborações, vide Anexos, descrevem como são re-
alizadas as operações de criação de novo item, recuperação, atualização e remoção de itens
cadastrados.
As classes e interfaces de controle e fronteira, dentre outras, ControleAbstratoDeGes-
tãoDeItens e InterfaceControladorFrontalDeGestãoDeItens denem as abstrações estruturais

necessárias às colaborações de cadastro; conforme exemplicado a seguir.
Figura 4.19: Visão geral Camada de Controle
Figura 4.20: Detalhes Tela de Listagem de Itens

Figura 4.21: Detalhes Tela de Edição de Item
Por m, o conjunto de abstrações para as visões de desenho externo, solução de desenho
e implementação constituem um arcabouço base para o desenvolvimento de aplicações web,
como o Merci-Web, orientado às diretrizes denidas durante este trabalho.
O detalhamento de todas as abstrações e resultados de modelagem encontra-se na seção
de Anexos.
Capítulo 5
Conclusões
Apresentamos neste trabalho um conjunto de diretrizes para orientar o uso de técnicas de
modelagem em processos de desenvolvimento de software dirigido por modelos. As denições
de atividades e artefatos do Praxis Synergia forneceram os subsídios necessários a obtenção
das diretrizes alinhadas ao objetivo proposto oferecer um guia para produção de

modelos de software com conteúdo adequado.
Em cada perspectiva de modelagem abordamos os principais itens de modelo compreen-
didos e denições de organização de conteúdo. O arcabouço Model Driven Architecture e
o próprio processo Praxis Synergia forneceram os limiares para determinarmos até onde
prosseguir com as denições sobre o que modelar e como modelar independentemente de
solução tecnológica e/ou plataforma. As denições de informações insumo às diretrizes foram
orientadas por conceitos chave em modelagem, como padrões de desenho, colaborações, visões
de modelo e a notação UML 2.0, dentre outros.
Com base nestas informações, um gabarito de modelo de desenho de software para apli-
cações web foi concebido independentemente de aspectos de solução de implementação. O uso
das diretrizes e conceitos envolvidos nos forneceu um modelo onde abordamos perspectivas
centradas em usuários nais, casos de uso e arquitetura de software. A interação entre os
usuários e as interfaces de usuário, a realização dos casos de uso de análise em função destas
49
5. Conclusões 50
interações e em função dos mecanismos arquiteturais previstos e o próprio detalhamento ar-
quitetural foram contemplados.
Finalmente, para o Praxis Synergia, concluimos com a denição de diretrizes de confecção
de conteúdo para seus modelos e a elaboração de artefatos de modelo como o conceito de reuso
de desenho externo, padrões de projeto e mecanismos arquiteturais previstos para aplicações
web.
5.1 Trabalhos futuros
Alguns tópicos abordados neste trabalho podem dar origem a estudos relevantes. A aplicação
integral dos conceitos do arcabouço MDA no Praxis Synergia, por exemplo, requer estudos
quanto a questões em aberto como as transformações modelo para modelo e modelo para
código-fonte. O primeiro passo quanto ao uso de modelos independentes de plataforma foi
concebido através das diretrizes para as visões de desenho externo e solução de desenho
do MDSw Praxis Synergia. Contudo, denições sobre como e quando proceder com o uso
destas regras de transformações para modelos especícos a uma plataforma e em código-
fonte estão em aberto. Este tipo de automação provavelmente traria ganhos signicativos de
produtividade, além de tornar o processo de modelagem mais simples. O desenhista poderia
se concentrar em aspectos intrínsecos ao negócio, deixando a geração dos mecanismos de
implementação a cargo de uma ferramenta.

Capítulo 6
Anexos
Esta seção contém informações que complementam alguns aspectos apontados ao longo do
texto deste trabalho.
6.1 Informações sobre o MDSw web gabarito
Esta seção de anexo contém o conjunto de diagramas e denições de aplicação do roteiro de
diretrizes para o desenvolvimento dirigido por modelos aplicado ao MDSw web gabarito. As
informações estão dispostas segundo a orientação por visões e pacotes denidos.
6.1.0.1 Visão de desenho externo
praxis::cliente::Aspectos gerais de processo::Tipos::Campos
Denições de reuso de desenho externo para tipos de campos de interfaces de usuário.
51
6. Anexos 52
Figura 6.1: Visão geral Tipos de Campos

6. Anexos 53
praxis::cliente::Aspectos gerais de processo::Tipos::Comandos
Denições de reuso de desenho externo para tipos de comandos de interfaces de usuário.
Figura 6.2: Visão geral Tipos de Comandos

6. Anexos 54
praxis::cliente::Componentes das interfaces de usuário::Básicos
Denições de reuso de desenho externo para tipos básicos de interfaces de usuário.
Figura 6.3: Estrutura estática Caixa de Mensagem
Figura 6.4: Estrutura estática Elemento de Interface de Usuário

6. Anexos 55
Figura 6.5: Diagrama Estados Tela

6. Anexos 56
praxis::cliente::Componentes das interfaces de usuário::Cadastro
Denições de reuso de desenho externo para tipos de interfaces de usuário para cadastro.
Figura 6.6: Diagrama Estados Painel de Itens de Edição
Figura 6.7: Diagrama Estados Tela de Edição de Item

6. Anexos 57
Figura 6.8: Diagrama Estados Tela de Gestão de Itens
Figura 6.9: Diagrama Estados Tela de Seleção de Itens

6. Anexos 58
Figura 6.10: Estrutura estática Item de Linha
Figura 6.11: Estrutura estática Tela de Edição de Item

6. Anexos 59
Figura 6.12: Estrutura estática Tela de Itens
Figura 6.13: Estrutura de navegação

6. Anexos 60
praxis::cliente::Componentes das interfaces de usuário::Principal:
Denições de reuso de desenho externo para a Tela Principal do produto.
Figura 6.14: Estrutura estática Tela Principal

6. Anexos 61
praxis::cliente::Funções do produto
Denições de reuso de desenho externo para colaborações de desenho externo.
Figura 6.15: Visão geral Funções do produto

6. Anexos 62
Colaboração Listagem de Itens
Colaboração de classes que provêem o comportamento de listagem de itens cadastrados, ex-
ibidos em uma Tela de Itens.
Figura 6.16: Listagem de Itens - Fluxo Principal

6. Anexos 63
Figura 6.17: Listagem de Itens - Subuxo Listagem de Itens
Figura 6.18: Listagem de Itens - Subuxo Restrição de Listagem de Itens

6. Anexos 64
Colaboração Listagem de Itens com Pesquisa
Colaboração de classes que provêem o comportamento de listagem com pesquisa por itens
cadastrados, exibidos em uma Tela de Itens.
Figura 6.19: Listagem de Itens com Pesquisa - Subuxo Pesquisa a Itens Cadastrados
6. Anexos 65
Figura 6.20: Listagem de Itens com Pesquisa - Fluxo alternativo Listagem com Pesquisa
6. Anexos 66
Colaboração Gestão de Cadastro
Colaboração de classes que provêem o cadastro e edição de itens.
Figura 6.21: Gestão de Cadastro - Fluxo alternativo Alteração de Item

6. Anexos 67
Figura 6.22: Gestão de Cadastro - Fluxo alternativo Edição de Item

6. Anexos
68
Figura 6.23: Gestão de Cadastro - Fluxo alternativo Exclusão de Item
6. Anexos 69
Figura 6.24: Gestão de Cadastro - Fluxo alternativo Finalização de Edição de Item

6. Anexos 70
Figura 6.25: Gestão de Cadastro - Fluxo alternativo Inclusão de Novo Item

6. Anexos 71
Figura 6.26: Gestão de Cadastro - Fluxo alternativo Visualização de Item

6. Anexos 72
Colaboração Gestão do Cadastro com Detalhes
Colaboração de classes que provêem o cadastro e edição de itens com detalhes (relação item
mestre/itens de detalhe).
Figura 6.27: Gestão de Cadastro com Detalhes - Fluxo alternativo Alteração de Item de
Detalhe
6. Anexos
Figura 6.28: Gestão de Cadastro com Detalhes - Fluxo alternativo Exclusão de Item de Detalhe
73
6. Anexos 74
Figura 6.29: Gestão de Cadastro com Detalhes - Fluxo alternativo Inclusão de Novo Item de
Detalhe
6. Anexos
Figura 6.30: Gestão de Cadastro com Detalhes - Fluxo alternativo Seleção de Novo Item de Detalhe
75
6. Anexos 76
Figura 6.31: Gestão de Cadastro com Detalhes - Fluxo alternativo Visualização de Item de
Detalhe
6. Anexos 77
Figura 6.32: Gestão de Cadastro com Detalhes - Subuxo Edição de Item de Detalhe
6. Anexos 78
com::uhackers::merci::Componentes das interfaces de

usuário::Administração::Usuários
Denições de desenho externo para as interfaces de usuário do caso de uso Gestão de Usuários
do Merci-Web.
Figura 6.33: Estrutura estática Tela de Usuários

6. Anexos 79
com::uhackers::merci::Componentes das interfaces de

usuário::Compras::Mercadorias
Denições de desenho externo para as interfaces de usuário do caso de uso Gestão de Mer-
cadorias do Merci-Web.
Figura 6.34: Estrutura estática Tela de Edição de Mercadoria

6. Anexos 80
Figura 6.35: Estrutura estática Tela de Mercadorias
Figura 6.36: Estrutura estática Tela de Seleção de Mercadorias

6. Anexos 81
com::uhackers::merci::Funções do produto::Administração
Denições de desenho externo para os casos de uso de administração do Merci-Web.
Figura 6.37: Visão geral Colaboração Gestão de Usuários

6. Anexos
Figura 6.38: Diagrama de Estrutura Gestão de Usuários
82
6. Anexos 83
com::uhackers::merci::Funções do produto::Compras
Denições de desenho externo para os casos de uso de compras do Merci-Web.
Figura 6.39: Visão geral Colaboração Gestão de Mercadorias

6. Anexos
Figura 6.40: Diagrama de Estrutura Gestão de Mercadorias
84
6. Anexos 85
6.1.0.2 Visão de solução de desenho
praxis::cliente::controle
Denições de reuso de desenho interno para a camada de controle.
Figura 6.41: Visão geral Camada de controle

6. Anexos 86
praxis::cliente::controle::cadastro
Denições de reuso de desenho interno para mecanismos de cadastro da camada de controle.
Figura 6.42: Visão geral Camada de controle::cadastro

6. Anexos 87
praxis::cliente::controle::util
Denições de reuso de desenho interno para mecanismos utilitários da camada de controle.
Figura 6.43: Visão geral Camada de controle::util

6. Anexos 88
praxis::cliente::entidade
Denições de reuso de desenho interno para a camada de entidade.
Figura 6.44: Visão geral Camada de entidade
Figura 6.45: Detalhes Adaptador Atualização de Objeto Persistente

6. Anexos 89
praxis::cliente::fronteira
Denições de reuso de desenho interno para a camada de fronteira.
Figura 6.46: Visão geral Camada de fronteira
Figura 6.47: Detalhes Tela

6. Anexos 90
praxis::cliente::fronteira::cadastro
Denições de reuso de desenho interno para mecanismos de cadastro da camada de fronteira.
Figura 6.48: Detalhes Tela de Listagem de Itens
Figura 6.49: Detalhes Tela de Edição de Item

6. Anexos 91
praxis::cliente::fronteira::util
Denições de reuso de desenho interno para mecanismos utilitários da camada de fronteira.
Figura 6.50: Detalhes Gerente de Aplicação
Figura 6.51: Detalhes Tratador de Requisição HTTP

6. Anexos 92
praxis::cliente::persistência
Denições de reuso de desenho interno para a camada de persistência.
Figura 6.52: Detalhes Adaptador Sessão de Banco de Dados
Figura 6.53: Detalhes Adaptador Transação de Banco de Dados

6. Anexos 93
praxis::cliente::sistema::mensagem
Denições de desenho interno para mecanismos utilitários para mensagens de sistema.
Figura 6.54: Visão geral Camada de sistema::mensagem

6. Anexos 94
praxis::cliente::realizações::apresentação
Denições de desenho interno para mecanismos da camada de apresentação (view ).
Figura 6.55: Visão geral Colaboração Tratamento de Requisição de Usuário

6. Anexos 95
Colaboração Tratamento de Requisição de Usuário
Colaboração descritiva para o tratamento de requisições de usuário.
Figura 6.56: Tratamento de Requisição de Usuário - Fluxo Principal

6. Anexos 96
praxis::cliente::realizações::cadastro
Denições de desenho interno para mecanismos de cadastro.
Figura 6.57: Visão geral Colaborações de cadastro

Colaboração Gestão de Cadastro de Item
6. Anexos
Colaboração descritiva para o cadastro de item.
Figura 6.58: Gestão de Cadastro de Item - Fluxo alternativo Alteração de Item
97
6. Anexos
Figura 6.59: Gestão de Cadastro de Item - Fluxo alternativo Exclusão de Item
98
6. Anexos
99
Figura 6.60: Gestão de Cadastro de Item - Fluxo alternativo Inclusão de Novo Item
6. Anexos
100
Figura 6.61: Gestão de Cadastro de Item - Fluxo alternativo Salvamento de Item
6. Anexos
Figura 6.62: Gestão de Cadastro de Item - Fluxo alternativo Visualização de Item
101
Colaboração Gestão de Cadastro de Item com Detalhes
6. Anexos
Colaboração descritiva do cadastro de item com detalhes.
Figura 6.63: Gestão de Cadastro de Item com Detalhes - Fluxo alternativo Alteração de Item de Detalhe
102
6. Anexos
Figura 6.64: Gestão de Cadastro de Item com Detalhes - Fluxo alternativo Exclusão de Item de Detalhe
103
6. Anexos 104
Figura 6.65: Gestão de Cadastro de Item com Detalhes - Fluxo alternativo Inclusão de Novo
Item de Detalhe
6. Anexos 105
Figura 6.66: Gestão de Cadastro de Item com Detalhes - Fluxo alternativo Seleção de Novo
Item de Detalhe
6. Anexos
Figura 6.67: Gestão de Cadastro de Item com Detalhes - Fluxo alternativo Visualização de Item de Detalhe
106
6. Anexos 107
praxis::cliente::realizações::listagem
Denições de desenho interno para mecanismos de listagem de itens cadastrados.
Figura 6.68: Visão geral Colaborações de listagem

6. Anexos 108
Colaboração Gestão de Itens
Colaboração descritiva da listagem de itens cadastrados. Figura 6.69.
Colaboração Gestão de Itens com Pesquisa
Colaboração descritiva da listagem de itens com pesquisa. Figura 6.70.

6. Anexos
109
Figura 6.69: Gestão de Itens - Fluxo Principal
6. Anexos
110
Figura 6.70: Gestão de Itens com Pesquisa - Fluxo alternativo Listagem com Pesquisa
6. Anexos 111
praxis::cliente::realizações::persistência
Denições de desenho interno para mecanismos de persistência de dados.
Figura 6.71: Visão geral Colaborações de persistência

6. Anexos 112
Colaboração Exclusão de Item
Colaboração descritiva da exclusão de um item cadastrado. Figuras: 6.72 e 6.73.
Colaboração Salvamento de Item
Colaboração descritiva do salvamento de um item em banco de dados. Figuras: 6.74 e 6.75.

6. Anexos
113
Figura 6.72: Exclusão de Item - Detalhe Execução de Exclusão de Item
6. Anexos
114
Figura 6.73: Exclusão de Item - Detalhe Execução de Exclusão de Item Ignorando Alertas
6. Anexos
115
Figura 6.74: Salvamento de Item - Detalhe Execução de Salvamento de Item
6. Anexos
116
Figura 6.75: Salvamento de Item - Detalhe Execução de Salvamento de Item Ignorando Alertas
6. Anexos 117
Colaboração Recuperação de Itens
Colaboração descritiva da recuperação de itens cadastrados.
Figura 6.76: Recuperação de Itens - Detalhe Recuperação de Item

6. Anexos 118
Figura 6.77: Recuperação de Itens - Detalhe Recuperação de Itens

6. Anexos 119
Figura 6.78: Recuperação de Itens - Detalhe Recuperação de Itens Filtrados

6. Anexos 120
Figura 6.79: Recuperação de Itens - Detalhe Totalização de Itens

6. Anexos 121
Figura 6.80: Recuperação de Itens - Detalhe Totalização de Itens Filtrados

Referências Bibliográcas
[Alexander et al., 2007] Alexander, C.; Ishikawa, S.; Silverstein, M.; Jacobson, M.; Fiksdahl,
I. e Angel, S. (2007). A Pattern Language. Oxford University.
[Bettin, 2004] Bettin, J. (2004). Model-driven software development. Disponível em:
http://www.softmetaware.com/mdsd-and-isad.pdf. v. 0.8.
[Booch et al., 2005] Booch, G.; Rumbaugh, J. e Jacobson, I. (2005). UML Guia do Usuário.
Campus, 2 edição.
[Bray et al., 2000] Bray, T.; Paoli, J.; Sperberg, C. M. M. e Maler, E. (2000). Extensible
markup language. Disponível em: http://www.w3.org/TR/2000/REC-xml-20001006/. v.
1.0.
[Clements et al., 2006] Clements, P.; Bachmann, F.; Bass, L.; Garlan, D.; Ivers, J.; Little,
R.; Nord, R. e Staord, J. (2006). Documenting Software Architectures. Addison Wesley, 8
edição.
[Filho, 2002] Filho, W. P. P. (2002). Engenharia de Software, Métodos e Padrões. LCT.
[Fowler, 2005] Fowler, M. (2005). Patterns of Enterprise Application Architecture. Addison
Wesley.
[Gamma et al., 2003] Gamma, E.; Helm, R.; Johson, R. e Vlissides, J. (2003). Design Pat-
terns: Elements of Reusable Object-Oriented Software. Addison Wesley.
[IBM, 2003] IBM (2003). Rational Unied Process. IBM, Disponível em
http://www.developer.ibm.com/us/en/university/scholars/members/spm/software/
Rational1.html.
122
Referências Bibliográficas 123
[IEEE, 1994] IEEE (1994). IEEE Standards Collection Software Engineering. IEEE,
Disponível em: http://shop.ieee.org/store.
[IEEE, 2000] IEEE (2000). Standard for Modeling and Simulation. IEEE, Disponível em:
http://shop.ieee.org/store.
[Jacobson, 1992] Jacobson, I. (1992). Object-Oriented Software Engineering: A Use Case
Driven Approach. Addison Wesley.
[Jacobson et al., 1999] Jacobson, I.; Rumbaugh, J. e Booch, G. (1999). Unied Software
Development Process. Addison Wesley.
[Klepe et al., 2003] Klepe, S.; Warmer, S. e Bast, W. (2003). MDA Explained, The Model
Drive Architecture: Practice and Promise. Addison Wesley.
[Mark et al., 1995] Mark, C. P.; Charles, V. W.; Bill, C. e Chrissis, M. B. (1995). The
Capability Maturity Model: Guidelines for Improving the Software Process. Addison Wesley.
[Mellor et al., 2004] Mellor, S. J.; Scott, K.; Uhl, A. e Weise, D. (2004). MDA Distilled:
Priciples of Model-Driven Architecture. Addison Wesley.
[OMG, 2002] OMG (2002). XML Metadata Interchange, forma/03-05-02. OMG.
[OMG, 2003a] OMG (2003a). Meta Object Facility Core Final Adopted Spectication, ptc/03-
10-04. OMG.
[OMG, 2003b] OMG (2003b). UML 2.0 Infrastructure Final Adopted Specication, ptc/03-
09-15. OMG.
[OMG, 2004] OMG (2004). MOF Model to Text Transformation Language, ad/04-04-07.
OMG.
[OMG, 2006a] OMG (2006a). Object management group. Disponível em:
http://www.omg.org/.
[OMG, 2006b] OMG (2006b). Omg model driven architecture. Disponível em:
http://www.omg.org/mda.
Referências Bibliográficas 124
[Pádua et al., 2006] Pádua, C.; Pimentel, B.; Filho, W. P. P. e Machado, F. T. (2006). Tran-
sitioning model-driven development from academia to real life. In Proceedings of Educators'
Symposium of the ACM / IEEE 9th International Conference on Model Driven Engineering
Languages and Systems, pp. 6177, Gênova, Itália.

Desenho de Processos

Încărcat de

Informații document

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Desenho de Processos

Încărcat de

Drepturi de autor:

Formate disponibile

ALYSSON FÉLIX RODRIGUES

UM GUIA PARA A CRIAÇÃO DE MODELOS DE

DESENHO DE SOFTWARE NO PRAXIS SYNERGIA

UM GUIA PARA A CRIAÇÃO DE MODELOS DE

DESENHO DE SOFTWARE NO PRAXIS SYNERGIA

Dissertação apresentada ao Curso de Pós-

ALYSSON FÉLIX RODRIGUES

bem-sucedido; um desses componentes é a utilização da modelagem. A escolha dos modelos

de um software. A meta de trabalho é que as denições sejam fundamentadas em técnicas

contexto de aplicações web.

Praxis Synergia software development process.

Agradeço aos meus pais, sempre presentes.

Agradeço aos amigos do Synergia pelo constante auxílio e capacitação oferecidos.

pela conança em mim depositada e pelas inúmeras oportunidades de aprendizagem que o

Synergia tem me oferecido.

Finalmente, agradeço a todos os amigos essenciais ao meu bem estar e serenidade.

1.2 Objetivos do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

1.3 Limites do trabalho . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

1.4 Organização deste documento . . . . . . . . . . . . . . . . . . . . . . . . . . . 6

2 Desenvolvimento dirigido por modelos 8

2.1 Modelos e processos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.1.1 Introdução ao processo Praxis Synergia . . . . . . . . . . . . . . . . . 9

2.1.2 O arcabouço MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9

2.2 Padrões e recomendações para o desenvolvimento dirigido por modelos . . . . 12

2.2.1 A notação UML . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.2 Visões de modelo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.2.3 Padrões de desenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

2.2.5 Arquitetura de software . . . . . . . . . . . . . . . . . . . . . . . . . . 18

3 Denição das diretrizes 19

3.1 Diretrizes e o processo Praxis Synergia . . . . . . . . . . . . . . . . . . . . . . 19

4 Aplicação das diretrizes 29

4.1 Visão de desenho externo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

4.2 Visão de solução de desenho . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.2.1 A denição e comunicação entre camadas . . . . . . . . . . . . . . . . 36

4.2.2 O modelo de domínio . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.2.3 A persistência de dados . . . . . . . . . . . . . . . . . . . . . . . . . . 42

4.2.4 O cadastro de itens . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46

5.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

6.1 Informações sobre o MDSw web gabarito . . . . . . . . . . . . . . . . . . . . . 51

Referências Bibliográcas 122

2.1 Artefatos denidos pelo MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.1 O ciclo de desenvolvimento no Praxis Synergia . . . . . . . . . . . . . . . . . . . 20

3.2 Exemplos de colaborações de desenho externo . . . . . . . . . . . . . . . . . . . . 25

3.3 Exemplos de mecanismos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26

3.4 Comunicação entre camadas Praxis . . . . . . . . . . . . . . . . . . . . . . . . . . 27

4.1 Estrutura estática Tela de Itens . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

4.2 Estrutura de navegação Tela de Itens . . . . . . . . . . . . . . . . . . . . . . . . . 32

4.3 Estrutura estática Tela de Mercadorias . . . . . . . . . . . . . . . . . . . . . . . . 32

4.4 Estrutura estática Tela de Edição de Mercadoria . . . . . . . . . . . . . . . . . . 33

4.5 Visão geral Colaborações de desenho externo . . . . . . . . . . . . . . . . . . . . 33

4.6 Diagrama de estrutura Colaboração Gestão de Mercadorias . . . . . . . . . . . . 35

4.7 Padrão MVC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36

4.8 Padrão MVC e camadas Praxis Synergia . . . . . . . . . . . . . . . . . . . . . . . 38

4.10 Fluxo de desenho Colaboração Tratamento de Requisição de Usuário . . . . . . . 39

4.11 Detalhes Arquitetura . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

4.12 Visão geral Camada de entidade . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

4.13 Detalhes Adaptador de Sessão de Banco de Dados . . . . . . . . . . . . . . . . . 43

4.14 Detalhes Adaptador de Transação de Banco de Dados . . . . . . . . . . . . . . . 43

4.15 Detalhes Adaptador de Atualização de Objeto Persistente . . . . . . . . . . . . . 43

4.16 Detalhes Execução de Exclusão de Item . . . . . . . . . . . . . . . . . . . . . . . 44

4.17 Detalhes Execução de Salvamento de Item . . . . . . . . . . . . . . . . . . . . . . 45

4.18 Visão geral Colaborações de Cadastro . . . . . . . . . . . . . . . . . . . . . . . . 46

4.19 Visão geral Camada de Controle . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

4.20 Detalhes Tela de Listagem de Itens . . . . . . . . . . . . . . . . . . . . . . . . . . 47

de um software. A meta de trabalho é que as denições sejam fundamentadas em técnicas

pela conança em mim depositada e pelas inúmeras oportunidades de aprendizagem que o

3 Denição das diretrizes 19

4.2.1 A denição e comunicação entre camadas . . . . . . . . . . . . . . . . 36

Referências Bibliográcas 122

2.1 Artefatos denidos pelo MDA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

6.17 Listagem de Itens - Subuxo Listagem de Itens . . . . . . . . . . . . . . . . . . . 63

6.18 Listagem de Itens - Subuxo Restrição de Listagem de Itens . . . . . . . . . . . . 63

6.19 Listagem de Itens com Pesquisa - Subuxo Pesquisa a Itens Cadastrados . . . . . 64

6.32 Gestão de Cadastro com Detalhes - Subuxo Edição de Item de Detalhe . . . . . 77

sistemas de software de maneira previsível e em determinado período, com utilização eciente

e ecaz de recursos, será uma empresa com um negócio viável.