Unidad N° 1: Los Sistemas de Información

Introducción (Datos, Información y Sistema)

Los datos son realidades concretas en su estado primario, representan hechos reales y
poseen escaso valor más allá del de su sola existencia. Por ejemplo, es posible pensar en los datos
como piezas de madera, en cuya condición tiene escaso valor más allá del que poseen como
objetos específicos. En cambio, si se define algún tipo de relación entre las piezas de madera, éstas
adquirirán mayor valor.

Por su parte, la información es muy similar; pueden establecerse reglas y relaciones para
organizar datos a fin de que provean útil y valiosa información. La información se define como un
conjunto de datos organizados de tal modo que adquieren un valor adicional más allá del propio.

Ejemplos de datos: el nombre de un empleado y la cantidad de horas trabajadas por él en una

semana, los pedidos de venta o los números de parte de un inventario.

Ejemplos de Información: un administrador podría considerar más acorde con su propósito

conocer las ventas mensuales totales que la cantidad de ventas de cada vendedor individual.

Características de la información:

 Exacta: carece de errores. Se genera información inexacta porque se insertan datos

inexactos.
 Completa: contiene todos los datos importantes.
 Flexible: es útil para muchos propósitos.
 Confiable: depende por lo general de las técnicas de recopilación de información que se
realiza.
 Pertinente: es la realmente importante para los tomadores de decisiones.
 Simple: debe ser simple, no excesivamente compleja, no muy detallada ni sofisticada.
 Oportuno: es la que se recibe justo cuando se la necesita.
 Verificable: debe ser verificable, es decir, que se pueda comprobar que la información es
correcta.
 Accesible: La información debe ser de fácil acceso para los usuarios autorizados.
 Segura: debe estar protegida contra el acceso a ella de usuarios no autorizados.

Otro de los conceptos centrales es el de Sistema. Un Sistema es un conjunto de elementos o

componentes que interactúan entre sí para cumplir objetivos. Los propios elementos y relaciones
entre ellos determinan el funcionamiento del sistema.

Los sistemas poseen Entradas, Procesamientos, Salidas y Retroalimentación. Las entradas son
aquellos objetos, acciones, procesos o algún evento que desencadena el funcionamiento del
sistema. Los procesamientos son acciones, procedimientos que se realizan sobre las entradas para
producir las salidas que dará el sistema. Las salidas, es la consecuencia de los procesamientos,
suelen representar algo de valor para alguien o pueden ser, a su vez, entradas para otro sistema.
La Retroalimentación, se le suele llamar también FeedBack, es un proceso que consiste en utilizar
la información de las salidas para realizar cambios en actividades de entrada o procesamiento.

Sabiendo todo esto, ¿Qué es un Sistema de Información?

Un Sistema de Información es un conjunto de elementos interrelacionados para recolectar,

manipular y diseminar datos e información permitiendo una retroalimentación entre los
componentes para cumplir el objetivo.

Un sistema de información está compuesto por:

 Personas: el personal de sistemas de información incluye a todos los individuos que

administran, operan, programan y mantienen el sistema.
 Procedimientos: son las estrategias, políticas, métodos y reglas para el uso del sistema de
información basado en computadoras. Describen en qué momento ejecutar un programa,
quién puede tener acceso a información de la base de datos, qué debe hacerse en casos
donde el sistema de información sea inutilizable.
 Equipo: material necesario para poder implementar el sistema de información.
Un sistema informático, a diferencia del sistema de información, esta compuesto por:
 Personas
 Procedimientos
 Hardware
 Software
 Base de Datos
 Telecomunicaciones

Tipos de Sistemas de Información:

 Sistema de procesamiento de transacciones(TPS) y comercio electrónico(CE):
o TPS: Conjunto organizado de personas, procedimientos, software, base de datos y
dispositivos para registrar las transacciones comerciales consumadas. Se entiende
por transacción a todo intercambio relacionado con la actividad empresarial, tales
como pago del empleado o ventas. Conocer un sistema de procesamiento de
transacciones es conocer las operaciones y funciones básicas de las compañías.
o CE: Transacciones de negocios ejecutadas por medios electrónicos entre
compañías, consumidores y sector publico. Debido al acceso de internet, hubo un
crecimiento en este comercio por parte de los usuarios, debido a la confianza,
seguridad y comodidad.

 Sistemas de información Administrativos: Los beneficios provistos por un eficaz sistema de

procesamiento de transacciones son tangibles y permiten justificar su costo en equipo y
programas de computación. Pero a pesar del valor que brindan, es evidente que los datos
almacenados en ellos pueden resultar de utilidad para los administradores en la toma de
mejores decisiones.
 Un Sistema de información administrativa es un conjunto organizado de personas,
procedimientos, software, bases de datos y dispositivos para suministrar información
rutinaria a administradores y tomadores de decisiones. El interés particular es la eficiencia
operativa y se caracterizan por utilizar sistemas de información para producir informes
administrativos que se generan de manera periódica. Áreas funcionales, como
producción, finanzas, se apoyan en sistemas de información administrativa y se vinculan
entre si por medio de una base de datos común, por lo general, procedentes del sistema
de procesamiento de transacciones.

 Sistema de apoyo para la toma de decisiones: Un sistema de apoyo para la toma de

decisiones es un conjunto organizado de personas, procedimientos, software, bases de
datos y dispositivos para el apoyo en la toma de decisiones, sirve de base y fuente de
ayuda para todos los aspectos de la toma de decisiones referentes a problemas
específicos. Es capaz de ofrecer asistencia inmediata para resolver problemas complejos.
Se recurre a un sistema de este tipo cuando se está frente a un problema complejo en el
que es difícil obtener y usar la información necesaria para tomar la mejor decisión.

 Sistema de inteligencia artificial(IA) y expertos(EX):

o IA: El campo de inteligencia artificial incluye varios subcampos. La robótica es el
area donde las maquinas ejecutan tareas complejas, rutinarias o tediosas, tales
como la soldadura del chasis de un automóvil o el montaje de sistemas de
computación y sus componentes. Los sistemas de visión, que dotan de “vista” a
robots y otros dispositivos con lo cual son capaces de almacenar y procesar
imágenes visuales. El procesamiento del lenguaje natural, implica la facultad de las
computadoras para comprender y responder a órdenes orales o escritas en varios
idiomas. Los sistemas de aprendizaje, habilitan a las computadoras para aprender
de la experiencia o de sus errores.
o EX: Los sistemas expertos facultan a las computadoras para hacer sugerencias y
proceder a la manera de expertos en un campo en particular. El valor excepcional
de los sistemas expertos radica en el hecho de que permiten a las organizaciones
proveerse de y utilizar el saber de expertos y especialistas. Por lo tanto, años de
experiencia y habilidades específicas no se pierden del todo cuando un experto
muere, se retira o cambia de trabajo.

Entonces, ¿para que utilizan los sistemas de información las empresas?

Para operar con eficiencia, las empresas se apoyan cada vez más en los sistemas de información.
En definitiva el objetivo de esta computarización es satisfacer a los clientes de una empresa y
proporcionar una ventaja competitiva al reducir los costos y mejorar el servicio.

El procesamiento de transacciones fue uno de los primeros procesos que se computarizaron en las
empresas; además sin los sistemas de información, el registro y el procesamiento de las
transacciones de negocios requeriría de enormes cantidades de los recursos de una organización.
Los sistemas de procesamiento de transacciones realizan operaciones rutinarias tales como
pedidos y facturación de ventas, y realizan con frecuencia diaria o semanalmente las mismas
operaciones.

Existen varios métodos para procesar las transacciones y son:

 Procesamiento por lotes: en los inicios de la evolución de los sistemas computarizados de

procesamiento de transacciones, todas las transacciones se reunian en grupos,
denominados “lotes” y se procesaban juntos. Las operaciones de negocio se acumulan por
un tiempo y se preparan para ser procesados como una sola unidad o lote. La
característica esencial es que se produce una 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: la tecnología de computación actual permite

otro método de procesamiento denominado “procesamiento en línea”, con esta forma de
procesamiento, 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. Por consiguiente, los datos en un sistema en
línea en cualquier momento presentan la situación actual.

 Entrada en línea con procesamiento retardado: este tipo de procesamiento es un

intermedio entre los procesamientos por lotes y en línea. Con este tipo de sistema, los
pedidos o las transacciones se introducen al sistema de computación al momento en que
ocurren, pero no se procesan de inmediato.

Para seleccionar que método para procesar las transacciones se debe elegir, se debe tener
en cuenta los objetivos específicos de la organización. Las empresas por lo general esperan
que su sistema de procesamiento de transacciones logren varios objetivos, como por
ejemplo, “procesar datos generados por las transacciones y que se relacionen con ellas”,
“asegurar la integridad y la exactitud de los datos y la información”, “elaborar documentos
e informes oportunos”, “ayudar a proporcionar mayores y mejores servicios”, “lograr una
ventaja competitiva”, etc.

¿Por qué una empresa elige utilizar sistemas informaticos?

 Procesamiento más rápido, consultas rápidas

 Mayor exactitud y consistencia de la información
 Reducción de costos
 Eficiencia de mano de obra
 Mayor seguridad
Sistemas de Informacion que dan soporte a los procesos de negocio

