Combine PDF

Introducción a la Ingeniería de
Software
El Software y la Ingeniería de
Software
CONTENIDO
2
Contenido
Contenido
Contenido
METODOLOGÍA
6
Distribución de los temas por
semana
• Semana 1 – La Ingeniería de Software
• Semana 2 – Ingeniería de Procesos de Software
• Semanas 3 y 4 – Ingeniería de Requisitos
• Semana 5 – Examen Primer Parcial
• Semanas 6 y 7 – Ingeniería de Diseño
• Semana 8 – Garantía de la Calidad de Software
• Semana 9 – Examen Segundo Parcial
• Semanas 10 y 11 – Técnicas de Pruebas del Software
• Semana 12 – Gestión y Estimación de Proyectos de
Software
• Semana 13 – Métricas de Proyectos
• Semana 14 – Examen Final
Actividades
• Práctica 1 - El Software y la Ingeniería de Software (3 puntos)
• Práctica 2 - Ingeniería de Procesos de Software (3 puntos)
• Práctica 3 - Ingeniería de Requisitos (Parte I) (3 puntos)
• Práctica 4 - Ingeniería de Requisitos (Parte II) (3 puntos)
• Práctica 5 - Ingeniería del Diseño (Parte I) (3 puntos)
• Práctica 6 - Ingeniería del Diseño (Parte II) (3 puntos)
• Práctica 7 - Garantía de la Calidad de Software (3 puntos)
• Práctica 8 - Técnicas de Pruebas del Software (Parte I) (3 puntos)
• Práctica 9 - Técnicas de Pruebas del Software (Parte II) (3 puntos)
• Práctica 10 - Gestión y Estimación Proyectos de Software (4 puntos)
• Práctica 11 - Métricas de Software (4 puntos)
• Exposiciones (5 puntos)
EVALUACIÓN
9
Resumen
• Prácticas: 40 puntos
• Exámenes: 60 puntos
Profe, deme esos dos
puntitos para la C, a favol…
Práctica final (4 puntos)

BIBLIOGRAFÍA
12
¿CONOCIMIENTOS PREVIOS?
14
¿EXPECTATIVAS?
15
Es el conjunto de los programas de cómputo,
procedimientos, reglas, documentación y datos
asociados, que forman parte de las operaciones
de un sistema de computación.
Extraído del estándar 729 del IEEE
Ingeniería es el conjunto de conocimientos y

técnicas científicas aplicadas al desarrollo,
implementación, mantenimiento y
perfeccionamiento de estructuras (tanto
físicas como teóricas) para la resolución de
problemas que afectan la actividad cotidiana
La ingeniería de software está formada por un de la sociedad.
proceso, un conjunto de métodos (prácticas) y
un arreglo de herramientas que permite a los
profesionales elaborar software de cómputo de
alta calidad.
Ley de las consecuencias inesperadas, cualquier acción humana, especialmente
las que envuelven o afectan a grupos humanos extensos, tendrá consecuencias
no anticipadas o calculadas.
Papel dual del Software
Características del Software
Se construye a
la medida; se
construye por
componentes
El software
no se
desgasta pero
sí se deteriora
El software se
desarrolla o modifica
con intelecto; no se
manufactura
Software Heredado
• Programas viejos - Longevidad
• Múltiples modificaciones
• Soporte de las funciones centrales de negocios –
Críticos
• Mala calidad
• No son susceptibles de extenderse
• Código confuso
• Documentación mala o inexistente
• Casos y resultados de prueba que nunca se archivaron
• Historial de cambio mal administrado
Por qué evoluciona el Software?
• Para que cumpla las necesidades de los nuevos

ambientes del cómputo y de la tecnología.
• Implementar nuevos requerimientos del
negocio
• Para hacerlo operable con otros sistemas o
bases de datos modernos.
• La arquitectura del software debe rediseñarse
para hacerla viable dentro de un ambiente de
redes.
Debe hacerse ingeniería con el software en todas sus formas y a través de todos
sus dominios de aplicación.
La ingeniería de software es el
establecimiento y uso de principios
fundamentales de la ingeniería con objeto
de desarrollar en forma económica software
que sea confiable y que trabaje con
eficiencia en máquinas reales. Fritz Bauer
Capas de la ingeniería de software
¿Cuáles son los
elementos de un
proceso de software?
Actividades estructurales del Proceso
• Comunicación
• Planeación
• Modelado
• Construcción
• Despliegue
Principios generales
• Dar valor a sus usuarios
• Todo diseño debe ser tan simple como sea
posible, pero no más
• Una visión clara es esencial para el éxito de un
proyecto de software
• Siempre establezca especificaciones, diseñe e
implemente con la seguridad de que alguien más
tendrá que entender lo que usted haga
• Un sistema con larga vida útil tiene más valor
• Planee por anticipado la reutilización
• ¡Piense!
Mitos del Software
Mitos de la Mitos del Mitos del

administración cliente desarrollador
Cualquier Corregir un defecto
proyecto
de Adaptar un sistema heredado a un
Software se ambiente de negocios cambiante
inicia por Extender las funciones y
alguna características
necesidad Crear un producto, servicio o
del Negocio sistema nuevos
Software
Conceptos y principios del análisis
(Parte I)
Conceptos
¿Qué es la práctica de la
ingeniería de software?
Principios
Métodos
Herramientas
Principios Fundamentales
• Nivel del proceso
− Establecen un fundamento filosófico que guía al equipo de software
cuando:
 Realiza actividades estructurales y actividades sombrilla
 Navega por el flujo del proceso
 Elabora un conjunto de productos del trabajo de la ingeniería de software
• Nivel de la práctica
− Definen un conjunto de valores y reglas que sirven como guía cuando:
 Se analiza un problema
 Se diseña una solución
 Se implementa y prueba ésta
 Se entrega el software a la comunidad de usuarios
Principios que guían el proceso
• Ser ágil
− Son los principios básicos del desarrollo ágil los
que deben gobernar el enfoque
− Economía de acción:
 Mantener el enfoque técnico tan sencillo como sea
posible
 Hacer los productos del trabajo que se generan tan
concisos como se pueda
 Tomar las decisiones localmente, siempre que sea
posible
• Centrarse en la calidad
Principios que guían el proceso
• Estar listo para adaptar
– Adapte su enfoque a las restricciones impuestas por el problema, la gente y el proyecto
en sí
• Formar un equipo eficaz
– El objetivo son las personas
– Forme un equipo con organización propia en el que haya confianza y respeto mutuos
• Establecer mecanismos para la comunicación y coordinación
• Administrar el cambio
– Deben establecerse mecanismos para administrar la forma en la que los cambios se
solicitan, evalúan, aprueban e implementan
• Evaluar el riesgo
– Es esencial establecer planes de contingencia
• Crear productos del trabajo que agreguen valor para otros
– Asegúrese de que el producto del trabajo imparte la información necesaria sin
ambigüedades u omisiones
Principios que guían la práctica
• Divide y vencerás
– Separación de entidades, un problema grande es más fácil de resolver si se
divide en un conjunto de elementos
• Entender el uso de la abstracción
– Abstracción: Simplificación de algún elemento complejo de un sistema usado
para comunicar significado en una sola frase
– El objetivo de una abstracción es eliminar la necesidad de comunicar detalles
• Buscar la coherencia
– Principio de coherencia: Sugiere que un contexto familiar hace que el software
sea más fácil de usar. Considerar el aspecto ergonómico
• Centrarse en la transferencia de información
– La información fluye a través de una interfaz
– Debe ponerse atención especial al análisis, diseño, construcción y prueba de
las interfaces
Principios que guían la práctica
• Construir software que tenga modularidad eficaz
– Cada módulo debe centrarse exclusivamente en un aspecto bien delimitado
del sistema
– Cohesivo en su función
– Restringido en el contenido que representa
– Interconectados en forma relativamente sencilla, poco acoplamiento
• Buscar patrones
– Objetivo de los patrones
 Crear un cúmulo de bibliografía para resolver problemas recurrentes
 Crear un lenguaje compartido
 Acumular con éxito el cuerpo de conocimientos que define nuestra comprensión de
las buenas arquitecturas que satisfacen las necesidades de sus usuarios
• Cuando sea posible, representar el problema y su solución desde
varias perspectivas diferentes
• Tener en mente que alguien dará mantenimiento al software
PRINCIPIOS QUE GUÍAN TODA
ACTIVIDAD ESTRUCTURAL
Principios de Escuchar Centrarse en las palabras del hablante en lugar
de formular su respuesta a dichas palabras
comunicación
Si algo no está claro, pregunte para aclararlo,
pero evite las interrupciones constantes
Antes de comunicarse, Dedique algún tiempo a entender el problema

antes de reunirse con otras personas
prepararse
Alguien debe facilitar la Mantenga la conversación en movimiento
actividad. Facilitador que: Mediador en cualquier conflicto
Garantice que se sigan otros principios
Es mejor la comunicación
cara a cara
Principios de Tomar notas y documentar las decisiones
comunicación
Perseguir la colaboración
Permanecer centrado; hacer módulos con Abandonar un tema sólo después de que se
la discusión haya resuelto
Si algo no está claro, hacer un dibujo

a) Una vez que se acuerde algo, b) Si no
es posible ponerse de acuerdo en algo, c)
Si una característica o función no está Avanzar
clara o no puede aclararse en el
momento
La negociación no es un concurso o un Negociar funciones y características,
juego. Funciona mejor cuando las dos prioridades y fechas de entrega
partes ganan La negociación demandará el compromiso
de todas las partes
• Principios de planeación
– Entender el alcance del proyecto
 El alcance da un destino al equipo de software
– Involucrar en la actividad de planeación a los participantes del
software
– Reconocer que la planeación es iterativa
 Los modelos de proceso iterativo incrementales dictan que debe repetirse
la planeación después de la entrega de cada incremento de software, con
base en la retroalimentación recibida de los usuarios
– Estimar con base en lo que se sabe
 El objetivo de la estimación es obtener un índice del esfuerzo, costo y
duración de las tareas, con base en la comprensión que tenga el equipo
sobre el trabajo que va a realizar
– Al definir el plan, tomar en cuenta los riesgos
• Principios de planeación (cont.)
– Ser realista
 Las personas no trabajan 100% todos los días
– Ajustar la granularidad cuando se defina el plan
 Granularidad, nivel de detalle que se adopta cuando se desarrolla un plan
– Definir cómo se trata de asegurar la calidad
 Si se realizan revisiones técnicas, deben programarse
 Si se usará programación por parejas, debe definirse en forma explícita en el
plan
– Describir cómo se busca manejar el cambio
 Debe identificarse la forma en la que van a recibirse los cambios a medida que
avanza el trabajo de la ingeniería de software
– Dar seguimiento al plan con frecuencia y hacer los ajustes que se
requieran
• Evaluar diariamente el avance
• Cuando se detecten desviaciones, hay que ajustar el plan en consecuencia
V N
Representar
i Información i
s v
t e
a l
del Construcción más

Arquitectura y
Comportamiento
Funciones
C de Software T
l é
i c
e n
n i
t Características
c
e o
Principios de Modelado
Dominio
de la Arquitectura
Información
Modelos
Modelos
de de
Requerimientos
Dominio Dominio Interfaz de
Diseño Nivel de
de
Comportamiento Funcional usuario componente
Principios de Modelado
Principios de modelado
• El equipo de software tiene como objetivo principal elaborar software, no crear
modelos
• Viajar ligero, no crear más modelos de los necesarios
• Tratar de producir el modelo más sencillo que describa al problema o al software
• Construir modelos susceptibles al cambio
• Ser capaz de enunciar un propósito explícito para cada modelo que se cree
• Adaptar los modelos que se desarrollan al sistema en cuestión
• Tratar de construir modelos útiles, pero olvidarse de elaborar modelos perfectos
• No ser dogmático respecto de la sintaxis del modelo. Si se tiene éxito para
comunicar contenido, la representación es secundaria
• Si su instinto dice que un modelo no es el correcto a pesar de que se vea bien en
el papel, hay razones para estar preocupado
• Obtener retroalimentación tan pronto como sea posible
• Principios de modelado de los Requerimientos
– Debe representarse y entenderse el dominio de información de un problema
 Datos que fluyen hacia el sistema
 Datos que fluyen fuera del sistema
 Almacenamientos de datos que recaban y organizan objetos persistentes de datos
– Deben definirse las funciones que realizará el software
– Debe representarse el comportamiento del software
 Interacción con el ambiente externo
 Entradas que dan los usuarios finales
 Control de los datos efectuado por un sistema externo
 Vigilancia de datos reunidos en una red
