Este documento presenta una introducción a los conceptos fundamentales de análisis y diseño orientado a objetos. Explica técnicas como análisis y diseño orientado a objetos, el lenguaje unificado de modelado, técnicas de modelado de objetos, la metodología de Booch, la metodología RUP, diseño de alto y bajo nivel, y comprensión de requerimientos. También incluye referencias históricas clave en el desarrollo de la arquitectura y el diseño de software.

1. Materia: Arquitectura y diseño de Software I.T.S.A .
1.1.- Análisis y diseño orientado a objetos
Análisis y diseño orientado a objetos (ADOO) es un enfoque de la ingeniería de software que modela un sistema
como un grupo de objetos que interactúan entre sí. Este enfoque representa un dominio en términos de conceptos
compuestos por verbos y sustantivos, clasificados de acuerdo a su dependencia funcional.
En este método de análisis y diseño se crea un conjunto de modelos utilizando una notación acordada como, por
ejemplo, el lenguaje unificado de modelado (UML). ADOO aplica técnicas de modelado de objetos para analizar los
requerimientos para un contexto - por ejemplo, un sistema de negocio, un conjunto de módulos de software - y para
diseñar una solución para mejorar los procesos involucrados. No está restringido al diseño de programas de
computadora, sino que cubre sistemas enteros de distinto tipo. Las metodologías de análisis y diseño más modernas
son casos de uso guiados a través de requerimientos, diseño, implementación, pruebas, y despliegue.
El lenguaje unificado de modelado se ha vuelto el lenguaje de modelado estándar usado en análisis y diseño
orientado a objetos.
Referencias Históricas
Definición de Arquitectura y Diseño de Software
La Arquitectura de Software es una disciplina emergente del tópico general de diseño de software, relacionada con la
representación y composición de sistemas de software. En este contexto, el diseño de software se propone como una
actividad conciliatoria entre los requerimientos del problema, en términos de una función, y la factibilidad de una
solución en términos de un sistema de software. La idea básica es obtener una visión amplia, completa y humana del
software, como un producto tanto del conocimiento como de la intuición del diseñador de software.
 Edsger Djikstra, 1968
 Ciencias de la computación como rama aplicada de las matemáticas
 Niveles de abstracción
 Stack, abrazos mortales, semáforos, algoritmos de camino mas corto
 NATO, 1968
 F. L. Bauer “Ingeniería de software”
 NATO, 1969
 P. I. Sharp, “Arquitectura de software”
 C. R. Spooner, 1971
 “Una arquitectura de software para los 70s”
 Referencia accidental
Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 1

2.  Niklaus Wirth, 1971
 Niveles de abstracción, Stepwise refinement
 DeRemer & Kron, 1976
 Programming in the large
 Fred Brooks, 1975 – MMM
 Diseñador del OS/360, Premio Turing 2000
 Arquitectura como interfaz usuario
 El arquitecto es un agente del usuario, igual que quien diseña su casa
 Importancia de las estructuras de alto nivel y de decisiones tomadas al principio
 Arquitectura: qué hacer – Implementación: cómo hacerlo
 David Parnas
 1972: Módulos – Ocultamiento de información
 1974: Estructuras de software
 1976: Familias de programas (Árbol de decisión) – Descomposición – Alternativa a diagramas de flujo,
propensión estructural (no funcional)
 “Una familia de programas es un conjunto de programas (no todos los cuales han sido construidos o
lo serán alguna vez) a los cuales es provechoso o útil considerar como grupo. Esto evita el uso de
conceptos ambiguos tales como “similitud funcional” que surgen a veces cuando se describen
dominios. Por ejemplo, los ambientes de ingeniería de software y los juegos de video no se
consideran usualmente en el mismo dominio, aunque podrían considerarse miembros de la misma
familia de programas en una discusión sobre herramientas que ayuden a construir interfaces graficas,
que ambos casualmente utilizan”.
 Dewayne Perry, Alexander Wolf – 1992
 “Foundations for the study of software architecture”
 “La década de 1990, creemos, será la década de la arquitectura de software. Usamos el término
