UNIVERSIDAD SALESIANA DE BOLIVIAvirtual.usalesiana.edu.bo/web/contenido/dossier/22012/1869.pdf ·...

UNIVERSIDAD SALESIANA DE BOLIVIA

CARRERA DE INGENIERÍA DE SISTEMAS

DOSSIER

ANALISIS Y DISEÑO DE SISTEMAS II Sexto Semestre

Mg.Sc. Elisa Antonieta Arizaca Ramirez

I - 2012

Análisis y Diseño de Sistemas II U.S.B.

Lic. Elisa Arizaca Ramirez

2

INDICE

PRESENTACION DEL DOSSIER …..………………………………….…………………………………… Pag. 3

UNIDAD I ……………………………………………………………………………………………………… INSTRUMENTOS PARA LA IDENTIFICACIÓN DE UN PROYECTO Análisis de problemas Planteamiento del Problema General Arbol de Problemas Arbol de objetivos Análisis de costos y beneficios

Pag. 4

UNIDAD II …………………………………………………………………………………………………… PROCESO UNIFICADO DE DESARROLLO El ciclo de vida del proceso unificado. Etapas del proceso de desarrollo Características del proceso de desarrollo Racional Unified Process (RUP) El UML y el proceso de desarrollo Análisis y Diseño orientado a objetos

Pag. 10

UNIDAD III …………………………………………………………………………………………………… CAPTURA DE REQUISITOS Definición de modelos y artefactos Fase de Planeación y elaboración Definición de requerimientos Presentación general, clientes, metas, funciones y atributos Casos de Uso y Diagramas de casos de uso Formatos de casos de uso, Tipos de casos de uso Clasificación y programación de los casos de uso

Pag. 27

UNIDAD IV …………………………………………………………………………………………………… ANALISIS ORIENTADO A OBJETOS

El objeto del análisis. Modelo conceptual Obtención de conceptos Glosario Diagrama de secuencia, Identificación de operaciones del sistema Contratos

Pag. 37

UNIDAD V …………………………………………………………………………………………………… DISEÑO ORIENTADO A OBJETOS

El papel del diseño en el ciclo de vida del software. Descripción de los casos de uso reales, interfaz. Diagramas de colaboración Patrones de Diseño Diagrama de clases

Pag. 48

UNIDAD VI …………………………………………………………………………………………………… IMPLEMENTACION Y PRUEBA

Transición Diagramas de componentes Diagrama de despliegue

Pag. 59

LECTURAS COMPLEMENTARIAS …………………………………………………………………………

Pag. 65

BIBLIOGRAFÍA ………………………….…………………………………………………….………………

Pag. 78

GLOSARIO ………..……………………….……………………………………………………………………

Pag. 79



3

PRESENTACIÓN DEL DOSSIER El presente documento refleja el material educativo que se plantea para la materia de Análisis y Diseño de Sistemas II de la Carrera de Ingeniería de Sistemas, constituyéndose en un texto de apoyo que pretende guiar el avance de las unidades temáticas programadas para la asignatura en el semestre. La contribución a la formación académica de los participantes a través de actividades y experiencias cognoscitivas y reflexivas pertinentes a la asignatura, es una de las ideas que impulsan la elaboración del presente material, así como el desarrollo de actividades psicopedagógicas que estimulen y permitan al estudiante procesar, evaluar, asimilar y recrear la información proporcionada sobre la asignatura. El presente documento ha sido elaborado tomando en cuenta principalmente la competencia general y específicas propuestas para la asignatura, que consisten en: - Lograr que el estudiante conozca, analice y aplique los conceptos y metodología de Análisis y

Diseño de Sistemas Orientado a Objetos con notación estándar UML (Unified Modeling Language), sobre casos que se desarrollen durante el semestre.

- Lograr que el estudiante adquiera la habilidad de aplicar la notación orientada a objetos en el

planteamiento de casos específicos de análisis y diseño de sistemas de información. - Lograr que el estudiante adquiera la habilidad de aplicar los conceptos de Analisis y Diseño

orientado a objetos en el desarrollo de sistemas informáticos enmarcados en nuestro ámbito de instituciones y organizaciones.

- Lograr que el estudiante adquiera la habilidad de manejar las interacciones, el respeto y la

valoración de los aportes de los otros en el trabajo en grupo. El documento está organizado en unidades, las mismas que tienen un desarrollo de cada tema propuesto para el mismo: La Unidad I hace referencia a los instrumentos que se dispone para la identificación y formulación de proyectos de desarrollo de sistemas informáticos. Unidad II, muestra el método de desarrollo de sistemas detallando sus fases y actividades a realizar. Unidad III, presenta los artefactos propios para el análisis orientado a objetos en el desarrollo de sistemas. Unidad IV, a su vez, presenta los artefactos que se utilizan para el diseño orientado a objetos. Unidad V, finalmente en esta unidad se describe la implementación y prueba del sistema antes de su implantación o puesta en marcha.



4

UNIDAD I

INSTRUMENTOS PARA LA IDENTIFICACIÓN DE UN PROYECTO

Un proyecto de desarrollo de software es el proceso de gestión para la creación de un sistema de informático o software, el cual encierra un conjunto de actividades. La idea inicial para plantear un proyecto de desarrollo de software puede nacer de cualquier persona que pertenezca o no a la Institución, y en la mayoría de los casos como resultado de la identificación de problemas de procesos involucrados. Para realizar ésta identificación de problemas se necesita de toda la información posible relacionada directa o indirectamente con el sistema en estudio, lo que podrá lograrse a partir del relevamiento de información que se realice utilizando alguna de las técnicas ya conocidas como la entrevista, cuestionario, encuestas, observación, revisión de documentos, etc. Análisis de problemas El planteamiento de un proyecto de desarrollo de software debe iniciarse a partir de la identificación de problemas que deben ser organizados de acuerdo a las posibles causas y efectos de los mismos. Para dar solución a éstos problemas será necesario plantear estrategias de solución a partir de un objetivo general que guiará el desarrollo del proyecto desde su inicio hasta su conclusión. Por lo tanto, los primeros pasos de una estrategia sistémica para resolver problemas son los siguientes:

1. Definir y analizar el problema y las necesidades de la situación 2. Determinar los objetivos que pueden o deben ser alcanzados para solucionar los problemas, o las

necesidades que han sido identificados. 3. Desarrollar soluciones alternativas o planes de acción para cumplir con estos objetivos.

Existen dos instrumentos o técnicas que pueden ayudar a analizar la situación problemática de una institución antes de plantear un proyecto:

1. El árbol de problemas 2. El árbol de objetivos

El uso de éstos instrumentos aseguran el diseño de un proyecto más sólido. Árbol de Problemas Definición: Un árbol de problemas es una técnica para identificar todos los problemas vinculados con una situación dada en un formato de dependencia y/o relación entre ellos. Puntos clave para el análisis de problemas

Uno de los errores más comunes en la especificación del problema consiste en expresarlo como la negación o falta de algo, un problema no es la ausencia de su solución. En vez de ello, el problema debe plantearse de tal forma que permita encontrar diferentes posibilidades de solución, como un estado existente negativo. Ejemplo: Problemas mal formulados

• No existe un generador local de energía eléctrica. • Falta de programas de educación inicial • Falta de repuestos

Problemas correctamente formulados • Limitada provisión de energía eléctrica durante el día. • Bajo rendimiento de los niños y niñas en los primeros años de educación primaria.



5

• Equipo no funciona Los ejemplos de problemas mal formulados conducen de antemano a una única solución: Construir un generador de energía eléctrica, implementar programas de educación inicial, conseguir repuestos. En cambio, los ejemplos de problemas bien formulados permiten una amplia gama de posibilidades de solución, como la utilización de medios de generación de energía electríca alternativos, diversas estrategias para elevar el rendimiento de los niños y niñas en educación primaria y el planteamiento de soluciones para el equipo que esta fuera de funcionamiento. Tómese en cuenta que: � La importancia de un problema no está determinada por su ubicación en el Arbol de Problemas � Identificar problemas existentes (no los posibles, ficticios o futuros) � Formular el problema como un estado negativo Cómo se elabora un árbol de problemas PASO 1 Identificar los principales problemas con respecto a la situación en cuestión. PASO 2 Formular el problema central tomando en cuenta la necesidad que quiera solucionar PASO 3 Enumere todos los demás problemas que han sido identificados durante la etapa previa de relevamiento de información indicando si se trata de causa o efecto del problema central.

- Asegúrese de incluir todas las posibles perspectivas del problema PASO 4 Elaborar un esquema que muestre las relaciones de causa y efecto en forma de un Arbol de Problemas PASO 5 Revisar el esquema completo y verificar su lógica e integridad NOTA Para asegurar un diagnóstico más completo, incluya todas las perspectivas posibles del problema:

- De los altos ejecutivos - De los subordinados dentro de la institución - De los clientes – los afectados por el problema - De organismos nacionales o regionales de planificación - El punto de vista desprejuiciado de una persona de afuera o de un consultor - De otras posibles personas vinculadas

Ejemplo de una empresa de transporte:



6

Planteamiento de problema central (principal) En la redacción de un problema central se consideran dos problemas que vienen a ser sus componentes, éstos son : Variable Dependiente y Variable Independiente: La variable independiente es la causa del problema central, es lo que en realidad debemos solucionar. La variable dependiente es aquella que representa el problema, su solución depende de la solución de la variable independiente. Ejemplo: (De la empresa de transporte)

"Frecuencia alta de accidentes de omnibuses de la empresa de transporte debido a una falta de prevención"

Identificando la variable independiente : Falta de prevención (en la empresa de transporte) Y la variable dependiente : Frecuencia alta de accidentes de omnibuses de la empresa de transporte. Ejemplo: (Del Colegio Alemán)

"El sistema de Seguimiento Académico del Colegio Alemán, muestra una baja productividad debido a la lentitud y morosidad de sus procesos involucrados"

Identificando la variable independiente : Lentitud y morosidad de los procesos involucrados (con el sistema de Seguimiento Académico del Colegio Alemán) Y la variable dependiente : Baja productividad del sistema de Seguimiento Académico del Colegio Alemán. Árbol de objetivos: Un árbol de objetivos representa gráficamente los objetivos que tiene un proyecto en una serie de niveles jerárquicos. Los árboles de objetivos suponen que las conexiones de causa/efecto o de medios/fines enlazan los objetivos del proyecto. Los árboles de objetivos son importantes porque:

- Proporciona la razón que guía el desarrollo de un sistema de ejecución. - Muestra cómo se interrelacionan los objetivos de un proyecto - Demuestra cómo la consecución de sub-objetivos contribuye al logro de objetivos de orden

superior - Proporciona los insumos iniciales para otras técnicas de ejecución tales como las matrices

de marcos lógicos de ejecución, las redes de desempeño y los gráficos de segmentos/responsabilidades

Los árboles de objetivos se construyen y se usan para ayudar en la planificación de la ejecución y en el rediseño. La disponibilidad de un árbol terminado permite determinar visualmente cómo se interrelacionan los componentes de un subproyecto en los diversos niveles del proyecto. Definición: El árbol de objetivos es una técnica para identificar aquellos objetivos que deben ser logrados para resolver los problemas que se mencionan en el árbol de problemas. El árbol de objetivos despliega esa información en un formato sencillo. Como se elabora un árbol de objetivos PASO 1 Formular todas las condiciones negativas del Arbol de Problemas en forma de condiciones positivas que sean deseadas y realizables en la práctica



7

PASO 2 Examinar las relaciones "medios - fines" establecidas para garantizar la lógica e integridad del esquema PASO 3 Si fuera necesario hay que:

• Modificar las frases existentes • Añadir frases nuevas en el contexto de las relaciones "medios - fines" • Eliminar Objetivos que no sean efectivos o necesarios

Ejemplo de una empresa de transporte:

Otras herramientas Durante la etapa de determinación de la factibilidad de un proyecto de desarrollo de sistemas, específicamente para determinar la factibilidad económica, se utiliza una herramienta que permite determinar si el desarrollo de un proyecto es factible económicamente, es decir, si la inversión será recuperable. ANALISIS DE COSTOS Y BENEFICIOS El estudio de costos y beneficios consiste en realizar un estudio detallado de todos los costos que involucra el desarrollo del sistema, los costos de adquisición de nuevos equipos (hardware, software), los costos de operación y los de mantenimiento del nuevo sistema. Y por otro lado, el estudio involucra también el detalle de los beneficios que trae el nuevo sistema, éstos pueden ser de dos tipos: tangible e intangibles. Se denominan tangibles aquellos beneficios que pueden ser medidos en términos económicos (moneda) y los beneficios intangibles son aquellos que difícilmente pueden ser medidos en términos económicos, pero que aportan una mejora a la organización, por ejemplo: Mejores relaciones con los cliente, empleados más satisfechos con sus trabajos, etc. Ejemplo: La Tabla siguiente, muestra un estudio de costos de desarrollo de un sistema propuesto, que involucra la compra de un equipo de cómputo Pentium III. Los costos de desarrollo, incluidos los ya erogados en el estudio de sistemas- sobre el que se fundamenta este reporte, serán aproximadamente de Bs. 18200. Se estima que el costo total del nuevo sistema es de Bs. 26 000, incluyendo el nuevo equipo. Por otra parte se estima que el costo total para el primer año de operación, que incluye papelería, gastos de suministro y mantenimiento es de Bs. 3 000, cifra que toma en cuenta los incrementos proyectados para la instalación y la depreciación del sistema.



8

Existen varios beneficios del nuevo sistema que pueden clasificarse en dos categorías. Con el desarrollo del nuevo sistema, el departamento de personal tendrá la necesidad de contratar más personal para satisfacer las necesidades de procesamiento de control de préstamos y devoluciones de libros durante este año y los próximos. Sin embargo el nuevo sistema no disminuirá la cantidad actual de personal. Los ahorros obtenidos por no necesitar más personal se verán durante el tiempo de vida del sistema. Dado que serán instalados nuevos y mejores procedimientos junto con el nuevo sistema, se reducirán los errores y pérdidas en las ganancias. Una estimación muy conservadora indica que esta cantidad será menor de Bs. 1 200 para el primer año. En el futuro aumentaran los ahorros por este concepto. El sistema producirá beneficios que pueden clasificarse como intangibles. Aunque son importantes y notables, es difícil darles un valor en términos monetarios: se enumeran en el ejemplo, pero no se utilizaron para realizar la comparación costo/beneficio. Se anticipa que el nuevo sistema tendrá una vida de 5 años aunque aumentará el costo de su uso y mantenimiento durante los últimos años, lo cual es una expectativa normal. Al emplear los costos y beneficios esperados durante los 5 años de vida, como se muestra en el ejemplo, el sistema comenzará a pagarse por si mismo en un lapso menor de 16 meses. De aquí que el periodo de recuperación del sistema propuesto sea mucho mejor que el promedio y éste sea considerado como una inversión efectiva en costos. Si la empresa desea iniciar los trabajos de desarrollo se estima que el diseño, la programación, el entrenamiento de personal y la implantación del sistema necesitarán de cuatro meses. Para tal fin se asignaran al proyecto dos personas (uno de ellos contratado para tal fin) que trabajaran tiempo completo. COSTOS Costos de Desarrollo Software Análisis de sistemas y determinación de requerimientos ……………………………. (20 días de horas laborales)

Bs

3.000

Diseño de sistemas ( 30 días de 8 horas laborales) ………………………………….. 5.000 Desarrollo e implementación ………………………………………………………… (6 días de 8 horas laborales)

9.000

Costos indirectos generados por el personal ………………………………………… 1.200 Hardware Compra de equipo …………………………………………………………………… (Pentium IV, 1000 Mhz)

5.500

Impresora ……………………………………………………………………………. 1300 Mobiliario ……………………………………………………………………………… 700 Instalación Capacitación al personal ( 5 días de 2 horas) …………………………………………

300

TOTAL COSTOS DE DESARROLLO Bs 26.000 Costos de Operación Suministros Mantenimiento adicional de equipo Programa de mantenimiento

TOTAL COSTO DE OPERACIÓN Bs 3.000 Beneficios del sistema Beneficios Tangibles Ahorros por no necesitar más personal ……………………………………………….. Ahorros de operación

Bs

7.200



9

Eliminación de errores (mínimo) …………………………………………………… Beneficios Intangibles Mayor información para planificación Mejores relaciones con los clientes Empleados satisfechos con su trabajo Necesidad de crecer

Bs 1.200

TOTAL BENEFICIOS (primer año)……….………………………………………… Bs 8.400 Considerando que el nuevo sistema tendrá una vida de 5 años, durante ese tiempo el costo de uso y mantenimiento del nuevo sistema tendrá un incremento paulatino, lo que se constituye en una expectativa normal, se realizan los siguientes cálculos tomando en cuenta los costos y beneficios esperados durante los 5 años de vida, como se muestra en el ejemplo. TIEMPO DE VIDA (cinco años)

Año Costos del sistema Bs

Beneficios del sistema Bs

1 29.000 8.400 2 3.150,0 8.820,0 3 3.307,5 9.261,0 4 3.472,9 9.724,1 5 3.646,5 10.210,3

Los datos de la tabla, nos permiten obtener la siguiente gráfica que muestra que la inversión realizada en la implementación e instalación del nuevo sistema podrá ser recuperada.

0,0

5.000,0

10.000,0

15.000,0

20.000,0

25.000,0

30.000,0

35.000,0

1 2 3 4 5

Tiempo

Mon

to Costos

Beneficios

Interpretación. La grafica demuestra que la recuperación de la inversión se realizará

aproximadamente a partir de los 16 meses de implantado el nuevo sistema.



10

UNIDAD II

PROCESO UNIFICADO DE DESARROLLO El desarrollo de software es un proceso riesgoso. Un estudio reveló que 31% de los proyectos no se concluyen, que 53% de ellos rebasa casi en 200% el costo estimado. Se requiere tiempo y dinero para seguir un proceso de desarrollo y realizar el análisis y el diseño orientados a objetos a fin de lograr el resultado esperado. Algunas de las razones por las cuales se debe realizar un análisis y un diseño antes de la programación son:

1. Como indican las estadísticas anteriores, los proyectos de software son una actividad riesgosa; de ahí que el motivo primordial sea aminorar el riesgo, aumentando la probabilidad de crear un sistema eficiente. Y una estrategia para conseguirlo consiste en examinar rigurosamente los requerimientos y elaborar un diseño formal.

2. Conviene crear un proceso que puedan utilizar los individuos, y sobre todo los equipos. No es sustentable el desarrollo que se funda en heroicos esfuerzos individuales.

3. Es más barato y fácil efectuar cambios durante las actividades de análisis y diseño que en la fase de construcción.

4. Podemos atenuar y manejar la abrumadora complejidad con sólo modelar los sistemas y hacer abstracciones para detectar los detalles esenciales; así se evita una excesiva complejidad.

5. Conviene crear sistemas robustos, susceptibles de mantenimiento y capaces de soportar una mayor reutilización del software. Por lo regular estas metas no se cumplen sin un riguroso examen y diseño efectuados antes de la programación.

A todas las razones anteriores, le da soporte, una aplicación metódica del análisis y del diseño. En un proyecto de desarrollo de software la metodología define Quién debe hacer Qué, Cuándo y Cómo debe hacerlo. No existe una metodología de software universal. Las características de cada proyecto (equipo de desarrollo, recursos, etc.) exigen que el proceso sea configurable. PROCESO DE DESARROLLO Es un método de organizar las actividades relacionadas con la creación, presentación y mantenimiento de los sistemas de software. El proceso de desarrollo de software, que a su vez incluye actividades, no representa un método nuevo estándar para sistemas orientados a objetos, es un proceso de desarrollo recomendado para el desarrollo de sistemas orientados a objetos. Este proceso incluye las siguientes etapas de macronivel: Planeación y elaboración: planear, definir los requerimientos, construir prototipos, etc. Construcción: la creación del sistema Aplicación: la transición de la implementación del sistema a su uso. Cada una de estas etapas, incluyen un conjunto de actividades, las mismas que se detallan a continuación

Planeación y elaboración

Construcción Aplicación



11

ETAPA DE PLANEACIÓN Y ELABORACIÓN Las actividades de esta etapa incluye: Plan: programa, recursos, presupuesto, etc. Informe preliminar de investigación: motivos, alternativas, necesidades de la empresa Especificación de requerimientos: declaración de los requerimientos Glosario: Diccionario (nombres de conceptos, por ejemplo) y toda información afín, como las restricciones y las reglas. Prototipo: sistema de prototipos cuyo fin es facilitar la comprensión del problema, los problemas de lato riesgo y los requerimientos. Casos de uso: Descripciones narrativas de los procesos de dominio. Diagramas de casos de uso: Descripción gráfica de todos los casos y de sus relaciones. Bosquejo del modelo conceptual: modelo conceptual preliminar cuya finalidad es facilitar el conocimiento del vocabulario del dominio, especialmente en su relación con los casos de uso y con las especificaciones de los requerimientos. ETAPA DE CONSTRUCCIÓN: CICLOS DE DESARROLLO

La etapa de construcción de un proyecto requiere de varios ciclos de desarrollo a lo largo delos cuales se extiende el sistema. El objetivo final es obtener un sistema funcional de software que atienda debidamente los requerimientos. A su vez cada ciclo de desarrollo, incluye un conjunto de actividades:



3. Definir los requerimientos

5. Implementar el prototipo 6. Definir los casos de uso (alto nivel y esenciales)

1. Definir el plan preliminar 2. Elaborar el informe preliminar de investigación

4. Preparar los términos en el glosario

8. Definir la arquitectura preliminar del sistema

9. Perfeccionar el plan 7. Definir el modelo conceptual preliminar



Ciclo de desarrollo 1


. . . Ciclo de desarrollo N



12

El análisis en un ciclo de desarrollo se centra en una investigación del problema y en el análisis de los requerimientos. El diseño en ciclo de desarrollo busca ante todo definir una solución lógica.

La construcción en un ciclo de desarrollo requiere implementar el diseño en software y hardware.

La prueba en un ciclo de desarrollo se incluye como un paso final, se recomienda como una actividad






Análisis Construcción Prueba Perfeccionar el plan

Sincronización de artefactos

Diseño



Diseño

3. Perfeccionar el modelo conceptual

5. Definir los contratos de operaciones

6. Definir los diagramas de estado

1. Definir los casos esenciales de uso

2. Perfeccionar los diagramas de casos de uso

4. Definir los diagramas de secuencia de los sistemas

4. Perfeccionar el glosario



Diseño

3. Perfeccionar la

arquitectura del sistema

5. Definir los diagramas de diseño de clase

6. Definir el esquema de la base de datos

1. Definir los casos reales de uso

2. Definir los reportes, la interfaz del usuario y la

secuencia de las pantallas

4. Definir los diagramas de interacción



Diseño

3. Implementar ventanas

5. Implementar esquema de base de datos (SQL, etc)

6. Escribir código de prueba

1. Implementar las definiciones de clase y de

interfaz

2. Implementar los métodos

4. Implementar reportes



13

constante en los ciclos de desarrollo. No todas las pruebas mencionadas son adecuadas en los ciclos de desarrollo. Por ejemplo: las pruebas de integración del sistema entero pueden efectuarse con menor frecuencia en cada uno. DURACIÓN DE LOS CICLOS DE DESARROLLO Con una duración menor de la necesaria será difícil realizar un conjunto significativo de requerimientos y actividades; con una duración se correrá el riesgo de una excesiva complejidad y de insuficiente retroalimentación inicial. Se recomienda como tiempo de duración de un ciclo de desarrollo entre dos semanas y dos meses.( considerando sistemas complejos y los no complejos). La fijación de duración de un ciclo de desarrollo es una tarea muy útil ya que limita a un marco temporal, un lapso rígidamente fijo la conclusión de los prototipos. CARACTERÍSTICAS DEL PROCESO DE DESARROLLO Los siguientes aspectos caracterizan al proceso de desarrollo recomendado: • Desarrollo iterativo e incremental • Desarrollo orientado a casos de uso • Desarrollo que comienza por definir la arquitectura (“centrado en la arquitectura”) DESARROLLO ITERATIVO E INCREMENTAL Desventajas de un ciclo de vida en cascada La característica principal que distingue a un ciclo de desarrollo en cascada es que tiene un solo paso de análisis, diseño y construcción; en un único paso se realiza todo el análisis, luego todo el diseño, luego la codificación y finalmente todas las pruebas. Lo que provoca las siguientes deficiencias: - Carga frontal de gran complejidad: excesiva complejidad - Retraso de la retroalimentación - Congelamiento temprano de las especificaciones, mientras cambia el ambiente de negocios.



Diseño

3. Pruebas del sistema

5. Pruebas de aceptación 6. Pruebas de la documentación

1. Pruebas de unidad 2. Pruebas de integración

4. Pruebas de desempeño

Enfoque cascada



14

UN CICLO DE VIDA ITERATIVO E INCREMENTAL En contraste con un ciclo de vida en cascada, el ciclo iterativo se funda en el perfeccionamiento gradual de un sistema a través de múltiples ciclos de análisis, diseño y construcción, según se aprecia en la figura:

Ciclo de vida iterativo En cada ciclo se trata un conjunto relativamente pequeño de requerimientos y el sistema crece incrementalmente conforme van concluyéndose los ciclos. Por eso a este proceso se le califica de iterativo e incremental. Aporta los siguientes beneficios: - La complejidad nunca resulta abrumadora porque en un ciclo sólo se abordan unidades cuya complejidad

es manejable. Se evitan así la “parálisis del análisis” y la “parálisis del diseño”. - Se generan retroalimentación en las fases iniciales, porque la implementación ocurre rápidamente en un

pequeño subconjunto del sistema. Esta retroalimentación le suministra información al análisis de ciclos subsecuentes, pudiendo además mejorarlo. Llega a los diseñadores a través de los resultados de su fase de implementación y pruebas a través de la comunidad que usa una versión ya liberada del sistema.

- El equipo de desarrollo podrá ir replicando gradualmente su creciente dominio de las herramientas: no es

necesario que desde un principio se sirva de las mejores ( y más complejas) características del lenguaje/herramienta ni tampoco que se sirva exclusivamente de técnicas no dominadas para dividir el sistema.

- Los requerimientos son ajustables para que respondan a las necesidades cambiantes de la compañía, a

medida que avanza el proyecto. El desarrollo iterativo no significa hacer una pausa, alcanzar una meta importante y luego volver a detenerse. He aquí una definición más exacta del desarrollo iterativo: es un proceso planeado que consiste en revisar varias veces un área, mejorando el sistema en cada revisión. Se trata de un proceso formalmente planeado y programado de ninguna manera fortuito.





...



Diseño

Enfoque iterativo e incremental



15

Es posible realizar muchos ciclos de desarrollo con los mismos requerimientos, en los cuales el sistema (o subsistema) se afina y perfecciona, y también hacerlo con nuevos requerimientos (que es el caso más común) El desarrollo incremental consiste en agregarle funcionalidad a un sistema en los ciclos productivos; con cada uno va aumentando la funcionalidad. Una creación incremental se compone de varios ciclos de desarrollo iterativo. Con producciones incrementales bastante frecuentes se obtienen los siguientes beneficios: - Integración global y pruebas del sistema en una etapa inicial. - Retroalimentación temprana al diseñador por parte de la comunidad de usuarios finales, utilizando el

sistema generado. - Retroalimentación al cliente y a la comunidad de usuarios finales respecto a la habilidad y confiabilidad

del equipo encargado del desarrollo. - Suposición de que la versión producida es exitosa, de que desde un principio genera confianza y

satisfacción entre la comunidad de usuarios. Una de las principales desventajas del desarrollo iterativo e incremental son las expectativas del cliente y de los directivos. Como este proceso admite demostraciones en las primeras fases, el cliente y los directivos tenderán a pensar que el sistema “casi está terminado”: el conocido problema de “funciona la interfaz para el usuario, sistema terminado”. Se requiere de un manejo riguroso de las expectativas y una comunicación frecuente y clara por parte del equipo de desarrollo, si se quiere atenuar esta reacción, desagraciadamente inevitable. DESARROLLO ORIENTADO A CASOS DE USO Un caso de uso es una descripción narrativa de un proceso de dominio: Por ejemplo Obtener libros prestados en una biblioteca. El proceso de desarrollo debería evidenciar el flujo de los casos de uso y organizarse en torno a ellos. Por ejemplo: - Los requerimientos se organizan y se redactan a partir de los casos de uso - En las estimaciones influyen directa e indirectamente los casos: su número, su complejidad, los servicios

de soporte que requieren, etc. - Los programas se organizan a partir de ciclos iterativos, los cuales se basan en la realización de los casos

de uso. - A partir de los casos de uso se escogen los requerimientos que deberían cumplirse en un ciclo iterativo

particular. - Las actividades de un ciclo de desarrollo procuran ante todo llevar a cabo el caso o casos que se

consideran en el ciclo. - Los conceptos y las clases de software pueden identificarse atendiendo a los casos de uso. Los ciclos iterativos de desarrollo se organizan a partir de los requerimientos del caso de uso. Dicho de otra manera, se asigna un ciclo de desarrollo para implementar un subconjunto de casos de uso o bien sus versiones simplificadas.




Caso de Uso A: Versión simplificada --------------

Caso de Uso B: Versión íntegra --------------

Caso de Uso D: Versión simplificada --------------

Caso de Uso C: --------------



16

Clasificación de los casos de uso Los casos de uso deben clasificarse, y los que ocupen los niveles más altos habrían de abordarse en los ciclos iniciales de desarrollo. La estrategia general consiste en seleccionar los casos que influyen profundamente en la arquitectura básica, dando soporte al dominio y a las capas de servicios de alto nivel o los que presente el máximo riesgo. DESARROLLO QUE COMIENZA POR DEFINIR LA ARQUITECTURA (“CENTRADO EN LA ARQUITECTURA”) Con el término arquitectura se designa la estructura de alto nivel de los subsistemas y de los componentes, así como de sus interfaces, conexiones e interacciones. La arquitectura se compone de un conjunto de esquemas, subsistemas, clases, asignaciones de responsabilidades y colaboraciones entre objetos que cumplen con las funciones del sistema. Es decir la arquitectura de un sistema, es la organización o estructura básica de un sistema, estructura de sus partes más relevantes. Una arquitectura ejecutable es una implementación parcial del sistema, construida para demostrar algunas funciones y propiedades. Un proceso de desarrollo eficaz estimula la generación temprana de una arquitectura global del sistema: está centrado en la arquitectura. Ello significa que en los primeros ciclos se ponen de relieve la investigación y el desarrollo de esquemas arquitectónicos bien diseñados; al mismo tiempo se tiene una visión global de una arquitectura integrada a los largo del proyecto. El diseño se ha construido de una forma sistemática y organizada. Por lo tanto el proceso de desarrollo establece refinamiento sucesivos de una arquitectura ejecutable, construida como un prototipo evolutivo. Una arquitectura bien diseñada reúne las siguientes cualidades ideales: � Es robusta, flexible y se incrementa en modo adecuado � Tiene muchos componentes reutilizables � Se orienta a los casos de uso más importantes y riesgosos � Ofrece bajo acoplamiento entre subsistemas EL UML Y EL PROCESO DE DESARROLLO El UML (Lenguaje Unificado para la construcción de modelos) se define como un lenguaje que permite especificar, visualizar y construir los artefactos de los sistemas de software, es un sistema notacional destinado a los sistemas de modelado que utilizan conceptos orientados a objetos. El Lenguaje UML estandariza los artefactos y la notación del análisis y diseño orientado a objetos, pero no define un proceso oficial de desarrollo. La siguiente razón explica esta situación: - Para aumentar las posibilidades de una aceptación generalizada de la notación estándar del modelado sin la obligación de adoptar un proceso oficial COMPARACIÓN ENTRE EL ANÁLISIS Y EL DISEÑO ORIENTADO A OBJETOS Y EL ANÁLISIS Y DISEÑO ORIENTADO A FUNCIONES. Anteriormente, el método usual de descomponer un problema eran el análisis y diseño de sistemas estructurados cuya dimensión de descomposición es fundamentalmente por funciones y procesos, lo cual origina una división jerárquica de procesos constituidos por subprocesos.

Planeación y elaboración Construcción Aplicación

Arquitectura



17

Sin embargo existen otras dimensiones de descomposición: el análisis y diseño orientados a objetos buscan ante todo descomponer un espacio de problema por objetos y no por funciones.

Sistema de Información Biblioteca

Análisis y Diseño Orientado a Objetos

Análisis y Diseño Estructurado

Descomposición por objetos y funciones Descomposición por funciones y procesos

Catálogo Bibliotecario

Libro Biblioteca

Sistema

Registro de Datos

Préstamo de Textos

Consultas y Reportes



18

RATIONAL UNIFIED PROCESS (RUP) RUP es un producto comercial desarrollado y comercializado por Rational Software, compañía de IBM. Historia La Figura siguiente ilustra la historia de RUP. El antecedente más importante se ubica en 1967 con la Metodología Ericsson (Ericsson Approach) elaborada por Ivar Jacobson, una aproximación de desarrollo basada en componentes, que introdujo el concepto de Caso de Uso. Entre los años de 1987 a 1995 Jacobson fundó la compañía Objectory AB y lanza el proceso de desarrollo Objectory (abreviación de Object Factory).

Historia de RUP

Posteriormente en 1995 Rational Software Corporation adquiere Objectory AB y entre 1995 y 1997 se desarrolla Rational Objectory Process (ROP) a partir de Objectory 3.8 y del Enfoque Rational (Rational Approach) adoptando UML como lenguaje de modelado. Desde ese entonces y a la cabeza de Grady Booch, Ivar Jacobson y James Rumbaugh, Rational Software desarrolló e incorporó diversos elementos para expandir ROP, destacándose especialmente el flujo de trabajo conocido como modelado del negocio. En junio del 1998 se lanza Rational Unified Process. Características esenciales

Los autores de RUP destacan que el proceso de software propuesto por RUP tiene tres características esenciales: está dirigido por los Casos de Uso, está centrado en la arquitectura, y es iterativo e incremental.

Proceso dirigido por Casos de Uso

Los Casos de Uso son una técnica de captura de requisitos que fuerza a pensar en términos de importancia para el usuario y no sólo en términos de funciones que seria bueno contemplar. Se define un Caso de Uso como un fragmento de funcionalidad del sistema que proporciona al usuario un valor añadido. Los Casos de Uso representan los requisitos funcionales del sistema. En RUP los Casos de Uso no son sólo una herramienta para especificar los requisitos del sistema. También guían su diseño, implementación y prueba. Los Casos de Uso constituyen un elemento integrador y una guía del trabajo como se muestra en la Figura siguiente.



19

Los Casos de Uso integran el trabajo

Los Casos de Uso no sólo inician el proceso de desarrollo sino que proporcionan un hilo conductor, permitiendo establecer trazabilidad entre los artefactos que son generados en las diferentes actividades del proceso de desarrollo. Como se muestra en la Figura siguiente, basándose en los Casos de Uso se crean los modelos de análisis y diseño, luego la implementación que los lleva a cabo, y se verifica que efectivamente el producto implemente adecuadamente cada Caso de Uso. Todos los modelos deben estar sincronizados con el modelo de Casos de Uso.

Trazabilidad a partir de los Casos de Uso

Proceso centrado en la arquitectura

La arquitectura de un sistema es la organización o estructura de sus partes más relevantes, lo que permite tener una visión común entre todos los involucrados (desarrolladores y usuarios) y una perspectiva clara del sistema completo, necesaria para controlar el desarrollo. La arquitectura involucra los aspectos estáticos y dinámicos más significativos del sistema, está relacionada con la toma de decisiones que indican cómo tiene que ser construido el sistema y ayuda a determinar en qué orden. Además la definición de la arquitectura debe tomar en consideración elementos de calidad del sistema, rendimiento, reutilización y capacidad de evolución por lo que debe ser flexible durante todo el proceso de desarrollo. La arquitectura se ve influenciada por la plataforma software, sistema operativo, gestor de bases de datos, protocolos, consideraciones de desarrollo como sistemas heredados. Muchas de estas restricciones constituyen requisitos no funcionales del sistema. En el caso de RUP además de utilizar los Casos de Uso para guiar el proceso se presta especial atención al establecimiento temprano de una buena arquitectura que no se vea fuertemente impactada ante cambios posteriores durante la construcción y el mantenimiento. Cada producto tiene tanto una función como una forma. La función corresponde a la funcionalidad reflejada en los Casos de Uso y la forma la proporciona la arquitectura. Existe una interacción entre los Casos de Uso y la arquitectura, los Casos de Uso deben encajar en la arquitectura cuando se llevan a cabo y la arquitectura debe permitir el desarrollo de todos los Casos de Uso requeridos, actualmente y en el futuro. Esto provoca que tanto arquitectura como Casos de Uso deban evolucionar en paralelo durante todo el proceso de desarrollo de software.



20

Architecture

Inception Elaboration Construction Transition

tiempo

ArchitectureArchitecture

Inception Elaboration Construction Transition

tiempo Evolución de la arquitectura del sistema

Es conveniente ver el sistema desde diferentes perspectivas para comprender mejor el diseño por lo que la arquitectura se representa mediante varias vistas que se centran en aspectos concretos del sistema, abstrayéndose de los demás. Para RUP, todas las vistas juntas forman el llamado modelo 4+1 de la arquitectura, el cual recibe este nombre porque lo forman las vistas lógica, de implementación, de proceso y de despliegue, más la de Casos de Uso que es la que da cohesión a todas.

Los modelos se completan, la arquitectura no cambia drásticamente

Como se observa en la Figura anterior, durante la construcción los diversos modelos van desarrollándose hasta completarse (según se muestra con las formas rellenas en la esquina superior derecha). La descripción de la arquitectura sin embargo, no debería cambiar significativamente (abajo a la derecha) debido a que la mayor parte de la arquitectura se decidió durante la elaboración. Se incorporan pocos cambios a la arquitectura (indicados con mayor densidad de puntos en la figura inferior derecha).

Proceso iterativo e incremental

El equilibrio correcto entre los Casos de Uso y la arquitectura es algo muy parecido al equilibrio de la forma y la función en el desarrollo del producto, lo cual se consigue con el tiempo. Para esto, la estrategia que se propone en RUP es tener un proceso iterativo e incremental en donde el trabajo se divide en partes más pequeñas o mini proyectos. Permitiendo que el equilibrio entre Casos de Uso y arquitectura se vaya logrando durante cada mini proyecto, así durante todo el proceso de desarrollo. Cada mini proyecto se puede ver como una iteración (un recorrido más o menos completo a lo largo de todos los flujos de trabajo fundamentales) del cual se obtiene un incremento que produce un crecimiento en el producto. Una iteración puede realizarse por medio de una cascada como se muestra en la Figura siguiente. Se pasa por los flujos fundamentales (Requisitos, Análisis, Diseño, Implementación y Pruebas), también existe una planificación de la iteración, un análisis de la iteración y algunas actividades específicas de la iteración. Al



21

finalizar se realiza una integración de los resultados con lo obtenido de las iteraciones anteriores.

Una iteración RUP El proceso iterativo e incremental consta de una secuencia de iteraciones. Cada iteración aborda una parte de la funcionalidad total, pasando por todos los flujos de trabajo relevantes y refinando la arquitectura. Cada iteración se analiza cuando termina. Se puede determinar si han aparecido nuevos requisitos o han cambiado los existentes, afectando a las iteraciones siguientes. Durante la planificación de los detalles de la siguiente iteración, el equipo también examina cómo afectarán los riesgos que aún quedan al trabajo en curso. Toda la retroalimentación de la iteración pasada permite reajustar los objetivos para las siguientes iteraciones. Se continúa con esta dinámica hasta que se haya finalizado por completo con la versión actual del producto. RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en los distintas actividades.

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una premodelo de la arquitectura. Durante la fase de inicio las iteraciones hacen ponen mayor énfasis en actividades modelado del negocio y de requisitos. En la fase de elaboración, las iteraciones se orientan al desarrollo del premodelo de la arquitectura, abarcan más los flujos de trabajo de requerimientos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la arquitectura. En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones. Para cada iteración se selecciona algunos Casos de Uso, se refina su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan tantas iteraciones hasta que se termine la implementación de la nueva versión del producto. En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios. Descripción de las fases

Inicio

Durante la fase de inicio se define el modelo del negocio y el alcance del proyecto. Se identifican todos los actores y Casos de Uso, y se diseñan los Casos de Uso más esenciales (aproximadamente el 20% del modelo completo). Se desarrolla, un plan de negocio para determinar que recursos deben ser asignados al proyecto. Los objetivos de esta fase son:

• Establecer el ámbito del proyecto y sus límites. • Encontrar los Casos de Uso críticos del sistema, los escenarios básicos que definen la funcionalidad.



22

• Mostrar al menos una arquitectura candidata para los escenarios principales. • Estimar el coste en recursos y tiempo de todo el proyecto. • Estimar los riesgos, las fuentes de incertidumbre.

Los resultados de la fase de inicio deben ser :

• Un documento de visión: Una visión general de los requerimientos del proyecto, características clave y restricciones principales.

• Modelo inicial de Casos de Uso (10-20% completado). • Un glosario inicial: Terminología clave del dominio. • El caso de negocio. • Lista de riesgos y plan de contingencia. • Plan del proyecto, mostrando fases e iteraciones. • Modelo de negocio, si es necesario • Prototipos exploratorios para probar conceptos o la arquitectura candidata.

Al terminar la fase de inicio se deben comprobar los criterios de evaluación para continuar:

• Todos los interesados en el proyecto coinciden en la definición del ámbito del sistema y las estimaciones de agenda.

• Entendimiento de los requisitos, como evidencia de la fidelidad de los Casos de Uso principales. • Las estimaciones de tiempo, coste y riesgo son creíbles. • Comprensión total de cualquier prototipo de la arquitectura desarrollado. • Los gastos hasta el momento se asemejan a los planeados.

Si el proyecto no pasa estos criterios hay que plantearse abandonarlo o repensarlo profundamente.

Elaboración

El propósito de la fase de elaboración es analizar el dominio del problema, establecer los cimientos de la arquitectura, desarrollar el plan del proyecto y eliminar los mayores riesgos. En esta fase se construye un prototipo de la arquitectura, que debe evolucionar en iteraciones sucesivas hasta convertirse en el sistema final. Este prototipo debe contener los Casos de Uso críticos identificados en la fase de inicio. También debe demostrarse que se han evitado los riesgos más graves. Los objetivos de esta fase son :

