Guía para explicar la importancia de la separacion de componentes y unidades de puesta en marcha.

1. Diseño modular de
sistemas
Desde el diseño general, podemos facilitar la entrega de software:
• En menos tiempo
• Con menos conflictos
• Y menos defectos

2. Introducción
¿Por qué queremos seguir lineamientos de diseño de
sistemas?
¿Qué es un diseño modular?
Sus ventajas y cómo lograrlo.

3. ¿Por qué queremos seguir lineamientos
de diseño de sistemas?
En nuestro día a día, vivimos inconvenientes y dificultades debido a que las relaciones
entre las piezas de software no siguen patrones establecidos.
Esto nos afecta directamente:
1. Tardamos mucho tiempo haciendo cambios aparentemente sencillos.
2. Producimos incidentes aunque hacemos análisis cuidadosos y pruebas.
3. Nuestros esfuerzos de migración a nuevas tecnologías son muy costosos.
Esto quiere decir que no estamos en control debido a la complejidad del software, y
dicha complejidad se reduce si aplicamos líneas de diseño modular.
Esta guía trata con el diseño general de las piezas de software. Otro tema esencial es
el diseño del código fuente y sus algoritmos.

4. Empecemos definiendo qué es un
sistema
Llamamos un sistema a un conjunto de funcionalidades que están relacionadas y que operan
sobre una base de datos. En ciertos contextos, llamamos un “Servicio SINPE” a un sistema
dentro de la plataforma SINPE.
Un sistema se compone de todos los componentes de aplicación (DLLs), Servicios web
(webservices, wcfs) e interfaces graficas (web, desktop, etc).
Cada sistema es dueño de los objetos de base de datos que tienen que ver con sus
funcionalidades.
Por ejemplo, el servicio TVA es el dueño de todas sus Tablas. Si hace un cambio en una de sus
tablas, es responsable de que todo procedimiento almacenado y vista que opere sobre sus
tablas siga funcionando correctamente .
Igualmente, si hace un cambio en uno de sus componentes de aplicación, es responsable de
que todos sus clientes funcionen correctamente.

5. ¿Qué es un diseño modular?
Llamaremos diseño modular a la idea de que la organización jerárquica de cualquier
sistema ayuda a mantener el orden y el control.
La naturaleza y nuestros mismos cuerpos siguen un diseño modular, donde los
órganos se componen de células que a su vez tienen componentes internos. Así se
mantiene el orden en el intercambio de información.

6. Las ventajas del diseño modular en
software
1. Nos permite hacer cambios con el mínimo impacto y riesgo.
2. Nos permite realizar desarrollos y liberaciones en paralelo y con menos conflictos.

7. Cómo identificar los
builds
Inicie con un buen modelo de casos de uso
Cada build es un canal de entrada.

8. Un sistema ofrece servicios por distintos
canales
Estos canales de entrada de datos serán la clave para lograr una separación adecuada.
CDF
ERP Otros sistemas
que necesitan
consultar datos
de cuentas
CalendarizadorPersonas
website webservice
webservice

9. Un build es un canal de entrada de datos
Bccr.Sinpe.Cdf.
ProcesosCalendarizados
Bccr.Sinpe.Cdf.Opciones
Bccr.Sinpe.Cdf.Erp Bccr.Sinpe.Cdf.Consultas
ERP Otros sistemas
que necesitan
consultar datos
de cuentas
Calendarizador
Personas
website webservice
webservice wcf

10. ¿Cómo lograr el diseño modular?
1. Definiremos cómo dividir un sistema completo en unidades a las que llamaremos
Builds.
2. Definiremos cómo se pueden comunicar los Builds.
TVA GSP

11. ¿Cómo identificar los builds de un
sistema?
A partir del modelo de casos de uso, identifique los distintos canales de entrada de
datos:
“Personas que usan el UI”: un website
“Contabilidad”: un webservice
“Entidad origen”: servicios wcf
“Hacienda”: webservices
“Procesos calendarizados”: servicios wcf.
Si cada canal de entrada es ejecutado por una pieza de software independiente,
entonces podemos entender, cambiar y liberar cambios en ese canal sin tener que
modificar o probar los demás.
Esto nos permite hacer desarrollos en paralelo para cada canal de entrada, lo que
implica menos conflictos de permisos y tiempo de desarrollo.

