Metodologia rup

Proyecto de desarrollo del Software Rational Unified Process

METODOLOGIA RUP

(RATIONAL UNIFIED PROCESS)

Proyecto: __________________________________________

Sistema: ___________________________________________

Integrantes:

Jefe de Proyecto: ________________________________________

Colaboradores:

1- Colaborador12- Colaborador23- Colaborador….n

Prof. Ayquipa Cordova, Godofredo


FASE

DE

INICIO

Consideraciones:

1- Aspectos generales de la organización2- Plan de desarrollo de software3- Modelo de Negocio

a- Unidad Organizacionalb- Paquete de Negocioc- Diagrama de Paquete de Negociod- Diagrama de Caso de Uso de Negocioe- Especificaciones de Caso de Uso de Negociof- Diagrama de Actividad de Negociog- Diagrama de Objetos de Negocio



PROYECTO DE DESARROLLO DE SOFTWARE

ASPECTOS ORGANIZACIONALES

1- Organización1.1-Introducción1.2-Reseña histórica1.3-Ubicación Geográfica

2- Estructura Organizacional2.1- Visión2.2- Misión2.3- Metas2.4- Objetivo

- General- Específicos

2.5- Organigrama

3- Área de Desarrollo

3.1- Descripción del área3.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 manuales



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óricaOrigen, creación y evolución de la organización

1.3- Ubicación Geográfica (mapa)

2- Estructura Organizacional2.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 el 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 DesarrolloEstablecer 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:

3.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.


Integrante Cargo Funciones Responsabilidades


3.5- Recomendaciones

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.


Problemas Descripcion

Problema1Problema2

Problemas Descripcion

Problema1Problema2

Administrativo

Organizacional

Recomendaciones Descripcion

Recomendación 1Recomendación 2

Recomendaciones Descripcion

Recomendación 1Recomendación 2

Administrativo

Organizacional


PLAN DE DESARROLLO DE SOFTWARE

1. Introducción

2. 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 Software

3. Organización del Proyecto

3.1 Participantes en el Proyecto

3.3 Roles y Responsabilidades

4. Gestión del Proceso

4.1 Tecnologia de Informacion

4.1..1 Evaluacion Tecnologica

4.1.2 Recomendaciones

4.2 Plan del Proyecto4.2.1 Plan de las Fases4.2.2 Calendario del Proyecto



Proyecto de desarrollo del Software Rational

Unified Process 1. 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 Proyecto

2.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;- 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, los 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 SoftwareEs el presente documento.

2) Modelo de Casos de Uso del NegocioEs 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 NegocioEs 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 UsoEl 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 UsoPara 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 UsuarioSe 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 de 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 RiesgosEste 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


Clientes y

Usuarios

Desarrollador

essoftwa

re objetiv

o Maqui

na

Personas, Equipos, Organizaciones

Ideas…Especificación… Diseño… Código


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 aprendidas

2.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.



3.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.


Analistas - Programadores.

Aquí se declara el perfil de los candidatos a estos puestos, así como sus nombres y apellidos

Ingeniero de Software.


3.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

Jefe de Proyecto

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 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.

Analista de Sistemas

Captura, especificación y validación de requisitos, interactuando con el cliente y los usuarios mediante entrevistas. Elaboración del Modelo de Análisis y Diseño. Colaboración en la elaboración de las pruebas funcionales y el modelo de datos.

Programador Construcción de prototipos. Colaboración en la elaboración de las



pruebas funcionales, modelo de datos y en las validaciones con el usuario

Ingeniero de Software

Gestión de requisitos, gestión de configuración y cambios, elaboración del modelo de datos, preparación de las pruebas funcionales, elaboración de la documentación. Elaborar modelos de implementación y despliegue.

4. 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- Recomendaciones

4.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.



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 Elaboración

En esta fase se analizan los requisitos y se desarrolla un prototipo de 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 Construcción

Durante la fase de construcción se terminan de analizar y diseñar 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 apoyo 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 Transición En esta fase se prepararán dos releases para distribució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.



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ón


12 Paquetes del Análisis

13 Realización de Casos de Uso

14 Modelo de Clases del Análisis


Fase de Construcción

Fase de Transición



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 siguientes etapas:

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 del Negocio 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.

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 Organizacionalb- Paquete de Negocioc- Diagrama de Paquete de Negociod- Diagrama de Caso de Uso de Negocioe- Especificaciones de Caso de Usof- Diagrama de Actividad de Negociog- Diagrama de Objetos de Negocio

