Arquitectura de software - contenido.elion.education · Realizar diseños de software que responden...

ArquitecturadeSoftware

Arquitectura de software Ingeniería Informática Facultad de Ingeniería y Ciencias Ambientales


Video Introductorio


Ruta de aprendizaje


Mapa conceptual


La arquitectura de software juega un papel fundamental dentro de las etapas de desarrollo de software, las decisiones críticas relativas al diseño general de un sistema de software complejo deben de hacerse desde un principio, no crear este diseño desde etapas tempranas del desarrollo puede limitar severamente el que el producto final satisfaga las necesidades de los clientes, independientemente de la metodología que se utilice, las actividades relacionadas con el desarrollo de la arquitectura de software generalmente forman parte de las actividades definidas dentro de las metodologías de desarrollo.

De igual manera, es importante tener en cuenta que el software hace cada vez más parte de nuestras vidas; y su relevancia juega cada vez un papel más crítico en la sociedad. Hoy en día no solamente se requiere que el software se entregue a los clientes dentro del tiempo pactado, sino que éste se caracterice por un conjunto de aspectos de calidad que garanticen la satisfacción de los clientes; y más significativo aún, que no ponga en riesgo el curso de un negocio o las personas que utilizan el software.

Es en el dominio de los aspectos de calidad donde la arquitectura y el diseño de software juegan el rol más importante. Desarrollar un software funcional no es una tarea compleja pero cuando éste debe incluir aspectos de alta disponibilidad, seguridad, rendimiento, confiabilidad, entre otros, es cuando se convierte en una tarea difícil y se puede convertir en imposible sino se aborda desde la arquitectura y el diseño de software.

Es fundamental la arquitectura de software, se considera vital realizar una rigurosa y disciplinada fase de diseño de software dentro de un proyecto con el fin de garantizar que el sistema de información cumpla con sus tareas funcionales de la forma más adecuada; al igual que dejarlo documentado para su posterior evolución.

Durante el curso ‘Arquitectura de Software, se van a presentar los fundamentos y conceptos más relevantes dentro del área del Diseño de Software; igualmente se van a presentar las técnicas utilizadas para modelar y documentar los productos de software, con el propósito que los estudiantes aprendan a aplicarlas dentro de un contexto real y adquieran habilidades de diseño de software de calidad.

El desarrollo del presente curso promueve el aprendizaje de tipo investigativo, recursivo, encaminado a la asimilación y ejecución práctica de los conocimientos y saberes adquiridos como posible solución a la situación problemática planteada. Se plantea la continua necesidad de exploración de fuentes y recursos, actualización y continua investigación dentro de cada uno de los ejes temáticos propuestos, toda vez que el presente curso se desarrolla en modalidad virtual, aparte que se considera la arquitectura de software como una actividad fundamental en el ciclo de vida del desarrollo de software. Se hace vital y necesaria la continua interacción, comunicación y complementación entre el tutor y el estudiante, mediante los comentarios, aportes, preguntas aprovechando las herramientas virtuales de comunicación, a fin de recibir la oportuna orientación y complementación dentro del desarrollo de la situación o caso propuesto. El estudiante es el centro del proceso y su disciplina y autoestudio se constituyen en factores fundamentales para esta modalidad educativa. Adicionalmente las herramientas de la plataforma ofrecen espacios para la presentación de los contenidos, la interacción, la entrega de evidencias y verificación de competencias alcanzadas.

Justificación

Metodología


Las actividades de aprendizaje propuestas, permiten dejar plasmada como evidencia real de adquisición de conocimientos y habilidades, y gracias a la implementación de trabajos aplicativos, foros de discusión, video tutoriales y tutorías sincrónicas.

La evaluación por competencias en la Católica del Norte se orienta por los siguientes principios:

1. Continua: no hay momentos específicos para la evaluación, se realiza durante todo el periodo y a través de las actividades programadas en los módulos.

2. Integral: se valoran el ser, el saber y el hacer; es decir, el ser humano en todas sus dimensiones.

3. Refuerzo permanente: está implícito en el desarrollo de las actividades, porque el mismo criterio de desempeño se puede valorar en diferentes momentos.

La evaluación de las competencias se realiza a partir de la entrega de las evidencias, éstas a su vez están planteadas como actividades y cada una cuenta con una serie de criterios que estandarizan la valoración de los resultados. Los criterios de desempeño definidos para cada elemento de la competencia, son la base para determinar los resultados de aprendizaje que se estructuran con base en EVIDENCIAS DE APRENDIZAJE que son las pruebas manifiestas de aprendizaje, recogidas directamente durante el proceso formativo. Son recolectadas con la orientación del facilitador, utilizando técnicas, métodos e instrumentos de evaluación seleccionados, según sean