“arquitectura” en contraste con “diseño”, para evocar nociones de codificación, de abstracción, de
estándares, de entrenamiento formal (de los arquitectos de software) y de estilo.  Es tiempo de re-
examinar el papel de la arquitectura de software en el contexto más amplio del proceso de software
y de su administración, así como señalar las nuevas técnicas que han sido adoptadas”.
 Escuela de Carnegie Mellon (CMU-SEI)
 Mary Shaw, David Garlan, Paul Clements, Robert Allen
Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 2

3. 1.2.1 Técnicas de modelado de objetos (OMT)
Según la Real Lengua Española: Técnica: es Conjunto de procedimientos y recursos de que se sirve una ciencia o un
arte. Modelado: es una técnica que ayuda a “visualizar” el sistema a construir. Objeto: Un objeto es una
representación detallada, concreta y particular de un “algo”. Tal representación determina su identidad, su estado y
su comportamiento particular en un momento dado.
En conclusión es Una serie de procedimientos para visualizar una serie de caracteristicas asignadas a un objeto.
Metodología OMT (Técnica de Modelado de Objetos):
Un modelo es una abstracción de algo, con la finalidad de comprenderlo, antes de construirlo, ya que un modelo
omite los detalles no esenciales, es más sencillo manejarlos, que manejar la entidad original.
OMT es una de las metodologías de análisis y diseño orientadas a objetos, más maduras y eficientes que existen en la
actualidad. La gran virtud que aporta esta metodología es su carácter de abierta (no propietaria), que le permite ser
de dominio público y, en consecuencia, sobrevivir con enorme vitalidad. Esto facilita su evolución para acoplarse a
todas las necesidades actuales y futuras de la ingeniería de software.
Esta técnica es trilateral, ya que toma en cuenta tres puntos de vista: modelo de objetos, modelo dinámico y modelo
funcional.
El modelo de objetos.
El modelo de objetos es el modelo más importante, ya que en él se identifican las clases dentro del sistema junto con
sus relaciones, así como sus atributos y operaciones, lo que representa la estructura estática del sistema.
El modelo de objetos, representado en UML con Diagramas de Clase, describe la estructura de un sistema desde el
punto de vista de objetos y asociaciones.
El modelo dinámico.
Representa los aspectos temporales de comportamiento "de control" del sistema, mediante la secuencia de
operaciones en el tiempo.
El modelo dinámico, representado en UML con Diagramas de Secuencia, Diagramas de colaboración, Diagramas de
Actividad y Diagramas de Estado, describe el comportamiento del sistema.
El modelo funcional.
Representa los aspectos transformacionales "de función" del sistema, mediante la transformación de valores de los
datos. Se representa mediante un diagrama de flujo.
Cada modelo describe un aspecto del sistema pero contiene referencias a los demás modelos. Lo cual indica que los
tres no son totalmente independientes.
El modelo funcional, representado en UML con Diagramas de Caso de Uso, describe la funcionalidad del sistema
desde el punto de vista del usuario.
Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 3

4. 1.2.2 metodología de Booch
La Metodología de Booch es una técnica usada en ingeniería de software. Es un lenguaje de modelado de objetos y
una metodología ampliamente usada en el diseño de software orientado a objetos. Fue desarrollada por Grady Booch
mientras trabajaba para Rational Software (hoy parte de IBM).
Los aspectos notables de la metodología de Booch han sido superados por el Lenguaje Unificado de Modelado, que
combina elementos gráficos de la metodología de Booch junto a elementos de la técnica de modelado de objetos y la
Ingeniería de software orientada a objetos
Los aspectos metodológicos de la metodología de Booch fueron incorporados en varias metodologías y procesos,
siendo la principal de ellas el Proceso Racional Unificado (RUP).
1.3 Metodologia RUP (Rational Unified Process)
El Proceso Unificado de Rational (Rational Unified Process en inglés, habitualmente resumido como RUP) es
un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología
estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos.
El RUP no es un sistema con pasos firmemente establecidos, sino un conjunto de metodologías adaptables al
contexto y necesidades de cada organización.
También se conoce por este nombre al software desarrollado por Rational, hoy propiedad de IBM, el cual incluye
información entrelazada de diversos artefactos y descripciones de las diversas actividades. Está incluido en el Rational
Method Composer (RMC), que permite la personalización de acuerdo con las necesidades.
Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 4

