PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE
INGENIERIA DE SOFTWARE PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE Ing. Sanchez Castillo Eddye Arturo Sesión 02

PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE
Fases y modelos. Modelo del Negocio. Diagrama de actividades del negocio. Casos de uso del negocio. Modelos de objetos del negocio Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo
EL PROCESO UNIFICADO El Proceso Unificado es un proceso de desarrollo de software. Un proceso de desarrollo de software es el conjunto de actividades necesarias para transformar los requisitos de un usuario en un sistema software. El Proceso Unificado está basado en componentes, lo cual quiere decir que el sistema software en construcción está formado por componentes software, interconectados a través de interfaces bien definidas. 03 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

EL PROCESO UNIFICADO El Proceso Unificado utiliza el Lenguaje Unificado de Modelado (Unified Modeling Language. UML) para preparar todos los esquemas de un sistema software. De hecho, UML es una parle esencial del Proceso Unificado. 04 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

EL PROCESO UNIFICADO Un sistema software ve la luz para dar servicio a sus usuarios. Por lo tanto, para construir un sistema con éxito debemos conocer lo que sus futuros usuarios necesitan y desean. El término usuario no sólo hace referencia a usuarios humanos sino a otros sistemas. En este sentido, el término usuario representa alguien o algo que interactúa con el sistema que estamos desarrollando. Un ejemplo de interacción seria una persona que utiliza un cajero automático. 05 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

EL PROCESO UNIFICADO Y LOS C.U.
Un proceso de software “guiado por los casos de uso, centrado en la arquitectura, iterativo e incremental. Reconoce la importancia de la comunicación con el cliente y la orientación a describir el punto de vista del cliente con respecto a un sistema (ejem el CdU). Enfatiza la importancia de la arquitectura de software, focalizando las metas correctas, como el entendimiento, el ajuste a los cambios futuros y la reutilización” Plantea un flujo de proceso iterativo e incremental, concordando con la característica evolutiva del software moderno. 06 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

LA VIDA DEL PROCESO UNIFICADO
El Proceso Unificado se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema. Cada ciclo concluye con una versión del producto para los clientes. Cada ciclo consta de cuatro fases: inicio, elaboración, construcción y transición. Cada fase se subdivide a su vez en iteraciones. 07 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

FASES DEL PROCESO UNIFICADO
Lanzamiento Fig. Relación del Proceso Unificado con la actividades genéricas del marco de trabajo del proceso de software 08 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

INICIO Comprende la comunicación con el cliente y las actividades de planeación. Propósito: definir y acordar el alcance del proyecto con los patrocinadores, identificar los riesgos asociados al proyecto, proponer una visión muy general de la arquitectura de software y producir el plan de las fases y el de iteraciones posteriores. Los requisitos fundamentales del negocio se describen a través Casos de Uso (CU). Los CU describen las características y funciones deseables para cada clase importante de usuarios. 09 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

ELABORACION Se seleccionan los casos de uso que permiten definir la arquitectura base del sistema, se realiza la especificación de los casos de uso seleccionados y el primer análisis del dominio del problema, se diseña la solución preliminar. Expande la representación arquitectónica para incluir 5 visiones diferentes del software: El modelo de CU El modelo de análisis El modelo de diseño El modelo de implementación El modelo de despliegue. 010 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

CONSTRUCCION Desarrolla o adquiere los componentes del software que hará que cada CU sea operativo para los usuarios finales. Se diseñan y ejecutan pruebas de unidad para cada componente. Se realizan las actividades de integración (ensamble de componentes y pruebas de integración) 011 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

TRANSICION Propósito: asegurar que el software esté disponible para los usuarios finales, ajustar los errores y defectos encontrados en las pruebas de aceptación, capacitar a los usuarios y proveer el soporte técnico necesario. Se debe verificar que el producto cumpla con las especificaciones entregadas por las personas involucradas en el proyecto.. Al final de esta fase, el incremento de software se convierte en un lanzamiento de software utilizable. 012 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

Análisis de requisitos Enfoques de modelado del análisis Conceptos del modelado de datos Análisis orientado a objetos. Conceptos Modelado basado en escenarios 5.1 Especificación y Diagrama de Casos de Uso 5.2 Diagramas de actividad 013 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

MODELADO DE ANALISIS La Ingeniería de Software comienza con una serie de tareas de modelado que conducen a una especificación de requisitos y a una representación completa del diseño del software que se construirá. El modelo de análisis, conformado por una serie de modelos, es la primera representación técnica del sistema. ANÁLISIS DE REQUISITOS Por medio del modelado del análisis, el ingeniero de software se centra primero en el qué, no en el cómo. ¿Qué objetos manipula el sistema? ¿Qué funciones debe desempeñar el sistema? ¿Qué comportamientos muestra el sistema? ¿Qué interfaces se definen? Y, ¿Qué restricciones se aplican? 014 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

