1 2008 universidad de las américas - ingeniería de software : dr. juan josé aranda aboy aci491:...

1 2008 Universidad de Las Américas - Ingeniería de Software : Dr. Juan José Aranda Aboy

ACI491:ACI491:Ingeniería de SoftwareIngeniería de Software

Unidad 4:Estrategias de desarrollo


ContenidosContenidos

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


Objetivos EspecíficosObjetivos 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.


Introducción 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.


•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,….

Causas para el estudio de Modelos


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.


Aspectos generales del Aspectos generales del análisis estructuradoaná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.


Aspectos generales del análisis Aspectos generales del análisis estructuradoestructurado

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


Análisis de Análisis de Flujos de datosFlujos 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.


Diagramas de flujos de datosDiagramas 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.



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



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


Diagrama de ContextoDiagrama de Contexto

• Nivel 0


Diagrama NivelDiagrama Nivel

• Nivel 1


Herramientas de flujos de Herramientas de flujos de datosdatos• Microsoft Visio• Poseidon for UML• Visible Analyst • ProcessAnalyst de PowerDesigner • Esquemático (Schematic)

• Miles más!!!


Diagramas de entidad-relación


Diccionario de datosDiccionario 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.


Ejemplo de parte de un diccionario


Gráficos de ProcesosGrá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


Diagrama Gráfico de ProcesoDiagrama Gráfico de Proceso

Proceso de Firma


Representación gráfica de Representación gráfica de procesosprocesos• El gráfico representa el proceso de auditoría,

desde la elección del grupo de trabajo hasta la evaluación del mismo.


Panorama lógico y Panorama lógico y consistenciaconsistencia• 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.


¿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.

El Proceso de Desarrollo de Sistemas


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

¿Que? ¿Como?

Realización Pruebas

División del Proceso


Modelos de Ingeniería del softwareExisten algunos Modelos de Ingeniería del software:

A na lis isD iseñoC od ificaciónP ruebas

D esarro llo de S oftware

P lanificaciónO rgan izaciónR eclu tam ien toD irecciónC ontro l

G estión de p royectos

F iabilidadU sabilidadF lexib ilidadM antenib ilidadR eusab ilidadE tc.

M etricasde l so ftw are

C orrección de E rroresM od ificaciones

M antenim ien to de so ftware

Ingen ie ríade l so ftw are


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.


¿Cómo se debe abordar el desarrollo de un Sistema?


La Versión Ideal …

Validación

Instalación, Explotación

Test y pruebas previas a la OPERACIÓN

OPERACIÓN Y MANTENIMIENTO

Estudio de Viabilidad

AnálisisEspecificación

Requerimientos del Software

DiseñoEspecificación de diseño

Diseño Preliminar y Detallado

CodificaciónAplicación

Codificación y Depuración

A alguien se le ha ocurrido introducir Informática

Investigación Inicial, Identificación de Necesidades, Encuesta, etc.

Requerimientos del Sistema


El Cono de Helado

Identificación de Necesidades

Especificación Esencial

Especificación Física

Diseño

Codificación

Integración

Empaquetado

Validación

Explotación

USUARIOS

CLIENTES

ANALISTA

DISEÑADORES Y CODIFICADORES


El Modelo Real

Identificación de Necesidades

Especificación Esencial

Especificación Física

Diseño

Codificación

Integración

Empaquetado

Validación

Explotación


Propuesta de Yourdon

Encuesta

Análisis

diseño Preliminar

Estudio del HW

Diseño Detallado

Codificación

Prueba de Unidad

Prueba de subsistema

Prueba de Sistema

Requerimientos del Usuario

Especificación Funcional

Necesidades de Rendimiento

Especificación del Sistema

Configuración Final

Especificación de los

Programas

Módulos Codificados

Módulos Probados

Subsistemas Probados

Sistema Probado


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.


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.


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.


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.


Fases fundamentales

El trabajo asociado a la ingeniería de Software puede dividirse en tres fases fundamentales, independientemente del área de aplicación:

1. FASE DE DEFINICIÓN

2. FASE DE DESARROLLO

