Analisis y Diseño de Sistem as - Senati

SERVICIO NACIONAL DE ADIESTRAMIENTO EN TRABAJO INDUSTRIAL

DESARROLLO DE SOFTWARE

MANUAL DE APRENDIZAJE

ANÁLISIS Y DISEÑO DE SISTEMAS

CÓDIGO: 89001638 Profesional Técnico


TAREA 01: ENTENDER LA CONCEPTUALIZACIÓN DE UN SISTEMA, SISTEMA DE INFORMACIÓN. En esta tarea trataremos las siguientes operaciones:  Entender los conceptos de elementos o componentes de un sistema.  Reconocer las características de los sistemas y los tipos de sistemas.

EQUIPOS Y MATERIALES:

 Computadora con microprocesadores core 2 Duo o de mayor capacidad.  Sistema operativo Windows y la aplicación de Wampserver.  Acceso a internet. OPERACIÓN: Instalación de Rational Rose Enterprise. La aplicación de Rational Rose Enterprise es un software desarrollado por IBM que tiene como finalidad brindar una herramienta y un lenguaje de modelado común para simplificar el entorno de trabajo y permitir una creación más rápida de software de calidad, lo que las organizaciones necesitan actualmente. 1. Ingresar a la carpeta que contiene los archivos de instalación, por lo general recibe el nombre de Rational Rose Enterprise 20017. 2. Ubique el archivo que inicia la instalación y haga doble clic Setup.exe. 3. Haga clic en la opción Install IBM Rational Rose Enterprise Edition.

Haga clic en la opción Install IBM Rational Rose Enterprise Edition.

4. Se muestra la pantalla de bienvenida, haga clic en el botón Siguiente. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

5


5. Seleccione la opción Desktop installation fron CD imagem y luego haga clic en el botón Siguiente.

6. En el siguiente pantallazo haga clic en Next, y se mostrará un mensaje de advertencia para la instalación. Se recomiendo desactivar el antivirus para realizar la instalación.

ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

6


Haga clic en el botón Next.

7. Se mostrará la licencia. Haga clic en el botón Aceptar. 8. Seleccione la ubicación de los archivos de instalación y haga clic en botón Next 9. Elija la opción Rose Ada Addin y luego haga clic en la segundo opción.

10. Haga clic en Next y por último en el botón Install. 11. Activar la opción Import a Rational License File y haga clic en Siguiente.


7


12. Haga clic en Browser para seleccionar el archivo de la licencia. 13. Pantalla de inicio del Rational Rose.

Interfaz de Rational Rose. 1. Ingrese a la aplicación Rational Rose. 2. En la primera pantalla haga clic en el botón Cancel. La primera pantalla tiene la típica estructura de una venta de Microsoft Windows.


8

ANÁLISIS Y DISEÑO DE SISTEMAS Barra de Titulo.

Barra de Menús. Barra de Herramientas Estandar.

Barra de Herramientas Área de

de Diagramas

Navegación.

Ventana de diagrama.

Área de Documentación.

Área de Registro.

¿Qué sub-elementos se encuentra en el elemento Use Case View?

Instalación de ArgoUML. ArgoUML es una aplicación que cumple con todas la características de ser un software Open Source, publicado bajo la licencia de BSD, dicha aplicación se ha terminado por convertir en una herramienta necesaria cuando elaboración de software se trata, básicamente fortaleciendo los puntos de análisis, es por eso que se suele decir que con la aplicación se ha llegado al cambio en los procesos involucrados en el ciclo de vida de desarrollo de software. 1. Ingrese a la siguiente dirección web. http://argouml.tigris.org/. 2. Haga clic en la opción Dowload para Windows.


9


3. Luego de generar la descarga. Haga doble clic en el archivo de instalación. ArgoUML-0.34-setup.exe. 4. Seleccione el idioma Español y luego haga clic en el botón Ok.

5. Se mostrará la pantalla de bienvenida. Haga clic en Siguiente. 6. Seleccione los componentes con los cuales trabajara el ArgoUML, para este caso, active las dos opciones mostradas en la ventana. Y luego haga clic en Siguiente.

Activar los dos componentes.

7. Elija el lugar de instalación y luego haga clic en siguiente. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

10


8. Defina la carpeta del menú inicio y haga clic en Instalar.

Asistente de configuración de ArgoUML. 1. Ingrese a la aplicación ArgoUML. 2. Haga clic en el menú Editar y luego en la opción Configuración.

Instalación de StarUML. 1. Ingrese a la siguiente dirección web http://staruml.sourceforge.net/en/. 2. Haga clic en la opción Downloads.


11


3. Haga doble clic en el icono staruml-5.0-with-cm, para iniciar la instalación. 4. En la pantalla de bienvenida elegir el botón Next, luego acepte la licencia para la aplicación. 5. Haga doble clic en el acceso directo StarUML, para iniciar la aplicación. 6. Ubicar el cursos del mouse en el área de exploración de modelos y haga clic en el botón + de la opción DeploymentModel y luego doble clic en la opción Main.

Haga doble clic en la opción Main.

Procedimiento para crear nuevo proyecto: 1. Ingrese a la aplicación StarUML 2. Seleccione el menú File y luego la opción New Project. Un nuevo proyecto se crea con el seleccionado por el usuario dependiendo de los perfiles o marcos pueden ser incluidos.


12


Haga clic en la opción New Project.

Opciones para administrar el Proyecto

¿Qué otras opciones tiene el Menú File y cuáles son sus combinaciones de tecla? N

Opción

Combinación de teclas

1

New Project

Ctrl + N

2

New Project Approach

Ctrl + I

3 4 5 6 7 8 9 10 11 12 13 14 Procedimiento para crear nuevo proyecto de la selección de la caja de diálogo. 1. Ingrese a la aplicación StarUML 2. Una lista de los enfoques disponibles se mostrará en el cuadro de diálogo Seleccionar Nuevo proyecto.


13


Seleccione uno de la lista y haga clic en el botón OK.

3. Un nuevo proyecto se crea y se inicializa según el enfoque seleccionado.

Procedimiento para la apertura de un Proyecto. 1. Ingrese a la aplicación StarUML. 2. Seleccione el menú File y luego la opción Open. 3. En el cuadro de diálogo Abrir proyecto, seleccione un archivo de proyecto y haga clic en el botón Abrir. El archivo de proyecto seleccionado se abrirá.

Procedimiento para guardar el proyecto: 1. Ingrese a la aplicación StarUML. 2. Seleccione el menú File y luego la opción Save as. 3. Si no se ha especificado el nombre de archivo de proyecto, aparecerá el cuadro de diálogo Guardar proyecto, e ingrese el nombre de archivo y haga clic en el botón Guardar.

Importancia de un Framework. 1. Ingrese a la aplicación StarUML. 2. Seleccione el menú File y luego la opción Import.

Haga clic en la opción Import y luego en la opción Framework.


14

ANÁLISIS Y DISEÑO DE SISTEMAS En el cuadro de diálogo Importar Framework, seleccione un marco para importar y haga clic en Ok.

Aparecerá el cuadro de diálogo Seleccionar elemento,

para

determinar

qué

elemento

contendrá.

FUNDAMENTO TEÓRICO: Entender los conceptos de elementos o componentes de un sistema. Hoy en día hablar de sistemas es básicamente enfocarse a un conjunto de elementos que tienen que poseer algunas características para poder ser catalogado como tal, es por ello que la gente asocia mucho la palabra sistemas a las computadoras, es cierto un computadora es un sistema pero no es único, existen a nuestro alrededor muchos sistemas, pero como nos somos capaces de identificarlos cometemos una apreciación errónea de ello. Es por eso que se recomienda trabajar teniendo en cuenta los muchos aspectos del enfoque de sistemas y cómo se relacionan con la ya famosa teoría general de sistemas (TGS). En pocas palabras se tiene que tener claro lo que realmente es TGS ya que esta proporciona los fundamentos teóricos. Los diferentes aspectos del enfoque de sistemas.

Metodolo gía de diseño.

Marco de trabajo conceptu al común.

Nueva clase de método científico.

Teoría de organizaci ones.


Dirección por sistemas.

Método relaciona do

15

ANÁLISIS Y DISEÑO DE SISTEMAS 1. Una metodología de diseño. Hoy en día la gran mayoría de personas que tienen un puesto de trabajo en organizaciones de sector público, industrial, educativo, se dan con la complejidad de encontrar la forma más eficaz de poder solucionar tus problemas, esto quiere decir que no encuentra el camino correcto o el más adecuado para dar con una solución feliz a dicho problema. Todo ello genera que estas personas se vean atormentadas por bandos que los urgen para que observen todos los aspectos del problema y al mismo tiempo incorporen sus opiniones en el diseño final del sistema en cuestión. No importa cuán pequeño sea el impacto que una decisión tiene en uno o varios sistemas, en donde por sistema se entiende no sólo la organización de una área, sino también la función y todos los usuario y componentes de éste. Es por ello que primera se llegar a la conclusión de que existen sistemas dentro de los sistemas. La organización entiende que su personal es parte de un sistema potencial humano que a su vez pertenece a un sistema de trabajo y este terminara adhiriéndose y a un sistema operativo, y de esta forma poder ir encontrado otros sistemas inmersos dentro de otros sistemas. Pero eso no solo queda ahí, no basta con reconocer otro un sistema dentro de otro, también es importante recomer la relación que se tienen entre ellos ya que un movimiento en uno de los sistemas puede afectar y hacer que éste mismo se perciba en los demás. En conclusión los sistemas deben planearse, no debe permitirse que sólo "sucedan". 2. Un marco de trabajo conceptual común. De todas formas los sistemas mantienen características en común por más que tengan objetivos distintos. • Propiedades y estructuras, Uno de los objetivos del enfoque de sistemas, es buscar similitudes de estructura y de propiedades, así como fenómenos comunes, esto quiere decir que el enfoque de sistemas busca generalizaciones que se refieran a la forma en que están organizados los sistemas, a los medios por los cuales los sistemas reciben, almacenan, procesan y recuperan información, y a la forma en que funcionan; es decir, la forma en que se comportan, responden y se adaptan ante diferentes entradas del medio. • Métodos de solución y modelos, En este caso el enfoque de sistemas busca encontrar la relación de métodos de solución, a fin de extender su dominio de aplicación y facilitar la comprensión de nuevos fenómenos. Siempre que sea posible, se debe combatir la especialización y compartimentalización.


16

ANÁLISIS Y DISEÑO DE SISTEMAS • Dilemas y paradojas, Los sistemas no trata problemas metodológicos. Tan pronto como se adopta el enfoque de sistemas, aparecen los siguientes problemas de dualismo o dualidad. • Simplicidad contra complejidad. Se tiene que partir de la premisa que no se puede hacer frente a problemas complejos, esto quiere decir que se debe de optar por emplear versiones más simples. Al simplificar las soluciones, éstas pierden realismo. Por tanto se llega al punto en la que uno se encuentra en un dilema dividido entre la incapacidad de resolver problemas complejos y la falta de aplicabilidad de soluciones obtenidas de modelos simples. • Optimización y suboptimización. Se puede optimizar sistemas cerrados, como son los modelos en los cuales se conocen todos los supuestos y condiciones limitantes. Las situaciones de la vida real son sistemas abiertos, porciones que pueden, a lo mejor, estar parcialmente optimizadas. Además, optimizar los subsistemas no garantiza que el sistema total óptimo se logre. • Idealismo contra realismo. Se tiene que entender que no se puede alcanzar lo óptimo, la solución claramente ideal. Si va a tener lugar la implantación, se deben aceptar versiones más realistas de lo óptimo. • Acuerdo y consenso. La planeación requiere que todos los participantes contribuyan a las soluciones de los sistemas y su implantación. Para obtener tales resultados se necesita un consenso que es difícil de lograr cuando se premia la individualidad e independencia. 3. Nueva clase de método científico. El mundo está hecho de entidades físicas y de sistemas vivientes. Hay un conocimiento creciente de que, en tanto estas dos clases de sistemas comparten muchas propiedades, sus atributos respectivos son tan diferentes que aplicar los mismos métodos a ambos, conduce a grandes conceptos falsos y errores. El método científico que nos ha sido de gran utilidad para explicar el mundo físico debe complementarse con nuevos métodos que pueden explicar el fenómeno de los sistemas vivientes. El enfoque de sistemas y la teoría general de sistemas de la cual se deriva, están animando el desarrollo de una nueva clase de método científico abarcado en el paradigma de sistemas, que puede enfrentarse con procesos como la vida, muerte, nacimiento, evolución, adaptación, aprendizaje, motivación e interacción. 4. Una teoría de organizaciones. El enfoque de sistemas tiene que ver, en gran parte, con las organizaciones. El enfoque de sistemas otorga una nueva forma de pensamiento a las organizaciones que complementan las escuelas previas de la teoría de la organización. Éste busca unir el punto de vista conductual con el estrictamente mecánico y considerar la organización como un todo integrado, cuyo objetivo


17

ANÁLISIS Y DISEÑO DE SISTEMAS sea lograr la eficacia total del sistema, además de armonizar los objetivos en conflicto de sus componentes. Esta integración demanda nuevas formas de organización formal, como las que se refieren a los conceptos de proyecto de administración y programa de presupuesto con estructuras horizontales superpuestas sobre las tradicionales líneas de autoridad verticales. 5. El enfoque de sistemas: dirección por sistemas. Las grandes organizaciones, como por ejemplo, las corporaciones multinacionales, enfrentan problemas cuyas ramificaciones e implicaciones requieren que éstos sean tratados en una forma integral, a fin de competir con sus complejidades e interdependencias. Tales organizaciones deben tener la habilidad de "planear, organizar y administrar la tecnología eficazmente”. Deben aplicar el enfoque de sistemas y el paradigma de sistemas a la solución de sus problemas, un enfoque que requiere que las funciones de sistemas, se apliquen a la dirección de los problemas complejos de la organización. Al tratar cada situación, ésta debe considerarse en el contexto y marco de trabajo de la organización tomada como un "sistema", un todo complejo en el cual el director busca la eficacia total de la organización. 6. Métodos relacionados. Creemos que existe una distinción entre lo que algunos llaman análisis de sistemas, y lo que aquí llamamos enfoque de sistemas. Muchos tratados de análisis de sistemas se han dedicado al estudio de problemas relacionados a los sistemas de información administrativa, sistemas de procesamiento de datos, sistemas de decisión, sistemas de negocios, y similares. El enfoque de sistemas, como se le concibe en este texto, es bastante general y no se interesa en un tipo particular de sistema. Algunas presentaciones del análisis de sistemas sólo enfatizan el aspecto metodológico de este campo. Nuestro tratado sobre el enfoque de sistemas intenta estudiar las herramientas del oficio, así como el fundamento conceptual y filosófico de la teoría. La metodología de Checkland, llamada análisis aplicado de sistemas, es más parecida a nuestra teoría general de sistemas aplicada que lo que pudiera parecer que implica su nombre. La ingeniería de sistemas y la eficiencia de costos también son nombres relacionados al enfoque de sistemas. Todos ellos se derivan de una fuente común, y la literatura de estos campos está íntimamente relacionada con el de análisis de sistemas. No se debe pasar por alto los lazos que unen el enfoque de sistemas con la investigación de operaciones y con la ciencia de la administración. Muchos artículos de esos campos pueden considerarse del dominio de la teoría general de sistemas. Estas tres jóvenes disciplinas aún se


18

ANÁLISIS Y DISEÑO DE SISTEMAS encuentran en estado de flujo. Mantienen intereses comunes y poseen raíces comunes. Es concebible que algún día una nueva disciplina que lleve uno de los nombres arriba citados, o alguno nuevo, abarcará a las demás. Hasta este momento, la teoría general de sistemas ha proporcionado el ímpetu hacia esa dirección. Reconocer las características de los sistemas y los tipos de sistemas. Las características de los sistemas dependen de su dominio. El dominio de los sistemas es el campo sobre el cual están trabajando. De acuerdo a ello se puedo encontrar la siguiente clasificación: 1. Sistemas vivientes y no vivientes. En este sentido se hace mención de forma específica aquellos sistemas que poseen funciones biológicas como son el nacimiento, la muerte y la reproducción. 2. Sistemas abstractos y concretos. De acuerdo con Ackoff, "un sistema abstracto es aquel en que lodos sus elementos son conceptos. Un sistema concreto es aquel en el que por lo menos dos de sus elementos son objetos". Para entrar un poco más al detalle se puede entender que un sistema concreto dicho como tal, los elementos terminan siendo objetos y en otras casos sujetos 3. Sistemas abiertos y cerrados. Los conceptos de sistemas abierto y cerrado introducen una diferenciación muy importante entre ellos y radica en la influencia ya que un sistema cerrado es un sistema que no se deja influencia por otro sistema es por eso su nombre, caso contrario con un sistema abierto, ya que dicho sistema por ser de tipo abierto posee otros sistemas con los cuales se relaciona, intercambia y comunica. La distinción entre sistemas abierto y cerrado, es fundamental para la comprensión de los principios básicos de la teoría general de sistemas. Cualquier consideración de sistemas abiertos como sistemas cerrados, en los que pasa inadvertido el medio, trae consigo graves riesgos que deben comprenderse totalmente. Tomando los datos de la primera características se puede llegar a la conclusión que los sistemas vivientes son sistemas abiertos. Los sistemas cerrados se mueven a un estado estático de equilibrio que es únicamente dependiente de las condiciones iniciales del sistema. SÍ cambian las condiciones iniciales, cambiará el estado estable final.


19

ANÁLISIS Y DISEÑO DE SISTEMAS 4. Entropía, incertidumbre e información. La entropía es tomada de la termodinámica, para efectos de medir el desorden dentro de los sistemas. Un sistema muestra una alta o baja entropía (variedad, incertidumbre, desorden). Reducir la entropía de un sistema, es reducir la cantidad de incertidumbre que prevalece. La incertidumbre se disminuye al obtenerse información. La información, en el sentido de la teoría sobre la información, posee un significado especial que está ligado al número de alternativas en el sistema. Estos conceptos pueden utilizarse para caracterizar los sistemas vivientes y no vivientes. Los sistemas no vivientes (considerados generalmente como cerrados), tienden a moverse hacia condiciones de mayor desorden y entropía. Los sistemas vivientes (y por tanto abiertos), se caracterizan como resistentes a la tendencia hacia el desorden y se dirigen hacia mayores niveles de orden. 5. Complejidad organizada y no organizada. Los sistemas vivientes son sistemas de complejidad organizada, en tanto que los sistemas no vivientes muestran propiedades ya sea de simplicidad organizada o complejidad no organizada. En contraste a la simplicidad organizada. Se reconoce al sistema que muestran una complejidad caótica desorganizada. Los sistemas vivientes muestran un tipo de conducta que no puede explicarse ni en términos de leyes dinámicas resultantes de la suma de las propiedades de las partes, ni por el resultado probable de un número infinito de interacciones como podría encontrarse, respectivamente, en sistemas de simplicidad organizada y de complejidad no organizada. Los sistemas vivientes generalmente muestran una clase diferente de complejidad llamada complejidad organizada. 6. Propósito y conducta con un propósito. La conducta con un propósito e intencional es la que está dirigida hacia el logro de un objetivo, un estado final. El objetivo hacia el cual se esfuerzan los sistemas, tiene una consecuencia más inmediata que el concepto rechazado de la antigua teleología. La conducta sin un propósito es la que no está dirigida hacia el logro de un objetivo. Los criterios para distinguir entre una conducta con propósito y sin éste, pueden elaborarse como sigue: Para que tenga lugar la conducta con propósito, el objeto al cual se atribuye la conducta debe ser parte del sistema. La conducta con propósito debe estar dirigida hacia un objetivo. Debe haber una relación recíproca entre el sistema y su medio. La conducta debe estar relacionada o acoplada con el medio, del cual debe recibir y registrar señales que indiquen si la conducta progresa hacia el objetivo. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

20

ANÁLISIS Y DISEÑO DE SISTEMAS Un sistema con un propósito debe siempre mostrar una elección de cursos alternos de acción. La elección de una conducta debe conducir a un producto final o resultado. Deben distinguirse las condiciones suficientes y necesarias para un evento. Las condiciones suficientes nos capacitan para predecir que éste ocurra, en tanto que las condiciones necesarias nos descubren elementos en la naturaleza que son responsables de él. 7. Retroalimentación. Vimos que los sistemas no vivientes pueden dirigirse con retro alimentación hacia una salida específica mediante la regulación de la conducta con un mecanismo controlado. Este mecanismo se basa en el principio de retroalimentar una porción de la salida, para controlar la entrada. Podemos tener una retroalimentación positiva, en la cual la multiplicación entre la entrada y la salida es tal que la salida aumenta con incrementos en la entrada, o una retroalimentación negativa, en la cual la salida disminuye al aumentar la entrada. La retroalimentación positiva generalmente conduce a la inestabilidad de sistemas, en tanto que la retroalimentación negativa se usa para proporcionar un control de sistema estable. Las condiciones para un control estable e inestable a través de una retroalimentación positiva y negativa han sido resueltas matemáticamente y están en la base de la teoría de los servomecanismos, que trata con dispositivos por los cuales los grandes sistemas pueden controlarse automáticamente. La aplicación de los principios de control de la retroalimentación a sistemas vivientes no es tan integra como la que trata con los sistemas no vivientes. En el estudio sobre la teoría de control, en el capítulo 18, tendremos un análisis completo de estos problemas. Será suficiente en este punto, enfatizar la importancia que mantiene el concepto de control para la teoría de sistemas. El científico social está primordialmente interesado en organizaciones o sistemas vivientes, sistemas que tienen un propósito en el sentido limitado, como se describió en la sección anterior. El científico social está interesado en dirigir esos sistemas hacia su objetivo o en proporcionar principios al administrador a fin de que pueda^ controlar los movimientos hacia esos objetivos. En tanto se pueda hacer un intento para traducir los principios de control y servomecanismos a sistemas vivientes, su aplicación será más difícil, debido a que las entradas y salidas no están tan claramente definidas, como cuando se trata de sistemas no vivientes, o abstracciones matemáticas. A pesar de tales dificultades, esos intentos son de la mayor importancia para mejorar el desempeño de sistemas que sirven al ser humano. Tenemos que encontrar principios y procedimientos por los cuales la organización humana pueda lograr el progreso y moverse en dirección a los objetivos que se ha fijado para sí misma.


21

ANÁLISIS Y DISEÑO DE SISTEMAS 8. Jerarquía en los sistemas. La jerarquía es un concepto importante que puede utilizarse para representar el hecho de que los sistemas pueden ordenarse de acuerdo a varios criterios, uno de los cuales es la complejidad en incremento de la función de sus componentes. Pueden considerarse los siguientes niveles de sistemas. 9. Organización. La organización es una característica de sistemas que van más allá de la complejidad de la estructura. Por tanto, Ackoff define una organización como "un sistema por lo menos parcialmente autocontrolado" que posee las siguientes características: Contenido ya que hay una relación sistemas hombre-máquina. Estructura porque el sistema debe mostrar la posibilidad de cursos de acción alternativos, la responsabilidad por la cual puede diferenciarse con base en funciones (mercadeo, producción, contabilidad, etc.), geográfica, o alguna otra propiedad. Las Comunicaciones desempeñan un papel importante en la determinación de la conducta e interacción de subsistemas en la organización. Por último la elección de toma de decisión ya que los cursos de acción conduce a resultados que también deben ser el objeto de elecciones entre los participantes. El estudio anterior es importante, principalmente por la lección que contiene para mejorar el conocimiento sobre organizaciones. Es obvio que las organizaciones son sistemas que muestran órdenes más elevados que otros sistemas vivientes; el orden se interpreta en términos de elevada complejidad y determinación consciente para alcanzar objetivos autoestablecidos. Los sistemas de nivel bajo muestran una complejidad menor y contienen conjuntos de objetivos impuestos, ya sea por el medio o por otros sistemas. La conciencia es la que se mueve en dirección al progreso, hacia objetivos autoimpuestos, la que hace del ser humano un sistema superior en la jerarquía de los sistemas. Se acredita a la teoría general de sistemas, haber separado la teoría de los sistemas no vivientes, los cuales pueden tratarse mediante el enfoque mecánico, de la teoría de los sistemas vivientes, la que requiere un enfoque diferente del anterior.


22

ANÁLISIS Y DISEÑO DE SISTEMAS TAREA 02: DEFINIR EL PROCEDIMIENTO PARA EL ANÁLISIS Y DISEÑO DE SISTEMAS. En esta tarea trataremos las siguientes operaciones:  Definir los procedimientos para el análisis y diseño de sistemas. EQUIPOS Y MATERIALES:

 Computadora con microprocesadores core 2 Duo o de mayor capacidad.  Sistema operativo Windows y la aplicación de Wampserver.  Acceso a internet. OPERACIONES: Cómo se trabaja en Rational Rose. 1. Ingrese a la aplicación Rational Rose. 2. En la primera pantalla haga clic en el botón Cancel. La primera pantalla tiene la típica estructura de una venta de Microsoft Windows. 3. Haga clic en Use Case View. (incluye todos los actores y todos los diagramas de caso de uso), luego doble clic en la opción Main (Cambia la barra de herramientas). 4. Elija el botón Actor y haga clic en el área de diseño para ingresar la entidad y por ultimo ingrese el nombre alumno. Una entidad es todo aquello que puede ser descrito por sus atributos.

5. Haga doble clic en la entidad alumno, aparece la ventana de especificaciones para el actor alumno.


23


6. Ubicar el cursor en la sección Documentation que cumple la función de ayuda o de recordatorio para las entidades empleadas en el diseño. Para el ejemplo ingrese el siguiente texto: “El alumno es el encargado de realizar las acciones más importante dentro del sistema, como realizar la matricula, estudias y cancelas las pensiones.” 7. Haga clic en el botón Ok. 8. Haga clic en la entidad alumno para lograr visualizar la ayuda creada.

Ayuda o recordatorio para las entidades

9. Elija el botón Use Case y haga clic en el área de diseño y por último ingrese el texto Estudia Software.


24


10. Elija el botón Actor y haga clic en el área cliente. 11. Elija el botón Use Case y haga clic en el ingrese el texto Compra Producto. 12. Elija el botón Actor y haga clic en el área Cajero. 13. Elija el botón Use Case y haga clic en el ingrese el texto Registra Pedidos.

de diseño e ingrese el texto área de diseño y por último de diseño e ingrese el texto área de diseño y por último

Los Use Case son en su mayoría procedimientos generados por los actores.

14. Haga clic en el botón Unidirectional Association y realice un arrastre desde el actor alumnos hacia el use case Estudia Software. 15. Repetir la acción con los actores restantes. 16. Haga doble clic a la entidad Cliente para poder ingresar a las propiedades de la entidad. 17. Del campo Stereotype seleccione la opción Business Actor.


25

ANÁLISIS Y DISEÑO DE SISTEMAS 18. Ubique el cursor en la sección Documentation que cumple la función de ayuda o de recordatorio “El cliente es alguien que es externo a la organización pero que lograr interactuar con la misma”, en pocas palabras se podría decir que el cliente no es parte de la organización pero interactúa con ella. 19. Haga clic en el botón Ok.

Tomar en cuenta cómo cambia el actor dentro del diseño.

18. Haga doble clic a la entidad Cajero para poder ingresar a las propiedades de la entidad. 19. Del campo Stereotype seleccione la opción Business Worker. 20. Ubique el cursor en la sección Documentation que cumple la función de ayuda o de recordatorio “El cajero representa un rol dentro de la organización” en pocas palabras se podría decir que interactúa de forma directa en la organización. 21. Clic en el menú File y luego en la opción Save As. Ingrese el nombre y la ubicación para el archivo. 22. Haga clic en Guardar. Cómo se trabaja en ArgoUML. Asistente de Configuración. 1. Haga clic en el menú Editar y luego en la opción Configuración.

2. Seleccione el idioma en el Panel de Apariencias.


26


Seleccione la opción es (español)

Configuración de atajos. 1. Haga clic en el menú Editar y luego en la opción Configuración. 2. Seleccione la opción Configuración de Atajos. 3. Ingresar los primeros atajos hasta completar la tabla. Acción

Atajo

Por defecto

Guardando el Proyecto. 1. Haga clic en el menú Archivo y luego en la opción Guardar el proyecto como. 2. Ingrese un nombre y una ubicación y luego haga clic en Guardar.


27

ANÁLISIS Y DISEÑO DE SISTEMAS FUNDAMENTO TEÓRICO: Definir los procedimientos para el análisis y diseño de sistemas. Muchas de las organizaciones no tiene aún claro el valor del software dentro de la misma, y lo más grave se podría decir que mucho de los departamento de TI dentro de la organización no está preparadas para asumir el papel que deben cumplir, es por ello que no se entiende mucho el software como un producto, y es así. Por se debe entender al software, como todo capital, es conocimiento incorporado y a que el conocimiento originalmente se halla disperso, tácito, latente e incompleto en gran medida, tal como se habló en la tarea anterior, pero hay que tener en cuenta que también es un aprendizaje social debido a su característica de sistema abierto. El software como producto, mejor dicho como cualquier otro producto se desarrolla mediante procesos. De forma genérica este proceso debe ser un diálogo en el que el conocimiento tiene la finalidad de convertirse en software. Ahora este proceso que se debe dar debe generar interacción entre usuarios y diseñadores, entre usuarios y herramientas cambiantes, y entre diseñadores y herramientas tecnológicas. Todos estos elementos interactúan entre sí, gracias a la herramienta tecnológica, por otro lado con cada nueva interacción del diálogo se genera más conocimiento útil a partir de las personas involucradas. Pero desde el punto de vista técnico, ¿qué es exactamente un proceso del software?, se define proceso del software como una estructura para las actividades, acciones y tareas que se requieren a fin de construir software de alta calidad, pero las organizaciones tiene diferentes requerimientos y son estos lo que termina por convertir la actividad de desarrollo de software en algo realmente interesante porque se tiene que adaptar los procesos según las circunstancias. Cuando se trabaja en la construcción de un producto o sistema, es importante ejecutar una serie de pasos predecibles el mapa de carreteras que lo ayuda a obtener a tiempo un resultado de alta calidad.

Definición de actividad estructural. Cuando se define la actividad estructural es básicamente que un equipo de software necesitará mucha más información antes de poder ejecutar de manera apropiada cualquiera de ellas como parte del proceso del software. Por tanto, sale una pregunta importante: ¿qué trabajos son apropiadas para una actividad estructural, dados la naturaleza del problema por resolver, las características de las personas que hacen el trabajo y los participantes que patrocinan el proyecto? ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

28

ANÁLISIS Y DISEÑO DE SISTEMAS Para un proyecto de software pequeño solicitado por una persona con requerimientos sencillos y directos, la actividad de comunicación tal vez no incluya algo más que una llamada telefónica con el participante apropiado. Entonces, la única acción necesaria es una conversación telefónica, y las tareas del trabajo que engloba son las siguientes: 1. Hacer contacto con el colaborador de la organización por vía telefónica. 2. Analizar los requerimientos por parte de la organización y tomar notas. 3. Organizar las notas por escrito en una formulación breve de los requerimientos. 4. Enviar correo electrónico al colaborador de la organización para que examine y apruebe. Pero hay que dejar en claro que estas cuatro tareas se dan por la naturaleza del proyecto, esto quiere decir un software para un problema pequeño, esto termina en un requerimiento corto. Pero en el caso de que el proyecto fuera considerablemente más complejo, esto quiere decir muchos colaboradores por parte de la organización y cada uno de ellos con sus propios requerimientos, esto nos es nada ya que en muchos casos estos requerimientos terminar por generar conflictos entre los mismos. En un caso así la actividad de comunicación puede tener seis acciones distintas: concepción, indagación, elaboración, negociación, especificación y validación. Cada una de estas acciones de la ingeniería del software tendrá muchas tareas de trabajo y un número grande de diferentes productos finales.

