Diseño del Software (página 2)

Title: Metodología de diseño Body: Formalizar la estrategia Identificación de entidades (clases, métodos, …) Agrupar métodos en clases Identificar y asignar responsabilidades Identificar relaciones entre clases Refinar las clases Diseño detallado Definir atributos, argumentos de las operaciones, … Codificar interfaces (código Ada, C++, Java, …)

Title: Reutilización Body: Componentes Librerías, genéricos, etc. Esquemas de arquitectura (Frameworks) Módulos fijos, ya definidos Módulos específicos, a crear en cada caso Patrones de diseño Esquemas conocidos (no reinventar la rueda) E.Gamma, R.Helm, R.Johnson, J.Vlissides: Design Patterns: … – (“la banda de los cuatro”)

Title: Diseño en capas

Diseño en capas Capa de Presentación Componentes de interfaz de usuario Componentes de proceso de usuario (Gp:) UI Components (Gp:) UI Process Components (Gp:) Presentation

Capa de Negocio Interfaces de servicio Componentes de procesos de negocio Componentes de negocio (Gp:) Service Interfaces (Gp:) Business Process Components (Gp:) Business Components

Body: Capa de Negocios Componentes de Negocio Recomendaciones Usar comunicaciones basadas en mensajes cuando sea posible Idempotent – aplicación no queda incosistente si el mismo mensaje es recibido dos veces Escoger cuidadosamente los comienzos y finales de las transacciones (atómicas o long-running) para permitir re-intentos y composición. Componentes deberían poder correr en un contexto independiente del usuario – si necesariamente impersonar al usuario actual. Esto permite usarlos sin tener que transmitir o delegar la identidad. Escojer y utilizar en forma consistente los formatos de datos (XML, DataSet, etc) como parámetros o retornos. Colocar el nivel de aislamiento de las transacciones (transaction isolation level) apropiadamente. Exponer Interfaces en lugar de objetos

Capa de datos Entidades de negocio Componentes de acceso a datos Proveen método específicos para el motor de datos. Encapsulan la complejidad del modelo de datos (Gp:) Data Access Components (Gp:) Business Entities (Gp:) Data Layer

Diseño en capas Aspectos transversales Seguridad Comunicaciones Administración y operaciones

Title: Puntos clave del Diseño Body: Un diseño es un proceso creativo, aunque los métodos y líneas guía son útiles, el juicio y pericia del ingeniero de software son requeridas para diseñar el sistema de software. Las principales actividades de diseño en el proceso de software es: El diseño arquitectónico, La especificación del sistema, El diseño de la interfaz, la estructura de datos y el diseño de algoritmos. La descomposición funcional involucra considerar un sistema como un conjunto de unidades funcionales que interactúan entre sí.

Title: Puntos clave del Diseño Body: Una decisión sobre si un sistema debe ser implementado como una simple secuencia de procesos o como un número de procesos en paralelo es una decisión del diseño detallado. El diseño debe partir el sistema en unidades (componentes) lógicas que interactúan entre sí, puede ser realizado secuencialmente o en paralelo. La cualidad más importante de los atributos de diseño es el mantenimiento. Maximizar la cohesión en un componente y minimizar el acoplamiento entre componentes es deseable para tener un diseño mantenible. El uso de herencia en los sistemas OO puede mejorar la calidad de un diseño pero puede hacer del diseño más difícil de entender.

Title: Diseño de la Interfaz de usuario Body: La interfaz debe usar términos y conceptos que son familiares para una clase de usuario . La interfaz debe ser apropiadamente consistente. El usuario no debe ser sorprendido por el sistema. La interfaz debe incluir algún mecanismo que permita al usuario recuperarse de sus errores. La interfaz debe incorporar alguna forma de guía para el usuario

Title: Diseño de la ayuda de usuario Body: La interfaz de usuario debe siempre proveer alguna forma de ayuda en línea. El diseño de la ayuda es una faceta de la interfaz de usuario que cubre las siguientes áreas: La documentación provista con el sistema La ayuda en línea del sistema Los mensajes producidos por el sistema en respuesta a las acciones del usuario.

