Apuntes_SIG_OO_UML

Tema IX. Metodología Orientada a Objetos para el Desarrollo de Sistemas de Información...........................

2
1. Objetivos del Desarrollo de Sistemas de Información................................................................................................. 2 2. Estructura de la metodología ....................................................................................................................................... 3 3. Fundamentos del modelo Orientado a Objetos ............................................................................................................ 3 Modelado en el Análisis y Diseño Orientado a Objetos............................................................................................... 3 Conceptos Básicos ....................................................................................................................................................... 3 3.1 Objetos ................................................................................................................................................................... 3 3.1.1 Tipo de Objeto y Clase........................................................................................................................................ 4 3.2 Encapsulado .......................................................................................................................................................... 5 i. Interfaz ................................................................................................................................................................ 5 ii. Generalización, Especialización y Herencia ................................................................................................... 6 iii. Polimorfismo y Ligadura Dinámica................................................................................................................ 7 Razones de Enfoque Orientado a Objetos .................................................................................................................... 8 3.2.1 Elementos Claves en el Desarrollo de Sistemas de Información........................................................................10 Diagramas: Las Herramientas de UML.......................................................................................................................12 5.1 Diagramas de Casos de Uso ..................................................................................................................................13 Casos de Uso y Actores ..........................................................................................................................................13 Organización de los Casos de Uso..........................................................................................................................14 Pasos para la Construcción de un Diagrama de Casos de Uso................................................................................19 5.2. Diagramas de Clases ............................................................................................................................................19 5.2.1 Clases............................................................................................................................................................20 5.2.2 Relaciones......................................................................................................................................................21 5.2.3 Pasos para la Construcción de un Diagrama de Clases ..................................................................................29 5.4 Diagrama de Secuencia....................................................................................................................................42 5.5 Diagrama de Colaboración ..............................................................................................................................44 Equivalencia Semántica..........................................................................................................................................46

6. El Proceso Unificado de Desarrollo ..................................................................................................... 47 7. Las Cuatro “P” del Proceso Unificado de Desarrollo........................................................................... 49 Personas................................................................................................................................................ 49 Proyectos .............................................................................................................................................. 50 Producto ............................................................................................................................................... 50 Proceso ................................................................................................................................................. 51 7.1 El Proceso Unificado Dirigido por Casos de Uso .............................................................................. 51 La Captura de los Casos de Uso ........................................................................................................... 52 Análisis, Diseño e Implementación para Realizar los Casos de Uso.................................................... 52 Prueba de los Casos de Uso.................................................................................................................. 53 7.2 El Proceso Unificado Centrado en la Arquitectura ............................................................................ 54 7.3 El Proceso Unificado Iterativo e Incremental..................................................................................... 55 Anexo: Transformación de Diagrama de Clases a Modelo Relacional ............................................................ 57 1. Obtención del Modelo Conceptual a partir del Diagrama de Clases........................................................ 57 Modelos de Bases de Datos Relacionales para Sistemas de Información ........................................................ 59 1. Tecnologías Web para el Desarrollo de Sistemas de Información ........................................................... 64 1.1. Lenguaje de Hipertexto Basado en Marcas (HTML) ....................................................................... 64 1.1.1. Páginas Estáticas y Dinámicas.................................................................................................. 65 1.1.2. Herramientas para la Construcción de Páginas Web ................................................................ 65 1.2. Lenguaje de Marcas Extensibles (XML).......................................................................................... 67 1.3. Herramientas para Páginas Web Personales (PHP).......................................................................... 69 1.4. MySQL............................................................................................................................................. 70 1.5. Java................................................................................................................................................... 70 2. Aplicación de UML en el Modelado de un Sistema de Información de Gestión del Recurso Humano... 72 2.1. Contexto de la Situación................................................................................................................... 72 2.2. Modelo de Proceso de Negocios ...................................................................................................... 73 2.3. Análisis y Diseño Orientado a Objetos: Modelado con UML.......................................................... 78 2.3.1. Desarrollo del Diagrama de Casos de Uso ............................................................................... 79

Profesor. Oscar Saavedra Rodríguez

1

Tema IX. Metodología Orientada a Objetos para el Desarrollo de Sistemas de Información.
1. Objetivos del Desarrollo de Sistemas de Información A medida que crece el volumen de información a manejar en una Organización, aumenta la necesidad de disponer de una Tecnología de la Información que soporte dinámica y eficazmente el funcionamiento normal de los distintos departamentos que la constituyen. Dicho soporte ha de ser dinámico en el sentido de que debe adaptarse con facilidad a las condiciones, externas e internas, cambiantes de la Organización. Por otra parte, ha de ser eficaz y atenerse estrictamente a las necesidades del usuario. Para ello la comunicación entre las Unidades usuarias y la de Tecnología de la Información es un factor vital y determinante. La problemática de los Departamentos de Tecnología de la Información que no utilizan ninguna metodología de desarrollo, se puede resumir así: • escasa o nula documentación de los sistemas, lo que dificulta las tareas de desarrollo, implantación y especialmente la de mantenimiento. • falta de comunicación con los usuarios, lo que genera productos no entregados a tiempo y que, además, no responden totalmente a las necesidades de los usuarios. Se justifica, por tanto, la implantación de una Metodología de Desarrollo de Sistemas en una Organización, en la que se defina un conjunto de métodos, procedimientos, técnicas y herramientas que faciliten la construcción de Sistemas de Información, con el fin de: • satisfacer todas las necesidades de los departamentos usuarios implicados. • generar la documentación asociada, la cual comprende instrucciones de operación, documentación del mantenimiento y la explotación, etc.. El principal objetivo de la metodología es crear un entorno que permita al equipo de trabajo construir Sistemas, que: • den solución a los objetivos considerados prioritarios en la Organización. • se desarrollen cuando el usuario los necesite y de acuerdo con los presupuestos y duración estimados. • se mantengan fácilmente para soportar los cambios futuros de la Organización. Todo ello utilizando un vocabulario común y un conjunto completo de tareas y productos finales que ayuden a construir con éxito Sistemas de Información. Esta metodología es una guía formal, aunque flexible en su utilización, para el Diseño y Construcción de Sistemas de Información empleando conceptos y técnicas de Ingeniería de Sistemas de Información y Tecnología de la Información.

Profesor. Oscar Saavedra Rodríguez

2

2. Estructura de la metodología Esta metodología ofrece un marco de trabajo en el que se define: • una estructura de proyecto que sirva de guía al equipo de trabajo e involucre a los usuarios en su desarrollo y en sus puntos decisivos. • un conjunto de productos finales a desarrollar. • las diferentes responsabilidades y funciones de los miembros del equipo de proyecto y de los usuarios. Con este fin, se describen en detalle la sucesión de pasos, estructurados en Fases, Módulos, Actividades y Tareas, que se han de seguir en el desarrollo de sistemas informáticos, así como los productos que se obtienen en cada uno de dichos pasos. Estos productos pueden ser, productos finales o bien productos intermedios que servirán para la realización de algún paso posterior. Por último se describe la estructura final de la documentación obtenida. 3. Fundamentos del modelo Orientado a Objetos Modelado en el Análisis y Diseño Orientado a Objetos Antes de comenzar a estudiar el modelado en el Análisis y Diseño Orientado a Objetos, se debe mencionar los conceptos básicos y propiedades inherentes de la Orientación a Objetos. Conceptos Básicos
3.1 Objetos

“Los objetos son cualquier cosa, ya sea real o abstracta, acerca de la cual se almacenan datos y las operaciones que permiten controlar dichos datos.” [3] Esta definición se basa principalmente en la idea de que todas las personas se forman conceptos de las cosas, las cuales poseen características que las describen y pueden efectuar ciertas funciones o procedimientos. Sin embargo, esta definición abarca una mayor cantidad de conceptos de forma implícita. Un objeto no es sólo una cosa en un sistema, sino que también es una representación de un concepto en el sistema. Los objetos presentan una determinada condición llamada estado, el cual está constituido por los datos que lo representan en un momento dado. Un objeto contiene una cierta cantidad de atributos, también conocidos como variables de instancia, en los cuales se registran los datos. Algunos de los atributos pueden tener valores variables, mientras que otros pueden ser inmutables o constantes. Por otra parte, un objeto puede tener un determinado comportamiento, que corresponde a la manera en que el objeto actúa y reacciona de acuerdo a sus cambios de estado y los mensajes que puede recibir. Los atributos que tiene un objeto y los mensajes que puede recibir se encuentran normalmente fijados; por lo tanto, la forma en que un objeto
Profesor. Oscar Saavedra Rodríguez

3

Cada clase cumple con un determinado propósito en el sistema. determinando la funcionalidad Profesor. 3. No hay mayor distinción entre tipo de objeto y clase al referirse a una agrupación de objetos con propiedades comunes. De esta forma. El nombre de un objeto.1 Tipo de Objeto y Clase Se puede tener varios objetos que comparten las propiedades ya mencionadas. Por ende. pueden ser analizados bajo el concepto de caja negra. la cual no se define por los valores de sus atributos en un momento dado. dichos mensajes permiten activar una operación definida previamente a través de métodos. pueden efectuar las mismas operaciones para sus datos. Los métodos especifican la forma en que se controlan los datos de un objeto.reaccionará ante un mensaje determinado dependerá de los valores de sus atributos en un momento determinado. el objeto sigue siendo el mismo durante toda su existencia. Para que un objeto que recibe un mensaje. sólo debe conocer la forma de comunicarse con él. sino que se debe a una existencia continua del objeto. De este modo las solicitudes permitirán la comunicación entre un objeto y otro. En un sistema de información. los cuales presentan un comportamiento al interactuar con otras clases. haciendo que cada objeto particular sea una instancia del tipo de objeto en el que fue definida. y por ende. pueda efectuar una operación a través de los métodos definidos. estos objetos que comparten características comunes son agrupados en una categoría común para todos. o de sí mismos. así como los valores de los otros atributos pueden sufrir cambios en el tiempo. aquél que desee utilizarlo no debe conocer su estructura interna. Para poder efectuar esto. Indica el nombre de la clase (o tipo de objeto). Dada la gran complejidad que puede tener un tipo objeto gracias a la composición de éste. haciendo referencia sólo a la estructura de datos del objeto invocado. los atributos y los métodos definidos para la manipulación de sus datos. La signatura corresponde al nombre y parámetros de la operación. ya sea de otros objetos con los cuales están relacionados. Una clase corresponde a la implementación en software de un tipo de objeto. Los objetos también se caracterizan por tener una identidad. los objetos reciben mensajes. así como pueden presentar los mismos estados y responder de la misma forma ante un determinado mensaje. lo cual define su identidad.1. y por lo tanto. Oscar Saavedra Rodríguez 4 . no obstante. debe validar el mensaje a través de una concordancia entre el mensaje y la signatura de la operación que se va a efectuar. La definición de objeto hace referencia a las operaciones que permiten manipular los datos de un objeto. las clases corresponden a elementos estructurales o componentes fundamentales. se hace referencia a tipos de objetos que contienen una determinada estructura de datos definida por los atributos y los métodos para manipular dichos datos.

y no tienen conocimiento de los emisores y receptores con los que se comunica. Por lo tanto. lo que se define como ocultamiento de la información. 3. el tipo de objeto esconde sus datos de los demás tipos de objetos y permite el acceso a éstos mediante sus propios métodos. la interfaz del objeto permite intermediar la comunicación entre éste y los demás objetos en una colaboración. La ventaja que presenta el ocultamiento de la información a través del encapsulado es que evita la corrupción de los datos de un objeto a causa de un mal manejo de éstos por parte de un usuario. El usuario puede acceder a los datos sólo a través de los métodos sin conocer la estructura interna de éstos ni los detalles de cómo se llevan a cabo las operaciones.de éste. y la especialización de componentes que implementa la herencia de atributos y operaciones a nuevas subclases. los mensajes deben ser especificados de acuerdo a la signatura de los métodos del objeto para poder efectuar una operación. La funcionalidad del sistema está representada por las propias características que estos elementos poseen y le aportan como son la reutilización de componentes en nuevos sistemas. Sin embargo. Sin embargo. Otra de las ventajas que presenta el encapsulado es que permite modificar la implantación de un objeto sin que sea necesario modificar las aplicaciones que lo utilizan. el sistema puede utilizar el objeto de las maneras permitidas por la interfaz. éste debe estar definido como parte de su responsabilidad. Oscar Saavedra Rodríguez 5 . la construcción clases y sistemas complejos a partir de la composición de unidades más simples. De este modo. entregando los servicios solicitados en los mensajes que se intercambian entre ellos. Estas responsabilidades determinan la forma en que debe responder un objeto ante los requerimientos de otro.2 Encapsulado El concepto de encapsulado se refiere al empaque conjunto de datos y métodos de un tipo de objeto. Dado que los objetos son elementos caracterizados por el encapsulado de sus atributos y operaciones en la clase que los define. encapsulando el conocimiento que se puede tener sobre el módulo. A través del encapsulado. y establecido en su interfaz. i. de las cuales un cliente puede depender. Profesor. lo cual confirma el encapsulado del objeto. para que un objeto responda a los requerimientos de otro. la interfaz de un objeto permite la comunicación entre éste y otros objetos de los cuales reciben mensajes. Interfaz La interfaz de un objeto define ciertas características de éste. La interfaz de un objeto está ligada a las responsabilidades de éste para con los demás objetos con que interactúa.

La relación de herencia es una relación particular que no se da sólo para las clases. Cuando se produce una especialización se establece una relación entre las clases que implementan los respectivos tipos y subtipos. donde también se le denomina relación de generalización – especialización. Incluye las operaciones y los atributos de la superclase y posiblemente algunos más. sino que también es extensible a otros elementos del modelado orientado a objetos. Cuando una clase tiene un sólo padre. Especialización y Herencia Un tipo de objeto de alto nivel puede especializarse en un tipo de objeto de bajo nivel. pero que sí tienen uno o más hijos.Modelo Comunicación entre Objetos: Op1 Op2 Op A Op B Op3 Clase Op4 Op C Clase Op D Ejecutar (Op E) Op5 Op6 . Profesor. también son conocidas como clases raíz o clases base. Las clases que no tienen un padre. un tipo de objeto puede presentar subtipos. análogamente. Generalización. Fuente: Elaboración Propia. Por lo tanto la clase hija puede sustituir a la clase padre. Sin embargo. De esta forma. Figura 2. cuando una clase tiene más de un padre. donde la subclase hereda las propiedades de la clase padre su estructura de datos y sus métodos. Una clase puede tener uno o más padres. ii. por lo tanto. Oscar Saavedra Rodríguez 6 .. la relación se conoce como herencia múltiple. la relación se conoce como herencia simple. pero no a la inversa. mientras que las clases sin hijos son denominadas clases hoja. una subclase es una versión extendida y especializada de su superclase. Comunicación Entre Objetos de Acuerdo a Responsabilidades.1. la subclase también puede tener atributos y métodos propios. Op E Op F ..

puede que la implementación de algún método heredado tenga una implementación diferente para la subclase que lo hereda.. Op1 Op2 Op 1 Op 2 Op3 Producto Herencia Op 3 Producto Nacional Op C Op A Op B . Polimorfismo y Ligadura Dinámica El polimorfismo y la ligadura dinámica (también conocida como enlace dinámico) son propiedades de los objetos frente a una relación de herencia o generalización entre clases y subclases. la subclase redefine el método heredado para poder efectuar la manipulación de datos requerida según el mensaje que reciba. la ligadura dinámica corresponde a un mecanismo que permite identificar el método que se debe ejecutar cuando existen métodos heredados a una clase especializada y que han sido redefinidos. y esto se debe principalmente a que la subclase puede responder a ciertos comandos de forma diferente que la clase padre.2.Figura 2. Sin embargo. Fuente: Elaboración Propia. Oscar Saavedra Rodríguez 7 . Sin embargo. ya que la invocación del método está ligada a la signatura de la operación. es decir. Profesor. En una relación de generalización las subclases heredan los atributos y los métodos de la clase padre. iii. Por lo tanto. ya que a través de la ligadura dinámica se identifica el código del método polimórfico que debería ejecutarse como respuesta a algún mensaje. Esta redefinición del método en una subclase se conoce como polimorfismo del método. Representación de Especialización entre Tipos de Objetos. el objeto invocador (el que envía el mensaje) no debe preocuparse por la diferencia de definición entre estos dos métodos.

Figura 2.3. Representación de Polimorfismo y Enlace Dinámico.

Jubilar Ejecutivo

Ascender

Contratar

Ascender.

Contratar

Herencia
Jubilar

Empleado Operación polimórfica

Jubilar

Ejecutivo

Sueldo

Gastos Nómina

..

Fuente: Martin, J.; Odell, J. Análisis y Diseño Orientado a Objetos.

Razones de Enfoque Orientado a Objetos Existe una gran cantidad de razones que se pueden enumerar para justificar el uso de la metodología orientada a objetos para el modelado de sistemas de información. Estas razones se fundamentan en las características de las técnicas orientadas a objetos. 1. El mundo está formado por objetos, por lo que se hace natural categorizar los objetos y descubrir su comportamiento. Las personas en las organizaciones piensan de manera natural en términos de objetos, eventos y procesos, lo cual facilita la diagramación de este tipo de modelos. 2. Los sistemas suelen construirse a partir de objetos ya existentes, conduciendo a un alto grado de reutilización de componentes, con lo cual se reducen los tiempos de desarrollo, entregando mayor confiabilidad del sistema y menores costos en el proceso de diseño e implantación. 3. La creación de sistemas con un funcionamiento correcto es más fácil con las tecnologías Orientadas a Objetos, ya que las clases están diseñadas para reutilizarse. Por otra parte las clases están autocontenidas y divididas en métodos, donde cada método se puede construir, depurar y modificar con relativa facilidad según los vínculos que presenten las clases y los requerimientos del usuario que se deben cumplir. Por otra parte, se puede enumerar una gran cantidad de beneficios del análisis y diseño orientado a objetos: 1. Reutilización. Las clases están diseñadas para ser reutilizadas en otros sistemas, y por lo tanto su construcción permite una mayor flexibilidad para poder maximizar la reutilización de componentes en nuevos sistemas. 2. Estabilidad y confiabilidad. En la medida que se van reutilizando las clases en diversos sistemas de información, éstas se van volviendo estables, permitiendo un desempeño más eficiente y confiable de la clase que está siendo reutilizada. 3. El diseñador piensa en términos del comportamiento de objetos y no en detalles de bajo nivel. El encapsulado oculta los detalles y hace que las clases complejas sean fáciles de utilizar. Las clases son como cajas negras, es decir, el
Profesor. Oscar Saavedra Rodríguez

8

4.

5.

6. 7.

8.

9.

10.

investigador utiliza las clases y no ve al interior de ésta, ya que sólo debe entender su comportamiento y cómo comunicarse con ella. Cada vez se construyen clases más complejas. El diseño orientado a objetos permite la construcción de clases a partir de otras clases, de la misma forma en que los bienes se fabrican a partir de un conjunto de materiales y partes ya existentes. Esto permite llevar a cabo la construcción de componentes complejos que a su vez, se convierten en sistemas más complejos. Los diseños suelen tener mayor calidad, ya que se integran a partir de componentes ya han sido probados y por lo tanto corregidos ante la presencia de errores pasados. Las clases poseen integridad, ya que los datos sólo se pueden utilizar con métodos específicos. El análisis orientado a objetos modela la organización o área de aplicación de modo que sea lo más cercana a la realidad, y por lo tanto se obtienen modelos más fáciles de comprender dentro de la organización. Permiten que se manifieste una mejor comunicación entre los profesionales de los sistemas de información y los directivos de una organización, puesto que los empresarios pueden comprender fácilmente el paradigma, ya que piensan en términos de eventos, objetos y políticas empresariales Los modelos empresariales deben describir las reglas del negocio, las cuales se expresan en términos de eventos y la forma en que éstos deben modificar el estado de los objetos en la empresa. Por lo tanto, a partir del modelo de empresa se deben deducir diseños con la mayor automatización posible. Independencia del diseño. Las clases están pensadas para ser independientes del ambiente de plataformas, hardware y software, dado que utilizan solicitudes y respuestas en formato estándar. Esta característica es la que permite que las clases sean reutilizables.

Profesor. Oscar Saavedra Rodríguez

9

3.2.1 Elementos Claves en el Desarrollo de Sistemas de Información. Todo sistema de gestión destinado a apoyar el proceso de toma de decisiones dentro de una organización debe cumplir con ciertos requisitos que establecen la forma en que los usuarios esperan que el sistema responda frente a determinadas solicitudes, tanto a nivel de procedimientos como de información. Por lo tanto, se debe establecer claramente el contexto sistema – usuario en el cual se debe trabajar para modelar un sistema. Sin embargo, ésta no es una tarea simple, puesto que implica la delimitación del área de negocios, incorporando sus agentes, procesos, recursos, flujos de información y reglas de negocio, para poder analizar y diseñar un sistema de gestión adecuado a implementar. Para definir los límites de un sistema de información, se debe tener claro cuál es el proceso global que se desea representar. Es por esta razón que la mejor manera de determinar la frontera sistema – entorno es a través del modelado del proceso de negocios que se encuentra bajo análisis, de modo de poder identificar los elementos ya mencionados, acotando el problema en cuestión. Por otra parte, si bien el modelado del proceso de negocios permite obtener una gran cantidad de antecedentes del sistema que se desea modelar, se requiere la integración de tres aspectos que conforman lo que se puede denominar como la “Trilogía del modelado de sistemas”, la cual está conformada por tres aspectos claves que se deben considerar en forma conjunta para un desempeño eficaz y eficiente durante todo el proceso. Tal como se representan en la figura 1, la trilogía del modelado de sistemas considera: • Una notación común y clara para llevar a cabo el proceso de modelado. • Herramientas de apoyo para la elaboración de modelos. • Un proceso lógico, claro y ordenado que permita tomar todos los aspectos relevantes del proceso de modelado. Elementos Clave del Desarrollo de Sistemas de Información.