Aunque los Sistemas de Informacion de las empresas están adaptados a las circunstancias de cada
una de ellas (mercado, tipo de negocio, tamaño, recursos, etc.), todos los sistemas presentan
algunas características comunes, puesto que ciertas actividades de gestión suelen ser muy
parecidas en la mayoría de las organizaciones. Podríamos decir que una empresa típica cuenta con
una estructura de Sistema de Informacion compuesta por los siguientes subsistemas:

 Subsistema de Recursos Humanos: se ocupa tanto de la gestión del personal como de la

nomina.
o Personal: incluye toda la información personal compuesta por el historial labora,
datos personales, salario, etc.
o Nomina: se realiza de forma periodica. Se responsabiliza del mantenimiento de
datos de los empleados, experiencia y perfil psicológico de los mismos, puestos de
trabajos y evaluación de los empleados.
 Subsistema de Gestion Contable y Financiera: la parte contable es la que registra todos los
movimientos realizados por la empresa y la parte financiera es la encargada de registrar
todo lo relacionado con pagos y cobros.
 Subsistema de Gestion Comercial y de Marketing: maneja todos los flujos de información
de los gustos del cliente y el manejo de las ventas.
 Subsistema de Control de Existencias y de Produccion: maneja toda la información del
momento en que se necesita una reposición.
 Unidad 2: El Modelado de Procesos de Negocio

Introduccion

En esta unidad describiremos como se debe modelar los procesos de negocio con UML, explicando
las herramientas que se utilizaran para lograr los modelos de negocio.

UML significa Lenguaje Unificado de Modelado, es tal como su nombre lo indica, un lenguaje de
modelado y no un método o un proceso, es decir no nos define como se debe modelar.

Comenzando con lo básico, ¿Qué es un modelo?, Un modelo es una representación abstracta de

un objeto real que se construye para comprender el objeto modelado. Se pueden realizar modelos
diferentes de un mismo objeto, por eso es importante establecer el objetivo que se persigue. Los
modelos deben ser graficos con detalles textuales apropiados, deben permitir que el sistema se
pueda ver en partes, deben ser transparentes para el lector.

¿En que ayudan los modelos a los analistas? Les ayuda a entender el comportamiento, la
información y el funcionamiento del sistema, también sirven de base para la revisión del trabajo
realizado y sirven de base para la etapa siguiente.

Los analistas lo utilizan porque les permite concentrarse en lo importante dejando de lado
aspectos que en ese momento no son de gran interés, les permite disctir cambios del sistema a
bajo costo y ahorrar tiempo. Tambien permite verificar que se comprendió lo que el cliente pidió,
al utilizar modelos se obtiene información documentada del sistema.

Sabiendo para que se utilizan los modelos y que son, ¿Qué es el modelado de negocio? Es una
parte esencial de cualquier proceso de desarrollo de software. Es una técnica que se utiliza para
comprender los procesos de negocio de una organización. Muestra el ambiente de la organización
y cómo ésta actúa en relación con el ambiente. Con un modelo preliminar del negocio, permite al
analista capturar los eventos, las entradas, los recursos y las salidas más importantes vinculadas
con el proceso de negocio.

Es necesario modelar el negocio porque nos permite conocer el contexto en el cual se va a insertar
el sistema de información y a partir de ello identificar futuros usuarios del sistema, tareas que se
llevan a cabo en los procesos y los documentos que se generan en cada proceso. Nos permite
detectar problemas y ver oportunidad de mejoras, permite que el cliente y el desarrollador
comprendan exactamente lo mismo.

Siempre que construimos un Sistema de Informacion, ¿debe modelarse el negocio?

Es necesario cuando:

 Tengamos que modelar el dominio

 En caso de sistemas para encontrar requerimientos funcionales.
 En caso de construir Sistema de Información utilizados por varias organizaciones para ver
como trabajan ellos y evitar que los requerimientos sean muy complejos.
  En caso de que la organización decida cambiar su manera de hacer sus procesos, eso se
conoce como Reingenieria.

Estructura del Modelo de Negocio

La estructura se divide en vistas, Vista Externa y Vista Interna.

Vista Externa: muestra lo esencial que realiza el negocio para entregar un resultado deseado al
actor o usuario. Esta compuesto actores, eventos, procesos, información, recursos, objetivos y
salidas.

Informacion Recursos Objetivo

Evento Proceso Salida

Vista Interna: define como debería ser organizado y ejecutado el trabajo para lograr los mismos
resultados deseados. Puede comprender además a los trabajadores y entidades de negocio.

A partir del modelo de negocio, aparece un concepto llamado Proceso de Negocio, que se define
como una colección de actividades relacionadas, diseñadas para producir una salida específica
para un cliente o un mercado en particular. Esto implica un fuerte énfasis en cómo se realiza el
trabajo dentro de la organización.

Se puede modelar procesos de negocio a partir del Diagrama de Actividad. Es un diagrama de flujo
que muestra el flujo de control entre actividades, la concurrencia y las bifurcaciones del control.
Sirven para visualizar, especificar, construir y documentar la dinámica de una sociedad de objetos.
Permiten modelar procesos como una actividad que consta de una colección de nodos conectados
por extremos.

Entre las herramientas del Diagrama de Actividad tenemos los nodos.

 Nodos de Acción: representa unidades de trabajo que son atómicas dentro de la actividad.
 Unidad 3 Proceso de Desarrollo de Software

Conceptos de modelo:

 Método: conjunto de pasos para realizar una tarea o cumplir un objetivo. Un método
define ¿Qué hacer?
 Herramienta: elementos que nos ayudan a construir modelos. Las herramientas definen
¿con que?
 Técnica: procedimiento ordenado que se lleva a cabo para realizar una tarea. Las técnicas
definen el ¿Cómo?
 Metodología: conjunto de métodos, herramientas y técnicas.
 Proceso de Software: da un marco de trabajo a las actividades necesarias para construir un
sistema de alta calidad en el tiempo adecuado.
 Paradigma: es una forma de pensar. Conjunto de teorías, métodos, que en conjunto
organizan el pensamiento. Es una forma de mirar la realidad
 Ingeniería de Software: metodología que nos permite desarrollar software económico,
que sea fiable, y funcione de manera eficiente sobre máquinas reales.

Metodologías

Es importante utilizar metodologías estandarizadas ya que sirven para aumentar la productividad

del equipo de trabajo, debido a que las herramientas utilizadas ya fueron probadas y optimizadas.
Al tener un lenguaje en común, se facilita la comunicación entre los desarrolladores.
Caracteristicas:

 Deben ser COMPLETAS. Eso significa, que cubran todos los aspectos del dominio del
problema y la solución.
 Deben ser VERIFICABLES. Que permita realizar correcciones.
 Deben GENERAR PRODUCTOS contra los cuales se pueda medir el avance del producto.
 Esos productos deben ser APROVECHABLES en la fase siguiente.

Marco de Trabajo Genérico del Proceso

1. COMUNICACIÓN: consiste en la relación con el cliente para capturar los requerimientos

del Sistema de Información.
2. PLANEACIÓN: se definen tareas, riesgos posibles, productos que generará y se define un
programa de trabajo.
3. MODELADO: abarca tanto el análisis como el diseño, consiste en construir modelos que
representen diferentes aspectos del sistema.
4. CONSTRUCCIÓN: codificación y generación de pruebas del sistema.
5. DESPLIEGUE: consiste en entregar el producto al cliente, para que éste lo evalúe y nos
proporcione información de su información.

Vision Generica de la Ingenieria de Software(actividades genericas)

El proceso de desarrollo del software contiene tres fases genéricas, independientemente del
paradigma de ingeniería elegido. Las tres fases, ANALISIS, DISEÑO Y MANTENIMIENTO, se
encuentran en todos los desarrollos de software, independientemente del área de aplicación, del
tamaño del proyecto o de la complejidad.

ANALISIS
La fase de Analisis se centra en el qué, consiste en estudiar el sistema para determinar qué
mejoras pueden realizarse o si es necesario construir un nuevo sistema. El que desarrolla
el software intenta identirficar qué información ha de ser procesada, qué función y
rendimiento se desa, qué interfaces han de establecerse, qué restricciones de diseño
existen y qué criterios de validadcion se necesitan para definir un sistema correcto. Se
deben especifijar los requisitos clave del sistema y del software, se debe realizar un
documento formal de requisitos. Dentro de esta fase se producirán tres pasos específicos:
 Analisis del Sistema: define el papel de cada elemento de un sistema informatico,
asignando finalmente al software el papel que va a desempeñar.
 Planificacion del proyecto de Software: se analizan los riesgos, se asignan los
recursos, se estiman los costes, se definen las tareas y se planifica el trabajo.
 Analisis de Requisitos: es necesario disponer de una información más detallada del
ámbito de información y de función del software.

Modelo Lógico (tareas a llevar a cabo)

 Buscar funciones mal echas, inexistentes o altamente costosas.

 Reconocer el problema.
 Evaluacion y síntesis, con síntesis hacemos referencia a modelos que representan
la solución.
 Especificar los requisitos.
 Revision.

DISEÑO

