1 INTRODUCCIÓN............................................................................................................................................. 92 Ciclo de Vida de un Proyecto de software.......................................................................................................92.1 Preanálisis................................................................................................................................................... 92.2 Análisis........................................................................................................................................................ 92.3 Diseño.......................................................................................................................................................... 92.4 Codificación............................................................................................................................................... 102.5 Implementación.......................................................................................................................................... 103 UNIDAD I PREANALISIS.............................................................................................................................. 103.1 Identificación de la empresa...................................................................................................................... 103.2 Identificación de usuarios.......................................................................................................................... 103.3 Programación de entrevistas.....................................................................................................................103.4 Definición de Objetivos.............................................................................................................................. 113.5 Estado del Arte.......................................................................................................................................... 113.6 Definición de requerimientos...................................................................................................................... 113.7 Clasificación de Requerimientos................................................................................................................113.8 Evaluación de Beneficios........................................................................................................................... 113.9 Estudio de la Prefactibilidad.......................................................................................................................113.10 Estudio de Factibilidad........................................................................................................................... 123.11 Beneficios por Aumento o Incremento de la Utilidad Eficiencia..............................................................123.12 Beneficios por Reducción y/o Ahorro de Costos y/o Gastos..................................................................123.13 Planeación del Proyecto......................................................................................................................... 124 UNIDAD II ANALISIS..................................................................................................................................... 134.1 Diagramas................................................................................................................................................. 144.2 UML está compuesto por los siguientes diagramas:..................................................................................144.3 Diagramas recomendados.........................................................................................................................155 UNIDAD III DISEÑO...................................................................................................................................... 295.1 Diagrama de Interacción............................................................................................................................ 295.2 Diagrama de Secuencia............................................................................................................................. 305.3 Diagrama de Estados................................................................................................................................ 345.4 Diagrama de colaboración......................................................................................................................... 345.5 Diagrama de Actividades........................................................................................................................... 355.6 Diagrama del Negocio............................................................................................................................... 365.7 Diagrama de Despliegue........................................................................................................................... 375.8 Diagrama de Componentes.......................................................................................................................385.9 Prototipos................................................................................................................................................... 39

GLOSARIO

Actor: Un usuario externo al sistema

Autómata: En electrónica un autómata es un sistema secuencial, aunque en ocasiones la palabra es utilizada también para referirse a un robot. Puede definirse como un equipo electrónico programable en lenguaje no informático y diseñado para controlar, en tiempo real y en ambiente industrial, procesos secuenciales. Sin embargo, la rápida evolución de los autómatas hace que esta definición no esté cerrada.

Aplicación: En informática las aplicaciones son los programas con los cuales el usuario final interactúa, es decir, son aquellos programas que permiten la interacción entre el usuario y la computadora. Esta comunicación se lleva acabo cuando el usuario elige entre las diferentes opciones o realiza actividades que le ofrece el programa.

Clase: Un concepto del sistema modelado

Componente: Una pieza física de un sistema

Cliente: Es un computador que accede a recursos y servicios brindados por otro llamado Servidor

Diagrama: Flujo o Procedimiento que se realiza para representar gráficamente un sistema.

Escenario: Un conjunto de variables que para esa situación poseen un nivel de valor y un grado de ocurrencia.

Entidad: Una entidad es un objeto que existe y que es distinguible de otros objetos. Por ejemplo, Host, profesor de la Universidad USB.

Interfaz: Un conjunto de operaciones con nombre que caracteriza un comportamiento

Nodo: Un recurso computacional

Monousuario: Sistema que solo puede ser ocupado por un solo usuario

Modelo: Es una representación, en cierto medio, de algo en el mismo u otro medio. El modelo capta los aspectos importantes de lo que estamos modelando, desde cierto punto de vista, y simplifica u omite el resto. La ingeniería, la arquitectura y muchos otros campos creativos usan modelos.

Multiusuario: Varios usuarios pueden acceder a las aplicaciones y recursos del sistema.

Rol: Clasificador restringido a un uso particular en una colaboración

Subsistema: Un paquete que es tratado como una unidad con una especificación, implementación, e identidad

Servidor: En informática o computación es: Un computador que realiza algunas tareas en beneficio de otras aplicaciones llamadas clientes. Algunos servicios habituales son los servicios de archivos, que permiten a los usuarios almacenar y acceder a los archivos de un ordenador y los servicios de aplicaciones, que realizan tareas en beneficio directo del usuario final.

Sistema en red: Un Sistema de archivos de red (NFS) permite a los hosts remotos montar sistemas de archivos sobre la red e interactuar con esos sistemas de archivos como si estuvieran montados localmente. Esto permite a los administradores de sistemas consolidar los recursos en servidores centralizados en la red.

Usuario: En telecomunicaciones un usuario es la persona, organización u otra entidad que depende de los servicios de un computador o sistema computacional para obtener un resultado deseado.

UML: Lenguaje de Modelado Unificado (UML), es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar artefactos de un sistema de software.

Tipo de dato: Un descriptor de un conjunto de valores primitivos que carecen de identidad

Relación: Cuando se formula una expresión que liga dos o más objetos entre sí.

PRESENTACIÓN DE LA MATERIA

La asignatura Análisis y Diseño, forma parte de la estructura del programa Técnico Desarrollo de Software que se imparte en el centro de estudios especializados CESDE. Esta asignatura se orienta en el tercer semestre y tiene una intensidad de 2 horas semanales presénciales y 1 hora de trabajo independiente, durante 18 horas de clase, para un total de 36 horas de clase en el semestre,(54 horas tomando la clase independiente). Hace parte del ejercicio de la profesión y se convierte en una asignatura del eje transversal del programa, pues, permite a lo largo de los diferentes semestres interactuar con el entorno de las herramientas.

