xo-zam

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