– Los modelos que representen información, función y comportamiento deben

dividirse de manera que revelen los detalles en forma estratificada
 Divide y vencerás
 Partición o separación de entidades
– El trabajo de análisis debe avanzar de la información esencial hacia la
implementación en detalle
• Principios del modelado del diseño
– El diseño debe poderse rastrear hasta el modelo de
requerimientos
– Siempre tomar en cuenta la arquitectura del sistema
que se va a construir
• Interfaces
• Estructuras de datos
• Flujo de control
• Comportamiento del
programa
• Pruebas
• Mantenimiento
La arquitectura
del software
• Principios del modelado del diseño (cont.)
– El diseño de los datos es tan importante como el de las funciones de
procesamiento
 Ayuda a simplificar el flujo del programa
 Hace más fácil el diseño e implementación de componentes de software
 Hace más eficiente el procesamiento conjunto
– Las interfaces deben diseñarse con cuidado
– El diseño de la interfaz de usuario debe ajustarse a las necesidades
del usuario final
 Debe resaltar la facilidad de uso
– El diseño en el nivel de componentes debe tener independencia
funcional
 Cohesiva, centrarse en una y sólo una función o subfunción
• Principios del modelado del diseño (cont.)
– Los componentes deben estar acoplados con holgura entre sí y con el
ambiente externo
 El acoplamiento de componentes debe mantenerse tan bajo como sea
razonable
– Las representaciones del diseño (modelos) deben entenderse con

facilidad
 Propósito del diseño, comunicar información a los profesionales que
generarán el código, a los que probarán el software y a otros que le darán
mantenimiento en el futuro
– El diseño debe desarrollarse en forma iterativa. El diseñador debe

buscar más sencillez en cada iteración
• Principios de construcción
– Codificación
• Creación directa de lenguaje de programación en
código fuente
• Generación automática de código fuente
– Pruebas
• De integración
• De validación
• De aceptación
Principios de codificación
• Principios de preparación
– Entender el problema que se trata de resolver.
– Comprender los principios y conceptos básicos del
diseño.
– Elegir un lenguaje de programación que satisfaga las
necesidades del software que se va a elaborar y el
ambiente en el que operará.
– Seleccionar un ambiente de programación que
disponga de herramientas que hagan más fácil su
trabajo.
– Crear un conjunto de pruebas unitarias
• Principios de programación
– Restringir sus algoritmos
– Programación por parejas
– Seleccionar estructuras de datos que satisfagan las
necesidades del diseño
– Entender la arquitectura del software
– Mantener la lógica condicional tan sencilla como sea
posible
– Crear lazos anidados
– Seleccionar nombres significativos para las variables
– Escribir código que se documente a sí mismo
– Crear una imagen visual
• Principios de validación
– Recorrido del código
– Pruebas unitarias y corregir errores detectados
– Rediseñar el código
• Objeto de la prueba:
Encontrar un error ¿Cuáles son los
• Caso de prueba: objetivos de probar el
Probabilidad de software?
encontrar un error no
detectado hasta el
momento
• Prueba exitosa:
Descubre un error no
detectado hasta el
momento
• Principios de la prueba
– Todas las pruebas deben poder rastrearse hasta
los requerimientos del cliente
– Las pruebas deben planearse mucho antes de que
den comienzo
– El principio de Pareto se aplica a las pruebas de
software
Componentes
Errores
• Principios de la prueba (cont.)
– Las pruebas deben comenzar “en lo pequeño” y
avanzar hacia “lo grande”
– No son posibles las pruebas exhaustivas
Principios de construcción
• Entrega
• Apoyo
• Retroalimentación
Actividad del
despliegue
Principios de construcción
Principios de despliegue
• Deben manejarse las expectativas de los clientes
• Debe ensamblarse y probarse el paquete completo que
se entregará
• Antes de entregar el software, debe establecerse un
régimen de apoyo
• Se deben proporcionar a los usuarios finales materiales
de aprendizaje apropiados
• El software defectuoso debe corregirse primero y
después entregarse
COMPRENSIÓN DE LOS
REQUERIMIENTOS
Es la peor de las pesadillas. Un cliente

entra a la oficina, toma asiento, lo
mira a uno fijamente a los ojos y dice:
“Sé que cree que entiende lo que
digo, pero lo que usted no entiende
es que lo que digo no es lo que quiero
decir.”
Ingeniería de Requerimientos
• Espectro amplio de tareas y técnicas que llevan a entender los
requerimientos
• Se definen las necesidades del negocio, se describen los escenarios de uso,
se delinean las funciones y características y se identifican las restricciones
del proyecto
• Proporciona el mecanismo apropiado para:
– Entender lo que desea el cliente,
– Analizar las necesidades,
– Evaluar la factibilidad,
– Negociar una solución razonable,
– Especificar la solución sin ambigüedades,
– Validar la especificación y
– Administrar los requerimientos a medida de que se transforman en un
sistema funcional
• Tareas:
– Concepción
• Se identifica una necesidad del negocio o se
descubre un nuevo mercado o servicio potencial
• Se establece el entendimiento básico del
problema, las personas que quieren una solución,
la naturaleza de la solución que se desea, así como
la eficacia de la comunicación y colaboración
preliminares entre los otros participantes y el
equipo de software
• Tareas (cont.)
– Indagación
• Preguntar al cliente, a los usuarios y a otras personas
cuáles son los objetivos para el sistema o producto
Problemas de alcance, la frontera de

los sistemas está mal definida ¿Por qué es difícil
Problemas de entendimiento, los llegar al entendimiento
clientes o usuarios no están claro de lo que quiere
completamente seguros de lo que se
necesita
el cliente?
Problemas de volatilidad, los
requerimientos cambian con el
tiempo
• Tareas (cont.)
– Elaboración
• Se centra en desarrollar un modelo refinado de los
requerimientos que identifique distintos aspectos de la
función del software, su comportamiento e información
• Creación y mejora de escenarios de usuario que describan
cómo interactuará el usuario final con el sistema
• Extraer clases de análisis
• Se definen los atributos de cada clase de análisis
• Se identifican los servicios que requiere cada clase de
análisis
• Se identifican las relaciones y colaboración entre clases
• Se producen varios diagramas adicionales
• Tareas (cont.)
– Negociación
• Se pide a clientes, usuarios y otros participantes que
ordenen sus requerimientos según su prioridad y que
después analicen los conflictos
• Se evalúa su costo y riesgo, y se enfrentan los conflictos
internos
– Especificación
• Documento escrito
• Conjunto de modelos gráficos
• Modelo matemático formal
• Conjunto de escenarios de uso
• Prototipo
• Tareas (cont.)
– Validación
• Analiza la especificación a fin de garantizar que
– Todos ellos han sido enunciados sin ambigüedades
– Se detectaron y corrigieron las inconsistencias, las omisiones y los errores
– Los productos del trabajo se presentan conforme a los estándares
establecidos para el proceso, el proyecto y el producto
• El mecanismo principal de validación de los requerimientos es la
revisión técnica
– Administración de los requerimientos

• Conjunto de actividades que ayudan al equipo del proyecto a
identificar, controlar y dar seguimiento a los requerimientos y a
sus cambios en cualquier momento del desarrollo del proyecto
Etapas requeridas para establecer
las bases que permiten entender
los requerimientos de software
Identificación Reconocer los Hacer las

Trabajar hacia
de los múltiples primeras
la colaboración
participantes puntos de vista preguntas
¿Quién está detrás
de la solicitud de
este trabajo?
¿Es usted la
persona indicada ¿Quién usará la
para responder solución?
estas preguntas?
¿Cuáles preguntas
ayudarían a tener un
¿Puede otra ¿Cuál será el
persona dar beneficio
entendimiento preliminar
información económico de una del problema?
adicional? solución exitosa?
¿Qué problemas ¿Hay otro origen

resolvería esta para la solución que
solución? se necesita?
Indagación de los requerimientos
• Recabación de los requerimientos en forma
colaborativa
– Tanto ingenieros de software como otros participantes
dirigen o intervienen en las reuniones
– Se establecen reglas para la preparación y participación
– Se sugiere una agenda con suficiente formalidad para
cubrir todos los puntos importantes, pero con la suficiente
informalidad para que estimule el libre flujo de ideas
– Un “facilitador controla la reunión
– Se utiliza un “mecanismo de definición”
La meta es identificar el problema, proponer elementos de la solución, negociar
distintos enfoques y especificar un conjunto preliminar de requerimientos de la
solución
• Despliegue de la función de calidad (DFC)
– Técnica de administración de la calidad que traduce las necesidades
del cliente en requerimientos técnicos para el software
– Se concentra en maximizar la satisfacción del cliente a partir del
proceso de ingeniería del software
– Pone el énfasis en entender lo que resulta valioso para el cliente y
luego despliega dichos valores en todo el proceso de ingeniería
– Identifica tres tipos de requerimientos
 Requerimientos normales. Objetivos y metas que se establecen para un producto o
sistema durante las reuniones con el cliente. Si estos requerimientos están
presentes, el cliente queda satisfecho
 Requerimientos esperados. Están implícitos en el producto o sistema y quizá sean
tan importantes que el cliente no los mencione de manera explícita. Su ausencia
causará mucha insatisfacción
 Requerimientos emocionantes. Estas características van más allá de las
expectativas del cliente y son muy satisfactorias si están presentes.
Escenarios de uso
• Proporcionan la descripción de la manera en la que se utilizará el sistema
Indagación de los productos del trabajo

• Un enunciado de la necesidad y su factibilidad
• Un enunciado acotado del alcance del sistema o producto
• Una lista de clientes, usuarios y otros participantes
• Una descripción del ambiente técnico del sistema
• Una lista de requerimientos y las restricciones del dominio que se aplican a
cada uno
• Un conjunto de escenarios de uso que dan perspectiva al uso del sistema o
producto en diferentes condiciones de operación
• Cualesquiera prototipos desarrollados para definir requerimientos.
DESARROLLO DE CASOS DE USO
• Un caso de uso narra una historia estilizada
sobre cómo interactúa un usuario final con
el sistema en circunstancias específicas
• Ilustra el software o sistema desde el punto
de vista del usuario final
• Actores, cualquier cosa que se comunique
con el sistema o producto y que sea externo
a éste
– Actores principales, interactúan para
lograr la función requerida del sistema y
obtienen el beneficio previsto de éste
– Actores secundarios, dan apoyo al
sistema, de modo que los primarios
puedan hacer su trabajo.
¿Qué se necesita saber a fin de
desarrollar un caso de uso eficaz?
• ¿Quién es el actor principal y quién(es) el(los) secundario(s)?
• ¿Cuáles son los objetivos de los actores?
• ¿Qué precondiciones deben existir antes de comenzar la historia?
• ¿Qué tareas o funciones principales son realizadas por el actor?
• ¿Qué excepciones deben considerarse al describir la historia?
• ¿Cuáles variaciones son posibles en la interacción del actor?
• ¿Qué información del sistema adquiere, produce o cambia el actor?
• ¿Tendrá que informar el actor al sistema acerca de cambios en el
ambiente externo?
• ¿Qué información desea obtener el actor del sistema?
• ¿Quiere el actor ser informado sobre cambios inesperados?
Elaboración del modelo de los
requerimientos
• Objetivo del modelo del análisis
– Describir los dominios de información, función y comportamiento que se
requieren para un sistema basado en computadora
• Elementos del modelo de requerimientos

– Elementos basados en el escenario, el sistema se describe desde el punto de
vista del usuario con el empleo de un enfoque basado en el escenario
– Elementos basados en clases, cada escenario de uso implica un conjunto de
objetos que se manipulan cuando un actor interactúa con el sistema. Se
clasifican en clases: conjunto de objetos que tienen atributos similares y
comportamientos comunes
– Elementos de comportamiento, tiene un efecto profundo en el diseño que se
elija y en el enfoque de implementación que se aplique
– Elementos orientados al flujo, el sistema acepta entradas en varias formas,
aplica funciones para transformarla y produce salidas en distintos modos
El diagrama de estado es un método de representación del comportamiento de un sistema que
ilustra sus estados y los eventos que ocasionan que el sistema cambie de estado
Un estado es cualquier modo de comportamiento observable desde el exterior

Elaboración del modelo de los
requerimientos
• Patrones de análisis
– Sugieren soluciones dentro del dominio de la
aplicación que pueden volverse a utilizar cuando se
modelen muchas aplicaciones
– Beneficios
1. Aceleran el desarrollo de los modelos de análisis abstracto
que capturan los principales requerimientos del problema
concreto, debido a que proveen modelos de análisis
reutilizables con ejemplos, así como una descripción de
sus ventajas y limitaciones
2. Facilitan la transformación del modelo de análisis en un

