UNIVERSIDAD TECNOLÓGICA DE CHETUMAL

Carrera: Tecnología de la información

Cuatrimestre: 2

Grupo: A

TRABAJO PRESENTADO EN CUMPLIMIENTO A LA ASIGNATURA:

Metodologías y modelado de desarrollo de software

Alumno: Edgar David Peech Chan

DOCENTE:
MTI. WILLIAM ROBERTO SÁNCHEZ FERNÁNDEZ

Aula: 2

CHETUMAL, QUINTANA ROO A 24 DE ENERO DEL 2020

CICLO ESCOLAR
2019-2020

pág. 1
Índice

Tabla de contenido
TIPOS DE ARQUITECTURA DE SOFTWARE................................................................................. 3
DIAGRAMA UML.................................................................................................................................. 4
Conclusión............................................................................................................................................ 7

pág. 2
TIPOS DE ARQUITECTURA DE SOFTWARE
La arquitectura de software es el proceso por el cual se define una solución para
los requisitos técnicos y operacionales del mismo. Este proceso define qué
componentes forman el software, cómo se relacionan entre ellos, y cómo mediante
su interacción llevan a cabo la funcionalidad especificada, cumpliendo con los
criterios previamente establecidos; como seguridad, disponibilidad, eficiencia o
usabilidad y es por eso que tenemos diferentes tipos de arquitectura de software, y
hablaremos sobre 6 tipos de arquitectura de software. El primero es SOA, ya que
este es un estándar del sector de definición abierta que presenta todos los
procesos de negocio de un modo orientado a servicios. Las dependencias entre
servicios, tales como servicios web, activos de servicio EIS ( Enterprise
Information System ), flujos de trabajo y bases de datos se minimizan y se oculta
la implementación de cualquier servicio. El objetivo de la arquitectura orientada a
servicios es separar la lógica de integración de negocio de la implementación,
para que el desarrollador de integración pueda centrarse en ensamblar una
aplicación integrada en lugar de hacerlo en los detalles resultado es una
arquitectura de tres capas : lógica de integración de negocio, componentes
enfoque tradicional y monolítico de las aplicaciones, en el que todo se compila en
una sola Este enfoque de desarrollo de software valora el nivel de detalle, la
sencillez fundamental de la optimización del desarrollo de aplicaciones hacia un
modelo nativo de la El tercero es Cliente - Servidor, es un modelo de diseño de
software en el que las sobre una sola computadora, aunque es más ventajosa en
un sistema operativo multiusuario distribuido a través de una red de
computadoras. aplicaciones computacionales que usen el modelo cliente - servidor
son el Correo electrónico, un Servidor de impresión y la World Wide Web. un
modelo en el cual el sistema operativo y todos los servicios fundamentales residen
en un monitor monolítico que se accede a través de un mecanismo de llamada al
núcleo. quinto es Distribuido, que es un sistema en el que el procesamiento de
información se ultima es la de Capa, es un tipo de arquitectura usada en la gran
mayoría de sistemas. suele usar en sistemas que implementan un modelo de
negocio como podría ser una tienda online, una aplicación para gestionar ciertos
datos, etc. Sin embargo, no es recomendable Todo sistema que gestiona datos
tendrá una base de datos para guardar esos datos y una interfaz de usuario,
Además, una parte del sistema se encargará de procesar los datos y gestionar lo
que se hace con ellos. La arquitectura en tres capas lo que hace es dividir el

pág. 3
sistema en tres partes diferenciadas, de tal forma que cada capa solo Esas tres
capas se denominan: Persistencia: Esta capa se Negoció : En esta capa se
gestiona la tener un usuario, que ocurre si un usuario se retrasa al devolver un
libro, etc. Estará conectada con la capa de persistencia para poder realizar sus
funciones y Presentación: En esta capa se crea la interfaz del usuario. realice el
usuario a la capa de negocio. Al hacer que cada capa se comunique solo con la
inmediatamente inferior, conseguimos que si hay que realizar un cambio no nos
volvamos locos tocando todo el sistema.

