You are on page 1of 79

Resumen Análisis de Sistemas

Unidad Nº 1 “los sistemas de información”

Conceptos de información

1) Diferencia entre datos e información:

a) Datos: Realidades concretas en su estado primario. Representan hechos reales. Poseen escaso valor más allá del de su
sola existencia.
b) Información: Conjunto de datos organizados de tal manera que adquieren valor adicional más allá del que poseen por
sí mismos. La conversión de datos en información es un proceso o serie de tareas lógicamente 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 apreciación y comprensión de un conjunto de información y de la utlidad que puede extraerse de
ella en benefcio de una tarea específca. Es por eso que decimos que la información puede considerarse como datos
provistos de mayor utlidad mediante la aplicación 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) Característcas de la información valiosa:

La información debe poseer ciertas característcas para que a los administradores y responsables de decisiones les resulte
valiosa:

• Exacta: Carece de errores.
• Completa: Contene todos los datos importantes.
• Económica: Los responsables de la toma de decisiones siempre deben evaluar el valor de la información con el
costo de producirla.
• Flexible: Es útl para muchos propósitos.
• Confable: Esto dependerá de algunos factores. En algunos casos, del método de recolección de datos, en otros de
la fuente de información.
• 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 fácil acceso para los usuarios autorizados.
• Segura: Protegida contra el acceso a ella de usuarios no autorizados.

La información útl puede variar ampliamente según el valor de cada uno de estos atributos.

3) El valor de la información:

El valor de la información está directamente relacionado con la utlidad que represente para los responsables de la toma
de decisiones en el cumplimiento de las metas de la organización; puede medirse, por ejemplo, con base en el tempo
requerido para tomar una decisión o en el aumento de las utlidades de la compañía. La información valiosa también
puede ser de utlidad para los administradores en su decisión de invertr o no en sistemas y tecnología de información
adicionales.



Conceptos de sistemas y modelado

1) Sistema: Conjunto de elementos o componentes que interactúan 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) Límite 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 retroalimentación. La forma
en que están organizados o dispuestos los elementos de un sistema se llama confguración.

c) Tipos de sistemas:

-Simple vs. Complejo: El simple posee pocos componentes y la relación entre ellos es sencilla y directa. El complejo posee
muchos elementos estrechamente relacionados e interconectados. -Abierto vs. Cerrado: El abierto interactúa con su
entorno. El cerrado no.
-Estable vs. Dinámico: El estable sufre escasos cambios al paso del tempo, en cambio el dinámico sufre rápidos 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á diseñado para existr durante un período relatvamente largo, en
cambio el temporal está diseñado para existr durante un período relatvamente corto.

d) Clasifcación de organizaciones por tpo de sistema: La mayoría de las compañías pueden ser descritas con base en el
esquema de clasifcación descrito anteriormente.

3) Desempeño y estándares de sistema

El desempeño 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 términos relatvos empleados para comparar sistemas.
Efciencia y efcacia son objetvos de desempeño fjados en relación con un sistema general. El cumplimiento de estos
objetvos supone considerar no sólo la efciencia y efcacia deseadas, sino también 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 relación 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 límites el funcionamiento del sistema.
La evaluación del desempeño de un sistema demanda también el empleo de estándares de desempeño. Un estándar de
desempeño de sistemas es un objetvo específco del sistema. Una vez establecidos los estándares, se mide el desempeño
del sistema y se lo compara con el estándar. Las variaciones respecto al estándar son determinantes del desempeño del
sistema.
El cumplimiento de objetvos defnidos de efciencia y efcacia o de estándares de desempeño de sistemas pueden imponer
disyuntvas en términos de costo, control y complejidad.

4) Variables y parámetros 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 parámetro de sistemas es
un valor o cantdad imposible de controlar.

5) Modelado de un sistema

Un modelo es una abstracción o aproximación que sirve para representar la realidad. Permiten examinar situaciones reales
y obtener una mejor comprensión 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.
Físico: es una representación tangible de la realidad.
Esquemátco: es una representación gráfca de la realidad. Ej: gráfcas, mapas, fguras, diagramas, ilustraciones e imágenes.
Matemátco: es una representación aritmétca de la realidad.

¿Qué es un sistema de información?

1) Sistema de información: Conjunto de elementos o componentes interrelacionados para recolectar(entrada),
manipular(procesamiento) y diseminar(salida) datos e información, que cuenta además con un mecanismo de
retroalimentación para el cumplimiento de un objetvo.

2) Entrada, procesamiento, salida y retroalimentación.

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: Conversión o transformación de datos en salidas útles. Esto puede implicar ejecutar cálculos, 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: Información útl, por lo general en forma de documentos y/o reportes. En algunos casos, la salida de un
sistema bien podría ser la entrada de otro. Puede producirse por diversos medios.
d) Retroalimentación: salida que se utliza para efectuar cambios en actvidades de entrada o procesamiento. La
presencia de errores o problemas, podría 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 retroalimentación puede reaccionar a la
existencia de un problema y alertar al administrador (método reactvo). Un sistema de computación también puede
adoptar un método pro actvo de retroalimentación, llamado pronóstco, para prever la futura ocurrencia de
determinados hechos con el propósito de evitar problemas.

3) Sistemas de información manuales y computarizados.

Un sistema de información puede ser manual o computarizado. Muchos sistemas de información son inicialmente
sistemas manuales que después se convierten en sistemas computarizados. Sin embargo, la simple computarización de un
sistema manual de información no garantza un mejor desempeño. SI el sistema original es defectuoso, bien podría ocurrir
que al ser computarizado no se consiguiera más que magnifcar el impacto de esos errores.

4) Sistemas de información basados en computadoras.

Un sistema de información basado en computadoras (SIBC) está compuesto por hardware, sofware, bases de datos,
telecomunicaciones, personas y procedimientos específcamente confgurados para recolectar, manipular, almacenar y
procesar datos para ser convertdos en información. También se les conoce como infraestructura tecnológica de una
compañía, porque consttuyen los recursos compartdos de SI que sirven de fundamento a los sistemas de información.

a) Hardware: Equipo de computación 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 computación que dirigen las operaciones de una computadora. Son dos los tpos básicos de
sofware: sofware del sistema que controla las operaciones fundamentales de una computadora como arranque e
impresión; y sofware de aplicaciones que hacen posibles la ejecución de tareas específcas como el procesamiento de
texto o tabulación de números.
c) Bases de datos: Conjunto organizado de datos e información. Se cuentan entre los componentes más valiosos e
importantes de los sistemas de información basados en computadoras.
d) Telecomunicaciones, redes e Internet: La telecomunicaciones son la transmisión electrónica de señales de
comunicación que permiten a las organizaciones conectar entre sí sistemas de computación para integrar redes. Las redes
sirven para enlazar las computadoras y equipo de computación de un edifcio, un país o el mundo entero, con la fnalidad
de establecer comunicaciones electrónicas. La Internet es la red de computación más grande del mundo; consiste en miles
de redes interconectadas, todas las cuales intercambian libremente información. Dentro de una organización se utlizan las
Intranet que son redes que emplean la tecnología de Internet mediante las cuales los miembros de la organización pueden
intercambiar información y trabajar en proyectos comunes. La World Wide Web (WWW) es una red de enlaces con
documentos dotados de hipermedia ( texto, gráfcos, video, audio). La información respecto a tales documentos y el
acceso a ellos se hallan bajo el control y administración 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 más importante de la mayoría de los sistemas de información basados en computadoras.
El personal de sistemas de información incluye a todos los individuos que administran, operan, programan y mantenen el
sistema. Los usuarios son todos aquellos que utlizan sistemas de información para obtener resultados.


Ejemplos:
Líder del proyecto.
Usuario.
Administrador: da los recursos para la realización del sistema.
Analista: crea los modelos de la solución a los requerimientos del usuario.
Diseñador: 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, polítcas, métodos y reglas para el uso de SIBC. Describen en qué momento
efectuar un programa, quién puede tener acceso a la información de la base de datos, qué debe hacerse en caso de
desastre, en cuyos casos el SIBC sea inutlizable.


Sistemas de información de las empresas

1) Sistemas de procesamiento de transacciones: Una transacción 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 básicas de la compañía.

2) Comercio electrónico: Comprende todas las transacciones de negocios ejecutadas por medios electrónicos entre
compañías (empresa-empresa), compañías y consumidores (empresa-cliente), compañías y sector público, y consumidores
y sector público.

3) Sistemas de información administratva (MIS): Conjunto organizado de personas, procedimientos, sofware, bases de
datos y dispositvos para suministrar información rutnaria a administradores y tomadores de decisiones. El interés
partcular de un MIS es la efciencia operatva. Suelen producir informes estándar generados con base en datos e
información 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 específcos. El campo de
interés del DSS es la efcacia de la toma de decisiones. Así, mientras un MIS contribuye a que una organización “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 específcos. 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 carecería de utlidad. Sus elementos principales son: modelos útles para el tomador de decisiones o usuario
(base de modelos), un compuesto de datos e información 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 noción se
inteligencia artfcial (IA) que adoptan característcas propias de la inteligencia humana. El campo de la IA incluye varios
subcampos: la robótca ( área de la IA donde máquinas ejecutan tareas complejas, rutnarias o tediosas); los sistemas de
visión ( que dotan de “vista” a robots y otros dispositvos, con lo cual son capaces de almacenar y procesar imágenes
visuales); el procesamiento del lenguaje natural (que implica la facultad de las computadoras para comprender y
responder a órdenes orales o escritas en inglés, español 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:

Investgación y análisis de sistemas: El objetvo de la investgación de sistemas es obtener un conocimiento claro del
problema por resolver o de la oportunidad por aprovechar. El análisis de sistemas consiste en defnir los problemas y
oportunidades que el sistema existente ofrece.
Diseño, implementación y mantenimiento y revisión de sistemas: El diseño de sistemas es la determinación del modo en
que operará el nuevo sistema para satsfacer las necesidades de la empresa defnidas durante el análisis de sistemas. La
implementación de sistemas es la creación o adquisición de los diversos componentes de sistemas (hardware, sofware,
bases de datos, etc.) defnidos en el paso de diseño, su respectvo montaje y puesta en operación del nuevo sistema. El
mantenimiento y revisión de sistemas es la inspección y modifcación del sistema para que siga satsfaciendo las
cambiantes necesidades de la empresa.

CAPACITACIÓN EN SISTEMAS COMPUTACIONALES Y DE INFORMACIÓN

Para poder emplear sistemas de información es preciso capacitarse en sistemas.

-La capacitación computacional es el conocimiento de los sistemas y equipo de computación y su funcionamiento. -La
capacitación en sistemas de información es el conocimiento del uso que individuos, grupos y organizaciones hacen de
datos e información.
Saber cómo poner en funcionamiento TPS’s, MIS’s, DSS’s y sistemas expertos para cumplir las metas de una organización es
uno de los aspectos esenciales de la capacitación en sistemas de información.



Sistemas de procesamiento de transacciones

Toda organización tene sistemas de procesamiento de transacciones (TPS) manuales y automátcos que procesan los
datos detallados necesarios para actualizar registros referentes a las operaciones de negocios esenciales de la
organización. Las entradas a estos sistemas incluyen transacciones, que son operaciones de negocios básicas tales como
pedidos de clientes, solicitudes de compras, recepciones, tarjetas de registro de tempos, facturas, etc.
Los TPS son la base de los demás sistemas. En la mayor parte de las organizaciones dan soporte a las actvidades rutnarias,
todos los días, que ocurren en el curso normal de los negocios y que ayudan a una compañía a añadir valor a sus
productos y servicios.

1)Métodos 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 característca 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
transacción relacionada para actualizar los registros de la organización.
-Procesamiento de transacciones en línea(OLTP): En la actualidad, cada transacción se procesa de inmediato. Sin la demora
de acumular las transacciones en un lote. Tan pronto como se cuenta con la información de entrada, un programa de
computación realiza el procesamiento necesario y actualiza los registros implicados en esa transacción individual. Los
datos en un sistema de línea en cualquier momentos presentan la situación actual.
-Entrada en línea con procesamiento retardado: es un intermedio entre los procesamientos por lotes y en línea. Los
pedidos o las transacciones se introducen al sistema de computación al momento que ocurren, pero no se procesan de
inmediato.
Aunque exista la tecnología para ejecutar las aplicaciones de un TPS mediante el procesamiento en línea, 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 compañías esperan que sus TPS logren varios objetvos específcos:

-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 información.
-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
través de un ciclo de procesamiento de transacciones que consta de recopilación, edición, corrección, manipulación y
almacenamiento de datos, y elaboración de documentos.

Recopilación 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.
Edición de datos: Proceso de verifcar los datos para comprobar su validez e integridad.
Corrección de datos: implica volver a introducir, mediante el teclado o el escáner los datos mal capturados que se
localizaron durante la edición de datos.
Manipulación de datos: Proceso de realizar cálculos y otras transformaciones de los datos que tenen relación con
transacciones de negocios. La manipulación incluye clasifcar los datos, reunirlos por categorías, realizar cálculos, etc.
Almacenamiento de datos: Incluye actualizar una o más bases de datos con nuevas transacciones.
Elaboración 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 administración:

-Planeación de la reanudación de los negocios de la empresa: Proceso de prever y prepararse para desastres. Se centra
principalmente en dos consideraciones: preservar la integridad de la información corporatva y mantener operando el
sistema de información 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.

-Recuperación de desastres: Puesta en práctca del plan de reanudación de los negocios de la empresa.
Las principales herramientas utlizadas para la planeación y la recuperación de desastres implican la creación 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
básicas: ¿Satsface el sistema las necesidades de la empresa por las que se puso en práctca? ¿Que procedimientos y
controles se han establecido? ¿Se están utlizando de forma apropiada estos procedimientos y controles?. Existen dos
tpos de auditorías: la interna la realizan los empleados de la organización ; la externa la llevan a cabo organizaciones o
compañías de contadores y personas no relacionadas con la organización. El auditor inspecciona todos los programas,
documentación, técnicas de control, el plan de desastres, y muchas otras cosas más.

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 básicos necesarios para procesar el pedido de un cliente. Una vez que
se introduce y acepta el pedido, se convierte en un pedido abierto.
-Confguración de las ventas: Sistema que asegura que los productos y servicios ordenados sean sufcientes para lograr los
objetvos del cliente, además de asegurar que operarán juntos en forma satsfactoria.
-Planeación de embarques: Sistema que determina cuales pedidos abiertos se surtrán y desde que lugar se embarcaran.
-Ejecución de embarques: Sistema que coordina el fujo de salida de todos los productos y bienes de la organización 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.
-Facturación: Las facturas de los clientes se basan en registros recibidos del sistema de procesamiento de transacciones de
ejecución de embarques. Son la salida del sistema de facturación y refejan el valor de la factura actual así como que
productos compró el cliente.
-Interacción con el cliente: Sistema que supervisa y lleva el control de cada interacción de un cliente con la compañía. -
Determinación de rutas y planifcación de horarios: El sistema de determinación de rutas determina la mejor forma de
llevar los bienes y productos de una localidad a otra. El sistema de planifcación 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 rápida y efciente.
-Recepción: Sistema que crea un registro de las recepciones esperadas y las reales. Se hace cargo de todos los artculos que
llegan, su inspección y envío al personal o a los departamentos que lo solicitaron.
-Cuentas por pagar: Sistema que incrementa el control de la organización sobre las compras, mejora el fujo de efectvo,
aumenta la rentabilidad y proporciona la administración más 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 organización 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 compañía mediante el mantenimiento del control del
dinero adeudado a la empresa por cargos de bienes vendidos y servicios prestados.
-Nóminas: Las dos salidas principales del sistema de nóminas son el cheque de nóminas y el talón, que se distribuyen a los
empleados; y el registro de nóminas, que es un informe breve de todas las transacciones de nóminas.
-Administración de actvos: Sistema que controla las inversiones en equipos de capital y administra la depreciación para
obtener los máximos benefcios fscales.
-Libro mayor general: Sistema que produce una relación detallada de transacciones de negocios, diseñado para automatzar
la elaboración de informes fnancieros y la captura de datos.

