Framework Entities - Apresentação da Defesa da Dissertacao

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

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

Introdução
50% do código e tempo
de desenvolvimento

Maior complexidade
esta no domínio

70% do
código é de
infraestrutura

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

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

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

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”

Referencial teórico

Domain-
Driven
Design

Naked Objects

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).

Princípios NOP

Completude comportamental

Único ponto de definição :
Domain Model

UIs 100% geradas
automaticamente

Implementação genérica de
serviços

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).

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

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.

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

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)
}

Implementação da arquitetura

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;}
}

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;
}

Mapeamento Objeto-User Interface

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 {

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

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

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

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

Perguntas?

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

Framework Entities - Apresentação da Defesa da Dissertacao

Mais conteúdo relacionado

Mais procurados

Semelhante a Framework Entities - Apresentação da Defesa da Dissertacao

Mais de Marcius Brandão

Último

Framework Entities - Apresentação da Defesa da Dissertacao

Notas do Editor