pagina principal

El objetivo de el blog 

El objetivo de este blog es mostrar y entender la  importancia  que tiene los requerimientos asi los framework,el modelo entidad relacion los patrones del diseño de software entre otros para comprender acerca de ellos.

Los requerimientos funcionales y no funcionales

Framework de software

El modelo de entidad de relacion

Patrón de diseño

Framework de software

Que es un framework de software:

En la programación de computadoras, un marco de software es una abstracción en la que el software que proporciona una funcionalidad genérica se puede cambiar selectivamente mediante código adicional escrito por el usuario, lo que proporciona software de aplicación específica. 

Un marco de software es: un entorno de software universal, reutilizable que proporciona una funcionalidad particular, como parte de una plataforma de software más grande para facilitar el desarrollo de software de aplicaciones, productos y soluciones. marcos de software pueden incluir programas de apoyo, compiladores, librerías de código, conjuntos de herramientas e interfaces de programación de aplicaciones (API) que reúnen a todos los diferentes componentes para permitir el desarrollo de un proyecto o solución.

API

Marcos contienen características distintivas que los separan de las bibliotecas normales:

• la inversión de control: En un marco, a diferencia de las bibliotecas o las aplicaciones de usuario normales, el flujo general del programa de control no está dictada por la persona que llama, sino por el marco por defecto
• comportamiento: un marco tiene un comportamiento predeterminado. Este comportamiento por defecto debe ser un comportamiento útil y no una serie de no-ops (cita requerida)
• extensibilidad:. Un marco puede ser ampliado por el usuario por lo general por imperiosa selectiva o especializada por código de usuario para proporcionar una funcionalidad específica.
• no modificable código de la arquitectura: El código de la arquitectura, en general, no se supone que debe ser modificado, si bien acepta extensiones implementadas por el usuario. En otras palabras, los usuarios pueden ampliar el marco, pero no deben modificar su código.

Los frameworks suelen incluir:

• Soporte de programas.
• Bibliotecas.
• Lenguaje de scripting.
• Software para desarrollar y unir diferentes componentes de un proyecto de desarrollo de programas.

Los frameworks permiten:

• Facilitar el desarrollo de software.
• Evitar los detalles de bajo nivel, permitiendo concentrar más esfuerzo y tiempo en identificar los requerimientos de software.

¿Qué ventajas tiene utilizar un ‘framework’?

Las que se derivan de utilizar un estándar; entre otras:

• El programador no necesita plantearse una estructura global de la aplicación, sino que el framework le proporciona un esqueleto que hay que “rellenar”.
• Facilita la colaboración. Cualquiera que haya tenido que “pelearse” con el código fuente de otro programador (¡o incluso con el propio, pasado algún tiempo!) sabrá lo difícil que es entenderlo y modificarlo; por tanto, todo lo que sea definir y estandarizar va a ahorrar tiempo y trabajo a los desarrollos colaborativos.
• Es más fácil encontrar herramientas (utilidades, librerías) adaptadas al framework concreto para facilitar el desarrollo.

ventajas

-Reutilización de código que ha sido pre-construido y probado con anterioridad.

Aumentar la fiabilidad de la nueva aplicación y reducir la programación y el esfuerzo de prueba, y el tiempo de comercialización.

-Un marco puede ayudar a establecer mejores prácticas de programación y el uso adecuado de patrones de diseño y nuevas herramientas de programación. Una actualización del marco puede proporcionar nueva funcionalidad, rendimiento mejorado, o una mejor calidad sin necesidad de programación adicional por parte del usuario marco.

-Por definición, un marco que proporciona los medios para extender su comportamiento.

Desventajas

-La creación de un marco es difícil y requiere mucho tiempo (es decir caro).

-La curva de aprendizaje de un nuevo marco puede ser muy altas.

Con el tiempo, puede llegar a ser un marco cada vez más complejo.

                                            Regresar a la pagina principal

Los requerimientos funcionales y no funcionales

¿Que Es El Proceso Unificado de Desarrollo de Software?

Es un proceso de software genérico que puede ser utilizado para una gran cantidad de tipos de sistemas de software, para diferentes áreas de aplicación, diferentes tipos de organizaciones, diferentes niveles de competencia y diferentes tamaños de proyectos.

