Proyecto de desarrollo del Software Rational Unified Process
Proyecto de desarrollo del Software Rational Unified Process
METODOLOGIA RUP
(RATIONAL UNIFIED PROCESS)
Proyecto: __________________________________________
Sistema: ___________________________________________
Integrantes:
Jefe de Proyecto: ________________________________________
Colaboradores:1- Colaborador12- Colaborador23- Colaborador.n
FASE DE INICIO
Consideraciones:1- Aspectos generales de la organizacin2- Plan
de desarrollo de software3- Modelo de Negocioa- Unidad
Organizacionalb- Paquete de Negocioc- Diagrama de Paquete de
Negociod- Diagrama de Caso de Uso de Negocioe- Especificaciones de
Caso de Uso de Negociof- Diagrama de Actividad de Negociog-
Diagrama de Objetos de Negocio
PROYECTO DE DESARROLLO DE SOFTWAREASPECTOS ORGANIZACIONALES1-
Organizacin1.1- Introduccin1.2- Resea histrica1.3- Ubicacin
Geogrfica
2- Estructura Organizacional2.1- Visin2.2- Misin2.3- Metas2.4-
Objetivo- General- Especficos2.5- Organigrama 3- rea de
Desarrollo3.1- Descripcin del rea3.2- Aspectos generales del rea-
Visin- Misin- Metas3.3- Integrantes del rea- Cargo- Funciones-
Responsabilidades3.4- Definicin y descripcin del problema-
Administrativo- Organizacional3.5- Recomendaciones- Administrativo-
Organizacional 3.5- reas Involucradas3.6- Formatos manuales
1- OrganizacinUna 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 histricaOrigen, creacin y evolucin de la
organizacin1.3- Ubicacin Geogrfica (mapa)
2- Estructura Organizacional2.1- VisinDefine 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 ObjetivosUna 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- OrganigramaEl 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 DesarrolloEstablecer 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 problemaCuadro donde se menciona
todos los problemas (administrativo y organizacional) puntuales y
una breve descripcin del mismo.
3.5- Recomendaciones
3.6- Areas InvolucradasIdentificar las areas que estn
relacionadas con el rea en estudio3.7- Formatos ManualesInsertar
todos los formatos manuales existentes en el rea.
PLAN DE DESARROLLO DE SOFTWARE
1.Introduccin2.Vista General del Proyecto2.1Propsito, Alcance y
Objetivos2.2Suposiciones y Restricciones2.3Entregables del
proyecto2.4Evolucin del Plan de Desarrollo del
Software3.Organizacin del Proyecto3.1Participantes en el
Proyecto3.3Roles y Responsabilidades4.Gestin del
Proceso4.1Tecnologia de Informacion4.1..1 Evaluacion
Tecnologica4.1.2 Recomendaciones4.2Plan del Proyecto4.2.1Plan de
las Fases4.2.2Calendario del Proyecto
Plan de Desarrollo del SoftwareIntroduccinLa 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 planEjemplo1: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.Vista General del ProyectoPropsito, Alcance y
ObjetivosPropsito: 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.Suposiciones
y RestriccionesLos 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).
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 SoftwareEs el
presente documento.2) Modelo de Casos de Uso del NegocioEs un
modelo de las funciones de negocio vistas desde la perspectiva de
los actores externos (Agentes de registro, solicitantes finales,
otros sistemas etc.). Permite situar al sistema en el contexto
organizacional haciendo nfasis en los objetivos en este mbito. Este
modelo se representa con un Diagrama de Casos de Uso usando
estereotipos especficos para este modelo.3) Modelo de Objetos del
NegocioEs 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 UsoEl modelo de Casos de Uso presenta
las funciones del sistema y los actores que hacen uso de ellas. Se
representa mediante Diagramas de Casos de Uso. 5) Especificaciones
de Casos de UsoPara los casos de uso que lo requieran (cuya
funcionalidad no sea evidente o que no baste con una simple
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 UsuarioSe 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
DiseoEste 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 RiesgosEste 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
Evolucin del Plan de Desarrollo del SoftwareEl Plan de
Desarrollo del Software se revisar semanalmente y se refinar antes
del comienzo de cada iteracin.
Organizacin del ProyectoDescribe 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.
Clientes y UsuariosDesarrolladoressoftware objetivo Maquina
Personas, Equipos, Organizaciones
IdeasEspecificacin Diseo Cdigo
Participantes en el Proyecto
Jefe de Proyecto. Aqu se declara el perfil del candidato a este
puesto, as como su nombre y apellidosAnalista de Sistemas. Aqu se
declara el perfil del candidato a este puesto, as como su nombre y
apellidosAnalistas - Programadores. Aqu se declara el perfil de los
candidatos a estos puestos, as como sus nombres y
apellidosIngeniero de Software.Aqu se declara el perfil del
candidato a este puesto, as como su nombre y apellidos
Roles y ResponsabilidadesA 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.
PuestoResponsabilidad
Jefe de ProyectoEl 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 SistemasCaptura, 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.
ProgramadorConstruccin de prototipos. Colaboracin en la
elaboracin de las pruebas funcionales, modelo de datos y en las
validaciones con el usuario
Ingeniero de SoftwareGestin 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.
Gestin del ProcesoLa 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.Tecnologa de
Informacin Evaluacin Tecnolgica RecomendacionesPlan del ProyectoEn
esta seccin se presenta la organizacin en fases e iteraciones y el
calendario del proyecto.Plan de las FasesEl 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)FaseNro.
IteracionesDuracin
Fase de Inicio117-set-30
Fase de Elaboracin11-oct-11-nov
Fase de Construccin112-nov-24-dic
Fase de Transicin125-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.DescripcinHito
Fase de InicioEn 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 ElaboracinEn 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 ConstruccinDurante 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 TransicinEn 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.
Calendario del ProyectoA 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 ElaboracinFase de Construccin
Fase de Transicin
MODELO DE NEGOCIO1. 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 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 Negocioa- Unidad Organizacionalb-
Paquete de Negocioc- Diagrama de Paquete de Negociod- Diagrama de
Caso de Uso de Negocioe- Especificaciones de Caso de Usof- Diagrama
de Actividad de Negociog- Diagrama de Objetos de NegocioUnidad
OrganizacionalLa unidad Organizacional es un contenedor de objetos
de negocio, representa la organizacin
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
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: 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:
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:
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 libroLa 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 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 productosProceso de negocio:1. La venta
de productos comienza cuando un cliente se acerca al local de la
empresa y es atendido por un asesor de ventas que toma su pedido
generando una orden de pedido, en esta orden se detalla los datos
del cliente y las 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 NEGOCIOEs 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 NEGOCIOEl 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
softwareElemnetos:1- Bussiness Enty o Entidad de Negocio: ente
manipulado por los trabajadores de negocio, representa el lugar
donde se almacena o consulta datos de forma manual.
2- Bussiness Worker o trabajador de negocio: rol o roles dentro
del proceso de negocio que manipula las entidades de negocio.
3- Business use case realization o Realizacion de Caso de Uso de
Negocio
4- Diagrama de Actividad de Negocio5- Diagrama de Objetos de
Negocio: Representa las responsabilidades de los trabajadores de
negocio con respecto a las entidades de negocio y las relaciones
entre las mismas entidades de negocio.6- Diagrama de colaboracion
de negocio
Ejemplo de daigrama de objetos de negocio:
FASE DE ELABORACION
1- Diagrama de Paquete de Sistema2- Modelo de Caso de Uso
(Modelo de Requisitos)a- Diagrama de caso de usob- Diagrama de
Actividadc- Especificaciones de caso de uso3- Prototipos (interfaz
de usuario)
1- DIAGRAMA DE PAQUETE DE SISTEMAEn 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 USOEl
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 funcionalesa- 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 sistemaEl 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.
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 Uso1.1- Descripcion2- Flujo de Eventos2.1-
Flujo Basico2.2- Flujos Alternativos2.2.1- Flujo alternativo2.2.2-
Otro flujo alternativo3- Precondiciones3.1- Una Precondicion3.2-
Otra precondicion4- Poscondiciones4.1- Una poscondicion4.2- Otra
poscondicion Ejemplo de especificaciones de caso de
uso:Especificacin de Caso de Uso 1- Registrar Producto 1.1 Breve
DescripcinPermite 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
Eventos2.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 Producto1. 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
Producto1. 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 Buscar3. 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 Producto5. 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 criterio8. El jefe de Almacn selecciona
grabar9. El sistema guarda los datos modificados y genera un
mensaje Actualizacin Completada 10. El Jefe de almacn presiona
Aceptar11. El Sistema regresa a la interfaz Gestin de
Productos.2.1.3- Eliminar Producto1. El jefe de almacn ingresa el
criterio de bsqueda del producto en la interfaz de Gestin de
productos.2. El jefe de almacn selecciona buscar3. 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
Producto5. El Jefe de almacn selecciona el producto(s) que desea
eliminar presionando en el checkbox correspondiente.6. El Jefe de
almacn presiona el botn Eliminar7. El sistema muestra mensaje
Seguro que desea eliminar el producto(s) seleccionado(s) de la
lista8. El jefe de Almacn confirma presionando el botn Aceptar9. El
sistema elimina el producto(s) seleccionado de la base de datos10.
El sistema limpia los campos del producto2.2- Flujos
Alternativos2.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- 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 momento2.2.3 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- Precondiciones3.1- El Jefe de Almacn tiene que
estar logeado en el sistema3.2- Que existan productos ingresados a
la base de datos 4- Pos condiciones4.1- El sistema ha actualizado
la lista de productos Ejemplo de especificaciones de Caso de
UsoEspecificacin de Caso de Uso1- Gestin de Clientes 1.1-
DescripcinEste 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 EventosFlujo Bsico1. 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 AlternativosEn el punto 2.2El 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
error3- PROTOTIPO O INTERFAZ DE USUARIOEsta 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:
HotelEl 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 Anlisisa- Caso de Uso Anlisisb- Clase Anlisis Clase
Boundary Clase Control Clase Entidadc- Diagrama de Colaboracin
Clase Anlisisd- Diagrama de Secuencia Clase anlisis2- 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 USOMODELO DE ANALISIS
Se describe utilizando el lenguaje del clienteSe describe
utilizando el lenguaje del programador
Vista externa del sistemaVista interna del sistema
Estructurado por casos de usoEstructurado por clases y
paquetes
Se usa primariamente como un contratoentre el cliente y
desarrolladores, determinaQUE har el sistema y se decide si
elsistema se llevar a cabo o noSe utiliza principalmente por
losdesarrolladores para entender QUE har elsistema y plantear
interacciones quecomiencen a definir el COMO
Puede contener redundancias einconsistencias
Se reducen considerablemente lasredundancias e
inconsistencias
Captura las funcionalidades del sistema
Refina y describe la forma en que serealizarn las
funcionalidades del sistema
Define los CASOS DE USO y a futurosern analizados en el Modelo
de Anlisis
Define REALIZACIONES DE CASOS DEUSO, donde cada uno representa
el anlisisde 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 ANALISISa- 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
especialesb- 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 ANALISISa- 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
SecretariaSistema
1. Ingresa el DNI del cliente.3. Ingresa nro socio, nombre,
telfono y localidad2. Chequea existencia.4. Include (buscar
localidad)5. Carga al nuevo cliente.
FLUJO DE EVENTOS ALTERNATIVOS2.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- Diagrama de Clase Anlisis y Diagrama de Colaboracin
3- Atributos y responsabilidades de la clase
Atributos: DNI, nombre, telfono,nrosocio.
Localidad??Responsabilidades:brindar ymantener guardada los datos
delcliente. (set y get).
Atributos: DNI, nombre, telfono,nrosocio.
Localidad??Responsabilidades:brindar ymantener guardada los datos
delcliente. (set y get).
Atributos: ??.Responsabilidades: recibir los datosingresados por
el usuario. Chequearformato de los datos ingresados.Mostrar
resultados al usuario.
Atributos: ??.Responsabilidades: chequear laexistencia del
cliente, enviar datospara ser guardados, buscar lalocalidad
ingresada.
4- Diagrama de Secuencia
5- REALIZACION EN ANALISIS DE LOS CASOS DE USO Es una
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 participantesb- diagramas de interaccin: escenarios
del CU.c- descripcin textual del flujo de eventosd- nada de
requisitos no funcionales (hasta el diseo).
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.
Ejemplo: ANALISIS DE CASO DE USO: SACAR DINERO
FASE DE TRANSICION
3- Modelo de Diseo
e- Diseo de Caso de Usof- Diagrama de Clase Elementos Relaciones
Multiplicidadg- Diagrama de Clase Interfazh- Diagrama de Clase
Entidadi- Diagrama de Colaboracin j- Diagrama de Secuencia
4- Modelo Implementacin
a- Diagrama de Despliegueb- Diagrama de Componentes
5- Modelo de Prueba
a- Especificaciones de caso de Prueba
MODELO DE DISEO1- 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 UsoEl 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.
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 Mtodoa- 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.
Relacionesa- 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 conflictode 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
alternativasDiagrama 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 IMPLEMENTACION1- 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 ComponenteUn 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 DespliegueEl 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.
Prof. Ayquipa Cordova, Godofredo
Hoja1IdNombre de Tarea17 - Setiembre - 2324 - Setiembre -
301Fase de InicioLMMJVSDLMMJVSD2Modelado del Negocio3Modelos de
Casos de Uso de Negocio4Modelo de los procesos de Negocio5Modelado
del Dominio6Modelo de Objetos del Negocio7Modelado de
Requisitos8Visin9Modelo de Requisitos10Especificacin de Casos de
Uso11Priorizar Organizar Casos de Uso12Anlisis13Diseo
IdNombre de Tarea01/10 a 07/1008/10 a 14/1015/10 a 21/1022/10 a
28/1029/10 a 04/1105/11 a 11/111Fase de Inicio2Modelado del
Negocio3Modelos de Casos de Uso de Negocio4Modelo de los procesos
de Negocio5Modelado del Dominio6Modelado de Requisitos7Visin8Modelo
de Requisitos9Especificacin de Casos de Uso10Priorizar Organizar
Casos de Uso11Anlisis del Sistema12Paquetes del Anlisis13Realizacin
de Casos de Uso14Modelo de Clases del Anlisis15 Clases Entidad
Fundamentales16 Otras Clases del Modelo17Diseo del
Sistema18Arquitectura Lgica del Sistema19Arquitectura Fsica del
Sistema20Modelo Lgico de Datos21Implementacion22Modelo Fsico de
Datos23Implementacin de las Clases del Sistema24Aspectos Destacados
de Implementacin25 Aplicaciones del Sistema26 Interaccin con la
Base de Datos27 Correspondencia con la Base de Datos28
Implementacin del Sitio Web29Pruebas
Hoja2
Hoja3