Problema.

El desarrollo de aplicaciones informáticas, requiere de un proceso de gestión donde se defina el conjunto de actividades que se deben estimar antes de iniciar con la solución sistematizada; esto garantiza la fiabilidad y deja de lado los posibles errores en el diseño del proyecto, que pueden entorpecer y hasta hacer fracasar todo el desarrollo del programa.

Objeto.Análisis y Diseño de una Aplicación Informática con UML.

Objetivo.

Al finalizar la asignatura, el estudiante estará en capacidad de realizar el análisis y el diseño de una aplicación, de manera que la fase de programación se haga de una manera organizada y que el producto final satisfaga las necesidades de información del usuario.

Sistema de Conocimientos. Recolección de información sobre las necesidades del usuario. Análisis de las necesidades del usuario. Planeación del trabajo con base en la teoría de análisis orientado a objetos. Utilización de parte de la metodología UML. Esquematizar las especificaciones del software propuesto.

Sistemas de habilidades. Metodología para la recopilación de la información necesaria. Esquematización de la propuesta de un software determinado. Apropiación de la teoría del análisis orientado a objetos. Utilización de las principales herramientas de UML.

Sistema de valores

Organización, Dedicación, Lógica, Atención a usuarios, Trabajo en Equipo, Comunicación e interpretación.

Metodología: Exposición magistral del docente (o con proyector), explicando los conceptos o contenidos temáticos de la unidad. Ejemplos demostrativos.

Medios: Marcador y tablero. Modulo. Video beam. Fotocopias con ejercicios. Talleres. Sala de Sistemas.

Evaluación: Quices teóricos individuales y en parejas. Talleres prácticos individuales. Talleres prácticos en parejas. Trabajo Independiente.

Docente: Asignatura: Análisis y Diseño

1 INTRODUCCIÓN

En el proceso de enseñanza del Análisis y Diseño de Sistemas de Información, el estudiante debe adquirir sistemáticamente unos conocimientos y destrezas que le permitan enfrentarse satisfactoriamente a problemas de la vida real, dándoles soluciones científicas y de acuerdo a normativas y estándares para el desarrollo de software.

En los primeros semestres, el alumno adquiere los conocimientos básicos de manejo de herramientas informáticas para aplicarlas en la elaboración de programas de computador, pero debido a su nivel de conocimientos estas herramientas se utilizan en programas de pequeño alcance y bajo la supervisión del docente, quien determina las necesidades del software y que herramientas debe utilizar.

Diferencia entre dato e información.

Datos: Son hechos, observaciones o sucesos independientes, que pueden tomar la forma de números, letras y símbolos. Los datos por si solos no tienen un significado directo.

Información: Es el resultado de procesar, evaluar o analizar los datos.

DATOS PROCESO INFORMACION

2 Ciclo de Vida de un Proyecto de software

2.1 PreanálisisCobija básicamente el estudio del usuario de un proyecto, con el fin de determinar si un sistema particular será desarrollado, respondiendo a la pregunta de ¿qué tan factible es, económica, técnica y operativamente?

Entradas: Declaración de las necesidades del usuario sobre el sistema de información específico.Salidas  : Documento con el estudio de factibilidades.

2.2 Análisis.Es la colección, organización y evaluación de hechos de un sistema y del medio ambiente en el cual opera con el objeto de establecer las bases de un nuevo sistema. Responde a la pregunta de ¿qué es lo que va a hacer el nuevo sistema?

Entradas: Estudio de factibilidad y requerimientos más detallados.Salidas : Modelo de funcionamiento del sistema con las especificaciones a través de un documento.

2.3 Diseño.Responde a la pregunta de ¿cómo se va a hacer el sistema? Consta de dos partes:

Diseño global (Prototipos)

Es la concepción global y estructural del sistema, en la que se definen las interfaces y módulos del sistema.

Entradas: Especificaciones del análisis.Salidas : Descripción estructural del sistema, por medio de diagramas estructurados.

Diseño detallado.En esta parte cada módulo se detalla al máximo.

Entradas: Diagramas estructurados.Salidas : Seudocódigo2.4 Codificación.Es la programación en un lenguaje específico.

Entradas: Seudocódigo y/o algoritmosSalidas : Programa en el lenguaje fuente.

2.5 Implementación.Valida el sistema con datos ficticios y luego con datos reales.

Entradas: Programas.Salidas : Sistema disponible.

3 UNIDAD I PREANALISIS

En esta primera etapa se adquiere por parte del analista un conocimiento global del sistema a desarrollar mediante entrevistas con los diferentes usuarios con el fin de conocer las necesidades de estos y determinar la viabilidad del sistema.

3.1 Identificación de la empresaComo una primera actividad a realizar está la descripción de la empresa donde se instalará el sistema propuesto, detallando La Razón social, el sector al que pertenece, los productos que ofrece ,el tamaño de la empresa, de etc. También se recomienda presentar un organigrama de la empresa con el fin de dar una visión clara de la ubicación del área donde se realizará el sistema con respecto a las otras áreas, ya que estas serán las que interactuarán con el sistema en estudio.

3.2 Identificación de usuariosEn esta actividad es importante identificar todos los posibles usuarios y su TIPO, al usuario RESPONSABLE y los diferentes usuarios FINALES.

El usuario RESPONSABLE es aquel que perteneciendo a la realidad de aplicación, ejerce autoridad directa sobre la futura operación del sistema o le ha sido encargada como función el dirigir el proyecto a modo de usuario.

Los usuarios FINALES son todos aquellos que utilizan de modo directo el sistema a través de algunas de sus funciones (entrada de datos, consulta, reportes, etc.).

3.3 Programación de entrevistasUna vez identificados los usuarios, se deben programar las reuniones con los usuarios más relevantes.