Fuente: Elaboración Propia

Profesor. Oscar Saavedra Rodríguez

10

los cuales permiten determinar los aspectos estáticos y dinámicos del sistema de información. y de la misma forma ocurría con los integrantes de equipos de desarrollo de sistemas. hasta la estructura interna del sistema a través del uso de UML. El primer nivel de análisis del sistema fue entregado por los Modelos de Procesos de Negocio (BPM) definidos en la sección anterior. UML entrega a los desarrolladores de software un lenguaje que les ayuda en la discusión de problemas y soluciones involucrados en la construcción de un sistema. UML es un lenguaje de modelado que no está asociado a un proceso particular. La metodología orientada a objetos abarca estas perspectivas y pueden representarse a través de modelos gráficos que son elaborados con una nomenclatura clara y simple de comprender. Además. UML entrega una representación simple y gráfica de los elementos que participan en un sistema analizado y diseñado a través del enfoque Orientado a Objetos y las interacciones estructurales y de comportamiento existente entre ellos. UML cumple con las características que un buen lenguaje de modelado debe tener. en torno a la especificación de casos de uso. Mediante UML y sus herramientas se establecerá el análisis y diseño de un sistema orientado a objetos. desarrollado en la década de 1990 por los tres expertos de la Ingeniería de Software: Ivar Jacobson. se abarca la sociedad de objetos participantes del proceso de negocios del área escogida como sistema de estudio para el modelado del mismo como un sistema de información.A continuación se describirán en detalles los elementos claves del desarrollo de sistemas de información. UML: Una Notación Común para el Modelado Orientado a Objetos El modelado de sistemas de gestión requiere tomar en cuenta varias perspectivas que van desde un enfoque estático y estructural hasta el comportamiento del sistema. Esta nomenclatura está definida por el llamado Lenguaje Unificado de Modelado (UML). Grady Booch y James Rumbaugh. lo cual ayuda a evitar confusiones en las diferentes etapas del proceso de desarrollo. Esto permitirá efectuar el estudio desde un punto de vista externo que considera la interacción sistema – usuario. y de las áreas involucradas dentro de un entorno delimitado. cada metodología de diseño tenía su lenguaje de modelado. al considerar la organización en su totalidad como un sistema social. En el segundo nivel de análisis. conocidos como los “tres amigos”. 5. Oscar Saavedra Rodríguez 11 . Esto se debe a que en el pasado. a través de un conjunto de diagramas que atacan cada uno de los aspectos que se deben analizar durante el desarrollo de un sistema de gestión. las cuales Profesor. lo cual dificultaba la comprensión de los diagramas elaborados y provocaba notorios retrasos en los proyectos de software. otorgando una visión contextual del problema desde una perspectiva de procesos y procedimientos propios del negocio.

cuando más general sea la utilización de un lenguaje. Diagramas: Las Herramientas de UML Un sistema representa la cosa que está modelando. Debe ser inequívoco. UML permite representar los dos aspectos principales de un sistema: la estructura y el comportamiento. de modo que sea posible expresar los aspectos del diseño que será necesario tratar. ambos relativamente estables. Se pueden ver los aspectos estáticos de un sistema como su esqueleto y su andamiaje. es una ventaja si ya conocen el lenguaje de modelado. y arcos que representan las relaciones entre los elementos. 4. un diagrama es la representación gráfica de un conjunto de elementos. 2. vista desde diferentes perspectivas mediante diferentes modelos. 5. y que reflejen de forma que tengan sentido. los cambios en el diseño que se llevan a cabo durante el desarrollo como cambios en el modelo. 12 Profesor. Suficientemente expresivo. Oscar Saavedra Rodríguez . • • • • Los diagramas estructurales de UML son: Diagramas de clases. de forma que el lenguaje de modelado proporcione un claro conocimiento del sistema en vez de proporcionar el camino para lograr dicha comprensión del sistema. Para hacer diseño basado en componentes hay que ser capaz de leer las descripciones de los componentes. y con esas vistas representadas mediante diagramas. Diagramas de despliegue. Por ende. Por supuesto. normalmente mostrado como un grafo conexo de nodos que representan los elementos. en vez de presentar más. Diagramas de objetos. de modo que ayude a resolver los malos entendidos que se tengan respecto de la comprensión del sistema.justifican la necesidad de un lenguaje unificado de modelado. es más barato tener en cuenta un componente. es más probable que se cumplan los cuatro puntos anteriores. Generalmente utilizado. Suficientemente fácil de utilizar. Para ello cuenta con un conjunto de diagramas que se enfoca al modelado de un determinado punto de vista del análisis del sistema de información. Estas características se presentan a continuación. Por otra parte: • • Cuando se incorpora gente nueva a un proyecto. Soportado por herramientas adecuadas. construir y documentar los aspectos estáticos de un sistema. Los diagramas estructurales de UML existen para visualizar. no en un trabajo rutinario como crear un diagrama con una herramienta de dibujo. de manera que el esfuerzo de los desarrolladores pueda utilizarse en un trabajo que requiera su habilidad. especificar. y cuanto más rápido y fácil se pueda hacer. 3. Diagrama de componentes. 1. por una gran variedad de razones.

Los diagramas de comportamiento de UML se utilizan para visualizar. tomando en cuenta el conjunto de requisitos a los cuales el sistema debe responder. por lo que son externos a él. Un actor representa un conjunto coherente de roles que los usuarios de los casos de uso interpretan al interactuar con éstos. y sus relaciones. en gran cantidad de sistemas los actores también son considerados como parte de un modelo estructural del sistema como son los diagramas de clases. un actor se representa mediante la figura de un muñeco con un nombre que hace referencia al rol que interpreta.1 Diagramas de Casos de Uso Un diagrama de casos de uso representa un conjunto de casos de uso y actores. Diagramas de actividades. incluyendo variantes. 5. Los diagramas de casos de uso permiten entregar una definición de los límites del sistema que se está estudiando. Profesor. Gráficamente. Diagramas de estados. que ejecuta un sistema para producir un resultado observable de valor para un actor. construir y documentar los aspectos dinámicos de un sistema. Los actores representan una interacción individual con el sistema. • • • • • Los diagramas de comportamiento de UML son: Diagramas de casos de uso. Los casos de uso documentan el comportamiento desde el punto de vista del usuario. El rol que interpreta un actor puede representar a una persona. La planificación de las iteraciones del desarrollo. Casos de Uso y Actores Un caso de uso es una descripción de un conjunto de secuencias de acciones. Diagramas de secuencia. Sin embargo. Se pueden ver los aspectos dinámicos de un sistema como aquellos que representan sus partes mutables. Diagramas de colaboración. Oscar Saavedra Rodríguez 13 . un dispositivo hardware o incluso otro sistema que interactúa con aquel que se está analizando. El modelado de casos de uso es de gran ayuda en los siguientes aspectos: • • • La captura de requisitos. un caso de uso se representa mediante una elipse con un nombre distintivo. La validación de los sistemas. especificar. el cual puede ser cualquier cosa ajena al sistema que se está desarrollando y que interactúa con el mismo. dado que permiten representar la interacción sistema – usuario. Gráficamente.

Se debe tener en consideración que a pesar de capturar el comportamiento del sistema. cada secuencia representa un posible flujo de eventos a través de todas las posibles variantes.Los actores pueden llevar a cabo un caso de uso conectándose con él a través de relaciones de asociación. el cual ilustra un comportamiento del sistema. los casos de uso que los componen pueden organizarse de acuerdo a aspectos comunes de requisitos en agrupaciones llamadas paquetes. En consecuencia. no es necesario representar esta relación. cada uno puede enviar y recibir mensajes. Sin embargo. Además de las relaciones de asociación entre actores y casos de uso. Pooley. Representación General de Asociación Actor – Caso de Uso. un escenario corresponde a una instancia de un caso de uso. Organización de los Casos de Uso Cuando se cuenta con un diagrama de casos de uso muy extenso.4b. Por lo tanto. y por ende. Utilización de UML. Un caso de uso en un diagrama representa un flujo de eventos que se lleva a cabo mediante secuencias y que puede ser descrito mediante texto. Esta sociedad de elementos y sus estructuras estática y dinámica. Figura 5. ya que el análisis no debe estar influenciado por asuntos de implementación. No obstante. Procesar Prestamo Resposable de Prestamos Fuente: Stevens. Una asociación entre un actor y un caso de uso indica que se comunican entre sí. Ejemplo de Asociación Actor – Caso de Uso. los cuales serían representaciones de subsistemas dentro del sistema global en estudio. dado que se subentiende que el caso de uso será implementado a través de otros diagramas en etapas posteriores del desarrollo. Figura 5. Caso de Uso Actor Fuente: Elaboración Propia. un caso de uso debe ser implementado en algún momento a través de una sociedad de elementos que colaboran entre sí para este fin. Oscar Saavedra Rodríguez 14 . los diagramas de casos de uso no especifican el modo en que se implementa el comportamiento. Cada secuencia se denomina escenario.4a. dentro de un diagrama de casos de uso pueden presentarse otro tipo de relaciones particulares que permiten dar una mayor potencialidad a este tipo de diagramas en la representación de la Profesor. puede modelarse en UML como una colaboración.

Figura 5. pudiendo añadir nuevas acciones o redefinir el comportamiento del padre. La especialización de los casos de uso se da cuando una tarea puede presentar una versión específica de sí misma. así como en la descripción y análisis de requisitos. Los actores hijos. Actor Actor Específi co 1 Actor Específico 2 Fuente: Elaboración Propia. Profesor. heredan las propiedades del actor padre. Oscar Saavedra Rodríguez 15 . Inclusión. así como para otros nodos dentro de los distintos diagramas de UML.5a. lo que da una mayor versatilidad funcional a los sistemas de gestión. La relación de generalización. e incluso pueden presentar características propias y redefinir las propiedades heredadas. Para los casos de uso. se presenta. para el caso de los actores. Relación de Generalización para Actores. Una relación de generalización se puede manifestar tanto para actores como para casos de uso. la relación de generalización también implica que el caso de uso hijo hereda el comportamiento y el significado del caso de uso padre. Los tipos de relaciones particulares que se pueden dar son: • • • Generalización. Extensión.interacción sistema – usuario. cuando un determinado actor se puede especializar en subtipos de actores que llevan a cabo un rol más específico que el actor padre. también denominada como herencia.

El Lenguaje Unificado de Modelado. Oscar Saavedra Rodríguez 16 .5b. El Lenguaje Unificado de Modelado.Figura 5. Jacobson. Relación de Generalización para Casos de Uso. Rubaugh. Cl i en te Cl i e n te Co m e rci al Fuente: Booch.6a.6b. Figura 5. Caso de Uso General Caso de Uso Específico 2 Caso de Uso Específico 1 Fuente: Elaboración Propia. Rubaugh. Ejemplo de Relación de Generalización para Actores. Jacobson. Figura 5. Profesor. Validar Usuario Comprobar Clave Examinar Retina Fuente: Booch. Ejemplo de Relación de Generalización para Casos de Uso.

La relación de inclusión se usa para evitar describir el mismo flujo de actividades repetidas veces.7a. La relación de extensión se emplea para separar el comportamiento excepcional. El caso de uso nunca está aislado. Por lo tanto. Oscar Saavedra Rodríguez 17 . La relación de inclusión entre casos de uso significa que un caso de uso base incorpora explícitamente el comportamiento de otro caso de uso en un punto de extensión del caso de uso base. Representación General de la Relación de Inclusión. La relación de inclusión de casos de uso se representa mediante una dependencia con el estereotipo <<include>> entre los casos de uso.Las relaciones de inclusión y de extensión son un tipo de relación de dependencia estereotipada que se presenta entre casos de uso. <<include>> Tomar Prestada Copia de Libro Comprobar para Reserva Fuente: Stevens. Cuando un caso de uso incorpora dos o más escenarios con diferencias significativas. pero específicos a un problema concreto. donde la dirección de la dependencia va desde el caso de uso base hacia el caso de uso de funcionalidad común. Otra forma de describir la relación de extensión es como la incorporación implícita del comportamiento de un caso de uso por parte del caso de uso base en un lugar Profesor. es decir. los estereotipos son extensiones de UML que permiten crear nuevos bloques de construcción a partir de uno ya existente. Figura 5.7b. o bien. sino que es instanciado como parte de un caso de uso base más amplio que lo incluye. Una relación de dependencia declara que un cambio en el elemento independiente afecta al elemento dependiente. Pooley. Por otra parte. Se emplea para mostrar cómo el sistema puede utilizar un componente que ya existe. para mostrar la funcionalidad común entre casos de uso. ubicando el comportamiento común en un lugar aparte. Caso de Uso Base <<include>> Caso de Uso Común Fuente: Elaboración Propia. cuando pueden ocurrir varias cosas distintas dependiendo de las circunstancias. Figura 5. pero no al revés. se puede decir que la relación de inclusión es un tipo de delegación. Utilización de UML. Ejemplo de Relación de Inclusión. se puede decidir que es más claro mostrarlos como un caso principal y uno o más casos secundarios.

Rubaugh. Representación General de la Relación de Extensión. se debe efectuar la descripción de los casos de uso involucrados en el diagrama.8a. Figura 5. de manera similar a la relación de inclusión. Ejemplo de Relación de Extensión. el caso de uso base puede estar aislado. donde la dirección de la dependencia va desde el caso de uso excepcional al caso de uso normal.9. Figura 5. En este tipo de relación.especificado de éste. Oscar Saavedra Rodríguez 18 . narración en prosa de la secuencia de acciones implícitas en la realización del caso de uso. la relación de extensión puede o no mostrar la condición bajo la cual se manifiesta el caso de uso excepcional. pero bajo ciertas condiciones. Verficar Cliente <<extend>> Registrar Cliente Nuevo Fuente: Booch. Además.8b. Figura 5. La relación de extensión se representa a través de una relación de dependencia con el estereotipo <<extend>> entre los casos de uso. la cual puede llevarse a cabo mediante el uso de pseudocódigo en español estructurado. Jacobson. su comportamiento puede extenderse con el comportamiento de otro caso de uso. El Lenguaje Unificado de Modelado. diagramas de interacción. Forma de Tabla de Descripción de Caso de Uso. o bien mediante un formato de tablas estándar. Una vez que ha sido construido el diagrama de casos de uso. Caso de Uso Actores Tipo Precondiciones Postcondiciones Descripción Curso Típico de Eventos Acción Actor Respuesta Sistema Fuente: Elaboración Propia Profesor. Caso de Uso Normal <<extend>> Caso de Uso Excepcional Fuente: Elaboración Propia.

En el caso de existir comportamientos que sean similares a otros proporcionados por casos de uso. o bien. se debe emplear un criterio adecuado que tome en consideración el propósito original del sistema de gestión que se está modelando y/o desarrollando. pero que presentan un grado de especialización. se debe ser más sutil en la identificación de los actores no humanos. Sin embargo. 4. ya que es menos claro qué se debería considerar como un sistema externo o un dispositivo. Oscar Saavedra Rodríguez 19 . Para ello. Un diagrama de clases se define como un diagrama que muestra un conjunto de interfaces. 3. Los denominados actores humanos son los más fáciles de identificar dado que los roles que interpretan tienen una alta relación con su participación dentro del proceso de negocios de la organización. Para ello. Identificar los actores. Una vez determinado el diagrama de casos de uso. y nombrar tales comportamientos como casos de uso y asociarlos con el o los actores correspondientes. Organizar los actores similares en jerarquías a través de relaciones de generalización/especialización. se deben establecer las relaciones de generalización pertinentes. un diagrama de interacción como el diagrama de secuencias. para lo cual se puede usar utilizar un texto escrito. los casos de uso deben ser especificados. 5.2. 2. 6. Estos diagramas se utilizan para: Profesor. se debe tener en cuenta quiénes son los usuarios del sistema y los roles que pueden tomar frente a determinados requisitos. Además.Pasos para la Construcción de un Diagrama de Casos de Uso Tal como se mencionó al principio de esta sección. los diagramas de clases representan la base para otros diagramas de UML como son los diagramas de componentes y de despliegue. los diagramas de casos de uso se utilizan principalmente para modelar el contexto de un sistema. Este tipo de diagramas se emplea para modelar la vista de diseño estática de un sistema. 5. colaboraciones y relaciones. Identificar los comportamientos comunes y excepcionales que se pueden presentar para uno o varios casos de uso y vincularlos a través de relaciones de inclusión y extensión respectivamente. para modelar los requisitos del sistema. La identificación de los casos se desprende del análisis del modelo de procesos de negocios. Por lo tanto. o bien. Los diagramas de clases soportan los requisitos funcionales y los servicios que debe proporcionar a los usuarios finales o clientes. Diagramas de Clases Los diagramas de clases son los más utilizados en el modelado de sistemas orientados a objetos. delimitando los límites del mismo. para la construcción de un diagrama de casos de uso se deben seguir los siguientes pasos: 1. Considerar el comportamiento que cada actor espera del sistema.

se puede pensar en el diagrama de clases como un plano para un modelo conceptual de una base de datos.1 Clases Una clase corresponde a la implementación en una aplicación software de un tipo de objeto. operaciones y responsabilidades. El nombre de la clase debe ser representativo de la colección de objetos que agrupa y debe distinguirla de las demás clases que se encuentra incorporadas en el diagrama. En este sentido. A menudo. Una operación es la implementación de un servicio que puede ser requerido a cualquier objeto de la clase para que muestre un comportamiento. Por lo tanto. Dado que una clase puede presentar una gran cantidad de atributos y operaciones. es decir. A menudo se presenta la situación en que los atributos u operaciones de una clase no se encuentran disponibles para todos lo clientes de ésta. y por lo tanto indica las repuestas que una clase debe entregar frente a determinados requerimientos. implica tomar decisiones sobre qué abstracciones (y sus responsabilidades) se consideran parte del sistema y cuáles quedan fuera de sus límites. los diagramas se emplean para representar dicho conjunto de clases y sus relaciones. Se mencionó anteriormente que las clases. el encontrar un compartimento vacío en una clase no significa que no haya atributos u operaciones.• • • Modelar el vocabulario de un sistema. Modelar colaboraciones simples. la cual incluye el nombre. una operación es una abstracción de algo que se puede hacer a un objeto y que es compartido por todos los objetos de la clase. no es necesario representarlos todos en un diagrama. Por lo tanto. Las colaboraciones son una sociedad de interfaces. tipo y los valores por defecto de todos los parámetros y un valor de retorno para el caso de las funciones. Una operación se puede especificar indicando su signatura. clases y otros elementos que actúan en conjunto para lograr sinergias en el sistema. Un atributo es una propiedad de una clase con un nombre que describe un rango de valores que pueden tomar las instancias de la propiedad. además de atributos y operaciones. Una responsabilidad es un contrato u obligación de una clase. relaciones y semántica. Modelar un esquema lógico de bases de datos. Esta propiedad se denomina Profesor. Por lo tanto. Las clases se caracterizan por poseer un nombre. 5. no tenerlos. la invocación de una operación sobre un objeto puede provocar un cambio de los datos o del estado en éste. Una clase puede tener cualquier número de atributos o simplemente. Oscar Saavedra Rodríguez 20 . una clase puede tener cualquier número de operaciones o ninguno. una clase describe un conjunto de objetos que comparten los mismos atributos. operaciones. Dicho de otro modo. Al igual que los atributos.2. también poseen responsabilidades. ya que en gran cantidad de dominios se necesitará almacenar información persistente en una base de datos relacional o en una base de datos orientada a objetos. atributos.

Cualquier colaborador externo a la clase con visibilidad a ésta puede utilizar la característica (atributo u operación). La visibilidad de los atributos u operaciones puede ser de tres tipos: Pública (public).visibilidad y se emplea cuando se quieren ocultar detalles de implementación. 5. Profesor.operacion2 () : int # operacion3 () : int Fuente: Elaboración Propia. Representación de una Clase. • Figura 5. sus Atributos y Operaciones y Visibilidades. mostrando sólo las características necesarias para que la clase cumpla con sus responsabilidades.2 Relaciones Una relación se define como una conexión entre elementos. Figura + origen : java. Figura 5. Se represente anteponiendo el símbolo “#” a la característica. Jacobson. El Lenguaje Unificado de Modelado. • Privada (private). Se especifica anteponiendo un signo “–” a la característica. Sólo la propia clase o elemento puede utilizar esta característica. NombreClase + + # atributo1 atributo2 atributo3 atributo4 : : : : int int int int + operacion1 () : int . Ejemplo de Clase con sus Atributos y Operaciones y Visibilidades.10b. así como características adicionales que permiten entregar una mejor descripción de lo que buscan representar en un modelo visual. • Protegido (protected). Rubaugh. las dependencias y las de asociación.String : int + mover () + redimensionar () : int : int + visualizar () Fuente: Booch. Cualquier descendiente o especificación de la clase o elemento puede utilizar la característica. La visibilidad de una característica es la base del ocultamiento de la información. Cuando una característica no posee un algún signo anteponiéndola. las relaciones presentan varios tipos según el tipo de conexión que se desea establecer entre los nodos.10a. se asume como pública. Los tipos de relaciones más importantes son las generalizaciones. Oscar Saavedra Rodríguez 21 .lang.2. Se especifica anteponiendo un signo “+” a la característica. En los modelos orientados a objetos.