Planeación de recursos de la empresa (ERP)

Un sofware ERP es una aplicación de gestón empresarial que da soporte a las distntas áreas funcionales de la empresa.
Típicamente manejan la producción, logístca, distribución, inventario, envíos, facturas y contabilidad de la compañía. Sin
embargo, puede intervenir en el control de muchas actvidades de negocios como ventas, entregas, pagos, producción,
administración de inventarios, calidad de administración y la administración de recursos humanos.
El elemento fundamental para la ERP es la supervisión en tempo real de las funciones de la empresa. Esto permite el
análisis en tempo real de de temas básicos como son la calidad, disponibilidad, satsfacción del cliente, desempeño y
rentabilidad.
Los sistemas ERP se adaptan a las formas diferentes en que cada compañía maneja sus negocios al proporcionar muchas
más funciones de las que podría llegar a necesitar una empresa o incluyendo herramientas de adaptación que les
permitan a las empresas perfeccionar lo que para éstas ya es un buen ajuste.

Ventajas:

-Eliminación de sistemas inefcientes. -Proporcionar
mejores procesos de trabajo -Mejoramiento del
acceso a los datos.
-Mejorar la infraestructura de la tecnología.

Desventajas:

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

UNIDAD Nº 2
“EL PARADIGMA DE LA ORIENTACIÓN 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 precisión
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 código mediante algún mecanismo
ingenioso y así también se reutliza códigos ya existentes.

La fexibilidad que se puede alcanzar a través del sofware: Cada desarrollador tende a construir por sí mismo práctcamente
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 diseñar los
sistemas con una separación de intereses, de forma que el comportamiento de una parte del sistema tenga mínimo
impacto en el comportamiento de otra parte del mismo.

La principal consecuencia de la complejidad es que cuánto más complejo sea el sofware más abierto está al
derrumbamiento total.

El papel de la descomposición

Cuando se diseña un sistema de sofware complejo, es esencial descomponerlo en partes más y más pequeñas, cada una de
las cuales se puede refnar entonces de forma independiente.

Descomposición algorítmica: Es la forma de descomposición sustentada por el análisis y diseño estructurado. En este caso
se divide el sistema en elementos funcionales relacionados estructuralmente entre sí (pasos). Esta visión enfatza el orden
de los eventos.

Descomposición orientada a objetos: En este caso la descomposición consiste en determinar un conjunto de agentes
autónomos (objetos) que se derivan directamente de dominio del problema, que colaboran para llevar a cabo algún
comportamiento de nivel superior. Esta visión resalta los agentes que causan acciones o son sujetos de estas acciones.

La Crisis del Sofware

- La Planifcación y estmación 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 técnicas de desarrollo de
sofware.
-Todos nos resistmos al cambio.

Debido a esta crisis se necesitaba una mejora en:

- Complejidad
- Capacidad de diseño
- Flexibilidad
- Rapidez de desarrollo
- Relación
- Facilidad de modifcación
- Confabilidad

Así se da una revolución en la industria del sofware, logrando lo siguiente:

Tendencia actual en el Sofware:
- Los computadores son más potentes cada año.
- Los usuarios por lo tanto, esperan más de ellos.
- Queremos sofware que esté más adaptado a nuestras necesidades.

Construcción de Sistemas
- Más Complejos
- Más Grandes
- En menos tempo
- A menor costo
- Más Confables

¿Cómo logramos manejar la complejidad del Sofware, reducir los costos de su construcción, 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 teorías, estándares y métodos que juntos representan una forma de organizar el conocimiento, es decir, una
forma de ver el mundo.



Paradigma de programación

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

-Orientado a procedimientos: Algoritmos.
-Orientado a objetos: Clases y objetos.
-Orientados a lógica: Objetvos, a menudo expresados como cálculo de predicados.
-Orientados a reglas: Reglas si-entonces (if-then).
-Orientados a restricciones: Relaciones invariantes.

No hay un estlo de programación que sea el mejor de todos, sino que cada uno tene sus ventajas y desventajas. Se debe
saber usar cada uno según la situación que se nos presenta.

Programación orientada a objetos (POO)

La POO es un paradigma de programación que usa objetos y sus interacciones para diseñar aplicaciones y programas de
computadora.
Está basado en varias técnicas, incluyendo herencia, modularidad, polimorfsmo y encapsulamiento.
Considera al mundo como un conjunto de entdades u objetos que están relacionados y se comunican entre ellos, para
realizar tareas. Esto permite hacer los programas y módulos más fáciles de escribir, mantener y reutlizar.

Elementos del Modelo de Objetos

El modelo de objetos abarca los principios de abstracción, encapsulación, modularidad, jerarquía, tpos, concurrencia y
persistencia. Lo importante del modelo de objetos es el hecho de conjugar todos estos elementos de forma sinérgica.

• Abstracción: denota las característcas esenciales de un objeto que lo distnguen de todos los demás tpos de objeto
y proporciona fronteras conceptuales defnidas respecto al punto de vista del observador. Se centra en la visión
externa de un objeto.
• Encapsulamiento: Es el proceso de almacenar en un mismo compartmiento (una caja negra) los elementos de una
Abstracción (toda la información relacionada con un objeto) que consttuyen su estructura y su Comportamiento.
Esta información permanece oculta tanto para los usuarios como para otros objetos Y puede ser accedida solo
mediante la ejecución de los métodos adecuados. Separa la abstracción de su implementación.
• Modularidad: es la propiedad que tene un sistema que ha sido descompuesto en un conjunto de módulos
coherentes e independientes.
• Jerarquía: es una clasifcación u ordenación 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 partción en subclases más especializadas.

Hay tres elementos secundarios:

• Tipos (tpifcación): Es la defnición 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 teoría de tpos en el que solo un nombre puede denotar objetos de muchas
clases diferentes que se relacionan por alguna superclase común. 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 abstracción de alguna cosa en el dominio del problema que refeja la capacidad de un sistema de alcanzar información
alrededor de él.
Es una instancia de una clase. Son entdades provistas de atributos y de métodos. Un objeto contene toda la información
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 estátcas) del mismo mas los valores actuales
(normalmente dinámicos) de cada una de esas propiedades.

Comportamiento
El comportamiento es cómo actúa y reacciona un objeto, en términos de sus cambios de estado y paso de mensajes.
El comportamiento de un objeto representa su actvidad visible exteriormente.
Está defnido por los métodos 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 demás objetos dicho con otras palabras, es su
identfcador (concepto análogo 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 través de las relaciones.
Hay dos tpos de relaciones:

• Enlace: es una conexión entre objetos. Un objeto colabora con otros a través de sus enlaces.
• Agregación: la agregación denota una jerarquía todo/parte, con la capacidad de ir desde el todo hasta sus partes.

CLASES

Las clases son los bloques de construcción más importantes de cualquier sistema orientado a objetos.
Una clase es un conjunto de objetos que comparten una estructura común y un comportamiento común. Una clase consta
de métodos y atributos que resumen las característcas comunes de los objetos. Puede implementar una o más interfaces.
No es un objeto individual sino que representa un conjunto de objetos.
Los conceptos de clase y objetos están entretejidos. Sin embargo, existen diferencias importantes entre ambos términos.
Un objeto es una entdad concreta que existe en el tempo y en el espacio; una clase representa sólo una abstracción,
como si dijésemos 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 abstracción 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
también puede incluir la declaración de constantes, variables y excepciones que se necesiten para completar la abstracción.

Implementación: es su vista interna. Engloba los secretos de su comportamiento. Se compone de la implementación de
todas las operaciones defnidas en la interfaz.

Estructura de una clase

UML proporciona la siguiente representación gráfca:


NOMBRE


ATRIBUTOS

MÉTODOS

• 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 ubicación. 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 sólo lectura o estátco, es decir, compartdo por todos los objetos de la clase.
• Métodos: Es un algoritmo asociado a un objeto (o a una clase de objetos), cuya ejecución se desencadena tras la
recepción 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 obligación de una clase, es decir lo que debe hacer. Una clase puede tener
cualquier número de responsabilidades, aunque en la práctca 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 párrafo corto.

Mensajes

Los objetos tenen la posibilidad de actuar; la acción 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 cómo se relacionan unas con otras. Se dice que los diagramas
de clases son diagramas «estátcos» porque muestran las clases, junto con sus métodos y atributos, así como las
relaciones estátcas entre ellas: qué clases «conocen» a qué otras clases o qué clases «son parte» de otras clases, pero no
muestran los métodos mediante los que se invocan entre ellas. Además de mostrar la vista estátca muestra una vista
externa del sistema.
Mediante el diagrama de clases identfcamos el dominio (lo que el sistema tendrá que administrar).

• CLASIFICACION: de Estructura, Estátco, Lógico.
• USO:
Explorar conceptos del dominio.
Analizar Requerimientos.
Mostrar el diseño detallado del SW Orientado a Objetos.
• Muestra: un conjunto de clases, interfaces, colaboraciones y sus relaciones.
• Contene comúnmente:
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, automóvil)
• Lugares (Barrio, Provincia, País, Zona)
• Transacciones o operaciones (Venta, Pago, Pedido)
• Hechos o eventos (Reserva, Vuelo, Accidente, Incidente)
• Roles de personas (Proveedor, Cliente, Empleado)
• Contenedores de otras cosas (Almacén)
• Catálogos (catalogo de productos)
• Otras organizaciones u áreas (Ministerio, Juzgado, dpto. de ventas)


Relaciones entre clases

Existen distntos tpos de relaciones:
• Asociación: Una asociación es una relación estructural que especifca que los objetos de una clase están
conectados con los objetos de otra. Una asociación sólo denota una dependencia semántca entre dos clases pero
no establece la forma exacta en que una clase se relaciona con la otra.
Dada una asociación entre dos clases se puede navegar desde un objeto de
una clase hasta un objeto de la otra.
Gráfcamente, una asociación se representa como una línea contnua que conecta la misma o diferentes clases.


-Navegabilidad: la dirección de la navegación indica qué clase es la que contene la referencia hacia la otra (determina
“quién conoce a quién”).
-Multplicidad: señala cuántos objetos pueden conectarse a través de una instancia de la asociación. Se puede indicar una
multplicidad de exactamente uno (1), cero (0), muchos (*), uno o más (1..*) o un valor exacto (por ejemplo, 3). La
multplicidad se indica en el extremo que corresponde a la navegación.


• Agregación: el elemento destno es parte del elemento de origen. Representa una relación entre un “todo” y sus
“partes”.

• Generalización: es una relación en la que una clase comparte la estructura y/o el comportamiento defnidos en
una (herencia simple) o más clases (herencia múltple). El elemento origen es una especialización 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 problemátca en la que se ven inmersas las empresas hoy, se plantea un nuevo paradigma para su gestón, la
administración por procesos.

Empresas de ayer y de hoy





el

El nuevo paradigma nos lleva a la innovación y transformación operacional, así como al uso de nuevas herramientas y
tecnologías.

Ventajas:

-Mejora de la atención y servicio al cliente.
-Disminución drástca del tempo de cada proceso.
-La transformación del entorno de trabajo, de “reactvo” a “proactvo”.
-Mejora de la gestón y optmización de procesos.

Procesos de negocio

Proceso: Conjunto de actvidades relacionadas lógicamente, que toman uno o más tpos de entradas (inputs) y crean uno o
más resultados (outputs) que producen un valor para la organización, sus inversores y/o sus clientes.”

Característcas de un proceso:

-Complejos
-Dinámicos
-Distribuidos y partcularizados
-En algunos casos, de duración prolongada (pueden durar incluso meses o años)
-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 Líderes
Orientación a las tareas
Orientación al cliente y a los
Procesos
Enfoque funcional. (Finanzas,
Compras……...)

Enfoque sobre procesos
Organización reactva Organización proactva
Decisiones basadas
en la experiencia
Decisiones basadas
en análisis de datos
-Dependen de la inteligencia y el juicio de las personas -Difciles
de visibilizar

Proceso de negocio: Es una secuencia específca de actvidades de trabajo a través del tempo y del espacio, con un inicio,
un fnal y unas entradas para producir una salida específca para un cliente o un mercado en partcular.
Puede afectar a más de una unidad organizacional.
Tiene un impacto horizontal en la organización.
Crea algún tpo de valor para el cliente. Los clientes pueden ser externos o internos

Característcas 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 serán realizadas por personas o por un sistema aplicando reglas de decisión que tendrán 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 añadido al agente. -Necesita
de una organización para desarrollarse.
Tipos de procesos de negocio:

-Estratégicos, son aquellos que orientan la dirección de una organización.
-Centrales, son aquellos que consttuyen el núcleo de actvidad de la organización.
-De soporte, son aquellos que apoyan a los centrales en su desarrollo.

Importancia de los procesos

Sin un proceso defnido, no puedo saber cuán bien o mal se encuentra mi organización, ni identfcar a tempo desvíos 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: simplifcación de la realidad. Es una representación 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 descripción 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 específcas;
-Las salidas específcas;
-Los recursos consumidos;
-La secuencia de las actvidades; y -Los
eventos que dirigen el proceso.




Los procesos de negocio emplean información para adaptar o completar sus actvidades. La información, a diferencia de
los recursos, no se consume en los procesos, sino que se usa como parte del proceso de transformación. El conector
“supply” indica que la información 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 recepción de algún objeto, un momento o fecha cumplidos, una notfcación 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 más salidas de valor para el negocio, para uso interno o para
satsfacer requisitos externos. Una salida puede ser un objeto fsico, una transformación 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 algún objeto que es de valor para la organización.

