ACI491: Ingenier - PowerPoint PPT Presentation

1 / 87
About This Presentation
Title:

ACI491: Ingenier

Description:

ACI491: Ingenier a de Software Unidad 4: Estrategias de desarrollo Causas para el estudio de Modelos Costos asociados al desarrollo de software excesivamente elevados. – PowerPoint PPT presentation

Number of Views:202
Avg rating:3.0/5.0
Slides: 88
Provided by: Juan72
Category:

less

Transcript and Presenter's Notes

Title: ACI491: Ingenier


1
ACI491Ingeniería de Software
  • Unidad 4
  • Estrategias de desarrollo

2
Contenidos
  • Introducción y aspectos generales del análisis
    estructurado.
  • Flujos de datos, Diagramas de flujos de datos,
    Herramientas de los flujos de datos.
  • El diccionario de datos, Gráficos de procesos,
    Panorama lógico y consistencia.
  • Introducción y aspectos generales acerca de los
    prototipos.
  • Los usuarios con respecto a los prototipos,
    Impacto en la productividad.
  • Ventajas y desventajas del desarrollo de
    prototipos.
  • Etapas del modelo, Aspectos en el diseño físico.
  • Verificación y aspectos generales sobre el
    análisis orientado a objetos.
  • Diseño de sistemas, Diseño de Objetos,
    Aplicaciones UML.

3
Objetivos Específicos
  • Identificar los diferentes modelos de análisis
    existentes.
  • Conocer y manejar las herramientas del análisis
    estructurado.
  • Conocer y manejar las herramientas del análisis
    orientado al objeto.
  • Evaluar el momento y factibilidad de la
    implementación de prototipos.
  • Conocer y manejar las herramientas orientadas al
    diseño de prototipos.

4
Introducción
  • El objetivo del análisis estructurado es
    estructurar u organizar las tareas asociadas con
    la determinación de requerimientos para obtener
    la comprensión completa y exacta de una situación
    dada.
  • Se concentra en especificar lo que se requiere
    que haga el sistema o la aplicación.
  • No se establece como cumplirán los requerimientos
    o la forma en que implantaran la aplicación. Más
    bien permite que las personas observen los
    elementos lógicos separados de los componentes
    físicos.
  • Después de esto se puede desarrollar un modelo
    físico eficiente para la situación donde será
    utilizado.  

5
Causas para el estudio de Modelos
  • Costos asociados al desarrollo de software
    excesivamente elevados.
  • El comportamiento y funcionalidad del sistema
    actual es insatisfactorio.
  • ?
  • Motivación de los ingenieros a desarrollar nuevos
    modelos de desarrollo, incluyendo prototipos,
    síntesis de software, software reutilizable,.

6
Necesidades de las organizaciones
  • Definir las actividades necesarias en el
    desarrollo de un Sistema de Información.
  • Mantener una coherencia entre todos los proyectos
    de una misma organización.
  • Introducir puntos de control para realizar
    revisiones y controles de calidad, toma de
    decisiones.
  • Investigación de paradigmas o modelos de
    desarrollo.

7
Aspectos generales del análisis estructurado
  • El análisis estructurado se concentra en
    especificar lo que se requiere que haga el
    sistema o la aplicación.
  • Permite que las personas observen los elementos
    lógicos (lo que hará el sistema) separados de los
    componentes físicos (computadora, terminales,
    sistemas de almacenamiento, etc.).
  • Después de esto se puede desarrollar un diseño
    físico eficiente para la situación donde será
    utilizado.
  • El análisis estructurado es un método para el
    análisis de sistemas manuales o automatizados,
    que conduce al desarrollo de especificaciones
    para sistemas nuevos o para efectuar
    modificaciones a los ya existentes.
  • Éste análisis permite al analista conocer un
    sistema o proceso en una forma lógica y manejable
    al mismo tiempo que proporciona la base para
    asegurar que no se omite ningún detalle
    pertinente.

