Resumen Anlisis de Sistemas

Unidad N 1 los sistemas de informacin

Conceptos de informacin

1) Diferencia entre datos e informacin:

a) Datos: Realidades concretas en su estado primario. Representan hechos reales. Poseen escaso valor ms all del de su
sola existencia.
b) Informacin: Conjunto de datos organizados de tal manera que adquieren valor adicional ms all del que poseen por
s mismos. La conversin de datos en informacin es un proceso o serie de tareas lgicamente relacionadas entre s y
ejecutadas con el fn de producir un resultado defnido. El proceso para defnir relaciones entre datos requiere de
conocimiento, que es la apreciacin y comprensin de un conjunto de informacin y de la utlidad que puede extraerse de
ella en benefcio de una tarea especfca. Es por eso que decimos que la informacin puede considerarse como datos
provistos de mayor utlidad mediante la aplicacin del conocimiento. El conjunto de datos, reglas, procedimientos y
relaciones que deben tomarse en cuenta para generar valor u obtener el resultado que se busca consttuye la base de
conocimientos.

2) Caracterstcas de la informacin valiosa:

La informacin debe poseer ciertas caracterstcas para que a los administradores y responsables de decisiones les resulte
valiosa:

Exacta: Carece de errores.
Completa: Contene todos los datos importantes.
Econmica: Los responsables de la toma de decisiones siempre deben evaluar el valor de la informacin con el
costo de producirla.
Flexible: Es tl para muchos propsitos.
Confable: Esto depender de algunos factores. En algunos casos, del mtodo de recoleccin de datos, en otros de
la fuente de informacin.
Pertnente: Es la realmente importante para el responsable de la toma de decisiones.
Simple: No excesivamente compleja.
Oportuna: Es la que se recibe justo cuando se la necesita.
Verifcable: Se tene la posibilidad de comprobar que es correcta.
Accesible: De fcil acceso para los usuarios autorizados.
Segura: Protegida contra el acceso a ella de usuarios no autorizados.

La informacin tl puede variar ampliamente segn el valor de cada uno de estos atributos.

3) El valor de la informacin:

El valor de la informacin est directamente relacionado con la utlidad que represente para los responsables de la toma
de decisiones en el cumplimiento de las metas de la organizacin; puede medirse, por ejemplo, con base en el tempo
requerido para tomar una decisin o en el aumento de las utlidades de la compaa. La informacin valiosa tambin
puede ser de utlidad para los administradores en su decisin de invertr o no en sistemas y tecnologa de informacin
adicionales.



Conceptos de sistemas y modelado

1) Sistema: Conjunto de elementos o componentes que interactan entre si para cumplir metas. Los propios elementos y
las relaciones entre ellos determinan el funcionamiento del sistema.

2) Componentes y conceptos de sistema:

a) Lmite de un sistema: Alcance que defne a un sistema y lo distngue de su entorno.

b) Componentes de un sistema: Los cuatro componentes de un sistema son: entrada, salida y retroalimentacin. La forma
en que estn organizados o dispuestos los elementos de un sistema se llama confguracin.

c) Tipos de sistemas:

-Simple vs. Complejo: El simple posee pocos componentes y la relacin entre ellos es sencilla y directa. El complejo posee
muchos elementos estrechamente relacionados e interconectados. -Abierto vs. Cerrado: El abierto interacta con su
entorno. El cerrado no.
-Estable vs. Dinmico: El estable sufre escasos cambios al paso del tempo, en cambio el dinmico sufre rpidos y constantes
cambios al paso del tempo.
-Adaptable vs. No adaptable: El adaptable es capaz de modifcarse en respuesta a cambios en el entorno, en cambio el no
adaptable es incapaz de modifcarse en respuesta a cambios en el entorno.
-Permanente vs. No permanente: El permanente est diseado para existr durante un perodo relatvamente largo, en
cambio el temporal est diseado para existr durante un perodo relatvamente corto.

d) Clasifcacin de organizaciones por tpo de sistema: La mayora de las compaas pueden ser descritas con base en el
esquema de clasifcacin descrito anteriormente.

3) Desempeo y estndares de sistema

El desempeo de un sistema puede medirse de varias maneras. La efciencia es una medida de lo que se produce dividido
entre lo que se consume, puede ir del 0 al 100 por ciento. La efcacia es una medida del grado en el que un sistema cumple
sus metas. Se le puede calcular al dividir las metas alcanzadas en realidad entre el total de las metas establecidas. La
efciencia y la efcacia son trminos relatvos empleados para comparar sistemas.
Efciencia y efcacia son objetvos de desempeo fjados en relacin con un sistema general. El cumplimiento de estos
objetvos supone considerar no slo la efciencia y efcacia deseadas, sino tambin el costo, complejidad y nivel de control
que desean del sistema. El costo comprende tanto los gastos iniciales de un sistema como la totalidad de sus gastos
directos permanentes. La complejidad tene que ver con qu tan complicada es la relacin entre los elementos del
sistema. El control es la capacidad de un sistema para funcionar dentro del marco de normas predefnidas as como el
esfuerzo administratvo requerido para mantener dentro de esos lmites el funcionamiento del sistema.
La evaluacin del desempeo de un sistema demanda tambin el empleo de estndares de desempeo. Un estndar de
desempeo de sistemas es un objetvo especfco del sistema. Una vez establecidos los estndares, se mide el desempeo
del sistema y se lo compara con el estndar. Las variaciones respecto al estndar son determinantes del desempeo del
sistema.
El cumplimiento de objetvos defnidos de efciencia y efcacia o de estndares de desempeo de sistemas pueden imponer
disyuntvas en trminos de costo, control y complejidad.

4) Variables y parmetros de sistemas

Ciertas partes de un sistema son susceptbles de control administratvo directo, mientras que otras no. Una variable de
sistemas es una cantdad o unidad que puede ser controlada por el tomador de decisiones. Un parmetro de sistemas es
un valor o cantdad imposible de controlar.

5) Modelado de un sistema

Un modelo es una abstraccin o aproximacin que sirve para representar la realidad. Permiten examinar situaciones reales
y obtener una mejor comprensin de ellas. Son modelos simplifcados, NO reales.

Existen varios tpos de modelos
Narratvo: se basa en palabras. Las descripciones de la realidad, tanto orales como escritas, se consideran modelos
narratvos.
Fsico: es una representacin tangible de la realidad.
Esquemtco: es una representacin grfca de la realidad. Ej: grfcas, mapas, fguras, diagramas, ilustraciones e imgenes.
Matemtco: es una representacin aritmtca de la realidad.

Qu es un sistema de informacin?

1) Sistema de informacin: Conjunto de elementos o componentes interrelacionados para recolectar(entrada),
manipular(procesamiento) y diseminar(salida) datos e informacin, que cuenta adems con un mecanismo de
retroalimentacin para el cumplimiento de un objetvo.

2) Entrada, procesamiento, salida y retroalimentacin.

a) Entrada: Actvidad que consiste en recopilar y capturar datos primarios. El tpo de entrada est determinado por la
salida que se desea obtener del sistema. Puede ser un proceso manual o automatzado. La exacttud de la entrada es
decisiva para obtener la salida deseada.
b) Procesamiento: Conversin o transformacin de datos en salidas tles. Esto puede implicar ejecutar clculos, realizar
comparaciones y adoptar acciones alternas, y el almacenamiento de datos para su uso posterior. El procesamiento puede
llevarse a cabo de manera manual o con la asistencia de computadoras.
c) Salida: Informacin tl, por lo general en forma de documentos y/o reportes. En algunos casos, la salida de un
sistema bien podra ser la entrada de otro. Puede producirse por diversos medios.
d) Retroalimentacin: salida que se utliza para efectuar cambios en actvidades de entrada o procesamiento. La
presencia de errores o problemas, podra imponer la necesidad de corregir datos de entrada o modifcar un proceso. Es de
gran importancia para administradores y tomadores de decisiones. El sistema de retroalimentacin puede reaccionar a la
existencia de un problema y alertar al administrador (mtodo reactvo). Un sistema de computacin tambin puede
adoptar un mtodo pro actvo de retroalimentacin, llamado pronstco, para prever la futura ocurrencia de
determinados hechos con el propsito de evitar problemas.

3) Sistemas de informacin manuales y computarizados.

Un sistema de informacin puede ser manual o computarizado. Muchos sistemas de informacin son inicialmente
sistemas manuales que despus se convierten en sistemas computarizados. Sin embargo, la simple computarizacin de un
sistema manual de informacin no garantza un mejor desempeo. SI el sistema original es defectuoso, bien podra ocurrir
que al ser computarizado no se consiguiera ms que magnifcar el impacto de esos errores.

4) Sistemas de informacin basados en computadoras.

Un sistema de informacin basado en computadoras (SIBC) est compuesto por hardware, sofware, bases de datos,
telecomunicaciones, personas y procedimientos especfcamente confgurados para recolectar, manipular, almacenar y
procesar datos para ser convertdos en informacin. Tambin se les conoce como infraestructura tecnolgica de una
compaa, porque consttuyen los recursos compartdos de SI que sirven de fundamento a los sistemas de informacin.

a) Hardware: Equipo de computacin que se utliza para llevar a cabo las actvidades de entrada( teclados por ej.),
procesamiento( CPU y memoria principal) y salida (impresora y pantalla por ej.).
b) Sofware: Programas de computacin que dirigen las operaciones de una computadora. Son dos los tpos bsicos de
sofware: sofware del sistema que controla las operaciones fundamentales de una computadora como arranque e
impresin; y sofware de aplicaciones que hacen posibles la ejecucin de tareas especfcas como el procesamiento de
texto o tabulacin de nmeros.
c) Bases de datos: Conjunto organizado de datos e informacin. Se cuentan entre los componentes ms valiosos e
importantes de los sistemas de informacin basados en computadoras.
d) Telecomunicaciones, redes e Internet: La telecomunicaciones son la transmisin electrnica de seales de
comunicacin que permiten a las organizaciones conectar entre s sistemas de computacin para integrar redes. Las redes
sirven para enlazar las computadoras y equipo de computacin de un edifcio, un pas o el mundo entero, con la fnalidad
de establecer comunicaciones electrnicas. La Internet es la red de computacin ms grande del mundo; consiste en miles
de redes interconectadas, todas las cuales intercambian libremente informacin. Dentro de una organizacin se utlizan las
Intranet que son redes que emplean la tecnologa de Internet mediante las cuales los miembros de la organizacin pueden
intercambiar informacin y trabajar en proyectos comunes. La World Wide Web (WWW) es una red de enlaces con
documentos dotados de hipermedia ( texto, grfcos, video, audio). La informacin respecto a tales documentos y el
acceso a ellos se hallan bajo el control y administracin de decenas de miles de servidores Web. La Web es uno de los
muchos servicios disponibles en Internet y permite acceder a millones de documentos.
e) Personas: Son el elemento ms importante de la mayora de los sistemas de informacin basados en computadoras.
El personal de sistemas de informacin incluye a todos los individuos que administran, operan, programan y mantenen el
sistema. Los usuarios son todos aquellos que utlizan sistemas de informacin para obtener resultados.


Ejemplos:
Lder del proyecto.
Usuario.
Administrador: da los recursos para la realizacin del sistema.
Analista: crea los modelos de la solucin a los requerimientos del usuario.
Diseador: dice de qu modo hay que construir el sistema.
Desarrollador: codifca el sistema.
Operador: realiza la carga de datos.
Tester: prueba el sistema.

f) Procedimientos: Son las estrategias, poltcas, mtodos y reglas para el uso de SIBC. Describen en qu momento
efectuar un programa, quin puede tener acceso a la informacin de la base de datos, qu debe hacerse en caso de
desastre, en cuyos casos el SIBC sea inutlizable.


Sistemas de informacin de las empresas

1) Sistemas de procesamiento de transacciones: Una transaccin es todo intercambio relacionado con la actvidad
empresarial. Un sistema de procesamiento de transacciones (TPS) es un conjunto organizado de personas,
procedimientos, sofware, bases de datos y dispositvos para registrar las transacciones comerciales consumadas. Conocer
un sistema de procesamiento de transacciones es conocer las operaciones y funciones bsicas de la compaa.

2) Comercio electrnico: Comprende todas las transacciones de negocios ejecutadas por medios electrnicos entre
compaas (empresa-empresa), compaas y consumidores (empresa-cliente), compaas y sector pblico, y consumidores
y sector pblico.

3) Sistemas de informacin administratva (MIS): Conjunto organizado de personas, procedimientos, sofware, bases de
datos y dispositvos para suministrar informacin rutnaria a administradores y tomadores de decisiones. El inters
partcular de un MIS es la efciencia operatva. Suelen producir informes estndar generados con base en datos e
informacin procedentes del sistema de procesamiento de transacciones.

4) Sistemas de apoyo para la toma de decisiones (DSS): Conjunto organizado de personas, procedimientos, sofware,
bases de datos, y dispositvos para el apoyo en la toma de decisiones referentes a problemas especfcos. El campo de
inters del DSS es la efcacia de la toma de decisiones. As, mientras un MIS contribuye a que una organizacin haga
correctamente las cosas, Un DSS ayuda a los administradores a hacer las cosas correctas. Un DSS sirve de base y fuente
de ayuda ara todos los aspectos de la toma de decisiones referentes a problemas especfcos. Por tanto, su espectro es
mayor que el de un MIS; es capaz de ofrecer asistencia inmediata para resolver problemas complejos respecto de los
cuales un MIS carecera de utlidad. Sus elementos principales son: modelos tles para el tomador de decisiones o usuario
(base de modelos), un compuesto de datos e informacin de utlidad para la toma de decisiones (base de datos), y
sistemas y procedimientos ( interfaz del usuario) que permitan a tomadores de decisiones y otros usuarios interactuar con
el DSS.

5) Inteligencia artfcial y sistemas expertos: Las organizaciones suelen servirse de sistemas basados en la nocin se
inteligencia artfcial (IA) que adoptan caracterstcas propias de la inteligencia humana. El campo de la IA incluye varios
subcampos: la robtca ( rea de la IA donde mquinas ejecutan tareas complejas, rutnarias o tediosas); los sistemas de
visin ( que dotan de vista a robots y otros dispositvos, con lo cual son capaces de almacenar y procesar imgenes
visuales); el procesamiento del lenguaje natural (que implica la facultad de las computadoras para comprender y
responder a rdenes orales o escritas en ingls, espaol u otros idiomas); los sistemas de aprendizaje ( que habilitan a las
computadoras para aprender de la experiencia o de sus errores); y las redes neuronales (rama de la IA que permite a las
computadoras reconocer patrones o tendencias y actuar en consecuencia).
Los sistemas expertos facultan a las computadoras para hacer sugerencias y proceder a la manera de expertos en un
campo en partcular. Permiten a las organizaciones proveerse de y utlizar el saber de expertos y especialistas. Son
aplicables a casi cualquier campo o disciplina.

Desarrollo de sistemas

El desarrollo de sistemas es la actvidad destnada a crear sistemas o a modifcar los ya existentes en uso en las empresas. Es
una tarea sumamente compleja y difcil.
Sus pasos son:

Investgacin y anlisis de sistemas: El objetvo de la investgacin de sistemas es obtener un conocimiento claro del
problema por resolver o de la oportunidad por aprovechar. El anlisis de sistemas consiste en defnir los problemas y
oportunidades que el sistema existente ofrece.
Diseo, implementacin y mantenimiento y revisin de sistemas: El diseo de sistemas es la determinacin del modo en
que operar el nuevo sistema para satsfacer las necesidades de la empresa defnidas durante el anlisis de sistemas. La
implementacin de sistemas es la creacin o adquisicin de los diversos componentes de sistemas (hardware, sofware,
bases de datos, etc.) defnidos en el paso de diseo, su respectvo montaje y puesta en operacin del nuevo sistema. El
mantenimiento y revisin de sistemas es la inspeccin y modifcacin del sistema para que siga satsfaciendo las
cambiantes necesidades de la empresa.

CAPACITACIN EN SISTEMAS COMPUTACIONALES Y DE INFORMACIN

Para poder emplear sistemas de informacin es preciso capacitarse en sistemas.

-La capacitacin computacional es el conocimiento de los sistemas y equipo de computacin y su funcionamiento. -La
capacitacin en sistemas de informacin es el conocimiento del uso que individuos, grupos y organizaciones hacen de
datos e informacin.
Saber cmo poner en funcionamiento TPSs, MISs, DSSs y sistemas expertos para cumplir las metas de una organizacin es
uno de los aspectos esenciales de la capacitacin en sistemas de informacin.



Sistemas de procesamiento de transacciones

Toda organizacin tene sistemas de procesamiento de transacciones (TPS) manuales y automtcos que procesan los
datos detallados necesarios para actualizar registros referentes a las operaciones de negocios esenciales de la
organizacin. Las entradas a estos sistemas incluyen transacciones, que son operaciones de negocios bsicas tales como
pedidos de clientes, solicitudes de compras, recepciones, tarjetas de registro de tempos, facturas, etc.
Los TPS son la base de los dems sistemas. En la mayor parte de las organizaciones dan soporte a las actvidades rutnarias,
todos los das, que ocurren en el curso normal de los negocios y que ayudan a una compaa a aadir valor a sus
productos y servicios.

1)Mtodos tradicionales del procesamiento de transacciones:

-Sistemas de procesamiento por lotes: En los inicios, las transacciones de negocio se acumulaban por un tempo y se
preparaban para procesarse como una sola unidad o lote. La caracterstca esencial de un sistema de procesamiento por
lotes es que se produce alguna demora entre el momento en que ocurre el acto y el posterior procesamiento de la
transaccin relacionada para actualizar los registros de la organizacin.
-Procesamiento de transacciones en lnea(OLTP): En la actualidad, cada transaccin se procesa de inmediato. Sin la demora
de acumular las transacciones en un lote. Tan pronto como se cuenta con la informacin de entrada, un programa de
computacin realiza el procesamiento necesario y actualiza los registros implicados en esa transaccin individual. Los
datos en un sistema de lnea en cualquier momentos presentan la situacin actual.
-Entrada en lnea con procesamiento retardado: es un intermedio entre los procesamientos por lotes y en lnea. Los
pedidos o las transacciones se introducen al sistema de computacin al momento que ocurren, pero no se procesan de
inmediato.
Aunque exista la tecnologa para ejecutar las aplicaciones de un TPS mediante el procesamiento en lnea, no se realiza para
todas las aplicaciones. En muchos casos el procesamiento por lotes es mas conveniente y efectvo en cuanto a costos.



2)Objetvos tradicionales del procesamiento de transacciones:

Las compaas esperan que sus TPS logren varios objetvos especfcos:

-Procesar datos generados por las transacciones y que se relacionen con ellas.
-Mantener un alto grado de exacttud.
-Asegurar la integridad y la exacttud de los datos y la informacin.
-Elaborar documentos e informes oportunos.
-Aumentar la efciencia de la mano de obra.
-Ayudar a proporcionar mayores y mejores servicios.
-Ayudar a crear y mantener la lealtad del cliente.
-Lograr una ventaja compettva.

3)Actvidades del procesamiento de transacciones

Los TPS capturan y procesan datos que describen transacciones de negocios fundamentales. Los datos de negocios pasan a
travs de un ciclo de procesamiento de transacciones que consta de recopilacin, edicin, correccin, manipulacin y
almacenamiento de datos, y elaboracin de documentos.

Recopilacin de datos: Proceso de capturar y recopilar todos los datos necesarios para completar las transacciones. En
algunos casos se puede hacer manualmente; en otros se automatza mediante dispositvos de entrada especiales.
Edicin de datos: Proceso de verifcar los datos para comprobar su validez e integridad.
Correccin de datos: implica volver a introducir, mediante el teclado o el escner los datos mal capturados que se
localizaron durante la edicin de datos.
Manipulacin de datos: Proceso de realizar clculos y otras transformaciones de los datos que tenen relacin con
transacciones de negocios. La manipulacin incluye clasifcar los datos, reunirlos por categoras, realizar clculos, etc.
Almacenamiento de datos: Incluye actualizar una o ms bases de datos con nuevas transacciones.
Elaboracin de documentos: Proceso de elaborar registros e informes de salida. Pueden ser informes en copias impresas en
papel o pueden mostrarse en las pantallas de las computadoras(copia visual).

4) Temas de control y administracin:

-Planeacin de la reanudacin de los negocios de la empresa: Proceso de prever y prepararse para desastres. Se centra
principalmente en dos consideraciones: preservar la integridad de la informacin corporatva y mantener operando el
sistema de informacin hasta que puedan reanudarse la operaciones normales. Los administradores de los SI deben
realizar de vez en cuando, sin previo aviso, pruebas de desastres para asegurarse de que el plan para desastres es sea
efectvo.

-Recuperacin de desastres: Puesta en prctca del plan de reanudacin de los negocios de la empresa.
Las principales herramientas utlizadas para la planeacin y la recuperacin de desastres implican la creacin de respaldos
para el hardware, el sofware y las bases de datos, las telecomunicaciones y el personal.

-Auditoria del sistema de procesamiento de transacciones: examen del TPS para intentar de responder a tres preguntas
bsicas: Satsface el sistema las necesidades de la empresa por las que se puso en prctca? Que procedimientos y
controles se han establecido? Se estn utlizando de forma apropiada estos procedimientos y controles?. Existen dos
tpos de auditoras: la interna la realizan los empleados de la organizacin ; la externa la llevan a cabo organizaciones o
compaas de contadores y personas no relacionadas con la organizacin. El auditor inspecciona todos los programas,
documentacin, tcnicas de control, el plan de desastres, y muchas otras cosas ms.

Aplicaciones tradicionales del procesamiento de transacciones

1) Sistemas de procesamiento de pedidos: Sistemas que procesan lo siguiente:

-Captura de pedidos: Sistema que captura los datos bsicos necesarios para procesar el pedido de un cliente. Una vez que
se introduce y acepta el pedido, se convierte en un pedido abierto.
-Confguracin de las ventas: Sistema que asegura que los productos y servicios ordenados sean sufcientes para lograr los
objetvos del cliente, adems de asegurar que operarn juntos en forma satsfactoria.
-Planeacin de embarques: Sistema que determina cuales pedidos abiertos se surtrn y desde que lugar se embarcaran.
-Ejecucin de embarques: Sistema que coordina el fujo de salida de todos los productos y bienes de la organizacin con el
objetvo de entregar a los clientes productos de calidad y a tempo.
-Control de inventarios: Sistema que actualiza los registros computarizados de inventarios, para que presenten la cantdad
exacta existente de cada unidad donde se mantenen existencias.
-Facturacin: Las facturas de los clientes se basan en registros recibidos del sistema de procesamiento de transacciones de
ejecucin de embarques. Son la salida del sistema de facturacin y refejan el valor de la factura actual as como que
productos compr el cliente.
-Interaccin con el cliente: Sistema que supervisa y lleva el control de cada interaccin de un cliente con la compaa. -
Determinacin de rutas y planifcacin de horarios: El sistema de determinacin de rutas determina la mejor forma de
llevar los bienes y productos de una localidad a otra. El sistema de planifcacin de horarios determina el mejor momento
para entregar bienes y servicios.

2) Sistemas de compras: Sistemas que incluyen:

-Control de inventarios: dem sistema anterior.
-Procesamiento de pedidos de compras: Sistema que ayuda a los departamentos de compras a completar sus transacciones
en forma rpida y efciente.
-Recepcin: Sistema que crea un registro de las recepciones esperadas y las reales. Se hace cargo de todos los artculos que
llegan, su inspeccin y envo al personal o a los departamentos que lo solicitaron.
-Cuentas por pagar: Sistema que incrementa el control de la organizacin sobre las compras, mejora el fujo de efectvo,
aumenta la rentabilidad y proporciona la administracin ms efectva de los pasivos circulantes.

3) Sistemas de contabilidad: Sistemas que incluyen:

