Desarrollo de Sistemas a Medida

Realizando sistemas a medida orientado a servicios

Realizamos Tiendas Online

Te construimos tu tienda online para que ofrescas tus productos y ganes más

Realizamos reportes online y en excel

Analisis de información para generar reportes

Soporte Informático

No pierdas tiempo tenemos el mejor servicio de soporte garantizado

Auditoria Informática

Te asesoramos para sacar el mayor beneficio de la tecnología

martes, 26 de junio de 2018

Plan de estudio - Programación 2


CARRERA : INGENIERÍA DE SISTEMAS 
SEMESTRE : SEXTO 
ASIGNATURA : ANÁLISIS Y DISEÑO DE SISTEMAS I 
SIGLA O CÓDIGO : INS216
PRE-REQUISITO : INS215
CARGA HORARIA : HT = 52; HP = 36 , TOT = 88 
CRÉDITOS : 9 
DOCENTE : Ing. Angel Céspedes Quiroz
UNIVERSIDAD : Universidad Nacional del Oriente

I. COMPETENCIAS 

ALCANCE 

Aprender los fundamentos e identificar y programar los distintos tipos de relaciones de la programación orientada a objetos, así también programar interfaces gráficas.

a) Genérico o básica 

Adquiere los conocimientos necesarios de programación orientada a objetos y programación visual. 

b) Disciplinaria 

Reconoce los diagramas de UML que se utilizan para en el análisis de la arquitectura, casos de uso y clases. Valora la importancia de elaborar el análisis del sistema para facilitar el trabajo en el diseño y la programación. 

Al término del curso, el estudiante será capaz de: 

a. Manejar correctamente la programación orientado a objetos, interpretando modelos y programando los mismos. 

b. Aprender a programar interfaces graficas. 

II. PRIORIZACIÓN DE HABILIDADES INTELECTUALES DE ORDEN SUPERIOR 

a. Pensamiento analítico, crítico y reflexivo. 

III. CONTENIDO MÍNIMO 

Fundamentos de programación. Programación Orienta a Objetos. Programación Visual en C#.

IV. UNIDADES PROGRAMÁTICAS 

1. FUNDAMENTOS DE LENGUAJES DE PROGRAMACION
  • Lenguajes de Maquina.
  • Lenguajes Ensambladores.
  • Lenguajes De Alto Nivel.
  • Lenguajes Compilados. 
  • Lenguajes Interpretados. 
  • Lenguajes Declarativos. 
  • Lenguajes Imperativos. 
  • Lenguajes Orientado a Objetos.
2. PROGRAMACIÓN ORIENTADA A OBJETOS 

Ø  Conceptos generales de programación orientada a objetos.
Ø  Asociacion
Ø  Herencia.
Ø  Agregación.
Ø  Composición
Ø  Programación de las relaciones en C#.

3. PROGRAMACION VISUAL EN C#

Ø  Programación básica en lenguajes visuales.
Ø  Programación avanzada en lenguajes visuales.

V. EVALUACIÓN A LOS ESTUDIANTES 

a. Trabajos Prácticos 20 Puntos
b. Primer Parcial 20 Puntos
c. Segundo Parcial 20 Puntos
d. Examen Final 40 Puntos

TOTAL, CALIFICACIÓN 100 Puntos

VI. METODOLOGÍA

a. Clases magistrales.
b. Resolución de casos prácticos.

VII. BIBLIOGRAFÍA 

1.    Arbib-Alagic, The Design of Well Structured and Correct Programs, Springer Verlag
2.    Joyanes Aguilar, Fundamentos de la Programación, Editorial McGraw Hill
3.    Joyanes Aguilar, Programación Orientada a Objetos, Editorial McGraw Hill
4.    Cevallos J., Microsoft Visual C++, Programación Avanzada, Ra-ma
5.    0Knuth, D., Fundamental Algorithms, Addison Wesley
6.    Harel D., Algorithmics: The Spirit of Computing, Addison Wesley
7.    Blaider E., Programación en Java, Editorial Megabyte
8.    Lemay L, Aprendiendo HTML para Web, Simon & Schuster

VII. HERRAMIENTAS

jueves, 21 de junio de 2018

Conceptos básicos de VueJS


Vue.js es un framework de JavaScript nuevo, si lo comparamos con otros frameworks como Backbone o Ember.

Sin embargo, su facilidad de aprendizaje y uso con respecto a otros frameworks y libraries como ReactJS, su rendimiento comparado con AngularJS y la facilidad para usarlo y adaptarlo a proyectos tanto grandes como pequeños, ha hecho que Vue gane cada vez más popularidad.

Objetos especiales

vm:
el objeto que representa la instancia de Vue.
key: propiedad que identificará como único a un elemento para ser reutilizado por Vue
$data: variable que contiene el modelo de la instancia Vue en el objeto vm.
$event: variable que representa el evento cuando se ejecuta en la instancia Vue en el objeto vm.
$store: variable que representa el estado de la aplicación cuando se usa Vuex en Vue.
$route: variable que representa el objeto de rutas de la aplicación cuando se usa Vue Router en Vue.
template: etiqueta HTML que mantiene el contenido del lado del cliente que no se renderiza cuando se carga una página, pero que posteriormente puede ser instanciado durante el tiempo de ejecución empleando JavaScript.

Directivas

Atributos especiales que nos permiten realizar cambios reactivos en el DOM.

v-model: enlaza los datos a través de la propiedad data .
v-bind: añadir o remover atributos ( atajo : ).
v-show: permite mostrar u ocultar contenido del DOM sin eliminarlo del mismo, no funciona con la etiqueta template.
v-if, v-else-if, v-else: condicionales.
v-for: ciclos, se puede usar el operador in u of indistintamente.
v-on: manejar eventos ( atajo @ ).
v-once: evita la reactividad en un elemento, lo vuelve estático.
v-text: muestra contenido textual dentro de un elemento, NO acepta código HTML.
v-html: muestra contenido textual dentro de un elemento, SÍ acepta código HTML.
v-pre: ignora las expresiones Vue del elemento, evitando la compilación reactiva del mismo.
Interpolaciones

  • Enlazan de datos entre Vue.js y el DOM. Se requiere el uso de las dobles llaves

{{ propiedad }}


  • Podemos hacer operaciones aritméticas

{{ 19 + 7 }}


  • Podemos concatenar

Hola, {{ propiedad + ':)' }}


  • Podemos hacer expresiones de una sola línea

{{ propiedad ? true : false }}

lunes, 18 de junio de 2018

Desarrollador web: Front-end, back-end ¿Quién es quién?

