Conceptos Básicos de Programación y Desarrollo de Software

Enviado por Chuletator online y clasificado en Informática y Telecomunicaciones

Escrito el en español con un tamaño de 30,37 KB

Conceptos Básicos de Programación

Un programa informático es un conjunto de instrucciones que, una vez ejecutadas, realizan una o varias tareas en un ordenador. Al conjunto general de programas se le llama software.

Las instrucciones se escriben en un lenguaje de programación y son traducidas al único idioma que comprende la máquina: unos y ceros (binario).

Obtención de Código Ejecutable

Nuestro programa, independientemente del lenguaje en que esté escrito, si se quiere ejecutar en la arquitectura que sea, necesita ser traducido para poder ser ejecutado. Aunque tengamos el código escrito, salvo que lo pasemos al lenguaje que entienda la máquina, no podrá ser ejecutado.

Tipos de Código

El código de nuestro programa es manejado mediante programas externos, comúnmente asociados al lenguaje de programación en que está escrito, antes de ser ejecutado.

Código fuente: Es un conjunto de instrucciones escritas en un lenguaje de programación determinado. Es el código en el que nosotros escribimos nuestro programa en la máquina.

Código objeto: Es el código resultante de compilar el código fuente. Si se trata de programación, el código será código máquina; si es de máquina virtual, será bytecode.

Código ejecutable: Es el resultado obtenido de enlazar nuestro código objeto con las librerías. Este código ya es un programa ejecutable, programa que se podrá iniciar en nuestro sistema.

Proceso de Compilación de un Programa

Código fuente → Compilador → Código objeto → Enlazador (archivos de biblioteca) → Programa ejecutable

Código Java

  1. Más lento a la hora de interpretar.
  2. Más cómodo (vas de línea en línea).
  3. Una vez que, al compilar, encuentra un error, se para.
  4. Solo se compila una vez.

Tradicionalmente, se han dividido los lenguajes en compilados e interpretados. Los primeros, mencionados anteriormente, necesitan ser traducidos por un programa llamado compilador, que convierte el código fuente en código objeto, y otro programa enlazador, que unirá el código objeto del programa con el código de las librerías que necesite (C, C++).

Los interpretados, en cambio, son traducidos mientras se ejecutan, sin que se genere código objeto. Ejemplo: (HTML, WML).

La diferencia entre estos dos lenguajes radica en la manera de ejecutarlos. Mientras que los compilados solo se compilan una vez y lo hacen pasando todo el programa a código máquina, se crea un archivo .exe que se podrá ejecutar cuantas veces quieras. Los interpretados, en cambio, cada vez que los queramos ejecutar, tendremos que interpretarlos línea a línea; es más lento, pero si tiene un error en la última línea, se puede ejecutar hasta la línea que produce el error.

Los lenguajes virtuales funcionan muy similar a los lenguajes compilados, salvo que estos no generan un código objeto, sino un bytecode que puede ser interpretado por cualquier arquitectura que tenga máquina virtual. Aunque su ejecución sea lenta, tiene la ventaja de poder ser multisistema.

Java está diseñado para que un programa escrito en este lenguaje sea ejecutado independientemente de la plataforma. Se coge el código fuente, se compila a un lenguaje intermedio cercano al lenguaje máquina en que se ejecuta.

Código Java (.java) → Javac → Código bytecode (.class)

Finalmente, se interpreta ese lenguaje intermedio por medio de un programa denominado máquina virtual Java.

Código Bytecode (.class) → Navegador web → JVM (Entorno)

A los programas Java se les conoce como “Compila una vez y ejecútalo donde quieras”. Podemos compilar nuestros programas a bytecode en cualquier plataforma que tenga compilador Java.

.Jar → Agrupa todos los .class y te dice cuál es el principal para ejecutarlo en otra plataforma.

La plataforma Java tiene 2 componentes:

  • La máquina virtual Java (JVM).
  • El Java API → vienen algunas predeterminadas, pero se pueden añadir más.

La JAVA API es una gran colección de componentes de software que proporcionan muchas utilidades para el programador.

Compilación Tradicional

Se le denomina compilación tradicional cuando el código ejecutable pasa tanto por un compilador como por un enlazador.

Todo este proceso se lleva a cabo mediante dos programas: el compilador y el enlazador. Mientras el compilador traduce el código fuente a código objeto, el trabajo del enlazador es mucho más completo, uniendo el código objeto con las librerías necesarias.

