Title: Metodología de diseño
Body: Evaluar y comprender la especificación
Idear una estrategia de solución, informal
Formalizar la estrategia
Validar el modelo: escenarios, etc.
¿Hay elementos complejos? ? Iterar
Diseño detallado
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
 Página anterior | Volver al principio del trabajo | Página siguiente  |