La fase de Diseño se centra en el cómo , esto es, el que desarrolla el software intenta
descubrir cómo han de diseñarse las estructuras de datos y la arquitectura del fostware,
cómo han de implementarse los detalles procedimentales, cómo ha de traducirse el diseño
a un lenguaje de programación y cómo ha de realizarse la prueba. Es un proceso por el
cual el Modelo Logico se transforma en Modelo Fisico.

Se produciran tres métodos concretos.

 Diseño del Software: el diseño traduce los requisitos del software a un conjunto de
representaciones que describen la estructura de los datos, la arquitectura, el
procedimiento algorítmico y las características de la interfaz.
  Codificación: las representaciones del diseño deben ser traducidas a un lenguaje
artificial (un lenguaje de programación) dando como resultado unas instrucciones
ejecutables por la computadora.
 Prueba del Software: una vez que el software ha sido implementado en una forma
ejecutable por la máquina, debe ser probado para descubrir los defectos que
puedan existir en la función, en la lógica y en la implementación.

Actividades:

 Diseñar Datos
 Diseñar Arquitectura
 Diseñar Interfaz. Definir dispositivos de E/S (interfaz)
 Aspectos a tener en cuenta: se debe ofrecer retroalimentación, ser consistente al
utilizar formatos y visualización de datos, preguntar por la verificación de
cualquier acción destructiva, permitir volver atrás, perdonar errores, usar
mensajes de error significativos, permitir mantener el contacto visual de una
imagen original, proporcionar ayuda.

MANTENIMIENTO

Se centra en el cambio que va asociado a la corrección de errores, a las adaptaciones

requeridas por la evolución del entorno del software y a las modificaciones debidas a los
cambios de los requisitos del cliente dirigidos a reforzar o a ampliar el sistema. La fase de
Mantenimiento vuelve a aplicar los pasos de las fases de Analisis y Diseño pero en el
contexto del software ya existente. Se encuentran tres tipos de cambio:

 Corrección: incluso llevando a cabo las mejores actividades de garantía de calidad,

es muy probable que el cliente descubra defectos en el software. El
mantenimiento correctivo cambia el software para corregir los defectos.
 Adaptación: con el paso del tiempo es probable que cambie el entorno original
para el que desarrollo el software. El mantenimiento adaptativo consiste en
modificar el software para acomodarlo a los cambios de su entorno externo.
 Mejora: conforme utilice el software, el cliente/usuario puede descubrir funciones
adicionales que podría interesar que estuvieran incorporadas en el software. El
mantenimiento perfectivo amplía el software más allá de sus requisitos
funcionales originales.

Modelos de Proceso de Software

CASCADA
  Sistemático y secuencial
 No se puede volver atrás
 Al principio se establecen todos los requisitos del sistema. Es difícil para el cliente
establecer todos los requerimientos al principio.
 No siempre siguen el flujo secuencial que propone el modelo
 El cliente solo observará el sistema cuando ya éste terminado el diseño.

ESTRUCTURADO

 No es secuencial, es decir, trabaja en paralelo.

 Permite volver atrás.
 No se necesita tener todos los requerimientos definidos al inicio.
 Las especificaciones son gráficas.

PROTOTIPO:

 Se diseña un prototipo rápido para ver si se entendió lo que pidió el cliente y/o para ver la
interfaz.
 Lleva a la confusión entre prototipo y sistema de información.
 Se adapta a cualquier modelo de procesos.

ESPIRAL

 Se incorpora el análisis de riesgo

 Permite solapar etapas
 El software crece por cada vuelta del espiral
 El sistema de información se construye más rápido

Metodología orientada a objetos

La programación orientada a objetos es un paradigma que utiliza objetos como elementos

fundamentales en la construcción de la solución. Un objeto es una abstracción de algún hecho o
ente del mundo real que tiene atributos que representan sus caracteristias o propiedades y
métodos que representan su comportamiento o acciones que realizan. Todas las propiedades y
métodos comunes a los objetos se encapsulan o se agrupan en clases. Una clase es una plantilla o
un prototipo para crear objetos, por eso se dice que los objetos son instancias de clases.

Calidad

La calidad es la concordancia de los requisitos funcionales y las características implícitas que se

espera de todo sistema desarrollado profesionalmente.

Factores que determinan la Calidad:

 Fiabilidad
  Integridad (regularidad en los datos)
 Facilidad de Mantenimiento
 Flexibilidad
 Reutilizacion

La garantía de calida es una actividad de protección que se aplica en cada paso del proceso y
engloba:

 Métodos y herramientas de análisis: diseño, codificación y prueba.

 Revisiones formales a cada paso: son actividades que sirven como filtro, eliminando o
defectos que no son costosos de usar u corregir.
o Estrategia de prueba
o Control de la documentación y de los cambios realizados
o Mecanismos de medida (muestras)

PUD: Proceso Unificado de Desarrollo

¿Qué es un proceso? Se define a un proceso como un conjunto de pasos a realizar para cumplir un
objetivo. Nuestro objetivo es diseñar un software de calidad.

Es importante utilizar un proceso para desarrollar un Sistema de Información porque:

 Proporciona una guía para ordenar las actividades de un equipo.

 Dirigir las tareas de cada desarrollador por separado o del equipo como un todo.
 Especifica los artefactos que deben desarrollarse.
 Ofrece criterios para el control y la medición de los productos y actividades del proyecto.

Sabiendo que es un proceso, ¿Qué es el PUD? Es un marco de trabajo genérico que puede
especializarse para una gran variedad de sistemas software, para diferentes áreas de aplicación,
diferentes tipos de organizaciones, diferentes modelos de aptitud y diferentes tamaños.

Características del PUD

ESTÁ DIRIGIDO POR CASOS DE USOS: porque para construir un sistema con éxito debemos
conocer lo que sus futuros usuarios necesitan y desean. Los casos de uso no son solo una
herramienta para especificar los requisitos de un sistema sino que también guían el diseño,
implementación y prueba, es decir, que guían el proceso de desarrollo.

ESTA CENTRADO EN LA ARQUITECTURA: la arquitectura surge de la necesidad de la

empresa. Es una vista de diseño completo como las características más importantes resaltadas,
dejando de lado los detalles. El proceso sirve de ayuda para centrar los objetivos más adecuados,
como la compresibilidad, la capacidad de adaptación al cambio y la reutilización.

ES ITERATIVO E INCREMENTAL: significa que se le va entregando por parte, el sistema con

calidad al cliente.
El PUD se repite a lo largo de una serie de ciclos que constituyen la vida de un sistema y produce
una nueva versión del sistema, donde cada versión es un producto preparado para su entrega..
Cada ciclo consta de cuatro fases: inicio, elaboración, construcción y transición.

 INICIO: se desarrolla una descripción del producto final a partir de una buena idea y se
presenta el análisis de negocio para el producto. Esta fase responde a las siguientes
preguntas:
o ¿Cuáles son las principales funciones del sistema para sus usuarios más
importantes? (casos de usos)
o ¿Cómo podría ser la arquitectura del sistema?
o ¿Cuál es el plan de proyecto y cuanto costará desarrollar el producto?
 ELABORACION: se especifican en detalle la mayoría de los casos de uso del producto y se
diseña la arquitectura del sistema. La relación entre la arquitectura del sistema y el propio
sistema es primordial. La arquitectura se expresa en forma de vistas de todos los modelos
del sistema, los cuales juntos representan al sistema entero. Esto implica que hay vistas
arquitectónicas del modelo de casos de uso, del modelo de análisis, del modelo de
negocio, del modelo de implementación y el modelo de despliegue. Al final de la fase, el
director de proyecto está en disposición de planificar las actividades y estimar los recursos
necesarios para terminar el proyecto.
 CONSTRUCCION: se crea el producto, “se añaden los musculos (software) al esqueleto
(arquitectura)”. La línea base de la arquitectura crece hasta convertirse en el sistema
completo. Al final de la fase, el producto contiene todos los casos de uso que la dirección y
el cliente han acordado para el desarrollo de esta versión.
 TRANSICION: cubre el período durante el cual el producto se convierte en versión beta. Un
número reducido de usuarios con experiencia prueba el producto e informa de defectos y
deficiencias. También conlleva a actividades como la fabricación, formación del cliente,
proporcionar una línea de ayuda y asistencia.

Concepto de proceso:

 Flujo de trabajo: conjunto de actividades.

 Artefacto: lo que se va construyendo mediante el proceso de trabajo. Puede er desde un
modelo hasta una prueba.
 Trabajador: el que realiza los flujos de trabajo y manipula o construye los artefactos.

Flujos de trabajo

 FT de Requisitos --------- Modelo de C.U.

 FT de Analisis--------------Modelo de Analisis
 FT de Diseño---------------Modelo de Diseño / Modelo de Despliegue
 FT de Implementacion—Modelo de Implementacion
 FT de Prueba---------------Modelo de Prueba
UML: Lenguaje Unificado de Modelado.

Surgimiento

Los lenguajes de modelado orientados a objetos aparecieron a mediados de los ´70 y fines de los
´80. El número de métodos orientados a objetos ha incrementado mucho durante 1989 y 1994.

Una masa crítica de ideas comenzó a formarse en la primera mitad de los 90 cuando Bosch,
Jacobson y Rumbaugh empezaron a adoptar ideas de cada uno, los cuales habrían sido
reconocidos como los principales métodos orientados a objetos a nivel mundial.