Unidad Organizacional

La unidad Organizacional es un contenedor de objetos de negocio, representa la organización

Paquete de Negocio

Representa las áreas de la organización.


Unidad OrganizacionalLibreria Juanito S.A


Diagrama de Paquete de Negocio

- Representa la interrelación de las áreas con el área en desarrollo- Muestra la dependencia de las áreas


Paquete de Negocio

VentasCompras

Almacen

Ventas

Compras

Almacen

DIAGRAMA DE PAQUETE DE NEGOCIO

Cliente


Diagrama 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.

Elementos:

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.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:

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.


Vendedor


- 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.

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.

- 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:

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:


Persona

Natural Juridico

ClienteSolici tar Credito

Vendedor

Evaluar Credito


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.

-

Ejemplo:


Caso de Uso Origen Caso de Uso Destino

<<include>>

Analizar RiesgoAnalizar Documentos

Credito

Evaluar Credito

<<include>>

<<include>>


- 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.

Ejemplo:


Caso de Uso Origen Caso de Uso destino<<extend>>

Solici tar Nueva Tarjeta

ClienteSolici tar Prestamo

[tarjeta caducada]

<<extend>>


Ejercicio 1: Sociedad de amigos del libro

La sociedad de amigos del libro se dedica a la venta de libros a sus socios a través del teléfono. Esta sociedad actúa como intermediario entre las editoriales y sus socios, proporcionándoles los libros que estos solicitan a precios reducidos. La empresa está estructurada en varios departamentos, uno de los cuales se encarga de los pedidos, almacén y el de contabilidad.

Los socios pueden realizar sus pedidos por teléfono al departamento de pedidos. En la petición se especifican los siguientes datos: nombre del socio y el número de ejemplares solicitados por título. Previamente a la aceptación del pedido, se verifica que el socio este registrado y que no tenga ninguna cuota vencida o pagos pendientes. Para ello se hacen las comprobaciones oportunas y en cualquiera de estos supuestos el pedido se rechaza (lo que se comunica al socio en el momento). Si todo es correcto se elabora la nota de pedido y pasa a la situación de pendiente por atender.

El departamento de pedidos utiliza dos o tres veces a la semana los pedidos pendientes para generar un pedido a las editoriales (un listado con los títulos solicitados y el número total de ejemplares de cada título). Cuando se reciben los libros, el departamento de almacén verifica el estado del producto, si existe alguna anomalía con el libro, este es devuelto a la editorial y esta correcto se procede a la distribución en los anaqueles, el departamento de almacén entrega los documentos (guía y factura) de la editorial a contabilidad para ser cancelada.

Preguntas:

Realice el diagrama de casos de uso de negocio correspondiente

Ejercicio 2: Fabrica de productos

Proceso 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.

DIAGRAMA DE ACTIVIDAD DE NEGOCIO

Es la representación de una secuencia de actividades dentro de un caso de uso de negocio. Provee una manera grafica 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 Flujo

Elementos:

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.

Ejemplo 1



Ejemplo2



Ejemplo 3

Ejercicio:

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 un 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 el 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.



MODELO DE ANALISIS DE NEGOCIO

El modelo del análisis de negocio describe la realización de los casos del uso del negocio en función a la interacció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 ser relacionados 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 no hace 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 del negocio), y definen cómo obran recíprocamente para realizar el comportamiento descrito en los casos del uso del negocio.

El analista del negocio es responsable de la estructura y de la integridad del modelo, mientras que los diseñ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 en cómo el sistema de software será utilizado como parte de los procesos del negocio. Los arquitectos del software utilizan el modelo para definir una arquitectura del software que para la organización y para identificar clases en modelos del análisis y del diseño del software

Elemnetos:

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 Negocio5- 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 negocio

Ejemplo de daigrama de objetos de negocio:



FASE

DE

ELABORACION

1- Diagrama de Paquete de Sistema2- Modelo de Caso de Uso (Modelo de Requisitos)

a- Diagrama de caso de usob- Diagrama de Actividadc- Especificaciones de caso de uso

3- Prototipos (interfaz de usuario)



1- DIAGRAMA DE PAQUETE DE SISTEMA

En el Lenguaje Unificado de Modelado, un diagrama de paquetes muestra como un sistema está dividido en agrupaciones lógicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete está pensado como un directorio, los diagramas de paquetes suministran una descomposición de la jerarquía lógica de un sistema.

