SlideShare a Scribd company logo
1 of 33
Wendy Oliveros CI: 21676071
Nicola Pizzi CI: 20140117
Fundamentos
de Diseño
 A través de la historia de la ingeniería del software ha
evolucionado un conjunto de conceptos fundamentales
de diseño de software, aunque el grado deinterés en
cada concepto ha variado con los años, han pasado la
prueba del tiempo ofreciendo cada uno al ingeniero de
software fundamentos sobre el cual pueden
aplicarse métodos de diseño más elaborados.
 El diseño de Software juega un papel importante en
el desarrollo de software lo cual permite al ingeniero de
software producir
varios modelos delsistema o producto de que se va a
construir el mismo que forman una especie de plan de
la solución de la aplicación.
DISEÑO DE SOFTWARE
DISEÑO DE SOFTWARE
 Estos modelos puede evaluarse en relación con
su calidad y mejorarse antes de generar código, de
realizar pruebas y de que los usuarios finales se vean
involucrados a gran escala. El diseño es el sitio en el
que se establece la calidad del software.
 El diseño del software se encuentra en el núcleo técnico
de la ingeniería del software y se aplica
independientemente del modelo de diseño de software
que se utilice.
 Una vez que se analizan y especifican los requisitos del
software, el diseño del software es la primera de las tres
actividades técnicas - diseño, generación de código y
pruebas- que se requieren para construir y verificar el
software.
IMPORTANCIA DEL DISEÑO DE SOFTWARE
 La importancia del diseño del software se puede
describir con una sola palabra -calidad-. El diseño es el
lugar en donde se fomentará la calidad en la ingeniería
del software. El diseño proporciona las
representaciones del software que se pueden evaluar
en cuanto a calidad. El diseño es la única forma de
convertir exactamente los requisitos de un cliente en un
producto o sistema de software finalizado. El dise- ño
del software sirve como fundamento para todos los
pasos siguientes del soporte del software y de la
ingeniería del software.
PERSISTENCIAS, ALMACENAMIENTO,
EXCEPCIONES ENTRE OTRAS
 Persistencia es el "arte" de almacenar
y/o recuperar el estado de un objeto. No
todo campo de un objeto requiere
persistir, puede ser calculado, en tal
caso a ese campo se lo llama
trasciente. Por ejemplo si tengo una
clase que representa un triángulo
rectángulo entonces el estado a
almacenarse corresponderá a las
dimensión de los lados, mientras que la
hipotenusa es un campo trasciente ya
que resulta de aplicar la eterna
ecuación pitagórica.
PERSISTENCIAS, ALMACENAMIENTO,
EXCEPCIONES ENTRE OTRAS
 Los almacenes de datos internos y externos dentro de
un sistema proporcionan puntos limpios de separación
entre subsistemas con interfaces bien definidas. En
general, todo almacén de datos puede
combinar estructuras de datos, archivos y bases de
datos implementados en memoria o bien en dispositivos
de almacenamiento secundario. Los distintos tipos de
almacenes de datos proporcionan diversas
compensaciones entre costo, tiempo de acceso,
capacidad y fiabilidad.
MÉTODOS PARA LA ACTIVIDAD DE DISEÑO
 Resulta necesario establecer un enfoque sistemático y
disciplinado para llevar a cabo un desarrollo software.
 Una metodología de ingeniería del software es un
proceso para producir software de forma organizada,
empleando una colección de técnicas y convenciones
de notación predefinidas.
 Conjunto de procedimientos, técnicas, herramientas y
un soporte documental que ayuda a los desarrolladores
a realizar nuevo software.
MÉTODOS PARA LA ACTIVIDAD DE DISEÑO
 Un conjunto estructurado de actividades y resultados
asociados que conducen a la creación de un producto
de software:
 Especificación de requisitos: Definir la funcionalidad y
las restricciones en sus operaciones
 Diseño e implementación: Producir software que cumple
la especificación
 Validación: Asegurar que hace lo que el cliente desea.
 Mantenimiento (o Evolución): Seguir cumpliendo los
cambios en las necesidades del usuario.
PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE
EL DISEÑO Y REQUERIMIENTOS
Un buen diseñador
debería considerar
enfoques alternativos
Se debería poder
seguir los pasos del
diseño hasta el modelo
del análisis
El diseñador no debe
inventar nada de lo
que ya esté inventado
Uniformidad e
integración
Debe estructurarse
para admitir cambios
Estructurarse para
degradarse poco a
poco
El diseño no es escribir
códigos y viceversa
Valorar el diseño
mientras se crea
Revisar el diseño para
minimizar errores
conceptuales
PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE
EL DISEÑO Y REQUERIMIENTOS
 El diseño de interacción determina las posibilidades de
operación de un sistema tecnológico: las posibilidades
de acción de las personas que lo usarán, y las
reacciones del sistema ante estas acciones.
 El diseño de interacción y el diseño de la interfaz son
mutuamente dependientes, muchas veces las
decisiones de un plano condicionarán las decisiones en
el otro plano.
 Hasta el momento1, los sistemas electrónicos y
tecnológicos en general, no están dotados de
inteligencia propia. Todo sistema será tan inteligente
como su diseño permita.
PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE
EL DISEÑO Y REQUERIMIENTOS
 El diseño de interacción comienza durante las etapas
estratégicas del diseño, con la definición de
requerimientos y funcionalidades, elementos claves que
dan forma a la estrategia del sistema. Al hablar de
diseño estratégico nos referimos a decisiones de
negocios que permiten elegir una estrategia a tomar con
un producto: estrategias de diferenciación de la
competencia, audiencia primaria a enfocar el producto.
PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE
EL DISEÑO Y REQUERIMIENTOS
 El diseño de un producto tecnológico es un proceso
complejo con múltiples dimensiones, estas decisiones
estratégicas dan forma al producto, aunque muchas
veces se las considere fuera del proceso de diseño.
 Para crear un diseño amigable es fundamental entender
