Uml Proyect

Proyecto de desarrollo del Software Rational Unified Process
METODOLOGIA
RUP

(RATIONAL UNIFIED PROCESS)

Proyecto: __________________________________________

Sistema: ___________________________________________

Integrantes:

Jefe de Proyecto: ________________________________________

Colaboradores:
1- Colaborador1
2- Colaborador2
3- Colaborador.n


FASE
DE
INICIO

Consideraciones:
1- Aspectos generales de la organizacin
2- Plan de desarrollo de software
3- Modelo de Negocio
a- Unidad Organizacional
b- Paquete de Negocio
c- Diagrama de Paquete de Negocio
d- Diagrama de Caso de Uso de Negocio
e- Especificaciones de Caso de Uso de Negocio
f- Diagrama de Actividad de Negocio
g- Diagrama de Objetos de Negocio


PROYECTO DE DESARROLLO DE SOFTWARE
ASPECTOS ORGANIZACIONALES
1- Organizacin
1.1- Introduccin
1.2- Resea histrica
1.3- Ubicacin Geogrfica

2- Estructura Organizacional
2.1- Visin
2.2- Misin
2.3- Metas
2.4- Objetivo
- General
- Especficos
2.5- Organigrama
3- rea de Desarrollo
3.1- Descripcin del rea
3.2- Aspectos generales del rea
- Visin
- Misin
- Metas
3.3- Integrantes del rea
- Cargo
- Funciones
- Responsabilidades
3.4- Definicin y descripcin del problema
- Administrativo
- Organizacional
3.5- Recomendaciones
- Administrativo
- Organizacional
3.5- reas Involucradas
3.6- Formatos manuales


1- Organizacin
Una organizacin es un conjunto de elementos, compuesto principalmente por personas, que actan e
interactan entre s bajo una estructura pensada y diseada para que los recursos humanos, financieros,
fsicos, de informacin 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- Introduccin
Descripcin de la organizacin, rubro, direccin, etc...
1.2- Resea histrica
Origen, creacin y evolucin de la organizacin
1.3- Ubicacin Geogrfica (mapa)

2- Estructura Organizacional
2.1- Visin
Define y describe la situacin futura que desea tener la empresa, el propsito de la visin es
guiar, controlar y alentar a la organizacin en su conjunto para alcanzar el estado deseable de la
organizacin.

Ejemplo:

La Visin es ser un Grupo energtico y de servicios lder 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 ampliacin de oportunidades de
desarrollo profesional y personal a sus empleados y una contribucin positiva a la sociedad
actuando con un compromiso de ciudadana global.
2.2- Misin:
Define el negocio al que se dedica la organizacin, las necesidades que cubren con sus
productos y servicios, el mercado en el cual se desarrolla la empresa y la imagen pblica de
la empresa u organizacin.
Ejemplo:
La Misin del Grupo Gas Natural es atender las necesidades energticas 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 ms clsico de lo que es un objetivo y lo que es una meta, son las vueltas
ciclsticas como el Tour de Francia, la vuelta a Colombia o a Espaa. El objetivo es ganar el

ttulo o la vuelta. Las metas ser ganar cada una de las etapas. Aqu tambin podemos ver
que existen lo que llaman metas volantes y/o los premios de montaa.
2.5- Organigrama
El organigrama se define como la representacin grfica de la estructura orgnica de una
institucin o de una de sus reas y debe reflejar en forma esquemtica la descripcin de las
unidades que la integran, su respectiva relacin, niveles jerrquicos y canales formales de
comunicacin.

3- rea de Desarrollo
Establecer el rea de desarrollo (organigrama)
3.1- Descripcin del rea
Describir todas las actividades realizadas en el rea.
3.2- Aspectos generales del rea.
Visin, Misin y Metas
3.3- Integrantes del rea
Empleados que laboran en el rea, elaborar un cuadro donde se describa lo siguiente:

3.4- Definicin y descripcin del problema
Cuadro donde se menciona todos los problemas (administrativo y organizacional)
puntuales y una breve descripcin del mismo.

Integrante Cargo Funciones Responsabilidades

3.5- Recomendaciones

3.6- Areas Involucradas
Identificar las areas que estn relacionadas con el rea en estudio
3.7- Formatos Manuales
Insertar todos los formatos manuales existentes en el rea.

Problemas Descripcion
Problema1
Problema2
Problemas Descripcion
Problema1
Problema2
Administrativo
Organizacional
Recomendaciones Descripcion
Recomendacin 1
Recomendacin 2
Recomendaciones Descripcion
Recomendacin 1
Recomendacin 2
Administrativo
Organizacional

PLAN DE DESARROLLO DE SOFTWARE

1. Introduccin
2. Vista General del Proyecto
2.1 Propsito, Alcance y Objetivos
2.2 Suposiciones y Restricciones
2.3 Entregables del proyecto
2.4 Evolucin del Plan de Desarrollo del Software
3. Organizacin del Proyecto
3.1 Participantes en el Proyecto
3.3 Roles y Responsabilidades
4. Gestin del Proceso
4.1 Tecnologia de Informacion
4.1..1 Evaluacion Tecnologica
4.1.2 Recomendaciones
4.2 Plan del Proyecto
4.2.1 Plan de las Fases
4.2.2 Calendario del Proyecto


Plan de Desarrollo del Software
1. Introduccin
La introduccin es una breve descripcin de de las razones por las cuales se lleva a cabo este
proyecto de desarrollo, tambin una breve descripcin de la metodologa a implementar.
La introduccin del plan de desarrollo del software debe dar una visin del documento completo.
Debe incluir el propsito, alcance, definiciones, acrnimos, abreviaturas y referencias de este plan
Ejemplo1:
Este Plan de Desarrollo del Software es una versin preliminar preparada para ser incluida en la
propuesta elaborada como respuesta al proyecto de prcticas de la asignatura de Laboratorio de
Sistemas de Informacin de la Facultad de Informtica de la Universidad Catlica. Este documento
provee una visin global del enfoque de desarrollo propuesto.
El proyecto ha sido ofertado por Patricio Orlando Letelier Torres basado en una metodologa de
Rational Unified Process en la que nicamente se proceder a cumplir con las tres primeras fases que
marca la metodologa, constando nicamente en la tercera fase de dos iteraciones. Es importante
destacar esto puesto que utilizaremos la terminologa RUP en este documento. Se incluir el detalle
para las fases de Inicio y Elaboracin y adicionalmente se esbozarn las fases posteriores de
Construccin y Transicin para dar una visin global de todo proceso.
El enfoque desarrollo propuesto constituye una configuracin del proceso RUP de acuerdo a las
caractersticas del proyecto, seleccionando los roles de los participantes, las actividades a realizar y
los artefactos (entregables) que sern generados. Este documento es a su vez uno de los artefactos de
RUP.
2. Vista General del Proyecto
2.1 Propsito, Alcance y Objetivos
Propsito: el propsito define lo que se espera lograr a travs del proyecto mismo. Este debe incluir
referencias sobre la duracin, el lugar, la cantidad, la calidad y los beneficiarios.
Un propsito adecuadamente definido constituye la clave para el xito del proyecto. La definicin de
otros elementos del proyecto fluye del propsito.
Ejemplo:
- Evaluar la efectividad de las tcnicas de captura de requisitos, en pequeas empresas de
desarrollo de software.
- Desarrollar y evaluar un interfaz de usuario para paquetes estadsticos.
- Producir y evaluar lenguajes de cuarta generacin para el desarrollo de bases de datos.

