República Bolivariana de Venezuela

Ministerio del Poder Popular para la Educación

Universidad Nacional Experimental Politécnica de la Fuerza Armada

Análisis Y Diseño de Sistemas II

Diseño orientado a
objetos.

Profesor: Alumno:

Ángel Cipriano Márquez César Wilson Ruda

C.I: 25.561.120

Caracas, 27 de noviembre de 2022

 Introducción
El diseño Orientado a Objetos (DOO) difiere considerablemente del diseño
estructurado ya que en DOO no se realiza un problema en términos de
tareas (subrutinas) ni en términos de datos, sino que se analiza el problema
como un sistema de objetos que interactúan entre sí.

Un problema desarrollado con técnicas orientadas a objetos requiere, en

primer lugar, saber cuáles son los objetos del programa. Como tales objetos
son instancias de clases, la primera etapa en el desarrollo orientado a
objetos requiere de la identificación de dichas clases (atributos y
comportamiento), así como las relaciones entre éstas y su posterior
implementación en un lenguaje de programación.

Aunque no siempre están bien delimitadas las etapas de análisis y diseño en

la OO, se pueden sintetizar de alguna forma las ideas claves de las distintas
tecnologías existentes dentro del desarrollo orientado a objetos al que
denominaremos diseño.

En el diseño orientado a objetos, los objetos necesitan interactuar y

comunicarse, para realizar dicha comunicación, los objetos utilizan su propia
interfaz pública, dicha interfaz se compone principalmente de métodos y
propiedades. El diseño orientado a objetos transforma el modelo del análisis
en un modelo de diseño que sirve como anteproyecto para la construcción de
software.

Tambien se tiene en cuenta que hay una constante con la que tenemos que
vivir -nos guste o no-, sin duda esa es el cambio. Todo evoluciona a veces a
bien, a veces no tanto a nuestro alrededor, y la tecnología tiene mucho que
decir en este ámbito. Sin duda muchos de los grandes avances de los
últimos tiempos han tenido que ver con el desarrollo informático.

De hecho, las cosas parecen cambiar tan rápido en ese aspecto que casi no
nos da tiempo de asumir una novedad y ya tenemos otra de camino. Sin
embargo, una empresa jamás puede quedarse atrás: por eso, en este post
restamos incertidumbre a tu decisión de implantar un sistema informático
nuevo y te contamos cuáles son las 4 fases que atraviesa todo proyecto
informático.

2
Diseño orientado a objetos.

Fundamentos del diseño orientado a objetos:

Diseño del componente de dominio problema

El componente del dominio del problema (PDC) es el conjunto básico de
objetos funcionales que llega de la etapa de análisis. Tales objetos
directamente resuelven el problema que se pretende ser resuelto por el
sistema que se está construyendo, lo que quiere decir que el diseño del PDC
se termina en su mayor parte en la etapa de análisis, completándose ahora
con la ejecución de tres actividades, las cuales son:

Diseño de reusó.
Se pueden añadir en esta etapa nuevas clases para reusar objetos que
serán útiles más adelante. Es el caso de los paquetes comerciales de clase
generalizada como las que contienen las organizaciones de programadores
OO con experiencia, ellos por lo general poseen una biblioteca de clases
desarrollada para los objetos. Estas bibliotecas y paquetes pueden contener
clases que tienen atributos y servicios para objetos similares a los requeridos
en el diseño del sistema a desarrollarse. Estas clases reusables pueden ser
añadidas al diseño como clases bases en una estructura Gen-Spec.

Estructura de Implementación.

Debido a la implementación en un lenguaje de programación en particular

podría ser necesario que en el diseño se agreguen estructuras que pueden
ser de agregación, o Gen-Spec, este último para permitir que varias clases
de objetos compartan un protocolo o estructura de datos. Estas estructuras
usan el concepto de herencia para hacer más fácil el enfoque de
programación.

Acomodo al lenguaje

