martes, 16 de octubre de 2018

DSN_XP y el método OOSE

Dentro del estudio de UML bajamos a las raíces de sus artefactos y esto implicó el desarmar el método propuesto por Jacobson para el Análisis y Diseño orientado a objetos como uno de sus precursores.


CVDS: 


Desarrollo iterativo e incremental, orientado al análisis, diseño y codificación por componentes.

ESCUELA DE DISEÑO: 

Orientación a objetos, orientación a componentes, los casos de uso originan el método

FECHA: 1992 (OBJECTORY)

FLUJOS DE TRABAJO: 


Arquitectura, análisis y diseño orientado a objetos, codificación orientada a componentes e implementación.

MÉTODO: 


El método se divide en 2 procesos una macro y otro micro, ambos procesos incluyen las etapas mencionadas pero se diferencian por el nivel de abstracción requerido de los objetos.

El proceso micro propone:

Una vez realizada la captura de requerimientos y el entendimiento del problema mediante los casos de uso, se define una arquitectura que soporte como guía al proceso de análisis y diseño debido a la noción de componentes como unidades modulares independientes que contienen objetos relacionados entre sí por su razón de uso (use case), el proceso de análisis y diseño se preocupa por definir los objetos, organizarlos, describirlos en sus relaciones y establecer su estructura interna (tipo y atributos), el proceso de construcción contempla objetos propios de la implementación diferentes del análisis y diseño con el objetivo de mantener intacto el diseño inicial, el proceso se repite y se refina continuamente hasta lograr el objetivo planteado por la arquitectura que dirige todo el proceso en sí.

Artefactos y/o Diagramas:

Los artefactos utilizados por OOSE son bastante parecidos a los propuestos por OMT, la diferencia fundamental radica en los denominados casos de uso que se convierten en el corazón del método y de los cuales se realiza los demás artefactos. OOSE potencia el uso de diagramas de interacción, diagramas de secuencia, diagramas de estados, diagramas de clases, diagramas de componentes.

Referencias: 

http://www.ivarjacobson.com/default.aspx
http://blog.ivarjacobson.com/ivarblog/
http://en.wikipedia.org/wiki/Ivar_Jacobson
http://en.wikipedia.org/wiki/Use_case
http://www.mactech.com/articles/frameworks/7_1/SWare_Engin_Review_Sandvik.html

DSN_XP y el método OMT

Dentro del estudio de UML bajamos a las raíces de sus artefactos y esto implicó el desarmar el método propuesto por Rumbaugh para el Análisis y Diseño orientado a objetos como uno de sus precursores.



CVDS: 


Desarrollo iterativo y secuencial, OMT sólo identifica los flujos de trabajo de análisis y diseño y no contempla los demás flujos.

ESCUELA DE DISEÑO: 

Orientación a objetos

FECHA: 1991 (GENERAL ELECTRIC LABS)

FLUJOS DE TRABAJO: 


Análisis del dominio del problema, diseño del sistema, diseño de objetos, implementación.

MÉTODO: 


El análisis comienza con el descubrimiento del problema y su modelado bajo entidades básicas del dominio (lenguaje apropiado para el negocio), este previo análisis permite definir el comportamiento deseado de las entidades y se define el alcance del sistema, para lograr modelar el sistema se utiliza la técnica TOP-DOWN (describir la complejidad en partes sencillas) y se definen los subsistemas desde el punto de vista arquitectónico logrando así establecer una estrategia de descomposición, el diseño de objetos considera la estructura de datos de las entidades y los algoritmos necesarios para implementar el comportamiento deseado de las clases principales, se consideran las relaciones entre las entidades (modelo E/R orientado a las clases) y se construye un diccionario de entidades, la herencia se puede usar para generalizar los aspectos comunes de las clases existentes construyendo una superclase o para refinar una clase en subclases especializadas, finalmente se comprueba el diseño de objetos mediante las asociaciones establecidas para responder a inquietudes del negocio (aspectos de consumo y construcción de información sobre data básica de entrada) El proceso de implementación de la solución considera el uso adecuado de lenguajes de programación (sean o no orientados a objetos) y la capacidad de persistencia en bases de datos.

Artefactos y/o Diagramas:


El método utiliza 3 perspectivas: (1) Estática (Modelo de objetos = diagrama del modelo de objetos + diccionario de datos), (2) Dinámica (diagramas de estados + diagrama global de trazado de eventos ) y (3) Funcional (diagramas de flujo de datos + restricciones) 

Nota: se requieren modelos comunes durante el desarrollo desde las 3 perspectivas y se verifican, iteran y refinan las tres perspectivas continuamente.

Referencias: 

http://www.ibm.com/developerworks/rational/library/139.html#author1
http://en.wikipedia.org/wiki/James_Rumbaugh
http://en.wikipedia.org/wiki/Object-modeling_technique
http://marchingcubes.org/index.php/Object_Oriented_Modeling
http://www.mcc.unam.mx/~cursos/Objetos/Omt/omt.html

DSN_XP y el método BOOCH

Dentro del estudio de UML bajamos a las raíces de sus artefactos y esto implicó el desarmar el método propuesto por Booch para el Análisis y Diseño orientado a objetos como uno de sus precursores.


CVDS: 


Desarrollo iterativo y secuencial, BOOCH sólo identifica los flujos de trabajo de análisis y diseño y no contempla los demás flujos.

ESCUELA DE DISEÑO: 

Orientación a objetos

FECHA: 1991 (RATIONAL SOFTWARE)

FLUJOS DE TRABAJO: 


Análisis de requerimientos, análisis de dominio, diseño orientado a objetos.

MÉTODO: 


El método se divide en 2 procesos una macro y otro micro, ambos procesos incluyen las etapas mencionadas pero se diferencian por el nivel de abstracción requerido de los objetos.

El proceso micro propone:

Identificación de clases y objetos, proposición de objetos candidatos, análisis de comportamiento, identificación de escenarios relevantes, definición de atributos y relaciones para cada clase, identificación de la semántica de clases y objetos, selección y análisis de escenarios, asignación de responsabilidades para alcanzar el comportamiento deseado, división de responsabilidades para equilibrar el comportamiento, selección de objetos y definición de su comportamiento como actor y sus responsabilidades, definición de operaciones para satisfacer las responsabilidades, búsqueda de colaboración entre objetos, identificación de interrelaciones entre clases y objetos, definición de la dependencia que existen entre objetos, descripción del papel de cada objeto participante. 

El macro proceso propone:

Validación de escenarios por revisión completa, refinamiento sucesivo, producción de diagramas apropiados para el proceso micro, definición de jerarquías de clases apropiadas, agrupamientos basados en clases comunes, implementación de clases y objetos. 

Artefactos y/o Diagramas:

El método utiliza 3 perspectivas: (1) Estática (diagrama de clases y objetos), (2) Dinámica (estados de transición e interacción ) y (3) Lógica (módulo y procesos)

Referencias: 

https://www.ibm.com/developerworks/mydeveloperworks/blogs/gradybooch
http://metodologia-de-booch.blogspot.com/2009/06/metodo-booch.html
http://en.wikipedia.org/wiki/Grady_Booch
http://www.mactech.com/articles/frameworks/6_4/OO_Analysis_and_Design.html

DSN_XP y el modelado con UML

Esta sección contiene el registro de la investigación realizada sobre el lenguaje unificado de modelado UML dentro del estudio y diseño de DSN_XP.

Los criterios de modelado y su relación con UML


El Lenguaje Universal de Modelado (UML) es independiente del proceso de desarrollo, lo que significa que como lenguaje no está ligado a ningún modelo del ciclo de vida del desarrollo de software (CVDS) en particular.

Todo método sobre desarrollo de software requiere por defecto definir un modelo CVDS, es decir, la forma en la cual se va a gestionar el proceso de desarrollo del software.

UML puede representar este modelo CVDS mediante un diagrama estereotipado de actividades.

Las escuelas de diseño y el modelado del sistema


La forma en la cual se diseñe el sistema software depende de las guías de diseño definidas para ello, UML no es una guía de diseño para desarrollar software; proporciona un lenguaje de modelado que soporta tanto la orientación a objetos como otros paradigmas de desarrollo. 

UML no posee un modelo para representar modelos, solventa este problema por la noción de paquetes estereotipados.