5. Originalmente se diseñó un proceso genérico y de dominio público, el Proceso Unificado, y una especificación más
detallada, el Rational Unified Process, que se vendiera como producto independiente.
RUP Forma disciplinada de asignar tareas y responsabilidades en una empresa de desarrollo (quién hace qué, cuándo
y cómo).
RUP es el proceso de desarrollo más general de los existentes actualmente.
Los procesos de RUP estiman tareas y horario del plan midiendo la velocidad de iteraciones concerniente a sus
estimaciones originales. Las iteraciones tempranas de proyectos conducidos RUP se enfocan fuertemente sobre
arquitectura del software; la puesta en práctica rápida de características se retrasa hasta que se ha identificado y se
ha probado una arquitectura firme.
RUP proporciona muchas ventajas sobre XP (METODOLOGIA EXTREME PROGRAMMING) le da énfasis en los
requisitos y el diseño.
La ventaja principal de RUP es que se basa todo en las mejores prácticas que se han intentado y se han probado en el
campo. (en comparación con XP que se basa en las prácticas inestables que utilizaron juntas se evita que se derribe).
RUP se divide en cuatro fases:
Inicio (Define el alcance del proyecto)
Elaboración (definición, análisis, diseño)
Construcción (implementación)
Transición (fin del proyecto y puesta en producción)
Cada fase concluye con un HITO (T. Decisiones)
RUP realiza un levantamiento exhaustivo de requerimientos. Busca detectar defectos en las fases iniciales.
Intenta reducir al número de cambios tanto como sea posible. Realiza el Análisis y diseño, tan completo como sea
posible. Diseño genérico, intenta anticiparse a futuras necesidades. Las necesidades de clientes no son fáciles de
discernir.
Existe un contrato prefijado con los clientes.
El cliente interactúa con el equipo de desarrollo mediante reuniones a diferencia de la metodología XP que el cliente
es parte del equipo (in situ).
1.4 Diseño de alto nivel (HLD) y bajo nivel (LLD)
Diseño de Alto Nivel (DAN) es el diseño general del sistema que abarca la arquitectura del sistema y el diseño de
bases de datos. En él se describe la relación entre los diferentes módulos y las funciones del sistema. Flujo de datos,
diagramas de flujo y estructuras de datos están cubiertos por la DAN. El diseño de alto nivel también identifica los
principales candidatos fuera de la plataforma de productos que pueden ser utilizados en el sistema.
Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 5

6. Alto nivel de diseño es la etapa de transición entre los requisitos de los subsistemas y cómo la arquitectura y las
interfaces del sistema se implementarán para cumplir con los requisitos del sistema. Este proceso incluye la
descomposición de los requisitos del sistema en las arquitecturas de proyecto alternativo y luego de la evaluación de
estas arquitecturas de proyecto para un óptimo rendimiento, funcionalidad, costo, y otros asuntos técnicos y no
técnicos. Participación de los interesados es fundamental para esta actividad. En este paso, las interfaces internas y
externas se identifican con los estándares de la industria es necesario.
Diseño de Bajo Nivel (LLD) es como detalla el Diálogo de Alto Nivel. Se define la lógica real de cada componente del
sistema. Los diagramas de clases con todos los métodos y la relación entre las clases están bajo LLD. Especificaciones
de los programas están cubiertas por LLD.
La funcionalidad de un diseño de bajo nivel es adaptar el diseño que anteriormente se ha realizado (diseño de alto
nivel) al lenguaje de programación.
LLD describe todas y cada módulo de forma elaborada de modo que el programador directamente el código del
programa basado en este. Este será por lo menos un documento para cada módulo y puede haber más de un módulo.
La LLD contendrá:
 Detallada lógica funcional del módulo en pseudocódigo - tablas de base de datos con todos los elementos