modelo del diseño, sugiriendo patrones de diseño y
soluciones confiables para problemas comunes
Requerimientos de las negociaciones
• Objetivo
– Desarrollar un plan del proyecto que satisfaga las
necesidades del participante y que al mismo tiempo refleje
las restricciones del mundo real que se hayan establecido
al equipo del software
• Actividades
– Identificación de los participantes clave del sistema o
subsistema
– Determinación de las “condiciones para ganar” de los
participantes
– Negociación de las condiciones para ganar de los
participantes a fin de reconciliarlas en un conjunto de
condiciones ganar-ganar para todos los que intervienen
Cuando se revisan los requerimientos,
¿qué preguntas deben plantearse?
• ¿Es coherente con los objetivos generales del sistema o producto?
• ¿Se han especificado en el nivel apropiado de abstracción?
• ¿Es realmente necesario?
• ¿Está acotado y no es ambiguo?
• ¿Hay una fuente clara?
• ¿Hay requerimientos en conflicto con otros?
• ¿Es asequible en el ambiente técnico que albergará el sistema o producto?
• ¿Puede someterse a prueba?
• ¿Refleja de manera apropiada la información, la función y el comportamiento del
sistema que se va a construir?
• ¿Se ha “particionado” en forma que exponga información cada vez más detallada
sobre el sistema?
• ¿Se ha usado el patrón para simplificar el modelo de éstos? ¿Se han validado todos
los patrones de manera apropiada? ¿Son consistentes todos los patrones con los
requerimientos del cliente?
Software
(Parte II)
Modelado de los requerimientos
• Utiliza una combinación de texto y diagramas para
ilustrarlos en forma que sea relativamente fácil de
entender y de revisar para corregir, completar y hacer
congruente.
• Da como resultado:
– La especificación de las características operativas del
software
– Indica la interfaz de éste y otros elementos del sistema
– Establece las restricciones que limitan al software
• Permite al profesional construir sobre los
requerimientos básicos establecidos durante las tareas
de concepción, indagación y negociación
Modelado de los requerimientos
Tipos de modelo:
• Modelos basados en el escenario desde el punto de vista de
distintos “actores” del sistema
• Modelos de datos, ilustran el dominio de información del
problema
• Modelos orientados a clases, representan clases orientadas a
objetos y la manera en la que las clases colaboran para cumplir
con los requerimientos del sistema
• Modelos orientados al flujo, representan los elementos
funcionales del sistema y la manera como transforman los datos
a medida que se avanza a través del sistema
• Modelos de comportamiento, ilustran el modo en el que se
comporta el software como consecuencia de “eventos” externos
Caso de Uso
Modelos Basados en el Escenario

Diagrama de Actividades

Diagrama de Carril (swimlane)

Modelo Relacional
Modelo E-R
Modelos de Datos
Modelos Orientados a Clase
Diagrama CRC

Diagrama de Paquetes

Modelos Orientados al Flujo
Diagrama de Secuencia
Diagrama de Estado
Modelos Orientados al Comportamiento

Objetivos y filosofía general
Durante el modelado de los requerimientos,

la atención se centra en qué, no en cómo
• ¿Qué interacción del usuario ocurre en una
circunstancia particular?
• ¿Qué objetos manipula el sistema?
• ¿Qué funciones debe realizar el sistema?
• ¿Qué comportamientos tiene el sistema?
• ¿Qué interfaces se definen?
• ¿Qué restricciones son aplicables?
Objetivos y filosofía general
Objetivos principales:
• Describir lo que requiere el cliente
• Establecer una base para la creación de un

diseño de software
• Definir un conjunto de requerimientos que

puedan validarse una vez construido el software
Reglas prácticas del análisis
• El modelo debe centrarse en los requerimientos que sean visibles dentro del
problema o dentro del dominio del negocio
• Cada elemento debe agregarse al entendimiento general de los requerimientos del

software y dar una visión del dominio de la información, de la función y del
comportamiento del sistema
• Hay que retrasar las consideraciones de la infraestructura y otros modelos no

funcionales hasta llegar a la etapa del diseño
• Debe minimizarse el acoplamiento a través del sistema
• Es seguro que el modelo de requerimientos agrega valor para todos los

participantes
• Mantener el modelo tan sencillo como se pueda

Análisis del dominio
El análisis del dominio del software
• Es la identificación, análisis y especificación de los
requerimientos comunes, a partir de un dominio de
aplicación específica, normalmente para usarlo varias veces
en múltiples proyectos dentro del dominio de la aplicación
La meta
• Encontrar o crear aquellas clases o patrones de análisis que
sean aplicables en lo general, de modo que puedan volverse
a usar
Enfoques del modelado de
requerimientos
• Análisis estructurado, considera que los datos y los procesos
que los transforman son entidades separadas
– Los objetos de datos, se modelan de modo que se definan
sus atributos y relaciones
– Los procesos, se modelan en forma que se muestre cómo
transforman a los datos a medida que los objetos que se
corresponden con ellos fluyen por el sistema
• Análisis orientado a objetos, se centra en la definición de las

clases y en la manera en la que colaboran uno con el otro para
cumplir los requerimientos
Modelado basado en escenarios
• Creación de un caso preliminar de uso
– Caso de uso
• Capta las interacciones que ocurren entre los productores y
consumidores de la información y el sistema en sí
– ¿Sobre qué escribir?
• Las reuniones para recabar los requerimientos, el DEC, y
otros, se utilizan para:
 Identificar a los participantes
 Definir el alcance del problema
 Especificar los objetivos operativos generales
 Establecer prioridades
 Delinear todos los requerimientos funcionales conocidos
 Describir las cosas que serán manipuladas por el sistema
Mejora de un caso de uso preliminar
¿El actor puede emprender
otra acción en este punto?
¿Es posible que el actor ¿Cómo examino los cursos
encuentre alguna condición alternativos de acción?
de error en este punto?
¿Cuál podría ser?
¿Es posible que el actor
encuentre otro
comportamiento? ¿Cuál
sería?
• Escenarios secundarios, forman parte del caso de uso
original, pero representan comportamientos alternativos
Mejora de un caso de uso preliminar
• Excepción
– Describe una situación que ocasiona que el sistema
presente un comportamiento algo distinto
– Debe describirse dentro del caso de uso si el software
la puede detectar y debe manejarla una vez detectada
– ¿Existen casos en los que ocurra alguna “función de
validación” durante este caso de uso?
– ¿Hay casos en los que una función (o actor) de soporte
falle en responder de manera apropiada?
– ¿El mal desempeño del sistema da como resultado
acciones inesperadas o impropias?
Escritura de un caso de uso formal
Excepciones
Disparador • Identifican las
Objetivo en • Identifica el situaciones
contexto evento o detectadas
condición que cuando se
• Identifica el “hace que mejora el caso
alcance general comience el caso de uso
del caso de uso de uso” preliminar
Precondición Escenario
• Describe lo que • Enlista las
se sabe que es acciones
verdadero antes específicas que
de que inicie el requiere el actor,
caso de uso y las respuestas
apropiadas del
sistema
Modelos UML que proporcionan el
caso de uso
• El diagrama de actividad UML
– Representa las acciones y decisiones que
ocurren cuando se realiza cierta función
– Gráfica del flujo de interacción dentro de
un escenario específico
• Rectángulos redondeados para denotar
una función específica del sistema,
• Flechas para representar flujo a través de
éste
• Rombos de decisión para ilustrar una
ramificación de las decisiones
• Líneas continuas para indicar que están
ocurriendo actividades en paralelo
Modelos UML que proporcionan el
caso de uso
• Diagramas de canal
– Representa el flujo de
acciones y decisiones e
indica qué actores
efectúan cada una de
ellas
– Las responsabilidades se
representan con
segmentos paralelos que
dividen el diagrama en
forma vertical
Conceptos de modelado de datos
• Modelo de datos
– Un ingeniero o analista de software define:
• Objetos de datos que se procesan dentro del sistema
• Relación entre ellos
• Otro tipo de información que sea pertinente para las
relaciones
– Diagrama entidad-relación
• Representa los datos que se introducen, almacenan,
transforman y generan dentro de una aplicación
algo que tiene varias
propiedades o atributos
• Objetos de datos diferentes
– Representación de información compuesta que

debe ser entendida por el software
• Entidad externa, cosa, ocurrencia, evento, rol
• Unidad organizacional, lugar, estructura
– Un objeto de datos contiene sólo datos
– Puede representarse en forma de tabla
• Atributos, encabezados de la tabla
• Instancias, cuerpo de la tabla
• Atributos de los datos
– Definen las propiedades de un objeto de datos
– Características
1) Nombrar una instancia del objeto de datos
2) Describir la instancia
3) Hacer referencia a otra instancia en otra tabla
– Atributo identificador, se convierte en una “llave”
cuando se desea encontrar una instancia del objeto de
datos
• Relaciones
– Los objetos de datos están conectados entre sí de
diferentes maneras
El modelado basado en clases
• Representa
– Objetos que manipulará el sistema
– Operaciones que se aplicarán a los objetos para efectuar la
manipulación
– Relaciones entre los objetos
– Colaboraciones que tienen lugar entre las clases definidas
• Elementos
– Clases
– Objetos
– Atributos
– Operaciones
– Modelos clase-responsabilidad-colaborador (CRC)
– Diagramas de colaboración
– Paquetes
• Identificación de las clases de análisis
– Se determinan subrayando cada sustantivo o frase
que las incluya para introducirlo en una tabla
simple
– Deben anotarse los sinónimos
– Espacio de solución, si la clase (sustantivo) se
requiere para implementar una solución
– Espacio del problema, si la clase sólo es necesaria
para describir la solución
Entidades
externas
Estructuras Cosas
¿Cómo se
manifiestan
las clases?
Ocurrencias
Lugares
o eventos
Unidades
organizacionales Roles
• ¿Cómo determino si una clase potencial debe, ser una clase
de análisis?
– Información retenida. La clase potencial será útil durante
el análisis sólo si debe recordarse la información sobre ella
para que el sistema pueda funcionar.
– Servicios necesarios. La clase potencial debe tener un
conjunto de operaciones identificables que cambien en
cierta manera el valor de sus atributos
– Atributos múltiples
– Atributos comunes
– Operaciones comunes
– Requerimientos esenciales
• Especificación de atributos
– Describen una clase que ha sido seleccionada para
incluirse en el modelo de requerimientos
• Definición de las operaciones
– Definen el comportamiento de un objeto
– Se dividen en cuatro categorías principales:
1) Operaciones que manipulan datos en cierta manera
2) Operaciones que realizan un cálculo
3) Operaciones que preguntan sobre el estado de un objeto
4) Operaciones que vigilan un objeto en cuanto a la
ocurrencia de un evento de control
• Modelado clase-responsabilidad-colaborador
– Proporciona una manera sencilla de identificación
y organización de las clases que son relevantes
para los requerimientos de un sistema o producto
– Responsabilidades, son los atributos y operaciones
relevantes para la clase
– Colaboradores, son aquellas clases que se
requieren para dar a una clase la información
necesaria a fin de completar una responsabilidad
Modelado clase-responsabilidad-
colaborador
• Clases-Categorías
– Clases de entidad, se extraen directamente del
enunciado del problema
– Clases de frontera, se utilizan para crear la interfaz
que el usuario mira y con la que interactúa cuando
utiliza el software. Se diseñan con la
responsabilidad de administrar la forma en la que
se presentan a los usuarios los objetos de entidad
– Clases de controlador, administran una “unidad de
trabajo” de principio a fin
colaborador
• Responsabilidades-Lineamientos
– La inteligencia del sistema debe estar distribuida entre
las clases para enfrentar mejor las necesidades del
problema
– Cada responsabilidad debe enunciarse del modo más
general posible
– La información y el comportamiento relacionado con
ella deben residir dentro de la misma clase
– La información sobre una cosa debe localizarse con
una sola clase, y no distribuirse a través de muchas
– Cuando sea apropiado, las responsabilidades deben
compartirse entre clases relacionadas
colaborador
• Colaboraciones
– Se identifican determinando si una clase puede
cumplir cada responsabilidad
– Relación es-parte-de, todas las clases que forman
parte de una clase agregada
– Relación tiene-conocimiento-de, cuando una clase
debe adquirir información de otra
– Relación depende-de, significa que dos clases
tienen una dependencia que no se determina por
tiene-conocimiento-de ni por es-parte-de
• Asociaciones y dependencias
– Asociación, define una relación entre clases
– Multiplicidad, define cuántas de una clase se
relacionan con cuántas de otra clase
– Relación de dependencia, una clase cliente depende
de algún modo de la clase servidor
– Estereotipo, “mecanismo extensible” dentro del UML
que permite definir un elemento especial de
modelado con semántica y especialización
determinadas. En UML se representan entre
paréntesis dobles angulares
• Paquetes de análisis
– Se utiliza para ensamblar un conjunto de
clases relacionadas
– Categorización, se clasifican distintos
elementos del modelo de análisis de
manera que se agrupen en un paquete
al que se da un nombre representativo
– El signo más (suma) que precede al
nombre de la clase de análisis en cada
paquete, indica que las clases tienen
visibilidad pública, por lo que son
accesibles desde otros paquetes
– El signo menos (resta) indica que un
elemento queda oculto desde todos los
demás paquetes
– El símbolo # señala que un elemento es
accesible sólo para los paquetes
contenidos dentro de un paquete dado
Requerimientos que modelan las
estrategias
Análisis estructurado
• Considera como entidades separadas los datos y los procesos que los
transforman
• Los objetos de datos se modelan en una forma que define sus
atributos y relaciones
• Los procesos que manipulan objetos de datos se modelan de una
forma que muestra cómo transforman los datos cuando los objetos
de datos fluyen por el sistema
Análisis orientado a objetos