8
Aspectos generales del análisis estructurado
  • Los componentes del análisis estructurado
  • Símbolos gráficos iconos y convenciones para
    identificar y describir los componentes de un
    sistema junto con las relaciones entre estos
    componentes.
  • Diccionario de datos descripciones de todos los
    datos utilizados en el sistema.
  • Descripciones de procesos y procedimientos
    declaraciones formales que emplean técnicas y
    lenguajes que permiten a los analistas describir
    actividades importantes que forman parte del
    sistema.
  • Reglas estándares para describir y documentar el
    sistema en forma correcta y completa.

9
Análisis de Flujos de datos
  • Estudia el empleo de los datos para llevar a cabo
    procesos específicos de la empresa dentro del
    ámbito de una investigación de sistemas usa los
    diagrama de flujos de datos y los diccionarios de
    datos.

10
Diagramas de flujos de datos
  • Un diagrama de flujo de datos (DFD) es un modelo
    lógico-gráfico para representar el funcionamiento
    de un sistema en un proyecto software.
  • Sus elementos gráficos son círculos, flechas, y
    rectángulos cerrados o abiertos.
  • Los cerrados representan entidades externas
    mientras que los abiertos describen almacenes o
    archivos.
  • Los círculos significan procesos y las flechas
    flujos de datos desde, o hacia, un proceso.
  • En un DFD también se utiliza la escritura. Los
    flujos, entidades externas y los almacenes se
    etiquetan con un nombre. Los procesos se
    etiquetan con un número y un verbo en infinitivo
    con objeto directo.

11
Diagramas de flujos de datos
  • Un diagrama de flujo de datos puede ser
    profundizado expandiendo algunos de sus procesos
    en subprocesos, en este caso la etiqueta tendrá
    un número adicional. No hay un límite para el
    número de procesos.
  • Los diagramas derivados de los procesos
    principales se clasifican en niveles, los cuales
    son
  • Nivel 0 Diagrama de contexto.
  • Nivel 1 Diagrama de nivel superior.
  • Nivel 2 Diagrama de detalle o expansión.

12
Diagramas de flujos de datos
  • En el diagrama de contexto solo modela, o dibuja,
    el proceso principal del problema en cuestión con
    sus respectivas entidades. Cada proceso debe
    tener al menos una entrada y una salida (de
    datos).
  • En el diagrama de nivel superior se plasman todos
    los procesos que describen al proceso principal,
    o sea, éste se descompone en varios procesos. En
    este nivel aparecen los archivos, los cuales
    tienen la capacidad de almacenar o enviar datos
    para ser usados en los distintos procesos.
  • En el diagrama detalle se generan procesos
    provenientes del nivel anterior.
  • Cabe destacar que en el nivel 1 y 2 siempre los
    procesos deben tener las entradas y las salidas
    dadas en el diagrama de contexto.

13
Diagrama de Contexto
  • Nivel 0

14
Diagrama Nivel
  • Nivel 1

15
Herramientas de flujos de datos
  • Microsoft Visio
  • Poseidon for UML
  • Visible Analyst
  • ProcessAnalyst de PowerDesigner
  • Esquemático (Schematic)
  • Miles más!!!

16
Diagramas de entidad-relación
17
Diccionario de datos
  • El diccionario de datos es un listado organizado
    de todos los datos que pertenecen a un sistema.
  • El objetivo de un diccionario de datos es dar
    precisión sobre los datos que se manejan en un
    sistema, evitando así malas interpretaciones o
    ambigüedades.
  • Define con precisión los datos de entrada,
    salida, componentes de almacenes, flujos,
    detalles de las relaciones entre almacenes, etc.
  • Los diccionarios de datos son buenos complementos
    a los diagramas de flujo de datos, los diagramas
    de entidad-relación, etc.

18
Ejemplo de parte de un diccionario
19
Gráficos de Procesos
  • La representación gráfica de procesos debe
    mostrar la relación existente entre las distintas
    partes de un proceso.
  • Ejemplos de diseñadores gráficos de Procesos
  • Microsoft Visio
  • JBoss jBPM

