mi茅rcoles, 23 de septiembre de 2020

BIENVENIDA

    BIENVENIDOS…

Este blog es realizado con la finalidad de aprender y dar a conocer informaci贸n y conocimientos con respecto a los que es la Ingeniera del Software, y m谩s aun el Dise帽o Arquitect贸nico, esta informaci贸n es recolectada a trav茅s de una serie de paginas y documento con la finalidad de dar a conocer la importancia de la Ingenier铆a del Software y el Dise帽o Arquitect贸nico en la realizaci贸n de los proyectos de software, puesto que permiten tener una gesti贸n de los recursos y actividades a realizar, as铆 como una estructura en la que se pueden plasmar de manera eficaz todos los componentes de un sistema, lo que beneficiara al programador al momento de desarrollar el software en cada una de sus fases u etapas. 

Esperando que sea de su agrado y ayude a la compresi贸n de los diferentes temas aqu铆 plasmados...




INGENIER脥A DE SOFTWARE - ARQUITECTURA DEL SOFTWARE

INGENIER脥A DE SOFTWARE - ARQUITECTURA DEL SOFTWARE

En los primeros tiempos de la inform谩tica, la programaci贸n se consideraba un arte y se desarroll贸 como tal debido a la dificultad que entra帽aba para la mayor铆a de las personas, pero con el tiempo se han ido descubriendo y desarrollando formas y directrices generales, sobre la base de las cuales se pueden resolver los problemas. Se han llamado arquitectura de software, porque, al igual que los planos de un edificio o una construcci贸n, indican la estructura, el funcionamiento y la interacci贸n entre las partes del software. Por lo que, la arquitectura de software es el dise帽o de m谩s alto nivel de la estructura de un sistema.

§ Una arquitectura de software, tambi茅n llamada arquitectura l贸gica, consiste en un conjunto de patrones coherentes y abstracciones que proporcionan un marco definido y claro para interactuar con el c贸digo fuente del software.

§ La arquitectura de un programa inform谩tico se selecciona y dise帽a en funci贸n de los objetivos (requisitos) y las limitaciones. Los objetivos son los prefijados para el sistema de informaci贸n, pero no s贸lo los funcionales sino tambi茅n otros objetivos como el mantenimiento, la auditor铆a, la flexibilidad y la interacci贸n con otros sistemas de informaci贸n.

§ Las restricciones son las limitaciones derivadas de las tecnolog铆as disponibles para aplicar los sistemas de informaci贸n. Algunas arquitecturas son m谩s aconsejables de implementar con ciertas tecnolog铆as mientras que otras no son adecuadas para determinadas arquitecturas. Por ejemplo, no es factible utilizar una arquitectura de programas inform谩ticos de tres niveles para implantar sistemas en tiempo real.

§ La arquitectura de programas inform谩ticos define, de manera abstracta, los componentes que realizan alguna tarea de c谩lculo, sus interfaces y la comunicaci贸n entre ellos. Toda arquitectura debe ser ejecutable en una arquitectura f铆sica, que consiste simplemente en determinar qu茅 computadora se asignar谩 a cada tarea.




El Dise帽o en la Ingenier铆a De Software

     El Dise帽o en la Ingenier铆a De Software    

Es el proceso de dise帽o para la planificaci贸n de una soluci贸n de software, este proceso es por regla general, necesaria para que los programadores puedan manejar la complejidad que la mayor铆a de los programas inform谩ticos poseen y para disminuir el riesgo de desarrollos err贸neos. De forma m谩s sencilla, es definida como el proceso de definici贸n de la arquitectura, componentes, interfaces y otras caracter铆sticas de un sistema o componente que resulta de este proceso. Tambi茅n, como un proceso que transforma los requisitos del usuario de una manera conveniente, lo que ayuda al programador a en la codificaci贸n e implementaci贸n del software.


Para evaluar los requisitos del usuario, un documento SRS (Software Requirement Specification, en espa帽ol “ERS” - Especificaci贸n de Requisitos de Software) se crea tanto para codificar como para implementar, hay una necesidad de especificar de un modo m谩s detallado los requisitos en t茅rminos de Software. El resultado de este proceso puede ser usado directamente en la implementaci贸n de lenguajes de programaci贸n. Adem谩s, el dise帽o de Software es el primer paso en el SFDLC (Software Design Life Cycle o en espa帽ol Ciclo de Vida del Dise帽o de Software).  Cabe agregar, que el dise帽o de datos es la primera de las tres actividades de dise帽o, los datos bien dise帽ados pueden conducir a una mejor estructura de programa, a una modularidad efectiva y a una complejidad procedimental reducida.




