MANUAL DE APRENDIZAJE
CÓDIGO: 89001638
Profesional Técnico
ANÁLISIS Y DISEÑO DE
SISTEMAS
DESARROLLO DE
SOFTWARE
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.
4. Se muestra la pantalla de bienvenida, haga clic en el botón Siguiente. Haga clic en la opción Install
IBM Rational Rose Enterprise Edition.
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.
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. Haga clic en el botón Next.
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.
¿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.
Barra de Titulo. Barra de Menús.
Barra de Herramientas Estandar.
Área de Navegación. Área de Documentación. Barra de Herramientas de Diagramas Ventana de diagrama. Área de Registro.
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.
7. Elija el lugar de instalación y luego haga clic en siguiente. Activar los dos componentes.
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.
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.
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.
Haga doble clic en la opción Main.
¿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.
Haga clic en la opción New Project.
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.
Seleccione uno de la lista y haga clic en el botón OK.
Haga clic en la opción Import y luego en la opción Framework.
En el cuadro de diálogo Importar Framework, seleccione un marco para importar y haga clic en Ok.
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 Aparecerá el cuadro de diálogo Seleccionar elemento, para determinar qué elemento contendrá.
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.
• 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
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
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.
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.
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.
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.
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.
5. Haga doble clic en la entidad alumno, aparece la ventana de especificaciones para el actor alumno.
Una entidad es todo aquello que puede ser descrito por sus atributos.
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.
9. Elija el botón Use Case y haga clic en el área de diseño y por último ingrese el texto Estudia Software.
Ayuda o recordatorio para
10. Elija el botón Actor y haga clic en el área de diseño e ingrese el texto cliente.
11. Elija el botón Use Case y haga clic en el área de diseño y por último ingrese el texto Compra Producto.
12. Elija el botón Actor y haga clic en el área de diseño e ingrese el texto Cajero.
13. Elija el botón Use Case y haga clic en el área de diseño y por último ingrese el texto Registra Pedidos.
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.
Los Use Case son en su mayoría procedimientos generados por los actores.
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.
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.
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. Seleccione la opción es
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?
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.
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
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 Productos Técnicas y
Prácticas Participantes DSI Definición de Niveles de Arquitectura • Diseño de la Arquitectura del Sistema o
Aprisionamiento. Físico del Sistema de Información. • Diagrama de Representación- • Diagrama de Despliegue. • Equipo de Arquitectura. • Equipo de Soporte Técnico. • Equipo de Seguridad. DSI Identificación de Requisitos de Diseño y Construcción • Catálogo de Requisitos. • Sesiones de Trabajo. • Catalogación. • Equipo de Arquitectura. • Equipo de Soporte Técnico.
DSI Especificación de
Excepciones • Catálogo de Excepciones.
• Sesiones de Trabajo. • Catalogación.
• Equipo de Arquitectura. • Equipo de Soporte Técnico
DSI Especificación de Estándares y Normas de Diseño y Construcción • Catálogo de Normas • Sesiones de Trabajo. • Catalogación. • Equipo de Arquitectura. • Equipo de Soporte Técnico.
DSI
Identificación de Subsistemas de
Diseño
• Diseño de la Arquitectura del Sistema o Descripción de Subsistemas de Diseño • Matricial • Diagrama de Estructura • Diagrama de Inter-acción de Objetos. • Diagrama de Paquetes. • Diagrama de Despliegue • Equipo de Arquitectura. • Equipo de Soporte Técnico. • Equipo de Seguridad
DSI
Especificación del Entorno Tecnológico
• Entorno Tecnológico del Sistema: o Especificación del Entorno Tecnológico o Restricciones Técnicas o Estimación de Planifi-cación de Capacidades • Sesiones de Trabajo. • Diagrama de Representación • Equipo de Arquitectura. • Equipo de Soporte Técnico.
DSI Especificación de Requisitos de Operación y Seguridad • Procedimientos de Segu-ridad y Control de Acceso. • Procedimientos de
Operación y Adminis-tración del Sistema.
• Equipo de Seguridad. • Equipo de Arquitectura. • Equipo de Soporte Técnico
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:
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.
Gestores de datos.
Tipos de puesto cliente.
Tipos de dispositivos de impresión.
Monitores de teleproceso.
Servidores.
Comunicaciones.
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.
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
Productos. (Entrada) • Descripción General del Entorno Tecnológico del Sistema. • Catálogo de Requisitos. • Especificación de Interfaz de Usuario. 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. Técnicas • Diagrama de Despliegue. Prácticas. • Diagrama de Representación Participantes • Equipo de Arquitectura • Equipo de Soporte Técnico • Equipo de Seguridad
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.
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
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
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.
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) • Catálogo de Requisitos • Diseño de la Arquitectura del Sistema En Diseño Orientado a Objetos. • Modelo de Casos de Uso • Especificación de Casos de Uso. • De salida • Catálogo de Excepciones. Prácticas • Sesiones de Trabajo • Catalogación Participantes. • Equipo de Arquitectura • Equipo de Soporte Técnico 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
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 Gestión de transacciones Control y gestión de errores. Control y gestión de errores Seguridad y control de acceso. Gestión de interfaz. Interacción con los recursos propios del sistema.
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.
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
Productos. (Entrada) • Descripción General del Entorno Tecnológico del Sistema. • Diseño de la Arquitectura del Catálogo de Requisitos. En Diseño Estructurado • Matriz de Procesos / Localización. • Descripción de Interfaz con otros Sistemas. • Modelo de Procesos. En Diseño Orientado a Objetos • 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. Técnicas • Diagrama de Estructura • Matricial
• Diagrama de Interacción de Objetos • Diagrama de Paquetes
• Diagrama de Despliegue
Participantes • Equipo de Arquitectura • Equipo de Soporte Técnico • Equipo de Seguridad
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
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.
Prácticas • Sesiones de Trabajo
• Diagrama de Representación
Participantes • 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.
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.
Tarea Productos Técnicas y Prácticas Participantes DSI • Diseño de Subsistemas de Soporte • Diseño Detallado de los Subsistemas de Soporte. • Diagrama de Estructura. • Diagrama de Interacción de Objetos. • Diagrama de Clases • Equipo de Arquitectura. DSI • Identificación de Mecanismos Genéricos de Diseño • Mecanismos Genéricos de Diseño y Construcción. • Sesiones de Trabajo − Diagrama de Interacción de Objetos. • Diagrama de Clases • 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.
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. Diseño Detallado de los Subsistemas de Soporte. Técnicas Diagrama de Estructura Diagrama de Interacción de Objetos Diagrama de Clases Participantes Equipo de Arquitectura. 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 Sesiones de Trabajo Participantes Equipo de Arquitectura
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 Productos Técnicas y Prácticas Participantes DSI
Identificación de Clases Asociadas a
un Caso de Uso
• Diseño de la Realización de los Casos de Uso o Especificación Detallada. • Diagrama de Interacción de Objetos • Equipo del Proyecto. DSI Diseño de la Realización de los Casos de Uso
• Diseño de la Realización de los Casos de Uso o Especificación Detallada. • Diagrama de Interacción de Objetos. • Equipo del Proyecto. DSI Revisión de la Interfaz de Usuario
• Diseño de Interfaz de Usuario: o Formatos Individuales de Interfaz de Pantalla Gráfica o Catálogo de Controles y • Catalogación Diagrama de Transición de Estados Diagrama • Equipo del Proyecto. • Usuarios Expertos
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 o Prototipo de Interfaz de Pantalla Gráfica de Interacción de Objetos. • Prototipado DSI Revisión de Subsistemas de Diseño e Interfaces
• 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. • 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.
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
Productos. (Entrada) •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 Técnicas. •Diagrama de Interacción de Objetos Participantes •Equipo de Proyecto
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.
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.
Productos. (Entrada) •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. Técnicas. •Diagrama de interacción de objetos (colaboración o secuencia). Participantes •Equipo de proyecto.