20
Diagrama Gráfico de Proceso
  • Proceso de Firma

21
Representación gráfica de procesos
  • El gráfico representa el proceso de auditoría,
    desde la elección del grupo de trabajo hasta la
    evaluación del mismo.

22
Panorama lógico y consistencia
  • Consiste en realizar una visión introspectiva del
    sistema que se tiene actualmente en
    funcionamiento.
  • De esta manera, es posible evaluar tanto sus
    alcances como sus limitaciones, lo que facilita
    mejorarle.

23
El Proceso de Desarrollo de Sistemas
  • Qué se debe realizar?
  • División del Producto
  • Se fracciona el producto de modo que cada
    fragmento lo puede realizar un miembro del grupo
    de desarrollo.

24
División del Proceso
  • Implica dividir el desarrollo del sistemas en
    fases o etapas, y normalmente se habla de
    especificación, diseño y construcción.

Realización
25
Modelos de Ingeniería del software
Existen algunos Modelos de Ingeniería del
software
26
Definición de Ingeniería de Software
  • Se define como la disciplina tecnológica que
    incluye
  • Desarrollo y mantenimiento sistemáticos de
    productos software que son desarrollados y
    modificados en el tiempo y con los costos
    estimados.
  • Gestión que no está dentro del dominio de la
    programación tradicional de un sistema.

27
Cómo se debe abordar el desarrollo de un Sistema?
28
La Versión Ideal
A alguien se le ha ocurrido introducir Informática
Requerimientos del Sistema
Investigación Inicial, Identificación de
Necesidades, Encuesta, etc.
Estudio de Viabilidad
Requerimientos del Software
Análisis
Especificación
Diseño Preliminar y Detallado
Diseño
Especificación de diseño
Codificación y Depuración
Codificación
Aplicación
Test y pruebas previas a la OPERACIÓN
Validación
Instalación, Explotación
OPERACIÓN Y MANTENIMIENTO
29
El Cono de Helado
USUARIOS
Identificación
Explotación
de Necesidades
Especificación
CLIENTES
Validación
Esencial
Especificación
ANALISTA
Empaquetado
Física
Diseño
Integración
DISEÑADORES Y CODIFICADORES
Codificación
30
El Modelo Real
Identificación
Explotación
de Necesidades
Especificación
Validación
Esencial
Especificación
Empaquetado
Física
Diseño
Integración
Codificación
31
Propuesta de Yourdon
32
Ciclo de vida del Software
  • Marco de referencia que contiene
  • los procesos.
  • las actividades y las tareas involucradas en el
    desarrollo.
  • la explotación y el mantenimiento de un producto
    de software.
  • Esto incluye la vida del sistema desde la
    definición de los requisitos hasta que finaliza
    su uso.

33
DEFINICIONES
CICLO DE VIDA Conjunto de etapas que se han de
llevar a cabo para crear, explotar y mantener un
Sistema Informático. METODOS Son las
normativas que marcan las directrices que se han
de seguir para llevar a cabo una tarea. Responde
a la pregunta QUÉ. TECNICAS Es un modo de
representación para la solución de un problema
concreto. Responde a la pregunta CÓMO.
34
Herramientas y metodología
  • HERRAMIENTAS Proporcionan un soporte automático
    o semi-automático para el proceso y para los
    métodos.
  • METODOLOGIA Es un conjunto coherente de métodos
    y técnicas que cubren más de una etapa del ciclo
    de vida.

35
Paradigmas o Modelos de desarrollo
  • Los paradigmas o modelos de desarrollo de
    Software son
  • estrategias de desarrollo para organizar las
    diversas etapas y actividades del ciclo de vida
    del software.
  • Describen las transiciones entre las etapas,
    especificando qué actividades desarrollar en cada
    momento.
  • Selección de un modelo o paradigma específico
    dependiendo de la naturaleza del proyecto y/o
    aplicación, los métodos, las herramientas a
    utilizar, los controles y entregas que se
    requieren.