denominado subclase o hijo. se puede decir que el hijo puede reemplazar al padre.La relación de generalización es aquella que se da entre un elemento general. Además. Figura 5. La relación de generalización se representa a través de una línea continua que termina en una flecha cerrada que apunta a la clase padre. pudiendo contener atributos y operaciones propias. La relación de generalización. mientras que una clase que no tiene hijos se le denomina clase hoja. Representación de una Relación de Herencia Simple. así como puede redefinir algunas o todas las operaciones heredadas a través de la propiedad del polimorfismo. así como la subclase también puede especializarse y presentar clases hijo. En una relación de generalización. Oscar Saavedra Rodríguez 22 . Por lo tanto.11a. Cl a se P a d re + + # + # a tri b u to 1 a tri b u to 2 a tri b u to 3 a tri b u to 4 : : : : int int int int o p e ra ci o n 1 () : i n t o p e ra ci o n 2 () : i n t o p e ra ci o n 3 () : i n t Cl a se Hi j o 1 + a tri b u to h i j o 1 : int + Cl a se Hi j o 2 . una superclase puede especializarse en más de una subclase. también llamada herencia es el mismo tipo de relación de generalización presentada para los casos de uso. la subclase. Una clase que tiene hijos. hereda los atributos y operaciones del padre.a tri b u to h i j o 2 : int .o p e ra ci o n h i j o 1 () : i n t o p e ra ci o n h i j o 2 () : i n t Cl a se Hi j o 3 + + a tri b u to h 1 : int o p e ra ci o n h 2 () : i n t Fuente: Elaboración Propia Profesor. en la metodología orientada a objetos se puede manifestar la herencia múltiple. se le denomina clase base o raíz. pero que no tiene padre. frente a esta relación. A menudo este tipo de relación también se le conoce relación Is-A (es-un-tipo-de). llamado superclase o padre. en la cual un hijo puede heredar las características de más de una clase padre. y uno específico. Dada la herencia de las características de la clase padre a la clase hijo.

