La descarga está en progreso. Por favor, espere

La descarga está en progreso. Por favor, espere

Daniel Correa Botero José López Vélez Universidad de Antioquia 2013-II.

Presentaciones similares


Presentación del tema: "Daniel Correa Botero José López Vélez Universidad de Antioquia 2013-II."— Transcripción de la presentación:

1 Daniel Correa Botero José López Vélez Universidad de Antioquia 2013-II

2 Especificación del software Desarrollo del software Validación del software Evolución del software Ing. del software - Ian Sommerville Entrevistas – Plantillas – Modelo del dominio – Casos de uso – Req funcionales y no funcionales – Etiquetado – Objetivos – Diagrama de clases – Modelo entidad relación – Diagramas estructurales y de comportamiento (UML). (Diseño e implementación) Arquitectura del software – diagramas UML - patrones de arquitectura - patrones de diseño – patrones grasp y gof – frameworks – artefactos – componentes – librerías. (Diseño e implementación) Arquitectura del software – diagramas UML - patrones de arquitectura - patrones de diseño – patrones grasp y gof – frameworks – artefactos – componentes – librerías.

3 Especificación del software Desarrollo del software Validación del software Evolución del software Administrador de bases de datos Administrador de bases de datos Analista Programador DiseñoImplementación Diseñador o arquitecto del software Ingeniero en seguridad Ingeniero en pruebas - testing Nota: en algunos casos el programador terminando cumpliendo el rol de: analista, arquitecto, testing, etc. Gerente de proyectos

4

5 La primera etapa del diseño e implementación del software es llamada diseño arquitectónico. Comprende el establecimiento de un marco de trabajo estructural básico para un sistema (patrón de organización del sistema). Sirve para identificar los principales componentes de un sistema y la comunicación entre estos.

6 Permite conocer si el sistema podrá cumplir reglas del negocio y requisitos críticos tales como rendimiento, seguridad, adaptabilidad, fiabilidad y mantenibilidad. Toda esta etapa es llevada a cabo por el arquitecto de software. Nota: en algunos casos no existe el arquitecto de software. Las decisiones son tomadas entre los analistas o por un analista líder. Incluso a veces no se realiza documentación adicional de la parte del diseño arquitectónico.

7 Diseño de arquitectura Implementación

8 ¿Existe una arquitectura de aplicación genérica que pueda actuar como una plantilla para el sistema que se está diseñando?. ¿Qué estilo o estilos arquitectónicos son apropiados para el sistema?. ¿Cómo debería documentarse la arquitectura del sistema?. ¿Cómo se descompondrán en módulos las unidades estructurales del sistema?. ¿Patrones de arquitectura? ¿Frameworks? ¿Qué sucede si desean realizar modificaciones con otra empresa o desarrollador? ¿Cómo vamos a sincronizar la información de los pagos? ¿Cómo sacar la información de la temperatura de la caldera? ¿Qué lenguaje de programación utilizar? La clave para responder todas estas preguntas es: la experiencia.

9 El resultado es un documento de diseño arquitectónico. Incluye representaciones graficas del sistema junto con texto descriptivo asociado. Debería describir como se divide el sistema en subsistemas y como se divide cada subsistema en módulos. Existen múltiples forma de desarrollo de un documento de diseño arquitectónico. Puede ser: utilizando notación UML, diagramas de procesos, interfaces, diseño orientados a objetos, entre otros. Nota: la evaluación de un sistema arquitectónico es muy difícil debido a que consiste en averiguar el grado de satisfacción de los requisitos funcionales y no funcionales especificados anteriormente, y para esto se debe implementar el software.

10

11

12

13 Diagrama de robustez de Jacobson

14 Ejemplo de un mapa de navegación.

15 Arquitecturas centradas de datos. Algunas veces llamado Blackboard. En el centro de esta arquitectura se encuentra un almacén de datos (por ejemplo, un documento o una base de datos) al que otros componentes acceden con frecuencia para actualizar, añadir, borrar o bien modificar los datos del almacén. Hearsay Speech Understanding ftp://shelob.cs.umass.edu/pub/Erman_Hearsay80.pdf

16 Arquitecturas centradas de datos. Adobe Acrobat Capture (OCR) (ahora descontinuada) uso un sistema Blackboard para descomponer y reconocer páginas de imágenes para entender los objetos, el texto y las fuentes en la página. Uno de los componentes principales del sistema de misión de control de RADARSAT-1 utilizó la arquitectura Blackboard. cations/2007/2007-Rudenko-Borisov-RTU.pdf Muy utilizada en sistemas expertos, visión artificial, interpretación sensorial.

17 Arquitecturas de flujo de datos. Esta arquitectura se aplica cuando los datos de entrada son transformados a través de una serie de componentes computacionales o manipulativos en los datos de salida. Típicamente usada en procesamiento de señales y transformación de flujos de datos.