evidencias de conocimiento, de producto o de desempeño, permitiendo reconocer los logros obtenidos por el estudiante en los tres tipos de saberes: conceptual, procedimental y actitudinal. EVIDENCIAS DE CONOCIMIENTO. Apuntan al dominio cognoscitivo para procesar e identificar información relevante, su clasificación, su interpretación de manera útil, y la búsqueda de las relaciones entre información nueva e información adquirida previamente. Incluye el conocimiento de hechos y procesos, la comprensión de los principios, y teorías y las maneras de utilizar el conocimiento en situaciones cotidianas y nuevas. EVIDENCIAS DE DESEMPEÑO. Evidencias del saber procedimental, relativas al cómo ejecuta el estudiante una actividad, en donde pone en juego sus habilidades, conocimientos y actitudes. Permiten recoger información directa, de mejor calidad y más confiable, sobre la forma como el estudiante desarrolla su proceso de aprendizaje y así poder identificar cuáles han sido sus logros y cuáles le faltan por alcanzar. Incluye las evidencias actitudinales. EVIDENCIAS DE PRODUCTO. Son los resultados que obtiene el estudiante en una actividad que refleja el aprendizaje alcanzado y permite hacer inferencias sobre el proceso desarrollado, o método utilizado.

Evaluación


Realizar diseños de software que responden a las necesidades de un sistema de información considerando las diferentes vistas de una arquitectura de software y los atributos de calidad más relevantes para los usuarios.

Unidad de aprendizaje 1: Aplicar conceptos y técnicas de modelamiento de la vista conceptual de una arquitectura de software

TEMAS HORAS

AD TI

Tema 1: Conceptos de Arquitectura de software 2 6

Tema 2: Qué es el análisis y diseño 2 6

Tema 3: Qué son los procesos de negocio 4 12

Tema 4: Lenguaje Unificado de Modelado 2 6

Tema 5: Diagrama de actividades 2 6

Total 12 36

Unidad de aprendizaje 2: Aplicar conceptos y técnicas de modelamiento de la vista lógica de una arquitectura de software

TEMAS HORAS

Competencia Global


AD TI

Tema 1: Análisis de atributos de calidad 2 6

Tema 2: Análisis de requisitos 2 6

Tema 3: Diagramas de paquetes 2 6

Tema 4: Asignación de responsabilidades 2 6

Tema 5: Diagramas de clases 2 6

Tema 6: Asignación de responsabilidades 2 6

Total 12 36

Unidad de aprendizaje 3: Aplicar conceptos y técnicas de modelamiento de la vista física de una arquitectura de software

TEMAS HORAS

AD TI

Tema 1: Infraestructura 3 9

Tema 2: Diagrama de componentes 3 9

Tema 3: Diagrama de despliegue 3 9

Tema 4: Interfaces 3 9

Tema 5: Documentación 3 9

Total 12 36


Desarrollo temático

Elemento de competencia

Aplicar conceptos y técnicas de modelamiento de la vista conceptual de una arquitectura de software.

Objetivos del módulo Los criterios de desempeño esperados son:

» A Identifica la visión de usuarios de negocio relevantes para la arquitectura.

» Identifica los procesos y entidades de negocio relevantes para la arquitectura.

» Identifica los requerimientos funcionales y atributos de calidad relevantes para la arquitectura.

» Analiza y desarrolla casos de uso e historias de usuario.

» Construye y documenta diagramas de actividades o procesos de negocio.

La arquitectura de software, está relacionada con el diseño y la implementación de estructuras de software de alto nivel. Su propósito es ensamblar un cierto número de elementos arquitectónicos de forma adecuada para satisfacer la mayor funcionalidad y requerimientos de desempeño de un sistema. Según Pressman (2010) "La arquitectura es la estructura u organización de los componentes de un programa (módulos) la manera en que estos componentes interactúan y la estructura de los datos que utilizan los componentes”. Según el estándar IEEE de Prácticas recomendadas para la descripción de arquitectura de software (ISO/IEC 42010:2007) define la arquitectura de software como: “La arquitectura de un sistema software es la organización funcional de dicho sistema plasmada en sus componentes, las relaciones entre éstos y con el entorno, y los principios que guían su diseño e implementación.” Cada paradigma de desarrollo exige diferente número y tipo de vistas o modelos para describir una arquitectura. Existen al menos tres vistas absolutamente fundamentales en cualquier arquitectura:

• La visión estática: describe qué componentes tiene la arquitectura.

• La visión funcional: describe qué hace cada componente.

• La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y cómo interactúan entre sí.

• Las arquitecturas más universales son: • Descomposición Modular. Donde el software se estructura en grupos funcionales muy acoplados.

1

2

Tema 1:Conceptos generales de Arquitectura de Software


• Cliente-servidor. Donde el software reparte su carga de cómputo en dos partes independientes, pero sin reparto claro de funciones. • Arquitectura de tres niveles. Especialización de la arquitectura cliente-servidor donde la carga se divide en tres partes (o capas) con un reparto claro de funciones: una capa para la presentación (interfaz de usuario), otra para el cálculo (donde se encuentra modelado el negocio) y otra para el almacenamiento (persistencia). Una capa solamente tiene relación con la siguiente.

Diseño arquitectónico Este diseño establece la plataforma en que se implementa el sistema, constituye la estructura global del software y las formas en que estas estructuras suministran la integridad conceptual a un sistema, también compone la estructura jerárquica de los elementos del programa, la forma de interactuar de estos elementos y la estructura de los datos usados por estos elementos.


Fuente: http://www.slideshare.net/jose_rob/diseo-de-la-arquitectura-del-software