3. FASE DE MANTENIMIENTO


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.


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.


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


Desarrollo … (2)

Las tareas principales serán:

• Diseño del software.

• Generación de código.

• Prueba del software.


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.


Mantenimiento … (2)

Podemos visualizar cuatro tipos de cambio:

1. Corrección.2. Adaptación (Cambio de sistema

operativo, reglas de la empresa, etc.).3. Mejora.4. Prevención (reingeniería).


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.


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


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.


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.


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.


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.


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.


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.


Objetivos principales de cada una de las fases

1. 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.


Objetivos … (2)

2. AnálisisEspecificació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ñoEstablecer 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.


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.

Objetivos … (3)


Documentación

Definición

de requerimientos

Análisis y Diseño del sistema

Implementación

Integración y Pruebas

Explotación yMantenimiento

Como se Representa:


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.


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.


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

Modelo del Prototipo


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.

Fases


Aceptado

NO Aceptado

Evaluación Cliente

Mejora de la Especificación

Construcción Prototipo

Obtención Especificación

Ciclo de

Vida Clásico

Es el siguiente:

Ciclo de vida de Prototipos Desechables


Prototipo


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.

Prototipo: Desventajas


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

Prototipo: ¿Para qué puede ser útil?


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

Modelo o ciclo de vida en espiral


• 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

Puntos Importantes


Determinar objetivos, alternativas, restricciones

Evaluar alternativas, identificar y resolver riesgos

Desarrollar, verificarPlanificar las próximas fases

REVISIÓNAcuerdo

Modelo Espiral


Ejemplo


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

Modelo o ciclo de vida en espiral: Ventajas


Dominio de aplicaciónProyectos complejos, dinámicos, innovadores, ambiciosos, llevados a cabo por equipos internos (no necesariamente de software).

Dominios de aplicación inapropiadosDominio 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.

Modelo o ciclo de vida en espiral: Dominio


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

Modelos de desarrollo Programación Exploratoria


Modelos de desarrollo Programación Exploratoria


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

Modelos de desarrollo Transformaciones Formales


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

Ingeniería Inversa y Reingeniería


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.

Modelos de desarrollo Orientación a objetos


• Describen e implementan los sistemas de información desde un punto de vista más real.

Métodos orientados a objeto


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”).

Modelos de desarrollo Orientación a objetos (2)


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

Términos más importantes en la orientación 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.

Características principales del enfoque orientado a objetos


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.

Características principales del enfoque orientado a objetos (2)


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.

Polimorfismo


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.

Herencia


• Fase Planificación y Especificación de Requerimientos

1. Definir el Plan-Borrador.2. Crear el Informe de Investigación Preliminar.3. Definir los Requerimientos.4. Registrar Términos en el Glosario. 5. Implementar un Prototipo. (opcional)6. Definir Casos de Uso (de alto nivel y

esenciales).7. Definir el Modelo Conceptual-Borrador. 8. Definir la Arquitectura del Sistema-Borrador. 9. Refinar el Plan.

Etapas del Desarrollo OO


• Fase de Construcción: Análisis

1. Definir Casos de Uso Esenciales en formato expandido.

2. Refinar los Diagramas de Casos de Uso.3. Refinar el Modelo Conceptual.4. Refinar el Glosario. 5. Definir los Diagramas de Secuencia del

Sistema.6. Definir Diagramas de Estados. (opcional)

Etapas del Desarrollo OO (2)


• Fase de Construcción: Diseño

1. Definir los Casos de Uso Reales.2. Definir Informes e Interfaz de Usuario.3. Refinar la Arquitectura del Sistema.4. Definir los Diagramas de Interacción.5. Definir el Diagrama de Clases de Diseño. 6. Definir el Esquema de Base de Datos.

• Fases de Implementación y Pruebas

Etapas del Desarrollo OO (3)


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?


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?


Fuentes de informaciónFuentes 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


Referencias en Internet• http://alarcos.inf-cr.uclm.es/per/fgarcia/isoftware/

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

1 2008 universidad de las américas - ingeniería de software : dr. juan josé aranda aboy aci491:...

Documents