MODELADO DE ANALISIS Arquitectura de aplicación del SW Interfaz con el usuario Funcionalidad general del sistema (aplicando SW, HW, Datos, Humanos) Modelo de Diseño Modelo de Análisis Estructura en el nivel de componentes Descripción del sistema (llena el vacío entre una descripción al nivel de sistemas y el diseño de software) Y, otros elementos del sistema (Ejm: seguridad, rendimiento) Fig. El modelo de análisis como un puente entre la descripción del sistema y el modelo de diseño 15 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

ENFOQUE DEL MODELADO DE ANALISIS Una visión del modelado del análisis, llamado análisis estructurado, considera que los datos y el proceso que transforma los datos son entidades separadas. Los objetos de datos se modelan en una forma que define sus atributos y relaciones. Los procesos que manipulan los objetos de los datos se modelan de tal manera que muestran cómo transforman los datos, mientras los objetos de datos fluyen por el sistema. Un segundo enfoque del modelado del análisis, llamado análisis orientado a objetos, se centra en la definición de clases y en la manera en que éstas colaboran entre ellas para efectuar los requisitos del cliente. El UML y el proceso unificado están orientados a objetos en forma predominante. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos. 16 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

CONCEPTOS DEL MODELADO DE DATOS
El modelado del análisis a menudo comienza con el modelado de datos. El ingeniero o analista del software define todos los objetos de datos que se procesan dentro del sistema y las relaciones entre los objetos de datos, además de otra información pertinente para las relaciones. OBJETOS DE DATOS Un objeto de datos es una representación de casi cualquier información compuesta que el software debe entender. Información compuesta se refiere a algo que tiene muchas propiedades o atributos diferentes. Un objeto de datos puede ser: una entidad externa (por ejem., cualquier cosa que produzca o consuma información), una cosa (por ejemplo, un reporte o un despliegue), un suceso (como una transacción bancaria o, una llamada telefónica) o un evento (como alerta por clave errada o, una alarma), un rol (por ejem., un comprador, un auditor), una unidad organizacional (como un departamento de logística), un lugar (como un almacén), o una estructura (como un archivo). (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos. 17 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

Por ejemplo, una persona o un auto pueden verse como un objeto de datos en el sentido de que cualquier de ellos puede definirse en términos de un conjunto de atributos. Un objeto de datos encapsula sólo datos: no existe alguna referencia dentro del objeto de datos a las operaciones que actúan sobre los datos. Une los objetos de datos entre si Atributos referenciales Identificador Atributos descriptivos (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos. Instancia Nombres de atributos 18 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

ATRIBUTOS Los atributos definen las propiedades de un objeto de datos y toman una de las tres características diferentes. Se pueden utilizar para: 1) nombrar una ocurrencia de objeto de datos. 2) describir la ocurrencia, o 3) hacer referencia a otra ocurrencia en otra tabla. Además, se debe definir uno o más atributos como un identificador es decir, el atributo identificado se convierte en una “clave” cuando se desea encontrar una concurrencia del objeto de datos. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos. 19 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

RELACIONES Los objetos de datos están conectados entre si de muchas maneras diferentes. Por ejemplo, dos objetos de datos, persona y auto, pueden representarse con la simple notación ilustrada. Se establece una conexión entre persona y auto porque los objetos se relacionan entre sí. persona posee automóvil persona automóvil (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos. autorizada para manejar a) Una conexión básica entre objetos de datos b) Relaciones entre objetos de datos 20 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

CARDINALIDAD Y MODALIDAD Se debe entender cuántas ocurrencias del objeto X están relacionadas con cuántas ocurrencias del objeto Y. Esto conduce al concepto del modelado de datos llamado cardinalidad. El modelo de datos debe ser capaz de representar el número de ocurrencias de los objetos en una relación dada. Ejm.: si un objeto puede relacionarse sólo con otro objeto entonces la relación es 1: 1 Y, si es con muchos objetos entonces la relación es 1:N Cuando la relación es de muchas ocurrencias a muchas ocurrencias, entonces es M:N “Cardinalidad es la especificación del número de ocurrencias de un (objeto) que puede relacionarse con el número de ocurrencias de otro (objeto)”. Sin embargo, no indica si un objeto particular de datos debe participar o no en la relación. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos. 21 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