En esta sección podemos corregir (si es necesario) el diseño para que las
estructuras puedan ser construidas en el lenguaje de programación
seleccionado, debido a que estos lenguajes pueden tener diferentes patrones
de herencia. Algunos lenguajes, por ejemplo, incluyen herencia múltiple (C+
+), otros solamente incluyen herencia simple (Java) y todavía otros que
posiblemente no incluyen herencia. En los casos más restrictivos, los
patrones de herencia del diseño deben ser modificados para permitir las
capacidades del lenguaje de programación.

3
Diseño del Componente de Interfaz Humana

En esta actividad creamos los menús, reportes y pantallas interactivas que

usarán las personas para trabajar con el sistema. Por lo general, se puede
obtener ayuda en gran forma en clases de bibliotecas para el diseño de
clases de Interfaz. Esta es un área donde la reusabilidad de las clases
Orientado a Objetos ha probado ser muy efectiva. Las clases de bibliotecas
generalmente proporcionan generalizaciones de menús, ventanas, control de
tipo de letra, y utilerías de cortar y pegar.

Los prototipos son muy útiles durante el diseño de Interfaz para hacer más
fácil la manera en que trabajarán las clases de biblioteca con los objetos del
dominio.

Por lo general, con la información obtenida en las entrevistas y casos de uso

podemos recopilar información acerca de los perfiles de usuarios
involucrados en el sistema y diseñar una interfaz correspondiente a su perfil.

Diseño de componentes de administración de tareas y datos.

Ambos componentes están estrechamente relacionados con la tecnología

de implementación. El manejo de tareas está muy determinado por la
configuración de hardware de computación, y el manejo de datos está muy
determinado por el software de sistema disponible cuando el sistema está de
hecho en ejecución.

El componente de manejo de tareas es más importante cuando el sistema

está ejecutándose en varios procesadores o computadoras. Una “tarea”es un
conjunto de servicios relacionados que deben ejecutarse juntos (tal vez en el
mismo procesador). Las tareas son activadas por el tiempo transcurrido o por
un evento. Los objetos del manejo de tarea obedecen a activadores de
tareas, asignación de procesadores y prioridades cuando son llamados los
servicios.

El componente de Manejo de Datos comprende, por lo general, clases y

objetos necesarios para almacenar y recuperar a los otros objetos del
sistema. El Componente Manejo de Datos varía considerablemente
dependiendo de si la tecnología de tiempo de ejecución subyacente es una
base de datos orientada a objetos, una base de datos relacional o un sistema
de archivos “plano” ordinario. En un ambiente de Base de Datos relacional o
de archivo plano el componente de manejo de datos debe proporcionar
servicios de almacenamiento al sistema.

Hay tres formas diferentes para diseñar el Diagrama de Manejo de Datos:

4
1. Construir servicios de almacenamiento en cada Clase y Objetos en el
diseño: Esto involucra, por lo general, una cantidad considerable de
programación de diseño adicional.

2. Crear una Clase y Objeto, ServidorObjeto, que proporcione todos los

servicios de Base de Datos: Involucra un complejo objeto que sepa cómo
guardar o recuperar todos los objetos del sistema. Cualquier petición de
almacenamiento se hace por medio de mensajes a este único objeto cuyo
diseño podría ser como el que se muestra a continuación.

3. Crear una clase Almacenable: Es una combinación de los dos enfoques

anteriores. Cada objeto del sistema que deba ser guardado o recuperado es
conectado luego a una estructura Gen-Spec con la clase almacenable. La
figura a continuación es un ejemplo de ésta.

Enfoques alternativos y notación para su implantación

El diseño orientado a Objetos permite al ingeniero de software indicar los

objetos que se derivan de cada clase de las interrelaciones entre ellos.
Además, el DOO debe proporcionar una notación que refleje las relaciones
entre los objetos. También se pueden aplicar de igual forma la terminología,
la notación y el enfoque usado en el AOO.

Los primeros intentos de escribir con método de diseño orientado a los