Dise帽o de Niveles o Entornos de Software

Dise帽o de Niveles o Entornos de Software


El dise帽o de Mediante Software produce tres tipos o niveles de resultado: 


Dise帽o arquitect贸nico: Define las relaciones entre los principales elementos estructurales del programa, es decir, el dise帽o arquitect贸nico, es la versi贸n m谩s abstracta del sistema. Identifica el software como un sistema con distintos componentes que interact煤an entre ellos. En este momento es cuando los dise帽adores conciben la idea de posibles soluciones de dominio.

Dise帽o de alto nivel - El Dise帽o de alto nivel, rompe con el concepto de dise帽o arquitect贸nico que se refiere a “Componente de 煤nica entidad m煤ltiple”, por lo contrario tiene un punto de vista menos abstracto de los subsistemas y m贸dulos y representa la existente interacci贸n entre ellos. El Dise帽o de alto nivel se centra en c贸mo el sistema junto con todos sus componentes se puede implementar en forma de m贸dulos. Reconoce estructuras modulares de cada subsistema y su relaci贸n e interacci贸n entre las mismas.

Dise帽o detallado - Es m谩s detallado en cuanto a los m贸dulos y a su implementaci贸n,  define estructuras l贸gicas de cada m贸dulo y de sus interfaces para comunicarse con los otros m贸dulos. Adem谩s, se ocupa del refinamiento de la representaci贸n arquitect贸nica que lleva a una estructura de datos detallada y a las representaciones algor铆tmicas del software.  Igualmente, el dise帽o detallado describe cada componente y su comportamiento espec铆fico, de forma que puede procederse a su construcci贸n

Conceptos B谩sicos del Dise帽o

    Conceptos B谩sicos del Dise帽o

Abstracci贸n

Es el proceso o el resultado de la generalizaci贸n de la reducci贸n del contenido de la informaci贸n de un concepto o un fen贸meno observable, por lo general, con el fin de conservar 煤nicamente la informaci贸n que es relevante para un prop贸sito en particular. Cuando se considera una soluci贸n modular a cualquier problema se pueden exponer muchos grados de abstracci贸n.

·      Abstracci贸n Procedimental: Se refiere a una secuencia de instrucciones que tiene una funci贸n espec铆fica y limitada.

·      Abstracci贸n de Datos: Es una colecci贸n nombrada de datos que describe un objeto de datos.

 

Cohesi贸n

La Cohesi贸n es una medida que define el grado de interdependencia entre los elementos que conforman los m贸dulos. A mejor cohesi贸n, mejor dise帽o de programa obtenemos. Hay siete tipos de cohesi贸n, llamados:

§  Cohesi贸n coincidente - Es una cohesi贸n no planificada y aleatoria, la cual puede romper el programa en peque帽os m贸dulos por el bien de la modularizaci贸n. Como que no tiene una planificaci贸n, puede confundir a los programadores. Por eso este tipo no est谩 generalmente aceptado.

§  Cohesi贸n l贸gica - La categorizaci贸n de manera l贸gica en la que los elementos se colocan juntos en un mismo m贸dulo, se denomina Cohesi贸n l贸gica.

§  Cohesi贸n temporal - Cuando los elementos del m贸dulo se organizan de manera que se procesan en un momento similar en el tiempo, hablamos de Cohesi贸n temporal.

§  Cohesi贸n procedimental - Cuando los elementos del m贸dulo se agrupan juntos, y se ejecutan de forma secuencial para poder llevar a cabo una tarea, hablamos de Cohesi贸n procedimental.

§  Cohesi贸n comunicativa - Cuando los elementos del m贸dulo se agrupan juntos, y se ejecutan y funcionan en los mismos datos (informaci贸n) de forma secuencial, hablamos de Cohesi贸n comunicativa.

§  Cohesi贸n secuencial - Cuando los elementos del m贸dulo se agrupan porque el resultado de un elemento sirve de entrada a otro y as铆 sucesivamente, hablamos de Cohesi贸n secuencial.

