1.
OBJETIVO
O obj eti vo dest e d ocumento é d ef inir as normas e os padrões q ue de verã o ser adota dos pe los dese n vo l ve dores d a eq uip e interna e ext erna (f ornecedore s) q ue venh am a desen vo l ver so lu ções de software para aten der a s de mandas da Pref eitur a da C ida de d o R io de Ja ne iro - PC RJ.
2.
CONTEXTO
2.1. Com a cresce nte d e manda por S istema s de Inf ormação no â mbito da Pref eitur a da C i dade do Ri o de Ja neir o, f oi el abor ado este document o q ue d is põe so bre a arq uit etura, práti cas, pa drões, f ramework s e APIs (Appl ic atio n Pro gramming Interfac e) com o obj eti vo de ori entar o des en vo l vimento n a pl ataf orma Micro so ft .Net nas ver sões do . Net Frame work 4, 4.5 e super iore s para a c riaçã o de So luç ões W eb Corporati vas.
a. A p lataf orma recom enda da é W eb, com arq uitetura Mi cro soft .Net;
b. A l ing uag em rec omenda da para c od if icação de S istemas de Inf ormações é C#;
c. O padrão arq uitetura l recomen dad o para os proj etos de software é o Padrão d e Arq uitetura em Camadas a ssoc iado c om o Mod
Figura 1 - Diagrama do Padrão de Arquitetura em Camadas
Figura 2 - Diagrama do Padrão Model-View-Controller (MVC)
d. Recomendados adoção de Design Patterns para a modelagem de software orientada a objetos e os princípios SOLID para a gestão de dependências dos objetos, onde cada técnica é uma das letras da palavra SOLID. Esses cinco princípios são:
S - Single Responsability Principle (Princípio de responsabilidade única); O - Open Close Principle (Princípio aberto-fechado);
L - Liskov Substitution Principle (Princípio de substituição de Liskov); I - Interface Segregation Principle (Princípio de segregação de interface); D - Dependency Inversion Principle (Princípio inversão de dependência). 2.2. Uti li zan do essas linh as g erais, serão f ormali za das aq ui:
arq uitetura, prát ica s, padrões e outr as def in içõe s rel ati vas à tecno log ia Mi crosoft .Net.
3.
PADRÕES, PRÁTICAS E FRAMEWORK
3.1. Todos os padrões, model os e def in içõe s a serem util i za dos devem seg uir obrig ator ia mente as con ve nções prec on i zad as na espec if icaçã o DO TN E TRIO para Dese n vol vimento de So l uçõ es W eb Corpor ati vas com Mi crosoft .Net.
3.2. Os arq uivo s de cód ig o f onte “.cs” deve m utili zar as con ve nções para a e scrita uti l i za ndo o pa drão Pa scal Cas e para nom es de clas ses e método s, os q uais de vem s er escritos com pa la vra s compostas ou f rases montadas e, Ca melC ase
(http://pt.w ikipe di a.o rg/w iki/C amel Ca se) para vari á ve is e parâmetros de méto dos, conf orme aba i xo:
Estrutura Nomenclatura Exemplo
Classe Pascal PessoaJuridica
Interface I + Pascal ICliente
Método Público ,
Propriedades Pascal NomeCompleto()
Método Privado Camel Case calculaDesconto()
Variável Pública Pascal SobreNome
Variável Privada Camel Case impostoPredial
Constantes Maiúsculas com
sublinhado
VALOR_DESCONT O
Tabela 1 - Convenções para a escrita de código em C#.
Não usar notação húngara, abreviações, um único caractere, sublinhado para nomear variáveis.
Utilize as convenções de código descritas no endereço (http://msdn.microsoft.com/en-us/library/ff926074.aspx).
3.3. A composição dos namespaces construídos para a PCRJ deve seguir a seguinte regra: Rio.<ORGAO>.<PROJETO>.<COMPONENTE_DE_NEGOCIO>.<CAM ADA><TIPO_DDD _CLASSE>; Ex.: Rio.SMF.Iptu.Calculo.Interface Rio.SMF.Iptu.Calculo.Aplicacao Rio.SMF.Iptu.Calculo.Servico Rio.SMF.Iptu.Calculo.Dominio.Entidades Rio.SMF.Iptu.Calculo.Dominio.ValoresObjeto Rio.SMF.Iptu.Calculo.Dominio.Agregados Rio.SMF.Iptu.Calculo.Dominio.Servicos Rio.SMF.Iptu.Calculo.Dominio.Fabricas Rio.SMF.Iptu.Calculo.Infraestrutura.Repositorio Rio.SMF.Iptu.Calculo.Infraestrutura.Util
4.
AUTOMAÇÃO
4.1. Todas as operações necessárias para o desenvolvimento, compilação, testes, distribuição e execução podem ser automatizadas com Team Foundation (http://msdn.microsoft.com/en-us/vstudio/ff637362.aspx) ou pelas ferramentas relacionadas a seguir:
para integração continua, o Jenkins (http://jenkins-ci.org/);
para repositórios e versionamento de arquivos, o Subversion (http://subversion.apache.org);
para o controle de chamados, o JIRA (https://www.atlassian.com/software/jira);
para a inspeção automatizada de código fonte, o Sonar
para gerenciamento de casos de teste, o Testlink (http://testlink.org);
para a execução de testes funcionais automatizados, o Selenium (http://docs.seleniumhq.org);
para a execução de testes de desempenho, o JMeter (http://jmeter.apache.org).
4.2. Os projetos devem ser construídos preferencialmente na IDE Microsoft Visual
Studio (Ambiente de Desenvolvimento Integrado) sempre que possível
tecnicamente;
5.
DOCUMENTAÇÃO
5.1. Toda a documentação deve ser feita em HTML, sendo obrigatória a confecção de marcações XML inseridas nos comentários do programa e das classes com as descrições dos métodos, das propriedades e do domínio quando aplicável, todos no padrão "XML Documentation Comments".
(http://msdn.microsoft.com/en-us/library/b2s063f7.aspx).
6.
DOTNETRIO
6.1. É um conjunto de regras, ferramentas, padrões, frameworks e práticas que auxiliam o desenvolvedor a criar, manter e executar softwares baseados em
6.2. Diagrama da Arquitetura Corporativa DOTNERIO
Figura 3 - Framework para Desenvolvimento de Soluções Web Corporativas em Microsoft .Net.
6.3. Microsoft .Net
Conforme já estabelecido no tópico 3.1 deste documento, todo software Microsoft .Net desenvolvido pela IPLANRIO ou fornecedores deve utilizar os padrões descritos na especificação DOTNETRIO para o Desenvolvimento de Soluções Web Corporativas na plataforma Microsoft .Net. O Framework DOTNERIO é todo baseado nas melhores práticas para desenvolvimento de aplicações Web ASP.Net e utiliza os recursos da
IDE do Visual Studio para desenvolvimento em sua totalidade. Utilizamos desde os templates para a criação de projetos ASP.Net Web Forms e ASP.Net MVC Web até os
recursos nativos do .Net Framework, componentes de segurança Membership, Testes Unitários, Web Services, Web API etc.
Como utilizamos preferencialmente os recursos nativos da Microsoft .Net e da IDE do Visual Studio, não é permitido a criação de Softwares com outros recursos, ferramentas, frameworks e APIs concorrentes, exceto, aquelas que foram homologadas e constam na documentação do framework DOTNETRIO.
Os Softwares criados na IPLANRIO são executados no Servidor Internet Information
Services – IIS nas versões 7 ou superiores.
Os projetos criados pelos templates do Visual Studio já possuem a capacidade de serem executados nos Servidores IIS da IPLANRIO.
Em projetos que utilizamos o Microsoft.Net 4 os softwares são criados com ASP.Net 4 e Entity Framework 5. Quando optamos pelo Microsoft.Net 4.5 os softwares são criados com ASP.Net 4.5 e Entity Framework 6.
Os projetos ASP.Net MVC 4 adotam o RAZOR, HTML 5, jQuery 1.8.2 ou superior em ambas versões do Microsoft .Net. Para persistência de dados também podemos utilizar o NHibernate 3.3.1.4000 com Fluent NHibernate 1.4.1.1. no lugar do Entity
Framework.
Uma prática adotada pelas Equipes é que POCOS devem ser utilizados nos serviços e/ou controladores.
6.4. Documentação detalhada da especificação DOTNETRIO
Corporativas com Microsoft.Net está em constante atualização e poderá ser visualizada na sua última versão no endereço http://dotnetrio.rio.rj.gov.br.
7.
TESTES
7.1. Todas as classes de domínio devem possuir seus respectivos testes unitários com cobertura de código de 100% de acordo com a ferramenta Code Coverage do Visual Studio;
1.1 Os testes unitários não devem acessar outros serviços externos (Rede, Sistema Gerenciador de Banco de Dados - SGBD, etc.). Quando necessários devem utilizar objetos que simulam o comportamento de objetos reais de forma controlada (“mock”);
7.2. Os testes de aceitação (fim-a-fim) devem ser automatizados após a sua respectiva aprovação com o Team Foundation ou Selenium
(http://seleniumhq.org/);
7.3. Todas as classes dentro da camada de Infraestrutura devem possuir seus respectivos testes de integração com cobertura de código de 100% de acordo com a ferramenta Code Coverage do Visual Studio;
7.4. Todos os releases deverão possuir o relatório do Code Coverage, do Code
Analysis e do Code Metrics do Visual Studio antes de serem promovidos para os
ambientes de homologação e produção.
8.
ARQUITETURA
8.1. A estratégia de modelagem de domínios deve ser a DDD (Domain Driven
Design);
8.2. Classes tipo repositório devem implementar a persistência através do Entity
Framework ou do NHibernate;
8.3. A injeção de dependência deve ser priorizada em detrimento a outros padrões de projeto semelhantes (http://martinfowler.com/articles/injection.html);
8.4. É vetada a dependência de qualquer produto SGBD (Sistema Gerenciador de Banco de Dados) específico;
8.5. É vetada a utilização de “triggers” ou “stored procedures” de forma explícita para implantação de regras de negócio;
8.6. A autenticação e a autorização devem ser viabilizadas pelo protocolo LDAP (Lightweight Directory Access Protocol) com a adoção da Membership API;
9.
GUI (Graphical User Interface)
9.1. As páginas que compõem a interface gráfica do usuário - GUI na camada de visão devem ser padrão XHTML (http://www.w3.org/TR/xhtml1/) ou HTML5 (http://www.w3.org/TR/html5).
9.2. É vetada a utilização de qualquer lógica condicional e/ou iteração no código fonte das páginas da GUI (instruções if, for, scriplets, javascript, etc) relacionada a regra de negócio;
9.3. As identidades de cores e características visuais devem ser gerenciadas com a utilização de CSS2 (http://www.w3.org/Style/CSS2/) ou CSS3;
9.4. As imagens devem possuir dimensões padronizadas e devem ser catalogadas
em uma área denominada Banco de Imagens
(http://www.abraweb.com.br/site/banners.php);
9.5. Os relatórios devem fornecer saída nos seguintes formatos: html e pdf, sendo desejável as saídas nos formatos txt, json, xml e csv;
9.6. A GUI deve ter aparência e comportamento idênticos nos navegadores mais utilizados (p.ex: atualmente: IE, Firefox, Chrome e Safari);
10.
AMBIENTES
10.1. São quatro os ambientes necessários para o desenvolvimento e execução das soluções baseadas no DOTNERIO, considerando as boas práticas para garantir a integridade do software produzido: Local, Desenvolvimento, Teste, Homologação e Produção:
a) Local: este ambiente é estabelecido na máquina do desenvolvedor aonde possui total acesso e liberdade de manuseio;
é acessado somente pelo líder do projeto utilizando como ferramenta um integrador contínuo;
c) Homologação: este ambiente também está localizado no DataCenter da IplanRio e é acessado somente pelo setor de qualidade e produção, utilizando como ferramenta um integrador contínuo;
d) Produção: este ambiente também está localizado no DataCenter da IplanRio e é acessado somente pelo setor de produção, utilizando como ferramenta um integrador contínuo;
11.
ACOMPANHAMENTO
11.1. O acompanhamento do desenvolvimento será feito em ferramenta de controle de projeto/tarefas com acesso pela IplanRio, no papel de responsável técnica, (por exemplo: Project Builder http://wwwH.projectbuilder.com.br/ e JIRA
-http://wwwH.atlassian.com/software/jira/);
12.
GERÊNCIA DE CONFIGURAÇÃO
12.1. Todos os artefatos devem ser versionados nos repositórios especificados pela IplanRio.
12.2. As ramificações criadas no versionador possuem prazo de validade; 12.3. Sobre a política de numeração de versões:
As versões dos aplicativos são numeradas da seguinte forma: A.B.C onde:
A = Produção (número da entrega para a produção)
B = Homologação (número da entrega para a homologação) C = Validação (número da entrega para a validação)
Exemplo: Um aplicativo com o número de versão 2.3.11 sugere que foi para a validação do cliente onze vezes, foi homologado três vezes e foi para a produção duas vezes.
As versões das ferramentas, Application Programming Interface (ou
Interface de Programação de Aplicações) - APIs, servidores, máquinas
virtuais .Net Framework e outros serão dadas pelas versões correntes ativas no ambiente de homologação.
13.
EXCEÇÕES
13.1. Todas as exceções e dúvidas relacionadas a este documento devem ser tratadas, decididas e justificadas pela IplanRio, tendo como referência o responsável pelo padrão indicado no tópico 4 da ficha técnica do padrão Desenvolvimento em dotNet para aplicações Web (P05.004).