Un objetivo del diseño del software es derivar una representación arquitectónica de un sistema. Esta representación sirve como marco de trabajo desde donde se llevan a cabo actividades de diseño más detalladas. Un conjunto de patrones arquitectónicos permite que el desarrollador de software reutilice los conceptos a nivel de diseño. (Presman, 2010) Modelos para describir la arquitectura de software Dentro de estos modelos se pueden encontrar:

La visión estática: describe qué componentes tiene la arquitectura. La visión funcional: describe qué hace cada componente. La visión dinámica: describe cómo se comportan los componentes a lo largo del tiempo y cómo interactúan entre sí. La siguiente figura muestra las vistas que integran la arquitectura de un sistema software.


Fuente: http://www.que-informatica.com/index.php/software/uml-lenguaje-unificado-de-modelado-2/


El siguiente documento Arquitectura_Software da cuenta de la arquitectura de software y diseño arquitectónico, este se centra en la representación de la estructura de los componentes del software, sus propiedades e interacciones. Con la siguiente presentación Arquitectónico y Detallado se muestra los pasos requeridos para elaborar el documento de diseño que incluye el diseño arquitectónico del software. Ya se tiene el conocimiento de cuál es la arquitectura de software que integran un sistema software, ahora para construir la arquitectura de una situación software se debe entrar a ver lo que es el análisis y diseño. Tema 2: ¿Qué es el análisis y diseño? El análisis de software se centra en determinar el qué asociado a un problema y no en el cómo se da solución al mismo, en el análisis de requerimientos se captura y detalla los requerimientos de funcionalidad y de calidad del producto a desarrollar.

Imagen recuperada de: http://isg2.pbworks.com/w/page/7624278/Introduccion%20al%20Dise%C3%B1o Para construir un sistema de información es necesario tener las descripciones detalladas de la solución lógica y la forma en como estas descripciones satisfacen los requerimientos del sistema. El diseño se centra en determinar el cómo se da solución a un problema, es el proceso de transformar un problema en una solución, es concebir y especificar los detalles de cómo el sistema cumplirá las especificaciones de requerimientos, es en el diseño donde se involucra la arquitectura de software.


Tema 3: ¿Qué son los procesos de negocio? Los procesos de negocio indican aquello que hace una empresa para operar: realizar ventas, pagar nómina, realizar la contabilidad, etc. Un primer paso en el análisis y diseño es analizar los procesos de negocio de una organización; lo cual nos permite identificar sus necesidades, las cuales pueden expresarse como casos de uso. Un caso de uso es una descripción narrativa textual de los procesos de una empresa o sistema, ejemplo:

Caso de uso Hacer un pedido Descripción Este caso de uso empieza cuando un cliente hace

una compra en el sitio web de la organización. Este pedido queda registrado en una nueva orden junto con la información del cliente y el producto

Una vez se identifican los procesos de negocio de una organización, se identifican los roles de las personas que intervienen en ellos; ejemplo: cliente, representante de ventas, analistas, contadores, etc. Esta actividad nos permite tener un primer borrador de un modelo conceptual, en donde, se presentan las diversas categorías de las cosas en el dominio; no sólo los roles de las personas sino también todas las cosas de interés. Conociendo los roles de los empleados, se definen las responsabilidades de ellos para efectuar las tareas requeridas para llevar a cabo un proceso de negocio (funciones). Teniendo identificado los procesos de negocio y funciones de una organización se puede realizar asignación de responsabilidades. La asignación distribuye las funciones y las responsabilidades entre varios objetos de software en el sistema de información. Los objetos de software interactúan para cumplir con sus responsabilidades. Requerimiento

Con la lectura del siguiente documento Requerimientos se puede ampliar los conocimientos sobre la Ingeniería de Requerimientos. Un requerimiento es una descripción de una necesidad o un deseo de un

producto. Durante la licitación de requerimientos se identifican y documentan las necesidades de forma clara y concisa. Un requerimiento no debe ser interpretado de forma diferente por varios interesados.

Casos de uso Para comprender los requerimientos es necesario conocer los procesos de negocio y las características que rodean o tienen algún tipo de impacto en una organización. Los procesos de negocio se pueden descomponer en casos de uso. Los casos de uso son una excelente técnica que permite mejorar la comprensión de los requerimientos. Un caso de uso es un documento narrativo que describe la secuencia de eventos de un actor que interactúa con un sistema para completar un proceso. Un caso de uso es una historia o caso de utilización de un sistema de información. A continuación, se presenta una descripción de un caso de uso y posteriormente se presenta el curso normal de eventos asociado a ese caso de uso. (Larman, 2004)

Fuente: UML y patrones, Craig Larman


Acción del actor Respuesta del sistema 1. Este caso de uso comienza cuando un Cliente llega a una caja de TPDV (terminal de punto de venta) con productos que desea comprar

2. El Cajero registra el identificador de cada producto. Si hay varios productos de una misma categoría, el Cajero también puede introducir la cantidad.

3. Determina el precio del producto e incorpora a la transacción actual la información correspondiente. Se presentan la descripción y el precio del producto actual.

4. Al terminar de introducir el producto, el Cajero indica al TPDV que se concluyó la captura del producto.

5. Calcula y presenta el total de la venta.

6. El Cajero le indica el total al cliente.

7. El Cliente efectúa el pago en efectivo.

