Lenguaje de Modelado Unificado (UML)

Lenguaje Unificado de Modelado (LUM) o (UML, por sus siglas en inglés, Unified Modeling Language) es el lenguaje de modelado de sistemas de software más conocido y utilizado en la actualidad; está respaldado por el OMG (Object Management Group). Es un lenguaje gráfico para visualizar, especificar, construir y documentar un sistema. UML ofrece un   estándar para describir un "plano" del sistema (modelo), incluyendo aspectos conceptuales tales como procesos de negocio y funciones del sistema, y aspectos concretos como expresiones de lenguajes de programación, esquemas de bases de datos y componentes reutilizables.   

Es importante resaltar que UML es un "lenguaje de modelado" para especificar o para describir métodos o procesos. Se utiliza para definir un sistema, para detallar los artefactos en el sistema y para documentar y construir. En otras palabras, es el lenguaje en el que está descrito el modelo.

Se puede aplicar en el desarrollo de software entregando gran variedad de formas para dar soporte a una metodología de desarrollo de software (tal como el Proceso Unificado Racional o RUP), pero no especifica en sí mismo qué metodología o proceso usar. 

 

UML no puede compararse con la programación estructurada, pues UML significa Lenguaje Unificado de Modelado, no es programación, solo se diagrama la realidad de una utilización en un requerimiento. Mientras que, programación estructurada, es una forma de programar como lo es la orientación a objetos, sin embargo, la programación orientada a objetos viene siendo un complemento perfecto de UML, pero no por eso se toma UML sólo para lenguajes orientados a objetos.

UML cuenta con varios tipos de diagramas, los cuales muestran diferentes aspectos de las entidades representadas.

¿Por qué Utilizar el UML?
Como la estrategia de evaluación incrementa en muchas compañías, las industrias la observa como técnicas de automatización la producción del Software y para mejorar la calidad y reducir los costos y el tiempo del mercado. Éstas técnicas incluyen el componente tecnológico, la programación visual, modelos y sistemas. Los negocios también observan técnicas para manejar la complexión de sistemas, así ellos aumentan en ámbito y en escala.

En particular, ellos reconocen la necesidad de resolver problemas que ocurran en la arquitectura, tales como la distribución física, concurrencia, réplicas, seguridad, carga balanceada y tolerancia de culpa. Adicionalmente, el desarrollo de la World Wide Web (Mundo de la Ancha Telaraña), mientras se hacen algunas cosas simples, tiene exacerbada ese problema de arquitectura.

 

VENTAJAS

• Expresar la intención que tiene el actor (usuario)
• Extraer los requerimientos del usuario y del sistema
• Centrar al analista en las tareas principales de usuario (describiendo los casos de mayor importancia).
• Tener en cuenta todos los usuarios evitando que las personas especializadas en informática dirijan la funcionalidad del nuevo sistema basándose solamente en criterios tecnológicos. 

Desventajas

• No establecen los requisitos funcionales.
• Tampoco permiten establecer los requisitos no funcionales.
•  Los casos de uso deben complementarse con información adicional como:

1.  Reglas de negocio
2.  Requisitos no funcionales
3.  Diccionario de datos que complementen los requerimientos del sistema.Cada caso crítico del uso debe tener un requisito no funcional centrado en el funcionamiento asociado. 

Un modelo es expresado en un lenguaje de modelado. Un lenguaje de modelado consiste de vistas, diagramas, elementos de modelos (los símbolos utilizados en los modelos) y un conjunto de mecanismos generales o reglas que indican cómo utilizar los elementos. Las reglas son sintácticas, semánticas y pragmáticas.

VISTAS: Las vistas muestran diferentes aspectos del sistema modelado. Una vista no es una gráfica, pero sí una abstracción que consiste en un número de diagramas y todos esos diagramas juntos muestran una "fotografía" completa del sistema. Las vistas también ligan el lenguaje de modelado a los métodos o procesos elegidos para el desarrollo.