Fases de la Compilación

Análisis lexicográfico: Se leen de manera secuencial los caracteres de nuestro código fuente, buscando palabras reservadas, operaciones, agrupándolos todos en cadenas de caracteres que se denominan lexemas, eliminando a su vez toda la información superflua, como los comentarios.

Análisis sintáctico-semántico: Agrupa todos los componentes léxicos estudiados en el análisis anterior en forma de fases gramaticales. Con el resultado, se revisa la coherencia de las fases gramaticales, si su “significado” es correcto. Los datos son correctos, si los arrays tienen el tamaño y el tipo adecuado.

Generación de código intermedio: Se genera una representación intermedia a modo de pseudoensamblador con el objetivo de facilitar la tarea de traducir al código objeto.

Optimización de código: Revisa el código pseudoensamblador generado en el paso anterior, optimizándolo para que el código resultante sea más fácil y rápido de interpretar.

Generación de código: Genera el código objeto de nuestro programa en un código en lenguaje máquina relocalizable, con diversas posiciones de memoria sin establecer, ya que no sabemos en qué parte de la memoria volátil se va a ejecutar.

Enlazador de librerías: Se enlaza nuestro código objeto con las librerías necesarias, produciendo, en último término, nuestro código ejecutable.

Código fuente → Análisis lexicográfico → Análisis sintáctico-semántico → Generador de código intermedio → Código intermedio → Optimizador de código → Código optimizado → Generado de código → Código objeto → Enlazador → (librerías) → Código ejecutable

(Lenguaje máquina: tiene que ser 1 y 0, “binario”).

Ingeniería de Software

La ingeniería de software trata de métodos y técnicas para desarrollar y mantener software, desde que es concebido hasta que está listo para usarse.

Fases del Proceso de Desarrollo del Software

El desarrollo del software pasa por diferentes etapas, desde que se produce la necesidad de crear un software hasta que se finaliza y está listo para ser usado por el usuario. A estas etapas se les denomina ciclo de vida del software. No todos los programas llevarán las mismas etapas en el proceso de desarrollo.

Hay más de un modelo de etapas de desarrollo (cascada, evolutivo, espiral, etc.) que, de modo recurrente, suelen ser compatibles y usadas entre sí.

Modelo en cascada: Para pasar a la siguiente fase, tiene que estar la fase anterior al 100%.

(En cascada)

Análisis de requisitos → Diseño y arquitectura → Programación → Pruebas → Implementación → Mantenimiento → Documentación.

(Incremental)

Toma de requisitos o Análisis → Diseño → Implementación → Pruebas → Implantación → Mantenimiento → Documentación.

Análisis de Requisitos: ¿Qué?

  1. La información que ha de ser procesada → Información que necesito recoger.
  2. Qué función y rendimientos se desea → En qué proceso la vamos a poner.
  3. Qué interfaces van a ser establecidas.

Tipos de Análisis

  1. Funcional → Función del sistema descrita al detalle.
  2. No funcional → Determinar características del software, sistemas para llegar a hacer esas funciones → Hardware, Software, Sistema Operativo, Fiabilidad, Mantenimiento.

Técnicas para Representar Requisitos

  1. Diagrama de flujo de datos: Se representan el flujo de datos entre los distintos procesos, las entidades externas y los almacenes (dónde recoge para luego volver a dar salida a datos o información).
  2. Diagrama de flujo de control: Flujo de información de control. Controles para supervisar datos.
  3. Diagrama de transición de estados: Refleja cómo se comporta el sistema como consecuencia de sucesos externos.
  4. Diagrama de Entidad/Relación: Refleja los datos y la relación entre ellos.
  5. Diagrama de clase: Refleja las clases y la relación entre ellos. Orientado a objetos.
  6. Diccionario de datos: Descripción detallada de los datos que se utilizan en el sistema.

Diseño y Arquitectura: ¿Cómo?

Se traducen los requisitos funcionales y no funcionales en una representación de software.