Es conveniente una reunión general de todos los usuarios, en la cual expresarán los objetivos del proyecto y brindarán apoyo para la labor del personal de desarrollo.

Para las entrevistas en general deben contemplarse los siguientes aspectos: Las entrevistas deben formalizarse con fecha y hora. Para toda entrevista deben definirse los objetivos. El analista debe siempre realizar un acta de reunión, resumiendo los resultados. Todos los resultados deben ser aprobados por el usuario responsable.

3.4 Definición de Objetivos Como objetivos del sistema a proponer se tienen: Uno general y varios específicos. Estos objetivos deben determinarse en forma clara y precisa y no deben utilizarse términos vagos o ambiguos. Se debe distinguir entre lo que el usuario necesita y lo que él desea. Lo que se necesita corresponde a los elementos críticos para la realización del proyecto y lo que se quiere corresponde a elementos deseables pero no esenciales.

Es muy importante la precisión de estos objetivos para la determinación del desarrollo del sistema, y ser  contra ellos que se va a evaluar el progreso del proyecto.

3.5 Estado del ArteEs averiguar cómo se encuentra y cómo se está manejando actualmente el negocio que compete al software que se está planeando, respondiendo a las siguientes preguntas:¿Se está empleando en la actualidad algún software específico para el proceso?¿Se está empleando alguna herramienta genérica para el proceso (Excel, Word, Access, etc.)?¿Se está trabajando el proceso manualmente?¿Qué formatos impresos y/o digitales se manejan para llevar el proceso?¿Tienen algún servicio Out-Sourcing contratado?.Etcétera.

Después de hacer este análisis, se deben identificar las Debilidades, Oportunidades, Fortalezas y Amenazas (DOFA) y esto se tendrá en cuenta para el nuevo software que se está planeando. 3.6 Elaborar el diagrama general de casos de usoEl diagrama de casos de uso (Use Case Diagram) es una representación gráfica de parte o el total de los actores y casos de uso del sistema, incluyendo sus interacciones. Todo sistema tiene como mínimo un diagrama Main Use Case (Diagrama principal de casos de uso), que es una representación gráfica del entorno del sistema (actores) y su funcionalidad principal (casos de uso). Un diagrama de casos de uso muestra, por tanto, los distintos requisitos funcionales que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuarios u otras aplicaciones), pero no se acostumbra mostrar las relaciones entre los diferentes casos de uso. Ejemplo:

3.7 Definición de requerimientosEn las entrevistas con los diferentes usuarios, se deben identificar que es lo que ellos pretenden que el nuevo sistema les proporcione. Un requerimiento debe ser necesario, conciso, completo, consistente, no ambiguo y verificable.Los requerimientos se clasifican así:

o Consultas: Se define como consultas todos aquellos accesos interactivos a la base de datos con el fin de obtener una respuesta inmediata.

TIPO: Consulta CÓDIGO: R1USUARIO

oooo /Informeso Almacenamiento

3.8 Evaluación de BeneficiosEn esta fase correspondiente estudiar todos los antecedentes que permitan formar juicio respecto a la conveniencia y factibilidad técnico –económico de llevar a cabo la idea del proyecto. En la evaluación se deben determinar y explicitar los beneficios y costos del proyecto para lo cual se requiere definir previa y precisamente la situación "sin proyecto", es decir, prever que sucederá en el horizonte de evaluación si no se ejecuta el proyecto.

En primer lugar, analizar su viabilidad técnica de las alternativas propuestas, descartando las que no son factibles técnicamente. En esta fase corresponde además evaluar las alternativas técnicamente factibles. En los proyectos que involucran inversiones pequeñas y cuyo perfil muestra la conveniencia de su implementación, cabe avanzar directamente al diseño o anteproyecto en detalle.

3.9 Estudio de la Prefactibilidad.En esta fase se examinan en detalles las alternativas consideradas más convenientes, las que fueron determinadas en general en la fase anterior. Para la elaboración del informe de prefactibilidad del proyecto deben analizarse en detalle los aspectos identificados especialmente los que inciden en la factibilidad y rentabilidad de las posibles alternativas. Entre estos aspectos sobresalen:

El mercado. La tecnología. El tamaño y la localización. Las condiciones de orden institucional y legal.

3.10 Estudio de FactibilidadEsta ultima fase de aproximaciones sucesivas iniciadas en la preinversión, se bordan los mismos puntos de la prefactibilidad. Además de profundizar el análisis el estudio de las variables que inciden en el proyecto, se minimiza la variación esperada de sus costos y beneficios. Para ello es primordial la participación de especialistas, además de disponer de información confiable.Sobre la base de las recomendaciones hechas en el informe de prefactibilidad, y que han sido incluidas en los términos de referencia para el estudio de factibilidad, se deben definir aspectos técnicos del proyecto, tales como localización, tamaño, tecnología, calendario de ejecución y fecha de puesta en marcha. El estudio de factibilidad debe orientarse hacia el examen detallado y preciso de la alternativa que se ha considerado viable en la etapa anterior. Además, debe afinar todos aquellos aspectos y variables que puedan mejorar el proyecto, de acuerdo con sus objetivos, sean sociables o de rentabilidad.

VALOR TOTAL = Unidades a Valorizar * Tasa de Valor

Los beneficios se pueden clasificar de la siguiente manera:

3.11 Beneficios por Aumento o Incremento de la Utilidad Eficiencia Son todos Beneficios que directamente signifiquen una mayor ganancia (como se entiende generalmente a la utilidad, aunque no necesariamente esta es de tipo monetaria) o que representan un aumento en la capacidad y velocidad actual de procesamiento.