DIAGRAMAS: Los diagramas son las gráficas que describen el contenido de una vista. UML tiene nueve tipos de diagramas que son utilizados en combinación para proveer todas las vistas de un sistema: diagramas de caso de uso, de clases, de objetos, de estados, de secuencia, de colaboración, de actividad, de componentes y de distribución.


SÍMBOLOS O ELEMENTOS DE MODELO: Los conceptos utilizados en los diagramas son los elementos de modelo que representan conceptos comunes orientados a objetos, tales como clases, objetos y mensajes, y las relaciones entre estos conceptos incluyendo la asociación, dependencia y generalización. Un elemento de modelo es utilizado en varios diagramas diferentes, pero siempre tiene el mismo significado y simbología.


REGLAS O MECANISMOS GENERALES: Proveen comentarios extras, información o semántica acerca del elemento de modelo; además proveen mecanismos de extensión para adaptar o extender UML a un método o proceso específico, organización o usuario.

FUENTES DE INFORMACIÓN:

http://wcano-disenouml.blogspot.mx/2009/04/ventajas-de-los-casos-de-uso.html 

http://www.taringa.net/posts/info/6858927/UML_-Lenguaje-Unificado-de-Modelado.html
http://www.monografias.com/trabajos34/ingenieria-software/ingenieria-software.shtml#quees

Leer más »

METODOLOGÍA RUP

El Proceso Unificado Racional, Rational Unified Process en inglés, y sus siglas RUP, es un proceso de desarrollo de software y junto con el Lenguaje Unificado de Modelado UML, constituye la metodología estándar más utilizada para el análisis, implementación y documentación de sistemas orientados a objetos. El RUP no es un sistema con pasos firmemente establecidos, sino que trata de un conjunto de metodologías adaptables al contexto y necesidades de cada organización, donde el software es organizado como una colección de unidades atómicas llamados objetos, constituidos por datos y funciones, que interactúan entre sí.

RUP es un proceso para el desarrollo de un proyecto de un software que define claramente quien, cómo, cuándo y qué debe hacerse en el proyecto

 

 

RUP como proceso de desarrollo

• RUP es explícito en la definición de software y su trazabilidad, es decir, contempla en relación causal de los programas creados desde los requerimientos hasta la implementación y pruebas.

• RUP identifica claramente a los profesionales (actores) involucrados en el desarrollo del software y sus responsabilidades en cada una de las actividades.


Fases de desarrollo del software

•  Inicio
•  Elaboración
•  Construcción
• Transición

 
Ciclo de vida

El ciclo de vida RUP es una implementación del Desarrollo en espiral. Fue creado ensamblando los elementos en secuencias semi-ordenadas. El ciclo de vida organiza las tareas en fases e iteraciones.

RUP divide el proceso en cuatro fases, dentro de las cuales se realizan varias iteraciones en número variable según el proyecto y en las que se hace un mayor o menor hincapié en las distintas actividades. 

Las primeras iteraciones (en las fases de Inicio y Elaboración) se enfocan hacia la comprensión del problema y la tecnología, la delimitación del ámbito del proyecto, la eliminación de los riesgos críticos, y al establecimiento de una baseline (Línea Base) de la arquitectura.

Durante la fase de inicio las iteraciones hacen mayor énfasis en actividades de modelado del negocio y de requisitos.

En la fase de elaboración, las iteraciones se orientan al desarrollo de la baseline de la arquitectura, abarcan más los flujos de trabajo de requisitos, modelo de negocios (refinamiento), análisis, diseño y una parte de implementación orientado a la baseline de la arquitectura.

En la fase de construcción, se lleva a cabo la construcción del producto por medio de una serie de iteraciones.

Para cada iteración se seleccionan algunos Casos de Uso, se refinan su análisis y diseño y se procede a su implementación y pruebas. Se realiza una pequeña cascada para cada ciclo. Se realizan iteraciones hasta que se termine la implementación de la nueva versión del producto.

En la fase de transición se pretende garantizar que se tiene un producto preparado para su entrega a la comunidad de usuarios.

 

