Resumen de Diseño de Sistemas – by Damián Nardelli & Diego Barberio & Lucas Mayoni

Normalización
La normalización es una forma de análisis de datos.
Organiza los atributos de datos de manera que se agrupen en estructuras
esencialmente estables (que no haya redundancia de datos).
Análisis de datos: es el procedimiento que lleva a un modelo de datos al grado de
refinamiento apropiado para su implementación (no redundante, flexible y adaptable)
En al normalización no hay prácticamente participación del usuario, ya que es
jodido para ellos (porque son estupidos por naturaleza).

Definiciones
Entidad: objeto que se puede distinguir. Ejemplos: Orquesta y Concierto.
Atributo: elemento de información que describe una entidad. Ejemplo: Tipo de
Concierto.
Relación: elemento que vincula dos o más entidades. Ejemplo: interpretación, una
Orquesta interpreta un Concierto.
SubTipo: Y es subtipo de X <=> para que Y exista debe existir X. Ejemplo:
Concierto es subtipo de Composición.
Dependencia Funcional: Existe DF entre un atributo B respecto de uno A <=> Si
conociendo A puedo saber el valor de B.
Determinante funcional: Existe un DF entre A respecto de B <=> B depende
funcionalmente de A.
Clave Candidata: un atributo o conjunto de atributos que determina en forma
univoca a la totalidad de la estructura y es lo mínima posible.
Clave Principal: clave candidata elegida como clave principal siguiendo algún
criterio en particular.

Características
• Opera sobre una estructura de datos ya definida.
• Se basa en conceptos del análisis de datos.
• Se realiza en 3 formas normales.

Pasos en la Normalización
1. Estructura Inicial: el modelo de datos tiene estructura repetitivas dependencias
incompletas de las claves y dependencias transitivas entre atributos. Es la que nos
da el usuario o el gil del analista. Antes de comenzar con las formas normales se
deben eliminar los atributos calculables.
2. Primera Forma Normal: No tiene atributos repetitivos. Tiene definido el Id de la
estructura.
3. Segunda Forma Normal: Se necesita la totalidad de la clave principal para
determinar a cada uno del resto de los atributos.
4. Tercera Forma Normal: No hay dependencias funcionales entre atributos no claves
Resumen de Diseño de Sistemas – by Damián Nardelli & Diego Barberio & Lucas Mayoni

(Un atributo no clave no puede depender de otro no clave).

5. Boyce And Code Normal Form (BCNF): Todo determinante es clave candidata (No
puede haber atributos que dependan de la clave principal y de un atributo no
clave)

Carta Estructurada
Es un diagrama jerárquico de módulos.
Modulo: Componente de software capaz de convertirse en una parte independiente.
Basado en los conceptos de alta cohesión y bajo acoplamiento para mejorar la
reusabilidad.
Clasificación:
• Según su función:
• Operativos: son los que se ocupan de completar las tareas propiamente dichas.
• Coordinación: son los que se encargan de controlar la ejecución de los
operativos.
• Según su uso (solo para módulos operativos):
• Terminales: Cuando producen un resultado final.
• Intermedios: El coordinador se lo pasa a otro.
• Según su tiempo de procesamiento:
• On-line: el proceso se realiza en forma continua (una tarea tras otra).
• Off-line: el proceso se corta temporariamente a la espera de una respuesta.

Heurísticas
Reglas de bases empíricas avaladas por la experiencia y comprobadas. Permiten
asegurar la calidad del diseño.
Cohesión: cantidad de funciones realizadas por un módulo.
Tipos (orden. de mejor a peor)
1. Cohesión funcional: hacer una y solo una tarea. Ejemplo: “Abrir Archivo”, solo
abre el archivo.
A partir de ahora todos los demás tipos ejecutan más de 1 tarea, la diferencia está
en como se comunican entre ellas.
2. Cohesión Secuencial: La salida de datos de una, es la entrada de datos de otra,
e importa la secuencialidad. Ejemplo: “Totalizar Factura”, compuesta por dos
tareas “Calcular Subtotal”, “Aplicar IVA”, para aplicar el IVA utilizo la señal de
datos que me pasa calcular subtotal.
3. Cohesión Comunicacional: Todas las tareas requieren la misma señal de datos.
No importa la secuencia. Ejemplo: “Grabar e imprimir Factura”. Ambas requieren
los datos de la factura para ejecutarse, pero son independientes.
Resumen de Diseño de Sistemas – by Damián Nardelli & Diego Barberio & Lucas Mayoni