Objetvos: Un proceso de negocio tene algún objetvo bien defnido. Es la razón por la que la organización 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 cómo 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 guía en la construcción del sofware. -Los
modelos documentan las decisiones que se han adoptado.



UML - Lenguaje de Modelado Unifcado

Es un lenguaje de modelado visual, de propósito general, usado para la visualización, especifcación, construcción y
documentación de sistemas Orientados a Objetos. El Lenguaje Unifcado de Modelado (UML) es un lenguaje de modelado
y no un método o un proceso. Está compuesto por una notación muy específca y por las reglas semántcas relacionadas
para la construcción de sistemas de sofware. En sí mismo no prescribe ni aconseja como usar esta notación.

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 dinámicos 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 ejecución del proceso.

Elementos de una diagrama de actvidad:

• Actvidad: Redes de nodos conectados por extremos. La notación para una actvidad es una combinación de los nodos y
arcos que contene, más el nombre (en infnitvo) y sus restricciones.




Los extremos representan fujos por la actvidad. Existen dos categorías 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 serán ciertas después de que la actvidad haya terminado. Las
acciones dentro de la actvidad pueden tener también 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
ejecución cuando se invoca la actvidad. Uno o más nodos fnales indican los lugares donde termina la actvidad.


• Acción: Es un nodo en el diagrama de actvidad, en el cual se puede colocar el nombre de la acción o una expresión. Es
un nodo de actvidad que no puede descomponerse más. Las acciones son atómicas, 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
acción; o se ejecuta completamente o no se ejecuta. Pueden tener precondiciones o postcondiciones locales.

• Nodos de acción: Se ejecutan cuando se satsfacen todas las precondiciones locales del nodo de acción. Cuando el
nodo ha terminado de ejecutarse se comprueba la postcondición local.

Existen cuatro tpos de nodos de acción:

Sintaxis Nombre Semántca

Alguna acción
Nodo de acción
llamada
de Invoca una actvidad, comportamiento u operación.

NombreSeñal

Enviar señal
Envía una señal: Una señal representa información que se
pasa asíncronamente entre objetos.
Es una acción que crea una señal a partr de sus entradas
y la transmite a su objeto receptor.


AceptarEvento



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


Expresión de tempo
Nodo de acción
aceptar evento
tempo.
de
de
Acepta un evento de tempo: responde a tempo. Genera
eventos de tempo según su expresión de tempo.

Se espera una señal Se envía una señal de confirmación
De pedido de pago de pago





La aceptación de la confrmación de pago sólo 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 Semántca
Nodo inicial Indica donde empieza el fujo cuando se invoca una actvidad.
Una actvidad puede tener más 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 actúan 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 número infnito de tokens de
objeto.
Los nodos de objeto pueden tener un comportamiento de selección. Es un comportamiento anexado al nodo que
selecciona objetos de los extremos de entrada de acuerdo a algún 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 máquinas de estados.

• Pins

Un pin es un nodo de objeto que representa una entrada o salida de una acción.
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 acción o un nodo de actvidad, el fujo de control pasa inmediatamente a la siguiente acción o
nodo de actvidad. Se especifca con fechas que muestran el camino de control de un nodo de actvidad o una acción al
siguiente. Se puede especifcar el inicio y la terminación, ya que tene que empezar y parar en algún sito, a no ser que sea
un fujo infnito donde solo tendría inicio.

• Flujos de objetos

Se pueden especifcar los objetos implicados en un diagrama de actvidades colocándolos 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 acción hasta otra. Un fujo de objetos conlleva un fujo de control de forma implícita.

• Partciones de actvidad

Una partción es un agrupamiento de acciones que poseen ciertas característcas en común. Frecuentemente corresponden
a unidades organizacionales en un modelo de negocios.
Se pueden dividir las actvidades en partciones al utlizar líneas vertcales, horizontales o curvas. Cada partción de
actvidad representa una agrupación de alto nivel de acciones relacionadas. Pueden hacer que los diagramas de actvidad
sean mucho más fáciles 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 líneas curvas para crear partciones irregulares, o se podrían indicar partciones al utlizar
texto.

• Regiones de expansión y nodos de expansión

Frecuentemente, la misma operación debe ejecutarse sobre todos los elementos de un conjunto.
Una región de expansión representa un fragmento de un modelo de actvidades que se ejecutan sobre los elementos de
una lista o un conjunto. Se representa dibujando una línea discontnua alrededor de una región de un diagrama. Las
entradas a la región y las salidas de ella son colecciones de valores.
Las colecciones de entrada y salida se representan como una fla de pequeños recuadros unidos y se las denomina nodos
de expansión. Un nodo de expansión es un nodo de objeto que representa una colección de objetos que fuyen en o fuera
de una región de expansión. Esta región se ejecuta una vez por elemento de entrada. Cuando un valor array llega a la
colección de entrada de una región de expansión desde el resto del modelo de actvidades, aquel se divide en valores
individuales.
Cuando cada ejecución de la región de expansión termina, su valor de salir se introduce en un array en el mismo orden que
el valor de entrada correspondiente.
Podría haber uno o más arrays de entrada y cero o más arrays de salida.

Existen dos restricciones en los nodos de expansión:

• El tpo de colección de salida debe coincidir con el tpo de la colección de entrada.
• El tpo de objeto contenido en las colecciones de entrada salida deben ser iguales.

Toda región de expansión tene un modo que determina el orden en el que procesa los elementos en su colección de
entrada. El modo puede ser:

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

Siempre debe especifcar explícitamente el modo. Por defecto ningún 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
región se interrumpe, todo el fujo dentro de la región se aborta inmediatamente.
Los extremos de interrupción se dibujan como una fecha de zigzag o como una fecha normal con un icono de zigzag
dibujado sobre esta.


• Gestón de excepciones

Si se detecta un error en una parte protegida de código, se crea un objeto de excepción y el fujo de control salta hasta un
manejador de excepción que procesa el objeto de excepción de alguna forma. El objeto de excepción contene
información sobre el error que se puede utlizar por el manejador de excepción. Este manejador puede terminar la
aplicación o tratar de recuperarse. La información en el objeto de excepción se guarda en un registro de error.

Un pin representa el resultado de un objeto de excepción al notarlo con un pequeño triangulo equilátero.

• Multdifusión y multreceptor

Se denomina multdifusión cuando un objeto se envía a múltples receptores.
Se denomina multreceptor cuando los objetos se reciben de múltples emisores.

• Conjunto de parámetros

Son conjuntos de pins que permiten que una acción tenga conjuntos alternatvos de pin de entrada y salida. Los conjuntos
de parámetros de entrada contenen pins de entrada y los conjuntos de parámetros de salida contenen pins de salida. No
puede tener un conjunto mezclado de pins de entrada y de salida.


Aplicación Práctca

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 más relevantes.
Por cada proceso identfcado se defne el objetvo correspondiente.
También puede identfcarse para cada proceso: partcipantes, formularios y/o documentación involucrada, etc.
Nombre de Procesos: Podrán estar expresados en infnitvo o como sustantvo considerándose ambas formas
correctas.


Unidad Nº 4: Proceso de desarrollo de sofware

La construcción del sofware de computadora es un proceso iteratvo de aprendizaje y el resultado es una materialización
del conocimiento recolectado, depurado y organizado conforme el proceso estuvo en ejecución.

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

La ingeniería de sofware es el establecimiento y uso de principios sólidos de la ingeniería para obtener económicamente
un sofware confable y que funcione de modo efciente en maquinas reales. Es la aplicación de un enfoque sistemátco,
disciplinado y cuantfcable al desarrollo, operación, y mantenimiento del sofware. Es importante porque ofrece
estabilidad, control y organización a una actvidad que puede volverse caótca si no se controla. Es una tecnología
estratfcada.

Capas de la ingeniería de sofware

La base que soporta la ingeniería de sofware es un enfoque en la calidad. Cualquier enfoque de la ingeniería, 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 tecnología de la ingeniería de
sofware. El proceso del sofware forma la base para el control de la gestón de los proyectos de sofware y establece el
contexto en el cual se aplican los métodos técnicos, se generan los productos del trabajo, se establecen los fundamentos,
se asegura la calidad, y el cambio se maneja de manera apropiada.
Los métodos de la ingeniería de sofware proporcionan los “como” técnicos para construir el sofware. Abarcan un amplio
espectro de tareas que incluyen la comunicación, el análisis de requisitos, el modelo del diseño, la construcción del
programa, la realización de pruebas y el soporte.
Las herramientas de la ingeniería del sofware proporcionan el soporte automátco para el proceso y los métodos.
Combinación de hardware, sofware y bases de datos.
Cuando las herramientas se integran de forma que la información que genera una la puede usar la otra, se dice que se ha
establecido un sistema para el soporte del desarrollo de sofware, denominado ingeniería 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 número de actvidades del
marco de trabajo aplicables a todos los proyectos de sofware. Además 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 ingeniería del sofware. Cada acción la forman tareas de trabajo individuales que completa alguna parte del trabajo
implicado por la acción.

El siguiente marco genérico del proceso se puede aplicar en la mayoría de los proyectos de sofware (actvidades genéricas
del proceso):

Comunicación: implica una intensa colaboración y comunicación con los clientes; abarca la investgación de requisitos y
otras actvidades relacionadas.
Planeación: establece un plan para el trabajo de la ingeniería del sofware. Describe las tareas técnicas que deben
realizarse, los riesgos probables, los recursos que serán requeridos, los productos del trabajo que han de producirse y un
programa de trabajo.
Modelados: abarca la creación de modelos que permite al desarrollador y al cliente entender mejor los requisitos del
sofware y el diseño que logrará satsfacerlos.
Construcción: combina la generación del código y la realización de pruebas necesarias para descubrir errores en el código.
Despliegue: El sofware se entrega al cliente, quien evalúa el producto recibido y proporciona información basada en su
evaluación.

Los detalles del proceso del sofware serán muy diferentes en cada caso, pero las actvidades permanecerán iguales.
La actvidad de elaboración del modelo se compone de dos acciones de la ingeniería de sofware: análisis y diseño. El
análisis es un conjunto de tareas que conducen a la elaboración del modelo de análisis y el diseño abarca tareas de trabajo
que crean un modelo de diseño.

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

-Seguimiento y control del proyecto de sofware -
Gestón del riesgo.
-Aseguramiento de la calidad del sofware. -
Revisiones técnicas formales.
-Medición.
-Gestón de la confguración del sofware.
-Gestón de la reutlización.
-Preparación y producción del producto de trabajo.

La aplicación de estos modelos prescriptvos intenta mejorar intenta mejorar la calidad del sistema, hacer que los
proyectos sean más manejables, que las fechas de entrega y los costos sean más predecibles, y guiar a los equipos de
ingenieros de sofware mientras realizan el trabajo que requiere construir un sistema.
En años 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 más 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 común: crear sofware de alta calidad que satsfaga las necesidades del
cliente, pero tenen perspectvas diferentes.

Patrones de proceso

Un patrón de proceso se defne como un método consistente para describir una característca importante del proceso de
sofware.

Plantlla para describir un proceso:

-Nombre de patrón: nombre signifcatvo que describa su función dentro del sofware.
-Propósito: Se describe con brevedad el objetvo del patrón. -Tipo: Se
especifca el tpo de patrón:

• Patrones de una tarea: acción de la ingeniería 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 patrón.
-Problema: Se describe el problema que debe resolver el patrón.
-Solución: Se describe la implementación del patrón.
-Contexto resultante: Se describen las condiciones que habrá una vez que el patrón 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 específcos en los cuales el patrón es aplicable.

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

Paradigma

En la ingeniería de sofware un equipo de desarrollo debe seguir una estrategia de que acompañe al proceso, los métodos y
las herramientas. Esa estrategia es lo que se conoce como Modelos de Proceso o Paradigmas.
Estos defnen una serie de pasos que abarcan métodos, herramientas y procedimientos, y que permiten al analista de
sistemas tener una forma clara, confable y generalizada de desarrollar un sistema de información

Evaluación 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 característcas técnicas que conducirán a característcas de calidad a largo plazo. Los
patrones de proceso deben ir acompañados de una práctca solida de la ingeniería de sofware, el proceso mismo debe
evaluarse para asegurarse de que cumpla una serie de criterios básicos.
La organización Internacional de Estandarización ha establecido el estándar ISO 9001:2000 para defnir los requisitos de un
sistema de gestón de calidad que sirva para elaborar productos de más alta calidad y así mejorar la satsfacción 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 ingeniería del sofware. Cada ingeniero de sofware crearía un proceso que llene lo mejor posible sus
necesidades, y al mismo tempo satsfaga las amplias necesidades del equipo y la organización.

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:

Planeación. Selecciona requisitos, desarrolla el tamaño y la estmación de los recursos y se estman los defectos. Diseño de
alto nivel. Se elaboran las especifcaciones externas para que cada componente sea construido y se crea un diseño del
componente.
Revisión de alto nivel. Las mediciones se mantenen para todas las tareas importantes y los resultados de trabajo.
Desarrollo. El diseño al nivel de componente se refna y revisa. Se genera, revisa, compila y prueba el código.
Análisis 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 desempeño.
- Ofrecer una guía de mejoramiento a organizaciones de alta madurez.
- Facilitar la enseñanza universitaria de habilidades de equipo industrial de calidad.

El PSE defne las siguientes actvidades del marco de trabajo: lanzamiento, diseño de alto nivel, implementación,
integración y prueba, y análisis de resultados. Al igual que el PSP estas actvidades permiten al equipo planear, diseñar y
construir un sofware de una manera disciplinada al mismo tempo que midan de modo cuanttatvo el proceso y el
producto.



Tecnología del proceso

Las herramientas de tecnología 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 técnica.
Una vez creado el proceso aceptable es posible utlizar otras herramientas de tecnología del proceso para localizar,
monitorear e incluso controlar todas las tareas de ingeniería del sofware defnidas como una parte del modelo del
proceso.
La herramienta de tecnología del proceso también se puede aprovechar para coordinar el uso de otras herramientas de la
ingeniería de sofware.

Producto y proceso