• Definir, validar y cimentar la arquitectura. • Completar la visión. • Crear un plan fiable para la fase de construcción. Este plan puede evolucionar en sucesivas

iteraciones. Debe incluir los costes si procede. • Demostrar que la arquitectura propuesta soportará la visión con un coste razonable y en un tiempo

razonable. Al terminar deben obtenerse los siguientes resultados :

• Un modelo de Casos de Uso completa al menos hasta el 80%: todos los casos y actores identificados, la mayoría de los casos desarrollados.

• Requisitos adicionales que capturan los requisitos no funcionales y cualquier requisito no asociado con un Caso de Uso específico.

• Descripción de la arquitectura software. • Un prototipo ejecutable de la arquitectura. • Lista de riesgos y caso de negocio revisados. • Plan de desarrollo para el proyecto. • Un caso de desarrollo actualizado que especifica el proceso a seguir. • Un manual de usuario preliminar (opcional).

En esta fase se debe tratar de abarcar todo el proyecto con la profundidad mínima. Sólo se profundiza en los puntos críticos de la arquitectura o riesgos importantes.



23

En la fase de elaboración se actualizan todos los productos de la fase de inicio. Los criterios de evaluación de esta fase son los siguientes:

• La visión del producto es estable. • La arquitectura es estable. • Se ha demostrado mediante la ejecución del prototipo que los principales elementos de riesgo han

sido abordados y resueltos. • El plan para la fase de construcción es detallado y preciso. Las estimaciones son creíbles. • Todos los interesados coinciden en que la visión actual será alcanzada si se siguen los planes

actuales en el contexto de la arquitectura actual. • Los gastos hasta ahora son aceptables, comparados con los previstos.

Si no se superan los criterios de evaluación quizá sea necesario abandonar el proyecto o replanteárselo considerablemente. Construcción La finalidad principal de esta fase es alcanzar la capacidad operacional del producto de forma incremental a través de las sucesivas iteraciones. Durante esta fase todos los componentes, características y requisitos deben ser implementados, integrados y probados en su totalidad, obteniendo una versión aceptable del producto. Los objetivos concretos incluyen:

• Minimizar los costes de desarrollo mediante la optimización de recursos y evitando el tener que rehacer un trabajo o incluso desecharlo.

• Conseguir una calidad adecuada tan rápido como sea práctico. • Conseguir versiones funcionales (alfa, beta, y otras versiones de prueba) tan rápido como sea

práctico. Los resultados de la fase de construcción deben ser:��

• Modelos Completos (Casos de Uso, Análisis, Diseño, Despliegue e Implementación) • Arquitectura íntegra (mantenida y mínimamente actualizada) • Riesgos Presentados Mitigados • Plan del Proyecto para la fase de Transición. • Manual Inicial de Usuario (con suficiente detalle) • Prototipo Operacional – beta • Caso del Negocio Actualizado

Los criterios de evaluación de esta fase son los siguientes: • El producto es estable y maduro como para ser entregado a la comunidad de usuario para ser

probado. • Todos los usuarios expertos están listos para la transición en la comunidad de usuarios. • Son aceptables los gastos actuales versus los gastos planeados.

Transición La finalidad de la fase de transición es poner el producto en manos de los usuarios finales, para lo que se requiere desarrollar nuevas versiones actualizadas del producto, completar la documentación, entrenar al usuario en el manejo del producto, y en general tareas relacionadas con el ajuste, configuración, instalación y facilidad de uso del producto. Se citan algunas de las cosas que puede incluir esta fase:

• Prueba de la versión Beta para validar el nuevo sistema frente a las expectativas de los usuarios • Funcionamiento paralelo con los sistemas legados que están siendo sustituidos por nuestro proyecto. • Conversión de las bases de datos operacionales. • Entrenamiento de los usuarios y técnicos de mantenimiento. • Traspaso del producto a los equipos de marketing, distribución y venta.

Los principales objetivos de esta fase son:



24

• Conseguir que el usuario se valga por si mismo. • Un producto final que cumpla los requisitos esperados, que funcione y satisfaga suficientemente al

usuario. Los resultados de la fase de transición son :

• Prototipo Operacional • Documentos Legales • Caso del Negocio Completo • Línea de Base del Producto completa y corregida que incluye todos los modelos del sistema • Descripción de la Arquitectura completa y corregida • Las iteraciones de esta fase irán dirigidas normalmente a conseguir una nueva versión.

Los criterios de evaluación de esta fase son los siguientes:

• El usuario se encuentra satisfecho. • Son aceptables los gastos actuales versus los gastos planificados.

Términos asociados Estructura Estática del proceso. Roles, actividades, artefactos y flujos de trabajo Un proceso de desarrollo de software define quién hace qué, cómo y cuándo. RUP define cuatro elementos los roles, que responden a la pregunta ¿Quién?, las actividades que responden a la pregunta ¿Cómo?, los productos, que responden a la pregunta ¿Qué? y los flujos de trabajo de las disciplinas que responde a la pregunta ¿Cuándo?.

Relación entre roles, actividades, artefactos

Roles Un rol define el comportamiento y responsabilidades de un individuo, o de un grupo de individuos trabajando juntos como un equipo. Una persona puede desempeñar diversos roles, así como un mismo rol puede ser representado por varias personas. Las responsabilidades de un rol son tanto el llevar a cabo un conjunto de actividades como el ser el dueño de un conjunto de artefactos [MMA]. RUP define grupos de roles, agrupados por participación en actividades relacionadas. Estos grupos son : Analistas:

• Analista de procesos de negocio.

• Diseñador del negocio. • Analista de sistema. • Especificador de

requisitos.

Desarrolladores: • Arquitecto de software. • Diseñador • Diseñador de interfaz de

usuario • Diseñador de cápsulas. • Diseñador de base de

datos. • Implementador. • Integrador

Gestores: • Jefe de proyecto • Jefe de control de cambios. • Jefe de configuración. • Jefe de pruebas • Jefe de despliegue • Ingeniero de procesos • Revisor de gestión del

proyecto • Gestor de pruebas.



25

Apoyo: • Documentador técnico • Administrador de sistema • Especialista en

herramientas • Desarrollador de cursos • Artista gráfico

Especialista en pruebas: • Especialista en Pruebas

(tester) • Analista de pruebas • Diseñador de pruebas

Otros roles: • Revisor • Coordinación de revisiones • Revisor técnico • Cualquier rol

Actividades Una actividad en concreto es una unidad de trabajo que una persona que desempeñe un rol puede ser solicitado a que realice. Las actividades tienen un objetivo concreto, normalmente expresado en términos de crear o actualizar algún producto. Artefactos Un producto o artefacto es un trozo de información que es producido, modificado o usado durante el proceso de desarrollo de software. Los productos son los resultados tangibles del proyecto, las cosas que va creando y usando hasta obtener el producto final [MMA]. Un artefacto puede ser cualquiera de los siguientes :

• Un documento, como el documento de la arquitectura del software. • Un modelo, como el modelo de Casos de Uso o el modelo de diseño. • Un elemento del modelo, un elemento que pertenece a un modelo como una clase, un Caso de Uso o

un subsistema. Flujos de trabajo Con la enumeración de roles, actividades y artefactos no se define un proceso, necesitamos contar con una secuencia de actividades realizadas por los diferentes roles, así como la relación entre los mismos. Un flujo de trabajo es una relación de actividades que nos producen unos resultados observables. A continuación se dará una explicación de cada flujo de trabajo.

Modelado del negocio

Con este flujo de trabajo pretendemos llegar a un mejor entendimiento de la organización donde se va a implantar el producto. Los objetivos del modelado de negocio son :

• Entender la estructura y la dinámica de la organización para la cual el sistema va ser desarrollado (organización objetivo).

• Entender el problema actual en la organización objetivo e identificar potenciales mejoras. • Asegurar que clientes, usuarios finales y desarrolladores tengan un entendimiento común de la

organización objetivo. • Derivar los requisitos del sistema necesarios para apoyar a la organización objetivo.

Para lograr estos objetivos, el modelo de negocio describe como desarrollar una visión de la nueva organización, basado en esta visión se definen procesos, roles y responsabilidades de la organización por medio de un modelo de Casos de Uso del negocio y un Modelo de Objetos del Negocio. Complementario a estos modelos, se desarrollan otras especificaciones tales como un Glosario.

Requisitos

Este es uno de los flujos de trabajo más importantes, porque en él se establece qué tiene que hacer exactamente el sistema que construyamos. En esta línea los requisitos son el contrato que se debe cumplir, de modo que los usuarios finales tienen que comprender y aceptar los requisitos que especifiquemos.



26

Los objetivos del flujo de datos Requisitos es : • Establecer y mantener un acuerdo entre clientes sobre lo que el sistema podría hacer. • Proveer a los desarrolladores un mejor entendimiento de los requisitos del sistema. • Definir el ámbito del sistema. • Proveer una base para la planeación de los contenidos técnicos de las iteraciones. • Proveer una base para estimar costos y tiempo de desarrollo del sistema. • Definir una interfaz de usuarios para el sistema, enfocada a las necesidades y metas del usuario.

Los requisitos se dividen en dos grupos. Los requisitos funcionales representan la funcionalidad del sistema. Se modelan mediante diagramas de Casos de Uso. Los requisitos no funcionales representan aquellos atributos que debe exhibir el sistema, pero que no son una funcionalidad específica. Por ejemplo requisitos de facilidad de uso, fiabilidad, eficiencia, portabilidad, etc. Para capturar los requisitos es preciso entrevistar a todos los interesados en el proyecto, no sólo a los usuarios finales, y anotar todas sus peticiones. A partir de ellas hay que descubrir lo que necesitan y expresarlo en forma de requisitos. En este flujo de trabajo, y como parte de los requisitos de facilidad de uso, se diseña la interfaz gráfica de usuario. Para ello habitualmente se construyen prototipos de la interfaz gráfica de usuario que se contrastan con el usuario final. QUÉ SON EL ANÁLISIS Y EL DISEÑO? El análisis se centra en una investigación del problema y las necesidades o requerimientos. Por ejemplo, si se desea un nuevo sistema de información computarizada de una biblioteca, se investigará acerca de los problemas y requerimientos relacionados a los procesos que incluye este sistema. El diseño pone de relieve la solución lógica a los problemas y requerimientos que se identificó durante el análisis. Ej: Respecto al sistema biblioteca, el diseño contemplaría el trazo de una solución del problema de registro de prestamos de libros. El análisis orientado a objetos se centra también en la identificación de problemas y requerimientos, procurando ante todo identificar y describir los objetos o conceptos dentro del dominio del problema. Por ejemplo en el caso del sistema de información biblioteca, algunos de los conceptos son libro, lector, etc. El diseño orientado a objetos se centra también en definir una solución lógica a los problemas y requerimientos detectados durante el análisis, procurando definir los objetos lógicos del software que finalmente serán implementados en un lenguaje de programación orientado a objetos. Los objetos tienen atributos y métodos. Así, en el sistema biblioteca, un objeto de software Libro puede tener un atributo Título y un método Imprimir. Finalmente, durante la construcción o programación orientada a objetos, se implementan los componentes del diseño, como una clase Libro en C++, Java, Smalltalk o Visual Basic.



27

UNIDAD III

CAPTURA DE REQUISITOS

Definición de Modelos y Artefactos Un sistema (tanto en el mundo real como en el mundo del software) suele ser extremadamente intrincado; por ello es necesario dividir el sistema en partes o fragmentos si queremos entender y administrar su complejidad. Estas partes se representan como modelos que describen y abstraen los aspectos esenciales del sistema, para lo cual se utiliza el lenguaje UML (Lenguaje cuya finalidad es describir modelos de sistemas del mundo real basados en los conceptos de objetos). El modelo del sistema.- El modelo global del sistema está constituido por el: Modelo de análisis: el que se relaciona con una investigación del dominio y del ámbito del problema, pero no con la solución. Modelo de diseño: el que se relaciona con la solución lógica Relación entre artefactos.- Sin importar cómo los artefactos se organicen para construir modelos, se dan dependencias muy importantes entre ellos, éstas dependencias e influencias entre artefactos ayudan en el momento de efectuar comprobaciones de consistencia y rastreabilidad y para poder utilizar eficazmente los artefactos dependientes como punto de partida para crear otros.

Influencia de los artefactos en la fase de planeación y de elaboración

Informe preliminar de investigación

Prototipos

Presupuesto. programa

Glosario

Modelo conceptual preliminar

Diagramas de casos de uso

Casos de uso: a. Todos de alto nivel b. Algunos esenciales

expandidos

Especificaciones de requerimientos

Dependencia respecto a



28

FASE DE PLANEACIÓN Y DE ELABORACIÓN Definición los requerimientos.- Requerimientos.- Son una descripción de las necesidades o deseos de un producto. La meta primaria de la fase de requerimientos es identificar y documentar lo que en realidad se necesita. Se recomiendan los siguientes artefactos en la fase de requerimientos:

1. Presentación general del proyecto 2. Clientes, para quien se desarrolla el proyecto 3. Metas, metas que tiene la realización del proyecto 4. Funciones del sistema, las funciones del sistema son lo que éste habrá de hacer. Con el objeto de

verificar que algún X es verdad una función del sistema, la siguiente oración deberá tener sentido: El sistema deberá hacer <X> Categorías de las funciones Las funciones tienen categorías, lo que permite clasificarlas a fin de establecer prioridades entre ellas e identificar las que de los contrario pasarían inadvertidas ( pero que consumen tiempo y otros recursos). Las categorías son:

- Evidente.- Debe realizarse, y el usuario debería saber que se ha realizado - Oculta.- debe realizarse, aunque no es visible para los usuarios. Esto se aplica a muchos

servicios técnicos subyacentes, como Guardar información en disco. Este tipo de funciones a menudo se omiten durante el proceso de obtención de requerimientos (no aconsejable)

- Superflua.- Opcionales, su inclusión no repercute significativamente en el costo ni en otras funciones

5. Atributos del sistema, son sus características o dimensiones; no son funciones. Por ejemplo:

Facilidad de uso Tolerancia a las fallas Tiempo de respuesta Metáfora de interfaz Costo al detalle Plataformas - Los atributos del sistema pueden abarcar todas las funciones (por ejemplo: la plataforma del

sistema operativo) o ser específicos de una función o grupo de funciones. - Los atributos tienen un posible conjunto de detalles de atributos, los cuales tienden a ser valores

discretos, por ejemplo: Metáfora de interfaz = (gráfico, colorido) - Algunos atributos del sistema también pueden tener restricciones de frontera del atributo, que son

condiciones obligatorias de frontera, por ejemplo: Tiempo de respuesta = (cinco segundos como máximo)

Otros ejemplos: Atributo Detalles y restricciones de frontera

Tiempo de respuesta (restricción de frontera) Cuando se registre un producto vendido, la descripción y el precio aparecerán en cinco segundos

Metáfora de interfaz (detalle) Ventanas orientadas a la metáfora de una forma y cuadros de diálogo. (detalle) Maximiza una navegación fácil con teclado y no con apuntadores.

Tolerancia a fallas (restricción de frontera) Debe registrar los pagos a crédito autorizados que se hagan a las cuentas por cobrar en un plazo de 24 horas, aun cuando se produzcan fallas de emergía o del equipo.

Plataformas del sistema operativo

(detalle) Microsoft Windows 95 y NT

Conviene describir todos los atributos del sistema que se relacionen claramente con las funciones dentro de la



29

lista en que se especifican éstas últimas. Además, los detalles de los atributos y las restricciones de frontera pueden catalogarse como obligatorios u opcionales. Otros artefactos en la fase de los requerimientos Las funciones y los atributos del sistema son los documentos mínimos de los requerimientos, de modo que se necesitan otros artefactos importantes para atenuar el riego y entender el problema, a saber: Requerimientos y equipos de enlace: Lista de los que deberían participar en la especificación de las funciones y atributos del sistema, en la realización de entrevistas, de pruebas, de negociaciones y de otras actividades. Grupos afectados: Los que reciben el impacto del desarrollo o aplicación del sistema Suposiciones: las cosas cuya verdad se supone. Riesgos: las cosas que pueden ocasionar el fracaso o retraso Dependencias: con otras personas, sistemas y productos de los cuales no puede prescindir el proyecto para su terminación. Glosario: Definición de los términos pertinentes. Casos de uso: descripciones narrativas de los procesos del dominio; Modelo conceptual preliminar: modelo de conceptos importantes y de sus relaciones. Los tres artefactos últimos se verán con mayor detalle.



30

Ejemplo de Artefactos (Definición de requerimientos)

El proyecto consiste en desarrollar un Sistema para una terminal de Punto de Venta, ésta terminal comprende un sistema computarizado con el que se registran las ventas y se realizan los pagos; normalmente se utiliza en las tiendas la detalle. Abarca componentes de hardware (una computadora y un lector de código de barra) y software para correr el sistema

Presentación General.- Este proyecto tiene por objeto crear un sistema de terminal para el punto de venta que se utilizará en las ventas al menudeo. Clientes.- MundoNet Inc., detallista multinacional de objetos. Metas.- Concretamente, la meta incluye:

- Pago rápido de los clientes - Análisis rápido y exacto de las ventas - Control automático del inventario

Funciones del sistema.- Funciones básicas: REF FUNCIÓN CATEGORÍA R1.1 Registra la venta en proceso (actual): los productos comprados evidente R1.2 Calcula el total de la venta actual; se incluyen el impuesto y los cálculos de cupón. evidente R1.3 Captura la información sobre el objeto comprado usando su código de barras y un lector evidente R1.4 Reduce las cantidades del inventario cuando se realiza una venta Oculta R1.5 Se registran las ventas efectuadas Oculta R1.6 El cajero debe introducir una identificación y una contraseña para poder utilizar el

sistema evidente

R1.7 Ofrece un mecanismo de almacenamiento persistente Oculta R1.8 Ofrece mecanismos de comunicación entre los procesos y entre los sistemas Oculta R1.9 Muestra la descripción y el precio del producto registrado Evidente Funciones de pago REF FUNCIÓN CATEGORÍA R2.1 Maneja los pagos en efectivo, capturando la cantidad ofrecida y calculando el saldo deudor evidente R2.2 Maneja los pagos a crédito, capturando la información crediticia a partir de una lectora de

tarjetas o mediante captura manual, y autorizando los pagos con el servicio de autorización (externa) de créditos de la tienda a través de una conexión por módem.

evidente

R2.3 Maneja los pagos con cheque, capturando la licencia de conducir mediante captura manual, y autorizando los pagos con el servicio de autorización (externa) de cheques de la tienda a través de la conexión por módem.

evidente

R2.4 Registra los pagos en el sistema de cuentas por cobrar, pues el servicio de autorización de crédito debe a la tienda el monto de pago

Oculta

Atributos del sistema.- Ref Función Cat Atributo Detalles y restricciones Cat.

R1.9 Muestra la descripción y el precio del producto registrado

Evidente Tiempo de respuesta

5 segundos como máximo Obligatorio

Metáfora de interfaz

Pantallas basadas en forma Colorido

Obligatorio Opcional

R2.4

Registra los pagos en el sistema de cuentas por cobrar, pues el servicio de autorización de crédito debe a la tienda el monto de pago

Oculto Tolerancia a fallas

Debe registrar en las cuentas por cobrar en un plazo de 24 horas, aún cuando se produzcan fallas de energía o del equipo

Obligatorio

Tiempo de respuesta

10 segundos como máximo Obligatorio



31

CASOS DE USO Descripción De Procesos Una técnica excelente que permite mejorar la comprensión de los requerimientos es la creación de casos de uso, es decir, descripciones narrativas de los procesos del dominio. El UML incluye formalmente el concepto de casos de uso y sus diagramas de uso Para describir casos de uso se requiere tener al menos un conocimiento parcial de los requerimientos del sistema que se desarrolla. Proceso.- Describe de comienzo a fin una secuencia de eventos, de acciones o transacciones que se requieren para producir u obtener algo de valor para una empresa o actor. Se describe en un caso de uso. Casos de uso. El caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (agente externo) que utiliza un sistema para completar un proceso. Los casos de uso son historias o casos de utilización de un sistema; no son exactamente los requerimientos ni las especificaciones funcionales, sino que ejemplifican e incluyen tácitamente los requerimientos en la historias que narran. Representación en lenguaje UML: Actores. El actor es una entidad externa del sistema que de alguna manera participa en la historia del caso de uso. Por lo regular estimula el sistema con eventos de entrada o recibe algo de él. Los actores están representados por el papel que desempeñan en el caso: Cliente, cajero, u otro. Conviene escribir su nombre con mayúscula en la narrativa del caso para facilitar la identificación Representación en lenguaje UML: Cliente Formato Para describir casos de uso, existen dos formatos definidos: Formato de Alto Nivel y Formato Expandido.

Formato de alto Nivel .- Describe el proceso de manera general. Caso de uso: Nombre del caso de uso Actores: Lista de actores Tipo: 1. Primario, secundario u opcional Descripción: resumen narrativo que describe la secuencia de eventos

Ej. De un caso de uso de alto nivel: Comprar productos El siguiente caso de uso de alto nivel describe claramente el proceso de comprar artículos en una tienda cuando se emplea una terminal en un punto de venta.