• Se centra en la definición de clases y en el modo en el que colaboran
una con otra para cumplir con los requerimientos del cliente
Modelado orientado al flujo
Diagrama de flujo de datos
• Adopta un punto de vista del tipo entrada-proceso-

salida para el sistema
• Objetos de datos entran al sistema, son
transformados por elementos de procesamiento y
los objetos de datos que resultan de ello salen del
software
• Permite desarrollar modelos del dominio de la
información y del dominio funcional.
Creación de un modelo de flujo de datos
• El nivel 0 del diagrama debe ilustrar el software o sistema como
una sola burbuja
• Debe anotarse con cuidado las entradas y salidas principales
• La mejora debe comenzar por aislar procesos candidatos, objetos
de datos y almacenamiento de éstos, para representarlos en el
siguiente nivel
• Todas las flechas y burbujas deben etiquetarse con nombres
significativos
• De un nivel a otro, debe mantenerse la continuidad del flujo de
información
• Debe mejorarse una burbuja a la vez
• Creación de un modelo de flujo de control
– Para aplicaciones “motivadas” por eventos y no por datos,
información de control en lugar de reportes o pantallas, información
con mucha atención en el tiempo y el desempeño
– Lineamientos:
 Enlistar todos los sensores que son “leídos” por el software
 Enlistar todas las condiciones de interrupción
 Enlistar todos los “interruptores” que son activados por un operador
 Enlistar todas las condiciones de los datos
 Revisar todos los “aspectos de control” como posibles entradas o salidas de
especificación del control, según el análisis gramatical de sustantivos y verbos que
se aplicó a la narración del procesamiento
 Describir el comportamiento de un sistema con la identificación de sus estados,
identificar cómo se llega a cada estado y definir las transiciones entre estados
 Centrarse en las posibles omisiones
• La especificación de control
– Representa de dos maneras distintas el comportamiento
del sistema
– Contiene:
 Diagrama de estado, especificación secuencial del
comportamiento
 Tabla de activación del programa, especificación combinatoria del
comportamiento
– Describe el comportamiento del sistema, pero no da
información acerca del funcionamiento interno de los
procesos que se activan como resultado de dicho
comportamiento
• La especificación del proceso
– Se utiliza para describir todos los procesos del
modelo del flujo que aparecen en el nivel final de
la mejora
– Incluye:
 Texto narrativo
 Descripción del lenguaje de diseño del programa del
algoritmo del proceso
 Ecuaciones matemáticas
 Tablas o diagramas de actividad UML
Creación de un modelo de
comportamiento
• Modelo de comportamiento
– Indica la forma en la que responderá el software a eventos
o estímulos externos
– Deben seguirse los pasos siguientes:
1. Evaluar todos los casos de uso para entender por completo la
secuencia de interacción dentro del sistema
2. Identificar los eventos que conducen la secuencia de interacción
y que entienden el modo en el que éstos se relacionan con
objetos específicos
3. Crear una secuencia para cada caso de uso
4. Construir un diagrama de estado para el sistema
5. Revisar el modelo de comportamiento para verificar la exactitud
y consistencia
comportamiento
Identificar los eventos con el caso de uso
• Un evento ocurre siempre que el sistema y un actor

intercambian información
• Un evento no es la información que se intercambia,

sino el hecho de que se intercambió la información
• Un caso de uso se estudia para efectos del intercambio

de información
comportamiento
• Representaciones de estado
– Caracterizaciones diferentes de los estados
1. El estado de cada clase cuando el sistema ejecuta su
función
2. El estado del sistema según se observa desde el exterior
cuando realiza su función
– El estado de una clase tiene características tanto
pasivas como activas
– Estado pasivo, estado actual de todos los atributos de
un objeto
– Estado activo, de un objeto indica el estado actual del
objeto conforme pasa por una transformación o
procesamiento continuos
comportamiento
• Representaciones de estado (cont.)
– Diagramas de secuencia
• Indica la forma en la que los eventos provocan
transiciones de un objeto a otro
• Representación del modo en el que los eventos causan
el flujo de uno a otro como función del tiempo
• Versión taquigráfica del caso de uso
• Todos los eventos que causan transiciones entre
objetos del sistema se recopilan en un conjunto de
eventos de entrada y de salida
Patrones para el modelado de
requerimientos
Patrones de software
• Mecanismo para capturar conocimiento del dominio, en forma que
permita que vuelva a aplicarse cuando se encuentre un problema nuevo
• Con frecuencia incorpora una clase, función o comportamiento dentro
del dominio de aplicación
Descubrimiento de patrones de análisis

• Basados en el escenario (casos de uso)
• Orientados a datos (el modelo de datos)
• Basados en clases
• Orientados al flujo
• Comportamiento
Modelado de requerimientos para
webapps
• ¿Cuánto análisis es suficiente? Depende de:
– Tamaño y complejidad del incremento de la
webapp
– Número de participantes
– Tamaño del equipo de la webapp
– Grado en el que los miembros del equipo han
trabajado juntos antes
– Medida en la que el éxito de la organización
depende directamente del éxito de la webapp
webapps
Entrada del modelado de los requerimientos
• Participantes
• Categorías de usuario
• el contexto del negocio
• Las metas definidas de información y aplicación
• Requerimientos generales de webapps
• Los escenarios de uso
webapps
Salida del modelado de los requerimientos
• Modelo de contenido: identifica el espectro completo de contenido que
dará la webapp. El contenido incluye datos de texto, gráficos e imágenes,
video y sonido
• Modelo de interacción: describe la manera en que los usuarios
interactúan con la webapp
• Modelo funcional: define las operaciones que se aplicarán al contenido
de la webapp y describe otras funciones de procesamiento que son
independientes del contenido pero necesarias para el usuario final
• Modelo de navegación: define la estrategia general de navegación para
la webapp
• Modelo de configuración: describe el ambiente e infraestructura en la
que reside la webapp
webapps
• Modelo del contenido de las webapps
– Incluye elementos estructurales que dan un punto de vista importante de los requerimientos del
contenido de una webapp
 Objetos del contenido
 Clases de análisis
 Entidades visibles para el usuario
– El contenido puede desarrollarse antes de la implementación de la webapp, mientras ésta se
construye o cuando ya opera
– Se incorpora por referencia de navegación en la estructura general de la webapp
– Objeto de contenido
 Descripción de un producto en forma de texto
 Pueden almacenarse como archivos separados, incrustarse directamente en páginas web u obtenerse en forma
dinámica de una base de datos
 Es cualquier aspecto de información cohesiva que se presente al usuario final
 Se determinan directamente a partir de casos de uso, estudiando la descripción del escenario respecto de
referencias directas e indirectas al contenido
– Árbol de datos
 Representa una jerarquía de información que se utiliza para describir un componente
 Se desarrolla como un esfuerzo para definir relaciones jerárquicas entre los objetos de contenido y para dar un
medio de revisión del contenido a fin de que se descubran las omisiones e inconsistencias antes de que
comience el diseño
 Sirve como base para diseñar el contenido
webapps
• Modelo de la interacción para webapps
– Se compone de los elementos siguientes:
 Casos de uso
 Diagramas de secuencia
 Diagramas de estado
 Prototipos de la interfaz de usuario
– El formato de la interfaz de usuario, el contenido que presenta, los
mecanismos de interacción que implementa y la estética general de
las conexiones entre el usuario y la webapp tienen mucho que ver con
la satisfacción de éste y con el éxito conjunto del software
– Aunque se afirme que la creación de un prototipo de interfaz de
usuario es una actividad de diseño, es una buena idea llevarla a cabo
durante la creación del modelo de análisis
webapps
• Modelo funcional para las webapps
– Enfrenta dos elementos de procesamiento de la webapp,
cada uno de los cuales representa un nivel distinto de
abstracción del procedimiento:
1) Funciones observables por los usuarios que entrega la webapp a
éstos
2) Las operaciones contenidas en las clases de análisis que
implementan comportamientos asociados con la clase
– En un nivel más bajo de abstracción del procedimiento,
describe el procesamiento que se realizará por medio de
operaciones de clase de análisis
– En el nivel de análisis, los diagramas de actividades deben
usarse sólo donde la funcionalidad sea relativamente
compleja
webapps
• Lista de atributos del lado del

Modelos de servidor y del lado del cliente
configuración
• Diagrama de despliegue UML, se
para las utiliza en situaciones en las que
webapps deben considerarse arquitecturas
de configuración compleja
webapps
• Modelado de la navegación
– Se considera cómo navegará cada categoría de usuario de un elemento de la webapp a otro
– La mecánica de navegación se define como parte del diseño
– Debe centrarse la atención en los requerimientos generales de navegación
– Preguntas:
• ¿Ciertos elementos deben ser más fáciles de alcanzar que otros? ¿Cuál es la prioridad de presentación?
• ¿Debe ponerse el énfasis en ciertos elementos para forzar a los usuarios a navegar en esa dirección?
• ¿Cómo deben manejarse los errores en la navegación?
• ¿Debe darse prioridad a la navegación hacia grupos de elementos relacionados y no hacia un elemento
específico?
• ¿La navegación debe hacerse por medio de vínculos, acceso basado en búsquedas o por otros medios?
• ¿Debe presentarse a los usuarios ciertos elementos con base en el contexto de acciones de navegación previas?
• ¿Debe mantenerse un registro de usuarios de la navegación?
• ¿Debe estar disponible un mapa completo de la navegación en cada punto de la interacción del usuario?
• ¿El diseño de la navegación debe estar motivado por los comportamientos del usuario más comunes y
esperados o por la importancia percibida de los elementos definidos de la webapp?
• ¿Un usuario puede “guardar” su navegación previa a través de la webapp para hacer expedito el uso futuro?
• ¿Para qué categoría de usuario debe diseñarse la navegación óptima?
• ¿Cómo deben manejarse los vínculos externos hacia la webapp? ¿Con la superposición de la ventana del
navegador existente? ¿Como nueva ventana del navegador? ¿En un marco separado?
Software
Ingeniería del Diseño
• Principios:
– Resistencia: Un programa no debe tener ningún error que impida su
funcionamiento.
– Funcionalidad: Un programa debe se apropiado para los fines que
persigue.
– Belleza: La experiencia de usar el programa debe ser placentera.
• Objetivo:
– Producir un modelo o representación que tenga Resistencia,
Funcionalidad y Belleza.
– Esto se logra a través de dos elementos:
o Diversificación y convergencia, las cuales se basan en:
 Experiencia
 Principios
 Criterios
 Proceso de iteración
El diseño de software se ubica en el área técnica de la
ingeniería de software y se aplica sin importar el modelo
del proceso que se utilice
El diseño de software comienza una vez que se han

analizado y modelado los requerimientos
El diseño de software es la última acción de la ingeniería

de software dentro de la actividad de modelado y prepara
la etapa de construcción
Modelo de Análisis
Elementos basados en Elementos orientados al
escenarios flujo
• Casos de uso - texto • Diagramas de flujo de Diseño en el nivel de
• Diagramas de caso de uso datos
• Diagramas de actividad • Diagramas de flujo de componentes
• Diagramas de carril control
• Narrativas de
procesamiento Diseño de interfaz
Elementos basados en Elementos de Diseño arquitectónico