18 Arquitecturas orientadas a objetos. Los componentes de un sistema encapsulan los datos y las operaciones que se deben realizar para manipular los datos. La comunicación y la coordinación entre componentes se consigue a través del paso de mensajes. Arquitecturas estratificadas (por capas). Se crean diferentes capas y cada una realiza operaciones diferentes. La ventaja principal de este estilo es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sobrevenga algún cambio, sólo se ataca al nivel requerido sin tener que revisar entre código mezclado.

19 En el desarrollo de software de casi todas las aplicaciones es necesario solucionar una y otra vez los mismos problemas: autenticación del usuario, persistencia de datos, separación de la capa de presentación, lógica, control, etc. En lugar de reinventar la rueda es mas conveniente aplicar estrategias que ya hayan funcionado con anterioridad. Ventajas: ya están probados, son reutilizables, reducen notablemente el esfuerzo y las líneas de código.

20 Para algunos autores existe una sutil diferencia entre tipos de arquitectura (o estilos de arquitectura) y patrones de arquitectura. Diciendo que un estilo de arquitectura es una manera conceptual como se creará o trabajará el sistema, mientras que un patrón de arquitectura describe una solución para la aplicación de un estilo de arquitectura a nivel de subsistemas o módulos y sus relaciones. Para otros autores son conceptos similares. Figura patrón mvc A Practical Guide to Enterprise Architecture (The Coad Series) es%5Cjava%5CPGEArchitecture.pdf

21 El Modelo: Es la representación de la información con la cual el sistema opera, por lo tanto gestiona todos los accesos a dicha información, tanto consultas como actualizaciones, implementando también los privilegios de acceso que se hayan descrito en las especificaciones de la aplicación (lógica de negocio). En los frameworks actuales normalmente representa una entidad del diagrama entidad-relación. Ejemplo de una parte del modelo user en php.

22 La Vista: presenta el modelo (información y lógica de negocio) en un formato adecuado para que un usuario pueda interactuar (usualmente la interfaz de usuario). Ejemplo de una vista creada en html y smarty.

23 El controlador: es el intermediario entre la vista y el modelo, su función consiste en controlar el flujo de datos, responder a eventos (usualmente provocados por los usuarios) e invocar peticiones al modelo. Ejemplo de un controlador en php.

24 Un patrón de diseño es una solución reutilizable general a un problema que ocurre comúnmente en un contexto determinado en el diseño de software. Los patrones de diseño se encuentran en el dominio de los módulos y las interconexiones. Dominios de mas bajo nivel que los patrones de arquitectura. Los patrones de diseño son generalmente asociados con aspectos comunes a nivel de código.

25 Es un marco (un esqueleto, un patrón) para el desarrollo y/o la implementación de una aplicación. Ventajas: - Mayor seguridad, agrupa prácticas y criterios para solucionar problemas comunes. - Reutilización de código (no hay que reinventar la rueda). - Acceso a tutoriales y documentación sobre como crear aplicaciones. - El programador no necesita plantearse una estructura global de la aplicación, sino que el framework le proporciona un esqueleto que hay que "rellenar".

26 Poseen un árbol de carpetas estructurado. Poseen patrones de diseño y de arquitectura integrados. Poseen componentes y librerías pre- instaladas que facilitan la programación. Evolucionan continuamente para adaptarse a las nuevas necesidad o corregir errores de versiones anteriores.

27 Tipos de documentación Patterns. [9] Example-based learning. [7] Cookbooks. [10] Visualization. [11] Yii - Error Handling Yii - URL Management Yii - Data Caching Codeigniter - Error Handling Codeigniter - URI Routing Codeigniter - Caching Ruby on rails - Exception Handling Ruby on rails - Rails routes Ruby on rails - Caching Yii - Error Handling Yii - URL Management Yii - Data Caching Codeigniter - Error Handling Codeigniter - URI Routing Codeigniter - Caching Ruby on rails - Exception Handling Ruby on rails - Rails routes Ruby on rails - Caching Componentes

28 How to define a controller How to call views How to call model classes How to handle errors

29 13 componentes principales identificados, algunas tareas definidas para cada componente. Learning of web application frameworks components - Identify how to create controller classes and what functions should be override. - Identify how to call model classes. - Identify how to call libraries or plugins. - Identify how to call views. - Identify how to receive data from views. - Identify how to do redirects. - Identify how to create controller classes and what functions should be override. - Identify how to call model classes. - Identify how to call libraries or plugins. - Identify how to call views. - Identify how to receive data from views. - Identify how to do redirects.

30 Proyectos desechados poco tiempo después de ser entregados. El mantenimiento se convierte en una tarea casi imposible. Grandes sobrecostos por incluir funcionalidades adicionales. Proyectos con mala calidad y poca fiabilidad.

31

32 Learning UML 2.0 OReilly Software Modeling & desing. UML, use cases, patterns, & software architectures. Hassan Gomma Ingenieria del software. 7th edición. Ian Somerville UML y patrones. Craig Larman Ingeniería del software. Un enfoque practico 5ta edición. Roger S. Pressman Use Case Driven Object Modeling with UML, Theory and Practice. Doug Rosenberg


Descargar ppt "Daniel Correa Botero José López Vélez Universidad de Antioquia 2013-II."

Presentaciones similares


Anuncios Google