-Presupuesto: El presupuesto es el plan fnanciero que identfca las partdas y los importes que la organizacin estma
gastar. El sistema de procesamiento de transacciones de presupuesto automatza muchas de las tareas requeridas para
acumular datos del presupuesto, distribuirlo a los usuarios y consolidar los presupuestos preparados.
-Cuentas por cobrar: Sistema que administra el fujo de efectvo de la compaa mediante el mantenimiento del control del
dinero adeudado a la empresa por cargos de bienes vendidos y servicios prestados.
-Nminas: Las dos salidas principales del sistema de nminas son el cheque de nminas y el taln, que se distribuyen a los
empleados; y el registro de nminas, que es un informe breve de todas las transacciones de nminas.
-Administracin de actvos: Sistema que controla las inversiones en equipos de capital y administra la depreciacin para
obtener los mximos benefcios fscales.
-Libro mayor general: Sistema que produce una relacin detallada de transacciones de negocios, diseado para automatzar
la elaboracin de informes fnancieros y la captura de datos.

Planeacin de recursos de la empresa (ERP)

Un sofware ERP es una aplicacin de gestn empresarial que da soporte a las distntas reas funcionales de la empresa.
Tpicamente manejan la produccin, logstca, distribucin, inventario, envos, facturas y contabilidad de la compaa. Sin
embargo, puede intervenir en el control de muchas actvidades de negocios como ventas, entregas, pagos, produccin,
administracin de inventarios, calidad de administracin y la administracin de recursos humanos.
El elemento fundamental para la ERP es la supervisin en tempo real de las funciones de la empresa. Esto permite el
anlisis en tempo real de de temas bsicos como son la calidad, disponibilidad, satsfaccin del cliente, desempeo y
rentabilidad.
Los sistemas ERP se adaptan a las formas diferentes en que cada compaa maneja sus negocios al proporcionar muchas
ms funciones de las que podra llegar a necesitar una empresa o incluyendo herramientas de adaptacin que les
permitan a las empresas perfeccionar lo que para stas ya es un buen ajuste.

Ventajas:

-Eliminacin de sistemas inefcientes. -Proporcionar
mejores procesos de trabajo -Mejoramiento del
acceso a los datos.
-Mejorar la infraestructura de la tecnologa.

Desventajas:

-Requiere tempo.
-Es complicado y costoso de poner en marcha.

UNIDAD N 2
EL PARADIGMA DE LA ORIENTACIN A OBJETOS

La complejidad innata del sofware

Es una propiedad esencial.

Se debe a:

La complejidad del dominio del problema: Surge de la gran difcultad que tenen los usuarios para expresar con precisin
sus necesidades en una forma que los desarrolladores puedan entender.

La difcultad de gestonar el proceso de desarrollo: La fundamental tarea de los desarrolladores es dar vida a un sofware
simple que disminuya esa complejidad externa. Se hace lo posible por escribir menos cdigo mediante algn mecanismo
ingenioso y as tambin se reutliza cdigos ya existentes.

La fexibilidad que se puede alcanzar a travs del sofware: Cada desarrollador tende a construir por s mismo prctcamente
todos los bloques fundamentales. Esto hace que la industria del sofware sea muy fexible pero a la vez muy laboriosa.

Los problemas de caracterizar el comportamiento de sistemas discretos: Los desarrolladores deben intentar disear los
sistemas con una separacin de intereses, de forma que el comportamiento de una parte del sistema tenga mnimo
impacto en el comportamiento de otra parte del mismo.

La principal consecuencia de la complejidad es que cunto ms complejo sea el sofware ms abierto est al
derrumbamiento total.

El papel de la descomposicin

Cuando se disea un sistema de sofware complejo, es esencial descomponerlo en partes ms y ms pequeas, cada una de
las cuales se puede refnar entonces de forma independiente.

Descomposicin algortmica: Es la forma de descomposicin sustentada por el anlisis y diseo estructurado. En este caso
se divide el sistema en elementos funcionales relacionados estructuralmente entre s (pasos). Esta visin enfatza el orden
de los eventos.

Descomposicin orientada a objetos: En este caso la descomposicin consiste en determinar un conjunto de agentes
autnomos (objetos) que se derivan directamente de dominio del problema, que colaboran para llevar a cabo algn
comportamiento de nivel superior. Esta visin resalta los agentes que causan acciones o son sujetos de estas acciones.

La Crisis del Sofware

- La Planifcacin y estmacin de costos son frecuentemente muy imprecisas.
- La productvidad de la comunidad del sofware no se corresponde con la demanda de sus servicios.
- La calidad del sofware no llega a ser a veces ni aceptable.
- En algunos casos los responsables del desarrollo de sofware han sido ejecutvos de nivel medio y alto sin conocimientos
de sofware, en la creencia de que un buen gestor puede gestonar cualquier proyecto.
-Los trabajadores del sofware no siempre han tenido un entrenamiento formal en las nuevas tcnicas de desarrollo de
sofware.
-Todos nos resistmos al cambio.

Debido a esta crisis se necesitaba una mejora en:

- Complejidad
- Capacidad de diseo
- Flexibilidad
- Rapidez de desarrollo
- Relacin
- Facilidad de modifcacin
- Confabilidad

As se da una revolucin en la industria del sofware, logrando lo siguiente:

Tendencia actual en el Sofware:
- Los computadores son ms potentes cada ao.
- Los usuarios por lo tanto, esperan ms de ellos.
- Queremos sofware que est ms adaptado a nuestras necesidades.

Construccin de Sistemas
- Ms Complejos
- Ms Grandes
- En menos tempo
- A menor costo
- Ms Confables

Cmo logramos manejar la complejidad del Sofware, reducir los costos de su construccin, y aumentar la velocidad del
desarrollo?

-Construyendo el Sofware partr de componentes reusables.
-Ensamblando el Sofware a partr de componentes de muchos proveedores.
-Creando una enorme biblioteca de componentes.

As aparece el paradigma orientado a objetos.

Paradigma

Paradigma es una forma de ver y entender el mundo, es una forma de abstraerlo dentro de nuestra cabeza. Es un
conjunto de teoras, estndares y mtodos que juntos representan una forma de organizar el conocimiento, es decir, una
forma de ver el mundo.



Paradigma de programacin

Un paradigma de programacin representa un enfoque partcular o flosofa para la construccin del sofware. Es una forma
de ver y entender las cosas. Hay diferentes tpos de paradigmas de programacin:

-Orientado a procedimientos: Algoritmos.
-Orientado a objetos: Clases y objetos.
-Orientados a lgica: Objetvos, a menudo expresados como clculo de predicados.
-Orientados a reglas: Reglas si-entonces (if-then).
-Orientados a restricciones: Relaciones invariantes.

No hay un estlo de programacin que sea el mejor de todos, sino que cada uno tene sus ventajas y desventajas. Se debe
saber usar cada uno segn la situacin que se nos presenta.

Programacin orientada a objetos (POO)

La POO es un paradigma de programacin que usa objetos y sus interacciones para disear aplicaciones y programas de
computadora.
Est basado en varias tcnicas, incluyendo herencia, modularidad, polimorfsmo y encapsulamiento.
Considera al mundo como un conjunto de entdades u objetos que estn relacionados y se comunican entre ellos, para
realizar tareas. Esto permite hacer los programas y mdulos ms fciles de escribir, mantener y reutlizar.

Elementos del Modelo de Objetos

El modelo de objetos abarca los principios de abstraccin, encapsulacin, modularidad, jerarqua, tpos, concurrencia y
persistencia. Lo importante del modelo de objetos es el hecho de conjugar todos estos elementos de forma sinrgica.

Abstraccin: denota las caracterstcas esenciales de un objeto que lo distnguen de todos los dems tpos de objeto
y proporciona fronteras conceptuales defnidas respecto al punto de vista del observador. Se centra en la visin
externa de un objeto.
Encapsulamiento: Es el proceso de almacenar en un mismo compartmiento (una caja negra) los elementos de una
Abstraccin (toda la informacin relacionada con un objeto) que consttuyen su estructura y su Comportamiento.
Esta informacin permanece oculta tanto para los usuarios como para otros objetos Y puede ser accedida solo
mediante la ejecucin de los mtodos adecuados. Separa la abstraccin de su implementacin.
Modularidad: es la propiedad que tene un sistema que ha sido descompuesto en un conjunto de mdulos
coherentes e independientes.
Jerarqua: es una clasifcacin u ordenacin de abstracciones.
Herencia: es un mecanismo para expresar similaridad entre clases, simplifcando defniciones de las clases similares
previamente defnidas. La herencia permite crear nuevas clases llamadas subclases agregando solamente las
diferencias con la clase. En otras palabras la herencia es una partcin en subclases ms especializadas.

Hay tres elementos secundarios:

Tipos (tpifcacin): Es la defnicin precisa de un objeto de tal forma que objetos de diferentes tpos no puedan ser
intercambiados o, cuando mucho, puedan intercambiarse de manera muy restringida.

-Polimorfsmo: Representa un concepto de teora de tpos en el que solo un nombre puede denotar objetos de muchas
clases diferentes que se relacionan por alguna superclase comn. Lo contrario se denomina monomorfsmo.

Concurrencia: permite a diferentes objetos actuar al mismo tempo. Permite distnguir un objeto actvo de uno que
no lo est.
Persistencia: conserva el estado de un objeto en el tempo y en el espacio.


OBJETOS

Un objeto modela alguna parte de la realidad. Es algo que existe en el tempo y el espacio. Se corresponde con los objetos
reales del mundo que nos rodea. Representa un elemento, unidad o entdad individual e identfcable, real o abstracta, con
un papel bien defnido.
Es la abstraccin de alguna cosa en el dominio del problema que refeja la capacidad de un sistema de alcanzar informacin
alrededor de l.
Es una instancia de una clase. Son entdades provistas de atributos y de mtodos. Un objeto contene toda la informacin
que permite defnirlo e identfcarlo frente a otros objetos pertenecientes a otras clases, al poder tener valores bien
diferenciados en sus atributos.

Los objetos son entdades del mundo real que combinan estado, comportamiento e Identdad.

Estado
El estado de un objeto abarca todas las propiedades (normalmente esttcas) del mismo mas los valores actuales
(normalmente dinmicos) de cada una de esas propiedades.

Comportamiento
El comportamiento es cmo acta y reacciona un objeto, en trminos de sus cambios de estado y paso de mensajes.
El comportamiento de un objeto representa su actvidad visible exteriormente.
Est defnido por los mtodos con que puede operar dicho objeto, es decir, qu operaciones se pueden realizar con l. Las
responsabilidades de un objeto son todos los servicios que proporciona para todos los contratos que soporta.

Identdad
La identdad es aquella propiedad de un objeto que lo distngue de todos los dems objetos dicho con otras palabras, es su
identfcador (concepto anlogo al de identfcador de una variable o una constante).

Relaciones entre objetos

Los objetos contribuyen al comportamiento de un sistema colaborando con otros. Esto se logra a travs de las relaciones.
Hay dos tpos de relaciones:

Enlace: es una conexin entre objetos. Un objeto colabora con otros a travs de sus enlaces.
Agregacin: la agregacin denota una jerarqua todo/parte, con la capacidad de ir desde el todo hasta sus partes.

CLASES

Las clases son los bloques de construccin ms importantes de cualquier sistema orientado a objetos.
Una clase es un conjunto de objetos que comparten una estructura comn y un comportamiento comn. Una clase consta
de mtodos y atributos que resumen las caracterstcas comunes de los objetos. Puede implementar una o ms interfaces.
No es un objeto individual sino que representa un conjunto de objetos.
Los conceptos de clase y objetos estn entretejidos. Sin embargo, existen diferencias importantes entre ambos trminos.
Un objeto es una entdad concreta que existe en el tempo y en el espacio; una clase representa slo una abstraccin,
como si dijsemos la esencia de un objeto. Un objeto es una instancia de una clase.

Vistas de una clase

Una clase posee dos vistas:

Interfaz: proporciona su vista externa. Enfatza la abstraccin y oculta su estructura y secretos de su comportamiento.
Se compone principalmente de las declaraciones de todas las operaciones aplicables a instancias de la clase (objetos), pero
tambin puede incluir la declaracin de constantes, variables y excepciones que se necesiten para completar la abstraccin.

Implementacin: es su vista interna. Engloba los secretos de su comportamiento. Se compone de la implementacin de
todas las operaciones defnidas en la interfaz.

Estructura de una clase

UML proporciona la siguiente representacin grfca:


NOMBRE


ATRIBUTOS

MTODOS

Nombre: cada clase ha de tener un nombre que la distnga de otras clases. Se distnguen entre nombres simples y
califcados. Los primeros son sencillamente una cadena y el segundo consta del nombre de la clase precedido por el
paquete, es decir, la ubicacin. El nombre de la clase debe ser nico en el paquete.
Atributos: Es una propiedad de una clase, que se identfca con un nombre. Una clase puede tener ninguno o varios
atributos. Un atributo puede ser de slo lectura o esttco, es decir, compartdo por todos los objetos de la clase.
Mtodos: Es un algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecucin se desencadena tras la
recepcin de un "mensaje". Desde el punto de vista del comportamiento, es lo que el objeto puede hacer.


Responsabilidades

Una responsabilidad es un contrato o una obligacin de una clase, es decir lo que debe hacer. Una clase puede tener
cualquier nmero de responsabilidades, aunque en la prctca cada clase bien estructurada tene al menos una
responsabilidad y a lo sumo unas pocas. Las responsabilidades se enuncian como texto libre: una frase, una sentencia o,
como mucho, un prrafo corto.

Mensajes

Los objetos tenen la posibilidad de actuar; la accin sucede cuando un objeto recibe un mensaje, que es, una solicitud
que pide al objeto que se comporte de alguna forma. Cuando se ejecutan los programas orientados a objetos, los objetos
reciben, interpretan y responden a mensajes procedentes de otros objetos.
Los mensajes que reciben el objeto son los nicos conductos que conectan al objeto con el mundo exterior.



DIAGRAMA DE CLASES

Muestran las diferentes clases que componen un sistema y cmo se relacionan unas con otras. Se dice que los diagramas
de clases son diagramas esttcos porque muestran las clases, junto con sus mtodos y atributos, as como las
relaciones esttcas entre ellas: qu clases conocen a qu otras clases o qu clases son parte de otras clases, pero no
muestran los mtodos mediante los que se invocan entre ellas. Adems de mostrar la vista esttca muestra una vista
externa del sistema.
Mediante el diagrama de clases identfcamos el dominio (lo que el sistema tendr que administrar).

CLASIFICACION: de Estructura, Esttco, Lgico.
USO:
Explorar conceptos del dominio.
Analizar Requerimientos.
Mostrar el diseo detallado del SW Orientado a Objetos.
Muestra: un conjunto de clases, interfaces, colaboraciones y sus relaciones.
Contene comnmente:
Clases
Interfaces (tpo especial de clases)
Relaciones

Clases y objetos candidatos

Las clases y objetos candidatos provienen de las siguientes fuentes:

Cosas tangibles (producto, herramienta, automvil)
Lugares (Barrio, Provincia, Pas, Zona)
Transacciones o operaciones (Venta, Pago, Pedido)
Hechos o eventos (Reserva, Vuelo, Accidente, Incidente)
Roles de personas (Proveedor, Cliente, Empleado)
Contenedores de otras cosas (Almacn)
Catlogos (catalogo de productos)
Otras organizaciones u reas (Ministerio, Juzgado, dpto. de ventas)


Relaciones entre clases

Existen distntos tpos de relaciones:
Asociacin: Una asociacin es una relacin estructural que especifca que los objetos de una clase estn
conectados con los objetos de otra. Una asociacin slo denota una dependencia semntca entre dos clases pero
no establece la forma exacta en que una clase se relaciona con la otra.
Dada una asociacin entre dos clases se puede navegar desde un objeto de
una clase hasta un objeto de la otra.
Grfcamente, una asociacin se representa como una lnea contnua que conecta la misma o diferentes clases.


-Navegabilidad: la direccin de la navegacin indica qu clase es la que contene la referencia hacia la otra (determina
quin conoce a quin).
-Multplicidad: seala cuntos objetos pueden conectarse a travs de una instancia de la asociacin. Se puede indicar una
multplicidad de exactamente uno (1), cero (0), muchos (*), uno o ms (1..*) o un valor exacto (por ejemplo, 3). La
multplicidad se indica en el extremo que corresponde a la navegacin.


Agregacin: el elemento destno es parte del elemento de origen. Representa una relacin entre un todo y sus
partes.

Generalizacin: es una relacin en la que una clase comparte la estructura y/o el comportamiento defnidos en
una (herencia simple) o ms clases (herencia mltple). El elemento origen es una especializacin del elemento
destno.



Dependencia: el elemento origen depende del elemento destno y puede verse afectado por los cambios en l.















Unidad N 3: El modelo de procesos de negocio
Nuevo paradigma
En base a la problemtca en la que se ven inmersas las empresas hoy, se plantea un nuevo paradigma para su gestn, la
administracin por procesos.

Empresas de ayer y de hoy





el

El nuevo paradigma nos lleva a la innovacin y transformacin operacional, as como al uso de nuevas herramientas y
tecnologas.

Ventajas:

-Mejora de la atencin y servicio al cliente.
-Disminucin drstca del tempo de cada proceso.
-La transformacin del entorno de trabajo, de reactvo a proactvo.
-Mejora de la gestn y optmizacin de procesos.

Procesos de negocio

Proceso: Conjunto de actvidades relacionadas lgicamente, que toman uno o ms tpos de entradas (inputs) y crean uno o
ms resultados (outputs) que producen un valor para la organizacin, sus inversores y/o sus clientes.

Caracterstcas de un proceso:

-Complejos
-Dinmicos
-Distribuidos y partcularizados
-En algunos casos, de duracin prolongada (pueden durar incluso meses o aos)
-A veces automatzados, aunque sea parcialmente
Empresas de ayer Empresas de hoy
El empleado es el problema. El proceso es el problema
Evaluar al individuo Evaluar el proceso
Controlar a los empleados Desarrollar a las personas
Gerentes - Jefes Lderes
Orientacin a las tareas
Orientacin al cliente y a los
Procesos
Enfoque funcional. (Finanzas,
Compras...)

Enfoque sobre procesos
Organizacin reactva Organizacin proactva
Decisiones basadas
en la experiencia
Decisiones basadas
en anlisis de datos
-Dependen de la inteligencia y el juicio de las personas -Difciles
de visibilizar

Proceso de negocio: Es una secuencia especfca de actvidades de trabajo a travs del tempo y del espacio, con un inicio,
un fnal y unas entradas para producir una salida especfca para un cliente o un mercado en partcular.
Puede afectar a ms de una unidad organizacional.
Tiene un impacto horizontal en la organizacin.
Crea algn tpo de valor para el cliente. Los clientes pueden ser externos o internos

Caracterstcas de un proceso de negocio:

-Un proceso de negocio incorpora entradas que se transforman en salidas.
-Lleva asociadas actvidades secuenciadas y ordenadas en el tempo y localizadas en un lugar.
-Estas tareas sern realizadas por personas o por un sistema aplicando reglas de decisin que tendrn como resultado el
producto o servicio fnal, otro proceso o un subproceso.
-Existe siempre un agente que debe ser satsfecho, cliente, proveedor, empleado, con la entrega de un determinado servicio
o producto.
-Este servicio o producto debe proporcionar un valor aadido al agente. -Necesita
de una organizacin para desarrollarse.
Tipos de procesos de negocio:

-Estratgicos, son aquellos que orientan la direccin de una organizacin.
-Centrales, son aquellos que consttuyen el ncleo de actvidad de la organizacin.
-De soporte, son aquellos que apoyan a los centrales en su desarrollo.

Importancia de los procesos

Sin un proceso defnido, no puedo saber cun bien o mal se encuentra mi organizacin, ni identfcar a tempo desvos y
problemas.




En los procesos de negocio, la entrada la consttuyen los requerimientos de un cliente y las salidas se corresponden con el
producto o servicio ofrecido


Modelado de procesos de negocio

Concepto de modelo: simplifcacin de la realidad. Es una representacin a bajo costo de la realidad. Construimos
modelos para poder comprender mejor el sistema que estamos desarrollando.

Modelar el proceso de negocio: Modelar el proceso de negocio es una parte esencial de cualquier proceso de
desarrollo de sofware. Permite al analista capturar el esquema general y los procedimientos que gobiernan el negocio.
Pro
du
cto

Requeri
P r o c e s o

d e

N e g o c i o

Este modelo provee una descripcin de donde se va a ajustar el sistema de sofware considerado dentro de la estructura
organizacional y de las actvidades habituales.

Defne los siguientes elementos:

-El objetvo o el motvo del proceso;
-Las entradas especfcas;
-Las salidas especfcas;
-Los recursos consumidos;
-La secuencia de las actvidades; y -Los
eventos que dirigen el proceso.




Los procesos de negocio emplean informacin para adaptar o completar sus actvidades. La informacin, a diferencia de
los recursos, no se consume en los procesos, sino que se usa como parte del proceso de transformacin. El conector
supply indica que la informacin u objeto conectado al proceso no se gasta en la fase de procesamiento.

Recurso: Un recurso es una entrada para un proceso de negocio; se consume durante el procesamiento. Un conector
input destaca que el objeto o recurso conectado se consume durante el procesamiento.

Eventos: Un evento es la recepcin de algn objeto, un momento o fecha cumplidos, una notfcacin o cualquier otro
disparador que inicie un proceso de negocio. Se puede consumir y transformar, o simplemente actuar como un catalizador.

Salidas: Un proceso de negocio tpicamente producir una o ms salidas de valor para el negocio, para uso interno o para
satsfacer requisitos externos. Una salida puede ser un objeto fsico, una transformacin de recursos crudos con un nuevo
ordenamiento o un resultado fnal de un proceso. Una salida de un proceso de negocio puede alimentar a otro. Un
conector output indica que el proceso de negocio produce algn objeto que es de valor para la organizacin.

Objetvos: Un proceso de negocio tene algn objetvo bien defnido. Es la razn por la que la organizacin realiza su trabajo.
Un conector goal indica que el objeto adjunto al proceso describe el objetvo del proceso.

Trazabilidad: Defne la forma en la que un proceso de negocio dado se implementara en el sistema propuesto.

Objetvos del modelado

-Los modelos ayudan a visualizar cmo es que queremos que sea un sistema.
-Los modelos permiten especifcar la estructura o el comportamiento de un sistema.
-Los modelos proporcionan plantllas que sirven de gua en la construccin del sofware. -Los
modelos documentan las decisiones que se han adoptado.



UML - Lenguaje de Modelado Unifcado

Es un lenguaje de modelado visual, de propsito general, usado para la visualizacin, especifcacin, construccin y
documentacin de sistemas Orientados a Objetos. El Lenguaje Unifcado de Modelado (UML) es un lenguaje de modelado
y no un mtodo o un proceso. Est compuesto por una notacin muy especfca y por las reglas semntcas relacionadas
para la construccin de sistemas de sofware. En s mismo no prescribe ni aconseja como usar esta notacin.

Vista Externa

Se utlizar el esquema propuesto para representar cada uno de los procesos de negocio esenciales.



Diagrama de Actvidad

Concepto: Los diagramas de actvidad son uno de los cinco tpos de diagramas de UML que se utlizan para el modelado de
los aspectos dinmicos de los sistemas. Permite modelar la vista interna del proceso de negocio, defniendo las principales
actvidades que se ejecutan y la secuencia en que se realizan las mismas.
Muchas veces incluyen los objetos que van sufriendo transformaciones a lo largo de la ejecucin del proceso.

Elementos de una diagrama de actvidad:

Actvidad: Redes de nodos conectados por extremos. La notacin para una actvidad es una combinacin de los nodos y
arcos que contene, ms el nombre (en infnitvo) y sus restricciones.




Los extremos representan fujos por la actvidad. Existen dos categoras de extremos: fujos de control y fujos de objetos.
Las actvidades pueden tener precondiciones y postcondiciones (restricciones). Las precondiciones deben ser ciertas antes
de que la actvidad pueda empezar y las postcondiciones sern ciertas despus de que la actvidad haya terminado. Las
acciones dentro de la actvidad pueden tener tambin sus propias precondiciones y postcondiciones locales.
Las actvidades empiezan a menudo con un solo nodo de control, el nodo inicial, que indica el lugar donde empezar la
ejecucin cuando se invoca la actvidad. Uno o ms nodos fnales indican los lugares donde termina la actvidad.