8. El Cajero registra la cantidad de efectivo recibida

9. Muestra al cliente la diferencia. Genera un recibo.

10. El Cajero deposita el efectivo recibido y extrae el cambio del pago. El Cajero da al Cliente el cambio y el recibo impreso.

11. El cliente se marcha con los

artículos comprados. Cursos alternos:

§ Paso 2: introducción de identificador inválido. Indicar error. § Paso 7: el cliente no tenía suficiente dinero. Cancelar la

transacción de venta.

Fuente: UML y patrones, Craig Larman La construcción de los casos de uso necesita los requerimientos tomados al cliente, observemos este video. Levantamiento de requerimientos de un proyecto. http://www.youtube.com/watch?v=nvPcjDCtEu0 En el video se puede ver la importancia de tomar los requerimientos del cliente y así poder comprometernos con un desarrollo eficiente considerando los atributos de calidad requeridos. Diagrama de casos de uso Un diagrama de casos de uso explica de forma gráfica un conjunto de casos de uso de un sistema, los actores y las relaciones entre éstos y los casos de uso; al igual que las relaciones entre los casos de uso.


Fuente: UML y patrones, Craig Larman No existe una forma única de realizar un diagrama de casos de uso, pero si existen algunas buenas prácticas que ayudan al entendimiento de éstos:

§ Demarcar el sistema e incluir dentro del sistema aquellos casos de uso que son responsabilidad del mismo.

§ Tratar de agrupar casos de uso. Ejemplo: casos de uso relacionados con interacción con una base de datos (crear, eliminar, actualizar, consultar) se pueden simplificar en un solo caso de uso.


§ Nombrar los casos de uso de manera que comiencen con un verbo.

En la siguiente presentación casos de uso le guía con ejemplos la construcción del diagrama de casos de usos. Modelo conceptual Un modelo conceptual es una representación gráfica subjetiva que ayuda a entender el dominio, la organización, los procesos de negocio y el problema que se desea resolver, descompone el dominio del problema en conceptos, atributos y asociaciones que se consideran importantes. Como puede observar en el siguiente documento: Modelización, el diseño conceptual de datos solo hace una representación de las reglas

que reflejan la necesidad planteada por el cliente, el modelamiento conceptual no representa componentes de software sino conceptos del dominio del problema en el mundo real. Tema 4: Lenguaje Unificado de Modelado El Lenguaje Unificado de Modelado (UML) es un lenguaje de modelado de propósito general en la ingeniería de software que provee una forma estándar de visualizar el diseño de un sistema de información. La última versión de UML cuenta con muchos tipos de diagramas que se pueden dividir en dos categorías: aquellos que representan información estructural y los que representan tipos de comportamiento, incluyendo algunos que representan diferentes aspectos de interacciones. Los diagramas UML se pueden clasificar de forma jerárquica de la siguiente forma:


Recuperado de: http://sistemasy.blogspot.com/2011/03/enumere-los-tipos-de-diagrama-de-uml-y.html


Para poder representar los diagramas tenemos que retomar lo que es UML y para esto debemos ver el siguiente video. UML (Historia, definición e implementación) https://www.youtube.com/watch?v=lkZ9vyBeWqU Como se puede observar en el video UML tiene una notación para poder comunicar el análisis de requisitos de forma adecuada, contar con diagramas que representan una estructura no es suficiente, al documentar una vista, conviene acompañar al diagrama de información adicional donde se expliquen decisiones de diseño, además de brindar mayor detalle sobre los elementos mostrados en el diagrama y las relaciones entre estos. Herramientas de trabajo UML Para realizar los ejercicios y trabajos de esta asignatura usted debe contar con el siguiente software: Herramienta de Modelado UML: para ello tiene las siguientes alternativas: 1. Astah: para descargar este software puedes revisar el paso a paso en el siguiente manual Manual Astah También hay otras alternativas como:

2. Ms Visio: Se puede conseguir una versión de prueba. Este software es compatible con las herramientas de Visual Studio. 3. Puede conseguir muchas otras herramientas, entre ellas Visual UML, Visual Paradigm. Ver enlace: COMPARATIVA_HERRAMIENTAS_UML En el documento Lenguaje de modelado UML puede profundizar en el tema de UML Tema 5: diagrama de actividades Los diagramas de actividad describen la lógica del funcionamiento de cada uno de los casos de uso descritos en el Diagrama de Casos de Uso. Para cada caso de uso se desarrolla una interfaz de usuario de prueba para mostrar cómo se piensa implementar tal funcionalidad. Por lo tanto, la funcionalidad del sistema queda expresada por: el caso de uso, el diagrama de actividad y la interfaz de usuario. En el documento: Diagrama de Actividades se indican las técnicas necesarias para crear un diagrama de secuencia. DIAGRAMAS DE ACTIVIDAD PARA CASO DE USO – EJEMPLO: Plantilla resumida del Caso de Uso Realizar Pedido