Un desarrollador web no es una sola cosa, sino que abarca múltiples conjuntos de habilidades que se traducen en diferentes especialidades. Los tres términos más comunes que se utilizan para nombrar dichas especialidades de forma genérica son: front-end, back-end y full stack. En este artículo trataremos de definir cada una de ellas y ver sus diferencias.

Desarrollador Front-end:

Trabaja del lado Cliente, en el navegador, en el lado de lo que se ve. Principalmente se ocupa de los componentes externos del sitio web o de la aplicación web. Como consecuencia, deben dominar obligatoriamente:

HTML: HyperText Markup Language, es el componente estructural clave de todas las webs de internet. Sin él las páginas web no pueden existir.

CSS: Cascading Style Sheets, es lo que le proporciona estilo a HTML.

JavaScript: Usando solo HTML y CSS tus webs serían páginas estáticas, con JS tus páginas web son interactivas.

Desarrollador Back-end:
El desarrollador back-end trabaja del lado Servidor, detrás del escenario, permitiendo con su trabajo que el usuario disfrute de su experiencia.

Sin él, el desarrollo llevado a cabo por su anterior compañero no se sostendría.

Para ser programador del lado Servidor, son numerosos los lenguajes y frameworks entre los que elegir, todo dependerá de la empresa en la que caigas.

A día de hoy, los más comunes son:


ASP.NET: es la plataforma de desarrollo web de Microsoft. Muy utilizada en las empresas. Tiene las variantes Web Forms y MVC, y ahora también ASP.NET Core MVC.
PHP: por ejemplo, el famoso gestor de contenidos WordPress usa por detrás PHP. Laravel es uno de los frameworks usados con este lenguaje.
Ruby: junto con su framework Ruby on rails.
Python: fácil de aprender. Usado a menudo con Django como framework
Node.js: se está haciendo cada vez más popular debido a que usa el mismo lenguaje que en el lado cliente: JavaScript.
Java: el lenguaje clásico y uno de los más demandados.

Sin embargo, no es suficiente con dominar un lenguaje y un framework. Toda aplicación web debe almacenar datos de alguna manera. Por lo tanto, un desarrollador back-end también debe estar familiarizado con las bases de datos. Entre las más comunes destacan:
  • SQL Server
  • MySQL
  • Oracle
  • PostgreSQL
  • MongoDB, que es un almacén de datos no-relacional o NoSQL.
Al igual que hemos comentado antes el entorno en el que trabajes te obligará a especializarte en una u otra.


viernes, 18 de mayo de 2018

Solución sobre desarrollo MonoDevelop usando GTK# en Windows 64 bits


Para poder correr un programa escrito en C#, que use GTK#, en Windows, primero es necesario instalar GTK# for .NET

Por lo que el instalador de un programa que usa GTK# debería checar la versión de GTK# ya instalada, si hay una, y si es oportuno ejecutar la instalación de GTK# antes de instalar la aplicación que depende de ella.

El problema aparece cuando estamos usando GTK# 32 bits en un Windows de 64 bits. Si la solución la creamos en MonoDevelop corriendo en Windows no habrá mayores complicaciones.

Podemos compilar sin problemas en Windows 64 bits. Pero yo me he topado casos en los cuales después de compilar desde MonoDevelop corriendo en Linux 64 bits, el assembly resultado de la compilación no corre en Windows 64 bits (no hay problema si el sistema es de 32 bits).

Aún si en las propiedades del proyecto figura como 32 bits. Mientras que al revés sí funciona, compilar en Windows y luego correr en Linux usando Mono.

Al intentar recompilar el programa usando MonoDevelop en Windows resulta que ahora no encontraba ninguna de las referencias. Desde GTK#, glade, etc. Nada, como si ninguna estuviera instalada. Noten que GTK# sí estaba instalada en el sistema.

Según las listas de correo del proyecto Mono se debe forzar la arquitectura como de 32 bits. Pero en mi caso, en las propiedades del proyecto ya figuraba como 32 bits.

La primera vez que tuve este problema lo solucioné yendo a las propiedades del proyecto y volviendo a seleccionar x86 en todas las páginas en las que aparece un Combo Box que permita seleccionar la arquitectura. Luego, al recompilar, se podía correr el programa de nuevo en Windows con total normalidad.

Pensé que con esto bastaba pero cuando volví a editar el proyecto desde Linux, y recompilé, al querer correrlo en Windows ocurrió lo mismo que la primera vez. E igual que la primera vez las versiones de Windows de 32 bit no se vieron afectadas, pero era imposible correr el programa en Windows de 64 bit. Intenté solucionarlo igual que lo había hecho la primera vez pero no funcionó.

Lo que sí me funcionó esta segunda vez fue borrar el ejecutable del programa y el archivo pdb que queda en el mismo directorio después de compilar. Luego abrí el archivo de solución (sln) con MonoDevelop y recompilé y ahora sí todo fue como se esperaba.

No aparecieron errores relacionados con referencias faltantes a GTK#.
Quisiera poder dar más información sobre esto pero por ahora me es imposible. Simplemente diré que este problema se presenta cada vez que edito el proyecto desde Linux y lo compilo. El resultado de esa compilación corre bien tanto en Linux 32/64 bit como en Windows de 32 bit. Pero para poder correr el programa en Windows 64 bit debo hacer lo que indico más arriba y recompilar, de lo contrario obtengo un montón de errores de referencias a GTK# que no se pueden satisfacer.

Los archivos pdb sólo se generan si compilamos con el objetivo debug del proyecto. O pasando /debug al compilador.

miércoles, 25 de abril de 2018

UML: Diagrama de Componentes y de Despliegue