Si el proceso es débil, 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 satsfacción 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 transición desde la programación hasta la ingeniería 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 traído consigo cierta cantdad de estructuras útles para el trabajo en la ingeniería de
sofware.
Cualquier organización de ingeniería de sofware debe describir un conjunto único de actvidades dentro del marco de
trabajo para el proceso de sofware que adopte. También debe llenar cada actvidad del marco de trabajo con un conjunto
de acciones de ingeniería de sofware, y defnir cada acción en cuanto a un conjunto de tareas que identfque el trabajo
para alcanzar las metas de desarrollo. Después la organización debe adaptar el modelo de proceso resultante y ajustarlo a
la naturaleza específca de cada proyecto, a las personas que lo realizarán, 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 ingeniería 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).
Construcción de prototpos (cuadro).
El modelo en espiral (cuadro).
El modelo de desarrollo concurrente. Se representa en forma
esquemátca como una serie de actvidades del marco de trabajo,
acciones y tareas de la ingeniería 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 visión exacta del estado actual de un
proyecto. Defne una red de actvidades, cada actvidad, acción o
tarea en la red existe de manera simultánea 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 construcción. 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 creación del sofware. Además confgura
aplicaciones a partr de componentes de sofware empaquetados en forma previa.
El modelado y construcción comienza con la identfcación de los componentes candidatos. Estos componentes se pueden
diseñar como módulos 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 evalúan para el dominio de aplicación en cuestón.
- Se consideran los aspectos de integración de componentes.
- Se diseña 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 reutlización del sofware.

El modelo de métodos 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 específco de característcas, funciones y contenido de
información. Estas característcas específcas del sofware se modelan como componentes y después se construyen dentro
del contexto de una arquitectura de sistema. Este desarrollo es un paradigma de la ingeniería relatvamente nuevo que
proporciona un proceso y enfoque metodológico para defnir, especifcar, diseñar y construir aspectos (mecanismos mas
allá de subrutnas y legados para localizar la expresión de un interés 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 satsfacción 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 (Organización Internacional de Normalización) – ISO 9001:2008: ISO (la Organización Internacional de
Normalización) es una federación mundial de organismos nacionales de normalización (organismos miembros de ISO). Esta
Norma Internacional promueve la adopción de un enfoque basado en procesos cuando se desarrolla, implementa y
mejora la efcacia de un sistema de gestón de la calidad, para aumentar la satsfacción del cliente mediante el
cumplimiento de sus requisitos.
La aplicación de un sistema de procesos dentro de la organización, junto con la identfcación e interacciones de estos
procesos, así como su gestón para producir el resultado deseado, puede denominarse como "enfoque basado en
procesos”.
• CMMI (Capability Maturity Model Integraton): El insttuto de Ingeniería 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 organización debe crear un modelo de proceso que se ajuste a las
directrices establecidas por la integración del modelo de capacidad de madurez.
CMMI es un modelo de procesos, o una colección de elementos estructurada que describe característcas 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 función de metas específcas y de las práctcas específcas requeridas para alcanzar
dichas metas.
Las metas específcas establecen las característcas que deben existr para que las actvidades implicadas por un área de
proceso sean efectvas.
Las práctcas específcas 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 ingeniería 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 términos de bloques mas pequeños denominados componentes. En 1987 Jacobson
fundó Objetory AB, empresa que desarrolló y vendió un proceso de ingeniería de sofware, basado en el enfoque Ericsson,
denominado Objetory.
El Ratonal Objetory Process (ROP) fue el resultado de la unifcación de Objetory con el trabajo de Ratonal (Booch).
Desde 1997 en adelante, Ratonal adquirió muchas más empresas que aportaban su experiencia en captura de requisitos,
gestón de confguración, pruebas, etc. Esto llevó a la aparición del Ratonal Unifed Process (RUP).
Mientras que RUP es un producto de proceso Ratonal, UP es un proceso de ingeniería de sofware abierto de los autores de
UML.

UP y UPR

RUP es una versión comercial de UP de IBM, proporciona los estándares, herramientas y otras necesidades no incluidas en
UP.
UP y RUP modelan el quién, cuándo y qué del proceso de desarrollo de sofware, pero lo hacen de forma ligeramente
diferente:
Para modelar el quién, UP introduce el concepto del recurso (trabajador), describe un rol desempeñado por una persona o
equipo dentro del proyecto.
UP modela el qué como actvidades y artefactos. Las actvidades son tareas que realizarán personas o equipos en el
proyecto. Estas personas o equipos adoptan roles específcos cuando realizan ciertas actvidades. UP modela el cuándo
como workfows.


Característcas

-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 interactúa con el sistema. Esta
interacción 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 guían el diseño, implementación y prueba del sistema, es
decir, guían el proceso de desarrollo. Los CU no se desarrollan aisladamente, se desarrollan a la vez que la arquitectura del
sistema. Los CU guían a la arquitectura del sistema y la arquitectura del sistema infuye en la selección de los casos de uso.

-Proceso centrado en la arquitectura: El concepto de arquitectura incluye aspectos estátcos y dinámicos del sistema. La
arquitectura es una vista del diseño completo. Cada producto tene una función (CU) y una forma (arquitectura). Los CU
deben encajar en la arquitectura y ésta permitr su desarrollo. Debe haber interacción entre los casos de uso y la
arquitectura.

-Proceso iteratvo e incremental: una iteración es un mini proyecto que obtene como resultado una versión interna. Un
incremento es la diferencia entre la versión interna, o línea base, de una iteración y la versión interna de la siguiente. Es
práctco dividir el trabajo en iteraciones, que son más fáciles 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 iteración trata de un grupo de
CU que juntos amplían 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 solución, mientras que las siguientes dan como resultado incrementos aditvos que fnalmente
conforman la versión externa, es decir, el producto para el cliente.
Las iteraciones construyen los modelos resultantes incremento por incremento. Cada iteración añade algo más a cada
modelo, a medida que la iteración fuye a lo largo de los requisitos, análisis, diseño, implementación y prueba. Algunos de
estos modelos como el e casos de uso, reciben más atención en las primeras fases, mientras que otros como el de
implementación, la recibe durante la fase de construcción.


Benefcios de un proceso iteratvo controlado:

-La iteración 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 más
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
también herramientas que soporten este nuevo método.

La arquitectura proporciona la estructura sobre la cual guiar las iteraciones, mientras que los CU defnen los objetvos y
dirigen el trabajo de cada iteración. La eliminación de una de las tres ideas reduciría drástcamente 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 versión del producto para los clientes.
Cada ciclo consta de cuatro fases: inicio, elaboración, construcción y transición. Cada fase se divide a su vez en iteraciones.

Cada versión es un producto preparado para su entrega. Consta de un código 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
Elaboración Transición Construcción
Iteración
# n-1
Iteración
# n
Iteración
# 2 ...
Iteración
# 1
- - - - - - - - - - - - - - -
Versiones

-Un modelo de casos de uso: con todos los casos de uso y su relación con los usuarios.
…especifcado por…
-Un modelo de análisis, con dos propósitos: refnar los costos de uso con más detalle y establecer la asignación inicial de
funcionalidad del sistema a un conjunto de objetos que proporcionan el comportamiento.
…realizado por…
-Un modelo de diseño que defne: la estructura estátca del sistema (subsistemas,, clases e interfaces) y los casos de uso
refejados como colaboraciones. …implementado por…
-Un modelo de implementación, 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 representación de la arquitectura.
También 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 descripción del producto fnal a partr de una idea y se presenta el análisis de
negocio para el producto. Principalmente esta fase responde a las preguntas sobre cuáles son las principales funciones del
sistema para sus usuarios más importantes, cómo podría ser la arquitectura del sistema y cuál es el plan del proyecto,
además de cuánto costará desarrollar el sistema. Se realiza un modelo de casos de uso simplifcado, con los más crítcos; la
arquitectura es un esbozo que muestra los principales subsistemas, se identfcan y priorizan los riesgos, se planifca en
detalle la fase de elaboración y se estma el proyecto.

Fase de elaboración: Se especifcan en detalle la mayoría de los casos de uso del producto y se diseña 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 línea base de la
arquitectura (versión interna (o externa) del conjunto de artefactos revisados y aprobados generados por esa iteración).

Fase de construcción: se crea al producto. Combina la generación del código y la realización de pruebas para
descubrir errores en el código. Aquí la línea base de la arquitectura crece hasta convertrse en el sistema completo,
obteniendo así un producto preparado para ser entregado a los usuarios.

Fase de transición: En esta fase el producto se convierte en versión una beta. Un número 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 además las
tareas de formación del cliente, ayuda en línea y asistencia.

Conceptos básicos del PUD

Flujo de Trabajo (Workfow)
Es un conjunto de actvidades. Un fujo de trabajo determina cómo 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 término general para cualquier tpo de información 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 desempeñar en el desarrollo de sofware. Cada trabajador es responsable de un conjunto completo de actvidades.
Actvidades
Son trabajos signifcatvos para una persona que actúa como trabajador.

Flujos de trabajo del PUD

En el PUD existen cinco FT:

• FT de Requerimientos: capturan lo que el sistema debería hacer.
• FT de Análisis: mejora y estructura los requisitos.
• FT de Diseño: realiza los requisitos en la arquitectura del sistema.
• FT de Implementación: crea el sofware.
• FT de Prueba: verifca que la implementación funciona según se desea.





UML: Lenguaje Unifcado de Modelado

Es un lenguaje estándar para escribir planos de sofware. Es un lenguaje de modelado visual, de propósito general, usado
para la visualización, especifcación, construcción y documentación de sistemas Orientados a Objetos. El Lenguaje
Unifcado de Modelado (UML) es un lenguaje de modelado y no un método o un proceso. Está compuesto por una
notación muy específca y por las reglas semántcas relacionadas para la construcción de sistemas de sofware. En sí
mismo no prescribe ni aconseja como usar esta notación.
UML es independiente del proceso, aunque para utlizarlo óptmamente se debería 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 comunicación. Un lenguaje de modelado es un lenguaje cuyo vocabulario y reglas se centran en la
representación conceptual y fsica de un sistema.
El vocabulario y las reglas de UML indican cómo crear y leer modelos bien formados, pero no dicen qué modelos se deben
crear ni cuándo se deberían crear. Ésta es la tarea del proceso de desarrollo de sofware.

Lenguaje ? Método ? Proceso ?

Lenguaje: Notación + Reglas
Proceso: Pasos a seguir
Método: Qué + Cómo + Porqué

Qué NO es UML?

-Un lenguaje de programación visual.
-La especifcación de una herramienta o un repositorio.
-UNA METODOLOGÍA, MÉTODO O PROCESO.

UML es un lenguaje para visualizar: UML es un lenguaje gráfco que aporta modelos explícitos que facilitan la
comunicación. Detrás de cada símbolo en la notación UML hay una semántca bien defnida. Así un
desarrollador puede escribir un modelo en UML, y otro desarrollador o incluso herramienta puede interpretar
ese modelo sin ambigüedad.

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 programación visual, pero
sus modelos pueden conectarse de forma directa a una gran variedad de lenguajes de programación, esto permite
ingeniería directa: generación de código a partr de un modelo UML, en un lenguaje de programación. Lo
contrario también es posible: se puede reconstruir un modelo en UML a partr de una implementación. La
combinación de estas dos vías produce una ingeniería “de ida y vuelta”, entendiendo la posibilidad de trabajar
en una vista gráfca 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
Diseño
Código fuente
Planifcación de proyectos
Pruebas Prototpos
Versiones

UML: Un modelo conceptual

Aprender a aplicar UML requiere aprender tres elementos principales: bloques básicos de construcción de UML, reglas que
dictan cómo pueden combinarse esos bloques y mecanismos comunes que se aplican a lo largo de todo el lenguaje.

1) Bloques básicos 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 estátcas de un modelo, y representan conceptos o cosas materiales.
Colectvamente se denominan clasifcadores. Hay 7 tpos:

− Clase: descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y
semántca. Una clase implementa una o más interfaces.

− Interfaz: colección de operaciones que especifcan un servicio de una clase o componente, y no una
implementación. Describe el comportamiento visible externamente de ese elemento.

− Colaboración: Defne una interacción, 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 interactúa con el sofware. Un
caso de uso es realizado por una colaboración.

− Clase actva: Clase cuyos objetos tenen uno o más procesos o hilos de ejecución.

− Componente: Parte fsica y reemplazable de un sistema.

− Nodo: Elemento fsico que existe en tempo de ejecución 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 también migrar de un nodo a otro.

Elementos de comportamiento: Son las partes dinámicas de los modelos UML. Son los verbos de un modelo.
Representan comportamientos en el tempo y en el espacio.
− Interacción: Comportamiento que comprende un conjunto de mensajes intercambiados entre un conjunto de
objetos, dentro de un contexto partcular, para alcanzar un propósito específco.

− Máquina de estados: Comportamiento que especifca las secuencias de estados por las que pasa un objeto
o una interacción 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 acción.


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

− Paquete: Mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales,
de comportamiento e incluso otros elementos de agrupación pueden incluirse en un paquete.

También hay variaciones como los frameworks, los modelos y los subsistemas.

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

− Nota: Símbolo para mostrar restricciones y comentarios.


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

− Dependencia: Relación semántca entre dos elementos, en la cual un cambio a un elemento puede afectar a la
semántca del otro elemento.

− Asociación: Relación estructural entre clases que especifca que los objetos de un elemento están conectados
con los objetos de otro. La agregación es un tpo especial de asociación, que representa una relación estructural
entre un todo y sus partes.

− Generalización: Relación que conecta elementos generalizados (padre) a elementos especializados (hijo). El
hijo comparte la estructura y el comportamiento del padre.

− Realización: Relación semántca entre clasifcadores, en donde un clasifcador especifca un contrato que otro
clasifcador garantza que cumplirá.


c) Diagramas en UML: Es la representación gráfca de un conjunto de elementos, visualizado la mayoría de
las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Es una proyección 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 estátca del sistema:

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

Los que cubren la vista dinámica del sistema:

Diagramas de interacción:
Diagrama de secuencia
Diagrama de comunicación
Diagrama de estados Diagrama
de actvidades

No sé qué modelan:

Diagrama de paquetes
Diagrama de tempos
Diagrama de visión 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 encapsulación 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 interacción: Muestra una interacción, que consta de un conjunto de objetos o roles, incluyendo
los mensajes que pueden ser enviados entre ellos.
− Diagrama de secuencia: Resalta la ordenación temporal de los mensajes.
− Diagrama de comunicación: Resalta la organización estructural de los objetos o roles que envían y reciben
mensajes.
− Diagrama de estados: Muestra una máquina de estados, que consta de estados, transiciones, eventos y
actvidades.
− Diagrama de actvidades: Muestra la estructura de un proceso u otra computación.
− Diagrama de despliegue: Muestra la confguración de nodos de procesamiento en tempo de ejecución y los
artefactos que residen en ellos. Normalmente un nodo alberga uno o más 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. También muestran las clases y
componentes que implementan.
− Diagrama de paquetes: Muestra la descomposición del propio modelo en unidades organizatvas y sus
dependencias.
− Diagrama de tempos: Muestra los tempos reales entre diferentes objetos o roles.
− Diagrama de visión global de interacciones: Híbrido entre diagrama de actvidades y diagrama de secuencia.



2) Reglas de UML

Especifcan a que debe parecerse un modelo bien formado (aquel que es semántcamente autoconsistente y
está en armonía con todos sus modelos relacionados). UML tene reglas sintáctcas y semántcas para:

Nombres: Cómo llamar a los elementos, relaciones y diagramas.
Alcance: Contexto que da un signifcado específco a un nombre.
Visibilidad: Cómo se pueden ver y utlizar esos nombres por otros.
Integridad: Cómo se relacionan apropiada y consistentemente unos elementos con otros. Ejecución: Qué
signifca ejecutar o simular un modelo dinámico.

Es habitual que el equipo de desarrollo no sólo construya modelos bien formados, sino modelos que también
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 análisis, diseño e
implementación 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 más que un lenguaje gráfco. Detrás de cada elemento de notación gráfca
hay una especifcación que proporciona una explicación textual de la sintaxis y semántca de ese bloque
de construcción.

Adornos: La especifcación 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
gráfcos o textuales en la notación rectangular básica de la clase.

Divisiones comunes:

− División entre clase y objeto: Una clase es una abstracción; un objeto es una manifestación concreta de esa
abstracción.

− División entre interfaz e implementación: Una interfaz declara un contrato; una implementación representa
una realización concreta de ese contrato.

− División entre tpo y rol: El tpo declara la clase de una entdad, como un objeto, un atributo o parámetro;
un rol describe el signifcado de una entdad en un contexto, como una clase, un componente o una
colaboración.


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

Estereotpos: extenden el vocabulario de UML, permitendo crear nuevos tpos de bloques de construcción que
derivan de los existentes pero que son específcos a un problema.
Valores etquetados: extenden las propiedades de un estereotpo de UML, permitendo añadir nueva
información en la especifcación de ese estereotpo.
Restricciones: extenden la semántca de un bloque de construcción de UML permitendo añadir nuevas reglas o
modifcar las existentes.

Arquitectura