Accin: Es un nodo en el diagrama de actvidad, en el cual se puede colocar el nombre de la accin o una expresin. Es
un nodo de actvidad que no puede descomponerse ms. Las acciones son atmicas, lo que signifca que pueden
ocurrir eventos, pero el comportamiento interno de la misma no es visible. No se puede ejecutar una parte de una
accin; o se ejecuta completamente o no se ejecuta. Pueden tener precondiciones o postcondiciones locales.

Nodos de accin: Se ejecutan cuando se satsfacen todas las precondiciones locales del nodo de accin. Cuando el
nodo ha terminado de ejecutarse se comprueba la postcondicin local.

Existen cuatro tpos de nodos de accin:

Sintaxis Nombre Semntca

Alguna accin
Nodo de accin
llamada
de Invoca una actvidad, comportamiento u operacin.

NombreSeal

Enviar seal
Enva una seal: Una seal representa informacin que se
pasa asncronamente entre objetos.
Es una accin que crea una seal a partr de sus entradas
y la transmite a su objeto receptor.


AceptarEvento



Nodo de accin
aceptar evento
de Acepta un evento: Es una accin que espera por la
ocurrencia de un evento que satsfaga una condicin. Si la
accin no tene un arco que ingrese, luego la accin
comienza cuando se actve la actvidad que la contene. La
accin, sin arcos que ingresen, no fnaliza luego de
aceptar un evento y producir un valor de salida,
permanece esperando por el prximo evento.


Expresin de tempo
Nodo de accin
aceptar evento
tempo.
de
de
Acepta un evento de tempo: responde a tempo. Genera
eventos de tempo segn su expresin de tempo.

Se espera una seal Se enva una seal de confirmacin
De pedido de pago de pago





La aceptacin de la confrmacin de pago slo se puede aceptar luego que se solicit el pago.


Nodos de control


Los nodos de control gestonan el fujo de control dentro de una actvidad.

Sintaxis Nombre Semntca
Nodo inicial Indica donde empieza el fujo cuando se invoca una actvidad.
Una actvidad puede tener ms de un nodo inicial. Estos nodos
no son obligatorios dado que existe otra forma de iniciar la
actvidad.

Nodo fnal
actvidad.
de Termina la actvidad. El nodo fnal de actvidad detene todos los
fujos dentro de una actvidad. Una actvidad puede tener
muchos nodos fnales de actvidad y el primero en actvarse
termina el resto de fujos y la propia actvidad.


Nodos de objeto

Representan instancias de un clasifcador o sus subclases. Los extremos de entrada y salida de los nodos de objeto son
fujos de objeto.
Los nodos de objeto actan como bufers, que son lugares en la actvidad donde pueden residir los tokens de objeto
mientras esperan a ser aceptados por otros nodos. Este tpo de nodo puede albergar un nmero infnito de tokens de
objeto.
Los nodos de objeto pueden tener un comportamiento de seleccin. Es un comportamiento anexado al nodo que
selecciona objetos de los extremos de entrada de acuerdo a algn criterio defnido por el modelador.
Los nodos de objetos pueden representar objetos en un estado determinado. Los estados de objetos referenciados por
nodos de objeto se pueden modelar con mquinas de estados.

Pins

Un pin es un nodo de objeto que representa una entrada o salida de una accin.
Los pins de entrada tenen exactamente un extremo de entrada y los pins de salida tenen exactamente un extremo de
salida.

Flujos de control

Cuando se completa una accin o un nodo de actvidad, el fujo de control pasa inmediatamente a la siguiente accin o
nodo de actvidad. Se especifca con fechas que muestran el camino de control de un nodo de actvidad o una accin al
siguiente. Se puede especifcar el inicio y la terminacin, ya que tene que empezar y parar en algn sito, a no ser que sea
un fujo infnito donde solo tendra inicio.

Flujos de objetos

Se pueden especifcar los objetos implicados en un diagrama de actvidades colocndolos en el diagrama, conectados con
una fecha a las acciones que los crean o los consumen. Esto se denomina fujo de objetos, porque representa el fujo de
un valor de objetos desde una accin hasta otra. Un fujo de objetos conlleva un fujo de control de forma implcita.

Partciones de actvidad

Una partcin es un agrupamiento de acciones que poseen ciertas caracterstcas en comn. Frecuentemente corresponden
a unidades organizacionales en un modelo de negocios.
Se pueden dividir las actvidades en partciones al utlizar lneas vertcales, horizontales o curvas. Cada partcin de
actvidad representa una agrupacin de alto nivel de acciones relacionadas. Pueden hacer que los diagramas de actvidad
sean mucho ms fciles de entender.
Algunas veces no es posible organizar los nodos en partciones vertcales u horizontales sin difcultar la lectura del
diagrama. En este caso se utlizan lneas curvas para crear partciones irregulares, o se podran indicar partciones al utlizar
texto.

Regiones de expansin y nodos de expansin

Frecuentemente, la misma operacin debe ejecutarse sobre todos los elementos de un conjunto.
Una regin de expansin representa un fragmento de un modelo de actvidades que se ejecutan sobre los elementos de
una lista o un conjunto. Se representa dibujando una lnea discontnua alrededor de una regin de un diagrama. Las
entradas a la regin y las salidas de ella son colecciones de valores.
Las colecciones de entrada y salida se representan como una fla de pequeos recuadros unidos y se las denomina nodos
de expansin. Un nodo de expansin es un nodo de objeto que representa una coleccin de objetos que fuyen en o fuera
de una regin de expansin. Esta regin se ejecuta una vez por elemento de entrada. Cuando un valor array llega a la
coleccin de entrada de una regin de expansin desde el resto del modelo de actvidades, aquel se divide en valores
individuales.
Cuando cada ejecucin de la regin de expansin termina, su valor de salir se introduce en un array en el mismo orden que
el valor de entrada correspondiente.
Podra haber uno o ms arrays de entrada y cero o ms arrays de salida.

Existen dos restricciones en los nodos de expansin:

El tpo de coleccin de salida debe coincidir con el tpo de la coleccin de entrada.
El tpo de objeto contenido en las colecciones de entrada salida deben ser iguales.

Toda regin de expansin tene un modo que determina el orden en el que procesa los elementos en su coleccin de
entrada. El modo puede ser:

Iteratvo: procesa cada elemento de la coleccin de entrada secuencialmente.
Paralelo: procesa cada elemento de la coleccin de entrada en paralelo
Flujo: procesa cada elemento de la coleccin de entrada a medida que llega al nodo.

Siempre debe especifcar explcitamente el modo. Por defecto ningn modo.

Conectores

Si encontrara una complejidad irreducible, puede utlizarlos para romper extremos largos que son difciles de seguir. Esto
puede simplifcar un diagrama de actvidad. Aunque se debe evitar utlizar conectores.
Para una actvidad dada cada conector de salida debe tener exactamente un conector entrante con la misma etqueta. Las
etquetas son identfcadoras para el conector.




Regiones interrumpibles de actvidad

Son regiones de una actvidad que se interrumpen cuando un token atraviesa un extremo que se interrumpe. Cuando la
regin se interrumpe, todo el fujo dentro de la regin se aborta inmediatamente.
Los extremos de interrupcin se dibujan como una fecha de zigzag o como una fecha normal con un icono de zigzag
dibujado sobre esta.


Gestn de excepciones

Si se detecta un error en una parte protegida de cdigo, se crea un objeto de excepcin y el fujo de control salta hasta un
manejador de excepcin que procesa el objeto de excepcin de alguna forma. El objeto de excepcin contene
informacin sobre el error que se puede utlizar por el manejador de excepcin. Este manejador puede terminar la
aplicacin o tratar de recuperarse. La informacin en el objeto de excepcin se guarda en un registro de error.

Un pin representa el resultado de un objeto de excepcin al notarlo con un pequeo triangulo equiltero.

Multdifusin y multreceptor

Se denomina multdifusin cuando un objeto se enva a mltples receptores.
Se denomina multreceptor cuando los objetos se reciben de mltples emisores.

Conjunto de parmetros

Son conjuntos de pins que permiten que una accin tenga conjuntos alternatvos de pin de entrada y salida. Los conjuntos
de parmetros de entrada contenen pins de entrada y los conjuntos de parmetros de salida contenen pins de salida. No
puede tener un conjunto mezclado de pins de entrada y de salida.


Aplicacin Prctca

Para modelar los procesos de negocio a partr de un caso de estudio planteado, deber desarrollar lo siguiente:

Listado de procesos de negocio
Vista externa de proceso de negocio
Vista interna del proceso de negocio, usando diagrama de actvidad



Listado de procesos de negocio

Lista de Procesos: Elaborar un listado con los procesos de negocio identfcados y a partr de ello evaluar cuales
consideramos oportuno modelar. Se pueden modelar todos o aquellos que se consideren ms relevantes.
Por cada proceso identfcado se defne el objetvo correspondiente.
Tambin puede identfcarse para cada proceso: partcipantes, formularios y/o documentacin involucrada, etc.
Nombre de Procesos: Podrn estar expresados en infnitvo o como sustantvo considerndose ambas formas
correctas.


Unidad N 4: Proceso de desarrollo de sofware

La construccin del sofware de computadora es un proceso iteratvo de aprendizaje y el resultado es una materializacin
del conocimiento recolectado, depurado y organizado conforme el proceso estuvo en ejecucin.

Un proceso de sofware es un marco de trabajo para las tareas que se requieren en la construccin de sofware de alta
calidad. ste defne el enfoque que se adopta mientras el sofware est en desarrollo.

La ingeniera de sofware es el establecimiento y uso de principios slidos de la ingeniera para obtener econmicamente
un sofware confable y que funcione de modo efciente en maquinas reales. Es la aplicacin de un enfoque sistemtco,
disciplinado y cuantfcable al desarrollo, operacin, y mantenimiento del sofware. Es importante porque ofrece
estabilidad, control y organizacin a una actvidad que puede volverse catca si no se controla. Es una tecnologa
estratfcada.

Capas de la ingeniera de sofware

La base que soporta la ingeniera de sofware es un enfoque en la calidad. Cualquier enfoque de la ingeniera, incluida la
ing. de sofware debe estar sustentado en un compromiso con la calidad, debido a que la calidad del producto obtenido
est fuertemente afectada por la calidad del proceso utlizado para producirlo.
El proceso defne un marco de trabajo que debe establecerse para la entrega efectva de la tecnologa de la ingeniera de
sofware. El proceso del sofware forma la base para el control de la gestn de los proyectos de sofware y establece el
contexto en el cual se aplican los mtodos tcnicos, se generan los productos del trabajo, se establecen los fundamentos,
se asegura la calidad, y el cambio se maneja de manera apropiada.
Los mtodos de la ingeniera de sofware proporcionan los como tcnicos para construir el sofware. Abarcan un amplio
espectro de tareas que incluyen la comunicacin, el anlisis de requisitos, el modelo del diseo, la construccin del
programa, la realizacin de pruebas y el soporte.
Las herramientas de la ingeniera del sofware proporcionan el soporte automtco para el proceso y los mtodos.
Combinacin de hardware, sofware y bases de datos.
Cuando las herramientas se integran de forma que la informacin que genera una la puede usar la otra, se dice que se ha
establecido un sistema para el soporte del desarrollo de sofware, denominado ingeniera del sofware asistdo por
computadora.

Marco de trabajo para el proceso



Un marco de trabajo establece la base para un proceso de sofware completo al identfcar un nmero de actvidades del
marco de trabajo aplicables a todos los proyectos de sofware. Adems abarca un conjunto de actvidades sombrilla (de
soporte) aplicables a lo largo del proceso del sofware. Cada actvidad dentro del marco contene un conjunto de acciones
de ingeniera del sofware. Cada accin la forman tareas de trabajo individuales que completa alguna parte del trabajo
implicado por la accin.

El siguiente marco genrico del proceso se puede aplicar en la mayora de los proyectos de sofware (actvidades genricas
del proceso):

Comunicacin: implica una intensa colaboracin y comunicacin con los clientes; abarca la investgacin de requisitos y
otras actvidades relacionadas.
Planeacin: establece un plan para el trabajo de la ingeniera del sofware. Describe las tareas tcnicas que deben
realizarse, los riesgos probables, los recursos que sern requeridos, los productos del trabajo que han de producirse y un
programa de trabajo.
Modelados: abarca la creacin de modelos que permite al desarrollador y al cliente entender mejor los requisitos del
sofware y el diseo que lograr satsfacerlos.
Construccin: combina la generacin del cdigo y la realizacin de pruebas necesarias para descubrir errores en el cdigo.
Despliegue: El sofware se entrega al cliente, quien evala el producto recibido y proporciona informacin basada en su
evaluacin.

Los detalles del proceso del sofware sern muy diferentes en cada caso, pero las actvidades permanecern iguales.
La actvidad de elaboracin del modelo se compone de dos acciones de la ingeniera de sofware: anlisis y diseo. El
anlisis es un conjunto de tareas que conducen a la elaboracin del modelo de anlisis y el diseo abarca tareas de trabajo
que crean un modelo de diseo.

Este marco de trabajo lo completa una serie de actvidades sombrillas:

-Seguimiento y control del proyecto de sofware -
Gestn del riesgo.
-Aseguramiento de la calidad del sofware. -
Revisiones tcnicas formales.
-Medicin.
-Gestn de la confguracin del sofware.
-Gestn de la reutlizacin.
-Preparacin y produccin del producto de trabajo.

La aplicacin de estos modelos prescriptvos intenta mejorar intenta mejorar la calidad del sistema, hacer que los
proyectos sean ms manejables, que las fechas de entrega y los costos sean ms predecibles, y guiar a los equipos de
ingenieros de sofware mientras realizan el trabajo que requiere construir un sistema.
En aos recientes se han propuesto modelos de proceso que subrayan la agilidad del proyecto y siguen un conjunto de
principios, los cuales conducen a un enfoque ms informal para el proceso sofware llamados modelos agiles del proceso.
stos son apropiados para muchos tpos de proyectos y son tles de manera partcular cuando se desarrollan aplicaciones
en la red.
Ambos enfoques de proceso tenen una meta comn: crear sofware de alta calidad que satsfaga las necesidades del
cliente, pero tenen perspectvas diferentes.

Patrones de proceso

Un patrn de proceso se defne como un mtodo consistente para describir una caracterstca importante del proceso de
sofware.

Plantlla para describir un proceso:

-Nombre de patrn: nombre signifcatvo que describa su funcin dentro del sofware.
-Propsito: Se describe con brevedad el objetvo del patrn. -Tipo: Se
especifca el tpo de patrn:

Patrones de una tarea: accin de la ingeniera de sofware.
Patrones de escenario: defnen una actvidad del marco de trabajo para el proceso.
Patrones de fase: defnen la secuencia de actvidades del marco de trabajo que ocurre junto con el proceso.

-Contexto inicial: Se describen las condiciones en las cuales se aplica el patrn.
-Problema: Se describe el problema que debe resolver el patrn.
-Solucin: Se describe la implementacin del patrn.
-Contexto resultante: Se describen las condiciones que habr una vez que el patrn haya sido implementado con xito.
-Patrones relacionados: Se proporciona una lista de todos los patrones de proceso directamente relacionados con este.
-Usos conocidos/Ejemplos: Se indican los ejemplos especfcos en los cuales el patrn es aplicable.

Los patrones de proceso proporcionan un mecanismo efectvo para describir cualquier proceso de sofware.

Paradigma

En la ingeniera de sofware un equipo de desarrollo debe seguir una estrategia de que acompae al proceso, los mtodos y
las herramientas. Esa estrategia es lo que se conoce como Modelos de Proceso o Paradigmas.
Estos defnen una serie de pasos que abarcan mtodos, herramientas y procedimientos, y que permiten al analista de
sistemas tener una forma clara, confable y generalizada de desarrollar un sistema de informacin

Evaluacin del proceso

La existencia de un proceso de sofware no es garanta que ste ser entregado a tempo, de que satsfaga las necesidades
del cliente, o de que mostrara las caracterstcas tcnicas que conducirn a caracterstcas de calidad a largo plazo. Los
patrones de proceso deben ir acompaados de una prctca solida de la ingeniera de sofware, el proceso mismo debe
evaluarse para asegurarse de que cumpla una serie de criterios bsicos.
La organizacin Internacional de Estandarizacin ha establecido el estndar ISO 9001:2000 para defnir los requisitos de un
sistema de gestn de calidad que sirva para elaborar productos de ms alta calidad y as mejorar la satsfaccin del
cliente.
Modelos de proceso personales y en equipo

Si un modelo de proceso de sofware ha sido desarrollado en un mbito corporatvo u organizacional, puede ser efectvo
solo si es en gran medida adaptable para satsfacer las necesidades del equipo del proyecto, que es el que en realidad lleva
a cabo el trabajo de ingeniera del sofware. Cada ingeniero de sofware creara un proceso que llene lo mejor posible sus
necesidades, y al mismo tempo satsfaga las amplias necesidades del equipo y la organizacin.

Proceso de sofware personal (PSP): Resalta la medida personal de producto de trabajo que se produce y la calidad
resultante del producto de trabajo. Defne cinco actvidades del marco de trabajo:

Planeacin. Selecciona requisitos, desarrolla el tamao y la estmacin de los recursos y se estman los defectos. Diseo de
alto nivel. Se elaboran las especifcaciones externas para que cada componente sea construido y se crea un diseo del
componente.
Revisin de alto nivel. Las mediciones se mantenen para todas las tareas importantes y los resultados de trabajo.
Desarrollo. El diseo al nivel de componente se refna y revisa. Se genera, revisa, compila y prueba el cdigo.
Anlisis de resultados. Mediante las mediciones y medidas recolectadas se determina la efectvidad del proceso.

Proceso de sofware en equipo (PSE): Se defnen los siguientes objetvos:

- Construir equipos autodirigidos que planeen y tengan un seguimiento de su trabajo, establezcan metas y
posean sus procesos y planes.
- Mostrar a los jefes como preparar y motvar a sus equipos y como ayudarlos a sostener un alto desempeo.
- Ofrecer una gua de mejoramiento a organizaciones de alta madurez.
- Facilitar la enseanza universitaria de habilidades de equipo industrial de calidad.

El PSE defne las siguientes actvidades del marco de trabajo: lanzamiento, diseo de alto nivel, implementacin,
integracin y prueba, y anlisis de resultados. Al igual que el PSP estas actvidades permiten al equipo planear, disear y
construir un sofware de una manera disciplinada al mismo tempo que midan de modo cuanttatvo el proceso y el
producto.



Tecnologa del proceso

Las herramientas de tecnologa del proceso destnadas a ayudar a las organizaciones de sofware a analizar sus procesos
actuales, organizar sus tareas, controlar y monitorear su progreso, y administrar su calidad tcnica.
Una vez creado el proceso aceptable es posible utlizar otras herramientas de tecnologa del proceso para localizar,
monitorear e incluso controlar todas las tareas de ingeniera del sofware defnidas como una parte del modelo del
proceso.
La herramienta de tecnologa del proceso tambin se puede aprovechar para coordinar el uso de otras herramientas de la
ingeniera de sofware.

Producto y proceso

Si el proceso es dbil, sin duda el producto fnal sufrir las consecuencias. Asimismo, una confanza excesiva en el proceso
es peligrosa.
Un profesional del sofware creatvo debe sentr tanta satsfaccin del proceso como del producto terminado.
La calidad del producto y el proceso es un elemento importante para mantener a la gente creatva comprometda mientras
fnaliza la transicin desde la programacin hasta la ingeniera del sofware.

Modelos prescriptvos de proceso

Los modelos prescriptvos de proceso se propusieron originalmente para ordenar el caos del desarrollo de sofware. Estos
modelos convencionales han trado consigo cierta cantdad de estructuras tles para el trabajo en la ingeniera de
sofware.
Cualquier organizacin de ingeniera de sofware debe describir un conjunto nico de actvidades dentro del marco de
trabajo para el proceso de sofware que adopte. Tambin debe llenar cada actvidad del marco de trabajo con un conjunto
de acciones de ingeniera de sofware, y defnir cada accin en cuanto a un conjunto de tareas que identfque el trabajo
para alcanzar las metas de desarrollo. Despus la organizacin debe adaptar el modelo de proceso resultante y ajustarlo a
la naturaleza especfca de cada proyecto, a las personas que lo realizarn, y el ambiente en el que se ejecutar el trabajo.
Se llaman prescriptvos porque prescriben un conjunto de elementos del proceso: actvidades del marco de trabajo,
acciones de ingeniera del sofware, tareas, productos del trabajo, aseguramiento de la calidad, y mecanismos de control
del cambio para cada proyecto.

El modelo en cascada (cuadro).
El modelo incremental (cuadro).
El modelo DRA (cuadro).
Construccin de prototpos (cuadro).
El modelo en espiral (cuadro).
El modelo de desarrollo concurrente. Se representa en forma
esquemtca como una serie de actvidades del marco de trabajo,
acciones y tareas de la ingeniera del sofware y sus estados
asociados.
Todas las actvidades existen de forma concurrente, pero se
encuentran en diferentes estados. El modelo de proceso
concurrente proporciona una visin exacta del estado actual de un
proyecto. Defne una red de actvidades, cada actvidad, accin o
tarea en la red existe de manera simultnea con otras actvidades,
acciones o tareas. Los eventos generados en un punto de la red
del proceso disparan transiciones entre los estados.
Desarrollo basado en componentes. Los nuevos componentes de
sofware comerciales, desarrollados por vendedores que los
ofrecen como producto, se pueden emplear cuando el sofware
est en proceso de construccin. Estos componentes
proporcionan funcionalidad dirigida con interfaces bien defnidas que permiten que el componente se integre en el
sofware.
Este desarrollo es evolutvo por naturaleza y exige un enfoque iteratvo para la creacin del sofware. Adems confgura
aplicaciones a partr de componentes de sofware empaquetados en forma previa.
El modelado y construccin comienza con la identfcacin de los componentes candidatos. Estos componentes se pueden
disear como mdulos de sofware convencionales o como clases o paquetes de clases orientados a objetos.

Este modelo incorpora los siguientes pasos:
- Los productos basados en componentes disponibles se investgan y evalan para el dominio de aplicacin en cuestn.
- Se consideran los aspectos de integracin de componentes.
- Se disea una arquitectura de sofware para adaptar los componentes.
- Los componentes se integran en la arquitectura.
- Se realizan pruebas detalladas para asegurar una funcionalidad apropiada.
El modelo de desarrollo basado en componentes conduce a la reutlizacin del sofware.

El modelo de mtodos formales (cuadro).
Desarrollo del sofware orientado a aspectos. Sin importar el proceso de sofware que se elija, los constructores de
sofware complejo implementan de manera invariable un conjunto especfco de caracterstcas, funciones y contenido de
informacin. Estas caracterstcas especfcas del sofware se modelan como componentes y despus se construyen dentro
del contexto de una arquitectura de sistema. Este desarrollo es un paradigma de la ingeniera relatvamente nuevo que
proporciona un proceso y enfoque metodolgico para defnir, especifcar, disear y construir aspectos (mecanismos mas
all de subrutnas y legados para localizar la expresin de un inters genera).

Proyecto de desarrollo de sofware

Los proyectos de desarrollo de sofware son instanciaciones del proceso defnido organizacionalmente.

Calidad

Calidad es cumplir con los requerimientos de alguien. Es el valor para una persona. Valor es aquello que se est dispuesto
a pagar para obtener sus requerimientos. Calidad es satsfaccin de las necesidades y expectatvas de los clientes y
usuarios consumidores a menor costo
Si no conocemos las necesidades del cliente y solamente las suponemos seguiremos dando lo que nosotros creemos que es
mejor pero no lo que el cliente necesita!

Modelos de Calidad de Procesos

