Colabora
 

Programación Orientada a Objetos

Complejidad

 

Fecha: 06/Jun/2007 (22 Mayo 2007)
Autor: Cristhian Jaret Velasquez Miranda - Cristiancjv@hotmail.com

 


Introducción

Hola Guille soy de Honduras y tantas veces he tomado informacion de tu pagina que decidi colaborar un poco. Es sobre "Metodologia para aplicaciones Orientadas a Objetos independientemente del lenguaje. ya que es algo importante para las personas que recien iniciamos en este amplio mundo de la programacion orientada a objetos ya que se toman diferentes metodologias y como dice cada quien tiene su forma de hacerlo pero cada una de ellas se rige por ciertas reglas y son una de las cuales tomare en cuenta creo que enviare mas dependiendo del tiempo.

Desde el principio de la historia el ser humano ha basado su aprendizaje en mecanismos exitosos para repetir procesos y posteriormente afinarlos hasta obtener mejoras al proceso. A este tipo de aprendizaje basado en aciertos y errores lo denominamos experiencia, la cual puede ser adquirida en forma personal u obtenida con ayuda de la experiencia de otros, y en la medida que la experiencia trasciende se convierte en conocimiento, a tal grado que esta sea la forma principal de educación en las escuelas, la cual toma conocimientos de la experiencia profesional de profesores y escritos para transmitirla a los alumnos.

 

Contenido

Naturaleza

El software modela segmentos del mundo real para tratar de replicar su funcionamiento en sistemas discretos, por ende cualquier modelo mantiene una complejidad al tratar de imitar la realidad con herramientas electrónicas. La naturaleza del software desprende su complejidad en cuatro elementos: complejidad del dominio del problema, la dificultad del manejo de procesos de desarrollo, la posible flexibilidad del software y los problemas de representación del funcionamiento en sistemas discretos.

 

Complejidad del dominio del problema: El requerimiento de software para satisfacer un problema particular requiere del conocimiento y experiencia del dominio del negocio, en donde aún así las personas con estas características pocas veces dominan la totalidad del problema. Por eso el desarrollador debe de escuchar y cuestionar para lograr obtener la experiencia del usuario referente al dominio del problema en unos cuantos meses, semanas o días. Se incrementa la complejidad si el problema a resolver mantiene muchas condicionantes para tomar decisiones. Adicionalmente es necesario luchar contra elementos no funcionales como reutilización de código, esquemas de seguridad, performance, costo, interactividad y limitaciones físicas de hardware y software.

 

Dificultad del manejo de procesos de desarrollo: Es común la evolución del software, en donde muchas veces es necesario reescribir código, por eso es casi indispensable construir pequeños bloques de código para su reutilización y limitación de responsabilidades, pero generalmente en un desarrollo participa un conjunto de programadores los cuales después de escribir su código deben hacerlo interactuar con otros códigos, durante esta integración es donde saltan las deficiencias de las etapas de análisis, diseño y desarrollo, sin tomar en cuenta siquiera la complejidad de coordinar en tiempos y objetivos los equipos de trabajo, los cuales generalmente tienen poco trabajo conjunto y/o problemas derivados de la distancia causantes de poca interacción y comunicación.

 

Posible flexibilidad a través del software: Durante la solución a un problema particular se debe de pensar en aspectos capaces de ofrecer solución a la evolución de las necesidades sin requerir afectar código o al menos tratar de impactarlo en menor medida con unidades de funcionamiento específico. Todo esto obliga a conocer y apostar a la flexibilidad de un sistema para funcionar en un futuro, claro que a mayor flexibilidad el nivel de complejidad se incrementa exponencialmente.

 

Problemas de representación del funcionamiento en sistemas discretos: Dentro de aplicaciones grandes existen miles de variables, así como también más de un hilo de control. La colección de estas variables, sus valores actuales, su dirección en memoria, constituyen el presente estado de una aplicación. Al ejecutar nuestro software en sistemas digitales nosotros tenemos estados discretos, así se conforman un número finito de estados. Si diseñamos un sistema con separación de tareas, el funcionamiento de una parte del sistema deberá repercutir en menor grado para el funcionamiento de otra, pero aún así pueden existir errores de transición entre estados, lo cual nunca ocurriría en sistemas continuos. Otro factor importante de complejidad es la descripción de un funcionamiento a través de instrucciones lógicas y matemáticas tratando de representar segmentos del mundo real.

 