DIAGRAMA UML
El lenguaje unificado de modelado mas conocido por su singlas UML es un
estándar OMG (Grupo de Gestión de objetos) diseñado para visualizar,
especificar, construir y documentar software orientado a objetos. UML prescribe un
conjunto de notaciones y diagramas estándar para modelar sistemas orientados a
objetos, y describe la semántica esencial de lo que estos diagramas y símbolos
significan. UML se puede usar para modelar distintos tipos de sistemas como, por
ejemplo: sistemas de software, sistemas de hardware, y organizaciones del mundo
real. UML ofrece nueve diagramas en los cuales modelar sistemas. Es un lenguaje
muy expresivo, que cubre todas las vistas necesarias para desarrollar y luego
desplegar tales sistemas, además que el UML estandariza 9 tipos de diagramas
para representar gráficamente un sistema desde distintos puntos de vista. El
primer diagrama UML es de Clases y sirve para describir los tipos de objetos de
un sistema, así como los distintos tipos de relaciones que pueden existir entre
ellos. Los diagramas de clase se convierten así en la técnica más potente para el
modelado conceptual de un sistema software, la cual suele recoger los conceptos
clave del modelo de objetos subyacente al método orientado a objetos que la
incorpora y su propósito es describir las clases que conforman el modelo de un
determinado sistema. Dado el carácter de refinamiento iterativo que caracteriza un
desarrollo orientado a objetos, el diagrama de clase va a ser creado y refinado
durante las fases de análisis y diseño, estando presente como guía en la
implementación del Sistema. Se puede decir que existen tres perspectivas
diferentes desde las cuales se pueden utilizar los diagramas de clase: la primera
es Conceptual: El diagrama de clase representa los conceptos en el dominio del
problema que se está estudiando. Este modelo debe crearse con la mayor
independencia posible de la implementación final del sistema. El segundo es
Especificación: El diagrama de clase refleja las interfaces de las clases, pero no su
implementación. Aquí las clases aparecen más cercanas a los tipos de datos, ya
que un tipo representa una interfaz que puede tener muchas implementaciones
diferentes, y por último es la Implementación: Esta vista Página 5 de 9 representa
las clases tal cual aparecen en el entorno de implementación. El segundo
diagrama UML es de Objetos y están vinculados con los Diagramas de Clases. Un
objeto es una instancia de una clase, por lo que un diagrama de objetos puede ser