objetos no surgieron hasta principios de la década de los ochenta, tanto
Abbott |ABBB83° como Booch |BOO86A| establecen que el DOO debe
comenzar con una descripción en el lenguaje natural de la estrategia de
solución mediante una realización en software, de un problema del mundo
real. Posteriores contribuciones de Schlaer y Mellor |SCL88| y de Coad
Yourdon |COA90| introdujeron una notación más amplia para asistir esa
actividad y argumentaron que se trataba realmente una actividad de análisis.

Usamos una notación grafica para representar los objetos, las operaciones,
los mensajes y otras estructuras propuestas por Coad y Yourdon. Esta
notación también para las primeras etapas del diseño. Sin embargo, también
se han propuesto otras notaciones que a menudo se encuentran en el
cambio industrial.

Algunas son:

El método Shlaer-Mellor: también conocido como Análisis de sistemas

orientados a objetos (OOSA) o Análisis orientado a objetos (OOA) es una

5
metodología de desarrollo de software orientada a objetos introducida por
Sally Shlaer y Stephen Mellor en 1988. El método hace que el análisis
documentado sea tan preciso que es posible implementar el modelo de
análisis directamente mediante la traducción a la arquitectura de destino, en
lugar de elaborar cambios de modelo a través de una serie de modelos más
específicos de la plataforma. En el nuevo milenio, el método Shlaer-Mellor ha
migrado a la notación UML, convirtiéndose en Executable UML.

Método de Rumbaugh: La técnica de modelado de objetos (TMO) [RUM91]

engloba una actividad de diseño que alienta al diseño a ser conducido a dos
diferentes niveles de abstracción. El diseño de sistema se centra en el
esquema de los componentes que se necesitan para construir un sistema o
producto completo. El modelo de análisis se divide en subsistemas, los
cuales se asignan a procesadores y tareas. Se define una estrategia para
implementar la administración de datos, y se identifican los recursos y
mecanismos de control requeridos para accesarlos. El diseño de objetos
enfatiza el esquema detallado de un objeto individual. Se seleccionan las
operaciones del modelo de análisis, y los algoritmos se definen para cada
operación. Se representan las estructuras de datos apropiadas para atributos
y algoritmos. Las clases y atributos de clase son diseñados de manera que
se optimice el acceso a los datos, y se mejore la eficiencia computacional. Se
crea un modelo de mensajería, para implementar relaciones de objetos
(asociaciones).

Enfoque Shlaer-Mellor: Un objeto es una persona, un lugar, o una cosa. Un

objeto puede ser físico o conceptual. La idea es que un objeto es una sola
entidad o noción. Cada objeto es un individuo único. Un objeto se puede
relacionar con o componer de otros objetos, pero cada objeto es único.

Clase (Metodología Embley)

Identificación de conjunto de objetos que pertenecen juntos por una cierta

razón lógica llamada clasificación. En OSA, un sistema de objetos que
pertenecen juntos por una cierta razón lógica se le llama clase del objeto. El
modelo de la Objeto-Relación ínsita a los analistas a que organicen objetos
en clases del objeto. Cada clase del objeto tiene un nombre genérico y
denota a cualquier miembro de la clase del objeto. Así, en un ORM, una
clase del objeto con nombre X señala una clasificación de los objetos cada
uno de los cuales se considera ser un X. Como cada objeto en clase del

6
objeto X es un X, los objetos en la clase son semejantes, por lo menos en un
cierto sentido.

Concepto Operación Según Metodología Embley

Además de estados y de transiciones entre estados, también deseamos

modelar las acciones que un objeto realiza. Una acción puede causar
acontecimientos, crear o destruir objetos y relaciones, observar objetos y
relaciones, y enviar o recibir mensajes.

"Ponemos acciones en dos categorías en OSA: acciones no-interrumpibles y

acciones interrumpibles. Las acciones no-interrumpibles son las acciones
que el analista espera correr al terminar a menos que ocurran las
excepciones o los fallos del sistema. Las acciones interrumpibles pueden ser
suspendidas antes de que acaben de ejecutarse y puedan reasumir la
ejecución después. En OSA, pensamos en las acciones asociadas a
transiciones como no-interrumpible, mientras que las acciones asociadas a
los estados son interrumpibles."