RUP para el desarrollo de software moderno que junto con UML trata de mejorar el desarrollo de software no solo con una serie de pasos establecidos si no combinando varios modelos, esto dependiendo de las necesidades de la empresa que lo solicite.

FUENTE DE INFORMACIÓN:

http://fabianbermeop.blogspot.mx/2010/12/metodologia-rup-desarrollo-de-software.html

http://angellozano.wordpress.com/2009/01/03/%C2%BFque-es-la-metologia-y-que-es-el-ciclo-de-vida/

Leer más »

Modelo en Flor

Para el desarrollo de cualquier producto de software se realizan una serie de tareas entre
la idea inicial y el producto final. 

 

Un modelo de desarrollo establece el orden en el que se harán los procedimientos para la elaboración del producto y tener a si una mejor perspectiva de lo que se realizara.

Si hablamos específicamente del modelo en flor básicamente se basa en la estructura de una flor el cual todos los pétalos u hojas que contenga dicha estructura sera una etapa a realizar.

Sin embargo todas las etapas se deben de desarrollar al mismo tiempo para a si lograr que el procedimiento llegue a obtener un producto final.

Para lograr entender algunas etapas especificas que debe tener este modelo, mencionare solo algunas:

• ANÁLISIS
• DISEÑO
• INICIO
• CÓDIGO 
• IMPLEMENTACIÓN 
• PRUEBAS 

Si en dado caso nuestra opción para realizar un software es la de el modelo en flor recomendare algunos puntos importantes que no debemos de olvidar. 

1. -El proceso del desarrollo de software es el de desarrollar un producto de software.
2. -Los equipos no deben de estar preocupados por el proceso de desarrollo mismo.
3. -Deben de desarrollarse todas las etapas al mismo tiempo hasta que el producto final es alcanzado.

VENTAJAS

• Al terminar el modelo  tendrás el producto de software libre de errores.
• Podrás realizar las pruebas durante el proceso para lograr detectar problemas inmediatamente. 
• Involucración del usuario en todas las etapas del modelo. 

Desventajas

• Demasiada carga de trabajo. 
• Los involucrados en el software tendrán que tener mucha paciencia y minuciosa concentración.
• Si se detecta un error en cualquier etapa tendrán que repararlo inmediatamente de lo contrario no funcionara ninguna etapa y no obtendrán un satisfactorio producto. 

Leer más »

Modelo en V

El modelo-V deriva directamente del modelo en cascada (Waterfall model), y se usa como base de procesos dentro del ciclo de vida de software. El modelo considera el testing como una actividad paralela al SDLC (Sofware development Life Cycle) y no como una actividad aislada que se realiza al final del desarrollo. Fue desarrollado en Alemania por el Ministerio de Defensa.

La siguiente figura muestra como cada fase de desarrollo (a la izquierda de la imagen) se alinean con las fases de testing.

Esta es la representación más simple del modelo en V, en muchos casos las organizaciones crean sus propios modelos usando este como base. El modelo puedes llegar a ser tan complejo como uno quiera.

La ventaja principal con respecto al modelo en cascada es simple, ya que este modelo involucra chequeos de cada una de las etapas del modelo de cascada. Los requisitos se validan con las pruebas de “User Acceptance Test”, Análisis y deseño de arquitectura con las pruebas de IST (integration & system test), mientras que las pruebas a nivel de componentes y a más bajo nivel se realizan en las fases de pruebas de “Assembly” y “Unit Test” respectivamente.

¿Cuales son los objetivos del modelo en V?

• Minimizar los riesgos del proyecto.
• Mejorar y garantizar la calidad del proyecto.
• Reducir los costes totales a lo largo del ciclo de vida del proyecto.
• Mejorar la comunicación entre los Stakeholders.

En definitiva se trata de un modelo más robusto y completo que el Modelo de Cascada, y puede producir software de mayor calidad que con el modelo de cascada (todo depende de la empresa y el secto).

Ventajas:

• La relación entre las etapas de desarrollo y los distintos tipos de pruebas facilitan la localización de fallos.
• Es un modelo sencillo y de fácil aprendizaje
• Hace explícito parte de la iteración y trabajo que hay que revisar
• Especifica bien los roles de los distintos tipos de pruebas a realizar
• Involucra al usuario en las pruebas

Desventajas:

• Es difícil que el cliente exponga explícitamente todos los requisitos
• El cliente debe tener paciencia pues obtendrá el producto al final del ciclo de vida
• Las pruebas pueden ser caras y, a veces, no lo suficientemente efectivas
• El producto final obtenido puede que no refleje todos los requisitos del usuario

FUENTES DE INFORMACIÓN:

http://www.softqanetwork.com/el-famosisimo-modelo-v 

http://spanishpmo.com/index.php/ciclos-de-vida-modelo-en-v/ 

Análisis del Modelo V

Este modelo es una versión mejorada del modelo cascada, incorpora o se enfoca, de mejor manera al control de calidad, este modelo también muestra la relación iterativa entre las distintas fases en el proceso de desarrollo de software y añade dos partes que son:

La VERIFICACIÓN: que tiene relación con la pregunta ¿ Se está haciendo correctamente el producto?

La VALIDACIÓN: que tiene relación con la pregunta ¿ Se está haciendo el producto , es decir, la demostración de que el software cumple con exactitud la finalidad pretendida.

En el modelo V podemos ver las mismas fases del modelo cascada pero con una mejor relación entre ellas.

Leer más »

¿Qué es un Cibernauta y un Nativo Digital?

Cibernauta es aquella persona que navega por Internet.

En principio es un término aplicable a cualquier persona que utiliza un navegador web y visita sitios web; pero suele utilizarse especialmente para aquellas personas que son expertos navegantes de la WWW, incluso sin saber demasiado sobre computación.

 

Sociabilidad de los cibernautas
La idea social más generalizada, es que los cibernautas son personas poco sociables e introvertidas. Pero un estudio realizado por expertos de la Universidad de Cataluña, concluyó que las personas que utilizan Internet son más sociables, se interesan más en la política y tienen relaciones de amistad y familiares más intensas.

Nativo digital

La Red contiene mucha información sobre los conceptos de nativo digital e inmigrante digital. Según la definición propuesta por Marc Prensky, los nativos digitales son aquellas personas que han crecido, se han desarrollado y han adquirido todo su bagaje sociocultural y cognitivo en un vínculo más que estrecho con Internet y las tecnologías en general: teléfonos celulares, videojuegos, televisión, etc. Por contraposición, los inmigrantes digitales se relacionan tardíamente con las TIC y nunca llegan a hacerlo como los nativos, ya que lo hacen desde otro modo de apropiación y utilización del conocimiento y la información en general.

FUENTES DE INFORMACIÓN:

http://www.alegsa.com.ar/Dic/cibernauta.php

http://www.emudesc.net/foros/cafeteria/45779-nativos-e-inmigrantes-digitales.html

Leer más »

¿Qué es la cibernética?

La palabra cibernética en griego se refiere a mecanismos precisos de gobierno y control, con Platón y Ampere es usada siempre en su sentido político - social, pero es utilizada por primera vez en referencia a la ingeniería humana por Norbert Wiener.

La cibernética es una disciplina íntimamente vinculada con la teoría general de sistemas, al grado en que muchos la consideran inseparable de esta, y se ocupa del estudio de: el mando, el control, las regulaciones y el gobierno de los sistemas. El propósito de la cibernética es desarrollar un lenguaje y técnicas que nos permitan atacar los problemas de control y comunicación en general.

Lo que estabiliza y coordina el funcionamiento de los sistemas complejos como los seres vivos o las sociedades y les permite hacer frente a las variaciones del ambiente y presentar un comportamiento más o menos complejo es el control, que le permite al sistema seleccionar los ingresos (inputs) para obtener ciertos egresos (outputs) predefinidos. La regulación esta constituida por los mecanismos que permiten al sistema mantener su equilibrio dinámico y alcanzar o mantener un estado.

