- Governança-TIC
- 01. Apresentação DTIC
- 02. Estratégia de TIC
- 03. Indicadores e Metas de TIC
-
04. Processos de TIC
-
1.01. Contratação de STIC
-
1.02. Processo do PETIC
-
1.03. Processo do PDTIC
-
1.04. Capacitação de TIC
-
1.05. Processo do PAT
-
1.06. Orçamentos de TIC
-
2.01. Gestão de Demandas TIC
-
2.02. Gestão de Projetos TIC
-
2.03. Gestão de Contratos TIC
-
3.01. Gestão de Riscos TIC
-
3.02. Continuidade de Serviços TIC
-
3.03. Processo de Eventos TIC (Monitoria)
-
3.04. Processo de Backup / Restore
-
4.01. Desenvolvimento de Software
-
Matriz de Artefatos MDS
-
Diretrizes Desenvolvimento de Software
- Arquitetura de Desenvolvimento Java
-
Modelo Conceitual de Classes
-
Modelo de Atividades
- Modelo de Banco de Dados
-
Modelo de Caso de Uso
- Modelo de Classes
-
Modelo de Componentes
-
Modelo de Implantação
-
Modelo de Instâncias
-
Modelo de Interação
-
Modelo de Máquina de Estados
- Padrão de Interface Web de Sistema com o Usuário
- Orientações de trabalho Desenvolvimento de Software
-
Diretrizes Desenvolvimento de Software
-
Matriz de Artefatos MDS
-
4.02. Sustentação de Software
-
5.01. Central de Serviços TIC
-
5.02. Gerenciamento de Problemas TIC
-
5.03. Gerenciamento de Mudanças TIC
-
5.04. Gerenciamento de Liberação e Implantação TIC
-
5.05. Gerenciamento de Configuração e Ativo de Serviços TIC
-
5.06. Gerenciamento do Catálogo de Serviços TIC
-
5.07. Gerenciamento de Nível de Serviço TIC
-
6.01. Pesquisa Satisfação Usuários de TIC
-
6.02. Organizar Reuniões de TIC
-
Ferramentas para Mapeamento de Processos de TIC
-
sobre Processo de TI
-
1.01. Contratação de STIC
- 05. Segurança de TIC
- 06. Portfólio de TIC
-
Base de Conhecimento
- Capacitação de TIC
-
Normativos CNJ
- Publicações de TIC
-
Relatório Atividades DTIC
- Videoconferência
Os dados de negócio serão representados por objetos Java simples que atravessarão as camadas da aplicação. As classes que representam as entidade de negócio serão referenciadas pelas camadas persistence (persistência), enterprise (corporativa se existir), service (serviços) e client (cliente), formando assim uma camada transversal na arquitetura lógica que será chamada entity (entidades).
Com esta escolha, a camada de persistência tem como papel transformar o conteúdo da camada de dados em entidades, representação do modelo do objeto de negócio. Este modelo comporta alguns aspectos técnicos ligados à um framework de persistência quando for possível realizar o mapeamento objeto-relacional dos JavaBeans simples. Em contrapartida, esta estrutura não permite generalizar uma especialização de dados de negócio por camada. Esta limitação foi aceita em relação à produtividade e desempenho trazidos por esta solução.
A funcionalidade das aplicações será implementada nas classes chamadas serviços, distintas das entidades de negócio. Não deverá existir nos objetos de negócio atributos e operações complexas. Os serviços constituem as camadas de persistência, enterprise e de serviço.
Visando uma maior flexibilidade e reutilização dos serviços, de acordo com a arquitetura orientada à serviço (SOA), estes deverão ser preparados para sofrer DI (Dependency Injection). Estas classes deverão possuir um ou mais métodos setter para receber a interface de cada dependência que será implementada ou deverão existir construtores específicos para receber as interfaces das dependências entre os serviços utilizados.
No caso da camada de persistência, os serviços serão chamados DAO referindo-se ao padrão de desenvolvimento Data Access Object RF03. O seu papel é oferecer serviços de persistência às entidades apoiando-se nas soluções retidas (frameworks de persistência).
A camada cliente realiza geralmente a interface entre o usuário e o sistema. Ela não deverá conter lógica funcional, com exceção de controles eventuais na camada superficial que devem ser realizados, não deve substituir os controles da camada de negócio (service e enterprise) mas poderá constituir redundância com objetivo meramente ergonômico.
Esta prática visa isolar a funcionalidade dos aspectos de apresentação e navegação que são geralmente complexos e particularmente técnicos. Assim a evolução das funcionalidades será mais fácil de ser realizada. Por outo lado, esta estrutura facilita as mudanças IHM do ponto de vista técnico sem risco de perder ou alterar uma regra de negócio. Será possível possuir simultaneamente várias IHM para uma mesma aplicação (por exemplo, um cliente simples e outro com vários detalhes de tela) sendo que o essencial é centralizado.
A camada de persistência e conectores realiza a interface com as bases de dados ou outros sistemas externos. Não deverá conter lógica funcional.
As regras precedentes se resumem da maneira seguinte: a funcionalidade das aplicações serão centralizada nas camadas de serviço e enterprise (se existir) e os dados nas entidades da aplicação. Estas camadas constituem o core (núcleo) das aplicações. As outras camadas se contentam em realizar a interface com os usuários ou outros sistemas.
Com esta escolha, a camada de persistência tem como papel transformar o conteúdo da camada de dados em entidades, representação do modelo do objeto de negócio. Este modelo comporta alguns aspectos técnicos ligados à um framework de persistência quando for possível realizar o mapeamento objeto-relacional dos JavaBeans simples. Em contrapartida, esta estrutura não permite generalizar uma especialização de dados de negócio por camada. Esta limitação foi aceita em relação à produtividade e desempenho trazidos por esta solução.
A funcionalidade das aplicações será implementada nas classes chamadas serviços, distintas das entidades de negócio. Não deverá existir nos objetos de negócio atributos e operações complexas. Os serviços constituem as camadas de persistência, enterprise e de serviço.
Visando uma maior flexibilidade e reutilização dos serviços, de acordo com a arquitetura orientada à serviço (SOA), estes deverão ser preparados para sofrer DI (Dependency Injection). Estas classes deverão possuir um ou mais métodos setter para receber a interface de cada dependência que será implementada ou deverão existir construtores específicos para receber as interfaces das dependências entre os serviços utilizados.
No caso da camada de persistência, os serviços serão chamados DAO referindo-se ao padrão de desenvolvimento Data Access Object RF03. O seu papel é oferecer serviços de persistência às entidades apoiando-se nas soluções retidas (frameworks de persistência).
A camada cliente realiza geralmente a interface entre o usuário e o sistema. Ela não deverá conter lógica funcional, com exceção de controles eventuais na camada superficial que devem ser realizados, não deve substituir os controles da camada de negócio (service e enterprise) mas poderá constituir redundância com objetivo meramente ergonômico.
Esta prática visa isolar a funcionalidade dos aspectos de apresentação e navegação que são geralmente complexos e particularmente técnicos. Assim a evolução das funcionalidades será mais fácil de ser realizada. Por outo lado, esta estrutura facilita as mudanças IHM do ponto de vista técnico sem risco de perder ou alterar uma regra de negócio. Será possível possuir simultaneamente várias IHM para uma mesma aplicação (por exemplo, um cliente simples e outro com vários detalhes de tela) sendo que o essencial é centralizado.
A camada de persistência e conectores realiza a interface com as bases de dados ou outros sistemas externos. Não deverá conter lógica funcional.
As regras precedentes se resumem da maneira seguinte: a funcionalidade das aplicações serão centralizada nas camadas de serviço e enterprise (se existir) e os dados nas entidades da aplicação. Estas camadas constituem o core (núcleo) das aplicações. As outras camadas se contentam em realizar a interface com os usuários ou outros sistemas.