lang.11b.String JornadaCompleta + Oficina : java.lang.lang.String + anexo : int + + + + + JornadaCompleta () setOficina (java.String getApellidos () : java. Academico : java. Ejemplo de una Relación de Herencia Simple.String + + + + Academico () setRut (java. Oscar Saavedra Rodríguez 23 .operacion2 () : i nt # operacion3 () : i nt Cl aseHij o2 .String + Nombre + Apellidos : java.String newOficina) : void setAnexo (int newAnexo) : void getOficina () : java.12a.lang.lang.lang.lang.String newRut) : void getNombre () : java.Figura 5.String getAnexo () : int JornadaParcial + Horas : int + email : int + + + + + JornadaParcial () getHoras () setHoras (int newHoras) getEmail () setEmail (int newEmail) : : : : int void int void Fuente: Elaboración Propia Figura 5. Representación de una Relación de Herencia Múltiple.lang.atributohi jo2 : int + operacionhi jo2 () : i nt Fuente: Elaboración Propia Profesor.String + Rut : java.lang. Cl asePadre + + # atri buto1 atri buto2 atri buto3 atri buto4 : : : : i nt i nt i nt i nt ClasePadre2 + atri butop2 : i nt + operacionp2 () : i nt + operacion1 () : i nt .

Ejemplo de una Relación de Herencia Múltiple. Representación de una Relación de Dependencia.13a. se debe incluir el nombre del estereotipo sobre la relación. Curso OO con UML (UTFSM) En una relación de dependencia entre establece una relación de uso.operacion2 () : int ClaseDependiente . Para representar una dependencia estereotipada.operacion1 () : int . Especifica que el origen de la dependencia instancia a la plantilla destino con los parámetros reales dados.12b. PeliculaVideo + nombre : java. Figura 5. En un diagrama de clases. Ejemplo de una Relación de Dependencia. La relación de dependencia se representa a través de una línea discontinua que finaliza en una punta de flecha abierta en dirección hacia el objeto independiente.13b. donde una modificación en la especificación de un elemento afecta al otro. Vehiculo Motorizado Aeronave Avion Fuente: Saavedra. UML provee ocho tipos de dependencias estereotipadas. O. Jacobson. 24 Profesor. Los estereotipos que se aplican a dependencias son: • Bind. ClaseIndependiente + atributo1 : int + atributo2 : int . las cuales pueden utilizarse para entregar un mayor nivel de detalle. Oscar Saavedra Rodríguez .String + duracion : int + + + + reproducir () iniciar () detener () rebobinar () Canal Fuente: Booch. El Lenguaje Unificado de Modelado. la clase dependiente utiliza a la clase independiente como argumento en la signatura de una operación.Figura 5. Rubaugh. pero no a la inversa.lang.atributodep1 : int + operaciondep1 () : int Fuente: Elaboración Propia Figura 5. Para entregar una mayor funcionalidad en las relaciones de dependencia entre clases.

. Una relación de asociación es una relación de tipo estructural que especifica que los objetos de una clase se encuentran conectados con los objetos de otra clase. Tabla 5. lo cual se puede interpretar como una amistad entre las clases de la relación.. Una relación de asociación se representa mediante una línea continua entre las clases conectadas. Una relación de asociación presenta varias características más. Powertype. Este estereotipo se utiliza cuando se desea modelar las relaciones entre dos atributos o dos asociaciones. Se utiliza para modelar clases que envuelven a otras clases.. Especifica que el origen puede calcularse a partir del destino. Esta especificación se conoce como multiplicidad o cardinalidad de la relación. Además.N Mínimo M hasta N. Especifica que la semántica del elemento origen depende de la semántica del objeto destino. Instantiate.1 Sólo uno 1 0. Friend. En una instancia de asociación se pueden presentar las siguientes multiplicidades. las clases participantes en una asociación interpretan un rol. también se debe especificar la cantidad de objetos de una clase con los que se relaciona un objeto de la otra. una relación de asociación puede tener un nombre que especifica cuál es el tipo de asociación entre las clases. Es de gran utilidad para implementar clases en las que se desee calcular indicadores de rendimiento a partir de otros datos. Se aplica cuando se desea etiquetar explícitamente una relación de uso. Especifica que el origen tiene una visibilidad especial en el destino. Especifica que el destino es un supratipo del origen. Especifica que el origen crea instancias del destino.1 Cero o uno 1. Simbología de la Multiplicidad de una Relación de Asociación. Por otra parte. Especifica que el objeto origen es una instancia de la clase destino. Símbolo Significado 0. Un supratipo es una clase cuyos objetos son todos hijos de un padre dado. donde uno de ellos es concreto y el otro conceptual.. Este tipo de relaciones son las más comunes en un diagrama de clases.* Muchos 2 1.2. También se puede simbolizar como *. Especifica que el origen está a un grado de abstracción más detallado que el destino. InstanceOf. 1 2 También se puede simbolizar como 1.* Uno o más M.. El uso de roles permite una interpretación más clara de una relación de asociación. con M < N Fuente: Elaboración Propia. Profesor. Oscar Saavedra Rodríguez 25 .• • • • • • • Derive. Dado que se trata de una conexión entre objetos de dos clases. Refine. Un rol puede definirse como la cara que la clase de un extremo presenta a la clase del otro extremo en una relación de asociación. Use.

operacion1 () : int .1 Fuente: Elaboración Propia.operacion2 () : int 0. Clase1 + atributo1 : int + atributo2 : int . Relación de Asociación con Multiplicidades y Roles. Clase1 + atributo1 : int + atributo2 : int . La navegabilidad se representa agregando una punta de flecha abierta en la dirección en que se desee la comunicación de las clases. Ejemplo Relación de Asociación con Multiplicidades.String java. Profesor.lang.String java.14b..operacion2 () : int Clase2 0. también se puede desear navegar desde los registros de una clase hacia los registros de la clase ubicada en el otro extremo de la relación.* .1 rol clase 1 0..String + + + + + Cliente RUT nombreCliente apellidoCliente direccionCliente emailCliente : : : : : java.operacion1 () : int .lang.String java. Figura 5.lang. Además de las características ya presentadas para una relación de asociación.String java..1 0.Figura 5.lang.lang. Oscar Saavedra Rodríguez 26 . Tal propiedad se denomina navegabilidad de la asociación e indica la dirección en que fluyen los mensajes desde una clase a la otra.String java.atributob1 : int + operacionb1 () : int Fuente: Elaboración Propia.* rol clase 2 Clase2 ..* 1.lang.lang.atributob1 : int + operacionb1 () : int Fuente: Elaboración Propia.lang. Vendedor + + + + + codigo nombre apellido fono direccion : : : : : int java.14a. presentando una mayor eficiencia de recorrido..15a. Relación de Asociación con Navegabilidad. Figura 5.String 1.String int java..

operacion2 () : int Clase2 1.atributob1 : int + operacionb1 () : int Fuente: Elaboración Propia.lang.1 Fuente: Elaboración Propia.String + EquipoDeTrabajo () 1.. La relación de agregación es meramente conceptual y sólo distingue el todo de las partes..lang. Figura 5.lang.15b. Por lo tanto se dice que la Clase 1 conoce a la Clase 2.15a.lang. Vendedor + + + + + codigo nombre apellido fono direccion : : : : : int java. Clase1 + atributo1 : int + atributo2 : int .String + Empleado () Fuente: Elaboración Propia. De acuerdo a la figura 5.String java. Además de la relación de asociación tal como se ha presentado hasta el momento.16b. Ejemplo de Relación de Asociación con Navegabilidad. No genera cambios en el significado de la navegación ni las multiplicidades. dado que éste viene dado por lo que la relación representa en un modelo visual. la navegabilidad indica que la Clase 1 puede conocer los registros y enviar mensajes a la clase 2.lang.String java. pero no a la inversa.. cuando la navegabilidad es bidireccional. también existen dos casos particulares de asociaciones que hacen referencia a que el objeto de una clase es parte del objeto de otra clase.String int java. Estas asociaciones particulares son las denominadas relaciones de Agregación y de Composición.. creando una conexión todo – parte. Oscar Saavedra Rodríguez 27 .lang.* . ésta no se representa en la asociación.String java.lang. Figura 5.* 0.operacion1 () : int .String java.String java.* + + + + + RUT nombre apellido fono direccion : : : : : int java.Figura 5. Una relación de agregación no tiene nombre.lang.String 1. Empleado EquipoDeTrabajo + numeroDeIntegrantes : java. Representación de una Relación de Agregación. Ejemplo de una Relación de Agregación.String java.lang.. Sin embargo. Una relación de agregación se representa mediante un diamante vacío ubicado en el extremo del todo. ni liga la vida del todo y las partes.lang.lang.String + fechaDeFormacion : java.lang.lang.* 0.. Profesor.* 1. Esto se debe a que una navegabilidad bidireccional puede implicar que aún no se ha tomado una decisión sobre el recorrido deseado para la relación.String int java.16a.String + + + + + Cliente RUT nombreCliente apellidoCliente direccionCliente emailCliente : : : : : java.

1).String java. Otra diferencia fundamental que presenta una relación de composición es la multiplicidad permitida para el todo. la relación de composición establece un fuerte vínculo entre el todo y las partes.. Clase1 + atributo1 : int + atributo2 : int .17b. donde la vida del todo determina la vida de las partes..String int int java.. Empresa + + + + RUT nombre direccion fono : : : : java. Es decir. Representación de una Relación de Composición. dado que una parte no puede pertenecer a más de un todo. Ejemplo de una Relación de Composición. si se elimina el todo. No obstante las partes pueden eliminarse individualmente antes de la eliminación de la parte compuesta.lang. las cuales no pueden ser parte de las propiedades de las clases asociadas o establecer una clase intermedia.1) o simplemente uno (1..String int 0. las partes son eliminadas con él. Oscar Saavedra Rodríguez 28 .* + + + + Departamento nombre piso numeroDeEmpleados gerente : : : : java.lang.operacion1 () : int .1 + Empresa () + Departamento () Fuente: Elaboración Propia. La relación de composición se representa mediante un diamante relleno ubicado en el extremo.* . Otro caso particular que se presenta para una relación de asociación entre dos clases es la posibilidad de que la relación también tenga propiedades.1 1.A diferencia de una relación de agregación..operacion2 () : int Clase2 0. ya que no permitiría vincular una instancia específica de la relación al par de clases ya asociadas.atributob1 : int + operacionb1 () : int Fuente: Elaboración Propia.lang.lang.. Figura 5.lang. Profesor. Una asociación con propiedades se representa a través de una Clase de Asociación.17a.String java. Figura 5. ya que ésta sólo puede ser cero o uno (0. la cual se expresa como una clase unida a la asociación a través de una línea discontinua.String 0.

Figura 5.2.* empleado Persona Contrato + descirpcion : java.operacion1 () : int . Representación de una Relación de Asociación con Clase de Asociación. Clase1 + atributo1 : int + atributo2 : int . Oscar Saavedra Rodríguez 29 .String + fechaContrato : java. para la construcción de un diagrama de clases se deben seguir los siguientes pasos: 1. Compañía 0..atributob1 : int + operacionb1 () : int ClaseAsociacion + atributoh1 : int + operacionh2 () : int Fuente: Elaboración Propia. Cabe mencionar que una clase de asociación no puede estar conectada a más de una asociación. Por lo tanto. Es decir.lang. Profesor. En diagramas de clases muy extensos.1 1..* . Rubaugh. se deben identificar los mecanismos que se desea modelar. Ejemplo de una Relación de Asociación con Clase de Asociación.18a. esto se puede solucionar formado grupos de clases cercanamente vinculadas y almacenarlas en paquetes relacionados a través de dependencias.18b. 5.util. A partir del modelo de procesos de negocios y de las especificaciones de los casos de uso.. El Lenguaje Unificado de Modelado.. Sin embargo.3 Pasos para la Construcción de un Diagrama de Clases Tal como se mencionó al principio de esta sección. los diagramas de clases se utilizan principalmente para modelar la vista de diseño estática del sistema. Jacobson.1 patron 1. la interpretación de éste se puede volver muy dificultosa. a través de la identificación de las clases participantes y sus relaciones.operacion2 () : int Clase2 0.Date + salario : int Fuente: Booch. ya que una clase de asociación es la propia asociación en sí. Figura 5. al igual como se describió para los diagramas de casos de uso. determinar las funciones y comportamientos del dominio de análisis.

tales como: Presentación: interfaz gráfica. estableciendo los roles. El incluye componentes de hardware tales como un computador un scanner de código de barras y software para que funcione el sistema. etc). Hint: Este caso es representativo de muchos sistemas de información y considera muchos temas comunes que un desarrollador de sistemas se va a encontrar.2. Para cada mecanismo se debe identificar los sustantivos candidatos a tipos de objeto que se implementarán como clases. pero que proveen servicios de soporte. Oscar Saavedra Rodríguez 30 . luego al análisis. tales como interfaces con las bases de datos. para así determinar las operaciones que podrán llevarse a cabo. Para decidir qué tipos de objetos candidatos se implementarán se debe tomar en consideración los límites y el propósito del sistema de información. estilo windows. agregaciones y composiciones respectivas que permitan entregar información adecuada para interpretar el diagrama. es el sistema típicamente utilizado en un negocio de retail (ventas al detalle). navegabilidades. por tanto la arquitectura del sistema considera varias capas. Utilizando una estrategia de desarrollo incremental iterativa. 4. Pagos. que satisfacen los requerimientos de la aplicación. debe proceder a establecer los requerimientos de información. Este sistema de información incluye una interfaz gráfica para el usuario final y el acceso a bases de datos relacional. Un terminal de punto de venta es un sistema computarizado utilizado para registrar las ventas y manejar los pagos. Se debe determinar los atributos y responsabilidades de las clases a implementar en el modelo. Profesor. tales cómo bases de datos orientada a objetos o relacional. Asuma que usted se le ha solicitado que cree un software para hacer funcionar un terminal POST. Lógica de aplicación – Objetos de servicios: objetos que no pertenecen al dominio del problema. Almacenamiento: un mecanismo de almacenamiento permanente. Identificar las relaciones estructurales existentes entre clases: asociaciones. diseño e implementación. dependencias y generalizaciones. Caso de Estudio: Sistema de Punto de Venta (Point of Sale) El sistema a estudiar es un terminal de point of sale (POST). 3. multiplicidades. Lógica de aplicación – Objetos del dominio del problema: objetos que representan conceptos del dominio (por ejemplo: Objeto Ventas.

es decir. asignación de responsabilidades de estos para completar los requerimientos de la aplicación. Oscar Saavedra Rodríguez 31 . Clientes. Capas: Caso de estudio POST Presentación Lógica de aplicación Objetos del dominio del problema Ventas Pagos Objetos servicios Conexión BD Administrador Seguridad Almacenamiento ---------------------------------------------------------------------------------------Análisis de Requerimientos La especificación de requerimientos es esencial para el éxito del proyecto. Funciones del sistema. Profesor. en una forma que claramente se pueda comunicar el cliente y el equipo de desarrolladores del sistema. Visión global: el propósito de este proyecto es crear un sistema de POST para ser utilizado en un negocio de retail. Objetivos y metas.En esta etapa del desarrollo del sistema enfatizaremos en el estudio preliminar. Los requerimientos son la descripción de las necesidades o deseos que debe cumplir un producto. Atributos del sistema. Clientes: una empresa orientada al retail. se dará mayor importancia a los objetos del dominio. Aspectos a considerar en esta fase: Afirmación de la visión global del sistema. La primera meta de esta fase es identificar y documentar que es realmente lo necesario.

Un proceso describe. Profesor. mejor y un servicio más barato y un eficiente proceso de negocio.Objetivos: en general. capturando la cantidad ofertada y calculando valor a pagar R2. tal como un proceso de negocios. y autorizar el pago con una autorización externa vía una conexión MODEM. Funciones del sistema: son las que se suponen que el sistema hace. Rápido y seguro análisis de venta. Oculto Procesos R1.7 Proveer un mecanismo de almacenamiento persistente Categoría Evidente Evidente Evidente Oculto Oculto Evidente Oculto. R2.4 Registrar los pagos del crédito a un sistema de contabilidad Evidente Evidente Evidente Oculto Casos de Usos: descripción de un proceso.6 El cajero se debe conectar con un ID y password para utilizar el sistema R1. plataformas. Ref.9 Presentar la descripción y precio del item registrado Oculto Funciones de Pago R2. tales cómo. Funciones básicas del sistema POST Ejemplo representativo.8 Proveer mecanismos de comunicación Inter. Función # R1.5 Poner en la bitácora venta completada R1. una secuencia de eventos. se debe ejecutar y no visible para usuario R1.2 Manipular los pagos a crédito. Sistema e Inter. costo de la venta al detalle. es decir: Rápido verificación para el cliente.3 Capturar la información del item comprado desde un código de barra. necesarias para producir algo de valor para una organización o actor. tales cómo autorización de pagos a crédito. acciones y transacciones.2 Calcular el total de la venta actual. el objetivo es incrementar la automatización de caja.4 Reducir las cantidades de inventario cuando la venta es comprometida R1. desde su inicio hasta su final. capturando la información del crédito desde la tarjeta de crédito o por una entrada manual. para un soporte más rápido. no exhaustivo.3 Manipular los pagos con cheque. incluyendo IVA y descuentos R1. y autorizar el pago con una autorización externa vía una conexión MODEM. capturando la información desde carné identidad por una entrada manual. tolerante a fallo. características de la interfaz. fácil de usar. Automatizar el control de inventario. etc. R2. o la entrada manual del código de producto universal (UPC) R1. Atributos del sistema: son las cualidades no funcionales del sistema. Oscar Saavedra Rodríguez 32 .1 Registrar la venta actual (en ejecución) – los items comprados R1. tiempo de respuesta.1 Manipular los pagos en efectivos.

6.2. balance. Un caso de uso es un documento narrativo que describe la secuencia de eventos de un actor (un agente externo) utilizando un sistema para completar un proceso. transacción de venta en ejecución. 9. el cajero entrara la agrega la información del item a la cantidad también. R1. R1.1. Referen. Registra la venta terminada. El cajero registra el identificador de cada item. Profesor.7. El cliente entrega el pago en efectivo. Tipo: primario y esencial. 8. 12. 2. Una vez completado. Determina los precios de los items y Si hay más de uno del mismo item. el cajero indica a la 5. el cliente sale con los items. Muestra el resultado (balance) el vuelto para el cliente. 10. 7. Propósito: Capturar una venta y su pago al contado. El cliente sale con los items comprados. Completado la entrada del item. Curso típico de eventos Acción Actor Respuesta Sistema 1. Genera una boleta. posiblemente más que el total.3. R1. Cruzadas: Funciones R1. El cajero registra la cantidad recibida. Oscar Saavedra Rodríguez 33 . 4. Visión general: Un cliente llega a la caja con los items a comprar.Retirar efectivo de un ATM Ordenar un producto Registrarse en las asignaturas en un colegio Chequear la ortografía de un documento en un procesador de texto Hacer una llamada telefónica. el cliente sale con los items. El cajero deposita el efectivo recibido y extrae su propio 11. El cajero informa al cliente el total. Caso de uso expandido Caso de Uso: Compra de items al contado Actores: Cliente (inicia). R1. Calcula y presenta el total de la venta. Se presenta la descripción y el precio de item actual. El cajero registra los items comprados y recibe el pago. El cajero entrega el vuelto y la boleta impresa al cliente.9. Caso de uso de alto nivel Caso de Uso: Compra de items Actores: Cliente. R2. El cajero registra los items a comprar y recibe un pago al contado. cajero Tipo: primario Descripción: Un cliente llega a una caja con items a comprar. POST que la entrada del item se ha terminado. Permite comprender mejor los requerimientos del sistema. cajero.1. Este caso de uso comienza cuando un cliente llega a una caja POST con los items a comprar. Una vez completado. 3.

El propósito de este diagrama es presentar un diagrama de contexto para comprender los actores externos de un sistema y la manera en la cual ellos lo utilizan. Indicar error. Diagramas de caso de uso Ilustra un conjunto de casos de uso del sistema. Verificar que todas las funciones han sido asignadas: Las funciones del sistema.Cursos alternativos: Línea 2: entrada de un identificador invalido. Vía la sección de referencia cruzada de un caso de uso. Por cada actor. Las líneas indican un flujo de información o un estimulo. Línea 7: el cliente no tiene dinero suficiente. Cancelar la transacción de ventas. Oscar Saavedra Rodríguez 34 . Para nombrar un caso de uso: comenzar con un verbo para enfatizar que es un proceso. Un caso de uso puede contener puntos de decisión. Comprar item. Métodos para identificar Casos de Usos Basado en actores Identificar los actores relacionados con un sistema u organización. identificadas en la especificación de requerimientos deben ser asignadas a un caso de uso. el cliente tiene la opción de pagar al contado. Relacionar los eventos a actores y casos de usos. Profesor. y la relación entre los actores y casos de usos. los actores. a crédito o con cheque. Por ejemplo. Basado en eventos Identificar los eventos externos a los cuales el sistema debe responder. identificar los procesos que ellos inician o participan.

POST que la entrada del item se ha terminado. El cliente entrega el pago en efectivo. 11. El cajero deposita el efectivo recibido y extrae su propio balance. 2. Registra venta terminada. Completado la entrada del item. 9. Si es pago a crédito. ver sección Pago Contado. 4. 3. Genera una boleta. Se presenta la descripción y el precio de item actual. el cajero entrara la agrega la información del item a la cantidad también. 4. ver sección Pago con Cheque. posiblemente más que el total. Caso de Uso: Pago Contado Curso típico de eventos Acción Actor Respuesta Sistema 1. 10. 7. El cajero registra la cantidad recibida. transacción de venta en ejecución. 6. El cajero informa al cliente el total. Profesor.Caso de Uso: Compra de items Acción Actor Respuesta Sistema 1. Muestra el resultado (balance) el vuelto para el cliente. El cliente sale con los items comprados. el cajero indica a la 5. Este caso de uso comienza cuando un cliente llega a una caja POST con los items a comprar. Calcula y presenta el total de la venta. 5. Oscar Saavedra Rodríguez 35 . Determina los precios de los items y Si hay más de uno del mismo item. Si es pago con cheque. 2. El cajero registra el identificador de cada item. 3.El cajero entrega el vuelto.El cliente elige el tipo de pago: Si es pago contado. 8. ver sección Pago a Crédito. El cajero da la boleta al cliente.

Caso de Uso: Pago Crédito Curso típico de eventos Acción Actor Respuesta Sistema 1. Los casos de usos se pueden ir refinando a medida que se avanza en el proceso de desarrollo del sistema de información. Cursos alternativos: Línea 2: El requerimiento de crédito es denegado por el CAS. o consulta al cliente para un pago más cerca de la venta total. 2. Oscar Saavedra Rodríguez 36 . Sugiere un método diferente de pago. El cajero llama al supervisor. crédito y lo envía a un Servicio de Autorización de Crédito externo. Genera un requerimiento de pago a pago a crédito.Cursos alternativos: Línea 1: Fondos insuficientes para dar el vuelto al cliente. El Servicio de Autorización de Crédito autoriza el pago. El cliente comunica su información de crédito para el 2. Profesor. Recibe un respuesta de aprobación de crédito desde el Servicio de Autorización de Crédito (CAS) POST registra el pago a crédito y la información de aprobación de crédito para el sistema de Contabilidad. Despliega el mensaje de autorización exitoso.

El modelo conceptual se representa por un Diagrama de Estructura Estático en el cual no se definen las operaciones. asociaciones entre objetos y atributos de los objetos. Profesor. Desde la lista de categoría de conceptos y el análisis de sustantivos en los Casos de Uso.Diagrama de Caso de Uso: Sistema POST Modelo Conceptual En la fase de análisis o investigación del sistema se representa el dominio del problema en base a conceptos u objetos. Oscar Saavedra Rodríguez 37 .

8. Completado la entrada del item. Muestra el resultado (balance) el vuelto para el cliente. 9. el cajero entrara la cantidad también. 12. POST que la entrada del item se ha terminado. 7. El cliente sale con los items comprados. Oscar Saavedra Rodríguez 38 . El cajero entrega el vuelto y la boleta impresa al cliente. 6. posiblemente más que el total.Caso de Uso: Compra de items Curso típico de eventos Acción Actor 1. Registra la venta terminada. POST Item Tienda Venta Línea detalle Vendedor Cliente Administrador Pago Catalogo Producto Especificación Producto Profesor. Determina los precios de los items y agrega la información del item a la transacción de venta en ejecución. 4. Si hay más de uno del mismo item. Calcula y presenta el total de la venta. El cajero informa al cliente el total. 10. balance. 2. El cajero deposita el efectivo recibido y extrae su propio 11. el cajero indica a la 5. Este caso de uso comienza cuando un cliente llega a una caja POST con los items a comprar. El cliente entrega el pago en efectivo. Se presenta la descripción y el precio de item actual. Genera una boleta. El cajero registra la cantidad recibida. Respuesta Sistema 3. El cajero (Vendedor) registra el identificador (UPC) de cada item.

Usos de los Diagramas de Objetos Profesor. Modelan las instancias de los elementos que se encuentran contenidas en los diagramas de clases.Diagramas de Objetos Los diagramas de objetos son representaciones gráficas que muestran un conjunto de objetos y sus relaciones en un momento concreto. Oscar Saavedra Rodríguez 39 .

Mostrar las instancias de asociaciones entre los objetos participantes. se conocen como colaboraciones. Mostrar el estado y los valores de los atributos de cada uno de los objetos participantes en el escenario escogido para poder tener una mejor comprensión de éste. Por lo tanto. con la expectativa que desencadenará una actividad. representando una escena fija de la interacción entre los elementos del sistema de información. 5. los diagramas de objetos también pueden presentar paquetes que faciliten la disposición de los elementos del sistema en unidades organizadas más grandes. por lo tanto. sus vecinos y sus relaciones con éstos en dicho momento.3 Diagrama de Interacción Una interacción es un comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de objetos dentro de un contexto para lograr un propósito. desde una perspectiva de instancias reales o prototípicas. El modelado de estructuras en un diagrama de objetos implica tomar una fotografía instantánea del sistema. tomando una vista del sistema en un momento determinado. Por otra parte. lo cual facilita la comprensión de un sistema complejo al considerar determinados. y sustentada en los requerimientos funcionales del sistema. un diagrama de objetos congela un instante en el tiempo para visualizar el sistema. determinando los objetos y asociaciones relevantes de la instantánea que se desea tomar del sistema. los objetos que interactúan para la ejecución de alguna tarea. se debe centrar el interés en los mensajes y los enlaces existentes entre los elementos que participan del comportamiento observado. Pasos para la Construcción de un Diagrama de Objetos Cuando se desea construir un diagrama de objetos se debe tener en cuenta que éste no permite representar el sistema en su totalidad. En la representación del comportamiento dinámico de un sistema. El aspecto estático de una interacción puede representarse por medio un diagrama de objetos. Considerar el escenario en el cual interviene el mecanismo a modelar en un momento del tiempo. Considerando esto. Oscar Saavedra Rodríguez 40 . Profesor. sino que sólo se pueden mostrar los conjuntos interesantes de objetos. para construir un diagrama de objetos se debe: Identificar el mecanismo que se desea modelar a partir del diagrama de clases representativo de la estructura estática del sistema. Sin embargo. Al igual que los diagramas de clases y de casos de uso. una interacción implica la realización de un comportamiento dinámico por parte de los componentes participantes de ella. junto con los enlaces entre ellos.Los diagramas de objetos se utilizan para modelar la vista de diseño estática o la vista de procesos estática de los objetos de un sistema. un mensaje es definido como la especificación de una comunicación entre objetos que transmite información.

Tal como ya se ha tratado, los enlaces son instancias de una asociación entre objetos, especificando el camino a lo largo del cual un objeto puede enviar un mensaje a otro objeto o a sí mismo. Cuando se recibe un mensaje, se lleva a cabo una instrucción ejecutable cuya acción puede producir un cambio de estado. Las acciones que se pueden modelar mediante UML son las siguientes: • Llamada. Invoca una operación sobre un objeto; un objeto puede enviarse un mensaje a sí mismo, lo que resulta en la invocación local de una operación. Gráficamente, se representa mediante una línea continua con punta de flecha cerrada rellena. Retorno. Devuelve un valor al invocador. Se representa mediante una línea discontinua con punta de flecha abierta. Envío. Envía una señal al objeto. Se representa mediante una línea continua con punta de flecha abierta. Creación. Crea un objeto. Es un mensaje estereotipado que puede representarse como una llamada o como un envío. Destrucción. Destruye un objeto; un objeto puede destruirse a sí mismo. Es un mensaje estereotipado que puede representarse como una llamada o como un envío.

• • • •

Los mensajes más comunes en un diagrama de interacción son los de llamada. Sin embargo, cuando se establece la invocación de una llamada no sólo debe estar definida la clase que recibe el mensaje, sino que la operación invocada debe ser visible para el invocador. Además, los mensajes que se envían a los objetos con el fin de invocar una operación deben contener los parámetros de la operación. Por lo tanto, el mensaje debe acarrear consigo la signatura de una operación para poder ser reconocida y validada por el objeto receptor del mensaje. El envío y recepción de mensajes entre objetos origina una secuencia de acciones que permite modelar el comportamiento del sistema, o bien, de una parte de él, lo que facilita la comprensión de los procedimientos involucrados para efectuar una operación. Toda secuencia tiene un comienzo en algún proceso, y continuará mientras el proceso que la contenga exista. Los diagramas de interacción muestran, tal como lo dice su nombre, una interacción entre un conjunto de objetos relacionados, los cuales se envían y reciben mensajes entre sí para llevar a cabo algún determinado proceso. Por lo tanto, los diagramas de interacción se utilizan para el modelado de los aspectos dinámicos de un sistema. De hecho, el representar los aspectos dinámicos del sistema o de una operación, permite modelar la realización de los casos de uso de un diagrama de casos de uso. Cuando se trata de representar la realización de un caso de uso a través de un diagrama de interacción, se contará con la presencia de los actores del caso de uso. Puede que haya varios actores, pero siempre habrá uno que da comienzo al caso de uso: el iniciador.

Profesor. Oscar Saavedra Rodríguez

41

Para la representación del comportamiento dinámico del sistema existen dos tipos de diagramas de interacción: diagramas de secuencia y diagramas de colaboración. 5.4 Diagrama de Secuencia Un diagrama de secuencia es un diagrama de interacción que se caracteriza por representar la ordenación temporal de los mensajes, mostrando los objetos y actores que participan de la colaboración. La representación gráfica de una interacción a través de un diagrama de secuencia especifica en primera instancia, el actor que inicia la interacción, seguido por el conjunto de objetos relacionados que enviarán y recibirán mensajes para realizar los procesos involucrados en la interacción. Cada objeto se encuentra sobre una línea vertical discontinua que representa la línea de vida del objeto, la cual se extiende desde la creación de éste hasta su destrucción. El transcurso del tiempo se mide verticalmente, a través de la línea de vida, desde el extremo superior hacia el extremo inferior. Horizontalmente se representan los mensajes emitidos desde un objeto hacia otro, ordenados temporalmente según su ocurrencia. Por otra parte, se encuentra el foco de control, representado por un rectángulo delgado ubicado por sobre la línea de vida del objeto, y representa el tiempo durante el cual un objeto efectúa una acción, ya sea directamente o por medio de un procedimiento subordinado. Además, un objeto puede enviarse mensajes a sí mismo para realizar determinadas operaciones, como son las operaciones privadas, lo cual se representa a través de un mensaje desde el objeto a sí mismo en un foco de control anidado. El foco de control anidado se representa también, por medio de un rectángulo estrecho sobrepuesto sobre el foco de control original del objeto y levemente desplazado hacia la derecha. En la metodología orientada a objetos, cada invocación corresponde a una llamada para realizar una operación es resultado de un mensaje previamente emitido por un objeto hacia otro, o hacia sí mismo. En gran cantidad de diagramas de secuencia, se establece la creación y eliminación de objetos. Para la creación de objetos, se envía un mensaje estereotipado que va desde el flujo de control del objeto emisor hasta la representación del objeto creado, y desde ese instante de tiempo, surge la línea de vida para el objeto creado. Análogamente, para la eliminación de un objeto, el emisor envía el mensaje con el estereotipo correspondiente hacia el extremo inferior de la línea de vida del objeto a eliminar, la cual concluye con una “X”.

Profesor. Oscar Saavedra Rodríguez

42

Figura 5.19a. Representación de un Diagrama de Secuencia.

O b j e to 2

O b j e to 3

A cto r

Cre a r

O b j e to 1

M e n sa j e d e l l a m a d a A u to i n vo ca ci o n

M e n sa j e d e l l a m a d a 2 Re to rn o M e n sa j e d e E n vío Re to rn o 2

De stru i r

Fuente: Elaboración Propia.

Figura 5.19b. Ejemplo de un Diagrama de Secuencia.
Interlocutor 1 Central Interlocutor 2

descolgar auricular

dar tono de llamada () marcar digito

enrutar llamada

crear conversacion

Conversacion llamar () descolgar auricular

conectar interlocutores conectar (interlocutor_1) conectar (interlocutor_2)

Fuente: Booch, Rubaugh, Jacobson; El Lenguaje Unificado de Modelado.
Profesor. Oscar Saavedra Rodríguez

43

Se debe establecer el escenario de la interacción. mientras que el resto mostrarán los caminos alternativos. distinguiendo cada diagrama de los demás por medio de un nombre característico.5 Diagrama de Colaboración Un diagrama de colaboración es un diagrama que destaca la organización de los objetos que participan en una interacción. Visualizar el anidamiento de mensajes o el intervalo de tiempo en el que tiene lugar la acción si es necesario. Ordenar los mensajes desde arriba hacia abajo partiendo por el mensaje iniciador de la secuencia hasta el mensaje que la termina. una clase o un escenario de un caso de uso. organizándolos de izquierda a derecha según el orden de emisión de los mensajes. Profesor.Una propiedad ventajosa de los diagramas de secuencia. 5. 4. una operación. especificar las restricciones de tiempo con las marcas pertinentes en los flujos de mensajes. es la ya mencionada capacidad para representar el paso del tiempo en forma gráfica. indicando dichos puntos en forma explícita. Sin embargo. 7. mostrando las propiedades de cada mensaje según sea necesario para explicar la semántica de la interacción. sus líneas de vida deben extenderse desde el momento de su creación hasta su eliminación dentro de la secuencia. se pueden utilizar paquetes para organizar una colección de diagramas de secuencia. 3. Se debe establecer la línea de vida de cada uno de los objetos. el inconveniente que esto representa es la medición de una escala de tiempo en la línea de vida de un objeto. Oscar Saavedra Rodríguez 44 . 2. especificar los flujos de control de un modo más formal. De ser necesario. Un único diagrama de secuencia sólo puede mostrar un flujo de control. permiten representar restricciones de tiempo para el desarrollo de determinados procesos que el sistema debe satisfacer. Se debe establecer el contexto de la interacción. subsistema. donde algunos de los cuales serán los principales. ya sea un sistema. por lo tanto se deben realizar varios diagramas de interacción. y por lo tanto. • Para realizar un flujo de control por ordenación temporal o cualquier tipo de diagrama de secuencia se debe tener en consideración los siguientes aspectos: 1. La representación de restricciones y sincronización en diagramas en UML se puede hacer de dos maneras: • Dejar que las líneas de vida representen el tiempo real y la distancia entre mensajes indique la duración del proceso u operación. De ser necesario. Escribir restricciones de sincronismo en el diagrama en función de los nombres de los mensajes involucrados. Para el caso de los objetos creados y destruidos en la interacción. Por otra parte. 5. identificando los objetos que participan de ella. 6.

especificar los flujos de control de un modo más formal.1 es el primer mensaje del primer mensaje. 1. Si los valores de los atributos. los valores etiquetados. Se puede utilizar una numeración secuencial regular (1. los elementos que participan en una colaboración. Comenzando por el mensaje que inicia la interacción. 3. los enlaces pueden contener más de un mensaje. La numeración para mensajes anidados se puede dar hasta cualquier nivel de profundidad. se pueden utilizar estereotipos de camino como un enlace. Profesor. 2.Los diagramas de colaboración representan. una clase o un escenario de un caso de uso. Los diagramas de colaboración permiten representar flujos más complejos que impliquen iteraciones y bifurcaciones. se debe colocar un objeto duplicado en el diagrama. subsistema. Sin embargo. una operación. De ser necesario. De ser necesario. Se debe establecer el contexto de la interacción. el estado o el rol de algún objeto cambia de forma significativa durante la interacción. 3. Estos números preceden al mensaje e incrementan secuencialmente por cada nuevo mensaje en el flujo de control. Los diagramas de colaboración tienen dos características que los diferencian de los diagramas de secuencia: • • Para indicar como se enlaza un objeto a otro.). Para realizar un flujo de control por organización o cualquier tipo de diagrama de colaboración se debe tener en consideración los siguientes aspectos: 1. actualizarlo con los nuevos valores y conectarlo con un mensaje estereotipado. identificando los objetos que participan de ella. . 5.. 6. organizándolos de izquierda a derecha según el orden de emisión de los mensajes.. 7. especificar las restricciones de tiempo con las marcas pertinentes en los flujos de mensajes. al igual que en los diagramas de secuencia. en vez de representar una secuencia de procesos. Se debe establecer las propiedades iniciales de cada uno de los objetos. etc. Se debe especificar los enlaces entre los objetos junto con los mensajes que se pueden traspasar. se debe asociar cada mensaje subsiguiente al enlace apropiado. estableciendo el número de secuencia correspondiente. ya sea un sistema. En un diagrama de colaboración. 4. los diagramas de colaboración presentan los enlaces existentes entre los objetos participantes adornados con los mensajes enviados y recibidos entre ellos.). o bien la numeración del sistema decimal de Dewey que facilita la representación de mensajes anidados (1 es el primer mensaje. Para indicar la ordenación temporal de los mensajes se utilizan números de secuencia. Se debe establecer el escenario de la interacción. cada uno con un número de secuencia único. 2. Oscar Saavedra Rodríguez 45 .

dado que ambos derivan de un mismo metamodelo de UML. ambos diagramas comparten el mismo modelo subyacente. donde algunos de los cuales serán los principales. Equivalencia Semántica Los diagramas de secuencia y de colaboración son semánticamente equivalentes. mientras que el resto mostrarán los caminos alternativos. pero cada uno puede representar cosas que el otro no puede. No obstante. se puede construir uno de ellos a partir del otro sin perder información. Tal como se acaba de mencionar. es decir. la equivalencia semántica no implica que ambos diagramas visualicen la misma información de forma explícita. distinguiendo cada diagrama de los demás por medio de un nombre característico. Oscar Saavedra Rodríguez 46 .Al igual que en los diagramas de secuencia. Por otra parte. se pueden utilizar paquetes para organizar una colección de diagramas de secuencia. por lo tanto se deben realizar varios diagramas de interacción. un único diagrama de colaboración sólo puede mostrar un flujo de control. Profesor.

Pero además de eso. contempla todas las actividades necesarias para transformar los requisitos de usuario en sistema software. es conocido como el Proceso Unificado de Desarrollo. UML se ha aplicado para el proceso de construcción e implementación de sistemas de gestión y aplicaciones en general. Este nuevo paradigma o metodología. y a través de la secuencia de modelos utilizados en cada flujo de trabajo. elaboración. diseñar. Profesor. el proceso unificado es un marco de trabajo genérico que puede especializarse para una gran variedad de sistemas. los equipos a cargo del desarrollo del sistema de información pueden descomponer el trabajo en iteraciones. • Es iterativo e incremental. el cual se determina por la disponibilidad de un conjunto de modelos y documentos que han sido desarrollados para alcanzar en determinado estado del proceso completo. que si bien no es perfecto. y no convertirse en una herramienta de apoyo para el corto plazo.6. el Proceso Unificado se lleva a cabo mediante tres características primordiales que lo hacen único. y como tal. el producto terminado debe ajustarse tanto a las necesidades de los usuarios. El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. De esta forma. Por lo tanto. El Proceso Unificado es un proceso de desarrollo de software. ha probado ser el más eficiente dentro los existentes. El Proceso Unificado de Desarrollo El modelado visual de sistemas a través de un lenguaje más amplio y estándar como es UML. donde al final de cada ciclo se obtiene una versión del producto para los clientes. como a las de todas aquellas personas que trabajarán con el sistema. Sin embargo. Dentro de cada fase. aportando un nuevo paradigma. que considera las diversas etapas desde la captura de requisitos del cliente hasta la implementación. sobre todo si se trata de sistemas centrados en un enfoque orientado a objetos. ha permitido abarcar un mismo problema desde diversas perspectivas interrelacionadas. para diferentes áreas de aplicación. se puede visualizar lo que está sucediendo en cada fase. diferentes tipos de organizaciones. se encuentra basado en componentes interconectados por medio de interfaces bien definidas. El Proceso Unificado se centra en la utilización de UML para la preparación de todos los esquemas del sistema que se desea analizar. construir e implementar. donde cada una de ellas responde a un aspecto de análisis particular. construcción y transición. • Está centrado en la arquitectura. diferentes niveles aptitud y diferentes y tamaños de proyecto. flexible y eficiente: • Está dirigido por casos de uso. Cada ciclo del Proceso unificado se desarrolla a lo largo del tiempo. el cual se divide en cuatro fases: inicio. Además de permitir abarcar los aspectos de análisis y diseño. Oscar Saavedra Rodríguez 47 . De este modo. así como ser flexible ante futuras necesidades que se puedan presentar con el fin de perdurar en el tiempo. Cada fase concluye con un hito.

a través de la utilización el Enfoque Sistémico. buscan determinar los siguientes aspectos: • • Las principales funciones del sistema para sus usuarios más importantes. la visión y el posicionamiento de la organización en su entorno. Por medio de la relación estructura existente en la organización. viable y dinámico. abierto.Figura 5. Cada iteración se considera como un pequeño proyecto inserto en el proyecto total. Oscar Saavedra Rodríguez . Fuente: website European Instute for Research and Strategic Studies in Telecomunications.31. El estudio preliminar de la organización y la definición de los límites del sistema de información a desarrollar. La posible arquitectura del sistema. Flujos de Trabajo e Iteraciones en el Proceso Unificado. haciendo que los procesos de negocio internos de la organización sean de carácter fundamental en el estudio del sistema de información a desarrollar. se debe estudiar los flujos de información internos y con el entorno para determinar cómo estos flujos y los procesos internos apoyan el proceso de toma de decisiones.31 se pueden apreciar los diferentes flujos de trabajo (captura de requisitos. Esquema de Fases. 48 Profesor. análisis. diseño. implementación y pruebas) que intervienen en cada iteración de las fases a lo largo del tiempo. Durante la fase de inicio se efectúa un estudio integral de la organización como un sistema social. la cual pasa por todos los flujos de trabajo. con el fin de determinar y/o estudiar sus estrategias y su relación con la estructura organizacional adoptada. En la figura 5. Las curvas son una aproximación de hasta dónde se llevan a cabo los flujos de trabajo en cada fase. Este conocimiento integral de la organización requiere de un análisis estratégico previo que tome en cuenta la misión. y la realización de un análisis interno y externo de ésta.

La fase de transición abarca la fabricación del producto. es decir. cada una de gran importancia para el desarrollo del sistema. Los esfuerzos de las personas involucradas en el proyecto son guiados durante todo el proceso de desarrollo a través de cada fase. y la utilización del sistema. pero esta vez. ya que de ellas depende el financiamiento. la mayoría de los recursos se utiliza en esta fase. las gestiones. Por lo tanto. una versión Beta. aunque la arquitectura del sistema es estable. En 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 del sistema. El resultado de esta fase es la línea base de la arquitectura. pero los cambios en la arquitectura se hacen mínimos. aplicándolos al Enfoque de Base de Datos. Para llevar a cabo esta etapa se toman en consideración todos los aspectos abarcados por medio del análisis orientado a objetos de la etapa anterior. pero que no se encuentra necesariamente libre de defectos. En la versión Beta. la cual corresponderá al esqueleto del sistema que se está desarrollando. La línea base de la arquitectura crece hasta convertirse en el sistema completo. Profesor. No obstante. operacional. los desarrolladores pueden encontrar mejores formas de estructurar el sistema. se requiere de distintos equipos a cargo de tareas particulares. el proporcionar una línea de ayuda y asistencia. Oscar Saavedra Rodríguez 49 . En la fase de construcción se crea el producto. El resultado es un producto que cumple con todos los requerimientos solicitados. Las Cuatro “P” del Proceso Unificado de Desarrollo El Proceso Unificado entrega como resultado final un producto. en un producto preparado para ser entregado a la comunidad de usuarios. 7. legal. por lo que no representa un inconveniente para el cumplimiento de plazos durante el desarrollo. financiera y económica. y la corrección de defectos finales. capaz de realizar los requerimientos básicos especificados al inicio del desarrollo. el cual va tomando forma durante su desarrollo gracias a la intervención de distintos tipo de personas que juegan un rol importante en cada una de las etapas y flujos de trabajo. la planificación del proyecto de desarrollo. las pruebas. Estas fallas son corregidas por los desarrolladores y se incorporan algunas nuevas mejoras sugeridas en una nueva versión dirigida a la totalidad de la comunidad de usuarios. y por lo tanto. Las personas son decisivas. La fase de transición cubre el período en el cual el producto se convierte en lo que se denomina. la formación del cliente. un número reducido de usuarios con experiencia prueba el producto e informa los defectos y deficiencias que el sistema aún pudiese presentar. basados en estudios de evaluación técnica. Personas Personas corresponden a los principales autores de un proyecto de desarrollo de sistemas de información.• El plan del proyecto y el costo del desarrollo del producto.

A través de su ciclo de vida. por lo que puede considerarse como un miniproyecto que entrega una nueva versión del producto. iteración y fase. El equipo a cargo de un proyecto también debe preocuparse del patrón organizativo del mismo. permite que cada grupo de personas involucrado en los flujos de trabajo estructure sus funciones y responsabilidades en el conjunto de diagramas o vista que englobe su perspectiva. además de los diferentes diagramas implicados según la perspectiva de trabajo de cada flujo de trabajo. la estructura de los equipos de trabajo. la planificación global del proyecto y la facilidad de comprensión del proyecto. la gestión del riesgo. La existencia de diversos trabajadores. un sistema contiene. usuarios u otros sistemas. De acuerdo con esto. deben preocuparse de cada iteración y los casos de uso que se implementan en cada una de ellas con el fin de atenuar cada vez más los riesgos del proyecto. Durante el desarrollo de un proyecto de este tipo. y por lo tanto hace referencia al sistema completo y no sólo a la generación de un código fuente. Profesor. ya sean trabajadores. las personas son un recurso valioso en cualquier tarea. Proyectos Un proyecto entrega como resultado. tanto desde la captura y análisis de requisitos. La construcción del sistema va a estar centrada en los distintos diagramas que se desarrollen. tomando en cuenta las restricciones del negocio. el equipo de proyecto debe preocuparse de las secuencias de cambio que ocurren al concluir cada flujo de trabajo. siendo responsables de un conjunto de actividades necesarias para el desarrollo del subsistema. hasta los diagramas de implementación 3 . Producto En el contexto del Proceso Unificado. Cada iteración debe pasar por los cinco flujos de trabajo. las personas participan como trabajadores durante el desempeño de las diferentes tareas en los flujos de trabajo. 3 Diagramas de componentes y de despliegue. permitiendo la representación estructural y de comportamiento del sistema. una nueva versión del producto. Por otra parte. también cubre las relaciones y restricciones entre tales diagramas. las cuales abarcan el tiempo. Por otra parte. el sistema en desarrollo va a estar compuesto por todos los artefactos o diagramas necesarios para representarlo de un modo comprensible para todos los actores que interactuarán con el sistema. el producto que se obtiene es un sistema software. Oscar Saavedra Rodríguez 50 . por lo que se establecen las diferentes colaboraciones entre diagramas.El desempeño de las personas en un proyecto de desarrollo de software va a depender de la viabilidad del proyecto. los costos y la calidad requerida en el producto.

hay un elemento clave que debe ser mencionado. Sin embargo. se hace imperativamente necesario comprender qué es lo que los futuros usuarios necesitan y desean de un sistema de Profesor. y para convertir los cambios sobre esos requisitos en un nuevo conjunto consistente de artefactos. cualquier tipo de aplicación. Por lo tanto. así como no se puede esperar que las herramientas desarrolladas resulten estar sobredimensionadas frente a un proceso de desarrollo que no es completo. un proyecto es una instancia de proceso.1 El Proceso Unificado Dirigido por Casos de Uso Los sistemas de gestión y en general. tanto en el uso de los recursos como en la gestión del mismo proyecto. Contar con herramientas que soporten los procesos se ha vuelto un aspecto que no puede ser dejado de lado. no se puede tener éxito en el desarrollo de sistemas con herramientas que no son lo suficientemente robustas para soportar el proceso. Oscar Saavedra Rodríguez 51 . De este modo. ya que a partir de estas tareas se van desprendiendo los demás procesos. UML como un lenguaje estándar de modelado. automatizando procesos repetitivos. En un proyecto de este tipo. haciendo una analogía con las clases. que consisten en herramientas de modelado visual para apoyar los procesos de Ingeniería de Software. a esto se suma el uso de tecnologías CASE. 7. de una forma más eficaz y eficiente. la captura y análisis de requisitos es de vital importancia. proceso de desarrollo de software es una definición de un conjunto completo de actividades necesarias para convertir los requisitos de usuario en un conjunto consistente de artefactos que conforman un producto software. Por lo tanto. actúan como una guía a lo largo de un camino de desarrollo concreto. permite organizar el conjunto de actividades relacionadas en flujos de trabajo encargados de desarrollar una perspectiva particular del todo. tal como ya se ha mencionado. apoyar al proceso de toma de decisiones de una organización. ya que permiten que los procesos se lleven a cabo de forma más expedita. dado que son de vital apoyo para el proceso durante todas sus etapas: las herramientas. y además. permiten mantener un orden de las cosas. el término proceso se refiere a los procesos de negocios claves par una empresa de desarrollo de sistemas de gestión y de aplicaciones software en general.Proceso En el contexto del Proceso Unificado. El proceso de desarrollo en sí. una cabal comprensión de los requisitos permite agregar una mayor cantidad de valor al producto final: el sistema. y entregar información que permita una mayor y mejor comprensión del dominio del problema. El desarrollo exitoso de herramientas no puede hacerse sin el desarrollo paralelo de un marco de trabajo de proceso en el cual vayan a funcionar las herramientas. Sin embargo. se desarrollan para entregar un servicio al usuario. permiten gestionar grandes cantidades de información. El término proceso hace referencia a un contexto que sirve como plantilla que puede reutilizarse para crear instancias de ellas. ya es una poderosa herramienta para realizar las actividades de análisis y diseño. y en el presente caso.

centrándose en el valor agregado para el usuario. como pueden ser requisitos de rendimiento. A través de los casos de uso se capturan todos los requisitos funcionales del sistema que agreguen valor para el usuario. La Captura de los Casos de Uso El modelo de casos de uso ayuda al cliente. De esta forma se va desarrollando paso a paso un sistema que va creciendo gradualmente hasta llegar al sistema completo que conforma el producto final. se utilizan los diagramas de interacción para modelar el aspecto dinámico del sistema. a los usuarios y a los desarrolladores a llegar a un acuerdo sobre cómo utilizar el sistema. Estos tipos de usuarios. y dirigen todo el proceso de desarrollo. Los casos de uso también pueden ser utilizados para especificar requisitos no funcionales del sistema. Por ende. Una vez que se han capturado y descrito los casos de uso identificados. se proponen posibles clasificadores. los cuales pueden ser humanos o no humanos. Diseño e Implementación para Realizar los Casos de Uso Durante el análisis y diseño. Sin embargo. se van detallando casos de uso más específicos que permiten que el sistema crezca en funcionalidad acercándose al producto final. la captura de requisitos debe cumplir con encontrar los requisitos que añadan valor y representarlos de un modo adecuado para los usuarios. lo cual lleva a delimitar el alcance del sistema. también conocido como el dominio del problema – solución. disponibilidad o seguridad. Como es de esperarse. Profesor. La identificación de los clasificadores y sus relaciones permite determinar la estructura del sistema en desarrollo. Oscar Saavedra Rodríguez 52 . así como para reutilizar los ya existentes. pero además. debido a que proporcionan un medio sistemático e intuitivo de captura de los requisitos funcionales. En la medida que se va avanzando a través de las fases del Proceso Unificado por medio de la realización de las iteraciones. la mayoría de los sistemas tiene muchos tipos de usuarios que lo utilizan y que interactúan con él. Para esto se utilizan los casos de uso. tal como ya se mencionó anteriormente. En la medida que se avanza en las iteraciones. Análisis. la cual contiene una estructura de clasificadores y realizaciones de casos de uso. representando los enlaces entre los objetos participantes de un proceso que el sistema debe llevar a cabo. se transforma el diagrama de casos de uso mediante un diagrama de análisis en un diagrama de diseño. la arquitectura ya creada sirve de apoyo para la identificación de nuevos clasificadores.información. pero que cumplen un rol con el sistema en cuestión a través del envío y recepción de mensajes. Esto último se debe a que los flujos de trabajo que comprenden el análisis. se representan por medio de actores. sus responsabilidades y sus relaciones necesarias para llevar a cabo el caso de uso. diseño y prueba se llevan a cabo a partir de los casos de usos que representan la captura de requisitos. clientes y desarrolladores.

los cuales se ordenan según prioridad y se corrigen por orden de importancia. Un procedimiento de prueba es una especificación de cómo llevar a cabo la preparación. se recomienda agruparlas coherentemente en subsistemas. Los subsistemas se representarán mediante paquetes. o bien. se establecen clases de implementación e interfaces que permiten la realización de operaciones definidas para satisfacer los requisitos de información del cliente. los desarrolladores deben establecer los roles de los clasificadores en el sistema para establecer un grupo consistente de responsabilidades ante las cuales el sistema debe responder. Profesor. condiciones de ejecución y resultados esperados. Oscar Saavedra Rodríguez 53 . se continúa con la elaboración del modelo de diseño. el desarrollador a cargo debe asegurarse que la nueva clase cumple con las responsabilidades establecidas y es capaz de realizar el caso de uso asociado. Un caso de prueba es un conjunto de entradas de prueba. el cual abarca el ámbito físico del aspecto lógico ya desarrollado. en la cual se verifica que las instancias de las clases participantes realizan el caso de uso según lo especificado. Para ello se desarrolla un modelo de prueba que está formado por casos de prueba y procedimientos de prueba. éstos son analizados para localizar los problemas. Ambos conceptos pueden derivarse de un caso de uso con propósitos de verificación de cumplimiento de requisitos. de modo que el sistema no pierda comprensibilidad para los clientes.Para asegurar un buen cumplimiento de requisitos por parte del sistema. Las pruebas de los casos de uso pueden llevarse a cabo desde la perspectiva de una actor que aborda el sistema como una caja negra. Una vez realizadas las pruebas y hallados los defectos si es que los hubiere. Para ello se establecen los diagramas de componentes y de despliegue que permiten llevar el sistema al “mundo real”. Prueba de los Casos de Uso Durante las pruebas se verifica que el sistema implementa correctamente las especificaciones. Cuando se tienen demasiadas clases de implementación en el modelo. desarrollado para un objetivo concreto. Habiendo definido el modelo de diseño. desde la perspectiva de diseño. usuarios y desarrolladores. ejecución y evaluación de los resultados de un caso de prueba particular. Por lo tanto. Ya establecido el modelo de análisis mediante los diagramas ya mencionados. el cual funciona como esquema para la implementación. Si se cambia un clasificador. se establece el modelo de implementación.

construido e implementado. tanto los sistemas desarrollados como aquellos en desarrollo pueden evolucionar en sistemas más grandes y complejos con el fin de cumplir con los requisitos de los clientes y usuarios en un entorno constantemente cambiante. fomento de la reutilización. además que va acompañado de una reducción de costos. los diferentes diagramas que proporciona UML permiten representar las diversas perspectivas que el análisis y diseño de un sistema abarca. Sin embargo. La arquitectura está condicionada por los casos de uso que son deseados para soportar el sistema. así como a los diversos usuarios con el fin de facilitar su participación a lo largo de la duración del proyecto. mayor es la sobrecarga de comunicación existente entre los desarrolladores para intentar coordinar sus esfuerzos. evolución del sistema. y no tener que reconstruir el sistema completo desde cero. La correcta comprensión del sistema por parte de los desarrolladores para llevar a cabo las tareas de un proyecto de desarrollo de sistema se debe a que los sistemas abarcan un comportamiento complejo. realizando pequeñas modificaciones y pruebas.7. Profesor. el desarrollo debe incorporar a todos los trabajadores que intervienen en los distintos flujos de trabajo. y con un grupo responsable de cada subsistema. La existencia de una arquitectura es vital para llevar a cabo cuatro aspectos fundamentales: comprensión el sistema. De este modo. el hacer uso de técnica común requiere de un conocimiento acabado del dominio del problema por parte de los desarrolladores. haciendo que el contacto sea más eficiente para que los desarrolladores puedan saber qué están haciendo los otros equipos. El desarrollo de un sistema puede llegar a ser muy complejo y tomar un largo período de tiempo en ser diseñado. organización del desarrollo. el proceso de desarrollo debe ser capaz de proveer una arquitectura flexible para poder soportar los cambios. al igual que los entornos en los que operan y las tecnologías utilizadas en su desarrollo. Es por esto que la utilización de partes de sistemas similares previamente realizados es de gran ayuda para la agilización del proceso de desarrollo. cada uno de los cuales entrega información relevante para llevar a cabo el proceso de desarrollo en cada una de sus fases y flujos de trabajo. Para esto se debe organizar el desarrollo del sistema en subsistemas adecuadamente conectados por medio de interfaces claramente definidas. haciendo que los casos de uso se conviertan en los directores de la arquitectura que se diseñará para el sistema a implementar en cada una de las iteraciones de cada fase.2 El Proceso Unificado Centrado en la Arquitectura En el Proceso Unificado. pueden presentarse distribuidos físicamente en lugares muy apartados y deben operar en forma eficiente. lo cual permite aligerar la sobrecarga comunicacional. Mientras mayor sea la organización del proyecto. Oscar Saavedra Rodríguez 54 . Por otra parte. la arquitectura de un sistema se ve cubierta por cada uno de los diversos puntos de vista. Por lo tanto. deben satisfacer las demandas individuales de los usuarios y de la organización. Por lo tanto.

principalmente en las primeras iteraciones. Una vez desarrollada la capa general. especificación y diseño de Profesor. se van agregando las demás capas que implementan los casos de uso más específicos del sistema. ya que el cómo se ha desarrollado cada una de las iteraciones previas. para poder efectuar correcciones y continuar con el siguiente miniproyecto en forma gradual. en las siguiente iteraciones y fases. En una iteración. las necesidades de distribución en el despliegue del sistema. El jefe de proyecto se verá forzado a efectuar una reasignación de recursos que permita resolver los problemas antes que el trabajo pueda continuar. lo cual se va llevando a cabo de forma más expedita debido al conocimiento adquirido de la arquitectura del sistema en las iteraciones anteriores. las cuales se extienden desde aquellas más generales en cuanto al dominio del sistema y que buscan la realización de los casos de uso fundamentales del sistema. Esto va acompañado del análisis. permiten que la arquitectura que se va construyendo para soportar al sistema adquiera un carácter robusto. aportando un incremento en el desarrollo del sistema y una reducción de los riesgos con que se relaciona cada flujo de trabajo. a hacer el seguimiento y a controlar el proyecto. donde se establece la línea base que sostendrá al sistema. Una vez alcanzada una arquitectura estable. los requisitos no funcionales. así como permite especificar. hasta las capas más específicas. como son los sistemas operativos o los sistemas de gestión de bases de datos. lo que permite finalizar en el desarrollo de un producto entregable a clientes y usuarios y que es capaz de cumplir con todos los requisitos de éstos. Oscar Saavedra Rodríguez 55 . diseñar. Cada paso iterativo del proceso es dependiente del anterior. sino que también debe considerar los productos software sobre los cuales se desarrollará el sistema. Las iteraciones ayudan a la dirección a planificar. a organizar. probar y ejecutar un poco en cada iteración.3 El Proceso Unificado Iterativo e Incremental El desarrollo de sistemas de gestión a través de pequeños pasos facilita la planificación del proyecto. integrar. lo cual da a conocer riesgos del proyecto que pueden tener efectos mayores si no son controlados previamente.Sin embargo. los sistemas heredados que se quieran utilizar en el nuevo sistema. 7. implementar. lo que genera un crecimiento gradual de los subsistemas elaborados. la arquitectura no sólo está condicionada por los casos de uso significativos. La reducción de riesgos y los incrementos logrados en cada iteración. Permite obtener suficiente retroalimentación de cómo se ha realizado este miniproyecto. estándares y políticas corporativas. La elaboración de la arquitectura del sistema se va construyendo mediante lo que se puede denominar como capas. se puede implementar el resto de las funcionalidades realizando el resto de los casos de uso durante la fase de construcción. por lo que se requiere compatibilidad para que la nueva arquitectura encaje con el producto antiguo. los mayores problemas que se pueden presentar durante la integración y las pruebas. determina las capas arquitectónicas sobre las cuales evoluciona el sistema.

evitan bruscos retrocesos en el avance del proyecto en sí. además de cubrir o aminorar los riesgos inherentes de cada etapa. aunque los más importantes son los riesgos relativos a la arquitectura. Los riesgos relativos a la arquitectura están basados en una selección no adecuada de los casos de usos que se utilizarán en la definición de la estructura del sistema. los cuales están basados en los casos de uso que se determinan para el análisis estructural y de comportamiento del sistema. La realización de iteraciones a lo largo de todo el proceso. lo cual se refleja en una mayor probabilidad de realizar la entrega del producto dentro del plazo estipulado. el no cumplimiento con la calidad necesaria del sistema. y no tener que incurrir en mayores costos. Los riesgos implicados en un proyecto de desarrollo de sistemas consideran aspectos técnicos y no técnicos. poco conocimiento en nuevas tecnologías a utilizar para el desarrollo de sistemas. permite realizar integraciones en las nuevas versiones obtenidas con las cuales. derivan de la importancia de la identificación de los requisitos funcionales y no funcionales. como desde un punto de vista de aseguramiento de la calidad. las causas asignables de éstos se centran principalmente en las nuevas tecnologías. Por otra parte. En el caso de los riesgos técnicos. Los riesgos relativos al rendimiento del sistema se basan principalmente en el tiempo de respuesta del sistema. también se consideran los riesgos derivados de la gestión misma del proyecto como pueden ser: un calendario de actividades demasiado ajustado. tanto desde un foco estructural – operativo. es de vital importancia manejar estos cambios por medio de validaciones de las pruebas que se realizan a las versiones desarrolladas del sistema. Los riesgos relativos a la construcción del sistema adecuado. así como de su capacidad para soportar un determinado número de instancias concurrentes en un instante de tiempo. la construcción del sistema adecuado. dependencia de empresas externas a cargo de la realización de ciertas actividades del proyecto.requisitos cambiantes que van surgiendo en la medida que el sistema va creciendo. el rendimiento. Oscar Saavedra Rodríguez 56 . por lo tanto. los riesgos no técnicos comprenden principalmente aquellos que derivan del efecto experiencia: la falta de experiencia de algún equipo de trabajo. Profesor.

y modelos conceptuales CANÓNICOS a modelos relacionales. todo lo anteriormente se puede resumir en: Clase Atributos Operaciones Entidad Identificador <id> Atributos Profesor. como este es un modelo que se va a implementar. o. en el modelo conceptual se obvian las operaciones. existen las herramientas para lograr esto sin la necesidad de recurrir a lo primeramente planteado. lo primero que se debe tener en cuenta es que en el diagrama conceptual se eliminan las operaciones presentes en el diagrama de clases. 1. no es imperativo que todas las entidades tengan atributos identificadores. por lo que. Es decir. Sin embargo. por lo que hay que buscar cuál de las 2 o más entidades es la que se busca utilizar. Las relaciones de dependencia no se representan en este modelo. ya que para los objetivos del modelo (implementación) estas propiedades no son necesarias desde el punto de vista del modelo. estamos hablando de una relación IS-A excluyente. Este tipo de entidades son las que en el diagrama de clases forman parte de una relación Todo-parte. que aunque se pueden obtener todos los diagramas y modelos por separado. Como bien recordaremos. puede quedar como una relación regular. se especifique de que entidad se esta hablando. Además. el cuál va a permitir el acceso a esta entidad. Oscar Saavedra Rodríguez 57 . Por lo tanto. estas en este diagrama se representan como relaciones del tipo IS-A. Sin embargo. a su vez. Esto debido a la existencia de las entidades débiles. de un atributo identificador. de las cuáles se infiere que no pueden existir por si sola (como se dijo en secciones anteriores). existen reglas para transformar diagramas de clases a modelos conceptuales. la relación de agregación puede quedar convertida en una relación que evidencie la existencia de una entidad débil. la cuál en este diagrama queda manifestada como una relación del tipo débil. Gráficamente. se requier que. en el modelo conceptual. por lo que se debe buscar la relación que más se adecue a lo que se buscaba analizar en el diagrama de clases. cuando ocurre esto. el diagrama de clases representa tanto atributos como operaciones que permiten realizar una análisis de manera adecuada. Obtención del Modelo Conceptual a partir del Diagrama de Clases. Con respecto a las generalizaciones. Sin embargo. específicamente de una asociación de composición. en algunos casos.Anexo: Transformación de Diagrama de Clases a Modelo Relacional Es importante recalcar. Otro punto sumamente importante es la búsqueda. modelos conceptuales a modelos conceptuales CANÓNICOS.

1 0... Oscar Saavedra Rodríguez 58 .Eliminada Si es Excluyente: Con respecto a las cardinalidades.1 ó 1 1..* Profesor. estas se transforman de las siguiente manera: Normal 0..* ó * Débil 1.

no siempre es posible definir un identificador para una entidad. Sin embargo. éste puede estar compuesto por más de un atributo y la combinación de valores tomados por atributos que conforman el identificador es única para cada registro o instancia de la entidad. Sin embargo. Las relaciones de dependencia y las realizaciones de interfaces no tienen una nomenclatura equivalente en el modelo. por lo tanto éstas no pueden ser especificadas en este tipo de representaciones. los modelos entidad – relación pueden ser considerados como un caso particular de los diagramas de clases. El identificador de una entidad está conformado por un atributo cuyo valor de registro es único para cada instancia de la misma. Otro aspecto que se debe tener en cuenta es la existencia de atributos identificadores en las entidades. aunque esta equivalencia semántica no se puede dar para todas las relaciones de los diagramas de clases. así como para establecer el vínculo con las instancias de las demás entidades con las que se encuentra asociada. En consecuencia. en los cuales las clases corresponden a las entidades que contienen sus respectivos atributos. En cambio. Bajo el marco de referencia de los modelos orientados a objetos. Del mismo modo. los modelos entidad – relación sólo abarcan el aspecto estructural de un sistema. resultando ésta en lo que se denomina una entidad débil. cuando un atributo identificador no es suficiente.Modelos de Bases de Datos Relacionales para Sistemas de Información Las bases de datos relacionales se encuentran representadas a través de un tipo de modelo semántico conocido como Modelo Entidad – Relación. así como su implementación. sino que queda limitada sólo a las relaciones de generalización (llamada relación Is-A en los modelos entidad – relación) y las relaciones de asociación. su simplicidad facilita tanto la comprensión de la estructura del sistema. se puede efectuar una conversión de dichos diagramas de la metodología orientada a objetos por medio del uso de las Herramientas Profesor. Oscar Saavedra Rodríguez 59 . un análisis por medio de modelos entidad – relación no puede abarcar el aspecto de captura de requisitos ni el comportamiento del sistema como lo hace el conjunto de diagramas de UML en la metodología orientada a objetos. No obstante. Las relaciones de los diagramas de clases presentan un cierto grado de equivalencia con las relaciones de los modelos entidad – relación. el cual se basa en la existencia de entidades con atributos que la describen y cuyas instancias se asocian con instancias de otras entidades por medio de relaciones. Se define un identificador en las entidades para poder distinguir entre una instancia y otra en la entidad correspondiente. por lo que las entidades no contienen las operaciones que manipulan los datos de ésta. en una clase no se establece un atributo o conjunto de atributos que se determinen como identificador para ésta. la cual va depender de los identificadores de las entidades con que se encuentre directamente asociada. dado que la metodología orientada a objetos establece un Identificador de Objeto u Object Identifier (OID) que se genera automáticamente al crear una instancia de clase. La definición de identificadores en una entidad es un requisito básico cuando se cuenta con uno o varios atributos que permitan distinguir a una instancia de otra en una entidad. Ya que los modelos entidad – relación pueden ser considerados un caso particular y simplificado de los diagramas de clases.

1.CASE. Ya establecido e implementado un modelo de base de datos relacional. sólo restará elaborar el diseño de las interfaces de ingreso y salida de información de acuerdo a los requisitos establecidos durante las fases de análisis y diseño. para luego trabajar solamente en el ámbito estructural del modelo del sistema de información. Ejemplo de Diagrama de Clases. Una vez que el modelo entidad – relación generado a partir del diagrama de clases ha sido normalizado. Profesor. estas relaciones redundantes pueden permitir una optimización del tiempo de respuesta al efectuar consultas de datos. Para el caso de la información de salida. Oscar Saavedra Rodríguez 60 . A continuación. el cual corresponde a un lenguaje estándar y estructurado para la creación y edición de tablas relacionales y columnas de una base de datos. y la creación de un modelo físico a partir del último. También es conocido como modelo físico. Figura 6. El modelo relacional representa las tablas de la base de datos con sus índices o claves primarias y foráneas. es posible generar el modelo relacional que resume en forma gráfica la representación física del código fuente que se generará para implementar un RDBMS4 como tal. La conversión de modelos requerirá probablemente una definición o especificación de identificadores en las entidades generadas a partir de las clases previamente diseñadas. así como las columnas de datos con sus tipos de datos. Los loops de relaciones existentes también pueden ser extraídos del modelo por ser redundantes. 4 Sistema de Administración de Bases de Datos (Relational Data Base Management System). aunque si el modelo representa una base de datos de tamaño considerable. ésta se establece a través de la confección de comandos DML (lenguaje de manipulación de datos) de SQL (lenguaje estructurado de consulta). las siguientes imágenes representan la equivalencia en la conversión de un diagrama de clases en un modelo conceptual de tipo entidad relación. así como eliminar alguna posible redundancia de datos a través de la aplicación del proceso de normalización. así como para la especificación de consultas de datos contenidos en dichas tablas. Cabe destacar que en el diagrama de clases se omitieron las operaciones correspondientes dado que éstas no son implementadas en el modelo conceptual.

l a n g .Da te j a va . Profesor.Nu m b e r j a va ..Nu m b e r Fuente: Elaboración Propia.* P ro ye cto + + + + + n u m e ro p r d e scri p ci o n g ra l p r fe ch a co sto p r va l o r p r : : : : : j a va .l a n g .In te g e r 1 .S tri n g j a va .l a n g .1 1 . Ejemplo de Modelo Conceptual Generado desde el Diagrama de Clases.In te g e r j a va .l a n g ..In te g e r 1 .Nu m b e r 1 ..l a n g .S tri n g j a va .* + + + + Co n su l to r ru t co n n o m b re co n a p e l l i d o co n fo n o co n : : : : j a va .l a n g .S tri n g j a va .Nu m b e r j a va .In te g e r j a va .Nu m b e r j a va .l a n g .u ti l . Figura 6.l a n g .l a n g .S tri n g j a va .l a n g .S tri n g j a va .1 1 .S tri n g j a va .1 0 .. Oscar Saavedra Rodríguez 61 .* De ta l l e P ro ye cto + + + + + ca n ti d a d re cu rso ca n ti d a d e q u i p o su b to ta l IV A T o ta l : : : : : j a va ..l a n g .l a n g .l a n g .l a n g .l a n g .Cl i e n te + + + + ru t cl n o m b re cl d i re cci o n cl fo n o cl : : : : j a va .2.l a n g .In te g e r j a va .S tri n g j a va ..l a n g .

Profesor.Cliente rut cl <pi> TXT <M> nombre cl TXT direccion cl TXT fono cl I rut cl <pi> solicita Proyecto numero pr <pi> I <M> descripcion gral pr TXT fecha D costo pr N valor pr N numero pr <pi> genera Consultor rut con <pi> TXT <M> nombre con TXT apellido con TXT fono con I rut con <pi> contiene DetalleProyecto cantidad recurso I cantidad equipo I subtotal N IVA N Total N Fuente: Elaboración Propia. Oscar Saavedra Rodríguez 62 .

Oscar Saavedra Rodríguez 63 .fk> INTEGER INTEGER NUMERIC NUMERIC NUMERIC Fuente: Elaboración Propia. Ejemplo de Modelo Físico de Datos Obtenido del Modelo Conceptual.Figura 6. Profesor. Cliente rut cl nombre cl direccion cl fono cl NOTE <pk> NOTE NOTE INTEGER FK_PROYECTO_SOICITA_CLIENTE Proyecto numero pro INTEGER <pk> rut cl NOTE <fk1> rut con NOTE <fk2> descripcion gral pr NOTE fecha pr NUMERIC costo pr NUMERIC valor pr NUMERIC Consultor FK_PROYECTO_GENERA_CONSULTO rut con nombre con apellido con fono con NOTE <pk> NOTE NOTE INTEGER FK_DETALLEP_CONTIENE_PROYECTO DetalleProyecto numero pro cantidad recurso cantidad equipo subtotal IVA Total INTEGER <pk.3.

las cuales pueden ser consideradas como herramientas de modelado visual. puedan crear por propia iniciativa sus documentos de páginas Web en forma simple y rápida. mejor conocido como HTML5 es el lenguaje más utilizado en la creación de páginas Web.1. 1. al cual se incorporan tecnologías que potencian la funcionalidad y el diseño como son las aplicaciones java y el uso de sistemas de bases de datos en línea a través de su vinculación con páginas dinámicas. Las tecnologías Web consideran el diseño y construcción de sitios y páginas Web como un aspecto base. permite que usuarios no interiorizados con el lenguaje en sí. con el paso del tiempo se fueron añadiendo más etiquetas con el fin de evitar problemas de formato en la visualización de los documentos en diferentes navegadores. 5 6 Hyper Text Markup Language Abreviación para What You See Is What You Get (Lo que ves es lo que obtienes). desde cualquier lugar y en forma expedita. aplicaciones. Profesor. Su facilidad de uso y el no ser propiedad de nadie es lo que ha hecho a HTML un medio ideal para compartir información en Internet. La aparición de estas aplicaciones del tipo WYSIWYG6. La evolución del lenguaje HTML ha permitido establecer vínculos con otro tipo de documentos como son archivos de imágenes. Tecnologías Web para el Desarrollo de Sistemas de Información La utilización de sistemas de información en conjunto con la red Internet ha permitido a las Organizaciones contar con la información justa en el momento preciso y de forma constante. En un principio se contaba con una determinada cantidad de etiquetas que marcaban la información de acuerdo a su significado. Es por esta razón que el uso de tecnologías Web ha incrementado la utilidad de las Tecnologías de la Información y Comunicación (TIC) como apoyo al proceso de toma de decisiones. Lenguaje de Hipertexto Basado en Marcas (HTML) El Lenguaje de Hipertexto basado en Marcas. vídeo. con lo cual ha aumentado su funcionalidad y potencialidad en el desarrollo de documentos en la World Wide Web. audio. haciendo que HTML se volviera un lenguaje orientado al control de la presentación. independiente de la máquina que se utilice. Esta evolución del lenguaje permitió la salida al mercado de aplicaciones dedicadas a la creación y construcción de páginas Web basadas en el diseño como son los populares FrontPage de Microsoft y Dreamweaver de Macromedia. pero además. Sin embargo. Consiste en un conjunto de etiquetas que permiten describir documentos de texto y vínculos de hipertexto que permiten desplazarse a otros documentos. Oscar Saavedra Rodríguez 64 .1. y la visualización de formato del documento quedaba en manos del navegador o browser.

Dinámic a Activa • Fuente: Sitio Web de SALNET S. el contenido de un documento activo nunca es fijo. • • Capaces de actualizar • continuamente la información. Costos extras de creación y ejecución. y por ende. Cuadro Comparativo de los Tres Tipos de Páginas. ejecuta un programa de aplicación que crea el documento dinámico y devuelve al solicitante el documento en cuestión. Páginas Dinámicas.1.A. Incapaz de presentar información cambiante mientras se visualiza el documento en el navegador. El contenido del documento puede variar de solicitud en solicitud. los documentos de páginas Web se pueden clasificar en los siguientes tipos: Páginas Estáticas.2. Corresponden a documentos creados por el servidor Web cuando un usuario lo solicita. Tabla 7. Los cambios requieren de tiempo y correcciones. al recibir la solicitud. Herramientas para la Construcción de Páginas Web Las principales herramientas para el diseño y construcción de páginas Web se clasifican en tres tipos: Editores.1. Cuando un visualizador o usuario solicita un documento activo. Oscar Saavedra Rodríguez 65 . Corresponden a un documento Web cuyo autor determina su contenido al momento de escribirlo. El servidor Web. Los editores de páginas Web son aquellas aplicaciones que permiten la creación de documentos HTML. la cual puede llevarse a cabo a través de la de creación y edición de código por medio de los denominados Editores HTML. se desarrollaron las páginas Web dinámicas. 1. el servidor regresa una copia del programa que deberá ejecutarse localmente. • Confiabilidad.1. Páginas Estáticas y Dinámicas En la medida que el uso de Internet se fue haciendo más popular como Sistema de Información.1. ya que consta de un programa que entiende la forma de calcular y presentar valores. o bien. Página Estática Ventajas • • • • • Desventajas Inflexibilidad. • Desempeño. Debe ser modificada cada vez que cambie el contenido. De este modo. Por lo tanto.1. éste no cambia. Debido a esto. Páginas Activas. Cada vez que se emite una solicitud a un documento estático se recibe siempre la misma respuesta. las cuales permiten establecer un cierto nivel de interacción con los usuarios. Reportan información actualizada. Pueden ser presentadas con relativa rapidez por un navegador. Sencillez. Profesor. Mayor costo de desarrollo. surgió la necesidad de incorporar un mayor dinamismo a la páginas Web que muestran la información estáticamente. Un documento activo no es especificado completamente por el servidor. por medio de edición de la vista de diseño utilizando Editores WYSIWYG. Navegadores y Programas de Tratamiento de Imágenes.

Editor HTML gratuito y bastante popular. efectos de HTML dinámico. También posee la opción de edición y vista de código. Permite el manejo de capas. posee la opción de edición y vista de código. por lo que también puede ser utilizado como un editor HTML. Paint Shop Pro. dadas las características del lenguaje HTML. Oscar Saavedra Rodríguez 66 . Es una aplicación que posee muchas funciones y ayudas. Al igual que Dreamweaver. Los editores WYSIWYG más populares son: Dreamweaver. o bien. Es un programa pensado para aprovechar la gran cantidad de temas que se pueden incorporar a un sitio Web. la cual permite desarrollar animaciones como entornos interactivos que complementan a las Profesor. Los editores HTML más utilizados son: HTML-Kit. Es ideal para aquellos usuarios que buscan realizar un diseño rápido. Además de los tres tipos de herramientas necesarias para la creación y edición de páginas Web. Corel Draw. Sin embargo. También posee la opción de edición y vista de código. el diseño y creación de una página Web considera la creación de un código. Además. Adobe Golive. las cuales deben ser creadas o editadas. Se caracteriza por su facilidad de uso. Tal como ya se ha visto. convirtiéndolo en la opción ideal. por lo que dos navegadores pueden presentar de manera diferente un documento HTML. Aracnophilia. ya que muchas veces el navegador está a cargo de la visualización de los detalles. entre otras herramientas profesionales. En la mayoría de los casos está la incorporación de imágenes. Sin embargo. Por otra parte. Para ello se debe contar con programas de tratamiento de imágenes. Es un editor visual de páginas Web que ha alcanzado un alto nivel de sofisticación sin perder simplicidad. la creación del código no es lo único que se debe tomar en cuenta. Adobe PhotoShop. Algunos de los programas más populares en el tratamiento de imágenes se encuentran: Fireworks. HotMetal Pro. que tienen poco o ningún conocimiento del código. se recomienda no utilizar un solo navegador para la visualización de los documentos de páginas Web. los editores WYSIWYG son utilizados por usuarios que desean crear y editar páginas del mismo modo como lo hacen con un procesador de palabras. Posee una interfaz sencilla y fácil de utilizar. Permite la importación de documentos de MS Office a HTML. los editores WYSIWYG son altamente empleados por usuarios ya sean principiantes. Los navegadores o browsers son utilizados para ver los resultados de las páginas que se crean. FrontPage2000. Cute HTML.Los editores HTML son recomendados para personas experimentadas que tienen conocimiento del lenguaje y que quieren tener control total sobre el código de sus páginas. Es una herramienta bastante cómoda para profesionales. aunque con un uso bastante limitado en sus acciones. La herramienta más popular de este tipo es Flash de Macromedia. Recomendado para principiantes. Posee autocompletado de código y gran cantidad de asistentes. existe otro tipo de aplicaciones que aportan valor a las páginas tanto desde la perspectiva del diseño como de la funcionalidad. Dichas aplicaciones se caracterizan por la posibilidad de crear animaciones adjuntas a los documentos HTML e incorporando aspectos multimediales que le brindan un mayor atractivo al visualizador de la página o sitio Web.

se pueden emplear 7 Extensible Markup Language Profesor. No obstante. XML no corresponde a una versión mejorada de HTML sino que corresponde a un metalenguaje más rico y complementario a HTML. más flexible que HTML. lo cual otorga una mayor flexibilidad al lenguaje. El crecimiento y desarrollo explosivo que ha sufrido Internet. pero capaz de aprovechar sus ventajas. muy exitoso en mostrar documentos en la Web. permitiendo que la información contenida sea más rica y fácil de utilizar. como lo es por ejemplo <TITULO>Investigación de Operaciones</TITULO>. Sin embargo. XML permite identificar el contenido que está etiquetando. donde cada uno de estos últimos puede contener texto o más componentes. XML no es sólo un simple lenguaje. El uso de etiquetas personalizadas de XML permite organizar la información en una estructura de tipo árbol. se pueden mencionar las ventajas que posee XML sobre HTML: Los diseñadores pueden crear sus propios tipos de documentos. es decir como un componente formado por otros componentes.páginas creadas en HTML. Oscar Saavedra Rodríguez 67 . En la actualidad. Esta es una de las ventajas de XML sobre HTML. 1. sino que corresponde a un metalenguaje. ya que las etiquetas de HTML sólo describen el tipo de formato del documento. Dicho esto. existiendo una marca al principio y otra al final. La presentación se lleva cabo mediante una hoja de estilo. Esto llevó a los desarrolladores de HTML a estructurar un nuevo lenguaje denominado XML7. Lenguaje de Marcas Extensibles (XML) El lenguaje HTML ha sido. la cual describe que “Investigación de Operaciones corresponde a un título. posiblemente de un curso o un texto. el lenguaje sigue siendo bastante rígido. ya que la flexibilidad de las etiquetas de XML pueden emplearse sin tener que ajustarse a las reglas específicas de HTML. así como los intereses comerciales de las organizaciones ha requerido que el lenguaje evolucione para satisfacer las continuas necesidades de funcionalidad y diseño de las páginas. los cuales pueden ser “hechos a medida” al poder crear etiquetas propias. pero no se refiere a una serie de contenidos. los archivos Flash se han vuelto un estándar y pueden ser visualizados a través de cualquier navegador. Según sea la conveniencia para la presentación de un mismo documento. pero no lo que contienen éstas. la cual corresponde a una descripción de cómo debe visualizarse una información en un medio determinado. Las marcas más utilizadas tienden a ser descritas por textos característicos encerrados entre los signos “<” y “>”. y sigue siendo. ya que permite definir un propio lenguaje de etiquetas para múltiples tipos de documentos. XML puede entregar más y mejores facilidades para la representación en los visualizadores. En cambio. La información se vuelve más accesible y reusable.2.

El documento debe adherirse a la gramática que establezca la DTD. las interfaces entre dichas partes que vayan evolucionando en el tiempo. Para que un documento XML sea válido debe cumplir con los siguientes requisitos: El documento debe estar bien estructurado. Dentro de éstos existen dos tipos: los que representan el fichero en forma de árbol y permiten construir el documento trabajando sobre este árbol y formularios adicionales. las entidades no analizadas son recursos cuyo contenido puede ser texto o no. y los que representan el documento XML en su formato original y que normalmente son editores de ficheros de texto con facilidades para XML. proveyendo una forma para definir el vocabulario a emplear. cuando se habla de un sitio de compras en línea que se comunica con una empresa de tarjetas de crédito. los documentos XML están formados por unidades de almacenamiento llamadas entidades. XML se utiliza mucho en la actualidad para el establecimiento de la comunicación entre varias partes que desean dialogar entre sí.diferentes hojas de estilo. etc. algunos de los cuales conforman datos de carácter y otros conforman marcas. Cada documento XML contiene una entidad llamada entidad documento. Los datos procesados están hechos de caracteres. Es decir. Las entidades pueden ser de dos tipos: analizadas o sin analizar. El documento debe tener una Definición de Tipo de Documento (DTD) que declare todos los elementos. atributos y entidades que se utilicen en el documento. En un documento XML se distinguen dos estructuras: física y lógica. y parcialmente describe el comportamiento de programas que pueden procesarlos. Las marcas codifican la descripción del esquema de almacenamiento y estructura lógica del documento. Todas estas unidades tienen contenido y están identificadas por un nombre. aunque es recomendable el uso de editores especializados. Los elementos están delimitados por etiquetas de comienzo y de final. las cuales contienen datos procesados o sin procesar. Las entidades se invocan a través de su nombre. y en el caso de las entidades no analizadas. La estructura física está dada por una o más unidades de almacenamiento virtual denominadas entidades. Por ejemplo. se puede emplear una hoja de estilo para presentar el documento como página Web. En cambio. Cada elemento tiene un tipo identificado por un Profesor. Además. se realiza a través de sus atributos de entidad. la estructura lógica está determinada por los elementos que hay en dicho documento junto con las relaciones que hay entre ellos. Por otra parte. Oscar Saavedra Rodríguez 68 . El contenido de una entidad analizada también es conocido como texto de reemplazo y es parte integrante del documento. XML describe una clase de objetos de datos denominados documentos XML. El elemento raíz debe coincidir con el nombre que proporcione la declaración del tipo de documento. la cual sirve como punto de inicio para el procesador XML y puede contener el documento completo. La creación de documentos XML se puede realizar por medio de editores de texto. en el caso de las entidades analizadas la invocación se lleva a cabo a través de su referencia a entidad. otra para presentarlo como texto imprimible.

Una analogía a la estructura física y lógica de un documento XML es la estructura física y lógica de una base de datos relacional. como son: El envío de correo a una persona o a una lista parametrizando toda una serie de aspectos tales como e-mail de procedencia. y puede tener un conjunto de Cada especificación de atributo tiene un nombre y un valor. PosgreSQL.). Oracle. Informix. denominado identificador especificaciones de atributos. Presenta un soporte para bases de datos. persona a responder. con excepción de los nombres que comienzan por XML. Posteriormente se diseñó y desarrolló un sistema para el procesamiento de formularios. mover. el uso o los nombres de los tipos de los elementos y los atributos. entre otras. PHP presenta la posibilidad de llevar a cabo una serie de tareas útiles en la gestión de sistemas de información en línea. Se distribuye gratuitamente en la Web. y no restringen la semántica.3. 8 Personal Home Page Profesor. entre otras. genérico. PHP se caracteriza por presentar varias virtudes que corroboran su alta funcionalidad y utilidad. modificar. los cuales se reservan para estandarizar etiquetas o atributos en versiones posteriores. dentro de las cuales pueden mencionarse: Interbase. La generación de interfaces para acceder a bases de datos comerciales y por ODBC. Herramientas para Páginas Web Personales (PHP) La herramienta PHP8 nació como un analizador sintáctico de un número limitado de comandos. Con el rápido avance que sufrió Internet. mSQL. la cual emplea campos y tablas en el aspecto lógico. el asunto. a partir de las cuales se puede editar el contenido de un sitio en forma sencilla. Las características de PHP consideran: Software Libre. MySQL. etc. borrar. Oscar Saavedra Rodríguez 69 . 1. El uso de PHP facilita la realización de operaciones tales como el uniformar el tamaño de imágenes o la creación de platillas Web donde sólo se modifican contenidos con el uso de librerías de funciones gráficas. La realización de funciones de administrador FTP para la gestión de archivos a partir de sentencias en el código para el cual PHP ha previsto una gran cantidad de funciones además de las estándares (crear. especialmente para el trabajo con sistemas de gestión en línea basados en páginas Web dinámicas con conexiones a bases de datos tanto dentro de una Intranet como en Internet.nombre. Soportado en diversos tipos de plataformas. y archivos binarios en el aspecto físico. se incorporaron nuevas funcionalidades como soporte a nuevos protocolos de Internet y el soporte a una gran cantidad de bases de datos comerciales.

el cual se caracteriza por ser un lenguaje de fácil y rápido aprendizaje. robustez. Por lo tanto. MySQL es un software accesible para cualquiera. MySQL MySQL es sistema de gestión de bases de datos implementada como arquitectura cliente servidor con la cual se puede agregar. cuyas aplicaciones generadas buscan lograr la ejecución independientemente del hardware y del sistema operativo.4. La comprobación de la existencia del disparador y su ejecución consume recursos y tiempo y es la única razón por la que no se encuentran implementados en esta herramienta. Java se caracteriza por brindar la construcción de aplicaciones distribuidas y de agentes de software con facilidad. y para conseguir esto de una forma relativamente fácil se utiliza la Lógica Transaccional. fundamentado en álgebra relacional. tal como se mencionó. La conectividad.1. pero sin la posibilidad de deshacer las operaciones realizadas con los datos. 1. facilidad de uso tanto para volúmenes de datos grandes como pequeños. Oscar Saavedra Rodríguez 70 . velocidad y seguridad hace de MySQL una herramienta altamente conveniente para el acceso a bases de datos en Internet a través de la interacción entre el sistema administrador de base de datos y el uso de páginas Web dinámicas. ya sea para uso o modificación. Se ha convertido en una aplicación muy útil debido a su rapidez. Java Java es un lenguaje totalmente orientado a Internet. un aspecto muy importante para cualquier base de datos relacional es la consistencia de las tablas que la componen. Sin embargo. permitir que las aplicaciones sean interactivas cuando se utilizan a través de la Web. Por otra parte. las aplicaciones Java pueden instalarse en Internet y ser ejecutadas en máquinas clientes. trabaja con conceptos simples que involucran a tablas (filas y columnas). Los Triggers corresponden a una porción de código almacenado que se “dispara” o ejecuta cuando se realiza una operación con la base de datos. debido a que permite la escritura fiable de programas en Profesor. en cualquier entorno que lo soporte sin la necesidad de crear una aplicación en cada entorno. es un lenguaje estándar y flexible para efectos de consultas. MySQL no soporta las transacciones en favor de la velocidad y sólo permite la utilización de comandos de bloqueo y desbloqueo de tablas. donde será el mismo gestor de base de datos el que proporcione mecanismos de bloqueo de ficheros y consolidación o retroceso en las operaciones con las tablas.5. acceder y procesar datos grabados en una base de datos. Trabaja con bases de datos relacionales implementadas a través de SQL (Lenguaje Estructurado de Consultas). impidiendo que otros usuarios puedan acceder a ellas. flexibilidad. la alta rapidez de MySQL es a costa de no implementar ciertos aspectos de SQL como son los Triggers y la Lógica Transaccional. No obstante.

no lo es con todas. como es el caso de las aplicaciones de tiempo real. éstas están formadas por objetos que se ejecutan en múltiples computadores. de red o distribuidas. no pueden comunicarse con un servidor distinto del que tenía almacenado el applet original. los applets podrían programarse para contener virus. desde un servidor Web y que se ejecuta localmente en un browser. Sin estas restricciones. Las aplicaciones de Java pueden ser autónomas. Finalmente. los cuales corresponden a programas escritos en Java que se transfieren junto a una página HTML desde donde se le llama. en el caso de las aplicaciones de red. Sin embargo. La diferencia entre cada una de éstas se centra en el uso de los recursos. No se pueden volver a cargar programas residentes en el sistema donde se ejecuta el browser. el programa se ejecuta por medio de los recursos de un solo computador. se utilizan los recursos disponibles en la red. requiere de un cierto tiempo de aprendizaje para que los programadores puedan aprovechar su potencial. El lenguaje Java se utiliza principalmente en la creación de applets. Oscar Saavedra Rodríguez 71 . a excepción de directorios específicos. incluidas las DLL. esto la convierte en una herramienta potente para el desarrollo de aplicaciones para la red. el problema de compatibilidad no sólo se presenta en la plataforma de software y hardware. No se puede ejecutar programas en el sistema donde se ejecuta el browser. a pesar de ser compatible con muchas plataformas. sino que también con versiones de Java. mientras que en el caso de las aplicaciones distribuidas. Los applets se caracterizan por tener restricciones de seguridad ya que provienen de cualquier servidor Web y se ejecutan localmente y pueden provocar daños al sistema o brechas en la seguridad. Las restricciones sobre lo que un applet realiza incluyen las siguientes: No se puede leer o escribir en el sistema de archivo donde se ejecuta el browser. Se emplean para proporcionar mayor interactividad y dinamismos a los servidores Web. si bien Java se caracteriza por ser un lenguaje simple. Para el caso de las aplicaciones autónomas. así como la distribución de aplicaciones a través de la red. Además puede se puede dar que Java no alcance las exigencias de rendimiento de las aplicaciones en las que la velocidad de ejecución es de vital importancia.múltiples plataformas. Por lo general. Profesor.

pruebas. valor del curso. fecha de nacimiento. tipo contrato. descuentos especiales. Por estas razones. asignaciones especiales. En este momento se actualiza la base de datos de personal con la información del postulante (Rut. capacidad intelectual. fecha contrato. descripción.). el jefe y colegas del personal realizan una evaluación Profesor. etc. es necesario diseñar un eficiente sistema de información que refleje los siguientes procesos: el proceso se inicia cuando un jefe o gerente de unidad debe enfrentar el desarrollo de un nuevo e importante proyecto y requiere personal. AFP. estudios universitarios. en este momento se actualiza nuevamente la base de datos con la información del cargo (número.1. nombre. nacionalidad. beneficios médicos. capacidad física. funciones y responsabilidades. sueldo neto. En este proceso. experiencia. subordinados). tests. a través de distintos medios (contactos en las Universidades. fecha inicio. Oscar Saavedra Rodríguez 72 . radio. Una vez terminados estos procesos. resultados. etc. dirección. También es importante mantener información de la evaluación y desarrollo del personal en la unidad de trabajo.2. Una vez que llegan los antecedentes de los postulantes se inicia el proceso de selección (entrevistas. periódico. habilidades personales. nombre. Una vez terminado el proceso de selección.). el personal aceptado pasa por un proceso de socialización (se dan a conocer las normas y procedimientos de la Organización. trabajo anterior. etc. el contrato (número. habilidades desarrolladas. Un jefe o gerente de área necesita información de su personal a cargo para decidir formar los equipos de trabajo más adecuados para el desarrollo de proyectos y actividades de la institución. Frente a nuevas necesidades o requerimientos de proyectos.). colegas. Estos antecedentes son un elemento importante en el momento de la evaluación del personal. el cual se debería desarrollar periódicamente. Esta actividad debe difundir los requerimientos de personal al mercado laboral y revisar las bases de datos internas de la unidad. fecha término. título profesional. sueldo bruto. utilizando indicadores y variables desarrolladas con esta finalidad. Con estos antecedentes se comienza el proceso de reclutamiento de personal.). Contexto de la Situación En las Organizaciones es cada vez más importante saber y conocer las habilidades y capacidades del personal que se desempeña en las distintas áreas. estado civil. personas recomendación.). dependencia y cargos. para mejorar sus capacidades y habilidades. por tal motivo se determina el perfil del personal a contratar o asignar. nombre.). el puesto que desempeñará. El personal cuando desempeña su actividad en la empresa debe pasar por procesos de capacitación y entrenamiento. etc. nuevamente es necesario actualizar la base de datos de personal con información de cursos (código. etc. el gerente de área debe decidir mover personal de su unidad o recurrir a seleccionar candidatos (postulantes) externos. Aplicación de UML en el Modelado de un Sistema de Información de Gestión del Recurso Humano 2. etc. estudios básicos. recomendación. Otro proceso importante es el proceso de evaluación del personal. Este proceso puede ser con postulantes externos y personal interno que desea una promoción.

relaciones interpersonales. Modelo de Proceso de Negocios Una vez que se conoce el contexto de la situación se ha procedido a realizar el modelado del Proceso de Negocios de la unidad.) y del evaluador (Rut. participación. y se determina un mejoramiento o mantener la situación actual del personal. Esta información es ingresada a la base de datos de personal. y con estos antecedentes se puede asignar un beneficio o incentivo al personal. Esta información también debe ser ingresada a la base de datos de personal (número expediente.2. La impartición de los cursos de capacitación está considerada como de tipo externa. recomendaciones. cargo. Si se produce algún cambio esto debe ser reflejado en la base de datos. cargas familiares y en general. motivo. liderazgo. etc. por lo que éstas quedan fuera del dominio del problema – solución del sistema. Oscar Saavedra Rodríguez 73 .). trabajo en equipo. nombre. la evaluación contiene la información de la persona evaluada (Rut. se revisa el contrato. etc. responsable. dependiendo de la información obtenida de la base de datos de personal. conocimiento. Una vez transcurrido un tiempo. unidad. cargo. El segundo proceso identificado. fecha de evaluación. En el cual se han identificado cuatro procesos principales que se pueden llevar a cabo de forma paralela. 2. El primer proceso de negocio consiste en el reclutamiento y contratación o ascenso de nuevo personal a través de las postulaciones de personas externas o de personal interno a la organización a partir de la identificación de necesidades de nuevo recurso humano para el desarrollo de proyectos y actividades. Profesor. responsabilidad). fecha. se abre un expediente disciplinario. una persona en la empresa pasa a un proceso de retiro o separación de la unidad. es decir. nombre. En este momento se calculan todos los indicadores de acuerdo a los antecedentes en la base de datos de personal y se realiza el proceso respectivo. corresponde a la definición de personal que debe ser enviado a capacitación para adquirir y desarrollar determinadas capacidades requeridas en ciertas actividades en las que se verá involucrado dentro de la organización. esto puede ser por renuncia. jubilación o despido. todos los beneficios asociados. Estos expedientes también pueden ser por un buen desempeño en esta situación. Si una persona de la Organización tiene un desempeño inadecuado o presenta un comportamiento que no está acorde con las reglas de la Organización. los beneficios sociales. es decir. tipo. aunque mantienen un vínculo entre ellos dado por la información que se entrega y solicita.personal basada en los resultados de las actividades desarrolladas por las personas en sus equipos de trabajo y los resultados su capacitación. existe una determinada cantidad de centros de estudios encargados de dicha labor. En base a los antecedentes de desempeño del personal en su puesto de trabajo (evaluación) y a los resultados de la capacitación y entrenamiento del personal se realizan los procesos de mantenimiento del personal.

Figura 8. Seleccion y contratación de personal Depto de RRHH Cargo Personal Contrato Capacitar personal Mantener Personal Evaluación Evaluar Personal Expediente Cursos capacitación Fuente: Elaboración Propia Profesor.El tercer gran proceso dice relación con la evaluación de desempeño del personal cargo de un equipo o comisión conformada por el mismo jefe de área y otros empleados de la misma.1. Oscar Saavedra Rodríguez 74 . A continuación se presentan los diagramas de proceso de negocio para el caso en estudio. El cuarto proceso hace referencia a la promoción y el despido de personal de acuerdo a revisión de los expedientes obtenidos resultado de las evaluaciones. Realizada la evaluación se procede con la generación o actualización del expediente del empleado en particular. Modelo de Procesos de Negocios Global. lo cual consiste en términos globales en un proceso de mantención del recurso humano de la organización.

tal como se presenta en las figuras siguientes. éstos pueden ser explicados individualmente como un procesos paralelos. así como por otra parte. Subdiagrama de Proceso de Negocios: Selección y Contratación de RR. Figura 8. pero relacionados. Profesor.Cada uno de los procesos globales presentados. se vinculan entre sí a través de los requerimientos de información existentes entre ellos. Oscar Saavedra Rodríguez 75 .2.HH De fi n i r p e rfi l P e rfi l d e p e rso n a l De p to d e RRHH P e rfi l d e p e rso n a l Je fe d e A re a Re vi sa r i n fo rm a ci ó n e n B D d e p e rso n a l Di fu n d i r a m e rca d o l a b o ra l Re ci b i r a n te ce d e n te s d e p o stu l a n te s A n te ce d e n te s d e P o stu l a n te s E xte rn o s P o stu l a n te E xte rn o A l m a ce n a r a n te ce d e n te s p o stu l a n te s e xte rn o s [S I] [NO ] Re a l i za r e n tre vi sta i n i ci a l P o stu l a n te s P e rso n a l E n tre vi sta a p ro b a d a [NO ] [S I] Ca rg o Re a l i za r te sts T e sts a p ro b a d o s [NO ] [S I] Re a l i za r e n tre vi sta fi n a l [S I] Co n tra to S e l e cci o n a r p o stu l a n te E n tre vi sta a p ro b a d a [NO ] Fuente: Elaboración Propia.

Subdiagrama de Proceso de Negocios: Capacitación de Personal.Figura 8. De p to d e RRHH S e l e cci o n a r cu rso d e ca p a ci ta ci ó n De si g n a r p e rso n a l a ca p a ci ta r Cu rso s ca p a ci ta ci ó n P e rso n a l O b te n e r re su l ta d o s d e ca p a ci ta ci ó n Re su l ta d o s ca p a ci ta ci ó n Re g i stra r re su l ta d o s d e ca p a ci ta ci ó n Je fe d e A re a Fuente: Elaboración Propia. Oscar Saavedra Rodríguez 76 .3. Figura 8.4. Profesor. Subdiagrama de Proceso de Negocios: Evaluación de Personal.

Oscar Saavedra Rodríguez 77 . Figura 8.5. Profesor.Conformar Equipo evaluador Cursos capacitación Evaluar empleado Personal Evaluación de desempeño Evaluación Archivar Evaluación Crear Expediente Disciplinario Expediente Jefe de Area Fuente: Elaboración Propia. Subdiagrama de Proceso de Negocios: Mantención de Personal.

Análisis y Diseño Orientado a Objetos: Modelado con UML Profesor. Ya teniendo en cuenta cómo se lleva cabo las cuatro principales tareas. Cada uno de los diagramas presentados muestra los detalles del proceso de negocios del área en estudio. se dará inicio al análisis y diseño orientado a objetos por medio de la utilización de UML. 2.Personal Cursos capacitación Recopilar antecedentes Expediente Revisar Contrato Evaluación Contrato Promover empleado Promover empleado [SI] [NO] Cargo Jefe de Area Despedir Empleado [SI] Remover empleado [NO] Mantaner situación actual del empleado Depto de RRHH Fuente: Elaboración Propia. y con la información que proveen.3. Oscar Saavedra Rodríguez 78 . es posible obtener los requisitos necesarios para el modelado del problema y la delimitación de su dominio y solución.

y por lo tanto. el principal de los actores en el diagrama de casos de uso corresponde al jefe de área. ya que de éste depende la iniciación de las distintas tareas que se realizan. Desarrollo del Diagrama de Casos de Uso A partir de los modelos de proceso de negocio realizados para la situación en estudio.3. El actor Staff de RR. lo cual permite realizar la especificación de requisitos para el modelado estructural y de comportamiento del sistema de información.6. es posible determinar los principales actores y casos de uso del sistema.1. Tal como se puede apreciar. Figura 8. así como su participación constante en los procesos. los cuales vienen dados en forma general por las principales tareas que lleva a cabo el área de Recursos Humanos. juega un papel Profesor. Diagrama de Casos de Uso para el Sistema de Recursos Humanos. se l e cci o n a r p e rso n a l S ta ff d e RRHH ca p a ci ta r e m p l e a d o Je fe d e a re a a ctu a l i za r si tu a ci o n e m p l e a d o p ro m o ve r e m p l e a d o E q u i p o e va l u a d o r d e sp e d i r e m p l e a d o e va l u a r e m p l e a d o Fuente: Elaboración Propia.2. en la realización de los casos de uso determinados.HH. A continuación se presenta el modelo de casos de uso obtenido para este sistema de estudio. Oscar Saavedra Rodríguez 79 .

Oscar Saavedra Rodríguez 80 . la recopilación de información referida a algún empleado. se debe destacar la existencia de una relación de generalización de casos de uso para el proceso de mantención de personal debido a que su realización implica. participan como un apoyo de los procesos. Tabla 8. Seleccionar postulante acorde con el cargo vacante. Entregar Información de postulantes. Registrar nuevo empleado o actualizar Solicitar creación de un contrato nuevo. así como la secuencia de mensajes para la construcción de los diagramas de secuencia. las clases involucradas. Curso Típico de Eventos Respuesta Sistema Acción Actor Solicitar la información de los postulantes. Postcondicione Creación de un contrato nuevo. y dependiendo de los resultados obtenidos se produce una especialización del caso de uso padre en los dos casos de uso resultantes: promoción del empleado o despido de éste. Entregar descripciones de cargos. en forma general. Eliminar postulante del listado de Profesor. debido a que los principales procesos que tienen relación con la administración y gestión del recurso humano están sujetos a las áreas respectivas y en estas circunstancias. uno ya existente.1. Descripción Recopilar información de postulantes y cargos para la asignación de éstos a postulantes creando contratos de trabajo. Tipo Primario y Esencial Precondiciones Existencia de cupos de trabajo. Descripción de Caso de Uso Seleccionar Personal. Caso de Uso Seleccionar Personal Actores Jefe de área (iniciador). Especificación de los Casos de Uso Una vez realizado el diagrama de casos de uso. Staff de RR. ya sean internos o externos. Además de los actores identificados. se debe llevar a cabo la especificación de cada uno de los casos de uso involucrados en el diagrama con el fin de poder determinar posteriormente.HH. Obtener descripciones de cargos. Eliminación del contrato antiguo s cuando se trate de una promoción de un postulante interno.como actor secundario.

postulantes Fuente: Elaboración Propia Tabla 8. Tipo Primario Precondiciones Existencia del curso Postcondicione s Descripción Generar un listado de empleados que serán enviados a cursos de capacitación. Staff de RR. Buscar y entregar lista de cursos de capacitación Solicitar listado de empleados del área Asignar curso empleados de capacitación a Entregar listado de empleados del área Entregar listado de empleados designados a curso de capacitación Generar Nómina de empleados y los cursos a los han sido asignados Fuente: Elaboración Propia Tabla 8. Descripción de Caso de Uso Capacitar Empleado. Tipo Primario y Esencial Precondiciones El empleado a evaluar no puede formar parte del equipo que lo evalúa. Curso Típico de Eventos Acción Actor Respuesta Sistema Solicitar lista de empleados. la cual se registra en un expediente personal del empleado. Postcondicione Desarmar el equipo de evaluación al crear/actualizar el s expediente Descripción Formar un equipo para llevar a cabo la evaluación de desempeño del personal. Caso de Uso Evaluar Empleado Actores Jefe de área (iniciador).HH.2. Descripción de Caso de Uso Evaluar Empleado. Caso de Uso Capacitar empleado Actores Jefe de área (iniciador). Curso Típico de Eventos Respuesta Sistema Acción Actor Solicitar listado de cursos de capacitación. Equipo Evaluador. Generar expediente disciplinario si es la primera evaluación del empleado. Oscar Saavedra Rodríguez 81 .3. Profesor.

Descripción de Caso de Uso Actualizar Situación de un Empleado. Actores Jefe de área Tipo Especializado Precondiciones El empleado debe tener un expediente disciplinario Postcondicione s Descripción Obtener la información de un empleado. su cargo y su expediente disciplinario para definir si se mantendrá en su situación actual. Curso Típico de Eventos Respuesta Sistema Acción Actor Solicitar información del empleado. Actores Jefe de área Tipo Primario Precondiciones El empleado debe tener un expediente disciplinario Postcondicione s Descripción Obtener la información de un empleado. su cargo y su expediente disciplinario para ser promovido. disciplinario del empleado. Formar equipo de evaluación Crear equipo de evaluación. Caso de Uso Actualizar Situación de un Empleado.5. Registrar resultados de la evaluación Generar (o actualizar) expediente disciplinario Desarmar Equipo de Evaluación Fuente: Elaboración Propia Tabla 8. Fuente: Elaboración Propia Tabla 8. Curso Típico de Eventos Profesor. Descripción de Caso de Uso Promover Empleado. Revisar información del expediente Entregar la información recopilada. Oscar Saavedra Rodríguez 82 . Caso de Uso Promover Empleado. Mantener situación actual del empleado.Entregar listado de empleados. Obtener el expediente disciplinario del empleado.4. será promovido o despedido. Obtener el cargo del empleado.

Actualizar contrato asociado. se ha determinado un total de nueve clases participantes en el modelo: Postulante. Eliminar contrato asociado. Despedir Empleado. expediente Entregar la información recopilada. Profesor. Descripción de Caso de Uso Despedir Empleado. disciplinario del empleado. Promover empleado. Oscar Saavedra Rodríguez 83 . Caso de Uso Despedir Empleado. Actualizar cargo asociado. Fuente: Elaboración Propia de Clases Participantes en la Realización de los Casos de Uso y Desarrollo del Diagrama de Clases De acuerdo con la descripción de los casos de uso realizada en la sección anterior. Revisar información del expediente Entregar la información recopilada. Curso de Capacitación. Notificar término del proceso despido al jefe de área. Obtener el cargo del empleado. Externo (postulante). Contrato. Actores Jefe de área Tipo Especializado Precondiciones El empleado debe tener un expediente disciplinario Postcondicione s Descripción Obtener la información de un empleado. Notificar ascenso al jefe unidad Fuente: Elaboración Propia Tabla 8. Respuesta Sistema Revisar información del disciplinario del empleado. su cargo y su expediente disciplinario para ser despedido. Obtener el cargo del empleado. Obtener el expediente disciplinario del empleado. Obtener el expediente disciplinario del empleado. Remover cargo asociado.4. Empleado (postulante interno).Acción Actor Solicitar información del empleado. Curso Típico de Eventos Respuesta Sistema Acción Actor Solicitar información del empleado. Cargo. Modificar empleado.

HH9. y por lo tanto. el cual contiene los resultados de las evaluaciones que se le realizan por un Equipo Evaluador formado también. Profesor. dado que el sistema de recursos humanos de una organización toma como principal elemento a las personas que trabajan en la ella. A partir de estas clases. De acuerdo con esta información. los empleados pueden o no asistir a Cursos de Capacitación dictados por una empresa externa. por otros empleados (y entre ellos. Figura 8. Un empleado puede formar parte de más de un Equipo Evaluador. cuya existencia no determina la existencia y vida de cada objeto Empleado. se determinan las asociaciones entre ellas para conformar el diagrama de clases que modela el aspecto estático del sistema de información en estudio. particularmente. se ha obtenido el siguiente Diagrama de Clases. Evaluación y Expediente Disciplinario.Equipo Evaluador. Oscar Saavedra Rodríguez 84 . la situación descrita. una relación de agregación. donde se establece a Postulante como la clase padre. se determina que la clase principal corresponde a la de empleado. Empleado y Externo. Por otra parte. el jefe de área).7. 9 El detalle de las operaciones de las clases se encuentra en el Anexo 4. en las cuales se aprecia la existencia de un Contrato y de un Cargo para cada empleado de la organización. Dada esta información se establece la existencia de una relación de generalización – especificación (o herencia) entre las clases Postulante. la mayoría de las otras clases deben encontrarse asociadas a esta clase principal. Diagrama de Clases para el Sistema de Información del RR. Dentro de estas clases. Cada empleado tiene asociado un Expediente Disciplinario. El resto de las relaciones existentes se determinan como asociaciones. lo cual define la relación de asociación entre Empleado y Equipo Evaluador como una relación del tipo Todo – Parte.

String : java.Number : java.Date + Externo () Empleado .lang.fechaPos tulacion : java.Number : java.util.lang.lang.util.String : java.Date : java.util..Number + Postulante () 1.Date : java.lang..lang.String : java.1 ExpedienteDisciplinario 1.lang.String : java.lang.lang.Date : java.* + Evaluacion () Fuente: Elaboración Propia.String : java.String : java.String : java.lang.String 0.String 0.1 1.Date : java.String : java..String : java.Date : java.lang.lang.lang.1 1.lang.lang.String : java....* + + + fechaEvaluacion tipoEvaluacion conocimiento participacion relacionesInterpersonales trabajoEquipo liderazgo : java.String : java..lang..Number : java.String : java.Postulante + + + + + + + + + + + + + rut nombres apellidoPaterno apellidoMaterno fechaNacimiento direccion estadoCivil estudiosBasicos estudiosUniversitarios tituloProfesional habilidades experiencia trabajoAnterior recomendacion capacidadFisica capacidadIntelectual : char : java.String : java.1 1.lang.lang.lang.lang.1 1.lang.* Externo .lang.String : java.String : java.String : java.lang.String : java.lang.* 1.util.lang.String : java...lang.util.String : java..lang.String + CursoCapacitacion () Contrato + + + numeroContrato fecha tipoContrato sueldoBruto beneficiosMedicos AFP descuentosEspeciales asignacionesEspeciales sueldoNeto : int : java.String : java.lang.lang.1 + EquipoEvaluador () 1..Number : java.Date : java.String : java.lang.lang.* + + + + + + + + Contrato () Cargo codigoCargo nombreCargo des cripcion funciones res abilidades pons dependencia s ubordinados : int : java.lang.lang.antiguedad : int + Empleado () 1.lang.util.lang.lang.* EquipoEvaluador + numeroIntegrantes : int + Cargo () + ExpedienteDisciplinario () Evaluacion + + + + 1..Number : java.String : java.lang..String + + + + + 0. Oscar Saavedra Rodríguez 85 .* + + CursoCapacitacion codigoCurso nombreCurso fechaInicio fechaTermino resultados valorCurs o habilidadesDesarrolladas : int : java.String : java.1 1.String : java.lang.* 1.lang..1 + + + + + + numeroExpediente fechaExpediente motivo unidad responsable recomendaciones : int : java.String : java.String : java.String 0.lang.String : java.String : java.String : java. Profesor.lang.util..lang.String : java.

haciendo uso de diagramas de secuencia. El uso de los diagramas de secuencia. A continuación se presentan los diagramas de secuencia para los casos de uso del modelo estudiado.8. es posible modelar el comportamiento del sistema a través de diagramas de interacción. Diagrama de Secuencia de la Promoción de un Postulante Interno. Diagrama de Secuencia de la Contratación de un Postulante Externo. de acuerdo al establecimiento de necesidades personal para el desarrollo de actividades y proyectos dentro de la organización. permiten representar la realización de los escenarios de los casos de uso. es posible que la existencia de más de un diagrama de interacción para un mismo caso de uso. Por lo tanto. el cual trata la contratación de postulantes internos y la promoción de postulantes internos. Figura 8. Oscar Saavedra Rodríguez 86 . particularmente. Las siguientes figuras representan la realización del caso de uso “Seleccionar Personal”. PostExterno:Externo Cargo:Cargo Jefe de area Obtener Postulante Externo Obtener Descripcion de Cargos Descripciones de Cargos Lista de Postulantes Externos Generar Contrato con Postulante Externo Contrato:Contrato Registrar Nuevo Empleado Empleado:Empleado Remover Postulante Contratado Empleado Nuevo Fuente: Elaboración Propia.Modelado del Comportamiento y Realización de los Casos de Uso por Medio de Diagramas de Secuencia Ya determinados los diagramas de clases y de casos de uso. Profesor.9. Figura 8. así como la especificación de éstos.

y por lo tanto.10 muestra la realización del caso de uso “Capacitar Empleado”. el cual trata la asignación de cursos de capacitación a los empleados para el desarrollo de habilidades requeridas en el quehacer de la organización.PostInterno:Empleado Cargo:Cargo Contrato:Contrato Jefe de area Obtener Postulantes Internos Obtener Descripciones de Cargo Descripciones de Cargo Lista de Postulantes Internos Actualizar Contrato de Empleado Actualizar Empleado Fuente: Elaboración Propia. La Figura 8.10. En el caso de tratarse de una Profesor. no posee un expediente disciplinario hasta el momento de terminada la evaluación. Diagrama de Secuencia de la Capacitación de un Empleado. En la realización del caso de uso “Evaluar Empleado” cabe la posibilidad que el empleado en cuestión sea evaluado por primera vez. Figura 8. Oscar Saavedra Rodríguez 87 . Curso:CursoCapacitacion Empleado:Empleado Jefe de area Obtener Cursos de Capacitacion Lista de Cursos de Capacitacion Obtener Empleados del Area Lista de Empleados Staff de RRHH Asignar Capacitación Lista de Empleados Designados Generar Nomina Fuente: Elaboración Propia.

A continuación se presentan los diagramas de secuencia que para los casos de uso especializados. Figura 8. Los dos diagramas siguientes representan la realización del caso de uso “Actualizar Situación del Empleado”. Esta situación queda representada en las figuras siguientes. Diagrama de Secuencia de la Primera Evaluación de un Empleado. :Empleado Empleado:Empleado Expediente:ExpedienteDisciplinario Jefe de area Obtener Empleados Conformar Equipo Equipo:EquipoEvaluador Evaluar Registrar Resultados Evaluacion:Evaluacion Evaluacion Registrada Actualizar Expediente Expediente Actualizado Fuente: Elaboración Propia. Oscar Saavedra Rodríguez 88 .nueva evaluación.11. en la cual cabe la posibilidad que el empleado en cuestión reciba una promoción por su desempeño. el expediente disciplinario ya existe. Ambas situaciones están representadas como casos de uso especializados (“Promover Empleado” y “Despedir Empleado”) del caso de uso “Actualizar Situación del Empleado”. :Empleado Empleado:Empleado Jefe de area Obtener Empleados Conformar Equipo Equipo:EquipoEvaluador Evaluar Registrar Resultados Evaluacion:Evaluacion Evaluacion Registrada Generar Expediente Disciplinario Expediente:ExpedienteDisciplinario Expediente Creado Fuente: Elaboración Propia. Profesor. Diagrama de Secuencia de la Evaluación de un Empleado. por lo que sólo debe ser actualizado incorporando los resultados de la última evaluación. así como puede ser despedido por un desempeño deficiente.12. a la que se encuentra sujeto el empleado. Figura 8.

Empleado:Empleado Cargo:Cargo Expediente:ExpedienteDisciplinario Contrato:Contrato Jefe de area Obtener Empleado Obtener Cargo Cargo Obtener Expediente Expediente Empleado Promover Empleado Actualizar Contrato Contrato Actualizado Actualizar Cargo Cargo Actualizado Empleado Ascendido Fuente: Elaboración Propia. Oscar Saavedra Rodríguez 89 .Figura 8.13. Diagrama de Secuencia de la Promoción por Desempeño de un Empleado. Profesor.

Diagrama de Secuencia del Despido por Desempeño de un Empleado. Figura 8. tanto de su estructura como de su comportamiento. se analiza el sistema desde una perspectiva estructural a través de la utilización del enfoque de base de datos. Una vez terminado el modelado del sistema de acuerdo a esta metodología. Oscar Saavedra Rodríguez 90 . Con este propósito y el apoyo de herramientas CASE.Figura 8. Empleado:Empleado Cargo:Cargo Expediente:ExpedienteDisciplinario Contrato:Contrato Jefe de area Obtener Empleado Obtener Cargo Cargo Obtener Expediente Expediente Empleado Despedir Empleado Anular Contrato Contrato Anulado Actualizar Cargo Modificar Empleado Empleado Despedido Fuente: Elaboración Propia. efectuando una conversión del diagrama de clases a un modelo conceptual de datos. en el cual se definen los identificadores que permitirán distinguir un registro de otro. La siguiente figura muestra el modelo conceptual de datos obtenido para el sistema en estudio. para luego llevar a cabo el proceso de normalización de datos. Modelo Conceptual de Datos para el Sistema de Información de RR. se puede continuar con el modelado del sistema.14. Enfoque de Base de Datos El modelado del sistema a través de los diagramas del enfoque orientado a objetos utilizando UML permite una mayor comprensión de éste.15.HH. Profesor.

Modelo Físico de Datos para el Sistema de Información de RR. Profesor. y sus posteriores correcciones de redundancias. se ha generado un modelo físico de datos con la utilización de la herramienta CASE PowerDesigner.16. Oscar Saavedra Rodríguez 91 . El modelo físico que se genera presenta las tablas que se implementará en la construcción del sistema de base de datos.Postulante <pi> A9 <M> rut nombres TXT apellidoPaterno TXT apellidoMaterno TXT fechaNacimiento D direccion TXT estadoCivil TXT estudiosBasicos TXT estudiosUniversitarios TXT tituloProfesional TXT habilidades TXT experiencia TXT trabajoAnterior TXT recomendacion TXT capacidadFisica TXT capacidadIntelectual TXT rut <pi> CursoCapacitacion <M> <pi> I codigoCurso TXT nombreCurso D fechaInicio D fechaTermino N resultados N valorCurso TXT habilidadesDesarrolladas codigoCurso <pi> Contrato Realiza numeroContrato <pi> I <M> fecha D tipoContrato TXT sueldoBruto N beneficiosMedicos TXT AFP TXT descuentosEspeciales N asignacionesEspeciales N sueldoNeto N numeroContrato <pi> Empleado antiguedad I ejecuta ExpedienteDisciplinario numeroExpediente <pi> I <M> fechaExpediente D motivo TXT unidad TXT responsable TXT recomendaciones TXT numeroExpediente <pi> genera Evaluacion fechaEvaluacion tipoEvaluacion conocimiento participacion relacionesInterpersonales trabajoEquipo liderazgo D TXT TXT TXT TXT TXT TXT (D) pertenece conforma (D) Cargo <M> <pi> I codigoCargo TXT nombreCargo TXT descripcion TXT funciones TXT responsabilidades TXT dependencia TXT subordinados codigoCargo <pi> EquipoEvaluador codigoEquipo <pi> I <M> numeroIntegrantes I codigoEquipo <pi> Es firma Externo fechaPostulacion D Fuente: Elaboración Propia. así como la definición de las claves primarias y foráneas que permitirán la compilación de información de varias tablas al definir consultas de información por medio de sentencias en SQL. Una vez generado el modelo conceptual de datos. Figura 8.HH.

fk2> FK_CONFORMA_CONFORMA_EQUIPOEV FK_EVALUACI_GENERA_EXPEDIEN EquipoEvaluador Evaluacion numeroExpediente fechaEvaluacion tipoEvaluacion conocimiento participacion relacionesInterpersonales trabajoEquipo liderazgo INTEGER <pk.fk2> FK_EXTERNO_ES_POSTULAN FK_REALIZA_REALIZA_EMPLEADO FK_EMPLEADO_ES_POSTULAN Externo rut CHAR(9) <pk.fk2> codigoCargo INTEGER <fk1> antiguedad INTEGER FK_CONTRATO_FIRMA_EMPLEADO FK_EXPEDIEN_PERTENECE_EMPLEADO FK_EMPLEADO_EJECUTA_CARGO Cargo codigoCargo nombreCargo descripcion funciones responsabilidades dependencia subordinados INTEGER <pk> NOTE NOTE NOTE NOTE NOTE NOTE FK_CONFORMA_CONFORMA_EMPLEADO ExpedienteDisciplinario numeroExpediente rut fechaExpediente motivo unidad responsable recomendaciones INTEGER <pk> CHAR(9) <fk> DATE NOTE NOTE NOTE NOTE conforma codigoEquipo INTEGER <pk. A través de las herramientas CASE. También se muestra una interfaz de la base de datos diseñada en MS Access para el ingreso de datos de los empleados. generado automáticamente con la Herramienta CASE a partir de los modelos desarrollados.17. Modelo Físico de Datos Implementado en MS Access.fk> DATE NOTE NOTE NOTE NOTE NOTE NOTE codigoEquipo INTEGER <pk> numeroIntegrantes INTEGER Fuente: Elaboración Propia. En la siguiente figura se presenta el modelo físico implementado en el DBMS MS Access. Oscar Saavedra Rodríguez 92 .fk> fechaPostulacion DATE Empleado rut CHAR(9) <pk. 10 Database Management System: Sistema Administrador de Base de Datos Profesor.fk1> rut CHAR(9) <pk. se puede llevar a cabo la creación de una base de datos para algún DBMS10 deseado y llevar a cabo la conexión del modelo físico obtenido a partir del modelo conceptual.fk1> codigoCurso INTEGER <pk.Postulante rut nombres apellidoPaterno apellidoMaterno fechaNacimiento direccion estadoCivil estudiosBasicos estudiosUniversitarios tituloProfesional habilidades experiencia trabajoAnterior recomendacion capacidadFisica capacidadIntelectual CHAR(9) <pk> NOTE NOTE NOTE DATE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE NOTE CursoCapacitacion codigoCurso nombreCurso fechaInicio fechaTermino resultados valorCurso habilidadesDesarrolladas INTEGER <pk> NOTE DATE DATE NUMERIC NUMERIC NOTE Contrato FK_REALIZA_REALIZA_CURSOCAP numeroContrato rut fecha tipoContrato sueldoBruto beneficiosMedicos AFP descuentosEspeciales asignacionesEspeciales sueldoNeto INTEGER <pk> CHAR(9) <fk> DATE NOTE NUMERIC NOTE NOTE NUMERIC NUMERIC NUMERIC Realiza rut CHAR(9) <pk. generando una aplicación utilizable en una forma mucho más óptima y rápida. Figura 8.

2: ióniabaja o aciónalta y Negociación Entrantes ad bl s Nuevos Figurae2.18. Profesor. Oscar Saavedra Rodríguez 93 . Interfaz de Ingreso de Datos para los Empleados (MS Access).Fuente: Elaboración Propia. Competencia Figura Figura Nº 2: Amenaza de Configurac Entradasde Resultados Retroaliment Amenaza Proveedor Rentabilid Sustitutos Usuarios Posibles Poder Bajas Altas 2. Figura 8.3 Barreras Esfuerzo de dentro altay VadSalida aades Productos Servicios2.4del derModelo e Instituciona sectordebient general de Am Servicios ra Sustitutoslo Perceptiva de Usuarios Centros inestable Entrantes estable Relación de Mode Modelopade Entrada l pero Educaciónla definir Sustitutos Proveedores Compradore posibleme Educación entre de s las las aleCinco (controlabl Superior estrategia Superior nte s (no Rentabil Cinco Fuerzas de e) Ni i t lbl Fuente: Elaboración Propia.

Sign up to vote on this title
UsefulNot useful