4. Cohesión Procedimental: Las tareas se relacionan por señales de control.

Importa la secuencia. Ejemplo: “Abrir archivo y buscar alumno”, para buscar un
alumno debo abrir antes el archivo que contiene sus datos.
5. Cohesión Temporal: Las tareas se relacionan por el tiempo en que deben
ejecutarse. Ejemplo “Abrir archivo e inicializar vectores”, ambas se ejecutan al
inicio del programa.
6. Cohesión Lógica: Se ejecutan distintas tareas pero semejantes. Ejemplo:
“Calcular saldos de Cta. Cte. y Caja de ahorro”, son todos cálculos de distintas
cosas.
7. Cohesión Coincidental: Es de casualidad, las tareas no tienen nada que ver.
Ejemplo: “Buscar Cliente y Calcular Factura”. 'Para el que llega a una cohesión
coincidental es para agarrar y meterle un tiro en la capocha' by Diego (modified by
Damian).

Acoplamiento: Relación entre los módulos que se necesitan para que una estructura
pueda funcionar.
• De datos: se analiza según la composición de la señal de datos.
• De control: que un módulo coordinador le mande una señal de control a un módulo
operativo.

Fan In: Cantidad de líneas que se relacionan al módulo desde arriba.

Fan Out: Ídem. Anterior pero hacia abajo.
Inflows: Cantidad de señales entrantes.
Outflows: Cantidad de señales salientes.
Mezquita: Siempre al final queda la carta estructurada con esta forma, mediante el
agrupamiento de módulos de muy bajo nivel en librerías.
Diseño Externo - Fórmula Loka: Da un valor que indica la complejidad del módulo.
DE = A.(FanIn . Inflows) + B.(FanOut . Outflows)
A y B son constantes. Generalmente, A=B=1.
Alcance de Control: Es el mismo módulo, más el conjunto de módulos que están
relacionados directa o indirectamente mediante arcos hacia abajo.
Efecto de decisión: Son los módulos que se ven afectados por la decisión.
Alcance de efecto: Módulos que se ven afectados por otro.
Acoplamiento Patológico: Cuando existe uno o varios módulos que pertenecen al
conjunto de módulos del alcance de efecto, pero no del de alcance de control.

Diseño Arquitectónico
Determinar los subsistemas, su distribución física, la forma de comunicación ente ellos y
su estructura de control (determina la arquitectura del sistema).
Resumen de Diseño de Sistemas – by Damián Nardelli & Diego Barberio & Lucas Mayoni

Ventajas
Permite una comunicación con los stakeholders. Permite el análisis de sistema, al
dividir al sistema en subsistemas los que permite un análisis profundo de los
requerimientos.
Reutilización a gran escala

Proceso de Diseño de la Arquitectura:

• Estructuración del sistema: el sistema descompone en varios subsistemas principales y se identifican las
comunicaciones entre los mismos.
 Modelo Repositorio: muchos subsistemas intercambian datos compartiéndolos por medio de un
almacén común.
 Ventajas: forma eficiente de compartir datos.
 Desventajas:
 Los subsistemas deben coincidir en el modelo de datos de Repositorio.
 La evolución de los datos es difícil y cara
 Se dificultad una distribución eficiente.
 Arquitectura Cliente-Servidor: modelo de sistemas distribuido. Conjunto de servidores “stand-
alone”, los cuales proporcionan servicios específicos cuando un conjunto de clientes los requieren.
 Ventajas:
 La distribución de datos es directa.
 Permite uso efectivo de sistemas de Red (más barato).
 Es fácil añadir nuevos servidores.
 Desventajas:
 No comparte datos con los subsistemas de la organización.
 Administración redundante en cada servidor.
 No existen Registros centrales de nombres y servicios. Difícil encontrar los servidores y