3.12 Beneficios por Reducción y/o Ahorro de Costos y/o Gastos Son aquellos beneficios que de una forma directa por la implantación del sistema, permiten disminuir los recursos asignados a este proceso o asociados a gastos que conlleva el tener los recursos asignados y el proceso funcionado, entre estos están:

Disminución de personal fijo o temporal Disminución de área requerida por el proceso Disminución de gastos de papelería Disminución de gastos de mantenimiento Ahorro en costos de almacenaje Disminución del inventario Reducción de costos en procesamiento de datos

3.13 Planeación del Proyecto

Estimación del Esfuerzo Requerido En el desarrollo de un proyecto se tiene tres variables dependientes:

Cantidad de Esfuerzo Tiempo de Duración Personal Asignado

En un proyecto se puede estimar un esfuerzo de 1000 horas-hombre para durar 1000 horas si lo realiza 1 hombre, y al utilizar más hombres debe realizarse en menos tiempo. Pero siempre hay un número óptimo de personas para terminar, de tal forma que al adicionar personal se encarecerá el proyecto. El esfuerzo requerido puede encontrarse a través de la medición de los requerimientos para las entradas, informes, consultas, almacenamientos e interfaces externas y aplicando criterios de Análisis y Programación. El tiempo de duración esperado para el proyecto se determina a partir de los recursos humanos y su calidad o categoría.

Calendario de EjecuciónSiguiendo los estándares de análisis y programación, se elabora el diagrama de barras o de Gannt, con el cual se facilita el seguimiento y control de las actividades mediante los tiempos de iniciación y terminación con las respectivas revisiones y ajustes periódicos.

Ejemplo:

ACTIVIDADES SEMANAS

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.EntrevistasPreanálisisAnálisisDiseñoPrototipos

Ejemplo de DIAGRAMA DE GANNT

4 UNIDAD II ANALISIS

Introducción a UML

Desde los inicios de la informática se han estado utilizando distintas formas de representar los diseños de una manera más bien personal o con algún modelo gráfico, La falta de estandarización en la representación gráfica de un modelo impedía que los diseños gráficos realizados se pudieran compartir fácilmente entre distintos diseñadores, con este objetivo se creo el Lenguaje Unificado de Modelado (UML: Unified Modeling Language).

El Lenguaje de Modelamiento Unificado (UML - Unified Modeling Language) es un lenguaje gráfico para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de modelar cosas conceptuales como lo son procesos de negocio y funciones de sistema, además de cosas concretas como lo son escribir clases en un lenguaje determinado, esquemas de base de datos y componentes de software reusables.

UML es una especificación de notación orientada a objetos. Se basa en las anteriores especificaciones BOOCH, RUMBAUGH y COAD-YOURDON. Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto.

Con UML nos debemos olvidar del protagonismo excesivo que se le da al diagrama de clases, este representa una parte importante del sistema, pero solo representa una vista estática, es decir muestra al sistema parado. Sabemos su estructura pero no sabemos que le sucede a sus diferentes partes cuando el sistema empieza a funcionar. UML introduce nuevos diagramas que representa una visión dinámica del sistema. Es decir, gracias al diseño de la parte dinámica del sistema podemos darnos cuenta en la fase de diseño de problemas de la estructura al propagar errores o de las partes que necesitan ser sincronizadas, así como del estado de cada una de las instancias en cada momento. El diagrama de clases continua siendo muy importante, pero se debe tener en cuenta que su representación es limitada, y que ayuda a diseñar un sistema robusto con partes reutilizables, pero no a solucionar problemas de propagación de mensajes ni de sincronización o recuperación ante estados de error. En resumen, un sistema debe estar bien diseñado, pero también debe funcionar bien.

UML también intenta solucionar el problema de propiedad de código que se da con los desarrolladores, al implementar un lenguaje de modelado común para todos los desarrollos se crea una documentación también común, que cualquier desarrollador con conocimientos de UML será capaz de entender, independientemente del lenguaje utilizado para el desarrollo.

4.1 Diagramas.

4.2 UML está compuesto por los siguientes diagramas:

Área Vista Diagramas Conceptos Principales

Estructural

Vista Estática Diagrama de Clases Clase, asociación, generalización, dependencia, realización, interfaz.

Vista de Casos de Uso Diagramas de Casos de Uso

Caso de Uso, Actor, asociación, extensión, generalización.

Vista de Implementación Diagramas de Componentes Componente, interfaz, dependencia, relaización.

Vista de Despliegue Diagramas de Despliegue Nodo, componente, dependencia, localización.

Dinámica

Vista de Estados de máquina Diagramas de Estados Estado, evento, transición, acción.

Vista de actividad Diagramas de Actividad Estado, actividad, transición, determinación, división, unión.

Vista de interacción

Diagramas de Secuencia Interacción, objeto, mensaje, activación.

Diagramas de Colaboración Colaboración, interacción, rol de colaboración, mensaje.

Administración o Gestión de modelo

Vista de Gestión de modelo Diagramas de Clases Paquete, subsistema, modelo.

Extensión de UML Todas Todos Restricción, estereotipo, valores, etiquetados.

La explicación se basará en los diagramas o vistas, ya que son estos la esencia de UML. Cada diagrama usa la anotación pertinente y la suma de estos diagramas crean las diferentes vistas. Las vistas existentes en UML son:

Vista casos de uso: Se forma con los diagramas de casos de uso, colaboración, estados y actividades. Vista de diseño: Se forma con los diagramas de clases, objetos, colaboración, estados y actividades. Vista de procesos: Se forma con los diagramas de la vista de diseño. Recalcando las clases y objetos

referentes a procesos. Vista de implementación: Se forma con los diagramas de componentes, colaboración, estados y

actividades. Vista de despliegue: Se forma con los diagramas de despligue, interacción, estados y actividades.