Diferentes usuarios (usuarios fnales, analistas, desarrolladores, integradores de sistemas, encargados de las
pruebas, encargados de la documentación técnica 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 más
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 través 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 estátcos de
esta vista se capturan en los diagramas de casos de uso; los aspectos dinámicos en los diagramas de interacción,
diagramas de estados y diagramas de actvidades.
− Vista de diseño: Comprende las clases, interfaces y colaboraciones que forman el vocabulario del problema y
la solución. Soporta requisitos funcionales del sistema, o sea los servicios que el sistema debería proporcionar a
sus usuarios fnales. En UML, los aspectos estátcos se capturan en los diagramas de clases y de objetos; los
aspectos dinámicos en los diagramas de interacción, diagramas de estados y diagramas de actvidades.
− Vista de interacción: Muestra el fujo de control entre sus diversas partes, incluyendo los posibles mecanismos
de concurrencia y sincronización. Abarca el rendimiento, escalabilidad y capacidad de procesamiento del
sistema. En UML, los aspectos estátcos y dinámicos se capturan con los mismos diagramas que en la vista de
diseño.
− Vista de implementación: Comprende artefactos que se utlizan para ensamblar y poner en producción el
sistema fsico. Se ocupa de la gestón de confguraciones de las versiones del sistema a partr de archivos
independientes que pueden ensamblarse para producir un sistema en ejecución. En UML, los aspectos estátcos
se capturan con los diagramas de artefactos; los aspectos dinámicos con los diagramas de interacción,
diagramas de estados y diagramas de actvidades.
− Vista de despliegue: Contene los nodos que forman la topología hardware sobre la que se ejecuta el sistema.
Se ocupa de la distribución, entrega e instalación de las partes que consttuyen el sistema fsico. En UML, los
aspectos estátcos se capturan con diagramas de despliegue; los aspectos dinámicos con diagramas de
interacción, diagramas de estados y diagramas de actvidades.


El nacimiento de UML
Del libro:
Anterior a 1994, el mundo de los métodos orientados a objetos era bastante confuso. En términos de lenguajes
de modelado visual los líderes eran Booch y Rumbaugh. En el lado de las metodologías, Jacobson tenía el caso
más fuerte.
Hubo un primer intento de unifcación en 1994 con el método de fusión de Coleman, pero este no implicó a los
autores originales y llegó tarde al mercado. La fusión se vio superada rápidamente por los acontecimientos
cuando en 1994 Booch y Raumbaugh se unieron para trabajar en UML. Así se convirtó en un estándar de la
industria abierto.
En 1997 se aceptó UML, desde entonces todos los métodos competdores han desaparecido.
En el 2000, UML incorporó la semántca de acción, que describe el comportamiento de un conjunto de acciones
primitvas que se pueden implementar por lenguajes de acción específcos. Se permitó que la especifcación 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
más 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 precisión
y la coherencia de la especifcación UML.



De la profe:
Surgimiento UML

- Los lenguajes de modelado orientados a objetos aparecieron entre la mitad de los años 70 y fnales de los 80, por el uso
de los lenguajes de programación O.O.
- Entre fnes de los 80 y mediados de los 90 surgen muchos nuevos métodos 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 versión 1.0 de UML a OMG (Object Management Group), que se fue perfeccionando hasta la
1.3.
- Actualmente versión 2.0 de UML.

MDA, el futuro de UML
MDA defne una visión de cómo se puede desarrollar sofware basándose en modelos. La esencia de esta visión
es que los modelos dirigen la producción 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 noción del modelo es bastante general y el código se considera un tpo muy
concreto de modelo.
El CIM es un modelo en su nivel más alto de abstracción 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 semántca del negocio del sistema de sofware independientemente de
cualquier plataforma subyacente (como EJB, .NET, otras). PIM está adornado con información específca de la
plataforma para crear el PSM. El código fuente se genera desde el PSM contra la plataforma destno.
En la visión MDA, el código fuente, como el código Java y C#, es el “código máquina” resultante de la compilación
de los modelos UML. Este código se genera según 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 implementación.
Dominios de aplicación: Se ha utlizado para modelar de todo, desde sistemas incorporados en el tempo real a
sistemas de soporte a la toma de decisión.
Lenguajes y plataformas de implementación: 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 ingeniería de sofware.
Sus propios conceptos internos: trata de ser coherente y uniforme en su aplicación de un pequeño 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 estátca: Esto describe qué tpo de objetos son importantes para modelar el sistema y cómo se
relacionan.
− Comportamiento dinámico: Esto describe los ciclos de vida de estos objetos y cómo interactúan 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: Ingeniería de requerimientos

Requerimientos del sofware

Es difcil establecer exactamente lo que el sistema debe hacer. Los requerimientos para un sistema son la descripción de
los servicios proporcionados por el sistema y sus restricciones operatvas. Es una característca que debe incluirse en un
nuevo sistema y puede consistr en una forma de captar o procesar datos, producir información, controlar una actvidad o
dar apoyo a la gerencia”. El proceso de descubrir, analizar documentar, y verifcar estos servicios y restricciones se
denomina ingeniería 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 técnico detallado.
Únicamente deben especifcar el comportamiento externo del sistema y deben evitar las característcas de diseño 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 especifcación del
sistema, y por lo tanto, debe ser una especifcación 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 implementación. Son
declaraciones de los servicios que proveerá el sistema, de la manera en que éste reaccionará a entradas partculares y de
cómo 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
organización al redactar requerimientos.

Requerimientos no funcionales: Describen una restricción sobre el sistema que limita nuestras elecciones en la
construcción de una solución al problema. Son aquellos que no se referen directamente a las funciones específcas del
sistema, sino a las propiedades emergentes de éste (fabilidad, respuesta en el tempo, capacidad de almacenamiento,
etc.). Rara vez se asocian con característcas partculares del sistema.
A menudo son más crítcos 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 también pueden venir de las característcas requeridas del sofware (
requerimientos del producto), de la organización 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 polítcas y procedimientos existentes en la organización del cliente y
en la del desarrollador. Ej:

Estándares de proceso.
Lenguaje de programación.
Requerimientos de implementación.

• 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 práctca esto es difcil.

Requerimientos del dominio: Se derivan del dominio de aplicación del sistema más que de las necesidades específcas de
los usuarios. Refejan las característcas y restricciones de ese dominio. Pueden ser RNF, RF nuevos, restringir los existentes
o establecer cómo se deben ejecutar cálculos partculares. Normalmente incluyen terminología especializada del dominio o
referencias a conceptos del dominio.

Especifcación de la interfaz:

Casi todos los sistemas de sofware deben funcionar con otros sistemas que ya están 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 información. Tienen que ver con el
dominio del problema.
El proceso de determinación 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. Después 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.

Categorías de Requerimientos

• Requerimientos que deben ser absolutamente satsfechos.
• Requerimientos que son deseables pero no indispensables.
• Requerimientos que son posibles, pero que podrían eliminarse.

Característcas de los Requerimientos

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


Documento de requerimientos del sofware ó especifcación de requerimientos del sofware (ERS)

Es la declaración ofcial de qué es lo que requieren los desarrolladores del sistema. Incluye tanto los requerimientos del
usuario para el sistema como una especifcación detallada de los requerimientos del sistema. El documento de
requerimientos tene un conjunto diverso de usuarios que va desde los altos cargos de la organización 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 implementación.
• Ser fácil 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

• Introducción
Propósito del documento: delinear el propósito de la ERS y especifcar a quién se dirige.
Defniciones, acrónimos y abreviaturas: incluir las defniciones de los términos, acrónimos y abreviaturas
requeridas para interpretar la ERS.
Audiencia: indicar a quiénes va dirigido el documento y cuál será su utlidad.
Alcance: identfcar los productos de SW, explicar que hará y que no hará cada uno, escribir la aplicación.
Referencias: proveer una lista completa de todos los documentos referenciados.

• Presentación del Producto

Propósito del Sistema
Restricciones y Supuestos: límites a las opciones para diseñar el sistema. Restricciones económicas, legales, impositvas,
etc.

• Descripción General

Listado de la Funcionalidad del Sistema: resumen de las funciones que ejecutará el SW.
Listado de Actores: característcas generales de los usuarios (descripción de los actores).
Perspectva del Producto: relación con otros productos o proyectos, productos independientes, componentes de un
sistema o de un proyecto, HW y equipamiento periférico, restricciones de diseño.

• Descripción Detallada de Requerimientos

Requerimientos Funcionales: diagrama de CU del SI y descripción de CU.
Requerimientos No Funcionales: plantlla de descripción de RNF.

o Del Producto
o Del Ambiente

• Requerimientos de Interfaz

Interfaces de Usuario Interfaces
de Hardware
Interfaces de Sofware Interfaces de
Comunicación

• Restricciones de Diseño
• Operaciones
• Requerimientos de Licencia
• Componentes Comprados
• Observaciones


Proceso de ingeniería de requerimientos (PIR)

La ingeniería 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.
• Elicitación de requerimientos (Obtención y análisis).
• Especifcación de requerimientos.
• Validación de requerimientos.

Estudio de viabilidad

Evaluación de si el sistema es útl para el negocio. La entrada es una descripción del sistema y de cómo se utlizará en la
organización. El resultado es un informe que recomienda si es conveniente o no seguir con la ingeniería de requerimientos
y el proceso de desarrollo del sistema.

Elicitación de requerimientos

En esta actvidad se trabaja con los clientes y los usuarios fnales del sistema para determinar el dominio de la aplicación,
cuáles servicios debe proveer el sistema, el desempeño requerido por el sistema, las restricciones de hardware, etc. La
elicitación incluye diferentes tpos de personas de la organización. El término stakeholders se utliza para referirse a
cualquier persona que tene infuencia directa o indirecta sobre los requerimientos del sistema. Las actvidades del
proceso son:

• Comprensión del dominio.
• Recolección de requerimientos.
• Clasifcación.
• Resolución de confictos.
• Priorización.
• Verifcación de requerimientos.

Especifcación de requerimientos

La tarea fundamental que se defne para este proceso es la de realizar una análisis de los requerimientos detectados y la
creación de los modelos necesarios que representen la solución del sofware, que tene en cuenta esos requerimientos.
La solución presentada es una solución lógica o teórica, libre de cualquier aspecto referido a como se implementará el
sistema.
Como resultado de desarrollo de este proceso se obtene el documento de Especifcación de Requerimientos de Sofware
(ERS) que expresa los requerimientos funcionales detectados a través de los modelos que dan solución a los mismos.
Algunas de las principales herramientas que nos permiten realizar la especifcación de requerimientos funcionales y realizar
la ERS son:

• Diagrama de Casos de Uso.
• Descripción de Casos de Uso.
• Diagrama de Clases.

Validación de requerimientos

La validación 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:

• Verifcación de validez: Un usuario puede pensar que se necesita un sistema para llevar a cabo ciertas
funciones. Sin embargo, el razonamiento y el análisis pueden identfcar que se requieren funciones adicionales
o diferentes.
• Verifcación de consistencia: los requerimientos no deben contradecirse.
• Verifcación de integridad: los requerimientos deben cubrir todas las funciones y restricciones propuestas por el
usuario.
• Verifcación 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.

Administración 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
comprensión del problema por el desarrollador está cambiando constantemente y estos cambios retroalimentan a los
requerimientos.
La administración de requerimientos es el proceso de comprender y controlar los cambios en los requerimientos del
sistema.

Requerimientos duraderos y volátles

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

• Requerimientos duraderos: son relatvamente estables que se derivan de la actvidad principal de la
organización y están directamente relacionados con el dominio del problema.

• Requerimientos volátles: cambian durante el desarrollo del sistema o después de que éste se haya puesto en
operación.

Unidad Nº 6:
El proceso de elicitación de requerimientos

Elicitación
Está explicado en la unidad 5.
Tareas en la Elicitación

Planeación

– Determinación de cuándo y a quién será dirigida la recolección de datos.
– Conocimiento del dominio
– Diseño de la herramienta

Desarrollo

– Tomar notas
– Grabación
– Filmación
– Uso de Formularios

Organización y análisis de la información obtenida

– Resúmenes
– Informes – Minutas – Cuadros
– Listado de Requerimientos
– Especifcación de Requerimientos


Fuentes de Información



Técnicas de recopilación de información.

Métodos interactvos.

Hay tres métodos interactvos clave para obtener los requerimientos de la
Información: las entrevistas, el diseño conjunto de aplicaciones (Joint Applicaton Design) y la realización de encuestas
mediante cuestonarios.

Entrevistas:

Conversación dirigida con un propósito específco que utliza un formato de preguntas y respuestas.

Pasos para preparar una entrevista.

• Leer los antecedentes.
• Establecer los objetvos de la entrevista.
• Decidir a quién entrevistar.
• Preparar al entrevistado.
• Decidir tpo de preguntas y respuestas.

Tipos de preguntas:

Preguntas Abiertas: Describe las opciones del entrevistado para responder. Están abiertas, la respuesta puede ser de dos
palabras o dos párrafos

Ventajas de utlizar preguntas abiertas:

◦ Hacen que el entrevistado se sienta más a gusto.
◦ Permiten al entrevistador entender el vocabulario del entrevistado, el cual refeja su educación,
valores, acttudes y creencias.
◦ Proporcionan gran cantdad de detalles.
◦ Revelan nuevas líneas de preguntas que pudieron haberse pasado por alto.
◦ Hacen más 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:

◦ Podrían dar como resultado muchos detalles irrelevantes.
◦ Posible pérdida de control de la entrevista.
◦ Permiten respuestas que podrían tomar más tempo del debido para la cantdad útl de información
obtenida.
◦ Dan la impresión de que el entrevistador es inexperto.
◦ Podrán dar la impresión 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 fácilmente ◦
Ir al grano.
◦ Mantener el control durante toda la entrevista. ◦
Cubrir terreno rápidamente
◦ Conseguir datos relevantes.

Desventajas de usar preguntas cerradas:

◦ Aburren al entrevistado.
◦ No permiten obtener gran cantdad de detalles.
◦ Olvidar ideas principales por la razón anterior.
◦ No ayuda a forjar una relación 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 propósito del sondeo
es ir más allá de la respuesta inicial para conseguir mayor signifcado, califcar, obtener y ampliar la opinión del
entrevistado. Los sondeos pueden constar de preguntas abiertas o cerradas.

Colocar preguntas en una secuencia lógica

• Estructura pirámide: 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
pirámide si cree que su entrevistado necesita motvación 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 método de estructura de embudo proporciona una forma cómoda y sencilla de empezar
una entrevista. La secuencia de preguntas de forma embudo también es útl cuando el entrevistado tene opciones fuertes
acerca del tema y necesita libertad para expresar sus emociones.
• Estructura de diamante: Combinación de las 2 anteriores. Empezar de una manera muy específca, después se
examinan los aspectos generales y fnalmente se termina con una conclusión muy específca.

Diseño de conjunto de aplicaciones (JAD)

Experimentará situaciones en las cuales las entrevistas uno a uno, no parecerán tan útles como usted quisiera. IBM
desarrollo un método alternatvo para entrevistar a los usuarios uno a uno, conocido como diseño 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 evaluación de los requerimientos de información y generar una mayor identfcación del usuario
con los nuevos sistemas de información como resultado de los procesos partcipatvos. Tiene un carácter interactvo y
tene mucho en común con las técnicas de “lluvia de ideas”.

Ventajas:

-Reducción del tempo y el costo.
-Mejor calidad de resultados de la evaluación de los requerimientos.
-Ayuda a los usuarios a involucrarse en las etapas de los proyectos de sistemas.
-Desarrollo de diseños creatvos.

Desventajas:

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


Cuestonarios

El uso de cuestonarios es una técnica de recopilación de información que permite a los analistas de sistema estudiar las
acttudes, creencias, comportamientos y característcas de muchas personas importantes en la organización que podrían
resultar afectadas por los sistemas actuales y propuestos. Las acttudes consisten en lo que las personas de la organización
dicen que quieren, las creencias son lo que las personas realmente piensan que es verdad, el comportamiento es lo que
los miembros de la organización hacen y las característcas 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 información a través 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 planeación.

Vamos a usar cuestonarios en los siguientes casos:

• Las personas que necesita encuestar se encuentran en ubicaciones dispersas.
• Una gran cantdad de personas están involucradas en el proyecto de sistemas, y es importante saber que proporción de
un grupo dado aprueba o desaprueba una característca específca del sistema propuesto.
• Está haciendo un estudio preliminar y desea medir la opinión 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.

Redacción de preguntas:

Las entrevistas permiten interacción entre las preguntas y su signifcado y el analista tene la oportunidad de refnar una
pregunta, defnir un término 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 aplicación del cuestonario debe planearse en detalle.
Aquí las preguntas también 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 información de un gran número de personas en poco tempo.
-Las preguntas estandarizadas proporcionan datos más 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 distribución de los cuestonarios es costoso y lleva tempo.
Métodos no intrusivos.

Muestreo:

Es el proceso que consiste en seleccionar sistemátcamente elementos representatvos de una población. Cuando dichos
elementos se examinan con cuidado, se da por hecho que el análisis revelará información útl de la población en general.

Ventajas:

-Es un método económico.
-La recopilación de datos y obtención de resultados es rápida.
-Una muestra ofrece mejor calidad y precisión de los datos. -Reduce
la parcialidad.

Desventajas:

-Es posible seleccionar una muestra inadecuada.

Investgación:

Es la acción de descubrir y analizar los datos. Los datos examinados pueden cuanttatvos o cualitatvos.


Análisis 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 producción.
-Informes de desempeño: refejan el desempeño real vs el deseado.
-Registros: proporcionan actualizaciones periódicas de lo que ocurre en el negocio. -Formularios
de captura de datos

Análisis de documentos cualitatvos:

-Memorados
-Carteles o pancartas
-Sitos web corporatvos
-Manuales
-Manuales de polítcas

Ventajas:

-Permite conocer a la organización en su esencia.

Desventajas:

-Es un proceso bastante esforzado.
-La recopilación de datos es lenta.

Observación:

-Observación 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 información para
realizar su trabajo.

Ventajas:

-Permite conocer el procesamiento de la información rápidamente al ver las operaciones personalmente.
-Observando se pueden obtener datos que no se podrían obtener de otra forma.

Desventajas:

-La recopilación de datos es lenta y minuciosa.

-Observación del entorno fsico: Consiste en examinar sistemátcamente las ofcinas de los tomadores de decisiones. Esto
pone de manifesto muchos de sus requerimientos de información.

Ventajas:

-Permite reconocer los elementos que se usan en el procesamiento de la información. -Observando
se pueden obtener datos que no se podrían obtener de otra forma.



Desventajas:

-La recopilación 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 ESPECIFICACIÓN DE REQUERIMIENTOS”

Especifcación de requerimientos.

La especifcación de requerimientos es el proceso de realizar una descripción detallada y precisa de los requerimientos del
sistema. Debe servir de base para la elaboración de un contrato entre el cliente y el equipo de desarrollo. Permite
describir a través de modelos gráfcos la funcionalidad del sistema.

Técnicas de la especifcación de requerimientos.

Entrevistas y Cuestonarios. (vistos en la unidad 6).
Lluvia de ideas.
Prototpos.
Análisis Jerárquico.
Casos de Uso.

Herramientas de la especifcación de requerimientos.

Algunas de las herramientas que nos permiten realizar la especifcación de requerimientos y realizar la ERS son:

Diagramas de clases (descripción en la unidad 4)
Descripción 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
reseñas 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
llevaría 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 están pensados para representar el diseño y no puede describir
los elementos internos de un sistema. Sirven para facilitar la comunicación con los futuros usuarios del sistema, y con el
cliente, y resultan especialmente útles para determinar las característcas 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 análisis, el diseño y las pruebas. En otras palabras, los diagramas de casos de uso
describen qué es lo que debe hacer el sistema, pero no cómo. Se emplean para modelar la vista de CU de un sistema y así
también 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 dinámico de un procedimiento, transacción 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 representación limitada de un producto, permite a las partes probarlo en
situaciones reales o explorar su uso, creando así un proceso de diseño de iteración que genera calidad.
Un prototpo puede ser cualquier cosa, desde un trozo de papel con sencillos dibujos a un complejo sofware.

El documento de especifcación de requerimientos de sofware

Como resultado del desarrollo del PIR se obtene el Documento de Especifcación 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 más importantes. Establece lo que se espera del sistema. NO es un documento
de diseño. Contene tanto los requerimientos del usuario como los del sistema.

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

--Los encargados de la aprobación fnal de la ERS son los administradores de la organización (quienes pagan).

--La ERS es independiente de la tecnología 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
-Diseñadores
-Cliente
-Testng
-Administradores

--Estructura del documento:

-Introducción: Característcas y objetvos del sistema.
-Glosario: Defnición de términos técnicos utlizados.
-Descripción general.
-Requerimientos.
-Apéndice.
-Índice.

Proceso de gestón de cambios
Cuando los requerimientos cambian o varían se realiza este proceso para validar los nuevos cambios y así poder modifcar la
ERS.

Modelización

Los requerimientos del usuario deben redactarse en lenguaje natural para que sean comprendidos por personas que no son
técnicos expertos. Sin embargo, los requerimientos del sistema más detallados se expresan en una forma más técnica. Una
técnica muy utlizada es la modelización, técnica para documentar la especifcación del sistema como un conjunto de
modelos.
Los modelos son representaciones gráfcas que describen el problema a resolver y el sistema a desarrollar. Son un puente
importante entre los procesos de análisis y diseño. Es una abstracción del sistema que omite los detalles irrelevantes al
dominio del problema, y simplifca el mismo.

Modelos de contexto
Se utliza para defnir los límites del sistema y su relación 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 cómo fuyen los datos a través de una secuencia de pasos de procesamiento.
• Modelos de máquinas 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 información de gran tamaño. A menudo, los
modelos de datos se utlizan en conjunto con los de fuljo de datos para describir la estructura de la información que se está
procesando.

Modelos de objetos

Se utlizan para representar los datos del sistema y su procesamiento.
UNIDAD Nº 8
“EL PROCESO DE VALIDACIÓN DE REQUERIMIENTOS”

La validación 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 ambigüedad, sin inconsistencias, sin omisiones, que
los errores detectados fueron corregidos, y que el resultado del trabajo se ajusta a los estándares establecidos para el
proceso, proyecto y producto.

Tipos de validación:

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

Técnicas de validación de requerimientos:

• Revisiones de requerimientos: Las revisiones de requisitos consisten en reuniones donde un equipo de analistas
intenta localizar errores en el documento de especifcación.
• Generación de casos de prueba: Este método tene como objetvo comprobar la verifcabilidad de los requisitos.
Consiste en la defnición de casos de prueba que permitan verifcar el cumplimiento de los requisitos funcionales.
• Análisis de consistencia automátco.
• Construcción de prototpos.

Construcción de prototpos:

Prototpo: Versión inicial del sofware. Se utiza para demostrar los conceptos, probar las opciones de diseño, enterarse
más acerca del problema y sus posibles soluciones. Ayudan a:

• Obtención de requerimientos: pueden proponer nuevos requerimientos del sistema.
• Validación 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 diseño.
-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 más de ellos. Los requerimientos que son precisos
nunca deben estar en el prototpo.
Tienen un ciclo de vida corto. Se permite un desempeño pobre y una baja fabilidad puesto que su función principal es
ayudar a la comprensión de los requerimientos. El prototpo se escribe, evalúa y modifca.
-Evolutvos: El objetvo de la construcción de prototpos evolutvos es entregar a los usuarios fnales un sistema funcional.
La construcción de prototpos evolutvos inicia con un sistema relatvamente simple que implementa los requerimientos
más importantes del usuario. Dicho prototpo se aumenta o cambia en cuanto se descubren nuevos requerimientos.

INTERFACES DE USUARIO

La construcción de prototpos es una parte esencial del proceso de diseño 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 construcción de prototpos evolutvos con la partcipación del usuario fnal es la única forma sensible para desarrollar
interfaces gráfcas de usuario para los sistemas de sofware.




Diseño de la interfaz de usuario

Para que el sistema tenga éxito, es importante contar con un buen diseño de la interfaz de usuario. Una interfaz difcil de
utlizar provocará que los usuarios cometan muchos errores, o simplemente se rehusarán a utlizar el sistema de sofware
sin tomar en cuenta su funcionalidad. Si la información se presenta de una forma confusa o engañosa, los usuarios no
comprenderán el signifcado de la información. Las ventajas de las GUI’s son:

• Son relatvamente fáciles de aprender y utlizar.
• Para interactuar con el sistema, los usuarios cuentan con pantallas múltples.
• Es posible interactuar rápidamente y tener acceso inmediato a cualquier punto de la pantalla.

Principio de diseño de la interfaz de usuario

• Familiaridad del usuario: la interfaz debe utlizar términos 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 realizarían sin la
automatzación.
• Mínima 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.
• Guía al usuario: cuando los errores ocurren, la interfaz debe proveer retroalimentación signifcatva y
característcas de ayuda sensible al contexto.
• Diversidad de usuarios: la interfaz debe proveer característcas de interacción apropiada para los diferentes tpos
de usuarios del sistema.

Relación GUI-CU

• Por cada caso de uso puedo tener:

- 1 GUI
- + 1 GUI
-Ninguna GUI (Procesos automátcos que no necesitan interacción 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 opción:

A

B








C
-Botón; Una funcionalidad del caso de uso.




-Seleccionar más de una opción:

A
B
C
D

Aspectos a tener en cuenta en el diseño de la GUI

1. Lo más importante va en la esquina superior izquierda. El
sentdo de la secuencia de acciones sería:



2. No dejar espacios en blanco. 3. Lenguaje del usuario
4. Estétca:

-Alineación
-Colores
-Tipo y tamaño de letra
-Imágenes
-Sonido-efectos
5. Distribución
6. Claridad, facilidad de uso, que sea intuitvo.


Tipos de ventanas:

- Ventanas de aplicación
- 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 pestañas.

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 cuáles son los requisitos ni tampoco cómo especifcarlos de una forma precisa.
La aproximación 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 visión de conjunto y de componer una
especifcación de requisitos completa, correcta y consistente.
Incluso con la ayuda de los analistas, los usuarios no comprendían del todo lo que el sistema sofware debería hacer hasta
que el sistema estaba casi terminado.
Durante años nos hemos engañado a nosotros mismos creyendo que los usuarios saben cuáles 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, sistemátco para llevarla a cabo desde
hace mucho tempo.

Objeto del fujo de trabajo de los requisitos.

El propósito fundamental del FTR es guiar el desarrollo hacia el sistema correcto. Esto se consigue mediante una
descripción 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 también ayudan al jefe de proyecto a planifcar las iteraciones y las versiones del cliente.

Visión 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 podrían 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 versión futura del
sistema. Esta lista de característcas crece a medida que se añaden nuevos elementos y mengua cuando algunas
característcas se convierten en requerimientos y se transforman en otros artefactos como CU. La lista de característcas se
utliza sólo para la planifcación del trabajo.
Cada característca tene un nombre corto y una breve explicación o defnición, información sufciente para poder hablar
de ella durante la planifcación del producto. Cada característca tene también un conjunto de valores de planifcación que
podríamos incluir:
-Estado (propuesto, aprobado, incluido o validado).
-Coste estmado de implementación (en términos de tpos de recursos y horas-persona).
- Prioridad (crítco, importante o secundario).
-Nivel de riesgo asociado a la implementación de la característca (crítco, signifcatvo u ordinario).

Estos valores de planifcación se utlizan junto con otros aspectos para estmar el tamaño del proyecto y para decidir cómo
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 técnica para identfcar los
requerimientos del sistema se basa en los CU. Estos CU capturan tanto los requisitos funcionales como los no
funcionales que son específcos 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 implementación, 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 añadirán nuevos CU y/o
añadirán detalle a las descripciones de los CU existentes.
El fujo de trabajo de requisitos se hace fundamentalmente durante el inicio y la elaboración.

• Durante la fase de inicio, los analistas identfcan la mayoría de los CU para delimitar el sistema y el alcance del
proyecto y para detallar los más importantes.
• Durante la fase de elaboración, los analistas capturan la mayoría de los requerimientos restantes para que los
desarrolladores puedan estmar el tamaño del esfuerzo de desarrollo que se requerirá. El objetvo es haber
capturado sobre un 80 por ciento de los requisitos y haber descrito la mayoría de los casos de uso al fnal de esta
fase de elaboración.
• Los requerimientos restantes se capturan (e implementan) durante la fase de construcción.
• Casi no hay captura de requerimientos en la fase e transición, a menos que haya requerimientos que cambien.


COMPRENSIÓN DEL CONTEXTO

Comprensión del contexto del sistema mediante un Modelo del dominio.

Un modelo del dominio captura los tpos más 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 especifcación 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 aviación enemiga, misiles y
trayectorias.
-Suceso que ocurrirán o han ocurrido, como la llegada de un avión, 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 cómo se
relacionan unas con otras mediante asociaciones.

Comprensión del contexto del sistema mediante un Modelo del negocio

El modelo del negocio es una técnica para comprender los procesos de negocio de la organización. 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 términos 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 cómo 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 cómo 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 realización de un caso de uso del negocio puede mostrarse en diagramas de interacción 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 realización de más 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 sólo 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 términos indistntamente. Sin
embargo, existen algunas diferencias importantes entre el modelado del negocio y el modelado del dominio que hacen
mucho más recomendable el realizar el más 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 utlización 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
mayoría de los RNF son específcos 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 más 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
realización 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 más actores. Un actor es el rol que juega un usuario en relación 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 interactúa con el
sistema, la instancia correspondiente del actor está desarrollando ese papel. Una instancia de un actor es un usuario
concreto que interactúa 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
información. Es aquel actor para el cual el CU ha sido desarrollado.
Actor Secundario: Es de quién 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 especifcación del comportamiento de “cosas” dinámicas (instancias de CU). Una instancia de caso de uso es
la realización (o ejecución) de un caso de uso.
Según el vocabulario de UML, un caso de uso es un clasifcador, lo cual quiere decir que tene operaciones y atributos. Una
descripción 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 términos de estados y
transiciones entre los estados.
Los diagramas de actvidad describen el ciclo de vida con más detalle describiendo también la secuencia temporal de
acciones que tene lugar dentro de cada transición. Los diagramas de colaboración 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
mayoría de las veces es una instancia de un actor la que invoca a la instancia del caso de uso, pero también 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 ejecución 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 interactúan 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 atómicas 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 más sencillo el modelado de casos de uso.

Descripción de la arquitectura (vista del modelo de CU)

La descripción de la arquitectura contene una vista de la arquitectura del modelo de CU, donde se describen los CU más
importantes.
La vista de la arquitectura del modelo de CU debería incluir los CU que describan alguna funcionalidad importante y crítca,
o que impliquen algún 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 (análisis, diseño, implementación)
dentro de cada iteración.

Glosario

Podemos utlizar un glosario para defnir términos 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 sólo nos ayuda a desarrollar una interfaz gráfca mejor sino también a
comprender mejor los CU.
En la actvidad de especifcación de requerimientos la función principal de los prototpos de interfaz es derivar y validar los
requerimientos esenciales de información de los usuarios, manteniendo abiertas, al mismo tempo, las opciones de
implementación.


TRABAJADORES


Un trabajador es un puesto al cual se puede asignar una persona “real”. Con cada trabajador tenemos una descripción 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 abstracción 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.
• Diseñador de interfaz gráfca.


Analista de sistemas

El analista de sistemas es el responsable del conjunto de requerimientos que están 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 también
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 práctca, este trabajador está respaldado por un equipo
que incluye otras personas que también trabajan como analistas.

Especifcador de CU

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

Diseñador de interfaz de usuario

Los diseñadores 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 sitúa 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 están
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 lógico. En el mundo real, no es necesario trabajar mediante actvidades
en secuencia. De hecho, podemos trabajar por múltples vñias que producen un resultado fnal equivalente. Una actvidad
puede ser retomada muchas veces, y cada una de éstas puede acarrear la ejecución de una sola fracción de la actvidad.
Primero, el analista de sistemas ejecuta la actvidad de “Encontrar Actores y CU” para preparar una primera versión del
modelo de CU, con los actores y CU identfcados.
Entonces, el arquitecto identfca los CU relevantes para proporcionar entradas a la priorización de CU que van a ser
desarrollados en la iteración actual.
Hecho esto, los especifcadotes de CU describen todos los CU que se han priorizado. Más o menos en paralelo, los
diseñadores de interfaz de usuario sugieren las interfaces de usuario adecuadas para cada actor basándose en los CU.
Entonces, el analista de de sistemas reestructura el modelo de CU defniendo generalizaciones entre los CU para hacerlo lo
más comprensible posible.
Los resultados de la primera iteración a través de este FT consisten en una primera versión del modelo de CU, los CU y
cualquier prototpo de interfaz de usuario asociado. Los resultados de cualquier iteración subsiguiente consistrán
entonces en nuevas versiones de estos artefactos.


Encontrar actores y CU

Consiste en encontrar los actores y los CU asociados a cada actor.
La identfcación de actores y CU es la actvidad más 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 ningún orden en partcular, y a menudo se
hacen simultáneamente.

• 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 categorías
representadas por actores.
En ambos casos, se deben identfcar los actores que representan sistemas externos y los actores para el mantenimiento y
operación del sistema.
El resultado es una nueva versión 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 llegarán a ser CU por sí mismos (podrán ser partes de otros CU). Se elige un nombre para CU (de
forma que nos haga pensar en la secuencia de acciones que añade un valor al actor) que suele comenzar con un
verbo y debe refejar el objetvo de la interacción entre el actor y el sistema.

• Describir brevemente cada CU: el analista de sistemas garabatea unas pocas palabras explicando cada CU.
Después 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 cuáles son necesarios para el
desarrollo en las primeras iteraciones, y cuales pueden dejarse para más tarde.

Detallar un CU

El objetvo principal de detallar cada CU es describir su fujo de sucesos en detalle, incluyendo cómo comienza, termina e
interactúan con los actores.
El especifcador de CU detalla paso a paso la descripción de cada CU en una especifcación 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 más 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 más
específcas (generalizaciones).
• Extraer descripciones de funcionalidad adicionales u opcionales que pueden extraer descripciones más
específcas (inclusiones y extensiones).


CASOS DE USO

Defnición en la parte anterior de la unidad.
Los CU:

• Son descripciones de la funcionalidad del sistema independientes de la implementación.
• Describen los límites del sistema y las relaciones entre el sistema y el entorno.
• Defnen el conjunto de requerimientos, atendiendo a la categoría 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 debería poder entenderlos para realizar su validación)

¿Qué asumimos para la defnición de Casos de Uso?

Propósito: Determinación de REQUERIMIENTOS (Funcionales)
Contenido: Descripción 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 información. Poseen la prioridad más 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 clasifcación:
Concreto: Son aquellos que son instanciados por un actor o trabajador.
Abstracto: son aquellos que nunca serán instanciados por un actor. Son instanciados por otros CU por medio de inclusión
o extensión.

CU y actores

Defnición de actor en la parte anterior.
Los actores sólo se pueden conectar a los CU a través de asociaciones.

Generalización entre actores
Se defne una categoría general de actor y se especializa a través de relaciones de generalización. 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 podría haber CU
que son instanciados por uno de los actores “hijo” en partcular.


Generalización

CU y fujo de eventos

Un CU describe qué hace un sistema, pero no especifca cómo 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 cómo y cuándo empieza y acaba el CU, cuándo interactúa con los actores y qué
objetos se intercambian, el fujo básico 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 sería 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 colaborarán para llevar a
cabo el comportamiento del CU. Esta sociedad de elementos, incluyendo tanto su estructura estátca como dinámica, se
modela en UML como una colaboración.

Organización de CU

Los CU pueden organizarse agrupándolos en paquetes, de la misma manera que se organizan las clases. Los
CU también pueden organizarse especifcando relaciones entre ellos:

• Inclusión: Relación dada únicamente entre casos de uso. Parte de la funcionalidad que detecto como común
entre los CU, al detectarla la pongo aparte. El CU base incorpora explícitamente el comportamiento de otro CU en
el lugar especifcado en el caso base. El CU incluido sólo es instanciado como parte de algún CU base más amplio
que lo incluye.
Vendedor de
mostrador
Viajante
Vendedor
Registrar Venta
Un CU de inclusión es siempre un CU abstracto. La fecha va del CU base al CU abstracto.



• Extensión: el CU base incorpora implícitamente 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 extensión al CU base.


• Generalización: Se diferencia de la inclusión 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 añadir o redefnir el comportamiento del CU padre.

con tarjeta


DIAGRAMA DE CASOS DE USO

Defnición en Unidad 7.

Un diagrama de CU contene:

• Casos de uso.
• Actores.
• Relaciones de dependencia, generalización y asociación.

Usos comunes

Los diagramas de CU se emplean para modelar la vista de CU estátca de un sistema.
Caso de uso base
Caso de uso incluído
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 estátca de un sistema, normalmente se emplearán 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é debería hacer el sistema, independientemente de cómo
se haga.

Especifcación de CU Defnición
en unidad 7.

Pre-condiciones
Una pre-condición es una restricción sobre cuándo un CU puede empezar. No es el evento que inicia el CU.

Post-condiciones
Una post-condición para un CU debe ser verdadera, independientemente de cuál fujo sea ejecutado.

A saber: un requerimiento puede incluir 1 o más 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).
-Estátco (porque no muestra comunicación ni interrelación).
-Lógico (porque es conceptual, teórico, no lo bajamos a un lenguaje ni a lo fsico.

USO:
-Comunicar el Alcance.
-Proveer descripción de todo o una parte de los requerimientos de un sistema u organización.

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

CONTIENE comúnmente:
-Casos de Uso
-Actores
-Relaciones de extensión, inclusión, generalización.
-Paquetes

Construcción del diagrama de casos de uso

Identfcar los Actores
Defnir la funcionalidad esencial relacionada a cada actor a través de casos de uso.
Identfcar parte de funcionalidad común y opcional en los casos de uso, y agregar relaciones de inclusión, extensión y
generalización.
Defnir casos de uso de soporte, que ayuden a que la funcionalidad principal se cumpla


PATRONES DE CU

Un patrón es una solución a un problema. Para que una solución sea considerada un patrón debe poseer ciertas
característcas. 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 algún contexto determinado del proceso
de desarrollo de sofware y entregan una buena solución ya probada. Son estereotpos que usamos una y otra vez para
solucionar problemas parecidos. Se pueden utlizar millones de veces y además perfeccionarlos.

Un buen patrón:

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

También debe especifcar:

1. Cuándo aplicarlos
2. Si debe o no ser aplicado.
3. Consecuencias de la aplicación
4. Que debe tenerse en cuenta cuando se lo está aplicando
5. Debe formularse estableciendo una relación entre un contexto, un sistema y una confguración que permita
resolver el problema.

Componentes:

1. Nombre
2. Propósito
3. Sinónimo
4. Colaboraciones
5. Contexto
6. Explicación
7. Fuerzas
8. Motvación
9. Ejemplos
10. Patrones Relacionados
11. Aplicabilidad
12. Estructura
13. Partcipantes
14. Consecuencia

Patrones de CU

Organización del lenguaje de los patrones de CU

• Consiste en 31 patrones • Conforman dos categorías:

Patrones de Desarrollo: describen característcas de práctca de escritura de CU probadas, y ofrecen criterios para medir
la calidad del proceso de escritura de CU.
Patrones Estructurales: describen los componentes básicos de los CU, explicando cómo deberían 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 colección 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 acción que el actor o el sistema
debe hacer para acercar al actor a su objetvo.
• Relaciones de CU: los CU a menudo interactúan con otros CU. Los patrones de relación describen técnicas 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 característcas para el desarrollo efectvo de CU. Estos
patrones se dividen en tres subcategorías:

• De equipo: composición de los equipos que escriben CU.
• De proceso: técnicas para crear un conjunto de CU.
• De edición: técnicas para mejorar CU existentes.

Ver ejemplos en cuadernillo!

Patrones de dominio

Los patrones de dominio son soluciones expresadas en términos de objetos e interfaces. Se expresan en base a la estructura
y/o comunicación de objetos y clases para resolver los problemas de contexto.
Un patrón de modelo de objetos es una agrupación de objetos con responsabilidades estereotpadas y escenarios de
interacción.

15. Patrón Fundamental: Es la plantlla que todos los patrones siguen

1. #1 – Patrón: “Colección-Trabajador”

16. Patrones Transaccionales: Los patrones transaccionales son aquellos patrones que tenen un jugador de transacción o
tenen jugadores que comúnmente juegan con un jugador de transacción.

1. #2 – “Actor - Partcipante”
1. Organización – Agente
2. #3 – “Partcipante - Transacción”
1. Agente – Contrato
3. #4 – “Lugar - Transacción”
1. Aeropuerto – Venta
4. #5 – “Ítem especifco - Transacción”
1. Vehículo Especifco – Venta

5. #6 – “Transacción - Detalle de Transacción”
1. Pago – Detalle de Pago

6. #7 – “Transacción - Transacción subsiguiente”
1. Compra – Pago

7. #8 – “Detalle de Transacción – Detalle de Transacción Subsiguiente”
1. Detalle de orden – Detalle de Envió

8. #9 – “Ítem - Detalle de Transacción”
1. Ítem – Detalle de Pago

9. #10 – “Ítem especifco - Detalle de Transacción”
1. Video – Detalle de Alquiler

10. #11 – “Ítem - Ítem especifco”
1. Aeroplano – Aeroplano Especifco

11. #12 – “Asociación – Otra Asociación”
1. Conductor – Vehículo

12. #13 – “Ítem especifco – Jerarquía de ítem”
Cuenta – Jerarquía de descripción de cuentas

UNIDAD Nº 10
“EL FLUJO DE TRABAJO DE ANÁLISIS”


El fujo de trabajo de análisis: concepto, importancia.

El objetvo de este fujo de trabajo es analizar los requerimientos que se describieron en la captura de requerimientos,
refnándolos y estructurándolos. El objetvo de hacerlo es conseguir una comprensión más precisa de los requerimientos y
una descripción de los mismos que sea fácil 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 especifcación de funcionalidad completa.

En el análisis podemos razonar más sobre los aspectos internos del sistema.
La estructura de los requisitos que proporciona el análisis también sirve como entrada fundamental para dar forma al
sistema en su totalidad.

Artefactos, trabajadores y actvidades del fujo de trabajo de análisis.

ARTEFACTOS

Clase del análisis

Una clase de análisis representa una abstracción de una o varias clases y/o subsistemas del diseño del sistema. Esta
abstracción posee las siguientes característcas:

• Una clase de análisis se centra en el tratamiento de los RF, dejand de lado los no funcionales para las actvidades
de diseño.
• Una clase de análisis raramente defne su comportamiento mediante responsabilidades en un nivel más alto y
menos formal (una responsabilidad es una descripción textual de un conjunto cohesivo del comportamiento de
una clase).
• Una clase de análisis defne atributos. Los atributos identfcados durante el análisis con frecuencia pasan a ser
clases en el diseño y la implementación.
• Una clase de análisis partcipa en relaciones.
• Las clases de análisis siempre encajan en uno de tres estereotpos básicos:

De interfaz: se utlizan para modelar la interacción entre el sistema y sus actores. Esta interacción a menudo implica
recibir (y presentar) información 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 debería asociarse con al menos un actor (y viceversa).

Ventana Ingreso

de pedido


De entdad: se utlizan para modelar información que posee una vida larga y que es a menudo persistente. Modelan la
información y el comportamiento asociado de algún fenómeno 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 dinámico del sistema (coordinación, secuencia,
transacciones y control de otros objetos). Coordinan acciones y delegan trabajo a otros objetos.


Pedido
Gestor de
pedidos

Realización de caso de uso-análisis

Una realización de caso de uso – análisis es una colaboración dentro del modelo de análisis que describe cómo se lleva a
cabo y se ejecuta un CU en términos de las clases del análisis y de sus objetos del análisis en interacción. Una realización
de CU proporciona por tanto una traza directa hacia un CU concreto del modelo de CU.

Diagramas de clases
Una clase del análisis 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 interacción
La secuencia de acciones en un CU comienza cuando un actor invoca el CU mediante el envío de algún tpo de mensaje al
sistema. En el análisis se prefere mostrar esto con diagramas de colaboración, ya que el objetvo es identfcar requisitos y
responsabilidades sobre los objetos, y no identfcar secuencias de interacción.
En los diagramas de colaboración, se muestran las interacciones entre objetos creando enlaces entre ellos y añadiendo
mensajes a estos enlaces.

Dentro de una realización de CU, objetos diferentes tenen diferentes ciclos de vida:
• Un objeto de interfaz no tene por qué ser partcular de una realización de CU. Sin embargo, los objetos de
interfaz a menudo se crean y fnalizan dentro de una sola realización de CU.
• Un objeto de entdad normalmente no es partcular de una realización de CU.
• Las clases de control suelen encapsular el control asociado con un CU concreto, lo cual implica que debería
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 más de una realización de CU, cuando varios objetos
de control partcipan en una misma realización de CU, y cuando una realización de CU no requiere ningún objeto
de control.

Paquete del análisis

Los paquetes del análisis proporcionan un medio para organizar los artefactos del modelo de análisis en piezas manejables.
Puede constar de clases de análisis, de realizaciones de CU, y de otros paquetes del análisis.
Los paquetes del análisis tenen las siguientes característcas:
• Pueden representar una separación de intereses de análisis.
• Deberían crearse basándonos en los RF y en el dominio del problema.
• Probablemente se convertrán en subsistemas en las dos capas de aplicación superiores del modelo de diseño.

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.


Descripción de la arquitectura (vista del modelo de análisis)

La descripción de la arquitectura contene una vista de la arquitectura del modelo de análisis, que muestra sus artefactos
signifcatvos para la arquitectura.
Los siguientes artefactos del modelo de análisis normalmente se consideran signifcatvos para la arquitectura:
La descomposición del modelo de análisis en paquetes de análisis y sus dependencias.
Las clases fundamentales del análisis como las clases de entdad, las clases de interfaz, las clases de control y las clases del
análisis que son generales.
Realizaciones de CU que describen cierta funcionalidad importante y crítca 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 análisis, garantzando que éste sea correcto, consistente y
legible como un todo.
El arquitecto es responsable de lo que es signifcatvo para la arquitectura (descripción de la arquitectura).
Es también responsable de la arquitectura del modelo de análisis.
El arquitecto no es responsable del desarrollo y mantenimiento de los artefactos del modelo de análisis.

Ingeniero de casos de uso

Un ingeniero de CU es responsable de la integridad de una o más realizaciones de CU, garantzando que cumplen los
requerimientos que recaen sobre ellos.
Es también responsable del diseño de las realizaciones de los CU (por lo tanto, es responsable tanto del análisis como del
diseño del CU).
El ingeniero de CU no es responsable de las clases de análisis ni de las relaciones que se usan en la realización 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 análisis.
También mantene la integridad de uno o varios paquetes del análisis, garantzando que sus contenidos son correctos.


ACTIVIDADES (fujo de trabajo)





Los arquitectos comienzan la creación del modelo de análisis identfcando los paquetes de análisis principales, las clases
de entdad y los requisitos comunes. Después, los ingenieros de CU realizan cada CU en términos de las clases del análisis
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 análisis, clases y requisitos comunes, y los ingenieros de
componentes responsables de los paquetes del análisis contnuamente los refnan y mantenen. Análisis de la arquitectura

El propósito del análisis de la arquitectura es esbozar el modelo de análisis y la arquitectura mediante la identfcación de
paquetes del análisis, clases del análisis y requisitos especiales.


Identfcación de paquetes del análisis
Los paquetes del análisis proporcionan un medio para organizar el modelo de análisis en piezas más pequeñas y más
manejables.
Una identfcación inicial de los paquetes del análisis se hace basándonos 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 análisis es asignar la mayor parte
de un cierto número 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 generalización y de extensión.


Identfcación de clases de entdad obvias
Suele ser adecuado prepara una propuesta preliminar de las clases de entdad más importante basado en las clases del
dominio o la EN que se identfcaron durante la captura de requerimientos. Sin embargo, la mayoría de las clases se
identfcarán al crear las realizaciones de los CU.



Identfcación de requisitos especiales comunes
Un requisito especial es un requisito que aparece durante el análisis y que es importante anotar de forma que pueda ser
tratado en las actvidades de diseño e implementación.

Ejemplos:
• Persistencia.
• Distribución y concurrencia.
• Característcas de seguridad.
• Tolerancia a fallos.
• Gestón de transacciones.

Analizar un caso de uso

Analizamos un CU para:

• Identfcar las clases del análisis.
• Distribuir el comportamiento del CU entre los objetos del análisis que interactúan.
• Capturar requisitos especiales.

Otra forma de llamar al análisis de CU es refnamiento de CU. Refnamos cada CU como colaboración de clases del análisis.

Identfcación de clases del análisis
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 están sufcientemente detallados, por lo tanto, puede que tengamos que
refnar las descripciones de los CU.

Descripción de interacciones entre objetos del análisis
Cuando tenemos un esbozo de las clases necesarias para realizar el CU, debemos describir cómo interactúan sus
correspondientes objetos del análisis. Esto se hace mediante diagramas de colaboración.

Captura de requisitos especiales
Recogemos todos los requisitos sobre una realización de CU que se identfcan en el análisis, pero deberían tratarse en el
diseño y en la implementación.
Debemos hacer referencia si es posible a los requisitos especiales comunes que habían sido identfcados por el arquitecto.

Analizar una clase

Los objetvos de analizar una clase son:

• Identfcar y mantener las responsabilidades de una clase del análisis.
• Identfcar y mantener los atributos y relaciones de la clase de análisis.
• Capturar requisitos especiales sobre la realización de la clase de análisis.


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

Identfcación de atributos
Un atributo especifca una propiedad de una clase de análisis, y normalmente es necesaria para las responsabilidades de su
clase.

Identfcación de asociaciones y agregaciones
Los objetos del análisis interactúan unos con otros mediante enlaces. Estos enlaces suelen ser instancias de asociaciones
entre sus correspondientes clases. El ingeniero de componentes debería estudiar los enlaces empleados para determinar
qué asociaciones son necesarias. Los enlaces pueden implicar la necesidad de referencias y agregaciones entre objetos.

Identfcación de generalizaciones
Las generalizaciones deberían utlizarse durante el análisis para extraer comportamiento compartdo y común entre varias
clases del análisis diferentes.

Captura de requisitos especiales
Recogeremos todos los requisitos de una clase del análisis que se han identfcado en el análisis, pero que deberían tratarse
en el diseño y en la implementación.
Debemos hacer referencia si es posible a cualquier requisito especial común identfcado por el arquitecto.

Analizar un paquete

Los objetvos de analizar un paquete son:

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

El lenguaje que utlizamos en el análisis se basa en un modelo de objetos conceptual, que llamamos modelo de análisis. El
modelo de análisis nos ayuda a refnar los requisitos y nos permite razonar sobre los aspectos internos del sistema. El
modelo de análisis también nos ayuda a estructurar los requisitos y nos proporciona una estructura centrada en el
mantenimiento.
El modelo de análisis puede considerarse una primera aproximación al modelo de diseño, aunque es un modelo por sí
mismo.
Sin embargo, es importante hacer notar que el modelo de análisis hace abstracciones y evita resolver problemas y tratar
algunos requisitos que es mejor posponer al diseño y a la implementación.

Por qué el análisis no es diseño ni implementación

El diseño y la implementación son mucho más que el análisis (refnamiento y estructuración de los requerimientos), por lo
que se requiere una separación de intereses.
El diseño y la implantación son mucho más que simplemente el analizar los requerimientos; el diseño y la implementación
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 diseñar e implementar deberíamos contar con una comprensión precisa y detallada de los
requerimientos, lo cual se logra en el análisis.

Modelo de análisis: resumen

• Ofrece una especifcación más precisa de los requerimientos.
• Se describe utlizando el lenguaje de los desarrolladores.
• Estructura los requerimientos de un modo que facilita su comprensión, su preparación, su modifcación y su
mantenimiento.
• Puede considerarse una primera aproximación al modelo de diseño.
• Proporciona una vista interna del sistema.
• Está estructurado por clases y paquetes.
• Es utlizado fundamentalmente por los desarrolladores para comprender cómo debería darse forma al sistema.
• No debería contener redundancias, inconsistencias, etc.
• Defne realizaciones de CU y cada una de ellas representa el análisis de un CU.

El análisis en el ciclo de vida del sofware

Las iteraciones iniciales de la elaboración se centran en el análisis. Eso contribuye a obtener una arquitectura estable y
sólida y facilita una comprensión en profundidad de los requerimientos. Al término de la fase de elaboración y durante la
construcción, el énfasis pasa al diseño y a la implementación.
La manera de ver y emplear el análisis puede diferir de un proyecto a otro:

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

Los objetos interactúan entre sí pasándose mensajes. Una interacción es un comportamiento que incluye un conjunto de
mensajes intercambiados por un conjunto de objetos dentro de un contexto para lograr un propósito.
Las interacciones se utlizan para modelar los aspectos dinámicos de las colaboraciones.
Las interacciones incluyen los mensajes enviados entre objetos. Un mensaje implica la invocación de una operación o el
envío de una señal.

Enlaces

Un enlace es una conexión semántca 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 especifcación de una comunicación entre objetos que transmite información, con la expectatva de que
se desencadenará una actvidad. La recepción de una instancia de un mensaje puede considerarse una instancia de un
evento.
En UML se pueden modelar varios tpos de acciones:
• Llamada.
• Retorno.
• Envío.
• Creación.
• Destrucción.

Secuenciación

Cuando un objeto envía 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.

Representación

Cuando se modela una interacción, normalmente se incluirán tanto objetos como mensajes.
Los objetos y mensajes implicados en una interacción se pueden visualizar de dos formas:
• Destacando la ordenación temporal de sus mensajes (diagrama de secuencia).
• Destacando la organización estructural de los objetos que envían y reciben los mensajes (diagrama de
colaboración).
DIAGRAMAS DE INTERACCIÓN

Un diagrama de interacción muestra una interacción, 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 interacción que destaca la ordenación temporal de los mensajes.
Un diagrama de colaboración es un diagrama de interacción que destaca la organización estructural de los objetos que
envían y reciben mensajes.
Los diagramas de interacción no son sólo importantes para modelar los aspectos dinámicos de un sistema, sino también
para construir sistemas ejecutables por medio de ingeniería directa e inversa.

Contenidos

Normalmente, los diagramas de interacción contenen:
• Objetos.
• Enlaces.
• Mensajes.

Diagramas de secuencia

Un diagrama de secuencia destaca la ordenación temporal de los mensajes.
Tienen dos característcas que los distnguen de los diagramas de colaboración: en primer lugar, está la línea de vida, que
representa la existencia de un objeto a lo largo de un período de tempo. En segundo lugar, está el foco de control, que
representa el período de tempo durante el cual un objeto ejecuta una acción.

Diagramas de colaboración

Un diagrama de colaboración destaca la organización de los objetos que partcipan en una interacción.
Los diagramas de colaboración tenen dos característcas que los distnguen de los diagramas de secuencia: en primer
lugar, el camino. En segundo lugar, está la secuencia. Para indicar la ordenación temporal de un mensaje, se precede de un
número.
En un diagrama de colaboración interactúan objetos, no clases.
Se hace un diagrama de colaboración por cada escenario del CU que el diagrama describe.

MÁQUINAS DE ESTADO

El comportamiento de una sociedad de objetos que colaboran puede ser modelado mediante una interacción. El
comportamiento de un objeto individual puede ser modelado mediante una máquina de estados.
Una máquina 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 condición o situación en la vida de un objeto durante la cual satsface alguna condición, realiza alguna
actvidad o espera algún 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 máquina de estados; y el estado fnal indica que la
ejecución de la máquina de estado o del estado que lo contene ha fnalizado.

Transiciones
Una transición es una relación 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 máquina de estados.
Un diagrama de actvidades es un caso especial de diagrama de estados en el cual todos o la mayoría de los estados son
estados de actvidad y todas o la mayoría de las transiciones se disparan por la terminación de las actvidades en el estado
de origen.

COLABORACIONES
Una colaboración denota una sociedad de clases, interfaces y otros elementos que colaboran para proporcionar algún
comportamiento cooperatvo.
Las colaboraciones se utlizan para especifcar la realización 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
colaboración a la que se da nombre.
• Una parte de comportamiento que especifca la dinámica de cómo interactúan esos elementos.

Comportamiento
Mientras que la parte estructural de una colaboración se representa normalmente mediante un diagrama de clases, la parte
de comportamiento de una colaboración se representa mediante un diagrama de interacción.
Si se quiere destacar la ordenación 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 colaboración.

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


Patrones para la asignación de responsabilidades

Se aplican durante la construcción de diagramas de interacción, al asignar responsabilidades a los objetos y al diseñar la
colaboración entre ellos. Ej: patrón experto.