servicios.
 Modelo de Máquina Abstracta: el sistema se organiza en base a un conjunto de capas, cada una
de las cuales proporciona un conjunto de servicios.
 Es utilizado para interfases de sistemas
 Soporta desarrollo incremental de subsistemas. Ofrece dificultad para sistemas estructurados de
esa manera.

• Modelos de Control: establece las relaciones entre las diferentes partes de un sistema. (subsistemas)
 Control Centralizado: un subsistema tiene sobre todo la responsabilidad de controlar, iniciar y
detener a otros subsistemas.
 Modelo Call-Return: un modelo de subrutina Top-Down donde el control inicia en lo más alto
de la jerarquía de una subrutina y se mueve hasta la parte más baja de la misma. Es aplicable a
sistemas secuenciales.
 Modelo Administrador: es aplicable a sistemas concurrentes. Un componente del sistema
controla el inicio, coordinación y el alto de procesos de otro sistema. Puede ser implementado en
sistemas secuenciales con una instrucción CASE.
 Control basado en eventos: cada subsistema puede responder a eventos generados externamente
por otros subsistemas o por el ambiente del sistema.
 Modelo de Transmisión: un evento es transmitido a todos los subsistemas. Cualquier subsistema
puede manejar el evento.
Resumen de Diseño de Sistemas – by Damián Nardelli & Diego Barberio & Lucas Mayoni

 Modelos Manejadores de interrupciones: utilizados en sistemas de tiempo real donde una

interrupción es detectada por un manejador de interrupciones y es pasada a otros componentes para
ser procesada.
• Descomposición Modular: los subsistemas identificados son descompuestos en módulos.
 Subsistema: es un sistema por si mismo y puede operar independientemente de los servicios
proporcionados por otros subsistemas.
 Módulo: es un componente del sistema que proporciona servicios a otros componentes y
normalmente no puede considerarse como parte separada del sistema.
 Modelos de Objetos: donde el sistema es descompuesto en objetos interactuando.
 Modelos de Flujo de Datos: donde el sistema es descompuesto en módulos funcionales, los
cuales transforman entradas en salidas. (modelo pipeline)

Arquitecturas de Dominio Específico

Son modelos de Arquitectura los cuales son específicos para algún dominio de aplicación.
 Modelos Genéricos: son abstracciones de un número de sistemas reales que encapsulan las
características principales de estos sistemas. (Ej: Modelo compilador)
 Modelos de Referencia: son modelos idealistas, más abstractos. Proporcionan un significado de
información con respecto a sistemas de clases y comparación de diversas arquitecturas. (Ej: Modelo
OSI)

Sistemas de Tiempo Real

Sistema que esta sujeto a restricciones de tiempo.
Hay 3 tipos:
• Hard (estricto): su operación es incorrecta si los resultados no son producidos en
tiempo. (Ej: Marcapasos)
• Soft (flexibles): su operación es degradada si los resultados no son producidos en
tiempo. (Sistemas de telefonía)
• Firm (firme): se admite cierto rango de perdido si los resultados no son producidos en el tiempo.
(Sistemas de monitoreo de aviones)

Clasificación
 Sistemas de Monitoreo: recolecta datos desde sensores pero no controla en
tiempo real los actuadores.
 Sistemas de Control: continuamente controlan sensores y en respuesta el
sistema envía señales de control a los actuadores.
 Sistemas de Captura de datos: recolectan datos desde los sensores para
subsecuentes procesos y análisis.

Sistemas de Estímulos respuestas: dados ciertos estímulos el sistema debe producir

una respuesta dentro de un tiempo especificado.
 Estímulo periódico: ocurre a intervalos predecibles de tiempo.
 Estímulo aperiódico: ocurre en momentos impredecibles.

Arquitectura:
Resumen de Diseño de Sistemas – by Damián Nardelli & Diego Barberio & Lucas Mayoni

 Por la necesidad de responder a demandas de tiempo hechas por diferentes