Fases

  1. Diseño de datos: Cómo ha de diseñar las estructuras de datos. Están en el DFD, DER, DD.
  2. Diseño arquitectónico: Cómo ha de implementarse la función dentro de una arquitectura de software. Parte del diagrama de flujo de datos. Se representan la estructura modular del software. Propiedades e interacciones.
  3. Diseño de interfaz: Cómo han de caracterizarse las interfaces. Comunicaciones entre el software consigo mismo, con entidades externas y con personas que lo utilizan.
  4. Diseño procedimental: Cómo ha de traducirse el diseño a un lenguaje de programación (o lenguajes no procedimentales). Se hace con suficiente nivel de detalle como para que un programador lo pueda traducir a ordinogramas, diagrama de flujos, tablas de decisión…
  5. Pruebas: Cómo ha de realizarse la prueba. Prevén los modelos de pruebas que se usarán, pero no se desarrollan aquí.

Construcciones Lógicas

  • Secuencial.
  • Condicional. Puede ser selección múltiple.
  • Repetitiva. Repetir-hasta, hacer mientras.

Fases (Orientado a Objetos)

  1. Subsistema: Se diseñan los subsistemas que van a implementar las funciones principales del sistema.
  2. Clase y objetos: Se especifica el área de objetos global, y la jerarquía de las clases requeridas.
  3. Mensaje: Cómo se realiza la colaboración entre objetos.
  4. Responsabilidades: Se identifican los métodos y atributos que caracterizan cada clase.

En la fase de diseño, se crearán los diagramas de casos de uso y de secuencia para definir la funcionalidad del sistema. (Se pueden hacer las iniciales en la fase de análisis).

  • Diagrama de caso de uso: Se intenta representar los actores y su forma de actuar en el sistema.
  • De secuencia: Modelar la secuencia lógica a través del tiempo, es decir, nos muestran los mensajes entre instancias (objetos) mandadas a través del tiempo.

Ambos diagramas serán orientados a objetos.

El diseño y arquitectura (todas las fases como tal) se representa con UML (lenguaje de modelado unificado, no es un lenguaje de programación).

Programación o Codificación del Programa

Transformar un diseño mediante un lenguaje de programación en un programa puede ser la parte más obvia del trabajo. La complejidad y la duración de esta etapa están íntimamente ligadas al o a los lenguajes de programación utilizados.

El programador contará con un análisis completo del sistema que hay que codificar y con una especificación de la estructura básica que se necesitará. En un principio, solo habría que traducir el cuaderno de carga en el lenguaje deseado para culminar la etapa de codificación. Cuanto más exhaustivo haya sido el análisis y el diseño, la tarea será más sencilla.

Pruebas

En esta fase, se comprueba el funcionamiento de cada programa, y esto se hace con datos reales o ficticios. Las pruebas buscan confirmar que la codificación ha sido exitosa y el software no contiene errores, a la vez que se comprueba que el software hace lo que debe hacer (validar → comprobar que hace bien lo que el cliente ha pedido).

Consiste en comprobar que el software realice correctamente las tareas indicadas en la especificación. No es un proceso estático, y es usual realizar pruebas después de otras etapas, como la documentación. Una técnica de prueba es probar por separado cada módulo del software.

En general, hay dos grandes formas de organizar un área de pruebas. La primera es que esté compuesto por personal inexperto y que desconozca el tema de pruebas; de esta forma, se evalúa que la documentación entregada sea de calidad, y que los procesos descritos son claros, que cualquiera pueda entenderlos. El segundo enfoque es tener un área de pruebas conformada por programadores con experiencia, personas que saben, sin mayores indicaciones, en qué condiciones puede fallar una aplicación y que pueden poner atención en detalles que personal inexperto no vería.

  • Pruebas de aceptación: Cuando el cliente te da el visto bueno y está todo acabado.
  • Caja blanca: Validar la estructura interna del programa.
  • Caja negra: Validar los requisitos funcionales sin fijarse en el funcionamiento.

Verificar: Hace una tarea y funciona perfectamente.

Validar: Funciona y ver lo que te pide el cliente (está por encima).

  • Cada prueba debe definir los resultados esperados.
  • Un programador debe evitar probarlo.
  • Es necesario revisar y probarlo.
  • Las pruebas deben incluir datos de entrada válidos y esperados.
  • Centrar las pruebas en dos objetivos:
    • Comprobar si el software no hace lo que debe hacer.
    • Comprobar si el software hace lo que no debe hacer.
  • Evitar hacer pruebas que no estén documentadas ni diseñadas con cuidado.
  • No planear pruebas asumiendo que no se encontrarán errores.
  • La probabilidad de encontrar errores en una parte del software es proporcional al número de errores ya encontrados.

Documentación