Objetivo:
Los objetivos representan los logros significativos en el camino hacia el propsito final del proyecto.
Ejemplo:
- Definir las pautas, controles y procedimientos que debe reunir el marco para la administracin
de proyectos relacionados al desarrollo de sistemas de informacin.
- Documentar las diferentes tcnicas actuales para la prediccin de las variaciones de los ndices
de Bolsa;
- Desarrollar un modelo apropiado con una red neuronal artificial:
- Reunir datos para el anlisis y la evaluacin;

- Evaluar el modelo utilizando las tcnicas estadsticas adecuadas;
- Redactar un informe final.
Alcance: Definir lmites 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 informticos y los sitios donde se realicen proyectos de desarrollos
o adquisicin de sistemas de informacin en el Estado Provincial, comprendidos en el Decreto
Acuerdo 462/96.
2.2 Suposiciones y Restricciones
Los supuestos o factores exgenos 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 contribucin 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 ms tiempo
y disponibilidad en la venta y alquiler de estos.
Estar a corde con el desarrollo tecnolgico puesto que sera el primer sistema que
tendra 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
programacin asp.net).

2.3 Entregables del proyecto

Definicin:
Dado que el objetivo final del proyecto es la entrega de un subsistema informtico (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 ejecucin del proyecto informtico".
Los entregables los clasificamos como relativos al objetivo y relativos a la gestin del proyecto. Son
entregables relativos al objetivo todos aquellos documentos que hacen referencia exclusivamente al
sistema de informacin y al subsistema informtico en desarrollo. Pertenecen a este conjunto los
requisitos del sistema, la especificacin del sistema, la documentacin del diseo, l cdigo fuente,
los programas ejecutables, los manuales de usuario, etc. Los entregables relativos a la gestin del
proyecto hacen referencia a aquellos documentos que se refieren a la situacin 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 planificacin del proyecto, los

presupuestos, los documentos de control de la planificacin o de la calidad, los estudios de riesgos
durante el desarrollo, etc.
A continuacin se indican y describen cada uno de los artefactos que sern generados y utilizados
por el proyecto y que constituyen los entregables. Esta lista constituye la configuracin de RUP
desde la perspectiva de artefactos, y que proponemos para este proyecto.
Es preciso destacar que de acuerdo a la filosofa 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,
slo al trmino del proceso podramos tener una versin definitiva y completa de cada uno de ellos.
Sin embargo, el resultado de cada iteracin y los hitos del proyecto estn enfocados a conseguir un
cierto grado de completitud y estabilidad de los artefactos. Esto ser indicado ms adelante cuando
se presenten los objetivos de cada iteracin.
1) Plan de Desarrollo del Software
Es el presente documento.
2) Modelo de Casos de Uso del Negocio
Es un modelo de las funciones de negocio vistas desde la perspectiva de los actores externos
(Agentes de registro, solicitantes finales, otros sistemas etc.). Permite situar al sistema en el contexto
organizacional haciendo nfasis en los objetivos en este mbito. Este modelo se representa con un
Diagrama de Casos de Uso usando estereotipos especficos para este modelo.
3) Modelo de Objetos del Negocio
Es un modelo que describe la realizacin de cada caso de uso del negocio, estableciendo los
actores internos, la informacin que en trminos generales manipulan y los flujos de trabajo
asociados al caso de uso del negocio. Para la representacin de este modelo se utilizan
Diagramas de Colaboracin (para mostrar actores externos, internos y las entidades
(informacin) que manipulan, un Diagrama de Clases para mostrar grficamente las entidades
del sistema y sus relaciones, y Diagramas de Actividad para mostrar los flujos de trabajo.
4) Modelo de Casos de Uso
El modelo de Casos de Uso presenta las funciones del sistema y los actores que hacen uso de
ellas. Se representa mediante Diagramas de Casos de Uso.
5) Especificaciones de Casos de Uso
Para los casos de uso que lo requieran (cuya funcionalidad no sea evidente o que no baste con
una simple descripcin narrativa) se realiza una descripcin detallada utilizando una plantilla de
documento, donde se incluyen: precondiciones, post-condiciones, flujo de eventos, requisitos
no-funcionales asociados. Tambin, para casos de uso cuyo flujo de eventos sea complejo podr
adjuntarse una representacin grfica mediante un Diagrama de Actividad.

6) Prototipos de Interfaces de Usuario
Se trata de prototipos que permiten al usuario hacerse una idea ms o menos precisa de las
interfaces que proveer el sistema y as, conseguir retroalimentacin de su parte respecto a los
requisitos del sistema. Estos prototipos se realizarn como: dibujos a mano en papel, dibujos con
alguna herramienta grfica o prototipos ejecutables interactivos, siguiendo ese orden de acuerdo
al avance del proyecto. Slo los de este ltimo tipo sern entregados al final de la fase de
Elaboracin, los otros sern desechados. Asimismo, este artefacto, ser desechado en la fase de

Construccin en la medida que el resultado de las iteraciones vayan desarrollando el producto
final.
7) Modelo de Anlisis y Diseo
Este modelo establece la realizacin de los casos de uso en clases y pasando desde una
representacin en trminos de anlisis (sin incluir aspectos de implementacin) hacia una de
diseo (incluyendo una orientacin hacia el entorno de implementacin), de acuerdo al avance
del proyecto.
8) Modelo de Datos
Previendo que la persistencia de la informacin del sistema ser soportada por una base de datos
relacional, este modelo describe la representacin lgica 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 representacin de tablas, claves, etc.).
9) Lista de Riesgos
Este documento incluye una lista de los riesgos conocidos y vigentes en el proyecto, ordenados
en orden decreciente de importancia y con acciones especficas de contingencia o para su
mitigacin.
Ejemplo:
La gestin de un proyecto de software exitoso requiere entender qu puede salir mal. A continuacin
se indican 10 seales 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 ms definido

3. Los cambios se gestionan mal

4. La tecnologa elegida cambia

5. Las necesidades comerciales cambian

6. Los plazos de entrega no son realistas

7. Los usuarios se resisten

8. Se pierde el patrocinio

9. El equipo de proyecto carece de personal con las habilidades apropiadas

10. Los gestores evitan las mejores prcticas y las lecciones aprendidas


Clientes y
Usuarios
Desarrolladores
software objetivo Maquina
2.4 Evolucin del Plan de Desarrollo del Software
El Plan de Desarrollo del Software se revisar semanalmente y se refinar antes del comienzo de
cada iteracin.

3. Organizacin del Proyecto
Describe la arquitectura organizacional del equipo de desarrollo.
En la planificacin se fracciona las actividades de modo que resulte fcil la realizacin y control de
cada tarea.
Hay que crear las condiciones que:
faciliten la coordinacin: puesta en marcha, toma de decisiones, seguimiento y
finalizacin 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 continuacin se describen las principales responsabilidades de cada uno de los puestos en el
equipo de desarrollo durante las fases de Inicio y Elaboracin, de acuerdo con los roles que
desempean 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
tambin establece un conjunto de prcticas que aseguran la
integridad y calidad de los artefactos del proyecto. Adems, el jefe de
proyecto se encargar de supervisar el establecimiento de la
arquitectura del sistema. Gestin de riesgos. Planificacin y control

