Documentos de Académico
Documentos de Profesional
Documentos de Cultura
Desarrollo SW Arquitectura2
Desarrollo SW Arquitectura2
q=arquitectura+de+software+de+acuerdo+al+patr%C3%B3n+de+dise%C3%B1o&tbm=isch&ved=2ahUKEwi2uKzFmtb5AhWlioQIHUTQDXYQ2-
cCegQIABAA&oq=arquitectura+de+software+de+acuerdo+al+patr%C3%B3n+de+dise%C3%B1o&gs_lcp=CgNpbWcQA1DfDlitY2DtbmgAcAB4AIAB6hiIAaSWAZIBDTMtMS42LTEuMy4wLjWYAQCgAQGqAQtnd3Mtd2l6LWltZ8ABAQ&sclien
t=img&ei=PD0BY7aqOaWVkvQPxKC3sAc&rlz=1C1UEAD_esCO976CO976#imgrc=x44fJccYCRwXrM
seleccionado
Los patrones de diseño o design patterns, son una solución general, reutilizable y
aplicable a diferentes problemas de diseño de software.
Se trata de plantillas que identifican problemas en el sistema y proporcionan
soluciones apropiadas a problemas generales a los que se han enfrentado los
desarrolladores durante un largo periodo de tiempo, a través de prueba y error.
Concluciones.
Antes se requería completar todo el software antes de realizar pruebas, lo que suponía
encontrarse con problemas.
Para ahorrar tiempo y evitar volver a la etapa de desarrollo una vez que este ha
finalizado, se introdujo una práctica de prueba durante la fase de desarrollo.
Esta práctica se usa para identificar condiciones de error y problemas en el código
que pueden no ser evidentes en ese momento.
En definitiva, los patrones de diseño te ayudan a estar seguro de la validez de tu
código, ya que son soluciones que funcionan y han sido probados por muchísimos
desarrolladores siendo menos propensos a errores.
PÁGINA 1
Tipos de patrones de diseño de sotware:
Patrones creacionales
Patrones estructurales
Patrones de comportamiento
PÁGINA 2
Patrones creacionales:
1. Abstract Factory
En este patrón, una interfaz crea conjuntos o familias de objetos relacionados sin
especificar el nombre de la clase.
2. Builder Patterns
Permite producir diferentes tipos y representaciones de un objeto utilizando el mismo
código de construcción.
Se utiliza para la creación etapa por etapa de un objeto complejo combinando objetos
simples.
La creación final de objetos depende de las etapas del proceso creativo, pero es
independiente de otros objetos.
3. Factory Method
Proporciona una interfaz para crear objetos en una superclase, pero permite que las
subclases alteren el tipo de objetos que se crearán.
Proporciona instanciación de objetos implícita a través de interfaces comunes
4. Prototype
Permite copiar objetos existentes sin hacer que su código dependa de sus clases.
Se utiliza para restringir las operaciones de memoria / base de datos manteniendo la
modificación al mínimo utilizando copias de objetos.
5. Singleton
Este patrón de diseño restringe la creación de instancias de una clase a un único
objeto.
PÁGINA 3
Patrones estructurales:
1. Adapter
Se utiliza para vincular dos interfaces que no son compatibles y utilizan sus
funcionalidades.
El adaptador permite que las clases trabajen juntas de otra manera que no podrían al
ser interfaces incompatibles.
2. Bridge
En este patrón hay una alteración estructural en las clases principales y de
implementador de interfaz sin tener ningún efecto entre ellas.
Estas dos clases pueden desarrollarse de manera independiente y solo se conectan
utilizando una interfaz como puente.
3. Composite
Se usa para agrupar objetos como un solo objeto.
Permite componer objetos en estructuras de árbol y luego trabajar con estas
estructuras como si fueran objetos individuales.
4. Decorator
Este patrón restringe la alteración de la estructura del objeto mientras se le agrega
una nueva funcionalidad.
La clase inicial permanece inalterada mientras que una clase decorator proporciona
capacidades adicionales.
5. Facade
Proporciona una interfaz simplificada para una biblioteca, un marco o cualquier otro
conjunto complejo de clases.
6. Flyweight
El patrón Flyweight se usa para reducir el uso de memoria y mejorar el rendimiento al
reducir la creación de objetos.
El patrón busca objetos similares que ya existen para reutilizarlo en lugar de crear
otros nuevos que sean similares.
7. Proxy
Se utiliza para crear objetos que pueden representar funciones de otras clases u
objetos y la interfaz se utiliza para acceder a estas funcionalidades.
PÁGINA 4
Patrones de comportamiento:
1. Chain of responsibility
El patrón de diseño Chain of Responsibility es un patrón de comportamiento que evita
acoplar el emisor de una petición a su receptor dando a más de un objeto la posibilidad
de responder a una petición.
2. Command
Convierte una solicitud en un objeto independiente que contiene toda la información
sobre la solicitud.
Esta transformación permite parametrizar métodos con diferentes solicitudes, retrasar
o poner en cola la ejecución de una solicitud y respaldar operaciones que no se
pueden deshacer.
3. Interpreter
Se utiliza para evaluar el lenguaje o la expresión al crear una interfaz que indique el
contexto para la interpretación.
4. Iterator
Su utilidad es proporcionar acceso secuencial a un número de elementos presentes
dentro de un objeto de colección sin realizar ningún intercambio de información
relevante.
5. Mediator
Este patrón proporciona una comunicación fácil a través de su clase que permite la
comunicación para varias clases.
6. Memento
El patrón Memento permite recorrer elementos de una colección sin exponer su
representación subyacente.
7. Observer
Permite definir un mecanismo de suscripción para notificar a varios objetos sobre
cualquier evento que le suceda al objeto que está siendo observado.
8. State
En el patrón state, el comportamiento de una clase varía con su estado y, por lo tanto,
está representado por el objeto de contexto.
9. Strategy
Permite definir una familia de algoritmos, poner cada uno de ellos en una clase
separada y hacer que sus objetos sean intercambiables.
PÁGINA 5
10. Template method
Se usa con componentes que tienen similitud donde se puede implementar una
plantilla del código para probar ambos componentes.
El código se puede cambiar con pequeñas modificaciones.
11. Visitor
El propósito de un patrón Visitor es definir una nueva operación sin introducir las
modificaciones a una estructura de objeto existente.
PÁGINA 6
Elaborar la vista de componentes para visualizar el software en fases avanzadas
del ciclo de vida.
Veremos:
El ciclo de vida permite iniciar una serie de fases mediante las cuales se procede a la
validación y al desarrollo del software garantizando que se cumplan los requisitos para
la aplicación y verificación de los procedimientos del desarrollo como tal.
PÁGINA 7
Desde un punto de vista conceptual, las actividades son de cinco clases:
http://yuglenisdelcarmen.blogspot.com/p/fases-de-la-ingenieria-de-requisitos.html
PÁGINA 8
Paradigmas de los modelos de ciclo de vida del software:
Un modelo de ciclo de vida de software es una vista de las actividades que ocurren
durante el desarrollo de software e intenta determinar el orden de las etapas
involucradas y los criterios de transición asociados entre estas.
Según la norma 1074 IEEE se define al ciclo de vida del software como:
Un marco de referencia que contiene los procesos, las actividades y las tareas
involucradas en el desarrollo, la explotación y el mantenimiento de un producto de
software, abarcando la vida del sistema desde la definición de los requisitos hasta la
finalización de su uso (2008).
Paradigma tradicional.
Los paradigmas tradicionales se identifican, fundamentalmente, por ser lineales, es
decir se trata de completar cada proceso de principio a fin hasta que quede listo para
avanzar a la segunda fase del ciclo del software.
PÁGINA 9
Modelos de paradigmas más utilizados:
Modelo en cascada:
Uno de los primeros modelos de ciclo de vida del desarrollo fue establecido por W.
Royce en 1970 y es conocido como el “modelo de cascada” (waterfall model).
En el modelo de ciclo de vida en cascada las fases anteriores funcionarán una detrás
de la otra de manera lineal. De este modo, solo cuando una fase termine se podrá
continuar con la siguiente, y así progresivamente.
https://www.google.com/search?q=Modelo+en+cascada&rlz=1C1UEAD_esCO976CO976&sxsrf=AOaemvLSiVGcjaXx1qUGhxqPjcQvMl9JYg:1640446763807&source=lnms&tbm=isch&sa=X&sqi=2&ved=2ahUKEwjJ-
4O1pP_0AhXir5UCHXumC0MQ_AUoAXoECAIQAw&biw=1139&bih=497&dpr=1.2
Modelo espiral:
Fue diseñado por Boehm en el año 1988 y se basa en una serie de ciclos repetitivos
para ir ganando madurez en el producto final.
El espiral se repite las veces que sea necesario hasta que el cliente o el usuario
obtenga la satisfacción de sus necesidades.
El modelo en espiral es una combinación de los modelos anteriores donde se tiene en
cuenta el riesgo.
De esta forma, se comienza fijando los objetivos y las limitaciones al empezar cada
repetición.
En la etapa siguiente se crean los modelos de prototipo del software, que incluye el
análisis de riesgo.
Posteriormente se usa un modelo estándar para construir el software y finalmente se
prepara el plan de la próxima repetición.
https://intelequia.com/blog/post/2083/ciclo-de-vida-del-software-todo-lo-que-necesitas-saber
https://www.google.com/search?q=modelo+en+espiral&tbm=isch&ved=2ahUKEwjsgLm2pP_0AhVBFt8KHSUmD88Q2-
cCegQIABAA&oq=Modelo+en+&gs_lcp=CgNpbWcQARgCMgcIIxDvAxAnMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBQgAEIAEMgUIABCABDIFCAAQgAQyBAgAEENQjQdYlhFg8CVoAHAAeACAAekBiAHFC
JIBBTAuNy4xmAEAoAEBqgELZ3dzLXdpei1pbWfAAQE&sclient=img&ei=LjvHYeyxLsGs_AalzLz4DA&bih=497&biw=1139&rlz=1C1UEAD_esCO976CO976#imgrc =3Z4bSJL1pmPzQM
PÁGINA 10
Modelo iterativo o por prototipos:
Objetivos:
A
Son un medio eficaz para aclarar los requisitos de los usuarios e identificar las
características de un sistema que debe cambiarse o añadirse.
B
Mediante el prototipo se puede verificar la viabilidad del diseño de un sistema.
https://www.google.com/search?q=Modelo+iterativo+o+por+prototipos&rlz=1C1UEAD_esCO976CO976&hl=es-419&sxsrf=AOaemvIhFPGVJ_k0IbpBmVSU4Xn1w-
7vPw:1640448612316&source=lnms&tbm=isch&sa=X&ved=2ahUKEwi-nbymq__0AhUvQzABHTHvC-0Q_AUoAXoECAEQAw&biw=1139&bih=497&dpr=1.2
Es un modelo derivado del ciclo de vida en cascada. Este modelo busca reducir el
riesgo que surge entre las necesidades del usuario y el producto final por malos
entendidos durante la etapa de recogida de requisitos.
PÁGINA 11
Las etapas del modelo iterativo o por prototipos:
2 diseño rápido.
Diseño técnico.
Programación y test.
Operación y mantenimiento.
6 producto de ingeniería.
(con respecto a los modelos del ciclo de vida del paradigma ágil, estos se caracterizan
por estar basados en etapas del ciclo de vida del software tradicional, pero
combinándolas con algunas técnicas, al respecto se pueden revisar los siguientes)
Modelo Scrum:
Este modelo se basa en el desarrollo incremental, es decir conforme pasen las fases
y la iteración mayor será el tamaño del proyecto que se está desarrollando.
La metodología Scrum es un proceso para llevar a cabo un conjunto de tareas de
forma regular con el objetivo principal de trabajar de manera colaborativa, es decir,
para fomentar el trabajo en equipo.
Con este método de trabajo lo que se pretende es alcanzar el mejor resultado de un
proyecto determinado.
Las prácticas que se aplican con la metodología Scrum se retroalimentan unas con
otras y la integración de las mismas tiene su origen en un estudio de cómo hay que
coordinar a los equipos para ser potencialmente competitivos.
En Scrum se van realizando entregas regulares y parciales del trabajo final, de manera
prioritaria y en función del beneficio que aportan dichas entregas a los receptores del
proyecto.
Por este motivo, es una metodología especialmente indicada para proyectos
complejos, con requisitos cambiantes y en los que la innovación y la flexibilidad son
protagonistas.
https://www.apd.es/metodologia-scrum-que-es/
PÁGINA 12
El Scrum consiste en realizar un análisis de los requerimientos del sistema (Product
Backlog), señalar cuáles serán los objetivos a corto o mediano plazo dentro de un
sprint, o sea, la fase de desarrollo. Posteriorme
https://www.google.com/search?q=Modelo+Scrum&rlz=1C1UEAD_esCO976CO976&sxsrf=AOaemvIuLBO6_BUf98rs99dVS39qBX4YHg:1640467836111& source=lnms&tbm=isch&sa=X&sqi=2&ved=2ahUKEwiUzIv18v_0AhWbAogKH
avwDVMQ_AUoAXoECAEQAw&biw=1139&bih=497&dpr=1.2#imgrc=B0VmLys_mt_RiM
Modelo Kanban:
PÁGINA 13
Mediante la metodología japonesa:
https://www.google.com/search?q=Modelo+Kanban&tbm=isch&ved=2ahUKEwjF3sO59v_0AhUqSN8KHWrLCS8Q2-
cCegQIABAA&oq=Modelo+Kanban&gs_lcp=CgNpbWcQAzIFCAAQgAQyBQgAEIAEMgYIABAIEB4yBggAEAgQHjIGCAAQCBAeMgQIABAYMgQIABAYMgQIABAYMgQIABAYMgQIABAYOgcIIxDvAxAnOgYIABAHEB46BggAEAUQHK
CCMQ7wMQ6gIQJ1DnCljsyQFgp9cBaANwAHgIgAGfAogBpBSSAQUwLjYuN5gBAKABAaoBC2d3cy13aXotaW1nsAEKwAEB&sclient=img&ei=MJHHYcWGOaqQ_Qbqlqf4Ag&bih=497&biw=1139&rlz=1C1UEAD_esCO976CO976#img
rc=bmNVGBM1R7du-M
Es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer
libro sobre este tema: Extreme Programming Explained: Embrace Change (1999).
https://www.google.com/search?q=Modelo+XP+o+programaci%C3%B3n+extrema&rlz=1C1UEAD_esCO976CO976&hl=es-
419&sxsrf=AOaemvKbfonbSw3tzEgT0wPQ3EjQAPEEqA:1640471411187&source=lnms&tbm=isch&sa=X&ved=2ahUKEwiGkOmdgID1AhV3SjABHROWBUwQ_AUoAXoECAEQAw&biw=1139&bih=497&dpr=1.2#imgrc=3OfLMvA_SFq
usM
PÁGINA 14
Características principales de la programación extrema:
Requisitos:
PÁGINA 15
Importancia de los requisitos:
las características que los requisitos deben cumplir de acuerdo con Pfleeger
(2002) son:
Necesario:
Si se tiene alguna duda acerca de la necesidad del requerimiento, se puede
preguntar “¿Qué sería lo peor de no incluirlo?”. Si no se encuentra una respuesta o
cualquier consecuencia, entonces es probable que no sea un requerimiento
necesario.
Completo:
Un requerimiento está completo si no necesita ampliar detalles en su redacción, es
decir, si se proporciona la información suficiente para su comprensión.
Consistente:
Un requerimiento es consistente si no es contradictorio con otro requerimiento.
Correcto:
Acuerdo entre dos partes. Contiene una sola idea.
Factible:
El requerimiento deberá de ser totalmente factible y dentro de presupuesto, calendario
y otras restricciones, si se tiene alguna duda de su factibilidad, hay que investigar,
generar pruebas de concepto para saber su complejidad y factibilidad, si aun así el
requerimiento es no factible, hay que revisar la visión del sistema y replantear el
requerimiento.
Modificable:
Los cambios en los requisitos deben hacerse de manera sistemática, y debe tenerse
en cuenta su impacto en otros requisitos.
Priorizado:
Categorizar el requerimiento nos ayuda a saber el grado de necesidad del mismo:
esencial/crítico, deseado, opcional verificable.
PÁGINA 16
Verificable:
Si un requerimiento no se puede comprobar, entonces, ¿cómo se sabe si se cumplió
con él o no? Debe ser posible verificarlo ya sea por inspección, análisis de prueba o
demostración. Cuando se escriba un requerimiento, se deberán determinar los
criterios de aceptación.
Rastreable:
La especificación se debe organizar de tal forma que cada función del sistema se
pueda rastrear hasta su conjunto de requerimientos correspondientes.
Facilita las pruebas y la validación del diseño.
Claro:
Un requerimiento es conciso si es fácil de leer y entender, su redacción debe ser
simple y clara para quienes lo consulten en un futuro.
Clasificación:
Requerimientos de usuario: Son declaraciones, en lenguaje natural y en
diagramas, de los servicios que se espera que el sistema proporcione y de las
restricciones bajo las cuales debe funcionar.
Requerimientos no funcionales:
Son restricciones de los servicios o funciones ofrecidos por el sistema.
Incluyen restricciones de tiempo, sobre el proceso de desarrollo y estándares.
Dentro de estos requerimientos encontramos todo lo referente a fiabilidad, el tiempo
de respuesta y la capacidad de almacenamiento.
funcionales y no funcionales
Funcionales No funcionales
Se debe ingresar cédula, nombre y teléfono de cada cliente. Las consultas deben resolverse en menos de 3 segundos.
Se requiere un listado de clientes por zona. El lenguaje de programación debe ser Java.
Diseño propio con énfasis en la plataforma e igual para que me sirva en futuras labores
PÁGINA 17
Ingeniería de requisitos:
https://www.google.com/search?q=Ingenier%C3%ADa+de+requisitos&rlz=1C1UEAD_esCO976CO976&sxsrf=AOaemvJiAhrFsw-
IKPf8TKNYNH7GXpB4Mg:1640534670636&source=lnms&tbm=isch&sa=X&ved=2ahUKEwj8raPy64H1AhXHTDABHZ4pBoYQ_AUoAXoECAIQAw
PÁGINA 18
Etapas de la ingeniería de requisitos:
Elicitación:
Actividad involucrada en el descubrimiento de los requisitos del sistema. Aquí
los analistas deben trabajar junto con el cliente para descubrir el problema que
el sistema debe resolver, los diferentes servicios que el sistema debe prestar
y las restricciones que se pueden presentar.
1. Conocer el dominio del problema, de forma tal que los analistas puedan
entenderse con los clientes y usuarios y sean capaces de transmitir
dicho conocimiento al resto del equipo.
2. Descubrir necesidades reales entre clientes y usuarios, haciendo
énfasis en aquellas, que la mayor parte de las veces se asumen y
toman por implícitas.
3. Consensuar los requisitos entre los propios clientes y usuarios hasta
obtener una visión común de los mismos.
Análisis:
Sobre la base de la obtención realizada previamente, comienza esta fase la
cual tiene como propósito descubrir problemas con los requisitos del sistema
identificados hasta el momento, para ello se basa en los siguientes objetivos:
1. Detectar conflicto en los requisitos que suelen provenir de distintas
fuentes y presentar contradicciones o ambigüedades debido a su
naturaleza informal.
2. Profundizar en el conocimiento del dominio del problema puede facilitar
el proceso de construir un producto útil para clientes y usuarios (Durán,
2000).
3. En esta fase, el analista proporciona un sistema de retroalimentación que
defina el entendimiento conseguido en la etapa de obtención.
Especificación:
Aquí se documentan los requisitos acordados con el cliente, en un nivel
apropiado de detalle.
En la práctica, esta etapa se realiza conjuntamente con el análisis, por lo que
se puede decir que la especificación es el “pasar en limpio” el análisis realizado
previamente aplicando técnicas y/o estándares de documentación, como la
notación UML (Lenguaje de Modelado Unificado), que es un estándar para el
modelado orientado a objetos, por lo que los casos de uso y la obtención de
requisitos basada en los casos de uso se utilizan cada vez más para la
obtención de requisitos.
PÁGINA 19
Elaborar la vista de despliegue del software.
PÁGINA 20
Bibliografia
https://profile.es/blog/patrones-de-diseno-de-software/
https://docplayer.es/9392809-Patrones-de-diseno-ejercicios.html
https://www.google.com/search?q=patrones+de+dise%C3%B1o&tbm=isch&hl=es-419&chips=q:patrones+de+dise%C3%B1o,online_chips:arquitectura:LaaYlD-
50mo%3D&sa=X&ved=2ahUKEwjPkpXKntj5AhWPNd8KHXTyBfcQ4lYoAHoECAEQJA&biw=1113&bih=493#imgrc=GJZH9_cpLfKEuM
https://www.google.com/search?q=Elaborar+la+vista+de+despliegue+del+software.&rlz=1C1UEAD_esCO976CO976&sxsrf=ALiCzsZTKtnybkWqxjCrvC1-x3u-
LmgulA:1661298599877&source=lnms&tbm=isch&sa=X&ved=2ahUKEwjEhaXHk975AhXBVTABHdh9CVsQ_AUoAXoECAEQAw&biw=1130&bih=493&dpr=1.21#imgrc=km2u6-Y18v0pTM
https://iveconsultores.com/diagrama-de-flujo/
PÁGINA 21