Diseño del Sistema. En el caso del diseño el objetivo primordial es la definición de la arquitectura del sistema y del ambiente tecnológico que le va a dar soporte, junto con la especificación detallada de los componentes del sistema de información. Luego se generan todas las especificaciones de construcción relativas al propio sistema, así como la descripción técnica del plan de pruebas, la definición de los requisitos de implantación y el diseño de los procedimientos de migración si fuere el caso y carga inicial,

Definición de la arquitectura del sistema. En esta actividad se define la arquitectura general del sistema de información, especificando las distintas particiones físicas del mismo, la descomposición lógica en subsistemas de diseño y la ubicación de cada subsistema en cada partición, así como la especificación detallada de la infraestructura tecnológica necesaria para dar soporte al sistema de información.


29

ANÁLISIS Y DISEÑO DE SISTEMAS El aprisionamiento físico del sistema de información se especifica identificando los nodos y las comunicaciones entre los mismos, con cierta independencia de la infraestructura tecnológica que da soporte a cada nodo. Con el fin de organizar y facilitar el diseño, se realiza una división del sistema de información en subsistemas de diseño, como partes lógicas coherentes y con interfaces claramente definidas. Se establece una distinción entre subsistemas específicos del sistema de información (en adelante, subsistemas específicos) y subsistemas de soporte, con la finalidad de independizar, en la medida de lo posible, las funcionalidades a cubrir por el sistema de información de la infraestructura que le da soporte. En la mayoría de los casos, los subsistemas específicos provienen directamente de las especificaciones de análisis y de los subsistemas de análisis, mientras que los subsistemas de soporte provienen de la necesidad de interacción del sistema de información con la infraestructura y con el resto de los sistemas, así como de la reutilización de módulos o subsistemas ya existentes en la instalación. Debido a que la definición de los subsistemas de soporte puede exigir la participación de distintos perfiles técnicos, se propone el diseño de ambos tipos de subsistemas en actividades distintas, aunque en paralelo. Una vez identificados y definidos los distintos subsistemas de diseño, se determina su ubicación óptima de acuerdo a la arquitectura propuesta. La asignación de dichos subsistemas a cada nodo permite disponer, en función de la carga de proceso y comunicación existente entre los nodos, de la información necesaria para realizar una estimación de las necesidades de infraestructura tecnológica que da soporte al sistema de información. Este factor es especialmente crítico en arquitecturas multinivel o cliente/servidor, donde las comunicaciones son determinantes en el rendimiento final del sistema. Se propone crear un catálogo de excepciones en el que se especifiquen las situaciones anómalas o secundarias en el funcionamiento y ejecución del sistema de información, y que se irá completando a medida que se avance en el diseño detallado de los subsistemas En esta actividad también se establecen los requisitos, normas y estándares originados como consecuencia de la adopción de una determinada solución de arquitectura o infraestructura, que serán aplicables tanto en este proceso como en la Construcción del Sistema de Información (CSI). Se detallan a su vez, de acuerdo a las particularidades de la arquitectura del sistema propuesta, los


30

ANÁLISIS Y DISEÑO DE SISTEMAS requisitos de operación, seguridad y control, especificando los procedimientos necesarios para su cumplimiento. Como resultado de esta actividad, se actualizan los catálogos de requisitos y normas, y se generan los siguientes productos: • Diseño de la Arquitectura del Sistema, como producto que engloba el aprisionamiento físico del sistema de información y la descripción de subsistemas de diseño. • Entorno Tecnológico del Sistema, que a su vez comprende la especificación del entorno tecnológico, las restricciones técnicas y la planificación de capacidades. • Catálogo de Excepciones. • Procedimientos de Operación y Administración del Sistema. • Procedimientos de Seguridad y Control de Acceso. Tarea Definición de DSI

Niveles de Arquitectura

Productos • Diseño de la Arquitectura del Sistema o Aprisionamiento. Físico del Sistema de Información.

Identificación de DSI

Requisitos de Diseño y

DSI

Excepciones

DSI

Normas de Diseño

• Diagrama de

Trabajo.

Trabajo. • Catalogación. • Sesiones de

• Catálogo de Normas

Trabajo. • Catalogación.

y Construcción

• Equipo de Arquitectura. • Equipo de Soporte Técnico. • Equipo de Seguridad.

Despliegue.

• Sesiones de

Especificación de Estándares y

Representación-

• Catalogación.

• Catálogo de Excepciones.

Participantes

• Diagrama de

• Sesiones • Catálogo de Requisitos.

Construcción Especificación de

Técnicas y Prácticas

de

• Equipo de Arquitectura. • Equipo de Soporte Técnico.

• Equipo de Arquitectura. • Equipo de Soporte Técnico


• Matricial • Diagrama de Estructura

DSI

Identificación de

• Diseño de la Arquitectura

Subsistemas de

del Sistema o Descripción

Diseño

de Subsistemas de Diseño

• Diagrama de Inter-acción de Objetos. • Diagrama de

• Equipo de Arquitectura. • Equipo de Soporte Técnico. • Equipo de Seguridad

Paquetes. • Diagrama de Despliegue


31

ANÁLISIS Y DISEÑO DE SISTEMAS • Entorno Tecnológico del Especificación del DSI

Entorno Tecnológico

Sistema: o Especificación • Sesiones de del Entorno Tecnológico o

Trabajo.

Restricciones Técnicas o • Diagrama de Estimación

de

Planifi-


Representación

cación de Capacidades Especificación de DSI

Requisitos de Operación y Seguridad

• Procedimientos de Seguridad y Control de Acceso. • Procedimientos de Operación y Adminis-

• Equipo de Seguridad. • Equipo de Arquitectura. • Equipo de Soporte Técnico

tración del Sistema.

1. Definición de Niveles de Arquitectura. En esta tarea se describen los niveles de la arquitectura software, mediante la definición de las principales particiones físicas del sistema de información, representadas como nodos y comunicaciones entre nodos. Se entiende por nodo cada partición física o parte significativa del sistema de información, con características propias de ejecución o función, e incluso de diseño y construcción. Para facilitar la comprensión del sistema, se recomienda identificar como nodos los elementos de infraestructura más significativos de la arquitectura en la que se va a implementar el sistema de información. Los elementos que se aconseja especificar son los siguientes:

Gestores de datos. Tipos de puesto cliente. Tipos de dispositivos de impresión. Monitores de teleproceso. Servidores. Comunicaciones. La comunicación se expresa por una conexión entre nodos, indicando su carácter bidireccional o unidireccional, con las principales características de los protocolos o tipo de mensajes utilizados.


32

ANÁLISIS Y DISEÑO DE SISTEMAS La especificación de los niveles de la arquitectura se realiza con el detalle suficiente como para permitir un diseño dirigido hacia una solución concreta. En general, no es preciso indicar en cada nodo detalles relativos al hardware, capacidad, rendimiento o configuraciones de tolerancia a fallos, entre otros. Esta información se concreta en la tarea Especificación del Entorno Tecnológico. Los criterios para diseñar la arquitectura se obtienen a partir de directrices tecnológicas o de integración, propias de la instalación, y del catálogo de requisitos del sistema de información. Es necesario tener en cuenta, especialmente, aspectos relacionados con: • Usuarios: ubicación, movilidad, concurrencia, número, etc. • Datos: variabilidad, volúmenes, necesidades de consolidación, seguridad, etc. Procesos: distribución, reutilización, concurrencia, carácter crítico, etc. Productos. (Entrada) • Descripción General del Entorno Tecnológico del Sistema. • Catálogo de Requisitos. • Especificación de Interfaz de Usuario.

Técnicas • Diagrama de Despliegue.

En Diseño Estructurado • Matriz de Procesos / Localización Geográfica. • Descripción de Interfaz con otros Sistemas. • Modelo de Procesos. • Modelo Lógico de Datos Normalizado.

En Diseño Orientado a Objetos. • Modelo de Casos de Uso. • Especificación de Casos de Uso. • Descripción de Subsistemas de Análisis. • Descripción Interfaces entre Subsistemas. • Modelo de Clases de Análisis. • Análisis de la Realización de los Casos de Uso. • De salida. • Diseño de la Arquitectura del Sistema o Particionamiento Físico del Sistema de Información.

Prácticas. • Diagrama de Representación

Participantes • Equipo de Arquitectura • Equipo de Soporte Técnico • Equipo de Seguridad

2. Identificación de Requisitos de Diseño y Construcción. En esta tarea se realiza la especificación de los requisitos que están directamente relacionados con la adopción o diseño de una arquitectura o


33

ANÁLISIS Y DISEÑO DE SISTEMAS infraestructura concreta, y que pueden condicionar el diseño o la construcción del sistema de información. Entre estos requisitos pueden estar los relacionados con lenguajes, rendimiento de los distintos elementos de la arquitectura, así como criterios de ubicación de módulos y datos en los distintos nodos. Por tanto, como resultado de esta tarea se actualiza el catálogo de requisitos elaborado en el proceso Análisis de Sistemas de Información.

Productos. (Entrada) • Catálogo de Requisitos. • Diseño de la Arquitectura del Sistema. • De salida • Catálogo de Requisitos.

Prácticas • Sesiones de Trabajo • Catalogación

Participantes • Equipo de Arquitectura • Equipo de Soporte Técnico

3. Especificación de Excepciones. El objetivo de esta tarea es la definición de los comportamientos no habituales en el sistema, que reflejan situaciones anómalas o secundarias en el funcionamiento y ejecución del sistema de información. Para ello, se establece previamente el nivel de especificación de las mismas, así como los criterios de catalogación y clasificación. Se propone su catalogación como ayuda para el diseño del sistema de información y como guía en la especificación técnica de las pruebas, al permitir la generación de algunos casos de prueba de forma inmediata. Dicho catálogo se va completando a partir de las actividades correspondientes al diseño detallado de los subsistemas. Las excepciones se describen incluyendo, al menos, los siguientes conceptos: • Tipo y descripción de la excepción. • Condiciones previas del sistema de información. • Elemento afectado (nodo, módulo, caso de uso). • Respuesta del sistema de información. • Elemento asociado a la respuesta esperada del sistema (módulo, clase, procedimiento, etc.). Las excepciones que se proponen como obligatorias son las relacionadas con el funcionamiento general del sistema de información, habitualmente asociadas a: • Nodos y comunicaciones del aprisionamiento físico del sistema de información. Este tipo de excepciones tiene lugar cuando no están ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

34

ANÁLISIS Y DISEÑO DE SISTEMAS disponibles los gestores de bases de datos o los recursos compartidos del sistema (representados como nodos), cuando se producen fallos en las comunicaciones entre nodos, etc. • Rangos o valores no válidos en la entrada de datos, como pueden ser atributos obligatorios, con formatos específicos, etc. Se recomienda, según el nivel de especificación que se establezca en cada caso, catalogar también las excepciones particulares que se identifiquen en las actividades del diseño de detalle. En Diseño Orientado a Objetos.

Productos. (Entrada) • Catálogo de Requisitos • Diseño de la Arquitectura del Sistema

Prácticas

• Modelo de Casos de Uso • Especificación de Casos de Uso. • De salida • Catálogo de Excepciones.

• Sesiones de Trabajo • Catalogación

Participantes. • Equipo de Arquitectura • Equipo de Soporte Técnico

4. Especificación de Estándares y Normas de Diseño y Construcción. En esta tarea se definen los estándares técnicos y de nomenclatura, normas y recomendaciones, que generalmente están relacionados con la adopción o diseño de una arquitectura o infraestructura tecnológica concreta, y que pueden condicionar el diseño o la construcción del sistema de información. Como resultado de esta tarea, se actualiza el catálogo de normas obtenido en el proceso Análisis del Sistema de Información. La información recogida en el catálogo se debe tener en cuenta en la elaboración de los productos resultantes del diseño y construcción del sistema de información. El catálogo de normas es, por tanto, producto de entrada en todas las tareas, aunque por sencillez se omite la referencia al mismo. Productos. (Entrada) • Estándares y Normativas de la Instalación (externo) • Catálogo de Normas. • Diseño de la Arquitectura del Sistema. • De salida • Catálogo de Normas.

Prácticas • Sesiones de Trabajo • Catalogación


Participantes. • Equipo de Arquitectura • Equipo de Soporte Técnico

35

ANÁLISIS Y DISEÑO DE SISTEMAS 5. Identificación de Subsistemas de Diseño. En esta tarea se divide de forma lógica el sistema de información en subsistemas de diseño, con el fin de reducir la complejidad y facilitar el mantenimiento. Hay que tomar como referencia inicial los subsistemas de análisis especificados en el proceso de Análisis del Sistema de Información (ASI). La división en subsistemas de diseño se puede realizar con una continuidad directa de los modelos del análisis, o aplicando nuevos criterios de diseño, entre los que es posible citar los siguientes: • Facilidad de mantenimiento. • Reutilización de elementos del propio sistema o de la instalación. • Optimización de recursos (por ejemplo, líneas de comunicaciones). • Características de ejecución (en línea o por lotes). • Funcionalidad común. • Aplicación de mecanismos genéricos de diseño al nivel de arquitectura. Los subsistemas resultantes se califican como específicos o de soporte, asignando cada subsistema al nodo correspondiente. Los subsistemas específicos contemplan las funcionalidades propias del sistema de información, mientras que los de soporte cubren servicios comunes, proporcionando un acceso transparente a los distintos recursos. Estos últimos están relacionados con: − Comunicaciones entre subsistemas.

Gestión de datos

Seguridad y control de acceso.

Gestión de transacciones

Control y gestión de errores

Control y gestión de errores.

Gestión de interfaz.

Interacción con los recursos propios del sistema.


36

ANÁLISIS Y DISEÑO DE SISTEMAS La interacción del sistema de información con la infraestructura que le da soporte, así como con el resto de los sistemas y servicios de la instalación, puede originar la necesidad de nuevos subsistemas, módulos, clases o servicios no especificados en el análisis. La definición del comportamiento externo de cada subsistema se completa durante el diseño de detalle con la especificación de su interfaz, así como con la dependencia entre subsistemas. El diseño de detalle de los subsistemas identificados por criterios de optimización y reutilización, puede aconsejar la reorganización y reubicación de los elementos que forman parte de cada subsistema y, a su vez, puede dar lugar a la identificación de nuevos subsistemas de soporte. En diseño estructurado, la descripción de los subsistemas de diseño que conforman el sistema de información se especifica mediante un diagrama de estructura de alto nivel, que muestra los distintos subsistemas de que consta el sistema, incluidos los subsistemas de soporte, junto con la definición de la interfaz de cada subsistema. La ubicación de subsistemas en nodos y la dependencia entre subsistemas se especifica por medio de técnicas matriciales, o bien en lenguaje natural o pseudocódigo.

Productos. (Entrada) • Descripción General del Entorno Tecnológico del Sistema. • Diseño de la Arquitectura del Catálogo de Requisitos.

En Diseño Orientado a Objetos

En Diseño Estructurado • Matriz de Procesos / Localización. • Descripción de Interfaz con otros Sistemas. • Modelo de Procesos.

Técnicas • Diagrama de Estructura • Matricial • Diagrama de Interacción de Objetos • Diagrama de Paquetes • Diagrama de Despliegue

• Descripción de Subsistemas de Análisis. • Descripción Interfaces entre Subsistemas. • De salida • Diseño de la Arquitectura del Sistema o Descripción de Subsistemas de Diseño.

Participantes • Equipo de Arquitectura • Equipo de Soporte Técnico • Equipo de Seguridad

6. Especificación del Entorno Tecnológico. En esta tarea se definen en detalle los distintos elementos de la infraestructura técnica que dan soporte al sistema de información, determinando la ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

37

ANÁLISIS Y DISEÑO DE SISTEMAS implementación concreta de los nodos y comunicaciones especificados en la tarea Definición de Niveles de Arquitectura Se propone agrupar los elementos de la infraestructura en los siguientes conceptos: • Hardware: procesadores, unidades de almacenamiento, estaciones de trabajo, etc. • Software: sistemas operativos, subsistemas, middleware, gestores de bases de datos, sistemas de ficheros, software de base, herramientas y utilidades de gestión propias del sistema, etc. • Comunicaciones: diseño de la topología de la red, protocolos, nodos de red, etc. La definición de los distintos elementos puede generar restricciones técnicas que afecten al diseño o construcción del sistema de información. Así mismo, se realiza una estimación de la planificación de capacidades (capacity planning) o se especifican los parámetros que Explotación y Sistemas precisen para realizar dicha planificación. Se indican, al menos, las necesidades previstas de: • Almacenamiento: espacio en disco, espacio en memoria, pautas de crecimiento y evolución estimada del sistema de información, etc. • Procesamiento: número y tipo de procesadores, memoria, etc. • Comunicaciones: líneas, caudal, capacidades de elementos de red, etc. Para poder determinar la planificación de capacidades, es necesario conocer los diseños detallados de los módulos / clases y escenarios, incluida la información de control en las comunicaciones, así como el diseño físico de datos optimizado, productos que se están generando en paralelo a esta actividad. También se tienen en cuenta, cuando proceda, las estimaciones de volúmenes de datos propios de la migración y carga inicial de datos.

Productos. (Entrada) • Descripción General del Entorno Tecnológico del Sistema. • Diseño del Sistema de Información • Catálogo de Requisitos. • Diseño de la arquitectura del sistema.

En Diseño Estructurado • Matriz de Procesos / Localización Geográfica. • Plan de Migración y Carga Inicial de Datos


En Diseño Orientado a Objetos • Plan de Migración. • Entorno Tecnológico del Sistema o Especificación del Entorno Tecnológico o Restricciones Técnicas o Estimación de Planificación de Capacidades

38


Prácticas • Sesiones de Trabajo • Diagrama de Representación

Participantes • Equipo de Arquitectura. • Equipo de Soporte Técnico.

7. Especificación de Requisitos de Operación y Seguridad. El objetivo de esta tarea es definir los procedimientos de seguridad y operación necesarios para no comprometer el correcto funcionamiento del sistema y garantizar el cumplimiento de los niveles de servicios que exigirá el sistema en cuanto a la gestión de operaciones (procesos por lotes, seguridad, comunicaciones, etc.). Los niveles de servicio se especifican formalmente en el proceso Implantación y Aceptación del Sistema. Tomando como referencia los requisitos establecidos para el sistema, y teniendo en cuenta la arquitectura propuesta y las características del entorno tecnológico definido en esta actividad, se lleva a cabo la definición de los requisitos de seguridad y control de acceso necesarios para garantizar la protección del sistema y minimizar el riesgo de pérdida, alteración o consulta indebida de la información. Para ello, se diseñan los procedimientos relacionados con: • • • • •

Acceso al sistema y a sus recursos (datos, transacciones, librerías, etc.). Mantenimiento de la integridad y confidencialidad de los datos. Control y registro de accesos al sistema (logs, certificación, etc.). Copias de seguridad y recuperación de datos y su periodicidad. Recuperación ante catástrofes.

Así mismo, se definen los requisitos de operación para los distintos elementos del sistema (módulos, clases, estructuras físicas de datos, sistemas de ficheros), que se están elaborando en paralelo a esta actividad, y se diseñan los procedimientos asociados relacionados con: • Tratamiento en línea (franja horaria/periodos críticos, número máximo de usuarios, etc.). • Tratamiento por lotes (periodicidad y secuencia de ejecución, interdependencias, petición de ejecución, etc.). • Control y planificación de trabajos. • Recuperación y reanudación de trabajos. • Distribución de información generada por el sistema, tanto trabajos planificados o bajo petición. • Control y seguimiento del correcto funcionamiento de los procedimientos de backup y recuperación utilizados habitualmente.


39


Productos. (Entrada) • Catálogo de Requisitos. • Diseño de la Arquitectura del Sistema. • Entorno Tecnológico del Sistema. • De salida • Procedimientos de Seguridad y Control de Acceso. • Procedimientos de Operación y Administración del Sistema.

Prácticas. • Sesiones de Trabajo • Catalogación

Participantes • Equipo de Seguridad • Equipo de Arquitectura • Equipo de Soporte Técnico.

Diseño de la arquitectura de soporte. En esta actividad se lleva a cabo la especificación de la arquitectura de soporte, que comprende el diseño de los subsistemas de soporte identificados en la actividad de Definición de la Arquitectura del Sistema (DSI 1), y la determinación de los mecanismos genéricos de diseño. Estos últimos sirven de guía en la utilización de diferentes estilos de diseño, tanto en el ámbito global del sistema de información, como en el diseño de detalle. El diseño de los subsistemas de soporte, conceptualmente, es similar al diseño de los subsistemas específicos, aunque debe cumplir con unos objetivos claros de reutilización. De esta manera, se consigue simplificar y abstraer el diseño de los subsistemas específicos de la complejidad del entorno tecnológico, dotando al sistema de información de una mayor independencia de la infraestructura que le da soporte. Con este fin, se aconseja la consulta de los datos de otros proyectos existentes, disponible en el Histórico de Proyectos. Si esto no fuera suficiente, se puede contar en esta actividad con la participación de perfiles técnicos, con una visión global de la instalación. Esta actividad se realiza en paralelo al diseño detallado, debido a que existe una constante realimentación, tanto en la especificación de los subsistemas con sus interfaces y dependencias, como en la aplicación de esqueletos o patrones en el diseño. Los productos resultantes de esta actividad son: • Diseño del Sistema de Información. • Diseño Detallado de los Subsistemas de Soporte. • Mecanismos Genéricos de Diseño y Construcción.


40

ANÁLISIS Y DISEÑO DE SISTEMAS Tarea

DSI

DSI

• Diseño de Subsistemas de Soporte • Identificación de Mecanismos Genéricos de Diseño

Productos •

•

Diseño Detallado de los Subsistemas de Soporte. Mecanismos Genéricos de Diseño y Construcción.

Técnicas y Prácticas •

Diagrama de Estructura.

•

Diagrama de Interacción de Objetos.

•

Diagrama de Clases

•

Sesiones de Trabajo − Diagrama de Interacción de Objetos.

•

Diagrama de Clases

Participantes •

Equipo de Arquitectura.

•

Equipo de Arquitectura

1. Diseño de Subsistemas de Soporte. El objetivo de esta tarea es la especificación y diseño de los módulos/clases que forman parte de los subsistemas de soporte, identificados en la tarea Identificación de Subsistemas de Diseño (DSI 1.5). Se lleva a cabo siempre y cuando no se disponga en la instalación de servicios comunes que respondan satisfactoriamente a los requisitos planteados. El nivel de reutilización de los subsistemas de soporte y sus servicios es potencialmente alto, de modo que se debe intentar emplear, en la medida de lo posible, los subsistemas que ya existan en la instalación y se consideren viables. La información relativa a dichos subsistemas podrá obtenerse del Histórico de Proyectos. En cualquier caso, cuando proceda realizar el diseño de los subsistemas de soporte, se recomienda hacerlo con ese fin. El diseño sigue las mismas pautas que las establecidas para los subsistemas específicos, aunque con las siguientes particularidades: • Generalmente, será necesaria una descomposición de los subsistemas de soporte en servicios, entendiendo como tales módulos o clases independientes y reutilizables. • Se recomienda realizar una descripción de la interfaz y del comportamiento de cada servicio, previa a su diseño de detalle, que permita completar el diseño de los subsistemas específicos. • La especificación y diseño de cada servicio, módulo o clase, se realiza con las técnicas habituales de especificación y diseño de módulos o clases, o incluso opcionalmente, si la simplicidad de los elementos lo aconseja, otros lenguajes de especificación, pseudocódigo o lenguaje natural. A medida que se lleva a cabo esta tarea pueden surgir comportamientos de excepción que deberán contemplarse igualmente en el diseño, y que en función del nivel de especificación que se haya establecido, se incorporan al catálogo de excepciones.


41


Productos. De entrada

Técnicas

Diseño de la Arquitectura del Sistema.

Diagrama de Estructura

De salida. Diseño Detallado de los Subsistemas de Soporte.

Diagrama de Interacción de Objetos Diagrama de Clases

Participantes Equipo de Arquitectura.

2. Identificación de Mecanismos Genéricos de Diseño. El objetivo es identificar y diseñar, en el caso de no existir en la instalación, esqueletos, patrones de diseño o guías de diseño. Estos mecanismos genéricos se definen a partir del estudio de comportamientos comunes relacionados, generalmente, con gestión de transacciones, persistencia de datos, control y recuperación de errores, utilización de recursos comunes, etc. Los mecanismos genéricos de diseño se aplican tanto en la definición de la arquitectura del sistema como en el diseño de los subsistemas. Productos De entrada Diseño de la Arquitectura del Sistema. De salida Mecanismos Genéricos de Diseño y Construcción.

Técnicas Diagrama de Interacción de Objetos Diagrama de Clases

Prácticas

Participantes

Sesiones de Trabajo

Equipo de Arquitectura


42

ANÁLISIS Y DISEÑO DE SISTEMAS Diseño de casos de uso reales. Esta actividad, que se realiza solo en el caso de Diseño Orientado a Objetos, tiene como propósito especificar el comportamiento del sistema de información para un caso de uso, Diseño del Sistema de Información mediante objetos o subsistemas de diseño que interactúan, y determinar las operaciones de las clases e interfaces de los distintos subsistemas de diseño. Para ello, una vez identificadas las clases participantes dentro de un caso de uso, es necesario completar los escenarios que se recogen del análisis, incluyendo las clases de diseño que correspondan y teniendo en cuenta las restricciones del entorno tecnológico, esto es, detalles relacionados con la implementación del sistema. Es necesario analizar los comportamientos de excepción para dichos escenarios. Algunos de ellos pueden haber sido identificados en el proceso de análisis, aunque no se resuelven hasta este momento. Dichas excepciones se añadirán al catálogo de excepciones para facilitar las pruebas. Algunos de los escenarios detallados requerirán una nueva interfaz de usuario. Por este motivo es necesario diseñar el formato de cada una de las pantallas o impresos identificados. Es importante validar que los subsistemas definidos en la tarea Identificación de Subsistemas de Diseño tienen la mínima interfaz con otros subsistemas. Por este motivo, se elaboran los escenarios al nivel de subsistemas y, de esta forma, se delimitan las interfaces necesarias para cada uno de ellos, teniendo en cuenta toda la funcionalidad del sistema que recogen los casos de uso. Además, durante esta actividad pueden surgir requisitos de implementación, que se recogen en el catálogo de requisitos. Las tareas de esta actividad se realizan en paralelo con las de Diseño de Clases. Tarea DSI

Identificación de

• Diseño de la Realización de los Casos de Uso o Especificación

Interacción de

Detallada.

Objetos

• Diagrama de

Diseño de la

• Diseño de la Realización de los

Realización de los

Casos de Uso o Especificación

Interacción de

Detallada.

Objetos.

Casos de Uso

• Diseño de Interfaz de Usuario: DSI


Clases Asociadas a un Caso de Uso

DSI

Productos

Revisión de la Interfaz de Usuario

• Diagrama de

• Catalogación

o Formatos Individuales de

Diagrama de

Interfaz de Pantalla Gráfica o

Transición de

Catálogo de Controles y

Estados Diagrama


Participantes • Equipo del Proyecto. • Equipo del Proyecto. • Equipo del Proyecto. • Usuarios Expertos

43

ANÁLISIS Y DISEÑO DE SISTEMAS Elementos de Diseño de Interfaz de Pantalla Gráfica o Modelo de Navegación de

de Interacción de Objetos. • Prototipado

Interfaz de Pantalla Gráfica o Formatos de Impresión o Prototipo de Interfaz de Pantalla Gráfica DSI

Revisión de Subsistemas de Diseño e Interfaces

• Diseño de la Realización de los

• Diagrama de

Casos de Uso o Definición a

Interacción de

Nivel de Subsistemas e Interfaz

Objetos.

• Equipo del Proyecto • Equipo de Arquitectura

1. Identificación de Clases Asociadas a un Caso de Uso. El objetivo de esta tarea es identificar las clases que intervienen en cada caso de uso, a partir del conjunto de clases definidas en la tarea Identificación de Clases Adicionales, ya que, como se ha señalado en la introducción de esta actividad, las actividades DSI 3 y DSI 4 se realizan en paralelo. Dichas clases se identifican a partir de las clases del modelo del análisis y de aquellas clases adicionales necesarias para el escenario que se está diseñando. A su vez, a medida que se va estudiando la descripción de los casos de uso, pueden aparecer nuevas clases de diseño que no hayan sido identificadas anteriormente y que se incorporan al modelo de clases en la tarea Identificación de Clases Adicionales. Productos. (Entrada)

Técnicas.

•De entrada •Modelo de Clases de Diseño. •Modelo de Casos de Uso. •Especificación de Casos de Uso. •Análisis de la Realización de los Casos de Uso. •De salida •Diseño de la Realización de los Casos de Uso o Especificación Detallada

•Diagrama de Interacción de Objetos

Participantes •Equipo de Proyecto

2. Diseño de la Realización de los Casos de Uso. El objetivo de esta tarea es definir cómo interactúan entre sí los objetos identificados en la tarea anterior para realizar, desde un punto de vista técnico, un caso de uso del sistema de información. Para ello, se parte de los


44

ANÁLISIS Y DISEÑO DE SISTEMAS escenarios especificados en el análisis, y se detallan teniendo en cuenta que se deben llevar cabo sobre un entorno tecnológico concreto y unos mecanismos genéricos de diseño. Durante el desarrollo de esta tarea, es posible que surjan excepciones que se incluyen en el catálogo de excepciones, y que ahora quedan resueltas en los escenarios correspondientes. Algunos de estos escenarios necesitan nueva interfaz de usuario. Por lo tanto, las clases de interfaz que se identifiquen se incorporan al modelo de clases de la tarea Identificación de Clases Adicionales, para realizar su diseño detallado. También se realiza el estudio de los escenarios de los distintos casos de uso, para identificar comportamientos comunes sobre los que se aplican mecanismos genéricos de diseño identificados en la tarea de Identificación de Mecanismos Genéricos de Diseño, o se puede decidir diseñar un subsistema de soporte que contenga dicho comportamiento, como un servicio. El estudio de los comportamientos comunes identificados puede servir de ayuda para detallar o revisar la herencia entre clases en la tarea Diseño de la Jerarquía. Productos. (Entrada)

Técnicas.

•De entrada •Modelo de casos de uso. •Especificación de casos de uso. •Análisis de la realización de los casos de uso. •Especificación de interfaz de usuario. •Diseño de la realización de los casos de uso. •De salida. •Diseño de la realización de los casos de uso o especificación detallada.

•Diagrama de interacción de objetos (colaboración o secuencia).

Participantes •Equipo de proyecto.

3. Revisión de la Interfaz de Usuario. El objetivo de esta tarea es realizar el diseño detallado del comportamiento de la interfaz de usuario a partir de la especificación de la misma, obtenida en el proceso de análisis, y de acuerdo con el entorno tecnológico definido. Si se hubiera realizado un prototipo de la interfaz de usuario, éste se tomaría como punto de partida para el diseño. Además, se incluyen las ventanas alternativas o elementos de diseño surgidos como consecuencia del diseño de los escenarios definidos en la tarea anterior.


45

ANÁLISIS Y DISEÑO DE SISTEMAS Además, se revisa: la interfaz de usuario, la navegación entre ventanas, los elementos que forman cada interfaz, sus características (que deben ser consistentes con los atributos con los que están relacionadas), su disposición, y cómo se gestionan los eventos relacionados con los objetos. En aquellos casos en los que se realizan modificaciones significativas sobre la interfaz de usuario, es conveniente que éste las valide, siendo opcional la realización de un nuevo prototipo.

Productos. (Entrada)

Técnicas.

•De entrada •Diseño de la eealización de los casos de uso. •Especificación de interfaz de usuario de salida. •Diseño de interfaz de usuario o formatos individuales de interfaz de pantalla gráfica. •Catálogo de controles y elementos de diseño de interfaz de pantalla gráfica o modelo de navegación de interfaz de pantalla gráfica o formatos de impresión •Prototipo de interfaz de pantalla gráfica.

•Diagrama de interacción de objetos. •Diagrama de transición de estados.

Prácticas •Prototipado •Catalogación

Participantes •Prototipado. •Catalogación. •Equipo del proyecto. •Usuarios expertos.