Un diagrama de componentes es un diagrama tipo del Lenguaje Unificado de Modelado. Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes.

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar la disposición física de los artefactos software en nodos (usualmente plataforma de hardware

Adjunto la presentación:

lunes, 23 de abril de 2018

UML: Diagrama de Colaboración



Introducción.

Los diagramas de colaboración son otro tipo de diagramas de interacción, que contiene la misma información que los diagramas de secuencia, sólo que se centran en las responsabilidades de cada objeto, en lugar del tiempo en que los mensajes son enviados. Un Diagrama de Colaboración describe en forma de un grafo el comportamiento de sistemas, subsistemas y operaciones, representando los objetos que intervienen, así como los mensajes que intercambian, enumerados en el tiempo.

Definición.


El diagrama de colaboración es un tipo de diagrama de interacción cuyo objetivo es describir el comportamiento dinámico del sistema de información mostrando cómo interactúan los objetos entre sí.

Propósitos.

  • Manejar la comunicación entre los elementos del sistema. 
  • Mostrar cómo será implementada una operación. 
  • Indicar cómo deben colaborar los objetos del sistema para llevar a cabo una operación. 

Características.
  • Muestra cómo las instancias específicas de las clases trabajan juntas para conseguir un objetivo común. 
  • Implementa las asociaciones del diagrama de clases mediante el paso de mensajes de un objeto a otro. Dicha implementación es llamada "enlace". 

Ventajas.

  1. Permite elegir el orden en que pueden hacerse las cosas. 
  2. Puede describir procesos o casos de uso. 
  3. Muestra los aspectos dinámicos de un sistema. 
  4. Establece las reglas de secuencia a seguir. 
  5. Ayuda a un programador a desarrollar código a través de una descripción lógica de un proceso. 
Desventajas

La gran desventaja de los diagramas de colaboración es que no indican de forma explícita que los objetos ejecutan qué actividades ni tampoco la forma en que el servicio de mensajería trabaja entre ellos. Para mostrar tales interacciones de forma clara son necesarios los diagramas de interacción, los cuales son más utilizados en la práctica.

Elementos.

Objetos o Roles
: nodos del grafo.
Enlaces o comunicaciones: arcos del grafo.
Mensajes: llevan número de secuencia y flecha dirigida.
Anidamiento: se utiliza la numeración decimal
Iteración: colocar un * antes del número de secuencia y una cláusula de condición, si es necesario.
Bifurcación: los caminos alternativos tendrán el mismo número de secuencia, seguido del número de subsecuencia, y se deben distinguir por una condición.


Ejercicio Práctico:

Caso de Uso: Generar pedido




UML: Diagrama de secuencia


Diagrama de Secuencia.

Introducción.


El diagrama de Secuencia, muestra gráficamente los eventos que originan los actores dentro de un sistema y cómo se comunican (interactúan) entre sí a lo largo del tiempo. Esta descripción es importante porque puede dar detalle a los casos de uso, aclarándolos al nivel de mensajes.El diagrama de secuencia es más adecuado para observar la perspectiva cronológica de las interacciones, muestra la secuencia explícita de mensajes y son mejores para especificaciones de tiempo real y para escenarios complejos. La creación de los diagramas de secuencia forma parte de la investigación para conocer el sistema, por lo que es parte del análisis del mismo.

Definición.

Los diagramas de secuencia ilustran la interacción entre objetos y el orden secuencial en el que ocurren dichas interacciones, es decir cómo se comunican los objetos entre sí.

Propósitos.

Poner énfasis en el orden y momento en que se envían los mensajes a los objetos.
Proporcionar un camino a partir de los escenarios para describir las operaciones en una forma más detallada.
Mostrar la secuencia de comportamiento de un caso de uso.

Características.

Mostrar la secuencia de mensajes entre objetos durante un escenario concreto.
Cada objeto viene dado por una barra vertical.
El tiempo transcurre de arriba abajo.
Cuando existe demora entre el envío y la atención se puede indicar usando una línea oblicua

Ventajas.

Da la posibilidad de representar los mensajes en función del tiempo.
La separación de los mensajes no indica intervalos o cantidades de tiempo, solo ordenación temporal.
Es posible añadir restricciones temporales.

Desventajas.

Una representación de un diagrama de secuencia demasiado largo, puede ser difícilmente entendido por alguien ajeno al sistema.

Elementos.

OBJETOS:

Se obtienen de los diagramas de casos de uso, y se representan con dos componentes: opcionalmente el nombre del objeto, y la clase a la que pertenece.


MENSAJES:

Es una comunicación entre objetos que transmite información con la expectativa de desatar una acción. La recepción de un mensaje es, normalmente, considerada un evento Se representan mediante una flecha horizontal que va desde la línea de vida del objeto que envió el mensaje hasta la línea de vida del objeto que ha recibido el mensaje.


MÉTODOS Y OPERACIONES:

Son representados con rectángulos que se encuentran sobre la línea del objeto al cual pertenecen. La longitud de estos rectángulos se puede usar para determinar cómo se va estableciendo el control durante la secuencia, ya que un método obtiene el control desde el inicio del rectángulo hasta el final del rectángulo.


RECURSIVIDAD:

En ocasiones un objeto posee una operación que se invoca a sí misma. A esto se le conoce como recursividad y es una característica fundamental de varios lenguajes de programación.


Ejercicio Práctico:

Caso de Uso: Logueo del sistema


viernes, 20 de abril de 2018

UML: Diagrama de Paquetes


Un diagrama de paquetes en el Lenguaje Unificado de Modelado representa las dependencias entre los paquetes que componen un modelo. Es decir, muestra cómo un sistema está dividido en agrupaciones lógicas y las dependencias entre esas agrupaciones.


  • Proyecto MVC Hibernate



  • Proyecto 3 capas con Hibernate  



  • Proyecto 3 capas

jueves, 19 de abril de 2018

UML: Diagramas de Actividad

En diagrama de actividades muestra un proceso de negocio o un proceso de software como un flujo de trabajo a través de una serie de acciones. Las personas, los componentes de software o los equipos pueden realizar estas acciones.


Puede usar un diagrama de actividades para describir procesos de varios tipos, como los ejemplos siguientes:
    Un proceso de negocio o un flujo de trabajo entre los usuarios y el sistema. 
    Los pasos que se realizan en uno o varios casos de uso. 
    Un protocolo de software, es decir, las secuencias de interacciones entre componentes permitidas.
Adjunto va el documento de la presentación:

miércoles, 18 de abril de 2018

UML: Diagrama de Estados

Como ya he mencionado en ediciones anteriores y se lo repetimos a nuestros alumnos constantemente en nuestros cursos para evitarles la burocracia en su trabajo, no todos los proyectos requieren utilizar todos los artefactos de UML. Uno de estos artefactos que no veremos en cualquier proyecto es el diagrama de estados. Aunque, en ciertos proyectos no es opcional, sino indispensable utilizarlos.

Adjunto va el archivo con la presentación del tema en cuestión:


jueves, 12 de abril de 2018

UML: Diagrama de Casos de Uso

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactuan (operaciones o casos de uso).


UML: Diagrama de Clases

En ingeniería de software, un diagrama de clases en Lenguaje Unificado de Modelado (UML) es un tipo de diagrama de estructura estática que describe la estructura de un sistema mostrando las clases del sistema, sus atributos, operaciones (o métodos), y las relaciones entre los objetos.
Presentación:

lunes, 2 de abril de 2018

INTRODUCCIÓN AL UML

1.    INTRODUCCIÓN AL UML



 
1.1.    INTRODUCCIÓN

Como la guerra de métodos de modelado de objetos no hacía progresar la tecnología de objetos, Rumbaugh y Booch decidieron unificar sus trabajos en un método único: el método unificado (The Unified Method). La primera versión de la descripción del método unificado fue presentada en octubre de 1995 en un documento titulado Unified Method 0.8. Un año después se les unió Jacobson y el método unificado se transformó en UML (The Unified Modeling Language). Asimismo durante el año 1996 se crea un consorcio de colaboradores para trabajar en la definición de la versión 1.0 de UML, que agrupa a grandes empresas del sector. De esta colaboración nace la descripción del UML versión 1.0 enviada el 17 de enero de 1997 al OMG (Object Management Group), constituyéndose en un estándar en el mes de julio del mismo año. 

Sus creadores insisten en el hecho de que UML es un lenguaje de modelado de objetos y no un método de objetos. La notación UML ha sido pensada para servir de lenguaje de modelado de objetos, independientemente del método implementado. Así pues, la notación UML puede subsistir a las notaciones de Booch, OMT (Objetc Modeling Technique) o incluso OOSE (Object Oriented Software Engineering también llamada Objectory).

1.2.    MODELO CONCEPTUAL DEL UML

Para entender el UML, necesitamos constituir un modelo conceptual del lenguaje, y esto requiere aprender tres elementos importantes: los bloques de construcción básicos del UML, las reglas que dictan cómo estos bloques se pueden poner juntos, y los mecanismos comunes que se aplican a lo largo del UML. 

1.2.1.    Bloques de construcción del UML

El vocabulario del UML engloba tres tipos de bloques de construcción:

1.    Cosas
2.    Relaciones
3.    Diagramas

Las cosas son abstracciones del mundo real; las relaciones conectan estas cosas; los diagramas agrupan colecciones de cosas.

1.2.1.1.    Cosas 

Hay cuatro tipos de cosas en el UML:

1.    Cosas de estructura

Las cosas estructurales son los nombres de los modelos UML. Éstas son mayormente las partes estáticas de un modelo, representando elementos que son bien conceptuales o bien físicos. 

Los siguientes elementos – clases, interfaces, colaboraciones, casos de uso, componentes y nodos – son las cosas estructurales básicas que nos pueden ayudar en un modelo de UML. Hay algunas variaciones en estos elementos, tales como actores, señales y utilidades (tipos de clases).

2.    Cosas de comportamiento

Las cosas de comportamiento son las partes dinámicas de los modelos del UML. Éstas son los verbos de un modelo, representando el comportamiento en el tiempo y en el espacio. 

Los dos siguientes elementos – interacciones y máquinas de estado – son las cosas de comportamiento básicas que nos pueden ayudar en un modelo de UML. Semánticamente, estos elementos están conectados a varios elementos estructurales, principalmente clases, colaboraciones y objetos.

3.    Cosas de agrupamiento

Las cosas de agrupamiento son las partes de organización de los modelos del UML. Éstas son las cajas en las que se puede descomponer un modelo.

Los paquetes son las cosas de agrupamiento básicas con que podemos organizar un modelo de UML. Hay algunas variaciones, tales como subsistemas (tipos de paquetes). 

4.    Cosas de anotación

Las cosas de anotación son las partes de explicación de los modelos del UML. Éstas son los comentarios que podemos aplicar para describir cualquier elemento en un modelo.

Las notas son las cosas de anotación básicas que podemos incluir en un modelo de UML. Normalmente utilizamos notas para adornar nuestros diagramas con restricciones o comentarios que son expresadas en texto formal o informal.

1.2.1.2.    Relaciones 

Hay tres tipos de relaciones en el UML:

1.    Relaciones de asociación

Una asociación es una relación de estructura que describe un conjunto de enlaces, siendo un enlace una conexión entre objetos. La agregación es un tipo especial de asociación, representando una relación de estructura entre un todo y sus partes.

2.    Relaciones de dependencia

Una dependencia es una relación semántica entre dos cosas en las que un cambio en una cosa (la cosa independiente) puede afectar a las semánticas de la otra cosa (la cosa dependiente). También hay variaciones, tales como «includes» y «extends».

3.    Relaciones de generalización

Una generalización es una relación de especialización/generalización en la que los objetos del elemento especializado (el hijo) son sustituibles por objetos del elemento generalizado (el padre). De esta forma, el hijo comparte la estructura y el comportamiento del padre.

1.2.1.3.    Diagramas 

Un diagrama es la presentación gráfica de un conjunto de elementos, la mayoría de las veces como si se tratara de un grafo conectado de vértices (cosas) y de arcos (relaciones). Nosotros dibujamos diagramas para visualizar un sistema desde diferentes perspectivas. En teoría, un diagrama puede contener cualquier combinación de cosas y relaciones. Sin embargo, en la práctica sólo aparece un número pequeño de combinaciones que sean consistentes con las cinco vistas comprendidas en la arquitectura de un sistema de software. La notación UML incluye nueve tipos de diagramas:

1.    Diagrama de clase

Un diagrama de clase muestra un conjunto de clases, interfaces, colaboraciones y sus relaciones. Este diagrama es el que más se encuentra en los sistemas de modelado orientado a objetos. Los diagramas de clase dirigen la visión de diseño estática de un sistema.

2.    Diagrama de objeto 

Un diagrama de objeto muestra un conjunto de objetos y sus relaciones. Este diagrama representa una fotografía estática de instancias de las cosas que se encuentran en un diagrama de clase. Los diagramas de objeto dirigen la visión de diseño estática o la visión de proceso estática  de un sistema, al igual que los diagramas de clase, pero desde la perspectiva del mundo real.

3.    Diagrama de caso de uso 

Un diagrama de caso de uso muestra un conjunto de casos de uso y actores (un tipo especial de clase) y sus relaciones. Los diagramas de casos de uso dirigen la visión de caso de uso estática de un sistema. Estos diagramas son importantes a la hora de organizar y modelar los comportamientos de un sistema.

4.    Diagrama de secuencia 
5.    Diagrama de colaboración

Estos diagramas son tipos de diagramas de interacción. Un diagrama de interacción muestra una interacción, que consiste de un conjunto de objetos y sus relaciones, incluyendo los mensajes que pueden enviarse entre ellos. Los diagramas de interacción dirigen la visión dinámica de un sistema.

Un diagrama de secuencia es un diagrama de interacción que enfatiza el orden de los mensajes en el tiempo. Un diagrama de colaboración es un diagrama de interacción que enfatiza la organización estructural de los objetos que envían y reciben mensajes. Los diagramas de secuencia y los diagramas de colaboración son isomórficos, es decir, se pueden transformar el uno en el otro.

6.    Diagrama de estado 

Un diagrama de estado muestra una máquina de estado, que consta de estados, transiciones, eventos, acciones y actividades. Los diagramas de estado dirigen la visión dinámica de un sistema. Estos diagramas son importantes a la hora de modelar el comportamiento de una interfaz, clase o colaboración, y enfatizan el comportamiento de un objeto ordenado por los eventos que se suceden, lo cual es especialmente útil en los sistemas de tiempo real.

7.    Diagrama de actividad 

Un diagrama de actividad es un tipo especial de diagrama de estado que muestra el flujo de actividad a actividad dentro de un sistema. Los diagramas de actividad dirigen la visión dinámica de un sistema. Estos diagramas son importantes a la hora de modelar la función de un sistema y enfatizan el flujo de control entre los objetos. 

8.    Diagrama de componente

Un diagrama de componente muestra las organizaciones y dependencias entre un conjunto de componentes. Los diagramas de componente dirigen la visión de implementación estática de un sistema. Estos diagramas se relacionan con los diagramas de clase en el sentido de que un componente, normalmente, engloba a una o varias clases, interfaces o colaboraciones.

9.    Diagrama de despliegue

Un diagrama de despliegue muestra la configuración de los nodos que se procesan en tiempo de ejecución y los componentes que están dentro de ellos. Los diagramas de despliegue dirigen la visión de despliegue estática de una arquitectura. Estos diagramas se relacionan con los diagramas de componente en el sentido de que un nodo encierra, normalmente, uno o más componentes. 

1.2.2.    Reglas del UML

Los bloques de construcción del UML no se pueden mostrar todos ellos juntos de una forma aleatoria. Al igual que cualquier otro lenguaje, el UML tiene una serie de reglas que especifican lo que un modelo bien formado debería contemplar. Un modelo bien formado es un modelo semánticamente consistente consigo mismo y en armonía con el resto de los modelos con los que se relaciona.

El UML posee reglas semánticas para:

•    Nombres: ¿Cómo podemos llamar a las cosas, relaciones y diagramas?
•    Ámbito: ¿Cuál es el contexto que da un significado específico a un nombre?
•    Visibilidad: ¿Cuántos de esos nombres van a ser vistos y usados por otros?
•    Integridad: ¿Cuántas cosas se relacionan unas con otras de manera apropiada y consistente?
•    Ejecución: ¿Qué significa realmente ejecutar o simular un modelo dinámico?

1.2.3.    Mecanismos comunes del UML

La construcción de los bloques del UML resulta más sencilla y más armoniosa, si se realiza de acuerdo a un patrón de características comunes.
 
En UML se aplican de forma consistente estos cuatro mecanismos comunes: 

1.    Especificaciones

Detrás de cada parte de la notación gráfica del UML hay una especificación que proporciona una declaración textual de la sintaxis y semánticas de dicho bloque de construcción. Por ejemplo, detrás de un icono de clase hay una especificación que proporciona el conjunto completo de atributos, de operaciones (incluyendo sus formatos completos) y de comportamientos que engloba dicha clase; visualmente, dicho icono de clase podría mostrar únicamente una pequeña parte de esta especificación. 

2.    Adornos

La mayoría de los elementos en el UML tienen una notación gráfica y directa que proporciona una representación visual de los aspectos más importantes del elemento. Por ejemplo, la notación de clase también expone los aspectos más importantes de una clase, principalmente su nombre, sus atributos y sus operaciones. Pero una especificación de clase puede incluir otros detalles, tales como si es abstracta o la visibilidad de sus atributos y de sus operaciones. Muchos de estos detalles se pueden añadir como adornos textuales o gráficos dentro del rectángulo básico de la clase.

3.    Divisiones comunes

A la hora de modelar sistemas orientados a objetos, el mundo aparece dividido como mínimo en un par de formas. Por ejemplo, está la división de clase y de objeto. Una clase es una abstracción, mientras que un objeto es una manifestación concreta de dicha abstracción en el UML. Podemos modelar tanto las clases como los objetos. Gráficamente, el UML distingue un objeto de una clase, ya que el objeto aparece con un formato algo diferente y además subrayado.

4. Mecanismos de extensión 

El UML proporciona un lenguaje estándar para escribir modelos de software, pero no es posible para un lenguaje cerrado expresar todos los detalles de todos los modelos en todos los dominios a lo largo de todo el tiempo. Por esta razón, el UML es un lenguaje abierto, que se puede extender de forma controlada. Los mecanismos de extensión del UML incluyen:

•    Estereotipos

Un estereotipo extiende el vocabulario del UML, permitiendo que podamos crear nuevos tipos de bloques de construcción que son derivados a partir de los ya existentes y que son específicos a nuestro problema. Se distinguen claramente ya que van encerrados entre los siguientes delimitadores: «  ».

•    Valores añadidos (tagged values) 

Un valor añadido, en el sentido de una “coletilla”, extiende las propiedades de un bloque de construcción del UML, permitiendo que podamos crear nueva información en la especificación de dicho elemento. En la práctica se utilizan muy poco. 

•    Restricciones

Una restricción extiende las semánticas de un bloque de construcción del UML, permitiendo que podamos añadir nuevas reglas o modificar las ya existentes. Se distinguen claramente ya que van encerrados entre los siguientes delimitadores: { }.

1.3.    ARQUITECTURA

La visualización, especificación, construcción y documentación de un sistema de software demanda que dicho sistema pueda ser visto desde diferentes perspectivas. Las diferentes personas implicadas en el desarrollo de una aplicación, tales como usuarios finales, analistas, desarrolladores, directores de gestión del proyecto, etc., ven el sistema de diferentes formas en diferentes momentos a lo largo de la vida del proyecto. La arquitectura de un sistema es quizá la parte más importante que puede utilizarse para gestionar los diferentes puntos de vista y controlar el desarrollo iterativo e incremental de un sistema a lo largo de su ciclo de vida.

                              Representación del modelo de arquitectura de Philippe Krutchen

Esta representación de la arquitectura está basada en el modelo de Philippe Krutchen, denominado modelo de las 4 + 1 vistas, que son:

1. La vista lógica

La vista lógica describe los aspectos estáticos y dinámicos de un sistema en términos de clases y objetos y se concentra en la abstracción, el encapsulamiento y la uniformidad. El sistema se descompone en un juego de abstracciones, surgidas del ámbito del problema. Más allá de la satisfacción de las necesidades funcionales del usuario, la vista lógica permite identificar y generalizar los elementos y los mecanismos que constituyen las diferentes partes del sistema. La vista lógica trata los siguientes elementos de modelado:
•    los objetos,
•    las clases,
•    las colaboraciones, 
•    las interacciones.

2. La vista de realización o implementación

La vista de realización se preocupa de la organización de los módulos en el entorno de desarrollo. Muestra la asignación de las clases en los módulos y la asignación de los módulos en los subsistemas. Los subsistemas se organizan en niveles jerárquicos con las interfaces bien definidas. La vista de realización trata los siguientes elementos de modelado:
•    los módulos,
•    los subprogramas,
•    las tareas, 
•    los subsistemas (paquetes estereotipados).

3. La vista de los procesos

La vista de los procesos representa la descomposición en flujos de ejecución (proceso, threads, tareas, etc.), la sincronización entre flujos y la asignación de los objetos y las clases dentro de los diferentes flujos. La vista de los procesos también se preocupa de la disponibilidad del sistema, de la fiabilidad de las aplicaciones y del rendimiento. La vista de los procesos manipula los siguientes elementos de modelado:
• las tareas, los threads, los procesos;
• las interacciones. 

4. La vista de despliegue

La vista de despliegue describe los diferentes recursos de hardware y la implantación del programa en dichos recursos. La vista de despliegue cobra toda su importancia cuando el sistema es distribuido. La vista de despliegue manipula los siguientes elementos de modelado:
•    los nodos,
•    los módulos,
•    los programas principales. 
 
5. La vista de requerimientos

La vista de los casos de uso forma el adhesivo que unifica las cuatro vistas anteriores. Los casos de uso motivan y justifican las opciones de arquitectura. Permiten identificar las interfaces críticas, fuerzan a los diseñadores a concentrarse sobre los problemas concretos, demuestran y validan las otras vistas de la arquitectura. La vista de los casos de uso se concentra en los siguientes elementos de modelado:
•    los actores,
•    los casos de uso,
•    las clases,
•    las colaboraciones.

domingo, 25 de marzo de 2018

Plan de estudio - Análisis y Diseño de Sistemas 1

FACULTAD : CIENCIAS Y TECNOLOGÍA



CARRERA : INGENIERÍA DE SISTEMAS
SEMESTRE : SEXTO
ASIGNATURA : ANÁLISIS Y DISEÑO DE SISTEMAS I
SIGLA O CÓDIGO : ADS1T6
PRE-REQUISITO : SIN1T5
CARGA HORARIA : HT = 52; HP = 36 , TOT = 88
CRÉDITOS : 6
DOCENTE : Ing. Angel Céspedes Quiroz
UNIVERSIDAD : CUMBRE

I. COMPETENCIAS

ALCANCE

Identifica los elementos, relaciones y diagramas de UML para expresar de una forma gráfica un sistema de tal manera que otros lo puedan entender. Aplica los conocimientos del Lenguaje de Modelado Unificado y la metodología del Proceso Unificado para modelar la arquitectura de un software.

a) Genérico o básica