Estos 3 autores comenzaron a unificar sus métodos en la búsqueda de crear un lenguaje de

modelado moderno que proporcionara cierta estabilidad al mercado orientado a objetos.

Así se presento UML en 1997.

Ahora bien, ¿Qué es UML?

Es un lenguaje cuyo vocabulario y reglas se centran en la representación conceptual y física de un

sistema.

Es un lenguaje estándar para escribir, modelar cualquier sistema de información. Es solo un

lenguaje y, por tanto, es tan sólo una parte de un método de desarrollo de software. UML es
independiente del proceso, aunque para utilizarlo óptimamente se debería usar en un proceso
que fuese dirigido por casos de uso, centrado en la arquitectura, iterativo e incremental.

¿Para qué se utiliza UML?

UML es un lenguaje para visualizar, especificar, construir y documentar los artefactos de un

sistema con gran cantidad de software. Esto se conoce como Visión General de UML.

UML ES UN LENGUAJE PARA VISUALIZAR

Para muchos programadores, la distancia entre pensar en una implementación y transformarla en

código es casi cero. Se piensa y se codifica. De hecho algunas cosas dse modelan mejor
directamente en código, si bien el programador realiza el modelo en forma mental. Incluso puede
bosquejar algunas ideas sobre una pizarra blanca o sobre una servilleta. Pero esto genera una
serie de problemas.

Primero, la comunicación de esos modelos conceptuales a otros está sujeta a errores a menos que
cualquier persona implicada hable el mismo lenguaje. Por ejemplo, las organizaciones usualmente
generan su propio lenguaje y es difícil comprender lo que esta sucediendo para alguien nuevo o
ajeno a la empresa.
Segundo, hay algunas cuestiones sobre un sistema software que no se pueden entender a menos
que se construyan modelos que trasciendan el lenguaje de programación textual. Por ejemplo, el
significado de una jerarquía de clases puede inferirse, pero no capturarse completamente,
inspeccionando el código de todas las clases en la jerarquía.

Tercero, si el desarrollador que escribió el código no dejo documentación escrita sobre los
modelos que había en su cabeza, esa información se perderá para siempre o será solo
parcialmente reproducible a partir de la implementación.

Soluciones: al escribir modelos en UML se afronta el tercer problema, un modelo explicito facilita
la comunicación.

En todos los sistemas interesantes hay estructuras que trascienden de lo que puede ser
representado en un lenguaje de programación. UML es uno de estos lenguajes gráficos. Así
afronta el segundo problema.

UML es algo más que un simple montón de símbolos gráficos. Detrás de cada símbolo en la
notación UML hay una semántica bien definida. De esta manera, un desarrollador puede escribir
un modelo en UML, y otro desarrollador puede interpretar ese modelo sin ambigüedad. Así se
afronta al primer problema.

UML ES UN LENGUAJE PARA ESPECIFICAR

Especificar significa construir modelos precisos, no ambiguos y completos. En particular, UML

cubre la especificación de todas las decisiones de análisis, diseño e implementación que deben
realizarse al desarrollar y desplegar un sistema con gran cantidad de software.

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. UML permite ingeniería directa, es
decir, la generación de código a partir de un modelo en un lenguaje de programación. Lo contrario
también es posible, pero la ingeniería inversa no es magia, a menos que se codifique esa
información en la implementación, la información se pierde cuando se pasa de los modelos al
código.

UML ES UN LENGUAJE PARA DOCUMENTAR

Una organización de software que trabaje bien produce toda clase de artefactos, además de
código ejecutable. Estos artefactos incluyen:

 Requisitos
 Arquitectura
 Diseño
 Código fuente
  Planificación de proyectos
 Pruebas
 Prototipos
 Versiones

Tales artefactos no son tan sólo los entregables de un proyecto, también son críticos para el
control, la medición y comunicación que requiere un sistema durante su desarrollo y después de
su despliegue. UML cubre la documentación de la arquitectura de un sistema y todos sus detalles.
También proporciona un lenguaje para expresar requisitos y pruebas y proporciona un lenguaje
para modelar las actividades de planificación de proyectos y gestión de versiones.

¿Dónde se puede utilizar UML?

Esta pensado principalmente para sistemas con gran cantidad de software. Ha sido utilizado de
forma efectiva en dominios como Sistemas de información empresariales, bancos y servicios
financieros, transporte, telecomunicaciones, comercio, etc.

¿Qué NO DICE UML?

UMl no dice como llevar a cabo el diseño de cada uno de los diagramas, no es una metodología
que nos dice paso a paso lo que debemos hacer para hacer frente a los requerimientos del
usuario, modelado del negocio. Simplementa es una herramienta de modelado.
Modelo Conceptual de UML
ELEMENTOS DE UML

 Estructural: son los nombres de los modelos UML. Son las partes estáticas de un modelo y
representan cosas que son conceptuales o materiales. Algunos de sus tipos son:
o Clases: es una descripción de un conjunto de objetos que comparten los mismos
atributos, operaciones, relaciones y semántica. Implementa una o mas interfaces
o Intefaz: es una colección de operaciones que especifican un servicio de una clase o
componente. Describe el comportamiento visible de una clase o componente o
solo una parte de ese comportamiento.
o Caso de Uso: es una descripción de un conjunto de secuencias y de acciones que
un sistema ejecuta y que produce un resultado observable, de interés para un
actor peculiar.

RELACIONES DE UML

 Dependencia: es una relación semántica entre dos elementos, en la cual un cambio a un

elemento puede afectar a la semántica de otro elemento. Se representa como una línea
punteada.
 Asociacion: es una relación esctructural que describe un conjunto de enlaces, los cuales
son conexiones entre objetos. Se representa con una línea continua sin flecha.
 Agregacion: representa una relación estructural entre un todo y sus partes.
 Generalización: es una relación de especialización en la cual los objetos del elemetno
especializado (el hijo) pueden sustituir a los objetos del elemento general (padre). El hijo
comparte la estructura y el comportamiento del padre. Se representa con una línea
contínua con flecha triangular en blanco.
 Realizacion: es una relación semántica entre clasificadores, en donde un clasificador
específica un contrato que otro clasificador garantiza que cumplirá. Se representa con una
línea punteada con flecha triangular en blanco

DIAGRAMAS DE UML

Representacion gráfica de un conjunto de elementos. Es una proyección de un sistema

 Diagramas de Estructura
o De clases: muestra un conjunto de clases, interfaces y colaboraciones, así como
sus relaciones. Abarcan la vista de diseño estática de un sistema
o De componentes: variante de los diagramas de clases, representa la encapsulación
de una clase. Cubren la vista de implementación estática del diseño de un sistema.
o De objetos: muestra un conjunto de objetos y sus relaciones. Los diagramas de
objetos representan
o De estructura compuesta
o De despliegue: muestra la configuración de nodos de procesamiento en tiempo de
ejecución y los artefactos que residen en ellos. Los diagramas de despliegue
 abordan la vista de de despliegue estática de una arquitectura. Un nodo alberga
uno o más paquetes.
o De paquetes: muestra la descomposición del propio modelo en unidades
organizativas y sus dependencias.
 Diagramas de Comportamiento
o De casos de uso: muestra un conjunto de casos de uso y actores y sus relaciones.
Cubren la vista de casos de uso estática de un sistema. Estos diagramas son
importantes en el modelado ya que organizan el comportamiento de un sistema.
o De maquina de estado: muestra una máquina de estados, que consta de estados,
transiciones, eventos y actividades. Muestra la vista dinámica de un objeto. Son
importantes en el modelado del comportamiento de una interfaz, clase o
colaboración y resalta el comportamiento dirigido por eventos.
o De actividad: muestra la estructura de un proceso u otra computación como el
flujo de control y datos paso a paso en la computación. Cubren la vista dinámica
de un sistema.
o De interaccion: muestra una interaccion, que consta de un conjunto de objetos o
roles, incluyendo los mensajes que pueden ser enviados entre ellos. Cubren la
vista dinámica de un sistema.
o De secuencias: es un diagrama de interaccion que resalta la ordenación temporal
de los mensajes. Resaltan la ordenación temporal.
o De comunicación: es un diagrama de interaccion que resalta la organización
estructural de los objetos o roles que envían y reciben mensajes. Resaltan la
estructura de datos a través de la cual fluyen los mensajes.
o De tiempos: muestra los tiempos reales en los que se intercambian los mensajes.
o DE VISION GLOBAL DE INTERACCIONES: es un híbrido entre un diagrama de
actividades y un diagrama de secuencia.

REGLAS DE UML

Los bloques de construcción de UML no pueden combinarse simplemente de cualquier manera.

Como cualquier lenguaje, UML tiene reglas que especifican a qué debe parecerse un modelo bien
formado. Un “modelo bien formado” es aquel que es semánticamente autoconsistente y está en
armonía con todos sus modelos relacionados.

UML tiene reglas sintácticas y semánticas para:

 Nombres: como llamar a los elementos, relaciones y diagramas.

 Alcance: el contexto que da un significado específico a un nombre.
 Visibilidad: cómo se pueden ver y utilizar esos nombres por otros.
 Integridad: cómo se relacionan apropiada y consistentemente unos elementos con otros.
 Ejecución: qué significa ejecutar o simular un modelo dinámico.
