https://migabeta.wordpress.

com/2017/01/03/introduccion-al-modelado-y-al-proceso-de-
desarrollo-de-software/

Introducción al modelado y al proceso de desarrollo de software.

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
afronta 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 identificar cuáles son los objetos del
programa. A su vez, tales objetos son instancias de clases, por lo que la primera etapa en el desarrollo
orientado a objetos requiere de la especificación de dichas clases – con sus atributos y
comportamiento-, así como la enumeración de las relaciones mantenidas entre éstas y su posterior
implementación en un lenguaje de programación. Pero en general como ocurre en cualquier proyecto
estructurado, un proyecto software bajo POO se compone de las siguientes etapas:

Análisis Orientado a Objetos (AOO)

Diseño Orientado a Objetos (DOO)

Vemos el curso que hace parte del master en desarrollo web dictado por la U politécnica de Madrid.

Programación Orientada a Objetos (POO)

Según una definición bastante convencional el Análisis Orientado a Objetos (OOA por sus siglas
en inglés de Object Oriented Analysis) sería un método de análisis que examina los
requerimientos desde la perspectiva de las clases y objetos encontrados en el vocabulario de del
dominio del problema.

A su vez, el Diseño Orientado a Objetos resultaría un método de diseño para abarcar el proceso
de descomposición orientado a objetos y una notación para representar ambos modelos lógico y
físico.

Sobre estas premisas puede decirse que las metodologías POO son muy abundantes, entre las más
conocidas y estudiadas hasta antes de la fulgurante aparición del UML estarían:

 Object-Oriented Design (OOD) de Booch.

 Object Modeling Technique (OMT) de Rumbaugh.
 Object Oriented Analysis (OOA) de Coad/Yourdon.
 Hierarchical Object Oriented Design (HOOD) de ESA.
 Object Oriented Structured Design (OOSD) de Wasserman.
 Object Oriented Systems Analysis (OOSA) de Shaler y Mellor.
 Responsibility Driven Design (RDD) de Wirfs-Brock.

Actualmente las metodologías más importantes de análisis y diseño de sistemas han confluido en lo
que se denomina el UML, bajo el respaldo del Object Management Group Los sistemas de
información, sistemas informáticos y las organizaciones son elementos cuyo desarrollo o desempeño
están notablemente ligados, de ahí que su éxito esté estrechamente vinculado, de tal forma que los
logros de uno inciden notablemente en el éxito del otro.

Para entender estos aspectos debemos partir de la idea sistema que es un conjunto de partes,
elementos o cosas interdependientes e interrelacionadas para la consecución de un fin. Aplicado a los
sistemas de información este mismo concepto se entiende como un todo unitario y organizado de
procesos, procedimientos, tareas, métodos y recursos materiales, tecnológicos y humanos
interdependientes, de los que se vale una organización para alcanzar un objetivo, y es fácilmente
identificable por los límites de su medio ambiente. Así las cosas, las organizaciones son sistemas
abiertos, cada una a su vez compuesta por subsistemas de mayor o menor tamaño o complejidad, que
asimismo tiene límites claramente definidos. Todos poseen funciones y objetivos particulares, que
unidos forman las funciones y objetivos de la empresa u organización. Pues bien, si así está
constituida la realidad empresarial, de manera análoga están conformados o estructurados los
sistemas informáticos, también sujetos al correcto desempeño de las funciones de cada subsistema,
para lograr así el buen funcionamiento del sistema y la consecución de todas sus metas.

Al entrar en juego dentro del sistema la información, el sistema quedaría entonces definido como un
medio organizado de proporcionar información pasada, presente y hasta futura relacionada con las
operaciones internas y el conocimiento externo de la organización.

Esto quiere decir que un sistema de información es un ente que sigue una estructura bien organizada
y claramente planteada con el fin de emitir y generar información histórica, actual y proyecciones
futuras inclusive, todo esto con la espina vertebral de las operaciones llevadas a cabo por la
organización.

Lo más característico de los sistemas informáticos y de los sistemas de información es su complejidad.

Toda organización es compleja por naturaleza, todo sistema informático es complejo más por esencia
que por casualidad, de tal manera que el desarrollo de cualquiera, y posteriormente su supervisión
constante, es una tarea difícil que debe, sin embargo, ofrecerse como algo sencillo de manejar a la
larga.

Como ha quedado enumerado anteriormente existen diversas metodologías para la creación de