Adquiere los conocimientos necesarios, Identifica los actores y casos de uso para elaborar el modelo de casos de uso del sistema. Reconoce los diagramas de UML que se utilizan para en el análisis de la arquitectura, casos de uso y clases.

b) Disciplinaria

Reconoce los diagramas de UML que se utilizan para en el análisis de la arquitectura, casos de uso y clases. Valora la importancia de elaborar el análisis del sistema para facilitar el trabajo en el diseño.

Al término del curso, el estudiante será capaz de:

a. Manejar correctamente los fundamentos del desarrollo de sistemas integrados de información.

b. Aplicar las metodologías y herramientas utilizadas en el análisis y diseño de sistemas.

II. PRIORIZACIÓN DE HABILIDADES INTELECTUALES DE ORDEN SUPERIOR

a. Pensamiento analítico, crítico y reflexivo.

III. CONTENIDO MÍNIMO

Introducción a UML. Modelos. Vistas UML. Vistas Estáticas. Clasificadores. Relaciones. Asociaciones. Generalización. Realización. Dependencia. Restricción. Instancias. Actores. Descripción de Casos de Uso. Diagrama de Actividades. Diagrama de Colaboración. Diagrama de Secuencia. Diagrama de Paquetes. Estereotipos. Entorno UML. Modelado con Herramientas.