a las personas que usarán el sistema, por esto parte
importante de este trabajo consiste en entrevistar
personas que representen al tipo de usuario final del
sistema. Empaparse del modo de pensar, las
necesidades y el lenguaje de los usuarios permitirá al
diseñador estar en mejor pie para anticipar sus
expectativas y reacciones, generando una interacción
natural para ellos.
DISEÑO DE ATRIBUTOS DE CALIDAD
(FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD,
EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
○ Los atributos de calidad son las cualidades o
propiedades de calidad que la aplicación debe
satisfacer.
o La calidad de una aplicación se mide en función de
sus atributos de calidad.
o Para facilitar su medición durante la verificación,
deben expresarse cuantitativa o cualitativamente.
DISEÑO DE ATRIBUTOS DE CALIDAD
(FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD,
EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
Del Software
Asociado a la Funcionalidad
Asociado a la Confiabilidad
Asociado a la Utilidad
Asociado a la Eficiencia
Calidad
Asociado a la Mantenibilidad
Asociado a la Portabilidad
DISEÑO DE ATRIBUTOS DE CALIDAD
(FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD,
EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
DISEÑO DE ATRIBUTOS DE CALIDAD
(FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD,
EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 El diseño de la arquitectura de software es una fase
muy importante en el ciclo de vida del software. Es
absolutamente necesario desempeñar é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.
 Una arquitectura de software se selecciona y diseña
con base en objetivos y restricciones. Los objetivos son
aquellos prefijados para el sistema de información, pero
no solamente los de tipo funcional, también otros
objetivos como la mantenibilidad, auditabilidad,
flexibilidad e interacción con otros sistemas de
información.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 Las restricciones son aquellas limitaciones derivadas de
las tecnologías disponibles para implementar sistemas
de información. Unas arquitecturas son más
recomendables de implementar con ciertas tecnologías
mientras que otras tecnologías no son aptas para
determinadas arquitecturas. Por ejemplo, no es viable
emplear una arquitectura de software de tres capas
para implementar sistemas en tiempo real.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 En toda tarea humana, podemos encontrar una serie
de patrones que se repiten. Incluso en las bellas artes,
actividad representativa de la creatividad humana,
podemos hallar características comunes que nos
permiten clasificar las obras en distintos movimientos
artísticos. Y cómo no, en el arte de la programación no
iba a ser menos.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 Era de esperar, por tanto, que alguien se animara tarde
o temprano a estudiar los distintos patrones que pueden
encontrarse en la inmensa mayoría del software, de
forma que los problemas solucionados por estos
quedasen perfectamente clasificados junto con su
solución, para que así no fuese necesario reinventar la
rueda cada vez que un programador se enfrentase a un
obstáculo similar al descrito en uno de estos patrones.
Nacieron así los patrones de diseño de sistemas
software.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 Un patrón de diseño debe cumplir al menos dos
requisitos para considerarse como tal: Debe ser
efectivo, de modo que se haya podido comprobar su
éxito resolviendo problemas anteriores; y debe
ser reutilizable, es decir, podemos aplicarlo a problemas
que se hallan en circunstancias similares a las descritas
por el patrón.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 Imagina cuán sencillo sería poder comentar un
problema de diseño con un compañero, y poder decirle
algo tan sencillo como: “Esto es un patrón adapter”;
siendo este breve comentario suficiente como para que
tu interlocutor te entendiese perfectamente y sepa cómo
hay que resolver el problema al que te enfrentas.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 Reusabilidad – Cada fragmento de software debe ser lo
más reutilizable posible (a menos que sea aplicativo), y
reutilizar otros componentes lo mayor posible.
 Cuando desarrollas software, el factor de reusabilidad
es crucial, especialmente cuanto tienes plazos que
cumplir. Divide tu código en varias librerías 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 están
involucrados.
ARQUITECTURA, PATRONES DE DISEÑO Y
REÚSO
 Si solamente tienes un proyecto, aún así deberías
reutilizar. Deberías separar código reutilizable en
una librería lo que te permitirá simplificar aún más el
código a mantener.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 DISEÑO ORIENTADO A FUNCIONES
(ESTRUCTURADO)
 El diseño estructurado se utiliza generalmente
después de un análisis estructurado, cuyo
producto es el diagrama de flujo de datos y las
descripciones de procesos. Los investigadores
han propuesto diversas estrategias y heurísticas,
como por ejemplo fan-in/fan-out, para
transformar un DFD en una arquitectura de
software en general representada como una
estructura chart.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 Como un método de diseño, ésta es realmente una
combinación de dos técnicas diferentes,
interrelacionadas. La primera es el Análisis de Sistemas
Estructurados(SSA), que se ocupa de la construcción
de un modelo del problema mediante el uso de
Diagramas de Flujo de Datos (DFD). La segunda es el
diseño estructurado (SD), que a su vez se orienta hacia
los aspectos relacionados con la búsqueda de
soluciones (diseño detallado) mediante el uso de la
estructura chart.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 DISEÑO ORIENTADO A OBJETOS
 Existen numerosos métodos de diseño
de software basado en objetos que han
sido propuestos desde la década de
1980. De manera informal, de acuerdo a
su elaboración, se los ubica en tres
generaciones (Budgen, 2003):
 •Métodos de primera generación:
Desarrollados en la década de 1970 y
principios de 1980, estos métodos
tienen una tendencia evolutiva. Se
caracterizan por tener formas limitadas
de notación diagramática y procesos
débiles.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 Este método no ofrece una forma eficaz para el uso de
la propiedad de herencia y el concepto de jerarquía de
clases. Sin embargo, se limita exclusivamente a las
características de objetos como: la modularidad, el
encapsulamiento y la abstracción.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 •Métodos de segunda generación: Desarrollados a
mediados de la década de 1990, estos métodos son
considerados revolucionarios. El método Fusión
desarrollado en 1994 integra y amplia los elementos de
mayor éxito de las prácticas existentes hasta ese
entonces. Al igual que HOOD, Fusión emplea una
combinación de texto y diagramas, aunque la
proporción de diagramas es mucho mayor. Fusión
cuenta con un diagrama de clase (Denominado el
modelo de objetos) que trata de proporcionar un punto
de vista de la construcción de un sistema. Mientras que
el modelado del comportamiento de clase hace uso de
descripciones textuales.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 El Proceso Unificado: Surgió en la década de 1990
como resultado de unir las ideas y enfoques empleados
por Booch, Jacobson y Rumbaugh. Se relaciona
estrechamente con el desarrollo en paralelo de UML.
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 DISEÑO BASADO EN COMPONENTES
 Un componente de software es una unidad
independiente, que posee interfaces bien definidas y
dependencias que pueden ser construidas e
implementadas de forma separada. El diseño basado
en componentes busca proveer, desarrollar e integrar
dichos componentes (Budgen, 2003).
 Una de las principales razones para optar por este
diseño es promover la reutilización, la misma que
permite reducir los costos de elaboración del producto
final (Budgen, 2003). Existen dos características que se
deben tomar en cuenta para la reutilización:
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 Funcionalidad bien definida, para facilitar la
identificación de los componentes útiles, que satisfagan
los requerimientos.
 Los componentes deben tener interfaces bien definidas
que permitan su interrelación.
 Sin embargo, existen varios problemas relacionados al
diseño utilizando componentes:
ESTRATEGIAS DE DISEÑO: ORIENTADA A
FUNCIONES, A OBJETOS, A COMPONENTES, A
ESTRUCTURA DE DATOS, A ASPECTOS
 Búsqueda del Componente: es una tarea complicada
encontrar un componente que satisfaga la funcionalidad
indicada para un sistema. Es necesario identificar
claramente las necesidades generales del problema,
para luego buscar un conjunto de componentes que
colectivamente resuelvan estas necesidades.
 Integración de componentes: pueden darse casos en
los cuales el conjunto de componentes no logra
satisfacer la funcionalidad requerida. De igual forma,
existe la posibilidad de que dos o más componentes
brinden la misma funcionalidad. Incluso, existe la
posibilidad de una incompatibilidad arquitectónica entre
componentes.

More Related Content

What's hot

Mapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de RequisitosMapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de Requisitosinmacu_
 
Fundamentos del diseño de software
Fundamentos del diseño de software Fundamentos del diseño de software
Fundamentos del diseño de software AlessandreMndez
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftChuyito Alvarado
 
Analisis y especificacion de requerimientos
Analisis y especificacion de requerimientosAnalisis y especificacion de requerimientos
Analisis y especificacion de requerimientosUPTP
 
Modelo iterativo
Modelo iterativoModelo iterativo
Modelo iterativotim100492
 
Modelo en cascada
Modelo en cascadaModelo en cascada
Modelo en cascadahome
 
Problemas en el desarrollo de software
Problemas en el desarrollo de software Problemas en el desarrollo de software
Problemas en el desarrollo de software Arielkad
 
TAREAS DE LA ING. DE REQUISITOS
TAREAS DE LA ING. DE REQUISITOSTAREAS DE LA ING. DE REQUISITOS
TAREAS DE LA ING. DE REQUISITOSxinithazangels
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de softwareYaskelly Yedra
 
Unidad 2 concepto de Programa,Proceso y Procesador
Unidad 2  concepto de Programa,Proceso y ProcesadorUnidad 2  concepto de Programa,Proceso y Procesador
Unidad 2 concepto de Programa,Proceso y ProcesadorMario Alberto Antonio Lopez
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareantonio
 
Clasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de softwareClasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de softwareElvisAR
 
Ingenieria de Software-Somerville.pdf
Ingenieria de Software-Somerville.pdfIngenieria de Software-Somerville.pdf
Ingenieria de Software-Somerville.pdfSergio283420
 
Analisis de requerimiento
Analisis de requerimientoAnalisis de requerimiento
Analisis de requerimientoturlahackers
 

What's hot (20)

1.3 La memoria principal ram
1.3 La memoria principal ram1.3 La memoria principal ram
1.3 La memoria principal ram
 
Modelo en cascada
Modelo en cascadaModelo en cascada
Modelo en cascada
 
Mapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de RequisitosMapa conceptual Ingeniería de Requisitos
Mapa conceptual Ingeniería de Requisitos
 
Fundamentos del diseño de software
Fundamentos del diseño de software Fundamentos del diseño de software
Fundamentos del diseño de software
 
Ventajas y desventajas de moprosoft
Ventajas y desventajas de moprosoftVentajas y desventajas de moprosoft
Ventajas y desventajas de moprosoft
 
Analisis y especificacion de requerimientos
Analisis y especificacion de requerimientosAnalisis y especificacion de requerimientos
Analisis y especificacion de requerimientos
 
Modelo iterativo
Modelo iterativoModelo iterativo
Modelo iterativo
 
Etapa de estudio de viabilidad de un proyecto informático c4
Etapa de estudio de viabilidad de un proyecto informático c4Etapa de estudio de viabilidad de un proyecto informático c4
Etapa de estudio de viabilidad de un proyecto informático c4
 
Modelo en cascada
Modelo en cascadaModelo en cascada
Modelo en cascada
 
Reingenieria inversa
Reingenieria inversaReingenieria inversa
Reingenieria inversa
 
Problemas en el desarrollo de software
Problemas en el desarrollo de software Problemas en el desarrollo de software
Problemas en el desarrollo de software
 
Modelado conceptual de aplicaciones web
Modelado conceptual de aplicaciones webModelado conceptual de aplicaciones web
Modelado conceptual de aplicaciones web
 
TAREAS DE LA ING. DE REQUISITOS
TAREAS DE LA ING. DE REQUISITOSTAREAS DE LA ING. DE REQUISITOS
TAREAS DE LA ING. DE REQUISITOS
 
Modelo de desarrollo de software
Modelo de desarrollo de softwareModelo de desarrollo de software
Modelo de desarrollo de software
 
Unidad 2 concepto de Programa,Proceso y Procesador
Unidad 2  concepto de Programa,Proceso y ProcesadorUnidad 2  concepto de Programa,Proceso y Procesador
Unidad 2 concepto de Programa,Proceso y Procesador
 
Segmentacion de memoria
Segmentacion de memoriaSegmentacion de memoria
Segmentacion de memoria
 
Tecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto softwareTecnicas de estimacion de costos de proyecto software
Tecnicas de estimacion de costos de proyecto software
 
Clasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de softwareClasificación de las metodologías de desarrollo de software
Clasificación de las metodologías de desarrollo de software
 
Ingenieria de Software-Somerville.pdf
Ingenieria de Software-Somerville.pdfIngenieria de Software-Somerville.pdf
Ingenieria de Software-Somerville.pdf
 
Analisis de requerimiento
Analisis de requerimientoAnalisis de requerimiento
Analisis de requerimiento
 

Viewers also liked

Aspectos importantes acerca de internet xd
Aspectos importantes acerca de internet xdAspectos importantes acerca de internet xd
Aspectos importantes acerca de internet xdDiego Estacio
 
14. fundamentos de desarrollo de software
14. fundamentos de desarrollo de software14. fundamentos de desarrollo de software
14. fundamentos de desarrollo de softwareJhon Barrera
 
Fundamentos Básicos Del Diseño II
Fundamentos Básicos Del Diseño IIFundamentos Básicos Del Diseño II
Fundamentos Básicos Del Diseño IIGerardo González
 
Fundamentos de la ingenieria del software
Fundamentos de la ingenieria del softwareFundamentos de la ingenieria del software
Fundamentos de la ingenieria del softwarealberto calatayu
 
Principios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del softwarePrincipios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del softwareJose Patricio Bovet Derpich
 
METODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWAREMETODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWAREadark
 
Unidad 1 - Fundamentos del diseño gráfico
Unidad 1  - Fundamentos del diseño gráficoUnidad 1  - Fundamentos del diseño gráfico
Unidad 1 - Fundamentos del diseño gráficoFidel Romero
 
Patrones de diseño de software
Patrones de diseño de softwarePatrones de diseño de software
Patrones de diseño de softwareIker Canarias
 

Viewers also liked (14)

Aspectos importantes acerca de internet xd
Aspectos importantes acerca de internet xdAspectos importantes acerca de internet xd
Aspectos importantes acerca de internet xd
 
14. fundamentos de desarrollo de software
14. fundamentos de desarrollo de software14. fundamentos de desarrollo de software
14. fundamentos de desarrollo de software
 
Fundamentos Básicos Del Diseño II
Fundamentos Básicos Del Diseño IIFundamentos Básicos Del Diseño II
Fundamentos Básicos Del Diseño II
 
Fundamentos de la ingenieria del software
Fundamentos de la ingenieria del softwareFundamentos de la ingenieria del software
Fundamentos de la ingenieria del software
 
Principios diseño del software
Principios diseño del software Principios diseño del software
Principios diseño del software
 
Principios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del softwarePrincipios de diseño de la arquitectura del software
Principios de diseño de la arquitectura del software
 
Top down
Top downTop down
Top down
 
Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)Fundamentos de ingenieria del software (2)
Fundamentos de ingenieria del software (2)
 
METODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWAREMETODOLOGÍA PARA EL DISEÑO DE SOFTWARE
METODOLOGÍA PARA EL DISEÑO DE SOFTWARE
 
Ieee 830
Ieee 830Ieee 830
Ieee 830
 
Diseño de Software
Diseño de SoftwareDiseño de Software
Diseño de Software
 
Unidad 1 - Fundamentos del diseño gráfico
Unidad 1  - Fundamentos del diseño gráficoUnidad 1  - Fundamentos del diseño gráfico
Unidad 1 - Fundamentos del diseño gráfico
 
Fundamentos del diseño
Fundamentos del diseñoFundamentos del diseño
Fundamentos del diseño
 
Patrones de diseño de software
Patrones de diseño de softwarePatrones de diseño de software
Patrones de diseño de software
 

Similar to Fundamentos de Diseño - Grupo Delta

Actividad remedial_Maria_Albarran
Actividad remedial_Maria_AlbarranActividad remedial_Maria_Albarran
Actividad remedial_Maria_AlbarranMarijoalbarranb
 
Unidad 1 Ingenieria de software
Unidad 1 Ingenieria de softwareUnidad 1 Ingenieria de software
Unidad 1 Ingenieria de softwareJahiro Bojorquez
 
Metodologias de analisis y diseño de sistemas
Metodologias de analisis y diseño de sistemasMetodologias de analisis y diseño de sistemas
Metodologias de analisis y diseño de sistemasgrupo7inf162
 
1. ciclo de_vida_de_software
1. ciclo de_vida_de_software1. ciclo de_vida_de_software
1. ciclo de_vida_de_softwareMiguel Castro
 
Fundamentos de diseño de software
Fundamentos de diseño de softwareFundamentos de diseño de software
Fundamentos de diseño de softwareLuis Jesus Curbata
 
Presentación Fundamentos Básicos del Diseño de Software Pedro Luces
Presentación Fundamentos Básicos del Diseño de Software Pedro LucesPresentación Fundamentos Básicos del Diseño de Software Pedro Luces
Presentación Fundamentos Básicos del Diseño de Software Pedro LucesPedroLuces3
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de softwareLiliana Pacheco
 
Ingeniería de software
Ingeniería de software Ingeniería de software
Ingeniería de software jevo1994
 
Tecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.softwareTecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.softwarejuankexmisiodj
 
Ingeniería de software y el paradigma orientado a objetos
Ingeniería de software y el paradigma orientado a objetosIngeniería de software y el paradigma orientado a objetos
Ingeniería de software y el paradigma orientado a objetosWilfredo Mogollón
 
Tarea semana 1
Tarea semana 1Tarea semana 1
Tarea semana 1preciadoag
 
Fundamentos basicos del diseño de software
Fundamentos basicos del diseño de softwareFundamentos basicos del diseño de software
Fundamentos basicos del diseño de softwareJesús Molleda
 
Metodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De SistemasMetodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De Sistemasgrupo7inf162
 

Similar to Fundamentos de Diseño - Grupo Delta (20)

Actividad remedial_Maria_Albarran
Actividad remedial_Maria_AlbarranActividad remedial_Maria_Albarran
Actividad remedial_Maria_Albarran
 
Unidad v
Unidad vUnidad v
Unidad v
 
Unidad 1 Ingenieria de software
Unidad 1 Ingenieria de softwareUnidad 1 Ingenieria de software
Unidad 1 Ingenieria de software
 
Metodologias de analisis y diseño de sistemas
Metodologias de analisis y diseño de sistemasMetodologias de analisis y diseño de sistemas
Metodologias de analisis y diseño de sistemas
 
1. ciclo de_vida_de_software
1. ciclo de_vida_de_software1. ciclo de_vida_de_software
1. ciclo de_vida_de_software
 
Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
Fundamentos de diseño de software
Fundamentos de diseño de softwareFundamentos de diseño de software
Fundamentos de diseño de software
 
Omar,luis,daniel
Omar,luis,danielOmar,luis,daniel
Omar,luis,daniel
 
Presentación Fundamentos Básicos del Diseño de Software Pedro Luces
Presentación Fundamentos Básicos del Diseño de Software Pedro LucesPresentación Fundamentos Básicos del Diseño de Software Pedro Luces
Presentación Fundamentos Básicos del Diseño de Software Pedro Luces
 
Arquitectura de software
Arquitectura de softwareArquitectura de software
Arquitectura de software
 
Ingeniería de software
Ingeniería de software Ingeniería de software
Ingeniería de software
 
Tecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.softwareTecnicas.de.ingenieria.de.software
Tecnicas.de.ingenieria.de.software
 
Adrian adrianza
Adrian adrianzaAdrian adrianza
Adrian adrianza
 
Ingeniería de software y el paradigma orientado a objetos
Ingeniería de software y el paradigma orientado a objetosIngeniería de software y el paradigma orientado a objetos
Ingeniería de software y el paradigma orientado a objetos
 
Ingenieria de software
Ingenieria de softwareIngenieria de software
Ingenieria de software
 
8.conceptos de diseño
8.conceptos de diseño8.conceptos de diseño
8.conceptos de diseño
 
Tarea semana 1
Tarea semana 1Tarea semana 1
Tarea semana 1
 
Tareasemana1
Tareasemana1Tareasemana1
Tareasemana1
 
Fundamentos basicos del diseño de software
Fundamentos basicos del diseño de softwareFundamentos basicos del diseño de software
Fundamentos basicos del diseño de software
 
Metodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De SistemasMetodologias De Analisis Y Diseño De Sistemas
Metodologias De Analisis Y Diseño De Sistemas
 

Recently uploaded

CONCLUSIONES DESCRIPTIVAS TIC que ayudaran a tus registrosdocx
CONCLUSIONES DESCRIPTIVAS TIC que ayudaran a tus registrosdocxCONCLUSIONES DESCRIPTIVAS TIC que ayudaran a tus registrosdocx
CONCLUSIONES DESCRIPTIVAS TIC que ayudaran a tus registrosdocxMarlynRocaOnofre
 
LA PRIMERA GUERRA MUNDIAL PARA NIÑOS.pdf
LA PRIMERA GUERRA  MUNDIAL PARA NIÑOS.pdfLA PRIMERA GUERRA  MUNDIAL PARA NIÑOS.pdf
LA PRIMERA GUERRA MUNDIAL PARA NIÑOS.pdfFEDERICOPEDRODIONISI
 
Comunidades Virtuales de Aprendizaje Caracteristicas.pptx
Comunidades Virtuales de Aprendizaje Caracteristicas.pptxComunidades Virtuales de Aprendizaje Caracteristicas.pptx
Comunidades Virtuales de Aprendizaje Caracteristicas.pptxJunkotantik
 
Tipologías de vínculos afectivos (grupo)
Tipologías de vínculos afectivos (grupo)Tipologías de vínculos afectivos (grupo)
Tipologías de vínculos afectivos (grupo)portafoliodigitalyos
 
Como construir los vínculos afectivos (Grupal)
Como construir los vínculos afectivos (Grupal)Como construir los vínculos afectivos (Grupal)
Como construir los vínculos afectivos (Grupal)portafoliodigitalyos
 
Lecciones 07 Esc. Sabática. Motivados por la esperanza
Lecciones 07 Esc. Sabática. Motivados por la esperanzaLecciones 07 Esc. Sabática. Motivados por la esperanza
Lecciones 07 Esc. Sabática. Motivados por la esperanzaAlejandrino Halire Ccahuana
 
LA GEOMETRÍA Y LOS SISTEMAS ANGULARES, APRENDER LEYENDO LA BIBLIA
LA GEOMETRÍA Y LOS SISTEMAS ANGULARES, APRENDER LEYENDO LA BIBLIALA GEOMETRÍA Y LOS SISTEMAS ANGULARES, APRENDER LEYENDO LA BIBLIA
LA GEOMETRÍA Y LOS SISTEMAS ANGULARES, APRENDER LEYENDO LA BIBLIASandra Mariela Ballón Aguedo
 
11.NEOLIBERALISMO: que es, ventajas, desventajas, consecuenciaspptx
11.NEOLIBERALISMO: que es, ventajas, desventajas, consecuenciaspptx11.NEOLIBERALISMO: que es, ventajas, desventajas, consecuenciaspptx
11.NEOLIBERALISMO: que es, ventajas, desventajas, consecuenciaspptxFESARAUGUSTOFANDIORI
 
Profecia 2300 dias explicada, Daniel 8:14
Profecia 2300 dias explicada, Daniel 8:14Profecia 2300 dias explicada, Daniel 8:14
Profecia 2300 dias explicada, Daniel 8:14KevinBuenrostro4
 
Vínculo afectivo (labor expositivo de grupo )
Vínculo afectivo (labor expositivo de grupo )Vínculo afectivo (labor expositivo de grupo )
Vínculo afectivo (labor expositivo de grupo )portafoliodigitalyos
 
📝 Semana 09 - Tema 01: Tarea - Redacción del texto argumentativo
📝 Semana 09 - Tema 01: Tarea - Redacción del texto argumentativo📝 Semana 09 - Tema 01: Tarea - Redacción del texto argumentativo
📝 Semana 09 - Tema 01: Tarea - Redacción del texto argumentativoharolbustamante1
 
a propósito del estado su relevancia y definiciones
a propósito del estado su relevancia y definicionesa propósito del estado su relevancia y definiciones
a propósito del estado su relevancia y definicionessubfabian
 
PLAN DE GESTION DEL RIESGO 2023 - 2024.docx
PLAN DE GESTION DEL RIESGO  2023 - 2024.docxPLAN DE GESTION DEL RIESGO  2023 - 2024.docx
PLAN DE GESTION DEL RIESGO 2023 - 2024.docxpily R.T.
 
Tema Identificar Relaciones y Casos de Uso 19-05-24.pdf
Tema Identificar Relaciones y Casos de Uso 19-05-24.pdfTema Identificar Relaciones y Casos de Uso 19-05-24.pdf
Tema Identificar Relaciones y Casos de Uso 19-05-24.pdfNoe Castillo
 
SISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docx
SISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docxSISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docx
SISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docxgesicavillanuevaqf
 

Recently uploaded (20)

CONCLUSIONES DESCRIPTIVAS TIC que ayudaran a tus registrosdocx
CONCLUSIONES DESCRIPTIVAS TIC que ayudaran a tus registrosdocxCONCLUSIONES DESCRIPTIVAS TIC que ayudaran a tus registrosdocx
CONCLUSIONES DESCRIPTIVAS TIC que ayudaran a tus registrosdocx
 
LA PRIMERA GUERRA MUNDIAL PARA NIÑOS.pdf
LA PRIMERA GUERRA  MUNDIAL PARA NIÑOS.pdfLA PRIMERA GUERRA  MUNDIAL PARA NIÑOS.pdf
LA PRIMERA GUERRA MUNDIAL PARA NIÑOS.pdf
 
Revista Faro Normalista 6, 18 de mayo 2024
Revista Faro Normalista 6, 18 de mayo 2024Revista Faro Normalista 6, 18 de mayo 2024
Revista Faro Normalista 6, 18 de mayo 2024
 
Comunidades Virtuales de Aprendizaje Caracteristicas.pptx
Comunidades Virtuales de Aprendizaje Caracteristicas.pptxComunidades Virtuales de Aprendizaje Caracteristicas.pptx
Comunidades Virtuales de Aprendizaje Caracteristicas.pptx
 
Sesión de clase Motivados por la esperanza.pdf
Sesión de clase Motivados por la esperanza.pdfSesión de clase Motivados por la esperanza.pdf
Sesión de clase Motivados por la esperanza.pdf
 
Power Point : Motivados por la esperanza
Power Point : Motivados por la esperanzaPower Point : Motivados por la esperanza
Power Point : Motivados por la esperanza
 
Tipologías de vínculos afectivos (grupo)
Tipologías de vínculos afectivos (grupo)Tipologías de vínculos afectivos (grupo)
Tipologías de vínculos afectivos (grupo)
 
La historia de la vida estudiantil a 102 años de la fundación de las Normales...
La historia de la vida estudiantil a 102 años de la fundación de las Normales...La historia de la vida estudiantil a 102 años de la fundación de las Normales...
La historia de la vida estudiantil a 102 años de la fundación de las Normales...
 
Como construir los vínculos afectivos (Grupal)
Como construir los vínculos afectivos (Grupal)Como construir los vínculos afectivos (Grupal)
Como construir los vínculos afectivos (Grupal)
 
Lecciones 07 Esc. Sabática. Motivados por la esperanza
Lecciones 07 Esc. Sabática. Motivados por la esperanzaLecciones 07 Esc. Sabática. Motivados por la esperanza
Lecciones 07 Esc. Sabática. Motivados por la esperanza
 
LA GEOMETRÍA Y LOS SISTEMAS ANGULARES, APRENDER LEYENDO LA BIBLIA
LA GEOMETRÍA Y LOS SISTEMAS ANGULARES, APRENDER LEYENDO LA BIBLIALA GEOMETRÍA Y LOS SISTEMAS ANGULARES, APRENDER LEYENDO LA BIBLIA
LA GEOMETRÍA Y LOS SISTEMAS ANGULARES, APRENDER LEYENDO LA BIBLIA
 
11.NEOLIBERALISMO: que es, ventajas, desventajas, consecuenciaspptx
11.NEOLIBERALISMO: que es, ventajas, desventajas, consecuenciaspptx11.NEOLIBERALISMO: que es, ventajas, desventajas, consecuenciaspptx
11.NEOLIBERALISMO: que es, ventajas, desventajas, consecuenciaspptx
 
Profecia 2300 dias explicada, Daniel 8:14
Profecia 2300 dias explicada, Daniel 8:14Profecia 2300 dias explicada, Daniel 8:14
Profecia 2300 dias explicada, Daniel 8:14
 
Vínculo afectivo (labor expositivo de grupo )
Vínculo afectivo (labor expositivo de grupo )Vínculo afectivo (labor expositivo de grupo )
Vínculo afectivo (labor expositivo de grupo )
 
📝 Semana 09 - Tema 01: Tarea - Redacción del texto argumentativo
📝 Semana 09 - Tema 01: Tarea - Redacción del texto argumentativo📝 Semana 09 - Tema 01: Tarea - Redacción del texto argumentativo
📝 Semana 09 - Tema 01: Tarea - Redacción del texto argumentativo
 
Sesión de clase: Luz desde el santuario.pdf
Sesión de clase: Luz desde el santuario.pdfSesión de clase: Luz desde el santuario.pdf
Sesión de clase: Luz desde el santuario.pdf
 
a propósito del estado su relevancia y definiciones
a propósito del estado su relevancia y definicionesa propósito del estado su relevancia y definiciones
a propósito del estado su relevancia y definiciones
 
PLAN DE GESTION DEL RIESGO 2023 - 2024.docx
PLAN DE GESTION DEL RIESGO  2023 - 2024.docxPLAN DE GESTION DEL RIESGO  2023 - 2024.docx
PLAN DE GESTION DEL RIESGO 2023 - 2024.docx
 
Tema Identificar Relaciones y Casos de Uso 19-05-24.pdf
Tema Identificar Relaciones y Casos de Uso 19-05-24.pdfTema Identificar Relaciones y Casos de Uso 19-05-24.pdf
Tema Identificar Relaciones y Casos de Uso 19-05-24.pdf
 
SISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docx
SISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docxSISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docx
SISTEMA RESPIRATORIO DEL CUERPO HUMANO triptico.docx
 

Fundamentos de Diseño - Grupo Delta

  • 1. Wendy Oliveros CI: 21676071 Nicola Pizzi CI: 20140117 Fundamentos de Diseño
  • 2.  A través de la historia de la ingeniería del software ha evolucionado un conjunto de conceptos fundamentales de diseño de software, aunque el grado deinterés en cada concepto ha variado con los años, han pasado la prueba del tiempo ofreciendo cada uno al ingeniero de software fundamentos sobre el cual pueden aplicarse métodos de diseño más elaborados.  El diseño de Software juega un papel importante en el desarrollo de software lo cual permite al ingeniero de software producir varios modelos delsistema o producto de que se va a construir el mismo que forman una especie de plan de la solución de la aplicación. DISEÑO DE SOFTWARE
  • 3. DISEÑO DE SOFTWARE  Estos modelos puede evaluarse en relación con su calidad y mejorarse antes de generar código, de realizar pruebas y de que los usuarios finales se vean involucrados a gran escala. El diseño es el sitio en el que se establece la calidad del software.  El diseño del software se encuentra en el núcleo técnico de la ingeniería del software y se aplica independientemente del modelo de diseño de software que se utilice.  Una vez que se analizan y especifican los requisitos del software, el diseño del software es la primera de las tres actividades técnicas - diseño, generación de código y pruebas- que se requieren para construir y verificar el software.
  • 4. IMPORTANCIA DEL DISEÑO DE SOFTWARE  La importancia del diseño del software se puede describir con una sola palabra -calidad-. El diseño es el lugar en donde se fomentará la calidad en la ingeniería del software. El diseño proporciona las representaciones del software que se pueden evaluar en cuanto a calidad. El diseño es la única forma de convertir exactamente los requisitos de un cliente en un producto o sistema de software finalizado. El dise- ño del software sirve como fundamento para todos los pasos siguientes del soporte del software y de la ingeniería del software.
  • 5. PERSISTENCIAS, ALMACENAMIENTO, EXCEPCIONES ENTRE OTRAS  Persistencia es el "arte" de almacenar y/o recuperar el estado de un objeto. No todo campo de un objeto requiere persistir, puede ser calculado, en tal caso a ese campo se lo llama trasciente. Por ejemplo si tengo una clase que representa un triángulo rectángulo entonces el estado a almacenarse corresponderá a las dimensión de los lados, mientras que la hipotenusa es un campo trasciente ya que resulta de aplicar la eterna ecuación pitagórica.
  • 6. PERSISTENCIAS, ALMACENAMIENTO, EXCEPCIONES ENTRE OTRAS  Los almacenes de datos internos y externos dentro de un sistema proporcionan puntos limpios de separación entre subsistemas con interfaces bien definidas. En general, todo almacén de datos puede combinar estructuras de datos, archivos y bases de datos implementados en memoria o bien en dispositivos de almacenamiento secundario. Los distintos tipos de almacenes de datos proporcionan diversas compensaciones entre costo, tiempo de acceso, capacidad y fiabilidad.
  • 7. MÉTODOS PARA LA ACTIVIDAD DE DISEÑO  Resulta necesario establecer un enfoque sistemático y disciplinado para llevar a cabo un desarrollo software.  Una metodología de ingeniería del software es un proceso para producir software de forma organizada, empleando una colección de técnicas y convenciones de notación predefinidas.  Conjunto de procedimientos, técnicas, herramientas y un soporte documental que ayuda a los desarrolladores a realizar nuevo software.
  • 8. MÉTODOS PARA LA ACTIVIDAD DE DISEÑO  Un conjunto estructurado de actividades y resultados asociados que conducen a la creación de un producto de software:  Especificación de requisitos: Definir la funcionalidad y las restricciones en sus operaciones  Diseño e implementación: Producir software que cumple la especificación  Validación: Asegurar que hace lo que el cliente desea.  Mantenimiento (o Evolución): Seguir cumpliendo los cambios en las necesidades del usuario.
  • 9. PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE EL DISEÑO Y REQUERIMIENTOS Un buen diseñador debería considerar enfoques alternativos Se debería poder seguir los pasos del diseño hasta el modelo del análisis El diseñador no debe inventar nada de lo que ya esté inventado Uniformidad e integración Debe estructurarse para admitir cambios Estructurarse para degradarse poco a poco El diseño no es escribir códigos y viceversa Valorar el diseño mientras se crea Revisar el diseño para minimizar errores conceptuales
  • 10. PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE EL DISEÑO Y REQUERIMIENTOS  El diseño de interacción determina las posibilidades de operación de un sistema tecnológico: las posibilidades de acción de las personas que lo usarán, y las reacciones del sistema ante estas acciones.  El diseño de interacción y el diseño de la interfaz son mutuamente dependientes, muchas veces las decisiones de un plano condicionarán las decisiones en el otro plano.  Hasta el momento1, los sistemas electrónicos y tecnológicos en general, no están dotados de inteligencia propia. Todo sistema será tan inteligente como su diseño permita.
  • 11. PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE EL DISEÑO Y REQUERIMIENTOS  El diseño de interacción comienza durante las etapas estratégicas del diseño, con la definición de requerimientos y funcionalidades, elementos claves que dan forma a la estrategia del sistema. Al hablar de diseño estratégico nos referimos a decisiones de negocios que permiten elegir una estrategia a tomar con un producto: estrategias de diferenciación de la competencia, audiencia primaria a enfocar el producto.
  • 12. PRINCIPIOS DEL DISEÑO, INTERACCIÓN ENTRE EL DISEÑO Y REQUERIMIENTOS  El diseño de un producto tecnológico es un proceso complejo con múltiples dimensiones, estas decisiones estratégicas dan forma al producto, aunque muchas veces se las considere fuera del proceso de diseño.  Para crear un diseño amigable es fundamental entender a las personas que usarán el sistema, por esto parte importante de este trabajo consiste en entrevistar personas que representen al tipo de usuario final del sistema. Empaparse del modo de pensar, las necesidades y el lenguaje de los usuarios permitirá al diseñador estar en mejor pie para anticipar sus expectativas y reacciones, generando una interacción natural para ellos.
  • 13. DISEÑO DE ATRIBUTOS DE CALIDAD (FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD, EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD) ○ Los atributos de calidad son las cualidades o propiedades de calidad que la aplicación debe satisfacer. o La calidad de una aplicación se mide en función de sus atributos de calidad. o Para facilitar su medición durante la verificación, deben expresarse cuantitativa o cualitativamente.
  • 14. DISEÑO DE ATRIBUTOS DE CALIDAD (FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD, EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD) Del Software Asociado a la Funcionalidad Asociado a la Confiabilidad Asociado a la Utilidad Asociado a la Eficiencia Calidad Asociado a la Mantenibilidad Asociado a la Portabilidad
  • 15. DISEÑO DE ATRIBUTOS DE CALIDAD (FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD, EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
  • 16. DISEÑO DE ATRIBUTOS DE CALIDAD (FUNCIONABILIDAD, CONFIABILIDAD, USABILIDAD, EFICIENCIA,MANTENIBILIDAD, TRANSPORTABILIDAD)
  • 17. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  El diseño de la arquitectura de software es una fase muy importante en el ciclo de vida del software. Es absolutamente necesario desempeñar é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.  Una arquitectura de software se selecciona y diseña con base en objetivos y restricciones. Los objetivos son aquellos prefijados para el sistema de información, pero no solamente los de tipo funcional, también otros objetivos como la mantenibilidad, auditabilidad, flexibilidad e interacción con otros sistemas de información.
  • 18. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  Las restricciones son aquellas limitaciones derivadas de las tecnologías disponibles para implementar sistemas de información. Unas arquitecturas son más recomendables de implementar con ciertas tecnologías mientras que otras tecnologías no son aptas para determinadas arquitecturas. Por ejemplo, no es viable emplear una arquitectura de software de tres capas para implementar sistemas en tiempo real.
  • 19. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  En toda tarea humana, podemos encontrar una serie de patrones que se repiten. Incluso en las bellas artes, actividad representativa de la creatividad humana, podemos hallar características comunes que nos permiten clasificar las obras en distintos movimientos artísticos. Y cómo no, en el arte de la programación no iba a ser menos.
  • 20. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  Era de esperar, por tanto, que alguien se animara tarde o temprano a estudiar los distintos patrones que pueden encontrarse en la inmensa mayoría del software, de forma que los problemas solucionados por estos quedasen perfectamente clasificados junto con su solución, para que así no fuese necesario reinventar la rueda cada vez que un programador se enfrentase a un obstáculo similar al descrito en uno de estos patrones. Nacieron así los patrones de diseño de sistemas software.
  • 21. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  Un patrón de diseño debe cumplir al menos dos requisitos para considerarse como tal: Debe ser efectivo, de modo que se haya podido comprobar su éxito resolviendo problemas anteriores; y debe ser reutilizable, es decir, podemos aplicarlo a problemas que se hallan en circunstancias similares a las descritas por el patrón.
  • 22. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  Imagina cuán sencillo sería poder comentar un problema de diseño con un compañero, y poder decirle algo tan sencillo como: “Esto es un patrón adapter”; siendo este breve comentario suficiente como para que tu interlocutor te entendiese perfectamente y sepa cómo hay que resolver el problema al que te enfrentas.
  • 23. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  Reusabilidad – Cada fragmento de software debe ser lo más reutilizable posible (a menos que sea aplicativo), y reutilizar otros componentes lo mayor posible.  Cuando desarrollas software, el factor de reusabilidad es crucial, especialmente cuanto tienes plazos que cumplir. Divide tu código en varias librerías 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 están involucrados.
  • 24. ARQUITECTURA, PATRONES DE DISEÑO Y REÚSO  Si solamente tienes un proyecto, aún así deberías reutilizar. Deberías separar código reutilizable en una librería lo que te permitirá simplificar aún más el código a mantener.
  • 25. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  DISEÑO ORIENTADO A FUNCIONES (ESTRUCTURADO)  El diseño estructurado se utiliza generalmente después de un análisis estructurado, cuyo producto es el diagrama de flujo de datos y las descripciones de procesos. Los investigadores han propuesto diversas estrategias y heurísticas, como por ejemplo fan-in/fan-out, para transformar un DFD en una arquitectura de software en general representada como una estructura chart.
  • 26. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  Como un método de diseño, ésta es realmente una combinación de dos técnicas diferentes, interrelacionadas. La primera es el Análisis de Sistemas Estructurados(SSA), que se ocupa de la construcción de un modelo del problema mediante el uso de Diagramas de Flujo de Datos (DFD). La segunda es el diseño estructurado (SD), que a su vez se orienta hacia los aspectos relacionados con la búsqueda de soluciones (diseño detallado) mediante el uso de la estructura chart.
  • 27. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  DISEÑO ORIENTADO A OBJETOS  Existen numerosos métodos de diseño de software basado en objetos que han sido propuestos desde la década de 1980. De manera informal, de acuerdo a su elaboración, se los ubica en tres generaciones (Budgen, 2003):  •Métodos de primera generación: Desarrollados en la década de 1970 y principios de 1980, estos métodos tienen una tendencia evolutiva. Se caracterizan por tener formas limitadas de notación diagramática y procesos débiles.
  • 28. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  Este método no ofrece una forma eficaz para el uso de la propiedad de herencia y el concepto de jerarquía de clases. Sin embargo, se limita exclusivamente a las características de objetos como: la modularidad, el encapsulamiento y la abstracción.
  • 29. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  •Métodos de segunda generación: Desarrollados a mediados de la década de 1990, estos métodos son considerados revolucionarios. El método Fusión desarrollado en 1994 integra y amplia los elementos de mayor éxito de las prácticas existentes hasta ese entonces. Al igual que HOOD, Fusión emplea una combinación de texto y diagramas, aunque la proporción de diagramas es mucho mayor. Fusión cuenta con un diagrama de clase (Denominado el modelo de objetos) que trata de proporcionar un punto de vista de la construcción de un sistema. Mientras que el modelado del comportamiento de clase hace uso de descripciones textuales.
  • 30. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  El Proceso Unificado: Surgió en la década de 1990 como resultado de unir las ideas y enfoques empleados por Booch, Jacobson y Rumbaugh. Se relaciona estrechamente con el desarrollo en paralelo de UML.
  • 31. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  DISEÑO BASADO EN COMPONENTES  Un componente de software es una unidad independiente, que posee interfaces bien definidas y dependencias que pueden ser construidas e implementadas de forma separada. El diseño basado en componentes busca proveer, desarrollar e integrar dichos componentes (Budgen, 2003).  Una de las principales razones para optar por este diseño es promover la reutilización, la misma que permite reducir los costos de elaboración del producto final (Budgen, 2003). Existen dos características que se deben tomar en cuenta para la reutilización:
  • 32. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  Funcionalidad bien definida, para facilitar la identificación de los componentes útiles, que satisfagan los requerimientos.  Los componentes deben tener interfaces bien definidas que permitan su interrelación.  Sin embargo, existen varios problemas relacionados al diseño utilizando componentes:
  • 33. ESTRATEGIAS DE DISEÑO: ORIENTADA A FUNCIONES, A OBJETOS, A COMPONENTES, A ESTRUCTURA DE DATOS, A ASPECTOS  Búsqueda del Componente: es una tarea complicada encontrar un componente que satisfaga la funcionalidad indicada para un sistema. Es necesario identificar claramente las necesidades generales del problema, para luego buscar un conjunto de componentes que colectivamente resuelvan estas necesidades.  Integración de componentes: pueden darse casos en los cuales el conjunto de componentes no logra satisfacer la funcionalidad requerida. De igual forma, existe la posibilidad de que dos o más componentes brinden la misma funcionalidad. Incluso, existe la posibilidad de una incompatibilidad arquitectónica entre componentes.