Todas las etapas del desarrollo quedan documentadas.

  • Documentación del proceso: Proceso de desarrollo y mantenimiento. Indican planes, se utilizan para predecir y controlar el proceso.
  • Documentación del producto: La documentación del usuario, y describe el producto desde el punto de vista técnico, orientado al desarrollo y mantenimiento del mismo.
  • Documentación para el usuario: Debe mostrar una información completa y de calidad que ilustre, mediante los recursos más adecuados, cómo manejar la aplicación. Una buena documentación debe permitir a un usuario cualquiera comprender el propósito y el modo de uso de la aplicación sin información previa adicional.
  • Documentación técnica: Destinada a equipos de desarrollo, que explica el funcionamiento interno del programa, haciendo hincapié en explicar la codificación del programa. Se pretende que un equipo de desarrollo cualquiera pueda entender el programa y modificarlo si fuese necesario.

Implantación y Mantenimiento

Una vez que tenemos nuestro software, hay que prepararlo para su distribución. Para ello, se implementa el software en el sistema elegido o se prepara de manera automática.

Si es una versión sustitutiva de una anterior, es recomendable valorar la convivencia de ambas aplicaciones durante el proceso de adaptación.

  1. Corrección: Es muy probable que el cliente descubra defectos en el software, aunque sea de las mejores calidades.
  2. Adaptación: Con el tiempo, es probable que cambie el entorno original (ejemplo: el sistema operativo, las reglas de empresa, etc.) para el que se desarrolló el software. El mantenimiento adaptativo produce modificaciones en el software para acomodarlo a los cambios de su entorno externo.
  3. Perfectivo: Se detectan nuevas necesidades. Mantener y mejorar el software para enfrentar errores descubiertos y nuevos requisitos. Una parte del trabajo consiste en arreglar errores o bugs. La mayor parte consiste en extender el sistema.
  4. Soporte técnico o preventivo: Consiste en la modificación del producto de software sin alterar las especificaciones. Sin alterar, corregir, adaptar y mejorar con el tiempo.

El mantenimiento consiste en una ampliación; el modelo en cascada suele volverse cíclico.

Metodología de Desarrollo de Software

En ingeniería de software, es un marco de trabajo usado para estructurar, planificar y controlar el proceso de desarrollo en sistemas de información.

Para el desarrollo del software, tenemos que usar una metodología.

Se llama Metodología al conjunto de pasos, métodos, técnicas y herramientas que deben usarse.

Metodología se Define

  • Una estructura de proyecto que sirva de guía al equipo de trabajo, involucre a los usuarios en su desarrollo y en sus puntos decisivos.
  • Un conjunto de productos finales a desarrollar.
  • Un conjunto de técnicas para obtener los productos finales.
  • Las diferentes responsabilidades y funciones de los miembros del equipo de proyecto y de los usuarios.

RUP → metodología de desarrollo de software, basado en UML (lenguaje modelado unificado).

Relación del Software con los Componentes del Sistema

4 componentes de tipo hardware:

  • Dispositivos de entrada.
  • Dispositivos de salida.
  • Unidad central de proceso.
  • Memoria principal y secundaria.

Dispositivos de entrada:

Los dispositivos de entrada son aquellos que permiten introducir la información al ordenador: teclado, ratón.

Dispositivos de salida:

Los dispositivos de salida son aquellos que envían la información del interior al exterior: altavoces, monitor.

CPU:

Constituye la parte operacional más importante de todo sistema computacional. La CPU es el cerebro del ordenador.

Memoria principal y secundaria:

La memoria principal es un área de almacenamiento interno del ordenador, de acceso rápido, donde se almacenan las instrucciones y los datos que la CPU necesita para mejorar una tarea.

Hardware:

Se refiere a todos los componentes físicos que intervienen en un sistema: disco duro, impresoras.

Software:

Se refiere a las instrucciones, datos o programas con los cuales opera el ordenador. Todo lo que se puede ser almacenado electrónicamente es software.

Roles que Interactúan en el Proceso de Desarrollo del Software

