Son muchas las herramientas llamadas CASE que apoyan el modelado bajo las reglas que dicta UML en sus diversas versiones, tanto privativas como libres, les dejo este link sobre un cuadro comparativo de algunas herramientas de UML, ajustadas a una serie de criterios:
http://www.diatel.upm.es/malvarez/UML/Comparativa.html
domingo, 29 de mayo de 2011
Lenguaje Unificado de Modelado (UML)
El lenguaje unificado de diagrama o notación (UML) sirve para especificar,visualizar y documentar esquemas de sistemas de software orientado a objetos. UML no es un método de desarrollo, lo que significa que no sirve para determinar qué hacer en primer lugar o cómo diseñar el sistema, sino quesimplemente le ayuda a visualizar el diseño y a hacerlo más accesible para otros.
Hay dos grupos principales: Diagramas Estructurales los cuales muestran una vista estática del modelo; y Diagramas de Comportamiento los cuales muestran una vista dinámica del modelo. Veamos a continuación, la lista de diagramas que componen cada grupo:
Diagramas Estructurales: representan elementos componiendo un sistema o una función. Estos diagramas pueden reflejar las relaciones estáticas de una estructura, como lo hacen los diagramas de clases o de paquetes, o arquitecturas en tiempo de ejecución, tales como diagramas de Objetos o de Estructura Compuesta.
- Diagrama de Clases: captura la estructura lógica del sistema, las clases y cosas que constituyen el modelo. Es un modelo estático, describiendo lo que existe y qué atributos y comportamiento tiene, más que cómo se hace algo.
- Diagrama de Objetos: está relacionado de cerca con un diagrama de Clases, con la diferencia de que éste describe las instancias de los objetos de clases en un punto en el tiempo.
- Diagrama de Componentes: ilustra los fragmentos de software, controladores embebidos, etc. que conformarán un sistema. Un diagrama de componentes tiene un nivel de abstracción más elevado que un diagrama de clase; usualmente un componente se implementa por una o más clases (u objetos) en tiempo de ejecución.
- Diagrama de Estructura Compuesta: refleja la colaboración interna de clases, interfaces o componentes para describir una funcionalidad. Los diagramas de estructura compuesta son similares a los diagramas de clase, a excepción de que estos modelan un uso especifico de la estructura.
- Diagrama de Despliegue: muestra cómo y dónde se desplegará el sistema. Las máquinas físicas y los procesadores se representan como nodos, y la construcción interna puede ser representada por nodos o artefactos embebidos. Como los artefactos se ubican en los nodos para modelar el despliegue del sistema, la ubicación es guiada por el uso de las especificaciones de despliegue.
- Diagrama de Paquetes: se usan para reflejar la organización de los paquetes y sus elementos, y para proveer una visualización de sus correspondientes nombres de espacio.
- Diagrama de Interacción: Una interacción es una generalización para un tipo de diagrama de interacción. Los diagramas de interacción pueden ser: de secuencia, de tiempos, de comunicaciones y de descripción de la interacción.
- Diagrama de Secuencia: es una representación estructurada de comportamiento como una serie de pasos secuenciales a lo largo del tiempo. Se usa para representar el flujo de trabajo, el paso de mensajes y cómo los elementos en general cooperan a lo largo del tiempo para lograr un resultado.
- Diagrama de Tiempos: define el comportamiento de los diferentes objetos con una escala de tiempo. Provee una representación visual de los objetos cambiando de estado e interactuando a lo largo del tiempo.
- Diagrama de Comunicaciones: muestra las interacciones entre los elementos en tiempo de ejecución en forma semejante a un diagrama de Secuencia. No obstante, los diagramas de Comunicación se usan para visualizar relaciones inter-objetos, mientras que los diagramas de Secuencia son más efectivos para visualizar procesamiento a lo largo del tiempo.
- Diagrama de Descripción de la Interacción: muestran la cooperación entre otros diagramas de interacción para reflejar el flujo de control que responde a un propósito abarcativo.
- Diagrama de Actividades:se usan para modelar el comportamiento de un sistema, y la manera en que éste comportamiento está relacionado con un flujo global del sistema. Se usan los caminos lógicos que sigue un proceso basado en varias condiciones, concurrencia en el proceso, los datos de acceso, interrupciones y otras alternativas del camino lógico para construir un proceso, sistema o procedimiento.
- Diagrama de Casos de Uso: describen las relaciones y las dependencias entre un grupo de casos de uso y los actores participantes en el proceso. Describe los requisitos funcionales del sistema, la forma en la que las cosas externas (actores) interactúan a través del límite del sistema y la respuesta del sistema.
- Diagrama de Máquina de Estados: modela el comportamiento de un solo objeto, especificando la secuencia de eventos que un objeto atraviesa durante su tiempo de vida en respuesta a los eventos. Ilustra cómo un elemento (a menudo una clase) se puede mover entre estados, clasificando su comportamiento de acuerdo con los disparadores de transiciones y las guardas de restricciones.
martes, 3 de mayo de 2011
Objetivos de la ingeniería de software
La parte más difícil de construir un sistema es precisamente saber qué construir. Ninguna otra parte del trabajo conceptual es tan difícil como establecer los requerimientos técnicos detallados, incluyendo todas las interfaces con gente, máquinas y otros sistemas. Ninguna otra parte del trabajo afecta tanto el sistema si es hecha mal. Ninguna es tan difícil de corregir más adelante… Entonces, la tarea más importante que el ingeniero de software hace para el cliente es la extracción iterativa y el refinamiento de los requerimientos del producto. [Frederick P. Brooks, 1987]
En la construcción y desarrollo de proyectos se aplican métodos y técnicas para resolver los problemas, la informática aporta herramientas y procedimientos sobre los que se apoya la ingeniería de software.
- Mejorar la calidad de los productos de software
- Aumentar la productividad y trabajo de los ingenieros del software
- Facilitar el control del proceso de desarrollo de software
- Suministrar a los desarrolladores las bases para construir software de alta calidad en una forma eficiente
- Definir una disciplina que garantice la producción y el mantenimiento de los productos software desarrollados en el plazo fijado y dentro del costo estimado
1) Correccion
2) Fiabilidad
3) Eficiencia
4) Integridad
5) Facilidad de uso
6) Faciliadad de mantenimiento
7) Flexibilidad
8) Facilidad de prueba
9) Portabilidad
10) Facilidad de reuso
11) Interoperabilidad
Fuente(s):
http://www.slideshare.net/guest9ad165/intoduccion-a-la-ingenieria-del-software
http://www.monografias.com/trabajos5/inso/inso.shtml#obje
Ingeniería del software libre
El término ingeniería del software empezó a usarse a finales de la década de los sesenta, para expresar el área de conocimiento que se estaba desarrollando en torno a las problemáticas que ofrecía el software en ese momento.
En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software (en palabras de Edsger Dijkstra) entre los años 1965 y 1985.
Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, etc.) que sus implicaciones iban más allá de las pérdidas millonarias que causaban.
La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías.
Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software.
Entre las herramientas, la programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación, los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello.
Por supuesto, también ha habido quien ha culpado a los programadores por su indisciplina o anarquía en sus desarrollos. La ignorancia y algunos casos excéntricos contribuyeron a crear una imagen falsa del programador, que hoy en día aún perdura. Aunque muchas veces él es el “sufridor” de alguna de estas metodologías o de una pobre implementación de las mismas, parece lógico que, como participante activo en el proyecto, las metodologías más modernas empiecen a tenerle más en cuenta.
En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas de la ingeniería.
Entre las metodologías y procesos, además de Métrica v3 (promovida por la Secretaría del Consejo Superior de Informática) y eXtreme Programming, que veremos en detalle más adelante, destacan muchos otros como RUP (rational unified process desarrollado por Rational Software Corp. ahora una división de IBM), SSADM (structured systems analysis and design methodology promovido por el Gobierno británico) o el método de evaluación de la capacidad de desarrollo de los equipos o empresas conocido como CMMI (capability maturity model integration). Paralelamente, suelen usarse también métodos de predicción de costes como COCOMO o los puntos de función.
Las últimas iniciativas en este campo son múltiples y se extienden a lo largo de todo el proceso relacionado con el software. Los más académicos se inclinan por una estructura de componentes, servicios, con orientación a objetos o a aspectos en la implementación; aunque también es igual de significativo el desarrollo de las herramientas que nos ayuden a representar y compartir estos diseños, así como a valorar el esfuerzo y el valor que añaden al producto final. Es realmente un campo fascinante, donde tanto en los seminarios o en las grandes consultoras, como en los pequeños laboratorios se innova cada día y se presentan buenas ideas.
En esa época, el crecimiento espectacular de la demanda de sistemas de computación cada vez más y más complejos, asociado a la inmadurez del propio sector informático (totalmente ligado al electrónico) y a la falta de métodos y recursos, provocó lo que se llamó la crisis del software (en palabras de Edsger Dijkstra) entre los años 1965 y 1985.
Durante esa época muchos proyectos importantes superaban con creces los presupuestos y fechas estimados, algunos de ellos eran tan críticos (sistemas de control de aeropuertos, equipos para medicina, etc.) que sus implicaciones iban más allá de las pérdidas millonarias que causaban.
La crisis del software pasó, no tanto por la mejora en la gestión de los proyectos, sino en parte porque no es razonable estar en crisis más de veinte años, y en parte porque se estaban haciendo progresos en los procesos de diseño y metodologías.
Así pues, desde 1985 hasta el presente, han ido apareciendo herramientas, metodologías y tecnologías que se presentaban como la solución definitiva al problema de la planificación, previsión de costes y aseguramiento de la calidad en el desarrollo de software.Entre las herramientas, la programación estructurada, la programación orientada a objetos, a los aspectos, las herramientas CASE, el lenguaje de programación ADA, la documentación, los estándares, CORBA, los servicios web y el lenguaje UML (entre otros) fueron todos anunciados en su momento como la solución a los problemas de la ingeniería del software, la llamada “bala de plata” (por silver bullet). Y lo que es más, cada año surgen nuevas ideas e iniciativas encaminadas a ello.
Por supuesto, también ha habido quien ha culpado a los programadores por su indisciplina o anarquía en sus desarrollos. La ignorancia y algunos casos excéntricos contribuyeron a crear una imagen falsa del programador, que hoy en día aún perdura. Aunque muchas veces él es el “sufridor” de alguna de estas metodologías o de una pobre implementación de las mismas, parece lógico que, como participante activo en el proyecto, las metodologías más modernas empiecen a tenerle más en cuenta.
En combinación con las herramientas, también se han hecho esfuerzos por incorporar los métodos formales al desarrollo de software, argumentando que si se probaba formalmente que los desarrollos hacían lo que se les requería, la industria del software sería tan predecible como lo son otras ramas de la ingeniería.
Entre las metodologías y procesos, además de Métrica v3 (promovida por la Secretaría del Consejo Superior de Informática) y eXtreme Programming, que veremos en detalle más adelante, destacan muchos otros como RUP (rational unified process desarrollado por Rational Software Corp. ahora una división de IBM), SSADM (structured systems analysis and design methodology promovido por el Gobierno británico) o el método de evaluación de la capacidad de desarrollo de los equipos o empresas conocido como CMMI (capability maturity model integration). Paralelamente, suelen usarse también métodos de predicción de costes como COCOMO o los puntos de función.
Las últimas iniciativas en este campo son múltiples y se extienden a lo largo de todo el proceso relacionado con el software. Los más académicos se inclinan por una estructura de componentes, servicios, con orientación a objetos o a aspectos en la implementación; aunque también es igual de significativo el desarrollo de las herramientas que nos ayuden a representar y compartir estos diseños, así como a valorar el esfuerzo y el valor que añaden al producto final. Es realmente un campo fascinante, donde tanto en los seminarios o en las grandes consultoras, como en los pequeños laboratorios se innova cada día y se presentan buenas ideas.
Suscribirse a:
Entradas (Atom)