O documento discute o desenvolvimento de software focado no domínio de negócios usando os padrões Naked Objects e Domain-Driven Design. Ele propõe a linguagem NOVL para mapear objetos de domínio para interfaces do usuário personalizadas e o framework Entities para estender o padrão Naked Objects com múltiplas visões por objeto e aplicações transientes. O documento também descreve como a abordagem proposta pode levar a interfaces consistentes, código reduzido e um ciclo de desenvolvimento mais rápido.

1. Marcius Gomes Brandão
Orientadora: Prof. Dra. Mariela Inés Cortés
Co-orientação : Prof. Msc. Ênyo J. T. Gonçalves

3. Introdução
Mudanças são
inevitáveis Softwares são
complexos!
Mudanças são Software não é
consideradas construído, e sim
fáceis desenhado
Trabalho Desenvolvimento
repetitivo é de Software é
automatizado pesquisa
Melhores práticas Experiência em
Requisitos são
não estão tecnologia é
incompletos
maduras incompleta
Software é Software é Tecnologia muda Tecnologia é
Complexo Abstrato rapidamente vasta
Stepanek,2005

4. Introdução
50% do código e tempo
de desenvolvimento
Maior complexidade
esta no domínio
70% do
código é de
infraestrutura

5. Motivação
Para o Standish Group a adoção de
uma infraestrutura de software
padrão (por exemplo, frameworks de
desenvolvimento) possibilita que a
equipe de desenvolvimento possa se
concentrar no domínio de negócio
em vez de tecnologia

6. Objetivos
 Orientação a Objetos
 Completude Comportamental
 Boas práticas de programação
 Modelo flexível e fácil de manter
 Rápido ciclo de desenvolvimento
 Redução de prazos
 Redução de custos
 Redução de “Lines of Code”
 Menos erros
 Maior qualidade
 Menor custo de manutenção

7. Metodologia: Embasamento teórico
Domain-Driven Design Applying Domain-
Eric Evans, Driven Design and
Addison–Wesley,2004. Patterns
Jimmy Nilsson,
Addison-Wesley,2006
Naked Objects
Richard Pawson and About Face
Robert Matthews, Alan Cooper,
Wiley 2002 Wiley Publishing 2007

8. Metodologia: Projetos Reais

9. Metodologia: Estudos de Caso

10. Metodologia : Artigos científicos
“Naked Objects View
Language” “Entities – A framework Based on Naked
Objects for the Development of Transient
Web applications”
“Monitoramento e Controle de “Domain-Driven Design
Projetos com e-Kanban e Burndown: using Entities Framework”
Um Relato de Experiência”

12. Referencial teórico
Domain-
Driven
Design
Naked Objects

13. Naked Objects Architectural Pattern
Arquitetura padrão em 4-camadas Arquitetura com Naked Objects
O problema : quando os requisitos Alterações no domínio se propagam
mudam, geralmente temos que automaticamente para a interface do
propagar essas alterações usuário e as camadas de persistência
manualmente para as outras três (PAWSON,2008).
camadas (LÄUFER,2008).

14. Princípios NOP
Completude comportamental
Único ponto de definição :
Domain Model
UIs 100% geradas
automaticamente
Implementação genérica de
serviços

15. Domain-Driven Design (DDD)
“código que resolve problema de
domínio não se mistura com
código que resolve problema
de software” NILSSON(2006).

16. Domain-Driven Design (DDD)

18. Comparativo dos frameworks

20. NOVL
Layout Grid (Cooper2007) é um esquema em
 Linguagem de descrição de layout grade que fornece uma estrutura uniforme e
consistente para a criação de uma interface com
 baseada no layoutgrid vários níveis de complexidade visual.
 para personalização de UI
 utilizando texto simples
 no lugar de estruturas mais sofisticadas
como SWING, CSS, XML, HTML, etc
 independente de tecnologia
 de rápido aprendizado e
 dispensa o uso de ferramentas
visuais de edição de interfaces

21. NOVL : Definição formal

22. NOVL : Diagramas de sintaxe

23. NOVL : Recursos
Convenção Usado para
property Nome case-sensitive da propriedade do naked object ou do controlador.
Action Nome case-sensitive do método do naked object ou do controlador.
, Separador de colunas.
; Separador de linhas.
:colspan Colspan define quantas colunas o membro deve ocupar na grade
(readonly) O membro sempre será exibido em modo de leitura (saída de dados)
*
incondicionalmente.
(writeonly) O membro sempre será exibido em modo de edição (entrada de dados)
#
incondicionalmente.
É um texto simples que será atribuído ao próximo elemento. No caso de um membro,
'label'
substitui o rótulo padrão.
[] Define uma sub-grade.
+ Indica que o componente deve ser apresentado inicialmente no modo expandido.
- Indica que o componente deve ser apresentado inicialmente no modo recolhido.
Delimita uma sub-grade que será apresentada a partir dos membros do domínio de
<...>
uma coleção.