La necesidad de utilizar perspectivas en el modelado


Un modelo es una abstracción de un sistema; un subsistema representa una partición de los elementos de un sistema más grande en partes independientes, los subsistemas y el sistema global pueden modelarse desde muy diferentes puntos de vista. 

Una vista es una proyección de la organización y estructura de un sistema centrada en un aspecto particular del mismo. 

UML posee la noción de paquetes que contienen todas las abstracciones pertinentes para esa vista

Modelado de la arquitectura de un sistema


Cuando se modela la arquitectura de un sistema, se capturan las decisiones sobre los aspectos estructurales y de comportamiento de los sistemas y los patrones que configuran estas vistas.

UML posee diversos artefactos para soportar las vistas requeridas para modelar la arquitectura del sistema (4+1), los patrones de diseño se modelan como colaboraciones.

Modelo conceptual de UML


El modelo conceptual de UML está conformado por los bloques básicos de construcción UML, (elementos, relaciones y diagramas), las reglas que dictan cómo se pueden combinar los bloques básicos (reglas semánticas para nombres, alcance, visibilidad, integridad, etc.) y algunos mecanismos comunes que se aplican a través de UML (especificaciones, adornos, divisiones comunes, mecanismos de extensibilidad)

Apuntes DSN_XP sobre UML 


UML: Lenguaje de modelado para visualizar, especificar, construir, documentar software

UML como lenguaje de modelado provee 5 vistas para modelar toda la arquitectura software, posee la vista de diseño, la vista de procesos, la vista de implementación la vista de despliegue y la vista de casos de uso.

DSN_XP no reconoce a los casos de uso como un artefacto orientado a objetos y no recomienda utilizar la noción de relaciones en los diagramas de clases ya que las relaciones en base a asociaciones no son tampoco recomendadas por DSN_XP en el diseño orientado a objetos.

Inicios de UML como lenguaje de modelado


El método de Booch era particularmente expresivo durante las fases de diseño y construcción de los proyectos, OOSE proporcionaba un soporte excelente para los casos de uso como forma de dirigir la captura de requisitos, el análisis y el diseño de alto nivel y OMT era principalmente útil para el análisis y para los sistemas de información con gran cantidad de datos.

“Como creadores principales de los métodos de Booch, OOSE y OMT, nos sentimos motivados para crear un lenguaje unificado de modelado por 3 razones. En primer lugar, cada uno de nuestros métodos ya estaba evolucionado independientemente hacia los otros dos. Tenía sentido hacer continuar esa evolución de forma conjunta en vez de hacerlo por separado, eliminando la posibilidad de cualquier diferencia gratuita e innecesaria, en segundo lugar, al unificar nuestros métodos, podríamos proporcionar cierta estabilidad al mercado orientado a objetos, permitiendo que los proyectos se pusieran de acuerdo en un lenguaje de modelado maduro y permitiendo a los constructores de herramientas que centraran en proporcionar más características útiles. En tercer lugar, esperábamos que nuestra colaboración introduciría mejoras en los tres métodos anteriores, ayudándonos a capturar lecciones aprendidas y a cubrir problemas que ninguno de nuestros métodos había manejado bien anteriormente” [UML]

Metas propuestas por UML


  1. Modelar sistemas, desde el concepto hasta los artefactos ejecutables utilizando técnicas orientadas a objetos.
  2. Cubrir las cuestiones relacionadas con el tamaño inherentes a los sistemas complejos y críticos.
  3. Crear un lenguaje de modelado utilizable tanto por las personas como por las máquinas.
Curiosamente, un montón de empresas de desarrollo de software comienzan queriendo construir rascacielos pero enfocan el problema como si estuvieran enfrentándose a la caseta de un perro :o)
Las ventajas del modelado son:

  1. Los modelos nos ayudan a visualizar cómo es o queremos que sea un sistema.
  2. Los modelos nos permiten especificar la estructura o el comportamiento de un sistema.
  3. Los modelos nos proporcionan plantillas que nos guían en la construcción de un sistema.
  4. Los modelos documentan las decisiones que hemos adoptado.