estímulo/respuesta, la arquitectura del sistema debe considerar rápidos
switchings entre manejadores de estímulos.
 Los STR son usualmente diseñados como procesos cooperativos.

Elementos del sistema:

 Procesador de control de Sensores: recolectan información desde los
sensores (recolectan datos del entorno del sistema)
 Procesador de datos: procesa la información recolectada y calcula la
respuesta del sistema.
 Procesador de control de Actuadores: genera señales de control (signals)
para los actores (cambian en algún modo el entorno del sistema)

Proceso de Diseño de STR:

 Identificar estímulos y respuestas asociadas.
 Definir restricciones de tiempo asociadas con cada estimulo y respuesta.
 Agregar funciones del sistema en procesos concurrentes. Un proceso debe
ser asociado con cada clase de estímulo y respuesta.
 Diseñar algoritmos para procesos de estímulos y generación de respuestas.
Deben conocer las restricciones de tiempo.
 Diseñar un sistema de planificación (scheduling) que asegure que los
procesos siempre serán planificados para ejecutar sus desconexiones.
 Integrar usando un Ejecutivo de tiempo real o sistema operativo.

Ejecutivo de Tiempo Real: es un SO especializado el cual administra los procesos en

el STR
 Características:
 Es responsable de administrar la alocación de procesos y recursos
(procesador y memoria)
 Puede estar basado en un kernel RTE.
 No incluye facilidades como administración de archivos:
 Componentes:
 Reloj de Tiempo Real: provee información para la planificación de procesos.
 Manipulador de interrupciones: administra solicitudes aperiódicas de
servicios.
 Planificador: define el próximo proceso a ejecutar.
 Administrador de recursos: Aloca recursos de memoria y procesador.
 Despachador: lanza la ejecución de procesos.
Resumen de Diseño de Sistemas – by Damián Nardelli & Diego Barberio & Lucas Mayoni

Modelo de Peters

Formalismo
Analisis de Sistema
Diseño del Sistema c ta
Implementación del Sistema o rre
C ca
ica áti
Operación del sistema ü í st m
o Lin
g r ag
mp aP sI
I
Ti e Optimización del Sistema
íst i c
ale
Definición de Problema

ü ur
Síntesis del Sistema

Toma de decisiones
Análisis del Sistema
g t
Lin uc I
str

Planificar Acción
s E
r a les
lo tu
de uc
Mo E str
os al
o del ent
M o M
del
Mo
Logico

• Eje Temporal: refleja todas las etapas del proyecto

• Eje Formal: posición mental que se adopta frente a un problema
• Eje Lógico: pasa de los modelos mentales hasta las expresiones lingüísticas.
Existe un cuarto eje de experiencia del profesional de sistemas.

Ciclos de Vida
Nombre Características Visibilidad Problemas y riesgos
Modelo de Fases: Buena. Cada Dificultad en hacer cambios
Cascada • Análisis de requerimientos y etapa produce entre etapas.
definición. un documento Alto riesgo en sistemas
• Diseño de sistemas y de SW. o resultado. nuevos por problemas en la
• Implementación y prueba de especificación y el diseño.
Unidades. Bajo Riesgo para desarrollos
• Integración y Prueba del bien comprendidos utilizando
sistema. tecnología conocida.
• Operación y Mantenimiento.
Considera cada actividad como
una actividad discreta
Desarrollo La especificación y el desarrollo Poca. Muy Sistemas pobremente
Evolutivo están intercalados. caro al especificados.
Considera actividades del producir Se requieren habilidades
Resumen de Diseño de Sistemas – by Damián Nardelli & Diego Barberio & Lucas Mayoni

proceso en forma concurrente. documentos en especiales