4. Revisión de Subsistemas de Diseño e Interfaces. El objetivo de esta tarea es describir cada caso de uso en términos de los subsistemas que participan en el caso de uso y las interfaces que se requieren entre ellos. Para un caso de uso hay que definir, además de los subsistemas y actores que intervienen en el mismo, los mensajes que intercambian los objetos de un subsistema con otro. Estos mensajes sirven para verificar y detallar las interfaces de cada subsistema, teniendo en cuenta todos los casos de uso en los que interviene, y completar de esta manera la definición de subsistemas establecida en la tarea Identificación de Subsistemas de Diseño.


46

ANÁLISIS Y DISEÑO DE SISTEMAS Productos. (Entrada)

Técnicas.

•De entrada •Modelo de Casos de Uso. •Especificación de Casos de Uso. •Diseño de la Realización de los Casos de Uso. •De salida •Diseño de la Realización de los Casos de Uso o Definición a Nivel de Subsistemas e Interfaz

•Diagrama de Interacción de Objetos

Participantes •Equipo del Proyecto •Equipo de Arquitectura

Diseño de clases. El propósito de esta actividad, que se realiza sólo en el caso de Diseño Orientado a Objetos, es transformar el modelo de clases lógico, que proviene del análisis, en un modelo de clases de diseño. Dicho modelo recoge la especificación detallada de cada una de las clases, es decir, sus atributos, operaciones, métodos, y el diseño preciso de las relaciones establecidas entre ellas, bien sean de agregación, asociación o jerarquía. Para llevar a cabo todos estos puntos, se tienen en cuenta las decisiones tomadas sobre el entorno tecnológico y el entorno de desarrollo elegido para la implementación. Se identifican las clases de diseño, que denominamos clases adicionales, en función del estudio de los escenarios de los casos de uso, que se está realizando en paralelo en la actividad Diseño de Casos de Uso Reales y aplicando los mecanismos genéricos de diseño que se consideren convenientes por el tipo de especificaciones tecnológicas y de desarrollo. Entre ellas se encuentran clases abstractas, que integran características comunes con el objetivo de especializarlas en clases derivadas. Se diseñan las clases de interfaz de usuario, que provienen del análisis. Como consecuencia del estudio de los escenarios secundarios que se está realizando, pueden aparecer nuevas clases de interfaz. También hay que considerar que, por el diseño de las asociaciones y agregaciones, pueden aparecer nuevas clases, o desaparecer incluyendo sus atributos y métodos en otras, si se considera conveniente por temas de optimización. La jerarquía entre las clases se va estableciendo a lo largo de esta actividad, a medida que se van identificando comportamientos comunes en las clases, aunque haya una tarea propia de diseño de la jerarquía.


47

ANÁLISIS Y DISEÑO DE SISTEMAS Otro de los objetivos del diseño de las clases es identificar para cada clase, los atributos, las operaciones que cubren las responsabilidades que se identificaron en el análisis, y la especificación de los métodos que implementan esas operaciones, analizando los escenarios del Diseño de Casos de Uso Reales. Se determina la visibilidad de los atributos y operaciones de cada clase, con respecto a las otras clases del modelo. Una vez que se ha elaborado el modelo de clases, se define la estructura física de los datos correspondiente a ese modelo, en la actividad Diseño Físico de Datos. Además, en los casos en que sea necesaria una migración de datos de otros sistemas o una carga inicial de información, se realizará su especificación a partir del modelo de clases y las estructuras de datos de los sistemas origen. Como resultado de todo lo anterior se actualiza el modelo de clases del análisis, una vez recogidas las decisiones de diseño. Tarea DSI

Identificación de

•

Clases Adicionales Diseño de

DSI

Productos

Asociaciones y

Diseño •

DSI

Atributos de las

•

DSI

Operaciones de las Clases

DSI

Diseño de la

DSI

•

Métodos de las

Modelo de Clases

de Diseño • •

Jerarquía Descripción de

Modelo de Clases de Diseño

Clases Identificación de


Agregaciones Identificación de

Modelo de Clases de

Diagrama de Clases

•

Diagrama de Clases

•

Diagrama de Clases

•

Diagrama de Clases

•

Diagrama de Transición de

Clases de Diseño

Estados

Modelo de Clases de


Operaciones

•

Comportamiento de

Diseño •


•

Diagrama de Clases

•

Diagrama de Clases

Especificación de DSI

Necesidades de Migración y Carga

•

Plan de Migración y Carga Inicial de Datos

•

Sesiones de Trabajo

Inicial de Datos

Participantes •

Equipo del Proyecto.

•


•


•


•


•


•

Analistas.

•

Usuarios Expertos.

1. Identificación de Clases Adicionales. El objetivo de esta tarea es identificar un conjunto de clases que completen el modelo de clases analizado en la tarea Validación de los Modelos del proceso anterior (clases y/o interfaces) teniendo en cuenta que:


48

ANÁLISIS Y DISEÑO DE SISTEMAS • Cada interfaz identificada en el análisis se corresponde en el diseño con una clase que proporcione esa interfaz. • El conjunto de clases del análisis puede modificarse en función de las tecnologías de desarrollo utilizadas y de los mecanismos genéricos de diseño especificados. Las clases de control deben contemplar la coordinación y secuencia entre objetos y, en algunos casos, deben contener lógica de negocio. De cualquier manera, se deben considerar cuestiones de distribución, de rendimiento, de transacción y de serialización. El diseño de las clases de entidad varía según el sistema de gestión de datos utilizado. Las clases pueden ser construidas por el propio desarrollador, adquiridas en forma de bibliotecas, facilitadas por el entorno de trabajo o por el entorno tecnológico. El diseño de las clases de interfaz de usuario depende de la tecnología específica que se esté utilizando. Así, por ejemplo, la interfaz puede crearse a partir de los objetos gráficos disponibles en el entorno de desarrollo, sin necesidad de que estos se contemplen en el modelo de clases correspondiente. Entre las clases identificadas a lo largo de esta tarea se encuentran clases abstractas, que reúnen características comunes a varias clases. Cada subclase aumenta su estructura y comportamiento con la clase abstracta de la que hereda.

Productos. (Entrada) •De entrada •Modelo de Clases de Análisis •Especificación de Interfaz de Usuario •De salida •Modelo de Clases de Diseño

Técnicas. •Diagrama de Clases.

Participantes •Equipo del Proyecto

2. Diseño de Asociaciones y Agregaciones. En esta tarea se completan las asociaciones entre las clases del modelo de clases del diseño, estudiando la secuencia de mensajes entre los objetos correspondientes en el diagrama de interacción de los escenarios definidos en la tarea Descripción de la Interacción entre Objetos. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

49

ANÁLISIS Y DISEÑO DE SISTEMAS Para definir las asociaciones, partimos de las que fueron identificadas en la tarea Identificación de Asociaciones y Agregaciones teniendo en cuenta que: • Las características de la asociación (papeles que desempeña, multiplicidad, etc.) se detallan según el entorno de desarrollo utilizado. • Las relaciones bidireccionales se transforman en unidireccionales, para simplificar la implementación del sistema. • Se realiza la modelización de las rutas de acceso óptimas entre las asociaciones para evitar problemas de rendimiento. • Se analiza la posibilidad de diseñar como clases algunas de las asociaciones. • Opcionalmente, se especifica la forma en la que se va a implementar cada asociación (punteros, colecciones, etc.).

Productos. (Entrada) • De entrada • Modelo de Clases de Análisis • Modelo de Clases de Diseño • De salida • Modelo de Clases de Diseño

Técnicas. • Diagrama de Clases.

Participantes • Equipo del Proyecto

3. Identificación de Atributos de las Clases. El objetivo de esta tarea es identificar y describir, una vez que se ha especificado el entorno de desarrollo, los atributos de las clases. Para identificar los atributos se revisa el modelo de clases obtenido en el proceso de Análisis del Sistema de Información, considerando que, a partir de uno de ellos, puede ser necesario definir atributos adicionales. Para cada atributo identificado se define su tipo, con formatos específicos, y si existieran, las restricciones asociadas a ese atributo. Asimismo, se analiza la posibilidad de convertir un atributo en clase en aquellos casos en los que: • El atributo se defina en varias clases de diseño. • La complejidad del atributo aumente la dificultad para comprender la clase a la que pertenece.


50


Productos. (Entrada) •De entrada •Modelo de Clases de Análisis •Modelo de Clases de Diseño •De salida •Modelo de Clases de Diseño

Técnicas. •Diagrama de Clases.


4. Identificación de Operaciones de las Clases. El objetivo de esta tarea es definir, de forma detallada, las operaciones de cada clase de diseño. Para ello, se toma como punto de partida el modelo de clases generado en el análisis, así como el diseño de los casos de uso reales y los requisitos de diseño que pueden aparecer al definir el entorno de desarrollo. Las operaciones de las clases de diseño surgen para dar respuesta a las responsabilidades de las clases de análisis y, además, para definir las interfaces que ofrece esa clase. Según el entorno de desarrollo utilizado, se describe cada operación especificando: su nombre, parámetros y visibilidad (pública, privada, protegida). Si el entorno de desarrollo lo permite, se tiene en cuenta la posibilidad de simplificar el modelo de clases haciendo uso del polimorfismo y la sobrecarga de operaciones. Para identificar las operaciones de aquellos objetos que presenten distintos estados, por lo que su comportamiento depende del estado en el que se encuentren, es recomendable realizar un diagrama de transición de estados, y traducir cada acción o actividad del mismo en una de estas operaciones.

Productos. (Entrada) •De entrada •Modelo de Clases de Análisis •Comportamiento de Clases de Análisis •Modelo de Clases de Diseño •De salida •Comportamiento de Clases de Diseño •Modelo de Clases de Diseño

Técnicas. •Diagrama de Clases •Diagrama de Transición de Estados



51

ANÁLISIS Y DISEÑO DE SISTEMAS 5. Diseño de la Jerarquía. El objetivo de esta tarea es revisar la jerarquía de clases que ha surgido en el modelo de clases a lo largo de las tareas anteriores y comprobar que esa jerarquía es viable según los mecanismos disponibles en el entorno de desarrollo utilizado. Entre las modificaciones realizadas sobre la jerarquía se identifican clases abstractas, que son superclases en las que se agrupan atributos y operaciones que heredan sus subclases. Productos. •De entrada •Modelo de Clases de Diseño •De salida •Modelo de Clases de Diseño

Técnicas. •Diagrama de Clases


6. Descripción de Métodos de las Operaciones. En esta tarea se describen los métodos que se usan para detallar como se realiza cada una de las operaciones de una clase. Los métodos pueden especificarse mediante un algoritmo, usando pseudocódigo o lenguaje natural. Su implementación se basa en la secuencia de interacciones del diagrama de interacción en los que la clase aparezca o en la secuencia de transiciones del diagrama de transición de estados. En la mayoría de los casos, esta tarea no se realiza hasta el proceso de construcción, en el que los métodos se describen directamente en el lenguaje de programación que se va a utilizar.

Productos. •De entrada •Modelo de Clases de Diseño. •Comportamiento de Clases de Diseño. •De salida •Modelo de Clases de Diseño

Técnicas. •Diagrama de Clases


7. Especificación de Necesidades de Migración y Carga Inicial de Datos. En esta tarea se realiza, en los casos que sea necesario y a partir de los resultados de la tarea, una primera especificación de las necesidades de ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

52

ANÁLISIS Y DISEÑO DE SISTEMAS migración o carga inicial de los datos requeridos por el sistema, que se completa en la actividad Diseño de la Migración y Carga Inicial de Datos.

Productos. •De entrada •Estructura de Datos del Sistema Origen (externo) •Modelo de Clases de Diseño •Plan de Migración y Carga Inicial de Datos •De salida •Plan de Migración y Carga Inicial de Datos

Practicas. •Sesiones de trabajo.

Participantes •Analista. •Usuarios Expertos.

Diseño de la arquitectura de módulos del sistema. El objetivo de esta actividad, que sólo se realiza en el caso de Diseño Estructurado, es definir los módulos del sistema de información, y la manera en que van a interactuar unos con otros, intentando que cada módulo trate total o parcialmente un proceso específico y tenga una interfaz sencilla. Para cada uno de los subsistemas específicos, identificados en la tarea Identificación de los Subsistemas de Diseño, se diseña la estructura modular de los procesos que lo integran, tomando como punto de partida los modelos obtenidos en la tarea Validación de los Modelos del proceso de Análisis del Sistema de Información (ASI) y el catálogo de requisitos. Dicha estructura se irá completando con los módulos que vayan apareciendo como consecuencia del diseño de la interfaz de usuario, así como de la optimización del diseño físico de datos. Durante el diseño de los módulos, se pueden identificar características o comportamientos comunes relacionados con accesos a las bases de datos o ficheros, lógica de tratamiento, llamadas a otros módulos, gestión de errores, etc. que determinen la necesidad de realizar su implementación como subsistemas de soporte. Además, se analizan los comportamientos de excepción asociados a los diferentes módulos y a las interfaces entre los mismos, intentando independizar en la medida de lo posible aquéllos que presenten un tratamiento común. Dichas excepciones se incorporan al catálogo de excepciones.


53

ANÁLISIS Y DISEÑO DE SISTEMAS En esta fase se consideran los estándares y normas establecidas para el diseño, aplicando, cuando proceda, los mecanismos genéricos de diseño identificados en la tarea Identificación de Mecanismos Genéricos de Diseño. Las tareas de esta actividad no se realizan de forma secuencial, sino en paralelo, con continuas realimentaciones entre ellas y con las realizadas en las actividades Definición de la Arquitectura del Sistema, Diseño de la Arquitectura de Soporte y Diseño Físico de Datos. Tarea

DSI

Diseño de Módulos del Sistema

•

Diseño de la Arquitectura Modular del Sistema

• DSI


Productos

Diseño de la Arquitectura Modular del Sistema

Diseño de Comunicaciones entre Módulos

Participantes •

•


• •

•


• •

Equipo de Arquitectura. Equipo del Proyecto. Equipo de Arquitectura. Equipo del Proyecto. Equipo de Seguridad.

•

DSI

Revisión de la Interfaz de Usuario

Diseño de Interfaz de Usuario: Descomposición Funcional en Diálogos o Formatos Individuales de Interfaz de Pantalla Catálogo de Controles y Elementos de Diseño de Interfaz de Pantalla. Modelo de Navegación de Interfaz de Pantalla Formatos de Impresión o Prototipo de Interfaz de Pantalla o Prototipo de Interfaz de Impresión

• •

• • •

Diagrama de Descomposición Funcional Diagrama de Transición de Estados. Matricial Catalogación Prototipo

• •

Equipo del Proyecto. Usuarios Expertos

1. Diseño de Módulos del Sistema. El objetivo de esta tarea es realizar una descomposición modular de los subsistemas específicos identificados en la tarea Identificación de Subsistemas de Diseño, a partir del modelo de procesos obtenido en el proceso Análisis del Sistema de Información. En esta tarea también se diseñan los módulos de consulta, generalmente no especificados en el modelo de procesos, aunque sí en el catálogo de requisitos. Como paso previo al diseño de la estructura modular del sistema, se identifican los procesos que se van a implementar en cada subsistema específico. Para cada uno de ellos se establece el tipo de implementación y el tipo de iniciación.


54

ANÁLISIS Y DISEÑO DE SISTEMAS A su vez, se analiza el alcance y características propias de cada proceso con el fin de determinar qué parte gestiona el acceso a la información soportada en bases de datos, qué parte se encarga de integrar las funcionalidades necesarias para cumplir las reglas del negocio y, en el caso de tratamiento en línea, qué parte gestiona la presentación de la información en los dispositivos de interfaz con los que el usuario va a interactuar. Este análisis permite identificar los procesos que son específicos del propio sistema y aquéllos que comparten servicios comunes o dan respuesta a los mismos requisitos, y como consecuencia, considerar la posibilidad de independizar dichos servicios e implementarlos como subsistemas de soporte, teniendo en cuenta que su incorporación puede llevar a una reorganización de los subsistemas inicialmente identificados en la actividad Definición de la Arquitectura del Sistema. De acuerdo a la arquitectura propuesta y al resultado del análisis de cada proceso, se diseña su estructura en módulos considerando los comportamientos de excepción correspondientes, en sucesivos niveles de detalle, de forma que los módulos resultantes tengan el mínimo acoplamiento y la máxima cohesión. Finalmente, se especifica la lógica interna de tratamiento por medio de lenguaje natural o pseudocódigo. La estructura modular refleja, en el caso de tratamiento en línea, las sucesivas transacciones y diálogos, y en el caso de implementación en lotes, la secuencia de módulos dentro de cada ejecución. En sistemas interactivos en los que exista una gran complejidad de gestión de pantalla se propone, complementariamente al diagrama de estructura de cuadros, perfeccionar el diseño de la interfaz de usuario en la tarea Revisión de la Interfaz de Usuario, relacionando cada control/evento/acción de los formatos individuales de presentación de pantalla con los respectivos módulos.


55


Productos. •De entrada •Modelo de Procesos •Especificación de Interfaz de Usuario. •Descripción de Interfaz con otros Sistemas. •Matriz de Procesos / Localización. •Diseño de la Arquitectura del Sistema. •De salida •Diseño de la Arquitectura Modular del Sistema.

Tècnicas. • Diagrama de Estructura

Participantes • Equipos de Arquitectura. • Equipo de Proyecto.

2. Diseño de Comunicaciones entre Módulos. El objetivo de esta tarea es definir las interfaces entre los módulos de cada subsistema, entre subsistemas y con el resto de los sistemas, incluyendo tanto la comunicación de control como los datos propios del sistema, de acuerdo a la arquitectura propuesta y a las características del entorno tecnológico. Hay que definir interfaces sencillas, que permitan reducir la complejidad de comunicación entre los distintos módulos, especialmente los relacionados con las comunicaciones entre subsistemas. Por tanto, la especificación de la estructura modular obtenida en la tarea anterior se completa con la descripción de las comunicaciones existentes entre los distintos módulos, considerando los requisitos establecidos inicialmente para el sistema. Para garantizar el cumplimiento de dichos requisitos y especialmente los relacionados con el rendimiento, disponibilidad y seguridad, puede ser necesaria la incorporación de nuevos módulos o rediseñar la lógica asociada. Para el diseño de las interfaces es necesario especificar:  Los datos o mensajes involucrados y formato de los mismos en el intercambio.  Los valores o rangos de los datos intercambiados.  El origen y destino de los datos.  La información de control y valores posibles. En el diseño de las interfaces con otros sistemas hay que tener en cuenta, además, la información recogida en la descripción de interfaz con otros sistemas obtenida en el proceso de Análisis del Sistema del Información.


56

ANÁLISIS Y DISEÑO DE SISTEMAS Las interfaces entre módulos permiten evaluar las necesidades de comunicación entre los distintos nodos, de modo que influyen decisivamente en el dimensionamiento del entorno tecnológico.

Productos. •De entrada •Modelo de Procesos. •Descripción de Interfaz con otros Sistemas. •Diseño de la Arquitectura Modular del Sistema. •De salida •Diseño de la Arquitectura Modular del Sistema

Tècnicas. •Diagrama de Estructura

Participantes •Equipo de Arquitectura •Equipo del Proyecto •Equipo de Seguridad.

3. Revisión de la Interfaz de Usuario. El objetivo de esta tarea es realizar el diseño detallado de la interfaz de usuario, tanto de pantalla como impresa, a partir de la especificación obtenida en el proceso de Análisis del Sistema de Información, de acuerdo al entorno tecnológico seleccionado y considerando los estándares y directrices marcados por la instalación. Se revisa la descomposición funcional en diálogos de acuerdo a la arquitectura modular para el sistema de información definida en la tarea anterior. Se realizan las adaptaciones oportunas, teniendo en cuenta, a su vez, los requisitos de rendimiento, de seguridad, la necesidad de alcanzar los tiempos de respuesta establecidos y las características de cada diálogo. Asimismo, se revisa en detalle la navegación entre ventanas y la información precisa para la ejecución de cada diálogo, identificando las relaciones de dependencia entre los datos para establecer la secuencia de presentación más apropiada. Se determinan los datos obligatorios y opcionales, y aquéllos que requieren un rango de valores predefinido o algún tipo de información que se considere relevante en el contexto del diálogo. Se definen las ventanas alternativas o elementos de diseño necesarios, especificando su contenido. Se comprueba que la información necesaria en cada interfaz, tanto de pantalla como impresa, es tratada por el módulo correspondiente de la arquitectura del sistema, y es consistente con el modelo físico de datos que se está elaborando en paralelo en la actividad Diseño Físico de Datos. En diálogos complejos, se propone utilizar como base de la especificación el modelo de navegación de interfaz de pantalla, relacionando cada ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

57

ANÁLISIS Y DISEÑO DE SISTEMAS control/evento/acción de los formatos individuales de presentación de pantalla con el módulo correspondiente, especificado en la tarea Diseño de Módulos del Sistema. Igualmente, se realiza el diseño de los mensajes de error, mensajes de aviso o advertencia que genera el sistema en función del tipo de acción realizado por el usuario en el contexto del diálogo, así como las facilidades de ayuda que proporciona la interfaz durante la interacción con el sistema. En el caso de que las modificaciones sean significativas en cuanto al formato o la definición de diálogos, se propone una validación por parte del usuario, con la realización opcional de prototipos para facilitar la revisión y aceptación.

Productos. •De entrada •Especificación de Interfaz de Usuario. •Diseño de la Arquitectura Modular del Sistema •De salida •Diseño de Interfaz de Usuario: •Descomposición Funcional en Diálogos o Formatos Individuales de Interfaz de pantalla •Catálogo de Controles.

Tècnicas. •Diagrama de Descomposición Funcional. •Diagrama de Transición de Estados. •Matricial.

Participantes •Equipo del Proyecto •Usuarios Expertos.

En el caso de las Prácticas tomar en cuenta la catalogación y prototipo.

Diseño físico de datos. En esta actividad se define la estructura física de datos que utilizará el sistema, a partir del modelo lógico de datos normalizado o modelo de clases, de manera que teniendo presentes las características específicas del sistema de gestión de datos concreto a utilizar, los requisitos establecidos para el sistema de información, y las particularidades del entorno tecnológico, se consiga una mayor eficiencia en el tratamiento de los datos.


58

ANÁLISIS Y DISEÑO DE SISTEMAS También se analizan los caminos de acceso a los datos utilizados por cada módulo/clase del sistema en consultas y actualizaciones, con el fin de mejorar los tiempos de respuesta y optimizar los recursos de máquina. Las tareas de esta actividad se realizan de forma iterativa y en paralelo con las realizadas en las actividades Definición de la Arquitectura del Sistema, dónde se especifican los detalles de arquitectura e infraestructura y la planificación de capacidades, Diseño de la Arquitectura de Soporte, dónde se determinan y diseñan los servicios comunes que pueden estar relacionados con la gestión de datos, Diseño de Casos de Uso Reales y de Clases, para desarrollo orientado a objetos, y Diseño de la Arquitectura de Módulos del Sistema, para desarrollo estructurado, dónde se especifica la lógica de tratamiento y las interfaces utilizadas. En el caso de diseño orientado a objetos, esta actividad también es necesaria. La obtención del modelo físico de datos se realiza aplicando una serie de reglas de transformación a cada elemento del modelo de clases que se está generando en la actividad Diseño de Clases. Asimismo, en esta actividad hay que considerar los estándares y normas establecidos para el diseño aplicando, cuando proceda, los mecanismos genéricos de diseño identificados en la tarea Identificación de Mecanismos Genéricos de Diseño. Tarea

DSI

Diseño del Modelo Físico de Datos

• Modelo Físico de Datos

DSI

Especificación de los Caminos de Acceso a los Datos

• Especificación de los Caminos de Acceso a los Datos

DSI

Optimización del Modelo Físico de Datos

DSI

Especificación de la Distribución de Datos


Productos

• Modelo Físico de Datos Optimizado

• •

Esquemas Físicos de Datos Asignación esquemas Físicos de Datos a Nodos.

• Reglas de Obtención del Modelo Físico a Partir del Lógico • Reglas de Transformación • Cálculo de Accesos Físicos. • Caminos de Acceso.

• Optimización

Participantes • Equipo de Arquitectura • Equipo del Proyecto • Administradores de Bases de Datos • Equipo del Proyecto. • Equipo de Arquitectura • Equipo del Proyecto. • Administradores de Bases de Datos. • Equipo de Seguridad.

• •

Matricial


•

Equipo de Arquitectura. Equipo de Soporte Técnico.

59

ANÁLISIS Y DISEÑO DE SISTEMAS 1. Diseño del Modelo Físico de Datos. El objetivo de esta tarea es realizar el diseño del modelo físico de datos a partir del modelo lógico de datos normalizado o del modelo de clases, en el caso de diseño orientado a objetos. Como paso previo al diseño de la estructura física de datos, se analizan las peculiaridades técnicas del gestor de bases de datos o sistema de ficheros a utilizar, y las estimaciones sobre la utilización y volumen de las ocurrencias de cada entidad / clase del modelo lógico de datos normalizado o modelo de clases. Además, si se ha establecido la necesidad de llevar a cabo una migración de datos, se deben tener en cuenta también los volúmenes de las estructuras de datos implicadas en la conversión. Esta información sirve para decidir la mejor implementación del modelo lógico de datos/modelo de clases, así como para hacer una estimación del espacio de almacenamiento. De acuerdo al análisis anterior, se determina cómo se van a convertir las entidades/clases en tablas, considerando las relaciones existentes entre ellas y los identificadores, definiendo sus claves primarias, ajenas, alternativas u otros medios de acceso en general. También se definen aquellos elementos que, en función del gestor o sistemas de ficheros a utilizar, se considere necesario implementar. Entre estos elementos podemos citar los siguientes: • Bloqueo y comprensión de datos. • Agrupamientos (clúster). • Punteros. Otros. Productos. •De entrada •Características Específicas del SGBD o Sistemas de Ficheros a Utilizar (externo) •En Análisis Estructurado: •Modelo Lógico de Datos Normalizado. •Plan de Migración y Carga Inicial de Datos. •En Análisis Orientado a Objetos: •Modelo de Clases de Diseño y Migracion de datos. •De salida. •Modelo Físico de Datos.

Tècnicas. •Reglas de Obtención del Modelo Físico a partir del Lógico. •Reglas de Transformación.


Participantes •Equipo de Arquitectura. •Equipo del Proyecto. •Administradores de Bases de Datos.

60

ANÁLISIS Y DISEÑO DE SISTEMAS 2. Especificación de los Caminos de Acceso a los Datos. El objetivo de esta tarea es determinar los caminos de acceso a los datos persistentes del sistema, utilizados por los principales módulos/clases de acuerdo al modelo físico de datos, con el fin de optimizar el rendimiento de los gestores de datos o sistemas de ficheros y el consumo de recursos, así como disminuir los tiempos de respuesta. Se recomienda realizar esta tarea para aquellos módulos/clases que reúnan, entre otras, alguna de las siguientes características: • Tratamiento crítico. • Concurrencia. • Accesos complejos a datos. Para el inicio de esta tarea, se toma como referencia el Diseño Detallado de los Subsistemas de Soporte y el Diseño de la Arquitectura Modular o Diseño de Clases de los subsistemas específicos, productos que se están generando en paralelo a esta actividad. Para cada módulo / clase se identifican las tablas o ficheros y el tipo de acceso realizado, así como el orden que debe seguirse para la obtención de los datos. Asimismo, se efectúa una estimación del número de accesos que deben realizarse teniendo en cuenta, a su vez, la frecuencia y la prioridad del acceso. La información obtenida sirve para identificar accesos excesivamente costosos o redundantes que pueden comprometer el rendimiento final del sistema y que, por lo tanto, exigen la optimización del modelo físico de datos, mediante la creación de nuevos accesos, posibles desnormalizaciones o particiones del modelo físico de datos. Productos. •De entrada. •Modelo Físico de Datos. •Diseño Detallado de Subsistemas de Soporte. •En Diseño Estructurado: •Diseño de la Arquitectura Modular del Sistema. •En Diseño Orientado a Objetos: •Modelo de Clases de Diseño. •De salida. •Especificación de los Caminos de Acceso a los Datos.

Prácticas. •Reglas de Obtención del Modelo Físico a partir del Lógico. •Reglas de Transformación.


Participantes •Equipo del Proyecto.

61

ANÁLISIS Y DISEÑO DE SISTEMAS 3. Optimización del Modelo Físico de Datos. En esta tarea se optimiza el diseño físico de datos, con el objetivo de mejorar el tiempo de respuesta en el acceso a datos persistentes, hacer una adecuada utilización de los recursos del sistema y, en consecuencia, garantizar que el diseño satisface las necesidades de tratamiento establecidas para el sistema de información en cuanto a que se ajusta a los requisitos de rendimiento exigidos. A partir de la especificación de la secuencia de accesos de aquellos módulos/clases identificados como críticos, obtenida en la tarea anterior, se detectan las posibles mejoras con el fin de conseguir los niveles de rendimiento establecidos y, por lo tanto, una mayor eficiencia del sistema. Como resultado, puede ser necesaria una desnormalización controlada que se aplica para reducir o simplificar el número de accesos a los sistemas de almacenamiento de datos. La desnormalización puede obligar a: • Introducir elementos redundantes (campos, campos derivados, etc.). • Definir nuevos caminos de acceso. • Redefinir relaciones. • Dividir o unir tablas. En la revisión de la estructura física de datos se deben tener en cuenta criterios relacionados con: • Módulos / clases identificados como críticos. • Estimación de volúmenes. • Frecuencia y tipo de acceso. • Estimaciones de crecimiento por periodo. • Requisitos relativos al rendimiento, seguridad, disponibilidad, entre otros, considerados relevantes.

confidencialidad

y

Es importante que la desnormalización se lleve a cabo de una forma controlada, para evitar anomalías en el tratamiento de los datos.


62

ANÁLISIS Y DISEÑO DE SISTEMAS Productos. •De entrada •Características Específicas del SGBD o Sistemas de Ficheros a Utilizar (externo) •En Análisis Estructurado: •Modelo Lógico de Datos Normalizado. •Plan de Migración y Carga Inicial de Datos. •En Análisis Orientado a Objetos: •Modelo de Clases de Diseño y Migracion de datos. •De salida. •Modelo Físico de Datos.

Tècnicas. •Optimización.

Participantes •Equipo de Arquitectura. •Equipo del Proyecto. •Administradores de Bases de Datos. •Equipo de Seguridad.

Especificación de la Distribución de Datos. En esta tarea se determina el modelo de distribución de datos, teniendo en cuenta los requisitos de diseño establecidos. Se establece la ubicación de los gestores de bases de datos o sistemas de ficheros, así como de los distintos elementos de la estructura física de datos, en los nodos correspondientes, de acuerdo al particionamiento físico del sistema de información especificado en la actividad Diseño de la Arquitectura del Sistema. El resultado de esta actividad es la especificación de los modelos físicos particulares de cada nodo, esquemas físicos de datos, así como su asignación a los nodos.


63

ANÁLISIS Y DISEÑO DE SISTEMAS Productos. •De entrada. •Diseño de la Arquitectura del Sistema o Particionamiento Físico del Sistema de Información Catálogo de Requisitos Modelo Físico de Datos Optimizado. •De salida. •Esquemas Físicos de Datos. •Asignación Esquemas Físicos de Datos a Nodos

Tècnicas. •Matricial.

Participantes •Equipo de Arquitectura. •Equipo de Soporte Técnico.

Verificación y aceptación de la arquitectura del sistema. El objetivo de esta actividad es garantizar la calidad de las especificaciones del diseño del sistema de información y la viabilidad del mismo, como paso previo a la generación de las especificaciones de construcción. Para cumplir dicho objetivo, se llevan a cabo las siguientes acciones: • Verificación de la calidad técnica de cada modelo o especificación • Aseguramiento de la coherencia entre los distintos modelos • Aceptación del diseño de la arquitectura por parte de Explotación y Sistemas. Esta actividad es compleja, por lo que es aconsejable utilizar herramientas de apoyo para la realización de sus tareas. Tarea

DSI