Fuente: www.vico.org Recursos de profundización de aprendizaje: El siguiente documento Interfaces de usuario avanzadas puede profundizar en la arquitectura de software para una interfaz de usuario avanzada en diferentes tipos de aplicaciones software. El siguiente presentación Fundamentos de Definición de Arquitectura de Software se centra en la evolución, estructura de los componentes del software, sus propiedades e interacciones de la arquitectura de software. En el libro “Ingeniería del software. Un enfoque práctico”, parte 2 modelado que se encuentra en la biblioteca Pearson, puede profundizarse en los siguientes temas: CAPÍTULO 5. Comprensión de los requerimientos CAPÍTULO 6. Modelado de los requerimientos: escenarios, información y clases de análisis CAPÍTULO 7. Modelado de los requerimientos: flujo, comportamiento, patrones y webapps CAPÍTULO 8. Conceptos de diseño CAPÍTULO 9. Diseño de la arquitectura Referencias de la unidad de competencia: 2 - levantamiento de requerimientos de un proyecto. Recuperado de: http://www.youtube.com/watch?v=nvPcjDCtEu0

Astah: Recuperado de: http://translate.google.com.co/translate?hl=es-419&sl=en&u=http://astah.net/editions/community&prev=search Booch, G. (2006). El Lenguaje Unificado de Modelado. Ed. Prentice – Hall. Biblioteca Virtual – Universidad Católica del Norte. Bruegge, B. (2002). Ingeniería de software orientada a objetos. Ed. Prentice – Hall. Biblioteca Virtual – Universidad Católica del Norte. Comparativa de herramientas UML de libre distribución (o con pocas restricciones). Recuperado de: https://es.scribd.com/doc/231335605/COMPARATIVA-DE-HERRAMIENTAS-UML-DE-LIBRE-DISTRIBUCION-docx Diagramas UML de actividades para la definición de reglas de negocio y comportamientos de RFS. Recuperado de: http://www.lsi.us.es/~javierj/cursos_ficheros/metricaUML/EAActividades.pdf El Lenguaje de Modelado UML. Recuperado de: http://biblioteca.ucn.edu.co/repositorio/Ingenieria/Ingenieria-de-Software-I/documentos/Vision_uml.htm Interfaces de Usuario Avanzadas. Arquitecturas de software http://docplayer.es/76476248-Interfaces-de-usuario-avanzadas-arquitecturas-de-software.html Kendall, K. (2011) Análisis y diseño de sistemas. 8ª edición. Ed. Prentice – Hall. Biblioteca Virtual – Universidad Católica del Norte. La Ingeniería de Requerimientos - Ingeniería De Software. Recuperado de: http://www.ilustrados.com/publicaciones/EpyVZFEVukfVKPBUot.php


Larman, C. (2004). UML y patrones: Introducción al análisis y diseño orientado a objetos. Ed. Prentice – Hall. Biblioteca Virtual – Universidad Católica del Norte. Manual Astah. Recuperado de: http://www.google.com.co/url?sa=t&rct=j&q=&esrc=s&source=web&cd=4&ved=0CDIQFjAD&url=http%3A%2F%2Fumlcomoestandardemodelado.wikispaces.com%2Ffile%2Fview%2FTutorial%2BASTAH.docx&ei=P_dzVLvqE8afNoe0grgN&usg=AFQjCNEmNgN2I9rkiRSWBIYVGnLupEl5Rw&bvm=bv.80185997,d.eXY Modelización conceptual de datos. Recuperado de: http://www.manati-atlantico.gov.co/apc-aa-files/37343238356636333361356139626137/Modelizacion.pdf. Naranjo. Mauricio. Chief Architect. Recuperado de: http://52.0.140.184/typo43/fileadmin/Base_de_Conocimiento/XXV_Salon_de_Informatica/LucasianLabs.ACIS.MNARANJO.DEF-ARQ.PARTE1.ver2.0.0.ppt UML (Historia, definición e implementación). Recuperado de: https://www.youtube.com/watch?v=lkZ9vyBeWqU Roger S. Pressman (2010). Ingeniería de Software. Un enfoque práctico. 7ª Edición. Ed. McGraw-Hill. Sommerville, I. (2011). Ingeniería de Software. 9ª Edición. Ed. Pearson. Biblioteca Virtual – Universidad Católica del Norte.



Aplicar conceptos y técnicas de modelamiento de la vista lógica de una arquitectura de software


» Identifica los requerimientos funcionales y atributos de calidad relevantes para la arquitectura.

» Identifica y asigna responsabilidades a los componentes de la arquitectura.

» Selecciona estilos y patrones arquitectónicos.

» Construye y documenta diagramas de clases.

» Construye y documenta diagramas de paquetes.

La calidad de un producto software se mide en función de sus atributos de calidad y éstos deben ser expresados de forma que puedan ser verificados. Si una arquitectura de software se encuentra incorrecta en su diseño, se tiene la posibilidad de construir un sistema que no alcanzará el total de los requerimientos creados inicialmente. En la siguiente figura se muestran los seis atributos claves que define el estándar ISO 9126.

Tema 1:Análisis de atributos de calidad

2

2


Recuperado de: http://www.runit.com.ar/pages/view/32917/atributos-de-calidad-de-software


El analista y arquitecto no se pueden comprometer a cumplir con todos los atributos de calidad al 100%, resultaría indefinido por el conflicto que puede existir entre ellos, esto puede llevar a que el cliente quede descontento entonces se busca que sea lo más aproximado posible es por esto que debe ver en la siguiente presentación la importancia de analizar los atributos de calidad de un software. Atributos_calidad_software