Los Paquetes están normalmente organizados para maximizar la coherencia interna dentro de cada paquete y minimizar el acoplamiento externo entre los paquetes. Con estas líneas maestras sobre la mesa, los paquetes son buenos elementos de gestión. Cada paquete puede asignarse a un individuo o a un equipo, y las dependencias entre ellos pueden indicar el orden de desarrollo requerido.

2- MODELO DE CASO DE USO

El Modelo de Casos de uso es un modelo que describe los requerimientos funcionales del sistema en forma de Casos de uso.En UML los Casos de Uso son los principales medios para capturar la funcionabilidad del sistema desde la perspectiva del usuario y muchas 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 el sistema en operación. Se ejecuta en su totalidad o no se ejecuta nada, devolviendo algo de valor al usuario.

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

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.

Relación: Comunicación (relación entre un actor y un caso de uso con el que interactúa; se representa simplemente con una línea). Relacion entre casos de uso : Include y Extend

b-

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.

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 Uso1.1- Descripcion

2- Flujo de Eventos2.1- Flujo Basico2.2- Flujos Alternativos

2.2.1- Flujo alternativo2.2.2- Otro flujo alternativo

3- Precondiciones3.1- Una Precondicion3.2- Otra precondicion

4- Poscondiciones4.1- Una poscondicion4.2- Otra poscondicion

Ejemplo de especificaciones 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)

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”

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 Eventos

Flujo Básico

1. 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”.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 error

3- 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:



Hotel

El dueño de un hotel nos pide desarrollar un programa para consultar las habitaciones disponibles y

poder reservar habitaciones en su hotel.

El hotel posee tres tipos de habitaciones: simple, doble y matrimonial, y dos tipos de clientes: habituales y esporádicos. Una reserva almacena datos del cliente, de la habitación reservada, la fecha de comienzo 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).

El diseño a desarrollar debe facilitar la extensibilidad de nuevos tipos de habitaciones o clientes y a su vez

permitir agregar nuevas consultas.

Obtener el diagrama de casos de uso.



FASE

DE

CONSTRUCCION

1- Modelo de Análisisa- Caso de Uso Análisisb- Clase Análisis

- Clase Boundary- Clase Control- Clase Entidad

c- Diagrama de Colaboración Clase Análisisd- Diagrama de Secuencia Clase análisis

2- Modelo de Datos (Data Modeler Diagram)



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 contratoentre el cliente y desarrolladores, determinaQUE hará el sistema y se decide si elsistema se llevará a cabo o no

Se utiliza principalmente por losdesarrolladores para entender QUE hará elsistema y plantear interacciones quecomiencen a definir el COMO

Puede contener redundancias einconsistencias

Se reducen considerablemente lasredundancias e inconsistencias

Captura las funcionalidades del sistema Refina y describe la forma en que serealizarán las funcionalidades del sistema

Define los CASOS DE USO y a futuroserán analizados en el Modelo de Análisis

Define REALIZACIONES DE CASOS DEUSO, donde cada uno representa el análisisde 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 ARQUITECTONICO- 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 ANALISISa- 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 actores

Ejemplo

Caso 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 PRINCIPALSecretaria Sistema

1. Ingresa el DNI del cliente.3. Ingresa nro socio, nombre, teléfono y localidad

2. Chequea existencia.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 Ctrl_Cliente Cliente


2- Diagrama de Clase Análisis y Diagrama de Colaboración

3- Atributos y responsabilidades de la clase


IU_Cliente ClienteCtrl_Cliente

Ctrl_Localidad

: Cliente

: IU_Cliente

: Ctrl_Cliente

Atributos: DNI, nombre, teléfono,nrosocio. Localidad??Responsabilidades:brindar ymantener guardada los datos delcliente. (set y get).

Atributos: DNI, nombre, teléfono,nrosocio. Localidad??Responsabilidades:brindar ymantener guardada los datos delcliente. (set y get).

Atributos: ??.Responsabilidades: recibir los datosingresados por el usuario. Chequearformato de los datos ingresados.Mostrar resultados al usuario.

Atributos: ??.Responsabilidades: chequear laexistencia del cliente, enviar datospara ser guardados, buscar lalocalidad ingresada.


4- Diagrama de Secuencia

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 participantesb- diagramas de interacción: escenarios del CU.c- descripción textual del flujo de eventosd- nada de requisitos no funcionales (hasta el diseño).