del proyecto.
Analista de Sistemas
Captura, especificacin y validacin de requisitos, interactuando con
el cliente y los usuarios mediante entrevistas. Elaboracin del
Modelo de Anlisis y Diseo. Colaboracin en la elaboracin de las
pruebas funcionales y el modelo de datos.
Programador
Construccin de prototipos. Colaboracin en la elaboracin de las
pruebas funcionales, modelo de datos y en las validaciones con el
usuario
Ingeniero de Software
Gestin de requisitos, gestin de configuracin y cambios,
elaboracin del modelo de datos, preparacin de las pruebas
funcionales, elaboracin de la documentacin. Elaborar modelos de
implementacin y despliegue.
4. Gestin del Proceso
La Gestin de Proyectos tiene como finalidad principal la planificacin, el seguimiento y control de
las actividades y de los recursos humanos y materiales que intervienen en el desarrollo de un Sistema
de Informacin. Como consecuencia de este control es posible conocer en todo momento qu
problemas se producen y resolverlos o paliarlos de manera inmediata.
4.1 Tecnologa de Informacin
- Evaluacin Tecnolgica
- Recomendaciones
4.2 Plan del Proyecto
En esta seccin se presenta la organizacin 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 ms iteraciones en cada una de ellas. La
siguiente tabla muestra una la distribucin de tiempos y el nmero de iteraciones de cada fase (para
las fases de Construccin y Transicin es slo una aproximacin muy preliminar)
Fase Nro. Iteraciones Duracin
Fase de Inicio 1 17-set-30
Fase de Elaboracin 1 1-oct-11-nov
Fase de Construccin 1 12-nov-24-dic
Fase de Transicin 1 25-dic-5feb


Como se ha comentado, el proceso iterativo e incremental de RUP est caracterizado por la
realizacin en paralelo de todas las disciplinas de desarrollo a lo largo del proyecto, con lo cual la
mayora de los artefactos son generados muy tempranamente en el proyecto pero van desarrollndose
en mayor o menor grado de a la fase e iteracin 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.
Descripcin Hito
Fase de Inicio En esta fase desarrollarn los requisitos del producto desde la
perspectiva del usuario, los cuales sern establecidos en el artefacto
Visin. Los principales casos de uso sern identificados y se har un
refinamiento del Plan de Desarrollo del Proyecto. La aceptacin del
cliente /usuario del artefacto Visin y el Plan de Desarrollo marcan el
final de esta fase.
Fase de
Elaboracin
En esta fase se analizan los requisitos y se desarrolla un prototipo de
arquitectura (incluyendo las partes ms relevantes y / o crticas del
sistema). Al final de esta fase, todos los casos de uso correspondientes
a requisitos que sern implementados en la primera release de la fase
de Construccin deben estar analizados y diseados (en el Modelo de
Anlisis / Diseo). La revisin y aceptacin del prototipo de la
arquitectura del sistema marca el final de esta fase. En nuestro caso
particular, por no incluirse las fases siguientes, la revisin y entrega de
todos los artefactos hasta este punto de desarrollo tambin se incluye
como hito. La primera iteracin tendr como objetivo la identificacin
y especificacin de los principales casos de uso, as como su
realizacin preliminar en el Modelo de Anlisis / Diseo, tambin
permitir hacer una revisin general del estado de los artefactos hasta
este punto y ajustar si es necesario la planificacin para asegurar el
cumplimiento de los objetivos. Ambas iteraciones tendrn una

duracin de una semana.
Fase de
Construccin
Durante la fase de construccin se terminan de analizar y disear
todos los casos de uso, refinando el Modelo de Anlisis / Diseo. 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 elaboracin de material de apoyo
al usuario. El hito que marca el fin de esta fase es la versin de la
release 2.0, con la capacidad operacional parcial del producto que
se haya considerado como crtica, lista para ser entregada a los
usuarios para pruebas beta.
Fase de
Transicin
En esta fase se prepararn dos releases para distribucin,
asegurando una implantacin 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
documentacin del proyecto con los manuales de instalacin y todo
el material de apoyo al usuario, la finalizacin del entrenamiento de
los usuarios y el empaquetamiento del producto.

4.2.2 Calendario del Proyecto
A continuacin se presenta un calendario de las principales tareas del proyecto incluyendo slo las
fases de Inicio y Elaboracin. Como se ha comentado, el proceso iterativo e incremental de RUP est
caracterizado por la realizacin en paralelo de todas las disciplinas de desarrollo a lo largo del
proyecto, con lo cual la mayora de los artefactos son generados muy tempranamente en el proyecto
pero van desarrollndose en mayor o menor grado de acuerdo a la fase e iteracin 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 aprobacin indica cundo el
artefacto en cuestin tiene un estado de completitud suficiente para someterse a revisin y probacin,
pero esto no quita la posibilidad de su posterior refinamiento y cambios.
Calendario Fase de Inicio


Calendario Fase de Elaboracin
Fase de Construccin

Fase de Transicin


MODELO DE NEGOCIO
1. CONCEPTO:
Un modelo del negocio es una abstraccin de cmo funciona la organizacin.
Provee una vista simplificada de la estructura y comportamiento del negocio que actuar como la
base de comunicacin, mejora o innovacin del negocio, as como tambin para definir los requisitos
de los diferentes sistemas de software que pueden soportar al negocio.
El Modelo de negocio es un modelo que refleja grficamente las metas y funciones que persigue el
negocio. Se usa como una entrada esencial para identificar roles y entregables en la organizacin.
As, los objetivos de la etapa de modelado del negocio son los siguientes:
Entender los problemas actuales en la organizacin o empresa para identificar los aspectos a mejorar.
Comprender la estructura y el dinamismo de la organizacin 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 visin
comn de la organizacin considerada.
Obtener los requisitos del sistema software.
Entender como el sistema software encaja en la organizacin.
Entender los mecanismos del negocio actual

Unidad Organizacional Libreria Juanito S.A
Evaluar los procesos actuales
Formar una base para mejorar/innovar el negocio actual
Formar una base para un sistema de informacin que apoya al negocio permitiendo definir los
requisitos funcionales y no funcionales de un futuro sistema informtico.
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.
Anlisis del Negocio.
Identificar Procesos de Negocio.
Definir y Refinar los Procesos de Negocio.
Diseo de la Realizacin de los Procesos de Negocio.
Evaluacin.
Los productos de desarrollo del software fundamentales que se desarrollan en la etapa de Modelado del
Negocio son:
Especificacin del Negocio, que incluye Visin del Negocio y Glosario de Trminos.
Modelo de Casos de Uso del Negocio, que incluye Especificacin de Casos de Uso, Descripcin 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 Realizacin de los
Casos de Uso.
Informe de Evaluacin.
Documento de Arquitectura del Negocio.

El Modelo de Caso de Uso de negocio es usado por:

Los stakeholders, los analistas y los diseadores de procesos de negocio, para entender y mejorar la
manera cmo 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 Organizacional
b- Paquete de Negocio
c- Diagrama de Paquete de Negocio
d- Diagrama de Caso de Uso de Negocio
e- Especificaciones de Caso de Uso
f- Diagrama de Actividad de Negocio
g- Diagrama de Objetos de Negocio
Unidad Organizacional
La unidad Organizacional es un contenedor de objetos de negocio, representa la organizacin


Paquete de Negocio
Ventas
Compras
Almacen

Paquete de Negocio

Representa las reas de la organizacin.

Diagrama de Paquete de Negocio
- Representa la interrelacin de las reas con el rea en desarrollo
- Muestra la dependencia de las reas

Ventas
Compras
Almacen
DIAGRAMA DEPAQUETEDENEGOCIO
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 organizacin.
Modela lo qu hace una compaa, quin est dentro y quin est fuera de la compaa.
Da el alcance de la organizacin, visualizando lo que abarca y cules son sus fronteras.

Elementos:
1. Actores: Agente que interacta con determinado proceso de negocio.