12. Un canal de entrada sirve a un tipo de
actor
CDF
ERP Otros sistemas
que necesitan
consultar datos
de cuentas
Calendarizador
Personas
website webservice
webservice
Cada canal de entrada de datos tendrá un
build para servicios que sólo él necesita.

13. Un ejemplo, el sistema PVB
Este sistema tiene los siguientes canales de entrada, es decir, los casos de uso son
iniciados por medio de:
-Un sitio web para funcionarios internos
-Un sitio web por medio de internet
-Ejecución automática de procesos calendarizados
-Consultas para otros sistemas
Con esta información general, podemos separar el sistema en cuatro builds. Cada uno
es independiente de los demás. Todos comparten y encapsulan su base de datos.

14. Cómo manejar las
relaciones
Los componentes de un build
Los builds encapsulan la base de datos
El manejo de referencias entre builds
Los builds protegen la base de datos

15. Los componentes de un build
Un build tiene un solo componente como un canal de entrada. Por ejemplo, un
website, wcf o webservice:
1. Si un build contiene un website, no da servicios WCF a otros sistemas.
2. Si ofrece servicios WCF para el sistema ERP, no contiene servicios Webservice
para la Contabilidad.
Los componentes de un build son utilizados solamente dentro del mismo build.
Un build puede acceder directamente a la base de datos del mismo sistema.
Bccr.Sinpe.Rex.Opciones
Personas
website
UI DS
Base de
datos de
Rex

16. Los builds encapsulan su base de datos
Bccr.Sinpe.Cdf.
ProcesosCalendarizados
Bccr.Sinpe.Cdf.Opciones
Bccr.Sinpe.Cdf.Erp Bccr.Sinpe.Cdf.Consultas
ERP Otros sistemas
que necesitan
consultar datos
de cuentas
Calendarizador
Personas
website webservice
webservice wcf
Para mantener un diseño modular, ningún otro sistema debe acceder a la base de datos ni a los DLLs
del servicio. Esto aplica también para nuestra base de datos la cual no accede a objetos de base de
datos de otros servicios o sistemas. Esta línea de diseño también abarca las vistas y llaves foráneas.
Con esto, encapsulamos los detalles de la persistencia de los datos y facilitamos los cambios a futuro.

17. Manejo de las referencias entre builds
Un build puede utilizar otros builds a través de servicios (wcf, webservice, web api).
No accede DLLs o a objetos de base de datos de otros sistemas.
Bccr.Sinpe.Cdf.Opciones
Personas
website
Objetos de base
de datos de otro
servicio
DLLs de otro
build

18. Los builds protegen su base de datos
Bccr.Sinpe.Cdf.
ProcesosCalendarizados
Bccr.Sinpe.Cdf.Opciones
Bccr.Sinpe.Cdf.Erp Bccr.Sinpe.Cdf.Consultas
website webservice
webservice wcf
Otros sistemas
Deberíamos poder modificar cualquier aspecto de la base de datos de
un sistema y los únicos impactados por los cambios deberían ser los
builds del propio sistema. Esto nos hace mas eficientes y confiables.

19. Respecto al rendimiento
¿Comunicar nuestros sistemas a través de servicios podría afectar el rendimiento?
Sabemos que lo más rápido es hacer las consultas directamente dentro de una sola
base de datos, sin embargo para poder mantener bajo control la complejidad de los
sistemas necesitamos mantener una separación de los esquemas de base de datos.
Lo más importante es que tengamos visibilidad del rendimiento de cada funcionalidad
que desarrollemos y así podemos optimizar cada consulta para que todo el proceso
tenga un rendimiento aceptable.
Para esto, utilice un profiler como Prefix para identificar el rendimiento de cada punto
de integración de la aplicación: http://stackify.com/prefix