Orientación a objetos

Sistemas continuos. Otro factor importante de complejidad es la descripción de un funcionamiento a través de instrucciones lógicas y matemáticas tratando de representar segmentos del mundo real.

Atributos

Existen al menos cinco atributos comunes a los sistemas discretos:
1. La complejidad habitualmente se muestra de forma jerárquica, es decir, un sistema complejo se compone de
subsistemas relacionados, existiendo dentro de un subsistema más subsistemas y así sucesivamente, hasta llegar
al nivel más bajo de componentes elementales menos complejos.
2. La decisión de elementabilidad de un componente es arbitraria, por depender del observador del sistema.
3. Las relaciones dentro de un componente son más fuertes que las relaciones entre componentes.
4. Los sistemas jerárquicos se componen normalmente de pocos tipos de subsistemas simples debido a la
semejanza de patrones entre los subsistemas compuestos.
5. Un sistema complejo necesita envolver a sistemas simples. Solución a la complejidad.

 

La solución a la complejidad del software puede resolverse a través de ciertas reglas previstas para abatir la complejidad a través de diferentes ángulos. Dentro de las reglas para solucionar la complejidad de un problema con orientación a objetos tenemos la regla de descomposición, regla de abstracción y regla de jerarquía (clasificación).

 

Reglas de descomposición

Un argumento muy fuerte para solucionar problemas es dividir para vencer. Segmentando un problema en subproblemas más simples cada subproblema puede ser atacado sin lidiar contra la totalidad. Existen diferentes formas de descomponer un problema: descomposición algorítmica (estructurada) y descomposición orientada a objetos. La descomposición algorítmica se ocupa en el diseño estructurado conocida como Top-Down, en donde cada módulo en el sistema es desglosado en un conjunto de módulos más pequeños en coordinación para dar una solución conjunta, y así sucesivamente se hace por cada módulo de nivel inferior obtenido, así hasta llevar cada módulo a un proceso simple de programación.
La descomposición orientada a objetos divide el problema utilizando abstracciones con responsabilidades obtenidas del dominio del problema. El resultado de la abstracción son objetos capaces de brindar coordinadamente una solución al problema. Mientras la descomposición algorítmica identifica secuencia de procesos, la descomposición orientada a objetos identifica objetos cooperantes.

 

Regla de abstracción

La dificultad de dominar un objeto en su totalidad nos guía a obtener una idea generalizada del objeto, evitando distraer la atención en detalles no esenciales (solución a sus compromisos), para concentrarnos en los detalles más importantes (sus relaciones). La incapacidad humana de dominar la totalidad de un objeto, escoge ignorar los detalles no esenciales del objeto, para crear una idea globalizada del objeto.

Regla de jerarquía

Las jerarquías permiten entender en forma más sencilla al mundo real, existiendo dos jerarquías básicas: la estructura de objetos y la de clases. La estructura de objetos muestra la colaboración de diversos objetos en un patrón de interacción con formato de una totalidad / parte, llamado mecanismo. La estructura de clases muestra la estructura común en base a alguna característica con un funcionamiento sin un propósito causal en un sistema.

Importancia del diseño

El propósito de un diseño es ofrecer una solución a la estructura del problema, conocida como arquitectura.
El diseño es la invención a la solución a un problema, satisfaciendo los requerimientos antes de su implementación.
Un buen diseño debe de cumplir con:
• Satisfacer funcionalmente la especificación del problema.
• Satisfacer las restricciones de diseño, tiempo, costo y herramientas disponibles para la construcción.
En la ingeniería de software se cubren diferentes métodos de diseño, identificados por un lenguaje de comunicación,
denominado notación, un proceso científico y herramientas para respetar la secuencia del proceso a través de su
notación, conocido como CASE.

 

Nota: Espero que les sea de utilidad ya que a mi me ha servido de mucho para entender mejor el concepto de Programación Orientada a Objetos. Si les gusto este articulo se que el otro les gustará más es el "Modelo de Objetos" con temas a tratar como (AOO) Analisis Orientado a Objetos,(DOO)Diseño Orientado a Objetos y la famosa (POO)Programacion Orientada a Objetos claro siempre y cuando Dios y el Guille me lo permitan y me despido con un saludo a toda la comunidad de programadores.




Ir al índice principal de el Guille