Aplicable para sistemas cada iteración Se construye sin
interactivos pequeños y especificación inicial
medianos, para partes de
sistemas grandes y para sistemas
de corta vida.
Prototipado Un modelo sirve de prototipo Falta de Bajo Riesgo para nuevas
para la construcción del sistema visibilidad. aplicaciones debido a que las
final. Alto Riesgo. especificaciones y el diseño
Exploratorio: trabajar con se llevan a cabo paso a paso.
clientes hasta evolucionar a un
sistema final.
Throw-away: entender los
requerimientos del sistema.
Se utiliza cuando hay
especificaciones incompletas
Transforma Un modelo Matemático se Buena. Cada
ción Formal transforma formalmente en la fase se
implementación. produce
Se utiliza cuando hay documentos
requerimientos estables y
sistemas de seguridad críticos
Desarrollo El sistema es ensamblado a Moderada. Importante contar con
basado en partir de componentes documentación de
reutilizació existentes. componentes reutilizables.
n
Modelo de Fases: Buena, cada El desarrollo contractual
Espiral • Planteamiento de objetivos: se segmento y especifica el modelo del
identifican los objetivos cada anillo del proceso y los resultados a
específicos para c/fase del espiral deben entregar por adelantado.
proyecto. producir un Requiere experiencia en
• Identificación y reducción de documento. identificación de riesgos.
Riesgos: se identifican y Requiere refinamiento para
analizan y la info sirve para uso generalizado.
minimizar los mismos.
• Desarrollo y Validación: se elige
un modelo apropiado para la
siguiente fase del desarrollo
• Planeación: se revisa el
proyecto y se trazan planes
para la siguiente ronda del
espiral.
Centra su atención en la
reutilización de componentes y
eliminación de errores.
Primer objetivo: CALIDAD
Integra desarrollo con
mantenimiento

RUP Proceso iterativo e incremental. Excelente. Complejidad de

Resumen de Diseño de Sistemas – by Damián Nardelli & Diego Barberio & Lucas Mayoni

Dirigido por los casos de uso. Cada iteración customización / adaptación.

Centrado en la arquitectura produce
Compuesto por: Fases, Workers, documentos
Workflows y Artefactos (artefactos).
XP Proceso iterativo e incremental. Management sin mucho
Testeo Continuo. detalle.
Programación por parejas. Problemas con proyectos
Interacción constante con el grandes.
cliente.
Corrección de todos los errores
antes de lanzar un nuevo release.
SCRUM Empírico, iterativo y Flexible. Prácticas de desarrollo y
Se basa en 3 etapas: Inicio, testing no descriptas.
Desarrollo y Cierre, dentro de la
etapa de desarrollo se producen
los sprints que son las
iteraciones, cuyo resultado final
es un release.

Ideal para problemas complejos

y de ambientes cambiantes.

Ingeniería de Requerimientos
Proceso de descubrir, analizar documentar y verificar los servicios y restricciones
(requerimientos) del sistema.
Clasificación de los requerimientos
• Del Usuario: declaraciones en lenguaje natural y/o diagramas de los servicios que
el usuario espera que el sistema provea y de las restricciones bajo las cuales debe
operar. Abstractos de alto nivel. (Lo que me dice el usuario)
• Del Sistema: descripción detallada de lo que el sistema debe hacer. (Lo que
realmente va a hacer el sistema). Funcionan como contrato entre el cliente y el
desarrollador.
o Funcionales: declaraciones de los servicios que realizara el sistema y su
respuesta a ciertas entradas. Ej: Se podrá consultar toda la base de datos o
parte de esta. El sistema NO permitirá el cambio de colores de la pantalla.
o No Funcionales: restricciones a los funcionales. Ej: Pantalla de color
amarillo patito.
o De Dominio: requerimientos que provienen del ambiente de
implementación del sistema. Ej: Se le aplicará el IVA a las personas que no
son monotributistas.
• Especificación del diseño de software: los elementos necesarios para el desarrollo
del software. Ej: un GateKeeper para testing, en el desarrollo de sistemas VoIP.
Resumen de Diseño de Sistemas – by Damián Nardelli & Diego Barberio & Lucas Mayoni

Documentación
• Manual de Normas y Procedimientos: normativa de los accionares de la
organización. No lo hace la gente de sistemas.
• Manual de Sistemas: que es lo que hace el sistema, quienes participan en cada
tarea y sus responsabilidades.
• Manual de Usuario: explica la forma de usar el sistema. Es difícil de realizarlo ya
que hay que definir el nivel de detalle y el lenguaje a utilizar.
• Manual de Operador: secuencia de pasos operativos.

