Repú blica Bolivariana de Venezuela

Ministerio del Poder Popular para la Defensa

Universidad Nacional Experimental Politécnica
De la fuerza Armada Nacional Bolivariana
Carrera: TSU Aná lisis y Diseñ o de Sistemas
Á rea: Aná lisis y Diseñ o de Sistemas II
UNEFA

Fundamentos de los
diseños de
programas

Profesor: Bachiller:

Víctor Velásquez Dairelys Martínez C.I: 28384910

Fundamentos de los diseños de programas

Todo desarrollo, antes o después, se ve sometido a cambios sobre la

funcionalidad inicial o simplemente se requiere funcionalidad nueva.
Estos principios nos proporcionan unas bases para la construcció n de
aplicaciones mucho má s só lidas y robustas. Permiten que los cambios y la
evolució n del software tengan un mínimo impacto en el có digo ya desarrollado
tratando de evitar que lo que funciona deje de funcionar y por ello que el coste
del mantenimiento sea mucho menor.
A continuació n pasamos a ver SOLID que es un acró nimo de 5 principios bá sicos
en el diseñ o y programació n orientada a objetos.

 Single responsibility (Principio de responsabilidad ú nica): Este principio dice

que cada clase tiene que tener una responsabilidad ú nica y concreta, como
dice Rober C. Martín “Una clase debería tener una y só lo una razó n para
cambiar”. Es comú n que cuando empezamos a desarrollar se acabe tomando
decisiones como meter en una clase un método a causa de que esa clase lo
utiliza, el problema llega cuando má s adelante ese método lo necesitamos
usar en otras clases y vemos que pierde coherencia. Supongamos que
tenemos que realizar una aplicació n para registrar las ofertas presentadas y
las ventas cerradas. Se puede crear una clase vendedor con un método
“Generar Oferta” que registrará las ofertas presentadas y otro “Cerrar Venta”
que registrará las ofertas ganadas.

 Open-Close (Principio de abierto-cerrado): Lo que dice este principio es que

no se debe modificar el có digo de una clase o entidad, sino que estas deben de
ser extendidas y para que esto se cumpla, nuestro có digo debe estar bien
diseñ ado. La forma má s comú n para cumplir con este principio es el uso de la
herencia y/o el de las interfaces. Cumplir el principio de responsabilidad
ú nica ayuda a que este otro principio también se cumpla, pero no significa
que cumpliendo uno se cumpla el otro.

 Liskov Substitution (Principio de Sustitució n de Liskov): Este principio recibe

su nombre por su creadora Barbara Liskov. Viene a decir que una clase
derivada de otra debe poder ser sustituida por su clase base y debemos
garantizar que los métodos de la primera no provoquen un mal
funcionamiento de los métodos de la clase base.

 Interface Segregation (Principio de Segregació n de Interfaces): Mejor crear

muchas interfaces que contengan pocos métodos, que crear pocas interfaces
que definan demasiados métodos. El motivo de este principio es que ninguna
clase debe de estar obligada a implementar métodos que no necesita, por ello
es preferible crear varias interfaces que agrupen funcionalidad comú n, a
englobar gran parte de esa funcionalidad en unas pocas interfaces y
 Dependency Inversion (Principio de Inversió n de Dependencia): Este
principio busca que no existan un alto acoplamiento en las aplicaciones, ya
que ello repercute en un difícil mantenimiento. El principio quiere decir que
las clases de alto nivel no tienen que depender de otras de bajo nivel, sino que
ambas dependan de abstracciones, así como que las abstracciones no deben
depender de los detalles, sino al contrario.

1. diseñ os modular

El diseñ o modular es un enfoque donde se subdivide un sistema en partes má s

pequeñ as llamadas mó dulos, que pueden ser creadas independientemente y
luego utilizadas en diferentes sistemas

El software se divide en componentes nombrados y abordados por separado,

llamados frecuentemente mó dulos, que se integran para satisfacer los requisitos
del problema. Es má s fá cil resolver un problema complejo cuando se rompe en
piezas manejables.

Un mó dulo es normalmente un componente de un subsistema que proporciona

uno o má s servicios a otros mó dulos. A su vez éste usa los servicios
proporcionados por otros mó dulos. Los mó dulos se componen normalmente de
varios componentes del sistema má s simples.

Segú n G. Meyers, “la modularidad es el ú nico atributo del software que permite
gestionar un programa intelectualmente”

Un software monolítico (programa grande formado por un ú nico mó dulo) no

puede ser entendido fá cilmente por el lector. Hay dos estrategias principales que
se pueden usar cuando se descompone un subsistema en mó dulos:

 Descomposición orientada a objetos: en la que se descompone un sistema

en un conjunto de objetos que se comunican. Este criterio es el má s usado hoy
día, y consiste en dividir el Problema principal, en mó dulos (Objetos) que
encapsulan juntas la definició n del objeto y todas sus operaciones. Se refiere a
pequeñ os mó dulos que van a realizar una tarea independiente y específica,
encaminada a la resolució n del problema principal pero sin depender de otro
modulo; debido a esto es muy fá cil modificar los mó dulos sin afectar otros.

 Descomposición orientada a flujos de funciones: en la que se descompone

un sistema en mó dulos funcionales que aceptan datos y los transforman en
datos de salida. Este criterio es el menos usado hoy en día y se refiere a
dividir el programa principal en subprogramas que agrupan funciones
similares, es decir cada uno de estos Mó dulos está n relacionados entre sí, por
tanto estos mó dulos no son independientes, debido a esto resulta muy difícil
 modificarlos ya que el modificar alguno de los mó dulos, implica modificar
todos los demá s Mó dulos.

Al aplicar la programació n modular, un problema complejo debe ser dividido en

varios subproblemas má s simples, y estos a su vez en otros subproblemas má s
simples aú n. Esto debe hacerse hasta obtener subproblemas lo suficientemente
simples como para poder ser resueltos fá cilmente con algú n lenguaje de
programació n. Esta técnica se llama refinamiento sucesivo, divide y vencerá s o
aná lisis descendente (Top-Down).

Un 'mó dulo' es cada una de las partes de un programa que resuelve uno de los
subproblemas en que se divide el problema complejo original. Cada uno de estos
mó dulos tiene una tarea bien definida y algunos necesitan de otros para poder
operar. En caso de que un mó dulo necesite de otro, puede comunicarse con este
mediante una interfaz de comunicació n que también debe estar bien definida.

Si bien un mó dulo puede entenderse como una parte de un programa en

cualquiera de sus formas y variados contextos, en la prá ctica se los suele tomar
como sinó nimos de procedimientos y funciones. Pero no necesaria ni
estrictamente un mó dulo es una funció n o un procedimiento, ya que el mismo
puede contener muchos de ellos. No debe confundirse el término "mó dulo" (en el
sentido de programació n modular) con términos como "funció n" o
"procedimiento", propios del lenguaje que lo soporte.

2. descomposición modular:

La descomposició n modular es un método de diseñ o proporciona un mecanismo

sistemá tico para descomponer el problema en subproblemas, reducirá la
complejidad de todo el problema consiguiendo de esta manera una solució n
modular efectiva.

Consiste en descomponer el problema a resolver en mó dulos o tareas má s

simples. Cada tarea representa una actividad completa y se codifica de manera
independiente. Facilita el diseñ o descendente del problema, centrá ndonos cada
vez en la resolució n de subproblemas de magnitud inferior.

A la resolució n de cada uno de estos subproblemas de complejidad inferior se

denomina refinamiento por pasos. Los mó dulos pueden ser planificados,
codificados, comprobados y depurados independientemente, y a continuació n se
combinan uno a uno con otros mó dulos.
El diseñ o modular propone dividir el sistema en partes diferenciadas y definir
sus interfaces.

 Ventajas

 Claridad
 Reducció n de costos
 Reutilizació n

Se siguen los siguientes pasos para poder realizar la descomposició n modular:

 Identificar los mó dulos

 Describir cada mó dulo
 Describir las relaciones entre mó dulos

Una descomposició n modular debe poseer ciertas cualidades mínimas para que
se pueda considerar suficiente validad.

 Independencia funcional
 Acoplamiento
 Cohesió n
 Comprensibilidad
 Adaptabilidad

 Independiente Funcional: Al final de los documentos ADD y DDD debe

haber una matriz REQUISITOS/COMPONNETES. En principio, cada
funció n será realizada en un mó dulo distinto. Si las funciones son
independientes los mó dulos tendrá n independencia funcional. Cada
mó dulo debe realizar una funció n concreta o un conjunto de funciones
afines. Es recomendable reducir las relaciones entre mó dulos al mínimo.
Para medir la independencia funcional hay dos criterios: acoplamiento y
cohesió n.
 Acoplamiento: el grado de acoplamiento mide la interrelació n entre dos
mó dulos, segú n el tipo de conexió n y la complejidad de la interface:

 Fuerte:

 POR CONTENIDO, cuando desde un mó dulo se pueden cambiar datos

locales de otro
 COMÚN, se emplea una zona comú n de datos a la que tienen acceso varios
mó dulos
 MODERADO
 DE CONTROL, la zona comú n es un dispositivo externo al que está n
ligados los mó dulos, esto implica que un cambio en el formato de datos
afecta a todos estos mó dulos
 POR ETIQUETA, en intercambio de datos se realiza mediante una
referencia a la estructura completa de datos (vector, pila, á rbol, grafo, …)

 Débil:

 DE DATOS, viene dado por los datos que intercambian los mó dulos. Es el
mejor posible
 SIN ACOPLAMIENTO DIRECTO, es el acoplamiento que no existe

 Cohesión: Es necesario lograr que el contenido de cada mó dulo tenga la

má xima coherencia. Para que el nº de mó dulos no sea demasiado elevado
y complique el diseñ o se tratan de agrupar elementos afines y
relacionados en un mismo mó dulo.

 Alta:

 COHESIÓN ABSTRACCIONAL, se logra cuando se diseñ a el mó dulo como

tipo abstracto de datos o como una clase de objetos
 COHESIÓN FUNCIONAL, el mó dulo realiza una funció n concreta y
específica

 Media:

 COHESIÓN SECUENCIAL, los elementos del mó dulo trabajan de forma

secuencial
 COHESIÓN DE COMUNICACIÓN, elementos que operan con le mismo
conjunto de datos de entrada o de salida
 COHESIÓN TEMPORAL, se agrupan elementos que se ejecutan en el
mismo momento. Ej. Arrancar o parar dispositivos
  Baja:

 COHESIÓN LÓGICA, se agrupan elementos que realizan funciones

similares. Ejs.: mó dulos de E/S o de tratamiento de errores
 COHESIÓN COINCIDENTAL, es la peor y se produce cuando los elementos
de un mó dulo no guardan relació n alguna

La descripció n del comportamiento de un mó dulo permite establecer el grado de

cohesió n:

 Si es una frase compuesta y contiene má s de un verbo la cohesió n será MEDIA

 Si contiene expresiones secuenciales (primero, entonces, cuando…), será
temporal o secuencial
 Si la descripció n no se refiere a algo específico (Ej. Todos los errores),
cohesió n ló gica
 Si aparece “inicializar”, “preparar”, “configurar”, probablemente sea temporal.

 Comprensibilidad: Para facilitar los cambios, el mantenimiento y la

reutilizació n de mó dulos es necesario que cada uno sea comprensible de
forma aislada. Para ello es bueno que posea independencia funcional, pero
ademá s es deseable:

 IDENTIFICACIÓN, el nombre debe ser adecuado y descriptivo

 DOCUMENTACIÓN, debe aclarar todos los detalles de diseñ o e
implementació n que no queden de manifiesto en el propio có digo
 SIMPLICIDAD, las soluciones sencillas son siempre las mejores

 Adaptabilidad: La adaptació n de un sistema resulta má s difícil cuando no

hay independencia funcional, es decir, con alto acoplamiento y baja cohesió n,
y cuando el diseñ o es poco comprensible. Otros factores para facilitar la
adaptabilidad:

 PREVISIÓN, es necesario prever que aspectos del sistema pueden ser

susceptibles de cambios en el futuro, y poner estos elementos en mó dulos
independientes, de manera que su modificació n afecte al menor nú mero de
mó dulos posible
 ACCESIBILIDAD, debe resultar sencillo el acceso a los documentos de
especificació n, diseñ o, e implementació n para obtener un conocimiento
suficiente del sistema antes de proceder a su adaptació n
 CONSISTENCIA, después de cualquier adaptació n se debe mantener la
consistencia del sistema, incluidos los documentos afectados
3. diseño asistido por herramientas CASE

Se puede definir a las Herramientas CASE como un conjunto de programas y

ayudas que dan asistencia a los analistas, ingenieros de software y
desarrolladores, durante todos los pasos del Ciclo de Vida de desarrollo de un
Software. En otras palabras

Las Herramientas CASE son un conjunto de métodos, utilidades y técnicas que

facilitan la automatizació n del ciclo de vida del desarrollo de sistemas de
informació n, completamente o en alguna de sus fases.

La sigla genérica para una serie de programas y una filosofía de desarrollo de

software que ayuda a automatizar el ciclo de vida de desarrollo de los sistemas.

Una innovació n en la organizació n, un concepto avanzado en la evolució n de

tecnología con un potencial efecto profundo en la organizació n. Se puede ver al
CASE como la unió n de las herramientas automá ticas de software y las
metodologías de desarrollo de software formales.

o El empleo de herramientas CASE permiten integrar el proceso de ciclo

de vida:

 Aná lisis de datos y procesos integrados mediante un repositorio.

 Generació n de interfaces entre el aná lisis y el diseñ o.

 Generació n del có digo a partir del diseñ o.

 Control de mantenimiento.
 Tipos de Herramientas CASE

No existe una ú nica clasificació n de herramientas CASE, es difícil incluirlas en

una clase determinada. Podrían clasificarse atendiendo a:

 Las plataformas que soportan.

 Las fases del ciclo de vida del desarrollo de sistemas que abarca.

 La arquitectura de las aplicaciones que produce.

 Su funcionalidad.

Las herramientas CASE, en funció n de las fases del ciclo de vida abarcadas, se
pueden agrupar de la forma siguiente:

 Herramientas integradas, I-CASE (Integrated CASE, CASE integrado):

abarcan todas las fases del ciclo de vida del desarrollo de sistemas. Son
llamadas también CASE workbench. Las herramientas I-CASE se basan en una
metodología. Tienen un repositorio y aportan técnicas estructuradas para
todas las fases del ciclo de vida. Estas son las características que les confieren
su mayor ventaja: una mejora de la calidad de los desarrollos. Sin embargo,
no todas ellas son modernas en el sentido de aprovechar la potencia de las
estaciones de trabajo o la utilizació n de lenguajes de alto nivel o técnicas de
prototipo.

 Herramientas de alto nivel, U-CASE (Upper CASE - CASE superior) o front-

end, orientadas a la automatizació n y soporte de las actividades desarrolladas
durante las primeras fases del desarrollo: aná lisis y diseñ o. Una estrategia
posible es utilizar una U-CASE para aná lisis y diseñ o, combinada con otras
herramientas má s modernas para las fases de construcció n y pruebas. En este
caso, habría que vigilar cuidadosamente la integració n entre las distintas
herramientas.

 Herramientas de bajo nivel, L-CASE (Lower CASE - CASE inferior) o back-

end, dirigidas a las ú ltimas fases del desarrollo: construcció n e implantació n.

Juegos de herramientas o toolkits, son el tipo má s simple de herramientas CASE.

Automatizan una fase dentro del ciclo de vida. Dentro de este grupo se
encontrarían las herramientas de reingeniería, orientadas a la fase de
mantenimiento.

Otra posible clasificació n, utilizando la funcionalidad como criterio principal, es

la siguiente:
 Herramientas de gestió n de proyectos

 Herramientas de gestió n y configuració n de software (SCM)

 Herramientas de calidad y seguridad de software

 Herramientas de aná lisis y diseñ o

 Herramientas de desarrollo de interfaz de usuarios

 Herramientas para la Ingeniería de Software Orientada a Objetos

 Herramientas de integració n y prueba

 Herramientas de métodos formales

 Herramientas Cliente/Servidor

 Herramientas de Ingeniería WEB

 Herramientas de Reingeniería

 Beneficios de las Herramientas CASE

Entre los beneficios má s significativos de las herramientas CASE se enumeran los

siguientes:

 Facilidad para la revisión de aplicaciones

La experiencia muestra que una vez que las aplicaciones se implementan, se

emplean por mucho tiempo. Las herramientas CASE proporcionan un beneficio
substancial para las organizaciones al facilitar la revisió n de las aplicaciones.
Contar con un depó sito central agiliza el proceso de revisió n ya que éste
proporciona bases para las definiciones y está ndares para los datos. Las
capacidades de generació n interna, si se encuentran presentes, contribuyen a
modificar el sistema por medio de las especificaciones má s que por los ajustes al
có digo fuente.

 Soporte para el desarrollo de prototipos de sistemas

En general, el desarrollo de prototipos de aplicaciones toma varias formas. En

ocasiones se desarrollan diseñ os para pantallas y reportes con la finalidad de
mostrar la organizació n y composició n de los datos, encabezados y mensajes. Los
ajustes necesarios al diseñ o se hacen con rapidez para alterar la presentació n y
las características de la interface. Sin embargo, no se prepara el có digo fuente, de
naturaleza orientada hacia procedimientos, como una parte del prototipo.

Como disyuntiva, el desarrollo de prototipos puede producir un sistema que

funcione. Las características de entrada y salida son desarrolladas junto con el
có digo orientado hacia los procedimientos y archivos de datos.

 Generación de código

La ventaja má s visible de esta característica es la disminució n del tiempo

necesario para preparar un programa. Sin embargo, la generació n del có digo
también asegura una estructura está ndar y consistente para el programa (lo que
tiene gran influencia en el mantenimiento) y disminuye la ocurrencia de varios
tipos de errores, mejorando de esta manera la calidad. Las características de la
generació n del có digo permiten volver a utilizar el software y las estructuras
está ndares para generar dicho có digo, así como el cambio de una especificació n
modular, lo que significa volver a generar el có digo y los enlaces con otros
mó dulos.

 Mejora en la habilidad para satisfacer los requerimientos del usuario

Es bien conocida la importancia de satisfacer los requerimientos del usuario, ya

que esto guarda relació n con el éxito del sistema. De manera similar, tener los
requerimientos correctos mejora la calidad de las prá cticas de desarrollo. Las
herramientas CASE disminuyen el tiempo de desarrollo, una característica que es
importante para los usuarios. Las herramientas afectan la naturaleza y cantidad
de interacció n entre los encargados del desarrollo y el usuario. Las descripciones
grá ficas y los diagramas, así como los prototipos de reportes y la composició n de
las pantallas, contribuyen a un intercambio de ideas má s efectivo.

 Soporte interactivo para el proceso de desarrollo

La experiencia ha demostrado que el desarrollo de sistemas es un proceso

interactivo. Las herramientas CASE soportan pasos interactivos al eliminar el
tedio manual de dibujar diagramas, elaborar catá logos y clasificar. Como
resultado de esto, se anticipa que los analistas repasará n y revisará n los detalles
del sistema con mayor frecuencia y en forma má s consistente.

4. generadores automaticos de codigos

En un primer momento, los generadores de có digo nacen como una manera de

agilizar el desarrollo, por ejemplo si siempre partimos de un caso en el que
usamos 5 librerías y nuestro diseñ o es de cierta manera, para nosotros sería muy
ú til, poder disponer de esa plantilla ya creada y luego completar el contenido.
Este proceso es muy importante si queremos diseñ ar un prototipo rá pido, de lo
que va a ser nuestro servicio y con el cual le podemos enseñ ar a un posible
cliente, inversor o al propio equipo, có mo será lo que queremos montar.

Ese tipo de sistemas hasta hace poco los teníamos disponibles y nos añ adían
muchas facilidades, pero actualmente y utilizando una expresió n muy típica de
informá tica, hemos intentado “rizar el rizo” para conseguir que no sea una mera
plantilla lo que vamos a utilizar, sino que nos pueda generar una versió n sencilla,
pero completa o casi completa de todo el sistema.

 Tipos de generadores de codigo

Dentro de los generadores de có digo, podemos distinguir dos tipos principales:

 Generadores interactivos: este tipo de generadores son muy comunes

actualmente y permiten, que con un simple sistema de arrastrar y configurar
un par de pará metros del elemento, poder generar todo el có digo necesario
para implementar esa funcionalidad. Un ejemplo de ello es el App Studio, el
generador de Aplicaciones para Windows Phone que Microsoft pone a
disposició n de cualquier persona.

 Generadores usando un lenguaje de modelado: este tipo de generadores

son menos comunes pero son los má s “potentes”, ya que usando una
descripció n del modelo que queremos crear en un lenguaje de modelado
como UML, son capaces de crear un porcentaje bastante amplio del có digo.
Un ejemplo de esto es Visual Paradigm, y una de sus ventajas es que permite
generar có digo en diversos lenguajes como C++, Java y PHP.

 Ventajas del uso de generadores de código.

Entre las ventajas que tienen, podemos destacar:

 El có digo se genera de una manera transparente al usuario, así que se puede

obtener un programa en C# sin saber ese lenguaje.
 Agiliza mucho el desarrollo de pequeñ os prototipos para hacer las
demostraciones.
 Los generadores interactivos suelen poseer como característica, que unos
usuarios sin saber programar en ningú n lenguaje, pueda crear un programa
má s o menos complejo.

 Inconvenientes de los generadores de codigo.

La parte negativa de esas herramientas que hoy comentamos es principalmente:

 La calidad del có digo, llegados a este punto muchos programadores
avanzados pueden cuestionar, có mo de bueno es el có digo que generan estas
herramientas. Desde Somos Binarios afirmamos que un programador
avanzado y entendido en ese lenguaje, va a poder hacer có digo mucho mejor
optimizado del que genera la má quina, porque puede adaptar mucho mejor el
proyecto al lenguaje, mientras que el generador está pensado para que funcione en
muchos proyectos muy distintos. Pero también es verdad, que un generador de
có digo respecto a un usuario de nivel medio-bajo, posiblemente puede generar
mejor có digo o por lo menos cometiendo un nú mero sensiblemente inferior de
errores.

 Los generadores basados en lenguajes formales como UML, necesitan conocer UML y
esto no es una cosa que se aprenda en un par de semanas, sino que necesita un duro
y continuo trabajo para poder dominarlo. Así que algunos casos, puede ser má s
rentable aprender la nueva tecnología que aprender UML.