Los modelos construidos durante el desarrollo de un sistema con gran cantidad de software
tienden a evolucionar y pueden ser vistos por muchos usuarios de formas diferentes. Por esta
razón, es habitual que el equipo de desarrollo no sólo construya modelos bien formados, sino
también modelos que sean:

 Abreviados: ciertos elementos se ocultan para simplificar la vista.

 Incompletos: pueden estar ausentes ciertos elementos.
 Inconsistentes: no se garantiza la integridad del modelo.

Estos modelos que no llegan a ser bien formados son inevitables onforme los detalles de un
sistema van apareciendo y mezclándose durante el proceso de desarrollo de software. Las reglas
de UML estimulan a considerar las cuestiones más importantes de análisis, diseño e
implementación que llevan a tales sistemas a convertirse en bien formados con el paso del
tiempo.

MECANISMOS COMUNES EN UML

Una casa puede construirse, en su mayor parte, de estilo victoriano o francés utilizando ciertos
patrones arquitectónicos que definen esos estilos. Lo mismo es cierto para UML. Éste se simplifica
mediante la presencia de cuatro mecanismos comunes:

 Especificaciones: la notación grafica de un sistema se utiliza para visualizar un sistema; la

especificación de UML se utiliza para expresar los detalles del sistema. Se puede dibujara
primero diagramas y después añadir semántica a las especificaciones del modelo, o bien
mediante la creación de una especificación hacer ingeniería inversa. Las especificaciones
proporcionan una base semántica que incluye a todas las partes de todos los modelos de
un sistema, y cada parte esta relacionada con las otras de manera consistente.
 Adornos: la especificación de una clase puede incluir otros detalles, tales como si es
abstracta o la visibilidad de sus atributos y operaciones. Muchos de estos detalles se
pueden incluir como adornos gráficos o tetuales en la notación rectangular básica de la
clase. Por ejemplo en una clase:

 Divisiones comunes: al modelar sistemas oritentados a objetos, el mundo a menudo se

divide de varias formas. En primer lugar, esta la división entre clase y objeto. Una clase es
una abstracción, un objeto es una manifestación concreta de esa abstracción.
 En segundo lugar, la separación entre interfaz e implementación. Una interfaz declara un
contrato, y una implementación representa una realización concreta de ese contrato,
responsable de hacer efectiva la semántica completa de la interfaz de forma fidedigna.

En tercer lugar, está la separación entre tipo y rol. El tipo declara la clase de una entidad,
como un objeto, un atributo o un parámetro. Un rol describe el significado de una entidad
en un contexto, como una clase, un componente o una colaboración.

 Mecanismos de extensibilidad: UML proporciona un lenguaje estándar para escribir

planos software, pero no es posible que un lenguaje cerrado sea siempre suficiente
para expresar todos los modelados de dominio. Por esta razón, UML es abierto-
cerrado, siendo posible extender el lenguaje. Los mecanismos de extensión son:
o Estereotipos: extiende el vocabulario de UML, permitiendo crear nuevos tipos
de bloques de construcción que derivan de los existentes pero que son
específicos a un problema.
o Valores etiquetados extiende las propiedades de un estereotipo de UML,
permitiendo añadir nueva información en la especificación de ese estereotipo.
o Restricciones extiende la semántica de un bloque de construcción de UML,
permitiendo añadir nuevas reglas o modificar las existentes.

ARQUITECTURA

Se define la arquitectura de un sistema como “la estructura organizacional de un sistema, incluida

su descomposicipon en partes, su conectividad, interaccion, mecanismos y los principios
directores que informan al diseño de un sistema”. Los aspectos esenciales de la arquitectura se
capturan en cuatro vistas diferentes del sistema: la vista lógica, de proceso, de implementación y
la vista de despliegue. Todas éstas están integradas por una quinta vista, la vista de caso de uso.

 Vista lógica: captura el vocabulario del ámbito del problema como un conjunto de
clases y objetos. El énfasis está en mostrar como los objetos y las clases que
componen un sistema implementan el comportamiento requerido del sistema.
 Vista de proceso: modela los procesos en un sistema como clases activas. Es una
variación orientada al proceso de la vista lógica y contiene los mismos artefactos.
  Vista de implementación: modela los archivos y componentes que conforman la base
de código físico del sistema. También trata sobre ilustrar dependencias entre
componentes y sobre la gestión de la configuración de conjuntos de componentes
para definir una versión del sistema.
 Vista de despliegue: modela el despliegue físico de artefactos en un conjunto de
nodos físicos computacionales como ordenadores y periféricos. Le permite modelar la
distribución de artefactos en los nodos de un sistema distribuido.
 Vista de caso de uso: captura los requisitos básicos para el sistema como un conjunto
de casos de uso. Estos casos de uso proporcionan la base para la construcción de otras
vistas.

¿Qué es un Caso de Uso?

Un caso de uso se utiliza como un artefacto básico para establecer el comportamiento deseado del
sistema, para verificar y validar la arquitectura del sistema, para las pruebas y la comunicación
entre las personas involucradas en el proyecto. El actor es el usuario del sistema.
 Unidad 4: Paradigma Orientado a Objetos

Introduccion

La tecnología orientada a objetos se apoya en los sólidos fundamentos de la ingeniería, cuyos

elementos reciben el nombre global de modelo de objetos. Este modelo abarca los principios de
abstracción, encapsulación, modularidad, jerarquía. El modelo de objetos ha demostrado ser un
concepto unificador en la informática, aplicable no sólo a los lenguajes de programación, sino
también al diseño de interfaces de usuario, bases de datos e incluso arquitecturas de
computadoras.

¿Qué es entonces la programación orientada a objetos (POO)? Es un método de implementación

en el que los programas se organizan como colecciones cooperativas de objetos, cada uno de los
cuales representa una instancia de alguna clase, y cuyas clases son miembro de una jerarquía de
clases unidas mediante relaciones de herencia.

¿Qué es el diseño orientado a objetos (DOO)? El diseño es un método de diseño que abarca el
proceso de descomposición orientada a objetos y una notación para describir los modelos lógico y
físico, y así como los modelos estático y dinámico del sistema que se diseña.

¿Qué es el análisis orientado a objetos (AOO)? Es un método de análisis que examina los requisitos
desde la perspectiva de las clases y objetos que se encuentran en el vocabulario del dominio del
problema.

Existen varios tipos de software que un analista puede desarrollar. Estos son Simples y Complejos

 Simples: son aplicaciones especificadas, construidas y mantenidas por una persona. Tales
sistemas tienen un propósito limitado y un ciclo de vida corto. Cuando el sistema no se
ajusta a las necesidades del cliente se descarta y se crea otro.
 Complejos: son aplicaciones que exhiben un conjunto de comportamiento, tienen ciclo de
vida largo, son sumamente difíciles sino imposibles de desarrollar por una persona. La
complejidad es la propiedad esencial de todos los sistemas de gran tamaño. Tienden a
evolucionar con el tiempo. Un sistema grande significa una inversión considerable por lo
que no es aceptable desechar un sistema cada vez que los requerimientos cambian.

Dificultades que se presentan al desarrollar software

 Planificacion y estimación de costos frecuentemente muy imprecisos.

 Software que no corresponde con lo pedido.
 Calidad del software que no llega a veces a ser aceptable.
Estos problemas se producen por el carácter propio del software (A) y por los errores de
las personas encargadas del desarrollo (B)
 Carácter del Software: (A)
a. complejidad del dominio (es decir puede haber requerimientos
contradictorios, se debe definir bien los requerimientos)
 b. Dificultades para gestionar el proceso de desarrollo (debido a una mala
comunicación y coordinación entre el equipo que desarrolla el sistema)
 Errores de Personas : (B)
a. No poseen el conocimiento de nuevas técnicas de desarrollo.
b. Resistencia al cambio.

Se necesita Complejidad, Rapidez de desarrollo, Flexibilidad, Confiabilidad, Facilidad de

modificación.

¿Qué es la Descomposicion? ¿Cual es su Rol?

Asdfasdf********

(Rol) Cuando se diseñan sistemas complejos hay que descomponerlos en partes y existen dos
formas de hacerlo:

1. Descomposicion Algoritmica: se centra en los procesos donde cada modulo es un proceso

importante de algún proceso global; el sistema se divide en elementos funcionales
relacionados estructuralmente entre sí.
2. Descomposicion Orientada a Objetos: determina un conjunto de objetos que colaboran
para llevar a cabo algún comportamiento. Se centra en las cosas.

Caracteristicas de las técnicas Orientadas a Objetos

 Cambia nuestra forma de pensar.

 El sistema se construye a partir de objetos existentes.
 La complejidad sigue en aumento.
 Ayuda a aprovechar al máximo a los lenguajes basados y orientados a objetos.

Clase y Objeto

Objeto: cosa tangible y/o visible, algo que puede comprenderse intelectualmente, algo hacia lo
que se dirige un pensamiento o acción. Entidad o elemento individual, ya sea real o abstractos,
juega un rol en el dominio del problema, posee atributos, operaciones.

Propiedades de los objetos

 Estado: son todas las propiedades de un objeto más los valores actuales de cada una de
esas propiedades.
 Comportamiento: es cómo actúa y reacciona un objeto frente a cambios de estado y paso