Clase Automóvil Ejemplos * * Clase Motor Clase Llantas Clase Techo Corredizo Clase Dados Clase Asientos Clase Chasis (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos. “Un automóvil se compone de un chasis, un motor, 4 ó 5 llantas, un techo corredizo, cero ó más dados que cuelgan del espejo retrovisor y 2 ó más asientos” 22 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

CONCEPTOS ORIENTADOS A OBJETOS
ANALISIS ORIENTADO A OBJETOS El objetivo del análisis orientado a objeto (AOO) es definir todas las clases (además de las relaciones y el comportamiento asociado con ellas) relevantes para el problema y que deben resolverse. Esto se logra llevando a cabo algunas tareas: Deben comunicarse los requisitos básicos del usuario entre el cliente y el ingeniero de software. Deben identificarse las clases (es decir, se definen los atributos y métodos). Se define una jerarquía de clases. Deben representarse las relaciones de objeto a objeto (conexiones entre objetos). Debe modelarse el comportamiento del objeto. Las tareas 1 a 5 se vuelven a aplicar de manera iterativa hasta que el modelo esté completo. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos. 23 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

CONCEPTOS ORIENTADOS A OBJETOS
Atributos: una colección de valores de los datos que describen una clase. Clase: encapsula los datos y las abstracciones de procedimiento requeridos para describir el contenido y el comportamiento de alguna entidad del mundo real. Dicho de otra manera, una clase es una descripción generalizado (por ejemplo, una plantilla un patrón o un plano de trabajo) que describe una colección de objetos similares. Objetos: instancias de una clase específica. Los objetos heredan los atributos y operaciones de una clase. Operaciones: también llamadas métodos servicios proporcionan la representación de uno de los comportamientos de una clase. Subclase: una especialización de la superclase. Una subclase puede heredar tanto los atributos como las operaciones de una superclase. Superclase: también llamada una clase básica, es una generalización de un conjunto de clases que están relacionadas con ella. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos. 24 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

MODELADO BASADO EN ESCENARIOS
La satisfacción del usuario mide el éxito de un sistema. Si los ingenieros de software entienden la manera en que los usuarios finales quieren interactuar con el sistema, el equipo de software será más capaz de caracterizar en forma apropiada los requisitos y construir modelos significativos de análisis y diseño. Por lo tanto, el modelado del análisis con UML comienza con la creación de escenarios en la forma de casos de uso y diagramas de actividad. CASOS DE USO Un caso de uso captura las interacciones que ocurren entre los productores y consumidores de información y del sistema en sí mismo. Un caso de uso describe un escenario de uso específico en un lenguaje directo desde el punto de vista de un actor definido. Un ACTOR no es una persona específica, sino el rol que desempeña una persona (o dispositivo) dentro de un contexto específico. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos. 25 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

MODELADO BASADO EN ESCENARIOS
DIAGRAMA DE ACTIVIDAD El diagrama de actividad en UML complementaria el caso de uso al proporcionar una representación gráfica del flujo de interacción dentro de un escenario específico. El diagrama de actividad, con carriles, permite al modelador la representación del flujo de actividades descritas por el caso de uso y al mismo tiempo, indicar que actor (si hay múltiples actores involucrados en una función específica) o clase de análisis tiene la responsabilidad de la acción descrita mediante un rectángulo de actividad. (Object Management Group) Consorcio con más de 700 compañías con el objetivo de proveer una estructura común para el desarrollo de aplicaciones usando técnicas de programación orientado a objetos. OMG es responsable de las especificaciones CORBA. (Common Object Request Broker Architecture). CORBA es un estándar definido por el OMG (Object Management Group) que permite escribir componentes de software en múltiples lenguajes y ejecutarlos en múltiples computadoras para trabajar juntos. 26 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

ESPECIFICACIÓN DE CASOS DE USO (ECUN)
PREGUNTAS A FORMULAR: ¿Quiénes son los actores y cuáles son sus tareas? El actor ¿qué información crea, modifica, guarda, lee o destruye? El actor ¿ qué cambios externos debe notificar al sistema? El sistema ¿ qué cambios internos debe informar al actor? ESPECIFICACIÓN DE UN CDU: Objetivo del CdU: ¿qué debe realizar? El inicio: ¿cuándo y qué actores lo produce? El fin: ¿cuándo se produce y qué valor devuelve? La interacción Actor- CdU: ¿qué mensajes intercambian ambos? Cronología y origen de las interacciones Frecuencia del comportamiento: ¿qué operaciones son iteradas? Escenarios: ¿qué ejecuciones alternativas se presentan en el CdU? 27 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

ESPECIFICACIÓN DE CASOS DE USO (ECUN)
A continuación se mencionan algunos elementos extras con los que puedes complementar la plantilla para documentar tus especificaciones de casos de uso. Propósito. Si comienzas por este punto se te facilitará definir los pasos más relevantes para ejecutar el caso de uso. Precondiciones. Son las condiciones que se deben de cumplir en el sistema antes de iniciarlo. El estado en que se debe encontrar el sistema antes de ejecutarlo. Postcondiciones. Te indica como queda el sistema después de ejecutar el caso de uso. Requerimientos Especiales. Cualquier requerimiento extra del sistema, asociado al caso de uso especificado. Puntos de Extensión. Puntos donde se extiende el caso de uso mediante una relación de <<extend>>. CURSO: Análisis y Diseño de Sistemas

CURSO: Análisis y Diseño de Sistemas
ESTRUCTURA DE UN ECUN Caratula <NOMBRE DEL PROYECTO> ESPECIFICACIONES DE CASO DE USO DE NEGOCIO (ECUN) <NOMBRE DEL PROCESO> Pag. 2 HISTORIAL Pag. 3 TABLA DE CONTENIDOS FECHA VERSION DESCRIPCION AUTOR CURSO: Análisis y Diseño de Sistemas

TABLA DE CONTENIDOS INTRODUCCION 1.1 Propósito 1.2 Alcance 1.3 Definiciones Acrónicos y Abreviaturas 1.4 Referencias 1.5 Descripción CASO DE USO DE NEGOCIO 2.1 Breve Descripción METAS METAS DE FUNCIONAMIENTO FLUJO DE TRABAJO 5.1 Flujo Básico 5.2 Flujo Alternativo 5.3 Pre-Condiciones 5.4 Post-Condiciones CATEGORIA RIESGOS POSIBILIDADES DUEÑOS DEL PROCESO REQUERIMIENTOS ESPECIALES PUNTOS DE EXTENSION CURSO: Análisis y Diseño de Sistemas

DIAGRAMA DE CASOS DE USO
Un caso de uso es un modelo de la interacción entre los usuarios externos de un SI (actores) y el sistema de información mismo. Un diagrama de casos de uso es un conjunto de casos de uso. Interacción entre Casos de Uso: Inclusión.- son incorporadas en otro CdU y pueden ser compartidas por varios CdU. No pueden ser ejecutados directamente por un actor. Regla para su aplicación: cuando se “usa siempre” Devolución a proveedor <<inclusión>> Actualizar Stock <<inclusión>> Actor Salidas a fábrica 31 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

INTERACCIÓN ENTRE CASOS DE USO: Extensión.- son transacciones relevantes que forman CdUs y que son diferentes secuencias o alternativas de un CdU. Si pueden ser ejecutados directamente por los actores. Regla para su aplicación: cuando se “usa a veces” La flecha siempre señala al CdU que está siendo incluido o extendido <<extensión>> Pagar en efectivo <<extensión>> Pagar cuotas Pagar con cheque Cliente <<extensión>> Pagar con tarjeta de crédito 32 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

SAR- Sistema de administración de requerimientos Ejemplos 33 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

DIAGRAMA DE ACTIVIDAD Un diagrama de actividad modela la secuencia de actividades que se desarrollan en el flujo de trabajo de un Caso de Uso. También podemos modelar el flujo de un objeto cuando pasa de un estado a otro en diferentes puntos de control del flujo. A diferencia de los diagramas de interacción que destaca el flujo de control entre objetos, un diagrama de actividad destaca el flujo de control entre actividades. Ejemplos 34 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

Un diagrama de actividad para una Cia. ensambladora de PCs Ejemplos 35 Ingeniería de Software - Ing. Eddye Arturo Sanchez Castillo

Análisis y Diseño de Sistemas
Ejercicio # 1 Análisis y Diseño de Sistemas

Solución Análisis y Diseño de Sistemas

Solución en Rational Rose
Clic aquí para Rational Rose 03 02 Clic a Todos los Programas 01 Clic al botón INICIO Análisis y Diseño de Sistemas

Comienza a cargar Rational Rose
Análisis y Diseño de Sistemas

Listo cargó Rational Rose
Bajar toda la Barra Análisis y Diseño de Sistemas

Selección de Rational Unified Process
02 Luego Clic en el botón OK Seleccione Aquí 01 Análisis y Diseño de Sistemas

Seleccionando MCUN Trabajar Aquí

Crear Paquete de Trabajo

Creación del Paquete Paquete Creado

Creación un Diagrama de Clase
Creando Diagrama de Clase

Diagrama de Clase Creado
Se ha credo el Diagrama de Clase Main

Listo para Crear Actores
1. Hacer Doble Clic Aquí 2. Aparecerá las siguientes Figuras

Actores de Negocios Creados
Creando el Actor Actores de Negocios Creados

Creando CUN CUN Creados

Creando Business Goal

Creando Diagrama CUN

MODELO DE ANÁLISIS DE NEGOCIO EN RATIONAL ROSE

Seleccionamos MAN Análisis y Diseño de Sistemas

Crear Nuevo Paquete Análisis y Diseño de Sistemas

Paquete: Trabajadores del Negocio

Crear Diagrama de Clase

Diagrama de Clase: Main

Trabajadores (Business Worker)

Crear Paquete y Diagrama de Clase

Entidades de Negocio Creadas

Realizaciones de Negocio(Crear paquete)

Realizaciones de Negocio Creadas

Realizaciones de Negocio Terminada

Realización de Caso de Negocio
TRABAJAR CON EL DIAGRAMA DE ACTIVIDAD CURSO: Análisis y Diseño de Sistemas

Diagrama de Actividad (D.A.)
CURSO: Análisis y Diseño de Sistemas

Crear el espacio para el DA
2. Dar Clic a Activity Diagram 1. Seleccionar NEW CURSO: Análisis y Diseño de Sistemas

3. Selecciónalo y da clic aquí
DA listo para trabajar 3. Selecciónalo y da clic aquí 1. DA creado 2. Para crear carriles CURSO: Análisis y Diseño de Sistemas

3. Dar Doble clic al Nombre
Carril Creado 3. Dar Doble clic al Nombre CURSO: Análisis y Diseño de Sistemas

2. Busca y Selecciona el nombre aquí
Poner Nombre al Carril 1. Borrar el nombre 2. Busca y Selecciona el nombre aquí 3. Apply luego OK CURSO: Análisis y Diseño de Sistemas

Carril con Nombre 3. Listo Carril Nombrado CURSO: Análisis y Diseño de Sistemas

todos los Carriles Creados
Listo Carriles Creados CURSO: Análisis y Diseño de Sistemas

Comienza a Crear el D.A. Dar clic aquí 1. Seleccione este botón CURSO: Análisis y Diseño de Sistemas

Creando el D.A. CURSO: Análisis y Diseño de Sistemas

Camino de todo la ruta CURSO: Análisis y Diseño de Sistemas

Barra de Sincronización

D.A. Completo CURSO: Análisis y Diseño de Sistemas

Poner Nombre a la Decisión
2. Aparece esta Ventana y Darle Clic a Detalle 1. Dar Doble Clic a la Flecha 3. Escribir el Texto CURSO: Análisis y Diseño de Sistemas

Listo, ahora agregar las Entidades

Listo, ahora agregar las Entidades
1. Dar Clic derecho a la Barra y luego al la opción Customize 2. Seleccionar el Botón necesario y clic a AGREGAR, para terminar clic a CERRAR CURSO: Análisis y Diseño de Sistemas

2. Dar Clic Aquí y aparecera esta figura
Como agregar Entidad 2. Dar Clic Aquí y aparecera esta figura 1. Seleccionar el Objeto

2. Arrástralo hasta el Objeto 1. Seleccionar la Entidad Pedido
Como agregar Entidad 2. Arrástralo hasta el Objeto 1. Seleccionar la Entidad Pedido

2. Arrástralo hasta el Objeto 1. Seleccionar la Entidad Pedido
Entidad Agregada 2. Arrástralo hasta el Objeto 1. Seleccionar la Entidad Pedido

Se agregó las Entidades al D.A.

Como Diferenciar las entidades iguales
1. Doble Clic a la Entidad CURSO: Análisis y Diseño de Sistemas

2. Escribir Completado 1. Seleccionar NEW 3. Dar Clic a OK CURSO: Análisis y Diseño de Sistemas

1. Escribir Completado 2. Dar Clic a OK CURSO: Análisis y Diseño de Sistemas

2. Escribir la letra C 2. Dar Clic a OK CURSO: Análisis y Diseño de Sistemas

La Entidad ya tiene diferencia CURSO: Análisis y Diseño de Sistemas

Diagrama de entidad (DA) Completado

Fin de la Presentación GRACIAS Análisis y Diseño de Sistemas

PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

Presentaciones similares

Presentación del tema: "PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback

Iniciar la sesión

Autorizarse a través de una red social:

PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE

Presentaciones similares

Presentación del tema: "PROCESO UNIFICADO DE DESARROLLO DE SOFTWARE"— Transcripción de la presentación:

Presentaciones similares

Sobre el proyecto

Feedback