ENSAYO Analisis y Diseño del software
Anuncio
Tecnológico de Estudios Superiores de Ecatepec División de Ingeniería en Sistemas Computacionales Academia de Ingeniería Aplicada Asignatura: Desarrollo de Proyectos de Software Ensayo: Análisis y Diseño de software Profesora: Xóchitl Raquel Wong Cohén Alumno: J. C. Cruz Calderon Grupo: 5801 Fecha de entrega: 31 de Marzo del 2014 RESUMEN La arquitectura software trata el diseño e implementación de la estructura de alto nivel del software. El enfoque de orientación a objetos es una forma de observar la realidad. La diagramación, también llamada maquetación, es un oficio del diseño editorial que se encarga de organizar en un espacio, contenidos escritos y visuales. El modelo de casos de uso, permite hacer una mejor toma de requerimientos y clarificarla funcionalidad del sistema, es decir que espera el usuario que haga el sistema. La interfaz de usuario es el espacio por medio del cual se pueden comunicar las personas con las máquinas para que así los usuarios puedan operar y controlar a la máquina. Una clase es un marco que permite crear objetos semejantes; es decir con las mismas características. Una clase representa un grupo de objetos que comparten una misma estructura y un mismo comportamiento. Las interacciones se centran en los mensajes intercambiados entre los objetos, y no en los datos asociados a esos mensajes. Los estados a menudo realizan diferentes actividades manipulan un mismo objeto que cambia de estado según el grado de avance del mecanismo. 1 INTRODUCCIÓN La arquitectura software trata el diseño e implementación de la estructura de alto nivel del software. Es el resultado de ensamblar un cierto número de elementos arquitectónicos para satisfacer la funcionalidad y ejecución de los requisitos del sistema. Un modelo representa a un sistema software desde una perspectiva específica. La interfaz de usuario es el espacio por medio del cual se pueden comunicar las personas con las máquinas para que así los usuarios puedan operar y controlar a la máquina, y que esta a su vez envíe retroalimentación para ayudar al operador a tomar decisiones y realizar tareas. También podrá descubrir cuál es la diferencia entre un objeto y una clase. Lo cual los objetos son solo instancias de clases. También sabrá cuál es la interacción en cuestión del desarrollo de proyectos de software así como los Estado y transiciones. 2 DESARROLLO: 4+1 VISTAS La arquitectura software trata el diseño e implementación de la estructura de alto nivel del software. Es el resultado de ensamblar un cierto número de elementos arquitectónicos para satisfacer la funcionalidad y ejecución de los requisitos del sistema(“4mas1 jgarzas,” n.d.). En mi opinión 4+1 vistas es una arquitectura que ha sido implementada en muchos softwares de lo cual por medio de vistas es fácil crear la representación de un sistema, aunque también debemos de decir que el modelo en algunos casos no es necesario aplicar pero es un modelo a seguir. 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) (“Desarrollo de proyectos de software,” n.d.).. En otro punto de vista el desarrollo orientado a objetos nos permite resolver problemas de que hace el sistema, mandar órdenes, etc. Con el desarrollo orientado a objetos es más fácil de realizar un sistema ya que por medio de objetos se realizan procesos distintos y dan un mejor resultado y optimización. DIAGRAMACIÓN Un diagrama representa a un sistema software desde una perspectiva específica. Al igual que la planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema(“Desarrollo de proyectos de software,” n.d.). . En mi opinión la diagramación es lo más importante porque es uno de los primeros pasos para realizar un software ya que nosotros podemos definir si realmente funcionara o no un sistema. Existen muchos Diagramas pero cada diagrama tiene un uso en específico como el diagrama de casos de uso o los diagramas de clases que le da un uso estético al sistema. ACTIVIDAD DE CASOS DE USO El modelo de casos de uso, permite hacer una mejor toma de requerimientos y clarificarla funcionalidad del sistema, es decir que espera el usuario que haga el sistema, no tanto como lo haga o con qué(“Diseño del sistema en base a procesos,” n.d.). . 3 En otra perspectiva es una descripción de los pasos o las actividades que deberán realizarse para llevar a cabo algún proceso. Los diagramas de casos de uso sirven para especificar la comunicación y el comportamiento de un sistema mediante su interacción con los usuarios y/u otros sistemas. INTERFACES DE USUARIO La interfaz de usuario es el espacio por medio del cual se pueden comunicar las personas con las máquinas para que así los usuarios puedan operar y controlar a la máquina, y que esta a su vez envíe retroalimentación para ayudar al operador a tomar decisiones y realizar tareas. Mi opinión es que La interfaz es otro punto importante ya que el sistema requiere uno para que se puede interactuar con el sistema y así hacer más fácil el uso de un hardware sin que el usuario tenga que realizar otro trabajo extra con el hardware, por eso el interfaz nos permite interactuar con el software y el hardware (“3. Clases. CLASES Y OBJETOS Las clases y los objetos son importantes en el desarrollo orientado a objetos, una clase pues nos permite tener funciones, métodos, atributos que puede realizar un objeto, en si cual es la diferencia entre un objeto y una clase, que un objeto es la llamada de una clase eso es un objeto en si el objeto es una parte de una clase, siempre van a estar unidos. Cabe destacar que un objeto puede tener polimorfismo, herencia y encapsulamiento. En otra opinión las clases y los objetos son: Las clases son plantillas que agrupan comportamiento (métodos) y estados (atributos) de los futuros objetos. Así como los objetos Se puede decir que un objeto es todo aquello que pueda ser identificable dentro de una especificación de requerimientos. INTERACCIÓN Una interacción modela un Escenario concreto, presentando: Todos los objetos que colaboran Los mensajes enviados entre los objetos(“Desarrollo de software,” n.d.).. En si una interacción se usa para la realizar una traza de la ejecución de un escenario y una interacción se realiza con objetos también. ESTADOS Y TRANSICIONES Es una manera para caracterizar un cambio en un sistema, es decir que los objetos que lo componen modificaron su estado como respuesta a los sucesos y al tiempo. En si mi opinión es que un software tiene un estado son importantes en un sistemas igual que una transición ya que un estado y una transición se ve reflejado en la diagramación cada paso es un estado y si el resultado es correcto entonces se avanza y ahí se cumple 4 una transición entonces es muy importante los estados y transiciones en la calidad del software(Uml, n.d.). METODOLOGÍA LA ARQUITECTURA 4+1 VISTAS La arquitectura software trata el diseño e implementación de la estructura de alto nivel del software. Es el resultado de ensamblar un cierto número de elementos arquitectónicos para satisfacer la funcionalidad y ejecución de los requisitos del sistema Es muy complejo capturar la arquitectura software en un sólo modelo (o diagrama). Para manejar esta complejidad se representan diferentes aspectos y características de la arquitectura en múltiples vistas. Una vista es “una presentación de un modelo, la cual es una descripción completa de un sistema desde una particular perspectiva” (Kruchten, 1995). El modelo más aceptado a la hora de establecer las vistas necesarias para describir una arquitectura software es el modelo 4+1(“4mas1 - jgarzas,” n.d.). No toda arquitectura de software requiere las “4+1” vistas completas. Las vistas que no son u ‘tiles pueden omitirse de la descripción de arquitectura, tales como la vista física si hay un único procesador, y la vista de procesos si existe un solo proceso o programa. Para sistemas muy pequeños, es posible que las vistas lógica y de desarrollo sean tan similares que no requieran descripciones independientes. Los escenarios son útiles en todas las circunstancias (Software & Kruchten, 2006). 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). Percibimos tal cual por sus características y su respuesta ante el entorno. Un elemento notable es que las características de un objeto pueden ser por sí mismas otros objetos(“DESARROLLO DE PROYECTOS DE SOFTWARE: 1.2.- DESARROLLO ORIENTADO A OBJETOS,” n.d.). Desarrollo Orientado A Objetos es una técnica de programación cuyo soporte fundamental es el objeto. Es un modo de trabajo más natural, que permite al desarrollador centrarse en solucionar el problema en lugar de tener que andar pensando en cómo decirle a la computadora que haga esto o lo otro. La programación orientada a objetos es un modo de trabajo más natural, que te permite centrarte en solucionar el problema en lugar de tener que andar pensando en cómo decirle a la computadora que haga esto o lo otro(“Desarrollo de proyectos de software,” n.d.). 5 Un objeto puede considerarse como una especie de cápsula dividida en tres partes: 1. RELACIONES. Las relaciones permiten que el objeto se inserte en la organización y están formadas esencialmente por punteros a otros objetos. 2. PROPIEDADES Las propiedades distinguen un objeto determinado de los restantes que forman parte de la misma organización y tiene valores que dependen de la propiedad de que se trate. Las propiedades de un objeto pueden ser heredadas a sus descendientes en la organización. 3. METODOS. Los métodos son las operaciones que pueden realizarse sobre el objeto, que normalmente estarán incorporados en forma de programas (código) que el objeto es capaz de ejecutar y que también pone a disposición de sus descendientes a través de la herencia. DIAGRAMACIÓN Un modelo representa a un sistema software desde una perspectiva específica. Al igual que la planta y el alzado de una figura en dibujo técnico nos muestran la misma figura vista desde distintos ángulos, cada modelo nos permite fijarnos en un aspecto distinto del sistema. Los modelos de UML que se tratan en esta parte son los siguientes: • Diagrama de Estructura Estática. • Diagrama de Casos de Uso. • Diagrama de Secuencia. • Diagrama de Colaboración. • Diagrama de Estados. Diagramas de clases Los diagramas de clases proporcionan una perspectiva estática del sistema (representan su diseño estructural), son los bloques de construcción más importantes de cualquier sistema orientado a objetos y es una descripción de un conjunto de objetos que comparten los mismos atributos, operaciones, relaciones y semántica(“Desarrollo de proyectos de software,” n.d.). La diagramación, también llamada maquetación, es un oficio del Diseño editorial que se encarga de organizar en un espacio, contenidos escritos, visuales y en algunos casos audiovisuales (multimedia) en medios impresos y electrónicos, como libros, diarios y revistas(“Desarrollo de Proyectos de Software,” n.d.). DISEÑO DEL SISTEMA EN BASE A PROCESOS. ACTIVIDADES Y CASOS DE USO 6 El modelo de casos de uso, permite hacer una mejor toma de requerimientos y clarificarla funcionalidad del sistema, es decir que espera el usuario que haga el sistema, no tanto como lo haga o con qué. Por lo tanto una descripción de un caso de uso específico se debe orientar hacia qué es lo que ese usuario haría allí en interacción con un sistema. Por lo tanto si tiene un caso de uso llamado “Registrar inventario”, en la descripción no puede tener un paso que diga “el usuario registra el inventario” y listo, puesto que eso es Precisamente lo que le preguntan, como se registra, (los pasos), los datos que se manipulan y que operaciones se hacen con ellos(“Diseño del sistema en base a procesos,” n.d.). INTERFACES DE USUARIO La interfaz de usuario es el espacio por medio del cual se pueden comunicar las personas con las máquinas para que así los usuarios puedan operar y controlar a la máquina, y que esta a su vez envíe retroalimentación para ayudar al operador a tomar decisiones y realizar tareas. La palabra "interface" -interfaz en inglés- puede traducirse como: superficie de contacto entre dos cuerpos. Lo que en este caso nos ayuda a entender el término, ya que se pude decir que la interfaz de usuario es el área en el que máquina y usuario se tocan para interactuar, pero sin invadir el espacio del otro. Hay interfaces que funcionan por medio de texto, es decir que no son gráficas. Un ejemplo de esto sería el sistema operativo MS-DOS, que funciona introduciendo cadenas de comandos para operar una computadora(“Interfaz de Usuario,” n.d.). Las interfaces de usuario no solamente se limitan al software de una computadora, sino que también incluyen el hardware. Es importante señalar que dentro del proceso de creación de la IU existen cuatro diferentes tipos de personas involucradas. La primera persona, y probablemente la más importante, es el usuario final o simplemente usuario. El usuario es quien va a utilizar el programa final. La segunda persona es aquella que crea la interfaz de usuario. Esta persona es conocida como diseñador o arquitecto de la interfaz de usuario. Trabajando muy cercanamente con el diseñador estará el programador de la aplicación, este será el encargado de la escritura del software del resto de la aplicación. CLASES Y OBJETOS Objetos: Se puede decir que un objeto es todo aquello que pueda ser identificable dentro de una especificación de requerimientos o problema y tenga las siguientes características: Tenga estados definibles (abierto, cerrado). Posea comportamientos asociados (puede correr, saltar, volar, etc.). Éstos son denominados métodos. Son capaces de interactuar/comunicarse con otros objetos por medio de sus métodos 7 Una característica propia de este paradigma, es la transparencia entre la implementación a nivel de código y la funcionalidad que provee un método (no me interesa cómo lo haga, sólo que lo haga)(“POO – Objetos, Clases y Herencia Simple | El blog de Martini en WordPress.com,” n.d.). Es el conjunto valores de los atributos que tiene el objeto. El estado de un objeto evoluciona con el tiempo. Algunos atributos pueden ser constantes, otros serán variables. El estado de un objeto se almacena en las variables asociadas a cada objeto(“3. Clases y objetos | POO Virginia Calpena en WordPress.com,” n.d.). Clases: Las clases son plantillas que agrupan comportamiento (métodos) y estados (atributos) de los futuros objetos. Los objetos son instancias de una clase. Usando el símil “variable – tipo” de la programación estructurada, se entiendo que un objeto es una variable que tiene el comportamiento y estados del tipo (objeto)(“POO – Objetos, Clases y Herencia Simple | El blog de Martini en WordPress.com,” n.d.). Una clase es un marco que permite crear objetos semejantes; es decir con las mismas características. Una clase representa un grupo de objetos que comparten una misma estructura y un mismo comportamiento; es decir, una clase representa un grupo de objetos con los mismos atributos y los mismos métodos(“3. Clases y objetos | POO Virginia Calpena en WordPress.com,” n.d.). INTERACCIONES Una interacción modela un Escenario concreto, presentando: Todos los objetos que colaboran Los mensajes enviados entre los objetos. Las interacciones se centran en los mensajes intercambiados entre los objetos, y no en los datos asociados a esos mensajes. 8 Las interacciones aparecen en la colaboración de objetos existentes en el contexto de Una operación Los parámetros, variables locales y objetos globales a la operación (visibles por ella) pueden interactuar entre sí para llevar a cabo el algoritmo que la implementa. Cualquier clasificador Las interacciones sirven para visualizar, especificar, construir y documentar la semántica de un clasificador (clase, componente, nodo o caso de uso). En el contexto de un caso de uso la interacción representa un escenario (flujo particular)(“Desarrollo de software,” n.d.). ESTADOS Y TRANSICIONES Es una manera para caracterizar un cambio en un sistema, es decir que los objetos que lo componen modificaron su estado como respuesta a los sucesos y al tiempo. Presenta los estados en los que puede encontrarse un objeto junto con las transiciones entre los estados, y muestra los puntos inicial y final de una secuencia de cambios de estado. Las transiciones entre actividades pueden vigilarse con condiciones booleana mutuamente exclusivas. Los guardas se representan cerca de las transiciones cuyo desencadenamiento validan. Las transiciones al principio de simultáneamente(Uml, n.d.). una barra de sincronización se desencadenan Los estados A menudo realizan diferentes actividades manipulan un mismo objeto que cambia de estado según el grado de avance del mecanismo. En este caso los flujos de objetos se representan por flechas punteadas. Una flecha enlaza un objeto a la actividad que la ha creado. Asimismo una flecha vincula un objeto a las actividades que lo ponen en juego, Ejemplo. 9 CONCLUSIÓN Mi conclusión tanto el análisis como el diseño son muy importantes ya que no se puede crear una sistema así al cómo vaya saliendo eso generaría tiempo, mucho esfuerzo y dinero eso es pagar los platos rotos por no tener un análisis y diseño, Cabe destacar que cada proceso es muy importante desde empezar a que es lo que se quiere hacer, ya teniendo eso como estructurar el sistema, realizar un diagrama define todo el sistema, la interfaz hace posible la interacción con el software y hardware, en si todo es importante para realizar un buen sistema. 10 REFERENCIAS 3. Clases y objetos | POO Virginia Calpena en WordPress.com. (n.d.). Retrieved March 30, 2014, from http://vcalpena.wordpress.com/clases-y-objetos/ 4mas1 - jgarzas. (n.d.). Retrieved February 27, 2014, from https://sites.google.com/site/jgarzas/4mas1 Desarrollo de proyectos de software. (n.d.), 1–4. Desarrollo de Proyectos de Software. (n.d.). Retrieved March 30, 2014, from http://fernandotescha.blogspot.mx/ DESARROLLO DE PROYECTOS DE SOFTWARE: 1.2.- DESARROLLO ORIENTADO A OBJETOS. (n.d.). Retrieved March 29, 2014, from http://julleny4801.blogspot.mx/2012/09/12-desarrollo-orientado-objetos.html Desarrollo de software. (n.d.). Retrieved March 30, 2014, from http://ocw.unican.es/ensenanzas-tecnicas/ingenieria-del-software-i/materiales-declase-1/is1-t07-trans.pdf Diseño del sistema en base a procesos. (n.d.). Retrieved March 30, 2014, from http://es.scribd.com/doc/85136722/Diseno-del-sistema-en-base-a-procesos Interfaz de Usuario. (n.d.). Retrieved March 30, 2014, from http://computadorasmac.about.com/od/nuevos-usuarios-mac/g/Interfaz-DeUsuario.htm POO – Objetos, Clases y Herencia Simple | El blog de Martini en WordPress.com. (n.d.). Retrieved March 30, 2014, from http://emartini.wordpress.com/2008/08/06/orientacion-a-objetos-objetos-clases-yherencia-simple/ Uml, O. C. O. N. (n.d.). Análisis y diseño orientado a objetos con. 11