36
Fases fundamentales
  • El trabajo asociado a la ingeniería de Software
    puede dividirse en tres fases fundamentales,
    independientemente del área de aplicación
  • FASE DE DEFINICIÓN
  • FASE DE DESARROLLO
  • FASE DE MANTENIMIENTO

37
Fase de Definición
  • Qué información ha de ser procesada
  • Qué función y rendimiento se desea
  • Qué comportamiento se espera del sistema
  • Qué interfaces van a ser establecidas
  • Qué restricciones de diseño existen
  • Qué criterios de validación se necesitan para
    esta fase definición.

38
Definición (2)
  • Dependiendo del paradigma o modelo se definen un
    conjunto específico de actividades, pero las
    tareas principales serán
  • ingeniería de sistema o de información.
  • planificación del proyecto del software.
  • análisis de los requisitos.

39
Fase de Desarrollo
  • Cómo se diseñan las estructuras de datos.
  • Cómo se implementara la función como una
    arquitectura de software.
  • Cómo se caracterizarán las interfaces.
  • Cómo se traducirá el diseño en un lenguaje de
    programación.
  • Cómo se realizarán las pruebas

40
Desarrollo (2)
  • Las tareas principales serán
  • Diseño del software.
  • Generación de código.
  • Prueba del software.

41
Fase de Mantenimiento
  • Fase centrada en el cambio que va asociado a
  • La corrección de errores.
  • Las adaptaciones requeridas a medida que
    evoluciona el entorno del software.
  • Los cambios producidos por los requerimientos
    cambiantes del software.

42
Mantenimiento (2)
  • Podemos visualizar cuatro tipos de cambio
  • Corrección.
  • Adaptación (Cambio de sistema operativo, reglas
    de la empresa, etc.).
  • Mejora.
  • Prevención (reingeniería).

43
Mantenimiento (3)
  • Actividades a realizar
  • Gestión de riesgos.
  • Revisiones técnicas formales.
  • Mediciones.
  • Garantia de calidad del software.
  • Seguimiento y gestion del proyecto de software.
  • Gestión de reutilización.

44
Fases o etapas del ciclo de vida
  • Si se desglosan las fases anteriores, encontramos
    las principales fases o etapas del ciclo de vida
    del software
  • Identificación del sistema y definición de
    requerimientos
  • Análisis
  • Diseño
  • Desarrollo e implementación
  • Integración y prueba del software
  • Documentación
  • Entrenamiento y uso
  • Mantenimiento del software

45
Principales Modelos de Desarrollo
  • Ciclo de vida en cascada o modelo tradicional
    (WaterFall).
  • Prototipo.
  • Modelo o ciclo de vida en espiral.
  • Programación Exploratoria.
  • Transformaciones formales.
  • Modelos de desarrollo orientados a objetos.

46
Ciclo de vida en cascada o modelo Tradicional
  • La finalidad de este modelo es establecer orden
    en el desarrollo de grandes productos de
    software.
  • Las diferentes etapas son procesadas de un modo
    lineal.
  • Es la base de muchos otros modelos, levemente
    mejorada y retocada a lo largo del tiempo.
  • Aún en nuestros días sigue siendo muy utilizado.

47
Desarrollo en cascada (2)
  • Enfocado a especificar lo que el sistema ha de
    hacer (definición de requerimientos) antes de la
    construcción del sistema.
  • Define los componentes que van a interaccionar.
  • Gestiona la identificación de errores.
  • Genera un conjunto de documentos para más tarde
    son utilizados y permitir un buen chequeo y
    mantenimiento del sistema.
  • Reducir los costos de desarrollo y
    mantenimiento.

48
Etapas del Ciclo de vida en cascada
  • 1. Definición de requerimientos
  • Estudio detallado de la situación actual del
    problema a tratar.
  • Definición de los requerimientos que debe
    cumplir el nuevo sistema.
  • 2. Análisis y diseño del sistema
  • Descomposición modular del sistema.
  • Descripción detallada de cada uno de los
    módulos y sus interrelaciones, todo ello para
    poder facilitar al máximo la fase de codificación.

