Está en la página 1de 4

Principios del Diseo de Software

El diseo de la arquitectura de software es una fase muy importante en el ciclo de vida del software. Es absolutamente necesario desempear sta tarea con demasiada cautela, ya que un error en sta fase del desarrollo puede lastrar todo un proyecto y llevarlo a caer en una espiral de constantes cambios. Existen algunas reglas las que podramos considerar a la hora de disear la arquitectura del sistema. Reusabilidad Cada fragmento de software debe ser lo ms reutilizable posible (a menos que sea aplicativo), y reutilizar otros componentes lo mayor posible. Extensibilidad - Cada fragmento de software deber ser lo ms extensible posible, es decir, tener todos los lugares posibles para aadir ms funcionalidad. Funcionalidad Cada fragmento de software debe hacer la vida mas fcil al usuario, la regla 8020 debe encajar aqui (por lo menos un 80 % del tiempo). Orden Cada pieza de software debe estar organizada para encontrar fcilmente cada fragmento de cdigo, y estructurado de forma fcil para poder aadir un nuevo fragmento. Trazabilidad Cada fragmento de software deber registrar sus acciones en detalle, preferentemente en diferentes niveles de detalles. Utilizar libreras de logging facilitarn tu trabajo. Seguridad Cada pieza de software no debe revelar sus debilidades de seguridad, eso permitira que se abusara maliciosamente del sistema, como inyeccin de cdigo, modificacin de privilegios no autorizados, denegacin de servicios del sistema, etc. Portabilidad Cada fragmento de software debe ser lo ms portable posible. No necesariamente entre diferentes sistemas operativos, pero generalmente entre diferentes ordenadores. La noinstalacin (despliegue xcopy) es bienvenida en la portabilidad. Reusabilidad Cuando desarrollas software, el factor de reusabilidad es crucial, especialmente cuanto tienes plazos que cumplir. Divide tu cdigo en varias libreras bien definidas, que te permita utilizar en otros proyectos, por lo general te costar menos en conceptos de tiempos, esfuerzo y dinero cuando varios proyectos estn involucrados. Si solamente tienes un proyecto, an as deberas reutilizar. Deberas separar cdigo reutilizable en una librera lo que te permitir simplificar an ms el cdigo a mantener. Cuando no Reutilizar

Un caso donde no es bienvenida la reutilizacin es en un proceso muy especfico. Otro caso donde no se recomienda reutilizar, es la falta de entendimiento para encontrar el la forma correcta de construir cdigo reutilizable. Por lo general, el cdigo en cuestin se escribi slo una o dos veces. Te lo explicar: escribes un fragmento de software que hace una determinada tarea, y crees que esta tarea podra repetirse en el futuro, lo exportas a una biblioteca. Entonces, despus de un tiempo, deseas volver a utilizarlo, en otro lugar, pero ya ves que no es lo suficiente extensible, lo suficientemente porttil, no responde a sus requisitos de funcionalidad, etc. Todava tienes que escribir tu propio cdigo. O tienes que fijar la biblioteca para adaptarse a los dos proyectos, y luego ir y arreglar el viejo proyecto que ya lo utiliza. La fijacin de la biblioteca en este momento sera difcil, ya que las necesidades del nuevo proyecto no se tuvieron en cuenta en el diseo original. Cuando un proyecto de tercera que lo necesita, esto podra repetirse de nuevo. Por lo general, una buena idea esperar hasta que haya requisitos de al menos tres proyectos diferentes antes dedecidirse a hacer una pieza de cdigo de una biblioteca reutilizable. Extensibilidad. La extensibilidad te permite aadir nuevas funcionalidades en el futuro. Existen muchos tipos de extensibilidad, tanto internas como externas. Extensibilidades externas son las ms importantes. El desarrollador de software reutilizable deber tener en cuenta la necesidad de otro desarrollador para aadir funcionalidad o hacer las cosas un poco diferentes de su propio punto de vista. Por ejemplo, supongamos que tienes una clase que contiene un control de usuario, y ese control de usuario es visible para el usuario final. Puedes agrupar por completo, solamente la funcionalidad que consideres til. Pero en algunos casos un desarrollador puede querer ajustar este determinado control, y puede ser que no le han dado la opcin de hacer su pequea modificacin. Mejores Prcticas de Extensibilidad. Una regla de oro de extensibilidad sera exponer la funcionalidad de siempre a travs de interfaces, y si desea que el usuario sea capaz de llevarlas a la introduccin de los objetos creados a tu librera, utilice el patrn de fbrica, y permitir al usuario el registro de sus propios tipos. Esto le permite reemplazar el cdigo detrs de la interfaz como todo lo que quieras sin que el usuario tiene que desconfiar de l, y tambin permite al usuario introducir sus propios tipos.