Verificación de las Especificaciones de Diseño

Productos


• Entorno Tecnológico del Sistema • Diseño de la Arquitectura del Sistema • Diseño Detallado de Subsistemas de Soporte • Modelo Físico de Datos Optimizado • Esquemas Físicos de Datos • Asignación de Esquemas Físicos de Datos a Nodos


Participantes • •

Equipo de Arquitectura Equipo del Proyecto

64


DSI

Análisis de Consistencia de las Especificaciones de Diseño

DSI

Aceptación de la Arquitectura del Sistema

• Diseño de Interfaz de Usuario Estructurado: • Diseño de la Arquitectura Modular Orientación a Objetos: • Diseño de la Realización de los Casos de Uso. • Modelo de Clases de Diseño. • Comportamiento de Clases de Diseño. • Entorno Tecnológico del Sistema. • Diseño de la Arquitectura del Sistema • Diseño Detallado de Subsistemas de Soporte. • Modelo Físico de Datos Optimizado • Esquemas Físicos de Datos • Asignación de Esquemas Físicos de Datos a Nodos. • Diseño de Interfaz de Usuario Estructurado: • Diseño de la Arquitectura Modular Orientación a Objetos: • Diseño de la Realización de los Casos de Uso • Modelo de Clases de Diseño • Comportamiento de Clases de Diseño •

• •

Matricial

Aceptación Técnica del Diseño

•

• • •

Equipo de Arquitectura. Equipo del Proyecto.

Jefe de Proyecto Responsable de Operación Responsable de Sistemas

1. Verificación de las Especificaciones de Diseño. El objetivo de esta tarea es asegurar la calidad formal de los distintos modelos, conforme a la técnica seguida para la elaboración de cada producto y a las normas y estándares especificados en el catálogo de normas. 2. Análisis de Consistencia de las Especificaciones de Diseño. El objetivo de esta tarea es asegurar que las especificaciones del diseño son coherentes entre sí, comprobando la falta de ambigüedades o duplicación de


65

ANÁLISIS Y DISEÑO DE SISTEMAS información. Esta consistencia se asegura entre especificaciones de diseño, y con respecto a los modelos del análisis. Las diferentes comprobaciones se fundamentan generalmente en técnicas matriciales o de revisión entre los elementos comunes de los distintos modelos. El análisis de consistencia relativo a la arquitectura del sistema es común para desarrollo estructurado y orientado a objetos, aunque respecto a los productos del diseño detallado es específico para cada uno de los enfoques. Las verificaciones que se hacen son las siguientes: • Arquitectura del Sistema / Subsistemas. • Cada subsistema de diseño está asociado al menos con un nodo del particionamiento físico del sistema de información. • Arquitectura del Sistema / Modelo Físico de Datos. • Todos los elementos definidos en el Modelo Físico de Datos Optimizado se incorporan, al menos, en un esquema físico de datos. • Cada esquema del Modelo Físico de Datos está asociado con un nodo del particionamiento físico del sistema de información. Arquitectura del Sistema / Entorno Tecnológico del Sistema de Información: Cada nodo del particionamiento del sistema de información está soportado por el entorno tecnológico. Se da soporte a todas las necesidades de comunicaciones entre nodos. Arquitectura del Sistema / Diseño Detallado de Subsistemas: • Cada módulo o clase del diseño detallado pertenece al menos a un subsistema. • La interfaz del subsistema está proporcionada por interfaces de módulos o clases internas al subsistema. • La especificación de dependencias mediante el estudio de las interfaces entre subsistemas, ya que la existencia de interfaz implica el establecimiento de una dependencia. Catálogo de Excepciones / Diseño Detallado de Subsistemas: • Cada excepción del catálogo es tratada en el diseño de detalle del sistema de información, según los criterios establecidos en la creación del catálogo. Los análisis de consistencia específicos para el Diseño Estructurado son: • Diseño Detallado de Subsistemas / Modelo Físico de Datos: • Los elementos del modelo físico de datos corresponden con los elementos utilizados por los módulos del diseño detallado, tanto de los subsistemas específicos como de los de soporte.


66

ANÁLISIS Y DISEÑO DE SISTEMAS Diseño Detallado de Subsistemas / Interfaz de Usuario: • Los datos o formatos de mensajes necesarios en el diseño de la interfaz de usuario corresponden con los datos o formatos de mensajes de los correspondientes módulos. • Para cada evento / acción solicitado por el usuario existe un módulo que le da respuesta. Los análisis de consistencia específicos para el Diseño Orientado a Objetos son: Modelo de Clases / Modelo Físico de Datos: • Los elementos del modelo físico de datos corresponden con los elementos utilizados por las clases del diseño detallado, tanto de los subsistemas específicos como de soporte. • Modelo de Clases / Diagramas Dinámicos. • Cada mensaje entre objetos se corresponde con una operación de una clase, y todos los mensajes se envían a las clases correctas, incluyendo las clases de interfaz y la navegación entre ventanas. • Cada mensaje entre subsistemas se corresponde con una operación de una clase del subsistema destino. • La clase que recibe un mensaje con petición de datos tiene capacidad para proporcionar esos datos. • Cada objeto del diagrama de interacción de objetos tiene una correspondencia en el modelo de clases. • Todas las clases, atributos y métodos identificados en la interfaz de usuario tienen su correspondencia con algún atributo, método o clase en el modelo de clases. En el caso de haber elaborado diagramas de transición de estados para clases significativas: • Se comprueba que para cada uno de ellos, todo evento se corresponde con una operación de la clase. También se tendrá que establecer si las acciones y actividades de los diagramas de transición de estado se corresponden con operaciones de la clase. Opcionalmente, se propone obtener para el análisis de consistencia en un diseño orientado a objetos: • Matriz de mensajes del diagrama de interacción de objetos / operaciones del modelo de clases. • Matriz de mensajes del diagrama de interacción de objetos / operaciones y atributos del modelo de clases. • Matriz de objetos del diagrama de interacción de objetos / clases, atributos del modelo de clases. • Matriz (evento, acción, actividad de clase) / operaciones de clase. • Matriz clases / elementos del modelo físico de datos.


67


Productos.

De entrada Catálogo de Requisitos

Diseño Detallado de los Subsistemas de Soporte

Catálogo de Excepciones

Catálogo de Normas

Entorno Tecnológico del Sistema

Diseño de la Arquitectura del Sistema

3. Aceptación de la Arquitectura del Sistema. El objetivo de esta tarea es obtener la aceptación, por parte de las áreas de explotación y sistemas, de la arquitectura del sistema de información y de los requisitos de operación y seguridad, con el fin de poder valorar su impacto en la instalación.

Generación de especificaciones de construcción. En esta actividad se generan las especificaciones para la construcción del sistema de información, a partir del diseño detallado. Estas especificaciones definen la construcción del sistema de información a partir de las unidades básicas de construcción (en adelante, componentes), entendiendo como tales unidades independientes y coherentes de construcción y ejecución, que se corresponden con un empaquetamiento físico de los elementos del diseño de detalle, como pueden ser módulos, clases o especificaciones de interfaz. La división del sistema de información en subsistemas de diseño proporciona, por continuidad, una primera división en subsistemas de construcción, definiendo para cada uno de ellos los componentes que lo integran. Si se considera necesario, un subsistema de diseño se podrá dividir a su vez en sucesivos niveles para mayor claridad de las especificaciones de construcción. Las dependencias entre subsistemas de diseño proporcionan información para establecer las dependencias entre los subsistemas de construcción y, por lo tanto, definir el orden o secuencia que se debe seguir en la construcción y en la realización de las pruebas.


68

ANÁLISIS Y DISEÑO DE SISTEMAS También se generan las especificaciones necesarias para la creación de las estructuras de datos en los gestores de bases de datos o sistemas de ficheros. El producto resultante de esta actividad es el conjunto de las especificaciones de construcción del sistema de información, que comprende: • Especificación del entorno de construcción. • Descripción de subsistemas de construcción y dependencias. • Descripción de componentes. • Plan de integración del sistema de información. • Especificación detallada de componentes. • Especificación de la estructura física de datos. Tarea

Técnicas y

Productos  Especificaciones de

DSI 8.1

Especificación del Entorno de Construcción

Participantes

Prácticas

Construcción del Sistema de Información: o









Equipo de Soporte Técnico.

Especificación del Entorno



Equipo de Sistemas.



Equipo de Seguridad.









Equipo del Proyecto

Construcción del Sistema de



Equipo del Proyecto

Información o



Administradores de la

de Construcción  Especificaciones de

Definición de DSI 8.2

Componentes y Subsistemas de Construcción

Construcción del Sistema de 

Diagrama de

Información: o Descripción

Estructura

de Subsistemas de

Matricial.

Construcción y



Diagrama de

Dependencias o Descripción

Componentes.

de Componentes o Plan de 

Diagrama de

Integración del Sistema de

Despliegue.

Información  Especificaciones de DSI 8.3

Elaboración de Especificaciones de Construcción

Construcción del Sistema de Información: o Especificación Detallada de



Diagrama de Componentes

Componentes Elaboración de DSI 8.4

Especificaciones del Modelo Físico de Datos

 Especificaciones de

Especificación de la

Base de Datos

Estructura Física de Datos.

1. Especificación del Entorno de Construcción. El objetivo de esta tarea es la definición detallada y completa del entorno necesario para la construcción de los componentes del sistema de información.


69

ANÁLISIS Y DISEÑO DE SISTEMAS Se propone que la especificación del entorno se realice según los siguientes conceptos: • Entorno tecnológico: hardware, software y comunicaciones. • Herramientas de construcción, generadores de código, compiladores, etc. • Restricciones técnicas del entorno. • Planificación de capacidades previstas, o la información que estime oportuno el departamento de sistemas para efectuar dicha planificación. • Requisitos de operación y seguridad del entorno de construcción. Productos. De entrada. Catálogo de Requisitos. Diseño de la Arquitectura del Sistema. Entorno Tecnológico del Sistema. De salida Especificaciones de Construcción del Sistema de Información o Especificación. del Entorno de Construcción. Participantes Equipo de Arquitectura. Equipo del Proyecto. Equipo de Soporte Técnico. Equipo de Sistemas. Equipo de Seguridad. 2. Definición de Componentes y Subsistemas de Construcción. La especificación de los subsistemas de construcción se realiza a partir de los subsistemas de diseño, con una continuidad directa, permitiéndose a su vez un mayor nivel de detalle agrupando componentes en subsistemas dentro de un subsistema de construcción. Los componentes se definen mediante la agrupación de elementos del diseño de detalle de cada subsistema de diseño. En principio, cada módulo o clase y cada formato individual de interfaz se corresponden con un componente, aunque se pueden agrupar o redistribuir módulos o clases en componentes, siguiendo otros criterios más oportunos, como pueden ser: • Optimización de recursos. • Características comunes de funcionalidad o de acceso a datos. • Necesidades especiales de ejecución: elementos críticos, accesos costosos a datos, etc.


70

ANÁLISIS Y DISEÑO DE SISTEMAS Los subsistemas de construcción y las dependencias entre subsistemas y entre componentes de un subsistema recogen aspectos prácticos relativos a la plataforma concreta de construcción y ejecución. Entre estos aspectos se pueden citar, por ejemplo: • Secuencia de compilación entre componentes. • Agrupación de elementos en librerías o packages (por ejemplo, DLL en el entorno Windows, packages en Java). La asignación de subsistemas de construcción a nodos, por continuidad con el diseño, determina la distribución de los componentes que lo integran. Opcionalmente, se propone la realización de un plan de integración del sistema de información, especificando la secuencia y organización de la construcción y prueba de los subsistemas de construcción y de los componentes, desde un punto de vista técnico. 3. Elaboración de Especificaciones de Construcción. Se realiza una especificación detallada de cada componente, en pseudocódigo o lenguaje natural, completando la información que se considere necesaria según el entorno tecnológico. Asimismo, se determinan y especifican todos los elementos o parámetros complementarios a la propia definición de componentes que, en función del entorno tecnológico, completan las especificaciones de construcción. Como ejemplos, es posible citar las tablas de definición de programas y transacciones en monitores de teleproceso, etc. 4. Elaboración de Especificaciones del Modelo Físico de Datos. En esta tarea se generan las especificaciones necesarias para la definición y creación de los elementos del modelo físico de datos, mediante el lenguaje de definición de datos del correspondiente gestor de base de datos o sistema de ficheros, teniendo en cuenta el entorno tecnológico, las normas y estándares de la organización y características intrínsecas del gestor o sistema de ficheros a utilizar.

Diseño de la migración y carga inicial de datos. Esta actividad sólo se lleva a cabo cuando es necesaria una carga inicial de información, o una migración de datos de otros sistemas, cuyo alcance y estrategia a seguir se habrá establecido previamente. Para ello, se toma como referencia el plan de migración y carga inicial de datos, que recoge las estructuras físicas de datos del sistema o sistemas origen implicadas en la conversión, la prioridad en las cargas y secuencia a seguir, las necesidades previas de depuración de la información, así como los ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

71

ANÁLISIS Y DISEÑO DE SISTEMAS requisitos necesarios para garantizar la correcta implementación de los procedimientos de migración sin comprometer el funcionamiento de los sistemas actuales. A partir de dicho plan, y de acuerdo a la estructura física de los datos del nuevo sistema, obtenida en la actividad Diseño Físico de Datos, y a las características de la arquitectura y del entorno tecnológico propuesto en la actividad Definición de la Arquitectura del Sistema, se procede a definir y diseñar en detalle los procedimientos y procesos necesarios para realizar la migración. Se completa el plan de pruebas específico establecido en el plan de migración y carga inicial, detallando las pruebas a realizar, los criterios de aceptación o rechazo de la prueba y los responsables de la organización, realización y evaluación de resultados. Asimismo, se determinan las necesidades adicionales de infraestructura, tanto para la implementación de los procesos como para la realización de las pruebas. Como resultado de esta actividad, se actualiza el plan de migración y carga inicial de datos con la información siguiente: • Especificación del entorno de migración. • Definición de procedimientos de migración. • Diseño detallado de módulos. • Especificación técnica de las pruebas. • Planificación de la migración y carga inicial. Es importante considerar que una carga inicial de información no tiene el mismo alcance y complejidad que una migración de datos, de modo que las tareas de esta actividad se deben llevar a cabo en mayor o menor medida en función de las características de los datos a cargar. Tarea Especificación del DSI

Entorno de Migración Diseño de

DSI

Productos


• Plan de Migración y Carga Inicial de Datos: o Especificación del Entorno de Migración y Carga Inicial • Plan de Migración y Carga

Participantes • Equipo de Arquitectura • Equipo de Soporte Técnico • Equipo de Arquitectura

Procedimientos de

Inicial de Datos: o Definición

Migración y Carga

de Procedimientos de

• Equipo del Proyecto

Migración y Carga Inicial

• Equipo de Seguridad

Inicial


72

ANÁLISIS Y DISEÑO DE SISTEMAS • Plan de Migración y Carga Diseño Detallado DSI

de Componentes de Migración y Carga Inicial

Inicial de Datos: o Diseño Detallado de Módulos de Migración y Carga Inicial o

• Equipo del Proyecto

Especificación Técnica de las Pruebas de Migración y Carga Inicial

Revisión de la DSI

Planificación de la Migración

• Plan de Migración y Carga Inicial de Datos: o Planificación de la Migración

• Jefe de Proyecto.

y Carga Inicial

1. Especificación del Entorno de Migración. El objetivo de esta tarea es definir el entorno tecnológico propio de los procesos de migración y carga inicial, adecuando al mismo las necesidades y requisitos reflejados en el plan de migración y carga inicial de datos. En la descripción del entorno tecnológico, hay que tener en cuenta las herramientas o utilidades software específicas de estos procesos. Se realiza una estimación de capacidades (capacity planning) para este entorno que permita evaluar las necesidades de infraestructura, principalmente relacionadas con el espacio de almacenamiento y las comunicaciones. 2. Diseño de Procedimientos de Migración y Carga Inicial. El objetivo de esta tarea es la definición de los procedimientos necesarios para llevar a cabo la migración y carga inicial de datos del sistema. Como punto de partida se tiene en cuenta, junto con los requisitos y especificaciones de migración y carga inicial, el modelo físico de datos optimizado y su localización en los nodos, así como la definición del entorno tecnológico del sistema de información. Los procedimientos asociados a la migración y carga inicial de datos son, principalmente, los relacionados con la preparación, la realización y la posterior verificación del proceso. Entre ellos se encuentran los siguientes: • • • • • •

Procedimientos de seguridad, relativos a Control de acceso a la información. Copias de seguridad de los procesos. Recuperación de la información. Tratamiento de las posibles contingencias durante la conversión. Procedimientos de carga de datos, relativos a: Depuraciones previas de información.


73

ANÁLISIS Y DISEÑO DE SISTEMAS • • • •

Procesos de validación. Procesos de importación. Procesos de carga y prioridades. Procedimientos de verificación de los procesos y comprobación de la integridad de la información resultante al finalizar la conversión, conforme a la estructura física de los datos destino.

3. Diseño Detallado de Componentes de Migración y Carga Inicial. El objetivo de esta tarea es el diseño detallado, en sucesivos niveles de detalle, de los módulos de migración y carga inicial, indicando la jerarquía y orden de ejecución. El diseño de los módulos necesarios para la migración y carga inicial no es conceptualmente distinto del diseño de cualquier otro módulo del sistema de información, por lo que se recomienda utilizar pautas similares. Se debe tener en cuenta el modelo físico de datos del sistema de información, así como las estructuras de datos del sistema o sistemas origen recogidas en el plan de migración y carga inicial de datos. Finalmente, se complementa el plan de migración y carga inicial con la definición de los distintos tipos de prueba a realizar. 4. Revisión de la Planificación de la Migración. El objetivo de esta tarea es completar la especificación del plan de migración y carga inicial, concretando el plan de trabajo de acuerdo a los procedimientos y procesos de migración y carga inicial definidos. Especificación técnica del plan de pruebas. En esta actividad se realiza la especificación de detalle del plan de pruebas del sistema de información para cada uno de los niveles de prueba establecidos en el proceso Análisis del Sistema de Información: • • • • •

Pruebas unitarias. Pruebas de integración. Pruebas del sistema. Pruebas de implantación. Pruebas de aceptación.

Para ello se toma como referencia el plan de pruebas, que recoge los objetivos de la prueba de un sistema, establece y coordina una estrategia de trabajo, y provee del marco adecuado para planificar paso a paso las actividades de prueba. También puede ser una referencia el plan de integración del sistema


74

ANÁLISIS Y DISEÑO DE SISTEMAS de información propuesto, opcionalmente, Componentes y Subsistemas de Construcción.

en

la tarea Definición de

El catálogo de requisitos, el catálogo de excepciones y el diseño detallado del sistema de información, permiten la definición de las verificaciones que deben realizarse en cada nivel de prueba para comprobar que el sistema responde a los requisitos planteados. La asociación de las distintas verificaciones a componentes, grupos de componentes y subsistemas, o al sistema de información completo, determina las distintas verificaciones de cada nivel de prueba establecido. Las pruebas unitarias comprenden las verificaciones asociadas a cada componente del sistema de información. Su realización tiene como objetivo verificar la funcionalidad y estructura de cada componente individual. Las pruebas de integración comprenden verificaciones asociadas a grupos de componentes, generalmente reflejados en la definición de subsistemas de construcción o en el plan de integración del sistema de información. Tienen por objetivo verificar el correcto ensamblaje entre los distintos componentes. Las pruebas del sistema, de implantación y de aceptación corresponden a verificaciones asociadas al sistema de información, y reflejan distintos propósitos en cada tipo de prueba: • Las pruebas del sistema son pruebas de integración del sistema de información completo. Permiten probar el sistema en su conjunto y con otros sistemas con los que se relaciona para verificar que las especificaciones funcionales y técnicas se cumplen. • Las pruebas de implantación incluyen las verificaciones necesarias para asegurar que el sistema funcionará correctamente en el entorno de operación al responder satisfactoriamente a los requisitos de rendimiento, seguridad y operación, y coexistencia con el resto de los sistemas de la instalación, y conseguir la aceptación del sistema por parte del usuario de operación. • Las pruebas de aceptación van dirigidas a validar que el sistema cumple los requisitos de funcionamiento esperado, recogidos en el catálogo de requisitos y en los criterios de aceptación del sistema de información, y conseguir la aceptación final del sistema por parte del usuario. Las pruebas unitarias, de integración y del sistema se llevan a cabo en el proceso Construcción del Sistema de Información (CSI), mientras que las pruebas de implantación y aceptación se realizan en el proceso Implantación y Aceptación del Sistema (IAS).


75

ANÁLISIS Y DISEÑO DE SISTEMAS Como resultado de esta actividad se actualiza el plan de pruebas con la información siguiente: • Especificación del entorno de pruebas. • Especificación técnica de niveles de prueba. • Planificación de las pruebas. Tarea

Productos


Participantes  Equipo de Arquitectura

DSI

Especificación del

 Plan de Pruebas: o

Entorno de

Especificación del

Pruebas

Entorno de Pruebas.

 Equipo de Soporte Técnico  Equipo del Proyecto  Equipo de Seguridad

Especificación DSI

Técnica de Niveles de Prueba Revisión de la

DSI

Planificación de Pruebas

 Plan de Pruebas: o

 Jefe de Proyecto

Especificación Técnica de

 Analistas

Niveles de Prueba.

 Usuarios Expertos

 Plan de Pruebas: o Planificación de las

 Jefe de Proyecto

Pruebas

1. Especificación del Entorno de Pruebas. El objetivo de esta tarea es la definición detallada y completa del entorno necesario para la realización de las pruebas del sistema: unitarias, de integración, de implantación y de aceptación. Se propone considerar los siguientes conceptos en la especificación del entorno: • Entorno tecnológico: hardware, software y comunicaciones. • Restricciones técnicas del entorno. • Requisitos de operación y seguridad del entorno de pruebas. • Herramientas de prueba relacionadas con la extracción de juegos de ensayo, análisis de resultados, utilidades de gestión del entorno, etc. • Planificación de capacidades previstas, o la información que estime oportuno el departamento técnico para efectuar dicha planificación. • Procedimientos de promoción de elementos entre entornos (desarrollo, pruebas, explotación, etc.). • Procedimientos de emergencia y de recuperación, así como de vuelta atrás. 2. Especificación Técnica de Niveles de Prueba. El objetivo de esta tarea es el diseño detallado de los distintos niveles de prueba, especificados en el plan de pruebas elaborado en el proceso Análisis del Sistema de Información.


76

ANÁLISIS Y DISEÑO DE SISTEMAS El plan de integración del sistema de información, si se ha definido en la actividad Definición de Componentes y Subsistemas de Construcción, va a servir de referencia para la elaboración detallada del plan de pruebas, principalmente las pruebas de integración y del sistema. En cualquier caso se hay que especificar la estrategia de integración de dichas pruebas. De acuerdo a la arquitectura del sistema propuesta y a las características intrínsecas del diseño del sistema de información, se definen en detalle las distintas verificaciones a realizar sobre el sistema, conforme a los niveles de prueba establecidos, teniendo en cuenta que una verificación puede ser aplicable a varios componentes o grupos de componentes. Estas verificaciones deben cubrir aspectos funcionales y no funcionales, considerando las excepciones que puedan producirse, así como las soluciones de diseño adoptadas, tanto del propio diseño de detalle del sistema de información, como de la utilización de subsistemas de soporte propios de la instalación. Las verificaciones a realizar se especifican detallando: • Ámbito de aplicación (prueba unitaria, de integración, del sistema, de implantación o aceptación) y objetivo. Casos de prueba asociados: se definen en detalle los casos de prueba y se detalla cómo proceder en la ejecución de dichos casos, describiendo todas las entradas necesarias para ejecutar la prueba, y las relaciones de secuencialidad existentes entre las entradas, así como todas aquellas salidas que se espera obtener una vez ejecutado el caso de prueba, y las características especiales requeridas, como por ejemplo, tiempo de respuesta. Procedimientos de prueba: se determina el conjunto de pasos a seguir para asegurar que los casos de prueba se ejecutan adecuadamente, especificando: Casos de prueba a los que se aplica el procedimiento. Recursos hardware y software necesarios para ejecutar el procedimiento. Requisitos especiales o acciones necesarias para iniciar la ejecución. Requisitos especiales o acciones necesarias a realizar durante la ejecución del procedimiento. Entorno de prueba: herramientas adicionales, condicionantes especiales de ejecución, etc. Criterios de aceptación de la prueba. Análisis y evaluación de resultados. Como resultado final, se obtiene la relación de verificaciones que permiten comprobar:


77

ANÁLISIS Y DISEÑO DE SISTEMAS - El correcto funcionamiento de cada componente (pruebas unitarias), cada subsistema de construcción o conjunto de componentes (pruebas de integración). - La integración del sistema de información en su totalidad (pruebas del sistema). - El ajuste del sistema a las necesidades para las que fue creado, de acuerdo a las características del entorno en el que se va a implantar (pruebas de implantación). - La respuesta satisfactoria del sistema a los requisitos especificados por el usuario (pruebas de aceptación). 3. Revisión de la Planificación de Pruebas En esta tarea se completa y especifica la planificación de las pruebas, determinando los distintos perfiles implicados en la preparación y ejecución de las pruebas y en la evaluación de los resultados, así como el tiempo estimado para la realización de cada uno de los niveles de prueba, de acuerdo a la estrategia de integración establecida. Productos: De entrada, Plan de Pruebas, De salida, Plan de Pruebas o Planificación de las Pruebas. Participantes: Jefe de Proyecto Establecimiento de requisitos de implantación. En esta actividad se completa el catálogo de requisitos con aquéllos relacionados con la documentación que el usuario requiere para operar con el nuevo sistema, y los relativos a la propia implantación del sistema en el entorno de operación. La incorporación de estos requisitos permite ir preparando, en los procesos de Construcción del Sistema de Información (CSI) e Implantación y Aceptación del Sistema (IAS), los medios y recursos necesarios para que los usuarios, tanto finales como de operación, sean capaces de utilizar el nueva sistema de forma satisfactoria. Tarea

DSI

Especificación de Requisitos de Documentación de Usuario

Productos

•

Catálogo de Requisitos


• •

Catalogación Sesiones de Trabajo

• • • • •


Participantes Jefe de Proyecto. Analistas. Usuarios Expertos. Responsable de Operación. Responsable de Sistemas.

78


DSI

Especificación de Requisitos de Implantación

•

Catálogo de Requisitos

• •

Catalogación Sesiones de Trabajo

• • •

Jefe de Proyecto. Directores de Usuarios. Equipo de. Soporte Técnico.

1. Especificación de Requisitos de Documentación de Usuario. En esta tarea se recoge toda la información necesaria para la especificación de la documentación a entregar al usuario, que incluirá los manuales de usuario y, cuando proceda, los manuales de explotación. Para ello, es necesario definir, entre otros, los siguientes aspectos: • Tipo de documentos y estándares a seguir en la elaboración de los mismos. • Formato en el que se desarrollarán. • Estructura. • Soporte en el que se van a generar. • Distribución y mantenimiento de la documentación y copias a editar. • Control de versiones. 2. Especificación de Requisitos de Implantación. En esta tarea se especifican de forma detallada los requisitos de implantación, generalmente relacionados con la formación, infraestructura e instalación, con el fin de preparar y organizar, con la antelación suficiente, todos los recursos necesarios para la implantación e instalación del sistema de información. Teniendo en cuenta las particularidades del sistema de información, se determinan los conocimientos o aptitudes adicionales que requieren los usuarios finales para operar con el nuevo sistema, al margen de la funcionalidad soportada por el mismo. Como consecuencia, se pueden establecer requisitos de formación indispensables, como condición previa, para el desarrollo del plan de formación que se elaborará en el proceso Implantación y Aceptación del Sistema (IAS). Los requisitos de infraestructura e instalación hacen referencia a las necesidades especiales de equipamiento software, hardware y comunicaciones exigidos por el nuevo sistema, así como a los tipos de elementos implicados en la instalación, que deben tenerse en cuenta al especificar la estrategia de implantación, en el proceso Implantación y Aceptación del Sistema (IAS).


79

ANÁLISIS Y DISEÑO DE SISTEMAS Aprobación del diseño del sistema de información.

Tarea Presentación y DSI

Aprobación del Diseño del Sistema de Información

Productos 


Aprobación del Diseño del Sistema de



Participantes 

Comité de



Jefe de Proyecto

Presentación

Información

Dirección

1. Presentación y Aprobación del Diseño del Sistema de Información. En esta tarea se realiza la presentación del diseño del sistema de información al Comité de Dirección para la aprobación final del mismo.


80

ANÁLISIS Y DISEÑO DE SISTEMAS TAREA 03: DEFINIR EL CICLO DE VIDA DE DESARROLLO DE SISTEMA.

En esta tarea trataremos las siguientes operaciones:  Entender las actividades generadas para el desarrollo de software.


   

Computadora con microprocesadores core 2 Duo o de mayor capacidad. Sistema operativo Windows. Acceso a internet. Software de maquetación.

INFORMACIÓN TECNOLÓGICA: Identificación de un conjunto de tareas. Se tiene que entender que cada acción de la ingeniería de software (por ejemplo, obtención, asociada a la actividad de comunicación) se representa por cierto número de distintos conjuntos de tareas, cada uno de los cuales es una colección de tareas de trabajo de la ingeniería de software, relacionadas con productos del trabajo, puntos de aseguramiento de la calidad y puntos de referencia del proyecto. Debe escogerse el conjunto de tareas que se adapte mejor a las necesidades del proyecto y a las características del equipo. Esto implica que una acción de la ingeniería de software puede adaptarse a las necesidades específicas del proyecto de software y a las características del equipo del proyecto. Patrones del proceso. Cada equipo de software se enfrenta a problemas conforme avanza en el proceso del software. Si se demostrara que existen soluciones fáciles para dichos problemas, sería útil para el equipo abordarlos y resolverlos rápidamente. Un patrón del proceso1 describe un problema relacionado con el proceso que se encuentra durante el trabajo de ingeniería de software, identifica el ambiente en el que surge el problema y sugiere una o más soluciones para el mismo. Dicho de manera general, un patrón de proceso da un formato: un método consistente para describir soluciones del problema en el contexto del proceso del software. Al combinar patrones, un equipo de software resuelve problemas y construye el proceso que mejor satisfaga las necesidades de un proyecto.


81

ANÁLISIS Y DISEÑO DE SISTEMAS Los patrones se definen en cualquier nivel de abstracción. En ciertos casos, un patrón puede usarse para describir un problema asociado con un modelo completo del proceso. En otras situaciones, los patrones se utilizan para describir un problema asociado con una actividad estructural (por ejemplo, planeación) o una acción dentro de una actividad estructural (estimación de proyectos).En estos casos se propone un formato para describir un patrón del proceso: Nombre del patrón. El patrón recibe un nombre significativo que lo describe en el contexto del proceso del software (por ejemplo, Revisiones Técnicas). Fuerzas. El ambiente en el que se encuentra el patrón y los aspectos que hacen visible el problema y afectan su solución. Tipo. Se especifica el tipo de patrón, sugiere tres tipos: 1. Patrón de etapa: define un problema asociado con una actividad estructural para el proceso. Como una actividad estructural incluye múltiples acciones y tareas del trabajo, un patrón de la etapa incorpora múltiples patrones de la tarea que son relevantes para la etapa (actividad estructural). Un ejemplo de patrón de etapa sería Establecer Comunicación. Este patrón incorporaría el patrón de tarea Recabar Requerimientos y otros más. 2. Patrón de tarea: define un problema asociado con una acción o tarea de trabajo de la ingeniería de software y que es relevante para el éxito de la práctica de ingeniería de software (por ejemplo, Recabar Requerimientos es un patrón de tarea). Patrón de fase: define la secuencia de las actividades estructurales que ocurren dentro del proceso, aun cuando el flujo general de las actividades sea de naturaleza iterativa. Un ejemplo de patrón de fase es Modelo Espiral o Prototipos. 3. Contexto inicial. Describe las condiciones en las que se aplica el patrón. Antes de iniciar el patrón: 1) ¿Qué actividades organizacionales o relacionadas con el equipo han ocurrido? 2) ¿Cuál es el estado de entrada para el proceso? 3) ¿Qué información de ingeniería de software o del proyecto ya existe? Por ejemplo, el patrón Planeación (patrón de etapa) requiere que: 1) los clientes y los ingenieros de software hayan establecido una comunicación colaboradora; 2) haya terminado con éxito cierto número de patrones de tarea [especificado] para el patrón Comunicación; y 3) se conozcan el alcance del proyecto, los requerimientos básicos del negocio y las restricciones del proyecto. Problema. El problema específico que debe resolver el patrón. Solución. Describe cómo implementar con éxito el patrón. Esta sección describe la forma en la que se modifica el estado inicial del proceso (que existe antes de implementar el patrón) como consecuencia de la iniciación del patrón. También describe cómo se transforma la información sobre la ingeniería de software o sobre el proyecto, disponible antes de que ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