pág. 4
visto como una instancia de un diagrama de clases. Los diagramas de objetos
describen la estructura estática de un sistema en un momento particular y son
usados para probar la precisión de los diagramas de clases, también se puede
considerar un caso especial de un diagrama de clase. Los diagramas de objetos
usan un sub conjunto de elementos de un diagrama de clase para enfatizar la
relación entre las instancias de las clases en algún punto en el tiempo. Estos son
útiles para entender los diagramas de clases. Estos no muestran nada diferente en
su arquitectura a los diagramas de secuencia, pero reflejan multiplicidad y roles. El
tercer diagrama UML es de Casos de uso y esta captura la funcionalidad de un
sistema, de un subsistema, o de una clase, tal como se muestra a un usuario
exterior. Reparte la funcionalidad del sistema en transacciones significativas para
los usuarios de un sistema Los usuarios del sistema se denominan actores y las
particiones funcionales se conocen con el nombre de casos de uso La técnica que
se utiliza para modelar esta vista es el diagrama de casos de uso y modela la
funcionalidad del sistema tal como la perciben los agentes externos, denominados
actores, que interactúan con el sistema desde un punto de vista particular. Sus
componentes principales son: Sujeto: Sistema que modela, Casos de uso:
unidades funcionales completas y Actores: entidades externas que interactúan con
el sistema. El cuarto diagrama UML es de Secuencia y permite modelar la
secuencia de interacciones entre los distintos objetos para lograr alguna tarea ya
sea un escenario de un caso de uso, la lógica de un método o la lógica de un
servicio y muestra la interacción de un conjunto de objetos de una aplicación a
través del tiempo, en el cual se indicaran los módulos o clases que formaran parte
del programa y las llamadas que se hacen cada uno de ellos para realizar una
tarea determinada, por esta razón permite observar la perspectiva cronológica de
las interacciones. Es importante recordar que el diagrama de secuencias se
realiza a partir de la descripción de un caso de uso y tenemos elementos del
diagrama de secuencias, como: El rol de la clase describe la manera en que un
objeto se va a comportar en el contexto. No se listan los atributos del objeto, La
activación describe los cuadros de activación que representan el tiempo que un
objeto necesita para completar una tarea, Los mensajes son flechas que
representan comunicaciones entre objetos, Las medias flechas representan
mensajes asincrónicos, Los mensajes asincrónicos son enviados desde un objeto
que no va a esperar una respuesta del receptor para continuar con sus tareas, Las
líneas de vida son verticales y en línea de puntos, ellas indican la presencia del
objeto durante el tiempo, Los objetos pueden ser eliminados tempranamente
usando una flecha etiquetada “<>” que apunta a una X, Una repetición o loop en
un diagrama de secuencias, es representado como un rectángulo. La condición
para abandonar el loop se coloca en la parte inferior entre corchetes [ ]. El quinto
diagrama UML es de Estados y esté muestra la secuencia de estados por los que
pasa bien un caso de uso, un objeto a lo largo de su vida, o bien todo el sistema,
ya que indica qué eventos hacen que se pase de un estado a otro y cuáles son las
respuestas y acciones que genera. También ilustra qué eventos pueden cambiar
pág. 5
el estado de los objetos de la clase. En cuanto a la representación, un diagrama
de estados es un grafo cuyos nodos son estados y cuyos arcos dirigidos son
transiciones etiquetadas con los nombres de los eventos. Normalmente contienen:
estados y Página 6 de 9 transiciones. Como los estados y las transiciones
incluyen, a su vez, eventos, acciones y actividades. Al igual que otros diagramas,
en los diagramas de estado pueden aparecer notas explicativas y restricciones. El
sexto diagrama UML es de Actividades y permiten describir como un sistema
implementa su funcionalidad, además de como modelan el comportamiento
dinámico de un procedimiento, transacción o caso de uso haciendo énfasis en el
proceso que se lleva a cabo y es uno de los elementos de modelado que son
mejor comprendidos por todos, ya que son herederos directos de los diagramas de
flujo. El séptimo diagrama UML es de Colaboración y tiene como objetivo describir
el comportamiento dinámico del sistema de información mostrando como
interactúan los objetos entre sí, es decir, con qué otros objetos tiene vínculos o
intercambia mensajes un determinado objeto, además que muestra la misma
información que un diagrama de secuencia, pero de forma diferente. En los
diagramas de colaboración no existe una secuencia temporal en el eje vertical; es
decir, la colocación de los mensajes en el diagrama no indica cual es el orden en
el que se suceden. Además, la colocación de los objetos es más flexible y permite
mostrar de forma más clara cuales son las colaboraciones entre ellos. En estos
diagramas la comunicación entre objetos se denomina vinculo o enlace (link) y
estará́ particularizada mediante los mensajes que intercambian. El octavo
diagrama UML es de Componentes y está clasificado como diagrama de
estructura y, como tal, representa de forma estática el sistema de información.
Habitualmente se utiliza después de haber creado el diagrama de clases, pues
necesita información de este diagrama como pueden ser las propias clases,
además que este diagrama proporciona una vista de alto nivel de los componentes
dentro de un sistema. Los componentes pueden ser un componente de software,
como una base de datos o una interfaz de usuario; o un componente de hardware
como un circuito, microchip o dispositivo; o una unidad de negocio como un
proveedor, nómina o envío, algunos usos de este tipo de diagrama es el siguiente:
Se utilizan en desarrollo basado en componentes para describir sistemas con
arquitectura orientada a servicios. Mostrar la estructura del propio código, Se
puede utilizar para centrarse en la relación entre los componentes mientras se
ocultan los detalles de las especificaciones, Ayudar a comunicar y explicar las
funciones del sistema que se está construyendo a los interesados, Se utilizan en
desarrollo basado en componentes para describir sistemas con arquitectura
orientada a servicios. Mostrar la estructura del propio código, Se puede utilizar
para centrarse en la relación entre los componentes mientras se ocultan los
detalles de las especificaciones y Ayudar a comunicar y explicar las funciones del
sistema que se está construyendo a los interesados. El ultimo diagrama de UML
es de Despliegue y es un tipo de diagrama de UML que se utiliza para modelar el
hardware utilizado en las implementaciones de sistemas y las relaciones entre sus
pág. 6
componentes. Muestra las relaciones físicas entre los componentes hardware y
software en el sistema final, es decir, la configuración de los elementos de
procesamiento en tiempo de ejecución y los componentes software (procesos y
objetos que se ejecuten en ellos), además que describen la arquitectura física del
sistema durante la ejecución, en términos de: Procesadores, Dispositivos y
Componentes de software. En el diagrama de distribución es donde
representamos la estructura de hardware donde estará nuestro sistema o
software, para ello cada componente lo podemos representar como nodos, el nodo
es cualquier elemento que sea un recurso de hardware, es decir, es nuestra
denominación genérica para Página 7 de 9 nuestros equipos. Dentro de la
clasificación de los nodos tenemos que hay el nodo que puede ejecutar o procesar
y el nodo que no ejecuta ni procesa, estos últimos pueden ser los dispositivos de
salida como impresoras o monitores, es decir, los que están en contacto con el
exterior y para representar al nodo utilizaremos la figura del cubo, dentro de
nuestro cubo podemos escribir la información correspondiente al nodo, por
ejemplo, su nombre.

Conclusión
El lenguaje Unificado de modelado UML es una notación que es el resultado de la
evolución de las notaciones previas en ingeniería de software, toma los aspectos
fuertes de tres metodologías anteriores: OMT, Booch y OOSE. La notación UML
se fundamenta en principios de modelado, lo cual es importante para toda
implementación de un sistema de información. El UML debe adoptar el Proceso
Unificado de Desarrollo para modelar las actividades de un proyecto. Los
diagramas a utilizar en las diferentes etapas del desarrollo de los sistemas de
información, pueden variar dependiendo del tamaño y tipo de sistema, por lo que
es necesario organizarlos según las fases del Proceso Unificado.
Como se mencionó anteriormente los diagramas de clases representan
información estática de sistema, pero ya en un sistema funcional, los objetos
interactúan entre sí con el tiempo, esto se puede representar mediante un
diagrama de secuencias.
El objetivo de UML es ser capaz de describir el comportamiento de un sistema,
subsistema u operación particular mediante un diagrama de secuencia el cual
muestra la interacción de un conjunto de objetos en una aplicación a través del
tiempo y se modela para cada caso de uso, esto facilita como se distribuyen las
tareas entre los componentes.

pág. 7