Principios de modelado

  • La elección de qué modelos crear tiene una profunda influencia sobre cómo se enfrenta un problema y cómo se da forma a una solución.
  • Todo modelo puede ser expresado a diferentes niveles de precisión.
  • Los mejores modelos están ligados a la realidad.
  • Un único modelo no es suficiente. Cualquier sistema no trivial se aborda mejor a través de un pequeño conjunto de modelos casi independientes.

DSN_XP soporta varios lenguajes de modelado pero usualmente recurre a UML por estándar y lenguaje de modelado más conocido.

Referencias

El lenguaje unificado de modelado, Booch et al, Addison Wesley, 1999, ISBN:84-7829-028-1


domingo, 22 de julio de 2018

DSN_XP y el método Codificar_Corregir

DSN_XP.Nucleo.CVDS.Code_fix feb2006



Modelo: Codificar y corregir
Recomendación: El más utilizado

Ventajas de aplicar el modelo CVDS codificar y corregir


DSN_XP soporta por su filosofía de diseño basada en la ingeniería inversa el modelo codificar y corregir <<Code_fix>> esto significa que DSN_XP está dirigida o <driver by> por el código fuente.

Ahora bien, concluir que un modelo es erroneo es incorrecto, el modelo por concepto es correcto pues representa bajo el proceso de abstracción una realidad y nadie discute si la realidad es incorrecta o si_???

Cuando nosotros (DSN_XP) aplicamos la ingeniería inversa en la creación de nuestros modelos, tenemos muy en claro la concepción del error como elemento fundamental para el análisis, el diseño está omnipresente a lo largo del desarrollo de un producto software bajo la noción del prototipado.

Este modelo representa si se lo entiende muy bien, la gran ventaja de que el programador sabe lo que quiere programar, investiga al lenguaje y a la vez investiga la arquitectura además de la estructura.

La falencia de conocimientos teóricos respecto al cómo utilizar un modelo es resuelta por la experiencia, la práctica, la definición de un método. Bajo este razonamiento, un modelo no es una metodología, por lo tanto no puede decirse de este modelo <<Code_fix>> es una metodología :o)

En cuanto al desorden, este puede presentarse al aplicar otros modelos CVDS, por lo que no es culpa del modelo sino de la metodología asociada al explicar el uso tanto de métodos y artefactos, así como el uso asistido por computadora (RAD)

Finalmente levante la mano entre el público lector, aquel que no ha utilizado este modelo o lo sigue utilizando hasta lograr confiar en él como un modelo certero pues hasta ahora sigue dando resultados.

La teoría responde que este modelo incluye todas las fases por las cuales debe pasar el proceso de desarrollo, la investigación, planificación, etc, etc, pueden ser representadas en un orden secuencial solo con fines académicos.

Estas fases son:


  • Codificar: definir la estructura interna con objetivos reutilizables.
  • Corregir: Implementar el sistema mediante el registro de errores para la definición de patrones reutilizables.

domingo, 15 de julio de 2018

DSN_XP y el diseño de software

DSN_XP.Arquitectura.FAQs.Metodología feb2004


Durante el diseño de nuestro marco de trabajo (considerado como una tesis para la obtención de la ingeniería), era necesario responder sobre la practicidad de nuestro método de investigación para el desarrollo, diseño y sustento de un marco de trabajo.

Durante esta primera etapa, teníamos que desarrollar la capacidad de responder si era necesario o no utilizar una metodología para desarrollar software, de serlo, ¿cuál sería la mejor metodología?...

Responder a esta pregunta, nos motivó a que en foros de discusión, crucemos ideas con otros sobre este mismo tema y otros más relacionados con la ingeniería de software y la gestión de proyectos software.


¿Es DSN_XP una metodología de investigación científica? <<Resumido>> <<Diferido>>

</OffTopic>

Mil disculpas al grupo de discusión, en especial al señor moderador, por utilizar este canal de retroalimentación para fines personales :o)

La temática del grupo reza así:

“Comunidad virtual de profesionales y/o estudiantes de habla castellana para discutir, por ejemplo: ciclo de vida;técnicas, metodologías y tecnólogos/metodólogos —como Boëhm, Booch, Chen, Coad, De Marco,Humphrey, Jacobson, Jacopini, Martin, Mellor, Nassi, Pressman, Rumbaugh, Shlaer, Yourdon y más—; Ingeniería de Sistemas Asistida por Computadora —Computer-Aided Systems Engineering (CASE)—; proyectos; planificación; requerimientos; análisis, procesos, viabilidad/factibilidad; modelado de datos —entidad-relación (E/R), IDEF1X, etc.—; diseño de sistemas, bases de datos, interfaces de usuario; implantación, despliegue, soporte y mantenimiento; etc.” [*SI]

</OffTopic>

<Temática>

Estimado Osvaldo, felices días para ti y para cada uno de los miembros del grupo SI :o)

Me he tomado la libertad de utilizar este canal de retroalimentación para sostener el debate planteado, en vista de que otros miembros no se han manifestado y tampoco ha existido una sugerencia de parte del moderador del grupo.  Como miembro del mismo, puedo comenzar el debate de tan importante tema para la ingeniería software.

Sin embargo, por la amplitud de la temática, me gustaría sugerir una estrategia común entre tu forma de razonamiento y el mío.  Tu nivel de cultura informática es muy avanzado <<Lejano>> (lejos de ver claramente) para mi estructura de pensamiento actual ¿Por qué?

La observación demuestra que en un intercambio de ideas, cada interlocutor tiende a llevar la información hacia su estructura de pensamiento (esto lo demostró Turing con su test de Turing).


Esta información es transmitida en forma paralela y bidireccionalmente a través del canal de retroalimentación establecido entre el emisor y el receptor. <<OffTopic: por no pensar en esferas>> <<Diferido>>

Para poder ponernos de acuerdo, es necesario resaltar un punto común de perspectivas, este punto lo denomino el de mayor perspectiva de información <<Perspectiva de ubicación>> <<Diferido>> [DSN_XP]

</Temática>

<Preguntas>

El diccionario es uno de los artefactos más importantes del diseño, en este caso solo me interesa la definición de metodología de desarrollo del software. Las siguientes preguntas son consideradas como frecuentes:

<FAQs>

¿Qué es metodología?, ¿Qué es método?, ¿Qué es modelo?

<<Esta preguntas fueron planteadas en el foro del señor Rodolfo Quispe , miembro de esta comunidad [*Ingenieríadelsoftware]>> <<Referido>> <<Recomendado>>

</FAQs>

</Preguntas>

Sin embargo, contestar sobre una metodología de desarrollo de software, es muy difícil ¿Por qué?

Estas fueron las evidencias que encontré al plantear mi metodología: <<Diferido>>

¿Cómo puedo aplicar el método científico en la concepción de DSN_XP?

El estudio de la ingeniería software como método para la concepción del software cae necesariamente en una investigación intelectual, ésta es diferente con la física que planteas, que es más material. Ahora que, para ponernos de acuerdo debo manifestar que mi estructura de pensamiento esta regida por el pensamiento dialéctico, por lo tanto materialista <<Discutible>> <<Diferido>>

Investigaciones al respecto en mi base de conocimiento, hacen referencia a la Universidad Rey Juan Carlos de España y el proyecto Kybele [*Kybele] <<Enlace HTML>>

Este estudio manifiesta que no son aplicables los métodos científicos tradicionales al estudio del software, lo cual comparto como evidente desde mi experiencia.

El proceso cognoscitivo de la concepción de software se vuelve entonces en mi objeto de estudio, para lo cual es preciso aplicar un método científico de investigación (¿Cuál es el más apropiado?), la segunda evidencia refleja que la teoría dialéctica se acopla de mejor forma al proceso del diseño del software y su estudio, por un simple hecho, su carácter objetivo.

Existe una interesante observación al comparar el método científico de investigación y el método de diseño y desarrollo del software, por ejemplo:

  • La fase de captura de requisitos e investigación del negocio se asemejan en concepto al proceso de abstracción del método científico.
  • La fase de diseño y codificación del software se asemeja a la estructura de pensamiento para obtener el razonamiento correcto (experimentar).
  • Los métodos diferentes a la dialéctica consideran un solo paso en el proceso de abstracción, pero este paso queda incompleto si no se vuelve al objeto con conocimiento de causa (concretación), esto es ingeniería inversa. <<Diferido>>

</Temática>

“Moviéndonos hacia el lado de la Ciencia y dejando la Filosofía de lado entramos de lleno en la lógica la modelización y la resolución de problemas. Este si es el campo de mi interés” [*Osvaldo]

Al igual que el mío.

“Si me concentro en la Resolución de Problemas llegará a la conclusión que solo puedo resolver un problema en tanto haya realizado un Modelo de Información del Problema, Contexto, Dominio y Medio” [Ibíd.] 
Este primer paso en la concepción del software es el límite del software, por lo tanto como evidentemente razonas entramos en la discusión de la forma y el contenido.

“La relación de Problema y Contexto ha quedado patentizada en la Física Teórica , sobre todos en la teorías de Simetrías” [Ibíd.]

Añado que este dilema está presente todo el tiempo y es una característica del desarrollo (Dialéctica, lucha de contrarios).

“Y brevemente indican que muchas veces cambiando el punto de enfoque lo que parecía un problema, ya no lo es decir al reencuadrar el problema en un contexto diferente desaparece” [Ibíd.]

Este proceso se conoce como un “salto”, sin embargo debo aclarar que no desaparece, persiste pero en condiciones diferentes (Dialéctica, salto de lo cuantitativo a lo cualitativo y viceversa).

“El Dominio está relacionado en mucho con lo que nos ha enseñado la metodología orientada a objetos, es decir considera a todos aquellos elementos (objetos) que están relacionados de alguna forma con nuestro problema y con nuestro contexto. Y luego nos queda el medio que es lo que excede a nuestro 'ambiente'” [Ibíd.]

Totalmente de acuerdo, sin embargo este es el aspecto de más riesgo en el proceso productivo (¿evidencia una falla en el diseño?) <<Crisis del software>>

“Desde otro punto de vista, se debe buscar la relación entre fondo, forma y función, y cuanto más cercana este esta relación a los valores estéticos de una cultura mas apetecible la solución será” [Ibíd.]

Esto es la definición de un modelo o patrón, sin embargo refiere al marketing como campo de acción en la actualidad <<La nueva crisis del software>> <<Diferido>>

“Teniendo en claro esto como Objetivo o Modelo de Conocimiento pasamos a considerar que tipo de lógica tiene la capacidad para resolver problemas y luego que tipo de problemas pueden ser resueltos por dicha lógica” [Ibíd.]

La investigación refleja que las metodologías se preocuparon primero por el proceso de diseño para luego enfocarse en el proceso de análisis, lo que evidencio con mi experiencia.

“En mi caso mi óptica cambió cuando pasé de la lógica binaria convencional (la cual se inicia con Descartes), (tesis-Antítesis) a una lógica trinaria que es propia del Unicismo” [Ibíd.]

Pues aquí aparece el punto de fuga entre tu perspectiva y la mía <<Pensamiento dialéctico>>

“No ahondaré a.C. en esta lógica trinaria, pero si puedo decirle que es de un orden superior a la binaria” [Ibíd.]
<<Sin comentarios>> estoy de acuerdo :o)

“Si Ud logra darse cuenta de cuales son los problemas que tienen solución con la lógica que Ud utiliza y cuales no, entonces podrá darse cuenta de cuales son las limitaciones de su Modelo y por ende de la Metodología que se deriva de dicho Modelo” [Ibíd.]

Completamente de acuerdo y si no me equivoco se denominan esenciales [*Bohem]

“Este fue justamente el caso de Eisntein, una persona con tal claridad mental llego a encontrar las limitaciones de la teoría física de su tiempo y a generar un Modelo alternativo mucho más abarcativo” [Ibíd.]

<<Sin comentarios>>

“Generado el modelo pasó a diseñar una nueva Teoría y Metodología asociada” [Ibíd.]

Esta es la parte que impactó en mi razonamiento por la siguiente razón:

Hace poco hice una pregunta en dos foros sobre el modelo del ciclo de vida del software CVDS y si debe ser considerado como metodología de desarrollo. <<Diferido>>

La investigación refleja que no es tan descabellada la idea (aunque no son lo mismo), es decir ¿es un modelo una metodología? Justamente se presenta este punto de fuga por existir una sola metodología asociada <<Parte de tu razonamiento>> <<Diferido más adelante>>

“Pero dado que los 'problemas terrenales no le interesaban, allí dejo su teoría. Otras personas más cercanas a los problemas terrenales, diseñaron experimentos y comprobaron que la Teoría se convalidaba con la práctica, por lo cual la metodología debería ser valida. Ya que no soy físico, dejemos el tema para ellos, pues hasta aquí llega mi conocimiento sobre el particular” [Ibíd.]

Hace poco observé un programa por cable (Discovery) en el que los físicos astrónomos reconocieron que los modelos que diseñaban para entender la configuración del Cosmos, no les servían porque contínuamente fracasaban en la experimentación.

Esta verdad evidencia necesariamente al “fallo” como un dato importante en el proceso de diseño (uso de prototipos)

“Llegado a este punto Ud posee una Metodología la cual, por fuerza, deberá aglutinar a un conjunto de Métodos que operan en la práctica. Queda ahora validarla (o falsarla, como diría Popper)” [Ibíd.]

Lo siento no tengo definido “falsarla” pero asumo como evidenciar un fallo <<Asumido>>

“Siguiendo a Popper, hasta que no la pueda falsar la premisa, sigue siendo válida. Por lo cual en tanto y en cuanto funcione no la debería abandonar. El camino contrario es el del crítico, pues siempre resta una prueba mas para estar seguro, para estar seguro de que nunca la podrá validar en un 100 %” [Ibíd.]

Efectivamente esto es así y para mi criterio personal descansa necesariamente en la ingeniería inversa del modelo, es decir desarmarlo nuevamente.

“Si se producen discrepancias, sucede lo que comente en mi email anterior.
  1. Se aplicó en forma correcta el método (check list)
  2. Los instrumentos funcionaron correctamente o eran defectuosos (retroalimentación)
  3. No se produjo ningún error humano. (variable de mayor riesgo)
  4. Dadas las mismas condiciones se producen los mismos resultados (discrepancias) (Bitácora de trabajo)” [Ibíd.]
“Entonces el Modelo no es Completo, pues no se condice con la realidad” [Ibíd.]

Efectivamente, DSN_XP considera que el modelo debe estar sujeto a continuo perfeccionamiento, no es estático, debe reflejar al menos ligeras modificaciones, la manifestación de un fallo se expresa por la presencia de ruido en el canal de retroalimentación, el software no es estático es dinámico y mutable maleable.

Un cambio cualitativo se presenta en la idea de “The Matrix” lo cual es posible gracias a la nanotecnología y al conocimiento parcial del manejo del genoma humano. <<Diferido>> <<OffTopic>>

“Aquí debe tener presente el término Completo y no Erróneo” [Ibíd.]

Estoy muy claro de ello :o)

“La Física de Newton no es Errónea, solo es más incompleta que la Física de Einstein, pero dentro del contexto adecuado la física de Newton sigue siendo válida” [Ibíd.]

Esta es la respuesta a un dilema que pretendía abordar como segunda fase al dilema del CVDS, y que consiste en:

¿Un modelo puede entrar en caducidad? <<Diferido>>

Sin embargo debo manifestar nuevamente que esto lo concluí como premisa de mi metodología por la razones explicadas en el párrafo anterior.

“Ahora si tenemos un problema. Algo no encaja en el Modelo con lo cual quedan dos problemas. O cambiamos el Modelo o cambiamos la lógica” [Ibíd.]

<<Sin comentarios>> :o)

“Ninguna de las dos cosas es algo que se pueda resolver en forma rápida, y pueden necesitarse muchos años antes de que a alguien se le ocurra un nuevo modelo o una nueva lógica” [Ibíd.]

<<Experimentación>> :o)

“Por ejemplo y yendo a Sistemas” [Ibíd.]

<Importante> :o)

“ La Programación Procedural nos indica como hacer procedimientos, lo cual en principio parece lo más natural del mundo” [Ibíd.]

No “parece” mi estimado Osvaldo, ¡es! un proceso natural del pensamiento humano, esta es la concepción del software como herramienta, y se conoce bajo mi metodología como la “Perspectiva de los procesos”.