82

ANÁLISIS Y DISEÑO DE SISTEMAS inicie el patrón, como consecuencia de la ejecución exitosa del patrón. Contexto resultante. Describe las condiciones que resultarán una vez que se haya implementado con éxito el patrón: 1) ¿Qué actividades organizacionales o relacionadas con el equipo deben haber ocurrido? 2) ¿Cuál es el estado de salida del proceso? 3) ¿Qué información sobre la ingeniería de software o sobre el proyecto se ha desarrollado? Patrones relacionados. Proporciona una lista de todos los patrones de proceso directamente relacionados con éste. Puede representarse como una jerarquía o en alguna forma de diagrama. Por ejemplo, el patrón de etapa Comunicación incluye los patrones de tarea: Equipo Del Proyecto, Lineamientos De Colaboración, Definición De Alcances, Recabar Requerimientos, Descripción De Restricciones y Creación De Escenarios. Usos y ejemplos conocidos. Indica las instancias específicas en las que es aplicable el patrón. Por ejemplo, Comunicación es obligatoria al principio de todo proyecto de software, es recomendable a lo largo del proyecto y de nuevo obligatoria una vez alcanzada la actividad de despliegue. Los patrones de proceso dan un mecanismo efectivo para enfrentar problemas asociados con cualquier proceso del software. Los patrones permiten desarrollar una descripción jerárquica del proceso, que comienza en un nivel alto de abstracción (un patrón de fase). Después se mejora la descripción como un conjunto de patrones de etapa que describe las actividades estructurales y se mejora aún más en forma jerárquica en patrones de tarea más detallados para cada patrón de etapa. Una vez desarrollados los patrones de proceso, pueden reutilizarse para la definición de variantes del proceso, es decir, un equipo de software puede definir un modelo de proceso específico con el empleo de los patrones como bloques constituyentes del modelo del proceso.

Evaluación y mejora del proceso. La existencia de un proceso del software no es garantía de que el software se entregue a tiempo, que satisfaga las necesidades de los consumidores o que tenga las características técnicas que conducirán a características de calidad de largo plazo. Los patrones de proceso deben acoplarse con una práctica sólida de ingeniería de software. Además, el proceso en sí puede evaluarse para garantizar que cumple con ciertos criterios de proceso básicos que se haya demostrado que son esenciales para el éxito de la ingeniería de software. En las últimas décadas se han propuesto numerosos enfoques para la evaluación y mejora de un proceso del software:


83

ANÁLISIS Y DISEÑO DE SISTEMAS Método de evaluación del estándar CMMI para el proceso de mejora, proporciona un modelo de cinco fases para evaluar el proceso: inicio, diagnóstico, establecimiento, actuación y aprendizaje. En pocas palabras el CMMI como la base de la evaluación. Evaluación basada en CMM para la mejora del proceso interno proporciona una técnica de diagnóstico para evaluar la madurez relativa de una organización de software; usa el SEI CMM como la base de la evaluación. SPICE (ISO/IEC 15504): estándar que define un conjunto de requerimientos para la evaluación del proceso del software. El objetivo del estándar es ayudar a las organizaciones a desarrollar una evaluación objetiva de cualquier proceso del software definido. ISO9001:2000 para software: estándar genérico que se aplica a cualquier organización que desee mejorar la calidad general de los productos, sistemas o servicios que proporciona. Por tanto, el estándar es directamente aplicable a las organizaciones y compañías de software.


84

ANÁLISIS Y DISEÑO DE SISTEMAS TAREA 04: DEFINIR LA TECNOLOGÍA DE OBJETOS.

En esta tarea trataremos las siguientes operaciones:  Entender el ciclo de vida del software.  Comprender las fases y las interacciones.  Implementar los artefactos y UML en el proceso unificado.


   


FUNDAMENTO TEÓRICO:

Entender el ciclo de vida del software y comprender las fases y las interacciones.

Modelos de proceso prescriptivo. Los modelos de proceso prescriptivo fueron propuestos originalmente para poner orden en el caos del desarrollo de software. La historia indica que estos modelos tradicionales han dado cierta estructura útil al trabajo de ingeniería de software y que constituyen un mapa razonablemente eficaz para los equipos de software. Sin embargo, el trabajo de ingeniería de software y el producto que genera sigue “al borde del caos”. En un artículo intrigante sobre la extraña relación entre el orden y el caos en el mundo del software, Nogueira y sus colegas afirman lo siguiente: El borde del caos se define como “el estado natural entre el orden y el caos, un compromiso grande entre la estructura y la sorpresa”. El borde del caos se visualiza como un estado inestable y parcialmente estructurado Es inestable debido a que se ve atraído constantemente hacia el caos o hacia el orden absoluto. Tenemos la tendencia de pensar que el orden es el estado ideal de la naturaleza. Esto podría ser un error las investigaciones apoyan la teoría de que la operación que se aleja del equilibrio genera creatividad, procesos auto organizados y rendimientos crecientes. El orden absoluto significa ausencia de ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

85

ANÁLISIS Y DISEÑO DE SISTEMAS variabilidad, que podría ser una ventaja en los ambientes impredecibles. El cambio ocurre cuando hay cierta estructura que permita que el cambio pueda organizarse, pero que no sea tan rígida como para que no pueda suceder. Por otro lado, demasiado caos hace imposible la coordinación y la coherencia. La falta de estructura no siempre significa desorden. Las implicaciones filosóficas de este argumento son significativas para la ingeniería de software. Si los modelos de proceso prescriptivo buscan generar estructura y orden, ¿son inapropiados para el mundo del software, que se basa en el cambio? Pero si rechazamos los modelos de proceso tradicional (y el orden que implican) y los reemplazamos con algo menos estructurado, ¿hacemos imposible la coordinación y coherencia en el trabajo de software? No hay respuestas fáciles para estas preguntas, pero existen alternativas disponibles para los ingenieros de software. En las secciones que siguen se estudia el enfoque de proceso prescriptivo en el que los temas dominantes son el orden y la consistencia del proyecto. El autor los llama “prescriptivos” porque prescriben un conjunto de elementos del proceso: actividades estructurales, acciones de ingeniería de software, tareas, productos del trabajo, aseguramiento de la calidad y mecanismos de control del cambio para cada proyecto. Cada modelo del proceso también prescribe un flujo del proceso (también llamado flujo de trabajo), es decir, la manera en la que los elementos del proceso se relacionan entre sí. Todos los modelos del proceso del software pueden incluir las actividades estructurales generales descritas en el capítulo 1, pero cada una pone distinto énfasis en ellas y define en forma diferente el flujo de proceso que invoca cada actividad estructural (así como acciones y tareas de ingeniería de software). 1. Modelo de la cascada. Hay veces en las que los requerimientos para cierto problema se comprenden bien: cuando el trabajo desde la comunicación hasta el despliegue fluye en forma razonablemente lineal. Esta situación se encuentra en ocasiones cuando deben hacerse adaptaciones o mejoras bien definidas a un sistema ya existente (por ejemplo, una adaptación para software de contabilidad que es obligatorio hacer debido a cambios en las regulaciones gubernamentales). También ocurre en cierto número limitado de nuevos esfuerzos de desarrollo, pero sólo cuando los requerimientos están bien definidos y tienen una estabilidad razonable.


86

ANÁLISIS Y DISEÑO DE SISTEMAS El modelo de la cascada, a veces llamado ciclo de vida clásico, sugiere un enfoque sistemático y secuencial6 para el desarrollo del software, que comienza con la especificación de los requerimientos por parte del cliente y avanza a través de planeación, modelado, construcción y despliegue, para concluir con el apoyo del software terminado. Una variante de la representación del modelo de la cascada se denomina modelo en V. Se ilustra el modelo en V, donde se aprecia la relación entre las acciones para el aseguramiento de la calidad y aquellas asociadas con la comunicación, modelado y construcción temprana. A medida que el equipo de software avanza hacia abajo desde el lado izquierdo de la V, los requerimientos básicos del problema mejoran hacia representaciones técnicas cada vez más detalladas del problema y de su solución. Una vez que se ha generado el código, el equipo sube por el lado derecho de la V, y en esencia ejecuta una serie de pruebas (acciones para asegurar la calidad) que validan cada uno de los modelos creados cuando el equipo fue hacia abajo por el lado izquierdo. En realidad, no hay diferencias fundamentales entre el ciclo de vida clásico y el modelo en V. Este último proporciona una forma de visualizar el modo de aplicación de las acciones de verificación y validación al trabajo de ingeniería inicial. El modelo de la cascada es el paradigma más antiguo de la ingeniería de software. Es raro que los proyectos reales sigan el flujo secuencial propuesto por el modelo. Aunque el modelo lineal acepta repeticiones, lo hace en forma indirecta. Como resultado, los cambios generan confusión conforme el equipo del proyecto avanza.  A menudo, es difícil para el cliente enunciar en forma explícita todos los requerimientos.  El modelo de la cascada necesita que se haga y tiene dificultades para aceptar la incertidumbre natural que existe al principio de muchos proyectos.  El cliente debe tener paciencia. No se dispondrá de una versión funcional de los programas hasta que el proyecto esté muy avanzado. Un error grande sería desastroso si se detectara hasta revisar el programa en funcionamiento. Hoy en día, el trabajo de software es acelerado y está sujeto a una corriente sin fin de cambios. El modelo de la cascada suele ser inapropiado para ese tipo de labor.


87


2. Modelos de proceso incremental. Hay muchas situaciones en las que los requerimientos iniciales del software están razonablemente bien definidos, pero el alcance general del esfuerzo de desarrollo imposibilita un proceso lineal. Además, tal vez haya una necesidad imperiosa de dar rápidamente cierta funcionalidad limitada de software a los usuarios y aumentarla en las entregas posteriores de software. En tales casos, se elige un modelo de proceso diseñado para producir el software en incrementos. El modelo incremental combina elementos de los flujos de proceso lineal. En relación el modelo incremental aplica secuencias lineales en forma escalonada a medida que avanza el calendario de actividades. Cada secuencia lineal produce “incrementos” de software susceptibles de entregarse de manera parecida a los incrementos producidos en un flujo de proceso evolutivo. Por ejemplo, un software para procesar textos que se elabore con el paradigma incremental quizá entregue en el primer incremento las funciones básicas de administración de archivos, edición y producción del documento; en el segundo dará herramientas más sofisticadas de edición y producción de documentos; en el tercero habrá separación de palabras y revisión de la ortografía; y en el cuarto se proporcionará la capacidad para dar formato avanzado a las páginas. Debe observarse que el flujo de proceso para cualquier incremento puede incorporar el paradigma del prototipo. Cuando se utiliza un modelo incremental, es frecuente que el primer incremento sea el producto fundamental. Es decir, se abordan los requerimientos básicos, pero no se proporcionan muchas características ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

88

ANÁLISIS Y DISEÑO DE SISTEMAS suplementarias (algunas conocidas y otras no). El cliente usa el producto fundamental (o lo somete a una evaluación detallada). Como resultado del uso y/o evaluación, se desarrolla un plan para el incremento que sigue. El plan incluye la modificación del producto fundamental para cumplir mejor las necesidades de la organización, así como la entrega de características adicionales y más funcionalidad. Este proceso se repite después de entregar cada incremento, hasta terminar el producto final. El modelo de proceso incremental se centra en que en cada incremento se entrega un producto que ya opera. Los primeros incrementos son versiones desnudas del producto final, pero proporcionan capacidad que sirve al usuario y también le dan una plataforma de evaluación. El desarrollo incremental es útil en particular cuando no se dispone de personal para la implementación completa del proyecto en el plazo establecido por el negocio. Los primeros incrementos se desarrollan con pocos trabajadores. Si el producto básico es bien recibido, entonces se agrega más personal (si se requiere) para que labore en el siguiente incremento. Además, los incrementos se planean para administrar riesgos técnicos. Por ejemplo, un sistema grande tal vez requiera que se disponga de hardware nuevo que se encuentre en desarrollo y cuya fecha de entrega sea incierta. En este caso, tal vez sea posible planear los primeros incrementos de forma que eviten el uso de dicho hardware, y así proporcionar una funcionalidad parcial a los usuarios finales sin un retraso importante. Modelos de proceso evolutivo El software, como todos los sistemas complejos, evoluciona en el tiempo. Es frecuente que los requerimientos del negocio y del producto cambien conforme avanza el desarrollo, lo que hace que no sea realista trazar una trayectoria rectilínea hacia el producto final; los plazos apretados del mercado hacen que sea imposible la terminación de un software perfecto, pero debe lanzarse una versión limitada a fin de aliviar la presión de la competencia o del negocio; se comprende bien el conjunto de requerimientos o el producto básico, pero los detalles del producto o extensiones del sistema aún están por definirse. En estas situaciones y otras parecidas se necesita un modelo de proceso diseñado explícitamente para adaptarse a un producto que evoluciona con el tiempo. Los modelos evolutivos son iterativos. Se caracterizan por la manera en la que permiten desarrollar versiones cada vez más completas del software. En los párrafos que siguen se presentan dos modelos comunes de proceso evolutivo.


89


3. Hacer prototipos. Es frecuente que un cliente defina un conjunto de objetivos generales para el software, pero que no identifique los requerimientos detallados para las funciones y características. En otros casos, el desarrollador tal vez no esté seguro de la eficiencia de un algoritmo, de la adaptabilidad de un sistema operativo o de la forma que debe adoptar la interacción entre el humano y la máquina. En estas situaciones, y muchas otras, el paradigma de hacer prototipos tal vez ofrezca el mejor enfoque. Aunque es posible hacer prototipos como un modelo de proceso aislado, es más común usarlo como una técnica que puede implementarse en el contexto de cualquiera de los modelos de proceso descritos en este capítulo. Sin importar la manera en la que se aplique, el paradigma de hacer prototipos le ayudará a usted y a otros participantes a mejorar la comprensión de lo que hay que elaborar cuando los requerimientos no están claros. El paradigma de hacer prototipos comienza con comunicación. Usted se reúne con otros participantes para definir los objetivos generales del software, identifica cualesquiera requerimientos que conozca y detecta las áreas en las que es imprescindible una mayor definición. Se planea rápidamente una iteración para hacer el prototipo, y se lleva a cabo el modelado (en forma de un “diseño rápido”). Éste se centra en la representación de aquellos aspectos del software que serán visibles para los usuarios finales (por ejemplo, disposición de la interfaz humana o formatos de la pantalla de salida). El diseño rápido lleva a la construcción de un prototipo. Éste se entrega y es evaluado por los participantes, que dan retroalimentación para mejorar los requerimientos. La iteración ocurre a medida de que el prototipo es afinado para satisfacer las


90

ANÁLISIS Y DISEÑO DE SISTEMAS necesidades de distintos participantes, y al mismo tiempo le permite a usted entender mejor lo que se necesita hacer. El ideal es que el prototipo sirva como mecanismo para identificar los requerimientos del software. Si va a construirse un prototipo, pueden utilizarse fragmentos de programas existentes o aplicar herramientas (por ejemplo, generadores de reportes y administradores de ventanas) que permitan generar rápidamente programas que funcionen. Pero, ¿qué hacer con el prototipo cuando ya sirvió para el propósito descrito? En la mayoría de proyectos es raro que el primer sistema elaborado sea utilizable. Tal vez sea muy lento, muy grande, difícil de usar o todo a la vez. No hay más alternativa que comenzar de nuevo, con más inteligencia, y construir una versión rediseñada en la que se resuelvan los problemas. El prototipo sirve como “el primer sistema”. Lo que se recomienda es desecharlo. Pero esto quizá sea un punto de vista idealizado. Aunque algunos prototipos se construyen para ser “desechables”, otros son evolutivos; es decir, poco a poco se transforman en el sistema real. Tanto a los participantes como a los ingenieros de software les gusta el paradigma de hacer prototipos. Los usuarios adquieren la sensación del sistema real, y los desarrolladores logran construir algo de inmediato. No obstante, hacer prototipos llega a ser problemático por las siguientes razones:  Los participantes ven lo que parece ser una versión funcional del software, sin darse cuenta de que el prototipo se obtuvo de manera caprichosa; no perciben que en la prisa por hacer que funcionara, usted no consideró la calidad general del software o la facilidad de darle mantenimiento a largo plazo. Cuando se les informa que el producto debe rehacerse a fin de obtener altos niveles de calidad, los participantes ponen el grito al cielo. Después de un tiempo, quizá se sienta cómodo con esas elecciones y olvide todas las razones por las que eran inadecuadas. La elección de algo menos que lo ideal ahora ha pasado a formar parte del sistema. Aunque puede haber problemas, hacer prototipos es un paradigma eficaz para la ingeniería de software. La clave es definir desde el principio las reglas del juego; es decir, todos los participantes deben estar de acuerdo en que el prototipo sirva como el mecanismo para definir los requerimientos. Después se descartará (al menos en parte) y se hará la ingeniería del software real con la mirada puesta en la calidad.


91


4. El modelo espiral. El modelo espiral es un modelo evolutivo del proceso del software y se acopla con la naturaleza iterativa de hacer prototipos con los aspectos controlados y sistémicos del modelo de cascada. Tiene el potencial para hacer un desarrollo rápido de versiones cada vez más completas. El modelo de desarrollo espiral es un generador de modelo de proceso impulsado por el riesgo, que se usa para guiar la ingeniería concurrente con participantes múltiples de sistemas intensivos en software. Tiene dos características distintivas principales. La primera es el enfoque cíclico para el crecimiento incremental del grado de definición de un sistema y su implementación, mientras que disminuye su grado de riesgo. La otra es un conjunto de puntos de referencia de anclaje puntual para asegurar el compromiso del participante con soluciones factibles y mutuamente satisfactorias. Con el empleo del modelo espiral, el software se desarrolla en una serie de entregas evolutivas. Durante las primeras iteraciones, lo que se entrega puede ser un modelo o prototipo. En las iteraciones posteriores se producen versiones cada vez más completas del sistema cuya ingeniería se está haciendo. Un modelo en espiral es dividido por el equipo de software en un conjunto de actividades estructurales. Para fines ilustrativos, se utilizan las actividades estructurales generales ya analizadas. Cada una de ellas representa un segmento de la trayectoria espiral ilustrada. Al comenzar el proceso evolutivo, el equipo de software realiza actividades implícitas en un circuito alrededor de la espiral en el sentido horario, partiendo del centro. El riesgo se considera conforme se desarrolla cada revolución. En ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

92

ANÁLISIS Y DISEÑO DE SISTEMAS cada paso evolutivo se marcan puntos de referencia puntuales: combinación de productos del trabajo y condiciones que se encuentran a lo largo de la trayectoria de la espiral. El primer circuito alrededor de la espiral da como resultado el desarrollo de una especificación del producto; las vueltas sucesivas se usan para desarrollar un prototipo y, luego, versiones cada vez más sofisticadas del software. Cada paso por la región de planeación da como resultado ajustes en el plan del proyecto. El costo y la programación de actividades se ajustan con base en la retroalimentación obtenida del cliente después de la entrega. Además, el gerente del proyecto ajusta el número planeado de iteraciones que se requieren para terminar el software. A diferencia de otros modelos del proceso que finalizan cuando se entrega el software, el modelo espiral puede adaptarse para aplicarse a lo largo de toda la vida del software de cómputo. Entonces, el primer circuito alrededor de la espiral quizá represente un “proyecto de desarrollo del concepto” que comienza en el centro de la espiral y continúa por iteraciones múltiples10 hasta que queda terminado el desarrollo del concepto. Si el concepto va a desarrollarse en un producto real, el proceso sigue hacia fuera de la espiral y comienza un “proyecto de desarrollo de producto nuevo”. El nuevo producto evolucionará a través de cierto número de iteraciones alrededor de la espiral. Más adelante puede usarse un circuito alrededor de la espiral para que represente un “proyecto de mejora del producto”. En esencia, la espiral, cuando se caracteriza de este modo, sigue operativa hasta que el software se retira. Hay ocasiones en las que el proceso está inmóvil, pero siempre que se inicia un cambio comienza en el punto de entrada apropiado (por ejemplo, mejora del producto). El modelo espiral es un enfoque realista para el desarrollo de sistemas y de software a gran escala. Como el software evoluciona a medida que el proceso avanza, el desarrollador y cliente comprenden y reaccionan mejor ante los riesgos en cada nivel de evolución. El modelo espiral usa los prototipos como mecanismo de reducción de riesgos, pero, más importante, permite aplicar el enfoque de hacer prototipos en cualquier etapa de la evolución del producto. Mantiene el enfoque de escalón sistemático sugerido por el ciclo de vida clásico, pero lo incorpora en una estructura iterativa que refleja al mundo real en una forma más realista. El modelo espiral demanda una consideración directa de los riesgos técnicos en todas las etapas del proyecto y, si se aplica de manera apropiada, debe reducir los riesgos antes de que se vuelvan un problema. Pero, como otros paradigmas, el modelo espiral no es una panacea. Es difícil convencer a los clientes (en particular en situaciones bajo contrato) de que el enfoque evolutivo es controlable. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

93


Demanda mucha experiencia en la evaluación del riesgo y se basa en ella para llegar al éxito. No hay duda de que habrá problemas si algún riesgo importante no se descubre y administra.