IV. UNIDADES PROGRAMÁTICAS

1. FUNDAMENTOS DEL MODELO DE OBJETOS

1.1 Introducción a UML
1.2 Sintaxis de Diagramas y las expresiones
1.3 Modelos de UML
1.4 Vistas de UML

2. VISTAS ESTATICAS

2.1 Descripción
2.2 Clasificadores
2.3 Relaciones
2.4 Asociaciones
2.5 Generalización
2.6 Realización
2.7 Dependencia
2.8 Restricción
2.9 Instancias

3. VISTAS UML

3.1 Casos de uso
3.2 Actores
3.3 Descripción de Casos de uso.
3.4 Maquina de Estados
3.5 Evento
3.6 Estados
3.7 Transición
3.8 Diagrama de Actividades
3.9 Interacción
3.10 Diagrama de secuencia
3.11 Diagrama de Colaboración
3.12 Patrones
3.13 Componentes
3.14 Nodos
3.15 Diagrama de Paquetes
3.16 Modelo y Subsistema

4. Mecanismos de Extensión y Entorno UML 

4.1 Restricción
4.2 Valor etiquetado
4.3 Estereotipos
4.4 Entorno UML
4.5 Responsabilidades Semánticas
4.6 Responsabilidades del lenguaje de Programación
4.7 Modelado con herramientas