“Entonces poseo un Procedimiento para cocinar un huevo, pero luego si quiero cocinar el huevo de otra forma debo escribir otro procedimiento y luego si en lugar de un huevo quiero cocinar un pollo, necesito otro procedimiento y así sucesivamente” [Ibíd.] <<Top_down>>

Efectivamente lo que has descrito lo conozco como “polimorfismo”

“Podría tener la mala idea de poner a todos los procedimientos juntos en un mismo programa y entonces empezar a modificar todo el conjunto” [Ibíd.]

Esto mi estimado Osvaldo es aplicable a los dos métodos OO y no OO o a cualquiera, ¿es una falla en el diseño? :o)

“Cuando a alguien se le ocurre cambiar el proceso para rostizar al pollo o cuando a alguien se le ocurre agregar la cocción de una torta, y así sucesivamente debiendo 'toquetear' el código anterior para incorporar el nuevo procedimiento” [Ibíd.]

Esto mi estimado Osvaldo me parece muy interesante, por un lado estoy 100% de acuerdo contigo, esto implica necesariamente en considerar a la arquitectura software como una herramienta más en el proceso del diseño del software (ingeniería software).

Por otro lado de ser inmutable esta premisa del modelo centralizado, ¿cómo se explica que justamente el modelo inverso, es decir aceptar que tienes que “toquetear el código fuente” (que debe ser abierto por consecuencia y aplicable a la ingeniería inversa) puede considerar seriamente en rehacer completamente el modelo? <<Open source>>

Y por otro lado, esta es la idea que se quiere conseguir en el diseño de los denominados “Agentes” <<diferido>> o sistemas expertos.

“Pero si cambiamos de enfoque, la cosa cambia” [Ibíd.]

Esto lo conozco como el uso de perspectivas (Arquitectura DSN_XP)

“Consideremos que tenemos un ambiente denominado Cocina en donde existen una cantidad de objetos” [Ibíd.] <<Límite del sistema>>
“Cocina, Batidora, Mezcladora, Refrigerador, etc.” <<Diagramas de clases>>
“Y que definimos las clases y hacemos interacturar los alimentos con los elementos de cocción” <<Perspectiva dinámica: Casos de uso y escenarios, modelo por contrato>>
“Podríamos entonces generar métodos específicos e individuales para diversas comidas” <<Diferido: Top_down>>
“De la misma forma en que un Cocinero adapta su experiencia cuando debe cambiar de Cocina o de Receta” (base de conocimientos) <<Necesidad de una arquitectura interna más robusta y sujeta al cambio>>
“Pero en nuestro ambiente no existía ni Freezer, ni Horno a Microndas, estas son nuevas Clases que se han incorporado a nuestro ambiente” <<nótese que se referencia a la influencia del hardware y a un cambio en el entorno>>
¿Cambia esto en algo a nuestros procedimientos?

Efectivamente que sí; se reconoce que la “Visión de los procesos” es más inestable que la de los datos. :o)

Los procesos del negocio tienden a cambiar. <<Factor de riesgo>>

“¿Podrá haber ahora nuevos `procedimientos' (métodos) para las viejas recetas?” [Ibíd.]

Efectivamente que sí ¿no entiendo la pregunta? A menos que se trate de indicar que no es posible modificar la estructura interna de los datos con la presencia de nuevos atributos, lo cual puede permitirse con un nuevo tratamiento a la vista de los datos según la arquitectura ANSI-SPARC :o) o a la capa del manejo de los datos.

Entonces la pregunta es ¿Es correcto utilizar la visión de los datos para el diseño del software?

“¿Podremos incluir nuevas recetas?” [Ibíd.]

Nuevamente me he perdido, me parece que evidentemente que sí, si el enfoque de tu pregunta va por el lado nuevamente de los datos, la respuesta es que efectivamente es muy crítico depender en el diseño de la representación de la estructura física de los datos (problema Y2K) lo cual pone en evidencia al uso del diagrama Entidad/Relación y sus derivados como UML. :o) <<¿Modelo incompleto?, ¿falla en el diseño? => ¿metodología errónea?>>

(Message over 64 KB, truncated)

domingo, 2 de julio de 2017

DSN_XP y el ENEAGRAMA

DSN_XP.FRAMEWORK.1.0