5. Modelos concurrentes. El modelo de desarrollo concurrente, en ocasiones llamado ingeniería concurrente, permite que un equipo de software represente elementos iterativos y concurrentes de cualquiera de los modelos de proceso descritos en este capítulo. Por ejemplo, la actividad de modelado definida para el modelo espiral se logra por medio de invocar una o más de las siguientes acciones de software: hacer prototipos, análisis y diseño. Muestra la representación esquemática de una actividad de ingeniería de software dentro de la actividad de modelado con el uso del enfoque de modelado concurrente. La actividad modelado puede estar en cualquiera de los estados mencionados en un momento dado. En forma similar, es posible representar de manera análoga otras actividades, acciones o tareas (por ejemplo, comunicación o construcción). Todas las actividades de ingeniería de software existen de manera concurrente, pero se hallan en diferentes estados. Por ejemplo, la actividad de comunicación (no se muestra en la figura) termina su primera iteración al principio de un proyecto y existe en el estado de cambios en espera. La actividad de modelado (que existía en estado inactivo mientras concluía la comunicación inicial, ahora hace una transición al estado en desarrollo. Sin embargo, si el cliente indica que deben hacerse cambios en los requerimientos, la actividad de modelado pasa del estado en desarrollo al de cambios en espera. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

94

ANÁLISIS Y DISEÑO DE SISTEMAS El modelado concurrente define una serie de eventos que desencadenan transiciones de un estado a otro para cada una de las actividades, acciones o tareas de la ingeniería de software. Por ejemplo, durante las primeras etapas del diseño (acción importante de la ingeniería de software que ocurre durante la actividad de modelado), no se detecta una inconsistencia en el modelo de requerimientos. Esto genera el evento corrección del modelo de análisis, que disparará la acción de análisis de requerimientos del estado terminado al de cambios en espera. El modelado concurrente es aplicable a todos los tipos de desarrollo de software y proporciona un panorama apropiado del estado actual del proyecto. En lugar de confinar las actividades, acciones y tareas de la ingeniería de software a una secuencia de eventos, define una red del proceso. Cada actividad, acción o tarea de la red existe simultáneamente con otras actividades, acciones o tareas. Los eventos generados en cierto punto de la red del proceso desencadenan transiciones entre los estados.

Implementar los artefactos y UML en el proceso unificado. En los tiempos que corren, el software tiene la tendencia de ser grande y complejo. Los usuarios demandan interfaces cada vez más completas y funcionalidades más elaboradas, todo ello influyendo en el tamaño y la complejidad del producto final. Por ello, los programas deben ser estructurados de manera que puedan ser revisados, corregidos y mantenidos, rápida y eficazmente, por gente que no necesariamente ha colaborado en su diseño y construcción, permitiendo acomodar nueva funcionalidad, mayor seguridad y robustez, funcionando en todas las situaciones que puedan surgir, de manera previsible y reproducible. Ante problemas de gran complejidad, la mejor forma de abordar la solución es modelar. Modelar es diseñar y estructurar el software antes de lanzarse a programar y es la única forma de visualizar un diseño y comprobar que cumple todos los requisitos para él estipulados, antes de que la flotilla de programadores comience a generar código. Modelando, los responsables del éxito del producto pueden estar seguros de que su funcionalidad es completa y correcta, que todas las expectativas de los usuarios finales se cumplen, que las posibles futuras ampliaciones pueden ser acomodadas, todo ello mucho antes de que la implementación haga que los cambios sean difíciles o imposibles de acomodar. Modelando, se abstraen los detalles esenciales de un problema complejo y se obtiene diseños estructurados que, además, permiten la reutilización de código, reduciendo los tiempos de producción y minimizando las posibilidades de introducir errores.


95

ANÁLISIS Y DISEÑO DE SISTEMAS UML es un lenguaje gráfico que sirve para modelar, diseñar, estructurar, visualizar, especificar, construir y documentar software. UML proporciona un vocabulario común para toda la cadena de producción, desde quien recaba los requisitos de los usuarios, hasta el último programador responsable del mantenimiento. Es un lenguaje estándar para crear los planos de un sistema de forma completa y no ambigua. Fue creado por el Object Management Group, OMG, un consorcio internacional sin ánimo de lucro, que asienta estándares en el área de computación distribuida orientada a objetos, y actualmente revisa y actualiza periódicamente las especificaciones del lenguaje, para adaptarlo a las necesidades que surgen. El prestigio de este consorcio es un aval más para UML, considerando que cuenta con socios tan conocidos como la NASA, la Agencia Europea del Espacio ESA, el Instituto Europeo de Bioinformática EBI, Boeing, Borland, Motorla y el W3C, por mencionar algunos. La Orientación a Objetos (OO). Aunque UML puede emplearse en cualquier paradigma, como la programación estructurada o la lógica, está especialmente cerca del paradigma de la orientación a objetos. Por tanto, es precisa una familiarización con algunos detalles de este paradigma antes de continuar con UML.  Qué es un Objeto. De manera intuitiva, la tendencia general es asociar el término objeto con todo aquello a lo que se puede atribuir la propiedad física de masa, como una tostadora de pan, aunque es posible encontrar objetos de índole no tangible, como por ejemplo una dirección postal. En el ámbito de la informática, un objeto define una representación abstracta de las entidades del mundo, tangibles o no, con la intención de emularlas. Existe pues, una relación directa entre los objetos del mundo y los objetos informáticos, de modo que puede emplearse el término objeto de manera indistinta. Los objetos tienen dos características, que son su estado y su comportamiento. El estado es una situación en la que se encuentra el objeto, tal que cumple con alguna condición o condiciones particulares, realiza alguna actividad o espera que suceda un acontecimiento. Una tostadora puede estar encendida y cargada de pan y, en cuanto a su comportamiento, lo normal en este estado es tostar pan. Los objetos mantienen su estado en uno o más atributos, que son simplemente datos identificados por un nombre, y exhiben su comportamiento a través de métodos, que son trozos de funcionalidad asociados al objeto. En este sentido, un objeto es realmente un conjunto de atributos y métodos. Pero un objeto sólo revela su verdadera utilidad cuando es integrado en un contexto de


96

ANÁLISIS Y DISEÑO DE SISTEMAS comunicación con otros objetos, a través del envío de mensajes, para componer un sistema mucho mayor y demostrar un comportamiento más complejo. Una tostadora en un armario resulta de poca utilidad, pero cuando interactúa con otro objeto, como un ser humano, se convierte en una herramienta útil para tostar pan. El humano intercambiaría con la tostadora el mensaje “tuesta el pan que tienes en la bandeja” a través de la pulsación del botón de tostar. A partir del ejemplo anterior, es fácil deducir que el envío de mensajes es la forma en que se invocan los métodos de un objeto y que la invocación de métodos es el mecanismo a través del cual un objeto puede cambiar su estado o el de otro objeto. Los atributos y los métodos de un objeto pueden tener un menor o mayor grado de visibilidad, desde “privado” hasta “público”, lo que hace que aparezca un concepto nuevo, la encapsulación. La encapsulación oculta los detalles del funcionamiento interno del objeto, exponiendo sólo aquello que pueda ser de interés.  Qué es una Clase Los objetos no son entidades que existan de modo único. Hay muchos tipos de tostadoras e, igualmente, muchas tostadoras del mismo tipo. Se puede entender fácilmente el concepto de clase si nos permitimos emplear el término tipo como equivalente. Así, todos los objetos que son del mismo tipo, comparten el mismo juego de atributos y métodos (aunque cada objeto pueda tener un valor distinto asociado a cada atributo) y por tanto pertenecen a una misma clase. Las clases son como patrones que definen qué atributos y qué métodos son comunes a todos los objetos de un mismo tipo. Cada objeto tiene sus atributos y su comportamiento, creados empleando una clase a modo de patrón. Una vez creado el objeto, pasa a ser una instancia particular de la clase a la que pertenece y sus atributos tienen unos valores concretos, que podrán variar de un objeto a otro (dos objetos distintos pertenecientes a la misma clase, pueden tener exactamente los mismos valores en todos sus atributos). A estos atributos, que pueden variar de un objeto a otro, se les conoce también como variables de instancia. Hay atributos que, sin embargo, no varían de un objeto a otro, es decir todas las instancias de la clase a la que pertenecen, tienen el mismo valor para ese atributo. Todas las tostadoras del mismo tipo consumen los mismos Watios y sus resistencias son de los mismos Ohmios. A estos atributos se les conoce como variables de clase y son compartidos por todas y cada una de las instancias de la clase. De manera análoga al caso de los atributos, encontramos métodos de instancia y métodos de clase.


97

ANÁLISIS Y DISEÑO DE SISTEMAS  Qué es la Herencia. Los objetos se definen en función de clases, es decir, tomando una clase como patrón. Se puede saber mucho acerca de un objeto sabiendo la clase a la que pertenece. Por ejemplo, con decir que la “Russell Hobbs 10243 Kudos” es un tipo de tostadora, inmediatamente se sabe que se trata de una máquina para tostar pan, probablemente eléctrica y con por lo menos una ranura en la que insertar una rebanada de pan y un botón para activar su funcionamiento. Las clases llegan un paso más lejos, permitiendo su definición en función de otras clases, de modo que es posible establecer una jerarquía de especialización. Una clase que se define en función de otra, hereda todos los atributos y métodos de aquella y permite el añadido de nuevos o la sobre escritura de los heredados. La clase patrón se conoce con el nombre de superclase o clase padre, mientas que la que hereda se conoce como clase hija. La herencia no está limitada simplemente a padre-hija(s), la jerarquía puede ser todo lo profunda que sea necesario, hablando en términos de nietas, biznietas, etc. De la misma manera, una clase puede heredar de varias clases a la vez. En la siguiente figura se puede ver una jerarquía de especialización de dos niveles. La clase “Animal” es la raíz, la clase padre en la jerarquía. Especifica que los animales comen, como característica más significativa de éstos. En el primer nivel de especialización encontramos las clases “Carnívoro” y “Herbívoro”, ambas son sendos tipos de animal y por tanto comen, sólo que en el caso de los carnívoros se ha especializado el tipo de comida que comen para indicar que se trata de carne. Aparece una nueva característica de este tipo de animal, que es el hecho de que los carnívoros cazan. En el caso de los herbívoros, encontramos que comen plantas y pacen. En el segundo nivel de especialización, encontramos un animal que es a la vez “Herbívoro” y “Carnívoro” y, como cabe esperar, este nuevo tipo de animal puede hacer todo lo que pueden hacer sus ancestros, comer carne, comer plantas, cazar y pacer, no encontrando ninguna característica adicional en los “Omnívoros”.  Qué es una Interfaz. Una interfaz es un mecanismo que emplean dos objetos para interactuar. En nuestro ejemplo de la tostadora, el humano emplea el botón de tostar a modo de interfaz para pasar el mensaje “tuesta el pan que tienes en la bandeja”. Las interfaces definen un conjunto de métodos para establecer el protocolo en base al cual interactúan dos objetos. En este sentido, existe una analogía entre interfaces y protocolos. Para que el humano pueda tostar, debe seguir el protocolo establecido por la interfaz botón de tostar, consistente en pulsar dicho botón. Las interfaces capturan las similitudes entre clases no relacionaras, sin necesidad de forzar una interrelación y son a su vez clases. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

98

ANÁLISIS Y DISEÑO DE SISTEMAS TAREA 05: IMPLEMENTAR DIAGRAMAS CONFORME UML. En esta tarea trataremos las siguientes operaciones:  Entender la importancia de utilizar UML para el diseño del sistema.  Realizar la configuración del software.


   


OPERACIONES.

DIAGRAMA DE CASO DE USO EN RATIONAL ROSE. 1. Ingrese a la aplicación Rational Rose. 2. En la primera pantalla haga clic en el botón Cancel. La primera pantalla tiene la típica estructura de una venta de Microsoft Windows. 3. Ubicar el cursos de mouse en el área de navegación y haga clic en la opción Use Case View. 4. Haga doble clic en Main. 5. Elija el botón Actor y haga clic en el área de diseño para ingresar la entidad y por ultimo ingrese el nombre Clientes. 6. Elija el botón Use Case y haga clic en el área de diseño y por ultimo ingrese el texto Ganar Dinero. 7. Repita la acción elija el botón Use Case y haga clic en el área de diseño y por ultimo ingrese el texto Usar Internet. 8. Elija el botón Use Case y haga clic en el área de diseño y por ultimo ingrese el texto Identificar Identidad.


99


9. Haga clic en el botón Unidirectional Association y realice un arrastre desde el actor Cliente hacia el use case Ganar Dinero. 10. Elija el botón Dependency or Instantiates y realice un arrastre desde el Use Case Usar Internet hacia el actor Cliente. 11. Haga doble clic en la línea punteada agregada recientemente y del campo Stereotype seleccione la opción extend. 12. Elija el botón Dependency or Instantiates y realice un arrastre desde el Use Case Ganar Dinero hacia el use case Identificar Identidad. 13. Haga doble clic en la línea punteada agregada recientemente y del campo Stereotype seleccione la opción include.

14. Elija el menú File y luego la opción Save As. 15. Ingrese el nombre “Ganar dinero Jugando” y seleccione una ubicación, luego haga clic en Guardar.

DIAGRAMA DE CASO DE USO AUTENTIFICACIÓN AL SISTEMA. 1. Elija el menú File y luego la opción New. 2. En la primera pantalla haga clic en el botón Cancel. La primera pantalla tiene la típica estructura de una venta de Microsoft Windows.


100

ANÁLISIS Y DISEÑO DE SISTEMAS 3. Ubicar el cursos de mouse en el área de navegación y haga clic en la opción Use Case View. 4. Haga doble clic en Main. 5. Elija el botón Actor y haga clic en el área de diseño para ingresar la entidad y por ultimo ingrese el nombre Administrador. 6. Repita la acción, elija el botón Actor y haga clic en el área de diseño para ingresar la entidad y por ultimo ingrese el nombre Usuario. 7. Agregue tres actores más con el nombre Invitado, sistema y base de datos.

8. Elija el botón Use Case y haga clic en el área de diseño y por ultimo ingrese el texto Realizar Logueo. 9. Haga clic en el botón Unidirectional Association y realice un arrastre desde el actor Administrador hacia el use case Realizar Logueo. 10. Repetir la misma acción con los tres primeros actores.

8. Haga clic en el botón Unidirectional Association y realice un arrastre desde el use case “Realizar loqueo” hacia el actor Sistema.


101

ANÁLISIS Y DISEÑO DE SISTEMAS 9. Elija el botón Use Case y haga clic en el área de diseño y por ultimo ingrese el texto Autorizar Ingreso. 10. Haga clic en el botón Unidirectional Association y realice un arrastre desde el actor Sistema hacia el use case Autorizar Ingreso. 11. Repita la acción agregando un use case con el nombre Consultar Identidad y otro con el nombre Devolver una respuesta. 12. Haga clic en el botón Unidirectional Association y realice un arrastre desde el actor Sistema hacia el use case Consultar Identidad. 13. Elija en el botón Unidirectional Association y realice un arrastre desde el use case Consultar Identidad hacia actor base de datos. 14. Haga clic en el botón Unidirectional Association y realice un arrastre desde el actor Base de datos hacia el use case Devolver una respuesta. Repetir la misma acción hacia el actor sistema, quedando el diseño de la siguiente forma:

8. Elija el botón Use Case e ingrese el texto Verificar Identidad. 9. Haga clic en el botón Unidirectional Association y realice un arrastre desde el actor Base de datos hacia el use case Verificar Identidad. 10. Elija el menú File y luego la opción Save As. 11. Ingrese el nombre “Autentificación al sistema” y seleccione una ubicación, luego haga clic en Guardar.

Diagrama de caso de uso de Trámite documentario. 1. Elija el menú File y luego la opción New. 2. En la primera pantalla haga clic en el botón Cancel. La primera pantalla tiene la típica estructura de una venta de Microsoft Windows. 3. Ubicar el cursos de mouse en el área de navegación y haga clic en la opción Use Case View. 4. Haga doble clic en Main.


102

ANÁLISIS Y DISEÑO DE SISTEMAS 5. Elija el botón Actor y haga clic en el área de diseño para ingresar la entidad y por ultimo ingrese el nombre Cliente. 6. Repita la acción, elija el botón Actor y haga clic en el área de diseño para ingresar la entidad y por ultimo ingrese el nombre Secretaria. Agregue dos actores más con el nombre Sistema, y Base de datos.

7. Elija el botón Use Case e ingrese el texto Elabora Documento. 8. Haga clic en el botón Unidirectional Association y realice un arrastre desde el actor Cliente hacia el use case Elabora Documento. 9. Elija el botón Use Case y haga clic en el área de diseño y por ultimo ingrese el texto Entrega Documento. 10. Ubique el botón Unidirectional Association y realice un arrastre desde el actor Cliente hacia el use case Entrega Documento. 11. Vuelva a repetir la acción con el botón Unidirectional Association y realice un arrastre desde el use case Entrega Documento hacia el actor secretaria. 12. Elija el botón Use Case e ingrese el texto Recepcionar Documento. 13. Haga clic en el botón Unidirectional Association y realice un arrastre desde el actor Secretaria hacia el use case Recepcionar Documento. 14. Elija el botón Use Case y haga clic en el área de diseño y por ultimo ingrese el texto Registrar los datos. 15. Vuelva a repetir la acción con el botón Unidirectional Association y realice un arrastre desde el actor secretaria hacia el use case Registrar los datos. 16. Elija el botón Use Case e ingrese el texto Sellar el cargo.


103


17. Haga clic en el botón Unidirectional Association y realice un arrastre desde el actor Secretaria hacia el use case Sellar el cargo. 18. Elija el botón Use Case y haga clic en el área de diseño y por ultimo ingrese el texto Ingresar datos. 19. Haga clic en el botón Unidirectional Association y realice un arrastre desde el actor Secretaria hacia el use case Ingresar datos y luego de la misma hacia Sistema. 20. Complete la operación hasta que el diseño quede de la siguiente forma:

DIAGRAMA DE SECUENCIA Y COLABORACIÓN. 1. Elija el menú File y luego la opción New. 2. En la primera pantalla haga clic en el botón Cancel. La primera pantalla tiene la típica estructura de una venta de Microsoft Windows. 3. Ubicar el cursos de mouse en el área de navegación y haga clic en la opción Logical View y luego en la opción New y por último en Séquense Diagrama.


104

ANÁLISIS Y DISEÑO DE SISTEMAS 4. Ingrese el nombre para el diagrama, en este caso para la operación será “Ejemplo de Secuencia”. 5. Elija el botón object y haga clic en el área de diseño y por ultimo ingrese el texto Persona1. 6. Vuelva a repetir la acción con el botón object y haga clic en el área de diseño e ingrese el texto Persona2. 7. Haga clic en el botón Object Message y realice un arrastre desde el object “Persona 1” hacia el object “Persona 2”

El número 1 simboliza la primera acción.

El rectángulo La línea punteada es el tiempo de vida

vertical indica el tiempo de vida de la acción.

de los objetos.

8. Haga doble clic en el número uno del diseño e ingrese el siguiente texto “Mensaje 1()”. 9. Seleccione el botón Return Message y realice un arrastre desde el object “Persona 2” hacia el object “Persona 1 y por ultimo haga doble clic en el número dos del diseño e ingrese el siguiente texto “Respuesta ()”. 10. Elija el botón Object Message y realice un arrastre desde el object “Persona 2” hacia el object “Persona 1” 11. Haga doble clic en el número dos del diseño e ingrese el siguiente texto “Mensaje 2()”. 12. Seleccione el botón Return Message y realice un arrastre desde el object “Persona 1” hacia el object “Persona 2 y por ultimo haga doble clic en el número cuatro del diseño e ingrese el siguiente texto “Respuesta ()”.


105


EJEMPLO DE DIAGRAMA DE SECUENCIA Y COLABORACIÓN PARA LA GENERACIÓN DE UNA TARJETA. 1. Ingrese a la aplicación Rational Rose. 2. En la primera pantalla haga clic en el botón Cancel. La primera pantalla tiene la típica estructura de una venta de Microsoft Windows. 3. Ubicar el cursos de mouse en el área de navegación y haga clic derecho Use Case View. Del menú contextual seleccione la opción New y por ultimo Package. El nombre del paquete será “Actores del sistema” El nombre del paquete será “Actores del sistema”

4. Haga clic derecho en el package “Actores del Sistema” y del menú contextual seleccione la opción New y por ultimo Actor e ingrese el siguiente nombre: “Cajero”. 5. Repita la acción de crear un nuevos actores para el package “Actores del Sistema” con los siguientes nombres; Especialista en Apertura de cuentas, Gerente de Agencias, Jefe de turno, Usuario.


106


Actores creados para el package “Actores del Sistema”

6. Haga clic en el actor “Especialista en Apertura de Cuentas” y haga clic en el área de diseño. 7. Elija el botón object e insertarlo al costado del objeto agregado anteriormente y por ultimo ingrese el texto “Interfaz Principal”. 8. Repita la acción de crear un nuevos object para el diseño con los siguientes nombres; Interfaz Generar Tarjeta; Controlador generar tarjeta; Entidad Tarjeta; Entidad Cuenta de Ahorro.

9. Elija el botón Object Message y realice un arrastre desde el “Especialista en Apertura de cuentas” hacia la “Interfaz Principal”. 10. Haga doble clic en el número uno del diseño e ingrese el siguiente texto “Mensaje 1()”.


107

ANÁLISIS Y DISEÑO DE SISTEMAS 11. Seleccione el botón Object Message y realice un arrastre desde el object “Interfaz Principal” hacia la “Interfaz Generar tarjeta”. 12. Haga doble clic en el número dos del diseño e ingrese el siguiente texto “Cargar Interfaz”.

13. Seleccione el botón Object Message y realice un arrastre desde el actor “Especialista en Apertura de cuentas” hacia la “Interfaz Generar tarjeta”. 14. Haga doble clic en el número tres del diseño e ingrese el siguiente texto “Ingresar número de cuenta de ahorro”. 15. Repita la acción y elija el botón Object Message y realice un arrastre desde el actor “Especialista en Apertura de cuentas” hacia la “Interfaz Generar tarjeta”, e ingrese el texto “Hacer clic en Generar Tarjeta”.

16. Seleccione el botón Object Message y realice un arrastre desde la “Interfaz Generar tarjeta” hacia la “Controlador Generar tarjeta”, e ingrese el texto “Generar Tarjeta”. 17. Repita la acción y elija el botón Object Message y realice un arrastre desde el object “Controlador generar tarjeta” hacia la “Entidad cuenta de Ahorro”, e ingrese el texto “Buscar cuenta de Ahorro”. 18. Haga clic en el botón Message to Selft y ubicarlo en el “Controlador generar tarjeta” e ingrese el nombre “Verificar cuenta de Ahorro”


108

ANÁLISIS Y DISEÑO DE SISTEMAS 19. Seleccione el botón Object Message y realice un arrastre desde la “Controlador generar tarjeta” hacia la “Entidad Tarjeta”, e ingrese el texto “Registrar tarjeta”.

20. Haga clic en el menú Browse y luego en la opción Go to Collaboration Diagram

21. Ordene los objetos hasta quedar conforme con el diagrama.


109


FUNDAMENTO TEÓRICO: Modelos. Un modelo representa a un sistema software desde una perspectiva específica. Al igual que la planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema. Los modelos de UML que se tratan en esta parte son los siguientes:

Diagrama de Estructura Estática.

Diagrama de Casos de Uso.

Diagrama de Secuencia.

Diagrama de Colaboración.


Diagrama de Estados.

110

ANÁLISIS Y DISEÑO DE SISTEMAS Elementos Comunes a Todos los Diagramas  Notas. Una nota sirve para añadir cualquier tipo de comentario a un diagrama o a un elemento de un diagrama. Es un modo de indicar información en un formato libre, cuando la notación del diagrama en cuestión no nos permite expresar dicha información de manera adecuada. Una nota se representa como un rectángulo con una esquina doblada con texto en su interior.

Usuario puede ser cualquiera de Los actores definidos en el sistema

 Dependencias. La relación de dependencia entre dos elementos de un diagrama significa que un cambio en el elemento destino puede implicar un cambio en el elemento origen (por tanto, si cambia el elemento destino habría que revisar el elemento origen). Una dependencia se representa por medio de una línea de trazo discontinuo entre los dos elementos con una flecha en su extremo.

Pueden existir Dependencias entre dos Elementos cualesquiera

Clase dependiente

Clase de la que depende

Diagramas de Estructura Estática Con el nombre de Diagramas de Estructura se engloba tanto al Modelo Conceptual de la fase de Análisis como al Diagrama de Clases de la fase de Diseño. Ambos son distintos conceptualmente, mientras el primero modela elementos del dominio el segundo presenta los elementos de la solución software. Sin embargo, ambos comparten la misma notación para los


111

ANÁLISIS Y DISEÑO DE SISTEMAS elementos que los forman (clases y objetos) y las relaciones que existen entre los mismos (asociaciones). Clases. Una clase se representa mediante una caja subdividida en tres partes: En la superior se muestra el nombre de la clase, en la media los atributos y en la inferior las operaciones. Una clase puede representarse de forma esquemática (plegada), con los detalles como atributos y operaciones suprimidos, siendo entonces tan solo un rectángulo con el nombre de la clase. En la Figura 5 se ve cómo una misma clase puede representarse a distinto nivel de detalle según interese, y según la fase en la que se esté. Objetos. Un objeto se representa de la misma forma que una clase. En el compartimento superior aparece el nombre del objeto junto con el nombre de la clase subrayados, según la siguiente sintaxis: nombre_del_objeto: nombre_de_la_clase Puede representarse un objeto sin un nombre específico, entonces sólo aparece el nombre de la clase. Asociaciones Las asociaciones entre dos clases se representan mediante una línea que las une. La línea puede tener una serie de elementos gráficos que expresan características particulares de la asociación. A continuación se verán los más importantes de entre dichos elementos gráficos.  Nombre de la Asociación y Dirección. El nombre de la asociación es opcional y se muestra como un texto que está próximo a la línea. Se puede añadir un pequeño triángulo negro sólido que indique la dirección en la cual leer el nombre de la asociación.”. Los nombres de las asociaciones normalmente se incluyen en los modelos para aumentar la legibilidad. Sin embargo, en ocasiones pueden hacer demasiado abundante la información que se presenta, con el consiguiente riesgo de saturación. En ese caso se puede suprimir el nombre de las asociaciones consideradas como suficientemente conocidas. En las asociaciones de tipo agregación y de herencia no se suele poner el nombre.  Multiplicidad a multiplicidad es una restricción que se pone a una asociación, que limita el número de instancias de una clase que pueden tener esa asociación con una instancia de la otra clase. Puede expresarse de las siguientes formas: Con un número fijo: 1. Con un intervalo de valores: 2..5.


112




 





Con un rango en el cual uno de los extremos es un asterisco. Significa que es un intervalo abierto. Por ejemplo, 2..* significa 2 o más. Con una combinación de elementos como los anteriores separados por comas: 1, 3..5, 7, 15..*. Con un asterisco: * . En este caso indica que puede tomar cualquier valor (cero o más). Roles. Para indicar el papel que juega una clase en una asociación se puede especificar un nombre de rol. Se representa en el extremo de la asociación junto a la clase que desempeña dicho rol. Agregación: El símbolo de agregación es un diamante colocado en el extremo en el que está la clase que representa el “todo”. Clases Asociación. Cuando una asociación tiene propiedades propias se representa como una clase unida a la línea de la asociación por medio de una línea a trazos. Tanto la línea como el rectángulo de clase representan el mismo elemento conceptual: la asociación. Por tanto ambos tienen el mismo nombre, el de la asociación. Cuando la clase asociación sólo tiene atributos el nombre suele ponerse sobre la línea (como ocurre en el ejemplo de la Figura 11). Por el contrario, cuando la clase asociación tiene alguna operación o asociación propia, entonces se pone el nombre en la clase asociación y se puede quitar de la línea. Asociaciones N-Arias En el caso de una asociación en la que participan más de dos clases, las clases se unen con una línea a un diamante central. Si se muestra multiplicidad en un rol, representa el número potencial de tuplas de instancias en la asociación cuando el resto de los N-1 valores están fijos. En la Figura 12 se ha impuesto la restricción de que un jugador no puede jugar en dos equipos distintos a lo largo de una temporada, porque la multiplicidad de “Equipo” es 1 en la asociación ternaria. Navegabilidad En un extremo de una asociación se puede indicar la navegabilidad mediante una flecha. Significa que es posible "navegar" desde el objeto de la clase origen hasta el objeto de la clase destino. Se trata de un concepto de diseño, que indica que un objeto de la clase origen conoce al (los) objeto(s) de la clase destino, y por tanto puede llamar a alguna de sus operaciones.

Herencia. La relación de herencia se representa mediante un triángulo en el extremo de la relación que corresponde a la clase más general o clase “padre”. Si se tiene una relación de herencia con varias clases subordinadas, pero en un diagrama concreto no se quieren poner todas, esto se representa mediante puntos suspensivos. Un elemento derivado es aquel cuyo valor se puede calcular a partir de otros elementos presentes en el modelo, pero que se incluye en el modelo por


113

ANÁLISIS Y DISEÑO DE SISTEMAS motivos de claridad o como decisión de diseño. Se representa con una barra “/” precediendo al nombre del elemento derivado.

Diagrama de Casos de Uso. Un Diagrama de Casos de Uso muestra la relación entre los actores y los casos de uso del sistema. Representa la funcionalidad que ofrece el sistema en lo que se refiere a su interacción externa. Los elementos que pueden aparecer en un Diagrama de Casos de Uso son: actores, casos de uso y relaciones entre casos de uso.

Actores. Un actor es una entidad externa al sistema que realiza algún tipo de interacción con el mismo. Se representa mediante una figura humana dibujada con palotes. Esta representación sirve tanto para actores que son personas como para otro tipo de actores (otros sistemas, sensores, etc.).

Casos de Uso. Un caso de uso es una descripción de la secuencia de interacciones que se producen entre un actor y el sistema, cuando el actor usa el sistema para llevar a cabo una tarea específica. Expresa una unidad coherente de funcionalidad, y se representa en el Diagrama de Casos de Uso mediante una elipse con el nombre del caso de uso en su interior. El nombre del caso de uso debe reflejar la tarea específica que el actor desea llevar a cabo usando el sistema. Relaciones entre Casos de Uso. Entre dos casos de uso puede haber las siguientes relaciones:  Extiende: Cuando un caso de uso especializa a otro extendiendo su funcionalidad.  Usa: Cuando un caso de uso utiliza a otro. Se representan como una línea que une a los dos casos de uso relacionados, con una flecha en forma de triángulo y con una etiqueta <> o <> según sea el tipo de relación. En el diagrama de casos de uso se representa también el sistema como una caja rectangular con el nombre en su interior. Los casos de uso están en el interior de la caja del sistema, y los actores fuera, y cada actor está unido a los casos de uso en los que participa mediante una línea.


114

ANÁLISIS Y DISEÑO DE SISTEMAS Diagramas de Interacción. En los diagramas de interacción se muestra un patrón de interacción entre objetos. Hay dos tipos de diagrama de interacción, ambos basados en la misma información, pero cada uno enfatizando un aspecto particular: Diagramas de Secuencia y Diagramas de Colaboración.

Diagrama de Secuencia. Un diagrama de Secuencia muestra una interacción ordenada según la secuencia temporal de eventos. En particular, muestra los objetos participantes en la interacción y los mensajes que intercambian ordenados según su secuencia en el tiempo. El eje vertical representa el tiempo, y en el eje horizontal se colocan los objetos y actores participantes en la interacción, sin un orden prefijado. Cada objeto o actor tiene una línea vertical, y los mensajes se representan mediante flechas entre los distintos objetos. El tiempo fluye de arriba abajo. Se pueden colocar etiquetas (como restricciones de tiempo, descripciones de acciones, etc.) bien en el margen izquierdo o bien junto a las transiciones o activaciones a las que se refieren.

Diagrama de Colaboración. Un Diagrama de Colaboración muestra una interacción organizada basándose en los objetos que toman parte en la interacción y los enlaces entre los mismos (en cuanto a la interacción se refiere). A diferencia de los Diagramas de Secuencia, los Diagramas de Colaboración muestran las relaciones entre los roles de los objetos. La secuencia de los mensajes y los flujos de ejecución concurrentes deben determinarse explícitamente mediante números de secuencia. En cuanto a la representación, un Diagrama de Colaboración muestra a una serie de objetos con los enlaces entre los mismos, y con los mensajes que se intercambian dichos objetos. Los Mensajes son flechas que van junto al enlace por el que “circulan”, y con el nombre del mensaje y los parámetros (si los tiene) entre paréntesis. Cada mensaje lleva un número de secuencia que denota cuál es el mensaje que le precede, excepto el mensaje que inicia el diagrama, que no lleva número de secuencia. Se pueden indicar alternativas con condiciones entre corchetes (por ejemplo 3 [condición_de_test] : nombre_de_método() ).


115

ANÁLISIS Y DISEÑO DE SISTEMAS Diagrama de Estados. Un Diagrama de Estados muestra la secuencia de estados por los que pasa un caso de uso o un objeto a lo largo de su vida, indicando qué eventos hacen que se pase de un estado a otro y cuáles son las respuestas y acciones que genera. En cuanto a la representación, un diagrama de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son transiciones etiquetadas con los nombres de los eventos. Un estado se representa como una caja redondeada con el nombre del estado en su interior. Una transición se representa como una flecha desde el estado origen al estado destino. La caja de un estado puede tener 1 o 2 compartimentos. En el primer compartimento aparece el nombre del estado. El segundo compartimento es opcional, y en él pueden aparecer acciones de entrada, de salida y acciones internas. Una acción de entrada aparece en la forma entrada/acción asociada donde acción asociada es el nombre de la acción que se realiza al entrar en ese estado. Cada vez que se entra al estado por medio de una transición la acción de entrada se ejecuta. Una acción de salida aparece en la forma salida/acción asociada. Cada vez que se sale del estado por una transición de salida la acción de salida se ejecuta. Una acción interna es una acción que se ejecuta cuando se recibe un determinado evento en ese estado, pero que no causa una transición a otro estado. Se indica en la forma nombre_de_evento/acción asociada. Un diagrama de estados puede representar ciclos continuos o bien una vida finita, en la que hay un estado inicial de creación y un estado final de destrucción (del caso de uso o del objeto). El estado inicial se muestra como un círculo sólido y el estado final como un círculo sólido rodeado de otro círculo. En realidad, los estados inicial y final son pseudoestados, pues un Objeto no puede “estar” en esos estados, pero nos sirven para saber cuáles son las transiciones iniciales y final(es). Desarrollo Orientado a Objetos. Proceso de Desarrollo. Cuando se va a construir un sistema software es necesario conocer un lenguaje de programación, pero con eso no basta. Si se quiere que el sistema sea robusto y mantenible es necesario que el problema sea analizado y la solución sea cuidadosamente diseñada. Se debe seguir un proceso robusto,


116

ANÁLISIS Y DISEÑO DE SISTEMAS que incluya las actividades principales. Si se sigue un proceso de desarrollo que se ocupa de plantear cómo se realiza el análisis y el diseño, y cómo se relacionan los productos de ambos, entonces la construcción de sistemas software va a poder ser planificable y repetible, y la probabilidad de obtener un sistema de mejor calidad al final del proceso aumenta considerablemente, especialmente cuando se trata de un equipo de desarrollo formado por varias personas. Para este curso se va a seguir el método de desarrollo orientado a objetos que propone Craig Larman [Larman99]. Este proceso no fija una metodología estricta, sino que define una serie de actividades que pueden realizarse en cada fase, las cuales deben adaptarse según las condiciones del proyecto que se esté llevando a cabo. Se ha escogido seguir este proceso debido a que aplica los últimos avances en Ingeniería del Software, y a que adopta un enfoque eminentemente práctico, aportando soluciones a las principales dudas y/o problemas con los que se enfrenta el desarrollador. Su mayor aportación consiste en atar los cabos sueltos que anteriores métodos dejan. La notación que se usa para los distintos modelos, tal y como se ha dicho anteriormente, es la proporcionada por UML, que se ha convertido en el estándar de facto en cuanto a notación orientada a objetos. El uso de UML permite integrar con mayor facilidad en el equipo de desarrollo a nuevos miembros y compartir con otros equipos la documentación, pues es de esperar que cualquier desarrollador versado en orientación a objetos conozca y use UML (o se esté planteando su uso). Se va a abarcar todo el ciclo de vida, empezando por los requisitos y acabando en el sistema funcionando, proporcionando así una visión completa y coherente de la producción de sistemas software. El enfoque que toma es el de un ciclo de vida iterativo incremental, el cual permite una gran flexibilidad a la hora de adaptarlo a un proyecto y a un equipo de desarrollo específicos. El ciclo de vida está dirigido por casos de uso, es decir, por la funcionalidad que ofrece el sistema a los futuros usuarios del mismo. Así no se pierde de vista la motivación principal que debería estar en cualquier proceso de construcción de software: el resolver una necesidad del usuario/cliente.

Visión General. El proceso a seguir para realizar desarrollo orientado a objetos es complejo, debido a la complejidad que nos vamos a encontrar al intentar desarrollar cualquier sistema software de tamaño medio-alto. El proceso está formado por una serie de actividades y subactividades, cuya realización se va repitiendo en el tiempo aplicado a distintos elementos.


117

ANÁLISIS Y DISEÑO DE SISTEMAS En este apartado se va a presentar una visión general para poder tener una idea del proceso a alto nivel, y más adelante se verán los pasos que componen cada fase. Las tres fases al nivel más alto son las siguientes: Planificación y Especificación de Requisitos: Planificación, definición de requisitos, construcción de prototipos, etc. Construcción: La construcción del sistema. Las fases dentro de esta etapa son las siguientes: Análisis: Se analiza el problema a resolver desde la perspectiva de los usuarios y de las entidades externas que van a solicitar servicios al sistema. Diseño: El sistema se especifica en detalle, describiendo cómo va a funcionar internamente para satisfacer lo especificado en el análisis. Implementación: Se lleva lo especificado en el diseño a un lenguaje de programación. Pruebas: Se llevan a cabo una serie de pruebas para corroborar que el software funciona correctamente y que satisface lo especificado en la etapa de Planificación y Especificación de Requisitos. Instalación: La puesta en marcha del sistema en el entorno previsto de uso. De ellas, la fase de Construir es la que va a consumir la mayor parte del esfuerzo y del tiempo en un proyecto de desarrollo. Para llevarla a cabo se va adoptar un enfoque iterativo, tomando en cada iteración un subconjunto de los requisitos (agrupados según casos de uso) y llevándolo a través del análisis y diseño hasta la implementación y pruebas. Fase de Planificación y Especificación de Requisitos Esta fase se corresponde con la Especificación de Requisitos tradicional ampliada con un Borrador de Modelo Conceptual y con una definición de Casos de Uso de alto nivel. En esta fase se decidiría si se aborda la construcción del sistema mediante desarrollo orientado a objetos o no, por lo que, en principio, es independiente del paradigma empleado posteriormente. 1. Actividades. Las actividades de esta fase son las siguientes: Definir el Plan-Borrador.


118

ANÁLISIS Y DISEÑO DE SISTEMAS Crear el Informe de Investigación Preliminar. Definir los Requisitos. Registrar Términos en el Glosario. (Continuado en posteriores fases) Implementar un Prototipo. (Opcional) Definir Casos de Uso (de alto nivel y esenciales). Definir el Modelo Conceptual-Borrador. (Puede retrasarse hasta una fase posterior). Definir la Arquitectura del Sistema-Borrador. (Puede retrasarse hasta una fase posterior) Refinar el Plan. El orden propuesto es el que parece más lógico. De todos modos, el orden no es estricto, lo normal es que las distintas actividades se solapen en el tiempo. Esto sucede también en las actividades de las fases de Análisis y de Diseño, que se verán más adelante. De estas actividades no se va a entrar en las que corresponden al campo de la planificación de proyectos software, como las correspondientes a creación de planes e informes preliminares. Tan solo se va a ver por encima la actividad de Definición de Requisitos en cuanto está relacionada con los Casos de Uso, pues son éstos los que van a servir de punto de partida en el Análisis Orientado a Objetos. 2. Requisitos. Un requisito es una descripción de necesidades o aspiraciones respecto a un producto. El objetivo principal de la actividad de definición de requisitos consiste en identificar qué es lo que realmente se necesita, separar el grano de la paja. Esto se hace en un modo que sirva de comunicación entre el cliente y el equipo de desarrollo. Es aconsejable que un documento de Especificación de Requisitos tenga los siguientes puntos:  Propósito.  Ámbito del Sistema, Usuarios.  Funciones del Sistema.  Atributos del Sistema. El formato del documento de Especificación de Requisitos no está definido en UML, pero se ha incluido este punto para resaltar que la actividad de definición de requisitos es un paso clave en la creación de cualquier producto software.


119

ANÁLISIS Y DISEÑO DE SISTEMAS Para refinar los requisitos y mejorar la comprensión de los mismos la técnica de casos de uso constituye una valiosa ayuda. 3. Casos de Uso. Un Caso de Uso es un documento narrativo que describe la secuencia de eventos de un actor (un agente externo) que usa un sistema para completar un proceso [Jacobson92]. Es una historia o una forma particular de usar un sistema. Los casos de uso no son exactamente requisitos ni especificaciones funcionales, pero ilustran e implican requisitos en las historias que cuentan. En la página 9 se definió la notación de UML para los Diagramas de Casos de Uso. Nótese que UML no define un formato para describir un caso de uso. Tan sólo define la manera de representar la relación entre actores y casos de uso en un diagrama (Diagrama de Casos de Uso). El formato textual que se va a usar en este texto para definir los casos de uso se va a definir a continuación, mientras que la representación de los escenarios correspondientes a un caso de uso por medio de Diagramas de Secuencia se verá más adelante. En un primer momento interesa abordar un caso de uso desde un nivel de abstracción alto, es lo que se denomina Caso de Uso de Alto Nivel.

Fase de Construcción: Análisis En la fase de Análisis de un ciclo de desarrollo se investiga sobre el problema, sobre los conceptos relacionados con el subconjunto de casos de uso que se esté tratando. Se intenta llegar a una buena comprensión del problema por parte del equipo de desarrollo, sin entrar en cómo va a ser la solución en cuanto a detalles de implementación. Cuando el ciclo de desarrollo no es el primero, antes de la fase de Análisis hay una serie de actividades de planificación. Estas actividades consisten en actualizar los modelos que se tengan según lo que se haya implementado, pues siempre se producen desviaciones entre lo que se ha analizado y diseñado y lo que finalmente se construye. Una vez se tienen los modelos acordes con lo implementado se empieza el nuevo ciclo de desarrollo con la fase de Análisis. En esta fase se trabaja con los modelos de Análisis construidos en la fase anterior, ampliándolos con los conceptos correspondientes a los casos de uso que se traten en el ciclo de desarrollo actual.


120

ANÁLISIS Y DISEÑO DE SISTEMAS 1. Actividades. Las actividades de la fase de Análisis son las siguientes: Definir Casos de Uso Esenciales en formato expandido. (Si no están definidos). Refinar los Diagramas de Casos de Uso. Refinar el Modelo Conceptual. Refinar el Glosario. (Continuado en posteriores fases). Definir los Diagramas de Secuencia del Sistema. Definir Contratos de Operación. Definir Diagramas de Estados. (Opcional). 2. Modelo Conceptual. Una parte de la investigación sobre el dominio del problema consiste en identificar los conceptos que lo conforman. Para representar estos conceptos se va a usar un Diagrama de Estructura Estática de UML, al que se va a llamar Modelo Conceptual. En el Modelo Conceptual se tiene una representación de conceptos del mundo real, no de componentes software. El objetivo de la creación de un Modelo Conceptual es aumentar la comprensión del problema. Por tanto, a la hora de incluir conceptos en el modelo, es mejor crear un modelo con muchos conceptos que quedarse corto y olvidar algún concepto importante. Para identificar conceptos hay que basarse en el documento de Especificación de Requisitos y en el conocimiento general acerca del dominio del problema. En la Tabla se muestran algunas categorías típicas, junto con ejemplos pertenecientes al dominio de los supermercados y al de la reserva de billetes de avión: Tipo de Concepto Objetos físicos o tangibles Especificaciones, diseños o descripciones de cosas Lugares Transacciones Líneas de una transacción Roles de una persona

Ejemplos Avión Terminal_de_Caja Especificación_de_Producto Descripción_de_Vuelo Supermercado Aeropuerto Venta, Pago Reserva Artículo_de_Venta Cajero


121

ANÁLISIS Y DISEÑO DE SISTEMAS Piloto Supermercado, Cesta

Contenedores de otras cosas

Avión Artículo Pasajero

Cosas en un contenedor Otros ordenadores o sistemas electromecánicos externos a nuestro sistema

Sistema_de_Autorización_de_Tarjetas_de Crédito Sistema_Controlador_de_Tráfico_Aéreo Departamento_de_Ventas

Organizaciones

Compañía_Aérea_Toto Venta, Robo, Reunión

Eventos

Vuelo, Accidente, Aterrizaje Política_de_Devoluciones

Reglas y políticas

Política_de_Cancelaciones Catálogo_de_Productos

Catálogos

Catálogo_de_Piezas

Archivos financieros, de trabajo, de contratos, de asuntos legales Instrumentos y servicios financieros Manuales, libros

Recibo, Contrato_de_Empleo Registro_de_Revisiones Línea_de_Crédito Stock Manual_del_Empleado Manual_de_Reparaciones

Identificación de Asociaciones. Una asociación es una relación entre conceptos que indica una conexión con sentido y que es de interés en el conjunto de casos de uso que se está tratando. Se incluyen en el modelo las asociaciones siguientes: Categoría

Ejemplos

A es una parte física de B

Ala – Avión

A es una parte lógica de B

Artículo_en_Venta –Venta

A está físicamente contenido en B

Artículo – Estantería

A está lógicamente contenido en B

Descripción_de_Artículo – Catálogo

A es una descripción de B

Descripción_de_Artículo – Artículo

A es un elemento en una transacción o un informe B A es registrado/archivado/capturado en B

Trabajo_de_Reparación – Registro_de_Reparaciones Venta – Terminal_de_Caja


122


A es un miembro de B

A es una subunidad organizativa de B

A usa o gestiona B

A comunica con B

A está relacionado con una transacción B

Cajero – Supermercado Piloto – Compañía_Aerea Sección – Supermercado Mantenimiento – Compañía_Aerea Cajero – Terminal_de_Caja Piloto – Avión Cliente – Cajero Empleado_de_Agencia_de_Viajes – Pasajero Cliente – Pago Pasajero – Billete

A es una transacción relacionada con otra

Pago – Venta

transacción B

Reserva – Cancelación

A está junto a B

Ciudad – Ciudad

A posee B

Supermercado – Terminal_de_Caja Compañía_Aérea – Avión

Identificación de Atributos. Es necesario incorporar al Modelo Conceptual los atributos necesarios para satisfacer las necesidades de información de los casos de uso que se estén desarrollando en ese momento. Los atributos deben tomar valor en tipos simples (número, texto, etc.), pues los tipos complejos deberían ser modelados como conceptos y ser relacionados mediante asociaciones. Incluso cuando un valor es de un tipo simple es más conveniente representarlo como concepto en las siguientes ocasiones: Se compone de distintas secciones. Por ejemplo: un número de teléfono, el nombre de una persona, etc. Tiene operaciones asociadas, tales como validación. Ejemplo: NIF. Tiene otros atributos. Por ejemplo un precio de oferta puede tener fecha de fin. Es una cantidad con una unidad. Ejemplo: El precio, que puede estar en pesetas o en euros. Una vez definidos los atributos se tiene ya un Modelo Conceptual. Este modelo no es un modelo definitivo, pues a lo largo del Análisis y del Diseño se va refinando según se le añaden conceptos que se habían pasado por alto. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

123

ANÁLISIS Y DISEÑO DE SISTEMAS Glosario. En el glosario debe aparecer una descripción textual de cualquier elemento de cualquier modelo, para eliminar toda posible ambigüedad. Un formato tipo para el glosario es el que se muestra en la Tabla 3. Formato tipo de Glosario. Término

Categoría

Realizar Reintegro

caso de uso

Banco

concepto

Descripción Descripción del proceso por el que un Cliente realiza un reintegro en un cajero automático. Entidad que ofrece servicios financieros a sus clientes.

3. Diagramas de Secuencia del Sistema. En cada caso de uso se muestra una interacción de actores con el sistema. En esta interacción los actores generan eventos, solicitando al sistema operaciones. Por ejemplo, en el caso de una reserva de un billete de avión, el empleado de la agencia de viajes solicita al sistema de reservas que realice una reserva. El evento que supone esa solicitud inicia una operación en el sistema de reservas. Los casos de uso representan una interacción genérica. Una instancia de un caso de uso se denomina escenario, y muestra una ejecución real del caso de uso, con las posibles bifurcaciones y alternativas resueltas de forma particular. Un Diagrama de Secuencia de Sistema se representa usando la notación para diagramas de secuencia de UML. En él se muestra para un escenario particular de un caso de uso los eventos que los actores generan, su orden, y los eventos que se intercambian entre sistemas. Para cada caso de uso que se esté tratando se realiza un diagrama para el curso típico de eventos, y además se realiza un diagrama para los cursos alternativos de mayor interés. Construcción de un Diagrama de Secuencia del Sistema. Para construir un Diagrama de Secuencia del Sistema para el curso típico de eventos de un caso de uso, se siguen los siguientes pasos: Representar el sistema como un objeto con una línea debajo. Identificar los actores que directamente operan con el sistema, y dibujar una línea para cada uno de ellos.


124

ANÁLISIS Y DISEÑO DE SISTEMAS Partiendo del texto del curso típico de eventos del caso de uso, identificar los eventos (externos) del sistema que cada actor genera y representarlos en el diagrama. Opcionalmente, incluir el texto del caso de uso en el margen del diagrama. Los eventos del sistema deberían expresarse en base a la noción de operación que representan, en vez de en base a la interfaz particular. Por ejemplo, se prefiere “finOperación” a “presionadaTeclaEnter”, porque captura la finalidad de la operación sin realizar compromisos en cuanto a la interfaz usada.

Contratos de Operaciones. Una vez se tienen las Operaciones del Sistema identificadas en los Diagramas de Secuencia, se describe mediante contratos el comportamiento esperado del sistema en cada operación. Un Contrato es un documento que describe qué es lo que se espera de una operación. Tiene una redacción en estilo declarativo, enfatizando en el que más que en el cómo. Lo más común es expresar los contratos en forma de pre- y post-condiciones en torno a cambios de estado. Se puede escribir un contrato para un método individual de una clase software, o para una operación del sistema completa. En este punto se verá únicamente éste último caso. Un Contrato de Operación del Sistema describe cambios en el estado del sistema cuando una operación del sistema es invocada. A continuación se ve un ejemplo de Contrato: La descripción de cada apartado de un contrato es como sigue: Nombre:

Nombre de la operación y parámetros.

Responsabilidades:

Una descripción informal de las responsabilidades que la operación debe desempeñar.

Referencias Cruzadas:

Números de referencia en los requisitos de funciones del sistema, casos de uso, etc.

Notas:

Comentarios de diseño, algoritmos, etc.

Excepciones:

Casos excepcionales. Situaciones que debemos tener en cuenta que pueden pasar. Se indica también qué se hace cuando ocurre la excepción.


125


Salida:

Salidas que no corresponden a la interfaz de usuario, como mensajes o registros que se envían fuera del sistema. (En la mayor parte de las operaciones del sistema este apartado queda vacío)

Pre-condiciones:

Asunciones acerca del estado del sistema antes de ejecutar la operación. Algo que no tenemos en cuenta que pueda ocurrir cuando se llama a esta operación del sistema.

Post-condiciones:

El estado del sistema después de completar la operación.

Los pasos a seguir para construir un contrato son los siguientes: Identificar las operaciones del sistema a partir de los Diagramas de Secuencia del Sistema. Para cada operación del sistema construir un contrato. Empezar escribiendo el apartado de Responsabilidades, describiendo informalmente el propósito de la operación. Este es el apartado más importante del contrato. A continuación rellenar el apartado de Post-condiciones, describiendo declarativamente los cambios de estado que sufren los objetos en el Modelo Conceptual. Puede ser que este apartado quede vacío si no cambia el valor de ningún dato de los maneja el sistema (por ejemplo en una operación del sistema que tan solo se encarga de sacar por pantalla algo al usuario). Para describir las post-condiciones, usar las siguientes categorías: Creación y borrado de instancias. Modificación de atributos. Asociaciones formadas y retiradas. Completar el resto de apartados en su caso. 4. Diagramas de Estados. Para modelar el comportamiento del sistema pueden usarse los Diagramas de Estados que define UML (ver página 12). Se puede aplicar un Diagrama de Estados al comportamiento de los siguientes elementos: Una clase software. Un concepto. Un caso de uso.


126

ANÁLISIS Y DISEÑO DE SISTEMAS En la fase de Análisis sólo se haría para los dos últimos tipos de elemento, pues una clase software pertenece al Diagrama de Clases de Diseño. Puesto que el sistema entero puede ser representado por un concepto, también se puede modelar el comportamiento del sistema completo mediante un Diagrama de Estados. La utilidad de un Diagrama de Estados en el análisis reside en mostrar la secuencia permitida de eventos externos que pueden ser reconocidos y tratados por el sistema. Por ejemplo, no se puede insertar una tarjeta en un cajero automático si se está en el transcurso de una operación. Para los casos de uso complejos se puede construir un Diagrama de Estados. El Diagrama de Estados del sistema sería una combinación de los diagramas de todos los casos de uso. El uso de Diagramas de Estados es opcional. Tan solo los usaremos cuando consideremos que nos ayudan a expresar mejor el comportamiento del elemento descrito.

Fase de Construcción: Diseño En la fase de Diseño se crea una solución a nivel lógico para satisfacer los requisitos, basándose en el conocimiento reunido en la fase de Análisis.

Actividades: Las actividades que se realizan en la etapa de Diseño son las siguientes: Definir los Casos de Uso Reales. Definir Informes e Interfase de Usuário. Refinar la Arquitectura del Sistema. Definir los Diagramas de Interacción. Definir el Diagrama de Clases de Diseño. (en paralelo con los Diagramas de Interacción)

Definir el Esquema de Base de Datos. El paso de Refinar la Arquitectura del Sistema puede realizarse antes o después. Casos de Uso Reales. Un Caso de Uso Real describe el diseño real del caso de uso según una tecnología concreta de entrada y de salida y su implementación. Si el caso de


127

ANÁLISIS Y DISEÑO DE SISTEMAS uso implica una interfaz de usuario, el caso de uso real incluirá bocetos de las ventanas y detalles de la interacción a bajo nivel con los widgets (botón, lista seleccionable, campo editable, etc.) de la ventana. Como alternativa a la creación de los Casos de Uso Reales, el desarrollador puede crear bocetos de la interfaz en papel, y dejar los detalles para la fase de implementación. Diagramas de Colaboración. Los Diagramas de Interacción muestran el intercambio de mensajes entre instancias del modelo de clases para cumplir las post-condiciones establecidas en un contrato. Hay dos clases de Diagramas de Interacción: Diagramas de Colaboración. Diagramas de Secuencia. La notación en UML para ambos es la definida en la página 10. De entre ambos tipos se prefieren los Diagramas de Colaboración por su expresividad y por su economía espacial (una interacción compleja puede ser muy larga en un Diagrama de Secuencia). La creación de los Diagramas de Colaboración de un sistema es una de las actividades más importantes en el desarrollo orientado a objetos, pues al construirlos se toman unas decisiones clave acerca del funcionamiento del futuro sistema. La creación de estos diagramas, por tanto, debería ocupar un porcentaje significativo en el esfuerzo dedicado al proyecto entero. Creación de Diagramas de Colaboración. Para crear los Diagramas de Colaboración se pueden seguir los siguientes consejos: Crear un diagrama separado para cada operación del sistema en desarrollo en el ciclo de desarrollo actual. Para cada evento del sistema, hacer un diagrama con él como mensaje inicial. Si el diagrama se complica, dividirlo en diagramas más pequeños. Usando los apartados de responsabilidades y de post-condiciones del contrato de operación, y la descripción del caso de uso como punto de partida, diseñar un sistema de objetos que interaccionan para llevar a cabo las tareas requeridas.


128

ANÁLISIS Y DISEÑO DE SISTEMAS La capacidad de realizar una buena asignación de responsabilidades a los distintos objetos es una habilidad clave, y se va adquiriendo según aumenta la experiencia en el desarrollo orientado a objetos. Booch, Rumbaugh y Jacobson definen responsabilidad como “un contrato u obligación de una clase o tipo”[BJR97]. Las responsabilidades están ligadas a las obligaciones de un objeto en cuanto a su comportamiento. Básicamente, estas responsabilidades son de los dos siguientes tipos: Conocer: Conocer datos privados encapsulados. Conocer los objetos relacionados. Conocer las cosas que puede calcular o derivar. Hacer: Hacer algo él mismo. Iniciar una acción en otros objetos. Controlar y coordinar actividades en otros objetos. Por ejemplo, puedo decir que “un Recibo es responsable de imprimirse” (tipo hacer), o que “una Transacción es responsable de saber su fecha” (tipo conocer). Las responsabilidades de tipo “conocer” se pueden inferir normalmente del Modelo Conceptual. Una responsabilidad no es lo mismo que un método, pero los métodos se implementan para satisfacer responsabilidades. Diagrama de Clases de Diseño Al construir los Diagramas de Colaboración se van usando clases procedentes del Modelo Conceptual, junto con otras creadas para encargarse de responsabilidades específicas. El conjunto de todas las clases usadas, junto con sus relaciones, forma el Diagrama de Clases de Diseño. Un Diagrama de Clases de Diseño muestra la especificación para las clases software de una aplicación. Incluye la siguiente información: Clases, asociaciones y atributos. Interfaces, con sus operaciones y constantes. Métodos. Navegabilidad. • Dependencias. A diferencia del Modelo Conceptual, un Diagrama de Clases de Diseño muestra definiciones de entidades software más que conceptos del mundo real. Relaciones de Dependencia para Representar Visibilidad entre Clases.


129

ANÁLISIS Y DISEÑO DE SISTEMAS Cuando una clase conoce a otra por un medio que no es a través de un atributo (una asociación con la navegabilidad adecuada), entonces es preciso indicar esta situación por medio de una dependencia. Un objeto debe conocer a otro para poder llamar a uno de sus métodos, se dice entonces que el primer objeto tiene “visibilidad” sobre el segundo. La visibilidad más directa es por medio de atributo, cuando hay una asociación entre ambas clases y se puede navegar de la primera a la segunda (un atributo de la primera es un puntero a un objeto de la segunda). Hay otros tres tipos de visibilidad que hay que representar en el diagrama de clases mediante relaciones de dependencia: Parámetro: Cuando a un método de una clase se le pasa como parámetro un objeto de otra clase, se dice que la primera tiene visibilidad de parámetro sobre la segunda. La relación de dependencia entre ambas clases se etiqueta con el estereotipo <> (<> en inglés). Local: Cuando en un método de una clase se define una variable local que es un objeto de otra clase, se dice que la primera tiene visibilidad local sobre la segunda. La relación de dependencia entre ambas clases se etiqueta con el estereotipo <>. Global: Cuando hay una variable global en el sistema, y un método de una clase llama a un método de esa variable global, se dice que la clase tiene visibilidad global sobre la clase a la que pertenece la instancia que es una variable global. La relación de dependencia entre ambas clases se etiqueta con el estereotipo <>. No es necesario representar la relación de dependencia entre clases que ya están relacionadas por medio de una asociación, que se trata de una “dependencia” más fuerte. Las relaciones de dependencia se incluyen tan solo para conocer qué elementos hay que revisar cuando se realiza un cambio en el diseño de un elemento del sistema. Construcción de un Diagrama de Clases de Diseño. Para crear un Diagrama de Clases de Diseño se puede seguir la siguiente estrategia: - Identificar todas las clases participantes en la solución software. Esto se lleva a cabo analizando los Diagramas de Interacción. - Representarlas en un diagrama de clases. - Duplicar los atributos que aparezcan en los conceptos asociados del Modelo Conceptual. - Añadir los métodos, según aparecen en los Diagramas de Interacción. - Añadir información de tipo a los atributos y métodos. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

130

ANÁLISIS Y DISEÑO DE SISTEMAS - Añadir las asociaciones necesarias para soportar la visibilidad de atributos requerida. - Añadir flechas de navegabilidad a las asociaciones para indicar la dirección de visibilidad de los atributos. - Añadir relaciones de dependencia para indicar visibilidad no correspondiente a atributos. No todas las clases que aparecían en el Modelo Conceptual tienen por qué aparecer en el Diagrama de Clases de Diseño. De hecho, tan solo se incluirán aquellas clases que tengan interés en cuanto a que se les ha asignado algún tipo de responsabilidad en el diseño de la interacción del sistema. No hay, por tanto, un transición directa entre el Modelo Conceptual y el Diagrama de Clases de Diseño, debido a que ambos se basan en enfoques completamente distintos: el primero en comprensión de un dominio, y el segundo en una solución software. En la fase de Diseño se añaden los detalles referentes al lenguaje de programación que se vaya a usar. Por ejemplo, los tipos de los atributos y parámetros se expresarán según la sintaxis del lenguaje de implementación escogido. Navegabilidad. La navegabilidad es una propiedad de un rol (un extremo de una asociación) que indica que es posible “navegar” unidireccionalmente a través de la asociación, desde objetos de la clase origen a objetos de la clase destino. Como se vio en la parte II, se representa en UML mediante una flecha. La navegabilidad implica visibilidad, normalmente visibilidad por medio de un atributo en la clase origen. En la implementación se traducirá en la clase origen como un atributo que sea una referencia a la clase destino. Las asociaciones que aparezcan en el Diagrama de Clases deben cumplir una función, deben ser necesarias, si no es así deben eliminarse. Las situaciones más comunes en las que parece que se necesita definir una asociación con navegabilidad de A a B son: A envía un mensaje a B. A crea una instancia B. A necesita mantener una conexión con B. Visibilidad de Atributos y Métodos. Los atributos y los métodos deben tener una visibilidad asignada, que puede ser: ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

131

ANÁLISIS Y DISEÑO DE SISTEMAS + Visibilidad pública. # Visibilidad protegida. - Visibilidad privada. También puede ser necesario incluir valores por defecto, y todos los detalles ya cercanos a la implementación que sean necesarios para completar el Diagrama de Clases. Otros Aspectos en el Diseño del Sistema. En los puntos anteriores se ha hablado de decisiones de diseño a un nivel de granularidad fina, con las clases y objetos como unidades de decisión. En el diseño de un sistema es necesario también tomar decisiones a un nivel más alto sobre la descomposición de un sistema en subsistemas y sobre la arquitectura del sistema (ver sección III.2.5). Esta parte del Diseño es lo que se denomina Diseño del Sistema. Estas decisiones no se toman de forma distinta en un desarrollo orientado a objetos a como se llevan a cabo en un desarrollo tradicional. Por tanto, no se va a entrar en este documento en cómo se realiza esta actividad. Sí hay que tener en cuenta que las posibles divisiones en subsistemas tienen que hacerse en base a las clases definidas en el Diagrama de Clases del Diseño.

Fases de Implementación y Pruebas. Una vez se tiene completo el Diagrama de Clases de Diseño, se pasa a la implementación en el lenguaje de programación elegido. El programa obtenido se depura y prueba, y ya se tiene una parte del sistema funcionando que se puede probar con los futuros usuarios, e incluso poner en producción si se ha planificado una instalación gradual. Una vez se tiene una versión estable se pasa al siguiente ciclo de desarrollo para incrementar el sistema con los casos de uso asignados a tal ciclo.


132

ANÁLISIS Y DISEÑO DE SISTEMAS TAREA 06: DIAGRAMAR UTILIZANDO EL PROCESO DE DESARROLLO DE SOFTWARE (RUP)

En esta tarea trataremos las siguientes operaciones:  Reconocer los requisitos para el diagrama de caso de uso.  Definir e identificar el caso de uso y sus relaciones. EQUIPOS Y MATERIALES:

   


FUNDAMENTO TECNOLÓGICO: RUP es una metodología sólida, con documentación que apoya el ciclo de vida evolutivo incremental, además de orientarse al desarrollo de componentes secundando el desarrollo orientado a objetos RUP es un proceso de ingeniería de software que provee un enfoque disciplinado para la asignación de tareas y responsabilidades dentro de una organización. Su principal objetivo es asegurar la producción de software de alta calidad que satisfaga las necesidades de sus usuarios finales dentro de un presupuesto y tiempo predecibles. Debido a las características que posee de ser una herramienta flexible, le permite un marco de trabajo más amplio el cual puede ser adaptado tanto a empresas grandes como pequeñas y puede ser modificada para ajustarse a la forma de trabajo de una compañía. El Proceso Unificado tiene dos dimensiones:  Un eje horizontal que representa el tiempo y muestra los aspectos del ciclo de vida del proceso a lo largo de su desenvolvimiento.  Un eje vertical que representa las disciplinas, las cuales agrupan actividades de una manera lógica de acuerdo a su naturaleza. La primera dimensión representa el aspecto dinámico del proceso conforme se va desarrollando, se expresa en términos de fases, iteraciones e hitos.


133

ANÁLISIS Y DISEÑO DE SISTEMAS La segunda dimensión representa el aspecto estático del proceso: cómo es descrito en términos de componentes del proceso, disciplinas, actividades, flujos de trabajo, artefactos y roles.

Características de RUP.          

Interactivo. Refinamiento sucesivo. Controlado. Gestión de requisitos y control de cambios Construcción de modelos. Centrado en arquitectura. Desarrollo de software basado en componentes. Conducido por los casos de uso. Soporta técnicas OO (Orientadas a objetos) uso del UML. Configurable. Fomenta al control de calidad del software. Soportado por herramientas.

Reconoce que las necesidades del usuario y sus requerimientos no se pueden definir completamente al principio. Permite evaluar tempranamente los riesgos en lugar de descubrir problemas en la integración final del sistema. Reduce el costo del riesgo a los costos de un solo incremento. Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan para obtener resultados claros a corto plazo. Distribuye la carga de trabajo a lo largo del tiempo del proyecto ya que todas las disciplinas colaboran en cada iteración. Facilita la reutilización del código teniendo en cuenta que se realizan revisiones en las primeras iteraciones lo cual además permite que se aprecien oportunidades de mejoras en el diseño. El proceso de desarrollo está dividido en Fases a lo largo del tiempo cada una de las cuales tiene objetivos específicos y un conjunto de “artefactos” definidos que deben alcanzarse. La duración de cada fase depende del equipo y del producto a generar. A su vez, cada fase puede tener una o más iteraciones y cada iteración sigue el modelo en cascada pasando por las distintas disciplinas. Cada iteración termina con una liberación del producto. Principio de desarrollo:  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


134

ANÁLISIS Y DISEÑO DE SISTEMAS 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 participantes pueden ser diferentes, contradictorios o disputarse recursos limitados. Debe encontrarse un balance que satisfaga los deseos de todos.  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 4GL1 o marcos de referencia (frameworks) por nombrar algunos. Esto evita que los ingenieros de software vayan directamente de los requisitos a la codificación de software a la medida del cliente, sin saber con certeza qué codificar para satisfacer de la mejor manera los requerimientos y sin comenzar desde un principio pensando en la reutilización del código. Un alto nivel de abstracción también permite discusiones sobre diversos niveles y soluciones arquitectónicas. Éstas se pueden acompañar por las representaciones visuales de la arquitectura, por ejemplo con el lenguaje UML.  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 de RUP. El ciclo de vida RUP es una implementación del Desarrollo en espiral. El ciclo de vida organiza las tareas en fases e iteraciones.


135


Deterninar Objetivos

Analisis de Riesgo

Planificación

Desarrollo y Probar

Fases RUP. La metodología RUP, llamada así por sus siglas en inglés Rational Unified Process, divide en 4 fases el desarrollo del software. Cada Fase tiene definido un conjunto de objetivos y un punto de control específico. Fase

Objetivos Definir el alcance del proyecto

Inicio

Elaboración

Construcción

Puntos de Control Objetivo del proyecto

Entender que se va a construir Construir una versión ejecutable de la arquitectura de la aplicación

Arquitectura Aplicación

de

la

Entender cómo se va a construir

Completar el esqueleto de la Aplicación con la funcionalidad

Versión Operativa Inicial de la Aplicación

Construir una versión Beta Transición

Poner a disposición la aplicación para los usuarios finales

Liberación de la versión de la Aplicación

Construir la versión Final


136

ANÁLISIS Y DISEÑO DE SISTEMAS Cada una de estas etapas es desarrollada mediante el ciclo de iteraciones, la cual consiste en reproducir el ciclo de vida en cascada a menor escala. Los Objetivos de una iteración se establecen en función de la evaluación de las iteraciones precedentes.  Fase de Inicio: Durante la fase reinicio se desarrolla una descripción del producto final, y se presenta el análisis del negocio. Esta fase responde las siguientes preguntas: ¿Cuáles son las principales funciones del sistema para los usuarios más importantes? ¿Cuáles podría ser la mejor arquitectura del sistema? En estas fases se identifican y priorizan los riesgos más importantes. Artefactos que típicamente sobreviven en esta fase. Un enunciado de los mayores requerimientos planteados generalmente como casos de uso.


137


5 4 3 2 1

Boceto inicial de la arquitectura

Descripción de los objetivos del proyecto

Versión preliminar del plan del proyecto.

Caso de negocio y alcance de proyecto

Modelo de negocio

10

9 8 7 6 Plan de proyecto

Modelo inicial de casos de uso

Identificación inicial de riesgos

Uno o más prototipos

Documento de visión general

SE ESTABLECE EL ALCANCE Y LA ESTIMACIÓN DE TIEMPO Y COSTO.  Fase de elaboración: Durante la fase de elaboración se especifican en detalle la mayoría de los casos de uso del producto y se diseña la arquitectura. Las iteraciones en la fase de elaboración. Establecen una firme compresión del problema a solucionar. Establece la fundación arquitectural para el software. Establece un plan detallado para las siguientes iteraciones. Elimina los mayores riesgos. El resultado de esta fase es la línea base de la arquitectura. En esta fase se construyen típicamente los siguientes artefactos. ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

138


5 4 3 2 1

Prototipo arquitectural

Casos de prueba.

casos de uso que describen la funcionalidad del sistema.

Analizar el dominio del problema

Eliminar los elementos de mayor riesgo

10

9 8 7 6

Se realizan pruebas de riesgos.

Analizar el dominio del problema .

Eliminar los elementos de mayor riesgo

Marca de Arquitectura.

Se realizan pruebas de riesgos

Un plan detallado para las siguientes iteraciones: La fase de elaboración finaliza con el hito de la arquitectura del ciclo de vida, este hito se alcanza cuando el equipo de desarrollo y los stakeholders llegan a un acuerdo sobre: Los casos de uso que describen la funcionalidad del sistema. La línea base de la arquitectura. Los mayores riesgos han sido mitigados. El plan de proyecto.

 Fase de construcción: Durante la fase de construcción se crea el producto. La línea base de la arquitectura crece hasta convertirse en el sistema completo


139

ANÁLISIS Y DISEÑO DE SISTEMAS Al final de esta fase, el producto contiene todos los casos de uso implementados, sin embargo puede que no esté libre de defectos Los artefactos producidos en esta fase son:

1

El sistema software

4

Los componente s se desarrollan e incorporan al producto

2

Los casos de prueba 5

Todo es probado para eliminar posibles errores y riesgos

3

Los manuales de usuario 6

Marca de Capacidad.

Se obtiene un producto Beta que debe ser puesto en ejecución para que los usuarios den retroalimentación. La fase de construcción finaliza con el hito de capacidad operativa inicial, este hito se alcanza cuando el equipo de desarrollo y los stakeholders llagan a un acuerdo sobre: El producto es estable para ser usado. El producto provee alguna funcionalidad de valor. Todas las partes están listas para comenzar la transición.  Fase de transición. La fase de transición cubre el período durante el cual el producto se convierte en la versión beta. Sin embargo, las características se agregan a un sistema que el usuario se encuentra utilizando activamente (ambiente de desarrollo). Los artefactos construidos en esta fase son el mismo que en la fase de construcción. El equipo se encuentra ocupando fundamentalmente en corregir y extender la funcionalidad del sistema desarrollado en la fase anterior.


140

ANÁLISIS Y DISEÑO DE SISTEMAS El objetivo es realizar el lanzamiento del software desarrollado a los usuarios. Pruebas Beta para validar el producto con la retroalimentación del usuario. Conversión de bases de datos. Enviar el producto a otros lados donde también se va a usar el producto. Marca de Producto. Usuarios satisfechos. Verificación de gastos. La fase de transición finaliza con el hito de lanzamiento del producto.

Elementos de rup.  Actividades, Son los procesos que se llegan a determinar en cada iteración.  Trabajadores, Vienen hacer las personas o entes involucrados en cada proceso.  Artefactos, Un artefacto puede ser un documento, un modelo, o un elemento de modelo.  Disciplinas primarias y secundarias o de apoyo: Una disciplina es una colección de actividades relacionadas con un área de atención dentro de todo el proyecto. Actividad: Los trabajadores realizan actividades. Una actividad es algo que se realiza para proveer un resultado de valor en el contexto de un proyecto. Trabajador (ROL): Un trabajador o rol, define un comportamiento o responsabilidades de un individuo o grupo de individuos trabajando en equipo, en el contexto de una organización de ingeniería de software. Sugerencias para identificar adecuadamente los trabajadores del negocio: Son roles (Humanos, software o hardware) no personas con nombres propios. Se encuentran dentro de las fronteras del negocio o campo de acción. No deben representar áreas, departamentos o parte de una organización sino roles de ejecución. Cada trabajador debe participar en al menos un caso de uso del negocio. Si no participa en ningún proceso debe ser eliminado del modelo.


141

ANÁLISIS Y DISEÑO DE SISTEMAS Artefactos: Las actividades tienen artefactos de entrada y de salida, un artefacto es un producto de trabajo de un proceso: los trabajadores utilizan artefactos para realizar actividades y producen artefactos como resultado de sus actividades. Los artefactos son responsabilidad de un único trabajador y promueven la idea de que toda pieza de información en el proceso debe ser responsabilidad de un rol especifico, un trabajador es el propietario de un artefacto, pero otros trabajadores pueden usarlo y tal vez modificarlo si tienen permisos para ello. Actividades Primarias y secundarias o de (apoyo): Una disciplina es una colección de actividades relacionadas con un área de atención dentro de todo el proyecto. El grupo de actividades que se encuentran dentro de una disciplina principalmente son una ayuda para entender el proyecto desde la perspectiva clásica de cascada. Las disciplinas son:

Modelado de Negocios,

Requerimientos,

Análisis y Diseño,

Implementación,

Pruebas, Transición,

Actividades de poyo y Diseño,

Configuración y Administración del Cambio,

Administración de Proyectos y Ambiente.

,


142

ANÁLISIS Y DISEÑO DE SISTEMAS TAREA 07: IMPLEMENTAR COLABORACIÓN.

DIAGRAMAS

DE

SECUENCIAS

Y

En esta tarea trataremos las siguientes operaciones:  Reconocer los requisitos para el diagrama de secuencia y colaboración.  Identificar la representación gráfica de los elementos.


   


OPERACIONES: DIAGRAMA DE SECUENCIA EN ArgoUML. 1. Ingrese a la aplicación ArgoUML. 2. Haga clic en la derecho opción Modelo sin título ubicado en el panel de navegación (lado izquierdo), luego elija la opción Crear elemento del modelo y por ultimo Crear Paquete.

3. Ingrese el nombre Sistemas en el área de propiedades, ubicado en la parte inferior (Como lo muestra la imagen). ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

143


4. Haga clic en la derecho opción paquete Sistemas ubicado en el panel de navegación (lado izquierdo), luego elija la opción Crear elemento del modelo y por ultimo Actor Nuevo. 5. Ingrese el nombre Cliente en el área de propiedades, ubicado en la parte inferior. 6. Repita la acción e ingrese los siguientes elementos: Sitio Web de Ventas, DNCustomer Server, DNKitchenServer, Autorización de Pago. 7. Haga clic en la derecho opción paquete Sistemas y luego elija la opción Crear diagrama y por ultimo Diagrama de secuencia.

8. Ingrese el siguiente nombre para el diagrama “Ecommerce” en el área de propiedades, ubicado en la parte inferior. 9. Elija el elemento cliente y realice un arrastre hacia el área de diseño.


144


10. Repita la acción, elija los elementos Sitio Web de Ventas, DNCustomer Server, DNKitchen Server, Autorización de Pago y agregarlos al área de diseño.

11. Elija el siguiente botón.

Y realice el arrastre del acto “Cliente” hacia “Sitio Web de Ventas”. Luego haga doble clic en la línea e ingrese el texto “Agregar elemento del carro de compra”. 12. Repetir la acción hasta que el diseño quede de la siguiente manera.


145


DIAGRAMA DE COLABORACIÓN EN StarUML. 1. Ingrese a la aplicación StarUML. 2. Haga clic derecho en la opción UseCaseModel y luego en la opción Add Diagram y por último en Collaboration Diagram.

3. Haga clic en el botón objetc y haga clic en el área de diseño.


146


Seleccione el botón Link y realice un arrastre desde el objeto Formulario hacia Lista de Candidato.

4. Haga doble clic en la línea recién insertada e ingrese el nombre “Buscar Candidato”. 5. Realizar el diagrama hasta que termine de la siguiente forma:


147

ANÁLISIS Y DISEÑO DE SISTEMAS FUNDAMENTO TEÓRICO. Diagrama de Secuencia. Este diagrama muestra la interacción de los objetos entre ellos. Es importante comentar que hasta este momento no se han considerado objetos técnicos. En UML, durante el Análisis de los requerimientos y el Análisis, no se consideran objetos técnicos que definan detalles y soluciones en el sistema de software, tales como objetos para interfaces de usuario, bases de datos, comunicaciones, etc. Todos esos objetos se consideran hasta el diseño del sistema. En este diagrama se observa que sólo se consideran algunos objetos y es importante aclarar que estos no serán todos los objetos a considerar dentro del sistema, ya que todavía es posible agregar nuevos objetos que no se habían considerado en el dominio del análisis así como los objetos técnicos, como se mencionó anteriormente. Los objetos considerados se representan en rectángulos con el nombre subrayado y cada uno cuenta con su línea de vida vertical que muestra la vida del objeto. Diagrama de colaboración. Así mismo, se cuenta con el diagrama de colaboración se centra tanto en las interacciones y las ligas entre un conjunto de objetos colaborando entre ellos (una liga es una instancia de una asociación). Ambos, el diagrama de secuencia y el diagrama de colaboración, muestran interacciones, pero el diagrama de secuencia se centra en el tiempo mientras que el diagrama de colaboración se centra en el espacio. Las ligas muestran los objetos actuales y cómo ellos se relacionan unos con otros. Así como los diagramas de secuencia, los diagramas de colaboración pueden ser utilizados para ilustrar la ejecución de una operación, una ejecución de un use-case o simplemente un escenario de interacción dentro del sistema. En este diagrama también se representa a los objetos en cajas rectangulares y con el nombre subrayado. Las ligas se dibujan con líneas y se puede agregar una etiqueta para un mensaje y un número que define la secuencia de las ligas.


148

ANÁLISIS Y DISEÑO DE SISTEMAS TAREA 08: IMPLEMENTAR DIAGRAMAS DE CLASE Y OBJETOS, ESTADOS Y ACTIVIDAD.

En esta tarea trataremos las siguientes operaciones:  Realizar la representación gráfica.  Identificar el comportamiento, relaciones entre las clases y los casos particulares. EQUIPOS Y MATERIALES:

   


OPERACIONES.

DIAGRAMA DE CLASE EN ArgoUML. 1. Ingrese a la aplicación ArgoUML. 2. Haga clic en la opción Modelo sin título ubicado en el panel de navegación (lado izquierdo), de esta forma se ingresara un nuevo nombre para el proyecto. 3. Ingrese el nombre Publicaciones en el área de propiedades, ubicado en la parte inferior (Como lo muestra la imagen). 4. Active la visibilidad Pública.

Ingresar

los

datos

correspondientes.

5. Haga clic en el icono de Diagrama de Clase.


149


6. Ingrese el nombre para el nuevo diagrama, para la práctica será Diagrama de Clases.

7. Haga clic en el botón Clase Nueva.

8. Haga un clic en el Panel de Edición para agregar el objeto seleccionado.

Clase Agregada

9. Teniendo seleccionada la clase, se podrá agregar un nombre. En el área de propiedades, en la sección nombre, ingrese el texto Publicación.


150


10. Elija el botón Atributo nuevo.

11. Teniendo agregado el atributo, se podrá agregar un nombre. En el área de propiedades, en la sección nombre, ingrese el texto Editor. 12. En la opción Tipo, selección String.


151

ANÁLISIS Y DISEÑO DE SISTEMAS 13. Haga clic en el botón Atributo nuevo. 14. Teniendo agregado el atributo, se podrá agregar un nombre. En el área de propiedades, en la sección nombre, ingrese el texto Fecha. 15. En la opción Tipo, seleccione String.

16. Agregar una operación, para ello haga clic en el botón Agregar operación.

17. En el campo nombre Ingresar el texto Publicación, que terminara siendo el constructor por defecto.

18. Se repite la acción de agregar una operación, para ello haga clic en el botón Agregar operación. 19. En el campo nombre Ingresar el texto Publicación. 20. Haga clic en el botón + de Parámetro, para agregar uno. Y seleccione la opción Agregar parámetro.


152


21. En el campo nombre Ingresar el texto Editor. 22. En la opción Tipo, seleccione String.

23. Se repite la acción de agregar un nuevo parámetro, para ello haga clic en el botón Agregar parámetro. 24. En el campo nombre Ingresar el texto Fecha. 25. En la opción Tipo, seleccione String. 26. Se repite la acción de agregar una operación, para ello haga clic en el botón Agregar operación. 27. Se proceder agregar los getters y setters.

Los Setters & Getters son métodos de acceso lo que indica que son siempre declarados públicos.

 Setters: Sirve para asignar un valor inicial a un atributo, pero de forma explícita, además el Setter nunca retorna nada, y solo permite dar acceso público a ciertos atributos que se desea, además el usuario pueda modificar.


153

ANÁLISIS Y DISEÑO DE SISTEMAS  Getters: sirve para obtener (recuperar o acceder) el valor ya asignado a un atributo y utilizarlo para cierto método. 28. En el campo nombre Ingresar el texto getEditor y luego especifique que tipo de datos devolverá, para el ejemplo. Haga doble clic en return y luego seleccione el tipo de datos String. 29. Haga clic en el botón retornar.

30. Haga clic en el botón Agregar operación y en el campo nombre Ingresar el texto getFeha y luego especifique que tipo de datos devolverá, para el ejemplo. Haga doble clic en return y luego seleccione el tipo de datos String. 31. Haga clic en el botón retornar y luego en el botón Agregar operación. 32. En el campo nombre ingrese el texto setEditor y luego haga clic en el botón Agregar parámetro. 33. En el campo nombre Ingresar el texto Editor y seleccione el tipo de datos String. 34. Haga clic en el botón retornar y luego en el botón Agregar operación. 35. En el campo nombre ingrese el texto setFecha y luego haga clic en el botón Agregar parámetro. 36. En el campo nombre Ingresar el texto Fecha y seleccione el tipo de datos String.


154

ANÁLISIS Y DISEÑO DE SISTEMAS CREAR UNA NUEVA CLASE CON EL NOMBRE LIBRO. 1. Haga clic en el botón Clase Nueva.

2. Haga un clic en el Panel de Edición para agregar el objeto seleccionado. 3. Ingrese el nombre Libro en el área de propiedades, ubicado en la parte inferior (Como lo muestra la imagen). 4. Active la visibilidad Pública.

Ingresar

los

datos

correspondientes.


6. Teniendo agregado el atributo, se podrá agregar un nombre. En el área de propiedades, en la sección nombre, ingrese el texto ISBN. 7. En la opción Tipo, selección String. 8. En el campo de Visibilidad, active la opción privado.

9. Haga clic en el botón Atributo nuevo.


155

ANÁLISIS Y DISEÑO DE SISTEMAS 10. Teniendo agregado el atributo, se podrá agregar un nombre. En el área de propiedades, en la sección nombre, ingrese el texto autor. 11. En la opción Tipo, seleccione String. 12. En el campo de Visibilidad, active la opción privado. 13. Haga clic en el botón Agregar operación y en el campo nombre Ingresar el texto Libro. 14. Repita la acción de Agregar operación y en el campo nombre Ingresar el texto Libro (una vez más). 15. Haga clic en el botón + de Parámetro, para agregar uno. Y seleccione la opción Agregar parámetro.

16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38.

En el campo nombre Ingresar el texto ISBN. En la opción Tipo, seleccione String. Repita la acción para agregar un nuevo parámetro. En el campo nombre Ingresar el texto Autor. En la opción Tipo, seleccione String. Haga clic en el botón retornar y luego en el botón Agregar operación. En el campo nombre ingrese el texto getISBN. Haga doble clic en la opción return. En la opción Tipo, seleccione String. Haga clic en el botón retornar y luego en el botón Agregar operación. En el campo nombre ingrese el texto getAutor. Haga doble clic en la opción return. En la opción Tipo, seleccione String. Haga clic en el botón retornar y luego en el botón Agregar operación. En el campo nombre ingrese el texto setISBN. Haga clic en el botón + de Parámetro, para agregar uno. Y seleccione la opción Agregar parámetro. En el campo nombre ingrese el texto ISBN. En la opción Tipo, seleccione String. Haga clic en el botón retornar y luego en el botón Agregar operación. En el campo nombre ingrese el texto setAutor. Haga clic en el botón + de Parámetro, para agregar uno. Y seleccione la opción Agregar parámetro. En el campo nombre ingrese el texto Autor. En la opción Tipo, seleccione String.


156

ANÁLISIS Y DISEÑO DE SISTEMAS CREAR UNA NUEVA CLASE CON EL NOMBRE LIBRO. 1. Haga clic en el botón Clase Nueva.

2. Haga un clic en el Panel de Edición para agregar el objeto seleccionado. 3. Ingrese el nombre Revista en el área de propiedades, ubicado en la parte inferior (Como lo muestra la imagen). 4. Active la visibilidad Pública.

Ingresar

los

datos

correspondientes.


6. Teniendo agregado el atributo, se podrá agregar un nombre. En el área de propiedades, en la sección nombre, ingrese el texto NumerosporAño. 7. En la opción Tipo, selección Integer. 8. En el campo de Visibilidad, active la opción privado.

9. Haga clic en el botón Atributo nuevo. 10. Teniendo agregado el atributo, se podrá agregar un nombre. En el área de propiedades, en la sección nombre, ingrese el texto NumerosVentasAño.


157

ANÁLISIS Y DISEÑO DE SISTEMAS 11. En la opción Tipo, seleccione Integer. 12. En el campo de Visibilidad, active la opción privado. 13. Haga clic en el botón Agregar operación y en el campo nombre Ingresar el texto Revista. 14. Repita la acción de Agregar operación y en el campo nombre Ingresar el texto Revista (una vez más). 15. Haga clic en el botón + de Parámetro, para agregar uno. Y seleccione la opción Agregar parámetro.

16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38.

En el campo nombre Ingresar el texto NumerosporAño. En la opción Tipo, seleccione Integer. Repita la acción para agregar un nuevo parámetro. En el campo nombre Ingresar el texto NumerosVentasAño. En la opción Tipo, seleccione Integer. Haga clic en el botón retornar y luego en el botón Agregar operación. En el campo nombre ingrese el texto getNumerosporAño. Haga doble clic en la opción return. En la opción Tipo, seleccione Integer. Haga clic en el botón retornar y luego en el botón Agregar operación. En el campo nombre ingrese el texto getNumerosVentasAño. Haga doble clic en la opción return. En la opción Tipo, seleccione Integer. Haga clic en el botón retornar y luego en el botón Agregar operación. En el campo nombre ingrese el texto setNumerosporAño. Haga clic en el botón + de Parámetro, para agregar uno. Y seleccione la opción Agregar parámetro. En el campo nombre ingrese el texto NumerosporAño. En la opción Tipo, seleccione Integer. Haga clic en el botón retornar y luego en el botón Agregar operación. En el campo nombre ingrese el texto setNumerosVentasAño. Haga clic en el botón + de Parámetro, para agregar uno. Y seleccione la opción Agregar parámetro. En el campo nombre ingrese el texto NumerosVentasAño. En la opción Tipo, seleccione Integer.


158

ANÁLISIS Y DISEÑO DE SISTEMAS CREAR LAS RELACIONES ENTRE LAS DISTINTAS CLASES.

1. Haga clic en el botón Crear Generalización.

2. Haga un clic sostenido desde la clase Libro y arrastre hasta la clase Publicación, quedando de la siguiente forma.

3. Mantener la selección activa y en el área de propiedades ingrese un nombre e identificador a la relación.


159

ANÁLISIS Y DISEÑO DE SISTEMAS 4. Haga clic en el botón Crear Generalización. 5. Haga un clic sostenido desde la clase Revista y arrastre hasta la clase Publicación, quedando de la siguiente forma.

6. Mantener la selección activa y en el área de propiedades ingrese un nombre e identificador a la relación.

7. Haga clic en el menú Archivo y luego en la opción Guardar Proyecto. GENERAR EL CÓDIGO JAVA DE LA CLASE. 1. Haga clic en el botón seleccionar y con dicha herramienta genere el arrastre para seleccionar todas las clases.

2. Elija el menú Generar y luego la opción Generar clases escogidas. 3. Activar las opciones de Java.


160


Haga clic en Buscar y luego seleccionar la opción Desktop.

4. Haga clic en Generar. DIAGRAMA DE ESTADO EN RATIONAL ROSE. Es empleado para diagramar los estados por los cuales pasara el sistema, también muestra lo que podría suceder después de un determinado evento. 1. Ingrese a la aplicación Rational Rose. 2. En la primera pantalla haga clic en el botón Cancel. La primera pantalla tiene la típica estructura de una venta de Microsoft Windows. 3. Ubicar el cursos de mouse en el área de navegación y haga clic derecho en la opción Logical View y luego en new. 4. Haga clic en la opción Statechart Diagram.

Haga clic en la opción Statechart Diagram.

5. Ingrese el nombre para el diagrama; “Ejemplo de diagrama de estados”, luego haga clic en el botón Start State para iniciar el diagrama.


161


Haga clic en el botón Start State.

6. Elija el botón State e ingrese el texto “descolgar sin marcar”.

7. Haga clic derecho en el state ingresado hace unos instantes y luego seleccionar la opción Open Specification. 8. Elija la pestaña Action y en el espacio en blanco, haga clic en Insert, se podrá observar que se ha agregado el texto Entry, en resumen esto quiere decir que es una acción de entrada.

9. Haga clic derecho en el texto Entry y seleccione la opción Specification. 10. En el campo Name ingrese el texto Sonar_tono_de_llamada y luego haga clic en Ok. 11. Haga clic en el botón State Transition y realice un clic sostenido desde el objeto start state hacia el state descolgar sin marcar. Esto quiere decir que se tiene un estado iniciar con una acción de entrada. 12. Elija el botón State e ingrese el texto “Marcar”.


162

ANÁLISIS Y DISEÑO DE SISTEMAS 13. Haga clic derecho en el state ingresado hace unos instantes y luego seleccionar la opción Open Specification. 14. Elija la pestaña Action y en el espacio en blanco, haga clic en Insert, se podrá observar que se ha agregado el texto Entry, en resumen esto quiere decir que es una acción de entrada. 15. Haga clic derecho en el texto Entry y seleccione la opción Specification. 16. En el campo When seleccione la opción On Entry y luego en el campo name ingrese el texto Añadir_digito(0) 17. Haga clic en Apply y luego en Ok. 18. Haga clic en el botón State Transition y realice un clic sostenido desde el objeto Descolgar sin marcar hacia el state Marcar. 19. Elija el botón text box y haga clic en la línea de transition. 20. Ingrese en el campo Event el texto digito() 21. Haga clic en el botón End State y ubicarlo encima del state Marcar. 22. Haga clic en el botón State Transition y realice un clic sostenido desde el objeto Marcar hacia el state End. 23. Elija el botón text box y haga clic al costado de la línea de transition e ingresar el texto Numero.Es_Valido. DIAGRAMA DE ACTIVIDAD EN RATIONAL ROSE. En un diagrama de actividades se muestra un proceso de negocio o un proceso de software como un flujo de trabajo a través de una serie de acciones. Estas acciones las pueden llevar a cabo personas, componentes de software o equipos. 1. Ingrese a la aplicación Rational Rose. 2. En la primera pantalla haga clic en el botón Cancel. La primera pantalla tiene la típica estructura de una venta de Microsoft Windows. 3. Ubicar el cursos de mouse en el área de navegación y haga clic derecho en la opción Logical View y luego en new. 4. Haga clic en la opción Activity Diagram.

Haga clic en la opción Activity Diagram.


163

ANÁLISIS Y DISEÑO DE SISTEMAS 5. Ingrese el nombre para el diagrama; “Ejemplo de diagrama de actividad”, luego haga clic en el botón Start State para iniciar el diagrama.

Haga clic en el botón Start State.

6. Elija el botón Activity e ingrese el texto “Pedir Contraseña”.

Ingrese el texto “Pedir Contraseña

7. Haga clic en el botón Activity e ingrese el texto “Permitir acceso”. 8. Elija el botón Decisión y dibuje la figura entro las dos actividades agregadas recientemente. 9. Haga clic en el botón End State y ubicarlo por debajo de la actividad “Permitir acceso”.

Botón Decisión


164

ANÁLISIS Y DISEÑO DE SISTEMAS 10. Haga clic en el botón State transition y realizar el arrastre sostenido desde el objeto Start State hacia la actividad “Pedir contraseña”. 11. Elije el botón State transition y realizar el arrastre sostenido desde el objeto actividad “Pedir contraseña” hacia el objeto decisión. 12. Haga clic en el botón State transition y realizar el arrastre sostenido desde el objeto decisión hacia la actividad “Permitir acceso”. 13. Elije el botón State transition y realizar el arrastre sostenido desde el objeto actividad “Permitir acceso” hacia el objeto End state.

14. Elije el botón State transition y realizar el arrastre sostenido desde el objeto decisión hacia la actividad “Pedir contraseña”. 15. Haga clic en el medio de las flechas y realice un arrastre hacia la derecha. 16. Haga doble clic en la flecha creada recientemente y luego elija la ficha Detail. 17. En la opción Guard Gondition, ingrese el texto “Contraseña incorrecta”.

Ingrese el texto “Contraseña incorrecta”.

Haga clic en Apply y luego en la opción OK


165

ANÁLISIS Y DISEÑO DE SISTEMAS 18. Haga doble clic en la flecha que une el objeto decisión y la actividad “Permitir acceso” y luego elija la ficha Detail. 19. En la opción Guard Gondition, ingrese el texto “Contraseña correcta”.

FUNDAMENTO TEÓRICO: DIAGRAMAS DE CLASE Y OBJETOS, ESTADOS Y ACTIVIDAD. Los diagramas de estado tienen las características de exponer un conjunto de estados por los cuales pasa un objeto durante el tiempo que permita cumplir su función en la aplicación. Es común encontrar en el diagrama estados y transiciones. Como los estados y las transiciones incluyen, a su vez, eventos, acciones y actividades, vamos a ver primero sus definiciones. Por último es necesario recordar que el diagrama de estado como cualquier otro diagrama permite los comentarios. Los elementos que son propios del diagrama son:  Los eventos. Es la acción que genera una transición de un estado a otro.  Las acciones. Son reconocidas como una operación atómica, que no se puede interrumpir por un evento y que tiene la peculiaridad que se ejecuta hasta su finalización.  Estados. Cuando se trabajó con los estados es para por identificar una condición o una situación en la vida de un objeto En el caso de los diagramas de clase se podría decir que son la base del análisis y diseño orientado a objetos. Ya que dichos diagramas muestran las clases del sistema, sus interrelaciones (incluyendo herencia, agregación y ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

166

ANÁLISIS Y DISEÑO DE SISTEMAS asociación), y las operaciones y atributos de las clases. Los diagramas de clases se utilizan para una amplia variedad de propósitos, incluyendo tanto el modelado conceptual y el modelado de diseño. Los elementos que son propios del diagrama son:  Las Clases. Son objetos que pueden ser representados por personas, lugar, cosa, concepto, acontecimiento del monitor, o el informe correspondiente al sistema. También se tiene que tener en cuenta que estas clases tienen atributos y que originan los métodos. Esto quiere decir que una clase es una representación de un objeto y, en muchos sentidos, es simplemente una plantilla a partir de la cual se crean objetos. Las clases forman los bloques de construcción principales de una aplicación orientada a objetos.  Responsabilidades. Las clases se modelan normalmente como rectángulos con tres secciones: la sección superior para el nombre de la clase, la sección central de los atributos de la clase, y la sección inferior de los métodos de la clase. Los atributos son la información almacenada acerca de un objeto (o, al menos, información que se mantiene temporalmente sobre un objeto), mientras que los métodos son las cosas que un objeto o clase hacen. De formas más didáctica se podría decir que los estudiantes tienen un código de estudiantes, nombres, direcciones y números de teléfono, todo ello vendría hacer los atributos de un estudiante. Pero estos mismo estudiantes son los que terminar por inscribirse en determinados cursos o solicitar algún tipo de información académica, esto se conoce como método.  Asociaciones. Está relacionado a la asociación o relación que puede tener un objeto con otro objeto dentro del diseño. El Diagrama de actividad es empleado normalmente para el modelado de procesos de negocios, porque de esta forma permite capturar un solo caso de uso o escenario de uso, o para modelar la lógica detallada de una regla de negocio. Aunque los diagramas de actividad potencialmente podrían modelar la lógica interna de una operación compleja que sería mucho mejor simplemente reescribir la operación por lo que es bastante simple que no necesita un diagrama de actividades. En muchos sentidos, los diagramas de actividad son el equivalente a orientado a objetos de diagramas de flujo y diagramas de flujo de datos de desarrollo estructurado. Los elementos que son propios del diagrama son:  Nodo inicial. El llenado el círculo es el punto de partida del diagrama. Un nodo inicial no es necesaria, aunque sí lo hace mucho más fácil de leer el diagrama.


167

ANÁLISIS Y DISEÑO DE SISTEMAS  Actividad nodo final. El círculo lleno de una frontera es el punto final. Un diagrama de actividades puede tener cero o más nodos de actividad definitiva.  Actividad. Los rectángulos redondeados representan las actividades que ocurran. Una actividad puede ser física, como Inspeccione las formas, o electrónica, tales como pantalla Crear pantalla de estudiante.  Flujo o borde. Las flechas en el diagrama. Aunque hay una sutil diferencia entre los flujos y los bordes nunca he visto a un propósito práctico de la diferencia, aunque no tengo ninguna duda de que exista. Usaré el término flujo.  Tenedor. Una barra de color negro con un flujo de entrar en ella y varios de abandonarlo. Esto denota el comienzo de la actividad paralelo.  Unirse. Una barra de color negro con varios flujos de entrar en ella y uno de abandonarlo. Todos los flujos de entrar en la unión debe llegar a él antes de su procesamiento puede continuar. Esta denota el final del procesamiento paralelo.  Condición. Texto como [Forma incorrecta] en un flujo, la definición de un guardia que debe evaluar a verdadero para poder atravesar el nodo.  Decisión. Un diamante con un flujo que entra y varios de salir. Los flujos salientes incluyen condiciones aunque algunos modeladores no se indican las condiciones si es obvio.  Combinar. Un diamante con varios flujos de entrada y una salida. La implicación es que uno o más flujos de entrada deben llegar a este punto hasta que el proceso continúa.


168

ANÁLISIS Y DISEÑO DE SISTEMAS TAREA 09: IMPLEMENTAR INTERFACES Y DESPLIEGUE.

DIAGRAMAS

DE

COMPONENTES,

En esta tarea trataremos las siguientes operaciones:  Identificar los componentes en el diagrama.  Identificar los nodos en función de sus tipos y conexiones.


   


OPERACIONES: DIAGRAMA DE COMPONENTES EN Rational Rose. 1. Ingrese a la aplicación Rational Rose. 2. En la primera pantalla haga clic en el botón Cancel. La primera pantalla tiene la típica estructura de una venta de Microsoft Windows. 3. Ubicar el cursos de mouse en el área de navegación y haga clic derecho en la opción Component View y luego en new. 4. Haga clic en la opción Component Diagram.

Haga clic en la opción Component Diagram.

5. Ingrese el nombre para el diagrama; “Ejemplo de diagrama de componentes”, luego haga clic en el botón Componet para iniciar el diagrama e ingrese el nombre Cliente.


169


Ingrese el nombre Cliente para el Component.

6. Haga clic en el botón Componet para iniciar el diagrama e ingrese el nombre Servidor.

7. Haga clic en el botón Package e ingrese el nombre “Emisor”. Luego repetir la acción e ingrese un nuevo nombre “Receptor”

8. Haga clic en el botón Package e ingrese el nombre “Receptor”. Luego repetir la acción e ingrese un nuevo nombre “Work Thread” y por ultimo un package de Emisor.


170

ANÁLISIS Y DISEÑO DE SISTEMAS Si al crear Package repetidos la aplicación muestra un mensaje, haga clic en la opción No.

9. Haga clic en el botón Dependency y haga un clic sostenido desde el “Emisor” del Cliente hasta el “Receptor” del Servidor. 10. Elegir el botón Text Box y haga clic en la dependencia recién creada y agregue el texto Petición. 11. Haga clic en el botón Dependency y haga un clic sostenido desde el “Receptor” del Servidor hasta el “Work Thread” del Servidor. 12. Elige el botón Dependency y haga un clic sostenido desde el “Work Thread” del Servidor hasta el “Emisor” del Servidor. 13. Haga clic en el botón Dependency y haga un clic sostenido desde el “Emisor” del Servidor hasta el “Receptor” del Cliente. 14. Elegir el botón Text Box y haga clic en la dependencia recién creada y agregue el texto Respuesta.


171

ANÁLISIS Y DISEÑO DE SISTEMAS DIAGRAMA DE DESPLIEGUE EN StarUML. 1. Ingrese a la siguiente dirección web http://staruml.sourceforge.net/en/. 2. Haga clic en la opción Downloads.

3. Haga doble clic en el icono staruml-5.0-with-cm, para iniciar la instalación. 4. En la pantalla de bienvenida elegir el botón Next, luego acepte la licencia para la aplicación. 5. Haga doble clic en el acceso directo StarUML, para iniciar la aplicación. 6. Ubicar el cursos del mouse en el área de exploración de modelos y haga clic en el botón + de la opción DeploymentModel y luego doble clic en la opción Main.

Haga doble clic en la opción Main

7. En la barra de herramientas, haga clic en la herramienta Node y luego un clic en el área de diseño. 8. Ingrese el nombre computadora.


172

ANÁLISIS Y DISEÑO DE SISTEMAS 9. Repetir la acción de trabajar con la herramienta Node e ingresar el nombre de impresora, luego de ello insertar un node con el nombre router.

10. Haga clic en el botón Association y haga un clic sostenido desde el node “Router” hasta el node “Computadora”. Repita la acción del node Computadora hasta el node impresora.

FUNDAMENTO TEÓRICO: Diagrama de componentes. Dentro de esta etapa se crea el diagrama de componentes que describe componentes de software y sus dependencias con otros componentes, representando la estructura del código. Los componentes de software pueden ser: componentes de código, componentes binarios que son los generados por la compilación de los componentes de código y los componentes ejecutables. En este diagrama se pueden manejar paquetes, que son contenedores de clases utilizados para mantener el espacio de nombres de clases dividido en ESCUELA DE TECNOLOGÍAS DE LA INFORMACIÓN

173

ANÁLISIS Y DISEÑO DE SISTEMAS compartimentos, de manera que se utilizan para representar subsistemas del sistema en el mundo físico. Cada paquete se liga con otros a través de dependencias, que se representan con flechas de líneas discontinuas que van del componente dependiente al componente del cual depende. Cada paquete debe tener un diagrama de componentes para representar las clases que contiene internamente, similar a hacer un acercamiento o "zoom" al interior de cada uno de los paquetes. Los componentes de software se representan con un rectángulo que contiene dos pequeños rectángulos en su extremo izquierdo. Diagrama de despliegue. Los Diagramas de Despliegue muestran las relaciones físicas 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. Los nodos se interconectan mediante soportes bidireccionales que pueden a su vez estereotiparse. Esta vista permite determinar las consecuencias de la distribución y la asignación de recursos. Las instancias de los nodos pueden contener instancias de ejecución, como instancias de componentes y objetos. El modelo puede mostrar dependencias entre las instancias y sus interfaces, y también modelar la migración de entidades entre nodos u otros contenedores. Esta vista tiene una forma de descriptor y otra de instancia. La forma de instancia muestra la localización de las instancias de los componentes específicos en instancias específicas del nodo como parte de una configuración del sistema. La forma de descriptor muestra qué tipo de componentes pueden subsistir en qué tipos de nodos y qué tipo de nodos se pueden conectar, de forma similar a un diagrama de clases, esta forma es menos común que la primera


174

Analisis y Diseño de Sistem as - Senati

Recommend Documents