Se Dispone de dos tipos diferentes de diagramas los que dan una vista estática del sistema y los que dan una visión dinámica. Los diagramas estáticos son:

Diagrama de clases: muestra las clases, interfaces, colaboraciones y sus relaciones. Son los más comunes y dan una vista estática del proyecto.

Diagrama de objetos: Es un diagrama de instancias de las clases mostradas en el diagrama de clases. Muestra las instancias y como se relacionan entre ellas. Se da una visión de casos reales.

Diagrama de componentes: Muestran la organización de los componentes del sistema. Un componente se corresponde con una o varias clases, interfaces o colaboraciones.

Diagrama de despliegue.: Muestra los nodos y sus relaciones. Un nodo es un conjunto de componentes. Se utiliza para reducir la complejidad de los diagramas de clases y componentes de un gran sistema. Sirve como resumen e índice.

Diagrama de casos de uso: Muestran los casos de uso, actores y sus relaciones. Muestra quien puede hacer que y relaciones existen entre acciones (casos de uso). Son muy importantes para modelar y organizar el comportamiento del sistema.

Los diagramas dinámicos son:

Diagrama de secuencia, Diagrama de colaboración: Muestran a los diferentes objetos y las relaciones que pueden tener entre ellos, los mensajes que se envían entre ellos. Son dos diagramas diferentes,

que se puede pasar de uno a otro sin perdida de información, pero que nos dan puntos de vista diferentes del sistema. En resumen, cualquiera de los dos es un Diagrama de Interacción.

Diagrama de estados: muestra los estados, eventos, transiciones y actividades de los diferentes objetos. Son útiles en sistemas que reaccionen a eventos.

Diagrama de actividades: Es un caso especial del diagrama de estados. Muestra el flujo entre los objetos. Se utilizan para modelar el funcionamiento del sistema y el flujo de control entre objetos.

Como podemos ver el número de diagramas es muy alto, en la mayoría de los casos excesivos, y UML permite definir solo los necesarios, ya que no todos son necesarios en todos los proyectos. En el Módulo se dará una breve explicación de todos, ampliándose para los más necesarios.

4.3 Diagramas recomendados

Los diagramas a representar dependerán del sistema a desarrollar, para ello se efectúan las siguientes recomendaciones dependiendo del sistema. Estas recomendaciones se deberán adaptar a las características de cada desarrollo, y seguramente será la práctica la que nos diga que diagramas serán los necesarios.

Aplicación monousuario Diagrama de casos de uso. Diagrama de clases. Diagrama de Interacción.

Aplicación monousuario, con entrada de eventos: Añadir: Diagrama de estados.

Aplicación cliente servidor: Añadir: Diagrama de despliegue y diagrama de componentes, dependiendo de la complejidad.

Aplicación compleja distribuida: Todos.

Así tenemos que para una aplicación sencilla debemos realizar entre tres y seis tipos de diagramas, y para una aplicación compleja unos nueve tipos. ¿Es esto demasiado trabajo? En un principio no lo parece, ya que el tiempo dedicado a la realización de los diagramas es proporcional al tamaño del producto a realizar, no entraremos en la discusión de que el tiempo de diseño no es tiempo perdido si no ganado. Para la mayoría de los casos tendremos suficiente con tres o cuatro diagramas. Debemos pensar que UML esta pensado para el modelado tanto de pequeños sistemas como de sistemas complejos, y debemos tener en cuenta que los sistemas complejos pueden estar compuestos por millones de líneas de código y ser realizados por equipos de centenares de programadores. Así que no debemos preocuparnos, el mayor de nuestros proyectos, desde el punto de vista de UML no deja de ser un proyecto mediano tirando a pequeño.

Diagrama de Casos de Uso

El diagrama de casos de uso representa la forma en como un Cliente (Actor) opera con el sistema en desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso).

Un diagrama de casos de uso consta de los siguientes elementos:

Actor. Casos de Uso. Relaciones de Uso, Herencia y Comunicación.

Elementos

Actor:

Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una persona en particular, sino más bien la labor que realiza frente al sistema.

Como ejemplo a la definición anterior, tenemos el caso de un sistema de ventas en que el rol de Vendedor con respecto al sistema puede ser realizado por un Vendedor o bien por el Jefe de Local.

Caso de Uso:

Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una petición de un actor o bien desde la invocación desde otro caso de uso.

Sistema

Actor A

Caso de uso X

Actor B

Caso de uso Y

Relaciones:

o Asociación

Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso de uso). Dicha relación se denota con una flecha simple.

o Dependencia o Instanciación

Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se instancia (se crea). Dicha relación se denota con una flecha punteada.

o Generalización

Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo, que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).

Este tipo de relación esta orientado exclusivamente para casos de uso (y no para actores).

extends: Se recomienda utilizar cuando un caso de uso es similar a otro (características).

uses: Se recomienda utilizar cuando se tiene un conjunto de características que son similares en más de un caso de uso y no se desea mantener copiada la descripción de la característica.

De lo anterior cabe mencionar que tiene el mismo paradigma en diseño y modelamiento de clases, en donde esta la duda clásica de usar o heredar.

Ejemplo:

Como ejemplo esta el caso de una Máquina Recicladora:

Sistema que controla una máquina de reciclamiento de botellas, tarros y jabas. El sistema debe controlar y/o aceptar:

Registrar el número de ítems ingresados. Imprimir un recibo cuando el usuario lo solicita:

a. Describe lo depositado b. El valor de cada item c. Total

El usuario/cliente presiona el botón de comienzo Existe un operador que desea saber lo siguiente:

a. Cuantos ítems han sido retornados en el día. b. Al final de cada día el operador solicita un resumen de todo lo depositado en el día.

El operador debe además poder cambiar: a. Información asociada a items. b. Dar una alarma en el caso de que:

i. Item se atora. ii. No hay más papel.

Como una primera aproximación identificamos a los actores que interactúan con el sistema:

Luego, tenemos que un Cliente puede Depositar Ítems y un Operador puede cambiar la información de un Ítem o bien puede Imprimir un informe:

Además podemos notar que un ítem puede ser una Botella, un Tarro o una Jaba.

Otro aspecto es la impresión de comprobantes, que puede ser realizada después de depositar algún ítem por un cliente o bien puede ser realizada a petición de un operador.

Entonces, el diseño completo del diagrama Use Case es:

Casos de Uso: Documentación

Un caso de uso debe ser simple, claro y conciso Generalmente hay pocos actores asociados a cada Caso de Uso Preguntas clave:

• ¿cuáles son las tareas del actor?• ¿qué información crea, guarda, modifica, destruye o lee el actor?• ¿debe el actor notificar al sistema los cambios externos?

• ¿debe el sistema informar al actor de los cambios internos?

La descripción del Caso de Uso comprende:

• el inicio: cuándo y qué actor lo produce?• el fin: cuándo se produce y qué valor devuelve?• la interacción actor-caso de uso: qué mensajes intercambian ambos?• objetivo del caso de uso: ¿qué lleva a cabo o intenta?• cronología y origen de las interacciones• repeticiones de comportamiento: ¿qué operaciones son iteradas?• situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el caso de uso?

Nombre: Crear mensaje foro

Autor: Oscar Gil

Fecha: 15/01/2007

Descripción:      Permite crear un mensaje en el foro de discusión.

Actores:      Usuario de Internet logeado.

Precondiciones:      El usuario debe haberse logeado en el sistema.

Flujo Normal:

1. El actor pulsa sobre el botón para crear un nuevo mensaje.2. El sistema muestra una caja de texto para introducir el título del mensaje y una zona de mayor tamaño

para introducir el cuerpo del mensaje.3. El actor introduce el título del mensaje y el cuerpo del mismo.4. El sistema comprueba la validez de los datos y los almacena.

Flujo Alternativo:

4. El sistema comprueba la validez de los datos, si los datos no son correctos, se avisa al actor de ello permitiéndole que los corrija

Poscondiciones:      El mensaje ha sido almacenado en el sistema.

Antes de centrarnos en el diagrama de clases vamos a revisar un concepto muy importante sobre el Diagrama Conceptual, que no es más que todas las tablas de nuestro aplicativo sin relaciones.Ejemplo:

Diagrama de Clases

Un diagrama de clases sirve para visualizar las relaciones entre las clases que involucran el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento.

Un diagrama de clases esta compuesto por los siguientes elementos:

Clase: atributos, métodos y visibilidad. Relaciones: Herencia, Composición, Agregación, Asociación y Uso.

Elementos

Clase

Es la unidad básica que encapsula toda la información de un Objeto (un objeto es una instancia de una clase). A través de ella podemos modelar el entorno en estudio (una Casa, un Auto, una Cuenta Corriente, etc.).

En UML, una clase es representada por un rectángulo que posee tres divisiones:

En donde:

o Superior: Contiene el nombre de la Clase o Intermedio: Contiene los atributos (o variables de instancia) que caracterizan a la Clase

(pueden ser private, protected o public). o Inferior: Contiene los métodos u operaciones, los cuales son la forma como interactúa el objeto

con su entorno (dependiendo de la visibilidad: private, protected o public).

Ejemplo:

Una Cuenta Corriente que posee como característica:

o Balance

Puede realizar las operaciones de:

o Depositar o Girar o y Balance

El diseño asociado es:

Atributos y Métodos:

o Atributos:

Los atributos o características de una Clase pueden ser de tres tipos, los que definen el grado de comunicación y visibilidad de ellos con el entorno, estos son:

public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden accesar).

protected (#, ): Indica que el atributo no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de las subclases que se deriven (ver herencia).

o Métodos:

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

public (+, ): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accsesible desde todos lados.

private (-, ): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la clase lo pueden accesar).