Recuperado de: http://estandarescalidadsoftware.blogspot.com/

Tema 2: Análisis de requisitos Dentro del análisis de requisitos se busca conocer con todo el detalle, cuál es el funcionamiento actual del área y en especial, cuál es el manejo y flujo de la información producida y que llega al área. Es una labor totalmente descriptiva y de conocimiento por parte del grupo de trabajo, se definen los procesos de información existentes, qué hacen, cómo lo hacen, con qué información lo hacen y qué resultados arrojan. Según (PRESSMAN, 2010) “La ingeniería de requisitos del software es un proceso de descubrimiento, refinamiento, modelado y especificación. Se refinan en detalle los requisitos del sistema y el papel asignado al software”. Según (PRESSMAN, 2010) “La calidad con que se realice la captura de los requisitos va a influenciar en todo el proceso de desarrollo del software repercutiendo en el resto de las fases de desarrollo del mismo. Una definición eficiente de los requisitos permite mostrar un nivel de disciplina en el proceso de desarrollo, dar un mejor soporte a la Gestión de Cambios y ganar una mayor eficiencia en las pruebas reduciendo el riesgo, mejorando la calidad y permitiendo la automatización. Además, contribuye a tomar mejores decisiones de diseño y de arquitectura. También le permite al equipo de desarrollo reducir los problemas de mantenimiento”. Luego del análisis de los requisitos funcionales representados en los casos de uso se continúa con el análisis de datos.


Tema 3: Diagramas de paquetes

Después de la especificación de los requerimientos viene el diseño de la arquitectura de software que involucra elementos como: componentes de software, propiedades de dichos componentes y la comunicación entre ellos. Se encontrará con la necesidad de organizar los elementos de un diagrama en un grupo, ciertas clases o componentes que son parte de un subsistema en particular. Características

• Permiten dividir un modelo para agrupar y encapsular sus elementos en unidades lógicas individuales.

• Permite organizar los elementos modelados con UML, facilitando de esta forma el manejo de los modelos de un sistema complejo.

• Plantean la arquitectura del sistema a nivel macro. • En este sentido, son similares a los namespaces en C++ o a los

paquetes en Java

Ejemplo


Imagen adaptada de http://www.codecompiling.net/files/slides/UML_clase_05_UML_paquetes.pdf


Recuperada de: http://moodle2.unid.edu.mx/dts_cursos_mdl/pos/TI/IS/AM/09/secuencia_del_sistema.pdf


Es importante que todos los elementos relacionados con el modelo del dominio tengan como raíz un paquete denominado Dominio, y todos los conceptos básicos, comunes, compartidos, se definan en un paquete llamado Elementos Básicos Como se pudo observar en el video del elemento de competencia unidad 1 UML tiene una notación para poder comunicar el diseño de forma adecuada, contar con diagramas que representan una estructura no es suficiente, al documentar una vista, conviene acompañar al diagrama de información adicional donde se expliquen decisiones de diseño, además de brindar mayor detalle sobre los elementos mostrados en el diagrama y las relaciones entre estos. Tema 4: Asignación de responsabilidades Patroness Grasp (General reponsability assignament software pattern) En diseño orientado a objetos, GRASP son patrones generales de software para asignación de responsabilidades, es el acrónimo de "General Responsibility Assignment Software Patterns". Aunque se considera que más que patrones propiamente dichos, son una serie de "buenas prácticas" de aplicación recomendable en el diseño de software. Patrones de software para asignar responsabilidades Función: Definir en las clases de análisis. La clase con mayor jerarquía para implementar en ella los métodos. Clase patrón Asignar responsabilidades a las clases. Elementos para definir un patrón Grasp. Diagrama de paquetes Diagrama de clases

Tema 5: Diagramas de clases La arquitectura de software permite representar de forma concreta la estructura y funcionamiento interno de un sistema es por esto que el diseño detallado se lleva a cabo justo antes de la codificación, y forma parte de las primeras tareas del desarrollador donde describe la lógica, la estructura de datos, empacado de componentes, propiedades visibles externamente de esos componentes, y las relaciones entre ellos.


Fuente: Oralia Cortés G. (2014). Módulo de Arquitectura de Software


En el documento Tecnología orientada a objetos encontrará los principios básicos de la orientación a objetos que son fundamentales para interpretar el diagrama de clases.

Es en el diagrama de clases donde se describe la estructura de un software mostrando sus clases, atributos y las relaciones entre ellos. Estos son utilizados durante el proceso de análisis y diseño de los sistemas, donde se crea el diseño conceptual de la información que se manejará en la aplicación.

Lea y analice el documento sobre Diagrama de clases en el que se explica la arquitectura y los componentes del diagrama, preste especial atención a los ejemplos, en los cuales se desarrollan los diagramas de clases, aspecto fundamental para representar la vista lógica. Ahora que ya se realizó el diagrama de clases veremos cómo los objetos (instancias y clases) interactúan unos con otros a través de los diagramas de interacción como son los diagramas de secuencia. Los diagramas de interacción muestran las decisiones referentes a la asignación de responsabilidades entre objetos del diagrama de clases. Con la lectura del documento diagrama de secuencia podrá obtener los conocimientos necesarios para realizar un diagrama de secuencias. Tema 6: Asignación de responsabilidades Booch, Rumbaugh y Jacobson definen responsabilidad como “un contrato u obligación de una clase o tipo”. La asignación de responsabilidades a objetos consiste en determinar cuáles son las obligaciones (responsabilidades) concretas de los objetos del diagrama de clases que permita dar respuesta a las funcionalidades del sistema.

