S. Santana Ambriz INTRODUCCIÓN El reciente aumento de aplicaciones en donde se utiliza la computadora ha sido posible debido a un hardware de bajo costo, por lo cual la demanda de software ha crecido de forma exponencial. Esto implica que son necesarias técnicas y tecnología eficientes de Ingeniería de Software para resolver los múltiples problemas que se derivan de las aplicaciones en donde se desarrollan sistemas software de gran tamaño. La Ingeniería de Software implica seguir en cualquier proyecto de software una metodología de desarrollo y la utilización de distintas técnicas y herramientas. Los diferentes procedimientos a seguir en cualquier proyecto de Ingeniería de software son: Definición de requerimientos, Análisis, Diseño, Verificación y Validación (Pruebas de Calidad del Software), Pruebas y Mantenimiento. OBJETIVO GENERAL Diseñar y construirá un proyecto de software conforme a los requerimientos establecidos en el dominio del proyecto de software tomando como en cuenta los estándares actuales y las mejores prácticas en el desarrollo del mismo. 1. CONCEPTOS INTRODUCTORIOS. 1.1 LA ARQUITECTURA “4+1”. La descripción correcta detallada de la arquitectura de los sistemas informáticos resulta muy importante para lograr éxito en el desarrollo de los mismos. Los almacenes de datos como solución informática que apoya la toma de decisiones en las entidades que los implementan también necesitan una descripción detallada de la arquitectura. Ralph kimball propone los aspectos a tener en cuenta para la descripción pero no expone con que realizarla. Existen modelos específicos para describir la arquitectura como es el 4 + 1 vistas de Kruchten pero no se ajusta a las necesidades de descripción que requiere un almacén de datos. S. Santana Ambriz Entre dichas vistas se encuentran: La Vista Lógica: En esta vista se ha de representar lo que el sistema debe hacer, y las funciones y servicios que ofrece. Vista de Despliegue: En esta vista se va a mostrar cómo está dividido el sistema software en componentes y las dependencias que hay entre esos componentes. Vista de Procesos: En esta vista se tiene que mostrar el flujo de trabajo paso a paso de negocio y operacionales de los componentes que conforman el sistema. Vista Física: En esta vista se muestra desde la perspectiva de un ingeniero de sistemas todos los componentes físicos del sistema así como las conexiones físicas. “+1” Vista de Escenarios: Esta vista va a ser representada por los casos de uso software y va a tener la función de unir y relacionar las otras 4 vistas. 1.2 DESARROLLO ORIENTADO A OBJETOS. El enfoque de orientación a objetos es una forma de observar la realidad. El enfoque como su nombre lo indica se basa en el concepto de objeto. Es todo aquello que tiene características que lo hacen único e indivisible dentro del entorno al que pertenece. Siempre es posible establecer propiedades o atributos de un objeto, lo mismo que su grado de respuesta a estímulos externos (comportamientos del objeto). El uso de Análisis orientado a objetos puede facilitar mucho la creación de prototipos, y las técnicas de desarrollo evolutivo de software. Los objetos son inherentemente reutilizables, y se puede crear un catálogo de objetos que podemos usar en sucesivas aplicaciones. Un lenguaje orientado a objetos por varios autores tiene tres características básicas: – basado en objetos – basado en clases – capaz de tener herencia de clases. El elemento fundamental de la OOP es, como su nombre lo indica, el objeto. Los Programadores lo definen como un conjunto complejo de datos y programas que poseen estructura y forman parte de una organización. Esa definición especifica varias propiedades importantes de los objetos. S. Santana Ambriz 1.3 DIAGRAMACION La diagramación es una de las principales herramientas para el desarrollo de un sistema porque con ellos somos capaces de analizar, diseñar, desarrollar e hasta implementar el sistema, por tal motivo son esenciales para el desarrollo de un sistema desde el inicio del mismo. La diagramación es un proceso aparentemente sencillo, pero su complejidad radica en que de ella depende que haya una fácil lectura, que el cuerpo del texto sea correcto y proporcionado, que las imágenes sean comprensibles y concuerden con el texto o la información que están apoyando, entre otras cosas. 2.1 DISEÑO DEL SISTEMA EN BASE A PROCESOS Todo el sistema tiene que estar desarrollado a través de procesos para su buen diseño y que el sistema se encuentre bien realizado y concluido para que a través de la buena diagramación realizada anteriormente se pueda implementar para el diseño del mismo. 2.1.1 ACTIVIDADES Y CASOS DE USO. Un modelo de caso de uso describe lo que hace un sistema sin describir cómo lo hace, es como un modelo lógico del sistema solamente lo que se ocupa sin descripción especifica de lo que realiza. Los diagramas de casos de uso pueden llegar a ser bastante grandes siempre y cuando se agregue valor al esfuerzo global. El hecho es que se puede llegar a crear un modelo de gran tamaño que describe los requisitos para un sistema, y puede incluir un modelo de casos de uso general que se han creado durante meses o años de trabajo. No deben ser creados todos por adelantado antes de empezar a programar. . 2.1.2 INTERFAZ DE USUARIO La interfaz de usuario UI2 es la parte del software con el que un usuario interactúa directamente. Un prototipo de interfaz de usuario es un modelo de baja fidelidad de la interfaz de usuario para el sistema. La interfaz de usuario de desarrollada a través del diseño antes planeado y del análisis de los requerimiento que el usuario pre-dispone al desarrollador del sistema por ende tiene que cubrir todos los defectos que el usuario haya omitido. O como otra definición se podría decir que es el diseño concreto del caso de uso a partir de una tecnología particular de entrada y salida, así como de su implementación global. S. Santana Ambriz Cuando se desarrolla la Interfaz de Usuario nos podríamos bazar en explorar el uso del sistema, modelo de los elementos principales de la Interfaz de Usuario, modelo de elementos menores de la Interfaz de Usuario. La creación de un prototipo de interfaz de usuario es una técnica de análisis esencial para el buen desarrollo del mismo ya que con esta se puede darle una idea al usuario como seria implementado y asi mismo sacar posibles errores del mismo. 2.2 DISEÑO DE LA LÓGICA. Todo sistema se tiene que implementar un diseño de la lógica para la buena organización y procesamiento de las tareas a realizar por el sistema. 2.2.1 CLASES Y OBJETOS. Se puede definir como clase a todas las acciones que los objetos van a realizar para realizar una tarea determina por la cual las clases son las encargadas de manipular a los objetos. Los objetos son partes del sistema fijas o que tengan estados definibles (abierto, cerrado), que posea comportamientos asociados (puede correr, saltar, volar, etc) y son capaces de comunicarse con otros objetos por medio de sus métodos 2.2.2 INTERACCIÓN. Los diagramas de interacción se pueden describir como la manera en que colaboran grupos de objetos para cierto comportamiento. O también lo podemos definir desde otro punto de visa como el conjunto de todos los diagramas en uno mismo para empezar a armar el sistema con todos los elementos antes descriptos. Hay dos tipos de diagramas de interacción: diagramas de secuencia y diagramas de colaboración. 2.2.3 ESTADOS Y TRANSICIÓN. Los diagramas de estados son una técnica conocida para describir el comportamiento de un sistema. Describen todos los estados posibles en los que puede entrar un objeto particular y la manera en que cambia el estado del objeto. Los diagramas de estados se dibujan para una sola clase mostrando el comportamiento de un solo objeto durante todo su ciclo de vida. S. Santana Ambriz Un estado representa una etapa en el patrón de comportamiento de un objeto casi siempre se comienza con un estado inicial y uno final para posteriormente ir desarrollando los demás estado conforme el sistema lo requiera. El estado identifica un periodo de tiempo del objeto en el cual el objeto está esperando alguna operación. El evento es una ocurrencia que puede causar la transición de un estado a otro de un objeto. Una transición simplemente es una relación entre dos estados que indica que un objeto en el primer estado puede entrar al segundo estado y ejecutar ciertas operaciones, cuando un evento ocurre y si ciertas condiciones son satisfechas. Se puede representar como una línea sólida entre dos estados, que puede venir acompañada de un texto con el siguiente formato: event-signature "[" guard-condition] "/" action-expression "^"send-clause Event-signaturees la descripción del evento, guard-conditionson las condiciones adicionales al evento necesarias para que la transición ocurra, action-expressiones un mensaje al objeto y send-clauseson acciones adicionales que se ejecutan con el cambio de estado. Una transición interna permanece en el mismo estado, en vez de involucrar dos estados distintos Este evento desencadena una transición que permite salir del estado que alberga la actividad de espera. El flujo de control se transmite entonces a otro estado. CONCLUSIÓN La documentación de la arquitectura es una actividad fundamental para poder realizar una comunicación adecuada del diseño. Es importante recalcar que no existen criterios precisos que permitan determinar el grado exacto de documentación que se debe realizar, y esto se debe determinar considerando diversos aspectos que incluyen a los involucrados, el tipo de proyecto y la experiencia del equipo de desarrollo. REFERENCIAS [1] Kruchten Philippe, “Architectural Blueprints—The “4+1” View Model of Software Architecture”, IEEE Software 12, 1995 [2] IEEE Computer Society, “IEEE Recommended Practice for Architectural Description of Software-Intensive Systems”, IEEE Std 1471-2000, 2000 [3] Clements P. et al. Documenting Software Architectures, Views and Beyond. Addison Wesley, 2003 [4]http://www.cs.buap.mx/~dpinto/semadoo/mario.pdf [5] http://julleny4801.blogspot.mx/2012/09/12-desarrollo-orientado-objetos.html