clases comportamiento
• Diagramas de clase • Diagramas de estado

• Paquetes de análisis • Diagramas de secuencia Diseño de datos/ clase
• Modelos CRC
• Diagramas de colaboración
Modelo del Diseño

Por qué es tan importante el diseño?

• La importancia del diseño del software puede describirse con una sola
palabra calidad.
• Es la etapa en la que se fomentará la calidad en la ingeniería de
software.
• Proporciona las representaciones del software susceptibles de evaluar
respecto de la calidad.
• Es la única forma en que, de manera exacta, un requisito del cliente se
puede convertir en un sistema o producto de software terminado.
• Sirve como fundamento para todas las actividades subsecuentes de la
ingeniería del software y del soporte de este.
El Proceso de Diseño
Proceso del diseño
• Es un proceso iterativo mediante el cual los requisitos se traducen en
un "plano" para construir el software.
Características para evaluar un buen diseño

• Debe implementar todos los requisitos explícitos contenidos en el
modelo de análisis, y debe ajustarse a todos los requisitos implícitos
que desea el cliente.
• Debe ser una guía legible y comprensible para quienes generan
código y quienes realizan pruebas y, en consecuencia, dan soporte al
software.
• Debe proporcionar una imagen completa del software desde una
perspectiva de implementación.
Lineamientos de calidad
• Debe presentar una estructura arquitectónica
• Debe ser modular
• Debe contener distintas representaciones de los datos, la arquitectura, las
interfaces y los componentes
• Debe conducir a estructuras de datos que sean apropiadas para las clases que
habrán de implementarse y que procedan de patrones de datos reconocibles
• Debe conducir a componentes que presenten características funcionales
independientes
• Debe conducir a interfaces que reduzcan la complejidad de las conexiones entre
los componentes y el ambiente externo
• Debe obtenerse por medio de un método repetible que se base en la
información obtenida durante el análisis de requisitos del software
• Debe representarse por medio de una notación que comunique de manera
eficaz su significado
Atributos de calidad
• Funcionalidad, conjunto de características y capacidades del

programa, la generalidad de las funciones que se entregan y la
seguridad general del sistema
• Usabilidad, factores humanos, estética general, consistencia y
documentación
• Confiabilidad, frecuencia y gravedad de las fallas, exactitud de los
resultados que salen, el tiempo medio para que ocurra una falla,
capacidad de recuperación ante ésta y lo predecible del programa
• Rendimiento, velocidad de procesamiento, tiempo de respuesta,
uso de recursos, conjunto y la eficiencia
• Mantenibilidad, capacidad del programa para ser ampliable,
adaptable y servicial, que pueda probarse, compatible y
configurable, facilidad para instalarse en el sistema y para que se
detecten los problemas
La evolución
del diseño del Métodos para
software es traducir el
un proceso flujo de datos
continuo que o la estructura
ya ha cubierto de éstos a una Métodos
casi seis definición de orientados al
décadas diseño aspecto
Programación Enfoque Desarrollo

estructurada orientado a orientado al
objeto para modelo y a las
diseñar pruebas
derivaciones
1. Un mecanismo para traducir el

modelo de requerimientos en
una representación del diseño ¿Qué características son
2. Una notación para representar comunes en todos los
las componentes funcionales y
métodos de diseño?
sus interfaces
3. Una heurística para mejorar y
hacer particiones
4. Lineamientos para evaluar la
calidad
Conceptos de Diseño
Abstracción Es una de las formas fundamentales en
las que el humano se enfrenta a la
complejidad
Abstracción de Secuencia de instrucciones que tiene
Procedimiento
una función específica y limitada
Abstracción de Es una colección nombrada de datos

Datos
que describe un objeto de datos
Arquitectura del software
•Estructura general del software y las formas en que la estructura proporciona una integridad conceptual para un sistema
•Estructura u organización de los componentes del programa
•La manera en que estos componentes interactúan
•Estructura de datos que utilizan los componentes
Propiedades del diseño de la arquitectura
•Propiedades estructurales, define los componentes de un sistema y la manera en la que están agrupados e interactúan
unos con otros
•Propiedades extrafuncionales, cómo se satisface los requerimientos de desempeño, capacidad, confiabilidad, seguridad
y adaptabilidad, así como otras características del sistema
•Familias de sistemas relacionados, el diseño debe tener la capacidad de reutilizar bloques de construcción
arquitectónica
Modelos del diseño arquitectónico
•Modelos estructurales, representan la arquitectura como un conjunto organizado de componentes del programa
•Modelos del marco de trabajo, aumentan el nivel de abstracción del diseño, al tratar de identificar patrones de diseño
arquitectónico repetibles que se encuentran en tipos similares de aplicaciones
•Modelos dinámicos, abordan los aspectos estructurales de la arquitectura del programa e indican cómo cambia la
estructura o la configuración del sistema en función de eventos externos
•Modelos del proceso, se centran en el diseño del negocio o proceso técnico al que debe dar acomodo el sistema
•Modelos funcionales, se usan para representar la jerarquía funcional de un sistema
• Patrón de diseño
– Describe una estructura de diseño que resuelve un
problema de diseño particular dentro de un contexto
específico y en medio de "fuerzas" que pueden tener un
impacto en la manera en que se aplica y utiliza el patrón
• Objetivo
– Proporcionar una descripción que le permita al diseñador
determinar si el patrón:
1) Es aplicable al trabajo en cuestión
2) Se puede reutilizar
3) Sirve como guía para desarrollar un patrón distinto en funciones
o estructura
• División de problemas
– Cualquier problema complejo puede manejarse con más facilidad si se subdivide en elementos
susceptibles de resolverse u optimizarse de manera independiente
o Problema, característica o comportamiento que se especifica en el modelo de los requerimientos para el
software
• Modularidad
– El software se divide en componentes (módulos) con nombres independientes y que es posible
abordar en forma individual
– Atributo particular del software que permite que un programa sea manejable de manera intelectual
• Ocultación de información
– Sugiere que los módulos se caracterizan por las decisiones de diseño que cada uno oculta a los otros
– Los módulos deben especificarse y diseñarse de manera que la información que está dentro del
módulo sea inaccesible para otros módulos que no necesiten esa información
– El ocultamiento define y fortalece las restricciones de acceso para los detalles de procedimiento
dentro de un módulo y para cualquier estructura de datos local que utilice el módulo
• Independencia funcional
– Debe diseñarse software de manera que cada módulo resuelva un
subconjunto específico de requerimientos y tenga una interfaz sencilla cuando
se vea desde otras partes de la estructura del programa
– El software es más fácil de desarrollar porque su función se subdivide y las
interfaces se simplifican
– Son más fáciles de mantener debido a que los efectos secundarios causados
por el diseño o por la modificación del código son limitados, se reduce la
propagación del error y es posible obtener módulos reutilizables
– Es una clave para el buen diseño y éste es la clave de la calidad del software
– Se evalúa aplicando dos criterios cualitativos:
• Cohesión: indicador de la fortaleza relativa funcional de un módulo
• Acoplamiento: independencia relativa entre módulos
– Un módulo cohesivo ejecuta una sola tarea, por lo que requiere interactuar
poco con otros componentes en otras partes del programa
– En el diseño de software, debe buscarse el mínimo acoplamiento posible
Refinamiento
- Es una estrategia de diseño descendente . Es un proceso de elaboración
- El desarrollo de un programa se realiza al refinar de manera sucesiva los niveles de detalle
procedimentales
- Ayuda al diseñador a revelar los detalles de grado menor mientras se realiza el diseño
Aspectos
- Representación de una preocupación de interferencia
- Es importante identificar aspectos, de modo que el diseño les pueda dar acomodo
conforme sucede el refinamiento y la división en módulos
Rediseño
- Técnica de reorganización que simplifica el diseño de un componente sin cambiar su función
o comportamiento
- Es el proceso de cambiar un sistema de software de tal forma que no se altere el
comportamiento externo de su código y aún así se mejore su estructura interna
• Clases de diseño
– Permite refinar las clases de análisis al proporcionar detalles del diseño que permitirán
la implementación de las clases
– Permite producir un conjunto nuevo de clases de diseño que implementen una
infraestructura de software para soportar la solución del negocio
• Tipos de clases
– Clases de interfaz con el usuario, definen todas las abstracciones necesarias para la
interacción humano-computadora
– Clases del dominio de negocios, identifican los atributos y servicios necesarios para
implementar algún elemento del dominio de negocios
– Clases de proceso, implementan abstracciones del negocio en un nivel más bajo, las
cuales se requieren para manejar por completo las clases del dominio de negocios
– Clases persistentes, representan almacenamientos de datos que persistirán más allá de
la ejecución del software
– Clases de sistema, implementan las funciones de gestión y control de software que
permiten que el sistema opere y se comunique dentro de su entorno de computación y
con el mundo exterior
• Características clase de diseño bien formada
– Completa y suficiente, una clase de diseño debe ser la encapsulación
completa de todos los atributos y métodos que se pueden esperar, en
forma razonable, que existan por clase
– Primitivismo, los métodos asociados con una clase de diseño deben
enfocarse en el cumplimiento de un servicio para la clase. Una vez que
el servicio ha sido implementado con un método, la clase no debe
proporcionar otra forma de complementar la misma cosa
– Cohesión alta, una clase de diseño cohesiva tiene un conjunto de
responsabilidades pequeño y enfocado, y aplica atributos y métodos
de manera sencilla para implementar dichas responsabilidades
– Acoplamiento bajo, Dentro del modelo de diseño es necesario que las
clases de diseño colaboren con alguna otra. La colaboración se debe
mantener en un mínimo aceptable. Si un modelo de diseño tiene un
acoplamiento alto, el sistema es difícil de implementar, probar y
mantener a través del tiempo
El Modelo del Diseño
• Dimensión del proceso
– Indica la evolución del modelo del diseño
conforme se ejecutan las tareas de éste como
parte del proceso del software
• Dimensión de la abstracción
– Representa el nivel de detalle a medida que cada
elemento del modelo de análisis se transforma en
un equivalente de diseño y luego se mejora en
forma iterativa
• Elementos del diseño de datos
– En ocasiones denominado arquitectura de datos
– Crea un modelo de datos o información que se
representa en un nivel de abstracción elevado
– La estructura de los datos y algoritmos requeridos
para manipular los datos – Nivel de componentes
– Traducción de un modelo de datos a una base de
datos – Nivel de aplicación
– Conjunto de información almacenada en bases de
datos incompatibles y reorganizados en un “data
warehouse” – Nivel de negocios
• Elementos del diseño arquitectónico
– Conjunto de sistemas interconectados, obtenidos de paquetes de análisis
dentro del modelo de requerimientos
– Fuentes:
• Información sobre el dominio de la aplicación del software que se va a elaborar
• Elementos específicos del modelo de requerimientos, sus relaciones y
colaboraciones para el problema en cuestión
• La disponibilidad de estilos arquitectónicos y sus patrones
• Elementos de diseño de la interfaz

– Elementos:
• Interfaz de usuario (UI)
• Interfaces externas que tienen que ver con otros sistemas, dispositivos, redes y
otros productores o consumidores de información
• Interfaces internas que involucran a los distintos componentes del diseño
• Elementos del diseño en el nivel de los
componentes
– Un componente se representa en forma de
diagrama UML
– Se utiliza un diagrama de actividades UML para
representar la lógica del procesamiento
– El flujo detallado del procedimiento para un
componente se representa con seudocódigo
– La estructura algorítmica sigue las reglas
establecidas para la programación estructurada
• Elementos del diseño del despliegue
– Indican la forma en la que se acomodarán la
funcionalidad del software y los subsistemas
dentro del ambiente físico de la computación que
lo apoyará
– Se indican los subsistemas (funcionalidad)
– Formato descriptor, el diagrama de despliegue
muestra el ambiente de computación, pero no
indica de manera explícita los detalles de la
configuración
Diseño Arquitectónico
• Qué es la arquitectura del software?
– Es la estructura o las estructuras del sistema, que incluyen los
componentes del software, las propiedades visibles externamente de
esos componentes y las relaciones entre ellos.
– Es una representación que permite que un ingeniero del software:
1) Analice la efectividad del diseño para cumplir con los requisitos
establecidos.
2) Considere opciones arquitectónicas en una etapa en que aún resulta
relativamente fácil hacer cambios al diseño.
3) Reduzca los riesgos asociados con la construcción del software.
– Componente de software es un módulo del programa o una clase
orientada a objetos, e incluye bases de datos y middleware que
permita configurar una red de clientes y servidores.
• Arquitectura del software
– El diseño de Ia arquitectura del software considera
dos niveles de Ia pirámide del diseño:
Diseño de datos, permite representar el componente
de datos de la arquitectura en sistemas convencionales
y definiciones de clase de los sistemas orientados a
objetos
 Diseño arquitectónico, se concentra en Ia