Características:

 Análisis de los Sistemas Orientado a Objeto

 Construcción de Modelos Objeto-Relación
 Construcción de Modelos Objeto-Comportamiento
 Construcción de Modelos Objeto Interacción
 Integrar los Modelos

Enfoque de Rumbaugh: La técnica de modelado de objetos (TMO) [RUM91]

engloba una actividad de diseño que alienta al diseño a ser conducido a dos
diferentes niveles de abstracción. El diseño de sistema se centra en el
esquema de los componentes que se necesitan para construir un sistema o
producto completo. El modelo de análisis se divide en subsistemas, los
cuales se asignan a procesadores y tareas. Se define una estrategia para
implementar la administración de datos, y se identifican los recursos y
mecanismos de control requeridos para accesarlos. El diseño de objetos
enfatiza el esquema detallado de un objeto individual. Se seleccionan las
operaciones del modelo de análisis, y los algoritmos se definen para cada
operación. Se representan las estructuras de datos apropiadas para atributos
y algoritmos. Las clases y atributos de clase son diseñados de manera que
se optimice el acceso a los datos, y se mejore la eficiencia computacional. Se

7
crea un modelo de mensajería, para implementar relaciones de objetos
(asociaciones).

Pruebas Orientadas a Objetos

Modelos de pruebas en Orientación a Objetos.

Los modelos de análisis y diseño no pueden probarse en el sentido
convencional, ya que no pueden ejecutarse. Sin embargo, se pueden utilizar
las revisiones técnicas formales para examinar la exactitud y consistencia de
ambos modelos de análisis y diseño.

Exactitud de los modelos de AOO y DOO

La notación y sintaxis que se utiliza para representar los modelos de análisis

y diseño se corresponderá con el método específico de análisis y diseño,
elegido para el proyecto. Por consiguiente, la exactitud sintáctica se juzga en
el uso apropiado de la simbología; cada modelo se revisa para asegurarse
de que se han mantenido las convenciones propias del modelado.

Durante el análisis y diseño, la exactitud semántica debe juzgarse basada en

la conformidad del modelo con el dominio del problema en el mundo real. Si
el modelo refleja con exactitud el mundo real (al nivel de detalle apropiado a
la etapa de desarrollo en la que se revisa el modelo), entonces es
semánticamente correcto. Para determinar si el modelo en realidad refleja el
mundo real, debe presentarse a expertos en el dominio del problema,
quienes examinarán las definiciones de las clases y sus jerarquías, para
detectar omisiones o ambigüedades. Las relaciones entre clases (conexiones
de instancia) se evalúan para determinar si reflejan con exactitud conexiones
del mundo real.

Consistencia de los modelos de AOO

La consistencia de los modelos de AOO y DOO debe juzgarse considerando

las relaciones entre entidades dentro del modelo. Un modelo inconsistente
tiene representaciones en una parte, que no se reflejan correctamente en
otras partes del modelo.

Para evaluar la consistencia, se debe examinar cada clase y sus conexiones

a otras clases. Un modelo clase-responsabilidad-colaboración (CRC) y un
diagrama objeto-relación pueden utilizarse para facilitar esta actividad. El
modelo CRC se compone de una tarjeta índice CRC. Cada tarjeta CRC
muestra el nombre de la clase, sus responsabilidades (operaciones) y sus

8
colaboradores (otras clases a las que se envían mensajes y de las cuales
depende para el cumplimiento de sus responsabilidades). Las
colaboraciones implican una serie de relaciones (por ejemplo, conexiones),
entre clases del sistema OO. El modelo objeto-relación proporciona una
representación gráfica de las conexiones entre clases. Toda esta información
se puede obtener del modelo de AOO.