49
Etapas del ciclo de vida en cascada (2)
  • 3. Implementación (codificación)
  • Cada módulo como resultado de la fase
    anterior es traducido a la herramienta o
    lenguaje con el cual se construirá el sistema.
  • 4. Integración y pruebas
  • Verificación del correcto funcionamiento de
    cada módulo y todo el sistema una vez ha sido
    integrado.
  • Detectar errores en la codificación,
    definiciones de
  • requerimientos y de diseño.
  • 5. Explotación y mantenimiento
  • Garantizar el mantenimiento del sistema.
  • Corrección de errores detectados en esta fase,
    adaptación del sistema a nuevos entornos.

50
Etapas
  • Cuál es la etapa que absorbe la mayoría de
    tiempo?
  • La fase de explotación y mantenimiento, y es un
    costo adicional para el cliente.

51
Objetivos principales de cada una de las fases
  • Estudio del sistema actual y viabilidad del nuevo
    sistema.
  • Identificación de usuarios relacionados.
  • Estudio de su puesto de trabajo.
  • Deficiencias actuales.
  • Sugerencias para el futuro.
  • Establecer los objetivos del nuevo sistema.
  • Determinar la viabilidad proponiendo diversas
    soluciones.
  • Planificación de desarrollo.

52
Objetivos (2)
  • 2. Análisis
  • Especificación estructurada utilizando
    diferentes técnicas de diagramas para modelar el
    sistema nuevo, realizando también el estudio de
    la situación actual.
  • 3. Diseño
  • Establecer un conjunto de módulos e interfaces
    entre ellos, desglosando la especificación
    obtenida en la fase de análisis.
  • Facilita la tarea de codificación, transformando
    los modelos lógicos a físicos.

53
Objetivos (3)
4. Implementación Obtener un producto
utilizando un lenguaje de programación y
obteniendo una integración de los módulos. 5.
Generación de pruebas de aceptación
Especificación de un conjunto de pruebas. 6.
Garantía de calidad. Obtener un producto de
calidad. 7. Descripción de los procedimientos
Toda la documentación necesaria para describir
tanto los procesos como el producto
resultante. 8. Instalación e implantación del
nuevo sistema al entorno. Instalar el
producto final.
54
Como se Representa
55
Ciclo de vida en cascada Desventajas
  • El establecimiento explícito de todos los
    requerimientos del sistema al principio del
    desarrollo.
  • Poca flexibilidad para cambios en el sistema. No
    muestra interactividad entre fases.
  • Nada hecho hasta el final. La validación de los
    requerimientos iniciales no se realiza hasta el
    final.

56
Implementación de modo ascendente
  • La implementación del sistema de un modo
    ascendente implica
  • primero las pruebas modulares
  • después la de los subsistemas
  • finalmente la del sistema completo
  • Los problemas graves suelen encontrarse en la
    interfase entre subsistemas.

57
Modelo del Prototipo
  • Utilizado principalmente en el desarrollo de
    sistemas donde existe un pobre conocimiento de
    los requerimientos o hay una rápida evolución de
    los mismos a través del tiempo.
  • Captura de requerimientos ? diseño rápido
  • El diseño rápido se centra en una representación
    de aquellos aspectos del software que serán
    visibles al usuario.
  • El prototipo es evaluado por el cliente y el
    usuario está autorizado para refinar los
    requerimientos del software a ser desarrollado.

58
Fases
  1. Análisis y especificación de los requerimientos
    del usuario.
  2. Diseño e implementación de un prototipo.
  3. Énfasis en la interfase del usuario, equipo
    pequeño para minimizar los costos de
    comunicación.
  4. Utilización de herramientas de ayuda al
    desarrollo.
  5. Ejercicio del prototipo, refinamiento iterativo
    del prototipo.
  6. Refinamiento de los requerimientos.
  7. A partir de la fase 6 se sigue con el estándar
    del ciclo de vida.