24. NOVL : Mestre-Detalhe

25. NOVL: Estudo de caso

26. Usando NOVL

28. Arquitetura

29. Plataforma de desenvolvimento
 JEE5
 Polimorfismo
 JavaServer Faces
 Java Persistence API
 Bean Validation
 Expression
Language
 Reflexão
 Annotations

30. Arquitetura

31. API Entities para UI

32. Infraestrutura para UI

33. BoundedControls

34. Filtragem

35. API Entities para persistência
public interface IRepository {
void add(Object domain);
int set(String domain, Object... parameters);
void remove(Object domain);
<T> T get(T domain);
<T> T get(Class<T> domain, Object id);
<T> List<T> get(String query, Object... parameters);
<T> List<T> get(String query, int startIndex, int maxObjects, Object... params);
long size(String query, Object... parameters);
void persistAll();
void clear();
}
public class Repository {
Object newInstance(Class entity)
void save(Object... entity)
void load(Object... entity)
void delete(Object... entity)
List query(String query, Object... parameters)
List query(String query, int start, int pageSize, Object... parameters)
int executeUpdate(String query, Object... parameters)
}

36. API Entities para segurança

37. Implementação da arquitetura

39. Criando o Domain Model

40. Prototipação

41. Implementação do Domain Model
public class Order {
private String number;
private Customer customer;
private Date orderDate;
private int numberOfItems;
private List<OrderLine> lines;
private double totalAmount;
private Status status;
public Order() { . . .}
public void addLine() { . . . }
public void accept() { . . . }
public void pay() { . . . }
public void reject() { . . . }
private boolean isOkAccordingToSize() { . . . }
private boolean isOkAccordingToCreditLimit() { . . . }
/* demais gets e sets omitidos */
public enum Status {NewOrder,Accepted,Paid,Canceled;}
}

42. Implementação do Domain Model
@Entity
public class Order implements Serializable {
@Id @GeneratedValue
private Integer id;
@Column(length = 8, unique = true, nullable = false)
@NotEmpty(message = "Enter the number of the Order")
private String number;
@ManyToOne(optional = false)
@NotNull(message = "Enter the customer of the Order")
private Customer customer;
@Past @Temporal(TemporalType.DATE)
private Date orderDate;
@Column(precision = 4)
@Min(value = 1, message = "Enter at least one line")
private Integer numberOfItems = 0;
@Valid
@OneToMany(mappedBy = "order",
cascade = CascadeType.ALL,
orphanRemoval = true)
private List<OrderLine> lines;
@Column(precision = 8, scale = 2)
private Double totalAmount;
@NotNull
@Enumerated(EnumType.STRING)
private Status status;
}

43. Instanciando o Domain Model

44. Instanciando o Domain Model

45. Mapeamento Objeto-User Interface

46. Mapeamento Objeto-User Interface
@Views({
@View(
title="List of Orders",
name="ListOfOrders",
filters="customer, Ctrl.DAO.filter()",
members="number,orderDate,numberOfItems,totalAmount,status"
footer="Ctrl.DAO.scroll()",
rows=10,
namedQuery="From domain.Order order by number",
roles="LOGGED"),
@View(
title="Add Order",
name="AddOrder",
members="[Header[#number,#orderDate;#customer:2]; "
+" Lines[addLine(); "
+" lines<#product,#numberOfUnits,#price>; "
+" *numberOfItems]; "
+" accept()] ",
namedQuery="Select new domain.Order()",
roles="Admin,SalesMan")
})
public class Order implements Serializable {

48. Contribuição geral
 Desenvolvimento focado no domínio
 UI robustas e consistentes
 Redução de “Lines of Code” redundantes
 Menos erros
 Maior qualidade
 Menor custo de manutenção
 Rápido ciclo de desenvolvimento
 Redução de prazos
 Redução de custos

49. Contribuições da NOVL
 Eliminação de uns dos principais limitadores do
padrão Naked Objects
 UI personalizadas
 Não invalida o padrão
 Independência de tecnologia
 Uso SEM editores visuais de UI
 Ciclo de aprendizado reduzido
 Manutenção facilitada
 Despreocupação da implementação da UI

50. Contribuições do Entities
 Extensão do padrão Naked Objects
 UI customizáveis
 Múltiplas visões por objeto de domínio
 Aplicações soberanas e transientes
 Suporte a Domain-Driven Design
 Essência da OO : Completude comportamental
 Foco no domínio
 Domínio independente da tecnologia

51. Trabalhos futuros
 Upgrade da NOVL
 Relatórios
 Módulo de Testes
 Outras plataformas

52. Perguntas?
“A simplicidade é o último
grau de sofisticação”
Leonardo da Vinci.