• La asignación de responsabilidades a objetos se realiza al definir y localizar las operaciones de cada clase de objetos

• Las responsabilidades de un objeto consisten en: Saber:

• Sobre los atributos de los objetos • Sobre los objetos asociados • Sobre los datos que puedan derivarse o calcularse

Hacer: • Operaciones sobre el propio objeto • Coordinar y controlar las actividades de otros objetos • Llamar a métodos de otros objetos

En el siguiente documento Capítulo 13 Modelo de Casos de Uso: añadir detalles con los contratos de las operaciones da cuenta de cómo construir los contratos que describen el comportamiento detallado del sistema en función de los cambios de estado de los objetos del Modelo del Dominio

Recursos de profundización de aprendizaje:

Profundice sus conocimientos con la presentación ClasesUML, en la que se explican clases, relaciones y atributos del diagrama de clases. El siguiente documento Capítulo 13 Modelo de Casos de Uso: añadir detalles con los contratos de las operaciones puede profundizar en los temas de casos de usos, diagrama de secuencia, diagrama de clases y contratos. Para profundizar sobre los patrones de la arquitectura de software debe estudiar el documento Patrón donde encontrara que estos dentro del mundo del desarrollo del software persiguen establecer una nomenclatura de referencia para ayudar a los ingenieros de software a solucionar o a afrontar problemas de Ingeniería del Software.


En el siguiente documento Análisis puede profundizar en el tema de los contratos en las páginas de la 13 a la 28. Por último se puede ver Ejemplo sencillo sobre Modelado de un Proyecto un caso de estudio resuelto completo y sencillo sobre modelado UML que le ayudará a extender los conocimientos sobre el modelado de los diagramas utilizados en la vista lógica. En el libro Ingeniería del software. Un enfoque práctico, parte dos

modelado, donde puede profundizar en los siguientes temas:

CAPÍTULO 6. Modelado de los requerimientos: escenarios, información

y clases de análisis

CAPÍTULO 7. Modelado de los requerimientos: flujo, comportamiento,

patrones y webapps

CAPÍTULO 8. Conceptos de diseño

CAPÍTULO 9. Diseño de la arquitectura

CAPÍTULO 10. Diseño en el nivel de componentes

CAPÍTULO 11. Diseño de la interfaz de usuario

CAPÍTULO 12. Diseño basado en patrones (Presman, 2010)

Referencias de la unidad de competencia: Referencias bibliográficas Análisis Recuperado de: http://adimen.si.ehu.es/~rigau/teaching/EHU/ISHAS/Curs2007-2008/Apunts/IS.6.pdf Atributos de calidad en el desarrollo del software. Recuperado de: http://es.slideshare.net/gustavocuen77/atributos-de-calidad-en-el-desarrollo-de-software-30272613?related=2 Booch, G. (2006). El Lenguaje Unificado de Modelado. Ed. Prentice –

Hall. Biblioteca Virtual – Universidad Católica del Norte.

Bruegge, B. (2002). Ingeniería de software orientada a objetos. Ed. Prentice – Hall. Biblioteca Virtual – Universidad Católica del Norte. Capítulo 13 Modelo de Casos de Uso: añadir detalles con los contratos de las operaciones. Recuperado de: http://lsi.ugr.es/~mvega/docis/contratos.pdf Caso de estudio resuelto completo y sencillo sobre modelado UML. Recuperado de: http://msdn.microsoft.com/es-es/library/bb972214.aspx#XSLTsection129121120120 Clases.ppt. Recuperado de: Http://www.exa.unicen.edu.ar/catedras/arqmod/CLASE1-UML.ppt . García, Peñalvo. Francisco. J. Patrones. Recuperado de: https://repositorio.grial.eu/bitstream/grial/356/1/patrones1.pdf Kendall, K. (2011) Análisis y diseño de sistemas. 8ª edición. Ed. Prentice – Hall. Biblioteca Virtual – Universidad Católica del Norte. Larman, C. (1999). UML y patrones: Introducción al análisis y diseño orientado a objetos. Ed. Prentice – Hall. Biblioteca Virtual – Universidad Católica del Norte. Principios básicos de la orientación a objetos. Recuperado de: http://biblioteca.ucn.edu.co/repositorio/Ingenieria/Ingenieria-de-Software-I/documentos/ppiosooo.htm http://java.ciberaula.com/articulo/tecnologia_orientada_objetos/ Sommerville, I. (2002). Ingeniería de Software. 9ª Edición. Ed. Pearson. Biblioteca Virtual Universidad Católica del Norte.



Aplicar conceptos y técnicas de modelamiento de la vista física de una arquitectura de software


» Identifica la infraestructura más apropiada para el sistema.

» Define los nodos, los componentes y las interfaces del sistema.

» Construye y documenta diagramas de despliegue.