- Actor de Negocio: Un actor del negocio, es cualquier persona o cualquier cosa
externa a la organizacin pero que obra recprocamente con ella.
Por ejemplo, para su organizacin serian los clientes, sus acreedores, sus
inversionistas, o sus proveedores. Cada uno de estos actores tiene un inters 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 compaa

- Trabajador de Negocio:
Un trabajador de negocios es un rol dentro de la organizacin. Importante, los
trabajadores del negocio son roles no posiciones. Una persona puede tener
varios roles, pero una sola posicin. 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:
Vendedor

- 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 trminos, los casos del uso de negocio le dicen al lector lo que la
organizacin hace para proporcionarle el valor de negocio que los individuos
que interactan con l esperan.
- El conjunto de los casos del uso de negocio para una organizacin 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
especficamente qu va a suceder dentro del caso del uso.
- El flujo de trabajo se puede documentar de dos formas. La ms simple es crear una lista
numerada, paso a paso de qu sucede mientras que progresa el caso del uso.
- La problemtica con la forma simple de escribir el flujo de trabajo, se presenta cuando
existe una gran cantidad de condiciones lgicas, lo que provoca poca claridad.
- Para solucionar este problema se pueden utilizar los Diagramas de Actividad, que nos
permiten mostrar de forma grafica los flujos de trabajo, la secuencia de los pasos y quien es
responsable de realizar cada paso.
- A cada caso de uso del negocio se le debe asociar una documentacin que sigue el siguiente
formato.

4. Relaciones entre Actores: Generalizacin
- Es una relacin entre actores de negocio que muestra que
cuando un actor especfico (el descendiente) est
presente, todas las caractersticas (atributos, operaciones y
asociaciones) que son descritas para el actor genrico
(el ascendente) del cul hereda, van a estar presentes.
- Una generalizacin 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 relacin de generalizacin se muestra de la
siguiente manera:

Persona
Natural Juridico

5. Relaciones entre Casos de Uso y Actores: Asociacin Unidireccional
- Una lnea de un actor de negocio a un caso del uso de negocio indica que el actor activa el
caso de uso.
- En UML, la relacin de asociacin se muestra de la siguiente manera:

6. Relaciones entre Casos de Uso de Negocio:
- Include (Inclusin): una instancia del Caso de Uso origen incluye tambin el
comportamiento descrito por el Caso de Uso destino, en un caso de uso incluido no
interviene un determinado actor.

-

Ejemplo:

Cl iente
Sol ici tar Credito
Vendedor
Evaluar Credi to
Caso de Uso Ori gen
Caso de Uso Destino
<<incl ude>>
Anali zar Ri esgo Anali zar Documentos
Credi to
Evaluar Credi to
<<incl ude>>
<<incl ude>>

- Extend (extensin): 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:

Ejercicio 1: Sociedad de amigos del libro
La sociedad de amigos del libro se dedica a la venta de libros a sus socios a travs del telfono. Esta sociedad
acta como intermediario entre las editoriales y sus socios, proporcionndoles los libros que estos solicitan a
Caso de Uso Ori gen Caso de Uso destino
<<extend>>
Sol ici tar Nueva Tarjeta
Cl iente
Sol ici tar Prestamo
[tarj eta caducada]
<<extend>>

precios reducidos. La empresa est estructurada en varios departamentos, uno de los cuales se encarga de los
pedidos, almacn y el de contabilidad.
Los socios pueden realizar sus pedidos por telfono al departamento de pedidos. En la peticin se especifican
los siguientes datos: nombre del socio y el nmero de ejemplares solicitados por ttulo. Previamente a la
aceptacin 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 situacin 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 ttulos solicitados y el nmero total de ejemplares de cada ttulo). Cuando
se reciben los libros, el departamento de almacn verifica el estado del producto, si existe alguna anomala
con el libro, este es devuelto a la editorial y esta correcto se procede a la distribucin en los anaqueles, el
departamento de almacn entrega los documentos (gua 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 caractersticas de los productos requeridos.
2. La orden de pedido es pasada al asistente de ventas, quin se encargar de llevarla al jefe de
produccin en el rea de produccin para su anlisis.
3. El pedido es revisado por el jefe de produccin para que analice la factibilidad de fabricar los
productos con las caractersticas requeridas.
4. La factibilidad se basa primero en si antes se ha fabricado un producto con similares caractersticas,
en caso contrario se analiza la dificultad del producto para aceptar o negar el pedido.
5. En caso de ser factible la fabricacin del producto, el jefe de produccin emite una lista de la materia
prima necesaria, esta lista se le enva al operario de almacn para que revise el stock y d un
estimado de tiempo en que la materia prima estara disponible para su utilizacin, mientras que el
jefe de produccin va calculando el tiempo que se tomara para la fabricacin.
6. En caso de que se pueda fabricar el producto, la informacin que emita el operario es necesaria para
generar el informe de evaluacin.

7. Luego, el jefe de produccin especfica su respuesta en un informe de evaluacin que contiene el
costo y la fecha de produccin; este documento se enva al asesor de ventas a travs de su asistente;
en caso de ser una respuesta afirmativa, tambin se genera una orden de produccin.
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 representacin 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 realizacin del caso del uso del negocio ordenar la tareas o las
actividades que logran una o ms metas de negocio, que satisfacen la iteracin entre los Actores
externos del negocio y los trabajadores internos del negocio.
Se usa separadores de Lnea para representar principalmente trabajadores del negocio, y de cmo
estos realizan el negocio
los flujos del objeto se utilizan para demostrar cmo 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 crculo de color negro slido.

2- Actividad de Negocio: Una actividad representa la accin que ser realizada por un caso de
uso de negocio la cual es representada dentro de un ovalo.

3- Transicin: Una transicin ocurre cuando se lleva a cabo el cambio de una actividad a otra,
la transicin es representada simplemente por una lnea con una flecha en su terminacin para indicar

direccin.

4- Bifurcacin (decisin): Una ramificacin ocurre cuando existe la posibilidad que ocurra ms de
una transicin (resultado) al terminar determinada actividad. Este elemento es representado a
travs de un rombo.

5- Barra de Sincronizacin: Representa actividades paralelas.

6- Fin: El fin de un diagrama de actividad es representado por un crculo, con otro crculo concntrico
de color negro slido.

7- Canales (Swimlines): En determinadas ocasiones ocurre que un diagrama de actividad se expanda a
lo largo de ms 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 mximo 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 compaa area
correspondiente con su DNI. La secretaria de ventas de viajes de la compaa, se encarga de
recibir la documentacin 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 compaa). 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 secretara 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 operacin. Si el cliente acepta, deber suministrar sus datos de tarjeta de crdito
o bien pagar en efectivo. En el caso de que el cliente pague con tarjera, la secretaria deber
verificar la disponibilidad del crdito para ese cliente comunicndose con el Centro
Internacional de Crdito (C.I.C.) quin ser el que confirmar si el cliente cuenta con el
crdito correspondiente para abonar el viaje.
3. Un paciente es atendido en un Consultorio Odontolgico. El paciente ingresa al consultorio,
la secretaria verifica si el paciente tiene un turno otorgado, y slo en ese caso el mismo ser
atendido. Si el paciente posee una mutual por la cual atiende el odontlogo, entrega la orden
correspondiente a la Secretara. 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 odontlogo, la secretaria realiza una
historia clnica tomando sus datos personales, y luego se la entrega al odontlogo.
Una vez atendido, el odontlogo registra los datos de la consulta en la historia clnica del
paciente. En caso que sea necesario, finalizada la consulta, el odontlogo se comunica con
la secretaria para acordar un nuevo turno para el paciente.