V. EVALUACIÓN A LOS ESTUDIANTES

a. Trabajos Prácticos 20 Puntos
b. Primer Parcial 20 Puntos
c. Segundo Parcial 20 Puntos
d. Examen Final 40 Puntos

TOTAL, CALIFICACIÓN 100 Puntos

VI. METODOLOGÍA

a. Clases magistrales.
b. Resolución de casos prácticos.

VII. BIBLIOGRAFÍA

§ Booch, G. ; Rumbaugh, J. y Jacobson, I.: 1999. El Lenguaje Unificado de Modelado. Addison Wesley.
§ Andreu, R., Ricart, J.E. y Valor, J.: 1996, Estrategias y sistemas de información. McGraw- Hill.

VII. HERRAMIENTAS

a. Umlet. (http://www.umlet.com/changes.htm)
b. Office. (https://www.microsoft.com/es-es/download/office.aspx)
c. Git. (https://github.com/nubeandobo)

jueves, 15 de febrero de 2018

Problema para descargar librerias desde Nuget Proxy Visual Studio XXXX


Un problema muy común cuando trabajamos en un entorno donde se tiene un servidor proxy restringiendo ciertos accesos, es que cuando queremos descargar librerías por Internet muchas veces no nos permite desde el IDE Visual Studio por lo cual nos aparece error de conexión o de proxy.

Para ello buscamos el archivo de configuración de Visual Studio llamado devenv.exe.config y reemplazamos la etiqueta <system.net=""> por el código siguiente:

 
 
 
    
  
    

En Visual Studio 2015 el archivo devenv.exe.config esta en la ubicacion:
C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE

Para las otras versiones como esta basta con ir a la ubicación del acceso directo que ejecuta el IDE de Visual Studio XXXX

Espero les sirva de ayuda.

Saludos...

miércoles, 31 de enero de 2018

Generar automáticamente procedimientos almacenados a partir de una tabla


La creación de procedimientos almacenados para un CRUD puede resultar una tarea bastante repetitiva. Aquí publico un procedimiento almacenado para SQL Server (T-SQL) que sirve para generar un script para crear 4 procedimientos almacenados a partir del nombre de una tabla.

El script creará 4 procedimientos. Todos los procedimientos que crea el script reciben como parámetros todos los campos de la tabla.

- SELECT filtrará por los campos recibidos que no sean NULL (where condicionado)

- INSERT insertará un registro con los parámetros recibidos

- UPDATE tal y como se genera no tiene sentido, simplemente borra las líneas que no quieras (del SET ó del WHERE)

- DELETE borrará registros filtrando por los campos recibidos que no sean NULL

- EXISTS devolverá registros que coincidan con el filtro creado con los campos recibidos que no sean NULL (where condicionado)
CREATE PROCEDURE [dbo].[sp_generate]  
  @tableName AS VARCHAR(100)  
AS  
  
--CAPITALIZE TABLENAME  
SET @tableName = UPPER(LEFT(@tableName,1)) + RIGHT(@tableName, LEN(@tableName) -1)  
  
--SALTO DE LÍNEA  
DECLARE @nl AS CHAR  
SET @nl = CHAR(10) + CHAR(13)   
  
--CABECERA  
DECLARE @spHeaders AS VARCHAR(1000)  
SET @spHeaders = 'SET ANSI_NULLS ON' + @nl +  
'GO' + @nl +  
'SET QUOTED_IDENTIFIER ON' + @nl +  
'GO' + @nl +  
'-- =============================================' + @nl +  
'-- Author:  TU_NOMBRE' + @nl +  
'-- Create date: ' + CONVERT(VARCHAR, GETDATE(), 3) + @nl +  
'-- ============================================='  
  
DECLARE @table AS VARCHAR(MAX)  
DECLARE @column AS VARCHAR(MAX)  
DECLARE @data_type AS VARCHAR(MAX)  
DECLARE @length AS INT  
DECLARE @precision AS INT  
DECLARE @scale AS INT  
  
--PARÁMETROS  
DECLARE @spParameters AS VARCHAR(MAX) SET @spParameters = ''  
  
--LISTA DE CAMPOS  
DECLARE @fieldList AS VARCHAR(MAX) SET @fieldList = ''  
  
--LISTA DE CAMPOS PARA EL SET DEL UPDATE  
DECLARE @fieldSetList AS VARCHAR(MAX) SET @fieldSetList = ''  
  
--LISTA DE PARÁMETROS PARA EL INSERT  
DECLARE @insertParameters AS VARCHAR(MAX) SET @insertParameters = ''  
  
--CONDICIONES  
DECLARE @spConditions AS VARCHAR(MAX) SET @spConditions = ''  
  
DECLARE c CURSOR STATIC FOR  
select table_name, column_name, data_type, character_maximum_length,numeric_precision, numeric_scale from information_schema.columns where table_name = @tableName order by ordinal_position  
OPEN c FETCH NEXT FROM c INTO @table, @column, @data_type, @length, @precision, @scale  
WHILE @@FETCH_STATUS = 0 BEGIN  
  
 SET @spParameters = @spParameters + (CASE WHEN LEN(@spParameters) >0 THEN @nl + ' ,' ELSE '  ' END) + '@' + @column + ' ' + UPPER(@data_type) + (CASE @data_type WHEN 'VARCHAR' THEN '('+CAST(@length AS VARCHAR)+')' WHEN 'DECIMAL' THEN '('+CAST(@precision AS VARCHAR)+', '+CAST(@scale AS VARCHAR)+')' ELSE '' END) + ' = NULL'  
 SET @fieldList = @fieldList + (CASE WHEN LEN(@fieldList) >0 THEN @nl + '    ,' ELSE '' END) + @column  
 SET @spConditions = @spConditions + (CASE WHEN LEN(@spConditions) >0 THEN @nl + '   AND ' ELSE '' END) + '(@' + @column + ' IS NULL OR @' + @column + '=' + @column + ')'  
 SET @fieldSetList = @fieldSetList + (CASE WHEN LEN(@fieldSetList) >0 THEN @nl + '     ,' ELSE '      ' END) + @column + ' = @' + @column  
 SET @insertParameters = @insertParameters + (CASE WHEN LEN(@insertParameters) >0 THEN @nl + '    ,' ELSE '' END) + '@' + @column  
  
 FETCH NEXT FROM c INTO @table, @column, @data_type, @length, @precision, @scale  
END  
CLOSE c DEALLOCATE c  
  
--********************************  
--*********** SELECT *************  
--********************************  
DECLARE @SELECT AS VARCHAR(MAX)  
SET @SELECT = @spHeaders + @nl  
SET @SELECT = @SELECT + 'CREATE PROCEDURE ' + @tableName + '_Select' + @nl  
SET @SELECT = @SELECT + @spParameters + @nl  
SET @SELECT = @SELECT + 'AS' + @nl + ' SET NOCOUNT OFF;' + @nl + @nl  
SET @SELECT = @SELECT + '    SELECT ' + @fieldList + @nl  
SET @SELECT = @SELECT + '    FROM ' + @table + @nl  
SET @SELECT = @SELECt + '    WHERE ' + @spConditions + @nl  
  
--********************************  
--*********** UPDATE *************  
--********************************  
DECLARE @UPDATE AS VARCHAR(MAX)  
SET @UPDATE = @spHeaders + @nl  
SET @UPDATE = @UPDATE + 'CREATE PROCEDURE ' + @tableName + '_Update' + @nl  
SET @UPDATE = @UPDATE + @spParameters + @nl  
SET @UPDATE = @UPDATE + 'AS' + @nl + ' SET NOCOUNT OFF;' + @nl + @nl  
SET @UPDATE = @UPDATE + '    UPDATE ' + @table + ' SET ' + @nl  
SET @UPDATE = @UPDATE + @fieldSetList + @nl  
SET @UPDATE = @UPDATE + '    WHERE ' + @spConditions + @nl  
  
--********************************  
--*********** DELETE *************  
--********************************  
DECLARE @DELETE AS VARCHAR(MAX)  
SET @DELETE = @spHeaders + @nl  
SET @DELETE = @DELETE + 'CREATE PROCEDURE ' + @tableName + '_Delete' + @nl  
SET @DELETE = @DELETE + @spParameters + @nl  
SET @DELETE = @DELETE + 'AS' + @nl + ' SET NOCOUNT OFF;' + @nl + @nl  
SET @DELETE = @DELETE + '    DELETE FROM ' + @table + @nl  
SET @DELETE = @DELETE + '    WHERE ' + @spConditions + @nl  
  
--********************************  
--*********** INSERT *************  
--********************************  
DECLARE @INSERT AS VARCHAR(MAX)  
SET @INSERT = @spHeaders + @nl  
SET @INSERT = @INSERT + 'CREATE PROCEDURE ' + @tableName + '_Insert' + @nl  
SET @INSERT = @INSERT + @spParameters + @nl  
SET @INSERT = @INSERT + 'AS' + @nl + ' SET NOCOUNT OFF;' + @nl + @nl  
SET @INSERT = @INSERT + '    INSERT INTO ' + @table + '(' + @nl  
SET @INSERT = @INSERT + '     ' + @fieldList + @nl  
SET @INSERT = @INSERT + ' )' + @nl + ' VALUES(' + @nl + '     ' + @insertParameters + @nl  
SET @INSERT = @INSERT + ' )' + @nl  
  
--********************************  
--*********** EXISTS *************  
--********************************  
DECLARE @EXISTS AS VARCHAR(MAX)  
SET @EXISTS = @spHeaders + @nl  
SET @EXISTS = @EXISTS + 'CREATE PROCEDURE ' + @tableName + '_Exists' + @nl  
SET @EXISTS = @EXISTS + @spParameters + @nl  
SET @EXISTS = @EXISTS + ' ,@exists BIT OUT' + @nl  
SET @EXISTS = @EXISTS + 'AS' + @nl + ' SET NOCOUNT OFF;' + @nl + @nl  
SET @EXISTS = @EXISTS + '    IF EXISTS (' + @nl + ' SELECT ' + LEFT(@fieldList,CHARINDEX(@nl,@fieldList))  
SET @EXISTS = @EXISTS + '    FROM ' + @table + @nl  
SET @EXISTS = @EXISTS + '    WHERE ' + @spConditions + @nl + ' )' + @nl  
SET @EXISTS = @EXISTS + ' SET @exists = 1' + @nl + ' ELSE SET @exists = 0'  
  
--MOSTRAR GENERADOS  
PRINT + '-- =====INSERT==================================' + @nl + @INSERT  
PRINT + '-- =====DELETE==================================' + @nl + @DELETE  
PRINT + '-- =====UPDATE==================================' + @nl + @UPDATE  
PRINT + '-- =====SELECT==================================' + @nl + @SELECT  
PRINT + '-- =====EXISTS==================================' + @nl + @EXISTS

Se usa así:
sp_generate NOMBRE_DE_TABLA 

viernes, 26 de enero de 2018

Utilizar varios repositorios remotos con Git

Cuando utilizamos git como control de versiones de nuestros proyectos, lo normal es tener un repositorio central donde subir nuestros cambios, ya sea en GitHubBitbucket, servidor propio, etc.
Hace poco me he encontrado con la necesidad de tener que mantener dos repositorios diferentes con el mismo código, por ejemplo en Bitbucket (repositorio privado) y en GitHub (repositorio público).
Para conseguirlo, lo que tenemos que hacer es simplemente añadir un remote más.
Por ejemplo, cuando asignamos el remote de Bitbucket, lo hacemos así:
git remote add bitbucket git@bitbucket.org:user/myproject.git
Para hacer push, utilizamos el siguiente comando:
git push bitbucket master
Ahora añadimos el repositorio adicional de Github. Utilizaremos también el comando git remote:
git remote add github git@github.com:user/myproject.git
git@github.com:jonseg/crud-admin-generator.git
Y de nuevo, para hacer push al repositorio de Github utilizamos el siguiente comando:
git push github master
Personalmente prefiero tener organizados los repositorios remotos separados de esta forma y hacer el push cuando yo quiera.
Hay otra forma de hacerlo que consiste en que cada vez que hagamos un push, se actualicen los cambios al mismo tiempo en los dos repositorios remotos. Para ello, en el momento de añadir el nuevo remote tenemos que indicar los parámetros set-url con la opción –add.
En el siguiente ejemplo añado el repositorio de GitHub. Como no separamos los repositorios remotos por nombre, supongamos que tenemos un único repositorio remoto llamado origin.
git remote set-url --add origin git@github.com:user/myproject.git
De esta forma, cada vez que hagamos un push, se actualizarán los cambios tanto en Bitbucket como en Github al mismo tiempo.

miércoles, 24 de enero de 2018

Calendario de feriados de Bolivia - 2018


Calendario de feriados de Bolivia - 2018



 Días con feriado nacional
 Días sin feriado nacional
 Días con feriado departamental


Días con feriado nacional

FECHADÍACONMEMORACIÓN
1 de Enero
Lunes
Año nuevo
22 de Enero
Lunes
Día de la Fundación del Estado Plurinacional de Bolivia.
12 de Febrero
Lunes
Carnaval
13 de Febrero
Martes
Carnaval
30 de Marzo
Viernes
Viernes santo
1 de Mayo
Martes
Día del trabajador
31 de Mayo
Jueves
Corpus Christi
21 de Junio
Jueves
Año nuevo Aymara
6 de Agosto
Lunes
Día de la independencia de Bolivia.
2 de Noviembre
Viernes
Día de todos los santos.
25 de Diciembre
Martes
Navidad

Días sin feriado nacional

FECHADÍACONMEMORACIÓN
24 de Enero
 Miércoles
Alasita.
19 de Marzo
 Lunes
Día del padre
23 de Marzo
Viernes
Día del mar
12 de Abril
Jueves
Día del niño
27 de Mayo
Domingo
Día de la madre
24 de Junio
Domingo
San Juan
17 de Agosto
Viernes
Día de la bandera boliviana
11 de Octubre   
Jueves
Día de la mujer boliviana.

Días con feriado departamental

FECHADÍACONMEMORACIÓN
10 de Febrero
   Sábado
Día del departamento de Oruro
15 de Abril
   Domingo
Día del departamento de Tarija
25 de Mayo 
   Viernes
Día del departamento de Chuquisaca
16 de Julio
   Lunes
Día del departamento de La Paz
14 de Septiembre
   Viernes
Día del departamento de Cochabamba
24 de Septiembre
   Lunes
Día del departamento de Pando
24 de Septiembre
   Lunes
Día del departamento de Santa Cruz
10 de Noviembre
  Sábado
Día del departamento de Potosí.
18 de Noviembre
  Domingo
Día del departamento de Beni.