» Construye y documenta diagramas de componentes.

Un proyecto software debe ser de calidad, sostenible, fácil de usar, que satisfaga las necesidades del cliente, que funcione de manera eficiente y eficaz en una infraestructura que congregue y establezca el conjunto de elementos tecnológicos para garantizar un excelente trabajo de software.

Tema 1:Infraestructura

2

2


Fuente: Oralia Cortés G (2015). Módulo de Arquitectura de Software.


Tema 2: Diagrama de componentes El Diagrama Componentes modela la estructura de componentes del sistema software que se quiere desarrollar, se presenta en el diseño que da paso a la implementación y se genera a partir del diagrama de clases.

La siguiente imagen refleja un diagrama de varios componentes y la relación entre ellos.

Recuperado de: https://prezi.com/yzvn1klhsd4x/diagramas-de-componentes/


Como se observa en el documento Diagrama_Componentes los elementos de diseño de un sistema de software del diseño que interactúan con otros elementos del diseño a través de un conjunto restringido de entradas y salidas. Tema 3: Diagrama de despliegue

El diagrama de distribución o despliegue UML muestra la arquitectura física de un sistema informático, este puede representar los equipos y los dispositivos, y también mostrar sus interconexiones y el software que se encontrará en cada computador.


Recuperado de: http://wiki.vivatia.com/index.php?title=Imagen:Arq7.png Los diagramas de despliegue describen la arquitectura física del sistema durante la ejecución, en términos de: procesadores, dispositivos, componentes de software, la topología del sistema: la estructura de los elementos de hardware y software que ejecuta cada uno de ellos. Tema 4: Interfaces Son los enlaces físicos y funcionales entre dos sistemas o dispositivos de cualquier tipo dando una comunicación entre distintos niveles, propiedad de la interacción, el área donde se desarrollan los intercambios y operaciones. En la arquitectura de software se suministran los componentes que llevan a cabo alguna tarea, sus interfaces y la comunicación entre ellos. esta debe ser implementable en una arquitectura física o diagrama de despliegue, que consiste simplemente en determinar qué computador tendrá asignada cada tarea. Estudiando el documento Las Interfaces en Arquitectura de Software puede crear las interfaces y la comunicación entre ellas.

Tema 5: Documentación Es muy importante documentar cada actividad u operación que se realiza en el desarrollo de cada etapa del software, si esto no se hace se tendrá que volver a consultar lo que está hecho y se pondrá en duda decisiones que tomó durante el desarrollo del mismo. Los analistas y programadores toman como hábito la documentación de todas las actividades desarrolladas, les resulta normal documentar a medida que van avanzando. Estudiando el documento Documentar un sistema de software Aprenderá a documentar software.


Recursos de profundización de aprendizaje:

Profundice sus conocimientos sobre la vista lógica visitando la siguiente página web: Concepto: Vista de despliegue en la que se explica la distribución física de procesos del sistema. Por último se puede ver Ejemplo de Despliegue un caso de estudio resuelto completo que le ayudará a extender los conocimientos sobre la aplicación de arquitectura de software a una situación determinada. En el libro Ingeniería del software. Un enfoque práctico, parte 2

modelado, donde puede profundizar en los siguientes temas:

CAPÍTULO 10. Diseño en el nivel de componentes

CAPÍTULO 11. Diseño de la interfaz de usuario

CAPÍTULO 12. Diseño basado en patrones (Presman, 2010)

Referencias bibliográficas Boletín S7: Cómo documentar un sistema de software. Recuperado de: http://mit.ocw.universia.net/6.170/6.170/f01/related-

resources/documentation.html

Días Emiliano (2011) Las Interfaces en Arquitectura de Software. Recuperado de: https://emidiaz.wordpress.com/author/emidiaz/

BOOCH, G. (2006). El Lenguaje Unificado de Modelado. Ed. Prentice –

Hall. Biblioteca Virtual – Universidad Católica del Norte.

BRUEGGE, B. (2002). Ingeniería de software orientada a objetos. Ed. Prentice – Hall. Biblioteca Virtual – Universidad Católica del Norte.

LARMAN, C. (1999). UML y patrones: Introducción al análisis y diseño orientado a objetos. Ed. Prentice – Hall. Biblioteca Virtual – Universidad Católica del Norte. KENDALL, K. (2011) Análisis y diseño de sistemas. 8ª edición. Ed. Prentice – Hall. Biblioteca Virtual – Universidad Católica del Norte. SOMMERVILLE, I. (2002). Ingeniería de Software. 9ª Edición. Ed. Pearson. Biblioteca Virtual – Universidad Católica del Norte. Concepto: Vista de despliegue. Recuperado de https://cgrw01.cgr.go.cr/rup/RUP.es/LargeProjects/core.base_rup/guidances/concepts/deployment_view_64CB74A6.html?proc={002674F9-6511-4D15-8623-B761D8C48986}&path={002674F9-6511-4D15-8623-B761D8C48986},{F2160C54-F666-4736-9982-FC7F58F15FAD},2.8416696002928195E-305

Arquitectura de software - contenido.elion.education · Realizar diseños de software que responden...

Documents

Transcript of Arquitectura de software - contenido.elion.education · Realizar diseños de software que responden...