de mensajes.
 Identidad: es aquella propiedad de un objeto que los distingue de todos los demás
objetos.

Relaciones entre objetos

  Enlace: conexión física o conceptual entre instancias de objetos por lo cual un objeto
utiliza los servicios de otros, esto se ve en el diagrama de colaboración o comunicación.
 Agregacion:

Clase: es una descripción o abstracción de un conjunto de objetos que comparten los mismos
atributos, operaciones, relaciones y semántica.

Vistas de una clase

 Externa: es la interfaz. Oculta su estructura y secretos de su comportamiento.

 Interna: es la implementación. Engloba los secretos de su comportamiento.

Las clases se representan con un rectángulo separado por tres partes:

 Nombre: representa el nombre con el cual se denota la clase. Se define el nombre de

forma mayúscula la primer letra, seguido por letras minúsculas. En caso de haber más de
una palabra para denotar el nombre, se separaran con letras mayúsculas en la primer letra
de cada palabra.
 Atributos: es donde se definen los atributos que poseera la clase. Se define el nombre de
cada atributo comenzando con letra minúscula, en caso de haber más de una palabra, se
separaran con letras mayúsculas.
 Operaciones: métodos, responsabilidades de las clases, son las que le darán funcionalidad
a la clase y permitirán el paso de mensajes de una clase a otra.

Relaciones entre clases

 Agregacion: representa una relación del tipo “tiene un” o “parte de”, un objeto del todo
tiene objetos de la parte.

 Generalizacion: relación entre un elemento general (Padre) y un caso más especifico de

ese elemtento (Hijo). Representa una relación del tipo “es un tipo de”.

 Asociacion: relación estructural que especifica que los objetos de un elemento están
conectados con los objetos de otro.
  Dependencia: un elemento utiliza la información y servicios de otro.

ELEMENTOS FUNDAMENTALES DEL MODELO DE OBJETOS

 Abstraccion: denota las características esenciales de un objeto que lo distingue de todos

los demás tipos de objetos y proporciona así fronteras conceptuales definidas respecto a
la perspectiva del observador.
 Encapsulamiento: es el proceso de almacenar en un mismo compartimiento los elementos
de una abstracción que constituyen su estructura y su comportamiento.
 Modularidad: es la propiedad que tiene un sistema que ha sido descompuesto en un
conjunto de modulos cohesivos y débilmente acoplados. Consiste en dividir un programa
en módulos que pueden compilarse separadamente. Un módulo es un contenedor físico
de clases y objetos.
 Jerarquia: es una clasificación u ordenación de abstracciones. La jerarquía de clases y
jerarquiea de partes son las jerarquías más importantes en un sistema complejo. Los tipos
de jerarquía son:
o Herencia simple: es una relación en donde una subclase comparte la estructura de
comportamiento con una clase.
o Herencia multiple: es una relación en donde una subclase comparte la estructura
de comportamiento con más de una clase.
o Agregación: es un tipo de relación parte de y permite el agrupamiento físico de
estructuras relacionadas lógicamente.

Conceptos

Operación: denota un servicio que una clase ofrece a sus clientes. Es una abstracción de algo que
se puede hacer a un objeto y que es compartido por todos los objetos de la clase. Es una acción
que un ojeto efectua sobre otro con el fin de provocar una reacción. Los tres tipos más comunes
de operaciones son los siguientes:

 Modificador: una operación que altera el estado de un objeto.

 Selector: una operación que accede al estado de un objeto, pero no altera ese estado.
  Iterador: una operación que permite acceder a todas las partes de un objeto en algún
orden perfectamente establecido.

Responsabilidad: contrato o obligación de una clase. Al crear una clase, se expresa que todos los
objetos de esa clase tienen el mismo tipo de estado y el mismo… Incluye el conocimiento que un
objeto mantiene y las acciones que puede llevar a cabo, es decir es una descripción de lo que sus
atributos y/o operaciones realizan en conjunto.

La diferencia entre los anteriores conceptos está en que las operaciones son las características por
medio de las cuales se llevan a cabo las responsabilidades; mientras que la responsabilidad es un
contrato o una obligación de una clase.

Metodo: secuencia lógica de actividades que realiza una clase para mostrar un comportamiento.
Es una implementación de una operación.

Colaboracion: representa una solicitud de un cliente a un servidor para cumplir una

responsabilidad del cliente. Se dice que el objeto B colabora con el objeto A cuando A, para
cumplir con su responsabilidad, necesita enviar algún mensaje a B solicitándole un servicio.

Polimorfismo: “cualidad de tener más de una forma”. Una operación adopta varias formas de
implementación.

Multiplicidad: cuantos objetos de A se relacionan con cuantos objetos de B.

Navegabilidad: nos muestra que es posible pasar desde un objeto de la clase fuente a uno o más
objetos de la clase destino, dependiendo de la multiplicidad. Se puede pensar como “mensajes
que solamente se pueden enviar en la dirección de la flecha”.
 Unidad 5: Ingenieria de Requerimientos

Introduccion

¿Qué es un requerimiento? Es una cualidad que debe estar incluido en el nuevo sistema de
información permitiéndole al cliente alcanzar un objetivo o resolver un problema. Una cosa es lo
que el cliente necesita, otra lo que cree necesitar y otra lo que le transmitió al profesional.

¿Qué sucede cuando se capturan mal los requerimientos?

 Software que no satisface a los usuarios.

 Costo y tiempo en Sistema de Informacion erróneos.
 Mantenimiento costoso.
 Interpretacion múltiple de requerimientos

Tipos de requerimientos

 Requerimientos Funcionales: son declaraciones de los servicios que proveerá el sistema,

de la manera en que éste reaccionará entradas particulares y de cómo se comportará en
situaciones particulares.
 Requerimientos no funcionales: son aquellos que no se refieren directamente a las
funciones específicas que entrega el sistema, sino a las propiedades emergentes de éste
como la fiabilidad, la respuesta en el tiempo y la capacidad de almacenamiento. Son
restricciones de los servicios o funciones ofrecidas por el sistema.
 Requerimientos del dominio: provienen del dominio de aplicación del sistema y reflejan
las características. Son requerimientos que surgen del lugar donde se va a instalar el
sistema.
 Requerimientos duraderos: estos son relativamente estables (que no cambian con el
tiempo), se derivan de la actividad principal de la organización. Están relacionados
directamente con el dominio del sistema.
 Requerimientos volátiles: estos combinarán probablemente durante el desarrollo del
sistema o después de que éste se haya puesto en marcha. Pueden ser:
o Emergentes:
o Mutantes:
o Consecutivos:
o De compatibilidad:

Niveles de Descripcion de Requerimientos:

 Del usuario o definición de requerimientos: son declaraciones, en lenguaje natural y en

diagrama, de los servicios y restricciones bajo las cuales debe operar.
  Del sistema o especificación de requerimientos: establece con detalles los servicios y
restricciones del sistema. Sirve como un contrato entre el comprador y el desarrollador.

¿Cuáles son los propósitos de los requerimientos?

 Qué los desarrolladores expliquen cómo han entendido lo que el cliente pretende del
sistema.
 Indican al equipo de prueba que demostraciones llevar a cabo para convencer al cliente
que el sistema que se entrega es el solicitado. Con este fin debe comprobarse que los
requerimientos posean las características que se desprenden de las siguientes preguntas:
o ¿Son correctos?: deben estar revisados tanto por el cliente como por el
desarrollador para asegurarse que no tienen errores.
o ¿Son consistentes?: que no tengan definiciones contradictorias o ambigüas.
o ¿Son completos?: todos los servicios solicitados por el cliente están definidos.
o ¿Son realistas?: significa que el sistema puede llevar a cabo lo que el cliente pidió.
o ¿Son verificables?: deben ser consistentes, completos y realistas.
o ¿Son rastreables?: se puede ir desde cada función hasta el conjunto de
requerimientos que la establece.

Categorias de Requerimientos

 Requerimientos que deben ser absolutamente satisfechos.

 Requerimientos que son muy deseables pero no indispensables.
 Requerimientos que son posibles pero que podrían eliminarse

¿Qué es la Ingeniería de Requerimientos?

Es un proceso que comprende todas las actividades requeridas para crear y mantener un
documento de requerimientos del sistema.

Proceso de Ingenieria de Requerimientos

1. Estudio de Factibilidad: un estudio de factibilidad es un estudio corto y orientado a

resolver varias preguntas:
a. ¿El sistema contribuye a los objetivos generales de la organizacion?
b. ¿El sistema se puede implementar utilizando la tecnología actual y con las
restricciones de costo y tiempo?
c. ¿El sistema puede integrarse a otros que existen en la organización?

Aquí la cuestión critica es si el sistema contribuye a los objetivos del negocio. Si no

contribuye a estos objetivos, entonces no tiene un valor real en el negocio.

La fase de evaluación de la información identifica la información requerida para contestar

las tres preguntas anteriores. Una vez que dicha información se ha identificado, se
 cuestionan las fuentes de información para descubrir las respuestas a estas preguntas.
Algunos ejemplos de preguntas son:

 ¿Cómo se las arreglaría la organización si no se lleva a cabo este sistema?

 ¿Cuáles son los problemas con los procesos actuales y como ayudaría el nuevo