sistemas informáticos. Cada uno enfoca diversas formas o teorías que permiten tratar de manera
exitosa la complejidad inherente al desarrollo de software. Los métodos de diseño estructurado
surgieron para tutelar a los desarrolladores que intentaban construir sistemas complejos utilizando
algoritmos como bloques fundamentales para la construcción de estos sistemas. Así, los métodos de
diseño orientado a objetos han surgido para ayudar a los desarrolladores a explotar la potencia
expresiva de los lenguajes de programación basados en objetos y orientados a objetos, utilizando las
clases y los objetos como bloques básicos de construcción. La metodología orientada a objetos es un
principio de desarrollo evolutivo, no revolucionario, porque no rompe con los avances del pasado,
sino que los reestructura y los afianza de una forma que el desarrollo de aplicaciones o sistemas es
mucho más sencillo y su proceso de desarrollo mucho más dinámico que con otras metodologías
estructuradas.

Como quedó dicho anteriormente el Análisis Orientado a Objetos (AOO) es un método de

análisis que examina los requisitos desde la perspectiva de las clases y objetos que se encuentran en
el vocabulario del dominio del problema. Dentro de este marco, los objetos serían entidades tangibles
que muestran un comportamiento bien definido. Así, debemos partir de entidades tangibles
identificadas dentro del problema a resolver. Tales entidades varían dependiendo de los diversos
casos prácticos, pero en todos los casos son elementos reales directamente extraídos del problema en
cuestión.
Si, como también quedó reflejado párrafos atrás, el Diseño Orientado a Objetos(DOO) es el
método que lleva a una descomposición Orientada a Objetos, aplicando DOO, se crea software
resistente al cambio y escrito con economía de expresión; se logra un mayor nivel de confianza en la
corrección del software a través de la división inteligente de su espacio de estados y, en última
instancia, se reducen los riesgos inherentes al desarrollo de sistemas.

Los modelos del diseño orientado a objetos reflejan la importancia de plasmar explícitamente las
jerarquías de clases y objetos del sistema que se diseña. Estos modelos cubren también el espectro de
las decisiones de diseño relevantes que hay que considerar en el desarrollo de un sistema complejo, y
así animan a construir implantaciones que posean los atributos de los sistemas complejos bien
formados.

También se dijo del DOO que es un método que abarca el proceso de descomposición orientada a
objetos y una notación para describir los modelos lógico y físico, así como los modelos estático y
dinámico del sistema que se diseña; el soporte para la descomposición orientada a objetos es lo que
hace al diseño orientado a objetos diferente del diseño estructurado. El primero, utiliza abstracciones
de clases y objetos para estructurar lógicamente los sistemas, y el segundo, utiliza abstracciones
algorítmicas.

Dentro de este ámbito, la Programación Orientada a Objetos (POO) aparece como un método
de implementación en el que los programas se organizan como colecciones cooperativas de objetos,
cada uno de los cuales representa una instancia de alguna clase, y cuyas clases son, todas ellas,
miembros de una jerarquía de clases unidas mediante relaciones de herencia.
¿Cómo se conjugan estos tres pilares? Los resultados obtenidos durante el análisis orientado a objetos
sirven como modelo o punto de partida para realizar el diseño orientado a objetos del sistema.
Posteriormente, se procederá, tomando como base dicho modelo realizado en el DOO, a desarrollar
el sistema computacional utilizando para tal fin la metodología de programación orientada a objetos
suministrada por determinado lenguaje de programación igualmente orientado a objetos.

a continuación se presenta una clase dictada desde desarrolloweb.com

El modelo lógico y el modelo físico del análisis

El modelo lógico nos servirá para describir la existencia y significado de las abstracciones
principales y los mecanismos que forman el espacio del problema, o para definir la arquitectura del
sistema. Detallará las características primordiales de las entidades principales (clases y objetos), así
como la forma de trabajo de estas entidades, estructurando sus límites, los pros y contras del
problema planteado, para luego definir o identificar la arquitectura del sistema.

El modelo lógico se representa gráficamente mediante dos diagramas básicos:

a) Diagrama de Objetos: Se utilizan para mostrar la existencia de objetos y sus relaciones en el

diseño lógico de un sistema. Es decir, representa las interacciones o relaciones estructurales que
pueden darse entre un conjunto de instancias (objetos) de clases. Un diagrama de objetos representa
una vista estructurada de los objetos de un sistema. Durante el análisis, se usa para indicar la
semántica de los escenarios primarios y secundarios que proporcionan una traza del comportamiento
del sistema. Durante el diseño, se usan para ilustrar la semántica de los mecanismos en el diseño
lógico de un sistema.