representación de Ia estructura de los componentes del
software, sus propiedades e interacciones.
• Por qué es importante la arquitectura?
– Permiten la comunicación entre todas las partes
interesadas en el desarrollo de un sistema de cómputo.
– Destaca las decisiones iniciales relacionadas con el diseño

que tendrán un impacto profundo en todo el trabajo de la
ingeniería del software que le sigue y en el éxito final del
sistema como entidad operacional.
– Constituye un modelo relativamente pequeño e

intelectualmente comprensible de como está estructurado
el sistema y como trabajan juntos sus componentes
• Descripciones arquitectónicas
– Es un conjunto de productos del trabajo que
reflejan puntos de vista distintos del sistema
– Perspectiva, representación del sistema completo

desde el punto de vista de un conjunto de
preocupaciones relacionadas de un participante
– Punto de vista, especificación de las convenciones

para construir y usar una perspectiva
Géneros Arquitectónicos
Inteligencia Simulan o incrementan la cognición humana, su locomoción u otros procesos orgánicos
artificial:
Comerciales y no Fundamentales para la operación de una empresa de negocios
lucrativos:
Comunicaciones: Proveen la infraestructura para transferir y manejar datos, para conectar usuarios de
éstos o para presentar datos en la frontera de una infraestructura
Contenido de Se emplean para crear o manipular artefactos de texto o multimedios

autor:
Dispositivos: Interactúan con el mundo físico a fin de brindar algún servicio puntual a un individuo
Entretenimiento y Administran eventos públicos o proveen una experiencia grupal de entretenimiento

deportes:
Financieros: Proporcionan la infraestructura para transferir y manejar dinero y otros títulos
Juegos: Dan una experiencia de entretenimiento a individuos o grupos

Géneros Arquitectónicos
Gobierno: Dan apoyo a la conducción y operaciones de una institución política local, estatal, federal, global o de otro tipo
Industrial: Simulan o controlan procesos físicos
Legal: Dan apoyo a la industria jurídica
Médicos: Diagnostican, curan o contribuyen a la investigación médica
Militares: Consulta, comunicaciones, comando, control e inteligencia, así como de armas ofensivas y defensivas
Sistemas operativos: Están inmediatamente instalados en el hardware para dar servicios de software básico
Plataformas: Se encuentran en los sistemas operativos para brindar servicios avanzados
Científicos: Se emplean para hacer investigación científica y aplicada
Herramientas: Se utilizan para desarrollar otros sistemas
Transporte: Controlan vehículos acuáticos, terrestres, aéreos o espaciales
Utilidades: Interactúan con otro software para brindar algún servicio específico
Estilos Arquitectónicos
• Estilos arquitectónicos
– Mecanismo descriptivo
– Plantilla para la construcción
– Describe una categoría de sistemas
• Objetivo
– Establecer una estructura para todos los componentes del sistema
• Los estilos arquitectónicos abarcan:
 Conjunto de componentes, que realizan una función requerida por el sistema
 Conjunto de conectores, que permiten la comunicación, coordinación y
cooperación entre los componentes
 Restricciones, que definen cómo se integran los componentes para formar el
sistema
 Modelos semánticos, que permiten a un diseñador, mediante el análisis de las
propiedades conocidas de las partes que lo integran, comprender las
propiedades generales de un sistema
• Arquitectura centrada en datos
– Un almacén de datos se encuentra en el centro; otros componentes tienen
acceso a él y cuentan con la opción de actualizar, agregar, eliminar o modificar
los datos
• Arquitectura de flujo de datos

– Se aplica cuando los datos de entrada se habrán de transformar en datos de
salida mediante una serie de componentes para el cálculo o la manipulación
• Arquitectura de llamada y retorno

– Permite que un diseñador de software obtenga una estructura de programa
que resulta relativamente fácil modificar y cambiar de tamaño
• Arquitectura orientada a objetos
– Encapsulan los datos y las operaciones que deben aplicarse para manipular los
datos
• Arquitectura en capas
– Hay varias capas definidas; cada una de ellas realiza operaciones que se
acercan progresivamente al conjunto de instrucciones de la máquina
• Capa externa, los componentes sirven a las operaciones de interfaz de usuario
• Capa interna, los componentes sirven como interfaz con el sistema operativo
• Capas intermedias, proporcionan servicios de utilería y de software de

aplicaciones
Patrones arquitectónicos
– Se abocan a un problema de aplicación específica
dentro de un contexto dado y sujeto a
limitaciones y restricciones
• Conjunto de criterios de diseño para evaluar un diseño arquitectónico
– Control.
 Cómo se maneja el control dentro de la arquitectura?
 Existe una jerarquía de control distintiva y si es así, cuál es la función de los componentes
dentro de esta jerarquía de control?
 Cómo transfieren los campos el control dentro del sistema?
 Cómo se comparte el control entre los componentes?
 Cuál es la topología del control?
 Está sincronizado el control o los componentes operan asincrónicamente?
– Datos.
• Cómo se comunican los datos entre los componentes?
• El flujo de datos es continuo o los objetos de datos se pasan esporádicamente al sistema?
• Cuál es el modo de transferencia de los datos?
• Existen componentes de datos, y de ser así, cuál es su papel?
• Cómo interactúan los componentes funcionales con los de datos?
• Los componentes de datos son pasivos o activos?
• Cómo interactúan los datos y el control dentro del sistema?
• Representación del sistema en el contexto
– Diagrama de contexto del sistema
• Representa el flujo de la información dentro y fuera del sistema, la información del
usuario y el procesamiento relevante de soporte.
• Modela la manera en que el software interactuará con las entidades ubicadas mas
allá de sus limites.
– Sistemas superiores: Utilizan al sistema objetivo como parte de algún
esquema de procesamiento de alto nivel
– Sistemas subordinados: Usados por el sistema objetivo y proveen
datos o procesamiento que son necesarios para completar las
funciones del sistema objetivo
– Sistemas entre iguales: Interactúan sobre una base de igualdad
– Actores: entidades que interactúan con el sistema objetivo mediante
la producción o consumo de información que es necesaria para el
procesamiento de los requerimientos
Definición de arquetipos
• Es una clase o un patrón que representa una abstracción central

importantísima en el diseño de una arquitectura para el sistema de
destino
Refinamiento de la arquitectura en componentes
• Dominio de la aplicación
• Dominio de la infraestructura
Instancia de Ia arquitectura
• La arquitectura se aplica a un problema específico con el propósito de

demostrar que la estructura y los componentes son apropiados
Evaluación de las arquitecturas de
software
• Método de la negociación para analizar la arquitectura
– Escenarios de investigación. Se desarrolla un conjunto de casos de
uso
– Obtención de los requerimientos y restricciones, y descripción del
ambiente
– Descripción de los estilos o patrones de arquitectura elegidos para
abordar los escenarios y requerimientos
– Evaluación de los atributos de calidad, considerando cada atributo
por separado
– Identificación de la sensibilidad de los atributos de calidad de
varios atributos arquitectónicos para un estilo de arquitectura
específico
– Crítica de las arquitecturas candidatas
software
• Complejidad arquitectónica
– Una técnica útil para evaluar la complejidad general de una
arquitectura determinada consiste en considerar las dependencias
entre componentes dentro de la arquitectura.
• Tipos de dependencias:
– Dependencias compartidas, representan relaciones de dependencia
entre consumidores que usan el mismo recurso o los productores que
producen para los mismos consumidores.
– Dependencias de flujo, representan las relaciones de dependencia
entre productores y consumidores de recursos.
– Dependencias de restricción, representan restricciones al flujo relativo
de control entre un conjunto de actividades.
software
Lenguajes de descripción arquitectónica
• Proporciona una semántica y una sintaxis para

describir una arquitectura del software
• Proporcionar al diseñador la capacidad de separar

componentes arquitectónicos, de integrar
componentes individuales en bloques arquitectónicos
mayores y de representar interfaces entre
componentes
• Flujo de transformación
– Trayectoria de flujo de entrada. Los datos se
transforman de una representación del mundo
exterior a una forma internalizada
– Centro de transformación. Los datos se procesan
– Trayectoria de flujo de salida. Transforma los datos

a una forma del mundo exterior
Mapeo de la Arquitectura
• Mapeo de Transformación
– Es un conjunto de pasos de diseño que permite que un Diagrama de Flujo de Datos
(DFD) con características de flujo de transformación se correlacione con un estilo
arquitectónico específico
• Pasos de diseño
– Paso 1. Revisar el modelo fundamental del sistema
– Paso 2. Revisar y refinar los diagramas de flujo de datos para el software
– Paso 3. Determinar si el DFD tiene características de flujo de transformación o de
transacción
– Paso 4. Aislar el centro de transformación al especificar límites de flujo de entrada y
salida
– Paso 5. Realizar una factorización de primer nivel. La factorización genera una estructura
de programa en que los componentes descendentes se encargan de la toma de
decisiones ylos componentes de bajo nivel realizan más trabajo de entrada, cálculo y
salida
– Paso 6. Realice una "factorización de segundo nivel"
– Paso 7. Refinar la arquitectura de primera iteración empleando diseño heurístico para
mejorar la calidad del software
Mapeo de la Arquitectura
Refinamiento del diseño arquitectónico
• Debe estimularse el refinamiento de la arquitectura

del software durante las primeras etapas del diseño
• Debe perseguir el menor número de componentes

que sea consistente con la modularidad efectiva y la
estructura de datos menos compleja que cumpla de
modo adecuado con los requerimientos de
información
Diseño en el Nivel de Componentes
¿Qué es?
Define las estructuras de datos, algoritmos,

características de la interfaz y mecanismos de
comunicación asignados a cada componente del
software
• ¿Qué es un componente?
– Es un bloque de construcción de software de cómputo
– Parte modular, desplegable y sustituible de un
sistema, que incluye la implantación y expone un
conjunto de interfaces
– Forman la arquitectura del software
– Juegan un papel en el logro de los objetivos y de los
requerimientos del sistema que se va a construir
– Deben comunicarse y colaborar con otros
componentes y con entidades que existen fuera de las
fronteras del software
Visión orientada a objetos
• Un componente contiene un conjunto de clases que

colaboran
Visión relacionada con el proceso
• El componente se diseña desde la nada

• Se crea un nuevo componente con base en las
especificaciones obtenidas del modelo de
requerimientos
• Visión tradicional
– Un componente es un elemento funcional de un programa
que incorpora la lógica del procesamiento, las estructuras
de datos internas que se requieren para implantar la lógica
del procesamiento y una interfaz que permite la
invocación del componente y el paso de los datos
– Módulo
o Componente de control, coordina la invocación de todos los
demás componentes del dominio del problema
o Componente del dominio del problema, implanta una función
completa o parcial que requiere el cliente
o Componente de infraestructura, responsable de las funciones que
dan apoyo al procesamiento requerido en el dominio del problema
Diseño de Componentes
Basados en Clase
• Principios básicos del diseño
– Principio Abierto-Cerrado. Debe especificarse el
componente en forma tal que permita extenderlo sin
necesidad de hacerle modificaciones internas
– Principio de sustitución de Liskov. Cualquier clase
derivada de una clase de base debe respetar cualquier
contrato implícito entre la clase de base y los componentes
que la usan
– Principio de Inversión de la Dependencia. Las
abstracciones son el lugar en el que es posible ampliar un
diseño sin muchas dificultades
– Principio de segregación de la interfaz. Es mejor tener
muchas interfaces específicas del cliente que una sola de
propósito general
Basados en Clase
• Principios básicos del diseño (cont.)
– Principio de equivalencia de la liberación de la
reutilización. El gránulo de reutilización es el
gránulo de liberación
– Principio de cierre común. Las clases que cambian
juntas pertenecen a lo mismo
– Principio de la reutilización común. Las clases que
no se reutilizan juntas no deben agruparse juntas
Basados en Clase
¿Qué es lo que hay que tomar en cuenta al dar nombre
a los componentes?
• Componentes. Deben establecerse convenciones para
dar nombre a los componentes. Deben provenir del
dominio del problema y significar algo para todos los
participantes que vean el modelo arquitectónico
• Interfaces. Dan información importante sobre la
comunicación y la colaboración
• Dependencias y herencia. Modelar las dependencias
de izquierda a derecha y la herencia de abajo hacia
arriba
Basados en Clase
Cohesión
• Implica que un componente o clase sólo contiene atributos y
operaciones que se relacionan de cerca uno con el otro y con la
clase o componente en sí
Tipos de cohesión
• Funcional. Ocurre cuando un componente realiza un cálculo y
luego devuelve el resultado
• De capa. Ocurre cuando una capa más alta accede a los servicios
de otra más baja, pero ésta no tiene acceso a las superiores
• De comunicación. Las clases se centran únicamente en los datos
en cuestión, acceden a ellos y los guardan
Basados en Clase
Acoplamiento
• Es la medición cualitativa del grado en el que