Un concepto muy importante o casi fundamental en cibernética es el de la retroalimentación. La retroalimentación parte del principio de que todos los elementos de una totalidad de un sistema deben comunicarse entre sí para poder desarrollar interrelaciones coherentes. Sin comunicación no hay orden y sin orden no hay totalidad, lo que rige tanto para los sistemas físicos como para los biológicos y los sociológicos.

La retroalimentación puede ser positiva, negativa o compensada. La retroalimentación es negativa cuando su función consiste en contener o regular el cambio, es positiva si amplifica o multiplica el cambio en una dirección determinada y se dice que es compensada cuando un regulador ejerce alternadamente retroalimentaciones positivas y negativas, según las necesidades del mantenimiento de la estabilidad del sistema regulado. (ejemplo Refrigerador, Temperatura Humana).

FUENTE DE INVESTIGACIÓN:

http://www.aprendizaje.com.mx/TeoriaSistemas/Cibernetica/cibernetica.html

Leer más »

¿Que son las heuristicas?

Se puede definir Heurística como un arte, técnica o procedimiento práctico o informal para resolver problemas. Alternativamente, se puede definir como un conjunto de reglas, metodológicas no necesariamente formalizadas, positivas y negativas, que sugieren o   establecen cómo proceder y problemas a evitar en la solución de problemas y elaboración de hipótesis.

Es generalmente considerado que la capacidad heurística es un rasgo característico de los humanos desde cuyo punto de vista puede describirse como el arte y la ciencia del descubrimiento y de la invención o de resolver problemas mediante la creatividad y el pensamiento lateral o pensamiento divergente. Según el matemático George Pólya4 la base de la heurística está en la experiencia de resolver problemas y en ver cómo otros lo hacen. Consecuentemente se dice que hay búsquedas ciegas, búsquedas heurísticas (basadas en la experiencia) y búsquedas racionales.

 

La popularización del concepto se debe a Pólya, con su libro Cómo resolverlo (How to solve it). Habiendo estudiado tantas pruebas matemáticas desde su juventud, quería saber cómo los matemáticos llegan a ellas. El libro contiene la clase de recetas heurísticas que trataba de enseñar a sus alumnos de matemáticas. Cuatro ejemplos extraídos de él ilustran el concepto mejor que ninguna definición:

• Si no consigues entender un problema, dibuja un esquema.
• Si no encuentras la solución, haz como si ya la tuvieras y mira qué puedes deducir de ella (razonando a la inversa).
• Si el problema es abstracto, prueba a examinar un ejemplo concreto.
• Intenta abordar primero un problema más general (es la “paradoja del inventor”: el propósito más ambicioso es el que tiene más posibilidades de éxito).

En Ingeniería:

En ingeniería, una heurística es un método basado en la experiencia que puede utilizarse como ayuda para resolver problemas de diseño, desde calcular los recursos necesarios hasta en planear las condiciones de operación de los sistemas. Mediante el uso de heurísticas, es posible resolver más rápidamente problemas conocidos o similares a otros conocidos. Existen varios métodos heurísticos disponibles para los ingenieros como, por ejemplo, el Análisis modal de fallos y efectos y los árboles de fallo. En el primero se depende de un grupo de ingenieros experimentados que evalúan los problemas y fallos, los ordenan según su importancia y recomiendan soluciones.

 
Otros, como los métodos de ingeniería forense, son una amplia fuente de información para la investigación de problemas y responsables, y se basan en la heurística del eslabón más débil y en la eliminación de causas improbables. El conocimiento de qué causas son probables y cuáles no, forma una heurística aprendida por la profesión durante muchos años, más que un conocimiento científico aplicado.
Dado que las heurísticas pueden equivocarse, es fundamental conocer los casos en los que son aplicables y los límites a su uso. En general, en la ingeniería deben considerarse como ayudas o apoyos para hacer estimaciones rápidas y diseños preliminares, pero no como justificaciones finales de un diseño o proyecto u otros.

FUENTE DE INFORMACIÓN:

http://es.wikipedia.org/wiki/Heur%C3%ADstica

Leer más »