Una vez que se crea el modelo de DOO, deben llevarse a cabo también las
revisiones del diseño del sistema y del diseño de objetos. El diseño del
sistema describe el producto arquitectónico global, los subsistemas que
componen el producto, la manera en que los subsistemas se asignan a los
procesadores, la asignación de clases a subsistemas y el diseño de la
interfaz de usuario. El diseño de objetos presenta los detalles de cada clase,
y las actividades de mensajería necesarias para implementar las
colaboraciones entre clases.

Conceptos básicos de la implantación:

Fundamentos de la implantación:

Fases de la implantación de Sistemas:

1. Consultoría y análisis

Lo primero que necesitas es identificar qué necesitas. Y eso no es tarea fácil.

Las empresas suelen combinar distintos procesos de importancia que deben
funcionar como la seda, y resulta muy útil preguntar a cada departamento
cuáles son sus necesidades, en qué pierden más tiempo… En definitiva,
escuchar a quienes desarrollan el día a día empresarial para mejorar su
experiencia y, con ella, la eficiencia de la empresa.

En este sentido, este análisis previo le será de gran utilidad a los

profesionales que se encarguen de desarrollar el nuevo sistema informático.
La relación entre ambas partes debe ser de extrema confianza: es mejor que
no se quede nada en el tintero para que la solución aportada sea
verdaderamente útil. Si sientes que tu empresa informática no te escucha,
estás a tiempo de cambiar, pero jamás dejes de expresar tus necesidades:
nadie mejor que tú conoce cómo funciona tu empresa.

Estos son algunos aspectos que te interesa identificar, junto con tu proveedor
de servicios informáticos:

9
Identificar los problemas con el sistema actual

Aclarar cuáles son los principales objetivos del nuevo sistema

Fijar cuánto podemos invertir y qué soluciones son prioritarias

Identificar el alcance del sistema que se podría implantar

Identificar un número de soluciones que pueden satisfacer las necesidades

del usuario dentro de su esquema

Desarrollar los beneficios y desventajas de cada solución

2. Gestión de proyectos

La siguiente fase es bastante más práctica, pero se trata de un punto en el

que la mayor parte del trabajo viene de la mano del equipo informático. En
esta etapa, los técnicos de la empresa proveedora se pondrán a trabajar
para evaluar cuáles son los productos y servicios que más se adecúan a las
necesidades de tu empresa, buscando siempre la mejor relación calidad-
precio para que el presupuesto definido se traduzca en una mejora lo más
cercana a la meta final posible.

El resultado será un proyecto a medida y un presupuesto que se ajuste a los

límites marcados. En éste se suele incluir todo lo necesario para la puesta a
punto de esa nueva etapa: equipo informático, programas, desarrollo, horas
de trabajo del equipo, implantación, formación del personal… Además, esta
fase de definición del proyecto (como la anterior) suele ser gratuita para el
cliente, excepto en el caso de proyectos de gran envergadura.

3. Implantación y formación

Una vez aceptado el proyecto, toca ponerse a trabajar en la implantación. La

clave está en introducir las nuevas soluciones en un plazo rápido de tiempo y
ajustando en todo momento lo que sea necesario, probando las soluciones y
comprobando la satisfacción del cliente. Hardware, software, instalación,
preparación para que todo quede operativo… Todo ello indicando al cliente
cómo utilizar su nuevo equipo.

La fase de implantación va íntimamente unida a la de formación. Y es que

resulta necesario que los trabajadores de la empresa conozcan en
profundidad cómo funcionan las nuevas herramientas de que disponen, no
solo para que comprendan cómo deben realizar ahora sus tareas, sino para

10
que puedan sacar el máximo partido a todas las nuevas funcionalidades. De
esta forma se busca evitar la infrautilización del sistema implantado, algo que
a veces, por pereza o por falta de conocimiento de los empleados, puede
llegar a suceder, restando eficiencia a la inversión.

En este sentido, resulta muy conveniente que, al menos durante un tiempo,

exista un canal de formación y consulta para los empleados. También que la
fase de implantación y formación se lleve a cabo con rapidez, ya que todo el
tiempo que la empresa se encuentre en ese ‘limbo’ informático puede
resultar perjudicial para su actividad.