Principales Elementos

Como RUP es un proceso, en su modelación define como sus principales elementos:

Trabajadores (“quién”): Define el comportamiento y responsabilidades (rol) de un individuo, grupo de individuos, sistema automatizado o máquina, que trabajan en conjunto como un equipo. Ellos realizan las actividades y son propietarios de elementos.

Actividades (“cómo”): Es una tarea que tiene un propósito claro, es realizada por un trabajador y manipula elementos. 

Artefactos (“qué”): Productos tangibles del proyecto que son producidos, modificados y usados por las actividades. Pueden ser modelos, elementos dentro del modelo, código fuente y ejecutables.

Flujo de actividades (“cuándo”): Secuencia de actividades realizadas por trabajadores y que produce un resultado de valor observable. 

Rup

Fases 

Cada fase representa un ciclo de desarrollo en la vida de un producto de software. 

La fase de concepción o inicio: Tiene por finalidad definir la visión, los objetivos y el alcance del proyecto, tanto desde el punto de vista funcional como del técnico, obteniéndose como uno de los principales resultados una lista de los casos de uso y una lista de los factores de riesgo del proyecto. 
La fase de elaboración: Tiene como principal finalidad completar el análisis de los casos de uso y definir la arquitectura del sistema, además se obtiene una aplicación ejecutable que responde a los casos de uso que la comprometen. 

La fase de construcción: está compuesta por un ciclo de varias iteracciones, en las cuales se van incorporando sucesivamente los casos de uso, de acuerdo a los factores de riesgo del proyecto.

La fase de transición:: se inicia con una versión “beta” del sistema y culmina con el sistema en fase de producción.

Tipos de requerimientos

Requerimiento No Funcional:

• Expresa una propiedad o cualidad que el sistema debe presentar
• También restricciones físicas sobre los funcionales

Requerimientos funcionales: 

• Expresa una acción que debe ser capaz de realizar el sistema
• Especifica comportamiento de entrada/salida

Los requerimientos funcionales y no funcionales

¿Que es un requerimiento funcional? 

Se define una función del sistema de software o sus componentes. Una función es descrita como un conjunto de entradas, comportamientos y salida.

pueden ser: cálculos, detalles técnicos, manipulación de datos y otras funcionalidades específicas que se supone, un sistema debe cumplir. Los requerimientos de comportamiento para cada requerimiento funcional se muestran en los casos de uso. 

Requerimientos funcionales

• Los requerimientos funcionales se expresaban en términos de “funciones del sistema”
• Una función del sistema es algo puntual que el sistema debe hacer
• Técnica básica: Si X es una función del sistema, entonces la frase “El sistema debe hacer X” tiene que tener sentido
• Un requerimiento es una condición o capacidad que un sistema debe cumplir

Ejemplo de los requerimientos funcionales

Matriculación

La matrícula será realizada de forma interactiva. Se le preguntará al alumno cuál

es el plan de estudios en que desea matricularse (pueden ser varios).

Se podrá generar una copia impresa de la matrícula (sin valor oficial) en el

ordenador desde donde se realice el proceso de matriculación.

Pago de matrícula:

La aplicación generará un impreso para que el alumno realice el pago

correspondiente a la matrícula en 1 ó 2 plazos (según las fechas

establecidas).

Si el alumno tiene matrículas de honor de cursos anteriores o disfruta de

algún tipo de beca, la aplicación deberá calcular automáticamente los

descuentos correspondientes

Requerimientos no funcionales

¿QUE ES UN REQUERIMIENTO NO FUNCIONAL? 

Es en la ingeniería de sistemas y la ingeniería de software, un requisito que especifica criterios que pueden usarse para juzgar la operación de un sistema en lugar de sus comportamientos específicos, ya que éstos corresponden a los requerimiento . Por tanto, se refieren a todos los requisitos que no describen información a guardar, ni funciones a realizar, sino características de funcionamiento.

Algunos ejemplos de requisitos no funcionales típicos son los siguientes;

• rendimiento
• disponibilidad
• accesibilidad
• usabilidad
• estabilidad
• portabilidad
• costo
• operatividad
• interoperabilidad