ISO (Organizacin Internacional de Normalizacin) ISO 9001:2008: ISO (la Organizacin Internacional de
Normalizacin) es una federacin mundial de organismos nacionales de normalizacin (organismos miembros de ISO). Esta
Norma Internacional promueve la adopcin de un enfoque basado en procesos cuando se desarrolla, implementa y
mejora la efcacia de un sistema de gestn de la calidad, para aumentar la satsfaccin del cliente mediante el
cumplimiento de sus requisitos.
La aplicacin de un sistema de procesos dentro de la organizacin, junto con la identfcacin e interacciones de estos
procesos, as como su gestn para producir el resultado deseado, puede denominarse como "enfoque basado en
procesos.
CMMI (Capability Maturity Model Integraton): El insttuto de Ingeniera de Sofware (SEI) ha desarrollado un
modelo completo de un amplio proceso basado en un conjunto de capacidades sofware y de sistemas que deben estar
presentes conforme las organizaciones alcanzan diferentes grados de capacidad y madurez del proceso.
El SEI sostene que para lograr estas capacidades una organizacin debe crear un modelo de proceso que se ajuste a las
directrices establecidas por la integracin del modelo de capacidad de madurez.
CMMI es un modelo de procesos, o una coleccin de elementos estructurada que describe caracterstcas de procesos que
han demostrado por experiencia ser efectvas.
CMMI representa un modelo completo de procesos en dos formas diferentes 1) como un modelo contnuo y 2) como un
modelo discreto.
CMMI defne cada rea de proceso en funcin de metas especfcas y de las prctcas especfcas requeridas para alcanzar
dichas metas.
Las metas especfcas establecen las caracterstcas que deben existr para que las actvidades implicadas por un rea de
proceso sean efectvas.
Las prctcas especfcas convierten una meta en un conjunto de actvidades relacionadas con el proceso.

Proceso unifcado de desarrollo

Un proceso es un conjunto de pasos ordenados para alcanzar un objetvo. En la ingeniera de sofware el objetvo es
entregar un producto de sofware que satsfaga las necesidades del usuario de forma efciente y predecible.
Un proceso de desarrollo de sofware es el conjunto de actvidades necesarias para transformar los requisitos de un usuario
en un sistema sofware.
El Proceso Unifcado es un proceso de desarrollo de sofware que utliza el Lenguaje Unifcado de Modelado (UML) para
preparar todos los esquemas de un sistema de sofware.

Nacimiento de PUD

Jacobson fue el padre de UP. El mismo se remonta a 1967 y el enfoque de Ericsson, que dio el paso radical de modelar un
sistema complejo como un conjunto de bloques interconectados. En UML, los bloques grandes se denominan subsistemas,
y cada subsistema se implementa en trminos de bloques mas pequeos denominados componentes. En 1987 Jacobson
fund Objetory AB, empresa que desarroll y vendi un proceso de ingeniera de sofware, basado en el enfoque Ericsson,
denominado Objetory.
El Ratonal Objetory Process (ROP) fue el resultado de la unifcacin de Objetory con el trabajo de Ratonal (Booch).
Desde 1997 en adelante, Ratonal adquiri muchas ms empresas que aportaban su experiencia en captura de requisitos,
gestn de confguracin, pruebas, etc. Esto llev a la aparicin del Ratonal Unifed Process (RUP).
Mientras que RUP es un producto de proceso Ratonal, UP es un proceso de ingeniera de sofware abierto de los autores de
UML.

UP y UPR

RUP es una versin comercial de UP de IBM, proporciona los estndares, herramientas y otras necesidades no incluidas en
UP.
UP y RUP modelan el quin, cundo y qu del proceso de desarrollo de sofware, pero lo hacen de forma ligeramente
diferente:
Para modelar el quin, UP introduce el concepto del recurso (trabajador), describe un rol desempeado por una persona o
equipo dentro del proyecto.
UP modela el qu como actvidades y artefactos. Las actvidades son tareas que realizarn personas o equipos en el
proyecto. Estas personas o equipos adoptan roles especfcos cuando realizan ciertas actvidades. UP modela el cundo
como workfows.


Caracterstcas

-Proceso dirigido por casos de uso: para construir un sistema con xito debemos conocer lo que sus futuros usuarios
(humanos u otros sistemas) necesitan y desean. Un usuario representa algo o alguien que interacta con el sistema. Esta
interaccin es un caso de uso, fragmento de funcionalidad del sistema que proporciona al usuario un resultado
importante. Los CU representan los requisitos funcionales. Todos los casos de uso juntos consttuyen el modelo de casos
de uso, el cual describe la funcionalidad total del sistema. Los CU guan el diseo, implementacin y prueba del sistema, es
decir, guan el proceso de desarrollo. Los CU no se desarrollan aisladamente, se desarrollan a la vez que la arquitectura del
sistema. Los CU guan a la arquitectura del sistema y la arquitectura del sistema infuye en la seleccin de los casos de uso.

-Proceso centrado en la arquitectura: El concepto de arquitectura incluye aspectos esttcos y dinmicos del sistema. La
arquitectura es una vista del diseo completo. Cada producto tene una funcin (CU) y una forma (arquitectura). Los CU
deben encajar en la arquitectura y sta permitr su desarrollo. Debe haber interaccin entre los casos de uso y la
arquitectura.

-Proceso iteratvo e incremental: una iteracin es un mini proyecto que obtene como resultado una versin interna. Un
incremento es la diferencia entre la versin interna, o lnea base, de una iteracin y la versin interna de la siguiente. Es
prctco dividir el trabajo en iteraciones, que son ms fciles de gestonar y completar con xito. Estas iteraciones hacen
referencia a pasos en el fujo de trabajo, y los incrementos al crecimiento del producto. La iteracin trata de un grupo de
CU que juntos amplan la utlidad del producto.
Las primeras iteraciones del proyecto dan como resultado un mayor conocimiento de los requisitos, los problemas, los
riesgos y el dominio de la solucin, mientras que las siguientes dan como resultado incrementos aditvos que fnalmente
conforman la versin externa, es decir, el producto para el cliente.
Las iteraciones construyen los modelos resultantes incremento por incremento. Cada iteracin aade algo ms a cada
modelo, a medida que la iteracin fuye a lo largo de los requisitos, anlisis, diseo, implementacin y prueba. Algunos de
estos modelos como el e casos de uso, reciben ms atencin en las primeras fases, mientras que otros como el de
implementacin, la recibe durante la fase de construccin.


Benefcios de un proceso iteratvo controlado:

-La iteracin controlada reduce el coste del riesgo a los costes de un solo incremento.
-Reduce el riesgo de no sacar al mercado el producto en el calendario previsto.
-Acelera el ritmo del esfuerzo de desarrollo en su totalidad debido a que los desarrolladores trabajan de manera ms
efciente para obtener resultados claros a corto plazo. -Reconoce una realidad que a menudo se ignora.

El problema del desarrollo iteratvo incremental es que requiere no solo una nueva forma de gestonar los proyectos, sino
tambin herramientas que soporten este nuevo mtodo.

La arquitectura proporciona la estructura sobre la cual guiar las iteraciones, mientras que los CU defnen los objetvos y
dirigen el trabajo de cada iteracin. La eliminacin de una de las tres ideas reducira drstcamente el valor del UP.

Ciclo de vida del proceso unifcado

El proceso unifcado se repite a lo largo de una serie de ciclos que consttuyen la vida de un sistema. Cada ciclo concluye con
una versin del producto para los clientes.
Cada ciclo consta de cuatro fases: inicio, elaboracin, construccin y transicin. Cada fase se divide a su vez en iteraciones.

Cada versin es un producto preparado para su entrega. Consta de un cdigo fuente incluido en componentes que pueden
compilarse y ejecutare, manuales y otros productos asociados.

Para llevar a cabo el ciclo de manera efciente los desarrolladores necesitan:

Inicio
Elaboracin Transicin Construccin
Iteracin
# n-1
Iteracin
# n
Iteracin
# 2 ...
Iteracin
# 1
- - - - - - - - - - - - - - -
Versiones

-Un modelo de casos de uso: con todos los casos de uso y su relacin con los usuarios.
especifcado por
-Un modelo de anlisis, con dos propsitos: refnar los costos de uso con ms detalle y establecer la asignacin inicial de
funcionalidad del sistema a un conjunto de objetos que proporcionan el comportamiento.
realizado por
-Un modelo de diseo que defne: la estructura esttca del sistema (subsistemas,, clases e interfaces) y los casos de uso
refejados como colaboraciones. implementado por
-Un modelo de implementacin, que incluye componentes y la correspondencia de las clases con los componentes.
distribuido por
-Un modelo de despliegue que defne los nodos fsicos y la correspondencia de los componentes con estos nodos.
verifcado por
-Un modelo de prueba que describe los casos de prueba que verifcan lo casos de uso.
-Y una representacin de la arquitectura.
Tambin debe tener un modelo del dominio o modelo del negocio.

Fases dentro de un ciclo: Cada fase termina con un hito. Cada hito se determina por la disponibilidad de ciertos modelos o
documentos que han sido desarrollados hasta alcanzar un estado predefnido.

Fase de inicio: se desarrolla una descripcin del producto fnal a partr de una idea y se presenta el anlisis de
negocio para el producto. Principalmente esta fase responde a las preguntas sobre cules son las principales funciones del
sistema para sus usuarios ms importantes, cmo podra ser la arquitectura del sistema y cul es el plan del proyecto,
adems de cunto costar desarrollar el sistema. Se realiza un modelo de casos de uso simplifcado, con los ms crtcos; la
arquitectura es un esbozo que muestra los principales subsistemas, se identfcan y priorizan los riesgos, se planifca en
detalle la fase de elaboracin y se estma el proyecto.

Fase de elaboracin: Se especifcan en detalle la mayora de los casos de uso del producto y se disea la
arquitectura del sistema. La arquitectura se expresa en forma de vistas de todos los modelos del sistema (decimos vista de
los modelos porque no son los modelos completos, ya que faltan incorporar casos de uso). Se crea una lnea base de la
arquitectura (versin interna (o externa) del conjunto de artefactos revisados y aprobados generados por esa iteracin).

Fase de construccin: se crea al producto. Combina la generacin del cdigo y la realizacin de pruebas para
descubrir errores en el cdigo. Aqu la lnea base de la arquitectura crece hasta convertrse en el sistema completo,
obteniendo as un producto preparado para ser entregado a los usuarios.

Fase de transicin: En esta fase el producto se convierte en versin una beta. Un nmero reducido de
usuarios, con experiencia, prueba el sistema e informa defectos y
defciencias. Los desarrolladores corrigen los problemas e incorporan las mejoras sugeridas. Esta fase incluye adems las
tareas de formacin del cliente, ayuda en lnea y asistencia.

Conceptos bsicos del PUD

Flujo de Trabajo (Workfow)
Es un conjunto de actvidades. Un fujo de trabajo determina cmo fuye el trabajo de un trabajador a otro. Para ello se ha
identfcado primero qu tpos de trabajadores partcipan en el proceso y qu artefactos se necesitan crear durante el
proceso por cada tpo de trabajador.
Artefacto
Es un trmino general para cualquier tpo de informacin creada, producida, cambiada o utlizada por los trabajadores en el
desarrollo del sistema.
Trabajador
Se denomina as a los puestos a los cuales se pueden asignar personas. Un tpo de trabajador es un papel que una persona
puede desempear en el desarrollo de sofware. Cada trabajador es responsable de un conjunto completo de actvidades.
Actvidades
Son trabajos signifcatvos para una persona que acta como trabajador.

Flujos de trabajo del PUD

En el PUD existen cinco FT:

FT de Requerimientos: capturan lo que el sistema debera hacer.
FT de Anlisis: mejora y estructura los requisitos.
FT de Diseo: realiza los requisitos en la arquitectura del sistema.
FT de Implementacin: crea el sofware.
FT de Prueba: verifca que la implementacin funciona segn se desea.





UML: Lenguaje Unifcado de Modelado

Es un lenguaje estndar para escribir planos de sofware. Es un lenguaje de modelado visual, de propsito general, usado
para la visualizacin, especifcacin, construccin y documentacin de sistemas Orientados a Objetos. El Lenguaje
Unifcado de Modelado (UML) es un lenguaje de modelado y no un mtodo o un proceso. Est compuesto por una
notacin muy especfca y por las reglas semntcas relacionadas para la construccin de sistemas de sofware. En s
mismo no prescribe ni aconseja como usar esta notacin.
UML es independiente del proceso, aunque para utlizarlo ptmamente se debera usar en un proceso dirigido por los casos
de uso, centrado en la arquitectura, iteratvo e incremental.
UML es un lenguaje: proporciona vocabulario y reglas para combinar palabras de ese vocabulario con el objetvo de
posibilitar la comunicacin. Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la
representacin conceptual y fsica de un sistema.
El vocabulario y las reglas de UML indican cmo crear y leer modelos bien formados, pero no dicen qu modelos se deben
crear ni cundo se deberan crear. sta es la tarea del proceso de desarrollo de sofware.

Lenguaje ? Mtodo ? Proceso ?

Lenguaje: Notacin + Reglas
Proceso: Pasos a seguir
Mtodo: Qu + Cmo + Porqu

Qu NO es UML?

-Un lenguaje de programacin visual.
-La especifcacin de una herramienta o un repositorio.
-UNA METODOLOGA, MTODO O PROCESO.

UML es un lenguaje para visualizar: UML es un lenguaje grfco que aporta modelos explcitos que facilitan la
comunicacin. Detrs de cada smbolo en la notacin UML hay una semntca bien defnida. As un
desarrollador puede escribir un modelo en UML, y otro desarrollador o incluso herramienta puede interpretar
ese modelo sin ambigedad.

UML es un lenguaje para especifcar: Especifcar signifca construir modelos precisos, no ambiguos y completos.

UML es un lenguaje para construir: UML no es un lenguaje de programacin visual, pero
sus modelos pueden conectarse de forma directa a una gran variedad de lenguajes de programacin, esto permite
ingeniera directa: generacin de cdigo a partr de un modelo UML, en un lenguaje de programacin. Lo
contrario tambin es posible: se puede reconstruir un modelo en UML a partr de una implementacin. La
combinacin de estas dos vas produce una ingeniera de ida y vuelta, entendiendo la posibilidad de trabajar
en una vista grfca o en una textual, mientras las herramientas mantenen la consistencia entre ambas.

UML es un lenguaje para documentar: Permite generar una serie de artefactos. Estos artefactos incluyen:

Requisitos
Arquitectura
Diseo
Cdigo fuente
Planifcacin de proyectos
Pruebas Prototpos
Versiones

UML: Un modelo conceptual

Aprender a aplicar UML requiere aprender tres elementos principales: bloques bsicos de construccin de UML, reglas que
dictan cmo pueden combinarse esos bloques y mecanismos comunes que se aplican a lo largo de todo el lenguaje.

1) Bloques bsicos de UML:

Tres clases:

Elementos
Relaciones
Diagramas

Los elementos son abstracciones que consttuyen los ciudadanos de primera clase en un modelo; las relaciones
ligan estos elementos entre si; los diagramas agrupan colecciones interesantes de elementos.



a) Elementos en UML: Cuatro tpos:
Elementos estructurales: Son las partes esttcas de un modelo, y representan conceptos o cosas materiales.
Colectvamente se denominan clasifcadores. Hay 7 tpos:

Clase: descripcin de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y
semntca. Una clase implementa una o ms interfaces.

Interfaz: coleccin de operaciones que especifcan un servicio de una clase o componente, y no una
implementacin. Describe el comportamiento visible externamente de ese elemento.

Colaboracin: Defne una interaccin, es una sociedad de roles y otros elementos que colaboran para
proporcionar un comportamiento cooperatvo mayor que la suma de los comportamientos de sus
elementos. Una clase dada o un objeto puede partcipar en varias colaboraciones.

Caso de uso: Describe una serie de acciones que desarrolla un actor cuando ste interacta con el sofware. Un
caso de uso es realizado por una colaboracin.

Clase actva: Clase cuyos objetos tenen uno o ms procesos o hilos de ejecucin.

Componente: Parte fsica y reemplazable de un sistema.

Nodo: Elemento fsico que existe en tempo de ejecucin y representa un recurso computacional, que por
lo general dispone de algo de memoria y, con frecuencia, capacidad de procesamiento. Un conjunto de
artefactos puede residir en un nodo y puede tambin migrar de un nodo a otro.

Elementos de comportamiento: Son las partes dinmicas de los modelos UML. Son los verbos de un modelo.
Representan comportamientos en el tempo y en el espacio.
Interaccin: Comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de
objetos, dentro de un contexto partcular, para alcanzar un propsito especfco.

Mquina de estados: Comportamiento que especifca las secuencias de estados por las que pasa un objeto
o una interaccin durante su vida en respuesta a eventos, junto con sus reacciones a estos eventos.

Actvidad: Comportamiento que especifca la secuencia de pasos que ejecuta un proceso computacional. El
nfasis se pone en los fujos entre los pasos, sin mirar qu objeto ejecuta cada paso. Un paso de una
actvidad se denomina una accin.


Elementos de agrupacin: Son las partes organizatvas de los modelos UML. Hay un tpo principal de
elementos de agrupacin: Los paquetes.

Paquete: Mecanismo de propsito general para organizar elementos en grupos. Los elementos estructurales,
de comportamiento e incluso otros elementos de agrupacin pueden incluirse en un paquete.

Tambin hay variaciones como los frameworks, los modelos y los subsistemas.

Elementos de anotacin: Partes explicatvas de los modelos UML. Son comentarios. Hay un tpo principal de
elemento de anotacin llamado nota.

Nota: Smbolo para mostrar restricciones y comentarios.


b) Relaciones en UML: Se utlizan para escribir modelos bien formados. Cuatro tpos:

Dependencia: Relacin semntca entre dos elementos, en la cual un cambio a un elemento puede afectar a la
semntca del otro elemento.

Asociacin: Relacin estructural entre clases que especifca que los objetos de un elemento estn conectados
con los objetos de otro. La agregacin es un tpo especial de asociacin, que representa una relacin estructural
entre un todo y sus partes.

Generalizacin: Relacin que conecta elementos generalizados (padre) a elementos especializados (hijo). El
hijo comparte la estructura y el comportamiento del padre.

Realizacin: Relacin semntca entre clasifcadores, en donde un clasifcador especifca un contrato que otro
clasifcador garantza que cumplir.


c) Diagramas en UML: Es la representacin grfca de un conjunto de elementos, visualizado la mayora de
las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Es una proyeccin de un
sistema, representa una vista resumida de los elementos que consttuyen un sistema. Se dibujan para
visualizar un sistema desde diferentes perspectvas. UML incluye trece tpos de diagramas:

Los que cubren la vista esttca del sistema:

Diagrama de clases
Diagrama de objetos
Diagrama de componentes
Diagrama de casos de uso
Diagrama de despliegue

Los que cubren la vista dinmica del sistema:

Diagramas de interaccin:
Diagrama de secuencia
Diagrama de comunicacin
Diagrama de estados Diagrama
de actvidades

No s qu modelan:

Diagrama de paquetes
Diagrama de tempos
Diagrama de visin global de interacciones
Diagrama de estructura compuesta

Diagrama de clases: Muestra un conjunto de clases, interfaces y colaboraciones, as como sus relaciones.
Son los diagramas mas comunes.
Diagrama de objetos: Muestra un conjunto de objetos y sus relaciones.
Diagrama de componentes: Representa la encapsulacin de una clase, junto con sus interfaces, puertos y
estructura interna.
Diagrama de casos de uso: Muestra un conjunto de casos de uso y actores y sus relaciones.
Diagrama de interaccin: Muestra una interaccin, que consta de un conjunto de objetos o roles, incluyendo
los mensajes que pueden ser enviados entre ellos.
Diagrama de secuencia: Resalta la ordenacin temporal de los mensajes.
Diagrama de comunicacin: Resalta la organizacin estructural de los objetos o roles que envan y reciben
mensajes.
Diagrama de estados: Muestra una mquina de estados, que consta de estados, transiciones, eventos y
actvidades.
Diagrama de actvidades: Muestra la estructura de un proceso u otra computacin.
Diagrama de despliegue: Muestra la confguracin de nodos de procesamiento en tempo de ejecucin y los
artefactos que residen en ellos. Normalmente un nodo alberga uno o ms artefactos.
Diagrama de artefactos: Muestra los consttuyentes fsicos de un sistema en el computador. Los artefactos
incluyen archivos, bases de datos y colecciones fsicas de bits similares. Tambin muestran las clases y
componentes que implementan.
Diagrama de paquetes: Muestra la descomposicin del propio modelo en unidades organizatvas y sus
dependencias.
Diagrama de tempos: Muestra los tempos reales entre diferentes objetos o roles.
Diagrama de visin global de interacciones: Hbrido entre diagrama de actvidades y diagrama de secuencia.



2) Reglas de UML

Especifcan a que debe parecerse un modelo bien formado (aquel que es semntcamente autoconsistente y
est en armona con todos sus modelos relacionados). UML tene reglas sintctcas y semntcas para:

Nombres: Cmo llamar a los elementos, relaciones y diagramas.
Alcance: Contexto que da un signifcado especfco a un nombre.
Visibilidad: Cmo se pueden ver y utlizar esos nombres por otros.
Integridad: Cmo se relacionan apropiada y consistentemente unos elementos con otros. Ejecucin: Qu
signifca ejecutar o simular un modelo dinmico.

Es habitual que el equipo de desarrollo no slo construya modelos bien formados, sino modelos que tambin
sean:

Abreviados: Ciertos elementos se ocultan para simplifcar la vista.
Incompletos: Pueden estar ausentes ciertos elementos.
Inconsistentes: No se garantza la integridad del modelo.

Las reglas de UML estmulan (no obligan) a considerar las cuestones mas importantes del anlisis, diseo e
implementacin que llevan a tales sistemas a convertrse en bien formados con el paso del tempo.

Mecanismos comunes en UML

UML se simplifca mediante la presencia de cuatro mecanismos comunes:

Especifcaciones: UML es ms que un lenguaje grfco. Detrs de cada elemento de notacin grfca
hay una especifcacin que proporciona una explicacin textual de la sintaxis y semntca de ese bloque
de construccin.

Adornos: La especifcacin de una clase puede incluir otros detalles, como si es abstracta o la
visibilidad de atributos y operaciones. Muchos de estos detalles se pueden incluir como adornos
grfcos o textuales en la notacin rectangular bsica de la clase.

Divisiones comunes:

Divisin entre clase y objeto: Una clase es una abstraccin; un objeto es una manifestacin concreta de esa
abstraccin.

Divisin entre interfaz e implementacin: Una interfaz declara un contrato; una implementacin representa
una realizacin concreta de ese contrato.

Divisin entre tpo y rol: El tpo declara la clase de una entdad, como un objeto, un atributo o parmetro;
un rol describe el signifcado de una entdad en un contexto, como una clase, un componente o una
colaboracin.


Mecanismos de extensibilidad: UML es abierto-cerrado, siendo posible extender el lenguaje de manera
controlada. Los mecanismos de extensin de UML comprenden:

Estereotpos: extenden el vocabulario de UML, permitendo crear nuevos tpos de bloques de construccin que
derivan de los existentes pero que son especfcos a un problema.
Valores etquetados: extenden las propiedades de un estereotpo de UML, permitendo aadir nueva
informacin en la especifcacin de ese estereotpo.
Restricciones: extenden la semntca de un bloque de construccin de UML permitendo aadir nuevas reglas o
modifcar las existentes.

Arquitectura

Diferentes usuarios (usuarios fnales, analistas, desarrolladores, integradores de sistemas, encargados de las
pruebas, encargados de la documentacin tcnica y jefes de proyectos) miran al sistema de formas diferentes en
diversos momentos a lo largo de la vida del proyecto. La arquitectura de un sistema es el artefacto ms
importante que puede emplearse para manejar estos diferentes puntos de vista y controlar el desarrollo
iteratvo e incremental de un sistema a lo largo de su ciclo de vida.
La arquitectura de un sistema con gran cantdad de sofware puede describirse mejor a travs de cinco vistas
interrelacionadas (vistas de UML):