b) Diagrama de Clases: Se utiliza para mostrar la existencia de clases y sus relaciones en la visión
lógica de un sistema. Durante el análisis, se utiliza para indicar los cometidos y responsabilidades
comunes de las entidades que caracterizan el comportamiento de un sistema. Durante el diseño, se
utilizan para plasmar la estructura de las clases que forman la arquitectura del sistema.

Del modelo físico por su parte, es la composición concreta en cuanto a hardware y software del
contexto o implantación del sistema.

Esto no es más que la descripción de la estructura física, o sea el hardware y lógica o software que
componen al sistema. Para representar gráficamente al modelo físico, existen dos diagramas, a saber:

a) Diagrama de Procesos o Actividad: Se usan para mostrar la asignación de actividad a los

procesadores y dispositivos presentes en el diseño físico de un sistema. El diagrama de actividad
representa una vista de la estructura de procesos de un sistema. Durante el desarrollo, se usan para
indicar la colección física de procesadores y dispositivos que sirven como plataforma de ejecución del
sistema.

b) Diagrama de Módulos o Componentes: Se utiliza para mostrar la asignación de clases y

objetos a módulos en el diseño físico de un sistema. Un diagrama de módulos representa una vista de
la estructura física de módulos que componen un sistema. Durante el desarrollo, se usan para indicar
la disposición en capas y la participación física de la arquitectura.
Es pertinente destacar que el diseño lógico se lleva a cabo, básicamente, durante las fases de análisis
y diseño del sistema, mientras que el modelo físico, se desarrolla, más bien durante la fase de
programación.

Tal como se mencionó anteriormente el modelo de desarrollo orientado a objetos está conformado
por los modelos lógico y físico, así como también por los modelos estático y dinámico, estos modelos
explican que, algunos diagramas son estáticos mientras que otros son de carácter dinámico. Por
ejemplo, los diagramas implementados en el modelo físico son fuertemente estáticos. No representan
o simbolizan ningún tipo de relaciones que involucren el movimiento o flujo de acciones que disparen
eventos, lo que genera una visión sumamente estática del sistema. Mientras que los diagramas del
modelo lógico amplían la visión del modelo físico, generando de esta forma una visión sumamente
amplia de cómo actúa el sistema.

Las etapas del análisis y del diseño orientado a objetos

Aunque no siempre están bien delimitadas las etapas de análisis y diseño en la POO, 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.

Así, se considera que las etapas del proceso en un desarrollo orientado a objetos son:

Estas etapas suelen seguirse por la mayoría de los métodos de diseño OO existentes.
De hecho, para los sistemas orientados a objetos se suelen definir según el siguiente formato en
pirámide.sss

La capa del subsistema. Contiene una representación de cada uno de los subsistemas que le
permiten al software conseguir los requisitos definidos por el cliente e implementar la
infraestructura técnica que los soporta.

La capa de clases y Objetos. Contiene las jerarquías de clase que permiten crear el sistema
usando generalizaciones y especializaciones mejor definidas. Esta capa también contiene
representaciones de diseño para cada objeto.

La capa de mensajes. Contiene los detalles que le permiten a cada objeto comunicarse con sus
colaboradores. Esta capa establece las interfaces externas e internas para el sistema.

La capa de responsabilidades. Contiene las estructuras de datos y el diseño de algoritmos para

todos los atributos y operaciones de cada objeto. Esta pirámide de diseño se centra entonces en
el diseño de un producto o sistema específico.

Al igual que el diseño de software convencional, el DOO aplica diseño de datos (cuando se representan
atributos), diseño de interfaces (cuando se presenta el intercambio de mensajes) y diseño
procedimental (en el diseño de operaciones), no obstante el diseño arquitectónico es diferente. La
arquitectura de diseño OO se centra más en las colaboraciones entre los objetos que con el flujo de
control de datos. De esta manera las capas de la pirámide se renombran para reflejar de forma más
exacta la naturaleza del DOO. La siguiente figura muestra ahora la correspondencia entre el AOO con
las correspondientes capas de la pirámide de diseño OO.

Algunos criterios nos permiten juzgar la capacidad que posee un método de diseño en poder lograr
ciertos elementos importantes tales como la modularidad:

Descomposición. Facilidad con la cual un método de diseño ayuda al diseñador a descomponer un

gran problema en microproblemas más sencillos de resolver.

Composición. Grado con el cual un método de diseño asegura que los componentes de un programa
(módulos), una vez diseñados y construidos, pueden reusarse para crear otros sistemas.

Comprensibilidad. Facilidad de comprensión de un componente de programa sin referencia a otra