59
Ciclo de vida de Prototipos Desechables
Es el siguiente
Aceptado
Ciclo de Vida Clásico
Construcción Prototipo
Obtención Especificación
Evaluación Cliente
Mejora de la Especificación
NO Aceptado
60
Prototipo
61
Prototipo Desventajas
  • El diseño rápido indica muchas de las veces el
    utilizar fragmentos de programas ya existentes y
    herramientas que faciliten la rápida generación
    de programas, lo que puede llevar a
  • No se tiene en cuenta la calidad del software,
    ni su
  • mantenimiento.
  • Ineficiencia de los programas, utilización de
    recursos, utilización de lenguajes inadecuados.

62
Prototipo Para qué puede ser útil?
  • Cuando el cliente no sabe o no quiere revisar
    modelos abstractos de datos (DER o DFD) para la
    validación de los resultados que se van
    obteniendo.
  • No sé lo que quiero, pero lo reconoceré en
    cuanto lo vea.
  • Sistemas online, donde la importancia reside más
    en la interfaz de usuario que en los procesos.

63
Modelo o ciclo de vida en espiral
  • Se produce una cadena continua de productos, los
    cuales están disponibles para su examen y
    evaluación por parte del cliente.
  • Provee mecanismos para asegurar la calidad del
    software.
  • La reevaluación después de cada fase permite
    cambios en las percepciones de los usuarios,
    avances tecnológicos o perspectivas financieras.

64
Puntos Importantes
  • Planificación
  • Determinación de objetivos, alternativas,
    restricciones y elaboración del plan de
    desarrollo para el ciclo actual.
  • Análisis de riesgos
  • Evaluación de las alternativas, identificación
    y resolución de riesgos.
  • Se decide si se sigue o no con el proyecto.
  • Ingeniería
  • Desarrollo del producto siguiendo un modelo
    ciclo de vida o cascada, prototipo, etc...
  • Evaluación por el cliente
  • Valoración de resultados

65
Modelo Espiral
Determinar objetivos,
Evaluar alternativas,
alternativas, restricciones
identificar y resolver
riesgos
REVISIÓN
Acuerdo
Desarrollar, verificar
Planificar las próximas
fases
66
Ejemplo
67
Modelo o ciclo de vida en espiral Ventajas
  • Intenta eliminar errores en las fases tempranas.
  • Es el mismo modelo para el desarrollo y el
    mantenimiento.
  • Provee mecanismos para asegurar la calidad del
    software.
  • Trabaja bien en proyectos complejos, dinámicos e
    innovadores.
  • La reevaluación después de cada fase permite
    cambios en las percepciones de los usuarios,
    avances tecnológicos o perspectivas financieras.
  • La focalización en los objetivos y limitaciones
    ayuda a asegurar la calidad.

68
Modelo o ciclo de vida en espiral Dominio
  • Dominio de aplicación
  • Proyectos complejos, dinámicos, innovadores,
    ambiciosos, llevados a cabo por equipos internos
    (no necesariamente de software).
  • Dominios de aplicación inapropiados
  • Dominio de problemas fáciles si el domino del
    problema está bien entendido y no hay mayores
    riesgos, es difícil y consume tiempo buscar
    riesgos donde no los hay.

69
Modelos de desarrollo Programación Exploratoria
  • Basado en el desarrollo de una implementación
    inicial, exponiéndola a la opinión del usuario y
    luego refinándola a través de muchas etapas hasta
    obtener un sistema adecuado.
  • Aplicable en Sistemas en los que es difícil (o
    imposible) establecer una detallada
    especificación. (Ejemplo Inteligencia
    Artificial)
  • Forma de validación no medible, convirtiéndose
    en una apreciación subjetiva por parte del
    cliente. No puede ser utilizado en el desarrollo
    de grandes sistemas.

70
Modelos de desarrollo Programación Exploratoria
71
Modelos de desarrollo Transformaciones Formales
  • Definición formal de los requerimientos del
    sistema ir desarrollando metódicamente hasta
    llegar al sistema definitivo.
  • Se puede demostrar la validación de los
    requerimientos.
  • Ejemplos de aplicación desarrollo de nuevos
    Sistemas Operativos, dispositivos médicos,
    desarrollo de aviónica, etc.
  • La ambigüedad, lo incompleto y la inconsistencia
    se descubren y corrigen más fácilmente.