Comprar productos



32

Caso de Uso: Comprar productos Actores: Cliente, Cajero Tipo: Primario Descripción: Un Cliente llega a la caja registradora con los artículos que comprará.

El Cajero registra los artículos y cobra el importe. Al terminar la operación, el Cliente se marcha con los productos

Se recomienda comenzar con los casos de uso de alto nivel para lograr rápidamente entender los principales procesos globales.

Formato Expandido.- Un caso expandido de uso muestra más detalles que uno de alto nivel; este tipo de casos suelen ser útiles para alcanzar un conocimiento más profundo de los procesos y requerimientos.

Caso de uso: Nombre del caso de uso Actores: Lista de actores (agentes externos), indicando quien inicia el caso de uso Propósito: Intención del caso de uso Resumen: Repetición del caso de uso de alto nivel o alguna síntesis similar. Tipo: 1. Primario, secundario u opcional

2. Esencial o real Referencias cruzadas: Casos relacionados de uso y funciones también relacionadas del sistema Curso normal de los eventos : Descripción de manera detallada de las acciones de los actores

y la respuesta del sistema. Ej: De caso expandido de uso : Comprar productos con efectivo

Caso de uso: Comprar productos en efectivo Actores: Cliente (iniciador), Cajero Propósito: Capturar una venta y su pago en efectivo. Resumen: Un cliente llega a la caja registradora con artículos que desea comprar.

El Cajero registra los productos y recibe un pago en efectivo. Al terminar la operación, el Cliente se marcha con los productos comprados.

Tipo: Primario y esencial Referencias cruzadas: Funciones: R1.1, R1.2, R1.3, R1.7, R1.9, R,2.1

Curso normal de los eventos :

Acción del actor Respuesta del sistema 1. Este caso de uso comienza cuando un Cliente llega a una caja de Punto de Venta con productos que desea comprar

2. El cajero registra el identificador de cada producto. Si hay varios productos de una misma categoría, el Cajero también puede introducir la cantidad

3. determina el precio del producto e incorpora a la transacción actual la información correspondiente. Se presentan la descripción y el precio del producto actual

4. al terminar de introducir el producto, el cajero indica al Punto de Venta que se concluyó la captura del producto

5. calcula y presenta el total de la venta

6. El cajero le indica el total al Cliente Casos de uso primarios, secundarios y opcionales Los casos de uso de acuerdo al grado de importancia para el sistema se clasifican en: Primarios, Secundarios u Opcionales. A partir de esta clasificación, se establecen prioridades de casos de uso para el desarrollo.



33

� Los casos primarios de uso representan los procesos comunes más importantes, como Comprar

productos. � Los casos secundarios de uso representan procesos o menores o raros; por ejemplo, Solicitud de

surtir el nuevo producto. � Los casos opcionales de uso representan procesos que pueden o no considerarse para el desarrollo.

Casos esenciales y reales. Los casos de uso de acuerdo al detalle en su descripción (tomando en cuenta detalles de implementación) se clasifican en: Esenciales y Reales � Casos esenciales de uso, son casos expandidos que se expresan en una forma teórica que contiene poca

tecnología y pocos detalles de implementación. Los casos de alto nivel siempre son de carácter esencial, debido a su brevedad y abstracción.

Ej: Caso de uso Comprar productos en efectivo, expresado en forma esencial

Caso de uso: Comprar productos en efectivo Actores: Cliente (iniciador), Cajero Propósito: Capturar una venta y su pago en efectivo. Resumen: Un cliente llega a la caja registradora con artículos que desea comprar.

El Cajero registra los productos y recibe un pago en efectivo. Al terminar la operación, el Cliente se marcha con los productos comprados.

Tipo: Primario y esencial Referencias cruzadas: Funciones: R1.1, R1.2, R1.3, R1.7, R1.9, R,2.1

Curso normal de los eventos :

Acción del actor Respuesta del sistema 1. Este caso de uso comienza cuando un Cliente llega a una caja de Punto de Venta con productos que desea comprar

2. El cajero registra cada producto. Si hay varios productos de una misma categoría, el Cajero también puede introducir la cantidad

3. El sistema determina el precio del producto e incorpora a la transacción actual la información correspondiente. Se presentan la descripción y el precio del producto actual

4. al terminar de introducir el producto, el cajero indica al Punto de Venta que se concluyó la captura del producto

5. El sistema calcula y presenta el total de la venta

6. El cajero le indica el total al Cliente

La forma en que el cajero registra los productos cambia con el tiempo –es una decisión de diseño-, pero forma parte del proceso esencial de que el registro de producto se realice de alguna manera

� Casos reales de uso, describen concretamente el proceso a partir de su diseño concreto actual, sujeto a

las tecnologías específicas de entrada y de salida, etc. Cuando se trata de la interfaz para el usuario, a menudo ofrece presentaciones de pantalla y explica la interacción con los artefactos.

Ej: Caso de Uso de efectivo expresado en forma real:



34

Comprar productos: Comprar productos en efectivo (Versión 1) Actores: Cliente (iniciador), cajero Propósito: Capturar una venta y su pago en efectivo. Resumen: Un cliente llega a la caja con productos que desea comprar. El cajero registra

los productos de la compra y recibe el pago en efectivo. Al terminar la transacción, el Cliente se marcha con los productos comprados.

Tipo: Primario y real

Curso normal de los eventos

Acción de los actores Respuesta del sistema

1. Este caso comienza cuando un Cliente llega a la caja con objetos que desea comprar.

2. Con cada producto, el Cajero teclea el código universal de producto CUP en A de la ventana Tienda de Objetos. Si hay más de un producto, es opcional capturar la cantidad en E. Se oprime luego H después de capturar cada producto

3. Agrega la información sobre el producto a la actual transacción de ventas. La descripción y el precio del producto actual se muestran en B y en F de la ventana Tienda de Objetos

4. Al terminar de capturar los productos, el cajero oprime el botón I para indicarle a la tienda que terminó de capturar los productos.

5. Calcula y presenta en C el total de la venta. 6. ......

En este ejemplo, el caso de uso se realizó concretamente en la serie de acciones comenzando con “el Cliente solicita comprar productos” Error común en la identificación de casos de uso Consiste en representar los eventos, pasos, operaciones o transacciones individuales como casos de uso, sin considerar que no son más que un paso de un proceso más amplio. Métodos de identificación de casos de uso Se requiere de una lluvia de ideas y revisión de documentos de especificación de requerimientos. Existen dos métodos:

� Basado en actores - Identificar los actores relacionados con un sistema o empresa - En cada actor se identifican procesos que inician o en que participan

� Basada en eventos

A

B

C

D

E

F

G

H I J



35

- Identificar eventos externos a los que un sistema responde - Relacionar eventos con actores y casos de uso

Diagramas de casos de uso ( En UML) Explica gráficamente un conjunto de casos de uso de un sistema, los actores y la relación entre éstos. Comprende:

- Casos de uso, representados por óvalos - Actores, representados por figuras estilizadas de personas - Relaciones, indican flujo de información o el estímulo

Se identifican en UML cuatro tipos de relaciones: 1. Comunicación : Relación propia entre caso de uso y actor 2. Inclusión : Esta relación se utiliza cuando una instancia del Caso de Uso origen incluye también

el comportamiento descrito por el Caso de Uso destino.

3. Extensión : Esta relación se utiliza cuando el Caso de Uso origen extiende el comportamiento del Caso de Uso destino.

4. Herencia : Herencia : el Caso de Uso origen hereda la especificación del Caso de Uso destino y posiblemente la modifica y/o amplía.

- Fronteras, representados por rectángulos que encierran casos de uso y actores del sistema.

Importante definir frontera del sistema para identificar lo que es interno o externo, así como las responsabilidades del sistema (Externo esta representado por actores) Las fronteras ordinarias del sistema son: 1. Frontera de hardware/software de

dispositivo 2. Sistema de cómputo

3. Departamento de la organización 4. Organización entera

ActorC aso de U so

Caso de Uso Origen Caso de Uso Destino

<<include>>

Caso de Uso Origen Caso de Uso Destino

<<extend>>

Caso de Uso Hijo Caso de Uso Padre



36

Notación.- Nombre de los casos de uso: Asignar nombre que comience con verbo para indicar que se trata de proceso Inicio: Comenzar un caso de uso expandido con el esquema:

“Este caso comienza cuando <Actor> <inicia un evento>, posibilita identificar de manera clara el actor y evento iniciador”

Pasos para describir casos de uso y el diagrama correspondiente 1. Después de listar funciones del sistema, defina frontera del mismo y luego identificar actores y

casos de uso 2. Escribir todos los casos de uso en formato de alto nivel. Clasificar en primario, secundario y

opcional. 3. Dibujar diagramas de casos de uso 4. Relacionar los casos de uso 5. Escriba en formato esencial expandido los casos de uso más importantes, influyentes y

riesgosos. 6. Clasificar los casos de uso

Sugerencia. En la fase de análisis, escribir casos de uso esenciales expandidos. En la fase de diseño escribir casos de uso reales.

Selección y programación de los casos de uso para ciclos de desarrrollo

Según la metodología recomendada para el desarrollo de sistemas orientados a objetos, se asigna un ciclo para implementar uno o más casos de uso o la versión simplificada de un caso de uso íntegro si resulta muy complejo para un ciclo

Selección de los casos de uso

La estrategia general consiste en escoger primero los casos de uso que influyen en la arquitectura básica del sistema. Citamos algunas cualidades que debe tener un caso de uso para considerarlo de mayor prioridad.

A. Debe tener fuerte repercusión en el diseño de la arquitectura del sistema B. Debe incluir funciones riesgosas, urgentes y complejas C. Debe requerir una investigación a fondo o tecnología nueva y riesgosa D. Debe representar proceso primario en la línea de negocios E. Debe apoyar directamente al aumento de ingresos o reducción de costos F. …….. ( citar otras cualidades que considere necesario, de acuerdo al sistema automatizado que se

desarrolla) Considerando los casos de uso identificados y descritos, se construye el siguiente esquema:

Casos de uso Criterios y/o cualidades del caso de uso Total

A B C …… F Caso de Uso 1 Caso de Uso 2 …. Caso de Uso N Los casos de uso con mayor porcentaje como promedio final, deben considerarse en el primer ciclo de desarrollo, dejando para los ciclos de desarrollo posteriores, los casos de uso de menor porcentaje. El caso de uso de arranque Es el caso de uso de inicio, que es preciso considerarlo por lo menos en una versión simplificada de él, al iniciar un ciclo de desarrollo e ir refinándolo en los posteriores ciclos.



37

UNIDAD IV

ANÁLISIS ORIENTADO A OBJETOS

INICIO DE UN CICLO DE DESARROLLO A la finalización de la fase de planeación y elaboración (fase en la que los casos de uso ya han sido identificados, clasificados y programados por lo menos en la primera pareja de ciclos de desarrollo) comienza la fase de construcción en la que se realizan los ciclos de desarrollo iterativos. Para iniciar un ciclo de desarrollo, como ya se había anticipado, se necesita definir por lo menos dos casos de uso que van a ser abordados en este primer ciclo. En el inicio de un ciclo de desarrollo de la fase de construcción, se inicia el análisis (en la que se investigan a fondo los problemas del ciclo actual) y como primera actividad del análisis está el desarrollo del modelo conceptual. En el análisis orientado a objetos se identifican muchos objetos o conceptos, esta identificación forma parte de una investigación del dominio del problema. Es decir se realiza una descomposición del problema en conceptos u objetos individuales. Entonces una tarea primordial es esta fase consiste en identificar varios conceptos en el dominio del problema y documentar los resultados en un modelo conceptual. Modelo conceptual: es el artefacto más importante de esta fase, es una representación de conceptos en un dominio del problema ( no son entidades de software). Un modelo conceptual representa: Conceptos, asociaciones entre conceptos y atributos de conceptos. Un modelo muestra conceptos del mundo real no muestra los artefactos o clases de software. Ej:

Modelo conceptual que explica gráficamente que Pago se relaciona con Venta y Venta tiene fecha y hora, Pago tiene monto (atributos más significativos)

Concepto.- es una idea, cosa u objeto. Formalmente se puede considerar un concepto a partir de:

• Símbolo, palabras o imágenes que representan un concepto • Intensión, la definición del concepto (grado de una cualidad) • Extensión, el conjunto de ejemplos a que se aplica el concepto

Ej: El concepto del evento de una transacción compra, puede ser designado con el:

Símbolo: Venta Intensión: representa el evento de una transacción de compra y tiene fecha y hora Extensión: son los ejemplos de venta, conjunto de todas las ventas

Venta

Fecha hora

Pago

monto

Pagada por

1

1

Concepto

Asociación

Atributos



38

Estrategias para identificar conceptos La identificación de conceptos debe realizarse considerando el o los casos de uso seleccionados para el ciclo y es recomendable que al identificar éstos conceptos se exagere y especifique un modelo conceptual con todos los conceptos que involucra el sistema, los cuales se irán refinando posteriormente en la fase de diseño. Existen dos estrategias para identificar conceptos, éstos son: 1. Obtención de conceptos a partir de una lista de categorías de conceptos: En este caso la creación de un modelo conceptual, comienza preparando una lista de conceptos a partir de la siguiente lista que contiene muchas categorías comunes que ayudan a identificar conceptos, los ejemplos listados fueron identificados tomando en cuenta el sistema de Ventas y reservación de líneas aéreas:

CATEGORÍA DEL CONCEPTO EJEMPLOS: Sistema de Control de Ventas y Sistema de Reservación de Pasajes en Línea Aérea

Objetos físicos o tangibles Avión Especificaciones, diseño o descripciones de cosas EspecificacióndeProducto

DescripcióndeVuelo Lugares Tienda

Aeropuerto Transacciones Venta, Pago

Reservación Línea de elemento de transacciones VentasLíneadeProducto Papel de las personas Cajero

Piloto Contenedoras de otras cosas Tienda, cesto

Avión Cosas dentro de un contenedor Producto

Pasajero Otros sistemas de cómputo o electromecánicos externos al sistema

SistemadeAutorizacióndeTarjetadeCrédito ControldeTraficoAereo

Conceptos de nombres abstractos Hambre Organizaciones DepartamentodeVentas

ObjetoLineaAerea Eventos Venta, Robo, Junta

Vuelo, Accidente, Aterrizaje Procesos VentaunProducto

ReservacionAsiento Reglas y políticas PolíticadeReembolso

PolíticadeCancelaciones

Venta

Fecha Hora

Una venta representa el evento de una transacción de compra. Tiene fecha y hora.

Venta – 1 Venta – 2 Venta - 3

Símbolo del concepto

Intención del concepto

Extensión del concepto



39

Catálogos CatalogodeProducto CatalogodePartes

Registros de finanzas, de trabajo, de contratos Recibo, Mayor, ContratodeEmpleo Instrumentos y servicios financieros LíneadeCrédito

Existencia Manuales, libros ManualdePersonal

Manual de Reparaciones 2. Obtención de conceptos a partir de las identificación de frases nominales Otra técnica muy útil consiste en identificar frase nominales (nombres o sustantivos) en las descripciones textuales del dominio de un problema y considerarlas conceptos o atributos idóneos: Ej: En la descripción del caso de uso de Comprar productos se tiene: En esta descripción, las palabras con Negrita son candidatos a ser conceptos, sin embargo, algunos más bien se adecuan a ser Atributos de conceptos. Cómo construir un modelo conceptual Aplicar los siguientes pasos:

1. Listar los conceptos idóneos usando la Lista de categorías de conceptos o la identificación de la frase nominal

2. Dibujar los conceptos identificados en un modelo conceptual 3. Incorporar asociaciones necesarias para registrar las relaciones 4. Agregar los atributos necesarios para cumplir con las necesidades de información

Especificación o descripción de conceptos Algunos conceptos necesitan ser especificados, es decir definir un nuevo concepto que especifique al concepto. Ej. Definición de términos en el lenguaje UML En UML se emplean los términos “clase” y “tipo”, no así concepto. Cualquiera sea la definición, lo importante es su utilidad para distinguir entre la perspectiva de un analista de dominios que observa conceptos reales y los diseñadores de software que especifican entidades de programas. Por lo tanto, se utiliza el término concepto para designar cosas del mundo real y el término clase, para designar las especificaciones e implementaciones de software. Agregación de las asociaciones Es necesario identificar las asociaciones de los conceptos que se requieren para satisfacer los requerimientos

Producto

Número de serie

EspecificacióndeProducto

Descripción Precio CUP

* 1 Describe

Producto

Descripción precio Número de serie CUP

…… Descripción Este caso de uso comienza cuando un Cliente llega a una caja con productos que desea comprar El Cajero registra el código de productos (Cod-Pro) en cada producto Si hay más de un producto, el Cajero puede introducir también una cantidad



40

