Uploaded on

xxxx

xxxx

  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
    Be the first to like this
No Downloads

Views

Total Views
743
On Slideshare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
58
Comments
0
Likes
0

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. Proyecto de desarrollo del Software Rational Unified Process METODOLOGIA RUP (RATIONAL UNIFIED PROCESS)Proyecto: __________________________________________Sistema: ___________________________________________Integrantes:Jefe de Proyecto: ________________________________________Colaboradores: 1- Colaborador1 2- Colaborador2 3- Colaborador….nProf. Ayquipa Cordova, Godofredo
  • 2. Proyecto de desarrollo del Software Rational Unified Process FASE DE INICIOConsideraciones: 1- Aspectos generales de la organización 2- Plan de desarrollo de software 3- Modelo de Negocio a- Unidad Organizacional b- Paquete de Negocio c- Diagrama de Paquete de Negocio d- Diagrama de Caso de Uso de Negocio e- Especificaciones de Caso de Uso de Negocio f- Diagrama de Actividad de Negocio g- Diagrama de Objetos de NegocioProf. Ayquipa Cordova, Godofredo
  • 3. Proyecto de desarrollo del Software Rational Unified Process PROYECTO DE DESARROLLO DE SOFTWARE ASPECTOS ORGANIZACIONALES 1- Organización 1.1- Introducción 1.2- Reseña histórica 1.3- Ubicación Geográfica 2- Estructura Organizacional 2.1- Visión 2.2- Misión 2.3- Metas 2.4- Objetivo - General - Específicos 2.5- Organigrama 3- Área de Desarrollo 3.1- Descripción del área 3.2- Aspectos generales del área - Visión - Misión - Metas 3.3- Integrantes del área - Cargo - Funciones - Responsabilidades 3.4- Definición y descripción del problema - Administrativo - Organizacional 3.5- Recomendaciones - Administrativo - Organizacional 3.5- Áreas Involucradas 3.6- Formatos manualesProf. Ayquipa Cordova, Godofredo
  • 4. Proyecto de desarrollo del Software Rational Unified Process 1- Organización Una organización es un conjunto de elementos, compuesto principalmente por personas, que actúan e interactúan entre sí bajo una estructura pensada y diseñada para que los recursos humanos, financieros, físicos, de información y otros, de forma coordinada, ordenada y regulada por un conjunto de normas, logren determinados fines, los cuales pueden ser de lucro o no. 1.1- Introducción Descripción de la organización, rubro, dirección, etc... 1.2- Reseña histórica Origen, creación y evolución de la organización 1.3- Ubicación Geográfica (mapa) 2- Estructura Organizacional 2.1- Visión Define y describe la situación futura que desea tener la empresa, el propósito de la visión es guiar, controlar y alentar a la organización en su conjunto para alcanzar el estado deseable de la organización. Ejemplo: “La Visión es ser un Grupo energético y de servicios líder y en continuo crecimiento, con presencia multinacional, que se distinga por proporcionar una calidad de servicio excelente a sus clientes, una rentabilidad sostenida a sus accionistas, una ampliación de oportunidades de desarrollo profesional y personal a sus empleados y una contribución positiva a la sociedad actuando con un compromiso de ciudadanía global.” 2.2- Misión: Define el negocio al que se dedica la organización, las necesidades que cubren con sus productos y servicios, el mercado en el cual se desarrolla la empresa y la imagen pública de la empresa u organización. Ejemplo: “La Misión del Grupo Gas Natural es atender las necesidades energéticas de la sociedad, proporcionando a sus clientes servicios y productos de calidad respetuosos con el medio ambiente, a sus accionistas una rentabilidad creciente y sostenible y a sus empleados la posibilidad de desarrollar sus competencias profesionales.” 2.3- Metas y Objetivos Una metas, es pues lo que conduce a lograr el objetivo, y en consecuencia, el objetivo es el resultado de haber alcanzado cada una de las metas necesarias o planteadas para lograr el objetivo propuesto. Ejemplo: Un ejemplo más clásico de lo que es un objetivo y lo que es una meta, son las vueltas ciclísticas como el Tour de Francia, la vuelta a Colombia o a España. El objetivo es ganar elProf. Ayquipa Cordova, Godofredo
  • 5. Proyecto de desarrollo del Software Rational Unified Process título o la vuelta. Las metas será ganar cada una de las etapas. Aquí también podemos ver que existen lo que llaman metas volantes y/o los premios de montaña. 2.5- Organigrama El organigrama se define como la representación gráfica de la estructura orgánica de una institución o de una de sus áreas y debe reflejar en forma esquemática la descripción de las unidades que la integran, su respectiva relación, niveles jerárquicos y canales formales de comunicación. 3- Área de Desarrollo Establecer el área de desarrollo (organigrama) 3.1- Descripción del área Describir todas las actividades realizadas en el área. 3.2- Aspectos generales del área. Visión, Misión y Metas 3.3- Integrantes del área Empleados que laboran en el área, elaborar un cuadro donde se describa lo siguiente: Integrante Cargo Funciones Responsabilidades3.4- Definición y descripción del problema Cuadro donde se menciona todos los problemas (administrativo y organizacional) puntuales y una breve descripción del mismo.Prof. Ayquipa Cordova, Godofredo
  • 6. Proyecto de desarrollo del Software Rational Unified Process Administrativo Problemas Descripcion Problema1 Problema2 Organizacional Problemas Descripcion Problema1 Problema2 3.5- Recomendaciones Administrativo Recomendaciones Descripcion Recomendación 1 Recomendación 2 Organizacional Recomendaciones Descripcion Recomendación 1 Recomendación 2 3.6- Aéreas Involucradas Identificar las aéreas que están relacionadas con el área en estudio 3.7- Formatos Manuales Insertar todos los formatos manuales existentes en el área.Prof. Ayquipa Cordova, Godofredo
  • 7. Proyecto de desarrollo del Software Rational Unified Process PLAN DE DESARROLLO DE SOFTWARE1. Introducción2. Vista General del Proyecto 2.1 Propósito, Alcance y Objetivos 2.2 Suposiciones y Restricciones 2.3 Entregables del proyecto 2.4 Evolución del Plan de Desarrollo del Software3. Organización del Proyecto 3.1 Participantes en el Proyecto 3.3 Roles y Responsabilidades4. Gestión del Proceso 4.1 Tecnologia de Informacion 4.1..1 Evaluacion Tecnologica 4.1.2 Recomendaciones 4.2 Plan del Proyecto 4.2.1 Plan de las Fases 4.2.2 Calendario del ProyectoProf. Ayquipa Cordova, Godofredo
  • 8. Proyecto de desarrollo del Software Rational Unified Process Plan de Desarrollo del Software1. Introducción La introducción es una breve descripción de de las razones por las cuales se lleva a cabo este proyecto de desarrollo, también una breve descripción de la metodología a implementar. La introducción del plan de desarrollo del software debe dar una visión del documento completo. Debe incluir el propósito, alcance, definiciones, acrónimos, abreviaturas y referencias de este plan Ejemplo1: “Este Plan de Desarrollo del Software es una versión preliminar preparada para ser incluida en la propuesta elaborada como respuesta al proyecto de prácticas de la asignatura de Laboratorio de Sistemas de Información de la Facultad de Informática de la Universidad Católica. Este documento provee una visión global del enfoque de desarrollo propuesto. El proyecto ha sido ofertado por Patricio Orlando Letelier Torres basado en una metodología de Rational Unified Process en la que únicamente se procederá a cumplir con las tres primeras fases que marca la metodología, constando únicamente en la tercera fase de dos iteraciones. Es importante destacar esto puesto que utilizaremos la terminología RUP en este documento. Se incluirá el detalle para las fases de Inicio y Elaboración y adicionalmente se esbozarán las fases posteriores de Construcción y Transición para dar una visión global de todo proceso. El enfoque desarrollo propuesto constituye una configuración del proceso RUP de acuerdo a las características del proyecto, seleccionando los roles de los participantes, las actividades a realizar y los artefactos (entregables) que serán generados. Este documento es a su vez uno de los artefactos de RUP.”2. Vista General del Proyecto2.1 Propósito, Alcance y Objetivos Propósito: el propósito define lo que se espera lograr a través del proyecto mismo. Este debe incluir referencias sobre la duración, el lugar, la cantidad, la calidad y los beneficiarios. Un propósito adecuadamente definido constituye la clave para el éxito del proyecto. La definición de otros elementos del proyecto fluye del propósito. Ejemplo: - Evaluar la efectividad de las técnicas de captura de requisitos, en pequeñas empresas de desarrollo de software. - Desarrollar y evaluar un interfaz de usuario para paquetes estadísticos. - Producir y evaluar lenguajes de cuarta generación para el desarrollo de bases de datos. Objetivo: Los objetivos representan los logros significativos en el camino hacia el propósito final del proyecto. Ejemplo: - Definir las pautas, controles y procedimientos que debe reunir el marco para la administración de proyectos relacionados al desarrollo de sistemas de información. - Documentar las diferentes técnicas actuales para la predicción de las variaciones de los índices de Bolsa; - Desarrollar un modelo apropiado con una red neuronal artificial: - Reunir datos para el análisis y la evaluación;Prof. Ayquipa Cordova, Godofredo
  • 9. Proyecto de desarrollo del Software Rational Unified Process - Evaluar el modelo utilizando las técnicas estadísticas adecuadas; - Redactar un informe final. Alcance: Definir límites del trabajo y partes del proyecto. “Hacer lo que hay que hacer y no hacer lo que no hay que hacer”. Ejemplo: - Todas las áreas de servicios informáticos y los sitios donde se realicen proyectos de desarrollos o adquisición de sistemas de información en el Estado Provincial, comprendidos en el Decreto Acuerdo 462/96.2.2 Suposiciones y Restricciones Los supuestos o factores exógenos son aquellas condiciones que se hallan afuera del control (o la influencia) inmediata del proyecto, pero son necesarias para lograr los objetivos del mismo. Un proyecto es siempre una contribución limitada al desarrollo que depende de factores externos para su éxito. Ejemplo: Suposiciones  Ayudara a mejorar el manejo y el control de sus productos generando más tiempo y disponibilidad en la venta y alquiler de estos.  Estará a corde con el desarrollo tecnológico puesto que sería el primer sistema que tendría la empresa. Restricciones  El personal no se encuentra capacitado para el uso del software.  No contar con licencia necesaria para poder instalar el software (lenguaje de programación asp.net).2.3 Entregables del proyecto Definición: Dado que el objetivo final del proyecto es la entrega de un subsistema informático (entregable) veamos algunas definiciones y utilidades de los entregables. Los entregables los definiremos como "Productos que, en un cierto estado, se intercambian entre los clientes y los desarrolladores a lo largo de la ejecución del proyecto informático". Los entregables los clasificamos como relativos al objetivo y relativos a la gestión del proyecto. Son entregables relativos al objetivo todos aquellos documentos que hacen referencia exclusivamente al sistema de información y al subsistema informático en desarrollo. Pertenecen a este conjunto los requisitos del sistema, la especificación del sistema, la documentación del diseño, él código fuente, los programas ejecutables, los manuales de usuario, etc. Los entregables relativos a la gestión del proyecto hacen referencia a aquellos documentos que se refieren a la situación en que se encuentra un proyecto, previsiones de costes, gastos realizados, informe sobre ambientes de trabajo, etc., siendo su objetivo el poder controlar el proyecto. Pertenecen a esta clase la planificación del proyecto, losProf. Ayquipa Cordova, Godofredo
  • 10. Proyecto de desarrollo del Software Rational Unified Process presupuestos, los documentos de control de la planificación o de la calidad, los estudios de riesgos durante el desarrollo, etc. A continuación se indican y describen cada uno de los artefactos que serán generados y utilizados por el proyecto y que constituyen los entregables. Esta lista constituye la configuración de RUP desde la perspectiva de artefactos, y que proponemos para este proyecto. Es preciso destacar que de acuerdo a la filosofía de RUP (y de todo proceso iterativo e incremental), todos los artefactos son objeto de modificaciones a lo largo del proceso de desarrollo, con lo cual, sólo al término del proceso podríamos tener una versión definitiva y completa de cada uno de ellos. Sin embargo, el resultado de cada iteración y los hitos del proyecto están enfocados a conseguir un cierto grado de completitud y estabilidad de los artefactos. Esto será indicado más adelante cuando se presenten los objetivos de cada iteración. 1) Plan de Desarrollo del Software Es el presente documento. 2) Modelo de Casos de Uso del Negocio Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos (Agentes de registro, solicitantes finales, otros sistemas etc.). Permite situar al sistema en el contexto organizacional haciendo énfasis en los objetivos en este ámbito. Este modelo se representa con un Diagrama de Casos de Uso usando estereotipos específicos para este modelo. 3) Modelo de Objetos del Negocio Es un modelo que describe la realización de cada caso de uso del negocio, estableciendo los actores internos, la información que en términos generales manipulan y los flujos de trabajo asociados al caso de uso del negocio. Para la representación de este modelo se utilizan Diagramas de Colaboración (para mostrar actores externos, internos y las entidades (información) que manipulan, un Diagrama de Clases para mostrar gráficamente las entidades del sistema y sus relaciones, y Diagramas de Actividad para mostrar los flujos de trabajo. 4) Modelo de Casos de Uso El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso de ellas. Se representa mediante Diagramas de Casos de Uso. 5) Especificaciones de Casos de Uso Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste con una simple descripción narrativa) se realiza una descripción detallada utilizando una plantilla de documento, donde se incluyen: precondiciones, post-condiciones, flujo de eventos, requisitos no-funcionales asociados. También, para casos de uso cuyo flujo de eventos sea complejo podrá adjuntarse una representación gráfica mediante un Diagrama de Actividad. 6) Prototipos de Interfaces de Usuario Se trata de prototipos que permiten al usuario hacerse una idea más o menos precisa de las interfaces que proveerá el sistema y así, conseguir retroalimentación de su parte respecto a los requisitos del sistema. Estos prototipos se realizarán como: dibujos a mano en papel, dibujos con alguna herramienta gráfica o prototipos ejecutables interactivos, siguiendo ese orden de acuerdo al avance del proyecto. Sólo los de este último tipo serán entregados al final de la fase de Elaboración, los otros serán desechados. Asimismo, este artefacto, será desechado en la fase deProf. Ayquipa Cordova, Godofredo
  • 11. Proyecto de desarrollo del Software Rational Unified Process Construcción en la medida que el resultado de las iteraciones vayan desarrollando el producto final. 7) Modelo de Análisis y Diseño Este modelo establece la realización de los casos de uso en clases y pasando desde una representación en términos de análisis (sin incluir aspectos de implementación) hacia una de diseño (incluyendo una orientación hacia el entorno de implementación), de acuerdo al avance del proyecto. 8) Modelo de Datos Previendo que la persistencia de la información del sistema será soportada por una base de datos relacional, este modelo describe la representación lógica de los datos persistentes, de acuerdo con el enfoque para modelado relacional de datos. Para expresar este modelo se utiliza un Diagrama de Clases (donde se utiliza un profile UML para Modelado de Datos, para conseguir la representación de tablas, claves, etc.). 9) Lista de Riesgos Este documento incluye una lista de los riesgos conocidos y vigentes en el proyecto, ordenados en orden decreciente de importancia y con acciones específicas de contingencia o para su mitigación. Ejemplo: La gestión de un proyecto de software exitoso requiere entender qué puede salir mal. A continuación se indican 10 señales de que un proyecto esté en peligro. 1. El personal de software no entiende las necesidades de sus clientes. 2. El ámbito del producto está más definido 3. Los cambios se gestionan mal 4. La tecnología elegida cambia 5. Las necesidades comerciales cambian 6. Los plazos de entrega no son realistas 7. Los usuarios se resisten 8. Se pierde el patrocinio 9. El equipo de proyecto carece de personal con las habilidades apropiadas 10. Los gestores evitan las mejores prácticas y las lecciones aprendidasProf. Ayquipa Cordova, Godofredo
  • 12. Proyecto de desarrollo del Software Rational Unified Process2.4 Evolución del Plan de Desarrollo del Software El Plan de Desarrollo del Software se revisará semanalmente y se refinará antes del comienzo de cada iteración.3. Organización del Proyecto Describe la arquitectura organizacional del equipo de desarrollo. En la planificación se fracciona las actividades de modo que resulte fácil la realización y control de cada tarea. Hay que crear las condiciones que: • faciliten la coordinación: puesta en marcha, toma de decisiones, seguimiento y finalización de tareas. • facilite comunicarse a las personas encargadas de cada tarea, con las personas que realizan la misma u otras tareas asociadas a la suya.Prof. Ayquipa Cordova, Godofredo
  • 13. Proyecto de desarrollo del Software Rational Unified Process3.1 Participantes en el Proyecto Jefe de Proyecto. Aquí se declara el perfil del candidato a este puesto, así como su nombre y apellidos Analista de Sistemas. Aquí se declara el perfil del candidato a este puesto, así como su nombre y apellidos Analistas - Programadores. Aquí se declara el perfil de los candidatos a estos puestos, así como sus nombres y apellidos Ingeniero de Software. Aquí se declara el perfil del candidato a este puesto, así como su nombre y apellidos3.2 Roles y Responsabilidades A continuación se describen las principales responsabilidades de cada uno de los puestos en el equipo de desarrollo durante las fases de Inicio y Elaboración, de acuerdo con los roles que desempeñan en RUP. Puesto Responsabilidad El jefe de proyecto asigna los recursos, gestiona las prioridades, coordina las interacciones con los clientes y usuarios, y mantiene al equipo del proyecto enfocado en los objetivos. El jefe de proyecto también establece un conjunto de prácticas que aseguran la Jefe de Proyecto integridad y calidad de los artefactos del proyecto. Además, el jefe de proyecto se encargará de supervisar el establecimiento de la arquitectura del sistema. Gestión de riesgos. Planificación y control del proyecto. Captura, especificación y validación de requisitos, interactuando con el cliente y los usuarios mediante entrevistas. Elaboración del Analista de Sistemas Modelo de Análisis y Diseño. Colaboración en la elaboración de las pruebas funcionales y el modelo de datos. Construcción de prototipos. Colaboración en la elaboración de las Programador pruebas funcionales, modelo de datos y en las validaciones con el usuario Gestión de requisitos, gestión de configuración y cambios, elaboración del modelo de datos, preparación de las pruebas Ingeniero de Software funcionales, elaboración de la documentación. Elaborar modelos de implementación y despliegue.Prof. Ayquipa Cordova, Godofredo
  • 14. Proyecto de desarrollo del Software Rational Unified Process4. Gestión del Proceso La Gestión de Proyectos tiene como finalidad principal la planificación, el seguimiento y control de las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de un Sistema de Información. Como consecuencia de este control es posible conocer en todo momento qué problemas se producen y resolverlos o paliarlos de manera inmediata.4.1 Tecnología de Información - Evaluación Tecnológica - Recomendaciones4.2 Plan del Proyecto En esta sección se presenta la organización en fases e iteraciones y el calendario del proyecto.4.2.1 Plan de las Fases El desarrollo se llevará a cabo en base a fases con una o más iteraciones en cada una de ellas. La siguiente tabla muestra una la distribución de tiempos y el número de iteraciones de cada fase (para las fases de Construcción y Transición es sólo una aproximación muy preliminar) Fase Nro. Iteraciones Duración Fase de Inicio 1 17-set-30 Fase de Elaboración 1 1-oct-11-nov Fase de Construcción 1 12-nov-24-dic Fase de Transición 1 25-dic-5feb Como se ha comentado, el proceso iterativo e incremental de RUP está caracterizado por la realización en paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo cual la mayoría de los artefactos son generados muy tempranamente en el proyecto pero van desarrollándose en mayor o menor grado de a la fase e iteración del proyecto. La siguiente figura ilustra este enfoque en ella lo ensombrecido marca el énfasis de cada disciplina (workflow) en un momento determinado del desarrollo.Prof. Ayquipa Cordova, Godofredo
  • 15. Proyecto de desarrollo del Software Rational Unified Process Los hitos que marcan el final de cada fase se describen en la siguiente tabla. Descripción Hito Fase de Inicio En esta fase desarrollarán los requisitos del producto desde la perspectiva del usuario, los cuales serán establecidos en el artefacto Visión. Los principales casos de uso serán identificados y se hará un refinamiento del Plan de Desarrollo del Proyecto. La aceptación del cliente /usuario del artefacto Visión y el Plan de Desarrollo marcan el final de esta fase. Fase de En esta fase se analizan los requisitos y se desarrolla un prototipo de Elaboración arquitectura (incluyendo las partes más relevantes y / o críticas del sistema). Al final de esta fase, todos los casos de uso correspondientes a requisitos que serán implementados en la primera release de la fase de Construcción deben estar analizados y diseñados (en el Modelo de Análisis / Diseño). La revisión y aceptación del prototipo de la arquitectura del sistema marca el final de esta fase. En nuestro caso particular, por no incluirse las fases siguientes, la revisión y entrega de todos los artefactos hasta este punto de desarrollo también se incluye como hito. La primera iteración tendrá como objetivo la identificación y especificación de los principales casos de uso, así como su realización preliminar en el Modelo de Análisis / Diseño, también permitirá hacer una revisión general del estado de los artefactos hasta este punto y ajustar si es necesario la planificación para asegurar el cumplimiento de los objetivos. Ambas iteraciones tendrán una duración de una semana. Fase de Durante la fase de construcción se terminan de analizar y diseñar Construcción todos los casos de uso, refinando el Modelo de Análisis / Diseño. El producto se construye en base a 2 iteraciones, cada una produciendo una release a la cual se le aplican las pruebas y se valida con el cliente / usuario. Se comienza la elaboración de material de apoyoProf. Ayquipa Cordova, Godofredo
  • 16. Proyecto de desarrollo del Software Rational Unified Process al usuario. El hito que marca el fin de esta fase es la versión de la release 2.0, con la capacidad operacional parcial del producto que se haya considerado como crítica, lista para ser entregada a los usuarios para pruebas beta. Fase de En esta fase se prepararán dos releases para distribución, Transición asegurando una implantación y cambio del sistema previo de manera adecuada, incluyendo el entrenamiento de los usuarios. El hito que marca el fin de esta fase incluye, la entrega de toda la documentación del proyecto con los manuales de instalación y todo el material de apoyo al usuario, la finalización del entrenamiento de los usuarios y el empaquetamiento del producto.4.2.2 Calendario del Proyecto A continuación se presenta un calendario de las principales tareas del proyecto incluyendo sólo las fases de Inicio y Elaboración. Como se ha comentado, el proceso iterativo e incremental de RUP está caracterizado por la realización en paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo cual la mayoría de los artefactos son generados muy tempranamente en el proyecto pero van desarrollándose en mayor o menor grado de acuerdo a la fase e iteración del proyecto. La siguiente figura ilustra este enfoque, en ella lo ensombrecido marca el énfasis de cada disciplina (workflow) en un momento determinado del desarrollo.Prof. Ayquipa Cordova, Godofredo
  • 17. Proyecto de desarrollo del Software Rational Unified Process Para este proyecto se ha establecido el siguiente calendario. La fecha de aprobación indica cuándo el artefacto en cuestión tiene un estado de completitud suficiente para someterse a revisión y probación, pero esto no quita la posibilidad de su posterior refinamiento y cambios. Calendario Fase de Inicio Calendario Fase de ElaboraciónProf. Ayquipa Cordova, Godofredo
  • 18. Proyecto de desarrollo del Software Rational Unified Process Fase de Construcción Fase de TransiciónProf. Ayquipa Cordova, Godofredo
  • 19. Proyecto de desarrollo del Software Rational Unified Process MODELO DE NEGOCIO 1. CONCEPTO: Un modelo del negocio es una abstracción de cómo funciona la organización. Provee una vista simplificada de la estructura y comportamiento del negocio que actuará como la base de comunicación, mejora o innovación del negocio, así como también para definir los requisitos de los diferentes sistemas de software que pueden soportar al negocio. El Modelo de negocio es un modelo que refleja gráficamente las metas y funciones que persigue el negocio. Se usa como una entrada esencial para identificar roles y entregables en la organización.Así, los objetivos de la etapa de modelado del negocio son los siguientes: Entender los problemas actuales en la organización o empresa para identificar los aspectos a mejorar. Comprender la estructura y el dinamismo de la organización o empresa para la cual se va a desarrollar el sistema software. Estudiar el impacto que pueden producir los cambios a nivel organizativo. Asegurar que los clientes, usuarios finales, desarrolladores y otros involucrados tienen una visión común de la organización considerada. Obtener los requisitos del sistema software. Entender como el sistema software encaja en la organización. Entender los mecanismos del negocio actual Evaluar los procesos actuales Formar una base para mejorar/innovar el negocio actual Formar una base para un sistema de información que apoya al negocio permitiendo definir los requisitos funcionales y no funcionales de un futuro sistema informático.Para conseguir estos objetivos el flujo de trabajo de la etapa de Modelado del Negocio consta de las siguientesetapas: Evaluar el estado del Negocio. Análisis del Negocio. Identificar Procesos de Negocio. Definir y Refinar los Procesos de Negocio. Diseño de la Realización de los Procesos de Negocio. Evaluación.Los productos de desarrollo del software fundamentales que se desarrollan en la etapa de Modelado delNegocio son: Especificación del Negocio, que incluye Visión del Negocio y Glosario de Términos. Modelo de Casos de Uso del Negocio, que incluye Especificación de Casos de Uso, Descripción de Actores, Diagrama de Casos de Uso e Informe del Modelo de Casos de Uso. Modelo interno del Negocio, que incluye el Modelo de Objetos del Negocio y la Realización de los Casos de Uso. Informe de Evaluación. Documento de Arquitectura del Negocio.El Modelo de Caso de Uso de negocio es usado por: Los stakeholders, los analistas y los diseñadores de procesos de negocio, para entender y mejorar la manera cómo funciona el negocio y se relaciona con su ambiente.Prof. Ayquipa Cordova, Godofredo
  • 20. Proyecto de desarrollo del Software Rational Unified Process Los analistas de sistemas y arquitectos de software, para mantener el contexto del desarrollo del software. El gerente del proyecto, para planificar el volumen y contenido de las iteraciones durante el modelado de negocio y hacer el seguimiento del progreso. 2. Elementos del Modelo de Negocio a- Unidad Organizacional b- Paquete de Negocio c- Diagrama de Paquete de Negocio d- Diagrama de Caso de Uso de Negocio e- Especificaciones de Caso de Uso f- Diagrama de Actividad de Negocio g- Diagrama de Objetos de NegocioUnidad OrganizacionalLa unidad Organizacional es un contenedor de objetos de negocio, representa la organización Libreria Juanito S.A Unidad OrganizacionalPaquete de NegocioRepresenta las áreas de la organización. Paquete de NegocioProf. Ayquipa Cordova, Godofredo
  • 21. Proyecto de desarrollo del Software Rational Unified Process Compras Ventas AlmacenDiagrama de Paquete de Negocio - Representa la interrelación de las áreas con el área en desarrollo - Muestra la dependencia de las áreas DIAGRAMA DE PAQUETE DE NEGOCIO Compras Ventas AlmacenDiagrama de Caso de Uso de Negocio Muestra los Casos de Uso de negocio, Actores del negocio, Trabajadores del negocio y las interacciones entre ellos para una organización. Modela lo qué hace una compañía, quién está dentro y quién está fuera de la compañía. Da el alcance de la organización, visualizando lo que abarca y cuáles son sus fronteras.Prof. Ayquipa Cordova, Godofredo
  • 22. Proyecto de desarrollo del Software Rational Unified ProcessElementos: 1. Actores: Agente que interactúa con determinado proceso de negocio. - Actor de Negocio: Un actor del negocio, es cualquier persona o cualquier cosa externa a la organización pero que obra recíprocamente con ella. Por ejemplo, para su organización serian los clientes, sus acreedores, sus inversionistas, o sus proveedores. Cada uno de estos actores tiene un interés en las acciones de la empresa. Cliente En UML se modela un actor del negocio usando la siguiente figura: El icono representa a una persona, pero el actor de negocios no es necesariamente un individuo. Puede representar a un grupo de personas o a una compañía - Trabajador de Negocio: Un trabajador de negocios es un rol dentro de la organización. Importante, los trabajadores del negocio son roles no posiciones. Una persona puede tener varios roles, pero una sola posición. La ventaja de diagramar roles es que estos no cambian con demasiada frecuencia en el tiempo, las posiciones si. En UML un trabajador de negocios se representa con el siguiente icono: Vendedor 2. Caso de Uso de Negocio: - Un caso del uso de negocio representa un conjunto de tareas relacionadas que generan un resultado de valor para los actores de negocio. - En otros términos, los casos del uso de negocio le dicen al lector lo que la organización hace para proporcionarle el valor de negocio que los individuos que interactúan con él esperan. - El conjunto de los casos del uso de negocio para una organización debe describir completamente lo que el negocio hace. - Los casos de uso de negocio cuenta con el siguiente formato: Verbo + Sustantivo - En UML, se usa el siguiente icono para los casos de uso de negocio. 3. Especificaciones de un Caso de Uso de Negocio: - Para cada caso de uso del negocio, se debe crear un cierto tipo de informe que permite saber específicamente qué va a suceder dentro del caso del uso. - El flujo de trabajo se puede documentar de dos formas. La más simple es crear una lista numerada, paso a paso de qué sucede mientras que progresa el caso del uso. - La problemática con la forma simple de escribir el flujo de trabajo, se presenta cuando existe una gran cantidad de condiciones lógicas, lo que provoca poca claridad. - Para solucionar este problema se pueden utilizar los Diagramas de Actividad, que nos permiten mostrar de forma grafica los flujos de trabajo, la secuencia de los pasos y quien es responsable de realizar cada paso. - A cada caso de uso del negocio se le debe asociar una documentación que sigue el siguiente formato.Prof. Ayquipa Cordova, Godofredo
  • 23. Proyecto de desarrollo del Software Rational Unified Process 4. Relaciones entre Actores: Generalización - Es una relación entre actores de negocio que muestra que cuando un actor “específico” (el descendiente) está presente, todas las características (atributos, operaciones y asociaciones) que son descritas para el actor “genérico” (el ascendente) del cuál hereda, van a estar presentes. Persona - Una generalización de un actor de negocio “A” a un actor de negocio “B”, indica que una instancia de A puede activar la misma clase de casos de uso que una instancia de B. - En UML, la relación de generalización se muestra de la siguiente manera: Natural Juridico 5. Relaciones entre Casos de Uso y Actores: Asociación Unidireccional - Una línea de un actor de negocio a un caso del uso de negocio indica que el actor activa el caso de uso. - En UML, la relación de asociación se muestra de la siguiente manera: Solicitar Credito Cliente Evaluar Credito VendedorProf. Ayquipa Cordova, Godofredo
  • 24. Proyecto de desarrollo del Software Rational Unified Process 6. Relaciones entre Casos de Uso de Negocio: - Include (Inclusión): una instancia del Caso de Uso origen incluye también el comportamiento descrito por el Caso de Uso destino, en un caso de uso incluido no interviene un determinado actor. <<include>> - Caso de Uso Origen Caso de Uso DestinoEjemplo: Evaluar Credito Credito <<include>> <<include>> Analizar Documentos Analizar Riesgo - Extend (extensión): el Caso de Uso origen extiende el comportamiento del Caso de Uso destino, en un caso de uso extendido puede intervenir un determinado actor de negocio. <<extend>> Caso de Uso Origen Caso de Uso destinoProf. Ayquipa Cordova, Godofredo
  • 25. Proyecto de desarrollo del Software Rational Unified ProcessEjemplo: Solicitar Prestamo Cliente <<extend>> [tarjeta caducada] Solicitar Nueva T arjetaEjercicio 1: Sociedad de amigos del libroLa sociedad de amigos del libro se dedica a la venta de libros a sus socios a través del teléfono. Esta sociedadactúa como intermediario entre las editoriales y sus socios, proporcionándoles los libros que estos solicitan aprecios reducidos. La empresa está estructurada en varios departamentos, uno de los cuales se encarga de lospedidos, almacén y el de contabilidad.Los socios pueden realizar sus pedidos por teléfono al departamento de pedidos. En la petición se especificanlos siguientes datos: nombre del socio y el número de ejemplares solicitados por título. Previamente a laaceptación del pedido, se verifica que el socio este registrado y que no tenga ninguna cuota vencida o pagospendientes. Para ello se hacen las comprobaciones oportunas y en cualquiera de estos supuestos el pedido serechaza (lo que se comunica al socio en el momento). Si todo es correcto se elabora la nota de pedido y pasa ala situación de pendiente por atender.El departamento de pedidos utiliza dos o tres veces a la semana los pedidos pendientes para generar un pedidoa las editoriales (un listado con los títulos solicitados y el número total de ejemplares de cada título). Cuandose reciben los libros, el departamento de almacén verifica el estado del producto, si existe alguna anomalíacon el libro, este es devuelto a la editorial y esta correcto se procede a la distribución en los anaqueles, eldepartamento de almacén entrega los documentos (guía y factura) de la editorial a contabilidad para sercancelada.Preguntas:Realice el diagrama de casos de uso de negocio correspondienteProf. Ayquipa Cordova, Godofredo
  • 26. Proyecto de desarrollo del Software Rational Unified ProcessEjercicio 2: Fabrica de productosProceso de negocio: 1. La venta de productos comienza cuando un cliente se acerca al local de la empresa y es atendido por un asesor de ventas que toma su pedido generando una orden de pedido, en esta orden se detalla los datos del cliente y las características de los productos requeridos. 2. La orden de pedido es pasada al asistente de ventas, quién se encargará de llevarla al jefe de producción en el área de producción para su análisis. 3. El pedido es revisado por el jefe de producción para que analice la factibilidad de fabricar los productos con las características requeridas. 4. La factibilidad se basa primero en si antes se ha fabricado un producto con similares características, en caso contrario se analiza la dificultad del producto para aceptar o negar el pedido. 5. En caso de ser factible la fabricación del producto, el jefe de producción emite una lista de la materia prima necesaria, esta lista se le envía al operario de almacén para que revise el stock y dé un estimado de tiempo en que la materia prima estaría disponible para su utilización, mientras que el jefe de producción va calculando el tiempo que se tomaría para la fabricación. 6. En caso de que se pueda fabricar el producto, la información que emita el operario es necesaria para generar el informe de evaluación. 7. Luego, el jefe de producción específica su respuesta en un informe de evaluación que contiene el costo y la fecha de producción; este documento se envía al asesor de ventas a través de su asistente; en caso de ser una respuesta afirmativa, también se genera una orden de producción. 8. El asesor de ventas comunica la respuesta al cliente, si es afirmativa se procede a generar una orden de pago. 9. El cliente se acerca con la orden de pago a la caja, en donde la cajera finalmente generara un comprobante de pago, pudiendo ser una boleta o factura 10. Termina el proceso.Preguntas:1. Realice el diagrama de casos de uso de negocio correspondiente.Prof. Ayquipa Cordova, Godofredo
  • 27. Proyecto de desarrollo del Software Rational Unified Process DIAGRAMA DE ACTIVIDAD DE NEGOCIOEs la representación de una secuencia de actividades dentro de un caso de uso de negocio. Provee una maneragrafica de documentar un caso de uso de negocio.  Un diagrama de la actividad en una realización del caso del uso del negocio ordenar la tareas o las actividades que logran una o más metas de negocio, que satisfacen la iteración entre los Actores externos del negocio y los trabajadores internos del negocio.  Se usa separadores de Línea para representar principalmente trabajadores del negocio, y de cómo estos realizan el negocio  los flujos del objeto se utilizan para demostrar cómo las entidades de negocio se crean y se utilizan en un FlujoElementos: 1- Inicio: El inicio de un diagrama de actividad es representado por un círculo de color negro sólido. 2- Actividad de Negocio: Una actividad representa la acción que será realizada por un caso de uso de negocio la cual es representada dentro de un ovalo. 3- Transición: Una transición ocurre cuando se lleva a cabo el cambio de una actividad a otra, la transición es representada simplemente por una línea con una flecha en su terminación para indicar dirección. 4- Bifurcación (decisión): Una ramificación ocurre cuando existe la posibilidad que ocurra más de una transición (resultado) al terminar determinada actividad. Este elemento es representado a través de un rombo. 5- Barra de Sincronización: Representa actividades paralelas. 6- Fin: El fin de un diagrama de actividad es representado por un círculo, con otro círculo concéntrico de color negro sólido. 7- Canales (Swimlines): En determinadas ocasiones ocurre que un diagrama de actividad se expanda a lo largo de más de un entidad o actor, cuando esto ocurre el diagrama de actividad es particionada en canales (swimlines), donde cada canal representa la entidad o actor que está llevando a cabo la actividad.Prof. Ayquipa Cordova, Godofredo
  • 28. Proyecto de desarrollo del Software Rational Unified ProcessEjemplo 1Ejemplo2Prof. Ayquipa Cordova, Godofredo
  • 29. Proyecto de desarrollo del Software Rational Unified ProcessEjemplo 3Ejercicio: 1. Realizar el Diagrama de Actividades y para modelar el siguiente flujo de control: Un cliente desea obtener una cuenta corriente a su nombre en un negocio particular. El gerente atiende la solicitud y solicita un informe de las referencias comerciales proporcionadas por el cliente, al centro de Referencias Comerciales. Si el gerente acepta la solicitud, fija un monto máximo y abre la cuenta corriente solicitada. El gerente rechaza la solicitud si: el cliente ya posee una cuenta abierta, si no tiene referencias comerciales en el centro de Referencias Comerciales o si éste devuelve un informe negativo. 2. Realizar un Diagrama de Actividades para modelar la compra de viajes. Una persona que desee adquirir un viaje deberá dirigirse a las oficinas de compañía aérea correspondiente con su DNI. La secretaria de ventas de viajes de la compañía, se encarga de recibir la documentación del cliente (pasajero).Con estos datos, la secretaria busca en el archivo las fichas de pasajeros registrados (tendrá una ficha si anteriormente ha realizado unProf. Ayquipa Cordova, Godofredo
  • 30. Proyecto de desarrollo del Software Rational Unified Process viaje con la compañía). En el caso de que el cliente no posea una ficha, se la completa en el momento. La secretaria pedirá los datos del viaje a realizar (origen, destino y fecha de partida) e informará los costos. Una vez completados estos pasos, la secretaría verificará la disponibilidad del viaje. En caso negativo, se ofrecerá al cliente alguna alternativa con respecto a la fecha de partida. El cliente puede aceptar alguna de estas propuestas o bien cancelar la operación. Si el cliente acepta, deberá suministrar sus datos de tarjeta de crédito o bien pagar en efectivo. En el caso de que el cliente pague con tarjera, la secretaria deberá verificar la disponibilidad del crédito para ese cliente comunicándose con el “Centro Internacional de Crédito (C.I.C.)” quién será el que confirmará si el cliente cuenta con el crédito correspondiente para abonar el viaje. 3. Un paciente es atendido en un Consultorio Odontológico. El paciente ingresa al consultorio, la secretaria verifica si el paciente tiene un turno otorgado, y sólo en ese caso el mismo será atendido. Si el paciente posee una mutual por la cual atiende el odontólogo, entrega la orden correspondiente a la Secretaría. Si no posee mutual, debe pagar un monto fijo por la consulta y la secretaria le entrega el recibo del pago correspondiente. Si es la primera vez que el paciente es atendido por el odontólogo, la secretaria realiza una historia clínica tomando sus datos personales, y luego se la entrega al odontólogo. Una vez atendido, el odontólogo registra los datos de la consulta en la historia clínica del paciente. En caso que sea necesario, finalizada la consulta, el odontólogo se comunica con la secretaria para acordar un nuevo turno para el paciente. 4. Elaborar el diagrama de actividad : El cliente envía una orden de pedido, que debe incluir la fecha de solicitud, datos del cliente y productos solicitados. Es posible que sea un empleado del departamento comercial quien introduzca el pedido, a petición de un cliente que realizó su pedido por teléfono o lo envió por fax o correo ordinario al depto. comercial de la empresa. - El empleado revisa el pedido (completándolo, si es necesario), y comienza su procesamiento enviándolo al jefe técnico, que está encargado de su análisis. - El jefe técnico analiza la viabilidad de cada producto del pedido por separado: · Si el producto pedido está en el catálogo, su fabricación es aceptada. · En caso contrario, es considerado un producto especial, y el jefe técnico estudia su producción: - Si es viable, la fabricación del producto especial es aceptada; - Si no es viable, el producto especial no será fabricado. Una vez estudiado el pedido completo, el jefe técnico... · Informa al departamento comercial de la aceptación o rechazo de cada producto pedido; · Si todos los productos de un pedido han sido aceptados, se crea una orden de trabajo para cada producto, a partir de una plantilla de fabricación (la estándar si el producto estaba catalogado, o una nueva, específicamente diseñada para el producto, si éste no estaba en elProf. Ayquipa Cordova, Godofredo
  • 31. Proyecto de desarrollo del Software Rational Unified Process catálogo). Cada orden de trabajo es enviada al jefe de producción, y queda pendiente de su lanzamiento. El comercial comunica al cliente el resultado final del análisis de su pedido.Prof. Ayquipa Cordova, Godofredo
  • 32. Proyecto de desarrollo del Software Rational Unified Process MODELO DE ANALISIS DE NEGOCIOEl modelo del análisis de negocio describe la realización de los casos del uso del negocio en función a lainteracción entre los trabajadores del negocio y las entidades de negocio.Sirve como abstracción de cómo los trabajadores del negocio y las entidades de negocio necesitan serrelacionados y de cómo necesitan colaborar para realizar los casos del uso del negocio.El propósito del modelo del análisis de negocio es describir cómo se realizan los casos del uso del negocio.El modelo del caso del uso del negocio describe qué sucede entre los Acores de negocio y el negocio, y nohace ninguna asunción sobre la estructura del negocio.El modelo del análisis de negocio, define los trabajadores internos del negocio y la información que utilizan(las entidades de negocio), describen su organización estructural en las unidades independientes (sistemas delnegocio), y definen cómo obran recíprocamente para realizar el comportamiento descrito en los casos del usodel negocio.El analista del negocio es responsable de la estructura y de la integridad del modelo, mientras que losdiseñadores del negocio son responsables de detallar elementos dentro del modelo.El modelo también es utilizado por los analistas de sistemas para derivar requisitos del software, basados encómo el sistema de software será utilizado como parte de los procesos del negocio. Los arquitectos delsoftware utilizan el modelo para definir una arquitectura del software que para la organización y paraidentificar clases en modelos del análisis y del diseño del softwareElemnetos: 1- Bussiness Enty o Entidad de Negocio: ente manipulado por los trabajadores de negocio, representa el lugar donde se almacena o consulta datos de forma manual. 2- Bussiness Worker o trabajador de negocio: rol o roles dentro del proceso de negocio que manipula las entidades de negocio. 3- Business use case realization o Realizacion de Caso de Uso de Negocio 4- Diagrama de Actividad de Negocio 5- Diagrama de Objetos de Negocio: Representa las responsabilidades de los trabajadores de negocio con respecto a las entidades de negocio y las relaciones entre las mismas entidades de negocio. 6- Diagrama de colaboracion de negocioProf. Ayquipa Cordova, Godofredo
  • 33. Proyecto de desarrollo del Software Rational Unified Process Ejemplo de daigrama de objetos de negocio:Prof. Ayquipa Cordova, Godofredo
  • 34. Proyecto de desarrollo del Software Rational Unified Process FASE DE ELABORACION 1- Diagrama de Paquete de Sistema 2- Modelo de Caso de Uso (Modelo de Requisitos) a- Diagrama de caso de uso b- Diagrama de Actividad c- Especificaciones de caso de uso 3- Prototipos (interfaz de usuario)Prof. Ayquipa Cordova, Godofredo
  • 35. Proyecto de desarrollo del Software Rational Unified Process 1- DIAGRAMA DE PAQUETE DE SISTEMAEn el Lenguaje Unificado de Modelado, un diagrama de paquetes muestra como un sistema está dividido enagrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paqueteestá pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquíalógica de un sistema.Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete yminimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetesson buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un equipo, y lasdependencias entre ellos pueden indicar elorden de desarrollo requerido. 2- MODELO DE CASO DE USOEl Modelo de Casos de uso es un modelo quedescribe los requerimientos funcionales delsistema en forma de Casos de uso.En UML los Casos de Uso son los principalesmedios para capturar la funcionabilidad delsistema desde la perspectiva del usuario ymuchas veces puede reemplazar al documento“requisitos funcionales” a- Diagrama de Caso de Uso: Un diagrama de Casos de Uso muestra las distintas operaciones que se esperan de una aplicación o sistema y cómo se relaciona con su entorno (usuarios u otras aplicaciones). El diagrama de casos de uso representa la forma en cómo 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). Secuencia de transacciones desarrolladas por un sistema en respuesta a un evento iniciado por un actor Sirven para especificar la funcionalidad y el Comportamiento de un sistema Un diagrama de caso de uso muestra las relaciones entre actores y casos de uso dentro del sistema Un caso de uso es una unidad coherente de una funcionalidad provista por el sistema (o una clase)Elementos:Caso de Uso: es una representación de una unidad discreta de trabajo realizada por un usuario usando elsistema en operación. Se ejecuta en su totalidad o no se ejecuta nada, devolviendo algo de valor alusuario.Es una operación/tarea específica que se realiza tras una orden de algún agente interno, sea desde unapetición de un actor o bien desde la invocación desde otro caso de uso.Prof. Ayquipa Cordova, Godofredo
  • 36. Proyecto de desarrollo del Software Rational Unified ProcessActor: Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Esimportante destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamenterepresenta a una persona en particular, sino más bien la labor que realiza frente al sistema.Relación: Comunicación (relación entre un actor y un caso de uso con el que interactúa; se representasimplemente con una línea). Relacion entre casos de uso : Include y Extend b- Diagrama de actividad de sistema El diagrama de actividad muestra el orden en el que se van realizando tareas dentro de un sistema. Los diagramas de actividad describen la secuencia de las actividades en un sistema.Elementos: 1- Inicio: El inicio de un diagrama de actividad es representado por un círculo de color negro sólido. 2- Actividad de Sistema: Una actividad representa la acción que será realizada por un caso de uso de negocio la cual es representada dentro de un ovalo. actividad 3- Transición: Una transición ocurre cuando se lleva a cabo el cambio de una actividad a otra, la transición es representada simplemente por una línea con una flecha en su terminación para indicar dirección. 4- Bifurcación (decisión): Una ramificación ocurre cuando existe la posibilidad que ocurra más de una transición (resultado) al terminar determinada actividad. Este elemento es representado a través de un rombo.Prof. Ayquipa Cordova, Godofredo
  • 37. Proyecto de desarrollo del Software Rational Unified Process 5- Barra de Sincronización: Representa actividades paralelas. 6- Fin: El fin de un diagrama de actividad es representado por un círculo, con otro círculo concéntrico de color negro sólido. 7- Canales (Swimlines): En determinadas ocasiones ocurre que un diagrama de actividad se expanda a lo largo de más de un entidad o actor, cuando esto ocurre el diagrama de actividad es particionada en canales (swimlines), donde cada canal representa la entidad o actor que está llevando a cabo la actividad. c- Especificaciones de Caso de Uso: cuenta con el siguiente formato. 1- Nombre del Caso de Uso 1.1- Descripcion 2- Flujo de Eventos 2.1- Flujo Basico 2.2- Flujos Alternativos 2.2.1- Flujo alternativo 2.2.2- Otro flujo alternativo 3- Precondiciones 3.1- Una Precondicion 3.2- Otra precondicion 4- Poscondiciones 4.1- Una poscondicion 4.2- Otra poscondicion Ejemplo de especificaciones de caso de uso: Especificación de Caso de Uso 1- Registrar Producto 1.1 Breve Descripción Permite al jefe de almacén tener una gestión de productos para luego poder adminístralos en el funcionamiento de nuestro sistema, el jefe de almacén podrá crear, editar y eliminar producto(s) según sea el criterio de la empresa. 2- Flujo de Eventos 2.1 Flujo Básico El sistema muestra la interfaz “Gestionar Producto” con los criterios de búsqueda que son los campos: código, modelo, marca, nombre producto, categoría además de las opciones buscar, editar, nuevo, eliminar. 2.1.1- Crear Producto 1. El caso de uso comienza cuando el Jefe de Almacén solicita” Nuevo” en la interfaz Gestión Productos. 2. El sistema muestra la interfaz “Crear Producto”. 3. El Jefe de Almacén selecciona Categoría (partes y piezas, periféricos y accesorios y suministros)Prof. Ayquipa Cordova, Godofredo
  • 38. Proyecto de desarrollo del Software Rational Unified Process 4. El sistema retorna lista de tipo de Producto en base a la categoría. 5. El jefe de Almacén selecciona Tipo de Producto (según la categoría). 6. El sistema retorna lista de marcas en base al Tipo de producto. 7. El jefe de almacén selecciona marca. 8. El jefe de Almacén ingresa Modelo. 9. El jefe de Almacén Ingresa Una breve descripción. 10. El jefe de Almacén elige la opción de Grabar para guardar el nuevo Producto Creado. 11. El Sistema Guarda registro nuevo del producto ingresado. 12. El Sistema genera mensaje de confirmación de creación de producto. 13. El sistema regresa a la interfaz de Gestión de Producto. 2.1.2- Editar Producto 1. El jefe de almacén ingresa el criterio de búsqueda del producto en la interfaz Gestión de Productos. 2. El jefe de almacén selecciona el botón “Buscar” 3. Se ejecuta el caso de uso extendido Buscar Producto 4. El sistema muestra el producto(s) y sus datos en una tabla en la interfaz de Gestión Producto 5. El jefe de almacén presiona “editar” en el producto que desea modificar. 6. El sistema muestra la interfaz Editar producto 7. El jefe de almacén modifica los datos del producto según criterio 8. El jefe de Almacén selecciona grabar 9. El sistema guarda los datos modificados y genera un mensaje “Actualización Completada” 10. El Jefe de almacén presiona “Aceptar” 11. El Sistema regresa a la interfaz Gestión de Productos. 2.1.3- Eliminar Producto 1. El jefe de almacén ingresa el criterio de búsqueda del producto en la interfaz de Gestión de productos. 2. El jefe de almacén selecciona buscar 3. Se ejecuta el caso de uso extendido Buscar Producto 4. El sistema muestra el producto(s) y sus datos en una tabla en la interfaz de Gestión Producto 5. El Jefe de almacén selecciona el producto(s) que desea eliminar presionando en el checkbox correspondiente. 6. El Jefe de almacén presiona el botón “Eliminar” 7. El sistema muestra mensaje “Seguro que desea eliminar el producto(s) seleccionado(s) de la lista”Prof. Ayquipa Cordova, Godofredo
  • 39. Proyecto de desarrollo del Software Rational Unified Process 8. El jefe de Almacén confirma presionando el botón Aceptar 9. El sistema elimina el producto(s) seleccionado de la base de datos 10. El sistema limpia los campos del producto 2.2- Flujos Alternativos 2.2.1- < Error falta ingresar datos obligatorios > En el punto 10 del crear producto, cuando el usuario selecciona guardar sin haber llenado todos los campos requeridos, el sistema muestra un mensaje de error “Falta llenar campos” y lo retorna al la interfaz Crear Producto. 2.2.2- <No coloca criterio de búsqueda> Si en editar producto y eliminar producto el jefe de almacén presionar buscar sin ingresar un criterio de búsqueda, el sistema mostrara en la tabla todos los productos ingresados hasta el momento 2.2.3 <Error no seleccionar producto> En el punto 6 de eliminar producto, cuando el usuario selecciona eliminar sin haber seleccionado el producto, el sistema muestra un mensaje de erro “Falta seleccionar producto a eliminar” y lo retorna a la interfaz eliminar producto. 3- Precondiciones 3.1- El Jefe de Almacén tiene que estar logeado en el sistema 3.2- Que existan productos ingresados a la base de datos 4- Pos condiciones 4.1- El sistema ha actualizado la lista de productos Ejemplo de especificaciones de Caso de Uso Especificación de Caso de Uso 1- Gestión de Clientes 1.1- Descripción Este caso de uso resume la utilidad de alta, baja y modificación de los datos registrados en la base de datos de la plantilla de clientes que tiene la empresa. El usuario de ventas, ya sea representante de ventas, operadora o cliente on-line, podrá acceder a los datos correspondientes a cada uno y realizar modificaciones. Los representantes de ventas solamente pueden modificar o eliminar clientes que estén asociados a los mismos, y el alta asociará automáticamente al cliente con dicho representante. Los clientes on-line solo podrán modificar datos propios, eliminarse como clientes o darse de alta como uno nuevo sin que dé lugar a repeticiones. Por último, la operadora podrá modificar, dar de alta o eliminar cualquier cliente. 2- Flujo de EventosFlujo Básico1. El Usuario de Ventas puede seleccionar dar de alta un nuevo cliente, pasar al punto 2; dar de baja un cliente, pasar al punto 3; modificar datos de un cliente, pasar al punto 4.2. El Usuario de Ventas solicita el alta de un nuevo cliente. 2.1. El sistema muestra los campos de datos necesarios a introducir; los campos a rellenar son: DNI/CIF, Nombre, País, Provincia, Localidad, Dirección, Código Postal, Teléfono, E-mail y Cuenta Bancaria. 2.2. El Usuario de Ventas pulsa el botón introducir datos. Pasar al punto 5.3. El Usuario de Ventas solicita la baja de un cliente. 3.1. El sistema muestra el campo DNI/CIF a introducir necesario para la baja. 3.2. El Usuario de Ventas introduce el DNI/CIF del cliente que desea eliminar y pulsa “entrar”.Prof. Ayquipa Cordova, Godofredo
  • 40. Proyecto de desarrollo del Software Rational Unified Process 3.3. El sistema muestra los campos de los datos del cliente que se ha solicitado para la baja. 3.4. El Usuario de Ventas pulsa el botón borrar de su interfaz gráfica. 3.5. El sistema genera un mensaje de aviso de borrado y solicita la confirmación de la eliminación. 3.6. El Usuario de Ventas puede confirmar la eliminación del cliente pulsando el botón Aceptar, o bien puede cancelar el borrado pulsando el botón Cancelar. Pasar al punto 5. 4. El Usuario de Ventas solicita la modificación de datos de un cliente. 4.1. El sistema muestra el campo DNI/CIF a introducir necesario para la modificación. El sistema muestra los datos del cliente que se ha solicitado para la modificación. 4.2. El Usuario de Ventas puede modificar cualquiera de los datos de los campos mostrados por el sistema, éstos son: DNI/CIF, Nombre, País, Provincia, Localidad, Dirección, Código Postal, Teléfono, E-mail y Cuenta Bancaria. 4.3. El Usuario de Ventas puede solicitar guardar los datos modificados pulsando el botón Modificar de la interfaz gráfica. 4.4. El sistema genera un mensaje de aviso de modificación y solicita la confirmación de la misma. 4.5. El Usuario de Ventas puede confirmar la modificación del cliente pulsando el botón Aceptar, o bien puede cancelar el borrado pulsando el botón Cancelar. Pasar al punto 5. Flujos Alternativos En el punto 2.2 El sistema comprueba que los datos del nuevo cliente, DNI/CIF no se corresponden con ningún otro cliente de la base de datos. En caso afirmativo, generará un mensaje de error comunicando que dicho cliente ya está dado de alta en la base de datos. El sistema comprueba que se han introducido todos los datos restantes, en caso de que no se hayan introducido datos en los campos Nombre, País, Provincia, Localidad, Dirección, Código Postal, Teléfono y Cuenta Bancaria, el sistema generará un mensaje de error3- PROTOTIPO O INTERFAZ DE USUARIO Esta es una de las partes más importantes de cualquier programa ya que determina que tan fácilmente es posible que el programa haga lo que el usuario quiere hacer. Un programa muy poderoso con una interfaz pobremente elaborada tiene poco valor para un usuario no experto. La elaboración de una interfaz de usuario, bien diseñada, exige una gran dedicación pues generalmente las interfaces son grandes, complejas y difíciles de implementar, depurar y modificar. Hoy en día las interfaces de manipulación directa (también llamadas interfaces gráficas de usuario, GUI por sus siglas en inglés) son prácticamente universales. Las interfaces que utilizan ventanas, íconos menú se han convertido en estándar en los materiales computacionales. Ejemplo de interfaz de usuario: Prof. Ayquipa Cordova, Godofredo
  • 41. Proyecto de desarrollo del Software Rational Unified ProcessHotelEl dueño de un hotel nos pide desarrollar un programa para consultar las habitaciones disponibles y poderreservar habitaciones en su hotel.El hotel posee tres tipos de habitaciones: simple, doble y matrimonial, y dos tipos de clientes: habitualesy esporádicos. Una reserva almacena datos del cliente, de la habitación reservada, la fecha decomienzo y el número de días que será ocupada la habitación.El recepcionista del hotel debe poder hacer las siguientes operaciones:  Obtener un listado de las habitaciones disponible de acuerdo a su tipo.  Preguntar por el precio de una habitación 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 número de reserva, tipo de habitación y número de noches.  Dibujar en pantalla la foto de una habitación de acuerdo a su tipo.  Reservar una habitación especificando el número de la pieza, reserva y nombre del cliente.  Eliminar una reserva especificando el número de la habitación.El administrador puede usar el programa para:  Cambiar el precio de una habitación 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).Prof. Ayquipa Cordova, Godofredo
  • 42. Proyecto de desarrollo del Software Rational Unified ProcessEl diseño a desarrollar debe facilitar la extensibilidad de nuevos tipos de habitaciones o clientes y a su vezpermitir agregar nuevas consultas.Obtener el diagrama de casos de uso.Prof. Ayquipa Cordova, Godofredo
  • 43. Proyecto de desarrollo del Software Rational Unified Process FASE DE CONSTRUCCION 1- Modelo de Análisis a- Caso de Uso Análisis b- Clase Análisis - Clase Boundary - Clase Control - Clase Entidad c- Diagrama de Colaboración Clase Análisis d- Diagrama de Secuencia Clase análisis 2- Modelo de Datos (Data Modeler Diagram)Prof. Ayquipa Cordova, Godofredo
  • 44. Proyecto de desarrollo del Software Rational Unified Process 1- MODELO DE ANALISIS - El modelo de análisis es una especificación detallada de los requerimientos y trabajos. - Lo usan los desarrolladores para entender los casos de uso, refinándolos como colaboraciones entre clasificadores conceptuales. - El modelo de análisis se usa para crear un sistema robusto con reuso considerable de componentes - El modelo de análisis es un modelo conceptual y no un proyecto de la implementación. - Especificación detallada (precisa) de requisitos. - Refina los casos de uso como colaboraciones entre clasificadores: Clasificadores: clases de análisis, paquetes. Colaboraciones: realizaciones de los casos de uso. MODELO DE CASO DE USO MODELO DE ANALISISSe describe utilizando el lenguaje del cliente Se describe utilizando el lenguaje del programadorVista externa del sistema Vista interna del sistemaEstructurado por casos de uso Estructurado por clases y paquetesSe usa primariamente como un contrato Se utiliza principalmente por losentre el cliente y desarrolladores, determina desarrolladores para entender QUE hará elQUE hará el sistema y se decide si el sistema y plantear interacciones quesistema se llevará a cabo o no comiencen a definir el COMOPuede contener redundancias e Se reducen considerablemente lasinconsistencias redundancias e inconsistenciasCaptura las funcionalidades del sistema Refina y describe la forma en que se realizarán las funcionalidades del sistemaDefine los CASOS DE USO y a futuro Define REALIZACIONES DE CASOS DEserán analizados en el Modelo de Análisis USO, donde cada uno representa el análisis de un caso de uso particular 2- ARTEFACTOS DEL ANALISIS a- CLASES DE ANALISIS: representan una abstracción de una o varias clases y/o subsistemas en el diseño del sistema. b- REALIZACIONES DE CASOS DE USO: descripción de la realización de cada caso de uso en término de clases de análisis y la interacción entre objetos de análisis. c- PAQUETES DE ANALISIS: permiten organizar el modelo de análisis en piezas manejables. Pueden contener realizaciones de casos de uso, clases de análisis y otros paquetes de análisis. d- DESCRIPCIÓN DE LA ARQUITECTURA: vista arquitectónica del Modelo de Análisis mostrando sus artefactos más significativo 3- ACTIVIDADES DEL ANALISIS a- ANALIZAR CADA CASO DE USO - Identificar Clases de Análisis _ UML- Diagrama de Clases - describir la interacción entre objetos de análisis - UML -Diagrama de Colaboración, descripción Textual - Capturar requerimientos especiales b- ANALISIS ARQUITECTONICOProf. Ayquipa Cordova, Godofredo
  • 45. Proyecto de desarrollo del Software Rational Unified Process - Realizar un bosquejo del modelo de análisis identificando los paquetes de análisis, clases de análisis y requerimientos especiales más importantes. c- ANALIZAR PAQUETE - Agrupar clases en paquetes cuando es necesario. - Asegurar que cada paquete de análisis es lo más independiente posible de otros. - Asegurar que cada paquete de análisis satisface su propósito de realización de ciertas clases y casos de uso. d- ANALIZAR CADA CLASE DE ANALISIS - Asignar un nombre, Identificar Atributos, Identificar relaciones. - Identificar Responsabilidades: compilación de todos los roles que la clase juega en todas las realizaciones de casos de uso. - Capturar requerimientos especiales. 4- TIPOS DE CLASE DE CLASES DE ANALISIS a- CLASES LIMITE (Boundary class o interfaz): - Modelan interacción entre el sistema y sus actores. - Clarifican los requisitos en la frontera entre sistema y usuarios. Cambios en los interfaces de usuario, de comunicación, etc. afectan a las clases frontera. - Representan abstracciones de ventanas, formularios, sensores, terminales y APIs (Application Program Interfaces). - Deben estar asociados a un acto. b- CLASES ENTIDAD (Entity class): - Modelan información persistente. - Las clases entidad muestran la estructura lógica de los datos c- CLASES CONTROL (Control class): - representan coordinación, secuencia miento, transacciones y control de objetos. - Buscar una información concreta de una clase conociendo alguno de los valores de sus atributos - Crear/modificar/eliminar información - Realizar procesos/cálculos relacionados con la lógica del negocio - No pueden conectarse directamente con los actoresProf. Ayquipa Cordova, Godofredo
  • 46. Proyecto de desarrollo del Software Rational Unified ProcessEjemploCaso de Uso: INSERTAR CLIENTEPrecondición: existe un cliente para ser ingresado al sistema.Pos condición: se registra el nuevo cliente en el sistema o el cliente ya estaba cargado.FLUJO DE EVENTOS PRINCIPAL Secretaria Sistema1. Ingresa el DNI del cliente. 2. Chequea existencia.3. Ingresa nro socio, nombre, teléfono y localidad 4. Include (buscar localidad) 5. Carga al nuevo cliente.FLUJO DE EVENTOS ALTERNATIVOS 2.1. El cliente ya existe, el sistema informa tal situación y termina el caso de uso. 4.1. La localidad ingresada no existe, debe ingresar una localidad existente.SOLUCION: 1- Clase Análisis: IU_Cliente Cliente Ctrl_Cliente 2- Diagr ama de Clase Análisis y Diagrama de Colaboración IU_Cliente Ctrl_Cliente Cliente Ctrl_LocalidadProf. Ayquipa Cordova, Godofredo
  • 47. Proyecto de desarrollo del Software Rational Unified Process 4: Ingresar otros datos 5: Enviar Datos 1: Ingresar DNI 2: Chequear DNI 7: Guardar Nvo Cliente : Secretaria : IU_Cliente : Ctrl_Cliente 3: Obtener Cliente 6: Buscar localidad : Cliente : Ctrl_Localidad 3- Atributos y responsabilidades de la clase Atributos: DNI, nombre, teléfono, nrosocio. Localidad?? Responsabilidades:brindar y mantener guardada los datos del cliente. (set y get). : Cliente Atributos: ??. Responsabilidades: recibir los datos ingresados por el usuario. Chequear formato de los datos ingresados. : IU_Cliente Mostrar resultados al usuario. Atributos: ??. Responsabilidades: chequear la existencia del cliente, enviar datos para ser guardados, buscar la : Ctrl_Cliente localidad ingresada.Prof. Ayquipa Cordova, Godofredo
  • 48. Proyecto de desarrollo del Software Rational Unified Process 4- Diagrama de Secuencia : Cliente : Ctrl_Cliente : Ctrl_Localidad : IU_Cliente : Secretaria 1. Ingresar DNI 2. Chequear DNI 3. Obtener Cliente 4. Ingresar otros datos 5. Enviar Datos 6. Buscar localidad 7. Guardar Nvo Cliente 5- REALIZACION EN ANALISIS DE LOS CASOS DE USO - Es una colaboración que describe cómo se realiza en análisis un caso de uso en términos de clases de análisis y sus interacciones. - Es una colaboración que indica cómo se realiza/ejecuta un caso de uso. - La realización en análisis de un caso de uso, incluye: a- diagramas de clases: clases participantes b- diagramas de interacción: escenarios del CU. c- descripción textual del flujo de eventos d- nada de requisitos no funcionales (hasta el diseño).Prof. Ayquipa Cordova, Godofredo
  • 49. Proyecto de desarrollo del Software Rational Unified Process Modelo de Caso de Uso Modelo de Analisis Use Case Realizacion en analisis 6- DIAGRAMA DE CLASE - Una clase de análisis puede participar en varios casos de uso. - Algunas responsabilidades, atributos y asociaciones suelen ser específicos de un sólo caso de uso. 7- DIAGRAMA DE INTERACCION - La secuencia de acciones en un caso de uso comienza cuando un actor envía un mensaje a una clase límite. - Se van a utilizar diagramas de colaboración. - Ejemplo: Caso de uso “Publicar notas” del actor “Profesor”.Prof. Ayquipa Cordova, Godofredo
  • 50. Proyecto de desarrollo del Software Rational Unified ProcessEjemplo: ANALISIS DE CASO DE USO: SACAR DINEROProf. Ayquipa Cordova, Godofredo
  • 51. Proyecto de desarrollo del Software Rational Unified Process FASE DE TRANSICION 3- Modelo de Diseño e- Diseño de Caso de Uso f- Diagrama de Clase - Elementos - Relaciones - Multiplicidad g- Diagrama de Clase Interfaz h- Diagrama de Clase Entidad i- Diagrama de Colaboración j- Diagrama de Secuencia 4- Modelo Implementación a- Diagrama de Despliegue b- Diagrama de Componentes 5- Modelo de Prueba a- Especificaciones de caso de PruebaProf. Ayquipa Cordova, Godofredo
  • 52. Proyecto de desarrollo del Software Rational Unified Process MODELO DE DISEÑO 1- Concepto El Diseño de Sistemas se define el proceso de aplicar ciertas técnicas y principios con el propósito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para permitir su interpretación y realización física. La Fase de diseño (y los modelos UML resultantes expande y detalla los modelos de análisis tomando en cuenta todas las implicaciones y restricciones técnicas. El propósito del diseño es especificar una solución que trabaje y pueda ser fácilmente convertida en código fuente y construir una arquitectura simple y fácilmente extensible. Las clases definidas en el análisis fueron detalladas, y se añadieron nuevas clases para manejar áreas técnicas como base de datos, interfaz de usuario, comunicación, dispositivos, etc. La importancia del Diseño del Software se puede definir en una sola palabra Calidad, dentro del diseño es donde se fomenta la calidad del Proyecto. El Diseño es la única manera de materializar con precisión los requerimientos del cliente. El Diseño del Software es un proceso y un modelado a la vez. El proceso de Diseño es un conjunto de pasos repetitivos que permiten al diseñador describir todos los aspectos del Sistema a construir. A lo largo del diseño se evalúa la calidad del desarrollo del proyecto con un conjunto de revisiones técnicas: El diseño debe implementar todos los requisitos explícitos contenidos en el modelo de análisis y debe acumular todos los requisitos implícitos que desea el cliente. Debe ser una guía que puedan leer y entender los que construyan el código y los que prueban y mantienen el Software. El Diseño debe proporcionar una completa idea de lo que es el Software, enfocando los dominios de datos, funcional y comportamiento desde el punto de vista de la Implementación.Prof. Ayquipa Cordova, Godofredo
  • 53. Proyecto de desarrollo del Software Rational Unified Process 2- Diseño de Caso de Uso El principal objetivo de esta etapa es refinar las realizaciones de los casos de uso a través de nuevas iteraciones en el proceso. Además, también se debe refinar el modelo de diseño y los requisitos de las operaciones de las clases de diseño. Esta actividad es básicamente el centro del proceso de creación del modelo de diseño, en el que se irán refinando, iteración a iteración, el diseño de los casos de uso y de las operaciones obtenidas a partir de ellos, que aparece plasmado en el modelo de clases de diseño. Este Modelo de Diseño se reflejará en Diagramas de Clases de Diseño donde aparecerán las clases de diseño utilizadas para realizar los casos de uso, los atributos de estas clases, las operaciones de las mismas y las relaciones existentes entre ellas. Dentro de esta actividad se realizarán las siguientes acciones: Refinar las realizaciones de casos de uso ya realizadas en iteraciones anteriores. Describir las interacciones entre los objetos de diseño. Simplificar diagramas de secuencia haciendo uso de subsistemas. Estos serán descritos en la siguiente actividad de esta fase. Refinar el modelo de comportamiento de los casos de uso y la descripción del flujo de eventos. Unificar las clases de diseño y los subsistemas que aparecerán en la solución diseñada. Continuamente se deberá completar y evaluar el modelo de diseño (clases de diseño) que se modificará a lo largo de esta actividad. Caso de Uso Realizacion Caso de Uso realizacion Diseño 3- Diagrama de Clase Los diagramas de clases muestran un resumen del sistema en términos de sus clases y las relaciones entre ellas. Son diagramas estáticos que muestran qué es lo que interactúa, pero no cómo interactúa o qué pasa cuando ocurre la interacción. 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 agregación. El propósito de este diagrama es el de representar los objetos fundamentales del sistema, es decir los que percibe el usuario y con los que espera tratar para completar su tarea en vez de objetos del sistema o de un modelo de programación. 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 es un tipo de diagrama estático que describe la estructura de un sistema mostrando sus clases, atributos y las relaciones entre ellos. Los diagramas de clases son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en el sistema, y los componentes que se encargaran del funcionamiento y la relación entre uno y otro.Prof. Ayquipa Cordova, Godofredo
  • 54. Proyecto de desarrollo del Software Rational Unified ProcessElementos del Diagrama de Clase Clase: - Una clase refiere genéricamente a los objetos de una familia que se perciben con propiedades y comportamiento comunes. - Es la unidad básica que encapsula toda la información de un Tipo de Objeto (un objeto es una instancia de una clase). - Un objeto es algo distinguible que percibimos como que tiene existencia, sea física o conceptual. - Objeto: Es una instancia de una clase. Ejemplo: Zapato mocasín. - En UML, una clase es representada por un rectángulo que posee tres divisiones: - Nombre: Cada clase debe tener un nombre que la distinga de otras clases. - Atributo: representa alguna propiedad de la clase, que se encuentra en todas las instancias de la clase. - definen la estructura de una clase y de sus correspondientes objetos. - Los atributos corresponden a sustantivos y sus valores pueden ser sustantivos o adjetivos. - Dentro de una clase, los nombres de los atributos deben ser únicos (aunque puede aparecer el mismo nombre de atributo en diferentes clases). - En el momento de incluir atributos en la descripción de una clase se debe distinguir entre los atributos los cuales reflejan las características de los objetos en el mundo real, y los identificadores los cuales son utilizados - exclusivamente por razones de implementación. Estos identificadores internos del sistema no deben ser incluidos como atributos. - Operaciones o Métodos: Las operaciones son funciones o transformaciones que se aplican a todos los objetos de una clase particular. La operación puede ser una acción ejecutada por el objeto o sobre el objeto.Prof. Ayquipa Cordova, Godofredo
  • 55. Proyecto de desarrollo del Software Rational Unified Process - Visibilidad en los atributos: a- Public (+, ): Indica que el atributo será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. b- Private (-, ): Indica que el atributo sólo será accesible desde dentro de la clase (sólo sus métodos lo pueden acceder). c- 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 (herencia). - Visibilidad en el Método a- Public (+, ): Indica que el método será visible tanto dentro como fuera de la clase, es decir, es accesible desde todos lados. b- Private (-, ): Indica que el método sólo será accesible desde dentro de la clase (sólo otros métodos de la misma clase lo pueden acceder). c- 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 (herencia)Prof. Ayquipa Cordova, Godofredo
  • 56. Proyecto de desarrollo del Software Rational Unified Process Multiplicidad Representa el número de objetos que pueden conectarse a través de una relación de asociación Especificación de multiplicidad (mínima...máxima) 1 Uno y sólo uno 1..1 Uno y sólo uno 0..1 Cero o uno M..N Desde M hasta N (enteros naturales) * Cero o muchos 0..* Cero o muchos 1..* Uno o muchos (al menos uno) 1..5 Entre uno y cinco. Relaciones a- 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.Ejemplo1:Prof. Ayquipa Cordova, Godofredo
  • 57. Proyecto de desarrollo del Software Rational Unified Process Ejemplo2: Ejemplo 3: Ejemplo4:Prof. Ayquipa Cordova, Godofredo
  • 58. Proyecto de desarrollo del Software Rational Unified Process EjerciciosProf. Ayquipa Cordova, Godofredo
  • 59. Proyecto de desarrollo del Software Rational Unified Process Tipos de Relaciones Composición: Es una relación de todo y parte de, donde el todo esta formado por objetos parte de que lo componen. Se pueden observar las siguientes características: - Dependencia existencial: El elemento dependiente desaparece al destruirse el que lo contiene y, si es de cardinalidad 1, es creado al mismo tiempo. - Pertenencia fuerte: Se puede decir que el objeto contenido es parte constitutiva y vital del que lo contiene. - No compartición: Los objetos contenidos no son compartidos, esto es, no forman parte del estado de otro objeto. Agregación: Es una relación de contenedor y contenido, donde el contenedor contiene objetos contenido. Se pueden observar las siguientes características: - Independencia existencial: El elemento contenido no desaparece al destruirse el que lo contiene. - Pertenencia débil: Se puede decir que el objeto contenedor no contiene realmente al objeto contenido, sino que tiene una referencia a él. - Compartición: Los objetos contenidos también pueden formar parte del estado de otro objetoProf. Ayquipa Cordova, Godofredo
  • 60. Proyecto de desarrollo del Software Rational Unified ProcessProf. Ayquipa Cordova, Godofredo
  • 61. Proyecto de desarrollo del Software Rational Unified Process Herencia: Indica que una subclase hereda los métodos y atributos especificados por una superclase, de esta forma la subclase además de poseer sus propios métodos y atributos, poseerá las características y atributos visibles de la superclase (public y protected), ejemplo: Clase Asociativa: describe una asociación que refiere a una familia de relaciones entre objetos sobre las que se perciben propiedades que son propias de las relaciones.Prof. Ayquipa Cordova, Godofredo
  • 62. Proyecto de desarrollo del Software Rational Unified Process Dependencia: 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 está condicionado a la instanciación proveniente desde el objeto Aplicación): Herencia Múltiple: - Se presenta cuando una subclase tiene más de una superclase - La herencia múltiple debe manejarse con precaución. Algunos problemas son el conflicto de nombre y el conflicto de precedencia. - Se recomienda un uso restringido y disciplinado de la herencia. - Uso disciplinado de la herencia múltiple: clasificaciones disjuntas con clases padre en hojas de jerarquías alternativasProf. Ayquipa Cordova, Godofredo
  • 63. Proyecto de desarrollo del Software Rational Unified ProcessDiagrama de Clase Interfaz: Representa la relación entre las clases que son asignadas a un determinadoformulario con parámetros de implementación.Diagrama de Clase Entidad: Representa la relación entre las clases que migran a un determinado gestor debase de datos.Prof. Ayquipa Cordova, Godofredo
  • 64. Proyecto de desarrollo del Software Rational Unified Process MODELO DE IMPLEMENTACION1- Concepto:En este flujo de trabajo se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y demás.Además se deben hacer las pruebas de unidad: cada implementador es responsable de probar las unidades queproduzca. El resultado final de este flujo de trabajo es un sistema ejecutable.En cada iteración habrá que hacer lo siguiente: Planificar qué subsistemas deben ser implementados y en qué orden deben ser integrados, formando el Plan de Integración. Cada implementador decide en qué orden implementa los elementos del subsistema. Si encuentra errores de diseño, los notifica. Se prueban los subsistemas individualmente. Se integra el sistema siguiendo el plan.La estructura de todos los elementos implementados forma el modelo de implementación. La integración debeser incremental, es decir, en cada momento sólo se añade un elemento. De este modo es más fácil localizarfallos y los componentes se prueban más a fondo. En fases tempranas del proceso se pueden implementarprototipos para reducir el riesgo. Su utilidad puede ir desde ver si el sistema es viable desde el principio,probar tecnologías o diseñar la interfaz de usuario. Los prototipos pueden ser exploratorios (desechables) oevolutivos. Estos últimos llegan a transformarse en el sistema final.2- Diagrama de ComponenteUn diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestralas dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, libreríascompartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de laarquitectura de software pero pueden ser usados para modelar y documentar cualquier arquitectura de sistema.Debido a que estos son más parecidos a los diagramas de casos de usos estos son utilizados para modelar lavista estática y dinámica de un sistema. Muestra la organización y las dependencias entre un conjunto decomponentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente serealizan por partes. Cada diagrama describeun apartado del sistema.En él se situarán librerías, tablas, archivos,ejecutables y documentos que formen partedel sistema.Uno de los usos principales es que puedeservir para ver qué componentes puedencompartirse entre sistemas o entrediferentes partes de un sistema. a- Componente: Un componente es una parte física de un sistema (modulo, base de datos, programa ejecutable, etc.). Se puede decir que un componente es la materialización de una o más clases, porque una abstracción con atributos y métodos pueden ser implementados en los componentes.Prof. Ayquipa Cordova, Godofredo
  • 65. Proyecto de desarrollo del Software Rational Unified Process b- Dependencias: La dependencia entre dos componentes se muestra como una flecha punteada. La dependencia quiere decir que una componente necesita de la otra para completar su definición. c-3- Diagrama de DespliegueEl Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza paramodelar el hardware utilizado en las implementaciones de sistemas y las relaciones entre sus componentes.Los elementos usados por este tipo de diagrama son nodos (representados como un prisma), componentes(representados como una caja rectangular con dos protuberancias del lado izquierdo) y asociaciones.La mayoría de las veces el modelado de la vista de despliegue implica modelar la topología del hardwaresobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósitogeneral, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficientepara que un ingeniero software pueda especificar la plataforma sobre la que se ejecuta el software del sistema . a- Nodos: Los nodos son objetos físicos que existen en tiempo de ejecución, y que representan algún tipo de recurso computacional (capacidad de memoria y procesamiento): - Computadores con procesadores - Otros dispositivos - impresoras - lectoras de códigos de barras - dispositivos de comunicación • Los nodos se conectan mediante asociaciones de comunicación. • Estas asociaciones indican: – Algún tipo de ruta de comunicación entre los nodos – Los nodos intercambian objetos o envían mensajes a través de esta ruta – El tipo de comunicación se identifica con un estereotipo que indica el protocolo de comunicación o la red.Prof. Ayquipa Cordova, Godofredo