protected (#, ): Indica que el método no será accesible desde fuera de la clase, pero si podrá ser accesado por métodos de la clase además de métodos de las subclases que se deriven (ver herencia).

Relaciones entre Clases:

Ahora ya definido el concepto de Clase, es necesario explicar como se pueden interrelacionar dos o más clases (cada uno con características y objetivos diferentes).

Antes es necesario explicar el concepto de cardinalidad de relaciones: En UML, la cardinalidad de las relaciones indica el grado y nivel de dependencia, se anotan en cada extremo de la relación y éstas pueden ser:

o uno o muchos: 1..* (1..n) o 0 o muchos: 0..* (0..n) o número fijo: m (m denota el número).

Herencia (Especialización/Generalización):

Indica que una subclase hereda los métodos y atributos especificados por una Super Clase, por ende la Subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la Super Clase (public y protected), ejemplo:

En la figura se especifica que Auto y Camión heredan de Vehículo, es decir, Auto posee las Características de Vehículo (Precio, VelMax, etc) además posee algo particular que es

Descapotable, en cambio Camión también hereda las características de Vehiculo (Precio, VelMax, etc) pero posee como particularidad propia Acoplado, Tara y Carga.

Cabe destacar que fuera de este entorno, lo único "visible" es el método Caracteristicas aplicable a instancias de Vehículo, Auto y Camión, pues tiene definición pública, en cambio atributos como Descapotable no son visibles por ser privados.

Agregación:

Para modelar objetos complejos, n bastan los tipos de datos básicos que proveen los lenguajes: enteros, reales y secuencias de caracteres. Cuando se requiere componer objetos que son instancias de clases definidas por el desarrollador de la aplicación, tenemos dos posibilidades:

Por Valor: Es un tipo de relación estática, en donde el tiempo de vida del objeto incluido esta condicionado por el tiempo de vida del que lo incluye. Este tipo de relación es comúnmente llamada Composición (el Objeto base se construye a partir del objeto incluido, es decir, es "parte/todo").

Por Referencia: Es un tipo de relación dinámica, en donde el tiempo de vida del objeto incluido es independiente del que lo incluye. Este tipo de relación es comúnmente llamada Agregación (el objeto base utiliza al incluido para su funcionamiento).

Un Ejemplo es el siguiente:

En donde se destaca que:

Un Almacen posee Clientes y Cuentas (los rombos van en el objeto que posee las referencias).

Cuando se destruye el Objeto Almacen también son destruidos los objetos Cuenta asociados, en cambio no son afectados los objetos Cliente asociados.

La composición (por Valor) se destaca por un rombo relleno. La agregación (por Referencia) se destaca por un rombo transparente.

La flecha en este tipo de relación indica la navegabilidad del objeto referenciado. Cuando no existe este tipo de particularidad la flecha se elimina.

Asociación:

La relación entre clases conocida como Asociación, permite asociar objetos que colaboran entre si. Cabe destacar que no es una relación fuerte, es decir, el tiempo de vida de un objeto no depende del otro.

Ejemplo:

Un cliente puede tener asociadas muchas Ordenes de Compra, en cambio una orden de compra solo puede tener asociado un cliente.

Dependencia o Instanciación (uso):

Representa un tipo de relación muy particular, en la que una clase es instanciada (su instanciación es dependiente de otro objeto/clase). Se denota por una flecha punteada.

El uso más particular de este tipo de relación es para denotar la dependencia que tiene una clase de otra, como por ejemplo una aplicación grafica que instancia una ventana (la creación del Objeto Ventana esta condicionado a la instanciación proveniente desde el objeto Aplicación):

Cabe destacar que el objeto creado (en este caso la Ventana gráfica) no se almacena dentro del objeto que lo crea (en este caso la Aplicación).

Casos Particulares:

o Clase Abstracta:

Una clase abstracta se denota con el nombre de la clase y de los métodos con letra "itálica". Esto indica que la clase definida no puede ser instanciada pues posee métodos abstractos (aún no han sido definidos, es decir, sin implementación). La única forma de utilizarla es definiendo subclases, que implementan los métodos abstractos definidos.

o Clase parametrizada:

Una clase parametrizada se denota con un subcuadro en el extremo superior de la clase, en donde se especifican los parámetros que deben ser pasados a la clase para que esta pueda ser instanciada. El ejemplo más típico es el caso de un Diccionario en donde una llave o palabra tiene asociado un significado, pero en este caso las llaves y elementos pueden ser genéricos. La genericidad puede venir dada de un Template (como en el caso de C++) o bien de alguna estructura predefinida (especialización a través de clases).

En el ejemplo no se especificaron los atributos del Diccionario, pues ellos dependerán exclusivamente de la implementación que se le quiera dar.

Ejemplo:

Supongamos que tenemos el caso del Diccionario implementado mediante un árbol binario, en donde cada nodo posee:

key: Variable por la cual se realiza la búsqueda, puede ser generica. ítem: Contenido a almacenar en el diccionario asociado a "key", cuyo tipo también puede ser genérico.

Para este caso particular hemos definido un Diccionario para almacenar String y Personas, las cuales pueden funcionar como llaves o como ítem, solo se mostrarán las relaciones para la implementación del Diccionario:

5 UNIDAD III DISEÑO

5.1 Diagrama de Interacción

El diagrama de interacción, representa la forma en como un Cliente (Actor) u Objetos (Clases) se comunican entre si en petición a un evento. Esto implica recorrer toda la secuencia de llamadas, de donde se obtienen las responsabilidades claramente.

Dicho diagrama puede ser obtenido de dos partes, desde el Diagrama Estático de Clases o el de Casos de Uso (son diferentes).

Los componentes de un diagrama de interacción son:

Un Objeto o Actor. Mensaje de un objeto a otro objeto. Mensaje de un objeto a si mismo.

Elementos

Objeto/Actor:

El rectángulo representa una instancia de un Objeto en particular, y la línea punteada representa las llamadas a métodos del objeto.

Mensaje a Otro Objeto:

Se representa por una flecha entre un objeto y otro, representa la llamada de un método (operación) de un objeto en particular.

Mensaje al Mismo Objeto:

No solo llamadas a métodos de objetos externos pueden realizarse, también es posible visualizar llamadas a métodos desde el mismo objeto en estudio.

Ejemplo

En el presente ejemplo, tenemos el diagrama de interacción proveniente del siguiente modelo estático:

Aquí se representa una aplicación que posee una Ventana gráfica, y ésta a su vez posee internamente un botón.

5.2 Diagrama de Secuencia

En donde se hacen notar las sucesivas llamadas a Draw () (entre objetos)

Diagrama de secuencia Reserva de Habitación

: Socio : Encargado : Libro : Ficha libro : Ficha socio : Préstamo

Coger libro

Solicitar préstamo

Verificar situación socio

Situación socio ok

Verificar situación libro

Situación libro ok

Introducir préstamo

Autorizar préstamo

Diagrama de secuencia Llamada Telefónica

Quien llama Línea telefónica Llamado

descuelga

tono

marcar

indicación de llamada timbre

descuelga

diga?

Diagrama de secuencia Reserva de Libro

5.3 Diagrama de Estados

Los Diagramas de Estados representan autómatas de estados finitos, de los estados y las transiciones Son útiles sólo para los objetos con un comportamiento significativo El resto de objetos se puede considerar que tienen un único estado El estado en el que se encuentra un objeto determina su comportamiento Cada objeto sigue el comportamiento descrito en el D. de Estados asociado a su clase Los D. De Estados y escenarios son complementarios Los D. de Estados son autómatas jerárquicos que permiten expresar concurrencia, sincronización y

jerarquías de objetos Los Diagramas de Estados son grafos dirigidos Los D. De Estados de UML son deterministas Los estados inicial y final están diferenciados del resto La transición entre estados es instantánea y se debe a la ocurrencia de un evento

Ejemplo:

5.4 Diagrama de colaboración

Los diagramas de interacción (diagramas de secuencia y diagramas de colaboración) explican gráficamente cómo los objetos interactúan a través de mensajes para realizar las tareas.

Antes de definir estos diagramas, hay que generar el modelo conceptual y los casos de uso reales (estos últimos se generan a partir de los casos de uso definidos en el análisis).

en el paro en activo

jubilado

contratar

perder empleo

jubilarsejubilarse

Ejemplo:

El diagrama de colaboración del caso de uso pasarProducto seríael siguiente:

5.5 Diagrama de Actividades

El Diagrama de Actividades es una variante de los Diagramas de Estados, organizado respecto de las acciones y principalmente destinado a representar el comportamiento interno de un método

Una actividad puede considerarse un estereotipo de estado Las actividades se enlazan por transiciones automáticas Cuando una actividad termina se desencadena el paso a la siguiente actividad Las actividades no poseen transiciones internas ni transiciones desencadenadas por eventos

Buscar Bebida

Poner café en filtro Añadir agua al depósito Coger taza

Poner filtro en máquina

Encender máquina

Café en preparación

Servir café

Coger zumo

Beber

[hay café[hay zumo]

^cafetera.On

indicador de fin

5.6 Diagrama del Negocio

Es la forma de representar a cada actor con su respectivo rol en un escenario

Pasajero Vendedor Airline

Emitir billete

Solicitar pago Reservar plazas

Confirmar plaza reservada

Pagar pasaje

Informar alternativas y precios

Verificar existencia vuelo

Dar detalles vuelo

Solicitar pasaje

Seleccionar vuelo

En esta gráfica podemos notar una nueva forma de unir 2 procesos y llegar al objetivo del propuesto emitir un billete

5.7 Diagrama de Despliegue

Los Diagramas de Despliegue muestran la disposición física de los distintos nodos que componen un sistema y el reparto de los componentes sobre dichos nodos. La vista de despliegue representa la disposición de las instancias de componentes de ejecución en instacias de nodos conectados por enlaces de comunicación. Un nodo es un recurso de ejecución tal como un computador, un dispositivo o memoria. Los estereotipos permiten precisar la naturaleza del equipo:

Dispositivos Procesadores Memoria

5.8 Diagrama de Componentes

Los diagramas de componentes describen los elementos físicos del sistema y sus relaciones. Muestran las opciones de realización incluyendo código fuente, binario y ejecutable. Los componentes representan todos los tipos de elementos software que entran en la fabricación de aplicaciones informáticas. Pueden ser simples archivos, paquetes de Ada, bibliotecas cargadas dinámicamente, etc. Las relaciones de dependencia se utilizan en los diagramas de componentes para indicar que un componente utiliza los servicios ofrecidos por otro componente.

Un diagrama de componentes representa las dependencias entre componentes software, incluyendo componentes de código fuente, componentes del código binario, y componentes ejecutables. Un módulo de software se puede representar como componente. Algunos componentes existen en tiempo de compilación, algunos en tiempo de enlace y algunos en tiempo de ejecución, otros en varias de éstas. Un componente de sólo compilación es aquel que es significativo únicamente en tiempo de compilación. Un componente ejecutable es un programa ejecutable.

5.9 Prototipos

Presentación de algunas pantallas de la aplicación .

Pantalla de mantenimiento de Medicamentos

Pantalla de mantenimiento Enfermedades

Pantalla de mantenimiento de Alergias

Ejemplo: Aplicación Hotel

El dueño de un hotel le pide a usted desarrollar un programa para consultar sobre las piezas disponibles y reservar piezas de su hotel.

El hotel posee tres tipos de piezas: simple, doble y matrimonial, y dos tipos de clientes: habituales y esporádicos. Una reservación almacena datos del cliente, de la pieza reservada, la fecha de comienzo y el número de días que será ocupada la pieza.

El recepcionista del hotel debe poder hacer las siguientes operaciones:

Obtener un listado de las piezas disponible de acuerdo a su tipo Preguntar por el precio de una pieza de acuerdo a su tipo Preguntar por el descuento ofrecido a los clientes habituales Preguntar por el precio total para un cliente dado, especificando su numero de RUT, tipo de pieza y

número de noches. Dibujar en pantalla la foto de un pieza de acuerdo a su tipo Reservar una pieza especificando el número de la pieza, rut y nombre del cliente. Eliminar una reserva especificando el número de la pieza

El administrador puede usar el programa para:

Cambiar el precio de una pieza de acuerdo a su tipo Cambiar el valor del descuento ofrecido a los clientes habituales Calcular las ganancias que tendrán en un mes especificado (considere que todos los meses tienen

treinta días).

El hotel posee información sobre cuales clientes son habituales. Esta estructura puede manejarla con un diccionario, cuya clave sea el número de RUT y como significado tenga los datos personales del cliente.

El diseño a desarrollar debe facilitar la extensibilidad de nuevos tipos de pieza o clientes y a su vez permitir agregar nuevas consultas.

El presente ejemplo contempla los siguientes diagramas:

Diagrama de Casos de Uso

Diagrama de Clases

BIBLIOGRAFÍA

Módulo. Libro Referencia: Aprendiendo UML en 24 horas. Joseph Schmuller UML gota a gota.

UML www.programacion.com/tutorial/uml