4. Elaborar el diagrama de actividad :
El cliente enva 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 peticin de un cliente que realiz su pedido por telfono o lo envi
por fax o correo ordinario al depto. comercial de la empresa.
- El empleado revisa el pedido (completndolo, si es necesario), y comienza su
procesamiento envindolo al jefe tcnico, que est encargado de su anlisis.
- El jefe tcnico analiza la viabilidad de cada producto del pedido por separado:
Si el producto pedido est en el catlogo, su fabricacin es aceptada.
En caso contrario, es considerado un producto especial, y el jefe tcnico estudia su
produccin:
- Si es viable, la fabricacin del producto especial es aceptada;
- Si no es viable, el producto especial no ser fabricado.
Una vez estudiado el pedido completo, el jefe tcnico...
Informa al departamento comercial de la aceptacin 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 fabricacin (la estndar si el producto estaba
catalogado, o una nueva, especficamente diseada para el producto, si ste no estaba en el

catlogo). Cada orden de trabajo es enviada al jefe de produccin, y queda pendiente de su
lanzamiento.
El comercial comunica al cliente el resultado final del anlisis de su pedido.


MODELO DE ANALISIS DE NEGOCIO
El modelo del anlisis de negocio describe la realizacin de los casos del uso del negocio en funcin a la
interaccin entre los trabajadores del negocio y las entidades de negocio.
Sirve como abstraccin de cmo los trabajadores del negocio y las entidades de negocio necesitan ser
relacionados y de cmo necesitan colaborar para realizar los casos del uso del negocio.
El propsito del modelo del anlisis de negocio es describir cmo 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 asuncin sobre la estructura del negocio.
El modelo del anlisis de negocio, define los trabajadores internos del negocio y la informacin que utilizan
(las entidades de negocio), describen su organizacin estructural en las unidades independientes (sistemas del
negocio), y definen cmo obran recprocamente 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
diseadores del negocio son responsables de detallar elementos dentro del modelo.
El modelo tambin es utilizado por los analistas de sistemas para derivar requisitos del software, basados en
cmo 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 organizacin y para
identificar clases en modelos del anlisis y del diseo 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 Negocio
5- Diagrama de Objetos de Negocio: Representa las responsabilidades de los trabajadores de negocio
con respecto a las entidades de negocio y las relaciones entre las mismas entidades de negocio.
6- Diagrama de colaboracion de negocio


Ejemplo de daigrama de objetos de negocio:


FASE
DE
ELABORACION

1- Diagrama de Paquete de Sistema
2- Modelo de Caso de Uso (Modelo de Requisitos)
a- Diagrama de caso de uso
b- Diagrama de Actividad
c- Especificaciones de caso de uso
3- Prototipos (interfaz de usuario)