Vista de casos de uso: Comprende los casos de uso que describen el comportamiento del sistema tal y como
es percibido por los usuarios fnales, analistas y encargados de las pruebas. En UML, los aspectos esttcos de
esta vista se capturan en los diagramas de casos de uso; los aspectos dinmicos en los diagramas de interaccin,
diagramas de estados y diagramas de actvidades.
Vista de diseo: Comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y
la solucin. Soporta requisitos funcionales del sistema, o sea los servicios que el sistema debera proporcionar a
sus usuarios fnales. En UML, los aspectos esttcos se capturan en los diagramas de clases y de objetos; los
aspectos dinmicos en los diagramas de interaccin, diagramas de estados y diagramas de actvidades.
Vista de interaccin: Muestra el fujo de control entre sus diversas partes, incluyendo los posibles mecanismos
de concurrencia y sincronizacin. Abarca el rendimiento, escalabilidad y capacidad de procesamiento del
sistema. En UML, los aspectos esttcos y dinmicos se capturan con los mismos diagramas que en la vista de
diseo.
Vista de implementacin: Comprende artefactos que se utlizan para ensamblar y poner en produccin el
sistema fsico. Se ocupa de la gestn de confguraciones de las versiones del sistema a partr de archivos
independientes que pueden ensamblarse para producir un sistema en ejecucin. En UML, los aspectos esttcos
se capturan con los diagramas de artefactos; los aspectos dinmicos con los diagramas de interaccin,
diagramas de estados y diagramas de actvidades.
Vista de despliegue: Contene los nodos que forman la topologa hardware sobre la que se ejecuta el sistema.
Se ocupa de la distribucin, entrega e instalacin de las partes que consttuyen el sistema fsico. En UML, los
aspectos esttcos se capturan con diagramas de despliegue; los aspectos dinmicos con diagramas de
interaccin, diagramas de estados y diagramas de actvidades.


El nacimiento de UML
Del libro:
Anterior a 1994, el mundo de los mtodos orientados a objetos era bastante confuso. En trminos de lenguajes
de modelado visual los lderes eran Booch y Rumbaugh. En el lado de las metodologas, Jacobson tena el caso
ms fuerte.
Hubo un primer intento de unifcacin en 1994 con el mtodo de fusin de Coleman, pero este no implic a los
autores originales y lleg tarde al mercado. La fusin se vio superada rpidamente por los acontecimientos
cuando en 1994 Booch y Raumbaugh se unieron para trabajar en UML. As se convirt en un estndar de la
industria abierto.
En 1997 se acept UML, desde entonces todos los mtodos competdores han desaparecido.
En el 2000, UML incorpor la semntca de accin, que describe el comportamiento de un conjunto de acciones
primitvas que se pueden implementar por lenguajes de accin especfcos. Se permit que la especifcacin de
UML fuera computacionalmente completa y permit que los modelos UML fueran ejecutables.
Ahora UML es un lenguaje de modelado muy maduro, presenta numerosa sintaxis visual nueva. Los cambios
ms importantes incorporados en UML 2 se han realizado en el metamodelo de UML, un modelo de lenguaje
que se expresa en un subconjunto de UML. stos cambios han estado relacionados con la mejora de la precisin
y la coherencia de la especifcacin UML.



De la profe:
Surgimiento UML

- Los lenguajes de modelado orientados a objetos aparecieron entre la mitad de los aos 70 y fnales de los 80, por el uso
de los lenguajes de programacin O.O.
- Entre fnes de los 80 y mediados de los 90 surgen muchos nuevos mtodos O.O. Autores mas destacados: Booch, Jacobson
(OOSE), Rumbaugh (OMT).
- En los 90 Booch (Ratonal Sofware Corporaton), Jacobson (Objectory), Rumbaugh (General Electric) comienzan a unifcar
sus ideas.
- En 1997 se presenta la versin 1.0 de UML a OMG (Object Management Group), que se fue perfeccionando hasta la
1.3.
- Actualmente versin 2.0 de UML.

MDA, el futuro de UML
MDA defne una visin de cmo se puede desarrollar sofware basndose en modelos. La esencia de esta visin
es que los modelos dirigen la produccin de la arquitectura de sofware ejecutable.
En MDA el sofware se produce por medio de una serie de transformaciones de modelo ayudadas por una
herramienta de modelado MDA. La nocin del modelo es bastante general y el cdigo se considera un tpo muy
concreto de modelo.
El CIM es un modelo en su nivel ms alto de abstraccin que captura requisitos clave del sistema y el vocabulario
del dominio del problema en una forma que es independiente de los ordenadores.
El PIM es un modelo que expresa la semntca del negocio del sistema de sofware independientemente de
cualquier plataforma subyacente (como EJB, .NET, otras). PIM est adornado con informacin especfca de la
plataforma para crear el PSM. El cdigo fuente se genera desde el PSM contra la plataforma destno.
En la visin MDA, el cdigo fuente, como el cdigo Java y C#, es el cdigo mquina resultante de la compilacin
de los modelos UML. Este cdigo se genera segn se necesite directamente desde el PSM.

UML es UNIFICADO
UML trata de estar unifcada en diferentes dominios:

Ciclo de vida de desarrollo: Proporciona sintaxis visual para modelado directamente por medio del ciclo de
vida del desarrollo de sofware desde los requisitos a la implementacin.
Dominios de aplicacin: Se ha utlizado para modelar de todo, desde sistemas incorporados en el tempo real a
sistemas de soporte a la toma de decisin.
Lenguajes y plataformas de implementacin: es neutro tanto en lenguaje como en plataforma.
Procesos de desarrollo: mas all de que UP sea preferido para los procesos de desarrollo orientado a objetos,
UML soporta muchos otros procesos de ingeniera de sofware.
Sus propios conceptos internos: trata de ser coherente y uniforme en su aplicacin de un pequeo grupo de
conceptos internos. No siempre tene xito, pero sigue siendo una gran mejora sobre intentos anteriores.


Objetos y UML
Tenemos dos aspectos en un modelo UML:

Estructura esttca: Esto describe qu tpo de objetos son importantes para modelar el sistema y cmo se
relacionan.
Comportamiento dinmico: Esto describe los ciclos de vida de estos objetos y cmo interactan entre s para
entregar la funcionalidad de sistema requerida.
Ambos aspectos van ntmamente unidos, y uno no est del todo completo sin el otro.

Unidad N 5: Ingeniera de requerimientos

Requerimientos del sofware

Es difcil establecer exactamente lo que el sistema debe hacer. Los requerimientos para un sistema son la descripcin de
los servicios proporcionados por el sistema y sus restricciones operatvas. Es una caracterstca que debe incluirse en un
nuevo sistema y puede consistr en una forma de captar o procesar datos, producir informacin, controlar una actvidad o
dar apoyo a la gerencia. El proceso de descubrir, analizar documentar, y verifcar estos servicios y restricciones se
denomina ingeniera de requerimientos.

Requerimientos del usuario: declaraciones, en lenguaje natural y en diagramas, de los servicios que se espera que el
sistema proporcione y de las restricciones bajo las cuales debe funcionar. Deben describir los requerimientos funcionales y
no funcionales de tal forma que sean comprensibles por los usuarios del sistema sin conocimiento tcnico detallado.
nicamente deben especifcar el comportamiento externo del sistema y deben evitar las caracterstcas de diseo del
sistema. Deben simplemente enfocarse a los recursos principales a proveer.

Requerimientos del sistema: Establecen con detalle las funciones, servicios y restricciones operatvas del sistema. Son
versiones extendidas de los requerimientos del usuario. Sirven como base para defnir el contrato de la especifcacin del
sistema, y por lo tanto, debe ser una especifcacin completa y consistente del sistema entero. Deben establecer lo que el
sistema har y no la manera en la que se implementar.


Tipos de requerimientos:


Requerimientos funcionales: Describen lo que el sistema har sin considerar aspectos de implementacin. Son
declaraciones de los servicios que proveer el sistema, de la manera en que ste reaccionar a entradas partculares y de
cmo se comportar en situaciones partculares.
Dependen del tpo de sofware que se desarrolle, de los posibles usuarios del sofware y del enfoque general tomado por la
organizacin al redactar requerimientos.

Requerimientos no funcionales: Describen una restriccin sobre el sistema que limita nuestras elecciones en la
construccin de una solucin al problema. Son aquellos que no se referen directamente a las funciones especfcas del
sistema, sino a las propiedades emergentes de ste (fabilidad, respuesta en el tempo, capacidad de almacenamiento,
etc.). Rara vez se asocian con caracterstcas partculares del sistema.
A menudo son ms crtcos que los RF, ya que el incumplimiento de este ltmo degradar al sistema, mientras que el
incumplimiento de un RNF puede signifcar que el sistema entero sea inutlizable.
Los RNF surgen de las necesidades del usuario. Pero tambin pueden venir de las caracterstcas requeridas del sofware (
requerimientos del producto), de la organizacin que desarrolla el sofware (requerimientos organizacionales) o de
fuentes externas (requerimientos externos).

Requerimientos del producto: especifcan el comportamiento del producto. Ej:
Efciencia.
Usabilidad
Performance.
Fiabilidad. Estabilidad
Etc.

Requerimientos organizacionales: derivan de poltcas y procedimientos existentes en la organizacin del cliente y
en la del desarrollador. Ej:

Estndares de proceso.
Lenguaje de programacin.
Requerimientos de implementacin.

Requerimientos externos: se derivan de los factores externos al sistema y de su proceso de desarrollo. Ej:
Legales.
tcos.
Impositvos.

Es de utlidad diferenciar los RF y los RNF en el documento de requerimientos, aunque en la prctca esto es difcil.

Requerimientos del dominio: Se derivan del dominio de aplicacin del sistema ms que de las necesidades especfcas de
los usuarios. Refejan las caracterstcas y restricciones de ese dominio. Pueden ser RNF, RF nuevos, restringir los existentes
o establecer cmo se deben ejecutar clculos partculares. Normalmente incluyen terminologa especializada del dominio o
referencias a conceptos del dominio.

Especifcacin de la interfaz:

Casi todos los sistemas de sofware deben funcionar con otros sistemas que ya estn implementados e instalados en el
entorno. Si el sistema nuevo y los ya existentes deben trabajar juntos, las interfaces de estos ltmos deben especifcarse
de forma precisa. Estas especifcaciones se deben defnir al inicio del proceso y se incluyen en el documento de
requerimientos. Existen tres tpos de interfaces que pueden defnirse:

- Interfaces de procedimientos
- Estructuras de datos
- Representaciones de datos

Verdaderos Requerimientos

Son aquellos que pueden ser solucionados a partr del desarrollo de un sistema de informacin. Tienen que ver con el
dominio del problema.
El proceso de determinacin de requerimientos para un sistema basado en computadoras implica en primer lugar trabajar
con los clientes para extraer los requerimientos, formulando preguntas, haciendo demostraciones del sistemas similares y
hasta desarrollando prototpos de todo o parte del sistema propuesto. Despus se capturan dichos requerimientos en un
documento o una base de datos, para ello se escriben los requerimientos, de modo que los clientes y los desarrolladores
puedan ponerse de acuerdo acerca de lo que el sistema debe hacer.

Categoras de Requerimientos

Requerimientos que deben ser absolutamente satsfechos.
Requerimientos que son deseables pero no indispensables.
Requerimientos que son posibles, pero que podran eliminarse.

Caracterstcas de los Requerimientos

Correctos.
Consistentes.
Completos.
Realistas.
Necesarios.
Verifcables. Rastreables.


Documento de requerimientos del sofware especifcacin de requerimientos del sofware (ERS)

Es la declaracin ofcial de qu es lo que requieren los desarrolladores del sistema. Incluye tanto los requerimientos del
usuario para el sistema como una especifcacin detallada de los requerimientos del sistema. El documento de
requerimientos tene un conjunto diverso de usuarios que va desde los altos cargos de la organizacin que paga por el
sistema, hasta los ingenieros responsables de desarrollar el sofware.

Los requisitos que debe satsfacer la ERS son:

Especifcar nicamente el comportamiento externo del sistema.
Especifcar las restricciones de la implementacin.
Ser fcil de cambiar.
Servir como herramienta de referencia para los mantenedores del sistema.
Registrar las previsiones del ciclo de vida del sistema.
Caracterizar las respuestas aceptables para los eventos no deseados.

Estructura y contenido de la ERS

Introduccin
Propsito del documento: delinear el propsito de la ERS y especifcar a quin se dirige.
Defniciones, acrnimos y abreviaturas: incluir las defniciones de los trminos, acrnimos y abreviaturas
requeridas para interpretar la ERS.
Audiencia: indicar a quines va dirigido el documento y cul ser su utlidad.
Alcance: identfcar los productos de SW, explicar que har y que no har cada uno, escribir la aplicacin.
Referencias: proveer una lista completa de todos los documentos referenciados.

Presentacin del Producto

Propsito del Sistema
Restricciones y Supuestos: lmites a las opciones para disear el sistema. Restricciones econmicas, legales, impositvas,
etc.

Descripcin General

Listado de la Funcionalidad del Sistema: resumen de las funciones que ejecutar el SW.
Listado de Actores: caracterstcas generales de los usuarios (descripcin de los actores).
Perspectva del Producto: relacin con otros productos o proyectos, productos independientes, componentes de un
sistema o de un proyecto, HW y equipamiento perifrico, restricciones de diseo.

Descripcin Detallada de Requerimientos

Requerimientos Funcionales: diagrama de CU del SI y descripcin de CU.
Requerimientos No Funcionales: plantlla de descripcin de RNF.

o Del Producto
o Del Ambiente

Requerimientos de Interfaz

Interfaces de Usuario Interfaces
de Hardware
Interfaces de Sofware Interfaces de
Comunicacin

Restricciones de Diseo
Operaciones
Requerimientos de Licencia
Componentes Comprados
Observaciones


Proceso de ingeniera de requerimientos (PIR)

La ingeniera de requerimientos es un proceso que comprende todas las actvidades requeridas para crear y mantener un
documento de requerimientos del sistema (ERS). Es un proceso iteratvo que incluye las siguientes actvidades:

Estudio de viabilidad.
Elicitacin de requerimientos (Obtencin y anlisis).
Especifcacin de requerimientos.
Validacin de requerimientos.

Estudio de viabilidad

Evaluacin de si el sistema es tl para el negocio. La entrada es una descripcin del sistema y de cmo se utlizar en la
organizacin. El resultado es un informe que recomienda si es conveniente o no seguir con la ingeniera de requerimientos
y el proceso de desarrollo del sistema.

Elicitacin de requerimientos

En esta actvidad se trabaja con los clientes y los usuarios fnales del sistema para determinar el dominio de la aplicacin,
cules servicios debe proveer el sistema, el desempeo requerido por el sistema, las restricciones de hardware, etc. La
elicitacin incluye diferentes tpos de personas de la organizacin. El trmino stakeholders se utliza para referirse a
cualquier persona que tene infuencia directa o indirecta sobre los requerimientos del sistema. Las actvidades del
proceso son:

Comprensin del dominio.
Recoleccin de requerimientos.
Clasifcacin.
Resolucin de confictos.
Priorizacin.
Verifcacin de requerimientos.

Especifcacin de requerimientos

La tarea fundamental que se defne para este proceso es la de realizar una anlisis de los requerimientos detectados y la
creacin de los modelos necesarios que representen la solucin del sofware, que tene en cuenta esos requerimientos.
La solucin presentada es una solucin lgica o terica, libre de cualquier aspecto referido a como se implementar el
sistema.
Como resultado de desarrollo de este proceso se obtene el documento de Especifcacin de Requerimientos de Sofware
(ERS) que expresa los requerimientos funcionales detectados a travs de los modelos que dan solucin a los mismos.
Algunas de las principales herramientas que nos permiten realizar la especifcacin de requerimientos funcionales y realizar
la ERS son:

Diagrama de Casos de Uso.
Descripcin de Casos de Uso.
Diagrama de Clases.

Validacin de requerimientos

La validacin muestra que los requerimientos son los que defnen el sistema que el cliente desea.
Es importante debido a que los errores en la ERS pueden conducir a costos excesivos.
Se deben llevar a cabo diferentes tpos de verifcaciones en el documento de requerimientos:

Verifcacin de validez: Un usuario puede pensar que se necesita un sistema para llevar a cabo ciertas
funciones. Sin embargo, el razonamiento y el anlisis pueden identfcar que se requieren funciones adicionales
o diferentes.
Verifcacin de consistencia: los requerimientos no deben contradecirse.
Verifcacin de integridad: los requerimientos deben cubrir todas las funciones y restricciones propuestas por el
usuario.
Verifcacin de realismo: los requerimientos deben verifcarse para asegurar que se puedan implementar.
Verifcabilidad: Los requerimientos del sistema siempre deben redactarse de tal forma que sean verifcables.
Esto signifca que debe poder escribir un conjunto de pruebas que demuestren que el sistema a entregar
cumple con cada uno de los requerimientos especifcados.

Administracin de requerimientos

Los requerimientos para sistemas de sofware grandes son siempre cambiantes. Debido a que el problema no puede
defnirse completamente, los requerimientos de sofware son incompletos. Durante el proceso del sofware, la
comprensin del problema por el desarrollador est cambiando constantemente y estos cambios retroalimentan a los
requerimientos.
La administracin de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos del
sistema.

Requerimientos duraderos y voltles

Desde una perspectva evolutva, los requerimientos son de dos clases:

Requerimientos duraderos: son relatvamente estables que se derivan de la actvidad principal de la
organizacin y estn directamente relacionados con el dominio del problema.

Requerimientos voltles: cambian durante el desarrollo del sistema o despus de que ste se haya puesto en
operacin.

Unidad N 6:
El proceso de elicitacin de requerimientos

Elicitacin
Est explicado en la unidad 5.
Tareas en la Elicitacin

Planeacin

Determinacin de cundo y a quin ser dirigida la recoleccin de datos.
Conocimiento del dominio
Diseo de la herramienta

Desarrollo

Tomar notas
Grabacin
Filmacin
Uso de Formularios

Organizacin y anlisis de la informacin obtenida

Resmenes
Informes Minutas Cuadros
Listado de Requerimientos
Especifcacin de Requerimientos


Fuentes de Informacin



Tcnicas de recopilacin de informacin.

Mtodos interactvos.

Hay tres mtodos interactvos clave para obtener los requerimientos de la
Informacin: las entrevistas, el diseo conjunto de aplicaciones (Joint Applicaton Design) y la realizacin de encuestas
mediante cuestonarios.

Entrevistas:

Conversacin dirigida con un propsito especfco que utliza un formato de preguntas y respuestas.

Pasos para preparar una entrevista.

Leer los antecedentes.
Establecer los objetvos de la entrevista.
Decidir a quin entrevistar.
Preparar al entrevistado.
Decidir tpo de preguntas y respuestas.

Tipos de preguntas:

Preguntas Abiertas: Describe las opciones del entrevistado para responder. Estn abiertas, la respuesta puede ser de dos
palabras o dos prrafos

Ventajas de utlizar preguntas abiertas:

Hacen que el entrevistado se sienta ms a gusto.
Permiten al entrevistador entender el vocabulario del entrevistado, el cual refeja su educacin,
valores, acttudes y creencias.
Proporcionan gran cantdad de detalles.
Revelan nuevas lneas de preguntas que pudieron haberse pasado por alto.
Hacen ms interesante la entrevista para el entrevistado.
Permiten mas espontaneidad.

Facilitan la forma de expresarse al entrevistador.
Son un buen recurso si el entrevistador no est preparado para la entrevista.

Desventajas de utlizar preguntas abiertas:

Podran dar como resultado muchos detalles irrelevantes.
Posible prdida de control de la entrevista.
Permiten respuestas que podran tomar ms tempo del debido para la cantdad tl de informacin
obtenida.
Dan la impresin de que el entrevistador es inexperto.
Podrn dar la impresin de que el entrevistador anda a la pesca sin un objetvo real en la entrevista.

Preguntas Cerradas: Pregunta que limita la respuesta del entrevistado a un numero, o a un si o un no.

Ventajas de usar preguntas cerradas:

Ahorrar tempo.
Comparar las entrevistas fcilmente
Ir al grano.
Mantener el control durante toda la entrevista.
Cubrir terreno rpidamente
Conseguir datos relevantes.

Desventajas de usar preguntas cerradas:

Aburren al entrevistado.
No permiten obtener gran cantdad de detalles.
Olvidar ideas principales por la razn anterior.
No ayuda a forjar una relacin cercana entre el entrevistador y el entrevistado.

Sondeos: Un tercer tpo de pregunta es el sondeo o seguimiento. El sondeo mas profundo es el mas simple: La pregunta
Por qu?, otros sondeos son Me puede dar un ejemplo? Y Me lo puede explicar con detalle?. El propsito del sondeo
es ir ms all de la respuesta inicial para conseguir mayor signifcado, califcar, obtener y ampliar la opinin del
entrevistado. Los sondeos pueden constar de preguntas abiertas o cerradas.

Colocar preguntas en una secuencia lgica

Estructura pirmide: El entrevistador empieza con preguntas, a menudo cerradas, muy detalladas. Posteriormente, el
entrevistador extende los temas permitendo preguntas abiertas y respuestas mas generalizadas. Se debe utlizar la
pirmide si cree que su entrevistado necesita motvacin para profundizar en el tema.
Estructura de embudo: Iniciar con preguntas generales y abiertas y luego limitar las posibles respuestas utlizando
preguntas cerradas. El uso del mtodo de estructura de embudo proporciona una forma cmoda y sencilla de empezar
una entrevista. La secuencia de preguntas de forma embudo tambin es tl cuando el entrevistado tene opciones fuertes
acerca del tema y necesita libertad para expresar sus emociones.
Estructura de diamante: Combinacin de las 2 anteriores. Empezar de una manera muy especfca, despus se
examinan los aspectos generales y fnalmente se termina con una conclusin muy especfca.

Diseo de conjunto de aplicaciones (JAD)

Experimentar situaciones en las cuales las entrevistas uno a uno, no parecern tan tles como usted quisiera. IBM
desarrollo un mtodo alternatvo para entrevistar a los usuarios uno a uno, conocido como diseo conjunto de
aplicaciones (Joint Applicaton Design, JAD). Las razones para usar JAD es reducir el tempo (y el costo), mejorar la calidad
de los resultados de la evaluacin de los requerimientos de informacin y generar una mayor identfcacin del usuario
con los nuevos sistemas de informacin como resultado de los procesos partcipatvos. Tiene un carcter interactvo y
tene mucho en comn con las tcnicas de lluvia de ideas.

Ventajas:

-Reduccin del tempo y el costo.
-Mejor calidad de resultados de la evaluacin de los requerimientos.
-Ayuda a los usuarios a involucrarse en las etapas de los proyectos de sistemas.
-Desarrollo de diseos creatvos.

Desventajas:

-Requiere que los partcipantes dediquen mucho tempo.
-El xito de las sesiones JAD es menos predecible.
-No puede ser aplicado en cualquier organizacin.


Cuestonarios

El uso de cuestonarios es una tcnica de recopilacin de informacin que permite a los analistas de sistema estudiar las
acttudes, creencias, comportamientos y caracterstcas de muchas personas importantes en la organizacin que podran
resultar afectadas por los sistemas actuales y propuestos. Las acttudes consisten en lo que las personas de la organizacin
dicen que quieren, las creencias son lo que las personas realmente piensan que es verdad, el comportamiento es lo que
los miembros de la organizacin hacen y las caracterstcas son las propiedades de las personas o cosas.Puede ser usado
para encuestar una muestra considerable de usuarios con el fn de detectar problemas o poner de manifesto cuestones
importantes antes de que se realicen las entrevistas. Si bien se puede recopilar mucha informacin a travs de los
cuestonarios sin invertr tempo en las entrevistas cara a cara, el desarrollo de un cuestonario tl implica una
considerable cantdad de tempo de planeacin.

Vamos a usar cuestonarios en los siguientes casos:

Las personas que necesita encuestar se encuentran en ubicaciones dispersas.
Una gran cantdad de personas estn involucradas en el proyecto de sistemas, y es importante saber que proporcin de
un grupo dado aprueba o desaprueba una caracterstca especfca del sistema propuesto.
Est haciendo un estudio preliminar y desea medir la opinin general antes de que se determine el rumbo que tomar el
proyecto de sistemas.
Desea tener la certeza de que en las entrevistas de seguimiento se identfcara y abordar cualquier problema relacionado
con el sistema actual.

Redaccin de preguntas:

Las entrevistas permiten interaccin entre las preguntas y su signifcado y el analista tene la oportunidad de refnar una
pregunta, defnir un trmino confuso, cambiar el curso de las preguntas, responder a una mirada desconcertada y
controlar generalmente el contexto.
En un cuestonario solo se pueden aprovechar alguna de estas oportunidades, por lo tanto para el analista, las preguntas
deben tener sufciente claridad, el fujo del cuestonario debe ser convincente, las preguntas de los encuestados deben
antciparse y la aplicacin del cuestonario debe planearse en detalle.
Aqu las preguntas tambin pueden ser abiertas o cerradas, pero si hacemos preguntas abiertas debe situar mas en el
contexto al entrevistado para obtener respuestas sobre lo que queremos, ya que las abiertas pueden ser muy generales y
nos pueden responder cosas que no nos interesan. En el caso de las preguntas cerradas el analista las debe usar cuando
puede listar efcazmente todas las posibles respuestas.

Ventajas:

-Permite relevar informacin de un gran nmero de personas en poco tempo.
-Las preguntas estandarizadas proporcionan datos ms confables.

Desventajas:

-No es posible observar expresiones o relaciones.
-Puede necesitarse un seguimiento del cuestonario para motvar al personal que lo responda. -El
desarrollo y distribucin de los cuestonarios es costoso y lleva tempo.
Mtodos no intrusivos.

Muestreo:

Es el proceso que consiste en seleccionar sistemtcamente elementos representatvos de una poblacin. Cuando dichos
elementos se examinan con cuidado, se da por hecho que el anlisis revelar informacin tl de la poblacin en general.

Ventajas:

-Es un mtodo econmico.
-La recopilacin de datos y obtencin de resultados es rpida.
-Una muestra ofrece mejor calidad y precisin de los datos. -Reduce
la parcialidad.

Desventajas:

-Es posible seleccionar una muestra inadecuada.

Investgacin:

Es la accin de descubrir y analizar los datos. Los datos examinados pueden cuanttatvos o cualitatvos.


Anlisis de documentos cuanttatvos:

-Informes usados para la toma de decisiones: documentos que se usan para dirigir un negocio, referentes al estado del
inventario, ventas o produccin.
-Informes de desempeo: refejan el desempeo real vs el deseado.
-Registros: proporcionan actualizaciones peridicas de lo que ocurre en el negocio. -Formularios
de captura de datos

Anlisis de documentos cualitatvos:

-Memorados
-Carteles o pancartas
-Sitos web corporatvos
-Manuales
-Manuales de poltcas

Ventajas:

-Permite conocer a la organizacin en su esencia.

Desventajas:

-Es un proceso bastante esforzado.
-La recopilacin de datos es lenta.

Observacin:

-Observacin del comportamiento del tomador de decisiones: Consiste en identfcar con exacttud lo que un gerente
hace. Permite ver personalmente la manera en que un gerente recopila, procesa, comparte y usa la informacin para
realizar su trabajo.

Ventajas:

-Permite conocer el procesamiento de la informacin rpidamente al ver las operaciones personalmente.
-Observando se pueden obtener datos que no se podran obtener de otra forma.

Desventajas:

-La recopilacin de datos es lenta y minuciosa.

-Observacin del entorno fsico: Consiste en examinar sistemtcamente las ofcinas de los tomadores de decisiones. Esto
pone de manifesto muchos de sus requerimientos de informacin.

Ventajas:

-Permite reconocer los elementos que se usan en el procesamiento de la informacin. -Observando
se pueden obtener datos que no se podran obtener de otra forma.



Desventajas:

-La recopilacin de datos es lenta y minuciosa.

Otras Herramientas

El Foro
La Mesa Redonda
El Panel
El Phillips 66 Torbellino
De Ideas
Otras

UNIDAD N 7
EL PROCESO DE ESPECIFICACIN DE REQUERIMIENTOS

Especifcacin de requerimientos.

La especifcacin de requerimientos es el proceso de realizar una descripcin detallada y precisa de los requerimientos del
sistema. Debe servir de base para la elaboracin de un contrato entre el cliente y el equipo de desarrollo. Permite
describir a travs de modelos grfcos la funcionalidad del sistema.

Tcnicas de la especifcacin de requerimientos.

Entrevistas y Cuestonarios. (vistos en la unidad 6).
Lluvia de ideas.
Prototpos.
Anlisis Jerrquico.
Casos de Uso.

Herramientas de la especifcacin de requerimientos.

Algunas de las herramientas que nos permiten realizar la especifcacin de requerimientos y realizar la ERS son:

Diagramas de clases (descripcin en la unidad 4)
Descripcin de casos de uso (Plantllas) (No pertenecen a UML): Consiste en describir para cada CU identfcado, la
secuencia de acciones que se llevan a cabo para cumplir con el objetvo del mismo. Las descripciones de casos de uso son
reseas textuales del caso de uso. Normalmente tenen el formato de una nota o un documento relacionado de alguna
manera con el caso de uso. Hay dos formas de realizarla:
-Trazo grueso: describe en forma narrada y general las acciones principales que son realizadas en un CU. Complejidad y
prioridad baja.
-Trazo fno: describe en forma detallada la secuencia de acciones que se llevan a cabo, defniendo el curso normal que se
llevara a cabo en el CU y las respectvas alternatvas al curso normal. Complejidad y prioridad media y alta.
Diagrama de casos de uso: Los diagramas de casos de uso describen las relaciones y las dependencias entre un grupo de
casos de uso y los actores partcipantes en el proceso. No estn pensados para representar el diseo y no puede describir
los elementos internos de un sistema. Sirven para facilitar la comunicacin con los futuros usuarios del sistema, y con el
cliente, y resultan especialmente tles para determinar las caracterstcas necesarias que tendr el sistema. permite que los
desarrolladores y los clientes lleguen a un acuerdo sobre los requisitos, es decir sobre lo que debe cumplir el sistema y
consttuye la entrada principal para el anlisis, el diseo y las pruebas. En otras palabras, los diagramas de casos de uso
describen qu es lo que debe hacer el sistema, pero no cmo. Se emplean para modelar la vista de CU de un sistema y as
tambin modelar el comportamiento de un sistema o subsistema.
Son importantes para visualizar, especifcar y documentar el comportamiento de un elemento.
Diagrama de actvidad: Los diagramas de actvidad permiten describir como un sistema implementa su funcionalidad.
Modelan el comportamiento dinmico de un procedimiento, transaccin o caso de uso haciendo nfasis en el proceso que
se lleva a cabo. Son uno de los elementos de modelado que son mejor comprendidos por todos, ya que son herederos
directos de los diagramas de fujo.
Prototpos de interfaz: Los prototpos son una representacin limitada de un producto, permite a las partes probarlo en
situaciones reales o explorar su uso, creando as un proceso de diseo de iteracin que genera calidad.
Un prototpo puede ser cualquier cosa, desde un trozo de papel con sencillos dibujos a un complejo sofware.

El documento de especifcacin de requerimientos de sofware

Como resultado del desarrollo del PIR se obtene el Documento de Especifcacin de requerimientos de sofware (ERS). Es
un documento que contene todos los requerimientos funcionales y no funcionales descriptos de manera completa, precisa
y verifcable. Es una de las documentaciones ms importantes. Establece lo que se espera del sistema. NO es un documento
de diseo. Contene tanto los requerimientos del usuario como los del sistema.

--Los destnatarios de la ERS son varios, desde los administradores principales de la organizacin (quienes pagan) hasta los
ingenieros responsables del sofware.

--Los encargados de la aprobacin fnal de la ERS son los administradores de la organizacin (quienes pagan).

--La ERS es independiente de la tecnologa de modelado, debido a que establece QUE hace y no COMO lo hace.

--Quien la confecciona es el jefe de proyecto.

--Los que la utlizan en el proceso de desarrollo son:

-Lider del proyecto
-Desarrolladores
-Diseadores
-Cliente
-Testng
-Administradores

--Estructura del documento:

-Introduccin: Caracterstcas y objetvos del sistema.
-Glosario: Defnicin de trminos tcnicos utlizados.
-Descripcin general.
-Requerimientos.
-Apndice.
-ndice.

Proceso de gestn de cambios
Cuando los requerimientos cambian o varan se realiza este proceso para validar los nuevos cambios y as poder modifcar la
ERS.

Modelizacin

Los requerimientos del usuario deben redactarse en lenguaje natural para que sean comprendidos por personas que no son
tcnicos expertos. Sin embargo, los requerimientos del sistema ms detallados se expresan en una forma ms tcnica. Una
tcnica muy utlizada es la modelizacin, tcnica para documentar la especifcacin del sistema como un conjunto de
modelos.
Los modelos son representaciones grfcas que describen el problema a resolver y el sistema a desarrollar. Son un puente
importante entre los procesos de anlisis y diseo. Es una abstraccin del sistema que omite los detalles irrelevantes al
dominio del problema, y simplifca el mismo.

Modelos de contexto
Se utliza para defnir los lmites del sistema y su relacin con los stakeholders.

Modelos de comportamiento

stos se utlizan para describir el comportamiento del sistema. Existen dos tpos de modelos de comportamiento:

Modelos de fujo de datos: son una forma de mostrar la manera en que un sistema procesa los datos. Se utlizan para
mostrar cmo fuyen los datos a travs de una secuencia de pasos de procesamiento.
Modelos de mquinas de estado: se utlizan para modelar el comportamiento de un sistema en respuesta a eventos.
Muestra los estados del sistema y los eventos que provocan las transiciones de un estado a otro.

Modelos de datos

Muchos de los sistemas de sofware grandes utlizan bases de datos de informacin de gran tamao. A menudo, los
modelos de datos se utlizan en conjunto con los de fuljo de datos para describir la estructura de la informacin que se est
procesando.

Modelos de objetos

Se utlizan para representar los datos del sistema y su procesamiento.
UNIDAD N 8
EL PROCESO DE VALIDACIN DE REQUERIMIENTOS

La validacin de requerimientos es el proceso mediante el cual se verifcan los mismos. Es el proceso de demostrarle al
cliente que el sistema hace lo que l pidi. Es importante validar porque se sacan errores sin corregir, sin pagar un costo
tan alto cuando el sistema est terminado.
Debe asegurar que los requisitos del sistema han sido establecidos sin ambigedad, sin inconsistencias, sin omisiones, que
los errores detectados fueron corregidos, y que el resultado del trabajo se ajusta a los estndares establecidos para el
proceso, proyecto y producto.

Tipos de validacin:

-Validez: comprobar que la funcin que pidi el cliente no sea parte de otro sistema o no sea de otra funcin. -Consistencia:
Que no haya contradicciones en los requerimientos.
-Realismo: Si se puede llevar a cabo o no con la tecnologa actual.
-Integridad: Que cubra todos los aspectos que el cliente pidi (funcionales y no funcionales). -Verifcabilidad:
Que se puedan demostrar con casos de prueba.

Tcnicas de validacin de requerimientos:

Revisiones de requerimientos: Las revisiones de requisitos consisten en reuniones donde un equipo de analistas
intenta localizar errores en el documento de especifcacin.
Generacin de casos de prueba: Este mtodo tene como objetvo comprobar la verifcabilidad de los requisitos.
Consiste en la defnicin de casos de prueba que permitan verifcar el cumplimiento de los requisitos funcionales.
Anlisis de consistencia automtco.
Construccin de prototpos.

Construccin de prototpos:

Prototpo: Versin inicial del sofware. Se utiza para demostrar los conceptos, probar las opciones de diseo, enterarse
ms acerca del problema y sus posibles soluciones. Ayudan a:

Obtencin de requerimientos: pueden proponer nuevos requerimientos del sistema.
Validacin de requerimientos: puede relevar errores y omisiones en los requerimientos propuestos.
Capacitar al usuario.
Probar el sistema.

Ventajas:

-Mejora el uso del sistema.
-Mejora el rendimiento.
-Mejora el acoplamiento entre el sistema y las necesidades del usuario.
-Mejora la calidad del diseo.
-Reduce el esfuerzo de desarrollo.

Tipos de prototpos

-Desechables: Se construyen para validar o derivar los requerimientos del sistema. Se debe iniciar con aquellos
requerimientos que no se comprendan bien ya que se requiere saber ms de ellos. Los requerimientos que son precisos
nunca deben estar en el prototpo.
Tienen un ciclo de vida corto. Se permite un desempeo pobre y una baja fabilidad puesto que su funcin principal es
ayudar a la comprensin de los requerimientos. El prototpo se escribe, evala y modifca.
-Evolutvos: El objetvo de la construccin de prototpos evolutvos es entregar a los usuarios fnales un sistema funcional.
La construccin de prototpos evolutvos inicia con un sistema relatvamente simple que implementa los requerimientos
ms importantes del usuario. Dicho prototpo se aumenta o cambia en cuanto se descubren nuevos requerimientos.

INTERFACES DE USUARIO

La construccin de prototpos es una parte esencial del proceso de diseo de la interfaz de usuario. Las descripciones
textuales y los diagramas no son sufcientemente buenos para expresar los requerimientos de dicha interfaz. Por lo tanto,
la construccin de prototpos evolutvos con la partcipacin del usuario fnal es la nica forma sensible para desarrollar
interfaces grfcas de usuario para los sistemas de sofware.




Diseo de la interfaz de usuario

Para que el sistema tenga xito, es importante contar con un buen diseo de la interfaz de usuario. Una interfaz difcil de
utlizar provocar que los usuarios cometan muchos errores, o simplemente se rehusarn a utlizar el sistema de sofware
sin tomar en cuenta su funcionalidad. Si la informacin se presenta de una forma confusa o engaosa, los usuarios no
comprendern el signifcado de la informacin. Las ventajas de las GUIs son:

Son relatvamente fciles de aprender y utlizar.
Para interactuar con el sistema, los usuarios cuentan con pantallas mltples.
Es posible interactuar rpidamente y tener acceso inmediato a cualquier punto de la pantalla.

Principio de diseo de la interfaz de usuario

Familiaridad del usuario: la interfaz debe utlizar trminos y conceptos que utlizan las personas que usaran el
sistema, o bien que sean familiares.
Consistencia: las operaciones provistas por la interfaz deben ser iguales que las que se realizaran sin la
automatzacin.
Mnima sorpresa: el comportamiento del sistema no debe provocar sorpresa a los usuarios.
Recuperabilidad: la interfaz debe incluir mecanismos para permitr a los usuarios recuperarse de los errores.
Gua al usuario: cuando los errores ocurren, la interfaz debe proveer retroalimentacin signifcatva y
caracterstcas de ayuda sensible al contexto.
Diversidad de usuarios: la interfaz debe proveer caracterstcas de interaccin apropiada para los diferentes tpos
de usuarios del sistema.

Relacin GUI-CU

Por cada caso de uso puedo tener:

- 1 GUI
- + 1 GUI
-Ninguna GUI (Procesos automtcos que no necesitan interaccin con el usuario).

Por cada GUI puedo tener:

- + 1 CU

Elementos que pueden conformar una GUI

-Campo de texto: El usuario escribe en l.

Cliente:

-Lista desplegable: Para que el usuario elija entre varias opciones.

Cliente:

-Lista: como la desplegable, pero toda visible.


-Grilla:

-Seleccionar una opcin:

A

B








C
-Botn; Una funcionalidad del caso de uso.




-Seleccionar ms de una opcin:

A
B
C
D

Aspectos a tener en cuenta en el diseo de la GUI

1. Lo ms importante va en la esquina superior izquierda. El
sentdo de la secuencia de acciones sera:



2. No dejar espacios en blanco. 3. Lenguaje del usuario
4. Esttca:

-Alineacin
-Colores
-Tipo y tamao de letra
-Imgenes
-Sonido-efectos
5. Distribucin
6. Claridad, facilidad de uso, que sea intuitvo.


Tipos de ventanas:

- Ventanas de aplicacin
- Ventanas desplegables: Vuelvo a la principal.
- Ventanas hijas: para guardar los datos, no vuelvo necesariamente a la madre.
- Ventanas de respuesta.
- Marcos MDI: Men de opciones.
- Ventanas fchas o pestaas.

UNIDAD N 9
EL FLUJO DE TRABAJO DE REQUERIMIENTOS

Cuando un grupo de desarrolladores de sofware debe desarrollar un nuevo sistema tene que descubrir por s mismo lo
que se necesita.
Llamamos captura de requisitos a este acto de descubrimiento. Es el proceso de averiguar, normalmente en circunstancias
difciles, lo que se debe construir.
Modifcar Cancelar
Nuevo

Porqu la captura de requisitos es complicada

Con frecuencia los usuarios no saben cules son los requisitos ni tampoco cmo especifcarlos de una forma precisa.
La aproximacin tradicional a este problema ha sido asignar intermediarios analistas- para obtener una lista de requisitos
de cada usuario con la esperanza de que el analista fuese capaz de tener una visin de conjunto y de componer una
especifcacin de requisitos completa, correcta y consistente.
Incluso con la ayuda de los analistas, los usuarios no comprendan del todo lo que el sistema sofware debera hacer hasta
que el sistema estaba casi terminado.
Durante aos nos hemos engaado a nosotros mismos creyendo que los usuarios saben cules son los requisitos y que lo
nico que tenemos que hacer es entrevistarnos con ellos.
La captura de requisitos es difcil y la industria lleva buscando un proceso bueno, sistemtco para llevarla a cabo desde
hace mucho tempo.

Objeto del fujo de trabajo de los requisitos.

El propsito fundamental del FTR es guiar el desarrollo hacia el sistema correcto. Esto se consigue mediante una
descripcin de los requisitos del sistema sufcientemente buena como para que pueda llegarse a un acuerdo entre el
cliente y los desarrolladores sobre qu debe y qu no debe hacer el sistema.
Un reto fundamental para conseguirlo es que el cliente debe ser capaz de leer y comprender el resultado de la captura de
requisitos. Para alcanzar este objetvo debemos utlizar el lenguaje del cliente para describir esos resultados.
Los resultados del fujo de trabajo tambin ayudan al jefe de proyecto a planifcar las iteraciones y las versiones del cliente.

Visin general de la captura de requisitos

Este fujo de trabajo incluye los siguientes pasos, que en realidad no se llevan a cabo separadamente:

Enumerar los requisitos candidatos: durante la vida del sistema, los clientes, usuarios y desarrolladores aparecen con
buenas ideas que podran convertrse en verdaderos requerimientos. Se mantene una lista de estas ideas, que
consideramos como un conjunto de requisitos candidatos que podemos decidir implementar en una versin futura del
sistema. Esta lista de caracterstcas crece a medida que se aaden nuevos elementos y mengua cuando algunas
caracterstcas se convierten en requerimientos y se transforman en otros artefactos como CU. La lista de caracterstcas se
utliza slo para la planifcacin del trabajo.
Cada caracterstca tene un nombre corto y una breve explicacin o defnicin, informacin sufciente para poder hablar
de ella durante la planifcacin del producto. Cada caracterstca tene tambin un conjunto de valores de planifcacin que
podramos incluir:
-Estado (propuesto, aprobado, incluido o validado).
-Coste estmado de implementacin (en trminos de tpos de recursos y horas-persona).
- Prioridad (crtco, importante o secundario).
-Nivel de riesgo asociado a la implementacin de la caracterstca (crtco, signifcatvo u ordinario).

Estos valores de planifcacin se utlizan junto con otros aspectos para estmar el tamao del proyecto y para decidir cmo
dividir el proyecto en una secuencia de iteraciones.

Comprender el contexto del sistema: muchas de las personas implicadas en el desarrollo de sofware son
especialistas en temas relatvos al sofware. Sin embargo, los desarrolladores clave requieren un frme
conocimiento del contexto en el que se emplaza el sistema. Hay dos formas para expresar el contexto de un
sistema en una forma utlizable para desarrolladores de sofware:
Modelado del dominio.
Modelado del negocio.

Capturar requisitos funcionales: Son servicios que brindar el sistema. La tcnica para identfcar los
requerimientos del sistema se basa en los CU. Estos CU capturan tanto los requisitos funcionales como los no
funcionales que son especfcos de cada caso de uso. Para el usuario, un CU es un modo de utlizar el sistema; si
los analistas describen todos los CU que necesita el usuario, entonces saben lo que debe hacer el sistema.
Capturar requisitos no funcionales: los RNF especifcan las propiedades del sistema, como restricciones del
entorno o de la implementacin, rendimiento, dependencias de la plataforma, facilidad de mantenimiento,
extensibilidad y fabilidad. Estos requerimientos pueden capturarse al principio en el objeto del dominio o del
negocio correspondiente en el modelo de contexto del sistema.


Los requerimientos en el ciclo de vida del sofware

El modelo de CU se desarrolla a lo largo de varios incrementos del desarrollo, donde las iteraciones aadirn nuevos CU y/o
aadirn detalle a las descripciones de los CU existentes.
El fujo de trabajo de requisitos se hace fundamentalmente durante el inicio y la elaboracin.

Durante la fase de inicio, los analistas identfcan la mayora de los CU para delimitar el sistema y el alcance del
proyecto y para detallar los ms importantes.
Durante la fase de elaboracin, los analistas capturan la mayora de los requerimientos restantes para que los
desarrolladores puedan estmar el tamao del esfuerzo de desarrollo que se requerir. El objetvo es haber
capturado sobre un 80 por ciento de los requisitos y haber descrito la mayora de los casos de uso al fnal de esta
fase de elaboracin.
Los requerimientos restantes se capturan (e implementan) durante la fase de construccin.
Casi no hay captura de requerimientos en la fase e transicin, a menos que haya requerimientos que cambien.


COMPRENSIN DEL CONTEXTO

Comprensin del contexto del sistema mediante un Modelo del dominio.

Un modelo del dominio captura los tpos ms importantes de objetos en el contexto del sistema. Los objetos del dominio
representan las cosas que existen o los eventos que suceden en el entorno en el que trabaja el sistema. Muchos de los
objetos del dominio o clases pueden obtenerse de una especifcacin de requerimientos o mediante una entrevista con
los expertos del dominio. Las clases del dominio aparecen en tres formas tpicas:

-Objetos del negocio que representan cosas que se manipulan en el negocio, como pedidos cuentas y contratos.
-Objetos del mundo real y conceptos de los que el sistema debe hacer un seguimiento, como la aviacin enemiga, misiles y
trayectorias.
-Suceso que ocurrirn o han ocurrido, como la llegada de un avin, su salida y la hora de la comida.

El modelo del dominio se describe mediante diagramas de UML (especialmente mediante diagramas de clases).
Estos diagramas muestran a los clientes, usuarios, revisores y a otros desarrolladores las clases del dominio y cmo se
relacionan unas con otras mediante asociaciones.

Comprensin del contexto del sistema mediante un Modelo del negocio

El modelo del negocio es una tcnica para comprender los procesos de negocio de la organizacin. Describe los procesos
del negocio.
El modelado del negocio est soportado por dos tpos de modelos de UML: modelos de CU y modelos de objetos.

Un modelo de CU del negocio describe los procesos de negocio de una empresa en trminos de CU del negocio y actores
del negocio que se corresponden con los procesos del negocio y los clientes, respectvamente. Al igual que el modelo de
casos de uso para un sistema sofware, el modelo de CU del negocio presenta un sistema desde la perspectva de su uso, y
esquematza cmo proporciona valor a sus usuarios.
El modelo de CU del negocio se describe mediante diagramas de CU.