4. Soporte y mantenimiento

La última fase –no menos importante- es la de soporte y mantenimiento. Se

trata de que tu proveedor informático mantenga una relación ‘en la sombra’
pero constante que consiste precisamente en implantar mejoras y llevar a
cabo un seguimiento del funcionamiento de las soluciones contratadas.
Además, te atenderán en caso de que existan incidencias y se encargarán
de solucionarlas.

Normalmente el mantenimiento preventivo es la opción favorita: se trata de

que tu informático lleve a cabo las operaciones necesarias para que tu
equipamiento reúna las condiciones para el propósito para el que fue
construido y funcione correctamente y al cien por cien durante su vida útil.
Todo ello garantizando la fiabilidad de equipos en funcionamiento antes de
que pueda producirse un accidente o avería.

Las herramientas para hacerlo son muchas: revisión del estado físico de los
equipos y servidores, revisión del estado de la instalación del sistema
operativo, copia de seguridad, comprobación de antivirus, soporte telefónico,
soporte remoto, informes mensuales…

Los motivos por los que un sistema informático puede desajustarse son
muchos: el deterioro provocado por el uso, su obsolescencia, causas
meteorológicas, uso inadecuado… Anteponerse a estos problemas suele ser
mucho más rentable a la larga que optar por un mantenimiento correctivo,
que se basa en llamar al técnico informático solo cuando ya es demasiado
tarde.

11
Así, enmendar el error cuando ya se ha producido no solo supone un coste
técnico (reparación o sustitución del equipo), sino una pérdida temporal de
productividad, al ‘pararse’ la actividad hasta que se solucione la incidencia.

12
 Conclusión
El análisis, diseño y programación orientada a objetos, ha sido desarrollado
para responder a las necesidades de flexibilidad en los sistemas de
información basados en computadora. La encapsulación, herencia y
polimorfismo, tienen como objeto proporcionar sistemas complejos con
mecanismos para un rápido, fácil y confiable mantenimiento y cambio de los
programas. Aunque el desarrollo orientado a Objeto típico involucra una fase
de análisis y diseño más amplia, esta inversión se traduce en menores
costos de operación de los sistemas que es probable que requiera una gran
actividad de mantenimiento.

Existen varias metodologías orientadas a objetos, a pesar que tienen

variantes entre ellas, todas trabajan con el mismo paradigma por tanto se
basan en los mismos fundamentos de modelación de objetos. Este trabajo se
enfoca en la técnica de Análisis y Diseño de Coad y Yourdon, por
considerase sencilla al momento de aplicar para analistas con poca
experiencia.

Las técnicas para el análisis y diseño Orientadas a Objetos todavía están en

desarrollo, esto debido a que la programación misma todavía se encuentra
en esta etapa. Por consiguiente, han surgido tantas metodologías que tratan
este modelo de programación, llegando a destacarse un enfoque de
Modelación de Lenguaje Unificado (UML) como uno de los más prácticos y
eficientes. Sin embargo, no existe una técnica que se haya definido como
estándar para este paradigma.

13
 Bibliografía
- Diseño y Programación Orientada a Objetos. Romero, K. (2014).
- Análisis y Fundamentos del software. Molina, C. (2017).

14
INDICE
Introducción 2
Diseño orientado a objetos. 3
Fundamentos del diseño orientado a objetos: 3
Diseño del componente de dominio problema 3
Diseño de reusó. 3
Estructura de Implementación. 3
Acomodo al lenguaje 3
Diseño del Componente de Interfaz Humana 4
Diseño de componentes de administración de tareas y datos. 4
Enfoques alternativos y notación para su implantación 5
Pruebas Orientadas a Objetos 8
Modelos de pruebas en Orientación a Objetos. 8
Conceptos básicos de la implantación: 9
Fundamentos de la implantación: 9
Fases de la implantación de Sistemas: 9
Conclusión 12
Bibliografía 13

15