1- DIAGRAMA DE PAQUETE DE SISTEMA
En el Lenguaje Unificado de Modelado, un diagrama de paquetes muestra como un sistema est dividido en
agrupaciones lgicas mostrando las dependencias entre esas agrupaciones. Dado que normalmente un paquete
est pensado como un directorio, los diagramas de paquetes suministran una descomposicin de la jerarqua
lgica de un sistema.
Los Paquetes estn normalmente organizados para maximizar la coherencia interna dentro de cada paquete y
minimizar el acoplamiento externo entre los paquetes. Con estas lneas maestras sobre la mesa, los paquetes
son buenos elementos de gestin. 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 aplicacin o sistema y
cmo se relaciona con su entorno
(usuarios u otras aplicaciones).
El diagrama de casos de uso
representa la forma en cmo un
Cliente (Actor) opera con el sistema
en desarrollo, adems de la forma, tipo
y orden en como los elementos
interactan (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 representacin de una unidad discreta de trabajo realizada por un usuario usando el
sistema en operacin. Se ejecuta en su totalidad o no se ejecuta nada, devolviendo algo de valor al
usuario.
Es una operacin/tarea especfica que se realiza tras una orden de algn agente interno, sea desde una
peticin de un actor o bien desde la invocacin desde otro caso de uso.

Actor: Una definicin 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 ms bien la labor que realiza frente al sistema.
Relacin: Comunicacin (relacin entre un actor y un caso de uso con el que interacta; se representa
simplemente con una lnea). Relacion entre casos de uso : Include y Extend

b- Diagrama de actividad de sistema
El diagrama de actividad muestra el orden en el que
se van realizando tareas dentro de un sistema.
Los diagramas de actividad describen la secuencia
de las actividades en un sistema.
Elementos:
1- Inicio: El inicio de un diagrama de actividad es representado por un crculo de color negro slido.

2- Actividad de Sistema: Una actividad representa la accin que ser realizada por un caso de uso
de negocio la cual es representada dentro de un ovalo.

3- Transicin: Una transicin ocurre cuando se lleva a cabo el cambio de una actividad a otra, la
transicin es representada simplemente por una lnea con una flecha en su terminacin para indicar
direccin.

4- Bifurcacin (decisin): Una ramificacin ocurre cuando existe la posibilidad que ocurra ms de una
transicin (resultado) al terminar determinada actividad. Este elemento es representado a travs de
un rombo.

actividad

5- Barra de Sincronizacin: Representa actividades paralelas.

6- Fin: El fin de un diagrama de actividad es representado por un crculo, con otro crculo concntrico
de color negro slido.

7- Canales (Swimlines): En determinadas ocasiones ocurre que un diagrama de actividad se expanda a
lo largo de ms de un entidad o actor, cuando esto ocurre el diagrama de actividad es particionada en
canales (swimlines), donde cada canal representa la entidad o actor que est llevando a cabo la
actividad.

c- Especificaciones de Caso de Uso: cuenta con el siguiente formato.

1- Nombre del Caso de Uso
1.1- Descripcion
2- Flujo de Eventos
2.1- Flujo Basico
2.2- Flujos Alternativos
2.2.1- Flujo alternativo
2.2.2- Otro flujo alternativo
3- Precondiciones
3.1- Una Precondicion
3.2- Otra precondicion
4- Poscondiciones
4.1- Una poscondicion
4.2- Otra poscondicion
Ejemplo de especificaciones de caso de uso:
Especificacin de Caso de Uso
1- Registrar Producto
1.1 Breve Descripcin
Permite al jefe de almacn tener una gestin de productos para luego poder adminstralos en el
funcionamiento de nuestro sistema, el jefe de almacn podr crear, editar y eliminar producto(s)
segn sea el criterio de la empresa.
2- Flujo de Eventos
2.1 Flujo Bsico
El sistema muestra la interfaz Gestionar Producto con los criterios de bsqueda que son los
campos: cdigo, modelo, marca, nombre producto, categora adems de las opciones buscar, editar,
nuevo, eliminar.
2.1.1- Crear Producto
1. El caso de uso comienza cuando el Jefe de Almacn solicita Nuevo en la interfaz Gestin
Productos.
2. El sistema muestra la interfaz Crear Producto.
3. El Jefe de Almacn selecciona Categora (partes y piezas, perifricos y accesorios y suministros)

4. El sistema retorna lista de tipo de Producto en base a la categora.
5. El jefe de Almacn selecciona Tipo de Producto (segn la categora).
6. El sistema retorna lista de marcas en base al Tipo de producto.
7. El jefe de almacn selecciona marca.
8. El jefe de Almacn ingresa Modelo.
9. El jefe de Almacn Ingresa Una breve descripcin.
10. El jefe de Almacn elige la opcin de Grabar para guardar el nuevo Producto Creado.
11. El Sistema Guarda registro nuevo del producto ingresado.
12. El Sistema genera mensaje de confirmacin de creacin de producto.
13. El sistema regresa a la interfaz de Gestin de Producto.
2.1.2- Editar Producto
1. El jefe de almacn ingresa el criterio de bsqueda del producto en la interfaz Gestin de
Productos.
2. El jefe de almacn selecciona el botn 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 Gestin Producto
5. El jefe de almacn presiona editar en el producto que desea modificar.
6. El sistema muestra la interfaz Editar producto
7. El jefe de almacn modifica los datos del producto segn criterio
8. El jefe de Almacn selecciona grabar
9. El sistema guarda los datos modificados y genera un mensaje Actualizacin Completada
10. El Jefe de almacn presiona Aceptar
11. El Sistema regresa a la interfaz Gestin de Productos.
2.1.3- Eliminar Producto
1. El jefe de almacn ingresa el criterio de bsqueda del producto en la interfaz de Gestin de
productos.
2. El jefe de almacn 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 Gestin Producto
5. El Jefe de almacn selecciona el producto(s) que desea eliminar presionando en el checkbox
correspondiente.
6. El Jefe de almacn presiona el botn Eliminar
7. El sistema muestra mensaje Seguro que desea eliminar el producto(s) seleccionado(s) de la lista

8. El jefe de Almacn confirma presionando el botn 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 bsqueda>
Si en editar producto y eliminar producto el jefe de almacn presionar buscar sin ingresar un criterio
de bsqueda, 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 Almacn 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
Especificacin de Caso de Uso
1- Gestin de Clientes
1.1- Descripcin
Este caso de uso resume la utilidad de alta, baja y modificacin 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
estn asociados a los mismos, y el alta asociar automticamente al cliente con dicho representante.
Los clientes on-line solo podrn 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 Bsico
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, Pas, Provincia, Localidad, Direccin, Cdigo Postal, Telfono, E-mail y Cuenta Bancaria.
2.2. El Usuario de Ventas pulsa el botn 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 botn borrar de su interfaz grfica.
3.5. El sistema genera un mensaje de aviso de borrado y solicita la confirmacin de la eliminacin.
3.6. El Usuario de Ventas puede confirmar la eliminacin del cliente pulsando el botn Aceptar, o bien
puede cancelar el borrado pulsando el botn Cancelar. Pasar al punto 5.
4. El Usuario de Ventas solicita la modificacin de datos de un cliente.
4.1. El sistema muestra el campo DNI/CIF a introducir necesario para la modificacin. El sistema
muestra los datos del cliente que se ha solicitado para la modificacin.
4.2. El Usuario de Ventas puede modificar cualquiera de los datos de los campos mostrados por el
sistema, stos son: DNI/CIF, Nombre, Pas, Provincia, Localidad, Direccin, Cdigo Postal,
Telfono, E-mail y Cuenta Bancaria.
4.3. El Usuario de Ventas puede solicitar guardar los datos modificados pulsando el botn Modificar de
la interfaz grfica.
4.4. El sistema genera un mensaje de aviso de modificacin y solicita la confirmacin de la misma.
4.5. El Usuario de Ventas puede confirmar la modificacin del cliente pulsando el botn Aceptar, o bien
puede cancelar el borrado pulsando el botn 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 ningn 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, Pas, Provincia, Localidad, Direccin,
Cdigo Postal, Telfono y Cuenta Bancaria, el sistema generar un mensaje de error
3- PROTOTIPO O INTERFAZ DE USUARIO
Esta es una de las partes ms importantes de cualquier programa ya que determina que tan fcilmente 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 elaboracin de una interfaz de usuario, bien diseada, exige una gran dedicacin pues generalmente
las interfaces son grandes, complejas y difciles de implementar, depurar y modificar. Hoy en da las
interfaces de manipulacin directa (tambin llamadas interfaces grficas de usuario, GUI por sus siglas
en ingls) son prcticamente universales. Las interfaces que utilizan ventanas, conos men se han
convertido en estndar en los materiales computacionales.
Ejemplo de interfaz de usuario:


Hotel
El dueo 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 espordicos. Una reserva almacena datos del cliente, de la habitacin reservada, la fecha de
comienzo y el nmero de das que ser ocupada la habitacin.
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 habitacin 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 nmero de reserva, tipo de
habitacin y nmero de noches.
Dibujar en pantalla la foto de una habitacin de acuerdo a su tipo.
Reservar una habitacin especificando el nmero de la pieza, reserva y nombre del cliente.
Eliminar una reserva especificando el nmero de la habitacin.
El administrador puede usar el programa para:
Cambiar el precio de una habitacin de acuerdo a su tipo.
Cambiar el valor del descuento ofrecido a los clientes habituales.
Calcular las ganancias que tendrn en un mes especificado (considere que todos los meses tienen
treinta das).

El diseo 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 Anlisis
a- Caso de Uso Anlisis
b- Clase Anlisis
- Clase Boundary
- Clase Control
- Clase Entidad
c- Diagrama de Colaboracin Clase Anlisis
d- Diagrama de Secuencia Clase anlisis
2- Modelo de Datos (Data Modeler Diagram)


1- MODELO DE ANALISIS
- El modelo de anlisis es una especificacin detallada de los requerimientos y trabajos.
- Lo usan los desarrolladores para entender los casos de uso, refinndolos como
colaboraciones entre clasificadores conceptuales.
- El modelo de anlisis se usa para crear un sistema robusto con reuso considerable de
componentes
- El modelo de anlisis es un modelo conceptual y no un proyecto de la implementacin.
- Especificacin detallada (precisa) de requisitos.
- Refina los casos de uso como colaboraciones entre clasificadores:
Clasificadores: clases de anlisis, paquetes.
Colaboraciones: realizaciones de los casos de uso.

MODELO DE CASO DE USO MODELO DE ANALISIS
Se describe utilizando el lenguaje del cliente Se describe utilizando el lenguaje del programador
Vista externa del sistema Vista interna del sistema
Estructurado por casos de uso Estructurado por clases y paquetes
Se usa primariamente como un contrato
entre el cliente y desarrolladores, determina
QUE har el sistema y se decide si el
sistema se llevar a cabo o no
Se utiliza principalmente por los
desarrolladores para entender QUE har el
sistema y plantear interacciones que
comiencen a definir el COMO

Puede contener redundancias e
inconsistencias

Se reducen considerablemente las
redundancias e inconsistencias

Captura las funcionalidades del sistema

Refina y describe la forma en que se
realizarn las funcionalidades del sistema

Define los CASOS DE USO y a futuro
sern analizados en el Modelo de Anlisis

Define REALIZACIONES DE CASOS DE
USO, donde cada uno representa el anlisis
de un caso de uso particular

2- ARTEFACTOS DEL ANALISIS

a- CLASES DE ANALISIS: representan una abstraccin de una o varias clases y/o subsistemas en
el diseo del sistema.
b- REALIZACIONES DE CASOS DE USO: descripcin de la realizacin de cada caso de uso en
trmino de clases de anlisis y la interaccin entre objetos de anlisis.
c- PAQUETES DE ANALISIS: permiten organizar el modelo de anlisis en piezas manejables.
Pueden contener realizaciones de casos de uso, clases de anlisis y otros paquetes de anlisis.
d- DESCRIPCIN DE LA ARQUITECTURA: vista arquitectnica del Modelo de Anlisis mostrando
sus artefactos ms significativo

3- ACTIVIDADES DEL ANALISIS
a- ANALIZAR CADA CASO DE USO
- Identificar Clases de Anlisis _ UML- Diagrama de Clases
- describir la interaccin entre objetos de anlisis
- UML -Diagrama de Colaboracin, descripcin Textual
- Capturar requerimientos especiales
b- ANALISIS ARQUITECTONICO

- Realizar un bosquejo del modelo de anlisis identificando los paquetes de anlisis, clases de
anlisis y requerimientos especiales ms importantes.

c- ANALIZAR PAQUETE
- Agrupar clases en paquetes cuando es necesario.
- Asegurar que cada paquete de anlisis es lo ms independiente posible de otros.
- Asegurar que cada paquete de anlisis satisface su propsito de realizacin de ciertas clases
y casos de uso.
d- ANALIZAR CADA CLASE DE ANALISIS
- Asignar un nombre, Identificar Atributos, Identificar relaciones.
- Identificar Responsabilidades: compilacin de todos los roles que la clase juega en todas las
realizaciones de casos de uso.
- Capturar requerimientos especiales.

4- TIPOS DE CLASE DE CLASES DE ANALISIS
a- CLASES LIMITE (Boundary class o interfaz):
- Modelan interaccin entre el sistema y sus actores.
- Clarifican los requisitos en la frontera entre sistema y usuarios. Cambios en los
interfaces de usuario, de comunicacin, 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 informacin persistente.
- Las clases entidad muestran la estructura lgica de los datos

c- CLASES CONTROL (Control class):
- representan coordinacin, secuencia miento, transacciones y control de objetos.
- Buscar una informacin concreta de una clase conociendo alguno de los valores de sus
atributos
- Crear/modificar/eliminar informacin
- Realizar procesos/clculos relacionados con la lgica del negocio
- No pueden conectarse directamente con los actores


Ejemplo
Caso de Uso: INSERTAR CLIENTE
Precondicin: existe un cliente para ser ingresado al sistema.
Pos condicin: se registra el nuevo cliente en el sistema o el cliente ya estaba cargado.
FLUJO DE EVENTOS PRINCIPAL
Secretaria Sistema
1. Ingresa el DNI del cliente.
3. Ingresa nro socio, nombre, telfono 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 situacin y termina el caso de
uso.
4.1. La localidad ingresada no existe, debe ingresar una localidad existente.

SOLUCION:
1- Clase Anlisis:

2- Diagr
ama de Clase Anlisis y Diagrama de Colaboracin
IU_Cliente
Ctrl_Cliente
Cliente
IU_Cliente Cliente
Ctrl_Cliente
Ctrl_Localidad

3- Atributos y responsabilidades de la clase

: Cliente
: Ctrl_Cliente
: Ctrl_Localidad
: IU_Cliente : Secretaria
1: Ingresar DNI 2: Chequear DNI
3: Obtener Cliente
4: Ingresar otros datos 5: Enviar Datos
6: Buscar localidad
7: Guardar Nvo Cliente
Atributos: DNI, nombre, telfono,
nrosocio. Localidad??
Responsabilidades:brindar y
mantener guardada los datos del
cliente. (set y get).

Atributos: DNI, nombre, telfono,
nrosocio. Localidad??
Responsabilidades:brindar y
mantener guardada los datos del
cliente. (set y get).

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

Atributos: ??.
Responsabilidades: chequear la
existencia del cliente, enviar datos
para ser guardados, buscar la
localidad ingresada.

: Cliente
: IU_Cliente
: Ctrl_Cliente

4- Diagrama de Secuencia

5- REALIZACION EN ANALISIS DE LOS CASOS DE USO
- Es una colaboracin que describe cmo se realiza en anlisis un caso de uso en trminos de
clases de anlisis y sus interacciones.
- Es una colaboracin que indica cmo se realiza/ejecuta un caso de uso.
- La realizacin en anlisis de un caso de uso, incluye:
a- diagramas de clases: clases participantes
b- diagramas de interaccin: escenarios del CU.
c- descripcin textual del flujo de eventos
d- nada de requisitos no funcionales (hasta el diseo).
: Cliente : Ctrl _Cli ente : Ctrl _Local idad : IU_Cl iente : Secretaria
1. Ingresar DNI
2. Chequear DNI
3. Obtener Cl iente
4. Ingresar otros datos
5. Envi ar Datos
6. Buscar local idad
7. Guardar Nvo Cl iente

6- DIAGRAMA DE CLASE
- Una clase de anlisis puede participar en varios casos de uso.
- Algunas responsabilidades, atributos y asociaciones suelen ser especficos de un slo caso
de uso.

7- DIAGRAMA DE INTERACCION
- La secuencia de acciones en un caso de uso comienza cuando un actor enva un mensaje a
una clase lmite.
- Se van a utilizar diagramas de colaboracin.
- Ejemplo: Caso de uso Publicar notas del actor Profesor.

Use Case Real izacion en anali sis
Modelo de Caso de Uso Modelo de Analisis

Ejemplo: ANALISIS DE CASO DE USO: SACAR DINERO


FASE
DE
TRANSICION

3- Modelo de Diseo

e- Diseo de Caso de Uso
f- Diagrama de Clase
- Elementos
- Relaciones
- Multiplicidad
g- Diagrama de Clase Interfaz
h- Diagrama de Clase Entidad
i- Diagrama de Colaboracin
j- Diagrama de Secuencia

4- Modelo Implementacin

a- Diagrama de Despliegue
b- Diagrama de Componentes

5- Modelo de Prueba

a- Especificaciones de caso de Prueba


MODELO DE DISEO
1- Concepto
El Diseo de Sistemas se define el proceso de aplicar ciertas tcnicas y principios con el
propsito de definir un dispositivo, un proceso o un Sistema, con suficientes detalles como para
permitir su interpretacin y realizacin fsica.
La Fase de diseo (y los modelos UML resultantes expande y detalla los modelos de anlisis
tomando en cuenta todas las implicaciones y restricciones tcnicas. El propsito del diseo es
especificar una solucin que trabaje y pueda ser fcilmente convertida en cdigo fuente y
construir una arquitectura simple y fcilmente extensible. Las clases definidas en el anlisis
fueron detalladas, y se aadieron nuevas clases para manejar reas tcnicas como base de datos,
interfaz de usuario, comunicacin, dispositivos, etc.
La importancia del Diseo del Software se puede definir en una sola palabra Calidad, dentro del
diseo es donde se fomenta la calidad del Proyecto. El Diseo es la nica manera de materializar
con precisin los requerimientos del cliente.
El Diseo del Software es un proceso y un modelado a la vez. El proceso de Diseo es un
conjunto de pasos repetitivos que permiten al diseador describir todos los aspectos del Sistema
a construir. A lo largo del diseo se evala la calidad del desarrollo del proyecto con un
conjunto de revisiones tcnicas:
El diseo debe implementar todos los requisitos explcitos contenidos en el modelo de anlisis y
debe acumular todos los requisitos implcitos que desea el cliente.
Debe ser una gua que puedan leer y entender los que construyan el cdigo y los que prueban y
mantienen el Software.
El Diseo 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 Implementacin.


2- Diseo de Caso de Uso
El principal objetivo de esta etapa es refinar las realizaciones de los casos de uso a travs de nuevas
iteraciones en el proceso. Adems, tambin se debe refinar el modelo de diseo y los requisitos de
las operaciones de las clases de diseo.
Esta actividad es bsicamente el centro del proceso de creacin del modelo de diseo, en el que se
irn refinando, iteracin a iteracin, el diseo de los casos de uso y de las operaciones obtenidas a
partir de ellos, que aparece plasmado en el modelo de clases de diseo.
Este Modelo de Diseo se reflejar en Diagramas de Clases de Diseo donde aparecern las clases
de diseo 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 realizarn las siguientes acciones:

Refinar las realizaciones de casos de uso ya realizadas en iteraciones anteriores.
Describir las interacciones entre los objetos de diseo.
Simplificar diagramas de secuencia haciendo uso de subsistemas. Estos sern descritos en la
siguiente actividad de esta fase.
Refinar el modelo de comportamiento de los casos de uso y la descripcin del flujo de eventos.
Unificar las clases de diseo y los subsistemas que aparecern en la solucin diseada.
Continuamente se deber completar y evaluar el modelo de diseo (clases de diseo) que se
modificar a lo largo de esta actividad.

3- Diagrama de Clase

Los diagramas de clases muestran un resumen del sistema en trminos de sus clases y las
relaciones entre ellas. Son diagramas estticos que muestran qu es lo que interacta, pero no
cmo interacta o qu pasa cuando ocurre la interaccin.
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 agregacin.
El propsito 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 programacin.
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 esttico 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 anlisis y diseo de los sistemas, donde se crea el diseo
conceptual de la informacin que se manejar en el sistema, y los componentes que se
encargaran del funcionamiento y la relacin entre uno y otro.

Caso de Uso Real izacion
Caso de Uso real izacion Diseo

Elementos del Diagrama de Clase
Clase:
- Una clase refiere genricamente a los objetos de una familia que se perciben con
propiedades y comportamiento comunes.
- Es la unidad bsica que encapsula toda la informacin 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 fsica o conceptual.
- Objeto: Es una instancia de una clase. Ejemplo: Zapato mocasn.
- En UML, una clase es representada por un rectngulo 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 descripcin de una clase se debe distinguir entre
los atributos los cuales reflejan las caractersticas de los objetos en el mundo real, y los
identificadores los cuales son utilizados
- exclusivamente por razones de implementacin. Estos identificadores internos del sistema
no deben ser incluidos como atributos.

- Operaciones o Mtodos: Las operaciones son funciones o transformaciones que se aplican
a todos los objetos de una clase particular. La operacin puede ser una accin 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 slo ser accesible desde dentro de la clase
(slo sus mtodos lo pueden acceder).
c- Protected (#, ): Indica que el atributo no ser accesible desde fuera de la clase,
pero si podr ser accesado por mtodos de la clase adems de las subclases que se
deriven (herencia).

- Visibilidad en el Mtodo
a- Public (+, ): Indica que el mtodo ser visible tanto dentro como fuera de la clase,
es decir, es accesible desde todos lados.
b- Private (-, ): Indica que el mtodo slo ser accesible desde dentro de la clase
(slo otros mtodos 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 mtodos de la clase adems de las subclases que se
deriven (herencia)


Multiplicidad
Representa el nmero de objetos que pueden conectarse a travs de una relacin de
asociacin
Especificacin de multiplicidad (mnima...mxima)

1 Uno y slo uno
1..1 Uno y slo 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- Asociacin: La relacin entre clases conocida como Asociacin, permite asociar objetos
que colaboran entre si. Cabe destacar que no es una relacin fuerte, es decir, el tiempo de
vida de un objeto no depende del otro.

Ejemplo1:


Ejemplo2:

Ejemplo 3:

Ejemplo4:


Ejercicios


Tipos de Relaciones
Composicin: Es una relacin de todo y parte de, donde el todo esta formado por objetos parte
de que lo componen. Se pueden observar las siguientes caractersticas:
- 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 comparticin: Los objetos contenidos no son compartidos, esto es, no forman parte del
estado de otro objeto.

Agregacin: Es una relacin de contenedor y contenido, donde el contenedor contiene objetos
contenido. Se pueden observar las siguientes caractersticas:
- Independencia existencial: El elemento contenido no desaparece al destruirse el que lo
contiene.
- Pertenencia dbil: Se puede decir que el objeto contenedor no contiene realmente al objeto
contenido, sino que tiene una referencia a l.
- Comparticin: Los objetos contenidos tambin pueden formar parte del estado de otro
objeto



Herencia: Indica que una subclase hereda los mtodos y atributos
especificados por una superclase, de esta forma la subclase adems de poseer
sus propios mtodos y atributos, poseer las caractersticas y atributos
visibles de la superclase (public y protected), ejemplo:

Clase Asociativa: describe una asociacin 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 relacin muy particular, en la que una clase es
instanciada (su instanciacin es dependiente de otro Objeto/clase). Se denota por una
flecha punteada.
El uso ms particular de este tipo de relacin es para denotar la dependencia que
tiene una clase de otra, como por ejemplo una aplicacin grafica que instancia una
ventana (la creacin del Objeto Ventana est condicionado a la instanciacin
proveniente desde el objeto Aplicacin):

Herencia Mltiple:
- Se presenta cuando
una subclase tiene
ms de una
superclase
- La herencia mltiple
debe manejarse con
precaucin. Algunos
problemas son el
conflicto
de nombre y el
conflicto de precedencia.
- Se recomienda un
uso restringido y
disciplinado de la
herencia.
- Uso disciplinado de
la herencia mltiple:
clasificaciones
disjuntas con clases padre en hojas de jerarquas alternativas

Diagrama de Clase Interfaz: Representa la relacin entre las clases que son asignadas a un determinado
formulario con parmetros de implementacin.

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


MODELO DE IMPLEMENTACION
1- Concepto:
En este flujo de trabajo se implementan las clases y objetos en ficheros fuente, binarios, ejecutables y dems.
Adems 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 iteracin habr que hacer lo siguiente:
Planificar qu subsistemas deben ser implementados y en qu orden deben ser integrados, formando el
Plan de Integracin.
Cada implementador decide en qu orden implementa los elementos del subsistema.
Si encuentra errores de diseo, 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 implementacin. La integracin debe
ser incremental, es decir, en cada momento slo se aade un elemento. De este modo es ms fcil localizar
fallos y los componentes se prueban ms 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 tecnologas o disear 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 cmo un sistema de software es dividido en componentes y muestra
las dependencias entre estos componentes. Los componentes fsicos incluyen archivos, cabeceras, libreras
compartidas, mdulos, 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 ms parecidos a los diagramas de casos de usos estos son utilizados para modelar la
vista esttica y dinmica de un sistema. Muestra la organizacin 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 situarn libreras, 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 fsica de un sistema
(modulo, base de datos, programa
ejecutable, etc.). Se puede decir
que un componente es la
materializacin de una o ms
clases, porque una abstraccin con
atributos y mtodos 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 definicin.

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 mayora de las veces el modelado de la vista de despliegue implica modelar la topologa del hardware
sobre el que se ejecuta el sistema. Aunque UML no es un lenguaje de especificacin hardware de propsito
general, se ha diseado 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 fsicos que existen en tiempo de ejecucin, y que representan algn
tipo de recurso computacional (capacidad de memoria y procesamiento):
- Computadores con procesadores
- Otros dispositivos
- impresoras
- lectoras de cdigos de barras
- dispositivos de comunicacin

Los nodos se conectan mediante asociaciones de comunicacin.
Estas asociaciones indican:
Algn tipo de ruta de comunicacin entre los nodos
Los nodos intercambian objetos o envan mensajes a travs de esta ruta
El tipo de comunicacin se identifica con un estereotipo que indica el protocolo de
comunicacin o la red.

Uml Proyect

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Uml Proyect

Uploaded by

Copyright:

Available Formats

Proyecto de desarrollo del Software Rational Unified Process

You might also like