sistema a resolverlos?
 ¿A qué debe ayudar el sistema y a qué no necesita ayudar?
2. Obtención y Análisis de Requerimientos: el personal del desarrollo técnico del software
trabajara con los clientes y los usuarios finales del sistema para determinar el dominio a la
aplicación, cuales servicios debe proveer el sistema, el desempeño requerido del sistema,
las restricciones de hardware, etc.
La obtención y análisis es un proceso difícil por varias razones:
 Los stakeholders a menudo no conocen realmente lo que desean obtener del
sistema de computo excepto en términos muy generales.
 Expresan los requerimientos con sus propios términos de forma natural y con un
conocimiento implícito de su propio trabajo.
 Tienen requerimientos distintos y podrían expresarlos de varias formas.
 El entorno económio y de negocios en el que se lleva a cabo el análisis es
dinámico.
Las actividades del proceso son:
 Compresión del dominio.
 Recolección de requerimientos.
 Clasificación.
 Resolución de conflictos.
 Priorización.
 Verificación de requerimientos.
3.

Niveles de Especificacion de Requerimientos

  Requerimientos del usuario: son declaraciones, en lenguaje natural y en diagramas, de los
servicios que se espera que el sistema provea y de las restricciones bajo las cuales debe
operar.
 Requerimientos del sistema: establecen con detalle los servicios y restricciones del
sistema. El documento de requerimientos del sistema, algunas veces denominado
especificación funcional, debe ser preciso. Éste sirve como un contrato entre el comprador
del sistema y el desarrollador de software.
 Especificación del diseño del software: es una descripción abstracta del diseño del
software que es una base para un diseño e implementación detallados. Esta especificación
agrega detalle a la especificación de requerimientos del sistema.

Diferentes niveles de especifiacion del sistema son de utilidad debido a que comunican la
información del sistema a los diferentes tipos de lectores. Los requerimientos del usuario se
redactan para el cliente y los contratistas administradores quienes no tienen un conocimiento
técnico detallado del sistema. La especificación de requerimientos del sistema se orienta al
personal técnico y a los administradores del proyecto. Los usuarios finales pueden leer ambos
documentos. La especificación del diseño del software es un documento orientado a la
implementación, debe redactarse para los ingenieros de software que desarrollarán el sistema.
 Unidad 7: Proceso de Especificaciones de Requerimientos

Introduccion

¿Qué es una especificación de requerimientos?

Consiste en documentar los requerimientos, teniendo en cuenta los niveles de los mismos (del
usuario y sistema). La especifiacion de requerimientos se define de dos maneras:

 Especificacion: es un documento que define de forma completa los requisitos, el

diseño, el comportamiento u otras características de un sistema o componente de
un sistema, éste documento se denomina Documento de Especificacion de
Requerimientos.
 Software: es el conjunto de programas, procedimientos y documentación asociada
a la operación de un sistema informático.
¿Para qué sirve? Sirve para contrarrestar las ambigüedades en la especificación en
lenguaje natural.
¿Cuándo se hace? Se realiza en la etapa de análisis de desarrollo del sistema.

¿Qué es entonces el Documento de Especificacion de Requerimientos?

Es el resultado de los requisitos esenciales del software y de sus interfaces externas. Para que sea
eficaz debe tener 2 características fundamentales:

 Debe influir información cierta, coherentes con las necesidades del usuario que se desean
satisfacer.
 Debe comunicar dicha información de forma eficaz para que se pueda comprender
perfectamente.

¿Cuáles son las características que debe tener un documento de Especificacion de

Requerimientos?

 No ambigüa: cada requisito descripto tiene una única interpretación.

 Completa: un ERS está completa si:
o Incluye requisitos significativos del software, ya sean relativos a la funcionalidad,
ejecución, etc.
o Define la respuesta del software a todas las posibles clases de datos de entrada y
las posibles situaciones.
o Están etiquetadas y referenciadas en el texto las figuras, tablas y diagramas.
Deben estar definidos los términos y unidades de medida.
 Fácil de verificar: existe algún procedimiento que compruebe que el software satisface los
requisitos.
 Consistente: ningún conjunto de los requisitos descriptos en ella son contradictorios.
 Clasificada por importancia: los requisitos deben tener establecidos un orden de prioridad
basado en su importancia para la aplicación.
  Fácil de modificar: para que se logre esto, el documento de Especificación de
Requerimientos debe:
o Tener una organización coherente y manejable, con una tabla de contenidos, un
índice y referencias cruzadas.
o No ser redundante, es decir, que el mismo requisito no aparezca en más de un
lugar del documento de Especificación de Requerimientos.
 Fácil de identificar el origen y las consecuencias: se establece un origen claro para cada
uno de los requisitos y se posibilita la referencia de estos en desarrollos futuros o
incrementos de la documentación.
 Fácil de utilizar.

Estructura del Documento de Especificación de Requerimientos.

Se divide en tres partes:

 Introducción: encontraremos la definición del objetivo, referencias y una visión global.

 Descripción General: las perspectivas y funciones del producto junto con las limitaciones
generales.
 Requisitos específicos: se enumeran todos los requisitos (funcionales, de interfaz, de
ejecución, etc)

¿Cómo evoluciona el documento de Especificación de Requerimientos?

El documento de Especificación de Requerimientos necesitará ser combinada a medida que

progresa el producto de software. Es decir, necesitará ser cambiada por cada cambio que ocurre.
Se debe tener en cuenta:

 El requisito debe ser especificado de la forma más completa posible para que sirva
de base en el diseño posterior.
 Debe iniciarse un proceso formal de cambio para identificar, controlar, seguir e
informar de cambios proyectados. Los cambios aprobados deben ser indicados en
el Documento de Especificación de Requerimientos.

Modelo de CU

El modelo de CU describe el comportamiento completo del sistema. Está formado por el caso de
uso, relaciones y paquetes.

¿Qué es un caso de uso de un Sistema de Información? ¿Qué es un escenario?

 Caso de uso: es la descripción de un conjunto de acciones que ejecuta un sistema para

producir un resultado de valor para un actor. Un caso de uso describe que hace un sistema
pero no como lo hace.
 Escenario; es una secuencia específica de acciones que ilustra un comportamiento. Es una
instancia de un caso de uso.
Un caso de uso está formado por:

 Actores: es quién demanda algo del sistema o está interesado en sus salidas. Es quién
interactúa directamente con el sistema.
o Caracteristicas:
 Cada actor humano expresa un rol.
 Cada actor está involucrado con, al menos, un caso de uso.
 Cada actor tiene un nombre y una descripción.
 Los actores pueden ser principales (demandan algo que responderá el
proceso) y secundarios (colaboran en alguna parte del proceso).
 Casos de Uso: existen 2 categorías de Casos de Uso. Los más importantes que se
denominan “esenciales” y los menos importantes que se llaman “de soporte”. Cada CU
esencial deberá tener una relación de comunicación de o hacia un actor porque el sistema
debe construirse alrededor de los servicios que sus usuarios requieren.
 Relaciones: no se utilizan para modelar las salidas sino inicios del proceso. Existen 3 tipos
de relaciones:
o Extension: si hay parte del CU que es opcional se la puede extender en un CU
adicional para simplificar la estructura del CU.
o Inclusión: si hay parte del CU que representa una función de la cual solo depende
del resultado, se la puede factorizar en un CU adicional.
o Generalizacion; si hay un CU que tiene comportamiento y estructura similar y
similitud de propósito, se puede factorizar a un CU (padre) que es heredado por
los CU (hijos).

¿Qué significa estructurar el modelo de CU?

Se estructura el modelo para que sea más fácil de entender, de mantener, para poder reutilizar
parte del flujo de trabajo y para trabajar con él.

El modelo de casos de uso se estructura para:

 Extraer descripciones de funcionalidad (de casos de uso) generales y compartidas que

pueden ser utilizadas por descripciones (de casos de uso) más específicas.
 Extraer descripciones de funcionalidad adicionales u opcionales que pueden extender
descripciones más específicas.

¿Qué significa Ingeniería Directa e Ingeniería Inversa?

 Ingeniería Directa: es el proceso de transformar un modelo en código a través de una

correspondencia con un lenguaje de implementación. A un diagrama de CU se le puede
aplicar ingeniería directa para generar pruebas del elemento al que se aplica.
 Ingeniería Inversa: es el proceso de transformar código en un modelo a través de una
correspondencia a partir de un lenguaje de implementación específico. Conseguir un
diagrama de CU a través de ingeniería inversa es impensable con la tecnología actual
 porque hay una pérdida de información al pasar de la especificación de cómo se debe
comportar un elemento al cómo se implementa.

¿Cuáles son las perspectivas que se modelan de un Sistema de Informacion? ¿Qué métodos se
utilizan?

Perspectivas:

 Externa: se modela el contexto o el entorno del sistema.

 De comportamiento: se modela el comportamiento del sistema.
 Estructural: se modela la arquitectura del sistema o la estructura de los datos procesados.
 Unidad 8: Proceso de Validación de Requerimientos

Introducción

¿Qué es la validación de Requerimientos? ¿Por qué es importante?