20. Stackify Prefix
Esta herramienta se instala en la PC
de desarrollo y nos muestra el
rendimiento de:
Llamados web http, json
Llamados WCF, WS, Web APÍ
Consultas a base de datos
Excepciones
Etc.
http://stackify.com/prefix

21. Liberaciones
Un build es una unidad de liberación.
Los drops son los instaladores versionados.

22. Un build es una unidad de liberación
Todos los componentes del build se compilan, empaquetan y liberan siempre juntos.
Una separación adecuada de builds nos permite hacer cambios en paralelo, lo cual
nos ayuda a entregar software mas rápido.
Bccr.Sinpe.Rex.Opciones
Personas
website
UI DS Negocio
Base de
datos de
Rex

23. Drops – los instaladores versionados
Cada build es integrado por un servidor de integración continua, y genera un Drop.
Un Drop contiene todo lo necesario para instalar el software (componentes e
instrucciones para su instalación automática).
El Drop puede instalar solamente los componentes de su build, nunca los
componentes de otros Builds o componentes de terceros.
Los drops tienen etiquetas con su numero de versión, lo que permite una trazabilidad
completa desde del código fuente hasta los componentes en producción.
Por ejemplo, Bccr.Firma.Fva.Cliente-401 significa que en TFS hay un Label que se
puede consultar para obtener el código fuente que generó ese Drop. Además, en LAS
se registra esa versión, sus dependencias y las liberaciones asociadas.

24. Análisis de
dependencias
La importancia
¿Cómo analizar componentes?
¿Cómo analizar la base de datos?

25. La importancia de analizar las
dependencias de un sistema
El diseño modular nos ayuda a mantener las dependencias bajo control.
Es decir, cuando tenemos que cambiar un sistema queremos afectar a la mínima
cantidad de elementos para tardar menos tiempo y reducir el riesgo de incidentes.
Esto quiere decir, que con cada relación que agreguemos debemos revisar que se
respeten los lineamientos.
Este análisis de dependencias lo realizamos de dos maneras:
1. Con el sitio web de componentes
2. Con el SQL Server Management Studio

26. ¿Cómo analizar las dependencias de mis
componentes?
Cada vez que un build de integración
continua se ejecuta, se analiza las
referencias de sus componentes hacia
DLLs o a WCFs, y dicha informción se
guarda en una base de datos.
En http://ponce/componentes, se
puede hacer consultas de dichas
dependencias:
- Entre componentes
- Entre builds.
- Entre sistemas (soluciones
tecnológicas)

27. ¿Cómo analizar las dependencias de
base de datos?
En SQL Server Management Studio,
1. Verifique que sus objetos de base de datos no
referencian a objetos de otros sistemas.
2. Verifique que otros sistemas no referencien sus objetos.
Sabemos que las dependencias con Triggers pueden no
mostrarse en esta vista, por lo que en el siguiente slide
damos la opción más completa.
Idealmente, cada sistema debe poseer su base de datos
independiente.

28. La búsqueda más completa de
dependencias de base de datos
Para buscar en el código de la base de datos, consulte la tabla Syscomments. Esta
tabla del sistema contiene el código que define los procedimientos almacenados,
vistas y funciones.
select o.name, o.type
from syscomments c
inner join sysobjects o on o.id = c.id
where
c.text like '%CLCChequeAct%'

29. ¿Por qué debo ocuparme de tantos
detalles?
Como profesionales, cada vez que modificamos un elemento de software somos
responsables por el buen funcionamiento de todos los otros elementos que lo
utilizan.
No hay diferencia si ese elemento es una clase .NET o un objeto de base de datos. Lo
más importante es que si no somos cuidadosos en este análisis, podríamos ocasionar
inconvenientes a las personas que dependen de nuestro software.

30. Conclusiones
1. Un sistema organizado con builds nos permite realizar desarrollos y liberaciones en
paralelo y con menos conflictos.
2. El diseño modular de los builds y su base de datos nos permite hacer cambios con
el mínimo impacto y riesgo.

31. Diseño modular de
sistemas
Desde el diseño general, podemos facilitar la entrega de software:
• En menos tiempo
• Con menos conflictos
• Y menos defectos