En el proceso de desarrollo de un software, deberemos realizar diferentes tareas. Es por ello que el personal que interviene en el desarrollo de un software es tan diverso como las diferentes tareas que se realizan.

  • Analista de sistemas:
    • Uno de los roles más antiguos en el desarrollo. Su objetivo consiste en realizar un estudio del sistema para dirigir el proyecto en una dirección que garantice las expectativas.
    • Participa en la etapa de análisis.
  • Diseñador de software:
    • Nace como evolución del analista y realiza el diseño de la solución que hay que desarrollar.
    • Participa en la etapa de diseño.
  • Analista programador:
    • Llamado “desarrollador”, domina una visión más amplia de la programación, aporta una visión general del proyecto más detallada, diseñando una solución más amigable para la codificación.
    • Participa en las etapas de diseño y codificación.
  • Programador:
    • Se encarga de manera exclusiva de crear el resultado del estudio realizado por analistas y diseñadores. Escribe el código fuente del software.
    • Participa en la etapa de codificación.
  • Arquitecto de software:
    • Es la argamasa que cohesiona el proceso de desarrollo. Conoce e investiga los frameworks y tecnologías, revisando que todo el procedimiento se lleva a cabo de la mejor forma y con los recursos más apropiados.
    • Participa en las etapas de análisis, diseño, documentación y explotación.
    • Explotación → Mantenimiento, implantación, documentación, pruebas.

Arquitecturas de Software

Es el diseño de nivel más alto de la estructura de un sistema, enfocándose más allá de los algoritmos y estructuras de datos. Es un conjunto de decisiones que definen, a nivel de diseño, los componentes computacionales y la interacción entre ellos.

La arquitectura lógica se refiere a la estructura del sistema a desarrollar.

La arquitectura del software es la base para comenzar con un proyecto que nos asegure la calidad del mismo.

Toda arquitectura lógica debe ser implementable en una arquitectura física, asignación de cada tarea.

  1. Una interfaz de usuario: Elemento con el que interacciona el usuario de la aplicación ejecutando acciones, introduciendo u obteniendo información.
  2. Lógica: Son las que procesan la información para generar los resultados que persiguen, siendo un elemento que diferencia unas aplicaciones de otras.
  3. Gestión de datos: Se ocupa del almacenamiento y recuperación de la información.

Clientes (capa de presentación) → Servidor de negociación (capa de negocio) → Servidor de base de datos (capa de datos).

Todas estas capas pueden estar en un mismo ordenador, si bien lo más usual es que haya una multitud de ordenadores en donde reside la capa de presentación. Las capas de negocio y de datos pueden residir en el mismo ordenador. Si el tamaño de la base de datos aumenta, se puede separar en varios ordenadores.

Si, por el contrario, la complejidad está en la capa de datos de negocio, lo que obligase a la separación, esta capa de negocio podría residir en uno o más ordenadores que realizan solicitudes a una única base de datos. En sistemas muy complejos, se llega a tener una serie de ordenadores sobre los cuales se ejecuta la capa de negocio.

En una arquitectura de tres niveles, los términos “capa” y “niveles” no significan lo mismo.

Nivel → corresponde a la forma en la que las capas lógicas se encuentran distribuidas de forma física.

Las arquitecturas más universales son:

  • Monolítica: Donde el software se estructura en grupos funcionales muy acoplados, involucrando los aspectos referidos a la presentación, procesamiento y almacenamiento.
  • Cliente-Servidor: Donde el software se reparte en dos partes independientes, pero sin reparto claro de funciones. Un cliente realiza peticiones a otro programa (servidor) que le da respuestas.
  • Arquitectura de tres niveles: Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes: una capa de presentación (interfaz de usuario), otra para el cálculo (se encuentra el modelado del negocio) y otra para el almacenamiento.

El objetivo principal de la arquitectura de software consiste en proporcionar elementos que ayuden a la toma de decisiones, abstrayendo los conceptos del sistema mediante un lenguaje común. Se organizan en forma de patrones y modelos.

Los resultados obtenidos después de efectuar buenas prácticas de arquitectura de software deben proporcionar capas de abstracción y encapsulado.

Patrones de Diseño

Los patrones de diseño ofrecen excelentes soluciones a muchos de los problemas que, como desarrolladores de software, encontramos día a día.

Establecen los componentes de la arquitectura y la funcionalidad y comportamiento de cada uno.

Las directrices marcadas facilitan la tarea de diseñar un software correctamente en menos tiempo, ayudan a construir soluciones reutilizables y extensibles, y facilitan la documentación. Los patrones nos dicen cómo aplicar de manera eficaz la herencia, el polimorfismo y todas las ventajas.