de información de los casos de uso en cuestión y los que contribuyen a entender el modelo conceptual. Asociación.- es una relación entre dos conceptos que indica alguna conexión significativa e interesante entre ellos. Notación de las asociaciones en el UML Una asociación se representa como una línea entre conceptos con el nombre de la asociación, vínculo totalmente abstracto, no es una afirmación sobre las conexiones entre las entidades del software. Los extremos de un asociación pueden contener una expresión de multiplicidad que indique la relación numérica entre las instancias de los conceptos En la flecha opcional de la dirección de la lectura (o “flecha de la dirección del nombre” indica la dirección en que debe leerse el nombre de la asociación, en su ausencia, por convención la asociación se lee de izquierda a derecha o de arriba hacia abajo. Identificación de las asociaciones: Lista de asociaciones comunes Agregar asociaciones al modelo conceptual ya identificado. A continuación se describen algunas pautas de identificación de asociaciones (con ejemplos para tienda de venta y reservación de líneas aéreas):

CATEGORIA EJEMPLOS: Sistema de Control de Ventas y Sistema de Reservación de Pasajes en Línea Aérea

A es una parte física de B Caja-Tienda Ala-Avión

A es una parte lógica de B VentasLíneas de Producto-Venta TramodeVuelo-RutadeVuelo

A está físicamente contenida en B Producto-Estante Pasajero-Avion

A está contenido lógicamente en B DescripcióndeProducto-Producto DescripcióndeVuelo-Vuelo

A es un elemento de línea en una transacción o reporte B

VentasLíneadeProducto-Venta TrabajodeMantenimiento-Mantenimiento

A se conoce/introduce/registra/presenta/captura en B Venta-Tienda Reservación-ListadePasajeros

A es miembro de B Cajero-Tienda Piloto-Avión

A es una subunidad organizacional de B Departamento-Tienda Mantenimiento-LíneaAerea

A usa o dirige a B Cajero-Tienda Piloto-Avión

A se comunica con B Cliente-Cajero AgentedeReservaciones-Pasajero

A se relaciona con una transacción B Pago-Venta Pasajero-Boleto

A es una transacción relacionada con otra transacción B Pago-Venta Reservación-Cancelación

Tienda Venta Actual Registra ►

1 1

Nombre de la asociación

Flecha de dirección de la lectura (Indica la dirección en que debe leerse el nombre de la asociación, a menudo se excluye)



41

A está contiguo a B Tienda-Tienda Ciudad-Ciudad

A es propiedad de B Avión-LíneaAerea Asociaciones de alta prioridad Las asociaciones de alta prioridad son las que se relacionan a la siguiente categoría: A es una parte física o lógica de B A está física o lógicamente contenido en B A está registrado en B Directrices de las asociaciones:

- Concentrarse en las asociaciones en que el conocimiento de la relación ha de preservarse durante algún tiempo

- Es mas importante identificar conceptos que asociaciones - Muchas asociaciones tiende a confundir el modelo conceptual en vez de aclararlo - No incluir asociaciones redundantes ni derivables.

Papeles.- Recibe esta denominación los extremos de una asociación. Estos pueden tener.

- Nombre, que represente la relación entre los conceptos - Expresión de multiplicidad

Multiplicidad.- define cuantas instancias de un tipo A pueden asociarse a una instancia del tipo B en determinado momento. Valores de la multiplicidad: Agregación de los Atributos Atributo.- es un valor lógico de un dato de un objeto Incluir sólo los atributos en que los requerimientos (por ejemplo los casos de uso) indican o conllevan la necesidad de recordar información. Ej: Un recibo de ventas normalmente incluye la fecha y hora. En consecuencia, el concepto Venta requiere de los atributos fecha y hora.

* Cero o más; “muchos”

1..* Uno o más

1..40 De uno a cuarenta

5 Exactamente 5

3,5,8 Exactamente tres,

Cinco u ocho

Tienda Producto Almacena ►

1 *

Multiplicidad



42

Notación de los atributos en UML Se muestran en la segunda sección de un concepto Tipos de atributos válidos - Conservar simples los atributos, los tipos más simples de atributos son los que, en la práctica, suelen considerarse los tipos más primitivos de datos. Ej: Fecha, número, hora, dirección, color, Nro. Telef., Nro. Del seguro social, Codigo de Producto (Cod-Pro) - Ningún atributo debe incluirse como llave foránea, los atributos no deben servir para relacionar conceptos en el modelo conceptual Otros atributos no son evidentes y posiblemente no se los identifique en el análisis. Esto es aceptable: durante las fases de diseño y construcción se irán incorporando el resto de los atributos. Un buen modelo conceptual capta las abstracciones esenciales y la información indispensable para comprender el dominio dentro del contexto de los requerimientos actuales. Registro de los términos en el glosario Glosario.- o diccionario modelo, es un documento simple en el cual se definen términos. (semejante a un diccionario de datos) incluye y define todos los términos que requieren explicación para mejorar la documentación del sistema. Un significado uniforme y compartido resulta extremadamente importante durante el desarrollo de las aplicaciones, sobre todo cuando muchos miembros del equipo intervienen en el proyecto. Actividades .- El glosario se crea originalmente durante la fase de Planeación y Elaboración conforme vayan generándose los términos. Darle mantenimiento es una actividad permanente a lo largo de todo el proyecto. Ejemplo de glosario aplicado al sistema de punto de venta

TERMINO CATEGORIA COMENTARIOS Comprar productos Caso de uso Descripción del proceso de un cliente que

compra productos en una tienda EspecificacióndeProducto.descripción:Texto

Atributo Descripción breve de un producto en una venta, junto con su EspecificacióndeProducto asociada

…. …… …….

CICLO DE DESARROLLO DIAGRAMA DE SECUENCIAS La creación de los diagramas de secuencia de un sistema forma parte de la investigación para conocer el sistema, se prepara durante la fase de análisis de un ciclo de desarrollo, su creación depende de la formulación previa de los casos de uso.

Venta

Fecha Hora de inicio

Atributos

Cajero

Nombre TiendaActual

No es atributo “Simple”

Cajero

Nombre

Tienda

Número Usa

1 1



43

Antes de iniciar el diseño lógico de una aplicación, es necesario investigar y definir su comportamiento como una “caja negra”. El comportamiento del sistema es una descripción de lo que hace, sin explicar como lo hace. Los casos de uso indican cómo los actores interactúan con el sistema. Durante la interacción un actor genera eventos dirigidos a un sistema, solicitando alguna operación a cambio. Ejemplo, En un sistema de Control de Ventas de una Tienda de Artículos, un cajero introduce un código de producto de un artículo, con lo que solicita al sistema registrar la compra, con el evento de esa petición se inicia una operación del sistema. El UML incluye en su notación, los diagramas de secuencia que dan una descripción gráfica de las interacciones del actor y de las operaciones a que da origen. Definición.- El diagrama de secuencia de un sistema es una representación que muestra, en determinado escenario de un caso de uso, los eventos generados por actores externos y los eventos internos del sistema. Eventos y fronteras de un sistema Para identificar los eventos de un sistema es necesario tener una idea clara de lo que se quiere al escoger su frontera, especialmente en lo que respecta al desarrollo de software, la frontera de un sistema suele seleccionarse considerando el sistema de software y hardware, en este contexto un evento del sistema es un hecho externo que estimula directamente el software. Posteriormente, se debe determinar los actores que interactúan directamente con el sistema de software. Ej: En el Sistema de Control de Ventas anterior, el cliente interactúa con el cajero pero no directamente con el software, esto sólo lo hace el cajero, por lo tanto sólo el cajero es un generador de eventos del sistema. Eventos y operaciones de un sistema El evento de un sistema es un hecho externo de entrada que un actor produce en un sistema. El evento da origen a una operación de respuesta. La operación de un sistema es una acción que éste ejecuta en respuesta a un evento del actor. Ej. Cuando el cajero genera el evento Registrar_Venta, causa la ejecución de la operación Registrar_Venta en el sistema; el nombre del evento y de la operación son idénticos, la diferencia reside en que el evento es el estímulo nombrado y la operación es la respuesta. Diferencia con modelo conceptual La representación del tipo sistema es muy diferente a lo que se expresó en el modelo conceptual. Los elementos de éste representan conceptos del mundo real, en cambio el tipo Sistema es un concepto artificial (además, muestra las operaciones), porque un modelo conceptual presenta información estática, en cambio un diagrama de secuencia describe comportamiento, que es información dinámica.

Cajero

Sistema:

Registra_Venta(Cod-Producto)



44

Cómo elaborar un diagrama de secuencia Para elaborar diagramas de secuencia que describen el curso normal de los eventos en un caso de uso:

- Trace una línea que represente el sistema como una caja negra - Identifique los actores que operan directamente sobre el sistema, trace una línea para cada uno de

ellos. - A partir del curso normal de los eventos del caso de uso, identifique los eventos “externos” del

sistema que son generados por los actores. Muéstrelos gráficamente en el diagrama, utilizando una línea para cada evento.

- Cuando existe demora entre el evento y la operación se puede indicar una línea oblicua - En el diagrama el tiempo avanza hacia abajo, y el ordenamiento de los eventos debería seguir el

orden indicado en el caso de uso. Los eventos del sistema pueden incluir parámetros. - A la izquierda del diagrama puede incluir o no el texto del caso de uso

Asignación de nombre a los eventos y operaciones del sistema Se sugiere nombrar a los eventos del sistema comenzando con verbos (agregar, introducir, terminar, etc) porque recalca que los eventos están orientados a comandos. Ejemplo de diagrama de secuencia El ejemplo refiere el curso normal de los eventos en el caso de uso Comprar Productos. Indica que el cajero es el único actor en el sistema y que genera los eventos del sistema Registrar_Venta Terminar_Venta y Efectuar_Pago. Registro de las operaciones de un sistema Para determinar el conjunto de las operaciones requeridas del sistema se identifican sus eventos. Posteriormente para cada evento identificado se registran las operaciones correspondientes. El UML ofrece una notación para registrar las operaciones de un tipo, en este caso se trata del tipo sistema. Los parámetros son opcionales pueden incluirse o no.

Operaciones del Sistema 1. Operación 1 (parámetros) 2. Operación 2 …

Cajero

Sistema:

Registrar_Venta (Cod-Pro)

Terminar_Venta

Efectuar_Pago($us)



45

COMPORTAMIENTO DE LOS SISTEMAS CONTRATOS El diagrama de secuencias muestra eventos generados por un actor externo pero no profundiza detalles de funcionalidad. Por lo cual en esta fase de análisis, se hace necesario la descripción de contratos, que son documentos que ayudan a definir el comportamiento de un sistema; describen el efecto que sobre el sistema tienen las operaciones del sistema. Definición: Los contratos son documentos que describen el comportamiento de un sistema a partir de cómo cambia el estado de un sistema cuando se llama una operación. Se redactan en estilo declarativo. En otras palabras, describe lo que una operación se propone lograr. En el diagrama de secuencias, se identificaron los eventos generados por un actor externo que afectaban al sistema, los mismos que a su vez generaban la creación de una operación correspondiente. Secciones de un contrato Un contrato incluye las siguientes secciones:

Nombre: Nombre de la operación y parámetros Responsabilidades: Descripción informal de las responsabilidades que debe cumplir

la operación (*) Excepciones: Casos excepcionales que suceden durante la operación (*) Precondiciones : Suposiciones acerca del estado inicial del sistema, antes de

ejecutar la operación Poscondiciones: Descripción del estado del sistema después de ejecutado la

operación. Indica cómo cambió el sistema tras esa operación. Nota.- En un contrato puede NO haber excepciones y precondiciones, son secciones opcionales(*) . El resto de las secciones deben estar bien descritas. Cómo preparar un contrato.

1. Identifique las operaciones del sistema a partir del diagrama de secuencias. 2. Elabore un contrato para cada operación del sistema 3. Comience redactando las Responsabilidades, describa informalmente el propósito de la operación. 4. Complete las poscondiciones, con descripción en forma declarativa de los cambios de estado de los

objetos en el modelo conceptual. Para realizar la descripción de las poscondiciones, utilice categorías, las cuales son:

- Creación y eliminación de instancias - Modificación de atributos - Asociaciones formadas y /o canceladas

CASO DE USO: Comprar productos Curso normal de los eventos 1. este caso de uso comienza...

Registrar_Venta (Cod-Pro, cantidad)

Terminar_Venta ()

EfectuarPago (monto)

Sistema

Operación: RegistrarVenta Poscondiciones 1. Si se trata de una nueva venta, fue creada una nueva Venta ...

Cajero Sistema

RegistrarVenta() IntroducirProducto() EfectuarPago()

Operación: TerminarVenta Poscondiciones 1. ...

Caso de uso Diagrama de la secuencia del sistema

Operaciones del sistema Contratos



46

Recomendación.- las poscondiciones expréselas en verbos de tiempo pasado.

Relación Contratos y Modelo conceptual Cuando se redactan contratos, en la sección de poscondiciones, se identifica para cada poscondición una categoría (Creación y eliminación de instancias, Modificación de atributos, Asociaciones formadas y/o canceladas). Estas poscondiciones con sus categorías permitirán tener una idea más clara acerca de las asociaciones que identificamos en un primer momento en el modelo conceptual, por esta razón será necesario mejorar el modelo conceptual agregando y/o eliminando las nuevas asociaciones, atributos y conceptos que se hayan identificado durante la construcción de un contrato.

A continuación para mayor comprensión del tema, se plantean ejemplos para cada una de los artefactos descritos.

Ejemplo: DIAGRAMA DE SECUENCIA

Ejemplo: REGISTRO DE LAS OPERACIONES DEL SISTEMA Ejemplo: CONTRATO En el siguiente ejemplo se describe un contrato de la operación Registrar_Venta del sistema

CASO DE USO: COMPRAR PRODUCTOS Curso normal de los eventos 1. Este caso de uso comienza cuando un cliente llega a una caja de la Tienda de productos, con productos que desea comprar. 2. El cajero registra el código de producto(Cod-Producto) de cada producto, si hay más de uno del mismo producto, también se puede capturara la cantidad. 3. El sistema determina el precio del producto y agrega la información sobre el producto a la transacción actual de ventas. Se muestran la descripción y el recio del producto actual. 4. etc.

Registrar_Venta (Cod-Producto, cantidad) Terminar_Venta () Efectuar_Pago (monto)

Cajero

Sistema

Comprar productos: versión 1

Sistema Registrar_Venta() Terminar_Venta() Efectuar_Pago()



47

Contrato

Nombre: Registrar_Venta (Cod-Producto: número , cantidad: entero) Responsabilidades: Registrar los datos de la venta de un producto y agregarla a la

venta. Desplegar la descripción y el precio del producto a vender.

Tipo: Sistema Excepciones: Si el Cod-Producto no es válido, indicar que se cometió un error Precondiciones : El sistema debe conocer el Cod-Producto de cada producto Poscondiciones:

o Si se trata de una nueva venta, se crea una Venta (creación de instancia) o Si se trata de una nueva venta, la nueva Venta debe asociarse a la Tienda (asociación

formada) o Se modificó la cantidad existente del producto vendido en Producto (modificación de

atributo) o Se asoció una instancia de Venta con una o mas instancias de Producto, (asociación

formada) Explicación: Poscondiciones de Registrar_Venta.

1. Creación y eliminación de instancias Una vez que el cajero registró el código de producto (Cod-Producto) y la cantidad de un producto, ¿qué nuevos objetos se van a crear? Si se trata de una nueva venta, habría que crear una instancia para una nueva Venta.

o Si se trata de una nueva venta, se crea una Venta (creación de instancia) 2. Modificación de atributos

Una vez que el cajero registró el Cod-Producto y la cantidad de un producto ¿qué atributos de los objetos nuevos o actuales deberían ser modificados? Se debe modificar la cantidad del producto existente de acuerdo a la cantidad vendida en Producto.

o Se modificó la cantidad existente del producto vendido en Producto (modificación de atributo)

3. Asociaciones formadas y canceladas

Una vez que el cajero registró el Cod-Producto y cantidad de un producto ¿qué asociaciones entre los objetos nuevos y los actuales deben formarse o cancelarse? Se debería haber relacionado la nueva instancia de Venta con su(s) producto(s) vendidos Producto. Si se trata de una nueva venta, la Venta debió relacionarse con la Tienda en la que se realizó la Venta.

o Si se trata de una nueva venta, la nueva Venta debe asociarse a la Tienda (asociación formada)

o Se asoció una instancia de Venta con una o mas instancias de Producto, (asociación formada)



48

UNIDAD V

DISEÑO ORIENTADO A OBJETOS

INICIO DE LA FASE DE DISEÑO Una vez construidos los artefactos de la fase de diseño, se inicia la siguiente fase que consiste en la creación de una solución lógica. La esencia de esta fase es la creación de diagramas de interacción, que muestra gráficamente cómo los objetos se comunicaran entre ellos afín de cumplir con los requerimientos. Los diagramas de interacción, posteriormente permiten dibujar diagramas de diseño de clases que resumen la definición de las clases ( e interfaces) implementables en software. En la construcción de los diagramas de interacción es necesario tener en cuenta dos aspectos: Asignación de responsabilidades y la utilización de patrones de diseño. Descripción de casos reales de uso Caso real de uso.- describe el diseño concreto del caso de uso a partir de una tecnología particular de entrada y salida, así como de su implementación global. Ej: Si interviene una interfaz gráfica para el usuario, el caso de uso incluirá diagramas de las ventanas en cuestión y una explicación de la interacción de bajo nivel con los artefactos de la interfaz. Ejemplo: CASO REAL DE USO

Comprar productos: Versión 1 (pago en efectivo exclusivamente) Actores: Cliente (iniciador), cajero Propósito: Capturar una venta y su pago en efectivo. Resumen: Un cliente llega a ala caja con productos que desea comprar. El cajero registra los productos de la compra y recibe el pago en efectivo. Al terminar la transacción, el Cliente se marcha con los productos comprados. Tipo: Primario y real

Curso normal de los eventos

Acción de los actores Respuesta del sistema 1. Este caso comienza cuando un Cliente llega a la caja con objetos que desea comprar.

2. Con cada producto, el Cajero teclea el código universal de producto CUP en A de la ventana Tienda de Objetos. Si hay más de un producto, es opcional capturar la cantidad en E. Se oprime luego H después de capturar cada producto

3. Agrega la información sobre el producto a la actual transacción de ventas. La descripción y el precio del producto actual se muestran en B y en F de la ventana Tienda de Objetos

4. Al terminar de capturar los productos, el cajero oprime el botón I para indicarle a la tienda que terminó de capturar los productos.

5. Calcula y presenta en C el total de la venta. 6. ......

A

B

C

D

E

F

G

H I J



49

DIAGRAMAS DE COLABORACIÓN En los contratos de las operaciones identificadas para el sistema, describen las responsabilidades y poscondiciones. Sin embargo, los contratos no muestran una solución de cómo los objetos de software van a cumplir con dichas poscondiciones. El UML contiene diagramas de colaboración que explican gráficamente cómo los objetos interactúan a través de mensajes para realizar las operaciones. Dependencias.- Los diagramas de colaboración no pueden prepararse sino se generan antes los siguientes artefactos:

- Modelo conceptual.- que comprende los conceptos, objetos del sistema. A partir del cual se podrán identificar las clases del sistema

- Contratos de operación del sistema.- a partir del cual se identifican las responsabilidades y poscondiciones.

- Casos de uso reales.- en los que se describen con precisión, el proceso a realizarse. Diagramas de interacción El UML define dos tipos de diagramas de interacción, ambos sirven para expresar interacciones de mensaje:

- Diagramas de colaboración.- que describen las interacciones entre objetos en un formato de grafo o red.

- Diagramas de secuencia.- que describen las interacciones en una especie de formato de pared o

muro.

Sin embargo, la notación que se recomienda utilizar en la de diagramas de colaboración con formato de grafo o red. Cómo preparar Diagramas de Colaboración

1. Elabore un diagrama por cada operación del sistema durante el ciclo actual de desarrollo - En cada mensaje del sistema, dibuje un diagrama incluyéndolo cono mensaje inicial.

2. Si el diagrama se torna complejo, divídalo tomando en cuenta las actividades que involucra cada operación.

3. Diseñe un sistema de objetos interactivos que realicen las tareas, usando como punto de partida las responsabilidades del contrato de operación, las poscondiciones y la descripción de casos de uso.

:Objeto :Objeto

:Objeto :Objeto

mensaje 1( ) � 1: mensaje 2( ) � 2: mensaje 3( ) �

mensaje 1( )

mensaje 2( )

mensaje 3( )



50

Notación de los diagramas de colaboración Representación gráfica de las clases y de las instancias Para representar una clase se utiliza el rectángulo, con el nombre de la clase dentro. Para representar una instancia, se utiliza el mismo símbolo, sólo que el nombre se subraya y se le antepone dos puntos. Para representar una instancia específica se usa el mismo símbolo, sólo se antecede un nombre de instancia: Clase Instancia Instancia con nombre Representación gráfica de los vínculos (Enlace) es una trayectoria de conexión entre dos instancias, clases, instancia, clase, etc., a lo largo del cual pueden fluir los mensajes. Representación gráfica de los mensajes Los mensajes entre objetos se representan identificándolos con un nombre, utilizando una flecha que indica la dirección del mensaje y situada sobre un vínculo. Representación gráfica de los parámetros Los parámetros pueden anotarse dentro de paréntesis después del nombre del mensaje, es opcional incluir o no el tipo de parámetro en cuestión.

IntroducirProducto (CUP, cantidad)

TerminarVenta ()

EfectuarPago (monto)

Cajero SistemaOperación: IntroducirProducto Poscondiciones 1. Si se trata de una nueva venta, fue creada una nueva Venta ...

Operación: EfectuarPago Poscondiciones 1. ...

Diagrama de la secuencia del sistema

Contratos

: Tienda

: Tienda

IntroducirProducto(CUP,cant)

EfectuarPago(monto)

Diagrama de colaboración

Venta :Venta s1:Venta

:Tienda :Venta 1: agregarPago(Efectivo)

mensaje1( )

vínculo

:Tienda :Venta

1: Mensaje1( ) 2: Mensaje2( ) 3: Mensaje3( )

mensaje1( )



51

Representación gráfica del mensaje de devolver valor Puede incluirse un valor de retorno anteponiéndole al mensaje un nombre de variable de esa instrucción y un operador de asignación (‘:=’). Es opcional mostrar el tipo del valor de retorno Sintaxis de los mensajes El UML cuenta con una sintaxis estándar para los mensajes: No. de secuencia de mensaje : Nombre de variable de retorno := Nombre de mensaje (parámetro : tipo de parámetro) : tipo de retorno

Representación gráfica de mensajes a si mismos Se utiliza un vínculo consigo mismo, donde el mensaje fluye a lo largo del vínculo

Representación gráfica de la iteración La iteración se indica posponiendo un asterisco (*) al número de secuencia, lo que significa que dentro de un ciclo, el mensaje va a ser enviado repetidamente al receptor. Se puede incluir también una cláusula de iteración que indique los valores de recurrencia Representación gráfica de la creación de instancias El mensaje de creación de instancia es crear , el mensaje crear puede contener parámetros, que son valores iniciales. En Java, de este modo se indican parámetros de constructores.

:Tienda :Venta 1: agregarPago(monto:Moneda)

mensaje1( ) parámetro

:Tienda :Venta 1: tot := total ( ): Entero

mensaje1( ) Tipo del valor de retorno

Nombre de variable en la que se devolverá el valor de retorno

:Tienda

mensaje1( )

1: limpiar( )

:Tienda :Venta

1*: li:= siguienteLínea de Producto( ): VentasLíneadeProducto

mensaje1( )

iteración

:Tienda :Venta

1*: [i:=1..10] li:= siguienteLínea de Producto( ): VentasLíneadeProducto

mensaje1( )

Cláusula de iteración



52

Representación gráfica de la secuencia del número de los mensajes El orden de los mensajes se indica con un número de secuencia:

- El primer mensaje no se numera - El orden y el anidamiento de los mensajes siguientes se realiza considerando dos números. Uno

indica el número del mensaje de entrada y el siguiente el número del mensaje de salida. Representación gráfica de los mensajes condicionales Un mensaje condicional se indica posponiendo al número de la secuencia una cláusula condicional entre corchetes, parecido a la cláusula de iteración. El mensaje se envía sólo si la cláusula se evalúa como verdadera. Representación gráfica de trayectorias condicionales mutuamente excluyentes En este caso es necesario modificar las expresiones de la secuencia con una letra de la trayectoria condicional, lo que indicará que tanto 1a como 1b pueden ejecutarse después del mensaje que les antecede

:Tienda :Venta 1: crear ( )

mensaje1( ) Mensaje crear con parámetros opcionales de inicialización

:ClaseA :ClaseB 1: mens2 ( ) mensaje1( )

:ClaseC

:ClaseD

2: mens4 ( )

2.2: mens6 ( )

1.1: mens3 ( ) 2.1: mens5( )

No se numera

:Tienda :Venta 1: [nueva venta] crear ( ) mensaje1( )

:VentasLíneadeProducto

1.1: crear ( )

Mensaje condicional con prueba

:ClaseA :ClaseB 1a: [prueba1] mens2 ( ) mensaje1( )

:ClaseC

1a.1: mens3 ( )

1a y 1b son trayectorias condicionales mutuamente excluyentes

:ClaseD

:ClaseE

1b.1: mens5 ( )

1b: [no prueba1] mens4 ( )

2: mens6 ( )



53

Representación gráfica de las colecciones Un multiobjeto, o conjunto de instancias, se representa por un grupo de rectángulos. Representación gráfica de los mensajes dirigidos a multiobjetos Mensajes dirigidos a un multiobjeto y a un elemento: Representación gráfica de los mensajes dirigidos a un objeto clase Los mensajes pueden ser dirigidos a la propia clase y no a una instancia, con el fin de llamar los métodos de la clase. En consecuencia es necesario subrayar los nombres de las instancias, cuando se desea denotar una instancia, ya que si no se hace puede interpretarse como mensaje dirigido a clase. PATRONES PARA ASIGNAR RESPONSABILIDADES : GRASP DETERMINACIÓN DE MÉTODOS Un sistema orientado a objetos se compone de objetos que envían mensajes a otros objetos para llevar a cabo las operaciones correspondientes, tomando en cuenta la asignación de responsabilidades. Es decir durante al creación de diagramas de colaboración, se requiere considerar quien debe realizar que para enviar el mensaje

:Ventas

:VentasLíneadeProducto

:Venta 1: s:= tamaño ( ): ent

mensaje1( ) Mensaje enviado al objeto colección

:VentasLineadeProducto

:Venta 1: crear ( )

mensaje1( )

v1:VentasLineadeProducto

2: agregarElemento (v1)

:VentasLineadeProducto

:Venta 2: imprimir ( )

mensaje1( )

v1:VentasLineade Producto

1:v1:= obtener(clave)

:Venta 1:d1:= hoy ( ):Fecha

mensaje1( )

Fecha

Clase



54

respectivo para que lo realice. Para realizar una mejor asignación de responsabilidades y así lograr mayor calidad en el diseño de sistemas, se utilizan patrones de diseño, los mismos que ayudan a decidir cómo realizar la asignación de responsabilidades. Importancia de los diagramas de colaboración: cómo asignar responsabilidades Categorías de las responsabilidades Las responsabilidades se relacionan con las obligaciones de un objeto respecto a su comportamiento. Esas responsabilidades pertenecen, esencialmente a dos categorías: Conocer Estar enterado de los datos privados encapsulados Estar enterado de la existencia de objetos conexos Estar enterado de cosas que se puede derivar o calcular Hacer Hacer algo en uno mismo Iniciar una acción en otros objetos Coordinar y controlar actividades en otros objetos Ej: Puede declarase que una Venta es responsable de imprimirse, ella misma (un hacer) o que una Venta tiene la obligación de conocer su fecha (un conocer) Responsabilidad no es lo mismo que método, los métodos se ponen en práctica para cumplir con las responsabilidades. Patrón: Es una pareja de problema/solución con un nombre y que es aplicable a otros contextos, con una sugerencia sobre la manera de usarlo en situaciones nuevas. Un patrón intenta codificar el conocimiento, expresiones y los principios existentes . Se recomienda asignar nombre a los patrones, para facilitar la comunicación y el lenguaje de diseño. Patrones GRASP GRASP ( General responsability Asignment Software Patterns) (Patrones generales de software para asignar responsabilidades). Los patrones básicos que debe considerarse en una fase de diseño orientado a objetos son los siguientes: � Experto � Creador � Alta cohesión � Bajo acoplamiento � Controlador Patrón Experto.-

Problema: Cual es el principio fundamental en virtud del cual se asignan responsabilidades en el diseño orientado a objetos? Solución: Asignar una responsabilidad al experto en información: la clase que cuenta con la información necesaria para cumplir la responsabilidad.

Pregunta: .............. Respuesta: ..............



55

Ejemplo: En la aplicación de la tienda de venta, alguna clase necesita conocer el gran total de la venta. Para determinar quien debe conocer el gran total de la venta se realiza la pregunta: ¿Quién es el responsable de conocer el gran total de la venta? Desde el punto de vista del patrón Experto, deberíamos buscar la clase de objetos que posee la información necesaria para calcular el total, entonces: Patrón Creador.-

Problema: Quién debería ser responsable de crear una nueva instancia de alguna clase? Solución: Asignarle a la clase B la responsabilidad de crear una instancia de clase A en uno de los siguientes casos:

� B agrega los objetos A � B Contiene los objetos A � B registra las instancia de los objetos A � B utiliza específicamente los objetos A

Ejemplo. En la misma aplicación de la tienda de venta ¿quién debería encargarse de crear una instancia de VentasLíneadeProducto? Desde el punto de vista del patrón creador, debemos buscar una clase que agregue, contenga y realice otras operaciones sobre este tipo de instancias, entonces: Patrón Bajo acoplamiento

Problema: ¿cómo dar soporte a una dependencia escasa y a un aumento de la reutilización? Solución: Asignar una responsabilidad para mantener bajo acoplamiento

Acoplamiento: es una medida de la fuerza con que una clase está conectada a otras clases, con que las conoce y con que recurre a ellas. Una clase con bajo o débil acoplamiento no depende de muchas otras, en cambio una clase con alto acoplamiento presenta los siguientes problemas: Son más difíciles de reutilizar porque se requiere la presencia de otras clases de las que dependen. Se afectan por cambio de otros componentes Ejemplo: Supongamos que se desea crear una instancia Pago y asociarla a Venta, que clase se encargará de esto, la posible solucione sería: Aquel que presente bajo acoplamiento Patrón alta cohesión

Problema: Cómo mantener la complejidad dentro de los límites manejables? Solución: Asignar una responsabilidad de modo que la cohesión siga siendo alta

Cohesión es una medida de cúan relacionadas y enfocadas están las responsabilidades de una clase, Así una clase con baja cohesión hace muchas cosas no afines o un trabajo excesivo. Presentan este tipo de problemas:

- Son difíciles de reutilizar - Son delicadas, las afectan constantemente los cambios

Ejemplo: El mismo ejemplo de bajo acoplamiento



56

Patrón controlador

Problema: ¿Quién debería encargarse de atender un evento del sistema? Solución: Asignar la responsabilidad del manejo de un mensaje de los eventos de un sistema a una clase que represente una de las siguientes opciones:

� El sistema global (controlador de fachada) � La empresa u organización global � Algo en el mundo real que es activo (Ej: el papel de una persona)

Evento del sistema: es un evento generado por algún actor externo, se asocia a operaciones del sistema Ej: Quién recibe el mensaje inicial

DIAGRAMA DE CLASES Definición: Describe gráficamente las especificaciones de las clases de software y de las interfaces en un aplicación, contiene información como. Clases, asociaciones y atributos, interfaces con sus operaciones y constantes, métodos, navegabilidad, dependencias. A diferencia del modelo conceptual, un diagrama de este tipo contiene la descripción de las entidades del software en vez de conceptos del mundo real Cómo elaborar un diagrama de clases del diseño

1. Identifique todas las clases que participan en la solución del software, para ello analice los diagramas de interacción.

2. Dibújelas en un diagrama de clases 3. Duplique los atributos provenientes de los conceptos asociados al modelo conceptual 4. Agregue los nombres de los métodos analizando los diagramas de interacción 5. Incorpore la información sobre los tipos a los atributos y a los métodos 6. Agregue flechas de navegabilidad a las asociaciones 7. Agregue la líneas de relaciones de dependencia

La Clase

Una clase esta representada por un rectángulo que dispone de tres apartados, el primero para indicar el nombre, el segundo para los atributos y el tercero para los métodos. Cada clase debe tener un nombre único, que las diferencie de las otras. Un atributo representa alguna propiedad de la clase que se encuentra en todas las instancias de la clase. Los atributos pueden representarse solo mostrando su nombre, mostrando su nombre y su tipo, e incluso su valor por defecto. Un método o operación es la implementación de un servicio de la clase, que muestra un comportamiento común a todos los objetos. En resumen es una función que le indica a las instancias de la clase que hagan algo. Para separar las grandes listas de atributos y de métodos se pueden utilizar estereotipos. Aquí vemos un ejemplo. La clase usuario contiene tres atributos. Nombre que es public, dirección que es protected y situación que es private. Situación empieza con el valor 3. También dispone de tres métodos Entrar, Salir y Trabajar

Atributos: Los atributos de una clase no deberían ser manipulables directamente por el resto de objetos. Por esta

razón se crearon niveles de visibilidad para los elementos que son: Privado (-): es el más fuerte. Esta parte es totalmente invisible (excepto para clases friends en terminología C++). Protegido (#): Los atributos/operaciones protegidos están visibles para las clases friends y para las clases derivadas de la original.



57

Público (+): Los atributos/operaciones públicos son visibles a otras clases (cuando se trata de atributos se está transgrediendo el principio de encapsulación).

Métodos: Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno, éstos pueden tener las características:

Privado (-): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden acceder). Protegido (#): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia). Público (+): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados.

Relaciones entre clases Existen tres relaciones diferentes entre clases Asociación, Agregación y Generalización. En las relaciones se habla de una clase destino y de una clase origen. La origen es desde la que se realiza la acción de relacionar. Es decir desde la que parte la flecha, la destino es la que recibe la flecha. Dependencia

Es una relación entre dos elementos, tal que un cambio en uno puede afectar al otro.

Asociación

Es una relación estructural que resume un conjunto de enlaces que son conexiones entre objetos.

Generalización

Es una relación en la que el elemento generalizado puede ser substituido por cualquiera de los elementos hijos, ya que comparten su estructura y comportamiento.

Asociación:

La asociación expresa una conexión bidireccional especifica que los objetos de una clase están relacionados con los elementos de otra clase. Se representa mediante una línea continua, que une las dos clases. Podemos indicar el nombre, multiplicidad en los extremos, su rol, y agregación.

La multiplicidad La siguiente tabla resume las más comunes. Hay que tener en cuenta que la multiplicidad se expresa “en el lado opuesto” de la relación y es el número de posibles instancias de una clase asociadas con una única instancia de la clase en el otro extremo.

1

Clase Exactamente uno

*

Clase Cero o más

O ..1

Clase Cero o uno

m..n

Clase Especificada numéricamente



58

Multiplicidad Significado 1 Una única instancia N / * N instancias 0..N / 0..* Entre ninguna y N instancias 1..N / 1..* Entre una y N instancias 0..1 Ninguna o una instancia N..M Entre N y M instancias

Rol Identificado como un nombre a los finales de la línea, describe la semántica de la relación en el sentido indicado. Cada asociación tiene dos roles; cada rol es una dirección en la asociación. El rol puede estar representado en el nombre de la clase.

Agregación :

Para modelar objetos complejos, no bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades: Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo"). Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

Un Ejemplo es el siguiente: En donde se destaca que: Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias). Cuando se destruye el Objeto Almacén también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados. La composición (por Valor) se destaca por un rombo relleno. La agregación (por Referencia) se destaca por un rombo transparente. La relación de agregación tiene cardinalidad o multiplicidad. Generalización: Relación entre clases y muestra que la subclase comparte la estructura o comportamiento definida en una o mas superclases.

En la relación de herencia, se presentan una o varias clases padre o superclase o madre, y una clase hija o subclase.



59

UNIDAD VI

IMPLEMENTACIÓN Y PRUEBA

En la transición de la implementación del sistema a su uso, es necesario considerar los siguientes aspectos: Documentación Uno de los productos fundamentales para un uso y un mantenimiento efectivos y eficientes de los sistemas programados son los manuales. Esta metodología incluye una etapa dedicada a esta actividad tan importante y hace hincapié para que en su elaboración se consideren el estilo de trabajo y las necesidades propias de los usuarios que utilizarán y mantendrán el sistema. Esta etapa se realiza al mismo tiempo que la de construcción. Los manuales, resultados de esta etapa, se elaboran a partir de las especificaciones de diseño, de los programas realizados y del análisis del estilo de trabajo y nivel de competencia de los usuarios y operadores de los sistemas. En la figura 6 se muestra el proceso de esta etapa. Transición La implantación de sistemas no necesariamente implica la sustitución total de los antiguos subsistemas y de sus bases de datos correspondientes. En ciertos casos, por razones operativas y/o económicas, los nuevos sistemas integran algunos de los antiguos; pero como quiera que sea, la introducción ya sea de un sistema completamente nuevo o un sistema que integra ya existentes implica un nuevo tipo de uso y de operación que deberá ser asimilado y aprendido por los usuarios y operadores. Por esta razón, el desarrollo de un sistema no se termina con su programación; antes de su liberación para su uso, se debe preveer un período de transición que deberá incluir la alimentación de la nuevas bases de datos, la capacitación de los usuarios y el desarrollo de pruebas. En esta metodología la transición conforma una de sus etapas y en ella se realizan se realizan todas las tareas necesarias para la implementación y proporciona un periodo inicial de soporte al sistema. La transición debe llevarse a cabo con una interrupción mínima de la organización, y debe dejar a los usuarios confiados y listos para explotar el nuevo sistema. El resultado final de esta etapa es un reporte que muestre que las pruebas fueron satisfactorias, en la figura siguiente se muestra el proceso de esta etapa. Producción Finalmente, en la etapa de producción se asegura que el sistema funcione correctamente en la mayoría de los casos, y con intervención mínima de los administradores del sistema. Para esto se realizan nuevas pruebas, se reevaluan los resultados y se hacen refinamientos del sistema, los cambios necesarios deberán ser introducidos sin afectar a los usuarios, y deberá conseguirse la máxima confianza de los usuarios. El resultado de esta etapa un sistema listo para su operación. Los diagramas que apoyan en la fase de implementación son los diagramas de Componentes y Despliegue. Diagrama de Componentes Definición: Un diagrama de componentes muestra un conjunto de componentes y sus relaciones de manera gráfica a través del uso de nodos y arcos entre estos. Un diagrama de componentes muestra la organización y las dependencias entre un conjunto de componentes. Para todo sistema OO se han de construir una serie de diagramas que modelan tanto la parte estática (diagrama de clases), como dinámica (diagramas de secuencia, colaboración, estados y de actividades), pero llegado el momento todo esto se debe materializar en un sistema implementado que utilizará partes ya implementadas de otros sistemas, todo esto es lo que pretendemos modelar con los diagramas de componentes. Normalmente los diagramas de componentes contienen:

• Componentes. • Interfaces. • Relaciones de dependencia, generalización, asociaciones y realización. • Paquetes o subsistemas. • Instancias de algunas clases.



60

Visto de otro modo un diagrama de componentes puede ser un tipo especial de diagrama de clases que se centra en los componentes físicos del sistema. Componente: Los componentes pertenecen al mundo físico, es decir, representan un bloque de construcción al modelar aspectos físicos de un sistema. Una característica básica de un componente es que:

“Debe definir una abstracción precisa con una interfaz bien definida, y permitiendo reemplazar fácilmente los componentes más viejos con otros más nuevos y compatibles”

En que consiste y que representa: En UML todos los elementos físicos se modelan como componentes. UML proporciona una representación gráfica para estos como se puede ver en la figura, en la que XXXX.dll, es el nombre del componente.

.

Cada componente debe tener un nombre que lo distinga de los demás. Al igual que las clases los componentes pueden enriquecerse con compartimentos adicionales que muestran sus detalles, como se puede ver en la siguiente figura .

Interfaces: Tanto los servicios propio de una clase como los de un componente, se especifican a través de una Interfaz. Por ejemplo, todas las facilidades más conocidas de los sistemas operativos, basados en componentes (COM+, CORBA, etc.), utilizan las interfaces como lazo de unión entre unos componentes y otros. La relación entre un componente y sus interfaces se puede representar de dos maneras diferentes, de forma icónica y de forma expandida.

Componentes e interfaces, formato icónico.

Componentes e interfaces, formato extendido. Tipos de componentes: Existen básicamente tres tipos de componentes: • Componentes de despliegue: componentes necesarios y suficientes para formar un sistema ejecutable,

como pueden ser las bibliotecas dinámicas (DLLs) y ejecutables (EXEs).

Representación de un componente

Representación extendida de un componente



61

• Componentes producto del trabajo: estos componentes son básicamente productos que quedan al final del proceso de desarrollo. Consisten en cosas como archivos de código fuente y de datos a partir de los cuales se crean los componentes de despliegue.

• Componentes de ejecución: son componentes que se crean como consecuencia de un sistema en ejecución. Es el caso de un objeto COM+ que se instancia a partir de una DLL.

Organización de componentes: Los componentes se pueden agrupar en paquetes de la misma forma que se organizan las clases. Además se pueden especificar entre ellos relaciones de dependencia, generalización, asociación (incluyendo agregación), y realización. Estereotipos de componentes: UML define cinco estereotipos estándar que se aplican a los componentes:

Executable, Componente que se puede ejecutar en un nodo. Library, Biblioteca de objetos estática o dinámica. Table, Componentes que representa una tabla de una base de datos. File, Componente que representa un documento que contiene código fuente o datos. Document, Componente que representa un documento. UML no especifica iconos predefinidos para estos estereotipos.

Nodos: Al igual que los componentes los nodos pertenecen al mundo material. Vamos a definir un nodo como un elemento físico, que existe en tiempo de ejecución y representa un recurso computacional que generalmente tiene alguna memoria y, a menudo, capacidad de procesamiento. Los nodos sirven para modelar la topología del hardware sobre el que se ejecuta el sistema. Un nodo representa normalmente un procesador o un dispositivo sobre el que se pueden desplegar los componentes. Un nodo debe tener un nombre asignado que lo distinga del resto de nodos. Además los nodos se representan gráficamente como se indica en la Figura 31. Nodos y componentes: En muchos aspectos los nodos y los componentes tienen características parecidas. Vamos a ver con más detalle cuales son los parecidos y las diferencias entre los componentes y los nodos.

PARECIDOS Ambos tienen nombre. Pueden participar en relaciones de dependencia, generalización y asociación. Ambos pueden anidarse. Ambos pueden tener instancias. Ambos pueden participar en interacciones.

DIFERENCIAS Nodos Componentes

Son los elementos donde se ejecutan los componentes. Representan el despliegue físico de los componentes.

Son los elementos que participan en la ejecución de un sistema. Representan el empaquetamiento físico de los elementos lógicos.

La relación entre un nodo y los componentes que despliega se pueden representar mediante una relación de dependencia como se indica en la figura .

Nodo



62

Relación entre nodos y componentes.

Los nodos se pueden agrupar en paquetes igual que los las clases y los componentes. Los tipos de relación más común entre nodos es la asociación. Una asociación entre nodos viene a representar una conexión física entre nodos.

Conexiones entre nodos.

Dependencias:

El diagrama de componentes se genera a partir de el diagrama de clases o también llamados paquetes, a partir de él tenemos el diagrama de componentes y el diagrama de despliegue en los cuales se mostrara la implementación del proyecto.

Diagrama De Despliegue Los Diagramas de Despliegue muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instancias de nodos conectados por enlaces de comunicación, también eses un grafo de nodos unidos por conexiones de comunicación. Los diagramas de despliegue muestran la configuración en funcionamiento del sistema, incluyendo su hardware y su software. Para cada componente de un diagrama de despliegue se deben documentar las características técnicas requeridas, el tráfico de red esperado, el tiempo de respuesta requerido, etc. La mayoría de las veces el modelado de la vista de despliegue estática implica modelar la topología del hardware sobre el que se ejecuta el sistema. Los diagramas de despliegue son fundamentalmente diagramas de clases que se ocupan de modelar los nodos de un sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificarla plataforma sobre la que se ejecuta el software del sistema y para que un ingeniero de sistemas pueda manejar la frontera entre el hardware y el software cuando se trata de la relación entre hardware y software se utilizan los diagramas de despliegue para razonar sobre la topología de procesadores y dispositivos sobre los que se ejecuta el software. Notación: El diagrame de despliegue es muy similar al de componentes por lo que también comparte la forma de notación que se ve a continuación:



63

El diagrama de despliegue :

• Describe la arquitectura física del sistema durante la ejecución, en términos de: – procesadores – dispositivos – componentes de software

• Describen la topología del sistema: la estructura de los elementos de hardware y el software que ejecuta cada uno de ellos.

Componentes :

• Los nodos son objetos físicos que existen en tiempo de ejecución, y que representan algún tipo de

recurso computacional (capacidad de memoria y procesamiento): – Computadores con procesadores – Otros dispositivos

• impresoras • lectoras de códigos de barras • dispositivos de comunicación

• Los nodos se conectan mediante asociaciones de comunicación. • Estas asociaciones indican:

– Algún tipo de ruta de comunicación entre los nodos – Los nodos intercambian objetos o envían mensajes a través de esta ruta

• El tipo de comunicación se identifica con un estereotipo que indica el protocolo de comunicación o la red.

Técnicas más comunes de modelado Los diagramas de despliegue muestran la configuración en funcionamiento del sistema, incluyendo su hardware y su software. Para cada componente de un diagrama de despliegue se deben documentar las características técnicas requeridas, el tráfico de red esperado, el tiempo de respuesta requerido, etc. La mayoría de las veces el modelado de la vista de despliegue estática implica modelar la topología del hardware sobre el que se ejecuta el sistema. Los diagramas de despliegue son fundamentalmente diagramas de clases que se ocupan de modelar los nodos de un sistema. Aunque UML no es un lenguaje

Transacciones Componente

Interfaz y su relación de realización

Relación de uso

Nodo físico

Enlace de comunicación entre nodos

Cliente:PC



64

de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para que un ingeniero software pueda especificarla plataforma sobre la que se ejecuta el software del sistema y para que un ingeniero de sistemas pueda manejar la frontera entre el hardware y el software cuando se trata de la relación entre hardware y software se utilizan los diagramas de despliegue para razonar sobre la topología de procesadores y dispositivos sobre los que se ejecuta el software. Esta vista cubre principalmente la distribución, entrega e instalación de las partes que configuran un sistema físico. Los diagramas de despliegue se suelen utilizar para modelar:

• Sistemas empotrados: Un sistema empotrado es un colección de hardware con una gran cantidad de software que interactúa con el mundo físico. Los sistemas empotrados involucran software que controla dispositivo (motores, actuadores) que a su ves están controlados por estímulos externos como censores.

• Sistemas cliente-servidor: Los sistemas cliente-servidor son un extremo del espectro de los sistemas distribuidos y requieren tomar decisiones sobre la conectividad de red de los clientes a los servidores y sobre la distribución física de los componentes software de los sistemas a través de nodos.

• Sistemas completamente distribuidos: En el otro extremo encontramos aquellos sistemas que son ampliamente o totalmente distribuidos y que normalmente incluyen varios niveles de servidores Tales sistemas contienen a menudo varias versiones de componentes software, alguno de los cuales pueden incluso migrar de un nodo a otro. El diseño de tales sistemas requiere tomar decisiones que permitan un cambio continuo de la topología del sistema.

Ejemplo: En un Sistema de Ventas de una empresa que cuenta con una sucursal remota, se utilizan 2 nodos que se conectan entre si a través de un enlace, cada nodo tiene sus respectivos componentes, en el nodo del servidor esta el componente transacción y en el nodo sucursal están los componentes consultas, reportes y ventas. El componente transacciones a través de la interfaz búsqueda hace una relación de uso con el componente de consultas y reportes, el cual se encarga de generar como dice el componente consultas y reportes de las transacciones que están almacenadas en el servidor, también vemos que transacciones a través de otra interfaz “actualizar transacciones” genera otra relación de uso con el componente Ventas el cual se encarga de actualizar las ventas que en las sucursales se realizan. En consecuencia se puede asegurar que el diagrama de despliegue ayuda al diseñador de sistemas a entender el funcionamiento de un sistema desde un punto de vista de hardware y software.

:Transacciones

Actualizar_transacciones

búsqueda

:Consultas /reportes

:Reservas

Servidor:ServidorCentral

Sucursal: sucursal remota



65

Prueba del sistema Esta fase, da inicio luego de que las diferentes unidades de diseño han sido desarrolladas y probadas por separado. Durante su desarrollo, el sistema se emplea de forma experimental para asegurar que el software no falle, es decir que funcione de acuerdo a sus especificaciones y a la manera que los usuarios esperan que lo haga, y de esta forma poder detectar cualquier anomalía, antes de que el sistema sea puesto en marcha y se dependa de él. Para evaluar el desenvolvimiento del sistema, en esta fase se llevan a cabo varios niveles de prueba: Si el Sistema cumple de forma satisfactoria con estos niveles mencionados anteriormente, se procede a realizar la carga de los archivos, base de datos y tablas del nuevo sistema, para de esta forma dar inicio al proceso de aceptación final, durante el cual, el sistema comenzará a funcionar bajo la responsabilidad del departamento de operaciones y del usuario, por un lapso determinado de tiempo llamado Periodo de Aceptación. Finalizado el Periodo de Aceptación, se le dará al sistema la aprobación final, para que pase a ser el sistema oficial. La prueba en un ciclo de desarrollo se incluye como un paso final, se recomienda como una actividad constante en los ciclos de desarrollo. No todas las pruebas mencionadas son adecuadas en los ciclos de desarrollo. Por ejemplo: las pruebas de integración del sistema entero pueden efectuarse con menor frecuencia en cada uno. Las pruebas que pueden realizarse son las siguientes:

• De Unidad: Se concentra en el esfuerzo de verificación de la unidad más pequeña del diseño del software: el componente o módulo del software. Las pruebas de unidad se concentran en la lógica del procesamiento interno. Este tipo de prueba se puede aplicar en paralelo a varios componentes.

• De Desempeño: Prueba desde el punto de vista de los requerimientos funcionales. La prueba de desempeño está diseñada para probar el desempeño del software en tiempo de ejecución dentro del contexto de un sistema integrado.

• De Sistema: Prueba desde el punto de vista de los niveles de calidad del sistema y de desempeño.

• De Integración: Prueba de interfaces. A menudo se tiende a intentar una integración que no sea incremental, se combinan todos los componentes por anticipado, se prueba todo el programa como un todo.

• De Aceptación Técnica: Prueba de manejo de condiciones extremas. El usuario comprueba en su propio entorno de explotación si lo acepta como está o no

• De documentación: Prueba de requisitos documentales que acompaña todo producto de software.



Diseño

3. Pruebas del sistema

5. Pruebas de aceptación 6. Pruebas de la documentación

1. Pruebas de unidad 2. Pruebas de integración

4. Pruebas de desempeño



66

Técnicas de Prueba del Software

1. Pruebas de Caja Negra y Caja Blanca 2. Pruebas de Caja Negra y Caja Blanca

Hay dos maneras de probar cualquier producto construido:

o 1. Si se conoce la función específica para la que se diseño el producto, se aplican pruebas, que demuestren que cada función es plenamente operacional, mientras se buscan los errores de cada función. (Prueba de Caja Negra)

o 2. Si se conoce el funcionamiento interno del producto, se aplican pruebas para asegurarse de que todas las “piezas encajan”, es decir, que las operaciones internas se realizan de acuerdo a las especificaciones, y que se han probado todos los componentes internos de manera adecuada. (Prueba de Caja Blanca)

3. Pruebas de Caja Negra y Caja Blanca o Las pruebas de caja negra son las que se aplican a la interfaz del software. o Una prueba de caja negra examina algún aspecto funcional de un sistema

que tiene poca relación con la estructura lógica interna del software. o La prueba de caja blanca del software se basa en un examen cercano al

detalle procedimental. En la prueba de caja blanca se prueban las rutas lógicas del software y la colaboración entre componentes, al proporcionar casos de prueba que ejerciten conjuntos específicos de condiciones, bucles o ambos.



67

LECTURAS COMPLEMENTARIAS A fin de complementar información referente a los temas propuestos para el presente documento se plantean las siguientes lecturas complementarias: 1. De la dirección electrónica: http://es.wikipedia.org/wiki/RUP

Proceso Unificado de Rational De Wikipedia, la enciclopedia libre

(Redirigido desde RUP) El Proceso Unificado Racional (Rational Unified Process en inglés, habitualmente resumido como RUP) es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al contexto y necesidades de cada organización. También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational Method Composer (RMC), que permite la personalización de acuerdo a necesidades. Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más detallada, el Rational Unified Process, que se vendiera como producto independiente

Contenidos

• 1 Principios de desarrollo o 1.1 Adaptar el proceso o 1.2 Balancear prioridades o 1.3 Demostrar valor iterativamente o 1.4 Elevar el nivel de abstracción o 1.5 Enfocarse en la calidad

• 2 Ciclo de vida • 3 Principales características • 4 Fases • 5 Un poco de historia • 6 Comentarios sobre Alcance del RUP • 7 Comentarios sobre Metodología • 8 Enlaces externos

Principios de desarrollo

El RUP está basado en 5 principios clave que son: Adaptar el proceso

El proceso deberá adaptarse a las características propias del proyecto u organización. El tamaño del mismo, así como su tipo o las regulaciones que lo condicionen, influirán en su diseño específico. También se deberá tener en cuenta el alcance del proyecto.

Balancear prioridades Los requerimientos de los diversos inversores pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.



68

Demostrar valor iterativamente Los proyectos se entregan, aunque sea de un modo interno, en etapas iteradas. En cada iteración se analiza la opinión de los inversores, la estabilidad y calidad del producto, y se refina la dirección del proyecto así como también los riesgos involucrados

Elevar el nivel de abstracción Este principio dominante motiva el uso de conceptos reutilizables tales como patrón del software, lenguajes 4GL o esquemas (frameworks) por nombrar algunos. Esto previene a los ingenieros de software ir directamente de los requisitos a la codificación de software a la medida del cliente. Un nivel alto de abstracción también permite discusiones sobre diversos niveles arquitectónicos. Éstos se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con UML. conforme

Enfocarse en la calidad El control de calidad no debe realizarse al final de cada iteración, sino en todos los aspectos de la producción. El aseguramiento de la calidad forma parte del proceso de desarrollo y no de un grupo independiente.

Ciclo de vida

Un típico perfil de proyecto mostrando el tamaño relativo de las cuatro fases

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones. El RUP divide el proceso de desarrollo en ciclos, teniendo un producto final al culminar cada una de ellos, estos a la vez se dividen en fases que finalizan con un hito donde se debe tomar una decisión importante: • Concepción: se hace un plan de fases, se identifican los principales casos de uso y se

identifican los riesgos • Elaboración: se hace un plan de proyecto, se completan los casos de uso y se eliminan los

riesgos • Construcción: se concentra en la elaboración de un producto totalmente operativo y

eficiente y el manual de usuario • Transición: se Instala el producto en el cliente y se entrena a los usuarios. Como

consecuencia de esto suelen surgir nuevos requisitos a ser analizados. • Mantenimiento: una vez instalado el producto, el usuario realiza requerimientos de ajuste,

esto se hace de acuerdo a solicitudes generadas como consecuencia del interactuar con el producto.

Principales características • Forma disciplinada de asignar tareas y responsabilidades (quién hace qué, cuándo y cómo) • Pretende implementar las mejores prácticas en Ingeniería de Software • Desarrollo iterativo • Administración de requisitos • Uso de arquitectura basada en componentes • Control de cambios • Modelado visual del software • Verificación de la calidad del software

El RUP es un producto de Rational (IBM). Se caracteriza por ser iterativo e incremental, estar centrado en la arquitectura y guiado por los casos de uso. Incluye artefactos (que son los



69

productos tangibles del proceso como por ejemplo, el modelo de casos de uso, el código fuente, etc.) y roles (papel que desempeña una persona en un determinado momento, una persona puede desempeñar distintos roles a lo largo del proceso)....

Fases • Establece oportunidad y alcance • Identifica las entidades externas o actores con las que se trata • Identifica los casos de uso

Un poco de historia Los orígenes de RUP se remontan al modelo espiral original de Barry Boehm. Ken Hartman, uno de los contribuidores claves de RUP colaboró con Boehm en la investigación. En 1995 Rational Software compró una compañía sueca llamada Objectory AB, fundada por Ivar Jacobson, famoso por haber incorporado los casos de uso a los métodos de desarrollo orientados a objetos. El Rational Unified Process fue el resultado de una convergencia de Rational Approach y Objectory (el proceso de la empresa Objectory AB). El primer resultado de esta fusión fue el Rational Objectory Process, la primera versión de RUP, fue puesta en el mercado en 1998, siendo el arquitecto en jefe Philippe Kruchten.

Comentarios sobre Alcance del RUP La metodología RUP es más apropiada para proyectos grandes, dado que requiere un equipo de trabajo capaz de administrar un proceso complejo en varias etapas. En proyectos pequeños, es posible que no sea posible cubrir los costos de dedicación del equipo de profesionales necesarios.

Comentarios sobre Metodología Por otro lado, en lo que se refiere a la metodología esta comprende tres frases claves: Dirigido por los casos de uso, centrado en la arquitectura, iterativo e incremental. En lo referente a dirigido por los casos de uso, está enfocado hacia el cliente y se utilizan con algunas modificaciones tal vez, hasta la fase de pruebas.

2. De la dirección electrónica: http://www.cs.ualberta.ca/~pfiguero/soo/uml/

Elementos notacionales de UML 1.0 Pablo Figueroa

Copyright Site Pablo Figueroa. 1.997. Versión 1.1

A Continuación se revisan en niveles de complejidad los diversos elementos notacionales que presenta el Unified Modeling Language. Estos elementos pretenden ser un lenguaje común para el modelamiento de cualquier sistema.

Esta descripción no pretende ser exhaustiva en términos sintácticos, semánticos y de presentación de los elementos de la notación. Debe entenderse como una guía inicial al tema. Los documentos que describen en detalle la notación pueden encontrarse aquí. Se agrupan los conceptos básicos por tipo de diagrama: 1. Diagrama de Estructura Estática 2. Diagrama de Casos de Uso 3. Diagrama de Secuencia 4. Diagrama de Colaboración 5. Diagrama de Estados 6. Diagrama de Actividades 7. Diagrama de Implementación

Los conceptos avanzados por tipo de diagrama son: 1. Diagrama de Estructura Estática 2. Diagrama de Secuencia



70

3. Diagrama de Colaboración 4. Diagrama de Estados

Elementos básicos en un diagrama de estructura estática Un diagrama de estructura estática muestra el conjunto de clases y objetos importantes que hacen parte de un sistema, junto con las relaciones existentes entre estas clases y objetos. Muestra de una manera estática la estructura de información del sistema y la visibilidad que tiene cada una de las clases, dada por sus relaciones con las demás en el modelo. Clase Representada por un rectángulo con tres divisiones internas, son los elementos fundamentales del diagrama.Una clase describe un conjunto de objetos con caracteristicas y comportamiento idéntico. En el ejemplo se encuentran las clases Ingrediente, Producto, Maquina, DepositoMonedas y DepositoMonedasIguales.

Los tres compartimientos estándares alojan el nombre de la clase, sus atributos y sus mensajes, respectivamente.

Atributo Identifican las características propias de cada clase. Generalmente son de tipos simples, ya que los atributos de tipos compuestos se representan mediante asociaciones de composición con otras clases. La sintáxis de un atributo es visibility name : type-expression = initial-value { property-string }

Donde visibility es uno de los siguientes: + public visibility # protected visibility - private visibility

type-expression es el tipo del atributo con nombre name. Puede especificarse como se ve un valor inicial y un conjunto de propiedades del atributo. En el caso del ejemplo, la clase Ingrediente tiene dos atributos: uno denominado cantidad, de tipo float y con valor inicial 0; y el atributo nombre de tipo string sin valor inicial. En este caso, la herramienta utilizada ha cambiado la representación de la visibilidad, utilizando el

símbolo para indicar visibilidad privada, el símbolo para visibilidad protegida y el

símbolo para indicar visibilidad pública. Operacion El conjunto de operaciones describen el comportamiento de los objetos de una clase. La síntaxis de una operación en UML es visibility name ( parameter-list ) : return-type-expression { property-string }

Cada uno de los parámetros en parameter-list se denota igual que un atributo. Los demás elementos son los mismos encontrados en la notación de un atributo.

Asociación (rol, multiplicidad, cualificador) Una asociación en general es una línea que une dos o más símbolos. Pueden tener varios tipos de adornos, que definen su semántica y características. Los tipos de asociaciones entre clases presentes en un diagrama estático son:

1. Asociación binaria 2. Asociación n-aria 3. Composición 4. Generalización 5. Refinamiento

Cada asociación puede presentar algunos elementos adicionales que dan detalle a la relación, como son:



71

Rol: Identificado como un nombres al los finales de la linea, describe la semántica de la relación en el sentido indicado. Por ejemplo, la asociación de composición entre Maquina e Ingrediente recibe el nombre de existencias, como rol en ese sentido Multiplicidad: Describe la cardinalidad de la relación. En el ejemplo anterior se utilizan 1, 1 ..*, 5, * , como indicadores de multiplicidad.

Asociación binaria Se identifica como una línea sólida que une dos clases. Representa una relación de algún tipo entre las dos clases, no muy fuerte ( es decir, no se exige dependencia existencial ni encapsulamiento).

En posible ejemplo es la relación entre una compañía y sus empleados

en este caso la relación recibe el nombre genérico Trabaja Para, la compañía tiene uno o más instancias de la clase Persona denominadas empleado y cada empleado conoce su empleador (en este caso único).

Composición Es una asociación fuerte, que implica tres cosas

• Dependiencia existencial. El elemento dependiente desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo.

• Hay una pertenencia fuerte. Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene

• Los objetos contenidos no son compartidos, esto es, no hacen parte del estado de otro objeto.

Se denota dibujando un rombo relleno del lado de la clase que contiene a la otra en la relación. En el ejemplo inicial de esta hoja se presentan varios ejemplos de relaciones de composición entre Maquina y Producto, Maquina y DepositoMonedas y Maquina y DepositoMonedasIguales.

Existe tambien una relación de composición menos fuerte (no se exige dependencia existencial, por ejemplo) que es denotada por una un rombo sin rellenar en uno de los extremos. Un ejemplo puede encontrarse entre Producto e Ingrediente.

Generalización La relación de generalización denota una relación de herencia entre clases. Se representa dibujando un triángulo sin rellenar en el lado de la superclase. La subclase hereda todos los atributos y mensajes descritos en la superclase. En el ejemplo se encuentra una generalización entre DepositoMonedas (superclase) y DepositoMonedasIguales (subclase). Clase paramétrica Una clase paramétrica representa el concepto de clase genérica en los conceptos básicos OO o de template en C++. Se dibuja como una clase acompañada de un rectángulo en la esquina superior derecha, con los parámetros del caso.

Por ejemplo, la clase Lista que utiliza un parámetro formal Tipo se vería de la siguiente manera

Paquete Un paquete es una forma de agrupar clases (u otros elementos en otro tipo de diagramas) en modelos grandes. Pueden tener asociaciones de dependencia o de generalización entre ellos. Un ejemplo puede ser el siguiente



72

En este caso existen tres paquetes (que se muestran vacios en este caso, con su contenido encapsulado), con dos de ellos dependiendo del Modelo del Mundo

Dependencia Denota una relación semántica entre dos elementos (clases o paquetes, por el momento) del modelo. Indica que cambiar el elemento independiente puede requerir cambios en los dependientes. Se muestra como una linea punteada direccional, indicando el sentido de la dependencia. Puede tener por medio de estereotipos una explicación del tipo de dependencia presentada.

En el ejemplo anterior pueden verse dos relaciones de dependencia hacia el paquete Modelo del Mundo.

Nota Es un comentario dentro de un diagrama. Puede estar relacionado con uno o más elementos en el diagrama mediante lineas punteadas. Pueden representar aclaraciones al diagrama o restricciones sobre los elementos relacionados (cuando el texto se encuentra entre '['y ']'). Se representa mediante un rectángulo con su borde superior derecho doblado.

En el ejemplo inicial de esta hoja se encuentran dos notas: Una relacionada con la clase máquina y otra con el depósito de monedas iguales.

Conceptos avanzados en un Diagrama de Secuencia Tiempos de transición En un ambiente de objetos concurrentes o de demoras en la recepción de mensajes, es útil agregar nombres a los tiempos de salida y llegada de mensajes. Analizando la recepción de una llamada telefónica puede tenerse un diagrama como el siguiente:

En este diagrama se tienen tres objetos concurrentes, el que hace la llamada, la central telefónica y el que recibe la llamada. se nombran los tiempos de los mensajes que envía o recibe el caller (a para descolgar, b para el tono de la llamada, c para la marcación, d para el inicio del enrutamiento de la llamada, d' para la finalización del enrutamiento). Estos nombres o tiempos de transición permiten describir restricciones de tiempo ( por ejemplo b-a



73

< 1sec. ) o demoras entre el envío y la recepción (entre d y d'). Condiciones caminos alternativos de ejecución. Concurrencia En algunos casos sencillos pueden expresarse en un diagrama de secuencia alternativas de ejecución. Estas alternativas pueden representar condiciones en la ejecución o diferentes hilos de ejecución (threads).

En el diagrama anterior se muestran dos casos. ob1 muestra una condición al enviar un mensaje a ob3 o a ob2, dependiendo de si x>0 o x<0. Estas dos líneas de ejecución se vuelven a unir más adelante, indicando el fin del condicional. Por otra parte ob4 muestra dos posibles operaciones dependiendo de si se siguió la condición x>0 o x<0. Ya que se presentan en el mismo instante de tiempo, se requiere dividir la linea del objeto en dos (esta misma representación se utiliza para el caso de dos hilos de ejecución).

Destrucción de un objeto Se representa como una X al final de la línea de ejecución del objeto. Por ejemplo, en el diagrama anterior se muestra el final de ob2 y de ob1. Métodos recursivos Un ejemplo de un método recursivo es el método more en ob1. Es un rectángulo un poco salido de la activación principal y con líneas de llamado de mensajes, que indican la entrada y salida de la recursión. 3. De la dirección electrónica: http://www.postgresql.cl/articulos/gmo_najar.htm

Modelado Orientado a Objetos, de Base de Datos. por Guillermo Najar Arreola .

Ingeniero en Sistemas Computacionales GNsis, Asesoria en Sistemas de Informacion, Guadalajara, Mexico

Como ingenieros en sistemas, programadores, analistas, informáticos, o cualquier titulo nobiliario profesional que tengamos, pero que implique que nos tengamos que relacionar en



74

algún momento de nuestras vidas con el diseño de Bases de Datos, nos hemos topado eventualmente con la disyuntiva de qué campos poner en qué tablas, especialmente si se trata de más de una tabla y aún más, si están relacionadas. En la escuela, cuando éramos pequeños, nos hablaron de la normalización, de las anomalías de actualización que se presentan en la base de datos cuando el diseño no está completamente normalizado... y eso deja de ser teoría cuando de repente nos ganamos la rifa del tigre y nos toca darle mantenimiento a un sistema cuya base de datos es un caos, sufriendo en carne propia no solo el darle mantenimiento a la base de datos, sino a los programas que leen y escriben en ella. Creo estaremos de acuerdo que, entre más correcto sea el diseño de la Base de Datos, más sencillo será su mantenimiento, y el de las aplicaciones que la usan directamente. Cuando entré al quinto semestre de la carrera de Ingeniería en Sistemas Computacionales, en la Universidad ITESO de México, tuve la fortuna de que el profesor que habían contratado para la materia de Bases de Datos, acababa de llegar de su maestría en la Universidad de Seattle, en Estados Unidos. A su vez, el tuvo como maestro al Doctor David M. Kroenke, autor del libro “Database Processing: Fundamentals, Design, and Implementation” (Prentice Hall) que fue nuestro libro de texto en aquel entonces, y he seguido usando en mis cursos de bases de datos. Fue en esa clase que nos introdujeron a la metodología de modelado lógico llamada Semantic Object Model (SOM).

Antecedentes Al menos para este artículo, acordemos que hay cuatro fases para tener una Base de Datos materializada: 1. Modelado 2. Diseño Lógico 3. Diseño Físico 4. Construcción

El Modelado es la etapa en donde identificamos y “dibujamos” los conjuntos de datos que el Usuario requiere en un Sistema de información. El Diseño Lógico es la etapa donde transformamos ese modelo en un diseño relacional (asumiendo que es el más utilizado), independiente de la herramienta (DBMS) que vayamos a utilizar. El Diseño Físico es aquel en donde especificamos características propias del DBMS elegido, como tipos de dato concretos, parámetros por cada tabla, campo, relación, etc. Y la construcción, es en si el proceso de capturar los “metadatos” o datos sobre datos para materializar el diseño relacional dentro de nuestro DBMS, quizá usando scripts SQL. Generalmente se usa el modelo de Entidad-Relación para el modelado y diseño lógico de bases de datos, en donde a través del reconocimiento de entidades débiles, entidades fuertes, relaciones entre entidades y su semántica vamos armando la red de la base de datos, para después con algunas reglas, llegar en pocos pasos al diseño lógico. De hecho las herramientas gráficas de diseño de Base de Datos que conozco, en su mayoría usan algún “sabor” o variante del modelado Entidad-Relación para elaborar el diseño lógico. El Modelado SOM El modelo SOM, o modelado de Objetos como aquí le llamaremos, permite ilustrar a la base de datos en términos de Objetos de negocio, y no directamente en tablas. Bajo la metodología SOM, una entidad es cualquier cosa, concreta o abstracta, con un infinito número de propiedades o características que la describen. Por ejemplo, un auto tiene modelo, número de neumáticos, tipo de bencina que utiliza, capacidad del tanque de aceite, potencia del motor, peso molecular, capacidad de reflejo de rayos UV según la pintura del fabricante, y así, podemos tardarnos un buen tiempo describiendo las características del auto. Sin embargo, dependiendo del cliente o usuario al que estemos sirviendo en cuestiones de informática, cada empresa, persona, departamento, institución, compañía, tendrá necesidades distintas y únicas



75

en el conjunto de propiedades o características que desean reunir para una entidad en particular. De acuerdo entonces a Kroenke *, al “conjunto nombrado de propiedades que suficientemente describen una entidad en el ambiente de trabajo del usuario”, ese es un Objeto Semántico. Siguiendo con el ejemplo anterior, a un vendedor de autos usados le interesará conocer datos, como: • Número de Serie • Marca • Sub-marca • Modelo • Kilometraje • Estado del auto • Precio mínimo • Precio máximo • Precio final de venta • Fecha inicial de venta • Fecha de venta

A un técnico de agencia, al que le han llevado ese auto, le podrá interesar: • Cliente • Marca • Sub-marca • Modelo • Kilometraje • Placas actuales del vehículo • Número de serie • Reporte de fallas • Costo en refacciones • Costo de mano de obra • Fecha de entrada al taller • Fecha de salida • Control de Calidad del Servicio

Como vemos, dependiendo de la realidad en donde operará el sistema que estamos analizando, puede haber diferentes “vistas” o perspectivas de la realidad del mismo Objeto. Ahora, el modelar un Objeto implica seguir una simbología para diagramarlos; esta simbología ha evolucionado desde la primera edición del libro de Kroenke, allá por 1987, hasta la actual novena edición (a la fecha en que se escribe este artículo). Para el vendedor, el Objeto AUTO se modelaría del siguiente modo:

En este diagrama podemos ver varios elementos: 1. La propiedad “Número de Serie” está prefijada con “ID” que significa que esta propiedad

identifica a un caso particular del Objeto; en este caso, el “Número de Serie” es la propiedad que identifica a un AUTO en particular.



76

1.1. Nótese el término formal “propiedad”, que se usa bajo SOM para identificar una característica del Objeto que nos interesa considerar.

2. En cada propiedad hay un subíndice tipo “0.1” o “1.1”; esta es la llamada cardinalidad que indica el mínimo y máximo número de valores que la propiedad puede tomar. 2.1. Por ejemplo, nótese que “Precio Máximo” tiene una cardinalidad de “0.1”; esto significa la propiedad puede no tener un valor (0), y máximo 1. 2.2. “Número de Serie” tiene una cardinalidad de “1.1”, lo cual indica que debe haber un valor almacenado, pero no más de uno; se trata entonces de una propiedad en que es obligatorio capturar un valor. 2.3. Si tuviéramos una propiedad con cardinalidad “0.N” o “1.N” significa que pueden almacenarse N valores para esa propiedad. Más adelante veremos un ejemplo con un caso como este. 2.4. Pueden darse cardinalidades como “1.3, 2.5, 0.30”, dependiendo de las reglas del negocio en torno al Objeto.

3. Podemos observar que las propiedades se nombran de manera clara y explícita en lenguaje natural, describiendo de manera concisa lo que la propiedad contiene y significa. 3.1. No es como en campos o variables, que en ocasiones abreviamos o hacemos algo corto su nombre por restricciones del lenguaje o DBMS, o simplemente por costumbre o estándares.

Identificación y definición de Objetos

En el proceso de Ingeniería de Requerimientos, es labor del analista formar los objetos y recabar la mayor cantidad posible de propiedades requeridas por el usuario para administrar el Objeto dentro del Sistema. Por ello es importante reconocer estos objetos en sesiones de trabajo con los usuarios, en documentos, pantallas de sistemas actuales, y cualquier fuente disponible que describa las operaciones de negocio. Es importante entonces contar con la habilidad del Ingeniero de Requerimientos para poder identificar estos Objetos, cuya información generalmente está dispersa en distintas fuentes y áreas de la organización; esta habilidad se refuerza con la práctica y gusto por el análisis e investigación para ir formando la “fotografía” del negocio y sus operaciones. La definición completa y correcta de objetos es un proceso evolutivo y de refinación, y no necesariamente se logra de un momento a otro. Es responsabilidad del Analista el encontrar, diseñar y expresar correctamente todos los Objetos que se requieran, según el alcance del Análisis, y responsabilidad del Usuario el validar que ésta información es correcta y modela efectivamente la realidad del negocio. El siguiente es un ejemplo en el que podemos observar como, a partir de un documento, emerge un Objeto. En base a la factura anexa, el Analista se lanza a la aventura de identificar Objetos Semánticos en el documento; veamos como se da este proceso en un dialogo con el Usuario, y a veces diálogos internos del Analista consigo mismo: 1. El Analista reflexiona: “Mmm !! al parecer este documento es un Objeto, ya que es una

entidad que el usuario requiere controlar y existe por si mismo: se llevan controles de Facturas, se crean, se eliminan, se reportan y hay reglas de negocio específicas en torno a ella... parece que entonces hablamos del Objeto FACTURA”, y lo ponemos en mayúsculas para seguir la nomenclatura formal de SOM.

2. Analista: “Señora/Señor Usuario; puede decirme usted si en el registro de sus facturas en el sistema puede repetirse el mismo proveedor para varias facturas?”

3. Usuario: “Si Ingeniero; puede darse ese caso”



77

4. Analista: “Acaso se requiere llevar controles por proveedor, estadísticas, reportes de Facturas por proveedor ?”

5. Usuario: “Si; de hecho mensualmente emitimos reportes de compras según proveedor.” 6. Analista: “OK !! Y supongo que en su momento requieren obtener datos específicos del

proveedor como datos de contacto, etc.” 7. Usuario: “Exacto!!” 8. Analista: “Interesante ...” 9. Y el Analista se dice a si mismo: “De seguro el PROVEEDOR es un Objeto, que se

relaciona con el Objeto FACTURA”, por lo que PROVEEDOR y FACTURA ya hay que escribirlos en mayúsculas, según la notación formal de SOM.

10. Analista: “Entonces, un PROVEEDOR puede tener asociadas muchas FACTURAS?” 11. Usuario: “Si, asi es” 12. Analista: “Y una FACTURA puede estar asociada a más de un PROVEEDOR”? 13. Usuario: “No” 14. El Analista se dice a si mismo nuevamente: “Entonces ya encontré la cardinalidad de las

propiedades PROVEEDOR y FACTURA en los respectivos Objetos; ya se como se relacionan entre si”

Y para no hacer larga la historia, el Analista, perspicaz, encuentra que los materiales o productos en la FACTURA (sus renglones) se da algo similar, por lo que después de diálogos internos, diálogos con el usuario y análisis de otros documentos llega a la conclusión de que MATERIAL es otro Objeto. Analizando el resto del documento se aprecia que, al parecer, cada partida o renglón no puede ser un Objeto individual dado cada uno de ellos no tendría sentido sin su pertenencia a una FACTURA. Es un caso típico en donde “el nudo no puede existir sin la corbata”; el nudo no puede ser un Objeto individual ya que no tiene sentido su existencia, aislado de la corbata. Así sucede con la partida de FACTURA ¡ Interesante !....y hasta levantamos la ceja al estilo Mr Spock. Por lo tanto, del caos surge la armonía:

Algunas anotaciones sobre el anterior modelado: 1. Nótese que se incluyen las llamadas propiedades “Grupo”, como “Domicilio” en

PROVEEDOR, o “Partidas” en FACTURA



78

1.1. Estas propiedades Grupo tienen el propósito de agrupar un conjunto de propiedades por que en conjunto forman un “órgano” del Objeto; hablan de un tema en particular del mismo. 1.2. En el caso de “Domicilio”, agrupamos propiedades que informan sobre el domicilio del PROVEEDOR, y en su momento estas propiedades podrían aparecen en un recuadro de la ventana de la aplicación o módulo, que da mantenimiento al PROVEEDOR dentro del Sistema. 1.3. Las “Partidas” son el grupo de propiedades que forman un renglón o una partida dentro de la Factura; y como vemos que puede haber varias partidas, entonces la cardinalidad del grupo es “0.N” 2. Se incluye el concepto de propiedad Objeto, que es la propiedad dentro de un Objeto que

establece la relación con otro. Podemos ver cómo en MATERIAL, se indica que un MATERIAL en particular, puede estar asociado a ninguna o a varias FACTURAS; esto, por la cardinalidad “0.N” de la propiedad objeto FACTURA en MATERIAL.

2.1.1. Hemos encontrado entonces varios tipos de propiedad:

2.1.1.1. Propiedad Objeto: establece la relación con otro objeto. 2.1.1.2. Propiedad Grupo: agrupa un conjunto de propiedades. 2.1.1.3. Propiedad Simple: toda aquella propiedad que no es ni Objeto ni Grupo.

Además, si pusimos la propiedad FACTURA en MATERIAL es obligatorio poner la propiedad MATERIAL en FACTURA, de manera “bi-direccional” y con la cardinalidad correcta. En este caso, y según el documento ejemplo , es dentro del grupo “Partidas” en la FACTURA que se registra el MATERIAL, y debe haber al menos uno registrado (y solo uno) en cada partida de la FACTURA. De manera similar, podemos ver como se entabla la relación entre FACTURA y PROVEEDOR a través de las propiedades Objeto indicadas y sus cardinalidades.

Es importante hacer énfasis en que el proceso de modelado de objetos, es evolutivo e implica tiempo, esfuerzo y un buen análisis de las fuentes de información disponibles para llegar a un modelado correcto, que sea validado por el usuario. Por experiencia propia, el usuario comprende los objetos en su representación, sin necesidad de un curso introductorio a Bases de Datos o a teoría relacionada con SOM; el presentar objetos semánticos es más claro para el usuario y para el equipo de desarrollo del sistema, que presentar un diseño lógico de base de datos.

¿ Y luego ? Kroenke sostiene que si se ha logrado un diseño correcto de Objetos Semánticos de acuerdo a la realidad del contexto de negocio, podemos llegar a un diseño lógico de Bases de Datos en la forma normal Domain/Key (DKNF), ausente de anomalías de actualización. Estas reglas y su explicación van más allá del alcance de este artículo; se trata de reglas relativamente sencillas y después de algunos ejercicios, se adquieren herramientas teóricas básicas que permiten transformar cualquier volumen de objetos a un diseño lógico de bases de datos limpio y normalizado, de manera prácticamente automática.

Herramientas disponibles

Los diagramas de objetos que aquí he expuesto, se elaboraron con una herramienta de versión académica llamada “Salsa”, que se obsequiaba en la compra de la 5ª edición del texto de Kroenke, antes mencionado. En la edición actual del libro este software ya no se distribuye, pero hay un producto llamado Table Designer (www.tabledesigner.com) del cual se puede



79

obtener una versión de evaluación que permite el modelado SOM y genera automáticamente la correspondiente base de datos para tristemente solo dos productos, y ambos de Microsoft. He visto en Internet sitios de universidades en donde se imparte esta metodología, pero no he encontrado otras herramientas que la exploten y automaticen. Al parecer el modelado ER se ha vuelto más popular y ciertamente el más acudido por software para diseño de base de datos, y sin querer ir contra la corriente, puedo decir que lo más popular y difundido no necesariamente es lo mejor.

Observaciones

He utilizado por 14 años aproximadamente este modelado, y mi experiencia ha sido satisfactoria; en lo personal me ha funcionado bastante bien y la he incorporado como parte de metodologías para el modelado de sistemas de información, administración de proyectos de software, control de calidad y administración de soporte de sistemas. Algunas ventajas que he podido observar, son: 1. El comenzar por el modelado SOM, me permite comprender de mejor manera el negocio

del usuario sin involucrarme desde el principio con tablas y campos. 2. Establece un lenguaje de enlace para expresar el modelado de datos entre analistas,

usuarios, programadores y en general, personas involucradas en un proyecto de desarrollo. 3. Permite llegar de manera guiada y prácticamente automática, a un diseño de base de datos

correcto y normalizado (siempre y cuando la definición de objetos sea correcta de acuerdo a la realidad de negocio).

4. Facilita la comprensión y organización de un sistema de información, en términos de objetos.

5. Facilita documentar las reglas de negocio, si las organizamos y agrupamos en torno a los objetos con los que se relacionan.

Algunas desventajas: 1. No hay variedad de software que permitan el modelado y después su alimentación a DBMS

diversos. 2. La desventaja anterior, obliga a usar herramientas no integradas; es decir, primero diseñar

SOM en Salsa, por ejemplo, y después elaborar manualmente el diseño derivado de los objetos en otra herramienta , o a emular representación de Objetos semánticos bajo ER en diseñadores de tablas.

Puedo decir que, aun con las desventajas mencionadas, siempre vale la pena usar SOM al menos en el modelado inicial de Base de Datos, para después continuar su mantenimiento en herramientas que incorporen el modelo ER; en estas últimas pueden crearse “vistas” o ventanas de la base de datos en donde cada vista sea el conjunto de tablas de un solo Objeto Semántico, y así poder ver al Sistema en términos de objetos en el resto de su vida útil.



80

BIBLIOGRAFÍA Ivar Jacobson, Grady Booch, James Rumbaugh “El proceso unificado de desarrollo de software” Madrid, Addison Wesley, 1997 Grady Booch “Análisis y diseño Orientado a Objetos” México, Prentice Hall, 1997 James Rumbaugh, Michael Bola “Modelado y diseño Orientado a Objetos” México, Prentice Hall, 1991 Craig Larman “UML y Patrones” México, Prentice Hall, 1999 Direcciones de Internet: http://www.cs.ualberta.ca/~pfiguero/soo/uml/ http://www.dcc.uchile.cl/~psalinas/uml/introduccion.html http://www.dsic.upv.es/~uml/ http://www.clikear.com/manuales/uml/index.aspx http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado http://es.wikipedia.org/wiki/RUP http://www.vico.org/aRecursosPrivats/TRAD_introUML.pdf http://www.willydev.net/descargas/articulos/general/cualxpfddrup.PDF http://www.dcc.uchile.cl/~luguerre/cc61j/recursos/clase2.ppt#264,14,Diapositiva%2014 http://es.wordpress.com/tag/rup/



81

GLOSARIO Árbol de Problemas Un árbol de problemas es una técnica para identificar todos los problemas vinculados con una situación dada en un formato de dependencia y/o relación entre ellos Árbol de objetivos Un árbol de objetivos representa gráficamente los objetivos que tiene un proyecto en una serie de niveles jerárquicos. Los árboles de objetivos suponen que las conexiones de causa/efecto o de medios/fines enlazan los objetivos del proyecto. Proceso Describe de comienzo a fin una secuencia de eventos, de acciones o transacciones que se requieren para producir u obtener algo de valor para una empresa o actor. Se describe en un caso de uso Planeación y elaboración Definir los requerimientos, construir prototipos, etc. Construcción Creación del sistema Aplicación Se denomina a la transición de la implementación del sistema a su uso. Prototipo Versión del sistema cuyo fin es facilitar la comprensión del problema, los problemas de riesgo y los requerimientos. RUP RUP es un producto comercial desarrollado y comercializado por Rational Software, compañía de IBM. Modelo de análisis Es el que se relaciona con una investigación del dominio y del ámbito del problema, pero no con la solución. Modelo de diseño Es el que se relaciona con la solución lógica Modelo conceptual Es el artefacto más importante de esta fase, es una representación de conceptos en un dominio del problema ( no son entidades de software). Un modelo conceptual representa: Conceptos, asociaciones entre conceptos y atributos de conceptos. Un modelo muestra conceptos del mundo real no muestra los artefactos o clases de software Concepto Es una idea, cosa u objeto. Asociación. Es una relación entre dos conceptos que indica alguna conexión significativa e interesante entre ellos. Actor Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema participando (y normalmente iniciando) en un caso de uso. Los actores pueden ser gente real (por ejemplo, usuarios del



82

sistema), otros ordenadores o eventos externos. Caso de uso Son descripciones de procesos, son reseñas textuales del proceso. Normalmente tienen el formato de una nota o un documento relacionado de alguna manera con el caso de uso, y explica los procesos o actividades que tienen lugar en el caso de uso Nodo Un nodo es un objeto físico en tiempo de ejecución que representa un recurso computacional, generalmente con memoria y capacidad de procesamiento. Pueden representarse instancias o tipos de nodos. Se representa como un cubo 3D en los diagramas de implementación. Componente Es una parte física reemplazable de un sistema que empaqueta su implementación y es conforme a un conjunto de interfaces a las que proporciona su realización. Algunos componentes tienen identidad y pueden poseer entidades físicas, que incluyen objetos en tiempo de ejecución, documentos, bases de datos, etc. Los componentes existentes en el dominio de la implementación son unidades físicas en los computadores que se pueden conectar con otros componentes, sustituir, trasladar, archivar,etc. Identidad Un componente tiene identidad tiene identidad y estado. Posee los objetos físicos que están situados en él. Puede tener atributos, relaciones de composición con los objetos poseídos, y asociaciones con otros componentes. Desde este punto de vista es una clase. Sin embargo la totalidad de su estado debe hacer referencia a las instancias que contiene. Estado Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto está esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos. Subestado Un estado puede descomponerse en subestados, con transiciones entre ellos y conexiones al nivel superior. Las conexiones se ven al nivel inferior como estados de inicio o fin, los cuales se suponen conectados a las entradas y salidas del nivel inmediatamente superior. Evento Es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Transición Una transición ocurre cuando se lleva acabo el cambio de una actividad a otra, la transición es representada simplemente por una línea con una flecha en su terminación para indicar dirección. Ramificación Una ramificación ocurre cuando existe la posibilidad que ocurra más de una transición (resultado) al terminar determinada actividad. Este elemento es representado a través de un rombo Transición simple Una transición simple es una relación entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Transición interna Es una transición que permanece en el mismo estado, en vez de involucrar dos estados distintos. Representa un evento que no causa cambio de estado. Se denota como una cadena adicional en el compartimiento de acciones del estado.



83

Transacción Compleja Una transición compleja relaciona tres o más estados en una transición de múltiples fuentes y/o múltiples destinos. Representa la subdivisión en threads del control del objeto o una sincronización. Se representa como una línea vertical de la cual salen o entran varias líneas de transición de estado. Clase Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.). Atributo Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno Método Los métodos u operaciones de una clase son la forma en como ésta interactúa con su entorno Patrón En la terminología de objetos, el patrón es una descripción de de un problema y su solución que recibe un nombre y que puede emplearse en otros contextos; en teoría indica la manera de utilizarlo en circunstancias diversas

UNIVERSIDAD SALESIANA DE BOLIVIAvirtual.usalesiana.edu.bo/web/contenido/dossier/22012/1869.pdf ·...

Documents

Transcript of UNIVERSIDAD SALESIANA DE BOLIVIAvirtual.usalesiana.edu.bo/web/contenido/dossier/22012/1869.pdf ·...