Title: Diseño de mensajes Body: Cuando se diseñan mensajes de cualquier tipo, los siguientes principios deben ser tomados en cuenta: Los mensajes debe están el contexto del usuario. Los mensajes deben tomar en cuenta el nivel de experiencia del usuario. Como los usuarios se familiarizan con el sistema se irritan con mensajes largos. Sin embargo los que no tienen experiencia encuentran dificultad entender un mensaje corto. Los mensajes deben tomar en cuenta las habilidades de los usuarios. No es lo mismo que la experiencia, por ejemplo un staff de secretarias y de programadores pueden usar el mismo sistema integrado. Diferente terminología puede ser apropiado cuando se generan mensajes. Los mensajes deben ser positivos y no negativos. Se debe usar el modo activo y no el pasivo, nunca se debe insultar o tratar de ser gracioso.

Title: Diseño de la Ayuda del sistema Body: La información de ayuda se prepara al mismo tiempo del manual de usuario del sistema. No simplemente se reduce a una pantalla con el listado del manual del papel, las razones para esto son: La gente no es tan buena leyendo pantallas como lo son leyendo texto en papel.

Title: Mantenimiento Body: El mantenimiento es un proceso iterativo: Nuevos requerimientos deben formalizarse y validar Componentes del sistema son rediseñados e implementados Todos el sistema debe ser testeado Los sucesivos cambios, originan que la estructura original se corrompa : los programas se hacen menos entendibles y por lo tanto más difíciles de cambiar.

Title: Mantenimiento Body: Lientz & Swason: encontraron la siguiente relación de los diferentes tipos de mantenimiento.

Title: Tipos de mantenimiento Body: Corrección Aunque se hayan tomado las mejores medidas y actividades de garantía de calidad, es muy probable que el cliente descubra defectos en el software. El mantenimiento correctivo cambia el software para corregir los errores Adaptación Con el paso del tiempo es probable que cambie el entorno original (Sistema Operativo, periféricos, UCP) para el que se desarrollo el software. El mantenimiento adaptativo consiste en modificar el software para acomodarlo a los cambios de su entorno externo. Perfectivo Conforme utilice el software el cliente/usuario puede descubrir funciones adicionales que podrían ser incorporadas al software. El mantenimiento perfectivo amplía el software más allá de sus requisitos funcionales originales.

Title: Fase de mantenimiento Body: El Software es como un iceberg: fuera de lo que se ve gran masa de problemas existe bajo la superficie. El cambio es algo inevitable => se deben desarrollar mecanismos para evaluar, controlar y realizar modificaciones. La fase de mantenimiento se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones requeridas por la evolución del entorno del software y a las modificaciones debidas a los cambios de los requisitos del cliente dirigidos a reforzar o ampliar el sistema. La fase de mantenimiento vuelve a aplicar los pasos de las fases de definición y de desarrollo pero en el contexto del software ya existente.

Title: Modelo del proceso de mantenimiento (Gp:) Req. Cambios (Gp:) Análisis Impacto (Gp:) Planeamiento de entrega (Gp:) Implementación del cambio (Gp:) Entrega del sistema (Gp:) Correción (Gp:) Adaptación (Gp:) Mejora

Title: Costos de Mantenimiento Body: Existe evidencia que el costo de mantenimiento es el más grande costo en el proceso de desarrollo de sistemas y son subestimados cuando el sistema es construido (análisis, diseño, implementación). Costos varían de un dominio a otro en promedio son 2 a 4 veces costo de desarrollo Por lo que resulta efectivo en pos de reducir costos invertir tiempo y esfuerzo en el diseño y codificación para reducir costos de mantenimiento.

Title: Reingeniería de Software Body: Una de las razones del alto costo de mantenimiento es porque la estructura de los sistemas ha de ser modificada: Puede no existir No es obvia para el lector Continuos mantenimientos puede haber corroído la estructura original y no es discernible.

Title: Reingeniería de Software Body: La REESTRUCTURACIÓN (parcial/completa) Vs. RESCRIBIR TODO EL PROGRAMA. Esta actividad involucra examinar partes del programa y su reescritura para MEJORAR su ESTRUCTURA. Por lo que la reingeniería es útil si los cambios son solo de una parte del sistema (y ninguna otra parte necesita ser cambiada o revalidada). Quitar código extraño. Identificar abstracciones de datos Asignar nombres significativos Simplificar condiciones Quitar goto Reformatear programa