Ejemplo: Requerimientos no funcionales

Hardware: El sistema se debe implementar sobre la infraestructura existente en las aulas de prácticas de la E.T.S. Ingeniería Informática.

Software: No existe posibilidad de adquirir licencias de software. La aplicación deberá funcionar sobre Oracle.

  Regresar a la pagina principal

El modelo de entidad de relacion

EL MODELO ENTIDAD RELACIÓN 

¿QUE ES EL MODELO ENTIDAD RELACIÓN?

 Es un diagrama o modelo entidad-relación (a veces denominado por sus siglas en inglés, E-R "Entity relationship", o del español DER "Diagrama de Entidad Relación") es una herramienta para el modelado de datos que permite representar las entidades relevantes de un sistema de información así como sus interrelaciones y propiedades.

 El Modelo Entidad-Relación

•    Se completa el modelo con listas de atributos y una descripción y son muy importantes 

• Permite mostrar resultados entre otras entidades.

• Transformación de relaciones múltiples en binarias.

• Normalización de un proceso  de relaciones (algunas relaciones pueden transformarse en atributos y viceversa).

•  Conversión en tablas alargar  .
• participan entidades y objetos 

  Elementos del modelo entidad-relación

Para poder seguir un ejemplo durante el artículo añadiré ejemplos sobre un taller mecánico, donde se podría crear las siguientes entidades:

•  Coches (objeto físico): contiene la información de cada taller. 

• Empleado (objeto físico): información de los trabajadores. 

• Cargo del empleado (cosa abstracta): información de la función del empleado. 

Atributos 

Los atributos definen o identifican las características de entidad (es el contenido de esta entidad). . Estos atributos pueden ser de distintos tipos (numéricos, texto, fecha...).

 Unos posibles atributos serían los siguientes:

• Número de chasis
• Matrícula 
• Marca
• Modelo y muchos otros que complementen la información de cada coche.

Los atributos se representan como círculos que descienden de una entidad, y no es necesario representarlos todos, sino los más significativos, como a continuación.

 Relación

Es un vínculo que nos permite definir una dependencia entre varias entidades, una relación entre entidad y objeto. Las relaciones se muestran en los diagramas como rombos, que se unen a las entidades mediante líneas. 

TIPOS DE RELACIÓN

Podemos encontrar distintos tipos de relaciones según como participen en ellas las entidades. Es decir, en el caso anterior cada empleado puede tener un cargo, pero un mismo cargo lo pueden compartir varios empleados.

 Uno a uno: Una entidad se relaciona únicamente con otra y viceversa. Por ejemplo, si tuviésemos una entidad con distintos chasis y otra con matrículas deberíamos de determinar que cada chasis solo puede tener una matrícula (y cada matrícula un chasis, ni más en ningún caso).

   Uno a varios o varios a uno: determina que un registro de una entidad puede estar relacionado con varios de otra entidad, pero en esta entidad existir solo una vez. Como ha sido en el caso anterior del trabajador del taller.

   

 Varios a varios: determina que una entidad puede relacionarse con otra con ninguno o varios registros y viceversa. Por ejemplo, en el taller un coche puede ser reparado por varios mecánicos distintos y esos mecánicos pueden reparar varios coches distintos.

NOTA:Todas estas relaciones son importantes porque nos permiten una percepción del mundo real 

Regresar a la pagina principal

Patrón de diseño

Que es un patrón de diseño:

Los patrones de diseño son la base para la búsqueda de soluciones a problemas comunes en el desarrollo de software y otros ámbitos referentes al diseño de interacción o interfaces.

Para que una solución sea considerada un patrón debe poseer ciertas características. Una de ellas es que debe haber comprobado su efectividad resolviendo problemas similares en ocasiones anteriores. Otra es que debe ser reutilizable, lo que significa que es aplicable a diferentes problemas de diseño en distintas circunstancias.

