AHORRE TIEMPO Y DINERO
CREAD-CASANARE www.remington.edu.co
Carreras Profesionales
ESTUDIE CON NOSOTROSY SEA PROFESIONAL EN MENOS DE 5 AÑOS Programación por créditos académicos
Administración de Negocios Internacionales
Técnicas Profesionales Contaduría Pública Secretariado ejecutivo Ingeniería de Sistemas Turismo
Tecnologías
Contabilidad sistematizada
Agroindustrial
Gestión Pública
Gestión Logística
Costos y Presupuestos
“La mejor opción en educación”
Sede administrativa: Cll 13 No 16-08 Brr. La Corocora Tels:6323232 6340401 Cel.3112327218 E-mail: Futcasanare@yahoo.com Página Web: www.futcasanare.com.co
INTRODUCCIÓN El concepto de arquitectura de software se refiere a la estructuración del sistema que se crea en etapas tempranas del desarrollo. Esta estructuración representa un diseño de alto nivel del sistema que principalmente tiene dos propósitos: satisfacer los atributos de calidad (desempeño, seguridad, modificabilidad), y servir como guía en el desarrollo. La arquitectura de software es de especial importancia ya que es la manera en que se estructura un sistema y tiene un impacto directo sobre la capacidad de este para satisfacer lo que se conoce como los atributos de calidad del sistema.
¿Por qué es importante la arquitectura de software? La arquitectura de software es de especial importancia ya que la manera en que se estructura un sistema tiene un impacto directo sobre la capacidad de este para satisfacer lo que se conoce como los atributos de calidad del sistema. Ejemplos de atributos de calidad son el desempeño, que tiene que ver con el tiempo de respuesta del sistema a las peticiones que se le hacen, la usabilidad, que tiene que ver con qué tan sencillo les resulta a los usuarios realizar operaciones con el sistema, o bien la modificabilidad, que tiene que ver con qué tan simple resulta introducir cambios en el sistema. Los atributos de calidad son parte de los requerimientos (no funcionales) del sistema y son características que deben expresarse de forma cuantitativa. No tiene sentido, por ejemplo, decir que el sistema debe devolver una petición “de manera rápida”, o presentar una página “ligera”, ya que no es posible evaluar objetivamente si el sistema cubre o no esos requerimientos.
El ciclo de desarrollo de la arquitectura
arquitectura, estos son los requerimientos funcionales primarios y las restricciones.
Dentro de un proyecto de desarrollo, e independientemente de la metodología que se utilice, se puede hablar de “desarrollo de la arquitectura de software”. Este desarrollo, que precede a la construcción del sistema, esta dividido en las siguientes etapas: requerimientos, diseño, documentación y evaluación. Cabe señalar que 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. A continuación se describen dichas etapas. • Requerimientos La etapa de requerimientos se enfoca en la captura, documentación y priorización de requerimientos que influencian la arquitectura. Como se mencionó anteriormente, los atributos de calidad juegan un papel preponderante dentro de estos requerimientos, así que esta etapa hace énfasis en ellos. Otros requerimientos, sin embargo, son también relevantes para la
• Diseño La etapa de diseño es la etapa central en relación con la arquitectura y probablemente la más compleja. Durante esta etapa se definen las estructuras que componen la arquitectura. La creación de estas estructuras se hace en base a patrones de diseño, tácticas de diseño y elecciones tecnológicas. El diseño que se realiza debe buscar ante todo satisfacer los requerimientos que influencian a la arquitectura, y no simplemente incorporar diversas tecnologías porque están “de moda”. • Documentación Una vez creado el diseño de la arquitectura, es necesario poder comunicarlo a otros involucrados dentro del desarrollo. La comunicación exitosa del diseño muchas veces depende de que dicho diseño sea documentado de forma apropiada. La documentación de una arquitectura involucra la representación de varias de sus estructuras que son representadas a través de
distintas vistas. Una vista generalmente contiene un diagrama, además de información adicional, que apoya en la comprensión de dicho diagrama. • Evaluación Dado que la arquitectura de software juega un papel crítico en el desarrollo, es conveniente evaluar el diseño una vez que este
QUE ES UML?
ha sido documentado con el fin de identificar posibles problemas y riesgos. La ventaja de evaluar el diseño es que es una actividad que se puede realizar de manera temprana (aún antes de codificar), y que el costo de corrección de los defectos identificados a través de la evaluación es mucho menor al costo que tendría el corregir estos defectos una vez que el sistema ha sido construido.
Lenguaje unificado de modelado (UML). Un lenguaje proporciona un vocabulario y unas reglas para permitir una comunicación. En este caso, este lenguaje se centra en la representación gráfica de un sistema. Este lenguaje nos indica cómo crear y leer los modelos, pero no dice cómo crearlos. Esto último es el objetivo de las metodologías de desarrollo. UML se puede usar para modelar distintos tipos de sistemas: sistemas de software, sistemas de hardware, y organizaciones del mundo real. UML ofrece nueve diagramas en los cuales modelar sistemas. • Diagramas de Casos de Uso. •Diagramas de Secuencia y de Colaboración • Diagramas de Estado. • Diagramas de Actividades. • Diagramas de Clases. • Diagrama Entidad Relación
• Diagramas de Componentes. • Diagramas de Implementación. UML es una consolidación de muchas de las notaciones y conceptos más usados orientados a objetos. Empezó como una consolidación del trabajo de Grade Booch, James Rumbaugh, e Ivar Jacobson, creadores de tres de las metodologías orientadas a objetos más populares.
Objetivos del Lenguaje Unificado de Modelado:
Visualizar: UML permite expresar de una forma gráfica un sistema de forma que otro lo puede entender. Especificar: UML permite especificar cuáles son las características de un sistema antes de su construcción. Construir: A partir de los modelos especifica-dos se pueden construir los sistemas diseñados. Documentar: Los propios elementos gráficos sirven como documentación del sistema desarrollado que pueden servir para su futura revisión. Además el lenguaje de modelado unificado, nos
ofrece tres bloques de construcción, los cuales nos permiten desarrollar los diferentes sistemas para saber cómo se va implementar y obtener un producto final. A continuación menciono los tres bloques: Elementos: Los elementos son abstracciones de cosas reales o ficticias; como por ejemplo los objetos, acciones etcétera. Relaciones: relacionan los elementos entre sí. Diagramas: Son colecciones de elementos con sus relaciones.
Modelo UML 2.0
Arquitectónico
en
UML 2.0 introduce nuevos conceptos y redefine otros presentes en sus versiones anteriores que desde el punto de vista arquitectónico son relevantes, a saber (Iver, Clements, Garlan, Nord, Schmerl y oviedo, 2004). Se toma como modelo estándar donde se toman diferentes componentes como por ejemplo las interfaces, puertos, diagramas, conectores, componentes, fases, etcétera. Además este modelo se base en la arquitectura para mostrar calidad software, por tal motivo se conoce como uno de
los modelos más eficientes para diseñar, desarrollar e implementar.
Cada una de ellas nos ofrece diferente información sobre el sistema software:
Estándares UML
Superestructura: Es la especificación que usamos a diario. En esta se encuentra todos los diagramas. Infraestructura: Están conceptos de bajo nivel-Meta-Modelos. OCL: Lenguaje de restringió. Se utiliza para especificar conceptos ambiguos. XMI: Intercambio de Diagramas: Se enfoca en los diagramas donde se pueden compartir. Arquitectura UML
El lenguaje unificado de modelado hace que esta sea algo tangible. Siendo el resultado de agrupar los diferentes diagramas en lo que llamamos vistas. Estas vistas forman la Arquitectura del Sistema.
Vista de Casos de Uso: Nos facilita información sobre el comportamiento y funcionalidad del sistema. Vista de Diseño: Nos proporciona información del vocabulario y la funcionalidad del sistema. Vista de Interacción: Nos da información sobre el rendimiento del sistema, la escalabilidad del mismo y la capacidad de procesamiento necesaria. Vista de Implementación: Establece el ensamblado del sistema y la gestión de la configuración. Vista de Despliegue: Nos permite establecer la topología del sistema, su distribución y las pautas para su instalación.
Algunos tipos de diagramas
A continuaci贸n podr谩s ver algunas im谩genes referentes a los diferentes diagramas, y posterior encontraras una tabla con la informaci贸n de cada uno de los diagramas de UML.
Diagrama de Casos de Uso
Diagrama de Clases
Diagrama de Secuencia
REGLAS DE NEGOCIO Esta capa es la encargada de procesar y validar las reglas de negocio, actúa como un servidor para la capa de presentación y traslada las solicitudes de esta a la capa de datos actuando como cliente de la misma. Así mismo funciona de la forma inversa. Las reglas de negocios son el puente entre el usuario y los servicios de los datos. Además estas reglas de negocios (business rules) son políticas que controlan el flujo de tareas.
El nivel de nivel de servicios de negocios es responsable de:
Recibir la entrada de la presentación Interactuar con los servicios de datos para ejecutar las operaciones de negocios para los que la aplicación fue diseñada a automatizar. Enviar el resultado procesado a nivel de presentación.
Servicios DNA para la capa de negocios:
Servicios Web a través de Microsoft internet information server (IIS) Transacciones y servicios de componentes, Microsoft transaction server (MTS) Servicios asincrónicos, Microsoft message queue server (MSMQ) Server- side scripting, via active server pages (ASP)
Principios: El proyecto debe ser orientado al usuario, no al desarrollador El proyecto debe tener contenido ético. El proyecto debe tener simplicidad, sencillez y minimalismo tanto en diseño gráfico como en usabilidad y contenidos. El proyecto debe ser estético y atractivo visualmente. El proyecto debe transmitir emociones. El proyecto debe tener herramientas y contenidos más actuales. El proyecto debe permitir interactividad entre el receptor el mensaje y la fuente. El proyecto debe tener enfoque global.
ALGUNOS MODELOS DE DESARROLLO DE SOFTWARE MODELO ESPIRAL
El
MODELO en espiral, propuesto originalmente por BOEHM en 1976, es un modelo de proceso de software evolutivo donde se conjuga la naturaleza de construcciรณn de prototipos con los aspectos controlados y sistemรกticos del MODELO LINEAL y SECUENCIAL. Proporciona el potencial para el desarrollo rรกpido de versiones incrementales del software que no se basa en fases claramente definidas y separadas para crear un sistema. http://modeloespiral.blogspot.com/
MODELO DRA
MODELO DE DESARROLLO RAPIDO DE APLICACIONES El desarrollo rápido de aplicaciones o RAD (Rapid Application Development) es un proceso de desarrollo de software, desarrollado inicialmente por James Martin en 1980. El método comprende el desarrollo iterativo, la construcción de prototipos y el uso de utilidades CASE. Tradicionalmente, el desarrollo rápido de aplicaciones tiende a englobar también la usabilidad, utilidad y la rapidez de ejecución. El Desarrollo Rápido de Aplicaciones (DRA) (Rapid Application Development RAD) es un modelo de proceso del desarrollo del software lineal secuencial que enfatiza un ciclo de desarrollo extremadamente corto. DRA es una adaptación a "Alta velocidad" en el que se logra el desarrollo rápido utilizando un enfoque de construcción basado en componentes. Si se comprenden bien los requisitos y se limita el ámbito del proyecto, el proceso DRA permite al equipo de desarrollo crear un "sistema completamente funcional" dentro de periodos cortos de tiempo. http://curiosisimos.files.wordpress.com/2009/12/modelo-de-desarrollo-rapidode-aplicaciones.pdf
MODELO EN CASCADA
Existen ocasiones en que los requisitos de un problema se entienden de una manera razonable: cuando el trabajo fluye desde la comunicación a través del despliegue de una manera casi lineal. Esta situación se encuentra a veces cuando es necesario hacer adaptaciones o mejorías bien definidas a un sistema existente (por ejemplo, una adaptación a un software contable debido a los cambios en las regulaciones del gobierno).Esto puede ocurrir también en un número limitado de proyectos de nuevos desarrollos, pero sólo cuando los requerimientos están bien definidos y son estables en forma razonable. Otros modelos de desarrollo de software los podemos encontrar en la siguiente pagina:http://es.scribd.com/doc/19162245/Unidad-5-Modelo-DesarrolloSoftware
deseamos tocar (DECORATOR) o que objetos establezcan comunicación unidireccional con otros sin conocer de su existencia (OBSERVER). Un patrón de software es una técnica de diseño de software que
Entre los más destacados están:
soluciona una clase de problemas concretos.
PATRÓN DELEGADO. El patrón de diseño de delegación es una técnica en la que un objeto de cara al exterior expresa cierto comportamiento pero en
Muchas veces nos encontramos frente al mismo problema una y otra vez, y optamos por soluciones distintas, perdiendo tiempo de desarrollo en encontrar una
realidad delega la responsabilidad de implementar dicho comportamiento a un objeto asociado en una relación inversa de responsabilidad.
solución. Además, como no la hemos “guardado”, puede que olvidemos esa solución y que la siguiente vez que nos encontremos ese problema, tengamos que volver a realizar todo el proceso de nuevas. PATRÓN COMPUESTO. Por ejemplo, permiten tener una solución a la falta de herencia de implementación múltiple en lenguajes que no la soportan (COMPOSITE), modificar funcionalidad a código que no
El patrón Composite sirve para construir objetos complejos a partir de otros más simples y similares entre sí, gracias a la composición recursiva y a una estructura en forma de árbol.
Esto simplifica el tratamiento de los
referencien unos a otros de
objetos creados, ya que al poseer
forma explícita. Permite
todos ellos una interfaz común, se
variar la interacción sin tocar
tratan todos de la misma manera.
los objetos, por tanto favorece la reutilización.
PATRÓN DECORADOR. El patrón Decorator responde a la necesidad de añadir dinámicamente funcionalidad
PATRÓN ITERADOR.
a un Objeto. Esto nos permite
En diseño de software,
no tener que crear sucesivas
el patrón de diseño Iterador,
clases que hereden de la
define una interfaz que
primera incorporando la
declara los métodos
nueva funcionalidad, sino
necesarios para acceder
otras que la implementan y
secuencialmente a un grupo
se asocian a la primera.
de objetos de una colección. Algunos de los métodos que podemos definir en la interfaz Iterador son: Primero(), Siguiente(), HayMas() y ElementoActual(). Este patrón de diseño
PATRÓN INTERMEDIARIO.
permite recorrer una
Es el especialista que define
estructura de datos sin que
las interdependencias entre
sea necesario conocer la
ellos. Favorece un bajo
estructura interna de la
acoplamiento, ya que evita
misma.
que los objetos se
PATRÓN MODELO VISTA – CONTROLADOR.
El Modelo Vista Controlador (MVC) es un patrón de arquitectura de software que separa PATRÓN OBSERVADOR.
los datos y la lógica de
Observador es un patrón de
negocio de una aplicación de
diseño que define una
la interfaz de usuario y el
dependencia del tipo uno-a-
módulo encargado de
muchos entre objetos, de
gestionar los eventos y las
manera que cuando uno de
comunicaciones.
los objetos cambia su estado, notifica este cambio a todos los dependientes. Se trata de un patrón de comportamiento (existen de 3 tipos: Creación, Estructurales y de Comportamiento), es decir, está relacionado con algoritmos de funcionamiento y asignación de responsabilidades a clase s y objetos.
PATRÓN DATA ACCESS
para la organización y desarrollo
OBJECT.
de software. Típicamente, puede
Un Data Access
incluir soporte
Object (DAO, Objeto de
de programas, bibliotecas, y
Acceso a Datos) es un
un lenguaje interpretado, entre otras
componente de software que
herramientas, para así ayudar a
suministra
desarrollar y unir los diferentes
una interfaz común entre la
componentes de un proyecto.
aplicación y uno o más
Representa una arquitectura
dispositivos de
de software que modela las
almacenamiento de datos,
relaciones generales de las
tales como una Base de
entidades del dominio, y provee una
datos o un archivo.
estructura y una especial metodología de trabajo, la cual extiende o utiliza las aplicaciones del dominio. Los Objetivos principales que persigue un framework son:
Acelerar el proceso de Desarrollo.
Reutilizar Código ya existente.
Promover buenas Prácticas de Desarrollo como lo son los Patrones.
En el desarrollo de software, un framework o infraestructura digital, es una estructura conceptual y tecnológica de soporte definido, normalmente con artefactos o módulos de software concretos, que puede servir de base