incluyendo su tipo y tamaño
 Todos los detalles de la interfaz con referencias completas de la API (ambas solicitudes y respuestas)
 Todos los problemas de dependencia
 El mensaje de error listados
 Entrada completa y salidas de un módulo
1.5 Compresión de los requerimientos
Se tiene que tener una completa comprensión de los requerimientos para poder resolver los problemas que se puedan
presentar así como para tener una participación activa en el desarrollo del software. Si hay un equipo, esta
experiencia puede estar representada en diferentes miembros del grupo, pero al menos una persona debe poder
mantener la visión global del proyecto. Esta persona es el arquitecto del Software quien es el responsable de diseñar
la arquitectura del software, la cual incluye tomar las principales decisiones de diseño y la implementación del
proyecto, se debe de tener experiencia en dominios tanto de problemas como de ingeniería de software.
Tipos de requerimientos
 Requerimiento: Atributo del sistema
Algo que el sistema debe ser capaz de hacer para cumplir su propósito
 Tipos clásicos de requerimientos:
o Funcionales: describen tareas específicas que el sistema debe ser capaz de hacer
Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 6

7. Ejemplo: imprimir cheques de sueldos
o No-funcionales (restricciones): limitan nuestras opciones para construir una solución.
Ejemplo: generar cheques máx. 4 hrs después de recibir listados de contabilidad
 Analogía:
Requisitos funcionales: los “verbos” (Xear)
Requisitos no-funcionales: los “adverbios” (Xmente)
1.6 Casos de Uso
1.6.1 Introducción
Un caso de uso es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo
algún proceso. Los personajes o entidades que participarán en un caso de uso se denominan actores. En el contexto
de ingeniería del software, un caso de uso es una secuencia de interacciones que se desarrollarán entre un sistema y
sus actores en respuesta a un evento que inicia un actor principal sobre el propio sistema. Los diagramas de casos de
uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los
usuarios y/u otros sistemas. O lo que es igual, un diagrama que muestra la relación entre los actores y los casos de
uso en un sistema. Una relación es una conexión entre los elementos del modelo, por ejemplo la especialización y la
generalización son relaciones. Los diagramas de casos de uso se utilizan para ilustrar los requerimientos del sistema al
mostrar cómo reacciona a eventos que se producen en su ámbito o en él mismo.
La técnica de caso de uso tiene éxito en sistemas interactivos, ya que expresa la intención que tiene el actor
(su usuario) al hacer uso del sistema.
Como técnica de extracción de requerimiento permite que el analista se centre en las necesidades del
usuario, qué espera éste lograr al utilizar el sistema, evitando que la gente especializada en informática dirija la
funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos.
A su vez, durante la extracción (elicitation en inglés), el analista se concentra en las tareas centrales del
usuario describiendo por lo tanto los casos de uso que mayor valor aportan al negocio. Esto facilita luego la
priorización del requerimiento.
El diagrama de casos de uso representa la forma en cómo un Cliente (Actor) opera con el sistema en
desarrollo, además de la forma, tipo y orden en como los elementos interactúan (operaciones o casos de uso).
1.6.2 Elementos de Casos de uso.
Un diagrama de casos de uso consta de los siguientes elementos:
Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 7