Los patrones no especifican todas las características o relaciones de los componentes de nuestro software, sino que están centrados en un ámbito específico. Cada patrón determina y especifica los aspectos de uno de los cuatro ámbitos: creacionales, estructurales, de comportamiento y de interacción.

  • Patrones creacionales: Definen el modo en que se construyen los objetos, principalmente con el objetivo de encapsular la creación de los mismos, haciendo que los constructores sean privados y el modo de crear una instancia sea mediante un método estático que devuelve el objeto (modo de crear objetos).
  • Patrones estructurales: Establecen las relaciones y organizaciones entre distintos componentes de nuestro software, resolviendo de una manera elegante diversos problemas que nos encontramos al implementar soluciones sin haber evaluado previamente todas las consecuencias y posibilidades (relaciones entre distintos componentes).
  • Patrones de comportamiento: Describen las comunicaciones entre objetos y clases, estableciendo directrices sobre cómo utilizar los objetos y clases para optimizar y organizar el comportamiento, interacción y comunicación entre ellos.
  • Patrones de interacción: Tienen como objetivo definir diferentes directrices para la creación de los interfaces, en donde prima la usabilidad.

Los antipatrones son la contraparte de los patrones, es decir, que si los patrones son buenas prácticas de desarrollo de software, los antipatrones son justamente lo contrario: situaciones que no tenemos que hacer o tenemos que evitar a la hora de desarrollar un software.

Desarrollo en Tres Capas: Modelos

Nace de la necesidad de separar la lógica de la aplicación del diseño, separando a su vez los datos de la presentación al usuario.

  • Presentación:
    • Comunica a la aplicación con el usuario.
    • Solo se comunica con la capa de negocio.
  • Negocio:
    • Alberga los programas de la aplicación.
    • Se comunica con la capa de presentación y la de datos.
  • Datos:
    • Es el acceso a datos, tanto para solicitar como para persistir.
    • Se comunica con la capa de negocio.

Capa de Presentación

  • Esta capa es la que ve el usuario final en su pantalla.
  • Lo que ve el usuario final da lo mismo lo que sea; puede ser un formulario web, un formulario de Windows…
  • Esta capa es la que permite la entrada de datos hacia el programa y, a partir de allí, que empiece la gestión de datos.

Capa de Negocio

  • Esta capa se considera el corazón del software. El programa tiene que pasar gran parte del proceso de datos en esta capa.

Capa de Datos

  • Una vez que los datos han pasado la regla de negocio, llega la capa de datos, en que los datos están preparados para ser guardados en una base de datos después de su correcto tratamiento. Y, una vez guardados, se devuelve la confirmación del proceso.

Lenguaje POO → Las capas pueden ser conjuntos de clases; cada grupo podría ocupar de programas una capa en concreto y así optimizar el proceso de mejoría en los programas.

Puedes mejorar la capa de datos sin que la capa de negocio se vea afectada.

Las capas no hace falta que estén todas en el mismo ordenador. El desarrollo por capas no solo nos mejora y facilita la estructura de nuestro propio software, sino que nos aporta la posibilidad de interoperar con otros sistemas ajenos a nuestra aplicación.

Entorno de Desarrollo y Entorno de Producción

Entorno de desarrollo: Engloba los equipos, servidores y aplicaciones que dan el servicio real.

Entorno de producción: Incluye equipos, servidores y aplicaciones semejantes a los del entorno de producción.

Todos los pasos que realizamos para poner en marcha el entorno de producción se llevan a cabo previamente en el entorno de desarrollo, para probar que el funcionamiento es el correcto. Cuando queramos realizar algún cambio o mejora en el entorno, primero lo llevamos a cabo en el entorno de desarrollo. Una vez que todos los cambios han sido aplicados y se han verificado que funcionan bien y sin errores, dichos cambios se aplican en el entorno de producción.

Se recomienda que el entorno de desarrollo y el de producción sean lo más parecido posible a nivel de hardware y software.

Cuando se aplican cambios en un entorno de desarrollo y se verifica que el funcionamiento es el esperado, existen dos posibilidades: volver a repetir manualmente los mismos cambios en el entorno de producción o programar los scripts que sean necesarios para poder aplicar los cambios de manera automática.

Modelo Vista Controlador

Modelo vista / vista modelo.

Vista → Parte de la presentación.

Vista modelo → Enlace entre las dos, recibe de visita y se lo envía a modelo. Parte de la logística, parte del proceso.

Modelo → Almacenamiento.

Entradas relacionadas: