UNIDAD ZACATENCO

INGENIERIA EN COMUNICACIONES Y ELECTRONICA

INGENIERÍA DEL SOFTWARE

PROFESOR:

MANCILLA LEÓN ARMANDO

ALUMNO:

FLORES GARCIA ELIAS

PRACTICA:

Ingeniería del diseño

INGENIERÍA DEL DISEÑO

Es el arte de aplicar los conocimientos científicos en la ordenación de los elementos básicos,

tangibles e intangibles, de un objeto o estructura con el fin de aumentar su belleza o utilidad

El término diseño admite varias significados. Así, el “diseño” puede ser una actividad, la
“actividad de diseñar”, puede ser un producto, el “resultado de la actividad de diseñar”, o puede
ser un calificativo, y en este sentido es muy común referirse a algo como “de diseño”, cuando
aporta una geometría, una forma o unas cualidades diferenciadoras que implican un aire de
calidad y distinción.

El término “diseño” viene de “diseñar”, que a su vez tiene su origen en el latín, designare, que en
origen significa en trazar (un surco en la tierra) y también dibujar, marcar o designar. De hecho,
la primera acepción del término diseño, en español, es “traza o delineación de una figura o un
edificio”.

Pero el término admite también un significado amplio: “ordenación de los elementos básicos,
tangibles e intangibles, de un objeto o estructura con el fin de aumentar su belleza o utilidad”.

Se debe notar que, de acuerdo con esta significación, el diseño aborda los “elementos básicos”,
esto es, los más relevantes o fundamentales. La ordenación de los detalles correspondería a una
parte del “diseño”, que sería el “diseño detallado”. También se debe apuntar que el diseño no
conlleva necesariamente unas tareas de “cálculo” o de “dimensionamiento preciso”, tareas que sí
formarían parte de un diseño detallado o de las propias de una ingeniería.

Por otro lado, el término “ingeniería”, del latín ingenium, se define como: “el arte de aplicar los
conocimientos científicos a la invención, utilización o perfeccionamiento de la técnica en todas
sus determinaciones”.

La ingeniería del diseño abarca un conjunto de principios, conceptos y prácticas que conducen al
desarrollo de un sistema o producto de alta calidad. Los principios del diseño establecen una
filosofía primordial que guían al diseñador en el trabajo que desempeña. Es necesario
comprender los conceptos del diseño antes de que se aplique las mecánicas de la práctica del
diseño, y la práctica del diseño mismo conduce a la creación de varias representaciones del
software, el cual sirve como guía para la actividad de construcción que sigue.

La ingeniería del diseño no es una frase común dentro del contexto de la ingeniería del software.
Sin embargo debería serlo. El diseño es una actividad primordial de la ingeniería. A principios de
la década de 1990, Mitch Kapor, presento un “manifiesto sobre el diseño de software” en Dr.
Dobbs jornual. Ahí afirma.

¿Qué es el diseño? Es el lugar en donde una persona se puede parar con un pie en dos
mundos, el mundo de la tecnología y el de la gente y los propósitos humanos, e intenta unirlos.

El crítico de la arquitectura romana Vitruvius aporto la noción de que las construcciones bien
diseñadas eran aquellas que mostraban firmeza, comodidad y placer. Lo mismo debe decirse del
buen software. Firmeza: el programa no debe tener ningún error que inhiba su función.
Comodidad: un programa debe cumplir con los propósitos para los que fue creado. Placer: la
experiencia de usar el programa debe ser agradable. Aquí se presentan los principios de una
teoría de diseño de software.

Proceso y calidad del diseño

El diseño del software es un proceso iterativo mediante el cual los requerimientos se traducen en
un “plano” para construir el software. Para lograr que un diseño sea presentable se deben seguir
ciertas pautas.

Características para la evaluación

1. Implementar todos los requisitos explícitos contenidos en el modelo de análisis, y

ajustarse a todos los requisitos del cliente.
2. Debe ser una guía legible y comprensible para quienes generan el código y quienes
realizan pruebas, es decir, dan soporte al software.
3. Debe proporcionar una imagen completa del software desde una perspectiva de
implementación.

¿Cómo alcanzar las metas del proceso?

1. Un diseño debe presentar una estructura arquitectónica que se halla creado mediante
patrones de diseño reconocibles, la integren componentes que exhiban buenas
características de diseño y que pueda implementarse de manera evolutiva para que de
estar forma facilite la implementación y las pruebas.
2. Un diseño debe ser modular.
3. Un diseño debe contener distintas representaciones de los datos, la arquitectura, las
interfaces y los componentes.
4. Un diseño debe conducir a estructuras de datos que sean apropiadas para las clases
que habrán de implementarse y que procedan de patrones de datos reconocibles.
5. Un diseño debe conducir a componentes que representan características funcionales
independientes.
6. Un diseño debe conducir a interfaces que reduzcan la complejidad de las conexiones
entre los componentes y el ambiente externo.
7. Un diseño debe obtenerse por medio de un método repetible que se base en la
información obtenida durante el análisis de requisitos del software.
8. Un diseño debe representarse por medio de una notación que comunique de manera
eficaz su significado.

Características

1. La funcionalidad.
2. La facilidad.
3. La confiabilidad.
4. El desempeño.
5. La so portabilidad, la adaptabilidad y la servicialidad.

Definiciones del diseño

 La abstracción es una de las formas fundamentales en las que los humanos se

enfrentan a la complejidad. La arquitectura es la estructura u organización de los
 componentes del programa módulos, la manera en que estos componentes interactúan,
y la estructura de datos que utilizan los componentes.
 Los patrones describen una estructura de diseño que resuelve un problema de diseño
particular dentro de un contexto especifico y en medio de “fuerzas” que pueden tener un
impacto en la manera en la que se aplica y utiliza el patrón, de manera tal que el
diseñador pueda decidir si este es el necesario o el que puede usar para su trabajo
actual.
 La modularidad, el software se divide en componentes con nombres independientes y
que es posible maniobrar de forma individual. Estos componentes llamados módulos se
integran para satisfacer los requisitos del problema.
 La ocultación de la información sugiere que los módulos se caracterizan por las
decisiones de diseño que oculta a los otros. En otras palabras el módulo debe diseñarse
de forma que la información sea inaccesible para otro módulo que no necesite esta
información.
 La independencia funcional surge como resultado de la suma directa de la modularidad y
de los conceptos de abstracción y ocultación de información pues cada módulo del
software debe ser capaz de funcionar por sí solo.

Refinamiento es un proceso de elaboración.

 Se inicia con el enunciado de una función o descripción de los datos que se define como
un alto grado de abstracción.
 Este describe los datos o función de manera conceptual pero no proporciona información
acerca de los trabajos internos de la función o estructura interna de los datos.
 El refinamiento hace que el diseñador trabaje sobre el enunciado original y que
proporcione más y más detalles conforme se realiza cada refinamiento sucesivo.

Refabricación técnica de reorganización que simplifica el diseño (o código) de un componente

sin cambiar su función o comportamiento, dicho de otra manera, "es el proceso de cambiar un
sistema de software de tal forma que no altere el comportamiento externo de su código (diseño)
y aun así se mejore su estructura interna".

Tipos de patrones

1. Arquitectónicos definen la estructura general del software, relaciones entre los

subsistemas y los componentes de software, y las reglas para especificar las relaciones
entre los elementos de la arquitectura.
2. De diseño agregado de componentes que se aplica a un elemento específico para
resolver problemas de diseño, relaciones.
3. Idiomas (patrones de código) patrones específicos de lenguajes por lo general
implementan un algoritmo, un protocolo de interfaz entre los componentes.

ABSTRACCIÓN

Cuando se considera una solución modular a cualquier problema se pueden exponer muchos
grados de abstracción. En un alto grado de abstracción una solución se establece en términos
generales con el lenguaje del entorno del problema. En los grados de menor abstracción se
proporciona una descripción más detallada de la solución.
“la abstracción es una de las formas fundamentales en las que el humano se enfrente a la
complejidad”.

En la medida en que cambian los diferentes grados de abstracción se trabaja para crear
abstracciones procedimentales y de datos. Una abstracción procedimental se refiere a una
secuencia de instrucciones que tiene una función específica y limitada. El nombre de abstracción
procedimental implica estas funciones, pero se omiten detalles específicos. Un ejemplo de
abstracción procedimental sería la palabra abrir para una puerta. Abrir implica una larga
secuencia de pasos procedimentales (por ejemplo, caminar a la puerta, alcanzar la manija, darle
vuelta a la manija y empujar la puerta, hacerse a un lado para abrir paso a la puerta que se abre,
etc.).

Una abstracción de datos es una colección nombrada de datos que describe un objeto de datos.
En el contexto de abstracción procedimental, abrir se puede definir como una abstracción de
datos llamada puerta. Como cualquier objeto de datos, la abstracción de datos para puerta
abarcaría una serie de atributos que la describan (por ejemplo, puerta, tipo, dirección de
apertura. mecanismo de apertura, peso, dimensiones). Se puede decir que la abstracción
procedimental abrir emplearía la información contenida en los atributos de la abstracción de
datos. Puerta.

ARQUITECTURA.

La arquitectura del software alude a “la estructura general del software y las formas en que la
estructura proporciona una integridad conceptual para un sistema”. En su forma más simple, la
arquitectura es la estructura u organización de los componentes del programa (módulos), la
manera en que estos componentes interactúan, y la estructura de datos que utilizan los
componentes. En un sentido más amplio, sin embargo, los componentes pueden generalizarse
para representar elementos importantes del sistema y sus interacciones.

“Una arquitectura del software es el producto del trabajo de desarrollo que ofrece el mayor
rendimiento de la inversión con respecto a la calidad, el tiempo y el costo.”

Una de las metas del diseño de software es derivar una representación arquitectónica de un
sistema. Esta representación sirve como el marco de trabajo a partir del cual se conducen
actividades de diseño más detalladas. Un conjunto de patrones arquitectónicos permite que un
ingeniero de software reutilice conceptos en el nivel de diseño.

El diseño arquitectónico puede representarse al usar uno o más de muchos modelos diferentes.
Los modelos estructurales representan la arquitectura como una colección organizada de
componentes del programa. Los modelos del marco de trabajo incrementan el grado de
abstracción del diseño al intentar identificar marcos de trabajo repetibles del diseño
arquitectónico que se encuentran en tipos de aplicaciones similares. Los modelos dinámicos
abordan los aspectos conductuales de la arquitectura del programa, al indicar cómo puede
cambiar la configuración de la estructura o el sistema, como función de los eventos externos. Los
modelos del proceso se centran en el diseño del proceso técnico o de negocios que el sistema
debe contener. Por último, los modelos funcionales pueden utilizarse para representar la
jerarquía funcional de un sistema.

“Cada patrón describe un problema que ocurre uno y otra vez en nuestro entorno, y después
describe la esencia de la solución a dicho problema, de tal formo que puedas usar esta solución
un millón de veces más, sin nunca hacerlo dos veces de la misma forma.”

La finalidad de cada patrón de diseño es proporcionar una descripción que le permita al

diseñador determinar

1) si el patrón es aplicable al trabajo actual.

2) si el patrón se puede reutilizar (por ende, ahorrar tiempo del diseño)

3) si el patrón puede servir como guía para desarrollar un patrón similar, pero diferente en
cuanto a la funcionalidad o estructura.

MODULARIDAD

Los patrones de arquitectura y diseño de software materializan la modularidad; es decir, el

software se divide en componentes con nombres independientes y que es posible abordar en
forma individual. Estos componentes llamados módulos se integran para satisfacer los requisitos
del problema.

Se ha establecido que la “modularidad es el atributo particular del software que permite que un
programa sea manejable de manera intelectual.” El software monolítico (es decir, un programa
grande compuesto por un módulo sencillo) no puede entenderlo con facilidad un ingeniero de
software. El número de rutas de control, la amplitud de las referencias, el número de variables y
la complejidad general imposibilitaría comprenderlo. Este punto se ilustra con el siguiente
argumento, basado en observaciones de solución de problemas humanos.

También se deduce que la complejidad observada de dos problemas, cuando están combinados,
con frecuencia es mayor que la suma de las complejidades observadas cuando cada una de
ellas se toma por separado: esto conduce a una estrategia de “divide y vencerás” (es más fácil
resolver un problema complejo cuando éste se divide en piezas más manejables). Esto tiene
implicaciones importantes con respecto a la modularidad y al software. De hecho, es un
argumento para la modularidad.

Es posible concluir que si el software se subdivide en forma indefinida, el esfuerzo requerido