Un modelo de objetos del negocio es un modelo interno a un negocio. Describe cmo cada CU de negocio es llevado a
cabo por parte de un conjunto de trabajadores del negocio (TN) que utlizan un conjunto de entdades del negocio (EN) y
de unidades de trabajo. Cada realizacin de un caso de uso del negocio puede mostrarse en diagramas de interaccin y
diagramas de actvidad.
Una EN representa algo (como una factura) que los TN toman, inspeccionan, manipulan, producen o utlizan en un CU de
negocio. Una unidad de trabajo es un conjunto de esas entdades que conforma un todo reconocible para un usuario fnal.
Las entdades del negocio y las unidades de trabajo se utlizan para representar los mismos tpos de conceptos que las
clases del dominio.
Cada trabajador, entdad del negocio, y unidad de trabajo pueden partcipar en la realizacin de ms de un caso de uso del
negocio.
Un modelo del negocio se desarrolla en dos pasos:

1- Los modeladores del negocio deben confeccionar un modelo de casos de uso del negocio que identfque los actores
del negocio y los casos de uso del negocio que utlicen los actores. Este modelo permite a los modeladores comprender
mejor qu valor proporciona el negocio a sus actores.
2- Los modeladores deben desarrollar un modelo de objetos del negocio compuesto por trabajadores, entdades del
negocio, y unidades de trabajo que juntos realizan los casos de uso del negocio. Se asocian a estos diferentes objetos las
reglas del negocio y otras normas impuestas por el negocio.

El modelado del negocio y el modelado del dominio se parecen en muchos aspectos. De hecho, podemos pensar en el
modelado del dominio como en una variante simplifcada del modelado del negocio, en la cual nos centramos slo en las
cosas, es decir, las clases del dominio o entdades del negocio que necesitan usar los trabajadores. Por tanto las clases
del dominio y las entdades del negocio son conceptos muy parecidos, y utlizamos ambos trminos indistntamente. Sin
embargo, existen algunas diferencias importantes entre el modelado del negocio y el modelado del dominio que hacen
mucho ms recomendable el realizar el ms completo modelado del negocio.

CAPTURA DE REQUERIMIENTOS COMO CU

El esfuerzo principal en el FTR es desarrollar un modelo del sistema que se va a construir, y la utlizacin de los CU es una
forma adecuada de crear este modelo. Esto es debido a que los RF se estructuran de forma natural mediante CU, y a que la
mayora de los RNF son especfcos de un solo CU, y pueden tratarse en el contexto de ese CU.
Los requisitos no funcionales restantes, aquellos que son comunes para muchos o para todos los casos de uso, se
mantenen en un documento aparte y se denominan requisitos adicionales.

Vamos a describir el FTR en tres pasos:

Los artefactos creados en el fujo de trabajo de los requisitos.
Los trabajadores partcipantes en el fujo de trabajo de los requisitos.
El fujo de trabajo de captura de requisitos, incluyendo cada actvidad en ms detalle.


ARTEFACTOS

Modelo de CU

El modelo de CU permite que los desarrolladores de sofware y los clientes lleguen a un acuerdo sobre los requerimientos,
es decir las condiciones y posibilidades que debe cumplir el sistema. Un modelo de CU es un modelo del sistema que
contene actores, CU y sus relaciones. Tiene la funcionalidad completa del SI. Me permite encontrar las clases para la
realizacin de cada caso de uso y a partr de estos casos de uso se realiza al interfaz.

Actor

El modelo de CU describe lo que hace el sistema para cada tpo de usuario. Cada uno de stos se representa mediante uno
o ms actores. Un actor es el rol que juega un usuario en relacin al sistema. Normalmente, un actor representa un rol que
es jugado por una persona, un dispositvo de hardware o incluso otro sistema al interactuar con nuestro sistema.
Una vez identfcados todos los actores, tenemos identfcado el entorno externo al sistema. Los
actores suelen corresponderse con TN en un negocio.
Un actor juega un papel por cada caso de uso con el que colabora. Cada vez que un usuario en concreto interacta con el
sistema, la instancia correspondiente del actor est desarrollando ese papel. Una instancia de un actor es un usuario
concreto que interacta con el sistema. Cualquier entdad que se ajuste a un actor puede actuar como una instancia del
actor.

Los Actores pueden ser:

Actor Primario: Tiene un objetvo claro que debe ser tenido en cuenta y concretado con la ayuda del sistema de
informacin. Es aquel actor para el cual el CU ha sido desarrollado.
Actor Secundario: Es de quin el sistema necesita ayuda para cumplir con el objetvo del actor primario.


Caso de Uso

Cada forma en que los actores usan el sistema se representa con un CU. Los CU son fragmentos de funcionalidad que el
sistema ofrece para aportar un resultado de valor para sus actores. Un CU especifca una secuencia de acciones que el
sistema puede llevar a cabo interactuando con sus actores, incluyendo alternatvas dentro de la secuencia.

Un CU es una especifcacin del comportamiento de cosas dinmicas (instancias de CU). Una instancia de caso de uso es
la realizacin (o ejecucin) de un caso de uso.
Segn el vocabulario de UML, un caso de uso es un clasifcador, lo cual quiere decir que tene operaciones y atributos. Una
descripcin de un caso de uso puede por tanto incluir diagramas de estados, diagramas de actvidad, colaboraciones, y
diagramas de secuencia.
Los diagramas de estados especifcan el ciclo de vida de las instancias de los casos de uso en trminos de estados y
transiciones entre los estados.
Los diagramas de actvidad describen el ciclo de vida con ms detalle describiendo tambin la secuencia temporal de
acciones que tene lugar dentro de cada transicin. Los diagramas de colaboracin y los de secuencia se emplean para
describir las interacciones entre, por ejemplo, una instancia tpica de un actor y una instancia tpica de un caso de uso. La
mayora de las veces es una instancia de un actor la que invoca a la instancia del caso de uso, pero tambin puede ser un
evento interno al sistema el que invoque a la instancia.
Al ser un clasifcador, los casos de uso tenen atributos, que representan los valores que una instancia de un caso de uso
utliza y manipula durante la ejecucin de su caso de uso. Estos valores son locales a la instancia del caso de uso, es decir,
no pueden ser utlizados por otras instancias del caso de uso.
Las instancias de los casos de uso no interactan con otras instancias de casos de uso. El nico tpo de interacciones en el
modelo de casos de uso tene lugar entre instancias de actores e instancias de casos de uso. El motvo es que queremos
que el modelo de casos de uso sea simple e intuitvo. Consideramos atmicas las instancias de casos de uso, es decir, cada
una de ellas se ejecuta por completo o no se ejecuta nada, sin interferencias por parte de otras instancias de casos de uso.
Por tanto el comportamiento de cada caso de uso puede interpretarse independientemente del de otros casos de uso, lo
cual hace ms sencillo el modelado de casos de uso.

Descripcin de la arquitectura (vista del modelo de CU)

La descripcin de la arquitectura contene una vista de la arquitectura del modelo de CU, donde se describen los CU ms
importantes.
La vista de la arquitectura del modelo de CU debera incluir los CU que describan alguna funcionalidad importante y crtca,
o que impliquen algn requisito importante que deba desarrollarse pronto dentro del ciclo de vida del sofware. Esta vista
de la arquitectura se utliza como entrada cuando se priorizan los CU para su desarrollo (anlisis, diseo, implementacin)
dentro de cada iteracin.

Glosario

Podemos utlizar un glosario para defnir trminos comunes importantes que los analistas utlizan al describir el sistema.
Un glosario es muy tl para alcanzar un consenso entre los desarrolladores y para reducir en general el riesgo de
confusiones.

Prototpo de interfaz de usuario

Los prototpos de interfaz de usuario nos ayudan a comprender y especifcar las interacciones entre actores humanos y el
sistema durante la captura de requisitos. No slo nos ayuda a desarrollar una interfaz grfca mejor sino tambin a
comprender mejor los CU.
En la actvidad de especifcacin de requerimientos la funcin principal de los prototpos de interfaz es derivar y validar los
requerimientos esenciales de informacin de los usuarios, manteniendo abiertas, al mismo tempo, las opciones de
implementacin.


TRABAJADORES


Un trabajador es un puesto al cual se puede asignar una persona real. Con cada trabajador tenemos una descripcin de
las responsabilidades y el comportamiento esperado del mismo. Un trabajador no es lo mismo que un individuo; una
misma persona puede estar asignada a diferentes trabajadores durante un proyecto. Un trabajo tampoco se corresponde
con un puesto o cargo concreto en una empresa.
Un trabajador representa una abstraccin de un ser humano con ciertas capacidades que se requieren en un CU del
negocio.
Podemos identfcar tres trabajadores que partcipan en el modelado de CU:

Analista de sistemas.
Especifcador de CU.
Diseador de interfaz grfca.


Analista de sistemas

El analista de sistemas es el responsable del conjunto de requerimientos que estn modelados en los CU, lo que incluye
todos los RF y RNF.
El analista de sistemas es responsable de delimitar el sistema, encontrando los actores y los CU y asegurando que el modelo
de casos de uso es consistente y completo.
Aunque el analista de sistemas es responsable del modelo de casos de uso y de los actores que contene, no es
responsable de cada CU en partcular; esto es responsabilidad del especifcador de CU. El analista de sistemas es tambin
el que dirige el modelado y el que coordina la captura de requerimientos.
Hay un analista de sistemas para cada sistema. No obstante, en la prctca, este trabajador est respaldado por un equipo
que incluye otras personas que tambin trabajan como analistas.

Especifcador de CU

El especifcador de CU es el encargado de describir detalladamente uno o ms CU. Cada especifcador de CU necesita
trabajar estrechamente con los usuarios reales de sus casos de uso.

Diseador de interfaz de usuario

Los diseadores de interfaces de usuario son los responsables del aspecto visual del sistema. Esto puede implicar el
desarrollo de prototpos de interfaces de usuario para algunos CU, habitualmente un prototpo para cada actor.

Arquitecto

El arquitecto partcipa en el FTR para describir la vista de la arquitectura del modelo de CU. Es el responsable de priorizar
cada caso de uso.


ACTIVIDADES (fujo de trabajo)



El diagrama utliza calles para mostrar que trabajadores ejecutan que actvidades; cada actvidad (representadas por
ruedas dentadas) se sita en el mismo campo que el trabajador que la ejecuta. Cuando los trabajadores ejecutan las
actvidades, crean y modifcan artefactos. Describimos los fujos de trabajos como una secuencia de actvidades que estn
ordenadas, as que una actvidad produce una salida que sirve de entrada a la siguiente actvidad. No obstante, el
diagrama de actvidad presenta solamente el fujo lgico. En el mundo real, no es necesario trabajar mediante actvidades
en secuencia. De hecho, podemos trabajar por mltples vias que producen un resultado fnal equivalente. Una actvidad
puede ser retomada muchas veces, y cada una de stas puede acarrear la ejecucin de una sola fraccin de la actvidad.
Primero, el analista de sistemas ejecuta la actvidad de Encontrar Actores y CU para preparar una primera versin del
modelo de CU, con los actores y CU identfcados.
Entonces, el arquitecto identfca los CU relevantes para proporcionar entradas a la priorizacin de CU que van a ser
desarrollados en la iteracin actual.
Hecho esto, los especifcadotes de CU describen todos los CU que se han priorizado. Ms o menos en paralelo, los
diseadores de interfaz de usuario sugieren las interfaces de usuario adecuadas para cada actor basndose en los CU.
Entonces, el analista de de sistemas reestructura el modelo de CU defniendo generalizaciones entre los CU para hacerlo lo
ms comprensible posible.
Los resultados de la primera iteracin a travs de este FT consisten en una primera versin del modelo de CU, los CU y
cualquier prototpo de interfaz de usuario asociado. Los resultados de cualquier iteracin subsiguiente consistrn
entonces en nuevas versiones de estos artefactos.


Encontrar actores y CU

Consiste en encontrar los actores y los CU asociados a cada actor.
La identfcacin de actores y CU es la actvidad ms decisiva para obtener adecuadamente los requerimientos, y es
responsabilidad del analista de sistemas (en conjunto con un equipo que incluye al cliente, los usuarios y otros analistas
que partcipan en talleres de modelado dirigidos por el analista de sistemas).
Esta actvidad consta de cuatro pasos, que no tene por qu ser ejecutados en ningn orden en partcular, y a menudo se
hacen simultneamente.

Encontrar los actores: esta tarea depende de nuestro punto de partda:
A partr de un modelo de negocio: encontrar los actores resulta sencillo. El analista de sistemas puede asignar un actor a
cada trabajador del negocio y un actor a cada actor del negocio.
A partr de un modelo del dominio: el analista de sistemas identfca los usuarios e intenta organizarlos en categoras
representadas por actores.
En ambos casos, se deben identfcar los actores que representan sistemas externos y los actores para el mantenimiento y
operacin del sistema.
El resultado es una nueva versin del artefacto modelo de CU con un conjunto de actores actualizado. Estos actores
brevemente descritos pueden utlizarse como punto de partda para encontrar los CU.

Encontrar los CU: el analista de sistemas va repasando los actores uno por uno y proponiendo los CU para cada
uno. Algunos no llegarn a ser CU por s mismos (podrn ser partes de otros CU). Se elige un nombre para CU (de
forma que nos haga pensar en la secuencia de acciones que aade un valor al actor) que suele comenzar con un
verbo y debe refejar el objetvo de la interaccin entre el actor y el sistema.

Describir brevemente cada CU: el analista de sistemas garabatea unas pocas palabras explicando cada CU.
Despus describe brevemente cada uno.

Describir el modelo de CU completo: se preparan diagramas y descripciones para explicar el modelo de CU en su
totalidad.

Priorizar CU

Dependiendo de las necesidades del cliente se priorizan los casos de uso, determinando cules son necesarios para el
desarrollo en las primeras iteraciones, y cuales pueden dejarse para ms tarde.

Detallar un CU

El objetvo principal de detallar cada CU es describir su fujo de sucesos en detalle, incluyendo cmo comienza, termina e
interactan con los actores.
El especifcador de CU detalla paso a paso la descripcin de cada CU en una especifcacin precisa de la secuencia de
acciones.

Prototpar la interfaz de usuario

El objetvo de esta actvidad es construir un prototpo de interfaz de usuario, que permita al usuario llevar a cabo los casos
de uso de manera efciente. Se le da la cara a la interfaz construyendo el prototpo de interfaz de usuario. El resultado
fnal de esta actvidad es un conjunto de esquemas de interfaces de usuario y prototpos de interfaces de usuario que
especifcan la apariencia de esas interfaces de cara a los actores ms importantes.

Estructurar el modelo de CU

El modelo de CU se estructura para:

Extraer descripciones de funcionalidad generales y compartdas que pueden ser utlizadas por descripciones ms
especfcas (generalizaciones).
Extraer descripciones de funcionalidad adicionales u opcionales que pueden extraer descripciones ms
especfcas (inclusiones y extensiones).


CASOS DE USO

Defnicin en la parte anterior de la unidad.
Los CU:

Son descripciones de la funcionalidad del sistema independientes de la implementacin.
Describen los lmites del sistema y las relaciones entre el sistema y el entorno.
Defnen el conjunto de requerimientos, atendiendo a la categora de usuarios que partcipan en el mismo.
Partcionan en forma de acciones y reacciones, el comportamiento de un sistema desde el punto de vista del
usuario (el usuario debera poder entenderlos para realizar su validacin)

Qu asumimos para la defnicin de Casos de Uso?

Propsito: Determinacin de REQUERIMIENTOS (Funcionales)
Contenido: Descripcin por medio de PROSA CONSISTENTE
Pluralidad: MULTIPLES ESCENARIOS
Estructura: SEMIFORMAL

Tipos de CU

Los CU pueden ser:

Esenciales: describen una funcionalidad principal o esencial con la que tene que cumplir el sistema. Comprenden
los principales procesos que debe ejecutar el sistema de informacin. Poseen la prioridad ms alta, y en estos se
pone esfuerzo en el desarrollo. El usuario fnal paga por los esenciales. De cada 100 CU, 30 son esenciales.
De soporte: Ayudan a los esenciales para que estos puedan funcionar correctamente. Esta funcionalidad surge a
partr de analizar aquello que se necesita para que puedan funcionar los CU esenciales.

Otra clasifcacin:
Concreto: Son aquellos que son instanciados por un actor o trabajador.
Abstracto: son aquellos que nunca sern instanciados por un actor. Son instanciados por otros CU por medio de inclusin
o extensin.

CU y actores

Defnicin de actor en la parte anterior.
Los actores slo se pueden conectar a los CU a travs de asociaciones.

Generalizacin entre actores
Se defne una categora general de actor y se especializa a travs de relaciones de generalizacin. Los actores especializados
(hijos) heredan el comportamiento del actor padre.
Si un CU es instanciado por el actor padre puede ser instanciado por cualquiera de sus hijos. Ahora bien podra haber CU
que son instanciados por uno de los actores hijo en partcular.


Generalizacin

CU y fujo de eventos

Un CU describe qu hace un sistema, pero no especifca cmo lo hace.
El comportamiento de un CU se puede especifcar describiendo un fujo de eventos de forma textual. Cuando se escribe
este fujo de eventos se debe incluir cmo y cundo empieza y acaba el CU, cundo interacta con los actores y qu
objetos se intercambian, el fujo bsico y los fujos alternatvos del comportamiento.

CU y escenarios

Conviene separar el fujo principal de los fujos alternatvos, porque un CU describe un conjunto de secuencias, no una
nica secuencia, y sera imposible expresar todos los detalles de un CU no trivial en una nica secuencia. Para CU puede
haber:

Escenarios principales: defnen secuencias esenciales.
Escenarios secundarios: defnen secuencias alternatvas.

CU y colaboraciones

Un CU debe implementarse y esto se hace creando una sociedad de clases y otros elementos que colaborarn para llevar a
cabo el comportamiento del CU. Esta sociedad de elementos, incluyendo tanto su estructura esttca como dinmica, se
modela en UML como una colaboracin.

Organizacin de CU

Los CU pueden organizarse agrupndolos en paquetes, de la misma manera que se organizan las clases. Los
CU tambin pueden organizarse especifcando relaciones entre ellos:

Inclusin: Relacin dada nicamente entre casos de uso. Parte de la funcionalidad que detecto como comn
entre los CU, al detectarla la pongo aparte. El CU base incorpora explcitamente el comportamiento de otro CU en
el lugar especifcado en el caso base. El CU incluido slo es instanciado como parte de algn CU base ms amplio
que lo incluye.
Vendedor de
mostrador
Viajante
Vendedor
Registrar Venta
Un CU de inclusin es siempre un CU abstracto. La fecha va del CU base al CU abstracto.



Extensin: el CU base incorpora implcitamente el comportamiento de otro CU en el lugar especifcado
indirectamente por el CU que extende al base. El CU puede estar aislado, pero bajos ciertas condiciones su
comportamiento puede extenderse con el comportamiento de otro CU. Se utliza para modelar la parte de un CU
que el usuario puede ver como comportamiento opcional del sistema. Se separa el comportamiento opcional del
obligatorio. El CU opcional se ejecutar bajo ciertas circunstancias. La fecha va del CU de extensin al CU base.


Generalizacin: Se diferencia de la inclusin donde se saca funcionalidad afuera; aqu veo si tengo CU con pasos
comunes o iguales y si es as a estos pasos comunes los pongo aparte en un nuevo CU padre. El CU hijo hereda el
comportamiento del CU padre. El hijo puede aadir o redefnir el comportamiento del CU padre.

con tarjeta


DIAGRAMA DE CASOS DE USO

Defnicin en Unidad 7.

Un diagrama de CU contene:

Casos de uso.
Actores.
Relaciones de dependencia, generalizacin y asociacin.

Usos comunes

Los diagramas de CU se emplean para modelar la vista de CU esttca de un sistema.
Caso de uso base
Caso de uso includo
Recepcionista de
hotel
Reservar Pieza
Eliminar Reserva
Actualizar Reserva
<< inc >>
<< inc >>

Registrar venta
Vendedor
Registrar nuevo cliente
<< extend >>
Caso de uso padre
Registrar Venta
Registrar venta
de contado
Vendedor
Registrar venta
Caso de uso hijo
Cuando se modela la vista de CU esttca de un sistema, normalmente se emplearn los diagramas de CU de una de las dos
formas siguientes:

Para modelar el contexto de un sistema.
Para modelar los requisitos de un sistema.

El modelado de los requisitos de un sistema implica especifcar qu debera hacer el sistema, independientemente de cmo
se haga.

Especifcacin de CU Defnicin
en unidad 7.

Pre-condiciones
Una pre-condicin es una restriccin sobre cundo un CU puede empezar. No es el evento que inicia el CU.

Post-condiciones
Una post-condicin para un CU debe ser verdadera, independientemente de cul fujo sea ejecutado.

A saber: un requerimiento puede incluir 1 o ms CU.

Modelo de casos de uso del SI
Permite que los desarrolladores y los clientes lleguen a un acuerdo sobre los requerimientos que debe cubrir el sistema.