Por lo general, prefieren introducir interfaces en lugar de las clases base. Si el usuario necesita integrar en su proyecto en curso un cdigo, una clase de base puede que le impida hacer lo que necesite, puede ser que quiera agregar funcionalidad a una clase actual que ya tiene, que hereda de otra clase base. Con interfaces, esto siempre es posible. Si tienes un mtodo que devuelve un resultado, prefieres crear una clase que de resultado especializado y llenarla con los datos pertinentes. Si deseas aadir datos en el futuro, esto sera tan fcil como agregar campos a la clase ya existente. Crea un mtodo con un parmetro extensible (Array de String) de entrada aunque se encuentre vaco, probablemente se utilice en un futuro. Funcionalidad. Cuando desarrollas software, asegrate que cada parte del software hace lo que se necesita que haga, y no lo que no se necesita que haga. Parece obvio, pero no lo es. Cuando piensas donde situar cada mtodo del software que implementa algunas de las funcionalidades requeridas, intenta agrupar los mtodos que se encuentren relacionados en funcionalidad. Intenta evitar funcionalidades duplicadas, simplemente por pequeas diferencias. Si tienes que hacerlo, hazlo de la forma ms inteligente, reduciendo la duplicidad de cdigo a lo mnimo necesario. Utiliza clases de soporte, o mtodos de soporte lo ms que puedas, y hazlos estticos, as reducirs el costo y optimizars los recursos del sistema. La funcionalidad expuesta, deber encajar con las necesidades del usuario. El cdigo reutilizable, no debe cubrir el 100% de los casos. Al menos el 10% de los casos son tan extraos, que nunca habrs pensado en ellos. Realiza una bsqueda exhaustiva y encuentra el 80% de los casos que son relevantes para ti. No mires lo que no se encuentre relacionado con el negocio. Esos casos hacen las cosas de una manera diferente, y tienen un mbito diferente. Mira implcitamente en tu negocio. Incluso en tu negocio, hay mucha informacin al respecto y debers encontrarla. Si no la encuentras, simplemente significa que quizs esa funcionalidad no necesites hacerla reutilizable. Simplemente hazla de forma aplicativa. No utilices tecnologa intrusiva en tu cdigo, si lo haces, documenta porque lo haz hecho. Orden y Estructura. Cuando desarrollas la estructura de tu proyecto, hazla significativamente separada por la logica, no en terminos fsicos. Piense en alguien que no conoce el proyecto y necesita un fichero determinado, si no puede encontrarlo es que la estructura no sigue una lgica determinada.

De la misma manera se pueden utilizar directivas de regin. Si veo miles y miles de mtodos pblicos, como podr encontrar lo que necesito realmente. Sera ptimo separar las funcionalidades por regin, considrese por el tipo de interaccin con el usuario, diseo de lgica, construccin e inicializacin. Trazabilidad. El software debe registrar las acciones y los errores, estos registros sern luego utilizados para analizar el uso de la aplicacin tanto para evaluar el performance, los errores, los comportamientos inesperados, etc. Utiliza un mtodo comn para registrar todas las partes de la aplicacin. Un mtodo altamente configurable y extensible en lo posible, porque en el caso inesperado de que una tercera persona desee extender sta funcionalidad, deber poder hacerlo. Seguridad. La seguridad es una cuestin muy importante en las aplicaciones, especialmente cuando el software es expuesto a una larga lista de usuarios, y realmente no puedes saber a ciencia cierta quien desea hacer dao a tu empresa o a tus clientes. Cuando creas consultas de base de datos, asegrate de limpiar las consultas para prevenir inyecciones SQL, stas pueden hacerte perder muchsima informacin. Cuando tienes parmetros de entrada de cualquier tipo, asegrate de que tienes suficiente espacio para almacenarlo, limitar lo que debes limitar y evita la inyeccin de cdigo. Portabilidad. Un software portable es mucho mejor que un software que necesitas instalar. Copiar ficheros a un lugar es mucho ms fcil que seguir un procedimiento de instalacin.

También podría gustarte