para desarrollarlo se reducirá en forma sensible. Por desgracia, hay otras fuerzas que entran en
juego, lo que ocasiona que esta conclusión sea (tristemente) inválida. el esfuerzo (costo) para
desarrollar un solo módulo de software decrece conforme se incrementa el número de módulos.
Si se tiene el mismo conjunto de requisitos, más módulos significan un tamaño individual menor.
Sin embargo, a medida que crece el número de módulos, el esfuerzo (costo) asociado con la
integración de los módulos también crece. Existe un número M de módulos que resultaría en un
costo de desarrollo mínimo, aunque hasta el momento no se tiene la sofisticación necesaria para
predecir M con seguridad.
REFINAMIENTO

La abstracción y el refinamiento son conceptos complementarios

La abstracción le permite al a un diseñador especificar procedimientos y datos sin considerar

detalles de grado menor

El refinamiento ayuda al diseñador a revelar los detalles de grado menor mientras se realiza el
diseño

Ambos conceptos auxilian al diseñador en la creación de un modelo de diseño completo a

medida que evoluciona la actividad de diseño

CLASES DE DISEÑO

1. Las clases de interfaz con el usuario definen las abstracciones necesarias para la
interacción humano-computadora.
2. Las clases del dominio de negocios proceso de refinamiento de las clases anteriores,
donde se identifican los atributos y servicios necesarios para implementar algún
elemento del dominio de negocios.
3. Las clases del proceso implementan abstracciones del negocio en un nivel más bajo, las
cuales se requieren para el manejo de las clases del dominio de negocio.
4. Las clases persistentes representan almacenamientos de datos que persistirán más allá
de la ejecución el software.
5. Las clases de sistema implementan las funciones que permite que el sistema opere y se
comunique dentro de su entorno de computación y con el mundo exterior.

 Las clases de interfaz con el usuario definen todas las abstracciones necesarias para la
interacción humano-computadora (IHC). En muchos casos, la (IHC). En muchos casos,
la IHC ocurre dentro del contexto de una metáfora (por ejemplo, un libro de verificación,
un formato de orden, una máquina de fax) y las clases de diseño para la interfaz pueden
ser representaciones visuales de los elementos de la metáfora.

• Las clases del dominio de negocios a menudo son refinamientos de las clases de análisis.
Las clases identifican los atributos y servicios (métodos) necesarios para implementar algún
elemento del dominio de negocios.

• Las clases de proceso implementan abstracciones del negocio en un nivel más bajo, las
cuales se requieren para manejar por completo las clases del dominio de negocios.

• Las clases persistentes representan almacenamientos de datos (por ejemplo, una base de
datos) que persistirán más allá de la ejecución del software.

Características de una clase de diseño

1. Completa y suficiente una clase de diseño debe ser la encapsulación completa de todos
los atributos y métodos que se pueden esperar, en forma razonable, que existan para la
 clase, es decir, que debe contener los métodos aquellos que sean suficientes para lograr
el objetivo ni más ni menos.
2. Primitivismo, los métodos asociados a una clase de diseño deben enfocarse en el
cumplimiento de un servicio para la clase. Una vez que el servicio ha sido implementado
con un método, la clase no debe proporcionar otra forma de complementar la misma.
3. Cohesión alta, una clase de diseño cohesiva tiene un conjunto de responsabilidades
pequeño y enfocado, y aplica atributos y métodos de manera sencilla para implementar
dichas responsabilidades.
4. Acoplamiento bajo dentro del modelo de diseño es necesario que las clases de diseño
colaboren con alguna otra. Sin embargo, la colaboración se debe mantener en un
mínimo aceptable. Si un modelo de diseño tiene un acoplamiento alto, el sistema es
difícil de implementar, probar y mantener a través del tiempo. En general las clases de
diseño dentro de un subsistema deben tener solo un conocimiento limitado de las clases
en otros subsistemas. Esta restricción, llamada la Ley de Deméter, sugiere que un
método solo debe enviar mensajes a métodos de clases vecinas.

BIBLIOGRAFÍA
Libros:
Booch G.
1996.
2° Edición.
Editorial Adison Wesley Longman.
Análisis y Diseño Orientado a Objetos con Aplicaciones.
México, Edo. de México.
Pressman R.G.
1995.
3° Edición.
Editorial McGraw Hill.
Ingeniería del Software. Un Enfoque Práctico.
México, DF.