Dise - PowerPoint PPT Presentation

1 / 34
About This Presentation
Title:

Dise

Description:

Dise o del SW Lic. Rosemary Torrico An lisis Entrada Conocimiento del dominio de la aplicaci n, actividades de los usuarios, mercado, etc. Actividades Identificar ... – PowerPoint PPT presentation

Number of Views:49
Avg rating:3.0/5.0
Slides: 35
Provided by: Estu180
Category:
Tags: base | datos | dise | modelo

less

Transcript and Presenter's Notes

Title: Dise


1
Diseño del SW
  • Lic. Rosemary Torrico

2
Análisis
  • Entrada
  • Conocimiento del dominio de la aplicación,
    actividades de los usuarios, mercado, etc.
  • Actividades
  • Identificar las necesidades del usuario
  • Análisis de viabilidad
  • Determinar los requisitos de la aplicación
  • Salida
  • Documento de requisitos del software

3
Diseño
  • Entrada
  • Documento de requisitos del software
  • Actividades
  • Establecer una(s) estrategia(s) de solución
  • Análisis de alternativas. Formalizar la solución
  • Descomponer y organizar la aplicación
  • Fijar descripciones de cada módulo
  • Salida
  • Documento de diseño del software

4
Diseño de Software
  • Un diseño de software es un modelo de un sistema
    del mundo real que tiene muchas entidades
    participantes y relaciones entre ellas.
  • Debe ser posible visualizarlo a diferentes
    niveles de abstracción.
  • Traduce los requisitos del software a un conjunto
    de representaciones (gráficas, tabulares, basadas
    en lenguajes) que describen la estructura de
    datos, la arquitectura, el procedimiento
    algorítmico y las características de la interfaz.

5
El diseño del SW
  • El diseño debe actuar como base para la
    implementación.
  • Es un medio de comunicación entre los diseñadores
    de subsistemas
  • Provee información para el mantenimiento, a cerca
    de la intención original.

6
El proceso de diseño involucra
  • Describir el sistema como un número de
    diferentes niveles de abstracción.
  • El diseño es descompuesto y se va refinando,
    errores y omisiones en etapas tempranas son
    descubiertos.
  • Las etapas que se muestran a continuación son
    arbitrarias pero muestran el proceso y permiten
    la administración del proceso

7
Capas del diseño
  • El diseño se enfoca sobre cuatro atributos
    distintos del programa
  • La estructura de los datos
  • La arquitectura del software
  • El detalle procedimental y
  • La caracterización de la interfaz.

8
Principios del diseño
  • El proceso de diseño no debe sugerir de "visión
    de túnel"
  • El diseño debe ser rastreable hacia el modelo de
    análisis
  • El diseño no debe "reinventar la rueda"
  • El diseño debe "minimizar la distancia
    intelectual" entre el software y el problema como
    en el mundo real.
  • El diseño debe exhibir uniformidad e integración.
  • El diseño debe estructurarse para soportar el
    cambio.
  • El diseño debe ser estructurado para acoplarse,
    aún cuando datos aberrantes, eventos o
    condiciones de operación se presenten.
  • El diseño no es codificación, codificar no es
    diseñar.
  • El diseño debe establecerse para calidad como
    será creado, no después de contruir el software.
  • El diseño debe ser revisado para minimizar
    errores conceptuales (semántica).

9
Diseño orientado a objetos
  • Descomposición y organización en partes
  • Partes clases o abstracciones
  • Organización estructura del conjunto
  • Relaciones entre clases
  • Agregación objetos que contienen otros objetos
  • Uso clases que utilizan otras clases
  • Herencia clases especializadas
  • Otras relaciones modelo de datos.
  • Ejemplo paciente padece enfermedad

10
Diagramas de clases
Clase
Atributos
Métodos
Herencia
Agregación
Uso
11
Descomposición modular
  • Módulo agrupación de elementos
  • Clases, tipos, constantes, objetos, etc.
  • Acoplamiento
  • Ligaduras o interferencias entre módulos
  • Deseable bajo acoplamiento (independencia)
  • Ejemplo No usar variables globales por su nombre
  • Cohesión
  • Relación entre los elementos de un módulo
  • Deseable alta cohesión
  • Ejemplo Módulos que sean clases o TADs

12
Metodología de diseño
  • 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

13
Metodología de diseño
  • 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, ...)

14
Reutilización
  • 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)

15
Diseño en capas
16
Diseño en capas
  • Capa de Presentación
  • Componentes de interfaz de usuario
  • Componentes de proceso de usuario

17
  • Capa de Negocio
  • Interfaces de servicio
  • Componentes de procesos de negocio
  • Componentes de negocio

18
  • 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

19
  • 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

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

21
Puntos clave del Diseño
  • 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í.

22
Puntos clave del Diseño
  • 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.

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

24
Diseño de la ayuda de usuario
  • 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.

25
Diseño de mensajes
  • 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.

26
Diseño de la Ayuda del sistema
  • 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.

27
Mantenimiento
  • 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.

28
Mantenimiento
  • Lientz Swason encontraron la siguiente
    relación de los diferentes tipos de
    mantenimiento.

29
Tipos de mantenimiento
  • 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.

30
Fase de mantenimiento
  • 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 gt 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.

31
Modelo del proceso de mantenimiento
32
Costos de Mantenimiento
  • 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.

33
Reingeniería de Software
  • 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.

34
Reingeniería de Software
  • 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
Write a Comment
User Comments (0)
About PowerShow.com