Filosofías del enfoque de implementación
enfoque de cascada
El enfoque en cascada para implementar una aplicación requiere que un diseñador consulte con uno o más representantes de la organización del usuario final y escriba todas las especificaciones de la aplicación. Por lo general, las especificaciones vienen en un conjunto de documentos funcionales o casos de uso, escritos de tal manera que el usuario final pueda leerlos y comprenderlos fácilmente.
El usuario final firma estos documentos y luego los recopila el equipo de diseño técnico que diseña la aplicación, creando varios artefactos como diagramas de modelo de clase, diagramas de estado, diagramas de actividad y modelos de datos. El objetivo de esta fase es escribir todo con tanto detalle que un desarrollador no tenga problemas para crear el código necesario. Hay una entrega formal del diseño al equipo de desarrollo y al equipo de prueba. Después de la entrega, el equipo de desarrollo comienza a codificar y el equipo de prueba usa el diseño técnico en combinación con los casos de uso para crear casos de prueba y escenarios de prueba.
Una vez que el equipo de desarrollo termina de codificar, el código se entrega al equipo de prueba. El equipo de pruebas realiza las pruebas que ha diseñado en función de los requisitos y el diseño detallado. Cualquier problema será solucionado por el equipo de desarrollo. Una vez que se completa el proceso de prueba y corrección, la aplicación se entrega al usuario final para la prueba de aceptación. El usuario final realiza una verificación final para ver si la aplicación cumple con los requisitos iniciales. Si se aprueba, aprueba el producto terminado y el proyecto se completa. Una vez que el equipo de desarrollo termina de codificar, el código se entrega al equipo de prueba.
El equipo de pruebas realiza las pruebas que ha diseñado en función de los requisitos y el diseño detallado. Cualquier problema será solucionado por el equipo de desarrollo. Una vez que se completa el proceso de prueba y corrección, la aplicación se entrega al usuario final para la prueba de aceptación. El usuario final realiza una verificación final para ver si la aplicación cumple con los requisitos iniciales. Si se aprueba, aprueba el producto terminado y el proyecto se completa. Una vez que el equipo de desarrollo termina de codificar, el código se entrega al equipo de prueba. El equipo de pruebas realiza las pruebas que ha diseñado en función de los requisitos y el diseño detallado.
Cualquier problema será solucionado por el equipo de desarrollo. Una vez que se completa el proceso de prueba y corrección, la aplicación se entrega al usuario final para la prueba de aceptación. El usuario final realiza una verificación final para ver si la aplicación cumple con los requisitos iniciales. Si se aprueba, aprueba el producto terminado y el proyecto se completa.
El usuario final realiza una verificación final para ver si la aplicación cumple con los requisitos iniciales. Si se aprueba, aprueba el producto terminado y el proyecto se completa. El usuario final realiza una verificación final para ver si la aplicación cumple con los requisitos iniciales. Si se aprueba, aprueba el producto terminado y el proyecto se completa.
Un proyecto puede tener más o menos fases cuando se utiliza el enfoque en cascada, pero la característica clave es un comienzo y un final de cada fase muy formales, con entregables muy formales.
La ventaja del enfoque en cascada es que la responsabilidad del equipo responsable de cada fase es mayor. Está claro lo que necesitan entregar, cuándo deben entregarlo y a quién deben entregarlo. A menudo, el equipo de desarrollo no necesitará interactuar con el usuario. Esto puede ser muy útil cuando se subcontrata el desarrollo a un país diferente.
La principal desventaja del enfoque en cascada es que, en un entorno donde todo está organizado de manera muy formal, la flexibilidad para responder a los cambios disminuye. Incluso la mudanza debe organizarse. Muy pocas empresas parecen hacer esto de manera efectiva, lo que a menudo resulta en un aumento significativo de los costos generales. Para administrar los costos de un proyecto, algunas empresas incluso retrasan cualquier cambio en los requisitos hasta la entrega inicial de la aplicación, entregando efectivamente una aplicación que no satisface las necesidades del usuario final.
desarrollo ágil
Muchos proyectos de desarrollo de software de larga duración superaron el presupuesto y no entregaron el producto a tiempo. La premisa de la filosofía de desarrollo de software ágil es minimizar el riesgo mediante el desarrollo de software en cuadros de tiempo cortos, llamados iteraciones, que suelen durar de una a cuatro semanas. Cada iteración es como su propio proyecto de software en miniatura e incluye todas las tareas necesarias para liberar el incremento de la nueva funcionalidad: planificación, análisis de requisitos, diseño, codificación, pruebas y documentación. Si bien es posible que una iteración no agregue suficiente funcionalidad para garantizar el lanzamiento del producto, un proyecto de software ágil tiene como objetivo poder lanzar un nuevo software al final de cada iteración. Al final de cada iteración, el equipo vuelve a evaluar las prioridades del proyecto.
El objetivo del desarrollo ágil de software es lograr la satisfacción del cliente a través de la entrega rápida y continua de software útil; siempre con el objetivo de construir lo que el cliente necesita; dar la bienvenida, en lugar de oponerse, a los cambios tardíos en los requisitos; adaptarse regularmente a las circunstancias cambiantes; tener una estrecha y cotidiana colaboración entre emprendedores y desarrolladores, en la que la conversación cara a cara es la mejor forma de comunicación.
La principal ventaja del desarrollo ágil de software es la flexibilidad para hacer frente a los cambios, siempre con el objetivo de cumplir con las necesidades del negocio. La desventaja, por supuesto, es un aumento en la complejidad de administrar el alcance, la planificación y el presupuesto. Otro riesgo común es la atención limitada a la documentación (técnica).
Desarrollo incremental
El desarrollo de software incremental es una combinación de desarrollo ágil y en cascada. Una aplicación se diseña, implementa y prueba de forma incremental para que cada incremento pueda entregarse al usuario final. El proyecto no se completa hasta que se completa el último incremento. Su objetivo es acortar la cascada definiendo incrementos intermedios y utilizando algunas de las ventajas del desarrollo ágil. En función de los comentarios recibidos sobre un incremento anterior, se pueden realizar ajustes al entregar el siguiente incremento. El siguiente incremento puede consistir en un código nuevo, así como modificaciones al código proporcionado anteriormente.
La ventaja es que se mantienen las formalidades, pero la gestión del cambio se vuelve más fácil. El costo de probar e implementar una aplicación varias veces será mayor que hacerlo solo una vez.
Control de flujo del programa
Elegir un enfoque para el control de flujo del programa es una tarea muy arquitectónica. El objetivo es crear un modelo de su aplicación donde, una vez que comience a agregar funcionalidad y código, todo parezca tener su propio lugar. Si alguna vez ha revisado o escrito código de alta calidad, comprende este principio.
Código del organizador
El primer paso en el diseño del flujo del programa es organizar el código mediante el establecimiento de un conjunto de reglas para ayudar a crear un modelo o esquema de la aplicación. El mantenimiento, la depuración y la corrección de errores serán más fáciles porque el código se encuentra en una ubicación lógica. Una vez que haya hecho el trabajo preliminar, puede elegir un enfoque para implementar la lógica de su aplicación.
Los patrones de diseño deben desempeñar un papel importante en el diseño del control de flujo del programa. A lo largo de los años, se ha escrito mucho código y se han diseñado muchas soluciones para problemas recurrentes. Estas soluciones se presentan en patrones de diseño. La aplicación de un patrón de diseño a un problema común de diseño de software lo ayudará a crear soluciones que sean fácilmente reconocibles y que sus pares puedan implementar. Los problemas únicos aún requerirán soluciones únicas, pero puede usar patrones de diseño para guiarlo en su solución.
Crear el proyecto
capas
El primer paso es considerar las capas lógicas. Tenga en cuenta que las capas no son lo mismo que las capas, a menudo se confunden o incluso se consideran iguales.
capas contra capas
Las capas tienen que ver con la creación de límites en su código. La capa superior puede tener referencias al código de las capas inferiores, pero una capa nunca puede tener una referencia al código de una capa superior. Los niveles se refieren a la distribución física de los niveles en varios equipos. Por ejemplo, en una aplicación de tres niveles, la interfaz de usuario está diseñada para ejecutarse en una computadora de escritorio, la lógica de la aplicación está diseñada para ejecutarse en un servidor de aplicaciones y la base de datos se ejecuta en un servidor de base de datos. capa puede constar de varias capas.
Figura 8-1: Organización básica de tres niveles
Las capas se refieren a los niveles de abstracción. Las capas que se muestran en la Figura 8-1 son válidas para la mayoría de las aplicaciones. Estos niveles también se conocen como las tres capas principales y pueden tener otros nombres. Como regla general, el código en la capa de presentación puede llamar a los servicios en la capa lógica de la aplicación, pero la capa lógica de la aplicación no debe llamar al método en la capa de presentación. La capa de presentación nunca debe llamar directamente a la capa de acceso a datos, ya que esto pasaría por alto las responsabilidades implementadas por la capa lógica de la aplicación. La capa de acceso a datos nunca debe llamar a la capa lógica de la aplicación.
Las capas son solo una abstracción y probablemente la forma más fácil de implementarlas es crear carpetas en su proyecto y agregar código a la carpeta adecuada. Un enfoque más útil sería colocar cada capa en un proyecto separado, creando así ensamblajes separados. El beneficio de poner la lógica de su aplicación en un ensamblado de biblioteca es que le permitirá crear pruebas unitarias, usando Microsoft Visual Studio o NUnit, para probar la lógica. También crea flexibilidad para elegir dónde implementar cada capa.
Capas Físicas
En una aplicación empresarial, esperaría tener múltiples clientes para la misma lógica. De hecho, lo que hace que una aplicación sea una aplicación empresarial es que se implementará en tres capas: cliente, servidor de aplicaciones y servidor de bases de datos. La aplicación Microsoft Office Access creada por el departamento de ventas de su empresa, aunque es muy importante para el departamento de ventas, no es una aplicación corporativa.
Tenga en cuenta que la lógica de la aplicación y las capas de acceso a datos a menudo se implementan juntas en el servidor de aplicaciones. Parte del diseño del proyecto es elegir si acceder al servidor de aplicaciones mediante servicios Web o .NET remotos. Cualquiera que elija, agregará un código para acceder fácilmente a los servicios remotos en la capa de presentación. Si está utilizando servicios web para acceder a servicios en su servidor de aplicaciones, Visual Studio .NET hará el trabajo por usted y generará el código de proxy, proporcionando automáticamente una implementación del patrón de proxy remoto.
Adición de patrones a capas
Las tres capas básicas proporcionan una visión general de alto nivel. Agreguemos algunos patrones estructurales para crear una arquitectura empresarial robusta. El resultado se muestra en la Figura 8-2.
Concéntrese en la capa lógica de la aplicación. La figura 8-2 muestra que el acceso a la lógica de la aplicación se realiza mediante el patrón de fachada. Una fachada es un objeto que proporciona una interfaz simplificada para un cuerpo de código más grande, como una biblioteca de clases. Una fachada puede reducir las dependencias del código externo en el funcionamiento interno de una biblioteca porque la mayoría del código usa la fachada, lo que permite una mayor flexibilidad en el desarrollo del sistema. Para ello, la fachada proporcionará una interfaz de granularidad gruesa a una colección de objetos de granularidad fina.
flujo de decisión
El control de flujo de programas, también conocido como flujo de decisiones, se refiere a cómo diseña los servicios en la capa lógica de su aplicación o, como vio en el párrafo anterior, cómo diseña los métodos en su fachada.
Hay dos enfoques para organizar sus servicios:
- Acción orientada
- impulsado por el estado
Enfoque orientado a la acción
Al organizar los servicios en función de las acciones del usuario, está implementando la lógica de la aplicación al ofrecer servicios, cada uno de los cuales maneja una solicitud específica de la capa de presentación. Esto también se conoce como patrón de secuencia de comandos de transacción. Este enfoque es popular porque es simple y se ve muy natural. Ejemplos de métodos que siguen este enfoque son BookStoreService.AddNewOrder(orden de pedido) y BookStoreService.CancelOrder(int orderId).
La lógica necesaria para realizar la acción se implementa de manera muy secuencial dentro del método, lo que hace que el código sea muy legible pero también más difícil de reutilizar. El uso de patrones de diseño adicionales, como el patrón de módulo de tabla, puede ayudar a aumentar la reutilización.
Enfoque impulsado por el estado
También es posible implementar el flujo de decisiones de la aplicación de una forma mucho más orientada al estado. Los servicios ofrecidos por el servidor de aplicaciones son de naturaleza más genérica, por ejemplo, BookStoreService.SaveOrder (orden de pedido). Este método examinará el estado del pedido y decidirá si agregar un nuevo pedido o cancelar un pedido existente.
Proyectos de estructura de datos
Debe tomar varias decisiones al diseñar sus estructuras de datos. La primera opción es el mecanismo de almacenamiento de datos, la segunda es el uso previsto de los datos y la tercera son los requisitos de la versión. Hay tres formas de ver los diseños de estructuras de datos:
- Los servicios ofrecen datos; data es un reflejo de la base de datos relacional.
- Los datos deben asignarse a objetos y los servicios proporcionan acceso a los objetos.
- Los datos ofrecidos por los servicios deben estar basados en esquemas.
La elección de uno de los tres como base para su estructura de flujo de datos debe realizarse en una etapa temprana del proceso de diseño. Muchas empresas tienen una directriz empresarial que exige una de tres opciones en todos los proyectos, pero cuando sea posible, debe volver a evaluar las opciones para cada proyecto, eligiendo el enfoque óptimo para el proyecto en cuestión.
Elegir un motor de almacenamiento de datos
Al diseñar su aplicación, sin duda tendrá que diseñar algún tipo de almacén de datos. Están disponibles los siguientes almacenes y formas de almacenamiento de datos:
- Registro
- archivo app.config
- archivos xml
- archivos de texto sin formato
- Base de datos
- cola de mensajes
Cada tienda tiene sus propias características únicas y se puede adaptar a requisitos específicos.
Diseño del flujo de datos
Flujo de datos usando ADO.NET
Al implementar servicios centrados en datos en la capa lógica de la aplicación, diseñará su flujo de datos utilizando ADO.NET. La biblioteca de clases de .NET Framework proporciona una amplia interfaz de programación de aplicaciones (API) para manipular datos en código administrado. Conocida como ADO.NET, la API se puede encontrar en el espacio de nombres System.Data. La separación completa de los soportes de datos y los almacenes de datos es una característica de diseño importante de ADO.NET. Las clases como DataSet, DataTable y DataRow están diseñadas para almacenar datos, pero no conservan el conocimiento de dónde provienen los datos. Se consideran independientes de la fuente de datos. Un conjunto separado de clases, como SqlConnection, SqlDataAdapter y SqlCommand, se encargan de conectarse a una fuente de datos, recuperar datos y completar DataSet, DataTable y DataRow. Estas clases se encuentran en subespacios de nombres como System.Data.Sql, System.Data.OleDB, System.Data.Oracle, etc. Dependiendo de la fuente de datos a la que desee conectarse, puede usar clases en el espacio de nombres correcto y, según el alcance del producto que esté usando, encontrará que estas clases ofrecen más o menos funcionalidad.
Dado que el DataSet no está conectado a la fuente de datos, se puede utilizar con bastante éxito para administrar el flujo de datos en una aplicación. La figura 8-5 muestra el flujo de datos al hacer esto.
Echemos un vistazo a este proyecto e imaginemos que alguien ha iniciado sesión en su librería y ha pedido tres libros. La capa de presentación gestionaba el estado del carrito de la compra. El cliente está listo para realizar el pedido y ha proporcionado todos los datos necesarios. Elige enviar pedido. La página web transforma todos los datos en un DataSet que contiene dos DataTables, una para pedido y otra para pedido; inserta un DataRow para el pedido; e inserta tres filas de datos para las líneas de pedido. Luego, la página web muestra estos datos al usuario una vez más, vinculando los controles de datos con el conjunto de datos y preguntando ¿Está seguro? El usuario confirma la solicitud y se envía a la capa lógica de la aplicación. La capa lógica de la aplicación verifica el DataSet para ver si todos los campos obligatorios tienen un valor y realiza una verificación para ver si el usuario tiene más de 1000 US$. 00 en facturas pendientes. Si todo va bien, el DataSet se pasa a la capa de acceso a datos, que se conecta a la base de datos y genera sentencias de inserción a partir de la información del DataSet.
El uso de DataSet de esta manera es una forma rápida y eficiente de crear una aplicación y usar el poder de la biblioteca de clases de Framework y la capacidad de ASP.NET para vincular datos a varios controles, como GridView contra un DataSet. En lugar de usar objetos DataSet simples, puede usar objetos DataSet con tipo y mejorar la experiencia de codificación implementando código en la capa de presentación, así como en la capa lógica de la aplicación. La ventaja de este enfoque es también la desventaja del enfoque. Pequeños cambios en el modelo de datos no implican necesariamente que muchos métodos tengan que cambiar sus firmas. Entonces, en términos de mantenimiento, esto funciona muy bien. Si recuerda que la capa de presentación no es necesariamente una interfaz de usuario, también puede ser un servicio web. Y si modifica la definición del DataSet, quizás porque está renombrando un campo en la base de datos, entonces está modificando el contrato al que se suscribe el servicio web. Como puede imaginar, esto puede conducir a algunos problemas importantes. Este escenario funciona bien si la capa de presentación es solo una interfaz de usuario, pero para las interfaces a sistemas o componentes externos, querrá ocultar el funcionamiento interno de su aplicación y transformar los datos en algo que no sea un clon directo de su modelo de datos y querrá crear objetos de transferencia de datos (DTO).
Flujo de datos usando mapeo relacional de objetos
El flujo de datos con ADO.NET es un enfoque muy centrado en los datos para administrar el flujo de datos. Los datos y la lógica son discretos. El otro extremo del espectro está adoptando un enfoque más orientado a objetos. Aquí, las clases se crean para agrupar datos y comportamiento. El objetivo es definir clases que imiten los datos y el comportamiento que se encuentran en el dominio empresarial para el que se creó la aplicación. El resultado a menudo se denomina objeto comercial. La colección de objetos comerciales que componen la aplicación se denomina modelo de dominio. Algunos desarrolladores afirman que un modelo de dominio enriquecido es mejor para diseñar una lógica más compleja. Es difícil probar o refutar tal afirmación. Solo sepa que tiene una opción y depende de usted tomarla.
La Figura 8-6 muestra un flujo de datos similar a la Figura 8-5, excepto que ahora agregó la capa de mapeo relacional de objetos y reemplazó los objetos DataSet con diferentes portadores de datos.
Ahora haz lo mismo paso a paso que antes; imagina que alguien se conectó a tu librería y ordenó tres libros. La capa de presentación gestionaba el estado del carrito de la compra. El cliente está listo para realizar el pedido y ha proporcionado todos los datos necesarios. Elige enviar pedido. La página web convierte todos los datos en un DTO, que contiene datos para un pedido y con tres líneas de pedido, creando los objetos según sea necesario. La página web muestra estos datos al usuario una vez más, los controles de enlace de datos contra el DTO usando ObjectDataSource en ASP.NET 2.0 y pregunta ¿Está seguro? El usuario confirma la elección y el DTO se envía a la capa lógica de la aplicación. La capa de lógica de la aplicación transforma el DTO en un objeto comercial de tipo Order con una propiedad para contener tres objetos OrderLine. El método de Orden. Se llama a Validate() para validar el pedido y verificar que todos los campos obligatorios tengan un valor, y se realiza una verificación para identificar si el usuario tiene más de R$ 1,000.00 en recibos pendientes. Para ello, el pedido llamará a Order.Customer.GetOutstandingBills(). Si todo va bien, se llama al método Order.Save(). La solicitud pasará por la capa de mapeo relacional de objetos, donde la solicitud y las filas de la solicitud se asignan a un DataTable en un DataSet, y el DataSet se pasa a la capa de acceso a datos, que se conecta a la base de datos y genera declaraciones de inserción desde la información en el DataSet. Hay, por supuesto, muchas formas en las que puede ocurrir el mapeo relacional de objetos, pero no todas incluirán la transformación a un DataSet. Algunos crearán la declaración de inserción directamente, pero seguirán usando la capa de acceso a datos para ejecutar esa declaración.
Como puede ver, se producen algunas transformaciones. El uso de DTO es necesario porque un objeto comercial implementa el comportamiento y el comportamiento está sujeto a cambios. Para minimizar el impacto de estos cambios en la capa de presentación, debe transformar los datos fuera del objeto comercial y convertirlos en un objeto de transferencia de datos. En Java, el objeto de transferencia de datos suele denominarse objeto de valor.
Una gran ventaja de trabajar con objetos comerciales es que realmente ayuda a organizar su código. Si mira hacia atrás en una pieza lógica compleja, generalmente es muy legible porque hay muy poco código de plomería. La desventaja es que la mayoría de los almacenes de datos siguen siendo relacionales y la asignación de objetos comerciales a datos relacionales puede volverse bastante compleja.
servicios basados en esquemas
Acaba de ver dos opuestos cuando se trata de administrar el flujo de datos. Muchas variaciones son posibles. Una variante común es la variante en la que se usa un conjunto de datos como portador de datos básico de la interfaz de usuario para almacenar datos, pero se usan esquemas separados (DTO) para servicios web llamados desde otros sistemas. La capa de aplicación transforma los datos relacionales en un esquema predefinido. La principal ventaja de esto es que cualquier aplicación que haga referencia al servicio no depende de ningún tipo de implementación interna del componente. Esto permite una mayor flexibilidad en el control de versiones, la compatibilidad con versiones anteriores de las interfaces y la capacidad de cambiar la implementación del componente sin cambiar la interfaz del servicio.
Por supuesto, puede usar objetos comerciales en la aplicación web y omitir la transformación DTO, pero esto generalmente solo funciona bien si la lógica de la aplicación se implementa junto con la aplicación web. Recuerda que para llamar a Order.Save() necesitarás una conexión a la base de datos. Si esto es deseable depende de usted y probablemente de su director de seguridad.