ACI491: Ingenier - PowerPoint PPT Presentation

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