información o módulos.

Continuidad. Facilidad de hacer pequeños cambios en un programa y hacer que estos se manifiesten
por sí mismos en cambios correspondientes solamente en no o unos pocos módulos más.

Protección. Característica arquitectónica que reducirá la propagación de efectos colaterales si

ocurre un error en un módulo dado.

Estos criterios y principios de diseño pueden aplicarse a cualquier método de diseño, incluyendo el
antiguo diseño estructurado. No obstante, el método de diseño orientado a objetos logra cada uno de
los principios de manera más eficiente que otros enfoques y el resultado final es una arquitectura
modular que permite cumplir con todos los principios de modularidad de una manera más eficiente.

Terminología básica de análisis y diseño: Método, modelos, diagramas, frameworks y patrones

Al estudiar las metodologías de análisis y diseño orientadas a objetos, se manejan algunos conceptos
que es bueno delimitar de manera precisa.

Métodos. Son un conjunto de reglas.

Modelo es una representación formal de un sistema con cierto nivel de abstracción. En las etapas de
especificación de requerimientos y análisis el nivel de abstracción normalmente es alto, omitiendo
detalles de implementación.

Metamodelo. Es un modelo que describe otros modelos, describe los conceptos del método modelo
y sus relaciones, define los modelos legales que pueden ser construidos dentro del método, describe
la información que debe ser capturada usando herramientas CASE que soporten el método.

Vistas y notaciones. Son útiles en la presentación fundamental del modelo de información para
que los seres humanos puedan comprenderla, examinarla y modificarla en su caso. Una vista solo
muestra una parte de la semántica o información del modelo y diferentes vistas pueden presentar la
misma información en varias formas. Mientras que la notación consigue construir, examinar y
manipular modelos. El mismo modelo se puede dibujar de diferentes maneras mediante el uso de
diferentes símbolos, donde algunos de ellos pueden tener el mismo significado. Cada persona puede
adoptar su propio formato para describir sus diagramas.
Artifacts. Término anglosajón que remite a los modelos y los diagramas del proceso de
desarrollo. Estos los documentos de desarrollo que los expertos del dominio, directores y clientes
pueden examinar, comentar acerca de ellos y criticar. Son las variables que miden el progreso, los
archivos que pueden ser intercambiados entre diseñadores y entre herramientas.

Proceso de desarrollo iterativo. Representa una secuencia de pasos para la construcción e

implementación de modelos. El proceso puede estar distribuido en varios niveles de detalle, desde el
nivel más alto del proyecto, hasta etapas específicas para la construcción de modelos de bajo nivel. El
proceso indica que modelos se deberán construir y como construirlos. En la siguiente imagen vemos
un ejemplo figurada de un proceso de desarrollo iterativo para desarrollo de software:

Proceso. Es la guía que indica como producir un modelo, proporciona un esqueleto o plataforma de
trabajo (frameworks) para el desarrollo, describe los artifacts a ser producidos y las etapas para
producirlos. A alto nivel, describe el desarrollo del ciclo de vida y las etapas de iteración dentro de él.
A bajo nivel describe un esqueleto de trabajo para la producción de modelos; las etapas para la
construcción del modelo, principios de diseño a seguirse, mediciones de calidad, referencias cruzadas,
reglas de consistencia y banderas rojas para identificar posibles problemas.

Patrón. Es una solución estándar escrita para resolver un problema, basada en una secuencia de
tiempo. No existen museos de programas donde los nuevos diseñadores puedan aprender, emulando
programas que allí existen, mas bien, tratan de captar ideas de los diseñadores expertos. Actualmente
existe un Movimiento de Patrones, con el propósito de coleccionar, catalogar y explicar patrones
útiles de diseño, de tal forma que otros diseñadores puedan aprender de ellos. Por lo tanto, los
Patrones, son resúmenes de casos de diseño basados en la experiencia.

Algunas metodologías de análisis y diseño famosas

Una vez conocido todo lo explicado en los epígrafes precedentes, estamos en condiciones de
comprender algunas propuestas teóricas y metodológicas de análisis y diseño de software orientado
 a objetos. Es opinión extendida que dentro de los enfoques AOO y DOO existen dos corrientes
principales:

Estáticos (enfocados a datos), en lo que lo importante es la estructura de datos anexa a los objetos y
las operaciones que sobre ella operan.

Dinámicos (enfocados a comportamientos o enfocados a responsabilidades): un objeto tiene