Interfaces
Principios
 Familiaridad con el Usuario: uso de términos y conceptos conocidos por el
Usuario.
 Consistencia: operaciones semejantes, tratamiento semejante.
 Sorpresa mínima: el Usuario no debe sorprenderse con el comportamiento
del sistema.
 Recuperabilidad: facilidades de recuperación de errores del Usuario.
 Guías de Usuario: manuales y ayudas en línea fácilmente accesibles.
 Diversidad de Usuarios: contener y satisfacer las necesidades del total de
Usuarios que la utilizan.

Principios de diseño
• Las teclas de función siempre tienen que hacer lo mismo en todo el sistema.
• Lo mismo para las teclas en general.
• Iconos claros.
• Formato de las letras, que pueda ser observado a simple vista.
• Las ayudas pueden ser de dos tipos:
o Por pantalla:
o Por campo
Ambas deben describir solamente la pantalla o el campo respectivamente.
• Colores: evitar romperle los ojos al usuario con contrastes del orto
(amarillo con azul, negro con verde). Usar colores neutros (no brillantes. NO, no
le hagas la pantalla rosa fuerte por más que sea un sistema para la asociación de
gays). Utilizar un código de colores uniforme.
Tipos de Interfaces

• De Comando: línea de comando

• De Menús / Selección: se usa el cursor mayormente. Consiste en menús
Resumen de Diseño de Sistemas – by Damián Nardelli & Diego Barberio & Lucas Mayoni

desplegables, opciones de selección, etc. (Similar a la interfaz que el 95.6% de

nosotros uso para el TP de Operativos)
• Grafica: contiene iconos, punteros, menús contextuales, barras de
desplazamiento, ventanas, etc.

Navegabilidad en las Interfaces

1. Total: El usuario tiene acceso a toda la aplicación; asociativo, accede a cualquier

nodo de la interfaz, desde cualquier punto del dialogo
2. Parcial / Restringido: Permite el acceso a un espacio de la aplicación. Pueden
quedar módulos excluidos del acceso de determinados perfiles de usuario
3. Focal: Siguen una rama definida (son como los Wizards de instalación, por
ejemplo)
4. Tours: Ejemplo de funcionamiento del sistema. Muestra como se desarrolla una
operación determinada

UML (4+ 1 vistas)

Je, bueno no hubo tiempo para hacerlo y los dos aprobamos, sorry. Nos vemos en
Administración de Recursos
06/03/2006 Como yo ya rendí y se me hizo un hueco de tiempo, les paso lo que
tengo de las 4+1 vistas que mis compañeros no alcanzaron a detallar. Como ellos
dijeron, nos vemos en Administración de Recursos..

El desarrollo de UML esta centrado en la Vista de Casos de Uso, y la rodean la Vista de

Diseño, de Implementación, de Distribución (o Despliegue) y de Proceso

• Vista de Casos de Uso: describe el comportamiento del sistema; como lo ven los
usuarios finales, desarrolladores, analistas, etc. Se utilizan los diagramas de
Casos de Uso; los diagramas de Actividad, Estado e Interacción le aportan
dinamismo

• Vista de Diseño: conjunto de artefactos para que se realice el código. Diagramas

de Clase, Interfaces y Colaboración

• Vista de Implementación: componentes que se utilizan para confeccionar el

sistema propiamente dicho. Aquí ya tenemos una arquitectura definida; ahora se
genera la línea de productos
Resumen de Diseño de Sistemas – by Damián Nardelli & Diego Barberio & Lucas Mayoni

• Vista de Distribución: nodos que forman la topología físico del sistema sobre el
cual se ejecuta el sistema real

• Vista de Proceso: se ocupa de los procesos hilos; mecanismos de concurrencia y

sincronización entre los objetos o clases

Vista de Diseño Vista de Implementación

Vista de
Casos de
Uso
Vista de Proceso Vista de Distribución