8. Actor:
Una definición previa, es que un Actor es un rol que un usuario juega con respecto al sistema. Es importante
destacar el uso de la palabra rol, pues con esto se especifica que un Actor no necesariamente representa a una
persona en particular, sino más bien la labor que realiza frente al sistema.
Caso de Uso:
Es una operación/tarea específica que se realiza tras una orden de algún agente externo, sea desde una
petición de un actor o bien desde la invocación desde otro caso de uso.
Relaciones:
Asociación
Es el tipo de relación más básica que indica la invocación desde un actor o caso de uso a otra operación (caso
de uso). Dicha relación se denota con una flecha simple.
Dependencia o Instanciación
Es una forma muy particular de relación entre clases, en la cual una clase depende de otra, es decir, se
instancia (se crea). Dicha relación se denota con una flecha punteada.
Generalización
Este tipo de relación es uno de los más utilizados, cumple una doble función dependiendo de su estereotipo,
que puede ser de Uso (<<uses>>) o de Herencia (<<extends>>).
Este tipo de relación está orientado exclusivamente para casos de uso (y no para actores).
Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 8

9. 1.7 Modelos del Dominio
Modelo de Dominio:
Es un artefacto de la disciplina de análisis, construido con las reglas de UML durante la fase de concepción, en la tarea
construcción del modelo de dominio, presentado como uno o más diagramas de clases y que contiene, no conceptos
propios de un sistema de software sino de la propia realidad física.
Los modelos de dominio pueden utilizarse para capturar y expresar el entendimiento ganado en un área bajo análisis
como paso previo al diseño de un sistema, ya sea de software o de otro tipo.
Similares a los mapas mentales utilizados en el aprendizaje, el modelo de dominio es utilizado por el analista como un
medio para comprender el sector industrial o de negocios al cual el sistema va a servir.
Los modelos de dominio pueden mostrar:
 Objetos del dominio o clases conceptuales.
 Asociaciones entre las clases conceptuales.
 Atributos de las clases conceptuales.
Nota: Ejemplo de Modelo de Dominio
1.7.1 Visualización de Conceptos
La visualización de los conceptos en el principal propósito del diagrama de dominio, se enfoca en una serie de
conceptos como las asociaciones y los atributos que son vitales para este diagrama, para tener un mejor y fácil
entendimiento.
Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 9

10. 1.7.2 Añadir Asociaciones
Una asociación representa una relación entre clases, y aporta la semántica común y la estructura de muchos tipos de
conexiones entre objetos.
Las asociaciones son los mecanismos que permite a los objetos comunicarse entre sí; Describe la conexión entre
diferentes clases.
Las asociaciones pueden tener un papel que especifica el propósito de la asociación y pueden ser unidireccionales o
bidireccionales (indicando si los dos objetos participantes en la relación pueden intercambiar mensajes entre sí, o es
únicamente uno de ellos el que recibe información del otro). Cada extremo de la asociación también tiene un valor de
multiplicidad, que indica cuántos objetos de ese lado de la asociación están relacionados con un objeto del extremo
contrario.
1.7.3 Añadir Atributos
Un atributo no debería ser un concepto complejo sino que deberían ser cosas simples o tipos de datos. Por ejemplo:
fecha, hora, número, color, código, descripción, cantidad.
Cuando algo está compuesto de más de un elemento, da la idea de estar frente a una entidad y no un atributo. Por
ejemplo, la dirección puede resultar un concepto simple pero en realidad está formada por calle, altura, etc.
Si una entidad puede tener muchos valores simultáneos para un mismo atributo, ese atributo debería ser otra
entidad. Por ejemplo, una persona puede tener muchos números de teléfono, entonces número de teléfono es una
entidad con una asociación de 1 a muchos con la persona.
Una regla importante a tener en cuenta es relacionar las entidades con una asociación y no a través de un atributo.
No existe un único diagrama de dominio correcto, todos serán una aproximación del dominio que estamos
intentando entender. Un buen diagrama captura las abstracciones y da la información necesaria para entender el
contexto.
Unidad I: Introducción Docente: M.I. Jose Yahveh Contreras Página 10