CLASIFICACION: -de Comportamiento (porque tene funcionalidad).
-Esttco (porque no muestra comunicacin ni interrelacin).
-Lgico (porque es conceptual, terico, no lo bajamos a un lenguaje ni a lo fsico.

USO:
-Comunicar el Alcance.
-Proveer descripcin de todo o una parte de los requerimientos de un sistema u organizacin.

MUESTRA: un conjunto de casos de uso, actores y sus relaciones.

CONTIENE comnmente:
-Casos de Uso
-Actores
-Relaciones de extensin, inclusin, generalizacin.
-Paquetes

Construccin del diagrama de casos de uso

Identfcar los Actores
Defnir la funcionalidad esencial relacionada a cada actor a travs de casos de uso.
Identfcar parte de funcionalidad comn y opcional en los casos de uso, y agregar relaciones de inclusin, extensin y
generalizacin.
Defnir casos de uso de soporte, que ayuden a que la funcionalidad principal se cumpla


PATRONES DE CU

Un patrn es una solucin a un problema. Para que una solucin sea considerada un patrn debe poseer ciertas
caracterstcas. Una de ellas es que debe haber comprobado su efectvidad resolviendo problemas similares en ocasiones
anteriores. Otra es que debe ser reusable, lo que signifca que es aplicable a diferentes problemas en distntas
circunstancias.
Los patrones de sofware describen un problema que ocurre repetdas veces en algn contexto determinado del proceso
de desarrollo de sofware y entregan una buena solucin ya probada. Son estereotpos que usamos una y otra vez para
solucionar problemas parecidos. Se pueden utlizar millones de veces y adems perfeccionarlos.

Un buen patrn:

1. Plantea una solucin al problema
2. Provee conceptos
3. Permite derivar soluciones desde primeros principios
4. Describe relaciones
5. Debe tener en cuenta al componente humano

Tambin debe especifcar:

1. Cundo aplicarlos
2. Si debe o no ser aplicado.
3. Consecuencias de la aplicacin
4. Que debe tenerse en cuenta cuando se lo est aplicando
5. Debe formularse estableciendo una relacin entre un contexto, un sistema y una confguracin que permita
resolver el problema.

Componentes:

1. Nombre
2. Propsito
3. Sinnimo
4. Colaboraciones
5. Contexto
6. Explicacin
7. Fuerzas
8. Motvacin
9. Ejemplos
10. Patrones Relacionados
11. Aplicabilidad
12. Estructura
13. Partcipantes
14. Consecuencia

Patrones de CU

Organizacin del lenguaje de los patrones de CU

Consiste en 31 patrones Conforman dos categoras:

Patrones de Desarrollo: describen caracterstcas de prctca de escritura de CU probadas, y ofrecen criterios para medir
la calidad del proceso de escritura de CU.
Patrones Estructurales: describen los componentes bsicos de los CU, explicando cmo deberan ser organizados y
ofrecen criterios para juzgar un CU.

Patrones estructurales

Conjunto de CU: describen el comportamiento de un sistema y consisten en un conjunto de CU, cada uno de los
cuales describe un servicio tl que un actor individual necesita.
Casos de Uso: cada CU es una coleccin de escenarios que puestos juntos describen todas las formas que un actor
tene que alcanzar o fracasar en alcanzar el objetvo.
Escenarios y Pasos: los escenarios consisten de pasos cada uno describiendo una accin que el actor o el sistema
debe hacer para acercar al actor a su objetvo.
Relaciones de CU: los CU a menudo interactan con otros CU. Los patrones de relacin describen tcnicas para
manejar comportamiento repettvo o excesivamente complejo.

Patrones de desarrollo

Las culturas individuales y organizacionales hacen difcil defnir un proceso universal para escribir CU.
Estos patrones identfcan algunas buenas caracterstcas para el desarrollo efectvo de CU. Estos
patrones se dividen en tres subcategoras:

De equipo: composicin de los equipos que escriben CU.
De proceso: tcnicas para crear un conjunto de CU.
De edicin: tcnicas para mejorar CU existentes.

Ver ejemplos en cuadernillo!

Patrones de dominio

Los patrones de dominio son soluciones expresadas en trminos de objetos e interfaces. Se expresan en base a la estructura
y/o comunicacin de objetos y clases para resolver los problemas de contexto.
Un patrn de modelo de objetos es una agrupacin de objetos con responsabilidades estereotpadas y escenarios de
interaccin.

15. Patrn Fundamental: Es la plantlla que todos los patrones siguen

1. #1 Patrn: Coleccin-Trabajador

16. Patrones Transaccionales: Los patrones transaccionales son aquellos patrones que tenen un jugador de transaccin o
tenen jugadores que comnmente juegan con un jugador de transaccin.

1. #2 Actor - Partcipante
1. Organizacin Agente
2. #3 Partcipante - Transaccin
1. Agente Contrato
3. #4 Lugar - Transaccin
1. Aeropuerto Venta
4. #5 tem especifco - Transaccin
1. Vehculo Especifco Venta

5. #6 Transaccin - Detalle de Transaccin
1. Pago Detalle de Pago

6. #7 Transaccin - Transaccin subsiguiente
1. Compra Pago

7. #8 Detalle de Transaccin Detalle de Transaccin Subsiguiente
1. Detalle de orden Detalle de Envi

8. #9 tem - Detalle de Transaccin
1. tem Detalle de Pago

9. #10 tem especifco - Detalle de Transaccin
1. Video Detalle de Alquiler

10. #11 tem - tem especifco
1. Aeroplano Aeroplano Especifco

11. #12 Asociacin Otra Asociacin
1. Conductor Vehculo

12. #13 tem especifco Jerarqua de tem
Cuenta Jerarqua de descripcin de cuentas

UNIDAD N 10
EL FLUJO DE TRABAJO DE ANLISIS


El fujo de trabajo de anlisis: concepto, importancia.

El objetvo de este fujo de trabajo es analizar los requerimientos que se describieron en la captura de requerimientos,
refnndolos y estructurndolos. El objetvo de hacerlo es conseguir una comprensin ms precisa de los requerimientos y
una descripcin de los mismos que sea fcil de mantener y que nos ayude a estructurar el sistema entero. Para comunicar
de manera efciente las funciones del sistema al cliente:

Los CU deben mantenerse tan independientes unos de otros como sea posible.
Los CU deben describirse utlizando el lenguaje del cliente.
Debe estructurarse cada CU para que forme una especifcacin de funcionalidad completa.

En el anlisis podemos razonar ms sobre los aspectos internos del sistema.
La estructura de los requisitos que proporciona el anlisis tambin sirve como entrada fundamental para dar forma al
sistema en su totalidad.

Artefactos, trabajadores y actvidades del fujo de trabajo de anlisis.

ARTEFACTOS

Clase del anlisis

Una clase de anlisis representa una abstraccin de una o varias clases y/o subsistemas del diseo del sistema. Esta
abstraccin posee las siguientes caracterstcas:

Una clase de anlisis se centra en el tratamiento de los RF, dejand de lado los no funcionales para las actvidades
de diseo.
Una clase de anlisis raramente defne su comportamiento mediante responsabilidades en un nivel ms alto y
menos formal (una responsabilidad es una descripcin textual de un conjunto cohesivo del comportamiento de
una clase).
Una clase de anlisis defne atributos. Los atributos identfcados durante el anlisis con frecuencia pasan a ser
clases en el diseo y la implementacin.
Una clase de anlisis partcipa en relaciones.
Las clases de anlisis siempre encajan en uno de tres estereotpos bsicos:

De interfaz: se utlizan para modelar la interaccin entre el sistema y sus actores. Esta interaccin a menudo implica
recibir (y presentar) informacin y petciones de (y hacia) los usuarios y los sistemas externos. Las clases de interfaz
modelan las partes del sistema que dependen de sus actores. Representan a menudo abstracciones de ventanas,
formularios, paneles, etc. Cada clase de interfaz debera asociarse con al menos un actor (y viceversa).

Ventana Ingreso

de pedido


De entdad: se utlizan para modelar informacin que posee una vida larga y que es a menudo persistente. Modelan la
informacin y el comportamiento asociado de algn fenmeno o concepto, como una persona, un objeto del mundo real,
o un suceso. En muchos casos, las clases de entdad se derivan de una clase de EN, o de una clase del dominio; tomada del
modelo de objetos de negocio, o del modelo del dominio. La diferencia entre una clase de entdad y una clase de EN es
que la primera representan objetos manejados por el sistema, mientras que la segunda representan objetos presentes en
el negocio y en el dominio del problema.

De control: representan el comportamiento dinmico del sistema (coordinacin, secuencia,
transacciones y control de otros objetos). Coordinan acciones y delegan trabajo a otros objetos.


Pedido
Gestor de
pedidos

Realizacin de caso de uso-anlisis

Una realizacin de caso de uso anlisis es una colaboracin dentro del modelo de anlisis que describe cmo se lleva a
cabo y se ejecuta un CU en trminos de las clases del anlisis y de sus objetos del anlisis en interaccin. Una realizacin
de CU proporciona por tanto una traza directa hacia un CU concreto del modelo de CU.

Diagramas de clases
Una clase del anlisis y sus objetos normalmente partcipan en varias realizaciones de CU. Por tanto, es importante
coordinar todos los requisitos sobre una clase y sus objetos que pueden tener diferentes CU. Para esto, se adjuntan
diagramas de clases a las realizaciones de CU.

Diagramas de interaccin
La secuencia de acciones en un CU comienza cuando un actor invoca el CU mediante el envo de algn tpo de mensaje al
sistema. En el anlisis se prefere mostrar esto con diagramas de colaboracin, ya que el objetvo es identfcar requisitos y
responsabilidades sobre los objetos, y no identfcar secuencias de interaccin.
En los diagramas de colaboracin, se muestran las interacciones entre objetos creando enlaces entre ellos y aadiendo
mensajes a estos enlaces.

Dentro de una realizacin de CU, objetos diferentes tenen diferentes ciclos de vida:
Un objeto de interfaz no tene por qu ser partcular de una realizacin de CU. Sin embargo, los objetos de
interfaz a menudo se crean y fnalizan dentro de una sola realizacin de CU.
Un objeto de entdad normalmente no es partcular de una realizacin de CU.
Las clases de control suelen encapsular el control asociado con un CU concreto, lo cual implica que debera
crearse un objeto de control cuando el CU comienza y destruirse cuando el CU termina. Sin embargo, hay
excepciones, como cuando un objeto de control partcipa en ms de una realizacin de CU, cuando varios objetos
de control partcipan en una misma realizacin de CU, y cuando una realizacin de CU no requiere ningn objeto
de control.

Paquete del anlisis

Los paquetes del anlisis proporcionan un medio para organizar los artefactos del modelo de anlisis en piezas manejables.
Puede constar de clases de anlisis, de realizaciones de CU, y de otros paquetes del anlisis.
Los paquetes del anlisis tenen las siguientes caracterstcas:
Pueden representar una separacin de intereses de anlisis.
Deberan crearse basndonos en los RF y en el dominio del problema.
Probablemente se convertrn en subsistemas en las dos capas de aplicacin superiores del modelo de diseo.

Paquetes de servicio
En el PUD, el concepto de servicio est soportado por los paquetes de servicio. Los paquetes de servicio se utlizan para
estructurar el sistema de acuerdo a los servicios que proporciona.


Descripcin de la arquitectura (vista del modelo de anlisis)

La descripcin de la arquitectura contene una vista de la arquitectura del modelo de anlisis, que muestra sus artefactos
signifcatvos para la arquitectura.
Los siguientes artefactos del modelo de anlisis normalmente se consideran signifcatvos para la arquitectura:
La descomposicin del modelo de anlisis en paquetes de anlisis y sus dependencias.
Las clases fundamentales del anlisis como las clases de entdad, las clases de interfaz, las clases de control y las clases del
anlisis que son generales.
Realizaciones de CU que describen cierta funcionalidad importante y crtca que se centran en un CU importante, que
probablemente se encuentra en la vista de la arquitectura del modelo de CU.

TRABAJADORES



Arquitecto

El arquitecto es el responsable de la integridad del modelo de anlisis, garantzando que ste sea correcto, consistente y
legible como un todo.
El arquitecto es responsable de lo que es signifcatvo para la arquitectura (descripcin de la arquitectura).
Es tambin responsable de la arquitectura del modelo de anlisis.
El arquitecto no es responsable del desarrollo y mantenimiento de los artefactos del modelo de anlisis.

Ingeniero de casos de uso

Un ingeniero de CU es responsable de la integridad de una o ms realizaciones de CU, garantzando que cumplen los
requerimientos que recaen sobre ellos.
Es tambin responsable del diseo de las realizaciones de los CU (por lo tanto, es responsable tanto del anlisis como del
diseo del CU).
El ingeniero de CU no es responsable de las clases de anlisis ni de las relaciones que se usan en la realizacin del CU.

Ingeniero de componentes

El ingeniero de componentes defne y mantene las responsabilidades, atributos, relaciones y requerimientos especiales
(RNF) de una o varias clases del anlisis.
Tambin mantene la integridad de uno o varios paquetes del anlisis, garantzando que sus contenidos son correctos.


ACTIVIDADES (fujo de trabajo)





Los arquitectos comienzan la creacin del modelo de anlisis identfcando los paquetes de anlisis principales, las clases
de entdad y los requisitos comunes. Despus, los ingenieros de CU realizan cada CU en trminos de las clases del anlisis
partcipantes exponiendo los requisitos de comportamiento de cada clase. Los ingenieros de componentes especifcan
posteriormente estos requisitos y los integran dentro de cada clase creando responsabilidades, atributos y relaciones para
cada clase.
El arquitecto identfca de manera contnua nuevos paquetes del anlisis, clases y requisitos comunes, y los ingenieros de
componentes responsables de los paquetes del anlisis contnuamente los refnan y mantenen. Anlisis de la arquitectura

El propsito del anlisis de la arquitectura es esbozar el modelo de anlisis y la arquitectura mediante la identfcacin de
paquetes del anlisis, clases del anlisis y requisitos especiales.


Identfcacin de paquetes del anlisis
Los paquetes del anlisis proporcionan un medio para organizar el modelo de anlisis en piezas ms pequeas y ms
manejables.
Una identfcacin inicial de los paquetes del anlisis se hace basndonos en los RF y en el dominio del problema. Debido a
que capturamos los RF en la forma de CU, una forma directa de identfcar paquetes del anlisis es asignar la mayor parte
de un cierto nmero de CU a un paquete concreto. Entre las asignaciones adecuadas de CU a un paquete tenemos:

CU requeridos para dar soporte a un determinado proceso de negocio.
CU requeridos para dar soporte a un determinado actor del sistema.
CU que est relacionado mediante relaciones de generalizacin y de extensin.


Identfcacin de clases de entdad obvias
Suele ser adecuado prepara una propuesta preliminar de las clases de entdad ms importante basado en las clases del
dominio o la EN que se identfcaron durante la captura de requerimientos. Sin embargo, la mayora de las clases se
identfcarn al crear las realizaciones de los CU.



Identfcacin de requisitos especiales comunes
Un requisito especial es un requisito que aparece durante el anlisis y que es importante anotar de forma que pueda ser
tratado en las actvidades de diseo e implementacin.

Ejemplos:
Persistencia.
Distribucin y concurrencia.
Caracterstcas de seguridad.
Tolerancia a fallos.
Gestn de transacciones.

Analizar un caso de uso

Analizamos un CU para:

Identfcar las clases del anlisis.
Distribuir el comportamiento del CU entre los objetos del anlisis que interactan.
Capturar requisitos especiales.

Otra forma de llamar al anlisis de CU es refnamiento de CU. Refnamos cada CU como colaboracin de clases del anlisis.

Identfcacin de clases del anlisis
Identfcamos las clases de control, entdad e interfaz necesarias para realizar los CU y esbozamos sus nombres,
responsabilidades, atributos y relaciones.
Los CU descritos en los requisitos no siempre estn sufcientemente detallados, por lo tanto, puede que tengamos que
refnar las descripciones de los CU.

Descripcin de interacciones entre objetos del anlisis
Cuando tenemos un esbozo de las clases necesarias para realizar el CU, debemos describir cmo interactan sus
correspondientes objetos del anlisis. Esto se hace mediante diagramas de colaboracin.

Captura de requisitos especiales
Recogemos todos los requisitos sobre una realizacin de CU que se identfcan en el anlisis, pero deberan tratarse en el
diseo y en la implementacin.
Debemos hacer referencia si es posible a los requisitos especiales comunes que haban sido identfcados por el arquitecto.

Analizar una clase

Los objetvos de analizar una clase son:

Identfcar y mantener las responsabilidades de una clase del anlisis.
Identfcar y mantener los atributos y relaciones de la clase de anlisis.
Capturar requisitos especiales sobre la realizacin de la clase de anlisis.


Identfcar responsabilidades
Las responsabilidades de una clase pueden recopilarse combinando todos los roles que cumple en diferentes realizaciones
de CU. Podemos identfcar todas las realizaciones de Cu en las cuales partcipa la clase mediante el estudio de sus
diagramas de clase y de interaccin.

Identfcacin de atributos
Un atributo especifca una propiedad de una clase de anlisis, y normalmente es necesaria para las responsabilidades de su
clase.

Identfcacin de asociaciones y agregaciones
Los objetos del anlisis interactan unos con otros mediante enlaces. Estos enlaces suelen ser instancias de asociaciones
entre sus correspondientes clases. El ingeniero de componentes debera estudiar los enlaces empleados para determinar
qu asociaciones son necesarias. Los enlaces pueden implicar la necesidad de referencias y agregaciones entre objetos.

Identfcacin de generalizaciones
Las generalizaciones deberan utlizarse durante el anlisis para extraer comportamiento compartdo y comn entre varias
clases del anlisis diferentes.

Captura de requisitos especiales
Recogeremos todos los requisitos de una clase del anlisis que se han identfcado en el anlisis, pero que deberan tratarse
en el diseo y en la implementacin.
Debemos hacer referencia si es posible a cualquier requisito especial comn identfcado por el arquitecto.

Analizar un paquete

Los objetvos de analizar un paquete son:

Garantzar que el paquete del anlisis es tan independiente de otros paquetes como sea posible.
Garantzar que el paquete del anlisis cumple su objetvo de realizar algunas clases del dominio o CU.
Describir las dependencias.
Modelo de anlisis

El lenguaje que utlizamos en el anlisis se basa en un modelo de objetos conceptual, que llamamos modelo de anlisis. El
modelo de anlisis nos ayuda a refnar los requisitos y nos permite razonar sobre los aspectos internos del sistema. El
modelo de anlisis tambin nos ayuda a estructurar los requisitos y nos proporciona una estructura centrada en el
mantenimiento.
El modelo de anlisis puede considerarse una primera aproximacin al modelo de diseo, aunque es un modelo por s
mismo.
Sin embargo, es importante hacer notar que el modelo de anlisis hace abstracciones y evita resolver problemas y tratar
algunos requisitos que es mejor posponer al diseo y a la implementacin.

Por qu el anlisis no es diseo ni implementacin

El diseo y la implementacin son mucho ms que el anlisis (refnamiento y estructuracin de los requerimientos), por lo
que se requiere una separacin de intereses.
El diseo y la implantacin son mucho ms que simplemente el analizar los requerimientos; el diseo y la implementacin
se preocupan en realidad de dar forma al sistema de manera que d vida a todos los requerimientos (incluidos los RNF)
que incorpora.
Antes de comenzar a disear e implementar deberamos contar con una comprensin precisa y detallada de los
requerimientos, lo cual se logra en el anlisis.

Modelo de anlisis: resumen

Ofrece una especifcacin ms precisa de los requerimientos.
Se describe utlizando el lenguaje de los desarrolladores.
Estructura los requerimientos de un modo que facilita su comprensin, su preparacin, su modifcacin y su
mantenimiento.
Puede considerarse una primera aproximacin al modelo de diseo.
Proporciona una vista interna del sistema.
Est estructurado por clases y paquetes.
Es utlizado fundamentalmente por los desarrolladores para comprender cmo debera darse forma al sistema.
No debera contener redundancias, inconsistencias, etc.
Defne realizaciones de CU y cada una de ellas representa el anlisis de un CU.

El anlisis en el ciclo de vida del sofware

Las iteraciones iniciales de la elaboracin se centran en el anlisis. Eso contribuye a obtener una arquitectura estable y
slida y facilita una comprensin en profundidad de los requerimientos. Al trmino de la fase de elaboracin y durante la
construccin, el nfasis pasa al diseo y a la implementacin.
La manera de ver y emplear el anlisis puede diferir de un proyecto a otro:

El proyecto utliza el modelo de anlisis para describir los resultados del anlisis, y mantene la consistencia de
este modelo a lo largo de todo el ciclo de vida del sofware.
El proyecto utliza el modelo de anlisis para describir los resultados del anlisis, pero considera a este modelo
como una herramienta transitoria e intermedia.
El proyecto no utliza en absoluta el modelo de anlisis para describir los resultados del anlisis (el proyecto
analiza los requerimientos en la captura de requerimientos o en el diseo). *Debe considerarse esta variante en
sistemas muy simples+.
INTERACCIONES

Los objetos interactan entre s pasndose mensajes. Una interaccin es un comportamiento que incluye un conjunto de
mensajes intercambiados por un conjunto de objetos dentro de un contexto para lograr un propsito.
Las interacciones se utlizan para modelar los aspectos dinmicos de las colaboraciones.
Las interacciones incluyen los mensajes enviados entre objetos. Un mensaje implica la invocacin de una operacin o el
envo de una seal.

Enlaces

Un enlace es una conexin semntca entre objetos.
Un enlace especifca un camino a lo largo del cual un objeto puede enviar un mensaje a otro objeto. Mensajes

Un mensaje es la especifcacin de una comunicacin entre objetos que transmite informacin, con la expectatva de que
se desencadenar una actvidad. La recepcin de una instancia de un mensaje puede considerarse una instancia de un
evento.
En UML se pueden modelar varios tpos de acciones:
Llamada.
Retorno.
Envo.
Creacin.
Destruccin.

Secuenciacin

Cuando un objeto enva un mensaje a otro, el objeto receptor puede, a su vez, enviar un mensaje a otro objeto, el cual
puede enviar un mensaje a otro objeto diferente. Este fujo de mensajes forma una secuencia.

Representacin

Cuando se modela una interaccin, normalmente se incluirn tanto objetos como mensajes.
Los objetos y mensajes implicados en una interaccin se pueden visualizar de dos formas:
Destacando la ordenacin temporal de sus mensajes (diagrama de secuencia).
Destacando la organizacin estructural de los objetos que envan y reciben los mensajes (diagrama de
colaboracin).
DIAGRAMAS DE INTERACCIN

Un diagrama de interaccin muestra una interaccin, que consiste en un conjunto de objetos y sus relaciones, incluyendo
los mensajes que se pueden enviar entre ellos.
Un diagrama de secuencia es un diagrama de interaccin que destaca la ordenacin temporal de los mensajes.
Un diagrama de colaboracin es un diagrama de interaccin que destaca la organizacin estructural de los objetos que
envan y reciben mensajes.
Los diagramas de interaccin no son slo importantes para modelar los aspectos dinmicos de un sistema, sino tambin
para construir sistemas ejecutables por medio de ingeniera directa e inversa.

Contenidos

Normalmente, los diagramas de interaccin contenen:
Objetos.
Enlaces.
Mensajes.

Diagramas de secuencia

Un diagrama de secuencia destaca la ordenacin temporal de los mensajes.
Tienen dos caracterstcas que los distnguen de los diagramas de colaboracin: en primer lugar, est la lnea de vida, que
representa la existencia de un objeto a lo largo de un perodo de tempo. En segundo lugar, est el foco de control, que
representa el perodo de tempo durante el cual un objeto ejecuta una accin.

Diagramas de colaboracin

Un diagrama de colaboracin destaca la organizacin de los objetos que partcipan en una interaccin.
Los diagramas de colaboracin tenen dos caracterstcas que los distnguen de los diagramas de secuencia: en primer
lugar, el camino. En segundo lugar, est la secuencia. Para indicar la ordenacin temporal de un mensaje, se precede de un
nmero.
En un diagrama de colaboracin interactan objetos, no clases.
Se hace un diagrama de colaboracin por cada escenario del CU que el diagrama describe.

MQUINAS DE ESTADO

El comportamiento de una sociedad de objetos que colaboran puede ser modelado mediante una interaccin. El
comportamiento de un objeto individual puede ser modelado mediante una mquina de estados.
Una mquina de estados es un comportamiento que especifca las secuencias de estados por las que pasa un objeto
durante su vida, en respuesta a eventos, junto con sus respuestas a esos eventos.




Estados

Un estado es una condicin o situacin en la vida de un objeto durante la cual satsface alguna condicin, realiza alguna
actvidad o espera algn evento. Un objeto permanece en un estado durante una cantdad fnita de tempo.
El estado inicial indica el punto de comienzo por defecto para la mquina de estados; y el estado fnal indica que la
ejecucin de la mquina de estado o del estado que lo contene ha fnalizado.

Transiciones
Una transicin es una relacin entre dos estados que indica que un objeto que est en el primer estado realizar ciertas
acciones y entrar en el segundo estado cuando ocurra un evento especifcado y se satsfagan una condiciones
especifcadas.

Diagramas de estados
Un diagrama de estados muestra una mquina de estados.
Un diagrama de actvidades es un caso especial de diagrama de estados en el cual todos o la mayora de los estados son
estados de actvidad y todas o la mayora de las transiciones se disparan por la terminacin de las actvidades en el estado
de origen.

COLABORACIONES
Una colaboracin denota una sociedad de clases, interfaces y otros elementos que colaboran para proporcionar algn
comportamiento cooperatvo.
Las colaboraciones se utlizan para especifcar la realizacin de CU y operaciones.

Estructura
Las colaboraciones tenen dos aspectos:
Una parte estructural que especifca las clases, interfaces y otros elementos que colaboran para llevar a cabo la
colaboracin a la que se da nombre.
Una parte de comportamiento que especifca la dinmica de cmo interactan esos elementos.

Comportamiento
Mientras que la parte estructural de una colaboracin se representa normalmente mediante un diagrama de clases, la parte
de comportamiento de una colaboracin se representa mediante un diagrama de interaccin.
Si se quiere destacar la ordenacin temporal de los mensajes, se puede utlizar un diagrama de secuencia. Si se quiere
destacar las relaciones estructurales entre los objetos que colaboran, se puede utlizar un diagrama de colaboracin.

Organizacin de colaboraciones
Hay dos tpos de relaciones que tenen que ver con las colaboraciones:
Relacin entre la colaboracin y el elemento al que realiza: una colaboracin puede realizar un clasifcador o una
operacin. Por ejemplo, un CU puede ser realizado por una colaboracin; ese CU, incluido sus actores, y los CU
con los que est relacionado, proporcionan un contexto para la colaboracin.
Relacin entre colaboraciones: unas colaboraciones pueden refnar a otras, y esta relacin se modela como un
refnamiento. La relaciones de refnamiento entre colaboraciones normalmente refejan las relaciones de
refnamiento entre CU que representan.


Patrones para la asignacin de responsabilidades

Se aplican durante la construccin de diagramas de interaccin, al asignar responsabilidades a los objetos y al disear la
colaboracin entre ellos. Ej: patrn experto.