: Cliente : Ctrl_Cliente : Ctrl_Local idad : IU_Cliente : Secretaria

1. Ingresar DNI

2. Chequear DNI

3. Obtener Cl iente

4. Ingresar otros datos

5. Enviar Datos

6. Buscar local idad

7. Guardar Nvo Cliente


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”.


Use Case Realizacion en analisis

Modelo de Caso de Uso Modelo de Analisis


Ejemplo: ANALISIS DE CASO DE USO: SACAR DINERO



FASE

DE

TRANSICION3- Modelo de Diseño

e- Diseño de Caso de Usof- Diagrama de Clase

- Elementos- Relaciones- Multiplicidad

g- Diagrama de Clase Interfazh- Diagrama de Clase Entidadi- Diagrama de Colaboración j- Diagrama de Secuencia

4- Modelo Implementación

a- Diagrama de Despliegueb- Diagrama de Componentes

5- Modelo de Prueba

a- Especificaciones de caso de Prueba



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.



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.

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.


Caso de Uso Realizacion Caso de Uso real izacion Diseño


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.

Elementos 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.


http://es.wikipedia.org/wiki/Sistema


- 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.

- 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)

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:

Ejemplo2:



Ejemplo 3:

Ejemplo4:

Ejercicios



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

objeto



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.



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 conflictode 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 alternativas



Diagrama de Clase Interfaz: Representa la relación entre las clases que son asignadas a un determinado formulario con parámetros de implementación.

Diagrama de Clase Entidad: Representa la relación entre las clases que migran a un determinado gestor de base de datos.


Cliente

NombreDireccionTelefonoDocumento

Factura

FechaTotalIgvMoneda

Calcular IGV()Calcular Importe()

1..n1 1..n1

Agregar Persona Conocida

Nombre : LabelApn : textfieldTelefono : LabelApf : texfieldEmail : LabelEmi : txtfieldAcepta : ButtonCancelar : Button

Acepta()Cancelar()

<<FRM>>

Nombre: personaApn:20 letrasTelefono: personaApf: 9 digitosEmail: personaEmi: 20 letrasBotones: acepta y Cancelar

T_Factura

Fecha : SMALLINTTotal : SMALLINTIgv : SMALLINTMoneda : SMALLINTT_Factura_ID : INTT_Cliente_ID : INT

<<PK>> PK_T_Factura1()<<FK>> FK_T_Factura0()<<Index>> TC_T_Factura1()

T_Cliente

Nombre : SMALLINTDireccion : SMALLINTTelefono : SMALLINTDocumento : SMALLINTT_Cliente_ID : INT

<<PK>> PK_T_Cliente0()

1 1..*1 1..*

<<Non-Identifying>>


MODELO DE IMPLEMENTACION

1- 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 que produzca. 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 debe ser incremental, es decir, en cada momento sólo se añade un elemento. De este modo es más fácil localizar fallos y los componentes se prueban más a fondo. En fases tempranas del proceso se pueden implementar prototipos 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) o evolutivos. Estos últimos llegan a transformarse en el sistema final.

2- Diagrama de Componente

Un diagrama de componentes representa cómo un sistema de software es dividido en componentes y muestra las dependencias entre estos componentes. Los componentes físicos incluyen archivos, cabeceras, librerías compartidas, módulos, ejecutables, o paquetes. Los diagramas de Componentes prevalecen en el campo de la arquitectura 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 la vista estática y dinámica de un sistema. Muestra la organización y las dependencias entre un conjunto de componentes. No es necesario que un diagrama incluya todos los componentes del sistema, normalmente se realizan por partes. Cada diagrama describe un apartado del sistema.En él se situarán librerías, tablas, archivos, ejecutables y documentos que formen parte del sistema.Uno de los usos principales es que puede servir para ver qué componentes pueden compartirse entre sistemas o entre diferentes 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.

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 Despliegue

El Diagrama de Despliegue es un tipo de diagrama del Lenguaje Unificado de Modelado que se utiliza para modelar 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 hardware sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificación hardware de propósito general, se ha diseñado para modelar muchos de los aspectos hardware de un sistema a un nivel suficiente para 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.


http://es.wikipedia.org/wiki/Lenguaje_Unificado_de_Modelado



Date post:	13-Jun-2015
Category:	Documents
Upload:	mcdonalds-peru
View:	2,807 times
Download:	2 times

Metodologia rup

Documents