§  Cohesi贸n funcional - Se considera la mejor en cuanto a mayor grado de cohesi贸n, y es altamente previsible. Los elementos del m贸dulo en cohesi贸n funcional se agrupan porque todos ellos contribuyen a conseguir una funci贸n 煤nica y bien definida. Tambi茅n se puede reutilizar.

 

Acoplamiento

El acoplamiento es una medida que define el nivel de interdependencia entre los m贸dulos del programa. Nos muestra el nivel en que los m贸dulos interfieren e interact煤an entre ellos. A menor acoplamiento, mejor programa se obtiene. Hay cinco niveles de acoplamiento, llamados:

·      Acoplamiento de contenido - Cuando un m贸dulo puede acceder, modificar o consultar directamente el contenido de otro m贸dulo hablamos de acoplamiento del nivel de contenido.

·      Acoplamiento com煤n- Cuando m煤ltiples m贸dulos han le铆do y escrito el acceso a alg煤n dato global, hablamos de acoplamiento global o com煤n.

·      Acoplamiento de Control- Dos m贸dulos se denominan acoplados de control si uno de ellos decide la funci贸n del otro o cambia su flujo de ejecuci贸n.

·      Acoplamiento 'stamp'- Cuando m煤ltiples m贸dulos comparten la misma estructura de datos y funcionan en diferentes partes de la misma, hablamos de acoplamiento 'stamp'.

·      Acoplamiento de datos- Se da cuando dos m贸dulos interact煤an entre ellos con la finalidad de pasarse informaci贸n (como par谩metro). Si un m贸dulo pasa una estructura de datos como par谩metro, el m贸dulo receptor debe usar todos sus componentes.

 

No hay un tipo de acoplamiento que se considere el mejor.

 



Fundamentos de Dise帽o

     Fundamentos de Dise帽o

a) Modularidad

El software se divide en componentes con nombres determinados que se denominan m贸dulos. Adem谩s, de que un programa compuesto de un solo m贸dulo no puede ser f谩cilmente manejado intelectualmente. Asimismo, se puede suponer que es m谩s f谩cil resolver problemas complejos cuando se descomponen en trozos m谩s manejables, es decir, que si dividi茅ramos el software indefinidamente el esfuerzo para desarrollarlo ser铆a insignificantemente peque帽o. No obstante, existen otros factores que hacen inv谩lida esta conclusi贸n. Por otro lado,  al modular se debe evitar tanto una excesiva modularizaci贸n, como una pobre.

b) Arquitectura del Software

La arquitectura del software se refiere a:

1.- La estructura jer谩rquica de los componentes procedimentales.

2.- La estructura de los datos.

La arquitectura del software se obtiene mediante un proceso de partici贸n, que relaciona los elementos de una soluci贸n de software con partes de un problema del mundo real definido en el an谩lisis de requisitos. 


Usando alguna de las metodolog铆as de dise帽o del software se producir谩 un determinado tipo de estructura del software.


c) Jerarqu铆a de Control

La jerarqu铆a de control, tambi茅n denominada “estructura del programa”, representa la organizaci贸n de los componentes del programa (m贸dulos). Esto no representa aspectos procedimentales del software, tales como la secuencia de procesos, la ocurrencia u orden de las decisiones o la repetici贸n de operaciones. Para representar la jerarqu铆a de control lo m谩s com煤n es usar un diagrama en forma de 谩rbol.


d) Estructura de Datos.

La estructura de datos es una representaci贸n de la relaci贸n l贸gica existente entre los elementos individuales de datos. Debido a que la estructura de la informaci贸n afectar谩 invariablemente al dise帽o procedimental final, la estructura de datos es tan importante como la estructura del programa en la representaci贸n de la arquitectura del software, puesto que esta dicta la organizaci贸n, los m茅todos de acceso, y las alternativas de procesamiento para la informaci贸n.



e) Procedimientos del Software.

El procedimiento del software se centra sobre los detalles de procesamiento de cada m贸dulo individual. Este debe proporcionar una especificaci贸n precisa del procesamiento, incluyendo la secuencia de procesos, las decisiones y la repetici贸n de operaciones. Adem谩s, la representaci贸n procedimental del software se realiza por capas.


 

Importancia del Dise帽o

Importancia del Dise帽o de Software

El dise帽o de Software juega un papel importante en el desarrollo de software lo cual permite al ingeniero de software producir varios modelos del sistema o producto de que se va a construir el mismo que forman una especie de plan de la soluci贸n de la aplicaci贸n. Estos modelos pueden 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.



BIENVENIDA