72
Ingeniería Inversa y Reingeniería
  • Consiste en analizar un programa y representarlo
    en un mayor nivel de abstracción que el código
    fuente.
  • Se debe extraer información del diseño de datos,
    de la arquitectura y del detalle del mismo, para
    poder entenderlo.
  • La Reingeniería no sólo recupera información
    sobre el diseño de un programa existente sino que
    utiliza esta información para reestructurar o
    reconstruir el programa existente, con vistas a
    adaptarlo a un cambio, a ampliarlo o a mejorar su
    calidad general.

73
Modelos de desarrollo Orientación a objetos
Primero se empezaron a utilizar los lenguajes de
programación estructurados, que permiten la
descomposición modular de los programas esto
condujo a la adopción de técnicas de diseño
estructuradas y de ahí se paso al análisis
estructurado. El paradigma orientado a objetos
ha seguido el mismo camino el uso de la
Programación Orientada a Objetos (POO) ha
modificado las técnicas de diseño para adaptarlas
a los nuevos lenguajes y ahora se están empezando
a utilizar técnicas de análisis basadas en esta
nueva forma de desarrollar software.
74
Métodos orientados a objeto
  • Describen e implementan los sistemas de
    información desde un punto de vista más real.

75
Modelos de desarrollo Orientación a objetos (2)
  • La cultura implícita en los modelos usuales de
    ciclo de vida está basada en
  • el proyecto ( y Beneficios),
  • mientras que en el desarrollo orientado a objetos
    está basada en
  • el producto (e inversión).

76
Términos más importantes en la orientación a
objetos
  • Reusabilidad Los nuevos Sistemas OO pueden ser
    creados utilizando otros sistemas OO ya
    existentes.
  • Extensibilidad Los nuevos sistemas OO son
    fácilmente ampliables, sin tener que retocar los
    módulos empleados en su construcción.

77
Características principales del enfoque orientado
a objetos
  • Las características principales del enfoque
    orientado a objetos son, en primer lugar
  • Identidad
  • Los datos se organizan en entidades discretas y
    distinguibles llamadas objetos.
  • Estos objetos pueden ser concretos o abstractos,
    pero cada objeto tiene su propia identidad.
  • Dicho de otra forma dos objetos son distintos
    incluso aún en el caso de que los valores de
    todos sus atributos coincidan.
  • Dos manzanas pueden ser totalmente idénticas
    pero no por eso pierden su identidad nos podemos
    comer una u otra.

78
Características principales del enfoque orientado
a objetos (2)
Clasificación Los objetos que tengan los mismos
atributos y comportamiento se agrupan en clases.
Todas las manzanas tienen una serie de atributos
comunes tamaño, peso, grado de maduración, y un
comportamiento común podemos coger una manzana,
moverla o comerla. Los valores de los atributos
podrán ser distintos para cada una de ellas, pero
todas comparten los mismos atributos y
comportamiento (las operaciones que se pueden
realizar sobre ellas). Una clase es una
abstracción que describe propiedades (atributos y
comportamiento) relevantes para una aplicación
determinada, ignorando el resto.
79
Polimorfismo
El polimorfismo permite que una misma operación
pueda llevarse a cabo de forma diferente en
clases diferentes. Por ejemplo, la operación
mover, es distinta para una pieza de ajedrez que
para una ficha de damas, pero ambos objetos
pueden ser movidos. Una operación es una acción
o transformación que realiza o padece un objeto.
La implementación específica de una operación
determinada en una clase determinada se denomina
método.
80
Herencia
El concepto de herencia se refiere al compartir
atributos y operaciones basada en una relación
jerárquica entre varias clases. Una clase puede
definirse de forma general y luego refinarse en
sucesivas subclases. Cada clase hereda todas las
propiedades (atributos y operaciones) de su
superclase y añade sus propiedades
particulares. La posibilidad de agrupar las
propiedades comunes de una serie de clases en una
superclase y heredar estas propiedades en cada
una de las subclases es lo que permite reducir la
repetición de código en el paradigma OO y es una
de sus principales ventajas.
81
Etapas del Desarrollo OO
  • Fase Planificación y Especificación de
    Requerimientos
  • Definir el Plan-Borrador.
  • Crear el Informe de Investigación Preliminar.
  • Definir los Requerimientos.
  • Registrar Términos en el Glosario.
  • Implementar un Prototipo. (opcional)
  • Definir Casos de Uso (de alto nivel y
    esenciales).
  • Definir el Modelo Conceptual-Borrador.
  • Definir la Arquitectura del Sistema-Borrador.
  • Refinar el Plan.