Que es un patrón de arquitectura:
Los patrones arquitectónicos, o patrones de arquitectura, también llamados arquetipos ofrecen soluciones a problemas de arquitectura de software en ingeniería de software. Dan una descripción de los elementos y el tipo de relación que tienen junto con un conjunto de restricciones sobre cómo pueden ser usados. Un patrón arquitectónico expresa un esquema de organización estructural esencial para un sistema de software, que consta de subsistemas, sus responsabilidades e interrelaciones. En comparación con los patrones de diseño, los patrones arquitectónicos tienen un nivel de abstracción mayor.

Objetivos de los patrones

Los patrones de diseño pretenden:

• Proporcionar catálogos de elementos reusables en el diseño de sistemas software.
• Evitar la reiteración en la búsqueda de soluciones a problemas ya conocidos y solucionados anteriormente.
• Formalizar un vocabulario común entre diseñadores.
• Estandarizar el modo en que se realiza el diseño.
• Facilitar el aprendizaje de las nuevas generaciones de diseñadores condensando conocimiento ya existente.

Asimismo, no pretenden:

• Imponer ciertas alternativas de diseño frente a otras.
• Eliminar la creatividad inherente al proceso de diseño. 

Categorías de patrones

Según la escala o nivel de abstracción:

• Patrones de arquitectura: Aquellos que expresan un esquema organizativo estructural fundamental para sistemas de software.
• Patrones de diseño: Aquellos que expresan esquemas para definir estructuras de diseño (o sus relaciones) con las que construir sistemas de software.
• Dialectos: Patrones de bajo nivel específicos para un lenguaje de programación o entorno concreto.

Estructuras o plantillas de patrones. Para describir un patrón se usan plantillas más o menos estandarizadas, de forma que se expresen uniformemente y puedan constituir efectivamente un medio de comunicación uniforme entre diseñadores. Varios autores eminentes en esta área han propuesto plantillas ligeramente distintas, si bien la mayoría definen los mismos conceptos básicos. 

La plantilla más común es la utilizada precisamente por el GoF y consta de los siguientes apartados:

• Nombre del patrón: nombre estándar del patrón por el cual será reconocido en la comunidad (normalmente se expresan en inglés).
• Clasificación del patrón: creacional, estructural o de comportamiento.
• Intención: ¿Qué problema pretende resolver el patrón?
• También conocido como: Otros nombres de uso común para el patrón.
• Motivación: Escenario de ejemplo para la aplicación del patrón.
• Aplicabilidad: Usos comunes y criterios de aplicabilidad del patrón.
• Estructura: Diagramas de clases oportunos para describir las clases que intervienen en el patrón.

Existen cuatro tipos de patrones:

• Patrones creacionales
• Patrones estructurales
• Patrones de comportamiento
• Patrones de arquitectura

Dominios en el diseño de Patrones

Control de acceso. Hay muchas situaciones en las cuales el acceso a datos, características y funcionalidad son limitadas a la definición de los usuarios.

Concurrencia. Muchas aplicaciones deben manejar múltiples tareas de forma que simule el paralelismo. Hay muchas formas de manejar esta concurrencia y cada una puede ser presentada por un patrón arquitectónico diferente.

Distribución. El problema de distribución dirige el problema de forma en que los sistemas o componentes se comunican con otros en un entorno distribuido.

Persistencia. Los datos persistentes son almacenados en bases de datos o archivos y pueden ser leídos o modificados por otros procesos más adelante.

PATRONES DE ARQUITECTURA VS. PATRONES DE DISEÑO

Si queremos creer que realmente existe diferencia, entonces es fácil verla midiendo el impacto al aplicar el patrón: si este es relevante a la totalidad del sistema entonces hablamos de un patrón de arquitectura; en cambio, si este sólo concierne a un subcomponente, nos referimos a un patrón de diseño.

Tomen como caso el patrón de Layers , este es claramente un patrón arquitectónico, ya que concierne al diseño general de la aplicación. Mientras que el patrón Active Record , que lidia con los mecanismos de persistencia de datos es un patrón de diseño.

Pero, qué pasa cuando lo que era totalidad se vuelve un subcomponente?. Cambiarían entonces sus patrones de arquitectura a diseño?. Aquí es donde no es tan fácil la respuesta.

Hay otros patrones que solapan responsabilidades de todo-parte, por ejemplo el MVC . Según como se aplique puede ser un patrón de diseño o arquitectura.

Regresar a la pagina principal