las clases se conectan una con otra
• Conforme las clases (y componentes) se
hacen más interdependientes, el
acoplamiento crece
• Un objetivo importante del diseño en el nivel
de componente es mantener el acoplamiento
tan bajo como sea posible
Basados en Clase
• Categorías de acoplamiento
– Acoplamiento de contenido. Tiene lugar cuando un
componente modifica datos internos en otro componente
– Acoplamiento común. Sucede cuando cierto número de
componentes hacen uso de una variable global
– Acoplamiento del control. Tiene lugar si la operación A( )
invoca a la operación B( ) y pasa una bandera de control a
B. La bandera dirige el flujo de la lógica dentro de B
– Acoplamiento de molde. Se presenta cuando se declara a
ClaseB como un tipo para un argumento de una operación
de ClaseA
Basados en Clase
• Categorías de acoplamiento (cont.)
– Acoplamiento de datos. Ocurre si las operaciones pasan
cadenas largas de argumentos de datos
– Acoplamiento de rutina de llamada. Tiene lugar cuando
una operación invoca a otra
– Acoplamiento de tipo de uso. Ocurre si el componente A
usa un tipo de datos definidos en el componente B
– Acoplamiento de inclusión o importación. Pasa cuando el
componente A importa o incluye un paquete o el
contenido del componente B.
– Acoplamiento externo. Sucede si un componente se
comunica o colabora con componentes de infraestructura
• Pasos
– Identificar todas las clases de diseño que correspondan al
dominio del problema
– Identificar todas las clases de diseño que correspondan al
dominio de la infraestructura
– Elaborar todas las clases de diseño que no sean
componentes reutilizables
– Especificar detalles del mensaje cuando colaboren clases o
componentes
– Identificar interfaces apropiadas para cada componente
– Elaborar atributos y definir tipos y estructuras de datos
requeridos para implantarlos
– Pasos (cont.)
• Describir en detalle el flujo del procesamiento dentro
de cada operación
• Describir las fuentes persistentes de datos e identificar
las clases requeridas para administrarlos
• Desarrollar y elaborar representaciones del
comportamiento para una clase o componente
• Elaborar diagramas de despliegue para dar más detalles
de la implantación
• Rediseñar cada representación del diseño en el nivel de
componentes y siempre considerar alternativas
para Webapps
Componente de webapp
• Función cohesiva bien definida que manipula contenido o da

procesamiento de cómputo o de datos para un usuario final
• Paquete cohesivo de contenido y funciones que brindan al
usuario final alguna capacidad solicitada
Diseño del contenido en el nivel de componente
• Se centra en objetos de contenido y en la forma en la que se

empacan para su presentación a un usuario final de webapps
• La formalidad debe adaptarse a las características de la webapp
que se va a elaborar
para Webapps
• Funciones de las Webapps
– Producen un procesamiento localizado que genera
contenido y capacidad de navegación en forma dinámica
– Dan capacidad de computación o procesamiento de datos
que resultan adecuados para el dominio del negocio de la
webapp
– Brindan consultas y acceso avanzado a una base de datos
– Establecen interfaces de datos con sistemas corporativos
externos
– Arquitectura funcional, representación del dominio de
funciones de la webapp y describe los componentes
funcionales clave de la webapp y la forma en la que
interactúan una con otra
Diseño de Componentes Tradicionales
Secuencia
• Implementa pasos de procesamiento que son esenciales en la

especificación de cualquier algoritmo
Condición
• Proporciona el medio para seleccionar un procesamiento con

base en algún suceso lógico
Repetición
• Permite la ejecución de lazos

Notación gráfica de diseño
Notación del diseño tabular
• Las tablas de decisión, proporcionan una notación que traduce las acciones y
condiciones a una forma tabular
¿Cómo elaboro una tabla de decisión?
• Enlistar todas las acciones asociadas con un procedimiento específico
• Enlistar todas las condiciones durante la ejecución del procedimiento
• Asociar conjuntos específicos de condiciones con acciones específicas, con la
eliminación de las combinaciones o con condiciones imposibles; de manera
alternativa, desarrollar toda posible permutación de las condiciones.
• Definir reglas indicando qué acciones suceden para un conjunto dado de
condiciones
Lenguaje de diseño del programa

• incorpora la estructura lógica de un lenguaje de programación y la
expresividad de forma libre de un lenguaje natural
Desarrollo Basado en Componentes
• Ingeniería de software basada en componentes
– Es un proceso que pone el énfasis en el diseño y construcción de sistemas
basados en computadora que emplean componentes reutilizables de software
• Preguntas:
– ¿Es posible construir sistemas complejos con el ensamble de componentes
reutilizables de software procedentes de un catálogo?
– ¿Se logra esto en forma eficaz en cuanto a costo y tiempo?
– ¿Pueden establecerse incentivos apropiados que estimulen a los ingenieros de
software a reutilizar, más que a reinventar?
– ¿La dirección está dispuesta a incurrir en los gastos adicionales asociados a la
creación de componentes de software reutilizables?
– ¿Es posible crear la biblioteca de componentes necesarios para conseguir la
reutilización en forma tal que sea accesible a quienes los necesitan?
– ¿Quienes necesitan los componentes que ya existen pueden encontrarlos?
Ingeniería del dominio

• Identifica, construye, cataloga y disemina un conjunto de
componentes de software que sean aplicables al software
existente y al del futuro en un dominio particular de aplicaciones
Los pasos de este proceso

• Definir el dominio que se va a investigar
• Clasificar los aspectos extraídos del dominio
• Reunir una muestra representativa de aplicaciones en el dominio
• Analizar cada aplicación en la muestra y definir clases de análisis
• Desarrollar un modelo de los requerimientos para las clases.
Calificación de componentes
• Garantiza que un componente candidato ejecute la función requerida, encaje en forma
adecuada en el estilo arquitectónico especificado para el sistema y tenga las
características de calidad que se requieren para la aplicación
Factores que se consideran durante la calificación de componentes

• Aplicación de programación de la interfaz (API)
• Herramientas de desarrollo e integración requeridas por el componente
• Requerimientos durante la puesta en marcha, incluidos el uso de recursos, sincronía o
velocidad y protocolo de redes
• Requerimientos de servicio, incluidos interfaces del sistema operativo y apoyo de otros
componentes
• Características de seguridad, incluidos controles de acceso y protocolo de
autentificación
• Suposiciones incrustadas en el diseño, incluido el empleo de algoritmos específicos
• Manejo de excepciones
• Adaptación de componentes
– Envoltura de caja blanca. Cuando un equipo de
software tiene acceso total al diseño y código interno
de un componente
– Envoltura de caja gris. Cuando la biblioteca de
componentes proporciona un lenguaje de extensión
del componente o API que permite que los conflictos
se eliminen o se anulen
– Envoltura de caja negra. Requiere la introducción de
procesamiento previo y posterior en la interfaz del
componente para eliminar o anular los conflictos
Combinación de componentes
• Ensambla componentes calificados, adaptados y con la ingeniería necesaria para

incluirse en la arquitectura establecida para una aplicación
Análisis y diseño para la reutilización
• El modelo de requerimientos se analiza para determinar qué elementos apuntan

hacia componentes reutilizables ya existentes
Aspectos clave para la reutilización
• Datos estándar. El dominio de la aplicación debe investigarse y tienen que

identificarse las estructuras de datos globales estándar
• Protocolos de interfaz estándar
• Plantillas de programa. Se elige un estilo arquitectónico que sirve como plantilla
para el diseño de la arquitectura del nuevo software
Clasificación y recuperación de componentes

• Concepto. Descripción de lo que hace el componente
• Contenido. Describe cómo se lleva a cabo el concepto
• Contexto. Coloca un componente de software
reutilizable en su dominio de aplicabilidad
• Biblioteca de reutilización. Es un elemento de un
repositorio mayor de software y brinda herramientas
para el almacenamiento de componentes de software,
así como una amplia variedad de productos finales
reutilizables
Cuándo Utilizar un <<include>> y <<extend>>
Casos a incluir y casos a extender
Un tema que genera mucha polémica entre la gente que modela casos de uso es la
elección entre la relación de <<include>> y <<extend>>. Lo peor es que muchas de esas
discusiones generan muy poco valor en el resultado final en el modelo y en cambio
quitan tiempo valioso del proyecto. Esto se debe a que dichas relaciones, muchas veces
no son del todo comprendidas por la persona que la modela, y mucho menos son
comprendidas por las personas que leen el modelo. Así que al final no se le saca el
provecho que en todo caso debería de tener dicha elección.
Es mejor mantener el modelo simple, incluso si esto significa utilizar menos elementos
gráficos de UML, si eso va a facilitar el modelado y la comunicación en el proyecto.
Pero, después de todo este tiempo y de los diferentes temas que hemos venido tratando,
es importante avanzar y adentrarnos en algunos pormenores del lenguaje unificado.
Antes que todo, ¿qué es el “include” y el “extend”?
Gráficamente lo que mostramos es una relación de dependencia entre el par de casos de

uso, con el nombre correspondiente al tipo de relación de la que se trate: ya sea
<<include>> o <<extend>>.
Estas, son relaciones que usamos para ligar gráficamente dos casos de uso, cuyos flujos
de eventos están unidos, normalmente en una sola sesión del usuario. En otras palabras,
un caso de uso que está ligado, por medio de una de estas dos relaciones, a otro caso de
uso; también podría leerse o ejecutarse como un sólo caso de uso en lugar de dos.
Obviamente, hay una razón por la cual decidimos separarlos en dos, lo cual explicaremos
más adelante.
Imagina el conjunto de pasos que ocurren al realizar una compra en una tienda
departamental. Seguramente no tendrás problema en visualizar el conjunto de pasos para
solicitar la autorización de la tarjeta de crédito con la que vas a pagar, ligado a los pasos
donde el vendedor registra los productos a comprar. Es decir, los flujos de eventos de
ambos procesos forman una sola cosa; juntos podrían formar un solo caso de uso, en
lugar de dos casos de uso unidos por alguna de estas relaciones que aquí estamos
tratando.
Figura 1. Relacionando casos de uso
Include. En términos muy simples, cuando relacionamos dos casos de uso con un
“include”, estamos diciendo que el primero (el caso de uso base) incluye al segundo (el
caso de uso incluido). Es decir, el segundo es parte esencial del primero. Sin el segundo,
el primero no podría funcionar bien; pues no podría cumplir su objetivo. Para una venta
en caja, la venta no puede considerarse completa si no se realiza el proceso para cobrarla
en ese momento. El caso de uso “Cobrar Renta” está incluido en el caso de uso “Rentar
Video”, o lo que es lo mismo “Rentar Video” incluye (<<include>>) “Cobrar Renta”.
Figura 2. Ejemplo de Include
Extend. La polémica al querer seleccionar una de las dos relaciones es que en el “extend”
también podemos ver, desde la perspectiva del usuario, a los dos flujos como si fueran
uno sólo. Y en ciertos escenarios el caso de uso base no podría cumplir su objetivo si no
se ejecutara la extensión. Pero, una de las diferencias básicas es que en el caso del
“extend” hay situaciones en que el caso de uso de extensión no es indispensable que
ocurra, y cuando lo hace ofrece un valor extra (extiende) al objetivo original del caso de
uso base. En cambio en el “include” es necesario que ocurra el caso incluido, tan sólo
para satisfacer el objetivo del caso de uso base. Ejemplo: Puedes “Realizar Venta” sin
“Acumular Puntos de Cliente VIP”, cuando no eres un cliente VIP. Pero, si eres un
cliente VIP sí acumularás puntos. Por lo tanto, “Acumular Puntos” es una extensión de
“Realizar Venta” y sólo se ejecuta para cierto tipo de ventas, no para todas.
Figura 3. Ejemplo de Extend
Casos de Abuso
Uno de los riesgos que existe cuando la gente sabe que tiene estas relaciones como un
elemento a utilizar en sus modelos de casos de uso, consiste en su abuso. Mucha gente, y
sobre todo la que arrastra prácticas de métodos estructurados, la suele utilizar en exceso.
No es raro ver modelos de casos de uso que llegan a tener decenas de inclusiones y
extensiones, incluso las inclusiones y extensiones se vuelven a extender a varios niveles,
generando una maraña de casos de uso que no ofrecen valor al ser mostrados
explícitamente.
Figura 4. Abuso de relaciones
Es importante comprender que el objetivo de estos tipos de relaciones NO consiste