Es una verficación que define el sistema que el cliente desea. Implica encontrar problemas con los
requerimientos. Es importante porque los errores en el documento de requerimientos conducen a
costos excesivos al repetir el trabajo.

Tipos de Verificaciones que se llevan a cabo:

 De validez: son aquellas donde un usuario cree necesitar un sistema para llevar a cabo
ciertas funciones, pero en realidad también se necesitan funciones adicionales y
diferentes.
 De consistencia: los requerimientos en el documento no deben contradecirse.
 De integridad: el documento debe incluir todas las funciones y restricciones propuestas
por el usuario.
 De realismo: utilizando el conocimiento de la tecnología existente, los requerimientos
deben verificarse para asegurar que se puedan implementar.
 De verificabilidad: deben redactarse de manera que permitan diseñar pruebas para
demostrar que el requerimiento cumple con lo documentado.

Tecnicas de Validacion de Requerimientos

 Revisiones: los requerimientos son analizados por un grupo de revisores para ver si se
necesita modificar algún requerimiento y ver qué se debe hacer.
 Construcción de prototipos: se muestra un modelo ejecutable del sistema a los usuarios
finales y a los clientes para ver si el sistema cumple con las necesidades reales.
 Generación de casos de prueba: se ponen a prueba los requerimientos a partir de
situaciones reales.
 Análisis de Consistencia: los requerimientos son procesados para generar informes, se
utilizan las herramientas CASE.

Hablando de prototipos, ¿Qué es un prototipo? Es una versión inicial del sistema que se utiliza
para demostrar los conceptos, probar opciones de diseño y así enterarse más acerca del problema
y sus posibles soluciones.

¿Qué utilidad tienen los prototipos?

 Encontrar requerimientos
 Validar requerimientos
 Capacitar a los usuarios
  Poder probar el sistema

¿Cuáles son las ventajas de trabajar con prototipos?

Ventajas:

 Mejora la usabilidad.
 Mejora el acoplamiento entre el sistema y las necesidades del usuario.
 Mejora la calidad del Diseño
 Mejora el mantenimiento.
 Reduce el esfuerzo en el desarrollo.

Tipos de Prototipos

 Evolutivos: inicia con un sistema simple que implementa los requerimientos más
importantes, dicho prototipo aumenta o cambia en cuanto se descubren nuevos
requerimientos. Finalmente se convierte en el sistema requerido.
No existe una especificación detalla de éste y en muchos casos no existe un documento
formal de requerimientos.
El objetivo es entregar un sistema funcional, por eso se dejan de lado los requerimientos
de prioridad baja hasta cuando lo requieran los usuarios, y además se deben desarrollar
con estándares de calidad.
 Desechables: ayudan a refinar y clasificar la especificación del sistema. El prototipo se
escribe, evalúa y modifica.
la evaluación informa del desarrollo de la especificación detallada del sistema que se
incluye en el documento de requerimientos.
una vez redactada la especificación, el prototipo ya no es útil y se desecha. El objetivo es
validar o derivar los requerimientos del sistema y se hace con aquellos requerimientos que
no se comprenden bien.

Problemas que pueden aparecer al construir prototipos

 Problemas al construir prototipos evolutivos

o Problemas de administración: como los prototipos evolucionan tan rápido no es
costeable producir una gran cantidad de documentación del sistema. Además, el
desarrollo rápido de prototipos requiere el uso de tecnologías no tan familiares y
por lo tanto el personal carece de las habilidades requeridas.
o Problemas de mantenimiento: los cambios continuos tienden a romper la
estructura del sistema prototipo. Es difícil encontrar personas que tengan el
conocimiento requerido para dar mantenimiento al sistema.
o Problemas contractuales: cuando no existe una especificación del sistema es difícil
diseñar un contrato para el desarrollo del sistema. Allí se producen problemas
entre el cliente y el desarrollador por los precios.
 Problemas al construir prototipos desechables
 o Las características importantes se excluyen del prototipo para simplificar la
implementación rápida.
o Una implementación no tiene valor legal para el contrato entre el cliente y el
contratista.
o En una implementación del prototipo, no se pueden probar de manera adecuada
los requerimientos no funcionales como los de fiabilidad, robustez y seguridad.

¿Qué se debe tener en cuenta a la hora de diseñar una interfaz de usuario?

A la hora de diseñar una interfaz de usuario se debe tener en cuenta la edad y conocimiento de la
persona que va a manejar el sistema.

Criterios para el diseño de una buena interfaz

 Control de usuario: que el usuario tenga la posibilidad de moverse de ventana a ventana.

 Sensibilidad: si la aplicación esta procesando durante mucho tiempo, colocar una escala
deslizante para indicar el porcentaje de trabajo que se ha realizado.
 Personalización: dejar la posibilidad de que los usuarios modifiquen cosas.
 Consistencia: usar formatos, abreviaturas estándares y éstandares para el aspecto y
sensación.
 Estética: uso cuidadoso de líneas, marcos, espacios, etc.
 Indulgencia: perdonar errores de los usuarios.
 Unidad 9: Flujo de Trabajo de Requisitos

¿Cuál es el propósito del flujo de trabajo de requisitos?

El propósito del FTR es guiar el desarrollo hacia el sistema correcto. Esto se consigue mediante la
descripción de los requisitos del sistema.

¿Cómo se descubren los requisitos?

 Enumerar requisitos candidatos: lista de posibles requerimientos.

 Comprender el contexto: modelo de dominio y modelado de negocio.
 Identificar requerimientos funcionales
 Identificar requerimientos no funcionales.

¿Qué es el modelo de dominio? El modelo de dominio describe los conceptos más importantes del
contexto.

¿Cómo se describe el FTR? Se describe con Artefactos, Trabajadores y Actividades.

 Artefactos:
o Modelo de CU
o Descripcion de Arquitectura: es una vista del modelo de CU. Esta vista debería
incluir CU que describan alguna funcionalidad importante o que posea algún
requisito importante que deba ser desarrollado pronto.
o Glosario: se utiliza para definir términos comunes importantes que utilizan los
analistas para describir el sistema.
o Prototipo de interfaz de usuario: nos ayuda a comprender cómo se va a comunicar
el usuario con el sistema.
 Trabajadores:
o Analista de sistemas: es el responsable de la obtención de los requerimientos. Es
el responsable de todo el modelo de CU.
o Especificador de CU: es el responsable de detallar cada uno de los CU.
o Diseñador de interfaz de usuario: es el responsable de dar forma visual a la
interfaz de usuario.
o Arquitecto: es quién le da la prioridad a los CU. Es quién describe la vista de la
arquitectura del modelo de CU.
 Actividades:
o Identificar actores y CU.
o Describir CU (plantillas): se describe el detalle de los CU a través de las plantillas.
o Estructurar CU (relaciones): establecer relaciones entre los CU. Si alguna relación
me va a complicar el modelo no se utiliza. Se estructura el modelo de CU para que
sea más fácil de entender, mantener y reutilizar flujos de trabajo.
o Priorizar los CU: determinar qué CU son más importantes, es decir, darles un
orden. Los primeros que se van a modelar son los que tienen un valor crítico.
¿Qué son los patrones?

Los patrones realizan una descripción de un problema que ocurre y de cómo solucionarlo. Son
estereotipos que se utilizan una y otra vez para solucionar problemas parecidos. Se pueden utilizar
muchas veces y además perfeccionarlos.
 Unidad 10: Flujo de Trabajo de Análisis

¿Cuál es el propósito del Flujo de Trabajo de Analisis?

Se analizan los requisitos capturados con el objetivo de conseguir una compresión más precisa y
una descripción de los mismos que sea fácil de mantener y nos ayude a estructurar el sistema
entero. Se centra en lo que el sistema necesita hacer, pero deja de lado los detalles de cómo lo
hará.

¿Cuáles son las características del modelo de análisis?

 Descripto con el lenguaje del desarrollador.

 Vista interna del sistema.
 Estructurado por clases y paquetes.
 Utilizado fundamentalmente por los desarrolladores (forma, diseñado, implementado)
 Esboza cómo llevar a cabo la funcionalidad del sistema (diseño)
 Define realizaciones de CU (análisis de cada CU)

¿Cómo describimos el FTA?

Se describe definiendo Artefactos, Trabajadores y Actividades, se describe mediante el

comportamiento dinámico.

 Identificando los paquetes de análisis Principal, las clases y los requisitos.

 La redacción del comportamiento de cada clase.
 Especificar los requisitos e integrarlos a las clases creando responsabilidades, atributos y
relaciones.

Glosario

***********Documentacion: la documentación permite ejercer el control y la comunicación

entre los miembros del grupo de trabajo.

Se documenta para: comprender los compromisos que se asumen, las políticas que se definen y
los riesgos que se corren, comunicar la información de un sector a otro, controlar las alternativas
que sufre el proyecto y prevenir situaciones indeseables, comunicar a los usuarios las desiciones
del diseño.

Se documentan todas las desiciones tomadas y los modelos construidos.

Se documenta a medida que se van haciendo las cosas.

Sin documentación no hay mantenimiento posible del sistema. **********

Requisito: se utiliza con un sentido general refiriéndose a “necesidades”. Para poder capturar
estos requisitos de una forma más completa, tenemos que comprender con mayor amplitud el
negocio de los clientes y el entorno en que trabajan sus usuarios.