82
Etapas del Desarrollo OO (2)
  • Fase de Construcción Análisis
  • Definir Casos de Uso Esenciales en formato
    expandido.
  • Refinar los Diagramas de Casos de Uso.
  • Refinar el Modelo Conceptual.
  • Refinar el Glosario.
  • Definir los Diagramas de Secuencia del Sistema.
  • Definir Diagramas de Estados. (opcional)

83
Etapas del Desarrollo OO (3)
  • Fase de Construcción Diseño
  • Definir los Casos de Uso Reales.
  • Definir Informes e Interfaz de Usuario.
  • Refinar la Arquitectura del Sistema.
  • Definir los Diagramas de Interacción.
  • Definir el Diagrama de Clases de Diseño.
  • Definir el Esquema de Base de Datos.
  • Fases de Implementación y Pruebas

84
Ejercicios
  1. Qué es el análisis estructurado?
  2. Qué es un prototipo de sistemas?
  3. Cuál es la diferencia entre el método del ciclo
    de vida de desarrollo de sistemas y el análisis
    estructurado? Se pueden vincular estos métodos?
  4. Qué habilidades de un analista de sistemas no se
    aprenden en clases?

85
Tarea
  • Para el proyecto en el que su equipo está
    trabajando
  • Analice comparativamente las ventajas y
    desventajas del ciclo de vida clásico y el modelo
    de prototipos.
  • Utilizaría algún otro modelo? (Orientación a
    Objetos, Exploratorio, etc) Por qué?
  • Cuál sería la alternativa de la Corporación para
    el Fomento (CORFO) de Chile que sería de mayor
    factibilidad para emplear por su equipo como
    fuente de financiamiento?

86
Fuentes de información
  • Análisis, Diseño y Mantenimiento del Software
  • Ian Sommerville Ingeniería del Software, 7ma
    edición.
  • Roger S. Presmann Ingeniería del Software un
    Enfoque Práctico, 5ta edición Editorial
    McGraw-Hill, España
  • James A. Senn Análisis y Diseño de Sistemas de
    Información, Segunda Edición, Editorial
    McGraw-Hill, España, 2001.
  • Eduard Yourdon Análisis Estructurado Moderno.
    Primera Edición, Prentice Hall Hispanoamericana
    S.A México 1993.
  • Kendall y Kendall Análisis y Diseño de
    Sistemas, 3ra edición, Pearson Educación, 1997

87
Referencias en Internet
  • http//alarcos.inf-cr.uclm.es/per/fgarcia/isoftwar
    e/isoftware.htm
  • http//arantxa.ii.uam.es/jlara/docencia/is1.2006/
    index.html
  • Ingeniería de software
  • Herramientas del Análisis Estructurado
  • Análisis Estructurado de Sistemas de Información
    (casos de estudio) Índice.
  • El analista de sistemas y el paradigma
    estructurado
  • Análisis y Diseño de Sistemas de Información.
    Metodología de James A. Senn
  • Fernández Desarrollo de sistemas de información
    Una metodología basada en el modelado
  • Whitten, Bentley y Dittman Systems Analysis and
    Design Methods, 6/e
  • Enlaces Web Sistemas
Write a Comment
User Comments (0)
About PowerShow.com