(remarco la negación) en motivar la división de los casos de uso en la mayor cantidad de
pedazos. Debe de existir una razón importante para que decidamos dividir un caso de uso
en dos que serán unidos por medio de alguna de estas relaciones. Si entendemos esto y
somos congruentes, obtendremos un beneficio real para el proyecto; fin último del uso de
UML.
La razón por la que la gente suele partir sus casos de uso en infinidad de “include” y
“extend” es porque quieren conocer, entender y comunicar el máximo detalle de los casos
de uso en el diagrama. Hay quien llega a utilizar, erróneamente, estas relaciones para
mostrar el orden en que se ejecutan estos casos de uso. Debemos de recordar que al
modelar el diagrama de casos de uso no buscamos analizar el detalle, y mucho menos los
flujos. Todo ese detalle lo podremos plasmar en otro tipo de diagramas, como los
diagramas de interacción, de actividad, de estados, o simplemente un texto en una
especificación.
Relaciones de Análisis o Diseño
Otra situación donde abusamos de estas relaciones se da cuando queremos representar la

unión de casos de uso por una decisión de diseño del sistema, específicamente por una
decisión de navegabilidad entre funciones. Pensemos en cierta funcionalidad en un
sistema, la cual corresponde a la ejecución de cierto caso de uso (por ejemplo “Registrar
Préstamo de un Video”). Y estando en dicho caso de uso tienes a la vista en la pantalla, y
decides utilizar, un botón que te permitiría iniciar otro caso de uso que tiene poco o nada
que ver con el objetivo del caso de uso inicial (digamos, “Consultar Promociones”). Esto
no debería de mostrarse como una relación entre estos dos casos de uso en el modelo.
No deberíamos modelar al primer caso de uso incluyendo ni siendo extendido con el

segundo caso de uso ni viceversa, pues la razón por la que se ligaron (no gráficamente,
sino en su ejecución) fue por una facilidad otorgada por la manera en que se diseño el
sistema, la cual permite navegar fácilmente entre las diferentes funciones del sistema. La
navegabilidad que otorga el sistema entre uno y otro caso de uso normalmente tiene que
ver poco con que exista o no una relación entre dichos casos de uso.
Reuso: Evitando el Retrabajo
Una de las razones por las cuales deberías de considerar el uso de este tipo de relaciones,
es porque identificas que hay pasos que son iguales en dos o más casos de uso. No
querrás tener que escribir y darle mantenimiento a esos pasos en los documentos
asociados a cada uno de ellos. Peor aún, no querrás correr el riesgo de que esos pasos se
diseñen, programen y prueben de maneras diferentes y con esfuerzos aislados por ti o tu
equipo de desarrollo. Finalmente son la misma cosa, ¿para qué querríamos trabajar
doble? Lo que queremos es economizar, ser más eficientes en el desarrollo, y ahí es
cuando viene el beneficio de identificar estos tipos de relaciones; porque es una
oportunidad de identificar reuso.
Figura 5. Identificación de reuso
Si te sientes preparado para desarrollar modelos de casos de uso más sofisticados y de

mayor valor, entonces considera la posibilidad de utilizar estos tipos de relaciones. Sólo
asegúrate de aprovecharlas adecuadamente, buscando el beneficio real que deberían de
proporcionar en tu modelo y proyecto con base en las recomendaciones mencionadas. Y
recuerda unificar los criterios dentro de tu empresa para que el lenguaje sea realmente
unificado o estandarizado dentro de tu empresa.
Diagramas de Casos de Uso
UNPSJB - 2005 Ingeniería de Software - Clase 6 1

Casos de Uso www.dsic.upv.es/~uml
• Los Casos de Uso (Ivar Jacobson) • Comparación con respecto a los Diagramas de
describen bajo la forma de Flujo de Datos del Enfoque Estructurado
acciones y reacciones el • Un caso de uso es una función atómica
ofrecida por el sistema al entorno (actores)
comportamiento de un sistema
• DFD puede ser detallada en un DFD Hijo
desde el p.d.v. del usuario
• Caso Uso y Proceso igual modelado, pero
• Permiten definir los límites del caso de uso expresa funcionalidad mediante
sistema y las relaciones entre el interacción de actores
sistema y el entorno • Caso de uno no modela detalle funcional
interno
• Los Casos de Uso son • Relaciones de extensión y generalización de
descripciones de la funcionalidad CU no tienen igual en DFD
del sistema independientes de la
implementación

… Casos de Uso www.dsic.upv.es/~uml
• Los Casos de Uso cubren la

carencia existente en métodos
previos (OMT, Booch) en cuanto
a la determinación de requisitos
• Los Casos de Uso particionan el
conjunto de necesidades Caso de Uso A
atendiendo a la categoría de Actor A
usuarios que participan en el
mismo
• Están basado en el lenguaje Caso de Uso B
Actor B
natural, es decir, es accesible

por los usuarios

• Actores:
• Principales: personas que usan el sistema
• Secundarios: personas que mantienen o administran el sistema
• Material externo: dispositivos materiales imprescindibles que forman parte del ámbito de la
aplicación y deben ser utilizados
• Otros sistemas: sistemas con los que el sistema interactúa
• La misma persona física puede interpretar varios papeles como actores distintos
• El nombre del actor describe el papel desempeñado

• Los Casos de Uso se determinan observando y precisando, actor por actor, las
secuencias de interacción, los escenarios, desde el punto de vista del usuario
• Un escenario es una instancia de un caso de uso
• Los casos de uso intervienen durante todo el ciclo de vida. El proceso de
desarrollo estará dirigido por los casos de uso

Casos de Uso: Relaciones www.dsic.upv.es/~uml
• UML define cuatro tipos • Inclusión: una instancia del

de relación en los Caso de Uso origen incluye
Diagramas de Casos de también el comportamiento
descrito por el Caso de Uso
Uso: destino
• Comunicación <<include>>
Caso de Uso Origen Caso de Uso Destino
Caso de Uso
Actor
<<include>> reemplazó al
denominado <<uses>>

… Casos de Uso: Relaciones www.dsic.upv.es/~uml
• Herencia: el Caso de Uso

• Extensión: el Caso de origen hereda la
Uso origen extiende el especificación del Caso
comportamiento del de Uso destino y
Caso de Uso destino posiblemente la
modifica y/o amplía
<<extend>>
Caso de Uso Origen Caso de Uso Destino

Caso de Uso Hijo Caso de Uso Padre

• Ejemplo:
Identificación
<<include>>
Transferencia
Cliente
<<extend>>
Transferencia en Internet

• Ejemplo:

Casos de Uso: Construcción www.dsic.upv.es/~uml
• Un caso de uso debe ser simple, inteligible, claro y conciso

• Generalmente hay pocos actores asociados a cada Caso de Uso
• Preguntas clave:
• ¿cuáles son las tareas del actor?
• ¿qué información crea, guarda, modifica, destruye o lee el actor?
• ¿debe el actor notificar al sistema los cambios externos?
• ¿debe el sistema informar al actor de los cambios internos?

… Casos de Uso: Construcción www.dsic.upv.es/~uml
• La descripción del Caso de Uso comprende:

• el inicio: cuándo y qué actor lo produce?
• el fin: cuándo se produce y qué valor devuelve?
• la interacción actor-caso de uso: qué mensajes intercambian ambos?
• objetivo del caso de uso: ¿qué lleva a cabo o intenta?
• cronología y origen de las interacciones
• repeticiones de comportamiento: ¿qué operaciones son iteradas?
• situaciones opcionales: ¿qué ejecuciones alternativas se presentan en el caso de uso?

RF- <id del requisito> <nombre del requisito funcional>
Versión <numero de versión y fecha>
Autores <autor>
Fuentes <fuente de la versión actual>
Objetivos asociados <nombre del objetivo>
Descripción El sistema deberá comportarse tal como se describe en
el siguiente caso de uso { concreto cuando <evento de
activación> , abstracto durante la realización de los
casos de uso <lista de casos de uso>}
Precondición <precondición del caso de uso>
Secuencia Paso Acción
Normal 1 {El <actor> , El sistema} <acción realizada por el
actor o sistema>, se realiza el caso de uso
< caso de uso RF-x>
2 Si <condición>, {el <actor> , el sistema} <acción
realizada por el actor o sistema>>, se realiza el
caso de uso < caso de uso RF-x>
3
4
5
6
n
Postcondición <postcondición del caso de uso>
Excepciones Paso Acción
1 Si <condición de excepción>,{el <actor> , el
sistema} }<acción realizada por el actor o
sistema>>, se realiza el caso de uso
< caso de uso RF-x>, a continuación este caso
de uso {continua, aborta}
2
3
Rendimiento Paso Cota de tiempo
1 n segundos
2 n segundos
Frecuencia esperada <nº de veces> veces / <unidad de tiempo>
Importancia {sin importancia, importante, vital}
Urgencia {puede esperar, hay presión, inmediatamente}
Comentarios <comentarios adicionales>
Modelo de Casos de Uso y
Modelo Conceptual (Análisis)
www.dsic.upv.es/~uml
• La especificación de cada caso de uso y los correspondientes D. de Interacción

establecen el vínculo con el modelo conceptual
• En métodos OO que carecen de una técnica de captura de requisitos se
comienza inmediatamente con la construcción del modelo conceptual
(análisis)

Combine PDF

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Combine PDF

Transféré par

Droits d'auteur :

Formats disponibles

Introducción a la Ingeniería de

Práctica final (4 puntos)

Extraído del estándar 729 del IEEE

Ingeniería es el conjunto de conocimientos y

• Para que cumpla las necesidades de los nuevos

Mitos de la Mitos del Mitos del

Antes de comunicarse, Dedique algún tiempo a entender el problema

Alguien debe facilitar la Mantenga la conversación en movimiento

actividad. Facilitador que: Mediador en cualquier conflicto

Garantice que se sigan otros principios

Si algo no está claro, hacer un dibujo

del Construcción más

– Los modelos que representen información, función y comportamiento deben

– Las representaciones del diseño (modelos) deben entenderse con

– El diseño debe desarrollarse en forma iterativa. El diseñador debe

Es la peor de las pesadillas. Un cliente

Problemas de alcance, la frontera de

– Administración de los requerimientos

Identificación Reconocer los Hacer las

¿Qué problemas ¿Hay otro origen

Indagación de los productos del trabajo

• Elementos del modelo de requerimientos

Un estado es cualquier modo de comportamiento observable desde el exterior

2. Facilitan la transformación del modelo de análisis en un

Modelos Basados en el Escenario

Modelos Basados en el Escenario

Modelos Basados en el Escenario

Modelos Orientados a Clase

Modelos Orientados a Clase

Modelos Orientados al Comportamiento

Durante el modelado de los requerimientos,

• Establecer una base para la creación de un

• Definir un conjunto de requerimientos que

• Cada elemento debe agregarse al entendimiento general de los requerimientos del

• Hay que retrasar las consideraciones de la infraestructura y otros modelos no

• Debe minimizarse el acoplamiento a través del sistema

• Es seguro que el modelo de requerimientos agrega valor para todos los

• Mantener el modelo tan sencillo como se pueda

• Análisis orientado a objetos, se centra en la definición de las

– Representación de información compuesta que

Análisis orientado a objetos

• Adopta un punto de vista del tipo entrada-proceso-

• Un evento ocurre siempre que el sistema y un actor

• Un evento no es la información que se intercambia,

• Un caso de uso se estudia para efectos del intercambio

Descubrimiento de patrones de análisis

• Lista de atributos del lado del

El diseño de software comienza una vez que se han

El diseño de software es la última acción de la ingeniería

Elementos basados en Elementos de Diseño arquitectónico

• Diagramas de clase • Diagramas de estado

Modelo del Diseño

Por qué es tan importante el diseño?

Características para evaluar un buen diseño

• Funcionalidad, conjunto de características y capacidades del

Programación Enfoque Desarrollo

1. Un mecanismo para traducir el

Abstracción de Es una colección nombrada de datos

Propiedades del diseño de la arquitectura

Modelos del diseño arquitectónico

• Elementos de diseño de la interfaz

– Destaca las decisiones iniciales relacionadas con el diseño

– Constituye un modelo relativamente pequeño e

– Perspectiva, representación del sistema completo