sentido en estos métodos cuando exhibe un comportamiento diferencial respecto del resto de los
objetos. Tal comportamiento puede referirse bien al objeto en sí (los cambios que pueden operarse
en su representación interna), o bien a sus relaciones con otros objetos.

Lo cierto es que ésta es una diferencia puramente teórica. La mayoría de las metodologías tiende a los
esquemas puramente dinámicos. En general, cualquier metodología buscará que:

Los cambios de diseño necesarios estén localizados, y resulten improbables las interacciones
inesperadas con otros módulos del programa.

El diseño basado en objetos sea adecuado para una realización distribuida, paralela o secuencial.

Procurará eliminar las zonas compartidas de datos, reduciendo, de esta manera, la posibilidad de
modificaciones inesperadas, así como otras anomalías en la actualización.

Los métodos de diseño orientados a objetos compartirán los siguientes pasos básicos de diseño,
aunque en su detalle final pueda haber grandes diferencias:

Identificar los objetos y sus atributos, así como los nombres de los métodos.

Establecer la visibilidad de cada objeto en relación con los demás objetos.

Establecer la interfaz de cada objeto y el tratamiento de excepciones.

Realizar y comprobar los objetos.

Examinemos ahora, sucintamente, algunas de las metodologías más famosas en la programación

orientada a objetos y que han recibido el nombre de sus autores:

Metodología de Booch: El método original de Booch comienza por un análisis de flujo de datos,
que se utiliza entonces como ayuda para identificar objetos, buscando tanto objetos concretos como
objetos abstractos en el espacio del problema, que se encontraran a partir de las burbujas y almacenes
de datos en el diagrama de flujo de datos (DFD). La notación y método de diseño revisados de Booch
consta de 4 actividades principales y 6 notaciones. Los primeros pasos tratan los aspectos estáticos
del sistema, tanto en su aspecto lógico como en su aspecto físico.

Estructura lógica compuesta de:

 Diagramas de clases
 Diagramas de objetos
 Estructura física:

 Diagramas de módulos
 Diagramas de procesos
 Dinámica de clases
 Diagramas de transición de estados
 Dinámica de instancias
 Diagramas temporales

El método Booch es uno de los métodos mejor desarrollado y con más éxito comercial, en el que se
han inspirado otros muchos teóricos de la metodología y aplicado numerosas empresas de desarrollo
de software.

Método Hood: La noción de la jerarquía de prioridades es aprovechada también por otro método,
HOOD. La “H” de HOOD quiere decir jerárquico. En HOOD los objetos son o pasivos o activos. Los
objetos pasivos solamente son capaces de utilizar los objetos de otros objetos pasivos, pero los activos
pueden utilizar los servicios de cualquier objeto. HOOD es un método de refinamiento progresivo que
se basa en la descomposición de un objeto del máximo nivel y, posteriormente, en la descomposición
de los objetos así resultantes. El método HOOD utiliza un cierto número de pasos para descomponer
cada objeto, comenzando por un paso de diseño básico que podría implicar técnicas de realización de
diagramas de procedentes de otros métodos de análisis y diseño estructurado. El paso siguiente
consiste en generar una estrategia informal de soluciones. Esto se descompone en un cierto número
de tareas: un esbozo del lenguaje natural, diagramas HOOD de primera mano y una descripción del
nivel actual de abstracción. El tercer paso consiste en formalizar la estrategia de solución. Esto se hace
por fases, identificando y describiendo los objetos y sus operaciones.

Método OOSD: Es el diseño estructurado orientado a objetos (OOSD), que fuera presentado por
Wasserman, Picher y Muller (1990). Hablando estrictamente, OOSD no es un método sino una
notación a la cual se pueden agregar reglas metodológicas. Esta notación es probablemente la que
más próxima se encuentra al espíritu de la orientación a objetos. OOSD es una notación para el diseño
arquitectónico, que cambia el diseño por refinamiento progresivo estructurado y el diseño orientado
a objetos. Una vez más, OOSD emplea una notación que se deriva de la de Booch, pero, también tiene
influencia de los diagramas estructurales. OOSD no es tanto un método como un tipo de notación
para apoyar los métodos de diseño orientado a objetos en general. Los usuarios de OOSD pueden
añadir reglas de diseño según cuál sea el método concreto que esté utilizando. Otros puntos
importantes de OOSD son la facilidad con la que es aceptado por los desarrolladores que ya están
familiarizados con el diseño estructurado así como lo adecuado que resulta para los sistemas de
tiempo real. OOSD es una de las notaciones de diseño más avanzadas y adecuada para el diseño
arquitectónico o lógico más que para el diseño físico.